[Bug libstdc++/52104] New: go1 fails to link on Solaris 8/9 x86 with native TLS

[Bug libstdc++/52104] New: go1 fails to link on Solaris 8/9 x86 with native TLS

[ro at gcc dot gnu.org]

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

             Bug #: 52104
           Summary: go1 fails to link on Solaris 8/9 x86 with native TLS
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ro@gcc.gnu.org
                CC: redi@gcc.gnu.org
              Host: i386-pc-solaris2.[89]
            Target: i386-pc-solaris2.[89]
             Build: i386-pc-solaris2.[89]


Between 20120120 (last build) and 20120202, go1 fails to link on Solaris 8 and
9/x86 when native TLS is in use (the as/ld combination isn't affected):

Undefined                       first referenced
 symbol                             in file
std::function<void ()>::function<void std::call_once<void (std::thread::*)(),
std::reference_wrapper<std::thread> >(std::once_flag&, void
(std::thread::*&&)(),
std::reference_wrapper<std::thread>&&)::{lambda()#1}>(void std::call_once<void
(std::thread::*)(), std::reference_wrapper<std::thread> >(std::once_flag&, void
(std::thread::*&&)(), std::reference_wrapper<std::thread>&&)::{lambda()#1},
std::enable_if<!std::is_integral<void std::call_once<void (std::thread::*)(),
std::reference_wrapper<std::thread> >(std::once_flag&, void
(std::thread::*&&)(),
std::reference_wrapper<std::thread>&&)::{lambda()#1}>::value,
std::function<void ()>::_Useless>::type)
/var/gcc/regression/trunk/8-gcc-gas/build/prev-i386-pc-solaris2.8/libstdc++-v3/src/.libs/libstdc++.a(future.o)
ld: fatal: Symbol referencing errors. No output written to go1
collect2: error: ld returned 1 exit status

  with COLLECT_NO_DEMANGLE=1:

Undefined                       first referenced
 symbol                             in file
_ZNSt8functionIFvvEEC1IZSt9call_onceIMSt6threadFvvEISt17reference_wrapperIS4_EEEvRSt9once_flagOT_DpOT0_EUlvE_EET_NSt9enable_ifIXntsrSt11is_integralISH_E5valueENS1_8_UselessEE4typeE
/var/gcc/regression/trunk/8-gcc-gas/build/prev-i386-pc-solaris2.8/libstdc++-v3/src/.libs/libstdc++.a(future.o)

I'm attaching the .ii and .s files for reference.

I suspect this patch

2012-02-01  Jonathan Wakely  <jwakely.gcc@gmail.com>

    PR libstdc++/49204
    * include/std/future (__future_base::_State_base::wait()): Use lambda
    expression for predicate and remove redundant test.

might be related, but haven't verified yet.

  Rainer

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> 2012-02-03 10:05:14 UTC ---
Created attachment 26560
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26560
preprocessed input

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> 2012-02-03 10:05:57 UTC ---
Created attachment 26561
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26561
assembler input

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-03 10:11:40 UTC ---
Looks as though we need an extra explicit instantiation in src/c++11/future.cc

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-02-03 10:21:03 UTC ---
> --- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-03 10:11:40 UTC ---
> Looks as though we need an extra explicit instantiation in src/c++11/future.cc

Seems so.  This would most likely also resolve a bootstrap failure I'm
seeing on Solaris 10 and 11/x86 with the gas/gld combo:

go1 fails to run with

ld.so.1: go1: fatal: relocation error: R_386_UNKNOWN37: file
/var/gcc/regression/trunk/10-gcc-gas-gld/build/gcc/go1: symbol
_ZSt15__once_callable: offset size (0 bytes) is not supported
gccgo: internal compiler error: Killed (program go1)

That R_386_UNKNOWN37 relocation is R_386_TLS_TPOFF32, not supported even
on Solaris 11.  If I look at the previous (20120127) libstdc++.a (go1 is
linked with -static-libstdc++), I find:

> nm -A libstdc++.a |grep once_callable
libstdc++.a[mutex.o]: [29]      |         0|         4|TLS  |GLOB |0    |8     
|_ZSt15__once_callable

As of 20120202, I get this instead:

libstdc++.a[mutex.o]: [29]      |         0|         4|TLS  |GLOB |0    |8     
|_ZSt15__once_callable
libstdc++.a[future.o]: [144]    |         0|         0|TLS  |GLOB |0    |UNDEF 
|_ZSt15__once_callable

Seems to be the same issue.

    Rainer

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-03 10:48:16 UTC ---
Are you sure this is using native TLS?

This part of the 49204 commit:

    (__future_base::_Async_state_common::_M_join): Serialize attempts to
    join thread.

adds:

    void _M_join() { std::call_once(_M_once, &thread::join, ref(_M_thread)); }

which is called from the destructor, which is defined in future.o

That calls call_once, which creates the missing symbol:

  template<typename _Callable, typename... _Args>
    void
    call_once(once_flag& __once, _Callable&& __f, _Args&&... __args)
    {
#ifdef _GLIBCXX_HAVE_TLS
      auto __bound_functor = std::__bind_simple(std::forward<_Callable>(__f),
          std::forward<_Args>(__args)...);
      __once_callable = &__bound_functor;
      __once_call = &__once_call_impl<decltype(__bound_functor)>;
#else
      unique_lock<mutex> __functor_lock(__get_once_mutex());
      auto __callable = std::__bind_simple(std::forward<_Callable>(__f),
          std::forward<_Args>(__args)...);
      __once_functor = [&]() { __callable(); };
      __set_once_functor_lock_ptr(&__functor_lock);
#endif

So the lambda and std::function are only used when _GLIBCXX_HAVE_TLS is not
defined

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-02-03 10:55:07 UTC ---
> --- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-03 10:48:16 UTC ---
> Are you sure this is using native TLS?

Not anymore ;-(  While Solaris 8 and 9 with gas support native TLS, the
test fails.  config.log shows

configure:26332: checking whether the target supports thread-local storage
configure:26396: /var/gcc/regression/trunk/8-gcc-gas/build/./gcc/xgcc
-B/var/gcc
/regression/trunk/8-gcc-gas/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.8/bin/
-B/v
ol/gcc/i386-pc-solaris2.8/lib/ -isystem /vol/gcc/i386-pc-solaris2.8/include
-isy
stem /vol/gcc/i386-pc-solaris2.8/sys-include    -o conftest -g -O2   conftest.c
 >&5
configure:26396: $? = 0
configure:26396: ./conftest
ld.so.1: conftest: fatal: conftest: object requires TLS, but TLS failed to
initi
alize
/vol/gcc/src/hg/trunk/local/libstdc++-v3/configure[20]: 5945 Killed
configure:26396: $? = 137
configure: program exited with status 137

The problem is with the test, though: before Solaris 10, programs using
native TLS need to be linked with -lthread (which happens implicitly
with -pthread) to get the definition of ___tls_get_addr.

    Rainer

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-03 11:08:47 UTC ---
So fixing that configure test should make the problem go away?

There's still a problem on non-TLS targets though.  I have no idea how to
explicitly instantiate the std::function template constructor for a lambda
type, I don't think it's possible, so it might be necessary to move the
~_Async_state_base destructor into the header file for non-TLS targets.  That
would result in larger object files because the vtable and typeinfo would be
emitted in every object using futures.

And there's still a Solaris 10 problem:

(In reply to comment #4)
> As of 20120202, I get this instead:
> 
> libstdc++.a[mutex.o]: [29]      |         0|         4|TLS  |GLOB |0    |8     
> |_ZSt15__once_callable
> libstdc++.a[future.o]: [144]    |         0|         0|TLS  |GLOB |0    |UNDEF 
> |_ZSt15__once_callable

That symbol is the one used when TLS *is* available.  __once_callable is just a
__thread void* so doesn't need instantiating. 
Why isn't the definition in mutex.o used?

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[ro at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org
   Target Milestone|---                         |4.7.0

--- Comment #8 from Rainer Orth <ro at gcc dot gnu.org> 2012-02-03 13:09:00 UTC ---
(In reply to comment #7)
> So fixing that configure test should make the problem go away?

I'd hope so.  Actually, the problem is in toplevel config/tls.m4
(GCC_CHECK_TLS):
on Solaris 8 and 9, the very first AC_RUN_IFELSE can only work if linked with
-pthread.  I'm uncertain wether to hardcode that as was done in the testsuite
(gcc/testsuite/lib/target-supports.exp (add_options_for_tls)).  Probably
Paolo has a suggestion/preference?

> There's still a problem on non-TLS targets though.  I have no idea how to
> explicitly instantiate the std::function template constructor for a lambda
> type, I don't think it's possible, so it might be necessary to move the
> ~_Async_state_base destructor into the header file for non-TLS targets.  That
> would result in larger object files because the vtable and typeinfo would be
> emitted in every object using futures.

The strange thing is that onSolaris 8 with Sun as/ld, i.e. emutls, everything
seems to work.

> And there's still a Solaris 10 problem:
> 
> (In reply to comment #4)
> > As of 20120202, I get this instead:
> > 
> > libstdc++.a[mutex.o]: [29]      |         0|         4|TLS  |GLOB |0    |8     
> > |_ZSt15__once_callable
> > libstdc++.a[future.o]: [144]    |         0|         0|TLS  |GLOB |0    |UNDEF 
> > |_ZSt15__once_callable
> 
> That symbol is the one used when TLS *is* available.  __once_callable is just a

Right: on Solaris 10 and 11, native TLS is available irrespective of toolchain
used.

> __thread void* so doesn't need instantiating. 
> Why isn't the definition in mutex.o used?

I've no idea: this all works with Sun ld, both with Sun as and gas.  Seems like
a pure gld issue to me (still only occured within the last week).

  Rainer

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-05
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
     Ever Confirmed|0                           |1

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-05 18:39:47 UTC ---
The patch also totally breaks C++ on Solaris 8/9 (SPARC but x86 too I guess).

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-05 19:17:41 UTC ---
Created attachment 26576
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26576
define destructor inline when TLS isn't supported

does this help?

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-02-05 23:27:09 UTC ---
> does this help?

Yes, this yields nominal results again, thanks!

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-05 23:55:56 UTC ---
Author: redi
Date: Sun Feb  5 23:55:51 2012
New Revision: 183920

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183920
Log:
    PR libstdc++/52104
    * include/std/future (__future_base::_Async_state_common): Define
    destructor inline for targets without TLS.
    * src/c++11/future.cc (__future_base::_Async_state_common): Only
    define destructor for TLS targets.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/std/future
    trunk/libstdc++-v3/src/c++11/future.cc

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-06 21:37:09 UTC ---
please let me know what issues remain on Solaris after r183920

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-02-10 15:22:41 UTC ---
> --- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-06 21:37:09 UTC ---
> please let me know what issues remain on Solaris after r183920

Solaris 8/9 works again, but the go1 runtime failure on Solaris 10/11
with gld remains.  But while this is triggered by your patch, it's
ultimately a gld bug.  I've filed

    PR ld/13671
    gld creates i386 relocations not supported by Solaris ld.so.1

for that, while at the same time checking with the Solaris linker
maintainers if it's possible to support the missing relocs directly.

    Rainer

[Bug libstdc++/52104] go1 fails to run on Solaris 10/11 x86 with with gld

[ro at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|i386-pc-solaris2.[89]       |i386-pc-solaris2.1[01]
               Host|i386-pc-solaris2.[89]       |i386-pc-solaris2.1[01]
            Summary|go1 fails to link on        |go1 fails to run on Solaris
                   |Solaris 8/9 x86 with native |10/11 x86 with with gld
                   |TLS                         |
      Known to fail|                            |4.7.0, 4.8.0
              Build|i386-pc-solaris2.[89]       |i386-pc-solaris2.1[01]

--- Comment #15 from Rainer Orth <ro at gcc dot gnu.org> 2012-03-09 16:15:07 UTC ---
The Solaris 8/9 x86 link error is gone, but the go1 failure to run when linked
with gld remains on Solaris 10/11 x86, so adapting summary.

  Rainer

[Bug libstdc++/52104] go1 fails to run on Solaris 10/11 x86 with with gld

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.0                       |4.7.1

--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-22 08:26:51 UTC ---
GCC 4.7.0 is being released, adjusting target milestone.

[Bug libstdc++/52104] go1 fails to run on Solaris 10/11 x86 with with gld

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.1                       |---