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

[Nathan Sidwell <nathan@codesourcery.com>]

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