From patchwork Sat Oct 9 01:10:09 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nathan Froyd X-Patchwork-Id: 67311 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 1DCF21007D2 for ; Sat, 9 Oct 2010 12:10:23 +1100 (EST) Received: (qmail 5644 invoked by alias); 9 Oct 2010 01:10:20 -0000 Received: (qmail 5634 invoked by uid 22791); 9 Oct 2010 01:10:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 09 Oct 2010 01:10:13 +0000 Received: (qmail 10319 invoked from network); 9 Oct 2010 01:10:11 -0000 Received: from unknown (HELO codesourcery.com) (froydnj@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Oct 2010 01:10:11 -0000 Date: Fri, 8 Oct 2010 21:10:09 -0400 From: Nathan Froyd To: gcc-patches@gcc.gnu.org Cc: julian@codesourcery.com Subject: [PATCH] fix newly-introduced buglet in tree-ssa-sccvn.c Message-ID: <20101009011006.GT17388@nightcrawler> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org My recent cleanup of tree-ssa-sccvn.c added a bug along the way. Prior to my patch, inserting a VN by pieces did: if (length >= 1) vno1->op[0] = op0; if (length >= 2) vno1->op[1] = op1; if (length >= 3) vno1->op[2] = op2; if (length >= 4) vno1->op[3] = op3; and looking up a VN by pieces did: vno1.op[0] = op0; vno1.op[1] = op1; vno1.op[2] = op2; vno1.op[3] = op3; and I unified these by using the second snippet of code. As you might have guessed, this change is not correct. When we're inserting a VN by pieces, we allocate a vn_nary_opt structure for a specific number of operands. If we use the second form, then we scribble over memory beyond the end of our allocation, causing havoc. (The specific case Julian noticed was overwriting libc's data structures for obstacks when doing a cross to arm-none-linux-gnueabi and compiling glibc...I am surprised this memory corruption was not discovered earlier.) The patch below fixes this by using a variant of the first snippet above. I think this is correct even for looking up a VN, since we'll only ever iterate over vno->length operands when computing the hash for the VN. Bootstrapped on x86_64-unknown-linux-gnu and verifying that the patch fixes compiling glibc for arm-none-linux-gnueabi. OK to commit? -Nathan * tree-ssa-sccvn.c (init_vn_nary_op_from_pieces): Consult length before initializing vno->op. Index: ChangeLog =================================================================== Index: tree-ssa-sccvn.c =================================================================== --- tree-ssa-sccvn.c (revision 165212) +++ tree-ssa-sccvn.c (working copy) @@ -1708,10 +1708,15 @@ init_vn_nary_op_from_pieces (vn_nary_op_ vno->opcode = code; vno->length = length; vno->type = type; - vno->op[0] = op0; - vno->op[1] = op1; - vno->op[2] = op2; - vno->op[3] = op3; + switch (length) + { + case 4: vno->op[3] = op3; + case 3: vno->op[2] = op2; + case 2: vno->op[1] = op1; + case 1: vno->op[0] = op0; + default: + break; + } } /* Initialize VNO from OP. */