/home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at

2023-08-06 Thread Toon Moene

Wonder if I am the only one to see this:

https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/792616.html

To quote:

during RTL pass: split1
/home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function 
'matmul_i1_avx512f':
/home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: 
internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 
'w' (rtx const_int) in vpternlog_redundant_operand_mask, at 
config/i386/i386.cc:19460

 1781 | }
  | ^
during RTL pass: split1
/home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c: In function 
'matmul_i2_avx512f':
/home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c:1781:1: 
internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 
'w' (rtx const_int) in vpternlog_redundant_operand_mask, at 
config/i386/i386.cc:19460

 1781 | }
  | ^
0x7a5cc7 rtl_check_failed_type2(rtx_def const*, int, int, int, char 
const*, int, char const*)

/home/toon/compilers/gcc/gcc/rtl.cc:761
0x82bf8d vpternlog_redundant_operand_mask(rtx_def**)
/home/toon/compilers/gcc/gcc/config/i386/i386.cc:19460
0x1f1295b split_44
/home/toon/compilers/gcc/gcc/config/i386/sse.md:12730
0x1f1295b split_63
/home/toon/compilers/gcc/gcc/config/i386/sse.md:28428
0xe7663b try_split(rtx_def*, rtx_insn*, int)
/home/toon/compilers/gcc/gcc/emit-rtl.cc:3800
0xe76cff try_split(rtx_def*, rtx_insn*, int)
/home/toon/compilers/gcc/gcc/emit-rtl.cc:3972
0x11b2938 split_insn
/home/toon/compilers/gcc/gcc/recog.cc:3385
0x11b2eff split_all_insns()
/home/toon/compilers/gcc/gcc/recog.cc:3489
0x11dd9c8 execute
/home/toon/compilers/gcc/gcc/recog.cc:4413
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).

Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [Makefile:4584: matmul_i1.lo] Error 1
make[3]: *** Waiting for unfinished jobs

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands


Re: GCC support for extensions from later standards

2023-08-06 Thread Jason Merrill via Gcc
On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser 
wrote:

> Hi everyone!
>
> I'm working on libc++ and we are currently discussing using language
> extensions from later standards (
> https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4).
> By that I mean things like using `if constexpr` with `-std=c++11`. GCC has
> quite a lot of these kinds of conforming extensions, but doesn't document
> them AFAICT. While discussing using these extensions, the question came up
> what GCCs support policy for these is. Aaron was kind enough to answer
> these questions for us on the Clang side. Since I couldn't find anything in
> the documentation, I thought I'd ask here.
>
> So, here are my questions:
>
> Do you expect that these extensions will ever be removed for some reason?
> If yes, what could those reasons be?
>

Potentially, if they don't actually work properly in earlier standard
modes.  I recently noticed that while we allow DMI and =default in C++03
mode with a pedwarn, combining them doesn't work.

Some of the extensions are needed by libstdc++ and are therefore well
tested; these are extremely unlikely to ever be removed.  libstdc++ folks,
is there a list of these?

Would you be interested in documenting them?
>

That would be useful, yes.

There is a patch in review to add __has_feature/__has_extension to G++,
which would seem like a suitable context for this documentation.

Aaron noted that we should ask the Clang folks before using them, so they
> can evaluated whether the extension makes sense, since they might not be
> aware of them, and some might be broken. So I'd be interested whether you
> would also like us to ask whether you want to actually support these
> extensions.
>

Sounds good.

Jason


Re: GCC support for extensions from later standards

2023-08-06 Thread Jonathan Wakely via Gcc
On Sun, 6 Aug 2023 at 20:20, Jason Merrill via Libstdc++
 wrote:
>
> On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser 
> wrote:
>
> > Hi everyone!
> >
> > I'm working on libc++ and we are currently discussing using language
> > extensions from later standards (
> > https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4).
> > By that I mean things like using `if constexpr` with `-std=c++11`. GCC has
> > quite a lot of these kinds of conforming extensions, but doesn't document
> > them AFAICT. While discussing using these extensions, the question came up
> > what GCCs support policy for these is. Aaron was kind enough to answer
> > these questions for us on the Clang side. Since I couldn't find anything in
> > the documentation, I thought I'd ask here.
> >
> > So, here are my questions:
> >
> > Do you expect that these extensions will ever be removed for some reason?
> > If yes, what could those reasons be?
> >
>
> Potentially, if they don't actually work properly in earlier standard
> modes.  I recently noticed that while we allow DMI and =default in C++03
> mode with a pedwarn, combining them doesn't work.
>
> Some of the extensions are needed by libstdc++ and are therefore well
> tested; these are extremely unlikely to ever be removed.  libstdc++ folks,
> is there a list of these?

We use variadic templates and long long in C++98. We use a DMI in
__gnu_cxx::__mutex even in C++98. I don't think we unconditionally use
anything else, because we can't rely on it being available when using
non-GCC compilers, or when compiling with -Wsystem-headers -pedantic.
We don't use if-constexpr before C++17 for example.

>
> Would you be interested in documenting them?
> >
>
> That would be useful, yes.
>
> There is a patch in review to add __has_feature/__has_extension to G++,
> which would seem like a suitable context for this documentation.
>
> Aaron noted that we should ask the Clang folks before using them, so they
> > can evaluated whether the extension makes sense, since they might not be
> > aware of them, and some might be broken. So I'd be interested whether you
> > would also like us to ask whether you want to actually support these
> > extensions.
> >
>
> Sounds good.
>
> Jason


gcc-14-20230806 is now available

2023-08-06 Thread GCC Administrator via Gcc
Snapshot gcc-14-20230806 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/14-20230806/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 529909f9e92dd3b0ed0383f45a44d2b5f8a58958

You'll find:

 gcc-14-20230806.tar.xz   Complete GCC

  SHA256=46a5396f15fc89439309a0f3ff197e9422df8b05d6657b9429a6cfae66f3e530
  SHA1=bd6e96f396101885e0904fc74fdbd2e7c4b5af91

Diffs from 14-20230730 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-14
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

2023-08-06 Thread Hongtao Liu via Gcc
On Mon, Aug 7, 2023 at 2:08 AM Toon Moene  wrote:
>
> Wonder if I am the only one to see this:
>
> https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/792616.html
>
> To quote:
>
> during RTL pass: split1
> /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function
> 'matmul_i1_avx512f':
> /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1:
> internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
> config/i386/i386.cc:19460
>   1781 | }
>| ^
> during RTL pass: split1
> /home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c: In function
> 'matmul_i2_avx512f':
> /home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c:1781:1:
> internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
> config/i386/i386.cc:19460
>   1781 | }
>| ^
> 0x7a5cc7 rtl_check_failed_type2(rtx_def const*, int, int, int, char
> const*, int, char const*)
> /home/toon/compilers/gcc/gcc/rtl.cc:761
> 0x82bf8d vpternlog_redundant_operand_mask(rtx_def**)
> /home/toon/compilers/gcc/gcc/config/i386/i386.cc:19460
> 0x1f1295b split_44
> /home/toon/compilers/gcc/gcc/config/i386/sse.md:12730
> 0x1f1295b split_63
> /home/toon/compilers/gcc/gcc/config/i386/sse.md:28428
> 0xe7663b try_split(rtx_def*, rtx_insn*, int)
> /home/toon/compilers/gcc/gcc/emit-rtl.cc:3800
> 0xe76cff try_split(rtx_def*, rtx_insn*, int)
> /home/toon/compilers/gcc/gcc/emit-rtl.cc:3972
> 0x11b2938 split_insn
> /home/toon/compilers/gcc/gcc/recog.cc:3385
> 0x11b2eff split_all_insns()
> /home/toon/compilers/gcc/gcc/recog.cc:3489
> 0x11dd9c8 execute
> /home/toon/compilers/gcc/gcc/recog.cc:4413
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[3]: *** [Makefile:4584: matmul_i1.lo] Error 1
> make[3]: *** Waiting for unfinished jobs
>
> --
> Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Looks like related to

https://gcc.gnu.org/g:567d06bb357a39ece865cef67ada44124f227e45

commit r14-2999-g567d06bb357a39ece865cef67ada44124f227e45
Author: Yan Simonaytes 
Date:   Tue Jul 25 20:43:19 2023 +0300

i386: eliminate redundant operands of VPTERNLOG

As mentioned in PR 110202, GCC may be presented with input where control
word of the VPTERNLOG intrinsic implies that some of its operands do not
affect the result.  In that case, we can eliminate redundant operands
of the instruction by substituting any other operand in their place.
This removes false dependencies.


-- 
BR,
Hongtao


Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

2023-08-06 Thread Hongtao Liu via Gcc
On Mon, Aug 7, 2023 at 9:35 AM Hongtao Liu  wrote:
>
> On Mon, Aug 7, 2023 at 2:08 AM Toon Moene  wrote:
> >
> > Wonder if I am the only one to see this:
> >
> > https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/792616.html
Could you share your GCC configure, I guess
--enable-checking=yes,rtl,extra is key to reproduce the issue?
> >
> > To quote:
> >
> > during RTL pass: split1
> > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function
> > 'matmul_i1_avx512f':
> > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1:
> > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> > 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
> > config/i386/i386.cc:19460
> >   1781 | }
> >| ^
> > during RTL pass: split1
> > /home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c: In function
> > 'matmul_i2_avx512f':
> > /home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c:1781:1:
> > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> > 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
> > config/i386/i386.cc:19460
> >   1781 | }
> >| ^
> > 0x7a5cc7 rtl_check_failed_type2(rtx_def const*, int, int, int, char
> > const*, int, char const*)
> > /home/toon/compilers/gcc/gcc/rtl.cc:761
> > 0x82bf8d vpternlog_redundant_operand_mask(rtx_def**)
> > /home/toon/compilers/gcc/gcc/config/i386/i386.cc:19460
> > 0x1f1295b split_44
> > /home/toon/compilers/gcc/gcc/config/i386/sse.md:12730
> > 0x1f1295b split_63
> > /home/toon/compilers/gcc/gcc/config/i386/sse.md:28428
> > 0xe7663b try_split(rtx_def*, rtx_insn*, int)
> > /home/toon/compilers/gcc/gcc/emit-rtl.cc:3800
> > 0xe76cff try_split(rtx_def*, rtx_insn*, int)
> > /home/toon/compilers/gcc/gcc/emit-rtl.cc:3972
> > 0x11b2938 split_insn
> > /home/toon/compilers/gcc/gcc/recog.cc:3385
> > 0x11b2eff split_all_insns()
> > /home/toon/compilers/gcc/gcc/recog.cc:3489
> > 0x11dd9c8 execute
> > /home/toon/compilers/gcc/gcc/recog.cc:4413
> > Please submit a full bug report, with preprocessed source (by using
> > -freport-bug).
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > make[3]: *** [Makefile:4584: matmul_i1.lo] Error 1
> > make[3]: *** Waiting for unfinished jobs
> >
> > --
> > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> > Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
>
> Looks like related to
>
> https://gcc.gnu.org/g:567d06bb357a39ece865cef67ada44124f227e45
>
> commit r14-2999-g567d06bb357a39ece865cef67ada44124f227e45
> Author: Yan Simonaytes 
> Date:   Tue Jul 25 20:43:19 2023 +0300
>
> i386: eliminate redundant operands of VPTERNLOG
>
> As mentioned in PR 110202, GCC may be presented with input where control
> word of the VPTERNLOG intrinsic implies that some of its operands do not
> affect the result.  In that case, we can eliminate redundant operands
> of the instruction by substituting any other operand in their place.
> This removes false dependencies.
>
>
> --
> BR,
> Hongtao



-- 
BR,
Hongtao


Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

