Re: Devs and rice flags (Was: Re: [gentoo-user] emerge -j, make -j and make -l )

[Florian Philipp]

Am 28.11.2011 20:14, schrieb Michael Mol:
> On Mon, Nov 28, 2011 at 1:56 PM, Florian Philipp <lists@×××××××××××.net> wrote:
>> Am 28.11.2011 18:56, schrieb Michael Mol:
>>> On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pandu@××××××.info> wrote:
>>> 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.
>
> I didn't know (or forgot) what arch he was using.
>
>>> -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.
>
> AMD64 puts the requisite data in its own register, right?
>

I guess so. Never actually looked up how stack traces are produced. I
just reproduced what `man gcc` tells me :)

> Yeah, it sounds like Pandu's setup CFLAGS can use some cleanup.
>

I wonder how many CPU cycles you save by reducing the number of
parameters emerge has to pass to gcc. ;)

>>> 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).
>
> Upstream devs might take issue with them, but I'm still not sure they
> should affect bug reports of build-time failures. I would *hope*
> upstream gcc is doing tests on its own build tools compiled with its
> graphite optimizations. I don't know about make and autotools, though.
>

Agreed. Even if upstream for failing package doesn't want to handle it,
you can still redirect it to the gcc folks. Even a bug report flagged
WONTFIX or INVALID is helpful for the next user who stumbles upon weird
compile issues.

Regards,
Florian Philipp