https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Petr from comment #3)
> Maybe marking it as confirmed would be appropriate then?
>
> I think as a workaround it would be better to not constant fold code that
> GCC cannot compute properly - that would mean properly calculating the
> values at runtime. I have no idea what else this would impact though.
GCC clearly doesn't constant fold that at all on GENERIC or GIMPLE (I think
that really should be fixed if we keep the builtin), nothing in
i386-builtins.cc mentions any of the *{MIN,MAX}{S,P}{S,D}* builtins.
It is constant folded on RTL (in this particular case in cse1).
The problem is that those builtins are expanded into RTL using SMIN/SMAX RTL
codes, and those are documented to be undefined in that case:
"Represents the smaller (for @code{smin}) or larger (for @code{smax}) of
@var{x} and @var{y}, interpreted as signed values in mode @var{m}.
When used with floating point, if both operands are zeros, or if either
operand is @code{NaN}, then it is unspecified which of the two operands
is returned as the result."
That matches the behavior of MIN_EXPR/MAX_EXPR:
"Minimum and maximum values. When used with floating point, if both
operands are zeros, or if either operand is NaN, then it is unspecified
which of the two operands is returned as the result."
So, it is fine to expand MIN_EXPR/MAX_EXPR using SMIN/SMAX (and use
vminss/vmaxss in this case), it is fine to expand the builtins using the same
for -ffast-math (if signed zeros and nans aren't allowed), but otherwise it
needs to use (if_then_else in the RTL)
- even with the same insn.
