[Bug fortran/52428] [RFC] I/O: READING of -huge()-1: Integer overflow
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=gccview=revrev=187478 Log: PR 52428 Range checking when reading integer values. gcc/fortran ChangeLog: 2012-05-14 Janne Blomqvist j...@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 j...@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 j...@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
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.
[Bug fortran/52428] [RFC] I/O: READING of -huge()-1: Integer overflow
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
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
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
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
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
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
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
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
