This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 05 Jan 2017 17:18:57 +0000
- Subject: [Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
- Auto-submitted: auto-generated
- References: <bug-63829-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rearnsha at gcc dot gnu.org
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #6)
> arm linux code should always be using the _S_atomic sequences. When the
> processor doesn't have the required instructions, kernel helper routines
> will be used.
Richard, do you mean this should happen via libatomic, or by libstdc++ calling
the kernel helpers directly?
It would be relatively easy to make ARM always use _S_atomic, but for some
programs that would add dependency on libatomic which IIUC is optional today.
Solving the backwards-compatibility problem would be harder (code compiled with
existing GCC releases would be using the _S_mutex implementation and mixing
object code would run into the same problems described above, but now even when
using the same -mcpu settings).