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
