https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2024-01-23
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Jambor from comment #4)
> The right place where to free stuff in lattices post-IPA would be in
> ipa_node_params::~ipa_node_params() where we should iterate over lattices
> and deinitialize them or perhaps destruct the array because since
> ipcp_vr_lattice directly contains Value_Range which AFAIU directly contains
> int_range_max which has a virtual destructor... does not look like a POD
> anymore. This has escaped me when I was looking at the IPA-VR changes but
> hopefully it should not be too difficult to deal with.
OK, that might work for the IPA side.
It's quite unusual to introduce a virtual DTOR in the middle of the class
hierarchy though. Grepping I do see quite some direct uses of 'irange'
and also 'vrange' which do not have the DTOR visible but 'irange' already
exposes and uses 'maybe_resize'. I think those should only be introduced
in the class exposing the virtual DTOR (but why virtual?!).
Would be nice to have a picture of the range class hierarchies with
pointers on which types to use in which circumstances ...
For example:
Value_Range vr (parm_type);
...
irange &r = as_a <irange> (vr);
irange_bitmask bm = r.get_bitmask ();
...
should that really use 'irange'? Why not int_range&?
All the complication might be because of GC (irange is GTY but int_range is
not), but re-allocation would happen with 'new', not ggc_alloc, so ...
But yes, please try to fix IPA CP, I'll see if this pops up elsewhere as well
then.
