cfgcleanup: Protect latches always [PR123417]

So it turns out LOOPS_MAY_HAVE_MULTIPLE_LATCHES is set in places
along compiling. Setting it only means there might be multiple
latches currently. It does not mean let's go in an delete them
all; which is what remove_forwarder_block does currently. This
was happening before my set of patches too but since it was
only happening in merge_phi pass, latches were not cleared away
al of the time and then recreated.

This solves the problem by protecting latches all of the time
instead of depedent on LOOPS_MAY_HAVE_MULTIPLE_LATCHES not being set.

vect-uncounted_7.c needs to be xfailed here because we no longer
vectorize the code. Note the IR between GCC 15 and after this patch
is the same so I think this was just a case were the testcase
was added after the remove forwarder changes and should not have
vectorized (or vectorize differently).

Bootstrapped and tested on x86_64-linux-gnu.

	PR tree-optimization/123417
gcc/ChangeLog:

	* tree-cfgcleanup.cc (maybe_remove_forwarder_block): Always
	protect latches.

gcc/testsuite/ChangeLog:

	* gcc.dg/vect/vect-uncounted_7.c: xfail vect test.

Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>

gcc/testsuite/gcc.dg/vect/vect-uncounted_7.c

@@ -20,5 +20,5 @@ void foo(int i, char *p, char *q)
   }
 }
 
-/* { dg-final { scan-tree-dump "Loop being analyzed as uncounted." "vect" } } */
-/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" } } */
+/* { dg-final { scan-tree-dump "Loop being analyzed as uncounted." "vect"  } } */
+/* { dg-final { scan-tree-dump "vectorized 1 loops in function" "vect" { xfail *-*-* } } } */

gcc/tree-cfgcleanup.cc

@@ -629,10 +629,8 @@ maybe_remove_forwarder_block (basic_block bb, bool can_split = false)
 		return false;
 	      /* If bb doesn't have a single predecessor we'd make this
 		 loop have multiple latches.  Don't do that if that
-		 would in turn require disambiguating them.  */
-	      if (!single_pred_p (bb)
-		      && !loops_state_satisfies_p
-			   (LOOPS_MAY_HAVE_MULTIPLE_LATCHES))
+		 would in turn require disambiguating them over again.  */
+	      if (!single_pred_p (bb))
 		return false;
 	    }
 	  /* cleanup_tree_cfg_noloop just created the loop preheader, don't