From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13340 invoked by alias); 28 Sep 2015 12:05:51 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 13325 invoked by uid 89); 28 Sep 2015 12:05:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 28 Sep 2015 12:05:49 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 259622EAA9C; Mon, 28 Sep 2015 12:05:48 +0000 (UTC) Received: from localhost.localdomain (vpn1-4-33.ams2.redhat.com [10.36.4.33]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8SC5k3t032346; Mon, 28 Sep 2015 08:05:46 -0400 Subject: Re: [PATCH 1/4] Add mkoffload for Intel MIC To: Jakub Jelinek References: <20141021171323.GA47586@msticlxl57.ims.intel.com> <20141021171602.GB47586@msticlxl57.ims.intel.com> <20141022082103.GH10376@tucnak.redhat.com> <20141022185701.GA21398@msticlxl57.ims.intel.com> <87r3ljuez8.fsf@kepler.schwinge.homeip.net> <5609106F.9040707@redhat.com> <560911CF.2010000@redhat.com> <20150928112548.GA25312@msticlxl57.ims.intel.com> <56092424.6000808@redhat.com> <20150928120045.GY1847@tucnak.redhat.com> Cc: Ilya Verbin , Thomas Schwinge , gcc-patches@gcc.gnu.org, Kirill Yukhin From: Bernd Schmidt Message-ID: <56092D1A.1090305@redhat.com> Date: Mon, 28 Sep 2015 12:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150928120045.GY1847@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg02103.txt.bz2 On 09/28/2015 02:00 PM, Jakub Jelinek wrote: > On Mon, Sep 28, 2015 at 01:27:32PM +0200, Bernd Schmidt wrote: >>> I've removed obstack_ptr_grow for arrays with known sizes after this review: >>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02210.html >> >> That's unfortunate, I think that made the code less future-proof. IMO we >> should revert to the obstack method especially if Thomas -v patch goes in. > > Why? If the number of arguments is bound by a small constant, using > automatic fixed size array is certainly more efficient, and I really don't > see it as less readable or maintainable. The code becomes harder to modify, with more room for error, and you no longer have consistency in how you build argv arrays within the same file. The obstack method is pretty much foolproof and doesn't even remotely allow for the possibility of a buffer overflow, and adding new arguments, even conditionally, is entirely trivial. Efficiency is really not an issue for building arguments compared to the cost of executing another binary. Bernd