Re: c++/9881: What is an address constant expression?

[Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca>]

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

From: Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca>
To: asharji@uwaterloo.ca, bangerth@dealii.org, gcc-bugs@gcc.gnu.org,
        gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org,
        pabuhr@uwaterloo.ca
Cc:  
Subject: Re: c++/9881: What is an address constant expression?
Date: Thu, 6 Mar 2003 17:39:58 -0500 (EST)

 >     I think this is now analyzed. We need a language lawyer
 >     to look at it.
 
 Before we start bashing each other over the head with our respective
 copies of the standard, let me ask a different question: was the
 change in gcc's behavior for this example intentional or accidental?
 Clearly, section 3.6.2 of the standard permits an implementation to
 compute static initializers at compile time even if no other part of
 the standard requires it to do so.  Even if the desired behavior is
 not mandated by the standard, it's still a beneficial optimization,
 provided that gcc wasn't generating incorrect code because of it.  So,
 if the change was accidental, relying on the standard to justify the
 current behavior is simply a way of avoiding the work it would take to
 restore the previous (better) behavior.
 
 I don't mean any disrespect to the gcc developers there -- their
 priorities are undoubtedly different from ours.  Peter asked me to
 look into this, and some debugging has convinced me that the change
 was accidental.
 
 Previously, the constant_flag was set for the expression in question (that
 is, &((bar*)&module::storage)->p) by the function build_component_addr
 in cp/typecheck.c.  This function was removed from the 3.3 branch:
 
 2002-08-08  Nathan Sidwell  <nathan@codesourcery.com>
 
         * typeck.c (build_component_addr): Remove.
         (build_unary_op): Just check it's not a bitfield, and then build
         an ADDR_EXPR.
 
 The intent here seems to have been to simplify the code by removing a
 function that was unnecessarily complicated.  However, the result was an
 oversimplification, as evidenced by
 
 2002-08-15  Nathan Sidwell  <nathan@codesourcery.com>
 
         PR c++/7598
         * typeck.c (build_unary_op): Fold offsetof idiom. Fixes
         regression caused by my 2002-08-08 patch.
 
 The code in question is very similar to offsetof, but it doesn't quite
 pass the test that Mr. Sidwell put in to fix offsetof.  As a result,
 the expression is no longer marked as constant.
 
 I am going to try to determine a more appropriate test to go in its place.
 Others who are more familiar with the g++ source are encouraged to try as
 well.
 
 - Richard