[Bug ld/2362] SH: Hidden symbol in DSO does not be forced local
https://sourceware.org/bugzilla/show_bug.cgi?id=2362 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/18700] Wrong code generated on i386 for instructions with AVX-512 {sae}
https://sourceware.org/bugzilla/show_bug.cgi?id=18700
--- Comment #4 from lili.cui at intel dot com ---
This is not an issue anymore.
I tested these instructions on a machine with AVX512 and they are correct.
1222 :
1222: f3 0f 1e fa endbr64
1226: 55 push %rbp
1227: 48 89 e5mov%rsp,%rbp
122a: 62 f1 f5 18 c2 ca 00vcmpeqpd {sae},%zmm2,%zmm1,%k1
1231: 62 f1 f5 48 c2 ca 00vcmpeqpd %zmm2,%zmm1,%k1
1238: 62 f1 f7 18 c2 ca 00vcmpeqsd {sae},%xmm2,%xmm1,%k1
123f: 62 f1 f7 08 c2 ca 00vcmpeqsd %xmm2,%xmm1,%k1
1246: 62 f1 f5 38 c2 ca 00vcmpeqpd {sae},%zmm2,%zmm1,%k1
124d: 5d pop%rbp
124e: c3 ret
For "62 f1 f5 38 c2 ca 00vcmpeqpd {sae},%zmm2,%zmm1,%k1"
I think when reg-reg and EVEX.b is 1, vcmpeqpd will ignore EVEX.L'L(I tested
them in the foo), and when EVEX.b is 0, EVEX.L'L makes sense.
Thanks to Michael for pointing out the inconsistencies in SDM. I checked them
one by one in SDM and found that they have all been corrected. Now the logic is
clearer.
For vcmpeqpd :
1c: 62 f1 f5 18 c2 ca 00vcmpeqpd {sae},%zmm2,%zmm1,%k1
23: 62 f1 f5 38 c2 ca 00vcmpeqpd {sae},%zmm2,%zmm1,%k1
2a: 62 f1 f5 58 c2 ca 00vcmpeqpd {sae},%zmm2,%zmm1,%k1
31: 62 f1 f5 78 c2 ca 00vcmpeqpd {sae},%zmm2,%zmm1,%k1
I think when reg-reg and EVEX.b is 1, vcmpeqpd will ignore EVEX.L'L(I tested
them in the foo), and when EVEX.b is 0, EVEX.L'L makes sense.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/18700] Wrong code generated on i386 for instructions with AVX-512 {sae}
https://sourceware.org/bugzilla/show_bug.cgi?id=18700 Sam James changed: What|Removed |Added Resolution|--- |OBSOLETE Status|NEW |RESOLVED --- Comment #5 from Sam James --- Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/32324] Stripping BOLT'ed binaries leads to unwanted behaviour
https://sourceware.org/bugzilla/show_bug.cgi?id=32324 --- Comment #1 from Andre Vieira --- I did a bit more investigation and looking through the sections in the warning I noticed something odd. readelf --sections shows me: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align ... [29] .eh_frame PROGBITS 00a0 0060 3d08 A 0 0 8 [30] .eh_frame_hdr PROGBITS 00a03d08 00603d08 0974 A 0 0 1 and readelf -l shows me that .eh_frame and .eh_frame_hdr are meant to go in the following segment (eh_frame_hdr also goes in the GNU_EH_FRAME): Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz Flags Align ... LOAD 0x0020 0x0060 0x0060 0x0040467c 0x0040467c R E0x20 It fails to allocate this section into this segment because the segment's p_vaddr as calculated by: assign_file_positions_for_load_sections through: p->p_vaddr = (m->sections[0]->vma + m->p_vaddr_offset) * opb; is only 0x430120 which leads to the warning because ELF_SECTION_IN_SEGMENT_1 fails the vma check: ((sec_hdr)->sh_addr - (segment)->p_vaddr + ELF_SECTION_SIZE(sec_hdr, segment)) <= (segment)->p_memsz which leads to: 0xa0 - 0x430120 + 0x3d08 <= 0x40467c 0x5d3be8 <= 0x40467c false This seems odd to me, given the section addres sh_addr, is now even beyond the 'new' end of the segment (p_vaddr + p_memsz), but it wasn't before. So we seem to have moved the start of the segment but not the location of the sections? -- You are receiving this mail because: You are on the CC list for the bug.
