https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123790
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
One option would be also not to do that build_nop for NULLPTR_TYPE, so
--- gcc/cp/call.cc.jj 2026-01-28 09:34:32.744243500 +0100
+++ gcc/cp/call.cc 2026-01-28 18:30:17.647847870 +0100
@@ -8689,7 +8689,12 @@ maybe_adjust_type_name (tree type, tree
literal). Maybe we want to express already-rvalue in the
conversion somehow? */
|| TREE_CODE (expr) == NON_LVALUE_EXPR))
- expr = build_nop (type, expr);
+ {
+ if (NULLPTR_TYPE_P (type) && integer_zerop (expr))
+ expr = build_zero_cst (type);
+ else
+ expr = build_nop (type, expr);
+ }
return expr;
}
Though, that
if (NULLPTR_TYPE_P (type) && null_ptr_cst_p (op))
return build_zero_cst (type);
in constexpr.cc (or both) would work too. Note, for integral etc. types, we do
fold and that folds the cast, but NULLPTR_TYPE is something the generic folding
doesn't handle.
