<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger 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"><span class="">On Thu, Dec 03, 2015 at 01:36:22AM -0000, Richard Smith via cfe-commits wrote:<br>
> Author: rsmith<br>
> Date: Wed Dec  2 19:36:22 2015<br>
> New Revision: 254574<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=254574&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=254574&view=rev</a><br>
> Log:<br>
> PR17381: Treat undefined behavior during expression evaluation as an unmodeled<br>
> side-effect, so that we don't allow speculative evaluation of such expressions<br>
> during code generation.<br>
><br>
> This caused a diagnostic quality regression, so fix constant expression<br>
> diagnostics to prefer either the first "can't be constant folded" diagnostic or<br>
> the first "not a constant expression" diagnostic depending on the kind of<br>
> evaluation we're doing. This was always the intent, but didn't quite work<br>
> correctly before.<br>
><br>
> This results in certain initializers that used to be constant initializers to<br>
> no longer be; in particular, things like:<br>
><br>
>   float f = 1e100;<br>
><br>
> are no longer accepted in C. This seems appropriate, as such constructs would<br>
> lead to code being executed if sanitizers are enabled.<br>
<br>
</span>This leads to some pretty annoying regressions as it now seems to be<br>
impossible to use NaN or infinites as constant initializers. Expressions<br>
like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined<br>
under normal IEEE rules, so they shouldn't be rejected.</blockquote><div><br></div><div>Well, we have a problem. The evaluation semantics of these expressions requires code to execute in some build modes (in particular, with sanitizers enabled), and thus has a side-effect.</div><div><br></div><div>I'm inclined to relax the restriction added in this change for the specific case of global variables in C, since (as you say) there is a fair amount of code using divide-by-zero as a "portable" way of generating an inf or nan.</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">Worse, it seems<br>
even using __builtin_nan() for example doesn't work.<br></blockquote><div><br></div><div>__builtin_nan() works fine for me, can you provide a testcase?</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">
I'm not even sure about the example given in the commit message, how<br>
exactly is that undefined behavior?</blockquote><div><br></div><div>C11 <a href="http://6.3.1.5/1">6.3.1.5/1</a>: "If the value being converted is outside the range of values that can be represented, the behavior is undefined."</div><div><br></div><div>We also have C11 6.6/4: "Each constant expression shall evaluate to a constant that is in the range of representable values for its type."</div></div></div></div>