[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Peter Bergner --- Fixed.
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 --- Comment #8 from Peter Bergner --- Author: bergner Date: Tue Nov 13 22:14:11 2018 New Revision: 266086 URL: https://gcc.gnu.org/viewcvs?rev=266086=gcc=rev Log: gcc/ PR rtl-optimization/87899 * lra-lives.c (start_living): Update white space in comment. (enum point_type): New. (sparseset_contains_pseudos_p): New function. (update_pseudo_point): Likewise. (make_hard_regno_live): Use HARD_REGISTER_NUM_P macro. (make_hard_regno_dead): Likewise. Remove ignore_reg_for_conflicts handling. Move early exit after adding conflicts. (mark_pseudo_live): Use HARD_REGISTER_NUM_P macro. Add early exit if regno is already live. Remove all handling of program points. (mark_pseudo_dead): Use HARD_REGISTER_NUM_P macro. Add early exit after adding conflicts. Remove all handling of program points and ignore_reg_for_conflicts. (mark_regno_live): Use HARD_REGISTER_NUM_P macro. Remove return value and do not guard call to mark_pseudo_live. (mark_regno_dead): Use HARD_REGISTER_NUM_P macro. Remove return value and do not guard call to mark_pseudo_dead. (check_pseudos_live_through_calls): Use HARD_REGISTER_NUM_P macro. (process_bb_lives): Use HARD_REGISTER_NUM_P and HARD_REGISTER_P macros. Use new function update_pseudo_point. Handle register copies by removing the source register from the live set. Handle INOUT operands. Update to the next program point using the unused_set, dead_set and start_dying sets. (lra_create_live_ranges_1): Use HARD_REGISTER_NUM_P macro. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-lives.c
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 Peter Bergner changed: What|Removed |Added URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc- |patches/2018-11/msg00890.ht |patches/2018-11/msg01118.ht |ml |ml --- Comment #7 from Peter Bergner --- Submitted updated patch that fixes the errors mentioned above.
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-11/msg00890.ht ||ml Last reconfirmed||2018-11-12 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 --- Comment #6 from Renlin Li --- Created attachment 44975 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44975=edit IRA dump
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 --- Comment #5 from Renlin Li --- Created attachment 44974 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44974=edit IRA dump The code you want to check is the following in ira pass: insn 10905: r1 = r2040 insn 208: use and update r1 with pre_modify insn 191: use pseudo r2040
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added CC||prathamesh3492 at gcc dot gnu.org --- Comment #4 from prathamesh3492 at gcc dot gnu.org --- *** Bug 87920 has been marked as a duplicate of this bug. ***
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 --- Comment #3 from Renlin Li --- (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 , > control_dependences*, int*, bool*)+90>: strbr7, [r2, #0] >0x61a348 , > control_dependences*, int*, bool*)+92>: str.w r7, [r8] > 1=>0x61a34c , > control_dependences*, int*, bool*)+96>: str.w r7, [r1, #12]! >0x61a350 , > control_dependences*, int*, bool*)+100>: mov r5, r1 > 2=>0x61a352 , > control_dependences*, int*, bool*)+102>: str r4, [r1, #8] >0x61a354 , > control_dependences*, int*, bool*)+104>: str r0, [r4, #0] >0x61a356 , > 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 0x0061a74a <+30>:movwr2, #57316 ; 0xdfe4 0x0061a74e <+34>:movtr2, #259; 0x103 0x0061a752 <+38>:str r2, [sp, #28] 0x0061a754 <+40>:mov r4, r0 0x0061a756 <+42>:movwr0, #389; 0x185 0x0061a75a <+46>:str r7, [r4, #8] 0x0061a75c <+48>:str r7, [r4, #12] 0x0061a75e <+50>:strdr7, r7, [r4, #16] 0x0061a762 <+54>:strhr7, [r4, #28] 0x0061a764 <+56>:bl 0xc2bc50 0x0061a768 <+60>:movwr3, #8452 ; 0x2104 0x0061a76c <+64>:movtr3, #242; 0xf2 0x0061a770 <+68>:lslsr2, 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 ::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>:strbr7, [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.
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 --- Comment #2 from Renlin Li --- Created attachment 44965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44965=edit disassembly of distribute_loop disassembly of wrongly compiled distribute_loop function
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 --- Comment #1 from Renlin Li --- 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 , control_dependences*, int*, bool*)+90>: strbr7, [r2, #0] 0x61a348 , control_dependences*, int*, bool*)+92>: str.w r7, [r8] 1=>0x61a34c , control_dependences*, int*, bool*)+96>: str.w r7, [r1, #12]! 0x61a350 , control_dependences*, int*, bool*)+100>: mov r5, r1 2=>0x61a352 , control_dependences*, int*, bool*)+102>: str r4, [r1, #8] 0x61a354 , control_dependences*, int*, bool*)+104>: str r0, [r4, #0] 0x61a356 , 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.
[Bug middle-end/87899] [9 regression]r264897 cause mis-compiled native arm-linux-gnueabihf toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87899 Richard Biener changed: What|Removed |Added Version|8.0 |9.0 Target Milestone|--- |9.0
