[Bug c++/110476] New: constexpr floating point regression with -std=c++XX

[Bug c++/110476] New: constexpr floating point regression with -std=c++XX

[pdimov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476

            Bug ID: 110476
           Summary: constexpr floating point regression with -std=c++XX
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pdimov at gmail dot com
  Target Milestone: ---

The following program

#define STATIC_ASSERT(...) static_assert(__VA_ARGS__, #__VA_ARGS__)

struct X
{
    float f;
};

int main()
{
    constexpr X x{ 3.14f };
    STATIC_ASSERT( x.f == 3.14f );
}

fails under GCC 13/14 with

<source>: In function 'int main()':
<source>:11:24: error: static assertion failed: x.f == 3.14f
   11 |     STATIC_ASSERT( x.f == 3.14f );
      |                    ~~~~^~~~~~~~
<source>:1:42: note: in definition of macro 'STATIC_ASSERT'
    1 | #define STATIC_ASSERT(...) static_assert(__VA_ARGS__, #__VA_ARGS__)
      |                                          ^~~~~~~~~~~
<source>:11:24: note: the comparison reduces to '(3.14000010490417480469e+0l ==
3.1400000000000000001e+0l)'
   11 |     STATIC_ASSERT( x.f == 3.14f );
      |                    ~~~~^~~~~~~~

when compiled with -m32 -std=c++XX under x86 (https://godbolt.org/z/Ghs7j5Teq).
The reason is that -std=c++XX implies -fexcess-precision=standard
(https://godbolt.org/z/zx4rn4j5W).

Previous versions worked fine.

[Bug c++/110476] constexpr floating point regression with -std=c++XX

[pdimov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476

--- Comment #1 from Peter Dimov <pdimov at gmail dot com> ---
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742, this is a
consequence of applying the FLT_EVAL_METHOD=2 rules, and can be fixed by
casting 3.14f to (float).

That's... incredibly surprising, though. 3.14f is already a float.

For context, I encountered this regression in the Boost.Variant2 test suite
when I added GCC 13 to CI.

[Bug c++/110476] constexpr floating point regression with -std=c++XX

[pdimov at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476

--- Comment #2 from Peter Dimov <pdimov at gmail dot com> ---
Discussion of FLT_EVAL_METHOD notwithstanding, I think that this behavior is
not allowed by https://eel.is/c++draft/lex.fcon#3.

"If the scaled value is not in the range of representable values for its type,
the program is ill-formed. Otherwise, the value of a floating-point-literal is
the scaled value if representable, else the larger or smaller representable
value nearest the scaled value, chosen in an implementation-defined manner."

I don't see any license here for the value of 3.14f to be 3.14L.

[Bug c++/110476] constexpr floating point regression with -std=c++XX

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think the justification for GCC's behaviour is that "representable value" is
to be interpreted in the context of FLT_EVAL_METHOD, so it means representable
as double (for FLT_EVAL_METHOD==1) or long double (for 2).

"its type" is only mentioned in the first sentence, which doesn't apply to IEEE
types because they support infinities and so all values are in the range of
representable values. The second sentence doesn't mention "its type".