* [Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
@ 2009-01-13 16:33 ` burnus at gcc dot gnu dot org
2009-01-14 15:30 ` burnus at gcc dot gnu dot org
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-01-13 16:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
2009-01-13 16:33 ` [Bug fortran/38822] Compile-time simplification of x**(real) / " burnus at gcc dot gnu dot org
@ 2009-01-14 15:30 ` burnus at gcc dot gnu dot org
2009-01-16 0:55 ` kargl at gcc dot gnu dot org
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-01-14 15:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
2009-01-13 16:33 ` [Bug fortran/38822] Compile-time simplification of x**(real) / " burnus at gcc dot gnu dot org
2009-01-14 15:30 ` burnus at gcc dot gnu dot org
@ 2009-01-16 0:55 ` kargl at gcc dot gnu dot org
2009-01-16 2:47 ` kargl at gcc dot gnu dot org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-01-16 0:55 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (2 preceding siblings ...)
2009-01-16 0:55 ` kargl at gcc dot gnu dot org
@ 2009-01-16 2:47 ` kargl at gcc dot gnu dot org
2009-01-16 2:58 ` jvdelisle at gcc dot gnu dot org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-01-16 2:47 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (3 preceding siblings ...)
2009-01-16 2:47 ` kargl at gcc dot gnu dot org
@ 2009-01-16 2:58 ` jvdelisle at gcc dot gnu dot org
2009-01-16 5:26 ` kargl at gcc dot gnu dot org
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: jvdelisle at gcc dot gnu dot org @ 2009-01-16 2:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (4 preceding siblings ...)
2009-01-16 2:58 ` jvdelisle at gcc dot gnu dot org
@ 2009-01-16 5:26 ` kargl at gcc dot gnu dot org
2009-01-20 19:22 ` kargl at gcc dot gnu dot org
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-01-16 5:26 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (5 preceding siblings ...)
2009-01-16 5:26 ` kargl at gcc dot gnu dot org
@ 2009-01-20 19:22 ` kargl at gcc dot gnu dot org
2009-01-20 19:41 ` kargl at gcc dot gnu dot org
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-01-20 19:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (6 preceding siblings ...)
2009-01-20 19:22 ` kargl at gcc dot gnu dot org
@ 2009-01-20 19:41 ` kargl at gcc dot gnu dot org
2009-03-29 20:41 ` kargl at gcc dot gnu dot org
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-01-20 19:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (7 preceding siblings ...)
2009-01-20 19:41 ` kargl at gcc dot gnu dot org
@ 2009-03-29 20:41 ` kargl at gcc dot gnu dot org
2009-03-30 0:54 ` [Bug fortran/38822] Compile-time simplification of x**(real) kargl at gcc dot gnu dot org
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-03-29 20:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real)
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (8 preceding siblings ...)
2009-03-29 20:41 ` kargl at gcc dot gnu dot org
@ 2009-03-30 0:54 ` kargl at gcc dot gnu dot org
2009-04-04 9:41 ` dominiq at lps dot ens dot fr
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-03-30 0:54 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real)
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (9 preceding siblings ...)
2009-03-30 0:54 ` [Bug fortran/38822] Compile-time simplification of x**(real) kargl at gcc dot gnu dot org
@ 2009-04-04 9:41 ` dominiq at lps dot ens dot fr
2009-04-04 15:10 ` kargl at gcc dot gnu dot org
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-04-04 9:41 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real)
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (10 preceding siblings ...)
2009-04-04 9:41 ` dominiq at lps dot ens dot fr
@ 2009-04-04 15:10 ` kargl at gcc dot gnu dot org
2009-04-04 20:44 ` dominiq at lps dot ens dot fr
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu dot org @ 2009-04-04 15:10 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real)
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (11 preceding siblings ...)
2009-04-04 15:10 ` kargl at gcc dot gnu dot org
@ 2009-04-04 20:44 ` dominiq at lps dot ens dot fr
2009-04-04 21:42 ` sgk at troutmask dot apl dot washington dot edu
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-04-04 20:44 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real)
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (12 preceding siblings ...)
2009-04-04 20:44 ` dominiq at lps dot ens dot fr
@ 2009-04-04 21:42 ` sgk at troutmask dot apl dot washington dot edu
2009-04-05 19:43 ` dominiq at lps dot ens dot fr
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: sgk at troutmask dot apl dot washington dot edu @ 2009-04-04 21:42 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real)
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (13 preceding siblings ...)
2009-04-04 21:42 ` sgk at troutmask dot apl dot washington dot edu
@ 2009-04-05 19:43 ` dominiq at lps dot ens dot fr
2010-01-15 18:31 ` kargl at gcc dot gnu dot org
2010-05-19 14:44 ` dfranke at gcc dot gnu dot org
16 siblings, 0 replies; 18+ messages in thread
From: dominiq at lps dot ens dot fr @ 2009-04-05 19:43 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real)
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (14 preceding siblings ...)
2009-04-05 19:43 ` dominiq at lps dot ens dot fr
@ 2010-01-15 18:31 ` kargl at gcc dot gnu dot org
2010-05-19 14:44 ` dfranke at gcc dot gnu dot org
16 siblings, 0 replies; 18+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-01-15 18:31 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/38822] Compile-time simplification of x**(real)
2009-01-13 10:53 [Bug fortran/38822] New: ICE in in gfc_target_encode_expr burnus at gcc dot gnu dot org
` (15 preceding siblings ...)
2010-01-15 18:31 ` kargl at gcc dot gnu dot org
@ 2010-05-19 14:44 ` dfranke at gcc dot gnu dot org
16 siblings, 0 replies; 18+ messages in thread
From: dfranke at gcc dot gnu dot org @ 2010-05-19 14:44 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 18+ messages in thread