r254574 - PR17381: Treat undefined behavior during expression evaluation as an unmodeled

[Hans Wennborg via cfe-commits]

On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer <david.majnemer at gmail.com> wrote:
>
>
> On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits
> <cfe-commits at lists.llvm.org> wrote:
>>
>> On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits
>> <cfe-commits at lists.llvm.org> wrote:
>>>
>>> On Thu, Dec 03, 2015 at 01:36:22AM -0000, Richard Smith via cfe-commits
>>> wrote:
>>> > Author: rsmith
>>> > Date: Wed Dec  2 19:36:22 2015
>>> > New Revision: 254574
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=254574&view=rev
>>> > Log:
>>> > PR17381: Treat undefined behavior during expression evaluation as an
>>> > unmodeled
>>> > side-effect, so that we don't allow speculative evaluation of such
>>> > expressions
>>> > during code generation.
>>> >
>>> > This caused a diagnostic quality regression, so fix constant expression
>>> > diagnostics to prefer either the first "can't be constant folded"
>>> > diagnostic or
>>> > the first "not a constant expression" diagnostic depending on the kind
>>> > of
>>> > evaluation we're doing. This was always the intent, but didn't quite
>>> > work
>>> > correctly before.
>>> >
>>> > This results in certain initializers that used to be constant
>>> > initializers to
>>> > no longer be; in particular, things like:
>>> >
>>> >   float f = 1e100;
>>> >
>>> > are no longer accepted in C. This seems appropriate, as such constructs
>>> > would
>>> > lead to code being executed if sanitizers are enabled.
>>>
>>> This leads to some pretty annoying regressions as it now seems to be
>>> impossible to use NaN or infinites as constant initializers. Expressions
>>> like 0.0 / 0.0, 1.0 / 0.0 and -1.0 / 0.0 are perfectly well defined
>>> under normal IEEE rules, so they shouldn't be rejected.
>>
>>
>> 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.
>>
>> 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.
>>
>>> Worse, it seems
>>> even using __builtin_nan() for example doesn't work.
>>
>>
>> __builtin_nan() works fine for me, can you provide a testcase?
>>
>>> I'm not even sure about the example given in the commit message, how
>>> exactly is that undefined behavior?
>>
>>
>> C11 6.3.1.5/1: "If the value being converted is outside the range of
>> values that can be represented, the behavior is undefined."
>
>
> I don't think we want to make the UB here true UB.  It would mean that code
> which expected to get NaN might get undef, even outside of constant
> expression evaluation.  The implementation defined behavior of providing NaN
> seems more friendly...  IIRC, this broke Chrome recently because folks were
> doing this in C++.  Hans, do you remember the details?

Hmm, it doesn't ring a bell, but my memory sometimes fails me. Didn't
you and Reid look at something like this the other day? (But maybe
that was in internal code?)