[Bug c++/90562] New: thread_local variables in inline functions have different addresses across shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90562 Bug ID: 90562 Summary: thread_local variables in inline functions have different addresses across shared libraries Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tudorb at gmail dot com Target Milestone: --- This is reduced from production code. I have an inline function (not "static inline", just "inline") that has a thread_local variable. The thread_local variable has a different address in different shared libraries. Code is at https://github.com/tudor/gcc_tl_bug The function is defined in a.h, and used in a.cc and b.cc. If all files are linked together (as per "mkstatic"), the function has the same address (as per the C++ standard), and so does the thread-local variable: $ ./main-static 0x5583a6b1a790 0x7f9e5acee4fc 0x5583a6b1a790 0x7f9e5acee4fc If a.cc and b.cc are compiled in the different shared libraries (as per "mkshared"), the function still has the same address, but the thread-local variable does not: $ ./main-shared 0x7f501b1d87c0 0x7f501b5e673c 0x7f501b1d87c0 0x7f501b5e6738 This is gcc 7.4.0, Ubuntu 18.04, x86-64. $ gcc --version gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/90562] thread_local variables in inline functions have different addresses across shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90562 --- Comment #1 from Tudor Bosman --- Note that the behavior is correct (the thread local variable has the same address) with -O0, but incorrect with -O1 or above.
[Bug c++/90562] thread_local variables in inline functions have different addresses across shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90562 --- Comment #3 from Tudor Bosman --- The bug also exists in gcc 8.3.0.
[Bug c/81329] New: Missing -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81329 Bug ID: 81329 Summary: Missing -Wmaybe-uninitialized warning Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tudorb at gmail dot com Target Milestone: --- Created attachment 41689 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41689&action=edit Missed maybe-uninitialized warning: test case The attached test case should warn, as foo is used uninitialized if the "atoi(argv[1]) != 0" branch isn't taken. There are no warnings, even with "-Wall -Wextra". Tested with gcc 7.1, both with -O0 and with -O3, see https://godbolt.org/g/J5wRSM
[Bug middle-end/81329] Missing -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81329 --- Comment #2 from Tudor Bosman --- (In reply to Andrew Pinski from comment #1) > There are a few duplicates of this bug floating around. I figured, but I don't know anything about gcc internals to tell which of these duplicates are the same bug and which are different (same symptom, different internal cause).
