https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0fd824d717ca901319864a5eeba4e62b278f8329
commit r14-9942-g0fd824d717ca901319864a5eeba4e62b278f8329
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #11 from Jakub Jelinek ---
Actually I had another look.
Jason said in the c++: fix in-charge parm in constexpr mail back in December
(as well as in the r14-6507 commit message):
"Since a class with vbases can't have constexpr 'tors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #10 from Richard Biener ---
As a band-aid, can we turn the gcc_assert into a gcc_checking_assert to make
the issue latent (again) on release branches? I understand the issue _is_
latent?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #9 from Jakub Jelinek ---
Unfortunately the above patch regressed g++.dg/opt/is_constant_evaluated3.C
test.
For constructors, even when they have VOID_TYPE_P, initialized_type actually
returns non-VOID type, so constructors are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #8 from Jakub Jelinek ---
2024-03-22 Jakub Jelinek
PR c++/114426
* cp-gimplify.cc (cp_fold): Don't call maybe_const_value on
CALL_EXPRs to cdtors.
* g++.dg/cpp2a/pr114426.C: New test.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #7 from Jakub Jelinek ---
It is indeed the assert added in that patch.
When cp_fold_function is called on the _ZN12ConfiguratorD0Ev body which
contains
Configurator::~Configurator(this); call
Now, maybe_constant_value is called on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
