GCC endless loop for store_bit_field with alignment 0

[Geoff Keating]

> cc: gcc-bugs@gcc.gnu.org, rth@cygnus.com
> Date: Thu, 10 Aug 2000 20:02:20 -0400
> From: David Edelsohn <dje@watson.ibm.com>
> 
> >>>>> Geoff Keating writes:
> 
> Geoff> The problem is that DECL_FIELD_OFFSET_ALIGN overflows, because it's
> Geoff> only an 8-bit-wide bitfield in the tree structure.  I posted a patch to
> Geoff> store this field as a power of two, giving alignments of up to 2^256,
> Geoff> which ought to be enough.
> 
> 	Why are such large alignments necessary?  The largest alignment
> that one ever needs is BIGGEST_ALIGNMENT which is less than 256 on all
> targets (128 is the largest that I see).  A pervasive change to
> powers-of-2 now does provide headroom when we port GCC to 128-bit
> processors. 

I can easily see someone implementing a custom handcoded database and
wanting alignment of some data structure to page boundaries:

/* This is a cache in RAM/swap of the top three levels of the B* trees
   on the primary and secondary keys.  */
#define PAGESIZE 4096
#define MAX_NITEMS (PAGESIZE/sizeof (struct item) - 1)
struct btree {
  int nitems;
  struct item items[MAX_NITEMS];
} __attribute__ ((aligned(PAGESIZE));

struct {
  struct btree one;
  struct btree two[MAX_NITEMS];
  struct btree three[MAX_NITEMS * MAX_NITEMS];
} primary, secondary;

I don't think that anyone would really use, say, a 2^32 alignment on a
64-bit processor, but the current field size can't even handle 256
bits which is the size of a cache line on some processors. 

One thing I wasn't sure of is if DECL_OFFSET_ALIGN is only for
optimisation and so we could clip it to BIGGEST_ALIGNMENT, that
correctness is ensured by DECL_ALIGN which is 24 bits wide.  However,
I'm not sure that in the future we'd never want to make
BIGGEST_ALIGNMENT 256 bits, so I decided it didn't matter.

IIRC, the reason that I stored the field a power of 2 was simply to
avoid making the 'tree' structure larger; apparently trees account for
much of the C++ compiler's memory consumption.
-- 
- Geoffrey Keating <geoffk@cygnus.com>