-sme, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
For:
extern __thread int x;
i
|1
Last reconfirmed||2025-08-05
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #1 from Richard Sandiford ---
Mine.
RMED
Keywords: aarch64-sme, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
For:
vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120718
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121294
Richard Sandiford changed:
What|Removed |Added
Summary|Incorrect optimisation of |[13/14/15 Backport]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121293
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121358
--- Comment #6 from Richard Sandiford ---
That makes it sound like the same issue as PR120718:
https://inbox.sourceware.org/gcc-patches/mpta55xpfro@arm.com/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121294
Richard Sandiford changed:
What|Removed |Added
Last reconfirmed||2025-07-29
Ever confirmed|0
-sve, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
#include
svbool_t
foo ()
{
return svtrn1_b16
||2025-07-29
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #1 from Richard Sandiford ---
I have a patch.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Compiling:
#pragma GCC aarch64 "arm_sve.h"
svint32_t f(s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121027
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121027
--- Comment #10 from Richard Sandiford ---
Fixed. I backported both r15-4111-g4fd473f66faf5bd95c84fe5c0fa41be735a7c09f
and the trunk fix for the code quality regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121218
--- Comment #12 from Richard Sandiford ---
On the REG_DEAD thing: REG_DEAD notes are not kept up-to-date, so any pass that
wants to use them needs to ask for them to be recomputed. The REG_DEAD usage
in scalar_chain::convert_insn_common suggest
|1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Last reconfirmed||2025-07-16
--- Comment #1 from Richard Sandiford ---
Mine.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
[https://godbolt.org/z/fYffh9bn8]
Compiling:
typedef __SVBool_t fixed_bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059
--- Comment #11 from Richard Sandiford ---
> if (masked_loop_p
> && code == BIT_AND_EXPR
> && VECTOR_BOOLEAN_TYPE_P (vectype))
> {
> if (loop_vinfo->scalar_cond_masked_set.contains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121059
--- Comment #10 from Richard Sandiford ---
(In reply to Richard Biener from comment #9)
> vectorizable_operation during transform does
>
> /* When combining two masks check if either of them is elsewhere
> combined with a
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #5 from Richard Sandiford ---
Mine for the backport. I'll have a look at the code quality regression too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
Richard Sandiford changed:
What|Removed |Added
Summary|[14/15/16 regression] gcc |[14/15 regression] gcc 14
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #23 from Richard Sandiford ---
I've posted a couple of patches that should help with this:
* https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688599.html
* https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688605.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120624
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120733
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120347
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #7 from Richard Sandiford ---
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120750
Richard Sandiford changed:
What|Removed |Added
Last reconfirmed||2025-06-23
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120745
--- Comment #2 from Richard Sandiford ---
Created attachment 61697
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61697&action=edit
Candidate patch
Hmm, yeah. Could you try the attached patch? It seems to work for this
testcase and pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120721
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120721
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113027
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120624
Richard Sandiford changed:
What|Removed |Added
Known to work||16.0
Summary|aarch64: In
|1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Last reconfirmed||2025-06-10
--- Comment #1 from Richard Sandiford ---
Testing a patch.
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
For:
#include
void callee();
__arm_new("za") __arm_locally_streamin
|UNCONFIRMED |WAITING
CC||rsandifo at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #8 from Richard Sandiford ---
I'm not sure why you're getting an illegal instruction, but the conditional
SMS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #9 from Richard Sandiford ---
I think the ICE is caused by a bad interaction between the AArch64 optimisation
and r16-718, which added more checks for paradoxical subregs. The testcase
works if r16-718 is reverted.
I think the shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #8 from Richard Sandiford ---
I think we've already got the right condition for partial modes:
/* If the predicate in operands[2] is a patterned SVE PTRUE predicate
with patterns VL1, VL2, VL4, VL8, or VL16 and at most the bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #6 from Richard Sandiford ---
I think a paradoxical VNx4QI subreg of QI is logically ok, but I'd need to
think a bit more about what the exact conditions should be. I don't think we
should rush into an aarch64 workaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119610
Richard Sandiford changed:
What|Removed |Added
Known to work||12.4.1
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901
--- Comment #14 from Richard Sandiford ---
ISTM that the problem is that cselib doesn't consider:
(clobber (mem:BLK (scratch)))
to be a read from memory (unlike note_uses, which gets this right). cselib
instead assumes that the SET_SRC of t
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
CC||rsandifo at gcc dot gnu.org
--- Comment #3 from Richard Sandiford ---
Mine then.
: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: amdgcn*-*-*
The following pattern is infinitely recursive. It looks like it should be
calling "vec_cmp..." r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120050
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966
--- Comment #6 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #4)
> validate_subreg allows the paradoxical subreg even in the case of hard
> register:
> ```
> /* Paradoxical subregs must have offset zero. */
> if (maybe_
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
AAPCS64 defined __fp16 and __bf16 to map to the same fundamental data type: a
half-precision floating-point
||rsandifo at gcc dot gnu.org
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
--- Comment #1 from Richard Sandiford ---
Removing the PTEST wouldn't be correct in isolation, since RDFFRS+B.LAST would
test the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113416
Bug 113416 depends on bug 101018, which changed state.
Bug 101018 Summary: ICE when enabling OpenMP on a simple loop with SVE
intrinsics (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118443
Bug 118443 depends on bug 119399, which changed state.
Bug 119399 Summary: [12 Backport] Overlap check in vectorized code may invoke UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 116125, which changed state.
Bug 116125 Summary: [12 Regression] Does not fully checking for overlapping
memory regions with the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119133
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115258
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
Richard Sandiford changed:
What|Removed |Added
Summary|Overlap check in vectorized |[12/13/14 Backport] Overlap
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #5 from Richard Sandiford ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
--- Comment #5 from Richard Sandiford ---
(In reply to rguent...@suse.de from comment #4)
> >, so for a 4-element
> > vector, the only problem cases are p==q+4, p==q+8 and p==q+12. That's
> > equivalent to testing whether the unsigned value p-(
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #3 from Richard Sandiford ---
Taking for the pointer difference.
(In reply to Richard Biener from comment #2)
> Still the actual alias check looks prone to overflow issues since we do
> not distinguish before/after pla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119689
--- Comment #14 from Richard Sandiford ---
(In reply to Richard Biener from comment #13)
> diff --git a/gcc/lra-remat.cc b/gcc/lra-remat.cc
> index 2f3afffcf5b..5f823193aa7 100644
> --- a/gcc/lra-remat.cc
> +++ b/gcc/lra-remat.cc
> @@ -460,7 +46
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #10 from Richard Sandiford ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104200
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116595
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
--- Comment #9 from Richard Sandiford ---
(In reply to ktkachov from comment #8)
> Richard, do you think this is something early-ra in aarch64 is well-placed
> to address? Or is there perhaps a realistic IRA solution?
I don't think the RAs can ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
--- Comment #10 from Richard Sandiford ---
(In reply to Richard Sandiford from comment #9)
> … Or perhaps we
> could do the optimisation in gimple, so that there is only one loop-carried
> dependency coming into expand.
That is, replace:
[loc
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #28 from Richard Sandiford ---
I'm back from holiday, so taking.
(In reply to Segher Boessenkool from comment #26)
> So, the one thing I really worry about a bit: will everything still work if
> we can lose some l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119495
--- Comment #2 from Richard Sandiford ---
(In reply to Filip Kastl from comment #0)
> So my understanding is that this slowdown isn't really that important.
> However, it seemed reasonable to at least notify Richard Sandiford about
> this in ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #23 from Richard Sandiford ---
(In reply to Segher Boessenkool from comment #22)
> (In reply to Richard Sandiford from comment #18)
> > but: the problem in PR101523 was that, after each
> > successful 2->2 attempt, distribute_links w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #20 from Richard Sandiford ---
(In reply to Richard Sandiford from comment #18)
> Still more than 0% of course, but nevertheless much less than before.
than before the fix for PR101523 went in, I mean.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #18 from Richard Sandiford ---
Created attachment 60754
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60754&action=edit
Proof of concept patch with hard-coded limit
I'd been reluctant to get involved in this for fear of creat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119287
--- Comment #4 from Richard Sandiford ---
(In reply to Jakub Jelinek from comment #3)
> tree_nop_conversion_p certainly doesn't imply the two types are compatible
> types.
> So, I think we should go with
> --- gcc/match.pd.jj 2025-03-13 14:05:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
CC||rsandifo at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2025-03-13
--- Comment #4 from Richard Sandiford ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115248
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115248
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118956
--- Comment #4 from Richard Sandiford ---
XFAILed for GCC 15, keeping open for the actual fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 116238, which changed state.
Bug 116238 Summary: [12 Regression] ICE building 526.blender_r on aarch64 SVE
after r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116238
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116238
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117045
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117045
--- Comment #8 from Richard Sandiford ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
--- Comment #7 from Richard Sandiford ---
(In reply to Alex Coplan from comment #6)
> So I'm testing the following to do this (which so far survives bootstrap on
> aarch64):
>
> diff --git a/gcc/df-problems.cc b/gcc/df-problems.cc
> index f3218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119114
--- Comment #21 from Richard Sandiford ---
Perhaps I'm missing the point, but I don't think we should look at 1 vs -1 for
. has only a single bit. That bit is
interpreted as a sign bit for extension purposes, but that only matters when an
ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116901
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119174
--- Comment #13 from Richard Sandiford ---
(In reply to Jeffrey A. Law from comment #11)
> Andrew. You're missing the point. This scenario isn't the kind of thing
> that reload and LRA are supposed to fix. They fix constraint problems. ie,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119133
Richard Sandiford changed:
What|Removed |Added
Summary|[14/15 Regression] ICE: |[14 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
Richard Sandiford changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119156
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
--- Comment #5 from Richard Sandiford ---
(In reply to Richard Biener from comment #3)
> We document
>
> class dr_with_seg_len
> {
> ...
> /* The minimum common alignment of DR's start address, SEG_LEN and
> ACCESS_SIZE. */
> unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119142
--- Comment #1 from Richard Sandiford ---
Sorry, I thought Honza had regression-tested it on x86, but I realise now that
I didn't confirm whether he had. I reverted the patch in
r15-7862-g2c6ab4c443ae3278.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118957
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117477
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #2 from Richard Sandiford ---
Mine.
1 - 100 of 1399 matches
Mail list logo
