<div dir="ltr">On Mon, Sep 8, 2014 at 1:19 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> Why not adjust this instead?<br>
<br>
</span>I was just being conservative. I don't know what else depends on this<br>
library and I don't want to change things outside of my scope.<br></blockquote><div><br></div><div>The current implementations actually return 0. Can you point out where that doesn't hold please? If you look at the generated code, in reality, the function is to spec as `bx lr'. The intent is that it provides a hook where you can break (without changing any state) OR replace it with the implementation that you prefer.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Since returning zero is consistent with the EABI, I don't think we<br>
should deviate from that norm, not without a lot of thought, at least.</blockquote><div><br></div><div>Yes, although the current implementation also is consistent with EABI.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
> We could use __rt_raise(2, 2), which would need to call signal as well, so<br>
> you end up growing a dependency on the target environment's libc<br>
> implementation. I think that expanding the responsibility of compiler-rt<br>
> from supporting the code generation from the compiler to integrating into<br>
> the target environment's libc can be problematic.<br>
<br>
</span>I wasn't proposing we signal, but that we return zero, instead of the argument.<br></blockquote><div><br></div><div>Fair enough. However, the point is that emulating GCC's behavior of the exception is what I was referring to.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Today we return either zero (in divmod/div/mod) or the argument (when<br>
calling div0 directly), and that's just wrong.</blockquote><div><br></div><div>Quoting the RTABI:</div><div>
<div class="" title="Page 21">
<div class="">
<div class="">
<ol start="0" style="list-style-type:none">
<li>
<pre><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><span style="font-size:9pt;font-family:CourierNewPSMT"> int __aeabi_idiv0(int return_value);<br></span><span style="font-size:9pt;font-family:CourierNewPSMT"> long long __aeabi_ldiv0(long long return_value);</span><div class="gmail_extra"><div class="gmail_quote"><div><div class="" title="Page 21"><div class=""><div class=""><p><span style="font-size:10pt;font-family:ArialMT">The *div0 functions:
</span></p></div></div></div></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><span style="font-size:8pt;font-family:Wingdings"> </span><span style="font-size:10pt;font-family:ArialMT">Return the value passed to them as a parameter. </span></blockquote></blockquote></pre>
</li>
</ol></div>
</div>
</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Is my copy out of date?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
> Why 0 and not infinity? Or some other value?<br>
<br>
</span>Because 0 is what it was before.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br>-- <br>Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org
</div></div>