On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches
wrote:
>
> The upcoming work for frange triggers a regression in
> gcc.dg/tree-ssa/phi-opt-24.c.
>
> For -O2 -fno-signed-zeros, we fail to transform the following into -A:
>
> float f0(float A)
> {
> // A == 0? A : -Asame as
On Tue, Aug 30, 2022 at 9:03 AM Richard Biener
wrote:
>
> On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > The upcoming work for frange triggers a regression in
> > gcc.dg/tree-ssa/phi-opt-24.c.
> >
> > For -O2 -fno-signed-zeros, we fail to transform the following
On Tue, Aug 30, 2022 at 9:07 AM Aldy Hernandez wrote:
>
> On Tue, Aug 30, 2022 at 9:03 AM Richard Biener
> wrote:
> >
> > On Mon, Aug 29, 2022 at 10:45 PM Aldy Hernandez via Gcc-patches
> > wrote:
> > >
> > > The upcoming work for frange triggers a regression in
> > > gcc.dg/tree-ssa/phi-opt-24.
On Mon, 29 Aug 2022, Richard Biener wrote:
> On Mon, 29 Aug 2022, Richard Biener wrote:
>
> [...]
>
> > The patch correctly diagnoses an uninitalized use of 'regnum'
> > in store_bit_field_1 but also diagnoses an uninitialized use of
> > best_match::m_best_candidate_len which I've chosen to sile
Richard Biener writes:
> On Mon, 29 Aug 2022, Martin Jambor wrote:
>
>> Hi,
>>
>> On Mon, Aug 29 2022, Richard Biener wrote:
>> > On Mon, 29 Aug 2022, Martin Jambor wrote:
>> >
>> >> Hi again,
>> >>
>> >> On Mon, Aug 29 2022, Richard Biener wrote:
>> >> > On Fri, 26 Aug 2022, Martin Jambor wrote
This adds a testcase for the PR which was fixed with r13-2155-gbaa3ffb19c54fa
Pushed.
PR tree-optimization/63660
* gcc.dg/uninit-pr63660.c: New testcase.
---
gcc/testsuite/gcc.dg/uninit-pr63660.c | 58 +++
1 file changed, 58 insertions(+)
create mode 1006
This patch does what the comment in uninit diagnostic suggests.
When the value-numbering run done without optimizing figures there's
a fallthru path, consider blocks on it as always executed.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-ssa-uninit.cc (warn_uninitial
Pushed as obvious.
Fixes build on i686:
gcc/config/s390/s390.cc: In function 'bool s390_rtx_costs(rtx, machine_mode,
int, int, int*, bool)':
gcc/config/s390/s390.cc:3728:63: error: cannot convert 'long int*' to 'long
long int*'
gcc/ChangeLog:
* config/s390/s390.cc (s390_rtx_costs): Us
OK, I'm good to go.
As the patch was getting rather large, I have split it into two parts.
The first is the core endpoints support to frange along with removal
of the +-INF markers (since they are no longer needed). The second
part is the FP relational operators. Splitting it up should help in
r
Hi,
There are two splitters, both are calling rs6000_emit_set_const to emit
instructions for constant building.
One splitter checks `const_int_operand`, this splitter is always used.
Another spitter checks `const_scalar_int_operand`, this one is never
used now.
Checking the history, that splitter
Richard Biener via Gcc-patches writes:
> On Tue, 30 Aug 2022, Tamar Christina wrote:
>
>> Hi All,
>>
>> This initializes regnum to 0 for when undefined_p.
>> 0 is the right default as it's supposed to get the lowpart
>> when undefined.
>>
>> Bootstrapped Regtested on aarch64-none-linux-gnu and n
The following removes duplicate dumping and makes the predicate
dumping more readable. That makes the GENERIC predicate build
routines unused which is also nice.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* gimple-predicate-analysis.cc (dump_pred_chain): Fix
par
On Tue, 30 Aug 2022, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > On Tue, 30 Aug 2022, Tamar Christina wrote:
> >
> >> Hi All,
> >>
> >> This initializes regnum to 0 for when undefined_p.
> >> 0 is the right default as it's supposed to get the lowpart
> >> when undefined
On 5/4/22 10:59, Martin Liška wrote:
> Hello.
>
> I'm going to do merge from upstream.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. I've
> also tested
> on ppc64le-linux-gnu and verified the ABI.
>
> The only real change is a small change in
> gcc/testsuite/c-c++-c
Ping! Anyone interested in this. I'm bootstrapping my trunk builds with
this patch without problems.
On Mon, Aug 22, 2022 at 9:09 PM Ulrich Drepper wrote:
> This is the second version of the proposed patch to add more identifiers
> to the known list to give hints about #include and version num
Another very brief update to say that I'm now tidying up the code and
primary platform testing
regards,
Gaius
The following makes sure to have use predicates simplified and
normalized before doing uninit_analysis::overlap because that
otherwise cannot pick up all flag setting cases. This fixes
half of the issue in PR67196 and conveniently resolves the
XFAIL in gcc.dg/uninit-pred-7_a.c.
Bootstrapped and t
On Fri, Aug 26 2022, Alexander Monakov wrote:
> On Fri, 26 Aug 2022, Martin Jambor wrote:
>
>> > +/* Check if promoting general-dynamic TLS access model to local-dynamic is
>> > + desirable for DECL. */
>> > +
>> > +static bool
>> > +optimize_dyn_tls_for_decl_p (const_tree decl)
>> > +{
>> > +
On Wed, Jul 13, 2022 at 03:29:04PM -0400, Nathan Sidwell via Gcc-patches wrote:
> Inspired by a user question. Jason, thoughts?
FWIW, this makes sense. I mean, how could I be against a patch
quoting Macbeth?!
> Since C++ is such a moving target, Microsoft have /std:c++latest
> (AFAICT clang do
Setting the definite NAN property should also force a [NAN, NAN]
range, otherwise we'd have two ways of representing a NAN: with the
endpoints or with the property. In the ranger world we avoid at all
costs having more than one representation for a range.
In doing this, I removed the FRANGE_PROP_
Surya Kumari Jangala via Gcc-patches writes:
> sched1: Fix -fcompare-debug issue in schedule_region [PR105586]
>
> In schedule_region(), a basic block that does not contain any real insns
> is not scheduled and the dfa state at the entry of the bb is not copied
> to the fallthru basic block. Howev
On 8/30/22 13:03, Gaius Mulley via Gcc-patches wrote:
>
> Another very brief update to say that I'm now tidying up the code and
> primary platform testing
>
> regards,
> Gaius
Hello.
As you may know I'm working on the documentation migration from texinfo to
Sphinx
and I noticed you have quite
On Tue, 30 Aug 2022, Martin Jambor wrote:
> There is still the optimize attribute so in fact no, even in non-LTO
> mode if there is no current function, you cannot trust the "global"
> "optimize" thing.
>
> Ideally we would assert that no "analysis" phase of an IPA pass reads
> the global optimiz
On 7/13/22 15:29, Nathan Sidwell wrote:
Inspired by a user question. Jason, thoughts?
Since C++ is such a moving target, Microsoft have /std:c++latest
(AFAICT clang does not), to select the currently implemented version
of the working paper. But the use of 'std:latest' is somewhat
ambiguous --
On 8/22/22 15:09, Ulrich Drepper via Gcc-patches wrote:
This is the second version of the proposed patch to add more identifiers to
the known list to give hints about #include and version numbers.
Marek looked through the first version and found it acceptable but remarked
that the list is gettin
> On Aug 30, 2022, at 9:22 AM, Jason Merrill via Gcc-patches
> wrote:
>
> On 7/13/22 15:29, Nathan Sidwell wrote:
>> Inspired by a user question. Jason, thoughts?
>> Since C++ is such a moving target, Microsoft have /std:c++latest
>> (AFAICT clang does not), to select the currently implement
The MAX_NUM_CHAINS is applied once with <= and once with < which
results in the chains not limited but analyis dropped completely.
That's one issue in the PR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/73550
* gimple-predicate-analysis.cc (pr
This produces less redundancy and more complete info dumping
the control dependence chains.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* gimple-predicate-analysis.cc (format_edge_vec): Dump
both source and destination.
(dump_dep_chains): Remove.
(
Xi Ruoyao via Gcc-patches writes:
> Another attempt to make kernel module happy.
>
> One remaining issue: the patch cannot diagnostic some insane thing like
>
> int x __attribute__((model("normal")));
> int x __attribute__((model("extreme")));
>
> It seems incredibly difficult to diagnose
On Thu, Aug 25, 2022 at 10:37 AM Martin Liška wrote:
>
> Remove the port that has been marked obsolete in GCC 12 change notes.
>
> Ready to be installed?
OK.
> Thanks,
> Martin
>
> contrib/ChangeLog:
>
> * config-list.mk: Remove the port.
>
> gcc/ChangeLog:
>
> * config.gcc: Remo
Hi Tom!
Ping.
Grüße
Thomas
On 2022-08-16T17:12:47+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-08-06T21:20:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On 2022-07-27T17:48:46+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>
Hi Tom!
Ping.
Grüße
Thomas
On 2022-08-16T17:13:42+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-08-06T21:20:38+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On 2022-07-27T17:48:58+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
>>
On Tue, Aug 30, 2022 at 09:22:14AM -0400, Jason Merrill via Gcc-patches wrote:
> On 7/13/22 15:29, Nathan Sidwell wrote:
> > Inspired by a user question. Jason, thoughts?
> >
> > Since C++ is such a moving target, Microsoft have /std:c++latest
> > (AFAICT clang does not), to select the currently
> I see, thank you for explaining the issue, and sorry if I was a bit stubborn.
>
> Does the attached patch (incremental change below) look better? It no longer
> has the 'shortcut' where iterating over referrers is avoided for the common
> case of plain 'gcc -O2' and no 'optimize' attributes, but
Jeff Law via Gcc-patches writes:
> On 8/25/2022 7:07 AM, Richard Sandiford via Gcc-patches wrote:
>> Currently SLP tries to force permute operations "down" the graph
>> from loads in the hope of reducing the total number of permutations
>> needed or (in the best case) removing the need for the per
On 26/08/2022 12:04, Jakub Jelinek wrote:
gcc/ChangeLog:
* doc/tm.texi: Regenerate.
* omp-simd-clone.cc (simd_clone_adjust_return_type): Allow zero
vecsize.
(simd_clone_adjust_argument_types): Likewise.
* target.def (compute_vecsize_and_simdlen): Document
On 09/08/2022 14:23, Andrew Stubbs wrote:
Enable and configure SIMD clones for amdgcn. This affects both the __simd__
function attribute, and the OpenMP "declare simd" directive.
Note that the masked SIMD variants are generated, but the middle end doesn't
actually support calling them yet.
gc
On Mon, Aug 15, 2022 at 07:42:39PM +0300, Frolov Daniil wrote:
> вт, 12 апр. 2022 г. в 00:56, Marek Polacek :
>
> >
> > On Thu, Apr 07, 2022 at 02:10:48AM +0500, Frolov Daniil wrote:
> > > Hello! Thanks for your feedback. I've tried to take into account your
> > > comments. New patch applied to th
On Mon, Aug 29, 2022 at 11:31:54PM -0400, Jason Merrill wrote:
> > The pedwarn on -std=c++23 -finput-charset=UTF-8 or just documenting that
> > "conforming" UTF-8 is only -finput-charset=UTF-8 -Werror=invalid-utf8 ?
>
> The former.
Ok.
So, here is an updated patch that implements that, and also
Martin Liška writes:
> On 8/30/22 13:03, Gaius Mulley via Gcc-patches wrote:
>>
>> Another very brief update to say that I'm now tidying up the code and
>> primary platform testing
>>
>> regards,
>> Gaius
>
> Hello.
>
> As you may know I'm working on the documentation migration from texinfo to
Previously [5,6] U NAN would just drop to VARYING. With this patch,
the resulting range becomes [5,6] with the NAN bit set to unknown.
[I still have yet to decide what to do with intersections. ISTM, the
intersection of a known NAN with anything else should be a NAN, but it
could also be undefin
> On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
> wrote:
>>
>>
>> LLVM defines both __bpf__ and __BPF_ as target macros.
>> GCC was defining only __BPF__.
>>
>> This patch defines __bpf__ as a target macro for BPF.
>> Tested in bpf-unknown-none.
>>
>> gcc/ChangeLog:
>>
>>
Hi Andrew,
> On 26/08/2022 12:04, Jakub Jelinek wrote:
>>> gcc/ChangeLog:
>>>
>>> * doc/tm.texi: Regenerate.
>>> * omp-simd-clone.cc (simd_clone_adjust_return_type): Allow zero
>>> vecsize.
>>> (simd_clone_adjust_argument_types): Likewise.
>>> * target.def (compute_vecsize_and_
Hi,
this patch replaces linked lists of ipa_agg_replacement_value with
vectors of similar structures called ipa_argagg_value and simplifies
how we compute them in the first place. Having a vector should also
result in less overhead when allocating and because we keep it sorted,
it leads to logari
Hi
this patch extends the previous one by using the same data structure
to represent aggregate values in classes ipa_auto_call_arg_values and
ipa_call_arg_values.
This usually simplifies handling and makes allocations of memory much
cheaper because only a single vectore is needed, as opposed to v
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (adjacent_view): Define.
(enable_borrowed_range): Define.
(__detail::__repeated_tuple): Define.
(adjacent_view::_Iterator): Define.
(adjacent_view::_Sen
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* testsuite/20_util/logical_traits/requirements/short_circuit.cc: New
test.
---
.../requirements/short_circuit.cc | 32 +++
1 file changed, 32 insertions(+)
create mode 10064
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__unarize): Define.
(adjacent_view::_Iterator): Befriend adjacent_transform_view.
(adjacent_transform_view): Define.
(adjacent_transform_view::_Itera
I'd like to ping the following patch.
Peter
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600451.html
Message-ID:
>When we expand an MMA disassemble built-in with C++ using a pointer that
>is casted to a valid MMA type, the type isn't passed down to the expand
>machinery and we e
On Tue, Aug 30, 2022 at 9:46 AM Jose E. Marchesi
wrote:
>
>
> > On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
> > wrote:
> >>
> >>
> >> LLVM defines both __bpf__ and __BPF_ as target macros.
> >> GCC was defining only __BPF__.
> >>
> >> This patch defines __bpf__ as a target ma
Hi,
A couple of cleanup patches when trying to understand -mexplicit-relocs
and code model.
- 1/2 should be strightfwd
- 2/2 might be slightly controversial.
Tested with a bunch of rv32/rv64 configs: same results before after,
granted pic might not really be getting tested here.
Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index eb7ef09297e9..bba72cf77a
CM_PIC is no longer doing anything directly. Removing it might
potentially affect USE_LOAD_ADDRESS_MACRO() but seems unlikely.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 4
gcc/config/riscv/riscv-opts.h | 3 +--
gcc/config/riscv/riscv.cc | 2 +-
3 files changed, 2
On 2022-08-29 10:06 a.m., Martin Liška wrote:
Thanks for the feedback, can you please check the updated version of the patch?
hppa64-hp-hpux11.11 built successfully with the updated patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2022-August/767508.html
Dave
--
John David Anglin dave.a
On 2022-08-29 10:06 a.m., Martin Liška wrote:
Thanks for the feedback, can you please check the updated version of the patch?
The changes to the libffi directory are not necessary and incorrect. libffi is
a separate project.
Dave
--
John David Anglin dave.ang...@bell.net
On 2022-08-29 10:06 a.m., Martin Liška wrote:
Thanks for the feedback, can you please check the updated version of the patch?
@@ -353,9 +347,6 @@ proc check_weak_available { } {
# return 1 if weak undefined symbols are supported.
proc check_effective_target_weak_undefined { } {
- if { [ist
On 8/11/22 21:38, David Malcolm via Gcc-patches wrote:
PR c/90885 notes various places in real-world code where people have
written C/C++ code that uses ^ (exclusive or) where presumbably they
meant exponentiation.
For example
https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=2%5E32&search
Hi, Joseph and Nathan,
Could you please review the C and C++ FE parts of the patch?
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html
The middle-end changes have been approved by Richard already.
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600379.html
Thanks.
Begin
This looks good to me, one thing though:
On Thu, Aug 11, 2022 at 09:38:12PM -0400, David Malcolm via Gcc-patches wrote:
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -1439,6 +1439,10 @@ Wwrite-strings
> C ObjC C++ ObjC++ Var(warn_write_strings) Warning
> In C++, nonzero means warn a
I'm seeing build failures of glibc for powerpc64, as illustrated by the
following C code:
#if 0
\NARG
#endif
(the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef
__ASSEMBLER__).
This shows some problems with this feature - and with delimited escape
sequences - as it affects C.
On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:
> I'm seeing build failures of glibc for powerpc64, as illustrated by the
> following C code:
>
> #if 0
> \NARG
> #endif
>
> (the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef
> __ASSEMBLER__).
>
> This shows some
On Tue, Aug 30, 2022 at 11:18:20PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:
> > I'm seeing build failures of glibc for powerpc64, as illustrated by the
> > following C code:
> >
> > #if 0
> > \NARG
> > #endif
> >
> > (the actual
On 8/30/22 11:20, Jakub Jelinek wrote:
On Mon, Aug 29, 2022 at 11:31:54PM -0400, Jason Merrill wrote:
The pedwarn on -std=c++23 -finput-charset=UTF-8 or just documenting that
"conforming" UTF-8 is only -finput-charset=UTF-8 -Werror=invalid-utf8 ?
The former.
Ok.
So, here is an updated patch
On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> I was hoping Joseph would chime in here - I recollect debugging this kind
> of thing and a thread about this a while back but unfortunately I do not
> remember the details here (IIRC some things get included where they
> better should no
On Sat, 27 Aug 2022, Jose E. Marchesi via Gcc-patches wrote:
> + if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer
> types" } */
> + if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer
> types" } */
> + if (metadata + 1 > data) /* There shouldn't
On Mon, 29 Aug 2022, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> > For convenience, singleton_p() returns false for a NAN. IMO, it makes
> > the implementation cleaner, but I'm not wed to the idea if someone
> > objects.
>
> If singlet
On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote:
> Hi, Joseph and Nathan,
>
> Could you please review the C and C++ FE parts of the patch?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html
I think some work is still needed on the diagnostic wording.
> + "%qE attribute
On 8/28/2022 10:34 AM, John David Anglin wrote:
On 2022-08-26 3:15 a.m., Martin Liška wrote:
Removes the deprecated ports. If I'm correct all hpux9,hpux10 should
be removed
as they only provide 32-bit targets. On the contrary, hpux11 supports
hppa64 that
we still do support.
It is my unders
On 2022-08-30 8:13 p.m., Jeff Law wrote:
On 8/28/2022 10:34 AM, John David Anglin wrote:
On 2022-08-26 3:15 a.m., Martin Liška wrote:
Removes the deprecated ports. If I'm correct all hpux9,hpux10 should be removed
as they only provide 32-bit targets. On the contrary, hpux11 supports hppa64
t
On Sat, 2022-07-09 at 10:11 -0600, Jeff Law via Gcc-patches wrote:
> Once Alex is OK with this patch, then it'll be good to go.
>
> jeff
Gentle ping as a distro maintainer :).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
If I got your point correctly here is this patch again with just the
change on '0' becoming 'nullptr' in assertions.
libstdc++: [_GLIBCXX_DEBUG] Review nullptr assertion diagnostics
Review null string checks to show:
_String != nullptr
rather than:
_String != 0
libstdc
After a second thought here is an even cleaner version. No more function
rename, current pretty_print is fine.
libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace
generation on
_GLIBCXX_DEBUG assertions. Prerequi
The LoongArch support for libubsan and libasan has been added in:
- https://reviews.llvm.org/D129371
- https://reviews.llvm.org/D129418
and we've merged them in r13-2269. It's time to enable them.
No unexpected failures in GCC asan.exp and ubsan.exp tests.
libsanitizer/ChangeLog:
* co
OK!
Thanks!
在 2022/8/31 下午1:54, Xi Ruoyao 写道:
The LoongArch support for libubsan and libasan has been added in:
- https://reviews.llvm.org/D129371
- https://reviews.llvm.org/D129418
and we've merged them in r13-2269. It's time to enable them.
No unexpected failures in GCC asan.exp and ubsan
On Tue, Aug 30, 2022 at 5:43 PM Aldy Hernandez via Gcc-patches
wrote:
>
> Previously [5,6] U NAN would just drop to VARYING. With this patch,
> the resulting range becomes [5,6] with the NAN bit set to unknown.
>
> [I still have yet to decide what to do with intersections. ISTM, the
> intersecti
On Wed, Aug 31, 2022 at 8:22 AM Richard Biener
wrote:
>
> On Tue, Aug 30, 2022 at 5:43 PM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > Previously [5,6] U NAN would just drop to VARYING. With this patch,
> > the resulting range becomes [5,6] with the NAN bit set to unknown.
> >
> > [I still ha
Hi,
Handle E_V8BFmode in expand_vec_perm_broadcast_1 and
ix86_expand_vector_init_duplicate.
Ok for trunk?
gcc/ChangeLog:
PR target/106742
* config/i386/i386-expand.cc (ix86_expand_vector_init_duplicate):
Handle V8BF mode.
(expand_vec_perm_broadcast_1): Ditto.
gc
77 matches
Mail list logo
