From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13779 invoked by alias); 29 Mar 2011 14:57:13 -0000 Received: (qmail 13768 invoked by uid 22791); 29 Mar 2011 14:57:12 -0000 X-SWARE-Spam-Status: No, hits=-2.5 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-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Mar 2011 14:57:07 +0000 Received: by bwz5 with SMTP id 5so273500bwz.20 for ; Tue, 29 Mar 2011 07:57:06 -0700 (PDT) Received: by 10.204.22.202 with SMTP id o10mr5094048bkb.70.1301410626125; Tue, 29 Mar 2011 07:57:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.15.81 with HTTP; Tue, 29 Mar 2011 07:56:46 -0700 (PDT) In-Reply-To: References: <4D9065FD.6060100@gnu.org> <4D9072B3.708@gnu.org> <4D908EF0.1040302@gnu.org> From: Nathan Boley Date: Tue, 29 Mar 2011 16:03:00 -0000 Message-ID: Subject: Re: Possible Bug To: Richard Guenther Cc: Paolo Bonzini , Michael Matz , Ian Lance Taylor , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00480.txt.bz2 >>> As some digging shows, already GCC 1.35 had effectively the same code. >>> As soon as parameters are passed in registers GCC loads the parts fitti= ng >>> into registers as full words. =A0We could simply sorry() for these case= s, as >>> they never worked correctly. =A0Though I suppose that's quite unforgivi= ng, >>> as most of the time (struct in question not passing page border) it wor= ks >>> fine. >> >> We should warn, I think. > > We should fix the bug ;) Agreed ;-) FWIW, this was particularly nasty because it was serious ( the segfault lost more than a days work on a couple of occasions ) and it was very very difficult to track down due to the fact that: 1) the read rarely crosses the page boundary. ( as others have noted ) 2) seemingly trivial changes to the struct that didn't change the alignment or the size would "fix" it 3) storing the data to an intermediate variable would "fix" it Also, for some context, in my real application I am using packed arrays of these ( so aligning each to the word boundary would be pretty worthless ) and the bitfield is still 6 bytes but quite a bit more complex ( copied below ). Thank you all very much for the comments and the feedback. I am sorry that my original report couldn't be more definitive. Best, Nathan Boley #define CHR_BITS 15 #define LOCATION_BITS 28 #define MAX_NUM_SNPS 3 typedef struct __attribute__((__packed__)) { /* 1 if it covers at least 1 snp */ unsigned covers_snp :1; unsigned snp_coverage :MAX_NUM_SNPS; /* read_type 0 =3D normal, 1 =3D junction */ unsigned read_type :1; /* the chr that the read came from */ unsigned chr :CHR_BITS; /* * Start of the sequence in the 5' direction - * so a read of length L that maps here covers * bps (loc, loc+1, ..., loc+L-1) */ unsigned loc :LOCATION_BITS; } GENOME_LOC_TYPE;