Hello, Edwin> Probably there are more 64-bit issues to solve. Unfortunately I don't > have time to look into this deeper now.At least these "4" looks pretty suspicious: - (void *)gcset((gc **)((unsigned int)this + nbb + 4 - sizeof(void *)), + (void *)gcset((gc **)((size_t)this + nbb + 4 - sizeof(void *)), (Object*)m); -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
Anton Korobeynikov wrote:> Hello, Edwin >Hi Anton,>> Probably there are more 64-bit issues to solve. Unfortunately I don't >> have time to look into this deeper now. >> > At least these "4" looks pretty suspicious: > > - (void *)gcset((gc **)((unsigned int)this + nbb + 4 - sizeof(void > *)), > + (void *)gcset((gc **)((size_t)this + nbb + 4 - sizeof(void *)), > (Object*)m); >Good point. I think it would be best to review the code Class by Class to locate 64-bit problems. Having unit-tests for this code would make this a lot easier .... Maybe somebody participating at GSoC could take care of this ;) Best regards, --Edwin
Török Edwin wrote:> > Good point. > > I think it would be best to review the code Class by Class to locate > 64-bit problems. >Indeed, the source code is very x86_64 unfriendly. Most of the errors should be in the GC and the Allocator though.> Having unit-tests for this code would make this a lot easier .... > > Maybe somebody participating at GSoC could take care of this ;) >Yeah, porting to all LLVM supported architectures, that would be great! As well as a test suite. As well as.... ;-) Nicolas> Best regards, > --Edwin > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >