This is a recent regression introduced with the following patch, but I think that it's just uncovered a latent GCSE bug: 2004-11-03 Ulrich Weigand <uweigand@de.ibm.com> * tree-ssa-loop-ivopts.c (get_address_cost): Offset zero does not cause extra costs. Generate canonical RTL. With the patch applied, we get the following RTL at the start of BB 25 before GCSE starts to run: (code_label 236 234 237 25 38 "" [1 uses]) (note 237 236 239 25 [bb 25] NOTE_INSN_BASIC_BLOCK) (insn 239 237 240 25 (set (reg/f:SI 154 [ D.28277 ]) (const:SI (plus:SI (symbol_ref:SI ("^all_cores") <var_decl 0x4062d740 all_cores>) (const_int 20 [0x14])))) 143 {*arm_movsi_insn} (nil) (nil)) (insn 240 239 241 25 (set (reg/v/f:SI 172 [ sel ]) (plus:SI (reg:SI 156 [ ivtmp.895 ]) (reg/f:SI 154 [ D.28277 ]))) 4 {*arm_addsi3} (nil) (nil)) (insn 241 240 243 25 (set (reg/f:SI 155 [ D.28275 ]) (reg/f:SI 154 [ D.28277 ])) 143 {*arm_movsi_insn} (nil) (expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI ("^all_cores") <var_decl 0x4062d740 all_cores>) (const_int 20 [0x14]))) (nil))) GCSE converts this to (code_label 236 234 237 26 38 "" [1 uses]) (note 237 236 1578 26 [bb 26] NOTE_INSN_BASIC_BLOCK) (insn 1578 237 240 26 (set (reg/f:SI 154 [ D.28277 ]) (const:SI (plus:SI (symbol_ref:SI ("^all_cores") <var_decl 0x4062d740 all_cores>) (const_int 20 [0x14])))) 143 {*arm_movsi_insn} (nil) (expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI ("^all_cores") <var_decl 0x4062d740 all_cores>) (const_int 20 [0x14]))) (nil))) (insn 240 1578 241 26 (set (reg/v/f:SI 172 [ sel ]) (plus:SI (reg:SI 156 [ ivtmp.895 ]) (reg/f:SI 677 [ D.28277 ]))) 4 {*arm_addsi3} (nil) (expr_list:REG_EQUAL (plus:SI (reg:SI 156 [ ivtmp.895 ]) (const:SI (plus:SI (symbol_ref:SI ("^all_cores") <var_decl 0x4062d740 all_cores>) (const_int 20 [0x14])))) (nil))) (insn 241 240 1666 26 (set (reg/f:SI 677 [ D.28277 ]) (reg/f:SI 154 [ D.28277 ])) 143 {*arm_movsi_insn} (nil) (expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI ("^all_cores") <var_decl 0x4062d740 all_cores>) (const_int 20 [0x14]))) (nil))) But note that now the second real insn uses pseudo 677 which isn't set until the following instruction. This use before-set causes the register to be marked live at the start of the BB. However, we ultimately end up deleting insn 240 entirely and this results in an abort when we update the register life information.
Created attachment 7504 [details] Testcase
Subject: Re: [4.0.0 Regression] Bootstrap failure on all ARM targets due to incorrect GCSE On Tue, 2004-11-09 at 15:09, rearnsha at gcc dot gnu dot org wrote: > ------- Additional Comments From rearnsha at gcc dot gnu dot org 2004-11-09 15:09 ------- > Created an attachment (id=7504) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7504&action=view) > Testcase Just a note that the bug can be triggered with the filed testcase on an arm-elf cross using flags '-O2'.
I cannot reproduce it with today's mainline, is this fixed or latent again?
Subject: Re: [4.0.0 Regression] Bootstrap failure on all ARM targets due to incorrect GCSE On Sun, 2004-12-12 at 22:10, pinskia at gcc dot gnu dot org wrote: > ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-12 22:10 ------- > I cannot reproduce it with today's mainline, is this fixed or latent again? Don't know. It seemed to disappear again fairly quickly, but I never saw any patch proposed that might have directly addressed the issue.
If only we had unit testing... Richard, you think you can figure out when this problem *disappeared*? Maybe it was one of the many bitmaps changes, and there really is no GCSE bug. If there is a real GCSE bug, I would think we'd have found it much earlier. But if some unrelated patch fixed the bug, I'll build a 2004-11-03 i686-x-arm compiler and see if I can figure out what is going on...
It went away after this patch: 2004-11-10 Zdenek Dvorak <dvorakz@suse.cz> * tree-ssa-loop-ivopts.c (get_address_cost): Add address elements in right order. (force_var_cost): Determine cost of addition and multiplication more precisely. (get_computation_cost_at): Add cost for computing address elements to the final cost. * fold-const.c (fold): Attempt to use ptr_difference_const whenever one of the arguments of MINUS_EXPR is an address. (split_address_to_core_and_offset): New function. (ptr_difference_const): Handle case when one of the operands is a pointer. * tree-ssa-loop-ivopts.c (determine_base_object): Fold &*addr. (ptr_difference_cost): Pass addresses instead of objects to ptr_difference_const. So I suspect it might have gone latent again, but it might be that it was fixed by the canonicalization change to get_address_cost and that the problem can only occur with RTL that is not in correct canonical form. For reference here are the links to the two patch proposals: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00610.html http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00715.html
Lets remove the regression marker for now and confirm it as it is latent but not reproducible.
If it is "latent but not reproducible" it shouldn't be a P1. Downgrading.
Not seen this again in a long time, so closing as works for me.