[Bug fortran/38822] New: ICE in in gfc_target_encode_expr

[Bug fortran/38822] New: ICE in in gfc_target_encode_expr

[burnus at gcc dot gnu dot org]

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2

(There is another issue with constant folding, which Steve wants to fix.)

The following program compiles with NAG f95/g95/ifort and prints "T F". With
gfortran 4.3 and 4.4 it crashes (with 4.1/4.2 it does not compile):

f951: internal compiler error: in gfc_target_encode_expr, at
fortran/target-memory.c:249

  gcc_assert (source->expr_type == EXPR_CONSTANT
              || source->expr_type == EXPR_STRUCTURE
              || source->expr_type == EXPR_SUBSTRING);

Here, source->expr_type == EXPR_OP.

Reduced testcase:
   integer z(0*transfer(2.D0**2.,1)+2)
   end

Long testcase, see
http://groups.google.com/group/comp.lang.fortran/msg/c71f697c3e21e3f2


-- 
           Summary: ICE in in gfc_target_encode_expr
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2009-01-13 16:33 -------
The problem is the following in arith.c:
  if (op == INTRINSIC_POWER && op2->ts.type != BT_INTEGER)
    goto runtime;

Thus it is only run-time evaluated. gfc_arith_power deals so far only with
(numeric_type)**(integer). We need to handle (complex)**(complex)
and (real)**(real).

I think Fortran 2003 allows ** in initialization expressions (at least I could
not find anything else) and thus one needs this. See also PR 38823.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE in in                   |Compile-time simplification
                   |gfc_target_encode_expr      |of x**(real)  /  ICE in in
                   |                            |gfc_target_encode_expr


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2009-01-14 15:30 -------
Before closing, please also check the two longer cases:
http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9
and the older (partially incorrect?) one at
http://groups.google.com/group/comp.lang.fortran/msg/c71f697c3e21e3f2


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2009-01-16 00:55 -------
(In reply to comment #2)
> Before closing, please also check the two longer cases:
> http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9
> and the older (partially incorrect?) one at
> http://groups.google.com/group/comp.lang.fortran/msg/c71f697c3e21e3f2
> 

Well, both programs compile with my patch that allows
2.e0**2.e0 to compile.

troutmask:sgk[220] gfc4x -o z j2.f90
troutmask:sgk[221] ./z
 T T
troutmask:sgk[222] gfc4x -o z -std=f95 j1.f90
troutmask:sgk[223] ./z
 T T

I haven't unraveled James' argument that the correct
answer is T F.


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2009-01-16 02:47 -------
I think I know how to fix this.  I'll note that James' clever
programs may be invoking processor defined behavior due to
the multiplication by 0 in his specification statements.
See 7.1.8.1.


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[jvdelisle at gcc dot gnu dot org]

------- Comment #5 from jvdelisle at gcc dot gnu dot org  2009-01-16 02:57 -------
ifort (IFORT) 10.1 20080801
Copyright (C) 1985-2008 Intel Corporation.  All rights reserved.

$ ./a.out 
 T F

I want to get my head around this too. :)


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[kargl at gcc dot gnu dot org]

------- Comment #6 from kargl at gcc dot gnu dot org  2009-01-16 05:26 -------
(In reply to comment #5)
> ifort (IFORT) 10.1 20080801
> Copyright (C) 1985-2008 Intel Corporation.  All rights reserved.
> 
> $ ./a.out 
>  T F
> 
> I want to get my head around this too. :)

Note, there are 2 separate programs.  Both should
give 'T F' according to James.  He had a bug in the
first program that gives the 'correct' answer with
several compilers.  His corrected program shows that
Intel gets the wrong answer 'T T'.

The gist of his argument is that in F95 a REAL exponent
is not permitted in an initialization expression.  This 
then means that the array 'z(0*transfer(2.d0**2.)+2)'
is an automatic array.  An automatic array is not saved
with a blank SAVE statement, and so it can't retain its
values when the routine returns.

There may be some processor-dependent behavior here.  A
Fortran processor does not have to evaluate the transfer()
and its arguments because the multiplication by 0 will 
always result in zero.  See 7.1.8.1.


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[kargl at gcc dot gnu dot org]

------- Comment #7 from kargl at gcc dot gnu dot org  2009-01-20 19:22 -------
I have a patch that not only fixes the ICE, but it will issue an
error for a program of the form

troutmask:sgk[203] cat a.f90
program a
  real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
  z = 1.
  print '(5ES12.5)', z
end program a
troutmask:sgk[204] gfc4x -o z a.f90
troutmask:sgk[205] ./z
 1.00000E+00 1.00000E+00 1.00000E+00 1.00000E+00 1.00000E+00
troutmask:sgk[206] gfc4x -o z -std=f95 a.f90
a.f90:2.32:

  real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
                                1
Error: Fortran 2003: Noninteger exponent in an initialization expression at (1)

Note, I plan to change the word initialization to restricted.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |kargl at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
           Priority|P3                          |P4
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-20 19:22:29
               date|                            |


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[kargl at gcc dot gnu dot org]

