This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Implement -fsanitize=float-cast-overflow
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Marek Polacek <polacek at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Tue, 13 May 2014 18:11:15 +0000
- Subject: Re: [PATCH] Implement -fsanitize=float-cast-overflow
- Authentication-results: sourceware.org; auth=none
- References: <20140513170801 dot GG2663 at redhat dot com>
On Tue, 13 May 2014, Marek Polacek wrote:
> Here's an attempt to add the -fsanitize=float-cast-overflow
> instrumentation. It should issue a runtime error when a floating-point
> to integer type conversion overflows. Eventually it should instrument
As with divide-by-zero, this should not be part of -fsanitize=undefined
because under Annex F this is not undefined behavior (instead it raises
"invalid" and returns an unspecified value, C11 F.4).
> even floating-point to floating-point conversions to detect e.g.
> (float)1e39 overflow, but I'd like to settle first on float to int
> before implementing that.
I think that should be a separate option. If the type has infinities,
it's not undefined even in the absence of Annex F (because infinities
count as part of the range of the type). And of course overflow depends
on the rounding mode when the type of the result is a floating-point type.
(However, conversions of integers to floating point can probably count the
same as conversions of floating point to floating point if you add such an
option. __int128 to float can overflow.)
It would be a good idea for the testcases to cover conversions to
__int128 / unsigned __int128, where supported.
What do you do for overflowing conversions to bit-fields? I think the
correct rule is:
* For C, if the floating-point value, truncated toward 0, is outside the
range of a signed or unsigned type of the specified number of bits, then
you should get the (invalid, unspecified value (this isn't actually
implemented in GCC)), and get a runtime error for the new option.
* For C++, bit-fields don't count as separate types, so it should act as
converting to the declared type and then converting from that to the
bit-field (as a modulo operation).
Thus, for an unsigned:1 bit-field, for example, values outside the
interval (-1, 2) would produce the error for C, but only those outside
(-1, 0x1p32) would do so for C++ (presuming 32-bit int).
> + tree min = TYPE_MIN_VALUE (type);
> + tree max = TYPE_MAX_VALUE (type);
> + /* Add/subtract 1.0 so we can avoid truncating the value of EXPR. */
> + min = fold_build2 (MINUS_EXPR, expr_type,
> + build_real_from_int_cst (expr_type, min),
> + build_one_cst (expr_type));
> + max = fold_build2 (PLUS_EXPR, expr_type,
> + build_real_from_int_cst (expr_type, max),
> + build_one_cst (expr_type));
It looks to me like this will first round the max value to the
floating-point type, then add 1 to the rounded value and round again.
Which I think is in fact safe at least for IEEE binary floating-point
types, but that isn't immediately obvious.
* Does the folding of the addition occur in all cases for IBM long double?
* Is this correct for decimal floating point? There, the overflow
condition (value >= max+1) should be using a value of (max+1) rounded
upward rather than to-nearest, if max+1 isn't exactly representable (and
in general it isn't - powers of two 0x1p24 and above aren't representable
in decimal32, 0x1p54 and above in decimal64, 0x1p113 and above in
decimal128, so you just need to find a case where the double-rounding
computation you have produces the wrong value).
* Likewise, (value <= min-1) for both binary and decimal floating point -
you need to round once, away from 0. For float converted to signed int,
the relevant condition is values < -0x1p31 - 1, i.e. <= 0x1.000002p31f
once you allow for which values are representable as float, which is not
min-1 (min-1 rounds to -0x1p31, but a conversion of that to signed int is
fully defined with no exceptions).
Joseph S. Myers