On Thu, 19 May 2022, Jakub Jelinek wrote:
> On Thu, May 19, 2022 at 02:13:33PM +, Richard Biener wrote:
> > > Though, depending on what exactly you allow or disallow, maybe even
> > > the im != 0 might not be acceptable.
> > > Oh, and if COND_EXPRs can only use some limited set of comparisons,
On Thu, May 19, 2022 at 02:13:33PM +, Richard Biener wrote:
> > Though, depending on what exactly you allow or disallow, maybe even
> > the im != 0 might not be acceptable.
> > Oh, and if COND_EXPRs can only use some limited set of comparisons, we might
> > need to adjust e.g. arith_overflow_ch
On Thu, 19 May 2022, Jakub Jelinek wrote:
> On Fri, May 13, 2022 at 12:23:01PM +0200, Richard Biener wrote:
> > 2022-05-13 Richard Biener
> >
> > * omp-expand.cc (expand_omp_atomic_cas): Do not short-cut
> > computation of the new value.
>
> Ok, thanks.
>
> Though, depending on what
On Fri, May 13, 2022 at 12:23:01PM +0200, Richard Biener wrote:
> 2022-05-13 Richard Biener
>
> * omp-expand.cc (expand_omp_atomic_cas): Do not short-cut
> computation of the new value.
Ok, thanks.
Though, depending on what exactly you allow or disallow, maybe even
the im != 0 mig
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
