On 10/28/2011 12:07 AM, Richard Henderson wrote:
This exposed a wealth of problems in code that has heretofore never
been tested. The fourth patch makes certain that all expansions of
compare-and-swap go through a single routine.
I've tested the whole series with and without the last patch. So
On 10/28/2011 04:06 AM, Jakub Jelinek wrote:
> It just wants a guarantee that the builtin will actually be implemented
> in hw. I guess if __sync_fetch_op (new/old) isn't supported but
> __sync_compare_and_swap_* is, we could just use the former and let
> optabs.c deal with that. But we have to h
On Thu, Oct 27, 2011 at 09:07:29PM -0700, Richard Henderson wrote:
> Jakub, in the seventh patch, is there any good reason why OMP is
> making the decision of whether or not to generate a compare-and-swap
> loop? Why shouldn't we simply always generate the __sync_fetch_op
> builtin and let optabs.
This exposed a wealth of problems in code that has heretofore never
been tested. The fourth patch makes certain that all expansions of
compare-and-swap go through a single routine.
I've tested the whole series with and without the last patch. So
that I've tested both the sync_ and atomic_ paths.
