On 2009-11-16 22:46, John Criswell wrote:> [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 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 -------------- An embedded and charset-unspecified text was scrubbed... Name: log URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091116/f78c1992/attachment.ksh>
Török Edwin wrote:> On 2009-11-16 22:46, John Criswell wrote: > >> [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 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? >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 incomplete or object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer. But the _compatibility_ rules for pointers don't mention void* (6.7.5.1p2): For two pointer types to be compatible, both shall be identically qualified and both shall be pointers to compatible types. Nor is there an exception carved out in 6.5p1. Among other things, this permits null pointers to have different representations based on the element type, &c &c. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091116/d6e3d19a/attachment.html>
On 2009-11-16 23:42, John McCall wrote:> Török Edwin wrote: >> On 2009-11-16 22:46, John Criswell wrote: >> >>> [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 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? >> > > 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 incomplete or object type > may be converted to a pointer to void and back again; the result shall > compare equal to the original pointer. > > But the _compatibility_ rules for pointers don't mention void* > (6.7.5.1p2): > > For two pointer types to be compatible, both shall be identically > qualified and both shall be pointers to compatible types. > > Nor is there an exception carved out in 6.5p1. > > Among other things, this permits null pointers to have different > representations based on the element type, &c &c.Ok, then converting from void** to PoolSlab** can be done by going through void* as an intermediary type? The attached patch fixes the warnings. BTW how do I run make check for SAFEcode? It says 'make[1]: Nothing to be done for `check-local'' if I run make check. Best regards, --Edwin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091117/84c54c43/attachment.ksh>