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

[Roland McGrath <roland at hack dot frob dot com>]

> 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.

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.

3. Something involving --with-cpu.

#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.  

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

#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.

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.

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.

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.


Thanks,
Roland