Re: [v3] atomics

[Andrew Haley <aph at redhat dot com>]

Benjamin Kosnik wrote:
>> Right, I had already thought that part out.  However it is even more 
>> trivial to change the libstdc++ code so that it only uses 32 bit wide 
>> locations.
> 
> For the specific atomic_flag issue, this kind of fix is possible.
> That's not really the end of the issue though.
>  
> The problem is that libstdc++ is now implementing an atomics interface
> that could potentially use __sync builtins on various size integral
> types. It seems now that the __sync builtins are not implemented
> uniformly across all backends, so libstdc++ would have to add in
> configure and logic to deal with this, probe the extent of support,
> and come up with a fallback position when it's missing, etc.
> 
> That's possible, but certainly more work than just assuming that if the
> __sync builtins are implemented, they are implemented for the entire
> set of sizes. (This is only coming up now because libstdc++ only used
> the atomic word size up until recently. It looks like libgfortran is
> is also only checking for int in LIBGFOR_CHECK_SYNC_FETCH_AND_ADD.)
> 
> It sounds like it's not hard to do implement the full set. That's
> certainly my preference.
> 
> Do you have any idea as to how many backends this impacts? 

ARM has none.

You could consider doing what I did in gcj.  If the back-end supports
a particular __sync builtin I use it, but if it doesn't I emit
libcalls to routines defined in libgcj.  Another alternative would
be simply to define all the __sync builtins in libgcc.

Andrew.