Re: [Bug ada/112446] New: Switch -gnatyz included in -gnatyg
> "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
Re: [Bug ada/69883] gcc-6.0 unable to build gcc-4.9 with ada
> 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
Re: [Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime
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
Re: [Bug ada/64492] New: Disabling libada prevents building gnattools-cross
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
Re: [Bug ada/60411] ADA bootstrap failure on ARM
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.
Re: [Bug tree-optimization/60174] [4.9 regression] ICE on ACATS cc3305a
./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
Re: [Bug tree-optimization/60174] [4.9 regression] ICE on ACATS cc3305a
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
Re: [Bug ada/60078] acats c761007 fails on ARM
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
Re: [Bug ada/60078] acats c761007 fails on ARM
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
Re: [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 #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
Re: [Bug ada/57188] [4.9 regression] Ada bootstrap broken on Solaris/x64: No_Implicit_Dynamic_Code violation
* 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
Re: [Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
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
Re: [Bug bootstrap/54820] [4.8 Regression] ada: cannot find -lstdc++ since 4.8.0 20121002
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
Re: [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)
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.
Re: [Bug ada/49940] New: [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
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.
Re: [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)
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
Re: [Bug ada/47717] building library for arm-none-eabi causes internal error
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
Re: [Bug ada/42368] ada/cio.c uses common names
Ping on this. Would a patch be OK? Depending on the patch, yes.
Re: [Bug ada/36939] Build Failure Ada SH2e
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
Re: [Bug ada/42153] 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
Re: [Bug ada/37309] 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
Re: [Bug tree-optimization/30911] 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
Re: [Bug ada/42073] [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
Re: [Bug ada/38400] 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
Re: [Bug ada/37034] /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
Re: [Bug ada/37034] 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
Re: [Bug ada/36591] 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
Re: [Bug ada/36573] 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
Re: [Bug ada/35284] 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
Re: [Bug ada/33722] putenv() is made posix-conformant on FreeBSD 7.x
Created an attachment (id=14335) -- (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
Re: [Bug tree-optimization/30911] 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
Re: [Bug tree-optimization/30911] 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
Re: [Bug tree-optimization/30911] 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
Re: [Bug testsuite/27476] 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
Re: [Bug bootstrap/25859] 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
Re: [Bug bootstrap/25859] 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
Re: [Bug ada/24533] 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;
Re: [Bug ada/24533] 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
Re: [Bug ada/24533] 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
