https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118269
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rguenther at suse dot de |tnfchris at gcc dot gnu.org Priority|P3 |P1 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- Mine then (and confirmed). It's odd we have only a single initial value but two SLP lanes ... ah, this is a SLP reduction chain - for that the adjustment def should be OK. But in vect_create_epilog_for_reduction we fail to classify it this way because we look at REDUC_GROUP_FIRST_ELEMENT of the PHI info when called via if (LOOP_VINFO_EARLY_BREAKS (loop_vinfo)) { slp_tree phis_node = slp_node ? slp_node_instance->reduc_phis : NULL; for (auto exit : get_loop_exit_edges (LOOP_VINFO_LOOP (loop_vinfo))) if (exit != LOOP_VINFO_IV_EXIT (loop_vinfo)) { vect_create_epilog_for_reduction (loop_vinfo, reduc_info, phis_node, slp_node_instance, exit); the issue is we do want to have the reduction PHI def values here, but I'm not sure we support this case? Most definitely the !slp_reduc case (reduction chain) with early breaks look broken, possibly not having great coverage. Possibly exposed by r14-9335-g89c443a7e9a078. I have a fix.