Nick Clifton <[EMAIL PROTECTED]> 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