Re: is portable aliasing possible in C++?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/4/14, Andrew Haley <aph@xxxxxxxxxx> wrote:
> On 09/04/2014 05:11 PM, Andy Webber wrote:
>> Our goal is to avoid bugs caused by strict aliasing in our networking
>> libraries.  My question is how to guarantee that we're not violating
>> the aliasing rules while also getting the most optimization.  I've
>> read through a ton of information about this online and in some gcc
>> discussions, but I don't see a consensus.
>>
>> Memcpy always works, but is dependent on optimization to avoid copies.
>> The union of values is guaranteed to work by C++11, but may involve
>> copies.
>
> Is this a real worry?  IME it makes copies when it needs to.
>
>> Each test works when built with -O3 on gcc-4.8.3, but I would like to
>> standardize across compilers and versions.  The optimization
>> information generated by -fdump-tree-all is interesting here as it
>> shows slightly different optimization for each case though
>> reinterpret_cast and placement new generate identical code in the end.
>
> The "union trick" has always worked with GCC, and is now hallowed by
> the standard.  It's also easy to understand.  It generates code as
> efficient as all the other ways of doing it, AFAIAA.  It's what we
> have always recommended.
>
> Your test is nice.  I suppose we could argue that this is a missed
> optimization:
>
> union_copy():
>         movl    $2, %eax
>         cmpw    $2, %ax
>         jne     .L13
>
> I don't know why we only generate code for one of the tests.
>
> Andrew.
>
>

Thanks for responding. I appreciate any clarity that the gcc devs and
standards experts can give here.

I'm especially interested in the validity of the placement new
approach.   Your recommendation of going through unions causes some
difficulty for us in terms of type abstraction. Specifically,
receiving network bytes directly into a union with all possible
message types present in the union is somewhat less flexible than
determining the correct message type and doing a placement new to
create essentially a memory overlay.   Is placement new a suitable
substitute for __may_alias__ in this specific example?

Andy




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux