[Bug fortran/34020] New: Bogus codegen for openmp atomics w/ indirects operands on IPF

[brian dot e dot bliss at intel dot com]

The codegen for atomic instructions with indirect/reference operands on
Itanium seems to be bogus:

% cat bar.F
        subroutine atomic_add(lhs, rhs)
        real lhs, rhs
!$omp atomic
        lhs = rhs + lhs
        end

% gfortran -v -fopenmp -O1 -S bar.F
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: /net/gnu-13/export/gnu/src/gcc-4.2/gcc/configure
--enable-cloca
le=gnu --with-system-zlib --with-demangler-in-ld --enable-shared
--enable-thread
s=posix --enable-haifa --enable-checking=assert --prefix=/usr/gcc-4.2
--with-loc
al-prefix=/usr/local
.
.
.

% cat bar.s
        .file   "bar.F"
        .pred.safe_across_calls p1-p5,p16-p63
        .text
        .align 16
        .global atomic_add_#
        .proc atomic_add_#
atomic_add_:
        .prologue
        .body
        ld4 r14 = [r32]
        ldfs f6 = [r33]
        ;;
        setf.s f7 = r14
        ;;
        fadd.s f7 = f7, f6
        ;;
        getf.s r16 = f7
        mov r15 = r14
.L2:
        ;;
        addp4 r14 = r15, r0
        ;;
        mov ar.ccv = r14
        mf
        ;;
        cmpxchg4.rel r14 = [r32], r16, ar.ccv
        ;;
        cmp4.eq p6, p7 = r14, r15
        (p6) br.ret.dpnt.many rp
        mov r15 = r14
        br .L2
        ;;
        .endp atomic_add_#
        .ident  "GCC: (GNU) 4.2.0"

Note that the fp add instruction is not in the retry path, so if the cmpxchg
fails because of contention from another thread, the incorrect result will
be written to the atomic location.

The bug happens in all versions of gfortran 4.2.x and 4.3.0 that I have tried.
It does not happen if lhs is a symbolic constant.
It happens for all data types, not just fp.
It happens for all optimization levels.


-- 
           Summary: Bogus codegen for openmp atomics w/ indirects operands
                    on IPF
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: brian dot e dot bliss at intel dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34020