[Bug libstdc++/55909] New: libtool test exposes what I think is some alignment issue in libstd++

[Bug libstdc++/55909] New: libtool test exposes what I think is some alignment issue in libstd++

[philip.copeland at oracle dot com]

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

             Bug #: 55909
           Summary: libtool test exposes what I think is some alignment
                    issue in libstd++
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: philip.copeland@oracle.com


Created attachment 29107
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29107
Original libtool cpp file

While debugging libtool breakage on sparc64 (64bit Big Endian)

gcc-4.7.2-8.fc18.sparc64
glibc-2.16-28.fc18.sparc64

[mockbuild@localhost 104]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.7.2/lto-wrapper
Target: sparc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128
--with-cpu=ultrasparc --disable-multilib --build=sparc64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) 

-------------------------------------------------------------------------------

++ at_fn_check_prepare_dynamic 'if /builddir/build/BUILD/libtool-2.4.2/libtool
--mode=execute -dlopen m/module.la "./main" ; then :; else lt_status=0;        
    test "Xsparc64-redhat-linux-gnu" != "Xsparc64-redhat-linux-gnu" && test -x
"./main" && exit 77;         exit ; fi' exceptions.at:385
++ case $1 in
++ at_fn_check_prepare_trace exceptions.at:385
++ printf '%s\n' exceptions.at:385
++ at_check_trace=:
++ at_check_filter=:
++ :
++ :
++ at_status=139
++ at_failed=false
++ :
++ echo stderr:
stderr:
++ cat
/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/stderr
++ :
++ /builddir/build/BUILD/libtool-2.4.2/libtool --mode=execute -dlopen
m/module.la ./main
exceptions_in_prog
/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/at-groups/104/test-source:
line 565: 61893 Segmentation fault      (core dumped) $LIBTOOL --mode=execute
-dlopen m/module.la "$lt_exe"
++ lt_status=139

------------------------------------------------------------------------------

This eventually boils down to
[mockbuild@localhost 104]$  /builddir/build/BUILD/libtool-2.4.2/libtool
--verbose --mode=execute -dlopen m/module.la ./.libs/lt-main
exceptions_in_prog
Segmentation fault (core dumped)


[mockbuild@localhost 104]$ gdb ./.libs/lt-main
(gdb) set environment LD_LIBRARY_PATH=m
(gdb) run
exceptions_in_prog

Program received signal SIGSEGV, Segmentation fault.
0xfffff8010061a558 in __frame_dummy_init_array_entry () from
/lib64/libstdc++.so.6
(gdb) where
#0  0xfffff8010061a558 in __frame_dummy_init_array_entry () from
/lib64/libstdc++.so.6
#1  0xfffff80100490988 in __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
#2  0xfffff801004907cc in std::uncaught_exception ()
    at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136
#3  0xfffff801004ccbe4 in ~sentry (this=0x7fefffff1b0, __in_chrg=<optimized
out>)
    at
/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429
#4  std::__ostream_insert<char, std::char_traits<char> > (__out=...,
__s=<optimized out>, 
    __n=<optimized out>)
    at
/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112
#5  0x000000000010321c in operator<< <std::char_traits<char> > (
    __s=0x1085f8 "exceptions_in_prog\n", __out=...)
    at
/usr/lib/gcc/sparc64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ostream:533
#6  exceptions_in_prog () at main.cpp:30
#7  0x0000000000102e78 in main () at main.cpp:120

-------------------------------------------------------------------------------
Lets read that in order with some program text around it that might make some
better sense:

#7  0x0000000000102e78 in main () at main.cpp:120
(gdb) list
115     int main (void)
116     {
117
118       LTDL_SET_PRELOADED_SYMBOLS();
119
120       if (exceptions_in_prog ())
121         return 1;
122       if (exceptions_in_lib ())
123         return 1;
124       if (exceptions_in_module ())

#6  exceptions_in_prog () at main.cpp:30
(gdb) list
25        return 0;
26      }
27
28      int exceptions_in_prog (void)
29      {
30        std::cerr << "exceptions_in_prog\n";
31        try {
32          foo ();
33        }
34        catch (exc e) {

#5  0x000000000010321c in operator<< <std::char_traits<char> > (
    __s=0x1085f8 "exceptions_in_prog\n", __out=...)
    at
/usr/lib/gcc/sparc64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ostream:533
533             __ostream_insert(__out, __s,
(gdb) list
528         operator<<(basic_ostream<char, _Traits>& __out, const char* __s)
529         {
530           if (!__s)
531             __out.setstate(ios_base::badbit);
532           else
533             __ostream_insert(__out, __s,
534                             
static_cast<streamsize>(_Traits::length(__s)));
535           return __out;
536         }
537

(gdb) down
#4  std::__ostream_insert<char, std::char_traits<char> > (__out=...,
__s=<optimized out>,
    __n=<optimized out>)
    at
/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112
112           return __out;
(gdb) list
107                   __throw_exception_again;
108                 }
109               __catch(...)
110                 { __out._M_setstate(__ios_base::badbit); }
111             }
112           return __out;
113         }
114
115       // Inhibit implicit instantiations for required instantiations,
116       // which are defined via explicit instantiations elsewhere.

#3  0xfffff801004ccbe4 in ~sentry (this=0x7fefffff1b0, __in_chrg=<optimized
out>)
    at
