https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115120
Bug ID: 115120
Summary: Bad interaction between ivcanon and early break
vectorization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #20 from Alex Coplan ---
I'd just like to ping this serious wrong code bug. It's unfortunate that this
wasn't addressed for the 14.1 release.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
Alex Coplan changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
--- Comment #2 from Alex Coplan ---
Here is some analysis on why we miss some of these opportunities in ldp_fusion.
So initially in 267r.vregs we have some very clean RTL:
6: r101:DI=sfp:DI-0x40
7: x0:DI=r101:DI
8: call [`g']
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
Alex Coplan changed:
What|Removed |Added
Last reconfirmed||2024-05-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114936
Alex Coplan changed:
What|Removed |Added
Summary|[14/15 Regression] Typo in |[14 Regression] Typo in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114936
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114936
Bug ID: 114936
Summary: [14/15 Regression] Typo in
aarch64-ldp-fusion.cc:combine_reg_notes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Bug ID: 114924
Summary: [11/12/13/14/15 Regression] Wrong update of MEM_EXPR
by RTL loop unrolling since r11-2963-gd6a05b494b4b71
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
Bug ID: 114801
Summary: [14 Regression] arm: ICE in find_cached_value, at
rtx-vector-builder.cc:100 with MVE intrinsics
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114492
Alex Coplan changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #4 from Alex Coplan ---
I think the problem is that the arm backend incorrectly sets the const
attribute on this builtin, but it can't be const because it reads memory (it
should be pure instead):
sizes-gimplified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
--- Comment #1 from Alex Coplan ---
Hmm, so in 043t.mergephi1 we have:
uint32x4_t foo ()
{
const uint32_t D.13439[4];
uint32x4_t V0;
:
D.13439 = *.LC0;
V0_3 = vld1q_u32 ();
D.13439 ={v} {CLOBBER(eos)};
return V0_3;
}
but then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114323
Bug ID: 114323
Summary: [14 Regression] MVE vector load intrinsic miscompiled
since r14-5622-g4d7647edfd7d98
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114291
Bug ID: 114291
Summary: -fcompare-debug failure (length) with -fprofile-use at
-O0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
--- Comment #3 from Alex Coplan ---
I think this has been fixed by
r14-9379-ga0e945888d973fc1a4a9d2944aa7e96d2a4d7581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114284
Bug ID: 114284
Summary: [14 Regression] arm: Load of volatile short gets
miscompiled (loaded twice)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114193
Bug ID: 114193
Summary: missed early break vectorization of reduction
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114192
Bug ID: 114192
Summary: scalar code left around following early break
vectorization of reduction
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
--- Comment #4 from Alex Coplan ---
(In reply to Richard Biener from comment #3)
> As said X + 0. -> X is an invalid transform with FP unless there are no
> signed zeros (maybe also problematic with sign-dependent rounding).
Yeah, I was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
--- Comment #2 from Alex Coplan ---
I think to progress this and related cases we need to have .MASK_LOAD defined
to zero in the case that the predicate is false (either unconditionally for all
targets if possible or otherwise conditionally for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Summary|[12 Regression] darktable |darktable build on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #30 from Alex Coplan ---
Backport for GCC 12 submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645415.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #12 from Alex Coplan ---
Here is an alternative testcase that also fails in the same way on the GCC 12
and 13 branches:
void foo(int x, int y, int z, int d, int *buf)
{
for(int i = z; i < y-z; ++i)
for(int j = 0; j < d; ++j)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Summary|[12/13 Regression] |[12 Regression] darktable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #7 from Alex Coplan ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896
>
> Which means it is related to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #4 from Alex Coplan ---
Same with the head of the GCC 12 branch, but I agree it isn't a [14 Regression]
as I can reproduce the issue with basepoints/gcc-14, so maybe something was
backported to 12/13 that is making it latent on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #3 from Alex Coplan ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a 14 Regression?
> Seems r12-5166 works fine while r12-6600 already doesn't, so that would make
> it [12/13/14 Regression], no?
Well on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Bug ID: 113787
Summary: [14 Regression] Wrong code at -O with ipa-modref on
aarch64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113705
Alex Coplan changed:
What|Removed |Added
Summary|[14 Regression] ICE in |[14 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113705
Alex Coplan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #25 from Alex Coplan ---
Proposed fix for GCC 13:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644459.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Keywords||patch
--- Comment #24 from Alex Coplan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Keywords|needs-bisection |
Known to fail|13.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113658
Alex Coplan changed:
What|Removed |Added
Last reconfirmed||2024-01-30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113661
Bug ID: 113661
Summary: [14 Regression] xalancbmk miscompiled on aarch64 since
r14-7194-g6cb155a6cf3142
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113616
Alex Coplan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
--- Comment #5 from Alex Coplan ---
Indeed passing -mearly-ra=none makes the ICE go away as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|acoplan at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Alex Coplan changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
--- Comment #3 from Alex Coplan ---
I think ldp_fusion is exposing a latent issue here. We trip the assert:
gcc_assert (aarch64_mem_pair_lanes_operand (mem, pair_mode));
on the RTL:
(rr) pr mem
(mem/f:V2x8QI (reg:DI 63 v31) [0 +0 S16 A64])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113616
Alex Coplan changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Alex Coplan changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113616
--- Comment #3 from Alex Coplan ---
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Alex Coplan changed:
What|Removed |Added
Last reconfirmed||2024-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113616
--- Comment #2 from Alex Coplan ---
I think the problem is this loop (and others that iterate over debug
uses in this way):
// Now that we've characterized the defs involved, go through the
// debug uses and determine how to update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113616
Alex Coplan changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
--- Comment #6 from Alex Coplan ---
FWIW, if I move ldp_fusion1 before early_ra, with:
diff --git a/gcc/config/aarch64/aarch64-passes.def
b/gcc/config/aarch64/aarch64-passes.def
index 769d48f4faa..3853f6bf7a4 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
--- Comment #5 from Alex Coplan ---
It looks like the current ordering of passes is:
early_ra
sched1
ldp_fusion1
early_remat
ISTM that ldp_fusion1 should probably be running before early_ra, but we found
that running ldp_fusion1 before sched1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|acoplan at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
Alex Coplan changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #20 from Alex Coplan ---
I think the testcase in #c10 went latent on the 13 branch but the following
(reduced from the attachment) still ICEs on the tip of the 13 branch with
-Ofast -fopenmp -fstack-protector-strong:
typedef struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #9 from Alex Coplan ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Alex Coplan from comment #7)
> > I expect the store pairs come from memcpy lowering/expansion in the aarch64
> > backend, that is the only way we get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #7 from Alex Coplan ---
I expect the store pairs come from memcpy lowering/expansion in the aarch64
backend, that is the only way we get store pairs so early in the RTL pipeline
IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #6 from Alex Coplan ---
Looking at the dump files, the first difference seems to be in 292r.dse1:
8: NOTE_INSN_BASIC_BLOCK 2
2: r116:SI=zero_extend(x0:HI)
REG_DEAD x0:HI
@@ -178,7 +161,26 @@
5:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #4 from Alex Coplan ---
Created attachment 57211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57211=edit
after.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #3 from Alex Coplan ---
Created attachment 57210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57210=edit
before.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #2 from Alex Coplan ---
(In reply to Richard Biener from comment #1)
> I will have a look - but can you explain for me what I see? I suppose the
> testcase was reduced from something?
Yeah, the testcase is reduced.
>
> Is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
Bug ID: 113597
Summary: [14 Regression] aarch64: Significant code quality
regression since r14-8346-ga98d5130a6dcff
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113356
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113070
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113546
--- Comment #5 from Alex Coplan ---
FWIW the original preprocessed testcase (regex.i) also started failing with the
same commit (as the reduced testcase).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113546
Alex Coplan changed:
What|Removed |Added
Keywords||compare-debug-failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113546
Bug ID: 113546
Summary: aarch64: bootstrap-debug-lean broken with
-fcompare-debug failure
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
--- Comment #4 from Alex Coplan ---
Reproduces with just -O3 -fno-strict-aliasing FWIW, no LTO or -mcpu needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
Bug ID: 113539
Summary: [14 Regression] perlbench miscompiled on aarch64 since
r14-8223-g1c1853a70f
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
Alex Coplan changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
--- Comment #7 from Alex Coplan ---
Testing a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089
Alex Coplan changed:
What|Removed |Added
URL||https://patchwork.sourcewar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113494
Bug ID: 113494
Summary: [14 Regression] ICE (segfault) in
slpeel_tree_duplicate_loop_to_edge_cfg since
r14-8206-g0f3880d6ad0e
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
--- Comment #6 from Alex Coplan ---
Hmm, it's worth noting that the ILP32 case is a bit different, though, in that
we have:
(rr) call debug (insn->rtl ())
(insn 16 21 19 3 (parallel [
(set (reg:DF 62 v30)
(unspec:DF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113184
Alex Coplan changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113221
Alex Coplan changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089
--- Comment #11 from Alex Coplan ---
Testing a patch, sorry for the delay on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
--- Comment #5 from Alex Coplan ---
Hmm, so initially (with the testcase in c3) we have:
ldp s30, s29, [x0, #-4]
...
add x0, x0, #-4
and we try to form:
ldp s30, s29, [x0, #-4]!
with this RTL:
(rr) call debug (pair_change.m_insn->rtl ())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
--- Comment #4 from Alex Coplan ---
(The above was reduced from gcc/testsuite/gcc.dg/torture/pr45720.c FWIW).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114
--- Comment #3 from Alex Coplan ---
The following ICEs in the same way without ILP32 (reduced from a testsuite run
with -funroll-loops):
$ cat t.c
float val[128];
float x;
void bar() {
int i = 55;
for (; i >= 0; --i)
x += val[i];
}
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113449
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438
--- Comment #1 from Alex Coplan ---
I also noticed the following C23 failures, not sure if these are worth tracking
separately or not:
FAIL: gcc.dg/gnu23-tag-1.c (internal compiler error: 'verify_type' failed)
FAIL: gcc.dg/gnu23-tag-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113438
Bug ID: 113438
Summary: ICE (segfault) in dwarf2out_decl with -g -std=c23 on
c23-tag-composite-2.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113356
Alex Coplan changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113070
Alex Coplan changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113070
--- Comment #7 from Alex Coplan ---
Just to give a concrete example / reduced testcase where this goes wrong (to
aid review). For the following testcase (reduced from libiberty) with -O2
-mlate-ldp-fusion:
struct {
unsigned D;
int E;
} *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113070
--- Comment #6 from Alex Coplan ---
And with those fixes it indeed looks like profiledbootstrap + LTO with all
frontends on aarch64 is working again (with the passes enabled).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113356
--- Comment #3 from Alex Coplan ---
... i13 to be a hazard w.r.t. itself, then we might not even need the clause in
the follow-up fix. I'll investigate.
Alternatively the assert can probably be relaxed to include the previous
nondebug insn,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113356
--- Comment #2 from Alex Coplan ---
So we have this IR:
insn i8 in bb2 [ebb2] at point 18:
+
|8: [r104:DI++]=r101:DI
| REG_DEAD r101:DI
| REG_INC r104:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113356
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
1 - 100 of 580 matches
Mail list logo
