search for: bitmappoolallocator

...rnings; -Werror > provides incentive for that. > > I'll consider removing it if there's a problem that's not trivially > fixable. That leaves us with the aliasing violations. I looked at the first, and I couldn't tell why gcc (4.3.4) thinks it is wrong: safecode/runtime/BitmapPoolAllocator/PoolAllocatorBitMask.cpp:185: warning: dereferencing type-punned pointer will break strict-aliasing rules Line 185 is: PS->addToList((PoolSlab**)&Pool->Ptr2); and Ptr2 is a field of type void*. Isn't void* compatible with anything? Best regards, --Edwin -------------- next part ----...

...hat. >> >> I'll consider removing it if there's a problem that's not trivially >> fixable. >> > > That leaves us with the aliasing violations. I looked at the first, and > I couldn't tell why gcc (4.3.4) thinks it is wrong: > safecode/runtime/BitmapPoolAllocator/PoolAllocatorBitMask.cpp:185: > warning: dereferencing type-punned pointer will break strict-aliasing rules > Line 185 is: PS->addToList((PoolSlab**)&Pool->Ptr2); > > and Ptr2 is a field of type void*. Isn't void* compatible with anything? > No. void* is _convertib...

...ic Pool Allocation on 64 bit architectures, so while it may work, we can't say for certain that it will. This particular error is caused by the fact that the run-time does not know which allocator is best for allocating page-aligned sections of memory. If you modify getPages() in runtime/BitmapPoolAllocator/PageManager.cpp to use mmap(), posix_memalign(), or valloc(), then it will fix this error and allow you to continue experimenting with Poolalloc/SAFECode in 64-bit mode. Eventually, we should set up something in the configure script to find a usable default for this function. This would be a s...

[snip] > > My initial message (containing the patch) was a private reply to John. > > Attached the patch again, it applies with 'patch -p0'. > > Also try to build on x86-32, x86-64 is not quite ready yet. > Actually, I made one small change to the patch. I kept -Werror in Makefile.common.in. It's better if we fix these warnings; -Werror provides incentive

On 2009-11-16 21:53, David Greene wrote: > On Monday 16 November 2009 13:04, John Criswell wrote: > >>> [snip] >>> >>> I applied the attached patch to make it compile on my box (Debian >>> x86_64), only to find out that x86_64 is not supported :( >>> This architecture is not supported by the pool allocator! >>> Aborted >>>

...gt;> I'll consider removing it if there's a problem that's not trivially >>> fixable. >>> >> That leaves us with the aliasing violations. I looked at the first, and >> I couldn't tell why gcc (4.3.4) thinks it is wrong: >> safecode/runtime/BitmapPoolAllocator/PoolAllocatorBitMask.cpp:185: >> warning: dereferencing type-punned pointer will break strict-aliasing rules >> Line 185 is: PS->addToList((PoolSlab**)&Pool->Ptr2); >> >> and Ptr2 is a field of type void*. Isn't void* compatible with anything? >> >...