This is the mail archive of the
mailing list for the GCC project.
Re: Patch gcc-4.0 should not apply mathematical associative rules for addition or multiplication
On Oct 5, 2004, at 2:46 PM, Geoff Keating wrote:
OK. I am not going to re-design Fariborz's patch for him in an e-mail
exchange. It is clear that the explanation of the patch is inadequate
to determine whether or not the patch is correct, so the patch is
rejected. Fariborz, please re-post the patch with a better
explanation, and addressing the other points I mentioned.
I have a new patch description which, I hope, addresses Geoff's
questions. Also, I have attached a dejagnu-style
- fariborz (firstname.lastname@example.org)
Abstract: In the following code the repeated multiplication is folded
into a single
operation (multiplication by Infinity), when compiled for
For different values of "x" this leads to undeserved or absent floating
exceptions, and breaks some of the elementary math functions in Libm.
at optimization O1 and higher.
/* test */
static const double C = 0x1.0p1023;
double foo(double x)
return ( ( (x * C) * C ) * C );
Section 220.127.116.11 Program execution of the Programming languages C
13 EXAMPLE 5 Rearrangement for floating-point expressions is often
restricted because of limitations
in precision as well as range. The implementation cannot generally
apply the mathematical associative
rules for addition or multiplication, nor the distributive rule,
because of roundoff error, even
in the absence of overflowand underflow. Likewise, implementations
cannot generally replace decimal
constants in order to rearrange expressions. In the following fragment,
rearrangements suggested by
mathematical rules for real numbers are often not valid (see F.8).
double x, y, z;
//not equivalent to
So, such optimization cannot take place under general optimization
Question remains, under which flag should we place this specific unsafe
There has been three suggestions, I will address each, one by one.
1. Do this optimization when flag_trapping_math is 0 (default is 1).
"Zero means that floating-point math operations cannot generate a
(user-visible) trap". This includes overflow, underflow. This certainly
can be the flag to check for. But such an optimization may cause finite
results which could be incorrect without causing a trap, for example,
a roundoff error.
2. Do this optimization when flag_finite_math_only is 1 (default is 0).
"Allow optimizations for floating-point arithmetic that assume that
arguments and results are not NaNs or +-Infs". Again, result of such
an optimization can be finite but wrong.
"Allow optimizations for floating-point arithmetic that (a) assume
that arguments and results are valid and (b) may violate IEEE or
Such an optimization is in violation of Section 18.104.22.168 of ANSI
as noted in above.
Above flag has been used for the following case, among others:
from negate_expr_p(tree) in fold-const.c
if (FLOAT_TYPE_P (type) && !flag_unsafe_math_optimizations)
/* -(A + B) -> (-B) - A. */
/* -(A + B) -> (-A) - B. */
So, it seems that flag_unsafe_math_optimizations has been used in
other situations to disallow certain optimizations which are in
violation of ANSI
standards. This is the flag that I check for in my patch.
2004-10-05 Fariborz Jahanian <email@example.com>
* tree-ssa-dom.c (associative_fp_binop): New function.
(simplify_rhs_and_lookup_avail_expr): Disallow associativity
and constant folding of floating point MULT_EXPR/PLUS_EXPR
Description: Text document
Description: Text document