cris: Correct gcc_assert for atomic_fetch_op pattern

Message ID 202007060040.0660elsX031741@ignucius.se.axis.com
State New
Headers show
Series
  • cris: Correct gcc_assert for atomic_fetch_op pattern
Related show

Commit Message

Jason Merrill via Gcc-patches July 6, 2020, 12:40 a.m.
Yet another misnumbering of operands: the asserted non-overlap
would be the only benign operands overlap.  "Suddenly" exposed
by g++.dg/cpp0x/pr81325.C when testing unrelated changes
affecting register allocation.

To wit, operands 2 and 1 are the only ones that are safe for
overlap, it's only that it doesn't seem to make much sense to
write the address of the atomic data as the atomic data.

gcc:
	* config/cris/sync.md ("cris_atomic_fetch_<atomic_op_name><mode>_1"):
	Correct gcc_assert of overlapping operands.
---
 gcc/config/cris/sync.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
2.11.0

Patch

diff --git a/gcc/config/cris/sync.md b/gcc/config/cris/sync.md
index 30b5ea075af..70640dbd55b 100644
--- a/gcc/config/cris/sync.md
+++ b/gcc/config/cris/sync.md
@@ -128,7 +128,11 @@  (define_insn "cris_atomic_fetch_<atomic_op_name><mode>_1"
   "<MODE>mode == QImode || !TARGET_ATOMICS_MAY_CALL_LIBFUNCS"
 {
   /* Can't be too sure; better ICE if this happens.  */
-  gcc_assert (!reg_overlap_mentioned_p (operands[2], operands[1]));
+  gcc_assert (!reg_overlap_mentioned_p (operands[0], operands[1])
+	      && !reg_overlap_mentioned_p (operands[0], operands[2])
+	      && !reg_overlap_mentioned_p (operands[0], operands[3])
+	      && !reg_overlap_mentioned_p (operands[1], operands[3])
+	      && !reg_overlap_mentioned_p (operands[2], operands[3]));
 
   if (cris_cpu_version == 10)
     return