This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: adjust generation of component addresses
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rth at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 25 Feb 02 18:23:36 EST
- Subject: Re: adjust generation of component addresses
I found a second, completely unrelated, problem with your change:
Consider the Ada test case
procedure Test_Func is
type A_Int is new Integer range 1..10;
type B_Int is new Integer range 11..20;
type A_Array is array(1..5) of A_Int;
type B_Array is array(1..5) of B_Int;
procedure Print_Values (A_Value : in A_Int;
B_Value : in B_Int) is
begin
if A_Value /= 10 then
raise Program_Error;
end if;
end Print_Values;
function Get_A return A_Array is
A : A_Array := (others => 10);
begin
return A;
end Get_A;
function Get_B return B_Array is
B : B_Array := (others => 20);
begin
return B;
end Get_B;
J : Natural := 3;
begin
Print_Values
(A_Value =>Get_A(J), B_Value =>Get_B(J));
end Test_Func;
This is miscompile on all targets. The problem is in the final statement.
The same temp slot is used for the return value of Get_A and Get_B. The
reason is because temp slot tracking expects the temp slot's address to be
put into a register and then to see an offset from that register.
But with your change, the N_ARRAY_REF returns a MEM whose address is a PLUS
of the stack address and an index. find_temp_slot_from_address doesn't
know how to handle that.
But even if we fixed it, it would fail if we reversed the order of the
calls since it would get confused by the low bound of 11 since it would
see an address being added to the index that's not within the bounds of
that temp slot.
In the 3.2-term, I think we have to add the temp slot location to MEM_ATTRS
and use it for temp slot tracking rather than the major mess we have now, but
I think this change will have to be reverted for 3.1 since I don't see how to
fix either problem *or* the one that Doug ran into on VMS.