------- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-08-31 06:36 ------- > http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01136.html > That was easy to find.... (using google).
You're the best :-) I was desperately searching my mailbox with "davis"... Anyway, I think the patch is flawed because it does pointer frobbing here: @@ -388,6 +377,7 @@ malloc_new_inpool_ (mallocPool pool, mal void *ptr; mallocArea_ a; unsigned short i; + mallocArea_ *temp; if (pool == NULL) pool = malloc_pool_image (); @@ -397,11 +387,14 @@ malloc_new_inpool_ (mallocPool pool, mal || malloc_pool_find_ (pool, malloc_pool_image ())); #endif - ptr = malloc_new_ (s + (i = (MALLOC_DEBUG ? strlen (name) + 1 : 0))); + ptr = malloc_new_ (sizeof(mallocArea_*) + s + (i = (MALLOC_DEBUG ? strlen (name) + 1 : 0))); #if MALLOC_DEBUG strcpy (((char *) (ptr)) + s, name); #endif a = malloc_new_ (offsetof (struct _malloc_area_, name) + i); + temp = (mallocArea_ *) ptr; + *temp = a; + ptr = ptr + sizeof(mallocArea_*); switch (type) { /* A little optimization to speed up killing of non-permanent stuff. */ What happens is that we allocate a new 'ffesymbol' in symbol.c:ffesymbol_new_: ffesymbol s; s = malloc_new_ks (FFESYMBOL_SPACE_POOL_, "FFESYMBOL", sizeof (*s)); The structure 'ffesymbol' contains the field 'accretes' whose type is defined as 'ffetargetOffset', which is actually 64-bit 'long long' on SPARC. So the structure gets 8-byte alignment (BIGGEST_ALIGNMENT is 64). When the system malloc is invoked, it returns a 8-byte aligned address; but then ptr = ptr + sizeof(mallocArea_*); destroys the alignment (ptr==0x439cdc) and the compiler dies because it is trying to do a 8-byte store to an unaligned address (ptr + 0x48). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180 ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.