From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25098 invoked by alias); 5 Jul 2005 14:40:17 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 25070 invoked by uid 48); 5 Jul 2005 14:40:11 -0000 Date: Tue, 05 Jul 2005 14:40:00 -0000 Message-ID: <20050705144011.25068.qmail@sourceware.org> From: "para at cfl dot rr dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050608225942.21970.para@cfl.rr.com> References: <20050608225942.21970.para@cfl.rr.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug rtl-optimization/21970] [3.4 only] Inline keyword causes computation to erroneously reduce to a constant X-Bugzilla-Reason: CC X-SW-Source: 2005-07/txt/msg00429.txt.bz2 List-Id: ------- Additional Comments From para at cfl dot rr dot com 2005-07-05 14:40 ------- The analysis is slightly flawed. For example: UINT32 r0045025C = opt_and(ic, r004501D4); // N = and (_, M) :00022108 UINT32 r00450994 = opt_not(r0045025C); // b = not (N) :fffddef7 Since you are using 1s to represent bits that are known to be 0 and 0s to represent bits whose value are completely unknown, b should be 00000000. All known 0s flip to 1s, and you can say nothing about the other bits because their values are all unknown. However, I ran my own analysis and came to the same conclusion. It seems that the mistake was mine as I was using and (&) instead of add (+) for the round key. My appologies. Interestingly, GCC 4.0 does *not* catch this optimization opportunity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21970