ppc64 clang LNT buildbot / reference_output / test failures

[Daniel Dunbar]

On Fri, Apr 26, 2013 at 6:38 AM, Renato Golin <renato.golin at linaro.org>wrote:

> On 26 April 2013 14:30, Hal Finkel <hfinkel at anl.gov> wrote:
>
>> 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.
>>
>
> 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).
>

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:
  http://llvm.org/viewvc/llvm-project?view=revision&revision=180647

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:
  http://llvm.org/viewvc/llvm-project?view=revision&revision=180649

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.

There are still other failures in the tests I am not sure of.

0. automotive-bitcount was obvious, I fixed it here I hope:
  http://llvm.org/viewvc/llvm-project?view=revision&revision=180648

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.

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. :(

We should fix it or remove it.

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).

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!).

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.
>

 - Daniel


>
> cheers,
> --renato
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130426/08e9b6a8/attachment.html>