[Bug target/49541] New: [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[Bug target/49541] New: [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

           Summary: [4.6/4.7 regression] TLS support partially broken in
                    64-bit mode
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ebotcazou@gcc.gnu.org
            Target: sparc-sun-solaris2.8


The new TLS support on SPARC/Solaris 8 is partially broken in 64-bit mode. 
This is visible with gcc.dg/tls/opt-12.c:

(botcazou@nile) /nile.build/botcazou/gcc-4.6/sparc-sun-solaris2.8 $ gcc/xgcc
-Bgcc -o opt-12 opt-12.c -fpic -O2 -pthread

(botcazou@nile) /nile.build/botcazou/gcc-4.6/sparc-sun-solaris2.8 $ gcc/xgcc
-Bgcc -o opt-12 opt-12.c -fpic -O2 -pthread -m64
Undefined                       first referenced
 symbol                             in file
__tls_get_addr                      /var/tmp//cc0nZy21.o
ld: fatal: Symbol referencing errors. No output written to opt-12
collect2: ld returned 1 exit status

This is with the Sun linker.  The difference between 32-bit and 64-bit mode is
that the driver inserts -L entries on the link line:

gcc/collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o opt-12 gcc/crt1.o gcc/crti.o
/usr/ccs/lib/values-Xa.o gcc/crtbegin.o -Lgcc -L/usr/ccs/lib
/var/tmp//ccLfjSjm.o -lgcc -lgcc_eh -L/usr/lib/lwp -R/usr/lib/lwp -lpthread
-lthread -lc -lgcc -lgcc_eh -L/usr/lib/lwp -R/usr/lib/lwp -lpthread -lthread
-lc gcc/crtend.o gcc/crtn.o

gcc/collect2 -V -Y P,/usr/lib/sparcv9 -Qy -o opt-12 gcc/sparcv9/crt1.o
gcc/sparcv9/crti.o /usr/ccs/lib/sparcv9/values-Xa.o gcc/sparcv9/crtbegin.o
-Lgcc/sparcv9 -L/usr/ccs/lib/sparcv9 -L/lib/sparcv9 -L/usr/lib/sparcv9 -Lgcc
-L/usr/ccs/lib /var/tmp//ccMywo2Z.o -lgcc -lgcc_eh -L/usr/lib/lwp/64
-R/usr/lib/lwp/64 -lpthread -lthread -lc -lgcc -lgcc_eh -L/usr/lib/lwp/64
-R/usr/lib/lwp/64 -lpthread -lthread -lc gcc/sparcv9/crtend.o
gcc/sparcv9/crtn.o

The problematic one is /lib/sparcv9.  It causes /lib/sparcv9/libthread.so to be
seen before /usr/lib/lwp/sparcv9/libthread.so.  Now the latter provides the
missing symbol __tls_get_addr while the former doesn't (we have the same setup
with /lib/libthread.so and /usr/lib/lwp/libthread.so in 32-bit mode).

This is a regression in the sense that the testcase links with GCC 4.5.x.

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.2

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu.org

--- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-06 08:52:17 UTC ---
Rainer, any idea to solve this?

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-07-06 14:06:59 UTC ---
> --- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-06 08:52:17 UTC ---
> Rainer, any idea to solve this?

One comment up front: It's best to directly Cc: me in PRs, otherwise I
may easily miss them.

It took me some time to understand why this didn't hit me in my S8
bootstraps, but they run in an S8 branded zone, where the alternate
thread library is copied over the default one, so __tls_get_addr is also
found in /lib/sparcv9/libthread.so.

Trying on our only native S8 machine, I see the same failure.

I think the only solution is to move LIB_THREAD_LDFLAGS_SPEC out of
LIB_SPEC (which is way too late, as you've observed) and into or in
front of LINK_ARCH_SPEC where all the other -L/-R flags are passed.

I'll have a look at this.

    Rainer

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.07.13 09:20:38
         AssignedTo|unassigned at gcc dot       |ro at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-13 09:20:38 UTC ---
Created attachment 24750
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24750
proposed patch

This patch seems to do it for me.  It took me some time due to several false
starts. Unfortunately, with gld instead of Sun ld, you don't see the problem.

Since I could only run the bootstrap on a Solaris 8 branded zone where the
default
libthread.so is a copy of the lwp one, could you try it on bare metal to
confirm
that it works?

I'll backport to 4.6 once this is on mainline.

Thanks.
  Rainer

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-13 16:11:25 UTC ---
> Since I could only run the bootstrap on a Solaris 8 branded zone where the
> default libthread.so is a copy of the lwp one, could you try it on bare metal
> to confirm that it works?

Works essentially OK by me.  The only remaining glitches are:

                === libgomp Summary for unix/ ===

# of expected passes            2572
# of unsupported tests          10

Running target unix//-m64
FAIL: libgomp.fortran/condinc2.f  -O  (test for excess errors)
WARNING: libgomp.fortran/condinc2.f  -O  compilation failed to produce
executabl
e
FAIL: libgomp.fortran/condinc4.f90  -O  (test for excess errors)
WARNING: libgomp.fortran/condinc4.f90  -O  compilation failed to produce
executa
ble
FAIL: libgomp.fortran/omp_cond2.f  -O  (test for excess errors)
WARNING: libgomp.fortran/omp_cond2.f  -O  compilation failed to produce
executab
le
FAIL: libgomp.fortran/omp_cond4.F90  -O  (test for excess errors)
WARNING: libgomp.fortran/omp_cond4.F90  -O  compilation failed to produce
execut
able

output is:
Undefined                       first referenced
 symbol                             in file
__tls_get_addr                     
/nile.build/botcazou/gcc-head/sparc-sun-solaris2.8/sparc-sun-solaris2.8/sparcv9/libgomp/.libs/libgomp.so
ld: fatal: Symbol referencing errors. No output written to ./condinc2.exe
collect2: error: ld returned 1 exit status

FAIL: libgomp.fortran/condinc2.f  -O  (test for excess errors


but this is more of a test harness issue: the 4 tests are compiled with the
combination -fno-openmp -lgomp so -pthread isn't added by the driver.

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-07-13 17:56:26 UTC ---
> --- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-13 16:11:25 UTC ---
>> Since I could only run the bootstrap on a Solaris 8 branded zone where the
>> default libthread.so is a copy of the lwp one, could you try it on bare metal
>> to confirm that it works?
>
> Works essentially OK by me.  The only remaining glitches are:

Fine, I'll commit the patch then.

> output is:
> Undefined                       first referenced
>  symbol                             in file
> __tls_get_addr                     
> /nile.build/botcazou/gcc-head/sparc-sun-solaris2.8/sparc-sun-solaris2.8/sparcv9/libgomp/.libs/libgomp.so
> ld: fatal: Symbol referencing errors. No output written to ./condinc2.exe
> collect2: error: ld returned 1 exit status
>
> FAIL: libgomp.fortran/condinc2.f  -O  (test for excess errors
>
>
> but this is more of a test harness issue: the 4 tests are compiled with the
> combination -fno-openmp -lgomp so -pthread isn't added by the driver.

This is strange: in my case, libgomp.so is self-contained and linked
with the right libthread.so which provides __tls_get_addr:

> LD_LIBRARY_PATH=. ldd -r ./libgomp.so.1 
        librt.so.1 =>    /usr/lib/64/librt.so.1
        libgcc_s.so.1 =>         ./libgcc_s.so.1
        libpthread.so.1 =>       /usr/lib/64/libpthread.so.1
        libthread.so.1 =>        /usr/lib/lwp/64/libthread.so.1
        libc.so.1 =>     /usr/lib/64/libc.so.1
        libaio.so.1 =>   /usr/lib/64/libaio.so.1
        libdl.so.1 =>    /usr/lib/64/libdl.so.1
        /usr/platform/SUNW,Sun-Fire-V440/lib/sparcv9/libc_psr.so.1

    Rainer

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-13 17:58:20 UTC ---
Author: ro
Date: Wed Jul 13 17:58:18 2011
New Revision: 176244

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176244
Log:
    PR target/49541
    * config/sol2.h (LIB_SPEC): Simplify.
    Move LIB_THREAD_LDFLAGS_SPEC ...
    (LINK_SPEC): ... here.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/sol2.h

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-13 19:34:48 UTC ---
> This is strange: in my case, libgomp.so is self-contained and linked
> with the right libthread.so which provides __tls_get_addr:
> 
> > LD_LIBRARY_PATH=. ldd -r ./libgomp.so.1 
>         librt.so.1 =>    /usr/lib/64/librt.so.1
>         libgcc_s.so.1 =>         ./libgcc_s.so.1
>         libpthread.so.1 =>       /usr/lib/64/libpthread.so.1
>         libthread.so.1 =>        /usr/lib/lwp/64/libthread.so.1
>         libc.so.1 =>     /usr/lib/64/libc.so.1
>         libaio.so.1 =>   /usr/lib/64/libaio.so.1
>         libdl.so.1 =>    /usr/lib/64/libdl.so.1
>         /usr/platform/SUNW,Sun-Fire-V440/lib/sparcv9/libc_psr.so.1

Same here, but the link line starts with:

/nile.build/botcazou/gcc-head/sparc-sun-solaris2.8/gcc/collect2 -V -Y
P,/lib/sparcv9:/usr/lib/sparcv9 -Qy -o ./condinc2.exe

and this apparently overrides it.

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-07-14 17:08:09 UTC ---
> Same here, but the link line starts with:
>
> /nile.build/botcazou/gcc-head/sparc-sun-solaris2.8/gcc/collect2 -V -Y
> P,/lib/sparcv9:/usr/lib/sparcv9 -Qy -o ./condinc2.exe
>
> and this apparently overrides it.

Not even that: the libgomp.so RUNPATH is completely ignored by ld, but
only evaluated at runtime by ld.so.1.

The problem is that the testsuite (lib/libgomp.exp) unconditionally
links with -lgomp even for the -fno-openmp testcases.  I'd argue that
this is a testsuite-only problem (pilot error, actually) and can be
worked around by use of dg-add-options tls.

    Rainer

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

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

--- Comment #9 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-14 17:37:43 UTC ---
Created attachment 24755
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24755
proposed 4.6 patch

Here's the 4.6 backport of the sol2.h patch.  Could you please give it a try on
Solaris 8 on bare metal?  I've bootstrapped it without regressions on
sparc-sun-solaris2.8 and i386-pc-solaris2.8.

Thanks.
  Rainer

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

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

--- Comment #10 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-14 17:40:06 UTC ---
Created attachment 24757
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24757
proposed libgomp testsuite patch

Here's the libgomp testsuite part of the patch. It should apply to both
mainline
and 4.6 branch.  I've lightly tested the approach by checking one of the
testcases
on sparc-sun-solaris2.8, but on Solaris 8 bare metal the libgomp testsuite
should
now be failure free.

Thanks.
  Rainer

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-15 09:30:09 UTC ---
> Here's the 4.6 backport of the sol2.h patch.  Could you please give it a try on
> Solaris 8 on bare metal?  I've bootstrapped it without regressions on
> sparc-sun-solaris2.8 and i386-pc-solaris2.8.

Works for me, thanks.

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-15 09:31:05 UTC ---
> Here's the libgomp testsuite part of the patch. It should apply to both
> mainline and 4.6 branch.  I've lightly tested the approach by checking one of 
> the testcases on sparc-sun-solaris2.8, but on Solaris 8 bare metal the libgomp
> testsuite should now be failure free.

Confirmed.

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

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

--- Comment #13 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-15 09:39:43 UTC ---
Author: ro
Date: Fri Jul 15 09:39:41 2011
New Revision: 176309

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176309
Log:
    Backport from mainline:
    2011-07-13  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

    PR target/49541
    * config/sol2.h (LIB_SPEC): Simplify.
    Move LIB_THREAD_LDFLAGS_SPEC ...
    (LINK_SPEC): ... here.

Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/config/sol2.h

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-07-15 12:01:02 UTC ---
> The problem is that the testsuite (lib/libgomp.exp) unconditionally
> links with -lgomp even for the -fno-openmp testcases.  I'd argue that
> this is a testsuite-only problem (pilot error, actually) and can be
> worked around by use of dg-add-options tls.

On second thought, it seems better to just remove the explicit -lgomp.

The following patch worked for me on sparc-pc-solaris2.8,
i386-pc-solaris2.10, and x86_64-unknown-linux-gnu:

diff --git a/libgomp/testsuite/lib/libgomp.exp
b/libgomp/testsuite/lib/libgomp.exp
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -137,7 +137,6 @@ proc libgomp_init { args } {
         lappend ALWAYS_CFLAGS "ldflags=-L${blddir}/.libs"
     }
     lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/.."
-    lappend ALWAYS_CFLAGS "ldflags=-lgomp"

     # We use atomic operations in the testcases to validate results.
     if { ([istarget i?86-*-*] || [istarget x86_64-*-*])

    Rainer

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #15 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-15 12:04:20 UTC ---
Jakub, do you see a reason to explicitly add -lgomp to ldflags in the libgomp
testsuite?  According to my testing, -fopenmp should take care of that, as my
testing confirms.

Thanks.
  Rainer

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

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

--- Comment #16 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-18 12:09:22 UTC ---
Author: ro
Date: Mon Jul 18 12:09:18 2011
New Revision: 176393

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176393
Log:
    PR target/49541
    * testsuite/lib/libgomp.exp (libgomp_init): Don't add -lgomp to
    ldflags.

Modified:
    trunk/libgomp/ChangeLog
    trunk/libgomp/testsuite/lib/libgomp.exp

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

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

--- Comment #17 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-18 12:10:39 UTC ---
Author: ro
Date: Mon Jul 18 12:10:34 2011
New Revision: 176394

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176394
Log:
    PR target/49541
    * testsuite/lib/libgomp.exp (libgomp_init): Don't add -lgomp to
    ldflags.

Modified:
    branches/gcc-4_6-branch/libgomp/ChangeLog
    branches/gcc-4_6-branch/libgomp/testsuite/lib/libgomp.exp

[Bug target/49541] [4.6/4.7 regression] TLS support partially broken in 64-bit mode

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

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

--- Comment #18 from Rainer Orth <ro at gcc dot gnu.org> 2011-07-18 12:14:44 UTC ---
Fixed for 4.6.2, 4.7.0.