From owner-freebsd-current@FreeBSD.ORG Sun Jul 27 18:50:51 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 239A737B401 for ; Sun, 27 Jul 2003 18:50:51 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9146443FA3 for ; Sun, 27 Jul 2003 18:50:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) h6S1ooh5077063; Sun, 27 Jul 2003 18:50:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)h6S1ooqE077062; Sun, 27 Jul 2003 18:50:50 -0700 (PDT) Date: Sun, 27 Jul 2003 18:50:50 -0700 From: Steve Kargl To: Jun Kuriyama Message-ID: <20030728015050.GA77047@troutmask.apl.washington.edu> References: <7mwue3v6gf.wl@black.imgsrc.co.jp> <7mvftnv3fp.wl@black.imgsrc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7mvftnv3fp.wl@black.imgsrc.co.jp> User-Agent: Mutt/1.4.1i cc: Current Subject: Re: dereferencing type-punned pointer will break strict-aliasing rules 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: Mon, 28 Jul 2003 01:50:51 -0000 On Mon, Jul 28, 2003 at 10:35:22AM +0900, Jun Kuriyama wrote: > At Mon, 28 Jul 2003 00:30:35 +0000 (UTC), > kuriyama wrote: > > Is this caused by -oS option? > > Grrr, of course this should be s/-oS/-Os/. > > These warnings are caused from DROP_GIANT() macro. By tracking this > down, actual source is __PCPU_GET() macro (line: 115) in > sys/i386/include/pcpu.h. > > __result = *(__pcpu_type(name) *)&__i; > snip > > What should we do? > I presume you read share/example/make.conf, which states # To compile just the kernel with special optimizations, you should use # this instead of CFLAGS (which is not applicable to kernel builds anyway). # There is very little to gain by using higher optimization levels, and doing # so can cause problems. # #COPTFLAGS= -O -pipe Notice the last 6 words. -- Steve