| 1 |
On Tuesday 11 July 2006 04:32, Ryan Hill wrote: |
| 2 |
> If yes, why ? And what is your better idea ? |
| 3 |
> |
| 4 |
> I prefer a filter-flags with a ewarn (or elog, haven't read that thread yet |
| 5 |
> ;)) message. |
| 6 |
> |
| 7 |
> * The -ffast-math option is known to break this package and has been |
| 8 |
> filtered from your CFLAGS. Link to Safe CFLAGS wiki page, blah blah blah. |
| 9 |
> |
| 10 |
> I like this better because it informs me of what I did wrong, what was done |
| 11 |
> to correct it, and how I can correct it for myself in the future if I |
| 12 |
> choose to. I don't like artificial barriers and things not working without |
| 13 |
> immediate attention. Call me lazy but it's annoying when you know what |
| 14 |
> you're doing yet you have to jump through hoops to get it done. |
| 15 |
|
| 16 |
The die would use the same message. Next, it would actually stop immediately |
| 17 |
instead of letting you continue further and break in the long run. |
| 18 |
Using -ffast-math globally is just broken. In some packages it may work. In |
| 19 |
others it doesn't. |
| 20 |
|
| 21 |
My argument is that we must not filter -ffast-math or any other dangerous |
| 22 |
cflags. The reason being that people will request more filters for all |
| 23 |
packages that don't work with it. Many users will either ignore or miss the |
| 24 |
warning messages. Filtering the flag basically tells them that even though |
| 25 |
the message says it is dangerous, their use of the flag is still more or less |
| 26 |
supported, while it is not. |
| 27 |
|
| 28 |
> Okay, bad joke aside, there are always going to be users who tweak GCC |
| 29 |
> flags. This has to be expected, as they're mysterious, and technical, and |
| 30 |
> kinda cool. I like the tweaker crowd and I am a dummy, so no offense was |
| 31 |
> intended to either groups. I meant that if you safety-proof a complex |
| 32 |
> system, people never learn that they're doing anything wrong in the first |
| 33 |
> place. |
| 34 |
|
| 35 |
Exactly, filtering the flags is safety-proofing. So just die, or not filter at |
| 36 |
all. |
| 37 |
|
| 38 |
> Right, but how are people supposed to learn something is dangerous if all |
| 39 |
> the sharp edges have been filed off? And how can you decide which flags |
| 40 |
> are "bad" and "good" on a global level when for the most part compiler |
| 41 |
> parameters are akin to black magic? |
| 42 |
|
| 43 |
In this case the compiler documentation itself says it is dangerous. That |
| 44 |
should be enough. |
| 45 |
|
| 46 |
Paul |
| 47 |
|
| 48 |
-- |
| 49 |
Paul de Vrieze |
| 50 |
Gentoo Developer |
| 51 |
Mail: pauldv@g.o |
| 52 |
Homepage: http://www.devrieze.net |
Archives