Am 28.11.2011 20:14, schrieb Michael Mol: > On Mon, Nov 28, 2011 at 1:56 PM, Florian Philipp <li...@binarywings.net> > wrote: >> Am 28.11.2011 18:56, schrieb Michael Mol: >>> On Mon, Nov 28, 2011 at 11:46 AM, Pandu Poluan <pa...@poluan.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
signature.asc
Description: OpenPGP digital signature
