[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745 --- Comment #8 from Jonathan Wakely --- (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.
[Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745 --- Comment #7 from Iain Sandoe --- (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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #6 from Xi Ruoyao --- (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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745 --- Comment #5 from Sebastian "spaetz" Spaeth --- 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745 --- Comment #4 from Jakub Jelinek --- 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- 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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745 --- Comment #2 from Sebastian "spaetz" Spaeth --- (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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745 --- Comment #1 from Andreas Schwab --- How did you configure the compiler?
