[Bug c++/115914] SIGSEGV when std::generator co_yield different ranges of elements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug c++/115914] New: SIGSEGV when std::generator co_yield different ranges of elements

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115914 Bug ID: 115914 Summary: SIGSEGV when std::generator co_yield different ranges of elements Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug middle-end/115913] [11/12/13/14/15 Regression] ICE with pragma GCC pop_options with diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug middle-end/115913] [11/12/13/14/15 Regression] ICE with pragma GCC pop_options with diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0, 10.5.0 Summary|ICE w

[Bug middle-end/115913] ICE with pragma GCC pop_options (‘global_options’ are modified in local context)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913 --- Comment #4 from Andrew Pinski --- ``` #pragma GCC push_options #pragma GCC diagnostic warning "-Wundef" #pragma GCC pop_options ```

[Bug rtl-optimization/115883] [15 Regression] late-combine exposing LRA problems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115883 --- Comment #3 from Hans-Peter Nilsson --- >From r15-2024-ga01b40c047334c (disabling late-combine for CRIS), you'll need -flate-combine-instructions to expose the bug.

[Bug target/109927] Bootstrap fails for m68k in stage2 compilation of gimple-match.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109927 Sam James changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug middle-end/115913] ICE with pragma GCC pop_options (‘global_options’ are modified in local context)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913 Andrew Pinski changed: What|Removed |Added Component|c++ |middle-end Target|

[Bug c++/115913] ICE with pragma GCC pop_options (‘global_options’ are modified in local context)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913 --- Comment #2 from Sam James --- Surrounding hb.hh does it, which makes sense given how much pragma fun it does: https://github.com/harfbuzz/harfbuzz/blob/main/src/hb.hh.

[Bug c++/115913] ICE with pragma GCC pop_options (‘global_options’ are modified in local context)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913 --- Comment #1 from Sam James --- It was fine until I moved the push_options+optimize above the include block.

[Bug c++/115913] New: ICE with pragma GCC pop_options (‘global_options’ are modified in local context)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913 Bug ID: 115913 Summary: ICE with pragma GCC pop_options (‘global_options’ are modified in local context) Product: gcc Version: 15.0 Status: UNCONFIRMED Severit

[Bug libstdc++/69350] Don't define the C99 functions in -std=c++98 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69350 --- Comment #2 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #0) > (that won't be > possible for GNU/Linux unless/until we stop defining _GNU_SOURCE implicitly). Which is PR 11196 .

[Bug rtl-optimization/115912] [15 regression] Harfbuzz testsuite fails (mvar_partial_instance test) since r15-1901-g98914f9eba5f19

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912 --- Comment #1 from Andrew Pinski --- >From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115877#c2 : "Based on what I'm seeing, we may have a problem with vectors as well -- worth keeping mind if there's additional bug reports against ext-dce."

[Bug rtl-optimization/115912] [15 regression] Harfbuzz testsuite fails (mvar_partial_instance test) since r15-1901-g98914f9eba5f19

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0

[Bug rtl-optimization/115912] New: [15 regression] Harfbuzz testsuite fails (mvar_partial_instance test) since r15-1901-g98914f9eba5f19

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115912 Bug ID: 115912 Summary: [15 regression] Harfbuzz testsuite fails (mvar_partial_instance test) since r15-1901-g98914f9eba5f19 Product: gcc Version: 15.0

[Bug c++/115911] New: [OpenMP]gcc rejects valid user defined openmp reduction in template class with default argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115911 Bug ID: 115911 Summary: [OpenMP]gcc rejects valid user defined openmp reduction in template class with default argument Product: gcc Version: 13.2.0 Status: UNCONFIRMED

[Bug c/68524] Please support attributes between function definition and opening brace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68524 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment

[Bug c++/65866] Wrong warning when using list-initialization: operation on 'b' may be undefined [-Wsequence-point]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65866 --- Comment #8 from Matthijs van Duin --- (In reply to Yuxuan Shui from comment #7) > IIUC now wrong codegen has all been fixed? so the only thing left should be > the diagnostic bug? It seems so yes, the combined testcase in Bug 70796 comment 5

[Bug c++/102623] Failure to detect destructed scalar objects in consteval function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102623 Andrew Pinski changed: What|Removed |Added Known to work||14.1.0 --- Comment #4 from Andrew Pinsk

