From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30088 invoked by alias); 18 Jul 2010 17:21:49 -0000 Received: (qmail 30047 invoked by uid 48); 18 Jul 2010 17:21:36 -0000 Date: Sun, 18 Jul 2010 17:21:00 -0000 Message-ID: <20100718172136.30046.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "steven 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: 2010-07/txt/msg01841.txt.bz2 ------- Comment #5 from steven at gcc dot gnu dot org 2010-07-18 17:21 ------- It looks like a store is scheduled wrong. Slightly reduced test case: ---------------------- 8< --------------------#define vector __attribute__((vector_size(16) )) vector int f1(vector int t, int a) { ((int*)&t)[1] = a; return t; } int main(void) { vector int a = {0, 0, 0, 0}; vector int c = {0, 1, 0, 0}; vector int a0; a0 = f1(a, 1); if (memcmp (&a0, &c, sizeof(a0))) __builtin_abort (); return 0; } ---------------------- 8< -------------------- Compiled at "-O2 -fno-inline -fpic" this will abort. The assembler output for f1 is this: 6 .global f1# 7 .type f1#, @function 8 .proc f1# 9 f1: 10 .prologue 11 .body 12 .mmi 13 mov r15 = r12 14 nop 0 15 mov r14 = r12 16 ;; 17 .mmi 18 st8 [r15] = r32, 8 19 ;; 20 st8 [r15] = r33, -4 21 nop 0 22 .mii 23 ld8 r8 = [r14], 8 24 nop 0 25 ;; 26 nop 0 27 .mmb 28 ld8 r9 = [r14] 29 st4 [r15] = r34 30 br.ret.sptk.many b0 31 .endp f1# The store on line 29 looked suspicious because the three stores (lines 18, 20, and 29) are together in the unscheduled version (i.e. with -fno-schedule-insns2, lines 15, 17, and 19): 6 .global f1# 7 .type f1#, @function 8 .proc f1# 9 f1: 10 .prologue 11 .body 12 mov r15 = r12 13 mov r14 = r12 14 ;; 15 st8 [r15] = r32, 8 16 ;; 17 st8 [r15] = r33, -4 18 ;; 19 st4 [r15] = r34 20 ld8 r8 = [r14], 8 21 ;; 22 ld8 r9 = [r14] 23 br.ret.sptk.many b0 24 ;; 25 .endp f1# The abort goes away if I hack the assembly manually with an extra bundle to move the three stores back together: .global f1# .global f1# .type f1#, @function .type f1#, @function .proc f1# .proc f1# f1: f1: .prologue .prologue .body .body .mmi .mmi mov r15 = r12 mov r15 = r12 nop 0 nop 0 mov r14 = r12 mov r14 = r12 ;; ;; .mmi .mmi st8 [r15] = r32, 8 st8 [r15] = r32, 8 ;; ;; st8 [r15] = r33, -4 st8 [r15] = r33, -4 nop 0 nop 0 > ;; > .mii > st4 [r15] = r34 > nop 0 > nop 0 .mii .mii ld8 r8 = [r14], 8 ld8 r8 = [r14], 8 nop 0 nop 0 ;; ;; nop 0 nop 0 .mmb .mmb ld8 r9 = [r14] ld8 r9 = [r14] st4 [r15] = r34 | nop 0 br.ret.sptk.many b0 br.ret.sptk.many b0 .endp f1# .endp f1# I am not an ia64 expert, but I see no reason why moving the store is a bad idea. Will have to look at the RTL, and if that doesn't help I'll leave this to a target specialist. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494