Hi,<div><br></div><div>For 
{VFP, noVFP } x { fastcc, none },  only VFP x fastcc gets wrong result, others will work properly.</div><div><br></div><div>Yes, disabling VFP will solve the problem, but VFP is very common, so I would make a patch to fix it.<br>
<br>Jush<br><br><div class="gmail_quote">On Fri, Aug 10, 2012 at 6:18 PM, Renato Golin <span dir="ltr"><<a href="mailto:rengolin@systemcall.org" target="_blank">rengolin@systemcall.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 9 August 2012 12:53, Jush Lu <<a href="mailto:jush.msn@gmail.com">jush.msn@gmail.com</a>> wrote:<br>
> Currently ARMFastISel handles fastcc for caller side by simply falling<br>
> through to other calling conventions such as CC_ARM_AAPCS, but the callee<br>
> with fastcc always uses CC_ARM_AAPCS_VFP calling convention if VFP2 is<br>
> available. This inconsistency of calling conventions will make problems, and<br>
> this patch will fix it as well.<br>
<br>
</div>Hi,<br>
<br>
You don't seem to be testing all cases. You should at least test {<br>
VFP, noVFP } x { fastcc, none }, so adding some llc with VFP disabled<br>
(or on older cores) would solve that.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
cheers,<br>
--renato<br>
<br>
<a href="http://systemcall.org/" target="_blank">http://systemcall.org/</a><br>
</font></span></blockquote></div><br></div>