<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 9, 2015 at 10:17 AM, Robinson, Paul via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><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">





<div lang="EN-US" link="blue" vlink="purple">
<div><span class="">
<p class="MsoNormal">| And at runtime, on some targets, we use this:<u></u><u></u></p>
<p class="MsoNormal">|<u></u><u></u></p>
<p class="MsoNormal">|  <a href="https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c" target="_blank">
https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c</a><u></u><u></u></p>
<p class="MsoNormal">|<u></u><u></u></p>
<p class="MsoNormal">| ... which gives a NaN in this case.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I copied that function into a test program on Ubuntu, built with gcc, and it gives me +Infinity (0x7f800000) not NaN (0x7fc00000).</span></p></div></div></blockquote><div><br></div><div>Oh right, sorry, off-by-one error when evaluating that by hand; I got 0x7fffffff (which is also a NaN, 0x7fc00000 is not the only NaN).</div><div><br></div><div>So, I think the question is, do we want to update LLVM to define the value of an out-of-range uitofp (and "fix" any targets that don't give +/- Inf for these conversions)? <a href="http://llvm.org/docs/LangRef.html#uitofp-to-instruction">http://llvm.org/docs/LangRef.html#uitofp-to-instruction</a> is clear that you get an undefined result for overflow currently.</div><div><br></div><div>In (AFAICS) all supported targets, for integer types supported by clang, there are only two ways to hit the overflow case:</div><div> 1) uint128 -> float</div><div> 2) uint64 or larger -> half</div><div><br></div><div>Case (1) goes through uitofp (which explicitly says the result is undefined at the moment), case (2) goes via @llvm.convert.to.fp16 (which says nothing about what happens in this case, but presumably it is defined). These are both phenomenally rare conversions, so adding (potential) extra cost to them to make them handle the out-of-range case correctly doesn't seem unreasonable.</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"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="15187f64ef2f2258__MailEndCompose"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></a></p>
<div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt">
<div>
<div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> <a href="mailto:metafoo@gmail.com" target="_blank">metafoo@gmail.com</a> [mailto:<a href="mailto:metafoo@gmail.com" target="_blank">metafoo@gmail.com</a>]
<b>On Behalf Of </b>Richard Smith<br>
<b>Sent:</b> Tuesday, December 08, 2015 11:42 AM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> Joerg Sonnenberger; cfe-commits (<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>)</span></p><div><div class="h5"><br>
<b>Subject:</b> Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled<u></u><u></u></div></div><p></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Tue, Dec 8, 2015 at 11:18 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Tue, Dec 8, 2015 at 10:59 AM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Okay, I'll bite:  so what *does* UINT128_MAX actually convert to?</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">$ echo 'unsigned __int128 max = -1; float f = max;' | ~/clang-8/build/bin/clang -x c++ - -emit-llvm -S -o - -O3 | grep @f<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">@f = global float undef, align 4<u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">And at runtime, on some targets, we use this:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">  <a href="https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c" target="_blank">
https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/builtins/floatuntisf.c</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">... which gives a NaN in this case.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0in 0in 0in 4pt">
<div>
<div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> cfe-commits [mailto:<a href="mailto:cfe-commits-bounces@lists.llvm.org" target="_blank">cfe-commits-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Richard Smith via cfe-commits<br>
<b>Sent:</b> Tuesday, December 08, 2015 10:52 AM<br>
<b>To:</b> Joerg Sonnenberger; cfe-commits<br>
<b>Subject:</b> Re: r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Tue, Dec 8, 2015 at 2:13 AM, Joerg Sonnenberger via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">On Mon, Dec 07, 2015 at 01:32:14PM -0800, Richard Smith via cfe-commits wrote:<br>
> C11 <a href="http://6.3.1.5/1" target="_blank">6.3.1.5/1</a>: "If the value being converted is outside the range of values<br>
> that can be represented, the behavior is undefined."<br>
<br>
The value of 1e100 can be represented as +inf, even if not precisely.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Only if +inf is in the range of representable values, which, as already noted, is problematic.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<p class="MsoNormal">This is a bit different from non-IEEE math like VAX, that doesn't have<br>
infinities.<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
Joerg<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><u></u><u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>
</div>

<br>_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div></div>