[Bug gas/27190] New: m68k: fmovemx does not accept pc-relative addressing modes for memory-to-register transfers
https://sourceware.org/bugzilla/show_bug.cgi?id=27190 Bug ID: 27190 Summary: m68k: fmovemx does not accept pc-relative addressing modes for memory-to-register transfers Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ad...@tho-otto.de Target Milestone: --- Created attachment 13121 --> https://sourceware.org/bugzilla/attachment.cgi?id=13121&action=edit Add fix for gas not allowing pc-relative addressing for fmovemx , Assembling an instruction like fmovem.x addr(%pc),%fp0-%fp1 Is rejected by gas. For memory-to-register-transfers, it should also allow pc-relative addressing modes. Attached is proposed fix (changes the "alterable-control" flag to "control" for those instructions). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/2097] 2.16.91.0.5 internal error wants to be reported ...
https://sourceware.org/bugzilla/show_bug.cgi?id=2097 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Alan Modra --- No testcase and out of date. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27191] New: m68k: incorrect assembly of fmovem.l #data,%fpsr/%fpcr
https://sourceware.org/bugzilla/show_bug.cgi?id=27191 Bug ID: 27191 Summary: m68k: incorrect assembly of fmovem.l #data,%fpsr/%fpcr Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ad...@tho-otto.de Target Milestone: --- When using immediate data for a fmovem.l to control register, and more than one register ist specified, only a single constant is written: fmovem.l#0x,%fpsr/%fpcr nop result: 0: f23c 9800 fmoveml #0,%fpsr/%fpcr 6: 8: 4e71nop Only the low 32-bit value was written. Specifying for example fmovem.l#0x,%fpsr/%fpcr/%fpiar nop does not work at all, because the constant overflows. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27191] m68k: incorrect assembly of fmovem.l #data,%fpsr/%fpcr
https://sourceware.org/bugzilla/show_bug.cgi?id=27191 --- Comment #1 from Andreas Schwab --- The IMM form only allows a single destination register. Both insns should be rejected. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27191] m68k: incorrect assembly of fmovem.l #data,%fpsr/%fpcr
https://sourceware.org/bugzilla/show_bug.cgi?id=27191 --- Comment #2 from Thorsten Otto --- Are you sure about this? I can't find any indication for that in the manual. Only register-direct are flagged as being allowed only for a single register. And actually, that is instruction is emulated, and also tested, by the FPSP060 support package: https://github.com/torvalds/linux/blob/1d94330a437a573cfdf848f6743b1ed169242c8a/arch/m68k/ifpsp060/src/ftest.S#L647 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/23169] IFUNC pointer should be allowed in executable
https://sourceware.org/bugzilla/show_bug.cgi?id=23169 --- Comment #7 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=75a933f39918ce4f4b9481234992895e022787ee commit 75a933f39918ce4f4b9481234992895e022787ee Author: H.J. Lu Date: Sat Jan 16 07:00:09 2021 -0800 ld/elf/x86: Don't compare IFUNC address in the shared object On x86, glibc 2.33 starts to issue a fatal error message when calling IFUNC function defined in the unrelocated executable from a shared library. 1. Update x86 ELF linker to always convert IFUNC function defined in position-dependent executable (PDE) to the normal function. GOT in PDE will be updated by R_*_IRELATIVE at run-time. 2. Update PR ld/23169 tests not to compare function address of external IFUNC function in the shared object to avoid calling the IFUNC function defined in the unrelocated executable. 3. Remove pr23169e tests which call the IFUNC function defined in the unrelocated position-independent executable from a shared library. bfd/ PR ld/23169 * elfxx-x86.c (_bfd_x86_elf_link_fixup_ifunc_symbol): Don't check pointer_equality_needed. ld/ PR ld/23169 * testsuite/ld-ifunc/ifunc.exp: Replace pr23169c.rd with pr23169a.rd for pr23169c and pr23169f. Remove pr23169e tests. * testsuite/ld-ifunc/pr23169a.c (foo): Don't compare function address. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27192] New: conflicting CPU architectures 10/16 error on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=27192 Bug ID: 27192 Summary: conflicting CPU architectures 10/16 error on ARM Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: na.vrchol.a.zpet at email dot cz Target Milestone: --- Created attachment 13124 --> https://sourceware.org/bugzilla/attachment.cgi?id=13124&action=edit A complete test project for Windows The armv8-m.base and armv8-m.main architectures cannot be mixed with others (armv4t through armv7m) when multilinking, even though the entry point is set (through the provided linker script) to a code compiled under a specific architecture and --gc-sections should discard unused code for other architectures, unless unsupported on these new architectures. I'm on a Windows 10 machine, using bleeding edge toolchain (https://freddiechopin.info/en/download/category/11-bleeding-edge-toolchain?download=186%3Ableeding-edge-toolchain-200517-64-bit-windows) with gcc-10.1.0. See the attached test project with assembler sources (/src), compiled objects (/out), linker scripts (/script), and linker commands (ld.cmd). In the ld.cmd, you can change where the toolchain and test project are located, the defaults are C:/gcc-10.1.0/arm-none-eabi/bin and C:/ld. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] New: GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 Bug ID: 27193 Summary: GCC trunk unable to bootstrap with Binutils Trunk Product: binutils Version: 2.37 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: dje at sourceware dot org Target Milestone: --- Matt Godbolt (CompilerExplorer) reports that GCC Trunk no longer is able to bootstrap with Binutils Trunk. Reverting to Binutils release works. multiple definition of `__x86.get_pc_thunk.bx' occurs during the xgcc build of libgcc_s.so https://twitter.com/CompileExplore/status/1350153503591854080 `curl https://godbolt.org/admin/logs/gcc | less` will get the current failure -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 David Edelsohn changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||hjl at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 David Edelsohn changed: What|Removed |Added Target||x86_64-*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #1 from H.J. Lu --- Is this a dup of PR 27173? I have no problems with binutils master and GCC master on Fedora 33. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 H.J. Lu changed: What|Removed |Added CC|hjl at sourceware dot org | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 David Edelsohn changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from David Edelsohn --- Matt reports that he is using Ubuntu 18.04, but reports that the build remains broken for him as of yesterday, after PR 27173 was closed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from H.J. Lu --- (In reply to David Edelsohn from comment #2) > Matt reports that he is using Ubuntu 18.04, but reports that the build > remains broken for him as of yesterday, after PR 27173 was closed Did he use the current binutils master? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 David Edelsohn changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from David Edelsohn --- He states that he is automatically downloading it for each daily build. Please engage him on Twitter. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 --- Comment #5 from H.J. Lu --- I reproduced it: /home/hjl/work/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux//usr/toolchain-11.0.0/x86_64-linux/bin/ld: /home/hjl/work/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/gcc/src/gcc-build/./gcc/32/crtbeginS.o: in function `__x86.get_pc_thunk.bx': crtstuff.c:(.text.__x86.get_pc_thunk.bx[__x86.get_pc_thunk.bx]+0x0): multiple definition of `__x86.get_pc_thunk.bx'; /usr/lib/i386-linux-gnu/crti.o:(.gnu.linkonce.t.__x86.get_pc_thunk.bx+0x0): first defined here collect2: error: ld returned 1 exit status Makefile:990: recipe for target 'libgcc_s.so' failed make[9]: *** [libgcc_s.so] Error 1 on Ubuntu 18.04. Looking into it now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 H.J. Lu changed: What|Removed |Added Assignee|unassigned at sourceware dot org |hjl.tools at gmail dot com Target Milestone|--- |2.37 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193
--- Comment #6 from H.J. Lu ---
/* Check if 2 sections define the same set of local and global
symbols. */
static bfd_boolean
bfd_elf_match_symbols_in_sections (asection *sec1, asection *sec2,
struct bfd_link_info *info)
{
doesn't ignore section symbols.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 Matt Godbolt changed: What|Removed |Added CC||matt at godbolt dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 --- Comment #7 from Matt Godbolt --- Hi there, It was failing until pretty recently. Our fix is to go back to 2.35.1 (which is more sane). Seems like you've been able to repro: please let me know if I can test anything! Cheers all, Matt -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] GCC trunk unable to bootstrap with Binutils Trunk
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 H.J. Lu changed: What|Removed |Added Target Milestone|2.37|2.36 CC||nickc at redhat dot com Version|2.37 (HEAD) |2.36 --- Comment #8 from H.J. Lu --- 2.36 branch has the same issue. A patch is posted at https://sourceware.org/pipermail/binutils/2021-January/114976.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/23169] IFUNC pointer should be allowed in executable
https://sourceware.org/bugzilla/show_bug.cgi?id=23169 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #8 from Fangrui Song --- Can https://sourceware.org/glibc/wiki/GNU_IFUNC to updated to document what is supported and what isn't supported? For the https://sourceware.org/bugzilla/show_bug.cgi?id=23169#c0 example, if you run: gcc -fpie -g -c -o main.o main.c gcc -fpie -g -c -o func.o func.c gcc -g -fPIC -c -o foo.o foo.c gcc -shared -o libfoo.so foo.o gcc -pie -o x main.o func.o libfoo.so -Wl,-R,. Previously, a STT_GNU_IFUNC did not need to be converted to STT_FUNC if there were only GOT-generating or PLT-generating relocations. func.o had only a GOT-generating relocation: R_X86_64_REX_GOTPCRELX. func was STT_GNU_IFUNC. After the recent GNU ld commit https://sourceware.org/bugzilla/show_bug.cgi?id=23169#c7 STT_GNU_IFUNC is converted to STT_FUNC regardless of the relocation type. func is STT_FUNC. Is the idea that (1) the main executable is relocated the last. (2) by making the main executable STT_GNU_IFUNC STT_FUNC, ifunc resolver will not be called while the main executable is unresolved (3) How does an ifunc resolver defined in another DSO work? Let the user ensures DT_NEEDED BFS order or the ld.so itself does topological sorting? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27195] New: Error: file number less than one
https://sourceware.org/bugzilla/show_bug.cgi?id=27195 Bug ID: 27195 Summary: Error: file number less than one Product: binutils Version: 2.36 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com CC: mark at klomp dot org, nickc at redhat dot com Target Milestone: --- From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98708 GCC 11 may generate: [hjl@gnu-clx-1 tmp]$ cat foo.s .file "cxx11-ios_failure.cc" .file 1 "../../../../../src-master/libstdc++-v3/src/c++11/cxx11-ios_failure.cc" .file 0 "/export/gnu/import/git/gcc-test-master-intel64-native/bld/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11" "../../../../../src-master/libstdc++-v3/src/c++11/cxx11-ios_failure.cc" .text nop [hjl@gnu-clx-1 tmp]$ gcc -c foo.s foo.s: Assembler messages: foo.s:3: Error: file number less than one [hjl@gnu-clx-1 tmp]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/23460] regression: ar can not create archive containing many (>1024) lto object files
https://sourceware.org/bugzilla/show_bug.cgi?id=23460 --- Comment #26 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=edf0f284b13293bb9740795131d18fe281139c48 commit edf0f284b13293bb9740795131d18fe281139c48 Author: H.J. Lu Date: Sat Jan 16 18:36:40 2021 -0800 PR binutils/23460: Increase the max number of open files to 20 Increase the max number of open files to 20 for PR binutils/23460 test which may have more than 16 file descriptors open: lr-x-- 1 hjl hjl 64 Jan 16 16:49 0 -> /dev/null l-wx-- 1 hjl hjl 64 Jan 16 16:49 1 -> pipe:[14151430] lr-x-- 1 hjl hjl 64 Jan 16 16:49 10 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460c.o lr-x-- 1 hjl hjl 64 Jan 16 16:49 11 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460d.o lr-x-- 1 hjl hjl 64 Jan 16 16:49 12 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460e.o lr-x-- 1 hjl hjl 64 Jan 16 16:49 13 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460f.o lrwx-- 1 hjl hjl 64 Jan 16 16:49 14 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/stTLiXpO lrwx-- 1 hjl hjl 64 Jan 16 16:49 15 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/stTLiXpO l-wx-- 1 hjl hjl 64 Jan 16 16:49 2 -> pipe:[14151430] lr-x-- 1 hjl hjl 64 Jan 16 16:49 3 -> pipe:[13933216] l-wx-- 1 hjl hjl 64 Jan 16 16:49 4 -> pipe:[13933216] lr-x-- 1 hjl hjl 64 Jan 16 16:49 5 -> pipe:[13990857] l-wx-- 1 hjl hjl 64 Jan 16 16:49 6 -> pipe:[13990857] lr-x-- 1 hjl hjl 64 Jan 16 16:49 7 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/libpr23460.a lr-x-- 1 hjl hjl 64 Jan 16 16:49 8 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460a.o lr-x-- 1 hjl hjl 64 Jan 16 16:49 9 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460b.o PR binutils/23460 * testsuite/ld-plugin/lto.exp: Increase the max number of open files to 20 for PR binutils/23460 test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27193] Linkonce section with unused section symbols won't match comdat section without unused section symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=27193 H.J. Lu changed: What|Removed |Added Summary|GCC trunk unable to |Linkonce section with |bootstrap with Binutils |unused section symbols |Trunk |won't match comdat section ||without unused section ||symbols --- Comment #9 from H.J. Lu --- When deciding if a single member comdat group section in file FOO should be discarded by a linkonce section in file BAR, we check if 2 sections define the same set of local and global symbols. When only one of the files doesn't contain the unused section symbols in the symbol table, such as object files generated by clang or GNU assembler with commit d1bcae833b32f1408485ce69f844dcd7ded093a8 Author: H.J. Lu Date: Thu Jan 7 06:42:00 2021 -0800 ELF: Don't generate unused section symbols the check will fail since one file has the extra unused section symbols. We should ignore both undefined and section symbols in the symbol table when making such a decision. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27195] Error: file number less than one
https://sourceware.org/bugzilla/show_bug.cgi?id=27195 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from H.J. Lu --- It is a GCC bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27195] Error: file number less than one
https://sourceware.org/bugzilla/show_bug.cgi?id=27195 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG |--- --- Comment #2 from H.J. Lu --- I think it is very bad that $ as -o x.o x.s fails when x.s contains DWARF5 info generated by GCC 11. Assembler shouldn't require --gdwarf-5 to accept DWARF5 info. GCC 11 should emit an assembly directive to enable DWARF5 info in assembler. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27195] Error: file number less than one
https://sourceware.org/bugzilla/show_bug.cgi?id=27195 H.J. Lu changed: What|Removed |Added Status|REOPENED|NEW --- Comment #3 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2021-January/114978.html -- You are receiving this mail because: You are on the CC list for the bug.
