Thanks. It's a minefield. I'm regretting using a division by zero example
(as it unintentionally drags in the whole undefined behaviour thing).
How about my recently added g++.dg/pr88173-1.C, is the following valid,
i.e. const, if ordered comparisons against NaNs should raise an exception
with (the default) -ftrapping-math? Or only with -fno-trapping-math?
constexpr bool my_false1 = __builtin_nan("") < 1.0;
constexpr bool my_false2 = __builtin_nans("") < 1.0;
I think Richard Beiner was right; some trapping math is acceptable and
other trapping math is unacceptable, with (currently) no distinction
(in the middle-end) between the two.
Perhaps the g++ front-end relies on/is abusing flag_trapping_math
as a proxy to ensure that division by zero is undefined (is unfolded).
Cheers,
Roger
--
-----Original Message-----
From: Jakub Jelinek <ja...@redhat.com>
Sent: 21 September 2021 14:22
To: Roger Sayle <ro...@nextmovesoftware.com>; Jason Merrill
<ja...@redhat.com>; Jonathan Wakely <jwak...@redhat.com>
Cc: 'Xi Ruoyao' <xry...@mengyan1223.wang>; 'GCC Patches'
<gcc-patches@gcc.gnu.org>
Subject: Re: [RFC/PATCH] C++ constexpr vs. floating point exceptions.
On Tue, Sep 21, 2021 at 02:15:59PM +0100, Roger Sayle wrote:
> Can you double check? Integer division by zero is undefined, but
> isn't floating point division by zero defined by the appropriate IEEE
standards?
https://eel.is/c++draft/expr.mul#4 doesn't make the division by zero
behavior conditional on integral types.
C has similar wording.
Jakub
