On Thu, 14 Apr 2022 at 16:24, Palmer Dabbelt <pal...@rivosinc.com> wrote: > > On Thu, 14 Apr 2022 08:22:05 PDT (-0700), jwak...@redhat.com wrote: > > 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. > > Great, thanks!
Pushed as r12-8161-g3fc22eedb033cb
