[LLVMdev] Stange behavior in fp arithmetics on x86 (bug possibly)
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>
> >> fpfail.s:26: Error: invalid instruction suffix for `ret'
> >> I downloaded Intel manual and haven’t found any mention of retl
> > "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 <
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev