[Bug ada/112446] Switch -gnatyz included in -gnatyg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112446 --- Comment #1 from charlet at adacore dot com --- > "gnatmake --help" states that -gnatyg is equivalent to -gnatydISux, but > in fact the new switch -gnatyz (check parentheses not required by operator > precedence rules) is included. > > If this is deliberate, the help information should say so. This is indeed deliberate, thanks for reporting! Arno
[Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69883 --- Comment #3 from charlet at adacore dot com --- > I could understand that I can not build something form 1992 with todays > tools, but what I do not understand conceptionally, why the host compiler > seems to link with the target compiler's runtime, would it work as a > cross build then? No, for a cross build you need an identical native compiler (same version) to start with. For native you need an older (or equal) compiler. > Could I even get into trouble building gcc4.9 with gcc-5 as host? Yes. Arno
[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205 --- Comment #5 from charlet at adacore dot com charlet at adacore dot com --- I???ve managed to make what I think is a very-low-quality workround by (a) not suppressing the standard library on the target in system.ads (b) including a C source file in the RTS which provides dummies for the irrelevant-in-this-context __gl_* objects which bindgen now references. Anyway, now I have my copyright assignment in place, I???ll submit the patch. I???m not sure what regression tests would be appropriate: I propose to apply the patch and bootstrap/make check-ada for Darwin, that will show I haven???t broken the normal case, and I can repeat the build for arm-eabi and build a null main program. If there???s no chance that this patch will ever be accepted, please let me know before I embark on this! Certainly a very low quality workaround won't be accepted, this would cause too much maintenance troubles. Arno
[Bug ada/64492] Disabling libada prevents building gnattools-cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64492 --- Comment #7 from charlet at adacore dot com charlet at adacore dot com --- Unfortunately you can???t build the cross gnattools, because --disable-libada adds gnattools to the list of unconfigured directories, which means that the directory gcc/ada/tools is never created, let alone populated. gcc/ada/gcc-interface/Makefile.in touches stamp-tools, but that???s all. You can actually. The way to build gnattools when using --disable-libada is to do: obj $ make -C gcc cross-gnattools ada.all.cross Arno
[Bug ada/60411] ADA bootstrap failure on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60411 --- Comment #7 from charlet at adacore dot com charlet at adacore dot com --- the cross build for arm-linux-gnueabihf succeeds again. Great. So they use the same system.ads, which now links with a-exexpr-gcc.adb; Should'nt this target now also use EH_MECHANISM=-gcc or -arm? Yes, android should also use EH_MECHANISM=-arm I'll make that change.
[Bug tree-optimization/60174] [4.9 regression] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 --- Comment #18 from charlet at adacore dot com charlet at adacore dot com --- ./gcc/xgcc -Bgcc -S cc3305a.adb -O2 -I gcc/ cc3305a.adb:74:11: run-time library configuration error cc3305a.adb:74:11: file s-soflin.ads not found cc3305a.adb:74:11: entity System.Soft_Links.Abort_Undefer not available compilation abandoned at which point I need to add -I gcc/ada/rts but then the testcase works. /abuild/rguenther/trunk-g ./gcc/xgcc -Bgcc -S cc3305a.adb -O2 -I gcc/ -I gcc/ada/rts /abuild/rguenther/trunk-g You need to use -I . -I gcc/ada/rts (and no -I gcc/) Arno
[Bug tree-optimization/60174] [4.9 regression] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 --- Comment #20 from charlet at adacore dot com charlet at adacore dot com --- Same result (system.ads and rep*.adb were in gcc/, but even moving them to $builddir and using -I. doesn't work). Same result == testcase passes. Maybe I have to rebuild gnat1 using that modified system.ads? Even No, you don't need to do that, gnat1 reads system.ads at run time. Assuming you have done a make install, then under the directory where you've done the gnatchop and copy of system.ads, it should really be a trivial matter of: gcc -c test case.adb Nothing more nothing less. (You can then of course debug using gnat1 once you can reproduce with the above). Arno
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #10 from charlet at adacore dot com charlet at adacore dot com --- well, I don't know if the Finalize method are supposed to be called in a sequential manner, which GNAT does obviously not guarantee. But how about this, for a fix? That can't be a fix, only a workaround hiding a potential issue. Your patch is completely changing the semantic and purpose of the test, which is basically equivalent to removing the test altogether. Furthermore, you can't put a delay statement inside a protected procedure, it's a potentially blocking operation. Arno
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 --- Comment #12 from charlet at adacore dot com charlet at adacore dot com --- What is the test supposed to do? Looks at the top of c761007.a, you'll find answers to this question. could you explain, why the test fails when the delay is added to the unmodified test case? Sorry, I'm not following you here, I do not know which delay you would add where (and why). Arno
[Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645 --- Comment #3 from charlet at adacore dot com charlet at adacore dot com --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Sure, but you can just skip the testcase like on Darwin. It is not! I was about to open a PR for it: Actually the new output is as expected since types are now accepted (in addition to objects), I just forgot to update the test after changes made this week, now done. This won't make a difference for this PR though, since the issue is unrelated to this week's changes. Arno
[Bug ada/57188] [4.9 regression] Ada bootstrap broken on Solaris/x64: No_Implicit_Dynamic_Code violation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57188 --- Comment #7 from charlet at adacore dot com charlet at adacore dot com --- * gcc-interface/Makefile.in (targ): Fix target name check. Having to deal with the target_alias instead of the canonical form found in target seems rather counterintuitive and fragile to me. The ChangeLog entry is misleading, neither Pascal nor I have anything to do with the change. Yes, this is very fragile and has already caused various issues. This seems to argue for reverting or at least reworking the change. I suppose I'll withhold my patch until it's decided how to proceed. This change is useful for many cross configurations which have similar names, so I would suggest you post your patch to gcc-patches@. Your patch is pre-approved FWIW, so feel free to apply it. Arno
[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54820 --- Comment #4 from charlet at adacore dot com charlet at adacore dot com 2012-10-09 08:34:03 UTC --- On that machine, the entire user-space is built without any static libstdc++ libraries, so it's quite annoying (and unexpected) to have to install them for Ada bootstrap. Couldn't Ada use the g++/libstdc++ bits from the compiler being built? That would probably be better indeed, it's dangerous to rely on the base compiler too much, in particular when the base compiler is a C++ compiler. This whole switch to C++ is causing all sort of subtle troubles in particular wrt building GNAT, so if people who worked on the switch could have a look and suggest a change, I'll be happy to review it. Arno
[Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54820 --- Comment #6 from charlet at adacore dot com charlet at adacore dot com 2012-10-09 13:09:38 UTC --- On that machine, the entire user-space is built without any static libstdc++ libraries, so it's quite annoying (and unexpected) to have to install them for Ada bootstrap. Couldn't Ada use the g++/libstdc++ bits from the compiler being built? No, this is stage 1 so the libstdc++ of the base compiler must be used. Well, we could first build g++ and libstdc++, and then Ada I guess, but that's probably too ambitious. In the end, requiring a static libstdc++ is probably overzealous and should be dropped. Annoying for other reasons, but fine with me, feel free to make that change. Arno
[Bug ada/49944] [4.5/4.6/4.7 regression] Bootstrapping on x86_64-pc-kfreebsd-gnu fails with s-taprop.adb:856:10: pthread_attr_setaffinity_np is undefined (more references follow)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49944 --- Comment #1 from charlet at adacore dot com charlet at adacore dot com 2011-08-02 10:51:19 UTC --- This is because GNU/kFreeBSD uses s-taprop-linux.adb, which uses subprograms Well, then that's the bug: kFreeBSD should cheat and try to reuse linux files, that's bound to cause this kind of error. Arno
[Bug ada/49944] [4.5/4.6/4.7 regression] Bootstrapping on x86_64-pc-kfreebsd-gnu fails with s-taprop.adb:856:10: pthread_attr_setaffinity_np is undefined (more references follow)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49944 --- Comment #2 from charlet at adacore dot com charlet at adacore dot com 2011-08-02 10:53:47 UTC --- This is because GNU/kFreeBSD uses s-taprop-linux.adb, which uses subprograms Well, then that's the bug: kFreeBSD should cheat and try to reuse linux Sorry, I meant of course shouldN'T cheat files, that's bound to cause this kind of error.
[Bug ada/49940] [4.5/4.6/4.7 regression] Bootstrapping on x86_64-pc-kfreebsd-gnu fails with s-taprop.adb:717:32: lwp_self is undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49940 --- Comment #1 from charlet at adacore dot com charlet at adacore dot com 2011-08-02 13:46:01 UTC --- The function __gnat_lwp_self exists in adaint.c only #if defined(linux), so it may not apply to kfreebsd-*. The problem exists because kfreebsd-* uses s-osinte-kfreebsd-gnu.ads, which does not import the function, but also uses s-taprop-linux.adb, which does use the function. (Note that s-taprop-posix.adb also calls lwp_self). I am not sure what to do: * introduce a new file s-taprop-kfreebsd-gnu.adb? * provide the function __gnat_lwp_self also on kfreebsd-* and import it in s-osinte-kfreebsd-gnu.ads? Better would be to use s-taprop-posix.adb, that would avoid relying on non portable code and would require minimal maintenance.
[Bug ada/49944] [4.5/4.6/4.7 regression] Bootstrapping on x86_64-pc-kfreebsd-gnu fails with s-taprop.adb:856:10: pthread_attr_setaffinity_np is undefined (more references follow)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49944
--- Comment #4 from charlet at adacore dot com charlet at adacore dot com
2011-08-02 17:42:05 UTC ---
I would not be so assertive as Arno.
Really? As the person who wrote this file and as the main tasking expert
of GNAT, I think I can be so assertive on this topic.
It seems to me (but I may be wrong) that
s-taprop-linux.adb really only calls glibc and libpthread, not the
kernel, and
therefore should be called s-taprop-glibc.adb. It looks like the
kernel-specific calls are all in
s-osinte-{linux,freebsd,kfreebsd-gnu}.ads,
No, s-taprop-linux.adb is only meant to be used under Linux and only
guaranteed to work under linux.
Using this file on non linux systems is bound to cause troubles and is not a
good idea.
If you're looking for a file shared among several platforms with a known
API, then as I said, using s-taprop-posix.adb is the way to go. That's what
I would do anyway if I were to port GNAT to kfreebsd properly.
Arno
[Bug ada/47717] building library for arm-none-eabi causes internal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47717 --- Comment #6 from charlet at adacore dot com charlet at adacore dot com 2011-03-21 14:44:20 UTC --- Just so we know, should it be possible to build libgnat.a using a project file via gnatmake? No, project files aren't designed to do that out of the box, libgnat.a is a special library. Arno
[Bug ada/42368] ada/cio.c uses common names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42368 --- Comment #2 from charlet at adacore dot com charlet at adacore dot com 2011-02-09 07:43:15 UTC --- Ping on this. Would a patch be OK? Depending on the patch, yes.
[Bug ada/36939] Build Failure Ada SH2e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939 --- Comment #17 from charlet at adacore dot com charlet at adacore dot com 2011-02-07 09:04:18 UTC --- With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds Ada. Is this OK to commit? Note that the proper place to submit a patch officially is gcc-patches. In any case, adding s-scaval-sh.adb isn't OK, s-scaval.adb isn't meant to have target specific implementations, or stubbed implementation, that's a kludge which is not really acceptable for mainstream. Arno
[Bug ada/42153] s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216
--- Comment #1 from charlet at adacore dot com 2009-11-23 07:44 --- Subject: Re: New: s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216 Laurent, This one is for you, caused by revision 154407 (you should also double check other linux implementations for similar issues). TIA. /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc -4.5.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11 /lib/ -isystem /opt/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/include -isystem /op t/gnu/gcc/gcc-4.5.0/hppa2.0w-hp-hpux11.11/sys-include-c -g -O2 -fPIC -frand om-seed=fixed-seed -W -Wall -gnatpg s-osinte.adb -o s-osinte.o s-osinte.adb:46:21: missing body for To_Duration declared at s-osinte.ads:216 s-osinte.adb:46:21: missing body for To_Timeval declared at s-osinte.ads:219 make[7]: *** [s-osinte.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42153
[Bug ada/37309] tasking is not implemented on NetBSD
--- Comment #13 from charlet at adacore dot com 2009-11-17 08:19 --- Subject: Re: tasking is not implemented on NetBSD This patch was simply not reviewed/discussed at all, Arnaud could you have a look? gcc-patches submission URL: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01510.html Well, this submission does not include a visible changelog and requires saving the attachment and unzip to review the patch. Very inconvenient. I'd suggest reposting the patch with the changelog in the email body, and the patch attached with no compression, that'll make it far easier and more likely to be reviewed. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37309
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #72 from charlet at adacore dot com 2009-11-17 15:50 --- Subject: Re: VRP fails to eliminate range checks in Ada code Is there anyway for the optimizers to get at this range information still? Or was range information removed because it is essentially impossible to use it correctly (if so this bug report should be closed as unfixable)? It was removed because it was impossible to use it correctly. The fix is to derive range information from existing range checks, possibly inter-procedurally. Right, as soon as you have one range check, the compiler can make more precise assumptions/conclusions about the actual range. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug ada/42073] [4.4 regression] Infinite loop when parsing a project file, alpha only
--- Comment #5 from charlet at adacore dot com 2009-11-17 21:45 --- Subject: Re: [4.4 regression] Infinite loop when parsing a project file, alpha only #1 0x02853dd8 in ?? () from /usr/lib/libgnatprj.so.4.4 #2 0x02856abc in prj__part__parse () from /usr/lib/libgnatprj.so.4.4 #3 0x0284df7c in prj__pars__parse () from /usr/lib/libgnatprj.so.4.4 Well, there's no such thing as libgnatprj.so in GCC sources/Makefiles. Can you please retry with a stock GCC and build with -O0 -g to get a more complete info/debug session? TIA. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42073
[Bug ada/38400] Acats faillures due to undefined pthread_setrunon_np
--- Comment #3 from charlet at adacore dot com 2008-12-11 11:15 --- Subject: Re: Acats faillures due to undefined pthread_setrunon_np The offending piece of code is pretty useless btw, even on IRIX 6.5. The cpu# in question is always initialized in s-tasinf-irix.ads with CPU_ANY so the end result is the same as when you wouldn't call pthread_setrunon_np() at all. So my initial fix was to simply remove this functionality entirely. That's a misunderstanding of the code: Task_Info can be specified by the user via pragma Task_Info. What you're seeing in s-tasinf-irix.ads is just a default that the user can change. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38400
[Bug ada/37993] [4.4 Regression] bootstrap with ada fails: a-direct.ads:426:09: alignment for Search_Typeb82s must be at least 8
--- Comment #1 from charlet at adacore dot com 2008-11-02 10:57 --- Subject: Re: [4.4 Regression] bootstrap with ada fails: a-direct.ads:426:09: alignment for Search_Typeb82s must be at least 8 This is yet again a failure due to having multilibs enabled by default for Ada with no proper support for it (this time on darwin). Do we have the many times discussed option --disable-multilibada yet or not by the way? Otherwise I suspect this issue will become a real FAQ. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37993
[Bug ada/37681] [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error
--- Comment #2 from charlet at adacore dot com 2008-09-30 15:06 --- Subject: Re: [4.4 regression] Building 64-bit libada fails on Solaris/x86: alignment error This happens only for the 64-bit libada, so it's probably due to missing support for the 64-bit multilib. Yes, it is, the hitch being that there is no port to x86_64/Solaris yet. Note that there was supposed to be a way (--disable-multilibada or some such) to easily disable this, so this should not be blocking. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
[Bug ada/37034] /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo ../../sinfo.h
--- Comment #3 from charlet at adacore dot com 2008-08-07 06:41 --- Subject: Re: /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo ../../sinfo.h mkdir -p ada/bldtools/einfo (cd ada/bldtools/sinfo gnatmake -q xsinfo ./xsinfo ../../sinfo.h ) rm -f ada/bldtools/einfo/einfo.ads ada/bldtools/einfo/einfo.adb ada/bldtools/einfo/xeinfo.adb cp -p ../../gcc/gcc/ada/einfo.ads ../../gcc/gcc/ada/einfo.adb ../../gcc/gcc/ada/xeinfo.adb ada/bldtools/einfo (cd ada/bldtools/einfo gnatmake -q xeinfo ./xeinfo ../../einfo.h ) /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo Sounds like your base Ada compiler may be corrupted, since the line above calls 'gnatmake', it does not use the newly built compiler. I belive it is xeinfo that's dropping core. This occurs in stage2. Right, and xeinfo is built with your base compiler. I'd try with an older or more recent base GNAT version. It's more likely a latent bug in GCC 4.3.1 only showing now because xeinfo dependencies have changed. chatr xeinfo This is debian linux. I will try debug xeinfo when the current build completes. Ooops, what about ldd xeinfo then ? Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37034
[Bug ada/37034] /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo ../../sinfo.h
--- Comment #1 from charlet at adacore dot com 2008-08-06 06:39 --- Subject: Re: New: /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo ../../sinfo.h mkdir -p ada/bldtools/einfo (cd ada/bldtools/sinfo gnatmake -q xsinfo ./xsinfo ../../sinfo.h ) rm -f ada/bldtools/einfo/einfo.ads ada/bldtools/einfo/einfo.adb ada/bldtools/einfo/xeinfo.adb cp -p ../../gcc/gcc/ada/einfo.ads ../../gcc/gcc/ada/einfo.adb ../../gcc/gcc/ada/xeinfo.adb ada/bldtools/einfo (cd ada/bldtools/einfo gnatmake -q xeinfo ./xeinfo ../../einfo.h ) /bin/sh: line 1: 26087 Aborted (core dumped) ./xsinfo Sounds like your base Ada compiler may be corrupted, since the line above calls 'gnatmake', it does not use the newly built compiler. Could you do: which gnatmake which gnatls gnatls -v chatr xeinfo ? Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37034
[Bug ada/36591] error: a-reatim.adb must be compiled
--- Comment #1 from charlet at adacore dot com 2008-06-21 17:08 --- Subject: Re: New: error: a-reatim.adb must be compiled I am seeing quite a few errors in the acats testsuite with the following errors: Most likely, your Ada run-time has not been rebuilt since your last incremental build. I'd suggest either redoing a build from scratch, or at least removing the target/libada/stamp-libada and gcc/stamp-* files and redoing a make. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36591
[Bug ada/36573] s-intman.adb:232:50: SA_ONSTACK is undefined
--- Comment #2 from charlet at adacore dot com 2008-06-19 03:37 --- Subject: Re: s-intman.adb:232:50: SA_ONSTACK is undefined s-intman.adb:232:50: SA_ONSTACK is undefined Looks like we need something like the following: Right. Assuming 0x1 is indeed the corresponding value of the SA_ONSTACK C macro, you can commit this change. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36573
[Bug ada/31808] cross-built gnattools installs vxaddr2line regardless of target triplet
--- Comment #4 from charlet at adacore dot com 2008-05-13 00:01 --- Subject: Re: cross-built gnattools installs vxaddr2line regardless of target triplet Are you sure of that? Because it has been built in my April 29 build of a cross-compiler targetting sh4-unknown-linux-gnu (from i686-pc-linux-gnu). Darn, I always forget about the new gnattools/Makefile.in file, which does indeed build wrongly vxaddr2line. Now fixed. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31808
[Bug ada/35880] GNAT (GCC) Ada does not generate symbolic debug for shared memory
--- Comment #5 from charlet at adacore dot com 2008-04-09 15:25 --- Subject: Re: GNAT (GCC) Ada does not generate symbolic debug for shared memory The application is an aircraft simulation by stimulating avionics black boxes. We use a debugger to examine state information while the simulation is running to try to determine problem causes. Note that the GCC project is based on volunteers, so your PR may never get the high priority attention that you apparently require. For such critical usage, you may consider getting support for your compiler (or get familiar with the compiler to investigate this issue yourself). I thought I read in the submission guidelines that an attachment was acceptable in a case like this. If I should submit the file contents as a large file, please point me to a sample so I know how to format the various individual file contents. Having a tar file for sources is certainly fine. Having all the instructions and explanation inside a README in a tarball is an unnecessary indirection which can only delay review of your PR. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880
[Bug ada/35284] Branch to 0x0 from Ada run-time
--- Comment #10 from charlet at adacore dot com 2008-02-22 08:34 --- Subject: Re: Branch to 0x0 from Ada run-time Arnaud, do you have any idea on what to look at (interesting breakpoint and data structures)? RTEMS tasking works on other platforms. May be some Ada/C thread interface data structure has the wrong size in the case of x86 and things get corrupted (s-oisinte-rtems.ads). I'd suggest putting a watchpoint on the softlink that gets cleared to 0x0 (or never set ?), you should see pretty quickly what's happening. Note that I removed myself from cc: because I already receive all bugzilla messages related to Ada PRs, so being in cc: means I receive the messages twice, which is annoying given the amount of email I have to deal with. It does not mean I'm ignoring this PR :-) Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35284
[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3
--- Comment #12 from charlet at adacore dot com 2008-02-10 13:12 --- Subject: Re: [4.3 regression] Serious regression on ACATS results since 4.2.3 I found remnants of a suggested EH change Arnaud had made to me and removed it. I do not think it was me. Possibly Laurent Guerby. YEAH! I will do a sparc-rtems run and after that I will clean up and add a patch to this PR. Please do not close it until I do that and it is reviewed and applied. Please close this PR as soon as you confirm that a clean tree builds properly. Note that in any case, this PR is 100% specific to RTEMS since Ada is in relatively good shape wrt exceptions on all the targets where tests are posted. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35143
[Bug ada/34717] Ada runtime improvements for OpenBSD to enable tasking and related features
--- Comment #2 from charlet at adacore dot com 2008-01-09 07:57 --- Subject: Re: New: Ada runtime improvements for OpenBSD to enable tasking and related features After the patch, configure option --with-threads=gnat enables tasking for OpenBSD on x86 platform. Note that this option is deprecated and will be removed at some point. You should use e.g. --with-threads=posix, or use the default (assuming it's not 'single') instead. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34717
[Bug ada/15803] Illegal program not detected, RM 8.3(19)
--- Comment #8 from charlet at adacore dot com 2007-12-19 16:50 --- Subject: Re: Illegal program not detected, RM 8.3(19) for traceability purpose, I would appreciate to be credited in the ChangeLog as well for this change as I am the one who submitted the patch for sem_ch3.adb (Check_For_Premature_Usage procedure and Access_Subprogram_Declaration change) that you committed (after some reformatting). Sure, I understand. Actually it was more than reformatting, we changed the error message also and a few other things. But you definitely deserve to get your name as well on this patch, now added. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15803
[Bug ada/22559] Bug box, Program_Error at sinput.adb:404, derived fixed-point type
--- Comment #9 from charlet at adacore dot com 2007-12-08 17:22 --- Subject: Re: Bug box, Program_Error at sinput.adb:404, derived fixed-point type good catch, I forgot to send the message to gcc-patches with the content and the ack indication. The patch was acked by Robert by mail (see GB19-012) on November 19. OK. Please be sure to follow the standard procedures in the future (send patch to gcc-patches and wait for review and OK before committing), otherwise this creates confusion and makes also my job harder at identifying which patches to merge in which tree (things are complex enough already :-). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22559
[Bug ada/33722] putenv() is made posix-conformant on FreeBSD 7.x
--- Comment #2 from charlet at adacore dot com 2007-10-10 08:18 --- Subject: Re: putenv() is made posix-conformant on FreeBSD 7.x Created an attachment (id=14335) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14335action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14335action=view) Fix for free() after putenv() on FreeBSD 7.x The patch allowed me to bootstrap gcc 4.2.2 on the FreeBSD 7.x with gnat enabled. Patch looks good to me. OK for 4.2 branch and trunk. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33722
[Bug ada/33392] ACATS cxa5a09, cxa5a10 and controlled2.adb failure
--- Comment #4 from charlet at adacore dot com 2007-09-13 07:47 --- Subject: Re: ACATS cxa5a09, cxa5a10 and controlled2.adb failure Your tree is very likely skewed, the Ada compiler bootstraps fine on x86, x86-64, IA-64 and SPARC at least. Right. I got a similar failure and fixed it by doing a complete svn update and then make -k clean; make. The svn update probably cured this issue. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33392
[Bug target/10768] ICEs on compilation of ada support library for avr
--- Comment #21 from charlet at adacore dot com 2007-05-22 14:26 --- Subject: Re: ICEs on compilation of ada support library for avr Then what would be a real fix that could actually be approved and committed? Fix support for long (or long long ?) in the avr back-end. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768
[Bug ada/31576] [4.3 regression] Ada bootstrap error
--- Comment #2 from charlet at adacore dot com 2007-04-17 13:06 --- Subject: Re: [regression] Ada bootstrap error You need to add the following in system-xxx.ads: pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning as done in other system-* files, after Default_Bit_Order definition. Patch is preapproved. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31576
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #33 from charlet at adacore dot com 2007-02-24 10:12 --- Subject: Re: VRP fails to eliminate range checks in Ada code I guess that nearly all range checks are eliminated and without bootstrapping we have a disconnect between the redundant checks in the rts and the testcases. If it happens that the non-bootstrapped rts is built by the host compiler(?). No, that never happens. The rts is always built with the latest (stage3) compiler. Otherwise it would not even begin to work fro cross compilers. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #34 from charlet at adacore dot com 2007-02-24 12:32 --- Subject: Re: VRP fails to eliminate range checks in Ada code we have a disconnect between the redundant checks in the rts and the testcases. If it happens that the non-bootstrapped rts is built by the host compiler(?). No, that never happens. The rts is always built with the latest (stage3) compiler. Otherwise it would not even begin to work fro cross compilers. Note that I'm talking about ada/rts, which gets installed under adainclude and adalib, and used by Ada apps. That's the target run-time. Maybe you are talking about the part of the Ada run-time which is used by the compiler itself, in which case, it's considered as a source of the compiler, and treated as such (built successively by all compilers from bootstrap compiler to stage2 compiler). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- Comment #36 from charlet at adacore dot com 2007-02-24 12:47 --- Subject: Re: VRP fails to eliminate range checks in Ada code I was talking about the rts that get's used if I configure with --disable-bootstrap, do a make and then run make check-ada from within the gcc/ subdirectory. As far as I understand that rts seems to be built using the bootstrap compiler. At least this would explain the difference in the number of acats failures I see comparing a bootstrapped tree vs. a non-bootstrapped tree. Sorry, I am not familiar with --disable-bootstrap, but if it builds the Ada rts with the bootstrap compiler, then that's a clear bug in the top level makefiles. Ada makefiles are not designed to build the Ada rts with the host compiler, so there must be some very strange makefile interaction going on if true. You can easily verify that of course by checking your build log. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug bootstrap/30541] Top-level should pass GNATBIND, GNATLINK and GNATMAKE variables down
--- Comment #12 from charlet at adacore dot com 2007-01-23 14:47 --- Subject: Re: Top-level should pass GNATBIND, GNATLINK and GNATMAKE variables down GNATBIND = $(STAGE_PREFIX)gnatbind GNATMAKE = gnatmake GNATLINK = gnatlink in both Make-lang.in and Makefile.in. (sidenote: after this patch is committed I'll remove STAGE_PREFIX altogether from mainline). True, they seem to be unused, but it's better to be consistent; for the same reason I prefer to pass GNATLINK down too via flags_to_pass. Not only they seem, but they ARE unused. Normally, only gcc and gnatbind are needed during the bootstrap. Now, gnatmake is also needed because of some support tools, but logically, these support tools should only be built once before bootstrap starts, in order to generate automatically files. So I see no reason to add GNATLINK here really. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30541
[Bug ada/19959] [4.0/4.1/4.2/4.3 Regression] Can't compile gnattools for the cross targets
--- Comment #14 from charlet at adacore dot com 2007-01-04 21:32 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] Can't compile gnattools for the cross targets libada and gnattools-cross are not related, IMHO. I consider the dependancy as a configure/Makefile bug. The following patch removes the dependency of gnattols on libada. Given that you apparently cannot build gnatlib, you could instead do a make -C gcc gnattools or similar --disable-libada is intended to disable both gnatlib and gnattools (and should perhaps be renamed), so this is not a bug. Your proposed patch removes a useful capability. At the very least, gnattools should be disabled in the case of native builds when using --disable-libada Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959
[Bug ada/19959] [4.0/4.1/4.2/4.3 Regression] Can't compile gnattools for the cross targets
--- Comment #15 from charlet at adacore dot com 2007-01-04 21:39 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] Can't compile gnattools for the cross targets BTW, answering an old message: Can you please describe how you tested the patch? No test since I do not have a set up for avr, it was an obvious change. Why does the '--disable-libada' switch disable gnattools-cross? This has nothing to do with this PR however, which is not about --disable-libada. Let's please keep issues separate; thanks. If you have troubles with --disable-libada, you should open another PR. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959
[Bug ada/30130] Cannot bootstrap 4.1.2 ada with 4.2.0 ada
--- Comment #7 from charlet at adacore dot com 2006-12-09 13:55 --- Subject: Re: Cannot bootstrap 4.1.2 ada with 4.2.0 ada I see it's not supported, but as Ada needs Ada to be bootstrapped how do you expect maintainance work to work for active release branches? By simply using an older bootstrap compiler, for both 4.1 and 4.2 Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30130
[Bug ada/29707] s-osinte.adb:86:13: warning: function To_Target_Priority is not referenced
--- Comment #3 from charlet at adacore dot com 2006-11-05 10:48 --- Subject: Re: New: s-osinte.adb:86:13: warning: function To_Target_Priority is not referenced You need to add a spec for To_Target_Priority in s-osinte-linux-hppa.ads Better in the medium term would be to merge s-osinte-linux-hppa.ads with s-osinte-linux.ads as suggested in the past, to avoid this kind of trouble. We probably have a similar issue with s-osinte-linux-alpha.ads Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29707
[Bug ada/29262] Adding tasking support for arm-linux
--- Comment #7 from charlet at adacore dot com 2006-10-09 08:28 --- Subject: Re: Adding tasking support for arm-linux ... well, I can see differences, but is there any definite way of finding out, how the C structures actually look like? Do I have to hunt this up in the glibc source code? You need to retrieve the values and struct definitions from the include files present on your system. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29262
[Bug ada/27936] [4.2 Regression] gnatbind fails to link on Tru64 UNIX
--- Comment #7 from charlet at adacore dot com 2006-07-04 19:09 --- Subject: Re: [4.2 Regression] gnatbind fails to link on Tru64 UNIX Arno, do you have any suggestions on how to investigate this? After all, this is a 4.2 regression. I'd suggest comparing what happens on another platform, and find where the difference starts. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27936
[Bug ada/27944] s-taprop.adb:66:06: warning: redundant with clause in body
--- Comment #2 from charlet at adacore dot com 2006-06-08 07:57 --- Subject: Re: s-taprop.adb:66:06: warning: redundant with clause in body Probably introduced by the following change: And/or by a new GNAT warning. Anyway, the fix should be trivial: simply follow GNAT's advice and remove the with clause. Change preapproved. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27944
[Bug ada/27936] [4.2 Regression] gnatbind fails to link on Tru64 UNIX
--- Comment #3 from charlet at adacore dot com 2006-06-08 08:03 --- Subject: Re: New: gnatbind fails to link on Tru64 UNIX Add ada/s-purexc.o to ada/Make-lang.in (GNATBIND_OBJS). If this is considered the correct fix, I'll submit a proper patch. This shouldn't be needed at first sight, so this is likely not the right fix. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27936
[Bug testsuite/27476] ACATS: Ada testsuite Bourne shell compatibility problem on hpux
--- Comment #5 from charlet at adacore dot com 2006-05-08 16:35 ---
Subject: Re: ACATS: Ada testsuite Bourne shell compatibility problem on hpux
-- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-08 16:31 ---
[ x${main} != x ] should also work and maybe a little more portable.
That's also fine, although overkill these days.
All host OSes supported by GNAT (and more) accept the following simpler
and cleaner syntax:
if [ $main != ]; then
or the other way around as needed here:
if [ $main = ]; then
Arno
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27476
[Bug ada/27366] ada build fails as cygwin does not have clearenv
--- Comment #2 from charlet at adacore dot com 2006-05-02 08:46 --- Subject: Re: ada build fails as cygwin does not have clearenv Here is the patch I tested. acats results below aren't a total disaster. Patch looks reasonable to me, you have my OK. Note that patches should be posted to gcc-patches@ Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27366
[Bug ada/14435] [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #14 from charlet at adacore dot com 2006-01-25 16:59 --- Subject: Re: [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics How committed are we to fix this bug? Last time it was closed as WONTFIX. If we are 100% committed to fix this, I can try to come up with something. Well, the first thing to do is really to fix the documentation, since GCC_EXEC_PREFIX is mentioned in several places in the documentation, in an inconsistent manner. Some places do document the behavior which the Ada test suite would like to rely upon (GCC_EXEC_PREFIX strictly equivalent to the -B switch), that's basically the old behavior, and some other places don't (that's the new behavior). I would personally vote for fixing things so that GCC_EXEC_PREFIX can be used instead of -B Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug ada/14435] [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics
--- Comment #16 from charlet at adacore dot com 2006-01-25 17:31 --- Subject: Re: [4.2 Regression] gnatchop cannot use the compiled compiler in Ada's testsuite because of changed GCC_EXEC_PREFIX semantics Is gnat1 a subprogram executed by the compiler? If anwser is yes and we agree the manual is correct, I will try to fix the driver. gnat1 is similar to cc1 and cc1plus, i.e. executed by the gcc driver. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
[Bug ada/18819] [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime
--- Comment #21 from charlet at adacore dot com 2006-01-23 15:12 --- Subject: Re: [4.1/4.2 Regression] ACATS cdd2a01 cdd2a02 fail at runtime No real solution as of this writing, only a poor workaround: not compiling the support files with -gnato (overflow checks). That's not really an option, since these files must be compiled with -gnato (well at least report.adb) for proper operation of some ACATS tests. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18819
[Bug bootstrap/25859] gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open
--- Comment #1 from charlet at adacore dot com 2006-01-19 15:53 --- Subject: Re: New: gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open This doesn't happen on the trunk. The following from ada/Makefile.in is supposed to take care of that: GCC_LINK=$(CC) -static-libgcc $(ADA_INCLUDES) (and uses of $(GCC_LINK) elsewhere in the tools). Basically we certainly do *not* want to link with libgcc_s, in particular to avoid this kind of nightmare. This was fixed as part of: 2005-02-09 Arnaud Charlet [EMAIL PROTECTED] PR ada/16592 * Makefile.in: Link all gnat tools with -static-libgcc, since -shared-libgcc is now used by default on some systems (e.g. linux with recent binutils). I am surprised that there's a regression between 4.1 and trunk here. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25859
[Bug bootstrap/25859] gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open
--- Comment #4 from charlet at adacore dot com 2006-01-19 16:19 --- Subject: Re: gnatmake: error while loading shared libraries: libgcc_s.so.4: cannot open For some reason, the above doesn't seem to have been used in linking gnatmake: Indeed, gnatmake has to be handled specially. So I guess the gnatmake rule needs to use $(GCC_LINK) one way or another (although there should be no difference between trubk and 4.1 in that respect). Same for gnatlink. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25859
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- 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 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. Index: s-osinte-linux-hppa.ads === --- s-osinte-linux-hppa.ads (revision 109788) +++ s-osinte-linux-hppa.ads (working copy) @@ -508,7 +508,7 @@ lock : lock_array; end record; pragma Convention (C, atomic_lock_t); - for atomic_lock_t'Alignment use 16; + for atomic_lock_t'Alignment use 8; type struct_pthread_fast_lock is record spinlock : atomic_lock_t; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- 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 about ??? ;-) Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- 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 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 like sizeof for size). If you use a storage_array, you definitely also need the proper alignment clause, yes. Arnaud, do you remember non opaque C types in s-osinte? I do not understand your question, could you clarify ? Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- 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 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 applied on some platforms to all the *private* C types, although this is not a good idea because the current files are written to be used on many architectures (e.g. s-osinte-hpux.ads can be used under both pa and ia64), so this approach would simply break it (System.Address has a different size under pa and ia64, and the default alignments are very different from one architecture/ABI to the other). That's why I said a few times already that creating s-osinte-linux-cpu.ads files was not a good idea and that a clean up will need to be done at some point to merge back those files. Your suggestion would simply go one step further in making this task close to impossible instead of difficult. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24533] FAIL: a85013b: *** glibc detected *** free(): invalid pointer: 0x00062a00 ***
--- 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 problem. This will work from a locking standpoint, but it's not correct from a struct layout standpoint. However, it might be ok depending on how ada uses atomic_lock_t objects. Hmm, so that means that 16 is bigger than Standard'Maximum_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 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. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24533
[Bug ada/24822] make[2]: *** [ada/einfo.h] Error 1
--- Comment #3 from charlet at adacore dot com 2005-12-12 16:06 --- Subject: Re: make[2]: *** [ada/einfo.h] Error 1 If the issue is with the bootstrap compiler, there's not much we can do. Bootstrap compiler is GCC. This doesn't occur on linux, but it Well sure, you can't bootstrap GNAT with anything else than GCC ;-) Is this the same version of GCC ? Could you try with another version ? doesn't need the -mdisable-indexing hack. I'll try to investigate further. Thanks. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24822
[Bug ada/24822] make[2]: *** [ada/einfo.h] Error 1
--- Comment #4 from charlet at adacore dot com 2005-12-12 16:08 --- Subject: Re: make[2]: *** [ada/einfo.h] Error 1 What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-12 16:06:55 date|| Well, I didn't want to confirm it (do not have the set up), I just wanted to reopen the bug (as in, remove the WAITING state). Anyway, no big deal. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24822
[Bug ada/24822] make[2]: *** [ada/einfo.h] Error 1
--- Comment #6 from charlet at adacore dot com 2005-12-13 07:22 --- Subject: Re: make[2]: *** [ada/einfo.h] Error 1 Is GNAT still being maintained in the 4.0 branch? Yes, although only critical changes go there (as you would expect for a release branch). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24822
[Bug ada/24946] [4.1/4.2 Regression] make[7]: rc: Command not found
--- Comment #3 from charlet at adacore dot com 2005-11-21 14:59 --- Subject: Re: [4.1/4.2 Regression] make[7]: rc: Command not found I'm not sure either. I did notice that the build that had a problem was using an old version of make (3.79.1). I removed this and now this system appears to be behaving similarly to the other hppa-linux system that I build on. On the otherhand, I've been building with this version of make for years. Interesting. This might be a bug in the handling of the export directive then, latent up to now, but showing explicitely now that more variables are used by the Ada Makefile. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24946
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Comment #4 from charlet at adacore dot com 2005-11-15 11:04 --- Subject: Re: [ada] Library_Version still at 4.0 ? can this be updated before the branch is created? Will commit the patch later today or tomorrow. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug ada/23732] [ada] Library_Version still at 4.0 ?
--- Comment #6 from charlet at adacore dot com 2005-11-15 11:22 --- Subject: Re: [ada] Library_Version still at 4.0 ? what about soext in gcc41/gcc/ada/Makefile.in? there is still soext = .so is ada abi compatible in gcc 3.3 ... 4.1 ? You seem to be confused: soext is about the extension not about soname which is already handled by Library_Version. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
[Bug ada/21717] [4.1 regression] Endless stream of exceptions ( c95085a, c95085b and c95086a)
--- Additional Comments From charlet at adacore dot com 2005-09-30 15:54 --- Subject: Re: [4.1 regression] Endless stream of exceptions ( c95085a, c95085b and c95086a) Maybe an Ada maintainer could at least confirm the bug? AFAIK, this is ia64 specific, so requires an ia64 set up. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21717
[Bug bootstrap/24030] target libraries are not rebuilt after gcc is rebuilt
--- Additional Comments From charlet at adacore dot com 2005-09-23 14:13 --- Subject: Re: libada not rebuilt when libbackend is What|Removed |Added CC||charlet at adacore dot com Thanks for the cc:, although I do monitor all Ada bugs, so do not worry, I saw your report ;-) Unfortunately, I am not a libada (actually GCC configure, script, makefile) expert so I am not the best person to ask. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24030
[Bug ada/23788] s-taprop.adb:69:06: warning: cannot depend on Interrupt_Operations (wrong categorization)
--- Additional Comments From charlet at adacore dot com 2005-09-22 08:34 --- Subject: Re: s-taprop.adb:69:06: warning: cannot depend on Interrupt_Operations (wrong categorization) This bug is also present on the 4.0 branch. This is a regression from 4.0.0 Could you double check ? I cannot see how this is possible, since the 4.0 branch hasn't been modified in this area at all. The regression is very recent and HEAD only AFAIK. The patch is fine BTW, feel free to commit it (I'll do it when I get a chance otherwise). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23788
[Bug ada/23187] MAXPATHLEN usage in gcc/ada/*.c
--- Additional Comments From charlet at adacore dot com 2005-09-01 07:21 --- Subject: Re: MAXPATHLEN usage in gcc/ada/*.c Reopened bug awaiting a proper fix. Feel free to submit one, since you have access to a GNU system. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23187
[Bug ada/23646] [4.1 Regression] Ada testsuite hangs -- many new failures
--- Additional Comments From charlet at adacore dot com 2005-08-31 07:19 --- Subject: Re: [4.1 Regression] Ada testsuite hangs -- many new failures So the only thing left is the Ada front-end/library changes. Thanks for investigating, I'll have a look. I have a set of pending changes that should take care of this. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23646
[Bug ada/23519] Dividing fixed point number by zero returns zero.
--- Additional Comments From charlet at adacore dot com 2005-08-22 20:39 --- Subject: Re: Dividing fixed point number by zero returns zero. This is a true front-end bug as on PPC divide by zero (in an instruction) does not raise an exception so there needs to be an extra check which should have been added by the front-end There is no such requirement in Ada that would force the compiler to map a PPC divide by zero to an Ada exception. If you want this kind of check, be sure to use -gnato. Is -gnato used here ? I suspect not, although the compilation command has not been provided as far as I can see. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23519
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From charlet at adacore dot com 2005-07-06 06:06 --- Subject: Re: [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed Ada is very confused it looks like as raise.c is both a host and target file which seems to me wrong. Ada is different in that the Ada compiler is written in Ada, and part of the Ada run-time is used by both the Ada compiler and the run-time itself. That does not make it wrong, just different from what people are used to. Arno -- 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 charlet at adacore dot com 2005-07-05 07:11 --- Subject: Re: [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed I got the same issue on i686-linux, so this is affecting several targets apparently. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug ada/21247] Cross-building gnat-4.0.0 requires native gnat-4.0.0
--- Additional Comments From charlet at adacore dot com 2005-05-18 13:33 --- Subject: Re: Cross-building gnat-4.0.0 requires native gnat-4.0.0 Could you suggest a patch for install.texi which corrects the tool requirements for building GNAT both natively and cross? I'm sure I could, like anyone else, when I get a chance. I am particularly busy these days, so feel free to go ahead and suggest such change. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21247
[Bug ada/21053] Warnings from init.c
--- Additional Comments From charlet at adacore dot com 2005-04-17 08:13 --- Subject: Re: Warnings from init.c I believe you can commit as obvious once tested. Right. There are other occurence of the same code for other target, but I don't have access to them, may be Arnaud? I don't have a gcc head set up except under x86-linux Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21053
[Bug ada/20822] makeinfo cannot process gnat_ugn_unw.texi
--- Additional Comments From charlet at adacore dot com 2005-04-13 08:32 --- Subject: Re: makeinfo cannot process gnat_ugn_unw.texi Arnaud, may be a candidate for review? Sure. I'd suggest posting the patch to gcc-patches@ Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
[Bug ada/19526] Windows errorcodes wrong in Ada when tasking
--- Additional Comments From charlet at adacore dot com 2005-03-19 13:54 --- Subject: Re: Windows errorcodes wrong in Ada when tasking IMO, resetting the error code set by the kernel whenever the internal Ada tasking functions are called successfully is a bug. So you are saying that there is a bug in the Windows kernel ? Since the Ada run time does not do any reset of the error code. It can be easily fixed: I don't see how this fixes things, since TlsGetValue is also called in the Self function. Is_Valid_Task is not called in the test case at hand, and Set is called during task elaboration, so that's also not problematic. Did you get a successfulrun of the application with this patch ? If so, it probably means that the problem is elsewhere and that this patch is just hiding it. The function which is called when you use tasking constructs is Self, and this function is time critical, so it is simply out of the question to call GetLastError/SetLastError there. If you want to know the error code associated with your socket call, you should save the result right away, and not delay this operation. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19526
[Bug ada/20515] stdcall imports are not handled correctly
--- Additional Comments From charlet at adacore dot com 2005-03-17 09:58 --- Subject: Re: New: stdcall imports are not handled correctly Patch looks correct (certainly better) to me, investigating. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20515
[Bug ada/19902] ACATS cxa3004 cxb3006 fail at compile time ambiguous expression
--- Additional Comments From charlet at adacore dot com 2005-02-22 09:46 --- Subject: Re: ACATS cxa3004 cxb3006 fail at compile time ambiguous expression Arno, any objection to moving them to norun.lst until after the issue is resolved? Actually I do not see the interest, since the test is wrong. I would simply cvs remove it. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19902
[Bug ada/19902] ACATS cxa3004 cxb3006 fail at compile time ambiguous expression
--- Additional Comments From charlet at adacore dot com 2005-02-22 09:55 --- Subject: Re: ACATS cxa3004 cxb3006 fail at compile time ambiguous expression I was under the impression that moving it to the norun.lst was the canonical procedure when waiting for an ACAA's response (did Laurent not do so once?). Not as far as I know. I'd say that norun.lst should be used for valid tests that are problematic. For other tests, it's simple enough to remove them, and add them back with changes when needed. That's a matter of taste of course, but I'd rather not overuse norun.lst Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19902
[Bug ada/18659] [4.0 Regression] ACATS ICE in bug in tree-sra.c:1507 on x86 and ppc-darwin (6 FAIL)
--- Additional Comments From charlet at adacore dot com 2005-02-18 12:58 --- Subject: Re: [4.0 Regression] ACATS ICE in bug in tree-sra.c:1507 on x86 and ppc-darwin (6 FAIL) SRA is an Ada killer because of the the abuse of VIEW_CONVERT_EXPRs by the Ada front-end. I think it should be disabled in the Ada compiler for 4.0.x. Sounds reasonable to me. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18659
[Bug ada/19902] ACATS cxa3004 cxb3006 fail at compile time ambiguous expression
--- Additional Comments From charlet at adacore dot com 2005-02-11 12:03 --- Subject: Re: New: ACATS cxa3004 cxb3006 fail at compile time ambiguous expression Probably related to recent changes, might be an ACATS problem. Right, these tests should be removed from the repository, or modified. We've informed the ACAA about this issue (incompatibility with Ada 2005). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19902
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From charlet at adacore dot com 2005-02-03 09:03 --- Subject: Re: gnat tools not buildable cross Arnauds: checking for .preinit_array/.init_array/.fini_array support... yes For the record, it's Laurent's, not Arno's Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From charlet at adacore dot com 2005-01-31 09:21 --- Subject: Re: gnat tools not buildable cross Since it is clearly a regression (vs 3.2 cross RTEMS/Ada capabilities), would you mind proposing a patch to current 4.0 libada? I've included Arnaud in CC. There must be a simpler way to fix this regression. I am not even convinced that this change would fix this particular bug anyway, so we first need this info before proceeding. Such major addition is not suitable for stage 3 in my opinion (but very welcome for stage 1), we want a much more localized change, which is certainly possible here. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19489] gnat tools not buildable cross
--- Additional Comments From charlet at adacore dot com 2005-01-31 16:38 --- Subject: Re: gnat tools not buildable cross I don't think so. When you get into the libada directory, CC=$(CC_FOR_TARGET) and all hope is lost of having the tools work in a cross configuration. That is wrong, ada/Makefile.in is designed to support this configuration, and use the native gnat bootstrap compiler instead of $(CC) to build the tools in the case of cross compilation. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19489
[Bug ada/19488] RTEMS Ada RTS doesn't compile
--- Additional Comments From charlet at adacore dot com 2005-01-18 09:33 --- Subject: Re: RTEMS Ada RTS doesn't compile Could you please submit your patch(es) for review on gcc-patches ? Thanks in advance. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19488
[Bug ada/13470] 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc.
--- Additional Comments From charlet at adacore dot com 2005-01-18 13:34 --- Subject: Re: 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc. Already did that yesterday. Patch here http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01057.html. Sorry about that, I somehow missed it. Patch is OK, thanks. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13470
[Bug ada/17307] Bug box in Gigi, code=116, 'Unrestricted_Access of a protected subprogram
--- Additional Comments From charlet at adacore dot com 2005-01-12 10:41 --- Subject: Re: Bug box in Gigi, code=116, 'Unrestricted_Access of a protected subprogram Hmm, now I get on the mainline: test_269775.adb:18:23: non-local pointer cannot point to local object So this rejects valid now? Not really, since 'Unrestricted_Access is a GNAT specific attribute, we can give it any semantic we like. In this particular case, I do not think we want nor claim to support access to nested protected procedure. Instead, the code should be fixed to be valid Ada 95 and use 'Access on a protected object declared at library level (= in a package). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17307
[Bug ada/13470] 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc.
--- Additional Comments From charlet at adacore dot com 2004-12-02 09:43 --- Subject: Re: 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc. Fixing the bug is nice, but it just won't fix the problem with people having Fixing the bug is needed, not only nice ;-) 3.4.0/1/2 already installed, only the Makefile workaround will help them since the base compiler and not the stage1 one is used to compile the build tools (unless I'm missing something obvious there). There are already work arounds, such as generating the files on another machine, and copying the generated file in your obj directory. Once the bug is fixed and understood, it should also be possible to modify the code that is being miscompiled, which would be a better work around than what has been suggested so far (for reasons already explained). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13470
[Bug ada/13470] 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc.
--- Additional Comments From charlet at adacore dot com 2004-12-01 08:40 --- Subject: Re: 64bits Ada bootstrap failure:xnmake etc. crash generating nmake.adb etc. should have worked but was rejected, so waiting for better ideas. Well that may seem obvious, but the better idea would be to fix the code generation issue to start with, instead of trying to work around it. I know this is less fun and more difficult, but having such pending bug is certainly annoying. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13470
[Bug ada/18417] [4.0 Regression]Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing
--- Additional Comments From charlet at adacore dot com 2004-11-24 14:37 --- Subject: Re: [4.0 Regression]Ada bootstrap failure on IRIX 6.5: tb-gcc.c missing The tb-gcc.c file is still missing from the repository. Would you please add it soon? Thanks for the reminder, I indeed forgot about it. I'll work on it as soon as possible. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18417
