-fno-common

-fno-common

[Bernhard Schommer]

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.

Best,
-Bernhard

Re: -fno-common

[Iain Sandoe]

> On 28 Jan 2019, at 15:58, Bernhard Schommer <bernhardschommer@gmail.com> wrote:
> 
> 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.

If you look in of, say, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

at section 

	• 6.7.3 Type qualifiers

there’s a footnote:

	• 132) The implementation may place a const object that is not volatile in a read-only region of storage. Moreover, the implementation need not allocate storage for such an object if its address is never used.

---

So, I don’t think you can make any assumption about whether such items appear in bss or .rodata (or const on darwin, for example).

HTH,
Iain

Re: -fno-common

[Richard Biener]

On Mon, Jan 28, 2019 at 4:59 PM Bernhard Schommer
<bernhardschommer@gmail.com> 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 can confirm this change in behavior.  I vaguely remember changes in this
area but I'm not sure if the change was on purpose.

Richard.

> Best,
> -Bernhard

Re: -fno-common

[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.

Re: -fno-common

[Bernhard Schommer]

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 <david@westcontrol.com>:
>
> 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.
>

Re: -fno-common

[Jakub Jelinek]

On Tue, Jan 29, 2019 at 11:09:35AM +0100, 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.

See the "Fix inconsistent section flags" thread in
http://gcc.gnu.org/ml/gcc-patches/2017-{07,08,09}/
archives for the rationale.

	Jakub

Re: -fno-common

[David Brown]

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.

<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678>

(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 <david@westcontrol.com>:
>>
>> 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.
>>

Re: -fno-common

[Bernhard Schommer]

Hi,

yes I'm aware of the problematic of common and unfortunately I'm stuck
with handling it in a similar way to gcc, due to similar constraints
regarding legacy code.

Best,
-Bernhard

Am Di., 29. Jan. 2019 um 11:24 Uhr schrieb David Brown <david@westcontrol.com>:
>
> 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.
>
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678>
>
> (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 <david@westcontrol.com>:
> >>
> >> 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.
> >>

-fno-common

[Dave Korn]

  According to the manual,

----------------------snip----------------------
`-fno-common'
     In C, allocate even uninitialized global variables in the data
     section of the object file, rather than generating them as common
     blocks.  
----------------------snip----------------------

  When I compile the following declaration:

----------------------snip----------------------
unsigned int operatingMode;
----------------------snip----------------------

at file-scope, with -fno-common, it actually gets allocated to the .bss
section.

  Is the manual wording just slightly vague here, and both .data and .bss
are regarded as covered by the phrase "the data section of the object file"?
Or should it actually have ended up in .data, not .bss after all?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: -fno-common

[Daniel Jacobowitz]

On Thu, Mar 31, 2005 at 07:33:53PM +0100, Dave Korn wrote:
>   Is the manual wording just slightly vague here, and both .data and .bss
> are regarded as covered by the phrase "the data section of the object file"?

Yes.

-- 
Daniel Jacobowitz
CodeSourcery, LLC