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]

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


On 05/28/2017 06:31 AM, Segher Boessenkool wrote:
> __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.
Hmmm.  I wonder if we have similar problems elsewhere.  For example
expand_builtin_int_roundingfn_2, stack_protect_epilogue,
expand_builtin_trap (though this one probably isn't broken in practice),
expand_ifn_atomic_compare_exchange_into_call.

OK, but please check the other instances where we call expand_call, then
continue generating code afterwards.  Fixing those can be a follow-up patch.

Sorry for the delay.

Jeff


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