On Mon, Dec 7, 2015 at 5:25 PM, Hans Wennborg <h...@chromium.org> wrote:
> On Mon, Dec 7, 2015 at 2:14 PM, David Majnemer <david.majne...@gmail.com> > wrote: > > > > > > On Mon, Dec 7, 2015 at 4:32 PM, Richard Smith via cfe-commits > > <cfe-commits@lists.llvm.org> wrote: > >> > >> 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." > > > > > > 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?) > Ah, I think you are right... Reid, do you happen to recall?
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
