code compiled with ifort doesn't work (but with gfortran does)

[Pfor]

Hallo All,
I have a f90 code, if I compile it with gfortran it works, however if I compile it with ifort a segmentation fault occurs.

I use to check for errors in memory allocation with gfortran via the option -fbounds-check and I have been told that the equivalent option for ifort is -C, however it does not return any information on the possible cause of the segmentation fault.

Do you have any suggestion how to search for the error? (which compiler option should I use),
thank you,
cheers,
Paolo

 

[NickFort]

Segmentation faults can also happen with optional arguments (I seem to recall, although, right now, I can't think of why the compiler wouldn't catch them), and allocatable arrays, so checking just the bounds might not help. Do you use either of those?

--------------------------------------
Background: Chemical engineer, familiar mostly with MATLAB, but now branching out into real programming.

 

[FJacq]

compile and link with -g -traceback

if you are lucky, the crash will print out the routine name and possibly the instruction number where the trouble occurred.

another way would be to run the code under a debugger. In setting break points correctly, it is easy to locate rapidly the instruction responsible of a segmentation fault (for instance a wrong call statement).


François Jacq

 

[Pfor]

Hi all,
indeed my code has allocatable arrays and optional variables, however the "funny" thing is that it compiles and works perfectly with gfortran (even with -fbounds-check).

I have no debugger...(I don't know of any free ones, do you have any suggestion?).

I am almost sure it used to work fine also with ifort (on a machine not available now), while on the pc and ifort version I am currently using it doesn't work.

I located where it crashes, just after calling a subroutine,
Within the subroutine the segmentation fault happens just after(during) the declaration of the variables, so that in the subroutine nothing can be done. I inserted a

write(*,*) 'here'

after declaring the variables but nothing is written.

The same variable declaration is present also in another subroutine, which works with no problems (I copied and pasted the declaration from the working sub to the problematic one and the code kept on segmentating).

thanks,
ciao
Paolo

 

[FJacq]

A question : is the called routine defined within a module or is it an external procedure ?

In addition, could you show us how you call the subroutine, how you define it and how you declare the arguments.

A classical mistake concern external procedures. If the dummy argument definitions are using the keywords POINTER, OPTIONAL, ALLOCATABLE, or if an dummy vector, for instance, is declared with ), then the routine needs an explicit interface.

When a procedure is defined within a module, then the explicit interface is automatically known by the calling procedure thanks to the USE statement. On the contrary, if the procedure is external, then you have to provide this interface (a block INTERFACE ... END INTERFACE) at the top of the calling routine (or at the top of the module containing the calling routine).

François Jacq

 

[NickFort]

FJacq, you're right, but why would gfortran be OK, but ifort not? When I've messed up with something like that, gfortran's complained during compile time.

Pfor, which version of gfortran are you using? Also, what about trying to compile with G95? It might give different errors which should give you more clues as to what's wrong.

I can think of a number of tips to give you regarding what to look for with segmentation faults in general, but the fact that gfortran works fine is making that seem redundant to me.

--------------------------------------
Background: Chemical engineer, familiar mostly with MATLAB, but now branching out into real programming.

 

[FJacq]

FJacq, you're right, but why would gfortran be OK, but ifort not?

It is very usual to observe this kind of behavior with a buggy code: it seems to work with a compiler but crashes with another one. this is more or less a question of chance... And when the OP says that his code works fine with gfortran, it just means that it does not crash. I suspect that a deeper examination of the results would exhibit mistakes (not sure again because a segmentation fault often corresponds to a memory corruption and if that memory is not used later by the program, then the results could be OK anyway...)

Notice that most professional developers use several compilers to catch these errors. For instance I use g95, gfortran, ifort, nagfor and also sometimes the Sun compiler (linux only)



François Jacq

 

[Pfor]

Hallo all,
I spent a lot of time trying to install the g95 as suggested with no success... (problems with the linking?)
so I start reporting you the structure of my code which might be helpful.

The segmentation occurs when I call a subroutine called GCR which is in a module called bogo (however I suspect that the subroutine is not responsible for the bug).

in the main program

if(isolv.eq.1) call GCR(npt)

module bogo

use cste
use param
use skforces
use fields

subroutine GCR(npt) !
use param
use cste ; use io ; use fields ; use skforces
use bogostatic ; use eqdifstatic ; use orcesstatic

implicit none
integer :: npt, i,j,k, i2,i3
real ( kind = pr) :: b0,bb ! PA for the iterative method
complex ( kind = pr ) :: Ene !is the energy of the QRPA
complex ( kind = pr ), dimension(0:Niter) :: Cden2 !
complex , parameter :: zI = (0.0_pr,1.0_pr) ! imaginary unit PA
complex ( kind = pr ) , dimension (iLong,0:Niter+1) :: P, AP
complex ( kind = pr ) , dimension (0:Niter, 0:Niter) :: betGCR!
integer :: ien, iter

...


en module bogo


***********************************************
Another funny behaviour is the following:
I tried to compile with ifort again and I received many errors starting with (Cste is the name of one module):

error #7001: Error in creating the compiled module file. [CSTE]
module Cste
-------^
Usohfbrad177.f90(152): error #7013: This module file was not generated by any release of this compiler. [CSTE]
use cste
------^
Usohfbrad177.f90(167): error #6683: A kind type parameter must be a compile-time constant. [PR]
real ( kind = pr ) :: h ! Step of integration.
----------------^
Usohfbrad177.f90(168): error #6683: A kind type parameter must be a compile-time constant. [PR]
real ( kind = pr ) :: h12 ! Definition for Numerov

***********************************************************
then I compiled it with gfortran and it compiled fine,
I re tried to compile it with ifort and now the compilation was successful
(in any case is gives the segmentation fault).

thanks
ciao
Paolo

 

[FJacq]

Before compiling with a new compiler, please take care to delete first files *.mod and *.obj generated by the previous compiler else your risk to get your "funny" error messages.

This king of error is usual when your building directory does not depend on the compiler name. Again, in a professional frame, each couple compiler/operating system is normally associated to a specific building directory...

François Jacq

 

[Pfor]

Hi Frnçois,
I have checked on the remote pc where the code works without
any segmentation fault, summing up:

Cluster, ifort (IFORT) 9.1 20071016 , code working
PC , ifort (IFORT) 12.0.4 20110427 , segmentation fault
PC , gfortran GNU Fortran 95 (GCC) 4.1.0 20060515 (Red Hat 4.1.0-18) , code working

So it seems that there is a conflict between my code and the new version of ifort.

I am wondering if it could be a memory problem, the pc has just 1 Gb while, is it possible that the segmentation fault is caused by some strange way to allocate the memory that exceeds the physical memory of the computer I am currently using? (and maybe gfortan has a less expansive method)

cheers,
ciao
Paolo

 

[FJacq]

It is possible that ifort 12.0 has a specific problem. This is rare but...

You should contact the Intel Fortran Forum. Perhaps Stieve Lionel (Intel Fortran Expert) could help you.

I recently met troubles with Intel Compilers but only in case of mixed C/Fortran applications

François Jacq