This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, MIPS] Enable fp-contract on MIPS and update -mfused-madd
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro at linux-mips dot org>
- Cc: Steve Ellcey <sellcey at imgtec dot com>, Richard Sandiford <rdsandiford at googlemail dot com>, <gcc-patches at gcc dot gnu dot org>, Catherine Moore <clm at codesourcery dot com>, Matthew Fortune <matthew dot fortune at imgtec dot com>
- Date: Tue, 16 Jun 2015 12:19:09 +0000
- Subject: Re: [Patch, MIPS] Enable fp-contract on MIPS and update -mfused-madd
- Authentication-results: sourceware.org; auth=none
- References: <4c25620c-546c-40ae-b330-3652fe25f791 at BAMAIL02 dot ba dot imgtec dot org> <alpine dot DEB dot 2 dot 10 dot 1506112002380 dot 15628 at digraph dot polyomino dot org dot uk> <alpine dot LFD dot 2 dot 11 dot 1506152042580 dot 5418 at eddie dot linux-mips dot org> <alpine dot DEB dot 2 dot 10 dot 1506152047390 dot 9772 at digraph dot polyomino dot org dot uk> <alpine dot LFD dot 2 dot 11 dot 1506152215570 dot 5418 at eddie dot linux-mips dot org> <alpine dot DEB dot 2 dot 10 dot 1506152157470 dot 9772 at digraph dot polyomino dot org dot uk> <alpine dot LFD dot 2 dot 11 dot 1506161240330 dot 5418 at eddie dot linux-mips dot org>
On Tue, 16 Jun 2015, Maciej W. Rozycki wrote:
> This makes me wonder however what the point has been to specify a strict
> particular semantics for the copy, negate, abs, copySign operations with
> respect to the sign bit of qNaN data where any other operation can then
> change the bit in a random fashion. Do you happen to know what the
> rationale and any possible use cases considered have been?
I don't know.
> Furthermore these checks were deliberately introduced by Richard with his
> proposal here <http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00682.html>
> and agreed upon in the discussion even before IEEE Std 754-2008 has been
> made. Are you suggesting that the arguments used there, that have led to
> the current arrangement, no longer stand and consequently the HONOR_NANS
> checks introduced are now best dropped?
Only the checks for abs and neg patterns are necessary, not those for
fused operations.
--
Joseph S. Myers
joseph@codesourcery.com