From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14110 invoked by alias); 31 Oct 2014 17:59:28 -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 14083 invoked by uid 89); 31 Oct 2014 17:59:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE 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; Fri, 31 Oct 2014 17:59:24 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XkGTo-0000k5-JN from joseph_myers@mentor.com ; Fri, 31 Oct 2014 10:59:20 -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.3.181.6; Fri, 31 Oct 2014 17:59:19 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1XkGTm-0007tH-8H; Fri, 31 Oct 2014 17:59:18 +0000 Date: Fri, 31 Oct 2014 19:02:00 -0000 From: "Joseph S. Myers" To: Richard Biener CC: GCC Patches Subject: Re: [PATCH] Use CONVERT_EXPR_P and friends in the middle-end In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-10/txt/msg03357.txt.bz2 On Fri, 31 Oct 2014, Richard Biener wrote: > This fixes the few places where explicit checks for NOP_EXPR > or CONVERT_EXPRs crept in. The goal really should be to eliminate anything that distinguishes the two, and then combine them (eliminate NOP_EXPR) (as I said in ). > A noticable change may be the tree-eh.c one where we previously > considered FP NOP_EXPRs trapping if flag_trapping_math > ("Any fp arithmetic may trap") but now like FP CONVERT_EXPRs > only when honor_nans (but for some reason the honor_nans > cases don't check flag_trapping_math). I'm not 100% sure which > variant is more correct (this is FP <-> FP conversions thus > widenings, truncations, converts from/to DFP). Well, use of honor_nans there is confused. (honor_nans is set in operation_could_trap_p in a way that checks flag_trapping_math && !flag_finite_math_only - but doesn't check HONOR_NANS on the relevant floating-point mode.) Setting aside for the moment that -ftrapping-math covers both cases where actual trap handlers are called, and cases where exception flags are set without calling trap handlers (the latter being the only one covered by ISO C at present), the following applies: * Conversions of quiet NaNs from one floating-point type to another do not raise exceptions. Conversions of signaling NaNs do, however, and conversions of finite values can raise "inexact" (except for widening from a narrower to a wider type with the same radix) and "underflow" (except for widening, again, and with an exception to the exception in the case of __float80 to __float128 conversion with underflow traps enabled). * Conversions from floating point to integer (FIX_TRUNC_EXPR) do however raise "invalid" for NaN (or infinite) arguments - and for finite arguments outside the range of the destination type (this includes -1 and below converted to unsigned types). Whether they raise "inexact" for non-integer arguments is unspecified. To a first approximation, even with -ffinite-math-only, assume with -ftrapping-math that "invalid" may be raised for such conversions because of out-of-range values (although the range of binary16 - currently only supported as ARM __fp16 - is narrow enough that if you ignore non-finite values, conversions to some signed integer types are guaranteed in-range). It looks like the honor_nans argument was intended for the case of ordered conversions, for which it's correct that quiet NaNs raise exceptions, and is being misused for conversions, where fp_operation && flag_trapping_math is the right thing to check (although there are certain subcases, depending on the types involved, where in fact you can't have traps). That in turn is the default, suggesting just removing the CASE_CONVERT and FIX_TRUNC_EXPR cases (the effect of which is to treat certain conversions as trapping for -ffinite-math-only where previously they weren't treated as trapping). -- Joseph S. Myers joseph@codesourcery.com