This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/9881: Incorrect address calculation for static class member
- From: "Peter A. Buhr" <pabuhr at plg2 dot math dot uwaterloo dot ca>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 27 Feb 2003 22:56:00 -0000
- Subject: Re: c++/9881: Incorrect address calculation for static class member
- Reply-to: "Peter A. Buhr" <pabuhr at plg2 dot math dot uwaterloo dot ca>
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 ticam dot utexas dot edu
Cc: asharji at uwaterloo dot ca, gcc-bugs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Subject: Re: c++/9881: Incorrect address calculation for static class member
Date: Thu, 27 Feb 2003 17:51:18 -0500 (EST)
> 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.
At which point you are out of luck in any case, since the standard does
not give any guarantee about the order of initialization in case there are
more than one translation units.
I think it does. All static variables in all translation units must be
initialized before any global constructors in any translation unit. The static
initialization is usually done by reading constants from the .data section or by
the linker/loader. So if I initialize a static variable in one translation
unit, it must be initialized before a constructor is run in any another
translation unit. I think you are referring to the order of evaluation of
global constructors across translation units, which is undefined.
May other language lawyers decide this case, regards
Let me change the program slightly and see if this clarifies the situation.
#include <iostream>
using namespace::std;
struct bar {
double p;
}; // bar
struct module {
static double *b;
static double storage;
};
class foo {
public:
foo() {
// the output for both values should be the same
cout << &module::storage << " " << module::b << endl;
}
};
foo f; // print output
bar v;
double *module::b = &(((bar *)(&v))->p); // LINE X
//double *module::b = &(((bar *)(&module::storage))->p); // LINE Y
double module::storage = 0.0;
int main() {
}
If you run this with gcc3.3, the output is:
@awk[5]% a.out
0x8049a50 0x8049a48
Now comment out LINE X, and uncomment LINE Y and run again getting output:
@awk[6]% a.out
0x8049a78 0
Zero (0) is not an acceptable address. BUT, the only different between these 2
lines is the chunk of storage for the object. Notice this has nothing to do
with the constructor. One case works and one doesn't. Is this not compelling?