https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Let me see if I can untangle things here. Thanks for chasing
this down, BTW.
Value_Range doesn't need a CTOR because it has an int_range_max which
does have one (courtesy of int_range<>), so things get initialized
correctly. Deleting a memory allocated container that has a
Value_Range also works, because of the ~int_range<> destructor:
+ {
+ struct container
+ {
+ Value_Range vr;
+ };
+ struct container *pointer = new container;
+ pointer->vr.set_type (integer_type_node);
+ for (int i = 0; i < 100; i += 5)
+ {
+ int_range<1> tmp (integer_type_node,
+ wi::shwi (i, TYPE_PRECISION (integer_type_node)),
+ wi::shwi (i+1, TYPE_PRECISION (integer_type_node)));
+ pointer->vr.union_ (tmp);
+ }
+ delete pointer;
Deleting pointer causes us to call int_range<N,
RESIZABLE>::~int_range() which clean things appropriately.
So it looks like the problem is the missing destructor in IPA.
That being said, there's a few things I've noticed thanks to you guys'
analysis.
First, the virtual marker in the int_range<> destructor is not needed.
IPA + ranges went through various changes this release, and I believe
that was left over from when value_range (int_range<2>) was being
placed in GC space directly.
We went through various incantations this release wrt IPA storage of
ranges, both in GC and in the stack. Ultimately we ended up with
ipa_vr, which I believe is the only use of ranges in GC space, and
furthermore it uses vrange_storage not vrange nor irange nor anything
else. For that matter, vrange_storage doesn't even have pointers, so
we shouldn't need GTY markers at all.
It seems that since IPA is the only GC user of iranges, I think we
can safely remove GTY support from the entire vrange hierarchy.
The rule of thumb should be that only int_range<> and derivatives
should be in short-term storage, and GC users should use
vrange_storage (like ipa_vr is doing, or perhaps vrange_allocator
which automates the allocation).
