[Bug fortran/54633] ICEs and reject valid with MINLOC/MINVAL (MAXLOC/MAXVAL) due to lacking compile-time simplification

burnus at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Sep 20 09:01:00 GMT 2012


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54633

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|diagnostic, wrong-code      |rejects-valid
                 CC|                            |burnus at gcc dot gnu.org
             Blocks|                            |54613
            Summary|Issues with MINLOC/MINVAL   |ICEs and reject valid with
                   |(MAXLOC/MAXVAL)             |MINLOC/MINVAL
                   |                            |(MAXLOC/MAXVAL) due to
                   |                            |lacking compile-time
                   |                            |simplification

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-20 09:00:45 UTC ---
See also related: pr25104 and pr45689 - and PR54613.

I forgot to quote the output of the different compilers:

minloc1.f90 REJECTED REJECTED REJECTED  REJECTED REJECTED
minloc2.f90      ICE        1      ICE 538976289        1
minval1.f90 REJECTED REJECTED REJECTED  REJECTED REJECTED
minval2.f90      ICE   ACCVIO      ICE         1        1
minval3.f90  17.0, 4 REJECTED REJECTED  REJECTED REJECTED
minval4.f90        2   ACCVIO      ICE         1        1


mincloc1, minval1 and minval3 are invalid Fortran 95 but valid Fortran 2003.
gfortran's result for minval3 is correct - the rejects are due to due to a
lacking simplify.

min*2.f90: Those are interesting, the program is valid Fortran 95 and valid
Fortran 2003, but the result is different. In Fortran 95 the expected result is
1, in Fortran 2003 the expected result is 2. (See below.)
Again, gfortran lacks a simplification - or a guard to catch (and reject) the
programs where the simplify is lacking.

  * * *

Looking at Fortran 95's "7.1.6.1 Constant expression", {min,max}{loc,val}
aren't constant expressions; nor are they "initialization expressions".

Looking at Fortran 2003's "7.1.7 Initialization expression", they are:

"(5) A reference to a transformational standard intrinsic function other than
     NULL, where each argument is an initialization expression,"
as {min,max}{loc,val} are in the "Class. Transformational function."

  * * *

Regarding the SAVE:

F95 has in "5.2.4 SAVE statement":
"A SAVE statement without a saved entity list is treated as though it contained
the names of all allowed items in the same scoping unit."

As with -std=f95, automatic variables don't have the SAVE attribute, as MINLOC
is not an initialization expression, "x" is not SAVE. With -std=f2003, MINLOC
is an initialization expression ...

Fortran 2003 contains the same:
"A SAVE statement without a saved entity list is treated as though it contained
the names of all allowed items in the same scoping unit."


Thus, in Fortran 2003, SAVE doesn't apply to "X", in Fortran 95 it does.


As Bob Covert points out, that's a known problem:

"1.6.4 Fortran 90 compatibility"

"The following Fortran 90 features have di
erent interpretations in this part
of ISO/IEC 1539:" [...]
"* whether an expression is a constant expression (thus whether a variable is
considered to be automatic)."


The question is whether we want to do something about or not.



More information about the Gcc-bugs mailing list