This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/9881: What is an address constant expression?
- From: Richard C Bilson <rcbilson at plg2 dot math dot uwaterloo dot ca>
- To: asharji at uwaterloo dot ca, bangerth at dealii dot org, gcc-bugs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, pabuhr at uwaterloo dot ca
- Date: Thu, 6 Mar 2003 17:39:58 -0500 (EST)
- Subject: Re: c++/9881: What is an address constant expression?
> 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 at codesourcery dot 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 at codesourcery dot 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