From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 17:29:15 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 1E5A716A420 for ; Tue, 14 Feb 2006 17:29:15 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78D7143D49 for ; Tue, 14 Feb 2006 17:29:14 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (zgzuvq@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k1EHT7wO071393 for ; Tue, 14 Feb 2006 18:29:12 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k1EHT73E071392; Tue, 14 Feb 2006 18:29:07 +0100 (CET) (envelope-from olli) Date: Tue, 14 Feb 2006 18:29:07 +0100 (CET) Message-Id: <200602141729.k1EHT73E071392@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <7.0.1.0.2.20060214104201.0845a270@tellurian.com> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.0-20051224 ("Ronay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 14 Feb 2006 18:29:13 +0100 (CET) Cc: Subject: Re: clock reverts to epoch on boot? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG 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 17:29:15 -0000 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 -- 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.