[Adding back cfe-commits] On Mon, Dec 7, 2015 at 6:46 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
> On Mon, Dec 7, 2015 at 1:59 PM, Robinson, Paul < > paul_robin...@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-boun...@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@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
