[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain

[renlin at gcc dot gnu.org]

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.