This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Disable building with i386-*, -march=i386 or -mcpu=i386.
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>, Andreas Jaeger <aj at suse dot com>, Thomas Schwinge <thomas at codesourcery dot com>
- Date: Thu, 11 Apr 2013 14:51:00 -0700 (PDT)
- Subject: Re: [PATCH] Disable building with i386-*, -march=i386 or -mcpu=i386.
- References: <513FE49D dot 3050406 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1303131610540 dot 19781 at digraph dot polyomino dot org dot uk> <51526E77 dot 4040801 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1303271431550 dot 23096 at digraph dot polyomino dot org dot uk> <5154668A dot 6000700 at redhat dot com> <5160465E dot 8060400 at redhat dot com> <20130408210918 dot D97632C074 at topped-with-meat dot com> <51634DE2 dot 1060109 at redhat dot com> <20130408231128 dot DA09C2C0A2 at topped-with-meat dot com> <51640354 dot 1080808 at redhat 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
#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.