This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Fix PR28684
- From: Revital1 Eres <ERES at il dot ibm dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Ayal Zaks <ZAKS at il dot ibm dot com>, Dorit Nuzman <DORIT at il dot ibm dot com>, gcc-patches at gcc dot gnu dot org, Richard Guenther <rguenther at suse dot de>, "R. Clint Whaley" <whaley at cs dot utsa dot edu>
- Date: Tue, 14 Nov 2006 22:33:03 +0200
- Subject: Re: [RFC] Fix PR28684
>
> I'm a bit disappointed that neither the ATLAS folks nor yourself have
> yet articulated a strong functionality request. I appreciate that you're
> somehow unhappy with -ffast-math, but apart from the Mflops argument
> you've failed to put your finger on precisely (or exactly :-) what
> about it you believe needs fixing. Even in the Mflops argument is
> seems ambiguous whether operations of constant arguments may be evaluated
> at compile-time, "2.0 + 3.0 -> 5.0"?
>From PR27827 and PR28684 I understood that the motivation for
the new flag is to allow programmers to benefit from floating point
transformations
that do not violate IEEE but may change the results due to
rounding. The problem that started this discussion was about
a testcase that could not be vectorized on ATLAS
as -unsafe-math-optimizations should have been used.
So following this I deduced that benefit from more optimization is
preferred
on keeping the number of operators. (which is a different goal as I see it)
So the question is indeed what kind of functionality we want to use.
Again - I understood it as a subset of --unsafe-flags which not violate
IEEE
but may change the result.
But as you mentioned in your previous email I'm also pleased that we're
discussing
the issues.
Revital