Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)

[Mel Gorman <mel@csn.ul.ie>]

On Mon, 29 May 2006, Segher Boessenkool wrote:

>>>>  arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function 
>>>> `vrsqrtefp':
>>>>  : undefined reference to `__udivdi3'
>>>>  arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function 
>>>> `vrsqrtefp':
>>>>  : undefined reference to `__udivdi3'
>>>>  make: *** [.tmp_vmlinux1] Error 1
>>> 
>>> A function with a name like that doesn't _deserve_ to compile.
>
> Would vector_reciprocal_square_root_estimate_floating_point() be any 
> better...
> Anyway, this is just a machine insn mnemonic, so the function name is fine
> I believe.
>
>>  #define push_end(res, size) do { unsigned long __sz = (size) ; \
>> -	res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
>> +	resource_size_t farEnd = (res->end + __sz); \
>> +	do_div(farEnd, (__sz + 1)); \
>> +	res->end = farEnd * (__sz + 1) + __sz; \
>>      } while (0)
>
> Size here is a) a misnomer (size + 1 is the actual size) and b) always a 
> power
> of two minus one.  So instead, do
>
> #define push_end(res, mask) res->end = -(-res->end & ~(unsigned long)mask)
>
> (with a do { } while(0) armour if you prefer).
>

It's not doing the same as the old code so is your suggested fix a correct 
replacement?

For example, given 0xfff for size the current code rounds res->end to the 
next 0x1000 boundary and adds 0xfff. Your propose fix just rounds it to 
the next 0x1000 if I'm reading it correctly but is what the code was meant 
to do in the first place? Using masks, the equivilant of the current code 
is something like;

#define push_end(res, mask) do { \
 	res->end = -(-res->end & ~(unsigned long)mask); \
 	res->end += mask; \
} while (0)

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab