[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721

--- Comment #20 from H.J. Lu <hjl.tools at gmail dot com> 2011-08-03 13:56:05 UTC ---
(In reply to comment #17)
> H.J., I agree with what you write in comment 16.  But unless we are sure that
> the problematic composition will never be generated (e.g. by ivopts), we cannot
> afford that.

I come to a conclusion that we must transform

ptr_extend:DI (plus:SI (FOO:SI) (const_int Y)))

to

(plus:DI (ptr_extend:DI (FOO:SI)) (const_int Y))

since this this how GCC supports Pmode != ptr_mode. You can
disable it and watch its fallout on HP-UX.  We never run into
it for zero_extend before since x32 is the first zero_extend
target.  We should extend it to zero_extend.

> The patch in comment 7 may have some snafu, but overall it looks very sane. 
> It's just that a const is not being stripped.  Can it be applied on top of the

I tried to strip const with

diff --git a/gcc/explow.c b/gcc/explow.c
index 069a68a..17afbbc 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -380,7 +380,7 @@ convert_memory_address_addr_space_1 (enum machine_mode
to_mode ATTRIBUTE_UNUSED,
     case CONST:
       temp = convert_memory_address_addr_space_1 (to_mode, XEXP (x, 0),
                    as, no_emit);
-      return temp ? gen_rtx_CONST (to_mode, temp) : temp;
+      return temp && !REG_P (temp) ? gen_rtx_CONST (to_mode, temp) : temp;
       break;

     case PLUS:

and it still has massive failures:

http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00264.html

> x32 branch?  Or do I first have to revert some earlier revision?

The patch in comment 7 is for trunk.