Re: -fno-common

[Bernhard Schommer <bernhardschommer at gmail dot com>]

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