search for: bitmappoolalloc

Displaying 6 results from an estimated 6 matches for "bitmappoolalloc".

2009 Nov 16
2
[LLVMdev] SAFECode Source Code Released
...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...
2009 Nov 16
0
[LLVMdev] SAFECode Source Code Released
...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 _conve...
2009 Nov 16
4
[LLVMdev] SAFECode Source Code Released
...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...
2009 Nov 16
0
[LLVMdev] SAFECode Source Code Released
[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
2009 Nov 16
3
[LLVMdev] SAFECode Source Code Released
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 >>>
2009 Nov 17
2
[LLVMdev] SAFECode Source Code Released
...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? >> &...