| 1 |
Am 28.11.2011 18:56, schrieb Michael Mol: |
| 2 |
> On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pandu@××××××.info> wrote: |
| 3 |
>> On Nov 28, 2011 10:38 PM, "Michael Mol" <mikemol@×××××.com> wrote: |
| 4 |
>>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pandu@××××××.info> wrote: |
| 5 |
>>>> Won't file a bug report, though. I have a feeling that my bug report re: |
| 6 |
>>>> emerge failure will be marked WONTFIX thanks to the 'ricer special' |
| 7 |
>>>> CFLAGS |
| 8 |
>>> |
| 9 |
>>> The CFLAGS you showed me weren't any more ricer than "-O2 |
| 10 |
>>> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc) |
| 11 |
>>> |
| 12 |
>>> They wouldn't have a leg to stand on... |
| 13 |
>>> |
| 14 |
>> |
| 15 |
>> Mine is: |
| 16 |
>> |
| 17 |
>> CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange |
| 18 |
>> -floop-strip-mine -floop-block -funsafe-math-optimizations |
| 19 |
>> -fexcess-precision=fast" |
| 20 |
>> |
| 21 |
>> If you tell me that's not a ricer's CFLAGS, then you've just made me a very |
| 22 |
>> happy cat :-) |
| 23 |
> |
| 24 |
> No, you've got some ugly flags in there. -fexcess-precision and |
| 25 |
> -funsafe-math-optimizations, in particular. (I must have been talking |
| 26 |
> to someone else last week; sorry, I'm terrible with names.) |
| 27 |
> |
| 28 |
|
| 29 |
I doubt -fexcess-precision=fast does anything at all. Pandu uses an |
| 30 |
AMD64 system, right? Then you have -mfpmath=sse set per default and SSE |
| 31 |
does not have excess precision issues (that's just for the old x87 FPU). |
| 32 |
Even if you used that, is redundant because of your other flags. To |
| 33 |
quote `man gcc`: |
| 34 |
"-fexcess-precision=standard is not implemented for languages other than |
| 35 |
C, and has no effect if -funsafe-math-optimizations or -ffast-math is |
| 36 |
specified." <-- Therefore you always have ..=fast anyway. |
| 37 |
|
| 38 |
-funsafe-math-optimizations is really terrible. Either you us floating |
| 39 |
point arithmetic, then you have to rely on it because it is hard enough |
| 40 |
already to gain necessary precision with it, or you don't, then you |
| 41 |
don't need that flag because it doesn't improve performance. |
| 42 |
|
| 43 |
> -fomit-frame-pointer shouldn't cause any headaches unless you're |
| 44 |
> feeding a gdb stack trace, and you're not adding any debugging data, |
| 45 |
> so your stack traces would be pretty useless, anyway. |
| 46 |
> |
| 47 |
|
| 48 |
If you are on an AMD64 system, this flag is implied because it doesn't |
| 49 |
affect stack traces on x86_64 anymore. |
| 50 |
|
| 51 |
> I don't know about -floop-interchange, -floop-strip-mine or |
| 52 |
> -floop-block. I recognize at least one of them from the discussion of |
| 53 |
> graphite the other day. |
| 54 |
> |
| 55 |
|
| 56 |
These definitely need graphite to have any effect. Then they should be |
| 57 |
reasonably safe (as far as anything relying on experimental compiler |
| 58 |
frameworks can be considered safe). |
Archives