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

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

[nathan]

Synopsis: What is an address constant expression?

Responsible-Changed-From-To: unassigned->nathan
Responsible-Changed-By: nathan
Responsible-Changed-When: Tue Apr  8 18:39:20 2003
Responsible-Changed-Why:
    yeah, yeah, I broke it

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9881

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

[nathan]

Synopsis: What is an address constant expression?

State-Changed-From-To: analyzed->closed
State-Changed-By: nathan
State-Changed-When: Mon Apr 21 11:30:04 2003
State-Changed-Why:
    fixed

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9881

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

[Richard C Bilson]

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: nathan@codesourcery.com
Cc: bangerth@ticam.utexas.edu, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
        pabuhr@uwaterloo.ca
Subject: Re: c++/9881: What is an address constant expression?
Date: Mon, 10 Mar 2003 15:33:55 -0500 (EST)

 > I suspect it will break. you need g++.dg/other/packed1.C, I'm curious as to
 > why it didn't fail for you.
 
 Search me.
 
 SunOS plg2.math 5.8 Generic_108528-18 sun4u sparc
 
 [ from g++.log ]
 
 Executing on host: /fsys2/u2/rcbilson/gcc/build/gcc/testsuite/../g++ -B/fsys2/u2/rcbilson/gcc/build/gcc/testsuite/../ /fsys2/u2/rcbilson/gcc/gcc/testsuite/g++.dg/other/packed1.C  -nostdinc++ -I/fsys2/u2/rcbilson/gcc/build/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8 -I/fsys2/u2/rcbilson/gcc/build/sparc-sun-solaris2.8/libstdc++-v3/include -I/fsys2/u2/rcbilson/gcc/libstdc++-v3/libsupc++ -I/fsys2/u2/rcbilson/gcc/libstdc++-v3/libio -I/fsys2/u2/rcbilson/gcc/libstdc++-v3/include/backward -I/fsy s2/u2/rcbilson/gcc/libstdc++-v3/testsuite -fmessage-length=0   -ansi -pedantic-errors -Wno-long-long    -L/fsys2/u2/rcbilson/gcc/build/sparc-sun-solaris2.8/./libstdc++-v3/src/.libs -L/fsys2/u2/rcbilson/gcc/build/sparc-sun-solaris2.8/./libiberty  -lm   -o ./packed1.exe    (timeout = 300)
 PASS: g++.dg/other/packed1.C (test for excess errors)
 PASS: g++.dg/other/packed1.C execution test
 
 Let me know if there is any output from the compiler that you would like
 to see.
 
 - Richard

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

[Nathan Sidwell]

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

From: Nathan Sidwell <nathan@codesourcery.com>
To: Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca>
Cc: bangerth@ticam.utexas.edu, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
   pabuhr@uwaterloo.ca
Subject: Re: c++/9881: What is an address constant expression?
Date: Sat, 08 Mar 2003 14:13:17 +0000

 Richard C Bilson wrote:
 
 > Whether the new behavior is in error is a matter of debate it seems.
 > I think that 5.19.4 requires the initializer in question to be an
 > address constant expression and thus be a static initialization.
 yup, I see you are correct, thanks for the reference.
 
 
 > As far as I can tell, the code to handle &(((T*)0)->x) also works
 > just fine in the case that the pointer is not null.  So I removed the
 > restriction that the operand of the indirection be a NPC.
 > 
 > This fixes our example code, solves the real problem that prompted us to
 > complain in the first place, and doesn't seem to cause any trouble with
 > the gcc test suite.  I can't say whether it would cause a recurrence
 > of the problems you fixed in the first place, but I do have some SPARC
 > machines at my disposal if you have an example of the problem for me
 > to try.
 I suspect it will break. you need g++.dg/other/packed1.C, I'm curious as to
 why it didn't fail for you.
 
 The real problem is gcc does represents a pointer to a misaligned
 int as an 'int *' rather than something like 'int __attribute__((misaligned)) *'
 which would help the dereferencing machinery out. The current mechanmism 'works'
 only when the field decl is visible. The fold behaviour takes that out. Yuck!
 
 nathan
 
 -- 
 Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
           The voices in my head said this was stupid too
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
 
 

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

