Date: Tue, 14 Feb 2006 18:29:07 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-stable@FreeBSD.ORG Subject: Re: clock reverts to epoch on boot? Message-ID: <200602141729.k1EHT73E071392@lurza.secnetix.de> In-Reply-To: <7.0.1.0.2.20060214104201.0845a270@tellurian.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Vinny Abello <vinny@tellurian.com> wrote:
> Oliver Fromme wrote:
> > Vinny Abello <vinny@tellurian.com> wrote:
> > > CFLAGS= -O2 -pipe
> > > COPTFLAGS= -O -pipe
> >
> > I recommend not to overide those two at all. Especially
> > your CFLAGS setting might generate broken code because
> > there are sources which are not aliasing-clean, which can
> > break with any optimizations beyond -O, unless you also
> > specify -fno-strict-aliasing.
>
> Really? Are there any current examples of such? I've never run into
> this myself, but I'm sure you wouldn't be recommending it if it wasn't true.
XEmacs, PostgreSQL, freetype2 and others. Whether you get
problems or not depends on a lot of things. If you're
lucky, it works. On platforms with only few registers
(like i386) it's more likely to work, because gcc has less
possibilities to exploit aliasing optimizations.
> What about -funroll-loops and -ffast-math? I see a lot of people
> using those options in general as well.
You can use them. They shouldn't cause harm, but in many
cases -funroll-loops makes the code slower, because it
increases the size of the code so it decreases the efficiency
of the processor caches.
> I actually found one reference from someone claiming -O3 is good in
> CFLAGS and -O2 for COPTFLAGS although I have read a lot of things
> about why not to use -O3 in CFLAGS and that it's not supported at all
> with buildworld, so I'm not really interested in using that at all,
> even with ports.
I probably didn't explain it clearly enough. You can use
-O2 (and probably also -O3, but I haven't tried that).
In former times, the gcc optimizer was known to have bugs
that could cause bad code to be generated. As far as I
know, those bugs have been fixed in current versions of
gcc.
However, -O2 also includes -fstrict-aliasing. Strict ali-
asing enables a special optimization which lets the compiler
assume that pointers with incompatible types never point
to the same target. For example, in the function
void func (int *foo, short *bar)
it is legal for the compiler (according to ANSI C) to assume
that the two pointers may not alias. But a lot of programs
don't fulfill that assumption. It's a problem with those
sources, not with gcc.
Therefore the default CFLAGS include -fno-strict-aliasing,
which disables that kind of optimizations in gcc. With
that option, gcc always assumes that pointers may alias.
If you override CFLAGS in your /etc/make.conf by specifying
-O2 (or -O3 or -Os) but not also specifying -fno-strict-ali-
asing, you run the risk of enabling bugs in programs.
> > The defaults are "-O2 -fno-strict-aliasing -pipe" for
> > CFLAGS, and for COPTFLAGS it's "-O -pipe" if DEBUG is
> > defined (the default in GENERIC), otherwise "-O2 -pipe
> > -fno-strict-aliasing".
>
> Is -O2 safe on COPTFLAGS if you have debugging disabled in the
> KERNCONF?
Yes, I think so. But when you disable DEBUG, then -O2 is
the default anyway ("-O2 -pipe -fno-strict-aliasing", to be
exact), so there's no point in overriding it in make.conf.
That's the reason why I recommend not to mess with CFLAGS
and COPTFLAGS in /etc/make.conf. The defaults provided by
the FreeBSD developers are usually the best optimization
possible without creating potentially broken binaries.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200602141729.k1EHT73E071392>