https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #16 from Richard Biener ---
The issue is that we cannot CSE a VLA typed "load" (whatever that is) to a
constnant.
char arr[] = {1, 2, 7, 1, 3, 4, 5, 3, 1
, 0, 1, 2, 4, 4, 9, 9, 1, 2, 7, 1, 3, 4, 5, 3,
1, 0, 1, 2, 4, 4,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111773
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111850
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101169
--- Comment #6 from Kewen Lin ---
PR111850 reminded me this bug, the sub-optimal issue described in #comment 4
has been fixed on latest trunk, I think it's r14-4664-g04c9cf5c786b94.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753
--- Comment #3 from Haochen Jiang ---
It seems like caused by I changed the behavior when trying to use x/ymm16+ w/o
avx512vl specified.
Working on a solution for that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111872
Bug ID: 111872
Summary: GCC rejects out of class definition of inner private
class template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100532
--- Comment #8 from Andrew Pinski ---
Maybe the simple fix:
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 6e044b4afbc..8f8562936dc 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -3367,7 +3367,7 @@ convert_argument (location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986
--- Comment #23 from Andrew Pinski ---
Final patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633517.html
The Canonicalization between the 2 forms or doing it in isel will wait until
next I think.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
--- Comment #10 from Andrew Pinski ---
Just an FYI, I do get a similar ICE on:
libgomp/testsuite/libgomp.fortran/simd3.f90
Testcase on aarch64-linux-gnu now too.
Maybe since it was in the libgomp testsuite you missed it when you tested your
pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104822
--- Comment #4 from Andrew Pinski ---
Created attachment 56147
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56147&action=edit
Patch which I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #7 from JuzheZhong ---
I don't think this is popcount vectorization issue.
This code should not be vectorized. It's true this code won' be vectorized if
we
use default COST model.
So this is not an issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111871
Bug ID: 111871
Summary: invoking gm2 with -pipe and -v does not work
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111720
--- Comment #15 from JuzheZhong ---
After investigation:
I found it seems to be an issue to variable-length vector:
https://godbolt.org/z/6Wrjz9ofE
void fn (char * restrict out, int x)
{
[local count: 1073741824]:
MEM[(int8x16_t *)out_2(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111739
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111738
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110733
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110986
Andrew Pinski changed:
What|Removed |Added
Attachment #56134|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #6 from Andrew Pinski ---
(In reply to Vineet Gupta from comment #5)
> (In reply to Robin Dapp from comment #4)
>
> > Analyzing loop at pr111791.c:8
> > pr111791.c:8:25: note: === analyze_loop_nest ===
> > pr111791.c:8:25: note:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #5 from Vineet Gupta ---
(In reply to Robin Dapp from comment #4)
> Analyzing loop at pr111791.c:8
> pr111791.c:8:25: note: === analyze_loop_nest ===
> pr111791.c:8:25: note: === vect_analyze_loop_form ===
> pr111791.c:8:25: note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101364
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101285
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101285
Andrew Pinski changed:
What|Removed |Added
Target Milestone|11.5|14.0
--- Comment #8 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863
--- Comment #11 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:b20dbddcc41120144e700c4e3ef1ec396b1c56ab
commit r14-4729-gb20dbddcc41120144e700c4e3ef1ec396b1c56ab
Author: Andrew Pinski
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101364
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:879c91fcccf93681bd7e13290bfbb384cadcd268
commit r14-4728-g879c91fcccf93681bd7e13290bfbb384cadcd268
Author: Andrew Pinski
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101285
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:11e6bcedb41359c69ee790f38b04033d236336a8
commit r14-4727-g11e6bcedb41359c69ee790f38b04033d236336a8
Author: Andrew Pinski
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #6 from Peter Bergner ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Peter Bergner from comment #4)
> > CCing richi and jakub to see if they've seen anything like this before?
>
> I suspect we are miscompiling the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103398
Mark Esler changed:
What|Removed |Added
CC||mark.esler at canonical dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #5 from Andrew Pinski ---
(In reply to Peter Bergner from comment #4)
> CCing richi and jakub to see if they've seen anything like this before?
I suspect we are miscompiling the final compiler somehow. I linked 2 other
reports whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #9 from Andrew Pinski ---
If I change your testcase to be:
uint64_t huh2 (_Atomic(uint64_t)* map, int t) {
return atomic_fetch_or_explicit(map, t, memory_order_relaxed);
}
You will see that it does the `lock cmpxchg` loop too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #8 from Andrew Pinski ---
On aarch64, ldset does both a load and ior. that is unlike the `lock or` on
x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #7 from Andrew Pinski ---
That is not using the fetch part is optimized to just `lock or`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #6 from Andrew Pinski ---
If you don't use the return value of atomic_fetch_or_explicit, there is no need
for a compare-and-exchange (swap) loop. If you need the fetch part, the
compare-and-exchange loop needs to be used as `lock or`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Peter Bergner changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #5 from isoosqa ---
Please, forgive me. I typed stuff wrong in original link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #4 from isoosqa ---
Oops, I sent wrong code. This is the one https://godbolt.org/z/GxdvMdP76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #3 from Andrew Pinski ---
Or maybe the issue is you don't understand the cmpxchg instruction and how it
gives back the original value too.
The RTL form for the "lock;cmpxchg " is:
(insn:TI 14 10 17 5 (parallel [
(set (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
--- Comment #1 from Andrew Pinski ---
Created attachment 56145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56145&action=edit
testcase
Next time please enter attach or place inline the testcase rather than just a
link.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111870
Bug ID: 111870
Summary: Miscompile of atomic rmw or on x86 (not aarch, though)
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111857
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111869
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Andrew Pinski changed:
What|Removed |Added
CC||shaohua.li at inf dot ethz.ch
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #8 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #4 from Robin Dapp ---
This is a scalar popcount and as Kito already noted we will just emit
cpop a0, a0
once the zbb extension is present.
As to the question what is actually being vectorized here, I'm not so sure :D
It looks l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111869
Bug ID: 111869
Summary: ICE: verify_ssa failed since r14-4710-g60c231cb658
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111851
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648
--- Comment #5 from CVS Commits ---
The master branch has been updated by Prathamesh Kulkarni
:
https://gcc.gnu.org/g:3ec8ecb8e92faec889bc6f7aeac9ff59e82b4f7f
commit r14-4726-g3ec8ecb8e92faec889bc6f7aeac9ff59e82b4f7f
Author: Prathamesh Kulkarn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110500
--- Comment #3 from Andrew Pinski ---
*** Bug 111862 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111862
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96347
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-10-18
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61192
--- Comment #7 from Andrew Pinski ---
Created attachment 56144
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56144&action=edit
Another testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61192
Andrew Pinski changed:
What|Removed |Added
CC||141242068 at smail dot
nju.edu.cn
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Created attachment 56143 [details]
> testcase that could go into the testsuite with more targets supported
Add:
```
#elif defined __aarch64__
# define ASM __asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865
--- Comment #1 from Andrew Pinski ---
Created attachment 56143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56143&action=edit
testcase that could go into the testsuite with more targets supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.5
Summary|GCC: 14: intern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
--- Comment #4 from Iain Sandoe ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Maybe something like:
> > diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> > index 62b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111868
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111860
Tamar Christina changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Maybe something like:
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index 62b1ae0652f..db2dde84329 100644
> --- a/gcc/config/aar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111868
Bug ID: 111868
Summary: [14 regression] many ICEs after r14-4710
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
--- Comment #2 from Andrew Pinski ---
Maybe something like:
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 62b1ae0652f..db2dde84329 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|aarch64-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
Bug ID: 111867
Summary: aarch64: Wrong code for bf16 literal load when the
arch support +fp16
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528
--- Comment #5 from CVS Commits ---
The releases/gcc-13 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:f5e56c5857cc6b704446c3666213468d25f6dcb2
commit r13-7961-gf5e56c5857cc6b704446c3666213468d25f6dcb2
Author: Richard San
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863
--- Comment #10 from Andrew Pinski ---
Created attachment 56142
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56142&action=edit
Reduced self-contained testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #5 from Steve Kargl ---
On Wed, Oct 18, 2023 at 03:56:32PM +, aluaces at udc dot es wrote:
> --- Comment #4 from Alberto Luaces ---
> I got the same error in almost the same circumstances (crash in
> error.cc:1078).
>
> I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89038
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111852
--- Comment #6 from Jakub Jelinek ---
In several gcc ml (or gcc-patches, don't remember) threads it was discussed
whether we should switch to C++14 as the implementation language, that would
bump to the bootstrap compiler requirement to GCC 5 (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111852
--- Comment #5 from seurer at gcc dot gnu.org ---
Yup, thanks!
In another 4.8.5 breakage PR someone mentioned removing that as the minimum
required compiler level. Has there been any more discussion of that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863
--- Comment #9 from Andrew Pinski ---
Created attachment 56141
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56141&action=edit
untested fix
This fixes the reuse of arg0 so we don't change it for the later on code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863
--- Comment #8 from Andrew Pinski ---
Oh I see the issue now, I am changing arg0 even if we don't do the thing ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed|2017-07-04 00:00:00 |2023-10-18
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114
--- Comment #9 from simon at pushface dot org ---
Created attachment 56140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56140&action=edit
C demonstrator
As noted in comment 8, the C compiler doesn’t have a problem with
finding a file wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866
--- Comment #1 from Tamar Christina ---
Thanks for reporting! I'll debug.
I suspect another case where the vectorized and scalar loop were sneakily
swapped.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81114
--- Comment #8 from simon at pushface dot org ---
I think I’d forgotten that compiling páck3.ads on its own, rather than as
part of the closure, was the way to demonstrate this problem. It was NOT
fixed in darwin19 (it’s still present in darwin2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Oh I see the issue:
> ```
> _8 = _7 & 2;
> _10 = _8 != 1;
>
> ```
>
> There needs to be a check that 1 here is the same as 2 or 0 ...
Wait I have that che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
Alberto Luaces changed:
What|Removed |Added
CC||aluaces at udc dot es
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863
--- Comment #6 from Andrew Pinski ---
Oh I see the issue:
```
_8 = _7 & 2;
_10 = _8 != 1;
```
There needs to be a check that 1 here is the same as 2 or 0 ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111866
Bug ID: 111866
Summary: [14 regression] ICE when compiling
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111863
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #9 from joseph at codesourcery dot com ---
A portability issue producing a compile failure is often better than one
where there is no error but the code misbehaves at runtime on some
platforms (a lot of code does not have good test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111852
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111852
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bc4bd69faf986326f6b0fd0400cdd6871577afd1
commit r14-4722-gbc4bd69faf986326f6b0fd0400cdd6871577afd1
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111849
--- Comment #2 from Rich Felker ---
I agree that volatile isn't the best way to handle memcpy suppression for other
purposes - it was just one of the methods I experimented with that led to me
discovering this issue, which I found surprising and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111865
Bug ID: 111865
Summary: GCC: 14: internal compiler error: symtab_node::verify
failed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111753
Jakub Jelinek changed:
What|Removed |Added
Summary|[14 Regression] ICE: in |[14 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
Bug ID: 111864
Summary: [14 Regression] Dead Code Elimination Regression since
r14-4038-gb975c0dc3be
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
1 - 100 of 138 matches
Mail list logo
