From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 119183858D20; Fri, 4 Feb 2022 01:37:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 119183858D20 From: "gcc_bugzilla at axeitado dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/102994] std::atomic::wait is not marked const Date: Fri, 04 Feb 2022 01:37:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 11.2.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: gcc_bugzilla at axeitado dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rodgertq at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 01:37:26 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102994 =C3=93scar Fuentes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|SUSPENDED |RESOLVED Resolution|--- |FIXED --- Comment #12 from =C3=93scar Fuentes = --- (In reply to Jonathan Wakely from comment #9) > (In reply to =C3=93scar Fuentes from comment #6) > > So IIUC you are applying modifications to libstdc++ that deviate from t= he > > published standard expecting that the committee will accept those chang= es. > > As a user, this is troublesome, because right now I need to special-cas= e gcc > > version >11.2 and maybe version > not accepted and is reverted. >=20 > Why do you need to special case anything? What problem are these extra co= nst > qualifications causing you? One project here consists on a compiler for certain strict, statically typed language that transparently interacts with C++ code bases. We have a mechan= ism for inferring the signature of C/C++ functions and automatically create wrappers for them, using a combination of macros and templates. For instanc= e, this is how std::atomic_notify_all is reflected: LP0_FFI_FN_OV("notify-all", void, (std::atomic*), std::atomic_notify_a= ll); The "_OV" means "overloaded", "void" is the type returned, (std::atomic*) is the argument list. If the returned type and argument list does not match= an overload of std::atomic_notify_all, the C++ compiler throws an error. For stdlibc++ we could simply use LP0_FFI_FN("notify-all", std::atomic_notify_all>); and let our template machinery deduce the signature of std::atomic_notify_a= ll, but other implementations (libc++) do provide the "volatile" overload, so we are forced to explicitly tell the compiler which overload we want. Thus, if the function's signature differ from one implementation to another= , we need to detect the correct signature and use it on each instantiation of std::atomic_notify_all et al we reflect. To make things worse, some distros picked the change and incorporated them = to their gcc 11.2 packages. I'm afraid the only solution is a platform check at configure time plus the corresponding macro-sprinkling on our C++ sources. A hairy mess for what otherwise would be something quite simple and clean. There are other technical inconveniences related to our precise use case th= at would be too long to explain here. Anyway, thanks for explaining the state of affairs. I understand your POV, = so I'm closing this issue.=