1 |
On Thu, 6 Jul 2006 20:42:27 +0200 "Diego 'Flameeyes' Pettenò" |
2 |
<flameeyes@g.o> wrote: |
3 |
| > Not really. The __MAGIC__ is subject to change whenever any GCC |
4 |
| > person feels like it. |
5 |
| |
6 |
| It's not magic. But if you think that going by that trick you can |
7 |
| magically turn me in agreeing with you, good luck. |
8 |
|
9 |
They're a bunch of arbitrary somethings that may or may not be defined |
10 |
based upon whatever upstream feels like doing to the compiler this |
11 |
week. It's not like the behaviour of your hello world app, which is |
12 |
defined by international standards. |
13 |
|
14 |
| > It also doesn't work in cases where people have one of |
15 |
| > those nasty corner case CPUs (such as the 4m, which is not an m and |
16 |
| > not really a 4 either, or the USIV, or the r8k) that's best off |
17 |
| > with a weird march. |
18 |
| |
19 |
| That's what the -m{,no-}{mmx,sse,sse2,sse3,3dnow,3dnowex} flags are |
20 |
| for. |
21 |
|
22 |
Which is a horrible hack, and far less elegant than just having a |
23 |
frickin' variable telling ebuilds what to do. |
24 |
|
25 |
| > Well that's kinda the point. Since ebuild developers don't have |
26 |
| > access to every kind of CPU, relying upon the ebuilds getting it |
27 |
| > right isn't a very good idea. |
28 |
| |
29 |
| The MMX code either works or don't. Not much to think about different |
30 |
| CPUs. |
31 |
|
32 |
And in cases where the choice is "an SSE routine or an MMX routine or a |
33 |
C routine"? It's not very likely that all possibilities will get tested |
34 |
by ebuild devs. |
35 |
|
36 |
| > Since when was Gentoo about covering up for idiots who can't get |
37 |
| > their ricing correct at the expense of those who know what they're |
38 |
| > doing? |
39 |
| |
40 |
| Again, I don't see any loss for who knows what he's doing. |
41 |
|
42 |
Because you carefully snipped it out of your reply. You said yourself |
43 |
that it's a regression. |
44 |
|
45 |
| > Sure it's magic. The __DEFINES__ aren't reliable. The GCC people |
46 |
| > change them around now and again for compatibility with other |
47 |
| > compilers. |
48 |
| |
49 |
| Yeah _some_ of them are unreliable. Not those tho, as they are just |
50 |
| the same on all the GCC we support. And I doubt that next week GCC |
51 |
| 4.1.2 changes them around. |
52 |
|
53 |
Oh, you doubt, do you? Very reassuring. |
54 |
|
55 |
| > Setting CFLAGS and praying is not asking for something. Setting a |
56 |
| > MY_X86_CPU_DOES_THIS_MKAY variable is asking for something. |
57 |
| |
58 |
| And if you know what your CPU does, is it that difficult to tell the |
59 |
| compiler to use them? |
60 |
|
61 |
Yes. That -msse -mnosse2 stuff is a nasty hack, especially when one |
62 |
remembers that for years we've been screaming at users for doing just |
63 |
that. |
64 |
|
65 |
CFLAGS is not a variable that should be used to control things. It has |
66 |
a specific purpose, which is providing flags to the compiler that |
67 |
should be used when compiling C programs. You're trying to give it a |
68 |
new unrelated meaning. This is bad even if it were not for all the |
69 |
nasty side cases and added complexity. |
70 |
|
71 |
-- |
72 |
Ciaran McCreesh |
73 |
Mail : ciaran dot mccreesh at blueyonder.co.uk |
74 |
|
75 |
|
76 |
-- |
77 |
gentoo-dev@g.o mailing list |