public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Patrick Horgan <phorgan1@yahoo.com>
To: gcc-help@gcc.gnu.org
Subject: Re: alias question
Date: Wed, 23 Feb 2011 01:31:00 -0000	[thread overview]
Message-ID: <4D646313.4020909@yahoo.com> (raw)
In-Reply-To: <34841.78061.qm@web130223.mail.mud.yahoo.com>

On 02/18/2011 09:35 AM, xorbe wrote:
>> >  But not every type aliases character type!
> What?  You can access any type with a char type,
> this is a specific exception.
>
> Here's a concrete example.  I think the point that is being
> overlooked is that all*writes*  are done with char only.
> That's the twist that makes this follow the letter of the
> law.  It doesn't matter that short and int overlap below,
> because they are "both" written simultaneously with a char.
>
> #include<stdio.h>
> char b[4] = {0,0,0,0};
> const short*w((short*)b);
> const int*d((  int*)b);
> void print() {printf("%02x%02x%02x%02x %04x%04x %08x\n",
>                       b[3],b[2],b[1],b[0],w[1],w[0],d[0]);}
> int main() {
>    print();
>    for (int i(0); i<4; ++i) { b[i] = i+1; print(); }
> }
>
> ie,
> b[3] = value;
> The compiler looks at w[1], and says, oh there was a byte write.
> The compiler looks at d[0], and says, oh there was a byte write.
> The compiler doesn't even notice that w[1] and d[0] overlap,
> which is what alias optimization is about.  But it does notice
> that b[3] and w[1] overlap, and that b[3] and d[0] overlap.
Actually the compiler doesn't have to notice any of the above.  The real 
issue is whether the compiler can assume there are no aliases and take 
the opportunity to make optimizations under that assumption.  Under the 
rules, the compiler is free to assume that w and d do not alias, but 
must assume that b can alias everything.   It's the rule.  Accesses 
through char* or char& can alias anything and if they can, the compiler 
must make the assumption that they have and scotch any otherwise 
available optimizations.

Patrick
> Jason
>
>
>
>
>

  parent reply	other threads:[~2011-02-23  1:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-18 18:31 xorbe
2011-02-19  9:41 ` Segher Boessenkool
2011-02-19 19:01   ` xorbe
2011-02-23  1:30 ` Patrick Horgan
2011-02-23  1:31 ` Patrick Horgan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-02-18  2:03 xorbe
2011-02-18  4:25 ` Segher Boessenkool
2011-02-18 10:02   ` Andrew Haley
2011-02-18 13:30     ` Segher Boessenkool
2011-02-18 13:45       ` Andrew Haley
2011-02-18 14:31         ` Segher Boessenkool
2011-02-18 14:44           ` Andrew Haley
2011-02-18 15:00             ` Segher Boessenkool
2011-02-18 10:32   ` xorbe
2011-02-18 10:40     ` 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=4D646313.4020909@yahoo.com \
    --to=phorgan1@yahoo.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).