https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> --- Created attachment 52564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52564&action=edit possible patch Perhaps better would be to not try to propagate NULL-ness. _1 = this_10(D)->d; _2 = &_1->m_mutex; if (_2 != 0B) goto <bb 5>; [90.00%] else goto <bb 3>; [10.00%] 2->5 (T) _1 : struct QFutureInterfaceBasePrivate * [1B, +INF] 2->5 (T) _2 : struct QMutex * [1B, +INF] 2->3 (F) _2 : struct QMutex * [0B, 0B] ON the edge 2->3 where _2 is 0, while it is also true that _1 must be 0, perhaps that doesn't buy us much? and may lead is down the UB path of differing expectations. We certainly would like to preserve knowing non-null, so instead of calling operator_addr_expr::fold_range, we could do the same actions, just not deal with the NULL side, thus sidestepping issues that arise with this whacky behaviour? So if the _2 is non-null, _1 is nonnull. OTherwie we claim to know nothing of _1.. The attached patch does just that, for what its owrth.