------- Comment #8 from kargl at gcc dot gnu dot org  2009-01-20 19:41 -------
(In reply to comment #7)
> I have a patch that not only fixes the ICE, but it will issue an
> error for a program of the form
> 
> troutmask:sgk[203] cat a.f90
> program a
>   real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
>   z = 1.
>   print '(5ES12.5)', z
> end program a
> troutmask:sgk[204] gfc4x -o z a.f90
> troutmask:sgk[205] ./z
>  1.00000E+00 1.00000E+00 1.00000E+00 1.00000E+00 1.00000E+00
> troutmask:sgk[206] gfc4x -o z -std=f95 a.f90
> a.f90:2.32:
> 
>   real z(int(transfer(2.e0**2.e0, 1.e0)) + 1)
>                                 1
> Error: Fortran 2003: Noninteger exponent in an initialization expression at (1)
> 
> Note, I plan to change the word initialization to restricted.
>

Dang, I got this wrong.  There is a distinction between an initialization
and specification expressions where a non-integer exponent is indeed allowed
in the latter and prohibited in the former.  I, at least, still have the
ICE fixed.


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr

[kargl at gcc dot gnu dot org]

------- Comment #9 from kargl at gcc dot gnu dot org  2009-03-29 20:41 -------
The ICE is fixed by revision 145261.


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[kargl at gcc dot gnu dot org]

------- Comment #10 from kargl at gcc dot gnu dot org  2009-03-30 00:54 -------
Adjust subject because the ICE is gone.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Compile-time simplification |Compile-time simplification
                   |of x**(real)  /  ICE in in  |of x**(real)
                   |gfc_target_encode_expr      |


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[dominiq at lps dot ens dot fr]

------- Comment #11 from dominiq at lps dot ens dot fr  2009-04-04 09:41 -------
This bug fix has been committed on trunk since almost a week, hence heavily
regtested on various platforms, could it be back-ported to 4.4 before release?
TIA.


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[kargl at gcc dot gnu dot org]

------- Comment #12 from kargl at gcc dot gnu dot org  2009-04-04 15:10 -------
(In reply to comment #11)
> This bug fix has been committed on trunk since almost a week, hence heavily
> regtested on various platforms, could it be back-ported to 4.4 before release?
> TIA.
> 

This bug has not been fixed.  Please see the audit trail especially
comments #2 and #3.

The ICE went away when I fixed a different PR.  That bug fix is not
a candidate for a backport because it changes a key concept in how
the routines in arith.c work.


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[dominiq at lps dot ens dot fr]

------- Comment #13 from dominiq at lps dot ens dot fr  2009-04-04 20:44 -------
At revision 145521, the test from comment #2 returns: "T F" on
(powerpc|i686)-apple-darwin9.

Since I am not really interesting in this way to split hairs, do what ever you
like.


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #14 from sgk at troutmask dot apl dot washington dot edu  2009-04-04 21:42 -------
Subject: Re:  Compile-time simplification of x**(real)

On Sat, Apr 04, 2009 at 08:44:36PM -0000, dominiq at lps dot ens dot fr wrote:
> 
> At revision 145521, the test from comment #2 returns: "T F" on
> (powerpc|i686)-apple-darwin9.
> 
> Since I am not really interesting in this way to split hairs, do what ever you
> like.
> 
> 

There are 2 URL's in comment #2.  Specifically, see

http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9

That code on FreeBSD gives

REMOVE:kargl[128] gfc4x -o z j2.f90
REMOVE:kargl[129] ./z
 T T

The correct answer according to James van Buskirk is T F.

The PR that fixed the ICE is 

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

See the audit trail.  I have no plans to back port this because
it changes the underlying semantics of the design of arith.c.


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[dominiq at lps dot ens dot fr]

------- Comment #15 from dominiq at lps dot ens dot fr  2009-04-05 19:43 -------
> There are 2 URL's in comment #2.

Sorry to be dense, but I overlooked the differences:

<             f = initialization(x-1)            --> gives "T F"
---
>             f = non_initialization(x-1)    --> gives "T T" 

I get the same answers for gfortran, ifort, and g95. If someone has access to
other compilers and can run the test, let see!


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[kargl at gcc dot gnu dot org]

------- Comment #16 from kargl at gcc dot gnu dot org  2010-01-15 18:31 -------
Unassign myself as I have no time to work on gfortran.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|kargl at gcc dot gnu dot org|unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[dfranke at gcc dot gnu dot org]

------- Comment #17 from dfranke at gcc dot gnu dot org  2010-05-19 14:43 -------
No more ICE, removed keyword.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org
             Status|NEW                         |WAITING

--- Comment #22 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #21)
> (In reply to Dominique d'Humieres from comment #19)
> > > AFAICS everthing is fixed here. Can we close this PR?
> > 
> > Without objection I'll proceed.
> 
> Should the bug be fixed before proceeding?  See comment #2 and #3.

With e.g. F2018 (10.1.12 Constant expression) there are no specification
expressions left in the example code, only constant expressions in the
declarations of the z's.

So do we really want to cripple simplification of now constant expressions
to support a restriction to F95?  Might be a nightmare, and there's not
much to be gained either.