[Patch, Fortran] PR fortran/36214: Wrong simplification of BOZ constants

[Tobias Burnus]

Hi Daniel,

Daniel Kraft wrote:
> > Regression testing on GNU/Linux-x86-32 at the moment. 
> > Ok to commit if no failures?
>
> All boz-tests are now passed, however; the rest is still running.

OK when all tests have passed.

> Should we test this on some other systems, too?
> With REAL(KIND=10) vs. REAL(KIND=16)?

I think a test for
 { dg-require-effective-target fortran_large_real }
which works with both kind=10 and kind=16 cannot harm. I don't think
gfortrab will ever regress, but following Murphy's law and given
that fortran_large_real is not so well tested ...

> > Should I backport this to 4.3, too?
> > (If the problem exists there, too, I've not yet tried.) 

I think the
+  gfc_set_model_kind (kind);
is simple enough for GCC 4.3; it probably also affects
TRANSFER(..., 0.0_kind).

Non-integer BOZ (common vendor extension + Fortran 2003 compatible
ones) were introduced rather late in the 4.3 development
(actually: stage3). Thus 4.3 should also be affected.
By the way, a bigger BOZ bug in 4.3 is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36186
(fixed in 4.4; I think it might be too large for a backport).

The vendor extension to allow BOZ everywhere is by the way quite
surprising: Whether a boz is interpreted as int(BOZ) or real(BOZ)
depends on the context - esp. on the type of variable on the LHS.
  i = 4.4 + BOZ
  r = 4 + BOZ
Is the BOZ now a real or an integer bit pattern? (In gfortran:
integer, cf.
http://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-constants.html
(Before the 4.3 patch  "i = BOZ" was also interpreted as integer,
now it is a real(BOZ).)

Tobias