From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sources.redhat.com
Subject: [Fwd: Re: -fstrict-aliasing and naughty code?]
Date: Fri, 08 Mar 2002 14:38:00 -0000 [thread overview]
Message-ID: <3C893D47.1080306@cygnus.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 65 bytes --]
Just FYI,
Both GDB and SIM are exposed to this problem.
Andrew
[-- Attachment #2: Re: -fstrict-aliasing and naughty code? --]
[-- Type: message/rfc822, Size: 3002 bytes --]
From: Geoff Keating <geoffk@geoffk.org>
To: Andrew Cagney <cagney@mac.com>
Cc: gcc@gcc.gnu.org
Subject: Re: -fstrict-aliasing and naughty code?
Date: 07 Mar 2002 15:48:28 -0800
Message-ID: <jmhens6isz.fsf@desire.geoffk.org>
Andrew Cagney <cagney@mac.com> writes:
> Hello,
>
> I'm trying to understand how to write ``bad'' (host dependant) code
> that doesn't get screwed by strict aliasing.
>
> For instance, the code snipit:
>
> > unsigned i;
> > unsigned64 tmp_reg, tmp_reg1;
> > for (i = 0; i < 4; i++)
> > *( (i < 2 ? (unsigned32 *) &tmp_reg
> > : (unsigned32 *) &tmp_reg1)
> > + (1 - i % 2) ) = ...;
> > cpu->registers[...] = tmp_reg;
> >
>
> I'm told, is bad because:
>
> > apparently, when -fstrict-aliasing is in effect, gcc is
> > allowed to assume that the expression inside the for loop
> > has no effect on the value of tmp_reg and tmp_reg1, since
> > the assignment is to an object of dissimilar type.
>
> Provided I make (wild?) assumptions about the host and compiler, can I
> instead write the above to use something like:
>
> union {
> unsigned64 u64;
> unsigned32 u32[2];
> } tmp_reg, tmp_reg1;
>
> for (i = 0; i < 4; i++)
> if (i < 2)
> tmp_reg.u32[1 - i % 2] = ...
> else
> tmp_reg1.u32[1 - i %2] = ...;
> cpu->registers[...] = tmp_reg.u64;
Yes, this is documented to work:
The practice of reading from a different union member than the one
most recently written to (called "type-punning") is common. Even
with `-fstrict-aliasing', type-punning is allowed, provided the
memory is accessed through the union type.
However, it will be no more efficient than the more portable
unsigned32 tmp_reg[2], tmp_reg1[2];
for (i = 0; i < 4; i++)
if (i < 2)
tmp_reg[1 - i % 2] = ...
else
tmp_reg1[1 - i %2] = ...;
cpu->registers[...] = (unsigned64)tmp_reg[0] << 32 | tmp_reg[1];
in fact it will usually be less efficient because GCC will allocate
registers better for the second example.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>
next reply other threads:[~2002-03-08 22:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-08 14:38 Andrew Cagney [this message]
2002-03-09 2:14 ` Eli Zaretskii
2002-03-09 7:39 ` Andrew Cagney
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=3C893D47.1080306@cygnus.com \
--to=ac131313@cygnus.com \
--cc=gdb@sources.redhat.com \
/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