From patchwork Wed Jul 20 21:50:03 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 650911 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3rvrF26VbTz9t8M for ; Thu, 21 Jul 2016 07:50:29 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=Feo6zkal; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; q=dns; s=default; b=FAeSLCCzikTrMgZ6 TGI7nDeWAdmpeVnzMISMow7oWpEMu8DH/3zkb4QBx+44kq61Z+SP29yLSp7RtNkM RfVWoxIfWlT6QiriJUeNULGp0zv9MNaqvbrmmpQhEsq17xPPwChajaUwb07ai9DA Mkrhgal5s0rOBUgvoGNRQMgabiA= 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:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; s=default; bh=txpv4+3xh1AeKUxOCVzS6m 8vfec=; b=Feo6zkaloii9MbfoqTQIeJeGfs5T4lIYsNafoOPd+mrch30D9ivecq To6d3hiV8dx72QNDwuB154GGZJn+ee2F/mt/So4svren0vHBmERWOQl0iARjKcYA V0JpSEWpzJ1BgYc/0TeXE7UrRIcOTsMsqxxnE55gjISifubuOZF/w= Received: (qmail 124996 invoked by alias); 20 Jul 2016 21:50:20 -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 124951 invoked by uid 89); 20 Jul 2016 21:50:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=no version=3.3.2 spammy=HX-HELO:sk:BLU004-, Hx-spam-relays-external:sk:blu004-, H*RU:sk:BLU004-, H*RU:sk:blu004- X-HELO: BLU004-OMC4S37.hotmail.com Received: from blu004-omc4s37.hotmail.com (HELO BLU004-OMC4S37.hotmail.com) (65.55.111.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Wed, 20 Jul 2016 21:50:09 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com ([65.55.111.135]) by BLU004-OMC4S37.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 20 Jul 2016 14:50:08 -0700 Received: from VE1EUR01FT029.eop-EUR01.prod.protection.outlook.com (10.152.2.54) by VE1EUR01HT223.eop-EUR01.prod.protection.outlook.com (10.152.3.189) with Microsoft SMTP Server (TLS) id 15.1.539.16; Wed, 20 Jul 2016 21:50:05 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.2.53) by VE1EUR01FT029.mail.protection.outlook.com (10.152.2.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5 via Frontend Transport; Wed, 20 Jul 2016 21:50:04 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) with mapi id 15.01.0544.014; Wed, 20 Jul 2016 21:50:03 +0000 From: Bernd Edlinger To: Richard Biener , Jeff Law CC: "jakub@redhat.com" , "gcc-patches@gcc.gnu.org" , Jan Hubicka Subject: Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876) Date: Wed, 20 Jul 2016 21:50:03 +0000 Message-ID: References: <8ecb18e7-7914-aa9f-3000-95fd0830c2a5@redhat.com> In-Reply-To: authentication-results: spf=softfail (sender IP is 10.152.2.53) smtp.mailfrom=hotmail.de; suse.de; dkim=none (message not signed) header.d=none; suse.de; dmarc=none action=none header.from=hotmail.de; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.de discourages use of 10.152.2.53 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.2.53; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:VE1EUR01HT223; H:AM4PR0701MB2162.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; VE1EUR01FT029; 1:lvxNNlpN2b6jpTBVDDjiu2s8qcR7rNQQ1S9gcTlOv7TV92fRBzeVcNEJuvcSkq5EOG04Z5sZQDSb729PA7syzI0foby17LzgT5IQpbHkPZIVcx5TDzIqtvpjgUuachnCKc8/GuoX5uC7SUl29YVbiuYqiLRN767xP/39eWQ7WLEBRSsobMpyj+Qc2NuyMhNe7XWJMj2foERuLyu5TMow9sHmGjULp0Gh5IYIp9lWu4wT7LAgYhrqWKhf5rsGupv0HUaCytX/o2ouHD2G2qVvpEEiiCoLXMceO7ihSj9NvHYvVF+K4lUCBJriQ0vklrjngx2OHCZEC2NK+FfsnPvBpFzKdaCvC6imV1IKJUcWhpLt9Y7ulqwblmLpL7t6bT+oNo0nn/Gg4kinIWsxDCLu4CygUXXfHABjQxHBA5dugm6t/amTOZCWl5CryHHGBF3gzNPplKq/45dl6/Cuoy5Pew== x-ms-office365-filtering-correlation-id: 15eabe92-e2fe-4ebe-b23d-08d3b0e7cdb6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(5061506196)(5061507196)(1603103041)(1601125047); SRVR:VE1EUR01HT223; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(102415321)(82015046); SRVR:VE1EUR01HT223; BCL:0; PCL:0; RULEID:; SRVR:VE1EUR01HT223; x-forefront-prvs: 000947967F MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2016 21:50:03.4196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR01HT223 On 07/20/16 20:08, Richard Biener wrote: > On July 20, 2016 6:54:48 PM GMT+02:00, Bernd Edlinger wrote: >> >> But I think that alloca just should not be recognized by name any >> more. > > It was introduced to mark calls that should not be duplicated by inlining or unrolling to avoid increasing stack usage too much. Sth worthwhile to keep even with -ffreestanding. > > Richard. > On second thought I start to think that an external alloca function might still work. And returning ECF_MAY_BE_ALLOCA just based on the name could be made safe by checking the malloc attribute at the right places. With this new incremental patch the example extern "C" void *alloca(unsigned long); void bar(unsigned long n) { char *x = (char*) alloca(n); if (x) *x = 0; } might actually work when -ansi is used, i.e. it does no longer assume that alloca cannot return null, but still creates a frame pointer, which it would not have done for allocb for instance. But the built-in alloca is still recognized because the builtin does have ECF_MAY_BE_ALLOCA and ECF_MALLOC. Is it OK for trunk after boot-strap and reg-testing? Thanks Bernd. 2016-07-19 Bernd Edlinger PR middle-end/71876 * fold-const.c (tree_expr_nonzero_warnv_p): Check for real built-in alloca. * tree-vrp.c (gimple_stmt_nonzero_warnv_p): Likewise. Index: gcc/fold-const.c =================================================================== --- gcc/fold-const.c (revision 238513) +++ gcc/fold-const.c (working copy) @@ -9018,7 +9018,7 @@ tree_expr_nonzero_warnv_p (tree t, bool *strict_ov && lookup_attribute ("returns_nonnull", TYPE_ATTRIBUTES (TREE_TYPE (fndecl)))) return true; - return alloca_call_p (t); + return alloca_call_p (t) && DECL_IS_MALLOC (fndecl); } default: Index: gcc/tree-vrp.c =================================================================== --- gcc/tree-vrp.c (revision 238513) +++ gcc/tree-vrp.c (working copy) @@ -1065,7 +1065,7 @@ gimple_stmt_nonzero_warnv_p (gimple *stmt, bool *s lookup_attribute ("returns_nonnull", TYPE_ATTRIBUTES (gimple_call_fntype (stmt)))) return true; - return gimple_alloca_call_p (stmt); + return gimple_alloca_call_p (stmt) && DECL_IS_MALLOC (fndecl); } default: gcc_unreachable ();