[Bug c++/104384] coroutines: Heap corruption when initializing struct with co_await

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104384 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug c++/107288] coroutines: Double-free of temporaries created in statement following co_await

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107288 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug c++/103909] coroutines: co_yield of aggregate-initialized temporaries leads to segmentation faults.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103909 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug analyzer/109027] [13 Regression] ICE: SIGSEGV (infinite recursion in ana::constraint_manager::eval_condition / ana::constraint_manager::impossible_derived_conditions_p) with -fanalyzer since r13-

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027 --- Comment #3 from Steven Sun --- Oh, my reduced test case has the same infinite recursion occurring, where the `a+4` is binop_svalue (pointer_plus_expr, unaryop_svalue (nop_expr, conjured_svalue (, _iterator::_iterator (&__position, 0);, dec

[Bug analyzer/109027] [13 Regression] ICE: SIGSEGV (infinite recursion in ana::constraint_manager::eval_condition / ana::constraint_manager::impossible_derived_conditions_p) with -fanalyzer since r13-

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug analyzer/108767] O2 optimization has side effects on static analysis.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108767 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug analyzer/109190] GCC Static Analyzer cannot handle the initialization of an array with a for loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109190 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug c++/109283] Destructor of co_yield conditional argument called twice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109283 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand since r12-5253-g4df7f8c79835d569

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #11 from Steven Sun --- (In reply to Andrew Pinski from comment #10) > https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2392 > > "potentially-evaluated". Oh, I realized that, According to the DR 2392 accepted as a DR

[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #7 from Steven Sun --- I got one simple idea as a workaround. I do not have the resources to do the tests. I agree anyone to take the following patch or the idea. >From 35b4186a0ed3671de603bed6df5fb1156f087581 Mon Sep 17 00:00:00

[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #6 from Steven Sun --- g:4df7f8c79835d56928f51f9e674d326300936e8e c++: don't do constexpr folding in unevaluated context The implicit constexpr patch revealed that we were doing constant evaluation of arbitrary expressions in uneva

[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #5 from Steven Sun --- h:4df7f8c79835d56928f51f9e674d326300936e8e sorry, copied wrong hash code

[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #3 from Steven Sun --- Bisecting tells me: 2551cd4f9bc1afee444a56e03c1cee6899593da9 is bad adcfd2c45c3523d74279b5fcac1d7c6c34dd1382 is good I think commit ddd25bd1a7c8f456bc914e34b77d43f39a1062d4 might be the root cause.

[Bug c++/108218] [12 Regression] Constant arguments in the new expression is not checked in unevaluated operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #1 from Steven Sun --- My concern is that, expressions within the require expressions are also considered as "unevaluated operands". Thus, the following concept is evaluated as true, but the program is ill-formed and does not compil

[Bug c++/108218] New: [12 Regression] Constant arguments in the new expression is not checked in unevaluated operand

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 Bug ID: 108218 Summary: [12 Regression] Constant arguments in the new expression is not checked in unevaluated operand Product: gcc Version: 12.1.0 Status: UNCONFIRMED

[Bug c++/101681] PMF comparison to nullptr is not considered a constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101681 --- Comment #3 from Steven Sun --- By the way, in the current design, the class definition is passed twice in order we can see every member data/function declaration before parsing NSDMI and member functions. The class is complete after parsing

[Bug c++/101681] PMF comparison to nullptr is not considered a constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101681 --- Comment #2 from Steven Sun --- The root cause for this is that the compiler forbids constant folding when involving PMF of an incomplete class. https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/cp/expr.c;h=d16d1896f2ddd08264b389b02b9640cca332e

[Bug c++/101681] PMF comparison to nullptr is not considered a constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101681 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug c++/101717] [12 Regression] ICE capturing static member within stateless generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101717 --- Comment #5 from Steven Sun --- (In reply to Andrew Pinski from comment #4) Thanks! (In reply to myself from comment #3) > The program seems never think of a situation "a lambda inside a lambda > inside a NSDMI`. We need to amend the logic

[Bug c++/101717] [12 Regression] ICE capturing static member within stateless generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101717 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug c++/100877] g++ freezes system by consuming infinite amount of memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comm

[Bug c++/100877] g++ freezes system by consuming infinite amount of memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100877 --- Comment #1 from Steven Sun --- I look at the call stack. Most of the time is wasted on `dump_template_parms` in `gcc/cp/error.c`. I commented several functions calling it: (I'm using stage-1 compiler) `announce_function` in `gcc/toplev.c`

[Bug c++/99686] ICE when using both concepts and full specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686 --- Comment #8 from Steven Sun --- under c++17 Step 4 needs `types_match == 1` [at 1] but, its value is zero, which is caused by `function_requirements_equivalent_p` [at 3] returns 0 [at 2] . [1] https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/c

[Bug c++/99686] ICE when using both concepts and full specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686 --- Comment #7 from Steven Sun --- After digging for two days, I think I may know what's happening inside. Under std=c++20 and my code in comment 1, the flow when parsing a full function specialization would be 1. Found a full specialization o

[Bug c++/99686] ICE when using both concepts and full specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686 --- Comment #6 from Steven Sun --- While in C++20, the complier thinks it's unnecessary to instatiate a new template. Just use the full specialization! Thus, this bug wouldn't exist at first place. Intuitively, I am in favor of the compiler's C+

[Bug c++/99686] ICE when using both concepts and full specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686 --- Comment #5 from Steven Sun --- I learn a little about gcc recently. I think I got a vague idea of what's going on inside. In c++17 mode with concepts, and with my code in comment 1. The compiler decides to instantiate from the concept const

[Bug c++/99686] ICE when using both concepts and full specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686 --- Comment #3 from Steven Sun --- @W E Brown: I got your idea. So are all uses like this ill-formed? This seems unexpected for me. I would expect the complete specialization is full specialization for both primary templates. I also find facts t

[Bug c++/99686] ICE when concepts on C++17 when providing both T&& and const T& specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686 --- Comment #1 from Steven Sun --- The compiler args are only "g++ -fconcepts -std=c++17" It should choose the full specialization func(int &&), while the compiler aborts during the instatiation of the partial specialization (using concepts). I

[Bug c++/99686] New: ICE when concepts on C++17 when providing both T&& and const T& specialization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686 Bug ID: 99686 Summary: ICE when concepts on C++17 when providing both T&& and const T& specialization Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity:

[Bug c++/99019] New: A nicer error hint, for cpp modules, if missing headers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99019 Bug ID: 99019 Summary: A nicer error hint, for cpp modules, if missing headers Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priorit

[Bug c++/98944] [modules] Failed to read compiled module with a non-exported partition.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98944 Steven Sun changed: What|Removed |Added CC||StevenSun2021 at hotmail dot com --- Comme