[Bug binutils/26259] Can't generate ORR instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=26259 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi Alexei, The problem is that "0x00800080" can be encoded as an immediate value for 32-bit vector operations, but it cannot be encoded for 64-bit vectors. (Because the top 32-bits are all zero, and the encoded constant must be a single pattern). See section C3.3.2 of the ARM ARM. So 0x0080008000800080 works (single repeating pattern of 0x0080) But 0x00800080 does not (two patterns) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26259] Can't generate ORR instruction
https://sourceware.org/bugzilla/show_bug.cgi?id=26259 --- Comment #3 from Alexei Fedorov --- Thanks, Nick I also worked that out. Regards. Alexei. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26400] Internal error when using .offset with jumps in RISC-V as
https://sourceware.org/bugzilla/show_bug.cgi?id=26400
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment #1 from Jim Wilson ---
I had to read the gas docs to figure out what .offset does.
I see that frag_new calls frag_now_fix_octets, and that one has
if (now_seg == absolute_section)
return abs_section_offset;
which is not what the rest of the frag code is expecting. Not obvious what
that is for, or how that can work.
Though looking at tc-i386.c, in output_branch, I see it has
if (now_seg == absolute_section)
{
as_bad (_("relaxable branches not supported in absolute section"));
return;
}
and that tracks back to a patch a couple of months ago from Jan Beulich
https://sourceware.org/pipermail/binutils/2020-July/112420.html
This checks for the absolute section in various places, and increments the
absolute section offset instead of writing bytes to frags which is compatible
with what frag_now_fix_octets is doing.
It appears that significant changes are required to be able to support
instructions in the absolute section. And that the best we can do for
relaxable instructions is emit a polite error. Since we have a lot of
relaxable instructions this doesn't look very useful in general for RISC-V.
Unless you turn off relaxation, but you will lose code size and performance if
you do that.
The x86 port allows one to calculate the size of an insn via the absolute
section, but otherwise putting things in the absolute section isn't useful.
They won't appear in the output .o file for instance.
Why are you trying to put instructions in the absolute section? Maybe this did
something useful with very old a.out or coff targets, but not for ELF? You did
say the code was pretty old.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/26654] New: opcodes/i386-dis.c:790 ~800, violate sorting model ,should be placed in MOD_VEX_0F38* group
https://sourceware.org/bugzilla/show_bug.cgi?id=26654 Bug ID: 26654 Summary: opcodes/i386-dis.c:790 ~800, violate sorting model ,should be placed in MOD_VEX_0F38* group Product: binutils Version: 2.36 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: lili.cui at intel dot com Target Milestone: --- form opcodes/i386-dis.c:790 to 800, there are 11 MOD_VEX_0F38* inserted in MOD_0F38* group, which should be placed in MOD_VEX_0F38* group. ... MOD_0F382A, MOD_VEX_0F3849_X86_64_P_0_W_0, MOD_VEX_0F3849_X86_64_P_2_W_0, MOD_VEX_0F3849_X86_64_P_3_W_0, MOD_VEX_0F384B_X86_64_P_1_W_0, MOD_VEX_0F384B_X86_64_P_2_W_0, MOD_VEX_0F384B_X86_64_P_3_W_0, MOD_VEX_0F385C_X86_64_P_1_W_0, MOD_VEX_0F385E_X86_64_P_0_W_0, MOD_VEX_0F385E_X86_64_P_1_W_0, MOD_VEX_0F385E_X86_64_P_2_W_0, MOD_VEX_0F385E_X86_64_P_3_W_0, MOD_0F38DC_PREFIX_1, MOD_0F38DD_PREFIX_1, ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26655] New: Power10 libstdc++.so R_PPC64_NONE dynamic relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=26655 Bug ID: 26655 Summary: Power10 libstdc++.so R_PPC64_NONE dynamic relocs Product: binutils Version: 2.36 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: amodra at gmail dot com Target Milestone: --- A recent build of gcc for power10 gave me a libstdc++.so with 87 R_PPC64_NONE dynamic relocations, all due to allocating GOT entries that are never used. The GOT entries correspond to R_PPC64_GOT_PCREL34 relocs for symbols that turn out to be local in the output. They are made local by code near the end of _bfd_elf_link_assign_sym_version, which is called by bfd_elf_size_dynamic_sections. The problem is that ppc64_elf_edit_toc, the code that decides whether GOT entries can be eliminated, is run before bfd_elf_size_dynamic_sections, and at that stage the symbols in question are dynamic, needing GOT entries. However, we do want ppc64_elf_edit_toc to run before sizing dynamic sections as obviously the size of .got changes if ppc64_elf_edit_toc removes the need for a GOT entry. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26655] Power10 libstdc++.so R_PPC64_NONE dynamic relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=26655 Alan Modra changed: What|Removed |Added Target||powerpc64*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26655] Power10 libstdc++.so R_PPC64_NONE dynamic relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=26655 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |amodra at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
