[Bug target/115258] [14/15 Regression] register swaps for vector perm in some cases after r14-6290

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115258 Richard Sandiford changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug c++/115192] [11/12/13/14 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115192 Richard Sandiford changed: What|Removed |Added Summary|[11/12/13/14/15 regression] |[11/12/13/14 regression]

[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115192 Richard Sandiford changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug tree-optimization/114635] OpenMP reductions fail dependency analysis

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114635 --- Comment #19 from Richard Sandiford --- (In reply to Richard Biener from comment #14) > Usually targets do have a limit on the actual length but I see > constant_upper_bound_with_limit doesn't query such. But it would > be a more

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #14 from Richard Sandiford --- Yeah, I think so.

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #12 from Richard Sandiford --- (In reply to Peter Bergner from comment #11) > > > but how are users supposed to know whether > > > -fno-omit-frame-pointer is in effect or not? I've looked and there is no > > > pre-defined macro a

[Bug rtl-optimization/114664] -fno-omit-frame-pointer causes an ICE during the build of the greenlet package

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664 --- Comment #10 from Richard Sandiford --- (In reply to Peter Bergner from comment #7) > Then that would seem to indicate that mentioning the frame pointer reg in > the asm clobber list is an error Yeah, I agree it's an error. The PR says

[Bug target/114607] aarch64: Incorrect expansion of svsudot

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607 --- Comment #2 from Richard Sandiford --- Fixed on trunk. I'll backport in a few weeks if there's no fallout.

[Bug target/114607] aarch64: Incorrect expansion of svsudot

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org

[Bug target/114607] New: aarch64: Incorrect expansion of svsudot

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607 Bug ID: 114607 Summary: aarch64: Incorrect expansion of svsudot Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority:

[Bug target/114603] aarch64: Invalid SVE cnot optimisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114603 Richard Sandiford changed: What|Removed |Added Last reconfirmed||2024-04-05

[Bug target/114603] New: aarch64: Invalid SVE cnot optimisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114603 Bug ID: 114603 Summary: aarch64: Invalid SVE cnot optimisation Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority:

[Bug target/114577] Inefficient codegen for SVE/NEON bridge

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114577 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED CC|

[Bug target/114521] [11 only] aarch64: wrong code with Neon ld1/st1x4 intrinsics gcc-11 and earlier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114521 Richard Sandiford changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org ---

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515 --- Comment #5 from Richard Sandiford --- For the record, the associated new testsuite failures are: FAIL: gcc.target/aarch64/ashltidisi.c scan-assembler-times asr 3 FAIL: gcc.target/aarch64/asimd-mull-elem.c scan-assembler-times

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515 --- Comment #4 from Richard Sandiford --- (In reply to Richard Biener from comment #1) > Btw, why does forwprop not do this? Not 100% sure (I wasn't involved in choosing the current heuristics). But fwprop can propagate across blocks, so there

[Bug rtl-optimization/114515] [14 Regression] Failure to use aarch64 lane forms after PR101523

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515 --- Comment #3 from Richard Sandiford --- In RTL terms, the dup is vec_duplicate. The combination is: Trying 10 -> 13: 10: r107:V4SF=vec_duplicate(r115:SF) REG_DEAD r115:SF 13: r110:V4SF=r111:V4SF*r107:V4SF REG_DEAD

[Bug rtl-optimization/114515] New: [14 Regression] Failure to use aarch64 lane forms after PR101523

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515 Bug ID: 114515 Summary: [14 Regression] Failure to use aarch64 lane forms after PR101523 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords:

[Bug sanitizer/97696] ICE since ASAN_MARK does not handle poly_int sized varibales

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302 --- Comment #5 from Richard Sandiford --- (In reply to Andrew Stubbs from comment #4) > Yes, that's what the simd-math-3* tests do. Ah, OK. > The simd-math-5* tests are explicitly supposed to be doing this in the > context of the

[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302 --- Comment #3 from Richard Sandiford --- Ah, ok. If the main aim is to test the libgcc routines, it might be safer to use something like: typedef char v64qi __attribute__((vector_size(64))); v64qi f(v64qi x, v64qi y) { return x / y; }

[Bug target/114302] [14 Regression] GCN regressions after: vect: Tighten vect_determine_precisions_from_range [PR113281]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114302 --- Comment #1 from Richard Sandiford --- The decision to stop narrowing division was deliberate, see the comments in PR113281 for details. Is the purpose of the test to check vectorisation quality, or to check for the right ABI routines?

[Bug tree-optimization/114234] New: [14 Regression] verify_ssa failure with early-break vectorisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234 Bug ID: 114234 Summary: [14 Regression] verify_ssa failure with early-break vectorisation Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords:

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441 Richard Sandiford changed: What|Removed |Added Attachment #57602|0 |1 is obsolete|

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441 --- Comment #41 from Richard Sandiford --- (In reply to Richard Biener from comment #40) > So I wonder if we can use "local costing" to decide a gather is always OK > compared to the alternative with peeling for gaps. On x86 gather tends > to

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441 --- Comment #39 from Richard Sandiford --- (In reply to Richard Sandiford from comment #38) > (In reply to Richard Biener from comment #37) > > Even more iteration looks bad. I do wonder why when gather can avoid > > peeling for GAPs using

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441 --- Comment #38 from Richard Sandiford --- (In reply to Richard Biener from comment #37) > Even more iteration looks bad. I do wonder why when gather can avoid > peeling for GAPs using load-lanes cannot? Like you say, we don't realise that all

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441 --- Comment #36 from Richard Sandiford --- Created attachment 57602 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57602=edit proof-of-concept patch to suppress peeling for gaps This patch does what I suggested in the previous comment:

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441 --- Comment #35 from Richard Sandiford --- Maybe I've misunderstood the flow of the ticket, but it looks to me like we do still correctly recognise the truncating scatter stores. And, on their own, we would be able to convert them into masked

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441 --- Comment #33 from Richard Sandiford --- Can you give me a chance to look at it a bit when I back? This doesn't feel like the way to go to me.

[Bug tree-optimization/113441] [14 Regression] Fail to fold the last element with multiple loop since g:2efe3a7de0107618397264017fb045f237764cc7

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113441 --- Comment #31 from Richard Sandiford --- (In reply to Tamar Christina from comment #29) > This works fine for normal gather and scatters but doesn't work for widening > gathers and narrowing scatters which only the pattern seems to handle.

[Bug target/98877] [AArch64] Inefficient code generated for tbl NEON intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98877 Richard Sandiford changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org ---

[Bug sanitizer/97696] ICE since ASAN_MARK does not handle poly_int sized varibales

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696 --- Comment #3 from Richard Sandiford --- Created attachment 57520 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57520=edit Candidate patch The attached patch seems to fix it. I'm taking next week off, but I'll run the patch through

[Bug sanitizer/97696] ICE since ASAN_MARK does not handle poly_int sized varibales

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696 Richard Sandiford changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org

[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205 --- Comment #12 from Richard Sandiford --- Created attachment 57511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57511=edit Candidate patch Sorry for the very slow response on this. I'm testing the attached.

[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346 since r14-3220

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org

[Bug target/112922] [14 Regression] 465.tonto from SPECFP 2006 fails train run on Aarch64-linux with -O2 and -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 112922, which changed state. Bug 112922 Summary: [14 Regression] 465.tonto from SPECFP 2006 fails train run on Aarch64-linux with -O2 and -flto https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922 What

[Bug target/113295] [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 113295, which changed state. Bug 113295 Summary: [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a

[Bug target/113613] [14 Regression] Missing ldp/stp optimization since r14-6290-g9f0f7d802482a8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/113295] [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295 --- Comment #6 from Richard Sandiford --- For me the miscompilation is in jkdmem_, where we end up allocating the same registers to both arms of an fcsel. It sounds like it occurs elsewhere too. I have a candidate fix, but need to think a bit

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #14 from Richard Sandiford --- I might have misunderstood the suggestion and so be arguing against something that no-one is suggesting, but I think [[__extension__ …]] should accept the same things for all standard versions (C23,

[Bug target/113995] ICE: in change_address_1, at emit-rtl.cc:2299 with [[arm::streaming_compatible]] and -march=armv9-a+sve -finstrument-functions -fstack-clash-protection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113995 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/113220] [aarch64] ICE Segmentation fault with r14-6178-g8d29b7aca15133

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113220 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/113295] [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org

[Bug target/112922] [14 Regression] 465.tonto from SPECFP 2006 fails train run on Aarch64-linux with -O2 and -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922 --- Comment #2 from Richard Sandiford --- I don't remember there being a deliberate bug fix in that patch, but there were some others later. I suppose the optimistic case is that this first went latent and then was fixed “properly” afterwards.

[Bug target/113778] ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1506 with -march=armv9-a+sme -fhardened

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113778 Richard Sandiford changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug target/113220] [aarch64] ICE Segmentation fault with r14-6178-g8d29b7aca15133

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113220 Richard Sandiford changed: What|Removed |Added CC||zsojka at seznam dot cz ---

[Bug target/113805] sme2 vs -mtrack-speculation, ICE in extract_insn, at recog.cc:2812 with r14-6178-g8d29b7aca15133

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113805 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/113995] ICE: in change_address_1, at emit-rtl.cc:2299 with [[arm::streaming_compatible]] and -march=armv9-a+sve -finstrument-functions -fstack-clash-protection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113995 Richard Sandiford changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org

[Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 Richard Sandiford changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org ---

[Bug target/113778] ICE: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx code_label) in PATTERN, at rtl.h:1506 with -march=armv9-a+sme -fhardened

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113778 Richard Sandiford changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0

[Bug target/113805] sme2 vs -mtrack-speculation, ICE in extract_insn, at recog.cc:2812 with r14-6178-g8d29b7aca15133

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113805 Richard Sandiford changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #14 from Richard Sandiford --- AFAIK, the constructor shouldn't be necessary. (And without it, the whole thing would fit on one line.) LGTM (and preapproved) otherwise. Thanks for doing this.

[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #11 from Richard Sandiford --- Currently away so can't try it myself, but how about just using an ad-hoc structure instead?

[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #34 from Richard Sandiford --- (In reply to Richard Biener from comment #32) > Btw, AVX512 knotb will invert all 8 bits and there's no knot just affecting > the lowest 4 or 2 bits. > > It all feels like desaster waiting to happen

[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #30 from Richard Sandiford --- (In reply to Richard Biener from comment #29) > But that's just for CONSTRUCTORs, we got the VIEW_CONVERT_EXPR path for > VECTOR_CSTs. But yeah, that _might_ argue we should perform the same > masking

[Bug debug/113636] [14 Regression] internal compiler error: in dead_debug_global_find, at valtrack.cc:275 since r14-6290-g9f0f7d802482a8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113636 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug target/111677] [12/13 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677 --- Comment #21 from Richard Sandiford --- (In reply to Alex Coplan from comment #13) > The problem seems to be this code in aarch64_process_components: > > while (regno != last_regno) > { > bool frame_related_p =

[Bug target/113623] [14 Regression] ICE in aarch64_pair_mem_from_base since r14-6605

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623 Richard Sandiford changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug debug/113636] [14 Regression] internal compiler error: in dead_debug_global_find, at valtrack.cc:275 since r14-6290-g9f0f7d802482a8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113636 Richard Sandiford changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0

[Bug tree-optimization/113281] Wrong code due to vectorization of shift reduction and missing promotions since r14-3027

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 --- Comment #24 from Richard Sandiford --- Fixed on trunk so far, but it's latent on branches. I'll see what the trunk fallout is like before asking about backports.

[Bug target/113613] [14 Regression] Missing ldp/stp optimization since r14-6290-g9f0f7d802482a8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613 Richard Sandiford changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #18 from Richard Sandiford --- (In reply to Tamar Christina from comment #17) > Well the mid-end has generated the right precision. The type it generates is > vector(4) vexit_reduc_67; > so it does say it's a single bit boolean. >

[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #16 from Richard Sandiford --- (In reply to Richard Biener from comment #15) > I think the problem is the cbranch pattern which looks at all of the > QImode mask - but of course it doesn't know it's really V4BImode it's > working on

[Bug target/113550] data512_t initializers dereference a clobbered register

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113550 Richard Sandiford changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org

[Bug target/113485] [14 regression] ICE with -fno-guess-branch-probability on aarch64 starting with r14-7187-g74e3e839ab2d36

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug target/113572] [14 Regression] aarch64: internal compiler error in aarch64_sve::vector_cst_all_same

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #13 from Richard Sandiford --- I don't think there's any principle that upper bits must be zero. How do we end up with a pattern that depends on that being the case?

[Bug tree-optimization/113281] [14 Regression] Wrong code due to vectorization of shift reduction and missing promotions since r14-3027

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org

[Bug target/113572] [14 Regression] aarch64: internal compiler error in aarch64_sve::vector_cst_all_same

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org

[Bug target/113485] [14 regression] ICE with -fno-guess-branch-probability on aarch64 starting with r14-7187-g74e3e839ab2d36

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485 Richard Sandiford changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from

[Bug target/109929] profiledbootstrap failure on aarch64-linux-gnu with graphite optimization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109929 --- Comment #7 from Richard Sandiford --- Hmm, yeah, like you say, neither of those commits should have made a different to whether bootstrap works. I guess the problem is just latent now.

[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267 --- Comment #12 from Richard Sandiford --- I don't object to the patch, but for the record: the current heuristics go back a long way. Although I reworked the pass to use rtl-ssa a few years ago, I tried as far as possible to preserve the old

[Bug target/113196] [14 Regression] Failure to use ushll{,2}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113196 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/112989] [14 Regression] GC ICE with C++, `#include ` and `-fsanitize=address`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112989 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug target/112989] [14 Regression] GC ICE with C++, `#include ` and `-fsanitize=address`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112989 --- Comment #12 from Richard Sandiford --- > another is try > #pragma GCC aarch64 "arm_sve.h" > after a couple of intentional declarations of the SVE builtins with > non-standard return/argument types and make sure that while it emits some >

[Bug target/112989] [14 Regression] GC ICE with C++, `#include ` and `-fsanitize=address`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112989 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org

[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type since r14-6524

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113270 --- Comment #8 from Richard Sandiford --- Thanks for trying it, and sorry for not doing it myself. The patch LGTM FWIW, so preapproved if it passes testing (which I'm sure it will :))

[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type since r14-6524

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113270 --- Comment #6 from Richard Sandiford --- I think we want the patch in comment 3, but in addition, I then also needed to use the following for a similar SVE case: extern GTY(()) tree scalar_types[NUM_VECTOR_TYPES + 1]; tree

[Bug tree-optimization/113104] Suboptimal loop-based slp node splicing across iterations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113104 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/68703] __attribute__((vector_size(N))) template member confusion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68703 Richard Sandiford changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org ---

[Bug target/113220] [aarch64] ICE Segmentation fault with r14-6178-g8d29b7aca15133

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113220 Richard Sandiford changed: What|Removed |Added CC|richard.sandiford at arm dot com |rsandifo at gcc dot gnu.org

[Bug target/113196] [14 Regression] Failure to use ushll{,2}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113196 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org

[Bug target/113196] New: [14 Regression] Failure to use ushll{,2}

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113196 Bug ID: 113196 Summary: [14 Regression] Failure to use ushll{,2} Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal

[Bug tree-optimization/113104] Suboptimal loop-based slp node splicing across iterations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113104 Richard Sandiford changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug tree-optimization/113091] Over-estimate SLP vector-to-scalar cost for non-live pattern statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113091 --- Comment #5 from Richard Sandiford --- > The issue here is that because the "outer" pattern consumes > patt_64 = (int) patt_63 it should have adjusted _2 = (int) _1 > stmt-to-vectorize > as being the outer pattern root stmt for all this

[Bug target/113094] [14 Regression][aarch64] ICE in extract_constrain_insn, at recog.cc:2713 since r14-6290-g9f0f7d802482a8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113094 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/112948] gcc/config/aarch64/aarch64-early-ra.cc:1953: possible cut'n'paste error ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112948 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/113094] [14 Regression][aarch64] ICE in extract_constrain_insn, at recog.cc:2713 since r14-6290-g9f0f7d802482a8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113094 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org

[Bug rtl-optimization/111702] [14 Regression] ICE: in insert_regs, at cse.cc:1114 with -O2 -fstack-protector-all -frounding-math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111702 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug target/113027] New: aarch64 is missing vec_set and vec_extract for structure modes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113027 Bug ID: 113027 Summary: aarch64 is missing vec_set and vec_extract for structure modes Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug tree-optimization/109543] Avoid using BLKmode for unions with a non-BLKmode member when possible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543 --- Comment #5 from Richard Sandiford --- I think the loop in compute_mode_layout needs to be smarter for unions. At the moment it's sensitive to field order, which doesn't make much conceptual sense. E.g. for the admittedly contrived

[Bug middle-end/80283] [11/12/13/14 Regression] bad SIMD register allocation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283 --- Comment #39 from Richard Sandiford --- (In reply to Andrew Pinski from comment #38) > For aarch64, the test from comment #11 is so much worse on the trunk than in > GCC 13.2.0. I've been working on a fix for that. I'm hoping to post it

[Bug target/112948] gcc/config/aarch64/aarch64-early-ra.cc:1953: possible cut'n'paste error ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112948 Richard Sandiford changed: What|Removed |Added Last reconfirmed||2023-12-11

[Bug target/112933] gcc.target/aarch64/sme2/acle-asm/read_za16_vg1x2.c fails on aarch64_be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112933 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug target/112931] gcc.target/aarch64/sme2/acle-asm/write_za16_vg1x2.c ICEs on aarch64_be

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112931 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

  1   2   3   4   5   6   7   >