On Thu, Jun 22, 2017 at 10:59:05PM -0600, Jeff Law wrote: > 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.
> 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. We certainly have similar problems elsewhere. I'm doing tests detecting whenever we create dead code (right after a barrier); it finds a few things, mostly harmless, but there are quite a few places where we create dead code during expand. This will take a while, but it will need to happen during stage 1... I'm trying to fit it in :-/ Segher