* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
@ 2012-02-29 9:09 ` burnus at gcc dot gnu.org
2012-04-24 6:37 ` jb at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-29 9:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
2012-02-29 9:09 ` [Bug fortran/52428] " burnus at gcc dot gnu.org
@ 2012-04-24 6:37 ` jb at gcc dot gnu.org
2012-04-24 9:17 ` jb at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-04-24 6:37 UTC (permalink / raw)
To: gcc-bugs
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?).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
2012-02-29 9:09 ` [Bug fortran/52428] " burnus at gcc dot gnu.org
2012-04-24 6:37 ` jb at gcc dot gnu.org
@ 2012-04-24 9:17 ` jb at gcc dot gnu.org
2012-04-24 11:17 ` jb at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-04-24 9:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
` (2 preceding siblings ...)
2012-04-24 9:17 ` jb at gcc dot gnu.org
@ 2012-04-24 11:17 ` jb at gcc dot gnu.org
2012-04-24 21:44 ` jb at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-04-24 11:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
` (3 preceding siblings ...)
2012-04-24 11:17 ` jb at gcc dot gnu.org
@ 2012-04-24 21:44 ` jb at gcc dot gnu.org
2012-04-25 0:29 ` jvdelisle at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-04-24 21:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
` (4 preceding siblings ...)
2012-04-24 21:44 ` jb at gcc dot gnu.org
@ 2012-04-25 0:29 ` jvdelisle at gcc dot gnu.org
2012-04-25 6:12 ` jb at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jvdelisle at gcc dot gnu.org @ 2012-04-25 0:29 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
` (5 preceding siblings ...)
2012-04-25 0:29 ` jvdelisle at gcc dot gnu.org
@ 2012-04-25 6:12 ` jb at gcc dot gnu.org
2012-04-25 21:16 ` jb at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-04-25 6:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
` (6 preceding siblings ...)
2012-04-25 6:12 ` jb at gcc dot gnu.org
@ 2012-04-25 21:16 ` jb at gcc dot gnu.org
2012-05-14 19:43 ` jb at gcc dot gnu.org
2012-05-14 19:50 ` jb at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-04-25 21:16 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
` (7 preceding siblings ...)
2012-04-25 21:16 ` jb at gcc dot gnu.org
@ 2012-05-14 19:43 ` jb at gcc dot gnu.org
2012-05-14 19:50 ` jb at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-05-14 19:43 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/52428] [RFC] I/O: READING of "-huge()-1": Integer overflow
2012-02-29 8:13 [Bug fortran/52428] New: [RFC] I/O: READING of "-huge()-1": Integer overflow burnus at gcc dot gnu.org
` (8 preceding siblings ...)
2012-05-14 19:43 ` jb at gcc dot gnu.org
@ 2012-05-14 19:50 ` jb at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-05-14 19:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread