[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: -fno-common
From:       Bernhard Schommer <bernhardschommer () gmail ! com>
Date:       2019-01-29 12:05:28
Message-ID: CAG8G+nsLcaoTWvtG3Gv0LR+x6LO5rr7FJKAeXifPcXFbzb6BQg () mail ! gmail ! com
[Download RAW message or body]

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.
> >>
[prev in list] [next in list] [prev in thread] [next in thread]