On 5/1/25 9:33 AM, Patrick Palka wrote:
On Mon, 21 Apr 2025, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
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.
FWIW the maybe_nonzero_address change seems to fix PR85944, yay!
Yay!
Except for the PR115207 dup, which we still reject with
115207.C:11:18: error: ‘(((const value*)(&<anonymous>)) != ((const value*)(&
test.array<4>::_items)))’ is not a constant expression
11 | if (this != &other) {
| ~~~~~^~~~~~~~~
Could this mean another spot in the middle-end needs relaxing in order to
handle address comparisons of context-less local vars?
This seems to actually be a front-end issue.
Jason
