Against my better judgement, I've produced the attached
patch to disable integer range checking. This patch allows
gfortran to compile code as the programmer intended not as
the programmer wrote! Consider,
program a
integer(4) b
data b /Z'FFFFFFFF'/
end program
where gfortran supports an integer(4) and an integer(8) type.
The standard explicitly states that the BOZ is converted
to an integer with a kind type parameter with the largest
decimal range. So, the BOZ above becomes 4294967295, which
overflows a 32-bit (signed) integer(4) type. On a twos-compliment
OS without range checking, the value of b would be -1 due
to the usual wrap around. Unfortunately, some programmers
have come to depend on the nonportable, processor-dependent,
behavior. Therefore, a gfortran user will need to explicitly
request no range checking via the -fno-range-check option.
Regression tested on amd64-*-freebsd. There were no new
regressions.
OK for trunk and 4.1? (It's borderline "obviously correct").
2006-09-28 Steven G. Kargl <kargl@gcc.gnu.org>
PR fortran/29147
* arith.c (gfc_check_integer_range): Disable range checking via
-fno-range-check.
------------------------------------------------------------------------
Index: arith.c
===================================================================
--- arith.c (revision 117289)
+++ arith.c (working copy)
@@ -351,6 +351,10 @@ gfc_check_integer_range (mpz_t p, int ki
result = ARITH_ASYMMETRIC;
}
+
+ if (gfc_option.flag_range_check == 0)
+ return result;
+
if (mpz_cmp (p, gfc_integer_kinds[i].min_int) < 0
|| mpz_cmp (p, gfc_integer_kinds[i].huge) > 0)
result = ARITH_OVERFLOW;