Re: [PATCH] ada: Fix musl build on Linux

2023-02-08 Thread Arnaud Charlet via Gcc-patches
> 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_debug. 
> 
> 
> [1] 
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f2b30a724e6bf7ff8e591b176967d596cee7648e;hp=83e8d37fe39d7c1afce19b61bbc2dd828fa37c6f
> [2] https://git.musl-libc.org/cgit/musl/tree/include/link.h#n39
> [3] 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/link.h;h=3b5954d9818e8ea9f35638c55961f861f6ae6057;hb=HEAD#l66
> [4] https://git.uclibc.org/uClibc/tree/include/link.h#n71
> 
> OK? Bootstrapped and tested on aarch64-linux-(gnu|musl),
> riscv64-linux-(gnu|musl) and x86_64-linux-(gnu|musl) with no regressions.

OK, thanks,

> gcc/ada/
> 
> * adaint.c [Linux]: Include .
> (__gnat_get_executable_load_address) [Linux]: Enable only for glibc & uClibc
> on Linux.


Re: [PATCH 1/2 v2] Ada: Synchronized private extensions are always limited

2023-09-13 Thread Arnaud Charlet via Gcc-patches
> 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 to follow instructions from https://gcc.gnu.org/contribute.html
and in particular meet the legal requirements.

Then get someone with write approval to commit the change.

Arno


Re: [PATCH 2/2 v3] Ada: Finalization of constrained subtypes of unconstrained synchronized private extensions

2023-09-18 Thread Arnaud Charlet via Gcc-patches
> 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 now OK.


Re: [PING][PATCH 1/2] Ada: Synchronized private extensions are always limited

2023-09-01 Thread Arnaud Charlet via Gcc-patches
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 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'
> ; 'Stephen Baird' 
> Subject: [PATCH 1/2] Ada: Synchronized private extensions are always limited
> 
>  
> 
> GNAT currently considers a synchronized private extension that derives from
> an interface to be limited only when said interface is a concurrent
> interface. However it is of course legal for a synchronized private
> extension to derive from a limited interface. In this case GNAT fails to
> correctly determine that the private extension is limited.
> 
>  
> 
> This causes two separate problems that makes discriminated types in such a
> case impossible:
> 
> 1.GNAT inappropriately rejects compilation, claiming default
> discriminants on such a private extension are illegal.
> 2.GNAT fails to generate the expected discriminals for the
> unconstrained discriminanted case, leading to the corresponding
> discriminants of the "corresponding record" of the underlying concurrent
> type to have no identifiers, and thus compilation fails.
> 
>  
> 
> Fairly simple fix. If "synchronized" appears in the private extension
> declaration, it is limited. This is explicit in the RM as well (7.3(6/2)).
> 
>  
> 
> Fixing this bug uncovered of a related bug wrt. TSS address finalizer
> generation for constrained subtypes of synchronized private extensions with
> no default discriminants. That patch is to follow separately.
> 
>  
> 
> Patch file is attached.
> 
>  
> 
> --  Begin change log entry --
> 
>  
> 
> ada: Private extensions with the keyword "synchronized" are always limited.
> 
>  
> 
> GNAT was relying on synchronized private type extensions deriving from a
> concurrent interface to determine its limitedness. This does not cover the
> case where such an extension derives a limited interface. RM-7.6(6/2) makes
> is clear that "synchronized" in a private extension implies the derived type
> is limited. GNAT should explicitly check for the presence of "synchronized"
> in a private extension declaration, and it should have the same effect as
> the presence of "limited".
> 
>  
> 
> gcc/ada/
> 
> * sem_ch3.adb (Build_Derived_Record_Type): Treat presence of
> keyword "synchronized" the same as "limited" when determining if a private
> extension is limited.
> 
> 
> -- End change log entry --
>  
> 
> This patch was bootstrapped on x86_64-*-freebsd13.2. Two new test cases were
> added. Note that 4 gnat test cases fail currently on master and are
> unrelated to this patch.


Re: [PING][PATCH 1/2] Ada: Synchronized private extensions are always limited

2023-09-01 Thread Arnaud Charlet via Gcc-patches
> 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 did contain the patch easily found, sorry for the noise!

Arno


Re: [PATCH][Ada] Fix syntax errors in expect.c

2023-09-01 Thread Arnaud Charlet via Gcc-patches
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:13:virhe: expected ”(” before numeric constant
>  353 |   } else if WIFSTOPPED(status) {
>  | ^~
> expect.c:358:1:varoitus: ei-void-tyyppisen funktion loppu saavutettu 
> [-Wreturn-type]
>  358 | }
>  | ^
> make[5]: *** [../gcc-interface/Makefile:297: expect.o] Error 1
> 
> Errors were there since commit 9e6274e0a3b60e77a42784c3fb6ef2aa3cfc071a(Wed
> Dec 15 19:26:50 2021 +0600)
> 
> Fixing these errors (attached patch for master branch) was not sufficient
> for building Ada cross-compiler, but it fixed compiler errors.
> 
> This would perhaps qualify for trivial change, but it seems that I no more
> have write access (I got it in 2015, but have not used it for a long time.
> Perhaps I do not really need it)
> 
> Andris
> 
> commit 64c48aa99656e06d5728bf5837da3bbc50ae4cc5
> Author: Andris Pavēnis 
> Date:   Sat Aug 19 10:40:22 2023 +0300
> 
> Fix syntax error
> 
> gcc/ada/expect.c(__gnat_waitpid):
> fix syntax errors


