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

jb at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Apr 25 06:12:00 GMT 2012


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.



More information about the Gcc-bugs mailing list