mpn_rshift / mpn_lshift bug on m68000

[Kevin Ryde]

Patrick Pelissier <Patrick.Pelissier at loria.fr> writes:
>
>   No. Until on 68000 (I am not sure for mcpu32, but I am sure it isn't
> the case on 68000).

This is almost certainly an aspect of the system, not the cpu.

> Build GMP on netbsd 68040 with theses options, and try the test. I
> hope you will see the bug.

Thanks, I see -mshort breaks the calling conventions.

That option is going to be unusable on any svr4 style system.  I
wonder what it's for.  68000 embedded system cross compiles or
something I guess.

If you have a system that you're using which has or wants those
variant conventions then we can accomodate it, otherwise I'm going to
add the words below to the manual.

(Incidentally, if you're using 68k of whatever flavour we're always on
the lookout for good, complete, well-tested assembler code
optimizations.  Those chips will always run slow, but perhaps can be
made less slow than they were before.  :-)


@item Motorola 68k ABI
@cindex 68000
@cindex PalmOS
The GMP assembler code has been written for the SVR4 standard ABI.  GCC option
@samp{-mshort} changes the calling conventions and is not supported.  We
believe the PalmOS calling conventions are similarly different and are
likewise not currently supported.
@c
@c  For reference, -mshort doesn't just change the size of an int but also
@c  changes the stack alignment to only 16-bits, where in svr4 it's 32-bits.
@c  This affects mpn_lshift and mpn_rshift in the gmp code, but perhaps
@c  nowhere else.  Having those routines understand the variant stack frame
@c  wouldn't be hard, if anyone was keen.  (PalmOS had problems building due
@c  to lack of stdio.h last time it was tried, so it's not yet really a
@c  target.)

-- 
All followups to gmp-bugs at swox.com please.