[llvm-bugs] [Bug 47731] Several Mips, X86 CodeGen tests FAIL on Solaris/sparcv9

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=47731

Rainer Orth <ro at gcc.gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #21 from Rainer Orth <ro at gcc.gnu.org> ---
(In reply to Eli Friedman from comment #20)
> 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.

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
(http://lab.llvm.org:8014/#/builders/134)
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.

> (In reply to Rainer Orth from comment #15)
> > 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.)

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201108/749f59f3/attachment.html>