From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15625 invoked by alias); 19 Sep 2009 16:57:45 -0000 Received: (qmail 15533 invoked by uid 48); 19 Sep 2009 16:57:28 -0000 Date: Sat, 19 Sep 2009 16:57:00 -0000 Message-ID: <20090919165728.15532.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/40987] Wrong optimization with if-conversion In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mikpe at it dot uu dot se" 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: 2009-09/txt/msg01788.txt.bz2 ------- Comment #9 from mikpe at it dot uu dot se 2009-09-19 16:57 ------- Seems like an if-conversion bug, in particular noce_try_store_flag_constants() appears to break on HWI32 platforms when long long literals are involved. In this test case, noce_t_s_f_c() is invoked with an IF where a (the false value) and b (the true value) are both DImode CONST_INTs. a is zero. b is stored as 0x80000000, which is truncated but sign-extends to the correct value. noce_t_s_f_c() then computes a subtraction and some log2() on these truncated values, and selects the second code generation template "x = (test != 0) << 3;". The code becomes (from the ce1 dump file): (insn 27 8 28 2 pr40987.c:4 (parallel [ (set (reg:DI 62) (sign_extend:DI (reg/v:SI 60 [ arg ]))) (clobber (reg:CC 17 flags)) (clobber (scratch:SI)) ]) 90 {*extendsidi2_1} (nil)) (insn 28 27 29 2 pr40987.c:4 (parallel [ (set (reg/v:DI 58 [ val ]) (lshiftrt:DI (reg:DI 62) (const_int 63 [0x3f]))) (clobber (reg:CC 17 flags)) ]) 394 {*lshrdi3_1} (nil)) # since this is a logical downshift, it produces 0 or 1 from the sign bit (insn 29 28 17 2 pr40987.c:4 (parallel [ (set (reg/v:DI 58 [ val ]) (ashift:DI (reg/v:DI 58 [ val ]) (const_int 31 [0x1f]))) (clobber (reg:CC 17 flags)) ]) 356 {*ashldi3_1} (nil)) # which is shifted up to produce 0 or 0x80000000, the high 32 bits are lost All gcc-4.x releases have this bug. It does not trigger in gcc-3.4.6. There it seems that the true/false values are swapped compared to 4.x, and a test near the top of noce_t_s_f_c() causes it to bail out and not perform the conversion. (The test looks the same in 4.x, but the IF-operands are swapped so it does not bail.) I don't know if this code can be fixed to handle longer-than-HWI literals. The simplest solution might be to just detect the situation and bail out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40987