------- 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
