Ulrich Drepper wrote:
> Has the gcc patch been committed?
Yes, it has been committed as revision 181825 on gcc trunk.
Regards,
kaz
On Tue, Nov 29, 2011 at 17:44, Kaz Kojima wrote:
> Uli, could you please approve the libc patch?
Has the gcc patch been committed?
Richard Henderson wrote:
> It does raise the question of whether it's worth while to move these
> sequences inline in the compiler? We'd need to keep the symbols from
> linux-atomic.S of course, but there's no reason we couldn't satisfy them with
> now-trivial C code.
The same question was ra
"Joseph S. Myers" wrote:
> This asm doesn't tell the compiler that r15 is temporarily saved and
> restored, and marking it as clobbering the stack pointer is unlikely to
> work. It might be possible to avoid problems by marking all the inputs
> that are used while the stack pointer has its spe
On 11/29/2011 09:10 AM, Joseph S. Myers wrote:
> So in my
> view the best fix is to add a new constraint that means "any
> general-purpose register other than r15" and to use it in glibc when the
> compiler version is new enough. That is what these GCC and glibc patches
> do. Comments? OK?
I've observed failures on SH of the glibc test csu/tst-atomic where the
problem is that
#define __arch_compare_and_exchange_val_32_acq(mem, newval, oldval) \
({ __typeof (*(mem)) __result; \
__asm __volatile ("\
.align 2\n\
mova 1f,r0\n\
nop\n\
mov r15,r1\n\
