[Bug other/39979] New: possible wrong code at -O0.

[Bug other/39979] New: possible wrong code at -O0.

[pluto at agmk dot net]

hi,

i'm currently testing gcc-4.4.1-20090427 on my large c++ codebase.
the application uses threads, contains over 100+ shared components
and the tested debug build (-O0 -g2 -fpic) needs over 2GB of disk space,
so creating reduced testcase at this point isn't trivial thing.

i've observed that boost-1.38.0 and/or stlport-5.2.1 used in this project
are broken by gcc-4.4.1 and trig abort() in glibc malloc checker.
application linked with boost/stlport compiled with gcc-4.3 works fine.

after few hours of valgrinding i've noticed following errors
with gcc-4.4.1/boost/stlport which don't happen with gcc-4.3.


% grep Invalid -A5 valgrind.log.24977                                  
==24977== Invalid write of size 8                                               
==24977==    at 0x327AA0F6D2: _dl_allocate_tls_init (in /lib64/ld-2.5.so)       
==24977==    by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.5.so)                   
==24977==    by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195)       
==24977==    by 0x54D2983:
_ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperIN2au9Function0IvEEEEEEOT_
(thread.hpp:155)
==24977==    by 0x54D2769: ts::MakeThread(au::Function0<void> const&)
(tsMain.cpp:333)                                          
--                                                                              
==24977== Invalid write of size 1                                               
==24977==    at 0x327AA0F6E5: _dl_allocate_tls_init (in /lib64/ld-2.5.so)       
==24977==    by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.5.so)                                         
==24977==    by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195)       
==24977==    by 0x54D2983:
_ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperIN2au9Function0IvEEEEEEOT_
(thread.hpp:155)
==24977==    by 0x54D2769: ts::MakeThread(au::Function0<void> const&)
(tsMain.cpp:333)                                          
--                                                                              
==24977== Invalid write of size 8                                               
==24977==    at 0x327AA0F6D2: _dl_allocate_tls_init (in /lib64/ld-2.5.so)       
==24977==    by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.5.so)                                         
==24977==    by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195)       
==24977==    by 0x54D2A33:
_ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperINS_8functionIFvvEEEEEEEOT_
(thread.hpp:155)
==24977==    by 0x54D27F4: _ZN2ts10MakeThreadERKN5boost8functionIFvvEEE
(tsMain.cpp:339)                                         
--                                                                              
==24977== Invalid write of size 1                                               
==24977==    at 0x327AA0F6E5: _dl_allocate_tls_init (in /lib64/ld-2.5.so)       
==24977==    by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.5.so)                                          
==24977==    by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195)       
==24977==    by 0x54D2A33:
_ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperINS_8functionIFvvEEEEEEEOT_
(thread.hpp:155)
==24977==    by 0x54D27F4: _ZN2ts10MakeThreadERKN5boost8functionIFvvEEE
(tsMain.cpp:339)                                         
--                                                                              
==24977== Invalid read of size 8                                                
==24977==    at 0x20F9E46E: void au::Delete::operator()<es::Port>(es::Port
const*) const (auOpDelete.hpp:13)                     
==24977==    by 0x20F9DBAF: au::Delete
stlpd_std::for_each<stlpd_std::priv::_DBG_iter<stlpd_std::priv::_NonDbg_vector<es::Port*,
stlpd_std::allocator<es::Port*> >,
stlpd_std::priv::_DbgTraits<stlpd_std::priv::_Vector_nonconst_traits<es::Port*,
es::Port**> > >,
au::Delete>(stlpd_std::priv::_DBG_iter<stlpd_std::priv::_NonDbg_vector<es::Port*,
stlpd_std::allocator<es::Port*> >,
stlpd_std::priv::_DbgTraits<stlpd_std::priv::_Vector_nonconst_traits<es::Port*,
es::Port**> > >,
stlpd_std::priv::_DBG_iter<stlpd_std::priv::_NonDbg_vector<es::Port*,
stlpd_std::allocator<es::Port*> >,
stlpd_std::priv::_DbgTraits<stlpd_std::priv::_Vector_nonconst_traits<es::Port*,
es::Port**> > >, au::Delete) (_algo.h:61)                                       
==24977==    by 0x20F99CB4: es::Instance::~Instance() (esInstance.cpp:104)      
==24977==    by 0x20F7EAF5: es::EdifInstance::~EdifInstance()
(esEdifInstance.cpp:27)                                                         
==24977==    by 0x20F7D61C: es::EdifBlackInstance::~EdifBlackInstance()
(esEdifBlackInstance.cpp:21)                                                    
--                                                                              
==24977== Invalid read of size 8                                                
==24977==    at 0x327AA0F575: _dl_tls_get_addr_soft (in /lib64/ld-2.5.so)       
==24977==    by 0x327AF06039: dl_iterate_phdr (in /lib64/libc-2.5.so)           
==24977==    by 0x4D5DBFE: _Unwind_Find_FDE (unwind-dw2-fde-glibc.c:417)        
==24977==    by 0x4D5B042: uw_frame_state_for (unwind-dw2.c:1128)               
==24977==    by 0x4D5BB3A: _Unwind_Backtrace (unwind.inc:290)                   
--                                                                              
==24977== Invalid read of size 8                                                
==24977==    at 0x20F9E46E: void au::Delete::operator()<es::Port>(es::Port
const*) const (auOpDelete.hpp:13)                                               
==24977==    by 0x20F9DBAF: au::Delete
stlpd_std::for_each<stlpd_std::priv::_DBG_iter<stlpd_std::priv::_NonDbg_vector<es::Port*,
stlpd_std::allocator<es::Port*> >,
stlpd_std::priv::_DbgTraits<stlpd_std::priv::_Vector_nonconst_traits<es::Port*,
es::Port**> > >,
au::Delete>(stlpd_std::priv::_DBG_iter<stlpd_std::priv::_NonDbg_vector<es::Port*,
stlpd_std::allocator<es::Port*> >,
stlpd_std::priv::_DbgTraits<stlpd_std::priv::_Vector_nonconst_traits<es::Port*,
es::Port**> > >,
stlpd_std::priv::_DBG_iter<stlpd_std::priv::_NonDbg_vector<es::Port*,
stlpd_std::allocator<es::Port*> >,
stlpd_std::priv::_DbgTraits<stlpd_std::priv::_Vector_nonconst_traits<es::Port*,
es::Port**> > >, au::Delete) (_algo.h:61)                                       
==24977==    by 0x20F99CB4: es::Instance::~Instance() (esInstance.cpp:104)
==24977==    by 0x20F7EAF5: es::EdifInstance::~EdifInstance()
(esEdifInstance.cpp:27)
==24977==    by 0x20F7D61C: es::EdifBlackInstance::~EdifBlackInstance()
(esEdifBlackInstance.cpp:21)
--
==24977== Invalid write of size 1
==24977==    at 0x327AA0F6E5: _dl_allocate_tls_init (in /lib64/ld-2.5.so)
==24977==    by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.5.so)
==24977==    by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195)
==24977==    by 0x54D2A33:
_ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperINS_8functionIFvvEEEEEEEOT_
(thread.hpp:155)
==24977==    by 0x54D27F4: _ZN2ts10MakeThreadERKN5boost8functionIFvvEEE
(tsMain.cpp:339)
--
==24977== Invalid write of size 8
==24977==    at 0x327AA0F6D2: _dl_allocate_tls_init (in /lib64/ld-2.5.so)
==24977==    by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.5.so)
==24977==    by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195)
==24977==    by 0x54D2A33:
_ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperINS_8functionIFvvEEEEEEEOT_
(thread.hpp:155)
==24977==    by 0x54D27F4: _ZN2ts10MakeThreadERKN5boost8functionIFvvEEE
(tsMain.cpp:339)
--
==24977== Invalid read of size 8
==24977==    at 0x327AA0F575: _dl_tls_get_addr_soft (in /lib64/ld-2.5.so)
==24977==    by 0x327AF06039: dl_iterate_phdr (in /lib64/libc-2.5.so)
==24977==    by 0x4D5DBFE: _Unwind_Find_FDE (unwind-dw2-fde-glibc.c:417)
==24977==    by 0x4D5B042: uw_frame_state_for (unwind-dw2.c:1128)
==24977==    by 0x4D5BB3A: _Unwind_Backtrace (unwind.inc:290)
--
==24977== Invalid write of size 1
==24977==    at 0x327AA0F6E5: _dl_allocate_tls_init (in /lib64/ld-2.5.so)
==24977==    by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.5.so)
==24977==    by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195)
==24977==    by 0x54D2983:
_ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperIN2au9Function0IvEEEEEEOT_
(thread.hpp:155)
==24977==    by 0x54D2769: ts::MakeThread(au::Function0<void> const&)
(tsMain.cpp:333)
--
==24977== Invalid write of size 8
==24977==    at 0x327AA0F6D2: _dl_allocate_tls_init (in /lib64/ld-2.5.so)
==24977==    by 0x327BA06732: pthread_create@@GLIBC_2.2.5 (in
/lib64/libpthread-2.5.so)
==24977==    by 0x54E1D0B: boost::thread::start_thread() (thread.cpp:195)
==24977==    by 0x54D2983:
_ZN5boost6threadC1IRN2ts12_GLOBAL__N_118ErrorHandleWrapperIN2au9Function0IvEEEEEEOT_
(thread.hpp:155)
==24977==    by 0x54D2769: ts::MakeThread(au::Function0<void> const&)
(tsMain.cpp:333)


