https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
--- Comment #7 from Walt Karas ---
I see this problem running in a Docker container on a MacBook. When I try it
on the Mac (clang, Darwin kernel), the output is 2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-linux
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
--- Comment #5 from Alexander Monakov ---
GCC is emitting static_local as @gnu_unique_object, so it should be unified by
the Glibc dynamic linker. You can use 'nm -CD' to check its type after linking
for the main executable and the library to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
--- Comment #4 from Walt Karas ---
(conanrunenv) [root@d761696b8abf VagueDynLink]# cc -O2 -Wall -Wextra -pedantic
-std=c++17 -fno-strict-aliasing -fwrapv -S main.cc
(conanrunenv) [root@d761696b8abf VagueDynLink]# cat main.s
.file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
--- Comment #3 from Walt Karas ---
(conanrunenv) [root@d761696b8abf setup-work]# cc -v
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
Target:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
