Bug 161499 - [libstdc++] [patch] Use FreeBSD's atomic.h if no cpu-specific code is available
Summary: [libstdc++] [patch] Use FreeBSD's atomic.h if no cpu-specific code is available
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: gnu (show other bugs)
Version: 8.2-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
Depends on:
Reported: 2011-10-11 20:40 UTC by Ian Lepore
Modified: 2016-06-13 16:07 UTC (History)
2 users (show)

See Also:

libstdcpp_atomicity.diff (3.48 KB, patch)
2011-10-11 20:40 UTC, Ian Lepore
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 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 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 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.