--- Comment #23 from charlet at gcc dot gnu dot org 2008-05-20 12:44
---
Subject: Bug 24533
Author: charlet
Date: Tue May 20 12:43:59 2008
New Revision: 135614
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135614
Log:
2008-05-20 Arnaud Charlet [EMAIL PROTECTED]
*
--- Comment #22 from danglin at gcc dot gnu dot org 2007-09-30 16:26
---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from danglin at gcc dot gnu dot org 2006-01-20 14:30
---
Subject: Bug 24533
Author: danglin
Date: Fri Jan 20 14:30:33 2006
New Revision: 110025
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110025
Log:
PR ada/24533
* s-osinte-linux-hppa.ads:
--- Comment #20 from danglin at gcc dot gnu dot org 2006-01-20 14:32
---
Subject: Bug 24533
Author: danglin
Date: Fri Jan 20 14:32:10 2006
New Revision: 110026
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110026
Log:
PR ada/24533
* s-osinte-linux-hppa.ads:
--- Comment #21 from danglin at gcc dot gnu dot org 2006-01-20 14:34
---
Subject: Bug 24533
Author: danglin
Date: Fri Jan 20 14:34:29 2006
New Revision: 110027
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110027
Log:
PR ada/24533
* s-osinte-linux-hppa.ads:
OK?
Assuming you add a proper ??? comment explaining why we use an alignment of
8 in this file (basically summarizing this PR), this is OK.
2006-01-16 John David Anglin [EMAIL PROTECTED]
PR ada/24533
* s-osinte-linux-hppa.ads: Reduce alignment of atomic_lock_t to 8.
--- Comment #16 from charlet at adacore dot com 2006-01-17 08:56 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
OK?
Assuming you add a proper ??? comment explaining why we use an alignment of
8 in this file (basically summarizing
--- Comment #17 from hainque at adacore dot com 2006-01-17 16:29 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
John David Anglin wrote:
As I understand the situation, fixing the above problem is quite involved.
Indeed. I have dug
--- Comment #18 from charlet at adacore dot com 2006-01-17 16:33 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
I'll let Arno state the definite approval.
As discussed live, I gave my OK this morning already, with the same comment
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-17
03:49 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
--- Comment #8 from hainque at adacore dot com 2006-01-03 16:25 ---
Subject: Re: FAIL: a85013b:
For most (if not all) s-osinte*.ads C type redeclarations, I believe it should
be sufficient to use a record containing a
System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an
alignement clause (I don't know if C or GNU C allows to retrieve the alignment
of a struct
--- Comment #12 from charlet at adacore dot com 2006-01-04 09:58 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
For most (if not all) s-osinte*.ads C type redeclarations, I believe it should
be sufficient to use a record containing a
--- Comment #13 from laurent at guerby dot net 2006-01-04 11:45 ---
(In reply to comment #12)
Arnaud, do you remember non opaque C types in s-osinte?
I do not understand your question, could you clarify ?
opaque means that the Ada runtime never access an internal C record
So my question is wether the record+storage array+align will work for all
the C types in s-osinte* or is there an exception (ie a non opaque C type)?
Now I understand your question ;-)
The answer is no, this approach can't be applied blindly to all C types.
This approach could most likely be
--- Comment #14 from charlet at adacore dot com 2006-01-04 11:54 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
So my question is wether the record+storage array+align will work for all
the C types in s-osinte* or is there an
--- Comment #4 from charlet at gcc dot gnu dot org 2006-01-03 13:28 ---
The bug is that the following line in s-osinte-linux-hppa.ads is wrong:
for atomic_lock_t'Alignment use 8 * 16;
The alignment clause takes *bytes*, not *bits*, so you need to use instead:
for
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-03
15:03 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
The alignment clause takes *bytes*, not *bits*, so you need to use instead:
for atomic_lock_t'Alignment
--- Comment #6 from charlet at adacore dot com 2006-01-03 15:10 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
and it doesn't fix the invalid tcb pointers being passed to free().
Reducing the alignment to 8, fixes the pointer
--- 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
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,
--- 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
--- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 ---
For most (if not all) s-osinte*.ads C type redeclarations, I believe it should
be sufficient to use a record containing a
System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an
alignement clause (I
--- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 ---
For most (if not all) s-osinte*.ads C type redeclarations, I believe it should
be sufficient to use a record containing a
System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an
alignement
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-03 19:31
---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
--- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 ---
For most (if not all)
--- Comment #11 from laurent at guerby dot net 2006-01-03 19:36 ---
(In reply to comment #7)
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
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-01
17:11 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
I've looked at the failure of a85013b.adb.
The problem seems to be that new is applying a kind of rounding
to
--- Comment #1 from danglin at gcc dot gnu dot org 2005-10-26 02:45 ---
Oops, somehow how ended up debugging in the wrong directory. However,
it has the same error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
--- Comment #2 from danglin at gcc dot gnu dot org 2005-10-26 04:00 ---
The same errors occur on the 4.0 branch using libc6 2.3.5-6.0.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
28 matches
Mail list logo
