Thread model: posix
Supported 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'
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
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 #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 = &&lab;
goto *p;
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=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, &&lab1};
lab:
a %= 3;
a1 = a;
i = !i;
go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113602
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc do
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=113613
Alex Coplan changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|acoplan at gcc dot
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=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.
Tha
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=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 function
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).
>
> p
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=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 accesses
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&action=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=85800
Sam James changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #4 from Sam James --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
Richard Sandiford changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
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=113602
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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
Pr
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 Mil
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=112899
--- Comment #3 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:a0dde47f84f17cbe7fa2fb41c14c5a2db8c4d63a
commit r14-8451-ga0dde47f84f17cbe7fa2fb41c14c5a2db8c4d63a
Author: Nathaniel Shead
Date:
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=112687
--- Comment #2 from Filip Kastl ---
Created attachment 57222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57222&action=edit
WIP patch to fix the missed optimization, version 0
I'm working on a patch. The problem (as Richard stated in pr
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=113605
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Target M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
Bug ID: 113617
Summary: [14 Regression] Symbol ... referenced in section
`.data.rel.ro.local' of ...: defined in discarded
section ... since r14-4944
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
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&action=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&action=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=61502
--- Comment #48 from Vincent Lefèvre ---
(In reply to Alexander Cherepanov from comment #35)
> DR 260 allows one to argue that representation of these pointers could
> change right between the checks but IMHO this part of DR 260 is just wrong
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #22 from Richard Biener ---
Is this fixed meanwhile?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
--- Comment #8 from Richard Biener ---
Does this still happen after r14-8413-g578c7b91f418eb?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113467
--- Comment #23 from Sam James ---
I last tried around r14-8422-gc3de14ba1ba0e7 without that workaround patch
applied and it still failed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14169
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2005-12-28 06:11:40 |2024-1-26
--- Comment #2 from Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19954
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
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 that
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 SPE
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 from
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 un
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 GPR
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 #5 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #4)
> (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
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
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113619
Bug ID: 113619
Summary: -Wanalyzer-tainted-divisor false positive seen in
Linux kernel's fs/ceph/ioctl.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severit
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=113620
Bug ID: 113620
Summary: Specialized Template
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #6 from Jakub Jelinek ---
Created attachment 57226
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57226&action=edit
pr113617.h
Reduced testcase:
./cc1plus -quiet -O2 -std=c++11 -fPIC pr113617.C; ./cc1plus -quiet -O2
-std=c++11
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&action=edit
pr113617.C
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&action=edit
pr113617-aux.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617
--- Comment #9 from Sam James ---
Ah, this explains a failure I started seeing recently with folly/watchman/etc
too. I just hadn't looked at it yet.
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 @@ _ZN3vtk6detail3smp15vtkSMPToo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113618
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
CC|
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 Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
--- Comment #4 from Andrew Pinski ---
Created attachment 57229
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57229&action=edit
Reduced testcase
I reduced the testcase slightly to show it is NSDMI related dealing with a
dependent value on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113568
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113620
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
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=107946
Martin Jambor changed:
What|Removed |Added
Last reconfirmed||2024-01-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113614
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
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 cur
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 n
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 = "(1a1,d0.2,
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=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=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
Sev
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
Prio
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 b/gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113622
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2024-01-26
Ever confirmed|0
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=113622
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.9.1
Summary|r14-8450 regre
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
> ref
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))) vec;
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=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++)
c
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&action=edit
An untested patch
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
Component
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=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 ins
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)
character(4)
1 - 100 of 125 matches
Mail list logo
