This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/410: -fstrict-aliasing and sim badness
- From: ac131313 at redhat dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 8 Mar 2002 22:37:10 -0000
- Subject: gdb/410: -fstrict-aliasing and sim badness
- Reply-to: ac131313 at redhat dot com
>Number: 410
>Category: gdb
>Synopsis: -fstrict-aliasing and sim badness
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Mar 08 14:38:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: ac131313@redhat.com
>Release: unknown-1.0
>Organization:
>Environment:
>Description:
Below is a reply from an e-mail I sent to gcc@. This was apparently discovered ~two years ago. I'm not sure any current src/sim simulators suffer this problem. I'm mainly adding it for reference.
GDB, is also very much exposed to the same problem.
>How-To-Repeat:
To: Andrew Cagney
CC: gcc@
Subject: Re: -fstrict-aliasing and naughty code?
From: Geoff Keating
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.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: