https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
--- Comment #6 from Robin Dapp <rdapp at gcc dot gnu.org> --- Created attachment 55902 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55902&action=edit Tentative You're referring to the case where we have init = -0.0, the condition is false and we end up wrongly doing -0.0 + 0.0 = 0.0? I suppose -0.0 the proper neutral element for PLUS (and WIDEN_SUM?) when honoring signed zeros? And 0.0 for MINUS? Doesn't that also depend on the rounding mode? neutral_op_for_reduction could return a -0 for PLUS if we honor it for that type. Or is that too intrusive? Guess I should add a test case for that as well. Another thing is that swapping operands is not as easy with COND_ADD because the addition would be in the else. I'd punt for that case for now. Next problem - might be a mistake on my side. For avx512 we create a COND_ADD but the respective MASK_FOLD_LEFT_PLUS is not available, causing us to create numerous vec_extracts as fallback that increase the cost until we don't vectorize anymore. Therefore I added a vectorized_internal_fn_supported_p (IFN_FOLD_LEFT_PLUS, TREE_TYPE (lhs)). SLP paths and ncopies != 1 are excluded as well. Not really happy with how the patch looks now but at least the testsuites on aarch and x86 pass.
