From owner-svn-src-all@FreeBSD.ORG Sat Dec 4 11:44:47 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7B47106566B; Sat, 4 Dec 2010 11:44:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6F88FC16; Sat, 4 Dec 2010 11:44:46 +0000 (UTC) Received: from c211-30-187-94.carlnfd1.nsw.optusnet.com.au (c211-30-187-94.carlnfd1.nsw.optusnet.com.au [211.30.187.94]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oB4BihTW028774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Dec 2010 22:44:44 +1100 Date: Sat, 4 Dec 2010 22:44:43 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20101204105232.GI2392@deviant.kiev.zoral.com.ua> Message-ID: <20101204223204.I2292@besplex.bde.org> References: <201012032154.oB3LsADC035461@svn.freebsd.org> <201012031744.01956.jkim@FreeBSD.org> <201012031802.40083.jkim@FreeBSD.org> <201012031817.23834.jkim@FreeBSD.org> <20101204103625.GA106@freebsd.org> <20101204105232.GI2392@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, John Baldwin , svn-src-all@freebsd.org, svn-src-head@freebsd.org, Roman Divacky , Jung-uk Kim Subject: Re: svn commit: r216161 - in head/sys: amd64/amd64 i386/i386 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2010 11:44:47 -0000 On Sat, 4 Dec 2010, Kostik Belousov wrote: > On Sat, Dec 04, 2010 at 11:36:25AM +0100, Roman Divacky wrote: >> On Fri, Dec 03, 2010 at 06:17:16PM -0500, Jung-uk Kim wrote: > ... >>>> I just tried it. GCC generates identical binaries as I thought. >>>> However, Clang doesn't do the optimization. :-/ >>> >>> Strangely, Clang increases .bss when a global variable is explicitly >>> initialized to zero. >>> >>> - 2 .bss 00000004 0000000000000000 0000000000000000 00000540 2**2 >>> + 2 .bss 00000014 0000000000000000 0000000000000000 00000540 2**3 >> >> in my naive test gcc produces: >> >> .globl foo >> .section .bss >> .align 4 >> .type foo, @object >> .size foo, 4 >> foo: >> .zero 4 >> >> >> and clang produces: >> >> .type foo,@object # @foo >> .bss >> .globl foo >> .align 4 >> foo: >> .long 0 # 0x0 >> .size foo, 4 >> >> ie. both put them into BSS > I have no idea how and where your gcc is configured, in particular, I > find the non-documenting directive .zero somewhat puzzling. All of gcc-3.3.3 on i386 on my local system, and gcc-4.2.1 on amd64 and i386 on FreeBSD cluseter machines produce the .zero, and either the .align or the .p2align. I think '.zero 4' is just a spelling of '.long 0' if longs have size 4. Not clear why the clang asm generates a different object. > Behaviour of clang looks like a plain bug, since initialized objects must > be put into the .data section, not into .bss. Note that gcc does this too in the above. The above is for explicitly initialized (to 0) objects. Such objects can be put in the bss just as validly as implicitly initialized (to 0) ones. > Both gcc 4.2.1/FreeBSD and plain 4.5.1 produce > .comm foo,4,4 > when compiling the file consisting of > long foo; > line. For amd64, substitute 4 by 8. Now the initialization is implicit. I guess the difference is to preserve the possibility of laying out the objects using explicit initialization. Hmm, this only works if they are all explicitly initialized to 0 -- others cannot remain adjacent since they musyt be moved to put them in the data section. Of course, C doesn't require anything for the layout. ABIs might, but I don't know of any other than defacto ones. Bruce