public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/109371] New: MIN_EXPR/MAX_EXPR and SMIN/SMAX trapping behavior is not documented
@ 2023-04-02 0:32 pinskia at gcc dot gnu.org
2023-06-12 4:57 ` [Bug tree-optimization/109371] MIN_EXPR/MAX_EXPR is not documented " crazylht at gmail dot com
0 siblings, 1 reply; 2+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-04-02 0:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109371
Bug ID: 109371
Summary: MIN_EXPR/MAX_EXPR and SMIN/SMAX trapping behavior is
not documented
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: documentation, internal-improvement
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
I noticed while working on phi-opt, that MIN/MAX EXPR were actually not
documented in generic.texi and even the behavior of trapping was not documented
for RTL.
There was a patch in 2019 about this:
https://inbox.sourceware.org/gcc-patches/20190822134551.18924-2-iii@linux.ibm.com/
But I am not sure where it ended up.
Note I also wrote
https://inbox.sourceware.org/gcc/CA+=Sn1keynE62f6bJ_heMfQNR_M1YOkzrqupkdQtqSWxfZ0Mew@mail.gmail.com/T/#u
asking about the behavior of trapping with respect to -ffinite-math-only too
because that is where I noticed a difference in how different parts of phi-opt
handle things even.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug tree-optimization/109371] MIN_EXPR/MAX_EXPR is not documented and SMIN/SMAX trapping behavior is not documented
2023-04-02 0:32 [Bug tree-optimization/109371] New: MIN_EXPR/MAX_EXPR and SMIN/SMAX trapping behavior is not documented pinskia at gcc dot gnu.org
@ 2023-06-12 4:57 ` crazylht at gmail dot com
0 siblings, 0 replies; 2+ messages in thread
From: crazylht at gmail dot com @ 2023-06-12 4:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109371
Hongtao.liu <crazylht at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |crazylht at gmail dot com
--- Comment #1 from Hongtao.liu <crazylht at gmail dot com> ---
NOTE for ieee-2019, there're extra 8 new floating point min/max functions
-----cut from ieee 2019 9.6 Minimum and maximum operations--
SourceFormat minimum(source, source)
sourceFormat minimumNumber(source, source)
sourceFormat maximum(source, source)
sourceFormat maximumNumber(source, source)
minimum(x, y) is x if x <y, y if y< x, and a quiet NaN if either operand is a
NaN, according to 6.2.
For this operation, −0 compares less than +0. Otherwise (i.e., when x= y and
signs are the same)
it is either x or y.
minimumNumber(x, y) is x if x< y, y if y< x, and the number if one operand is a
number and the
other is a NaN. For this operation, −0 compares less than +0. If x= y and signs
are the same it is
either x or y. If both operands are NaNs, a quiet NaN is returned, according to
6.2. If either
operand is a signaling NaN, an invalid operation exception is signaled, but
unless both operands
are NaNs, the signaling NaN is otherwise ignored and not converted to a quiet
NaN as stated in
6.2 for other operations.
maximum(x, y) is x if x> y, y if y >x, and a quiet NaN if either operand is a
NaN, according to 6.2.
For this operation, +0 compares greater than −0. Otherwise (i.e., when x= y and
signs are the
same) it is either x or y.
maximumNumber(x, y) is x if x >y, y if y >x, and the number if one operand is a
number and the
other is a NaN. For this operation, +0 compares greater than −0. If x =y and
signs are the same it
is either x or y. If both operands are NaNs, a quiet NaN is returned, according
to 6.2. If either
operand is a signaling NaN, an invalid operation exception is signaled, but
unless both operands
are NaNs, the signaling NaN is otherwise ignored and not converted to a quiet
NaN as stated in
6.2 for other operations.
69
Copyright © 2019 IEEE. All rights reserved.
Authorized licensed use limited to: Intel Corporation via the Virtual Library.
Downloaded on January 04,2023 at 06:43:47 UTC from IEEE Xplore. Restrictions
apply.IEEE Std 754-2019
IEEE Standard for Floating-Point Arithmetic
― sourceFormat minimumMagnitude(source, source)
sourceFormat minimumMagnitudeNumber(source, source)
sourceFormat maximumMagnitude(source, source)
sourceFormat maximumMagnitudeNumber(source, source)
minimumMagnitude(x, y) is x if |x|< |y|, y if |y|< |x|, otherwise minimum(x,
y).
minimumMagnitudeNumber(x, y) is x if |x|< |y|, y if |y|< |x|, otherwise
minimumNumber(x, y).
maximumMagnitude(x, y) is x if |x|> |y|, y if |y|> |x|, otherwise maximum(x,
y).
maximumMagnitudeNumber(x,y) is x if | x| >| y|, y if | y| >| x|, otherwise
maximumNumber(x, y).
The preferred exponent is Q(x) if x is the result, Q(y) if y is the result.
NOTE—The quantum of the result might differ among implementations when x and y
are
different representations of the same cohort in decimal floating-point numbers.
----------cut ends----------------------
Should we also support new IRs for them, libc has supported all of them.
https://sourceware.org/pipermail/libc-alpha/2021-September/131511.html
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-06-12 4:57 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-02 0:32 [Bug tree-optimization/109371] New: MIN_EXPR/MAX_EXPR and SMIN/SMAX trapping behavior is not documented pinskia at gcc dot gnu.org
2023-06-12 4:57 ` [Bug tree-optimization/109371] MIN_EXPR/MAX_EXPR is not documented " crazylht at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).