[tjf@fkpc167 Bug]$ cat acmod.f90 module AMod implicit none integer::i contains function f() result (s) real(kind=8),dimension(i)::s end function f end module [tjf@fkpc167 Bug]$ gfortran -c acmod.f90 [tjf@fkpc167 Bug]$ cat nnh.f90 program fred use AMod implicit none write(*,*)f() end [tjf@fkpc167 Bug]$ gfortran -v -c nnh.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --disable-multilib --enable-languages=fortran Thread model: posix gcc version 4.2.0 20070228 (prerelease) /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 nnh.f90 -quiet -dumpbase nnh.f90 -mtune=generic -auxbase nnh -version -I /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/ccpjANyk.s GNU F95 version 4.2.0 20070228 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20070228 (prerelease). GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=112046 nnh.f90: In function ‘MAIN__’: nnh.f90:1: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:863 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. I have not tried this with a more up to date gfortran.
Fails with the newest 4.2.0, works with current 4.3.0
Also happens on i686-linux. It's a 4.1/4.2 regression, which means we could theoretically try to fix it. I'm closing this as WONTFIX nonetheless due to the small impact of the bug (it's triggered by invalid code) and the fact that we have already much on our plates. If someone wants to take care of it, of if you (Terry) want to provide a patch, it will be welcome!
While being a reasonably uncommon case, AFAICT it's a legal construct. That is: not invalid code.
(I guess I should qualify that. I don't have a copy of the standard laying around to check, but it's legal according to the Ellis, Philips and Lahey book.)
(In reply to comment #4) > (I guess I should qualify that. I don't have a copy of the standard laying > around to check, but it's legal according to the Ellis, Philips and Lahey > book.) > It is not valid code. The variable i is being used without it being set to some value, ie., i is undefined.
Created attachment 13507 [details] Revised acmod.f90
Created attachment 13508 [details] Revised nnh.f90
(In reply to comment #5) > (In reply to comment #4) > > (I guess I should qualify that. I don't have a copy of the standard laying > > around to check, but it's legal according to the Ellis, Philips and Lahey > > book.) > > > > It is not valid code. The variable i is being used without it being set > to some value, ie., i is undefined. Well, obviously. Also obviously in the code in which I discovered the bug the dimensioning variable was set. Attached are revised codes that are 100% legal, give no warnings or errors with either g95 or ifort, pass Lahey's online standards conformance test and still produce the ICE with gfortran 4.2. Interestingly, if i is defined in nnh.f90 before the call to f the ICE goes away. Thus, while it may not effect the WONTFIX, I'm changing the keyword to ice-on-valid-code. (OK, that's the end of my "I know Fortran!" rant! ;-)