[Bug middle-end/115910] [15 Regression] ((unsigned)x)/3 with a range for (unsigned)x that does not have the sign bit set seems to produce much worse code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115910 --- Comment #1 from Andrew Pinski --- I should mention this was noticed while seeing if PR 102580 was fixed.

[Bug middle-end/115910] [15 Regression] ((unsigned)x)/3 with a range for (unsigned)x that does not have the sign bit set seems to produce much worse code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115910 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0

[Bug middle-end/115910] New: [15 Regression] ((unsigned)x)/3 with a range for (unsigned)x that does not have the sign bit set seems to produce much worse code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115910 Bug ID: 115910 Summary: [15 Regression] ((unsigned)x)/3 with a range for (unsigned)x that does not have the sign bit set seems to produce much worse code Product: gcc

[Bug middle-end/102580] Failure to optimize signed division to unsigned division when dividend can't be negative

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580 --- Comment #9 from Andrew Pinski --- (In reply to Gabriel Ravier from comment #8) > Seems to be fixed on trunk ? Actually it is worse on the trunk for the casting case. Let me file that seperately.

[Bug c++/102623] Failure to detect destructed scalar objects in consteval function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102623 --- Comment #3 from Gabriel Ravier --- Seems fixed on trunk ?

[Bug middle-end/102580] Failure to optimize signed division to unsigned division when dividend can't be negative

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580 --- Comment #8 from Gabriel Ravier --- Seems to be fixed on trunk ?

[Bug middle-end/115887] ICE: in gsi_insert_on_edge_immediate, at gimple-iterator.cc:849 with -O -fnon-call-exceptions -finstrument-functions and _BitInt()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115887 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-07-13 Host|x86_64-pc

[Bug target/95762] Failure to optimize __builtin_convertvector from vector of 16 chars to vector of 16 shorts in a single instruction on AVX2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95762 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 Resolution|---

[Bug target/95762] Failure to optimize __builtin_convertvector from vector of 16 chars to vector of 16 shorts in a single instruction on AVX2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95762 --- Comment #6 from Gabriel Ravier --- Seems fixed on trunk ?

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug tree-optimization/95230] Failure to optimize bit-scatter pattern to and 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95230 --- Comment #6 from Gabriel Ravier --- Oh oops, I was looking at -O3 output instead of -O2.

[Bug tree-optimization/95230] Failure to optimize bit-scatter pattern to and 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95230 --- Comment #5 from Andrew Pinski --- (In reply to Gabriel Ravier from comment #4) > Seems to be fixed on trunk ? The loop is still there: .L2: add w1, w1, 1 cmp w1, 32 bne .L2 [local count: 1018683651]:

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #38 from Arsen Arsenović --- (In reply to cqwrteur from comment #35) > Unless the "old enough glibc" won't be able to build latest GCC. Even glibc > 2.25 (which is centos stucks with). File a bug or write a patch. I'm not sure how y

[Bug tree-optimization/95230] Failure to optimize bit-scatter pattern to and 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95230 --- Comment #4 from Gabriel Ravier --- Seems to be fixed on trunk ?

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/115909] New: C++20 operator<=> explicitly defaulted but defined as deleted after first declaration does not error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115909 Bug ID: 115909 Summary: C++20 operator<=> explicitly defaulted but defined as deleted after first declaration does not error Product: gcc Version: 15.0 Status: UNCONFIRM

[Bug c++/52659] GCC fails to reject a deleted function definition which is not the first declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659 --- Comment #5 from Mital Ashok --- (It compiles with a warning, but that is not promoted to an error even with -pedantic, and the example shows how I think that accepting it even as an extension is harmful)

[Bug c++/52659] GCC fails to reject a deleted function definition which is not the first declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659 Mital Ashok changed: What|Removed |Added CC||mital at mitalashok dot co.uk --- Comment

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #36 from cqwrteur --- Also, it is a waste of energy and time to build the same compiler on different machines over and over again instead of just building one, packaging it and distributed it among many machines. Plus Cloud servers h

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #35 from cqwrteur --- (In reply to Arsen Arsenović from comment #34) > (In reply to cqwrteur from comment #29) > > I don't know how you do that. It is impossible to upgrade glibc on any of my > > linux distributions. I tried ubuntu,

