From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8782 invoked by alias); 21 Feb 2015 12:47:33 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 8727 invoked by uid 48); 21 Feb 2015 12:47:29 -0000 From: "vries at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/30957] Misscompare with variable expansion optimization Date: Sat, 21 Feb 2015 13:28:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg02372.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957 vries at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |WAITING CC| |vries at gcc dot gnu.org Resolution|FIXED |--- --- Comment #22 from vries at gcc dot gnu.org --- (In reply to mrs@gcc.gnu.org from comment #21) > So, is there anything left as a bug in the compiler, or has this issue been > fixed? The compiler behaves in accordance with the semantics of the switches passed. In that sense, there's no bug. The code committed for this PR (using -0.0 instead of +0.0) in insert_var_expansion_initialization currently looks like this: ... if (honor_signed_zero_p) zero_init = simplify_gen_unary (NEG, mode, CONST0_RTX (mode), mode); else zero_init = CONST0_RTX (mode); ... AFAIU, this has become dead code, because -fsigned-zeros cannot be true at the same time as -fassociative-math. The definition of -fno-signed-zeros is 'Allow optimizations for floating-point arithmetic that ignore the signedness of zero'. So stricly speaking, if the cost of -0.0 is the same as of +0.0, there's nothing that stops us from using -0.0 here for -fno-signed-zeros (attempting to be a bit 'more' correct at zero cost). My feeling is that this is not a good idea, but obviously others may think otherwise. If we decide that we want to implement this, we should reopen this bug. If we decide otherwise, we should mark this wontfix. Re-opening this as waiting for appropriate maintainer(s) to make a decision on this.