1 |
Lionel Bouton <lionel-dev@××××××.name> posted |
2 |
4522ED7B.8040205@××××××.name, excerpted below, on Wed, 04 Oct 2006 |
3 |
01:08:43 +0200: |
4 |
|
5 |
> Here's the third version of the draft, wiki-free and with less sugar |
6 |
> too. More warnings. |
7 |
|
8 |
Thanks for your patience in drafting this. I believe it's well worth the |
9 |
trouble and will likely be of help to many users. =8^) |
10 |
|
11 |
> Being able to tune the CFLAGS is part of one of the core principles of |
12 |
> Gentoo: let the user be in control. Being in control brings both |
13 |
> benefits and problems. CFLAGS tuning is not an exception. |
14 |
|
15 |
I read the feedback on the earlier versions and some may not agree with me |
16 |
here (fine by me), but this now seems a bit awkwardly worded ("part of |
17 |
one") and IMO actually waters it down a bit /too/ far. Perhaps rewording a |
18 |
bit makes it less awkward? How does the following work for the first |
19 |
sentence above. (Linking the official Gentoo about page /is/ acceptable, |
20 |
one hopes.) |
21 |
|
22 |
Being able to tune CFLAGS is part of the user control and extreme |
23 |
configurability that are hallmarks of the <uri |
24 |
link=http://www.gentoo.org/main/en/about.xml> Gentoo experience</uri>. |
25 |
|
26 |
> <warn> |
27 |
|
28 |
Good! Keep the warning just like it is, and where it is, right up front! |
29 |
=8^) |
30 |
|
31 |
> <li>nss_ldap stopped working with <c>-ffast-math</c> (reported to break |
32 |
> many packages changing with the actual gcc version)</li> |
33 |
|
34 |
I believe some of the discomfort you are seeing stems from wording like |
35 |
this. -ffast-math in general CFLAGS has been repeatedly referenced as |
36 |
/the/ archetypical example of riced out users gone totally ricer-mad |
37 |
insane. In fact, there was discussion a couple months ago of replacing |
38 |
all those calls to filter-flags -ffast-math with a (possibly |
39 |
portage-universal) call to die -- emerge simply refusing to do /anything/ |
40 |
but spit out the warning, until that flag was removed. |
41 |
|
42 |
The choice of wording on this flag then remains FAR too mild to satisfy |
43 |
many. Something along the lines of "this flag may cause your computer to |
44 |
incinerate like a Sony battery powered laptop!" I'm sure would be far more |
45 |
to their liking. =8^P |
46 |
|
47 |
A bit more seriously, a warning that at minimum, users choosing to use |
48 |
this flag can expect many bugs they file to be closed INVALID or WONTFIX, |
49 |
regardless of whether the bug is related or not, simply due to the number |
50 |
of packages that this flag has been found to break and therefore the level |
51 |
of reliability of the reporter found to be using it, might be appropriate. |
52 |
Or simply, a DON'T USE THIS FLAG. YOU HAVE BEEN WARNED, if you prefer. |
53 |
The latter may seem a bit extreme, but look at it from the viewpoint of a |
54 |
developer who has repeatedly spent hours tracking down bugs, only to find |
55 |
out they are related to something "stupid" like this, and it really |
56 |
doesn't seem so extreme after all. |
57 |
|
58 |
> <li>if you used gcc-4.0, <c>-ftree-loop-linear</c> now breaks in |
59 |
> gcc-4.1 (at least with mesa)</li> |
60 |
|
61 |
Please change the reference to gcc-4.0. That's needlessly confusing, |
62 |
given that gcc-4.0 was never unmasked even to ~arch on Gentoo, especially |
63 |
when you also mention 4.1 and are actually talking about it. Maybe simply |
64 |
gcc-4, or gcc4? |
65 |
|
66 |
> <li>again for gcc-4.0 users, <c>-ftree-vectorize</c> is known to be |
67 |
> broken in gcc-4.1 (at least for x86 and ppc, amd64 users seem to be |
68 |
> safe)</li> |
69 |
|
70 |
I posted about this one before, but never saw my message on the list, so |
71 |
it may not have made it. AFAIK, you are correct on x86/ppc, it breaks |
72 |
there. However, I'd be rather more careful about saying "amd64 users seem |
73 |
to be safe" with it. Unfortunately, many users are likely to parse that |
74 |
as "amd64 users WILL be safe with it." Maybe something along the lines of... |
75 |
|
76 |
amd64 users have reported fewer problems with this flag, but no guarantees. |
77 |
|
78 |
> <li><c>-fforce-addr</c> and <c>-fweb</c> break regularly on x86 with |
79 |
> video libraries or graphic processing apps which use hand-optimised ASM</li> |
80 |
|
81 |
Conversely here, you don't mention other platforms at all, but I've been |
82 |
using -fweb on amd64 for a very long time, likely since gcc-3.3, with few |
83 |
if any issues. I'd personally call it relatively safe on amd64, but would |
84 |
tend toward a bit more caution for GWN publication, with wording much like |
85 |
that suggested for -ftree-vectorize. IOW... |
86 |
|
87 |
amd64 users report fewer problems with this flag, but again, no guarantees. |
88 |
|
89 |
|
90 |
> <p>There are known-to-be-broken flags for all GCC versions that you want |
91 |
> to check for too:</p> |
92 |
[snip] |
93 |
> <li>-frename-registers</li> |
94 |
|
95 |
Same here as with -fweb. I've been using it for quite awhile on amd64, no |
96 |
known issues, so suggested similar or identical wording to the above. |
97 |
|
98 |
> <li>-msse -mmmx -m3dnow</li> |
99 |
|
100 |
You might mention that for amd64, these (except for -sse2 on the latest |
101 |
amd versions) are wrapped up in the -march=k8/nocona/whatever, that should |
102 |
be set for your hardware as appropriate. Thus, as long as that's set, no |
103 |
need to worry about these at all on amd64. |
104 |
|
105 |
> Users with unsupported CFLAGS might want to return to safe CFLAGS (see |
106 |
> warning above) if recent updates caused them stability problems. On the |
107 |
> other hand, more adventurous users might want to experiment with CFLAGS |
108 |
> that didn't work properly with gcc-3.4.6... As always, the user is in |
109 |
> control (and the gun pointed to their feet is in his/her hand). </p> |
110 |
|
111 |
As with the intro warning, this looks perfect just as it is! =8^) |
112 |
|
113 |
> <p>Final notes:</p> |
114 |
> <ul> |
115 |
> <li>The gcc man page contains warnings for some unsafe optimization |
116 |
> options. You should read it carefully when you experiment with CFLAGS or |
117 |
> upgrade GCC on a CFLAGS-customized Gentoo.</li> <li>Some options that |
118 |
> are unsafe in the system-wide CFLAGS might be added automatically in |
119 |
> some ebuilds if the developper deems them safe (by redefining CFLAGS or |
120 |
> using append-flags of the flag-o-matic eclass). For example |
121 |
> <c>-ffast-math</c> is added by the xmame/xmess ebuilds on most |
122 |
> architectures even if you don't put it in your CFLAGS.</li> <li>You |
123 |
> might get an idea of the stability issues of a specific optimization |
124 |
> option by running: <c>find /usr/portage -name '*.ebuild'| xargs grep -- |
125 |
> '-<your-risky-optimization-option>'</c>. It takes quite some time, but |
126 |
> might be enlightening: look for the 'filter-flags'.</li> </ul> |
127 |
|
128 |
Likewise here, perfect, with one tiny exception. In keeping with the |
129 |
above suggested far stronger wording on -ffast-math, change "even if you |
130 |
don't put it in your CFLAGS" to "even tho you SHOULD NOT put it in your |
131 |
CFLAGS". |
132 |
|
133 |
JMHO as a(n amd64) user, FWIW, but HIH. |
134 |
|
135 |
-- |
136 |
Duncan - List replies preferred. No HTML msgs. |
137 |
"Every nonfree program has a lord, a master -- |
138 |
and if you use the program, he is your master." Richard Stallman |
139 |
|
140 |
-- |
141 |
gentoo-dev@g.o mailing list |