[Bug c/114727] ICE with c23 with aligned attribute and -g

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114727 uecker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 uecker at gcc dot gnu.org changed: What|Removed |Added Known to work||15.0 --- Comment #12 from ue

[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115502 --- Comment #11 from Sam James --- As far as I'm concerned, all of these issues are now fixed and I haven't hit them since. I was leaving it to you and Jakub in case there were some followups needed or something.

[Bug c/115502] [15 regression] ICE when building Valgrind with -std=c23 (comptypes_same_p, at c/c-typeck.cc:1227) since r15-934-gd2cfe8a73b3c41

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115502 --- Comment #10 from uecker at gcc dot gnu.org --- Can this be closed?

[Bug c/115696] [15 regression] ICE on invalid repeated mixed declarations (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in comptypes_verify, at c/c-typeck.cc:1178)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115696 uecker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #34 from Arsen Arsenović --- (In reply to cqwrteur from comment #29) > I don't know how you do that. It is impossible to upgrade glibc on any of my > linux distributions. I tried ubuntu, arch linux. Neither of them allows me > to upg

[Bug target/115889] [15 Regression] FAIL: gcc.dg/vect/vect-vfa-03.c execution test with -march=znver4 --param vect-partial-vector-usage=1 since r15-1368-g6d0b7b69d14302

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115889 --- Comment #7 from Levy Hsu --- It appears that vect-partial-vector-usage=2 causes short int type V32HI falls into vpermt2_sepcial_bf16_shuffle_ while the original one was intended for bf16, will investigate.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #33 from cqwrteur --- https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html "If build and target are the same, but host is different, you are using a cross compiler to build a cross compiler that produces code for the machine y

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #32 from cqwrteur --- (In reply to cqwrteur from comment #31) > > Why not? It has to pull libraries and headers from somewhere (note that I > > do not know what "crossback" means). > > > > Note that there is desire to not predefine

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #31 from cqwrteur --- > Why not? It has to pull libraries and headers from somewhere (note that I > do not know what "crossback" means). > > Note that there is desire to not predefine _GNU_SOURCE in C++ modes. See > the PRs Andrew

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #30 from cqwrteur --- (In reply to cqwrteur from comment #29) > (In reply to Arsen Arsenović from comment #28) > > (In reply to cqwrteur from comment #26) > > > > The c++ frontend has defined _GNU_Source since at least 2001. > > > >

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #28 from Arsen Arsenović --- (In reply to cqwrteur from comment #26) > > The c++ frontend has defined _GNU_Source since at least 2001. > > You are de facto, breaking abi without any good reason. You break > cross-compiling for linux

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug preprocessor/115903] libcpp/macro.cc:528:19: style: Obsolete function 'asctime' called

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115903 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #22 from cqwrteur --- (In reply to Arsen Arsenović from comment #20) > (In reply to cqwrteur from comment #17) > > Then why? Why does it define _ISOC2X_SOURCE? C++ is not even C. > > "it"? presuming you mean glibc, because _GNU_SOU

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #20 from Arsen Arsenović --- (In reply to cqwrteur from comment #17) > Then why? Why does it define _ISOC2X_SOURCE? C++ is not even C. "it"? presuming you mean glibc, because _GNU_SOURCES enables all features, including the C2X spe

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #18 from cqwrteur --- (In reply to Andrew Pinski from comment #16) > (In reply to cqwrteur from comment #10) > > (In reply to Andrew Pinski from comment #6) > > > There is NO fix inside gcc/libstdc++. > > > THe only fix is your build

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Arsen Arsenović changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALI

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #13 from cqwrteur --- (In reply to cqwrteur from comment #12) > (In reply to Andrew Pinski from comment #6) > > There is NO fix inside gcc/libstdc++. > > THe only fix is your build of GCC (which includes the target libraries) > > nee

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #12 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of gli

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #11 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of gli

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #10 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of gli

