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. > > Bill. > -- 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.
