1 |
On 12/02/2011 05:57 PM, Mike Frysinger wrote: |
2 |
> i'd like to think Gentoo has grown up now to the point where we don't bother |
3 |
> with trivial ricer behavior. to that end, i'd like to EOL `filter-mfpmath`. |
4 |
> |
5 |
> my main beef with filtering -mfpmath is that we use this only when someone |
6 |
> actually notices and reports misbehavior with the package in question, the |
7 |
> behavior can fluctuate between gcc versions, and it's questionable whether the |
8 |
> flag makes a significant difference in performance. considering this is x86- |
9 |
> only, and our main user base is amd64 based, it doesn't see nearly the amount |
10 |
> of attention that it did in the past. i'd prefer we leave this flag to the |
11 |
> respective upstream packages to validate when it should be used (i.e. the |
12 |
> mplayer's and ffmpeg's and such in the world). |
13 |
> |
14 |
> Ryan did a check and it seems we've got all of 5 packages (and one eclass) |
15 |
> using this. so i say it's time to scrub the tree, punt the func, and then |
16 |
> punt people who attempt to report bugs when building their whole system with - |
17 |
> mfpmath and see misbehavior. |
18 |
> -mike |
19 |
|
20 |
I've never thought of -mfpmath=sse as a "ricer" flag. If anything, it |
21 |
should make floating point calculations more consistent. Back when I |
22 |
used x86, I had it in my global CFLAGS and can't remember it causing any |
23 |
issues. |
24 |
|
25 |
The varying behavior between gcc versions seems like a possibly good |
26 |
reason to not "support" it, but I'm not familiar with this. Has it |
27 |
stabilized recently or is it still in flux? |
28 |
|
29 |
I would rather leave this in the hands of package maintainers than punt |
30 |
it globally. |