public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jkrahn at nc dot rr dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places Date: Fri, 16 Mar 2007 03:46:00 -0000 [thread overview] Message-ID: <20070316034630.32721.qmail@sourceware.org> (raw) In-Reply-To: <bug-29471-1719@http.gcc.gnu.org/bugzilla/> ------- Comment #5 from jkrahn at nc dot rr dot com 2007-03-16 03:46 ------- BOZ processing was recently broken in gfortran. 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. Apparently, it is first converting to an UNSIGNED integer, then trying to cast to a SIGNED Fortran integer. With F2003, this form of BOZ should do a 'reinterpret-cast' of raw binary bits directly to the destination type. 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) Again, it is being intepreted as an UNSIGNED int then static-cast to a signed in, thus overflowing. The traditional behavior is for all BOZ to be initially interpreted as the largets integer type supported. As usual with Fortran, that is a horrible definition. In order to define a -1 BYTE, you have to write out the whole 8-bytes worth of FF. Intel seems to use a sane (but nonstandard) method that appears to interpret initially as the smallest type that contains all of the bits specified. F95 dropped BOZ because of the lame definition, but F2003 brought it back for use mainly within REAL() and INT(), which allow the raw initial interpretation in a sensible way. The only hassle with "processor dependent" definitions is that the result of a given binary value depends on a processor's internal binary format. So, IEEE floats are portable, but other long/quad real numbers are not. In any case, it comes down to a raw binary value converted directly to the destination for the F2003 forms. For the older form, which is still the case in F2003 for DATA statements, it is hard to know whether to 'cheat' and allow z'FF' to define a -1 byte, or stick to the strict messed-up definition. What did G77 do? 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.) But, good news, I just discovered that this hack works: NaN = transfer(ishft(int(z'FFF80000',8),32),0.0_8) I tried that a while back with gfortran and it crashed. What we really need is a NAN(kind=8) intrinsic. -- jkrahn at nc dot rr dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jkrahn at nc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
next prev parent reply other threads:[~2007-03-16 3:46 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-10-14 19:20 [Bug fortran/29471] New: " tobias dot burnus at physik dot fu-berlin dot de 2006-10-16 13:34 ` [Bug fortran/29471] " tobias dot burnus at physik dot fu-berlin dot de 2006-10-16 16:51 ` kargl at gcc dot gnu dot org 2006-10-16 17:12 ` tobias dot burnus at physik dot fu-berlin dot de 2006-10-16 17:23 ` kargl at gcc dot gnu dot org 2007-03-16 3:46 ` jkrahn at nc dot rr dot com [this message] 2007-03-16 3:54 ` jkrahn at nc dot rr dot com 2007-03-16 4:07 ` sgk at troutmask dot apl dot washington dot edu 2007-03-16 4:09 ` sgk at troutmask dot apl dot washington dot edu 2007-03-16 9:45 ` burnus at gcc dot gnu dot org 2007-08-12 20:10 ` fxcoudert at gcc dot gnu dot org 2007-12-08 21:47 ` burnus at gcc dot gnu dot org 2007-12-08 22:08 ` burnus at gcc dot gnu dot org 2007-12-08 22:10 ` burnus at gcc dot gnu dot org 2007-12-11 19:40 ` jkrahn at nc dot rr dot com 2007-12-11 23:15 ` burnus at gcc dot gnu dot org 2007-12-12 1:04 ` jkrahn at nc dot rr dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20070316034630.32721.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).