Re: GFortran BOZ-literals incompatible with F2003. Fix?

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Fri, Jan 12, 2007 at 11:43:22AM -0800, Brooks Moses wrote:
> I just came across a spot where our GNU-specific extensions (as 
> documented in version 4.2 and up) for BOZ-literal constants are 
> incompatible with Fortran 2003, and I think we should reconsider this 
> before the 4.2 release.

There is a PR about this.

> 
> Consider this bit of example code:
> 
>     X = REAL(Z'00FF')
> 
> Fortran 95 limits BOZ literals to DATA statements, where they can only 
> be associated with integers, and are interpreted as a representation of 
> an integer constant having the largest kind supported on the system. 
> Thus, under strict F95, that sample is illegal.

Correct.

> Currently, GNU Fortran allows BOZ literals in initialization expressions 
> and assignments, where they are interpreted in the same fashion.  Thus, 
> in the sample code, Z'FF is converted to 255_8, and then transformed to 
> 255.0.

Correct.

> Fortran 2003, however, also extends the allowable places for BOZ 
> literals to include the arguments of DBLE, REAL, INT, or CMPLX.  The INT 
> definition agrees with our usage, but in the case of REAL, DBLE, and 
> CMPLX, the BOZ literal is interpreted as the bit pattern of the 
> representation in memory.  Thus, the sample code will result in X being 
> something quite different, like 3.57331108E-43.

Yep.

> As I mentioned, the first version of GFortran that documents this 
> particular extension is 4.2, which we haven't released yet.  (I think it 
> may also be the first version that implements it, but I'm not sure.)  If 
> we do release it with this extension, we will then have a regression 
> against documented behavior once we implement this bit of F2003.

The F95 behavior dates back to at least 4.1.0.  Documentation
has been a mess for a long time.  When we implement the F2003, we'll
need a -fF2003-boz option or some such, and we'll need to emit
a loud warning.

> The unfortunate thing is that this extension is one that's also a 
> documented part of G77, so we'll get a regression against that in any 
> case.  More unfortunately, a bit of searching at Google Code Search on 
> "lang:fortran Z'[0-9A-Z]" indicates that usage of this particular 
> extension isn't all that rare, either.  So it seems that it would be a 
> bad idea just to revoke support for the extension entirely.
> 
> My thought is that we should probably make this a legacy extension 
> rather than a GNU extension, or otherwise have some means of producing a 
> warning whenever a bare BOZ-literal is used.  Thoughts?  Differing 
> opinions?  Any ideas for how to implement both sanely without weird 
> special-casing?

I looked at this briefly.  First, it needs to be mentioned that when
gfortran parses and recognizes a BOZ constant, it immediately converts
it to an integer.  So, by the time gfortran determines you have
REAL(...), the BOZ has already been converted.

I tried to change gfortran have a BT_BOZ basic type (similar to hollerith).
Then, I added a "char *boz_str" to gfc_symbol.  My plan was to save the
BOZ string in match_boz_constant and delay conversion until needed.  I 
never got it work.

There is also some ambiguity with what to do with REAL(Z'FF').  Is
Z'FF = 0x0000000FF or 0xFF0000000?  What do we do with big vs little
endian?  I'll need to check again, but I believe we need to break
the BOZ in a significand and integer exponent to give the BOZ to
mpfr.  That is, mpfr expects a string of the form "0xACBp4" where
"p4" denotes 16**4.


-- 
Steve