/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429
429             if (bool(_M_os.flags() & ios_base::unitbuf) &&
!uncaught_exception())
(gdb) list
424            *  @c flush() on the output stream.
425           */
426           ~sentry()
427           {
428             // XXX MT
429             if (bool(_M_os.flags() & ios_base::unitbuf) &&
!uncaught_exception())
430               {
431                 // Can't call flush directly or else will get into
recursive lock.
432                 if (_M_os.rdbuf() && _M_os.rdbuf()->pubsync() == -1)
433                   _M_os.setstate(ios_base::badbit);

#2  0xfffff801004907cc in std::uncaught_exception ()
    at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136
136       __cxa_eh_globals *globals = __cxa_get_globals ();
(gdb) list
131
132
133     bool
134     std::uncaught_exception() throw()
135     {
136       __cxa_eh_globals *globals = __cxa_get_globals ();
137       return globals->uncaughtExceptions != 0;
138     }

#1  0xfffff80100490988 in __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
63      { return get_global(); }
(gdb) list
58      __cxxabiv1::__cxa_get_globals_fast() _GLIBCXX_NOTHROW
59      { return get_global(); }
60
61      extern "C" __cxa_eh_globals*
62      __cxxabiv1::__cxa_get_globals() _GLIBCXX_NOTHROW
63      { return get_global(); }
64
65
66      #else
67

#0  0xfffff8010061a558 in __frame_dummy_init_array_entry () from
/lib64/libstdc++.so.6
(gdb) list
68      // Single-threaded fallback buffer.
69      static __cxa_eh_globals eh_globals;
70
71      #if __GTHREADS
72
73      static void
74      eh_globals_dtor(void* ptr)
75      {
76        if (ptr)
77          {

-------------------------------------------------------------------------------

I suspect this may be an endian/alignment bug as the same g++ program will run
correctly on an x86_64 system, however my c++ foo is somewhat weak when it
comes to the lower levels. The above is about as far as I can debug this.

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-01-08
            Summary|libtool test exposes what I |libtool test exposes what I
                   |think is some alignment     |think is some alignment
                   |issue in libstd++           |issue in libstdc++
     Ever Confirmed|0                           |1

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-01-08 17:23:34 UTC ---
Whatever it is, I don't think it's a libstdc++ issue: for example, very, very
little happens in terms of alignment vs exceptions in libsupc++. Maybe libgcc?
As far as you can see, is there something wrong in crtstuff.c in terms of
alignments of the various static arrays? Endianness too should not be an
issue...

In any case, we also need a self contained *.ii file to proceed, per the Bug
Reporting instructions.

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #2 from philip.copeland at oracle dot com 2013-01-08 17:59:14 UTC ---
Created attachment 29110
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29110
compressed tarball of .ii files

Adding .ii files as a compressed tarball

[mockbuild@localhost 104]$ ls -l *.ii
-rw-rw-r--. 1 mockbuild mockbuild 277580 Jan  8 12:48 common.ii
-rw-rw-r--. 1 mockbuild mockbuild 475863 Jan  8 12:48 lib.ii
-rw-rw-r--. 1 mockbuild mockbuild 515859 Jan  8 12:48 main.ii
-rw-rw-r--. 1 mockbuild mockbuild 475991 Jan  8 12:48 module.ii

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-01-08 18:45:14 UTC ---
Per the bug submitting instructions we need a *single* self-contained *.ii

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

philip.copeland at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #29110|0                           |1
        is obsolete|                            |

--- Comment #4 from philip.copeland at oracle dot com 2013-01-08 19:00:54 UTC ---
Created attachment 29112
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29112
main.ii

SINGLE .ii
I originally provided all the .ii's produced by the libtool compilation as I
thought it may have been relevant

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |sparc64-redhat-linux

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-09 01:00:41 UTC ---
>0xfffff8010061a558 in __frame_dummy_init_array_entry () from

What is the assembly instruction here?

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-09 01:06:18 UTC ---


*** This bug has been marked as a duplicate of bug 53218 ***

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

philip.copeland at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |WAITING
         Resolution|DUPLICATE                   |

--- Comment #7 from philip.copeland at oracle dot com 2013-01-09 01:33:03 UTC ---
Lets see for frame 0 that would be:

[root@localhost ~]# chroot /var/lib/mock/fc18-5/root/
bash-4.2# su - mockbuild
[mockbuild@localhost ~]$ cd  /builddir/build/BUILD/libtool-2.4.2/
[mockbuild@localhost libtool-2.4.2]$ cd tests/testsuite.dir/104/
(gdb) set environment LD_LIBRARY_PATH=m
(gdb) run
Starting program:
/builddir/build/BUILD/libtool-2.4.2/tests/testsuite.dir/104/.libs/lt-main 
exceptions_in_prog

Program received signal SIGSEGV, Segmentation fault.
0xfffff8010061a558 in __frame_dummy_init_array_entry ()
   from /lib64/libstdc++.so.6
(gdb) disassemble 0xfffff8010061a558
Dump of assembler code for function __frame_dummy_init_array_entry:
   0xfffff8010061a558:  unknown
   0xfffff8010061a55c:  bn  %icc, 0xfffff8010065175c <__ieee754_lgamma_r+2268>
   0xfffff8010061a560:  unknown
   0xfffff8010061a564:  bn  %icc, 0xfffff8010064f264 <__ieee754_j0+612>
   0xfffff8010061a568:  unknown
   0xfffff8010061a56c:  bn  %icc, 0xfffff8010064f36c <__ieee754_j0+876>
   0xfffff8010061a570:  unknown
   0xfffff8010061a574:  bn  %icc, 0xfffff8010064f474 <__ieee754_y0+20>
   0xfffff8010061a578:  unknown
   0xfffff8010061a57c:  bn  %icc, 0xfffff8010064fb7c <qone+92>
   0xfffff8010061a580:  unknown
   0xfffff8010061a584:  bn  %icc, 0xfffff80100650304 <__ieee754_y1+484>
   0xfffff8010061a588:  unknown
   0xfffff8010061a58c:  bn  %icc, 0xfffff80100650a8c <__ieee754_jn+1132>
   0xfffff8010061a590:  unknown
   0xfffff8010061a594:  bn  %icc, 0xfffff80100651014 <__ieee754_lgamma_r+404>
End of assembler dump.

dont think it is a function
(gdb) disassemble __frame_dummy_init_array_entry 
No function contains specified address.
(gdb) whatis __frame_dummy_init_array_entry
type = <data variable, no debug info>
(gdb) print &__frame_dummy_init_array_entry 
$1 = (<data variable, no debug info> *) 0xfffff8010097c150
(gdb) info var __frame_dummy_init_array_entry 
All variables matching regular expression "__frame_dummy_init_array_entry":

Non-debugging symbols:
0x000000000020bd20  __frame_dummy_init_array_entry
0xfffff80100225d78  __frame_dummy_init_array_entry
0xfffff80100329dc0  __frame_dummy_init_array_entry
0xfffff8010042fd80  __frame_dummy_init_array_entry
0xfffff8010061a558  __frame_dummy_init_array_entry
0xfffff80100867d90  __frame_dummy_init_array_entry
0xfffff8010097c150  __frame_dummy_init_array_entry

What does the memory there actually look like?: (assume 8 byte width)
(gdb) x/1xg 0xfffff8010061a558
0xfffff8010061a558:     0xfffff8010048dc80

Ok, since thats a pointer address, where does it lead to? (frame_dummy)
(gdb) disassemble 0xfffff8010048dc80
Dump of assembler code for function frame_dummy:
   0xfffff8010048dc80 <+0>:     save  %sp, -176, %sp
   0xfffff8010048dc84 <+4>:     sethi  %hi(0x5800), %o0
   0xfffff8010048dc88 <+8>:     sethi  %hi(0x192000), %l7
   0xfffff8010048dc8c <+12>:    call  0xfffff8010048dce0
<__sparc_get_pc_thunk.l7>
   0xfffff8010048dc90 <+16>:    add  %l7, 0x374, %l7    ! 0x192374
   0xfffff8010048dc94 <+20>:    xor  %o0, -608, %o0
   0xfffff8010048dc98 <+24>:    add  %l7, %o0, %o0
   0xfffff8010048dc9c <+28>:    ldx  [ %o0 ], %g1
   0xfffff8010048dca0 <+32>:    brz,pn   %g1, 0xfffff8010048dcc0
<frame_dummy+64>
   0xfffff8010048dca4 <+36>:    sethi  %hi(0x800), %g1
   0xfffff8010048dca8 <+40>:    xor  %g1, 0x1a8, %g1
   0xfffff8010048dcac <+44>:    ldx  [ %l7 + %g1 ], %g1
   0xfffff8010048dcb0 <+48>:    brz,pn   %g1, 0xfffff8010048dcc0
<frame_dummy+64>
   0xfffff8010048dcb4 <+52>:    nop 
   0xfffff8010048dcb8 <+56>:    call  %g1
   0xfffff8010048dcbc <+60>:    nop 
   0xfffff8010048dcc0 <+64>:    b  %xcc, 0xfffff8010048dba0
<register_tm_clones>
   0xfffff8010048dcc4 <+68>:    restore 
---Type <return> to continue, or q <return> to quit---
   0xfffff8010048dcc8 <+72>:    b,a   %xcc, 0xfffff8010048dce0
<__sparc_get_pc_thunk.l7>
   0xfffff8010048dccc <+76>:    nop 
   0xfffff8010048dcd0 <+80>:    nop 
   0xfffff8010048dcd4 <+84>:    nop 
   0xfffff8010048dcd8 <+88>:    nop 
   0xfffff8010048dcdc <+92>:    nop 
End of assembler dump.
(gdb) list frame_dummy
No line number known for frame_dummy.


let me try from the #1 frame above and step forward, see where that is going
(gdb) up
#1  0xfffff80100490988 in __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
63      { return get_global(); }
(gdb) disassemble
Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
   0xfffff80100490960 <+0>:     save  %sp, -176, %sp
   0xfffff80100490964 <+4>:     sethi  %hi(0), %o0
   0xfffff80100490968 <+8>:     sethi  %hi(0), %i0
   0xfffff8010049096c <+12>:    sethi  %hi(0x18f400), %l7
   0xfffff80100490970 <+16>:    call  0xfffff8010048dce0
<__sparc_get_pc_thunk.l7>
   0xfffff80100490974 <+20>:    add  %l7, 0x290, %l7    ! 0x18f690
   0xfffff80100490978 <+24>:    add  %o0, 8, %o0
   0xfffff8010049097c <+28>:    xor  %i0, 0, %i0
   0xfffff80100490980 <+32>:    call  0xfffff8010061a558
   0xfffff80100490984 <+36>:    add  %l7, %o0, %o0
=> 0xfffff80100490988 <+40>:    add  %o0, %i0, %i0
   0xfffff8010049098c <+44>:    rett  %i7 + 8
   0xfffff80100490990 <+48>:    nop 
End of assembler dump.

-------------------------------------------------------------------------------

Oh you closed this as a dupe? This was rebuilt using gcc-4.7.2-8 recompiled
with itself at the same level.. and looks like the bug you point to is orphaned
by the reporter. Since Tom's report is for a *32* bit problem and mine is for
64 bit It would seem, on balance, likely an endian issue /may/ have creeped in
(sparc is big endian) that or it's something way different. Just thinking out
loud of possibilities

gcc-4.7.2-8.fc18.sparc64
glibc-2.16-28.fc18.sparc64
binutils-2.23.51.0.1-3.fc18.sparc64

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-01-09 02:24:04 UTC ---
At least now we know that the issue is well known. And in fact it doesn't seem
64-bit specific, FWIW. Let's add Eric in CC for this one too, we are already
providing quite a bit of additional information (beyond PR53218) and we are
available to provide much more.

We should really figure out a much more reduced testcase triggering the
problem... I'm still finding weird that these endianness or alignment issues
affecting exception handling show up only with libtool (or source-highlight):
the usage of exceptions seems pretty basic in such cases, there is more in the
tests but apparently not much about exceptions. Thus I still believe we should
confirm whether the standard GCC C++ testsuite (which includes of course many
exception related testcases) passes smoothly, I don't think people have been
posting anything on gcc-testresults lately.

Eric, any hints?

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #9 from philip.copeland at oracle dot com 2013-01-09 02:32:26 UTC ---
Ooooooo..... <suck breath time>
GCC C++ testsuite,... umm well a quick summary is this,.. it's horrible.

                === g++ Summary ===

# of expected passes            926
# of unexpected failures        38498
# of unexpected successes       75
# of expected failures          190
# of unresolved testcases       6218
# of unsupported tests          1023

Course this has all scrolled WAAAAY back beyond my terminal history so I'll
rerun the whole suite again, tee off the dialog and pin it here as an
attachment.

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #10 from philip.copeland at oracle dot com 2013-01-09 06:09:54 UTC ---
Created attachment 29116
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29116
the gcc 4.7.2-8 srpm mangles the environment a bit but these are the testsuite
results

the Fedora gcc-4.7.2-8 src.rpm mangles the make check environment a bit with a
number of sed re-writes.

In summary the results are better than just casually running make check-c++
from the command line:


                === libstdc++ Summary for unix/ ===
# of expected passes            8434
# of unexpected failures        301
# of expected failures          43
# of unsupported tests          166

                === libstdc++ Summary for unix//-fstack-protector ===
# of expected passes            8434
# of unexpected failures        301
# of expected failures          43
# of unsupported tests          166

                === libstdc++ Summary ===
# of expected passes            16868
# of unexpected failures        602
# of expected failures          86
# of unsupported tests          332

[Note the attachment libstdc++.log.tar.bz2 is 401K but will expand to 51M]

[Bug libstdc++/55909] libtool test exposes what I think is some alignment issue in libstdc++

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-09 06:25:41 UTC ---
(In reply to comment #0)
> I suspect this may be an endian/alignment bug as the same g++ program will run
> correctly on an x86_64 system, however my c++ foo is somewhat weak when it
> comes to the lower levels. The above is about as far as I can debug this.


Note I doubt this is an endian/alignment issue as this works correctly on
big-endian MIPS64 without any issues and also PPC64 (were alignment is not an
issue but is big-endian).

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #12 from philip.copeland at oracle dot com 2013-01-09 06:27:32 UTC ---
Created attachment 29117
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29117
g++.log.tar.bz2 (part1)

                === g++ Summary for unix/ ===

# of expected passes            41197
# of unexpected failures        353
# of expected failures          278
# of unsupported tests          475
                === g++ Summary for unix//-fstack-protector ===

# of expected passes            41197
# of unexpected failures        353
# of expected failures          278
# of unsupported tests          475

                === g++ Summary ===

# of expected passes            82394
# of unexpected failures        706
# of expected failures          556
# of unsupported tests          950

[Note the g++.log.tar.bz2 is 1.3M which is too large for bugzilla so I've split
it into two attachments that can be catted together (g++-split-aa g++-split-ab
>
g++.log)]

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #13 from philip.copeland at oracle dot com 2013-01-09 06:28:26 UTC ---
Created attachment 29118
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29118
g++.log (part 2)

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #14 from philip.copeland at oracle dot com 2013-01-09 08:27:19 UTC ---
Smallest test case program

#include <iostream>
int main()
{
    std::cerr << "we are able to write to stderr\n";
}

bash-4.2# g++ test.c
bash-4.2# ./a.out
we are able to write to stderr
Segmentation fault (core dumped)



#0  0xfffff8010030a558 in __frame_dummy_init_array_entry ()
   from /lib64/libstdc++.so.6
#1  0xfffff80100180988 in __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
#2  0xfffff801001807cc in std::uncaught_exception ()
    at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136
#3  0xfffff801001bcbe4 in ~sentry (this=0x7fefffff0b0, 
    __in_chrg=<optimized out>)
    at
/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429
#4  std::__ostream_insert<char, std::char_traits<char> > (__out=..., 
    __s=__s@entry=0x100a00 "we are able to write to stderr\n", 
    __n=<optimized out>)
    at
/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112
#5  0xfffff801001bcfc4 in std::operator<< <std::char_traits<char> > (
    __out=..., __s=0x100a00 "we are able to write to stderr\n")
    at
/usr/src/debug/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:533
#6  0x000000000010087c in main ()

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #15 from philip.copeland at oracle dot com 2013-01-09 09:06:38 UTC ---
I've a fc17 x86_64 box in the backroom here that I'm going to generate a
comparison trace with

[root@ZenV tmp]# gdb a.out
(gdb) break ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (../../../../libstdc++-v3/libsupc++/eh_globals.cc:63) pending.
(gdb) run
Starting program: /tmp/a.out 
we are able to write to stderr

Breakpoint 1, __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
63      { return get_global(); }
(gdb) where
#0  __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
#1  0x000000354f25e0d9 in std::uncaught_exception ()
    at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:136
#2  0x000000354f295a12 in ~sentry (this=0x7fffffffe360, 
    __in_chrg=<optimized out>)
    at
/usr/src/debug/gcc-4.7.2-20120921/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ostream:429
#3  std::__ostream_insert<char, std::char_traits<char> > (__out=..., 
    __s=__s@entry=0x400870 "we are able to write to stderr\n", __n=31)
    at
