c++/9393: [3.2/3.3/3.4 regression] Anonymous namespaces and compiling the same file twice

c++/9393: [3.2/3.3/3.4 regression] Anonymous namespaces and compiling the same file twice

[bangerth]

>Number:         9393
>Category:       c++
>Synopsis:       [3.2/3.3/3.4 regression] Anonymous namespaces and compiling the same file twice
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 21 23:06:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Wolfgang Bangerth
>Release:        unknown-1.0
>Organization:
>Environment:
gcc 3.4
>Description:
Hm, this counters what anonymous namespaces are all about:
if I have the following file, and compile it twice (once
with D defined, once without), then I get a linker error
that elements of the anonymous namespaces are defined twice:
------------------------
namespace {
  struct S {
      void f();
  };
  void S::f () {}
}

#if D
  void foo () { S s; }
#else
  int main () { S s; }
#endif
--------------------------
With present 3.4 CVS, I get the following:

g/a> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc -DD -o x1.o
g/a> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc -o x2.o
g/a> /home/bangerth/bin/gcc-3.4-pre/bin/c++ x?.o -o a.out
x2.o: In function `(anonymous namespace)::S::f()':
x2.o(.text+0x0): multiple definition of `(anonymous namespace)::S::f()'
x1.o(.text+0x0): first defined here
collect2: ld returned 1 exit status


On the other hand, it worked with 2.95:

g/a> c++ -c x.cc -DD -o x1.o
g/a> c++ -c x.cc -o x2.o
g/a> c++ x?.o -o a.out
g/a>

It also works with 3.0.4, but is already broken on the
3.2 branch. In any case, it's a regression. Too bad,
anonymous namespaces are a useful feature...

When digging a little deeper, it is of course clear what
happens: until 3.0.4, the name of a symbol from an anonymous
namespace differs when the file is compiled twice (even with
the exact same flags). This is no longer the case since
3.2.2. A simpler testcase is thus the following: take
---------------------
namespace {
  int i;
}
---------------------
and compile it twice and look at the symbol names. I get

g/a> /home/bangerth/bin/gcc-3.0.4/bin/c++ -c x.cc -o x2.o
g/a> nm x2.o
00000000 B _ZN21_GLOBAL__N_x.ccc18R7c1iE

g/a> /home/bangerth/bin/gcc-3.0.4/bin/c++ -c x.cc -o x2.o
g/a> nm x2.o
00000000 B _ZN21_GLOBAL__N_x.ccQqZgxc1iE

which is different, but

g/a> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc -o x2.o
g/a> nm x2.o
00000000 B _ZN21_GLOBAL__N_x.ccI4JKib1iE

g/a> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc -o x2.o
g/a> nm x2.o
00000000 B _ZN21_GLOBAL__N_x.ccI4JKib1iE

which is the same twice.

W.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:

Re: c++/9393: [3.2/3.3/3.4 regression] Anonymous namespaces and compiling the same file twice

[Geoffrey Keating]

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

From: Geoffrey Keating <geoffk@apple.com>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, bangerth@ices.utexas.edu,
   gcc-prs@gcc.gnu.org
Cc:  
Subject: Re: c++/9393: [3.2/3.3/3.4 regression] Anonymous namespaces and compiling the same file twice
Date: Thu, 10 Apr 2003 16:49:01 -0700

 A better testcase is:
 
 #include <iostream>
 namespace {
    struct S {
        S();
    };
    S::S () { std::cout << "One more call" << std::endl; }
    S local_s;
 }
 
 (you can insert anything you like in the constructor).  You can have as 
 many of these as you like in your program.
 
 One additional problem with the existing behaviour is that you get 
 "determinism" only if inode numbers and modification times don't 
 change.  This means that (a) it's not reproducible; users normally 
 can't control inode numbers; and (b) it's fragile, because both of 
 these can quietly vary, especially on network file systems.
 

Re: c++/9393: [3.2/3.3/3.4 regression] Anonymous namespaces and compiling the same file twice

[ehrhardt]

Synopsis: [3.2/3.3/3.4 regression] Anonymous namespaces and compiling the same file twice

State-Changed-From-To: open->analyzed
State-Changed-By: cae
State-Changed-When: Sat Feb  1 23:25:44 2003
State-Changed-Why:
    Confirmed with 3.2 and 3.4. The current behaviour violates 7.3.1.1[1].
    This worked with 2.95.3, i.e. this is a regression.

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