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.
