On Fri, 2006-02-24 at 05:53 -0500, Josh Boyer wrote:

On Fri, 2006-02-24 at 10:45 +0000, David Woodhouse wrote:

...

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 ;).

I did some more digging and it turns out that malloc() _is_ returning chunks that are only 8-byte aligned. See:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182742

for the details on tla itself, but I can reproduce 8-byte aligned addresses with the trivial program below. From my understanding of the recent ABI change, this shouldn't happen.

Jakub, do you want me to open a bug for this?

josh

[jwboyer@net2-102 ~]$ gcc -o malloc-check malloc-check.c [jwboyer@net2-102 ~]$ ./malloc-check foo is not 16-byte aligned: 10011008 [jwboyer@net2-102 ~]$

#include <stdio.h> #include <stdlib.h>

int main(int argc, char **argv) { void *foo = NULL; void *bar = NULL; int i;

for (i = 0; i < 1000; i++) { foo = malloc(360); bar = malloc(360);

if ((unsigned long) foo & 0xf) { printf("foo is not 16-byte aligned: %lx\n", (unsigned long) foo); return -1; } if ((unsigned long) bar & 0xf) { printf("bar is not 16-byte aligned: %lx\n", (unsigned long) bar); return -1; }

if (i % 150) { free(foo); free(bar); foo = NULL; bar = NULL; } }

return 0; }