Re: [PING][PATCH] LoongArch: initial ada support on linux

2023-09-01 Thread Arnaud Charlet via Gcc-patches
> 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 multilib.
> ---
> --- a/gcc/ada/Makefile.rtl
> +++ b/gcc/ada/Makefile.rtl
> @@ -2111,6 +2111,55 @@ ifeq ($(strip $(filter-out cygwin% mingw32% 
> pe,$(target_os))),)
>LIBRARY_VERSION := $(LIB_VERSION)
>  endif
>  
> +# LoongArch Linux
> +ifeq ($(strip $(filter-out loongarch% linux%,$(target_cpu) $(target_os))),)
> +  LIBGNAT_TARGET_PAIRS = \
> +  a-exetim.adb +  a-exetim.ads +  a-intnam.ads +  a-nallfl.ads +  a-synbar.adb +  a-synbar.ads +  s-inmaop.adb +  s-intman.adb +  s-linux.ads +  s-mudido.adb +  s-osinte.ads +  s-osinte.adb +  s-osprim.adb +  s-taprop.adb +  s-tasinf.ads +  s-tasinf.adb +  s-tpopsp.adb +  s-taspri.ads +  g-sercom.adb +  $(TRASYM_DWARF_UNIX_PAIRS) \
> +  $(GNATRTL_128BIT_PAIRS) \
> +  s-tsmona.adb +  $(ATOMICS_TARGET_PAIRS) \
> +  $(ATOMICS_BUILTINS_TARGET_PAIRS) \
> +  system.ads +
> +  TOOLS_TARGET_PAIRS = indepsw.adb +
> +  EXTRA_GNATRTL_NONTASKING_OBJS += $(TRASYM_DWARF_UNIX_OBJS)
> +  EXTRA_GNATRTL_NONTASKING_OBJS += $(GNATRTL_128BIT_OBJS)
> +  EXTRA_GNATRTL_TASKING_OBJS = s-linux.o a-exetim.o
> +
> +  EH_MECHANISM = -gcc
> +  THREADSLIB = -lpthread
> +  MISCLIB = -ldl
> +  GNATLIB_SHARED = gnatlib-shared-dual
> +  GMEM_LIB = gmemlib
> +  LIBRARY_VERSION := $(LIB_VERSION)
> +  # Temporarily disable strict alignment -- for some reason, it causes
> +  # infinite loops during stack unwinding (libgcc) and indefinite hang
> +  # in some futex system calls.
> +  GNATLIBCFLAGS := $(GNATLIBCFLAGS) -mno-strict-align
> +  GNATLIBCFLAGS_FOR_C := $(GNATLIBCFLAGS_FOR_C) -mno-strict-align

Patch looks indeed OK.
A small nit above: I'd suggest using += instead of := $(XXX) to make things
clearer.

Arno


Re: [PATCH v2] LoongArch: initial ada support on linux

2023-09-04 Thread Arnaud Charlet via Gcc-patches
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 explicit for multilib.


Re: [PATCH 7/8] testsuite: use grep -E instead of egrep

