[cfe-commits] libc++ and const expr.

[Eli Friedman]

On Sat, Feb 4, 2012 at 10:50 AM, Howard Hinnant <hhinnant at apple.com> 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