Am 28.11.2011 18:56, schrieb Michael Mol:
> On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pa...@poluan.info> wrote:
>> On Nov 28, 2011 10:38 PM, "Michael Mol" <mike...@gmail.com> wrote:
>>> On Sun, Nov 27, 2011 at 7:54 PM, Pandu Poluan <pa...@poluan.info> wrote:
>>>> Won't file a bug report, though. I have a feeling that my bug report re:
>>>> emerge failure will be marked WONTFIX thanks to the 'ricer special'
>>>> CFLAGS
>>>
>>> The CFLAGS you showed me weren't any more ricer than "-O2
>>> -march=native". (I didn't know that -D_FORTIFY=2 came from gcc)
>>>
>>> They wouldn't have a leg to stand on...
>>>
>>
>> Mine is:
>>
>> CFLAGS="-O2 -march=native -fomit-frame-pointer -floop-interchange
>> -floop-strip-mine -floop-block -funsafe-math-optimizations
>> -fexcess-precision=fast"
>>
>> If you tell me that's not a ricer's CFLAGS, then you've just made me a very
>> happy cat :-)
> 
> No, you've got some ugly flags in there. -fexcess-precision and
> -funsafe-math-optimizations, in particular. (I must have been talking
> to someone else last week; sorry, I'm terrible with names.)
> 

I doubt -fexcess-precision=fast does anything at all. Pandu uses an
AMD64 system, right? Then you have -mfpmath=sse set per default and SSE
does not have excess precision issues (that's just for the old x87 FPU).
Even if you used that, is redundant because of your other flags. To
quote `man gcc`:
"-fexcess-precision=standard is not implemented for languages other than
C, and has no effect if -funsafe-math-optimizations or -ffast-math is
specified." <-- Therefore you always have ..=fast anyway.

-funsafe-math-optimizations is really terrible. Either you us floating
point arithmetic, then you have to rely on it because it is hard enough
already to gain necessary precision with it, or you don't, then you
don't need that flag because it doesn't improve performance.

> -fomit-frame-pointer shouldn't cause any headaches unless you're
> feeding a gdb stack trace, and you're not adding any debugging data,
> so your stack traces would be pretty useless, anyway.
> 

If you are on an AMD64 system, this flag is implied because it doesn't
affect stack traces on x86_64 anymore.

> I don't know about -floop-interchange, -floop-strip-mine or
> -floop-block. I recognize at least one of them from the discussion of
> graphite the other day.
> 

These definitely need graphite to have any effect. Then they should be
reasonably safe (as far as anything relying on experimental compiler
frameworks can be considered safe).

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to