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

[Richard Smith via cfe-commits]

[Adding back cfe-commits]

On Mon, Dec 7, 2015 at 6:46 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Mon, Dec 7, 2015 at 1:59 PM, Robinson, Paul <
> Paul_Robinson at playstation.sony.com> wrote:
>
>> | 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 think 5.2.4.2.2/5 says if infinities are representable, there are no
>> values "outside" the floating-point range?
>>
>
> That interpretation would also require converting UINT128_MAX to float to
> have defined behavior (it must give either FLT_MAX or +inf, as those are
> the two closest represetnable values), which it does not on real hardware.
>
>
>> And 6.3.1.5/1 starts out with "if the value being converted can be
>> represented exactly in the new type, it is unchanged."  I'd think that NaNs
>> could be represented "exactly" (they can certainly be represented:
>> 5.2.4.2.2/3) despite not having an actual numeric value.
>>
>
> In talking about NaNs, you've switched to talking about a different case;
> we were talking about doubles that don't fit in a float. The division by
> zero cases have UB because 6.5.5/5 explicitly says they do.
>
>
>> I don't think 6.3.1.5/1 means to exclude NaN/infinities, given that
>> 6.3.1.4/1 explicitly refers to "finite value" wrt conversion to an
>> integer type.
>>
>> --paulr
>>
>>
>>
>> *From:* cfe-commits [mailto:cfe-commits-bounces at lists.llvm.org] *On
>> Behalf Of *Richard Smith via cfe-commits
>> *Sent:* Monday, December 07, 2015 1:32 PM
>> *To:* Joerg Sonnenberger; cfe-commits
>> *Subject:* Re: r254574 - PR17381: Treat undefined behavior during
>> expression evaluation as an unmodeled
>>
>>
>>
>> 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."
>>
>>
>>
>> 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."
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151207/8207b7ef/attachment.html>