On Tue, Apr 30, 2019 at 11:04:10AM -0500, Kelvin Nilsen wrote:
> 
> In combination with a related recently committed patch 
> (https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00989.html), the attached 
> patch resolves the issues described in this problem report.  This patch also 
> includes tests to exercise the previously committed patch.
> 
> This patch includes redundant content from patch PR89424 
> (https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00994.html), which has been 
> already been approved by Segher for trunk and backports to GCC 7 and 8 but is 
> awaiting GCC 9 release.
> 
> The patch has been bootstrapped and tested without regressions on 
> powerpc64le-unknown-linux-gnu (both P8 and P9) and on 
> powerpc64-unknown-linux-gnu (P7 and P8, both -m32 and -m64).
> 
> Segher: After GCC9 release, is this ok for trunk and backports to GCC 7 and 
> GCC8?
> 
> Jakub or Richi: Is this patch and the redundant PR89424 patch ok for 
> backports to GCC9?

I'm not against backporting it for GCC 9.2, but would strongly prefer not to
backport before GCC 9.1 is released.  At least from what I've seen, you get
many wrong-code issues with the V1TImode on powerpc since many years ago,
so I don't see why it couldn't wait another week.

The only changes to GCC 9.1 now should be severe blockers.

> 2019-04-30  Kelvin Nilsen  <kel...@gcc.gnu.org>
> 
>       PR target/89765
>       * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
>       In handling of ALTIVEC_BUILTIN_VEC_INSERT, use modular arithmetic
>       to compute vector element selector for both constant and variable
>       operands.
>       * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add case
>       to handle V1TImode vectors.

        Jakub

Reply via email to