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