| Message ID | abafc4d8-a2d1-89ad-dffc-3700b7ee576a@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [committed] Remove bogus gcc_assert in mn103 backend | expand |
diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 949061a369e..4fc01e9f9dd 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2018-11-16 Jeff Law <law@redhat.com> + + * config/mn10300/mn10300.md (adddi3_degenerate): Remove bogus + gcc_assert. + 2018-11-16 Sandra Loosemore <sandra@codesourcery.com> PR middle-end/23197 diff --git a/gcc/config/mn10300/mn10300.md b/gcc/config/mn10300/mn10300.md index 9350a502c68..c01d3d085df 100644 --- a/gcc/config/mn10300/mn10300.md +++ b/gcc/config/mn10300/mn10300.md @@ -753,7 +753,6 @@ rtx scratch = NULL_RTX; if (!rtx_equal_p (operands[0], operands[2])) { - gcc_assert (!reg_overlap_mentioned_p (operands[0], operands[1])); if (reg_overlap_mentioned_p (operands[0], operands[3]) || reg_overlap_mentioned_p (operands[0], operands[4])) {
The mn103 adddi3_degenerate pattern looks something like this: (define_insn_and_split "*adddi3_degenerate" [(set (match_operand:SI 0 "register_operand" "=&r,&r") (match_operand:SI 2 "nonmemory_operand" " 0, 0")) (set (match_operand:SI 1 "register_operand" "=r , r") (plus:SI (match_operand:SI 3 "register_operand" "%1 , r") (match_operand:SI 4 "nonmemory_operand" "ri, r"))) (clobber (reg:CC CC_REG))] [ ... ] It has gcc_assert (!reg_overlap_mentioned_p (operands[0], operands[1])) out of an abundance of caution I suppose. The problem is we can be called with operands[0]: (subreg:SI (reg:DI X) 0)) operands[1]: (subreg:SI (reg:DI X) 4)) reg_overlap_mentioned_p has this comment: > /* Nonzero if modifying X will affect IN. If X is a register or a SUBREG, > we check if any register number in X conflicts with the relevant register > numbers. Of course in this case the writes will not stomp on each other and are safe. I wandered around rtlanal.c but never found anything which would match the test we really want here. I could just weaken the assert for subregs, possibly using read_modify_subreg_p, but it just doesn't seem worth the effort to save this assert. Removing the assert fixes a few dozen testsuite failures and does not introduce any regressions on the mn103 target. Installing on the trunk. Jeff