On Wed, Jun 3, 2020 at 9:41 AM Richard Sandiford <richard.sandif...@arm.com> wrote: > > Richard Biener <richard.guent...@gmail.com> writes: > > On Tue, Jun 2, 2020 at 5:00 PM Martin Liška <mli...@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
