From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20973 invoked by alias); 28 Mar 2011 10:42:16 -0000 Received: (qmail 20962 invoked by uid 22791); 28 Mar 2011 10:42:15 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-pv0-f175.google.com (HELO mail-pv0-f175.google.com) (74.125.83.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Mar 2011 10:42:11 +0000 Received: by pvc30 with SMTP id 30so1075671pvc.20 for ; Mon, 28 Mar 2011 03:42:10 -0700 (PDT) Received: by 10.142.234.5 with SMTP id g5mr2980858wfh.255.1301308930274; Mon, 28 Mar 2011 03:42:10 -0700 (PDT) Received: from yakj.usersys.redhat.com (93-34-210-217.ip51.fastwebnet.it [93.34.210.217]) by mx.google.com with ESMTPS id o11sm5725640wfa.0.2011.03.28.03.42.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2011 03:42:09 -0700 (PDT) Message-ID: <4D9065FD.6060100@gnu.org> Date: Mon, 28 Mar 2011 11:06:00 -0000 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ian Lance Taylor CC: Nathan Boley , gcc@gcc.gnu.org Subject: Re: Possible Bug References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00441.txt.bz2 On 03/27/2011 06:27 AM, Ian Lance Taylor wrote: > Nathan Boley writes: > >> 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 = 1. > That said, I could not recreate the problem with your test case. I only > 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__)) { unsigned short chr; unsigned int loc; } GENOME_LOC_TYPE_1; /* GCC uses 8-byte loads and register passing even though sizeof = 6 */ typedef struct __attribute__((__packed__)) { unsigned chr :16; unsigned loc :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) { return x.loc; } GENOME_LOC_TYPE h; GENOME_LOC_TYPE *g = &h; int main() { printf ("%d %d\n", sizeof (GENOME_LOC_TYPE), __alignof__(GENOME_LOC_TYPE)); return f(*g); } Both definitions have a (sizeof = 6, alignof = 1) but GCC loads the second with an 8-byte load. It's really an ugly bug if I understood it correctly, because I would have expected the second struct to have sizeof = 8. The two final bytes are not padding, they are what's left of the unsigned int from which the bitfields are carved. If that were the correct fix for the bug, it would be a change to the ABI. Paolo