This is the mail archive of the
libc-alpha@sourceware.org
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: Fri, 12 Apr 2013 13:25:03 -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> <20130411215100 dot 6F0BA2C06F at topped-with-meat dot com> <516808BC dot 5000102 at redhat dot com>
> 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