Re: c++/8249: Objects moved from common to BSS with -fdata-sections

Re: c++/8249: Objects moved from common to BSS with -fdata-sections

[Loren James Rittle]

The following reply was made to PR c++/8249; it has been noted by GNATS.

From: Loren James Rittle <rittle@latour.rsch.comm.mot.com>
To: bangerth@ticam.utexas.edu
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/8249: Objects moved from common to BSS with -fdata-sections
Date: Mon, 23 Dec 2002 11:27:02 -0600 (CST)

 In article <Pine.LNX.4.44.0212201110540.18379-100000@gandalf.ticam.utexas.edu>,
 Wolfgang Bangerth<bangerth@ticam.utexas.edu> writes:
 
 >> Knowing what Linux does might help me understand more about this
 >> problem.  Linux does properly support -fdata-sections, no?  In my
 >> case, the linker is GNU ld version 2.13 20020917 (and also tested with
 >> GNU ld version 2.12.1 [FreeBSD] 2002-07-20).
 
 > I have no idea how well Linux supports -fdata-sections. To be honest, I 
 > don't even know properly what this is about, I was just going through bug 
 > reports and checked whether they apply to my box as well and if I can 
 > contribute something :-)
 
 > GNU ld version 2.11.92.0.10 20011021 (SuSE)
 
 Thanks for checking.  Your machine got the same asm output file (at
 least in the section of interest), but the linker version is
 different.  Thus, I'd now say the bug is not in the compiler but in a
 change in the linker or bug in my port's ld configuration.
 
 Perhaps, we should close it with this analysis.
 
 Regards,
 Loren

Re: c++/8249: Objects moved from common to BSS with -fdata-sections

[Wolfgang Bangerth]

The following reply was made to PR c++/8249; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: rittle@labs.mot.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/8249: Objects moved from common to BSS with -fdata-sections
Date: Fri, 20 Dec 2002 11:15:12 -0600 (CST)

 [Let's keep cross-posting to the database, just in case someone else is 
 interested in these mails.]
 
 On Thu, 19 Dec 2002, Loren James Rittle wrote:
 
 > In article <20021220012230.3437.qmail@sources.redhat.com>,
 > <bangerth@dealii.org> writes:
 > 
 > >     Loren, can you tell whether this still happens? I can't
 > >     reproduce this, but admittedly I only have a Linux box,
 > >     so maybe this is really target specific.
 > 
 > Yes, with mainline built today, it still exists.  Thanks for checking
 > results in your environment.  If you don't mind, could you repeat the
 > following steps and e-mail the results to me.
 > 
 > $ g++ -S -o tX t2.ii
 > $ g++ -fdata-sections -S -o tY t2.ii 
 > $ diff tX tY
 > 19,20c19,32
 > <       .comm   _ZGVZN3fooILi0EE3barEvE10double_foo,8,8
 > <       .comm   _ZZN3fooILi0EE3barEvE10double_foo,4,4
 > ---
 > > .globl _ZGVZN3fooILi0EE3barEvE10double_foo
 > >       .section        .bss._ZGVZN3fooILi0EE3barEvE10double_foo,"aw",@nobits
 > >       .align 8
 > >       .type   _ZGVZN3fooILi0EE3barEvE10double_foo, @object
 > >       .size   _ZGVZN3fooILi0EE3barEvE10double_foo, 8
 > > _ZGVZN3fooILi0EE3barEvE10double_foo:
 > >       .zero   8
 > > .globl _ZZN3fooILi0EE3barEvE10double_foo
 > >       .section        .bss._ZZN3fooILi0EE3barEvE10double_foo,"aw",@nobits
 > >       .align 4
 > >       .type   _ZZN3fooILi0EE3barEvE10double_foo, @object
 > >       .size   _ZZN3fooILi0EE3barEvE10double_foo, 4
 > > _ZZN3fooILi0EE3barEvE10double_foo:
 > >       .zero   4
 > 
 > Knowing what Linux does might help me understand more about this
 > problem.  Linux does properly support -fdata-sections, no?  In my
 > case, the linker is GNU ld version 2.13 20020917 (and also tested with
 > GNU ld version 2.12.1 [FreeBSD] 2002-07-20).
 
 I have no idea how well Linux supports -fdata-sections. To be honest, I 
 don't even know properly what this is about, I was just going through bug 
 reports and checked whether they apply to my box as well and if I can 
 contribute something :-)
 
 This is my configuration:
 tmp/g> ld -V
 GNU ld version 2.11.92.0.10 20011021 (SuSE)
   Supported emulations:
    elf_i386
    i386linux
 tmp/g> cat /proc/version
   Linux version 2.4.18-4GB (root@Pentium.suse.de) (gcc version 2.95.3 
   20010315 (SuSE)) #1 Wed Mar 27 13:57:05 UTC 2002
 
 And here's what I get is this (with yesterday's mainline):
 
 tmp/g> /home/bangerth/bin/gcc-3.4-CVS/bin/c++ -S -o tX t2.ii
 tmp/g> /home/bangerth/bin/gcc-3.4-CVS/bin/c++ -fdata-sections -S -o tY 
 t2.ii
 tmp/g> diff tX tY
 19,20c19,32
 <       .comm   _ZGVZN3fooILi0EE3barEvE10double_foo,8,8
 <       .comm   _ZZN3fooILi0EE3barEvE10double_foo,4,4
 ---
 > .globl _ZGVZN3fooILi0EE3barEvE10double_foo
 >       .section        .bss._ZGVZN3fooILi0EE3barEvE10double_foo,"aw",@nobits
 >       .align 8
 >       .type   _ZGVZN3fooILi0EE3barEvE10double_foo, @object
 >       .size   _ZGVZN3fooILi0EE3barEvE10double_foo, 8
 > _ZGVZN3fooILi0EE3barEvE10double_foo:
 >       .zero   8
 > .globl _ZZN3fooILi0EE3barEvE10double_foo
 >       .section        .bss._ZZN3fooILi0EE3barEvE10double_foo,"aw",@nobits
 >       .align 4
 >       .type   _ZZN3fooILi0EE3barEvE10double_foo, @object
 >       .size   _ZZN3fooILi0EE3barEvE10double_foo, 4
 > _ZZN3fooILi0EE3barEvE10double_foo:
 >       .zero   4
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

