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

[Richard Smith via cfe-commits]

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/2b664905/attachment.html>