On 12/20/2016 05:14 AM, James Greenhalgh wrote:
On Tue, Dec 20, 2016 at 11:48:26AM +0100, Richard Biener wrote:
On Mon, Dec 19, 2016 at 6:58 PM, James Greenhalgh
<james.greenha...@arm.com> wrote:
On Thu, Dec 8, 2016 at 10:44 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
Hello!
Attached patch fixes fall-out from excess-precision improvements
patch. As shown in the PR, the code throughout the compiler assumes
FLAG_PRECISION_FAST when flag_unsafe_math_optimizations flag is in
effect. The patch puts back two lines, removed by excess-precision
improvements patch.
2016-12-08 Uros Bizjak <ubiz...@gmail.com>
PR middle-end/78738
* toplev.c (init_excess_precision): Initialize flag_excess_precision
to EXCESS_PRECISION_FAST for flag_unsafe_math_optimizations.
testsuite/ChangeLog:
2016-12-08 Uros Bizjak <ubiz...@gmail.com>
PR middle-end/78738
* gcc.target/i386/pr78738.c: New test.
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
OK for mainline?
Hmm, I think it belongs to set_unsafe_math_optimization_flags instead
(and be consistent if -fexcess-precision was manually specified).
I think it would be better if this were implied by -ffast-math/-Ofast
than by -funsafe-math-optimizations . That's what I've implemented here,
and tagged the option as SetByCombined to allow us to honour what the
user requests.
This should give us the behaviour you were looking for Uros.
I've bootstrapped and tested the behaviour on x86_64, and I've hacked up
the AArch64 backend to validate that we're setting the flag in the right
circumstances (but that meant changing the AArch64 behaviour, so isn't
something we'd want on trunk, and therefore I can't write a testcase for
this patch).
OK?
Looks good to me, but please also adjust invoke.texi to list -fexcess-precision
as affected by -ffast-math.
Ok with that change.
Thanks, I've modified the affected portions of the documentation.
As I've made a few mistakes in this area recently, I'll hold off on
committing the patch until these documentation changes have been looked
at by Sandra.
OK?
I only have one tiny nit, in this snippet:
semantics apply without excess precision, and in the latter, rounding
is unpredictable.
+
@item -ffast-math
@opindex ffast-math
Sets the options @option{-fno-math-errno},
@option{-funsafe-math-optimizations},
Please don't introduce unnecessary whitespace changes, or mix them with
changes to technical content. The doc parts are OK with that repaired.
-Sandra
