[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: using non-standard optflags (-O3, in particular)



On Fri, 2007-02-09 at 01:25 +0100, Patrice Dumas wrote:
> On Thu, Feb 08, 2007 at 04:16:58PM -0600, Callum Lerwick wrote:
> > 
> > With what GCC version? And with what other flags? Optimization is an
> > incredibly finicky thing, that can wildly vary depending on the version
> > of GCC, and different opt flags can interact in strange ways.
> > 
> > Unless you can show a conclusive benchmark showing -O3 is better with
> > *our* GCC and all the rest of *our* opt flags, this shouldn't be allowed
> > IMHO.
> 
> Why not trust upstream?
If you mean those people who implement RPM_OPT_FLAGS, then I'd agree.

If you mean a packages upstream: Yes, -O3 might have improved speed on
this upstream's test systems, but ... only on very rare occasions, these
"upstreams" will be able to prove generality of their claims.

>  And if a benchmark shows that it is untrue, 
> come back to -O2. If i recall well -O3 make debuging harder, so there is
> a choice to do, but the packager should certainly be trusted in those
> cases.
Your answer clearly shows you don't know what -O3 really does (I don't
know either), which details it all affects and which bugs it suffers
from.

This is no surprise, because -O3 (like any other -Ox flags) comprises a
set of optimizations which silently changes over time, can have
different effect on different architectures, particular cpus and will
vary between distributions (The fedora GCC is not a vanilla FSF gcc),
etc.

So, the only results of recommendations to trust when it comes to
packaging binaries for a distro is those who are deeply familiar with
the guts of the OS, in case of Fedora, RH's GCC, glibc and kernel
developers. 

They recommend those flags in RPM_OPT_FLAGS.

Ralf







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]