From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29600 invoked by alias); 8 Mar 2002 22:38:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29419 invoked from network); 8 Mar 2002 22:38:05 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 8 Mar 2002 22:38:05 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E3C943E74 for ; Fri, 8 Mar 2002 17:37:59 -0500 (EST) Message-ID: <3C893D47.1080306@cygnus.com> Date: Fri, 08 Mar 2002 14:38:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.8) Gecko/20020210 X-Accept-Language: en-us MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: [Fwd: Re: -fstrict-aliasing and naughty code?] Content-Type: multipart/mixed; boundary="------------050207060902090005020304" X-SW-Source: 2002-03/txt/msg00075.txt.bz2 This is a multi-part message in MIME format. --------------050207060902090005020304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 65 Just FYI, Both GDB and SIM are exposed to this problem. Andrew --------------050207060902090005020304 Content-Type: message/rfc822; name="Re: -fstrict-aliasing and naughty code?" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: -fstrict-aliasing and naughty code?" Content-length: 2981 X-Mozilla-Status2: 00000000 Return-Path: Received: from smtpin09.mac.com ([10.13.10.154]) by ms03.mac.com (Netscape Messaging Server 4.15) with ESMTP id GSMNGX00.IAN for ; Thu, 7 Mar 2002 15:48:33 -0800 Received: from desire.geoffk.org (12-235-56-190.client.attbi.com [12.235.56.190]) by smtpin09.mac.com (8.12.1/8.12.1/1.0) with ESMTP id g27NmMoZ002884 for ; Thu, 7 Mar 2002 15:48:22 -0800 (PST) Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id g27NmT020705; Thu, 7 Mar 2002 15:48:29 -0800 X-Authentication-Warning: desire.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f Sender: geoffk@geoffk.org To: Andrew Cagney CC: gcc@gcc.gnu.org Subject: Re: -fstrict-aliasing and naughty code? References: <3C87F8DD.2010407@mac.com> From: Geoff Keating Date: 07 Mar 2002 15:48:28 -0800 In-Reply-To: <3C87F8DD.2010407@mac.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-length: 1855 Andrew Cagney 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 --------------050207060902090005020304--