This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/8] Document signaling for min, max and ltgt operations


> Am 20.08.2019 um 17:04 schrieb Segher Boessenkool <segher@kernel.crashing.org>:
> 
> On Tue, Aug 20, 2019 at 11:18:38AM +0200, Ilya Leoshkevich wrote:
>> Currently it's not clear whether or not min, max and ltgt should raise
>> floating point exceptions when dealing with qNaNs.
>> 
>> Right now a lot of code assumes that LTGT is signaling: in particular,
>> it's generated for ((x < y) || (x > y)), which is signaling. The
>> behavior of MIN/MAX is (intentionally?) left unspecified, according to
>> commit 64dd117734d0 ("Unconditionally use MAX_EXPR/MIN_EXPR for MAX/MIN
>> intrinsics").
> 
> The < and > operators separately already can cause exceptions, unless
> you use -fno-trapping-math, in which case you cannot have LTGT at all.

Hmm, I've just tried compiling:

    int foo(float a, float b) { return ((a < b) || (a > b)); }

with -ftrapping-math and -fno-trapping-math with gcc 8.0.1, and got LTGT
on tree and rtl levels in both cases:

    232t.optimized: _1 = a_2(D) <> b_3(D);
    312r.final:        (if_then_else:SI (ltgt (reg:CCS 33 %cc)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]