https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117013
Richard Sandiford changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Richar
||2025-01-17
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Richard Sandiford ---
Mine.
Keywords: 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*-*-*
g:b096a6ebe9d9f9fed4c105f6555f724eb32af95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118328
--- Comment #11 from Richard Sandiford ---
Created attachment 60175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60175&action=edit
Proof-of-concept patch
Here's a lightly-tested proof-of-concept patch for preserve_none on AArch64.
In p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118377
--- Comment #10 from Richard Sandiford ---
(In reply to Tejas Belagod from comment #9)
> Technically, as this is not a regression, can we fix this to sorry more
> gracefully for GCC15 as 'Not yet implemented'?
Yeah. The testcase is IMO valid AC
: missed-optimization
Severity: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
[I'm filing this speculatively because I don't know whether the optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118418
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118418
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=117186
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=107102
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118301
--- Comment #6 from Richard Sandiford ---
(In reply to Jonathan Wakely from comment #5)
> We already have -std=c++2a for that and it doesn't solve anything.
You obviously know better than me :), but I thought c++2a was used for things
that aren'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118301
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118328
--- Comment #2 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #1)
> Note most of the use cases in my view for these attributes. These attributes
> are there specifically to work around the fact that llvm does not do ipa ra
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107102
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
We should consider implementing Clang's preserve_none attribute for AArch64
GCC. It should be relatively simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117938
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #6 from Richard Sandiford ---
This seems to go back to r0-29238
[https://gcc.gnu.org/pipermail/gcc-patches/2000-July/033786.html], for which
the code now looks like:
case COMPARE:
/* Convert (compare (gt (flags) 0
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #14 from Richard Sandiford ---
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118184
Richard Sandiford changed:
What|Removed |Added
Summary|[15 regression] glibc |[14 backport] glibc
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #9 from Richard Sandiford ---
early-ra is missing a check for cases in which a 128-bit value (or larger) is
modified at the individual word level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118215
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118133
--- Comment #3 from Richard Sandiford ---
The reason I went for m4 is that it means we don't need to write a parser, or
come up with a DSL. I was hoping that the scaffolding would be pretty much
write-and-forget, with only the main (declarative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117968
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
, missed-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
: normal
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*-*-*
#include
int
foo (svbool_t x, int y, int
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Created attachment 59927
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978
--- Comment #3 from Richard Sandiford ---
I think this would be better done in expand rather than gimple. The gimple
representation would be a vector load in a 128-bit type, followed by a zeroing
extension to the original SVE type. I'm not sur
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: acarlotti at gcc dot gnu.org, Alfie.Richards at arm dot com
Target Milestone: ---
For:
int f() __attribute__((symver("f@@VERS1.0")));
__attribute__((targ
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: acarlotti at gcc dot gnu.org, Alfie.Richards at arm dot com
Target Milestone: ---
For:
int f() asm("foo");
int f() { return 1; }
__attribute__((targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96340
--- Comment #2 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #1)
> was this also fixed by r14-6416-gf5fc001a84a7db ?
No, it's still unfixed due to:
/* We currently do not support generating simdclones where vector argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117850
--- Comment #3 from Richard Sandiford ---
(In reply to rguent...@suse.de from comment #2)
> I dont See how this is easier?
It's not to simplify things :) But isn't gimple_fold_builtin restricted to the
same search/valueisation domain as match.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117850
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
|1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Richard Sandiford ---
Thanks for the reproducer. I'll try to have a look soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704
--- Comment #9 from Richard Sandiford ---
That's because clobbers of hard-coded registers have usually been treated as
kind-of an earlyclobbers:
-
When a @code{clobber} expression for a register appears insid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117297
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116371
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117297
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=117248
--- Comment #2 from Richard Sandiford ---
Also, could you check whether g:9bd19ff515c95af71b29bc6e232785532afa6823 makes
a difference?
: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
int f1(int x) { return x < 0 || x & 3; }
on aarch64 produces:
f1:
tbn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550
--- Comment #12 from Richard Sandiford ---
(In reply to denisc from comment #4)
> Explanation.
> […]
Thanks for the great explanation! Based on that, the patch LGTM FWIW, although
Vlad should have the final say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #389 from Richard Sandiford ---
(In reply to Oleg Endo from comment #304)
> (define_insn "block_lump_real"
> [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
> (mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
Richard Sandiford changed:
What|Removed |Added
Known to work||15.0
Summary|[14/15 Regr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117045
--- Comment #3 from Richard Sandiford ---
Ah, yeah, the patch fixes that too. The easiest fix seemed to be to handle the
degenerate cases up-front rather than as part of constant folding.
I deliberately left off folding svwhilelt(INT_MAX, x) t
|1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Last reconfirmed||2024-10-09
--- Comment #1 from Richard Sandiford ---
I'll send a patch soon.
y: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
#include
#include
svbool_t f() { return svwhilele_b8_s32(INT_MAX, INT_MAX); }
is folded to:
ptrue p0.b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109498
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578
Bug 116578 depends on bug 116583, which changed state.
Bug 116583 Summary: vectorizable_slp_permutation cannot handle even/odd extract
from VLA vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
--- Comment #10 from Richard Sandiford ---
I have a proof-of-concept hack (far from submission quality). But it looks
like some cases will also require us to extend aarch64_evpc_reencode to handle
SVE modes, which is also worthwhile for its own
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #9 from Richard Sandiford ---
Mine. Lets see if I can remember how this “vectoriser” thing works…
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116629
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=116583
--- Comment #7 from Richard Sandiford ---
...actually, they probably don't need to bijective. I suppose
[0, 0] for two-lane SLP is handled too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583
--- Comment #6 from Richard Sandiford ---
Sorry for the slow response (here and in general). Been having to
spend my time on other things recently :(
I agree that this case is regular enough to handle for VLA, but it
seems to me like a separat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
--- Comment #8 from Richard Sandiford ---
(In reply to Georg-Johann Lay from comment #7)
> What about the following line in reload1.h:
>
> // Used during roload -> LRA transition because ELIMINABLE_REGS may depend
> // on command line options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
--- Comment #6 from Richard Sandiford ---
(In reply to Georg-Johann Lay from comment #5)
> > But either way, I think we should start with the assumption that the entry
> > should be removed and make everything else work to that. Unfortunately t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
--- Comment #4 from Richard Sandiford ---
(In reply to Georg-Johann Lay from comment #3)
> It was due to problems with multi-reg frame-pointer. (AFAIR, using a
> hard-frame-poiner besides frame-poiner didn't resolve the issues.)
>
> My problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116516
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
--- Comment #10 from Richard Sandiford ---
(In reply to Richard Sandiford from comment #9)
> If the tag bit is dropped by going
> out of bounds, that's a feature, not a bug, and would happen equally for
> void*/char* arithmetic as for (u)intptr_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116481
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #3 from Richard Sandiford ---
Gah, mine then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116254
Richard Sandiford changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116254
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116238
Richard Sandiford changed:
What|Removed |Added
Known to fail|15.0|14.2.1
Summary|[12/13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
--- Comment #17 from Richard Sandiford ---
Hmm, but if the ICE is coming from vregs then it doesn't sound like it's
related to LRA. vregs is the first RTL pass to run.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
--- Comment #14 from Richard Sandiford ---
Created attachment 58967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58967&action=edit
Patch for the decompse_mem_address ICE
Thanks. Can you try the attached patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
--- Comment #11 from Richard Sandiford ---
I can't reproduce this with m68k-elf. Do you have any local changes beyond
making TARGET_LRA_P return true?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #5 from Richard Sandiford ---
Yeah, seems to be a latent bug in aarch64_hard_regno_caller_save_mode. A
brute-force reproducer is:
void foo();
typedef unsigned char v2qi __attribute__((vector_size(2)));
void f(v2qi *ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115683
--- Comment #8 from Richard Sandiford ---
(In reply to Uroš Bizjak from comment #7)
> Richi, maybe tree optimizers can perform their optimizations with
> vec_cmp{,u} and vcond_mask, and at the end provide the true coditional
> vector move (that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114603
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607
Richard Sandiford changed:
What|Removed |Added
Known to work||12.4.1, 13.3.1, 14.1.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115464
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939
Bug 113939 depends on bug 116236, which changed state.
Bug 116236 Summary: [LRA] [M68K] ICE insn does not satisfy its constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116343
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #22 from Richard Sandiford ---
(In reply to Michael Matz from comment #21)
> (In reply to Richard Sandiford from comment #17)
> > > But if LRA needs to be extended for correctness, then, ... meh.
> > But this is how it's always worke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116371
--- Comment #2 from Richard Sandiford ---
Fixed on trunk. I'll wait a bit before backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116371
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
The intrinsics for PEXT are supposed to be called svpext_lane_cN and
svpext_lane_cN_x2, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #19 from Richard Sandiford ---
Of course, immediately after posting I realise it should be address_mode
instead of pointer_mode, but that shouldn't affect m68k.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #18 from Richard Sandiford ---
Created attachment 58927
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58927&action=edit
Candidate patch
Could you try the attached patch? It seems to fix the reduced testcase for me.
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #17 from Richard Sandiford ---
(In reply to Michael Matz from comment #16)
> (In reply to Richard Sandiford from comment #15)
> > > Yes, I considered adding this handling of (zero_extend Rx) to LRA. I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #15 from Richard Sandiford ---
(In reply to Michael Matz from comment #14)
> (In reply to Richard Sandiford from comment #13)
> > (In reply to Michael Matz from comment #12)
> > > That's why I struggle a bit, I lack the bigger pictur
|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #5 from Richard Sandiford ---
Argh, substituting into the REG_EQUAL note is causing INSN_CODE to be reset.
Testing a patch…
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116343
--- Comment #4 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #3)
> Note I think late_combine 1 depends on DCE later on to delete the
> noop_move_p instructions but since -fno-dce was passed on the command line,
> it is not d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116312
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30920
--- Comment #8 from Richard Sandiford ---
The patch in comment 7 is just one step.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145
Richard Sandiford changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116200
Richard Sandiford changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30920
Richard Sandiford changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116145
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=116145
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115881
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116109
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
1 - 100 of 1245 matches
Mail list logo
