[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Martin Jambor changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #8 from Martin Jambor --- (In reply to Jakub Jelinek from comment #6) > Somehow this constprop function is kept in the IL but not really called by > anything once IPA passes are done. This is discovered only when performing inlining on GIMPLE bodies, I guess during folding of the conditions. At this point, with LTO, the constprop functions could theoretically be in another partition so generally it is too late to remove them as unreachable. (In reply to Jakub Jelinek from comment #7) > Or perhaps when considering the constprop see that for __first_5(D) being 0B > there would be pointer arithmetics on NULL (the __first_5(D) p+ 16) and so > would invoke UB or likely invoke UB and so not worth constant propagation. Only when unguarded. Being able to eliminate these when they are guarded by a NULL check is something that IPA-CP should do. And NULL checks can be non-obvious at IPA time, in this case this is essentially done by the check that if (__first_4(D) != __last_5(D)) where we manage to prove that __first is zero but __last can be either zero or zero pointer_plus 16 and therefore we fail to propagate (for all contexts). I'm afraid I don't have any good ideas that might not lead to adverse effects in other situations. Perhaps we could specifically track such comparisons in a bitmap and then do some "likely invalid pointer" propagation for pointer arithmetics and then avoid cloning for zero value in presence of such comparisons...
[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 --- Comment #7 from Jakub Jelinek --- Or perhaps when considering the constprop see that for __first_5(D) being 0B there would be pointer arithmetics on NULL (the __first_5(D) p+ 16) and so would invoke UB or likely invoke UB and so not worth constant propagation.
[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- 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 >]/108. - Creating a specialized node of void std::__insertion_sort(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = object*; _Compare = __gnu_cxx::__op s::_Iter_comp_iter >]/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.
[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Richard Biener changed: What|Removed |Added Blocks||95507 Target Milestone|--- |11.4 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 [Bug 95507] [meta-bug] bogus/missing -Wnonnull
[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Jonathan Wakely changed: What|Removed |Added CC||msebor at gcc dot gnu.org Summary|std::sort of empty range|[11/12/13 Regression] |yield "warning: 'this' |std::sort of empty range |pointer is null"|yield "warning: 'this' ||pointer is null" Known to fail||11.1.0 Known to work||10.4.0 --- Comment #5 from Jonathan Wakely --- The warning started with r11-1697: Underline argument in -Wnonnull and in C++ extend warning to the this pointer [PR c++/86568]. Resolves: PR c++/86568 - -Wnonnull warnings should highlight the relevant argument not the closing parenthesis
