Re: GCC testsuite failures for mips64vrel-elf toolchain with -mlong64 -mgp32

[Richard Sandiford <richard at codesourcery dot com>]

Nick Clifton <nickc@redhat.com> writes:
> Hi Eric, Hi Richard,
>
>   I need your brains...
>
>   The mips64vrel-elf toolchain is showing a lot of unexpected failures
>   in the gcc testsuite (and g++ testsuite) for multilibs which use
>   -mlong64 and -mgp32 together.  For example the first one I came
>   across is this:
>
>     % ... mips64vrel-elf/gcc/xgcc ... -mlong64 -mgp32 ... gcc.c-torture/compile/20010327-1.c
>     
>     gcc.c-torture/compile/20010327-1.c:12: error: initializer element is not constant
>
>   Or how about this one:
>
>     % ... mips64vrel-elf/gcc/xgcc ... gcc.c-torture/compile/mipscop-4.c ... -mlong64 -mgp32
>
>     gcc.c-torture/compile/mipscop-4.c:4: error: register specified for 'c3r1' isn't suitable for data type
>
>   The problems all seem to extend from the fact that a long is forced
>   to be 64-bits but the general purpose registers are 32-bits. What I
>   am not sure about is whether this is a generic bug in gcc somewhere
>   (that assumes that a long will fit into a register) or whether there
>   is something mips specific about the problem.  (One thing telling
>   gcc that a long is 32-bits and another thing tell it that they are
>   64-bits).
>
>   What do you think ?

I don't think there's a generic answer here.  I think you just have
to go through each test in turn and see whether the test itself is
assuming something like sizeof (void *) == sizeof (long), whether
the library is, whether gcc is, etc.  gcc.c-torture/compile/20010327-1.c
does ring a bell as one of the tests that made the assumption,
but it's been a long time...

When I last worked on this target, I ended up maintaining an on-the-side
list of expected fails.  I'm afraid I no longer have a copy of that list;
I kept it somewhere on Red Hat machines (can't remember where).

Thanks to Janis, the testsuite now has proper support for xfailing
particular multilibs, so ideally we'd do that.

Richard