[Bug fortran/58204] New: Spurious error when using BOZ literal to set an integer

[Bug fortran/58204] New: Spurious error when using BOZ literal to set an integer

[quantheory at gmail dot com]

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

            Bug ID: 58204
           Summary: Spurious error when using BOZ literal to set an
                    integer
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: quantheory at gmail dot com

On a x86_64 system, I find that the following program produces two different
compile-time errors:

integer, parameter :: i128 = selected_int_kind(26)
integer(i128), parameter :: foo = int(Z'40000000000000000000000000000000',i128)
integer(i128), parameter :: bar = int(Z'80000000000000000000000000000000',i128)
integer, parameter :: i64 = selected_int_kind(13)
integer(i64), parameter :: foo2 = int(Z'4000000000000000',i64)
integer(i64), parameter :: bar2 = int(Z'8000000000000000',i64)
end


The errors are:

test_boz.F90:3.73:

integer(i128), parameter :: bar = int(Z'80000000000000000000000000000000',i128)
                                                                         1
Error: Integer too big for integer kind 16 at (1)
test_boz.F90:6.38:

integer(i64), parameter :: bar2 = int(Z'8000000000000000',i64)
                                      1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(8) at (1). This
check can be disabled with the option -fno-range-check


The problem seems to be that the BOZ literal is being represented as an
unsigned integer(16), and converting either to a signed value or to a smaller
integer produces an overflow.

In bug 54072, Tobias suggests that this is OK behavior because of this section
from the standard:

"If A is a boz-literal-constant, the value of the result is the value whose bit
sequence according to the model in 13.3 is the same as that of A as modified by
padding or truncation according to 13.3.3. The interpretation of a bit sequence
whose most significant bit is 1 is processor dependent."

I would disagree, and say that gfortran's behavior should be considered a bug,
for three reasons:

1) No truncation or padding is necessary in either of the cases in my example,
and so the bit pattern for "bar" and "bar2" clearly correspond to the bit
patterns for actual numbers that are representable in these types (in this
case, the smallest representable integer).

2) Throwing an error when the most significant bit is 1 is not in any
meaningful sense an "interpretation" of the bit sequence. In particular, an
integer with a most significant bit of 1 is valid in any other context in
gfortran, so it is unreasonable to treat it as if it were an invalid bit
pattern in this case.

3) The current behavior currently makes it impossible to use BOZ literals to
set any negative number, unless you use -fno-range-check and/or use the BOZ to
set an intermediate value and then use ibset to set the sign bit. This
complicates using BOZ literals to set constants representing positive and
negative infinity, which is one of the only reasons you would ever want to set
a real using a BOZ literal in the first place.

[Bug fortran/58204] Spurious error when using BOZ literal to set an integer

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-09-03
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |sgk at troutmask dot apl.washingto
                   |                            |n.edu
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
After knotting my neurons over the f2008 standard and their extracts in this PR
and PR54072, I think the current implementation (r202213) is valid for f95, but
does not handle the way it should be interpreted for more recent standards, at
least for f2008 (did not checked f2003).

Concerning the sign bit, i.e., "The interpretation of a bit sequence whose most
significant bit is 1 is processor dependent.", I think it does not make sense
to reject it (does anyone knows a present piece of hardware which is not using
two's complement?).

[Bug fortran/58204] [F2008] BOZ literals in the int function should not be treated as unsigned integers

[quantheory at gmail dot com]

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

Sean Santos <quantheory at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Spurious error when using   |[F2008] BOZ literals in the
                   |BOZ literal to set an       |int function should not be
                   |integer                     |treated as unsigned
                   |                            |integers

--- Comment #2 from Sean Santos <quantheory at gmail dot com> ---
Yes, re-reading the Fortran 95 standard, it does look like what gfortran is
doing follows the standard for a BOZ in a DATA statement, but BOZ is not
allowed in an int, so Fortran 95 isn't relevant for the particular test program
in comment 0. In the Fortran 2008 standard, it seems like this is still a bug,
for the reasons I mentioned.

Fortran 2003 is weird. If the BOZ is in the "int" function, it is supposed to
be treated as an integer constant, much like in a Fortran 95 data statement. If
the BOZ is in a "real" function, it is treated as a bit pattern, just like in
Fortran 2008. So actually, you could argue that gfortran is OK for Fortran 2003
as well.

I'm marking this as Fortran 2008, accordingly.

My main motivation for raising this issue at all is that this is one of several
reasons that you have to really jump through hoops to set a real to IEEE
infinity or NaN.

In fact, this seems to be the simplest way to create a constant for
double-precision -Infinity without using "-fno-range-check":

integer(8), parameter :: ninf_bits = &
     ibset(int(Z'7FF0000000000000',8),bit_size(1_8)-1)
real(8), parameter :: neginf = transfer(ninf_bits,1._8)

It's not the worst thing ever, but it's more than a little silly.

[Bug fortran/58204] [F2008] BOZ literals in the int function should not be treated as unsigned integers

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|sgk at troutmask dot apl.washingto |
                   |n.edu                       |

--- Comment #3 from kargl at gcc dot gnu.org ---
Remove myself from cc list.  I don't have time to work
on gfortran in the forseeable future.