Bug in gen_addr_rtx() in gcc4.1?

2006-04-25 Thread Charles Fu
On a system which supports 64-bit implementation but with TARGET_ILP32
ABI, like HPUX on ia64,  the gcc-4.1 compiler generates incorrect code
for the dejagnu test  gcc.dg/tree-ssa/pr23386.c. The problem seems
because that the gen_addr_rtx() in tree-ssa-address.c always returns
Pmode rtx. On a TARGET_64BIT machine, Pmode is DImode.

  In this case, the following expression is dereferenced after
tree-based transformation:
 *(index+offset)
  where index is an int variable (SImode) and offset is a constant.

  The call sequence in expr.c is:
expand_expr_real_1() --> addr_for_mem_ref() --> gen_addr_rtx()
--> memory_address()

where memory_address() is to generate a necessary zero_extend rtl
instruction to clean the upper 32bit of the returned address rtx from
gen_addr_rtx() if the rtx is not in Pmode.  Because the address rtx is
in Pmode, no zero_extend instruction is generated, and the address is
an illegal address.

It seems for me the correct solution is to generate the address rtx in
gen_addr_rtx() with the widest mode from the operands index and
offset, not always in Pmode.

 Thanks,
 Charles


Re: Bug in gen_addr_rtx() in gcc4.1?

2006-05-02 Thread Charles Fu

Yes. I know it doesn't fail on IA64-HPUX. The reason is
that the dereferencing expression has been transformed as:

 tmpvar = index+offset;
 *tmpvar;

during induction variable optimization, Where tmpvar has SImode.
PPC has different costs to compute induction variables as on IA64-HPUX.

Charles


On 5/2/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:

>
> On a system which supports 64-bit implementation but with TARGET_ILP32
> ABI, like HPUX on ia64,  the gcc-4.1 compiler generates incorrect code
> for the dejagnu test  gcc.dg/tree-ssa/pr23386.c. The problem seems
> because that the gen_addr_rtx() in tree-ssa-address.c always returns
> Pmode rtx. On a TARGET_64BIT machine, Pmode is DImode.

I do not see this failing on ia64-hpux (with -milp32).

http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00080.html
http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00045.html

Are you sure that you are not doing something funny with your
port?

-- Pinski