[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Richard Earnshaw : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=417f991f08cb869e8274e0a6af6c88b14413e0ec commit 417f991f08cb869e8274e0a6af6c88b14413e0ec Author: Richard Earnshaw Date: Thu Jul 1 11:37:13 2021 +0100 arm: don't treat XScale features as part of the FPU [PR 28031] Although the XScale and its iwMMX extensions are implemented in the Arm co-processor space, they are not considered to be part of the FPU specification. In particular, they cannot be enabled or disabled via a .fpu directive. It's therefore incorrect to strip these properties when a new .fpu directive is encountered. Note that the legacy Maverick co-processor is considered to be a FPU and it is possible to control this via the .fpu directive. include: PR gas/28031 * opcode/arm.h (FPU_ANY): Exclude XScale-related features. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 --- Comment #3 from Richard Earnshaw --- Fixed on master so far. Affects releases back to 2.34. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 Richard Earnshaw changed: What|Removed |Added Version|2.36|2.34 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28029] debuginfod 2 tests UNTESTED
https://sourceware.org/bugzilla/show_bug.cgi?id=28029 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1b8d1f5f3861c04070bd5d249855b575e431f56b commit 1b8d1f5f3861c04070bd5d249855b575e431f56b Author: Nick Clifton Date: Thu Jul 1 14:10:38 2021 +0100 Partially fix debuginfod tests in binutils testsuite. PR 28029 * testsuite/binutils-all/debuginfod.exp: Replace -wK with -wk. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28040] New: libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040 Bug ID: 28040 Summary: libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin Product: binutils Version: 2.37 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: tbaeder at redhat dot com Target Milestone: --- This is a forward of https://bugzilla.redhat.com/show_bug.cgi?id=1954375 and https://reviews.llvm.org/D104230 ld.bfd (or rather libbfd I think) creates tons of fds and passes them to the claim_file() callback that ld plugins implement. This is the case for archives as far as I can see. ld does not close the fd after the claim_file() callback has been called when the LLVM plugin is in use, but does close them when the gcc plugin is used (there is a comment about this in ld/plugin.c. Simply removing that comment and the surrounding if statement fixed the problem for me. Explicitly calling release_input_file() in LLVM's claim_file implementation also worked for me. I don't have a smaller test case for this unfortunately. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28029] debuginfod 2 tests UNTESTED
https://sourceware.org/bugzilla/show_bug.cgi?id=28029 Nick Clifton changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||nickc at redhat dot com Last reconfirmed||2021-07-01 --- Comment #2 from Nick Clifton --- Hi Toolybird, I have checked in a partial fix for this problem. But now one of the objdump tests is failing and I am not sure why... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28037] Semireproducible bug
https://sourceware.org/bugzilla/show_bug.cgi?id=28037 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Volker Weißmann from comment #0) Hi Volker, > sometimes (1 in 20 times maybe) A bug that does not happemn reliably is very hard to track down. The most common cause for such bugs are memory issues - either using uninitialised memory or using freed memory or the like. Are you able to run your tests in an environment with additional memory debugging enabled ? For example by using valgrind, or setting the MALLOC_CHECK_ environment variable ? Another possibility is a hardware problem. If you have a faulty memory bank for example then that might explain the problem. Are you able to reproduce the failure on another machine ? > = note: /usr/local/bin/ld: BFD (GNU Binutils) 2.34.50.20200328 This is not an official binutils release. Nor is it the latest release. Are you able to run your tests using the newest binutils (2.36.1) ? > internal > error, aborting at merge.c:939 in _bfd_merged_section_offset This error suggests that the issue might be due to uninitialised memory. There is a comment just before line 939 which says: /* This should only happen if somebody points into the padding after a NUL character but before next entity. */ if (*p) abort (); So the implication is that 'p' is pointing into "padding" of some kind and padding can often contain random bytes. Still without more information to go on, it is hard to make any further progress. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The binutils-2_36-branch branch has been updated by Richard Earnshaw : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=687dd74c9bac7b746ea69e4ea070adff05226b13 commit 687dd74c9bac7b746ea69e4ea070adff05226b13 Author: Richard Earnshaw Date: Thu Jul 1 11:37:13 2021 +0100 arm: don't treat XScale features as part of the FPU [PR 28031] Although the XScale and its iwMMX extensions are implemented in the Arm co-processor space, they are not considered to be part of the FPU specification. In particular, they cannot be enabled or disabled via a .fpu directive. It's therefore incorrect to strip these properties when a new .fpu directive is encountered. Note that the legacy Maverick co-processor is considered to be a FPU and it is possible to control this via the .fpu directive. include: PR gas/28031 * opcode/arm.h (FPU_ANY): Exclude XScale-related features. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28031] iwmmxt2 assembly broken since f439988037a
https://sourceware.org/bugzilla/show_bug.cgi?id=28031 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |2.36.1 --- Comment #5 from Richard Earnshaw --- Fixed on master and binutils-2.36 branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28040] libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com Status|NEW |WAITING --- Comment #1 from H.J. Lu --- I can't produce it on Fedora 34 when building LLVM main branch commit 2668727929e497553eba485876eb6190d38cc367 Author: Bradley Smith Date: Tue Jun 29 12:40:46 2021 +0100 [SelectionDAG] Implement PromoteIntRes_INSERT_SUBVECTOR with CC="clang" CXX="clang++" cmake -DCMAKE_BUILD_TYPE=Release -G Ninja -DLLVM_BUILD_TESTS=ON -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_BINUTILS_INCDIR=/usr/include -DLLVM_BUILD_EXAMPLES=ON -DCLANG_BUILD_EXAMPLES=ON -DCMAKE_INSTALL_PREFIX= -DLLVM_ENABLE_PROJECTS=clang -DLLVM_PARALLEL_LINK_JOBS=8 -DLLVM_ENABLE_LTO=ON /export/gnu/import/git/github/llvm/llvm Please show me exactly how to reproduce it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28040] libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040 H.J. Lu changed: What|Removed |Added See Also||https://bugzilla.redhat.com ||/show_bug.cgi?id=1954375 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28044] New: Add LSDA decoding to readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=28044 Bug ID: 28044 Summary: Add LSDA decoding to readelf Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: woodard at redhat dot com Target Milestone: --- One thing that is an important aspect of compatibility between libraries and their consumers (apps and other libraries) are the exceptions thrown and caught. Ideally you want to make sure that all exceptions that could be thrown are properly caught Unfortunately it is currently EXTREMELY difficult to look at an ELF file see which exceptions are thrown or caught. That information is readily available in the ELF file it just isn't being decoded. This forces a user to manually interpret the ELF file and decode the LSDA by hand to list the types. This is very likely above the level of most developers. It would be nice if readelf were able to decode the LSDA and print it in a human understandable form. I propose a feature that does this: readelf --exceptions-thrown readelf --exceptions-caught and maybe: readelf --exceptions which effectively is the same as readelf --exceptions-thrown --exceptions-caught So far the best descriptions of how to decode those sections that I have been able to find are: https://www.airs.com/blog/archives/464 and http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012-Skochinsky-Compiler-Internals.pdf (start at about page 35) The code that processes that section in GCC can be found in gcc/libgcc/unwind-c.c that could be a good reference. Once you have the LSDA decoding capabilities it may also be worthwhile to print out the decoded fields when doing --debug-dump=frames and pretty print the structures pointed to by the LSDA pointers. There is a possibility that at least at times llvm generates a different version of the LSDA and so for a fully functional tool you may also want to decode any flavors of LSDA that llvm may generate as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28045] New: add --warn-uncaught-exceptions to linker
https://sourceware.org/bugzilla/show_bug.cgi?id=28045 Bug ID: 28045 Summary: add --warn-uncaught-exceptions to linker Product: binutils Version: unspecified Status: NEW Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: woodard at redhat dot com Target Milestone: --- Right now given some random library it is very difficult and requires an awful amount of digging to just figure out what you should try to catch. It would be great if the linker which can observe these things as it is linking the binary could point out uncaught exceptions. So when gcc links the developer could pass: -Wl,--warn-uncaught-exceptions Then for every type thrown as listed in the LSDA, if at least one of the libraries doesn't have an entry in the TType table then it prints something like: Warning: thus_and_such_function throws type ExceptionType at line N there is no corresponding catch block that can catch that type. Then when they see that they could look at their code that either directly or indirectly calls the named function and insert a catch block. And like most warnings vs. errors they can look at it and say — yeah I don’t really care and ignore it. The simplest blunt way to fix that warning would be wrap the contents of main in a try block and put catch blocks for the types being pointed out there. It obviously would be better to be more targeted in where they insert their catch blocks. This would just be a first approximation, it wouldn't necessarily be able to guarantee that there isn't a way to reach some code where an exception wouldn't be caught. To be able to do that, you would have to do call chain analysis. However, it would insure that somewhere in the totality of the program being linked there is a catch block that can handle that type. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28045] add --warn-uncaught-exceptions to linker
https://sourceware.org/bugzilla/show_bug.cgi?id=28045 --- Comment #1 from Ben Woodard --- Some additional things to consider: https://wiki.c2.com/?DontCatchExceptions https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Re-catch https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#e17-dont-try-to-catch-every-exception-in-every-function All of these basically end up dealing with where to try to catch exceptions vs whether all the different types of exceptions are caught. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/21683] [avr] Support a pseudo-instruction to allow more efficient GCC ISR prologues
https://sourceware.org/bugzilla/show_bug.cgi?id=21683 Joe Anderson changed: What|Removed |Added CC||ampva300 at gmail dot com --- Comment #5 from Joe Anderson --- Nice! You did great on figuring out what's the real problem. Thanks for the hard work in fixing the currently generated ISR prologues. Greetings from all of us at https://www.pasadenaconcretepros.com/ -- You are receiving this mail because: You are on the CC list for the bug.
