<div>This is what I get on my Windows machine:</div><div> $ cat test.cpp</div><div> char hello;</div><div> $ <span style="line-height:1.5">bin\clang.exe -cc1 -gline-tables-only -triple i686-pc-linux -emit-obj -o z test.cpp</span></div><div> Assertion failed: DbgNode->isTemporary() && "Expected temporary node", file ..\lib\IR\DebugInfo.cpp, line 350</div><div>but on Linux it's fine.</div><div><br></div><div>Replacing </div><div><div> StorageType Storage : 2;</div></div><div>with</div><div> unsigned Storage : 2;</div><div>seems to resolve the issue.</div><div>Shall I commit this change?</div><div><br></div><div>Reid might know the enum stuff better.</div><div><br></div><div class="gmail_quote">On Tue Jan 20 2015 at 6:39:22 PM Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 2015 Jan 20, at 07:32, Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com" target="_blank" class="cremed">timurrrr@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue Jan 20 2015 at 6:20:34 PM Duncan Exon Smith <<a href="mailto:dexonsmith@apple.com" target="_blank" class="cremed">dexonsmith@apple.com</a>> wrote:<br>
><br>
><br>
> On Jan 20, 2015, at 3:48 AM, Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com" target="_blank" class="cremed">timurrrr@google.com</a>> wrote:<br>
><br>
>> Hi Duncan,<br>
>><br>
>> This has broken down "ninja check-asan" on 32-bit Windows.<br>
>> Assertion failed: Context.hasReplaceableUses() && "Expected RAUW support", file C:\src\llvm_bot\slave\win\<u></u>build\llvm\include\llvm/IR/<u></u>Metadata.h, line 976<br>
><br>
> Can you include the asan output? A backtrace? Point at a buildbot? I don't have the tools to reproduce this.<br>
><br>
> There's no public buildbot for ASan itself, but turns out this problem is not even specific to ASan.<br>
><br>
> This public bot just builds Chromium with Clang<br>
> <a href="http://build.chromium.org/p/chromium.fyi/builders/CrWinClang/builds/1295/steps/compile/logs/stdio" target="_blank" class="cremed">http://build.chromium.org/p/<u></u>chromium.fyi/builders/<u></u>CrWinClang/builds/1295/steps/<u></u>compile/logs/stdio</a><br>
><br>
> Assertion failed: isTemporary() && "Expected temporary node", file C:\b\build\slave\CrWinClang\<u></u>build\src\third_party\llvm\<u></u>include\llvm/IR/Metadata.h, line 741<br>
> since r226499.<br>
><br>
> OK, I'll try to minimize...<br>
> (I suppose the change looks sane at the first glance and you can't come up with a repro yourself)<br>
><br>
> It seems to be hard to revert now...<br>
>> You've committed a lot of small changes in a very short timeframe -<br>
><br>
> Actually, I committed work over the span of an entire work day.<br>
><br>
> Oh, I see.<br>
>> - I assume you're using git? Is there a reason why you don't squash your changes before committing? It makes finding bad commits / reverting harder...<br>
><br>
> Besides being developer policy to separate changes as much as possible, it also makes changes easier to review, and isolating which change causes a problem easier to determine.<br>
><br>
> Unless it results in complex history and back-in-forth changes, I suppose.<br>
> I've spent more than an hour today trying to locally bisect and revert the changes and ended up just locally reverting 40+ of your commits after 226490 to make progress. Unfortunately, reverting just r226490 results in a waterfall of merge conflicts.<br>
<br>
Yup, all the others depend on it. I would have dealt with it myself<br>
if a buildbot had told me about it.<br>
<br>
> Do you think it's reasonable to temporarily revert your changes in the [r226490, HEAD] range to unbreak stuff?<br>
> I have a patch ready for that.<br>
<br>
Certainly an option, although I'm actively looking at this right now<br>
(sorry for the delay, I'm in PDT so I just woke up).<br>
<br>
Did you do a full bisect? Are you sure that leaving this in and<br>
reverting the ones that follow don't also fix it?<br>
<br>
Do you know if MSVC handles things like:<br>
<br>
enum StorageType { ... };<br>
StorageType Storage : 2;<br>
<br>
correctly (well, the way I expect), or should I store it as an<br>
<br>
unsigned Storage : 2;<br>
<br>
for compatibility? Any chance it causes a weird layout problem that<br>
this commit happens to point out?<br>
<br>
(Given that this is MSVC-only, I suspect there's a layout problem or<br>
UB somewhere.)<br>
<br>
>> On Mon Jan 19 2015 at 10:30:36 PM Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" target="_blank" class="cremed">dexonsmith@apple.com</a>> wrote:<br>
>> Author: dexonsmith<br>
>> Date: Mon Jan 19 13:26:24 2015<br>
>> New Revision: 226490<br>
>><br>
>> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=226490&view=rev" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-<u></u>project?rev=226490&view=rev</a><br>
>> Log:<br>
>> IR: Remove direct comparisons against Metadata::Storage, NFC<br>
>><br>
>> Modified:<br>
>> llvm/trunk/lib/IR/Metadata.cpp<br>
>><br>
>> Modified: llvm/trunk/lib/IR/Metadata.cpp<br>
>> URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/IR/Metadata.cpp?rev=226490&r1=226489&r2=226490&view=diff" target="_blank" class="cremed">http://llvm.org/viewvc/llvm-<u></u>project/llvm/trunk/lib/IR/<u></u>Metadata.cpp?rev=226490&r1=<u></u>226489&r2=226490&view=diff</a><br>
>> ==============================<u></u>==============================<u></u>==================<br>
>> --- llvm/trunk/lib/IR/Metadata.cpp (original)<br>
>> +++ llvm/trunk/lib/IR/Metadata.cpp Mon Jan 19 13:26:24 2015<br>
>> @@ -402,7 +402,7 @@ MDNode::MDNode(LLVMContext &Context, uns<br>
>> for (unsigned I = 0, E = MDs.size(); I != E; ++I)<br>
>> setOperand(I, MDs[I]);<br>
>><br>
>> - if (Storage == Temporary)<br>
>> + if (isTemporary())<br>
>> this->Context.makeReplaceable(<br>
>> make_unique<<u></u>ReplaceableMetadataImpl>(<u></u>Context));<br>
>> }<br>
>> @@ -416,7 +416,7 @@ static bool isOperandUnresolved(Metadata<br>
>> UniquableMDNode::<u></u>UniquableMDNode(LLVMContext &C, unsigned ID,<br>
>> StorageType Storage, ArrayRef<Metadata *> Vals)<br>
>> : MDNode(C, ID, Storage, Vals) {<br>
>> - if (Storage != Uniqued)<br>
>> + if (!isUniqued())<br>
>> return;<br>
>><br>
>> // Check whether any operands are unresolved, requiring re-uniquing.<br>
>> @@ -432,7 +432,7 @@ UniquableMDNode::<u></u>UniquableMDNode(LLVMCon<br>
>> }<br>
>><br>
>> void UniquableMDNode::resolve() {<br>
>> - assert(Storage == Uniqued && "Expected this to be uniqued");<br>
>> + assert(isUniqued() && "Expected this to be uniqued");<br>
>> assert(!isResolved() && "Expected this to be unresolved");<br>
>><br>
>> // Move the map, so that this immediately looks resolved.<br>
>><br>
>><br>
>> ______________________________<u></u>_________________<br>
>> llvm-commits mailing list<br>
>> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
<br>
</blockquote></div>