[Bug c++/107745] New: long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[Bug c++/107745] New: long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[Sebastian at SSpaeth dot de]

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

            Bug ID: 107745
           Summary: long double constexprs don't work with * or /, but
                    work with + and - (JUST ON PPC)
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Sebastian at SSpaeth dot de
  Target Milestone: ---

TL;DR:
This looks like a compiler bug or quality-of-implementation issue, and happens
JUST ON PPC with gcc. From a bit of playing with godbolt, long double
constexprs don't work with * or /, but work with + and -.

https://godbolt.org/z/WYz5fY538

This works fine on everything but PPC that I tried. It also works with PPC
clang, but not PPC gcc. Could you report this to gcc and see what they say?

The shortest reproducible snippet is:

constexpr long double v =
    (6.15348059642740421245081038903225e-15L /
     5.40431955284459475358983848622456e+16L);


Details in upstream issue at https://github.com/google/s2geometry/issues/279

---------------------


The library built fine on all supported archs using Debian's gcc
(g++-12_12.2.0-7 gcc-12_12.2.0-7 libc6-dev_2.35-4 libstdc++-12-dev_12.2.0-7
libstdc++6_12.2.0-7 linux-libc-dev_6.0.3-1) EXCEPT for PPC.

The full failed build log is currently still at:
https://buildd.debian.org/status/fetch.php?pkg=s2geometry&arch=ppc64el&ver=0.10.0-2&stamp=1667081576&raw=0

-------------------

Build failure boils down to the error
```
/<<PKGBUILDDIR>>/src/s2/s2edge_crossings.cc: In instantiation of ‘bool
S2::internal::GetStableCrossProd(const Vector3<T>&, const Vector3<T>&,
Vector3<T>*) [with T = long double]’:
/<<PKGBUILDDIR>>/src/s2/s2edge_crossings.cc:127:54:   required from here
/<<PKGBUILDDIR>>/src/s2/s2edge_crossings.cc:115:31: error:
‘(6.15348059642740421245081038903225e-15l /
5.40431955284459475358983848622456e+16l)’ is not a constant expression
  115 |       (32 * kSqrt3 * DBL_ERR) /
      |       ~~~~~~~~~~~~~~~~~~~~~~~~^
  116 |       (kRobustCrossProdError.radians() / T_ERR - (1 + 2 * kSqrt3));
      |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```


Please let us know if you need more information.

[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[schwab@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
How did you configure the compiler?

[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[Sebastian at SSpaeth dot de]

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

--- Comment #2 from Sebastian "spaetz" Spaeth <Sebastian at SSpaeth dot de> ---
(sid_ppc64el-dchroot)~$ gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-9'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=powerpc64le-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --with-libphobos-druntime-only=yes
--enable-objc-gc=auto --enable-secureplt --enable-targets=powerpcle-linux
--disable-multilib --enable-multiarch --disable-werror --with-long-double-128
--enable-offload-targets=nvptx-none=/build/gcc-12-bHmBmO/gcc-12-12.2.0/debian/tmp-nvptx/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-9)

[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 19779

*** This bug has been marked as a duplicate of bug 19779 ***

[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think we have many dups on this.  IBM double double isn't accurately emulated
inside of GCC (GCC emulation pretends it is a 106-bit mantissa type, which
isn't true, e.g. for denormals it has only 53-bit mantissa, while in some cases
it has up to 2000-ish bit mantissa), so the constant evaluation punts if
computations in this mode are inexact, because they can differ from what one
gets at runtime.
Fixing this would involve representing MODE_COMPOSITE_P inside of gcc not as
one REAL_VALUE_TYPE, but a pair of DFmode REAL_VALUE_TYPEs at least for the
basic arithmetics and enforce on that the IBM double double constraints.
What to do with constexpr evaluation of math functions, starting with
nextafterl etc. is unknown, even libm is full of comments where it doesn't
really know what to do for those cases.  E.g. I think for nextafterl it mostly
pretends it is a 106-bit mantissa type except for subnormals.
Anyway, I'm afraid this is a month or more of work and so far nobody was
willing to invest that time in a dying format with numerically unusable
properties.
powerpc64le-linux is phasing that out and switching to IEEE quad instead.

[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[Sebastian at SSpaeth dot de]

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

--- Comment #5 from Sebastian "spaetz" Spaeth <Sebastian at SSpaeth dot de> ---
I fully understand that nobody wants to invest time into fixing this. What
would be nice though, is if this were really just a missed optimization and not
rejecting to compile valid code.

powerpc could ignore the constexpr in this case, rather than failing to build?

[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #6 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Sebastian "spaetz" Spaeth from comment #5)
> I fully understand that nobody wants to invest time into fixing this. What
> would be nice though, is if this were really just a missed optimization and
> not rejecting to compile valid code.
> 
> powerpc could ignore the constexpr in this case, rather than failing to
> build?

It will be an violation of the standard (at least in some cases).

[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Sebastian "spaetz" Spaeth from comment #5)
> I fully understand that nobody wants to invest time into fixing this. What
> would be nice though, is if this were really just a missed optimization and
> not rejecting to compile valid code.

It's not that no-one wants to fix the bug, it's just that no-one wants it fixed
enough to hire someone to do it .. and it's too much work for "spare time
hacking".

While ibm-128 is being phased out in favour of ieee754 - it is still used on a
number of systems that are current and will be for a few more GCC releases. 
Given the increase in use of constexpr, it's likely to become more common to
see issues.

In the past, I worked around the problem by making conditional non-constexpr
code (so _not_ ignoring constexpr, but having a #ifdef'd alternate path.)

[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to Sebastian "spaetz" Spaeth from comment #5)
> > I fully understand that nobody wants to invest time into fixing this. What
> > would be nice though, is if this were really just a missed optimization and
> > not rejecting to compile valid code.
> > 
> > powerpc could ignore the constexpr in this case, rather than failing to
> > build?
> 
> It will be an violation of the standard (at least in some cases).

Yeah, the suggestion doesn't really make sense in general. If you don't care
whether the initialization is constexpr ... don't use constexpr. It's not about
optimization, it's about guaranteeing compile-time calculations.

I suppose it might be possible to implicitly change the variable to const
instead of constexpr, which would then give errors if you tried to use that in
any constant expressions. I would guess that won't help much real code, because
if you didn't want to use it in constant expressions, you wouldn't usually
declare it constexpr anyway.

In the specific case of
https://github.com/google/s2geometry/blob/2ff824474f0c4dfb157a0d056e4a6bb76bfa690f/src/s2/s2edge_crossings.cc#L115
it would compile, because constexpr apparently is being used as an
optimization, it doesn't need to be done at compile time.

But again, somebody needs to spend time to do that work. The people who require
this to work on their hardware should be the ones to do (or fund) the work on
it. The people unaffected by it probably aren't going to do anything about it.

It might be simpler to implement a "this is powerpc double double and we know
we can't do some arithmetic at compile time so treat this is const not
constexpr and see if that allows us to continue" feature than to implement full
compile-time arithmetic for double double.