> Ok, I committed your suggestion to trunk for now.
Thanks!
--
Eric Botcazou
From: David Miller
Date: Sun, 23 Oct 2011 16:32:36 -0400 (EDT)
> From: Eric Botcazou
> Date: Sun, 23 Oct 2011 11:58:57 +0200
>
>>> I'll try to brainstorm on this, thanks for letting me know about the
>>> Solaris target problem.
>>
>> Let's fix the regression quickly though.
>
> I'll fix it by
From: Eric Botcazou
Date: Sun, 23 Oct 2011 11:58:57 +0200
>> I'll try to brainstorm on this, thanks for letting me know about the
>> Solaris target problem.
>
> Let's fix the regression quickly though.
I'll fix it by the end of tonight.
> This is precisely what I tried initially, and my posting was
> explicitly trying to explain that this kind of approach cannot
> work. :-)
It will work for Richard's case though and that's clearly the most glaring
problem. Moreover, it will bring Linux on par with Solaris, which is also a
good
From: Eric Botcazou
Date: Sun, 23 Oct 2011 00:22:14 +0200
> This breaks -mcpu on Solaris though because TARGET_DEFAULT has MASK_V8PLUS.
> So any setting below or equal to -mcpu=v8 triggers an architecture mismatch
> between assembler and compiler.
>
> I think we need to go the specs route. I'd
> You can't just fix this -mv8plus problem universally using spec
> tricks. Spec rules such as "{!-mcpu*:-mcpu=v9}" never trigger for the
> default bitness, because OPTION_DEFAULT_SPECS appends "-mcpu=v7" or
> similar to the command line first.
>
> Therefore, I put the cpu bump to v9 into sparc_ov
Richard reported to me that we wouldn't have a mulsi3 pattern with
"-m32 -mv8plus", which left me dumbfounded. It seemed impossible.
Clarifying further, the case is when gcc is built for a target of
sparc64-linux. And indeed I was able to reproduce this, a 32-bit
mutliply results in a libcall.
