https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118320
--- Comment #8 from Alex Coplan ---
Sorry, I'm now away until Tuesday 11th Feb so likely won't be able to look at
this before then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117790
Alex Coplan changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103680
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
I noticed that profile_estimate builds an inconsistent profile for this
testcase:
./xgcc -B . -c ~/toolchain/src/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117790
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following loop (testcase modified from gcc.dg/tree-ssa/cunroll-14.c):
$ cat t.c
int a[100];
void f()
{
for (int i = 0; i < 100 && a[i]; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117476
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails (reduced from perlbench_r from SPEC CPU 2017):
$ cat t.c
unsigned long *a;
int i;
void f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116783
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116783
--- Comment #8 from Alex Coplan ---
Should be fixed everywhere, I'll leave this open for a bit until we get
confirmation that this fixes the Debian package build with GCC 14, though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116783
Alex Coplan changed:
What|Removed |Added
Summary|[14/15 Regression] Wrong|[14 Regression] Wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683
Alex Coplan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683
--- Comment #5 from Alex Coplan ---
Ah, so the problem seems to be that we're scanning for "Unrolled loop 3 times"
appearing exactly once in the dump, but on powerpc it appears twice; that is
because the loop in main gets unrolled too (presumabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683
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=116683
--- Comment #3 from Alex Coplan ---
Sorry for the delay in looking into this.
So it looks like the unrolling works as expected without LTO, at least I see:
;; Unrolled loop 3 times, constant # of iterations 26 insns
in the dump with a powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116783
--- Comment #4 from Alex Coplan ---
Testing a fix for the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116783
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Created attachment 59150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59150&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140
--- Comment #14 from Alex Coplan ---
This should be largely fixed now (and in a position to get further improvements
from vectorisation further down the line), perhaps folks that monitor x86_64
performance can confirm if they see the expected im
,
||aarch64-linux-gnu
Last reconfirmed||2024-09-11
CC||acoplan at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116600
Alex Coplan changed:
What|Removed |Added
Summary|internal compiler error: in |internal compiler error: in
|NEW
CC||acoplan at gcc dot gnu.org
Last reconfirmed||2024-09-04
--- Comment #2 from Alex Coplan ---
Confirmed. ICEs with -O3 -fno-common all the way back to GCC 7.
|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||acoplan at gcc dot gnu.org,
||jschmitz at gcc dot gnu.org
--- Comment #1 from Alex Coplan ---
Confirmed. Started with r15-3082
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
Alex Coplan changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
--- Comment #2 from Alex Coplan ---
Here's a preprocessed testcase (not for the testsuite, just to make it easier
to reproduce using only cc1):
#pragma GCC aarch64 "arm_neon.h"
typedef double float64_t;
__extension__ extern __inline void
__at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140
--- Comment #9 from Alex Coplan ---
I think all except the first patch in the series (C++ patch) have been approved
now, so the rest are waiting on review for that:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661559.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522
--- Comment #5 from Alex Coplan ---
The following should fix it:
diff --git a/gcc/testsuite/lib/scanltranstree.exp
b/gcc/testsuite/lib/scanltranstree.exp
index a7d4de3765f..3d85813ea2f 100644
--- a/gcc/testsuite/lib/scanltranstree.exp
+++ b/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116522
--- Comment #4 from Alex Coplan ---
Testing a fix.
at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Comment #3 from Alex Coplan ---
Apologies for the breakage, I think this is the usual problem of
dg-cmp-results.sh not reporting new ERRORs (which is why I didn't see this in
my regression testing). I need to work out a better w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140
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=116140
--- Comment #7 from Alex Coplan ---
So it turns out the reason #pragma GCC unroll doesn't work under LTO is because
we don't propagate the `has_unroll` flag when streaming functions during LTO,
so RTL loop2_unroll ends up not running at all.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140
--- Comment #6 from Alex Coplan ---
Just to give an update on this, the following testcase shows why adding:
#pragma GCC unroll 4
in libstdc++ doesn't immediately seem to help. The testcase is:
$ cat lambda.cc
template
inline Iter
my_find(It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140
--- Comment #5 from Alex Coplan ---
Yeah, I'm looking into this as Tamar mentioned above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
--- Comment #4 from Alex Coplan ---
So the following is enough to fix the missed ldp due to alias analysis:
diff --git a/gcc/pair-fusion.cc b/gcc/pair-fusion.cc
index 31d2c21c88f..ab49d955ccf 100644
--- a/gcc/pair-fusion.cc
+++ b/gcc/pair-fusio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114936
Alex Coplan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Consider the following testcase on aarch64:
int arr[1024];
int *f()
{
int i;
for (i = 0; i < 1024; i++)
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.
at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Comment #3 from Alex Coplan ---
Mine for the aliasing issues/investigation, might be worth splitting off the RA
problem to track that separately.
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'] argc:0
|UNCONFIRMED |NEW
CC||acoplan at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Ever confirmed|0 |1
Keywords||missed-optimization, ra
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
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
aarch64-ldp-fusion.cc:combine_reg_notes has:
result = filter_notes (REG_NOTES (i2->rtl ()), res
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
: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following testcase is reduced from
libgomp/testsuite/libgomp.fortran/imperfect
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following testcase:
#include
uint32x4_t test_9() {
return vdupq_m_n_u32(vdupq_n_u32(0), 0
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
at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Comment #4 from Alex Coplan ---
I think these should be OK. In the case of:
for (unsigned i = 0; i < changes.length (); i++)
gcc_assert (rtl_ssa::restrict_movement_ignoring (*changes[i],
is_changing));
I think this is OK because
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 unsi
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);
D.13439 ={v} {CLOBBER(eos)};
return V0_3;
}
b
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following testcase:
#include
uint32x4_t foo (void) {
uint32x4_t V0 = vld1q_u32(((const uint32_t[4]){1, 2
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following is an -fcompare-debug failure that shows up with PGO (here on
aarch64-linux-gnu):
$ cat t.c
void foo() {}
int main(void
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
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following is a wrong code regression in GCC 14:
volatile short x;
short foo() {
return x;
}
with -march=armv8
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following loop:
int a[1024];
int f(int *x, int n)
{
int sum = 0;
for (int i = 0; i < n; i++)
{
if (a[i] == 42)
br
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following testcase:
int a[1024];
int f4(int *x, int n)
{
int sum = 0;
for (int i = 0; i < n
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 thinkin
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 110
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 b
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 the
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following testcase appears to be miscompiled on the trunk, on
aarch64-linux-gnu:
$ cat t.c
void foo(int x, int y, int z
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
||acoplan at gcc dot gnu.org
Last reconfirmed||2024-02-01
Ever confirmed|0 |1
--- Comment #2 from Alex Coplan ---
Confirmed. Here is a reduced testcase that ICEs with -O2 on aarch64-linux-gnu:
void free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
Alex Coplan changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12/13 Regression]
|dar
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
|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Comment #5 from Alex Coplan ---
(In reply to Jakub Jelinek from comment #3)
> Obviously using __has_builtin is much better t
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
xalancbmk (both from SPEC 2006 and SPEC 2017) seems to be miscompiled on
aarch64 since r14-7194
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
||14.0
Target||aarch64-*-*
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Comment #2 from Alex Coplan ---
Confirmed, mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113616
--- Comment #3 from Alex Coplan ---
Testing a patch.
|1
Status|UNCONFIRMED |NEW
CC||acoplan at gcc dot gnu.org
--- Comment #1 from Alex Coplan ---
Confirmed.
(In reply to Wilco from comment #0)
> A possible fix would be to avoid emitting LDP/STP in mem
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
Target||aarch64-*-*
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Alex Coplan ---
Confirmed, mine.
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
--- a/gcc/config/aarch64/aar
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
Su
dot gnu.org |acoplan at gcc dot
gnu.org
Last reconfirmed||2024-01-26
Status|UNCONFIRMED |ASSIGNED
--- Comment #3 from Alex Coplan ---
Confirmed, I'll take a look.
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
1 - 100 of 657 matches
Mail list logo
