From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15806 invoked by alias); 27 Jun 2011 18:40:48 -0000 Received: (qmail 15682 invoked by uid 22791); 27 Jun 2011 18:40:46 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Jun 2011 18:40:32 +0000 From: "acarmeli at mathworks dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/49543] Cast move causes incorrect code and numerical results X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: acarmeli at mathworks dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 27 Jun 2011 18:40:00 -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 X-SW-Source: 2011-06/txt/msg02636.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49543 --- Comment #3 from Alexander Carmeli 2011-06-27 18:40:25 UTC --- Andrew, You are correct about the standard not defining the result. Similar behavior was fixed before (see bug 36300 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300) I think this is still a bug, for 3 reasons: 1. the standard also defines the subtraction operation and its result to be 32-bit. The compiler is not free to up-cast it prematurely to a bigger size for optimization purposes. This was the same in 36300. 2. Relying on overflow behavior of 2's complement machines is extremely popular. Having the same expression behave differently in folded and unfolded expressions can lead to many unexpected behaviors. In addition: 2.1. Unoptimized code misbehaves, optimized code is well behaved - this is unexpected. 2.2. The C++ compiler does generate the expected numerical behavior under all conditions, without -fwrapv. 3. In my opinion, -pedantic should not affect compiler semantics. It should only control warning messages (correct me if I got this wrong). As for the result being undefined (value, not size), the standard primarily keeps the options open for non-2's complement machines and machines with non-traditional logic.