This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] Fix expand_builtin_atomic_fetch_op for pre-op (PR80902)


__atomic_add_fetch adds a value to some memory, and returns the result.
If there is no direct support for this, expand_builtin_atomic_fetch_op
is asked to implement this as __atomic_fetch_add (which returns the
original value of the mem), followed by the addition.  Now, the
__atomic_add_fetch could have been a tail call, but we shouldn't
perform the __atomic_fetch_add as a tail call: following code would
not be executed, and in fact thrown away because there is a barrier
after tail calls.

This fixes it.

Tested on powerpc64-linux {-m32,-m64}.  Is this okay for trunk?


Segher


2017-05-28  Segher Boessenkool  <segher@kernel.crashing.org>

	PR middle-end/80902
	* builtins.c (expand_builtin_atomic_fetch_op): If emitting code after
	a call, force the call to not be a tail call.

---
 gcc/builtins.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 4f6c9c4..3a70693 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -6079,6 +6079,12 @@ expand_builtin_atomic_fetch_op (machine_mode mode, tree exp, rtx target,
   gcc_assert (TREE_OPERAND (addr, 0) == fndecl);
   TREE_OPERAND (addr, 0) = builtin_decl_explicit (ext_call);
 
+  /* If we will emit code after the call, the call can not be a tail call.
+     If it is emitted as a tail call, a barrier is emitted after it, and
+     then all trailing code is removed.  */
+  if (!ignore)
+    CALL_EXPR_TAILCALL (exp) = 0;
+
   /* Expand the call here so we can emit trailing code.  */
   ret = expand_call (exp, target, ignore);
 
-- 
1.9.3


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]