https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994
Óscar Fuentes <gcc_bugzilla at axeitado dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Óscar Fuentes <gcc_bugzilla at axeitado dot com> ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Óscar Fuentes from comment #6)
> > So IIUC you are applying modifications to libstdc++ that deviate from the
> > published standard expecting that the committee will accept those changes.
> > As a user, this is troublesome, because right now I need to special-case gcc
> > version >11.2 and maybe version <X.xx again in the future if the change is
> > not accepted and is reverted.
>
> Why do you need to special case anything? What problem are these extra const
> 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 mechanism
for inferring the signature of C/C++ functions and automatically create
wrappers for them, using a combination of macros and templates. For instance,
this is how std::atomic_notify_all is reflected:
LP0_FFI_FN_OV("notify-all", void, (std::atomic<int>*), std::atomic_notify_all);
The "_OV" means "overloaded", "void" is the type returned, (std::atomic<int>*)
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<std::atomic<int>>);
and let our template machinery deduce the signature of std::atomic_notify_all,
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 that
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.
