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 +76
Sam James writes:
> Add -Werror=lto-type-mismatch,odr to bootstrap-lto* configurations to
> help stop LTO breakage/correctness issues sneaking in.
>
> We discussed -Werror=strict-aliasing but it runs early and doesn't
> give better diagnostics with LTO so left it out.
>
> config/ChangeLog:
>
The sparc port gained LRA support in r7-5076-gf99bd883fb0d05 and has
defaulted to LRA since r7-5642-g70a6dbe7e37e69.
Let's finish the transition by dropping -mlra entirely.
Tested on sparc64-unknown-linux-gnu with no regressions.
gcc/ChangeLog:
PR target/113952
* config/sparc/sp
On Tue, 2024-10-15 at 16:18 +0200, John Paul Adrian Glaubitz wrote:
> On Tue, 2024-10-15 at 07:56 -0600, Jeff Law wrote:
> > Also note if we think it's basically working I can flip my tester to
> > default to LRA. It bootstraps and regtests alpha once a week via qemu.
> >
> > I think it's testin
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-10-15 20:55
To: gcc-patches
CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai;
jeffreya...@gmail.com; pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Use biggest_mode as mode for constants.
Hi,
in compute
Thanks.
Pushed as:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=e7380688fa5917011c3fb85b5e06fb00f776a95d
Qing
> On Oct 15, 2024, at 12:23, Joseph Myers wrote:
>
> On Fri, 11 Oct 2024, Qing Zhao wrote:
>
>> Hi, This is the 8th version of the patch.
>>
>> Compared to the 7th version, the maj
> This should be documented in install.texi.
Right. Sorry I forgot that piece.
--
-keith
signature.asc
Description: PGP signature
From: Andi Kleen
Passes test suite. Ok to commit?
gcc/ChangeLog:
PR middle-end/116510
* tree-if-conv.cc (predicate_bbs): Add missing fold_converts.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-switch-ifcvt-3.c: New test.
---
gcc/testsuite/gcc.dg/vect/vect-switch-ifcvt-
Hi!
On Mon, Oct 14, 2024 at 05:26:51PM +0530, jeevitha wrote:
> Corrected the function code for the Atomic Memory Operation "Fetch and
> Decrement
> Bounded", changing it from 0x1A to 0x1C.
... which is the correct value. :-)
> 2024-10-14 Jeevitha Palanisamy
>
> gcc/
> * config/rs6000/
On 10/14/24 11:04, Cupertino Miranda wrote:
> Hi everyone,
>
> Here is the v2 for the patch in this thread:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665378.html
> Please noticed that commit message was adapted to new content.
>
> Regards,
> Cupertino
Hi Cupertino,
Thanks for
> On Oct 15, 2024, at 20:11, Andrew Carlotti wrote:
>
> On Tue, Oct 15, 2024 at 02:18:43PM +0800, Yangyu Chen wrote:
>> Some architectures may use ',' in the attribute string, but it is not
>> used as the separator for different targets. To avoid conflict, we
>> introduce a new macro TARGET_FM
On Tue, 15 Oct 2024, Jakub Jelinek wrote:
> Here is a new version of the patch, tested on the dg.exp=*named-loops*
> tests fine, I think it doesn't need more testing given that it is just
> comment changes in code plus testsuite changes.
This version is OK.
--
Joseph S. Myers
josmy...@redhat.co
Some architectures may use ',' in the attribute string, but it is not
used as the separator for different targets. To avoid conflict, we
introduce a new macro TARGET_CLONES_ATTR_SEPARATOR to separate different
clones.
As an example, according to RISC-V C-API Specification [1], RISC-V allows
',' in
On Tue, 15 Oct 2024, Matthew Malcomson wrote:
> Seems that the testsuite and build system are the main things to watch
> out for here right?
Yes, as illustrated by the draft patch linked from bug 81358 comment 11.
--
Joseph S. Myers
josmy...@redhat.com
This was added as part of the initial Concepts TS implementation and
reflects an early version of the Concepts TS paper, which is very
different from standard C++20 concepts (and even from more recent
versions of the Concepts TS, support for which we deprecated in GCC 14
and removed for GCC 15). S
> Quick question. We did something like this to aid internal
> testing/bringup. Our variant adjusted a ton of the mode iterators in
> vector-iterators.md and the TUPLE_ENTRY stuff in riscv-vector-switch.def.
>
> Robin, do you remember why you had to adjust all the iterators? Was it
> that LTO
Hi!
Here is an updated version of the patch.
My reading of C23 is that if some aggregate field is initialized with
{} (which is supposed to newly clear padding bits) and then its
subobjects are overridden with designated initializers, then the
padding bits are cleared property should be kept unle
Fixed by r15-4340-gcacbb4daac3e9a.
PR c++/80637
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-fn9.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/concepts-fn9.C | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-fn9.C
d
On Tue, 15 Oct 2024, Jakub Jelinek wrote:
> --- gcc/testsuite/gcc.dg/cpp/c23-delimited-escape-seq-1.c.jj 2024-10-14
> 17:58:54.436815339 +0200
> +++ gcc/testsuite/gcc.dg/cpp/c23-delimited-escape-seq-1.c 2024-10-14
> 17:59:05.032666716 +0200
> @@ -0,0 +1,87 @@
> +/* P2290R3 - Delimited escap
On Tue, Oct 15, 2024 at 05:00:04PM +, Joseph Myers wrote:
> What happens with a statement attribute on the iteration or switch
> statement?
>
> label: [[]] for (;;) break label;
Except for the omp::directive/omp::sequence attributes label is accepted
as loop label.
Those OpenMP attributes
On Mon, 14 Oct 2024, Keith Packard wrote:
> * Makefile.in: Expand multilib set when --enable-multilib-space
> * configure.ac: Support --enable-multilib-space option
> * configure: Regenerate
This should be documented in install.texi.
--
Joseph S. Myers
josmy...@redhat.com
David: Ping.
Le 2024-02-17 à 11 h 55, Antoni Boucher a écrit :
David: Ping.
On Fri, 2024-01-19 at 15:59 -0500, Antoni Boucher wrote:
David: Ping.
On Thu, 2023-12-21 at 11:59 -0500, Antoni Boucher wrote:
Hi.
This patch adds the ability to send const pointer as argument to a
function.
Thanks f
On Fri, 11 Oct 2024, Jakub Jelinek wrote:
> On Fri, Oct 11, 2024 at 02:19:08PM +, Joseph Myers wrote:
> > There should definitely be a test that -std=c23 -pedantic-errors gives
> > errors for these constructs (I'd say also test that -std=c23
> > -pedantic-errors -Wno-c23-c2y-compat doesn't d
On Fri, 11 Oct 2024, Qing Zhao wrote:
> Hi, This is the 8th version of the patch.
>
> Compared to the 7th version, the major changes are several documentation
> wording issues raised by Joseph.
>
> The 7th version is at:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/664032.html
>
>
x86-64-v3 requires AVX2 effective target and AVX2 specific avx2-check.h.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr107432-9.c: Require AVX2 effective target.
Include avx2-check.h instead of avx-check.h. Define TEST to avx2_test.
Tested on x86_64-linux-gnu {,-m32}.
Uros.
diff --git a
I forgot to regenerate the c.opt.urls files after adding the opindex for
changes-meaning.
Fixed thusly.
gcc/c-family/ChangeLog:
C++/117157
* c.opt.urls: Regenerate.
Signed-off-by: Andrew Pinski
---
gcc/c-family/c.opt.urls | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
On 10/15/24 8:56 AM, Patrick O'Neill wrote:
From: Greg McGary
Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.
gcc/ChangeLog:
* config/riscv/autovec.md (vec_mask_len_l
Adds missing opindex for -Wchanges-meaning
Pushed as obvious after building the HTML and checking the index.
gcc/ChangeLog:
PR c++/117157
* doc/invoke.texi (Wno-changes-meaning): Add opindex.
Signed-off-by: Andrew Pinski
---
gcc/doc/invoke.texi | 2 ++
1 file changed, 2 insert
jit.dg/test-error-pr63969-missing-driver.c tries to break PATH and
verify that an error is generated when using an external driver.
However it does this by unsetting PATH, and so the test could
accidentally find the driver if the system supplies a default and the
driver happens to be installed in
No functional change intended.
Successfully regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-4361-g77076d85e9aa5e.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/analyzer_cpython_plugin.c: Use success_call_info
in a couple of places to avoid reimplementing get_desc.
Signed-off
On Fri, Oct 11, 2024 at 10:41:36PM -0400, Jason Merrill wrote:
> The intent is that C++20 module header units obsolete PCH; they serve the
> same function and are more flexible (you can import multiple header units).
Though, simple use of -std=c++20 or -std=c++23 doesn't imply one is using
modules
This commit adds a new permute optimization step after running SLP
vectorization.
Although there are existing places where individual or nested permutes
can be optimized, there are cases where independent permutes can be optimized,
which cannot be expressed in the current pattern matching framewor
When two_operator SLP nodes are built, the VEC_PERM_EXPR that merges the result
selects a lane only based on the operator found. If the input nodes have
duplicate elements, there may be more than one way to choose. This commit
changes the policy to reuse an existing lane with the result that we can
From: Greg McGary
Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.
gcc/ChangeLog:
* config/riscv/autovec.md (vec_mask_len_load_lanes,
vec_mask_len_store_lanes):
Middle end can generate SYMBOL_REF RTX as a value "val" in the call
to expand_vector_set, but SYMBOL_REF RTX is not accepted in
_pinsr insn pattern, generated via
VEC_MERGE/VEC_DUPLICATE RTX path.
Force the value into a register before VEC_MERGE/VEC_DUPLICATE RTX
is generated if it doesn't satisfy
Am Dienstag, dem 15.10.2024 um 12:15 +0200 schrieb Jakub Jelinek:
> On Tue, Oct 15, 2024 at 11:50:21AM +0200, Richard Biener wrote:
> > > Would it be reasonable to approve this patch now and I try
> > > to improve this later?
> >
> > On the patch itself:
> >
> > void
> > expand_builtin_trap (vo
Good catch. Probably not a common case as usually we're already in
supported type contexts when we get around to check range_compatible..
I guess it wouldn't hurt to put a gcc_checking_assert in
range_compatible_p to confirm that they are supported types before
returning true.
Certainly ok.
On 15/10/24 15:20 +0100, Jonathan Wakely wrote:
Tested x86_64-linux.
-- >8 --
There doesn't seem to be a lot of benefit in reusing __find_if with
__gnu_cxx::__ops predicates, since they aren't going to actually
instantiate any less code if we use different predicates every time
(e.g. __ops::__n
Richard Biener writes:
> On Tue, Oct 15, 2024 at 5:30 AM liuhongt wrote:
>>
>> For x86 masked fma, there're 2 rtl representations
>> 1) (vec_merge (fma op2 op1 op3) op1 mask)
>> 2) (vec_merge (fma op1 op2 op3) op1 mask).
>>
>> 5894(define_insn "_fmadd__mask"
>> 5895 [(set (match_operand:VFH_AV
Tested x86_64-linux.
-- >8 --
We implement std::copy, std::fill etc. as a series of calls to other
overloads which incrementally peel off layers of iterator wrappers. This
adds a high abstraction penalty for -O0 and potentially even -O1. Add
the always_inline attribute to several functions that a
On 16/09/2024 10:38, Christophe Lyon wrote:
> From: Alfie Richards
>
> Implement the mve vld and vst intrinsics using the MVE builtins framework.
>
> The main part of the patch is to reimplement to vstr/vldr patterns
> such that we now have much fewer of them:
> - non-truncating stores
> - predi
This is a slightly different approach to C++98 compatibility than used
in patch 1/1 of this series for the uninitialized algos. It worked out a
bit cleaner this way for these algos, I think.
Tested x86_64-linux.
-- >8 --
This removes all the __copy_move class template specializations that
decide
This is v2 of
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665246.html
fixing some thinkos in uninitialized_{fill,fill_n}. We don't need to
worry about overwriting tail-padding in those algos, because we only use
memset for 1-byte integer types. So they have no tail padding that can
be re
Tested x86_64-linux.
-- >8 --
The __gnu_cxx::__normal_iterator type we use for std::vector::iterator
is not specified by the standard, it's an implementation detail. This
means it's not constrained by the rule that forbids strengthening
constexpr. We can make it meet the constexpr iterator requir
Tested x86_64-linux.
-- >8 --
There doesn't seem to be a lot of benefit in reusing __find_if with
__gnu_cxx::__ops predicates, since they aren't going to actually
instantiate any less code if we use different predicates every time
(e.g. __ops::__negate, or __ops::__iter_equals_val, or
__ops::__pr
Tested x86_64-linux.
-- >8 --
Use std::__assign_one instead of ranges::__assign_one. Adjust the uses,
because std::__assign_one has the arguments in the opposite order (the
same order as an assignment expression).
libstdc++-v3/ChangeLog:
* include/bits/ranges_algobase.h (ranges::__assig
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_algobase.h (find): Add nodiscard.
---
libstdc++-v3/include/bits/stl_algobase.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/stl_algobase.h
b/libstdc++-v3/include/bi
On Tue, 2024-10-15 at 07:56 -0600, Jeff Law wrote:
> Also note if we think it's basically working I can flip my tester to
> default to LRA. It bootstraps and regtests alpha once a week via qemu.
>
> I think it's testing the baseline configuration, so presumably non-BWX
> variants. That can pro
On 16/09/2024 10:38, Christophe Lyon wrote:
> From: Alfie Richards
>
> This patch extends
> function_expander::use_contiguous_load_insn and
> function_expander::use_contiguous_store_insn functions to
> support predicated versions.
>
> 2024-09-11 Alfie Richards
> Christophe Lyon
>
On Tue, 15 Oct 2024, Patrick Palka wrote:
> According to [temp.param]/11, the constraint on an auto NTTP is an
> associated constraint and so should be checked as part of satisfaction
> of the overall associated constraints rather than checked individually
> during coerion/deduction.
By the way,
On 16/09/2024 10:38, Christophe Lyon wrote:
> From: Alfie Richards
>
> This patch adds the load_extending and store_truncating function bases
> for MVE intrinsics.
>
> The constructors have parameters describing the memory element
> type/width which is part of the function base name (e.g. "h" in
On 10/15/24 6:55 AM, Robin Dapp wrote:
Hi,
in compute_nregs_for_mode we expect that the current variable's mode is
at most as large as the biggest mode to be used for vectorization.
This might not be true for constants as they don't actually have a mode.
In that case, just use the biggest mo
On 10/15/24 6:47 AM, Richard Biener wrote:
On Tue, Oct 15, 2024 at 2:41 PM John Paul Adrian Glaubitz
wrote:
Hi Maciej,
On Tue, 2024-10-15 at 13:36 +0100, Maciej W. Rozycki wrote:
IMO, we should simply deprecate non-BWX targets. If reload is going
away, then there is no way for non-BWX tar
On Tue, 15 Oct 2024 at 14:30, Patrick Palka wrote:
>
> On Mon, 14 Oct 2024, Jonathan Wakely wrote:
>
> > Tested x86_64-linux.
> >
> > -- >8 --
> >
> > LWG 3798 modified the iterator_category of the iterator types for
> > transform_view, join_with_view, zip_transform_view and
> > adjacent_transform
On Mon, 14 Oct 2024, Jonathan Wakely wrote:
> Tested x86_64-linux.
>
> -- >8 --
>
> LWG 3798 modified the iterator_category of the iterator types for
> transform_view, join_with_view, zip_transform_view and
> adjacent_transform_view, to allow the iterator's reference type to be an
> rvalue refer
On Tue, 15 Oct 2024, Richard Biener wrote:
> > FWIW, it *seems* that LRA seems to just work with EV56 as the baseline and
> > the
> > following replacements in the code:
> >
> > s/reload_in_progress/reload_in_progress || lra_in_progress/g
>
> If you can provide -mlra vs. -mno-lra testsui
Hi Jason,
On 15 Oct 2024, at 15:18, Jason Merrill wrote:
> On 10/13/24 7:55 AM, Simon Martin wrote:
>> The patch that I merged via r15-4282-g60163c85730e6b breaks the build
>> for the rust front-end because it does not work well when virtual
>> inheritance is in play.
>>
>> The problem is that in
On 10/15/24 12:47 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
When unifying two (non-forwarding) reference types, unify immediately
recurses into the reference type without first comparing rvalueness.
(Note that at thi
On 10/15/24 12:48 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
OK.
-- >8 --
Here we're tripping over the assert in extract_locals_r which enforces
that an extra-args tree appearing inside another extra-args tree doesn't
actually hav
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, October 15, 2024 1:42 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 4/4]middle-end: create the longest possible zero extend
> chain
> after overwidening
>
> On Mon, 14 Oct 2024, Tamar Christ
On 10/13/24 7:55 AM, Simon Martin wrote:
The patch that I merged via r15-4282-g60163c85730e6b breaks the build
for the rust front-end because it does not work well when virtual
inheritance is in play.
The problem is that in such a case, an overrider and its overridden base
method might have a di
On Tue, 2024-10-15 at 15:06 +0200, John Paul Adrian Glaubitz wrote:
> On Tue, 2024-10-15 at 14:47 +0200, Richard Biener wrote:
> > If you can provide -mlra vs. -mno-lra testsuite results as well that
> > would be interesting.
>
> OK, I'll try to provide these.
>
> > Does "just work" mean you can
Hi Richard,
On Tue, 2024-10-15 at 14:47 +0200, Richard Biener wrote:
> If you can provide -mlra vs. -mno-lra testsuite results as well that
> would be interesting.
OK, I'll try to provide these.
> Does "just work" mean you can build the compiler and its target
> libraries?
I'm performing a full
On Mon, Oct 14, 2024 at 8:00 PM Andrew Pinski wrote:
>
> Having a limit of 2 params for NEXT_PASS was just done because I didn't think
> there was
> a way to handle arbitrary number of params. But I found that we can handle
> this
> via a static const variable array (constexpr so we know it is t
Hi,
in compute_nregs_for_mode we expect that the current variable's mode is
at most as large as the biggest mode to be used for vectorization.
This might not be true for constants as they don't actually have a mode.
In that case, just use the biggest mode so max_number_of_live_regs
returns 1.
Th
On Tue, Oct 15, 2024 at 4:07 AM Andrew Pinski wrote:
>
> This FIXME:
>FIXME: Aggressive mode before PRE doesn't work currently because
> the dominance info is not invalidated after DCE1.
>
> Has not been true since at least r0-104723-g5ac60b564faa85 which
> added a call to calculate_
On Tue, Oct 15, 2024 at 2:41 PM John Paul Adrian Glaubitz
wrote:
>
> Hi Maciej,
>
> On Tue, 2024-10-15 at 13:36 +0100, Maciej W. Rozycki wrote:
> > > IMO, we should simply deprecate non-BWX targets. If reload is going
> > > away, then there is no way for non-BWX targets to access reload
> > > inte
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, October 15, 2024 1:22 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 2/4]middle-end: Fix VEC_PERM_EXPR lowering since
> relaxation of vector sizes
>
> On Mon, 14 Oct 2024, Tamar Christina wrot
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, October 15, 2024 1:20 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH 1/4]middle-end: support multi-step zero-extends using
> VEC_PERM_EXPR
>
> On Tue, 15 Oct 2024, Tamar Christina wrote:
>
>
On Mon, 14 Oct 2024, Tamar Christina wrote:
> Hi All,
>
> Consider loops such as:
>
> void test9(unsigned char *x, long long *y, int n, unsigned char k) {
> for(int i = 0; i < n; i++) {
> y[i] = k + x[i];
> }
> }
>
> where today we generate:
>
> .L5:
> ldr q29, [x5]
Hi Maciej,
On Tue, 2024-10-15 at 13:36 +0100, Maciej W. Rozycki wrote:
> > IMO, we should simply deprecate non-BWX targets. If reload is going
> > away, then there is no way for non-BWX targets to access reload
> > internals they require for compilation. As mentioned in the PR,
> > non-BWX targets
On Tue, 15 Oct 2024, Uros Bizjak wrote:
> > PR target/66207
> > * config/alpha/alpha.opt (mlra): New target option.
> > * config/alpha/alpha.cc (alpha_use_lra_p): New function.
> > (TARGET_LRA_P): Use it.
> > * config/alpha/alpha.opt.urls: Regenerate.
>
> IMO, we should simply deprecate non-BWX t
On Mon, 14 Oct 2024, Tamar Christina wrote:
> Hi All,
>
> In GCC 14 VEC_PERM_EXPR was relaxed to be able to permute to a 2x larger
> vector
> than the size of the input vectors. However various passes and
> transformations
> were not updated to account for this.
>
> I have patches in these ar
On Tue, 15 Oct 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, October 15, 2024 12:13 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: Re: [PATCH 1/4]middle-end: support multi-step zero-extends using
> > VEC_PERM
On Tue, Oct 15, 2024 at 02:18:43PM +0800, Yangyu Chen wrote:
> Some architectures may use ',' in the attribute string, but it is not
> used as the separator for different targets. To avoid conflict, we
> introduce a new macro TARGET_FMV_ATTR_SEPARATOR to separate different
> clones.
This is only f
The following makes sure to use a VEC_PERM SLP node to produce
lane duplications for non-grouped SLP loads as those are later
not lowered by load permutation lowering.
For some reason gcc.dg/vect/pr106081.c now fails permute optimizing,
in particular eliding vector reversal for the reduction.
Boo
The following prepares us for SLP instances with a non-uniform number
of lanes. We already have this with load permutation lowering, but
we managed to keep that within the constraints of the per SLP instance
computed VF based on its max_nunits (with a vector type fixed for
each node) and the insta
The following is a more complete fix for PR117050, restoring the
ability to permute non-grouped .MASK_LOAD with.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/117050
* tree-vect-slp.cc (vect_build_slp_tree_2): Properly handle
non-group
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, October 15, 2024 12:13 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 1/4]middle-end: support multi-step zero-extends using
> VEC_PERM_EXPR
>
> On Tue, 15 Oct 2024, Tamar Christina wrote:
>
>
On Tue, Oct 15, 2024 at 5:30 AM liuhongt wrote:
>
> For x86 masked fma, there're 2 rtl representations
> 1) (vec_merge (fma op2 op1 op3) op1 mask)
> 2) (vec_merge (fma op1 op2 op3) op1 mask).
>
> 5894(define_insn "_fmadd__mask"
> 5895 [(set (match_operand:VFH_AVX512VL 0 "register_operand" "=v,v
CC'ing Maciej who has also worked on Alpha
Hi Uros,
On Tue, 2024-10-15 at 12:29 +0200, Uros Bizjak wrote:
> On Tue, Oct 15, 2024 at 11:09 AM John Paul Adrian Glaubitz
> wrote:
> >
> > PR target/66207
> > * config/alpha/alpha.opt (mlra): New target option.
> > * config/alpha/alpha.cc (alpha_use_
Add support for SVE xor immediate when generating AdvSIMD code and SVE is
available.
Passes bootstrap & regress, OK for commit?
gcc/ChangeLog:
* config/aarch64/aarch64.cc (enum simd_immediate_check): Add
AARCH64_CHECK_XOR.
(aarch64_simd_valid_xor_imm): New function.
(a
On Sun, 13 Oct 2024, Richard Biener wrote:
> When we remove unused BLOCKs we fail to clean references to them
> from DECL_VALUE_EXPRs of variables in other BLOCKs which in the
> PR causes LTO streaming to walk into pointers to GGC freed blocks.
>
> There's the question of whether such DECL_VALUE_
On Tue, 15 Oct 2024, Jakub Jelinek wrote:
> On Mon, Oct 14, 2024 at 08:53:29AM +0200, Jakub Jelinek wrote:
> > > PR middle-end/116891
> > > * match.pd ((negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2)):
> > > Only enable for !HONOR_SIGN_DEPENDENT_ROUNDING.
> >
> > Guess it would be nice
On Tue, 15 Oct 2024, Tamar Christina wrote:
> Hi,
>
> Thanks for the look,
>
> The 10/15/2024 09:54, Richard Biener wrote:
> > On Mon, 14 Oct 2024, Tamar Christina wrote:
> >
> > > Hi All,
> > >
> > > This patch series adds support for a target to do a direct convertion for
> > > zero
> > > e
On Mon, Oct 14, 2024 at 08:53:29AM +0200, Jakub Jelinek wrote:
> > PR middle-end/116891
> > * match.pd ((negate (IFN_FNMS@3 @0 @1 @2)) -> (IFN_FMA @0 @1 @2)):
> > Only enable for !HONOR_SIGN_DEPENDENT_ROUNDING.
>
> Guess it would be nice to have a testcase which FAILs without the patch
On Tue, Oct 15, 2024 at 11:09 AM John Paul Adrian Glaubitz
wrote:
>
> PR target/66207
> * config/alpha/alpha.opt (mlra): New target option.
> * config/alpha/alpha.cc (alpha_use_lra_p): New function.
> (TARGET_LRA_P): Use it.
> * config/alpha/alpha.opt.urls: Regenerate.
IMO, we should simply depre
Thanks for the pointer — always linking with libatomic by default
using--as-needed sounds quite promising from my end.
I am not certain, but suspect that needing libatomic for
atomic::fetch_{add,sub} would not mean libstdc++.so would get a
DT_NEEDED for libatomic.
The place where the new builti
On Tue, Oct 15, 2024 at 11:50:21AM +0200, Richard Biener wrote:
> > Would it be reasonable to approve this patch now and I try
> > to improve this later?
>
> On the patch itself:
>
> void
> expand_builtin_trap (void)
> {
> + if (warn_trap)
> +{
> + location_t current_location =
Form
Hi Joseph,
On Wed, Oct 09, 2024 at 09:11:52PM GMT, Joseph Myers wrote:
> On Wed, 9 Oct 2024, Alejandro Colomar wrote:
>
> > Every little bit adds up. Documentation is simpler if there is naming
> > consistency. We have SYNOPSISes in the man pages, and they're up front,
> > because they constitu
On Sun, 13 Oct 2024, Martin Uecker wrote:
> Am Sonntag, dem 13.10.2024 um 10:56 +0200 schrieb Richard Biener:
> > On Sat, 12 Oct 2024, Martin Uecker wrote:
> >
> > > Am Samstag, dem 12.10.2024 um 18:44 +0200 schrieb Richard Biener:
> > > >
> > > > > Am 12.10.2024 um 16:43 schrieb Martin Uecker :
Hi,
Thanks for the look,
The 10/15/2024 09:54, Richard Biener wrote:
> On Mon, 14 Oct 2024, Tamar Christina wrote:
>
> > Hi All,
> >
> > This patch series adds support for a target to do a direct convertion for
> > zero
> > extends using permutes.
> >
> > To do this it uses a target hook use_
Hi!
The following patch adds selftests to genmatch to verify the new printing
routine there.
So that I can rely on HAVE_DECL_FMEMOPEN (host test), the tests are done
solely in stage2+ where we link the host libcpp etc. to genmatch.
The tests have been adjusted from pretty-print.cc (test_pp_format)
The following adds a testcase for the PR.
Pushed.
PR tree-optimization/117147
* gcc.dg/vect/pr117147.c: New testcase.
---
gcc/testsuite/gcc.dg/vect/pr117147.c | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/vect/pr117147.c
diff
On 16/09/2024 10:38, Christophe Lyon wrote:
> From: Alfie Richards
>
> This patch adds the extending load shape.
> It also adds/fixes comments for the load and store shapes.
>
> 2024-09-11 Alfie Richards
> Christophe Lyon
>
> gcc/
> * config/arm/arm-mve-builtins-shapes
On 16/09/2024 10:38, Christophe Lyon wrote:
> From: Alfie Richards
>
> The tests for vst* instrinsics use functions which return a void
> expression which can generate a warning. This hasn't come up previously
> as the inlining presumably prevents the warning.
>
> This change removed the unecces
On 14/10/2024 19:18, Richard Earnshaw (lists) wrote:
> On 04/09/2024 14:26, Christophe Lyon wrote:
>> Implement vadcq using the new MVE builtins framework.
>>
>> We re-use most of the code introduced by the previous patch to support
>> vadciq: we just need to initialize carry from the input paramet
PR target/66207
* config/alpha/alpha.opt (mlra): New target option.
* config/alpha/alpha.cc (alpha_use_lra_p): New function.
(TARGET_LRA_P): Use it.
* config/alpha/alpha.opt.urls: Regenerate.
Signed-off-by: John Paul Adrian Glaubitz
---
gcc/config/alpha/alpha.cc | 10 +-
gcc/config
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, October 14, 2024 7:34 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de
>> Subject: Re: [PATCH 1/4]middle-end: support multi-step zero-extends using
>> VEC_PERM_EXPR
>
Tamar Christina writes:
> Hi All,
>
> While chasing down a costing difference between SLP and non-SLP for memory
> access costing I noticed that at some point the SLP and non-SLP costing have
> diverged. It used to be we only supported LOAD_LANES in SLP and so the
> non-SLP
> costing was working
1 - 100 of 114 matches
Mail list logo
