Weird error in tla package

[Josh Boyer]

On Fri, 2006-02-24 at 10:45 +0000, David Woodhouse wrote:
> On Thu, 2006-02-23 at 20:31 -0500, Josh Boyer wrote:
> > I'm getting a weird error when trying to build the tla package from
> > Extras on PPC.  I haven't done too much digging yet, but I thought I
> > would ask in case the symptoms ring a bell for some reason.
> > 
> > Basically, it fails with this:
> > 
> > ================ unit-ar tests ================
> > /home/jwboyer/rpm/BUILD/tla-1.3.3/src/hackerlab/tests/arrays-tests/unit-ar.c:53:botched invariant
> >     0 == ((unsigned long)ar & (16 - 1))
> > PANIC: exiting on botched invariant
> > 
> > What is weird is where that '16' comes from.  It's coming from a #define
> > called MACHINE_ALIGNMENT which seems to be a computed value of some
> > kind.  On my x86 box, it's #defined to 4.  When building on PPC, it's
> > #defined to 16.
> > 
> > If the macro really does what it says it does, then I have to go figure
> > out why the test is failing.  And it doesn't help that this code makes
> > my head hurt.  But is the alignment on a PPC box really 16 bytes?
> > 
> > josh
> 
> MACHINE_ALIGNMENT is the maximal alignment of various types, including
> 'long double'. That's recently changed from 8 bytes to 16. Could it be
> that malloc() or your own internal allocation routines are still
> returning chunks which are only 8-byte aligned?

Ah...  that was the recent ABI change that caused rawhide to be respun a
bit ago, right?

It could be doing what you say.  The code to generate the macro is
convoluted so I'll need to figure it out.  If anyone cares, the code is
in the tla package at src/hackerlab/machine/gen-alignment.to-c (which
gets turned into a .c file at build time).  And the code for the test
that's failing is in src/hackerlab/tests/array-tests/unit-ar.c.

When I find some time I'll try an figure it all out.  In the meantime,
I'll just continue cursing tla ;).

josh