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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118531
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
Richard Sandiford changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13/14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002
Richard Sandiford changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125
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=118976
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=116604
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Status: UNCONFIRMED
Keywords: missed-optimization, testsuite-fail
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118956
--- Comment #1 from Richard Sandiford ---
Created attachment 60541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60541&action=edit
candidate patch
This patch changes the patterns so that they don't require a scratch register
post-reload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118952
--- Comment #3 from Richard Sandiford ---
(In reply to ktkachov from comment #2)
> Thanks, yeah I don't see PR34678 getting generally resolved any time soon.
> Is there something we could do with these particular builtins to make them a
> strong
||a/show_bug.cgi?id=34678
CC||rsandifo at gcc dot gnu.org
--- Comment #1 from Richard Sandiford ---
I think this is essentially the same problem as PR34678.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116604
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=117978
--- Comment #5 from Richard Sandiford ---
(In reply to ktkachov from comment #4)
> Do we also need to guard this under TARGET_NON_STREAMING?
Hopefully it should work for all cases. LDR Q and STR Q are still available in
streaming mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118892
--- Comment #10 from Richard Sandiford ---
(In reply to Tamar Christina from comment #9)
> I swear that was something that was fixed. But in any case, the simplest
> fix is to force it into a reg again indeed.
>
> I'm slightly worried that thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118611
--- Comment #9 from Richard Sandiford ---
(In reply to Vladimir Makarov from comment #7)
> Unfortunately, although the patch solves the problem but it adds 2 x86-64
> failures of tests expecting smaller number of moves. It also adds 2
> failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608
--- Comment #12 from Richard Sandiford ---
(In reply to fengfei.xi from comment #11)
> could you please explain under what specific circumstances this change might
> lead to slower performance?
> Also, is there a more complete fix or any plans f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118755
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118328
--- Comment #14 from Richard Sandiford ---
(In reply to Sam James from comment #13)
> The request here notwithstanding, bug report(s) with testcases for missed
> opportunities in ipa-ra would be welcome too.
Agreed, if we find any. But just in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117477
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=115673
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #13 from Richard Sandiford ---
Mine
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #12 from Richard Sandiford ---
Mine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922
--- Comment #23 from Richard Sandiford ---
FWIW, running locally on x86 with fold_mem_offsets disabled (admittedly with
rtl checking), I see:
combiner : 0.91 ( 0%)21M ( 0%)
late combiner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922
--- Comment #21 from Richard Sandiford ---
I should have said, but: another reason for suggesting rtl-ssa is that it is
usually self-updating. My long-term hope is that we'll be able to maintain it
between passes, when we have consecutive passe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922
--- Comment #19 from Richard Sandiford ---
Mind if I take this and try converting it to rtl-ssa? I think that would be
more forward-looking, rather than adding more custom (dominator walk) code to
the pass itself. Also, the switch to rtl-ssa d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117202
Richard Sandiford changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117202
--- Comment #5 from Richard Sandiford ---
FWIW, gcc.target/riscv/rvv/autovec/struct/mask_struct_store_run-3.c seems to
produce similar VEC_PERM_EXPRs for SVE, but it works there.
The idea is that we're unpacking one vector of [16,16] chars into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 117270, which changed state.
Bug 117270 Summary: [15 Regression] 9% exec time slowdown of 538.imagick_r on
aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
|UNCONFIRMED
Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot
gnu.org
--- Comment #9 from Richard Sandiford ---
Probably best if I unassign myself then, because I don't really see where the
wrong code is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118650
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #7 from Richard Sandiford ---
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index c0550acf6b2..06cd6e42355 100644
--- a/gcc/tree-vect-stmts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
--- Comment #6 from Richard Sandiford ---
(In reply to rguent...@suse.de from comment #5)
> On Mon, 27 Jan 2025, rsandifo at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
> >
> > ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118669
--- Comment #4 from Richard Sandiford ---
Just to be sure I understand: is the PR simply about making the RTL
representation of the memory more correct? Or is it about generating different
code?
gcc dot gnu.org|unassigned at gcc dot
gnu.org
--- Comment #7 from Richard Sandiford ---
The problem seems to be in the modelling of the FRM register.
CALL_USED_REGISTERS says that the register is call-clobbered/caller-save, which
means:
(a) it is not treated as live on entry to the
||2025-01-24
Status|UNCONFIRMED |ASSIGNED
CC||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #6 from Richard Sandiford ---
Mine.
|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||rsandifo at gcc dot gnu.org
--- Comment #4 from Richard Sandiford ---
I think the problem is IRA rather than LRA.
As a result of the quoted instruction, IRA realises
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118562
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118562
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=118594
--- Comment #9 from Richard Sandiford ---
(In reply to Richard Sandiford from comment #8)
> But that doesn't work because force_operand considers the subreg to be valid
> (and general_operand agrees).
…because the subreg isn't paradoxical, I for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118594
--- Comment #8 from Richard Sandiford ---
I was going to say that force_subreg should call force_operand:
diff --git a/gcc/explow.cc b/gcc/explow.cc
index 7799a98053b..3f378174268 100644
--- a/gcc/explow.cc
+++ b/gcc/explow.cc
@@ -759,7 +759,9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118184
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 117186, which changed state.
Bug 117186 Summary: [12/13 Regression] aarch64 wrong code for (a < b) < (b < a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117186
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117186
Richard Sandiford changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12/13 Regression] aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118348
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118384
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118531
Richard Sandiford changed:
What|Removed |Added
Summary|[14/15 Regression] |[14 Regression]
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
Richard Sandiford changed:
What|Removed |Added
Summary|[14/15 regression] aarch64: |[14 regression] aarch64:
||rsandifo at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #6 from Richard Sandiford ---
Mine (after discussing with Tamar).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
Richard Sandiford changed:
What|Removed |Added
Assignee|tnfchris at gcc dot gnu.org|rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501
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=118547
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118544
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117013
Richard Sandiford changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Richar
1 - 100 of 1344 matches
Mail list logo
