On Fri, Oct 31, 2014 at 6:59 PM, Joseph S. Myers <jos...@codesourcery.com> 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 > <https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01975.html>).
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 > jos...@codesourcery.com