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

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

[tobias dot burnus at physik dot fu-berlin dot de]

gfortran allows everywhere to use a BOZ.

However, there are constrains in Fortran 95 and 2003 on where to use them.

- Fortran 95: Only in DATA and only integer
- Fortran 2003: Only in DATA or as argument of INT, REAL, DBLE, CMPLX

Expected: An ERROR (or WARNING) is shown, when -std=f95/f2003 is used.

Fortran 95:
"R407 boz-literal-constant [...]
Constraint: A boz-literal-constant may appear only in a DATA statement.[...]
If a data-statement-constant is a boz-literal-constant, the corresponding
object shall be of type integer."

Fortran 2003:
"C410 (R411) A boz-literal-constant shall appear only as a data-stmt-constant
in a DATA statement, as the actual argument associated with the dummy argument
A of the numeric intrinsic functions DBLE, REAL or INT, or as the actual
argument associated with the X or Y dummy argument of the intrinsic function
CMPLX."


-- 
           Summary: Warn with -std=f95/f2003 when BOZ is used at invalid
                    places
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tobias dot burnus at physik dot fu-berlin dot de


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

[tobias dot burnus at physik dot fu-berlin dot de]

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

[kargl at gcc dot gnu dot org]

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

[tobias dot burnus at physik dot fu-berlin dot de]

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

[kargl at gcc dot gnu dot org]

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

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

[jkrahn at nc dot rr dot com]

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

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

[jkrahn at nc dot rr dot com]

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

[sgk at troutmask dot apl dot washington dot edu]

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

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

[sgk at troutmask dot apl dot washington dot edu]

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

[burnus at gcc dot gnu dot org]

------- 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'FFF8000000000000',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'FFFFFFFFFFFFFFFF',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'FFF80000',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'FFF80000',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

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-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

[burnus at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=130713
Log:
2007-12-08  Tobias Burnus  <burnus@net-b.de>

        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  <burnus@net-b.de>

        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

[burnus at gcc dot gnu dot org]

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

[burnus at gcc dot gnu dot org]

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

[jkrahn at nc dot rr dot com]

------- Comment #13 from jkrahn at nc dot rr dot com  2007-12-11 19:40 -------
My previous post here was a bit confused by differences in F95 and F2003, and
my misunderstanding of Gfortran's BOZ extension.

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

I thought that F2003 allowed this type of BOZ usage because the KIND was well
defined, because the F2003 (draft) standard gives the rule for interpretation
as the largest integer kind with DATA statements, but not under REAL(), DBLE(),
or CMPLX(). However, I just checked again and found that INT() does require the
initial interpretation as the largest integer kind. Unless the final standard
differs, it appears that interpretation of BOZ for REAL(), etc., are completely
undefined. As far as I can tell, it would be equally valid to interpret a hex
value as a binary real value, or just to convert as with integer assignment.

Due to being ill-defined, I suggested ignoring the standard. Instead, the right
suggestion is an extension which modifies the standard. Maybe there should be a
"-f[no-]boz-range-check" to exclude range errors just for the BOZ case. Also,
to avoid misleading users into thinking that F2003 BOZ are well-defined, it
might be good to warn about any BOZ usage, maybe as part of "-Wsurprising".

F2008 draft, it re-defines B/O/Z literals, named BITS instead of BOZ. It seems
to be an improvement, but will probably add to the difficulty of supporting
multiple standards. 


-- 


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

[burnus at gcc dot gnu dot org]

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

[jkrahn at nc dot rr dot com]

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