i have no idea how to track this more. any hints?


-- 
           Summary: possible wrong code at -O0.
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-gnu-linux


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

[Bug other/39979] possible wrong code at -O0.

[pluto at agmk dot net]

------- Comment #1 from pluto at agmk dot net  2009-11-12 10:39 -------
empty thread on libc-help:
http://sourceware.org/ml/libc-help/2009-10/msg00043.html


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #2 from pluto at agmk dot net  2010-04-17 13:58 -------
ok, i've tested the boost-1.42.0 libs with the application and
different compiler configuration (4.3/4.4/4.5) and now i'm sure
that libboost-thread.a is broken by 4.4/4.5. i'll dump gcc trees
from that library and compare results asap...


-- 

pluto at agmk dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.4.4 4.5.0
      Known to work|                            |4.3.5
            Summary|possible wrong code at -O0. |possible wrong code at all -
                   |                            |0x levels.


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #3 from pluto at agmk dot net  2010-04-18 13:34 -------
Created an attachment (id=20408)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20408&action=view)
some tree dumps from 4.3/4.5.


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #4 from pluto at agmk dot net  2010-04-18 13:44 -------
during analysis the boost::thread::start_thread() function which causes
invalid writes detected by valgrind i've noticed that gcc-4.5 generates
bigger and more complex code of this function with few more lock'ed opcodes.
afaics gcc-4.5 produces some mess for boost::shared_ptr.
could please someone look at this? it may be a missed optimization or other
bug.


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-04-18 18:30 -------
(In reply to comment #4)
> during analysis the boost::thread::start_thread() function which causes
> invalid writes detected by valgrind i've noticed that gcc-4.5 generates
> bigger and more complex code of this function with few more lock'ed opcodes.
> afaics gcc-4.5 produces some mess for boost::shared_ptr.
> could please someone look at this? it may be a missed optimization or other
> bug.

It seems to be a completely different implementation.

This bug lacks a testcase.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #6 from pluto at agmk dot net  2010-04-18 19:01 -------
Created an attachment (id=20413)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20413&action=view)
testcase.#0.