/usr/src/debug/gcc-4.7.2-20120921/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112
#4  0x000000354f295d8f in std::operator<< <std::char_traits<char> > (
    __out=..., __s=0x400870 "we are able to write to stderr\n")
    at
/usr/src/debug/gcc-4.7.2-20120921/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/ostream:533
#5  0x000000000040075f in main ()

(gdb) step
std::uncaught_exception ()
    at ../../../../libstdc++-v3/libsupc++/eh_catch.cc:137
137       return globals->uncaughtExceptions != 0;
(gdb) list
132
133     bool
134     std::uncaught_exception() throw()
135     {
136       __cxa_eh_globals *globals = __cxa_get_globals ();
137       return globals->uncaughtExceptions != 0;
138     }

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[mikpe at it dot uu.se]

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

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #16 from Mikael Pettersson <mikpe at it dot uu.se> 2013-01-09 10:13:02 UTC ---
Something is seriously broken in Philip's environment or his gcc-4.7 build.  I
get fairly clean g++/libstdc++ test suite results with vanilla 4.7 on Fedora
15/sparc64 + kernel 3.8-rc2, see e.g.
<http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg00571.html>.

One thing that differs is that my gcc is configured for 32-bit code by default
with the ability to generate 64-bit code when requested
(--target=sparc-unknown-linux --with-cpu=ultrasparc --enable-targets=all),
whereas I assume that Philip's sparc64 rpms are 64-bit binaries generating
64-bit code by default.

