On Dec 5, 4:02 pm, Bill Hart <[email protected]> wrote:
> I traced down precisely where the bug occurs. It is in the call to
> mpn_divexact_by3 in the toom3 interpolation code. If I replace that
> with a call to mpn_divexact_1 then it works fine.
>
> Under MinGW with the gcc compiler, on the same machine in Windows 32,
> the bug does not occur.
>
> That leaves few options.
>
> 1) The assembly file is misassembled by tcc.
> 2) There is a bug in the tcc linker.
> 2) The assembly file has a bug which relies on uninitialised data
> which just happens to be 0 on linux and in MinGW.
> 3) The subtle differences in calling conventions between Windows and
> Linux are biting me on this one file.
>
> I don't know how to check for 1, and consider it unlikely. An
> assembler doesn't exactly have to do a whole lot.
>
> A linker bug might be more likely, but I have no idea how to check for
> that either on Windows.
>
> Unfortunately there is no valgrind on any 32 bit machine I have access
> to, so checking 2 is difficult. I will probably have to read the
> assembly code extremely carefully.
>
> I can investigate 3, but I think there aren't enough arguments to the
> function for this to be the issue.
>
> Bill.
>
> 2009/12/5 Bill Hart <[email protected]>:
>
>
>
> > I tried to replicate the error I was having with diveby3.asm with tcc
> > on 32 bit windows, on linux, but no luck. On Cicero, which is a 32 bit
> > linux pentium4, that particular file seems to work fine.
>
> > Apart from it being misassembled by tcc, I don't really have any good
> > ideas. I checked that m4 is expanding it correctly.
>
> > There is no HAVE_NATIVE_mpn_divexact_by3 flag (at least none listed in
> > config.h), so it can't be an alternative code path. This function is
> > defined unconditionally for all archs.

If the *.obj formats are compatible (as they might be on win32) you
could take the *.obj for this file and link it into the 'other' build
(both ways) and see if it still fails.

The other thing I sometimes do is to use Agner Fog's excellent
objconv.exe program to produce assembler source code for two *.obj
modules that should be the same and then compare the resulting source
code to see if they differ.

    Brian




>
> > Bill.- Hide quoted text -
>
> - Show quoted text -

--

You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/mpir-devel?hl=en.


Reply via email to