This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [v3] atomics


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.

FYI: I am currently working on implementing the __sync_* builtins for all sizes on mips.



Do you have any idea as to how many backends this impacts?



A casual grep of arm, sh, and m68k indicates that they are probably missing _sync*, there may be others too.


David Daney


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]