[PR69123] fix handling of MEMs in VTA to avoid dataflow oscillation

[PR69123] fix handling of MEMs in VTA to avoid dataflow oscillation

The problem arises because we used to drop overwritten MEMs from loc
lists of VALUEs, but not of other onepart variables, and it just so
happens that, by doing so, block 6 in the testcase has no D#5 in its
output in the first pass, because the MEM holding its (previous) value
was correctly dropped from value 88:88, but gains it in the second
pass because D#5 has the MEM location incoming directly in its loc
list, rather than indirectly in a VALUE.

This incorrect binding enables other blocks to believe they have a
tentative binding for D#5 in some cycles, but others, still operating
on the early conclusion, believe there isn't, and they oscillate from
that.

Since we check for escaping MEMs in clobbers, we won't lose anything
relevant by dropping call-clobbered or overwritten MEMs in all onepart
variables, and this ensures the loc intersection operation in onepart
vars won't let a MEM through that wasn't present in earlier
iterations.

for  gcc/ChangeLog

	PR bootstrap/69123
	* var-tracking.c (drop_overlapping_mem_locs): Operate on all
	onepart vars.  Fix typo in comment.  Fix reversed condition in
	unshare test.
	(dataflow_set_remove_mem_locs): Operate on all onepart vars.

for gcc/testsuite/ChangeLog

	PR bootstrap/69123
	* g++.dg/pr69123.C: New.

From-SVN: r232218