Re: [PATCH] Use CONVERT_EXPR_P and friends in the middle-end

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Oct 31, 2014 at 6:59 PM, Joseph S. Myers
<joseph@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
> joseph@codesourcery.com