From patchwork Sun Nov 27 00:52:51 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Sebor X-Patchwork-Id: 84319 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp621647qgi; Sat, 26 Nov 2016 16:53:14 -0800 (PST) X-Received: by 10.99.131.67 with SMTP id h64mr26818407pge.135.1480207994875; Sat, 26 Nov 2016 16:53:14 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id g1si22430849pgc.92.2016.11.26.16.53.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Nov 2016 16:53:14 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-442721-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org; spf=pass (google.com: domain of gcc-patches-return-442721-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-442721-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE dis=NONE) header.from=gmail.com DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=vx1CgE1ocMeyVtDPn ibS+RAqA5Za3EsuUs8PLTRvo9OO2iK1OW6KuN0VDZ5IZSnDZ3r7d3ztUpoSClAdA JHeP0oyX5eVcYPOJLgWckkb4n78a25pXIUUrTonyVkhT1VdexqMOtG+ziUd1PULa sGZRg/AW2/W1JdOdhsc6pTnfCM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=nLdBURmys/BNOzEBptbGMOP YRMo=; b=lztvjWB+FWXs0POZX1HrQLD4my123Im/CMpHGvgb4TZ8rnqozR6ObDs e2i1SswXOPZFCzYuiDGYO5mLi8f328KvZW25e8OZREQwjz2ND6XSamDLF6gzqfFg pQO7rIEAr+u8qaMZNCbaq8HDSD5TWmrxBVm9l+R1E0WvPOJa7Z+8= Received: (qmail 127499 invoked by alias); 27 Nov 2016 00:52:57 -0000 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 Received: (qmail 126425 invoked by uid 89); 27 Nov 2016 00:52:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=xnewvec, XNEWVEC, gccinterface, gcc-interface X-HELO: mail-qk0-f196.google.com Received: from mail-qk0-f196.google.com (HELO mail-qk0-f196.google.com) (209.85.220.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 27 Nov 2016 00:52:55 +0000 Received: by mail-qk0-f196.google.com with SMTP id h201so9163834qke.3 for ; Sat, 26 Nov 2016 16:52:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=U8IxzBA6pKQvOoDYCzR5RGUOhkm3AfpBat8XTXkorzM=; b=UB4AdYnT1mkA7C6+HN0MxkO2ibC7QSCtkxehjbsFY3E/OUC2VWS9dqrVxAkIpuGdEP 5KYixfktaTttrIWpZ3rgxoNlCGFcmO3ym4ze+tCn4O6v7tpDZtqNa49jb0YadUM4h9Kd OC977VxF8HylWZPOITHxL3egpl2i0pdAkHxqPX8rEDEZA4B+MP7LvFV52s3a7K3UeFWr +418JU9CEIxdbUeNJnJbpvoX0vvZ4auiRlYrFIlo/XfdFFHgALJgAut9BalQHFNrrQFe v2yHZYf976bEm+3q9d7kxZZAuYSmoJ079hl0/EKy1xbiRdw0M38V4rPjRduS/Ec7OHv1 8xBw== X-Gm-Message-State: AKaTC02P15aahUAjoWx+kYCi9rV7Em9I7dzX6p3eX9kRhIyN3vulUiqlraSAmNNCIa1Vew== X-Received: by 10.55.189.135 with SMTP id n129mr12538948qkf.150.1480207973466; Sat, 26 Nov 2016 16:52:53 -0800 (PST) Received: from [192.168.0.26] (75-166-206-79.hlrn.qwest.net. [75.166.206.79]) by smtp.gmail.com with ESMTPSA id i190sm25064579qke.9.2016.11.26.16.52.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Nov 2016 16:52:52 -0800 (PST) Subject: Re: [PATCH] avoid calling alloca(0) To: Jeff Law , Bernd Edlinger References: <2915e7f6-99ce-e8e2-2001-6b65bbaeb345@gmail.com> <17b7b776-dfba-c3e9-3812-a1b82fcb5b40@gmail.com> <054dca99-7ba0-2363-ff47-8e3d759765b6@gmail.com> <03c10dd8-8d0a-e02a-ad6a-d3be12b23dba@gmail.com> Cc: Jakub Jelinek , "gcc-patches@gcc.gnu.org" From: Martin Sebor Message-ID: Date: Sat, 26 Nov 2016 17:52:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: X-IsSubscribed: yes On 11/25/2016 12:51 PM, Jeff Law wrote: > On 11/23/2016 06:15 PM, Martin Sebor wrote: >> >> gcc_assert works only in some instances (e.g., in c-ada-spec.c:191) >> but not in others because some actually do make the alloca(0) call >> at runtime: at a minimum, lto.c:3285, reg-stack.c:2008, and >> tree-ssa-threadedge.c:344 assert during bootstrap. > You might have the wrong line number of reg-stack.c and lto. You've > pointed to the start of subst_asm_stack_regs and lto_main respectively. > It'd probably be better if you posted the line with a bit of context. I must have copied the wrong line numbers or had stale sources in my tree. Sorry about that. In lto.c, there are two calls to XALLOCAVEC. I believe the first one is the one where the alloca(0) call takes place: 1580 1581 tree *map = XALLOCAVEC (tree, 2 * len); 1582 for (tree_scc *pscc = *slot; pscc; pscc = pscc->next) -- 1610 { 1611 tree *map2 = XALLOCAVEC (tree, 2 * len); 1612 for (unsigned i = 0; i < len; ++i) In reg-stack.c it's these three: 2052 2053 note_reg = XALLOCAVEC (rtx, i); 2054 note_loc = XALLOCAVEC (rtx *, i); 2055 note_kind = XALLOCAVEC (enum reg_note, i); 2056 To find all such calls I modified GCC to emit an inform call for every XALLOCAVEC invocation with a zero argument, configured the patched GCC on x86_64 with all languages (including lto), bootstrapped it, ran the full test suite, and extracted the set of unique notes from the logs. Attached in the .log file is the output along with counts of each. Curiously, neither of the two above shows up, even though adding asserts for them broke bootstrap. I haven't investigated why. Martin PS The patch I used to get the output is in the attached .diff file. diff --git a/gcc/tree-core.h b/gcc/tree-core.h index 3e3f31e..24c8c32 100644 --- a/gcc/tree-core.h +++ b/gcc/tree-core.h @@ -22,6 +22,12 @@ along with GCC; see the file COPYING3. If not see #include "symtab.h" +extern void inform (location_t, const char *, ...); + +#undef WARN_ALLOCA_ZERO +#define WARN_ALLOCA_ZERO() \ + inform (0, "%s:%i: %s: alloca called with a zero argument", \ + __FILE__, __LINE__, __PRETTY_FUNCTION__) /* This file contains all the data structures that define the 'tree' type. There are no accessor macros nor functions in this file. Only the basic data structures, extern declarations and type definitions. */ diff --git a/include/libiberty.h b/include/libiberty.h index 605ff56..c293533 100644 --- a/include/libiberty.h +++ b/include/libiberty.h @@ -352,8 +352,11 @@ extern unsigned int xcrc32 (const unsigned char *, int, unsigned int); #define XDELETE(P) free ((void*) (P)) /* Array allocators. */ +#ifndef WARN_ALLOCA_ZERO +# define WARN_ALLOCA_ZERO() (void)0 +#endif -#define XALLOCAVEC(T, N) ((T *) alloca (sizeof (T) * (N))) +#define XALLOCAVEC(T, N) ((N) != 0 ? (T *) alloca (sizeof (T) * (N)) : (WARN_ALLOCA_ZERO (), (T *)0)) #define XNEWVEC(T, N) ((T *) xmalloc (sizeof (T) * (N))) #define XCNEWVEC(T, N) ((T *) xcalloc ((N), sizeof (T))) #define XDUPVEC(T, P, N) ((T *) xmemdup ((P), sizeof (T) * (N), sizeof (T) * (N)))