[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