<div dir="ltr">On Fri, Apr 26, 2013 at 6:38 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="im">On 26 April 2013 14:30, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><span style="color:rgb(34,34,34)">I completely agree, and we should make the reference outputs work on PPC as well. My point is that, in the mean time, we should also have a ppc64 buildbot that gives accurate feedback to the rest of the LLVM community. Fixing endianess problems in large applications can take quite a bit of time.</span></div>

</blockquote><div><br></div></div><div>Hum, I do agree that endianess is not trivial. It may even require extensive changes in the programs to convert back-and-forth. Maybe this is a genuine case for GCC runs, at least temporary. It should be possible to disable the reference output IFF (Arch == PPC && ENDIAN == BIG).</div>
</div></div></div></blockquote><div><br></div><div style>Yeah. One reasonable thing we can do in this case is include separate reference output files for big endian platforms. I went ahead and did the Makefile plumbing for this here:</div>
<div style>  <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=180647">http://llvm.org/viewvc/llvm-project?view=revision&revision=180647</a></div><div style><br></div><div style>And then I added the files you sent in all the cases where I could clearly identify that the output mismatch was an endianness problem, here:</div>
<div style>  <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=180649">http://llvm.org/viewvc/llvm-project?view=revision&revision=180649</a></div><div style><br></div><div style>I apologize for my miscommunication earlier, I thought that in the past I had made this work for PPC on Darwin but obviously I did not. I think what I remembered was I *looked* at it and realized there were endian related problems, but didn't actually fix them.</div>
<div style><br></div><div style>There are still other failures in the tests I am not sure of. </div><div style><br></div><div style>0. automotive-bitcount was obvious, I fixed it here I hope:</div><div>  <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=180648">http://llvm.org/viewvc/llvm-project?view=revision&revision=180648</a></div>
<div><br></div><div style>1. For security-{rijndahl,sha}, I couldn't immediately prove to myself there was an endian portability problem in the code, and so I didn't immediately want to add your outputs for those.<br>
</div><div style><br></div><div style>2. For office-ispell, this test just looks busted. The existing reference output is "Illegal format hash table" followed by "exit 1", and on big-endian it just differs by reporting that the file magic value is off. I checked our performance results and indeed this test executes in ~0s so we are basically just testing its error path. :(</div>
<div style><br></div><div style>We should fix it or remove it.</div><div style><br></div><div style>3. The remaining bitfield / union / casting ones are obviously not endian-portable, but that is also inherent in the nature of the test. It seems like those tests should be rewritten to do the right thing on big-endian platforms, or be excluded, or something else. In their current form I think they are not really testing what they are supposed to test on big-endian platforms (or maybe on little-endian platforms).</div>
<div style><br></div><div style>Hal, can I interest you in looking at the remaining ones and seeing if they can be fixed. If you don't have time, I am also fine if you want to just go head and check in more big-endian specific reference outputs to get things to pass on PPC (without having to double the runtime by disabling reference outputs!).</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>But first, let's look at the outputs, and let's fix as much as we can without it. I fixed many bugs on other platforms while working to get the ARM bots green, so the work on the PPC bot will probably do the same as well.</div>
</div></div></div></blockquote><div><br></div><div style> - Daniel</div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>cheers,</div><div>--renato</div><div><br></div><div><br></div></div></div></div>
</blockquote></div><br></div></div>