Fix OMP CAS expansion with separate condition
authorRichard Biener <rguenther@suse.de>
Fri, 13 May 2022 10:07:58 +0000 (12:07 +0200)
committerRichard Biener <rguenther@suse.de>
Thu, 19 May 2022 14:25:55 +0000 (16:25 +0200)
commit060173dd73fcaf0767215f9d989ad064e2d5fe2a
tree6aa51bd15b5f5e04d5f7c65ac65499119665799b
parent4fc78e18b5be495aa71b9f87b0677e06a35b93a4
Fix OMP CAS expansion with separate condition

When forcing the condition to be split out from COND_EXPRs I see
a runtime failure of libgomp.fortran/atomic-19.f90 which can be
reduced to

  !$omp atomic update, compare, capture
  if (x == 69_2 - r) x = 6_8
    v = x

being miscompiled, the difference being

-  _13 = .ATOMIC_COMPARE_EXCHANGE (_9, _10, _11, 4, 0, 0);
-  _14 = IMAGPART_EXPR <_13>;
-  _15 = REALPART_EXPR <_13>;
-  _16 = _14 != 0 ? _11 : _15;
-  _2 = (integer(kind=4)) _16;
-  v_17 = _2;
+  _14 = .ATOMIC_COMPARE_EXCHANGE (_10, _11, _12, 4, 0, 0);
+  _15 = IMAGPART_EXPR <_14>;
+  _16 = REALPART_EXPR <_14>;
+  _2 = (logical(kind=1)) _15;
+  _3 = (integer(kind=4)) _16;
+  v_17 = _3;

where one can see a missing COND_EXPR.  It seems to be a latent
issue to me given the code can be exercised, it just maybe misses
a 'need_new' testcase combined with 'cond_stmt'.  Appearantly
the if (cond_stmt) code is just to avoid creating a temporary
(and possibly to preserve the condition compute if used elsewhere
since the original stmt is going to be deleted).  The following
makes the failure go away for me in my patched tree and it
also survives libgomp and gomp testing in an unpatched tree.

2022-05-13  Richard Biener  <rguenther@suse.de>

* omp-expand.cc (expand_omp_atomic_cas): Do not short-cut
computation of the new value.
gcc/omp-expand.cc