[Bug other/51011] FAIL: gcc.dg/atomic-generic.c (test for excess errors)

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51011

--- Comment #9 from dave.anglin at bell dot net 2011-11-17 22:56:41 UTC ---
On 11/17/2011 4:49 PM, amacleod at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51011
>
> --- Comment #8 from Andrew Macleod<amacleod at redhat dot com>  2011-11-17 21:49:44 UTC ---
> Created attachment 25846
>    -->  http://gcc.gnu.org/bugzilla/attachment.cgi?id=25846
> potential second patch
>
> What I dont get is why HP PARISC doesn't have this same problem with __sync.
> __atomic isnt really used anywhere that __sync wasn't before, it simply
> supplements it. or is suppose to.
>
> If __sync doesn't have any issues, then the first patch when applied should
> resolve the HP PARISC issues, it should make all the __atomic library calls be
> CODE labels.  If there is actually a __sync issue, the second patch does the
> same for both __atomic and __sync.
>
> I believe the secondary failures you have run across with __atomic_exchange_1
> should be gone due to the implementation of __atomic_test_and_set and
> __atomic_clear which was checked in on Nov 10, but you'll have to let me know.
>
__sync isn't supported on PARISC HP-UX.  There is library support on 
Linux using a special
system call.  I don't think __sync was used internally before.

The PR libstdc++/51181 provides an example of what happens when one 
attempts to use
__sync when there is no support.  The undefined sync call has no type 
(i.e., the .import
directive wasn't emitted).

Your second patch should fix the symbol's type.  Your first patch fixed 
the __atomic library calls.

The target-supports.exp file has various check_effective_target_sync* 
procs which disable tests
on targets without sync support.

It might be possible to implement a "sync_lock_test_and_set" but the 
only atomic exchange
operation on PARISC is ldcw (load and clear word).  There are also 
alignment constraints.