public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: Andy Webber <andy@aligature.com>, gcc-help@gcc.gnu.org
Subject: Re: is portable aliasing possible in C++?
Date: Thu, 04 Sep 2014 16:51:00 -0000	[thread overview]
Message-ID: <5408988E.2060301@redhat.com> (raw)
In-Reply-To: <CADa0DUiuqwF2rbvBcUQOFMN7iVMtedryYLO3i1gCskSRdcOvtg@mail.gmail.com>

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.

  reply	other threads:[~2014-09-04 16:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A76FB9DDEDFA994BAF6B77704A4AF465BC2464@xchmbbal502.ds.susq.com>
2014-09-04 16:11 ` Andy Webber
2014-09-04 16:51   ` Andrew Haley [this message]
2014-09-04 17:18     ` Andy Webber
2014-09-04 17:23       ` Andrew Haley
2014-09-04 17:44         ` Andy Webber
2014-09-04 17:47           ` Andy Webber
2014-09-04 17:48           ` Andrew Haley
2014-09-04 23:11     ` Jonathan Wakely
2014-09-05  7:16       ` Andrew Haley
2014-09-05 14:19       ` Jason Merrill
2014-09-08  9:33         ` Richard Biener
2014-09-10 14:31           ` Jason Merrill
2014-09-09 23:13 haynberg
2014-09-10  8:17 ` Andrew Haley
2014-09-10 23:03 haynberg
2014-09-11  8:11 ` Andrew Haley
2014-09-11 23:25   ` haynberg
2014-09-12  8:32     ` Andrew Haley
2014-09-12 22:58       ` haynberg
2014-09-13  7:23         ` Andrew Haley
2014-09-13 11:45           ` Oleg Endo
2014-09-15  2:37           ` Hei Chan
2014-09-15  8:35             ` Andrew Haley
2014-09-15 11:07               ` Hei Chan
2014-09-15 11:21                 ` Andrew Haley
2014-09-15 11:29                   ` Hei Chan
2014-09-15 11:32                     ` Andrew Haley
2014-09-15 11:57                       ` Hei Chan
2014-09-15 13:21                         ` Andrew Haley
2014-09-15 13:31                           ` Hei Chan
2014-09-15 14:11                             ` Andrew Haley
2014-09-15 11:27                 ` Jonathan Wakely
2014-09-15 12:09                   ` Paul Smith
2014-11-02 23:55       ` Hei Chan
2014-11-03  9:34         ` Andrew Haley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5408988E.2060301@redhat.com \
    --to=aph@redhat.com \
    --cc=andy@aligature.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).