$ gfortran bug.f90 bug.f90:8: internal compiler error: Segmentation fault $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc4/configure --enable-languages=c,c++,f95 Thread model: posix gcc version 4.1.0 20050609 (experimental) (This is this morning's CVS snapshot) Hmf. I don't see how to attach the "bug.f90" so I will place it in-line below. It's short. If I split into module and main program and compile separately, boom.f90 ICE's at line zero. Suspect a bad "modboom.mod" file. ------------------------------------------- module modboom implicit none ! can comment out private ! comment out, lose the bug public:: dummysub ! comment out, lose the bug type:: intwrapper ! a straight integer won't do integer n end type intwrapper contains subroutine dummysub(size, arg_array) type(intwrapper) :: size real, dimension(size%n) :: arg_array real :: local_array(4) ! comment out, lose the bug end subroutine dummysub end module modboom program boom use modboom ! bad .mod file ? print *, 'hey, we made it!' end program boom -------------------------------------------
Created attachment 9056 [details] self-contained test case, compile with "gfortran bug.f90"
Confirmed.
Segfault here while reading the module: Program received signal SIGSEGV, Segmentation fault. mio_ref (rp=Variable "rp" is not available. ) at ../../gcc/fortran/module.c:1839 1839 if (sym->components != NULL && p->u.pointer == NULL) ... where sym == NUlL. I can't see anything obviously wrong with the module file.
Created attachment 9144 [details] compiles but produces a toxic .mod file
Created attachment 9145 [details] ICE on attempt to USE toxic .mod file If you split the module and main program to separate files (this and previous attachment) the module compiles ok but the compiler ICE's on the main program. Is the bug easier to diagnose this way ? $ gfortran -c -o modboom.o modboom.f90 $ gfortran -fsyntax-only boom.f90 boom.f90:0: internal compiler error: Segmentation fault
Here is a reduced testcase: MODULE module1 TYPE type1 INTEGER TYP1 END TYPE type1 END MODULE MODULE module2 TYPE type2 INTEGER TYP2 END TYPE type2 END MODULE MODULE mymodule CONTAINS SUBROUTINE SUB1() IMPLICIT NONE END SUBROUTINE SUB1 SUBROUTINE SUB2(T_TYPE1, T_TYPE2) USE module1 USE module2 IMPLICIT NONE TYPE (type1):: T_TYPE1 TYPE (type2) T_TYPE2(T_TYPE1%TYP1) END SUBROUTINE SUB2 END MODULE SUBROUTINE A_SUBROUTINE USE mymodule END SUBROUTINE A_SUBROUTINE Oh, this is a dup of bug 19669. *** This bug has been marked as a duplicate of 19669 ***
(In reply to comment #0) This is incorrect code, which should generate an error, rather than an ICE. As ifort9.0 puts it: fortcom: Error: ../pr21986.f90, line 11: This procedure cannot be PUBLIC since it has argument(s) whose derived type(s) are PRIVATE. [SIZE] The example compiles and runs correctly with gfortran and ifort if public:: dummysub is changed to public:: dummysub, intwrapper. I do not see why this is marked as resolved duplicate, since it behaves in the same way that it always did.
This was fixed on mainline and 4.0 The testcase now gives: [root@localhost mytests]# /gcc-clean/bin/gfortran -c pr21986.f90 In file pr21986.f90:4 public:: dummysub ! comment out, lose the bug 1 Error: 'size' is a PRIVATE type and cannot be a dummy argument of 'dummysub', which is PUBLIC at (1) In file pr21986.f90:23 use modboom ! bad .mod file ? 1 Fatal Error: Can't open module file 'modboom.mod' for reading at (1): No such file or directory