> --- 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
> The base types are unchanged, the (non-private) subtypes defined in
> System.C_Time only add range constraints preventing some obviously
> invalid values. I do not understand how this could break existing
> code, could you please give an example?
OK, that should work indeed, so I withdraw my com
> In 0001-Ada-merge-all-timeval-and-timespec-definitions-and-c.patch:
>
> > - -- C timeval represent a duration (used in Select for example). This
> > - -- structure is composed of a number of seconds and a number of micro
> > - -- seconds. The timeval structure is not exposed here becaus
The change is OK, thanks.
> We suffer from an inconsistency in the names of uninstalled gnattools
> executables in cross-compiler configurations. The cause is a recipe we
> have:
>
> ada.all.cross:
> for tool in $(ADA_TOOLS) ; do \
> if [ -f $$tool$(exeext) ] ; \
> then \
Nicolas,
Thank you for such a large and delicate change!
This looks generally good, except for the first parts: we cannot change
documented/user
packages, meaning that GNAT.Calendar, System.OS_Lib (via the documented
GNAT.OS_Lib) and
Ada.Calendar.Conversion cannot be changed: we need to keep th
> The recent warning patches broke Ada bootstrap on Solaris:
>
> adaint.c: In function '__gnat_kill':
> adaint.c:3597:3: error: implicit declaration of function 'kill'
> [-Wimplicit-function-declaration]
> 3597 | kill (pid, sig);
> | ^~~~
>
> expect.c: In function '__gnat_expect_poll'
> >> #if defined (__APPLE__)
> >> -#include
> >
> > If removing unistd.h is intentional (i.e. you determined that it’s no longer
> > needed for Darwin), then we should make that a separate patch.
>
> I thought that I’d had to include unistd.h for the first patch in this
> thread; clearly not!
>
> OK so then the following is sufficient for our needs:
>
> #elif defined (__APPLE__)
>/* By default, macOS volumes are case-insensitive, iOS
> volumes are case-sensitive. */
> #if TARGET_OS_IOS
> file_names_case_sensitive_cache = 1;
> #else
> file_names_case_
> Apple’s naming is definitely confusing in this area!
>
> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X
> variant,
> which covers OSX, IOS, Watch … ; to determine which kind of device, you have
> to check the
> specific define for that device - OSX corresponds to
> > Please simplify the above to (untested):
> >
> > #elif defined (__APPLE__)
> >/* By default, macOS volumes are case-insensitive, iOS
> > volumes are case-sensitive. */
> > #if TARGET_OS_MAC/* macOS, in older SDK. */
> > file_names_case_sensitive_cache = 0;
> > #
> Also, should the test code below (between %%%) be included in the
> testsuite?
It would be good but tests shouldn't output anything, they should be self
testing,
and you will need to deal with making the test portable to all targets.
Given that the compiler itself uses this feature, I don't th
> >>> OK, I thought there would be some defines that we could use for that, too
> >>> bad if there isn't
> >>> and indeed we might need to perform another runtime check then as
> >>> suggested by Iain.
> >>
> >> I can see a possible interface, operatingSystemVersion in NSProcessInfo.h
> >> - Ob
Marc, can you please take care of it when you get a chance?
On Thu, Nov 09, 2023 at 11:22:21AM +, Simon Wright wrote:
> On 24 Oct 2023, at 10:49, Arnaud Charlet wrote:
> >
> > This change is OK, thank you.
>
> Can it be committed, then, please?
>
> >> Th
> "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!
> > So without changing fundamentally the model, you can't decide dynamically
> > for the whole
> > system. Making the choice based on the current directory is pretty random,
> > since the current
> > directory isn't well defined at program's start up and could be pretty much
> > any filesystem.
Hi Simon,
In addition to the non portable issues already mentioned, this change isn't OK
also
for other reasons.
Basically this function is global and decides once for all on the case
sensitivity, while
the case sensitiviy is on a per filsystem basis as you noted.
So without changing fundament
This change is OK, thank you.
> The description of the second Value function (returning Duration) (ARM
> 9.6.1(87)
> doesn't place any limitation on the Elapsed_Time parameter's value, beyond
> "Constraint_Error is raised if the string is not formatted as described for
> Image, or
> the funct
Hi Simon,
> Pierre-Marie, I’ve CC’d you hoping you’re an appropriate person to ping on
> this one.
> If not, who would be for this sort of change?
>
> I should have said, tested by
> - add test case, make -C gcc check-gnat: error reported
> - make -C gcc gnatlib_and_tools; make install
> - make
This is a great initiative I think.
See reference to AdaCore's security email below (among Debian, Red Hat,
SUSE)
On Mon, Aug 7, 2023 at 7:30 PM David Edelsohn via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> FOSS Best Practices recommends that projects have an official Security
> policy stat
> 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
rom a synchronized interface (see RM-7.3(6/2)).
the -> that does not derive...
OK with this change.
> From: Richard Wai
> Sent: Thursday, August 10, 2023 12:55 AM
> To: 'gcc-patches@gcc.gnu.org'
> Cc: 'Eric Botcazou' ; 'Arnaud Charlet'
> ;
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
>> The current statement (https://gcc.gnu.org/install/prerequisites.html) is:
>>
>> GNAT
>> In order to build GNAT, the Ada compiler, you need a working GNAT compiler
>> (GCC version 5.1 or later).
>>
>> so, if 5.1 is not working, then perhaps a PR is in order.
>
> I will do that, if the "sh
> 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
> Hi Arnaud, do I have permission to take/copy the code examples from
> AdaCore's blog entries? I could not find a "copy"right section or
> disclaimer. I know this is a very minor detail, but still. It would save
> me quite a bit of time :)
Yes, that’s fine.
Arno
> The wwwdocs repo is documented at https://gcc.gnu.org/about.html#git
>
> A change to those pages should be sent to the gcc-patc...@gcc.gnu.org
> mailing list like any other patch for GCC. You should include
> "wwwdocs" in the email Subject so people know to pay attention (or
> ignore it as appro
> >In particular can you explain the motivation behind all the changes in the
> >gcc/ada/doc directory?
>
> Sure:
> 1) All Sphinx manuals live in a directory where index page is called
> index.rst. That's why
> I moved e.g. this: gcc/ada/doc/{gnat_rm.rst => gnat_rm/index.rst}
> 2) I moved latex_e
> >In particular can you explain the motivation behind all the changes in the
> >gcc/ada/doc directory?
>
> Sure:
> 1) All Sphinx manuals live in a directory where index page is called
> index.rst. That's why
> I moved e.g. this: gcc/ada/doc/{gnat_rm.rst => gnat_rm/index.rst}
> 2) I moved latex_e
> I've got something that is very close to be a patch candidate that can be
> eventually merged. Right now, the patches are available here:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/sphinx-v3
FWIW I would prefer to review the changes posted here directly with a
> I've got something that is very close to be a patch candidate that can be
> eventually merged. Right now, the patches are available here:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/sphinx-v3
FWIW I would prefer to review the changes posted here directly with a
> >I've now committed it blindly (can't make things worse), let me know if the
> >problem is fully solved or if not, what output you are now getting.
>
> That is looking pretty good, thanks.
Great, thanks for confirming, and sorry again for the breakage on this
delicate change!
Arno
what output you are now getting.
--
commit 452321a9514a0ab4c01c0aba2a37de794cf69ef8
Author: Arnaud Charlet
Date: Wed Jun 16 03:55:17 2021 -0400
[Ada] Use runtime from base compiler during stage1 (continued)
gcc/ada/
* gcc-interface/Make-lang.in: Use libgnat.so if libgnat.a
> > gcc/ada/
> >
> > * Make-generated.in: Add rule to copy runtime files needed
> > during stage1.
> > * raise.c: Remove obsolete symbols used during bootstrap.
> > * gcc-interface/Make-lang.in: Do not use libgnat sources during
> > stage1.
> > (GNAT_ADA_OBJS, GNATBIND_OBJS
> RemovedInSphinx40Warning: app.add_lexer() API changed; Please give lexer
> class instead of instance
>
> Ready for master?
Yes, thanks (incidentally we just made the same change in our internal
tree today).
> Thanks,
> Martin
>
> gcc/ada/ChangeLog:
>
> * doc/share/conf.py: Fix Sphinx
> Right now, 2/3 of Ada manuals are both in .texi and .rst. I would like to port
> a small gnat-style manual based on [1].
>
> Ready for master?
OK, thanks.
> [1] https://github.com/davidmalcolm/texi2rst
>
> gcc/ada/ChangeLog:
>
> * doc/Makefile: Add gnat-style target.
> * doc/shar
> It's about more porting to Python3.
>
> Ready for master?
OK, thanks.
> gcc/ada/ChangeLog:
>
> * doc/share/conf.py: Do not use binary mode.
> Do not use u' literals as Python3 uses unicode by default.
> Thank you for a quick reply.
> There's an updated version of the patch.
The Ada part is OK now, thanks.
> The patchset is tested on x86_64-linux-gnu and I was able to build
> all cross-compilers.
>
> Ready to be installed to master once GCC 11.1 is released?
Not for the Ada part as just mentioned under your 1/3 email.
> gcc/ada/ChangeLog:
>
> * adadecode.c (has_prefix): Remove has_prefix and replace it
> with startswith.
> (__gnat_decode): Likewise.
This change is not OK: adadecode.c is also a runtime file and as such cannot
include compiler include files.
> * gcc-interface/utils.c (de
> >> With this patch the bottom navigation of the page at
> >> https://gcc.gnu.org/onlinedocs/gnat_ugn/index.html
> >> changes from
> >> Next: About This Guide, Up: (dir) [Contents][Index]
> >> to
> >> Next: About This Guide [Contents][Index]
> >> and the invalid "(dir)" link that pointed
> This is something I have been noticing for a while, and a hint by
> Sandra in a somewhat similar context taught me how to avoid it.
>
> With this patch the bottom navigation of the page at
> https://gcc.gnu.org/onlinedocs/gnat_ugn/index.html
> changes from
> Next: About This Guide, Up: (di
> Change the preprocessor logic so RTEMS uses utime().
> gcc/ada/
> * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
This change is OK.
> ---
> gcc/ada/adaint.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
> in
> I'm not sure I correctly understand you here, but my interpretation is that
> I should no longer submit Changelog entries, rather just the patch, and then
Right.
> a commit message (a-la git), and then presumably the Changelong entries will
> be generated automatically. From what I can see, gcc
> I appologise for making a mess of this final step. I have leared the errors
> of my ways.
Can you please submit everything self contained (the final final code changes
along with the commit log) so that we are sure the proper patch is
reviewed and approved?
> Below are the change log entries fo
> Oops, I wrote "effected" when I meant "affected". Of course, despite reading
> it several times before sending, I only noticed it after sending.
>
> Edited version:
>
> ---
>
> * libgnat/a-cohase.ads, libgnat/a-cohase.adb, libgnat/a-cohama.ads,
> libgnat/a-cohama.adb, libgnat/a-cihama.ads, lib
Richard,
Your patch is missing a corresponding commit log.
Can you please add it to your submission? Otherwise your test and patch
look good so far, thanks!
Arno
> We discovered an issue with the GNAT implementation of the hashed container
> types.
> > > > This fixes a compilation error preventing bootstrap with Ada on
> > > > x86_64-pc-cygwin. See PR bootstrap/94918 for details.
> > > >
> > > > Compared to the initial patch sent in May 2020, this v2 patch places
> > > > the fix in Ada's raise-gcc.c instead of the shared unwind-generic.h,
> >
>>> I did generate the ChangeLog by contrib/mklog.py by:
>>> contrib/mklog.py 0002_MY_PATCH.patch
>>> and get an empty ChangeLog template.
>>>
>>> gcc/ada/ChangeLog:
>>>
>>>* ChangeLog:
>>>* Makefile.rtl:
>>>
>>> So, should I keep it as is?
>>
>> The ChangeLog file is gene
> > > For MIPS N64 and N32:
> > > add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
> > > add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
> > >
> > > gcc/ada/ChangeLog:
> > > PR ada/98996
> > > * Makefile.rtl: add 128Bit operation file to MIPS
> > > N64 and N32 (LIBGN
> For MIPS N64 and N32:
> add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
> add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
>
> gcc/ada/ChangeLog:
> PR ada/98996
> * Makefile.rtl: add 128Bit operation file to MIPS
> N64 and N32 (LIBGNAT_TARGET_PAIRS, EXTRA_GNATRTL_
> > > For MIPS N64 and N32:
> > > add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
> > > add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
> > >
> > > gcc/ada/ChangeLog:
> > > PR ada/98996
> > > * Makefile.rtl (LIBGNAT_TARGET_PAIRS, EXTRA_GNATRTL_NONTASKING_OBJS)
> > >
+ : add 128Bit operation file to MIPS N64 and N32.
> +
> 2021-02-12 Arnaud Charlet
>
> * repinfo.ads, repinfo.adb (*SO_Ref*): Restore.
> diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
> index 35faf13ea46..d86eb8acbf3 100644
> --- a/gcc/ada/Makefile
> > We'd rather not have PR references in the source files, so please remove it
> > (it will be there as part of the commit log and git annotate).
> >
> > OK with the comment updated.
>
> Thanks, here's the revised patch.
OK, thanks.
> gcc/ada/
>
> 2021-02-05 Mikael Pettersson
>
> P
> This fixes the bootstrap failure with Ada on Cygwin since the switch
> to C++11. The configure checks detect that fileno_unlocked () is
> present, but when Ada's cstreams.c is compiled in C++11 mode,
> does not declare it, causing a hard error.
>
> Fixed by defining _GNU_SOURCE before including
This is OK, thanks.
> gcc/ada/
>
> PR ada/98595
> Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use
> wraplf version of Aux_Long_Long_Float.
> ---
> gcc/ada/Makefile.rtl | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
> index 8
Gerald,
Really sorry for the long delay on this one:
> > I spoke too fast, that was a 404 page.
> >
> > > -> > href="https://www2.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
> > > + https://www.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
> >
> > Arnaud, Eric, Pierre-Marie, what do y
> This fixes a compilation error preventing bootstrap with Ada on
> x86_64-pc-cygwin. See PR bootstrap/94918 for details.
>
> Compared to the initial patch sent in May 2020, this v2 patch places
> the fix in Ada's raise-gcc.c instead of the shared unwind-generic.h,
> which should hopefully simplif
> Thanks for responding to my post. I am not trying to generate C but to follow
> the intermediate representation into the Ada runtime.
>
> So let's just say we had this:
>
> with Ada.Text_IO;
> use Ada.Text_IO;
> procedure Do_Delays is
> begin
> Put_Line("Wait 5 seconds.");
> delay 5.0;
Pat,
Not sure what you are trying to do . Are you trying to generate C code
from Ada? If so, can you clarify why? In other words, what is the high level
problem you are trying to solve and that you'd like to achieve? Is it the
ability to navigate in Ada code?
If you want to generate C from Ada, G
> Fix PR ada/97504 for mips*-linux, the bootstrap works again on mips*-linux.
> Ok for the trunk?
OK, thanks.
> gcc/ada/
> PR ada/97504
> * Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use wraplf
> version of Aux_Long_Long_Float.
>
> --- a/gcc/ada/Makefile.rtl
> +++ b/gcc/ada/Makefile
1 - 100 of 2788 matches
Mail list logo
