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

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

[danglin at gcc dot gnu.org]

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

             Bug #: 51011
           Summary: FAIL: gcc.dg/atomic-generic.c (test for excess errors)
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: danglin@gcc.gnu.org
              Host: hppa2.0w-hp-hpux11.11
            Target: hppa2.0w-hp-hpux11.11
             Build: hppa2.0w-hp-hpux11.11


Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/atomic-generic.c    -w 
/test/gnu/gcc/gcc/gc
c/testsuite/gcc.dg/atomic-generic-aux.c  -lm   -o ./atomic-generic.exe   
(timeo
ut = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
   __atomic_compare_exchange (first referenced in /var/tmp//cc8Tx8dY.o) (data)
   __atomic_load (first referenced in /var/tmp//cc8Tx8dY.o) (data)
   __atomic_store (first referenced in /var/tmp//cc8Tx8dY.o) (data)
   __atomic_exchange (first referenced in /var/tmp//cc8Tx8dY.o) (data)
collect2: error: ld returned 1 exit status

Similar fails:

FAIL: gcc.dg/atomic-lockfree.c (test for excess errors)
Excess errors:
/usr/ccs/bin/ld: Unsatisfied symbols:
   __atomic_is_lock_free (first referenced in /var/tmp//ccmFyrgX.o) (data)

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/atomic-noinline.c    -w -fno-inline-atomics
 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/atomic-noinline-aux.c  -lm   -o
./atomic
-noinline.exe    (timeout = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
   __atomic_exchange_1 (first referenced in /var/tmp//ccCRwwDz.o) (data)
   __atomic_load_2 (first referenced in /var/tmp//ccCRwwDz.o) (data)
   __atomic_compare_exchange_2 (first referenced in /var/tmp//ccCRwwDz.o)
(data)
   __atomic_store_1 (first referenced in /var/tmp//ccCRwwDz.o) (data)
   __atomic_fetch_add_1 (first referenced in /var/tmp//ccCRwwDz.o) (data)
   __atomic_fetch_add_2 (first referenced in /var/tmp//ccCRwwDz.o) (data)
   __atomic_is_lock_free (first referenced in /var/tmp//ccCRwwDz.o) (data)

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

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #1 from Andrew Macleod <amacleod at redhat dot com> 2011-11-07 19:27:36 UTC ---
Is dejagnu on hpux limited somehow?

atomic-generic.c for instance has the line:

/* { dg-additional-sources "atomic-generic-aux.c" } */

which on all the targets I have tried it on cause atomic-generic-aux.c to be
compiled at the same time as atomic-generic.c, and it supplies those
functions...

is there a reason that doesn't happen on hpux?

[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 #2 from dave.anglin at bell dot net 2011-11-07 20:03:43 UTC ---
On 11/7/2011 2:27 PM, amacleod at redhat dot com wrote:
> Is dejagnu on hpux limited somehow
That's not the problem.

The problem is the atomic functions are not being typed correctly:

/usr/ccs/bin/ld: Unsatisfied symbols:
    __atomic_compare_exchange (first referenced in /var/tmp//cc8Tx8dY.o) 
(data)

The linker is looking for a data symbol.

[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 #3 from dave.anglin at bell dot net 2011-11-08 00:10:53 UTC ---
On 7-Nov-11, at 3:03 PM, dave.anglin at bell dot net wrote:

> The problem is the atomic functions are not being typed correctly:
>
> /usr/ccs/bin/ld: Unsatisfied symbols:
>    __atomic_compare_exchange (first referenced in /var/tmp// 
> cc8Tx8dY.o)
> (data)


This causes massive failures in g++ testsuite.  for example,

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/ 
test/gnu/
gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g+ 
+.dg/bprob
/g++-bprob-1.C   -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp- 
hpux11.11/libstd
c++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w- 
hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/ 
libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/ 
gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0  -g   - 
fprofile-arcs    -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc 
++-v3/src/.libs  -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc 
++-v3/src/.libs  -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc 
++-v3/src/.libs  -lm   -o /test/gnu/gcc/objdir/gcc/testsuite/g++/g++- 
bprob-1.x01    (timeout = 300)PASS: g++.dg/bprob/g++-bprob-1.C  
compilation,  -g  -fprofile-arcsSetting LD_LIBRARY_PATH to .:/test/gnu/ 
gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/test/gnu/ 
gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.
libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa2.0w-hp- 
hpux11.11/./lib
stdc++-v3/src/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./ 
libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/gcc/usr/lib/dld.sl:  
Unresolved symbol: __atomic_exchange_1 (data)  from /test/gnu/gcc/ 
objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs/libstdc++.sl. 
6FAIL: g++.dg/bprob/g++-bprob-1.C execution,    -g  -fprofile-arcs

The used flag is set during gimplification, so rtx_for_function_call  
doesn't call assemble_external when the
call is expanded.

--
John David Anglin    dave.anglin@bell.net

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

[amacleod at redhat dot com]

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

--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> 2011-11-08 03:18:36 UTC ---
Yeah, it looks like I'll have to change the built-in mechanism slightly.  I
followed the __sync methodology, but they dont resolve to function calls unless
they are in libgcc I think.  The __atomic calls resolve to actual external
references.  I think I need to change the initial def's in sync-builtins.def to
indicate there is a fallthrough function call, and make a few additional tweaks
to make sure it gets the right name.

I'll look into that tomorrow.

[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 #5 from dave.anglin at bell dot net 2011-11-08 14:56:44 UTC ---
On 11/7/2011 10:18 PM, amacleod at redhat dot com wrote:
> Yeah, it looks like I'll have to change the built-in mechanism slightly.  I
> followed the __sync methodology, but they dont resolve to function calls unless
> they are in libgcc I think.  The __atomic calls resolve to actual external
> references.  I think I need to change the initial def's in sync-builtins.def to
> indicate there is a fallthrough function call, and make a few additional tweaks
> to make sure it gets the right name.
HP-UX PA-RISC is somewhat unique in requiring that functions have the 
correct type.  It
doesn't matter on Linux.  Suspect the __sync builtins when they resolve 
to functions may
also have this problem.

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

[amacleod at redhat dot com]

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

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> 2011-11-16 19:03:18 UTC ---
Created attachment 25840
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25840
potential fix

rth has finished the libgcc changes required for supplying __atomic mappings
like __sync already has.  This should (hopefully) resolve the issues except for
the originally specified testcase atomic-noinline.c

Please try a new run with a recent checkout and see what fails.  I'm assuming
that atomic-noinline.c will still fail. If so this patch should resolve the
issue.  With any luck at all, it won't cause any new issues, but the
interaction between those __sync and libgcc supplied routines is very unclear
to me since I dont know why the __sync routines didnt fail before.  If there
are still other failures, this patch may fix them as well.

give it a try and let me know what happens.

Andrew

[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 #7 from dave.anglin at bell dot net 2011-11-17 01:23:53 UTC ---
On 16-Nov-11, at 2:03 PM, amacleod at redhat dot com wrote:

> Please try a new run with a recent checkout and see what fails.  I'm  
> assuming
> that atomic-noinline.c will still fail. If so this patch should  
> resolve the
> issue.  With any luck at all, it won't cause any new issues, but the
> interaction between those __sync and libgcc supplied routines is  
> very unclear
> to me since I dont know why the __sync routines didnt fail before.   
> If there
> are still other failures, this patch may fix them as well.


The reason the __sync routines didn't fail is they are only used with  
ELF objects
on arm and hppa Linux.   Explicit typing of functions and data symbols  
isn't
required.  On HP PARISC, the default assumption is that a symbol with  
no type
is a data symbol.  As a result, calls to functions that don't have  
a .import
directive (somewhat equivalent to the ELF .type) fail.

Dave
--
John David Anglin    dave.anglin@bell.net

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

[amacleod at redhat dot com]

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.

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

[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 #10 from dave.anglin at bell dot net 2011-11-18 13:24:22 UTC ---
On 17-Nov-11, at 4:49 PM, amacleod at redhat dot com wrote:

> Created attachment 25846
>  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25846
> potential second patch


Testing.  With this change, is_builtin_name could be static.

Dave
--
John David Anglin    dave.anglin@bell.net

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

[amacleod at redhat dot com]

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

--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> 2011-11-25 13:35:19 UTC ---
Author: amacleod
Date: Fri Nov 25 13:35:13 2011
New Revision: 181721

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181721
Log:

2011-11-24  Andrew MacLeod  <amacleod@redhat.com>

    PR other/51011
    * tree.h (is_builtin_name): No longer external.
    * builtins.c (is_builtin_name): Make static.
    * varasm.c (incorporeal_function_p): __sync and __atomic external calls
    are not incorporeal and may need asm label processing.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/tree.h
    trunk/gcc/varasm.c

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

[amacleod at redhat dot com]

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

--- Comment #12 from Andrew Macleod <amacleod at redhat dot com> 2012-01-23 01:48:59 UTC ---
Has this bug been resolved?

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

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #13 from John David Anglin <danglin at gcc dot gnu.org> 2012-01-23 12:54:55 UTC ---
Fixed.