> --- Comment #2 from Andrew Pinski ---
> (In reply to Eric Botcazou from comment #1)
>> GNATprove is not part of GCC, please report to the vendor instead.
>
> Though it is documented to be used:
> https://gcc.gnu.org/onlinedocs/gnat_rm/SPARK_005f05.html
Other tools are mentioned such as gprbu
> --- Comment #3 from Saada Mehdi <00120260a at gmail dot com> ---
> Moreover, the message itself points at gcc bug / bugzilla.
That's a bug by itself, but also not for GCC.
Arno
> "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!
> 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 compil
> 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.
>
>
> 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
> 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.
> 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.
Assumi
> > ./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/
> 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
> 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 o
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645
>
> --- Comment #2 from Dominique d'Humieres ---
> > 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 o
> >> * 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 t
> > 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
> 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
> 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
> the
> 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
> th
> > 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.
> 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
> Ping on this. Would a patch be OK?
Depending on the patch, yes.
> 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 O
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-
> #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.
> > 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.
> 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 patc
> 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
> > > 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
> > > ../../
> 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 a
> 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 /libada/stamp-libada and gcc/stamp-* files and redo
> > 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
> 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
> Created an attachment (id=14335)
> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14335&action=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.
> 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
>
> > 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 w
> 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
>-- 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:
> 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 gnatlin
ular
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
> 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
> 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
> 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 struc
> 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
42 matches
Mail list logo
