[Bug binutils/19722] [libopcodes] [Aarch64] Undefined SIMD instruction not marked undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=19722 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi, Are you sure that you are not seeing an error for this instruction ? When I assemble it using either the current development sources, or the latest version of the sources on the 2.26 branch, I get: Warning: unpredictable transfer with writeback -- `ldpsw x12,x6,[x6],#-8' Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19480] [2.26.51 regression] ld creates wrong output for libstdc++6.dll for mingw32 (32-bit)
https://sourceware.org/bugzilla/show_bug.cgi?id=19480 --- Comment #9 from Stephen Kitt --- For completeness' sake I tried patch 7 from #19803 too, and I get the same build log. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19795] LD crash on mipsel aborting at ../../bfd/merge.c:909 in _bfd_merged_section_offset
https://sourceware.org/bugzilla/show_bug.cgi?id=19795 --- Comment #2 from Gianfranco --- Hi Nick, unfortunately I don't know how to create a small testcase. The failure seems to happen when a lot of .a static libraries are tried to be linked together. I extracted them with some scripting, and put them in a tarball 1,9G mar 19 22:12 foo.tar.gz so maybe the regression is in llvm, because the new 3.8 version tries to link 2 GB of static libraries, and I'm sure the failure is not really a bug :p the old build was linking them dynamically. I think you can close if you want! Sorry for the noise, Gianfranco /usr/bin/g++-5 -fPIC -std=c++0x -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -O2 -g -DNDEBUG -Wl,-O3 -Wl,--gc-sections -Wl,-z,relro -Wl,-z,defs -shared -Wl,-soname,libLLVM-3.8.so.1 -o ../../lib/libLLVM-3.8.so.1 CMakeFiles/LLVM.dir/libllvm.cpp.o -Wl,--whole-archive ../../lib/libLLVMSupport.a ../../lib/libLLVMCore.a ../../lib/libLLVMIRReader.a ../../lib/libLLVMCodeGen.a ../../lib/libLLVMSelectionDAG.a ../../lib/libLLVMAsmPrinter.a ../../lib/libLLVMMIRParser.a ../../lib/libLLVMBitReader.a ../../lib/libLLVMBitWriter.a ../../lib/libLLVMTransformUtils.a ../../lib/libLLVMInstrumentation.a ../../lib/libLLVMInstCombine.a ../../lib/libLLVMScalarOpts.a ../../lib/libLLVMipo.a ../../lib/libLLVMVectorize.a ../../lib/libLLVMObjCARCOpts.a ../../lib/libLLVMLinker.a ../../lib/libLLVMAnalysis.a ../../lib/libLLVMLTO.a ../../lib/libLLVMMC.a ../../lib/libLLVMMCParser.a ../../lib/libLLVMMCDisassembler.a ../../lib/libLLVMObject.a ../../lib/libLLVMOption.a ../../lib/libLLVMDebugInfoCodeView.a ../../lib/libLLVMDebugInfoDWARF.a ../../lib/libLLVMDebugInfoPDB.a ../../lib/libLLVMSymbolize.a ../../lib/libLLVMExecutionEngine.a ../../lib/libLLVMInterpreter.a ../../lib/libLLVMMCJIT.a ../../lib/libLLVMOrcJIT.a ../../lib/libLLVMRuntimeDyld.a ../../lib/libLLVMTarget.a ../../lib/libLLVMAArch64CodeGen.a ../../lib/libLLVMAArch64Info.a ../../lib/libLLVMAArch64AsmParser.a ../../lib/libLLVMAArch64Disassembler.a ../../lib/libLLVMAArch64AsmPrinter.a ../../lib/libLLVMAArch64Desc.a ../../lib/libLLVMAArch64Utils.a ../../lib/libLLVMAMDGPUCodeGen.a ../../lib/libLLVMAMDGPUAsmParser.a ../../lib/libLLVMAMDGPUAsmPrinter.a ../../lib/libLLVMAMDGPUInfo.a ../../lib/libLLVMAMDGPUDesc.a ../../lib/libLLVMAMDGPUUtils.a ../../lib/libLLVMARMCodeGen.a ../../lib/libLLVMARMInfo.a ../../lib/libLLVMARMAsmParser.a ../../lib/libLLVMARMDisassembler.a ../../lib/libLLVMARMAsmPrinter.a ../../lib/libLLVMARMDesc.a ../../lib/libLLVMBPFCodeGen.a ../../lib/libLLVMBPFAsmPrinter.a ../../lib/libLLVMBPFInfo.a ../../lib/libLLVMBPFDesc.a ../../lib/libLLVMCppBackendCodeGen.a ../../lib/libLLVMCppBackendInfo.a ../../lib/libLLVMHexagonCodeGen.a ../../lib/libLLVMHexagonAsmParser.a ../../lib/libLLVMHexagonInfo.a ../../lib/libLLVMHexagonDesc.a ../../lib/libLLVMHexagonDisassembler.a ../../lib/libLLVMMipsCodeGen.a ../../lib/libLLVMMipsAsmPrinter.a ../../lib/libLLVMMipsDisassembler.a ../../lib/libLLVMMipsInfo.a ../../lib/libLLVMMipsDesc.a ../../lib/libLLVMMipsAsmParser.a ../../lib/libLLVMMSP430CodeGen.a ../../lib/libLLVMMSP430AsmPrinter.a ../../lib/libLLVMMSP430Info.a ../../lib/libLLVMMSP430Desc.a ../../lib/libLLVMNVPTXCodeGen.a ../../lib/libLLVMNVPTXInfo.a ../../lib/libLLVMNVPTXAsmPrinter.a ../../lib/libLLVMNVPTXDesc.a ../../lib/libLLVMPowerPCCodeGen.a ../../lib/libLLVMPowerPCAsmParser.a ../../lib/libLLVMPowerPCDisassembler.a ../../lib/libLLVMPowerPCAsmPrinter.a ../../lib/libLLVMPowerPCInfo.a ../../lib/libLLVMPowerPCDesc.a ../../lib/libLLVMSparcCodeGen.a ../../lib/libLLVMSparcInfo.a ../../lib/libLLVMSparcDesc.a ../../lib/libLLVMSparcAsmPrinter.a ../../lib/libLLVMSparcAsmParser.a ../../lib/libLLVMSparcDisassembler.a ../../lib/libLLVMSystemZCodeGen.a ../../lib/libLLVMSystemZAsmParser.a ../../lib/libLLVMSystemZDisassembler.a ../../lib/libLLVMSystemZAsmPrinter.a ../../lib/libLLVMSystemZInfo.a ../../lib/libLLVMSystemZDesc.a ../../lib/libLLVMX86CodeGen.a ../../lib/libLLVMX86AsmParser.a ../../lib/libLLVMX86Disassembler.a ../../lib/libLLVMX86AsmPrinter.a ../../lib/libLLVMX86Desc.a ../../lib/libLLVMX86Info.a ../../lib/libLLVMX86Utils.a ../../lib/libLLVMXCoreCodeGen.a ../../lib/libLLVMXCoreDisassembler.a ../../lib/libLLVMXCoreAsmPrinter.a ../../lib/libLLVMXCoreInfo.a ../../lib/libLLVMXCoreDesc.a ../../lib/libLLVMAsmParser.a ../../lib/libLLVMLineEditor.a ../../lib/libLLVMProfileData.a ../../lib/libLLVMPasses.a ../../lib/libLLVMLibDriver.a -Wl,--no-whole-archive ../../lib/libLLVMObjCARCOpts.a ../../lib/libLLVMDebugInfoDWARF.a ../../lib/libLLVMDebugInfoPDB.a -lffi ../../lib/libLLVMExecutionEngine.a ../../lib/libLLVMRuntimeDyld.a ../../lib/libLLVMAArch64Info.a ../../lib/libLLVMAArch64AsmPrinter.a ../../lib/libLLVMAArch64Utils.a ../../lib/libLLVMAMDGPUAsmPrinter.a ../../lib/libLLVMAMDGPUInfo.a
[Bug gold/19842] LTO build fails to write call address for weak symbol reference
https://sourceware.org/bugzilla/show_bug.cgi?id=19842 Cary Coutant changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Cary Coutant --- The std::function destructor is defined as a pair of comdat symbols in SystemExit.o (compiled with LTO): SYMBOLS: 82 out/haswell/main/SystemExit.o 0: WD D _ZNSt8functionIFvvEED2Ev [comdat: _ZNSt8functionIFvvEED5Ev] 1: WD D _ZNSt8functionIFvvEED1Ev [comdat: _ZNSt8functionIFvvEED5Ev] and also in Server.cpp.o (not compiled with LTO): 2096: 27 FUNCWEAK DEFAULT 846 _ZNSt8functionIFvvEED2Ev 2097: 27 FUNCWEAK DEFAULT 846 _ZNSt8functionIFvvEED1Ev These are also declared in the _ZNSt8functionIFvvEED5Ev comdat group. (Because the D1 and D2 destructors are the same for this case, the two symbols are simply aliased to each other.) The call from std::_List_node >::~_List_node() is to the D1 destructor: Relocation section '.rela.text._ZNSt10_List_nodeISt8functionIFvvEEED2Ev' at offset 0x1446b0 contains 1 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0018 08310004 R_X86_64_PLT32 _ZNSt8functionIFvvEED1Ev - 4 When processing SystemExit.o, the plugin claims it, and provides those two symbols to the linker. This is the first instance of a _ZNSt8functionIFvvEED5Ev comdat group, so the linker treats this as the "kept" group. When we later see Server.cpp.o, we discard its copy of that comdat group, and the reference to the destructor is expected to resolve to the earlier definition. When the LTO plugin is ready to generate final code, it asks the linker for the status of those two symbols, and is told (via the -lm.res file): out/haswell/main/SystemExit.o 82 10879 24ebb94a838bed5c PREVAILING_DEF _ZNSt8functionIFvvEED2Ev 10842 24ebb94a838bed5c PREVAILING_DEF _ZNSt8functionIFvvEED1Ev PREVAILING_DEF indicates that the IR contains a prevailing definition of the symbol, but that there are references to that symbol from outside the set of IR code (i.e., from Server.cpp.o). That tells the plugin that the compiler must generate a global definition of those symbols. (If there were no other references to the symbol, the resolution would have been PREVAILING_DEF_IRONLY. That would have allowed the compiler to generate a local definition.) But when the compiler sends back the generated file hippo.ltrans1.ltrans.o, it has defined these symbols as local: 30: 027033 FUNCLOCAL DEFAULT1 _ZNSt8functionIFvvEED2Ev 32: 027033 FUNCLOCAL DEFAULT1 _ZNSt8functionIFvvEED1Ev As a result, the "placeholder" symbols that the linker has kept remain undefined, and we end up resolving the reference from Server.cpp.o to 0. Gold should not be silently resolving this symbol to 0 -- instead, it should diagnose the compiler's failure to provide the expected definition and print an error message. I don't know how or why Gnu ld is resolving the symbol; I would expect the same behavior from it. So it looks to me (at the moment, at least) like this is a GCC bug. I'll try to come up with a simple test case, but it's often hard to reproduce the exact set of conditions that cause the optimizer to make a particular decision. It's possible this has been fixed since GCC 5.2 -- have you tried a newer GCC? -cary -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19842] LTO build fails to write call address for weak symbol reference
https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #5 from Matt Godbolt --- Wow! What an awesome diagnosis: thank you so much for digging in to this! I've tried with GCC 5.3.0 but not any GCC 6+ snapshots. The GCC guys on the mailing list didn't seem to think it was a GCC bug initially but this seems to be fairly conclusive. I can definitely try with the 6+ snapshot but as you may imagine building everything with the same version of GCC is a bit of an undertaking. I will at least try building hippo with GCC6 (and hope there aren't any other ABI differences that cause issue). I tried hard to repro this too: the optimizer seemed to make different decisions with a trivially small LTO program: I couldn't get it to happen. Perhaps if you could raise this on the relevant GCC list? Of course I'd be happy to do so too but I'd hate to get any details wrong! You've already been more than helpful! Thanks so much for spending your weekend on a very obscure issue! Matt On Sun, Mar 20, 2016 at 2:58 PM ccoutant at gmail dot com < sourceware-bugzi...@sourceware.org> wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=19842 > > Cary Coutant changed: > >What|Removed |Added > > > Status|NEW |ASSIGNED > > --- Comment #4 from Cary Coutant --- > The std::function destructor is defined as a pair of comdat symbols in > SystemExit.o (compiled with LTO): > > SYMBOLS: 82 out/haswell/main/SystemExit.o > 0: WD D _ZNSt8functionIFvvEED2Ev [comdat: _ZNSt8functionIFvvEED5Ev] > 1: WD D _ZNSt8functionIFvvEED1Ev [comdat: _ZNSt8functionIFvvEED5Ev] > > and also in Server.cpp.o (not compiled with LTO): > > 2096: 27 FUNCWEAK DEFAULT 846 > _ZNSt8functionIFvvEED2Ev > 2097: 27 FUNCWEAK DEFAULT 846 > _ZNSt8functionIFvvEED1Ev > > These are also declared in the _ZNSt8functionIFvvEED5Ev comdat group. > > (Because the D1 and D2 destructors are the same for this case, the two > symbols > are simply aliased to each other.) > > The call from std::_List_node >::~_List_node() is > to the > D1 destructor: > > Relocation section '.rela.text._ZNSt10_List_nodeISt8functionIFvvEEED2Ev' at > offset 0x1446b0 contains 1 entries: > Offset Info Type Symbol's Value > Symbol's Name + Addend > 0018 08310004 R_X86_64_PLT32 > _ZNSt8functionIFvvEED1Ev - 4 > > When processing SystemExit.o, the plugin claims it, and provides those two > symbols to the linker. This is the first instance of a > _ZNSt8functionIFvvEED5Ev > comdat group, so the linker treats this as the "kept" group. > > When we later see Server.cpp.o, we discard its copy of that comdat group, > and > the reference to the destructor is expected to resolve to the earlier > definition. > > When the LTO plugin is ready to generate final code, it asks the linker > for the > status of those two symbols, and is told (via the -lm.res file): > > out/haswell/main/SystemExit.o 82 > 10879 24ebb94a838bed5c PREVAILING_DEF _ZNSt8functionIFvvEED2Ev > 10842 24ebb94a838bed5c PREVAILING_DEF _ZNSt8functionIFvvEED1Ev > > PREVAILING_DEF indicates that the IR contains a prevailing definition of > the > symbol, but that there are references to that symbol from outside the set > of IR > code (i.e., from Server.cpp.o). That tells the plugin that the compiler > must > generate a global definition of those symbols. (If there were no other > references to the symbol, the resolution would have been > PREVAILING_DEF_IRONLY. > That would have allowed the compiler to generate a local definition.) > > But when the compiler sends back the generated file > hippo.ltrans1.ltrans.o, it > has defined these symbols as local: > > 30: 027033 FUNCLOCAL DEFAULT1 > _ZNSt8functionIFvvEED2Ev > 32: 027033 FUNCLOCAL DEFAULT1 > _ZNSt8functionIFvvEED1Ev > > As a result, the "placeholder" symbols that the linker has kept remain > undefined, and we end up resolving the reference from Server.cpp.o to 0. > > Gold should not be silently resolving this symbol to 0 -- instead, it > should > diagnose the compiler's failure to provide the expected definition and > print an > error message. > > I don't know how or why Gnu ld is resolving the symbol; I would expect the > same > behavior from it. > > So it looks to me (at the moment, at least) like this is a GCC bug. I'll > try to > come up with a simple test case, but it's often hard to reproduce the > exact set > of conditions that cause the optimizer to make a particular decision. It's > possible this has been fixed since GCC 5.2 -- have you tried a newer GCC? > > -cary > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are on the CC list for the bug. _
[Bug gold/19842] LTO build fails to write call address for weak symbol reference
https://sourceware.org/bugzilla/show_bug.cgi?id=19842 --- Comment #6 from Matt Godbolt --- I just tried with a snapshot build of GCC I had around (6.0.0 20160221), and the problem persists: Dump of assembler code for function std::_List_node >::~_List_node(): 0x0077434c <+0>: push %rbp 0x0077434d <+1>: mov%rsp,%rbp 0x00774350 <+4>: sub$0x10,%rsp 0x00774354 <+8>: mov%rdi,-0x8(%rbp) 0x00774358 <+12>:mov-0x8(%rbp),%rax 0x0077435c <+16>:add$0x10,%rax 0x00774360 <+20>:mov%rax,%rdi 0x00774363 <+23>:callq 0x0 0x00774368 <+28>:nop 0x00774369 <+29>:leaveq 0x0077436a <+30>:retq End of assembler dump. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19002] .eh_frame error: "no .eh_frame_hdr table will be created" with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=19002 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Cary Coutant : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=698400bfb91b3476d98edcb6a4bf5e4abe1c14cc commit 698400bfb91b3476d98edcb6a4bf5e4abe1c14cc Author: Cary Coutant Date: Sun Mar 20 19:15:56 2016 -0700 Fix problem where gold cannot build .eh_frame_hdr from ld -r output. When running ld -r on objects that have comdat groups, when gold deduplicates a function in a comdat group, it removes the relocations from the EH information that referred to the dropped copy of the function. When running a final link using the result of the -r link, the missing relocation cause it to fail to recognize the FDE for the dropped function. This patch improves gold's FDE scanning to take into account the possibility that an FDE corresponds to a dropped function, and drops that FDE as well. Gnu ld, on the other hand, leaves the relocations in the ld -r output, but makes them R_NONE with an r_sym field of 0. This was sufficient to let both linkers recognize the FDE properly. With this fix, if you do an ld -r with gold, then do the final link with Gnu ld, the .eh_frame_hdr section will not be generated. To make it work with Gnu ld, we would have to leave the R_NONE relocations in, but I think it's better to drop the relocations entirely. I'd hope that if you're doing a -r link with gold, you'll also do the final link with gold. gold/ PR gold/19002 * ehframe.cc (Eh_frame::read_fde): Check for dropped functions. * testsuite/Makefile.am (eh_test_2): New test. * testsuite/Makefile.in: Regenerate. * testsuite/eh_test_2.sh: New test script. * testsuite/eh_test_a.cc (bar): Make it comdat. * testsuite/eh_test_b.cc (bar): Add a duplicate copy. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
