<div dir="ltr">Was there any specific reason to take the opposite path (from x86) ? - Just curious to know. </div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 8, 2016 at 2:33 PM, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7 September 2016 at 18:32, Somenath Chakraborty via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> The value to the formal argument is zero-extended, different from x86_64. Is<br>
> this a known issue ? Am I missing anything ?<br>
<br>
</span>This is specified in the ABI document:<br>
<a href="http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf" rel="noreferrer" target="_blank">http://infocenter.arm.com/<wbr>help/topic/com.arm.doc.<wbr>ihi0055b/IHI0055B_aapcs64.pdf</a>.<br>
<br>
Section 7.1 gives mappings from C types to underlying ones and says<br>
that "char" is actually an "unsigned byte". This applies to 32-bit<br>
AAPCS targets as well; but beware that Darwin targets don't follow<br>
AAPCS here, and char is signed again.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>