Re: __divdi3 unresolved + X pointer blocks

quoted

quoted

quoted

quoted

Holger Bettag writes:

Holger> And: 'arithmetic shift right' is _not_ the same as signed divide, because the
Holger> rounding of negative operands or results may differ.

	Exactly!  For a 32-bit operand, a signed divide by an exact power
of two is equivalent to:

srawi
addze

	For synthesized 64-bit operand, this is more complicated, which is
why GCC calls __divdi3 instead of open-coding it.

	Will all of the people posting INCORRECT information about logical
versus arithmetic shift and converting signed divide into shift, please
stop.  You are propagating bad information.

	If one converts a divide into a shift, one is assuming more
information than one has informed the compiler.

	This whole discussion thread is confusing two issues.  If one
wants GCC to produce a shift, one needs to write the code so that GCC
safely can convert the divide into a shift.  If the shift is not safe,
then the Linux kernel needs to provide __divdi3.

	The two suggestions of writing the divide as a shift and linking
with libgcc.a BOTH ARE WRONG.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

	The two suggestions of writing the divide as a shift and linking
with libgcc.a BOTH ARE WRONG.

I haven't seen anyone suggest we link the kernel with libgcc.a. Just 'the
kernel needs to provide __divdi3'. As in: the kernel needs to provide a
hell of a lot of libgcc.a stuff on the various architectures (ashldi3,
ashrdi3, lshrdi3 come to mind, m68k and sparc). It's been done for ages.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/