<div class="gmail_quote">On Wed, Aug 29, 2012 at 2:20 AM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Aug 29, 2012 at 10:05 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> On Wed, Aug 29, 2012 at 1:44 AM, Hans Wennborg <<a href="mailto:hans@hanshq.net">hans@hanshq.net</a>> wrote:<br>
</div><div class="im">>>  bool LValueExprEvaluator::VisitVarDecl(const Expr *E, const VarDecl *VD)<br>
>> {<br>
>> +  if (VD->isThreadSpecified())<br>
>> +    return false;<br>
><br>
> That should be 'return Error(E);' (constant expression evaluation shouldn't<br>
> fail without producing a diagnostic). As a testcase, we should reject this:<br>
><br>
> __thread int n;<br>
> constexpr int &f() { return n; }<br>
<br>
</div>Thanks, Richard! Fixed in r162837.</blockquote><div><br></div><div>Thanks.</div><div><br></div><div>I've looked into what's specified for C++11 constant expression semantics, and it looks like this isn't the correct behavior there. C++11 thread_local variables *can* be used in core constant expressions, but can't be part of the eventual result of constant expression evaluation. It looks like the check belongs in CheckLValueConstantExpression instead.</div>
<div><br></div><div>For instance, this is valid under the C++11 rules:</div><div><br></div><div>thread_local int n;</div><div>constexpr bool b = &n == &n;</div></div>