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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob 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: Sun, 14 Apr 2013 17:20:25 -0400
- 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> <20130412202503 dot 0B3932C069 at topped-with-meat dot com>
On 04/12/2013 04:25 PM, Roland McGrath wrote:
>>> 3. Something involving --with-cpu.
>>
>> I like this better than compiler rules the roost.
>
> Elaborate.
No need to, I agree with your argument about compiler rules the
roost given that it includes CC variants. I wasn't sure at the time
which is why I asked you for clarification.
>> 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. ;-)
Yes :}
>> 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.
OK, so what might we do here? Explain clearly that sysdeps/i386/i686 is
free to use instructions what would not work on i586? I figured that was
already true. Am I still missing the point?
Cheers,
Carlos.