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. Possible issues: * 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 jos...@codesourcery.com
