[Bug gas/26212] New: doc for x86 incorrectly says that AVX-2 added 16 new XMM/YMM registers
https://sourceware.org/bugzilla/show_bug.cgi?id=26212 Bug ID: 26212 Summary: doc for x86 incorrectly says that AVX-2 added 16 new XMM/YMM registers Product: binutils Version: 2.36 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: sebastien at debian dot org Target Milestone: --- The documentation (in i386 Dependent features, section “Register Naming”, file c-i386.texi) says that: The AVX2 extensions made in 64-bit mode more registers available: * the 16 128-bit registers '%xmm16'-'%xmm31' and the 16 256-bit registers '%ymm16'-'%ymm31'. This is incorrect. Those extra registers were added in AVX512. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26212] doc for x86 incorrectly says that AVX-2 added 16 new XMM/YMM registers
https://sourceware.org/bugzilla/show_bug.cgi?id=26212 --- Comment #1 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=dbdba9b04d4b91121357ac9a0402d67cb53ce7ce commit dbdba9b04d4b91121357ac9a0402d67cb53ce7ce Author: H.J. Lu Date: Tue Jul 7 05:06:38 2020 -0700 x86: Remove an incorrect AVX2 entry The upper 16 vector registers were added by AVX512. PR gas/26212 * doc/c-i386.texi: Remove an incorrect AVX2 entry. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26212] doc for x86 incorrectly says that AVX-2 added 16 new XMM/YMM registers
https://sourceware.org/bugzilla/show_bug.cgi?id=26212 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The binutils-2_35-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=171ee0dc148e7db5a23b4e1c6c10910143bbc428 commit 171ee0dc148e7db5a23b4e1c6c10910143bbc428 Author: H.J. Lu Date: Tue Jul 7 05:06:38 2020 -0700 x86: Remove an incorrect AVX2 entry The upper 16 vector registers were added by AVX512. PR gas/26212 * doc/c-i386.texi: Remove an incorrect AVX2 entry. (cherry picked from commit dbdba9b04d4b91121357ac9a0402d67cb53ce7ce) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26212] doc for x86 incorrectly says that AVX-2 added 16 new XMM/YMM registers
https://sourceware.org/bugzilla/show_bug.cgi?id=26212 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.35 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from H.J. Lu --- Fixed for 2.35. -- You are receiving this mail because: You are on the CC list for the bug.
GNU windres cannot compile BITMAP or OWNERDRAW menu items
Hello, I'm katahiromz.
I'm using your resource compiler "windres".
I found that windres cannot compile BITMAP or OWNERDRAW menu items.
1 MENU
{
POPUP "&File"
{
MENUITEM "This is a test #1", 100, BITMAP
MENUITEM "This is a test #2", 101, OWNERDRAW
}
}
I want you to fix this bug...
Thanks,
片山博文MZ
[Bug gas/26143] gas generates invalid line table entry
https://sourceware.org/bugzilla/show_bug.cgi?id=26143 Tom de Vries changed: What|Removed |Added CC||aoliva at sourceware dot org --- Comment #2 from Tom de Vries --- (In reply to Nick Clifton from comment #1) > (In reply to Tom de Vries from comment #0) > Hi Tom, > > > [0x0080] Special opcode 75: advance Address by 5 to 0x1c and Line by > > 0 to 12 > > [0x0081] Extended opcode 1: End of Sequence > > > Every line number program sequence must end with a DW_LNE_end_sequence > > instruction which creates a row whose address is that of the byte after the > > last target machine instruction of the sequence. > > > One the one hand, the end-of-sequence declares that address 0x1c is one past > > the byte of the last target machine instruction of the sequence. > > > > On the other hand, the special opcode declares a target instruction starting > > at address 0x1c, that is part of that same sequence. > > Ah - but special opcodes do not necessarily assert that there is a target > instruction starting at the address they reference. Hi Nick, As indicated in dwarf4 standard 6.2.5.1 point 3, each special opcode adds a row to the matrix. Each row represents a machine instruction, as implied here in 6.2: ... If space were not a consideration, the information provided in the .debug_line section could be represented as a large matrix, with one row for each instruction in the emitted object code. ... The exception is a row with end_sequence set to true, but that's not the case for the row generated by: ... [0x0080] Special opcode 75: advance Address by 5 to 0x1c and Line by 0 to 12 ... So, I don't agree with this assessment. If you still think my interpretation is wrong, you should state an alternative one. What does the generated row mean according to you, in terms of the DWARF standard? > > > > This option causes a row to be added to .debug_line in reference to the > > current address (which might not be the same as that of the following > > assembly instruction), > > > I cannot tell from the formulation "in reference to the current address > > (which might not be the same as that of the following assembly instruction)" > > whether this particular instance of .loc usage is valid. > > My take on this is that the "view" directive specifies a property for an > address, but it does not require that there be an instruction at that > address. Hence the generated line number table is correct... > I'm not sure the semantics of the view directive are relevant to the correctness of the generated line number table. It's my understanding that the implementation for views intends to emit pure dwarf with no extensions, and that the view info can be interpreted by consumers with support, and ignored by consumers without support. After watching Alexandre Oliva's 2017 GNU Cauldron presentation, I get the impression that the "which might not be the same as that of the following assembly instruction" formulation refers to a situation like this: ... .loc .balign 32 .loc insn1 ... where the first loc may or may not refer to insn1. ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26216] New: 2.34 Linker error - dynsym local symbol at index 11
https://sourceware.org/bugzilla/show_bug.cgi?id=26216 Bug ID: 26216 Summary: 2.34 Linker error - dynsym local symbol at index 11 Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: shri.sn at gmail dot com Target Milestone: --- Linker error libQt5WebKitWidgets.so: .dynsym local symbol at index 11 (>= sh_info of 2) I get the above error during linking. I tried the versions 2.33.1 and 2.34. Both versions have the same error. I read that the issue was fixed in 2.33.1 version, but I still see the issue. https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0231a51ef7ff49336d3a2f0e4eec09cd17b23c95 2.30 works fine for me. Please help with a resolution. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26216] 2.34 Linker error - dynsym local symbol at index 11
https://sourceware.org/bugzilla/show_bug.cgi?id=26216 --- Comment #1 from Andreas Schwab --- Looks like libQt5WebKitWidgets.so is corrupt. Please attach the output of "readelf -WSs libQt5WebKitWidgets.so". -- You are receiving this mail because: You are on the CC list for the bug.
