[Bug binutils/11436] c++filt does not support the C++0x lambdas of GCC 4.5
https://sourceware.org/bugzilla/show_bug.cgi?id=11436 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #4 from Dmitry Vyukov --- Should this be closed? Still pops up as open in search. -- 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/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 --- Comment #7 from Alexander Monakov --- BFD's behavior becomes very problematic with LTO: archive index does not distinguish between normal and common definitions, and there's no explicit plugin API to check if a definition in IR is "common", so the linker has to round-trip via the plugin in a fairly convoluted way to emulate the non-LTO behavior :( I think it would be prudent to understand *why* ld.bfd wants to override common definitions by unpacking archive members with strong definitions. I don't expect it's for Fortran - is the real reason stated anywhere? -- 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 binutils/11436] c++filt does not support the C++0x lambdas of GCC 4.5
https://sourceware.org/bugzilla/show_bug.cgi?id=11436 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- Fixed (a long time ago) -- 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/23409] Shared libraries created with duplicate _end, _edata and __bss_start symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=23409 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The binutils-2_31-branch branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0694d6e5fb2c14934822e68a9a20b43317b0c2a8 commit 0694d6e5fb2c14934822e68a9a20b43317b0c2a8 Author: Nick Clifton Date: Mon Jul 16 14:29:26 2018 +0100 Import patch from mainline to fix gold's handling of already versioned symbols. goldPR gold/23409 * symtab.cc (Symbol_table::define_special_symbol): Add check for version name on existing symbol. * testsuite/Makefile.am (ver_test_pr23409): New test case. * testsuite/Makefile.in: Regenerate. * testsuite/ver_test_pr23409.sh: New test script. * testsuite/ver_test_pr23409_1.script: New version script. * testsuite/ver_test_pr23409_2.script: New version script. -- 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 gas/23418] New: Incorrect xmmword is accepted
https://sourceware.org/bugzilla/show_bug.cgi?id=23418 Bug ID: 23418 Summary: Incorrect xmmword is accepted Product: binutils Version: 2.32 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com CC: igor.v.tsimbalist at intel dot com Target Milestone: --- Target: x86 [hjl@gnu-cfl-1 fp16-1]$ cat z.s .intel_syntax noprefix vcvtps2qq xmm0, xmmword ptr [rax] This is wrong. [hjl@gnu-cfl-1 fp16-1]$ gcc -c z.s [hjl@gnu-cfl-1 fp16-1]$ objdump -dW -Mintel z.o z.o: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 62 f1 7d 08 7b 00 vcvtps2qq xmm0,QWORD PTR [rax] [hjl@gnu-cfl-1 fp16-1]$ -- 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 gas/23418] Incorrect xmmword is accepted
https://sourceware.org/bugzilla/show_bug.cgi?id=23418
--- Comment #1 from H.J. Lu ---
This looks odd:
/* Return 1 if there is no conflict in any size on operand J for
instruction template T. */
static INLINE int
match_mem_size (const insn_template *t, unsigned int wanted, unsigned int
given){
return (match_reg_size (t, wanted, given)
&& !((i.types[given].bitfield.unspecified
&& !i.broadcast
&& !t->operand_types[wanted].bitfield.unspecified)
|| (i.types[given].bitfield.fword
&& !t->operand_types[wanted].bitfield.fword)
/* For scalar opcode templates to allow register and memory
operands at the same time, some special casing is needed
here. Also for v{,p}broadcast*, {,v}pmov{s,z}*, and
down-conversion vpmov*. */
|| ((t->operand_types[wanted].bitfield.regsimd
&& !t->opcode_modifier.broadcast
&& (t->operand_types[wanted].bitfield.byte
|| t->operand_types[wanted].bitfield.word
|| t->operand_types[wanted].bitfield.dword
|| t->operand_types[wanted].bitfield.qword))
? (i.types[given].bitfield.xmmword
|| i.types[given].bitfield.ymmword
|| i.types[given].bitfield.zmmword)
: !match_simd_size(t, wanted, given;
}
--
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 gas/23419] New: Missing/Wrong Extended Mnemonics for POWER9 mt/fspr
https://sourceware.org/bugzilla/show_bug.cgi?id=23419 Bug ID: 23419 Summary: Missing/Wrong Extended Mnemonics for POWER9 mt/fspr Product: binutils Version: 2.32 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: koenigni at student dot ethz.ch Target Milestone: --- Created attachment 11134 --> https://sourceware.org/bugzilla/attachment.cgi?id=11134&action=edit Patch The Power ISA 3.0B suggests having extended mnemonics for moving from and to the perfomance count registers instead of using mt/fspr, so for example `mfspr ra, 771` becomes `mfupmc1 ra` or `mfpmc1 ra` (see page 972 in the isa). Attached is my humble try at a patch. (I couldn't make `make check` work, I hope it works). -- 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
Re: [Bug gold/23411] Different behavior when linking common symbol statically or to shared object
> BFD's behavior becomes very problematic with LTO: archive index does not > distinguish between normal and common definitions, and there's no explicit > plugin API to check if a definition in IR is "common", so the linker has to > round-trip via the plugin in a fairly convoluted way to emulate the non-LTO > behavior :( Sorry, I don't understand your point. Why does the archive index need to distinguish between normal and common definitions? I can understand how it would help, but as long as common symbols are listed in the archive index, the linker can take a closer look at the archive member to decide whether or not to include the file. And the plugin API does provide LDPK_COMMON. What's the "convoluted round trip" you're referring to? Hmm, maybe I do see what you're getting at... If the linker decides, based on the archive index, to include an IR file, it asks the plugin to provide the symbols for the "closer look", but the API doesn't provide a way for the linker to then say, "never mind, I don't need that object after all," in the case where the only symbol of interest happens to be a common. Is that a problem we really need to worry about? The only real issue with including an otherwise-unneeded object is the potential violation of the language's namespace pollution rules (see below). > I think it would be prudent to understand *why* ld.bfd wants to override > common > definitions by unpacking archive members with strong definitions. I don't > expect it's for Fortran - is the real reason stated anywhere? Common blocks were originally for Fortran, yes, and it's clear that the linker should include from an archive a BLOCK DATA subprogram that initializes a common block used elsewhere in the program. The linker support for this was leveraged for K&R C's tentative definitions, so the Fortran behavior became the de facto behavior for C. ANSI C's namespace pollution rules are responsible for the newer behavior. The scenario we're defending against is when a system library defines a symbol A that is introduced into the namespace only if header is included, and a program that does not include that header defines its own symbol A for unrelated purposes. The K&R behavior would have the library's definition of A override the user's A if the user's A is a tentative definition. The only way to prevent this is to avoid the use of K&R-style common for tentative definitions, or (as on HP-UX) to introduce a second type of "ANSI common". The argument for switching back to the K&R rules is that (a) we haven't implemented the "ANSI common" in the Gnu toolchain, (b) we need to preserve the old behavior for both Fortran and K&R C code, and (c) we can achieve strict ANSI compliance through the use of GCC's -fno-common flag. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 --- Comment #8 from Cary Coutant --- > BFD's behavior becomes very problematic with LTO: archive index does not > distinguish between normal and common definitions, and there's no explicit > plugin API to check if a definition in IR is "common", so the linker has to > round-trip via the plugin in a fairly convoluted way to emulate the non-LTO > behavior :( Sorry, I don't understand your point. Why does the archive index need to distinguish between normal and common definitions? I can understand how it would help, but as long as common symbols are listed in the archive index, the linker can take a closer look at the archive member to decide whether or not to include the file. And the plugin API does provide LDPK_COMMON. What's the "convoluted round trip" you're referring to? Hmm, maybe I do see what you're getting at... If the linker decides, based on the archive index, to include an IR file, it asks the plugin to provide the symbols for the "closer look", but the API doesn't provide a way for the linker to then say, "never mind, I don't need that object after all," in the case where the only symbol of interest happens to be a common. Is that a problem we really need to worry about? The only real issue with including an otherwise-unneeded object is the potential violation of the language's namespace pollution rules (see below). > I think it would be prudent to understand *why* ld.bfd wants to override > common > definitions by unpacking archive members with strong definitions. I don't > expect it's for Fortran - is the real reason stated anywhere? Common blocks were originally for Fortran, yes, and it's clear that the linker should include from an archive a BLOCK DATA subprogram that initializes a common block used elsewhere in the program. The linker support for this was leveraged for K&R C's tentative definitions, so the Fortran behavior became the de facto behavior for C. ANSI C's namespace pollution rules are responsible for the newer behavior. The scenario we're defending against is when a system library defines a symbol A that is introduced into the namespace only if header is included, and a program that does not include that header defines its own symbol A for unrelated purposes. The K&R behavior would have the library's definition of A override the user's A if the user's A is a tentative definition. The only way to prevent this is to avoid the use of K&R-style common for tentative definitions, or (as on HP-UX) to introduce a second type of "ANSI common". The argument for switching back to the K&R rules is that (a) we haven't implemented the "ANSI common" in the Gnu toolchain, (b) we need to preserve the old behavior for both Fortran and K&R C code, and (c) we can achieve strict ANSI compliance through the use of GCC's -fno-common flag. -- 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 gas/23418] Incorrect xmmword is accepted
https://sourceware.org/bugzilla/show_bug.cgi?id=23418 --- Comment #2 from H.J. Lu --- vcvtps2uqq has the same issue. -- 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 gas/23419] Missing Extended Mnemonics for POWER9 mt/fspr
https://sourceware.org/bugzilla/show_bug.cgi?id=23419 Nicolas Koenig changed: What|Removed |Added Summary|Missing/Wrong Extended |Missing Extended Mnemonics |Mnemonics for POWER9|for POWER9 mt/fspr |mt/fspr | -- 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 gas/23419] Missing Extended Mnemonics for POWER9 mt/fspr
https://sourceware.org/bugzilla/show_bug.cgi?id=23419 Nicolas Koenig changed: What|Removed |Added Attachment #11134|0 |1 is obsolete|| CC||koenigni at student dot ethz.ch --- Comment #1 from Nicolas Koenig --- Created attachment 11135 --> https://sourceware.org/bugzilla/attachment.cgi?id=11135&action=edit Patch Fixed mtspr extended opcode -- 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 binutils/11436] c++filt does not support the C++0x lambdas of GCC 4.5
https://sourceware.org/bugzilla/show_bug.cgi?id=11436 --- Comment #6 from Bruno Haible --- Confirmed: Fixed (at least) in 2.25.1 and 2.26.1. -- 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/23411] Different behavior when linking common symbol statically or to shared object
https://sourceware.org/bugzilla/show_bug.cgi?id=23411 --- Comment #9 from Alexander Monakov --- (In reply to Cary Coutant from comment #8) > Is that a problem we really need to worry > about? The only real issue with including an otherwise-unneeded object > is the potential violation of the language's namespace pollution rules > (see below). The reason it's being reported now is complications with plugin interaction. Recently, GCC strengthened internal consistency checks for LTO symbol resolution, and (combined with arguably poor choices for statuses reported for symbols coming from unused members) they fail when such unpacked-but-unused archive members get involved: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 I'm chiming in because I've been working on a third party (i.e. non-GCC, non-LLVM) linker plugin recently, and this ld.bfd-specific behavior was completely unexpected and cost some time. The ELF specification does not allow this, the other docs I consulted did not mention it, and the way ar index is built suggests common status is irrelevant for extraction (otherwise the index would include the common flag). If the BFD behavior is really intended, can at least the documentation please be improved to explain that? And what would really help is a dedicated plugin API entrypoint to allow the linker ask the plugin, "does IR in this file provide a strong definition for any currently common symbol in this array: ["foo", "bar", ...]?" -- 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
