From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11470 invoked by alias); 6 Mar 2003 22:46:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 11455 invoked by uid 71); 6 Mar 2003 22:46:01 -0000 Date: Thu, 06 Mar 2003 22:46:00 -0000 Message-ID: <20030306224601.11454.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Richard C Bilson Subject: Re: c++/9881: What is an address constant expression? Reply-To: Richard C Bilson X-SW-Source: 2003-03/txt/msg00286.txt.bz2 List-Id: The following reply was made to PR c++/9881; it has been noted by GNATS. From: Richard C Bilson 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 * 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 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