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: Wolfgang Bangerth <bangerth at ticam dot utexas dot edu>
To: "Peter A. Buhr" <pabuhr at plg2 dot math dot uwaterloo dot ca>
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:09:09 -0600 (CST)

 >    bar v;
 >    double *module::b = &(((bar *)(&v))->p); // LINE X
 >    //double *module::b = &(((bar *)(&module::storage))->p); // LINE Y
 > 
 > 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.
 
 Well, zero is the value the standard prescribes of initial initialization, 
 i.e. before dynamic initializers are run.
 
 > 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?
 
 Well, all the questions you raise boil down to the question: what is an 
 address constant expression. Apparently, the compiler chooses to consider 
 the initializer in line X to be one, while it doesn't for line Y. I cannot 
 answer the question further than what I did in my previous mail, apart 
 from the fact that line X has not cast (or, rather: a cast from one type 
 to itself), while line Y has a (reinterpret_)cast from type module to 
 incompatible type bar.
 
 Just as an aside, independent of the validity of the PR in itself: why are 
 you making it so particularly hard for the compiler to decide this? You 
 are setting module::b to &module::storage; there is simple syntax to 
 achieve this goal than teh one you use, no? :-)
 
 Cheers
   W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth at ticam dot utexas dot edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 


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