From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20385 invoked by alias); 14 May 2014 17:37:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20370 invoked by uid 89); 14 May 2014 17:37:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 May 2014 17:37:34 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Wkd7R-0001L2-5o from joseph_myers@mentor.com ; Wed, 14 May 2014 10:37:29 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 May 2014 10:37:29 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.2.247.3; Wed, 14 May 2014 18:37:26 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1Wkd7N-00051R-9j; Wed, 14 May 2014 17:37:25 +0000 Date: Wed, 14 May 2014 17:37:00 -0000 From: "Joseph S. Myers" To: Jakub Jelinek CC: Marek Polacek , GCC Patches Subject: Re: [PATCH] Implement -fsanitize=float-cast-overflow In-Reply-To: <20140514113839.GE10386@tucnak.redhat.com> Message-ID: References: <20140513170801.GG2663@redhat.com> <20140514113839.GE10386@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-05/txt/msg01106.txt.bz2 On Wed, 14 May 2014, Jakub Jelinek wrote: > So what do you see as the way to handle this properly? > I mean, for REAL_MODE_FORMAT (TYPE_MODE (expr_type))->b == 2 supposedly to avoid issues with > rounding of the max we could just > REAL_VALUE_TYPE maxval = dconst1; > SET_REAL_EXP (&maxval, REAL_EXP (&maxval) + TYPE_PRECISION (type) - !TYPE_UNSIGNED (type)); > real_convert (&maxval, TYPE_MODE (expr_type), &maxval); > max = build_real (expr_type, maxval); > or so, then supposedly max is always the smallest representable binary > floating point value above or equal to TYPE_MAX_VALUE + 1.0. Yes. Either the power of 2 is exactly representable, or it rounds up to +Inf, and in either case >= (or unordered) is the right test. > For the min value, if it is unsigned, then -1.0 is ok for all binary or > decimal floats, if it is signed, then supposedly we could do the above Yes. > 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. (If min overflows to -Inf, then <= -Inf is correct, use of < would be an incorrect test.) > 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.) -- Joseph S. Myers joseph@codesourcery.com