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

Pasi Parviainen pasi.parviainen at iki.fi
Fri Oct 10 04:23:57 PDT 2014

On 10.10.2014 9:48, Stephen Checkoway 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?

Since in x86 you can mix 16-bit and 32-bit code, therefore you must be able to distinguish between 16-bit and 32-bit return. And from there comes the w and l suffix for the return instruction.

code16: ret = retw => C3 retl => 66 C3

code32: ret = retl => C3 retw => 66 C3

And what comes to q suffix, it is either to be consistent or it just got cargo-culted.

Pasi

More information about the llvm-dev mailing list