-
- Downloads
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.
Loading
Please register or sign in to comment