Gentoo Archives: gentoo-dev

From: Martin Schlemmer <azarah@××××××××××××.org>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Replacing cpu-feature USE flags
Date: Fri, 07 Jul 2006 12:54:00
Message-Id: 1152276624.9384.46.camel@lycan.lan
In Reply to: Re: [gentoo-dev] Replacing cpu-feature USE flags by Brian Harring
1 On Fri, 2006-07-07 at 05:31 -0700, Brian Harring wrote:
2 > On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote:
3 > > On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote:
4 > > > On Friday 07 July 2006 01:54, Ciaran McCreesh wrote:
5 > > > > | No, we never spent years telling them not to use your so-called
6 > > > > | "CFLAGS hacks" that are rather a proper usage of what the compiler
7 > > > > | gives you.
8 > > > > Wrong. We did.
9 > > > Then you were wrong. I could have spent time explaining them when they make
10 > > > sense and why they don't in their usecases. If you did, well, then you really
11 > > > need to know better what you do because you seem to me pretty confused
12 > > > yourself, and I feel pity for you.
13 > > >
14 > >
15 > > Yes, we did. Were we wrong? Out of a purest point of view ... maybe.
16 > > The problem was though that earlier gcc's was very bad at generating
17 > > sse/sse2, and sometimes mmx code.
18 > >
19 > > Users being what they are though (ricers should say it all), they
20 > > enabled every flag that sounded like it could make their old box two
21 > > times faster. This included -msse, -msse2, etc. Which quite frankly
22 > > produced bad code in many cases. So we told the users to not add any
23 > > -m* flags, and let gcc do its job with the proper -march.
24 > >
25 > > So yeah, I can see that general use flags for cpu features might become
26 > > more tedious with the many new modules of processors out there, but to
27 > > say handle it by adding -msse, etc to CFLAGS, will surely if not on
28 > > gcc4, but then on gcc3 systems just ask for trouble.
29 > >
30 > > And yes, I know you are saying that that is not exactly what you are
31 > > proposing, but the users will see it as a clear passport to stick all
32 > > those nice sounding flags just right back in, and then it will be too
33 > > late to tell them its not proper thing to do when the bugs start
34 > > flooding in.
35 >
36 > Dumb question, but what really blocks them from doing that now for
37 > x86 (for example)?
38 >
39 > Yes, can't enable certain flags for non x86/x86_64 arches, but the con
40 > you're pointing at exists now for the most part.
41 >
42
43 I thought it was obvious, but apparently I overrated my writing
44 skills :/
45
46 Anyhow, because now we can say 'don't do that!', or just close the bug
47 as INVALID. If not, you can still try it, but the user might say we
48 told him to enable sse/whatever like that.
49
50 Also, as Luca stated, USE=mmx/sse/sse2/etc means that you enable
51 tailored mmx/sse/whatever code, that should be working fine, as it was
52 not gcc doing some shot in the dark at optimising, where if its
53 enveloped with the CFLAGS, you cannot disable broken gcc optimisations,
54 but enabled mmx/sse/whatever that should work on those older gcc's.
55
56
57 --
58 Martin Schlemmer

Attachments

File name MIME type
signature.asc application/pgp-signature