[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places

["sgk at troutmask dot apl dot washington dot edu" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #7 from sgk at troutmask dot apl dot washington dot edu  2007-03-16 04:07 -------
Subject: Re:  Warn with -std=f95/f2003 when BOZ is used at invalid places

On Fri, Mar 16, 2007 at 03:46:30AM -0000, jkrahn at nc dot rr dot com wrote:
> 
> 
> ------- Comment #5 from jkrahn at nc dot rr dot com  2007-03-16 03:46 -------
> BOZ processing was recently broken in gfortran.

No, it was fixed.

> I assume it relates to the issues here.
> 
> The current problem is shown in this bit of code:
> 
>   write(*,*)'NaN(8)=',real(z'FFF8000000000000',8)
>   end
> 
> gfortran, even with -std=f2003, claims that the BOZ data is too big.

Do you have an INTEGER(16)?

> Apparently, it is first converting to an UNSIGNED integer, then trying to cast
> to a SIGNED Fortran integer.

Not even close to the truth.

> With F2003, this form of BOZ should do a
> 'reinterpret-cast' of raw binary bits directly to the destination type.

gfortran implements the F95 behavior and extensions.  The extension
conflict with F2003.

> Even without the reinterpret cast problem, integer BOZ is not handled
> correctly. This expression also claims the BOZ is too large:
>    int(z'FFFFFFFFFFFFFFFF',8)

Do you have INTEGER(16)?

> Again, it is being intepreted as an UNSIGNED int then static-cast to a signed
> in, thus overflowing.


Not even close to the truth.

> The traditional behavior is for all BOZ to be initially interpreted as the
> largets integer type supported.

Do you have an INTEGER(16)?

> F95 dropped BOZ because of the lame definition

Huh?

> but F2003 brought it back for use mainly within REAL() and INT(),
> which allow the raw initial interpretation in a sensible way.

No, it isn't sensible.  It is *processor dependent*.  Think big
versus little endian to start.  Next consider that F2003 does not
define the underlying floating representation.  This was a very
broken attempt to fix TRANSFER.

> A related problem is that I am trying to create a NaN constant (parameter). I
> can't use REAL+BOZ, but I also cannot define "real :: NaN = 0.0/0.0". In this
> case, divide-by-zero is invalid math, but should only be a warning and not an
> error. (I am speaking practically; I don't know what the standards say.)

program rtfm
x = 0. / 0.
end program rtfm

gfc -fno-range-check -o z rtfm.f90


-- 


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