Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8201509

Zero: S390 31bit atomic_copy64 inline assembler is wrong

XMLWordPrintable

    • b12
    • other
    • generic

        In os_linux_zero.hpp the inline assembler for the S390x (S390 and not _LP64) has src and dst reversed thereby corrupting data.
         [THX to MBalao and APH for debugging]

        From APH:
         
        %0, %1, and %2 are not register names. They are operand numbers which
        are mapped onto physical registers by GCC. One problem with the
        broken asm is that it does not tell GCC that the memory pointed to by
        src is read or that the memory pointed to by dst is written. Because
        of this, GCC knows that the asm has no memory inputs and no memory
        outputs, thus the state of the memory when the asm is executed does
        not matter. Passing the addresses of src and dst has no effect.
        Another problem with the broken asm is that it uses "=r" (i.e. this
        register is an output) instead of "=&r" (i.e. this register is an
        input and an output).

        We need the early clobber on tmp and we need memory inputs
        and outputs on (*(volatile double*)src).


        (see the GCC Doc, 6.42.4 Constraints for Particular Machines.)

        on S390 it's

             'Q'
                  Memory reference without index register and with short
                  displacement.

        So I guess this

            double tmp;
            asm volatile ("ld %0, %2\n"
                          "std %0, %1\n"
                          : "=&f"(tmp), "=Q"(*(volatile double*)dst)
                          : "Q"(*(volatile double*)src));

        would work.

        https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#OutputOperands

              chrisphi Chris Phillips
              chrisphi Chris Phillips
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: