On Sat, 2020-02-22 at 18:15 -0600, Segher Boessenkool wrote:
> On Mon, Feb 17, 2020 at 02:48:20PM -0600, will schmidt wrote:
> > On Thu, 2020-02-13 at 17:23 -0600, Segher Boessenkool wrote:
> > > On Thu, Feb 13, 2020 at 04:41:09PM -0600, will schmidt wrote:
> > > > -/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14
> > > > "vect" }
> > > > } */
> > > > +/* { dg-final { scan-tree-dump-times "LOOP VECTORIZED" 14
> > > > "vect" {
> > > > target p8vector_hw } } } */
> > >
> > > That actually checks if the hardware is p8 or later, while what
> > > you
> > > care
> > > about is what options are compiled with. Say, if running on a p8
> > > but
> > > compiling for a p7 this will fail?
> >
> > Right...
> >
> > I did some experimentation and havn't come up with anything I'm
> > completely satisfied with. The powerpc_p8vector_ok check doesn't
> > fail out like I'd expect it to on a power7 target.
>
> What we usually do is duplicate the test, run one for p7, and the
> other
> for p8. This isn't nice at all.
>
> > Ok, so it appears check_effective_target_powerpc_p8vector_ok ()
> > inserts
> > a "-mpower8-vector" option as part of it's test, so as long as the
> > compiler on a power7 system is able to generate power8 code, that
> > power8-vector check will pass, even if we have not otherwise
> > indicated
> > power8 in our test incantation.
>
> Yes, that is what the *_ok mean: whether we can compile code for that
> target. This isn't usually useful at all.
>
> > I'll think on this one some more...
>
> If the test can be disabled at the source code level, there are
> _ARCH_PWR8
> and friends. Maybe we want some dejagnu effective targets that just
> test
> some of those defines?
Yup, I've sorted out some changes that work. It's now more of a
target-supports.exp change, versus just touching this testcase, so I'm
posting in a separate thread, momentarily.
Thanks
-Will
>
>
> Segher
