v5.0.1, Mac, 32-bit: gmp_snprintf problem for (high) multi-limb integers

[Torbjorn Granlund]

neunhoef at mcs.st-and.ac.uk (Max Neunhoeffer) writes:

  So m4 is used to create the actual assembler-source-code.
  This step seems to go wrong, since the 5th assembler statement
  in __gmpn_invert_limb which reads
  
          movzwl  -1024+approx_tab(%eax, %eax), %eax      C %eax = v0
  in invert_limb.asm is correctly translated into
          movzwl  -1024+approx_tab(%eax, %eax), %eax
  on Linux but incorrectly translated into
          movzwl  -1024+__gmpn_invert_limb_tab, %eax
  on MacOS.
  
  This leads to the fact that in some lookup table the lookup does no
  longer work. This trips up invert_limb and division.
  
  Note that the file invert_limb.asm says:
  
  C Make approx_tab global to work around Apple relocation bug.
  ifdef(`DARWIN',`
          define(`approx_tab', MPN(invert_limb_tab))
                  GLOBL   approx_tab')
  
  Is this the problem?
  
I've read and reread your text.  Unfortunately, I don't understand what
the error might be in the code you analyse.  As you can tell, we have
worked around a Mac OS bug, supposedly with some success.

Have you stepped though invert_limb on two systems, with the same input,
and see that loaded data from the appox_tab (or whatever we rename it
to) differs?

I side note: It is absolutely impossible that "make check" passes if
division does not work.  It it passes, there must be some linkage flags
set in the environment of your system making some not miscompiled
library version become picked up.

-- 
Torbjörn