]> git.ipfire.org Git - thirdparty/gcc.git/commit
c++: remove TREE_STATIC from constexpr heap vars [PR119162]
authorJason Merrill <jason@redhat.com>
Tue, 11 Mar 2025 15:17:46 +0000 (11:17 -0400)
committerJason Merrill <jason@redhat.com>
Thu, 1 May 2025 12:52:50 +0000 (08:52 -0400)
commit25fe59805029e164bfbe347adbdf62856d1b1b1e
tree944bf3b4eb2a7182f0e8fda84e4318db5f1b2d6e
parentaa6f1df4ec46a20d2292291b192d3331e51b59f8
c++: remove TREE_STATIC from constexpr heap vars [PR119162]

While working on PR119162 it occurred to me that it would be simpler to
detect the problem of a value referring to a heap allocation if we stopped
setting TREE_STATIC on them so they naturally are not considered to have a
constant address.  With that change we no longer need to specifically avoid
caching a value that refers to a deleted pointer.

But with this change maybe_nonzero_address is not sure whether the variable
could have address zero.  I don't understand why it returns 1 only for
variables in the current function, rather than all non-symtab decls; an auto
variable from some other function also won't have address zero.  Maybe this
made more sense when it was in tree_single_nonzero_warnv_p before r7-5868?

But assuming there is some reason for the current behavior, this patch only
changes the handling of non-symtab decls when folding_cxx_constexpr.

PR c++/119162

gcc/cp/ChangeLog:

* constexpr.cc (find_deleted_heap_var): Remove.
(cxx_eval_call_expression): Don't call it.  Don't set TREE_STATIC on
heap vars.
(cxx_eval_outermost_constant_expr): Don't mess with varpool.

gcc/ChangeLog:

* fold-const.cc (maybe_nonzero_address): Return 1 for non-symtab
vars if folding_cxx_constexpr.
gcc/cp/constexpr.cc
gcc/fold-const.cc