Re: [PATCH] aix: handle 64bit inodes for include directories

[CHIGOT, CLEMENT via Gcc-patches]

Hi everyone,

Gentle ping

Thanks,
Clément

From: CHIGOT, CLEMENT 
Sent: Tuesday, October 26, 2021 4:51 PM
To: Jeff Law ; David Malcolm 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 

Subject: Re: [PATCH] aix: handle 64bit inodes for include directories

Hi everyone,

Gentle ping on this patch.

Clément

From: CHIGOT, CLEMENT 
Sent: Tuesday, October 12, 2021 10:35 AM
To: Jeff Law ; David Malcolm 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 

Subject: Re: [PATCH] aix: handle 64bit inodes for include directories

Hi Jeff,

Any update on this patch ?
As it's dealing with configure files, I would like to have it merged
asap before any conflicts appear.

Thanks,
Clément

Re: aix: Add FAT library support for libffi for AIX

[CHIGOT, CLEMENT via Gcc-patches]

> Even if GCC64 is able to boostrap without libffi being a
> FAT library on AIX, the tests for "-maix32" are not working
> without it.
> 
> libffi/ChangeLog:
> 2021-10-21  Clément Chigot  
> 
>       * Makefile.am (tmake_file): Build and install AIX-style FAT
>          libraries.
>       * Makefile.in: Regenerate.
>       * include/Makefile.in: Regenerate.
>       * man/Makefile.in: Regenerate.
>       * testsuite/Makefile.in: Regenerate.
>        * configure (tmake_file): Substitute.
>        * configure.ac: Regenerate.
>        * configure.host (powerpc-*-aix*): Define tmake_file.
>        * src/powerpc/t-aix: New file.
>
> I've already made a PR to libffi itself in order to add the common part of 
> this patch to it. But for now, it's still unmerged: 
> https://github.com/libffi/libffi/pull/661. 

Gentle ping, 

Thanks
Clément

Re: [PATCH] gcc: implement AIX-style constructors

[CHIGOT, CLEMENT via Gcc-patches]

> Hi David, 
> 
> Here is the new version of the patch. 
> I've moved the startup function in crtcdtors files.
> 
> I'm just wondering if the part dealing with the
> __init_aix_libgcc_cxa_atexit is needed. I'm adding it because
> the destructor created in crtcxa.o is following GCC format and
> thus won't be launched if the flag "-mcdtors=aix" is passed.
> However, as you said, this option might not operate correctly
> if the GCC runtime isn't rebuild with it.

Gentle Ping. 

Thanks, 
Clément

Re: [PATCH] gcc: implement AIX-style constructors

[CHIGOT, CLEMENT via Gcc-patches]

Hi David,

Here is the new version of the patch.
I've moved the startup function in crtcdtors files.

I'm just wondering if the part dealing with the
__init_aix_libgcc_cxa_atexit is needed. I'm adding it because
the destructor created in crtcxa.o is following GCC format and
thus won't be launched if the flag "-mcdtors=aix" is passed.
However, as you said, this option might not operate correctly
if the GCC runtime isn't rebuild with it.

Thanks,
Clément
From 8a14b0eb312628ad9cce8ac9f439c420b12b33c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?= 
Date: Mon, 4 Oct 2021 09:24:43 +0200
Subject: [PATCH] gcc: implement AIX-style constructors
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

AIX linker now supports constructors and destructors detection. For such
functions to be detected, their name must starts with __sinit or __sterm.
and -bcdtors must be passed to linker calls. It will create "_cdtors"
symbol which can be used to launch the initialization.

This patch creates a new RS6000 flag "-mcdtors=".
With "-mcdtors=aix", gcc will generate these new constructors/destructors.
With "-mcdtors=gcc", which is currently the default, gcc will continue
to generate "gcc" format for constructors (ie _GLOBAL__I and _GLOBAL__D
symbols).
Ideally, it would have been better to enable the AIX format by default
instead of using collect2. However, the compatibility between the
previously-built binaries and the new ones is too complex to be done.

gcc/ChangeLog:
2021-10-04  Clément Chigot  

	* collect2.c (aixbcdtors_flags): New variable.
	(main): Use it to detect -bcdtors and remove -binitfini flag.
	(write_c_file_stat): Adapt to new AIX format.
	* config/rs6000/aix.h (FILE_SINIT_FORMAT): New define.
	(FILE_STERM_FORMAT): New define.
	(TARGET_FILE_FUNCTION_FORMAT): New define.
	* config/rs6000/aix64.opt: Add -mcdtors flag.
	* config/rs6000/aix71.h (LINK_SPEC_COMMON): Pass -bcdtors when
	  -mcdtors=aix is passed.
	(STARTFILE_SPEC): Add crtcdtors.o with -mcdtors=aix.
	* config/rs6000/aix72.h (LINK_SPEC_COMMON): Likewise.
	(STARTFILE_SPEC): Likewise.
	* config/rs6000/aix73.h (LINK_SPEC_COMMON): Likewise.
	(STARTFILE_SPEC): Likewise.
	* config/rs6000/rs6000-opts.h (enum rs6000_cdtors): New enum.
	* doc/invoke.texi: Add -mcdtors flag.
	* tree.c (get_file_function_name): Add
	  TARGET_FILE_FUNCTION_FORMAT support.

libgcc/ChangeLog:

	* config.host: Add crtcdtors.o files.
	* config/rs6000/t-aix-cxa: Likewise.
	* config/rs6000/crtcdtors.c: New file.

gcc/testsuite/ChangeLog:
2021-10-04  Clément Chigot  

	* gcc.target/powerpc/constructor-aix.c: New test.
---
 gcc/collect2.c| 63 ---
 gcc/config/rs6000/aix.h   | 56 +
 gcc/config/rs6000/aix64.opt   | 17 +
 gcc/config/rs6000/aix71.h | 10 ++-
 gcc/config/rs6000/aix72.h | 10 ++-
 gcc/config/rs6000/aix73.h | 10 ++-
 gcc/config/rs6000/rs6000-opts.h   |  8 +++
 gcc/doc/invoke.texi   | 21 ++-
 .../gcc.target/powerpc/constructor-aix.c  | 12 
 gcc/tree.c|  5 ++
 libgcc/config.host|  2 +-
 libgcc/config/rs6000/crtcdtors.c  | 53 
 libgcc/config/rs6000/t-aix-cxa| 12 
 13 files changed, 260 insertions(+), 19 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/constructor-aix.c
 create mode 100644 libgcc/config/rs6000/crtcdtors.c

diff --git a/gcc/collect2.c b/gcc/collect2.c
index 33114322f01..3d04bc8465f 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -186,6 +186,7 @@ static int aix64_flag;			/* true if -b64 */
 static int aixrtl_flag;			/* true if -brtl */
 static int aixlazy_flag;		/* true if -blazy */
 static int visibility_flag;		/* true if -fvisibility */
+static int aixbcdtors_flag;/* True if -bcdtors */
 #endif
 
 enum lto_mode_d {
@@ -984,6 +985,8 @@ main (int argc, char **argv)
 	  aixrtl_flag = 0;
 	else if (strcmp (argv[i], "-blazy") == 0)
 	  aixlazy_flag = 1;
+	else if (strcmp (argv[i], "-bcdtors") == 0)
+	  aixbcdtors_flag = 1;
 #endif
   }
 
@@ -1731,7 +1734,9 @@ main (int argc, char **argv)
   /* Tell the linker that we have initializer and finalizer functions.  */
 #ifdef LD_INIT_SWITCH
 #ifdef COLLECT_EXPORT_LIST
-  *ld2++ = concat (LD_INIT_SWITCH, ":", initname, ":", fininame, NULL);
+  /* Do not emit -binitfini when -bcdtors is enabled. */
+  if (!aixbcdtors_flag)
+*ld2++ = concat (LD_INIT_SWITCH, ":", initname, ":", fininame, NULL);
 #else
   *ld2++ = LD_INIT_SWITCH;
   *ld2++ = initname;
