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