https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899
--- Comment #3 from Renlin Li <renlin at gcc dot gnu.org> --- (In reply to Renlin Li from comment #1) > in tree-loop-distribution.c, distribution_loop function, I got the following > code snippets. > > 30386: 0103cff4 4 OBJECT LOCAL DEFAULT 25 _ZL23bb_top_order_index_s > 30387: 0103cff8 4 OBJECT LOCAL DEFAULT 25 _ZL18bb_top_order_index > 30388: 0103cffc 4 OBJECT LOCAL DEFAULT 25 _ZL10ddrs_table > 30389: 0103d000 4 OBJECT LOCAL DEFAULT 25 _ZL9loop_nest > 30390: 0103d004 4 OBJECT LOCAL DEFAULT 25 _ZL12datarefs_vec > > > r1 = 0x103cff4, which points to the local anchor area. > r4 is the dynamically allocated has_table pointer which supposed to be store > into ddrs_table, i.e. 0103cffc. > > 0x61a346 <distribute_loop(loop*, vec<gimple*, va_heap, vl_ptr>, > control_dependences*, int*, bool*)+90>: strb r7, [r2, #0] > 0x61a348 <distribute_loop(loop*, vec<gimple*, va_heap, vl_ptr>, > control_dependences*, int*, bool*)+92>: str.w r7, [r8] > 1=>0x61a34c <distribute_loop(loop*, vec<gimple*, va_heap, vl_ptr>, > control_dependences*, int*, bool*)+96>: str.w r7, [r1, #12]! > 0x61a350 <distribute_loop(loop*, vec<gimple*, va_heap, vl_ptr>, > control_dependences*, int*, bool*)+100>: mov r5, r1 > 2=>0x61a352 <distribute_loop(loop*, vec<gimple*, va_heap, vl_ptr>, > control_dependences*, int*, bool*)+102>: str r4, [r1, #8] > 0x61a354 <distribute_loop(loop*, vec<gimple*, va_heap, vl_ptr>, > control_dependences*, int*, bool*)+104>: str r0, [r4, #0] > 0x61a356 <distribute_loop(loop*, vec<gimple*, va_heap, vl_ptr>, > control_dependences*, int*, bool*)+106>: mov r0, r9 > > However, r1 is changed by the previous pre-indexed store at 0x61a34c (marked > as 1). > This makes the store later store the pointer in the wrong position. > Later when accessing ddrs_table, it got a null pointer, eventually resulting > in the ICE observed here. > > The full assembly is attached. Before the change: 0x0061a746 <+26>: bl 0xc86134 <operator new(unsigned int)> 0x0061a74a <+30>: movw r2, #57316 ; 0xdfe4 0x0061a74e <+34>: movt r2, #259 ; 0x103 0x0061a752 <+38>: str r2, [sp, #28] 0x0061a754 <+40>: mov r4, r0 0x0061a756 <+42>: movw r0, #389 ; 0x185 0x0061a75a <+46>: str r7, [r4, #8] 0x0061a75c <+48>: str r7, [r4, #12] 0x0061a75e <+50>: strd r7, r7, [r4, #16] 0x0061a762 <+54>: strh r7, [r4, #28] 0x0061a764 <+56>: bl 0xc2bc50 <hash_table_higher_prime_index(unsigned long)> 0x0061a768 <+60>: movw r3, #8452 ; 0x2104 0x0061a76c <+64>: movt r3, #242 ; 0xf2 0x0061a770 <+68>: lsls r2, r0, #4 0x0061a772 <+70>: mov r5, r0 0x0061a774 <+72>: mov r0, r4 0x0061a776 <+74>: ldr r6, [r3, r2] 0x0061a778 <+76>: mov r1, r6 0x0061a77a <+78>: bl 0x61d1b4 <hash_table<ddr_hasher, xcallocator>::alloc_entries(unsigned int) const> 0x0061a77e <+82>: ldr.w r12, [sp, #28] 0x0061a782 <+86>: ldr r2, [sp, #296] ; 0x128 0x0061a784 <+88>: str r5, [r4, #24] 0x0061a786 <+90>: mov r1, r12 0x0061a788 <+92>: str r6, [r4, #4] 0x0061a78a <+94>: strb r7, [r2, #0] 0x0061a78c <+96>: mov r5, r12 0x0061a78e <+98>: str.w r7, [r8] 0x0061a792 <+102>: str.w r7, [r1, #12]! 0x0061a796 <+106>: str.w r4, [r12, #8] We can see that, r4 is store in [r12+8], not using the updated r1 above.
