sp_counted_base_gcc_sparc.hpp compile failure on gcc.4.2.3 w/-O2

[jon_p_griffiths@…]

compare_and_swap() from sp_counted_base_gcc_sparc.hpp fails to compile here with gcc 4.2.3 configured thusly:

-bash-3.00$ /opt/gcc-4.2.3/bin/g++ -v Using built-in specs. Target: sparc64-sun-solaris2.10 Configured with: ../src/configure --host=sparc64-sun-solaris2.10 --with-gnu-as --with-as=/opt/binutils-2.17/bin/as --with-gnu-ld --with-ld=/opt/binutils-2.17/bin/ld --with-pic --enable-languages=c,c++ --prefix=/opt/gcc-4.2.3 Thread model: posix gcc version 4.2.3

The problem is the "=m" asm constraint in this function, which allows memory references of any form. When compiling with optimisation, gcc avoids some address math and ends up emitting <reg>+<offset> for the first operand in its inlined call. 'as' then refuses to assemble this ('Illegal Operands'). If the function is not inlined, the dest_ parameter has the offset added to it before being passed to the function and it then compiles quite happily. Unfortunately, gcc does not have an asm constraint to specify that offsets should not be used in memory references.

I'm working around this locally by making the function static and attribute(noinline), which works with a small code size cost. An alternate fix would be to load the memory address from another register in the asm expression, but that's beyond my gcc asm-fu.

Alternately, this may be considered a bug in the compiler - but adding the missing constraint is more likely to be considered a feature request IMO, hence the bug report here first.

[Peter Dimov]

According to

​http://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html

the proper constraint could be 'V' instead of 'm'.

[jon_p_griffiths@…]

the proper constraint could be 'V' instead of 'm'.

I tried +V before reporting but it also failed (with 'inconsistent asm contraints' IIRC). I found two sparc CAS implementations by googling (GASNet and the Linux kernel) - both use the following formulation:

__asm__ __volatile("cas [%2], %3, %0\n\t"
    : "=&r" (swap_)
    : "0" (swap_), "r" (dest_), "r" (compare_)
    : "memory");

This forces the address to be stored in a register, which avoids any offset addition in the emitted instruction. However, the Linux kernel implementation adds memory barriers before and after the CAS; it would be interesting to know whether they are really needed in this case.

For reference, I've tested the following version; it seems to be running without issues here:

inline int32_t compare_and_swap( volatile int32_t * dest_, int32_t compare_, int32_t swap_ )
{
    __asm__ __volatile__("membar #StoreLoad|#LoadLoad\n"
                         "cas [%2], %3, %0\n"
                         "membar #StoreLoad|#StoreStore\n"
                         : "=&r" (swap_)
                         : "0" (swap_), "r" (dest_), "r" (compare_)
                         : "memory");
    return swap_;
}

Cheers, Jon

[Peter Dimov]

(In [57949]) Fix SPARC asm operand failure. Refs #3678. Refs #3341.

[Peter Dimov]

(In [58063]) Merge [57949] to release. Fixes #3678. Fixes #3341.