https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #11 from lin1.hu at intel dot com ---
(In reply to Richard Biener from comment #9)
> That that GCC doesn't promise that -ftrapv preserves all overflows and
> traps, it merely guarantees that all overflows that actually happen trap.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
Xi Ruoyao changed:
What|Removed |Added
Summary|Front-end optimization |Front-end optimization
|g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #25 from Richard Biener ---
I think it's more interesting why
* 119: [r216:SI (2 MEM[(struct Vec128 *)_179]+0 S4 A64)] =
{r0:SI..r3:SI}
isn't considered as dependence? Why does the earlier insn even come into
play? What's the bre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #9 from Richard Biener ---
That that GCC doesn't promise that -ftrapv preserves all overflows and traps,
it merely guarantees that all overflows that actually happen trap. So GCC is
fine to contract some expressions where the overal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #8 from lin1.hu at intel dot com ---
(In reply to Andrew Pinski from comment #6)
> Note `c - y - c` to become `-y` reduces the possible of an overflow and is
> well defined for wrapping so this might be still on purpose as there wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #7 from lin1.hu at intel dot com ---
(In reply to Andrew Pinski from comment #5)
> From match.pd:
> /* Match patterns that allow contracting a plus-minus pair
> irrespective of overflow issues. */
> /* (A +- B) - A ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #17 from Kewen Lin ---
(In reply to Michael Matz from comment #16)
> (In reply to Kewen Lin from comment #15)
> > I agree, thanks for the comments! btw, I'm not fighting for the current
> > implementation, just want to know more deta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #5 from Andrew Pinski ---
>From match.pd:
/* Match patterns that allow contracting a plus-minus pair
irrespective of overflow issues. */
/* (A +- B) - A -> +- B */
/* (A +- B) -+ B -> A */
/* A - (A +- B)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #4 from Andrew Pinski ---
int z;
void func(int a, int b, int c, int y){
z = c - y - c + a + y - b;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #6 from sandra at gcc dot gnu.org ---
On further investigation, it appears that both the C and C++ front ends are at
least attempting to parse the context selectors in the correct scope, although
C++ trips over a "use of parameter ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #3 from lin1.hu at intel dot com ---
(In reply to lin1.hu from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Gcc's trapv is known not always to work correctly.
> >
> > Try -fsanitize=undefined instead.
Thanks, it sol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #2 from lin1.hu at intel dot com ---
(In reply to Andrew Pinski from comment #1)
> Gcc's trapv is known not always to work correctly.
>
> Try -fsanitize=undefined instead.
Thanks, it solves the problem to some extent. But c is elimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
--- Comment #1 from Andrew Pinski ---
Gcc's trapv is known not always to work correctly.
Try -fsanitize=undefined instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700
Bug ID: 114700
Summary: Front-end optimization generates wrong code with
-ftrapv.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112842
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106211
Andrew Pinski changed:
What|Removed |Added
Keywords||c++-lambda
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114695
--- Comment #2 from Andrew Pinski ---
Note you don't need the extra template int argument either to reproduce the
failure:
```
template struct Bar {
void accept(X value) { }
};
template struct Foo;
template
struct Foo...> : Bar... {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114695
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-11
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114697
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101019
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
Peter Bergner changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #22 from Tamar Christina ---
note that due to the secondary exit the actual full vector iteration count is 8
scalar elements at VF=4 == 2.
And it's this boundary condition where we fail, since ceil (8/4) == 2. any
other value would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
--- Comment #3 from Richard W.M. Jones ---
(Edit comment 2: To be clear, that wasn't the thread where the
segfault occurred, which was some golang thread, that was the
thread that was unmapping the memory at the same time. Using
nodelete avoids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
--- Comment #2 from Richard W.M. Jones ---
This was the stack trace of the crashing thread with gcc-go:
Thread 7 (Thread 0x7ff5c1af3a40 (LWP 2819340)):
#0 0x7ff5c24d67cb in __GI_munmap () at
../sysdeps/unix/syscall-template.S:117
#1 0x000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
--- Comment #1 from Richard W.M. Jones ---
gcc 14.0.1-0.13.fc40 => crashes
golang-bin-1.22.2-1.fc40.x86_64 => works
I also checked this by stracing the linking process and
seeing -Wl,-z,nodelete is being used by golang, but not by
gcc-go.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114699
Bug ID: 114699
Summary: gcc-go -buildmode=c-shared doesn't use -Wl,-z,nodelete
so libraries crash when dlclosed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #21 from Tamar Christina ---
Created attachment 57932
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57932&action=edit
loop.c
attached reduced testcase that reproduces the issue and also checks the buffer
position and copied v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-11
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Andrew Pinski changed:
What|Removed |Added
Component|target |driver
--- Comment #16 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Attachment #57354|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> There might be a dup somewhere ...
PR 93816 is definitely related but it is not a dup since that has no dependent
types but it does have templates being involve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #1 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Peter Bergner changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #8 from Peter Bergner ---
(In reply to Andrew Pinski from comment #6)
> Note this implementation of sha2.c is shared all over the place it seems and
> has this known issue ...
(In reply to Andrew Pinski from comment #4)
> (In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #7 from Andrew Pinski ---
See https://github.com/archiecobbs/libnbcompat/issues/4 for the full analysis
of the issue with sha2.c and even mentions it is shared with many projects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #6 from Andrew Pinski ---
Note this implementation of sha2.c is shared all over the place it seems and
has this known issue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #5 from Andrew Pinski ---
Specifically
https://github.com/archiecobbs/libnbcompat/commit/864c1cf42c2c605636008626f171caf6410421cb
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Andrew Pinski changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
--- Comment #3 from Andrew Pinski ---
uint8_t buffer[SHA256_BLOCK_LENGTH];
W256 = (sha2_word32*)context->buffer;
This is starting to smell like the code is violating strict aliasing rules ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Peter Bergner changed:
What|Removed |Added
Component|target |ipa
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 110216, which changed state.
Bug 110216 Summary: tuple_size requirements for structured binding has not been
updated after DR 2386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110216
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110216
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Peter Bergner changed:
What|Removed |Added
Known to work||11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114698
Bug ID: 114698
Summary: dcfldd produces wrong sha256 sum on ppc64le and -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114697
Bug ID: 114697
Summary: [DR 233] references in user defined conversions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #24 from Andrew Pinski ---
(In reply to Richard Earnshaw from comment #21)
> With my new testcase, compiled on an arm-none-eabi cross with
>
> cc1plus ../hwy-pr111231-cpp.cc -mfpu=neon-vfpv4 -mfloat-abi=hard
> -mfp16-format=ieee -m
ression algorithms: zlib zstd
gcc version 14.0.1 20240411 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #15 from Thomas Koenig ---
(In reply to Andrew Pinski from comment #14)
> (In reply to Jonathan Wakely from comment #10)
> > If --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld is required then
> > it needs to be documented at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114695
Bug ID: 114695
Summary: Template argument deduction and defaulted template
template parameters
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90390
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #11 from Andreas Krebbel ---
The documentation of vec_xl and vec_xst doesn't seem to mention anything
special with regard to that. So I understand the memory is only accessed
through pointers which are compatible to the ones used whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105168
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114625
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=111231
--- Comment #23 from Richard Earnshaw ---
#0 ptr_deref_may_alias_decl_p (ptr=0x75e0c678, decl=0x75dff000)
at /home/rearnsha/gnusrc/gcc-cross/gcc-13/gcc/tree-ssa-alias.cc:295
#1 0x01768173 in indirect_ref_may_alias_decl_p (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114059
Filip Kastl changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #22 from Richard Earnshaw ---
(Previous analysis is based on gcc-13 branch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Richard Earnshaw changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:1defe743aeb19532f6d6f4cab37e10f11467abd8
commit r14-9917-g1defe743aeb19532f6d6f4cab37e10f11467abd8
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694
Bug ID: 114694
Summary: dependent-name alias type accepted in elaborated type
specifier within a template
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114303
--- Comment #5 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:b262b17636e47ae969a74f16e86ccb00678d5e88
commit r14-9916-gb262b17636e47ae969a74f16e86ccb00678d5e88
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #20 from Richard Earnshaw ---
Created attachment 57928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57928&action=edit
fully preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #9 from Jonathan Wakely ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685
Nathaniel Shead changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
--- Comment #3 from Stefan Schulze Frielinghaus
---
Thanks for the pointer. I can confirm that the patch fixes this PR and also
fixes
FAIL: gcc.dg/tree-ssa/vrp-float-abs-1.c scan-tree-dump-not evrp "link_error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687
--- Comment #2 from Jakub Jelinek ---
Saying a function is valid code in this case is difficult, claiming that a
noreturn function is pure or returns_twice is wrong, it isn't pure, nor
returns_twice, as it never returns.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #16 from Michael Matz ---
(In reply to Kewen Lin from comment #15)
> I agree, thanks for the comments! btw, I'm not fighting for the current
> implementation, just want to know more details why users are unable to make
> use of the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #10 from Jakub Jelinek ---
I admit I haven't studied what exactly pytorch does there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #9 from Jakub Jelinek ---
It depends on what the vec_xl*/vec_xst* documentation requires/user expect.
If the expectation is that the loads/stores should alias the scalar pointee of
the pointer type passed to those intrinsics, then
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #8 from Andreas Krebbel ---
Apparently, I decided to go with a MEM_REF already for the load variant of the
builtin - vec_xl. I've to check whether there was any reason not to do this
also for vec_xst.
Making it a pointer which alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114693
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #8 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Jonathan Wakely from comment #4)
> > This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
>
> Oops, guess too late then for those. We'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114693
Andrew Pinski changed:
What|Removed |Added
Target||x86_64
Component|rtl-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114693
Bug ID: 114693
Summary: `expand` introduce redundant store facing logic
expression
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #7 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #4)
> This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
Oops, guess too late then for those. We'll need to consider 13.2 as a fuzzy
snapshot in betw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #6 from Jonathan Wakely ---
r14-739-gc62e945492afbb incorrectly added them to GLIBCXX_3.4.32 which should
have been frozen after 13.1 but it looks like I thought it was a new version
for 13.2/14.0
Then I must have thought 13.2 and 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #5 from Jonathan Wakely ---
The *shouldn't* have been added there though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #4 from Jonathan Wakely ---
This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #3 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #1)
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
> GLIBCXX_3.4.32 {
> _ZSt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #2 from Jakub Jelinek ---
Created attachment 57927
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57927&action=edit
gcc14-libstdc++-baseline-updates.patch
This was what I've been preparing before noticing this issue. If we ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #1 from Jonathan Wakely ---
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
GLIBCXX_3.4.32 {
_ZSt21ios_base_library_initv;
_ZNSt7__cxx1112basic_st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-04-11
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Bug ID: 114692
Summary: [14 Regression] Symbol versioning problem in GCC 14
libstdc++.so.6
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #6 from Jonathan Wakely ---
It's also a mostly-harmless ABI change for C++17 down, because the underlying
type without -fshort-enums changes from implicitly being chosen as unsigned
int, to explicitly being specified as int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #5 from Jonathan Wakely ---
I think we should just do this:
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -77,7 +77,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
inline constexpr memory_ord
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
Nicolas Boulenguez changed:
What|Removed |Added
Attachment #57890|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689
Richard Biener changed:
What|Removed |Added
Target||m68k
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691
Bug 114691 depends on bug 114409, which changed state.
Bug 114409 Summary: [14 Regression] ICE after adding novector pragmas (internal
compiler error: in tsubst_expr, at cp/pt.cc:21794) since
r14-4229-g9c62af101e11e1cce573c2b3d2e18b403412dbc8
h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #18 from Jakub Jelinek ---
The P1 bug has been fixed, I've moved the rest to PR114691.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691
Bug ID: 114691
Summary: [11/12/13/14 Regression] Bogus ignoring loop
annotation warning
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-c
1 - 100 of 119 matches
Mail list logo
