From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [130.237.48.193]) by dpdk.org (Postfix) with ESMTP id C79E91B3AF for ; Thu, 31 Jan 2019 09:02:40 +0100 (CET) Received: from smtp-4.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-4.sys.kth.se (Postfix) with ESMTP id 5516D2970; Thu, 31 Jan 2019 09:02:40 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-4.sys.kth.se ([127.0.0.1]) by smtp-4.sys.kth.se (smtp-4.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oVjWv-U47k6b; Thu, 31 Jan 2019 09:02:39 +0100 (CET) X-KTH-Auth: barbette [130.237.20.142] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1548921759; bh=npXoTW2i29XdYFqEYCFdRogVzpU8UfR07hK2rwRBMLU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=bQvKW3w3/EyXoS+DEUcEKRkv510vPBd8dAocPRACtxlkfiyzc1nuBW2EveQr54j2n LsuSpPOITSpyu6GyWYJ9Q9amsSfwoKVMdp8CRYk4gARGANJxoZz0X5aifK9CPnAeq5 cy858uRPViDBlpwaffhkU4l20Fn1e2QX74cI9wvQ= X-KTH-mail-from: barbette@kth.se Received: from [130.237.20.142] (s2587.it.kth.se [130.237.20.142]) by smtp-4.sys.kth.se (Postfix) with ESMTPSA id E098F25E1; Thu, 31 Jan 2019 09:02:36 +0100 (CET) To: Ferruh Yigit , Stephen Hemminger , Yongseok Koh Cc: Adrien Mazarguil , "dev@dpdk.org" References: <20180731163059.27085-1-stephen@networkplumber.org> <20180731164840.GD5211@6wind.com> <20180731110737.38555f02@xeon-e3> <50204CDA-B4AD-44C8-AB07-2FE9C2A412C0@mellanox.com> <20180801140356.5ac88c43@xeon-e3> From: Tom Barbette Message-ID: <2b06aafe-e444-b773-b5cd-bd0f186e46cd@kth.se> Date: Thu, 31 Jan 2019 09:02:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 0/5] remove usage of register keyword in C X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2019 08:02:41 -0000 Hi all, Has there been any change regarding this? I'm still at DPDK 18.11. Maybe automatically add -Wno-register when C++17 is enabled? Or have a some register macro which gets undefined if C++17 is enabled? The "warning: ISO C++1z does not allow ‘register’ storage class specifier" is annoying. And vim always goes to some DPDK header when ":make" fails because of the warning... Thanks, Tom On 2018-10-09 11:19, Ferruh Yigit wrote: > On 8/23/2018 2:07 PM, Ferruh Yigit wrote: >> On 8/1/2018 10:03 PM, Stephen Hemminger wrote: >>> On Wed, 1 Aug 2018 18:03:04 +0000 >>> Yongseok Koh wrote: >>> >>>>> On Jul 31, 2018, at 11:07 AM, Stephen Hemminger wrote: >>>>> >>>>> On Tue, 31 Jul 2018 18:48:40 +0200 >>>>> Adrien Mazarguil wrote: >>>>> >>>>>> On Tue, Jul 31, 2018 at 09:30:54AM -0700, Stephen Hemminger wrote: >>>>>>> Declaring variables as register in C is a leftover from an earlier >>>>>>> era (like cassette tape decks in cars). >>>>>> >>>>>> I don't agree here. It's a hint for compilers and developers that the >>>>>> address of such variables won't be needed (and cannot be taken) to enable >>>>>> whatever optimizations are possible knowing this. >>>>>> >>>>>> Somewhat like inline functions, it's not a forced optimization, just a >>>>>> useful hint that shouldn't hurt if used wisely. >>>>>> >>>>>> Besides, cassette decks are not dead yet :) >>>>> >>>>> If you look at the code, that is not how register is being used (ie. don't take >>>>> address of this). It seems like an attempt at optimization. >>>> >>>> I know compilers are smart enough and the occurrences in mlx4/5 were made from >>>> my old fashioned habit. But, I don't see any urgency to push this patch in RC >>>> stage even though I'm 99% sure that it is harmless. And in general I don't even >>>> understand why we can't live with that if it isn't harmful (or a violation) but >>>> informative. I mean no badness but at least one goodness :-) >>>> >>>> Thanks, >>>> Yongseok >>>> >>> >>> Sure, this is intended for next release not rc stage. >>> Just trying to clean up code base where I see it. >> >> I agree with Yongseok, at worst they show the intention of the developer, I >> don't see motivation to remove them unless they are doing something wrong, which >> seems not the reason of this patch. >> >> And although I found some information that says "register" ignored completely >> for gcc, I can see it differs when optimization disabled. >> I am not saying practically it differs, since we enable optimization expect from >> debugging, most probably there is no practical difference between having the >> keyword or not, but what I am trying to say is it not completely ignored either. > > I am for marking this set as rejected, any objection? >