Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Weird compiler crash

Michele_R_
Beginner
488 Views

Hi all,

I am experiencing a weird issue when compiling my code with ifort version 16.0.1.

I receive a catastrophic compiler error (catastrophic error: **Internal compiler error: segmentation violation signal raised...) when trying to compile a module that defines a type that is extended from an abstract type hosted in another module. Unfortunately I am working on a big code so I cannot post the whole source to reproduce the error, nor I am able reproduce the error in a minimal example. Notice that Gfortran is able to compile without any problem.

I am aware that the info I gave are not sufficient to diagnose the issue, but I would appreciate any tips to debug the problem nonetheless.

Also, is there any compiler flag that allows for the logging of the compilation process? That would be really useful to pin point where the failure occurs.

 

 

 

 

 

 

0 Kudos
8 Replies
jimdempseyatthecove
Honored Contributor III
488 Views

If you browse this forum and the Windows Fortran forum you will find a recent post where a user declared a type that had a recursive behavior (I think on the finish section of a type). You might want to check that out for similarities to your situation.

Jim Dempsey

0 Kudos
Steven_L_Intel1
Employee
488 Views

There are countless possible causes of an internal compiler error. We would appreciate your providing us with the affected source and the compile options used. We can then quickly identify the issue and perhaps provide you a workaround until the problem is fixed.

If you want to try narrowing it down yourself, what I do is first identify the minimal set of options that still shows the error, and then I start commenting (or #ifdef-ing) out sections of code until I get a minimal source. It is important to also provide us the full source as sometimes fixing the minimal problem doesn't fix the larger one.

Note that if your source uses modules, we also need the sources to those. You can create a .tgz file and attach that.

0 Kudos
Michele_R_
Beginner
488 Views

 

Thank you both for your quick replies.I attached a stripped-down version of the code that reproduces the error. In order to compile it, an mpi compiler is required. From the top level directory, issue:

cmake -DCMAKE_C_COMPILER=mpicc  -DCMAKE_Fortran_COMPILER=mpif90

make sol

I really appreciate your help: thank you very much!

 

0 Kudos
Steven_L_Intel1
Employee
488 Views

Thanks - we'll check it out.

0 Kudos
Steven_L_Intel1
Employee
488 Views

I've narrowed it down to the generic extension of MAXVAL and MINVAL that gets used in this source. Not that there's anything wrong with how you're doing it, but the compiler is not happy. I want to see how small I can get the reproducer before I send it to the developers. Should be done tomorrow with that.

0 Kudos
Michele_R_
Beginner
488 Views

Steve,

excellent! Thank you very much!

0 Kudos
Steven_L_Intel1
Employee
488 Views

Escalated as issue DPD200381895. I will update this thread when I get further information. I did find that if I changed the dummy argument "velocity" in "compute_new_variables" from CLASS(field) to TYPE(field), the error went away, but this may not be appropriate for the larger application, especially if you extend field anywhere.

0 Kudos
Steven_L_Intel1
Employee
488 Views

This bug has been fixed for a release later this year. 

0 Kudos
Reply