From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31579 invoked by alias); 28 Mar 2011 11:06:31 -0000 Received: (qmail 31568 invoked by uid 22791); 28 Mar 2011 11:06:30 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-wy0-f175.google.com (HELO mail-wy0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Mar 2011 11:06:26 +0000 Received: by wye20 with SMTP id 20so2462084wye.20 for ; Mon, 28 Mar 2011 04:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.61.146 with SMTP id t18mr3520865wbh.189.1301310385084; Mon, 28 Mar 2011 04:06:25 -0700 (PDT) Received: by 10.227.64.142 with HTTP; Mon, 28 Mar 2011 04:06:25 -0700 (PDT) In-Reply-To: <4D9065FD.6060100@gnu.org> References: <4D9065FD.6060100@gnu.org> Date: Mon, 28 Mar 2011 11:28:00 -0000 Message-ID: Subject: Re: Possible Bug From: Richard Guenther To: Paolo Bonzini Cc: Ian Lance Taylor , Nathan Boley , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg00442.txt.bz2 On Mon, Mar 28, 2011 at 12:42 PM, Paolo Bonzini wrote: > On 03/27/2011 06:27 AM, Ian Lance Taylor wrote: >> >> Nathan Boley =A0writes: >> >>> In a much larger application, I was getting a weird segfault that an >>> assignment to a temporary variable fixed. I distilled the example into >>> the attached "test_case.c". When I run test_case.c under valgrind I >>> get a memory read error, and it segfaults with electric fence, but I'm >>> not actually able to get a true segfault. However, I am pretty sure >>> that the same issue was causing the segfault in my application. >> >> There is nothing wrong if gcc is reading an 8-byte value at an 8-byte >> aligned address. > > Note the struct is packed, so alignof =3D 1. > >> That said, I could not recreate the problem with your test case. =A0I on= ly >> see 4-byte loads. > > I see it with this modified testcase: > > #include > #include > > /* GCC uses 4-byte + 2-byte loads and stack passing */ > typedef struct __attribute__((__packed__)) > { > =A0 unsigned short chr; > =A0 unsigned int loc; > } GENOME_LOC_TYPE_1; > > /* GCC uses 8-byte loads and register passing even though sizeof =3D 6 */ > typedef struct __attribute__((__packed__)) > { > =A0 unsigned chr =A0 =A0 =A0 =A0 =A0 =A0:16; > =A0 unsigned loc =A0 =A0 =A0 =A0 =A0 =A0:32; > } GENOME_LOC_TYPE_2; > > //#define GENOME_LOC_TYPE GENOME_LOC_TYPE_1 > #define GENOME_LOC_TYPE GENOME_LOC_TYPE_2 > > static __attribute__((__noclone__,__noinline__)) > int f(GENOME_LOC_TYPE x) > { > =A0return x.loc; > } > > GENOME_LOC_TYPE h; > GENOME_LOC_TYPE *g =3D &h; > > int > main() > { > =A0printf ("%d %d\n", sizeof (GENOME_LOC_TYPE), > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __alignof__(GENOME_LOC_TYPE)); > =A0return f(*g); > } > > > Both definitions have a (sizeof =3D 6, alignof =3D 1) but GCC loads the s= econd > with an 8-byte load. =A0It's really an ugly bug if I understood it correc= tly, > because I would have expected the second struct to have sizeof =3D 8. =A0= The two > final bytes are not padding, they are what's left of the unsigned int from > which the bitfields are carved. =A0If that were the correct fix for the b= ug, > it would be a change to the ABI. At expansion time we have the following for the call argument: unit size align 8 symtab 0 alias set -1 canonical type 0x7ffff5b29540 which looks ok to me. expand generates a MEM of BLKmode: (mem/s:BLK (reg/f:DI 62) [0 MEM[(struct GENOME_LOC_TYPE_2 *)g.0_1]+0 S6 A8]) which is also ok. But then calls.c calls move_block_to_reg and messes up via operand_subword_force (mem, 0, BLKmode) which simply makes a DImode mem out of it. Richard.