https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jennifer Schmitz :
https://gcc.gnu.org/g:9bbad3685131ec95d970f81bf75f9556d4d92742
commit r15-3082-g9bbad3685131ec95d970f81bf75f9556d4d92742
Author: Jennifer Schmitz
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
Bug ID: 116458
Summary: New valgrind error in search_line_ssse3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
David Binderman changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454
--- Comment #9 from Richard Biener ---
One of the issues is that
REALPART_EXPR , 0.0>>
is no longer simplified. I don't think __real folding can look through
a SAVE_EXPR but instead of building SAVE_EXPR > we
could build COMPLEX_EXPR >, 0.0>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115241
--- Comment #4 from sadineniharish8446 at gmail dot com ---
Is GCC upstream planning to backport the patch to older release branches for
gcc versions? If yes, which release versions will have it?
We can help to backport the patch, if needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115241
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #2 from Richard Biener ---
It's likely the tail padding we possibly inspect, with now unrolling the loop
twice to improve the number of badly predictable branches we can now end up
with inspecting a completely uninitialized qword. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115241
--- Comment #6 from Andrew Pinski ---
(In reply to sadineniharish8446 from comment #4)
> Is GCC upstream planning to backport the patch to older release branches for
> gcc versions? If yes, which release versions will have it?
>
> We can help t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #3 from Alexander Monakov ---
David, thanks for Cc'ing me and for running Valgrind builds!
Richi, I'll check in more detail later today, I think we should unbreak
Valgrind builds ASAP by initializing padding under #ifdef
ENABLE_VALG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #4 from David Binderman ---
(In reply to Alexander Monakov from comment #3)
> David, thanks for Cc'ing me and for running Valgrind builds!
You are welcome. Its a normal weekly part of gcc testing for me.
> "Wobbly values" aside, ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Host|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
--- Comment #3 from Franz Sirl ---
Isn't the missing bounds check on parr[c] on purpose? It's added with
-fsanitize=bounds-strict.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116455
--- Comment #7 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> I think the standard does not define it as constexpr which is why it is not
> constexpr in libstdc++.
Right, the standard does not allow implementations to ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
--- Comment #4 from Andrew Pinski ---
(In reply to Franz Sirl from comment #3)
> Isn't the missing bounds check on parr[c] on purpose? It's added with
> -fsanitize=bounds-strict.
You might be right, I misread the original qnd gimple dump. But I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115716
Simon Martin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |simartin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
--- Comment #7 from Sam James ---
The unreliable nature of the failure keeps confusing people. Any chance of a
revert until it can be fixed properly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
Xi Ruoyao changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
--- Comment #8 from Xi Ruoyao ---
Raising to P1 because now automatic regression tracker has started to "bisect"
on this and blame random people.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37801
--- Comment #15 from GCC Commits ---
The master branch has been updated by Bernd Edlinger :
https://gcc.gnu.org/g:bcb33b1237042e9540a905d9de19219f876e26c0
commit r15-3083-gbcb33b1237042e9540a905d9de19219f876e26c0
Author: Bernd Edlinger
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87440
--- Comment #7 from GCC Commits ---
The master branch has been updated by Bernd Edlinger :
https://gcc.gnu.org/g:bcb33b1237042e9540a905d9de19219f876e26c0
commit r15-3083-gbcb33b1237042e9540a905d9de19219f876e26c0
Author: Bernd Edlinger
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116365
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jennifer Schmitz :
https://gcc.gnu.org/g:313aa733e22b654ff822b867018b13ceb624c13a
commit r15-3085-g313aa733e22b654ff822b867018b13ceb624c13a
Author: Jennifer Schmitz
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
--- Comment #9 from Paul Thomas ---
(In reply to Sam James from comment #7)
> The unreliable nature of the failure keeps confusing people. Any chance of a
> revert until it can be fixed properly?
It is such an unreliable failure that I haven't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116358
--- Comment #5 from Manolis Tsamis ---
I had some trouble figuring the preferred way to address this. I made a choice
by answering these questions:
1) Should the aarch64 min/max expand pattern be improved?
This comment hints that we should get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454
--- Comment #10 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b07f8a301158e53717b8688cc8ea430b6f02574c
commit r15-3087-gb07f8a301158e53717b8688cc8ea430b6f02574c
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116454
Richard Biener changed:
What|Removed |Added
Known to work||15.0
Summary|[12/13/14/15 R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361
--- Comment #6 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:a98dd536b1017c2b814a3465206c6c01b2890998
commit r15-3088-ga98dd536b1017c2b814a3465206c6c01b2890998
Author: H.J. Lu
Date: Wed Aug 21 07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116365
Jennifer Schmitz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390
Jennifer Schmitz changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 101390, which changed state.
Bug 101390 Summary: Expand vector mod as vector div + multiply-subtract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
Bug ID: 116459
Summary: gcc 12.0 optimized out functions which has observable
side affect
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
xiaohuba2021 changed:
What|Removed |Added
CC||xiaohuba2021 at 163 dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #2 from xiaohuba2021 ---
> Uncomment line 20 (mask = 1) or explicitly add operator= for struct Matrix
> solves this problem.
sorry, the code above produces the correct answer, since line 20 is
uncommented. Comment it and it will ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
Richard Biener changed:
What|Removed |Added
Known to fail||12.1.0, 12.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116424
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #4 from xiaohuba2021 ---
Yes, it seems that only 12.1 and 12.2 are affected. But I wonder what's the
cause of it, and are there any patches for it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #6 from Jonathan Wakely ---
Regression started with with r12-2523 and was fixed by r13-7206, which was
backported as r12-9476.
So this is a dup of either PR ipa/107769 or PR ipa/109318.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #7 from xiaohuba2021 ---
Created attachment 58975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58975&action=edit
The miscompiled program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116459
--- Comment #8 from Jonathan Wakely ---
(In reply to xiaohuba2021 from comment #0)
> struct Matrix {
> long long mat[2][2];
> Matrix() { memset(mat, 0, sizeof(mat)); }
N.B. there's no miscompilation if you change this to the more idioma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116348
--- Comment #10 from Xi Ruoyao ---
I've tested the change and it fixes PR116314 case as well.
Richard: do you want me to send your change as a patch like before (the
PR116142 fix)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420
--- Comment #3 from Jeffrey A. Law ---
Fun.
The DF framework provides us a way to run dataflow problems on sub-graphs.
Naturally a bitmap of interesting blocks is passed into those routines. At a
confluence point, the DF framework will not m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116439
Patrick Palka changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052
ezannoni changed:
What|Removed |Added
CC||ezannoni at gmail dot com
--- Comment #10 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116329
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
Bug ID: 116460
Summary: ppc64le: LTO ICE during GIMPLE pass: forwprop
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #1 from Alessandro Astone ---
Cannot attach intermediate files because the size is too large.
Sorry that I don't have a minimal reproducer :/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #2 from Andrew Pinski ---
Can you try adding -fchecking and seeing if that fails differently?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #3 from Alessandro Astone ---
(In reply to Andrew Pinski from comment #2)
> Can you try adding -fchecking and seeing if that fails differently?
No, it fails in the same way.
BTW i realize i didn't specify this other than mentioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115921
Jovan Vukic changed:
What|Removed |Added
CC||jovan.vu...@rt-rk.com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #29 from andi at firstfloor dot org ---
The semantics of -foptimize-sibling-calls do not change. However if your
program depends on sbling calls for correctness it should migrate to the
new attribute
Hi there,
Want to expand your outreach to K-12 schools, colleges, universities? Our email
list of principals, superintendents, and key decision-makers is ideal for you!
Our List Includes:
* Principals
* Superintendents
* Board Members
* Department Heads
List Contains:- First N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106606
--- Comment #4 from Paul Thomas ---
Created attachment 58976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58976&action=edit
Full testcase that fails in runtime
The patch regtests OK but the attached fails in runtime, as it does with ifo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
Bug ID: 116461
Summary: New test case gcc.dg/vect/vect-mod-var.c from
r15-3082-g9bbad3685131ec fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106606
Paul Thomas changed:
What|Removed |Added
CC||vehre at gmx dot de
--- Comment #5 from P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
Andrew Pinski changed:
What|Removed |Added
Severity|normal |blocker
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #18 from Jerry DeL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460
--- Comment #4 from Andrew Pinski ---
(In reply to Alessandro Astone from comment #1)
> Cannot attach intermediate files because the size is too large.
> Sorry that I don't have a minimal reproducer :/
Is there a place where you could upload th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:c9377734b798d8d311dfd3a5618dc49407703b93
commit r15-3095-gc9377734b798d8d311dfd3a5618dc49407703b93
Author: Jeff Law
Date: Thu Aug 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
Bug ID: 116462
Summary: [15 regression] new test case
gcc.dg/debug/dwarf2/inline7.c from
r15-3083-gbcb33b1237042e fails
Product: gcc
Version: 15.0
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116420
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Bug ID: 116463
Summary: [15 Regression] fast-math-complex-mls-{double,float}.c
fail after r15-3087-gb07f8a301158e5
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #1 from Andrew Pinski ---
Created attachment 58977
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58977&action=edit
Reduced testcase
options: `-ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-commo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #6 from Alexander Monakov ---
As for Valgrind false positive, it handles this SSSE3 code really well and
misses the key point by a very narrow margin. We have
found = m1 + (m2 << 16);
where both m1 and m2 hold 16-bit masks from p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Andrew Pinski changed:
What|Removed |Added
Attachment #58977|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Andrew Pinski changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113746
Simon Martin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
Andrew Pinski changed:
What|Removed |Added
Attachment #58978|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #7 from Mark Wielaard ---
You could try --expensive-definedness-checks=yes
--expensive-definedness-checks= [default: auto]
Controls whether Memcheck should employ more precise but also more
expensive (ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462
--- Comment #2 from Bernd Edlinger ---
no forget it, this might make arm unhappy...
lets try this instead:
--- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline7.c
@@ -1,9 +1,9 @@
-/* Verify that both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707
--- Comment #12 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #11)
> Testing removal of this part from the driver.
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661228.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #19 from Andrew Pinski ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661228.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #8 from Alexander Monakov ---
Thanks for the reference, but it doesn't help. Something more subtle is going
on, because placing the shift-add combo in a separate function makes Valgrind
properly compute known bits even without the ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
--- Comment #7 from Alisdair Meredith ---
Late comment: according to [intro.multithread.general] it is a requirement for
hosted implementations to support more than one thread of execution, but
implementation defined for a free-standing implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105474
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464
Bug ID: 116464
Summary: [15 regression] new test gcc.dg/torture/pr116420.c
from r15-3095-gc9377734b798d8 fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116464
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:da043f9c7172bcbfda0cdb570fb3a979a4b1a525
commit r15-3096-gda043f9c7172bcbfda0cdb570fb3a979a4b1a525
Author: Andrew Pinski
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458
--- Comment #9 from Alexander Monakov ---
Okay, if you take the addition and the branch from the inlined variant:
addl %eax, %edx
je .L3
and add a 'test' instruction:
addl %eax, %edx
test %edx, %edx
je .L3
then Valgrind doesn't complain. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101139
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 57993 [details]
> Patch but it does not work for the code in this testcase
>
> I have to look into why it is not working for the testcase in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #5 from Tamar Christina ---
Yeah, This is because they generate different gimple sequences and thus
different SLP trees.
The core of the problem is there's no canonical form here, and a missing gimple
simplification rule:
_33 = IM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96290
Gabriel Ravier changed:
What|Removed |Added
CC||gabravier at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465
Bug ID: 116465
Summary: __builtin_eh_pointer ICEs when passed seemingly any
argument
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116466
Bug ID: 116466
Summary: The standard instruction pattern of RISC-V addv has
generated an unnecessary instruction.
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465
--- Comment #1 from Gabriel Ravier ---
(PS: I have no idea what this is caused by, somehow an assignment statement
with no left hand side appears to be generated ?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116465
--- Comment #2 from Gabriel Ravier ---
Looked into it a bit more and the root cause seems to be that
gcc/tree-eh.cc:lower_eh_constructs_2, when attempting to handle the case where
the user partakes in a little tomfoolery with its builtins (i.e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111933
rsaxvc at gmail dot com changed:
What|Removed |Added
CC||rsaxvc at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113454
--- Comment #5 from edison ---
Thanks for your reply, could you provide the patch for gcc 14.1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #185 from Kazumoto Kojima ---
Unfortunately, nothing new showed up in running gcc/g++ testsuite for
sh-elf+sim with -mlra.
OTOH, the segfault can be reproduced on qemu with the patched stage2 compiler
built with -g -O2 -mlra -m4. gd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116467
Bug ID: 116467
Summary: missed optimization: zero-extension duplicated on
xtensa
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468
Bug ID: 116468
Summary: Segmentation fault at intrinsic assignment to
allocatable array component of derived type with kind
type parameter
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
Kewen Lin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116468
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2024-08-23
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96290
--- Comment #2 from Andrew Pinski ---
(In reply to Gabriel Ravier from comment #1)
> I've encountered a similarly nonsensical error on trunk, though not with
> VLAs, instead with a char array of size 0:
It is not nonsensical at all. It just has
1 - 100 of 109 matches
Mail list logo