-- 

pluto at agmk dot net changed:

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


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #7 from pluto at agmk dot net  2010-04-18 19:04 -------
(In reply to comment #5)
> (In reply to comment #4)
> > during analysis the boost::thread::start_thread() function which causes
> > invalid writes detected by valgrind i've noticed that gcc-4.5 generates
> > bigger and more complex code of this function with few more lock'ed opcodes.
> > afaics gcc-4.5 produces some mess for boost::shared_ptr.
> > could please someone look at this? it may be a missed optimization or other
> > bug.
> 
> It seems to be a completely different implementation.
> 
> This bug lacks a testcase.
> 

i've atatched the first testcase for this bug. gcc43 and gcc44/45 generate
completely different code for the boost::thread::start_thread function.


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #8 from pluto at agmk dot net  2010-04-18 20:28 -------
debbuging 4.3 vs 4.5 start_thread() shows different results:

4.3:

182x     void thread::start_thread()
183x     {
184x         thread_info->self=thread_info;
185t>        int const res = pthread_create(&thread_info->thread_handle, 0,
&thread_proxy, thread_info.get());

(gdb) p *this->thread_info.pn.pi_
{
  _vptr.sp_counted_base = 0x7ffff767e6d0,
  use_count_ = 1,
  weak_count_ = 2
}
(gdb) n
(gdb) p *this->thread_info.pn.pi_
{
  _vptr.sp_counted_base = 0x7ffff767e6d0,
  use_count_ = 2,
  weak_count_ = 2
}

on 4.5:

(gdb) p *this->thread_info.pn.pi_
{
  _vptr.sp_counted_base = 0x7ffff767ead0,
  use_count_ = 1,
  weak_count_ = 2
}
(gdb) n
(gdb) p *this->thread_info.pn.pi_
Cannot access memory at address 0x30

as you can see, the 4.5 code does bad things.


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2010-04-18 20:32 -------
(In reply to comment #8)
> debbuging 4.3 vs 4.5 start_thread() shows different results:
> 
> 4.3:
> 
> 182x     void thread::start_thread()
> 183x     {
> 184x         thread_info->self=thread_info;
> 185t>        int const res = pthread_create(&thread_info->thread_handle, 0,
> &thread_proxy, thread_info.get());
> 
> (gdb) p *this->thread_info.pn.pi_
> {
>   _vptr.sp_counted_base = 0x7ffff767e6d0,
>   use_count_ = 1,
>   weak_count_ = 2
> }
> (gdb) n
> (gdb) p *this->thread_info.pn.pi_
> {
>   _vptr.sp_counted_base = 0x7ffff767e6d0,
>   use_count_ = 2,
>   weak_count_ = 2
> }
> 
> on 4.5:
> 
> (gdb) p *this->thread_info.pn.pi_
> {
>   _vptr.sp_counted_base = 0x7ffff767ead0,
>   use_count_ = 1,
>   weak_count_ = 2
> }
> (gdb) n
> (gdb) p *this->thread_info.pn.pi_
> Cannot access memory at address 0x30
> 
> as you can see, the 4.5 code does bad things.

it just means that the debugger uses a this variable which is currently NULL.
So maybe wrong-debug information.

The testcase is btw a too twisted maze.  Can you wrap up a simple main()
so that it fails at runtime?


-- 


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

[Bug other/39979] possible wrong code at all -0x levels.

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2010-04-18 20:33 -------
Oh, and does it fail with http://gcc.gnu.org/bugzilla/attachment.cgi?id=20394
applied?


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
            Summary|possible wrong code at all -|[4.4/4.5/4.6 Regression]
                   |0x levels.                  |possible wrong code at all -
                   |                            |0x levels.
   Target Milestone|---                         |4.4.4


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

[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #11 from pluto at agmk dot net  2010-04-19 11:44 -------
(In reply to comment #9)

> The testcase is btw a too twisted maze.  Can you wrap up a simple main()
> so that it fails at runtime?

i'll try to reduce it to something human readable...


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #12 from pluto at agmk dot net  2010-04-19 11:44 -------
(In reply to comment #10)
> Oh, and does it fail with http://gcc.gnu.org/bugzilla/attachment.cgi?id=20394
> applied?

this patch didn't help.


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #13 from pluto at agmk dot net  2010-04-20 12:20 -------
(In reply to comment #5)
> (In reply to comment #4)
> > during analysis the boost::thread::start_thread() function which causes
> > invalid writes detected by valgrind i've noticed that gcc-4.5 generates
> > bigger and more complex code of this function with few more lock'ed opcodes.
> > afaics gcc-4.5 produces some mess for boost::shared_ptr.
> > could please someone look at this? it may be a missed optimization or other
> > bug.
> 
> It seems to be a completely different implementation.

it's a missed inlining optimization in 4.5.
i'll fill a separate PR for this issue.


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.4                       |4.4.5


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

[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #14 from pluto at agmk dot net  2010-05-11 22:50 -------
few hours of git-bisecting and i have first bad commit:

3bfe8549d7fd3c67c90f64e76cbf60daae1e211c is the first bad commit
commit 3bfe8549d7fd3c67c90f64e76cbf60daae1e211c
Author: bkoz <bkoz@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Tue Jan 13 01:49:30 2009 +0000

    2009-01-12  Benjamin Kosnik  <bkoz@redhat.com>

        PR libstdc++/38384
        * crossconfig.m4 (hpux): Update for 10.20, 11, 11.20.
        * configure: Regenerate.

    2009-01-12  Benjamin Kosnik  <bkoz@redhat.com>

        * crossconfig.m4 (linux): Add GCC_CHECK_TLS to define
_GLIBCXX_HAVE_TLS.
        Use GLIBCXX_CHECK_COMPILER_FEATURES to compute SECTION_FLAGS.

    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@143322
138bc75d-0d04-0410-961f-82ee72b054a4

this change in some way breaks static version of STLport-5.2.1 used in my app.
i'll check parts of this commit...


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #15 from pluto at agmk dot net  2010-05-12 13:57 -------
the problematic is eh_globals.o which was merged into libstlport.a.
the TLS version of the get_globals causes memory corruption in my app.


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.

[pluto at agmk dot net]

------- Comment #16 from pluto at agmk dot net  2010-05-12 20:27 -------
(In reply to comment #15)
> the problematic is eh_globals.o which was merged into libstlport.a.
> the TLS version of the get_globals causes memory corruption in my app.
> 

strictly, the __thread based eh_globals.cc doesn't work with pthread based
stlport-5.2.1. libsupc++ configured with --disable-tls (forced tls via
pthread get/set specific) works fine with stlport again.


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.

[pinskia at gcc dot gnu dot org]

------- Comment #17 from pinskia at gcc dot gnu dot org  2010-05-12 20:54 -------
Not a bug, you need to configure libstdc++ and stlport the same if you want
them to work together.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.

[pluto at agmk dot net]

------- Comment #18 from pluto at agmk dot net  2010-05-13 09:13 -------
(In reply to comment #17)
> Not a bug, you need to configure libstdc++ and stlport the same if you want
> them to work together.

__thread/pthread in eh_globals.cc is an implemetation detail.
how this could conflicts with pthread-based stlport?


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.

[redi at gcc dot gnu dot org]

------- Comment #19 from redi at gcc dot gnu dot org  2010-05-13 10:24 -------
(In reply to comment #15)
> the problematic is eh_globals.o which was merged into libstlport.a.

If stlport imports files which are implementation details, then it depends on
those implementation details. isn't that obvious?

If that's by design, then as Andrew said you need to reconfigure stlport.
If it's not by design, it's an stlport bug.


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.

[pluto at agmk dot net]

------- Comment #20 from pluto at agmk dot net  2010-05-13 10:46 -------
(In reply to comment #19)
> (In reply to comment #15)
> > the problematic is eh_globals.o which was merged into libstlport.a.
> 
> If stlport imports files which are implementation details, then it depends on
> those implementation details. isn't that obvious?
> 
> If that's by design, then as Andrew said you need to reconfigure stlport.
> If it's not by design, it's an stlport bug.

stlport includes some gcc archives in libstlport.a for simplier linking
of stlport-based applications. users just type '-lstlport' and all is linked :)
i see only references to __cxa_finalize in stlport code but this doesn't
touch eh_globals.cc. i'll check this deeply...


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.

[redi at gcc dot gnu dot org]

------- Comment #21 from redi at gcc dot gnu dot org  2010-05-13 11:29 -------
(In reply to comment #20)
> 
> stlport includes some gcc archives in libstlport.a for simplier linking

for some definition of "simpler" :)

Either  don't use static linking or rebuild libstlport.a with the gcc version
you plan to use. This isn't a gcc bug though.


-- 


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

[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.

[peterf at silvaco dot com]

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

Peter Foelsche <peterf at silvaco dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peterf at silvaco dot com

--- Comment #22 from Peter Foelsche <peterf at silvaco dot com> 2012-04-26 23:52:02 UTC ---
does this mean, that I need to configure g++ in a certain way in case of I want
to use pthread?