From owner-freebsd-current@FreeBSD.ORG Thu Dec 11 05:20:12 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA34516A4CE for ; Thu, 11 Dec 2003 05:20:12 -0800 (PST) Received: from paladin.fortunaty.net (fortunaty.net [217.160.129.175]) by mx1.FreeBSD.org (Postfix) with SMTP id 2B88343D09 for ; Thu, 11 Dec 2003 05:20:11 -0800 (PST) (envelope-from ah@paladin.fortunaty.net) Received: (qmail 2492 invoked by uid 501); 11 Dec 2003 13:20:10 -0000 Date: 11 Dec 2003 13:20:10 -0000 Message-ID: <20031211132010.2491.qmail@paladin.fortunaty.net> User-Agent: Emai/0.0.2p1 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline References: <20031210204642.27989.qmail@paladin.fortunaty.net>, In-Reply-To: From: andy@splashground.de To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Damian Gerow cc: current@freebsd.org Subject: Re: buildworld doesn't like -O2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2003 13:20:12 -0000 des wrote @ Thu, 11 Dec 2003 14:02:31 +0100: > Andreas Hauser writes: > > There is a qr about it > > http://www.freebsd.org/cgi/query-pr.cgi?pr=55774 > > but it was closed by DES saying "Not a problem report". > > I don't understand why [...] > > Quoting from src/share/examples/etc/make.conf: > > # CFLAGS controls the compiler settings used when compiling C code. > # Note that optimization settings above -O (-O2, ...) are not recommended > # or supported for compiling the world or the kernel - please revert any > # nonstandard optimization settings to "-O" before submitting bug reports > # to the developers. > > Even if that weren't the case, PRs about a broken build are generally > not welcome. We have mailing lists for that. I know that and i also understand that brocken optimization levels of GCC have led to a lot of false reports. But with the newer GCC versions much has improved. And in this case, as far as i can see, the code does violate the strict aliasing rules. const char *rhost; ... (const void **)&rhost ... You only have (bad) luck that with less optimizations the compiler doesn't warn about it. Or is that a wrong representation? Andy