https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |jamborm at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I guess usual problem with late warnings.
In this particular case, we have std::__insertion_sort called with __first,
__first+16
and IPA-CP decides to create a constprop version for it with the first argument
0B
but the second one passed:
Evaluating opportunities for void std::__insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = object*;
_Compare = __gnu_cxx::__ops::_I
ter_comp_iter<main()::<lambda(const auto:1&, const auto:2&)> >]/108.
- Creating a specialized node of void
std::__insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare)
[with _RandomAccessIterator = object*; _Compare = __gnu_cxx::__op
s::_Iter_comp_iter<main()::<lambda(const auto:1&, const auto:2&)> >]/108 for
all known contexts.
replacing param #0 __first with const 0B
Accounting size:6.00, time:38.09 on predicate exec:(true)
Accounting size:3.00, time:2.00 on new predicate exec:(not
inlined)
Accounting size:2.00, time:2.00 on new predicate exec:(true)
nonconst:(op1 changed)
Accounting size:3.00, time:79.53 on predicate exec:(true)
Accounting size:3.00, time:79.53 on predicate exec:(true)
Accounting size:4.00, time:43.08 on predicate exec:(true)
Accounting size:3.00, time:39.76 on predicate exec:(true)
the new node is __insertion_sort.constprop/202.
and in that case it indeed calls object::size with NULL this in that function.
Somehow this constprop function is kept in the IL but not really called by
anything once IPA passes are done.
Ideally a fix for this particular case would be not to keep clearly dead
function in the IL, but not familiar enough with reading IPA dumps to see where
the caller actually went away. Or perhaps when making constprop for
__first_5(D) being 0B when the second argument is _2 = __first_5(D) + 16 also
constprop it for the second one being 16B, then
I think cfg cleanup could just optimize it away. Or both.
