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

Joerg Sonnenberger via cfe-commits cfe-commits at lists.llvm.org
Mon Dec 7 07:25:48 PST 2015


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. Worse, it seems
even using __builtin_nan() for example doesn't work.

I'm not even sure about the example given in the commit message, how
exactly is that undefined behavior?

Joerg


More information about the cfe-commits mailing list