From: David Miller <da...@davemloft.net>
Date: Wed, 02 Nov 2011 18:30:56 -0400 (EDT)
> From: Joel Sherrill <joel.sherr...@oarcorp.com>
> Date: Wed, 2 Nov 2011 16:29:16 -0500
>
>> Is this similar to what I just got for sparc-rtems when compiling
>> libgcc2 with -mcpu=v8?
>>
>> /tmp/cczMc4jN.s: Assembler messages:
>> /tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for
>> "smul".
>> /tmp/cczMc4jN.s:18: Error: Hardware capability "mul32" not enabled for
>> "smul".
>> /tmp/cczMc4jN.s:22: Error: Hardware capability "mul32" not enabled for
>> "umul".
>>
>> I can prepare a PR if you think it is different.
>
> I don't think so. The bug I'm hitting seems to be simply that
> config/sparc/t-linux64 wasn't migrated up into the libgcc configure
> area properly the way that config/sparc/t-linux was.
Actually the problem is that libgcc/config.host checks ${host}
to decide whether to append config/sparc/t-softmul to the tmake
variable.
But when multilibbing 64-bit libraries on a 32-bit hosted build
configured with --enable-targets=all, the host will be sparc-*-linux
even when building the 64-bit libgcc.
So t-softmul gets appended anyways, and this causes us to try and
build config/sparc/lb1spc.S for the 64-bit libgcc which we should
never do.
And it will do the wrong thing in the opposite case too, when building
a 64-bit hosted sparc gcc, host will be sparc64-*-* when building the
multilib 32-bit libgcc, and in that cast config.host will not append
t-softfp even when it should.
I sure wish these changes got a lot more testing before they were
installed :-/
