18 unexpected failures in test suite on Darwin PowerPC #2184
Labels
Comments
And then the same picture repeats with this issue: |
|
Finally, this one fails: |
|
Is this a bigendian target? |
|
Our current debian ppc64 and ppc64le build farm is failing as well we have a few things to iron out with block expression evaluation. |
Yes, ppc on Darwin is always Big-endian. In this instance it is ppc32, which is BE on every platform. |
|
that should be fixed now that #2156 has been merged - would you mind trying again @barracuda156 ? |
|
The tests still only have |
|
Ah, I see. I thought it was a different set of tests failing, related to #1446 but it's different. Some of these are an "easy fix", I'll get them done today |
|
I'm getting the same "test1canary" failure on one of the SPARC machines on the build farm. Here is the gimple output: __attribute__((cdecl))
struct builtin_macro_eager1::main ()
{
struct D.139;
RUSTTMP.1 = *.LC1;
return D.139;
}compared to the gimple output on my personal computer: __attribute__((cdecl))
struct builtin_macro_eager1::main ()
{
struct D.87;
RUSTTMP.1.data = "test1canary";
RUSTTMP.1.len = 11;
return D.87;
} |
|
@philberty @CohenArthur Could you say what is the expected current status for BE 32-bit targets? I understand perhaps nobody tested in on macOS ppc ever since this issue, but Linux and *BSD support ppc32. If there is something in need of being tested, ping me please, I could run the build and tests. |
|
Off the top of my head the main issue will be an annoying one with block expressions and handling the little-endian big-endian cfg macros it casuses a still issue with our AST. I dont really have a feel for big-endian targets as i dont have a regular big-endian dev machine or CI pipeline on github for that. I deally if we had a CI job reporting the testsuite and pass us the logs once a week we could get a better feel of where we are at. |
|
@philberty I think Linux BE CI is doable, I have seen a couple of examples for those. I am pretty sure GCC upstream devs got some Power machines, since they run tests for GCC and it is uploaded. Unfortunately, @iains Quad is defunct presently, but all Power cpus are bi-endian. I will find examples I have seen earlier. |
|
Is there any way we could set up something with qemu in github actions? |
|
We might not need qemu though -- see https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc |
Maybe something like this? (I do not know how this works on Linux, but it was specifically used to test a package on a big-endian platform.) |
|
It looks like that uses https://github.com/r-hub/actions/blob/main/ctr-start/action.yaml, which uses docker (which apparently has builtin qemu support) |
|
@tschwinge in the weblinks section |
|
building cross toolchains for darwin works fine (and I still do this from time to time for powerpc-darwin9) - but that does not provide any way to test the output. AFAIK qemu does not support 970. (and anyway, someone would have to arrange to bootstrap OSX 10.5 on it - which is probably non-trivial). |
I thought 10.5 is supported (and ppc970, I believe, not). But specifically for endianness issues there is no requirement for a testing system to be Darwin. |
It looks like you can use simulators to do it -- https://www.gnu.org/software/gcc/simtest-howto.html (a near duplicate of https://gcc.gnu.org/wiki/Building_Cross_Toolchains_with_gcc, referenced at the top of the latter) gives more info, listing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: