Bug 161499

Summary: [libstdc++] [patch] Use FreeBSD's atomic.h if no cpu-specific code is available
Product: Base System Reporter: Ian Lepore <freebsd>
Component: gnuAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: ed, ian
Priority: Normal    
Version: 8.2-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
libstdcpp_atomicity.diff none

Description Ian Lepore 2011-10-11 20:40:08 UTC 
The attached patch adds contrib/libstdc++/config/os/bsd/freebsd/atomicity.h
which implements the libstdc++ atomic ops in terms of FreeBSD's atomic.h, 
and changes the Makefile to use this implementation when a cpu-specific 
implementation is not available.  On the ARM platform this give us fast
atomic ops using the ARM RAS routines instead of generic pthread mutexes.
It may confer similar benefits on other non-x86 platforms.

I created this file by cloning an existing atomicity.h and replacing the
guts of each function.  I left the original GPL license block from the file I
started with in place, but I'm not sure that's appropriate; perhaps it should
be BSD-licensed.  I personally don't wish to assert any copyright or license
of my own, so please feel free to change the license block to whatever makes
the most sense.

How-To-Repeat: N/A
Comment 1 Pedro F. Giffuni freebsd_committer freebsd_triage 2016-06-12 16:29:38 UTC 
We now have a sys/stdatomic.h; I don't think we need such workarounds in libstdc++.

In any case, all tier1 platforms have moved away from libstdc++ into libc++ so if there are issues they should be treated upstream.
Comment 2 Ed Schouten freebsd_committer freebsd_triage 2016-06-12 18:39:28 UTC 
Yes. This could easily be built around C11's <stdatomic.h>, which on FreeBSD works on all supported platforms. Please don't use any of the BSD specific atomics APIs in new code.
Comment 3 Ian Lepore freebsd_committer freebsd_triage 2016-06-12 19:42:24 UTC 
I can't believe anybody is wasting their time addressing this.  Where was everybody 5 years ago when this mattered?  Even by time I became a commiter myself this had already become moot and I had completely forgotten about it.
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2016-06-13 16:07:31 UTC 
Every once in a while various committers go through to try to clean up the stale PRs.  (I have spent time doing that; see below.)  It's just necessary work that Someone (TM) needs to do.

There are various theories of how to go about this.  One that I particularly *dis*like is simply to close ones that are older than N months.  My feeling is that it just frustrates submitters.  In addition, some of the open bugs are still valid.

Of course we still need to figure out a methodology to flag PRs for applicability and non-staleness.  OTOH I myself am not in a position to work on that at this time.

The reason I am addressing your reply is that IMVHO it is counter-productive.  I have received similar replies when I have attempted to triage old PRs in the past.  It has tended to demotivate me to continue doing that, and working through PRs is frustrating enough as it is.