<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:ro@gcc.gnu.org" title="Rainer Orth <ro@gcc.gnu.org>"> <span class="fn">Rainer Orth</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Several Mips, X86 CodeGen tests FAIL on Solaris/sparcv9"
href="https://bugs.llvm.org/show_bug.cgi?id=47731">bug 47731</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Several Mips, X86 CodeGen tests FAIL on Solaris/sparcv9"
href="https://bugs.llvm.org/show_bug.cgi?id=47731#c21">Comment # 21</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Several Mips, X86 CodeGen tests FAIL on Solaris/sparcv9"
href="https://bugs.llvm.org/show_bug.cgi?id=47731">bug 47731</a>
from <span class="vcard"><a class="email" href="mailto:ro@gcc.gnu.org" title="Rainer Orth <ro@gcc.gnu.org>"> <span class="fn">Rainer Orth</span></a>
</span></b>
<pre>(In reply to Eli Friedman from <a href="show_bug.cgi?id=47731#c20">comment #20</a>)
<span class="quote">> It looks like StackSlotColoring has one other possibly relevant flag: you
> could try "-ssc-dce-limit=0". I think that will remove the diff noted in
> the comment.
>
> Beyond that, I think you could add a mechanism to limit the number of stack
> slots that are colored by StackSlotColoring, and bisect using that?
>
> Thinking about it a bit more, I have another theory for what might be going
> wrong: some code could be using uninitialized data, and we're getting
> lucky/unlucky. This can be nasty to diagnose... one trick I've used in the
> past is hacking the assembly to memset the stack to zero before returning.</span >
I didn't get back to this in a while, but recently found that the bug has
gone away. Looing at the new Linux/sparc64 buildbot
(<a href="http://lab.llvm.org:8014/#/builders/134">http://lab.llvm.org:8014/#/builders/134</a>)
which unlike my Solaris/sparcv9 one runs 2-stage builds), one can see that the
failures went away betweens builds 38 and 40. Given the large number of
changes
included in those two, it's difficult to tell exactly which patch fixed the
issue,
but it seems plausible that one of Simon's did.
Given that the failures haven't resurfaced since, I guess we can safely close
this PR.
<span class="quote">> (In reply to Rainer Orth from <a href="show_bug.cgi?id=47731#c15">comment #15</a>)
> > I can't help but feel that this is a total waste of my time: this is a
> > spare-time
> > activity and the result won't even be seen in the Solaris/sparcv9 buildbot
> > which is native-only. I think this is something for some SPARC maintainer to
> > look into.
>
> There is no SPARC maintainer, really; it's just various people keeping it
> limping in their spare time. So if you don't look, nobody is going to look.
> (The primary reason we haven't just killed off the backend is that SPARC is
> widely used in academia.)</span >
I wasn't aware of that, given that the the llvm/CODE_OWNERS.TXT still lists
a SPARC maintainer. Fortunately, the GCC situation is different here: we do
have an active SPARC maintainer and Oracle contributed several large patches to
support newer SPARC CPUs in recent years.</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>