Re: -fno-common

[Iain Sandoe]

> On 28 Jan 2019, at 15:58, Bernhard Schommer  
> 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
 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

Early Bird Discount - Health and Inactivity Conference 2019

[Why Sports 2018]

HEALTH AND INACTIVITY CONFERENCE

The Bridgewater Hall, Manchester

14th November 2019



Front-line professionals understand more than anyone about the pressures of
the increasing demand on health and social care at the same time as
managing tighter budgets. Managing this demand is part of the day to day
work of surgeries, clinics, care homes and wards across the country.
Debates on how to best approach these issues have often focused on how we
can better run our services but it is now widely accepted that preventing
people becoming ill in the first place – protecting or improving their
health before they need treatment – is of increased importance.

The members of a community are the most valuable resource in shaping
successful local programmes. - Sport England

Our latest Why Sports conference will provide an inclusive platform to
discuss current evidence whilst providing insight on how as a nation, we
can all work towards a sustainable preventative health approach across our
communities through the promotion and prescription of physical activity.

[1]CLICK FOR CONFERENCE AGENDA

BOOK NOW TO SAVE 25%

EARLY BIRD DISCOUNT ON DELEGATE TICKETS

Public Sector £225

3rd Sector £175

Private Sector £395

Discount Code - HA19EB21219

Discount available until 17:00 February 21st 2019

For more information call +44(0)161 464 8688

[2]REGISTER INTEREST / BUY TICKETS

Why Sports are asking for contributions from our community for our blog
site. If you have an inspiring case study or a story to tell that has
increased activity , please do not hesitate to get in touch.

[3]Contact us

Partner Profile:

How do you get people with dementia interested in physical activity? How
do you motivate them to keep exercising to improve their health?

[4]Click here to find out more

[5]TAKE ME TO THE WHY SPORTS BLOG SITE

Follow us on social media for more info & updates
[6]Twitter [7]LinkedIn [8]YouTube

[9]

References

1. https://healthy2019.whysports.co.uk/index.php/why-sports-agenda
2. https://healthy2019.whysports.co.uk/index.php?option=com_reg
3. mailto:enquir...@wsmg.co.uk?subject=I am interested in supplying information 
for the Why Sports Blog Site
4. 
https://www.whysports.blog/blog/improved-health-by-cycling-to-childhood-memories
5. https://www.whysports.blog/
6. https://www.twitter.com/whysportsmedia
7. https://www.linkedin.com/company/why-sports-media-group-limited
8. https://www.youtube.com/channel/UCvQMHl9pPd6GzA5MWCikjWw
9. http://whysports.co.uk/
Unsubscribe:
http://app.icontact.com/icp/mmail-mprofile.php?r=45048210&l=2500&s=9MBV&m=87967&c=1721525

This message was sent to gcc@gcc.gnu.org from ws2...@whysports-events.co.uk

Why Sports 2018
Richard Stott
5300 Lakeside
Cheadle, Stockport SK8 3GP, United Kingdom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

iContact - Try it for FREE: 
https://www.icontact.com/signup-trial?utm_medium=poweredby&utm_source=footerlink&utm_campaign=iC%20Footer&afid=144186

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




(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 :


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.

FOSDEM 2019

[Thomas Schwinge]

Hi!

Anybody going to visit FOSDEM in Bruxelles, Belgium this weekend,
?  I'll be there, and happy to meet up, of
course!


On Sunday, I'll be giving a presentation in the HPC, Big Data and Data
Science devroom: "Speeding up Programs with OpenACC in GCC",
.


Grüße
 Thomas

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