| Message ID | 1cde41880e018e2a31aafa6980ad175081b67206.camel@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [committed] Fix pr20601-1.c on the H8 | expand |
diff --git a/gcc/config/h8300/testcompare.md b/gcc/config/h8300/testcompare.md index 2e4cb5afee7..118db145a8a 100644 --- a/gcc/config/h8300/testcompare.md +++ b/gcc/config/h8300/testcompare.md @@ -9,7 +9,7 @@ (match_operand 1 "const_int_operand" "n,n,n")) (const_int 0))) (clobber (match_scratch:QI 2 "=X,X,&r"))] - "" + "!CONSTANT_P (operands[0])" "@ btst\\t%Z1,%Y0 btst\\t%Z1,%Y0 @@ -82,7 +82,7 @@ (const_int 7))) (const_int 0))) (clobber (match_scratch:QI 2 "=X,X,&r"))] - "" + "!CONSTANT_P (operands[0])" "@ btst\\t%w1,%X0 btst\\t%w1,%X0
This is a codegen fix for the H8 that I debugged while working on the cc0 conversion. In simplest terms we're accepting things like (const_int 0) as the source of a zero_extract and it ultimately interacts badly with register reloading. One might argue this is combine's fault for not simplifying the extraction, but it's really wrong for the pattern to accept something that we simply can't handle correctly, ever. THere isn't a great predicate for this, so we just reject the constants in the condition. Pushed to the trunk, without having to commit a ChangeLog entry! :-) Jeff commit bc48456d085d4ab8be92cf5369624dd86317cecb Author: Jeff Law <law@redhat.com> Date: Tue May 26 22:14:40 2020 -0600 Fix pr20601-1.c on the H8 gcc/ * config/h8300/testcompare.md (tst_extzv_1_n): Do not accept constants for the primary input operand. (tstsi_variable_bit_qi): Similarly.