------- Comment #1 from burnus at gcc dot gnu dot org 2007-08-27 13:44 -------
Segmentation fault means: The program accessed memory it was not supposed to
access. There is no error if it accesses memory which is garbage but it may
access. Seemingly the first it happening with g95 and ifort and the latter with
gfortran *for your program*.
Depending on the exact program and compiler options, it crashes using one or
the other compiler. It also depends (using glibc) on the setting of
MALLOC_CHECK_ (see "man 3 malloc").
A much more reliable way to catch such errors is to run the program through
valgrind which shows e.g. "Invalid read of size 1" - though this also does not
work always (see below).
Using the program
--------------------------
SUBROUTINE Routine(var1, var2)
INTEGER, INTENT(IN) :: var1
CHARACTER(LEN=3), INTENT(IN) :: var2
print *, var1
print *, var2
end subroutine
--------------------------
Call Routine(5)
end
--------------------------
- gfortran does not crash here (and valgrind does not find the error either)
- ifort does not crash here (and valgrind does not find the error either)
- g95 crashes
The actual call of g95 and gfortran is the same (dump of the tree):
routine_ (&U0);; // g95
and
routine (&C.1016); // gfortran
There are essentially only two possibilities to detect this:
a) Using an explicit interface at compile time
b) Doing an explicit checking at run time
For (a):
- Best: put the routine in a module and USE it or in a CONTAINS of the PROGRAM.
- Write an interface so that still the checking
(Useful e.g. for Lapack which as Fortran 77 code does not come as module.)
- Put them in the same file, this allows the compiler to do more checks.
(gfortran currently does not do same file checks, though this is planned)
- Use a compiler option to generate .mod files to check for this; ifort has
-gen-interfaces which does so. (Also planned for gfortran.)
For (b): Some compiler such as NAG f95 pass additional information so that the
arguments can be checked at run time. This slows down the program a lot and
also needs an extra option.
Anything else such as relying on a segmentation fault is (unfortunately?) not
reliable.
--
burnus at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
GCC host triplet| i686 |i686
Resolution| |INVALID
Summary|'NO' runtime problem with a |'NO' runtime problem with a
|code compiled using gfotran |code compiled using gfotran
|... and it should ! |... and it should !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33202
