From patchwork Tue May 29 16:32:13 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Meador Inge X-Patchwork-Id: 161768 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 D49E1B6FBB for ; Wed, 30 May 2012 02:32:43 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1338913964; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=wnzBnXGeoG+1KoReXmBELXSpli0=; b=XBeG++LaWMwEeyj QpI5xUibxzvRpIMxf1a4sRiMsupGjoadzD5pkSEPajtV9FJXvazZowcJfSSnKYMy DvHqiGLXOqPgI8awZcaz4vcNSq5KnHIejPucGsVV+lCUiethC96vuaycNsRxLAT+ 6pgjnxky75UuX5uXwjt+tKnLuOTc= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=BlHLQ/u1t7Z+pY/W4//aCtKft4zd89q/w62nVde2rHhksZNRgiTZOmlXf5kkyn w64Gt9ytccIc3wUzMxUfYj9J3bUnpTH21lmsCnU+5CRaXE0mzevjeoJUXHQHIoWh C2ap7F2o7whMpG+1oyLQVoR0pyaKg9BXyhhNIFplwB2ZM=; Received: (qmail 17210 invoked by alias); 29 May 2012 16:32:34 -0000 Received: (qmail 17195 invoked by uid 22791); 29 May 2012 16:32:31 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL, BAYES_00, FROM_12LTRDOM, KHOP_RCVD_UNTRUST, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL, TW_TM X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 May 2012 16:32:17 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SZPLD-0007Pr-Fe from meador_inge@mentor.com ; Tue, 29 May 2012 09:32:15 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 09:31:50 -0700 Received: from [IPv6:::1] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Tue, 29 May 2012 09:32:14 -0700 Message-ID: <4FC4FA0D.4000605@codesourcery.com> Date: Tue, 29 May 2012 11:32:13 -0500 From: Meador Inge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: CC: , "Joseph S. Myers" Subject: PATCH: Always create a new language function for nested functions 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 Hi All, Last week I went to build a mips-gnu-linux toolchain and the built compiler seg faulted while building glibc. Bisecting the change pointed to r187757. The problem really goes back to r178692, which added support for -Wunused-local-typedefs. r187757 just made it easier to hit by enabling the warning more aggressively. The problem is that in r187757 the following changes were applied: @@ -8455,9 +8479,11 @@ void c_push_function_context (void) { - struct language_function *p; - p = ggc_alloc_language_function (); - cfun->language = p; + struct language_function *p = cfun->language; + /* cfun->language might have been already allocated by the use of + -Wunused-local-typedefs. In that case, just re-use it. */ + if (p == NULL) + cfun->language = p = ggc_alloc_cleared_language_function (); p->base.x_stmt_tree = c_stmt_tree; c_stmt_tree.x_cur_stmt_list @@ -8483,7 +8509,11 @@ pop_function_context (); p = cfun->language; - cfun->language = NULL; + /* When -Wunused-local-typedefs is in effect, cfun->languages is + used to store data throughout the life time of the current cfun, + So don't deallocate it. */ + if (!warn_unused_local_typedefs) + cfun->language = NULL; This causes problems with nested functions because the following scenario might happen (and did happen in the cause of building glibc for MIPS): 1. A nested function is found while compiling with -Wunused-local-typedefs. 2. c_push_function_context reuses the outer functions cfun->language instance. 3. c_push_function_context saves a reference to the current functions statement tree: p->base.x_stmt_tree = c_stmt_tree; 4. c_pop_function_context is executed after processing the nested function. Note the c_stmt_tree value is still saved per step (3). 5. The outer function continues to be parsed and upon encountering more statements the statement tree is resized. This puts the original statement tree memory back in the free pool. Therefore cfun->language->base.x_stmt_tree is pointing to free memory. 6. The memory that was previously associated with the statement tree gets allocated to something else and written. 7. finish_function is called for the outer function and the garbage collector is invoked. The garbage collector crashes trying to walk the memory associated with the x_stmt_tree field, which is now owned by something else. The attached patch fixes the problem by always allocating a new language function when going into a new function context (it reverts back to the original code). I suppose another option would be to clear all the saved fields in c_pop_function_context, but that seems like more trouble than it is worth. I wasn't able to devise a simplified reproduction case for this problem. I could only reproduce it by building glibc. The patch was tested by building mips-linux-gnu and bootstrapping and running the full test suite for i686-pc-linux-gnu. OK? P.S. If it is OK, then can someone commit for me (I don't have write access)? 2012-05-29 Meador Inge * c-decl.c (c_push_function_context): Always create a new language function. (c_pop_function_context): Clear the language function created in c_push_function_context. Index: gcc/c-decl.c =================================================================== --- gcc/c-decl.c (revision 187923) +++ gcc/c-decl.c (working copy) @@ -8579,11 +8579,9 @@ check_for_loop_decls (location_t loc, bo void c_push_function_context (void) { - struct language_function *p = cfun->language; - /* cfun->language might have been already allocated by the use of - -Wunused-local-typedefs. In that case, just re-use it. */ - if (p == NULL) - cfun->language = p = ggc_alloc_cleared_language_function (); + struct language_function *p; + p = ggc_alloc_language_function (); + cfun->language = p; p->base.x_stmt_tree = c_stmt_tree; c_stmt_tree.x_cur_stmt_list @@ -8609,11 +8607,7 @@ c_pop_function_context (void) pop_function_context (); p = cfun->language; - /* When -Wunused-local-typedefs is in effect, cfun->languages is - used to store data throughout the life time of the current cfun, - So don't deallocate it. */ - if (!warn_unused_local_typedefs) - cfun->language = NULL; + cfun->language = NULL; if (DECL_STRUCT_FUNCTION (current_function_decl) == 0 && DECL_SAVED_TREE (current_function_decl) == NULL_TREE)