search for: poolslab

...tions. 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 _convertible_ to an arbitrary pointer type (6.3.2.3p1): > > A pointer to void may be converted to or from a pointer to any > incomplet...

Török Edwin wrote: > Ok, then converting from void** to PoolSlab** can be done by going > through void* as an intermediary type? > The violation is not in how you're converting the void** to a PoolSlab**. That array is forever and always an array of void*s, and no amount of conversion will make it not a strict-aliasing violation to load PoolSla...

...at 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 -------------- An embedded and charset-unspecified text was scrubbed... Name: log URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/200911...

...e 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 _convertible_ to an arbitrary pointer type (6.3.2.3p1): A pointer to void may be converted to or from a pointer to any incomplete or object type. A pointer to any...

[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 >>>

Török Edwin 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 > Thanks for the patch. What options do I give to the patch command to apply it to the source code? Although there's no documentation about