On 3/5/25 4:00 PM, Marek Polacek wrote:
On Wed, Mar 05, 2025 at 03:31:59PM -0500, Jason Merrill wrote:
On 3/5/25 12:09 PM, Marek Polacek wrote:
On Tue, Mar 04, 2025 at 05:34:10PM -0500, Jason Merrill wrote:
On 2/11/25 6:24 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE since r11-7740 because we no longer say that (long)&a
(where a is a global var) is non_constant_p. So VERIFY_CONSTANT
does not return and we crash on tree_to_uhwi. We should check
tree_fits_uhwi_p before calling tree_to_uhwi.
PR c++/118775
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): Check tree_fits_uhwi_p.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/constexpr-new24.C: New test.
* g++.dg/cpp2a/constexpr-new25.C: New test.
---
gcc/cp/constexpr.cc | 7 +++++
gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C | 25 ++++++++++++++++++
gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C | 27 ++++++++++++++++++++
3 files changed, 59 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C
diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index f142dd32bc8..f8f9a9df1a2 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -2909,6 +2909,13 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
gcc_assert (arg0);
if (new_op_p)
{
+ if (!tree_fits_uhwi_p (arg0))
+ {
+ if (!ctx->quiet)
+ error_at (loc, "cannot allocate array: size too large");
"too large" seems misleading in this case, where it just isn't a
compile-time constant.
Fair, how about "size not constant"?
Why didn't the VERIFY_CONSTANT just above already reject this?
This is about *non_constant_p. Since r11-7740 cxx_eval_constant_expression
returns early less often:
@@ -6656,7 +6656,8 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
if (TREE_CODE (t) == CONVERT_EXPR
&& ARITHMETIC_TYPE_P (type)
- && INDIRECT_TYPE_P (TREE_TYPE (op)))
+ && INDIRECT_TYPE_P (TREE_TYPE (op))
+ && ctx->manifestly_const_eval)
Aha. I think this should check ctx->strict instead of
ctx->manifestly_const_eval.
In the r11-7740 patch Jakub mentioned he had tried that, but it regressed
some tests. I've tried to see if that is still the case and it is; at
least
g++.dg/cpp1y/constexpr-shift1.C
g++.dg/cpp1y/constexpr-82304.C
g++.dg/cpp0x/constexpr-ex1.C
FAIL with ctx->strict.
This seems to be because maybe_constant_init_1 wrongly chooses
non-strict mode for static constexpr variables. After correcting that,
only constexpr-new3.C fails, which seems to be a latent bug that we can
otherwise see by moving v7 into a function.
Also, while using ctx->strict fixes constexpr-new25.C, it doesn't fix
the constexpr-new24.C crash.
Why?
Jason
