On Thu, 14 Apr 2022 at 16:18, Palmer Dabbelt wrote: > > On Thu, 14 Apr 2022 08:08:17 PDT (-0700), jwak...@redhat.com wrote: > > On 07/04/22 11:46 -0700, Palmer Dabbelt wrote: > >>The RISC-V port requires libatomic to be linked in order to resolve > >>various atomic functions, which results in builds that have > >>"--with-libstdcxx-lock-policy=auto" defaulting to mutex-based locks. > >>Changing this to direct atomics breaks the ABI, this forces the auto > >>detection mutex-based atomics on RISC-V in order to avoid a silent ABI > >>break for users. > >> > >>See Bug 84568 for more discussion. In the long run there may be a way > >>to get the higher-performance atomics without an ABI flag day, but > >>that's going to be a much more complicated operation. We don't even > >>have support for the inline atomics yet, but given that some folks have > >>been discussing hacks to make these libatomic routines appear implicitly > >>it seems prudent to just turn off the automatic detection for RISC-V. > >> > >>libstdc++-v3/ChangeLog > >> > >> * acinclude.md (GLIBCXX_ENABLE_LOCK_POLICY): Force auto to mutex > >> for RISC-V. > > > > As documented at https://gcc.gnu.org/lists.html all patches for > > libstdc++ need to go to the libstdc++ list as well as gcc-patches > > (otherwise I won't see them). > > Thanks, I'll try to remember to look next time. > > > We'd usually do something like: > > > > case "${host}" in > > *-*-riscv) libstdcxx_atomic_lock_policy=mutex ;; > > *-*-*) AC_TRY_COMPILE([ ... ],,[],[]) > > esac > > > > but this way is simpler. If we add more customization for other > > targets we can reconsider using the 'case "${host}"' form. > > Ya, that's kind of where I came to as well -- the proper autoconf flavor > would scale way better, but hopefully nobody else makes this mistake and > thus we don't need to worry about that.
<nod> > I'm fine with either way (though I think we'd need a "riscv*" there, to > match riscv32 and riscv64?), so if you want to swap it over (or have me > re-spin this) it's no big deal on my end -- also fine, as per below, > with you just committing this ;) Yeah, I figured *-*-riscv probably wasn't right, so that's another reason to prefer your approach. > > > So this is OK for trunk, modulo regenerating libstdc++-v3/configure > > with this change. Let me know if you want me to do that regen for you > > (or commit the whole thing for you). > > That'd be great, thanks! It usually takes me a while to get all the > autotools versions lined up (we just got new machines at the office), > that way I won't have to do so. No problem, I can regen+push for you.