2023-08-06 Thread Hongtao Liu via Gcc
On Mon, Aug 7, 2023 at 9:38 AM Hongtao Liu  wrote:
>
> On Mon, Aug 7, 2023 at 9:35 AM Hongtao Liu  wrote:
> >
> > On Mon, Aug 7, 2023 at 2:08 AM Toon Moene  wrote:
> > >
> > > Wonder if I am the only one to see this:
> > >
> > > https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/792616.html
> Could you share your GCC configure, I guess
> --enable-checking=yes,rtl,extra is key to reproduce the issue?
Reproduce with  --with-cpu=native --with-arch=native
---enable-checking=yes,rtl,extra on an AVX512 machine.
So on non-avx512 machine --with-cpu=cascadelake
--with-arch=cascadelake --enable-checking=yes,rtl,extra should be
enough.
> > >
> > > To quote:
> > >
> > > during RTL pass: split1
> > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function
> > > 'matmul_i1_avx512f':
> > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1:
> > > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> > > 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
> > > config/i386/i386.cc:19460
> > >   1781 | }
> > >| ^
> > > during RTL pass: split1
> > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c: In function
> > > 'matmul_i2_avx512f':
> > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c:1781:1:
> > > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> > > 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
> > > config/i386/i386.cc:19460
> > >   1781 | }
> > >| ^
> > > 0x7a5cc7 rtl_check_failed_type2(rtx_def const*, int, int, int, char
> > > const*, int, char const*)
> > > /home/toon/compilers/gcc/gcc/rtl.cc:761
> > > 0x82bf8d vpternlog_redundant_operand_mask(rtx_def**)
> > > /home/toon/compilers/gcc/gcc/config/i386/i386.cc:19460
> > > 0x1f1295b split_44
> > > /home/toon/compilers/gcc/gcc/config/i386/sse.md:12730
> > > 0x1f1295b split_63
> > > /home/toon/compilers/gcc/gcc/config/i386/sse.md:28428
> > > 0xe7663b try_split(rtx_def*, rtx_insn*, int)
> > > /home/toon/compilers/gcc/gcc/emit-rtl.cc:3800
> > > 0xe76cff try_split(rtx_def*, rtx_insn*, int)
> > > /home/toon/compilers/gcc/gcc/emit-rtl.cc:3972
> > > 0x11b2938 split_insn
> > > /home/toon/compilers/gcc/gcc/recog.cc:3385
> > > 0x11b2eff split_all_insns()
> > > /home/toon/compilers/gcc/gcc/recog.cc:3489
> > > 0x11dd9c8 execute
> > > /home/toon/compilers/gcc/gcc/recog.cc:4413
> > > Please submit a full bug report, with preprocessed source (by using
> > > -freport-bug).
> > > Please include the complete backtrace with any bug report.
> > > See  for instructions.
> > > make[3]: *** [Makefile:4584: matmul_i1.lo] Error 1
> > > make[3]: *** Waiting for unfinished jobs
> > >
> > > --
> > > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> > > Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> >
> > Looks like related to
> >
> > https://gcc.gnu.org/g:567d06bb357a39ece865cef67ada44124f227e45
> >
> > commit r14-2999-g567d06bb357a39ece865cef67ada44124f227e45
> > Author: Yan Simonaytes 
> > Date:   Tue Jul 25 20:43:19 2023 +0300
> >
> > i386: eliminate redundant operands of VPTERNLOG
> >
> > As mentioned in PR 110202, GCC may be presented with input where control
> > word of the VPTERNLOG intrinsic implies that some of its operands do not
> > affect the result.  In that case, we can eliminate redundant operands
> > of the instruction by substituting any other operand in their place.
> > This removes false dependencies.
> >
> >
> > --
> > BR,
> > Hongtao
>
>
>
> --
> BR,
> Hongtao



-- 
BR,
Hongtao


Re: /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_mask,