I could do a pure 64-bit bootstrap + regtest in a day or two, just to check.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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

--- Comment #17 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-01-09 10:18:34 UTC ---
Thanks Mikael. Thus I suppose the minimized snippet in Comment #14 also runs
fine for you? Indeed, it would be nice if you could try to reproduce the exact
problem Philip is seeing in a pure 64-bit setup.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[mikpe at it dot uu.se]

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

--- Comment #18 from Mikael Pettersson <mikpe at it dot uu.se> 2013-01-09 10:32:35 UTC ---
Yes, the snippet in Comment #14 works fine for me, with both -m32 and -m64.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #19 from philip.copeland at oracle dot com 2013-01-09 10:37:38 UTC ---
Mikael, could you compare against the versions of packages that I'm using?

gcc requires the following according to fedora)
cloog-ppl-0.15.11-4.fc18.1.sparc64
cpp-4.7.2-8.fc18.sparc64
libmpc-0.9-3.fc18.2.sparc64
mpfr-3.0.0-4.fc18.sparc64
gmp-5.0.5-3.fc18.sparc64
binutils-2.23.51.0.1-3.fc18.sparc64
gcc-4.7.2-8.fc18.sparc64
glibc-2.16-28.fc18.sparc64
elfutils-0.155-2.fc18.sparc64 * modified as per
https://bugzilla.redhat.com/attachment.cgi?id=672431&action=diff *

Hurm,.. your build of gcc-4.7.?, was that unmodified or with the slew of RHT
patches that the fc* packages normally gets added, applied?

Thanks

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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

--- Comment #20 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-01-09 10:49:44 UTC ---
Thanks Mikael. Having the testresults for -m32 and -m64 is also nice, by the
way. And they indeed look very good!

Philip's latest testsuite results look decent but worse. Some of those
fails are definitely more convenient than Comment #14, because they don't
include anything.  We should figure out whether Philip is seeing something like
an individual miscompilation in a determinant place, like in crtstuff.c, or
many different problems.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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

--- Comment #21 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-01-09 10:52:07 UTC ---
Philip, from http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg00571.html seems
obvious that Mikael is simply fetching with subversion and building.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #22 from philip.copeland at oracle dot com 2013-01-09 10:59:13 UTC ---
Ok so he's using 4.7.3 not 4.7.2-(butched by fedora folk) (there's about 24
patchs they apply)

ugh,.. what would you like me to do here then? pull over 4.7.3.svn and give
that a spin?

Phil
=--=

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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

--- Comment #23 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-01-09 11:07:10 UTC ---
Oh well, testing the current vanilla 4_7-branch is always a good idea, if you
ask me. That said, it seems very unlikely that back in the 4.7.2 times
something such basic as your reduced Comment #14 could not work (it's the C++
"Hello World!", literally!). Well, we could also bootstrap vanilla 4.7.2 and
see what happens.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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

--- Comment #24 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-01-09 11:51:22 UTC ---
> #1  0xfffff80100490988 in __cxxabiv1::__cxa_get_globals ()
>     at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
> 63      { return get_global(); }
> (gdb) disassemble
> Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
>    0xfffff80100490960 <+0>:     save  %sp, -176, %sp
>    0xfffff80100490964 <+4>:     sethi  %hi(0), %o0
>    0xfffff80100490968 <+8>:     sethi  %hi(0), %i0
>    0xfffff8010049096c <+12>:    sethi  %hi(0x18f400), %l7
>    0xfffff80100490970 <+16>:    call  0xfffff8010048dce0
> <__sparc_get_pc_thunk.l7>
>    0xfffff80100490974 <+20>:    add  %l7, 0x290, %l7    ! 0x18f690
>    0xfffff80100490978 <+24>:    add  %o0, 8, %o0
>    0xfffff8010049097c <+28>:    xor  %i0, 0, %i0
>    0xfffff80100490980 <+32>:    call  0xfffff8010061a558
>    0xfffff80100490984 <+36>:    add  %l7, %o0, %o0
> => 0xfffff80100490988 <+40>:    add  %o0, %i0, %i0
>    0xfffff8010049098c <+44>:    rett  %i7 + 8
>    0xfffff80100490990 <+48>:    nop 

