This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [cft] fix middle-end/16417

Thanks for looking at this.

Richard Henderson <> 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 ();


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;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]