From: panciyan
This patch adds testcase for form11 and form12, as shown below:
void __attribute__((noinline)) \
vec_sat_u_sub_##T##_fmt_11 (T *out, T *op_1, T *op_2, unsigned limit) \
{\
u
Implementation and tests for the standard reduction optabs.
Bootstrapped and regtested on s390. Ok for trunk?
Signed-off-by: Juergen Christ
gcc/ChangeLog:
* config/s390/vector.md (reduc_plus_scal_): Implement.
(reduc_plus_scal_v2df): Implement.
(reduc_plus_scal_v4sf):
The default setting of s390 for the parameter min-vect-loop-bound was
set to 2 to prevent certain epilogue loop vectorizations in the past.
Reevaluation of this parameter shows that this setting now is not
needed anymore and sometimes even harmful. Remove the overwrite to
align s390 with other bac
On Wed, Jul 9, 2025 at 10:16 PM Robert Dubner wrote:
>
> From 069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a Mon Sep 17 00:00:00 2001
> From: Robert Dubner mailto:rdub...@symas.com
> Date: Wed, 9 Jul 2025 12:24:38 -0400
> Subject: [PATCH] cobol: Development round-up. [PR120765, PR119337,
> PR120794]
>
>
On Thu, Jul 10, 2025 at 8:13 AM Jakub Jelinek wrote:
>
> Hi!
>
> While I'm not a native English speaker, I believe all the uses
> of bellow (roar/bark/...) in comments in gcc are meant to be
> below (beneath/under/...).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK
> >
> > I tried to implement a workaround to match lost discriminator in cases
> > this is uniquely deterined, but it is not so easy to do.
> > My plan is to figure out how to upstream it and then drop the lost
> > discriminator workaround from match.
> >
> > Do you see warnings with -Wauto-profi
Hi,
Changes from v1:
- Use Himode broadcast instead of float broadcast, saving two conversion
insns.
Let's be daring and leave the thorough testing to the CI first while my own
testing is in progress :)
This patch makes the zero-stride load broadcast idiom dependent on a
uarch-tunable "us
Soumya AR writes:
>> On 1 Jul 2025, at 9:22 PM, Kyrylo Tkachov wrote:
>>
>>
>>
>>> On 1 Jul 2025, at 17:36, Richard Sandiford
>>> wrote:
>>>
>>> Soumya AR writes:
From 2a2c3e3683aaf3041524df166fc6f8cf20895a0b Mon Sep 17 00:00:00 2001
From: Soumya AR
Date: Mon, 30 Jun 2025 1
Soumya AR writes:
>> On 10 Jul 2025, at 3:15 PM, Richard Sandiford
>> wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
>> Soumya AR writes:
On 1 Jul 2025, at 9:22 PM, Kyrylo Tkachov wrote:
> On 1 Jul 2025, at 17:36, Richard Sandiford
>
Hi,
this patch adds asserts that ensure we only expand an RDIV_EXPR with
actual float mode. It also replaces the RDIV_EXPR in setting a
vectorized loop's length by EXACT_DIV_EXPR. The code in question is
only used with length-control targets (riscv, powerpc, s390).
Bootstrapped and regtested o
Hi Harald,
sorry for all the confusion. Probably my understanding of a pure
elemental routine is imperfect. I therefore first like to express what
I need an a caf-accessor. In a caf-accessor I have only access to data
that is "exported" to it via the add_data object. The data in there has
to be ma
On 2/22/25 8:10 AM, Jan Dubiec wrote:
This patch fixes SFtype to UDWtype (aka float to unsigned long long)
conversion on targets without DFmode like e.g. H8/300H. It solely relies
on SFtype->UWtype and UWtype->UDWtype conversions/casts. The existing code
in line 2218 (counter = a) assigns/cast
On Thu, 10 Jul 2025, Jan Hubicka wrote:
> > The x86 add_stmt_hook relies on the passed vectype to determine
> > the mode and whether it is FP for a scalar operation. This is
> > unreliable now for stmts involving patterns and in the future when
> > there is no vector type passed for scalar operat
So far only a per thread canary in the TLS block is supported. This
patch adds support for a global canary, too. For this the new option
-mstack-protector-guard={global,tls} is added which defaults to tls.
The global canary is expected at symbol __stack_chk_guard which means
for a function prolo
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 10, 2025 3:09 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> RISC-V CI
> Subject: RE: [PATCH] Reject single lane vector types for SLP build
>
> On Thu, 10 Jul 2025, Tamar Christina wrote:
>
On 10.07.2025 15:42, Jeff Law wrote:
[...]
Anyway, this has been repeatedly bootstrapped & regression tested on
aarch64, ppc64le and other targets. It's also been many dozens of
regression testing cycles on the various embedded targets.
This part of code does not seem to be used on many targe
Am 10.07.25 um 11:27 schrieb Andre Vehreschild:
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Did you run extensive tests on all potential race conditions,
and fix the resulting fallout?
If you did, please post your test cases and the results. Otherwise,
https://gcc.gnu.org/piperm
On Thu, Jul 10, 2025 at 04:03:29PM +, Qing Zhao wrote:
> The size of the element of the FAM _cannot_ reliably depends on the original
> TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE:
>
> TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (gimple_call_arg (call, 5
>
>
On Fri, Jul 11, 2025 at 6:51 AM wrote:
>
> From: Pan Li
>
> The widen mul has different source type for differnt platform,
> like rv32 or rv64. For rv32, the source of widen mul is 32-bits
> while 64-bits in rv64. Thus, leverage HOST_WIDE_INT is not that
> correct and result in the pattern matc
> On 10 Jul 2025, at 08:09, Jakub Jelinek wrote:
>
> Hi!
>
> While I'm not a native English speaker, I believe all the uses
> of bellow (roar/bark/...) in comments in gcc are meant to be
> below (beneath/under/...).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
>
Hi all,
While the SVE2 NBSL instruction accepts MOVPRFX to add more flexibility
due to its tied operands, the destination of the movprfx cannot be also
a source operand. But the offending pattern in aarch64-sve2.md tries
to do exactly that for the "=?&w,w,w" alternative and gas warns for the
attac
The original pattern was not exercised by any pre-existing test. I tried but
failed to come up with a testcase that would expand to
float_extend ∘ vec_duplicate
rather than
vec_duplicate ∘ float_extend.
Ok, so we indeed don't have a test and the intrinsics tests unfortunately are
no help
From: Björn Schäpers
On Windows there is no API to get the current time zone as IANA name,
instead Windows has its own zones. But there exists a mapping provided
by the Unicode Consortium. This patch adds a script to convert the XML
file with the mapping to a lookup table and adds a Windows code
> +#define test_data TEST_UNARY_DATA_WRAP(T, usub)
Here should be ussub instead of usub? Aka unsigned saturation sub (standard
name ussubm3).
Looks you need to update the data defined in previous too.
Otherwise, LGTM.
Pan
-Original Message-
From: Ciyan Pan
Sent: Thursday, Ju
The SVE svpfalse folding tests use CFI directives to delimit the
function bodies. That requires -funwind-tables to be enabled,
which is true by default for *-linux-gnu targets, but not for *-elf.
Tested on aarch64-linux-gnu and aarch64_be-elf. Pushed as obvious.
Richard
gcc/testsuite/
The x86 add_stmt_hook relies on the passed vectype to determine
the mode and whether it is FP for a scalar operation. This is
unreliable now for stmts involving patterns and in the future when
there is no vector type passed for scalar operations.
To be least disruptive I've kept using the vector
> The x86 add_stmt_hook relies on the passed vectype to determine
> the mode and whether it is FP for a scalar operation. This is
> unreliable now for stmts involving patterns and in the future when
> there is no vector type passed for scalar operations.
>
> To be least disruptive I've kept using
Hi,
this patch fixes several issues I noticed in gimple matching and -Wauto-profile
warning. One problem is that we mismatched symbols with user names, such as
"*strlen" instead of "strlen". I added raw_symbol_name to strip extra '*' which
is ok on ELF targets which are only targets we support wit
On Thu, Jul 10, 2025 at 2:31 PM Uros Bizjak wrote:
>
> On Thu, Jul 10, 2025 at 1:57 PM H.J. Lu wrote:
> >
> > commit 77473a27bae04da99d6979d43e7bd0a8106f4557
> > Author: H.J. Lu
> > Date: Thu Jun 26 06:08:51 2025 +0800
> >
> > x86: Also handle all 1s float vector constant
> >
> > replaces
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 10, 2025 1:31 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford ; Tamar Christina
> ; RISC-V CI
> Subject: [PATCH] Reject single lane vector types for SLP build
>
> The following makes us never consider vector(1) T
Hi!
On Thu, Jul 10, 2025 at 12:10:16PM +, Sadineni, Harish wrote:
> Ping for [1]https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html.
>
> This patch avoids embedding full build paths into generated headers by using
> only the basename of the source file. This helps to improve bui
Hi Jeevitha,
On 24/06/25 3:30 pm, jeevitha wrote:
> Hi All,
>
> The following patch has been tested on powerpc64le-linux and verified it's
> fixed.
>
> Changes from V1:
> Added the reason for adding the flag(-fno-ipa-icf) inside the test case.
>
> The test vsx-builtin-7.c failed on powerpc64le-
Richard Biener writes:
> The following removes an optimization that wrongly triggers right now
> because it accesses LOOP_VINFO_COST_MODEL_THRESHOLD which might not be
> computed yet.
>
> Testing on x86_64 didn't reveal any testsuite coverage.
>
> Bootstrapped and tested on x86_64-unknown-linux-gn
Hi Surya, Jeevitha,
On Thu, Jul 10, 2025 at 08:26:51PM +0530, Surya Kumari Jangala wrote:
> On 24/06/25 3:30 pm, jeevitha wrote:
> > The following patch has been tested on powerpc64le-linux and verified it's
> > fixed.
> >
> > Changes from V1:
> > Added the reason for adding the flag(-fno-ipa-icf
Hi all,
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599882.html.
This patch avoids embedding full build paths into generated headers by using
only the basename of the source file. This helps to improve build
reproducibility, particularly in environments where build paths vary
> On 10 Jul 2025, at 3:15 PM, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Soumya AR writes:
>>> On 1 Jul 2025, at 9:22 PM, Kyrylo Tkachov wrote:
>>>
>>>
>>>
On 1 Jul 2025, at 17:36, Richard Sandiford
wrote:
Soumya
On Thu, Jul 10, 2025 at 6:22 AM Richard Sandiford
wrote:
>
> LD1Q gathers and ST1Q scatters are unusual in that they operate
> on 128-bit blocks (effectively VNx1TI). However, we don't have
> modes or ACLE types for 128-bit integers, and 128-bit integers
> are not the intended use case. Instead,
On Thu, Jul 10, 2025 at 04:03:30PM +, Qing Zhao wrote:
> gcc/c-family/ChangeLog:
>
> * c-ubsan.cc (get_bound_from_access_with_size): Adjust the position
> of the arguments per the new design.
>
> gcc/c/ChangeLog:
>
> * c-typeck.cc (build_counted_by_ref): Update comments.
>
> On Jul 10, 2025, at 12:34, Jakub Jelinek wrote:
>
> On Thu, Jul 10, 2025 at 04:03:29PM +, Qing Zhao wrote:
>> The size of the element of the FAM _cannot_ reliably depends on the original
>> TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE:
>>
>> TYPE_SIZE
On 7/10/25 4:05 AM, Jakub Jelinek wrote:
On Wed, Jul 09, 2025 at 06:45:41PM -0400, Jason Merrill wrote:
+ && reduced_constant_expression_p (val))
And a value doesn't need to be constant to be printable, we should be able
to print it unconditionally.
Sure, the question is if printing
Hi David,
On 09/07/25 03:33, David Faust wrote:
diff --git a/contrib/bpf-vmtest-tool/.gitignore
b/contrib/bpf-vmtest-tool/.gitignore
new file mode 100644
index 000..723dfe1d0f4
--- /dev/null
+++ b/contrib/bpf-vmtest-tool/.gitignore
@@ -0,0 +1,23 @@
+.gitignore_local
+.python-version
+#
> On Jul 10, 2025, at 12:56, Jakub Jelinek wrote:
>
> On Thu, Jul 10, 2025 at 04:03:30PM +, Qing Zhao wrote:
>> gcc/c-family/ChangeLog:
>>
>> * c-ubsan.cc (get_bound_from_access_with_size): Adjust the position
>> of the arguments per the new design.
>>
>> gcc/c/ChangeLog:
>>
>> * c-typec
> Am 10.07.2025 um 16:27 schrieb Tamar Christina :
>
>
>>
>> -Original Message-
>> From: Richard Biener
>> Sent: Thursday, July 10, 2025 3:09 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
>> RISC-V CI
>> Subject: RE: [PATCH] Reject single lane vecto
Oh, I guess I didn't expand enough about my thought:
I don't care that we have bad performance/bad code gen here if Zvfh is
mandatory for RVA23 since that means not many people and core will
fall into this code gen path.
But RVA23 will go to this code gen patch, which means we will go this
path fo
The following arranges vector reduction costs to hand down the
SLP node (of the reduction stmt) to the cost hooks, not only the
stmt_info. This also avoids accessing STMT_VINFO_VECTYPE of an
unrelated stmt to the node that is subject to code generation.
* tree-vect-loop.cc (vect_model_red
From: Indu Bhagat
Add basic tests for memtag-stack sanitizer. Memtag stack sanitizer
uses target hooks to emit AArch64 specific MTE instructions.
gcc/testsuite:
* lib/target-supports.exp:
* gcc.target/aarch64/memtag/alloca-1.c: New test.
* gcc.target/aarch64/memtag/allo
From: Indu Bhagat
Currently, the data type of sanitizer flags is unsigned int, with
SANITIZE_SHADOW_CALL_STACK (1UL << 31) being highest individual
enumerator for enum sanitize_code. Use 'uint64_t' data type to allow
for more distinct instrumentation modes be added when needed.
gcc/ChangeLog:
Hi,
to assign debug locations to corresponding statements auto-fdo uses
discriminators. Documentation says that if given statement belongs to multiple
basic blocks, the discrminator distinguishes them.
Current implementation however only work fork statements that expands into a
squence of gimple
From: Claudiu Zissulescu
MEMTAG sanitizer, which is based on the HWASAN sanitizer, will invoke
the target-specific hooks to create a random tag, add tag to memory
address, and finally tag and untag memory.
Implement the target hooks to emit MTE instructions if MEMTAG sanitizer
is in effect. Con
From: Indu Bhagat
Add new command line option -fsanitize=memtag-stack with the following
new params:
--param memtag-instrument-alloca [0,1] (default 1) to use MTE insns
for enabling dynamic checking of stack allocas.
Along with the new SANITIZE_MEMTAG_STACK, define a SANITIZE_MEMTAG
which will b
This pattern enables the combine pass (or late-combine, depending on the case)
to merge a float_extend'ed vec_duplicate into a plus-mult or minus-mult RTL
instruction.
Before this patch, we have three instructions, e.g.:
fcvt.s.h fa5,fa5
vfmv.v.f v24,fa5
vfmadd.vv v8,v24,v16
The following adjusts how we set SLP_TREE_VECTYPE for the conversion
node we build when fixing up the reduction with conversion SLP instance.
This should probably see more TLC, but the following avoids relying
on STMT_VINFO_VECTYPE for this.
* tree-vect-slp.cc (vect_build_slp_instance): D
From: Claudiu Zissulescu
Memory tagging is used for detecting memory safety bugs. On AArch64, the
memory tagging extension (MTE) helps in reducing the overheads of memory
tagging:
- CPU: MTE instructions for efficiently tagging and untagging memory.
- Memory: New memory type, Normal Tagged Mem
SLP analysis of early break conditions asserts pattern recognition
canonicalized all of them. But the pattern can fail, for example
when vector types cannot be computed. So be graceful here, so
we don't ICE when we didn't yet compute vector types.
Bootstrapped and tested on x86_64-unknown-linux-
commit 77473a27bae04da99d6979d43e7bd0a8106f4557
Author: H.J. Lu
Date: Thu Jun 26 06:08:51 2025 +0800
x86: Also handle all 1s float vector constant
replaces
(insn 29 28 30 5 (set (reg:V2SF 107)
(mem/u/c:V2SF (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8 A64])) 2031
{*movv2sf_inte
LD1Q gathers and ST1Q scatters are unusual in that they operate
on 128-bit blocks (effectively VNx1TI). However, we don't have
modes or ACLE types for 128-bit integers, and 128-bit integers
are not the intended use case. Instead, the instructions are
intended to be used in "hybrid VLA" operations
The following removes an optimization that wrongly triggers right now
because it accesses LOOP_VINFO_COST_MODEL_THRESHOLD which might not be
computed yet.
Testing on x86_64 didn't reveal any testsuite coverage.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
PR tree-optimizatio
The size of the element of the FAM _cannot_ reliably depends on the original
TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE:
TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (gimple_call_arg (call, 5
when the element of the FAM has a variable length type. Since the vari
This is an improvement to the design of internal function .ACCESS_WITH_SIZE.
Currently, the .ACCESS_WITH_SIZE is designed as:
ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, CLASS_OF_SIZE,
TYPE_OF_SIZE, ACCESS_MODE, TYPE_SIZE_UNIT for element)
which returns the REF_TO_OBJ sa
From: Indu Bhagat
gcc/Changelog:
* asan.h (HWASAN_TAG_SIZE): Use targetm.memtag.tag_bitsize.
* config/i386/i386.cc (ix86_memtag_tag_size): Rename to
ix86_memtag_tag_bitsize.
(TARGET_MEMTAG_TAG_SIZE): Renamed to TARGET_MEMTAG_TAG_BITSIZE.
* doc/tm.texi (TAR
From: Claudiu Zissulescu
Hi,
Please find a new series of patches that implememnts stack sanitizer
using AArch64 MTE instructions. This new series is based on Indu
previous patch series.
What is new:
- Introduces a new target instruction tag_memory.
- Introduces a new target hook to deal with
From: Claudiu Zissulescu
Add a new target instruction. Hardware-assisted sanitizers on
architectures providing insstructions to tag/untag memory can then
make use of this new instruction pattern. For example, the
memtag-stack sanitizer uses these instructions to tag and untag a
memory granule.
g
On Thu, Jul 10, 2025 at 12:38 PM Robin Dapp wrote:
>
> Hi,
>
> this patch adds asserts that ensure we only expand an RDIV_EXPR with
> actual float mode. It also replaces the RDIV_EXPR in setting a
> vectorized loop's length by EXACT_DIV_EXPR. The code in question is
> only used with length-contr
This isn't the required refactoring of vect_check_gather_scatter
but it avoids a now unnecessary call to vect_is_simple_use which
is problematic because it looks at STMT_VINFO_VECTYPE which we
want to get rid of. SLP build already ensures vect_is_simple_use
on all lane defs, so all we need is to p
From: Indu Bhagat
Define new constants to be used by the MTE pattern definitions.
gcc/
* config/aarch64/aarch64.md (MEMTAG_TAG_MASK): New define
constant.
(MEMTAG_ADDR_MASK): Likewise.
(irg, subp, ldg): Use new constants.
Signed-off-by: Claudiu Zissulescu
---
From: Claudiu Zissulescu
Add a new target hook TARGET_MEMTAG_COMPOSE_OFFSET_TAG to perform
addition between two tags.
The default of this hook is to byte add the inputs.
Hardware-assisted sanitizers on architectures providing instructions
to compose (add) two tags like in the case of AArch64.
When analyzing the reduction cycle we look to determine the
reduction input vector type, for lane-reducing ops we look
at the input but instead of using vect_is_simple_use which
is problematic for SLP we should simply get at the SLP
operands vector type. If that's not set and we make up one
we sho
namaskaaram
Please find the patch attached. This addresses regression for MicroBlaze
(PR118280)
Atomic support enhanced to fix existing atomic_compare_and_swapsi pattern
to handle side effects; new patterns atomic_fetch_op and atomic_test_and_set
added. As MicroBlaze has no QImode test/set instru
This peephole pattern combines the following instructions:
bswap8:
rev8a5,a0
-> li a4,-65536
-> sraia5,a5,32
-> and a5,a5,a4
-> roriw a5,a5,16
and a0,a0,a4
or a0,a0,a5
sext.w a0,a0
ret
And emits th
On 7/10/25 8:37 AM, Jan Dubiec wrote:
On 10.07.2025 15:42, Jeff Law wrote:
[...]
Anyway, this has been repeatedly bootstrapped & regression tested on
aarch64, ppc64le and other targets. It's also been many dozens of
regression testing cycles on the various embedded targets.
This part of c
LGTM :)
On Thu, Jul 10, 2025 at 6:00 PM Robin Dapp wrote:
>
> Hi,
>
> Changes from v1:
> - Use Himode broadcast instead of float broadcast, saving two conversion
>insns.
>
> Let's be daring and leave the thorough testing to the CI first while my own
> testing is in progress :)
>
> This patch
On Thu, Jul 10, 2025, 4:12 AM
wrote:
> From: Indu Bhagat
>
> Currently, the data type of sanitizer flags is unsigned int, with
> SANITIZE_SHADOW_CALL_STACK (1UL << 31) being highest individual
> enumerator for enum sanitize_code. Use 'uint64_t' data type to allow
> for more distinct instrumenta
On Thu, Jul 10, 2025 at 1:57 PM H.J. Lu wrote:
>
> commit 77473a27bae04da99d6979d43e7bd0a8106f4557
> Author: H.J. Lu
> Date: Thu Jun 26 06:08:51 2025 +0800
>
> x86: Also handle all 1s float vector constant
>
> replaces
>
> (insn 29 28 30 5 (set (reg:V2SF 107)
> (mem/u/c:V2SF (symbol
The following makes us never consider vector(1) T types for
vectorization and ensures this during SLP build. This is a
long-standing issue for BB vectorization and when we remove
early loop vector type setting we lose the single place we have
that rejects this for loops.
Once we implement partial
> diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
> index 6753b01db59..866aaf1e8a0 100644
> --- a/gcc/config/riscv/vector.md
> +++ b/gcc/config/riscv/vector.md
> @@ -1580,8 +1580,27 @@ (define_insn_and_split "*vec_duplicate"
>"&& 1"
>[(const_int 0)]
>{
> -riscv_
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 6753b01db59..866aaf1e8a0 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -1580,8 +1580,27 @@ (define_insn_and_split "*vec_duplicate"
"&& 1"
[(const_int 0)]
{
-riscv_vector::emit_vlma
Hi all!
So, should we go on with the proposed fix inside `store_bit_field`? As
updating `gen_lowpart_common` seems kind of tricky, we should at least
prevent `store_bit_field` from generating non-canonical subregs.
Thanks,
Konstantinos
On Thu, Jun 12, 2025 at 10:47 AM Konstantinos Eleftheriou
w
OK to trunk, although I didn't build a RISC-V rtems toolchain, but I
believe you have verified that change :)
On Thu, Jul 10, 2025 at 1:55 PM Sebastian Huber
wrote:
>
> gcc/ChangeLog:
>
> * config/riscv/t-rtems: Add -mstrict-align multilibs for
> targets without support for misali
After vect_analyze_loop_operations is gone we can clean up
vect_analyze_stmt as it is no longer called out of SLP context.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vectorizer.h (vect_analyze_stmt): Remove stmt-info
and need_to_vectorize arguments.
On Thu, Jul 10, 2025 at 5:31 PM Robin Dapp wrote:
>
> >> diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
> >> index 6753b01db59..866aaf1e8a0 100644
> >> --- a/gcc/config/riscv/vector.md
> >> +++ b/gcc/config/riscv/vector.md
> >> @@ -1580,8 +1580,27 @@ (define_insn_and_split "*
Add a fold at gimple_fold_builtin to prefer the highpart variant of
a builtin if at least one argument is a vector highpart and any
others are VECTOR_CSTs that we can cheaply extend to 128-bits.
This eliminates data movement instructions. For example, we prefer
UMULL2 here over DUP+UMULL
uint16x
Hi all,
This is V3 of a fix for PR117850. V2 wasn't picked up or pinged by me as my
work changed quickly, so I've taken the opportunity here to fix it up a bit.
The major differences from V1 are based on the feedback given there.
There are two things that I'd like to note:
* This fold i
On 7/9/25 11:53 PM, Sebastian Huber wrote:
There are targets, which only offer 32-bit atomic operations (for
example 32-bit RISC-V). For these targets, split the 64-bit atomic
bitwise-or operation into two parts.
For this test case
int a(int i);
int b(int i);
int f(int i)
{
if (i) {
As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685733.html
the operand of the call should be a mem rather than an unspec.
This patch moves the unspec to an additional argument of the parallel
and adjusts cmse_nonsecure_call_inline_register_clear accordingly.
The scan-rtl-dump
On Thu, 10 Jul 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, July 10, 2025 1:31 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Richard Sandiford ; Tamar Christina
> > ; RISC-V CI
> > Subject: [PATCH] Reject single lane vector types for SLP b
On Thu, Jul 10, 2025 at 05:27:50PM +, Qing Zhao wrote:
> ACCESS_MODE is only for a future work to reimplement the attribute
> access with the internal function .ACCESS_WITH_SIZE.
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-access-function-attribute
>
> For th
> On Jul 10, 2025, at 13:27, Qing Zhao wrote:
>
>
>
>> On Jul 10, 2025, at 12:56, Jakub Jelinek wrote:
>>
>> On Thu, Jul 10, 2025 at 04:03:30PM +, Qing Zhao wrote:
>>> gcc/c-family/ChangeLog:
>>>
>>> * c-ubsan.cc (get_bound_from_access_with_size): Adjust the position
>>> of the argumen
This is the 2nd version of the patch.
update the changelog per Jacub's comments.
I will commit this version soon.
thanks.
Qing
This is an improvement to the design of internal function .ACCESS_WITH_SIZE.
Currently, the .ACCESS_WITH_SIZE is designed as:
ACCESS_WI
> On 1 Jul 2025, at 9:22 PM, Kyrylo Tkachov wrote:
>
>
>
>> On 1 Jul 2025, at 17:36, Richard Sandiford wrote:
>>
>> Soumya AR writes:
>>> From 2a2c3e3683aaf3041524df166fc6f8cf20895a0b Mon Sep 17 00:00:00 2001
>>> From: Soumya AR
>>> Date: Mon, 30 Jun 2025 12:17:30 -0700
>>> Subject: [PATC
Kyrylo Tkachov writes:
> Hi all,
>
> While the SVE2 NBSL instruction accepts MOVPRFX to add more flexibility
> due to its tied operands, the destination of the movprfx cannot be also
> a source operand. But the offending pattern in aarch64-sve2.md tries
> to do exactly that for the "=?&w,w,w" alte
On Linux/x86_64,
2fd6f42c17a8040dbd3460ca34d93695dacf8575 is the first bad commit
commit 2fd6f42c17a8040dbd3460ca34d93695dacf8575
Author: François Dumont
Date: Thu Mar 27 19:02:59 2025 +0100
libstdc++: Make debug iterator pointer sequence const [PR116369]
caused
FAIL: 23_containers/forw
On Linux/x86_64,
ad2bab693f74cad239615ba8725a691d435b3a97 is the first bad commit
commit ad2bab693f74cad239615ba8725a691d435b3a97
Author: Richard Biener
Date: Tue Jul 8 13:46:01 2025 +0200
Avoid IPA opts around guality plumbing
caused
FAIL: gcc.dg/guality/pr41447-1.c -O2 -DPREVENT_OPT
> On 18 Jun 2025, at 17:26, Kyrylo Tkachov wrote:
>
> Hi all,
>
> This adds support for -mcpu=gb10. This is a big.LITTLE configuration
> involving Cortex-X925 and Cortex-A725 cores. The appropriate MIDR numbers
> are added to detect them in -mcpu=native. We did not add an
> -mcpu=cortex-x925.c
On Thu, Jul 10, 2025 at 07:26:52AM +, Kyrylo Tkachov wrote:
> … “Tunning” looks like a typo as well, should likely be “Tuning”.
You're right, but because like often it occurs in another place as well,
I've committed this separately as obvious.
Thanks for finding this.
2025-07-10 Jakub Jelin
Hi,
This patch makes the zero-stride load broadcast idiom dependent on a
uarch-tunable "use_zero_stride_load". Right now we have quite a few
paths that reach a strided load and some of them are not exactly
straightforward.
While broadcast is relatively rare on rv64 targets it is more common on
> On 10 Jul 2025, at 10:40, Richard Sandiford wrote:
>
> Kyrylo Tkachov writes:
>> Hi all,
>>
>> While the SVE2 NBSL instruction accepts MOVPRFX to add more flexibility
>> due to its tied operands, the destination of the movprfx cannot be also
>> a source operand. But the offending pattern in
On Wed, 9 Jul 2025 at 20:21, Björn Schäpers wrote:
>
> Am 09.07.2025 um 16:16 schrieb Jonathan Wakely:
> > On Wed, 9 Jul 2025 at 15:13, Jonathan Wakely wrote:
> >>
> >> On Tue, 8 Jul 2025 at 21:47, Björn Schäpers wrote:
> >>> index 9923d14b7a7..bfbba077b92 100644
> >>> --- a/libstdc++-v3/src/c++2
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687530.html .
Thanks,
Konstantinos
On Thu, 10 Jul 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, July 10, 2025 6:42 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> > CI RISC-V
> > Subject: Re: [PATCH] Reject single lane vector types for S
On Fri, 11 Jul 2025, Jakub Jelinek wrote:
> Hi!
>
> As the following testcase shows e.g. on ia32, letting IPA opts change
> signature of functions which have [[{gnu,clang}::musttail]] calls
> can turn programs that would be compiled normally into something
> that is rejected because the caller ha
1 - 100 of 140 matches
Mail list logo
