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