------- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-03 15:49 ------- Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
> Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment... Unfortunately, yes. The fundamental issue is that "ldcw" is the only atomic memory operation available in PA 1.x, and it requires a 16-byte alignment. In PA 2.0, this is relaxed to 4-byte alignment when the operation is coherent. The linux folks weren't willing to to throw out their PA 1.1 hardware, so we have this 16-byte alignment... > Is it really the case that the C headers mandate an alignment of 16 for this > type which is not guaranteed by malloc ? These alignment issues are > very tricky, and GCC also has several notions of maximum alignments, so > this are is definitely of that is causing many troubles with Ada when using > GCC 3.x or 4.x Agreed. Because of these issues, I came up with the scheme to make the size of the atomic_lock_t type 16 bytes. The pthread code dynamically picks the aligned 4-byte integer for the ldcw. Thus, the atomic_lock_t type now only needs 4-byte alignment. However, the 16-byte alignment attribute was retained for compatibility. There are some limitations to this scheme and I think the TLS thread implementation will do locking with a light-weight syscall rather than ldcw. This might reduce the alignment requirement to 4 bytes. > Ada does not do anything with these directly, so things should be OK, > except that it's easy to get a subtle alignment issue/discrepency. > > > 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. Ok, then I think the alignment should be reduced to 4 or 8. I've done a number of builds using an alignment of 8. There's only one fail in 4.0.3: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00025.html RUN cxg1005 ,.,. CXG1005 ACATS 2.5 06-01-01 01:38:37 ---- CXG1005 Check that the subprograms defined in the package Generic_Complex_Elementary_Functions provide correct results. * CXG1005 Non-imaginary result from Function Log with a minus one input value. * CXG1005 Non-real result from Function Arcsin with a minus one input value. * CXG1005 Non-real result from Function Arccos with a minus one input value. **** CXG1005 FAILED ****************************. FAIL: cxg1005 I checked the first issue in C and clog(-1.0) seems ok. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
