On Sat, Feb 4, 2012 at 10:50 AM, Howard Hinnant <[email protected]> wrote: > On Feb 4, 2012, at 1:19 PM, Howard Hinnant wrote: > >> On Feb 4, 2012, at 1:16 PM, Sebastian Redl wrote: >> >>> >>> On 04.02.2012, at 19:06, Howard Hinnant wrote: >>> >>>> On Feb 4, 2012, at 12:52 PM, Howard Hinnant wrote: >>>> >>>>> On Feb 4, 2012, at 12:04 PM, Eli Friedman wrote: >>>>>> >>>>>> [expr.shift]p2: [...] if E1 has a signed type and non-negative value, >>>>>> and E1×2E2 is representable in the result type, then that is the >>>>>> resulting value; otherwise, the behavior is undefined. >>>>>> >>>>>> -Eli >>>>> >>>>> I see, you're point is that I've walked into undefined territory because >>>>> I set the sign bit on the long long? Does changing 1LL to 1ULL make the >>>>> compiler happy? >>>> >>>> Another question: Is there a motivation for giving the compile time >>>> behavior of these operations a different behavior than they would have at >>>> run time? >>> >>> The runtime behavior is undefined. Do you really want the compile time >>> behavior to be the same? >>> >>> As a side note, I think the diagnostics here could still be improved. >>> >>> Sebastian >> >> It is undefined by the standards committee which has not had the willpower >> to abandon 1's complement hardware. I believe it is well defined behavior >> on every platform we support (2's complement hardware). I believe this >> compile time behavior is overly pedantic, does not reveal any programming >> error, and will only serve up busy work for clang's clients. >> >> Howard > > Just noticed: > > On Feb 3, 2012, at 7:33 PM, Richard Smith wrote: > >> constexpr: >> The recent support for potential constant expressions exposed a bug in the >> implementation of libstdc++4.6, where numeric_limits<int>::min() is defined >> as (int)1 << 31, which isn't a constant expression. Disable the 'constexpr >> function never produces a constant expression' error inside system headers >> to compensate. > > So it appears already that this is an issue wider than just libc++. And I > would be surprised if the issue isn't wide spread. Just did a quick search > of Boost and found this: > > static BOOST_LLT min BOOST_PREVENT_MACRO_SUBSTITUTION (){ return 1LL << > (sizeof(BOOST_LLT) * CHAR_BIT - 1); } > > Please reduce this to a pedantic warning and provide a way to turn it off > locally even then.
The problem is, this affects SFINAE... -Eli _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
