**Internal compiler error: segmentation violation signal raised**

[e745200]

I'm reporting here a simple case in which the Intel Fortran compiler crashes:

This is the program:

$ cat sample.f90

REAL(8) UNO
PRINT *, UNO()
END


FUNCTION UNO()

REAL(8) UNO
UNO = 1.D0
CALL DUE
RETURN

CONTAINS

SUBROUTINE DUE
UNO = 2.D0
RETURN
END SUBROUTINE DUE

END


Then :

$ ifort -logo -c -fp-model strict -save sample.f90

Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1
Build 20091012 Package ID: l_cprof_p_11.1.059
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
Intel Fortran 11.1-2620
: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.

compilation aborted for sample.f90 (code 3)

Note that building without any compiler option, it works fine :

$ ifort sample.f90 -o sample && sample
2.00000000000000


It also works when not using -fp-model strict and -save together.
Then, it seems that the combined effect of this two options (which I use without problems on other source) causes the crash.

If the problem is related to the use of the name of the containing function in the contained subroutine, then I guess the compiler should point this out, instead of crashing ...


Regards

[TimP]

There have been long standing problems with the use of -save with CONTAINS. I see you found a corner which hasn't been fixed. As far as I can see, the only thing wrong with your program is the desire to use -save rather than specifying SAVE in appropriate places in the program. It's still possible to expose the bug by putting SAVE in both containing and contained subroutines, without -save. It seems the compiler should simply save the last set value.

[Ron_Green]

Quoting - tim18

There have been long standing problems with the use of -save with CONTAINS. I see you found a corner which hasn't been fixed. As far as I can see, the only thing wrong with your program is the desire to use -save rather than specifying SAVE in appropriate places in the program. It's still possible to expose the bug by putting SAVE in both containing and contained subroutines, without -save. It seems the compiler should simply save the last set value.

Interesting - looks like -fp-model strict is working in combination with -save on this bug. Compiling without -fp-model and only -save doesn't invoke the error.

I'll get a bug report started.

ron

[Ron_Green]

bug report is DPD200142313

You may have noticed that -fp-model precise or -fp-model source avoid the error. You could work around the error with:

-save -fp-model precise -prec-div -prec-sqrt -nolib-inline

which should give you good numerical stability and SAVE.

ron

[e745200]

Thanks to all for your answers.

Yes, I noticed that the error occurs when using both -fp-model strict and -save and not when using only one of them (see the first post).

I need -fp-model strict because I need to change the floating point exception trapping behavior during the program execution; and the documentation says that that is a necessary flag, for such a purpose, if I remember well.

I will try not to use -save when not really needed (for sure it is better to use the SAVE statements in the code, and only for the variables that need it : I do not like depending on compiler options if not necessary).

I came across the compiler bug while moving a legacy application towards the more recent standard, also using CONTAINS for a better programming style, and I thought it was worth point it out to make Intel improve the compiler robustness.

Thanks again.

[Ron_Green]

This bug was fixed some time ago in 12.x compilers and newer.

closing.  Thanks for sending this in to us.

ron