[Fwd: Re: -fstrict-aliasing and naughty code?]

[Fwd: Re: -fstrict-aliasing and naughty code?]

[Andrew Cagney]

[-- 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>

Re: [Fwd: Re: -fstrict-aliasing and naughty code?]

[Eli Zaretskii]

> Date: Fri, 08 Mar 2002 17:37:59 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> Both GDB and SIM are exposed to this problem.

Can you point to specific places in the sources where this happens?

Re: [Fwd: Re: -fstrict-aliasing and naughty code?]

[Andrew Cagney]

> Date: Fri, 08 Mar 2002 17:37:59 -0500
>> From: Andrew Cagney <ac131313@cygnus.com>
>> 
>> Both GDB and SIM are exposed to this problem.
> 
> 
> Can you point to specific places in the sources where this happens?

They are ``exposed''.  BenE re-discovered some old sim code that hits 
the problem but (fortunatly?) it is not yet contributed :-/

Andrew