> Thanks for finding that! I have made the recommended change and attached the
> revised patch, which is also rebased on trunk.
>
> Additionally, I have added the “Signed-off-by” tag for legal compliance to
> the patch, as well as the change log entry as follows:
Thank you, patch is therefore n
> No worries, and sorry for the trouble. I’m going to try using a different
> client for the gcc mailing list, it doesn’t seem to like Outlook. Thanks for
> catching that mistake!
>
> Please advise how I can get this patch actually applied, given my lack of
> commit privilege.
You first need t
OK, thanks.
> gcc/ChangeLog:
>
> * ada/Makefile.rtl: Add LoongArch support.
> * ada/libgnarl/s-linux__loongarch.ads: New.
> * ada/libgnat/system-linux-loongarch.ads: New.
> * config/loongarch/loongarch.h: mark normalized options
> passed from driver to gnat1 as expli
> gcc/ChangeLog:
>
> * ada/Makefile.rtl: Add LoongArch support.
> * ada/libgnarl/s-linux__loongarch.ads: New.
> * ada/libgnat/system-linux-loongarch.ads: New.
> * config/loongarch/loongarch.h: mark normalized options
> passed from driver to gnat1 as explicit for multi
Change is OK, thanks!
> Noticed trivial syntax errors in gcc/ada/expect.c when tried to compile gcc
> 13.2 as cross-compiler for target i686-pc-msdosdjgpp.
>
> Errors were there since
>
> Tiedostossa, joka sisällytettiin kohdasta expect.c:54:
> expect.c:Funktio ”__gnat_waitpid”:
> expect.c:353:1
> For some reason, your email is endeing up in a strange format, I almost
> missed the .patch file attached, making the review harder.
Never mind, I was on vacation earlier this month and then busy with a seminar
last week, so I started looking at your ping email before the original email
which
Richard,
For some reason, your email is endeing up in a strange format, I almost
missed the .patch file attached, making the review harder.
There's a typo in the comment added:
+ -- explicit limitedness implied by a synchronized private extension
+ -- the does not derive from a synch
OK, thanks.
> Hi all,
>
> a bit belated but just like last year, I've made a patch for the Ada
> entry in the changelog. You can find the patch attached to this email.
>
> If I have forgotten anything relevant or if I have done something
> incorrectly, please, say so.
>
> Best regards,
> Fernan
> The commit "ada: Add PIE support to backtraces on Linux" [1] use
> _r_debug under Linux unconditionally. It is incorrect since musl[2]
> libc not defined _r_debug like glibc [3]:
>
> extern struct r_debug _r_debug;
>
> As far as I know, only glibc and uClibc [4] define the global variable
> _r_
> Use the GNATMAKE variables consistently.
> Avoids failures when bootstraping with a custom GNATMAKE value.
>
> gcc/ada/ChangeLog:
>
>* Make-generated.in: Use GNATMAKE.
>* gcc-interface/Makefile.in: Ditto.
Ok, thanks.
> Signed-off-by: Peter Foley
> ---
> gcc/ada/Make-generated.in
> I would like to revise this patch to be more conservative (only applying to
> Darwin 8 and 9).
This is OK, thanks (and Happy New Year!)
> > On 24 Dec 2022, at 19:00, Iain Sandoe via Gcc-patches
> > wrote:
> >
> > Tested on i686, x86-64 darwin, x86_64-linux (with a 32b multilib).
> > OK for
>> When decl is NULL, don't record its mapping in the
>> decl_to_instance_map.
>> Regstrapped on x86_64-linux-gnu. Ok to install?
>> for gcc/ada/ChangeLog
>>* gcc-interface/trans.cc (Sloc_to_locus): Don't map NULL decl.
> OK assuming that a NULL "decl" is valid -- you're in a much better po
> Sorry for the breakage. However, I contacted you (and your colleague)
> and haven't received
> any feedback for a couple of weeks.
> >>>
> >>> Right although I did give you feedback that what you sent wasn’t in a
> >>> suitable form for review wrt Ada.
> >>
> >> Sure, but sending
> >> Sorry for the breakage. However, I contacted you (and your colleague) and
> >> haven't received
> >> any feedback for a couple of weeks.
> >
> > Right although I did give you feedback that what you sent wasn’t in a
> > suitable form for review wrt Ada.
>
> Sure, but sending a patch set to
> Sorry for the breakage. However, I contacted you (and your colleague) and
> haven't received
> any feedback for a couple of weeks.
Right although I did give you feedback that what you sent wasn’t in a suitable
form for review wrt Ada.
Arno
> Similarly to other manuals, we should include the page
> in HTML builder.
>
> What Ada folks think about it?
The latest changes have broken our build of the Ada doc at AdaCore so until
further notice, please do not make any additional changes to the Ada doc while
we review in details all t
> This was introduced with the fix and backports of PR103530 on
> x86_64-linux-gnux32 with older glibc versions (checked with 2.31), where
> dladdr is still in the libdl.so library, and not included in libc.so as in
> newer glibc versions.
> Linking of libgnat.so fails with
>
> [...]
> /usr/x86_64
> GCC fails to bootstrap when configured with --enable-languages=all on
> machines that have older versions of GNAT installed as the system Ada
> compiler. In configure, it's not sufficient to check whether gnat is
> available, but whether a sufficiently recent version of GNAT is
> installed. Thi
OK, thanks.
> IIRC, this latter requirement is particularly important for canadian
> crosses, but it applies as a general recommendation, and GNAT often
> takes advantage of that to use features that will be disregarded by
> stage1 (no optimization, no fatal warnings, limited runtime, etc), but
> that must be
> egrep has been deprecated in favor of grep -E for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of egrep is used.
> Stop using egrep so we won't see the warning.
>
> However, simply replacing egrep with grep -E will break build on some
> systems (notably Solaris) w/o
> egrep has been deprecated in favor of grep -E for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of egrep is used.
> Stop using egrep so we won't see the warning.
Ada part is OK, thanks.
> gcc/testsuite/ChangeLog:
>
> * ada/acats/run_all.sh: Use grep -E instea
> > In order to build GNAT, the Ada compiler, you need a working GNAT
> > -compiler (GCC version 4.7 or later).
> > +compiler (GCC version 5.1 or later).
> >
> > This includes GNAT tools such as @command{gnatmake} and
> > @command{gnatlink}, since the Ada front end is written in Ada and
>
> I'v
> > Similarly in GCC itself. I've built all FEs with the patch.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
>
> OK for the middle-end parts.
and OK for the Ada parts.
> > So I don't see how your patch can work, can you clarify?
>
> Sorry for that, fixed in the updated version.
Assuming you're getting a successful Ada build, the Ada part is OK.
> From 5ad8fe059d3419446647eadf8785c768b647d15b Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Thu, 13 Jan 20
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ada/ChangeLog:
>
> * locales.c (iso_639_1_to_639_3): Use ARRAY_SIZE.
> (language_name_to_639_3): Likewise.
> (country_name_to_3166): Likewise.
Can you
This patch is OK, thank you and sorry for the breakage!
Arno
> Commit 621cccba3f8b0cd2757feda171e66e3820b55c2c broke the Ada build for all
> RTEMS targets except aarch64.
>
> gcc/ada/
>
>* tracebak.c: Add support for ARM RTEMS. Add support for RTEMS to PPC
>ELF. Add support for RTEMS
> Thank you all for your feedback and guidance. I have taken Eric's
> feedback and deleted the relevant entry.
>
> Since I do not have write access, I cannot add myself to the
> MAINTAINERS file. Therefore, I want to explicitly state that I am
> submitting these patches under the DCO. I have read
> Thank you for the feedback. Should I remove it and resuply the patch or
> can you/GCC maintainers do the modification before merging?
Can you please resubmit it?
I'll let others comment on the need to sign a contributor agreement, my
understanding is that this is unavoidable, whether you're con
> This warning will become ERROR in stage2 of bootstrap when use
> " make BOOT_CFLAGS='-O0' BOOT_CXXFLAGS='-O0' " command.
> So it is better to fix this warning.
> There are other similar warnings. I will submit patches one by one.
>
> Tested on x86_64. OK for trunk?
This is OK (pretty much obv
> The following arranges for s-oscons.ads to record target_noncanonical
> for Target_Name, matching the install directory layout and what
> gcc -dumpmachine says. This fixes build issues with gprbuild.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed as
> approved in bugzilla.
>
>
> Use the Long Long Float wrapper in terms of Long Float for Alpha/Linux
> targets as well, fixing gnatlib compilation errors:
>
> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on result
> [enabledby default]
> a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on parame
> > OK, thanks.
>
> OK for backports?
Yes.
> OK for backports?
Yes.
OK, thanks.
> Since the x86_64-linux-gnux32 compiler is actually an x32 compiler, set
> target_cpu to x32 for x86_64-linux-gnux32.
>
> PR ada/103538
> * gcc-interface/Makefile.in (target_cpu): Set to x32 for
> x86_64-linux-gnux32.
> ---
> gcc/ada/gcc-interface/Makefile.in | 7 +
OK, thanks.
> PR ada/103538
> * Makefile.rtl (LIBGNAT_TARGET_PAIRS): Add
> $(TRASYM_DWARF_UNIX_PAIRS),
> s-tsmona.adb $(GNATRTL_128BIT_PAIRS).
> (EXTRA_GNATRTL_NONTASKING_OBJS): Add $(TRASYM_DWARF_UNIX_OBJS)
> and $(GNATRTL_128BIT_OBJS).
> ---
> gcc/ada/M
> Unfortunately it's not OK, these are the most annoying/delicate dependencies,
> so
> we'd rather not reintroduce them. I'll instead update prerequisites to
> document that GCC 5.1 or later is required to build GNAT.
Now pushed on master:
Update prerequisites for GNAT
* doc/install
Thomas,
> OK to push (after more testing) the attached
> 'Revert parts of "[Ada] Reduce runtime dependencies on stage1"', for the
> reason detailed therein? Should the comment before 'GNAT1_C_OBJS' be
> re-instated/adjusted, too? Would appreciate a careful review, as I don't
> really know what I
> Allow the Ada runtimes to find GCC runtimes relative to their non-
> standard install positions.
>
> gcc/ada/
> * gcc-interface/Makefile.in: Add @loader_path runpaths to the
> libgnat and libgnarl shared library builds.
OK, thanks.
> Most of the time we get away with using the dsymutil that is
> installed with the latest Xcode, however for some cross-compilation
> cases that does not work.
>
> We now have the ability to specify the correct dsymutil to use for
> the toolchain (--with-dsymutil=) and we should use that specifie
> I apologize this is the diff I meant to send:
Thanks for sending this diff.
Note that in order to allow a review (and approval) of your change,
you need to send also an explanation of your change, as well as the
corresponding commit log.
Thanks in advance!
Arno
> No, I just managed to delete it when adding the post-notes to the email
> header ;-) … and then didn’t notice when git send-emailing it …
OK!
> Signed-off-by: Iain Sandoe
>
> gcc/ada/ChangeLog:
should be gcc/ada/
> * gcc-interface/Make-lang.in: Use ios signal trampoline code
> f
> This is host-only support (target support will come later).
>
> This will allow someone (with an existing Ada compiler on the
> platform - which can be provided by the experimental aarch64-darwin
> branch) - to build the host tools (gnatmake and friends) for a
> non-native cross.
>
> The existi
43 matches
Mail list logo
