[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226 Tatsuyuki Ishi changed: What|Removed |Added CC||ishitatsuyuki at gmail dot com --- Comment #7 from Tatsuyuki Ishi --- I'm suffering from this bug too. It currently break my CI since I can't use clang too due to ABI changes. This is 3 years-old: I hope someone will take a look on it.
[Bug c++/61636] generic lambda "cannot call member function without object"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636 Tatsuyuki Ishi changed: What|Removed |Added CC||ishitatsuyuki at gmail dot com --- Comment #16 from Tatsuyuki Ishi --- This is really annoying. Is the patch going to fix it or nothing has been done?
[Bug ipa/105625] Support .llvm_addrsig section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105625 --- Comment #7 from Tatsuyuki Ishi --- https://sourceware.org/pipermail/binutils/2022-May/121000.html I just posted an initial revision of the patchset for gas.
[Bug lto/105933] New: LTO ltrans object files does not have proper st_bind and st_visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105933 Bug ID: 105933 Summary: LTO ltrans object files does not have proper st_bind and st_visibility Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ishitatsuyuki at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- It looks like the .ltrans.o object files emitted by GCC gold plugin does not specify the `st_bind` and `st_visibility` attributes properly, and instead relies on the linker to somehow carry them over from the information passed from `add_symbols`. This is causing issues in mold (https://github.com/rui314/mold/issues/524), for cases of TLS symbols which uses GNU_UNIQUE instead of WEAK and cannot be overridden. In mold we just throw away the IR object files and symbols once we get the LTO output, doing the name resolution again --- and therefore the assumption made for gold does not hold here. I'd argue this design is not great for debugging as well, as it creates an object file that can be only linked while using the LTO plugin; if the individual object files are directly passed to the linker through command-line, then it results in a duplicate symbols error. On a separate topic, it looks like we're missing COMDAT information as well --- which AFAIK cannot be passed through any of the gold plugin API, unlike `add_symbols`. Due to weird interactions between weak symbols in the main object files and strong symbols in a static library, I think mold requires the COMDAT to deduplicate the sections beforehand in this case, even if it's not strictly necessary by the spec. So we would appreciate if you could include that information in the LTO output too.
[Bug lto/105933] LTO ltrans object files does not have proper st_bind and st_visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105933 --- Comment #2 from Tatsuyuki Ishi --- Created attachment 53164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53164&action=edit A source that fails to link when ltrans is grabbed separatedly and passed to link Here's a minimized test case from the linked mold issue for the purpose of reproducing the issue. For normal LTO usage, it compiles fine with `g++ main.cpp /usr/lib/libboost_fiber.a /usr/lib/libboost_context.a -flto`. We now add `-save-temps` to grab a copy of the ltrans output. Then, we grab the command line used to link through `-v`, then pass the ltrans object to ld directly. It will give you a duplicate symbol error. Exact command line attached below. $ ld --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../.. a.ltrans0.ltrans.o /usr/lib/libboost_fiber.a /usr/lib/libboost_context.a -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/crtn.o ld: /usr/lib/libboost_fiber.a(condition_variable.o):(.tbss._ZGVZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator[_ZGVZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator]+0x0): multiple definition of `guard variable for boost::fibers::detail::spinlock_ttas::lock()::generator'; a.ltrans0.ltrans.o:(.tbss+0x8): first defined here ld: /usr/lib/libboost_fiber.a(condition_variable.o):(.tbss._ZZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator[_ZZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator]+0x0): multiple definition of `boost::fibers::detail::spinlock_ttas::lock()::generator'; a.ltrans0.ltrans.o:(.tbss+0x0): first defined here To ensure successful resolution with GNU_UNIQUE TLS symbols, you need either WEAK symbols or COMDAT groups. GCC ltrans contains neither. When used with the LTO plugin, it inherits the weak st_bind from IR objects, and passes through the fallback WEAK symbols based resolution for duplicate C++ definitions (we usually use COMDAT). When you don't have the LTO plugin, boom, it's a GLOBAL symbol vs UNIQUE symbol which is a conflict without question.
