Date: Tue, 14 Feb 2006 15:09:23 -0500 From: Vinny Abello <vinny@tellurian.com> To: freebsd-stable@FreeBSD.ORG Subject: Re: clock reverts to epoch on boot? Message-ID: <7.0.1.0.2.20060214150849.06885eb8@tellurian.com> In-Reply-To: <200602141729.k1EHT73E071392@lurza.secnetix.de> References: <7.0.1.0.2.20060214104201.0845a270@tellurian.com> <200602141729.k1EHT73E071392@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:29 PM 2/14/2006, Oliver Fromme wrote:
>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
Thanks for all of your excellent explanations, Oliver. Highly appreciated. :)
Vinny Abello
Network Engineer
Server Management
vinny@tellurian.com
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A
Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN
"Courage is resistance to fear, mastery of fear - not absence of
fear" -- Mark Twain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7.0.1.0.2.20060214150849.06885eb8>