[Bug c++/114426] New: [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)

[Bug c++/114426] New: [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

            Bug ID: 114426
           Summary: [14 regression] ICE when building log4cxx on arm
                    (cxx_eval_call_expression, at cp/constexpr.cc:3242)
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

```
/usr/bin/armv7a-unknown-linux-gnueabihf-g++ -DFMT_SHARED -DLOG4CXX
-Dlog4cxx_EXPORTS
-I/var/tmp/portage/dev-libs/log4cxx-1.2.0/work/apache-log4cxx-1.2.0_build/src/main/include
-I/var/tmp/portage/dev-libs/log4cxx-1.2.0/work/apache-log4cxx-1.2.0/src/main/include
-I/usr/include/apr-1  -O3 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard
-fno-vect-cost-model -U_FORTIFY_SOURCE -fno-hardened -flto -Werror=odr
-Werror=lto-type-mismatch -Werror=strict-aliasing -std=c++20 -fPIC -MD -MT
src/main/cpp/CMakeFiles/log4cxx.dir/domconfigurator.cpp.o -MF
src/main/cpp/CMakeFiles/log4cxx.dir/domconfigurator.cpp.o.d -o
src/main/cpp/CMakeFiles/log4cxx.dir/domconfigurator.cpp.o -c
/var/tmp/portage/dev-libs/log4cxx-1.2.0/work/apache-log4cxx-1.2.0/src/main/cpp/domconfigurator.cpp
In file included from
/var/tmp/portage/dev-libs/log4cxx-1.2.0/work/apache-log4cxx-1.2.0/src/main/include/log4cxx/xml/domconfigurator.h:27,
                 from
/var/tmp/portage/dev-libs/log4cxx-1.2.0/work/apache-log4cxx-1.2.0/src/main/cpp/domconfigurator.cpp:19:
/var/tmp/portage/dev-libs/log4cxx-1.2.0/work/apache-log4cxx-1.2.0/src/main/include/log4cxx/spi/configurator.h:
In destructor ‘virtual constexpr log4cxx::spi::Configurator::~Configurato ()’:
/var/tmp/portage/dev-libs/log4cxx-1.2.0/work/apache-log4cxx-1.2.0/src/main/include/log4cxx/spi/configurator.h:38:22:
  in ‘constexpr’ expansion of ‘log4cxx::spi::Configurator::~Configurator()’
/var/tmp/portage/dev-libs/log4cxx-1.2.0/work/apache-log4cxx-1.2.0/src/main/include/log4cxx/spi/configurator.h:38:22:
internal compiler error: in cxx_eval_call_expression, at cp/constexpr.cc:3242
   38 | class LOG4CXX_EXPORT Configurator : virtual public helpers::Object
      |                      ^~~~~~~~~~~~
0xf374cb cxx_eval_call_expression
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/constexpr.cc:3242
0xf387cb cxx_eval_constant_expression
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/constexpr.cc:7535
0xf4bd3b cxx_eval_outermost_constant_expr
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/constexpr.cc:8833
0xf53a93 maybe_constant_value(tree_node*, tree_node*, mce_value)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/constexpr.cc:9121
0xf9ad63 cp_fold
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/cp-gimplify.cc:3405
0xf9bc0b cp_fold_r
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/cp-gimplify.cc:1359
0x21345d3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*))
        /usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/tree.cc:11428
0x2134897 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*))
        /usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/tree.cc:11662
0x2134d17 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, false, default_hash_traits<tree_node*> >*))
        /usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/tree.cc:11544
0xf8f2cf cp_fold_function(tree_node*)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/cp-gimplify.cc:1488
0x10173c3 finish_function(bool)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/decl.cc:18756
0x11531f7 maybe_clone_body(tree_node*)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/optimize.cc:708
0x12ce1bb expand_or_defer_fn_1(tree_node*)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/semantics.cc:5031
0x12ce74f expand_or_defer_fn(tree_node*)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/semantics.cc:5062
0x10c43bf synthesize_method(tree_node*)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/method.cc:1848
0x103c97f mark_used(tree_node*, int)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/decl2.cc:6020
0xed8467 build_over_call
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/call.cc:10563
0xedf08b build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/call.cc:11835
0xee08b3 build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, tree_node*, int, int)
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/call.cc:11320
0x106a707 expand_cleanup_for_base
       
/usr/src/debug/sys-devel/gcc-14.0.9999/gcc-14.0.9999/gcc/cp/init.cc:1697
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #1 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57765&action=edit
domconfigurator.cpp.ii.xz

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.gentoo.org/sho
                   |                            |w_bug.cgi?id=927394

--- Comment #2 from Sam James <sjames at gcc dot gnu.org> ---
Any idea why this only happened on arm btw?

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #3 from Sam James <sjames at gcc dot gnu.org> ---
g++ -c domconfigurator.cpp.ii -std=c++20 -O2

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
           Keywords|                            |ice-on-valid-code
             Target|                            |arm

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sam James from comment #2)
> Any idea why this only happened on arm btw?

because arm is the only target that returns true for
`targetm.cxx.cdtor_returns_this()`.

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #5 from Sam James <sjames at gcc dot gnu.org> ---
Reduced:
```
struct Object {
  virtual ~Object();
};
struct Configurator : virtual Object {
  virtual void doConfigure() = 0;
};
struct DOMConfigurator : Configurator {
  DOMConfigurator() {}
};
```

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org
           Priority|P3                          |P1

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-03-22
            Summary|[14 regression] ICE when    |[14 regression] ICE when
                   |building log4cxx on arm     |building log4cxx on arm
                   |(cxx_eval_call_expression,  |(cxx_eval_call_expression,
                   |at cp/constexpr.cc:3242)    |at cp/constexpr.cc:3242)
                   |                            |since r14-6507
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r14-6507-ge0659b5417b7f8a090ad2ed4dea830f11ef9c877

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 this in:
        /* Invoke maybe_constant_value for functions declared
           constexpr and not called with AGGR_INIT_EXPRs.
           TODO:
           Do constexpr expansion of expressions where the call itself is not
           constant, but the call followed by an INDIRECT_REF is.  */
        if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
            && !flag_no_inline)
          {
            mce_value manifestly_const_eval = mce_unknown;
            if (flags & ff_mce_false)
              /* Allow folding __builtin_is_constant_evaluated to false during
                 constexpr evaluation of this call.  */
              manifestly_const_eval = mce_false;
            r = maybe_constant_value (x, /*decl=*/NULL_TREE,
                                      manifestly_const_eval);
          }
also on targets other than arm, but except on arm the maybe_constant_value ->
cxx_eval_outermost_constant_expr call returns very quickly, because the call
has VOID_TYPE_P and constexpr_dtor is false and the dtor isn't
DECL_IMMEDIATE_FUNCTION_P,
so it
          /* Calls to immediate functions returning void need to be
             evaluated.  */
          tree fndecl = cp_get_callee_fndecl_nofold (t);
          if (fndecl == NULL_TREE || !DECL_IMMEDIATE_FUNCTION_P (fndecl))
            return t;
The difference on arm is that the CALL_EXPR doesn't have VOID_TYPE_P type, but
pointer to the class, so it evaluates it and triggers the assertion.

Now, if all we want to do is get the same behavior on arm as on other targets,
perhaps
we could avoid doing that maybe_constant_value in cp_fold if DECL_DESTRUCTOR_P
(callee) or perhaps even DECL_CONSTRUCTOR_P (callee).

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
2024-03-22  Jakub Jelinek  <jakub@redhat.com>

        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.

--- gcc/cp/cp-gimplify.cc.jj    2024-02-23 18:55:05.377594277 +0100
+++ gcc/cp/cp-gimplify.cc       2024-03-22 16:46:49.381442914 +0100
@@ -3395,7 +3395,14 @@ cp_fold (tree x, fold_flags_t flags)
           Do constexpr expansion of expressions where the call itself is not
           constant, but the call followed by an INDIRECT_REF is.  */
        if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
-           && !flag_no_inline)
+           && !flag_no_inline
+           /* Don't invoke it on cdtors.  On
+              !targetm.cxx.cdtor_returns_this () it won't do anything as it
+              has void type, so don't do it on
+              targetm.cxx.cdtor_returns_this () targets either for
+              consistency.  */
+           && !DECL_CONSTRUCTOR_P (callee)
+           && !DECL_DESTRUCTOR_P (callee))
          {
            mce_value manifestly_const_eval = mce_unknown;
            if (flags & ff_mce_false)
--- gcc/testsuite/g++.dg/cpp2a/pr114426.C.jj    2024-03-22 16:49:55.650882841
+0100
+++ gcc/testsuite/g++.dg/cpp2a/pr114426.C       2024-03-22 16:48:51.829759997
+0100
@@ -0,0 +1,6 @@
+// PR c++/114426
+// { dg-do compile }
+
+struct A { virtual ~A (); };
+struct B : virtual A { virtual void foo () = 0; };
+struct C : B { C () {} };

fixes the ICE, but dunno whether something different shouldn't be done instead.

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 optimized (though, dunno if not
differently on arm where initialized_type will likely return class* while on
other targets class).
So, we'd need to treat that way just destructors (if it shouldn't be fixed
elsewhere):
2024-03-23  Jakub Jelinek  <jakub@redhat.com>

        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.

--- gcc/cp/cp-gimplify.cc.jj    2024-02-23 18:55:05.377594277 +0100
+++ gcc/cp/cp-gimplify.cc       2024-03-22 16:46:49.381442914 +0100
@@ -3395,7 +3395,13 @@ cp_fold (tree x, fold_flags_t flags)
           Do constexpr expansion of expressions where the call itself is not
           constant, but the call followed by an INDIRECT_REF is.  */
        if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
-           && !flag_no_inline)
+           && !flag_no_inline
+           /* Don't invoke it on dtors.  On
+              !targetm.cxx.cdtor_returns_this () it won't do anything as it
+              has void type, so don't do it on
+              targetm.cxx.cdtor_returns_this () targets either for
+              consistency.  */
+           && !DECL_DESTRUCTOR_P (callee))
          {
            mce_value manifestly_const_eval = mce_unknown;
            if (flags & ff_mce_false)
--- gcc/testsuite/g++.dg/cpp2a/pr114426.C.jj    2024-03-22 16:49:55.650882841
+0100
+++ gcc/testsuite/g++.dg/cpp2a/pr114426.C       2024-03-22 16:48:51.829759997
+0100
@@ -0,0 +1,6 @@
+// PR c++/114426
+// { dg-do compile }
+
+struct A { virtual ~A (); };
+struct B : virtual A { virtual void foo () = 0; };
+struct C : B { C () {} };

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
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?

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 there isn't actually a
need for an in-charge parameter in a destructor"
but the ICE is because the destructor is marked implicitly constexpr.
https://eel.is/c++draft/dcl.constexpr#3.2 says that a destructor of a class
with virtual bases is not constexpr-suitable, but we were actually implementing
this just for constructors, so clearly my fault from the
https://wg21.link/P0784R7 implementation.  That paper clearly added that
sentence in there and removed similar sentence just from the constructor case.
--- gcc/cp/constexpr.cc.jj      2024-04-09 09:29:04.708521907 +0200
+++ gcc/cp/constexpr.cc 2024-04-12 11:45:08.845476718 +0200
@@ -262,18 +262,15 @@ is_valid_constexpr_fn (tree fun, bool co
        inform (DECL_SOURCE_LOCATION (fun),
                "lambdas are implicitly %<constexpr%> only in C++17 and
later");
     }
-  else if (DECL_DESTRUCTOR_P (fun))
+  else if (DECL_DESTRUCTOR_P (fun) && cxx_dialect < cxx20)
     {
-      if (cxx_dialect < cxx20)
-       {
-         ret = false;
-         if (complain)
-           error_at (DECL_SOURCE_LOCATION (fun),
-                     "%<constexpr%> destructors only available"
-                     " with %<-std=c++20%> or %<-std=gnu++20%>");
-       }
+      ret = false;
+      if (complain)
+       error_at (DECL_SOURCE_LOCATION (fun),
+                 "%<constexpr%> destructors only available with "
+                 "%<-std=c++20%> or %<-std=gnu++20%>");
     }
-  else if (!DECL_CONSTRUCTOR_P (fun))
+  else if (!DECL_CONSTRUCTOR_P (fun) && !DECL_DESTRUCTOR_P (fun))
     {
       tree rettype = TREE_TYPE (TREE_TYPE (fun));
       if (!literal_type_p (rettype))
patch fixes the ICE too, just will need to add testcase coverage and see what
regresses in the testsuite...

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:0fd824d717ca901319864a5eeba4e62b278f8329

commit r14-9942-g0fd824d717ca901319864a5eeba4e62b278f8329
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Apr 12 19:57:04 2024 +0200

    c++: Diagnose or avoid constexpr dtors in classes with virtual bases
[PR114426]

    I had another look at this P1 PR today.
    You 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 there isn't actually
    a need for an in-charge parameter in a destructor" but the ICE is because
    the destructor is marked implicitly constexpr.
    https://eel.is/c++draft/dcl.constexpr#3.2 says that a destructor of a class
    with virtual bases is not constexpr-suitable, but we were actually
    implementing this just for constructors, so clearly my fault from the
    https://wg21.link/P0784R7 implementation.  That paper clearly added that
    sentence in there and removed similar sentence just from the constructor
case.

    So, the following patch makes sure the
      else if (CLASSTYPE_VBASECLASSES (DECL_CONTEXT (fun)))
        {
          ret = false;
          if (complain)
            error ("%q#T has virtual base classes", DECL_CONTEXT (fun));
        }
    hunk is done no just for DECL_CONSTRUCTOR_P (fun), but also
    DECL_DESTRUCTOR_P (fun) - in that case just for cxx_dialect >= cxx20,
    as for cxx_dialect < cxx20 we already set ret = false; and diagnose
    a different error, so no need to diagnose two.

    2024-04-12  Jakub Jelinek  <jakub@redhat.com>

            PR c++/114426
            * constexpr.cc (is_valid_constexpr_fn): Return false/diagnose with
            complain destructors in classes with virtual bases.

            * g++.dg/cpp2a/pr114426.C: New test.
            * g++.dg/cpp2a/constexpr-dtor16.C: New test.

[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242) since r14-6507

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.