https://sourceware.org/bugzilla/show_bug.cgi?id=32624
--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Jan Beulich from comment #6) > (In reply to H.J. Lu from comment #5) > > x: file format elf32-i386 > > > > > > Disassembly of section .text: > > > > 08048074 <_start>: > > 8048074: 8d 05 fc ff ff ff lea 0xfffffffc,%eax > > 804807a: 8d 04 25 00 90 04 08 lea 0x8049000(,%eiz,1),%eax > > This should match the earlier LEA. > > > 8048081: 81 c0 10 90 04 08 add $0x8049010,%eax > > 8048087: 03 04 25 00 90 04 08 add 0x8049000(,%eiz,1),%eax > > If the former "add" is transformed, the latter should be, too. > > > 804808e: 0f ba 25 00 90 04 08 1f btl $0x1f,0x8049000 > > 8048096: 0f ba 24 25 00 90 04 08 1f btl $0x1f,0x8049000(,%eiz,1) > > 804809f: 62 f2 75 48 8d 05 fc ff ff ff vpermb 0xfffffffc,%zmm1,%zmm0 > > This wrongly was transformed as if it was LEA; the instruction is almost > certainly going to fault when executed (unless, oddly, something is mapped > at the topmost page of the address space). It should remain untouched just > like ... > > > 80480a9: 62 f2 75 48 8d 04 25 00 90 04 08 vpermb > > 0x8049000(,%eiz,1),%zmm1,%zmm0 > > ... this one. Were you saying that ld was OK, but as generated wrong binary? If it is true, it is a real issue. -- You are receiving this mail because: You are on the CC list for the bug.
