SGTM
On 14/04/2023 12:00, Jakub Jelinek wrote:
On Fri, Apr 14, 2023 at 11:59:02AM +0100, Andre Vieira (lists) wrote:
On the other thread I commented that inbranch simdclones are failing for
AVX512F because it sets the mask_mode, for which inbranch hasn't been
implemented, and so it is rejected.
On Fri, Apr 14, 2023 at 11:59:02AM +0100, Andre Vieira (lists) wrote:
> On the other thread I commented that inbranch simdclones are failing for
> AVX512F because it sets the mask_mode, for which inbranch hasn't been
> implemented, and so it is rejected.
But then we can as well use -mno-avx512f in
On the other thread I commented that inbranch simdclones are failing for
AVX512F because it sets the mask_mode, for which inbranch hasn't been
implemented, and so it is rejected.
On 14/04/2023 11:25, Jakub Jelinek via Gcc-patches wrote:
On Fri, Apr 14, 2023 at 10:15:06AM +, Richard Biener
On Fri, Apr 14, 2023 at 10:15:06AM +, Richard Biener wrote:
> Oops. Indeed target_avx checks whether it can compile sth with
> -O2 -mavx rather than verifying avx is present. I've seen scan
> failures with -m32/-march=cascadelake on a zen2 host. I'm not exactly
> sure why.
That is strange.
On Fri, 14 Apr 2023, Jakub Jelinek wrote:
> On Fri, Apr 14, 2023 at 11:42:55AM +0200, Richard Biener via Gcc-patches
> wrote:
> > This replaces i686*-*-* && { ! lp64 } with the appropriate
> > { i?86-*-* x86_64-*-* } && { ! lp64 } for the testcases and
> > also amends the e variants checking last
On Fri, Apr 14, 2023 at 11:42:55AM +0200, Richard Biener via Gcc-patches wrote:
> This replaces i686*-*-* && { ! lp64 } with the appropriate
> { i?86-*-* x86_64-*-* } && { ! lp64 } for the testcases and
> also amends the e variants checking last variant for avx.
> I've used avx in the dump scanning
