Re: IA64 Patch for pointer extension

[Steve Ellcey <sje at cup dot hp dot com>]

> On Tue, Apr 26, 2005 at 10:57:56AM -0700, Steve Ellcey wrote:
> > 	* expr.c (expand_expr_real_1): Handle expansion of pointers.
> 
> I guess this is ok, but I wonder what will happen if EXPAND_INITIALIZER
> is set.  Try something like
> 
> 	typedef void * ptr64 __attribute__((mode(DI)));
> 	int x;
> 	void *y = &x;
> 	ptr64 z = &x;
> 
> 
> 
> r~

It looks like this doesn't quite work right.  If I assemble this I get:

       .file   "x.c"
        .pred.safe_across_calls p1-p5,p16-p63
        .global y#
        .section        .sdata,"aws",@progbits
        .align 4
        .type   y#, @object
        .size   y#, 4
y:
        data4   x#
        .global z#
        .align 8
        .type   z#, @object
        .size   z#, 8
z:
        data4   x#
        .skip   4
        .common x#,4,4
        .ident  "GCC: (GNU) 4.1.0 20050425 (experimental)"

So z is set up as an 8 byte object, which is good, but the intial value,
the address of x is put in with data4 instead of data8.  I verified that
if I initialized z with 'data8 x#' instead of 'data4 x#' then everything
does seem to work OK.

Looking at where the data4 comes from I wind up in output_constant.  On
entry, size is set to 8 but then it calculates thissize and that is set
to 4, so when it calls assemble_integer with 'MIN (size, thissize)' I
get a 4 byte pointer instead of an 8 byte pointer.  It seems like I
would need to fix this in varasm.c directly instead of in target
specific code because the 'damage' has already been done before I call
assemble_integer which is something I could override with target
specific code.

Any advice on how to handle this?

Steve Ellcey
sje@cup.hp.com