From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 20:09:25 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA16F16A420 for ; Tue, 14 Feb 2006 20:09:24 +0000 (GMT) (envelope-from vinny@tellurian.com) Received: from mail1.tellurian.net (mail1.tellurian.net [216.182.1.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EFA143D4C for ; Tue, 14 Feb 2006 20:09:24 +0000 (GMT) (envelope-from vinny@tellurian.com) Received: from cactus.tellurian.com (cactus.tellurian.net [216.182.1.34]) by mail1.tellurian.net ([216.182.1.23] Tellurian Networks Mail Server version 3.7a-14) with ESMTP id 348990644 for ; Tue, 14 Feb 2006 15:09:23 -0500 Message-Id: <7.0.1.0.2.20060214150849.06885eb8@tellurian.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 14 Feb 2006 15:09:23 -0500 To: freebsd-stable@FreeBSD.ORG From: Vinny Abello In-Reply-To: <200602141729.k1EHT73E071392@lurza.secnetix.de> References: <7.0.1.0.2.20060214104201.0845a270@tellurian.com> <200602141729.k1EHT73E071392@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: vinny@tellurian.com X-Ultimate-Internet-Connection: Tellurian Networks Cc: Subject: Re: clock reverts to epoch on boot? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 20:09:25 -0000 At 12:29 PM 2/14/2006, Oliver Fromme wrote: >Vinny Abello wrote: > > Oliver Fromme wrote: > > > Vinny Abello 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