On Wed, Mar 05, 2025 at 05:28:49PM -0500, Jason Merrill wrote:
> 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.
Ah yeah,
@@ -9649,7 +9651,9 @@ maybe_constant_init_1 (tree t, tree decl, bool
allow_non_constant,
static or thread storage duration even if it isn't required, but we
shouldn't bend the rules the same way for automatic variables. */
bool is_static = (decl && DECL_P (decl)
- && (TREE_STATIC (decl) || DECL_EXTERNAL (decl)));
+ && ((TREE_STATIC (decl)
+ && !DECL_DECLARED_CONSTEXPR_P (decl))
+ || DECL_EXTERNAL (decl)));
if (is_static)
manifestly_const_eval = true;
does seem to work. I don't know how I would fix constexpr-new3.C though.
> > Also, while using ctx->strict fixes constexpr-new25.C, it doesn't fix
> > the constexpr-new24.C crash.
>
> Why?
Took me a sec but it's because there's no CONVERT_EXPR, only NOP_EXPR.
In that test we start off with:
1 * (sizetype) (long int) &a
where (long int) &a is a CONVERT_EXPR, but after the
size = cp_fully_fold (size);
in build_new_1 we get:
(sizetype) &a
and the CONVERT_EXPR is gone. Expanding the "conversion from pointer type"
check to NOP_EXPR breaks a lot of other tests. Sigh.
Marek
