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

[Howard Hinnant]

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.

Howard