Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

[David Edelsohn <dje.gcc@gmail.com>]

On Wed, Jun 3, 2020 at 9:41 AM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Richard Biener <richard.guenther@gmail.com> writes:
> > On Tue, Jun 2, 2020 at 5:00 PM Martin Liška <mliska@suse.cz> wrote:
> >>
> >> On 6/2/20 1:09 PM, Richard Biener wrote:
> >> > So please be constructive.  Like, provide a testcase that ICEs
> >> > with the FAILs replaced by gcc_unreachable ().  Martin, may I suggest
> >> > to do this replacement and bootstrap/test?  I think it would be nice
> >> > to have testsuite coverage for the FAILs, and maybe we have that
> >> > already.
> >>
> >> Hello.
> >>
> >> There's the suggested patch that survives bootstrap on ppc64le-linux-gnu
> >> and passes test-suite.
> >
> > OK, so can you please re-post the version of the VEC_COND_EXPR
> > patch that uses a regular IFN (without the static non-FAIL checking)
> > in a new thread?  If there's no OK from rs6000 maintainers to remove
> > the FAILs then we'll go ahead with that version, unless Richard objects
> > here.
>
> Well, it seems unfortunate to have to do that.
>
> I think Martin's powerpc patch is the correct one.  But assuming that
> the powerpc maintainers still object, I guess the options are:
>
> - Find enough global reviewers who are prepared to approve that patch,
>   to override the powerpc maintainers.

Luckily GCC Development does not operate this way.

How about (3) help to remove reliance on this incorrect behavior from
the PowerPC port?

I didn't formally check, but if this is 16 years old, then it's from
the original RHES Altivec work.

I don't believe that anyone fundamentally is objecting to "fixing this
correctly".  I don't know the entire history of this discussion, but
my objection is to a fix that breaks a long-time assumption of the
PowerPC port and leaves it as an exercise to the PowerPC maintainers
to fix it.

Thanks, David