2023-08-06 Thread Andrew Pinski via Gcc
On Sun, Aug 6, 2023 at 7:41 PM Hongtao Liu via Gcc  wrote:
>
> On Mon, Aug 7, 2023 at 9:38 AM Hongtao Liu  wrote:
> >
> > On Mon, Aug 7, 2023 at 9:35 AM Hongtao Liu  wrote:
> > >
> > > On Mon, Aug 7, 2023 at 2:08 AM Toon Moene  wrote:
> > > >
> > > > Wonder if I am the only one to see this:
> > > >
> > > > https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/792616.html
> > Could you share your GCC configure, I guess
> > --enable-checking=yes,rtl,extra is key to reproduce the issue?
> Reproduce with  --with-cpu=native --with-arch=native
> ---enable-checking=yes,rtl,extra on an AVX512 machine.
> So on non-avx512 machine --with-cpu=cascadelake
> --with-arch=cascadelake --enable-checking=yes,rtl,extra should be
> enough.

Also filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110926 .

Thanks,
Andrew

> > > >
> > > > To quote:
> > > >
> > > > during RTL pass: split1
> > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c: In function
> > > > 'matmul_i1_avx512f':
> > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i1.c:1781:1:
> > > > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> > > > 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
> > > > config/i386/i386.cc:19460
> > > >   1781 | }
> > > >| ^
> > > > during RTL pass: split1
> > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c: In function
> > > > 'matmul_i2_avx512f':
> > > > /home/toon/compilers/gcc/libgfortran/generated/matmul_i2.c:1781:1:
> > > > internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have
> > > > 'w' (rtx const_int) in vpternlog_redundant_operand_mask, at
> > > > config/i386/i386.cc:19460
> > > >   1781 | }
> > > >| ^
> > > > 0x7a5cc7 rtl_check_failed_type2(rtx_def const*, int, int, int, char
> > > > const*, int, char const*)
> > > > /home/toon/compilers/gcc/gcc/rtl.cc:761
> > > > 0x82bf8d vpternlog_redundant_operand_mask(rtx_def**)
> > > > /home/toon/compilers/gcc/gcc/config/i386/i386.cc:19460
> > > > 0x1f1295b split_44
> > > > /home/toon/compilers/gcc/gcc/config/i386/sse.md:12730
> > > > 0x1f1295b split_63
> > > > /home/toon/compilers/gcc/gcc/config/i386/sse.md:28428
> > > > 0xe7663b try_split(rtx_def*, rtx_insn*, int)
> > > > /home/toon/compilers/gcc/gcc/emit-rtl.cc:3800
> > > > 0xe76cff try_split(rtx_def*, rtx_insn*, int)
> > > > /home/toon/compilers/gcc/gcc/emit-rtl.cc:3972
> > > > 0x11b2938 split_insn
> > > > /home/toon/compilers/gcc/gcc/recog.cc:3385
> > > > 0x11b2eff split_all_insns()
> > > > /home/toon/compilers/gcc/gcc/recog.cc:3489
> > > > 0x11dd9c8 execute
> > > > /home/toon/compilers/gcc/gcc/recog.cc:4413
> > > > Please submit a full bug report, with preprocessed source (by using
> > > > -freport-bug).
> > > > Please include the complete backtrace with any bug report.
> > > > See  for instructions.
> > > > make[3]: *** [Makefile:4584: matmul_i1.lo] Error 1
> > > > make[3]: *** Waiting for unfinished jobs
> > > >
> > > > --
> > > > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
> > > > Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
> > >
> > > Looks like related to
> > >
> > > https://gcc.gnu.org/g:567d06bb357a39ece865cef67ada44124f227e45
> > >
> > > commit r14-2999-g567d06bb357a39ece865cef67ada44124f227e45
> > > Author: Yan Simonaytes 
> > > Date:   Tue Jul 25 20:43:19 2023 +0300
> > >
> > > i386: eliminate redundant operands of VPTERNLOG
> > >
> > > As mentioned in PR 110202, GCC may be presented with input where 
> > > control
> > > word of the VPTERNLOG intrinsic implies that some of its operands do 
> > > not
> > > affect the result.  In that case, we can eliminate redundant operands
> > > of the instruction by substituting any other operand in their place.
> > > This removes false dependencies.
> > >
> > >
> > > --
> > > BR,
> > > Hongtao
> >
> >
> >
> > --
> > BR,
> > Hongtao
>
>
>
> --
> BR,
> Hongtao