[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #14 from burnus at gcc dot gnu dot org 2007-12-11 23:15 --- As I understand the F2003 standard, the expression INT(z'ff',1) should produce a range error, for the same reasons as the data statement illustrated in: http://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-constants.html In practice, I don't think any compilers do this (yet). Well, I am not sure whether the compiler is required to do so; with some BOZ work, I disabled accidentally some range checks (see PR 34398), but your INT gives an error with gfortran: print *, INT(z'ff',1) 1 Error: Result of INT overflows its kind at (1) (Note: the value 1 is a (common) implementation choice; not every compiler has kind = byte size.) Maybe there should be a -f[no-]boz-range-check to exclude range errors just for the BOZ case. I think -fno-range-check should be enough for both, shouldn't it? F2008 draft, it re-defines B/O/Z literals, named BITS instead of BOZ. That part got dropped, see 13 August at: http://www.nag.co.uk/sc22wg5/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #15 from jkrahn at nc dot rr dot com 2007-12-12 01:04 --- Subject: Re: Warn with -std=f95/f2003 when BOZ is used at invalid places burnus at gcc dot gnu dot org wrote: ... Maybe there should be a -f[no-]boz-range-check to exclude range errors just for the BOZ case. I think -fno-range-check should be enough for both, shouldn't it? My feeling is that BOZ range errors will occur often due to a poorly designed spec, but that other range errors may really be bugs. Alternatively, it might be good to a define BOZ mode flag, especially since gfortran already supports a non-standard extension, and because the vague standard means that there will be differences among compilers. F2008 draft, it re-defines B/O/Z literals, named BITS instead of BOZ. That part got dropped, see 13 August at: http://www.nag.co.uk/sc22wg5/ Well, I hope that they at least update the BOZ specification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #10 from burnus at gcc dot gnu dot org 2007-12-08 21:47 --- Subject: Bug 29471 Author: burnus Date: Sat Dec 8 21:46:56 2007 New Revision: 130713 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130713 Log: 2007-12-08 Tobias Burnus [EMAIL PROTECTED] PR fortran/34342 PR fortran/34345 PR fortran/18026 PR fortran/29471 * gfortran.texi (BOZ literal constants): Improve documentation and adapt for BOZ changes. * Make-lang.ini (resolve.o): Add target-memory.h dependency. * gfortran.h (gfc_expr): Add is_boz flag. * expr.c: Include target-memory.h. (gfc_check_assign): Support transferring BOZ for real/cmlx. * resolve.c: Include target-memory.h (resolve_ordinary_assign): Support transferring BOZ for real/cmlx. * target-memory.c (gfc_convert_boz): New function. * target-memory.c (gfc_convert_boz): Add prototype. * primary.c (match_boz_constant): Set is_boz, enable F95 error also without -pedantic, and allow for Fortran 2003 BOZ. (match_real_constant): Fix comment. * simplify.c * (simplify_cmplx,gfc_simplify_dble,gfc_simplify_float, gfc_simplify_real): Support Fortran 2003 BOZ. 2007-12-08 Tobias Burnus [EMAIL PROTECTED] PR fortran/34342 PR fortran/34345 PR fortran/18026 PR fortran/29471 * gfortran.dg/boz_8.f90: New. * gfortran.dg/boz_9.f90: New. * gfortran.dg/boz_10.f90: New. * gfortran.dg/boz_7.f90: Update dg-warning. * gfortran.dg/pr16433.f: Add dg-error. * gfortan.dg/ibits.f90: Update dg-warning. * gfortran.dg/unf_io_convert_1.f90: Update/delete dg-warning. * gfortran.dg/unf_io_convert_2.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/boz_10.f90 trunk/gcc/testsuite/gfortran.dg/boz_8.f90 trunk/gcc/testsuite/gfortran.dg/boz_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/Make-lang.in trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/boz_7.f90 trunk/gcc/testsuite/gfortran.dg/ibits.f90 trunk/gcc/testsuite/gfortran.dg/pr16433.f trunk/gcc/testsuite/gfortran.dg/unf_io_convert_1.f90 trunk/gcc/testsuite/gfortran.dg/unf_io_convert_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #11 from burnus at gcc dot gnu dot org 2007-12-08 22:08 --- FIXED on the trunk (4.3.0). Fortran 95: Only in DATA and only integer Fortran 2003: Only in DATA or as argument of INT, REAL, DBLE, CMPLX Fortran 2003 BOZ are now properly supported. For -std=f95 full diagnostics exist, however, for -std=f2003 gfortran allows BOZ also at invalid places, see PR 34392. For the supported BOZ extensions, see also: http://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-constants.html (Wait a day until that page is up to date.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #12 from burnus at gcc dot gnu dot org 2007-12-08 22:09 --- Mark really as FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-12 20:10:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #9 from burnus at gcc dot gnu dot org 2007-03-16 09:45 --- The current problem is shown in this bit of code: write(*,*)'NaN(8)=',real(z'FFF8',8) end Note: gfortran does not support Fortran 2003 BOZ yet. gfortran, even with -std=f2003, claims that the BOZ data is too big. Use -fno-range-check to disable this checking. But this will still the old BOZ extension and not the Fortran 2003 BOZ. Even without the reinterpret cast problem, integer BOZ is not handled correctly. This expression also claims the BOZ is too large: int(z'',8) The number is does not fit into -huge(1_8) ... huge(1_8) and is therefore outside of the Fortran standard. - -fno-range-check The traditional behavior is for all BOZ to be initially interpreted as the largets integer type supported. Which is why gfortran gives no error if you use int(BOZ, kind=16). 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. Processor dependent in the Fortran language does not only mean the CPU but also the compiler; nonetheless, in this regard most (all?) compilers produce the same result on a given platform. 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.) The standard does not say anything about non-Fortran numbers. Fortran 2003 has now support of the IEEE arithmetics, which allows NaN, denormalized numbers and +/-INF, overflowing etc. Thus for a Fortran 95 compiler, the 0./0. can always be rejected, whereas for Fortran 2003 it is a bit unclearer (cf. below for a standard way to get Nan). my personal trick is to use: real :: r, NaN r = 0.0 NaN = 0.0/r which does the NaN at run time. (You still need to have the right compiler flags as otherwise you get an arithmetic exception at run time.) But, good news, I just discovered that this hack works: NaN = transfer(ishft(int(z'FFF8',8),32),0.0_8) I tried that a while back with gfortran and it crashed. A modified version still crashes with gfortran: real(kind(0d0)) :: NaN = transfer(ishft(int(z'FFF8',8),32),0d0) print *, NaN Interestingly, this produces 0.0 with ifort, while g95 and sunf95 give NaN. See PR 31194. What we really need is a NAN(kind=8) intrinsic. Well, one can do in Fortran 2003: use,intrinsic :: ieee_arithmetic real :: NaN NaN = ieee_value(x,ieee_quiet_nan) (Note: IEEE arithmetic is not yet supported by many compilers, especially gfortran does not support it yet.) (In reply to comment #6) My vote is to just ignore the standards when it comes to negative BOZ, the way Intel has done it, which I HOPE is what F2008 says. Sorry, I think most people would like to have a standard conform compiler; we cannot do so. Besides IEEE arithmetic allows what you want. Using transfer is a non-portable way to do so, which assumes a certain internal structure. And using your integer BOZ are supported with -fno-range-check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- 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'FFF8',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'',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'FFF8',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
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #6 from jkrahn at nc dot rr dot com 2007-03-16 03:53 --- One more comment: I just checked the INT() intrisic for F2003. It actually still states that a BOZ is initially interpreted as the largest integer type (ugh!) REAL() has the correct definition of interpreting as the target REAL kind. I have to assume that they think a LARGE integer will hold all BOZ values, and can simply be down-cast. Could they actually have forgotten about negative values?!? I have not checked F2008 yet. My vote is to just ignore the standards when it comes to negative BOZ, the way Intel has done it, which I HOPE is what F2008 says. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- 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 -, 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'FFF8',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'',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
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2007-03-16 04:09 --- Subject: Re: Warn with -std=f95/f2003 when BOZ is used at invalid places On Fri, Mar 16, 2007 at 03:53:57AM -, jkrahn at nc dot rr dot com wrote: I have not checked F2008 yet. My vote is to just ignore the standards when it comes to negative BOZ, the way Intel has done it, which I HOPE is what F2008 says. gfortran doesn't have that luxury. it can't ignore the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-16 13:34 --- Note that there is a change in meaning: BOZ-everywhere extension: a = real(z'F') is the same as real(int(z'F')) = 15.0 (This is what gfortran does and Intel does by default) Fortran 2003: a = real(z'F') = 2.1019477E-44 Intel gives a default warning in such cases: fortcom: Warning: boz2.f90, line 2: The Fortran 2003 Standard will use this bit pattern directly and NOT convert it to REAL as if it were an INTEGER constant (try -switch fe_new_BOZ_constants). a = real(z'F') ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #2 from kargl at gcc dot gnu dot org 2006-10-16 16:51 --- This is going to be difficult to fix. In fact, it will require a complete rewrite on how BOZ are handled. Fortran 2003: a = real(z'F') = 2.1019477E-44 Are you sure this is the only correct value? The F2003 says nothing about the other 28 bits. It also says nothing about whether z'F' applies to most significant bits or least significant bits of the 32-bit real. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-10-16 17:12 --- (In reply to comment #2) Fortran 2003: a = real(z'F') = 2.1019477E-44 Are you sure this is the only correct value? The F2003 says nothing about the other 28 bits. It also says nothing about whether z'F' applies to most significant bits or least significant bits of the 32-bit real. Well, that is the value ifort gave me (using -switch fe_new_BOZ_constants); I think it is a valid value, but I'm not sure whether it is the only one. As NAG f95, g95 and sunf95 do not yet support F2003's BOZ, I cannot compare with what they give. I also found the F2003 standard not so detailed, but maybe I missed the right spot. Best to ask at comp.lang.fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-16 17:23 --- Forgot to add myself to cc listing. Tobias, the only place the handling on a BOZ (other the data-stmt handling) is discussed in the description REAL() intrinsic procedure. It contains the dreaded processor-dependent language. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
