[Bug tree-optimization/126475] [13/14/15/16/17 Regression] x * { 0.0f, 1.0f, ... } must not become x & mask when NaNs/Infs are honoured

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126475

Drea Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2026-07-29
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=88598
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Drea Pinski <pinskia at gcc dot gnu.org> ---
The vector pattern is:
```
/* Transform x * { 0 or 1, 0 or 1, ... } into x & { 0 or -1, 0 or -1, ...},
   unless the target has native support for the former but not the latter.  */
(simplify
 (mult @0 VECTOR_CST@1)
 (if (initializer_each_zero_or_onep (@1)
      && !HONOR_SNANS (type)
      && !HONOR_SIGNED_ZEROS (type))
  (with { tree itype = FLOAT_TYPE_P (type) ? unsigned_type_for (type) : type; }
   (if (itype
        && (!VECTOR_MODE_P (TYPE_MODE (type))
            || (VECTOR_MODE_P (TYPE_MODE (itype))
                && optab_handler (and_optab,
                                  TYPE_MODE (itype)) != CODE_FOR_nothing)))
    (view_convert (bit_and:itype (view_convert @0)
                                 (ne @1 { build_zero_cst (type); })))))))
```

While the scalar pattern is this (and is correct):
```
/* Maybe fold x * 0 to 0.  The expressions aren't the same
   when x is NaN, since x * 0 is also NaN.  Nor are they the
   same in modes with signed zeros, since multiplying a
   negative value by 0 gives -0, not +0.  Nor when x is +-Inf,
   since x * 0 is NaN.  */
(simplify
 (mult @0 real_zerop@1)
 (if (!tree_expr_maybe_nan_p (@0)
      && (!HONOR_NANS (type) || !tree_expr_maybe_infinite_p (@0))
      && (!HONOR_SIGNED_ZEROS (type) || tree_expr_nonnegative_p (@0)))
  @1))
```


So r9-5228-g46c66a46aa3307.