[RFC] Fix PR28684

[Revital1 Eres]

Hello,

Following Clint‘s recent notes, I returned to the former definition
of the flag (if no one objects) and tried to clarify the
documentation  -

-fassociative-math:
Allow optimization for floating-point arithmetic which are IEEE
compliant but may not follow language standards by reordering
the operations and/or commuting operands.
This means that the result may be changed due to rounding issues.
For example; in transforming (a + b) + c to a + (b + c) the intermediate
calculations still follow IEEE standard but the result could be different
due to rounding which also make the final result different.
This flag intended for applications that need to be IEEE compliant
and would like to benefit from some transformations at the price of
loss of accuracy. Among the transformations that are enabled by this
flag are vectorization, mve and re-association.
An example of a transformation which is not allowed by this flag is
transforming x * 0 to 0 as the result is not IEEE compliant when x
is Inf.
NOTE: may reorder or strength reduce floating-point comparisons as
well, and so may not be used when ordered comparisons are required.

I thought that because reciprocal transformations involves division
it may be separated from -fassociative-math:

-freciprocal-math:
Same as -fassociative-math for expressions which include division.
For example x / y can be replaced with x * (1/y)
which is useful if (1/y) is subject to common subexpression
elimination.

By this definition a*(b/c) -> (a*b)/c should be applied with
-freciprocal-math flag
as it involves division.

It seems that -fassociative-math does not honor signed zero for different
rounding modes, is that o.k. ?

Comments are welcome.
Revital