clock reverts to epoch on boot?

[Vinny Abello]

At 12:29 PM 2/14/2006, Oliver Fromme wrote:
>Vinny Abello <vinny at tellurian.com> wrote:
>  >  Oliver Fromme wrote:
>  > > Vinny Abello <vinny at 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 at 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