While looking at template instantiation tracing, I noticed that we were
frequently looking up a particular class template instance while
instantiating it. This patch shortcuts that lookup, and speeds up compiling
stdc++.h with my (checking/unoptimized) compiler by about 3%.
Tested
Trivial change, committed to trunk.
[PATCH 1/1] Fix a typo in an AutoFDO error string
gcc/ChangeLog:
* auto-profile.c (read_profile): fix a typo in an error string
---
gcc/auto-profile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/auto-profile.c
Hi!
On Fri, Jun 11, 2021 at 02:19:40PM -0700, Carl Love wrote:
> The gcc test suite compiles and attempts to run the check-builtin-
> vec_rlnm-runnable.c test on Power 8 platforms. The test should only be
> run on Power 9 and newer platforms. The attached patch fixes the
> target for the
On Fri, Jun 11, 2021 at 10:35:58PM +0200, Jakub Jelinek wrote:
> > But I also agree that GCC shouldn't warn here.
>
> We could do that by using a wrapper around handle_unused_attribute
> for the maybe_unused attribute, that way warn on unused attribute on
> FIELD_DECLs, but not for maybe_unused
GCC maintainers:
The gcc test suite compiles and attempts to run the check-builtin-
vec_rlnm-runnable.c test on Power 8 platforms. The test should only be
run on Power 9 and newer platforms. The attached patch fixes the
target for the executable test so it only runs on Power 9 and newer
Add red_zone_used to machine_function to track if red zone is used.
When expanding function prologue, set red_zone_used to true if red
zone is used.
gcc/
PR target/pr101023
* config/i386/i386.c (ix86_expand_prologue): Set red_zone_used
to true if red zone is used.
David: this one wasn't reviewed yet by you, so you can review it.
Le jeudi 20 mai 2021 à 21:27 -0400, Antoni Boucher a écrit :
> Hi.
>
> I made this patch to set an arbitrary value to a global variable.
>
> This patch suffers from the same issue as inline assembly
>
On Thu, Jun 10, 2021 at 03:11:08PM +0800, Xionghu Luo wrote:
> On 2021/6/10 00:24, Segher Boessenkool wrote:
> >>"!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed &&
> >> !TARGET_P9_VECTOR
> >> && !altivec_indexed_or_indirect_operand (operands[0], mode)"
> >>[(const_int 0)]
> >> {
(PING. In case you missed this. Sorry, forgot to CC you.)
Am Montag, den 24.05.2021, 08:05 +0200 schrieb Martin Uecker:
> Hi Joseph,
>
> I found some time to update this patch. The only real change
> of the patch is the qualifier in the conditional expression for
> pointer to arrays in C2X. All
On 4/29/21 7:48 AM, Patrick Palka wrote:
On Wed, 28 Apr 2021, Jason Merrill wrote:
On 4/28/21 2:24 PM, Patrick Palka wrote:
This makes tsubst_arg_types substitute into a function's parameter types
in left-to-right order instead of right-to-left order, in accordance with
DR 1227.
Bootstrapped
>
> Jeff et. al.
>
> > On 9 Jun 2021, at 17:23, Jeff Law via Gcc-patches
> > wrote:
> > On 5/25/2021 2:23 PM, Paul Eggert wrote:
> >> The GCC manual's documentation of -fno-trampolines was apparently
> >> written from an Ada point of view. However, when I read it I
> >> understandably
Hi!
On Fri, Jun 11, 2021 at 01:56:58PM -0500, Aaron Sawdey wrote:
> These tests have become unstable and SMS either succeeds or doesn't
> depending on things like changes in instruction latency. Removing
> the scan-rtl-dump-times checks for powerpc*-*-*.
>
> If bootstrap/regtest is passes, ok
These tests have become unstable and SMS either succeeds or doesn't
depending on things like changes in instruction latency. Removing
the scan-rtl-dump-times checks for powerpc*-*-*.
If bootstrap/regtest is passes, ok for trunk and backport to 11?
Thanks!
Aaron
gcc/testsuite
*
> On Jun 11, 2021, at 11:50 AM, Joseph Myers wrote:
>
> ...
>
> "make" at top level should build all the info manuals and man pages, as at
> present (if a suitable Sphinx version is installed), and "make install"
> should install them, in the same directories as at present.
>
> "make
*PING*
BTW this patch also addresses PR95501, so I'll update the Changelog.
Thanks,
Harald
> Gesendet: Freitag, 04. Juni 2021 um 23:12 Uhr
> Von: "Harald Anlauf"
> An: "fortran" , "gcc-patches"
> Betreff: [PATCH] PR fortran/95502 - ICE in gfc_check_do_variable, at
> fortran/parse.c:4446
>
>
Hi,
This patch improves semantic passes in the front-end around the
`foreach' and `static foreach' statements to be more resilient to
compiling in a minimal D runtime environment. Checking of the index
type has been improved as well so now there won't be needless compiler
errors when using 8 or
In C++23 there is a basic_string_view(Range&&) constructor, which is
constrained to take a range (specifically, a contiguous_range). When the
filesystem::path comparison operators call lhs.compare(rhs) the overload
taking a string_view is considered, which means checking whether path
satisfies the
On Thu, 2021-05-27 at 21:22 -0400, Antoni Boucher wrote:
> Here's the patch with the condition removed.
> I believe everything is now fixed.
> Thanks!
Thanks; this looks good to me. Is this the latest version of the
patch; would you like me to apply it?
Dave
>
> Le jeudi 27 mai 2021 à 18:21
On Fri, 11 Jun 2021, Tom Honermann via Gcc-patches wrote:
> The option is needed because it impacts core language backward compatibility
> (for both C and C++, the type of u8 string literals; for C++, the type of u8
> character literals and the new char8_t fundamental type).
Lots of new features
On Fri, Jun 11, 2021 at 01:04:09PM +0200, Richard Biener wrote:
> On Tue, 8 Jun 2021, Kees Cook wrote:
>
> > On Tue, Jun 08, 2021 at 09:41:38AM +0200, Richard Biener wrote:
> > > On Mon, 7 Jun 2021, Qing Zhao wrote:
> > >
> > > > Hi,
> > > >
> > > > > On Jun 7, 2021, at 2:53 AM, Richard Biener
On Fri, 11 Jun 2021, Jakub Jelinek via Gcc-patches wrote:
> gcc/c/
> * c-typeck.c (c_mark_addressable): Diagnose trying to make
> bit-fields addressable.
The C front-end changes are OK.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 2021-06-10 at 17:26 -0600, Martin Sebor wrote:
> This diff introduces the diagnostic infrastructure changes to support
> controlling warnings at any call site in the inlining stack and
> printing
> the inlining context without the %K and %G directives.
Thanks for working on this, looks
On Jun 11, 2021, at 10:49 AM, Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On Jun 11, 2021, at 6:12 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
On Thu, 10 Jun 2021, Qing Zhao wrote:
Hi, Richard,
I need more discussion on the following comments you raised:
On Fri, Jun 11, 2021 at 12:20:48PM -0400, Tom Honermann wrote:
> I'm open to whatever signaling mechanism would be preferred. It took me a
> while to settle on _CHAR8_T_SOURCE as the mechanism to propose as I didn't
> find much for other precedents.
>
> I agree that having _CHAR8_T_SOURCE be
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 June 2021 17:14
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
>
> Subject: [GCC][PATCH] arm: Fix polymorphic variants failing with undefined
> reference to `__ARM_undef` error.
>
> Hi,
>
> This
Christophe Lyon writes:
> Thanks for the feedback. How about v2 attached?
> Do you want me to merge neon_vec_unpack and
> mve_vec_unpack and only have different assembly?
> if (TARGET_HAVE_MVE)
> return "vmovlb.%# %q0, %q1";
> else
> return "vmovlb.%# %q0, %q1";
I think it'd be better to
On Fri, Jun 11, 2021 at 03:49:02PM +, Qing Zhao wrote:
>
> On Jun 11, 2021, at 6:12 AM, Richard Biener wrote:
> > [...]
> >
> > The main point is that you need to avoid building the explicit initializer
> > only to have it consumed by assignment expansion. If you want to keep
> > all the
On 6/11/21 12:01 PM, Jakub Jelinek wrote:
On Fri, Jun 11, 2021 at 11:52:41AM -0400, Tom Honermann via Gcc-patches wrote:
On 6/7/21 5:11 PM, Joseph Myers wrote:
On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote:
When -fchar8_t support is enabled for non-C++ modes, the _CHAR8_T_SOURCE
On Fri, Jun 11, 2021 at 11:52:41AM -0400, Tom Honermann via Gcc-patches wrote:
> On 6/7/21 5:11 PM, Joseph Myers wrote:
> > On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote:
> >
> > > When -fchar8_t support is enabled for non-C++ modes, the _CHAR8_T_SOURCE
> > > macro
> > > is predefined.
On 6/7/21 5:12 PM, Joseph Myers wrote:
Also, it seems odd to add a new field to cpp_options without any code in
libcpp that uses the value of that field.
Ah, thank you. That appears to be leftover code from prior
experimentation and I failed to identify it as such when preparing the
patch.
On 6/7/21 5:11 PM, Joseph Myers wrote:
On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote:
When -fchar8_t support is enabled for non-C++ modes, the _CHAR8_T_SOURCE macro
is predefined. This is the mechanism proposed to glibc to opt-in to
declarations of the char8_t typedef and c8rtomb
On Fri, 11 Jun 2021, Martin Liška wrote:
> > Where languages have their own manuals, I think it's more appropriate for
> > those to go under the language-specific directories.
>
> So it will require the following folder structure:
>
> $gccroot/gcc/doc/gcc - for GCC documentation
>
> On Jun 11, 2021, at 6:12 AM, Richard Biener wrote:
>
> On Thu, 10 Jun 2021, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> I need more discussion on the following comments you raised:
>>
>>> On May 26, 2021, at 6:18 AM, Richard Biener wrote:
>>>
>>> +/* Expand the IFN_DEFERRED_INIT function
On 6/7/21 5:03 PM, Joseph Myers wrote:
On Sun, 6 Jun 2021, Tom Honermann via Gcc-patches wrote:
These changes do not impact default gcc behavior. The existing -fchar8_t
option is extended to C compilation to enable the N2653 changes, and
-fno-char8_t is extended to explicitly disable them.
On Fri, 11 Jun 2021 at 12:20, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > In the meantime, I tried to make some progress, and looked at how
> > things work on aarch64.
> >
> > This led me to define (in mve.md):
> >
> > (define_insn "@mve_vec_pack_trunc_lo_"
> > [(set
On 6/11/21 10:50 AM, Jakub Jelinek wrote:
On Wed, Jun 02, 2021 at 12:14:51PM -0400, Jason Merrill wrote:
On 6/2/21 11:25 AM, Jakub Jelinek wrote:
On Wed, Jun 02, 2021 at 11:09:45AM -0400, Jason Merrill wrote:
On 6/2/21 3:59 AM, Jakub Jelinek wrote:
if (!allows_reg &&
On Wed, Jun 02, 2021 at 12:14:51PM -0400, Jason Merrill wrote:
> On 6/2/21 11:25 AM, Jakub Jelinek wrote:
> > On Wed, Jun 02, 2021 at 11:09:45AM -0400, Jason Merrill wrote:
> > > On 6/2/21 3:59 AM, Jakub Jelinek wrote:
> > > > if (!allows_reg && !cxx_mark_addressable (*op))
> > > >
On 6/11/21 7:10 AM, Christophe Lyon wrote:
On Fri, 11 Jun 2021 at 09:53, Christophe Lyon
wrote:
On Fri, 11 Jun 2021 at 01:29, Martin Sebor via Gcc-patches
wrote:
This patch removes the uses of %K from error() calls in the aarch64
and arm back ends. I tested this change only by building a
On 6/11/21 3:58 AM, Richard Sandiford wrote:
Martin Sebor via Gcc-patches writes:
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 7b37e1b602c..7cdc824730c 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13242,13 +13242,8 @@ bounds_check (rtx operand,
On 6/11/21 1:48 AM, Martin Sebor wrote:
On 6/10/21 7:18 AM, Martin Liška wrote:
On 6/10/21 11:07 AM, Martin Liška wrote:
Doing that, one has 2 unique links, that would be needed for get_option_url
function.
Plus, both :option:`-Wfoo` and :option:`-Wno-foo` references are going to work.
And
On 6/10/21 6:49 PM, Joseph Myers wrote:
On Thu, 10 Jun 2021, Martin Liška wrote:
1) Can we organize the new documentation in $gccroot/doc folder
similarly to what I have in texi2rst-generated repo? Would be beneficial
as we can have a single Makefile and shared content will be in a same
depth
On Thu, Apr 29, 2021 at 7:48 AM Patrick Palka wrote:
>
> On Wed, 28 Apr 2021, Jason Merrill wrote:
>
> > On 4/28/21 2:24 PM, Patrick Palka wrote:
> > > This makes tsubst_arg_types substitute into a function's parameter types
> > > in left-to-right order instead of right-to-left order, in
On Fri, Jun 11, 2021 at 04:04:35PM +0200, Thomas Schwinge wrote:
> >From db04d261071eb5691906fd46436032a7db8a0b02 Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge
> Date: Fri, 11 Jun 2021 15:37:33 +0200
> Subject: [PATCH] For 'OMP_CLAUSE' in 'dump_generic_node', dump the whole OMP
> clause chain
Hi!
See attached. OK to push after testing -- or would there ever be a
reason where this is not appropriate?
For example, for 'gcc.dg/gomp/simd-clones-2.c', this changes ("corrects")
the '*.optimized' dump file as follows:
@@ -1,7 +1,7 @@
;; Function addit (addit, funcdef_no=0,
This plugs a hole in store-motion where it fails to perform dependence
checking on conditionally executed but not store-motioned refs.
Bootstrapped on x86_64-unknown-linux-gnu, regtest in progress.
2021-06-11 Richard Biener
PR tree-optimization/101025
* tree-ssa-loop-im.c
While debugging another issue I noticed that the analyzer could fail to
merge nodes for control flow in which one path had called a function
and another path hadn't:
BB
/ \
/\
fn call no fn call
\/
\ /
join BB
The root cause was that the
Hi Segher,
Thanks for the review!
on 2021/6/10 上午4:17, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Dec 16, 2020 at 04:49:49PM +0800, Kewen.Lin wrote:
>> Currently we have the check:
>>
>> if (!insn
>>|| (value && rsp->last_set_table_tick >= label_tick_ebb_start))
>>
On Fri, 11 Jun 2021 at 09:53, Christophe Lyon
wrote:
>
> On Fri, 11 Jun 2021 at 01:29, Martin Sebor via Gcc-patches
> wrote:
> >
> > This patch removes the uses of %K from error() calls in the aarch64
> > and arm back ends. I tested this change only by building a cross-
> > compiler but I can't
On 11/06/2021 14:02, Srinath Parvathaneni via Gcc-patches wrote:
Hi Richard,
I have addressed all your review comments in
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571739.html
in the following patch.
The current CMSE support in the multilib build for "-march=armv8.1-m.main+mve
Hi Richard,
I have addressed all your review comments in
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571739.html
in the following patch.
The current CMSE support in the multilib build for "-march=armv8.1-m.main+mve
-mfloat-abi=hard -mfpu=auto"
is broken as specified in PR99939 and this
On 6/11/21 6:28 AM, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 03:00:54PM -0400, Jason Merrill wrote:
The second is clearer about the fix, the first is clearer about the problem.
Maybe add a fixit to the first error?
Done.
OK, just add a comment then.
OK, just add a comment then.
And
Hi Segher,
on 2021/6/10 下午6:58, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jun 10, 2021 at 05:32:23PM +0800, Kewen.Lin wrote:
>> +/* { dg-do compile { target lp64 } } */
>
> One final thing: what requires lp64 here? Could you try without please?
>
The lp64 is required for lxsi[bh]zx and
This fixes a missing clearing of mismatched lanes from the
fatal fail path in SLP reassoc discovery in the most conservative
way.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2021-06-11 Richard Biener
PR tree-optimization/101028
* tree-vect-slp.c
Hi Richard,
I have addressed all your review comments in
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571739.html
in the following patch.
The current CMSE support in the multilib build for "-march=armv8.1-m.main+mve
-mfloat-abi=hard -mfpu=auto"
is broken as specified in PR99939 and this
On Thu, Jun 10, 2021 at 9:45 PM Roger Sayle wrote:
>
>
> The patch implements a missed optimization enhancement. Under usual
> IEEE rules, x+0.0 can't be simplified to x when x might potentially
> be an IEEE minus zero (-0.0). The current logic in the middle-end
> checks whether the type of x
Since we cannot yet encode the operation in the SLP node itself
but need a representative stmt require an existing one for now
to avoid the need to build a fake GIMPLE stmt.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-06-11 Richard Biener
PR
Hi Bernhard,
Please find attached my latest patch, it includes (hopefully) all your
feedback.
Thank you for comments,
Claudiu
>From 03075b3d9194120d7adb3cdc2aa0f58e3ea9dd1d Mon Sep 17 00:00:00 2001
From: Claudiu Zissulescu
Date: Wed, 21 Oct 2020 16:11:43 +0300
Subject: [PATCH] arc: Add
On Thu, 10 Jun 2021, Qing Zhao wrote:
> Hi, Richard,
>
> I need more discussion on the following comments you raised:
>
> > On May 26, 2021, at 6:18 AM, Richard Biener wrote:
> >
> > +/* Expand the IFN_DEFERRED_INIT function according to its second
> > argument. */
> > +static void
> >
On Tue, 8 Jun 2021, Kees Cook wrote:
> On Tue, Jun 08, 2021 at 09:41:38AM +0200, Richard Biener wrote:
> > On Mon, 7 Jun 2021, Qing Zhao wrote:
> >
> > > Hi,
> > >
> > > > On Jun 7, 2021, at 2:53 AM, Richard Biener wrote:
> > > >
> > > >>
> > > >> To address the above suggestion:
> > > >>
While testing newer patches I found several missing conversions from
__bit_cast to simd_bit_cast in this patch (i.e. where bit casting to / from
fixed_size was sometimes required). Corrected patch attached.
From: Matthias Kretz
The __bit_cast function was a hack to achieve what
On Fri, 11 Jun 2021, Jakub Jelinek wrote:
> Hi!
>
> simplify_relational_operation callees typically return just const0_rtx
> or const_true_rtx and then simplify_relational_operation attempts to fix
> that up if the comparison result has vector mode, or floating mode,
> or punt if it has scalar
Some permutations can be implemented without costly PSHUFB instruction, e.g.:
{ 8,9,10,11,12,13,14,15, 0,1,2,3,4,5,6,7 } with PALIGNR,
{ 0,1,2,3, 4,5,6,7, 4,5,6,7, 12,13,14,15 } with PSHUFD,
{ 0,1, 2,3, 2,3, 6,7, 8,9,10,11,12,13,14,15 } with PSHUFLW and
{ 0,1,2,3,4,5,6,7, 8,9, 10,11, 10,11,
On Thu, Jun 10, 2021 at 03:00:54PM -0400, Jason Merrill wrote:
> The second is clearer about the fix, the first is clearer about the problem.
> Maybe add a fixit to the first error?
Done.
> OK, just add a comment then.
>
> OK, just add a comment then.
And added comments.
> > > > ---
Christophe Lyon writes:
> In the meantime, I tried to make some progress, and looked at how
> things work on aarch64.
>
> This led me to define (in mve.md):
>
> (define_insn "@mve_vec_pack_trunc_lo_"
> [(set (match_operand: 0 "register_operand" "=w")
>(truncate: (match_operand:MVE_5 1
On Fri, 11 Jun 2021 at 11:38, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Tue, 8 Jun 2021 at 14:10, Richard Sandiford
> > wrote:
> >>
> >> Christophe Lyon writes:
> >> > This patch adds vec_unpack_hi_, vec_unpack_lo_,
> >> > vec_pack_trunc_ patterns for MVE.
> >> >
> >> > It
How can we make progress here? I could try to produce some "Tony Tables" of
diagnostic output of my modified stdx::simd. I believe it's a major
productivity boost to see abbreviated / "obfuscated" diagnostics *out-of-the
box* (with the possibility to opt-out). Actually, it already *is* a
Martin Sebor via Gcc-patches writes:
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 7b37e1b602c..7cdc824730c 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -13242,13 +13242,8 @@ bounds_check (rtx operand, HOST_WIDE_INT low,
> HOST_WIDE_INT high,
>
Christophe Lyon writes:
> On Tue, 8 Jun 2021 at 14:10, Richard Sandiford
> wrote:
>>
>> Christophe Lyon writes:
>> > This patch adds vec_unpack_hi_, vec_unpack_lo_,
>> > vec_pack_trunc_ patterns for MVE.
>> >
>> > It does so by moving the unpack patterns from neon.md to
>> > vec-common.md,
On Fri, Jun 11, 2021 at 10:59 AM Jakub Jelinek wrote:
>
> On Fri, Apr 23, 2021 at 12:53:58PM +0800, Hongtao Liu via Gcc-patches wrote:
> > -(define_insn "*vec_concatv4si_0"
> > - [(set (match_operand:V4SI 0 "register_operand" "=v,x")
> > - (vec_concat:V4SI
> > -
This fixes recording of distance vectors in case the DDR has just
constant equal indexes. In that case we expect distance vectors
with zero distances to be recorded which is what was done when
any distance was computed for affine indexes.
Bootstrapped and tested on x86_64-unknown-linux-gnu,
Hi!
simplify_relational_operation callees typically return just const0_rtx
or const_true_rtx and then simplify_relational_operation attempts to fix
that up if the comparison result has vector mode, or floating mode,
or punt if it has scalar mode and vector mode operands (it doesn't know how
On Fri, Apr 23, 2021 at 12:53:58PM +0800, Hongtao Liu via Gcc-patches wrote:
> -(define_insn "*vec_concatv4si_0"
> - [(set (match_operand:V4SI 0 "register_operand" "=v,x")
> - (vec_concat:V4SI
> - (match_operand:V2SI 1 "nonimmediate_operand" "vm,?!*y")
> -
On Fri, 11 Jun 2021 at 01:29, Martin Sebor via Gcc-patches
wrote:
>
> This patch removes the uses of %K from error() calls in the aarch64
> and arm back ends. I tested this change only by building a cross-
> compiler but I can't easily run the tests so I'd appreciate some help
> validating it.
On Fri, Jun 11, 2021 at 6:15 AM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> This should have been done before I started to work on connecting
> PHI-OPT to match-and-simplify to see quickly if we miss anything
> but it is better late than never.
> Anyways there was no statistics
On 6/10/21 5:32 PM, Tobias Burnus wrote:
On 10.06.21 16:46, Martin Liška wrote:
Note that flake8 has "plugins". At openSUSE, I install:
... None of those are available on Ubuntu – I probably should nag doko
or start using my private computer for the tests ...
I support the patch, please
This should preserve the original association order as much as possible
for the initial SLP discovery attempt and also improve consistency.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-06-11 Richard Biener
* tree-vect-slp.c (vect_build_slp_tree_2): Use stablesort
On Thu, 10 Jun 2021, Alexander Monakov wrote:
> On Thu, 10 Jun 2021, Richard Biener wrote:
>
> > This makes it possible to apply GCCs stable sort algorithm to vec<>
> > and also use it with the qsort_r compatible interface.
> >
> > Alex, any comments?
>
> I'm afraid the patch is not correct,
On 10 June 2021 20:52:12 CEST, Harald Anlauf wrote:
>> I think the mpz_set_si args above fit on one line.
>
>That's true.
>
>Since this block is exactly the same as for constant strings,
>which is handled in the first condition, I've thought some more
>and am convinced now that these two can be
78 matches
Mail list logo
