On Mon, Sep 13, 2021 at 4:40 PM Jakub Jelinek <ja...@redhat.com> wrote:

> On Mon, Sep 13, 2021 at 01:57:52PM +0200, Christophe Lyon wrote:
> > > --- gcc/testsuite/c-c++-common/gomp/atomic-29.c.jj      2021-09-10
> > > 11:47:17.093164041 +0200
> > > +++ gcc/testsuite/c-c++-common/gomp/atomic-29.c 2021-09-10
> > > 11:52:33.428722747 +0200
> > > @@ -0,0 +1,43 @@
> > > +/* { dg-do compile { target c } } */
> > > +/* { dg-additional-options "-O2 -fdump-tree-ompexp" } */
> > > +/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE
> > > \\\(\[^\n\r]*, 8, 5, 5\\\);" 1 "ompexp" { target sync_int_long } } } */
> > > +/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE
> > > \\\(\[^\n\r]*, 8, 4, 2\\\);" 1 "ompexp" { target sync_int_long } } } */
> > > +/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE
> > > \\\(\[^\n\r]*, 264, 5, 0\\\);" 1 "ompexp" { target sync_int_long } } }
> */
> > > +/* { dg-final { scan-tree-dump-times "\.ATOMIC_COMPARE_EXCHANGE
> > > \\\(\[^\n\r]*, 8, 0, 0\\\);" 1 "ompexp" { target sync_int_long } } } */
> > > +/* { dg-final { scan-tree-dump-not "__atomic_load_8 \\\(" "ompexp" {
> > > target sync_int_long } } } */
> > > +
> > >
> >
> > This test fails on arm*linux when forcing old CPU/ARCH (eg
> -march=armv5t).
> > Not sure how easy it is to fix?
> > sync_int_long returns true for arm*-*-linux-*,
> > but for other arm targets, it depends on the result
> > of check_effective_target_arm_acq_rel.
> >
> > Is it just a matter of removing arm*-*-linux-* from sync_int_long and
> > always rely on arm_acq_rel?
>
> So, atomic-28.c passes and just atomic-29.c fails?
>
Yes.


> atomic-29.c tests for double atomics aka 64-bit, so probably I should use
> sync_long_long effective target instead of sync_int_long.
> But, it is unclear how would that help for arm because sync_long_long is
> enabled for all arm targets...
>
Indeed :-(


> There is also sync_long_long_runtime effective target, but this is a
> compile
> test, so it would be weird to rely on that when it ought to test the
> runtime
> behavior of that.
>
Agreed



>
>         Jakub
>
>

Reply via email to