[RFC]PR103271 ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64
Qing Zhao
qing.zhao@oracle.com
Wed Dec 1 23:37:41 GMT 2021
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
More information about the Gcc-patches
mailing list