From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8895 invoked by alias); 3 Nov 2014 12:01:33 -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 8882 invoked by uid 89); 3 Nov 2014 12:01:33 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f50.google.com Received: from mail-wg0-f50.google.com (HELO mail-wg0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 03 Nov 2014 12:01:31 +0000 Received: by mail-wg0-f50.google.com with SMTP id z12so10780821wgg.23 for ; Mon, 03 Nov 2014 04:01:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.219.66 with SMTP id pm2mr16133248wic.5.1415016087689; Mon, 03 Nov 2014 04:01:27 -0800 (PST) Received: by 10.194.20.74 with HTTP; Mon, 3 Nov 2014 04:01:27 -0800 (PST) In-Reply-To: References: Date: Mon, 03 Nov 2014 12:01:00 -0000 Message-ID: Subject: Re: [PATCH] Use CONVERT_EXPR_P and friends in the middle-end From: Richard Biener To: "Joseph S. Myers" Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00055.txt.bz2 On Fri, Oct 31, 2014 at 6:59 PM, Joseph S. Myers wrote: > 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 > ). Yes, >> 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). Ok, I'll test a patch doing that. Thanks, Richard. > -- > Joseph S. Myers > joseph@codesourcery.com