[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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