llvm dev - Nov 2009 - [LLVMdev] SAFECode Source Code Released

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>

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 PoolSlab*s from it.  All your patch is doing is introducing enough 
indirection to disable the warning.

The only ways to avoid the aliasing violation are to (1) have the array 
be a PoolSlab** in the first place or (2) actually read and write void*s 
from the array, casting to and from PoolSlab* as appropriate.

John.

On 2009-11-17 10:43, John McCall wrote:
> 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 PoolSlab*s from it.  All your patch is doing is introducing
> enough indirection to disable the warning.
>
> The only ways to avoid the aliasing violation are to (1) have the
> array be a PoolSlab** in the first place or (2) actually read and
> write void*s from the array, casting to and from PoolSlab* as
> appropriate.
In this case changing the field type from void* to PoolSlab* worked (I
don't know why it had to be a void* in the first place).
Now SAFEcode (excluding the SVA runtime which I disabled in my patch)
builds.

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/a0914a5c/attachment.ksh>