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

[Roland McGrath]

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

Yes.  Hence it would also subsume --with{,out}-fp, which I'd forgotten
about.  That needs a bit more thought about all the details.

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

By "the compiler" I meant "$CC", so the compiler does rule the roost.

> > 3. Something involving --with-cpu.
> 
> I like this better than compiler rules the roost.

Elaborate.

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

Since that is indeed what I meant, then I guess you agree, in which case
you need not elaborate on your disagreement. ;-)

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

Agreed (with s/target/host/g since we're not a compiler).

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

-march=i586 -mtune=i686 produces code that executes correctly on an i586 as
well as an i686, but executes optimally only on an i686.  sysdeps/i386/i686
contains some code that won't execute correctly on an i586, but mostly
actually contains code that is just optimized for an i686.


Thanks,
Roland