2022-06-24 Thread Arnaud Charlet via Gcc-patches
> 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 instead of egrep.
>   * go.test/go-test.exp: Likewise.
> ---
>  gcc/testsuite/ada/acats/run_all.sh | 2 +-
>  gcc/testsuite/go.test/go-test.exp  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/ada/acats/run_all.sh 
> b/gcc/testsuite/ada/acats/run_all.sh
> index ac2a86bea6c..a48b492711b 100755
> --- a/gcc/testsuite/ada/acats/run_all.sh
> +++ b/gcc/testsuite/ada/acats/run_all.sh
> @@ -367,7 +367,7 @@ for chapter in $chapters; do
>target_run $dir/tests/$chapter/$i/$binmain > 
> $dir/tests/$chapter/$i/${i}.log 2>&1
>cd $dir/tests/$chapter/$i
>cat ${i}.log >> $dir/acats.log
> -  egrep -e '( |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
> +  grep -E -e '( |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
>if [ $? -ne 0 ]; then
>   grep 'tasking not implemented' ${i}.log > /dev/null 2>&1
>  
> diff --git a/gcc/testsuite/go.test/go-test.exp 
> b/gcc/testsuite/go.test/go-test.exp
> index 11c178ad7ec..5699d3d248d 100644
> --- a/gcc/testsuite/go.test/go-test.exp
> +++ b/gcc/testsuite/go.test/go-test.exp
> @@ -1207,7 +1207,7 @@ proc go-gc-tests { } {
>  || $test_line == "// \$G \$D/empty.go && errchk \$G 
> \$D/\$F.go" } {
>   # These tests import the same package under two different
>   # names, which gccgo does not support.
> - } elseif { $test_line == "// \$G -S \$D/\$F.go | egrep initdone 
> >/dev/null && echo BUG sinit || true" } {
> + } elseif { $test_line == "// \$G -S \$D/\$F.go | grep -E initdone 
> >/dev/null && echo BUG sinit || true" } {
>   # This tests whether initializers are written out
>   # statically.  gccgo does not provide a way to test that,
>   # as an initializer will be generated for any code which
> -- 
> 2.36.1
> 
> 


Re: [PATCH v2 5/7] testsuite: stop using obsoleted egrep

2022-06-26 Thread Arnaud Charlet via Gcc-patches
> 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 a POSIX-conform grep.  We detect a
> suitable command with AC_PROG_EGREP, and pass it to run_acats.sh for
> Ada.
> 
> For Go, simply use grep instead of egrep as the pattern does not need
> any ERE features.
> 
> gcc/ChangeLog:
> 
>   * Makefile.in (EGREP): New variable.
>   * configure.ac (AC_PROG_EGREP): Call it.
>   * configure: Regenerate.
> 
> gcc/ada/ChangeLog:
> 
>   * gcc-interface/Make-lang.in: Pass EGREP to run_acats.sh.

The Ada change is OK

Arno


Re: [Ada] Remove useless pragma Warnings Off from runtime units

2022-06-28 Thread Arnaud Charlet via Gcc-patches
> 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 available in later stages and in cross builds, which is
> easy to satisfy by using the same compiler version, and which is a given
> when bootstrapping.
> 
> Of course it isn't always the case that you will run into problems when
> deviating from these recommendations, so it's perfectly possible that
> you get lucky building it all using compilers that don't meet the
> recommendations to get started, but that's counting on luck, not on a
> reliable procedure.
> 
> See note Prerequisites in the GCC Installation manual for more details.

Right, see https://gcc.gnu.org/install/prerequisites.html (GNAT section).
The only combination that is guaranteed to work is to use the same
version for the native compiler to build the cross.

The error reported here is one example showing why using another version
will not work in general.

Arno


Re: [Ada] Fix typos in comments

2022-07-18 Thread Arnaud Charlet via Gcc-patches
OK, thanks.


Re: [Ada PATCH] Update configure to check for a recent gnat Ada compiler.

2022-08-01 Thread Arnaud Charlet via Gcc-patches
> 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.  This patch tweaks config/acx.m4 so that conftest.adb also
> contains a reference to System.CRTL.int64 as required by the current
> version of gcc/ada/osint.adb.  This fixes the build when the system
> Ada is GNAT v4.8.5 (on Redhat 7) by disabling ada, but continues to
> work fine when the system Ada is GNAT v11.3.1.
> 
> Tested in x86_64-pc-linux-gnu.  Ok for mainline?
> 
> 
> 2022-07-30  Roger Sayle  
> 
> ChangeLog
> * config/acx.me (AC_PROG_GNAT): Update conftest.adb to include
> features required of the host gnat compiler.
> * configure: Regenerate.
> 
> Thanks in advance,
> Roger
> --
> 

> diff --git a/config/acx.m4 b/config/acx.m4
> index b86c4f9..bd3e7f8 100644
> --- a/config/acx.m4
> +++ b/config/acx.m4
> @@ -396,6 +396,10 @@ AC_CHECK_TOOL(GNATMAKE, gnatmake, no)
>  AC_CACHE_CHECK([whether compiler driver understands Ada],

I'd suggest changing the text above to e.g. "whether compiler driver 
understands Ada and is recent enough"

OK with this change, thanks!

>acx_cv_cc_gcc_supports_ada,
>  [cat >conftest.adb < +pragma Warnings (Off);
> +with System.CRTL;
> +pragma Warnings (On);
> +use type System.CRTL.int64;
>  procedure conftest is begin null; end conftest;
>  EOF
>  acx_cv_cc_gcc_supports_ada=no
> diff --git a/configure b/configure
> index 65d7078..3ddcc9f 100755
> --- a/configure
> +++ b/configure
> @@ -5608,6 +5608,10 @@ if ${acx_cv_cc_gcc_supports_ada+:} false; then :
>$as_echo_n "(cached) " >&6
>  else
>cat >conftest.adb < +pragma Warnings (Off);
> +with System.CRTL;
> +pragma Warnings (On);
> +use type System.CRTL.int64;
>  procedure conftest is begin null; end conftest;
>  EOF
>  acx_cv_cc_gcc_supports_ada=no



Re: [wwwdocs] Add Ada's GCC13 changelog entry

2023-03-27 Thread Arnaud Charlet via Gcc-patches
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,
> Fernando Oleo Blanco

> From d273bb1835c1ef23e15d422bed22ca5d333cbdae Mon Sep 17 00:00:00 2001
> From: Fernando Oleo Blanco 
> Date: Sun, 26 Mar 2023 14:20:36 +0200
> Subject: [PATCH 1/1] [PATCH] Add Ada's entry in the v13 changelog
> 
> Signed-off-by: Fernando Oleo Blanco 
> ---
>  htdocs/gcc-13/changes.html | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> index ff70d2ee..2e25bcf5 100644
> --- a/htdocs/gcc-13/changes.html
> +++ b/htdocs/gcc-13/changes.html
> @@ -160,7 +160,16 @@ a work-in-progress.
>  
>  New Languages and Language specific improvements
>  
> -
> +Ada
> +
> +  Traceback support added in RTEMS for the PPC ELF and ARM 
> architectures.
> +  Support for versions older than VxWorks 7 has been removed.
> +  General improvements to the contracts in the standard libraries.
> +  Addition of GNAT.Binary_Search.
> +  Further additions and fixes for the Ada 2022 specification.
> +  The Pragma SPARK_Mode=>Auto is now accepted. Contract 
> analysis has been further improved.
> +  Documentation improvements.
> +
>  
>  C family
>  
> -- 
> 2.40.0
> 



Re: [11/13] ada: don't map NULL decl to locus

2022-12-27 Thread Arnaud Charlet via Gcc-patches


>> 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 position 
> than me to assess validity of a NULL "decl" here.

I confirm that this is OK and expected.

Arno

Re: [PATCH] Ada, Darwin: Do not link libgcc statically on Darwin [PR108202].

2023-01-02 Thread Arnaud Charlet via Gcc-patches
> 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 trunk?
> > Iain
> 
> revised:
> 
> [PATCH] Ada,Darwin: Do not link libgcc statically on Darwin 8 and 9  
> [PR108202].
> 
> Normally, GCC executables are built with -static-libstdc++ -static-libgcc
> on Darwin.  This is fine in most cases, because GCC executables typically
> do not use exceptions.   However gnat1 does use exceptions and also pulls
> in system libraries that are linked against the installed shared libgcc
> which contains the system unwinder.  This means that gnat1 effectively has
> two unwinder instances (which does not work reliably since the unwinders
> have global state).
> 
> A recent change in the initialization of FDEs has made this a hard error
> now on Darwin versions (8 and 9) with libgcc installed in /usr/lib (gnat1
> now hangs when an exception is thrown).
> 
> The solution is to link libgcc dynamically, picking up the installed
> system version.  To do this we strip -static-libgcc from the link flags.
> 
>   PR ada/108202
> 
> gcc/ada/ChangeLog:
> 
>   * gcc-interface/Make-lang.in (GCC_LINKERFLAGS, GCC_LDFLAGS):
>   Versions of ALL_LINKERFLAGS, LDFLAGS with -Werror and
>   -static-libgcc filtered out for Darwin8 and 9 (-Werror is filtered
>   out for other hosts).


Re: [PATCH] ada: Respect GNATMAKE

2023-01-17 Thread Arnaud Charlet via Gcc-patches


> 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 | 6 +++---
> gcc/ada/gcc-interface/Makefile.in | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/ada/Make-generated.in b/gcc/ada/Make-generated.in
> index 948fc508a56..34c86b2cd63 100644
> --- a/gcc/ada/Make-generated.in
> +++ b/gcc/ada/Make-generated.in
> @@ -18,7 +18,7 @@ GEN_IL_FLAGS = -gnata -gnat2012 -gnatw.g -gnatyg -gnatU 
> $(GEN_IL_INCLUDES)
> ada/seinfo_tables.ads ada/seinfo_tables.adb ada/sinfo.h ada/einfo.h 
> ada/nmake.ads ada/nmake.adb ada/seinfo.ads ada/sinfo-nodes.ads 
> ada/sinfo-nodes.adb ada/einfo-entities.ads ada/einfo-entities.adb: 
> ada/stamp-gen_il ; @true
> ada/stamp-gen_il: $(fsrcdir)/ada/gen_il*
>$(MKDIR) ada/gen_il
> -cd ada/gen_il; gnatmake -q -g $(GEN_IL_FLAGS) gen_il-main
> +cd ada/gen_il; $(GNATMAKE) -q -g $(GEN_IL_FLAGS) gen_il-main
># Ignore errors to work around finalization issues in older compilers
>- cd ada/gen_il; ./gen_il-main
>$(fsrcdir)/../move-if-change ada/gen_il/seinfo_tables.ads 
> ada/seinfo_tables.ads
> @@ -39,14 +39,14 @@ ada/stamp-gen_il: $(fsrcdir)/ada/gen_il*
> # would cause bootstrapping with older compilers to fail. You can call it by
> # hand, as a sanity check that these files are legal.
> ada/seinfo_tables.o: ada/seinfo_tables.ads ada/seinfo_tables.adb
> -cd ada ; gnatmake $(GEN_IL_INCLUDES) seinfo_tables.adb -gnatU -gnatX
> +cd ada ; $(GNATMAKE) $(GEN_IL_INCLUDES) seinfo_tables.adb -gnatU -gnatX
> 
> ada/snames.h ada/snames.ads ada/snames.adb : ada/stamp-snames ; @true
> ada/stamp-snames : ada/snames.ads-tmpl ada/snames.adb-tmpl ada/snames.h-tmpl 
> ada/xsnamest.adb ada/xutil.ads ada/xutil.adb
>-$(MKDIR) ada/bldtools/snamest
>$(RM) $(addprefix ada/bldtools/snamest/,$(notdir $^))
>$(CP) $^ ada/bldtools/snamest
> -cd ada/bldtools/snamest; gnatmake -q xsnamest ; ./xsnamest
> +cd ada/bldtools/snamest; $(GNATMAKE) -q xsnamest ; ./xsnamest
>$(fsrcdir)/../move-if-change ada/bldtools/snamest/snames.ns ada/snames.ads
>$(fsrcdir)/../move-if-change ada/bldtools/snamest/snames.nb ada/snames.adb
>$(fsrcdir)/../move-if-change ada/bldtools/snamest/snames.nh ada/snames.h
> diff --git a/gcc/ada/gcc-interface/Makefile.in 
> b/gcc/ada/gcc-interface/Makefile.in
> index da6a56fcec8..c8c38acf447 100644
> --- a/gcc/ada/gcc-interface/Makefile.in
> +++ b/gcc/ada/gcc-interface/Makefile.in
> @@ -616,7 +616,7 @@ OSCONS_EXTRACT=$(GCC_FOR_ADA_RTS) $(GNATLIBCFLAGS_FOR_C) 
> -S s-oscons-tmplt.i
>-$(MKDIR) ./bldtools/oscons
>$(RM) $(addprefix ./bldtools/oscons/,$(notdir $^))
>$(CP) $^ ./bldtools/oscons
> -(cd ./bldtools/oscons ; gnatmake -q xoscons)
> +(cd ./bldtools/oscons ; $(GNATMAKE) -q xoscons)
> 
> $(RTSDIR)/s-oscons.ads: ../stamp-gnatlib1-$(RTSDIR) s-oscons-tmplt.c 
> gsocket.h ./bldtools/oscons/xoscons
>$(RM) $(RTSDIR)/s-oscons-tmplt.i $(RTSDIR)/s-oscons-tmplt.s
> -- 
> 2.39.0
> 


Re: PING [PATCH] Avoid a warning of overflow

2022-03-21 Thread Arnaud Charlet via Gcc-patches
> 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 obvious), thanks.

> > -Original Message-
> > From: Qian Jianhua 
> > Sent: Friday, March 18, 2022 6:02 PM
> > To: Qian, Jianhua/钱 建华 
> > Subject: [PATCH] Avoid a warning of overflow
> > 
> > This patch avoid a warning of "c-ada-spec.cc:1660:34: warning:
> > 'sprintf' may write a terminating nul past the end of the destination
> > [-Wformat-overflow=]" when build GCC.
> > 
> > gcc/c-family/
> > * c-ada-spec.cc: Change array length
> > 
> > ---
> >  gcc/c-family/c-ada-spec.cc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/gcc/c-family/c-ada-spec.cc b/gcc/c-family/c-ada-spec.cc index
> > 149d336ee96..aeb429136b6 100644
> > --- a/gcc/c-family/c-ada-spec.cc
> > +++ b/gcc/c-family/c-ada-spec.cc
> > @@ -1579,7 +1579,7 @@ dump_ada_function_declaration (pretty_printer
> > *buffer, tree func,
> >tree type = TREE_TYPE (func);
> >tree arg = TYPE_ARG_TYPES (type);
> >tree t;
> > -  char buf[17];
> > +  char buf[18];
> >int num, num_args = 0, have_args = true, have_ellipsis = false;
> > 
> >/* Compute number of arguments.  */
> > --
> > 2.18.1


Re: [wwwdocs] Add Ada's changelog entry

2022-04-04 Thread Arnaud Charlet via Gcc-patches
> 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 contributing
code or documentation doesn't change this need AFAIU.

Arno


Re: [wwwdocs] Add Ada's changelog entry

2022-04-11 Thread Arnaud Charlet via Gcc-patches
> 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 and accept the
> indications and requirements listed in (https://gcc.gnu.org/dco.html).
> 
> There are two patches, the original one, with the DCO signature at the
> end and a second one, with the DCO signature too, with Eric's feedback.
> 
> Should anything else be required, do not hesitate to indicate so.

Thank you, I've just merged your contribution.

Arno


Re: [PATCH] ada: Fix build for RTEMS

2022-04-27 Thread Arnaud Charlet via Gcc-patches
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 to SPARC.  Merge aarch64 support of Linux
>and RTEMS.
> ---
> gcc/ada/tracebak.c | 32 ++--
> 1 file changed, 14 insertions(+), 18 deletions(-)
> 
> diff --git a/gcc/ada/tracebak.c b/gcc/ada/tracebak.c
> index 54e547d2414..6cc5d301737 100644
> --- a/gcc/ada/tracebak.c
> +++ b/gcc/ada/tracebak.c
> @@ -316,6 +316,13 @@ __gnat_backtrace (void **array,
> #define PC_ADJUST -2
> #define USING_ARM_UNWINDING 1
> 
> +/*-- ARM RTEMS  -*/
> +#elif (defined (__arm__) && defined (__rtems__))
> +
> +#define USE_GCC_UNWINDER
> +#define PC_ADJUST -2
> +#define USING_ARM_UNWINDING 1
> +
> /*-- PPC AIX/PPC Lynx 178/Older Darwin --*/
> #elif ((defined (_POWER) && defined (_AIX)) || \
>(defined (__powerpc__) && defined (__Lynx__) && !defined(__ELF__)) || \
> @@ -370,11 +377,12 @@ extern void __runnit(); /* thread entry point.  */
> 
> #define BASE_SKIP 1
> 
> -/*--- PPC ELF (GNU/Linux & VxWorks & Lynx178e) ---*/
> +/*--- PPC ELF (GNU/Linux & VxWorks & Lynx178e & RTEMS ) --*/
> 
> #elif (defined (_ARCH_PPC) && defined (__vxworks)) ||  \
>   (defined (__powerpc__) && defined (__Lynx__) && defined(__ELF__)) || \
> -  (defined (__linux__) && defined (__powerpc__))
> +  (defined (__linux__) && defined (__powerpc__)) || \
> +  (defined (__powerpc__) && defined (__rtems__))
> 
> #if defined (_ARCH_PPC64) && !defined (__USING_SJLJ_EXCEPTIONS__)
> #define USE_GCC_UNWINDER
> @@ -404,9 +412,9 @@ struct layout
> 
> #define BASE_SKIP 1
> 
> -/*-- SPARC Solaris -*/
> +/*-- SPARC Solaris or RTEMS */
> 
> -#elif defined (__sun__) && defined (__sparc__)
> +#elif (defined (__sun__) || defined (__rtems__)) && defined (__sparc__)
> 
> #define USE_GENERIC_UNWINDER
> 
> @@ -551,21 +559,9 @@ is_return_from(void *symbol_addr, void *ret_addr)
> #error Unhandled QNX architecture.
> #endif
> 
> -/* RTEMS -*/
> -
> -#elif defined (__rtems__)
> -
> -#define USE_GCC_UNWINDER
> -
> -#if defined (__aarch64__)
> -#define PC_ADJUST -4
> -#else
> -#error Unhandled RTEMS architecture.
> -#endif
> -
> -/*--- aarch64-linux --*/
> +/*--- aarch64-linux or aarch64-rtems -*/
> 
> -#elif (defined (__aarch64__) && defined (__linux__))
> +#elif (defined (__aarch64__) && (defined (__linux__) || defined (__rtems__)))
> 
> #define USE_GCC_UNWINDER
> #define PC_ADJUST -4
> -- 
> 2.34.1
> 


Re: [PATCH] Use more ARRAY_SIZE.

2022-05-09 Thread Arnaud Charlet via Gcc-patches
> 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 clarify where ARRAY_SIZE is defined? locales.c only contains:

#include 
#include 
#include 

So I don't see how your patch can work, can you clarify?
Also, did you perform a build with Ada enabled with this change?

Arno


Re: [PATCH] Use more ARRAY_SIZE.

2022-05-09 Thread Arnaud Charlet via Gcc-patches
> > 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 2022 18:46:26 +0100
> Subject: [PATCH] Use more ARRAY_SIZE.
> 
> 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.


Re: [PATCH] Replace PTR with 'void *' in compiler.

2022-05-10 Thread Arnaud Charlet via Gcc-patches
> > 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.


Re: [ada, patch] fix libgnat build on x86_64-linux-gnux32 with glibc <= 2.31

2022-11-07 Thread Arnaud Charlet via Gcc-patches
> 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-linux-gnux32/bin/ld: s-trasym.o: in function
> `system__traceback__symbolic__module_na
> me__getXnn':
> collect2: error: ld returned 1 exit status
> make[8]: *** [gcc-interface/Makefile:677: gnatlib-shared-default] Error 1
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=9d6c63ba490ec92245f04b5cbafc56abd28e8d22
> 
> -- a/gcc/ada/Makefile.rtl
> +++ b/gcc/ada/Makefile.rtl
> @@ -2650,13 +2650,18 @@ ifeq ($(strip $(filter-out %x32 linux%,$(target_cpu)
> $(target_os))),)
>s-tasinf.adbs-tpopsp.adbs-taspri.ads +  $(TRASYM_DWARF_UNIX_PAIRS) \
> +  s-tsmona.adb$(ATOMICS_TARGET_PAIRS) \
>$(X86_64_TARGET_PAIRS) \
> +  $(GNATRTL_128BIT_PAIRS) \
>system.ads 
> The addition of s-tsmona.adb reference to dladdr, however not setting MISCLIB to -ldl as on other
> architectures
> 
> Proposed patch:
> 
> 
>  PR ada/107475
>  * Makefile.rtl: Set MISCLIB for x86_64-linux-gnux32.
> 
> 
> --- a/gcc/ada/Makefile.rtl
> +++ b/gcc/ada/Makefile.rtl
> @@ -2584,6 +2584,7 @@ ifeq ($(strip $(filter-out %x32 linux%,$(target_cpu)
> $(target_os))),)
>EXTRA_GNATRTL_TASKING_OBJS=s-linux.o a-exetim.o
>EH_MECHANISM=-gcc
>THREADSLIB=-lpthread -lrt
> +  MISCLIB = -ldl
>GNATLIB_SHARED=gnatlib-shared-dual
>GMEM_LIB = gmemlib
>LIBRARY_VERSION := $(LIB_VERSION)
> 
> Ok for the trunk and the branches?

Yes, thanks.


Re: [PATCH] doc: Ada: include Indices and Tables in manuals

2022-11-11 Thread Arnaud Charlet via Gcc-patches


> 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 the recent changes and find a way to recover, thank 
you.

Arno 


Re: [PATCH] doc: Ada: include Indices and Tables in manuals

2022-11-13 Thread Arnaud Charlet via Gcc-patches


> 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

Re: [PATCH] doc: Ada: include Indices and Tables in manuals

2022-11-13 Thread Arnaud Charlet via Gcc-patches
> >> 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 gcc-patches wouldn't have worked either, 
> we've got quite a strict
> email size limit.
> 
> Anyway, hope the AdaCore build would be fixable with a reasonable amount of 
> effort?

Unclear yet. We'll probably need to change and possibly partially revert the
Ada changes, we'll see.

Arno


Re: [PATCH] doc: Ada: include Indices and Tables in manuals

2022-11-13 Thread Arnaud Charlet via Gcc-patches
>  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 gcc-patches wouldn't have worked either, 
> >> we've got quite a strict
> >> email size limit.

Note that the Ada part should have been quite limited in size given that the
doc was already in .rst format, which is why I was expecting a smaller patch
to review on the Ada side.

> >> Anyway, hope the AdaCore build would be fixable with a reasonable amount 
> >> of effort?
> > 
> > Unclear yet. We'll probably need to change and possibly partially revert the
> > Ada changes, we'll see.
> 
> Hello.
> 
> Note the Sphinx changes will be reverted today:
> https://gcc.gnu.org/pipermail/gcc/2022-November/239983.html
> 
> Sorry for your extra work.

Understood, thanks for your efforts and sorry you had to revert.

Clearly a change which requires a bleeding edge version of sphinx cannot be
pushed at this stage, that's premature.

Cheers,

Arno


Re: [gcc r12-6398] [Ada] Reduce runtime dependencies on stage1

2022-05-30 Thread Arnaud Charlet via Gcc-patches
> >  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've now tested that, but find that it doesn't work:
> 
> [...]
> gcc -c -g  -gnatpg -gnatwns -gnata -W -Wall -I- -I. -Iada/generated -Iada 
> -I[...]/source-gcc/gcc/ada [...]/source-gcc/gcc/ada/contracts.adb -o 
> ada/contracts.o

Ah, that's unfortunate. I guess on my side I'm using a version of GNAT built
without assertions, so not failing on this.

> So, what is actually the prerequisite GCC/Ada compiler version to be able
> to build GCC 12+ GCC/Ada?

I'm afraid I don't have more info at this stage, I assume GCC 6.1 would work
(not tested, if someone could confirm that would be great).

Arno


Re: [PATCH] [Ada] PR ada/98724: Alpha/Linux/libada: Use wraplf for Aux_Long_Long_Float

2022-02-13 Thread Arnaud Charlet via Gcc-patches
> 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 parameter 1 
> [enabled by default]
> a-nallfl.ads:48:13: warning: profile of "Sin" doesn't match the builtin it 
> binds [enabled by default]
> 
> etc. with the `alpha-linux-gnu' target.
> 
>   gcc/ada/
>   PR ada/98724
>   PR ada/97504
>   * Makefile.rtl (LIBGNAT_TARGET_PAIRS) : Use 
>   wraplf version of Aux_Long_Long_Float.
> ---
> Hi,
> 
>  OK for trunk and GCC 11?

OK, thanks.


Re: [PATCH] ada/104861 - use target_noncanonial for Target_Name

2022-03-10 Thread Arnaud Charlet via Gcc-patches
> 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.
> 
> OK also for branches after a while?

Yes, thanks.

> 2022-03-10  Richard Biener  
> 
>   PR ada/104861
> gcc/ada/
>   * gcc-interface/Makefile.in (target_noncanonical): Substitute.
>   (OSCONS_CPP): Pass target_noncanonical as TARGET.


Re: [PATCH] Darwin, Arm64 : Ada fixes for hosted tools.

2021-11-05 Thread Arnaud Charlet via Gcc-patches
> 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 existing provisions for iOS are OK for cross-compilation from
> an x86-64-darwin platform, but we need some adjustments so that these
> host tools can be built to run on aarch64-darwin.
> 
> tested on aarch64-darwin20.
> OK for master?

Did you forget to attach the commit log (git show is your friend)?

The patch itself looks OK on principle, pending the associated log! ;-)

Arno


Re: [PATCH] Darwin, Arm64 : Ada fixes for hosted tools.

2021-11-05 Thread Arnaud Charlet via Gcc-patches
> 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
>   for hosted Ada tools.
>   * sigtramp-ios.c: Wrap the declarations in extern "C" when the
>   code is built by a C++ compiler.

I confirm that the patch is OK, thanks!


Re: [PATCH] Combine malloc + memset to calloc

2021-11-12 Thread Arnaud Charlet via Gcc-patches
> 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


Re: [PATCH] Ada, Darwin : Use DSYMUTIL_FOR_TARGET in libgnat/gnarl builds.

2021-11-14 Thread Arnaud Charlet via Gcc-patches
> 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 specified
> tool for debug link.  Fixes cross-compilers from x86-64 to powerpc.
> 
> Tested on x86_64, i686 and with a cross from x86_64 -> powerpc, and
> with a bootstrap on x86_64-linux.
> 
> OK for master?

OK, thanks!


Re: [PATCH 4/4] Darwin, Ada : Add loader path as a default rpath.

2021-11-17 Thread Arnaud Charlet via Gcc-patches
> 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.


Re: [gcc r12-6398] [Ada] Reduce runtime dependencies on stage1

2022-01-18 Thread Arnaud Charlet via Gcc-patches
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'm doing there.  ;-)

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.

Sorry for the inconvenience!

Arno


Re: [gcc r12-6398] [Ada] Reduce runtime dependencies on stage1

2022-01-18 Thread Arnaud Charlet via Gcc-patches
> 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.texi: Update prerequisites for GNAT

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 54ad7c7..96b4dfc 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -263,7 +263,7 @@ name of the package depends on your distro) or you must 
build GCC as a
 @item @anchor{GNAT-prerequisite}GNAT

 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


Re: [PATCH 1/2] [Ada] Compile s-mmap and 128bit on x86_64-linux-gnux32

2022-01-19 Thread Arnaud Charlet via Gcc-patches
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/Makefile.rtl | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
> index 1b066ad6b14..6d60aea75a8 100644
> --- a/gcc/ada/Makefile.rtl
> +++ b/gcc/ada/Makefile.rtl
> @@ -2650,13 +2650,18 @@ ifeq ($(strip $(filter-out %x32 linux%,$(target_cpu) 
> $(target_os))),)
>s-tasinf.adbs-tpopsp.adbs-taspri.ads +  $(TRASYM_DWARF_UNIX_PAIRS) \
> +  s-tsmona.adb$(ATOMICS_TARGET_PAIRS) \
>$(X86_64_TARGET_PAIRS) \
> +  $(GNATRTL_128BIT_PAIRS) \
>system.ads  
>TOOLS_TARGET_PAIRS = indepsw.adb  
>EXTRA_GNATRTL_NONTASKING_OBJS=g-sse.o g-ssvety.o
> +  EXTRA_GNATRTL_NONTASKING_OBJS+=$(TRASYM_DWARF_UNIX_OBJS)
> +  EXTRA_GNATRTL_NONTASKING_OBJS+=$(GNATRTL_128BIT_OBJS)
>EXTRA_GNATRTL_TASKING_OBJS=s-linux.o a-exetim.o
>EH_MECHANISM=-gcc
>THREADSLIB=-lpthread -lrt
> -- 
> 2.34.1
> 


Re: [PATCH 2/2] [Ada] Set target_cpu to x32 for x86_64-linux-gnux32

2022-01-19 Thread Arnaud Charlet via Gcc-patches
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 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/gcc/ada/gcc-interface/Makefile.in 
> b/gcc/ada/gcc-interface/Makefile.in
> index 53d0739470a..b8a24708280 100644
> --- a/gcc/ada/gcc-interface/Makefile.in
> +++ b/gcc/ada/gcc-interface/Makefile.in
> @@ -350,6 +350,13 @@ ifeq ($(strip $(filter-out x86_64, $(target_cpu))),)
>endif
>  endif
>  
> +# The x86_64-linux-gnux32 compiler is actually an x32 compiler
> +ifeq ($(strip $(filter-out x86_64 linux-gnux32%, $(target_cpu) 
> $(target_os))),)
> +  ifneq ($(strip $(MULTISUBDIR)),/64)
> +target_cpu:=x32
> +  endif
> +endif
> +
>  # The SuSE PowerPC64/Linux compiler is actually a 32-bit PowerPC compiler
>  ifeq ($(strip $(filter-out powerpc64 suse linux%, $(target_cpu) 
> $(target_vendor) $(target_os))),)
>target_cpu:=powerpc
> -- 
> 2.34.1
> 


Re: [PATCH 1/2] [Ada] Compile s-mmap and 128bit on x86_64-linux-gnux32

2022-01-19 Thread Arnaud Charlet via Gcc-patches
> OK for backports?

Yes.


Re: [PATCH 2/2] [Ada] Set target_cpu to x32 for x86_64-linux-gnux32

2022-01-19 Thread Arnaud Charlet via Gcc-patches
> > OK, thanks.
> 
> OK for backports?

Yes.