SUBROUTINE SPFFT1(IMAX) IMPLICIT NONE INTEGER,INTENT(IN):: IMAX REAL:: AUX1(25000+INT(0.82*IMAX)) END SUBROUTINE using precompiled linux gfortran snapshot of 20041102, this gives: # gfc -v -c gaga.f Reading specs from /usr/local/gfortran/irun/bin/../lib/gcc/i686-pc-linux-gnu/4. 0.0/specs Configured with: ../gcc/configure --enable-languages=c,f95 --prefix=/usr/work/2004307/irun Thread model: posix gcc version 4.0.0 20041102 (experimental) /usr/local/gfortran/irun/bin/../libexec/gcc/i686-pc-linux-gnu/4.0.0/f951 gaga.f -ffixed-form -quiet -dumpbase gaga.f -mtune=pentiumpro -auxbase gaga -version -o /tmp/ccM6P9Ip.s GNU F95 version 4.0.0 20041102 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.0 20041020 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 gaga.f:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Confirmed, here is the backtrace: #0 0x000169f4 in check_inquiry (e=0x42103d20) at /Users/pinskia/src/local/gcc/gcc/fortran/expr.c: 1334 #1 0x00017038 in check_restricted (e=0x5a7aa4) at /Users/pinskia/src/local/gcc/gcc/fortran/expr.c: 1593 #2 0x00017038 in check_restricted (e=0x5a7aa4) at /Users/pinskia/src/local/gcc/gcc/fortran/expr.c: 1593 #3 0x000167d8 in check_intrinsic_op (e=0x5a7aa4, check_function=0x4459d8 <error_message+11340>) at /Users/pinskia/src/local/gcc/gcc/fortran/expr.c:1236 #4 0x00016f64 in check_restricted (e=0x5a7aa4) at /Users/pinskia/src/local/gcc/gcc/fortran/expr.c: 1616 #5 0x000170c4 in restricted_args (a=0x5a7aa4) at /Users/pinskia/src/local/gcc/gcc/fortran/expr.c: 1534 #6 0x000167d8 in check_intrinsic_op (e=0x5a7aa4, check_function=0x4459d8 <error_message+11340>) at /Users/pinskia/src/local/gcc/gcc/fortran/expr.c:1236 #7 0x00016f64 in check_restricted (e=0x5a7aa4) at /Users/pinskia/src/local/gcc/gcc/fortran/expr.c: 1616 #8 0x00006318 in resolve_array_bound (e=0x5a7aa4, check_constant=4479448) at /Users/pinskia/ src/local/gcc/gcc/fortran/array.c:219 #9 0x000063f0 in gfc_resolve_array_spec (as=0x42103d20, check_constant=0) at /Users/pinskia/src/ local/gcc/gcc/fortran/array.c:253 #10 0x0003c6b8 in resolve_symbol (sym=0x5a7aa4) at /Users/pinskia/src/local/gcc/gcc/fortran/ resolve.c:4077 #11 0x000482ec in traverse_ns (st=0x421041e0, func=0x3c5b8 <resolve_symbol>) at /Users/ pinskia/src/local/gcc/gcc/fortran/symbol.c:2297 #12 0x00048308 in traverse_ns (st=0x421041e0, func=0x3c5b8 <resolve_symbol>) at /Users/ pinskia/src/local/gcc/gcc/fortran/symbol.c:2300 #13 0x0003c168 in gfc_resolve (ns=0x42103d20) at /Users/pinskia/src/local/gcc/gcc/fortran/ resolve.c:4649 #14 0x00033ec8 in gfc_parse_file () at /Users/pinskia/src/local/gcc/gcc/fortran/parse.c:2612 #15 0x0004aa60 in gfc_be_parse_file (set_yydebug=1108360480) at /Users/pinskia/src/local/gcc/ gcc/fortran/f95-lang.c:266 #16 0x003356ac in toplev_main (argc=247224, argv=0x421041e0) at /Users/pinskia/src/local/gcc/ gcc/toplev.c:986
This is invalid code, INT is not allowed in a specification expression.
The problem is that we insert a function call to convert IMAX to default real, and check_inquiry does not support these conversion functions.
Subject: Re: ICE with computed array declaration This example is from the software copygb (ftp://ftpprd.ncep.noaa.gov/pub/cpc/wd51we/copygb) which was ported from generic Fortran95 to g95, and thus compiles perfectly with g95, but not with gfortran. > > ------- Additional Comments From tobi at gcc dot gnu dot org 2004-12-09 > 00:22 ------- > This is invalid code, INT is not allowed in a specification expression. > > -- > What |Removed |Added > ---------------------------------------------------------------------------- > Keywords|ice-on-valid-code |ice-on-invalid-code > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18271 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. >
1) There is an easy way to circumvent the ICE: if you add an explicit type conversion for IMAX, such as in REAL:: AUX1(25000+INT(0.82*float(IMAX))) the ICE goes away and gfortran compiles it successfully and without warnings, even with "-std=f95". 2) WRT invalid code: I checked the code with the Lahey Source Check, ifort, SUN f95 and g95: --> Lahey/Fujitsu Fortran 95 (lf95): no errors, no warnings --> Lahey Fortran 90 (lf90): error at INT expression Line 5, file SOURCE.F90 REAL:: AUX1(25000+INT(0.82*IMAX)) | FATAL -- Specification expression required. --> Intel ifort 8.1: no errors, no warnings with "-warn all -stand f90" --> SUN Workshop f95 6.2: no errors, no warnings with "-w4" --> g95: no errors, no warnings with "-std=f95"
(In reply to comment #2) > This is invalid code, INT is not allowed in a specification expression. I'm not a language lawyer, but if I read it correctly, then INT is a standard intrinsic function and thus allowed in a restricted expression (F2003 draft standard, 7.1.6, R729, C710 (8)) Am I missing something?
we no longer ICE on this code but we still accept it.
(In reply to comment #6) > I'm not a language lawyer, but if I read it correctly, then > INT is a standard intrinsic function and thus allowed in a > restricted expression (F2003 draft standard, 7.1.6, R729, C710 (8)) > Am I missing something? I've just sent a question to comp.lang.fortran. We'll see what the experts have to say.
It appears that the original testcase, involving INT in as specification expression, is valid F95 and F2003. It was not valid F90, however, because the return type of INT is real. This is confirmed by the results of different compilers and Bob Corbett on c.l.f, so I'm closing this one as INVALID.
(In reply to comment #9) > It appears that the original testcase, involving INT in as specification > expression, is valid F95 and F2003. It was not valid F90, however, because the > return type of INT is real. This is confirmed by the results of different > compilers and Bob Corbett on c.l.f, so I'm closing this one as INVALID. FX, I do not understand why you are closing this one as INVALID, since you just argued that it VALID F95 and F2003. Anyway, current gfortran seems to accept this code, so this issue appears resolved. Please do not break it! ;-)
(In reply to comment #10) > I do not understand why you are closing this one as INVALID, > since you just argued that it VALID F95 and F2003. I'm saying that the bug report, which says "This illegal code is wrongly accepted by gfortran", is INVALID, because the code is indeed legal. > Please do not break it! ;-) I'll be adding this bit of code to the testsuite.
Subject: Bug 18271 Author: fxcoudert Date: Mon May 8 09:59:09 2006 New Revision: 113627 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113627 Log: PR libfortran/18271 * gfortran.dg/spec_expr_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/spec_expr_3.f90 Modified: trunk/gcc/testsuite/ChangeLog
Subject: Bug 18271 Author: fxcoudert Date: Mon May 8 10:03:11 2006 New Revision: 113628 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113628 Log: PR libfortran/18271 * gfortran.dg/spec_expr_3.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/spec_expr_3.f90 - copied unchanged from r113627, trunk/gcc/testsuite/gfortran.dg/spec_expr_3.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog