[Bug ada/24533] 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: *** 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
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- 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 out the patches involved when this was first attempted, and look into them again. This was back in June 2004, so a lot has changed since then. > The problem is that the alignment provided by malloc is less than > that needed for atomic_lock_t objects. This causes the ada runtime > to round the pointer that it receives from malloc; but it doesn't > retain the adjustment and the free operation has a 50% chance of > failing. Close :) The problem as it currently stands is that the alignment required for atomic_lock_t is larger than BIGGEST_ALIGNMENT, which causes the compiler to generate special code to handle an allocation request from the default storage pool (aka bare malloc). Indeed the generated code arranges for the user visible address (the Ada allocator value) to be a multiple of the requested alignment by rounding up the malloc returned address, and the rounded value is erroneously passed back to free on deallocation request. > The enclosed change is a work-around for the above problem. > The linux libc code can accomodate an unaligned atomic_lock_t object > under most circumstances. The main issue is that ada may detemine > an incorrect struct layout. > > I have tested the above change on hppa-unknown-linux-gnu, 4.0 through > trunk. Without this change, ada is essentially unusable. Thus, I > recommend installing the change as a work-around until a proper fix > can be developed. > > OK? > - for atomic_lock_t'Alignment use 16; > + for atomic_lock_t'Alignment use 8; Since it definitely enhances the situation according to your testing (thanks), I'd go for it with a "???" accompaning comment. I'll let Arno state the definite approval. It is not easy to ensure it is really OK because of ripple effects. It appears fine from the local osinte perspective: << type lock_array is array (1 .. 4) of int; type atomic_lock_t is record lock : lock_array; end record; >> The base size is 16 bytes, and wouldn't change from an alignment upgrade to 16. << type struct_pthread_fast_lock is record spinlock : atomic_lock_t; >> The field is at beginning here so there is no offset rounding mistake to fear, and the size is right so following fields are laid out identically. Besides, in << type pthread_mutex_t is record m_reserved : int; m_count: int; m_owner: System.Address; m_kind : int; m_lock : struct_pthread_fast_lock; end record; >> the m_lock offset is a multiple of 16 here by virtue of the preceeding components (4 all 4 bytes long). Now, I think a 16 bytes alignment for atomic_lock_t would force a 16 bytes alignment for struct_pthread_fast_lock + pthread_mutex_t, and double checking the potential effects of that is fairly involved. Thanks for your feedback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/41100] [4.4/4.5 regression] Unchecked_Deallocation causes wrong free errors
--- Comment #17 from hainque at adacore dot com 2009-09-28 22:07 --- > I checked with gcc version 4.5.0 20090928 (experimental) [trunk revision > 152246] (GCC). > > I didn't test 4.4 but the patch should apply there too, no? Yes, and I just applied it. This is not a fullproof resolution of the general problem with tagged types, but makes sense overall and should get us back to the situation as it was in 4.3. The particular instance you were observing should definitely not cause trouble any more. Olivier -- hainque at adacore dot com changed: What|Removed |Added CC| |hainque at adacore dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41100
[Bug target/53271] powerpc-eabispe build fails with ice on unwind-dw2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53271 --- Comment #4 from hainque at adacore dot com 2012-05-09 08:52:01 UTC --- On May 9, 2012, at 10:18 , amodra at gmail dot com wrote: > --- Comment #3 from Alan Modra 2012-05-09 08:18:09 > UTC --- > fixed Indeed ! Thanks a lot Alan :-)
[Bug c/448] -related issues (C99 issues)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 --- Comment #41 from hainque at adacore dot com --- > On 2 Jan 2019, at 23:33, joseph at codesourcery dot com > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=448 > > --- Comment #40 from joseph at codesourcery dot com dot com> --- > The definitions have been added for VxWorks at some point. Yes, https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00761.html I think.
[Bug target/77687] frame access after release without redzone on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 --- Comment #4 from hainque at adacore dot com --- Thanks again for your help on this Segher! > On Jan 27, 2017, at 01:54 , segher at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 > > Segher Boessenkool changed: > > What|Removed |Added > > Known to work||7.0 > > -- > You are receiving this mail because: > You reported the bug.
[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470 --- Comment #14 from hainque at adacore dot com --- > On Dec 6, 2017, at 21:16 , rai...@emrich-ebersheim.de > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470 >> >> Confirmed, this patch solves the issue. >> >> Thanks > > Olivier, can we get the patch in, please? As soon as I get an approval for it :) https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02537.html will ping.
[Bug bootstrap/81470] [8 Regression] Bootstrap comparison failures in gcc/ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81470 --- Comment #15 from hainque at adacore dot com --- And thanks Rainer for having confirmed that it resolves the problem for you as well. > On Dec 6, 2017, at 23:54 , hainque at adacore dot com > wrote: > >>> Confirmed, this patch solves the issue. >>> >>> Thanks >> >> Olivier, can we get the patch in, please? > > As soon as I get an approval for it :) > > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02537.html > > will ping.
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From hainque at adacore dot com 2005-07-05 14:08 --- Subject: Re: [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed charlet at gcc dot gnu dot org wrote: > Hmm, so it means that there is no way for a compiler front-end to use GCC's > exception handling mechanism ? Humm, I guess it's even uncommon/unique-to-Ada to use exceptions in the compiler at all, isn't it ? > I would guess adding a #if IN_RTS around the unwind.h include would probably > solve this issue: > > #if IN_RTS > #include "unwind.h" > #endif > > Olivier, what do you think of the above ? I'm afraid conditioning the #include alone won't do, and need to check a couple of bits before commenting further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From hainque at adacore dot com 2005-07-06 13:30 --- Subject: Re: [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed pinskia at gcc dot gnu dot org wrote: > This patch fixed the problem I was having, thanks. :) Thanks for the test and feedback. I'll test on our internal suite and followup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From hainque at adacore dot com 2005-07-06 14:50 --- Subject: Re: [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed Olivier Hainque wrote: > I'll test on our internal suite and followup. Went fine on x86-linux, committing locally right away. We'll rapidly see if all goes well on of our other targets (no apparent reason why not), Thanks again for your feedback. Olivier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #11 from hainque at adacore dot com 2010-08-12 14:14 --- Subject: Re: pthread_default_stacksize_np failed. dave at hiauly1 dot hia dot nrc dot ca wrote: > The function is present in libc.sl on my PA HPUX 11.00 system. Hmm, not here. There are many more pthread_ entries in libc.sl than in libc.a, but not this one. > Possibly, this can be fixed by updating your libc version. > However, I just noticed that there is no libc stub for > pthread_default_stacksize_np in libc.a. Right, it's not here either for us (B.11.00 U 9000/785 2008571012). > Are you doing a static link? Not entirely (according to the logs, we link with libc.sl and libgcc*.a). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #12 from hainque at adacore dot com 2010-08-12 14:18 --- Subject: Re: pthread_default_stacksize_np failed. [Thanks for your prompt feebdack Dave :-)] dave at hiauly1 dot hia dot nrc dot ca wrote: > It appears pthread_default_stacksize_np was added to libc in PHCO_30531 > on 11.23. PHCO_29955 seems relevant as well ( SR:8606338169 CR:JAGae99143 ) Unable to resolve pthread_default_stacksize_np(3T) symbol due to the lack of stub in libc when not linked to pthread library. We probably could update our system and document but I don't know what to think of the more general user base (whether many could possibly be affected). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #13 from hainque at adacore dot com 2010-08-12 14:24 --- Subject: Re: pthread_default_stacksize_np failed. hainque at adacore dot com wrote: > PHCO_29955 seems relevant as well This was for 11.11. For 11.00, this is part of PHCO_29956. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #16 from hainque at adacore dot com 2010-08-13 10:14 --- Subject: Re: pthread_default_stacksize_np failed. dave at hiauly1 dot hia dot nrc dot ca wrote: > I think the answer is to provide a stub for pthread_default_stacksize_np > which is linked in last in final executables. I believe the function is > always present in the pthread libraries, both shared and archive. We > already do similar things for a number of functions on hppa64-hpux11. Hmm, certainly worth an attempt. We were caught by subtle bugs with similar attempts on other platforms in the past, like "stub added to lib X, and corner case situation Bla leads to a link order that gets us the stub instead of the real implementation in multi threaded apps". That's probably settled by now :) We're discussing the options internally. Thanks much for your feedback. Olivier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #21 from hainque at adacore dot com 2010-08-16 07:42 --- Subject: Re: pthread_default_stacksize_np failed. dave at hiauly1 dot hia dot nrc dot ca wrote: > Because of these issues, I have decided to revert the change on the > branches (probably tomorrow). I will also try to add the stub on > the trunk. Understood, thanks. Sounds like a sensible track to me. We're considering upgrading our system since the patches are pretty old by now, part of a bundle advertised as critical, and our direct set of potentially affected customers is not large. Plus doing it ourselves will get us experience in possible fallouts etc. Cheers, Olivier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612 --- Comment #17 from hainque at adacore dot com 2010-09-30 09:23:25 UTC --- ro at gcc dot gnu.org wrote: > Eric, Olivier, > could you please have a look at Jan's question in Comment #6? This > bug currently breaks Ada bootstrap on Solaris 2/SPARC and hampers my > Solaris testing. I'll see if I can get at something with a cross (faster to build), but please don't give up other tracks as I have very limited bandwidth for this right now. Olivier
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612
--- Comment #21 from hainque at adacore dot com
2010-10-01 22:11:52 UTC ---
hubicka at gcc dot gnu.org wrote:
> We might be missing some code in inliner that passes the fact that
> the label is user label...
I don't yet have a clear track here, but can provide a pretty easy
way to reproduce with a cross and get starters for further analysis:
$ configure --target=sparc-sun-solaris2.10 --enable-languages=c,ada
--disable-libada --disable-bootstrap
$ make CFLAGS="-O0 -g"
...
let it fail when it gets to C parts of runtime libraries.
you should have gnat1 at this stage. then ...
$ cd gcc
$ make -C ada ../stamp-gnatlib1-rts
this prepares the runtime library source symlinks in ada/rts. now:
$ ./gnat1 -Iada/rts ada/rts/g-debpoo.adb -O2 -fdump-tree-all -da
the anomaly is visible in the output, in particular in one call
to debug_pools__put_line from the code for 'Dereference'
gnat__debug_pools__dereference__2:
...
ld [%g1+%lo(gnat__debug_pools__code_address_for_dereference_end)], %o4
...
sethi %hi(.LL544), %o3
...
callgnat__debug_pools__put_line, 0
or %o3, %lo(.LL544), %o3
LL544 is nowhere for me.
From a quick glance, this one of the calls to Put_Line in
<>
if not Valid then
if Pool.Raise_Exceptions then
raise Accessing_Not_Allocated_Storage;
else
Put (Output_File (Pool),
"error: Accessing not allocated storage, at ");
Put_Line (Output_File (Pool), Pool.Stack_Trace_Depth, null,
Dereference_Label'Address,
Code_Address_For_Dereference_End);
end if;
else
Header := Header_Of (Storage_Address);
if Header.Block_Size < 0 then
if Pool.Raise_Exceptions then
raise Accessing_Deallocated_Storage;
else
Put (Output_File (Pool),
"error: Accessing deallocated storage, at ");
Put_Line
(Output_File (Pool), Pool.Stack_Trace_Depth, null,
Dereference_Label'Address,
Code_Address_For_Dereference_End);
which indeed passe the address of the <> code
label.
Compiling -da then grep suggests that the label disappears as of
ada/rts/g-debpoo.adb.153r.vregs:
(code_label/s 12 11 13 4 538 ("dereference_label") [4 uses])
ada/rts/g-debpoo.adb.154r.into_cfglayout:
(note/s 12 11 14 2 ("dereference_label") NOTE_INSN_DELETED_LABEL 538)
This is still very rough and obviously needs further investigation, but
yields starters.
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #8 from hainque at adacore dot com 2010-11-29 09:17:03 UTC --- dje at gcc dot gnu.org wrote: > Has anyone reported this AIX assembler behavior to IBM? It would be > much more effective coming from an external customer than from me. We haven't done that on our side. We haven't observed the 64K limit. We had observed the 0 case and thought it was legitimate to consider this invalid, so came up with a change close to what was suggested upthread, with comments on their possible origin after investgation. (attached) I can provide a testcase that triggered on 4.5 at least. Olivier
[Bug target/46655] invalid '.line 0' directive emitted with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655 --- Comment #13 from hainque at adacore dot com 2010-11-30 17:49:20 UTC --- dje at gcc dot gnu.org wrote: > Did something change in GCC that now generates line 0 debug > information? For Ada cases, we had mixups with BUILTINS_LOCATION. The testcase below triggered it for entirely different reasons in C with at least 4.5, and supposedly on. While there are multiple factors at play, I think one triggering piece was a change issued from http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00649.html In particular: --- c-parser.c(revision 140120) +++ c-parser.c(working copy) @@ -1301,9 +1301,9 @@ c_parser_declaration_or_fndef (c_parser while (c_parser_next_token_is_not (parser, CPP_EOF) && c_parser_next_token_is_not (parser, CPP_OPEN_BRACE)) c_parser_declaration_or_fndef (parser, false, false, true, false); - DECL_SOURCE_LOCATION (current_function_decl) -= c_parser_peek_token (parser)->location; store_parm_decls (); + DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus += c_parser_peek_token (parser)->location; for "__frame_state_for" at line 9 in the example below, we used to have saved[reg] = 0; 15 } 16
[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test
--- Comment #1 from hainque at adacore dot com 2007-11-23 17:11 --- Subject: Re: New: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test andreasmeier80 at gmx dot de wrote: > gnat.dg/release_unc_maxalign.adb execution test fails for me since > 20.11.2007. At 19.11.2007 it whas worked. Thanks for opening the PR. We have identified what is causing this and are qualifying a candidate fix. This is an old bug actually, showing up on this recently added testcase exercising the fix for another issue. Cheers, Olivier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34173
[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test
--- Comment #3 from hainque at adacore dot com 2007-11-25 08:43 --- Subject: Re: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test > ebotcazou at gcc dot gnu dot org changed: > >What|Removed |Added > > AssignedTo|unassigned at gcc dot gnu |hainque at adacore dot com Thanks. I tried to do that yesterday and was refused the privilege. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34173
[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test
--- Comment #6 from hainque at adacore dot com 2007-11-26 12:02 --- Subject: Re: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test pinskia at gmail dot com wrote: > Have you tried your @gcc.gnu.org account? Humm, no. I tried the login/password combination sent to me more than two years ago :) I'm obviously not very used to doing these operations and will give my @gcc.gnu.org a try. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34173
[Bug ada/34173] [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test
--- Comment #9 from hainque at adacore dot com 2007-12-07 11:08 --- Subject: Re: New: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb execution test Hello, andreasmeier80 at gmx dot de wrote: > gnat.dg/release_unc_maxalign.adb execution test fails for me since > 20.11.2007. At 19.11.2007 it whas worked. This should be fixed now. Analysis at http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00318.html Thanks again for opening the PR. Olivier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34173
[Bug middle-end/29609] [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
--- Comment #6 from hainque at adacore dot com 2007-12-19 08:30 --- Subject: Re: [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug Hi Steven, steven at gcc dot gnu dot org wrote: > xf. http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01789.html > > I was wrong to object to this patch No problem, and many thanks for getting back to us on this issue. What really matters is feedback/discussion IMO, and your comments had us look for better ways to perform the task. This is a positive outcome even if we haven't (yet) pushed further for an inclusion into the FSF tree. > there really doesn't seem to be any other way. It's funny, on the > one hand we complain about the code quality of -O0, but on the other > we have to do quite silly things such as adding jumps to jumps to > keep rather important debug information around... Right. We have several constraints at play (want to debug, want the ability to debug (-g) not to modify the generated code, and want to limit generated code bloats), and it's not always possible to progress on one aspect without effects on the others. I like the recently suggested "-Og" idea because it offers a way through. > Olivier, any chance someone at AdaCore can pick this up and re-submit it to > gcc-patches? We can definitely resubmit the current version we have (I copied the author). Thanks again for your feedback, Olivier -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
[Bug middle-end/29609] [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
--- Comment #7 from hainque at adacore dot com 2007-12-19 10:06 --- Subject: Re: [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug Olivier Hainque wrote: > We can definitely resubmit the current version we have (I copied the > author). Thanks again for your feedback, Actually, there was another related submission at http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00099.html There was an interesting exchange with Richard Guenther there, which didn't quite reach a conclusion at the time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
