Phil Endecott writes: > Andrew Haley wrote: > > Phil Endecott writes: > > > Andrew Haley wrote: > > > > David Daney writes: > > > > > There is nothing that says that __sync_compar_and_swap() cannot expand > > > > > to a libcall. > > > > > > > > Err, if a port doen't have an implementation, that's what gcc does > > > > anyway. :-) > > > > > > That's what the docs say, but actually if you try to use __sync_* on > > > ARM you'll get a linker error. A library implementation would need to > > > be OS-specific. > > > > Well, yes. What else would you expect? I don't understand your > > point. > > OK, there's a (subtle) difference between "expands to a library call" > and "expands to a library call which is actually implemented in libgcc". It can't be implemented in gcc, because it's hardware-specific. The same compiled libgcc is portable between different architectures. That's why compare_and_swap() has to be done in the kernel. > "My point", now about a thousand messages ago (:-!), is that I'd quite > like for __sync_lock_test_and_set to expand to a SWP instruction > please; and that's all. Sure, we got that before, but the discussion has moved on. Andrew.