#1333 [gcc-4.4.0] __thread not producing thread-specific storage

OTHER
closed
gcc (462)
fixed
Known_bugs
2013-02-18
2009-08-13
No

gcc-4.4.0-mingw is not producing thread-specific storage when __thread specifier is used.

In the submission source file, a number of threads are created that increment a __thread variable. When all threads have terminated, the "master" thread (original process thread) prints "its" __thread variable to stdout. In the test case, it is non-zero (should be zero since original process thread does not run that code).

-- Details --
Generate tls.exe (test program) with any of the following:
g++ -o tls.exe tls.cpp
g++ -mthreads -o tls.exe tls.cpp
g++ -shared-libgcc -o tls.exe tls.cpp
... etc ...

Compilation generates reference to __emutls_get_address which just returns the same memory address for each thread.

[Build environment]
WinXP Pro SP3
intel harpertown
gcc-4.4.0-mingw32
binutils-2.19.1
w32api-3.13
mingwrt-3.15.2

FYI - Unfortunately, this means that multi-threaded exception handling is broken too (which is how I stumbled onto this).

Discussion

  • Peter Hurley

    Peter Hurley - 2009-08-13

    Submission source file for __thread testing

     
  • Jonathan Liu

    Jonathan Liu - 2009-12-29

    Works with the following compilers using -mthreads option:
    -MinGW GCC 4.4.1 TDM-2
    -Equation Solution GCC 4.4.2 32-bit

     
  • Jonathan Liu

    Jonathan Liu - 2010-01-02

    If the compiler doesn't have shared libraries enabled (as with the previously mentioned compilers) or compiling with -static-libgcc option, the test case seems to run fine.

     
  • Mario Maya

    Mario Maya - 2010-06-24

    Any alternative other than linking libgcc statically? It show me an error at the end of the program (destroying static variables)...

     
  • Peter Hurley

    Peter Hurley - 2010-06-28

    This is probably fixed with the new gcc 4.5.0 release. I saw some dev traffic about this back in Jan-Feb '10 on the mailing list - you should ask there. I seriously doubt a fix will every be backported.

     
  • Pavel Dovgalyuk

    Pavel Dovgalyuk - 2012-04-13

    This bug does not seem to be fixed in 4.6.2.
    Proveded tls.cpp works correctly, but when I alter thread_fn as follows it print equal for several threads:

    unsigned __stdcall thread_fn(void*)
    {
    ++tls_value;
    std::cout << &tls_value << "\n";
    return 0;
    }

    Number of threads (const unsigned processors) was set to 16, which is greater than the number of physical cores.

     
  • Peter Hurley

    Peter Hurley - 2012-04-17

    I have no idea if this bug still exists in mingw. The fact that it's still an open item and includes a test case to validate whether it still exists would seem to indicate that the defect remains.

    @dovgaluk
    The value of tls_value for every thread but the main process thread should be 1. The value of the main process thread should be 0. Regardless, your modification is not stable since the standard library is not required to be thread-safe.

     
  • Earnie Boyd

    Earnie Boyd - 2012-06-14
    • assigned_to: nobody --> ir0nh34d
     
  • Earnie Boyd

    Earnie Boyd - 2012-06-14

    This sounds familiar to another issue. Assigning to Chris for follow up.

     
  • Earnie Boyd

    Earnie Boyd - 2012-06-14
    • milestone: --> Aged_issue
     
  • Earnie Boyd

    Earnie Boyd - 2012-08-03
    • assigned_to: ir0nh34d --> earnie
     
  • Earnie Boyd

    Earnie Boyd - 2012-11-09
    • status: open --> closed-out-of-date
     
  • Earnie Boyd

    Earnie Boyd - 2012-11-09

    As far as I can tell the attached test is working. The main returns 0 for tls_value.

     
  • Earnie Boyd

    Earnie Boyd - 2013-01-29
    • status: closed-out-of-date --> closed
    • resolution: --> fixed
    • category: --> Known_bugs
    • milestone: --> OTHER
     
  • Zach Saw

    Zach Saw - 2013-02-18

    Hi guys,

    What was the fix for this issue? I've stumbled upon the same problem on GCC 4.7.2 / Cygwin.

     
    • Peter Hurley

      Peter Hurley - 2013-02-18

      I suggest reading here first:

      http://mingw-users.1079350.n2.nabble.com/gcc-4-4-multi-threaded-exception-handling-amp-thread-specifier-not-working-td3440749.html

      My interest in this problem ended in this thread:

      http://mingw-users.1079350.n2.nabble.com/gcc-4-4-BUMP-Multi-threaded-exception-handling-broken-td4060049.html

      with this post:

      On Thursday 03 December 2009 16:58:20 Peter Hurley wrote:

      The better solution for this is, use for win9X/ME the old
      mingwm10.dll approach, and for newer OSes just use TLS-callback
      code in dll/exe startup-code.

      Hi Kai but also to the mingw devs,

      The conundrum over switching to TLS callbacks for cleaning up
      exception contexts has paralyzed fixing this problem.

      Hello Peter,

      What exactly do you expect the MinGW devs to do here? There is no
      one associated with this project who maintains a local fork of GCC.
      The only acceptable way to get this fixed is for the solution to be
      ratified upstream, by those responsible for the Win32 branch of GCC
      development itself.

      Danny Smith, who is one of those GCC developers, has already
      explained why the solution you advocate will not fly. While it may
      seem interesting, continued discussion here will not bear fruit;
      this needs to be escalated upstream, on GCC Bugzilla.

      --

      Regards,
      Keith.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks