[Bug target/17180] [3.4 Regression] nearly all g77 tests fail

[bdavis9659 at comcast dot net]

------- Additional Comments From bdavis9659 at comcast dot net  2004-08-31 10:39 -------
Subject: Re:  [3.4 Regression] nearly all g77 tests fail

On Tue, 2004-08-31 at 01:37, ebotcazou at gcc dot gnu dot org wrote:
 
> 
> 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).



my intention was that sizeof(mallocArea_*) was the size of a pointer to
mallocArea, so it should be either 4 or 8 depending on the system, which
IMHO should have worked...it is obvious there is something going on here
which i do not understand (not an uncommon occurrence :)

the changes to malloc.c and malloc.h are independent to the other files
in the patch.   they can be reverted and the original focus of the patch
(slow compilation of block data) is still intact.  


some info that may help debugging:

profiling showed that malloc_find_inpool was the biggest cpu consumer
while compiling large fortran files.  the intent was to store a pointer
to the mallocArea at the beginning of every memory block, thus a
malloc_find_inpool would not have to search a list, just return a
pointer.  this implementation meant that the using routines did not
receive the malloc'd pointer, but ptr + sizeof(mallocArea*).



--bud davis



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17180