Here's the disassembly for a working version of the compiler:

Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
   0xfffff801001ea7a0 <+0>:     save  %sp, -176, %sp
   0xfffff801001ea7a4 <+4>:     sethi  %hi(0xc00), %o0
   0xfffff801001ea7a8 <+8>:     sethi  %hi(0), %i0
   0xfffff801001ea7ac <+12>:    sethi  %hi(0x129800), %l7
   0xfffff801001ea7b0 <+16>:    call  0xfffff80100182e60
<__sparc_get_pc_thunk.l7>
   0xfffff801001ea7b4 <+20>:    add  %l7, 0x50, %l7     ! 0x129850
=> 0xfffff801001ea7b8 <+24>:    add  %o0, 0x140, %o0
   0xfffff801001ea7bc <+28>:    xor  %i0, 0x10, %i0
   0xfffff801001ea7c0 <+32>:    call  0xfffff80100317c20 <__tls_get_addr@plt>
   0xfffff801001ea7c4 <+36>:    add  %l7, %o0, %o0
   0xfffff801001ea7c8 <+40>:    add  %o0, %i0, %i0
   0xfffff801001ea7cc <+44>:    rett  %i7 + 8
   0xfffff801001ea7d0 <+48>:    nop 

So it looks like the dynamic linker screwed up the PLT on your system.  I think
that you should rebuild the compiler without --enable-initfini-array.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #25 from philip.copeland at oracle dot com 2013-01-09 12:21:19 UTC ---
Mmm yes I did notice the x86_64 trace I did  bounced off into the tls/PLT area
Breakpoint 1, __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
63      { return get_global(); }
(gdb) stepi
0x000000354f25e1a7      63      { return get_global(); }
(gdb) stepi
0x000000354f25a3f0 in __tls_get_addr@plt () from /lib64/libstdc++.so.6
(gdb) stepi
0x000000354f25a3f6 in __tls_get_addr@plt () from /lib64/libstdc++.so.6
(gdb) stepi
0x000000354f25a3fb in __tls_get_addr@plt () from /lib64/libstdc++.so.6
(gdb) stepi
0x000000354f258ff0 in ?? () from /lib64/libstdc++.so.6


where as the sparc went pretty much nowhere 8/

Ok,.. I was mid compiling 4.7.3  but it's a little more convenient to quickly
change 4.7.2-8 as you suggest and give that a quick check,.. should take a few
hours to get that far. I'll update in mm ~3-4 hours I guess

Thanks

Mikael, as reference was your version of 4.7.3 compiled without
--enable-initfini-array ?

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[mikpe at it dot uu.se]

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

