Re: [Intel-gfx] [PATCH] drm/i915: Avoid undefined behaviour of "u32 >> 32"

2017-06-29 Thread Chris Wilson
Quoting Tvrtko Ursulin (2017-06-29 15:50:17) > > On 29/06/2017 14:49, Chris Wilson wrote: > > When computing a hash for looking up relcoation target handles in an > > execbuf, we start with a large size for the hashtable and proceed to > > reduce it until the allocation suceeds. The final attempt

Re: [Intel-gfx] [PATCH] drm/i915: Avoid undefined behaviour of "u32 >> 32"

2017-06-29 Thread Tvrtko Ursulin
On 29/06/2017 14:49, Chris Wilson wrote: When computing a hash for looking up relcoation target handles in an execbuf, we start with a large size for the hashtable and proceed to reduce it until the allocation suceeds. The final attempt is with an order of 0 (i.e. a single element). This means

[Intel-gfx] [PATCH] drm/i915: Avoid undefined behaviour of "u32 >> 32"

2017-06-29 Thread Chris Wilson
When computing a hash for looking up relcoation target handles in an execbuf, we start with a large size for the hashtable and proceed to reduce it until the allocation suceeds. The final attempt is with an order of 0 (i.e. a single element). This means that we then pass bits=0 to hash_32() which