[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2023-05-21 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|12.3|11.4

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2023-05-21 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:58d2a4cdbbafa4431eb9cff3778099d185f9f391

commit r11-10804-g58d2a4cdbbafa4431eb9cff3778099d185f9f391
Author: Patrick Palka 
Date:   Thu Dec 15 16:02:05 2022 -0500

c++: extract_local_specs and unevaluated contexts [PR100295]

Here during partial instantiation of the constexpr if, extra_local_specs
walks the statement looking for local specializations within to capture.
However, we're thwarted by the fact that 'ts' first appears inside an
unevaluated context, and so the calls to process_outer_var_ref for its
local specializations are a no-op.  And since we walk each tree exactly
once, we end up not capturing the local specializations despite 'ts'
later occurring in an evaluated context.

This patch fixes this by making extract_local_specs walk evaluated
contexts first before walking unevaluated contexts.  We could probably
get away with not walking unevaluated contexts at all, but this approach
seems more clearly safe.

PR c++/100295
PR c++/107579

gcc/cp/ChangeLog:

* pt.c (el_data::skip_unevaluated_operands): New data member.
(extract_locals_r): If skip_unevaluated_operands is true,
don't walk into unevaluated contexts.
(extract_local_specs): Walk the pattern twice, first with
skip_unevaluated_operands true followed by it set to false.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if-lambda5.C: New test.

(cherry picked from commit 18499b9f848707aee42d810e99ac0a4c9788433c)

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2023-02-17 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

Patrick Palka  changed:

   What|Removed |Added

  Known to work||12.2.1, 13.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 12.3/13

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2022-12-19 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:cdc1a14be1182874ccf1ceb27ee5b67c5ce8c62d

commit r12-8998-gcdc1a14be1182874ccf1ceb27ee5b67c5ce8c62d
Author: Patrick Palka 
Date:   Thu Dec 15 16:02:05 2022 -0500

c++: extract_local_specs and unevaluated contexts [PR100295]

Here during partial instantiation of the constexpr if, extra_local_specs
walks the statement looking for local specializations within to capture.
However, we're thwarted by the fact that 'ts' first appears inside an
unevaluated context, and so the calls to process_outer_var_ref for its
local specializations are a no-op.  And since we walk each tree exactly
once, we end up not capturing the local specializations despite 'ts'
later occurring in an evaluated context.

This patch fixes this by making extract_local_specs walk evaluated
contexts first before walking unevaluated contexts.  We could probably
get away with not walking unevaluated contexts at all, but this approach
seems more clearly safe.

PR c++/100295
PR c++/107579

gcc/cp/ChangeLog:

* pt.cc (el_data::skip_unevaluated_operands): New data member.
(extract_locals_r): If skip_unevaluated_operands is true,
don't walk into unevaluated contexts.
(extract_local_specs): Walk the pattern twice, first with
skip_unevaluated_operands true followed by it set to false.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if-lambda5.C: New test.

(cherry picked from commit 18499b9f848707aee42d810e99ac0a4c9788433c)

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2022-12-15 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
 Status|NEW |ASSIGNED

--- Comment #7 from Patrick Palka  ---
Fixed on trunk so far

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2022-12-15 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:18499b9f848707aee42d810e99ac0a4c9788433c

commit r13-4730-g18499b9f848707aee42d810e99ac0a4c9788433c
Author: Patrick Palka 
Date:   Thu Dec 15 16:02:05 2022 -0500

c++: extract_local_specs and unevaluated contexts [PR100295]

Here during partial instantiation of the constexpr if, extra_local_specs
walks the statement looking for local specializations within to capture.
However, we're thwarted by the fact that 'ts' first appears inside an
unevaluated context, and so the calls to process_outer_var_ref for its
local specializations are a no-op.  And since we walk each tree exactly
once, we end up not capturing the local specializations despite 'ts'
later occurring in an evaluated context.

This patch fixes this by making extract_local_specs walk evaluated
contexts first before walking unevaluated contexts.  We could probably
get away with not walking unevaluated contexts at all, but this approach
seems more clearly safe.

PR c++/100295
PR c++/107579

gcc/cp/ChangeLog:

* pt.cc (el_data::skip_unevaluated_operands): New data member.
(extract_locals_r): If skip_unevaluated_operands is true,
don't walk into unevaluated contexts.
(extract_local_specs): Walk the pattern twice, first with
skip_unevaluated_operands true followed by it set to false.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if-lambda5.C: New test.

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2022-12-03 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

Andrew Pinski  changed:

   What|Removed |Added

 CC||onebit74 at gmail dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 107955 has been marked as a duplicate of this bug. ***

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2022-08-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

Andrew Pinski  changed:

   What|Removed |Added

 CC||janezz55 at gmail dot com

--- Comment #4 from Andrew Pinski  ---
*** Bug 106689 has been marked as a duplicate of this bug. ***

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2021-10-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

--- Comment #3 from Andrew Pinski  ---
*** Bug 102778 has been marked as a duplicate of this bug. ***

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2021-10-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

Andrew Pinski  changed:

   What|Removed |Added

 CC||benni.probst at gmx dot de

--- Comment #2 from Andrew Pinski  ---
*** Bug 102866 has been marked as a duplicate of this bug. ***

[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr

2021-04-28 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2021-04-28
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Confirmed, looks like this never worked.