openjdk team mailing list archive

[John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>]

Hi Andrew!

On 08/01/2017 02:57 PM, Andrew Haley wrote:
> The second one is more subtle.  Zero is so called because it uses zero
> assembly language, but this is not quite true: there is a tiny bit of
> assembly language, and it is wrong.  Here is the PPC32 definition of
> atomic_copy64.  It uses a floating-point register to copy a 64-bit
> doubleword atomically:
> 
>   // Atomically copy 64 bits of data
>   static void atomic_copy64(volatile void *src, volatile void *dst) {
> #if defined(PPC32) && !defined(__NO_FPRS__)
>     double tmp;
>     asm volatile ("lfd  %0, 0(%1)\n"
>                   "stfd %0, 0(%2)\n"
>                   : "=f"(tmp)
>                   : "b"(src), "b"(dst));
> 
> The eagle-eyed among you might have noticed the bug: this asm has no
> memory effect.  It has no memory inputs, no memory outputs, and no
> memory clobber.  So, as far as GCC is concerned atomic_copy64 does not
> touch memory at all, and there is no need to store the source operand
> into memory.  For all GCC knows, the asm might just be doing some
> arithmetic on the pointers.  We need a better definition of
> atomic_copy64, and this is mine:
> 
>   // Atomically copy 64 bits of data
> static void atomic_copy64(volatile void *src, volatile void *dst) {
> #if defined(PPC32) && !defined(__NO_FPRS__)
>     double tmp;
>     asm volatile ("lfd  %0, %2\n"
>                   "stfd %0, %1\n"
>                   : "=&f"(tmp), "=Q"(*(volatile double*)dst)
>                   : "Q"(*(volatile double*)src));
> 
> Note that we dereference src and dst and pass the actual memory
> operands to the asm, not just pointers to them.
This patch fixes the build for me. Could you get it merged upstream?

I assume it will go into the jdk10 branch because jdk9 isn't taking
any particular fixes at the moment. Am I correct?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@xxxxxxxxxx
`. `'   Freie Universitaet Berlin - glaubitz@xxxxxxxxxxxxxxxxxxx
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913