On Mon, Feb 12 2024, Jan Hubicka wrote: >> Hi, >> >> In PR 113476 we have discovered that ipcp_param_lattices is no longer >> a POD and should be destructed. This patch does that, calling >> destructor on each element of the array containing them when the >> corresponding summary of a node is freed. An alternative would be to >> change the XCNEWVEC-and-placement-new to initializations in >> constructors of all things in ipcp_param_lattices and then simply use >> normal operators new and delete. I am not sure, the initialization >> through XCNEWVEC may be a bit more efficient although that is probably >> not a big concern. In the end, I opted for a simpler solution for >> stage 4. >> >> I have verified that valgrind no longer reports lost memory blocks >> allocated within ipcp_vr_lattice::meet_with_1 on the preprocessed source >> (dwarf2out.i) attached to Bugzilla. The patch also passes bootstrap and >> LTO bootstrap and testing on x86_64-linux. >> >> OK for master? >> >> Thanks, >> >> Martin >> >> >> gcc/ChangeLog: >> >> 2024-02-09 Martin Jambor <mjam...@suse.cz> >> >> PR tree-optimization/113476 >> * ipa-prop.h (ipa_node_params::~ipa_node_params): Moved... >> * ipa-cp.cc (ipa_node_params::~ipa_node_params): ...here. Added >> destruction of lattices. > > OK. > So you do not use vectors (which would also handle the destruction) > basically to save space needed to keep the > size of the vector since that is known from the parameter count? >
Believe it or not, even though I have re-worked the internals of the lattices completely, the array itself is older than my involvement with GCC (or at least with ipa-cp.c ;-). So it being an array and not a vector is historical coincidence, as far as I am concerned :-). But that may be the reason, or because vector macros at that time looked scary, or perhaps the initialization by XCNEWVEC zeroing everything out was considered attractive (I kind of like that but constructors would probably be cleaner), I don't know. Martin
