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

["kargl at gcc dot gnu dot org" <gcc-bugzilla 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