On Fri, 2018-07-27 at 17:43 +0100, Andre Vieira (lists) wrote:
> On 27/07/18 16:39, David Malcolm wrote:
> > On Thu, 2018-07-26 at 13:22 +0100, Andre Vieira (lists) wrote:
> > 
> > [...snip...]
> > 
> > > > > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > > > > b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > > > > new file mode 100644
> > > > > index 0000000..2fe2f70
> > > > > --- /dev/null
> > > > > +++ b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > > > > @@ -0,0 +1,8 @@
> > > > > +/* { dg-options "-fsave-optimization-record -ftree-loop-
> > > > > vectorize -ftree-parallelize-loops=2" } */
> > > > > +
> > > > > +void
> > > > > +n2 (int ih)
> > > > > +{
> > > > > +  while (ih < 1)
> > > > > +    ++ih;
> > > > > +}
> > > > > --
> > > > > 1.8.5.3
> > > > > 
> > > 
> > > Hi David,
> > > 
> > > I believe the test in this patch needs a "{ dg-require-effective-
> > > target
> > > pthread }" as -ftree-parallelize-loops seems to be turning on
> > > -pthread.
> > > 
> > > Cheers,
> > > Andre
> > 
> > Thanks; indeed I now see that every test case using
> >   -ftree-parallelize-loops
> > has such a directive.
> > 
> > Also, the test is missing a dg-do compile.
> > 
> > Does the following look correct?  (borderline covered by "obvious
> > fix"
> > rule).
> > 
> > Dave
> > 
> > 
> > gcc/testsuite/ChangeLog:
> >     PR tree-optimization/86636
> >     * gcc.c-torture/compile/pr86636.c: Add dg-do compile.
> >     Add dg-require-effective-target pthread.
> > ---
> >  gcc/testsuite/gcc.c-torture/compile/pr86636.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > index 2fe2f70..8527a0f 100644
> > --- a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > +++ b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
> > @@ -1,3 +1,5 @@
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target pthread } */
> >  /* { dg-options "-fsave-optimization-record -ftree-loop-vectorize
> > -ftree-parallelize-loops=2" } */
> >  
> >  void
> > 
> 
> LGTM, but I am not a maintainer. I too would think you might would be
> ok
> with a "obvious fix" here.

Thanks for giving it another pair of eyes; given that, I've committed
it to trunk (r263031) under the "obvious fix" rule.

Dave

Reply via email to