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.
