Thursday, February 2, 2006, 12:00:09 PM, Nicolas Cannasse wrote: >Thursday, February 2, 2006, 11:50:19 AM, skaller wrote:
>>>If still crashing after the update could try to follow the different >>>calls being made and tell me in which function it's crashing ? >>>That would help alot. >> >> >> Any chance the machine registers Neko uses are being clobbered? > Yes that's one the things to check, although Neko only use registers > that should be "safe", and GCC should break when he can't allocate > needed registers. > Doug try to change in vm/interp.c : > #if defined(__GNUC__) && defined(__i386__) > to > #if false > This should disable manual register allocation for GCC. I tried this yesterday, and still got a crash. Today it fixes things, and I don't know why. [now I do, read on...] In interp.c I have //#if defined(__GNUC__) && defined(__i386__) #if 0 # define ACC_BACKUP int_val __acc = acc; etc. and build proceeds to the end. If I revert to #if defined(__GNUC__) && defined(__i386__) //#if 0 # define ACC_BACKUP int_val __acc = acc; I get the crash. I've tested 4 ways, with my gc.dll, with your gc.dll, and with or without gcc global registers. Oh, today I am compiling at -g -O2. Ah, that's the difference... -g -O2 no gcc global registers -- works -g -O2 with gcc global registers -- fails -O3 no gcc global registers -- fails -O3 with gcc global registers -- fails $ gcc --version gcc.exe (GCC) 3.4.4 (mingw special) e -- Neko : One VM to run them all (http://nekovm.org)