--- Comment #26 from Mikael Pettersson <mikpe at it dot uu.se> 2013-01-09 12:42:13 UTC ---
(In reply to comment #19)
> Mikael, could you compare against the versions of packages that I'm using?

Well, my environment is Fedora 15 so all system components are older.  glibc is
2.13.90-4.1 for instance.  The other things that matter for gcc are newer and
compiled and installed privately by myself: gmp-5.0.5, mpfr-3.1.1, mpc-1.0.1,
binutils-2.22, all compiled by my own gcc-4.6.3.

> Hurm,.. your build of gcc-4.7.?, was that unmodified or with the slew of RHT
> patches that the fc* packages normally gets added, applied?

That was with unmodified FSF sources (a weekly svn snapshot tarball).

Note that RH's gcc src rpms are usually (always?) based on RH's own gcc
branches
(see http://gcc.gnu.org/viewcvs/branches/redhat/) rather than vanilla upstream
releases or snapshots, so the amount of modifications are much larger than what
the explicit set of patches indicate.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[mikpe at it dot uu.se]

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

--- Comment #27 from Mikael Pettersson <mikpe at it dot uu.se> 2013-01-09 12:46:11 UTC ---
(In reply to comment #25)
> Mikael, as reference was your version of 4.7.3 compiled without
> --enable-initfini-array ?

Yes.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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

--- Comment #28 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-01-09 14:50:16 UTC ---
Thanks Eric for following this.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #29 from philip.copeland at oracle dot com 2013-01-09 15:29:26 UTC ---
Rebuilt fedoras 4.7.2-8 gcc without --enable-initfini-array reinstalled in a
chroot and rebuilt the test program

bash-4.2# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.7.2/lto-wrapper
Target: sparc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128
--with-cpu=ultrasparc --disable-multilib --build=sparc64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) 

bash-4.2# ./a.out
we are able to write to stderr
Segmentation fault (core dumped)

Breakpoint 1, __cxxabiv1::__cxa_get_globals ()
    at ../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
63      { return get_global(); }
(gdb) disassemble
Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
   0xfffff80100180960 <+0>:     save  %sp, -176, %sp
   0xfffff80100180964 <+4>:     sethi  %hi(0), %o0
   0xfffff80100180968 <+8>:     sethi  %hi(0), %i0
   0xfffff8010018096c <+12>:    sethi  %hi(0x18f400), %l7
   0xfffff80100180970 <+16>:    call  0xfffff8010017db40
<__sparc_get_pc_thunk.l7>
   0xfffff80100180974 <+20>:    add  %l7, 0x290, %l7    ! 0x18f690
=> 0xfffff80100180978 <+24>:    add  %o0, 8, %o0
   0xfffff8010018097c <+28>:    xor  %i0, 0, %i0
   0xfffff80100180980 <+32>:    call  0xfffff8010030a558
   0xfffff80100180984 <+36>:    add  %l7, %o0, %o0
   0xfffff80100180988 <+40>:    add  %o0, %i0, %i0
   0xfffff8010018098c <+44>:    rett  %i7 + 8
   0xfffff80100180990 <+48>:    nop 
End of assembler dump.
(gdb) stepi
0xfffff8010018097c      63      { return get_global(); }
(gdb) 
0xfffff80100180980      63      { return get_global(); }
(gdb) 
0xfffff80100180984      63      { return get_global(); }
(gdb) 
0xfffff8010030a558 in __frame_dummy_init_array_entry ()
   from /lib64/libstdc++.so.6
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0xfffff8010030a558 in __frame_dummy_init_array_entry ()
   from /lib64/libstdc++.so.6

again, no thread level support address actions.
Moving on to rebuild of gcc-trunk (4.7.3?)

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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

--- Comment #30 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-01-09 15:45:35 UTC ---
> Program received signal SIGSEGV, Segmentation fault.
> 0xfffff8010030a558 in __frame_dummy_init_array_entry ()
>    from /lib64/libstdc++.so.6

Is /lib64/libstdc++.so.6 really the rebuilt library?  Can you verify by running
readelf -S on it that it doesn't contain .init_array and .fini_array sections?

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #31 from philip.copeland at oracle dot com 2013-01-09 16:00:56 UTC ---
Hurm,...

bash-4.2# cd  /tmp
bash-4.2# mkdir expand
bash-4.2# cd  expand/
bash-4.2# rpm2cpio /builddir/build/RPMS/libstdc++-4.7.2-8.fc18.sparc64.rpm  |
cpio -id
bash-4.2# md5sum /tmp/expand/usr/lib64/libstdc++.so.6.0.17
/lib64/libstdc++.so.6
2b5b38c3e80e9739b1599df7e6ae84da  /tmp/expand/usr/lib64/libstdc++.so.6.0.17
2b5b38c3e80e9739b1599df7e6ae84da  /lib64/libstdc++.so.6

Well,.. it's definitely the rebuilt library and --enable-initfini-array is not
part of the passed options anymore, however readelf -S shows that those
sections still exist

  [18] .init_array       INIT_ARRAY       00000000001e6558  000e6558
       0000000000000040  0000000000000000  WA       0     0     8
  [19] .fini_array       FINI_ARRAY       00000000001e6598  000e6598
       0000000000000008  0000000000000000  WA       0     0     8
...
  [24] .plt              PROGBITS         00000000001ecc00  000ecc00
       0000000000005820  0000000000000020 WAX       0     0     256

are there any of the options that I used that would reenable initfini-array?

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[paolo.carlini at oracle dot com]

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

--- Comment #32 from Paolo Carlini <paolo.carlini at oracle dot com> 2013-01-09 16:07:19 UTC ---
Well, if you don't pass anything an autoconf test tries to figure out:

--enable-initfini-array
    Force the use of sections .init_array and .fini_array (instead of .init and
.fini) for constructors and destructors. Option --disable-initfini-array has
the opposite effect. If neither option is specified, the configure script will
try to guess whether the .init_array and .fini_array sections are supported
and, if they are, use them.

I would quickly test passing an explicit --disable-initfini-array

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #33 from philip.copeland at oracle dot com 2013-01-09 17:27:18 UTC ---
Ok,. thats 4.8.0 (gcc-trunk) rebuilt and tested.. fails

bash-4.2# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.8.0/lto-wrapper
Target: sparc64-redhat-linux
Configured with: ./configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++ --enable-plugin --with-ppl --with-cloog
--with-long-double-128 --with-cpu=ultrasparc --disable-multilib
--build=sparc64-redhat-linux --disable-initfini-array
Thread model: posix


Breakpoint 1, __cxxabiv1::__cxa_get_globals ()
    at ../../.././libstdc++-v3/libsupc++/eh_globals.cc:63
63      { return get_global(); }
(gdb) stepi
0xfffff801001811fc      63      { return get_global(); }
(gdb) 
0xfffff80100181200      63      { return get_global(); }
(gdb) 
0xfffff80100181204      63      { return get_global(); }
(gdb) 
0xfffff8010030e510 in ?? () from /lib64/libstdc++.so.6

(gdb) disassemble
No function contains program counter for selected frame.
(gdb) x/1xg 0xfffff8010030e510
0xfffff8010030e510:     0xfffff8010017dce0
(gdb) disassemble 0xfffff8010017dce0
Dump of assembler code for function
_GLOBAL__sub_I_compatibility_thread_c__0x.cc(void):
   0xfffff8010017dce0 <+0>:     save  %sp, -176, %sp
   0xfffff8010017dce4 <+4>:     sethi  %hi(0x196000), %l7
   0xfffff8010017dce8 <+8>:     call  0xfffff8010017e4e0
<__sparc_get_pc_thunk.l7>
   0xfffff8010017dcec <+12>:    add  %l7, 0x318, %l7    ! 0x196318
   0xfffff8010017dcf0 <+16>:    call  0xfffff80100316300
<_ZSt15future_categoryv@plt>
   0xfffff8010017dcf4 <+20>:    nop 
   0xfffff8010017dcf8 <+24>:    sethi  %hi(0x800), %g1
   0xfffff8010017dcfc <+28>:    xor  %g1, 0x50, %g1
   0xfffff8010017dd00 <+32>:    ldx  [ %l7 + %g1 ], %g1
   0xfffff8010017dd04 <+36>:    stx  %o0, [ %g1 ]
   0xfffff8010017dd08 <+40>:    rett  %i7 + 8
   0xfffff8010017dd0c <+44>:    nop 
End of assembler dump.
-------------------------------------------------------------------------------
readelf -S /lib64/libstdc++.so.6

There are 41 section headers, starting at offset 0x584f70:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .note.gnu.build-i NOTE             0000000000000200  00000200
       0000000000000024  0000000000000000   A       0     0     4
  [ 2] .gnu.hash         GNU_HASH         0000000000000228  00000228
       0000000000005a1c  0000000000000000   A       3     0     8
  [ 3] .dynsym           DYNSYM           0000000000005c48  00005c48
       0000000000016a58  0000000000000018   A       4     4     8
  [ 4] .dynstr           STRTAB           000000000001c6a0  0001c6a0
       00000000000278e1  0000000000000000   A       0     0     1
  [ 5] .gnu.version      VERSYM           0000000000043f82  00043f82
       0000000000001e32  0000000000000002   A       3     0     2
  [ 6] .gnu.version_d    VERDEF           0000000000045db8  00045db8
       00000000000003f4  0000000000000000   A       4    29     8
  [ 7] .gnu.version_r    VERNEED          00000000000461b0  000461b0
       00000000000000a0  0000000000000000   A       4     3     8
  [ 8] .rela.dyn         RELA             0000000000046250  00046250
       000000000000fc18  0000000000000018   A       3     0     8
  [ 9] .rela.plt         RELA             0000000000055e68  00055e68
       0000000000003e28  0000000000000018   A       3    25     8
  [10] .init             PROGBITS         0000000000059c90  00059c90
       0000000000000048  0000000000000000  AX       0     0     4
  [11] .text             PROGBITS         0000000000059ce0  00059ce0
       00000000000711e0  0000000000000000  AX       0     0     32
  [12] .fini             PROGBITS         00000000000caec0  000caec0
       0000000000000014  0000000000000000  AX       0     0     4
  [13] .rodata           PROGBITS         00000000000caee0  000caee0
       0000000000005e20  0000000000000000   A       0     0     16
  [14] .eh_frame_hdr     PROGBITS         00000000000d0d00  000d0d00
       00000000000048f4  0000000000000000   A       0     0     4
  [15] .eh_frame         PROGBITS         00000000000d55f8  000d55f8
       000000000000eab4  0000000000000000   A       0     0     8
  [16] .gcc_except_table PROGBITS         00000000000e40ac  000e40ac
       00000000000046ba  0000000000000000   A       0     0     4
  [17] .tbss             NOBITS           00000000001ea510  000ea510
       0000000000000020  0000000000000000 WAT       0     0     8
  [18] .init_array       INIT_ARRAY       00000000001ea510  000ea510
       0000000000000038  0000000000000000  WA       0     0     8
  [19] .ctors            PROGBITS         00000000001ea548  000ea548
       0000000000000010  0000000000000000  WA       0     0     8
  [20] .dtors            PROGBITS         00000000001ea558  000ea558
       0000000000000010  0000000000000000  WA       0     0     8
  [21] .jcr              PROGBITS         00000000001ea568  000ea568
       0000000000000008  0000000000000000  WA       0     0     8
  [22] .data.rel.ro      PROGBITS         00000000001ea570  000ea570
       0000000000005870  0000000000000000  WA       0     0     8
  [23] .dynamic          DYNAMIC          00000000001efde0  000efde0
       0000000000000220  0000000000000010  WA       4     0     8
  [24] .got              PROGBITS         00000000001f0000  000f0000
       0000000000000c00  0000000000000008  WA       0     0     8
  [25] .plt              PROGBITS         00000000001f0c00  000f0c00
       0000000000005360  0000000000000020 WAX       0     0     256
  [26] .data             PROGBITS         00000000001f5f60  000f5f60
       00000000000002d0  0000000000000000  WA       0     0     8
  [27] .bss              NOBITS           00000000001f6230  000f6230
       0000000000014910  0000000000000000  WA       0     0     16
  [28] .comment          PROGBITS         0000000000000000  000f6230
       0000000000000055  0000000000000001  MS       0     0     1
  [29] .debug_aranges    PROGBITS         0000000000000000  000f6285
       000000000000b060  0000000000000000           0     0     1
  [30] .debug_info       PROGBITS         0000000000000000  001012e5
       0000000000219760  0000000000000000           0     0     1
  [31] .debug_abbrev     PROGBITS         0000000000000000  0031aa45
       00000000000264a7  0000000000000000           0     0     1
  [32] .debug_line       PROGBITS         0000000000000000  00340eec
       0000000000043052  0000000000000000           0     0     1
  [33] .debug_frame      PROGBITS         0000000000000000  00383f40
       0000000000000510  0000000000000000           0     0     8
  [34] .debug_str        PROGBITS         0000000000000000  00384450
       000000000005829b  0000000000000001  MS       0     0     1
  [35] .debug_loc        PROGBITS         0000000000000000  003dc6eb
       000000000013a849  0000000000000000           0     0     1
  [36] .debug_ranges     PROGBITS         0000000000000000  00516f34
       000000000006de80  0000000000000000           0     0     1
  [37] .gnu.attributes   LOOS+ffffff5     0000000000000000  00584db4
       0000000000000020  0000000000000000   E       0     0     1
  [38] .shstrtab         STRTAB           0000000000000000  00584dd4
       0000000000000195  0000000000000000           0     0     1
  [39] .symtab           SYMTAB           0000000000000000  005859b0
       000000000001ace8  0000000000000018          40   714     8
  [40] .strtab           STRTAB           0000000000000000  005a0698
       000000000002e401  0000000000000000           0     0     1


so
  [10] .init             PROGBITS         0000000000059c90  00059c90
  [12] .fini             PROGBITS         00000000000caec0  000caec0
  [18] .init_array       INIT_ARRAY       00000000001ea510  000ea510
  [25] .plt              PROGBITS         00000000001f0c00  000f0c00
exist and .fini_array has vanished (or been renamed)

Let me ask, is it g++ itself that assembles the header or is it passed off to
elfutils or similar? Meanwhile I'll rebuild 4.7.2-8 with
--disable-initfini-array explicitly set though  I don't think I'm going to see
much difference.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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

--- Comment #34 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-01-09 19:17:00 UTC ---
> so
>   [10] .init             PROGBITS         0000000000059c90  00059c90
>   [12] .fini             PROGBITS         00000000000caec0  000caec0
>   [18] .init_array       INIT_ARRAY       00000000001ea510  000ea510
>   [25] .plt              PROGBITS         00000000001f0c00  000f0c00
> exist and .fini_array has vanished (or been renamed)
> 
> Let me ask, is it g++ itself that assembles the header or is it passed off to
> elfutils or similar? Meanwhile I'll rebuild 4.7.2-8 with
> --disable-initfini-array explicitly set though  I don't think I'm going to see
> much difference.

The (static) linker creates executables or shared libraries from the object
files generated by the compiler and from the system startup files.

What's the system compiler on your machine?  Is there an earlier C++ compiler
that you can install and test?

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #35 from philip.copeland at oracle dot com 2013-01-11 17:19:06 UTC ---
(Sorry for the delay in getting back to you)
I've multipass recompiled all the affected packages associated with gcc/glibc
over the last day which has taken quite some time, to try and be sure that none
of the support packages are deficient.

Paolo directed me to wade through the test-suites to look for anything odd
about the TLS results,.. and nothing seemed to be untoward until he mentioned
that he didn't see any thread_local tests

A bit of headscratching, initially the thought was that
   // { dg-require-effective-target tls }  was false,

however { dg-require-effective-target tls } can't be just false, because the
diag-1.C etc tests from the TLS testsuite were run (successfully).  I need to
understand what triggers the tls support. It can't be that tls isn't supported
because the base compiler I used

gcc-4.4.6-3
glibc-2.12

can compile up the test program with tls and complete successfully.

The only immediate code difference I see which probably has no impact is that
the older 4.4.6 code uses
61      extern "C" __cxa_eh_globals*
62      __cxxabiv1::__cxa_get_globals() throw()
63      { return get_global(); }

whereas the newer 4.7.2 codebase uses
62      __cxxabiv1::__cxa_get_globals() _GLIBCXX_NOTHROW

(can't immediately tell what _GLIBCXX_NOTHROW expands to or comes from, but
I'll work it out)

This is the test program disassembled at the same point when compiled with
older gcc 4.4.6
(gdb) disassemble
Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
   0xfffff801001ee760 <+0>:     save  %sp, -176, %sp
   0xfffff801001ee764 <+4>:     sethi  %hi(0xc00), %o0
   0xfffff801001ee768 <+8>:     sethi  %hi(0), %i0
   0xfffff801001ee76c <+12>:    sethi  %hi(0x12d800), %l7
   0xfffff801001ee770 <+16>:    call  0xfffff801001ee700
   0xfffff801001ee774 <+20>:    add  %l7, 0x90, %l7     ! 0x12d890
=> 0xfffff801001ee778 <+24>:    add  %o0, 0x80, %o0
   0xfffff801001ee77c <+28>:    xor  %i0, 0x10, %i0
   0xfffff801001ee780 <+32>:    call  0xfffff8010031fce0 <__tls_get_addr@plt>
   0xfffff801001ee784 <+36>:    add  %l7, %o0, %o0
   0xfffff801001ee788 <+40>:    add  %o0, %i0, %i0
   0xfffff801001ee78c <+44>:    rett  %i7 + 8
   0xfffff801001ee790 <+48>:    nop 
End of assembler dump.

So tls DID exist and was being used. I think I can assume that tls support
didn't go away for sparc64 in later gcc releases. (I also threw the binary
against readelf -S
[root@localhost ~]# readelf -S /tmp/test | egrep "init|fini|array"
  [11] .init             PROGBITS         0000000000100608  00000608
  [13] .fini             PROGBITS         0000000000100980  00000980

so the older fedora 4.4.6 gcc didn't use initfini-array (if it was even an
available option back then)

So this leaves me in the situation of not understanding what nudges gcc into
supporting tls thread_local etc.It's like it's only partially implemented.

(adding testcase snippet attachment)

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #36 from philip.copeland at oracle dot com 2013-01-11 17:20:35 UTC ---
Created attachment 29149
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29149
g++/gcc testsuite results

g++/gcc testsuite results

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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

--- Comment #37 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-01-11 17:55:38 UTC ---
> So tls DID exist and was being used. I think I can assume that tls support
> didn't go away for sparc64 in later gcc releases. (I also threw the binary
> against readelf -S
> [root@localhost ~]# readelf -S /tmp/test | egrep "init|fini|array"
>   [11] .init             PROGBITS         0000000000100608  00000608
>   [13] .fini             PROGBITS         0000000000100980  00000980
> 
> so the older fedora 4.4.6 gcc didn't use initfini-array (if it was even an
> available option back then)

My gut feeling is that --enable-initfini-array is completely broken.  You need
to find out where the .init_array section comes from for your recompiled
libstdc++.
This could be from the glibc, in which case you need to replace it.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #38 from philip.copeland at oracle dot com 2013-01-12 14:10:52 UTC ---
Ugh,...
well, the good news is that I can now compile this successfully. I didn't even
need to rebuild gcc. (although I will just to follow through on Eric's
suggestion since I didn't find anything terrifically useful as a test for the
initfini-array elf header sections)

Fedora's glibc does not specifically pass --with-tls, and it is assumed that
this is automatically picked up by the configure script (it isn't but I need to
examine that as to why a bit later)

By forcing --with-tls through the configure script and reinstalling the glibc,
g++ seems to notice glibc supporting tls and generates the code necessary for
it.

The rebuilt gcc-4.7.2-8 without initfini-array support produces the same
testsuite results as previously mentioned in #c10 and #c12


+ CC=/builddir/build/BUILD/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/gcc64
+ CFLAGS='-O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mcpu=ultrasparc'
++ echo -O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mcpu=ultrasparc
++ sed 's/ -Wall / /g'
+ CXXFLAGS='-O2 -g -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mcpu=ultrasparc'
+ XCFLAGS='-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mcpu=ultrasparc
'
+ TCFLAGS='-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mcpu=ultrasparc
'
+ GCJFLAGS='-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mcpu=ultraspar
c'
+ ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128
--with-cpu=ultrasparc --disable-multilib --disable-initfini-array
--build=sparc64-redhat-linux

<just in case there was some discrepancy with what was passed into configure
and what got built..>

<mock-chroot>[root@localhost ~]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.7.2/lto-wrapper
Target: sparc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128
--with-cpu=ultrasparc --disable-multilib --disable-initfini-array
--build=sparc64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) 


