This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: c++/9881: Incorrect address calculation for static class member


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

From: "Peter A. Buhr" <pabuhr at plg2 dot math dot uwaterloo dot ca>
To: bangerth at dealii dot org, gcc-bugs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Cc: asharji at uwaterloo dot ca
Subject: Re: c++/9881: Incorrect address calculation for static class member
Date: Thu, 27 Feb 2003 16:39:14 -0500 (EST)

    Synopsis: Incorrect address calculation for static class member
 
    State-Changed-From-To: open->closed
    State-Changed-By: bangerth
    State-Changed-When: Thu Feb 27 18:22:41 2003
    State-Changed-Why:
        In this code,
 	 foo f; // print output
 
 	 double *module::b = &(((bar *)&module::storage)->p);
 	 double module::storage = 0.0;
 
        The constructor of foo is run before module::b is initialized.
        If you change this order, the output is as you expect.
 
        W.
 
    http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9881
 
 Your response is incorrect. First, the program generates the correct result
 with gcc3.2. If you run the example with both gcc3.2 and gcc3.3, you will see
 that the output is different. Hence, one can conclude that either gcc3.2 or
 gcc3.3 is wrong. Second, when the example program is run with the SUN compiler,
 it generates the same output as for gcc3.2, indicating that the problem is
 probably in gcc3.3. Third, the position of the constructor has nothing to do
 with the assignment to a static variable. The expression to initialize the
 static variable "module::b" *MUST* be evaluated at compiler time. All static
 variables *MUST* be initialized before any constructor is run because a
 constructor can refer to these variables. Finally, your suggestion is not even
 a work-around, because the original problem occurred in separate compilation
 units, so the notion of moving the constructor in this case does not apply.
 
 It is slightly disconcerting that you should close this bug report without at
 least checking with the people that reported the problem.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]