Re: c++/8249: Objects moved from common to BSS with -fdata-sections

[Loren James Rittle]

The following reply was made to PR c++/8249; it has been noted by GNATS.

From: Loren James Rittle <rittle@latour.rsch.comm.mot.com>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/8249: Objects moved from common to BSS with -fdata-sections
Date: Thu, 19 Dec 2002 23:25:58 -0600 (CST)

 >    Loren, can you tell whether this still happens? I can't
 >    reproduce this, but admittedly I only have a Linux box,
 >    so maybe this is really target specific.
 
 Yes, as of mainline today.  The problem is exactly as originally
 reported on at least i386-unknown-freebsd4.  I don't recall if there
 was mailing list traffic on this PR.  When I committed a change to
 libstdc++-v3 that would have exercised this issue, I committed a
 work-around.
 
 Regards,
 Loren

Re: c++/8249: Objects moved from common to BSS with -fdata-sections

[bangerth]

Synopsis: Objects moved from common to BSS with -fdata-sections

State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Thu Dec 19 17:22:30 2002
State-Changed-Why:
    Loren, can you tell whether this still happens? I can't
    reproduce this, but admittedly I only have a Linux box,
    so maybe this is really target specific.
    
    Thanks
      Wolfgang

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8249

c++/8249: Objects moved from common to BSS with -fdata-sections

[rittle]

>Number:         8249
>Category:       c++
>Synopsis:       Objects moved from common to BSS with -fdata-sections
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 17 03:46:02 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     rittle@labs.mot.com
>Release:        gcc mainline; regression from 3.2.X
>Organization:
>Environment:
Seen on both i386-*-freebsd4.7 and
alpha-*-freebsd5.7 while working on libstdc++-v3
which uses -fdata-sections by default (on some platforms).
>Description:

>How-To-Repeat:
Run:

g++ -c t2.ii
nm -C t2.o
00000000 T double_bar()
00000008 C guard variable for foo<0>::bar()::double_foo
00000000 W foo<0>::fu()
00000000 W foo<0>::bar()
00000004 C foo<0>::bar()::double_foo
         U __gxx_personality_v0
g++ -fdata-sections -c t2.ii
nm -C t2.o
00000000 T double_bar()
00000000 B guard variable for foo<0>::bar()::double_foo
00000000 W foo<0>::fu()
00000000 W foo<0>::bar()
00000000 B foo<0>::bar()::double_foo
         U __gxx_personality_v0

Notice movement from common to BSS.

When linked against t.ii (which is also compiled with -fdata-sections):
# 1 "t.C"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "t.C"
template<int __inst>
struct foo
{
  static int fu(void) { return 1; }
  static void bar(void) { static int double_foo = fu(); }
};

int double_bar(void);

int main(void)
{
  double_bar();
  foo<0>::bar();
}

Produces:

t2.o(.bss._ZGVZN3fooILi0EE3barEvE10double_foo+0x0): multiple definition of `guard variable for foo<(int)0>::bar()::double_foo'
t.o(.bss._ZGVZN3fooILi0EE3barEvE10double_foo+0x0): first defined here
t2.o(.bss._ZZN3fooILi0EE3barEvE10double_foo+0x0): multiple definition of `foo<(int)0>::bar()::double_foo'
t.o(.bss._ZZN3fooILi0EE3barEvE10double_foo+0x0): first defined here
collect2: ld returned 1 exit status
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="t2.ii"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="t2.ii"

IyAxICJ0Mi5DIgojIDEgIjxidWlsdC1pbj4iCiMgMSAiPGNvbW1hbmQgbGluZT4iCiMgMSAidDIu
QyIKdGVtcGxhdGU8aW50IF9faW5zdD4Kc3RydWN0IGZvbwp7CiAgc3RhdGljIGludCBmdSh2b2lk
KSB7IHJldHVybiAxOyB9CiAgc3RhdGljIHZvaWQgYmFyKHZvaWQpIHsgc3RhdGljIGludCBkb3Vi
bGVfZm9vID0gZnUoKTsgfQp9OwoKdm9pZCBkb3VibGVfYmFyKHZvaWQpCnsKICBmb288MD46OmJh
cigpOwp9Cg==