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

["Joseph S. Myers" <joseph at codesourcery dot com>]

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>).

> 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