No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1267-g0401957b86fa29.
gcc/ChangeLog:
* selftest.h: Fix the sorting of the various *_cc_tests decls.
---
gcc/selftest.h | 14 +++---
1 file changed, 7 insertions(+)
Hello,
On Thu, May 15 2025, Jan Hubicka wrote:
>> Hi,
>>
>> starting with GCC 15 the order is not unique for any symtab_nodes but
>> m_uid is, I believe we ought to dump the latter in the ipa-clones dump,
>> if only so that people can reliably match entries abou
> Hi,
>
> starting with GCC 15 the order is not unique for any symtab_nodes but
> m_uid is, I believe we ought to dump the latter in the ipa-clones dump,
> if only so that people can reliably match entries about new clones to
> those about removed nodes (if any).
>
> Bo
On Wed, May 14, 2025 at 9:34 PM Andrew Pinski wrote:
>
> This is the followup based on the review at
> https://inbox.sourceware.org/gcc-patches/cafiyyc3xeg75dswaf63zbu5uelpeaeohwgfogavydwouuj7...@mail.gmail.com/
> .
> We should put ADDR_EXPR last instead of just is_gimple_invariant_address ones.
>
d put memory refs first, SSA_NAME second, which is reasonable.
> > >
> > > I'd say since an ADDR_EXPR is always a "value" (not memory), putting it
> > > last makes sense in general, whether invariant or not. Can you test that?
> > > The issue with
This is the followup based on the review at
https://inbox.sourceware.org/gcc-patches/cafiyyc3xeg75dswaf63zbu5uelpeaeohwgfogavydwouuj7...@mail.gmail.com/
.
We should put ADDR_EXPR last instead of just is_gimple_invariant_address ones.
Note a few match patterns needed to be updated for this change b
On Tue, May 13, 2025 at 12:48 AM Andrew Pinski wrote:
>
> This is a small optimization, the reversed order of the walk of
> update_cache_list queue.
> The queue is pushed in Pre-order/NLR, reversing the order will reduce how
> many times we
> need to go through the loop as w
This is a small optimization, the reversed order of the walk of
update_cache_list queue.
The queue is pushed in Pre-order/NLR, reversing the order will reduce how many
times we
need to go through the loop as we update the nodes which might have a link back
to another
one first.
Bootstrapped
"value" (not memory), putting it
> > last makes sense in general, whether invariant or not. Can you test that?
> > The issue with is_gimple_invariant_address is that it walks all handled
> > components.
>
> Coming back to this, I will make a change to put ADDR fir
On Mon, Apr 21, 2025 at 1:42 AM Richard Biener
wrote:
>
> On Thu, Apr 17, 2025 at 7:37 PM Andrew Pinski
> wrote:
> >
> > So unlike constants, address invariants are currently put first if
> > used with a SSA NAME.
> > It would be better if address invariants are consistent with constants
> > and
Hi,
On Wed, Apr 30 2025, Michal Jires wrote:
> On Mon, 2025-04-28 at 16:10:58 +0200, Martin Jambor wrote:
>> Hi,
>>
>> starting with GCC 15 the order is not unique for any symtab_nodes but
>> m_uid is, I believe we ought to dump the latter in the ipa-clones dump,
&g
On Mon, 2025-04-28 at 16:10:58 +0200, Martin Jambor wrote:
> Hi,
>
> starting with GCC 15 the order is not unique for any symtab_nodes but
> m_uid is, I believe we ought to dump the latter in the ipa-clones dump,
> if only so that people can reliably match entries about new cl
Hi,
starting with GCC 15 the order is not unique for any symtab_nodes but
m_uid is, I believe we ought to dump the latter in the ipa-clones dump,
if only so that people can reliably match entries about new clones to
those about removed nodes (if any).
Bootstrapped and tested on x86_64-linux. OK
On Tue, Apr 22, 2025 at 1:06 AM Andrew Pinski wrote:
>
> On Mon, Apr 21, 2025 at 1:42 AM Richard Biener
> wrote:
> >
> > On Thu, Apr 17, 2025 at 7:37 PM Andrew Pinski
> > wrote:
> > >
> > > So unlike constants, address invariants are currently put first if
> > > used with a SSA NAME.
> > > It w
On Mon, Apr 21, 2025 at 1:42 AM Richard Biener
wrote:
>
> On Thu, Apr 17, 2025 at 7:37 PM Andrew Pinski
> wrote:
> >
> > So unlike constants, address invariants are currently put first if
> > used with a SSA NAME.
> > It would be better if address invariants are consistent with constants
> > and
On Thu, Apr 17, 2025 at 7:37 PM Andrew Pinski wrote:
>
> So unlike constants, address invariants are currently put first if
> used with a SSA NAME.
> It would be better if address invariants are consistent with constants
> and this patch changes that.
> gcc.dg/tree-ssa/pr118902-1.c is an example w
On 4/17/25 11:35 AM, Andrew Pinski wrote:
So unlike constants, address invariants are currently put first if
used with a SSA NAME.
It would be better if address invariants are consistent with constants
and this patch changes that.
gcc.dg/tree-ssa/pr118902-1.c is an example where this canonical
So unlike constants, address invariants are currently put first if
used with a SSA NAME.
It would be better if address invariants are consistent with constants
and this patch changes that.
gcc.dg/tree-ssa/pr118902-1.c is an example where this canonicalization
can help. In it if `p` variable was a g
On 4/15/25 1:56 PM, Richard Sandiford wrote:
Tejas Belagod writes:
The operand order to gen_vcond_mask call in the vec_extract pattern is wrong.
Fix the order where predicate is operand 3.
Tested and bootstrapped on aarch64-linux-gnu. OK for trunk?
gcc/ChangeLog
* config/aarch64
On 4/14/25 7:44 PM, Kyrylo Tkachov wrote:
Hi Tejas,
On 14 Apr 2025, at 16:04, Tejas Belagod wrote:
The operand order to gen_vcond_mask call in the vec_extract pattern is wrong.
Fix the order where predicate is operand 3.
Tested and bootstrapped on aarch64-linux-gnu. OK for trunk?
gcc
Tejas Belagod writes:
> The operand order to gen_vcond_mask call in the vec_extract pattern is wrong.
> Fix the order where predicate is operand 3.
>
> Tested and bootstrapped on aarch64-linux-gnu. OK for trunk?
>
> gcc/ChangeLog
>
> * config/aarch64/aarch64-s
Hi Tejas,
> On 14 Apr 2025, at 16:04, Tejas Belagod wrote:
>
> The operand order to gen_vcond_mask call in the vec_extract pattern is wrong.
> Fix the order where predicate is operand 3.
>
> Tested and bootstrapped on aarch64-linux-gnu. OK for trunk?
>
> gcc/ChangeL
The operand order to gen_vcond_mask call in the vec_extract pattern is wrong.
Fix the order where predicate is operand 3.
Tested and bootstrapped on aarch64-linux-gnu. OK for trunk?
gcc/ChangeLog
* config/aarch64/aarch64-sve.md (vec_extract): Fix operand
order to gen_vcond_mask_
gcc/ChangeLog
PR c++/106618
* doc/invoke.texi (Option Summary): Remove -fargs-in-order, add
-fstrong-eval-order.
(C++ Dialect Options): Explicitly document that -fstrong-eval-order
takes an optional argument and what the choices are. Generalize
This patch introduces the TARGET_REJECT_FUNCTION_CLONE_VERSION hook
which is used to determine if a target_clones version string parses.
If true is returned, a warning is emitted and from then on the version
is ignored.
This is as specified in the Arm C Language Extension. The purpose of this
is
(Seems patch not sent out, resending)
Hi all,
The order of i386.opt.urls need to be the same as i386.opt according to
auto builder. I thought the urls file is a dict but actually not.
Commit as obvious.
Thx,
Haochen
gcc/ChangeLog:
* config/i386/i386.opt.urls: Adjust the order for
, init);
/* Output init aliases even with -fno-extern-tls-init. */
@@ -5081,6 +5182,7 @@ handle_tls_init (void)
gcc_assert (alias != NULL);
}
}
+ decomp_finalize_var_list (sl, save_stmts_are_full_exprs_p);
finish_then_clause (if_stmt);
finish_if_stmt
static_initialization_or_destruction (/*initp=*/true, var, init);
/* Output init aliases even with -fno-extern-tls-init. */
@@ -5081,6 +5182,7 @@ handle_tls_init (void)
gcc_assert (alias != NULL);
}
}
+ decomp_finalize_var_list (sl, save_stmts_are_full_exprs_p
On 1/25/25 4:12 AM, Jakub Jelinek wrote:
On Fri, Jan 24, 2025 at 07:07:15PM -0500, Jason Merrill wrote:
Hypothetically, but those cases are just either error or DECL_EXTERNAL. In
the error case we're failing anyway; in the external case all the
base/nonbase for a particular structured binding de
On Fri, Jan 24, 2025 at 07:07:15PM -0500, Jason Merrill wrote:
> Hypothetically, but those cases are just either error or DECL_EXTERNAL. In
> the error case we're failing anyway; in the external case all the
> base/nonbase for a particular structured binding declaration should be
> consistent.
So
On 1/23/25 9:47 AM, Jakub Jelinek wrote:
On Wed, Jan 22, 2025 at 04:19:38PM -0500, Jason Merrill wrote:
@@ -4482,6 +4536,7 @@ emit_partial_init_fini_fn (bool initp, u
/* Do one initialization or destruction. */
one_static_initialization_or_destruction (initp, decl, init);
if (STATIC_INIT_DECOMP_BASE_P (t)
&& result != NULL_TREE
&& STATIC_INIT_DECOMP_NONBASE_P (result))
clear_nonbase = true;
sets it to true if we are going to process a base entry and the last
entry we've processed was nonbase. The {static,tls}_aggrega
On 1/3/25 6:39 AM, Jakub Jelinek wrote:
On Thu, Dec 19, 2024 at 11:56:10AM -0500, Jason Merrill wrote:
Looks right.
So, I've tried to construct a testcase, but turns out modules.cc just
doesn't handle structured bindings at namespace scope at all, so it is
premature to try to get the ordering
id)
gcc_assert (alias != NULL);
}
}
+ decomp_finalize_var_list (sl, save_stmts_are_full_exprs_p);
finish_then_clause (if_stmt);
finish_if_stmt (if_stmt);
--- gcc/testsuite/g++.dg/DRs/dr2867-5.C.jj 2024-09-09 14:09:22.181185411
+0200
+++ gcc/testsuite/g++.dg/DRs/d
nux and i686-linux, ok for trunk?
OK.
No patch for the namespace scope structured bindings yet, will work on that
soon.
2024-09-05 Jakub Jelinek
PR c++/115769
* decl.cc: Partially implement CWG 2867 - Order of initialization
for structured bindings.
(cp_fini
On Mon, Dec 2, 2024 at 9:05 PM Richard Biener wrote:
>
> The PR uncovers unchecked constraints on the ability to code-generate
> with SLP but also latent issues with regard to stmt order checking
> since loop (early-break) and BB (for quite some time) vectorization
> are no longe
On Fri, Jan 03, 2025 at 12:39:08PM +0100, Jakub Jelinek wrote:
> Should be all !DECL_NAME (decl) MK_unique? Or just
> DECL_DECOMPOSITION_P (decl) && !DECL_NAME (decl)?
> Structured bindings can't be redeclared, so I guess they are unique.
With
--- gcc/cp/module.cc.jj 2025-01-02 11:47:10.367499411
{
if (RECORD_OR_UNION_TYPE_P (ctx))
mk = MK_field;
--- gcc/testsuite/g++.dg/modules/dr2867-1_a.H.jj2025-01-03
12:05:52.601093929 +0100
+++ gcc/testsuite/g++.dg/modules/dr2867-1_a.H 2025-01-03 12:13:23.746737536
+0100
@@ -0,0 +1,88 @@
+// CWG2867 - Order of
akes it even harder.
We'd need to ensure that we stream either all the decls coming from a
namespace scope structured binding, or none of them, in the right order
(no idea if that is already guaranteed somehow or would need to be extra
ensured and where).
Then probably write_va
> we read in the variables. Can we set the appropriate flags at that time?
I know we don't stream *_aggregates, that makes it even harder.
We'd need to ensure that we stream either all the decls coming from a
namespace scope structured binding, or none of them, in the right order
(no
On 9/11/24 8:26 AM, Jakub Jelinek wrote:
On Wed, Sep 11, 2024 at 10:16:18PM +1000, Nathaniel Shead wrote:
In the header_module_p case, it is valid to have internal linkage
definitions (e.g. in an anonymous namespace), but in that case the
{static,tls}_aggregates lists should still be in place to
is change.
> Honza
Applied suggested change.
This patch adds remapping of node order for each lto partition.
Resulting order conserves relative order inside partition, but
is independent of outside symbols. So if lto partition contains
identical set of symbols, their r
The PR uncovers unchecked constraints on the ability to code-generate
with SLP but also latent issues with regard to stmt order checking
since loop (early-break) and BB (for quite some time) vectorization
are no longer constraint to single-BBs. In particular get_later_stmt
simply compares UIDs of
> This patch adds remapping of node order for each lto partition.
> Resulting order conserves relative order inside partition, but
> is independent of outside symbols. So if lto partition contains
> identical set of symbols, their remapped order will be stable
> between compila
> Symbol order corresponds to the order in source code.
> For clones their order is currently arbitrarily chosen as max order++
> But it would be more consistent with original purpose to choose clones
> order to be shared with the original node order.
> This stabilizes clone order
> ipa_strub_set_mode_for_new_functions uses node order as unique ever
> increasing identifier. This is better satisfied with uid.
> Order loses uniqueness with following patches.
>
> gcc/ChangeLog:
> * ipa-strub.cc (ipa_strub_set_mode_for_new_functions): Replace
>
This patch adds remapping of node order for each lto partition.
Resulting order conserves relative order inside partition, but
is independent of outside symbols. So if lto partition contains
identical set of symbols, their remapped order will be stable
between compilations.
gcc/ChangeLog
ipa_strub_set_mode_for_new_functions uses node order as unique ever
increasing identifier. This is better satisfied with uid.
Order loses uniqueness with following patches.
gcc/ChangeLog:
* ipa-strub.cc (ipa_strub_set_mode_for_new_functions): Replace
order with uid
This set of patches replaces the original Incremental LTO patch for
stabilizing node order in lto partitions.
Main difference is earlier handling of node clone order, as suggested by
Honza (https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651593.html).
Previously I simply set clone's ord
Symbol order corresponds to the order in source code.
For clones their order is currently arbitrarily chosen as max order++
But it would be more consistent with original purpose to choose clones
order to be shared with the original node order.
This stabilizes clone order for Incremental LTO
following valid
code
with -std=c++17 and above
=== cut here ===
struct Base {
unsigned int *intarray;
};
template struct Sub : public Base {
bool Get(int i) {
return (Base::intarray[++i] == 0);
}
};
=== cut here ===
The problem is that from c++17 on, we use -fstrong-eval-order and
>>>> bool Get(int i) {
>>>> return (Base::intarray[++i] == 0);
>>>> }
>>>> };
>>>> === cut here ===
>>>>
>>>> The problem is that from c++17 on, we use -fstrong-eval-order and
>>>> need
;
};
template struct Sub : public Base {
bool Get(int i) {
return (Base::intarray[++i] == 0);
}
};
=== cut here ===
The problem is that from c++17 on, we use -fstrong-eval-order and
need
to wrap the array access expression into a SAVE_EXPR, and end up
calling
contains_placeholder_p
nt *intarray;
>> };
>> template struct Sub : public Base {
>>bool Get(int i) {
>> return (Base::intarray[++i] == 0);
>>}
>> };
>> === cut here ===
>>
>> The problem is that from c++17 on, we use -fstrong-eval-order
Tested x86_64-linux, and briefly checked with Clang. Pushed to trunk.
-- >8 --
GCC allows these in either order, but Clang doesn't like the C++11-style
[[__nodiscard__]] coming after __attribute__((__always_inline__)).
libstdc++-v3/ChangeLog:
PR libstdc++/117220
* incl
Fix the order of operands in andn3 expander to comply
with the specification, where bitwise-complement applies to operand 2.
PR target/117192
gcc/ChangeLog:
* config/i386/mmx.md (andn3): Swap operand
indexes 1 and 2 to comply with andn specification.
gcc/testsuite/ChangeLog
ChangeLog:
* MAINTAINERS: Fix Write After Approval name order.
Signed-off-by: Filip Kastl
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cf1cf78e16c..269ac2ea6b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -760,7
This is another case of load hoisting breaking UID order in the
preheader, this time between two hoistings. The easiest way out is
to do what we do for the main stmt - copy instead of move.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/116902
The following fixes the case when vectorizing a load hoists an invariant
load and dependent stmts, thereby breaking UID order of said stmts.
While we duplicate the load we just move the dependences.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
PR tree
ChangeLog:
* MAINTAINERS: Fix sort order and add username.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0ea4db20f88..3b4cf9d20d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -554,10 +554,10 @@ Sam James
On Wed, Sep 11, 2024 at 10:16:18PM +1000, Nathaniel Shead wrote:
> In the header_module_p case, it is valid to have internal linkage
> definitions (e.g. in an anonymous namespace), but in that case the
> {static,tls}_aggregates lists should still be in place to be streamed
> and everything should w
slot = tree_cons (init, decl, slot);
> + if (init && decomp_state == 1)
> + STATIC_INIT_DECOMP_BASE_P (slot) = 1;
> + else if (decomp_state == 2)
> + STATIC_INIT_DECOMP_NONBASE_P (slot) = 1;
> }
>
> if (!f
var, init);
/* Output init aliases even with -fno-extern-tls-init. */
@@ -5001,6 +5137,7 @@ handle_tls_init (void)
gcc_assert (alias != NULL);
}
}
+ decomp_finalize_var_list (sl, save_stmts_are_full_exprs_p);
finish_then_clause (if_stmt);
finish_if_stmt (if_s
Tested on hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu. Committed
to trunk.
Dave
---
hppa: Don't canonicalize operand order of scaled index addresses
pa_print_operand handles both operand orders for scaled index
addresses, so it isn't necessary to canonicalize the order of
operands
d version of the block scope static structured bindings
CWG 2867 patch.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
No patch for the namespace scope structured bindings yet, will work on that
soon.
2024-09-05 Jakub Jelinek
PR c++/115769
PR c++/115769
* cp-tree.h: Partially implement CWG 2867 - Order of initialization
for structured bindings.
(cp_finish_decomp): Add TEST_P argument defaulted to false.
* decl.cc (initialize_local_var): Add DECOMP argument, if true,
don't build cle
PR c++/115769
* cp-tree.h: Partially implement CWG 2867 - Order of initialization
for structured bindings.
(cp_finish_decomp): Add TEST_P argument defaulted to false.
* decl.cc (initialize_local_var): Add DECOMP argument, if true,
don't build c
eter, we could refer to the parameter instead of ever referring to
decomp_cl.
So like this (so far quickly tested on *decomp* dr2867*, full
bootstrap/regtest queued)?
2024-09-04 Jakub Jelinek
PR c++/115769
* cp-tree.h: Partially implement CWG 2867 - Order of initialization
t field a reference to the decomp
> parameter, we could refer to the parameter instead of ever referring to
> decomp_cl.
So like this (so far quickly tested on *decomp* dr2867*, full
bootstrap/regtest queued)?
2024-09-04 Jakub Jelinek
PR c++/115769
* cp-tree.h: Partially im
ecl call (which I like better),
Sounds good.
and attached is one which introduces a tristate argument to
cp_finish_decomp.
So far I've bootstrapped/regtested on x86_64-linux and i686-linux the RAII
one.
2024-08-30 Jakub Jelinek
PR c++/115769
* cp-tree.h: Partially impl
in the callers from
after the cp_finish_decl call (which I like better),
and attached is one which introduces a tristate argument to
cp_finish_decomp.
So far I've bootstrapped/regtested on x86_64-linux and i686-linux the RAII
one.
2024-08-30 Jakub Jelinek
PR c++/115769
On 8/27/24 07:56, Jeff Law wrote:
On 8/26/24 6:36 PM, Patrick O'Neill wrote:
The corresponding expander (riscv-v.cc:expand_const_vector) matches
const_vec_duplicate_p before const_vec_series_p. Reorder to match this
behavior when calculating costs.
gcc/ChangeLog:
* config/riscv/riscv.c
On 8/26/24 6:36 PM, Patrick O'Neill wrote:
The corresponding expander (riscv-v.cc:expand_const_vector) matches
const_vec_duplicate_p before const_vec_series_p. Reorder to match this
behavior when calculating costs.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_const_insns): Relocate.
The corresponding expander (riscv-v.cc:expand_const_vector) matches
const_vec_duplicate_p before const_vec_series_p. Reorder to match this
behavior when calculating costs.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_const_insns): Relocate.
Signed-off-by: Patrick O'Neill
---
Ack'd here
On 8/22/24 1:46 PM, Patrick O'Neill wrote:
The corresponding expander (riscv-v.cc:expand_const_vector) matches
const_vec_duplicate_p before const_vec_series_p. Reorder to match this
behavior when calculating costs.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_const_insns): Relocate.
The corresponding expander (riscv-v.cc:expand_const_vector) matches
const_vec_duplicate_p before const_vec_series_p. Reorder to match this
behavior when calculating costs.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_const_insns): Relocate.
Signed-off-by: Patrick O'Neill
---
gcc/confi
On 8/14/24 3:41 AM, Jakub Jelinek wrote:
Hi!
The following patch partially implements CWG 2867
- Order of initialization for structured bindings.
The DR requires that initialization of e is sequenced before r_i and
that r_i initialization is sequenced before r_j for j > i, we already do it
t
Hi,
This patch folds builtin_isfinite on IBM long double to builtin_isfinite
on its high-order double.
The isfinite_optab was already implemented in this patch.
https://gcc.gnu.org/g:44eb45c2ef7192eb6a811fd46fcb2c7fbeb6f865
Bootstrapped and tested on powerpc64-linux BE and LE with no
Hi,
This patch folds builtin_isinf on IBM long double to builtin_isinf on
its high-order double.
The isinf_optab was already implemented in this patch.
https://gcc.gnu.org/g:53945be1efb502f235d84ff67ceafe4a764b6e1c
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions
hat to do about modules.cc uses of these, it needs
to save/restore that stuff somehow too.
2024-08-14 Jakub Jelinek
PR c++/115769
* decl.cc: Partially implement CWG 2867 - Order of initialization
for structured bindings.
(cp_finish_decl): If need_decomp_init, for fu
ry the above variant next.
2024-08-14 Jakub Jelinek
PR c++/115769
* decl.cc: Partially implement CWG 2867 - Order of initialization
for structured bindings.
(expand_static_init): Add DECOMP argument. If true, call
cp_finish_decomp and if needed inte
Hi!
The following patch partially implements CWG 2867
- Order of initialization for structured bindings.
The DR requires that initialization of e is sequenced before r_i and
that r_i initialization is sequenced before r_j for j > i, we already do it
that way, the former ordering is a necessity
Per gccint, 'dg-require-*' must come before any
'dg-additional-sources' directives. Fix a handful of deviant cases.
* gcc.dg/tree-prof/crossmodule-indir-call-topn-1.c: Fix
dg-require-profiling
directive order.
* gcc.dg/tree-prof/crossmodule-indir-cal
Per gccint, 'dg-require-effective-target' must come before any
'dg-additional-sources' directives. Fix a handful of deviant cases.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/aapcs64/func-ret-3.c: Fix
dg-require-effective-target directive order.
* gcc.ta
constraint_vec_find (vec vec,
-struct constraint lookfor)
+constraint &lookfor)
{
unsigned int place;
constraint_t found;
@@ -2806,10 +2806,8 @@ solve_graph (constraint_graph_t graph)
better visitation order in the next iteration. */
wh
t; Thanks,
> Feng
> ---
> gcc/
> PR tree-optimization/114440
> * tree-vectorizer.h (struct _stmt_vec_info): Add a new field
> reduc_result_pos.
> * tree-vect-loop.cc (vect_transform_reduction): Generate lane-reducing
> statements in an op
-vectorizer.h (struct _stmt_vec_info): Add a new field
reduc_result_pos.
* tree-vect-loop.cc (vect_transform_reduction): Generate lane-reducing
statements in an optimized order.
---
gcc/tree-vect-loop.cc | 64 ++-
gcc/tree-vectorizer.h | 6
-loop.cc (vect_transform_reduction): Add a new parameter
slp_node_instance. Generate lane-reducing statements in an optimized
order.
---
gcc/tree-vect-loop.cc | 73 +++---
gcc/tree-vect-stmts.cc | 3 +-
gcc/tree-vectorizer.h | 8 -
3 files
Hi,
I've noticed wrong order in the Contributing under the DCO section of the
MAINTAINERS file. I'm commiting the fix as obvious.
Filip Kastl
-- 8< --
ChangeLog:
* MAINTAINERS: Fix order in Contributing under the DCO.
Signed-off-by: Filip Kastl
---
MAINTAINERS |
-vectorizer.h (struct _stmt_vec_info): Add a new field
reduc_result_pos.
* tree-vect-loop.cc (vect_transform_reduction): Generate lane-reducing
statements in an optimized order.
---
gcc/tree-vect-loop.cc | 43 +++
gcc/tree-vectorizer.h
_stmt_vec_info): Add a new field
reduc_result_pos.
* tree-vect-loop.cc (vect_transform_reduction): Generate lane-reducing
statements in an optimized order.
---
gcc/tree-vect-loop.cc | 43 +++
gcc/tree-vectorizer.h | 6 ++
2 files
_stmt_vec_info): Add a new field
reduc_result_pos.
* tree-vect-loop.cc (vect_transform_reduction): Generate lane-reducing
statements in an optimized order.
---
gcc/tree-vect-loop.cc | 39 +++
gcc/tree-vectorizer.h | 6 ++
2 files changed, 41
statements in an optimized order.
---
gcc/tree-vect-loop.cc | 51 ++-
gcc/tree-vectorizer.h | 6 +
2 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index fb9259d115c..de7a9bab990 100644
From: Javier Miranda
When the first formal parameter of a subprogram is a class-wide
interface type (or an access to a class-wide interface type),
changing the order of the interface types implemented by a
type declaration T enables or disables the ability to use the
prefix notation to call it
On Linux/x86_64,
4653b682ef161c3c2fc7bf8462b8f9206a1349e6 is the first bad commit
commit 4653b682ef161c3c2fc7bf8462b8f9206a1349e6
Author: Richard Biener
Date: Tue Mar 5 15:46:24 2024 +0100
Allow single-lane SLP in-order reductions
caused
FAIL: gcc.dg/vect/vect-cond-reduc-in-order-2
OK for trunk?
-- >8 --
This change fixes the following two errors:
Traceback (most recent call last):
File "../contrib/header-tools/gcc-order-headers", line 267, in
process_known_dups ()
File "../contrib/header-tools/gcc-order-headers", line 101, in
process_k
* tree-vect-loop.cc (vectorizable_reduction): Allow
single-lane SLP in-order reductions.
(vectorize_fold_left_reduction): Handle SLP reduction with
conditional reduction op.
---
gcc/tree-vect-loop.cc | 48 +--
1 file changed, 19
reduc_result_pos.
* tree-vect-loop.cc (vect_transform_reduction): Generate lane-reducing
statements in an optimized order.
---
gcc/tree-vect-loop.cc | 51 ++-
gcc/tree-vectorizer.h | 6 +
2 files changed, 51 insertions(+), 6 deletions(-)
diff --git a
> This patch squashes order of symbols in individual partitions, so that
> their relative order is conserved, but is not influenced by symbols in
> other partitions.
> Order of cloned symbols is set to 0. This should be fine because order
> specifies order of symbols in input file
wrong order.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114792
* tree-ssa-loop-ch.cc (ch_order_loops): New function.
(ch_base::copy_headers): Sort loops to unloop inner-to-outer.
* gcc.dg/torture/pr114792.c: New testcase
1 - 100 of 1001 matches
Mail list logo
