Re: Possible Bug

[Nathan Boley <npboley@gmail.com>]

>>> 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 fitting
>>> into registers as full words.  We could simply sorry() for these cases, as
>>> they never worked correctly.  Though I suppose that's quite unforgiving,
>>> as most of the time (struct in question not passing page border) it works
>>> 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 = normal, 1 = 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;