On Tue, Mar 2, 2021 at 8:48 AM Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> Alexandre Oliva <ol...@adacore.com> writes:
> > On Feb 26, 2021, Segher Boessenkool <seg...@kernel.crashing.org> wrote:
> >
> >> On Fri, Feb 26, 2021 at 12:31:16PM -0500, David Edelsohn wrote:
> >>> On Fri, Feb 26, 2021 at 11:09 AM Alexandre Oliva <ol...@adacore.com> 
> >>> wrote:
> >>> >
> >>> > This patch avoids an ICE in gimplefe-28.c, in our ppc64-vxworks7r2
> >>> > tests.  Tested on x86_64-linux-gnu, and on the affected platform.  Ok to
> >>> > install?
> >>>
> >>> I'm sort of surprised that sqrt instruction would be available for the
> >>> target but not enabled by default.  Is this really the method that
> >>> customers would use?  It seems that it might be more appropriate to
> >>> xfail or skip the test for PPC64 VxWorks.
> >
> >> You should essentially never use -mpowerpc-gpopt, but instead use a
> >> -mcpu= that has it.  You also of course whould not do that in run tests
> >> if the cpu does not support those insns.
> >
> > I think the feedback is missing the point of the obvious bug that Eric's
> > patch fixes.
> >
> > We have a dejagnu proc that should return any target-specific options
> > necessary for a sqrt insn to be available:
> >
> > # Return any additional options to enable square root intructions.
>
> Agreed FWIW.  The intention of dg-add-options was to try to increase
> test coverage by supporting pairs of procs, one to answer “can I enable
> this feature?” and another to say “this is how to enable the feature”.
> The question isn't whether sqrt is already enabled, but whether it can be.
>
> Both proposed fixes are correct, in that they make the pairs of procs
> consistent.  Changing add_options_for_sqrt_insn is more in the spirit
> of how this was supposed to work though.

The procs are used in more than that one test.  Maybe that one test
was intended as a pair, but the use of the procs is more general than
"does the target support sqrt instruction and the complementary
options to enable the instruction".

Thanks, David

Reply via email to