GMP MIPS64 divrem_1.asm bug?

[Torbjorn Granlund]

"Himlin, Bob" <bob.himlin at viasat.com> writes:

  I am running GMP on a Cavium Networks Octeon board, and trying to use
  64-bit mode, e.g. mabi=64.  The software package was originally complied
  and runs on the same hardware in 32-bit mode (mabi=n32).  I have run into
  the following issue with mpn/mips64/divrem_1.asm, which uses ADDU instead
  of DADDU to manipulate addresses.  The first example that tripped me up
  (though there are others, I am sure), is the last few lines of the
  following snip, which uses ADDU instead of DADDU to adjust a passed-in
  pointer, inadvertently making it a 32-bit address, then tries to access
  memory at that address causing a segmentation fault.
  
   
  
  .L176:
  sll   $2,$4,3
  addu  $2,$2,-8
  dli   $3,0x8000000000000000
  and   $3,$8,$3
  beq   $3,$0,.L177
  addu  $14,$14,$2
  beq   $7,$0,.L494
  dsll  $2,$8,1
  sll   $2,$7,3
  addu  $2,$2,$6
  ld    $13,-8($2)
  
   
  
  I am interested to hear if there is a simple solution to this - how is it
  that the library is used on MIPS64 with this error?  Do not all MIPS64
  behave the same way?
  
This surely looks like a bug affecting the ABI "64", but not the o32
or n32 ABIs.

I don't think the MIPS GMP code gets a lot of testing these days.  The
automated GMP build system does run on an ancient MIPS Irix system,
but this system does not seem to allocate anything at high enough
addresses for this bug to be triggered.

I don't feel comfortable editing the MIPS files, since I am not
familiar with the the ABIs.  For example, are 32-bit types used as
arguments zero extended when passed as parameters?  If they are not,
meaning the callee needs to extend them, we cannot safely change the
ADDUs to DADDUs, the SLLs to DSLLs, etc.

The best fix might be to simply delete mips64/divrem_1.asm.

-- 
Torbjörn