On Mon, Dec 7, 2015 at 7:25 AM, Joerg Sonnenberger via cfe-commits < cfe-commits@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."
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
