strange SIGSEGV error, when simply delete a write(*,*) sentence

[frank2009]

hi,

Something strange takes place when using intel fortran 11.1 046 under openSUSE 11.1 x86_64.

In my program file, when simply insert a line

write(*,*) 'rXTmp = ', rXTmp

things goes ok. But when have this sentence deleted, strange error emerges.

frank@frankpc:~/Desktop/tmp/slr> ifort aaaa.f90
frank@frankpc:~/Desktop/tmp/slr> ./a.out
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
a.out 00000000004037D5 Unknown Unknown Unknown
a.out 000000000040355D Unknown Unknown Unknown
a.out 0000000000402C2C Unknown Unknown Unknown
libc.so.6 00007F168CF2A586 Unknown Unknown Unknown
a.out 0000000000402B29 Unknown Unknown Unknown

I don't know how to solve this problem. Or is this a bug of this compiler?
Could I trust its output?

Program files and related data are attached.



Any help will be deeply appreciated.


Frank
Jul 30,2009

[TimP]

How about doing a little more investigation yourself? It appears likely that the compiler tries to fuse the loops on both sides of that write after you remove it, possibly instead of re-arranging you code for better cache locality, when you write it this way. For example,
rXTmp = 1/3.*(rX(1:6,:) + rX(2:7,:) + rX(3:8,:))
might make more sense than suggesting a slow order of operations and making the compile decide among various ways of transforming it.
Also, you don't tell us whether you have encountered stack overflow and have tried increasing stack limits or avoiding stack by /heap-arrays.
If you don't want compiler optimization passes, there's the -O0 option.

[inkant]

Quoting - tim18

How about doing a little more investigation yourself? It appears likely that the compiler tries to fuse the loops on both sides of that write after you remove it, possibly instead of re-arranging you code for better cache locality, when you write it this way. For example,
rXTmp = 1/3.*(rX(1:6,:) + rX(2:7,:) + rX(3:8,:))
might make more sense than suggesting a slow order of operations and making the compile decide among various ways of transforming it.
Also, you don't tell us whether you have encountered stack overflow and have tried increasing stack limits or avoiding stack by /heap-arrays.
If you don't want compiler optimization passes, there's the -O0 option.

Hello frank,

I have not looked into your code!

However I would like to mention that I got SIGSEGV when I commented out an unused SUBROUTINE. Later I figured out that the error was not because of that subroutine being commented.

You may want to try some checks like this:

-O0 -g -traceback -fp-stack-check -heap-arrays -check all -fp-stack-check -gen-interfaces -warn all

IF windows use '/' in place of '-' ( -heap arrays to-- /heap-arrays )

Inkant

[Stephen_D_Intel]

Hello,

Please try adding this compiler option: '-no-ip' and let us know your results.

Steve D.

[TimP]

Quoting - Steve D. (Intel)

Hello,

Please try adding this compiler option: '-no-ip' and let us know your results.

Steve D.

Or even simply removing the includes, and compiling the 3 source files without setting -fast or -ipo

[frank2009]

Thank you, tim18, inkant and Steve.

I made some modification, replacing the direct use of float(nY()) in the actual parameters by rTmp(:). The modified file is here(aaaa.f90). It works and no errors found.

> ifort aaaa.f90

However, if compile with -O0 option, SIESEGV comes out:

> ifort -O0 aaaa.f90

> ./a.out

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
a.out 00000000004045C1 Unknown Unknown Unknown
a.out 000000000040398A Unknown Unknown Unknown
a.out 00000000004032BC Unknown Unknown Unknown
libc.so.6 00007F97B2F4F586 Unknown Unknown Unknown
a.out 00000000004031B9 Unknown Unknown Unknown
And now wheather -no-ip is applied, ifort -O0 aaaa.f90 have the same results.

As for-O0 -g -traceback -fp-stack-check -heap-arrays -check all -fp-stack-check -gen-interfaces -warn all, it outputs many lines like this:

forrtl: warning (402): fort: (1): In call to SLR, an array temporary was created for argument #1

forrtl: warning (402): fort: (1): In call to PLC, an array temporary was created for argument #1

No warnings or errors about stacks are displayed.

Not advanced in programming or computing, and could not afford much time to learn much complicated insight stuff, I just wish to use a fortran compiler to do some simple work. It seems not easy.

Anyway, thank you very much for your replies.

Frank

[Stephen_D_Intel · Accepted solution]

Hello,

If you add the explicit interfaces of your subroutines to your main program, things
will work fine with both of your examples.

Something like this:

include 'sub_slr.f90'
include 'sub_plc.f90'

program main

implicit none

INTERFACE
SUBROUTINE SLR(RX,RY,NNUM,RA,RB,RUNDEFX,RUNDEFY)
INTEGER(KIND=4), INTENT(IN) :: NNUM
REAL(KIND=4), INTENT(IN) :: RX(NNUM)
REAL(KIND=4), INTENT(IN) :: RY(NNUM)
REAL(KIND=4), INTENT(OUT) :: RA
REAL(KIND=4) ,OPTIONAL, INTENT(OUT) :: RB
REAL(KIND=4) ,OPTIONAL, INTENT(IN) :: RUNDEFX
REAL(KIND=4) ,OPTIONAL, INTENT(IN) :: RUNDEFY
END SUBROUTINE SLR
END INTERFACE

INTERFACE
SUBROUTINE PLC(RX,RY,NNUM,RPLC,RUNDEFX,RUNDEFY)
INTEGER(KIND=4), INTENT(IN) :: NNUM
REAL(KIND=4), INTENT(IN) :: RX(NNUM)
REAL(KIND=4), INTENT(IN) :: RY(NNUM)
REAL(KIND=4), INTENT(OUT) :: RPLC
REAL(KIND=4) ,OPTIONAL, INTENT(IN) :: RUNDEFX
REAL(KIND=4) ,OPTIONAL, INTENT(IN) :: RUNDEFY
END SUBROUTINE PLC
END INTERFACE

integer(kind=4),parameter :: nYearA = 49
...

There's a discussion of why the explicit interfaces are needed in this forum posting:
http://software.intel.com/en-us/forums/showpost.php?p=12903


The command line suggested by inkant implicitly generates the interfaces and includes the
interface definitions in the main program. Removing the '-check all' option will eliminate
the extra messages.

Starting with the 11.1.038 version of the compiler, '-warn interfaces' will generate the
interfaces. This is equivalent to '-gen-interfaces -warn interfaces' in older compilers.


Steve D.

[frank2009]

Thank you Steve. It really solve my problem.

I appreciate your professional and constructive suggestion very much.



Frank