Re: [PATCH] Disable building with i386-*, -march=i386 or -mcpu=i386.

["Carlos O'Donell" <carlos at redhat dot com>]

On 04/11/2013 05:51 PM, Roland McGrath wrote:
>> Preference noted. I'd like to leave it as-is to help new developers
>> on such systems, and to assist downstream. While I agree that on
>> principle it should be a hard error, the practical side of me says
>> that it helps more than it hinders to do the elision.
> 
> I'm ambivalent enough that I don't have any more arguments on that.
> 
>> I mention again that it would be an additional enhancement to add 
>> --march=i686 when configuring for i686-* to avoid problems with 
>> users that have compilers defaulting to i386 code generation.
> 
> I don't think we should do any individual ad hoc bits like that.  We
> should only do anything like this at all if we make it thorough and
> coherent.  That is, one of:
> 
> 1. The tuple rules the roost: if you configure for i486, you get
>    -march=i486.  Likewise for i586 or i686.
> 
>    This also fixes the case of someone configuring for i586 with the
>    intent of producing binaries compatible with i586 hardware, but not
>    realizing that their compiler defaults to -march=i686.

OK.

> 2. The compiler rules the roost: the tuple just selects the top-level
>    machine architecture, and then configure examines what the
>    compiler's doing (i.e. its predefines) to choose submachine.
> 
>    This is what ARM does today.

I assume that this option encompases thing like:
CC="arm-none-linux-gnueabi-gcc -mfpu=neon -mfloat-abi=hardfp" ?

That's a ABI + hardware selection.

Where the compiler doesn't really rule the roost, but the user
still has to say which of the N code generation options should
be used to build glibc?

> 3. Something involving --with-cpu.

I like this better than compiler rules the roost.

> #1 and #2 both have the advantage of ruling out the possibility of any
> mismatch between what the compiler targets and what libc's assembly code
> targets.  

Agreed.

> #3 exists today mostly for submachines that are not
> config.sub-friendly, such as powerN for powerpc.

Right.

> #2 and #3 both could mean that someone configures with 
> i386-pc-linux-gnu as the tuple (and probably uses that tuple to name
> other things in the packaging world or whatnot) but is actually
> producing binaries only compatible with i686 or whatever.  That might
> be a bug or a feature, depending on your perspective.

Right.

> Joseph has advocated #2 before.  It seems reasonable to me.  If we'd
> thought about that route when the powerpc folks wanted what became the
> --with-cpu case, we probably never would have added --with-cpu.

Agreed.

> So my starting idea is that we do #2 for all machines, and demote the
> --with-cpu support to just being a shorthand (perhaps add --with-tune
> too).  That is, --with-cpu=foo just means CC="$CC -march=foo" and the
> actual submachine selection is still based on what the compiler says.
> The sysdeps/arm/preconfigure code would get refactored into a generic
> thing for all machines, with each sysdeps/CPU/preconfigure just
> supplying a table mapping predefine names (or patterns or regexps)
> to submachine settings.

If you agree about that my assumption about compiler rules the roost
also includes setting CC to compiler for a specific ABI/hardware
target then I would agree.

It has been a long long time since target ruled the roost, and the
target name is a fragile thing that unfortunately has been misused
or poorly used by users and developers. I don't see us recapturing
the use of target triplets for our purposes.

> We don't have the arch vs tune distinction in our submachine sysdeps
> layouts today.  We might consider adding that in some fashion.  For
> example, today some i386/foo.S and i386/i686/foo.S files don't differ
> in the set of instructions they use, just in tuning choices.

Could expand your kernel of a thought here a little more? I don't quite
see what you mean by arch vs. tune distinction?

Cheers,
Carlos.