I believe the obj format that TCC uses is not the same as that MinGW produces. So I don't think it will work.
There can be subtle differences, too, say to do with the global symbol prefix. What I really need is an object disassembler for tcc, but I believe one does not exist. Another option is for me to produce a .exe which only links that one object file and inspect the assembly for that. There are lots of disassemblers available for Windows, so this should work, I think, provided the .exe is not too large. I think if you compile with symbols it is easier to locate the relevant section, but it is not something I have experience with. Bill. 2009/12/5 Cactus <[email protected]>: > > > 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. > > > -- 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.
