<br><br><div class="gmail_quote">Le 5 février 2012 00:03, Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Feb 4, 2012, at 5:42 PM, Eli Friedman wrote:<br>
<br>
> On Sat, Feb 4, 2012 at 11:49 AM, Howard Hinnant <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>> wrote:<br>
>> On Feb 4, 2012, at 2:29 PM, Eli Friedman wrote:<br>
>><br>
>>> On Sat, Feb 4, 2012 at 10:50 AM, Howard Hinnant <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>> wrote:<br>
>>>> On Feb 4, 2012, at 1:19 PM, Howard Hinnant wrote:<br>
>>>><br>
>>>>> On Feb 4, 2012, at 1:16 PM, Sebastian Redl wrote:<br>
>>>>><br>
>>>>>><br>
>>>>>> On 04.02.2012, at 19:06, Howard Hinnant wrote:<br>
>>>>>><br>
>>>>>>> On Feb 4, 2012, at 12:52 PM, Howard Hinnant wrote:<br>
>>>>>>><br>
>>>>>>>> On Feb 4, 2012, at 12:04 PM, Eli Friedman wrote:<br>
>>>>>>>>><br>
>>>>>>>>> [expr.shift]p2: [...] if E1 has a signed type and non-negative value,<br>
>>>>>>>>> and E1×2E2 is representable in the result type, then that is the<br>
>>>>>>>>> resulting value; otherwise, the behavior is undefined.<br>
>>>>>>>>><br>
>>>>>>>>> -Eli<br>
>>>>>>>><br>
>>>>>>>> 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?<br>
>>>>>>><br>
>>>>>>> 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?<br>
>>>>>><br>
>>>>>> The runtime behavior is undefined. Do you really want the compile time behavior to be the same?<br>
>>>>>><br>
>>>>>> As a side note, I think the diagnostics here could still be improved.<br>
>>>>>><br>
>>>>>> Sebastian<br>
>>>>><br>
>>>>> 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.<br>

>>>>><br>
>>>>> Howard<br>
>>>><br>
>>>> Just noticed:<br>
>>>><br>
>>>> On Feb 3, 2012, at 7:33 PM, Richard Smith wrote:<br>
>>>><br>
>>>>> constexpr:<br>
>>>>>  The recent support for potential constant expressions exposed a bug in the<br>
>>>>>  implementation of libstdc++4.6, where numeric_limits<int>::min() is defined<br>
>>>>>  as (int)1 << 31, which isn't a constant expression. Disable the 'constexpr<br>
>>>>>  function never produces a constant expression' error inside system headers<br>
>>>>>  to compensate.<br>
>>>><br>
>>>> 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:<br>
>>>><br>
>>>>      static BOOST_LLT min BOOST_PREVENT_MACRO_SUBSTITUTION (){ return 1LL << (sizeof(BOOST_LLT) * CHAR_BIT - 1); }<br>
>>>><br>
>>>> Please reduce this to a pedantic warning and provide a way to turn it off locally even then.<br>
>>><br>
>>> The problem is, this affects SFINAE...<br>
>><br>
>> You are much more familiar with Chapter 14 than I am.  However in all places I'm aware, if the standard says that something is undefined behavior, the implementation can do anything it wants.  It can cause toilets to explode.  Or it can simply do what it believes its customers wanted in the first place.  I believe this is a case where we should do the latter.<br>

><br>
> The issue is that with DR1313, "an operation that would have undefined<br>
> behavior" is not a constant expression.  Therefore, given a function<br>
> template like "template<bool b> void f(int (*a)[b ? 1 << 31]);", b ==<br>
> false is required to cause a substitution failure.<br>
><br>
> -Eli<br>
<br>
</div></div>Thank you for that link.  I will pursue this issue at the meeting next week and report back whatever the outcome is.<br>
<br>
As Richard reports that changing the 1LL to 1ULL fixes the issue, perhaps our customers who are caught by this will not be so irritated if they know the solution is this simple.  But I will still run this by the CWG to see if they would rather change this to be implementation defined behavior instead of undefined behavior.<br>

<span class="HOEnZb"><font color="#888888"><br>
Howard<br>
</font></span><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br>Sorry for barging in...<br><br>Still I find the issue of SFINAE worrying, for portability. Looking at the example provided by Richard:<br>
<br><div>template<int n> auto f(int (&x)[n]) -> typename 
std::enable_if<(1 << n) < kMaxTableSize, int>::type {</div><div>  // ...<br><br>If the CWG make it implementation defined and clang chooses to make it work while gcc does not (I would be more worrid about MSVC I guess, since clang and gcc are much closer), then we end up with a significant difference in behavior between compilers. And those differences are always a pain to deal with.<br>
</div><br>I honestly don't think that a lukewarm approach is going to cut it here, either the CWG makes it well-defined or leaves it undefined and thus all compilers accept or reject it (respectively). Otherwise we are in for a world of hurt.<br>
<br>-- Matthieu<br></div></div>