Fix target default on biarch Linux/Sparc

> If you configure a biarch Linux/Sparc compiler defaulting to
> 32-bit, but give --with-cpu= for a v9 cpu it erroneously
> turns on 64-bit in TARGET_DEFAULT.

PR target/50354 reports the breakage of the opposite case after the change:
configuring for sparc64-linux --with-cpu=v8 used to build a 32-bit compiler, 
now the build aborts because of an architecture mismatch.

> The right thing to do is what the Solaris/Sparc target does,
> which is to key things off of a cpp macro (TARGET_64BIT_DEFAULT)
> which is defined by a header that gets prepended to the target
> header list based upon the target triplet.

There is a discrepancy between Solaris and Linux: on Solaris, we don't support 
the weird sparc64-* --with-cpu=v8 combination, whereas it is the default for 
some Linux distros (e.g. Debian).  So we cannot have the full symmetry here.

Something like the attached patch would be sufficient.  What do you think?


	PR target/50354
	* config/sparc/linux64.h (TARGET_DEFAULT): Only override if the default
	processor is at least V9 and TARGET_64BIT_DEFAULT is defined.

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Fri, 14 Oct 2011 20:27:03 +0200

>> If you configure a biarch Linux/Sparc compiler defaulting to
>> 32-bit, but give --with-cpu= for a v9 cpu it erroneously
>> turns on 64-bit in TARGET_DEFAULT.
> 
> PR target/50354 reports the breakage of the opposite case after the change:
> configuring for sparc64-linux --with-cpu=v8 used to build a 32-bit compiler, 
> now the build aborts because of an architecture mismatch.

Thanks for looking into this Eric.

If one wants a 32-bit default compiler, they should build for the
sparc-linux target.  And this is absolutely trivial to make happen
in the environments where this is supposedly a problem.

We could allow it for compatability, but I'd prefer not to.

> If one wants a 32-bit default compiler, they should build for the
> sparc-linux target.  And this is absolutely trivial to make happen
> in the environments where this is supposedly a problem.

I have criticized so many times this combination in the past, while Jakub and 
also you IIRC were defending it, that I find it a bit strange that the table 
have been turned like that...

> We could allow it for compatability, but I'd prefer not to.

I beg to differ though.  Breaking backward compatibility should be the last 
resort solution; restoring it in this case appears to be totally harmless.

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Fri, 14 Oct 2011 22:31:53 +0200

>> If one wants a 32-bit default compiler, they should build for the
>> sparc-linux target.  And this is absolutely trivial to make happen
>> in the environments where this is supposedly a problem.
> 
> I have criticized so many times this combination in the past, while Jakub and 
> also you IIRC were defending it, that I find it a bit strange that the table 
> have been turned like that...

The last time I discussed these kind of issues with you, I wanted us
to consider allowing the compiler to change it's output default based
upon the output of 'uname'.

This is effectively what Linux distributions on Sparc do, they provide
a special 'gcc' binary that looks at uname's output and munges the
command line to the real 'gcc' as needed.

If the primary users of gcc for this target are going to play these
games anyways, better to provide the facility in the gcc sources
itself.

Anyways, that is a seperate discussion.

>> We could allow it for compatability, but I'd prefer not to.
> 
> I beg to differ though.  Breaking backward compatibility should be the last 
> resort solution; restoring it in this case appears to be totally harmless.

Agreed, please install this patch if you haven't already.

Thanks Eric.

> Agreed, please install this patch if you haven't already.

Thanks, done after successfully bootstrapping on SPARC64/Linux.