Hi, 

As I studied, the issue with this bug is similar as PR102285:

For the testing case:

int
qy (void)
{
  int tw = 4;
  int fb[tw];
  return fb[2]; /* { dg-warning "uninitialized" } */
}

 if compiled with 
/home/opc/Install/cross/bin/riscv64-unknown-linux-gnu-gcc -c -O1  
-mno-strict-align -ftrivial-auto-var-init=pattern -fdump-tree-all t.c

******t.c.032t.cpp1:
int qy ()
{
  unsigned char fb.3[16];
  int tw;
  int[0:D.1494] * fb.1;
  sizetype D.1494;
  void * saved_stack.2_16;
  int _27;

  <bb 2> :
  saved_stack.2_16 = __builtin_stack_save ();
  fb.1_25 = &fb.3;
  (*fb.1_25) = .DEFERRED_INIT (16, 1, 1);
  _27 = (*fb.1_25)[2];
  fb.3 ={v} {CLOBBER};
  __builtin_stack_restore (saved_stack.2_16);
  return _27;

}

******t.c.033t.forwprop1:
int qy ()
{
  unsigned char fb.3[16];
  int tw;
  int[0:D.1494] * fb.1;
  sizetype D.1494;
  void * saved_stack.2_16;
  int _27;

  <bb 2> :
  saved_stack.2_16 = __builtin_stack_save ();
  MEM[(int[0:D.1494] *)&fb.3] = .DEFERRED_INIT (16, 1, 1);
  _27 = MEM[(int[0:D.1494] *)&fb.3][2];
  fb.3 ={v} {CLOBBER};
  __builtin_stack_restore (saved_stack.2_16);
  return _27;

}

the problem with the above IR for .DEFERRED_INIT expansion is:

for MEM[(int[0:D.1494] *)&fb.3] = .DEFERRED_INIT (16, 1, 1)

after the “forwprop1” phase, the original address that point to VLA fb.1 is 
replaced with the the new address that point to fixed array fb.3, however, the 
TREE_TYPE of the MEM still is kept the old VLA type int[0:D.1984]. Such 
inconsistency causes the ICE during expanding of call to the above 
.DEFERRED_INIT.

If during the forwprop, when replacing “fb.1” with “&fb.3”, the TREE_TYPE of 
the MEM_REF can be updated accordingly, we should fix this inconsistency of the 
IR, and therefore fix the issue in DEFERRED_INIT expansion. 

So, I think that the fix should be in “forwprop”, and update the TREE_TYPE of 
the MEM_REF accordingly.

What do you think on this?

thanks.

Qing


Reply via email to