[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277

Kazumoto Kojima <kkojima at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[5] [SH]: error: insn does  |[5/6 Regression] [SH]:
                   |not satisfy its constraints |error: insn does not
                   |when compiling erlang       |satisfy its constraints
                   |                            |when compiling erlang

--- Comment #2 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Here is a workaround.  It changes the total text size of CSiBE
from 3310543 to 3310579 which looks simply noise.

diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md
index 557a0f0..ad39a3c 100644
--- a/gcc/config/sh/sh.md
+++ b/gcc/config/sh/sh.md
@@ -2236,6 +2236,23 @@
 }
   [(set_attr "type" "arith")])

+;; Old reload might generate add insns directly for the memory address
+;; of complex insns like synchronization insns when reloading.
+(define_insn_and_split "*addsi3"
+  [(set (match_operand:SI 0 "arith_reg_dest" "=r")
+       (plus:SI (match_operand:SI 1 "arith_reg_operand" "r")
+                (match_operand:SI 2 "const_int_operand" "I08")))]
+  "TARGET_SH1 && !sh_lra_p ()
+   && reload_completed
+   && !reg_overlap_mentioned_p (operands[0], operands[1])"
+  "#"
+  "&& reload_completed"
+  [(set (match_dup 0) (match_dup 1))
+   (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))]
+{
+}
+  [(set_attr "type" "arith")])
+
 (define_insn_and_split "*addsi3"
   [(set (match_operand:SI 0 "arith_reg_dest" "=r,r")
        (plus:SI (match_operand:SI 1 "arith_reg_operand" "%0,r")

though I'm not sure that it's ok to add that hack to fix this corner
case.  There are two "new" failures with gcc testsuite:

FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -Os  (internal compiler error)
FAIL: gcc.dg/atomic/c11-atomic-exec-4.c   -Os  (test for excess errors)

which is not really new because these errors have popped up randomly
in our testresults.  After all, unfortunately, some SH synchronization
insns are too complex for the old reload.  You can avoid this PR and
c11-atomic-exec-4.c ICE with -mlra.
Oleg, do you have any ideas?