[Richard C Bilson]

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: nathan@codesourcery.com
Cc: bangerth@ticam.utexas.edu, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
        pabuhr@uwaterloo.ca
Subject: Re: c++/9881: What is an address constant expression?
Date: Fri, 7 Mar 2003 14:31:03 -0500 (EST)

 > From nathan@codesourcery.com  Fri Mar  7 11:25:42 2003
 > Richard C Bilson wrote:
 > 
 > > This is why I believe that the old behavior of gcc was not in error,
 > > regardless of how 5.19.4 is interpreted.
 > and neither is the new behaviour. This is a missed optimization
 > opportunity. My changes were to prevent a miscompilation on
 > sparc and other strict aligned architectures.
 
 Whether the new behavior is in error is a matter of debate it seems.
 I think that 5.19.4 requires the initializer in question to be an
 address constant expression and thus be a static initialization.
 Wolfgang Bangerth has provided a different interpretation -- I don't
 agree with his interpretation, but I'll grant that it's a hard question
 and it doesn't fall to me to decide the answer.
 
 On the other hand, I am capable of proposing a solution, so I will.
 My intent is to restore the old behavior, at least for the expression
 in question.
 
 To fix the offsetof bug, you added some code to fold the address
 calculation in the case that a) the operand of the address is a
 COMPONENT_REF, b) the first operand of the component is an INDIRECT_REF,
 and c) the operand of the indirection is an integer constant.  In other
 words, you're looking for &(((T*)0)->x).  If this expression can be
 computed as a constant, I see no reason why it couldn't be computed as a
 constant if the null pointer is replaced with a pointer to static data --
 this is exactly the case that's causing us problems.
 
 As far as I can tell, the code to handle &(((T*)0)->x) also works
 just fine in the case that the pointer is not null.  So I removed the
 restriction that the operand of the indirection be a NPC.
 
 This fixes our example code, solves the real problem that prompted us to
 complain in the first place, and doesn't seem to cause any trouble with
 the gcc test suite.  I can't say whether it would cause a recurrence
 of the problems you fixed in the first place, but I do have some SPARC
 machines at my disposal if you have an example of the problem for me
 to try.
 
 Many thanks to you and to Wolfgang for taking the time to correspond with
 us on this matter.
 
 - Richard
 
 [ This diff is against the version of cp/typeck.c in the cvs 3.3 branch
 from Monday.  I've been trying to update for a couple of days now, but I
 keep getting "connection reset by peer" from subversions. ]
 
 *** typeck-orig.c       Fri Mar  7 13:44:51 2003
 --- typeck.c    Fri Mar  7 13:47:53 2003
 *************** build_unary_op (code, xarg, noconvert)
 *** 4300,4308 ****
             return error_mark_node;
           }
         else if (TREE_CODE (arg) == COMPONENT_REF
 !                && TREE_CODE (TREE_OPERAND (arg, 0)) == INDIRECT_REF
 !                && (TREE_CODE (TREE_OPERAND (TREE_OPERAND (arg, 0), 0))
 !                    == INTEGER_CST))
           {
             /* offsetof idiom, fold it.  */
             tree field = TREE_OPERAND (arg, 1);
 --- 4300,4306 ----
             return error_mark_node;
           }
         else if (TREE_CODE (arg) == COMPONENT_REF
 !                && TREE_CODE (TREE_OPERAND (arg, 0)) == INDIRECT_REF)
           {
             /* offsetof idiom, fold it.  */
             tree field = TREE_OPERAND (arg, 1);
 
 

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

[Nathan Sidwell]

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

From: Nathan Sidwell <nathan@codesourcery.com>
To: Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca>
Cc: bangerth@ticam.utexas.edu, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
   pabuhr@uwaterloo.ca
Subject: Re: c++/9881: What is an address constant expression?
Date: Fri, 07 Mar 2003 16:25:25 +0000

 Richard C Bilson wrote:
 
 > This is why I believe that the old behavior of gcc was not in error,
 > regardless of how 5.19.4 is interpreted.
 and neither is the new behaviour. This is a missed optimization
 opportunity. My changes were to prevent a miscompilation on
 sparc and other strict aligned architectures.
 
 nathan
 
 -- 
 Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
           The voices in my head said this was stupid too
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
 
 

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

[Richard C Bilson]

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: bangerth@ticam.utexas.edu
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org, nathan@codesourcery.com,
        pabuhr@uwaterloo.ca
Subject: Re: c++/9881: What is an address constant expression?
Date: Fri, 7 Mar 2003 09:47:19 -0500 (EST)

 > From bangerth@ticam.utexas.edu  Thu Mar  6 18:01:02 2003
 > 
 > [I cc:ed Nathan, since he might know what's going on better than at least 
 > me.]
 > 
 > > >     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,
 > 
 > Well, I apologize if I seemed as if I wanted to.
 
 Not at all.  But I've seen where these discussions can end up.
 
 < snip >
 
 > > 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. 
 > 
 > While that is true, it is not the question here: the standard mandates to 
 > initialize 
 > - first dynamic data by zero
 > - then, constant initialized data by their value
 > - finally, dynamic data by their dynamically computed initializer
 > If the compiler can shortcut computations for the last category, it must 
 > not start initialization before the second class is completed, 
 > nevertheless. 
 
 Sorry, I mis-spoke -- what I was writing did not correspond exactly with
 what I was thinking.  What I meant to point out was that 3.6.2p2 permits an
 implementation to treat any initialization as a static initialization if it
 can (subject to certain restrictions that don't apply to the initializer in
 question here).  To use your terminology, this allows an implementation to
 move an initializer from class 3 to class 2.
 
 This is why I believe that the old behavior of gcc was not in error,
 regardless of how 5.19.4 is interpreted.
 
 - Richard

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

[Wolfgang Bangerth]

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

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Richard C Bilson <rcbilson@plg2.math.uwaterloo.ca>
Cc: asharji@uwaterloo.ca, <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>,
   <pabuhr@uwaterloo.ca>, <nathan@codesourcery.com>
Subject: Re: c++/9881: What is an address constant expression?
Date: Thu, 6 Mar 2003 17:00:49 -0600 (CST)

 [I cc:ed Nathan, since he might know what's going on better than at least 
 me.]
 
 > >     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,
 
 Well, I apologize if I seemed as if I wanted to. At least to me, it was
 not at all clear what might be the reasoning why this testcase might or
 should not fail. I think at least we now know which clauses are relevant,
 and what is the question that must be decided.
 
 > 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. 
 
 While that is true, it is not the question here: the standard mandates to 
 initialize 
 - first dynamic data by zero
 - then, constant initialized data by their value
 - finally, dynamic data by their dynamically computed initializer
 If the compiler can shortcut computations for the last category, it must 
 not start initialization before the second class is completed, 
 nevertheless. 
 
 In the testcase, an element of the second class has slipped into the
 third. The question I couldn't answer was whether it belongs to class 2 or 
 3. If it is 3, then the previous behavior was in error. If it is 2, then 
 the present behavior is a regression.
 
 
 > 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>
 > 2002-08-15  Nathan Sidwell  <nathan@codesourcery.com>
 
 Thanks for this very good detective work of figuring out which patch 
 caused the problem!
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth             email:            bangerth@ticam.utexas.edu
                               www: http://www.ticam.utexas.edu/~bangerth/
 
 

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

[Richard C Bilson]

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

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

[bangerth]

Old Synopsis: Incorrect address calculation for static class member
New Synopsis: What is an address constant expression?

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Wed Mar  5 22:10:32 2003
State-Changed-Why:
    I think this is now analyzed. We need a language lawyer
    to look at it.
    
    W.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9881