This is the mail archive of the
mailing list for the GCC project.
Call for compiler help/advice: atomic builtins for v3
- From: Paolo Carlini <pcarlini at suse dot de>
- To: gcc at gcc dot gnu dot org
- Cc: libstdc++ at gcc dot gnu dot org, rth at redhat dot com,Ian Lance Taylor <ian at airs dot com>
- Date: Sun, 06 Nov 2005 11:34:30 +0100
- Subject: Call for compiler help/advice: atomic builtins for v3
we have this long standing issue which really we should solve, one way
or another: otherwise there are both correctness and performance issues
which we cannot fix, new features which we cannot implement. I have
plenty of examples, just ask, in case, if you want more details and
In a nutshell, the problem is that there is no easy way to use in the
library *headers* the new atomic builtins: we want the builtins in the
headers, because we want inlining, but we cannot know whether the
builtins are actually available. This is of course because of targets
like i686-* (I think old Sparcs is another example), when by default the
generated code is i386 compatible. In such cases, more generally, the
availability or not of the builtins depends on the actual command line
switches (e.g., -march).
Thus my request: would it be possible to have available the builtins
unconditionally, by way of a slow (locks) fallback replacing the real
implementation when the actual target code doesn't allow for them? I
think it's rather obvious that this is the cleanest solution for the
issue by far. Alternately, something I could probably implement myself
rather quickly, export a preprocessor builtin, which could be exploited
in macros. As I said, I already explored a bit this solution time ago
and seems to me very easy to implement, but really I rather prefer the
first one. However, if you really believe the latter is the only
possible way to go, I can work on it immediately: the issue is on top of
my priorities for the next weeks.
I'm going to link this message to a new enhancement PR, anyway.
Thanks in advance,