<mock-chroot>[root@localhost tmp]# g++ test.c -o test
<mock-chroot>[root@localhost tmp]# ./test
we are able to write to stderr
<mock-chroot>[root@localhost tmp]#

also works
however,..

<mock-chroot>[root@localhost tmp]# readelf -S  ./test | egrep "init|fini|array"
  [11] .init             PROGBITS         0000000000100628  00000628
  [13] .fini             PROGBITS         0000000000100b60  00000b60
  [17] .init_array       INIT_ARRAY       0000000000200c78  00000c78

.init_array somehow crept into binary despite being specifically disabled. I
dunno if that was supposed to happen but it hasn't shown any ill effect as yet


So my last thoughts are, what exactly do we loose by not supporting
initfini_array on sparc?
--------------------------------------------------------------------------------
(From various googled sources and the gnu install.texi file):
.init_array
    An array of function pointers that contributes to a single initialization
array for the executable or shared object containing the section.

.fini_array
    An array of function pointers that contribute to a single termination array
for the executable or shared object containing the section."

--enable-initfini-array
Force the use of sections {.init_array} and {.fini_array}
(instead of {.init} and {.fini}) for constructors and
destructors.  Option {--disable-initfini-array} has the
opposite effect.  If neither option is specified, the configure script
will try to guess whether the {.init_array} and
{.fini_array} sections are supported and, if they are, use them.
--------------------------------------------------------------------------------

