[Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow

[Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow

[burnus at gcc dot gnu.org]

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

             Bug #: 52428
           Summary: [RFC] I/O: READING of "-huge()-1": Integer overflow
    Classification: Unclassified
           Product: gcc
           Version: unknown
               URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65825
                    1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: jvdelisle@gcc.gnu.org


As reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658251

For I/O, reading an integer with value -huge()-1 gives an overflow error.

While that is acceptable based on the Fortran numerical model (cf. Fortran
2008, "13.4 Numeric models"), where the valid integer numbers stretch from
-huge() to huge(), it is rather irritating that one can write (WRITE, PRINT)
those numbers but not READ them back in.

Except for Fortran's numerical model, the number looks valid to me as the sign
belongs to the number and is not an unary operator applied afterwards. For
integer I/O, one reads a "signed-digit-string" (R409).


For the source code, something similar applies: Also there, one does *not* have
an unary minus operator applied to the positive string literal but:
  R406  signed-int-literal-constant  is  [ sign ] int-literal-constant
Only Fortran's numerical model is violated. Contrary to I/O, a error is
printed, which can be overruled using -fno-range-check (and that flag is often
but not always mentioned).

EXPECTED: Be more generous at run time and allow this number for integer input.

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-29 08:50:33 UTC ---
Post scriptum:

* For
    read (*, '(i18)') i
  the value -2147483648 is accepted
  But only if one has compiled the main program with -fno-range-check.

  Cf. libgfortran/io/read.c's read_decimal function.

* For
    read (*, *) i
  the value -2147483648 is always rejected, independent of that flag.

  Cf. libgfortran/io/list_read.c's convert_integer function.


Expected:

* A list-directed read gives the same result as a read with an edit descriptor.

* The value is always accepted - even without -fno-range-check.
  This flag is completely nontransparent (with regards to the run-time
library),
  it only works if the main program is compiled with that flag, and not even
  the documentation of the flag mentions that the run-time library is affected.

  See: -fno-range-check at
  http://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

  Admittedly, it is mentioned at
  http://gcc.gnu.org/onlinedocs/gfortran/_005fgfortran_005fset_005foptions.html

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-04-24
                 CC|                            |jb at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-04-24 06:37:16 UTC ---
Confirmed.

I agree that at runtime we should allow full use of the range that the hardware
provides, the Fortran numerical model be damned. 

Also, since the overhead of range checking in string->character conversions is
AFAICS insignificant, I see no reason why it couldn't be enabled all the time.
Thus it's IMHO unnecessary to burden users with having to remember yet another
option.

In order to implement this, we'd need to consider MIN values of signed types
separately from MAX values. Perhaps in mk-kinds-h.sh we should also generate
GFC_INTEGER_X_{MAX,MIN} macros. Trying to figure out whether such macros are
always available also on non-C99 targets, I got bogged down in a maze of
GCC_HEADER_STDINT, glimits.h and whatnot, so I'm not sure actually. OTOH,
currently we typedef the GFC_{U}INTEGER_X types to the C99 {u}intNN_t types,
which are required to have two's complement representation, so we could just
hardcode the values (except for __int128_t where the compiler apparently
doesn't support large enough literals?).

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |jb at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-04-24 09:17:02 UTC ---
Created attachment 27228
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27228
Proposed untested patch

The attached patch should fix this, although I haven't tested it yet.

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #27228|0                           |1
        is obsolete|                            |

--- Comment #4 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-04-24 11:17:02 UTC ---
Created attachment 27229
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27229
Simplified patch

Simplified patch assuming two's complement representation.

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-04-24 21:44:06 UTC ---
See also PR 36515

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2012-04-25 00:29:00 UTC ---
I respectfully disagree.  The Fortran model is/was developed over many years
with many knowledgeable people investing time into it of good reasons.  Some
may disagree,but it is what it is and has nothing to do with hardware.

-fno-range-check is provided for those rare cases where people just can't live
without that one binary case. This is a Fortran compiler. We need to stick to
the standard has much as possible for default behavior and let the flags handle
these corner cases that really (emphasis) are not important at all except for
our human pedantic nature.

(now I crawl back into my cave, knowing that bugzilla is not the place for such
discussions that should be left to the Fortran committee or CLF.)

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-04-25 06:11:58 UTC ---
(In reply to comment #6)
> I respectfully disagree.  The Fortran model is/was developed over many years
> with many knowledgeable people investing time into it of good reasons.  Some
> may disagree,but it is what it is and has nothing to do with hardware.
> 
> -fno-range-check is provided for those rare cases where people just can't live
> without that one binary case. This is a Fortran compiler. We need to stick to
> the standard has much as possible for default behavior and let the flags handle
> these corner cases that really (emphasis) are not important at all except for
> our human pedantic nature.
> 
> (now I crawl back into my cave, knowing that bugzilla is not the place for such
> discussions that should be left to the Fortran committee or CLF.)

AFAICS, the numerical model is a least common denominator construction that
provides some guarantees about the internal representation such that code
mixing bit twiddling and normal integer operations can work portably, while
still allowing several different hardware implementations. With some
restrictions for such code, e.g. only positive integers are allowed and one may
not touch the sign bit with the bit twiddling operations. 

The numerical model does not specify the internal representation of negative
values, nor does it prevent a processor from allowing negative values beyond
the range of the numerical model (as hardware with two's complement does). As
Tobias mentions, as long as we can generate such values and write them out, it
makes sense to be able to read them back in as well.

Wrt range checking, currently we either check against the Fortran numerical
model, or we don't check anything at all. The second case at least makes no
sense, we should at least always check that the hardware value doesn't
overflow. After we do that, there's only that one -huge()-1 value left as the
difference between the numerical model and the hardware range, and IMHO having
a separate option for that seems overly pedantic. And since there are some
(rare, but still) usecases where that value is used, it seems to me that the
simplest option is to just check that the value doesn't overflow the hardware
supported range.

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-04-25 21:15:57 UTC ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01637.html

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

--- Comment #9 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-05-14 19:39:27 UTC ---
Author: jb
Date: Mon May 14 19:39:23 2012
New Revision: 187478

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187478
Log:
PR 52428 Range checking when reading integer values.

gcc/fortran ChangeLog:

2012-05-14  Janne Blomqvist  <jb@gcc.gnu.org>

    PR fortran/52428
    * gfortran.texi: Update _gfortran_set_options documentation.
    * invoke.texi: Remove runtime behavior description of
    -fno-range-check.
    * trans-decl.c (create_main_function): Don't pass the range-check
    setting to the library.


libgfortran ChangeLog:

2012-05-14  Janne Blomqvist  <jb@gcc.gnu.org>

    PR fortran/52428
    * io/io.h (max_value): Rename to si_max, remove second argument.
    * io/list_read.c (convert_integer): Use unsigned types when
    parsing the digits, set max value depending on the sign.
    * io/read.c (max_value): Rename to si_max, remove second argument,
    simplify.
    (read_decimal): Set max value depending on sign, always check
    overflow.
    (read_radix): Calculate max unsigned value directly.
    * libgfortran.h (struct compile_options_t): Remove range_check
    field.
    * runtime/compile_options.c (set_options): Skip handling
    options[7].
    (init_compile_options): Don't set removed field.


gcc/testsuite ChangeLog:

2012-05-14  Janne Blomqvist  <jb@gcc.gnu.org>

    PR fortran/52428
    * gfortran.dg/int_range_io_1.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/int_range_io_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.texi
    trunk/gcc/fortran/invoke.texi
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/io.h
    trunk/libgfortran/io/list_read.c
    trunk/libgfortran/io/read.c
    trunk/libgfortran/libgfortran.h
    trunk/libgfortran/runtime/compile_options.c

[Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow

[jb at gcc dot gnu.org]

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-05-14 19:42:04 UTC ---
Fixed on trunk. Thanks everyone.