https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127741
Bug ID: 127741
Summary: [GCC C++20] `new char[(long) &a]` as the initializer
of a namespace-scope variable ICEs in
`cxx_eval_call_expression` (constexpr.cc:4578)
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 0599jiangyc at gmail dot com
Target Milestone: ---
**Repo:** gcc-mirror/gcc · **Commit:** `d373724d1` (master, 2026-09-17) ·
**Build:** `--enable-languages=c,c++ --disable-bootstrap
--enable-checking=yes,extra,rtl` (x86_64-pc-linux-gnu, Ubuntu 22.04)
## What happens
A perfectly ordinary dynamic allocation whose size is a pointer converted to an
integer
crashes when it initializes a namespace-scope variable in C++20 mode.
`store_init_value`
tries constant evaluation of the initializer (`maybe_constant_init`); the
new-expression
handling in `cxx_eval_call_expression` expects a non-constant size to have been
rejected
by the preceding `VERIFY_CONSTANT`, and hits `gcc_checking_assert (false)`
instead:
```
t.cc:2:32: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.cc:4578
2 | auto p = new char[(long int) &a];
| ^
0x7c6f9d cxx_eval_call_expression
cp/constexpr.cc:4578
0xe3a96d cxx_eval_constant_expression(...)
cp/constexpr.cc:9996
0xe39f1a cxx_eval_constant_expression(...)
cp/constexpr.cc:10718
0xe4c5cc cxx_eval_outermost_constant_expr
cp/constexpr.cc:11655
0xe55e98 maybe_constant_init_1
cp/constexpr.cc:12302
0x1135b45 store_init_value(...) cp/typeck2.cc:1119
0xedafa3 check_initializer cp/decl.cc:8778
0xee0df6 cp_finish_decl(...) cp/decl.cc:10063
```
## Reproducer
`gcc-new-array-size-pointer-cast.cc`:
```cpp
int a;
auto p = new char[(long int) &a];
```
```bash
g++ -fsyntax-only gcc-new-array-size-pointer-cast.cc # default
-std=gnu++20; -std=c++20 and -O2 -c behave the same
```
`char *p = new char[(long int) &a];` crashes the same way. `-std=c++17`
compiles it.
Inside a function body the same statement compiles at `-O0` but crashes
identically at
`-O1`, `-Og` and `-O2`; in particular the testsuite's own
`g++.dg/cpp2a/constexpr-new24.C`
ICEs on its `f2` with `g++ -fsyntax-only -O1 -std=c++20` (it only passes at
`-O0`).
## Expected
The program compiles: the size is a run-time value, and the non-constexpr
initializer is
not required to be a constant expression. Inside a `constexpr` function the
same expression
is correctly diagnosed ("conversion from pointer type 'int*' to arithmetic type
'long int'
in a constant expression", `g++.dg/cpp2a/constexpr-new24.C`).
## Notes
Found by compiling a fusion of `constexpr-new24.C` under `-O2`; the
namespace-scope form
reproduces without any optimisation flag. GCC 11.4 compiles the reproducer.
**Upstream dedup 2026-10-06:** Bugzilla quicksearch (ALL states)
`cxx_eval_call_expression new array size`, `new char[] pointer cast ICE
constexpr`, `cxx_eval_call_expression constexpr.cc new`, `constexpr-new24.C`,
`constexpr new24`, `new expression non-constant size ICE
cxx_eval_call_expression`, `operator new array size VERIFY_CONSTANT ICE`,
`fold_to_constant new`, `new array size conversion pointer integer ICE c++20`,
plus a sweep of every bug filed since 2026-09-17 and WebSearch
`site:gcc.gnu.org/bugzilla cxx_eval_call_expression new array size
constexpr.cc`; gcc-patches Sept/Oct 2026 subject index: no patch touching
`cxx_eval_call_expression` or `build_new_1`. Verdict: **related to
[PR118775](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118775), mention
(reopen candidate)**: `constexpr-new24.C` is that PR's test, and the assert we
hit at `constexpr.cc:4578` is the `gcc_checking_assert (false)` that r16-56
("c++: new size folding [PR118775]", 2025-04-21) put in place of the r15-7893
`tree_fits_uhwi_p` guard, on the theory that `build_new_1` now folds less and
so the `CONVERT_EXPR` survives for `VERIFY_CONSTANT` to reject. Our
namespace-scope and `-O1`-in-function cases show the conversion is still folded
away in those paths, so the assert fires on valid code; PR118775 is RESOLVED
FIXED (last activity 2026-08-20 was the GCC 13 backport), so this is not fixed
since checkout. Suggested action: file as a new PR citing r16-56 and PR118775
(or ask to reopen), noting the testsuite's own `constexpr-new24.C` fails at
`-O1 -std=c++20`.
[PR108218](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218) (new-size
constant checks in unevaluated operands) is a different problem.
