From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122947 invoked by alias); 29 Jan 2019 10:24:47 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 122939 invoked by uid 89); 29 Jan 2019 10:24:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=advise, H*f:sk:nvBkHNs, H*f:sk:aJOPdv5, david@westcontrol.com X-HELO: mailfilter05.hatteland.com Received: from mailfilter05.hatteland.com (HELO mailfilter05.hatteland.com) (213.162.250.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Jan 2019 10:24:45 +0000 Received: from JHSVMHUB10.netsentral.no (unknown [10.135.1.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mailfilter05.hatteland.com (Postfix) with ESMTPS id B9171148640; Tue, 29 Jan 2019 11:24:41 +0100 (CET) Received: from [192.168.0.77] (10.135.1.5) by e2010.hatteland.com (10.135.1.80) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 29 Jan 2019 11:24:41 +0100 Subject: Re: -fno-common To: Bernhard Schommer CC: GCC Development References: <0c95c3f5-c9cb-8e36-a1d0-9b024c666564@westcontrol.com> From: David Brown Message-ID: <54bb3e6c-1ff8-985d-9cb8-d79898063e5f@westcontrol.com> Date: Tue, 29 Jan 2019 10:24:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-TMASE-Result: 10--12.108300-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24396.005 X-SW-Source: 2019-01/txt/msg00250.txt.bz2 Hi, You have to make sure you understand the standards here, not just copy what gcc does. In some aspects, gcc does what it always has done, rather than what it should do (from the point of view of following the standards, or for helping developers write correct code). The whole concept of common sections in C is a mistake - it can lead to errors that are very hard to spot, and limits compiler optimisations. However, gcc has to keep it because it has to support legacy code that relies on it. If your compiler does not need to support such code, then I would advise not supporting any kind of "common" at all - or at the very least, make "-fno-common" the default. (That is just my opinion, of course.) mvh., David On 29/01/2019 11:09, Bernhard Schommer wrote: > Thanks for the fast answer, sorry if I posted this on the wrong list. > Actually I was looking at this not due to changes in my code but > rather to implement the option for another compiler and I wanted to > mimic the behavior of gcc and was kind of confused in the change of > behavior. > > Bernhard. > > Am Di., 29. Jan. 2019 um 10:54 Uhr schrieb David Brown : >> >> On 28/01/2019 16:58, Bernhard Schommer wrote: >>> Hi, >>> >>> I would like to know if the handling of the option -fno-common has >>> changed between version 7.3 and 8.2 for x86. I tried it with the >>> default system version of OpenSUSE and for example: >>> >>> const int i; >>> >>> is placed in the .bss section. With a newer self-compiled version 8.2 >>> the same variable is placed in the section .rodata. I could not find >>> any information in the Changelog whether the behavior has changed and >>> thus would like to know if there was any change. >>> >> >> (I think this should be on gcc-help, not gcc.) >> >> "const int i;" is (in C) a tentative definition of an object "i" with >> external linkage. If you don't give an initialiser later in the file, >> it is equivalent to "const int i = 0;". The compiler knows it cannot >> legally change or be anything other than 0, and can therefore put it in >> the .rodata section. If you have another "const int i" definition in >> another translation unit, you can expect a linker error. >> >> It seems that gcc 7 put this in .bss. This is equally legal for the >> compiler. There should be no difference in how your code works, unless >> you are breaking some other C rules along the way. >> >> >> But there is no reason why you should ever write a line "const int i;". >> A "const" definition should always have an initialiser - while this >> line does the same job as "const int i = 0;" as far as the language is >> concerned, it is usually considered better style to initialise const >> data explicitly. >> >> So yes, it looks like the handling of this line has changed between >> versions of the compiler. But it should not affect your code functionality. >>