<div dir="ltr">On Wed, Aug 20, 2014 at 9:59 AM, Moritz Roth <span dir="ltr"><<a href="mailto:moritz.roth@arm.com" target="_blank">moritz.roth@arm.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The few failures I looked at in detail actually weren't using 64-bit<br>
integers. From what I've seen in gdb the function call to<br>
__aeabi_idivmod is fine as well, the problem seems to be in how the<br>
results are handled.<br></blockquote><div><br></div><div>Yeah, the function calls looked fine to me as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

E.g. in the code I sent yesterday, only the quotient (r0) is<br>
saved to a stack slot, the register that has the remainder (r1) is<br>
simply overwritten, and any further references to that remainder are<br>
treated as if it was the same as the quotient (i.e. loading from that<br>
spill slot).<br>
<br>
Assembly (working):<br>
        movs    r7, #31<br>
        (...)<br>
        mov     r0, r4<br>
        mov     r1, r7<br>
        bl      __aeabi_idiv<br>
        str     r0, [sp, #32]           @ 4-byte Spill [of the quotient]<br>
        mov     r0, r4<br>
        mov     r1, r7<br>
        bl      __modsi3<br>
        str     r0, [sp, #24]           @ 4-byte Spill [of the remainder]<br>
        (...)<br>
<br>
Code after r215862:<br>
        movs    r1, #31<br>
        (...)<br>
        bl      __aeabi_idivmod<br>
        str     r0, [sp, #32]           @ 4-byte Spill [just the quotient?]<br></blockquote><div><br></div><div>Hmm, somehow I missed that when I glanced at the asm output you sent out earlier.  That area does look incorrect.  You said that this same code works for -eabi targets?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        @DEBUG_VALUE: simulate:rem <- [SP+32]  ; both refer to the same<br>
        @DEBUG_VALUE: simulate:quot <- [SP+32] ; spill slot...<br>
        cmp     r4, #1<br>
        bge     .LBB3_1             ; This branch is taken, r4 = 10<br>
        b       .LBB3_42<br>
.LBB3_1:                                @ %<a href="http://for.cond3.preheader.lr.ph" target="_blank">for.cond3.preheader.lr.ph</a><br>
        ldr     r1, [sp, #104]  ; The value in r1 is lost.<br>
<br>
Unfortunately I've found it quite hard to isolate that behaviour in<br>
a reduced test case :/<br></blockquote><div><br></div><div>Im trying to decide the best thing to do here...whether we should investigate this failure (especially since its difficult to reduce) or if we should revert this for now ... though, it is something that we need to address I think.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you want, I can send more examples of miscompiled code, there<br>
are a few dozen failures across the test suites I'm running.<br></blockquote><div><br></div><div>Should the test case you sent the first time around fail on ARMv7-a as well?  If so, I should hopefully be able to reproduce it locally which would help.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers<br>
<span class="HOEnZb"><font color="#888888">Moritz<br>
</font></span><div class="im HOEnZb"><br>
> -----Original Message-----<br>
> From: Renato Golin [mailto:<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>]<br>
</div><div class="im HOEnZb">> Sent: 20 August 2014 13:44<br>
> To: Saleem Abdulrasool<br>
> Cc: LLVM Commits; Moritz Roth; Joey Gouly<br>
</div><div class="im HOEnZb">> Subject: Re: [llvm] r215862 - ARM: improve RTABI 4.2 conformance on<br>
> Linux<br>
><br>
</div><div class="HOEnZb"><div class="h5">> On 20 August 2014 03:59, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org">compnerd@compnerd.org</a>><br>
> wrote:<br>
> > Could you explain what exactly was broken?  I didn't notice anything<br>
> in the<br>
> > generated assembly (but, I could have accidentally overlooked it).<br>
> Or did<br>
> > you mean that libgcc's implementation of __aeabi_ldivmod had a bug in<br>
> it?<br>
><br>
> My memory fails me badly, but here's a long list of bugs about it:<br>
><br>
> <a href="http://llvm.org/bugs/show_bug.cgi?id=16387" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=16387</a><br>
> <a href="http://llvm.org/bugs/show_bug.cgi?id=17192" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=17192</a><br>
> <a href="http://llvm.org/bugs/show_bug.cgi?id=17193" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=17193</a><br>
> <a href="http://llvm.org/bugs/show_bug.cgi?id=17881" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=17881</a><br>
><br>
> Here's a thread I found that could also help:<br>
><br>
> <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-</a><br>
> 20130729/182718.html<br>
><br>
> Maybe Weiming (or someone else) did fix it and didn't update the bugs.<br>
><br>
> I'll let Moritz chime in on what problems he's finding, as I'm away<br>
> from the issue for a long time.<br>
><br>
> cheers,<br>
> --renato<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org
</div></div>