https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121772
--- Comment #5 from Alex Coplan ---
Here's a fully-preprocessed reduced testcase; not for the testsuite, but just
to enable debugging with a cc1 cross:
typedef __Int16x4_t int16x4_t;
typedef __Int16x8_t int16x8_t;
short f(int16x4_t va) {
int1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121772
--- Comment #4 from Alex Coplan ---
Simplified testcase:
#include
int16_t f(int16x4_t b) {
return vaddvq_s16(vcombine_s16(b, vdup_n_s16 (0)));
}
: UNCONFIRMED
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:
$ cat t.c
#include
int16_t f(int16x4_t b) {
return vaddvq_s16
: UNCONFIRMED
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:
$ cat t.c
#include
uint32_t foo(uint64_t v0) {
return vqshrnd_n_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121604
--- Comment #3 from Alex Coplan ---
(In reply to Jennifer Schmitz from comment #2)
> Thanks for catching this.
> Both svbrka and svbrkb produce wrong code with _m predication. Same for
> svpmov_lane with _m and a pfalse predicate.
> The problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121604
--- Comment #1 from Alex Coplan ---
Here is a possibly-related case:
#include
svuint64_t f(svuint64_t zd, svbool_t p) {
return svpmov_lane_u64_m(svdup_u64(~0UL), svpfalse(), 1);
}
with -O2 -march=armv8.2-a+sve2p1 on trunk this gives:
f:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121599
--- Comment #3 from Alex Coplan ---
(In reply to Jennifer Schmitz from comment #2)
> I can confirm the ICE. Thanks for the report.
> However, I think that g5289540ed58e42ae66255e31f22afe4ca0a6e15e only
> revealed a previously existing problem by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121604
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121604
Alex Coplan changed:
What|Removed |Added
CC||jschmitz at gcc dot gnu.org
T
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 is miscompiled since
r15-5957-g5289540ed58e42ae66255e31f22afe4ca0a6e15e:
$ cat brkb.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121599
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121602
Alex Coplan changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121602
Alex Coplan changed:
What|Removed |Added
CC||jschmitz at gcc dot gnu.org
Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121602
Alex Coplan changed:
What|Removed |Added
Known to fail||15.2.0, 16.0
Keywords|
Status: UNCONFIRMED
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:
$ cat t.c
#include
svint8_t foo(int8_t v32, svbool_t v16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121599
Alex Coplan changed:
What|Removed |Added
CC||jschmitz at gcc dot gnu.org
Su
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:
$ cat t.c
#include
svuint8_t foo(svbool_t j, svuint8_t g, uint8_t e, svint8_t c) {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121315
--- Comment #5 from Alex Coplan ---
So if I artificially increase the cost of the ADDRESS_REG_REG case by 1 in
aarch64_address_cost, then we get the desired codegen:
.L3:
ldp q31, q30, [x2], 32
rev32 v31.16b, v31.16b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121315
--- Comment #4 from Alex Coplan ---
Yes, it looks to be faster using post-increment LDP/STP indeed. I think it
would be difficult to undo in pair-fusion, perhaps best to handle this earlier
(I guess in ivopts).
Generally pair-fusion requires a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121315
--- Comment #3 from Alex Coplan ---
Here is a reduced testcase (compile with -O3 -mcpu=neoverse-v2):
void copyReverseGeneric(int *dst, int *src) {
for (int i = 0; i < 1; ++i)
dst[i] = __builtin_bswap32(src[i]);
}
of course using LDP/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
--- Comment #12 from Alex Coplan ---
Fixed on trunk, will backport to 15 after a week or so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
--- Comment #9 from Alex Coplan ---
I'm now going to be away until Mon 4th August, so won't be able to post the
re-spun patches until then (although they are ready to go and have passed
testing).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
Alex Coplan changed:
What|Removed |Added
Keywords||patch
--- Comment #8 from Alex Coplan --
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat t.c
#pragma GCC aarch64 "arm_sve.h"
void e(__fp16 *p, __fp16 *out, int mode) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
--- Comment #7 from Alex Coplan ---
(In reply to Spencer Abson from comment #6)
> > The insn is recognised if +fp8dot4 is added, so I suspect the gating of
> > this insn is also wrong in the backend.
>
> Yeah, I suspect the issue is that:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
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=121027
--- Comment #4 from Alex Coplan ---
Interestingly the codegen seems to have regressed significantly after that
change, too. We used to get:
foo:
mov z2.h, #0
uzp1z0.h, z0.h, z1.h
zip2z0.h, z2.h, z0.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121027
--- Comment #3 from Alex Coplan ---
For completeness, the above testcase started ICEing with
r14-3571-gcaa7a99a052929d5970677c5b639e1fa5166e334, though I suspect the
problem can be reproduced before that revision with an alternative testcase.
F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121027
Alex Coplan changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails on the head of the 14 branch:
$ cat t.c
#include
typedef svbfloat16_t vls_bfloat16_t __attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
--- Comment #4 from Alex Coplan ---
I also get an unrecognisable insn ICE when compiling a variant of this testcase
where the FPMR has a compile-time unknown value:
$ cat t.c
#pragma GCC aarch64 "arm_sve.h"
svfloat16_t foo(svfloat16_t a, svmflo
||acoplan at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-07-10
--- Comment #3 from Alex Coplan ---
Confirmed. Here's a reproducer that works with just a cc1 and the stack trace:
$ cat t.c
#pragma GCC aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118567
--- Comment #5 from Alex Coplan ---
(In reply to Jakub Jelinek from comment #4)
> Any progress on this?
Patch waiting for approval here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/676539.html
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Consider the following testcase, on aarch64:
typedef struct {
long ob_refcnt;
int size;
} PyListObject;
PyListObject *src;
PyListObject dst;
int main(void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120718
Alex Coplan changed:
What|Removed |Added
Summary|[15/16 Regression] ICE |ICE (unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120718
Alex Coplan changed:
What|Removed |Added
Summary|[15/16 Regression] ICE |[15/16 Regression] ICE
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat small.cc
#include
struct A { int x; int y; };
struct B {
B(A);
};
void foo() {
B b{{0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120707
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357
Alex Coplan changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
--- Comment #6 from Alex Coplan ---
I suppose that example boils down to whether code like:
_Bool f(_Float16 a) {
return a * a >= 0;
}
_Bool g(float a) {
return a * a >= 0;
}
can be optimised to return true. We currently do it with -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357
--- Comment #3 from Alex Coplan ---
This version ICEs with just -O3 on AArch64 (no longer needs -fwhole-program),
and fixes the -Woverflow warning:
char a;
void b(int d, int o, unsigned long long t[][22], int u[]) {
for (int v = 0; v < d + 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357
Alex Coplan changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[15/16 Regression] RI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120307
--- Comment #3 from Alex Coplan ---
Created attachment 61468
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61468&action=edit
reduced testcase
Attached is a reduced testcase with optabs.ii down to 458 lines and optabs.gcda
reduced to 15,2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Created attachment 61441
--> https://gcc.gnu.org/bugzi
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following function:
_Bool f(unsigned long u64)
{
return (double)u64 >= 0.0;
}
at -O3 on AArch64, GCC generates:
f:
ucvtf d31,
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
I tried a profiledbootstrap on x86_64-linux-gnu at
r16-457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120065
--- Comment #5 from Alex Coplan ---
FWIW, the following testcase seems to be more representative of the original
problem I saw when looking at gcc.c-torture/execute/20060420-1.c:
$ cat t2.c
void foo(float *dst, float *src)
{
int j;
for (j =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120065
--- Comment #4 from Alex Coplan ---
Thanks for the analysis. I think this shows that the testcase I gave above was
overly-reduced. I should have mentioned in the initial report that this code
came from gcc/testsuite/gcc.c-torture/execute/20060
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following testcase on the trunk, the profile info gets corrupted by
dom2 (reproduced on both x86_64 and aarch64):
$ cat small.c
float *a;
int j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
Alex Coplan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
--- Comment #6 from Alex Coplan ---
Alright, so after some digging through the dumps I realised that adding
-fno-early-inlining is enough to get a non-LTO testcase. So the following
testcase reproduces the different codegen before/after the abo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119610
Alex Coplan changed:
What|Removed |Added
Summary|aarch64: Wrong unwind info |aarch64: Wrong unwind info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119610
Alex Coplan changed:
What|Removed |Added
Component|c++ |target
CC|
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat t.cc
void foo() {
int c[1024*128];
throw 1;
}
int main()
{
try {
foo();
} catch
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails on the trunk:
$ cat t.cc
template struct vector;
template class Optional;
class Filter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
Alex Coplan changed:
What|Removed |Added
Summary|[12/13/14 Regression] |[12/13 Regression] aarch64:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114991
--- Comment #9 from Alex Coplan ---
(In reply to Richard Biener from comment #8)
> Is this now fixed on trunk?
No, not really. The codegen at -O2 on trunk is:
f:
stp x29, x30, [sp, -144]!
mov x29, sp
add x0
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
For the following testcase (current trunk, aarch64):
$ cat t.c
int main(void)
{
int x;
for (int i = 0; i < 10; i++)
x += 1;
return x;
}
compiled with -O2 -W
at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Comment #5 from Alex Coplan ---
(In reply to Andrew Pinski from comment #2)
> >I've attached a reduced reproducer which (unfortunately) still requires LTO,
> >but it is at least fairly well reduced (only two small TUs).
&
: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Created attachment 60836
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #2 from Alex Coplan ---
I will take a look and try to reproduce/reduce.
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 Regression]
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
Alex Coplan changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #
at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Comment #6 from Alex Coplan ---
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 f32185b3eac..a7f9eae10d3 100644
--- a/gcc/df-problems.cc
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Since the ext-dce change r15-7915-g4ed07a11ee2845c2085a3cd5cff043209a452441,
there have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114492
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118320
Alex Coplan changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118320
Alex Coplan changed:
What|Removed |Added
Assignee|rsandifo at gcc dot gnu.org|acoplan at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
--- Comment #2 from Alex Coplan ---
A bisect points to r10-917-g3b47da42de621c6c3bf7d2f9245df989aa7eb5a1 :
commit 3b47da42de621c6c3bf7d2f9245df989aa7eb5a1
Author: Martin Jambor
Date: Thu Jun 6 17:31:20 2019
Make SRA re-construct orginal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following testcase is miscompiled on the trunk with -O2 and above, on
aarch64-linux-gnu:
$ cat small.cc
template
||2025-02-17
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
--- Comment #2 from Alex Coplan ---
Mine, this should be straightforward: the checking loop is now being vectorised
after the PFA
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|---
1 - 100 of 729 matches
Mail list logo
