Re: c++/10112: static data member is not correctly initialised

Re: c++/10112: static data member is not correctly initialised

[nathan]

Synopsis: static data member is not correctly initialised

State-Changed-From-To: open->analyzed
State-Changed-By: nathan
State-Changed-When: Mon Mar 17 12:04:17 2003
State-Changed-Why:
    the ordering of these two template instantiations is implementation defined. I think there's an algorithm to get
    the order right
    
    nathan

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

Re: c++/10112: static data member is not correctly initialised

[Oliver Kullmann]

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

From: Oliver Kullmann <O.Kullmann@Swansea.ac.uk>
To: nathan@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/10112: static data member is not correctly initialised
Date: Mon, 17 Mar 2003 18:49:06 +0000

 On Mon, Mar 17, 2003 at 12:04:17PM -0000, nathan@gcc.gnu.org wrote:
 > Date: 17 Mar 2003 12:04:17 -0000
 > To: O.Kullmann@Swansea.ac.uk, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
 >    nobody@gcc.gnu.org
 > From: nathan@gcc.gnu.org
 > Reply-To: nathan@gcc.gnu.org, O.Kullmann@Swansea.ac.uk, gcc-bugs@gcc.gnu.org,
 >    gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
 > X-Mailer: gnatsweb 2.9.3
 > Subject: Re: c++/10112: static data member is not correctly initialised
 > X-Spam-Status: No, hits=-99.3 required=8.0
 > 	tests=NO_REAL_NAME,USER_IN_WHITELIST
 > 	version=2.50
 > X-Spam-Level: 
 > X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
 > 
 > Synopsis: static data member is not correctly initialised
 > 
 > State-Changed-From-To: open->analyzed
 > State-Changed-By: nathan
 > State-Changed-When: Mon Mar 17 12:04:17 2003
 > State-Changed-Why:
 >     the ordering of these two template instantiations is implementation defined. I think there's an algorithm to get
 >     the order right
 >     
 >     nathan
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10112
 
 Hi,
 
 (I hope that's the right way to reply?!)
 
 hmhm, might be. I guess the relevant sentence is
 
 in particular, the initialization (and any associated side-effects) of a static data member does not occur unless the static data member is itself used in a way that requires the definition of the static data member to exist.
 
 (section 14.7.1 of ISO/IEC 14882:1998(E)),
 
 and thus one could conclude that in Giovanni's example in the instruction
 
 assert(B<int>::p1 == B<int>::a.p);
 
 the order of initialisations depends on the order of evaluation of the equality
 expression, which is implementation defined.
 
 Is this the interpretation?!
 
 The best solution (which might also be a better design) seems to me, to put the
 static data member (in the example, of class B) into a new (local) class X (or struct),
 for which we provide a constructor guaranteeing the right order of initialisation. 
 The host class B then has one static data member of type X. When we first use this
 data member, it will be constructed using the right order of initialisation.
 
 Sounds okay to me. (Worked in my case.)
 
 Thanks for your help!
 
 Oliver
 
 -- 
 Dr. Oliver Kullmann
 Computer Science Department
 University of Wales Swansea
 Faraday Building, Singleton Park
 Swansea SA2 8PP, UK
 http://cs-svr1.swan.ac.uk/~csoliver/
 

Re: c++/10112: static data member is not correctly initialised

[Giovanni Bajo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

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

From: "Giovanni Bajo" <giovannibajo@libero.it>
To: <gcc-gnats@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>,
	<nobody@gcc.gnu.org>,
	<O.Kullmann@Swansea.ac.uk>,
	<gcc-prs@gcc.gnu.org>
Cc:  
Subject: Re: c++/10112: static data member is not correctly initialised
Date: Sun, 16 Mar 2003 23:22:30 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p
 r=10112
 
 Confirmed with 3.2, cygwin on x86. Reduced snippet is:
 
 ----------------------------------
 #include <cassert>
 using namespace std;
 
 struct A
 {
  int p;
 
  A(int _p) : p(_p)
  {}
 };
 
 template <typename T>
 struct B
 {
   static A a;
   static int p1;
 };
 
 
 template <typename T> A B<T>::a(123);
 template <typename T> int B<T>::p1 = a.p;
 
 int main()
 {
  // Should not assert, but it does
  assert(B<int>::p1 == B<int>::a.p);
 }
 ----------------------------------
 
 Looking at the generated code on x86, it seems that the two variables are
 initialized in reversed order:
 
 00401104 <__Z41__static_initialization_and_destruction_0ii>:
     [....]
   401139: a1 b0 e8 40 00        mov    0x40e8b0,%eax
   40113e: a3 a0 e8 40 00        mov    %eax,0x40e8a0
     [....]
   401172: c7 04 24 b0 e8 40 00  movl   $0x40e8b0,(%esp,1)
   401179: c7 44 24 04 7b 00 00  movl   $0x7b,0x4(%esp,1)
   401180: 00
   401181: e8 9a 47 00 00        call   405920 <__ZN1AC1Ei>
 
 00405920 <__ZN1AC1Ei>:
   405920: 55                    push   %ebp
   405921: 89 e5                 mov    %esp,%ebp
   405923: 8b 55 08              mov    0x8(%ebp),%edx
   405926: 8b 45 0c              mov    0xc(%ebp),%eax
   405929: 89 02                 mov    %eax,(%edx)
   40592b: 5d                    pop    %ebp
   40592c: c3                    ret
 
 
 The code at 401139 copies B<T>::a.p into B<T>::p1 (it's the initialization
 of B<T>::p1), while the second block initializes B<T>::a.p with 123 (0x7b),
 but it's too late. I tried with no optimization, and -O0/1/2/3 and there is
 no difference, the code is always wrong.
 
 As for the standard, §9.4.2p7 says <<Static data members are initialized and
 destroyed exactly like nonlocal objects (3.6.2, 3.6.3).>>. §3.6.2p1 says:
 <<Objects of POD types (3.9) with static storage duration initialized with
 constant expressions (5.19) shall be initialized before any dynamic
 initialization takes place. Objects with static storage duration defined in
 namespace scope in the same translation unit and dynamically initialized
 shall be initialized in the order in which their definition appears in the
 translation unit.>>. Now, B<T>::p1 is a POD type but it is not initialized
 with a constant expression, so I don't see any reason why it should be
 initialized before B<T>::a.
 
 Giovanni Bajo
 

c++/10112: static data member is not correctly initialised

[O.Kullmann]

>Number:         10112
>Category:       c++
>Synopsis:       static data member is not correctly initialised
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 16 20:06:02 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Oliver Kullmann
>Release:        gcc 3.2.1
>Organization:
>Environment:
> g++ -v
Reading specs from /compsci/partition1/csoliver/GCC/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
Configured with: /compsci/partition1/csoliver/GCC/gcc-3.2.1/configure --enable-threads=posix --enable-long-long --prefix=/compsci/partition1/csoliver/GCC/gcc-3.2.1 --with-local-prefix=/compsci/partition1/csoliver/GCC/Include_3.2.1 --enable-languages=c,c++ --disable-nls --enable-shared
Thread model: posix
gcc version 3.2.1
>Description:
When compiling the attached file (56 lines) with

> g++ FehlerInit.cpp

and running it I get

> ./a.out
-33630626
Speicherzugriffsfehler

The first line in main
LitIntOccInt::Var v;
yields a call of the member function
InfoPolicyVector<int>::new_variable()
which prints out the iterator difference between
centre and info_vector.begin(), where
centre is a static data member initialised to
info_vector.begin(),
and thus the result should be 0, but as shown
above, it is "undefined".

The code given seems to be a minimal example
(up to some typedefs) in the sense, that removing
any other stuff (which seems completely unrelated
to the above behaviour) changes the output to
the correct "0".
>How-To-Repeat:
Compile and run.
>Fix:
I have no idea. It seems to me quite serious.

P.S. Perhaps it would be a good idea to somehow
improve the instructions for submitting a bug.
For example I couldn't find an explanation of
what the above abbreviations for the error class
could mean.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/x-c++src; name="FehlerInit.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="FehlerInit.cpp"

Ly8gT2xpdmVyIEt1bGxtYW5uLCBTd2Fuc2VhLCAxNi4zLjIwMDMKCiNpbmNsdWRlIDx2ZWN0b3I+
CiNpbmNsdWRlIDxpb3N0cmVhbT4KCnRlbXBsYXRlIDxjbGFzcyBMaXRlcmFsTGluaz4Kc3RydWN0
IFZhcmlhYmxlc0FzSW5kaWNlcyB7CiAgdm9pZCBpbnNlcnQoKSB7CiAgICBMaXRlcmFsTGluazo6
bmV3X3ZhcmlhYmxlKCk7CiAgfQogIFZhcmlhYmxlc0FzSW5kaWNlcygpIHsKICAgIGluc2VydCgp
OwogIH0KfTsKCnN0cnVjdCBPY2N1cnJlbmNlcyB7CiAgaW50IHBvczsKfTsKCnRlbXBsYXRlIDx0
eXBlbmFtZSBJbmRleD4Kc3RydWN0IEluZm9Qb2xpY3lWZWN0b3IgewogIHR5cGVkZWYgT2NjdXJy
ZW5jZXMgSW5mb1ZhbHVlVHlwZTsKICB0eXBlZGVmIE9jY3VycmVuY2VzJiBJbmZvUmVmZXJlbmNl
VHlwZTsKICB0eXBlZGVmIHR5cGVuYW1lIHN0ZDo6dmVjdG9yPE9jY3VycmVuY2VzPiBJbmZvVmVj
dG9yVHlwZTsKICBzdGF0aWMgSW5mb1ZlY3RvclR5cGUgaW5mb192ZWN0b3I7CiAgc3RhdGljIHR5
cGVuYW1lIEluZm9WZWN0b3JUeXBlOjppdGVyYXRvciBjZW50cmU7CiAgc3RydWN0IExpbmsgewog
ICAgc3RhdGljIHZvaWQgbmV3X3ZhcmlhYmxlKCkgewogICAgICBzdGQ6OmNlcnIgPDwgY2VudHJl
IC0gaW5mb192ZWN0b3IuYmVnaW4oKSA8PCAiXG4iOwogICAgfQogIH07CiAgT2NjdXJyZW5jZXMm
IGdldF9pbmZvKGludCBpKSBjb25zdCB7CiAgICByZXR1cm4gKihjZW50cmUgKyBpKTsKICB9Cn07
CnRlbXBsYXRlIDx0eXBlbmFtZSBJbmRleD4KdHlwZW5hbWUgSW5mb1BvbGljeVZlY3RvcjxJbmRl
eD46OkluZm9WZWN0b3JUeXBlIEluZm9Qb2xpY3lWZWN0b3I8SW5kZXg+OjppbmZvX3ZlY3Rvcigx
KTsKdGVtcGxhdGUgPHR5cGVuYW1lIEluZGV4Pgp0eXBlbmFtZSBJbmZvUG9saWN5VmVjdG9yPElu
ZGV4Pjo6SW5mb1ZlY3RvclR5cGU6Oml0ZXJhdG9yIEluZm9Qb2xpY3lWZWN0b3I8SW5kZXg+Ojpj
ZW50cmUoaW5mb192ZWN0b3IuYmVnaW4oKSk7Cgp0ZW1wbGF0ZSA8dHlwZW5hbWUgSW5kZXgsIHRl
bXBsYXRlIDx0eXBlbmFtZSBJbmRleD4gY2xhc3MgSW5mb1BvbGljeUxpdD4Kc3RydWN0IExpdGVy
YWxzQXNJbnRlZ2VycyA6IEluZm9Qb2xpY3lMaXQ8SW5kZXg+IHsKICB0eXBlZGVmIFZhcmlhYmxl
c0FzSW5kaWNlczx0eXBlbmFtZSBJbmZvUG9saWN5TGl0PEluZGV4Pjo6TGluayA+IFZhcjsKICB0
eXBlbmFtZSBJbmZvUG9saWN5TGl0PEluZGV4Pjo6SW5mb1JlZmVyZW5jZVR5cGUgb3BlcmF0b3Ig
KigpIGNvbnN0IHsKICAgIHJldHVybiBnZXRfaW5mbygwKTsKICB9Cn07Cgp0eXBlZGVmIExpdGVy
YWxzQXNJbnRlZ2VyczxpbnQsIEluZm9Qb2xpY3lWZWN0b3I+IExpdEludE9jY0ludDsKCmludCBt
YWluKCkgewogIExpdEludE9jY0ludDo6VmFyIHY7CiAgTGl0SW50T2NjSW50IHk7CiAgKCp5KS5w
b3MgPSA3Owp9Cg==