> Note that vect_determine_vectorization_factor is supposed to set the > vector type on all > stmts. That it doesn't is a bug. Do you run into the else branch?
Yes, for result_15 = _6 & result_3; wich is a BIT_AND_EXPR, hence accepted by vectorizable_reduction. > I think that should only trigger with STMT_VINFO_RELEVANT_P and thus the > stmt in mask_producers which should later get post-processed and have the > VECTYPE set. OK, STMT_VINFO_RELEVANT_P is indeed not set: (gdb) p *stmt_info $4 = {type = undef_vec_info_type, live = true, in_pattern_p = false, stmt = 0x7ffff68f5738, vinfo = 0x2e14820, vectype = 0x0, vectorized_stmt = 0x0, data_ref_info = 0x0, dr_base_address = 0x0, dr_init = 0x0, dr_offset = 0x0, dr_step = 0x0, dr_aligned_to = 0x0, loop_phi_evolution_base_unchanged = 0x0, loop_phi_evolution_part = 0x0, related_stmt = 0x0, pattern_def_seq = 0x0, same_align_refs = {m_vec = 0x0}, simd_clone_info = {m_vec = 0x0}, def_type = vect_reduction_def, slp_type = loop_vect, first_element = 0x0, next_element = 0x0, same_dr_stmt = 0x0, size = 0, store_count = 0, gap = 0, min_neg_dist = 0, relevant = vect_unused_in_scope, vectorizable = true, gather_scatter_p = false, strided_p = false, simd_lane_access_p = false, v_reduc_type = TREE_CODE_REDUCTION, num_slp_uses = 0} -- Eric Botcazou