Re: [PATCH] xtensa: Optimize stack frame adjustment more
On Thu, Jan 5, 2023 at 10:57 PM Takayuki 'January June' Suwa wrote: > By using the helper function, it makes stack frame adjustment logic > simplified and instruction count less in some cases. I've built a couple linux configurations with and without this change and I observe consistent code size growth, e.g.: iss_defconfig without the change: textdata bss dec hex filename 3014768 164016 115108 3293892 3242c4 vmlinux iss_defconfig with the change: textdata bss dec hex filename 3015296 164008 115108 3294412 3244cc vmlinux virt_defconfig without the change: textdata bss dec hex filename 5498881 2254360 291768 8045009 7ac1d1 vmlinux virt_defconfig with the change: textdata bss dec hex filename 5500389 2254360 291768 8046517 7ac7b5 vmlinux generic_kc705_defconfig without the change: textdata bss dec hex filename 7062530 635340 286400 7984270 79d48e vmlinux generic_kc705_defconfig with the change: textdata bss dec hex filename 7064078 635340 286400 7985818 79da9a vmlinux -- Thanks. -- Max
[PATCH] Handle Windows nul device in unlink-if-ordinary.c
From: Himal
Hi,
This might be a better fix.
Thanks.
---
libiberty/unlink-if-ordinary.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libiberty/unlink-if-ordinary.c b/libiberty/unlink-if-ordinary.c
index 84328b216..e765ac8b1 100644
--- a/libiberty/unlink-if-ordinary.c
+++ b/libiberty/unlink-if-ordinary.c
@@ -62,6 +62,12 @@ was made to unlink the file because it is special.
int
unlink_if_ordinary (const char *name)
{
+/* MS-Windows 'stat' function (and in turn, S_ISREG)
+ reports the null device as a regular file. */
+#ifdef _WIN32
+ if (stricmp (name, "nul") == 0)
+return 1;
+#endif
struct stat st;
if (lstat (name, &st) == 0
--
2.39.0
[PATCH] Handle Windows nul device in unlink-if-ordinary.c
From: Himal
Hi,
This might be a better fix.
Regards.
PS. I had to use a different email.
---
libiberty/unlink-if-ordinary.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libiberty/unlink-if-ordinary.c b/libiberty/unlink-if-ordinary.c
index 84328b216..e765ac8b1 100644
--- a/libiberty/unlink-if-ordinary.c
+++ b/libiberty/unlink-if-ordinary.c
@@ -62,6 +62,12 @@ was made to unlink the file because it is special.
int
unlink_if_ordinary (const char *name)
{
+/* MS-Windows 'stat' function (and in turn, S_ISREG)
+ reports the null device as a regular file. */
+#ifdef _WIN32
+ if (stricmp (name, "nul") == 0)
+return 1;
+#endif
struct stat st;
if (lstat (name, &st) == 0
--
2.39.0
[PATCH] configure: remove dependencies on gmp and mpfr when gdb is disabled
Since 91e0d22025e0bf2af2e364cb7214a05512a0c431, the configure checks
about GMP and MPFR for gdb builds have been moved to the toplevel
configure.
However, it doesn't take into account the --disable-gdb option. Meaning
that a build without gdb will require these libraries even if not
needed.
ChangeLog:
* configure.ac: Skip GMP and MPFR when --disable-gdb is
provided.
* configure: Regenerate.
---
configure| 4 +++-
configure.ac | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index d6716e38e99..85883099410 100755
--- a/configure
+++ b/configure
@@ -7913,7 +7913,9 @@ if test -d ${srcdir}/gcc ; then
require_mpc=yes
fi
if test -d ${srcdir}/gdb ; then
- require_gmp=yes
+ if test "x$enable_gdb" != xno; then
+ require_gmp=yes
+ fi
fi
gmplibs="-lmpfr -lgmp"
diff --git a/configure.ac b/configure.ac
index 737c1a1172b..2b612dce6e9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1489,7 +1489,9 @@ if test -d ${srcdir}/gcc ; then
require_mpc=yes
fi
if test -d ${srcdir}/gdb ; then
- require_gmp=yes
+ if test "x$enable_gdb" != xno; then
+ require_gmp=yes
+ fi
fi
gmplibs="-lmpfr -lgmp"
--
2.25.1
Re: [PATCH] configure: remove dependencies on gmp and mpfr when gdb is disabled
On Fri, Jan 6, 2023 at 9:39 AM Clément Chigot wrote:
>
> Since 91e0d22025e0bf2af2e364cb7214a05512a0c431, the configure checks
> about GMP and MPFR for gdb builds have been moved to the toplevel
> configure.
> However, it doesn't take into account the --disable-gdb option. Meaning
> that a build without gdb will require these libraries even if not
> needed.
>
> ChangeLog:
>
> * configure.ac: Skip GMP and MPFR when --disable-gdb is
> provided.
> * configure: Regenerate.
> ---
> configure| 4 +++-
> configure.ac | 4 +++-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index d6716e38e99..85883099410 100755
> --- a/configure
> +++ b/configure
> @@ -7913,7 +7913,9 @@ if test -d ${srcdir}/gcc ; then
>require_mpc=yes
> fi
> if test -d ${srcdir}/gdb ; then
> - require_gmp=yes
> + if test "x$enable_gdb" != xno; then
> + require_gmp=yes
> + fi
> fi
>
> gmplibs="-lmpfr -lgmp"
> diff --git a/configure.ac b/configure.ac
> index 737c1a1172b..2b612dce6e9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1489,7 +1489,9 @@ if test -d ${srcdir}/gcc ; then
>require_mpc=yes
> fi
> if test -d ${srcdir}/gdb ; then
> - require_gmp=yes
> + if test "x$enable_gdb" != xno; then
> + require_gmp=yes
> + fi
> fi
>
> gmplibs="-lmpfr -lgmp"
> --
> 2.25.1
This patch has already been merged in the binutils repository see [1].
[1]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5fb0e308577143ceb313fde5538dc9ecb038f29f
Thanks,
Clément
Re: [PATCH] configure: remove dependencies on gmp and mpfr when gdb is disabled
> Am 06.01.2023 um 09:44 schrieb Clément Chigot via Gcc-patches
> :
>
> On Fri, Jan 6, 2023 at 9:39 AM Clément Chigot wrote:
>>
>> Since 91e0d22025e0bf2af2e364cb7214a05512a0c431, the configure checks
>> about GMP and MPFR for gdb builds have been moved to the toplevel
>> configure.
>> However, it doesn't take into account the --disable-gdb option. Meaning
>> that a build without gdb will require these libraries even if not
>> needed.
>>
>> ChangeLog:
>>
>>* configure.ac: Skip GMP and MPFR when --disable-gdb is
>>provided.
>>* configure: Regenerate.
>> ---
>> configure| 4 +++-
>> configure.ac | 4 +++-
>> 2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index d6716e38e99..85883099410 100755
>> --- a/configure
>> +++ b/configure
>> @@ -7913,7 +7913,9 @@ if test -d ${srcdir}/gcc ; then
>> require_mpc=yes
>> fi
>> if test -d ${srcdir}/gdb ; then
>> - require_gmp=yes
>> + if test "x$enable_gdb" != xno; then
>> + require_gmp=yes
>> + fi
>> fi
>>
>> gmplibs="-lmpfr -lgmp"
>> diff --git a/configure.ac b/configure.ac
>> index 737c1a1172b..2b612dce6e9 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -1489,7 +1489,9 @@ if test -d ${srcdir}/gcc ; then
>> require_mpc=yes
>> fi
>> if test -d ${srcdir}/gdb ; then
>> - require_gmp=yes
>> + if test "x$enable_gdb" != xno; then
>> + require_gmp=yes
>> + fi
>> fi
>>
>> gmplibs="-lmpfr -lgmp"
>> --
>> 2.25.1
>
> This patch has already been merged in the binutils repository see [1].
Ok for GCC
Richard
> [1]
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5fb0e308577143ceb313fde5538dc9ecb038f29f
>
> Thanks,
> Clément
[PATCH] rs6000: Teach rs6000_opaque_type_invalid_use_p about inline asm [PR108272]
Hi,
As PR108272 shows, there are some invalid uses of MMA opaque
types in inline asm statements. This patch is to teach the
function rs6000_opaque_type_invalid_use_p for inline asm,
check and error any invalid use of MMA opaque types in input
and output operands.
Bootstrapped and regtested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P9 and P10.
I'm going to push this next week if no objections.
Kewen
BR,
-
PR target/108272
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_opaque_type_invalid_use_p): Add the
support for invalid uses in inline asm, factor out the checking and
erroring to lambda function check_and_error_invalid_use.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr108272-1.c: New test.
* gcc.target/powerpc/pr108272-2.c: New test.
---
gcc/config/rs6000/rs6000.cc | 50 +++
gcc/testsuite/gcc.target/powerpc/pr108272-1.c | 17 +++
gcc/testsuite/gcc.target/powerpc/pr108272-2.c | 17 +++
3 files changed, 74 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr108272-1.c
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr108272-2.c
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index d362668ba13..46f74922755 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -28903,9 +28903,9 @@ constant_generates_xxspltidp (vec_const_128bit_type
*vsx_const)
__vector_pair built-in types. They are target specific and
only available when MMA is supported. With MMA supported, it
simply returns true, otherwise it checks if the given gimple
- STMT is an assignment stmt and uses either of these two opaque
- types unexpectedly, if yes, it would raise an error message
- and returns true, otherwise it returns false. */
+ STMT is an assignment or asm stmt and uses either of these two
+ opaque types unexpectedly, if yes, it would raise an error
+ message and returns true, otherwise it returns false. */
bool
rs6000_opaque_type_invalid_use_p (gimple *stmt)
@@ -28913,23 +28913,53 @@ rs6000_opaque_type_invalid_use_p (gimple *stmt)
if (TARGET_MMA)
return false;
+ /* If the given TYPE is one MMA opaque type, emit the corresponding
+ error messages and return true, otherwise return false. */
+ auto check_and_error_invalid_use = [](tree type)
+ {
+if (type == vector_quad_type_node)
+ {
+ error ("type %<__vector_quad%> requires the %qs option", "-mmma");
+ return true;
+ }
+else if (type == vector_pair_type_node)
+ {
+ error ("type %<__vector_pair%> requires the %qs option", "-mmma");
+ return true;
+ }
+return false;
+ };
+
if (stmt)
{
/* The usage of MMA opaque types is very limited for now,
-to check with gassign is enough so far. */
+to check with gassign and gasm is enough so far. */
if (gassign *ga = dyn_cast (stmt))
{
tree lhs = gimple_assign_lhs (ga);
tree type = TREE_TYPE (lhs);
- if (type == vector_quad_type_node)
+ if (check_and_error_invalid_use (type))
+ return true;
+ }
+ else if (gasm *gs = dyn_cast (stmt))
+ {
+ unsigned ninputs = gimple_asm_ninputs (gs);
+ for (unsigned i = 0; i < ninputs; i++)
{
- error ("type %<__vector_quad%> requires the %qs option", "-mmma");
- return true;
+ tree op = gimple_asm_input_op (gs, i);
+ tree val = TREE_VALUE (op);
+ tree type = TREE_TYPE (val);
+ if (check_and_error_invalid_use (type))
+ return true;
}
- else if (type == vector_pair_type_node)
+ unsigned noutputs = gimple_asm_noutputs (gs);
+ for (unsigned i = 0; i < noutputs; i++)
{
- error ("type %<__vector_pair%> requires the %qs option", "-mmma");
- return true;
+ tree op = gimple_asm_output_op (gs, i);
+ tree val = TREE_VALUE (op);
+ tree type = TREE_TYPE (val);
+ if (check_and_error_invalid_use (type))
+ return true;
}
}
}
diff --git a/gcc/testsuite/gcc.target/powerpc/pr108272-1.c
b/gcc/testsuite/gcc.target/powerpc/pr108272-1.c
new file mode 100644
index 000..b99e6a4d86d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr108272-1.c
@@ -0,0 +1,17 @@
+/* { dg-require-effective-target powerpc_p9modulo_ok } */
+/* If the default cpu type is power10 or later, type __vector_quad is
+ supported. To keep the test point available all the time, this case
+ specifies -mdejagnu-cpu=power9 here. */
+/* { dg-options "-mdejagnu-cpu=power9" } */
+
+/* Verify there is no ICE and don't check the error messages on unsupported
+ type since they could be fragile and are not test points of this case. */
+
+/* { dg-excess-errors "pr108272-1" } */
+
+void
[PATCH] rs6000: Allow powerpc64 to be unset for implicit 64 bit [PR108240]
Hi,
Before r13-4894, if 64 bit is explicitly specified, option
powerpc64 is explicitly enabled too; while if 64 bit is
implicitly enabled and there is no explicit setting for
option powerpc64, option powerpc64 is eventually enabled
or not would rely on the default value of the used cpu.
It's initially set as the setting for 64 bit, but later if
the used cpu doesn't have powerpc64 supported by default,
it gets cleared.
To keep it consistent with before (also the relevant error/
warning messages), this patch is to allow that powerpc64
can be unset if 64 bit is enabled implicitly, and only stop
it from being unset if 64 bit is enabled explicitly.
Note that since the behaviors are different for implicit
and explicit 64 bit, I failed to construct one solid test
case since it becomes fragile once RUNTESTFLAGS specifying
-m64 explicitly. BTW, the exposed latent ICE is still
there, would be fixed by a separated patch later.
Bootstrapped and regress-tested on:
- powerpc64-linux-gnu P7 and P8 {-m64,-m32}
- powerpc64le-linux-gnu P9 and P10
- powerpc-ibm-aix7.2.0.0 {-maix64,-maix32}
I'm going to push this next week if no objections.
BR,
Kewen
-
PR target/108240
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Allow
implicit powerpc64 setting to be unset if 64 bit is enabled implicitly.
---
gcc/config/rs6000/rs6000.cc | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 6ac3adcec6b..a9e1a790f28 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -3662,14 +3662,17 @@ rs6000_option_override_internal (bool global_init_p)
/* Without option powerpc64 specified explicitly, we need to ensure
powerpc64 always enabled for 64 bit here, otherwise some following
- checks can use unexpected TARGET_POWERPC64 value. Meanwhile, we
- need to ensure set_masks doesn't have OPTION_MASK_POWERPC64 on,
- otherwise later processing can clear it. */
+ checks can use unexpected TARGET_POWERPC64 value. */
if (!(rs6000_isa_flags_explicit & OPTION_MASK_POWERPC64)
&& TARGET_64BIT)
{
rs6000_isa_flags |= OPTION_MASK_POWERPC64;
- set_masks &= ~OPTION_MASK_POWERPC64;
+ /* Need to stop powerpc64 from being unset in later processing,
+so clear it in set_masks. But as PR108240 shows, to keep it
+consistent with before, we want to make this only if 64 bit
+is enabled explicitly. */
+ if (rs6000_isa_flags_explicit & OPTION_MASK_64BIT)
+ set_masks &= ~OPTION_MASK_POWERPC64;
}
/* Process the -mcpu= and -mtune= argument. If the user changed
--
2.27.0
Re: [PATCH] rs6000: Make P10_FUSION honour tuning setting
Hi Pat,
on 2023/1/6 03:30, Pat Haugen wrote:
> On 1/4/23 3:20 AM, Kewen.Lin via Gcc-patches wrote:
>> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
>> index 88c865b6b4b..6fa084c0807 100644
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -4378,9 +4378,15 @@ rs6000_option_override_internal (bool global_init_p)
>> rs6000_isa_flags &= ~OPTION_MASK_MMA;
>> }
>>
>> - if (TARGET_POWER10
>> - && (rs6000_isa_flags_explicit & OPTION_MASK_P10_FUSION) == 0)
>> - rs6000_isa_flags |= OPTION_MASK_P10_FUSION;
>> + /* Enable power10 fusion if we are tuning for power10, even if we aren't
>> + generating power10 instructions. */
>> + if (!(rs6000_isa_flags_explicit & OPTION_MASK_P10_FUSION))
>> + {
>> + if (processor_target_table[tune_index].processor == PROCESSOR_POWER10)
>
> You can use (rs6000_tune == PROCESSOR_POWER10) at this point.
Good catch, I will update it. Thanks!
BR,
Kewen
[committed] testsuite: Add testcases from PR108292 and PR108308
Hi!
These PRs were for now fixed by reversion of the r13-4977
patch, but so that the problems don't reappear during stage 1,
I'm adding testcase coverage from those PRs.
Tested on x86_64-linux -m32/-m64 before r13-5038 (where all tests
FAIL) and after it (where they PASS), committed to trunk as obvious.
2023-01-06 Jakub Jelinek
PR target/108292
PR target/108308
* gcc.c-torture/execute/pr108292.c: New test.
* gcc.target/i386/pr108292.c: New test.
* gcc.dg/pr108308.c: New test.
--- gcc/testsuite/gcc.c-torture/execute/pr108292.c.jj 2023-01-06
10:40:20.742991257 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr108292.c 2023-01-06
10:41:56.589597398 +0100
@@ -0,0 +1,18 @@
+/* PR target/108292 */
+
+typedef unsigned V __attribute__((__vector_size__ (64)));
+
+V x;
+
+int
+main ()
+{
+ if (sizeof (unsigned) * __CHAR_BIT__ != 32)
+return 0;
+ __builtin_sub_overflow (0, 6, &x[5]);
+ x >>= ((V){} != x) & 31;
+ for (unsigned i = 0; i < 16; i++)
+if (x[i] != (i == 5))
+ __builtin_abort ();
+ return 0;
+}
--- gcc/testsuite/gcc.target/i386/pr108292.c.jj 2023-01-06 10:50:12.382388648
+0100
+++ gcc/testsuite/gcc.target/i386/pr108292.c2023-01-06 10:50:05.704485693
+0100
@@ -0,0 +1,15 @@
+/* PR target/108292 */
+/* { dg-do compile } */
+/* { dg-options "-Ofast -march=alderlake" } */
+
+extern void foo (float *);
+
+extern int x;
+
+int
+bar (void)
+{
+ float y;
+ foo (&y);
+ return y > x ? 1 : 2;
+}
--- gcc/testsuite/gcc.dg/pr108308.c.jj 2023-01-06 10:43:45.793009294 +0100
+++ gcc/testsuite/gcc.dg/pr108308.c 2023-01-06 10:43:40.218090375 +0100
@@ -0,0 +1,39 @@
+/* PR target/108308 */
+/* { dg-do run { target { ilp32 || lp64 } } } */
+/* { dg-options "-Os -fno-tree-ccp" } */
+
+int a = 1, *d = &a, f = 2766708631, h;
+unsigned b = -1, c, e, g;
+
+static void
+foo (int j)
+{
+ if (a)
+{
+ c = ~c;
+ while (e)
+ j = 0;
+ goto k;
+}
+l:
+ h = 1;
+k:
+ *d = (!j) | 80;
+ int m = ~(~(-1 / b) | (a ^ 1)), n = ~(~g / (11 >> m)), o = -1 / n;
+ if (f)
+{
+ b = 9518150474215344 ^ ~f;
+ f = 0;
+ if (c)
+ goto l;
+ if (o)
+ goto k;
+}
+}
+
+int
+main ()
+{
+ foo (1);
+ return 0;
+}
Jakub
[PATCH] Set CROSS_SYSTEM_HEADER_DIR according includedir
For cross building with option: --sysroot=/ --prefix=/usr --includedir=/usr/ just like Debian does, fixinc.sh will use the wrong header files from /usr/include. gcc/ * Makefile.in (CROSS_SYSTEM_HEADER_DIR): set according the value of includedir. --- gcc/Makefile.in | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 6aed2cda3ca..6001c9e3b55 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -532,7 +532,11 @@ LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h # Default native SYSTEM_HEADER_DIR, to be overridden by targets. NATIVE_SYSTEM_HEADER_DIR = @NATIVE_SYSTEM_HEADER_DIR@ # Default cross SYSTEM_HEADER_DIR, to be overridden by targets. -CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@ +ifeq (@includedir@,$(prefix)/include) + CROSS_SYSTEM_HEADER_DIR = @CROSS_SYSTEM_HEADER_DIR@ +else + CROSS_SYSTEM_HEADER_DIR = @includedir@ +endif # autoconf sets SYSTEM_HEADER_DIR to one of the above. # Purge it of unnecessary internal relative paths -- 2.30.2
[PATCH] libsanitizer/mips: always build with largefile support
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 is always used for mips
when build libsanitizer in LLVM. Thus
FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 176 : 160, 216);
instead of
FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216);
in sanitizer_platform_limits_posix.h.
To keep sync with LLVM and to make the code simple, we use the
largefile options always.
libsanitizer/
* configure.ac: set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
always for mips*.
* configure: Regenerate.
---
libsanitizer/configure| 13 ++---
libsanitizer/configure.ac | 12 ++--
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/libsanitizer/configure b/libsanitizer/configure
index d3de3dbba51..d4ee0fac3e7 100755
--- a/libsanitizer/configure
+++ b/libsanitizer/configure
@@ -17045,9 +17045,16 @@ else
$as_echo "no" >&6; }
fi
-EXTRA_CFLAGS="$EXTRA_CFLAGS $CET_FLAGS"
-EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $CET_FLAGS"
-EXTRA_ASFLAGS=$CET_FLAGS
+# Always set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to sync with LLVM,
+# and keep struct *stat* have the same size.
+case "${host}" in
+ mips*-*) FILE64_FLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" ;;
+ *) FILE64_FLAGS="" ;;
+esac
+
+EXTRA_CFLAGS="$EXTRA_CFLAGS $CET_FLAGS $FILE64_FLAGS"
+EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $CET_FLAGS $FILE64_FLAGS"
+EXTRA_ASFLAGS="$CET_FLAGS $FILE64_FLAGS"
diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
index ad49f29db7e..04cd8910ed6 100644
--- a/libsanitizer/configure.ac
+++ b/libsanitizer/configure.ac
@@ -416,8 +416,16 @@ GCC_BASE_VER
# Add CET specific flags if Intel CET is enabled.
GCC_CET_FLAGS(CET_FLAGS)
-EXTRA_CFLAGS="$EXTRA_CFLAGS $CET_FLAGS"
-EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $CET_FLAGS"
+
+# Always set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to sync with LLVM,
+# and keep struct *stat* have the same size.
+case "${host}" in
+ mips*-*) FILE64_FLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" ;;
+ *) FILE64_FLAGS="" ;;
+esac
+
+EXTRA_CFLAGS="$EXTRA_CFLAGS $CET_FLAGS $FILE64_FLAGS"
+EXTRA_CXXFLAGS="$EXTRA_CXXFLAGS $CET_FLAGS $FILE64_FLAGS"
EXTRA_ASFLAGS=$CET_FLAGS
AC_SUBST(EXTRA_ASFLAGS)
AC_SUBST(EXTRA_CFLAGS)
--
2.30.2
[wwwdocs] Document libstdc++ additions for GCC 12 and 13
Pushed to wwwdocs. --- htdocs/gcc-12/changes.html | 1 + htdocs/gcc-13/changes.html | 18 +- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index b3775f82..1cefaf13 100644 --- a/htdocs/gcc-12/changes.html +++ b/htdocs/gcc-12/changes.html @@ -505,6 +505,7 @@ function Multiply (S1, S2 : Sign) return Sign is Improved experimental C++23 support, including: Monadic operations for std::optional. + std::expected std::move_only_functionstd::basic_string::resize_and_overwrite diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 3876ad77..d9879d79 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -224,14 +224,30 @@ a work-in-progress. Runtime Library (libstdc++) + Improved experimental support for C++20, including: + + header and std::format. +std::chrono::utc_clock and other clocks, time zones, + and std::format support in the + header. + + + Improved experimental support for C++23, including: Additions to the header: views::zip, views::zip_transform, views::adjacent, views::adjacent_transform views::pairwise, views::slide, - views::chunk, views::chunk_by. + views::chunk, views::chunk_by, + views::repeat, views::chunk_by, + views::cartesian_product, views::as_rvalue. + +Monadic operations for std::optional. +Constexpr std::bitset, std::to_chars + and std::from_chars. +Library support for extended floating-point types. Support for the header -- 2.39.0
[wwwdocs] Fix typo in libstdc++ release notes
The monadic ops for std::optional were in GCC 12, I meant to say std::expected in the GCC 13 release notes. --- htdocs/gcc-13/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index d9879d79..41a117b4 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -243,7 +243,7 @@ a work-in-progress. views::repeat, views::chunk_by, views::cartesian_product, views::as_rvalue. -Monadic operations for std::optional. +Monadic operations for std::expected. Constexpr std::bitset, std::to_chars and std::from_chars. -- 2.39.0
[PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR middle-end/106133
gcc/ChangeLog:
* diagnostic.cc (diagnostic_output_format_init): If
-fdiagnostics-format=json-file and -E is used, then
base_file_name is null and we should not emit anything.
---
gcc/diagnostic.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index c90c14e993e..fe7d121e340 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -2277,6 +2277,9 @@ diagnostic_output_format_init (diagnostic_context
*context,
const char *base_file_name,
enum diagnostics_output_format format)
{
+ if (base_file_name == NULL)
+return;
+
switch (format)
{
default:
--
2.39.0
Re: [PATCH] ipa: Sort ipa_param_body_adjustments::m_replacements (PR 108110)
Hi Martin
> + key.unit_offset = unit_offset;
> + ipa_param_body_replacement *res
> += std::lower_bound (m_replacements.begin (), m_replacements.end (), key,
> + [] (const ipa_param_body_replacement &elt,
> + const ipa_param_body_replacement &val)
> + {
> + if (DECL_UID (elt.base) < DECL_UID (val.base))
> + return true;
> + if (DECL_UID (elt.base) > DECL_UID (val.base))
> + return false;
> + if (elt.unit_offset < val.unit_offset)
> + return true;
> + return false;
> + });
I'm curious if we can re-use compare_param_body_replacement as the introduced
lambda does a very similar thing, right?
Thanks,
Martin
[committed] libstdc++: Fix deadlock in debug iterator increment [PR108288]
Tested x86_64-linux. Pushed to trunk.
I think we should backport this too, after some soak time on trunk.
-- >8 --
With -fno-elide-constructors the debug iterator post-increment and
post-decrement operators are susceptible to deadlock. They take a mutex
lock and then return a temporary, which also attempts to take a lock to
attach itself to the sequence. If the return value and *this happen to
collide and use the same mutex from the pool, then you get a deadlock
trying to lock a mutex that is already held by the current thread.
The solution is to construct the return value before taking the lock.
The copy constructor and pre-inc/pre-dec operators already manage locks
correctly, without deadlock, so just implement post-inc/post-dec in the
conventional way, taking a copy then modifying *this, then returning the
copy.
libstdc++-v3/ChangeLog:
PR libstdc++/108288
* include/debug/safe_iterator.h (_Safe_iterator::operator++(int))
(_Safe_iterator::operator--(int)): Do not hold lock around
construction of return value.
---
libstdc++-v3/include/debug/safe_iterator.h | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/libstdc++-v3/include/debug/safe_iterator.h
b/libstdc++-v3/include/debug/safe_iterator.h
index 117dc93de60..f9068eaf8d6 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -761,12 +761,9 @@ namespace __gnu_debug
_Safe_iterator
operator++(int) _GLIBCXX_NOEXCEPT
{
- _GLIBCXX_DEBUG_VERIFY(this->_M_incrementable(),
- _M_message(__msg_bad_inc)
- ._M_iterator(*this, "this"));
- __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
- return _Safe_iterator(this->base()++, this->_M_sequence,
- _Attach_single());
+ _Safe_iterator __ret = *this;
+ ++*this;
+ return __ret;
}
// -- Bidirectional iterator requirements --
@@ -788,12 +785,9 @@ namespace __gnu_debug
_Safe_iterator
operator--(int) _GLIBCXX_NOEXCEPT
{
- _GLIBCXX_DEBUG_VERIFY(this->_M_decrementable(),
- _M_message(__msg_bad_dec)
- ._M_iterator(*this, "this"));
- __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());
- return _Safe_iterator(this->base()--, this->_M_sequence,
- _Attach_single());
+ _Safe_iterator __ret = *this;
+ --*this;
+ return __ret;
}
// -- Random access iterator requirements --
--
2.39.0
Re: [PATCH 3/3] vect: inbranch SIMD clones
Here's a new version of the patch.
On 01/12/2022 14:16, Jakub Jelinek wrote:
+void __attribute__((noinline))
You should use noipa attribute instead of noinline on callers
which aren't declare simd (on declare simd it would prevent cloning
which is essential for the declare simd behavior), so that you don't
get surprises e.g. from extra ipa cp etc.
Fixed.
+/* Ensure the the in-branch simd clones are used on targets that support
+ them. These counts include all call and definitions. */
+
+/* { dg-skip-if "" { x86_64-*-* } { "-flto" } { "" } } */
Drop lines line above.
I don't want to drop the comment because I get so frustrated by
testcases that fail when something changes and it's not obvious what the
original author was actually trying to test.
I've tried to fix the -flto thing and I can't figure out how. The
problem seems to be that there are two dump files from the two compiler
invocations and it scans the wrong one. Aarch64 has the same problem.
+/* { dg-final { scan-tree-dump-times "simdclone" 18 "optimized" { target
x86_64-*-* } } } */
+/* { dg-final { scan-tree-dump-times "simdclone" 7 "optimized" { target
amdgcn-*-* } } } */
And scan-tree-dump-times " = foo.simdclone" 2 "optimized"; I'd think that
should be the right number for all of x86_64, amdgcn and aarch64. And
please don't forget about i?86-*-* too.
I've switched the pattern and changed to using the "vect" dump (instead
of "optimized") so that the later transformations don't mess up the
counts. However there are still other reasons why the count varies. It
might be that those can be turned off by options somehow, but probably
testing those cases is valuable too. The values are 2, 3, or 4, now,
instead of 18, so that's an improvement.
+/* TODO: aarch64 */
For aarch64, one would need to include it in
check_effective_target_vect_simd_clones
first...
I've done so and tested it, but that's not included in the patch because
there were other testcases that started reporting fails. None of the new
testcases fail for Aarch64.
OK now?
Andrewvect: inbranch SIMD clones
There has been support for generating "inbranch" SIMD clones for a long time,
but nothing actually uses them (as far as I can see).
This patch add supports for a sub-set of possible cases (those using
mask_mode == VOIDmode). The other cases fail to vectorize, just as before,
so there should be no regressions.
The sub-set of support should cover all cases needed by amdgcn, at present.
gcc/ChangeLog:
* internal-fn.cc (expand_MASK_CALL): New.
* internal-fn.def (MASK_CALL): New.
* internal-fn.h (expand_MASK_CALL): New prototype.
* omp-simd-clone.cc (simd_clone_adjust_argument_types): Set vector_type
for mask arguments also.
* tree-if-conv.cc: Include cgraph.h.
(if_convertible_stmt_p): Do if conversions for calls to SIMD calls.
(predicate_statements): Convert functions to IFN_MASK_CALL.
* tree-vect-loop.cc (vect_get_datarefs_in_loop): Recognise
IFN_MASK_CALL as a SIMD function call.
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Handle
IFN_MASK_CALL as an inbranch SIMD function call.
Generate the mask vector arguments.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-simd-clone-16.c: New test.
* gcc.dg/vect/vect-simd-clone-16b.c: New test.
* gcc.dg/vect/vect-simd-clone-16c.c: New test.
* gcc.dg/vect/vect-simd-clone-16d.c: New test.
* gcc.dg/vect/vect-simd-clone-16e.c: New test.
* gcc.dg/vect/vect-simd-clone-16f.c: New test.
* gcc.dg/vect/vect-simd-clone-17.c: New test.
* gcc.dg/vect/vect-simd-clone-17b.c: New test.
* gcc.dg/vect/vect-simd-clone-17c.c: New test.
* gcc.dg/vect/vect-simd-clone-17d.c: New test.
* gcc.dg/vect/vect-simd-clone-17e.c: New test.
* gcc.dg/vect/vect-simd-clone-17f.c: New test.
* gcc.dg/vect/vect-simd-clone-18.c: New test.
* gcc.dg/vect/vect-simd-clone-18b.c: New test.
* gcc.dg/vect/vect-simd-clone-18c.c: New test.
* gcc.dg/vect/vect-simd-clone-18d.c: New test.
* gcc.dg/vect/vect-simd-clone-18e.c: New test.
* gcc.dg/vect/vect-simd-clone-18f.c: New test.
diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
index 9471f543191..d9e11bfc62a 100644
--- a/gcc/internal-fn.cc
+++ b/gcc/internal-fn.cc
@@ -4527,3 +4527,10 @@ void
expand_ASSUME (internal_fn, gcall *)
{
}
+
+void
+expand_MASK_CALL (internal_fn, gcall *)
+{
+ /* This IFN should only exist between ifcvt and vect passes. */
+ gcc_unreachable ();
+}
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index 61516dab66d..301c3780659 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -466,6 +466,9 @@ DEF_INTERNAL_FN (TRAP, ECF_CONST | ECF_LEAF | ECF_NORETURN
DEF_INTERNAL_FN (ASSUME, ECF_CONST | ECF_LEAF | ECF_NOTHROW
| ECF_LOOPING_CONST_OR_PURE, NULL)
+/* For if-conversion o
[PATCH] Remove legacy pre-C++ 11 definitions
As mentioned in the PRs, both are defined in C++ 11 which is a version we depend on. Ready to be installed now? Thanks, Martin PR middle-end/108311 PR middle-end/108312 gcc/ChangeLog: * system.h (va_copy): Remove as it is defined in C++ 11. (NULL): Likewise. --- gcc/system.h | 13 - 1 file changed, 13 deletions(-) diff --git a/gcc/system.h b/gcc/system.h index 5eaeb9d2d03..0d06b9749e5 100644 --- a/gcc/system.h +++ b/gcc/system.h @@ -31,25 +31,12 @@ along with GCC; see the file COPYING3. If not see /* We must include stdarg.h before stdio.h. */ #include -#ifndef va_copy -# ifdef __va_copy -# define va_copy(d,s) __va_copy (d, s) -# else -# define va_copy(d,s) ((d) = (s)) -# endif -#endif - #ifdef HAVE_STDDEF_H # include #endif #include -/* Define a generic NULL if one hasn't already been defined. */ -#ifndef NULL -#define NULL 0 -#endif - /* Use the unlocked open routines from libiberty. */ /* Some of these are #define on some systems, e.g. on AIX to redirect -- 2.39.0
[PATCH] rs6000: mark tieable between INT and FLOAT
Hi,
During discussing/review patches in maillist, we find more modes are
tieable, e.g. DI<->DF. With some discussion, I drafted this patch
to mark more tieable modes.
Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_modes_tieable_p): Mark more tieable
modes.
gcc/testsuite/ChangeLog:
* g++.target/powerpc/pr102024.C: Updated.
---
gcc/config/rs6000/rs6000.cc | 9 +
gcc/testsuite/g++.target/powerpc/pr102024.C | 3 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 6ac3adcec6b..3cb0186089e 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -1968,6 +1968,15 @@ rs6000_modes_tieable_p (machine_mode mode1, machine_mode
mode2)
if (ALTIVEC_OR_VSX_VECTOR_MODE (mode2))
return false;
+ /* SFmode format (IEEE DP) in register would not as required,
+ So SFmode is restrict here. */
+ if (GET_MODE_CLASS (mode1) == MODE_FLOAT
+ && GET_MODE_CLASS (mode2) == MODE_INT)
+return GET_MODE_SIZE (mode2) == UNITS_PER_FP_WORD && mode1 != SFmode;
+ if (GET_MODE_CLASS (mode1) == MODE_INT
+ && GET_MODE_CLASS (mode2) == MODE_FLOAT)
+return GET_MODE_SIZE (mode1) == UNITS_PER_FP_WORD && mode2 != SFmode;
+
if (SCALAR_FLOAT_MODE_P (mode1))
return SCALAR_FLOAT_MODE_P (mode2);
if (SCALAR_FLOAT_MODE_P (mode2))
diff --git a/gcc/testsuite/g++.target/powerpc/pr102024.C
b/gcc/testsuite/g++.target/powerpc/pr102024.C
index 769585052b5..27d2dc5e80b 100644
--- a/gcc/testsuite/g++.target/powerpc/pr102024.C
+++ b/gcc/testsuite/g++.target/powerpc/pr102024.C
@@ -5,7 +5,8 @@
// Test that a zero-width bit field in an otherwise homogeneous aggregate
// generates a psabi warning and passes arguments in GPRs.
-// { dg-final { scan-assembler-times {\mstd\M} 4 } }
+// { dg-final { scan-assembler-times {\mmtvsrd\M} 4 { target has_arch_pwr8 } }
}
+// { dg-final { scan-assembler-times {\mstd\M} 4 { target { ! has_arch_pwr8 }
} } }
struct a_thing
{
--
2.17.1
Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file
On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:
> Patch can bootstrap on x86_64-linux-gnu and survives regression
> tests.
Thanks for the patch.
I noticed that you marked PR 108307 as a dup of this, which covers
-fdiagnostics-format=sarif-file (and a .S file as input).
The patch doesn't add any test coverage (for either of the diagnostic
formats).
If we try to emit a diagnostic and base_file_name is NULL, and the user
requested one of -fdiagnostics-format={json,sarif}-file, where do the
diagnostics go? Where should they go?
Dave
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR middle-end/106133
>
> gcc/ChangeLog:
>
> * diagnostic.cc (diagnostic_output_format_init): If
> -fdiagnostics-format=json-file and -E is used, then
> base_file_name is null and we should not emit anything.
> ---
> gcc/diagnostic.cc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
> index c90c14e993e..fe7d121e340 100644
> --- a/gcc/diagnostic.cc
> +++ b/gcc/diagnostic.cc
> @@ -2277,6 +2277,9 @@ diagnostic_output_format_init
> (diagnostic_context *context,
> const char *base_file_name,
> enum diagnostics_output_format format)
> {
> + if (base_file_name == NULL)
> + return;
> +
> switch (format)
> {
> default:
[committed] libstdc++: Disable broken std::format for floating-point types [PR108221]
Tested x86_64-linux, built (but not tested) on h8300-elf. Pushed to trunk. -- >8 -- If we don't have std::to_chars for floating-point types (either because float and double are not IEEE format, or size_t is 16-bit) then we can't use them with std::format. This causes a bootstrap failure since std/c++20/tzdb.cc was added to the library, because now includes . This change just disables formatting support for those types. This is not a proper fix, but solves the bootstrap failure for now. libstdc++-v3/ChangeLog: PR libstdc++/108221 * include/std/format (basic_format_arg) [!__cpp_lib_to_chars]: Disable visiting floating-point types. --- libstdc++-v3/include/std/format | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format index 98421e8c123..77f7c9fef3f 100644 --- a/libstdc++-v3/include/std/format +++ b/libstdc++-v3/include/std/format @@ -3034,6 +3034,7 @@ namespace __format return std::forward<_Visitor>(__vis)(_M_val._M_ll); case _Arg_ull: return std::forward<_Visitor>(__vis)(_M_val._M_ull); +#if __cpp_lib_to_chars // FIXME: need to be able to format these types! case _Arg_flt: return std::forward<_Visitor>(__vis)(_M_val._M_flt); case _Arg_dbl: @@ -3046,6 +3047,7 @@ namespace __format return std::forward<_Visitor>(__vis)(_M_val._M_f128); case _Arg_ibm128: return std::forward<_Visitor>(__vis)(_M_val._M_ibm128); +#endif #endif case _Arg_str: return std::forward<_Visitor>(__vis)(_M_val._M_str); -- 2.39.0
[committed] libstdc++: Fix misuse of alloca in std::bitset [PR108214]
I done a silly. Tested x86_64-linux, pushed to trunk.
-- >8 --
The use of alloca in a constructor is wrong, because the memory is gone
after the constructor returns, and will be overwritten by a subsequent
function call. This didn't show up in testing because function inlining
alters the stack usage.
libstdc++-v3/ChangeLog:
PR libstdc++/108214
* include/std/bitset (operator>>): Use alloca in the right
scope, not in a constructor.
* testsuite/20_util/bitset/io/input.cc: Check case from PR.
---
libstdc++-v3/include/std/bitset | 24 +++
.../testsuite/20_util/bitset/io/input.cc | 21
2 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/libstdc++-v3/include/std/bitset b/libstdc++-v3/include/std/bitset
index 1f3f68fefce..edda0776629 100644
--- a/libstdc++-v3/include/std/bitset
+++ b/libstdc++-v3/include/std/bitset
@@ -1598,20 +1598,24 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
struct _Buffer
{
- _Buffer()
- : _M_base(_Nb > 256 ? new _CharT[_Nb] : (_CharT*)__builtin_alloca(_Nb))
- { }
+ static _GLIBCXX_CONSTEXPR bool _S_use_alloca() { return _Nb <= 256; }
+
+ explicit _Buffer(_CharT* __p) : _M_ptr(__p) { }
~_Buffer()
{
- if _GLIBCXX17_CONSTEXPR (_Nb > 256)
- delete[] _M_base;
+ if _GLIBCXX17_CONSTEXPR (!_S_use_alloca())
+ delete[] _M_ptr;
}
- _CharT* const _M_base;
+ _CharT* const _M_ptr;
};
- _Buffer __buf;
- _CharT* __ptr = __buf._M_base;
+ _CharT* __ptr;
+ if _GLIBCXX17_CONSTEXPR (_Buffer::_S_use_alloca())
+ __ptr = (_CharT*)__builtin_alloca(_Nb);
+ else
+ __ptr = new _CharT[_Nb];
+ const _Buffer __buf(__ptr);
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 303. Bitset input operator underspecified
@@ -1662,8 +1666,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
if _GLIBCXX17_CONSTEXPR (_Nb)
{
- if (size_t __len = __ptr - __buf._M_base)
- __x.template _M_copy_from_ptr<_CharT, _Traits>(__buf._M_base, __len,
+ if (size_t __len = __ptr - __buf._M_ptr)
+ __x.template _M_copy_from_ptr<_CharT, _Traits>(__buf._M_ptr, __len,
0, __len,
__zero, __one);
else
diff --git a/libstdc++-v3/testsuite/20_util/bitset/io/input.cc
b/libstdc++-v3/testsuite/20_util/bitset/io/input.cc
index 0f22cefbb5b..4f7e6281ac5 100644
--- a/libstdc++-v3/testsuite/20_util/bitset/io/input.cc
+++ b/libstdc++-v3/testsuite/20_util/bitset/io/input.cc
@@ -42,8 +42,29 @@ void test01()
VERIFY( ss.rdstate() == ios_base::goodbit ); // LWG 3199
}
+void
+test02()
+{
+ std::bitset<4> a(0b1100), b;
+ std::stringstream ss;
+ ss << a;
+ ss >> b; // PR libstdc++/108214
+ VERIFY( b == a );
+
+ ss.str("");
+ ss.clear();
+
+ std::bitset<4000> c, d;
+ for (int i = 0; i < 4000; i += 5)
+c.flip(i);
+ ss << c;
+ ss >> d;
+ VERIFY( d == c );
+}
+
int main()
{
test01();
+ test02();
return 0;
}
--
2.39.0
[PATCH] libstdc++: Add feature-test macros for implemented C++23 views [PR108260]
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc++/108620
libstdc++-v3/ChangeLog:
* include/bits/utility.h (__cpp_lib_ranges_zip): Define.
* include/std/ranges (__cpp_lib_ranges_zip): Define.
(__cpp_lib_ranges_chunk): Define.
(__cpp_lib_ranges_slide): Define.
(__cpp_lib_ranges_chunk_by): Define.
(__cpp_lib_ranges_join_with): Define.
(__cpp_lib_ranges_repeat): Define.
(__cpp_lib_ranges_stride): Define.
(__cpp_lib_ranges_cartesian_product): Define.
(__cpp_lib_ranges_as_rvalue): Define.
* include/std/version: Likewise.
* testsuite/20_util/tuple/p2321r2.cc: Test feature-test macro.
* testsuite/std/ranges/adaptors/as_rvalue/1.cc: Likewise.
* testsuite/std/ranges/adaptors/chunk/1.cc: Likewise.
* testsuite/std/ranges/adaptors/chunk_by/1.cc: Likewise.
* testsuite/std/ranges/adaptors/join_with/1.cc: Likewise.
* testsuite/std/ranges/adaptors/slide/1.cc: Likewise.
* testsuite/std/ranges/adaptors/stride/1.cc: Likewise.
* testsuite/std/ranges/cartesian_product/1.cc: Likewise.
* testsuite/std/ranges/repeat/1.cc: Likewise.
* testsuite/std/ranges/zip/1.cc: Likewise.
* testsuite/std/ranges/version_c++23.cc: New test.
---
libstdc++-v3/include/bits/utility.h | 4 ++
libstdc++-v3/include/std/ranges | 19
libstdc++-v3/include/std/version | 9
.../testsuite/20_util/tuple/p2321r2.cc| 4 ++
.../std/ranges/adaptors/as_rvalue/1.cc| 4 ++
.../testsuite/std/ranges/adaptors/chunk/1.cc | 4 ++
.../std/ranges/adaptors/chunk_by/1.cc | 4 ++
.../std/ranges/adaptors/join_with/1.cc| 4 ++
.../testsuite/std/ranges/adaptors/slide/1.cc | 4 ++
.../testsuite/std/ranges/adaptors/stride/1.cc | 4 ++
.../std/ranges/cartesian_product/1.cc | 4 ++
libstdc++-v3/testsuite/std/ranges/repeat/1.cc | 4 ++
.../testsuite/std/ranges/version_c++23.cc | 44 +++
libstdc++-v3/testsuite/std/ranges/zip/1.cc| 4 ++
14 files changed, 116 insertions(+)
create mode 100644 libstdc++-v3/testsuite/std/ranges/version_c++23.cc
diff --git a/libstdc++-v3/include/bits/utility.h
b/libstdc++-v3/include/bits/utility.h
index 6a192e27836..fac6c7dc3bd 100644
--- a/libstdc++-v3/include/bits/utility.h
+++ b/libstdc++-v3/include/bits/utility.h
@@ -263,6 +263,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ using type = _Tp1; };
#endif
+#if __cplusplus > 202002L
+#define __cpp_lib_ranges_zip 202110L // for and
+#endif
+
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index ba544e116e1..dce7867e977 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -4364,6 +4364,9 @@ namespace views::__adaptor
} // namespace views
#if __cplusplus > 202002L
+
+#define __cpp_lib_ranges_zip 202110L
+
namespace __detail
{
template
@@ -5802,6 +5805,8 @@ namespace views::__adaptor
inline constexpr auto pairwise_transform = adjacent_transform<2>;
}
+#define __cpp_lib_ranges_chunk 202202L
+
namespace __detail
{
template
@@ -6339,6 +6344,8 @@ namespace views::__adaptor
inline constexpr _Chunk chunk;
}
+#define __cpp_lib_ranges_slide 202202L
+
namespace __detail
{
template
@@ -6702,6 +6709,8 @@ namespace views::__adaptor
inline constexpr _Slide slide;
}
+#define __cpp_lib_ranges_chunk_by 202202L
+
template, iterator_t<_Vp>> _Pred>
requires view<_Vp> && is_object_v<_Pred>
@@ -6895,6 +6904,8 @@ namespace views::__adaptor
inline constexpr _ChunkBy chunk_by;
}
+#define __cpp_lib_ranges_join_with 202202L
+
namespace __detail
{
template
@@ -7375,6 +7386,8 @@ namespace views::__adaptor
inline constexpr _JoinWith join_with;
} // namespace views
+#define __cpp_lib_ranges_repeat 202207L
+
template
requires (is_object_v<_Tp> && same_as<_Tp, remove_cv_t<_Tp>>
&& (__detail::__is_integer_like<_Bound> || same_as<_Bound,
unreachable_sentinel_t>))
@@ -7626,6 +7639,8 @@ namespace views::__adaptor
}
}
+#define __cpp_lib_ranges_stride 202207L
+
template
requires view<_Vp>
class stride_view : public view_interface>
@@ -7977,6 +7992,8 @@ namespace views::__adaptor
inline constexpr _Stride stride;
}
+#define __cpp_lib_ranges_cartesian_product 202207L
+
namespace __detail
{
template
@@ -8487,6 +8504,8 @@ namespace views::__adaptor
inline constexpr _CartesianProduct cartesian_product;
}
+#define __cpp_lib_ranges_as_rvalue 202207L
+
template
requires view<_Vp>
class as_rvalue_view : public view_interface>
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index c1a9896b0c2..5730357793d 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -
Re: [PATCH] libstdc++: Add feature-test macros for implemented C++23 views [PR108260]
On Fri, 6 Jan 2023, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> PR libstdc++/108620
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/utility.h (__cpp_lib_ranges_zip): Define.
> * include/std/ranges (__cpp_lib_ranges_zip): Define.
> (__cpp_lib_ranges_chunk): Define.
> (__cpp_lib_ranges_slide): Define.
> (__cpp_lib_ranges_chunk_by): Define.
> (__cpp_lib_ranges_join_with): Define.
> (__cpp_lib_ranges_repeat): Define.
> (__cpp_lib_ranges_stride): Define.
> (__cpp_lib_ranges_cartesian_product): Define.
> (__cpp_lib_ranges_as_rvalue): Define.
> * include/std/version: Likewise.
> * testsuite/20_util/tuple/p2321r2.cc: Test feature-test macro.
> * testsuite/std/ranges/adaptors/as_rvalue/1.cc: Likewise.
> * testsuite/std/ranges/adaptors/chunk/1.cc: Likewise.
> * testsuite/std/ranges/adaptors/chunk_by/1.cc: Likewise.
> * testsuite/std/ranges/adaptors/join_with/1.cc: Likewise.
> * testsuite/std/ranges/adaptors/slide/1.cc: Likewise.
> * testsuite/std/ranges/adaptors/stride/1.cc: Likewise.
> * testsuite/std/ranges/cartesian_product/1.cc: Likewise.
> * testsuite/std/ranges/repeat/1.cc: Likewise.
> * testsuite/std/ranges/zip/1.cc: Likewise.
> * testsuite/std/ranges/version_c++23.cc: New test.
> ---
> libstdc++-v3/include/bits/utility.h | 4 ++
> libstdc++-v3/include/std/ranges | 19
> libstdc++-v3/include/std/version | 9
> .../testsuite/20_util/tuple/p2321r2.cc| 4 ++
> .../std/ranges/adaptors/as_rvalue/1.cc| 4 ++
> .../testsuite/std/ranges/adaptors/chunk/1.cc | 4 ++
> .../std/ranges/adaptors/chunk_by/1.cc | 4 ++
> .../std/ranges/adaptors/join_with/1.cc| 4 ++
> .../testsuite/std/ranges/adaptors/slide/1.cc | 4 ++
> .../testsuite/std/ranges/adaptors/stride/1.cc | 4 ++
> .../std/ranges/cartesian_product/1.cc | 4 ++
> libstdc++-v3/testsuite/std/ranges/repeat/1.cc | 4 ++
> .../testsuite/std/ranges/version_c++23.cc | 44 +++
> libstdc++-v3/testsuite/std/ranges/zip/1.cc| 4 ++
> 14 files changed, 116 insertions(+)
> create mode 100644 libstdc++-v3/testsuite/std/ranges/version_c++23.cc
>
> diff --git a/libstdc++-v3/include/bits/utility.h
> b/libstdc++-v3/include/bits/utility.h
> index 6a192e27836..fac6c7dc3bd 100644
> --- a/libstdc++-v3/include/bits/utility.h
> +++ b/libstdc++-v3/include/bits/utility.h
> @@ -263,6 +263,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> { using type = _Tp1; };
> #endif
>
> +#if __cplusplus > 202002L
> +#define __cpp_lib_ranges_zip 202110L // for and
> +#endif
> +
> _GLIBCXX_END_NAMESPACE_VERSION
> } // namespace
>
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index ba544e116e1..dce7867e977 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -4364,6 +4364,9 @@ namespace views::__adaptor
>} // namespace views
>
> #if __cplusplus > 202002L
> +
> +#define __cpp_lib_ranges_zip 202110L
> +
>namespace __detail
>{
> template
> @@ -5802,6 +5805,8 @@ namespace views::__adaptor
> inline constexpr auto pairwise_transform = adjacent_transform<2>;
>}
>
> +#define __cpp_lib_ranges_chunk 202202L
> +
>namespace __detail
>{
> template
> @@ -6339,6 +6344,8 @@ namespace views::__adaptor
> inline constexpr _Chunk chunk;
>}
>
> +#define __cpp_lib_ranges_slide 202202L
> +
>namespace __detail
>{
> template
> @@ -6702,6 +6709,8 @@ namespace views::__adaptor
> inline constexpr _Slide slide;
>}
>
> +#define __cpp_lib_ranges_chunk_by 202202L
> +
>template indirect_binary_predicate, iterator_t<_Vp>> _Pred>
> requires view<_Vp> && is_object_v<_Pred>
> @@ -6895,6 +6904,8 @@ namespace views::__adaptor
> inline constexpr _ChunkBy chunk_by;
>}
>
> +#define __cpp_lib_ranges_join_with 202202L
> +
>namespace __detail
>{
> template
> @@ -7375,6 +7386,8 @@ namespace views::__adaptor
> inline constexpr _JoinWith join_with;
>} // namespace views
>
> +#define __cpp_lib_ranges_repeat 202207L
> +
>template unreachable_sentinel_t>
> requires (is_object_v<_Tp> && same_as<_Tp, remove_cv_t<_Tp>>
>&& (__detail::__is_integer_like<_Bound> || same_as<_Bound,
> unreachable_sentinel_t>))
> @@ -7626,6 +7639,8 @@ namespace views::__adaptor
> }
>}
>
> +#define __cpp_lib_ranges_stride 202207L
> +
>template
> requires view<_Vp>
>class stride_view : public view_interface>
> @@ -7977,6 +7992,8 @@ namespace views::__adaptor
> inline constexpr _Stride stride;
>}
>
> +#define __cpp_lib_ranges_cartesian_product 202207L
> +
>namespace __detail
>{
> template
> @@ -8487,6 +8504,8 @@ namespace views::__adaptor
> inline constexpr _CartesianProduct cartesian_product;
>
Re: [PATCH] libstdc++: Add feature-test macros for implemented C++23 views [PR108260]
On Fri, 6 Jan 2023 at 15:07, Patrick Palka via Libstdc++
wrote:
>
> On Fri, 6 Jan 2023, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > PR libstdc++/108620
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/utility.h (__cpp_lib_ranges_zip): Define.
> > * include/std/ranges (__cpp_lib_ranges_zip): Define.
> > (__cpp_lib_ranges_chunk): Define.
> > (__cpp_lib_ranges_slide): Define.
> > (__cpp_lib_ranges_chunk_by): Define.
> > (__cpp_lib_ranges_join_with): Define.
> > (__cpp_lib_ranges_repeat): Define.
> > (__cpp_lib_ranges_stride): Define.
> > (__cpp_lib_ranges_cartesian_product): Define.
> > (__cpp_lib_ranges_as_rvalue): Define.
> > * include/std/version: Likewise.
> > * testsuite/20_util/tuple/p2321r2.cc: Test feature-test macro.
> > * testsuite/std/ranges/adaptors/as_rvalue/1.cc: Likewise.
> > * testsuite/std/ranges/adaptors/chunk/1.cc: Likewise.
> > * testsuite/std/ranges/adaptors/chunk_by/1.cc: Likewise.
> > * testsuite/std/ranges/adaptors/join_with/1.cc: Likewise.
> > * testsuite/std/ranges/adaptors/slide/1.cc: Likewise.
> > * testsuite/std/ranges/adaptors/stride/1.cc: Likewise.
> > * testsuite/std/ranges/cartesian_product/1.cc: Likewise.
> > * testsuite/std/ranges/repeat/1.cc: Likewise.
> > * testsuite/std/ranges/zip/1.cc: Likewise.
> > * testsuite/std/ranges/version_c++23.cc: New test.
> > ---
> > libstdc++-v3/include/bits/utility.h | 4 ++
> > libstdc++-v3/include/std/ranges | 19
> > libstdc++-v3/include/std/version | 9
> > .../testsuite/20_util/tuple/p2321r2.cc| 4 ++
> > .../std/ranges/adaptors/as_rvalue/1.cc| 4 ++
> > .../testsuite/std/ranges/adaptors/chunk/1.cc | 4 ++
> > .../std/ranges/adaptors/chunk_by/1.cc | 4 ++
> > .../std/ranges/adaptors/join_with/1.cc| 4 ++
> > .../testsuite/std/ranges/adaptors/slide/1.cc | 4 ++
> > .../testsuite/std/ranges/adaptors/stride/1.cc | 4 ++
> > .../std/ranges/cartesian_product/1.cc | 4 ++
> > libstdc++-v3/testsuite/std/ranges/repeat/1.cc | 4 ++
> > .../testsuite/std/ranges/version_c++23.cc | 44 +++
> > libstdc++-v3/testsuite/std/ranges/zip/1.cc| 4 ++
> > 14 files changed, 116 insertions(+)
> > create mode 100644 libstdc++-v3/testsuite/std/ranges/version_c++23.cc
> >
> > diff --git a/libstdc++-v3/include/bits/utility.h
> > b/libstdc++-v3/include/bits/utility.h
> > index 6a192e27836..fac6c7dc3bd 100644
> > --- a/libstdc++-v3/include/bits/utility.h
> > +++ b/libstdc++-v3/include/bits/utility.h
> > @@ -263,6 +263,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > { using type = _Tp1; };
> > #endif
> >
> > +#if __cplusplus > 202002L
> > +#define __cpp_lib_ranges_zip 202110L // for and
> > +#endif
> > +
> > _GLIBCXX_END_NAMESPACE_VERSION
> > } // namespace
> >
> > diff --git a/libstdc++-v3/include/std/ranges
> > b/libstdc++-v3/include/std/ranges
> > index ba544e116e1..dce7867e977 100644
> > --- a/libstdc++-v3/include/std/ranges
> > +++ b/libstdc++-v3/include/std/ranges
> > @@ -4364,6 +4364,9 @@ namespace views::__adaptor
> >} // namespace views
> >
> > #if __cplusplus > 202002L
> > +
> > +#define __cpp_lib_ranges_zip 202110L
> > +
> >namespace __detail
> >{
> > template
> > @@ -5802,6 +5805,8 @@ namespace views::__adaptor
> > inline constexpr auto pairwise_transform = adjacent_transform<2>;
> >}
> >
> > +#define __cpp_lib_ranges_chunk 202202L
> > +
> >namespace __detail
> >{
> > template
> > @@ -6339,6 +6344,8 @@ namespace views::__adaptor
> > inline constexpr _Chunk chunk;
> >}
> >
> > +#define __cpp_lib_ranges_slide 202202L
> > +
> >namespace __detail
> >{
> > template
> > @@ -6702,6 +6709,8 @@ namespace views::__adaptor
> > inline constexpr _Slide slide;
> >}
> >
> > +#define __cpp_lib_ranges_chunk_by 202202L
> > +
> >template > indirect_binary_predicate, iterator_t<_Vp>> _Pred>
> > requires view<_Vp> && is_object_v<_Pred>
> > @@ -6895,6 +6904,8 @@ namespace views::__adaptor
> > inline constexpr _ChunkBy chunk_by;
> >}
> >
> > +#define __cpp_lib_ranges_join_with 202202L
> > +
> >namespace __detail
> >{
> > template
> > @@ -7375,6 +7386,8 @@ namespace views::__adaptor
> > inline constexpr _JoinWith join_with;
> >} // namespace views
> >
> > +#define __cpp_lib_ranges_repeat 202207L
> > +
> >template > unreachable_sentinel_t>
> > requires (is_object_v<_Tp> && same_as<_Tp, remove_cv_t<_Tp>>
> >&& (__detail::__is_integer_like<_Bound> || same_as<_Bound,
> > unreachable_sentinel_t>))
> > @@ -7626,6 +7639,8 @@ namespace views::__adaptor
> > }
> >}
> >
> > +#define __cpp_lib_ranges_stride 202207L
> > +
> >template
> > requires view<_Vp>
> >class stride_view : public view_interface>
> >
Re: [PATCH] ipa: Sort ipa_param_body_adjustments::m_replacements (PR 108110)
Hi,
On Fri, Jan 06 2023, Martin Liška wrote:
> Hi Martin
>
>> + key.unit_offset = unit_offset;
>> + ipa_param_body_replacement *res
>> += std::lower_bound (m_replacements.begin (), m_replacements.end (), key,
>> +[] (const ipa_param_body_replacement &elt,
>> +const ipa_param_body_replacement &val)
>> +{
>> + if (DECL_UID (elt.base) < DECL_UID (val.base))
>> +return true;
>> + if (DECL_UID (elt.base) > DECL_UID (val.base))
>> +return false;
>> + if (elt.unit_offset < val.unit_offset)
>> +return true;
>> + return false;
>> +});
>
> I'm curious if we can re-use compare_param_body_replacement as the introduced
> lambda does a very similar thing, right?
>
Not directly, the qsort callback returns an integer that can be either
negative, positive or zero but the lower_bound returns only true or
false (the semantics is that it returns the first element for which it
returns false). Plus one takes parameters which are pointer and other
needs references.
So I was lazy and just came up with a similar comparator lambda. But
sure, I can call the qsort comparator from it, which I guess makes sense
at least for consistency. I'll adjust the patch.
Thanks,
Martin
Re: [PATCH] Remove legacy pre-C++ 11 definitions
On Fri, Jan 6, 2023 at 4:21 AM Martin Liška wrote: > > As mentioned in the PRs, both are defined in C++ 11 > which is a version we depend on. > > Ready to be installed now? There is another #define NULL below: /* System headers may define NULL to be an integer (e.g. 0L), which cannot be used safely in certain contexts (e.g. as sentinels). Redefine NULL to nullptr in order to make it safer. Note that this might confuse system headers, however, by convention they must not be included after this point. */ #ifdef __cplusplus #undef NULL #define NULL nullptr #endif Thanks, Andrew Pinski > > Thanks, > Martin > > PR middle-end/108311 > PR middle-end/108312 > > gcc/ChangeLog: > > * system.h (va_copy): Remove as it is defined in C++ 11. > (NULL): Likewise. > --- > gcc/system.h | 13 - > 1 file changed, 13 deletions(-) > > diff --git a/gcc/system.h b/gcc/system.h > index 5eaeb9d2d03..0d06b9749e5 100644 > --- a/gcc/system.h > +++ b/gcc/system.h > @@ -31,25 +31,12 @@ along with GCC; see the file COPYING3. If not see > /* We must include stdarg.h before stdio.h. */ > #include > > -#ifndef va_copy > -# ifdef __va_copy > -# define va_copy(d,s) __va_copy (d, s) > -# else > -# define va_copy(d,s) ((d) = (s)) > -# endif > -#endif > - > #ifdef HAVE_STDDEF_H > # include > #endif > > #include > > -/* Define a generic NULL if one hasn't already been defined. */ > -#ifndef NULL > -#define NULL 0 > -#endif > - > /* Use the unlocked open routines from libiberty. */ > > /* Some of these are #define on some systems, e.g. on AIX to redirect > -- > 2.39.0 >
libbacktrace patch committed: Only test --build-id if supported
PR 108297 points out that there are systems that use ELF but for which the linker does not support the --build-id option. This libbacktrace patch skips --build-id tests when it doesn't work. Bootstrapped and ran libbacktrace tests on x86_64-pc-linux-gnu. Committed to mainline. Ian PR libbacktrace/108297 * configure.ac: Test whether linker supports --build-id. * Makefile.am: Only run --build-id tests if supported. * configure, Makefile.in: Regenerate. diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am index 047b573c29a..1c4ac2baeb6 100644 --- a/libbacktrace/Makefile.am +++ b/libbacktrace/Makefile.am @@ -248,6 +248,7 @@ check_DATA += allocfail.dSYM endif USE_DSYMUTIL if HAVE_ELF +if HAVE_BUILDID if HAVE_OBJCOPY_DEBUGLINK b2test_SOURCES = $(btest_SOURCES) @@ -271,6 +272,7 @@ MAKETESTS += b3test_dwz_buildid endif HAVE_DWZ endif HAVE_OBJCOPY_DEBUGLINK +endif HAVE_BUILDID endif HAVE_ELF btest_SOURCES = btest.c testlib.c diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac index d0a0475cfa8..28e3a688c24 100644 --- a/libbacktrace/configure.ac +++ b/libbacktrace/configure.ac @@ -484,7 +484,18 @@ AC_CHECK_LIB([z], [compress], [AC_DEFINE(HAVE_ZLIB, 1, [Define if -lz is available.])]) AM_CONDITIONAL(HAVE_ZLIB, test "$ac_cv_lib_z_compress" = yes) -dnl Test whether the linker supports the --compress_debug_sections option. +dnl Test whether the linker supports the --build-id option. +AC_CACHE_CHECK([whether --build-id is supported], +[libbacktrace_cv_ld_buildid], +[LDFLAGS_hold=$LDFLAGS +LDFLAGS="$LDFLAGS -Wl,--build-id" +AC_LINK_IFELSE([AC_LANG_PROGRAM(,)], +[libbacktrace_cv_ld_buildid=yes], +[libbacktrace_cv_ld_buildid=no]) +LDFLAGS=$LDFLAGS_hold]) +AM_CONDITIONAL(HAVE_BUILDID, test "$libbacktrace_cv_ld_buildid" = yes) + +dnl Test whether the linker supports the --compress-debug-sections option. AC_CACHE_CHECK([whether --compress-debug-sections is supported], [libgo_cv_ld_compress], [LDFLAGS_hold=$LDFLAGS
[PATCH] Always define `WIN32_LEAN_AND_MEAN` before
This fixes bootstrap issues with current mingw-w64 headers:
```
../../gcc/gcc/system.h:791:30: error: expected identifier before string
constant
791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
| ^~~~
```
The changes in this commit were generated by the following command, with some
post-processing:
```
sed -Ei 's,^( *)#( *)include ,\1#\2define
WIN32_LEAN_AND_MEAN\n&,' \
$(grep -Flr "")
```
This has been tested with C, C++, LTO, Fortran, Objective-C, Objective-C++ and JIT, on
{i868,x86_64}-w64-mingw32; but it contains changes to Ada, libgo, libgomp and libvtv, which I don't
usually build and test.
--
Best regards,
LIU Hao
From 6600e2b135bd06b2aad77e538b47a480c8deebdd Mon Sep 17 00:00:00 2001
From: LIU Hao
Date: Fri, 6 Jan 2023 23:18:15 +0800
Subject: [PATCH] Always define `WIN32_LEAN_AND_MEAN` before
Recently, mingw-w64 has got updated from Wine which is included
indirectly by if `WIN32_LEAN_AND_MEAN` is not defined. The
`IXMLDOMDocument` class has a member function named `abort()`, which gets
affected by our `abort()` macro in "system.h".
`WIN32_LEAN_AND_MEAN` should, nevertheless, always be defined. This
can exclude 'APIs such as Cryptography, DDE, RPC, Shell, and Windows
Sockets' [1], and speed up compilation of these files a bit.
[1]
https://learn.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers
gcc/
PR middle-end/108300
* config/xtensa/xtensa-dynconfig.c: Define `WIN32_LEAN_AND_MEAN`
before .
* diagnostic-color.cc: Likewise.
* plugin.cc: Likewise.
* prefix.cc: Likewise.
gcc/ada/
PR middle-end/108300
* adaint.c: Define `WIN32_LEAN_AND_MEAN` before `#include
`.
* cio.c: Likewise.
* ctrl_c.c: Likewise.
* expect.c: Likewise.
* gsocket.h: Likewise.
* mingw32.h: Likewise.
* mkdir.c: Likewise.
* rtfinal.c: Likewise.
* rtinit.c: Likewise.
* seh_init.c: Likewise.
* sysdep.c: Likewise.
* terminals.c: Likewise.
* tracebak.c: Likewise.
gcc/jit/
PR middle-end/108300
* jit-w32.h: Define `WIN32_LEAN_AND_MEAN` before .
libatomic/
PR middle-end/108300
* config/mingw/lock.c: Define `WIN32_LEAN_AND_MEAN` before
.
libffi/
PR middle-end/108300
* src/aarch64/ffi.c: Define `WIN32_LEAN_AND_MEAN` before
.
libgcc/
PR middle-end/108300
* config/i386/enable-execute-stack-mingw32.c: Define
`WIN32_LEAN_AND_MEAN` before .
* libgcc2.c: Likewise.
* unwind-generic.h: Likewise.
libgfortran/
PR middle-end/108300
* intrinsics/sleep.c: Define `WIN32_LEAN_AND_MEAN` before
.
libgo/
PR middle-end/108300
* misc/cgo/test/callback_c.c: Define `WIN32_LEAN_AND_MEAN` before
.
libgomp/
PR middle-end/108300
* config/mingw32/proc.c: Define `WIN32_LEAN_AND_MEAN` before
.
libiberty/
PR middle-end/108300
* make-temp-file.c: Define `WIN32_LEAN_AND_MEAN` before .
* pex-win32.c: Likewise.
libssp/
PR middle-end/108300
* ssp.c: Define `WIN32_LEAN_AND_MEAN` before .
libstdc++-v3/
PR middle-end/108300
* src/c++11/system_error.cc: Define `WIN32_LEAN_AND_MEAN` before
.
* src/c++11/thread.cc: Likewise.
* src/c++17/fs_ops.cc: Likewise.
* src/filesystem/ops.cc: Likewise.
libvtv/
PR middle-end/108300
* vtv_malloc.cc: Define `WIN32_LEAN_AND_MEAN` before .
* vtv_rts.cc: Likewise.
* vtv_utils.cc: Likewise.
---
gcc/ada/adaint.c | 1 +
gcc/ada/cio.c | 1 +
gcc/ada/ctrl_c.c | 1 +
gcc/ada/expect.c | 1 +
gcc/ada/gsocket.h | 1 +
gcc/ada/mingw32.h | 1 +
gcc/ada/mkdir.c | 1 +
gcc/ada/rtfinal.c | 1 +
gcc/ada/rtinit.c | 1 +
gcc/ada/seh_init.c| 1 +
gcc/ada/sysdep.c | 2 ++
gcc/ada/terminals.c | 1 +
gcc/ada/tracebak.c| 2 ++
gcc/config/xtensa/xtensa-dynconfig.c | 1 +
gcc/diagnostic-color.cc | 1 +
gcc/jit/jit-w32.h | 1 +
gcc/plugin.cc | 1 +
gcc/prefix.cc | 1 +
libatomic/config/mingw/lock.c | 1 +
libffi/src/aarch64/ffi.c | 1 +
libgcc/config/i386/enable-execute-stack-mingw32.c | 1 +
libgcc/libgcc2.c | 1 +
libgcc/unwind-
Re: [PATCH] Always define `WIN32_LEAN_AND_MEAN` before
On Sat, Jan 07, 2023 at 02:01:05AM +0800, LIU Hao via Gcc-patches wrote: > libgomp/ > > PR middle-end/108300 > * config/mingw32/proc.c: Define `WIN32_LEAN_AND_MEAN` before > . This change is ok for trunk. Jakub
Re: [PATCH] Remove legacy pre-C++ 11 definitions
On Fri, 6 Jan 2023, 17:21 Andrew Pinski, wrote: > On Fri, Jan 6, 2023 at 4:21 AM Martin Liška wrote: > > > > As mentioned in the PRs, both are defined in C++ 11 > > which is a version we depend on. > > > > Ready to be installed now? > > There is another #define NULL below: > /* System headers may define NULL to be an integer (e.g. 0L), which cannot > be >used safely in certain contexts (e.g. as sentinels). Redefine NULL to >nullptr in order to make it safer. Note that this might confuse system >headers, however, by convention they must not be included after this > point. > */ > #ifdef __cplusplus > #undef NULL > #define NULL nullptr > #endif > Seems to me that GCC code should just use nullptr directly not redefine NULL. Thanks, > Andrew Pinski > > > > > Thanks, > > Martin > > > > PR middle-end/108311 > > PR middle-end/108312 > > > > gcc/ChangeLog: > > > > * system.h (va_copy): Remove as it is defined in C++ 11. > > (NULL): Likewise. > > --- > > gcc/system.h | 13 - > > 1 file changed, 13 deletions(-) > > > > diff --git a/gcc/system.h b/gcc/system.h > > index 5eaeb9d2d03..0d06b9749e5 100644 > > --- a/gcc/system.h > > +++ b/gcc/system.h > > @@ -31,25 +31,12 @@ along with GCC; see the file COPYING3. If not see > > /* We must include stdarg.h before stdio.h. */ > > #include > > > > -#ifndef va_copy > > -# ifdef __va_copy > > -# define va_copy(d,s) __va_copy (d, s) > > -# else > > -# define va_copy(d,s) ((d) = (s)) > > -# endif > > -#endif > > - > > #ifdef HAVE_STDDEF_H > > # include > > #endif > > > > #include > > > > -/* Define a generic NULL if one hasn't already been defined. */ > > -#ifndef NULL > > -#define NULL 0 > > -#endif > > - > > /* Use the unlocked open routines from libiberty. */ > > > > /* Some of these are #define on some systems, e.g. on AIX to redirect > > -- > > 2.39.0 > > >
[committed] c: C2x semantics for __builtin_tgmath
__builtin_tgmath implements semantics for integer generic
arguments that handle cases involving _FloatN / _FloatNx types as
specified in TS 18661-3 plus some defect fixes.
C2x has further changes to the semantics for macros with
such types, which should also be considered defect fixes (although
handled through the integration of TS 18661-3 in C2x rather than
through an issue tracking process). Specifically, the rules were
changed because of problems raised with using the macros with the
evaluation format types such as float_t and _Float32_t: the older
version of the rules didn't allow passing _FloatN / _FloatNx types to
the narrowing macros returning float or double, or passing float /
double / long double to the narrowing macros returning _FloatN /
_FloatNx, which was a problem with the evaluation format types which
could be either kind of type depending on the value of
FLT_EVAL_METHOD.
Thus the new rules allow cases of mixing types which were not allowed
before - which is not itself a problem for __builtin_tgmath - and, as
part of the changes, the handling of integer arguments was also
changed: if there is any _FloatNx generic argument, integer generic
arguments are treated as _Float32x (not double), while the rule about
treating integer arguments to narrowing macros returning _FloatN or
_FloatNx as _Float64 not double was removed (no longer needed now
double is a valid argument to such macros).
Implement the changes for __builtin_tgmath. (The changes also added a
rule that if any argument is _DecimalNx, integer arguments are treated
as _Decimal64x, but GCC doesn't support _DecimalNx types so nothing is
done about that.)
I have a corresponding glibc patch to update glibc test expectations
for C2x and also ensure that appropriate semantics are followed when
GCC 7 through 12 are used with (avoiding __builtin_tgmath
in cases where it doesn't match the C2x semantics).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/
* doc/extend.texi (__builtin_tgmath): Do not restate standard rule
for handling real integer types.
gcc/c/
* c-parser.cc (c_parser_postfix_expression): Handle integer
generic arguments to functions passed to __builtin_tgmath as
_Float32x if any argument has _FloatNx or _Complex _FloatNx type.
Do not handle integer arguments to some narrowing functions as
_Float64.
gcc/testsuite/
* gcc.dg/builtin-tgmath-3.c: Update expectations and add more
tests.
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 7d6960fffbb..3a5998007a9 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -10276,16 +10276,17 @@ c_parser_postfix_expression (c_parser *parser)
types are treated as _Decimal64 if any type-generic
argument is decimal, or if the only alternatives for
type-generic arguments are of decimal types, and are
- otherwise treated as double (or _Complex double for
- complex integer types, or _Float64 or _Complex _Float64
- if all the return types are the same _FloatN or
- _FloatNx type). After that adjustment, types are
- combined following the usual arithmetic conversions.
- If the function only accepts complex arguments, a
- complex type is produced. */
+ otherwise treated as _Float32x (or _Complex _Float32x
+ for complex integer types) if any type-generic argument
+ has _FloatNx type, otherwise as double (or _Complex
+ double for complex integer types). After that
+ adjustment, types are combined following the usual
+ arithmetic conversions. If the function only accepts
+ complex arguments, a complex type is produced. */
bool arg_complex = all_complex;
bool arg_binary = all_binary;
bool arg_int_decimal = all_decimal;
+ bool arg_int_floatnx = false;
for (unsigned int j = 1; j <= nargs; j++)
{
if (parm_kind[j] == tgmath_fixed)
@@ -10380,20 +10381,17 @@ c_parser_postfix_expression (c_parser *parser)
goto out;
}
}
+ tree rtype = TYPE_MAIN_VARIANT (type);
+ if (TREE_CODE (rtype) == COMPLEX_TYPE)
+ rtype = TREE_TYPE (rtype);
+ if (SCALAR_FLOAT_TYPE_P (rtype))
+ for (unsigned int j = 0; j < NUM_FLOATNX_TYPES; j++)
+ if (rtype == FLOATNX_TYPE_NODE (j))
+ {
+ arg_int_floatnx = true;
+ break;
+ }
}
- /* For a macro rounding its result to a narrower type, map
- integer types to _Float64 not double if the return type
- is a _FloatN or _FloatNx type. */
- bool arg_int_float64 = false;
- if (pa
[committed] libstdc++: Refactor time_zone::_Impl::rules_counter [PR108235]
Tested x86_64-linux and powerpc-aix. Pushed to trunk.
-- >8 --
Abstract the atomic counter used to synchronize access to time_zone
infos behind a Lockable class API, and use atomic_signed_lock_free
instead of atomic, as that should be the most efficient
type. (For futex-supporting targets it makes no difference, but might
benefit other targets in future.)
The new API allows the calling code to be simpler, without needing to
repeat the same error prone preprocessor conditions in multiple places.
It also allows using template metaprogramming to decide whether to use
the atomic or a mutex, which gives us more flexibility than only using
preprocessor conditions. That allows us to choose the mutex
implementation for targets such as hppa-hp-hpux11.11 where 32-bit
atomics are not lock-free and so would introduce an unwanted dependency
on libatomic.
libstdc++-v3/ChangeLog:
PR libstdc++/108235
* src/c++20/tzdb.cc (time_zone::_Impl::RulesCounter): New class
template and partial specialization for synchronizing access to
time_zone::_Impl::infos.
(time_zone::_M_get_sys_info, reload_tzdb): Adjust uses of
rules_counter.
---
libstdc++-v3/src/c++20/tzdb.cc | 137 -
1 file changed, 84 insertions(+), 53 deletions(-)
diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index 9103b159400..fa4f4c7a30c 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -29,7 +29,7 @@
#include // ifstream
#include // istringstream
#include // ranges::upper_bound, ranges::lower_bound, ranges::sort
-#include // atomic, atomic
+#include // atomic, atomic
#include // atomic>
#include // mutex
#include // filesystem::read_symlink
@@ -598,13 +598,86 @@ namespace std::chrono
// Needed to access the list of rules for the time zones.
weak_ptr node;
-#ifndef __GTHREADS
-// Don't need synchronization for accessing the infos vector.
-#elif __cpp_lib_atomic_wait
-atomic rules_counter;
-#else
-mutex infos_mutex;
+// In the simple case, we don't actual keep count. No concurrent access
+// to the infos vector is possible, even if all infos are expanded.
+template
+ struct RulesCounter
+ {
+ // Called for each rule-based ZoneInfo added to the infos vector.
+ // Called when the time_zone::_Impl is created, so no concurrent calls.
+ void increment() { }
+ // Called when a rule-based ZoneInfo is expanded.
+ // The caller must have called lock() for exclusive access to infos.
+ void decrement() { }
+
+ // Use a mutex to synchronize all access to the infos vector.
+ mutex infos_mutex;
+
+ void lock() { infos_mutex.lock(); }
+ void unlock() { infos_mutex.unlock(); }
+ };
+
+#if defined __GTHREADS && __cpp_lib_atomic_wait
+// Atomic count of unexpanded ZoneInfo objects in the infos vector.
+// Concurrent access is allowed when all objects have been expanded.
+// Only use an atomic counter if it would not require libatomic,
+// because we don't want libstdc++.so to depend on libatomic.
+template requires _Tp::is_always_lock_free
+ struct RulesCounter<_Tp>
+ {
+ atomic_signed_lock_free counter{0};
+
+ void
+ increment()
+ { counter.fetch_add(1, memory_order::relaxed); }
+
+ void
+ decrement()
+ {
+ // The current thread holds the lock, so the counter is negative
+ // and so we need to increment it to decrement it!
+ // If the count reaches zero then there are no more unexpanded infos,
+ // so notify all waiting threads that they can access the infos.
+ // We must do this here, because unlock() is a no-op if counter==0.
+ if (++counter == 0)
+ counter.notify_all();
+ }
+
+ void
+ lock()
+ {
+ // If counter is zero then concurrent access is allowed, so lock()
+ // and unlock() are no-ops and multiple threads can "lock" at once.
+ // If counter is non-zero then the contents of the infos vector might
+ // need to be changed, so only one thread is allowed to access it.
+ for (auto c = counter.load(memory_order::relaxed); c != 0;)
+ {
+ // Setting counter to negative means this thread has the lock.
+ if (c > 0 && counter.compare_exchange_strong(c, -c))
+ return;
+
+ if (c < 0)
+ {
+ // Counter is negative, another thread already has the lock.
+ counter.wait(c);
+ c = counter.load();
+ }
+ }
+ }
+
+ void
+ unlock()
+ {
+ if (auto c = counter.load(memory_order::relaxed); c < 0)
+ {
+ counter.store(-c, memory_order::release);
+ counter.notify_one();
+ }
+ }
+ };
#endif
+
+Rule
[committed] libstdc++: Suppress -Waddress warning in tzdb.cc [PR108228]
Tested x86_64-linux and powerpc-aix. Pushed to trunk.
-- >8 --
For some tarets the weak symbol is always defined, so we get a warning
that its address is never null. The warning isn't useful in this case,
so suppress it.
libstdc++-v3/ChangeLog:
PR libstdc++/108228
* src/c++20/tzdb.cc (zoneinfo_dir): Add diagnostic pragma.
---
libstdc++-v3/src/c++20/tzdb.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libstdc++-v3/src/c++20/tzdb.cc b/libstdc++-v3/src/c++20/tzdb.cc
index fa4f4c7a30c..7227fe7cfe6 100644
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -1013,9 +1013,12 @@ namespace std::chrono
string
zoneinfo_dir()
{
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Waddress"
static const string dir = __gnu_cxx::zoneinfo_dir_override
? __gnu_cxx::zoneinfo_dir_override()
: _GLIBCXX_ZONEINFO_DIR;
+#pragma GCC diagnostic pop
return dir;
}
--
2.39.0
[PATCH, modula2] PR-108182 gm2 driver mishandles target and multilib options
Hi,
here are some patches which attempt to allow target specific include
paths and library paths in the gm2 driver. I admit that the patch has
flaws in that it only processes options -f, -m in the lang_specific_driver.
[Called after driver::set_up_specs but before read_specs is called].
I suspect a better implementation might include a language callback
(lang_post_spec) which could fixup target related paths.
Nevertheless as a stage3 bugfix (workaround) they are presented below:
I wonder if they would be suitable for master?
Tested on Darwin (prior cleanup) and X86_64 Linux
regards,
Gaius
- o< - o< - o< - o< - o< - o< - o< - o<
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index d629ca5e424..362a6a96b63 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -3849,7 +3849,7 @@ alloc_switch (void)
/* Save an option OPT with N_ARGS arguments in array ARGS, marking it
as validated if VALIDATED and KNOWN if it is an internal switch. */
-static void
+void
save_switch (const char *opt, size_t n_args, const char *const *args,
bool validated, bool known)
{
@@ -9559,6 +9559,24 @@ default_arg (const char *p, int len)
return 0;
}
+/* Return the value of multilib_dir. */
+
+const char *
+get_multilib_dir (void)
+{
+ set_multilib_dir ();
+ return multilib_dir;
+}
+
+/* Reset the mdswitches array to empty. */
+
+void
+reset_mdswitches (void)
+{
+ n_mdswitches = 0;
+ mdswitches = NULL;
+}
+
/* Work out the subdirectory to use based on the options. The format of
multilib_select is a list of elements. Each element is a subdirectory
name followed by a list of options followed by a semicolon. The format
diff --git a/gcc/gcc.h b/gcc/gcc.h
index 19a61b373ee..03646ff2d87 100644
--- a/gcc/gcc.h
+++ b/gcc/gcc.h
@@ -73,6 +73,11 @@ struct spec_function
extern int do_spec (const char *);
extern void record_temp_file (const char *, int, int);
extern void set_input (const char *);
+extern const char *get_multilib_dir (void);
+extern void reset_mdswitches (void);
+extern void save_switch (const char *opt, size_t n_args,
+const char *const *args,
+bool validated, bool known);
/* Spec files linked with gcc.cc must provide definitions for these. */
diff --git a/gcc/m2/gm2spec.cc b/gcc/m2/gm2spec.cc
index 583723da416..dbfd1ca 100644
--- a/gcc/m2/gm2spec.cc
+++ b/gcc/m2/gm2spec.cc
@@ -797,8 +797,14 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
if ((decoded_options[i].orig_option_with_args_text != NULL)
&& (strncmp (decoded_options[i].orig_option_with_args_text,
"-m", 2) == 0))
- multilib_dir = xstrdup
(decoded_options[i].orig_option_with_args_text
- + 2);
+ save_switch (decoded_options[i].orig_option_with_args_text,
+0, NULL, true, true);
+ else if ((decoded_options[i].orig_option_with_args_text != NULL)
+ && (strncmp (decoded_options[i].orig_option_with_args_text,
+ "-f", 2) == 0))
+ save_switch (decoded_options[i].orig_option_with_args_text,
+ 0, NULL, true, true);
+ break;
}
}
if (language != NULL && (strcmp (language, "modula-2") != 0))
@@ -864,10 +870,13 @@ lang_specific_driver (struct cl_decoded_option
**in_decoded_options,
if ((! (seen_uselist || seen_gen_module_list)) && linking)
append_option (OPT_fgen_module_list_, "-", 1);
+ multilib_dir = get_multilib_dir ();
+ reset_mdswitches ();
if (allow_libraries)
{
/* If the libraries have not been specified by the user but the
-dialect has been specified then select the appropriate libraries. */
+dialect has been specified then select the appropriate
+libraries. */
if (libraries == NULL)
{
if (strcmp (dialect, "iso") == 0)
[PATCH, modula2] PR-108182 gm2 driver mishandles target and multilib options
ChangeLog entry follows: regards, Gaius [PATCH, modula2] PR-108182 gm2 driver mishandles target and multilib options here are some patches which attempt to allow target specific include paths and library paths in the gm2 driver. I admit that the patch has flaws in that it only processes options -f, -m in the lang_specific_driver. [Called after driver::set_up_specs but before read_specs is called]. I suspect a better implementation might include a language callback (lang_post_spec) which could fixup target related paths. gcc/ChangeLog: * gcc.cc (save_switch): Remove static declaration. (get_multilib_dir): New function. (reset_mdswitches): New function. * gcc/gcc.h (save_switch): Declare extern. (get_multilib_dir): New extern. (reset_mdswitches): New extern. gcc/m2/ChangeLog: * gm2spec.cc (lang_specific_driver): Detect -m and -f options and call save_switch. Assign multilib_dir with the result of get_multilib_dir. Call reset_mdswitches afterwards.
Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
On Wed, Dec 21, 2022 at 09:40:24PM +, Joseph Myers wrote: > On Wed, 21 Dec 2022, Segher Boessenkool wrote: > > > > --- a/gcc/tree.cc > > > +++ b/gcc/tree.cc > > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char) > > >if (!targetm.floatn_mode (n, extended).exists (&mode)) > > > continue; > > >int precision = GET_MODE_PRECISION (mode); > > > - /* Work around the rs6000 KFmode having precision 113 not > > > - 128. */ > > > > It has precision 126 now fwiw. > > > > Joseph: what do you think about this patch? Is the workaround it > > removes still useful in any way, do we need to do that some other way if > > we remove this? > > I think it's best for the TYPE_PRECISION, for any type with the binary128 > format, to be 128 (not 126). > > It's necessary that _Float128, _Float64x and long double all have the same > TYPE_PRECISION when they have the same (binary128) format, or at least > that TYPE_PRECISION for _Float128 >= that for long double >= that for > _Float64x, so that the rules in c_common_type apply properly. > > How the TYPE_PRECISION compares to that of __ibm128, or of long double > when that's double-double, is less important. I spent a few days on working on this. I have patches to make the 3 128-bit types to all have TYPE_PRECISION of 128. To do this, I added a new mode macro (FRACTIONAL_FLOAT_MODE_NO_WIDEN) that takes the same arguments as FRACTIONAL_FLOAT_MODE. This will create a floating point mode that is a normal floating point mode, but the GET_MODE_WIDER and GET_MODE_2XWIDER macros will never return it. By declaring both IFmode and KFmode to not be widened to, but noral TFmode is, it eliminates the problems where an IBM expression got converted to IEEE, which can mostly (but not always) contain the value. In addition, on power8, it means it won't call the KF mode emulator functions, just the IF functions. We need to have one 128-bit mode (TFmode) that is not declared as NO_WARN, or long double won't be created, since float_mode_for_size (128) will not be able to find the correct type. I did have to patch convert_mode_scalar so that it would not abort if it was doing a conversion between two floating point types with the same precision. I tested this with the first patch from the previous set of patches (that rewrites complex multiply/divide built-in setup). I think that patch is useful as a stand alone patch. I also used Kewen Lin's patch from December 27th in build_common_tree_nodes to do the test. I haven't tested if this particular patch fixes this problem, or it fixes something else. Finally, I used the third patch in my series of patches that straightens out 128<->128 FP conversions. That patch needed to be tweaked slightly, as one of the conversations became FLOAT_EXTEND instead of FLOAT_TRUNCATE. We don't have a RTL operation that says convert from one floating point type to another where both types are the same size. Whether FLOAT_EXTEND is used or FLOAT_TRUNCATE, used to depend on whether the TYPE_PRECISION was greater or lesser. Now that they are the same, it arbitrarily picks FLOAT_EXTEND. While I still think the 2nd patch is important, it isn't needed with the above patches. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: [PATCH] xtensa: Optimize stack frame adjustment more
On 2023/01/06 17:05, Max Filippov wrote: > On Thu, Jan 5, 2023 at 10:57 PM Takayuki 'January June' Suwa > wrote: >> By using the helper function, it makes stack frame adjustment logic >> simplified and instruction count less in some cases. > > I've built a couple linux configurations with and without this change and > I observe consistent code size growth, e.g.: > > iss_defconfig without the change: > textdata bss dec hex filename > 3014768 164016 115108 3293892 3242c4 vmlinux > > iss_defconfig with the change: > textdata bss dec hex filename > 3015296 164008 115108 3294412 3244cc vmlinux > > virt_defconfig without the change: > textdata bss dec hex filename > 5498881 2254360 291768 8045009 7ac1d1 vmlinux > > virt_defconfig with the change: > textdata bss dec hex filename > 5500389 2254360 291768 8046517 7ac7b5 vmlinux > > generic_kc705_defconfig without the change: > textdata bss dec hex filename > 7062530 635340 286400 7984270 79d48e vmlinux > > generic_kc705_defconfig with the change: > textdata bss dec hex filename > 7064078 635340 286400 7985818 79da9a vmlinux > Probably due to this location: > + else if (TARGET_DENSITY && optimize_size && xtensa_simm12b (imm)) I omitted it in the new patch, so please check it.
[PATCH v2] xtensa: Optimize stack frame adjustment more
This patch introduces a convenient helper function for integer immediate
addition with scratch register as needed, that splits and emits either
up to two ADDI/ADDMI machine instructions or an addition by register
following an integer immediate load (which may later be transformed by
constantsynth).
By using the helper function, it makes stack frame adjustment logic
simplified and instruction count less in some cases.
gcc/ChangeLog:
* config/xtensa/xtensa.cc
(xtensa_split_imm_two_addends, xtensa_emit_add_imm):
New helper functions.
(xtensa_set_return_address, xtensa_output_mi_thunk):
Change to use the helper function.
(xtensa_emit_adjust_stack_ptr): Ditto.
And also change to try reusing the content of scratch register
A9 if the register is not modified in the function body.
---
gcc/config/xtensa/xtensa.cc | 151 +---
1 file changed, 106 insertions(+), 45 deletions(-)
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index ae44199bc98..a1f184950ae 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -104,6 +104,7 @@ struct GTY(()) machine_function
bool frame_laid_out;
bool epilogue_done;
bool inhibit_logues_a1_adjusts;
+ rtx last_logues_a9_content;
};
/* Vector, indexed by hard register number, which contains 1 for a
@@ -2518,6 +2519,86 @@ xtensa_split_DI_reg_imm (rtx *operands)
}
+/* Try to split an integer value into what are suitable for two consecutive
+ immediate addition instructions, ADDI or ADDMI. */
+
+static bool
+xtensa_split_imm_two_addends (HOST_WIDE_INT imm, HOST_WIDE_INT v[2])
+{
+ HOST_WIDE_INT v0, v1;
+
+ if (imm < -32768)
+v0 = -32768, v1 = imm + 32768;
+ else if (imm > 32512)
+v0 = 32512, v1 = imm - 32512;
+ else if (TARGET_DENSITY && xtensa_simm12b (imm))
+/* A pair of MOVI(.N) and ADD.N is one or two bytes less than two
+ immediate additions if TARGET_DENSITY. */
+return false;
+ else
+v0 = (imm + 128) & ~255L, v1 = imm - v0;
+
+ if (xtensa_simm8 (v1) || xtensa_simm8x256 (v1))
+{
+ v[0] = v0, v[1] = v1;
+ return true;
+}
+
+ return false;
+}
+
+
+/* Helper function for integer immediate addition with scratch register
+ as needed, that splits and emits either up to two ADDI/ADDMI machine
+ instructions or an addition by register following an integer immediate
+ load (which may later be transformed by constantsynth).
+
+ If 'scratch' is NULL_RTX but still needed, a new pseudo-register will
+ be allocated. Thus, after the reload/LRA pass, the specified scratch
+ register must be a hard one. */
+
+static bool
+xtensa_emit_add_imm (rtx dst, rtx src, HOST_WIDE_INT imm, rtx scratch,
+bool need_note)
+{
+ bool retval = false;
+ HOST_WIDE_INT v[2];
+ rtx_insn *insn;
+
+ if (imm == 0)
+return false;
+
+ if (xtensa_simm8 (imm) || xtensa_simm8x256 (imm))
+insn = emit_insn (gen_addsi3 (dst, src, GEN_INT (imm)));
+ else if (xtensa_split_imm_two_addends (imm, v))
+{
+ if (!scratch)
+ scratch = gen_reg_rtx (SImode);
+ emit_insn (gen_addsi3 (scratch, src, GEN_INT (v[0])));
+ insn = emit_insn (gen_addsi3 (dst, scratch, GEN_INT (v[1])));
+}
+ else
+{
+ if (scratch)
+ emit_move_insn (scratch, GEN_INT (imm));
+ else
+ scratch = force_reg (SImode, GEN_INT (imm));
+ retval = true;
+ insn = emit_insn (gen_addsi3 (dst, src, scratch));
+}
+
+ if (need_note)
+{
+ rtx note_rtx = gen_rtx_SET (dst, plus_constant (Pmode, src, imm));
+
+ RTX_FRAME_RELATED_P (insn) = 1;
+ add_reg_note (insn, REG_FRAME_RELATED_EXPR, note_rtx);
+}
+
+ return retval;
+}
+
+
/* Implement TARGET_CANNOT_FORCE_CONST_MEM. */
static bool
@@ -3245,41 +3326,33 @@ xtensa_initial_elimination_offset (int from, int to
ATTRIBUTE_UNUSED)
static void
xtensa_emit_adjust_stack_ptr (HOST_WIDE_INT offset, int flags)
{
+ rtx src, scratch;
rtx_insn *insn;
- rtx ptr = (flags & ADJUST_SP_FRAME_PTR) ? hard_frame_pointer_rtx
- : stack_pointer_rtx;
if (cfun->machine->inhibit_logues_a1_adjusts)
return;
- if (xtensa_simm8 (offset)
- || xtensa_simm8x256 (offset))
-insn = emit_insn (gen_addsi3 (stack_pointer_rtx, ptr, GEN_INT (offset)));
- else
-{
- rtx tmp_reg = gen_rtx_REG (Pmode, A9_REG);
+ src = (flags & ADJUST_SP_FRAME_PTR)
+? hard_frame_pointer_rtx : stack_pointer_rtx;
+ scratch = gen_rtx_REG (Pmode, A9_REG);
- if (offset < 0)
- {
- emit_move_insn (tmp_reg, GEN_INT (-offset));
- insn = emit_insn (gen_subsi3 (stack_pointer_rtx, ptr, tmp_reg));
- }
- else
- {
- emit_move_insn (tmp_reg, GEN_INT (offset));
- insn = emit_insn (gen_addsi3 (stack_pointer_rtx, ptr, tmp_reg));
- }
-}
-
- if (flags & ADJUST_SP_NEED_NOTE)
+ if (df && DF_REG_DEF_COUNT
[PATCH] xtensa: Optimize bitwise splicing operation
This patch optimizes the operation of cutting and splicing two register
values at a specified bit position, in other words, combining (bitwise
ORing) bits 0 through (C-1) of the register with bits C through 31
of the other, where C is the specified immediate integer 1 through 31.
This typically applies to signedness copy of floating point number or
__builtin_return_address() if the windowed register ABI, and saves one
instruction compared to four shifts and a bitwise OR by the RTL
generation pass.
gcc/ChangeLog:
* config/xtensa/xtensa.md (*splice_bits):
New insn_and_split pattern.
---
gcc/config/xtensa/xtensa.md | 47 +
1 file changed, 47 insertions(+)
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index 0a26d3dccf4..36ec1b1918e 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -746,6 +746,53 @@
(set_attr "mode""SI")
(set_attr "length" "3")])
+(define_insn_and_split "*splice_bits"
+ [(set (match_operand:SI 0 "register_operand" "=a")
+ (ior:SI (and:SI (match_operand:SI 1 "register_operand" "r")
+ (match_operand:SI 3 "const_int_operand" "i"))
+ (and:SI (match_operand:SI 2 "register_operand" "r")
+ (match_operand:SI 4 "const_int_operand" "i"]
+
+ "!optimize_debug && optimize
+ && INTVAL (operands[3]) + INTVAL (operands[4]) == -1
+ && (exact_log2 (INTVAL (operands[3]) + 1) > 0
+ || exact_log2 (INTVAL (operands[4]) + 1) > 0)"
+ "#"
+ "&& can_create_pseudo_p ()"
+ [(set (match_dup 5)
+ (ashift:SI (match_dup 1)
+ (match_dup 4)))
+ (set (match_dup 6)
+ (lshiftrt:SI (match_dup 2)
+(match_dup 3)))
+ (set (match_dup 0)
+ (ior:SI (lshiftrt:SI (match_dup 5)
+(match_dup 4))
+ (ashift:SI (match_dup 6)
+ (match_dup 3]
+{
+ int shift;
+ if (INTVAL (operands[3]) < 0)
+{
+ rtx x;
+ x = operands[1], operands[1] = operands[2], operands[2] = x;
+ x = operands[3], operands[3] = operands[4], operands[4] = x;
+}
+ shift = floor_log2 (INTVAL (operands[3]) + 1);
+ operands[3] = GEN_INT (shift);
+ operands[4] = GEN_INT (32 - shift);
+ operands[5] = gen_reg_rtx (SImode);
+ operands[6] = gen_reg_rtx (SImode);
+}
+ [(set_attr "type""arith")
+ (set_attr "mode""SI")
+ (set (attr "length")
+ (if_then_else (match_test "TARGET_DENSITY
+ && (INTVAL (operands[3]) == 0x7FFF
+ || INTVAL (operands[4]) == 0x7FFF)")
+ (const_int 11)
+ (const_int 12)))])
+
;; Zero-extend instructions.
--
2.30.2
Re: [PATCH] Always define `WIN32_LEAN_AND_MEAN` before
On 1/6/23 18:10, Jakub Jelinek wrote: On Sat, Jan 07, 2023 at 02:01:05AM +0800, LIU Hao via Gcc-patches wrote: libgomp/ PR middle-end/108300 * config/mingw32/proc.c: Define `WIN32_LEAN_AND_MEAN` before . This change is ok for trunk. Jakub Pushed to master branch, thanks LH.
