[cft] fix middle-end/16417
Richard Sandiford
rsandifo@redhat.com
Thu Dec 16 21:14:00 GMT 2004
Thanks for looking at this.
Richard Henderson <rth@redhat.com> writes:
> The problem in this pr is that the callee-copy code there in
> assign_parm_setup_reg asks for the size of a variable-sized
> parameter. Except that we've deleted as unused the gimplified
> variable that size depends on.
>
> The only way to fix this is to expose the use of the variable
> earlier, at the gimple level. This isn't too difficult if we
> re-use some of the assign_parms machinery...
>
> Will the affected systems please regression test this?
Tested on mipsisa64-elf. It fixes execute/20020210-1.c but
introduces two C regressions:
FAIL: gcc.c-torture/execute/20040703-1.c execution, -O0
FAIL: gcc.c-torture/execute/complex-2.c execution, -O0
The latter contains:
__complex__ double
f (__complex__ double x, __complex__ double y)
{
x += y;
return x;
}
and we're no longer making a copy of "x", so:
if (a != 1.0 + 1.0i)
abort ();
fails.
It also introduces some C++ regressions:
FAIL: g++.dg/other/crash-2.C (test for excess errors)
FAIL: g++.old-deja/g++.other/incomplete.C (test for errors, line 14)
FAIL: g++.old-deja/g++.other/incomplete.C (test for errors, line 15)
FAIL: g++.old-deja/g++.other/incomplete.C (test for errors, line 16)
The first is a segfault here in gimplify_callee_copies:
/* For constant sized objects, this is trivial; for
variable-sized objects, we have to play games. */
if (TREE_CONSTANT (DECL_SIZE (parm)))
{
local = create_tmp_var (type, get_name (parm));
DECL_IGNORED_P (local) = 0;
}
Richard
More information about the Gcc-patches
mailing list