From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11883 invoked by alias); 9 Feb 2009 20:17:29 -0000 Received: (qmail 11833 invoked by uid 48); 9 Feb 2009 20:17:13 -0000 Date: Mon, 09 Feb 2009 20:17:00 -0000 Message-ID: <20090209201713.11832.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/39139] [4.4 Regression] ICE with stringop and register var In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" 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-02/txt/msg00818.txt.bz2 ------- Comment #7 from jakub at gcc dot gnu dot org 2009-02-09 20:17 ------- This is different from that PR. In this case the code does nothing dangerous in the block with the register vars. For %rdi and a couple of other regs on x86-64 one could actually use "D" etc. constraints, but r8-r15 already don't have a single register class for each register, and on most of the other targets this isn't available either. So just to show that this isn't x86-64 only issue, here is a testcase for sparc64-linux: static inline int foo (unsigned int x, void *y) { register unsigned long r asm ("o0"); register unsigned long a1 asm ("g1") = a1; register unsigned long a2 asm ("g5") = a2; a1 = (unsigned long) x; a2 = (unsigned long) y; asm volatile ("# %0 %1 %2" : "=r" (r), "+r" (a1), "+r" (a2) : : "memory"); return (int) r; } struct T { unsigned long t1, t2; unsigned int t3, t4, t5; }; int bar (unsigned long x, unsigned int y, unsigned long u, unsigned int v) { long r; struct T e = { .t1 = x, .t2 = u }; if (x << y != u << v) return 5; r = foo (11, &e); return e.t3 == x; } compile with -Os -m64 and -Os -m64 -fno-tree-sink. See in the latter: add %fp, 2015, %l0 mov 0, %o1 mov %l0, %o0 call memset, 0 mov 32, %o2 ... mov %l0, %g5 mov 11, %g1 #APP ! 9 "pr39139.c" 1 # %o0 %g1 %g5 #NO_APP I.e. it would work just fine, both are initialized to the expected value. With sinking we have: save %sp, -208, %sp sllx %i0, %i1, %i1 sllx %i2, %i3, %i3 cmp %i1, %i3 bne,pt %xcc, .LL3 mov 5, %g1 add %fp, 2015, %o0 mov 0, %o1 call memset, 0 mov 32, %o2 stx %i2, [%fp+2023] stx %i0, [%fp+2015] #APP ! 9 "mm.c" 1 # %o0 %g1 %g5 #NO_APP where neither g1 nor g5 are initialized at all (they were initialized during expand, but before the memset call, and as both g1 and g5 are call clobbered their value would (or could) be corrupted during the call anyway). I'd say easiest fix would be for tree-ssa-sink.c to punt sinking = {} if there are any DECL_HARD_REGISTER vars in the function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39139