Call for compiler help/advice: atomic builtins for v3

Paolo Carlini pcarlini@suse.de
Sun Nov 6 10:34:00 GMT 2005


Hi,

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 
motivations.

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.

Other proposals?

I'm going to link this message to a new enhancement PR, anyway.

Thanks in advance,
Paolo.



More information about the Libstdc++ mailing list