[LLVMdev] Stange behavior in fp arithmetics on x86 (bug possibly) (original) (raw)

Craig Topper craig.topper at gmail.com
Fri Oct 10 00:10:06 PDT 2014

r198756 seems to be related too. That would explain why the difference appears in 3.5 relative to 3.4.

On Thu, Oct 9, 2014 at 11:48 PM, Stephen Checkoway <s at pahtak.org> wrote:

On Oct 7, 2014, at 2:26 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Dmitry, > > On 7 October 2014 10:50, Dmitry Borisenkov <d.borisenkov at samsung.com> wrote: >> fpfail.s:26: Error: invalid instruction suffix for `ret' >> >> I downloaded Intel manual and haven’t found any mention of retl instruction, > > "retl" is the AT&T syntax for the normal "ret" instruction in the > Intel manual, which makes it mostly undocumented. Are you sure about that? I don't recall ever seeing retl before. A while back a reference for AT&T was mentioned and, as I recall, this was the best anyone had <http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf>. It contains no mention of retl. This seems to be the commit that added support for it <_ _http://lists.cs.uiuc.edu/pipermail/llvm-branch-commits/2010-May/003229.html_ _>. I'm not sure I understand the distinction between retl/retq. x86 has 4 return instruction (cribbing from the Intel manual): C3 RET Near return CB RET Far return C2 iw RET imm16 Near return + pop imm16 bytes CA iw RET imm16 Far return + pop imm16 bytes (And I think that's been true since the 8086.) Distinguishing between near and far (e.g., ret vs. lret in AT&T or retn vs. retf with some other assemblers) makes sense, but what would a l or q suffix denote? But more to the point, even if there's a good reason to accept retl/retq as input, is there any reason to emit it ever? -- Stephen Checkoway

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141010/a7ee3fe0/attachment.html>

More information about the llvm-dev mailing list