Re: Bootstrap of trunk fails with Ada on powerpc-unknown-linux-gnu.

[Ulrich Weigand <uweigand at de dot ibm dot com>]

Andrew Pinski wrote:
> On Jan 25, 2005, at 7:37 PM, Richard Kenner wrote:
> 
> >     Notice how we take the address of a CONSTRUCTOR this is wrong and 
> > we
> >     should never do that.
> >
> > And why is that?  How else would you express making a "fat pointer"
> > for a constant?  (Yes, you could create a temporary, but why?  If
> > gimplification wants one, it can make one (and will)).  This has
> > always been done and hasn't caused any problems.  If something
> > suddenly broke, it's not related to that.
> 
> I asked RTH about this before posting this here and he said Ada 
> front-end
> was broken and you need to create a temporary variable for the 
> ADDR_EXPR.
> 
> I think there was another case like this in the Objective-C front-end
> which fixed to create a CONST_DECL for it.

I've now found a second instance of the same problem (tree check ICE --
expected ssa_name, have var_decl), which does *not* involve taking
the address of a CONSTUCTOR, but simply the addres of a local variable.

In fact, I've managed to reduce the problem to a C-only testcase that
still shows the same ICE.  So I don't think this is a front-end issue
(note that ADDR_EXPRs of CONSTRUCTORs are otherwise working for Ada
because the Ada front-end specific gimplifier reduces them by
creating a temporary variable).

The C test case is:


struct test { int *x; } global_test;
int global_int;

int flag;

void test (char *dummy)
{
  static const struct test const_test = { &global_int };
  struct test local_test;

  int i;
  for (i = 0; i < 1; i++)
    *dummy = 0;
  if (flag)
    __builtin_memset (dummy, 0, 16);

  local_test = const_test;
  global_test = local_test;
}



It ICEs with
krk.c: In function 'test':
krk.c:8: internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:679

in verify_ssa at:

677               FOR_EACH_SSA_TREE_OPERAND (op, stmt, iter, SSA_OP_ALL_USES | SSA_OP_ALL_KILLS)
678                 {
679                   if (verify_use (bb, definition_block[SSA_NAME_VERSION (op)],
680                                   op, stmt, false, !is_gimple_reg (op),
681                                   names_defined_in_bb))
682                     goto err;
683                 }

for the 'stmt':

(gdb) call debug_generic_stmt (stmt)
#   flagD.1053_12 = V_MAY_DEF <flagD.1053_3>;
#   global_testD.1051_13 = V_MAY_DEF <global_testD.1051_27>;
#   global_intD.1052 = V_MAY_DEF <global_intD.1052>;
#   VUSE <const_testD.1057_7>;
__builtin_memset (dummyD.1054_11, 0, 16);

because 'op' is not a SSA_NAME:

(gdb) call debug_tree (op)
 <var_decl 0x77e13000 global_int
    type <integer_type 0x77dab438 int public SI
        size <integer_cst 0x77da2440 constant invariant 32>
        unit size <integer_cst 0x77da2100 constant invariant 4>
        align 32 symtab 0 alias set 3 precision 32 min <integer_cst 0x77da23e0 -2147483648> max <integer_cst 0x77da2400 2147483647>
        pointer_to_this <pointer_type 0x77db5ac8>>
    addressable used public static ignored common SI file krk.c line 3 size <integer_cst 0x77da2440 32> unit size <integer_cst 0x77da2100 4>
    align 32 chain <var_decl 0x77e13078 flag>>


I do not quite understand who's at fault here.  Should global_int
have been wrapped into a SSA_NAME?  The SRA pass, which initially
exposed that variable, does mark it in vars_to_rename and the
subsequent rewrite_into_ssa pass does something with it, but the
var_decl is kept in the statement.  The .sra dump says:

test (dummy)
{
  int * local_test$x;
  int i;
  struct test local_test;
  static struct test const_test = {.x=&global_int};
  int flag.0;

<bb 0>:

  # i_24 = PHI <i_14(1), 0(0)>;
<L0>:;
  *dummy_11 = 0;
  i_14 = i_24 + 1;
  if (i_14 <= 0) goto <L0>; else goto <L2>;

<L2>:;
  flag.0_5 = flag;
  if (flag.0_5 != 0) goto <L3>; else goto <L4>;

<L3>:;
  __builtin_memset (dummy_11, 0, 16);

<L4>:;
  local_test$x_23 = &global_int;
  global_test.x = local_test$x_23;
  return;

}


I guess I'll have to defer to the SSA folks to debug this ...

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  Ulrich.Weigand@de.ibm.com