My reading of this is that .fini and .init will do just fine but only support
one function whereas the *_array sections can store numerous functions. I'm
guessing this is a load efficiency saver for the linker but wouldn't affect
normal program execution speed?

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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

--- Comment #39 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-01-13 09:07:24 UTC ---
> By forcing --with-tls through the configure script and reinstalling the glibc,
> g++ seems to notice glibc supporting tls and generates the code necessary for
> it.

So, in the end, it's glibc not being correctly configured with TLS support?

> My reading of this is that .fini and .init will do just fine but only support
> one function whereas the *_array sections can store numerous functions. I'm
> guessing this is a load efficiency saver for the linker but wouldn't affect
> normal program execution speed?

Yes, this is supposed to improve startup performances.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[philip.copeland at oracle dot com]

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

--- Comment #40 from philip.copeland at oracle dot com 2013-01-13 09:18:16 UTC ---
Seems that way 8/
I do apologise for consuming so much of everyone's time. My only defence being
it wasn't terribly obvious without the comparison of assembler in #24, and an
over reliance on the configure scripts filling in the blanks.

Not sure if that is a deficiency that can be tested for/warned against between
glibc/gcc


Phil
=--=

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #41 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-01-13 09:47:29 UTC ---
> I do apologise for consuming so much of everyone's time. My only defence being
> it wasn't terribly obvious without the comparison of assembler in #24, and an
> over reliance on the configure scripts filling in the blanks.

No need for any apology here.  And you did all the real work...

> Not sure if that is a deficiency that can be tested for/warned against between
> glibc/gcc

Clearly something went wrong on the Fedora side, as I don't understand how they
can ship a glibc without TLS support in 2012.  That's worth reporting to them
(if not already done).  Maybe the TLS detection mechanism could be improved on
the compiler side, but that's not easy when you're not compiling in native
mode.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #42 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-13 11:31:35 UTC ---
TLS is supported in Fedora glibc obviously, the issue is likely with the sorry
state of the Fedora/SPARC port, which is essentially unmaintained.  So it must
be something SPARC specific.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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

--- Comment #43 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-01-30 09:41:52 UTC ---
> TLS is supported in Fedora glibc obviously, the issue is likely with the sorry
> state of the Fedora/SPARC port, which is essentially unmaintained.  So it must
> be something SPARC specific.

This might be related to PR binutils/15056:
  http://sourceware.org/bugzilla/show_bug.cgi?id=15056
which reports that TLS is broken for the SPARC in the latest binutils release.

[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++

[ebotcazou at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc.girod at gmail dot com

--- Comment #44 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-03-27 10:22:44 UTC ---
*** Bug 56734 has been marked as a duplicate of this bug. ***