[PATCH V3 1/7] drm/amdgpu: correct tcp harvest setting

[Quan, Evan]

[AMD Official Use Only]

Thanks for the information. I will use 0xffffffffu then.

BR
Evan
> -----Original Message-----
> From: Lazar, Lijo <Lijo.Lazar at amd.com>
> Sent: Tuesday, June 22, 2021 6:40 PM
> To: Michel Dänzer <michel at daenzer.net>; Quan, Evan
> <Evan.Quan at amd.com>
> Cc: Deucher, Alexander <Alexander.Deucher at amd.com>; amd-
> gfx at lists.freedesktop.org
> Subject: Re: [PATCH V3 1/7] drm/amdgpu: correct tcp harvest setting
> 
> 
> 
> On 6/22/2021 2:49 PM, Michel Dänzer wrote:
> > On 2021-06-22 8:08 a.m., Lazar, Lijo wrote:
> >> [Public]
> >>
> >> AFAIK, that expression is legal (some code analyzer may warn on value of
> 4*max_wgp_per_sh); similar kind is used in rotate shift operations.
> >
> > The default type for constants in C is int, so 0xffffffff is a 32-bit signed
> integer.
> 
> Probably not as per section 6.4.4.
> 
> "The type of an integer constant is the first of the corresponding list in which
> its value can be represented."
> 
> It is a hexadecimal constant and the first to fit this value is unsigned int.
> Regardless, adding u suffix will avoid any ambiguity.
> 
> Thanks,
> Lijo
> 
> >
> > The C99 specification lists this under J.2 Undefined behavior:
> >
> > — An expression having signed promoted type is left-shifted and either
> the value of the
> >   expression is negative or the result of shifting would be not be
> representable in the
> >   promoted type (6.5.7).
> >
> > So it would be safer to make it unsigned: 0xffffffffu (or just ~0u).
> >
> >
> >> -----Original Message-----
> >> From: Quan, Evan <Evan.Quan at amd.com>
> >> Sent: Tuesday, June 22, 2021 7:56 AM
> >> To: Lazar, Lijo <Lijo.Lazar at amd.com>; amd-gfx at lists.freedesktop.org
> >> Cc: Deucher, Alexander <Alexander.Deucher at amd.com>
> >> Subject: RE: [PATCH V3 1/7] drm/amdgpu: correct tcp harvest setting
> >>
> >> [AMD Official Use Only]
> >>
> >> Thanks Lijo.
> >> However, I'm not quite sure whether " 0xffffffff << (4 *
> max_wgp_per_sh);" is a valid expression since it kind of triggers some
> overflow.
> >> Can that work for non-x86 platform or even work reliably for x86 platform?
> >
> >
> >