[PATCH] s390: avoid peeking eof after __vector
Hi,
Same like PR101168, this patch is need for s390 to
avoid peeking eof after vector keyword.
And similar test case is also ok for s390.
Is this ok for trunk?
Jeff (Jiufu Guo)
PR target/95782
gcc/ChangeLog:
* config/s390/s390-c.cc (s390_macro_to_expand): Avoid empty identifier.
gcc/testsuite/ChangeLog:
* g++.target/s390/pr95782.C: New test.
---
gcc/config/s390/s390-c.cc | 4 +++-
gcc/testsuite/g++.target/s390/pr95782.C | 5 +
2 files changed, 8 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.target/s390/pr95782.C
diff --git a/gcc/config/s390/s390-c.cc b/gcc/config/s390/s390-c.cc
index 8d3d1a467a8..45f164d978b 100644
--- a/gcc/config/s390/s390-c.cc
+++ b/gcc/config/s390/s390-c.cc
@@ -275,7 +275,9 @@ s390_macro_to_expand (cpp_reader *pfile, const cpp_token
*tok)
/* __vector long __bool a; */
if (ident == C_CPP_HASHNODE (__bool_keyword))
expand_bool_p = true;
- else
+
+ /* If there are more tokens to check. */
+ else if (ident)
{
/* Triggered with: __vector long long __bool a; */
do
diff --git a/gcc/testsuite/g++.target/s390/pr95782.C
b/gcc/testsuite/g++.target/s390/pr95782.C
new file mode 100644
index 000..daf887fc6fe
--- /dev/null
+++ b/gcc/testsuite/g++.target/s390/pr95782.C
@@ -0,0 +1,5 @@
+// { dg-do compile }
+// { dg-options "-march=z14 -mzvector" }
+
+using vdbl = __vector double;
+#define BREAK 1
--
2.25.1
[PATCH v1] RISC-V: Allow RVV intrinsic for more function target
From: Pan Li
In previous, we allowed the target(("arch=+v")) for a function with
rv64gc build. This patch would like to support more arch options as
below:
* zve32x
* zve32f
* zve64x
* zve64f
* zve64d
* zvfhmin
* zvfh
For example, we have sample code as below.
vfloat32m1_t
__attribute__((target("arch=+zve64f")))
test_9 (vfloat32m1_t a, vfloat32m1_t b, size_t vl)
{
return __riscv_vfadd_vv_f32m1 (a, b, vl);
}
It will generate the asm code when build with -O3 -march=rv64gc
test_9:
vsetvli zero,a0,e32,m1,ta,ma
vfadd.vvv8,v8,v9
ret
Meanwhile, this patch introduces more error handling for the target
attribute. Take arch=+zve32x with vfloat32m1_t will have error message
"'vfloat32m1_t' requires the zve32f, zve64f or zve64d ISA extension".
And take arch=+zve32f with vfloat16m1_t will have error message
"'vfloat16m1_t' requires the zvfhmin or zvfh ISA extension".
Below test are passed for this patch:
* The riscv fully regression test.
gcc/ChangeLog:
* config/riscv/riscv-c.cc (riscv_pragma_intrinsic): Add INT and
FP vector element flags, invoke override option and mode adjust.
* config/riscv/riscv-protos.h (riscv_option_override): New extern
func decl.
* config/riscv/riscv-vector-builtins.cc (expand_builtin): Return
target rtx after error_at.
* config/riscv/riscv.cc (riscv_vector_int_type_p): New predicate
func to tell one tree type is integer or not.
(riscv_vector_float_type_p): New predicate func to tell one tree
type is float or not.
(riscv_vector_element_bitsize): New func to get the element bitsize
of a vector tree type.
(riscv_validate_vector_type): New func to validate the tree type
is valid on flags.
(riscv_return_value_is_vector_type_p): Leverage the func
riscv_validate_vector_type to do the tree type validation.
(riscv_arguments_is_vector_type_p): Diito.
(riscv_override_options_internal): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-10.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-11.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-12.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-13.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-14.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-15.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-16.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-17.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-18.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-19.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-20.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-21.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-22.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-23.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-24.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-25.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-26.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-27.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-28.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-29.c: New
test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-9.c: New
test.
Signed-off-by: Pan Li
---
gcc/config/riscv/riscv-c.cc | 30 +-
gcc/config/riscv/riscv-protos.h | 1 +
gcc/config/riscv/riscv-vector-builtins.cc | 7 +-
gcc/config/riscv/riscv.cc | 101 --
.../target_attribute_v_with_intrinsic-10.c| 12 +++
.../target_attribute_v_with_intrinsic-11.c| 26 +
.../target_attribute_v_with_intrinsic-12.c| 33 ++
.../target_attribute_v_with_intrinsic-13.c| 33 ++
.../target_attribute_v_with_intrinsic-14.c| 40 +++
.../target_attribute_v_with_intrinsic-15.c| 47
.../target_attribute_v_with_intrinsic-16.c| 12 +++
.../target_attribute_v_with_intrinsic-17.c| 13 +++
.../target_attribute_v_with_intrinsic-18.c| 13 +++
.../target_attribute_v_with_intrinsic-19.c| 13 +++
.../target_attribute_v_with_intrinsic-20.c| 13 +++
.../target_attribute_v_with_intrinsic-21.c| 13 +++
.../target_attribute_v_with_intrinsic-22.c| 13 +++
.../target_attribute_v_with_intrinsic-23.c| 13 +++
.../target_attribute_v_with_intrinsic-24.c
Re: [PATCH] LoongArch: Increase division costs
在 2024/3/26 下午5:48, Xi Ruoyao 写道:
The latency of LA464 and LA664 division instructions depends on the
input. When I updated the costs in r14-6642, I unintentionally set the
division costs to the best-case latency (when the first operand is 0).
Per a recent discussion [1] we should use "something sensible" instead
of it.
Use the average of the minimum and maximum latency observed instead.
This enables multiplication to reciprocal sequence reduction and speeds
up the following test case for about 30%:
int
main (void)
{
unsigned long stat = 0xdeadbeef;
for (int i = 0; i < 1; i++)
stat = (stat * stat + stat * 114514 + 1919810) % 17;
asm(""::"r"(stat));
}
[1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648348.html
The test case div-const-reduction.c is modified to assemble the instruction
sequence as follows:
lu12i.w $r12,97440>>12# 0x3b9ac000
ori $r12,$r12,2567
mod.w $r13,$r13,$r12
This sequence of instructions takes 5 clock cycles.
The sequence of instructions after adding the patch is:
lu12i.w $r15,1152917504>>12 # 0x44b82000
ori $r15,$r15,3993
mulh.w $r12,$r16,$r15
srai.w $r14,$r16,31
lu12i.w $r13,97440>>12# 0x3b9ac000
ori $r13,$r13,2567
srai.w $r12,$r12,28
sub.w $r12,$r12,$r14
mul.w $r12,$r12,$r13
sub.w $r16,$r16,$r12
This sequence of instructions takes 11 clock cycles.
This test case is optimized and takes 6 more clock cycles than before
optimization,
so I need to run the spec.
Thanks!
gcc/ChangeLog:
* config/loongarch/loongarch-def.cc
(loongarch_rtx_cost_data::loongarch_rtx_cost_data): Increase
default division cost to the average of the best case and worst
case senarios observed.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/div-const-reduction.c: New test.
---
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
gcc/config/loongarch/loongarch-def.cc| 8
gcc/testsuite/gcc.target/loongarch/div-const-reduction.c | 9 +
2 files changed, 13 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
diff --git a/gcc/config/loongarch/loongarch-def.cc
b/gcc/config/loongarch/loongarch-def.cc
index e8c129ce643..93e72a520d5 100644
--- a/gcc/config/loongarch/loongarch-def.cc
+++ b/gcc/config/loongarch/loongarch-def.cc
@@ -95,12 +95,12 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data ()
: fp_add (COSTS_N_INSNS (5)),
fp_mult_sf (COSTS_N_INSNS (5)),
fp_mult_df (COSTS_N_INSNS (5)),
-fp_div_sf (COSTS_N_INSNS (8)),
-fp_div_df (COSTS_N_INSNS (8)),
+fp_div_sf (COSTS_N_INSNS (12)),
+fp_div_df (COSTS_N_INSNS (15)),
int_mult_si (COSTS_N_INSNS (4)),
int_mult_di (COSTS_N_INSNS (4)),
-int_div_si (COSTS_N_INSNS (5)),
-int_div_di (COSTS_N_INSNS (5)),
+int_div_si (COSTS_N_INSNS (14)),
+int_div_di (COSTS_N_INSNS (22)),
movcf2gr (COSTS_N_INSNS (7)),
movgr2cf (COSTS_N_INSNS (15)),
branch_cost (6),
diff --git a/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
new file mode 100644
index 000..0ee86410dd7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mtune=la464" } */
+/* { dg-final { scan-assembler-not "div\.\[dw\]" } } */
+
+int
+test (int a)
+{
+ return a % 17;
+}
Re: [PATCH] lto: Don't assume a posix shell is usable on windows [PR110710]
26 Mar 2024 10:36:45 pm Peter Damianov :
lto-wrapper generates Makefiles that use the following:
touch -r file file.tmp && mv file.tmp file
to truncate files.
If there is no suitable "touch" or "mv" available, then this errors
with
"The system cannot find the file specified".
The solution here is to check if sh -c true works, before trying to use
it in
the Makefile. If it doesn't, then fall back to "copy /y nul file"
instead.
The fallback doesn't work exactly the same (the modified time of the
file gets
updated), but this doesn't seem to matter in practice.
I tested this both in environments both with and without sh present,
and
observed no issues.
Signed-off-by: Peter Damianov
---
gcc/lto-wrapper.cc | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
index 5186d040ce0..8dee0aaa2d8 100644
--- a/gcc/lto-wrapper.cc
+++ b/gcc/lto-wrapper.cc
@@ -1389,6 +1389,27 @@ make_exists (void)
return errmsg == NULL && exit_status == 0 && err == 0;
}
+/* Test that an sh command is present and working, return true if so.
+ This is only relevant for windows hosts, where a /bin/sh shell
cannot
+ be assumed to exist. */
+
+static bool
+sh_exists (void)
+{
+ const char *sh = "sh";
+ const char *sh_args[] = {sh, "-c", "true", NULL};
+#ifdef _WIN32
+ int exit_status = 0;
+ int err = 0;
+ const char *errmsg
+ = pex_one (PEX_SEARCH, sh_args[0], CONST_CAST (char **, sh_args),
+ "sh", NULL, NULL, &exit_status, &err);
+ return errmsg == NULL && exit_status == 0 && err == 0;
+#else
+ return true;
+#endif
+}
+
/* Execute gcc. ARGC is the number of arguments. ARGV contains the
arguments. */
static void
@@ -1402,6 +1423,7 @@ run_gcc (unsigned argc, char *argv[])
const char *collect_gcc;
char *collect_gcc_options;
int parallel = 0;
+ bool have_sh = sh_exists ();
int jobserver = 0;
bool jobserver_requested = false;
int auto_parallel = 0;
@@ -2016,6 +2038,7 @@ cont:
argv_ptr[5] = NULL;
if (parallel)
{
+ fprintf (mstream, "SHELL=%s\n", have_sh ? "sh" : "cmd");
fprintf (mstream, "%s:\n\t@%s ", output_name, new_argv[0]);
for (j = 1; new_argv[j] != NULL; ++j)
fprintf (mstream, " '%s'", new_argv[j]);
@@ -2024,9 +2047,15 @@ cont:
truncate them as soon as we have processed it. This
reduces temporary disk-space usage. */
if (! save_temps)
- fprintf (mstream, "\t@-touch -r \"%s\" \"%s.tem\" > /dev/null "
- "2>&1 && mv \"%s.tem\" \"%s\"\n",
- input_name, input_name, input_name, input_name);
+ {
+ fprintf (mstream,
+ have_sh
+ ? "\t@-touch -r \"%s\" \"%s.tem\" > /dev/null "
+ "2>&1 && mv \"%s.tem\" \"%s\"\n"
+ : "\t@-copy /y nul \"%s\" > NUL "
+ "2>&1\n",
+ input_name, input_name, input_name, input_name);
+ }
}
else
{
--
2.39.2
I made this patch against gcc 13.2, because I couldn't get gcc 14 to
build.
I got the following errors:
In file included from ../../../../gcc/libgcc/config/i386/cpuinfo.c:30:
../../../../gcc/libgcc/../gcc/common/config/i386/cpuinfo.h: In function
'get_available_features':
../../../../gcc/libgcc/../gcc/common/config/i386/cpuinfo.h:938:21: error:
'bit_USER_MSR' undeclared (first use in this function)
938 | if (edx & bit_USER_MSR)
| ^~~~
../../../../gcc/libgcc/../gcc/common/config/i386/cpuinfo.h:938:21: note:
each undeclared identifier is reported only once for each function it
appears in
../../../../gcc/libgcc/../gcc/common/config/i386/cpuinfo.h:950:25: error:
'bit_AVXVNNIINT16' undeclared (first use in this function); did you mean
'bit_AVXVNNIINT8'?
950 | if (edx & bit_AVXVNNIINT16)
| ^~~~
| bit_AVXVNNIINT8
Hopefully it's still okay.
[PATCH] lto: Don't assume a posix shell is usable on windows [PR110710]
lto-wrapper generates Makefiles that use the following:
touch -r file file.tmp && mv file.tmp file
to truncate files.
If there is no suitable "touch" or "mv" available, then this errors with
"The system cannot find the file specified".
The solution here is to check if sh -c true works, before trying to use it in
the Makefile. If it doesn't, then fall back to "copy /y nul file" instead.
The fallback doesn't work exactly the same (the modified time of the file gets
updated), but this doesn't seem to matter in practice.
I tested this both in environments both with and without sh present, and
observed no issues.
Signed-off-by: Peter Damianov
---
gcc/lto-wrapper.cc | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/gcc/lto-wrapper.cc b/gcc/lto-wrapper.cc
index 5186d040ce0..8dee0aaa2d8 100644
--- a/gcc/lto-wrapper.cc
+++ b/gcc/lto-wrapper.cc
@@ -1389,6 +1389,27 @@ make_exists (void)
return errmsg == NULL && exit_status == 0 && err == 0;
}
+/* Test that an sh command is present and working, return true if so.
+ This is only relevant for windows hosts, where a /bin/sh shell cannot
+ be assumed to exist. */
+
+static bool
+sh_exists (void)
+{
+ const char *sh = "sh";
+ const char *sh_args[] = {sh, "-c", "true", NULL};
+#ifdef _WIN32
+ int exit_status = 0;
+ int err = 0;
+ const char *errmsg
+= pex_one (PEX_SEARCH, sh_args[0], CONST_CAST (char **, sh_args),
+ "sh", NULL, NULL, &exit_status, &err);
+ return errmsg == NULL && exit_status == 0 && err == 0;
+#else
+ return true;
+#endif
+}
+
/* Execute gcc. ARGC is the number of arguments. ARGV contains the arguments.
*/
static void
@@ -1402,6 +1423,7 @@ run_gcc (unsigned argc, char *argv[])
const char *collect_gcc;
char *collect_gcc_options;
int parallel = 0;
+ bool have_sh = sh_exists ();
int jobserver = 0;
bool jobserver_requested = false;
int auto_parallel = 0;
@@ -2016,6 +2038,7 @@ cont:
argv_ptr[5] = NULL;
if (parallel)
{
+ fprintf (mstream, "SHELL=%s\n", have_sh ? "sh" : "cmd");
fprintf (mstream, "%s:\n\t@%s ", output_name, new_argv[0]);
for (j = 1; new_argv[j] != NULL; ++j)
fprintf (mstream, " '%s'", new_argv[j]);
@@ -2024,9 +2047,15 @@ cont:
truncate them as soon as we have processed it. This
reduces temporary disk-space usage. */
if (! save_temps)
- fprintf (mstream, "\t@-touch -r \"%s\" \"%s.tem\" > /dev/null "
-"2>&1 && mv \"%s.tem\" \"%s\"\n",
-input_name, input_name, input_name, input_name);
+ {
+ fprintf (mstream,
+ have_sh
+ ? "\t@-touch -r \"%s\" \"%s.tem\" > /dev/null "
+"2>&1 && mv \"%s.tem\" \"%s\"\n"
+ : "\t@-copy /y nul \"%s\" > NUL "
+"2>&1\n",
+ input_name, input_name, input_name, input_name);
+ }
}
else
{
--
2.39.2
[r14-9677 Regression] FAIL: gcc.dg/debug/btf/btf-datasec-1.c scan-assembler-times .4byte[\t ][a-e][\t ]+[^\n]*bts_offset 5 on Linux/x86_64
On Linux/x86_64,
fa60ac549649655a3f55e69f83d2e97423d3eb5c is the first bad commit
commit fa60ac549649655a3f55e69f83d2e97423d3eb5c
Author: Cupertino Miranda
Date: Tue Mar 26 11:59:47 2024 +
btf: Emit labels in DATASEC bts_offset entries.
caused
FAIL: gcc.dg/debug/btf/btf-datasec-1.c scan-assembler-times .4byte[\t ][a-e][\t
]+[^\n]*bts_offset 5
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-9677/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="btf.exp=gcc.dg/debug/btf/btf-datasec-1.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="btf.exp=gcc.dg/debug/btf/btf-datasec-1.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="btf.exp=gcc.dg/debug/btf/btf-datasec-1.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="btf.exp=gcc.dg/debug/btf/btf-datasec-1.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
[r14-9668 Regression] FAIL: gcc.c-torture/execute/pr111151.c -Os execution test on Linux/x86_64
On Linux/x86_64,
c4f2c84e8fa369856aee76679590eb613724bfb0 is the first bad commit
commit c4f2c84e8fa369856aee76679590eb613724bfb0
Author: Jakub Jelinek
Date: Tue Mar 26 11:21:38 2024 +0100
fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR51]
caused
FAIL: gcc.c-torture/execute/pr51.c -O0 execution test
FAIL: gcc.c-torture/execute/pr51.c -O1 execution test
FAIL: gcc.c-torture/execute/pr51.c -O2 execution test
FAIL: gcc.c-torture/execute/pr51.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.c-torture/execute/pr51.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL: gcc.c-torture/execute/pr51.c -O3 -g execution test
FAIL: gcc.c-torture/execute/pr51.c -Os execution test
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-9668/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/pr51.c
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/pr51.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/pr51.c
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check
RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/pr51.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
Re: [patch, libgfortran] PR107031 - endfile truncates file at wrong position
Hi Jerry, Am 26.03.24 um 04:18 schrieb Jerry D: Hi all, There has been a bit of discussio on which way to go on this. I took a look today and this trivial patch gives the behavior concluded on Fortran Discourse. See the bugzilla for all the relevant information. Regresion tested on x86-64. I will do the appropriate changelog. OK for trunk? Attached is a new test case and the patch here: diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c index 2bc05b293f8..d169961f997 100644 --- a/libgfortran/io/file_pos.c +++ b/libgfortran/io/file_pos.c @@ -352,7 +352,6 @@ st_endfile (st_parameter_filepos *fpp) dtp.common = fpp->common; memset (&dtp.u.p, 0, sizeof (dtp.u.p)); dtp.u.p.current_unit = u; - next_record (&dtp, 1); } unit_truncate (u, stell (u->s), &fpp->common); this is OK from my side. Given the discussion on "dg-do run", wouldn't this be a perfect example where it is sufficient to run the testcase just once? The change is in libgfortran, not in the frontend or middle-end. Thanks for the patch! Harald
Re: [pushed] aarch64: Define out-of-class static constants
Vaseeharan Vinayagamoorthy writes:
> Hi Richard,
>
> I think this patch is breaking the build of aarch64-none-elf and
> aarch64-none-linux-gnu targets, when building with GCC 4.8.
> This is not an issue when building with GCC 7.5.
>
> Kind regards,
> Vasee
Thanks. I pushed the attached patch to fix it.
Richard
---
GCC 4.8 complained about the use of const rather than constexpr
for out-of-line static constexprs.
gcc/
* config/aarch64/aarch64-feature-deps.h: Use constexpr for
out-of-line statics.
---
gcc/config/aarch64/aarch64-feature-deps.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/config/aarch64/aarch64-feature-deps.h
b/gcc/config/aarch64/aarch64-feature-deps.h
index 3641badb82f..79126db8825 100644
--- a/gcc/config/aarch64/aarch64-feature-deps.h
+++ b/gcc/config/aarch64/aarch64-feature-deps.h
@@ -71,9 +71,9 @@ template struct info;
static constexpr auto enable = flag | get_enable REQUIRES; \
static constexpr auto explicit_on = enable | get_enable EXPLICIT_ON; \
}; \
- const aarch64_feature_flags info::flag; \
- const aarch64_feature_flags info::enable;\
- const aarch64_feature_flags info::explicit_on; \
+ constexpr aarch64_feature_flags info::flag; \
+ constexpr aarch64_feature_flags info::enable;
\
+ constexpr aarch64_feature_flags info::explicit_on; \
constexpr info IDENT () \
{\
return info ();\
--
2.25.1
Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)
On Tue, 26 Mar 2024, Qing Zhao wrote:
> > What happens when there are multiple counted_by attributes on the same
> > field? As far as I can see, all but one end up being ignored (by the code
> > that actually uses the attribute).
>
> In general, is there any rule for handling multiple same attributes in
> GCC? i.e, from left to right, the last one wins? Or something else? I’d
> like to following the consistent rule with other places in GCC.
Sometimes, they are meaningful and all can be respected. (An example is
the format_arg attribute, where ngettext legitimately has two such
attributes.)
When not meaningful, an error is appropriate. For example, with section
attributes you can get
error ("section of %q+D conflicts with previous declaration",
*node);
if different sections are named. I think that's a suitable model for the
new attribute here: allow duplicates if they name the same field, but give
errors if they name different fields, just as with the section attribute.
Once you give an error for multiple attributes naming different fields,
which one wins is just a question of error recovery; the specific choice
doesn't matter much, as long as you don't get an ICE in later processing.
--
Joseph S. Myers
josmy...@redhat.com
[PATCH] libatomic: Cleanup macros in atomic_16.S
As mentioned in https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648397.html , do some additional cleanup of the macros and aliases: Cleanup the macros to add the libat_ prefixes in atomic_16.S. Emit the alias to __atomic_ when ifuncs are not enabled in the ENTRY macro. Passes regress and bootstrap, OK for commit? libatomic: * config/linux/aarch64/atomic_16.S: Add __libat_ prefix in the LSE2/LSE128/CORE macros, remove elsewhere. Add ATOMIC macro. --- diff --git a/libatomic/config/linux/aarch64/atomic_16.S b/libatomic/config/linux/aarch64/atomic_16.S index 4e3fa870b0338da4cfcdb0879ab8bed8d041a0a3..d0343507120c06a483ffdae1a793b6b5263cfe98 100644 --- a/libatomic/config/linux/aarch64/atomic_16.S +++ b/libatomic/config/linux/aarch64/atomic_16.S @@ -45,7 +45,7 @@ # define HAVE_FEAT_LSE128 0 #endif -#define HAVE_FEAT_LSE2 HAVE_IFUNC +#define HAVE_FEAT_LSE2 HAVE_IFUNC #if HAVE_FEAT_LSE128 .arch armv9-a+lse128 @@ -53,31 +53,37 @@ .arch armv8-a+lse #endif -#define LSE128(NAME) NAME##_i1 -#define LSE2(NAME) NAME##_i2 -#define CORE(NAME) NAME +#define LSE128(NAME) libat_##NAME##_i1 +#define LSE2(NAME) libat_##NAME##_i2 +#define CORE(NAME) libat_##NAME +#define ATOMIC(NAME) __atomic_##NAME -#define ENTRY_FEAT(NAME, FEAT) \ - ENTRY (FEAT (NAME)) +#if HAVE_IFUNC +# define ENTRY(NAME) ENTRY2 (CORE (NAME), ) +#else +/* Emit __atomic_* entrypoints if no ifuncs. */ +# define ENTRY(NAME) ENTRY2 (CORE (NAME), ALIAS (NAME, ATOMIC, CORE)) +#endif +#define ENTRY_FEAT(NAME, FEAT) ENTRY2 (FEAT (NAME), ) + +#define END(NAME) END2 (CORE (NAME)) +#define END_FEAT(NAME, FEAT) END2 (FEAT (NAME)) -#define ENTRY(NAME)\ +#define ENTRY2(NAME, ALIASES) \ .global NAME; \ .hidden NAME; \ .type NAME,%function; \ .p2align 4; \ + ALIASES;\ NAME: \ - .cfi_startproc; \ - hint34 // bti c - -#define END_FEAT(NAME, FEAT) \ - END (FEAT (NAME)) + .cfi_startproc; \ + hint34; // bti c -#define END(NAME) \ +#define END2(NAME) \ .cfi_endproc; \ .size NAME, .-NAME; -#define ALIAS(NAME, FROM, TO) ALIAS1 (FROM (NAME),TO (NAME)) -#define ALIAS2(NAME) ALIAS1 (__atomic_##NAME, libat_##NAME) +#define ALIAS(NAME, FROM, TO) ALIAS1 (FROM (NAME), TO (NAME)) #define ALIAS1(ALIAS, NAME)\ .global ALIAS; \ @@ -116,7 +122,7 @@ NAME: \ #define SEQ_CST 5 -ENTRY (libat_load_16) +ENTRY (load_16) mov x5, x0 cbnzw1, 2f @@ -131,11 +137,11 @@ ENTRY (libat_load_16) stxpw4, res0, res1, [x5] cbnzw4, 2b ret -END (libat_load_16) +END (load_16) #if HAVE_FEAT_LSE2 -ENTRY_FEAT (libat_load_16, LSE2) +ENTRY_FEAT (load_16, LSE2) cbnzw1, 1f /* RELAXED. */ @@ -155,11 +161,11 @@ ENTRY_FEAT (libat_load_16, LSE2) ldp res0, res1, [x0] dmb ishld ret -END_FEAT (libat_load_16, LSE2) +END_FEAT (load_16, LSE2) #endif -ENTRY (libat_store_16) +ENTRY (store_16) cbnzw4, 2f /* RELAXED. */ @@ -173,11 +179,11 @@ ENTRY (libat_store_16) stlxp w4, in0, in1, [x0] cbnzw4, 2b ret -END (libat_store_16) +END (store_16) #if HAVE_FEAT_LSE2 -ENTRY_FEAT (libat_store_16, LSE2) +ENTRY_FEAT (store_16, LSE2) cbnzw4, 1f /* RELAXED. */ @@ -189,11 +195,11 @@ ENTRY_FEAT (libat_store_16, LSE2) stlxp w4, in0, in1, [x0] cbnzw4, 1b ret -END_FEAT (libat_store_16, LSE2) +END_FEAT (store_16, LSE2) #endif -ENTRY (libat_exchange_16) +ENTRY (exchange_16) mov x5, x0 cbnzw4, 2f @@ -217,11 +223,11 @@ ENTRY (libat_exchange_16) stlxp w4, in0, in1, [x5] cbnzw4, 4b ret -END (libat_exchange_16) +END (exchange_16) #if HAVE_FEAT_LSE128 -ENTRY_FEAT (libat_exchange_16, LSE128) +ENTRY_FEAT (exchange_16, LSE128) mov tmp0, x0 mov res0, in0 mov res1, in1 @@ -241,11 +247,11 @@ ENTRY_FEAT (libat_exchange_16, LSE128) /* RELEASE/ACQ_REL/SEQ_CST. */ 2: swppal res0, res1, [tmp0] ret -END_FEAT (libat_exchange_16, LSE128) +END_FEAT (exchange_16, LSE128) #endif -ENTRY (libat_compare_exchange_16) +ENTRY (compare_exchange_16) ldp exp0, exp1, [x1] cbz w4, 3f cmp w4, RELEASE @@ -289,11 +295,11 @@ ENTRY (libat_compare_exchange_16) stp tmp0, tmp1, [x1] 6: csetx0, eq ret -END (libat_compare_exchange_16) +END (compare_exchange_16) #if HAVE_FEAT_LSE2 -ENTRY_FEAT (libat_compare_exchange_16, LSE2) +ENTRY_FEAT (compare_exchange_16, LSE2) ldp exp0, exp1, [x1] mov tmp0, exp0 mov tmp1, exp1 @@ -326,
Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]
On Tue, Mar 26, 2024 at 9:33 AM Дилян Палаузов
wrote:
>
> Makefile.def contains already:
>
> host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84
> - "libbacktrace/: * Initial implementation" year 2012
>
> host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53dd8517c0b2
> - year 2004
Yes. I was just trying to answer your question.
Ian
> Am 25. März 2024 23:59:52 UTC schrieb Ian Lance Taylor :
>>
>> On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
>> wrote:
>>>
>>>
>>> Can the build experts say what needs to be changed? The dependencies I
>>> added are missing in the build configuration (@if gcc-bootstrap).
>>>
>>> I cannot say if libbacktrace should or should not be a bootstrap=true
>>> module.
>>
>>
>> I don't count as a build expert these days, but since GCC itself links
>> against libbacktrace, my understanding is that the libbacktrace
>> host_module should be bootstrap=true, just like, say, libcpp.
>>
>> Ian
Re: No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. [PR106472]
Hello Ian,
Makefile.def contains already:
host_modules= { module= libbacktrace; bootstrap=true; }; // since eff02e4f84 -
"libbacktrace/: * Initial implementation" year 2012
host_modules= { module= libcpp; bootstrap=true; }; // since 4f4e53dd8517c0b2 -
year 2004
Greetings
Дилян
Am 25. März 2024 23:59:52 UTC schrieb Ian Lance Taylor :
>On Sat, Mar 23, 2024 at 4:32 AM Дилян Палаузов
> wrote:
>>
>> Can the build experts say what needs to be changed? The dependencies I
>> added are missing in the build configuration (@if gcc-bootstrap).
>>
>> I cannot say if libbacktrace should or should not be a bootstrap=true module.
>
>I don't count as a build expert these days, but since GCC itself links
>against libbacktrace, my understanding is that the libbacktrace
>host_module should be bootstrap=true, just like, say, libcpp.
>
>Ian
Re: [PATCH] btf: Emit labels in DATASEC bts_offset entries.
David Faust writes:
> On 3/26/24 07:28, Cupertino Miranda wrote:
>> Hi everyone,
>>
>> This patch is an expected fix for the issue reported by systemd in:
>> https://github.com/systemd/systemd/issues/31888
>> Also, Jose Marchesi opened the following bugzilla to report it:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431
>>
>> Please notice that the function created was inspired by existing code
>> in the function btf_asm_type_ref.
>>
>> Looking forward to your comments.
>
> OK, LGTM.
> Thanks for the fix!
Pushed! Thanks!
>>
>> Cupertino
>>
>>
>> GCC was defining bts_offset entry to always contain 0.
>> When comparing with clang, the same entry is instead a label to the
>> respective variable or function. The assembler emits relocations for
>> those labels.
>>
>> gcc/ChangeLog:
>> PR target/114431
>> * btfout.cc (get_name_for_datasec_entry): Add function.
>> (btf_asm_datasec_entry): Print label when possible.
>>
>> gcc/testsuite/ChangeLog:
>> gcc.dg/debug/btf/btf-datasec-1.c: Correct for new
>> implementation.
>> gcc.dg/debug/btf/btf-datasec-2.c: Likewise
>> gcc.dg/debug/btf/btf-pr106773.c: Likewise
>> ---
>> gcc/btfout.cc | 30 ++-
>> .../gcc.dg/debug/btf/btf-datasec-1.c | 6 ++--
>> .../gcc.dg/debug/btf/btf-datasec-2.c | 7 +++--
>> gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c | 2 +-
>> 4 files changed, 39 insertions(+), 6 deletions(-)
>>
>> diff --git a/gcc/btfout.cc b/gcc/btfout.cc
>> index e63289bc554..5f708630e04 100644
>> --- a/gcc/btfout.cc
>> +++ b/gcc/btfout.cc
>> @@ -1014,13 +1014,41 @@ btf_asm_func_type (ctf_container_ref ctfc,
>> ctf_dtdef_ref dtd, ctf_id_t id)
>>btf_asm_type_ref ("btt_type", ctfc, get_btf_id (ref_id));
>> }
>>
>> +/* Collect the name for the DATASEC reference required to be output as a
>> + symbol. */
>> +
>> +static const char *
>> +get_name_for_datasec_entry (ctf_container_ref ctfc, ctf_id_t ref_id)
>> +{
>> + if (ref_id >= num_types_added + 1
>> + && ref_id < num_types_added + num_vars_added + 1)
>> +{
>> + /* Ref to a variable. Should only appear in DATASEC entries. */
>> + ctf_id_t var_id = btf_relative_var_id (ref_id);
>> + ctf_dvdef_ref dvd = ctfc->ctfc_vars_list[var_id];
>> + return dvd->dvd_name;
>> +}
>> + else if (ref_id >= num_types_added + num_vars_added + 1)
>> +{
>> + /* Ref to a FUNC record. */
>> + size_t func_id = btf_relative_func_id (ref_id);
>> + ctf_dtdef_ref ref_type = (*funcs)[func_id];
>> + return get_btf_type_name (ref_type);
>> +}
>> + return NULL;
>> +}
>> +
>> /* Asm'out a variable entry following a BTF_KIND_DATASEC. */
>>
>> static void
>> btf_asm_datasec_entry (ctf_container_ref ctfc, struct btf_var_secinfo info)
>> {
>> + const char *symbol_name = get_name_for_datasec_entry (ctfc, info.type);
>>btf_asm_type_ref ("bts_type", ctfc, info.type);
>> - dw2_asm_output_data (4, info.offset, "bts_offset");
>> + if (symbol_name == NULL)
>> +dw2_asm_output_data (4, info.offset, "bts_offset");
>> + else
>> +dw2_asm_output_offset (4, symbol_name, NULL, "bts_offset");
>>dw2_asm_output_data (4, info.size, "bts_size");
>> }
>>
>> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
>> b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
>> index 77df88648c5..8557c38c20d 100644
>> --- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
>> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
>> @@ -19,8 +19,10 @@
>> /* { dg-final { scan-assembler-times "0xf03\[\t \]+\[^\n\]*btt_info" 2
>> } } */
>> /* { dg-final { scan-assembler-times "0xf01\[\t \]+\[^\n\]*btt_info" 1
>> } } */
>>
>> -/* The offset entry for each variable in a DATSEC should be 0 at compile
>> time. */
>> -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
>> +/* The offset entry for each variable in a DATSEC should contain a label.
>> */
>> +/* { dg-final { scan-assembler-times ".4byte\[\t \]\[a-e\]\[\t
>> \]+\[^\n\]*bts_offset" 5 } } */
>> +/* { dg-final { scan-assembler-times "my_cstruct\[\t \]+\[^\n\]*bts_offset"
>> 1 } } */
>> +/* { dg-final { scan-assembler-times "bigarr\[\t \]+\[^\n\]*bts_offset" 1 }
>> } */
>>
>> /* Check that strings for each DATASEC have been added to the BTF string
>> table. */
>> /* { dg-final { scan-assembler-times "ascii \".data.0\"\[\t
>> \]+\[^\n\]*btf_aux_string" 1 } } */
>> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
>> b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
>> index d6f3358d6fb..857d830e446 100644
>> --- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
>> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
>> @@ -9,8 +9,11 @@
>> /* { dg-final { scan-assembler-times " BTF_KIND_DATASEC
>> '.foo_sec'\[\\r\\n\]+\[^\\r\\n\]*0xf01\[\t \]+\[^\n\]*btt_info" 1 } } */
>> /* { dg-final { scan-assembler-times " BTF_KIND_DATASEC
>> '.bar_sec'\[\\r\\n\]+\[^\\r\\n\]*0xf02\[
Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)
> On Mar 26, 2024, at 11:21, Joseph Myers wrote:
>
> On Tue, 26 Mar 2024, Qing Zhao wrote:
>
+@cindex @code{counted_by} variable attribute
+@item counted_by (@var{count})
+The @code{counted_by} attribute may be attached to the C99 flexible array
+member of a structure. It indicates that the number of the elements of
the
+array is given by the field named "@var{count}" in the same structure as
the
+flexible array member.
>>>
>>> You shouldn't use ASCII quotes like that in Texinfo (outside @code etc.
>>> where they represent literal quotes in programming language source code).
>>> You can say ``@var{count}'' if you wish to quote the name.
>> A little confused with the above..
>> So, what should I change in the above statement?
>
> I don't think you actually need quotes (or "named") at all; just
>
> the field @var{count}
>
> in place of
>
> the field named "@var{count}"
>
> would suffice.
Okay, I see. -:)
> But if you use quotes (for an English-language quotation,
> as opposed to when the quotes themselves are part of programming-language
> source code given in the manual), in Texinfo you should use ``'' rather
> than "".
Thanks for the explanation.
Qing
>
> --
> Joseph S. Myers
> josmy...@redhat.com
>
Re: [PATCH] btf: Emit labels in DATASEC bts_offset entries.
On 3/26/24 07:28, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch is an expected fix for the issue reported by systemd in:
> https://github.com/systemd/systemd/issues/31888
> Also, Jose Marchesi opened the following bugzilla to report it:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431
>
> Please notice that the function created was inspired by existing code
> in the function btf_asm_type_ref.
>
> Looking forward to your comments.
OK, LGTM.
Thanks for the fix!
>
> Cupertino
>
>
> GCC was defining bts_offset entry to always contain 0.
> When comparing with clang, the same entry is instead a label to the
> respective variable or function. The assembler emits relocations for
> those labels.
>
> gcc/ChangeLog:
> PR target/114431
> * btfout.cc (get_name_for_datasec_entry): Add function.
> (btf_asm_datasec_entry): Print label when possible.
>
> gcc/testsuite/ChangeLog:
> gcc.dg/debug/btf/btf-datasec-1.c: Correct for new
> implementation.
> gcc.dg/debug/btf/btf-datasec-2.c: Likewise
> gcc.dg/debug/btf/btf-pr106773.c: Likewise
> ---
> gcc/btfout.cc | 30 ++-
> .../gcc.dg/debug/btf/btf-datasec-1.c | 6 ++--
> .../gcc.dg/debug/btf/btf-datasec-2.c | 7 +++--
> gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c | 2 +-
> 4 files changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/btfout.cc b/gcc/btfout.cc
> index e63289bc554..5f708630e04 100644
> --- a/gcc/btfout.cc
> +++ b/gcc/btfout.cc
> @@ -1014,13 +1014,41 @@ btf_asm_func_type (ctf_container_ref ctfc,
> ctf_dtdef_ref dtd, ctf_id_t id)
>btf_asm_type_ref ("btt_type", ctfc, get_btf_id (ref_id));
> }
>
> +/* Collect the name for the DATASEC reference required to be output as a
> + symbol. */
> +
> +static const char *
> +get_name_for_datasec_entry (ctf_container_ref ctfc, ctf_id_t ref_id)
> +{
> + if (ref_id >= num_types_added + 1
> + && ref_id < num_types_added + num_vars_added + 1)
> +{
> + /* Ref to a variable. Should only appear in DATASEC entries. */
> + ctf_id_t var_id = btf_relative_var_id (ref_id);
> + ctf_dvdef_ref dvd = ctfc->ctfc_vars_list[var_id];
> + return dvd->dvd_name;
> +}
> + else if (ref_id >= num_types_added + num_vars_added + 1)
> +{
> + /* Ref to a FUNC record. */
> + size_t func_id = btf_relative_func_id (ref_id);
> + ctf_dtdef_ref ref_type = (*funcs)[func_id];
> + return get_btf_type_name (ref_type);
> +}
> + return NULL;
> +}
> +
> /* Asm'out a variable entry following a BTF_KIND_DATASEC. */
>
> static void
> btf_asm_datasec_entry (ctf_container_ref ctfc, struct btf_var_secinfo info)
> {
> + const char *symbol_name = get_name_for_datasec_entry (ctfc, info.type);
>btf_asm_type_ref ("bts_type", ctfc, info.type);
> - dw2_asm_output_data (4, info.offset, "bts_offset");
> + if (symbol_name == NULL)
> +dw2_asm_output_data (4, info.offset, "bts_offset");
> + else
> +dw2_asm_output_offset (4, symbol_name, NULL, "bts_offset");
>dw2_asm_output_data (4, info.size, "bts_size");
> }
>
> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
> b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
> index 77df88648c5..8557c38c20d 100644
> --- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
> @@ -19,8 +19,10 @@
> /* { dg-final { scan-assembler-times "0xf03\[\t \]+\[^\n\]*btt_info" 2 }
> } */
> /* { dg-final { scan-assembler-times "0xf01\[\t \]+\[^\n\]*btt_info" 1 }
> } */
>
> -/* The offset entry for each variable in a DATSEC should be 0 at compile
> time. */
> -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
> +/* The offset entry for each variable in a DATSEC should contain a label. */
> +/* { dg-final { scan-assembler-times ".4byte\[\t \]\[a-e\]\[\t
> \]+\[^\n\]*bts_offset" 5 } } */
> +/* { dg-final { scan-assembler-times "my_cstruct\[\t \]+\[^\n\]*bts_offset"
> 1 } } */
> +/* { dg-final { scan-assembler-times "bigarr\[\t \]+\[^\n\]*bts_offset" 1 }
> } */
>
> /* Check that strings for each DATASEC have been added to the BTF string
> table. */
> /* { dg-final { scan-assembler-times "ascii \".data.0\"\[\t
> \]+\[^\n\]*btf_aux_string" 1 } } */
> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
> b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
> index d6f3358d6fb..857d830e446 100644
> --- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
> @@ -9,8 +9,11 @@
> /* { dg-final { scan-assembler-times " BTF_KIND_DATASEC
> '.foo_sec'\[\\r\\n\]+\[^\\r\\n\]*0xf01\[\t \]+\[^\n\]*btt_info" 1 } } */
> /* { dg-final { scan-assembler-times " BTF_KIND_DATASEC
> '.bar_sec'\[\\r\\n\]+\[^\\r\\n\]*0xf02\[\t \]+\[^\n\]*btt_info" 1 } } */
>
> -/* Function entries should have offset and size of 0 at compile time. */
> -/* { dg-final { scan-assemb
[committed] testsuite: Fix up pr111151.c testcase [PR114486]
Hi! Apparently I've somehow screwed up the adjustments of the originally tested testcase, tweaked it so that in the second/third cases it actually see a MAX_EXPR rather than COND_EXPR the MAX_EXPR has been optimized into, and didn't update the expected value. Tested on x86_64-linux -m32/-m64 with older and current trunk, committed to trunk as obvious. 2024-03-26 Jakub Jelinek PR middle-end/51 PR testsuite/114486 * gcc.c-torture/execute/pr51.c (main): Fix up expected value for f. --- gcc/testsuite/gcc.c-torture/execute/pr51.c.jj 2024-03-26 11:21:31.0 +0100 +++ gcc/testsuite/gcc.c-torture/execute/pr51.c 2024-03-26 16:33:17.342319263 +0100 @@ -11,7 +11,7 @@ main () int d = (-__INT_MAX__ - 1) / 2; int e = 10; int f = (d * 2 > e * 5 ? d * 2 : e * 5) * 6; - if (f != 120) + if (f != 300) __builtin_abort (); int g = (-__INT_MAX__ - 1) / 2; int h = 0; Jakub
Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)
On Tue, 26 Mar 2024, Qing Zhao wrote:
> >> +@cindex @code{counted_by} variable attribute
> >> +@item counted_by (@var{count})
> >> +The @code{counted_by} attribute may be attached to the C99 flexible array
> >> +member of a structure. It indicates that the number of the elements of
> >> the
> >> +array is given by the field named "@var{count}" in the same structure as
> >> the
> >> +flexible array member.
> >
> > You shouldn't use ASCII quotes like that in Texinfo (outside @code etc.
> > where they represent literal quotes in programming language source code).
> > You can say ``@var{count}'' if you wish to quote the name.
> A little confused with the above..
> So, what should I change in the above statement?
I don't think you actually need quotes (or "named") at all; just
the field @var{count}
in place of
the field named "@var{count}"
would suffice. But if you use quotes (for an English-language quotation,
as opposed to when the quotes themselves are part of programming-language
source code given in the manual), in Texinfo you should use ``'' rather
than "".
--
Joseph S. Myers
josmy...@redhat.com
Re: [PATCH v7 3/5] Use the .ACCESS_WITH_SIZE in builtin object size.
Thanks, will update. Qing > On Mar 25, 2024, at 16:50, Joseph Myers wrote: > > On Wed, 20 Mar 2024, Qing Zhao wrote: > >> + the size of the element can be retrived from the result type of the call, >> + which is the pointer to the array type. */ > > Again, start a sentence with an uppercase letter. > >> + /* if not for dynamic object size, return. */ > >> + /* result type is a pointer type to the original flexible array type. */ > > Likewise. > > -- > Joseph S. Myers > josmy...@redhat.com >
Re: [PATCH v7 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.
> On Mar 25, 2024, at 16:48, Joseph Myers wrote: > > On Wed, 20 Mar 2024, Qing Zhao wrote: > >> + /* get the TYPE of the counted_by field. */ > > Start comments with an uppercase letter. Okay. > >> + The type of the first argument of this function is a POINTER type >> + to the orignal flexible array type. > > s/orignal/original/ Okay. > >> + If HANDLE_COUNTED_BY is true, check the counted_by attribute and generate >> + call to .ACCESS_WITH_SIZE. otherwise, ignore the attribute. */ > > A sentence should start with an uppercase letter, "Otherwise”. Okay. > >> - /* Ordinary case; arg is a COMPONENT_REF or a decl. */ >> + /* Ordinary case; arg is a COMPONENT_REF or a decl,or a call to >> + .ACCESS_WITH_SIZE. */ > > There should be a space after a comma. Okay. (I remembered that I used contrib/check_GNU_style.sh check all the patches, not sure why such errors were not caught). > >> +/* Get the corresponding reference from the call to a .ACCESS_WITH_SIZE. >> + * i.e the first argument of this call. return NULL_TREE otherwise. */ >> +extern tree get_ref_from_access_with_size (tree); > > Again, start a sentence with an uppercase letter. Okay. > >> +case CALL_EXPR: >> + /* for a call to .ACCESS_WITH_SIZE, check the first argument. */ > > Likewise. Okay. > >> + /* for a call to .ACCESS_WITH_SIZE, check the first argument. */ > > Likewise. Okay. Will update accordingly. thanks. Qing > > -- > Joseph S. Myers > josmy...@redhat.com >
Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)
Hi, Joseph,
Thanks a lot for the reviews.
> On Mar 25, 2024, at 16:44, Joseph Myers wrote:
>
> On Wed, 20 Mar 2024, Qing Zhao wrote:
>
>> + /* This attribute only applies to a C99 flexible array member type. */
>> + else if (! c_flexible_array_member_type_p (TREE_TYPE (decl)))
>> +{
>> + error_at (DECL_SOURCE_LOCATION (decl),
>> +"%qE attribute is not allowed for a non"
>> +" flexible array member field",
>
> "non-flexible" not "non flexible" ("non" shouldn't appear as a word on its
> own).
Okay.
>
>> + /* Error when the field is not found in the containing structure. */
>> + if (!counted_by_field)
>> +error_at (DECL_SOURCE_LOCATION (field_decl),
>> + "Argument %qE to the %qE attribute is not a field declaration"
>> + " in the same structure as %qD", fieldname,
>
> Diagnostics should start with a lowercase letter, "argument" not
> "Argument”.
Okay.
>
>> + if (TREE_CODE (TREE_TYPE (real_field)) != INTEGER_TYPE)
>> +error_at (DECL_SOURCE_LOCATION (field_decl),
>> + "Argument %qE to the %qE attribute is not a field declaration"
>> + " with an integer type", fieldname,
>
> Likewise.
Okay.
>
> Generally checks for integer types should allow any INTEGRAL_TYPE_P,
> rather than just INTEGER_TYPE. For example, it should be valid to use
> this attribute with a field with _BitInt type. (It would be fairly
> useless with a _BitInt larger than size_t, but maybe e.g. someone knows
> the size in their code must fit into 24 bits and so uses unsigned
> _BitInt(24) for the field.)
Okay. Will change this.
>
> Of course there should be corresponding testcases for _Bool / enum /
> _BitInt count fields.
And add corresponding testing cases.
>
> What happens when there are multiple counted_by attributes on the same
> field? As far as I can see, all but one end up being ignored (by the code
> that actually uses the attribute).
In general, is there any rule for handling multiple same attributes in GCC?
i.e, from left to right, the last one wins? Or something else? I’d like to
following the consistent rule with other places in GCC.
> I think multiple such attributes using
> different identifiers should be diagnosed, even if all the identifiers are
> indeed integer fields in the same structure - it doesn't seem meaningful
> to say that multiple fields give the count of elements.
Yes, this is reasonable. Shall we ignore all but the last one? And issue
warnings at the same time?
i.e. for the following:
struct trailing_array {
int c1;
int final;
int array_4[] __attribute ((counted_by (c1))) __attribute ((counted_by
(final)));
};
For the above, issue warning by default:
multiple 'counted-by' attribute specified for the same flexible array member
field “array_4”, only the last one “final” is valid.
??
> (Multiple
> attributes with the *same* identifier are probably OK to allow; maybe that
> could arise in code using complicated macros that end up adding the
> attribute more than once.)
Okay.
Shall we issue warnings for this case? (Probably not??)
>
>> +@cindex @code{counted_by} variable attribute
>> +@item counted_by (@var{count})
>> +The @code{counted_by} attribute may be attached to the C99 flexible array
>> +member of a structure. It indicates that the number of the elements of the
>> +array is given by the field named "@var{count}" in the same structure as the
>> +flexible array member.
>
> You shouldn't use ASCII quotes like that in Texinfo (outside @code etc.
> where they represent literal quotes in programming language source code).
> You can say ``@var{count}'' if you wish to quote the name.
A little confused with the above..
So, what should I change in the above statement?
>
>> +The field that represents the number of the elements should have an
>> +integer type. Otherwise, the compiler will report a warning and ignore
>> +the attribute.
>> +When the field that represents the number of the elements is assigned a
>> +negative integer value, the compiler will treat the value as zero.
>
> In general it's best for documentation to be in the present tense (so the
> compiler *reports* a warning rather than "will report", *treats* the value
> as zero rather than "will treat").
thanks, will update them.
>
>> +It's the user's responsibility to make sure the above requirements to
>> +be kept all the time. Otherwise the compiler will report warnings,
>> +at the same time, the results of the array bound sanitizer and the
>> +@code{__builtin_dynamic_object_size} is undefined.
>
> Likewise.
Okay.
Thanks a lot.
Qing
>
> --
> Joseph S. Myers
> josmy...@redhat.com
>
[PATCH 1/2] xtensa: Resurrect LEAF_REGISTERS and LEAF_REG_REMAP
They were once mistakenly removed with
"xtensa: Remove old broken tweak for leaf function", but caused unwanted
register spills.
gcc/ChangeLog:
* config/xtensa/xtensa.h (LEAF_REGISTERS, LEAF_REG_REMAP):
Withdraw the removal.
(REG_ALLOC_ORDER): Cosmetics.
* config/xtensa/xtensa.cc (xtensa_leaf_regs): Withdraw the removal.
(xtensa_adjust_reg_alloc_order): Cosmetics.
---
gcc/config/xtensa/xtensa.cc | 45 ++---
gcc/config/xtensa/xtensa.h | 29 ++--
2 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 9beac932467..df888294556 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -110,6 +110,18 @@ struct GTY(()) machine_function
HARD_REG_SET eliminated_callee_saved;
};
+/* Vector, indexed by hard register number, which contains 1 for a
+ register that is allowable in a candidate for leaf function
+ treatment. */
+
+const char xtensa_leaf_regs[FIRST_PSEUDO_REGISTER] =
+{
+ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
+ 1, 1, 1,
+ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
+ 1
+};
+
static void xtensa_option_override (void);
static enum internal_test map_test_to_internal_test (enum rtx_code);
static rtx gen_int_relational (enum rtx_code, rtx, rtx);
@@ -4314,15 +4326,32 @@ void
xtensa_adjust_reg_alloc_order (void)
{
static const int reg_windowed_alloc_order[FIRST_PSEUDO_REGISTER] =
- REG_ALLOC_ORDER;
+REG_ALLOC_ORDER;
static const int reg_call0_alloc_order[FIRST_PSEUDO_REGISTER] =
- {
- 9, 10, 11, 7, 6, 5, 4, 3, 2, 8, 0, 12, 13, 14, 15,
-18,
-19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34,
- 1, 16, 17,
-35,
- };
+{
+ /* a9 ... a11 : no special usage */
+ 9, 10, 11,
+ /* a7 ... a2 : function arguments, in reverse order */
+ 7, 6, 5, 4, 3, 2,
+ /* a8: static chain */
+ 8,
+ /* a0: return address (also callee saved) */
+ 0,
+ /* a12 ... a15 : callee saved */
+ 12, 13, 14, 15,
+ /* b0: boolean register for floating-point CC */
+ 18,
+ /* f0 ... f15 : floating-point registers */
+ 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34,
+ /* sp: stack pointer */
+ 1,
+ /* fp: FRAME_POINTER (fake) */
+ 16,
+ /* argp : ARG_POINTER (fake) */
+ 17,
+ /* acc: MAC16 accumulator */
+ 35,
+};
memcpy (reg_alloc_order, TARGET_WINDOWED_ABI ?
reg_windowed_alloc_order : reg_call0_alloc_order,
diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h
index 9591b3d4b40..835cb4bbf3b 100644
--- a/gcc/config/xtensa/xtensa.h
+++ b/gcc/config/xtensa/xtensa.h
@@ -248,14 +248,39 @@ along with GCC; see the file COPYING3. If not see
#define REG_ALLOC_ORDER
\
{ \
- 8, 9, 10, 11, 12, 13, 14, 15, 7, 6, 5, 4, 3, 2, \
+ /* a8 ... a15 : no special usage */ \
+ 8, 9, 10, 11, 12, 13, 14, 15, \
+ /* a7 ... a2 : incoming arguments, in reverse order */ \
+ 7, 6, 5, 4, 3, 2, \
+ /* b0: boolean register for floating-point CC */\
18, \
+ /* f0 ... f15 : floating-point registers */ \
19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, \
- 0, 1, 16, 17, \
+ /* a0: return address */\
+ 0, \
+ /* sp: stack pointer */ \
+ 1, \
+ /* fp: FRAME_POINTER (fake) */ \
+ 16, \
+ /* argp : ARG_POINTER (fake) */\
+ 17, \
+ /* acc: MAC16 accumulator */ \
35, \
}
#define ADJUST_REG_ALLOC_ORDER xtensa_adjust_reg_alloc_order ()
+/* For Xtensa, the only point of this is to prevent GCC from otherwise
+ giving preference to call-used registers. To minimize window
+ overflows for the AR registers, we want to give preference to the
+ lower-numbered AR registers. For other register files, which are
+ not windowed, we still prefer call-used registers, if ther
[PATCH 2/2] xtensa: Make use of std::swap where appropriate
No functional changes.
gcc/ChangeLog:
* config/xtensa/xtensa.cc
(gen_int_relational, gen_float_relational): Replace tempvar-based
value-swapping codes with std::swap.
* config/xtensa/xtensa.md (movdi_internal, movdf_internal):
Ditto.
---
gcc/config/xtensa/xtensa.cc | 12 ++--
gcc/config/xtensa/xtensa.md | 10 --
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index df888294556..38c6966cc31 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -799,11 +799,7 @@ gen_int_relational (enum rtx_code test_code, /* relational
test (EQ, etc) */
}
else if (p_info->reverse_regs)
-{
- rtx temp = cmp0;
- cmp0 = cmp1;
- cmp1 = temp;
-}
+std::swap (cmp0, cmp1);
return gen_rtx_fmt_ee (invert ? reverse_condition (p_info->test_code)
: p_info->test_code,
@@ -847,11 +843,7 @@ gen_float_relational (enum rtx_code test_code, /*
relational test (EQ, etc) */
}
if (reverse_regs)
-{
- rtx temp = cmp0;
- cmp0 = cmp1;
- cmp1 = temp;
-}
+std::swap (cmp0, cmp1);
brtmp = gen_rtx_REG (CCmode, FPCC_REGNUM);
emit_insn (gen_fn (brtmp, cmp0, cmp1));
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index fbe40ec671a..93c3ee78a01 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -1253,9 +1253,8 @@
xtensa_split_operand_pair (operands, SImode);
if (reg_overlap_mentioned_p (operands[0], operands[3]))
{
- rtx tmp;
- tmp = operands[0], operands[0] = operands[1], operands[1] = tmp;
- tmp = operands[2], operands[2] = operands[3], operands[3] = tmp;
+ std::swap (operands[0], operands[1]);
+ std::swap (operands[2], operands[3]);
}
})
@@ -1588,9 +1587,8 @@
xtensa_split_operand_pair (operands, SFmode);
if (reg_overlap_mentioned_p (operands[0], operands[3]))
{
- rtx tmp;
- tmp = operands[0], operands[0] = operands[1], operands[1] = tmp;
- tmp = operands[2], operands[2] = operands[3], operands[3] = tmp;
+ std::swap (operands[0], operands[1]);
+ std::swap (operands[2], operands[3]);
}
})
--
2.39.2
[pushed] c++: add fixed test [PR100557]
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
We used to hit the "Error reporting routines re-entered." ICE here but
it was fixed by Patrick's r14-3809.
PR c++/100557
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr100557.C: New test.
---
.../g++.dg/cpp2a/concepts-pr100557.C | 21 +++
1 file changed, 21 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-pr100557.C
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-pr100557.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-pr100557.C
new file mode 100644
index 000..8dcd0eaca51
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-pr100557.C
@@ -0,0 +1,21 @@
+// PR c++/100557
+// { dg-do compile { target c++20 } }
+
+template _Tp declval();
+
+struct print_tag_;
+
+bool tag_invoke(print_tag_, auto);
+bool tag_invoke(print_tag_, auto obj) requires requires { *obj; };
+
+template
+auto try_tag_invoke() noexcept(tag_invoke(declval, declval()...))
// { dg-error "no matching function for call" }
+-> decltype(tag_invoke(CPO(), declval()...));
+
+struct print_tag_ {
+ void operator()(auto... args) noexcept(noexcept( try_tag_invoke()));
+} print;
+
+void foo() {
+ print(0);
+}
base-commit: 2f47ca046eecf8f2fcae23df3ccee44d943ef512
--
2.44.0
[PATCH] btf: Emit labels in DATASEC bts_offset entries.
Hi everyone,
This patch is an expected fix for the issue reported by systemd in:
https://github.com/systemd/systemd/issues/31888
Also, Jose Marchesi opened the following bugzilla to report it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431
Please notice that the function created was inspired by existing code
in the function btf_asm_type_ref.
Looking forward to your comments.
Cupertino
GCC was defining bts_offset entry to always contain 0.
When comparing with clang, the same entry is instead a label to the
respective variable or function. The assembler emits relocations for
those labels.
gcc/ChangeLog:
PR target/114431
* btfout.cc (get_name_for_datasec_entry): Add function.
(btf_asm_datasec_entry): Print label when possible.
gcc/testsuite/ChangeLog:
gcc.dg/debug/btf/btf-datasec-1.c: Correct for new
implementation.
gcc.dg/debug/btf/btf-datasec-2.c: Likewise
gcc.dg/debug/btf/btf-pr106773.c: Likewise
---
gcc/btfout.cc | 30 ++-
.../gcc.dg/debug/btf/btf-datasec-1.c | 6 ++--
.../gcc.dg/debug/btf/btf-datasec-2.c | 7 +++--
gcc/testsuite/gcc.dg/debug/btf/btf-pr106773.c | 2 +-
4 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index e63289bc554..5f708630e04 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -1014,13 +1014,41 @@ btf_asm_func_type (ctf_container_ref ctfc,
ctf_dtdef_ref dtd, ctf_id_t id)
btf_asm_type_ref ("btt_type", ctfc, get_btf_id (ref_id));
}
+/* Collect the name for the DATASEC reference required to be output as a
+ symbol. */
+
+static const char *
+get_name_for_datasec_entry (ctf_container_ref ctfc, ctf_id_t ref_id)
+{
+ if (ref_id >= num_types_added + 1
+ && ref_id < num_types_added + num_vars_added + 1)
+{
+ /* Ref to a variable. Should only appear in DATASEC entries. */
+ ctf_id_t var_id = btf_relative_var_id (ref_id);
+ ctf_dvdef_ref dvd = ctfc->ctfc_vars_list[var_id];
+ return dvd->dvd_name;
+}
+ else if (ref_id >= num_types_added + num_vars_added + 1)
+{
+ /* Ref to a FUNC record. */
+ size_t func_id = btf_relative_func_id (ref_id);
+ ctf_dtdef_ref ref_type = (*funcs)[func_id];
+ return get_btf_type_name (ref_type);
+}
+ return NULL;
+}
+
/* Asm'out a variable entry following a BTF_KIND_DATASEC. */
static void
btf_asm_datasec_entry (ctf_container_ref ctfc, struct btf_var_secinfo info)
{
+ const char *symbol_name = get_name_for_datasec_entry (ctfc, info.type);
btf_asm_type_ref ("bts_type", ctfc, info.type);
- dw2_asm_output_data (4, info.offset, "bts_offset");
+ if (symbol_name == NULL)
+dw2_asm_output_data (4, info.offset, "bts_offset");
+ else
+dw2_asm_output_offset (4, symbol_name, NULL, "bts_offset");
dw2_asm_output_data (4, info.size, "bts_size");
}
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
index 77df88648c5..8557c38c20d 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
@@ -19,8 +19,10 @@
/* { dg-final { scan-assembler-times "0xf03\[\t \]+\[^\n\]*btt_info" 2 } }
*/
/* { dg-final { scan-assembler-times "0xf01\[\t \]+\[^\n\]*btt_info" 1 } }
*/
-/* The offset entry for each variable in a DATSEC should be 0 at compile time.
*/
-/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
+/* The offset entry for each variable in a DATSEC should contain a label. */
+/* { dg-final { scan-assembler-times ".4byte\[\t \]\[a-e\]\[\t
\]+\[^\n\]*bts_offset" 5 } } */
+/* { dg-final { scan-assembler-times "my_cstruct\[\t \]+\[^\n\]*bts_offset" 1
} } */
+/* { dg-final { scan-assembler-times "bigarr\[\t \]+\[^\n\]*bts_offset" 1 } }
*/
/* Check that strings for each DATASEC have been added to the BTF string
table. */
/* { dg-final { scan-assembler-times "ascii \".data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
index d6f3358d6fb..857d830e446 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-2.c
@@ -9,8 +9,11 @@
/* { dg-final { scan-assembler-times " BTF_KIND_DATASEC
'.foo_sec'\[\\r\\n\]+\[^\\r\\n\]*0xf01\[\t \]+\[^\n\]*btt_info" 1 } } */
/* { dg-final { scan-assembler-times " BTF_KIND_DATASEC
'.bar_sec'\[\\r\\n\]+\[^\\r\\n\]*0xf02\[\t \]+\[^\n\]*btt_info" 1 } } */
-/* Function entries should have offset and size of 0 at compile time. */
-/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 3 } } */
+/* Function entries should have offset with a label and size of 0 at compile
time. */
+/* { dg-final { scan-assembler-times "chacha\[\t \]+\[^\n\]*bts_offset" 1 } }
*/
+/* { dg-final { scan-assembler-times "bar\[\t \]+\[^\n\]*bts_offset" 1 } } */
+/* { dg-fi
Re: [PATCH] c++/modules: optimize tree flag streaming
On Tue, 27 Feb 2024, Patrick Palka wrote: > On Fri, 16 Feb 2024, Patrick Palka wrote: > > > On Thu, 15 Feb 2024, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > > OK for trunk? > > > > > > -- >8 -- > > > > > > One would expect consecutive calls to bytes_in/out::b for streaming > > > adjacent bits, as we do for tree flag streaming, to at least be > > > optimized by the compiler into individual bit operations using > > > statically known bit positions (and ideally merged into larger sized > > > reads/writes). > > > > > > Unfortunately this doesn't happen because the compiler has trouble > > > tracking the values of this->bit_pos and this->bit_val across such > > > calls, likely because the compiler doesn't know 'this' and so it's > > > treated as global memory. This means for each consecutive bit stream > > > operation, bit_pos and bit_val are loaded from memory, checked if > > > buffering is needed, and finally the bit is extracted from bit_val > > > according to the (unknown) bit_pos, even though relative to the previous > > > operation (if we didn't need to buffer) bit_val is unchanged and bit_pos > > > is just 1 larger. This ends up being quite slow, with tree_node_bools > > > taking 10% of time when streaming in parts of the std module. > > > > > > This patch optimizes this by making tracking of bit_pos and bit_val > > > easier for the compiler. Rather than bit_pos and bit_val being members > > > of the (effectively global) bytes_in/out objects, this patch factors out > > > the bit streaming code/state into separate classes bits_in/out that get > > > constructed locally as needed for bit streaming. Since these objects > > > are now clearly local, the compiler can more easily track their values. > > > > > > And since bit streaming is intended to be batched it's natural for these > > > new classes to be RAII-enabled such that the bit stream is flushed upon > > > destruction. > > > > > > In order to make the most of this improved tracking of bit position, > > > this patch changes parts where we conditionally stream a tree flag > > > to unconditionally stream (the flag or a dummy value). That way > > > the number of bits streamed and the respective bit positions are as > > > statically known as reasonably possible. In lang_decl_bools and > > > lang_type_bools we flush the current bit buffer at the start so that > > > subsequent bit positions are statically known. And in core bools, we > > > can add explicit early exits utilizing invariants that the compiler > > > can't figure out itself (e.g. a tree code can't have both TS_TYPE_COMMON > > > and TS_DECL_COMMON, and if a tree code doesn't have TS_DECL_COMMON then > > > it doesn't have TS_DECL_WITH_VIS). Finally if we're streaming fewer > > > than 4 bits, it's more space efficient to stream them as individual > > > bytes rather than as packed bits (due to the 32-bit buffer). > > > > Oops, this last sentence is wrong. Although the size of the bit buffer > > is 32 bits, upon flushing we rewind unused bytes within the buffer, > > which means streaming 2-8 bits ends up using only one byte not all four. > > So v2 below undoes this pessimization. > > > > > This patch also moves the definitions of the relevant streaming classes > > > into anonymous namespaces so that the compiler can make more informed > > > decisions about inlining their member functions. > > > > > > After this patch, compile time for a simple Hello World using the std > > > module is reduced by 7% with a release compiler. The on-disk size of > > > the std module increases by 0.7% (presumably due to the extra flushing > > > done in lang_decl_bools and lang_type_bools). > > > > The on-disk std module now only grows 0.4% instead of 0.7%. > > > > > > > > The bit stream out performance isn't improved as much as the stream in > > > due to the spans/lengths instrumentation performed on stream out (which > > > probably should be e.g. removed for release builds?) > > > > -- >8 -- > > > > gcc/cp/ChangeLog: > > > > * module.cc: Update comment about classes defined. > > (class data): Enclose in an anonymous namespace. > > (data::calc_crc): Moved from bytes::calc_crc. > > (class bytes): Remove. Move bit_flush to namespace scope. > > (class bytes_in): Enclose in an anonymous namespace. Inherit > > directly from data and adjust accordingly. Move b and bflush > > members to bits_in. > > (class bytes_out): As above. Remove is_set static data member. > > (bit_flush): Moved from class bytes. > > (struct bits_in): Define. > > (struct bits_out): Define. > > (bytes_out::bflush): Moved to bits_out/in. > > (bytes_in::bflush): Likewise > > (bytes_in::bfill): Removed. > > (bytes_out::b): Moved to bits_out/in. > > (bytes_in::b): Likewise. > > (class trees_in): Enclose in an anonymous namespace. > > (class trees_out): Enclose in an anonymous namespace. > > (trees_out:
Re: [PATCH] c++/modules: local class merging [PR99426]
On Tue, 5 Mar 2024, Patrick Palka wrote:
> On Tue, 27 Feb 2024, Patrick Palka wrote:
>
> > On Mon, 26 Feb 2024, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this approach
> > > look reasonable?
> > >
> > > -- >8 --
> > >
> > > One known missing piece in the modules implementation is merging of a
> > > streamed-in local class with the corresponding in-TU version of the
> > > local class. This missing piece turns out to cause a hard-to-reduce
> > > use-after-free GC issue due to the entity_ary not being marked as a GC
> > > root (deliberately), and manifests as a serialization error on stream-in
> > > as in PR99426 (see comment #6 for a reduction). It's also reproducible
> > > on trunk when running the xtreme-header tests without -fno-module-lazy.
> > >
> > > This patch makes us merge such local classes according to their position
> > > within the containing function's definition, similar to how we merge
> > > FIELD_DECLs of a class according to their index in the TYPE_FIELDS
> > > list.
> > >
> > > PR c++/99426
> > >
> > > gcc/cp/ChangeLog:
> > >
> > > * module.cc (merge_kind::MK_local_class): New enumerator.
> > > (merge_kind_name): Update.
> > > (trees_out::chained_decls): Move BLOCK-specific handling
> > > of DECL_LOCAL_DECL_P decls to ...
> > > (trees_out::core_vals) : ... here. Stream
> > > BLOCK_VARS manually.
> > > (trees_in::core_vals) : Stream BLOCK_VARS
> > > manually. Handle deduplicated local classes.
> > > (trees_out::key_local_class): Define.
> > > (trees_in::key_local_class): Define.
> > > (trees_out::get_merge_kind) : Return
> > > MK_local_class for a local class.
> > > (trees_out::key_mergeable) : Use
> > > key_local_class.
> > > (trees_in::key_mergeable) : Likewise.
> > > (trees_in::is_matching_decl): Be flexible with type mismatches
> > > for local entities.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > * g++.dg/modules/xtreme-header-7_a.H: New test.
> > > * g++.dg/modules/xtreme-header-7_b.C: New test.
> >
> > > ---
> > > gcc/cp/module.cc | 167 +++---
> > > .../g++.dg/modules/xtreme-header-7_a.H| 4 +
> > > .../g++.dg/modules/xtreme-header-7_b.C| 6 +
> > > 3 files changed, 149 insertions(+), 28 deletions(-)
> > > create mode 100644 gcc/testsuite/g++.dg/modules/xtreme-header-7_a.H
> > > create mode 100644 gcc/testsuite/g++.dg/modules/xtreme-header-7_b.C
> > >
> > > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > > index fa91c6ff9cb..f77f73a59ed 100644
> > > --- a/gcc/cp/module.cc
> > > +++ b/gcc/cp/module.cc
> > > @@ -2771,6 +2771,7 @@ enum merge_kind
> > >
> > >MK_enum, /* Found by CTX, & 1stMemberNAME. */
> > >MK_keyed, /* Found by key & index. */
> > > + MK_local_class, /* Found by CTX, index. */
> > >
> > >MK_friend_spec, /* Like named, but has a tmpl & args too. */
> > >MK_local_friend, /* Found by CTX, index. */
> > > @@ -2799,7 +2800,7 @@ static char const *const merge_kind_name[MK_hwm] =
> > > "unique", "named", "field", "vtable",/* 0...3 */
> > > "asbase", "partial", "enum", "attached", /* 4...7 */
> > >
> > > -"friend spec", "local friend", NULL, NULL, /* 8...11 */
> > > +"local class", "friend spec", "local friend", NULL, /* 8...11 */
> > > NULL, NULL, NULL, NULL,
> > >
> > > "type spec", "type tmpl spec", /* 16,17 type (template). */
> > > @@ -2928,6 +2929,7 @@ public:
> > >unsigned binfo_mergeable (tree *);
> > >
> > > private:
> > > + tree key_local_class (const merge_key&, tree);
> > >uintptr_t *find_duplicate (tree existing);
> > >void register_duplicate (tree decl, tree existing);
> > >/* Mark as an already diagnosed bad duplicate. */
> > > @@ -3086,6 +3088,7 @@ public:
> > >void binfo_mergeable (tree binfo);
> > >
> > > private:
> > > + void key_local_class (merge_key&, tree, tree);
> > >bool decl_node (tree, walk_kind ref);
> > >void type_node (tree);
> > >void tree_value (tree);
> > > @@ -4952,18 +4955,7 @@ void
> > > trees_out::chained_decls (tree decls)
> > > {
> > >for (; decls; decls = DECL_CHAIN (decls))
> > > -{
> > > - if (VAR_OR_FUNCTION_DECL_P (decls)
> > > - && DECL_LOCAL_DECL_P (decls))
> > > - {
> > > - /* Make sure this is the first encounter, and mark for
> > > - walk-by-value. */
> > > - gcc_checking_assert (!TREE_VISITED (decls)
> > > -&& !DECL_TEMPLATE_INFO (decls));
> > > - mark_by_value (decls);
> > > - }
> > > - tree_node (decls);
> > > -}
> > > +tree_node (decls);
> > >tree_node (NULL_TREE);
> > > }
> > >
> > > @@ -6204,7 +6196,21 @@ trees_out::core_vals (tree t)
> > >
> > >/* DECL_LOCAL_DECL_P decls are first encountered here and
> > > streamed by value. */
> > > - chained_decls (t->block.vars);
> > > + for (tree decls = t->block.vars; decls; de
Re: [PATCH] c++: recalculating local specs via build_extra_args [PR114303]
On Mon, 11 Mar 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk and release branches?
Ping.
>
> -- >8 --
>
> r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts
> first so that we prefer processing a local specialization in an evaluated
> context even if its first use is in an unevaluated context. But this
> means we need to avoid walking a tree that already has extra args/specs
> saved because the list of saved specs appears to be an evaluated
> context. It seems then that we should be calculating the saved specs
> from scratch each time, rather than potentially walking the saved specs
> list from an earlier partial instantiation when calling build_extra_args
> a second time around.
>
> PR c++/114303
>
> gcc/cp/ChangeLog:
>
> * constraint.cc (tsubst_requires_expr): Clear
> REQUIRES_EXPR_EXTRA_ARGS before calling build_extra_args.
> * pt.cc (tsubst_stmt) : Call build_extra_args
> on the new IF_STMT instead of t which might already have
> IF_STMT_EXTRA_ARGS.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp1z/constexpr-if-lambda6.C: New test.
> ---
> gcc/cp/constraint.cc | 1 +
> gcc/cp/pt.cc | 2 +-
> .../g++.dg/cpp1z/constexpr-if-lambda6.C | 16
> 3 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda6.C
>
> diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> index 49de3211d4c..8a3b5d80ba7 100644
> --- a/gcc/cp/constraint.cc
> +++ b/gcc/cp/constraint.cc
> @@ -2362,6 +2362,7 @@ tsubst_requires_expr (tree t, tree args, sat_info info)
>matching or dguide constraint rewriting), in which case we need
>to partially substitute. */
>t = copy_node (t);
> + REQUIRES_EXPR_EXTRA_ARGS (t) = NULL_TREE;
>REQUIRES_EXPR_EXTRA_ARGS (t) = build_extra_args (t, args,
> info.complain);
>return t;
> }
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 8cf0d5b7a8d..37f2392d035 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -18718,7 +18718,7 @@ tsubst_stmt (tree t, tree args, tsubst_flags_t
> complain, tree in_decl)
> IF_COND (stmt) = IF_COND (t);
> THEN_CLAUSE (stmt) = THEN_CLAUSE (t);
> ELSE_CLAUSE (stmt) = ELSE_CLAUSE (t);
> - IF_STMT_EXTRA_ARGS (stmt) = build_extra_args (t, args, complain);
> + IF_STMT_EXTRA_ARGS (stmt) = build_extra_args (stmt, args, complain);
> add_stmt (stmt);
> break;
> }
> diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda6.C
> b/gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda6.C
> new file mode 100644
> index 000..038c2a41210
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if-lambda6.C
> @@ -0,0 +1,16 @@
> +// PR c++/114303
> +// { dg-do compile { target c++17 } }
> +
> +struct A { static constexpr bool value = true; };
> +
> +int main() {
> + [](auto x1) {
> +return [&](auto) {
> + return [&](auto x3) {
> +if constexpr (decltype(x3)::value) {
> + static_assert(decltype(x1)::value);
> +}
> + }(A{});
> +}(0);
> + }(A{});
> +}
> --
> 2.44.0.165.ge09f1254c5
>
>
[pushed] c++/modules testsuite: fix a couple of dg-module-do directives
Tested on x86_64-pc-linux-gnu, committed to trunk as obvious.
-- >8 --
gcc/testsuite/ChangeLog:
* g++.dg/modules/decltype-1_a.C: Add missing } to dg-module-do
directive.
* g++.dg/modules/lambda-5_a.C: Likewise.
---
gcc/testsuite/g++.dg/modules/decltype-1_a.C | 2 +-
gcc/testsuite/g++.dg/modules/lambda-5_a.C | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/g++.dg/modules/decltype-1_a.C
b/gcc/testsuite/g++.dg/modules/decltype-1_a.C
index ca66e8b598a..e4202a26de4 100644
--- a/gcc/testsuite/g++.dg/modules/decltype-1_a.C
+++ b/gcc/testsuite/g++.dg/modules/decltype-1_a.C
@@ -1,5 +1,5 @@
// PR c++/105322
-// { dg-module-do link
+// { dg-module-do link }
// { dg-additional-options -fmodules-ts }
// { dg-module-cmi pr105322.Decltype }
diff --git a/gcc/testsuite/g++.dg/modules/lambda-5_a.C
b/gcc/testsuite/g++.dg/modules/lambda-5_a.C
index 6b589d4965c..37d0e77b1e1 100644
--- a/gcc/testsuite/g++.dg/modules/lambda-5_a.C
+++ b/gcc/testsuite/g++.dg/modules/lambda-5_a.C
@@ -1,5 +1,5 @@
// PR c++/105322
-// { dg-module-do link
+// { dg-module-do link }
// { dg-additional-options -fmodules-ts }
// { dg-module-cmi pr105322.Lambda }
--
2.44.0.368.gc75fd8d815
Re: [PATCH] c++: problematic assert in reference_binding [PR113141]
On Thu, 7 Mar 2024, Jason Merrill wrote:
> On 1/29/24 17:42, Patrick Palka wrote:
> > On Mon, 29 Jan 2024, Patrick Palka wrote:
> >
> > > On Fri, 26 Jan 2024, Jason Merrill wrote:
> > >
> > > > On 1/26/24 17:11, Jason Merrill wrote:
> > > > > On 1/26/24 16:52, Jason Merrill wrote:
> > > > > > On 1/25/24 14:18, Patrick Palka wrote:
> > > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > > > > > OK for trunk/13? This isn't a very satisfactory fix, but at least
> > > > > > > it safely fixes these testcases I guess. Note that there's
> > > > > > > implementation disagreement about the second testcase, GCC always
> > > > > > > accepted it but Clang/MSVC/icc reject it.
> > > > > >
> > > > > > Because of trying to initialize int& from {c}; removing the extra
> > > > > > braces
> > > > > > makes it work everywhore.
> > > > > >
> > > > > > https://eel.is/c++draft/dcl.init#list-3.10 says that we always
> > > > > > generate a
> > > > > > prvalue in this case, so perhaps we shouldn't recalculate if the
> > > > > > initializer is an init-list?
> > > > >
> > > > > ...but it seems bad to silently bind a const int& to a prvalue instead
> > > > > of
> > > > > directly to the reference returned by the operator, as clang does if
> > > > > we add
> > > > > const to the second testcase, so I think there's a defect in the
> > > > > standard
> > > > > here.
> > > >
> > > > Perhaps bullet 3.9 should change to "...its referenced type is
> > > > reference-related to E or scalar, ..."
> > > >
> > > > > Maybe for now also disable the maybe_valid heuristics in the case of
> > > > > an
> > > > > init-list?
> > > > >
> > > > > > The first testcase is special because it's a C-style cast; seems
> > > > > > like the
> > > > > > maybe_valid = false heuristics should be disabled if c_cast_p.
> > >
> > > Thanks a lot for the pointers. IIUC c_cast_p and
> > > LOOKUP_SHORTCUT_BAD_CONVS
> > > should already be mutually exclusive, since the latter is set only when
> > > computing argument conversions, so it shouldn't be necessary to check
> > > c_cast_p.
> > >
> > > I suppose we could disable the heuristic for init-lists, but after some
> > > digging I noticed that the heuristics were originally in same spot they
> > > are now until r5-601-gd02f620dc0bb3b moved them to get checked after
> > > the recursive recalculation case in reference_binding, returning a bad
> > > conversion instead of NULL. (Then in r13-1755-g68f37670eff0b872 I moved
> > > them back; IIRC that's why I felt confident that moving the checks was
> > > safe.)
> > > Thus we didn't always accept the second testcase, we only started doing so
> > > in
> > > GCC 5: https://godbolt.org/z/6nsEW14fh (sorry for missing this and saying
> > > we
> > > always accepted it)
> > >
> > > And indeed the current order of checks seems consistent with that of
> > > [dcl.init.ref]/5. So I wonder if we don't instead want to "complete"
> > > the NULL-to-bad-conversion adjustment in r5-601-gd02f620dc0bb3b and
> > > do:
> > >
> > > gcc/cp/ChangeLog:
> > >
> > > * call.cc (reference_binding): Set bad_p according to
> > > maybe_valid_p in the recursive case as well. Remove
> > > redundant gcc_assert.
> > >
> > > diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
> > > index 9de0d77c423..c4158b2af37 100644
> > > --- a/gcc/cp/call.cc
> > > +++ b/gcc/cp/call.cc
> > > @@ -2033,8 +2033,8 @@ reference_binding (tree rto, tree rfrom, tree expr,
> > > bool c_cast_p, int flags,
> > > sflags, complain);
> > > if (!new_second)
> > > return bad_direct_conv ? bad_direct_conv : nullptr;
> > > + t->bad_p = !maybe_valid_p;
> >
> > Oops, that should be |= not =.
> >
> > > > Perhaps bullet 3.9 should change to "...its referenced type is
> > > > reference-related to E or scalar, ..."
> > > conv = merge_conversion_sequences (t, new_second);
> > > - gcc_assert (maybe_valid_p || conv->bad_p);
> > > return conv;
> > > }
> > > }
> > >
> > > This'd mean we'd go back to rejecting the second testcase (only the
> > > call, not the direct-init, interestingly enough), but that seems to be
> >
> > In the second testcase, with the above fix initialize_reference silently
> > returns error_mark_node for the direct-init without issuing a
> > diagnostic, because in the error path convert_like doesn't find anything
> > wrong with the bad conversion. So more changes need to be made if we
> > want to set bad_p in the recursive case of reference_binding it seems;
> > dunno if that's the path we want to go down?
> >
> > On the other hand, disabling the badness checks in certain cases seems
> > to be undesirable as well, since AFAICT their current position is
> > consistent with [dcl.init.ref]/5?
> >
> > So I wonder if we should just go with the safest thing at this stage,
> > which would be the original patch that removes the problematic assert?
>
> I still think the as
[PATCH] c++/modules: Setup aliases imported from modules [PR106820]
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
I wonder if more generally we need to be doing more work when importing
definitions from header units especially to handle all the work that
'make_rtl_for_nonlocal_decl' and 'rest_of_decl_compilation' would have
been performing. But this patch fixes at least one missing step.
PR c++/106820
gcc/cp/ChangeLog:
* module.cc (trees_in::decl_value): Assemble alias when needed.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr106820_a.H: New test.
* g++.dg/modules/pr106820_b.C: New test.
Signed-off-by: Nathaniel Shead
---
gcc/cp/module.cc | 9 +
gcc/testsuite/g++.dg/modules/pr106820_a.H | 5 +
gcc/testsuite/g++.dg/modules/pr106820_b.C | 8
3 files changed, 22 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/modules/pr106820_a.H
create mode 100644 gcc/testsuite/g++.dg/modules/pr106820_b.C
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 8aab9ea0bae..b4e3b38c6fe 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -217,6 +217,7 @@ Classes used:
#include "dumpfile.h"
#include "bitmap.h"
#include "cgraph.h"
+#include "varasm.h"
#include "tree-iterator.h"
#include "cpplib.h"
#include "mkdeps.h"
@@ -8302,6 +8303,14 @@ trees_in::decl_value ()
if (state->is_header ()
&& decl_tls_wrapper_p (decl))
note_vague_linkage_fn (decl);
+
+ /* Setup aliases for the declaration. */
+ if (tree alias = lookup_attribute ("alias", DECL_ATTRIBUTES (decl)))
+ {
+ alias = TREE_VALUE (TREE_VALUE (alias));
+ alias = get_identifier (TREE_STRING_POINTER (alias));
+ assemble_alias (decl, alias);
+ }
}
else
{
diff --git a/gcc/testsuite/g++.dg/modules/pr106820_a.H
b/gcc/testsuite/g++.dg/modules/pr106820_a.H
new file mode 100644
index 000..7d32d4e5fc3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/pr106820_a.H
@@ -0,0 +1,5 @@
+// PR c++/106820
+// { dg-additional-options "-fmodules-ts" }
+// { dg-module-cmi {} }
+
+static int __gthrw___pthread_key_create() __attribute__((__weakref__("foo")));
diff --git a/gcc/testsuite/g++.dg/modules/pr106820_b.C
b/gcc/testsuite/g++.dg/modules/pr106820_b.C
new file mode 100644
index 000..247fe26e778
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/pr106820_b.C
@@ -0,0 +1,8 @@
+// PR c++/106820
+// { dg-additional-options "-fmodules-ts" }
+
+import "pr106820_a.H";
+
+int main() {
+ __gthrw___pthread_key_create();
+}
--
2.43.2
Re: [PATCH] aarch64: Add +lse128 architectural extension command-line flag
On Mär 15 2024, Victor Do Nascimento wrote: > \ No newline at end of file Please fix that. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: [PATCH] aarch64: Add +lse128 architectural extension command-line flag
Victor Do Nascimento writes:
> Given how, at present, the choice of using LSE128 atomic instructions
> by the toolchain is delegated to run-time selection in the form of
> Libatomic ifuncs, responsible for querying target support, the
> `+lse128' target architecture compile-time flag is absent from GCC.
>
> This, however, contrasts with the Binutils implementation, which gates
> LSE128 instructions behind the `+lse128' flag. This can lead to
> problems in GCC for certain use-cases. One such example is in the use
> of inline assembly, whereby the inability of enabling the feature in
> the command-line prevents the compiler from automatically issuing the
> necessary LSE128 `.arch' directive.
>
> This patch therefore brings GCC into alignment with LLVM and Binutils
> in adding support for the `+lse128' architectural extension flag.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-option-extensions.def: Add LSE128
> AARCH64_OPT_EXTENSION, adding it as a dependency for the D128
> feature.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/lse128-flag.c: New.
> * gcc.target/aarch64/cpunative/info_23: Likewise.
> * gcc.target/aarch64/cpunative/native_cpu_23.c: Likewise.
The new extension should be documented in doc/invoke.texi.
> ---
> gcc/config/aarch64/aarch64-option-extensions.def | 4 +++-
> gcc/testsuite/gcc.target/aarch64/cpunative/info_23| 8
> .../gcc.target/aarch64/cpunative/native_cpu_23.c | 11 +++
> gcc/testsuite/gcc.target/aarch64/lse128-flag.c| 10 ++
> 4 files changed, 32 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/aarch64/cpunative/info_23
> create mode 100644 gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_23.c
> create mode 100644 gcc/testsuite/gcc.target/aarch64/lse128-flag.c
>
> diff --git a/gcc/config/aarch64/aarch64-option-extensions.def
> b/gcc/config/aarch64/aarch64-option-extensions.def
> index 1a3b91c68cf..ac54b899a06 100644
> --- a/gcc/config/aarch64/aarch64-option-extensions.def
> +++ b/gcc/config/aarch64/aarch64-option-extensions.def
> @@ -275,7 +275,9 @@ AARCH64_OPT_EXTENSION("mops", MOPS, (), (), (), "")
>
> AARCH64_OPT_EXTENSION("cssc", CSSC, (), (), (), "cssc")
>
> -AARCH64_OPT_EXTENSION("d128", D128, (), (), (), "d128")
> +AARCH64_OPT_EXTENSION("lse128", LSE128, (LSE), (), (), "lse128")
> +
> +AARCH64_OPT_EXTENSION("d128", D128, (LSE128), (), (), "d128")
>
> AARCH64_OPT_EXTENSION("the", THE, (), (), (), "the")
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/info_23
> b/gcc/testsuite/gcc.target/aarch64/cpunative/info_23
> new file mode 100644
> index 000..d77c25d2f61
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/cpunative/info_23
> @@ -0,0 +1,8 @@
> +processor: 0
> +BogoMIPS : 100.00
> +Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 asimddp atomics
> lse128
> +CPU implementer : 0xfe
> +CPU architecture: 8
> +CPU variant : 0x0
> +CPU part : 0xd08
> +CPU revision : 2
> \ No newline at end of file
> diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_23.c
> b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_23.c
> new file mode 100644
> index 000..8a1e235d8ab
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_23.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile { target { { aarch64*-*-linux*} && native } } } */
> +/* { dg-set-compiler-env-var GCC_CPUINFO
> "$srcdir/gcc.target/aarch64/cpunative/info_23" } */
> +/* { dg-additional-options "-mcpu=native" } */
> +
> +int main()
> +{
> + return 0;
> +}
> +
> +/* { dg-final { scan-assembler {\.arch
> armv8-a\+dotprod\+crc\+crypto\+lse128} } } */
> +/* Test one where lse128 is available and so should be emitted. */
> diff --git a/gcc/testsuite/gcc.target/aarch64/lse128-flag.c
> b/gcc/testsuite/gcc.target/aarch64/lse128-flag.c
> new file mode 100644
> index 000..71339c3af6d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/lse128-flag.c
> @@ -0,0 +1,10 @@
> +/* { dg-do compile { target { aarch64*-*-*} } } */
> +/* { dg-additional-options "-march=armv9.4-a+lse128" } */
> +
> +int main()
> +{
> + return 0;
> +}
> +
> +/* { dg-final { scan-assembler {\.arch armv9\.4-a\+crc\+lse128} } } */
> +/* Test a normal looking procinfo. */
Not sure I understand the comment. Is procinfo part of this test?
Looks good otherwise.
Thanks,
Richard
Re: [PATCH] libatomic: Fix build for --disable-gnu-indirect-function [PR113986]
Hi Richard, > This description is too brief for me. Could you say in detail how the > new scheme works? E.g. the description doesn't explain: > > -if ARCH_AARCH64_HAVE_LSE128 > -AM_CPPFLAGS = -DHAVE_FEAT_LSE128 > -endif That is not needed because we can include auto-config.h in atomic_16.S. I needed this for HAVE_IFUNC, but then we redefine HAVE_FEAT_LSE128... > And what's the purpose of ARCH_AARCH64_HAVE_LSE128 after this change? None. I've removed the makefile leftovers in v2. > Is the indirection via ALIAS2 necessary? Couldn't ENTRY just define > the __atomic_* symbols directly, as non-hidden, if we remove the > libat_ prefix? That would make it easier to ensure that the lists > are kept up-to-date. Yes, we need both the libat_ symbol as well as the __atomic_ variant in this case. One is for internal calls, the other for external. I have a separate cleanup patch which hides the extra alias in ENTRY and removes all the libat prefixes. However while trivial, that feels more like a stage 1 patch. > Shouldn't we skip the ENTRY_FEAT functions and existing aliases > if !HAVE_IFUNC? Yes, that's relatively easy, I've added HAVE_FEAT_LSE2 for that. Also we skip the aliases at the end. > I think it'd be worth (as a prepatch) splitting the file into two > #included subfiles, one that contains the base AArch64 routines and one > that contains the optimised versions. The former would then be #included > for all builds while the latter would be specific to HAVE_IFUNC. That sounds like a complete rewrite. We might as well emit our own ifuncs at that point and avoid all of the workarounds needed to fit in the framework of libatomic. So for v2 I have kept things simple and just focus on fixing the bug. Cheers, Wilco v2: Fix libatomic build to support --disable-gnu-indirect-function on AArch64. Always build atomic_16.S, add aliases to the __atomic_ functions if !HAVE_IFUNC. Include auto-config.h in atomic_16.S to avoid having to pass defines via makefiles. Fix build if HWCAP_ATOMICS/CPUID are not defined. Passes regress and bootstrap, OK for commit? libatomic: PR target/113986 * Makefile.in: Regenerated. * Makefile.am: Make atomic_16.S not depend on HAVE_IFUNC. Remove predefine of HAVE_FEAT_LSE128. * acinclude.m4: Remove ARCH_AARCH64_HAVE_LSE128. * configure: Regenerated. * config/linux/aarch64/atomic_16.S: Add __atomic_ aliases if !HAVE_IFUNC. * config/linux/aarch64/host-config.h: Correctly handle !HAVE_IFUNC. Add defines for HWCAP_ATOMICS and HWCAP_CPUID. --- diff --git a/libatomic/Makefile.am b/libatomic/Makefile.am index d49c44c7d5fbe83061fddd1f8ef4813a39eb1b8b..980677f353345c050f6cef2d57090360216c56cf 100644 --- a/libatomic/Makefile.am +++ b/libatomic/Makefile.am @@ -130,12 +130,8 @@ libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix _$(s)_.lo,$(SIZEOBJS))) ## On a target-specific basis, include alternates to be selected by IFUNC. if HAVE_IFUNC if ARCH_AARCH64_LINUX -if ARCH_AARCH64_HAVE_LSE128 -AM_CPPFLAGS = -DHAVE_FEAT_LSE128 -endif IFUNC_OPTIONS = -march=armv8-a+lse libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS))) -libatomic_la_SOURCES += atomic_16.S endif if ARCH_ARM_LINUX @@ -155,6 +151,10 @@ libatomic_la_LIBADD += $(addsuffix _16_1_.lo,$(SIZEOBJS)) \ endif endif +if ARCH_AARCH64_LINUX +libatomic_la_SOURCES += atomic_16.S +endif + libatomic_convenience_la_SOURCES = $(libatomic_la_SOURCES) libatomic_convenience_la_LIBADD = $(libatomic_la_LIBADD) diff --git a/libatomic/Makefile.in b/libatomic/Makefile.in index 11c8ec7ba15ba7da5ef55e90bd836317bc270061..d9d529bc502d4ce7b9997640d5f40f5d5cc1232c 100644 --- a/libatomic/Makefile.in +++ b/libatomic/Makefile.in @@ -90,17 +90,17 @@ build_triplet = @build@ host_triplet = @host@ target_triplet = @target@ @ARCH_AARCH64_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_1 = $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS))) -@ARCH_AARCH64_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_2 = atomic_16.S -@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_3 = $(foreach \ +@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@am__append_2 = $(foreach \ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ s,$(SIZES),$(addsuffix \ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ _$(s)_1_.lo,$(SIZEOBJS))) \ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ $(addsuffix \ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ _8_2_.lo,$(SIZEOBJS)) \ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@ tas_1_2_.lo -@ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@am__append_4 = $(addsuffix _8_1_.lo,$(SIZEOBJS)) -@ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@am__append_5 = $(addsuffix _16_1_.lo,$(SIZEOBJS)) \ +@ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@am__append_3 = $(addsuffix _8_1_.lo,$(SIZEOBJS)) +@ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@am__append_4 = $(addsuffix _16_1_.lo,$(SIZEOBJS)) \ @ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@ $(addsuffix _16_2_.lo,$(SIZEOBJS)) +@ARCH_AARCH64_LINUX_TRUE@am__append_
Re: [PATCH 1/2] libstdc++: Add dg-require-cpp-feature-test to test feature test macros
Pushed to trunk.
On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely wrote:
>
> Thoughts? There are only a few uses for this presently, but I can see it
> being useful often in future. The library exposes which features it
> supports in a standardized way, so we can use those in tests to skip
> tests for features that aren't available on all targets.
>
> The obvious downside is that it becomes harder to notice if a particular
> feature is missing on all targets, because we don't get FAILs we just
> skip all tests as UNSUPPORTED. And the checks for whether
> correctly defines the macro become redundant, because the test won't
> even get run if it doesn't. But we won't use this dg-require for many
> tests, only the ones where support is target-dependent because it relies
> on something non-standard or not available on all targets (like
> nl_langinfo_l or libbacktrace).
>
> -- >8 -
>
> This adds a new dejagnu directive which can be used to make a test
> depend on a feature test macro such as __cpp_lib_text_encoding. This is
> mroe flexible than writing a new dg-require-xxx for each feature.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/lib/dg-options.exp (dg-require-cpp-feature-test):
> New proc.
> * testsuite/lib/libstdc++.exp (check_v3_target_cpp_feature_test):
> New proc.
> * testsuite/std/text_encoding/cons.cc: Use new directive to skip
> the test if the __cpp_lib_text_encoding feature test macro is
> not defined.
> * testsuite/std/text_encoding/requirements.cc: Likewise.
> ---
> libstdc++-v3/testsuite/lib/dg-options.exp | 9 +
> libstdc++-v3/testsuite/lib/libstdc++.exp | 15 +++
> libstdc++-v3/testsuite/std/text_encoding/cons.cc | 1 +
> .../testsuite/std/text_encoding/requirements.cc | 3 ++-
> 4 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp
> b/libstdc++-v3/testsuite/lib/dg-options.exp
> index 00ca678a53a..802bfc0b492 100644
> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
> +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
> @@ -277,6 +277,15 @@ proc dg-require-target-fs-lwt { args } {
> return
> }
>
> +proc dg-require-cpp-feature-test { n args } {
> +if { ![ check_v3_target_cpp_feature_test $args ] } {
> + upvar dg-do-what dg-do-what
> + set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
> + return
> +}
> +return
> +}
> +
> proc add_options_for_no_pch { flags } {
> # Remove any inclusion of bits/stdc++.h from the options.
> regsub -all -- "-include bits/stdc...h" $flags "" flags
> diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp
> b/libstdc++-v3/testsuite/lib/libstdc++.exp
> index 7466fb51c58..2b31c950826 100644
> --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> @@ -1134,6 +1134,21 @@ proc v3_check_preprocessor_condition { name cond { inc
> "" } } {
> return [v3_try_preprocess name $code $flags]
> }
>
> +# Return 1 if libstdc++ defines macro for the current target, 0 otherwise.
> +proc check_v3_target_cpp_feature_test { cond } {
> +global cxxflags
> +set cxxflags_saved $cxxflags
> +# Use the latest standard, so that all feature test macros are defined.
> +# We need to do it here, because this check happens before v3-dg-runtest
> +# runs its loop to test multiple times with different -std options.
> +# This should be updated when a new -std is added.
> +set cxxflags "$cxxflags -std=gnu++26"
> +set inc "#include "
> +set result [v3_check_preprocessor_condition cpp_feature_test "$cond"
> $inc]
> +set cxxflags $cxxflags_saved
> +return $result
> +}
> +
> # Return 1 if Debug Mode is active, 0 otherwise.
> proc check_v3_target_debug_mode { } {
> global cxxflags
> diff --git a/libstdc++-v3/testsuite/std/text_encoding/cons.cc
> b/libstdc++-v3/testsuite/std/text_encoding/cons.cc
> index 8fcc2ec8c3b..4196e32ea8b 100644
> --- a/libstdc++-v3/testsuite/std/text_encoding/cons.cc
> +++ b/libstdc++-v3/testsuite/std/text_encoding/cons.cc
> @@ -1,4 +1,5 @@
> // { dg-do run { target c++26 } }
> +// { dg-require-cpp-feature-test "__cpp_lib_text_encoding" }
>
> #include
> #include
> diff --git a/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
> b/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
> index a1d5d6baee1..3889b250688 100644
> --- a/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
> +++ b/libstdc++-v3/testsuite/std/text_encoding/requirements.cc
> @@ -1,4 +1,5 @@
> // { dg-do compile { target c++26 } }
> +// { dg-require-cpp-feature-test __cpp_lib_text_encoding }
> // { dg-add-options no_pch }
>
> #include
>
Re: [PATCH 2/2] libstdc++: Replace stacktrace effective target with feature test
Pushed to trunk.
On Sat, 23 Mar 2024 at 00:22, Jonathan Wakely wrote:
>
> And this replaces an existing custom dg-require- directive with a use of
> the new one that checks for a standard feature test macro. I didn't see
> any other existing dg-require-xxx directives that can be replaced like
> this.
>
> -- >8 --
>
> Remove the dejagnu code for checking whether std::stacktrace is supported
> and just use the new dg-require-cpp-feature-test directive to check for
> __cpp_lib_stacktrace instead.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/19_diagnostics/stacktrace/current.cc: Check for
> __cpp_lib_stacktrace instead of check for stacktrace ET.
> * testsuite/19_diagnostics/stacktrace/entry.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/hash.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/output.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/synopsis.cc: Likewise.
> * testsuite/19_diagnostics/stacktrace/version.cc: Likewise.
> * testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc:
> Likewise.
> * testsuite/lib/libstdc++.exp (check_effective_target_stacktrace):
> Remove.
> ---
> .../testsuite/19_diagnostics/stacktrace/current.cc| 2 +-
> libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc | 2 +-
> libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc | 2 +-
> .../testsuite/19_diagnostics/stacktrace/output.cc | 2 +-
> .../testsuite/19_diagnostics/stacktrace/stacktrace.cc | 2 +-
> .../testsuite/19_diagnostics/stacktrace/synopsis.cc | 2 +-
> .../testsuite/19_diagnostics/stacktrace/version.cc| 2 +-
> .../23_containers/vector/debug/assign4_backtrace_neg.cc | 2 +-
> libstdc++-v3/testsuite/lib/libstdc++.exp | 8
> 9 files changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
> index a27836d27af..b1af5f74fb2 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/current.cc
> @@ -1,6 +1,6 @@
> // { dg-options "-lstdc++exp" }
> // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
>
> #include
> #include
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
> index ab016d56400..bb348ebef8f 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc
> @@ -1,6 +1,6 @@
> // { dg-options "-lstdc++exp" }
> // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
>
> #include
> #include "testsuite_hooks.h"
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
> index 21705098ff0..2176596ae5c 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/hash.cc
> @@ -1,6 +1,6 @@
> // { dg-options "-lstdc++exp" }
> // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
>
> #include
> #include
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
> index 67f1e0cebaf..e27aea1f508 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/output.cc
> @@ -1,6 +1,6 @@
> // { dg-options "-lstdc++exp" }
> // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
> // { dg-add-options no_pch }
>
> #include
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
> index 5dfa76951df..070c4157471 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
> +++ b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc
> @@ -1,6 +1,6 @@
> // { dg-options "-lstdc++exp" }
> // { dg-do run { target c++23 } }
> -// { dg-require-effective-target stacktrace }
> +// { dg-require-cpp-feature-test __cpp_lib_stacktrace }
>
> #include
> #include "testsuite_allocator.h"
> diff --git a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/synopsis.cc
> b/libstdc++-v3/testsuite/19_diagnostics/stacktrace/synopsis.cc
> index 9e775b86ac9..b99d382ec26 100644
> --- a/libstdc++-v3/testsuite/19_diagnostics/stacktrace/synopsis.cc
> +++ b/libstdc++-v3/testsuite/19_
Re: [PATCH 1/2] libstdc++: fix _V badname in
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/generator: Fix _V badname.
OK for trunk, thanks.
> ---
> libstdc++-v3/include/std/generator | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/libstdc++-v3/include/std/generator
> b/libstdc++-v3/include/std/generator
> index 87983ee5e7c6..2d1dcced1e57 100644
> --- a/libstdc++-v3/include/std/generator
> +++ b/libstdc++-v3/include/std/generator
> @@ -76,14 +76,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> * @headerfile generator
> * @since C++23
> */
> - template
> + template
> class generator;
>
>/// @cond undocumented
>namespace __gen
>{
> /// _Reference type for a generator whose reference (first argument) and
> -/// value (second argument) types are _Ref and _V.
> +/// value (second argument) types are _Ref and _Val.
> template
> using _Reference_t = __conditional_t,
> _Ref&&, _Ref>;
> @@ -642,14 +642,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>} // namespace __gen
>/// @endcond
>
> - template
> + template
> class generator
> - : public ranges::view_interface>
> + : public ranges::view_interface>
> {
> - using _Value = __conditional_t, remove_cvref_t<_Ref>,
> _V>;
> + using _Value = __conditional_t,
> +remove_cvref_t<_Ref>,
> +_Val>;
>static_assert(__gen::_Cv_unqualified_object<_Value>,
> "Generator value must be a cv-unqualified object type");
> - using _Reference = __gen::_Reference_t<_Ref, _V>;
> + using _Reference = __gen::_Reference_t<_Ref, _Val>;
>static_assert(is_reference_v<_Reference>
> || (__gen::_Cv_unqualified_object<_Reference>
> && copy_constructible<_Reference>),
> @@ -737,8 +739,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>bool _M_began = false;
> };
>
> - template
> -struct generator<_Ref, _V, _Alloc>::_Iterator
> + template
> +struct generator<_Ref, _Val, _Alloc>::_Iterator
> {
>using value_type = _Value;
>using difference_type = ptrdiff_t;
> --
> 2.44.0
>
Re: [PATCH 2/2] libstdc++: fix generator iterator operator* return type
On Sat, 23 Mar 2024 at 15:47, Arsen Arsenović wrote:
>
> Per the standard, the return type of a generators ranges iterator op*
> should be the reference type rather than the yielded type.
>
> The yielded type was used here by mistake.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/generator (generator::_Iterator::operator*): Fix
> return type.
> * testsuite/24_iterators/range_generators/iter_deref_return.cc:
> New test.
> ---
> libstdc++-v3/include/std/generator| 4 +--
> .../range_generators/iter_deref_return.cc | 34 +++
> 2 files changed, 36 insertions(+), 2 deletions(-)
> create mode 100644
> libstdc++-v3/testsuite/24_iterators/range_generators/iter_deref_return.cc
>
> diff --git a/libstdc++-v3/include/std/generator
> b/libstdc++-v3/include/std/generator
> index 2d1dcced1e57..789016b5a883 100644
> --- a/libstdc++-v3/include/std/generator
> +++ b/libstdc++-v3/include/std/generator
> @@ -773,12 +773,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>operator++(int)
>{ this->operator++(); }
>
> - yielded
> + _Reference
>operator*()
> const noexcept(is_nothrow_move_constructible_v<_Reference>)
>{
> auto& __p = this->_M_coro.promise();
> - return static_cast(*__p._M_value());
> + return static_cast<_Reference>(*__p._M_value());
>}
>
> private:
> diff --git
> a/libstdc++-v3/testsuite/24_iterators/range_generators/iter_deref_return.cc
> b/libstdc++-v3/testsuite/24_iterators/range_generators/iter_deref_return.cc
> new file mode 100644
> index ..7bdbf4d489ec
> --- /dev/null
> +++
> b/libstdc++-v3/testsuite/24_iterators/range_generators/iter_deref_return.cc
> @@ -0,0 +1,34 @@
> +// { dg-do compile { target c++23 } }
> +// Copyright (C) 2023-2024 Free Software Foundation, Inc.
Just 2024 here.
> +//
> +// This file is part of the GNU ISO C++ Library. This library is free
> +// software; you can redistribute it and/or modify it under the
> +// terms of the GNU General Public License as published by the
> +// Free Software Foundation; either version 3, or (at your option)
> +// any later version.
> +
> +// This library is distributed in the hope that it will be useful,
> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +// GNU General Public License for more details.
> +
> +// Under Section 7 of GPL version 3, you are granted additional
> +// permissions described in the GCC Runtime Library Exception, version
> +// 3.1, as published by the Free Software Foundation.
> +
> +// You should have received a copy of the GNU General Public License and
> +// a copy of the GCC Runtime Library Exception along with this program;
> +// see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
> +//
[committed] testsuite: Add -Wno-psabi to pr113126.c test
Hi!
I've missed
FAIL: gcc.dg/torture/pr113126.c -O0 (test for excess errors)
etc. regressions on i686-linux since January. The problem is obvious
Excess errors:
.../gcc/testsuite/gcc.dg/torture/pr113126.c:11:1: warning: MMX vector return
without MMX enabled changes the ABI [-Wpsabi]
and I've added -Wno-psabi to dg-additional-options to fix that up.
Tested on x86_64-linux with
make check-gcc
RUNTESTFLAGS='--target_board=unix\{-m32/-mno-sse/-mno-mmx,-m32,-m64\}
dg-torture.exp=pr113126.c'
and committed to trunk as obvious.
2024-03-26 Jakub Jelinek
* gcc.dg/tort-re/pr113126.c: Add -Wno-psabi as dg-additional-options.
--- gcc/testsuite/gcc.dg/torture/pr113126.c.jj 2024-01-12 10:07:58.328849767
+0100
+++ gcc/testsuite/gcc.dg/torture/pr113126.c 2024-03-26 11:24:04.055734511
+0100
@@ -1,4 +1,5 @@
/* { dg-do compile } */
+/* { dg-additional-options "-Wno-psabi" } */
typedef float __attribute__((__vector_size__ (8))) F;
typedef double __attribute__((__vector_size__ (16))) G;
Jakub
Re: [PATCH] fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR111151]
On Tue, 26 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> As I've tried to explain in the comments, the extract_muldiv_1
> MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR.
> If the multiplication is done in unsigned type or in signed
> type with -fwrapv, it is fairly obvious that max (a, b) * c
> in many cases isn't equivalent to max (a * c, b * c) (or min if c is
> negative) due to overflows, but even for signed with undefined overflow,
> the optimization could turn something without UB in it (where
> say a * c invokes UB, but max (or min) picks the other operand where
> b * c doesn't).
> As for division/modulo, I think it is in most cases safe, except if
> the problematic INT_MIN / -1 case could be triggered, but we can
> just punt for MAX_EXPR because for MIN_EXPR if one operand is INT_MIN,
> we'd pick that operand already. It is just for completeness, match.pd
> already has an optimization which turns x / -1 into -x, so the division
> by zero is mostly theoretical. That is also why in the testcase the
> i case isn't actually miscompiled without the patch, while the c and f
> cases are.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, additionally
> bootstrapped/regtested on x86_64-linux with statistics gathering when
> the patch changes behavior and it is solely on the new testcase and
> nothing else during the bootstrap/regtest. Ok for trunk?
OK.
Thanks,
Richard.
> 2024-03-26 Jakub Jelinek
>
> PR middle-end/51
> * fold-const.cc (extract_muldiv_1) : Punt for
> MULT_EXPR altogether, or for MAX_EXPR if c is -1.
>
> * gcc.c-torture/execute/pr51.c: New test.
>
> --- gcc/fold-const.cc.jj 2024-03-11 09:42:04.544588951 +0100
> +++ gcc/fold-const.cc 2024-03-25 11:48:12.133625285 +0100
> @@ -7104,6 +7104,27 @@ extract_muldiv_1 (tree t, tree c, enum t
>if (TYPE_UNSIGNED (ctype) != TYPE_UNSIGNED (type))
> break;
>
> + /* Punt for multiplication altogether.
> + MAX (1U + INT_MAX, 1U) * 2U is not equivalent to
> + MAX ((1U + INT_MAX) * 2U, 1U * 2U), the former is
> + 0U, the latter is 2U.
> + MAX (INT_MIN / 2, 0) * -2 is not equivalent to
> + MIN (INT_MIN / 2 * -2, 0 * -2), the former is
> + well defined 0, the latter invokes UB.
> + MAX (INT_MIN / 2, 5) * 5 is not equivalent to
> + MAX (INT_MIN / 2 * 5, 5 * 5), the former is
> + well defined 25, the latter invokes UB. */
> + if (code == MULT_EXPR)
> + break;
> + /* For division/modulo, punt on c being -1 for MAX, as
> + MAX (INT_MIN, 0) / -1 is not equivalent to
> + MIN (INT_MIN / -1, 0 / -1), the former is well defined
> + 0, the latter invokes UB (or for -fwrapv is INT_MIN).
> + MIN (INT_MIN, 0) / -1 already invokes UB, so the
> + transformation won't make it worse. */
> + else if (tcode == MAX_EXPR && integer_minus_onep (c))
> + break;
> +
>/* MIN (a, b) / 5 -> MIN (a / 5, b / 5) */
>sub_strict_overflow_p = false;
>if ((t1 = extract_muldiv (op0, c, code, wide_type,
> --- gcc/testsuite/gcc.c-torture/execute/pr51.c.jj 2024-03-25
> 11:50:27.199744988 +0100
> +++ gcc/testsuite/gcc.c-torture/execute/pr51.c2024-03-26
> 10:41:51.003384032 +0100
> @@ -0,0 +1,21 @@
> +/* PR middle-end/51 */
> +
> +int
> +main ()
> +{
> + unsigned a = (1U + __INT_MAX__) / 2U;
> + unsigned b = 1U;
> + unsigned c = (a * 2U > b * 2U ? a * 2U : b * 2U) * 2U;
> + if (c != 0U)
> +__builtin_abort ();
> + int d = (-__INT_MAX__ - 1) / 2;
> + int e = 10;
> + int f = (d * 2 > e * 5 ? d * 2 : e * 5) * 6;
> + if (f != 120)
> +__builtin_abort ();
> + int g = (-__INT_MAX__ - 1) / 2;
> + int h = 0;
> + int i = (g * 2 > h * 5 ? g * 2 : h * 5) / -1;
> + if (i != 0)
> +__builtin_abort ();
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Re: [PATCH v2] MIPS: Add MIN/MAX.fmt instructions support for MIPS R6
On Tue, 2024-03-26 at 11:15 +0800, YunQiang Su wrote: /* snip */ > With -ffinite-math-only -fno-signed-zeros, it does work with > x >= y ? x : y > while without `-ffinite-math-only -fno-signed-zeros`, it cannot. > @Xi Ruoyao Is it expected by IEEE? When y is (quiet) NaN and x is not, fmax(x, y) should produce x but x >= y ? x : y should produce y. Thus -ffinite-math-only is needed. When x is +0.0 and y is -0.0, x >= y ? x : y should produce +0.0 but fmax(x, y) may produce +0.0 or -0.0 (IEEE allows both and I don't see a more strict requirement in MIPS 6.06 manual either). Thus -fno-signed- zeros is needed. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University
Re: [PATCH] c++: fix alias CTAD [PR114377]
The problem was is that in cp/pt.cc:find_template_parameter_info::found
compiler tried to get TEMPLATE_TEMPLATE_PARM tree from TEMPLATE_DECL tree by
DECL_INITIAL instead of TREE_TYPE(like for TYPE_DECL). Therefore, parm got
nullptr, because cp/pt.cc:process_template_parm doesn't assign anything to
DECL_INITIAL for both TYPE_DECL and TEMPLATE_DECL.
On Monday, March 25th, 2024 at 7:17 PM, centurion
wrote:
> From b34312d82b236601c348382d30e625558f37d40c Mon Sep 17 00:00:00 2001
> From: centurion centurion...@proton.me
>
> Date: Mon, 25 Mar 2024 01:57:21 +0400
> Subject: [PATCH] c++: fix alias CTAD [PR114377]
>
> PR c++/114377
>
> gcc/cp/ChangeLog:
>
> PR c++/114377
> * pt.cc (find_template_parameter_info::found): Use TREE_TYPE for
> TEMPLATE_DECL instead of DECL_INITIAL.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp2a/class-deduction-alias19.C: New test.
> ---
> gcc/cp/pt.cc | 3 ++-
> .../g++.dg/cpp2a/class-deduction-alias19.C | 15 +++
> 2 files changed, 17 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias19.C
>
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 8cf0d5b7a8d..d8a02f1cd7f 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -11032,7 +11032,8 @@ find_template_parameter_info::found (tree parm)
> {
> if (TREE_CODE (parm) == TREE_LIST)
> parm = TREE_VALUE (parm);
> - if (TREE_CODE (parm) == TYPE_DECL)
> + if (TREE_CODE (parm) == TYPE_DECL
> + || TREE_CODE(parm) == TEMPLATE_DECL)
> parm = TREE_TYPE (parm);
> else
> parm = DECL_INITIAL (parm);
> diff --git a/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias19.C
> b/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias19.C
> new file mode 100644
> index 000..1ea79bd7691
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias19.C
> @@ -0,0 +1,15 @@
> +// PR c++/114377
> +// { dg-do compile { target c++20 } }
> +
> +template typename Iterator>
>
> +struct K {};
> +
> +template
>
> +class Foo {};
> +
> +template typename TTP>
>
> +using Bar = Foo>;
>
> +
> +void s() {
> + Bar(1); // { dg-error "failed|no match" }
> +}
> --
> 2.44.0
[PATCH] tree-optimization/114471 - ICE with mismatching vector types
The following fixes too lax verification of vector type compatibility
in vectorizable_operation. When we only have a single vector size then
comparing the number of elements is enough but with SLP we mix those
and thus for operations like BIT_AND_EXPR we need to verify compatible
element types as well. Allow sign changes for ABSU_EXPR though.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114471
* tree-vect-stmts.cc (vectorizable_operation): Verify operand
types are compatible with the result type.
* gcc.dg/vect/pr114471.c: New testcase.
---
gcc/testsuite/gcc.dg/vect/pr114471.c | 13 +
gcc/tree-vect-stmts.cc | 11 ---
2 files changed, 21 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/vect/pr114471.c
diff --git a/gcc/testsuite/gcc.dg/vect/pr114471.c
b/gcc/testsuite/gcc.dg/vect/pr114471.c
new file mode 100644
index 000..218c953e45e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr114471.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+
+float f1, f0, fa[2];
+short sa[2];
+void quantize(short s0)
+{
+ _Bool ta[2] = {(fa[0] < 0), (fa[1] < 0)};
+ _Bool t = ((s0 > 0) & ta[0]);
+ short x1 = s0 + t;
+ _Bool t1 = ((x1 > 0) & ta[1]);
+ sa[0] = x1;
+ sa[1] = s0 + t1;
+}
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 5a4eb136c6d..f8d8636b139 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -6667,7 +6667,8 @@ vectorizable_operation (vec_info *vinfo,
nunits_out = TYPE_VECTOR_SUBPARTS (vectype_out);
nunits_in = TYPE_VECTOR_SUBPARTS (vectype);
- if (maybe_ne (nunits_out, nunits_in))
+ if (maybe_ne (nunits_out, nunits_in)
+ || !tree_nop_conversion_p (TREE_TYPE (vectype_out), TREE_TYPE (vectype)))
return false;
tree vectype2 = NULL_TREE, vectype3 = NULL_TREE;
@@ -6685,7 +6686,9 @@ vectorizable_operation (vec_info *vinfo,
is_invariant &= (dt[1] == vect_external_def
|| dt[1] == vect_constant_def);
if (vectype2
- && maybe_ne (nunits_out, TYPE_VECTOR_SUBPARTS (vectype2)))
+ && (maybe_ne (nunits_out, TYPE_VECTOR_SUBPARTS (vectype2))
+ || !tree_nop_conversion_p (TREE_TYPE (vectype_out),
+TREE_TYPE (vectype2
return false;
}
if (op_type == ternary_op)
@@ -6701,7 +6704,9 @@ vectorizable_operation (vec_info *vinfo,
is_invariant &= (dt[2] == vect_external_def
|| dt[2] == vect_constant_def);
if (vectype3
- && maybe_ne (nunits_out, TYPE_VECTOR_SUBPARTS (vectype3)))
+ && (maybe_ne (nunits_out, TYPE_VECTOR_SUBPARTS (vectype3))
+ || !tree_nop_conversion_p (TREE_TYPE (vectype_out),
+TREE_TYPE (vectype3
return false;
}
--
2.35.3
Re: [PATCH] c++: fix alias CTAD [PR114377]
The problem was that in cp/pt.cc:find_template_parameter_info::found compiler
tried to get TEMPLATE_TEMPLATE_PARM tree from TEMPLATE_DECL tree by
DECL_INITIAL instead of TREE_TYPE(like for TYPE_DECL).Therefore, parm got
nullptr, because cp/pt.cc:process_template_parm doesn't assign anything to
DECL_INITIAL for both TYPE_DECL and TEMPLATE_DECL.
On Monday, March 25th, 2024 at 7:17 PM, centurion
wrote:
> From b34312d82b236601c348382d30e625558f37d40c Mon Sep 17 00:00:00 2001
> From: centurion centurion...@proton.me
>
> Date: Mon, 25 Mar 2024 01:57:21 +0400
> Subject: [PATCH] c++: fix alias CTAD [PR114377]
>
> PR c++/114377
>
> gcc/cp/ChangeLog:
>
> PR c++/114377
> * pt.cc (find_template_parameter_info::found): Use TREE_TYPE for
> TEMPLATE_DECL instead of DECL_INITIAL.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp2a/class-deduction-alias19.C: New test.
> ---
> gcc/cp/pt.cc | 3 ++-
> .../g++.dg/cpp2a/class-deduction-alias19.C | 15 +++
> 2 files changed, 17 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp2a/class-deduction-alias19.C
>
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 8cf0d5b7a8d..d8a02f1cd7f 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -11032,7 +11032,8 @@ find_template_parameter_info::found (tree parm)
> {
> if (TREE_CODE (parm) == TREE_LIST)
> parm = TREE_VALUE (parm);
> - if (TREE_CODE (parm) == TYPE_DECL)
> + if (TREE_CODE (parm) == TYPE_DECL
> + || TREE_CODE(parm) == TEMPLATE_DECL)
> parm = TREE_TYPE (parm);
> else
> parm = DECL_INITIAL (parm);
> diff --git a/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias19.C
> b/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias19.C
> new file mode 100644
> index 000..1ea79bd7691
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp2a/class-deduction-alias19.C
> @@ -0,0 +1,15 @@
> +// PR c++/114377
> +// { dg-do compile { target c++20 } }
> +
> +template typename Iterator>
>
> +struct K {};
> +
> +template
>
> +class Foo {};
> +
> +template typename TTP>
>
> +using Bar = Foo>;
>
> +
> +void s() {
> + Bar(1); // { dg-error "failed|no match" }
> +}
> --
> 2.44.0
[PATCH] fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR111151]
Hi!
As I've tried to explain in the comments, the extract_muldiv_1
MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR.
If the multiplication is done in unsigned type or in signed
type with -fwrapv, it is fairly obvious that max (a, b) * c
in many cases isn't equivalent to max (a * c, b * c) (or min if c is
negative) due to overflows, but even for signed with undefined overflow,
the optimization could turn something without UB in it (where
say a * c invokes UB, but max (or min) picks the other operand where
b * c doesn't).
As for division/modulo, I think it is in most cases safe, except if
the problematic INT_MIN / -1 case could be triggered, but we can
just punt for MAX_EXPR because for MIN_EXPR if one operand is INT_MIN,
we'd pick that operand already. It is just for completeness, match.pd
already has an optimization which turns x / -1 into -x, so the division
by zero is mostly theoretical. That is also why in the testcase the
i case isn't actually miscompiled without the patch, while the c and f
cases are.
Bootstrapped/regtested on x86_64-linux and i686-linux, additionally
bootstrapped/regtested on x86_64-linux with statistics gathering when
the patch changes behavior and it is solely on the new testcase and
nothing else during the bootstrap/regtest. Ok for trunk?
2024-03-26 Jakub Jelinek
PR middle-end/51
* fold-const.cc (extract_muldiv_1) : Punt for
MULT_EXPR altogether, or for MAX_EXPR if c is -1.
* gcc.c-torture/execute/pr51.c: New test.
--- gcc/fold-const.cc.jj2024-03-11 09:42:04.544588951 +0100
+++ gcc/fold-const.cc 2024-03-25 11:48:12.133625285 +0100
@@ -7104,6 +7104,27 @@ extract_muldiv_1 (tree t, tree c, enum t
if (TYPE_UNSIGNED (ctype) != TYPE_UNSIGNED (type))
break;
+ /* Punt for multiplication altogether.
+MAX (1U + INT_MAX, 1U) * 2U is not equivalent to
+MAX ((1U + INT_MAX) * 2U, 1U * 2U), the former is
+0U, the latter is 2U.
+MAX (INT_MIN / 2, 0) * -2 is not equivalent to
+MIN (INT_MIN / 2 * -2, 0 * -2), the former is
+well defined 0, the latter invokes UB.
+MAX (INT_MIN / 2, 5) * 5 is not equivalent to
+MAX (INT_MIN / 2 * 5, 5 * 5), the former is
+well defined 25, the latter invokes UB. */
+ if (code == MULT_EXPR)
+ break;
+ /* For division/modulo, punt on c being -1 for MAX, as
+MAX (INT_MIN, 0) / -1 is not equivalent to
+MIN (INT_MIN / -1, 0 / -1), the former is well defined
+0, the latter invokes UB (or for -fwrapv is INT_MIN).
+MIN (INT_MIN, 0) / -1 already invokes UB, so the
+transformation won't make it worse. */
+ else if (tcode == MAX_EXPR && integer_minus_onep (c))
+ break;
+
/* MIN (a, b) / 5 -> MIN (a / 5, b / 5) */
sub_strict_overflow_p = false;
if ((t1 = extract_muldiv (op0, c, code, wide_type,
--- gcc/testsuite/gcc.c-torture/execute/pr51.c.jj 2024-03-25
11:50:27.199744988 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr51.c 2024-03-26
10:41:51.003384032 +0100
@@ -0,0 +1,21 @@
+/* PR middle-end/51 */
+
+int
+main ()
+{
+ unsigned a = (1U + __INT_MAX__) / 2U;
+ unsigned b = 1U;
+ unsigned c = (a * 2U > b * 2U ? a * 2U : b * 2U) * 2U;
+ if (c != 0U)
+__builtin_abort ();
+ int d = (-__INT_MAX__ - 1) / 2;
+ int e = 10;
+ int f = (d * 2 > e * 5 ? d * 2 : e * 5) * 6;
+ if (f != 120)
+__builtin_abort ();
+ int g = (-__INT_MAX__ - 1) / 2;
+ int h = 0;
+ int i = (g * 2 > h * 5 ? g * 2 : h * 5) / -1;
+ if (i != 0)
+__builtin_abort ();
+}
Jakub
[PATCH] LoongArch: Increase division costs
The latency of LA464 and LA664 division instructions depends on the
input. When I updated the costs in r14-6642, I unintentionally set the
division costs to the best-case latency (when the first operand is 0).
Per a recent discussion [1] we should use "something sensible" instead
of it.
Use the average of the minimum and maximum latency observed instead.
This enables multiplication to reciprocal sequence reduction and speeds
up the following test case for about 30%:
int
main (void)
{
unsigned long stat = 0xdeadbeef;
for (int i = 0; i < 1; i++)
stat = (stat * stat + stat * 114514 + 1919810) % 17;
asm(""::"r"(stat));
}
[1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648348.html
gcc/ChangeLog:
* config/loongarch/loongarch-def.cc
(loongarch_rtx_cost_data::loongarch_rtx_cost_data): Increase
default division cost to the average of the best case and worst
case senarios observed.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/div-const-reduction.c: New test.
---
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk?
gcc/config/loongarch/loongarch-def.cc| 8
gcc/testsuite/gcc.target/loongarch/div-const-reduction.c | 9 +
2 files changed, 13 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
diff --git a/gcc/config/loongarch/loongarch-def.cc
b/gcc/config/loongarch/loongarch-def.cc
index e8c129ce643..93e72a520d5 100644
--- a/gcc/config/loongarch/loongarch-def.cc
+++ b/gcc/config/loongarch/loongarch-def.cc
@@ -95,12 +95,12 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data ()
: fp_add (COSTS_N_INSNS (5)),
fp_mult_sf (COSTS_N_INSNS (5)),
fp_mult_df (COSTS_N_INSNS (5)),
-fp_div_sf (COSTS_N_INSNS (8)),
-fp_div_df (COSTS_N_INSNS (8)),
+fp_div_sf (COSTS_N_INSNS (12)),
+fp_div_df (COSTS_N_INSNS (15)),
int_mult_si (COSTS_N_INSNS (4)),
int_mult_di (COSTS_N_INSNS (4)),
-int_div_si (COSTS_N_INSNS (5)),
-int_div_di (COSTS_N_INSNS (5)),
+int_div_si (COSTS_N_INSNS (14)),
+int_div_di (COSTS_N_INSNS (22)),
movcf2gr (COSTS_N_INSNS (7)),
movgr2cf (COSTS_N_INSNS (15)),
branch_cost (6),
diff --git a/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
new file mode 100644
index 000..0ee86410dd7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/div-const-reduction.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mtune=la464" } */
+/* { dg-final { scan-assembler-not "div\.\[dw\]" } } */
+
+int
+test (int a)
+{
+ return a % 17;
+}
--
2.44.0
[PATCH] tree-optimization/114464 - verify types in recurrence vectorization
The following adds missing verification of vector type compatibility
to recurrence vectorization.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/114464
* tree-vect-loop.cc (vectorizable_recurr): Verify the latch
vector type is compatible with what we chose for the recurrence.
* g++.dg/vect/pr114464.cc: New testcase.
---
gcc/testsuite/g++.dg/vect/pr114464.cc | 11 +++
gcc/tree-vect-loop.cc | 22 ++
2 files changed, 33 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/vect/pr114464.cc
diff --git a/gcc/testsuite/g++.dg/vect/pr114464.cc
b/gcc/testsuite/g++.dg/vect/pr114464.cc
new file mode 100644
index 000..0d872aae9d4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/vect/pr114464.cc
@@ -0,0 +1,11 @@
+// { dg-do compile }
+
+void h(unsigned char *scratch, bool carry)
+{
+ for (int i = 0; i < 16; i++) {
+bool b = scratch[i] <<= 1;
+if (carry)
+ scratch[i] |= 1;
+carry = b;
+ }
+}
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 302c92e6f31..42e78cc9c32 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -9212,6 +9212,28 @@ vectorizable_recurr (loop_vec_info loop_vinfo,
stmt_vec_info stmt_info,
return false;
}
}
+
+ /* Verify we have set up compatible types. */
+ edge le = loop_latch_edge (LOOP_VINFO_LOOP (loop_vinfo));
+ tree latch_vectype = NULL_TREE;
+ if (slp_node)
+ {
+ slp_tree latch_def = SLP_TREE_CHILDREN (slp_node)[le->dest_idx];
+ latch_vectype = SLP_TREE_VECTYPE (latch_def);
+ }
+ else
+ {
+ tree latch_def = PHI_ARG_DEF_FROM_EDGE (phi, le);
+ if (TREE_CODE (latch_def) == SSA_NAME)
+ {
+ stmt_vec_info latch_def_info = loop_vinfo->lookup_def (latch_def);
+ latch_def_info = vect_stmt_to_vectorize (latch_def_info);
+ latch_vectype = STMT_VINFO_VECTYPE (latch_def_info);
+ }
+ }
+ if (!types_compatible_p (latch_vectype, vectype))
+ return false;
+
/* The recurrence costs the initialization vector and one permute
for each copy. */
unsigned prologue_cost = record_stmt_cost (cost_vec, 1, scalar_to_vec,
--
2.35.3
Re: [PATCH] tsan: Don't instrument non-generic AS accesses [PR111736]
On Tue, 26 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> Similar to the asan and ubsan changes, we shouldn't instrument non-generic
> address space accesses with tsan, because we just have library functions
> which take address of the objects as generic address space pointers, so they
> can't handle anything else.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
> 2024-03-26 Jakub Jelinek
>
> PR sanitizer/111736
> * tsan.cc (instrument_expr): Punt on non-generic address space
> accesses.
>
> * gcc.dg/tsan/pr111736.c: New test.
>
> --- gcc/tsan.cc.jj2024-01-03 11:51:29.155764166 +0100
> +++ gcc/tsan.cc 2024-03-25 10:36:07.602861266 +0100
> @@ -139,6 +139,9 @@ instrument_expr (gimple_stmt_iterator gs
>if (TREE_READONLY (base) || (VAR_P (base) && DECL_HARD_REGISTER (base)))
> return false;
>
> + if (!ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (base
> +return false;
> +
>stmt = gsi_stmt (gsi);
>loc = gimple_location (stmt);
>rhs = is_vptr_store (stmt, expr, is_write);
> --- gcc/testsuite/gcc.dg/tsan/pr111736.c.jj 2024-03-25 10:38:07.663191030
> +0100
> +++ gcc/testsuite/gcc.dg/tsan/pr111736.c 2024-03-25 10:43:08.071008937
> +0100
> @@ -0,0 +1,17 @@
> +/* PR sanitizer/111736 */
> +/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
> +/* { dg-options "-fsanitize=thread -fdump-tree-optimized -ffat-lto-objects"
> } */
> +/* { dg-final { scan-tree-dump-not "__tsan_read" "optimized" } } */
> +/* { dg-final { scan-tree-dump-not "__tsan_write" "optimized" } } */
> +
> +#ifdef __x86_64__
> +#define SEG __seg_fs
> +#else
> +#define SEG __seg_gs
> +#endif
> +
> +void
> +foo (int SEG *p, int SEG *q)
> +{
> + *q = *p;
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
[PATCH] c++: Don't maybe_constant_value fold dtor calls [PR114426]
Hi!
The following testcase ICEs on arm, because it is the only
cdtor_returns_this target. Normally cp_fold never folds destructor
calls because the calls have VOID_TYPE_P return and maybe_constant_value
in that case does nothing, and cxx_eval_outermost_constant_expr does
something for those only if it is a constructor (then initialized_type
returns the type of the object being constructed) or if called with
constexpr_dtor = true. Arm is the only exception because there the
dtor returns the this pointer and so we attempt to fold it, and run
into
+ for (; remapped; remapped = TREE_CHAIN (remapped))
+ if (DECL_NAME (remapped) == in_charge_identifier)
+ {
+ /* FIXME destructors unnecessarily have in-charge parameters
+ even in classes without vbases, map it to 0 for now. */
+ gcc_assert (!CLASSTYPE_VBASECLASSES (DECL_CONTEXT (fun)));
+ ctx->global->put_value (remapped, integer_zero_node);
assertion there.
The following patch "fixes" it by trying to handle (not handle actually)
the dtor calls on arm the same as on all other targets, but perhaps we
instead want to constexpr evaluate them on all targets (with constexpr_dtor
= true) and deal somehow with the above assertion. In any case, I think
some consistency is desirable even when one target has a weird ABI
requirement.
Bootstrapped/regtested on x86_64-linux and i686-linux plus tested on
the testcase in a cross to arm.
2024-03-26 Jakub Jelinek
PR c++/114426
* cp-gimplify.cc (cp_fold): Don't call maybe_const_value on
CALL_EXPRs to cdtors.
* g++.dg/cpp2a/pr114426.C: New test.
--- gcc/cp/cp-gimplify.cc.jj2024-02-23 18:55:05.377594277 +0100
+++ gcc/cp/cp-gimplify.cc 2024-03-22 16:46:49.381442914 +0100
@@ -3395,7 +3395,13 @@ cp_fold (tree x, fold_flags_t flags)
Do constexpr expansion of expressions where the call itself is not
constant, but the call followed by an INDIRECT_REF is. */
if (callee && DECL_DECLARED_CONSTEXPR_P (callee)
- && !flag_no_inline)
+ && !flag_no_inline
+ /* Don't invoke it on dtors. On
+ !targetm.cxx.cdtor_returns_this () it won't do anything as it
+ has void type, so don't do it on
+ targetm.cxx.cdtor_returns_this () targets either for
+ consistency. */
+ && !DECL_DESTRUCTOR_P (callee))
{
mce_value manifestly_const_eval = mce_unknown;
if (flags & ff_mce_false)
--- gcc/testsuite/g++.dg/cpp2a/pr114426.C.jj2024-03-22 16:49:55.650882841
+0100
+++ gcc/testsuite/g++.dg/cpp2a/pr114426.C 2024-03-22 16:48:51.829759997
+0100
@@ -0,0 +1,6 @@
+// PR c++/114426
+// { dg-do compile }
+
+struct A { virtual ~A (); };
+struct B : virtual A { virtual void foo () = 0; };
+struct C : B { C () {} };
Jakub
[PATCH] tsan: Don't instrument non-generic AS accesses [PR111736]
Hi!
Similar to the asan and ubsan changes, we shouldn't instrument non-generic
address space accesses with tsan, because we just have library functions
which take address of the objects as generic address space pointers, so they
can't handle anything else.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-03-26 Jakub Jelinek
PR sanitizer/111736
* tsan.cc (instrument_expr): Punt on non-generic address space
accesses.
* gcc.dg/tsan/pr111736.c: New test.
--- gcc/tsan.cc.jj 2024-01-03 11:51:29.155764166 +0100
+++ gcc/tsan.cc 2024-03-25 10:36:07.602861266 +0100
@@ -139,6 +139,9 @@ instrument_expr (gimple_stmt_iterator gs
if (TREE_READONLY (base) || (VAR_P (base) && DECL_HARD_REGISTER (base)))
return false;
+ if (!ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (TREE_TYPE (base
+return false;
+
stmt = gsi_stmt (gsi);
loc = gimple_location (stmt);
rhs = is_vptr_store (stmt, expr, is_write);
--- gcc/testsuite/gcc.dg/tsan/pr111736.c.jj 2024-03-25 10:38:07.663191030
+0100
+++ gcc/testsuite/gcc.dg/tsan/pr111736.c2024-03-25 10:43:08.071008937
+0100
@@ -0,0 +1,17 @@
+/* PR sanitizer/111736 */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-options "-fsanitize=thread -fdump-tree-optimized -ffat-lto-objects" }
*/
+/* { dg-final { scan-tree-dump-not "__tsan_read" "optimized" } } */
+/* { dg-final { scan-tree-dump-not "__tsan_write" "optimized" } } */
+
+#ifdef __x86_64__
+#define SEG __seg_fs
+#else
+#define SEG __seg_gs
+#endif
+
+void
+foo (int SEG *p, int SEG *q)
+{
+ *q = *p;
+}
Jakub
Re: [PATCH] testsuite: Fix copy-headers-8.c
On Tue, Mar 26, 2024 at 9:43 AM Stefan Schulze Frielinghaus
wrote:
>
> This fixes the test on s390x. I'm also seeing test failures for
> riscv64-suse-linux-gnu, m68k-unknown-linux-gnu, pru-unknown-elf, and
> powerpc64le-unknown-linux-gnu. However, I didn't check them so this
> might or might not fix those, too.
>
> OK for mainline?
OK.
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/tree-ssa/copy-headers-8.c: Set
> LOGICAL_OP_NON_SHORT_CIRCUIT to true.
> ---
> gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c
> b/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c
> index 8b4b5e7ea81..28b4d15d87f 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c
> @@ -1,5 +1,8 @@
> +/* For targets where LOGICAL_OP_NON_SHORT_CIRCUIT evaluates to false, two
> + conditional jumps are emitted instead of a combined conditional which this
> + test is all about. Thus, set it to true. */
> /* { dg-do compile } */
> -/* { dg-options "-O2 -fdump-tree-ch2-details" } */
> +/* { dg-options "-O2 -fdump-tree-ch2-details --param
> logical-op-non-short-circuit=1" } */
>
> int is_sorted(int *a, int n, int m, int k)
> {
> --
> 2.43.0
>
[committed] cfgloopmanip, i386: Fix comment typos
Hi! I've noticed a comment typo in x86-tune.def and cfgloopmanip.cc has the same typo as well. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as obvious. 2024-03-26 Jakub Jelinek * cfgloopmanip.cc (update_loop_exit_probability_scale_dom_bbs): Fix comment typo - multple -> multiple. * config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGOING_ARGS): Likewise. --- gcc/cfgloopmanip.cc.jj 2024-01-03 11:51:26.819796587 +0100 +++ gcc/cfgloopmanip.cc 2024-03-25 17:44:15.993120420 +0100 @@ -669,7 +669,7 @@ update_loop_exit_probability_scale_dom_b + old_exit_count - exit_edge->count (); } else -/* If there are multple blocks, just scale. */ +/* If there are multiple blocks, just scale. */ scale_dominated_blocks_in_loop (loop, exit_edge->src, exit_edge->src->count - exit_edge->count (), exit_edge->src->count - old_exit_count); --- gcc/config/i386/x86-tune.def.jj 2024-03-18 10:33:28.019418854 +0100 +++ gcc/config/i386/x86-tune.def2024-03-25 17:44:53.045606200 +0100 @@ -157,7 +157,7 @@ DEF_TUNE (X86_TUNE_FUSE_ALU_AND_BRANCH, by push/pop instructions. This increase code size by about 5% in 32bit mode, less so in 64bit mode because parameters are passed in registers. It is considerable - win for targets without stack engine that prevents multple push operations + win for targets without stack engine that prevents multiple push operations to happen in parallel. */ DEF_TUNE (X86_TUNE_ACCUMULATE_OUTGOING_ARGS, "accumulate_outgoing_args", Jakub
[PATCH] tree-optimization/114027 - fix testcase
The following fixes out-of-bounds read in the testcase.
Pushed to trunk and branch.
PR tree-optimization/114027
* gcc.dg/vect/pr114027.c: Fix iteration count.
---
gcc/testsuite/gcc.dg/vect/pr114027.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/vect/pr114027.c
b/gcc/testsuite/gcc.dg/vect/pr114027.c
index ead9cdd982d..b3f3e30e15f 100644
--- a/gcc/testsuite/gcc.dg/vect/pr114027.c
+++ b/gcc/testsuite/gcc.dg/vect/pr114027.c
@@ -20,7 +20,7 @@ int f[] = { 1, 1, 1, 1, 1, 1, 1, 1,
int
main ()
{
- if (foo (f, 16) != 2)
+ if (foo (f, 8) != 2)
__builtin_abort ();
return 0;
}
--
2.35.3
[PATCH] testsuite: Fix copy-headers-8.c
This fixes the test on s390x. I'm also seeing test failures for
riscv64-suse-linux-gnu, m68k-unknown-linux-gnu, pru-unknown-elf, and
powerpc64le-unknown-linux-gnu. However, I didn't check them so this
might or might not fix those, too.
OK for mainline?
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/copy-headers-8.c: Set
LOGICAL_OP_NON_SHORT_CIRCUIT to true.
---
gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c
b/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c
index 8b4b5e7ea81..28b4d15d87f 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-8.c
@@ -1,5 +1,8 @@
+/* For targets where LOGICAL_OP_NON_SHORT_CIRCUIT evaluates to false, two
+ conditional jumps are emitted instead of a combined conditional which this
+ test is all about. Thus, set it to true. */
/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-ch2-details" } */
+/* { dg-options "-O2 -fdump-tree-ch2-details --param
logical-op-non-short-circuit=1" } */
int is_sorted(int *a, int n, int m, int k)
{
--
2.43.0
[PATCH v2] RTEMS: Add multilib configuration for aarch64
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rtems | 42 ++
2 files changed, 43 insertions(+)
create mode 100644 gcc/config/aarch64/t-aarch64-rtems
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 648b3dc2110..c3b73d05eb7 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1139,6 +1139,7 @@ aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
;;
aarch64-*-rtems*)
tm_file="${tm_file} aarch64/rtems.h rtems.h"
+ tmake_file="${tmake_file} aarch64/t-aarch64-rtems"
;;
esac
case $target in
diff --git a/gcc/config/aarch64/t-aarch64-rtems
b/gcc/config/aarch64/t-aarch64-rtems
new file mode 100644
index 000..11f8c380222
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-rtems
@@ -0,0 +1,42 @@
+# Machine description for AArch64 architecture.
+# Copyright (C) 2024 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+#
