1 |
On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote: |
2 |
> On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote: |
3 |
> > On Friday 07 July 2006 01:54, Ciaran McCreesh wrote: |
4 |
> > > | No, we never spent years telling them not to use your so-called |
5 |
> > > | "CFLAGS hacks" that are rather a proper usage of what the compiler |
6 |
> > > | gives you. |
7 |
> > > Wrong. We did. |
8 |
> > Then you were wrong. I could have spent time explaining them when they make |
9 |
> > sense and why they don't in their usecases. If you did, well, then you really |
10 |
> > need to know better what you do because you seem to me pretty confused |
11 |
> > yourself, and I feel pity for you. |
12 |
> > |
13 |
> |
14 |
> Yes, we did. Were we wrong? Out of a purest point of view ... maybe. |
15 |
> The problem was though that earlier gcc's was very bad at generating |
16 |
> sse/sse2, and sometimes mmx code. |
17 |
> |
18 |
> Users being what they are though (ricers should say it all), they |
19 |
> enabled every flag that sounded like it could make their old box two |
20 |
> times faster. This included -msse, -msse2, etc. Which quite frankly |
21 |
> produced bad code in many cases. So we told the users to not add any |
22 |
> -m* flags, and let gcc do its job with the proper -march. |
23 |
> |
24 |
> So yeah, I can see that general use flags for cpu features might become |
25 |
> more tedious with the many new modules of processors out there, but to |
26 |
> say handle it by adding -msse, etc to CFLAGS, will surely if not on |
27 |
> gcc4, but then on gcc3 systems just ask for trouble. |
28 |
> |
29 |
> And yes, I know you are saying that that is not exactly what you are |
30 |
> proposing, but the users will see it as a clear passport to stick all |
31 |
> those nice sounding flags just right back in, and then it will be too |
32 |
> late to tell them its not proper thing to do when the bugs start |
33 |
> flooding in. |
34 |
|
35 |
Dumb question, but what really blocks them from doing that now for |
36 |
x86 (for example)? |
37 |
|
38 |
Yes, can't enable certain flags for non x86/x86_64 arches, but the con |
39 |
you're pointing at exists now for the most part. |
40 |
|
41 |
~harring |