[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 --- Comment #2 from Artyom Kolpakov --- When I wrote about returning the reference, i meant the return type of get_return_object(), and not the coroutine itself

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #9 from cqwrteur --- (In reply to Andrew Pinski from comment #6) > There is NO fix inside gcc/libstdc++. > THe only fix is your build of GCC (which includes the target libraries) > needs to be build against the oldest version of glib

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #7 from cqwrteur --- Created attachment 58654 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58654&action=edit patch

[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 --- Comment #1 from Andrew Pinski --- Created attachment 58653 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58653&action=edit testcase Next time please attach or place inline the testcase rather than just link to godbolt.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #5 from cqwrteur --- (In reply to Andrew Pinski from comment #3) > Note while glibc is backwards compatibility, it is not forward compatible. > So if you build against the newest version of glibc, it will always use the > newest symb

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 cqwrteur changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug c++/115908] New: [coroutines] Wrong behavior of using get_return_object() coroutines creation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 Bug ID: 115908 Summary: [coroutines] Wrong behavior of using get_return_object() coroutines creation Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: n

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #3 from Andrew Pinski --- Note while glibc is backwards compatibility, it is not forward compatible. So if you build against the newest version of glibc, it will always use the newest symbols and that is by design.

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/115907] Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 --- Comment #1 from cqwrteur --- Created attachment 58652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58652&action=edit dependency

[Bug libstdc++/115907] New: Libstdc++ and GCC itself should avoid glibc above 2.34 dependency

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115907 Bug ID: 115907 Summary: Libstdc++ and GCC itself should avoid glibc above 2.34 dependency Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug c++/115906] New: [coroutines] ICE when co_await used as default argument in function declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115906 Bug ID: 115906 Summary: [coroutines] ICE when co_await used as default argument in function declaration Product: gcc Version: 15.0 Status: UNCONFIRMED Severity

[Bug target/115889] [15 Regression] FAIL: gcc.dg/vect/vect-vfa-03.c execution test with -march=znver4 --param vect-partial-vector-usage=1 since r15-1368-g6d0b7b69d14302

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115889 Richard Biener changed: What|Removed |Added CC||admin at levyhsu dot com Su

[Bug tree-optimization/115868] [14 Regression] ICE: in exact_div, at poly-int.h:2156

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115868 Richard Biener changed: What|Removed |Added Known to work||15.0 Priority|P3

[Bug tree-optimization/115868] [14/15 Regression] ICE: in exact_div, at poly-int.h:2156

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115868 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:abf3964711f05b6858d9775c3595ec2b45483e14 commit r15-2014-gabf3964711f05b6858d9775c3595ec2b45483e14 Author: Richard Biener Date:

[Bug c++/115905] New: [coroutines] Wrong behavior of await_suspend()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 Bug ID: 115905 Summary: [coroutines] Wrong behavior of await_suspend() Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug rtl-optimization/115901] [15 regression] ICE when building coreutils-9.5 on arm64 with -O3 -flto -fno-vect-cost-model -ftrivial-auto-var-init=zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115901 Richard Sandiford changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org

[Bug preprocessor/115903] libcpp/macro.cc:528:19: style: Obsolete function 'asctime' called

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115903 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv

[Bug preprocessor/115903] libcpp/macro.cc:528:19: style: Obsolete function 'asctime' called

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115903 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Funny it looks like clang does the same thing for timestamp too :). s/clang/flang/

[Bug preprocessor/115903] libcpp/macro.cc:528:19: style: Obsolete function 'asctime' called

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115903 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv

[Bug target/115752] [13/14/15 Regression] [loongarch -O1] ICE: maximum number of generated reload insns per insn achieved (90)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115752 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |13.4

[Bug c++/115902] [14/15 Regression] Can't call immediate function within "if consteval" when optimizing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115902 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from Andre

[Bug c++/115902] [14/15 Regression] Can't call immediate function within "if consteval" when optimizing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115902 Andrew Pinski changed: What|Removed |Added Summary|Can't call immediate|[14/15 Regression] Can't

[Bug preprocessor/115903] libcpp/macro.cc:528:19: style: Obsolete function 'asctime' called

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115903 --- Comment #2 from Andrew Pinski --- Note the path to hit this is __TIMESTAMP__ . /* Generate __TIMESTAMP__ string, that represents the date and time of the last modification of the current

[Bug preprocessor/115903] libcpp/macro.cc:528:19: style: Obsolete function 'asctime' called

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115903 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-07-13 Ever confirmed|0

[Bug c++/115904] C++ 20, Lambda type template instantiated inside a class template method leads to crash

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115904 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|---

  1   2   >