------- Comment #8 from hainque at adacore dot com 2006-01-03 16:25 ------- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
charlet at adacore dot com wrote: > Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Yes, the latter is 8, computed from GCC's BIGGEST_ALIGNMENT. > Is it really the case that the C headers mandate an alignment of 16 for this > type which is not guaranteed by malloc ? IIUC, it asks for a 16 bytes alignment consciously knowing that it likely won't get it in terms of objects' _addresses_. Now the request will still impact component _offsets_ within records (make them multiple of 16), as Dave points out, and not matching it in Ada might indeed cause various troubles. The big difference between Ada and C here is that the alignment must also be obeyed for objects addresses in Ada, which is why the allocator return address is rounded up (together with the size argument). > > If ada is going to align malloc'd pointers, then it should keep track > > of the adjustment or the original pointer so that the memory can be > > freed using the original pointer. > > Right, and this is a non trivial task, hence my previous comment. Right. Preliminary attempts at fixing this a while ago made it necessary to touch expand_expr and is_alignin_offset, fairly deep in the back end. Will look it up again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