@@ -2020,6 +2025,7 @@ write_c_file_stat (FILE *stream, const char *name ATTRIBUTE_UNUSED)
 {
   const char *p, *q;
   char *prefix, *r;
+  char *regframe_name, *deregframe_name;
   int frames = (frame_tables.number > 0);
 
   /* Figure out name of output_file, stripping 

aix: Add FAT library support for libffi for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Even if GCC64 is able to boostrap without libffi being a
FAT library on AIX, the tests for "-maix32" are not working
without it.

libffi/ChangeLog:
2021-10-21  Clément Chigot  

        * Makefile.am (tmake_file): Build and install AIX-style FAT
          libraries.
        * Makefile.in: Regenerate.
        * include/Makefile.in: Regenerate.
        * man/Makefile.in: Regenerate.
        * testsuite/Makefile.in: Regenerate.
        * configure (tmake_file): Substitute.
        * configure.ac: Regenerate.
        * configure.host (powerpc-*-aix*): Define tmake_file.
        * src/powerpc/t-aix: New file.

I've already made a PR to libffi itself in order to add the common part of 
this patch to it. But for now, it's still unmerged: 
https://github.com/libffi/libffi/pull/661. 

Clément

From 9722d209326b84d8817c1ae654190bdc6b546690 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?= 
Date: Thu, 21 Oct 2021 09:07:04 +0200
Subject: [PATCH] aix: Add FAT library support for libffi for AIX
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Even if GCC64 is able to boostrap without libffi being a
FAT library on AIX, the tests for "-maix32" are not working
without it.

libffi/ChangeLog:
2021-10-21  Clément Chigot  

* Makefile.am (tmake_file): Build and install AIX-style FAT
  libraries.
* Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* man/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
* configure (tmake_file): Substitute.
* configure.ac: Regenerate.
* configure.host (powerpc-*-aix*): Define tmake_file.
* src/powerpc/t-aix: New file.
---
 libffi/Makefile.am   |  3 +++
 libffi/Makefile.in   |  4 
 libffi/configure | 17 +++--
 libffi/configure.ac  | 12 
 libffi/configure.host|  2 ++
 libffi/include/Makefile.in   |  1 +
 libffi/man/Makefile.in   |  1 +
 libffi/src/powerpc/t-aix | 14 ++
 libffi/testsuite/Makefile.in |  1 +
 9 files changed, 53 insertions(+), 2 deletions(-)
 create mode 100644 libffi/src/powerpc/t-aix

diff --git a/libffi/Makefile.am b/libffi/Makefile.am
index 02e36176c67..c671444c57c 100644
--- a/libffi/Makefile.am
+++ b/libffi/Makefile.am
@@ -228,4 +228,7 @@ clean-recursive: clean-multi
 distclean-recursive: distclean-multi
 maintainer-clean-recursive: maintainer-clean-multi
 
+# target overrides
+-include $(tmake_file)
+
 include $(top_srcdir)/../multilib.am
diff --git a/libffi/Makefile.in b/libffi/Makefile.in
index 6ff0c67a779..86eb1104f94 100644
--- a/libffi/Makefile.in
+++ b/libffi/Makefile.in
@@ -439,6 +439,7 @@ target_alias = @target_alias@
 target_cpu = @target_cpu@
 target_os = @target_os@
 target_vendor = @target_vendor@
+tmake_file = @tmake_file@
 toolexecdir = @toolexecdir@
 toolexeclibdir = @toolexeclibdir@
 top_build_prefix = @top_build_prefix@
@@ -1931,6 +1932,9 @@ clean-recursive: clean-multi
 distclean-recursive: distclean-multi
 maintainer-clean-recursive: maintainer-clean-multi
 
+# target overrides
+-include $(tmake_file)
+
 # GNU Make needs to see an explicit $(MAKE) variable in the command it
 # runs to enable its job server during parallel builds.  Hence the
 # comments below.
diff --git a/libffi/configure b/libffi/configure
index 4bababb87f5..9550a0906eb 100755
--- a/libffi/configure
+++ b/libffi/configure
@@ -644,6 +644,7 @@ LIBFFI_BUILD_VERSIONED_SHLIB_FALSE
 LIBFFI_BUILD_VERSIONED_SHLIB_TRUE
 OPT_LDFLAGS
 SECTION_LDFLAGS
+tmake_file
 toolexeclibdir
 toolexecdir
 FFI_DEBUG_FALSE
@@ -11481,7 +11482,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11484 "configure"
+#line 11485 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11587,7 +11588,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11590 "configure"
+#line 11591 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -16384,6 +16385,18 @@ esac
 
 
 
+# Conditionalize the makefile for this target machine.
+tmake_file_=
+for f in ${tmake_file}
+do
+  if test -f ${srcdir}/src/$TARGETDIR/$f
+  then
+tmake_file_="${tmake_file_} \$(srcdir)/src/$TARGETDIR/$f"
+  fi
+done
+tmake_file="${tmake_file_}"
+
+
 if test "${multilib}" = "yes"; then
   multilib_arg="--enable-multilib"
 else
diff --git a/libffi/configure.ac b/libffi/configure.ac
index bff5a1e7189..71777ea9b11 100644
--- a/libffi/configure.ac
+++ b/libffi/configure.ac
@@ -403,6 +403,18 @@ esac
 AC_SUBST(toolexecdir)
 AC_SUBST(toolexeclibdir)
 
+# Conditionalize the makefile for this target machine.
+tmake_file_=
+for f in ${tmake_file}
+do
+  if test -f ${srcdir}/src/$TARGETDIR/$f
+  then
+tmake_file_="${tmake_file_} \$(srcdir)/src/$TARGETDIR/$f"
+  fi
+done
+tmake_file="${tmake_file_}"
+AC_SUBST(tmake_file)
+
 if test 

Re: [PATCH] aix: handle 64bit inodes for include directories

[CHIGOT, CLEMENT via Gcc-patches]

Hi everyone,

Gentle ping on this patch.

Clément

From: CHIGOT, CLEMENT 
Sent: Tuesday, October 12, 2021 10:35 AM
To: Jeff Law ; David Malcolm 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 

Subject: Re: [PATCH] aix: handle 64bit inodes for include directories

Hi Jeff,

Any update on this patch ?
As it's dealing with configure files, I would like to have it merged
asap before any conflicts appear.

Thanks,
Clément

Re: [PATCH] gcc: implement AIX-style constructors

[CHIGOT, CLEMENT via Gcc-patches]

Hi David,

The problem is that cdtors is created by the linker only when -bcdtors
flag is provided. Thus, if we add "extern void (* _cdtors[]) (void);" to
the "crtcxa.c", we can't used it without using the new constructor types.
One solution would be to create another crtcxa (eg crtcxa_cdtors.o) which will
be replacing the default crtcxa.o when needed. I didn't thought about that
when creating the patch. But it might be a better approach. What do you think ?

About documentation, I wasn't aware of that. I'll do it.

Clément

From: David Edelsohn 
Sent: Tuesday, October 19, 2021 10:14 PM
To: CHIGOT, CLEMENT 
Cc: gcc-patches@gcc.gnu.org 
Subject: Re: [PATCH] gcc: implement AIX-style constructors

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

Clement,

+  /* Use __C_runtime_pstartup to run ctors and register dtors.
+ This whole part should normally be in libgcc but as
+ AIX cdtors format is currently not the default, managed
+ that in collect2.  */

Why are you emitting the special startup function call in collect2.c
instead of placing it in libgcc.  The comment mentions that the
special startup function should be defined in libgcc.

Yes, the AIX ld bcdtors mechanism is not the default, but what is the
harm? The symbol will be defined and exported by libgcc. If the AIX
linker -bcdtors functionality is not invoked, the symbol is not used.
And if a user does invoke the AIX linker with -bcdtors, the behavior
will be the same (either the program was compiled to use AIX cdtors or
not, which is the same if the startup function is emitted by
collect2.c.

Also, the patch should include documentation of the option.  The
documentation should mention that this is for interoperability with
IBM XL Compiler, and the option will not operate correctly unless the
application and the GCC runtime are built with the option.

Thanks, David

On Mon, Oct 18, 2021 at 3:55 AM CHIGOT, CLEMENT  wrote:
>
> AIX linker now supports constructors and destructors detection. For such
> functions to be detected, their name must starts with __sinit or __sterm.
> and -bcdtors must be passed to linker calls. It will create "_cdtors"
> symbol which can be used to launch the initialization.
>
> This patch creates a new RS6000 flag "-mcdtors=".
> With "-mcdtors=aix", gcc will generate these new constructors/destructors.
> With "-mcdtors=gcc", which is currently the default, gcc will continue
> to generate "gcc" format for constructors (ie _GLOBAL__I and _GLOBAL__D
> symbols).
> Ideally, it would have been better to enable the AIX format by default
> instead of using collect2. However, the compatibility between the
> previously-built binaries and the new ones is too complex to be done.
>
> gcc/ChangeLog:
> 2021-10-04  Clément Chigot  
>
> * collect2.c (aixbcdtors_flags): New variable.
> (main): Use it to detect -bcdtors and remove -binitfini flag.
> (write_c_file_stat): Adapt to new AIX format.
> * config/rs6000/aix.h (FILE_SINIT_FORMAT): New define.
> (FILE_STERM_FORMAT): New define.
> (TARGET_FILE_FUNCTION_FORMAT): New define.
> * config/rs6000/aix64.opt: Add -mcdtors flag.
> * config/rs6000/aix71.h (LINK_SPEC_COMMON): Pass -bcdtors when
>   -mcdtors=aix is passed.
> * config/rs6000/aix72.h (LINK_SPEC_COMMON): Likewise.
> * config/rs6000/aix73.h (LINK_SPEC_COMMON): Likewise.
> * config/rs6000/rs6000-opts.h (enum rs6000_cdtors): New enum.
> * tree.c (get_file_function_name): Add
>   TARGET_FILE_FUNCTION_FORMAT support.
>
> gcc/testsuite/ChangeLog:
> 2021-10-04  Clément Chigot  
>
> * gcc.target/powerpc/constructor-aix.c: New test.
>
>

[PATCH] aix: ensure reference to __tls_get_addr is in text section.

[CHIGOT, CLEMENT via Gcc-patches]

The garbage collector of AIX linker might remove the reference to
__tls_get_addr if it's added inside an unused csect, which can be
the case of .data with very simple programs.

gcc/ChangeLog:
2021-10-19  Clément Chigot  

        * config/rs6000/rs6000.c (rs6000_xcoff_file_end): Move
        __tls_get_addr reference to .text csect.

Approved offline by David Edelson.

From 52e9e4554d8dba9f9c9c56267789fc1d08b1de98 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?= 
Date: Thu, 14 Oct 2021 09:03:13 +0200
Subject: [PATCH] aix: ensure reference to __tls_get_addr is in text section.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The garbage collector of AIX linker might remove the reference to
__tls_get_addr if it's added inside an unused csect, which can be
the case of .data with very simple programs.

gcc/ChangeLog:
2021-10-19  Clément Chigot  

	* config/rs6000/rs6000.c (rs6000_xcoff_file_end): Move
	__tls_get_addr reference to .text csect.
---
 gcc/config/rs6000/rs6000.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 68111c3fe6a..bac959f4ef4 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -21626,17 +21626,17 @@ static void
 rs6000_xcoff_file_end (void)
 {
   switch_to_section (text_section);
+  if (xcoff_tls_exec_model_detected)
+{
+  /* Add a .ref to __tls_get_addr to force libpthread dependency.  */
+  fputs ("\t.extern __tls_get_addr\n\t.ref __tls_get_addr\n", asm_out_file);
+}
   fputs ("_section_.text:\n", asm_out_file);
   switch_to_section (data_section);
   fputs (TARGET_32BIT
 	 ? "\t.long _section_.text\n" : "\t.llong _section_.text\n",
 	 asm_out_file);
 
-  if (xcoff_tls_exec_model_detected)
-{
-  /* Add a .ref to __tls_get_addr to force libpthread dependency.  */
-  fputs ("\t.extern __tls_get_addr\n\t.ref __tls_get_addr\n", asm_out_file);
-}
 }
 
 struct declare_alias_data
-- 
2.25.1

[PATCH] MAINTAINERS: Add myself for write after approval

[CHIGOT, CLEMENT via Gcc-patches]

ChangeLog:
2021-10-19  Clément Chigot  

* MAINTAINERS: Add myself for write after approval.
From 13ddc381ea7bde6df9e48fb968d9324564f7a540 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?= 
Date: Tue, 19 Oct 2021 13:20:14 +0200
Subject: [PATCH] MAINTAINERS: Add myself for write after approval
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

ChangeLog:
2021-10-19  Clément Chigot  

	* MAINTAINERS: Add myself for write after approval.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index bf4006c779f..b22f930583a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -352,6 +352,7 @@ Gabriel Charette
 Chandra Chavva	
 Dehao Chen	
 Fabien Chêne	
+Clément Chigot	
 Harshit Chopra	
 Tamar Christina	
 Eric Christopher
-- 
2.25.1

[PATCH] gcc: implement AIX-style constructors

[CHIGOT, CLEMENT via Gcc-patches]

AIX linker now supports constructors and destructors detection. For such
functions to be detected, their name must starts with __sinit or __sterm.
and -bcdtors must be passed to linker calls. It will create "_cdtors"
symbol which can be used to launch the initialization.

This patch creates a new RS6000 flag "-mcdtors=".
With "-mcdtors=aix", gcc will generate these new constructors/destructors.
With "-mcdtors=gcc", which is currently the default, gcc will continue
to generate "gcc" format for constructors (ie _GLOBAL__I and _GLOBAL__D
symbols).
Ideally, it would have been better to enable the AIX format by default
instead of using collect2. However, the compatibility between the
previously-built binaries and the new ones is too complex to be done.

gcc/ChangeLog:
2021-10-04  Clément Chigot  

        * collect2.c (aixbcdtors_flags): New variable.
        (main): Use it to detect -bcdtors and remove -binitfini flag.
        (write_c_file_stat): Adapt to new AIX format.
        * config/rs6000/aix.h (FILE_SINIT_FORMAT): New define.
        (FILE_STERM_FORMAT): New define.
        (TARGET_FILE_FUNCTION_FORMAT): New define.
        * config/rs6000/aix64.opt: Add -mcdtors flag.
        * config/rs6000/aix71.h (LINK_SPEC_COMMON): Pass -bcdtors when
          -mcdtors=aix is passed.
        * config/rs6000/aix72.h (LINK_SPEC_COMMON): Likewise.
        * config/rs6000/aix73.h (LINK_SPEC_COMMON): Likewise.
        * config/rs6000/rs6000-opts.h (enum rs6000_cdtors): New enum.
        * tree.c (get_file_function_name): Add
          TARGET_FILE_FUNCTION_FORMAT support.

gcc/testsuite/ChangeLog:
2021-10-04  Clément Chigot  

        * gcc.target/powerpc/constructor-aix.c: New test.


From e1297880a2abe53db6422bcf25dcd883a2658260 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?= 
Date: Mon, 4 Oct 2021 09:24:43 +0200
Subject: [PATCH] gcc: implement AIX-style constructors
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

AIX linker now supports constructors and destructors detection. For such
functions to be detected, their name must starts with __sinit or __sterm.
and -bcdtors must be passed to linker calls. It will create "_cdtors"
symbol which can be used to launch the initialization.

This patch creates a new RS6000 flag "-mcdtors=".
With "-mcdtors=aix", gcc will generate these new constructors/destructors.
With "-mcdtors=gcc", which is currently the default, gcc will continue
to generate "gcc" format for constructors (ie _GLOBAL__I and _GLOBAL__D
symbols).
Ideally, it would have been better to enable the AIX format by default
instead of using collect2. However, the compatibility between the
previously-built binaries and the new ones is too complex to be done.

gcc/ChangeLog:
2021-10-04  Clément Chigot  

	* collect2.c (aixbcdtors_flags): New variable.
	(main): Use it to detect -bcdtors and remove -binitfini flag.
	(write_c_file_stat): Adapt to new AIX format.
	* config/rs6000/aix.h (FILE_SINIT_FORMAT): New define.
	(FILE_STERM_FORMAT): New define.
	(TARGET_FILE_FUNCTION_FORMAT): New define.
	* config/rs6000/aix64.opt: Add -mcdtors flag.
	* config/rs6000/aix71.h (LINK_SPEC_COMMON): Pass -bcdtors when
	  -mcdtors=aix is passed.
	* config/rs6000/aix72.h (LINK_SPEC_COMMON): Likewise.
	* config/rs6000/aix73.h (LINK_SPEC_COMMON): Likewise.
	* config/rs6000/rs6000-opts.h (enum rs6000_cdtors): New enum.
	* tree.c (get_file_function_name): Add
	  TARGET_FILE_FUNCTION_FORMAT support.

gcc/testsuite/ChangeLog:
2021-10-04  Clément Chigot  

	* gcc.target/powerpc/constructor-aix.c: New test.
---
 gcc/collect2.c| 91 +--
 gcc/config/rs6000/aix.h   | 56 
 gcc/config/rs6000/aix64.opt   | 17 
 gcc/config/rs6000/aix71.h |  2 +-
 gcc/config/rs6000/aix72.h |  2 +-
 gcc/config/rs6000/aix73.h |  2 +-
 gcc/config/rs6000/rs6000-opts.h   |  8 ++
 .../gcc.target/powerpc/constructor-aix.c  | 12 +++
 gcc/tree.c|  5 +
 9 files changed, 184 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/constructor-aix.c

diff --git a/gcc/collect2.c b/gcc/collect2.c
index 6f913041f26..59658cbadb7 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -186,6 +186,7 @@ static int aix64_flag;			/* true if -b64 */
 static int aixrtl_flag;			/* true if -brtl */
 static int aixlazy_flag;		/* true if -blazy */
 static int visibility_flag;		/* true if -fvisibility */
+static int aixbcdtors_flag;/* True if -bcdtors */
 #endif
 
 enum lto_mode_d {
@@ -984,6 +985,8 @@ main (int argc, char **argv)
 	  aixrtl_flag = 0;
 	else if (strcmp (argv[i], "-blazy") == 0)
 	  aixlazy_flag = 1;
+	else if (strcmp (argv[i], "-bcdtors") == 0)
+	  aixbcdtors_flag = 1;
 #endif
   }
 
@@ -1731,7 +1734,9 @@ main (int argc, char **argv)
   /* Tell the linker that we have 

Re: [PATCH] aix: ensure reference to __tls_get_addr is in text section.

[CHIGOT, CLEMENT via Gcc-patches]

Hi David,

The fact that csect .data is referencing csect .text doesn't mean that
if .text is kept, .data is kept too. It means the opposite. if .data is kept
then .text must be kept.

That's actually what is being done by the linker with the TLS support test
in configure.
$ cat test.c
__thread int a; int b; int main() { return a = b; }

With ".ref __tls_get_addr" in .data:
$ gcc -maix64 test.c -S -o test.s
$ cat test.s
...
_section_.text:
.csect .data[RW],4
.llong _section_.text
.extern __tls_get_addr
.ref __tls_get_addr
$ gcc -maix64 test.s -o test
$ dump -X64 -tv test
...
[142]   m   0x0097 debug 0FILEC:PPC64 test.c
[143]   m   0x16c0 .text 1  unamex.text
[144]   a4  0x005c   00 SD   PR--
[147]   m   0x20001298  .bss 1  externb
[148]   a4  0x0004   00 CM   BS--
[149]   m   0x8800 .tbss 1  externa
[150]   a4  0x0004   00 CM   UL--
...

Csect .data is garbage-collected by the linker. Thus the .ref doesn't matter.

With ".ref __tls_get_addr" in .text:
$ cat test.s
_section_.text:
.csect .data[RW],4
.llong _section_.text
.csect .text[PR],5
.extern __tls_get_addr
.ref __tls_get_addr
$ gcc  -maix64 test.s -o test
ld: 0711-317 ERROR: Undefined symbol: __tls_get_addr
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status

As csect .text is kept (because of main function), the .ref is still there and 
the error
is raise correctly. As "-pthread" isn't passed, __tls_get_addr is not available.

However, writing this mail, I'm wondering if we don't want to always keep both
csects. If .data is kept, then .text is and if .text is kept, then .data is.
Or always keeping .data would have too much side effects ?

Thanks,
Clément


From: David Edelsohn 
Sent: Thursday, October 14, 2021 3:42 PM
To: CHIGOT, CLEMENT 
Cc: gcc-patches@gcc.gnu.org 
Subject: Re: [PATCH] aix: ensure reference to __tls_get_addr is in text section.

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

The reference to __tls_get_addr is in the data section.  And the code
just above creates a symbol in the text section referenced from the
data section to ensure the text section is retained.  So this change
doesn't make sense.  You're essentially saying that the data section
is not used, which makes the other code useless to ensure that the
text section is referenced.

Thanks, David

On Thu, Oct 14, 2021 at 3:06 AM CHIGOT, CLEMENT  wrote:
>
> The garbage collector of AIX linker might remove the reference to
> __tls_get_addr if it's added inside an unused csect.
>
>
> Clément Chigot
> ATOS Bull SAS
> 1 rue de Provence - 38432 Échirolles - France
>

[PATCH] aix: ensure reference to __tls_get_addr is in text section.

[CHIGOT, CLEMENT via Gcc-patches]

The garbage collector of AIX linker might remove the reference to
__tls_get_addr if it's added inside an unused csect.


Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France



0001-aix-ensure-reference-to-__tls_get_addr-is-in-text-se.patch
Description: 0001-aix-ensure-reference-to-__tls_get_addr-is-in-text-se.patch

Re: [PATCH] aix: handle 64bit inodes for include directories

[CHIGOT, CLEMENT via Gcc-patches]

Hi Jeff,

Any update on this patch ?
As it's dealing with configure files, I would like to have it merged
asap before any conflicts appear.

Thanks,
Clément

Re: [PATCH] aix: Add FAT library support for libffi

[CHIGOT, CLEMENT via Gcc-patches]

Hi David,

The problem is that it has no meaning in libffi itself...
This patch is specific to gcc because the multilib part is specific
to gcc.
I'll ask the community but the patch cannot be merged inside
libffi.

Thanks,
Clément

From: David Edelsohn 
Sent: Wednesday, September 15, 2021 2:52 PM
To: CHIGOT, CLEMENT 
Cc: gcc-patches@gcc.gnu.org 
Subject: Re: [PATCH] aix: Add FAT library support for libffi

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

Clement,

GCC is not the primary repository for libffi.  This patch must be
submitted to the libffi project first, not GCC.  If it is accepted in
libffi, then you can ask for a backport to GCC.

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibffi%2Flibffidata=04%7C01%7Cclement.chigot%40atos.net%7C58a9dee835dd4d5ca10308d97847ec9c%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637673072579890230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6%2B%2Bxl4K30%2B%2FvitHcOZwwyq1B6CwAEtHmr3LXgUIp9uQ%3Dreserved=0

Thanks, David

On Wed, Sep 15, 2021 at 7:20 AM CHIGOT, CLEMENT  wrote:
>
> Even if GCC64 is able to bootstrap without libffi being a
> FAT library on AIX, the tests for "-maix32" are not working
> without it.
>
> libffi/ChangeLog:
> 2021-09-10  Clément Chigot  
>
> * Makefile.am (tmake_file): Build and install AIX-style FAT
>   libraries.
> * Makefile.in: Regenerate.
> * include/Makefile.in: Regenerate.
> * man/Makefile.in: Regenerate.
> * testsuite/Makefile.in: Regenerate.
> * configure (tmake_file): Substitute.
> * configure.ac: Regenerate.
> * configure.host (powerpc-*-aix*): Define tmake_file.
> * src/powerpc/t-aix: New file.
>
>
>
>
> Clément Chigot
> ATOS Bull SAS
> 1 rue de Provence - 38432 Échirolles - France
>

[PATCH] aix: Add FAT library support for libffi

[CHIGOT, CLEMENT via Gcc-patches]

Even if GCC64 is able to bootstrap without libffi being a
FAT library on AIX, the tests for "-maix32" are not working
without it.

libffi/ChangeLog:
2021-09-10  Clément Chigot  

* Makefile.am (tmake_file): Build and install AIX-style FAT
  libraries.
* Makefile.in: Regenerate.
* include/Makefile.in: Regenerate.
* man/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
* configure (tmake_file): Substitute.
* configure.ac: Regenerate.
    * configure.host (powerpc-*-aix*): Define tmake_file.
* src/powerpc/t-aix: New file.




Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France



0001-aix-Add-FAT-library-support-for-libffi.patch
Description: 0001-aix-Add-FAT-library-support-for-libffi.patch

aix: adjust installation directories for GCC64

[CHIGOT, CLEMENT via Gcc-patches]

As gcc on 64bit for AIX is built with "MULTILIB_MATCHES= .=maix32",
"-print-multi-directory" and similar flags aren't returning the
correct directory when used with -maix32: "." is returned instead
of "ppc32".
Libgcc installation script needs to be adjust to bypass this
problem and correctly install 32bit files in a ppc32 subdirectory.

libgcc/ChangeLog:
2021-09-03  Clément Chigot  

* config/rs6000/t-slibgcc-aix (SHLIB_INSTALL): Replace
"$(slibdir)@shlib_slibdir_qual@" by $(inst_libdir).


Please submit if accepted. 
Thanks, 

Clément

0001-aix-adjust-installation-directories-for-GCC64.patch
Description: 0001-aix-adjust-installation-directories-for-GCC64.patch


0001-aix-adjust-installation-directories-for-GCC64.patch
Description: 0001-aix-adjust-installation-directories-for-GCC64.patch

Re: [PATCH] aix: handle 64bit inodes for include directories

[CHIGOT, CLEMENT via Gcc-patches]

>>> So my worry here is this is really a host property -- ie, this is
>>> behavior of where GCC runs, not the target for which GCC is generating code.
>>>
>>> That implies that the change in aix.h is wrong.  aix.h is for the
>>> target, not the host -- you don't want to define something like
>>> HOST_STAT_FOR_64BIT_INODES there.
>>>
>>> You'd want to be triggering this behavior via a host fragment, x-aix, or
>>> better yet via an autoconf test.
>> Indeed, would this version be better ? I'm not sure about the configure test.
>> But as we are retrieving the size of dev_t and ino_t just above, I'm assuming
>> that the one being used in stat directly. At least, that's the case on AIX, 
>> and
>> this test is only made for AIX.
> It's a clear improvement.  It's still checking for the aix target though:
>
> +# Select the right stat being able to handle 64bit inodes, if needed.
> +if test "$enable_largefile" != no; then
> +  case "$target" in
> +*-*-aix*)
> +  if test "$ac_cv_sizeof_ino_t" == "4" -a "$ac_cv_sizeof_dev_t" ==
> 4; then
> +
> +$as_echo "#define HOST_STAT_FOR_64BIT_INODES stat64x" >>confdefs.h
> +
> +  fi;;
> +  esac
> +fi
>
> Again, we're dealing with a host property.  You might be able to just
> change $target above to $host.  Hmm, that makes me wonder about canadian
> crosses where host != build.We may need to do this for both the aix
> host and aix build.

Yes, my bad, I've updated the case. I don't know if there is a usual way
to check both $build and $host. I've tried to avoid code duplication so
tell me if it's okay or if you'd rather have a case for $build and one
for $host.

Thanks,
Clément


0001-aix-handle-64bit-inodes-for-include-directories.patch
Description: 0001-aix-handle-64bit-inodes-for-include-directories.patch

Re: [PATCH] aix: handle 64bit inodes for include directories

[CHIGOT, CLEMENT via Gcc-patches]

Hi guys,

Did you have a chance to take a look at the new version of this patch ?

Thanks,
Clément

From: CHIGOT, CLEMENT 
Sent: Monday, June 28, 2021 9:16 AM
To: Jeff Law ; David Malcolm 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 

Subject: Re: [PATCH] aix: handle 64bit inodes for include directories

>On 6/23/2021 12:53 AM, CHIGOT, CLEMENT via Gcc-patches wrote:
>> Hi David,
>>
>> Did you have a chance to take look at this patch ?
>>
>> Thanks,
>> Clément
>>
>>
>>> +DavidMalcolm
>>>
>>> Can you review this patch when you have a moment?
>>>
>>> Thanks, David
>>>
>>> On Mon, May 17, 2021 at 3:05 PM David Edelsohn  wrote:
>>>> The aix.h change is okay with me, but you need to get approval for the
>>>> incpath.c and cpplib.h parts of the patch from the appropriate
>>>> maintainers.
>>>>
>>>> Thanks, David
>>>>
>>>> On Mon, May 17, 2021 at 7:44 AM CHIGOT, CLEMENT  
>>>> wrote:
>>>>> On AIX, stat will store inodes in 32bit even when using LARGE_FILES.
>>>>> If the inode is larger, it will return -1 in st_ino.
>>>>> Thus, in incpath.c when comparing include directories, if several
>>>>> of them have 64bit inodes, they will be considered as duplicated.
>>>>>
>>>>> gcc/ChangeLog:
>>>>> 2021-05-06  Clément Chigot  
>>>>>
>>>>>  * configure.ac: Check sizeof ino_t and dev_t.
>>>>>  * config.in: Regenerate.
>>>>>  * configure: Regenerate.
>>>>>  * config/rs6000/aix.h (HOST_STAT_FOR_64BIT_INODES): New define.
>>>>>  * incpath.c (HOST_STAT_FOR_64BIT_INODES): New define.
>>>>>  (remove_duplicates): Use it.
>>>>>
>>>>> libcpp/ChangeLog:
>>>>> 2021-05-06  Clément Chigot  
>>>>>
>>>>>  * configure.ac: Check sizeof ino_t and dev_t.
>>>>>  * config.in: Regenerate.
>>>>>  * configure: Regenerate.
>>>>>  * include/cpplib.h (INO_T_CPP): Change for AIX.
>>>>>  (DEV_T_CPP): New macro.
>>>>>  (struct cpp_dir): Use it.
> So my worry here is this is really a host property -- ie, this is
> behavior of where GCC runs, not the target for which GCC is generating code.
>
> That implies that the change in aix.h is wrong.  aix.h is for the
> target, not the host -- you don't want to define something like
> HOST_STAT_FOR_64BIT_INODES there.
>
> You'd want to be triggering this behavior via a host fragment, x-aix, or
> better yet via an autoconf test.

Indeed, would this version be better ? I'm not sure about the configure test.
But as we are retrieving the size of dev_t and ino_t just above, I'm assuming
that the one being used in stat directly. At least, that's the case on AIX, and
this test is only made for AIX.

Clément

Re: [PATCH] aix: handle 64bit inodes for include directories

[CHIGOT, CLEMENT via Gcc-patches]

>On 6/23/2021 12:53 AM, CHIGOT, CLEMENT via Gcc-patches wrote:
>> Hi David,
>>
>> Did you have a chance to take look at this patch ?
>>
>> Thanks,
>> Clément
>>
>>
>>> +DavidMalcolm
>>>
>>> Can you review this patch when you have a moment?
>>>
>>> Thanks, David
>>>
>>> On Mon, May 17, 2021 at 3:05 PM David Edelsohn  wrote:
>>>> The aix.h change is okay with me, but you need to get approval for the
>>>> incpath.c and cpplib.h parts of the patch from the appropriate
>>>> maintainers.
>>>>
>>>> Thanks, David
>>>>
>>>> On Mon, May 17, 2021 at 7:44 AM CHIGOT, CLEMENT  
>>>> wrote:
>>>>> On AIX, stat will store inodes in 32bit even when using LARGE_FILES.
>>>>> If the inode is larger, it will return -1 in st_ino.
>>>>> Thus, in incpath.c when comparing include directories, if several
>>>>> of them have 64bit inodes, they will be considered as duplicated.
>>>>>
>>>>> gcc/ChangeLog:
>>>>> 2021-05-06  Clément Chigot  
>>>>>
>>>>>  * configure.ac: Check sizeof ino_t and dev_t.
>>>>>  * config.in: Regenerate.
>>>>>  * configure: Regenerate.
>>>>>  * config/rs6000/aix.h (HOST_STAT_FOR_64BIT_INODES): New define.
>>>>>  * incpath.c (HOST_STAT_FOR_64BIT_INODES): New define.
>>>>>  (remove_duplicates): Use it.
>>>>>
>>>>> libcpp/ChangeLog:
>>>>> 2021-05-06  Clément Chigot  
>>>>>
>>>>>  * configure.ac: Check sizeof ino_t and dev_t.
>>>>>  * config.in: Regenerate.
>>>>>  * configure: Regenerate.
>>>>>  * include/cpplib.h (INO_T_CPP): Change for AIX.
>>>>>  (DEV_T_CPP): New macro.
>>>>>  (struct cpp_dir): Use it.
> So my worry here is this is really a host property -- ie, this is 
> behavior of where GCC runs, not the target for which GCC is generating code.
> 
> That implies that the change in aix.h is wrong.  aix.h is for the 
> target, not the host -- you don't want to define something like 
> HOST_STAT_FOR_64BIT_INODES there.
>
> You'd want to be triggering this behavior via a host fragment, x-aix, or 
> better yet via an autoconf test.

Indeed, would this version be better ? I'm not sure about the configure test. 
But as we are retrieving the size of dev_t and ino_t just above, I'm assuming 
that the one being used in stat directly. At least, that's the case on AIX, and 
this test is only made for AIX. 

Clément

0001-aix-handle-64bit-inodes-for-include-directories.patch
Description: 0001-aix-handle-64bit-inodes-for-include-directories.patch

Re: [PATCH] aix: handle 64bit inodes for include directories

[CHIGOT, CLEMENT via Gcc-patches]

Hi David,

Did you have a chance to take look at this patch ?

Thanks,
Clément


>
> +DavidMalcolm
>
> Can you review this patch when you have a moment?
>
> Thanks, David
>
> On Mon, May 17, 2021 at 3:05 PM David Edelsohn  wrote:
>>
>> The aix.h change is okay with me, but you need to get approval for the
>> incpath.c and cpplib.h parts of the patch from the appropriate
>> maintainers.
>>
>> Thanks, David
>>
>> On Mon, May 17, 2021 at 7:44 AM CHIGOT, CLEMENT  
>> wrote:
>> >
>> > On AIX, stat will store inodes in 32bit even when using LARGE_FILES.
>> > If the inode is larger, it will return -1 in st_ino.
>> > Thus, in incpath.c when comparing include directories, if several
>> > of them have 64bit inodes, they will be considered as duplicated.
>> >
>> > gcc/ChangeLog:
>> > 2021-05-06  Clément Chigot  
>> >
>> > * configure.ac: Check sizeof ino_t and dev_t.
>> > * config.in: Regenerate.
>> > * configure: Regenerate.
>> > * config/rs6000/aix.h (HOST_STAT_FOR_64BIT_INODES): New define.
>> > * incpath.c (HOST_STAT_FOR_64BIT_INODES): New define.
>> > (remove_duplicates): Use it.
>> >
>> > libcpp/ChangeLog:
>> > 2021-05-06  Clément Chigot  
>> >
>> > * configure.ac: Check sizeof ino_t and dev_t.
>> > * config.in: Regenerate.
>> > * configure: Regenerate.
>> > * include/cpplib.h (INO_T_CPP): Change for AIX.
>> > (DEV_T_CPP): New macro.
>> > (struct cpp_dir): Use it.
>> >
>> >
>> >

[PATCH] aix: add Power10 flag in ASM_CPU_SPEC

[CHIGOT, CLEMENT via Gcc-patches]

Changelog:
2021-06-09  Clément Chigot  

* config/rs6000/aix71.h (ASM_CPU_SPEC): Add entry for Power10.
* config/rs6000/aix72.h (ASM_CPU_SPEC): Likewise.





0001-aix-add-Power10-flag-in-ASM_CPU_SPEC.patch
Description: 0001-aix-add-Power10-flag-in-ASM_CPU_SPEC.patch

[PATCH] collect2: avoid failure when passing text files in an AIX archive

[CHIGOT, CLEMENT via Gcc-patches]

AIX ld allows archives to contain text files by simply ignoring
them and printing a warning.
This patch enables the same behavior for collect2.

gcc/ChangeLog:
2021-05-20  Clément Chigot  

* collect2.c (scan_prog_file): Skip none-COFF files instead
of raising an error.


Maybe the warning message can be changed as it can say that 
an archive is not a COFF file instead of the file inside the archive. 
But I don't know how to handle location files under "po/" afterwards, 
and it was already the case before. 

Please apply if accepted. 

Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France



0001-collect2-avoid-failure-when-passing-text-files-in-an.patch
Description: 0001-collect2-avoid-failure-when-passing-text-files-in-an.patch

[PATCH] aix: handle 64bit inodes for include directories

[CHIGOT, CLEMENT via Gcc-patches]

On AIX, stat will store inodes in 32bit even when using LARGE_FILES.
If the inode is larger, it will return -1 in st_ino.
Thus, in incpath.c when comparing include directories, if several
of them have 64bit inodes, they will be considered as duplicated.

gcc/ChangeLog:
2021-05-06  Clément Chigot  

* configure.ac: Check sizeof ino_t and dev_t.
* config.in: Regenerate.
* configure: Regenerate.
* config/rs6000/aix.h (HOST_STAT_FOR_64BIT_INODES): New define.
* incpath.c (HOST_STAT_FOR_64BIT_INODES): New define.
(remove_duplicates): Use it.

libcpp/ChangeLog:
2021-05-06  Clément Chigot  

* configure.ac: Check sizeof ino_t and dev_t.
* config.in: Regenerate.
* configure: Regenerate.
* include/cpplib.h (INO_T_CPP): Change for AIX.
(DEV_T_CPP): New macro.
(struct cpp_dir): Use it.





0001-aix-handle-64bit-inodes-for-include-directories.patch
Description: 0001-aix-handle-64bit-inodes-for-include-directories.patch

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

>> * While you now define _GLIBCXX_C_LOCALE_XPG7 in
>>  config/locale/xpg7/c_locale.h, config/os/aix/ctype_configure_char.cc
>>   still tests the previous _GLIBCXX_C_LOCALE_IEEE_2008.
>
> Arf, I've missed that. it might not be the last patch then. 
> (I've made so much versions of it as I've tried to backport it to our 
> old versions. It seems that I've mixed up things...) 

Well, after several tries this morning, I can tell that I still don't 
understand at all how to setup this ctype for char... 
I'm sure it have improved things at a moment. But now, whether 
I'm removing or adding it, nothing changes.. 
Anyway, _GLIBCXX_C_LOCALE_XPG7 is needed for gnu or for the new 
testsuite check. So I'm just going to update aix/ctype_configure_char.c 
locally. I'll see later if I can figure what's wrong. 

Clément
going to update it locally. 

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

> * There are minor formatting issues:
> 
>   Should the linebreak in the extern inline definitions of strtof_l be
>   after the return type, not before, matching GNU coding standards?  It
>   may well be that the C++ style is different, though.
> 
>  Unrelated whitespace changes in xpg7/ctype_members.cc

I haven't yet check all the format issues. Especially, because the previous
code was already wrongly formatted at some point. I'll do that when 
releasing a "final" version of the patch.

> * The changes in the copyright ranges need to be undone, given that this
>  is just a renamed/augmented version of the previous dragonfly code.

Ok, I wasn't sure about that. I'll revert. 

> * Seeing the __DragonFly__ || __FreeBSD__ again, I had a quick look at
>   the FreeBSD 12.2 headers and found that localeconv_l does take a
>   locale_t arg, just like uselocale.  DragonFlyBSD seems to be the same
>   according to their online manuals.  I expect to give the code a try in
>   a FreeBSD 12.2 VM at some point to check.

Actually, it seems that the problem isn't about input argument, but 
the output which should "int*".

> * While you now define _GLIBCXX_C_LOCALE_XPG7 in
>  config/locale/xpg7/c_locale.h, config/os/aix/ctype_configure_char.cc
>   still tests the previous _GLIBCXX_C_LOCALE_IEEE_2008.

Arf, I've missed that. it might not be the last patch then. 
(I've made so much versions of it as I've tried to backport it to our 
old versions. It seems that I've mixed up things...) 

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Hi everyone, 

Here is a better version of the patch. 
All tests are on Linux are passing. Few have been disabled as 
they are working only with GNU model. 
For AIX, few failures remains. I haven't XFAIL them yet, as I 
want to know if they AIX only or related to the model itself. 

A few part still need to be improved (dg-require-localmodel,
std::locale:global, FreeBSD specific #ifdef). 
But at least it can be tested in most of the platforms as is. 

Note that I'll stop working on it until gcc12. Mostly because gcc
is on freeze but also because I've more urgent stuff to do right now. 
Of course any feedbacks is welcome ! But I might not send a
new patch if it requires too much time (at least not right now). 

Thanks anyway Rainer and Jonathan for your help ! I hope this 
version suits you better !

Clément



0001-libstdc-implement-locale-support-for-XPG7.patch
Description: 0001-libstdc-implement-locale-support-for-XPG7.patch

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Hi Rainer, Jonathan

>>>why?  I've just double-checked the OpenGroup pages: all of the functions
>>>listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
>>>have Technical Corrigenda applied.  IIUC IEEE 1003.1-2017 is just a
>>>revision of the -2008 standard, not a new issue (XPG8 or something).
>>
>> Technically, the 2008 standard has been withdrawn and replaced by
>> 2017. Since the content is the same, it seems more correct to refer to
>> the current standard (even if Solaris only documents support for the
>> 2008 edition, if it also implements the corrigenda then it conforms to
>> 2017 even if it doesn't document that).
>
>I've found no macro that would distinguish P1003.1-2008 and -2017.  It
>seems both are identified by _XOPEN_SOURCE=700 and
>_POSIX_C_SOURCE=200809L.
>
>> But as I said, a shorter, more memorable name like "xpg7" or just
>> "posix" might be preferable anyway.
>
> I'd strongly prefer xpg7 over posix: after all, xpg6 systems are still
> around (Solaris 11.3 being one of them, and I suspect older AIX versions
> as well).  It's certainly much less of a mouthful than ieee_1003.1-2008 ;-)

I honestly don't master all these conventions. So I'll follow you on the right
name to give.

>> Some are still needed as for example only the last version of AIX have
>> strftime_l.
>
> Then that version doesn't conform to XPG7 and shouldn't use that clocale
> variant.  Until we have a clearer understanding of the variation here,
> I'd argue that only P1003.1-2008 conforming OSes should use
> ieee_1003.1-2008, rather than creating an impenetrable maze of #ifdefs
> for all sorts of partial implementations.

Yes, AIX before 7.2 TL5 is Unix03 compliant, and after UNIXv7.
However, my aim is to implement locale support for these older versions
too. Thus, maybe I can create a fake strftime_l in config/os/aix. But I want
to use this model for AIX. Otherwise, I'll simply revert to the AIX model
as I've made in the first patch, as it's not possible to use this new
model for my purpose.
I mean no offense, but my aim is to improve AIX. Of course,
I'm glad to help other OS too, but I can't work on it if there is no
impact for AIX at the end.

 Besides, your configure tests are way too complicated: just use
 AC_CHECK_FUNCS doing a link test and be done with it.
>>>
>>> Sadly, you can't pass includes to AC_CHECK_FUNCS. That's why I had to do
>>> that. I've made a first version with AC_CHECK_DECLS which allows extra
>>> headers, but it didn't work too. I might know why though.
>>
>>Why would you need to?  AC_CHECK_FUNCS just perform a link test to check
>>if the functions are present in libc; no need to have a declaration
>>present.
>
>Right, I wondered about this too.

I didn't work when I've tried. Maybe I've missed something. I'll check.

Thanks,
Clément

From: Rainer Orth 
Sent: Friday, January 22, 2021 12:54 PM
To: Jonathan Wakely 
Cc: CHIGOT, CLEMENT ; libstdc++ 
; David Edelsohn via Gcc-patches 
; David Edelsohn 
Subject: Re: [PATCH] libstdc++: implement locale support for AIX

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

Hi Jonathan,

> On 22/01/21 12:04 +0100, Rainer Orth wrote:
>>why?  I've just double-checked the OpenGroup pages: all of the functions
>>listed as XPG7 above were part of IEEE 1003.1-2008, just some of them
>>have Technical Corrigenda applied.  IIUC IEEE 1003.1-2017 is just a
>>revision of the -2008 standard, not a new issue (XPG8 or something).
>
> Technically, the 2008 standard has been withdrawn and replaced by
> 2017. Since the content is the same, it seems more correct to refer to
> the current standard (even if Solaris only documents support for the
> 2008 edition, if it also implements the corrigenda then it conforms to
> 2017 even if it doesn't document that).

I've found no macro that would distinguish P1003.1-2008 and -2017.  It
seems both are identified by _XOPEN_SOURCE=700 and
_POSIX_C_SOURCE=200809L.

> But as I said, a shorter, more memorable name like "xpg7" or just
> "posix" might be preferable anyway.

I'd strongly prefer xpg7 over posix: after all, xpg6 systems are still
around (Solaris 11.3 being one of them, and I suspect older AIX versions
as well).  It's certainly much less of a mouthful than ieee_1003.1-2008 ;-)

 As for the BSD group, I suggest to have one representative configure
  test (for localeconv_l perhaps) and then use an appropriate name for the
 group as a whole.  Again, this will most likely be an all-or-nothing
 thing.
>>>
>>> I'm not sure this is really all-or-nothing for these. Maybe strtof_l and cie
>>> can be grouped by. But the 3 others are really different. Linux have
>>> wcsftime_l
>>> but not the others. AIX avec none. BSD have all.
>>
>>TBH, I don't care about Linux here: it will continue to use the gnu
>>variant anyway.  Besides, since the patch will have to work on targets

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Hi Rainer

> > 3) POSIX 2017 and non-POSIX functions
> > Many of the *_l functions being used in GNU or dragonfly models aren't
> > POSIX 2008, but mainly POSIX 2017 or like strtof_l not POSIX at all.
> > However, there are really useful in the code, thus I've made a double
> > implementation based on "#ifdef HAVE_". Is it ok for you ? It's not really
> > POSIX 2008 but more POSIX 2008 with 2017 compatibility.
> > For the configure, I didn't find any better way to check each syscall, as
> > they all depend on different includes. Tell me if you have a better idea.
>
> First a general observation: there are two groups of functions you're
> testing for:
>
> * Pure BSD additions, not available in either POSIX.1, ISO C, or glibc:
>
>  localeconv_l
>  mbstowcs_l
>  strtod_l
>  strtof_l
>  strtold_l
>  wcsftime_l
>
> * Part of XPG7:
>
>   iswctype_l
>   strcoll_l
>   strftime_l
>   strxfrm_l
>   towlower_l
>   towupper_l
>   wcscoll_l
>   wcsxfrm_l
>   wctype_l
>
> My suggestion would be not to have configure tests _GLIBCXX_HAVE_
> for any of the second group at all: this is ieee_1003.1-2008, after all,
> so if some OS selects that clocale variant, it better implement all of
> those.  If really need be, one could a configure check for those and
> error out if any is missing.  This makes the code way more readable than
> trying to handle some hypothetical partial implementation.

In this case, it would be better to call it ieee_1003.1-2017 but I agree
it would be better to avoid all these #ifdef.
Some are still needed as for example only the last version of AIX have
strftime_l.

> As for the BSD group, I suggest to have one representative configure
>  test (for localeconv_l perhaps) and then use an appropriate name for the
> group as a whole.  Again, this will most likely be an all-or-nothing
> thing.

I'm not sure this is really all-or-nothing for these. Maybe strtof_l and cie
can be grouped by. But the 3 others are really different. Linux have wcsftime_l
but not the others. AIX avec none. BSD have all.

> Besides, your configure tests are way too complicated: just use
> AC_CHECK_FUNCS doing a link test and be done with it.

Sadly, you can't pass includes to AC_CHECK_FUNCS. That's why I had to do
that. I've made a first version with AC_CHECK_DECLS which allows extra
headers, but it didn't work too. I might know why though.

> In a similar vein, configure.ac already has
> AC_CHECK_HEADERS([xlocale.h]).  Rather than hardcoding the existance of
> the header based on the configure triple, just use the existing
> HAVE_XLOCALE_H.  This ways, things will simply fall into place for
> e.g. NetBSD, OpenBSD and possibly others.

Right, I'll make the change. Thanks !

> > 4) ctype_configure_char.cc
> > I've some troubles knowing what is supposed to be implemented on this file.
> > I don't really understand the part with setlocale which appears in many
> > os. When I'm adding it, some tests start failing, some start working...
> > Moreover, on Linux, if I understand correctly, there is some optimizations
> > based on classic_table(), _M_toupper and _M_tolower. Could you confirm
> > that it's only useful on Linux ?
>
> I don't know myself.  However, when trying the first version of your
> patch (augmented to compile on Solaris), the corresponding change to the
> solaris file made no difference in test results.

I might have found the correct code since yesterday's mail. The problem seems
to come from _M_c_locale_ctype initialization. With locale support, it must be
_S_clone_c_locale(__cloc), without it, it must be the default locale which ends 
up
being "C". I might push a newer patch this afternoon, with the correct code.

> > Feel free to try in on other OS. But I've made modifications only for AIX 
> > and
> > Linux, as I can test the other ones.
>
> While reading through the patch, I saw that in two places you still use
> __DragonFly__ || __FreeBSD__ tests.  For one, it's hard to tell what
> feature they are really about, besides they will require fiddling with
> e.g. for other BSDs.  Please use a descriptive macro which says which
> difference this is about.

Right, because I don't know how to handle them (and I've forgotten to ask
for it...).
The first is for typedef __c_locale. It seems to be int* instead of locale_t.
Could you confirm that this is wanted and mandatory ?
The second is in about some functions in ctype_members.cc which are
defined in config/os/../ctype_inlines.h for FreeBSD and Dragonfly. Someone
has to confirm that it can be merged with the new code, or if this is mandatory.

> That said, I gave the new patch a try on Solaris 11.4.  To get it to
> compile, I had to apply two changes that I'd mentioned (without an actual
> patch) when commenting on the first patch:
>
> * The C99 fields of struct lconv need _LCONV_C99 to be visible for
>   C++11.
>
>  * Some ctype macros need __bitmapsize = 15, as the generic clocale
>   implementation uses.

If I'm not mistaking, POSIX is only defining 11 bit for ctype. 

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Hi everyone, 

Here is a new version of the patch. I've tested on Linux and AIX.
There are still some tests failing but it starts having a good shape ! 
However, I have few questions:

1) locale.name and syscalls
locale.name() is returning a string having the description of each locale
category. It looks like 
"LC_CTYPE=en_US.UTF-8; LC_NUMERIC=en_US.UTF-8; ...".
However, in locale::global() or sometimes in c_locale.cc functions, this
name is used as arguments of setlocale, newlocale, etc. 
It seems to work with GNU locale model but when I'm trying to do it 
with the POSIX_2008 model, it doesn't work. A simple C program 
seems to refuse it, anyway.
Thus, is there any define on Linux enabling this behavior ? And in 
a more general way, I'm not sure it will work on all POSIX 2008 
system. We might need to modify std:global() and other functions 
ending up using locale.name() as syscalls argument. 

2) Detect locale model during tests
Is there already a function in the testsuite to detect which locale model
is being used ? I didn't find any and as I'm not use to runtest scripts, 
I don't really know how to implement one. 
Ideally, it would be something like "has_locale_modele { gnu }". It would 
allow to skip some tests which are made only for GNU model.
Is there any function I can based myself on ?  

3) POSIX 2017 and non-POSIX functions
Many of the *_l functions being used in GNU or dragonfly models aren't 
POSIX 2008, but mainly POSIX 2017 or like strtof_l not POSIX at all. 
However, there are really useful in the code, thus I've made a double 
implementation based on "#ifdef HAVE_". Is it ok for you ? It's not really
POSIX 2008 but more POSIX 2008 with 2017 compatibility. 
For the configure, I didn't find any better way to check each syscall, as 
they all depend on different includes. Tell me if you have a better idea.

4) ctype_configure_char.cc 
I've some troubles knowing what is supposed to be implemented on this file. 
I don't really understand the part with setlocale which appears in many 
os. When I'm adding it, some tests start failing, some start working... 
Moreover, on Linux, if I understand correctly, there is some optimizations 
based on classic_table(), _M_toupper and _M_tolower. Could you confirm 
that it's only useful on Linux ?

5) Some tests results
Here are the remaining tests failing on Linux x86:
FAIL: 22_locale/locale/cons/29217.cc execution test
FAIL: 22_locale/locale/cons/38368.cc execution test
FAIL: 22_locale/locale/cons/40184.cc execution test
FAIL: 22_locale/locale/cons/5.cc execution test
FAIL: 22_locale/locale/global_locale_objects/14071.cc execution test
 => linked to 1)

FAIL: 22_locale/messages/13631.cc execution test
FAIL: 22_locale/messages/members/char/1.cc execution test
FAIL: 22_locale/messages/members/char/2.cc execution test
FAIL: 22_locale/messages/members/char/wrapped_env.cc execution test
FAIL: 22_locale/messages/members/char/wrapped_locale.cc execution test
FAIL: 22_locale/messages_byname/named_equivalence.cc execution test
  => linked to message_members.cc not being implemented.
Reason behind 2)

FAIL: 22_locale/numpunct/members/char/3.cc execution test
  => No idea yet. Maybe 1) too.

FAIL: 22_locale/time_get/get_time/char/2.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
  => Not related. 

Feel free to try in on other OS. But I've made modifications only for AIX and 
Linux, as I can test the other ones. 

Thanks, 
Clément
From 6b82a9c6b49d16e701f096891550c93661a58bbe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?= 
Date: Tue, 29 Dec 2020 11:08:33 +0100
Subject: [PATCH] libstdc++: implement locale support for POSIX 2008
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The implementation is based on dragonfly one.
It also adds support for AIX with a few tweaks.
As of now, a few locale functions are missing on AIX.
For strftime_l, localeconv_l, mbstowcs_l and wcsftime_l,
uselocale must be set prior to use the version without _l.
For strtof_l, strtod_l, strtold_l, a wrapper simply calls
the default version.

libstdc++-v3/ChangeLog:
2021-01-12  Clément Chigot  

* acinclude.m4: Add ieee_1003.1-2008 locale model.
* configure: Regenerate.
* config/os/aix/ctype_configure_char.cc: Enable locale support.
* testsuite/lib/libstdc++.exp (check_v3_target_namedlocale):
Handle AIX locale names.
* testsuite/util/testsuite_hooks.h: Likewise.
* config/locale/dragonfly/c_locale.cc: Removed.
* config/locale/dragonfly/c_locale.h: Removed.
* config/locale/dragonfly/codecvt_members.cc: Removed.
* 

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

> > However, is the C++ ABI not standard ? I don't have this test failing on
> > AIX, AFAIK. Strange.
>
> Not really: the ABI tests rely on symbol versioning, which is only
> available on Solaris and GNU ELF targets.
Maybe it's normal then.

> OTOH, I wondered if it wouldn't be better to start from the GNU code
> which is certainly known to work, rather than the DragonflyBSD one which
> may well have bitrotten since most of the BSDs moved to LLVM.  Then
> again, it may not: Gerald tests on FreeBSD regularly.  Perhaps a 3-way
merge of gnu and *bsd -> ieee_1003.1-2008 is in order?
Gnu model is really different as it implements catalogues, is using
nl_langinfo_l with GNU specific defines instead of localeconv_l, and few
other stuffs like this.
I'll check if some parts might be interesting. But BSD seems closer to want
we actually want.

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Hi Rainer,

> This alone makes the patch inacceptable in its present form: breaking
> the libstdc++ ABI is a non-starter.  However, I suspect this can be
> avoided somehow.
Thanks for having tried and I agree the patch isn't ready at all. I've just
wanted to see how behave on other systems and it seems that it might
not work as is.
However, is the C++ ABI not standard ? I don't have this test failing on
AIX, AFAIK. Strange.


> +FAIL: 22_locale/classification/isblank.cc execution test
>
> /vol/gcc/src/hg/master/solaris/libstdc++-v3/testsuite/22_locale/classification/isblank.cc:38:
>  void test02(): Assertion 'std::isblank(L' ', std::locale::classic())' failed.
>
> It turns out that this is caused by ieee_1003.1-2008/ctype_members.cc
> using __bitmapsize = 11 in a couple of places, unlike the generic
> version which uses 15 to accomodate variations in  character
> classifications.
11 is the correct value on AIX and maybe also in Dragnofly/FreeBSD,
based on the value of Dragonfly model. However, big endian vs little
endian needs to be handled. I haven't fix that part on the current
patch I guess. (when bitmapsize = 15, there is no difference, endianness
doesn't matter). However, it might be simpler to set bitmapsize = 15
for everyone, instead of having some defines for that. Maybe.

> However, there are many more which I haven't even started to
> investigate.  I suspect there's one (or a few) reasons immediately
> obvious to someone familiar with the code.
Thanks for the list. I'll check if there is some common with AIX. But
wait until I push the new patch to start studying them.
It'll have the correct #ifdef based on configure and I'll try it on Linux.
Thus, it should be far better.


Thanks,
Clément

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

> >Hi everyone, 
> >
> >I've reworked the patch to merged dragonfly and AIX
> >models into the new one named "ieee_1003.1-2008". 
> >It seems okay on the AIX part but if someone can test
> >on Dragonfly and Freebsd I would be glad. Configure
> >needs to be regenerated, first.
> 
> Presumably it could also be tested on GNU/Linux and Solaris, since
> they implement the POSIX 2008 APIs needed.
Indeed, I'll try it tomorrow for Linux. I don't have any Solaris 
VMs on my labs. 
Note that I've forgotten to add some "defined(__FreeBSD__)"
in the current patch, so it should not work on it. I'll send 
a better one tomorrow after having check on Linux.

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

> And I don't know for the Changelog/Patch, how renamed 
> files must be handled ? I've retrieved my git commit with 
> "git format-patch --no-renames" and thus the Changelog 
> is made of "Removed" and "New File". Is it okay or is there 
> anything special to add ? I didn't find the answer quickly. 
Actually, on the one, I've sent I've forgotten the 
"--no-renames" thus it's using git mechanism... 


Thanks, 
Clément

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Hi everyone, 

I've reworked the patch to merged dragonfly and AIX
models into the new one named "ieee_1003.1-2008". 
It seems okay on the AIX part but if someone can test
on Dragonfly and Freebsd I would be glad. Configure 
needs to be regenerated, first.

For now, I've used #ifdef inside the code for the few
differences. There are less than I thought. So, it seems 
okay to me. 
However, I haven't changed all the (locale_t) casts 
made on Dragonfly when passing a locale object to
a syscall. On AIX, this is transparent, __c_locale being 
locale_t. 

I haven't updated tests failing on AIX yet. 
And I don't know for the Changelog/Patch, how renamed 
files must be handled ? I've retrieved my git commit with 
"git format-patch --no-renames" and thus the Changelog 
is made of "Removed" and "New File". Is it okay or is there 
anything special to add ? I didn't find the answer quickly. 

Thanks, 
ClémentFrom d36a04c7d4eb390817d711dc59ad0e0759bccdce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?= 
Date: Tue, 29 Dec 2020 11:08:33 +0100
Subject: [PATCH] libstdc++: implement locale support for POSIX 2008
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The implementation is based on dragonfly one.
It also adds support for AIX with a few tweaks.
As of now, a few locale functions are missing on AIX.
For strftime_l, localeconv_l, mbstowcs_l and wcsftime_l,
uselocale must be set prior to use the version without _l.
For strtof_l, strtod_l, strtold_l, a wrapper simply calls
the default version.

libstdc++-v3/ChangeLog:
2021-01-12  Clément Chigot  

* acinclude.m4: Add ieee_1003.1-2008 locale model.
* configure: Regenerate.
* config/os/aix/ctype_configure_char.cc: Enable locale support.
* testsuite/lib/libstdc++.exp (check_v3_target_namedlocale):
Handle AIX locale names.
* testsuite/util/testsuite_hooks.h: Likewise.
* config/locale/dragonfly/c_locale.cc: Removed.
* config/locale/dragonfly/c_locale.h: Removed.
* config/locale/dragonfly/codecvt_members.cc: Removed.
* config/locale/dragonfly/collate_members.cc: Removed.
* config/locale/dragonfly/ctype_members.cc: Removed.
* config/locale/dragonfly/monetary_members.cc: Removed.
* config/locale/dragonfly/numeric_members.cc: Removed.
* config/locale/dragonfly/time_members.cc: Removed.
* config/locale/dragonfly/time_members.h: Removed.
* config/locale/ieee_1003.1-2008/c_locale.cc: New file.
* config/locale/ieee_1003.1-2008/c_locale.h: New file.
* config/locale/ieee_1003.1-2008/codecvt_members.cc: New file.
* config/locale/ieee_1003.1-2008/collate_members.cc: New file.
* config/locale/ieee_1003.1-2008/ctype_members.cc: New file.
* config/locale/ieee_1003.1-2008/monetary_members.cc: New file.
* config/locale/ieee_1003.1-2008/numeric_members.cc: New file.
* config/locale/ieee_1003.1-2008/time_members.cc: New file.
* config/locale/ieee_1003.1-2008/time_members.h: New file.
---
 libstdc++-v3/acinclude.m4 | 41 ++---
 .../c_locale.cc   |  3 +
 .../c_locale.h| 31 ++
 .../codecvt_members.cc|  0
 .../collate_members.cc|  0
 .../ctype_members.cc  | 58 +++
 .../monetary_members.cc   | 39 -
 .../numeric_members.cc| 27 +
 .../time_members.cc   | 32 +-
 .../time_members.h|  0
 .../config/os/aix/ctype_configure_char.cc | 44 +++---
 libstdc++-v3/testsuite/lib/libstdc++.exp  |  5 ++
 libstdc++-v3/testsuite/util/testsuite_hooks.h |  3 +
 13 files changed, 252 insertions(+), 31 deletions(-)
 rename libstdc++-v3/config/locale/{dragonfly => ieee_1003.1-2008}/c_locale.cc 
(99%)
 rename libstdc++-v3/config/locale/{dragonfly => ieee_1003.1-2008}/c_locale.h 
(80%)
 rename libstdc++-v3/config/locale/{dragonfly => 
ieee_1003.1-2008}/codecvt_members.cc (100%)
 rename libstdc++-v3/config/locale/{dragonfly => 
ieee_1003.1-2008}/collate_members.cc (100%)
 rename libstdc++-v3/config/locale/{dragonfly => 
ieee_1003.1-2008}/ctype_members.cc (82%)
 rename libstdc++-v3/config/locale/{dragonfly => 
ieee_1003.1-2008}/monetary_members.cc (97%)
 rename libstdc++-v3/config/locale/{dragonfly => 
ieee_1003.1-2008}/numeric_members.cc (93%)
 rename libstdc++-v3/config/locale/{dragonfly => 
ieee_1003.1-2008}/time_members.cc (94%)
 rename libstdc++-v3/config/locale/{dragonfly => 
ieee_1003.1-2008}/time_members.h (100%)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index e4175ea3e64..64a91b72359 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2421,7 +2421,7 @@ dnl
 AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [
   

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

>> Hi David, Clement,
>>
>>> The patch is local to libstdc++ AIX support, so I believe that I can 
>>> approve it.
>>
>>have you considered merging the dragonfly and aix trees?  I'm asking
>>because it seems prudent to try and avoid creating more and more
>>almost-but-not-quite-similar configurations (Solaris might be able to
>>use the same code, at least in 11.4 which has XPG7 support).
>
>Agreed.
>
>See also 
>https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57585data=04%7C01%7Cclement.chigot%40atos.net%7Cb9820136976149e643b408d8b64756c2%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637459764803442555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qinNdbwsbyUdvijD76PanMf0Y1iSfn1FhRAt2T2dl%2B0%3Dreserved=0url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57585data=04%7C01%7Cclement.chigot%40atos.net%7Cb9820136976149e643b408d8b64756c2%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637459764803442555%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qinNdbwsbyUdvijD76PanMf0Y1iSfn1FhRAt2T2dl%2B0%3Dreserved=0>

I haven't thought about that. It should be possible.
The main problem with AIX are the few missing locale functions
(strtof_l, localeconv_l, etc). I've defined some in c_locale.h, some
are simply wrapped by uselocale in the code itself.
The question is if we merged dragonfly, aix and allow others OS
to use this new locale support, what should go in c_locale.h ?
Do we want it to define all missing functions or do we rather
have some #ifdef wrapping "uselocale" when a *_l function
is missing ?
Both way, I'm fearing there will be a lot of #ifdef.

> As I'm sure I've said before, all patches for libstdc++ need to be
> sent to the libstdc++ list.
Sorry, I've forgotten that. I'll try to be more careful next time !

Clément

Re: [PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Hi David,

Alright, I'll see what I can do.
Would "Skip if target = aix" be ok, especially for the few that I have
absolutely no idea why they are failing ?

Clément

From: David Edelsohn 
Sent: Monday, January 11, 2021 4:03 PM
To: CHIGOT, CLEMENT 
Cc: gcc-patches@gcc.gnu.org 
Subject: Re: [PATCH] libstdc++: implement locale support for AIX

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

Hi, Clement

The patch is local to libstdc++ AIX support, so I believe that I can approve it.

libstdc++ loads the gcc testsuite target-supports.exp extensions. The
patch needs to update the libstdc++ testcases to require wchar32 or
utf-8 as appropriate to avoid the failures.

Thanks, David

On Mon, Jan 11, 2021 at 4:14 AM CHIGOT, CLEMENT  wrote:
>
> Hi everyone,
>
> This patch adds a partial locale support in libstdc++
> for AIX.
> The message_members part isn't yet implemented.
>
> The tests have been launched in AIX7.2 and AIX7.1.
> There are a few new tests failing (~20), but most of them
> weren't launched before and they don't seem too much
> related to locale itself. Some are failing in 32bit because
> wchar_t is 16bit on AIX. Some others are failing because
> of some slightly AIX differences.
>
> Please apply for me if approved.
> If possible, could it be backported as is in gcc-10, gcc-9
> and maybe gcc-8 branch ?
> For gcc-8 branch, there is a few changes to be made in
> check_v3_target_namedlocale where the indentation isn't
> the same, and the configure needs to be regenerated too.
> I've already made the patch if needed.
>
> Clément Chigot
> ATOS Bull SAS
> 1 rue de Provence - 38432 Échirolles - France
>

[PATCH] libstdc++: implement locale support for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Hi everyone, 

This patch adds a partial locale support in libstdc++
for AIX. 
The message_members part isn't yet implemented. 

The tests have been launched in AIX7.2 and AIX7.1. 
There are a few new tests failing (~20), but most of them 
weren't launched before and they don't seem too much
related to locale itself. Some are failing in 32bit because 
wchar_t is 16bit on AIX. Some others are failing because 
of some slightly AIX differences.

Please apply for me if approved.
If possible, could it be backported as is in gcc-10, gcc-9
and maybe gcc-8 branch ? 
For gcc-8 branch, there is a few changes to be made in 
check_v3_target_namedlocale where the indentation isn't 
the same, and the configure needs to be regenerated too. 
I've already made the patch if needed.  

Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France



0001-libstdc-implement-locale-support-for-AIX.patch
Description: 0001-libstdc-implement-locale-support-for-AIX.patch

Re: [PATCH] gcc: handle double quotes in symbol name during stabstrings generation

[CHIGOT, CLEMENT via Gcc-patches]

Hi Ian,

Yes it is.

Thanks,
Clément

From: Ian Lance Taylor 
Sent: Friday, December 11, 2020 6:58 PM
To: CHIGOT, CLEMENT 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 
; gofrontend-dev 
Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
stabstrings generation

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

On Thu, Dec 10, 2020 at 9:09 PM Ian Lance Taylor  wrote:
>
> On Tue, Dec 8, 2020 at 5:15 AM CHIGOT, CLEMENT  
> wrote:
> >
> > Any news about this bug ? It's not urgent even if it's breaking gcc builds 
> > with Go language, but I just want to know if you need any inputs/help from 
> > me.
>
> I sent 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgolang.org%2Fcl%2F277232data=04%7C01%7Cclement.chigot%40atos.net%7C237c1d4eb8f24966de6e08d89dfe60e2%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637433063155263771%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=NFRDFAbOGs%2FPqcYp%2BN4U80xXQctwoX3pUSY%2FVrca%2B4w%3Dreserved=0
>  to fix this problem.

Should be fixed now.

Ian


> > 
> > From: CHIGOT, CLEMENT 
> > Sent: Wednesday, December 2, 2020 5:14 PM
> > To: Ian Lance Taylor 
> > Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 
> > 
> > Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
> > stabstrings generation
> >
> > Hi Ian,
> >
> > Here is the test case.
> > If you're compiling with -gstabs you should have a line looking like:
> > .stabs  "type..struct{Type go.bug1.ObjectIdentifier;Value 
> > [][]go.bug1.Extension{asn1:"set"}}:G(0,7)=xsStructType:",32,0,0,0
> >
> > As you can see the " around for "set" aren't escaped.
> > I didn't try to reproduce it on linux/amd64, but I did on linux/ppc64le and 
> > I don't think it's a ppc-only bug.
> >
> > Clément
> > 
> > From: Ian Lance Taylor 
> > Sent: Wednesday, December 2, 2020 4:55 PM
> > To: CHIGOT, CLEMENT 
> > Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 
> > 
> > Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
> > stabstrings generation
> >
> > Caution! External email. Do not open attachments or click links, unless 
> > this email comes from a known sender and you know the content is safe.
> >
> > On Wed, Dec 2, 2020 at 4:24 AM CHIGOT, CLEMENT  
> > wrote:
> > >
> > > Since the new gccgo mangling scheme, libgo compilation is broken on AIX 
> > > (or in Linux with -gstabs) because of a type symbol having a " in its 
> > > name. I've made a patch (see attachment) in order to fix stabstring 
> > > generation, because, IMO, it should be handled anyway.
> > > However, it happens only once in the whole libgo so I don't know if this 
> > > " is intended or not. The problematic type is there: 
> > > https://github.com/golang/go/blob/master/src/crypto/x509/x509.go#L2674. 
> > > Other similar types don't trigger the bug though.
> > >
> > > I've a minimal test which might can be added if you wish, in Golang tests 
> > > or in Gcc Go tests or in both ?
> > >
> > > If the patch is okay, could you please apply it for me ?
> >
> > Could you show me the small test case?  I don't think I understand the
> > problem.  In DWARF I don't see any symbol names with quotation marks.
> > I'm not yet sure that your patch is the right fix.  Thanks.
> >
> > Ian

Re: [PATCH] gcc: handle double quotes in symbol name during stabstrings generation

[CHIGOT, CLEMENT via Gcc-patches]

Hi Ian,

Any news about this bug ? It's not urgent even if it's breaking gcc builds with 
Go language, but I just want to know if you need any inputs/help from me.

Thanks,
Clément

From: CHIGOT, CLEMENT 
Sent: Wednesday, December 2, 2020 5:14 PM
To: Ian Lance Taylor 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 

Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
stabstrings generation

Hi Ian,

Here is the test case.
If you're compiling with -gstabs you should have a line looking like:
.stabs  "type..struct{Type go.bug1.ObjectIdentifier;Value 
[][]go.bug1.Extension{asn1:"set"}}:G(0,7)=xsStructType:",32,0,0,0

As you can see the " around for "set" aren't escaped.
I didn't try to reproduce it on linux/amd64, but I did on linux/ppc64le and I 
don't think it's a ppc-only bug.

Clément

From: Ian Lance Taylor 
Sent: Wednesday, December 2, 2020 4:55 PM
To: CHIGOT, CLEMENT 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 

Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
stabstrings generation

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

On Wed, Dec 2, 2020 at 4:24 AM CHIGOT, CLEMENT  wrote:
>
> Since the new gccgo mangling scheme, libgo compilation is broken on AIX (or 
> in Linux with -gstabs) because of a type symbol having a " in its name. I've 
> made a patch (see attachment) in order to fix stabstring generation, because, 
> IMO, it should be handled anyway.
> However, it happens only once in the whole libgo so I don't know if this " is 
> intended or not. The problematic type is there: 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgolang%2Fgo%2Fblob%2Fmaster%2Fsrc%2Fcrypto%2Fx509%2Fx509.go%23L2674data=04%7C01%7Cclement.chigot%40atos.net%7Ce85b8b57669c47db583508d896db2fc2%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637425215428486700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aB6diiR9Tgo3FTKOm0vmqVVJ%2B5JlCwd9oM5WeUaTaF4%3Dreserved=0.
>  Other similar types don't trigger the bug though.
>
> I've a minimal test which might can be added if you wish, in Golang tests or 
> in Gcc Go tests or in both ?
>
> If the patch is okay, could you please apply it for me ?

Could you show me the small test case?  I don't think I understand the
problem.  In DWARF I don't see any symbol names with quotation marks.
I'm not yet sure that your patch is the right fix.  Thanks.

Ian

Re: [PATCH] gcc: handle double quotes in symbol name during stabstrings generation

[CHIGOT, CLEMENT via Gcc-patches]

Hi Ian,

Here is the test case.
If you're compiling with -gstabs you should have a line looking like:
.stabs  "type..struct{Type go.bug1.ObjectIdentifier;Value 
[][]go.bug1.Extension{asn1:"set"}}:G(0,7)=xsStructType:",32,0,0,0

As you can see the " around for "set" aren't escaped.
I didn't try to reproduce it on linux/amd64, but I did on linux/ppc64le and I 
don't think it's a ppc-only bug.

Clément

From: Ian Lance Taylor 
Sent: Wednesday, December 2, 2020 4:55 PM
To: CHIGOT, CLEMENT 
Cc: gcc-patches@gcc.gnu.org ; David Edelsohn 

Subject: Re: [PATCH] gcc: handle double quotes in symbol name during 
stabstrings generation

Caution! External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.

On Wed, Dec 2, 2020 at 4:24 AM CHIGOT, CLEMENT  wrote:
>
> Since the new gccgo mangling scheme, libgo compilation is broken on AIX (or 
> in Linux with -gstabs) because of a type symbol having a " in its name. I've 
> made a patch (see attachment) in order to fix stabstring generation, because, 
> IMO, it should be handled anyway.
> However, it happens only once in the whole libgo so I don't know if this " is 
> intended or not. The problematic type is there: 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgolang%2Fgo%2Fblob%2Fmaster%2Fsrc%2Fcrypto%2Fx509%2Fx509.go%23L2674data=04%7C01%7Cclement.chigot%40atos.net%7Ce85b8b57669c47db583508d896db2fc2%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C637425215428486700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=aB6diiR9Tgo3FTKOm0vmqVVJ%2B5JlCwd9oM5WeUaTaF4%3Dreserved=0.
>  Other similar types don't trigger the bug though.
>
> I've a minimal test which might can be added if you wish, in Golang tests or 
> in Gcc Go tests or in both ?
>
> If the patch is okay, could you please apply it for me ?

Could you show me the small test case?  I don't think I understand the
problem.  In DWARF I don't see any symbol names with quotation marks.
I'm not yet sure that your patch is the right fix.  Thanks.

Ian


bug_stabs.go
Description: bug_stabs.go

[PATCH] gcc: handle double quotes in symbol name during stabstrings generation

[CHIGOT, CLEMENT via Gcc-patches]

Hi Ian

Since the new gccgo mangling scheme, libgo compilation is broken on AIX (or in 
Linux with -gstabs) because of a type symbol having a " in its name. I've made 
a patch (see attachment) in order to fix stabstring generation, because, IMO, 
it should be handled anyway.
However, it happens only once in the whole libgo so I don't know if this " is 
intended or not. The problematic type is there: 
https://github.com/golang/go/blob/master/src/crypto/x509/x509.go#L2674. Other 
similar types don't trigger the bug though.

I've a minimal test which might can be added if you wish, in Golang tests or in 
Gcc Go tests or in both ?

If the patch is okay, could you please apply it for me ?
Thanks,


Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France


0001-gcc-handle-double-quotes-in-symbol-name-during-stabs.patch
Description: 0001-gcc-handle-double-quotes-in-symbol-name-during-stabs.patch

[PATCH] aix: remove libgomp and libatomic archives before creating FAT archives

[CHIGOT, CLEMENT via Gcc-patches]

libgomp and libatomic might be in use during the build. Thus, ar commands
will failed to add new objetcs to it as the file is considered busy.
Deleting it and recreating it with both architectures fixes that.

libatomic/Changelog:
2020-08-17 Clement Chigot 
 * config/t-aix: Deleting libatomic before creating FAT library.

libgomp/Changelog:
2020-08-17 Clement Chigot 
 * config/t-aix: Deleting libgomp before creating FAT library.


Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France



0001-aix-remove-libgomp-and-libatomic-archives-before-cre.patch
Description: 0001-aix-remove-libgomp-and-libatomic-archives-before-cre.patch

[PATCH] aix: add FAT library support for libstdc++fs.a

[CHIGOT, CLEMENT via Gcc-patches]

Knowing if --enable-libstdcxx-filesystem-ts has been passed to the configure in
the AIX config Makefile would require a lot of change in libstdc++ Makefiles. 
Thus,
it's easier to ignore errors when retrieving objects and check their existence
before adding them.

libstdc++/Changelog:
2020-09-22 Clement Chigot 
 * config/os/aix/t-aix: Add complementary mode object file to libstdc++fs.a



Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France



0001-aix-add-FAT-library-support-for-libstdc-fs.a.patch
Description: 0001-aix-add-FAT-library-support-for-libstdc-fs.a.patch

[PATCH] aix: retrieve AR for configure for FAT library construction

[CHIGOT, CLEMENT via Gcc-patches]

Description:
"ar" was changed to use AR value coming from configure,
as several "ar" might be available. But all the -X flags must first be
removed if the -r option is used. Otherwize, it might replace the
wrong object files.

libgcc/Changelog:
2020-09-22 Clement Chigot 
 * config/rs6000/t-slibgcc-aix: Change ar to use AR value from configure

libatomic/Changelog:
2020-09-22 Clement Chigot 
 * config/t-aix: Change ar to use AR value from configure

libgomp/Changelog:
2020-09-22 Clement Chigot 
 * config/t-aix: Change ar to use AR value from configure

libstdc++/Changelog:
2020-09-22 Clement Chigot 
 * config/os/aix/t-aix: Change ar to use AR value from configure

libgfortran/Changelog:
2020-09-22 Clement Chigot 
 * config/t-aix: Change ar to use AR value from configure




Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France



0001-aix-retrieve-AR-for-configure-for-FAT-library-constr.patch
Description: 0001-aix-retrieve-AR-for-configure-for-FAT-library-constr.patch

[PATCH] gcc: add GCC64 configuration for AIX 7.1

[CHIGOT, CLEMENT via Gcc-patches]

Description:
  This patch adds the support to build 64bit GCC applications on AIX 7.1

Changelog:
2020-07-24 Clement Chigot 

   * config.gcc: Use t-aix64, biarch64 and default64 for cpu_is_64bit.
   * config/rs6000/aix71.h (ASM_SPEC): Remove aix64 option.
   (ASM_SPEC32): New.
   (ASM_SPEC64): New.
   (ASM_CPU_SPEC): Remove vsx and altivec options.
   (CPP_SPEC_COMMON): Rename from CPP_SPEC.
   (CPP_SPEC32): New.
   (CPP_SPEC64): New.
   (CPLUSPLUS_CPP_SPEC): Rename to CPLUSPLUS_CPP_SPEC_COMMON..
   (TARGET_DEFAULT): Only define if not BIARCH.
   (LIB_SPEC_COMMON): Rename from LIB_SPEC.
   (LIB_SPEC32): New.
   (LIB_SPEC64): New.
   (LINK_SPEC_COMMON): Rename from LINK_SPEC.
   (LINK_SPEC32): New.
   (LINK_SPEC64): New.
   (STARTFILE_SPEC): Add 64 bit version of crtcxa and crtdbase.
   (ASM_SPEC): Define 32 and 64 bit alternatives using DEFAULT_ARCH64_P.
   (CPP_SPEC): Same.
   (CPLUSPLUS_CPP_SPEC): Same.
   (LIB_SPEC): Same.
   (LINK_SPEC): Same.
   (SUBTARGET_EXTRA_SPECS): Add new 32/64 specs.



Please apply for me if approved


Clément Chigot
ATOS Bull SAS
1 rue de Provence - 38432 Échirolles - France



0001-gcc-add-GCC64-configuration-for-AIX-7.1.patch
Description: 0001-gcc-add-GCC64-configuration-for-AIX-7.1.patch

[PATCH] libbacktrace: configure check linker support for DWARF-5

[CHIGOT, CLEMENT via Gcc-patches]

Description:
  On AIX, the compiler is able to handle DWARF-5 but not the linker.

Changelog:
2020-07-07 Clement Chigot 
 * configure.ac: Extend check to the linker for DWARF-5 support
 * configure: Regenerate

Please apply for me if approved.
Could it be backported in gcc-10 branch too, please ?

Thanks, 
ClémentFrom 35f784cf22b9f5432c805782d12177189ec68dda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Chigot?= 
Date: Wed, 10 Jun 2020 14:37:03 -0500
Subject: [PATCH] libbacktrace: configure check linker support for DWARF-5

On AIX, the compiler is able to handle DWARF-5 but not the linker.

Changelog:
2020-07-07 Clement Chigot 
 * configure.ac: Extend check to the linker for DWARF-5 support
 * configure: Regenerate
---
 libbacktrace/configure| 7 ---
 libbacktrace/configure.ac | 4 ++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/libbacktrace/configure b/libbacktrace/configure
index b453bae5ae6..8149b7c6508 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -13577,14 +13577,15 @@ else
 CFLAGS="$CFLAGS -gdwarf-5"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
-int i;
+int main(){return 0;}
 _ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
+if ac_fn_c_try_link "$LINENO"; then :
   libbacktrace_cv_lib_dwarf5=yes
 else
   libbacktrace_cv_lib_dwarf5=no
 fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+rm -f core conftest.err conftest.$ac_objext \
+conftest$ac_exeext conftest.$ac_ext
 CFLAGS=$CFLAGS_hold
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $libbacktrace_cv_lib_dwarf5" >&5
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index bd16f20fd0e..21feaf36294 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -465,12 +465,12 @@ AC_SUBST(PTHREAD_CFLAGS)
 
 AM_CONDITIONAL(HAVE_PTHREAD, test "$libgo_cv_lib_pthread" = yes)
 
-dnl Test whether the compiler supports the -gdwarf-5 option.
+dnl Test whether the compiler and the linker support the -gdwarf-5 option.
 AC_CACHE_CHECK([whether -gdwarf-5 is supported],
 [libbacktrace_cv_lib_dwarf5],
 [CFLAGS_hold=$CFLAGS
 CFLAGS="$CFLAGS -gdwarf-5"
-AC_COMPILE_IFELSE([AC_LANG_SOURCE([int i;])],
+AC_LINK_IFELSE([AC_LANG_SOURCE([int main(){return 0;}])],
 [libbacktrace_cv_lib_dwarf5=yes],
 [libbacktrace_cv_lib_dwarf5=no])
 CFLAGS=$CFLAGS_hold])
-- 
2.25.0

[PATCH] libatomic/test: correctly handle multilib in blddir

[CHIGOT, CLEMENT via Gcc-patches]

Hi, 

This patch fixes how the variable blddir is computed inside libatomic testsuite 
in order to ensure that the multilib arguments are taken into account. 

Note that I'm not sure why DejaGNU function "get_multilibs" can correctly 
retrieve the multilib directory in some configurations and won't with some 
others. Anyway, this patch seems a more logical approach to me. 

Changelog:
2020-05-26 Clement Chigot 
  * libatomic/testsuite/lib/libatomic.exp: pass $GCC_UNDER_TEST to
  get_multilibs


Please apply for me if approved.


0001-libatomic-test-correctly-handle-multilib-in-blddir.patch
Description: 0001-libatomic-test-correctly-handle-multilib-in-blddir.patch

gcc/testsuite/go: increase memory in issue4085b.go

[CHIGOT, CLEMENT via Gcc-patches]

Description: 
  On aix/ppc64, it's possible to allocate an array of 1<<50 int, because of the
  wider address space. Thus, increase it to 1<<59 like in Golang toolchain in
  order to trigger the panic.

Changelog:
2020-05-19 Clement Chigot 
  * go.test/test/fixedbugs/issue4085b.go: increase the size of n2 in 64bit


Please apply for me if approved.
Could it be backported in gcc-8 and gcc-9 branch too ? 

Thanks,
Clément Chigot



gcc-8.4.0-gcc-testsuite-go-increase-memory-in-issue4085b.go.patch
Description: gcc-8.4.0-gcc-testsuite-go-increase-memory-in-issue4085b.go.patch

[PATCH] gcc/config/rs6000: fix long double builtins for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Descritpion:
 * This patch fixes the explicit call made by some C long double
   builtins when long doubles are on 64bit for AIX.

Tests:
 * AIX 7.2, 7.1, 6.1: Build/Tests: OK

Changelog:
2020-04-27 Clément Chigot 

gcc-10-gcc-config-rs6000-fix-long-double-builtins-for-AIX-V3.patch
Description: gcc-10-gcc-config-rs6000-fix-long-double-builtins-for-AIX-V3.patch

[PATCH v2] gcc/config/rs6000: Add link with libc128 with -mlong-double-128 for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Description:
 * AIX applications using 128-bit long double must be linked with
   libc128.a, in order to have 128-bit compatible routines.

Tests:
 * AIX 7.2, 7.1, 6.1: Build/Tests: OK

Changelog:
2020-04-03 Clément Chigot 
 * config/rs6000/aix61.h (LIB_SPEC): Add -lc128 with -mlong-double-128.
 * config/rs6000/aix71.h (LIB_SPEC): Likewise.
 * config/rs6000/aix72.h (LIB_SPEC): Likewise.





gcc-8.4.0-gcc-config-rs6000-add-link-with-libc128-with-mlong-d.patch
Description: gcc-8.4.0-gcc-config-rs6000-add-link-with-libc128-with-mlong-d.patch

[PATCH] gcc/config/rs6000: Add link with libc128 with -mlong-double-128 for AIX

[CHIGOT, CLEMENT via Gcc-patches]

Description:
 * AIX applications using 128-bit long double must be linked with
   libc128.a, in order to have 128-bit compatible routines.

Tests:
 * AIX 7.2, 7.1: Build/Tests: OK

Changelog:
 * config/rs6000/aix61.h (LIB_SPEC): Add -lc128 with -mlong-double-128.
 * config/rs6000/aix71.h (LIB_SPEC: Likewise.
 * config/rs6000/aix72.h (LIB_SPEC: Likewise.

gcc-8.4.0-gcc-config-rs6000-add-link-with-libc128-with-mlong-d.patch
Description: gcc-8.4.0-gcc-config-rs6000-add-link-with-libc128-with-mlong-d.patch