On Mon, 1 Feb 2021, Jakub Jelinek wrote:
> On Mon, Feb 01, 2021 at 12:54:50PM -0700, Jeff Law wrote:
> > >>> So I see no difference for stage2-gcc/*.o dse1/dse2 with/without the
> > >>> patch but counts are _extremely_ small. Statistics:
> > >>>
> > >>> 70148 dse: local deletions = 0, global de
On Mon, 1 Feb 2021, Qing Zhao wrote:
> Hi, Richard,
>
> I have adjusted SRA phase to split calls to DEFERRED_INIT per you suggestion.
>
> And now the routine “bump_map” in 511.povray is like following:
> ...
>
> # DEBUG BEGIN_STMT
> xcoor = 0.0;
> ycoor = 0.0;
> # DEBUG BEGIN_STMT
> in
- Check `from` mode is not BLMmode before call store_expr, calling store_expr
with BLKmode will cause ICE.
- Verified with riscv64, x86_64 and aarch64, no introduce new regression.
Note: Those logic was introduced by 3e60ddeb8220ed388819bb3f14e8caa9309fd3c2,
so I cc Jakub for reivew.
On Mon, 1 Feb 2021 at 10:08, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 29 January 2021 18:18
> > To: Kyrylo Tkachov
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] arm: Auto-vectorization for MVE: vorn
> >
> > On Fri, 29 Jan 2021 at 1
On 2/2/21 12:12 AM, Jason Merrill wrote:
On 2/1/21 9:15 PM, Ed Smith-Rowland wrote:
On 2/1/21 2:23 PM, Jakub Jelinek wrote:
On Mon, Feb 01, 2021 at 01:46:13PM -0500, Ed Smith-Rowland wrote:
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++23 } }
+
+#include
+#include
+
+static_assert(std::is_
On 2/2/21 12:19 AM, Patrick Palka wrote:
In this testcase, we're crashing because the lookup of operator+ from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and C2::operator+) and returns a TREE_LIST
thereof, something which maybe_save_operator_binding is
In this testcase, we're crashing because the lookup of operator+ from
within the generic lambda via lookup_name finds multiple bindings
(namely C1::operator+ and C2::operator+) and returns a TREE_LIST
thereof, something which maybe_save_operator_binding isn't prepared to
handle.
Since we already d
On 2/1/21 9:15 PM, Ed Smith-Rowland wrote:
On 2/1/21 2:23 PM, Jakub Jelinek wrote:
On Mon, Feb 01, 2021 at 01:46:13PM -0500, Ed Smith-Rowland wrote:
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++23 } }
+
+#include
+#include
+
+static_assert(std::is_same_v);
+static_assert(std::is_same_v);
S
>From 4ceff15935a16da9ec5833279807855a8afc47cd Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Mon, 1 Feb 2021 22:19:57 -0500
Subject: [PATCH] Make asm not contain prefixed addresses.
In PR target/98519, the assembler does not like asm memory references that are
prefixed. We can't automati
PR analyzer/93355 tracks that -fanalyzer fails to report the FILE *
leak in read_alias_file in intl/localealias.c.
One reason for the failure is that read_alias_file is marked as
"static", and the path leading to the single call of
read_alias_file is falsely rejected as infeasible due to
PR analyz
This patch adds a couple more reduced test cases derived from the
integration test for PR analyzer/93355. In both cases, the analyzer
falsely rejects the buggy code paths as being infeasible due to
PR analyzer/96374, and so the tests are marked as XFAIL for now.
Tested on x86_64-pc-linux-gnu.
Pus
On 2/1/21 2:23 PM, Jakub Jelinek wrote:
On Mon, Feb 01, 2021 at 01:46:13PM -0500, Ed Smith-Rowland wrote:
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++23 } }
+
+#include
+#include
+
+static_assert(std::is_same_v);
+static_assert(std::is_same_v);
Shouldn't this be std::make_signed::type ins
Hi,
This patch merges the D front-end implementation with upstream dmd
5e2a81d9c, fixing PR98921. This adds a special formatter to OutBuffer
to handle formatted printing of integers, a common case. The
replacement is faster and safer.
In dmangle.c, it also gets rid of a number of problematic ca
On Mon, 1 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
> The message which contains the attached gzipped tarball of the
> development test programs is:
> https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg254210.html
> I'll include that link in the new patch as well.
I think it's best
On 02.02.2021 02:00, Ivan Sorokin wrote:
> [PATCH] [PR91400] build only one __cpu_model variable
This is my first patch to GCC. So I might have done something totally
stupid or totally wrong. Caution is required for reviewing. :-)
> gcc/ChangeLog:
>
> PR target/91400
> * config/i386/
Prior to this commit GCC -O2 generated quite bad code for this
function:
bool f()
{
return __builtin_cpu_supports("popcnt")
&& __builtin_cpu_supports("ssse3");
}
f:
movl__cpu_model+12(%rip), %eax
xorl%r8d, %r8d
testb $4, %al
je .L1
The message which contains the attached gzipped tarball of the
development test programs is:
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg254210.html
I'll include that link in the new patch as well.
I can't recall why I did not use _LIBGCC_XF_EPSILON__ or
_LIBGCC_TF_EPSILON__ before. P
Hi all,
This patch moves the vrshrn* intrinsics to builtins away from inline asm.
It's a bit of code, but it's very similar to the recent vsrhn* reimplementation
except that we use an unspec rather than standard RTL codes for the
functionality.
Bootstrapped and tested on aarch64-none-linux-gnu a
On Linux/x86_64,
6e0a231a4aa2407bb7167daf98a37795a67364d8 is the first bad commit
commit 6e0a231a4aa2407bb7167daf98a37795a67364d8
Author: Jason Merrill
Date: Wed Jan 27 17:15:39 2021 -0500
c++: alias in qualified-id in template arg [PR98570]
caused
FAIL: g++.dg/cpp0x/alias-decl-52.C -st
PR analyzer/98918 reports various false positives and state explosions
on correct code that frees nodes and other pointers in a singly-linked
list.
The issue is that state-merger in the loop leads to UNKNOWN_VALUEs,
and these are then erroneously used to form compound symbolic values
and regions,
On Mon, Feb 01, 2021 at 12:54:50PM -0700, Jeff Law wrote:
> >>> So I see no difference for stage2-gcc/*.o dse1/dse2 with/without the
> >>> patch but counts are _extremely_ small. Statistics:
> >>>
> >>> 70148 dse: local deletions = 0, global deletions = 0
> >>> 32 dse: local deletions = 0,
On 2/1/21 12:47 PM, Richard Biener wrote:
> On February 1, 2021 8:34:35 PM GMT+01:00, Jeff Law wrote:
>>
>> On 1/28/21 1:09 AM, Richard Biener wrote:
>>> On Wed, 27 Jan 2021, Jakub Jelinek wrote:
>>>
On Wed, Jan 27, 2021 at 03:40:38PM +0100, Richard Biener wrote:
> The following avoids
On February 1, 2021 8:34:35 PM GMT+01:00, Jeff Law wrote:
>
>
>On 1/28/21 1:09 AM, Richard Biener wrote:
>> On Wed, 27 Jan 2021, Jakub Jelinek wrote:
>>
>>> On Wed, Jan 27, 2021 at 03:40:38PM +0100, Richard Biener wrote:
The following avoids repeatedly turning VALUE RTXen into
sth useful
On Mon, Feb 01, 2021 at 08:23:18PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Feb 01, 2021 at 01:46:13PM -0500, Ed Smith-Rowland wrote:
> > @@ -0,0 +1,8 @@
> > +// { dg-do compile { target c++23 } }
> > +
> > +#include
> > +#include
> > +
> > +static_assert(std::is_same_v);
> > +static
On 2/1/21 1:46 PM, Ed Smith-Rowland wrote:
On 2/1/21 10:33 AM, Jason Merrill wrote:
On 1/30/21 6:22 PM, Ed Smith-Rowland wrote:
On 1/27/21 3:32 PM, Jakub Jelinek wrote:
On Sun, Oct 21, 2018 at 04:39:30PM -0400, Ed Smith-Rowland wrote:
This patch implements C++2a proposal P0330R2 Literal Suffix
On 1/28/21 1:09 AM, Richard Biener wrote:
> On Wed, 27 Jan 2021, Jakub Jelinek wrote:
>
>> On Wed, Jan 27, 2021 at 03:40:38PM +0100, Richard Biener wrote:
>>> The following avoids repeatedly turning VALUE RTXen into
>>> sth useful and re-applying a constant offset through get_addr
>>> via DSE ch
Okay.
Thanks, David
On Mon, Feb 1, 2021 at 2:17 PM wrote:
>
> From: Aaron Sawdey
>
> In a previous fusion-combine patch for rs6000, Segher had asked me to
> comment out the automatic regeneration of fusion.md. And more recently
> Edelsohn pointed out that gcc_update needed to fix the timestamp
On Mon, Feb 01, 2021 at 01:46:13PM -0500, Ed Smith-Rowland wrote:
> @@ -0,0 +1,8 @@
> +// { dg-do compile { target c++23 } }
> +
> +#include
> +#include
> +
> +static_assert(std::is_same_v);
> +static_assert(std::is_same_v);
Shouldn't this be std::make_signed::type instead of std::ptrdiff_t
> +
From: Aaron Sawdey
In a previous fusion-combine patch for rs6000, Segher had asked me to
comment out the automatic regeneration of fusion.md. And more recently
Edelsohn pointed out that gcc_update needed to fix the timestamp of
fusion.md so it didn't get unnecessarily regenerated.
OK for trunk i
Hi, Richard,
I have adjusted SRA phase to split calls to DEFERRED_INIT per you suggestion.
And now the routine “bump_map” in 511.povray is like following:
...
# DEBUG BEGIN_STMT
xcoor = 0.0;
ycoor = 0.0;
# DEBUG BEGIN_STMT
index = .DEFERRED_INIT (index, 2);
index2 = .DEFERRED_INIT (in
On 01/02/21 19:30 +0100, François Dumont via Libstdc++ wrote:
On 01/02/21 6:43 pm, Jonathan Wakely wrote:
On 31/01/21 16:59 +0100, François Dumont via Libstdc++ wrote:
After the debug issue has been fixed in PR 98466 the problem was
not in the debug iterator implementation itself but in the deq
On 2/1/21 10:33 AM, Jason Merrill wrote:
On 1/30/21 6:22 PM, Ed Smith-Rowland wrote:
On 1/27/21 3:32 PM, Jakub Jelinek wrote:
On Sun, Oct 21, 2018 at 04:39:30PM -0400, Ed Smith-Rowland wrote:
This patch implements C++2a proposal P0330R2 Literal Suffixes for
ptrdiff_t
and size_t*. It's not off
At the moment some iterators like std::list<>::end() looks like
value-init iterators once detached.
I think using an iterator in such a state is wrong so here is a patch to
detect this.
This patch also add a new iterator state: singular (value-initialized)
Example of the output of the forwar
On 01.02.21 19:28, Paul Richard Thomas wrote:
I have attached a memory leak free version of the testcase. I have
asked for Thomas's help to use frontend-passes.c tools to do the same
for compound constructors with allocatable components. My attempts to
do the job in other ways have failed totall
On 01/02/21 6:43 pm, Jonathan Wakely wrote:
On 31/01/21 16:59 +0100, François Dumont via Libstdc++ wrote:
After the debug issue has been fixed in PR 98466 the problem was not
in the debug iterator implementation itself but in the deque iterator
operator- implementation.
libstdc++: Make de
Hi Tobias,
I have attached a memory leak free version of the testcase. I have asked
for Thomas's help to use frontend-passes.c tools to do the same for
compound constructors with allocatable components. My attempts to do the
job in other ways have failed totally.
Cheers
Paul
On Fri, 29 Jan 202
Hi Richard(s),
I'm just looking to see if I'm going about this the right way, based on the
discussion we had on IRC. I've managed to hack something together, I've
attached a (very) WIP patch which gives the correct codegen for the testcase in
question (https://gcc.gnu.org/bugzilla/show_bug.cgi?
On 31/01/21 16:59 +0100, François Dumont via Libstdc++ wrote:
After the debug issue has been fixed in PR 98466 the problem was not
in the debug iterator implementation itself but in the deque iterator
operator- implementation.
libstdc++: Make deque iterator operator- usable with value-init
On 2/1/21 9:27 AM, Jakub Jelinek wrote:
On Mon, Feb 01, 2021 at 09:11:20AM -0700, Martin Sebor via Gcc-patches wrote:
Because free_lang_data only frees anything when LTO is enabled and
we want these trees cleared regardless to keep them from getting
clobbered during gimplification, this change a
On Mon, Feb 01, 2021 at 09:11:20AM -0700, Martin Sebor via Gcc-patches wrote:
> > > > Because free_lang_data only frees anything when LTO is enabled and
> > > > we want these trees cleared regardless to keep them from getting
> > > > clobbered during gimplification, this change also modifies the pa
I have pushed the tree.h comments in g:6a2053773b8. I will wait
for an approval of the changes to the manual.
On 1/27/21 5:54 PM, Martin Sebor wrote:
Attached is an updated patch for both tree.h and the internals manual
documenting the most important BLOCK_ macros and what they represent.
On 1
On 1/28/21 1:59 PM, Martin Sebor wrote:
On 1/28/21 1:31 AM, Richard Biener wrote:
On Thu, Jan 28, 2021 at 12:08 AM Martin Sebor via Gcc-patches
wrote:
Attached is another attempt to fix the problem caused by allowing
front-end trees representing nontrivial VLA bound expressions to
stay in att
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2011.xml: Update std::call_once
status.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise. Update
std::from_chars and std::to_chars status. Fix formatting.
Hi all,
The vmovl_high_* intrinsics map down to the SXTL2/UXTL2 instructions that
already have appropriately-named
patterns and expanders, so it's straightforward to wire them up.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill
gcc/ChangeLog:
* confi
Hi all,
Another simple set of intrinsic moved to builtins in the straightforward way.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (sabdl, uabdl): Define
builtins.
* config/a
The warning reported in PR 98835 is a true positive but there was
no test for this aspect of it. I have added one on the attached
diff.
Martin
commit c2f8e378d64f65645e5f9c41a8221ca102c71208
Author: Martin Sebor
Date: Mon Feb 1 08:42:58 2021 -0700
Verify a warning for a class with a ref-
On 1/30/21 6:22 PM, Ed Smith-Rowland wrote:
On 1/27/21 3:32 PM, Jakub Jelinek wrote:
On Sun, Oct 21, 2018 at 04:39:30PM -0400, Ed Smith-Rowland wrote:
This patch implements C++2a proposal P0330R2 Literal Suffixes for
ptrdiff_t
and size_t*. It's not official yet but looks very likely to pass.
On 2/1/21 7:48 AM, Patrick Palka wrote:
On Fri, 29 Jan 2021, Jason Merrill wrote:
On 1/29/21 12:28 PM, Patrick Palka wrote:
In this testcase we're crash during constexpr evaluation of the
ARRAY_REF b[0] as part of folding the lambda's by-copy capture of b
(which is encoded as a VEC_INIT_EXPR).
On 2/1/21 10:07 AM, Marek Polacek wrote:
On Fri, Jan 29, 2021 at 10:31:15PM -0500, Jason Merrill via Gcc-patches wrote:
On 1/29/21 6:28 PM, Marek Polacek wrote:
On Fri, Jan 29, 2021 at 06:18:35PM -0500, Jason Merrill via Gcc-patches wrote:
On 1/29/21 5:52 PM, Marek Polacek wrote:
On Fri, Jan
On Fri, Jan 29, 2021 at 10:31:15PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/29/21 6:28 PM, Marek Polacek wrote:
> > On Fri, Jan 29, 2021 at 06:18:35PM -0500, Jason Merrill via Gcc-patches
> > wrote:
> > > On 1/29/21 5:52 PM, Marek Polacek wrote:
> > > > On Fri, Jan 29, 2021 at 04:23:14PM
This fixes accounting issues with using auto_vec and auto_bitmap
for -fmem-report.
Bootstrap running on x86_64-unknown-linux-gnu, with and without
--enable-gather-detailed-mem-stats
2021-02-01 Richard Biener
* vec.h (auto_vec::auto_vec): Add memory stat parameters
and pass the
template_args_equal has handled dependent alias specializations for a while,
but in this testcase the actual template argument is a SCOPE_REF, so we
called cp_tree_equal, which doesn't handle aliases specially when we get to
them.
This patch generalizes this by setting a flag so structural_comptyp
We correctly accept this testcase ever since r10-5143.
gcc/testsuite/ChangeLog:
PR c++/84494
* g++.dg/cpp1y/constexpr-84494.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/constexpr-84494.C | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cp
> -Original Message-
> From: Tamar Christina
> Sent: 01 February 2021 12:39
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
> ; Richard Sandiford
>
> Subject: [PATCH]AArch64 Change canonization of smlal and smlsl in order to
> be able to o
> -Original Message-
> From: Jonathan Wright
> Sent: 01 February 2021 12:35
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH] testsuite: aarch64: Add tests for vmlXl_high intrinsics
>
> Hi,
>
> As subject, this patch adds tests for vmlal_high_* and vmlsl_high_*
>
On Montag, 1. Februar 2021 13:21:33 CET Rainer Orth wrote:
> Two simd tests FAIL on Solaris, both SPARC and x86:
>
> FAIL: experimental/simd/standard_abi_usable.cc -msse2 -O2 -Wno-psabi (test
> for excess errors) FAIL: experimental/simd/standard_abi_usable_2.cc -msse2
> -O2 -Wno-psabi (test for ex
Ok.
Thanks for doing this.
Kyrill
From: Jonathan Wright
Sent: 01 February 2021 11:45
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: Re: [PATCH] testsuite: aarch64: Add tests for vmull_high intrinsics
Woops, didn't attach the diff. Here we go.
Thanks,
Jonathan
On Fri, 29 Jan 2021, Jason Merrill wrote:
> On 1/29/21 12:28 PM, Patrick Palka wrote:
> > In this testcase we're crash during constexpr evaluation of the
> > ARRAY_REF b[0] as part of folding the lambda's by-copy capture of b
> > (which is encoded as a VEC_INIT_EXPR). Since A's default constructo
Hi Nathan,
> As Rainer pointed out, there were some regressions in the library tests.
> That's because we didn't build the correct ehspec for __cxa_atexit.
> This adds that, but also, I realize we can use the 'hidden' flag on
> pushdecl to make this lazy-builtin not visible to user name lookup
>
Hi All,
g:87301e3956d44ad45e384a8eb16c79029d20213a and
g:ee4c4fe289e768d3c6b6651c8bfa3fdf458934f4 changed the intrinsics to be
proper RTL but accidentally ended up creating a regression because of the
ordering in the RTL pattern.
The existing RTL that combine should try to match to remove the vec
Hi,
As subject, this patch adds tests for vmlal_high_* and vmlsl_high_*
Neon intrinsics. Since these intrinsics are only supported for AArch64,
these tests are restricted to only run on AArch64 targets.
Ok for master?
Thanks,
Jonathan
---
gcc/testsuite/ChangeLog:
2021-01-31 Jonathan Wright
Two simd tests FAIL on Solaris, both SPARC and x86:
FAIL: experimental/simd/standard_abi_usable.cc -msse2 -O2 -Wno-psabi (test for
excess errors)
FAIL: experimental/simd/standard_abi_usable_2.cc -msse2 -O2 -Wno-psabi (test
for excess errors)
This happens because the simd headers use identifiers
Woops, didn't attach the diff. Here we go.
Thanks,
Jonathan
From: Jonathan Wright
Sent: 01 February 2021 11:42
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH] testsuite: aarch64: Add tests for vmull_high intrinsics
Hi,
As subject, this patch add
Hi,
As subject, this patch adds tests for vmull_high_* Neon intrinsics. Since
these intrinsics are only supported for AArch64, these tests are
restricted to only run on AArch64 targets.
Ok for master?
Thanks,
Jonathan
---
gcc/testsuite/ChangeLog:
2021-01-29 Jonathan Wright
* gcc.t
> From: Sergei Trofimovich
>
> Before the change RVO gimple statements were treated as local
> stores by modres analysis. But in practice RVO escapes target.
>
> 2021-01-30 Sergei Trofimovich
>
> gcc/ChangeLog:
>
> PR tree-optimization/98499
> * ipa-modref.c: treat RVO conservat
On Mon, Feb 1, 2021 at 6:10 PM Jakub Jelinek wrote:
>
> On Mon, Feb 01, 2021 at 05:57:28PM +0800, Kito Cheng wrote:
> > > > - Check `TO` mode is not BLMmode before call store_expr, calling
> > > > store_expr
> > > >with BLKmode will cause ICE.
> > >
> > > How do you end up with a SUBREG_PROM
On Mittwoch, 27. Januar 2021 21:42:50 CET Matthias Kretz wrote:
> --- a/libstdc++-v3/include/experimental/bits/simd.h
> +++ b/libstdc++-v3/include/experimental/bits/simd.h
> @@ -204,6 +204,27 @@ template
> template
>using _SizeConstant = integral_constant;
>
> +namespace __detail {
> + str
On Mon, Feb 01, 2021 at 05:57:28PM +0800, Kito Cheng wrote:
> > > - Check `TO` mode is not BLMmode before call store_expr, calling
> > > store_expr
> > >with BLKmode will cause ICE.
> >
> > How do you end up with a SUBREG_PROMOTED* of something that has bitsize of 0
> > (GET_MODE_BITSIZE of B
> > - Check `TO` mode is not BLMmode before call store_expr, calling store_expr
> >with BLKmode will cause ICE.
>
> How do you end up with a SUBREG_PROMOTED* of something that has bitsize of 0
> (GET_MODE_BITSIZE of BLKmode is 0, right)?
to_rtx is already having a mode other than BLKmode in t
On Mon, Feb 01, 2021 at 05:38:46PM +0800, Kito Cheng wrote:
> - Check `TO` mode is not BLMmode before call store_expr, calling store_expr
>with BLKmode will cause ICE.
How do you end up with a SUBREG_PROMOTED* of something that has bitsize of 0
(GET_MODE_BITSIZE of BLKmode is 0, right)?
That
- Check `TO` mode is not BLMmode before call store_expr, calling store_expr
with BLKmode will cause ICE.
- Verified with riscv64, x86_64 and aarch64, no introduce new regression.
Note: Those logic was introduced by 3e60ddeb8220ed388819bb3f14e8caa9309fd3c2,
so I cc Jakub for reivew.
gc
Pushed, thanks :)
On Mon, Feb 1, 2021 at 4:58 PM Xing GUO wrote:
>
> Hi,
>
> I've reproduced the failure. It's because my gcc is configured as a
> bare-metal toolchain and built with binutils that supports RISC-V
> attribute. That is to say, my gcc emits RISC-V attributes by default.
> Below is t
> -Original Message-
> From: Christophe Lyon
> Sent: 29 January 2021 18:18
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] arm: Auto-vectorization for MVE: vorn
>
> On Fri, 29 Jan 2021 at 16:03, Kyrylo Tkachov
> wrote:
> >
> >
> >
> > > -Original Message-
> -Original Message-
> From: Christophe Lyon
> Sent: 29 January 2021 18:26
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: Remove testing of saturation cumulative QC
> bit
>
> On Tue, 19 Jan 2021 at 18:31, Kyrylo Tkachov via Gcc-patches
> wrote:
> >
Hi,
I've reproduced the failure. It's because my gcc is configured as a
bare-metal toolchain and built with binutils that supports RISC-V
attribute. That is to say, my gcc emits RISC-V attributes by default.
Below is the patch that should fix the failure. Sorry for the
inconvenience.
diff --git a
This sets DF_RD_PRUNE_DEAD_DEFS like all other uses of the UD/DU
chain problems which makes the RD problem consume a lot less memory.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-02-01 Richard Biener
PR rtl-optimization/98863
* config/i386/i386-features.c
76 matches
Mail list logo
