From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0DE213858D20; Tue, 20 Feb 2024 17:19:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0DE213858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708449577; bh=ZZRbkiPYna7jlHlN5DO/cBYpQPT9v6bqI5j6ZcGvdM0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DgreV9t3bq8Ua8fR0PInkabPLmmNyb6DTjCud0t7yLqJyYgbmOcExFzJpeWmumhGf xHvWTngEWgl1M7z01tMB5L/VKqUOKiFJRR2jMOZT9sCFBN/ifYuoF1/MvTqh2yMHRc cNq2XBx8VxXXtj+cEei1Mdp8bNPm7JKPUp5b9aDI= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/107745] long double constexprs don't work with * or /, but work with + and - (JUST ON PPC) Date: Tue, 20 Feb 2024 17:19:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 12.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107745 --- 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. W= hat > > would be nice though, is if this were really just a missed optimization= and > > not rejecting to compile valid code. > >=20 > > powerpc could ignore the constexpr in this case, rather than failing to > > build? >=20 > 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 a= bout 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, bec= ause 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/2ff824474f0c4dfb157a0d056e4a6bb76= bfa690f/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 req= uire 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 kn= ow 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.=