<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Assertion `E->isNonOdrUse() != NOUR_Unevaluated && "should not emit an unevaluated operand"' with sizeof"
href="https://bugs.llvm.org/show_bug.cgi?id=43080">43080</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Assertion `E->isNonOdrUse() != NOUR_Unevaluated && "should not emit an unevaluated operand"' with sizeof
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>C++
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>efriedma@quicinc.com
</td>
</tr>
<tr>
<th>CC</th>
<td>blitzrakete@gmail.com, dgregor@apple.com, erik.pilkington@gmail.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>Testcase (C++):
int f(int i) { return sizeof i<i; }
clang-10: [...]/llvm/tools/clang/lib/CodeGen/CGExpr.cpp:2518:
clang::CodeGen::LValue clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(const
clang::DeclRefExpr *): Assertion `E->isNonOdrUse() != NOUR_Unevaluated &&
"should not emit an unevaluated operand"' failed.
What I think is happening is that the parser sees "i<", so ParseCastExpression
calls checkPotentialAngleBracket. That tries to speculatively parse the second
"i", to try to disambiguate a template-id. It then backs out, but at that
point we've already annotated the token with a DeclRefExpr. That DeclRefExpr
is incorrectly marked unevaluated because "isUnevaluatedContext()" is true when
the expression is created.
We could probably teach mightBeIntendedToBeTemplateName so it knows that a
local variable is never a template name... that avoids the problem here. And I
think we can always determine whether a expression is "considered to refer to a
template" per [temp.names]? But that makes diagnostics worse on some
testcases. And I'm not sure checkPotentialAngleBracket is the only way to
trigger this sort of issue.
Alternatively, we could try to solve the issue at the point we parse the
annotated token. Maybe we could throw away the expression? Rewrite the
expression it like we do typeid() expressions? Something else?
The assertion is new in r363295, but the issue isn't, I think. This particular
formulation triggers a different assertion on older versions of clang.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>