From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10842 invoked by alias); 13 May 2014 18:11:26 -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 10810 invoked by uid 89); 13 May 2014 18:11:25 -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; Tue, 13 May 2014 18:11:24 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1WkHAd-00024a-0X from joseph_myers@mentor.com ; Tue, 13 May 2014 11:11:19 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 May 2014 11:11:18 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Tue, 13 May 2014 19:11:16 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1WkHAZ-0007TV-Hk; Tue, 13 May 2014 18:11:15 +0000 Date: Tue, 13 May 2014 18:11:00 -0000 From: "Joseph S. Myers" To: Marek Polacek CC: GCC Patches , Jakub Jelinek Subject: Re: [PATCH] Implement -fsanitize=float-cast-overflow In-Reply-To: <20140513170801.GG2663@redhat.com> Message-ID: References: <20140513170801.GG2663@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-05/txt/msg01006.txt.bz2 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 joseph@codesourcery.com