This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Jakub Jelinek <jakub at redhat dot com>*To*: "Joseph S. Myers" <joseph at codesourcery dot com>*Cc*: Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>*Date*: Thu, 15 May 2014 21:09:29 +0200*Subject*: Re: [PATCH] Implement -fsanitize=float-cast-overflow*Authentication-results*: sourceware.org; auth=none*References*: <20140513170801 dot GG2663 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1405131745570 dot 23277 at digraph dot polyomino dot org dot uk> <20140514113839 dot GE10386 at tucnak dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1405141727440 dot 16785 at digraph dot polyomino dot org dot uk>*Reply-to*: Jakub Jelinek <jakub at redhat dot com>

On Wed, May 14, 2014 at 05:37:25PM +0000, Joseph S. Myers wrote: > > with s/max/min/;s/dconst1/dconstm1/; and, after the real_convert > > do inexact = real_arithmetic (&newminval, MINUS_EXPR, &minval, &dconst1); > > if !inexact just min = build_real (expr_type, newminval); and be done with > > it (the question is if for IBM double double this will DTRT for > > LONG_LONG_MIN, which I think should be that the high double will contain > > (double) LONG_LONG_MIN and the low double -1.0). For inexact > > (which should be the same thing as if result of real_arithmetic + real_convert > > is the same as original minval) we need to subtract more than one, dunno if > > we should just compute it from the REAL_EXP and precision, or just keep > > subtracing powers of two until after real_convert it is no longer bitwise > > identical to original minval. We don't have anything close to > > real_nextafter nor real_convert variant that can round for arbitrary > > rounding modes. > > Any preferences how to implement this? > > In the inexact case but where the power of 2 is representable, you could > always handle it as < min rather than <= min-1 - although computing the > actual nextafter value based on the precision of the floating-point type > shouldn't be hard and would allow <= to be used everywhere. Here is incremental implementation for the binary floating point formats (and, it seems also the C/C++ bitfields are handled properly already by Marek's patch). I've tried struct S { int i : 17; } s; void f1 (float x) { s.i = x; } long long f2 (float x) { return x; } __int128_t f3 (long double x) { return x; } __int128_t f4 (float x) { return x; } __uint128_t f5 (float x) { return x; } long long f6 (long double x) { return x; } on both x86_64 and ppc64 -mlong-double-128 and manually inspected the numbers and they looked ok, for ppc64 f6 was using: u<= { 9223372036854775808.0 + 0.0 } u>= {-9223372036854775808.0 + -1.0 } and f3 u<= { 170141183460469231731687303715884105728.0 + 0.0 } u>= { -170141183460469231731687303715884105728.0 + -4194304.0 } which I believe is correct. Of course the above needs to be transformed into two real testcases that will actually test that valid in-range values don't complain and out of range do, will leave that to Marek. > > For _Decimal*, no idea unfortunately, perhaps for the first iteration > > ubsan should ignore decimal to int conversions. > > Yes, that seems reasonable. (Computing the exact max+1 or min-1 as an > MPFR value and then using mpfr_snprintf (then decimal_real_from_string) > would be one way of converting to decimal with a controlled rounding > direction.) If prec < HOST_BITS_PER_WIDE_INT, then we can just snprintf normally, otherwise yes, we could e.g. use char *buf = XALLOCAVEC (char, prec / 2); mpfr_t m; mpfr_init2 (m, prec + 2); mpfr_set_ui_2exp (m, 1, prec - !uns_p); mpfr_snprintf (buf, prec / 2, "%f", m); // buf should be TYPE_MAX_VALUE + 1.0 here? if (!uns_p) { mpfr_set_si_2exp (m, -1, prec - 1); mpfr_sub_ui (m, m, 1, GMP_RNDN); mpfr_snprintf (buf, prec / 2, "%f", m); // buf should be TYPE_MIN_VALUE - 1.0 here? } But I think we can't use decimal_real_from_string, we'd need a variant of that function that would allow specification of the rounding mode and which of the 3 _DecimalN types it is, and supposedly decNumber dn; decContext set; decContextDefault (&set, DEC_INIT_DECIMAL{32,64,128}); set.traps = 0; set.round = {DEC_ROUND_CEILING,DEC_ROUND_FLOOR}; decNumberFromString (&dn, s, &set); then if not DEC_INIT_DECIMAL128 supposedly convert there and back to DEC_INIT_DECIMAL128 and then convert to REAL_FORMAT. But my _Decimal knowledge is very limited, so I'll leave that to the DFP folks (unless Marek is interested). --- gcc/convert.c +++ gcc/convert.c @@ -851,6 +851,8 @@ expr = save_expr (expr); tree check = ubsan_instrument_float_cast (loc, type, expr); expr = build1 (FIX_TRUNC_EXPR, type, expr); + if (check == NULL) + return expr; return fold_build2 (COMPOUND_EXPR, TREE_TYPE (expr), check, expr); } else --- gcc/ubsan.c +++ gcc/ubsan.c @@ -903,17 +903,62 @@ ubsan_instrument_float_cast (location_t loc, tree type, tree expr) { tree expr_type = TREE_TYPE (expr); - tree t, tt, fn; + tree t, tt, fn, min, max; + enum machine_mode mode = TYPE_MODE (expr_type); + int prec = TYPE_PRECISION (type); + bool uns_p = TYPE_UNSIGNED (type); - 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)); + /* Float to integer conversion first truncates toward zero, so + even signed char c = 127.875f; is not problematic. + Therefore, we should complain only if EXPR is unordered or smaller + or equal than TYPE_MIN_VALUE - 1.0 or greater or equal than + TYPE_MAX_VALUE + 1.0. */ + if (REAL_MODE_FORMAT (mode)->b == 2) + { + /* For maximum, TYPE_MAX_VALUE might not be representable + in EXPR_TYPE, e.g. if TYPE is 64-bit long long and + EXPR_TYPE is IEEE single float, but TYPE_MAX_VALUE + 1.0 is + either representable or infinity. */ + REAL_VALUE_TYPE maxval = dconst1; + SET_REAL_EXP (&maxval, REAL_EXP (&maxval) + prec - !uns_p); + real_convert (&maxval, mode, &maxval); + max = build_real (expr_type, maxval); + + /* For unsigned, assume -1.0 is always representable. */ + if (uns_p) + min = build_minus_one_cst (expr_type); + else + { + /* TYPE_MIN_VALUE is generally representable (or -inf), + but TYPE_MIN_VALUE - 1.0 might not be. */ + REAL_VALUE_TYPE minval = dconstm1, minval2; + SET_REAL_EXP (&minval, REAL_EXP (&minval) + prec - 1); + real_convert (&minval, mode, &minval); + real_arithmetic (&minval2, MINUS_EXPR, &minval, &dconst1); + real_convert (&minval2, mode, &minval2); + if (real_compare (EQ_EXPR, &minval, &minval2) + && !real_isinf (&minval)) + { + /* If TYPE_MIN_VALUE - 1.0 is not representable and + rounds to TYPE_MIN_VALUE, we need to subtract + more. As REAL_MODE_FORMAT (mode)->p is the number + of base digits, we want to subtract a number that + will be 1 << (REAL_MODE_FORMAT (mode)->p - 1) + times smaller than minval. */ + minval2 = dconst1; + gcc_assert (prec > REAL_MODE_FORMAT (mode)->p); + SET_REAL_EXP (&minval2, + REAL_EXP (&minval2) + prec - 1 + - REAL_MODE_FORMAT (mode)->p + 1); + real_arithmetic (&minval2, MINUS_EXPR, &minval, &minval2); + real_convert (&minval2, mode, &minval2); + } + min = build_real (expr_type, minval2); + } + } + /* Only binary floating point supported right now. */ + else + return NULL_TREE; if (flag_sanitize_undefined_trap_on_error) fn = build_call_expr_loc (loc, builtin_decl_explicit (BUILT_IN_TRAP), 0); Jakub

**Follow-Ups**:**Re: [PATCH] Implement -fsanitize=float-cast-overflow***From:*Joseph S. Myers

**References**:**[PATCH] Implement -fsanitize=float-cast-overflow***From:*Marek Polacek

**Re: [PATCH] Implement -fsanitize=float-cast-overflow***From:*Joseph S. Myers

**Re: [PATCH] Implement -fsanitize=float-cast-overflow***From:*Jakub Jelinek

**Re: [PATCH] Implement -fsanitize=float-cast-overflow***From:*Joseph S. Myers

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |