From: SourceForge.net <no...@so...> - 2009-08-13 17:59:29
|
Bugs item #2837047, was opened at 2009-08-13 13:59 Message generated for change (Tracker Item Submitted) made by peterjhurley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) Assigned to: Nobody/Anonymous (nobody) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SourceForge.net <no...@so...> - 2009-12-29 10:35:26
|
Bugs item #2837047, was opened at 2009-08-14 03:59 Message generated for change (Comment added) made by net147 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) Assigned to: Nobody/Anonymous (nobody) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 21:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SourceForge.net <no...@so...> - 2010-01-02 01:37:30
|
Bugs item #2837047, was opened at 2009-08-14 03:59 Message generated for change (Comment added) made by net147 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) Assigned to: Nobody/Anonymous (nobody) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2010-01-02 12:37 Message: 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. ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 21:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SourceForge.net <no...@so...> - 2010-06-24 11:54:45
|
Bugs item #2837047, was opened at 2009-08-13 19:59 Message generated for change (Comment added) made by mmaya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) Assigned to: Nobody/Anonymous (nobody) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- Comment By: Mario Maya (mmaya) Date: 2010-06-24 13:54 Message: Any alternative other than linking libgcc statically? It show me an error at the end of the program (destroying static variables)... ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2010-01-02 02:37 Message: 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. ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 11:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SourceForge.net <no...@so...> - 2010-06-28 15:12:15
|
Bugs item #2837047, was opened at 2009-08-13 13:59 Message generated for change (Comment added) made by peterhurley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) Assigned to: Nobody/Anonymous (nobody) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2010-06-28 11:12 Message: 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. ---------------------------------------------------------------------- Comment By: Mario Maya (mmaya) Date: 2010-06-24 07:54 Message: Any alternative other than linking libgcc statically? It show me an error at the end of the program (destroying static variables)... ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2010-01-01 20:37 Message: 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. ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 05:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2012-04-13 10:38:36
|
Bugs item #2837047, was opened at 2009-08-13 10:59 Message generated for change (Comment added) made by dovgaluk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) Assigned to: Nobody/Anonymous (nobody) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- Comment By: Pavel Dovgalyuk (dovgaluk) Date: 2012-04-13 03:38 Message: 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. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2010-06-28 08:12 Message: 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. ---------------------------------------------------------------------- Comment By: Mario Maya (mmaya) Date: 2010-06-24 04:54 Message: Any alternative other than linking libgcc statically? It show me an error at the end of the program (destroying static variables)... ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2010-01-01 17:37 Message: 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. ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 02:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2012-04-17 16:58:44
|
Bugs item #2837047, was opened at 2009-08-13 10:59 Message generated for change (Comment added) made by peterhurley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) Assigned to: Nobody/Anonymous (nobody) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2012-04-17 09:58 Message: 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. ---------------------------------------------------------------------- Comment By: Pavel Dovgalyuk (dovgaluk) Date: 2012-04-13 03:38 Message: 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. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2010-06-28 08:12 Message: 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. ---------------------------------------------------------------------- Comment By: Mario Maya (mmaya) Date: 2010-06-24 04:54 Message: Any alternative other than linking libgcc statically? It show me an error at the end of the program (destroying static variables)... ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2010-01-01 17:37 Message: 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. ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 02:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2012-06-14 13:59:01
|
Bugs item #2837047, was opened at 2009-08-13 10:59 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) >Assigned to: Chris Sutcliffe (ir0nh34d) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2012-06-14 06:58 Message: This sounds familiar to another issue. Assigning to Chris for follow up. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2012-04-17 09:58 Message: 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. ---------------------------------------------------------------------- Comment By: Pavel Dovgalyuk (dovgaluk) Date: 2012-04-13 03:38 Message: 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. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2010-06-28 08:12 Message: 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. ---------------------------------------------------------------------- Comment By: Mario Maya (mmaya) Date: 2010-06-24 04:54 Message: Any alternative other than linking libgcc statically? It show me an error at the end of the program (destroying static variables)... ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2010-01-01 17:37 Message: 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. ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 02:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2012-06-14 14:00:19
|
Bugs item #2837047, was opened at 2009-08-13 10:59 Message generated for change (Settings changed) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc >Group: Aged issue Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) Assigned to: Chris Sutcliffe (ir0nh34d) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-06-14 06:58 Message: This sounds familiar to another issue. Assigning to Chris for follow up. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2012-04-17 09:58 Message: 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. ---------------------------------------------------------------------- Comment By: Pavel Dovgalyuk (dovgaluk) Date: 2012-04-13 03:38 Message: 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. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2010-06-28 08:12 Message: 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. ---------------------------------------------------------------------- Comment By: Mario Maya (mmaya) Date: 2010-06-24 04:54 Message: Any alternative other than linking libgcc statically? It show me an error at the end of the program (destroying static variables)... ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2010-01-01 17:37 Message: 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. ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 02:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2012-08-03 19:24:56
|
Bugs item #2837047, was opened at 2009-08-13 10:59 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: Aged issue Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) >Assigned to: Earnie Boyd (earnie) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2012-08-03 12:24 Message: See also https://sourceforge.net/tracker/?func=detail&aid=3322937&group_id=2435&atid=102435 ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-06-14 06:58 Message: This sounds familiar to another issue. Assigning to Chris for follow up. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2012-04-17 09:58 Message: 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. ---------------------------------------------------------------------- Comment By: Pavel Dovgalyuk (dovgaluk) Date: 2012-04-13 03:38 Message: 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. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2010-06-28 08:12 Message: 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. ---------------------------------------------------------------------- Comment By: Mario Maya (mmaya) Date: 2010-06-24 04:54 Message: Any alternative other than linking libgcc statically? It show me an error at the end of the program (destroying static variables)... ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2010-01-01 17:37 Message: 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. ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 02:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |
From: SF/projects/mingw n. l. <min...@li...> - 2012-11-09 20:19:17
|
Bugs item #2837047, was opened at 2009-08-13 10:59 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gcc Group: Aged issue >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Peter Hurley (peterjhurley) Assigned to: Earnie Boyd (earnie) Summary: [gcc-4.4.0] __thread not producing thread-specific storage Initial Comment: 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). ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2012-11-09 12:19 Message: As far as I can tell the attached test is working. The main returns 0 for tls_value. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-08-03 12:24 Message: See also https://sourceforge.net/tracker/?func=detail&aid=3322937&group_id=2435&atid=102435 ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2012-06-14 06:58 Message: This sounds familiar to another issue. Assigning to Chris for follow up. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2012-04-17 09:58 Message: 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. ---------------------------------------------------------------------- Comment By: Pavel Dovgalyuk (dovgaluk) Date: 2012-04-13 03:38 Message: 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. ---------------------------------------------------------------------- Comment By: Peter Hurley (peterhurley) Date: 2010-06-28 08:12 Message: 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. ---------------------------------------------------------------------- Comment By: Mario Maya (mmaya) Date: 2010-06-24 04:54 Message: Any alternative other than linking libgcc statically? It show me an error at the end of the program (destroying static variables)... ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2010-01-01 17:37 Message: 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. ---------------------------------------------------------------------- Comment By: Jonathan Liu (net147) Date: 2009-12-29 02:35 Message: Works with the following compilers using -mthreads option: -MinGW GCC 4.4.1 TDM-2 -Equation Solution GCC 4.4.2 32-bit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2837047&group_id=2435 |