https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Bug ID: 113622
Summary: r14-8450 regression: ICE with vectors in named
registers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Jakub Jelinek changed:
What|Removed |Added
Summary|ICE with vectors in named |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113621
--- Comment #2 from anlauf at gcc dot gnu.org ---
I guess the following reduced testcase shows the same crash:
program test
implicit none
character(4) :: c(7) = "*"
call three_val (c)
contains
subroutine three_val (i, j)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113580
Nathaniel Shead changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 113580, which changed state.
Bug 113580 Summary: -Wunused-parameter in template imported from module causes
segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113580
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
Andrew Pinski changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
Kacper Słomiński changed:
What|Removed |Added
CC||kacper.slominski72 at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113526
--- Comment #2 from Thiago Jung Bauermann
---
I verified the fix here.
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Bug ID: 113623
Summary: [14 Regression] ICE in aarch64_pair_mem_from_base
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
seurer at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #5 from Andrew Pinski ---
Here is a "valid" x86_64 testcase:
```
typedef float __attribute__ ((vector_size (64))) vec;
register vec a asm("zmm2"), b asm("zmm0"), c asm("zmm1");
void
test (void)
{
for (int i = 0; i < 8; i++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #11 from H.J. Lu ---
Created attachment 57233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57233=edit
An untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113623
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] ICE in |[14 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #18 from Andrew Pinski ---
Hmm. this loop should almost definitely get vectorized if vect_double is true:
for (i=0;ic+i) = num__infty;
I wonder why it is not on powerpc.
vect_double for powerpc does:
|| ([istarget
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #24)
> Currently gfortran does the following:
>
> character(20) :: fmt
> character(9) :: buffer
> fmt = "(1a1,d0.2,1a1)"
> write(buffer,fmt) ">", 3.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
--- Comment #6 from Andrew Pinski ---
(In reply to Patrick Palka from comment #5)
> Seems to be a name lookup issue ultimately:
>
> struct A {
> template
> struct B;
>
> template
> struct B {
> int x = V::value; // error: 'V' has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.9.1
Summary|r14-8450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #6 from Andrew Pinski ---
The assert by the way:
```
if (!MEM_P (to_rtx))
{
/* We can get constant negative offsets into arrays with broken
user code. Translate this to a trap
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=113580
--- Comment #1 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:ec57d183d35412aa5e0bcd7a448ccb75a4e1eab7
commit r14-8462-gec57d183d35412aa5e0bcd7a448ccb75a4e1eab7
Author: Nathaniel Shead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113625
Bug ID: 113625
Summary: Interesting behavior with and without -mcpu=generic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908
--- Comment #6 from anlauf at gcc dot gnu.org ---
Studying the cases that ICE (CLASS array dummy) and testcase PR95331.f90
which fixes an unlimited polymorphic problem, I tried the following change:
diff --git a/gcc/fortran/trans-array.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #19 from Andrew Pinski ---
(In reply to seurer from comment #17)
> This still fails on power.
Just so I can start to trying to reproduce it, how was your compiler
configured? I want to make sure the testsuite choices are done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314
--- Comment #11 from GCC Commits ---
The master branch has been updated by Maciej W. Rozycki :
https://gcc.gnu.org/g:3e3b9b708d390074f7825401b808e0ed41552c1d
commit r14-8459-g3e3b9b708d390074f7825401b808e0ed41552c1d
Author: Maciej W. Rozycki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109419
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
--- Comment #3 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #2)
> x86_64 Testcase (which invokes undefined behavior) which has been failing
> since at least 4.9.1 even:
> ```
> typedef double __attribute__ ((vector_size (16)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #15 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:861997a9c7088da25ed4dc0bd339060ca063514f
commit r14-8457-g861997a9c7088da25ed4dc0bd339060ca063514f
Author: Robin Dapp
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113600
--- Comment #4 from Martin Jambor ---
(In reply to Hongtao Liu from comment #2)
> A patch is posted at
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640276.html
>
> Would you give a try to see if it fixes the regression, I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113621
Bug ID: 113621
Summary: New test case gfortran.dg/optional_absent_10.f90 from
r14-8400-g186ae6d2cb93ad fails
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2024-01-26
Ever confirmed|0
x86_64-w64-mingw32
Configured with: ../configure --disable-multilib --disable-nls
--target=x86_64-w64-mingw32 --prefix=/tmp/rt/mingw14
--with-sysroot=/tmp/rt/mingw14
--enable-languages=c,ada,c++,d,fortran,lto,m2,objc,obj-c++,rust
Thread model: win32
Supported LTO compression algorithms: zlib zstd
gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
Roger Sayle changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #21 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #20)
> vect_long_mult is wrong again for powerpc (32bit).
>
> vect_long_mult should return true for ILP32 powerpc still. Because long is
> 32bit there ...
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #13 from Oleg Endo ---
(In reply to Roger Sayle from comment #12)
> It should be mentioned that the fwprop fix for PR11267 also resolved several
> FAILs in gcc.target/sh/pr59533.c. I mention this as tweaking the cost of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #27 from Jerry DeLisle ---
(In reply to anlauf from comment #26)
> (In reply to Jerry DeLisle from comment #24)
> > Currently gfortran does the following:
> >
> > character(20) :: fmt
> > character(9) :: buffer
> > fmt =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113621
--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to seurer from comment #0)
> This appears to be a problem just on big endian.
This is only for -m32, right?
> Program received signal SIGSEGV: Segmentation fault - invalid memory
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #6)
> This is currently regtesting.
Regtesting succeeded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113627
--- Comment #1 from Andrew Pinski ---
My gut feeling is there is some variable is not being treated as atomic.
That is there is a race condition somewhere. I am not saying you example code
has a race condition in it but rather that seems like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113626
Bug ID: 113626
Summary: The r14-8450 commit causes the loongarch
[x]vfcmp-{d/f}.c test case to fail
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Andrew Pinski changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113626
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113627
Bug ID: 113627
Summary: Detached tasks released without call to
omp_fulfill_event
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608
--- Comment #5 from GCC Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:5200ef26ac1771a75596394c20c5f1a348694d5e
commit r14-8465-g5200ef26ac1771a75596394c20c5f1a348694d5e
Author: Lewis Hyatt
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
H.J. Lu changed:
What|Removed |Added
Attachment #57233|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #6 from Patrick O'Neill ---
I think I may have messed up when copy/pasting the testcase. Please try this
testcase:
struct {
signed b;
} c, d = {6};
short e, f;
int g[1000];
signed char h;
int i, j;
long k, l;
long m(long n, long
LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240126 (experimental) (gd40b3c1e439)
COLLECT_GCC_OPTIONS='-O3' '-march=rv64gcv' '-o' 'user-config-o3.out' '-v'
'-mtune=rocket' '-mabi=lp64d' '-misa-spec=20191213'
'-march=rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #7 from Robin Dapp ---
Yep, that one fails for me now, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113567
--- Comment #3 from Andrew Pinski ---
Also here is one which fails even at -O1:
```
_BitInt(128+1) a1;
void foo(_BitInt(128+1) a, int i)
{
__label__ lab, lab1;
i &=1;
void *p[] = {&, &};
lab:
a %= 3;
a1 = a;
i = !i;
goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #8 from JuzheZhong ---
Ok. I can reproduce it too.
I am gonna work on fixing it.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113602
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=113612
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113567
--- Comment #2 from Andrew Pinski ---
(In reply to Marek Polacek from comment #1)
> Started with r14-4592:
Better testcase that does not depend on a very large size:
```
void
foo(_BitInt(128+1) a)
{
lab:
a %= 3;
void *p = &
goto *p;
}
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=113607
--- Comment #9 from JuzheZhong ---
Hi, Robin.
Could you try this case on latest ARM SVE ?
with -march=armv8-a+sve -O3 -fno-vect-cost-model.
I want to make sure first it is not an middle-end bug.
The RVV vectorized IR is same as ARM SVE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #12 from Andrew Pinski ---
Let test tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
Richard Sandiford changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #10 from rguenther at suse dot de ---
On Fri, 26 Jan 2024, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
>
> --- Comment #9 from Robin Dapp ---
> (In reply to rguent...@suse.de from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113615
Bug ID: 113615
Summary: internal compiler error: in extract_insn, at
recog.cc:2812
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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=113607
--- Comment #11 from JuzheZhong ---
(In reply to Robin Dapp from comment #10)
> The compile farm machine I'm using doesn't have SVE.
> Compiling with -march=armv8-a -O3 pr113607.c -fno-vect-cost-model and
> running it returns 0 (i.e. ok).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #13 from JuzheZhong ---
Ok. I found a regression between rvv-next and trunk.
I believe it is GCC-12 vs GCC-14:
rvv-next:
...
.L11:
li t1,31
mv a2,a1
bleua7,t1,.L12
bne a6,zero,.L13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113604
--- Comment #4 from Jakub Jelinek ---
Created attachment 57221
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57221=edit
gcc14-pr113604.patch
Untested fix. I've tried to explain what's going on in the large comment.
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
--- 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
--- 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=113583
--- Comment #9 from Robin Dapp ---
(In reply to rguent...@suse.de from comment #6)
> t.c:47:21: missed: the size of the group of accesses is not a power of 2
> or not equal to 3
> t.c:47:21: missed: not falling back to elementwise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113602
--- Comment #3 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f9b143d239db775318a29e9ff63f232b9501a22a
commit r14-8450-gf9b143d239db775318a29e9ff63f232b9501a22a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113607
--- Comment #10 from Robin Dapp ---
The compile farm machine I'm using doesn't have SVE.
Compiling with -march=armv8-a -O3 pr113607.c -fno-vect-cost-model and running
it returns 0 (i.e. ok).
pr113607.c:35:5: note: vectorized 3 loops in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
Sam James changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #4 from Sam James
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113602
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113616
Bug ID: 113616
Summary: [14 Regression] ICE in process_uses_of_deleted_def, at
rtl-ssa/changes.cc:252
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113616
Jakub Jelinek changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85800
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #1 from Jakub Jelinek ---
Created attachment 57223
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57223=edit
1.ii.xz
Not reduced first source.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #2 from Jakub Jelinek ---
Created attachment 57224
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57224=edit
2.ii.xz
Unreduced second source.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #24 from Sam James ---
just checked trunk too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #25 from Tamar Christina ---
So I think probably what's miscompiled is this loop
for (s=string; *s; s +=2 )
I think we currently incorrectly vectorize that. i.e. I think it's the same as
PR113588. I'm finishing testing for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103047
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
--- Comment #9 from Filip Kastl ---
(In reply to Richard Biener from comment #8)
> Does this still happen after r14-8413-g578c7b91f418eb?
I think it doesn't happen anymore.
I can confirm that both on aarch64 and zen3, both the SPEC2006 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
H.J. Lu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113614
--- Comment #1 from Jakub Jelinek ---
I guess the thing is that while using for a signed operand a positive precision
(if smaller than the precision of the signed operand) is always fine,
indicating zero extension from something narrower, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26827
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-01-26
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27672
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #4 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #3)
> LEA is changed to load through an indirection. Isn't it a regression?
LEA + moving a GPR register to SSE register.
So bet it depends on how costly the moving from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29461
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #10 from Jakub Jelinek ---
The difference with that revision is
--- pr113617-aux.s1 2024-01-26 11:00:05.532246309 -0500
+++ pr113617-aux.s 2024-01-26 11:00:36.291552459 -0500
@@ -80,22 +80,21 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Andrew Pinski changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.9.0
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529
--- Comment #3 from GCC Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:663d9e168bc1f2649721436f5188563eda9d04f0
commit r13-8255-g663d9e168bc1f2649721436f5188563eda9d04f0
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |13.3
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Bug ID: 113618
Summary: [14 Regression] AArch64: memmove idiom regression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #8 from Jakub Jelinek ---
Created attachment 57228
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57228=edit
pr113617-aux.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #7 from Jakub Jelinek ---
Created attachment 57227
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57227=edit
pr113617.C
1 - 100 of 125 matches
Mail list logo
