[dpdk-dev] [PATCH 0/5] remove usage of register keyword in C
Tom Barbette
barbette at kth.se
Thu Jan 31 09:02:36 CET 2019
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 <yskoh at mellanox.com> wrote:
>>>
>>>>> On Jul 31, 2018, at 11:07 AM, Stephen Hemminger <stephen at networkplumber.org> wrote:
>>>>>
>>>>> On Tue, 31 Jul 2018 18:48:40 +0200
>>>>> Adrien Mazarguil <adrien.mazarguil at 6wind.com> 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?
>
More information about the dev
mailing list