From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11414 invoked by alias); 19 May 2010 19:08:11 -0000 Received: (qmail 9880 invoked by uid 48); 19 May 2010 19:07:24 -0000 Date: Wed, 19 May 2010 19:08:00 -0000 Subject: [Bug target/44201] New: ppc64 glibc miscompilation X-Bugzilla-Reason: CC Message-ID: 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: 2010-05/txt/msg02108.txt.bz2 vfscanf is miscompiled by gcc 4.4, here is a shorter testcase that is miscompiled also by 4.6: extern void *alloca (__SIZE_TYPE__); extern void bar (long *, char *); long foo (long x) { long buf[400]; char *p = alloca (x); bar (buf, p); return buf[0]; } at -O2 -m64 results in: ... bl .bar nop addi 1,31,3328 ld 3,112(31) ld 0,16(1) ld 31,-8(1) mtlr 0 blr Note that sched2 swapped incorrectly the stack frame release and ld 3,112(31), so the ld insn reads from memory location 3216 below the stack (which is much lower than 288 bytes of ppc64 red zone). If a signal comes in in between addi and ld and something clobbers the stack, this function (or, with 4.4 vfscanf) will return incorrect value. There is nothing in the epilogue stack release insn that would make it a memory barrier. -- Summary: ppc64 glibc miscompilation Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44201