[PATCH] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]
In this PR, we have to handle a case where MVE predicates are supplied
as a const_int, where individual predicates have illegal boolean
values (such as 0xc for a 4-bit boolean predicate). To avoid the ICE,
we canonicalize them, replacing a non-null value with -1.
2024-04-26 Christophe Lyon
Jakub Jelinek
PR target/114801
gcc/
* config/arm/arm-mve-builtins.cc
(function_expander::add_input_operand): Handle CONST_INT
predicates.
gcc/testsuite/
* gcc.target/arm/mve/pr114801.c: New test.
---
gcc/config/arm/arm-mve-builtins.cc | 21 +++-
gcc/testsuite/gcc.target/arm/mve/pr114801.c | 36 +
2 files changed, 56 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/arm/mve/pr114801.c
diff --git a/gcc/config/arm/arm-mve-builtins.cc
b/gcc/config/arm/arm-mve-builtins.cc
index 6a5775c67e5..f338ab36434 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -43,6 +43,7 @@
#include "stringpool.h"
#include "attribs.h"
#include "diagnostic.h"
+#include "rtx-vector-builder.h"
#include "arm-protos.h"
#include "arm-builtins.h"
#include "arm-mve-builtins.h"
@@ -2205,7 +2206,25 @@ function_expander::add_input_operand (insn_code icode,
rtx x)
mode = GET_MODE (x);
}
else if (VALID_MVE_PRED_MODE (mode))
-x = gen_lowpart (mode, x);
+{
+ if (CONST_INT_P (x) && (mode == V8BImode || mode == V4BImode))
+ {
+ /* In V8BI or V4BI each element has 2 or 4 bits, if those
+bits aren't all the same, it is UB and gen_lowpart might
+ICE. Canonicalize all the 2 or 4 bits to all ones if any
+of them is non-zero. */
+ unsigned HOST_WIDE_INT xi = UINTVAL (x);
+ xi |= ((xi & 0x) << 1) | ((xi & 0x) >> 1);
+ if (mode == V4BImode)
+ xi |= ((xi & 0x) << 2) | ((xi & 0x) >> 2);
+ x = gen_int_mode (xi, HImode);
+ }
+ else if (SUBREG_P (x))
+ /* gen_lowpart on a SUBREG can ICE. */
+ x = force_reg (GET_MODE (x), x);
+
+ x = gen_lowpart (mode, x);
+}
m_ops.safe_grow (m_ops.length () + 1, true);
create_input_operand (_ops.last (), x, mode);
diff --git a/gcc/testsuite/gcc.target/arm/mve/pr114801.c
b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
new file mode 100644
index 000..676b109f9b8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
+/* { dg-final { check-function-bodies "**" "" "" } } */
+
+#include
+
+/*
+** test_32:
+**...
+** mov r[0-9]+, #65535 @ movhi
+**...
+*/
+uint32x4_t test_32() {
+ return vdupq_m_n_u32(vdupq_n_u32(0), 0, 0x);
+}
+
+/*
+** test_16:
+**...
+** mov r[0-9]+, #52428 @ movhi
+**...
+*/
+uint16x8_t test_16() {
+ return vdupq_m_n_u16(vdupq_n_u16(0), 0, 0x);
+}
+
+/*
+** test_8:
+**...
+** mov r[0-9]+, #52428 @ movhi
+**...
+*/
+uint8x16_t test_8() {
+ return vdupq_m_n_u8(vdupq_n_u8(0), 0, 0x);
+}
--
2.34.1
Re: [PATCH] wwwdocs: contribute.html: Update consensus on patch content.
On Fri, 26 Apr 2024 at 10:25, Christophe Lyon wrote: > > On Thu, 25 Apr 2024 at 17:44, Carlos O'Donell wrote: > > > > Discussion is here: > > https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/ > > > > Rough consensus from Jakub Jelinek, Richard Biener and others is > > that maintainers are for the change. > > > > This changes the contribution notes to allow it. > > Thank you Carlos for the patch and helping with the discussions! > > Christophe > And BTW sorry I wasn't able to attend the meeting yesterday, thanks Thiago for raising the question. I have a follow-up one: I think the same applies to binutils, but I don't think any maintainer / contributor expressed an opinion, and IIUC patch policy for binutils is (lightly) documented at https://sourceware.org/binutils/wiki/HowToContribute Maybe Nick can update it? (I don't have such rights) Thanks, Christophe > > --- > > htdocs/contribute.html | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/htdocs/contribute.html b/htdocs/contribute.html > > index 7c1ae323..e8137edc 100644 > > --- a/htdocs/contribute.html > > +++ b/htdocs/contribute.html > > @@ -195,8 +195,9 @@ of your testing. > > > > The patch itself > > > > -Do not include generated files as part of the patch, just mention > > -them in the ChangeLog (e.g., "* configure: Regenerate."). > > +The patch should include everything you are changing (including > > +regenerated files which should be noted in the ChangeLog e.g. > > +"* configure: Regenerate."). > > > > > > > > -- > > 2.44.0 > >
Re: [PATCH] wwwdocs: contribute.html: Update consensus on patch content.
On Thu, 25 Apr 2024 at 17:44, Carlos O'Donell wrote: > > Discussion is here: > https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/ > > Rough consensus from Jakub Jelinek, Richard Biener and others is > that maintainers are for the change. > > This changes the contribution notes to allow it. Thank you Carlos for the patch and helping with the discussions! Christophe > --- > htdocs/contribute.html | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/htdocs/contribute.html b/htdocs/contribute.html > index 7c1ae323..e8137edc 100644 > --- a/htdocs/contribute.html > +++ b/htdocs/contribute.html > @@ -195,8 +195,9 @@ of your testing. > > The patch itself > > -Do not include generated files as part of the patch, just mention > -them in the ChangeLog (e.g., "* configure: Regenerate."). > +The patch should include everything you are changing (including > +regenerated files which should be noted in the ChangeLog e.g. > +"* configure: Regenerate."). > > > > -- > 2.44.0 >
Re: [pushed] c++/modules: make bits_in/out move-constructible
Hi Patrick,
On Sat, 13 Apr 2024 at 22:12, Patrick Palka wrote:
>
> Pushed as obvious after verifying C++11 bootstrap is restored.
I guess this also fixes the bootstrap_ubsan breakage on aarch64
reported by Linaro CI?
See https://linaro.atlassian.net/browse/GNU-1199
(I think you also received a notification about this a few days ago?)
Thanks,
Christophe
>
> -- >8 --
>
> gcc/cp/ChangeLog:
>
> * module.cc (struct bytes_in::bits_in): Define defaulted
> move ctor.
> (struct bytes_out::bits_out): Likewise.
> ---
> gcc/cp/module.cc | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index bbed82652d4..c6f71e11515 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -706,6 +706,7 @@ struct bytes_in::bits_in {
> bflush ();
>}
>
> + bits_in(bits_in&&) = default;
>bits_in(const bits_in&) = delete;
>bits_in& operator=(const bits_in&) = delete;
>
> @@ -752,6 +753,7 @@ struct bytes_out::bits_out {
> bflush ();
>}
>
> + bits_out(bits_out&&) = default;
>bits_out(const bits_out&) = delete;
>bits_out& operator=(const bits_out&) = delete;
>
> --
> 2.44.0.591.g8f7582d995
>
Re: [PATCH] contrib: Add autoregen.py
On Fri, 19 Apr 2024 at 11:03, Christophe Lyon
wrote:
>
> This script is a copy of the current script used by Sourceware's
> autoregen buildbots.
>
> It is intended as a helper to regenerate files managed by autotools
> (autoconf, automake, aclocal, ), as well as the toplevel
> Makefile.in which is created by autogen.
>
> Other files can be updated when using maintainer-mode, but this is not
> covered by this script.
>
> 2024-04-19 Christophe Lyon
>
> contrib/
> * autogen.py: New script.
Of course this should read "autoregen.py" :-)
> ---
> contrib/autoregen.py | 221 +++
> 1 file changed, 221 insertions(+)
> create mode 100755 contrib/autoregen.py
>
> diff --git a/contrib/autoregen.py b/contrib/autoregen.py
> new file mode 100755
> index 000..faffc88c5bd
> --- /dev/null
> +++ b/contrib/autoregen.py
> @@ -0,0 +1,221 @@
> +#!/usr/bin/env python3
> +
> +# This script helps to regenerate files managed by autotools and
> +# autogen in binutils-gdb and gcc repositories.
> +
> +# It can be used by buildbots to check that the current repository
> +# contents has been updated correctly, and by developers to update
> +# such files as expected.
> +
> +import os
> +import shutil
> +import subprocess
> +from pathlib import Path
> +
> +
> +# On Gentoo, vanilla unpatched autotools are packaged separately.
> +# We place the vanilla names first as we want to prefer those if both exist.
> +AUTOCONF_NAMES = ["autoconf-vanilla-2.69", "autoconf-2.69", "autoconf"]
> +AUTOMAKE_NAMES = ["automake-vanilla-1.15", "automake-1.15.1", "automake"]
> +ACLOCAL_NAMES = ["aclocal-vanilla-1.15", "aclocal-1.15.1", "aclocal"]
> +AUTOHEADER_NAMES = ["autoheader-vanilla-2.69", "autoheader-2.69",
> "autoheader"]
> +AUTORECONF_NAMES = ["autoreconf-vanilla-2.69", "autoreconf-2.69",
> "autoreconf"]
> +
> +# Pick the first for each list that exists on this system.
> +AUTOCONF_BIN = next(name for name in AUTOCONF_NAMES if shutil.which(name))
> +AUTOMAKE_BIN = next(name for name in AUTOMAKE_NAMES if shutil.which(name))
> +ACLOCAL_BIN = next(name for name in ACLOCAL_NAMES if shutil.which(name))
> +AUTOHEADER_BIN = next(name for name in AUTOHEADER_NAMES if
> shutil.which(name))
> +AUTORECONF_BIN = next(name for name in AUTORECONF_NAMES if
> shutil.which(name))
> +
> +AUTOGEN_BIN = "autogen"
> +
> +# autoconf-wrapper and automake-wrapper from Gentoo look at this environment
> variable.
> +# It's harmless to set it on other systems though.
> +EXTRA_ENV = {
> +"WANT_AUTOCONF": AUTOCONF_BIN.split("-", 1)[1] if "-" in AUTOCONF_BIN
> else "",
> +"WANT_AUTOMAKE": AUTOMAKE_BIN.split("-", 1)[1] if "-" in AUTOMAKE_BIN
> else "",
> +"AUTOCONF": AUTOCONF_BIN,
> +"ACLOCAL": ACLOCAL_BIN,
> +"AUTOMAKE": AUTOMAKE_BIN,
> +"AUTOGEN": AUTOGEN_BIN,
> +}
> +ENV = os.environ.copy()
> +ENV.update(EXTRA_ENV)
> +
> +
> +# Directories we should skip entirely because they're vendored or have
> different
> +# autotools versions.
> +SKIP_DIRS = [
> +# readline and minizip are maintained with different autotools versions
> +"readline",
> +"minizip",
> +]
> +
> +# these directories are known to be re-generatable with a simple autoreconf
> +# without special -I flags
> +# Entries commented out (and directories not listed) are handled by
> +# regenerate_manually().
> +AUTORECONF_DIRS = [
> +# subdirs common to binutils-gdb and gcc
> +"libbacktrace",
> +"libdecnumber", # No Makefile.am
> +"libiberty", # No Makefile.am
> +"zlib",
> +
> +# binutils-gdb subdirs
> +"bfd",
> +"binutils",
> +"etc",
> +"gas",
> +"gdb",
> +"gdbserver",
> +"gdbsupport",
> +"gnulib",
> +"gold",
> +"gprof",
> +"gprofng",
> +"gprofng/libcollector",
> +"ld",
> +"libctf",
> +"libsframe",
> +"opcodes",
> +"sim",
> +
> +# gcc subdirs
> +"c++tools", # No aclocal.m4
> +"gcc", # No Makefile.am
> +#"fixincludes", # autoreconf complains about GCC_AC_FUNC_MMAP_BLACKLIST
> +"gnattools
[PATCH] contrib: Add autoregen.py
This script is a copy of the current script used by Sourceware's
autoregen buildbots.
It is intended as a helper to regenerate files managed by autotools
(autoconf, automake, aclocal, ), as well as the toplevel
Makefile.in which is created by autogen.
Other files can be updated when using maintainer-mode, but this is not
covered by this script.
2024-04-19 Christophe Lyon
contrib/
* autogen.py: New script.
---
contrib/autoregen.py | 221 +++
1 file changed, 221 insertions(+)
create mode 100755 contrib/autoregen.py
diff --git a/contrib/autoregen.py b/contrib/autoregen.py
new file mode 100755
index 000..faffc88c5bd
--- /dev/null
+++ b/contrib/autoregen.py
@@ -0,0 +1,221 @@
+#!/usr/bin/env python3
+
+# This script helps to regenerate files managed by autotools and
+# autogen in binutils-gdb and gcc repositories.
+
+# It can be used by buildbots to check that the current repository
+# contents has been updated correctly, and by developers to update
+# such files as expected.
+
+import os
+import shutil
+import subprocess
+from pathlib import Path
+
+
+# On Gentoo, vanilla unpatched autotools are packaged separately.
+# We place the vanilla names first as we want to prefer those if both exist.
+AUTOCONF_NAMES = ["autoconf-vanilla-2.69", "autoconf-2.69", "autoconf"]
+AUTOMAKE_NAMES = ["automake-vanilla-1.15", "automake-1.15.1", "automake"]
+ACLOCAL_NAMES = ["aclocal-vanilla-1.15", "aclocal-1.15.1", "aclocal"]
+AUTOHEADER_NAMES = ["autoheader-vanilla-2.69", "autoheader-2.69", "autoheader"]
+AUTORECONF_NAMES = ["autoreconf-vanilla-2.69", "autoreconf-2.69", "autoreconf"]
+
+# Pick the first for each list that exists on this system.
+AUTOCONF_BIN = next(name for name in AUTOCONF_NAMES if shutil.which(name))
+AUTOMAKE_BIN = next(name for name in AUTOMAKE_NAMES if shutil.which(name))
+ACLOCAL_BIN = next(name for name in ACLOCAL_NAMES if shutil.which(name))
+AUTOHEADER_BIN = next(name for name in AUTOHEADER_NAMES if shutil.which(name))
+AUTORECONF_BIN = next(name for name in AUTORECONF_NAMES if shutil.which(name))
+
+AUTOGEN_BIN = "autogen"
+
+# autoconf-wrapper and automake-wrapper from Gentoo look at this environment
variable.
+# It's harmless to set it on other systems though.
+EXTRA_ENV = {
+"WANT_AUTOCONF": AUTOCONF_BIN.split("-", 1)[1] if "-" in AUTOCONF_BIN else
"",
+"WANT_AUTOMAKE": AUTOMAKE_BIN.split("-", 1)[1] if "-" in AUTOMAKE_BIN else
"",
+"AUTOCONF": AUTOCONF_BIN,
+"ACLOCAL": ACLOCAL_BIN,
+"AUTOMAKE": AUTOMAKE_BIN,
+"AUTOGEN": AUTOGEN_BIN,
+}
+ENV = os.environ.copy()
+ENV.update(EXTRA_ENV)
+
+
+# Directories we should skip entirely because they're vendored or have
different
+# autotools versions.
+SKIP_DIRS = [
+# readline and minizip are maintained with different autotools versions
+"readline",
+"minizip",
+]
+
+# these directories are known to be re-generatable with a simple autoreconf
+# without special -I flags
+# Entries commented out (and directories not listed) are handled by
+# regenerate_manually().
+AUTORECONF_DIRS = [
+# subdirs common to binutils-gdb and gcc
+"libbacktrace",
+"libdecnumber", # No Makefile.am
+"libiberty", # No Makefile.am
+"zlib",
+
+# binutils-gdb subdirs
+"bfd",
+"binutils",
+"etc",
+"gas",
+"gdb",
+"gdbserver",
+"gdbsupport",
+"gnulib",
+"gold",
+"gprof",
+"gprofng",
+"gprofng/libcollector",
+"ld",
+"libctf",
+"libsframe",
+"opcodes",
+"sim",
+
+# gcc subdirs
+"c++tools", # No aclocal.m4
+"gcc", # No Makefile.am
+#"fixincludes", # autoreconf complains about GCC_AC_FUNC_MMAP_BLACKLIST
+"gnattools", # No aclocal.m4
+"gotools",
+"libada", # No aclocal.m4
+"libatomic",
+"libcc1",
+"libcody", # No aclocal.m4
+"libcpp", # No Makefile.am
+"libffi",
+"libgcc", # No aclocal.m4
+"libgfortran",
+# Hack: ACLOCAL_AMFLAGS = -I .. -I ../config in Makefile.in but we
+# apply -I../config -I.. otherwise we do not match the current
+# contents
+#"libgm2",
+"libgo",
+"libgomp",
+"libgrust",
+"libitm",
+"libobjc", # No Makefile.am
+"libphobos",
+"libquadmath",
+&quo
Re: [PATCH] libgcc: Fix up __divmodbitint4 [PR114755]
On Thu, 18 Apr 2024 at 09:37, Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase aborts on aarch64-linux but does not on x86_64-linux.
> In both cases there is UB in the __divmodbitint4 implemenetation.
> When the divisor is negative with most significant limb (even when partial)
> all ones, has at least 2 limbs and the second most significant limb has the
> most significant bit clear, when this number is negated, it will have 0
> in the most significant limb.
> Already in the PR114397 r14-9592 fix I was dealing with such divisors, but
> thought the problem is only if because of that un < vn doesn't imply the
> quotient is 0 and remainder u.
> But as this testcase shows, the problem is with such divisors always.
> What happens is that we use __builtin_clz* on the most significant limb,
> and assume it will not be 0 because that is UB for the builtins.
> Normally the most significant limb of the divisor shouldn't be 0, as
> guaranteed by the bitint_reduce_prec e.g. for the positive numbers, unless
> the divisor is just 0 (but for vn == 1 we have special cases).
Just curious: could this have been caught by ubsan? (I don't know if
it knows about clz)
Thanks,
Christophe
>
> The following patch moves the handling of this corner case a few lines
> earlier before the un < vn check, because adjusting the vn later is harder.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested with
> make check-gcc -j32 -k GCC_TEST_RUN_EXPENSIVE=1
> RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg.exp='*bitint* pr112673.c
> builtin-stdc-bit-*.c pr112566-2.c pr112511.c' dg-torture.exp=*bitint*
> dfp.exp=*bitint*"
> on aarch64-linux, ok for trunk?
>
> 2024-04-18 Jakub Jelinek
>
> PR libgcc/114755
> * libgcc2.c (__divmodbitint4): Perform the decrement on negative
> v with most significant limb all ones and the second least
> significant limb with most significant bit clear always, regardless of
> un < vn.
>
> * gcc.dg/torture/bitint-69.c: New test.
>
> --- libgcc/libgcc2.c.jj 2024-03-21 13:07:43.629886730 +0100
> +++ libgcc/libgcc2.c2024-04-17 19:00:55.453691368 +0200
> @@ -1705,69 +1705,62 @@ __divmodbitint4 (UBILtype *q, SItype qpr
>USItype rn = ((USItype) rprec + W_TYPE_SIZE - 1) / W_TYPE_SIZE;
>USItype up = auprec % W_TYPE_SIZE;
>USItype vp = avprec % W_TYPE_SIZE;
> + /* If vprec < 0 and the top limb of v is all ones and the second most
> + significant limb has most significant bit clear, then just decrease
> + vn/avprec/vp, because after negation otherwise v2 would have most
> + significant limb clear. */
> + if (vprec < 0
> + && ((v[BITINT_END (0, vn - 1)] | (vp ? ((UWtype) -1 << vp) : 0))
> + == (UWtype) -1)
> + && vn > 1
> + && (Wtype) v[BITINT_END (1, vn - 2)] >= 0)
> +{
> + vp = 0;
> + --vn;
> +#if __LIBGCC_BITINT_ORDER__ == __ORDER_BIG_ENDIAN__
> + ++v;
> +#endif
> +}
>if (__builtin_expect (un < vn, 0))
> {
> - /* If abs(v) > abs(u), then q is 0 and r is u.
> -Unfortunately un < vn doesn't always mean abs(v) > abs(u).
> -If uprec > 0 and vprec < 0 and vn == un + 1, if the
> -top limb of v is all ones and the second most significant
> -limb has most significant bit clear, then just decrease
> -vn/avprec/vp and continue, after negation both numbers
> -will have the same number of limbs. */
> - if (un + 1 == vn
> - && uprec >= 0
> - && vprec < 0
> - && ((v[BITINT_END (0, vn - 1)] | (vp ? ((UWtype) -1 << vp) : 0))
> - == (UWtype) -1)
> - && (Wtype) v[BITINT_END (1, vn - 2)] >= 0)
> - {
> - vp = 0;
> - --vn;
> + /* q is 0 and r is u. */
> + if (q)
> + __builtin_memset (q, 0, qn * sizeof (UWtype));
> + if (r == NULL)
> + return;
> #if __LIBGCC_BITINT_ORDER__ == __ORDER_BIG_ENDIAN__
> - ++v;
> + r += rn - 1;
> + u += un - 1;
> #endif
> + if (up)
> + --un;
> + if (rn < un)
> + un = rn;
> + for (rn -= un; un; --un)
> + {
> + *r = *u;
> + r += BITINT_INC;
> + u += BITINT_INC;
> }
> - else
> + if (!rn)
> + return;
> + if (up)
> {
> - /* q is 0 and r is u. */
> - if (q)
> - __builtin_memset (q, 0, qn * sizeof (UWtype));
> - if (r == NULL)
> + if (uprec > 0)
> + *r = *u & (((UWtype) 1 << up) - 1);
> + else
> + *r = *u | ((UWtype) -1 << up);
> + r += BITINT_INC;
> + if (!--rn)
> return;
> -#if __LIBGCC_BITINT_ORDER__ == __ORDER_BIG_ENDIAN__
> - r += rn - 1;
> - u += un - 1;
> -#endif
> - if (up)
> - --un;
> - if (rn < un)
> - un = rn;
> - for (rn -= un; un; --un)
> - {
> - *r = *u;
> - r += BITINT_INC;
> - u +=
[PATCH] libcpp: Regenerate aclocal.m4 and configure [PR 114748]
As discussed in the PR, aclocal.m4 and configure were incorrectly regenerated at some point. 2024-04-17 Christophe Lyon PR preprocessor/114748 libcpp/ * aclocal.m4: Regenerate. * configure: Regenerate. --- libcpp/aclocal.m4 | 1 + libcpp/configure | 3 +++ 2 files changed, 4 insertions(+) diff --git a/libcpp/aclocal.m4 b/libcpp/aclocal.m4 index 4fc81709622..4d898ea2c97 100644 --- a/libcpp/aclocal.m4 +++ b/libcpp/aclocal.m4 @@ -26,6 +26,7 @@ m4_include([../config/lib-ld.m4]) m4_include([../config/lib-link.m4]) m4_include([../config/lib-prefix.m4]) m4_include([../config/nls.m4]) +m4_include([../config/override.m4]) m4_include([../config/po.m4]) m4_include([../config/progtest.m4]) m4_include([../config/warnings.m4]) diff --git a/libcpp/configure b/libcpp/configure index 8a38c0546e3..32d6aaa3069 100755 --- a/libcpp/configure +++ b/libcpp/configure @@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu + + + ac_aux_dir= for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do if test -f "$ac_dir/install-sh"; then -- 2.34.1
Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output
ping?
On Tue, 6 Feb 2024 at 10:26, Christophe Lyon wrote:
>
> ping?
>
> On Thu, 25 Jan 2024 at 16:54, Christophe Lyon
> wrote:
> >
> > On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote:
> > >
> > > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> > > >
> > > > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
> > >
> > > We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> > >
> >
> > Hmm, right, sorry I had this patch in my tree for quite some time, but
> > wrote the description just now, so I read a bit too quickly.
> >
> > >
> > > > possibly leading to mismatches under racy conditions.
> > >
> > > What do we incorrectly match? Is the problem that a \r\n sequence
> > > might be incompletely printed, due to buffering, and so the regex only
> > > sees (and matches) the \r which then leaves an unwanted \n in the
> > > stream, which then interferes with the next match? I don't understand
> > > why that problem wouldn't just result in a failed match with your new
> > > regex though.
> > >
> > Exactly: READ1 forces read() to return 1 byte at a time, so we leave
> > an unwanted \r in front of a string that should otherwise match the
> > "got" case.
> >
> > >
> > > >
> > > > I noticed this while running the GCC testsuite using the equivalent of
> > > > GDB's READ1 feature [1] which helps detecting bufferization issues.
> > > >
> > > > Adjusting the first regexp to match the right order implied fixing the
> > > > second one, to skip the empty lines.
> > >
> > > At the very least, this part of the description is misleading. The
> > > existing regex matches "the right order" already. The change is to
> > > match *exactly* \r\n instead of any mix of CR and LF characters.
> > > That's not about matching "the right order", it's being more precise
> > > in what we match.
> > >
> > > But I'm still confused about what the failure scenario is and how the
> > > change fixes it.
> > >
> >
> > I followed what the GDB testsuite does (it matches \r\n at the end of
> > many regexps), but in fact it seems it's not needed:
> > it works if I update the "got" regexp like this (ie. accept any number
> > of leading \r or \n):
> > - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > + -re {^[\n\r]*(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > and leave the "skipping" regexp as it is currently.
> >
> > Is the new attached version OK?
> >
> > Thanks,
> >
> > Christophe
> >
> > > >
> > > > Tested on aarch64-linux-gnu.
> > > >
> > > > [1]
> > > > https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
> > > >
> > > > 2024-01-24 Christophe Lyon
> > > >
> > > > libstdc++-v3/
> > > > * testsuite/lib/gdb-test.exp (gdb-test): Fix regexps.
> > > > ---
> > > > libstdc++-v3/testsuite/lib/gdb-test.exp | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > > b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > > index 31206f2fc32..0de8d9ee153 100644
> > > > --- a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > > +++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > > @@ -194,7 +194,7 @@ proc gdb-test { marker {selector {}} {load_xmethods
> > > > 0} } {
> > > >
> > > > set test_counter 0
> > > > remote_expect target [timeout_value] {
> > > > - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > > > + -re {^(type|\$([0-9]+)) = ([^\n\r]*)\r\n} {
> > > > send_log "got: $expect_out(buffer)"
> > > >
> > > > incr test_counter
> > > > @@ -250,7 +250,7 @@ proc gdb-test { marker {selector {}} {load_xmethods
> > > > 0} } {
> > > > return
> > > > }
> > > >
> > > > - -re {^[^$][^\n\r]*[\n\r]+} {
> > > > + -re {^[\r\n]*[^$][^\n\r]*\r\n} {
> > > > send_log "skipping: $expect_out(buffer)"
> > > > exp_continue
> > > > }
> > > > --
> > > > 2.34.1
> > > >
> > >
[PATCH] rust: Add rust.install-dvi and rust.install-html rules
rust has the (empty) rust.dvi and rust.html rules, but lacks the (empty) rust.install-dvi and rust.install-html ones. 2024-04-04 Christophe Lyon gcc/rust/ * Make-lang.in (rust.install-dvi, rust.install-html): New rules. --- gcc/rust/Make-lang.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in index 4d646018792..4d73412739d 100644 --- a/gcc/rust/Make-lang.in +++ b/gcc/rust/Make-lang.in @@ -342,6 +342,8 @@ selftest-rust-valgrind: $(RUST_SELFTEST_DEPS) # should have dependencies on info files that should be installed. rust.install-info: +rust.install-dvi: +rust.install-html: rust.install-pdf: # Install man pages for the front end. This target should ignore errors. -- 2.34.1
[PATCH] modula2: Add m2.install-dvi in gcc/m2/Make-lang.in
m2 has a m2.dvi build rule, but lacks the m2.install-dvi one. 2024-04-04 Christophe Lyon gcc/m2/ * Make-lang.in (m2.install-dvi): New rule. --- gcc/m2/Make-lang.in | 12 1 file changed, 12 insertions(+) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index e56240b4c44..0abd8ce1455 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -162,6 +162,18 @@ m2.dvi: doc/m2.dvi doc/m2.dvi: $(TEXISRC) $(objdir)/m2/images/gnu.eps $(TEXI2DVI) -c -I $(objdir)/m2 -I $(srcdir)/doc/include -o $@ $(srcdir)/doc/gm2.texi +M2_DVIFILES = doc/m2.dvi + +m2.install-dvi: $(M2_DVIFILES) + @$(NORMAL_INSTALL) + test -z "$(dvidir)/gcc" || $(mkinstalldirs) "$(DESTDIR)$(dvidir)/gcc" + @list='$(M2_DVIFILES)'; for p in $$list; do \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ + f=$(dvi__strip_dir) \ + echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(dvidir)/gcc/$$f'"; \ + $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(dvidir)/gcc/$$f"; \ + done + doc/m2.ps: doc/m2.dvi dvips -o $@ $< -- 2.34.1
[PATCH] go: Add go.install-dvi rule in go/Make-lang.in
go has a go.dvi build rule, but lacks the go.install-dvi one. 2024-04-04 Christophe Lyon gcc/go/ * Make-lang.in (go.install-dvi): New rule. --- gcc/go/Make-lang.in | 10 ++ 1 file changed, 10 insertions(+) diff --git a/gcc/go/Make-lang.in b/gcc/go/Make-lang.in index 9a31eafa219..5c569a40389 100644 --- a/gcc/go/Make-lang.in +++ b/gcc/go/Make-lang.in @@ -175,6 +175,16 @@ go.install-pdf: doc/gccgo.pdf $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(pdfdir)/gcc/$$f"; \ done +go.install-dvi: doc/gccgo.dvi + @$(NORMAL_INSTALL) + test -z "$(dvidir)" || $(mkinstalldirs) "$(DESTDIR)$(dvidir)/gcc" + @for p in doc/gccgo.dvi; do \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ + f=$(dvi__strip_dir) \ + echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(dvidir)/gcc/$$f'"; \ + $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(dvidir)/gcc/$$f"; \ + done + go.install-html: $(build_htmldir)/go @$(NORMAL_INSTALL) test -z "$(htmldir)" || $(mkinstalldirs) "$(DESTDIR)$(htmldir)" -- 2.34.1
[PATCH 2/2] modula2: Fix m2.install-info in gcc/m2/Make-lang.in
Fix a few typos: the generated filename is m2.info (not gm2.info, and gm2$(exeext) is a file not a directory (so test -d would always fail). 2024-03-29 Christophe Lyon gcc/m2/ * Make-lang.in (m2.install-info): Fix rule. --- gcc/m2/Make-lang.in | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index 2d8a47a1b1f..e56240b4c44 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -400,20 +400,20 @@ m2.install-common: installdirs done m2.install-info: installdirs - if [ -d gm2$(exeext) ] ; then \ - if [ -f $(objdir)/doc/gm2.info ]; then \ - rm -f $(DESTDIR)$(infodir)/gm2.info*; \ - for f in $(objdir)/doc/gm2.info*; do \ + if [ -f gm2$(exeext) ] ; then \ + if [ -f $(objdir)/doc/m2.info ]; then \ + rm -f $(DESTDIR)$(infodir)/m2.info*; \ + for f in $(objdir)/doc/m2.info*; do \ realfile=`echo $$f | sed -e 's|.*/\([^/]*\)$$|\1|'`; \ rm -f $(DESTDIR)$(infodir)/`basename $$realfile`; \ $(INSTALL_DATA) $$f $(DESTDIR)$(infodir)/`basename $$realfile`; \ done; \ - chmod a-x $(DESTDIR)$(infodir)/gm2.info*; \ + chmod a-x $(DESTDIR)$(infodir)/m2.info*; \ else true; fi; \ else true; fi - -if [ -f gm2$(exeext) ] && [ -f $(DESTDIR)$(infodir)/gm2.info ]; then \ + -if [ -f gm2$(exeext) ] && [ -f $(DESTDIR)$(infodir)/m2.info ]; then \ if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \ - install-info --dir-file=$(infodir)/dir $(DESTDIR)$(infodir)/gm2.info; \ + install-info --dir-file=$(infodir)/dir $(DESTDIR)$(infodir)/m2.info; \ else true; fi; \ else true; fi -- 2.34.1
[PATCH 1/2] modula2: Add m2.install-html rule to gcc/m2/Make-lang.in
This rule was missing, and 'make install-html' was failing. It is copied from the corresponding one in fortran. 2024-03-29 Christophe Lyon gcc/m2/ * Make-lang.in (install-html): New rule. --- gcc/m2/Make-lang.in | 19 +++ 1 file changed, 19 insertions(+) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index ef6990ce617..2d8a47a1b1f 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -206,6 +206,25 @@ $(build_htmldir)/m2/index.html: $(TEXISRC) $(objdir)/m2/images/gnu.eps rm -f $(@D)/* $(TEXI2HTML) -I $(objdir)/m2 -I $(srcdir)/m2 -I $(gcc_docdir)/include -o $(@D) $< +M2_HTMLFILES = $(build_htmldir)/m2 + +m2.install-html: $(M2_HTMLFILES) + @$(NORMAL_INSTALL) + test -z "$(htmldir)" || $(mkinstalldirs) "$(DESTDIR)$(htmldir)" + @list='$(M2_HTMLFILES)'; for p in $$list; do \ + if test -f "$$p" || test -d "$$p"; then d=""; else d="$(srcdir)/"; fi; \ + f=$(html__strip_dir) \ + if test -d "$$d$$p"; then \ + echo " $(mkinstalldirs) '$(DESTDIR)$(htmldir)/$$f'"; \ + $(mkinstalldirs) "$(DESTDIR)$(htmldir)/$$f" || exit 1; \ + echo " $(INSTALL_DATA) '$$d$$p'/* '$(DESTDIR)$(htmldir)/$$f'"; \ + $(INSTALL_DATA) "$$d$$p"/* "$(DESTDIR)$(htmldir)/$$f"; \ + else \ + echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(htmldir)/$$f'"; \ + $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(htmldir)/$$f"; \ + fi; \ + done + # gm2-libs.texi m2/gm2-libs.texi: gm2-libs.texi-check; @true -- 2.34.1
[committed] [aarch64, testsuite]: Fix lrcpc3 testcase
There was a typo in the testcase, with GCC_CPUINFO pointing to the
wrong file.
Committed as obvious.
2024-03-29 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/cpunative/native_cpu_24.c: Fix GCC_CPUINFO.
---
gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
index 05dc870885f..3a720cc8552 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { { aarch64*-*-linux*} && native } } } */
-/* { dg-set-compiler-env-var GCC_CPUINFO
"$srcdir/gcc.target/aarch64/cpunative/info_23" } */
+/* { dg-set-compiler-env-var GCC_CPUINFO
"$srcdir/gcc.target/aarch64/cpunative/info_24" } */
/* { dg-additional-options "-mcpu=native --save-temps " } */
int main()
--
2.34.1
[PATCH] aarch64: Fix typo in comment about FEATURE_STRING
Fix the comment to document FEATURE_STRING instead of FEAT_STRING.
2024-03-29 Christophe Lyon
gcc/
* config/aarch64/aarch64-option-extensions.def: Fix comment.
---
gcc/config/aarch64/aarch64-option-extensions.def | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/config/aarch64/aarch64-option-extensions.def
b/gcc/config/aarch64/aarch64-option-extensions.def
index 061a145e9e7..aa3cd99f791 100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -54,14 +54,14 @@
If a feature A appears in this list then the list implicitly includes
any features that are transitively dependent on A (according to REQUIRES).
- - FEAT_STRING is a string containing the entries in the 'Features' field of
- /proc/cpuinfo on a GNU/Linux system that correspond to this architecture
- extension being available. Sometimes multiple entries are needed to
enable
- the extension (for example, the 'crypto' extension depends on four
- entries: aes, pmull, sha1, sha2 being present). In that case this field
- should contain a space (" ") separated list of the strings in 'Features'
- that are required. Their order is not important. An empty string means
- do not detect this feature during auto detection.
+ - FEATURE_STRING is a string containing the entries in the 'Features' field
+ of /proc/cpuinfo on a GNU/Linux system that correspond to this
+ architecture extension being available. Sometimes multiple entries are
+ needed to enable the extension (for example, the 'crypto' extension
+ depends on four entries: aes, pmull, sha1, sha2 being present). In that
+ case this field should contain a space (" ") separated list of the strings
+ in 'Features' that are required. Their order is not important. An empty
+ string means do not detect this feature during auto detection.
- OPT_FLAGS is a list of feature IDENTS that should be enabled (along with
their transitive dependencies) when the specified FMV feature is present.
--
2.34.1
Re: [PATCH] libgcc: arm: fix build for FDPIC target
Hi, On 3/22/24 21:14, Max Filippov wrote: libgcc/ * unwind-arm-common.inc (__gnu_personality_sigframe_fdpic): Cast last argument of _Unwind_VRS_Set to void *. --- libgcc/unwind-arm-common.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/unwind-arm-common.inc b/libgcc/unwind-arm-common.inc index 5453f38186b5..576f7e93e8a8 100644 --- a/libgcc/unwind-arm-common.inc +++ b/libgcc/unwind-arm-common.inc @@ -248,7 +248,7 @@ __gnu_personality_sigframe_fdpic (_Unwind_State state, + ARM_SIGCONTEXT_R0; /* Restore regs saved on stack by the kernel. */ for (i = 0; i < 16; i++) - _Unwind_VRS_Set (context, _UVRSC_CORE, i, _UVRSD_UINT32, sp + 4 * i); + _Unwind_VRS_Set (context, _UVRSC_CORE, i, _UVRSD_UINT32, (void *)(sp + 4 * i)); LGTM (but I'm not a maintainer). Thanks, Christophe return _URC_CONTINUE_UNWIND; }
Re: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for AArch64
On Mon, 18 Mar 2024 at 22:35, Evgeny Karpov wrote: > > Monday, March 18, 2024 2:27 PM > Christophe Lyon wrote: > > > > +/* Disable SEH and declare the required SEH-related macros that are > > > +still needed for compilation. */ #undef TARGET_SEH #define > > > +TARGET_SEH 0 > > > + > > > +#define SSE_REGNO_P(N) 0 > > > +#define GENERAL_REGNO_P(N) 0 > > I think you forgot to add a comment to explain the above two lines. > > (it was requested during v1 review) > > > > Thanks, > > > > Christophe > > Hi Christophe, > > Thank you for the review! > The comment regarding SEH and SEH-related macros has been added two lines > above. > It may not be obvious, but these macros are needed to emit SEH data in > mingw/winnt.cc. > This group is separated by an empty line; however, it still relates to > SEH-related macros. > Thanks for the clarification, I thought that comment only applied to the two lines about TARGET_SEH. Christophe > Regards, > Evgeny
Re: [PATCH v2 00/13] Add aarch64-w64-mingw32 target
On Thu, 7 Mar 2024 at 21:48, Evgeny Karpov wrote: > > Monday, March 4, 2024 > Evgeny Karpov wrote: > > > > > Changes from v1 to v2: > > Adjust the target name to aarch64-*-mingw* to exclude the big-endian target > > from support. > > Exclude 64-bit ISA. > > Rename enum calling_abi to aarch64_calling_abi. > > Move AArch64 MS ABI definitions FIXED_REGISTERS, > > CALL_REALLY_USED_REGISTERS, and STATIC_CHAIN_REGNUM from aarch64.h > > to aarch64-abi-ms.h. > > Rename TARGET_ARM64_MS_ABI to TARGET_AARCH64_MS_ABI. > > Exclude TARGET_64BIT from the aarch64 target. > > Exclude HAVE_GAS_WEAK. > > Set HAVE_GAS_ALIGNED_COMM to 1 by default. > > Use a reference from "x86 Windows Options" to "Cygwin and MinGW > > Options". > > Update commit descriptions to follow standard style. > > Rebase from 4th March 2024. > > Hello, > > It looks like the initial feedback has been addressed. I had a look at the v2 series, and besides a minor comment patch #8, ISTM than all the comments your received about v1 have been addressed, indeed. > While unit testing for the x86_64-w64-mingw32 target is still in > progress, the first 4 patches do not obviously change other > targets, including aarch64-linux-gnu. > Could they be merged once stage 1 starts, > or could it be done even now? What would be the benefit of committing only the first 4 patches? (whether now or when stage 1 reopens) Thanks, Christophe > Thanks! > > Regards, > Evgeny >
Re: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for AArch64
Hi!
On Mon, 4 Mar 2024 at 18:44, Evgeny Karpov wrote:
>
> From: Zac Walker
> Date: Fri, 1 Mar 2024 10:49:28 +0100
> Subject: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for
> AArch64
>
> Define Cygwin and MinGW environment such as types, SEH definitions,
> shared libraries, etc.
>
> gcc/ChangeLog:
>
> * config.gcc: Add Cygwin and MinGW difinitions.
> * config/aarch64/aarch64-protos.h
> (mingw_pe_maybe_record_exported_symbol): Declare functions
> which are used in Cygwin and MinGW environment.
> (mingw_pe_section_type_flags): Likewise.
> (mingw_pe_unique_section): Likewise.
> (mingw_pe_encode_section_info): Likewise.
> * config/aarch64/cygming.h: New file.
> ---
> gcc/config.gcc | 4 +
> gcc/config/aarch64/aarch64-protos.h | 5 +
> gcc/config/aarch64/cygming.h| 175
> 3 files changed, 184 insertions(+)
> create mode 100644 gcc/config/aarch64/cygming.h
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 3aca257c322..4471599454b 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1267,7 +1267,11 @@ aarch64*-*-linux*)
> aarch64-*-mingw*)
> tm_file="${tm_file} aarch64/aarch64-abi-ms.h"
> tm_file="${tm_file} aarch64/aarch64-coff.h"
> + tm_file="${tm_file} aarch64/cygming.h"
> + tm_file="${tm_file} mingw/mingw32.h"
> + tm_file="${tm_file} mingw/mingw-stdint.h"
> tmake_file="${tmake_file} aarch64/t-aarch64"
> + target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
> case ${enable_threads} in
> "" | yes | win32)
> thread_file='win32'
> diff --git a/gcc/config/aarch64/aarch64-protos.h
> b/gcc/config/aarch64/aarch64-protos.h
> index bd719b992a5..759e1a0f9da 100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -1110,6 +1110,11 @@ extern void aarch64_output_patchable_area (unsigned
> int, bool);
>
> extern void aarch64_adjust_reg_alloc_order ();
>
> +extern void mingw_pe_maybe_record_exported_symbol (tree, const char *, int);
> +extern unsigned int mingw_pe_section_type_flags (tree, const char *, int);
> +extern void mingw_pe_unique_section (tree, int);
> +extern void mingw_pe_encode_section_info (tree, rtx, int);
> +
> bool aarch64_optimize_mode_switching (aarch64_mode_entity);
> void aarch64_restore_za (rtx);
>
> diff --git a/gcc/config/aarch64/cygming.h b/gcc/config/aarch64/cygming.h
> new file mode 100644
> index 000..2f239c42a89
> --- /dev/null
> +++ b/gcc/config/aarch64/cygming.h
> @@ -0,0 +1,175 @@
> +/* Operating system specific defines to be used when targeting GCC for
> + hosting on Windows32, using a Unix style C library and tools.
> + Copyright (C) 1995-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
> +
[PATCH] arm: [MVE intrinsics] Fix support for loads [PR target/114323]
The testcase in this PR shows that we would load from an uninitialized
location, because the vld1 instrinsics are reported as "const". This
is because function_instance::reads_global_state_p() does not take
CP_READ_MEMORY into account. Fixing this gives vld1 the "pure"
attribute instead, and solves the problem.
2024-03-15 Christophe Lyon
PR target/114323
gcc/
* config/arm/arm-mve-builtins.cc
(function_instance::reads_global_state_p): Take CP_READ_MEMORY
into account.
gcc/testsuite/
* gcc.target/arm/mve/pr114323.c: New.
---
gcc/config/arm/arm-mve-builtins.cc | 2 +-
gcc/testsuite/gcc.target/arm/mve/pr114323.c | 22 +
2 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/arm/mve/pr114323.c
diff --git a/gcc/config/arm/arm-mve-builtins.cc
b/gcc/config/arm/arm-mve-builtins.cc
index 2f2c0f4a02a..6a5775c67e5 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -746,7 +746,7 @@ function_instance::reads_global_state_p () const
if (flags & CP_READ_FPCR)
return true;
- return false;
+ return flags & CP_READ_MEMORY;
}
/* Return true if calls to the function could modify some form of
diff --git a/gcc/testsuite/gcc.target/arm/mve/pr114323.c
b/gcc/testsuite/gcc.target/arm/mve/pr114323.c
new file mode 100644
index 000..bd9127b886a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/pr114323.c
@@ -0,0 +1,22 @@
+/* { dg-do run } */
+/* { dg-require-effective-target arm_mve_hw } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+
+#include
+
+__attribute__((noipa))
+uint32x4_t foo (void) {
+ uint32x4_t V0 = vld1q_u32(((const uint32_t[4]){1, 2, 3, 4}));
+ return V0;
+}
+
+int main(void)
+{
+ uint32_t buf[4];
+ vst1q_u32 (buf, foo());
+
+ for (int i = 0; i < 4; i++)
+if (buf[i] != i+1)
+ __builtin_abort ();
+}
--
2.34.1
Re: [PATCH] aarch64: Add +lse128 architectural extension command-line flag
On Fri, 15 Mar 2024 at 12:15, Victor Do Nascimento
wrote:
>
> 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.
> ---
> 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")
>
FWIW, looks good to me, I noticed that now we'll also have the
dependency of d128 on lse128, although d128 didn't have the (implicit)
dependency on lse before.
Christophe
> 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. */
> --
> 2.34.1
>
Re: [PATCH] c++: Fix ICE due to folding a call to constructor on cdtor_returns_this arches (aka arm32) [PR113083]
On Fri, 23 Feb 2024 at 10:13, Christophe Lyon
wrote:
>
> On Fri, 23 Feb 2024 at 09:42, Jakub Jelinek wrote:
> >
> > Hi!
> >
> > When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
> > constructor is supposed to return this pointer, but when we cp_fold such
> > a call, we don't take that into account and just INIT_EXPR the object,
> > so we can later ICE during gimplification, because the expression doesn't
> > have the right type.
> >
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux and
> > tested with a cross to armv7-linux-gnueabi on the testcase, but
> > unfortunately there are no 32-bit arm boxes in cfarm and arm32 is gone from
> > Fedora for quite some time as well, so I have no easy way to test this.
> > Christophe, do you think you could test this? Thanks.
>
> Hi Jakub,
>
> Sadly our precommit CI could not apply your patch automatically (as
> you can see in patchwork).
>
> I'll test your patch manually.
>
I can now confirm that the new test passes on arm (native
armv8l-unknown-linux-gnueabihf), and no regression.
Thanks,
Christophe
> Thanks,
>
> Christophe
>
> >
> > 2024-02-23 Jakub Jelinek
> >
> > PR c++/113083
> > * cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
> > wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0).
> >
> > * g++.dg/cpp0x/constexpr-113083.C: New test.
> >
> > --- gcc/cp/cp-gimplify.cc.jj2024-02-22 21:45:09.663430066 +0100
> > +++ gcc/cp/cp-gimplify.cc 2024-02-22 22:30:23.481428242 +0100
> > @@ -3412,9 +3412,15 @@ cp_fold (tree x, fold_flags_t flags)
> > if (DECL_CONSTRUCTOR_P (callee))
> > {
> > loc = EXPR_LOCATION (x);
> > - tree s = build_fold_indirect_ref_loc (loc,
> > - CALL_EXPR_ARG (x, 0));
> > + tree a = CALL_EXPR_ARG (x, 0);
> > + bool return_this = targetm.cxx.cdtor_returns_this ();
> > + if (return_this)
> > + a = cp_save_expr (a);
> > + tree s = build_fold_indirect_ref_loc (loc, a);
> > r = cp_build_init_expr (s, r);
> > + if (return_this)
> > + r = build2_loc (loc, COMPOUND_EXPR, TREE_TYPE (x), r,
> > + fold_convert_loc (loc, TREE_TYPE (x), a));
> > }
> > x = r;
> > break;
> > --- gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C.jj2024-01-13
> > 00:05:00.077372302 +0100
> > +++ gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C 2024-02-22
> > 22:20:20.622618992 +0100
> > @@ -0,0 +1,16 @@
> > +// PR c++/113083
> > +// { dg-do compile { target c++11 } }
> > +// { dg-options "-Os" }
> > +
> > +struct A { constexpr A (); };
> > +
> > +void
> > +foo ()
> > +{
> > + A b;
> > +}
> > +
> > +constexpr
> > +A::A ()
> > +{
> > +}
> >
> > Jakub
> >
Re: [PATCH] c++: Fix ICE due to folding a call to constructor on cdtor_returns_this arches (aka arm32) [PR113083]
On Fri, 23 Feb 2024 at 09:42, Jakub Jelinek wrote:
>
> Hi!
>
> When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
> constructor is supposed to return this pointer, but when we cp_fold such
> a call, we don't take that into account and just INIT_EXPR the object,
> so we can later ICE during gimplification, because the expression doesn't
> have the right type.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux and
> tested with a cross to armv7-linux-gnueabi on the testcase, but
> unfortunately there are no 32-bit arm boxes in cfarm and arm32 is gone from
> Fedora for quite some time as well, so I have no easy way to test this.
> Christophe, do you think you could test this? Thanks.
Hi Jakub,
Sadly our precommit CI could not apply your patch automatically (as
you can see in patchwork).
I'll test your patch manually.
Thanks,
Christophe
>
> 2024-02-23 Jakub Jelinek
>
> PR c++/113083
> * cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
> wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0).
>
> * g++.dg/cpp0x/constexpr-113083.C: New test.
>
> --- gcc/cp/cp-gimplify.cc.jj2024-02-22 21:45:09.663430066 +0100
> +++ gcc/cp/cp-gimplify.cc 2024-02-22 22:30:23.481428242 +0100
> @@ -3412,9 +3412,15 @@ cp_fold (tree x, fold_flags_t flags)
> if (DECL_CONSTRUCTOR_P (callee))
> {
> loc = EXPR_LOCATION (x);
> - tree s = build_fold_indirect_ref_loc (loc,
> - CALL_EXPR_ARG (x, 0));
> + tree a = CALL_EXPR_ARG (x, 0);
> + bool return_this = targetm.cxx.cdtor_returns_this ();
> + if (return_this)
> + a = cp_save_expr (a);
> + tree s = build_fold_indirect_ref_loc (loc, a);
> r = cp_build_init_expr (s, r);
> + if (return_this)
> + r = build2_loc (loc, COMPOUND_EXPR, TREE_TYPE (x), r,
> + fold_convert_loc (loc, TREE_TYPE (x), a));
> }
> x = r;
> break;
> --- gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C.jj2024-01-13
> 00:05:00.077372302 +0100
> +++ gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C 2024-02-22
> 22:20:20.622618992 +0100
> @@ -0,0 +1,16 @@
> +// PR c++/113083
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-Os" }
> +
> +struct A { constexpr A (); };
> +
> +void
> +foo ()
> +{
> + A b;
> +}
> +
> +constexpr
> +A::A ()
> +{
> +}
>
> Jakub
>
Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
On Mon, 12 Feb 2024 at 11:27, Jakub Jelinek wrote: > > On Mon, Feb 12, 2024 at 11:13:49AM +0100, Christophe Lyon wrote: > > On Sun, 11 Feb 2024 at 06:56, Alexandre Oliva wrote: > > > > > > Hello, Christophe, > > > > > > On Feb 10, 2024, Christophe Lyon wrote: > > > > > > > gcc/ > > > > * Makefile.in: Add no-info dependency. > > > > * configure.ac: Set BUILD_INFO=no-info if makeinfo is not > > > > available. > > > > * configure: Regenerate. > > > > > > Thank you, this is ok. > > > > > > Now, this doesn't fix a regression, does it? > > > > Of course not :-) > > > > > > > > I would support putting this in for GCC 14, but I would be overstepping > > > my authority if I approved even such a small and well-contained > > > improvement patch in the current stage, so I'm approving it for stage1, > > > but maybe some global maintainer or release manager will chime in in > > > support for earlier merging? (hint, hint ;-) > > > > Thanks! > > This is ok for GCC 14 as an exception, but if any issues related to that > are found, please be prepared to revert and resubmit for GCC 15. > Sure! Thanks, Christophe > Jakub >
Re: [PATCH] rtl-optimization/113597 - recover base term for argument pointers
On Mon, 12 Feb 2024 at 09:00, Richard Biener wrote:
>
> On Sat, Feb 10, 2024 at 10:21 PM Toon Moene wrote:
> >
> > I managed to try this patch on aarch64-linux-gnu:
> >
> > This is the test run without your patch:
> >
> > https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807637.html
> >
> > And this is the "result" with your patch:
> >
> > https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807645.html
>
> Interesting .. this looks like a miscompile of stage2. Note that the Linaro
> CI was happy:
>
> https://patchwork.sourceware.org/project/gcc/patch/20240209102649.09c543858...@sourceware.org/
>
Hi!
Indeed this is NOT a bootstrap build, we only have such checks in postcommit CI.
Thanks,
Christophe
> Richard.
>
> > For me, as for you, it works for x86_64-linux-gnu:
> >
> > https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807609.html
> >
> > I hope this helps.
> >
> > Kind regards,
> > Toon Moene.
> >
> > On 2/9/24 11:26, Richard Biener wrote:
> > > The following allows a base term to be derived from an existing
> > > MEM_EXPR, notably the points-to set of a MEM_REF base. For the
> > > testcase in the PR this helps RTL DSE elide stores to a stack
> > > temporary. This covers pointers to NONLOCAL which can be mapped
> > > to arg_base_value, helping to disambiguate against other special
> > > bases (ADDRESS) as well as PARM_DECL accesses.
> > >
> > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > >
> > > This is an attempt to recover some of the losses from dumbing down
> > > find_base_{term,value}. I did give my ideas how to properly do
> > > this during stage1 a start, I will post a short incomplete RFC series
> > > later today.
> > >
> > > OK for trunk?
> > >
> > > I've included all languages in testing and also tested with -m32 but
> > > details of RTL alias analysis might escape me ...
> > >
> > > Thanks,
> > > Richard.
> > >
> > > PR rtl-optimization/113597
> > > * alias.cc (find_base_term): Add argument for the whole mem
> > > and derive a base term from its MEM_EXPR.
> > > (true_dependence_1): Pass down the MEMs to find_base_term.
> > > (write_dependence_p): Likewise.
> > > (may_alias_p): Likewise.
> > > ---
> > > gcc/alias.cc | 43 ---
> > > 1 file changed, 36 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/gcc/alias.cc b/gcc/alias.cc
> > > index 6fad4b29d31..e33c56b0e80 100644
> > > --- a/gcc/alias.cc
> > > +++ b/gcc/alias.cc
> > > @@ -40,6 +40,9 @@ along with GCC; see the file COPYING3. If not see
> > > #include "rtl-iter.h"
> > > #include "cgraph.h"
> > > #include "ipa-utils.h"
> > > +#include "stringpool.h"
> > > +#include "value-range.h"
> > > +#include "tree-ssanames.h"
> > >
> > > /* The aliasing API provided here solves related but different problems:
> > >
> > > @@ -190,6 +193,10 @@ static struct {
> > > arguments, since we do not know at this level whether accesses
> > > based on different arguments can alias. The ADDRESS has id 0.
> > >
> > > + This is solely useful to disambiguate against other ADDRESS
> > > + bases as we know incoming pointers cannot point to local
> > > + stack, frame or argument space.
> > > +
> > >2. stack_pointer_rtx, frame_pointer_rtx, hard_frame_pointer_rtx
> > > (if distinct from frame_pointer_rtx) and arg_pointer_rtx.
> > > Each of these rtxes has a separate ADDRESS associated with it,
> > > @@ -2113,12 +2120,34 @@ find_base_term (rtx x, vec > > to avoid visiting them multiple times. We unwind that changes here.
> > > */
> > >
> > > static rtx
> > > -find_base_term (rtx x)
> > > +find_base_term (rtx x, const_rtx mem = NULL_RTX)
> > > {
> > > auto_vec, 32>
> > > visited_vals;
> > > rtx res = find_base_term (x, visited_vals);
> > > for (unsigned i = 0; i < visited_vals.length (); ++i)
> > > visited_vals[i].first->locs = visited_vals[i].second;
> > > + if (!res && mem && MEM_EXPR (mem))
> > > +{
> > > + tree base = get_base_address (MEM_EXPR (mem));
> > > + if (TREE_CODE (base) == PARM_DECL
> > > + && DECL_RTL_SET_P (base))
> > > + /* We need to look at how we expanded a PARM_DECL. It might be in
> > > +the argument space (UNIQUE_BASE_VALUE_ARGP) or it might
> > > +be spilled (UNIQUE_BASE_VALUE_FP/UNIQUE_BASE_VALUE_HFP). */
> > > + res = find_base_term (DECL_RTL (base));
> > > + else if (TREE_CODE (base) == MEM_REF
> > > +&& TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME
> > > +&& SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0)))
> > > + {
> > > + auto pt = _NAME_PTR_INFO (TREE_OPERAND (base, 0))->pt;
> > > + if (pt->nonlocal
> > > + && !pt->anything
> > > + && !pt->escaped
> > > + && !pt->ipa_escaped
> > > + && bitmap_empty_p (pt->vars))
> > > + res = arg_base_value;
> > > + }
> > > +}
> > > return res;
>
Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
On Sun, 11 Feb 2024 at 06:56, Alexandre Oliva wrote: > > Hello, Christophe, > > On Feb 10, 2024, Christophe Lyon wrote: > > > gcc/ > > * Makefile.in: Add no-info dependency. > > * configure.ac: Set BUILD_INFO=no-info if makeinfo is not > > available. > > * configure: Regenerate. > > Thank you, this is ok. > > Now, this doesn't fix a regression, does it? Of course not :-) > > I would support putting this in for GCC 14, but I would be overstepping > my authority if I approved even such a small and well-contained > improvement patch in the current stage, so I'm approving it for stage1, > but maybe some global maintainer or release manager will chime in in > support for earlier merging? (hint, hint ;-) Thanks! > > -- > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ >Free Software Activist GNU Toolchain Engineer > Disinformation flourishes because many people care deeply about injustice but > very few check the facts. Think Assange & Stallman. The empires strike back
Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
Hi! On Tue, 6 Feb 2024 at 06:37, Alexandre Oliva wrote: > > Hello, Christophe, > > Thanks for the patch. > > On Feb 5, 2024, Christophe Lyon wrote: > > > In order to save build time, our CI overrides BUILD_INFO="", which > > works when invoking 'make all' but not for 'make install' in case some > > info files need an update. > > Hmm, I don't think this would be desirable. We ship updated info files > in release tarballs, and it would be desirable to install them even if > makeinfo is not available in the build environment. > > > I noticed this when testing a patch posted on the gcc-patches list, > > leading to an error at 'make install' time after updating tm.texi (the > > build reported 'new text' in tm.texi and stopped). This is because > > 'install' depends on 'install-info', which depends on > > $(DESTDIR)$(infodir)/gccint.info (among others). > > Ideally, we'd detect and report info files that are out-of-date WRT > their ultimate sources, especially to catch tm.texi.in changes, but > doing so only at install time is clearly suboptimal. > > I mean, if we don't have the tools to build info files, it's fine if we > skip their building, and even refrain from installing info files that > are missing or outdated, but we should install prebuilt ones if they're > available, and we should probably *not* refrain from trying to satisfy > the dependencies for info files at build time, even if it turns out that > we can't build the info files themselves. > > This suggests to me that, rather than setting BUILD_INFO to the empty > string, we should set it to e.g. no-info, so that $(MAKEINFO) will not > be run because x$(BUILD_INFO) != xinfo, but so that we still get the > dependencies resolved, e.g. by making no-info depend on info. Or maybe > make it info-check-deps, and insert that between info and its current > deps. WDYT? I've just spent quite a bit of time looking at your suggestion, and well... I hadn't considered the case of makeinfo missing/too old, in our use case makeinfo is present and recent enough but we want to save a few minutes of build time during the CI loop. As I mentioned, we (tried to) do this by doing BUILD_INFO="" when invoking 'make', and it took me ages to realize it is not working as expected, because GCC's top-level Makefile does not propagate BUILD_INFO recursively, and this conflicted with the setting of BUILD_INFO=no-info (I wanted to try to support several values for BUILD_INFO: info, no-info and "", where "" would disable more things, but it seems to be too much hassle) So, the attached small patch implements your suggestion, and works as expected: it makeinfo is not available, we now detect problems with tm.texi.in at build time rather than install time. OK? Looking deeper, I realized that texi2dvi and texi2pdf belong to the texinfo package, like makeinfo, so the dvi and pdf rules should probably also depend on BUILD_INFO? To generate html, we call makeinfo --html so the html rules should also depend on BUILD_INFO. However, unlike install-man, the install-html, install-dvi and install-pdf are not part of the plain 'install' target, so maybe we can argue that if someone runs 'make install-pdf' without texinfo, then too bad for him? Thanks, Christophe > > -- > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ >Free Software Activist GNU Toolchain Engineer > Disinformation flourishes because many people care deeply about injustice but > very few check the facts. Think Assange & Stallman. The empires strike back From 7ec6ff8ead24eb7c07d011371347cf12db11faf5 Mon Sep 17 00:00:00 2001 From: Christophe Lyon Date: Sat, 10 Feb 2024 21:17:08 + Subject: [PATCH v3] gcc/Makefile.in: Always check info dependencies BUILD_INFO is currently a byproduct of checking makeinfo presence/version. INSTALL_INFO used to be defined similarly, but was removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df (svn r38141). In order to save build time, our CI overrides MAKEINFO=echo, which works when invoking 'make all' but not for 'make install' in case some info files need an update. I noticed this while testing a patch posted on the gcc-patches list, leading to an error at 'make install' time after updating tm.texi (the build reported 'new text' in tm.texi and stopped). This is because 'install' depends on 'install-info', which depends on $(DESTDIR)$(infodir)/gccint.info (among others). As discussed, it is better to detect this problem during 'make all' rather than 'make install', and we still want to detect it even if makeinfo is not available. This patch makes configure set BUILD_INFO=no-info in case makeinfo is missing/too old, which effectively makes the build rules no-ops (x$(BUILD_INFO) != xinfo),
Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output
ping?
On Thu, 25 Jan 2024 at 16:54, Christophe Lyon
wrote:
>
> On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote:
> >
> > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> > >
> > > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
> >
> > We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> >
>
> Hmm, right, sorry I had this patch in my tree for quite some time, but
> wrote the description just now, so I read a bit too quickly.
>
> >
> > > possibly leading to mismatches under racy conditions.
> >
> > What do we incorrectly match? Is the problem that a \r\n sequence
> > might be incompletely printed, due to buffering, and so the regex only
> > sees (and matches) the \r which then leaves an unwanted \n in the
> > stream, which then interferes with the next match? I don't understand
> > why that problem wouldn't just result in a failed match with your new
> > regex though.
> >
> Exactly: READ1 forces read() to return 1 byte at a time, so we leave
> an unwanted \r in front of a string that should otherwise match the
> "got" case.
>
> >
> > >
> > > I noticed this while running the GCC testsuite using the equivalent of
> > > GDB's READ1 feature [1] which helps detecting bufferization issues.
> > >
> > > Adjusting the first regexp to match the right order implied fixing the
> > > second one, to skip the empty lines.
> >
> > At the very least, this part of the description is misleading. The
> > existing regex matches "the right order" already. The change is to
> > match *exactly* \r\n instead of any mix of CR and LF characters.
> > That's not about matching "the right order", it's being more precise
> > in what we match.
> >
> > But I'm still confused about what the failure scenario is and how the
> > change fixes it.
> >
>
> I followed what the GDB testsuite does (it matches \r\n at the end of
> many regexps), but in fact it seems it's not needed:
> it works if I update the "got" regexp like this (ie. accept any number
> of leading \r or \n):
> - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> + -re {^[\n\r]*(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> and leave the "skipping" regexp as it is currently.
>
> Is the new attached version OK?
>
> Thanks,
>
> Christophe
>
> > >
> > > Tested on aarch64-linux-gnu.
> > >
> > > [1]
> > > https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
> > >
> > > 2024-01-24 Christophe Lyon
> > >
> > > libstdc++-v3/
> > > * testsuite/lib/gdb-test.exp (gdb-test): Fix regexps.
> > > ---
> > > libstdc++-v3/testsuite/lib/gdb-test.exp | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > index 31206f2fc32..0de8d9ee153 100644
> > > --- a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > +++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > @@ -194,7 +194,7 @@ proc gdb-test { marker {selector {}} {load_xmethods
> > > 0} } {
> > >
> > > set test_counter 0
> > > remote_expect target [timeout_value] {
> > > - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > > + -re {^(type|\$([0-9]+)) = ([^\n\r]*)\r\n} {
> > > send_log "got: $expect_out(buffer)"
> > >
> > > incr test_counter
> > > @@ -250,7 +250,7 @@ proc gdb-test { marker {selector {}} {load_xmethods
> > > 0} } {
> > > return
> > > }
> > >
> > > - -re {^[^$][^\n\r]*[\n\r]+} {
> > > + -re {^[\r\n]*[^$][^\n\r]*\r\n} {
> > > send_log "skipping: $expect_out(buffer)"
> > > exp_continue
> > > }
> > > --
> > > 2.34.1
> > >
> >
Re: [PATCH] gcc/configure: Re-introduce INSTALL_INFO
On Fri, 2 Feb 2024 at 11:40, Christophe Lyon wrote: > > On Fri, 2 Feb 2024 at 11:10, wrote: > > > > On 1 February 2024 18:15:34 CET, Christophe Lyon > > wrote: > > >BUILD_INFO is currently a byproduct of checking makeinfo > > >presence/version. INSTALL_INFO used to be defined similarly, but was > > >removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df > > >(svn r38141). > > > > > >In order to save build time, our CI overrides BUILD_INFO="", which > > >works when invoking 'make all' but not for 'make install' in case some > > >info files need an update. > > > > Instead of resurrecting INSTALL_INFO maybe you could something along the > > lines of > > > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=15038=edit > > Ha indeed something along these lines would work too. > Thanks for the archaeology :-) > > > > > not sure which approach would be considered cleaner.. > Not sure either. > > What do maintainers prefer? > Actually that leads to a small patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644957.html > > > > HTH
[PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
BUILD_INFO is currently a byproduct of checking makeinfo presence/version. INSTALL_INFO used to be defined similarly, but was removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df (svn r38141). In order to save build time, our CI overrides BUILD_INFO="", which works when invoking 'make all' but not for 'make install' in case some info files need an update. I noticed this when testing a patch posted on the gcc-patches list, leading to an error at 'make install' time after updating tm.texi (the build reported 'new text' in tm.texi and stopped). This is because 'install' depends on 'install-info', which depends on $(DESTDIR)$(infodir)/gccint.info (among others). This patch makes the 'install-info' dependency in 'install' conditioned by BUILD_INFO. 2024-02-05 Christophe Lyon gcc/ * Makefile.in: Use install-info only if BUILD_INFO is not empty. --- gcc/Makefile.in | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 4d38b162307..6cb564cfd35 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -817,7 +817,6 @@ INSTALL_HEADERS=install-headers install-mkheaders # Control whether Info documentation is built and installed. BUILD_INFO = @BUILD_INFO@ -INSTALL_INFO = @INSTALL_INFO@ # Control flags for @contents placement in HTML output MAKEINFO_TOC_INLINE_FLAG = @MAKEINFO_TOC_INLINE_FLAG@ @@ -3786,9 +3785,13 @@ maintainer-clean: # Install the driver last so that the window when things are # broken is small. install: install-common $(INSTALL_HEADERS) \ -install-cpp install-man $(INSTALL_INFO) install-@POSUB@ \ +install-cpp install-man install-@POSUB@ \ install-driver install-lto-wrapper install-gcc-ar +ifneq ($(BUILD_INFO),) +install: install-info +endif + ifeq ($(enable_plugin),yes) install: install-plugin endif -- 2.34.1
Re: [PATCH] gcc/configure: Re-introduce INSTALL_INFO
On Fri, 2 Feb 2024 at 11:10, wrote: > > On 1 February 2024 18:15:34 CET, Christophe Lyon > wrote: > >BUILD_INFO is currently a byproduct of checking makeinfo > >presence/version. INSTALL_INFO used to be defined similarly, but was > >removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df > >(svn r38141). > > > >In order to save build time, our CI overrides BUILD_INFO="", which > >works when invoking 'make all' but not for 'make install' in case some > >info files need an update. > > Instead of resurrecting INSTALL_INFO maybe you could something along the > lines of > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=15038=edit Ha indeed something along these lines would work too. Thanks for the archaeology :-) > > not sure which approach would be considered cleaner.. Not sure either. What do maintainers prefer? > > HTH
[PATCH] gcc/configure: Re-introduce INSTALL_INFO
BUILD_INFO is currently a byproduct of checking makeinfo presence/version. INSTALL_INFO used to be defined similarly, but was removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df (svn r38141). In order to save build time, our CI overrides BUILD_INFO="", which works when invoking 'make all' but not for 'make install' in case some info files need an update. I noticed this when testing a patch posted on the gcc-patches list, leading to an error at 'make install' time after updating tm.texi (the build reported 'new text' in tm.texi and stopped). This is because 'install' depends on 'install-info', which depends on $(DESTDIR)$(infodir)/gccint.info (among others). This patch replaces the 'install-info' dependency in 'install' with $(INSTALL_INFO), thus enabling to skip this step. 2024-02-01 Christophe Lyon gcc/ * Makefile.in: Add INSTALL_INFO. * configure.ac: Add INSTALL_INFO. * configure: Regenerate. --- gcc/Makefile.in | 3 ++- gcc/configure| 3 +++ gcc/configure.ac | 3 +++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 95caa54a52b..4d38b162307 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -817,6 +817,7 @@ INSTALL_HEADERS=install-headers install-mkheaders # Control whether Info documentation is built and installed. BUILD_INFO = @BUILD_INFO@ +INSTALL_INFO = @INSTALL_INFO@ # Control flags for @contents placement in HTML output MAKEINFO_TOC_INLINE_FLAG = @MAKEINFO_TOC_INLINE_FLAG@ @@ -3785,7 +3786,7 @@ maintainer-clean: # Install the driver last so that the window when things are # broken is small. install: install-common $(INSTALL_HEADERS) \ -install-cpp install-man install-info install-@POSUB@ \ +install-cpp install-man $(INSTALL_INFO) install-@POSUB@ \ install-driver install-lto-wrapper install-gcc-ar ifeq ($(enable_plugin),yes) diff --git a/gcc/configure b/gcc/configure index 4acb254d830..00f8c7ed6fb 100755 --- a/gcc/configure +++ b/gcc/configure @@ -826,6 +826,7 @@ FLEX GENERATED_MANPAGES MAKEINFO_TOC_INLINE_FLAG BUILD_INFO +INSTALL_INFO MAKEINFO have_mktemp_command make_compare_target @@ -8836,8 +8837,10 @@ $as_echo "$as_me: WARNING: *** Makeinfo is missing or too old. *** Info documentation will not be built." >&2;} BUILD_INFO= + INSTALL_INFO= else BUILD_INFO=info + INSTALL_INFO=install-info fi diff --git a/gcc/configure.ac b/gcc/configure.ac index d2ed14496c1..1041c2391fb 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1246,10 +1246,13 @@ if test $gcc_cv_prog_makeinfo_modern = no; then *** Makeinfo is missing or too old. *** Info documentation will not be built.]) BUILD_INFO= + INSTALL_INFO= else BUILD_INFO=info + INSTALL_INFO=install-info fi AC_SUBST(BUILD_INFO) +AC_SUBST(INSTALL_INFO) # Determine whether makeinfo supports the CONTENTS_OUTPUT_LOCATION variable. # If it does, we want to pass it to makeinfo in order to restore the old -- 2.34.1
Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output
On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote:
>
> On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> >
> > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
>
> We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
>
Hmm, right, sorry I had this patch in my tree for quite some time, but
wrote the description just now, so I read a bit too quickly.
>
> > possibly leading to mismatches under racy conditions.
>
> What do we incorrectly match? Is the problem that a \r\n sequence
> might be incompletely printed, due to buffering, and so the regex only
> sees (and matches) the \r which then leaves an unwanted \n in the
> stream, which then interferes with the next match? I don't understand
> why that problem wouldn't just result in a failed match with your new
> regex though.
>
Exactly: READ1 forces read() to return 1 byte at a time, so we leave
an unwanted \r in front of a string that should otherwise match the
"got" case.
>
> >
> > I noticed this while running the GCC testsuite using the equivalent of
> > GDB's READ1 feature [1] which helps detecting bufferization issues.
> >
> > Adjusting the first regexp to match the right order implied fixing the
> > second one, to skip the empty lines.
>
> At the very least, this part of the description is misleading. The
> existing regex matches "the right order" already. The change is to
> match *exactly* \r\n instead of any mix of CR and LF characters.
> That's not about matching "the right order", it's being more precise
> in what we match.
>
> But I'm still confused about what the failure scenario is and how the
> change fixes it.
>
I followed what the GDB testsuite does (it matches \r\n at the end of
many regexps), but in fact it seems it's not needed:
it works if I update the "got" regexp like this (ie. accept any number
of leading \r or \n):
- -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
+ -re {^[\n\r]*(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
and leave the "skipping" regexp as it is currently.
Is the new attached version OK?
Thanks,
Christophe
> >
> > Tested on aarch64-linux-gnu.
> >
> > [1]
> > https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
> >
> > 2024-01-24 Christophe Lyon
> >
> > libstdc++-v3/
> > * testsuite/lib/gdb-test.exp (gdb-test): Fix regexps.
> > ---
> > libstdc++-v3/testsuite/lib/gdb-test.exp | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > index 31206f2fc32..0de8d9ee153 100644
> > --- a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > +++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > @@ -194,7 +194,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 0}
> > } {
> >
> > set test_counter 0
> > remote_expect target [timeout_value] {
> > - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > + -re {^(type|\$([0-9]+)) = ([^\n\r]*)\r\n} {
> > send_log "got: $expect_out(buffer)"
> >
> > incr test_counter
> > @@ -250,7 +250,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 0}
> > } {
> > return
> > }
> >
> > - -re {^[^$][^\n\r]*[\n\r]+} {
> > + -re {^[\r\n]*[^$][^\n\r]*\r\n} {
> > send_log "skipping: $expect_out(buffer)"
> > exp_continue
> > }
> > --
> > 2.34.1
> >
>
From e7cd0475141921282d5c9044b2450ae8e196efc4 Mon Sep 17 00:00:00 2001
From: Christophe Lyon
Date: Thu, 25 Jan 2024 15:43:56 +
Subject: [PATCH v2] [testsuite] Fix pretty printers regexp for GDB output
GDB emits end of lines as \r\n, we currently match any >0 number of
either \n or \r, possibly leading to mismatches under racy conditions.
I noticed this while running the GCC testsuite using the equivalent of
GDB's READ1 feature [1] which helps detecting bufferization issues.
We try to match
\n$1 = empty std::tuple\r
against {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} which fails because
of the leading \n (which was left in the buffer after the previous
"skipping" pattern matched the preceding \r).
This patch accepts any number of leading \n and/or \r in the "got" clause.
Also take this opportunity to quote \r and \r in the logs, to make
debugging such issues easier.
Tested on aarch64-linux-gnu.
[1] https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
2024-01-24 Christophe Lyon
libstdc++-v3/
* testsuite/lib/gdb-test.exp (gdb-test): Fi
[PATCH] [testsuite] Fix pretty printers regexps for GDB output
GDB emits end of lines as \r\n, we currently match the reverse \n\r,
possibly leading to mismatches under racy conditions.
I noticed this while running the GCC testsuite using the equivalent of
GDB's READ1 feature [1] which helps detecting bufferization issues.
Adjusting the first regexp to match the right order implied fixing the
second one, to skip the empty lines.
Tested on aarch64-linux-gnu.
[1] https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
2024-01-24 Christophe Lyon
libstdc++-v3/
* testsuite/lib/gdb-test.exp (gdb-test): Fix regexps.
---
libstdc++-v3/testsuite/lib/gdb-test.exp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp
b/libstdc++-v3/testsuite/lib/gdb-test.exp
index 31206f2fc32..0de8d9ee153 100644
--- a/libstdc++-v3/testsuite/lib/gdb-test.exp
+++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
@@ -194,7 +194,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 0} } {
set test_counter 0
remote_expect target [timeout_value] {
- -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
+ -re {^(type|\$([0-9]+)) = ([^\n\r]*)\r\n} {
send_log "got: $expect_out(buffer)"
incr test_counter
@@ -250,7 +250,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 0} } {
return
}
- -re {^[^$][^\n\r]*[\n\r]+} {
+ -re {^[\r\n]*[^$][^\n\r]*\r\n} {
send_log "skipping: $expect_out(buffer)"
exp_continue
}
--
2.34.1
Re: [PATCH] testsuite: Disable test for PR113292 on targets without TLS support
On Fri, 19 Jan 2024 at 08:41, Nathaniel Shead wrote:
>
> Tested on x86_64-pc-linux-gnu using a cross-compiler to
> arm-unknown-linux-gnueabihf with --enable-threads=0 that the link test
> is correctly skipped. OK for trunk?
>
> -- >8 --
>
> This disables the new test added by r14-8168 on machines that don't have
> TLS support, such as bare-metal ARM.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/modules/pr113292_c.C: Require TLS.
>
> Signed-off-by: Nathaniel Shead
> ---
> gcc/testsuite/g++.dg/modules/pr113292_c.C | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gcc/testsuite/g++.dg/modules/pr113292_c.C
> b/gcc/testsuite/g++.dg/modules/pr113292_c.C
> index aa3f32ae818..c117c7cfcd4 100644
> --- a/gcc/testsuite/g++.dg/modules/pr113292_c.C
> +++ b/gcc/testsuite/g++.dg/modules/pr113292_c.C
> @@ -1,6 +1,8 @@
> // PR c++/113292
> // { dg-module-do link }
> +// { dg-add-options tls }
> // { dg-additional-options "-fmodules-ts" }
> +// { dg-require-effective-target tls_runtime }
>
Hi,
Thanks, I think this is OK, although I think we prefer to put
dg-require before dg-add-options (after dg-module-do).
Christophe
> import "pr113292_a.H";
>
> --
> 2.43.0
>
[PATCH] Allow overriding EXPECT
While investigating possible race conditions in the GCC testsuites
caused by bufferization issues, I wanted to investigate workarounds
similar to GDB's READ1 [1], and I noticed it was not always possible
to override EXPECT when running 'make check'.
This patch adds the missing support in various Makefiles.
I was not able to test the patch for all the libraries updated here,
but I confirmed it works as intended/needed for libstdc++.
libatomic, libitm, libgomp already work as intended because their
Makefiles do not have:
MAKEOVERRIDES=
Tested on (native) aarch64-linux-gnu, confirmed the patch introduces
the behaviour I want in gcc, g++, gfortran and libstdc++.
I updated (but could not test) libgm2, libphobos, libquadmath and
libssp for consistency since their Makefiles have MAKEOVERRIDES=
libffi, libgo, libsanitizer seem to need a similar update, but they
are imported from their respective upstream repo, so should not be
patched here.
[1] https://github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
2023-12-21 Christophe Lyon
gcc/
* Makefile.in: Allow overriding EXEPCT.
libgm2/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
libphobos/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
libquadmath/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
libssp/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
libstdc++-v3/
* Makefile.am: Allow overriding EXEPCT.
* Makefile.in: Regenerate.
---
gcc/Makefile.in | 3 +++
libgm2/Makefile.am | 1 +
libgm2/Makefile.in | 1 +
libphobos/Makefile.am| 1 +
libphobos/Makefile.in| 1 +
libquadmath/Makefile.am | 1 +
libquadmath/Makefile.in | 1 +
libssp/Makefile.am | 1 +
libssp/Makefile.in | 1 +
libstdc++-v3/Makefile.am | 1 +
libstdc++-v3/Makefile.in | 1 +
11 files changed, 13 insertions(+)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index f284c1387e2..bc35a1bd237 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -4303,6 +4303,7 @@ $(lang_checks_parallel): site.exp
vardots=`echo "$$variant" | sed 's,/,.,g'`; \
$(MAKE) TESTSUITEDIR="testsuite.$$vardots" \
RUNTESTFLAGS="--target_board=$$variant $(RUNTESTFLAGS)" \
+ EXPECT=$(EXPECT) \
"$$target"
TESTSUITEDIR = testsuite
@@ -4368,6 +4369,7 @@ $(lang_checks_parallelized): check-% : site.exp
GCC_RUNTEST_PARALLELIZE_DIR=`${PWD_COMMAND}`/$(TESTSUITEDIR)/$(check_p_tool)-parallel
; \
export GCC_RUNTEST_PARALLELIZE_DIR ; \
$(MAKE) TESTSUITEDIR="$(TESTSUITEDIR)" RUNTESTFLAGS="$(RUNTESTFLAGS)"
\
+ EXPECT=$(EXPECT) \
check-parallel-$* \
$(patsubst %,check-parallel-$*_%, $(check_p_subdirs)); \
sums= ; logs= ; \
@@ -4386,6 +4388,7 @@ $(lang_checks_parallelized): check-% : site.exp
rm -rf $(TESTSUITEDIR)/$*-parallel || true; \
else \
$(MAKE) TESTSUITEDIR="$(TESTSUITEDIR)" RUNTESTFLAGS="$(RUNTESTFLAGS)"
\
+ EXPECT=$(EXPECT) \
check_$*_parallelize= check-parallel-$*; \
fi
diff --git a/libgm2/Makefile.am b/libgm2/Makefile.am
index d2eadfc51aa..72391d01291 100644
--- a/libgm2/Makefile.am
+++ b/libgm2/Makefile.am
@@ -69,6 +69,7 @@ AM_MAKEFLAGS = \
"CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD)" \
"CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)" \
"CFLAGS_LONGDOUBLE=$(CFLAGS_LONGDOUBLE)" \
+ "EXPECT=$(EXPECT)" \
"INSTALL=$(INSTALL)" \
"INSTALL_DATA=$(INSTALL_DATA)" \
"INSTALL_PROGRAM=$(INSTALL_PROGRAM)" \
diff --git a/libgm2/Makefile.in b/libgm2/Makefile.in
index 5a96f98edc9..4c30d2b034f 100644
--- a/libgm2/Makefile.in
+++ b/libgm2/Makefile.in
@@ -371,6 +371,7 @@ AM_MAKEFLAGS = \
"CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD)" \
"CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)" \
"CFLAGS_LONGDOUBLE=$(CFLAGS_LONGDOUBLE)" \
+ "EXPECT=$(EXPECT)" \
"INSTALL=$(INSTALL)" \
"INSTALL_DATA=$(INSTALL_DATA)" \
"INSTALL_PROGRAM=$(INSTALL_PROGRAM)" \
diff --git a/libphobos/Makefile.am b/libphobos/Makefile.am
index d46cfef533e..307c57c8b22 100644
--- a/libphobos/Makefile.am
+++ b/libphobos/Makefile.am
@@ -38,6 +38,7 @@ AM_MAKEFLAGS = \
"CXXFLAGS=$(CXXFLAGS)" \
"CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD)" \
"CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)" \
+ "EXPECT=$(EXPECT)" \
"GDC_FOR_TARGET=$(GDC_FOR_TARGET)" \
"GDC=$(GDC)" \
"GDCFLAGS=$(GDCFLAGS)" \
diff --git a/libphobos/Makef
Re: [PATCH] testsuite, arm: Fix up pr112337.c test
On Fri, 1 Dec 2023 at 13:44, Richard Earnshaw (lists) wrote: > > On 01/12/2023 11:28, Saurabh Jha wrote: > > Hey, > > > > I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in > > this commit 2365aae84de030bbb006edac18c9314812fc657b before. This had an > > error which I unfortunately missed. This patch fixes that test. > > > > Did regression testing on arm-none-eabi and found no regressions. Output of > > running gcc/contrib/compare_tests is this: > > > > """ > > Tests that now work, but didn't before (2 tests): > > > > arm-eabi-aem/-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp: > > gcc.target/arm/mve/pr112337.c (test for excess errors) > > arm-eabi-aem/-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard: > > gcc.target/arm/mve/pr112337.c (test for excess errors) > > """ > > > > Ok for trunk? I don't have commit access so could someone please commit on > > my behalf? > > > > Regards, > > Saurabh > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/arm/mve/pr112337.c: Fix the testcase > > > Hmm, could this be related to the changes Christophe made recently to change > the way MVE vector types were set up internally? If so, this might indicate > an issue that's going to affect real users with existing code. > My change was only about vector types, here the problem is with a pointer to a scalar. Anyway, I ran the test with my commit reverted and it still fails in the same way, so I think this patch is needed. Thanks, Christophe > Christophe? > > R.
[PATCH] testsuite/arm: Fix bfloat16_vector_typecheck_[12].c tests
After commit r14-5617-gb8592186611, int32x[24]_t types now use
elements of 'long int' type instead of 'int' on arm-eabi (it's still
'int' on arm-linux-gnueabihf). Both are 32-bit types anyway.
This patch adjust the two tests so that they optionnally accept 'long '
before 'int' in the expected error message.
2023-11-30 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/bfloat16_vector_typecheck_1.c: Update expected
error message.
* gcc.target/arm/bfloat16_vector_typecheck_2.c: Likewise.
---
gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c | 4 ++--
gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
index f3c350b4cfc..470c13125fb 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_1.c
@@ -119,9 +119,9 @@ bfloat16x4_t footest (bfloat16x4_t vector0)
(bfloat16x4_t) { is_a_short_vec }; /* { dg-error {incompatible types when
initializing type '__bf16' using type 'int16x4_t'} } */
(bfloat16x4_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type '__bf16' using type 'bfloat16x4_t'} } */
- (int32x4_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type 'int' using type 'bfloat16x4_t'} } */
+ (int32x4_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type '(?:long )?int' using type 'bfloat16x4_t'} } */
(float32x4_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type 'float' using type 'bfloat16x4_t'} } */
- (int32x2_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type 'int' using type 'bfloat16x4_t'} } */
+ (int32x2_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type '(?:long )?int' using type 'bfloat16x4_t'} } */
(float16x4_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type '__fp16' using type 'bfloat16x4_t'} } */
(int16x4_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type 'short int' using type 'bfloat16x4_t'} } */
diff --git a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
index de0ade52c10..4e0d37907ce 100644
--- a/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
+++ b/gcc/testsuite/gcc.target/arm/bfloat16_vector_typecheck_2.c
@@ -111,7 +111,7 @@ bfloat16x8_t footest (bfloat16x8_t vector0)
(bfloat16x8_t) { is_a_short_vec }; /* { dg-error {incompatible types when
initializing type '__bf16' using type 'int16x8_t'} } */
(bfloat16x8_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type '__bf16' using type 'bfloat16x8_t'} } */
- (int32x4_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type 'int' using type 'bfloat16x8_t'} } */
+ (int32x4_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type '(?:long )?int' using type 'bfloat16x8_t'} } */
(float32x4_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type 'float' using type 'bfloat16x8_t'} } */
(int64x2_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type 'long long int' using type 'bfloat16x8_t'} } */
(float16x8_t) { glob_bfloat_vec }; /* { dg-error {incompatible types when
initializing type '__fp16' using type 'bfloat16x8_t'} } */
--
2.34.1
Re: [patch] OpenMP: Add -Wopenmp and use it
On Mon, 27 Nov 2023 at 11:33, Tobias Burnus wrote: > > Hi, > > On 27.11.23 11:20, Christophe Lyon wrote: > > > I think the lack of final '.' in: > > Indeed - but you are lagging a bit behind: > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638128.html > > [committed] c-family/c.opt (-Wopenmp): Add missing tailing '.' > > Fri Nov 24 18:56:21 GMT 2023 > > Committed as r14-5835-g6eb1507107dee3 > Great thanks! Sorry for the noise, it's a bit hard and error-prone to track which regressions have already fixed and/or are being worked on. Our bisect started at r14-5830, just a bit too early :-) Thanks, Christophe > Tobias > > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 > München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas > Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht > München, HRB 106955
Re: [patch] OpenMP: Add -Wopenmp and use it
Hi! On Fri, 24 Nov 2023 at 15:08, Jakub Jelinek wrote: > > On Fri, Nov 24, 2023 at 02:51:28PM +0100, Tobias Burnus wrote: > > Following the general trend to add a "[-W...]" to the warning messages > > for both better grouping of the warnings and - more importantly - for > > providing > > a means to silence such a warning (or to -Werror= them explicitly), this > > patch > > replaces several '0' by OPT_Wopenmp. > > > > Comments or remarks before I commit it? > > LGTM, thanks for working on it. > > Jakub > I think the lack of final '.' in: gcc/c-family/c.opt + Warn about suspicious OpenMP code has caused the following regressions: Running gcc:gcc.misc-tests/help.exp ... FAIL: compiler driver --help=c option(s): "^ +-.*[^:.]$" absent from output: " -WopenmpWarn about suspicious OpenMP code" FAIL: compiler driver --help=c++ option(s): "^ +-.*[^:.]$" absent from output: " -WopenmpWarn about suspicious OpenMP code" FAIL: compiler driver --help=fortran option(s): "^ +-.*[^:.]$" absent from output: " -WopenmpWarn about suspicious OpenMP code" FAIL: compiler driver --help=warnings option(s): "^ +-.*[^:.]$" absent from output: " -WopenmpWarn about suspicious OpenMP code" I think you have received a notification from our CI about that? Can you check it's as simple as that? Thanks, Christophe
Re: [PATCH] testsuite, lib: Re-allow mulitple function start labels.
On Thu, 23 Nov 2023 at 17:35, Iain Sandoe wrote:
>
> Hi
>
> > On 23 Nov 2023, at 16:11, Christophe Lyon
> > wrote:
> >
> > Hi Iain,
> >
> > Thanks for dealing with this :-)
> >
> > On Thu, 23 Nov 2023 at 10:58, Iain Sandoe wrote:
> >>
> >> Tested on a cross to armv8l-unknown-linux-gnueabihf where the failing
> >> testcase is restored, and on aarch64-linux-gnu where no change is seen
> >> on the aarch64.exp suite. Also tested on arm64 Darwin for aarch64.exp
> >> and aarch64-darwin.exp.
> >>
> >> OK for trunk, or some alternative would be better?
> >> Iain
> >>
> >> --- 8< ---
> >>
> >> The change applied in r14-5760-g2a46e0e7e20 changed the behaviour of
> >> functions with assembly like:
> >>
> >> bar:
> >> __acle_se_bar:
> >>
> >> Where both bar and __acle_se_bar are globals refering to the same
> >> function body. The old behaviour overrides 'bar' with '__acle_se_bar'
> >> and the scan tests for that label.
> >>
> >> The change here re-allows the override.
> >>
> >> Case like this are not legal Mach-O (where two global symbols cannot
> >> have the same address in the assembler output). However, given the
> >> constraints on the Mach-O scanning, it does not seem that it is
> >> necessary to skip the change (any incorrect case should be easily
> >> evident in the assembler).
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >>* lib/scanasm.exp: Allow multiple function start symbols,
> >>taking the last as the function name.
> >>
> >> Signed-off-by: Iain Sandoe
> >> ---
> >> gcc/testsuite/lib/scanasm.exp | 10 +-
> >> 1 file changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
> >> index 85ee54ff9a8..7ec3cfce02b 100644
> >> --- a/gcc/testsuite/lib/scanasm.exp
> >> +++ b/gcc/testsuite/lib/scanasm.exp
> >> @@ -877,7 +877,15 @@ proc parse_function_bodies { config filename result }
> >> {
> >>set in_function 0
> >>}
> >>} elseif { $in_function } {
> >> - if { [regexp $up_config(end) $line] } {
> >> + # We allow multiple function start labels, taking the last one
> >> seen
> >> + # as the function name.
> >> + if { [regexp [lindex $up_config(start) 0] \
> >> +$line dummy maybe_function_name] } {
> >> + verbose "parse_function_bodies: overriding $function_name
> >> with $maybe_function_name"
> >> + set function_name $maybe_function_name
> >> + set in_function 1
> > this is not necessary, since we are already inside if ($in_function) ?
>
> It resets the state to “first line matched” for mutli-line function start
> cases. Currently, those cases are only for Darwin and as noted in the
> changelog actually such code is not legal Mach-O, so in practice, at present
> we could remove it - but it might be better to be consistent (I am OK either
> way).
>
Ha, right.
Thanks
>
>
> Of course, an alternate fix would be to match the first label always and
> change the testcase to scan for ‘bar’ - since that seems to be the only
> instance needing this facility - but I’ll leave that to you folks to
> consider.
>
> Iain
>
> >
> >> + set function_body ""
> >> + } elseif { [regexp $up_config(end) $line] } {
> >>verbose "parse_function_bodies:
> >> $function_name:\n$function_body"
> >>set up_result($function_name) $function_body
> >>set in_function 0
> >> --
> >> 2.39.2 (Apple Git-143)
> >>
> >
> > Thanks,
> >
> > Christophe
>
Re: [PATCH] testsuite, lib: Re-allow mulitple function start labels.
Hi Iain,
Thanks for dealing with this :-)
On Thu, 23 Nov 2023 at 10:58, Iain Sandoe wrote:
>
> Tested on a cross to armv8l-unknown-linux-gnueabihf where the failing
> testcase is restored, and on aarch64-linux-gnu where no change is seen
> on the aarch64.exp suite. Also tested on arm64 Darwin for aarch64.exp
> and aarch64-darwin.exp.
>
> OK for trunk, or some alternative would be better?
> Iain
>
> --- 8< ---
>
> The change applied in r14-5760-g2a46e0e7e20 changed the behaviour of
> functions with assembly like:
>
> bar:
> __acle_se_bar:
>
> Where both bar and __acle_se_bar are globals refering to the same
> function body. The old behaviour overrides 'bar' with '__acle_se_bar'
> and the scan tests for that label.
>
> The change here re-allows the override.
>
> Case like this are not legal Mach-O (where two global symbols cannot
> have the same address in the assembler output). However, given the
> constraints on the Mach-O scanning, it does not seem that it is
> necessary to skip the change (any incorrect case should be easily
> evident in the assembler).
>
> gcc/testsuite/ChangeLog:
>
> * lib/scanasm.exp: Allow multiple function start symbols,
> taking the last as the function name.
>
> Signed-off-by: Iain Sandoe
> ---
> gcc/testsuite/lib/scanasm.exp | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
> index 85ee54ff9a8..7ec3cfce02b 100644
> --- a/gcc/testsuite/lib/scanasm.exp
> +++ b/gcc/testsuite/lib/scanasm.exp
> @@ -877,7 +877,15 @@ proc parse_function_bodies { config filename result } {
> set in_function 0
> }
> } elseif { $in_function } {
> - if { [regexp $up_config(end) $line] } {
> + # We allow multiple function start labels, taking the last one
> seen
> + # as the function name.
> + if { [regexp [lindex $up_config(start) 0] \
> +$line dummy maybe_function_name] } {
> + verbose "parse_function_bodies: overriding $function_name
> with $maybe_function_name"
> + set function_name $maybe_function_name
> + set in_function 1
this is not necessary, since we are already inside if ($in_function) ?
> + set function_body ""
> + } elseif { [regexp $up_config(end) $line] } {
> verbose "parse_function_bodies:
> $function_name:\n$function_body"
> set up_result($function_name) $function_body
> set in_function 0
> --
> 2.39.2 (Apple Git-143)
>
Thanks,
Christophe
Re: [PATCH 3/6] arm: [MVE intrinsics] Add support for contiguous loads and stores
Hi!
On Thu, 23 Nov 2023 at 14:29, Jan-Benedict Glaw wrote:
>
> On Thu, 2023-11-16 15:26:14 +, Christophe Lyon
> wrote:
> > diff --git a/gcc/config/arm/arm-mve-builtins-functions.h
> > b/gcc/config/arm/arm-mve-builtins-functions.h
> > index eba1f071af0..6d234a2dd7c 100644
> > --- a/gcc/config/arm/arm-mve-builtins-functions.h
> > +++ b/gcc/config/arm/arm-mve-builtins-functions.h
> > @@ -966,6 +966,62 @@ public:
> [...]
>
> > +class full_width_access : public multi_vector_function
> > +{
> > +public:
> > + CONSTEXPR full_width_access (unsigned int vectors_per_tuple = 1)
> > +: multi_vector_function (vectors_per_tuple) {}
> > +
> > + tree
> > + memory_scalar_type (const function_instance ) const override
> > + {
> > +return fi.scalar_type (0);
> > + }
> > +
> > + machine_mode
> > + memory_vector_mode (const function_instance ) const override
> > + {
> > +machine_mode mode = fi.vector_mode (0);
> > +/* Vectors of floating-point are managed in memory as vectors of
> > + integers. */
> > +switch (mode)
> > + {
> > + case E_V4SFmode:
> > + mode = E_V4SImode;
> > + break;
> > + case E_V8HFmode:
> > + mode = E_V8HImode;
> > + break;
> > + }
>
> This introduces warnings about many enum values not being handled, so
> a default would be good I think. (I do automated builds with
> --enable-werror-always, see eg.
> http://toolchain.lug-owl.de/laminar/log/gcc-arm-eabi/48)
>
Ha right, thanks for catching this.
Fixed by commit b9dbdefac626ba20222ca534b58f7e493d713b9a
Christophe
> MfG, JBG
>
> --
[PATCH] arm: [MVE intrinsics] Add default clause to full_width_access::memory_vector_mode
My recent commit 0c2037d9d93a8f768cb11698ff794278246bb31f added a switch statement lacking a default clause, leading to warnings or errors when building with --enable-werror-always. Fix by adding an empty default. Committed as obvious. 2023-11-23 Christophe Lyon gcc/ * config/arm/arm-mve-builtins-functions.h (full_width_access::memory_vector_mode): Add default clause. --- gcc/config/arm/arm-mve-builtins-functions.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/config/arm/arm-mve-builtins-functions.h b/gcc/config/arm/arm-mve-builtins-functions.h index 6d234a2dd7c..1c93e6436b5 100644 --- a/gcc/config/arm/arm-mve-builtins-functions.h +++ b/gcc/config/arm/arm-mve-builtins-functions.h @@ -1013,6 +1013,8 @@ public: case E_V8HFmode: mode = E_V8HImode; break; + default: + break; } if (m_vectors_per_tuple != 1) -- 2.34.1
Re: [PATCH] testsuite, Darwin: Add support for Mach-O function body scans.
On Thu, 23 Nov 2023 at 10:09, Iain Sandoe wrote: > > Hi Christophe. > > > On 23 Nov 2023, at 09:02, Christophe Lyon > > wrote: > > > > Hi Iain, > > > > On Mon, 6 Nov 2023 at 11:58, Richard Sandiford > > wrote: > >> > >> Iain Sandoe writes: > >>> Hi Richard, > >>> > >>>> On 5 Nov 2023, at 12:11, Richard Sandiford > >>>> wrote: > >>>> > >>>> Iain Sandoe writes: > >>> > >>>>>> On 26 Oct 2023, at 21:00, Iain Sandoe wrote: > >>>>> > >>>>>>> On 26 Oct 2023, at 20:49, Richard Sandiford > >>>>>>> > >>>>> wrote: > >>>>>>> > >>>>>>> Iain Sandoe writes: > >>>>>>>> This was written before Thomas' modification to the ELF-handling to > >>>>>>>> allow > >>>>>>>> a config-based change for target details. I did consider updating > >>>>>>>> this > >>>>>>>> to try and use that scheme, but I think that it would sit a little > >>>>>>>> awkwardly, since there are some differences in the start-up scanning > >>>>>>>> for > >>>>>>>> Mach-O. I would say that in all probability we could improve things > >>>>>>>> but > >>>>>>>> I'd like to put this forward as a well-tested initial implementation. > >>>>>>> > >>>>>>> Sorry, I would prefer to extend the existing function instead. > >>>>>>> E.g. there's already some divergence between the Mach-O version > >>>>>>> and the default version, in that the Mach-O version doesn't print > >>>>>>> verbose messages. I also don't think that the current default code > >>>>>>> is so watertight that it'll never need to be updated in future. > >>>>>> > >>>>>> Fair enough, will explore what can be done (as I recall last I looked > >>>>>> the > >>>>>> primary difference was in the initial start-up scan). > >>>>> > >>>>> I’ve done this as attached. > >>>>> > >>>>> For the record, when doing it, it gave rise to the same misgivings that > >>>>> led > >>>>> to the separate implementation before. > >>>>> > >>>>> * as we add formats and uncover asm oddities, they all need to be > >>>>> handled > >>>>> in one set of code, IMO it could be come quite convoluted. > >>>>> > >>>>> * now making a change to the MACH-O code, means I have to check I did > >>>>> not > >>>>> inadvertently break ELF (and likewise, in theory, an ELF change should > >>>>> check > >>>>> MACH-O, but many folks do/can not do that). > >>>>> > >>>>> Maybe there’s some half-way-house where code can usefully be shared > >>>>> without > >>>>> those down-sides. > >>>>> > >>>>> Anyway, to make progress, is the revised version OK for trunk? (tested > >>>>> on > >>>>> aarch64-linux and aarch64-darwin). > >>>> > >>>> Sorry for the slow reply. I was hoping we'd be able to share a bit more > >>>> code than that, and avoid an isMACHO toggle. Does something like the > >>>> attached adaption of your patch work? Only spot-checked on > >>>> aarch64-linux-gnu so far. > >>>> > >>>> (The patch tries to avoid capturing the user label prefix, hopefully > >>>> avoiding the needsULP thing.) > >>> > >>> Yes, this works for me too for Arm64 Darwin (and probably is fine for > >>> other > >>> Darwin archs in case we implement body tests there). If we decide to emit > >>> some comment-based markers to delineat functions without unwind data, > >>> we can just amend the start and end. > >>> > >>> thanks, > >>> Iain > >>> (doing some wider testing, but for now the only mach-o cases are in the > >>> arm64 code, so the fact that those passed so far is pretty good > >>> indication). > >> > >> OK, great. It passed testing for me too, so please go ahead and commit > >> if it does for you. > >> > >>> - > >>> > >>> As an aside what’s the intention for cases like this? > >>> > >>> .data > >>> foo: > >>> . …. > >>> .size foo, .-foo > >> > >> ATM there's no way for the test to say that specific pseudo-ops are > >> interesting to it. Same for labels. It might be useful to add > >> support for that though. > >> > >> Thanks, > >> Richard > >> > > > > As you have probably already noticed with the notification from our > > CI, this patch causes > > FAIL: gcc.target/arm/pr95646.c check-function-bodies __acle_se_bar > > At quick glance it's not obvious to me why check_function_body > > does not print "body" and "against" debug traces, so there's not hint in > > gcc.log > > Yeah, I’ve reproduced this (it did not show on either Richard’s nor my > aarch64 testing) > ... and have a potential fix. > It makes sense, aarch64 and arm are different targets. > the problem is this: > > .global bar > … > . global __acle_se_bar > > foo: > __acle_se_bar: > … > > = > > The change in code prevernt the second label overriding the first (but the > scan checks for the second). > > Actually, that’s not legal Mach-O (two global labels cannot have the same > address). > > I have a fix that re-allows the override (thinking if I should assume Mach-O > will never do this or skip the change for mach-o) > Good news, thanks! Christophe > —— > > > Iain >
Re: [PATCH] testsuite, Darwin: Add support for Mach-O function body scans.
Hi Iain,
On Mon, 6 Nov 2023 at 11:58, Richard Sandiford
wrote:
>
> Iain Sandoe writes:
> > Hi Richard,
> >
> >> On 5 Nov 2023, at 12:11, Richard Sandiford
> >> wrote:
> >>
> >> Iain Sandoe writes:
> >
> On 26 Oct 2023, at 21:00, Iain Sandoe wrote:
> >>>
> > On 26 Oct 2023, at 20:49, Richard Sandiford
> >>> wrote:
> >
> > Iain Sandoe writes:
> >> This was written before Thomas' modification to the ELF-handling to
> >> allow
> >> a config-based change for target details. I did consider updating this
> >> to try and use that scheme, but I think that it would sit a little
> >> awkwardly, since there are some differences in the start-up scanning
> >> for
> >> Mach-O. I would say that in all probability we could improve things
> >> but
> >> I'd like to put this forward as a well-tested initial implementation.
> >
> > Sorry, I would prefer to extend the existing function instead.
> > E.g. there's already some divergence between the Mach-O version
> > and the default version, in that the Mach-O version doesn't print
> > verbose messages. I also don't think that the current default code
> > is so watertight that it'll never need to be updated in future.
>
> Fair enough, will explore what can be done (as I recall last I looked the
> primary difference was in the initial start-up scan).
> >>>
> >>> I’ve done this as attached.
> >>>
> >>> For the record, when doing it, it gave rise to the same misgivings that
> >>> led
> >>> to the separate implementation before.
> >>>
> >>> * as we add formats and uncover asm oddities, they all need to be handled
> >>> in one set of code, IMO it could be come quite convoluted.
> >>>
> >>> * now making a change to the MACH-O code, means I have to check I did not
> >>> inadvertently break ELF (and likewise, in theory, an ELF change should
> >>> check
> >>> MACH-O, but many folks do/can not do that).
> >>>
> >>> Maybe there’s some half-way-house where code can usefully be shared
> >>> without
> >>> those down-sides.
> >>>
> >>> Anyway, to make progress, is the revised version OK for trunk? (tested on
> >>> aarch64-linux and aarch64-darwin).
> >>
> >> Sorry for the slow reply. I was hoping we'd be able to share a bit more
> >> code than that, and avoid an isMACHO toggle. Does something like the
> >> attached adaption of your patch work? Only spot-checked on
> >> aarch64-linux-gnu so far.
> >>
> >> (The patch tries to avoid capturing the user label prefix, hopefully
> >> avoiding the needsULP thing.)
> >
> > Yes, this works for me too for Arm64 Darwin (and probably is fine for other
> > Darwin archs in case we implement body tests there). If we decide to emit
> > some comment-based markers to delineat functions without unwind data,
> > we can just amend the start and end.
> >
> > thanks,
> > Iain
> > (doing some wider testing, but for now the only mach-o cases are in the
> > arm64 code, so the fact that those passed so far is pretty good
> > indication).
>
> OK, great. It passed testing for me too, so please go ahead and commit
> if it does for you.
>
> > -
> >
> > As an aside what’s the intention for cases like this?
> >
> > .data
> > foo:
> > . ….
> > .size foo, .-foo
>
> ATM there's no way for the test to say that specific pseudo-ops are
> interesting to it. Same for labels. It might be useful to add
> support for that though.
>
> Thanks,
> Richard
>
As you have probably already noticed with the notification from our
CI, this patch causes
FAIL: gcc.target/arm/pr95646.c check-function-bodies __acle_se_bar
At quick glance it's not obvious to me why check_function_body
does not print "body" and "against" debug traces, so there's not hint in gcc.log
I guess running the testsuite with -verbose or -v would help?
Can you have a look?
Thanks,
Christophe
> >
> >
> >
> >>
> >> Thanks,
> >> Richard
> >>
> >>
> >> diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
> >> index 5df80325dff..2434550f0c3 100644
> >> --- a/gcc/testsuite/lib/scanasm.exp
> >> +++ b/gcc/testsuite/lib/scanasm.exp
> >> @@ -785,23 +785,34 @@ proc configure_check-function-bodies { config } {
> >>
> >> # Regexp for the start of a function definition (name in \1).
> >> if { [istarget nvptx*-*-*] } {
> >> -set up_config(start) {^// BEGIN(?: GLOBAL|) FUNCTION DEF:
> >> ([a-zA-Z_]\S+)$}
> >> +set up_config(start) {
> >> +{^// BEGIN(?: GLOBAL|) FUNCTION DEF: ([a-zA-Z_]\S+)$}
> >> +}
> >> +} elseif { [istarget *-*-darwin*] } {
> >> +set up_config(start) {
> >> +{^_([a-zA-Z_]\S+):$}
> >> +{^LFB[0-9]+:}
> >> +}
> >> } else {
> >> -set up_config(start) {^([a-zA-Z_]\S+):$}
> >> +set up_config(start) {{^([a-zA-Z_]\S+):$}}
> >> }
> >>
> >> # Regexp for the end of a function definition.
> >> if { [istarget nvptx*-*-*] } {
> >> set up_config(end) {^\}$}
> >> +} elseif {
Re: [PATCH v2] gcov: Fix integer types in gen_counter_update()
Hi,
On Tue, 21 Nov 2023 at 12:22, Sebastian Huber
wrote:
>
> On 21.11.23 11:46, Jakub Jelinek wrote:
> > On Tue, Nov 21, 2023 at 11:42:06AM +0100, Sebastian Huber wrote:
> >>
> >> On 21.11.23 11:34, Jakub Jelinek wrote:
> --- a/gcc/tree-profile.cc
> +++ b/gcc/tree-profile.cc
> @@ -281,10 +281,13 @@ gen_assign_counter_update (gimple_stmt_iterator
> *gsi, gcall *call, tree func,
> if (result)
> {
> tree result_type = TREE_TYPE (TREE_TYPE (func));
> - tree tmp = make_temp_ssa_name (result_type, NULL, name);
> - gimple_set_lhs (call, tmp);
> + tree tmp1 = make_temp_ssa_name (result_type, NULL, name);
> + gimple_set_lhs (call, tmp1);
> gsi_insert_after (gsi, call, GSI_NEW_STMT);
> - gassign *assign = gimple_build_assign (result, tmp);
> + tree tmp2 = make_ssa_name (TREE_TYPE (result));
> + gassign *assign = gimple_build_assign (tmp2, NOP_EXPR, tmp1);
> + gsi_insert_after (gsi, assign, GSI_NEW_STMT);
> + assign = gimple_build_assign (result, gimple_assign_lhs (assign));
> >>> When you use a temporary tmp2 for the lhs of the conversion, you can just
> >>> use it here,
> >>> assign = gimple_build_assign (result, tmp2);
> >>>
> >>> Ok for trunk with that change.
> >> Just a question, could I also use
> >>
> >> tree tmp2 = make_temp_ssa_name (TREE_TYPE (result), NULL, name);
> >>
> >> ?
> >>
> >> This make_temp_ssa_name() is used throughout the file and the new
> >> make_ssa_name() would be the first use in this file.
> > Yes. The only difference is that it won't be _234 = (type) something;
> > but PROF_time_profile_234 = (type) something; in the dumps, but sure,
> > consistency is useful.
>
> Thanks for your help. I checked in an updated version.
>
Our CI bisected a regression to this commit:
Running gcc:gcc.dg/tree-prof/tree-prof.exp ...
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 0" 1
FAIL: gcc.dg/tree-prof/time-profiler-3.c scan-ipa-dump-times profile
"Read tp_first_run: 2" 1
(on aarch64)
Can you check?
Thanks,
Christophe
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
Re: Fix 'gcc.dg/tree-ssa/return-value-range-1.c' for 'char' defaulting to 'unsigned' (was: Propagate value ranges of return values)
Hi!
On Tue, 21 Nov 2023 at 22:24, Thomas Schwinge wrote:
>
> Hi!
>
> On 2023-11-19T16:05:42+0100, Jan Hubicka wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/return-value-range-1.c
>
> Pushed to master branch commit a0240662b22312ffb3e3fefb85f258ab0e7010f4
> "Fix 'gcc.dg/tree-ssa/return-value-range-1.c' for 'char' defaulting to
> 'unsigned'", see attached. On powerpc64le-linux-gnu ('char' defaulting
> to 'unsigned') I still saw:
>
> /tmp/ccd1xwD7.o: In function `test':
> return-value-range-1.c:(.text+0x50): undefined reference to `link_error'
>
We do see the same error in our CI (Thomas, normally you have received
a notification because your patch turned ERROR in FAIL)
Thomas, you said in another email that adding -O2 avoids the linker
error with missing link_error(), but I don't see how that would be
possible?
(and hence I expect the error you quoted above to happen)
So should we use dg-compile instead of dg-link? Not sure what the
original intention was?
Thanks,
Christophe
>
> Grüße
> Thomas
>
>
> > @@ -0,0 +1,22 @@
> > +/* { dg-do ling } */
> > +/* { dg-options "-O1 -dump-tree-evrp-details" } */
> > +__attribute__ ((__noinline__))
> > +int a(char c)
> > +{
> > + return c;
> > +}
> > +void link_error ();
> > +
> > +void
> > +test(int d)
> > +{
> > + if (a(d) > 200)
> > + link_error ();
> > +}
> > +int
> > +main(int argc, char **argv)
> > +{
> > + test(argc);
> > + return 0;
> > +}
> > +/* { dg-final { scan-tree-dump-times "Recording return range" 2 "evrp"} }
> > */
>
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
> München, HRB 106955
[PATCH] arm: [MVE intrinsics] Fix typo
In commt 0c2037d9d93a8f768cb11698ff794278246bb31f (Add support for contiguous loads and stores), I added a spurious line which broke bootstrap because of an unused variable error. This patch removes it. Committed as obvious. 2023-11-22 Christophe Lyon gcc/ChangeLog: * config/arm/arm-mve-builtins.cc (function_resolver::infer_pointer_type): Remove spurious line. --- gcc/config/arm/arm-mve-builtins.cc | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/config/arm/arm-mve-builtins.cc b/gcc/config/arm/arm-mve-builtins.cc index a265cb05553..dec163dce4f 100644 --- a/gcc/config/arm/arm-mve-builtins.cc +++ b/gcc/config/arm/arm-mve-builtins.cc @@ -1168,7 +1168,6 @@ function_resolver::infer_pointer_type (unsigned int argno) build_qualified_type (target, 0)); return NUM_TYPE_SUFFIXES; } - unsigned int bits = type_suffixes[type].element_bits; return type; } -- 2.34.1
Re: [PATCH] testsuite: Fix up pr111309-2.c on arm [PR111309]
On Tue, 21 Nov 2023 at 09:48, Jakub Jelinek wrote:
>
> Hi!
>
> ARM defaults to -fshort-enums and the following testcase FAILs there in 2
> lines. The difference is that in C++, E0 has enum E type, which normally
> has unsigned int underlying type, so it isn't int nor something that
> promotes to int, which is why we diagnose it (in C it is promoted to int).
> But with -fshort-enums, the underlying type is unsigned char in that case,
> which promotes to int just fine.
>
> The following patch adjusts the expectations, such that we don't expect
> it on arm or when people manually test with -fshort-enums.
>
> Tested on x86_64-linux and i686-linux, ok for trunk?
>
> 2023-11-21 Jakub Jelinek
>
> PR c/111309
> * c-c++-common/pr111309-2.c (foo): Don't expect errors for C++ with
> -fshort-enums if second argument is E0.
>
Thanks for the fix!
I keep forgetting about the -fshort-enum difference between arm-linux
and arm-eabi targets
Christophe
> --- gcc/testsuite/c-c++-common/pr111309-2.c.jj 2023-11-14 10:52:16.191276028
> +0100
> +++ gcc/testsuite/c-c++-common/pr111309-2.c 2023-11-20 17:52:30.606386073
> +0100
> @@ -32,7 +32,7 @@ foo (void)
>__builtin_clzg (0U, 2LL);/* { dg-error "does not have 'int' type" } */
>__builtin_clzg (0U, 2U); /* { dg-error "does not have 'int' type" } */
>__builtin_clzg (0U, true);
> - __builtin_clzg (0U, E0); /* { dg-error "does not have 'int' type" "" {
> target c++ } } */
> + __builtin_clzg (0U, E0); /* { dg-error "does not have 'int' type" "" {
> target { c++ && { ! short_enums } } } } */
>__builtin_ctzg (); /* { dg-error "too few arguments" } */
>__builtin_ctzg (0U, 1, 2); /* { dg-error "too many arguments" } */
>__builtin_ctzg (0); /* { dg-error "has signed type" } */
> @@ -51,7 +51,7 @@ foo (void)
>__builtin_ctzg (0U, 2LL);/* { dg-error "does not have 'int' type" } */
>__builtin_ctzg (0U, 2U); /* { dg-error "does not have 'int' type" } */
>__builtin_ctzg (0U, true);
> - __builtin_ctzg (0U, E0); /* { dg-error "does not have 'int' type" "" {
> target c++ } } */
> + __builtin_ctzg (0U, E0); /* { dg-error "does not have 'int' type" "" {
> target { c++ && { ! short_enums } } } } */
>__builtin_clrsbg (); /* { dg-error "too few arguments" } */
>__builtin_clrsbg (0, 1); /* { dg-error "too many arguments" } */
>__builtin_clrsbg (0U); /* { dg-error "has unsigned type" } */
>
> Jakub
>
Re: Propagate value ranges of return values
Hi!
On Sun, 19 Nov 2023 at 16:05, Jan Hubicka wrote:
>
> Hi,
> this is updated version which also adds testuiste compensation
> I lost earlier while maintaining the patch in my testing tree.
> There are quite few testcases that use constant return values to hide
> something from optimizer.
>
> Bootstrapped/regtested x86_64-linux.
> gcc/ChangeLog:
>
> * cgraph.cc (add_detected_attribute_1): New function.
> (cgraph_node::add_detected_attribute): Likewise.
> * cgraph.h (cgraph_node::add_detected_attribute): Declare.
> * common.opt: Add -Wsuggest-attribute=returns_nonnull.
> * doc/invoke.texi: Document new flag.
> * gimple-range-fold.cc (fold_using_range::range_of_call):
> Use known reutrn value ranges.
> * ipa-prop.cc (struct ipa_return_value_summary): New type.
> (class ipa_return_value_sum_t): New type.
> (ipa_return_value_sum): New summary.
> (ipa_record_return_value_range): New function.
> (ipa_return_value_range): New function.
> * ipa-prop.h (ipa_return_value_range): Declare.
> (ipa_record_return_value_range): Declare.
> * ipa-pure-const.cc (warn_function_returns_nonnull): New funcion.
> * ipa-utils.h (warn_function_returns_nonnull): Declare.
> * symbol-summary.h: Fix comment.
> * tree-vrp.cc (execute_ranger_vrp): Record return values.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/ipa/devirt-2.C: Add noipa attribute to prevent ipa-vrp.
> * g++.dg/ipa/devirt-7.C: Disable ipa-vrp.
> * g++.dg/ipa/ipa-icf-2.C: Disable ipa-vrp.
> * g++.dg/ipa/ipa-icf-3.C: Disable ipa-vrp.
> * g++.dg/ipa/ivinline-1.C: Disable ipa-vrp.
> * g++.dg/ipa/ivinline-3.C: Disable ipa-vrp.
> * g++.dg/ipa/ivinline-5.C: Disable ipa-vrp.
> * g++.dg/ipa/ivinline-8.C: Disable ipa-vrp.
> * g++.dg/ipa/nothrow-1.C: Disable ipa-vrp.
> * g++.dg/ipa/pure-const-1.C: Disable ipa-vrp.
> * g++.dg/ipa/pure-const-2.C: Disable ipa-vrp.
> * g++.dg/lto/inline-crossmodule-1_0.C: Disable ipa-vrp.
> * gcc.c-torture/compile/pr106433.c: Add noipa attribute to prevent
> ipa-vrp.
> * gcc.c-torture/execute/frame-address.c: Likewise.
> * gcc.dg/ipa/fopt-info-inline-1.c: Disable ipa-vrp.
> * gcc.dg/ipa/ipa-icf-25.c: Disable ipa-vrp.
> * gcc.dg/ipa/ipa-icf-38.c: Disable ipa-vrp.
> * gcc.dg/ipa/pure-const-1.c: Disable ipa-vrp.
> * gcc.dg/ipa/remref-0.c: Add noipa attribute to prevent ipa-vrp.
> * gcc.dg/tree-prof/time-profiler-1.c: Disable ipa-vrp.
> * gcc.dg/tree-prof/time-profiler-2.c: Disable ipa-vrp.
> * gcc.dg/tree-ssa/pr110269.c: Disable ipa-vrp.
> * gcc.dg/tree-ssa/pr20701.c: Disable ipa-vrp.
> * gcc.dg/tree-ssa/vrp05.c: Disable ipa-vrp.
> * gcc.dg/tree-ssa/return-value-range-1.c: New test.
>
After this patch in addition to the problem already reported about
vlda1.c and return-value-range-1.c, we have noticed these regressions
on aarch64:
Running gcc:gcc.target/aarch64/aarch64.exp ...
FAIL: gcc.target/aarch64/movk.c scan-assembler movk\tx[0-9]+, 0x4667, lsl 16
FAIL: gcc.target/aarch64/movk.c scan-assembler movk\tx[0-9]+, 0x7a3d, lsl 32
Running gcc:gcc.target/aarch64/simd/simd.exp ...
FAIL: gcc.target/aarch64/simd/vmulxd_f64_2.c scan-assembler-times
fmul[ \t]+[dD][0-9]+, ?[dD][0-9]+, ?[dD][0-9]+\n 1
FAIL: gcc.target/aarch64/simd/vmulxd_f64_2.c scan-assembler-times
fmulx[ \t]+[dD][0-9]+, ?[dD][0-9]+, ?[dD][0-9]+\n 4
FAIL: gcc.target/aarch64/simd/vmulxs_f32_2.c scan-assembler-times
fmul[ \t]+[sS][0-9]+, ?[sS][0-9]+, ?[sS][0-9]+\n 1
FAIL: gcc.target/aarch64/simd/vmulxs_f32_2.c scan-assembler-times
fmulx[ \t]+[sS][0-9]+, ?[sS][0-9]+, ?[sS][0-9]+\n 4
We have already sent you a notification for the regression on arm, but
it includes on vla-1.c and return-value-range-1.c.
The notification email contains a pointer to the page where we record
all the configurations that regress because of this patch:
https://linaro.atlassian.net/browse/GNU-1025
Can you have a look?
Thanks,
Christophe
> diff --git a/gcc/cgraph.cc b/gcc/cgraph.cc
> index e41e5ad3ae7..71dacf23ce1 100644
> --- a/gcc/cgraph.cc
> +++ b/gcc/cgraph.cc
> @@ -2629,6 +2629,54 @@ cgraph_node::set_malloc_flag (bool malloc_p)
>return changed;
> }
>
> +/* Worker to set malloc flag. */
> +static void
> +add_detected_attribute_1 (cgraph_node *node, const char *attr, bool *changed)
> +{
> + if (!lookup_attribute (attr, DECL_ATTRIBUTES (node->decl)))
> +{
> + DECL_ATTRIBUTES (node->decl) = tree_cons (get_identifier (attr),
> +NULL_TREE, DECL_ATTRIBUTES
> (node->decl));
> + *changed = true;
> +}
> +
> + ipa_ref *ref;
> + FOR_EACH_ALIAS (node, ref)
> +{
> + cgraph_node *alias = dyn_cast (ref->referring);
> + if (alias->get_availability () > AVAIL_INTERPOSABLE)
> + add_detected_attribute_1
Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march
On Mon, 20 Nov 2023 at 15:39, Richard Earnshaw wrote: > > > > On 20/11/2023 14:24, Christophe Lyon wrote: > > On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw > > wrote: > >> > >> > >> > >> On 20/11/2023 13:36, Christophe Lyon wrote: > >>> On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw > >>> wrote: > >>>> > >>>> > >>>> > >>>> On 20/11/2023 10:23, Christophe Lyon wrote: > >>>>> Hi Richard, > >>>>> > >>>>> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw wrote: > >>>>>> > >>>>>> > >>>>>> A number of tests in the gcc testsuite, especially for arm-specific > >>>>>> targets, add various flags to control the architecture. These run > >>>>>> into problems when the compiler is configured with -mfpu=auto if the > >>>>>> new architecture lacks an architectural feature that implies we have > >>>>>> floating-point instructions. > >>>>>> > >>>>>> The testsuite makes this worse as it falls foul of this requirement in > >>>>>> the base architecture strings provided by target-supports.exp. > >>>>>> > >>>>>> To fix this we add "+fp", or something equivalent to this, to all the > >>>>>> base architecture specifications. The feature will be ignored if the > >>>>>> float ABI is set to soft. > >>>>>> > >>>>>> gcc/testsuite: > >>>>>> > >>>>>> * lib/target-supports.exp > >>>>>> (check_effective_target_arm_arch_FUNC_ok): > >>>>>> Add base FPU specifications to all architectures that can > >>>>>> support > >>>>>> one. > >>>>>> --- > >>>>>>gcc/testsuite/lib/target-supports.exp | 50 > >>>>>> +-- > >>>>>>1 file changed, 25 insertions(+), 25 deletions(-) > >>>>>> > >>>>> > >>>>> Our CI has detected some regressions with this patch, in particular > >>>>> when testing for cortex-m55: > >>>>> > >>>>> with > >>>>> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto > >>>>> and GCC configured with --disable-multilib --with-mode=thumb > >>>>> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard > >>>>> > >>>>> you can see our logs here: > >>>>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ > >>>>> > >>>>> <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Christophe > >>>> > >>>> What exactly am I supposed to be looking at here? I see no description > >>>> of what those logs represent. If they are supposed to be before and > >>>> after, then why does the after only run a tiny fraction of the testsuite > >>>> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ... > >>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ... > >>>> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...) > >>>> > >>>> The logs give no clue as to why the reminder of the testsuite wasn't run. > >>>> > >>>> Please don't make me guess. > >>>> > >>> > >>> Here is a summary with the list of regressions: > >>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/ > >> > >> OK, that's much more useful. But how was I supposed to know that link > >> existed? > >> > > The full notification email contains a lot of information, with > > several pointers to our Jenkins artifacts. > > The notification email is not yet automatically sent to contributors > > because we are still polishing, and I thought I'd save you some time > > by just sending the useful links. > > > > Looks like it's time to send thos
Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march
On Mon, 20 Nov 2023 at 14:58, Richard Earnshaw wrote: > > > > On 20/11/2023 13:36, Christophe Lyon wrote: > > On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw > > wrote: > >> > >> > >> > >> On 20/11/2023 10:23, Christophe Lyon wrote: > >>> Hi Richard, > >>> > >>> On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw wrote: > >>>> > >>>> > >>>> A number of tests in the gcc testsuite, especially for arm-specific > >>>> targets, add various flags to control the architecture. These run > >>>> into problems when the compiler is configured with -mfpu=auto if the > >>>> new architecture lacks an architectural feature that implies we have > >>>> floating-point instructions. > >>>> > >>>> The testsuite makes this worse as it falls foul of this requirement in > >>>> the base architecture strings provided by target-supports.exp. > >>>> > >>>> To fix this we add "+fp", or something equivalent to this, to all the > >>>> base architecture specifications. The feature will be ignored if the > >>>> float ABI is set to soft. > >>>> > >>>> gcc/testsuite: > >>>> > >>>> * lib/target-supports.exp > >>>> (check_effective_target_arm_arch_FUNC_ok): > >>>> Add base FPU specifications to all architectures that can > >>>> support > >>>> one. > >>>> --- > >>>> gcc/testsuite/lib/target-supports.exp | 50 +-- > >>>> 1 file changed, 25 insertions(+), 25 deletions(-) > >>>> > >>> > >>> Our CI has detected some regressions with this patch, in particular > >>> when testing for cortex-m55: > >>> > >>> with > >>> -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto > >>> and GCC configured with --disable-multilib --with-mode=thumb > >>> --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard > >>> > >>> you can see our logs here: > >>> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ > >>> > >>> <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/> > >>> > >>> Thanks, > >>> > >>> Christophe > >> > >> What exactly am I supposed to be looking at here? I see no description > >> of what those logs represent. If they are supposed to be before and > >> after, then why does the after only run a tiny fraction of the testsuite > >> (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ... > >> Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ... > >> Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...) > >> > >> The logs give no clue as to why the reminder of the testsuite wasn't run. > >> > >> Please don't make me guess. > >> > > > > Here is a summary with the list of regressions: > > https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/ > > OK, that's much more useful. But how was I supposed to know that link > existed? > The full notification email contains a lot of information, with several pointers to our Jenkins artifacts. The notification email is not yet automatically sent to contributors because we are still polishing, and I thought I'd save you some time by just sending the useful links. Looks like it's time to send those automatically too. > > > > I thought you'd be able to find your way in the logs above, the .0 > > files contain the logs of the initial full testsuite run, and .1 ones > > contain the logs of the second run of the testsuite, restricted to the > > .exp files where we detected regressions. So looking at gcc.log.1.xz > > will give you details of the regressions shown in the link above. > > There's nothing in the page you sent me to that gives any clue as to how > to read the logs there. So my assumption was that the .0 was a before > run and .1 an after. Please, if you're going to direct people to the > log files, provide some way for them to understand what the log files show. > > Now, to the specific issues: > > Running gcc:gcc.target/arm/arm.exp ... > FAIL: gcc.target/arm
Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march
On Mon, 20 Nov 2023 at 13:44, Richard Earnshaw wrote: > > > > On 20/11/2023 10:23, Christophe Lyon wrote: > > Hi Richard, > > > > On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw wrote: > >> > >> > >> A number of tests in the gcc testsuite, especially for arm-specific > >> targets, add various flags to control the architecture. These run > >> into problems when the compiler is configured with -mfpu=auto if the > >> new architecture lacks an architectural feature that implies we have > >> floating-point instructions. > >> > >> The testsuite makes this worse as it falls foul of this requirement in > >> the base architecture strings provided by target-supports.exp. > >> > >> To fix this we add "+fp", or something equivalent to this, to all the > >> base architecture specifications. The feature will be ignored if the > >> float ABI is set to soft. > >> > >> gcc/testsuite: > >> > >> * lib/target-supports.exp > >> (check_effective_target_arm_arch_FUNC_ok): > >> Add base FPU specifications to all architectures that can support > >> one. > >> --- > >> gcc/testsuite/lib/target-supports.exp | 50 +-- > >> 1 file changed, 25 insertions(+), 25 deletions(-) > >> > > > > Our CI has detected some regressions with this patch, in particular > > when testing for cortex-m55: > > > > with > > -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto > > and GCC configured with --disable-multilib --with-mode=thumb > > --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard > > > > you can see our logs here: > > https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ > > > > <https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/> > > > > Thanks, > > > > Christophe > > What exactly am I supposed to be looking at here? I see no description > of what those logs represent. If they are supposed to be before and > after, then why does the after only run a tiny fraction of the testsuite > (Running gcc.git~master/gcc/testsuite/gcc.target/arm/arm.exp ... > Running gcc.git~master/gcc/testsuite/gcc.target/arm/cmse/cmse.exp ... > Running gcc.git~master/gcc/testsuite/gcc.target/arm/lto/lto.exp ...) > > The logs give no clue as to why the reminder of the testsuite wasn't run. > > Please don't make me guess. > Here is a summary with the list of regressions: https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/notify/regressions.sum/*view*/ I thought you'd be able to find your way in the logs above, the .0 files contain the logs of the initial full testsuite run, and .1 ones contain the logs of the second run of the testsuite, restricted to the .exp files where we detected regressions. So looking at gcc.log.1.xz will give you details of the regressions shown in the link above. Christophe > R.
Re: [committed 02/22] arm: testsuite: correctly detect hard_float
Hi Richard, On Mon, 13 Nov 2023 at 15:27, Richard Earnshaw wrote: > > > Add an arm-specific test to check_effective_target_hard_float for > Arm to handle cases where we only have single-precision FP in hardware. > > gcc/testsuite: > > * lib/target-supports.exp (check_effective_target_hard_float): Add > arm-specific test. > --- > gcc/testsuite/lib/target-supports.exp | 11 +++ > 1 file changed, 11 insertions(+) > Our CI has detected a problem when testing this patch for cortex-m33: with -mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto and GCC configured with --disable-multilib --with-mode=thumb --with-cpu=cortex-m33 --with-float=hard FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c -O0 execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c -O1 execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c -O2 execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c -O3 -g execution test FAIL: gcc:gcc.dg/torture/dg-torture.exp=gcc.dg/torture/fp-double-convert-float-1.c -Os execution test We use qemu for testing. Do these tests pass in your configuration? Thanks, Christophe
Re: [committed 03/22] arm: testsuite: avoid hard-float ABI incompatibility with -march
Hi Richard, On Mon, 13 Nov 2023 at 15:28, Richard Earnshaw wrote: > > > A number of tests in the gcc testsuite, especially for arm-specific > targets, add various flags to control the architecture. These run > into problems when the compiler is configured with -mfpu=auto if the > new architecture lacks an architectural feature that implies we have > floating-point instructions. > > The testsuite makes this worse as it falls foul of this requirement in > the base architecture strings provided by target-supports.exp. > > To fix this we add "+fp", or something equivalent to this, to all the > base architecture specifications. The feature will be ignored if the > float ABI is set to soft. > > gcc/testsuite: > > * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok): > Add base FPU specifications to all architectures that can support > one. > --- > gcc/testsuite/lib/target-supports.exp | 50 +-- > 1 file changed, 25 insertions(+), 25 deletions(-) > Our CI has detected some regressions with this patch, in particular when testing for cortex-m55: with -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto and GCC configured with --disable-multilib --with-mode=thumb --with-arch=armv8.1-m.main+mve.fp+fp.dp --with-float=hard you can see our logs here: https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/209/artifact/artifacts/00-sumfiles/ Thanks, Christophe
Re: [PATCH] Add a REG_P check for inc and dec for Arm MVE
Hi Saurabh,
On Tue, 14 Nov 2023 at 15:51, Kyrylo Tkachov wrote:
>
> Hi Saurabh,
>
> > -Original Message-
> > From: Saurabh Jha
> > Sent: Thursday, November 9, 2023 10:12 AM
> > To: gcc-patches@gcc.gnu.org; Richard Earnshaw
> > ; Richard Sandiford
> >
> > Subject: [PATCH] Add a REG_P check for inc and dec for Arm MVE
> >
> > Hey,
> >
> > This patch tightens mve_vector_mem_operand to reject non-register
> > operands inside {PRE,POST}_{INC,DEC} addresses by introducing a REG_P
> > check.
> >
> > This patch fixes this
> > ICE:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337
> >
> > Okay for trunk? I don't have trunk access so could someone please commit
> > on my behalf?
>
> Ok.
>
> >
> > Regards,
> > Saurabh
> >
> > gcc/ChangeLog:
> >
> > PR target/112337
> > * config/arm/arm.cc (mve_vector_mem_operand): Add a REG_P
> > check for INC
> > and DEC operations
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR target/112337
> > * gcc.target/arm/mve/pr112337.c: Test for REG_P check for INC and
> > DEC
> > operations
>
This new test fails in our CI (various flavours of target arm-eabi),
with the following:
/gcc.target/arm/mve/pr112337.c:11:18: warning: passing argument 1 of
'__arm_vldrwq_s32' from incompatible pointer type
[-Wincompatible-pointer-types]
In file included from
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.target/arm/mve/pr112337.c:5:
/arm-eabi/14.0.0/include/arm_mve.h:1752:35: note: expected 'const
int32_t *' {aka 'const long int *'} but argument is of type 'int *'
I think you should make p a int32_t pointer rather than int, but I am
wondering why you didn't see this problem in your testing?
Can you check?
Thanks,
Christophe
> ChangeLog entries should end with a full stop (the git commit hooks enforce
> it).
> I've adjusted the ChangeLog and pushed this patch for you.
> Thank you for the patch!
> Kyrill
>
Re: [PATCH 5/6] arm: [MVE intrinsics] fix vst1 tests
On Thu, 16 Nov 2023 at 16:30, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Thursday, November 16, 2023 3:26 PM
> > To: gcc-patches@gcc.gnu.org; Richard Sandiford
> > ; Richard Earnshaw
> > ; Kyrylo Tkachov
> > Cc: Christophe Lyon
> > Subject: [PATCH 5/6] arm: [MVE intrinsics] fix vst1 tests
> >
> > vst1q intrinsics return void, so we should not do 'return vst1q_f16 (base,
> > value);'
> >
> > This was OK so far, but will trigger an error/warning with the new
> > implementation of these intrinsics.
> >
>
> Whoops!
> Ok (could have gone in as obvious IMO).
Indeed, I'll try to remember that when I write the same patch for the
other vst* intrinsics tests ;-)
Thanks,
Christophe
> Thanks,
> Kyrill
>
> > This patch just removes the 'return' keyword.
> >
> > 2023-11-16 Christophe Lyon
> >
> > gcc/testsuite/
> > * gcc.target/arm/mve/intrinsics/vst1q_f16.c: Remove 'return'.
> > * gcc.target/arm/mve/intrinsics/vst1q_f32.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/vst1q_s16.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/vst1q_s32.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/vst1q_s8.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/vst1q_u16.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/vst1q_u32.c: Likewise.
> > * gcc.target/arm/mve/intrinsics/vst1q_u8.c: Likewise.
> > ---
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c | 4 ++--
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c | 4 ++--
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c | 4 ++--
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s32.c | 4 ++--
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c | 4 ++--
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c | 4 ++--
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u32.c | 4 ++--
> > gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u8.c | 4 ++--
> > 8 files changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
> > b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
> > index 1fa02f00f53..e4b40604d54 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
> > @@ -18,7 +18,7 @@ extern "C" {
> > void
> > foo (float16_t *base, float16x8_t value)
> > {
> > - return vst1q_f16 (base, value);
> > + vst1q_f16 (base, value);
> > }
> >
> >
> > @@ -31,7 +31,7 @@ foo (float16_t *base, float16x8_t value)
> > void
> > foo1 (float16_t *base, float16x8_t value)
> > {
> > - return vst1q (base, value);
> > + vst1q (base, value);
> > }
> >
> > #ifdef __cplusplus
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c
> > b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c
> > index 67cc3ae3b47..8f42323c603 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c
> > @@ -18,7 +18,7 @@ extern "C" {
> > void
> > foo (float32_t *base, float32x4_t value)
> > {
> > - return vst1q_f32 (base, value);
> > + vst1q_f32 (base, value);
> > }
> >
> >
> > @@ -31,7 +31,7 @@ foo (float32_t *base, float32x4_t value)
> > void
> > foo1 (float32_t *base, float32x4_t value)
> > {
> > - return vst1q (base, value);
> > + vst1q (base, value);
> > }
> >
> > #ifdef __cplusplus
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
> > b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
> > index 052959b2083..891ac4155d9 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
> > @@ -18,7 +18,7 @@ extern "C" {
> > void
> > foo (int16_t *base, int16x8_t value)
> > {
> > - return vst1q_s16 (base, value);
> > + vst1q_s16 (base, value);
> > }
> >
> >
> > @@ -31,7 +31,7 @@ foo (int16_t *base, int16x8_t value)
> > void
> > foo1 (int16_t *base, int16x8_t value)
> > {
> > - return vst1q (base, value);
> > + vst1q (base, value);
> > }
> >
> > #ifdef __cplusplus
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s32.c
> > b/gcc/testsuite/gcc.ta
[PATCH 6/6] arm: [MVE intrinsics] rework vldq1 vst1q
Implement vld1q, vst1q using the new MVE builtins framework.
2023-11-16 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vld1_impl, vld1q)
(vst1_impl, vst1q): New.
* config/arm/arm-mve-builtins-base.def (vld1q, vst1q): New.
* config/arm/arm-mve-builtins-base.h (vld1q, vst1q): New.
* config/arm/arm_mve.h
(vld1q): Delete.
(vst1q): Delete.
(vld1q_s8): Delete.
(vld1q_s32): Delete.
(vld1q_s16): Delete.
(vld1q_u8): Delete.
(vld1q_u32): Delete.
(vld1q_u16): Delete.
(vld1q_f32): Delete.
(vld1q_f16): Delete.
(vst1q_f32): Delete.
(vst1q_f16): Delete.
(vst1q_s8): Delete.
(vst1q_s32): Delete.
(vst1q_s16): Delete.
(vst1q_u8): Delete.
(vst1q_u32): Delete.
(vst1q_u16): Delete.
(__arm_vld1q_s8): Delete.
(__arm_vld1q_s32): Delete.
(__arm_vld1q_s16): Delete.
(__arm_vld1q_u8): Delete.
(__arm_vld1q_u32): Delete.
(__arm_vld1q_u16): Delete.
(__arm_vst1q_s8): Delete.
(__arm_vst1q_s32): Delete.
(__arm_vst1q_s16): Delete.
(__arm_vst1q_u8): Delete.
(__arm_vst1q_u32): Delete.
(__arm_vst1q_u16): Delete.
(__arm_vld1q_f32): Delete.
(__arm_vld1q_f16): Delete.
(__arm_vst1q_f32): Delete.
(__arm_vst1q_f16): Delete.
(__arm_vld1q): Delete.
(__arm_vst1q): Delete.
* config/arm/mve.md (mve_vld1q_f): Rename into ...
(@mve_vld1q_f): ... this.
(mve_vld1q_): Rename into ...
(@mve_vld1q_) ... this.
(mve_vst1q_f): Rename into ...
(@mve_vst1q_f): ... this.
(mve_vst1q_): Rename into ...
(@mve_vst1q_) ... this.
---
gcc/config/arm/arm-mve-builtins-base.cc | 58 +
gcc/config/arm/arm-mve-builtins-base.def | 4 +
gcc/config/arm/arm-mve-builtins-base.h | 4 +-
gcc/config/arm/arm_mve.h | 282 ---
gcc/config/arm/mve.md| 8 +-
5 files changed, 69 insertions(+), 287 deletions(-)
diff --git a/gcc/config/arm/arm-mve-builtins-base.cc
b/gcc/config/arm/arm-mve-builtins-base.cc
index 5478cac8aeb..cfe1b954a29 100644
--- a/gcc/config/arm/arm-mve-builtins-base.cc
+++ b/gcc/config/arm/arm-mve-builtins-base.cc
@@ -83,6 +83,62 @@ class vuninitializedq_impl : public quiet
}
};
+class vld1_impl : public full_width_access
+{
+public:
+ unsigned int
+ call_properties (const function_instance &) const override
+ {
+return CP_READ_MEMORY;
+ }
+
+ rtx
+ expand (function_expander ) const override
+ {
+insn_code icode;
+if (e.type_suffix (0).float_p)
+ icode = code_for_mve_vld1q_f(e.vector_mode (0));
+else
+ {
+ if (e.type_suffix (0).unsigned_p)
+ icode = code_for_mve_vld1q(VLD1Q_U,
+e.vector_mode (0));
+ else
+ icode = code_for_mve_vld1q(VLD1Q_S,
+e.vector_mode (0));
+ }
+return e.use_contiguous_load_insn (icode);
+ }
+};
+
+class vst1_impl : public full_width_access
+{
+public:
+ unsigned int
+ call_properties (const function_instance &) const override
+ {
+return CP_WRITE_MEMORY;
+ }
+
+ rtx
+ expand (function_expander ) const override
+ {
+insn_code icode;
+if (e.type_suffix (0).float_p)
+ icode = code_for_mve_vst1q_f(e.vector_mode (0));
+else
+ {
+ if (e.type_suffix (0).unsigned_p)
+ icode = code_for_mve_vst1q(VST1Q_U,
+e.vector_mode (0));
+ else
+ icode = code_for_mve_vst1q(VST1Q_S,
+e.vector_mode (0));
+ }
+return e.use_contiguous_store_insn (icode);
+ }
+};
+
} /* end anonymous namespace */
namespace arm_mve {
@@ -290,6 +346,7 @@ FUNCTION (vfmasq, unspec_mve_function_exact_insn, (-1, -1,
-1, -1, -1, VFMASQ_N_
FUNCTION (vfmsq, unspec_mve_function_exact_insn, (-1, -1, VFMSQ_F, -1, -1, -1,
-1, -1, VFMSQ_M_F, -1, -1, -1))
FUNCTION_WITH_M_N_NO_F (vhaddq, VHADDQ)
FUNCTION_WITH_M_N_NO_F (vhsubq, VHSUBQ)
+FUNCTION (vld1q, vld1_impl,)
FUNCTION_PRED_P_S (vmaxavq, VMAXAVQ)
FUNCTION_WITHOUT_N_NO_U_F (vmaxaq, VMAXAQ)
FUNCTION_ONLY_F (vmaxnmaq, VMAXNMAQ)
@@ -405,6 +462,7 @@ FUNCTION_ONLY_N_NO_F (vshrntq, VSHRNTQ)
FUNCTION_ONLY_N_NO_F (vshrq, VSHRQ)
FUNCTION_ONLY_N_NO_F (vsliq, VSLIQ)
FUNCTION_ONLY_N_NO_F (vsriq, VSRIQ)
+FUNCTION (vst1q, vst1_impl,)
FUNCTION_WITH_RTX_M_N (vsubq, MINUS, VSUBQ)
FUNCTION (vuninitializedq, vuninitializedq_impl,)
diff --git a/gcc/config/arm/arm-mve-builtins-base.def
b/gcc/config/arm/arm-mve-builtins-base.def
index 01dfbdef8a3..16879246237 100644
--- a/gcc/config/arm/arm-mve-builtins-base.def
+++ b/gcc/config/arm/arm-mve-builtins-base.def
@@ -47,6 +47,7 @@ DEF_MVE_FUNCTION (vhaddq, binary_opt_n, all_integer,
mx_or_none)
DEF_MVE_FUNCTION (vhcaddq_rot90, binary, al
[PATCH 3/6] arm: [MVE intrinsics] Add support for contiguous loads and stores
This patch adds base support for load/store intrinsics to the
framework, starting with loads and stores for contiguous memory
elements, without extension nor truncation.
Compared to the aarch64/SVE implementation, there's no support for
gather/scatter loads/stores yet. This will be added later as needed.
2023-11-16 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-functions.h (multi_vector_function)
(full_width_access): New classes.
* config/arm/arm-mve-builtins.cc
(find_type_suffix_for_scalar_type, infer_pointer_type)
(require_pointer_type, get_contiguous_base, add_mem_operand)
(add_fixed_operand, use_contiguous_load_insn)
(use_contiguous_store_insn): New.
* config/arm/arm-mve-builtins.h (memory_vector_mode)
(infer_pointer_type, require_pointer_type, get_contiguous_base)
(add_mem_operand)
(add_fixed_operand, use_contiguous_load_insn)
(use_contiguous_store_insn): New.
---
gcc/config/arm/arm-mve-builtins-functions.h | 56 ++
gcc/config/arm/arm-mve-builtins.cc | 116
gcc/config/arm/arm-mve-builtins.h | 28 -
3 files changed, 199 insertions(+), 1 deletion(-)
diff --git a/gcc/config/arm/arm-mve-builtins-functions.h
b/gcc/config/arm/arm-mve-builtins-functions.h
index eba1f071af0..6d234a2dd7c 100644
--- a/gcc/config/arm/arm-mve-builtins-functions.h
+++ b/gcc/config/arm/arm-mve-builtins-functions.h
@@ -966,6 +966,62 @@ public:
}
};
+/* A function_base that sometimes or always operates on tuples of
+ vectors. */
+class multi_vector_function : public function_base
+{
+public:
+ CONSTEXPR multi_vector_function (unsigned int vectors_per_tuple)
+: m_vectors_per_tuple (vectors_per_tuple) {}
+
+ unsigned int
+ vectors_per_tuple () const override
+ {
+return m_vectors_per_tuple;
+ }
+
+ /* The number of vectors in a tuple, or 1 if the function only operates
+ on single vectors. */
+ unsigned int m_vectors_per_tuple;
+};
+
+/* A function_base that loads or stores contiguous memory elements
+ without extending or truncating them. */
+class full_width_access : public multi_vector_function
+{
+public:
+ CONSTEXPR full_width_access (unsigned int vectors_per_tuple = 1)
+: multi_vector_function (vectors_per_tuple) {}
+
+ tree
+ memory_scalar_type (const function_instance ) const override
+ {
+return fi.scalar_type (0);
+ }
+
+ machine_mode
+ memory_vector_mode (const function_instance ) const override
+ {
+machine_mode mode = fi.vector_mode (0);
+/* Vectors of floating-point are managed in memory as vectors of
+ integers. */
+switch (mode)
+ {
+ case E_V4SFmode:
+ mode = E_V4SImode;
+ break;
+ case E_V8HFmode:
+ mode = E_V8HImode;
+ break;
+ }
+
+if (m_vectors_per_tuple != 1)
+ mode = targetm.array_mode (mode, m_vectors_per_tuple).require ();
+
+return mode;
+ }
+};
+
} /* end namespace arm_mve */
/* Declare the global function base NAME, creating it from an instance
diff --git a/gcc/config/arm/arm-mve-builtins.cc
b/gcc/config/arm/arm-mve-builtins.cc
index 02dc8fa9b73..a265cb05553 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -36,6 +36,7 @@
#include "fold-const.h"
#include "gimple.h"
#include "gimple-iterator.h"
+#include "explow.h"
#include "emit-rtl.h"
#include "langhooks.h"
#include "stringpool.h"
@@ -529,6 +530,22 @@ matches_type_p (const_tree model_type, const_tree
candidate)
&& TYPE_MAIN_VARIANT (model_type) == TYPE_MAIN_VARIANT (candidate));
}
+/* If TYPE is a valid MVE element type, return the corresponding type
+ suffix, otherwise return NUM_TYPE_SUFFIXES. */
+static type_suffix_index
+find_type_suffix_for_scalar_type (const_tree type)
+{
+ /* A linear search should be OK here, since the code isn't hot and
+ the number of types is only small. */
+ for (unsigned int suffix_i = 0; suffix_i < NUM_TYPE_SUFFIXES; ++suffix_i)
+ {
+ vector_type_index vector_i = type_suffixes[suffix_i].vector_type;
+ if (matches_type_p (scalar_types[vector_i], type))
+ return type_suffix_index (suffix_i);
+ }
+ return NUM_TYPE_SUFFIXES;
+}
+
/* Report an error against LOCATION that the user has tried to use
a floating point function when the mve.fp extension is disabled. */
static void
@@ -1125,6 +1142,37 @@ function_resolver::resolve_to (mode_suffix_index mode,
return res;
}
+/* Require argument ARGNO to be a pointer to a scalar type that has a
+ corresponding type suffix. Return that type suffix on success,
+ otherwise report an error and return NUM_TYPE_SUFFIXES. */
+type_suffix_index
+function_resolver::infer_pointer_type (unsigned int argno)
+{
+ tree actual = get_argument_type (argno);
+ if (actual == error_mark_node)
+return NUM_T
[PATCH 5/6] arm: [MVE intrinsics] fix vst1 tests
vst1q intrinsics return void, so we should not do 'return vst1q_f16 (base,
value);'
This was OK so far, but will trigger an error/warning with the new
implementation of these intrinsics.
This patch just removes the 'return' keyword.
2023-11-16 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/mve/intrinsics/vst1q_f16.c: Remove 'return'.
* gcc.target/arm/mve/intrinsics/vst1q_f32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst1q_s16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst1q_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst1q_s8.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst1q_u16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst1q_u32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst1q_u8.c: Likewise.
---
gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c | 4 ++--
gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c | 4 ++--
gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c | 4 ++--
gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s32.c | 4 ++--
gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c | 4 ++--
gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c | 4 ++--
gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u32.c | 4 ++--
gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u8.c | 4 ++--
8 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
index 1fa02f00f53..e4b40604d54 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f16.c
@@ -18,7 +18,7 @@ extern "C" {
void
foo (float16_t *base, float16x8_t value)
{
- return vst1q_f16 (base, value);
+ vst1q_f16 (base, value);
}
@@ -31,7 +31,7 @@ foo (float16_t *base, float16x8_t value)
void
foo1 (float16_t *base, float16x8_t value)
{
- return vst1q (base, value);
+ vst1q (base, value);
}
#ifdef __cplusplus
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c
index 67cc3ae3b47..8f42323c603 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_f32.c
@@ -18,7 +18,7 @@ extern "C" {
void
foo (float32_t *base, float32x4_t value)
{
- return vst1q_f32 (base, value);
+ vst1q_f32 (base, value);
}
@@ -31,7 +31,7 @@ foo (float32_t *base, float32x4_t value)
void
foo1 (float32_t *base, float32x4_t value)
{
- return vst1q (base, value);
+ vst1q (base, value);
}
#ifdef __cplusplus
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
index 052959b2083..891ac4155d9 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s16.c
@@ -18,7 +18,7 @@ extern "C" {
void
foo (int16_t *base, int16x8_t value)
{
- return vst1q_s16 (base, value);
+ vst1q_s16 (base, value);
}
@@ -31,7 +31,7 @@ foo (int16_t *base, int16x8_t value)
void
foo1 (int16_t *base, int16x8_t value)
{
- return vst1q (base, value);
+ vst1q (base, value);
}
#ifdef __cplusplus
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s32.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s32.c
index 444ad07f4ef..a28d1eb98db 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s32.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s32.c
@@ -18,7 +18,7 @@ extern "C" {
void
foo (int32_t *base, int32x4_t value)
{
- return vst1q_s32 (base, value);
+ vst1q_s32 (base, value);
}
@@ -31,7 +31,7 @@ foo (int32_t *base, int32x4_t value)
void
foo1 (int32_t *base, int32x4_t value)
{
- return vst1q (base, value);
+ vst1q (base, value);
}
#ifdef __cplusplus
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c
index 684ff0aca5b..81c141a63e0 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_s8.c
@@ -18,7 +18,7 @@ extern "C" {
void
foo (int8_t *base, int8x16_t value)
{
- return vst1q_s8 (base, value);
+ vst1q_s8 (base, value);
}
@@ -31,7 +31,7 @@ foo (int8_t *base, int8x16_t value)
void
foo1 (int8_t *base, int8x16_t value)
{
- return vst1q (base, value);
+ vst1q (base, value);
}
#ifdef __cplusplus
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c
index 1fea2de1e76..b8ce7fbe6ee 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vst1q_u16.c
@@ -18,7 +18,7 @@ extern "C" {
void
foo (uint16_t *base, uint16x8_t value)
{
- return vst1q_u16 (base, value);
+ vst1q_u16 (base, valu
[PATCH 2/6] arm: [MVE intrinsics] Add support for void and load/store pointers as argument types.
This patch adds support for '_', 'al' and 'as' for void, load pointer
and store pointer argument/return value types in intrinsic signatures.
It also adds a mew memory_scalar_type() helper to function_instance,
which is used by 'al' and 'as'.
2023-11-16 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (build_const_pointer):
New.
(parse_type): Add support for '_', 'al' and 'as'.
* config/arm/arm-mve-builtins.h (function_instance): Add
memory_scalar_type.
(function_base): Likewise.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 25 +++
gcc/config/arm/arm-mve-builtins.h | 17 +++
2 files changed, 42 insertions(+)
diff --git a/gcc/config/arm/arm-mve-builtins-shapes.cc
b/gcc/config/arm/arm-mve-builtins-shapes.cc
index 23eb9d0e69b..ce87ebcef30 100644
--- a/gcc/config/arm/arm-mve-builtins-shapes.cc
+++ b/gcc/config/arm/arm-mve-builtins-shapes.cc
@@ -39,6 +39,13 @@
namespace arm_mve {
+/* Return a representation of "const T *". */
+static tree
+build_const_pointer (tree t)
+{
+ return build_pointer_type (build_qualified_type (t, TYPE_QUAL_CONST));
+}
+
/* If INSTANCE has a predicate, add it to the list of argument types
in ARGUMENT_TYPES. RETURN_TYPE is the type returned by the
function. */
@@ -140,6 +147,9 @@ parse_element_type (const function_instance ,
const char *)
/* Read and return a type from FORMAT for function INSTANCE. Advance
FORMAT beyond the type string. The format is:
+ _ - void
+ al - array pointer for loads
+ as - array pointer for stores
p - predicates with type mve_pred16_t
s - a scalar type with the given element suffix
t - a vector or tuple type with given element suffix [*1]
@@ -156,6 +166,21 @@ parse_type (const function_instance , const char
*)
{
int ch = *format++;
+
+ if (ch == '_')
+return void_type_node;
+
+ if (ch == 'a')
+{
+ ch = *format++;
+ if (ch == 'l')
+ return build_const_pointer (instance.memory_scalar_type ());
+ if (ch == 's') {
+ return build_pointer_type (instance.memory_scalar_type ());
+ }
+ gcc_unreachable ();
+}
+
if (ch == 'p')
return get_mve_pred16_t ();
diff --git a/gcc/config/arm/arm-mve-builtins.h
b/gcc/config/arm/arm-mve-builtins.h
index 37b8223dfb2..4fd230fe4c7 100644
--- a/gcc/config/arm/arm-mve-builtins.h
+++ b/gcc/config/arm/arm-mve-builtins.h
@@ -277,6 +277,7 @@ public:
bool could_trap_p () const;
unsigned int vectors_per_tuple () const;
+ tree memory_scalar_type () const;
const mode_suffix_info _suffix () const;
@@ -519,6 +520,14 @@ public:
of vectors in the tuples, otherwise return 1. */
virtual unsigned int vectors_per_tuple () const { return 1; }
+ /* If the function addresses memory, return the type of a single
+ scalar memory element. */
+ virtual tree
+ memory_scalar_type (const function_instance &) const
+ {
+gcc_unreachable ();
+ }
+
/* Try to fold the given gimple call. Return the new gimple statement
on success, otherwise return null. */
virtual gimple *fold (gimple_folder &) const { return NULL; }
@@ -644,6 +653,14 @@ function_instance::vectors_per_tuple () const
return base->vectors_per_tuple ();
}
+/* If the function addresses memory, return the type of a single
+ scalar memory element. */
+inline tree
+function_instance::memory_scalar_type () const
+{
+ return base->memory_scalar_type (*this);
+}
+
/* Return information about the function's mode suffix. */
inline const mode_suffix_info &
function_instance::mode_suffix () const
--
2.34.1
[PATCH 4/6] arm: [MVE intrinsics] add load and store shapes
This patch adds the load and store shapes descriptions.
2023-11-16 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-shapes.cc (load, store): New.
* config/arm/arm-mve-builtins-shapes.h (load, store): New.
---
gcc/config/arm/arm-mve-builtins-shapes.cc | 67 +++
gcc/config/arm/arm-mve-builtins-shapes.h | 2 +
2 files changed, 69 insertions(+)
diff --git a/gcc/config/arm/arm-mve-builtins-shapes.cc
b/gcc/config/arm/arm-mve-builtins-shapes.cc
index ce87ebcef30..fe983e7c736 100644
--- a/gcc/config/arm/arm-mve-builtins-shapes.cc
+++ b/gcc/config/arm/arm-mve-builtins-shapes.cc
@@ -1428,6 +1428,38 @@ struct inherent_def : public nonoverloaded_base
};
SHAPE (inherent)
+/* sv_t svfoo[_t0](const _t *)
+
+ Example: vld1q.
+ int8x16_t [__arm_]vld1q[_s8](int8_t const *base)
+ int8x16_t [__arm_]vld1q_z[_s8](int8_t const *base, mve_pred16_t p) */
+struct load_def : public overloaded_base<0>
+{
+ void
+ build (function_builder , const function_group_info ,
+bool preserve_user_namespace) const override
+ {
+b.add_overloaded_functions (group, MODE_none, preserve_user_namespace);
+build_all (b, "t0,al", group, MODE_none, preserve_user_namespace);
+ }
+
+ /* Resolve a call based purely on a pointer argument. */
+ tree
+ resolve (function_resolver ) const override
+ {
+gcc_assert (r.mode_suffix_id == MODE_none);
+
+unsigned int i, nargs;
+type_suffix_index type;
+if (!r.check_gp_argument (1, i, nargs)
+ || (type = r.infer_pointer_type (i)) == NUM_TYPE_SUFFIXES)
+ return error_mark_node;
+
+return r.resolve_to (r.mode_suffix_id, type);
+ }
+};
+SHAPE (load)
+
/* _t vfoo[_t0](_t)
_t vfoo_n_t0(_t)
@@ -1477,6 +1509,41 @@ struct mvn_def : public overloaded_base<0>
};
SHAPE (mvn)
+/* void vfoo[_t0](_t *, v[xN]_t)
+
+ where might be tied to (for non-truncating stores) or might
+ depend on the function base name (for truncating stores).
+
+ Example: vst1q.
+ void [__arm_]vst1q[_s8](int8_t *base, int8x16_t value)
+ void [__arm_]vst1q_p[_s8](int8_t *base, int8x16_t value, mve_pred16_t p) */
+struct store_def : public overloaded_base<0>
+{
+ void
+ build (function_builder , const function_group_info ,
+bool preserve_user_namespace) const override
+ {
+b.add_overloaded_functions (group, MODE_none, preserve_user_namespace);
+build_all (b, "_,as,v0", group, MODE_none, preserve_user_namespace);
+ }
+
+ tree
+ resolve (function_resolver ) const override
+ {
+gcc_assert (r.mode_suffix_id == MODE_none);
+
+unsigned int i, nargs;
+type_suffix_index type;
+if (!r.check_gp_argument (2, i, nargs)
+ || !r.require_pointer_type (0)
+ || (type = r.infer_vector_type (1)) == NUM_TYPE_SUFFIXES)
+ return error_mark_node;
+
+return r.resolve_to (r.mode_suffix_id, type);
+ }
+};
+SHAPE (store)
+
/* _t vfoo[_t0](_t, _t, _t)
i.e. the standard shape for ternary operations that operate on
diff --git a/gcc/config/arm/arm-mve-builtins-shapes.h
b/gcc/config/arm/arm-mve-builtins-shapes.h
index a93245321c9..aa9309dec7e 100644
--- a/gcc/config/arm/arm-mve-builtins-shapes.h
+++ b/gcc/config/arm/arm-mve-builtins-shapes.h
@@ -61,7 +61,9 @@ namespace arm_mve
extern const function_shape *const cmp;
extern const function_shape *const create;
extern const function_shape *const inherent;
+extern const function_shape *const load;
extern const function_shape *const mvn;
+extern const function_shape *const store;
extern const function_shape *const ternary;
extern const function_shape *const ternary_lshift;
extern const function_shape *const ternary_n;
--
2.34.1
[PATCH 1/6] arm: Fix arm_simd_types and MVE scalar_types
So far we define arm_simd_types and scalar_types using type
definitions like intSI_type_node, etc...
This is causing problems with later patches which re-implement
load/store MVE intrinsics, leading to error messages such as:
error: passing argument 1 of 'vst1q_s32' from incompatible pointer type
note: expected 'int *' but argument is of type 'int32_t *' {aka 'long int *'}
This patch uses get_typenode_from_name (INT32_TYPE) instead, which
defines the types as appropriate for the target/C library.
2023-11-16 Christophe Lyon
gcc/
* config/arm/arm-builtins.cc (arm_init_simd_builtin_types): Fix
initialization of arm_simd_types[].eltype.
* config/arm/arm-mve-builtins.def (DEF_MVE_TYPE): Fix scalar
types.
---
gcc/config/arm/arm-builtins.cc | 28 ++--
gcc/config/arm/arm-mve-builtins.def | 16
2 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/gcc/config/arm/arm-builtins.cc b/gcc/config/arm/arm-builtins.cc
index fca7dcaf565..dd9c5815c45 100644
--- a/gcc/config/arm/arm-builtins.cc
+++ b/gcc/config/arm/arm-builtins.cc
@@ -1580,20 +1580,20 @@ arm_init_simd_builtin_types (void)
TYPE_STRING_FLAG (arm_simd_polyHI_type_node) = false;
}
/* Init all the element types built by the front-end. */
- arm_simd_types[Int8x8_t].eltype = intQI_type_node;
- arm_simd_types[Int8x16_t].eltype = intQI_type_node;
- arm_simd_types[Int16x4_t].eltype = intHI_type_node;
- arm_simd_types[Int16x8_t].eltype = intHI_type_node;
- arm_simd_types[Int32x2_t].eltype = intSI_type_node;
- arm_simd_types[Int32x4_t].eltype = intSI_type_node;
- arm_simd_types[Int64x2_t].eltype = intDI_type_node;
- arm_simd_types[Uint8x8_t].eltype = unsigned_intQI_type_node;
- arm_simd_types[Uint8x16_t].eltype = unsigned_intQI_type_node;
- arm_simd_types[Uint16x4_t].eltype = unsigned_intHI_type_node;
- arm_simd_types[Uint16x8_t].eltype = unsigned_intHI_type_node;
- arm_simd_types[Uint32x2_t].eltype = unsigned_intSI_type_node;
- arm_simd_types[Uint32x4_t].eltype = unsigned_intSI_type_node;
- arm_simd_types[Uint64x2_t].eltype = unsigned_intDI_type_node;
+ arm_simd_types[Int8x8_t].eltype = get_typenode_from_name (INT8_TYPE);
+ arm_simd_types[Int8x16_t].eltype = get_typenode_from_name (INT8_TYPE);
+ arm_simd_types[Int16x4_t].eltype = get_typenode_from_name (INT16_TYPE);
+ arm_simd_types[Int16x8_t].eltype = get_typenode_from_name (INT16_TYPE);
+ arm_simd_types[Int32x2_t].eltype = get_typenode_from_name (INT32_TYPE);
+ arm_simd_types[Int32x4_t].eltype = get_typenode_from_name (INT32_TYPE);
+ arm_simd_types[Int64x2_t].eltype = get_typenode_from_name (INT64_TYPE);
+ arm_simd_types[Uint8x8_t].eltype = get_typenode_from_name (UINT8_TYPE);
+ arm_simd_types[Uint8x16_t].eltype = get_typenode_from_name (UINT8_TYPE);
+ arm_simd_types[Uint16x4_t].eltype = get_typenode_from_name (UINT16_TYPE);
+ arm_simd_types[Uint16x8_t].eltype = get_typenode_from_name (UINT16_TYPE);
+ arm_simd_types[Uint32x2_t].eltype = get_typenode_from_name (UINT32_TYPE);
+ arm_simd_types[Uint32x4_t].eltype = get_typenode_from_name (UINT32_TYPE);
+ arm_simd_types[Uint64x2_t].eltype = get_typenode_from_name (UINT64_TYPE);
/* Note: poly64x2_t is defined in arm_neon.h, to ensure it gets default
mangling. */
diff --git a/gcc/config/arm/arm-mve-builtins.def
b/gcc/config/arm/arm-mve-builtins.def
index e2cf1baf370..a901d8231e9 100644
--- a/gcc/config/arm/arm-mve-builtins.def
+++ b/gcc/config/arm/arm-mve-builtins.def
@@ -39,14 +39,14 @@ DEF_MVE_MODE (r, none, none, none)
#define REQUIRES_FLOAT false
DEF_MVE_TYPE (mve_pred16_t, boolean_type_node)
-DEF_MVE_TYPE (uint8x16_t, unsigned_intQI_type_node)
-DEF_MVE_TYPE (uint16x8_t, unsigned_intHI_type_node)
-DEF_MVE_TYPE (uint32x4_t, unsigned_intSI_type_node)
-DEF_MVE_TYPE (uint64x2_t, unsigned_intDI_type_node)
-DEF_MVE_TYPE (int8x16_t, intQI_type_node)
-DEF_MVE_TYPE (int16x8_t, intHI_type_node)
-DEF_MVE_TYPE (int32x4_t, intSI_type_node)
-DEF_MVE_TYPE (int64x2_t, intDI_type_node)
+DEF_MVE_TYPE (uint8x16_t, get_typenode_from_name (UINT8_TYPE))
+DEF_MVE_TYPE (uint16x8_t, get_typenode_from_name (UINT16_TYPE))
+DEF_MVE_TYPE (uint32x4_t, get_typenode_from_name (UINT32_TYPE))
+DEF_MVE_TYPE (uint64x2_t, get_typenode_from_name (UINT64_TYPE))
+DEF_MVE_TYPE (int8x16_t, get_typenode_from_name (INT8_TYPE))
+DEF_MVE_TYPE (int16x8_t, get_typenode_from_name (INT16_TYPE))
+DEF_MVE_TYPE (int32x4_t, get_typenode_from_name (INT32_TYPE))
+DEF_MVE_TYPE (int64x2_t, get_typenode_from_name (INT64_TYPE))
#undef REQUIRES_FLOAT
#define REQUIRES_FLOAT true
--
2.34.1
Re: [committed 01/22] arm: testsuite: correctly detect armv6t2 hardware for acle execution tests
Hi,
On 11/13/23 15:26, Richard Earnshaw wrote:
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 1a7bea96c1e..d414cddf4dc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5590,6 +5590,24 @@ proc check_effective_target_arm_thumb1_cbz_ok {} {
}
}
+# Return 1 if this is an Arm target which supports the Armv6t2 extensions.
+# This can be either in Arm state or in Thumb state.
+
+proc check_effective_target_arm_arch_v6t2_hw_ok {} {
+if [check_effective_target_arm_thumb1_ok] {
Why arm_thumb1_ok and not arm_arch_v6t2_ok ?
Thanks,
Christophe
+ return [check_no_compiler_messages arm_movt object {
+ int
+ main (void)
+ {
+ asm ("bfc r0, #1, #2");
+ return 0;
+ }
+ } [add_options_for_arm_arch_v6t2 ""]]
+} else {
+ return 0
+}
+}
+
# Return 1 if this is an ARM target where ARMv8-M Security Extensions is
# available.
Re: [PATCH 5/5] aarch64: Add rsr128 and wsr128 ACLE tests
On 11/7/23 23:51, Richard Sandiford wrote:
Victor Do Nascimento writes:
Extend existing unit tests for the ACLE system register manipulation
functions to include 128-bit tests.
gcc/testsuite/ChangeLog:
* gcc/testsuite/gcc.target/aarch64/acle/rwsr.c (get_rsr128): New.
(set_wsr128): Likewise.
---
gcc/testsuite/gcc.target/aarch64/acle/rwsr.c | 30 +++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/acle/rwsr.c
b/gcc/testsuite/gcc.target/aarch64/acle/rwsr.c
index 3af4b960306..e7725022316 100644
--- a/gcc/testsuite/gcc.target/aarch64/acle/rwsr.c
+++ b/gcc/testsuite/gcc.target/aarch64/acle/rwsr.c
@@ -1,11 +1,15 @@
/* Test the __arm_[r,w]sr ACLE intrinsics family. */
/* Check that function variants for different data types handle types
correctly. */
/* { dg-do compile } */
-/* { dg-options "-O1 -march=armv8.4-a" } */
+/* { dg-options "-O1 -march=armv9.4-a+d128" } */
/* { dg-final { check-function-bodies "**" "" } } */
I'm nervous about having our only tests for 64-bit reads and writes
using such a high minimum version. Could the file instead be compiled
without any minimum architecture and have tests that work with plain
-march=armv8-a? Then the test could switch to other architectures
where necessary using #pragam GCC target. This test...
#include
+#ifndef __ARM_FEATURE_SYSREG128
+#error "__ARM_FEATURE_SYSREG128 feature macro not defined."
+#endif
+
...would still work. with a #pragma GCC target.
Or maybe add a new test file for 128 bit sysregs, and thus have two test
files, the existing one for 64 bit sysregs, and the new one for 128 bit
sysregs?
Thanks,
Christophe
Thanks,
Richard
/*
** get_rsr:
** ...
@@ -66,6 +70,17 @@ get_rsrf64 ()
return __arm_rsrf64("trcseqstr");
}
+/*
+** get_rsr128:
+** mrrsx0, x1, s3_0_c7_c4_0
+** ...
+*/
+__uint128_t
+get_rsr128 ()
+{
+ __arm_rsr128("par_el1");
+}
+
/*
** set_wsr32:
** ...
@@ -129,6 +144,18 @@ set_wsrf64(double a)
__arm_wsrf64("trcseqstr", a);
}
+/*
+** set_wsr128:
+** ...
+** msrrs3_0_c7_c4_0, x0, x1
+** ...
+*/
+void
+set_wsr128 (__uint128_t c)
+{
+ __arm_wsr128 ("par_el1", c);
+}
+
/*
** set_custom:
** ...
@@ -142,3 +169,4 @@ void set_custom()
__uint64_t b = __arm_rsr64("S1_2_C3_C4_5");
__arm_wsr64("S1_2_C3_C4_5", b);
}
+
[PATCH] testsuite: Force use of -c when precompiling headers
In some configurations of our validation setup, we always call the
compiler with -Wl,-rpath=XXX, which instructs the driver to invoke the
linker if none of -c, -S or -E is used.
This happens to be the case in the PCH tests, where dg-flags-pch sets
dg-do-what-default to precompile.
This works most of the time, in absence of any linker option, the
compiler defaults to generating a precompiled header (otherwise the
linker complains because it cannot find 'main').
This small patch forces the use of '-c' when generating the .gch file,
which is sufficient not to invoke the linker.
Arguably, this could be seen as a dejagnu bug: in gcc-dg-test-1 (in
gcc-dg.exp), we set compile_type to "precompiled_header", which is not
one of the supported values in dejagnu's default_target_compile (in
target.exp).
2023-10-27 Christophe Lyon
gcc/testsuite/
* lib/dg-pch.exp (dg-flags-pch): Add -c when generating the
precompiled header.
---
gcc/testsuite/lib/dg-pch.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/lib/dg-pch.exp b/gcc/testsuite/lib/dg-pch.exp
index b6fefaa0286..ae8ce3bf1e1 100644
--- a/gcc/testsuite/lib/dg-pch.exp
+++ b/gcc/testsuite/lib/dg-pch.exp
@@ -95,7 +95,7 @@ proc dg-flags-pch { subdir test otherflags options suffix } {
set dg-do-what-default precompile
catch { file_on_host delete "$bname$suffix" }
gcc_copy_files "[file rootname $test]${suffix}s" "$bname$suffix"
- dg-test -keep-output "./$bname$suffix" "$otherflags $flags" ""
+ dg-test -keep-output "./$bname$suffix" "$otherflags $flags -c" ""
# For the rest, the default is to compile to .s.
set dg-do-what-default compile
--
2.34.1
Re: [pushed] [RA]: Modify cost calculation for dealing with pseudo equivalences
On Fri, 27 Oct 2023 at 16:19, Vladimir Makarov wrote:
>
>
> On 10/27/23 09:56, Christophe Lyon wrote:
> > Hi Vladimir,
> >
> > On Thu, 26 Oct 2023 at 16:00, Vladimir Makarov
> > wrote:
> >> This is the second attempt to improve RA cost calculation for pseudos
> >> with equivalences. The patch explanation is in the log message.
> >>
> >> The patch was successfully bootstrapped and tested on x86-64, aarch64,
> >> and ppc64le. The patch was also benchmarked on x86-64 spec2017.
> >> specfp2017 performance did not changed, specint2017 improved by 0.3%.
> >>
> > As reported by our CI, this patch causes a regression on arm:
> > FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3
> >
> >
> > For this testcase, we used to generate:
> > str lr, [sp, #-4]!
> > sub sp, sp, #12
> > add r0, sp, #4
> > bl bar
> > add r0, sp, #4
> > bl bar
> > add r0, sp, #4
> > bl bar
> > add sp, sp, #12
> > ldr lr, [sp], #4
> > bx lr
> >
> > After your patch, we generate:
> > push{r4, lr}
> > sub sp, sp, #8
> > add r4, sp, #4
> > mov r0, r4
> > bl bar
> > mov r0, r4
> > bl bar
> > mov r0, r4
> > bl bar
> > add sp, sp, #8
> > pop {r4, lr}
> > bx lr
> >
> > which uses 1 more register and 1 more instruction.
> >
> > Shall I file a bugzilla report for this?
> >
> I started to work on this right after I got the message (yesterday). I
> already have a patch and am going to commit it during an hour. So there
> is no need to fill the PR.
>
Great, thanks for the quick fix!
Re: [pushed] [RA]: Modify cost calculation for dealing with pseudo equivalences
Hi Vladimir,
On Thu, 26 Oct 2023 at 16:00, Vladimir Makarov wrote:
>
> This is the second attempt to improve RA cost calculation for pseudos
> with equivalences. The patch explanation is in the log message.
>
> The patch was successfully bootstrapped and tested on x86-64, aarch64,
> and ppc64le. The patch was also benchmarked on x86-64 spec2017.
> specfp2017 performance did not changed, specint2017 improved by 0.3%.
>
As reported by our CI, this patch causes a regression on arm:
FAIL: gcc.target/arm/eliminate.c scan-assembler-times r0,[\\t ]*sp 3
For this testcase, we used to generate:
str lr, [sp, #-4]!
sub sp, sp, #12
add r0, sp, #4
bl bar
add r0, sp, #4
bl bar
add r0, sp, #4
bl bar
add sp, sp, #12
ldr lr, [sp], #4
bx lr
After your patch, we generate:
push{r4, lr}
sub sp, sp, #8
add r4, sp, #4
mov r0, r4
bl bar
mov r0, r4
bl bar
mov r0, r4
bl bar
add sp, sp, #8
pop {r4, lr}
bx lr
which uses 1 more register and 1 more instruction.
Shall I file a bugzilla report for this?
Thanks,
Christophe
Re: [PATCH] libcpp: Improve the diagnostic for poisoned identifiers [PR36887]
On Thu, 26 Oct 2023 at 19:44, Lewis Hyatt wrote:
>
> On Thu, Oct 26, 2023 at 12:48 PM Christophe Lyon
> wrote:
> >
> > On Thu, 26 Oct 2023 at 18:18, Lewis Hyatt wrote:
> > >
> > > On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon
> > > wrote:
> > > > We have noticed that the new tests fail on aarch64 with:
> > > > .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o: in function `_start':
> > > > .../sysdeps/aarch64/start.S:110:(.text+0x38): undefined reference to
> > > > `main'
> > > >
> > > > Looking at the test, I'd say it lacks a dg-do compile (to avoid
> > > > linking), but how does it work on other targets?
> > >
> > > Thanks for pointing it out. I am definitely under the impression that
> > > { dg-do compile } is the default and doesn't need to be specified, I
> > > have never seen it not be the case before... Is that just not correct?
> > > I tried it out on the cfarm (gcc185) for aarch64-redhat-linux and it
> > > works for me there too, I tried the test individually and also as part
> > > of the whole check-gcc-c++ target.
> > >
> > > I do see that there are target-dependent functions in
> > > testsuite/lib/*.exp that will change dg-do-what-default under some
> > > circumstances... but I also see in dg-pch.exp (which is the one
> > > relevant for this test g++.dg/pch/pr36887.C) that dg-do-what-default
> > > is set to compile explicitly.
> >
> > Indeed, thanks for checking.
> >
> > > Note sure what the best next step is, should I just add { dg-do
> > > compile } since it's harmless in any case, or is there something else
> > > worth looking into here? I'm not sure why I couldn't reproduce the
> > > issue on the compile farm machine either, maybe you wouldn't mind
> > > please check if adding this line fixes it for you anyway? Thanks...
> >
> > Can you share the compile line for this test in g++.log?
> >
>
> Sure, here is what I got on aarch64 for
>
> make RUNTESTFLAGS=pch.exp=pr36887.C check-gcc-c++
>
> For making the PCH:
>
> xg++ -B/dev/shm/lhyatt/build/gcc/testsuite/g++/../../ ./pr36887.H
> -fdiagnostics-plain-output -nostdinc++
> -I/dev/shm/lhyatt/build/aarch64-unknown-linux-gnu/libstdc++-v3/include/aarch64-unknown-linux-gnu
> -I/dev/shm/lhyatt/build/aarch64-unknown-linux-gnu/libstdc++-v3/include
> -I/dev/shm/lhyatt/src/libstdc++-v3/libsupc++
> -I/dev/shm/lhyatt/src/libstdc++-v3/include/backward
> -I/dev/shm/lhyatt/src/libstdc++-v3/testsuite/util -fmessage-length=0
> -g -o pr36887.H.gch
>
> For compiling the test:
>
> xg++ -B/dev/shm/lhyatt/build/gcc/testsuite/g++/../../
> /dev/shm/lhyatt/src/gcc/testsuite/g++.dg/pch/pr36887.C
> -fdiagnostics-plain-output -nostdinc++
> -I/dev/shm/lhyatt/build/aarch64-unknown-linux-gnu/libstdc++-v3/include/aarch64-unknown-linux-gnu
> -I/dev/shm/lhyatt/build/aarch64-unknown-linux-gnu/libstdc++-v3/include
> -I/dev/shm/lhyatt/src/libstdc++-v3/libsupc++
> -I/dev/shm/lhyatt/src/libstdc++-v3/include/backward
> -I/dev/shm/lhyatt/src/libstdc++-v3/testsuite/util -fmessage-length=0
> -g -I. -Dwith_PCH -S -o pr36887.s
>
> (and then it repeats with -O2 added, or with -g removed as well)
OK, thanks.
Our CI harness adds a few linker options to g++
(-Wl,--dynamic-linker=XXX, -Wl-,-rpath...)
which seem to force the GCC driver to invoke the linker.
So, nothing to fix on the testsuite side ;-)
I'll have a look to check if this is a driver bug, or if it can be
fixed in our scripts.
Sorry for the false alarm,
Christophe
>
> > Actually I'm seeing several similar errors in our g++.log, not
> > reported before because they were "pre-existing" failures.
> > So something is confusing the testsuite and puts it into link mode.
> >
> > I am currently building from scratch, without our CI scripts to get
> > some additional logs in a setup that probably matches yours. Then I
> > should be able to add more traces a dejagnu level to understand what's
> > happening.
> >
> > Thanks,
> >
> > Christophe
Re: [PATCH] libcpp: Improve the diagnostic for poisoned identifiers [PR36887]
On Thu, 26 Oct 2023 at 18:18, Lewis Hyatt wrote:
>
> On Thu, Oct 26, 2023 at 4:49 AM Christophe Lyon
> wrote:
> > We have noticed that the new tests fail on aarch64 with:
> > .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o: in function `_start':
> > .../sysdeps/aarch64/start.S:110:(.text+0x38): undefined reference to `main'
> >
> > Looking at the test, I'd say it lacks a dg-do compile (to avoid
> > linking), but how does it work on other targets?
>
> Thanks for pointing it out. I am definitely under the impression that
> { dg-do compile } is the default and doesn't need to be specified, I
> have never seen it not be the case before... Is that just not correct?
> I tried it out on the cfarm (gcc185) for aarch64-redhat-linux and it
> works for me there too, I tried the test individually and also as part
> of the whole check-gcc-c++ target.
>
> I do see that there are target-dependent functions in
> testsuite/lib/*.exp that will change dg-do-what-default under some
> circumstances... but I also see in dg-pch.exp (which is the one
> relevant for this test g++.dg/pch/pr36887.C) that dg-do-what-default
> is set to compile explicitly.
Indeed, thanks for checking.
> Note sure what the best next step is, should I just add { dg-do
> compile } since it's harmless in any case, or is there something else
> worth looking into here? I'm not sure why I couldn't reproduce the
> issue on the compile farm machine either, maybe you wouldn't mind
> please check if adding this line fixes it for you anyway? Thanks...
Can you share the compile line for this test in g++.log?
Actually I'm seeing several similar errors in our g++.log, not
reported before because they were "pre-existing" failures.
So something is confusing the testsuite and puts it into link mode.
I am currently building from scratch, without our CI scripts to get
some additional logs in a setup that probably matches yours. Then I
should be able to add more traces a dejagnu level to understand what's
happening.
Thanks,
Christophe
Re: [PATCH] libcpp: Improve the diagnostic for poisoned identifiers [PR36887]
Hi! On Wed, 20 Sept 2023 at 06:12, Lewis Hyatt wrote: > > Hello- > > This patch implements the PR's request to add more information to the > diagnostic issued for using a poisoned identifier. Bootstrapped + regtested > all languages on x86-64 Linux. Does it look OK please? Thanks! > > -Lewis > > -- >8 -- > > The PR requests an enhancement to the diagnostic issued for the use of a > poisoned identifier. Currently, we show the location of the usage, but not > the location which requested the poisoning, which would be helpful for the > user if the decision to poison an identifier was made externally, such as > in a library header. > > In order to output this information, we need to remember a location_t for > each identifier that has been poisoned, and that data needs to be preserved > as well in a PCH. One option would be to add a field to struct cpp_hashnode, > but there is no convenient place to add it without increasing the size of > the struct for all identifiers. Given this facility will be needed rarely, > it seemed better to add a second hash map, which is handled PCH-wise the > same as the current one in gcc/stringpool.cc. This hash map associates a new > struct cpp_hashnode_extra with each identifier that needs one. Currently > that struct only contains the new location_t, but it could be extended in > the future if there is other ancillary data that may be convenient to put > there for other purposes. > > libcpp/ChangeLog: > > PR preprocessor/36887 > * directives.cc (do_pragma_poison): Store in the extra hash map the > location from which an identifier has been poisoned. > * lex.cc (identifier_diagnostics_on_lex): When issuing a diagnostic > for the use of a poisoned identifier, also add a note indicating the > location from which it was poisoned. > * identifiers.cc (alloc_node): Convert to template function. > (_cpp_init_hashtable): Handle the new extra hash map. > (_cpp_destroy_hashtable): Likewise. > * include/cpplib.h (struct cpp_hashnode_extra): New struct. > (cpp_create_reader): Update prototype to... > * init.cc (cpp_create_reader): ...accept an argument for the extra > hash table and pass it to _cpp_init_hashtable. > * include/symtab.h (ht_lookup): New overload for convenience. > * internal.h (struct cpp_reader): Add EXTRA_HASH_TABLE member. > (_cpp_init_hashtable): Adjust prototype. > > gcc/c-family/ChangeLog: > > PR preprocessor/36887 > * c-opts.cc (c_common_init_options): Pass new extra hash map > argument to cpp_create_reader(). > > gcc/ChangeLog: > > PR preprocessor/36887 > * toplev.h (ident_hash_extra): Declare... > * stringpool.cc (ident_hash_extra): ...this new global variable. > (init_stringpool): Handle ident_hash_extra as well as ident_hash. > (ggc_mark_stringpool): Likewise. > (ggc_purge_stringpool): Likewise. > (struct string_pool_data_extra): New struct. > (spd2): New GC root variable. > (gt_pch_save_stringpool): Use spd2 to handle ident_hash_extra, > analogous to how spd is used to handle ident_hash. > (gt_pch_restore_stringpool): Likewise. > > gcc/testsuite/ChangeLog: > > PR preprocessor/36887 > * c-c++-common/cpp/diagnostic-poison.c: New test. > * g++.dg/pch/pr36887.C: New test. > * g++.dg/pch/pr36887.Hs: New test. We have noticed that the new tests fail on aarch64 with: .../aarch64-unknown-linux-gnu/libc/usr/lib/crt1.o: in function `_start': .../sysdeps/aarch64/start.S:110:(.text+0x38): undefined reference to `main' Looking at the test, I'd say it lacks a dg-do compile (to avoid linking), but how does it work on other targets? Thanks, Christophe > --- > libcpp/directives.cc | 3 ++ > libcpp/identifiers.cc | 42 +++-- > libcpp/include/cpplib.h | 21 ++--- > libcpp/include/symtab.h | 6 +++ > libcpp/init.cc| 4 +- > libcpp/internal.h | 8 +++- > libcpp/lex.cc | 10 - > gcc/c-family/c-opts.cc| 2 +- > gcc/stringpool.cc | 45 +++ > gcc/toplev.h | 3 +- > .../c-c++-common/cpp/diagnostic-poison.c | 13 ++ > gcc/testsuite/g++.dg/pch/pr36887.C| 3 ++ > gcc/testsuite/g++.dg/pch/pr36887.Hs | 1 + > 13 files changed, 134 insertions(+), 27 deletions(-) > create mode 100644 gcc/testsuite/c-c++-common/cpp/diagnostic-poison.c > create mode 100644 gcc/testsuite/g++.dg/pch/pr36887.C > create mode 100644 gcc/testsuite/g++.dg/pch/pr36887.Hs > > diff --git a/libcpp/directives.cc b/libcpp/directives.cc > index ee5419d1f40..c5c938fda1d 100644 > --- a/libcpp/directives.cc > +++
Re: [PATCH] testsuite: Fix gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c
Ping? Le lun. 2 oct. 2023, 10:23, Christophe Lyon a écrit : > ping? maybe this counts as obvious? > > > On Thu, 14 Sept 2023 at 11:13, Christophe Lyon > wrote: > >> ping? >> >> On Fri, 8 Sept 2023 at 10:43, Christophe Lyon >> wrote: >> >>> The test was declaring 'int *carry;' and wrote to '*carry' without >>> initializing 'carry' first, leading to an attempt to write at address >>> zero, and a crash. >>> >>> Fix by declaring 'int carry;' and passing '' instead of 'carry' >>> as parameter. >>> >>> 2023-09-08 Christophe Lyon >>> >>> gcc/testsuite/ >>> * gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c: Fix. >>> --- >>> .../arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c | 34 +-- >>> 1 file changed, 17 insertions(+), 17 deletions(-) >>> >>> diff --git >>> a/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c >>> b/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c >>> index a8c6cce67c8..931c9d2f30b 100644 >>> --- a/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c >>> +++ b/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c >>> @@ -7,7 +7,7 @@ >>> >>> volatile int32x4_t c1; >>> volatile uint32x4_t c2; >>> -int *carry; >>> +int carry; >>> >>> int >>> main () >>> @@ -21,45 +21,45 @@ main () >>>uint32x4_t inactive2 = vcreateq_u32 (0, 0); >>> >>>mve_pred16_t p = 0x; >>> - (*carry) = 0x; >>> + carry = 0x; >>> >>>__builtin_arm_set_fpscr_nzcvqc (0); >>> - c1 = vadcq (a1, b1, carry); >>> + c1 = vadcq (a1, b1, ); >>>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >>> __builtin_abort (); >>> - (*carry) = 0x; >>> + carry = 0x; >>>__builtin_arm_set_fpscr_nzcvqc (0); >>> - c2 = vadcq (a2, b2, carry); >>> + c2 = vadcq (a2, b2, ); >>>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >>> __builtin_abort (); >>> - (*carry) = 0x; >>> + carry = 0x; >>>__builtin_arm_set_fpscr_nzcvqc (0); >>> - c1 = vsbcq (a1, b1, carry); >>> + c1 = vsbcq (a1, b1, ); >>>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >>> __builtin_abort (); >>> - (*carry) = 0x; >>> + carry = 0x; >>>__builtin_arm_set_fpscr_nzcvqc (0); >>> - c2 = vsbcq (a2, b2, carry); >>> + c2 = vsbcq (a2, b2, ); >>>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >>> __builtin_abort (); >>> - (*carry) = 0x; >>> + carry = 0x; >>>__builtin_arm_set_fpscr_nzcvqc (0); >>> - c1 = vadcq_m (inactive1, a1, b1, carry, p); >>> + c1 = vadcq_m (inactive1, a1, b1, , p); >>>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >>> __builtin_abort (); >>> - (*carry) = 0x; >>> + carry = 0x; >>>__builtin_arm_set_fpscr_nzcvqc (0); >>> - c2 = vadcq_m (inactive2, a2, b2, carry, p); >>> + c2 = vadcq_m (inactive2, a2, b2, , p); >>>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >>> __builtin_abort (); >>> - (*carry) = 0x; >>> + carry = 0x; >>>__builtin_arm_set_fpscr_nzcvqc (0); >>> - c1 = vsbcq_m (inactive1, a1, b1, carry, p); >>> + c1 = vsbcq_m (inactive1, a1, b1, , p); >>>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >>> __builtin_abort (); >>> - (*carry) = 0x; >>> + carry = 0x; >>>__builtin_arm_set_fpscr_nzcvqc (0); >>> - c2 = vsbcq_m (inactive2, a2, b2, carry, p); >>> + c2 = vsbcq_m (inactive2, a2, b2, , p); >>>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >>> __builtin_abort (); >>> >>> -- >>> 2.34.1 >>> >>>
Re: [PATCH 1/2] testsuite: Add and use thread_fence effective-target
Ping?
Le lun. 2 oct. 2023, 10:24, Christophe Lyon a
écrit :
> ping?
>
> On Sun, 10 Sept 2023 at 21:31, Christophe Lyon
> wrote:
>
>> Some targets like arm-eabi with newlib and default settings rely on
>> __sync_synchronize() to ensure synchronization. Newlib does not
>> implement it by default, to make users aware they have to take special
>> care.
>>
>> This makes a few tests fail to link.
>>
>> This patch adds a new thread_fence effective target (similar to the
>> corresponding one in libstdc++ testsuite), and uses it in the tests
>> that need it, making them UNSUPPORTED instead of FAIL and UNRESOLVED.
>>
>> 2023-09-10 Christophe Lyon
>>
>> gcc/
>> * doc/sourcebuild.texi (Other attributes): Document thread_fence
>> effective-target.
>>
>> gcc/testsuite/
>> * g++.dg/init/array54.C: Require thread_fence.
>> * gcc.dg/c2x-nullptr-1.c: Likewise.
>> * gcc.dg/pr103721-2.c: Likewise.
>> * lib/target-supports.exp (check_effective_target_thread_fence):
>> New.
>> ---
>> gcc/doc/sourcebuild.texi | 4
>> gcc/testsuite/g++.dg/init/array54.C | 1 +
>> gcc/testsuite/gcc.dg/c2x-nullptr-1.c | 1 +
>> gcc/testsuite/gcc.dg/pr103721-2.c | 1 +
>> gcc/testsuite/lib/target-supports.exp | 12
>> 5 files changed, 19 insertions(+)
>>
>> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
>> index 1a78b3c1abb..a5f61c29f3b 100644
>> --- a/gcc/doc/sourcebuild.texi
>> +++ b/gcc/doc/sourcebuild.texi
>> @@ -2860,6 +2860,10 @@ Compiler has been configured to support link-time
>> optimization (LTO).
>> Compiler and linker support link-time optimization relocatable linking
>> with @option{-r} and @option{-flto} options.
>>
>> +@item thread_fence
>> +Target implements @code{__atomic_thread_fence} without relying on
>> +non-implemented @code{__sync_synchronize()}.
>> +
>> @item naked_functions
>> Target supports the @code{naked} function attribute.
>>
>> diff --git a/gcc/testsuite/g++.dg/init/array54.C
>> b/gcc/testsuite/g++.dg/init/array54.C
>> index f6be350ba72..5241e451d6d 100644
>> --- a/gcc/testsuite/g++.dg/init/array54.C
>> +++ b/gcc/testsuite/g++.dg/init/array54.C
>> @@ -1,5 +1,6 @@
>> // PR c++/90947
>> // { dg-do run { target c++11 } }
>> +// { dg-require-effective-target thread_fence }
>>
>> #include
>>
>> diff --git a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
>> b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
>> index 4e440234d52..97a31c27409 100644
>> --- a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
>> +++ b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
>> @@ -1,5 +1,6 @@
>> /* Test valid usage of C23 nullptr. */
>> /* { dg-do run } */
>> +// { dg-require-effective-target thread_fence }
>> /* { dg-options "-std=c2x -pedantic-errors -Wall -Wextra
>> -Wno-unused-variable" } */
>>
>> #include
>> diff --git a/gcc/testsuite/gcc.dg/pr103721-2.c
>> b/gcc/testsuite/gcc.dg/pr103721-2.c
>> index aefa1f0f147..e059b1cfc2d 100644
>> --- a/gcc/testsuite/gcc.dg/pr103721-2.c
>> +++ b/gcc/testsuite/gcc.dg/pr103721-2.c
>> @@ -1,4 +1,5 @@
>> // { dg-do run }
>> +// { dg-require-effective-target thread_fence }
>> // { dg-options "-O2" }
>>
>> extern void abort ();
>> diff --git a/gcc/testsuite/lib/target-supports.exp
>> b/gcc/testsuite/lib/target-supports.exp
>> index d353cc0aaf0..7ac9e7530cc 100644
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -9107,6 +9107,18 @@ proc check_effective_target_sync_char_short { } {
>> || [check_effective_target_mips_llsc] }}]
>> }
>>
>> +# Return 1 if thread_fence does not rely on __sync_synchronize
>> +# library function
>> +
>> +proc check_effective_target_thread_fence {} {
>> +return [check_no_compiler_messages thread_fence executable {
>> + int main () {
>> + __atomic_thread_fence (__ATOMIC_SEQ_CST);
>> + return 0;
>> + }
>> +} ""]
>> +}
>> +
>> # Return 1 if the target uses a ColdFire FPU.
>>
>> proc check_effective_target_coldfire_fpu { } {
>> --
>> 2.34.1
>>
>>
Re: Ping: [PATCH v2 2/2] testsuite: Replace many dg-require-thread-fence with dg-require-atomic-cmpxchg-word
LGTM but I'm not a maintainer ;-)
On Thu, 12 Oct 2023 at 04:22, Hans-Peter Nilsson wrote:
>
> Ping.
>
> > From: Hans-Peter Nilsson
> > Date: Wed, 4 Oct 2023 19:08:16 +0200
> >
> > s/atomic-exchange/atomic-cmpxchg-word/g.
> > Tested as v1.
> >
> > Ok to commit?
> > -- >8 --
> > These tests actually use a form of atomic compare and exchange
> > operation, not just atomic loading and storing. Some targets (not
> > supported by e.g. libatomic) have atomic loading and storing, but not
> > compare and exchange, yielding linker errors for missing library
> > functions.
> >
> > This change is just for existing uses of
> > dg-require-thread-fence. It does not fix any other tests
> > that should also be gated on dg-require-atomic-cmpxchg-word.
> >
> > * testsuite/29_atomics/atomic/compare_exchange_padding.cc,
> > testsuite/29_atomics/atomic_flag/clear/1.cc,
> > testsuite/29_atomics/atomic_flag/cons/value_init.cc,
> > testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc,
> > testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc,
> > testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc,
> > testsuite/29_atomics/atomic_ref/generic.cc,
> > testsuite/29_atomics/atomic_ref/integral.cc,
> > testsuite/29_atomics/atomic_ref/pointer.cc: Replace
> > dg-require-thread-fence with dg-require-atomic-cmpxchg-word.
> > ---
> > .../testsuite/29_atomics/atomic/compare_exchange_padding.cc | 2 +-
> > libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc| 2 +-
> > .../testsuite/29_atomics/atomic_flag/cons/value_init.cc | 2 +-
> > .../testsuite/29_atomics/atomic_flag/test_and_set/explicit.cc | 2 +-
> > .../testsuite/29_atomics/atomic_flag/test_and_set/implicit.cc | 2 +-
> > .../testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc | 2 +-
> > libstdc++-v3/testsuite/29_atomics/atomic_ref/generic.cc | 2 +-
> > libstdc++-v3/testsuite/29_atomics/atomic_ref/integral.cc| 2 +-
> > libstdc++-v3/testsuite/29_atomics/atomic_ref/pointer.cc | 2 +-
> > 9 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git
> > a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> > b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> > index 01f7475631e6..859629e625f8 100644
> > --- a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> > +++ b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
> > @@ -1,5 +1,5 @@
> > // { dg-do run { target c++20 } }
> > -// { dg-require-thread-fence "" }
> > +// { dg-require-atomic-cmpxchg-word "" }
> > // { dg-add-options libatomic }
> >
> > #include
> > diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
> > b/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
> > index 89ed381fe057..2e154178dbd7 100644
> > --- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
> > +++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc
> > @@ -1,5 +1,5 @@
> > // { dg-do run { target c++11 } }
> > -// { dg-require-thread-fence "" }
> > +// { dg-require-atomic-cmpxchg-word "" }
> >
> > // Copyright (C) 2009-2023 Free Software Foundation, Inc.
> > //
> > diff --git
> > a/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
> > b/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
> > index f3f38b54dbcd..6439873be133 100644
> > --- a/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
> > +++ b/libstdc++-v3/testsuite/29_atomics/atomic_flag/cons/value_init.cc
> > @@ -16,7 +16,7 @@
> > //
Re: Ping: [PATCH v2 1/2] testsuite: Add dg-require-atomic-cmpxchg-word
LGTM but I'm not a maintainer ;-)
On Thu, 12 Oct 2023 at 04:21, Hans-Peter Nilsson wrote:
>
> Ping.
>
> > From: Hans-Peter Nilsson
> > Date: Wed, 4 Oct 2023 19:04:55 +0200
> >
> > > From: Hans-Peter Nilsson
> > > Date: Wed, 4 Oct 2023 17:15:28 +0200
> >
> > > New version coming up.
> >
> > Using pointer-sized int instead of int,
> > __atomic_compare_exchange instead of __atomic_exchange,
> > renamed to atomic-cmpxchg-word from atomic-exchange, and
> > updating a comment that already seemed reasonably well
> > placed.
> >
> > Tested as with v1 1/2.
> >
> > Ok to commit?
> >
> > -- >8 --
> > Some targets (armv6-m) support inline atomic load and store,
> > i.e. dg-require-thread-fence matches, but not atomic operations like
> > compare and exchange.
> >
> > This directive can be used to replace uses of dg-require-thread-fence
> > where an atomic operation is actually used.
> >
> > * testsuite/lib/dg-options.exp (dg-require-atomic-cmpxchg-word):
> > New proc.
> > * testsuite/lib/libstdc++.exp (check_v3_target_atomic_cmpxchg_word):
> > Ditto.
> > ---
> > libstdc++-v3/testsuite/lib/dg-options.exp | 9 ++
> > libstdc++-v3/testsuite/lib/libstdc++.exp | 37 +++
> > 2 files changed, 46 insertions(+)
> >
> > diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp
> > b/libstdc++-v3/testsuite/lib/dg-options.exp
> > index 84ad0c65330b..850442b6b7c1 100644
> > --- a/libstdc++-v3/testsuite/lib/dg-options.exp
> > +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
> > @@ -133,6 +133,15 @@ proc dg-require-thread-fence { args } {
> > return
> > }
> >
> > +proc dg-require-atomic-cmpxchg-word { args } {
> > +if { ![ check_v3_target_atomic_cmpxchg_word ] } {
> > + upvar dg-do-what dg-do-what
> > + set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
> > + return
> > +}
> > +return
> > +}
> > +
> > proc dg-require-atomic-builtins { args } {
> > if { ![ check_v3_target_atomic_builtins ] } {
> > upvar dg-do-what dg-do-what
> > diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp
> > b/libstdc++-v3/testsuite/lib/libstdc++.exp
> > index 608056e5068e..4bedb36dc6f9 100644
> > --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> > +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> > @@ -1221,6 +1221,43 @@ proc check_v3_target_thread_fence { } {
> > }]
> > }
> >
> > +proc check_v3_target_atomic_cmpxchg_word { } {
> > +return [check_v3_target_prop_cached et_atomic_cmpxchg_word {
> > + global cxxflags
> > + global DEFAULT_CXXFLAGS
> > +
> > + # Set up and link a C++11 test program that depends on
> > + # atomic-compare-exchange being available for a pointer-sized
> > + # integer. It should be sufficient as gcc can derive all
> > + # other operations when a target implements this operation.
> > + set src atomic_cmpxchg_word[pid].cc
> > +
> > + set f [open $src "w"]
> > + puts $f "
> > + __UINTPTR_TYPE__ i, j, k;
> > + int main() {
> > + __atomic_compare_exchange (, , , 1, __ATOMIC_SEQ_CST,
> > __ATOMIC_SEQ_CST);
> > + return 0;
> > + }"
> > + close $f
> > +
> > + set cxxflags_saved $cxxflags
> > + set cxxflags "$cxxflags $DEFAULT_CXXFLAGS -Werror -std=gnu++11"
> > +
> > + set lines [v3_target_compile $src /dev/null executable ""]
> > + set cxxflags $cxxflags_saved
> > + file delete $src
> > +
> > + if [string match "" $lines] {
> > + # No error message, linking succeeded.
> > + return 1
> > + } else {
> > + verbose "check_v3_target_atomic_cmpxchg_word: compilation failed"
> > 2
> > + return 0
> > + }
> > +}]
> > +}
> > +
> > # Return 1 if atomics_bool and atomic_int are always lock-free, 0
> > otherwise.
> > proc check_v3_target_atomic_builtins { } {
> > return [check_v3_target_prop_cached et_atomic_builtins {
> > --
> > 2.30.2
> >
Re: [PATCH] __atomic_test_and_set: Fall back to library, not non-atomic code
On Wed, 4 Oct 2023 at 02:49, Hans-Peter Nilsson wrote: > (Just before sending, I noticed you replied off-list; I > won't add back gcc-patches to cc here myself, but please > feel free to do it, if you choose to reply.) > Sorry, it was a typo of mine, I meant to reply to the list > > > From: Christophe Lyon > > Date: Tue, 3 Oct 2023 18:06:21 +0200 > > > On Tue, 3 Oct 2023 at 17:16, Hans-Peter Nilsson wrote: > > > > > > From: Christophe Lyon > > > > Date: Tue, 3 Oct 2023 15:20:39 +0200 > > > > > > > The patch passed almost all our CI configurations, except arm-eabi > when > > > > testing with > > > > -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto > > > > where is causes these failures: > > > > FAIL: 29_atomics/atomic_flag/clear/1.cc -std=gnu++17 (test for excess > > > > errors) > > > > UNRESOLVED: 29_atomics/atomic_flag/clear/1.cc -std=gnu++17 > compilation > > > > failed to produce executable > [...] > > > For which set of multilibs in that set, do you get these > > > errors? I'm guessing -march=armv6s-m, but I'm checking. > > > > > > > Not sure to understand the question? > > By your "testing with > -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto" > I presume you mean "testing with make check > > 'RUNTESTFLAGS=--target_board=arm-sim/-mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto' > (as that's where you usually put that expression) > Yes > > - but I misremembered what "/" means in RUNTESTFLAGS (it's > combining options in one single set of options passed to > gcc, not delimiting separate options used to form > combinations). Sorry for the confusion! > I see. Actually I always find "multilib" confusing in the context of running the tests, where in fact we generally mean we add some flags in RUNTESTFLAGS and/or --target_board. To me, multilib refers to the set of lib variants we build, but I noticed "multilib" is often used in the context of running the tests... > > > > > Maybe we need a new variant of dg-require-thread-fence ? > > > > > > Perhaps. > > Or rather: most certainly. IIUC, ARMv6 (or whatever you > prefer to call it) can load and store atomically, but only > as separate events; it can't atomically exchange a stored > value and therefore arm-eabi calls out to a library > function. > In this case, it's armv6s-m (which is different from armv6) And yes, it seems so, as your patch showed, assuming there's no bug in the target description ;-) > I think I'll help and replace the obvious uses of > dg-require-thread-fence where actually an atomic exchange is > required; replacing those with a new directive > dg-require-atomic-exchange. That will however not be *all* > places where such a guard should be added. > Indeed. > I also see lots of undefined references to *other* outlined > atomic builtins, for example __atomic_compare_exchange_4 and > __atomic_fetch_add_4. Though, those likely aren't > regressions. I understand you focus on regressions here. > Yes, my reply to your patch was meant to look at the regressions. As a separate action, I plan to look at the remaining existing such failures. > By the way, how do you test; what simulator, what baseboard > file? Please share! Also, please send *some* > contrib/test_summary reports for arm-eabi to > gcc-testresults@ every now and then. (But also, please > We use qemu, with qemu.exp from: https://git.linaro.org/toolchain/abe.git/tree/config/boards/qemu.exp nothing fancy ;-) > don't post multiple results several times a day for similar > configurations. Looking at you, powerpc people!) > We have plans to restart sending such results, like I was doing several years ago (with many results every day, too ;-)) > I can't test *anything* newer than default arm-eabi (armv4t) > on arm-sim (the one next to gdb), or else execution tests > get lost and time out while also complaining about "Unknown > machine type". I noticed there's a qemu.exp in ToT dejagnu, > but it doesn't work for arm-eabi for at least two reasons. > (I might get to that yak later, I just take it as a sign > that qemu-arm isn't what I look for.) We do use qemu-arm, depending on how you want to test, maybe you need to add a -cpu flag such that it supports the required instructions. > > Unless of course, there's a multilib combination > > > for which you *can* emit the proper atomic spell; missing it > > > because the need for it, has been hidden! > > > > > > (At first I thought it was related to caching the > > > thread-fence property across multilib testing, but I don't > > > think that was correct.) > > > > > Not sure what you mean? We run the tests for a single multilib here > > (mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto) > > so the cached value should always be correct? > > Yeah, part of my RUNTESTFLAGS confusion per above, please > ignore that. > > brgds, H-P >
Re: [PATCH] __atomic_test_and_set: Fall back to library, not non-atomic code
Hi!
On Tue, 26 Sept 2023 at 16:34, Hans-Peter Nilsson wrote:
> Tested cris-elf, native x86_64-pc-linux-gnu and arm-eabi.
>
> For arm-eabi, notably lacking any atomic support for the
> default multilib, with --target_board=arm-sim it regressed
> 29_atomics/atomic_flag/cons/value_init.cc with the expected
> linker failure due to lack of __atomic_test_and_set - which
> is a good thing. With this one, there are 44 unexpected
> FAILs for libstdc+++ at r14-4210-g94982a6b9cf4. This number
> was 206 as late as r14-3470-g721f7e2c4e5e, but mitigated by
> r14-3980-g62b29347c38394, deliberately. To fix the
> regression, I'll do the same and follow up with adding
> dg-require-thread-fence on
> 29_atomics/atomic_flag/cons/value_init.cc (and if approved,
> commit it before this one).
>
> Incidentally, the fortran test-results for arm-eabi are
> riddled with missing-__sync_synchronize linker errors
> causing some 18134 unexpected failures, where cris-elf has
> 121.
>
>
The patch passed almost all our CI configurations, except arm-eabi when
testing with
-mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
where is causes these failures:
FAIL: 29_atomics/atomic_flag/clear/1.cc -std=gnu++17 (test for excess
errors)
UNRESOLVED: 29_atomics/atomic_flag/clear/1.cc -std=gnu++17 compilation
failed to produce executable
FAIL: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++20 (test for
excess errors)
UNRESOLVED: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++20
compilation failed to produce executable
FAIL: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++26 (test for
excess errors)
UNRESOLVED: 29_atomics/atomic_flag/cons/value_init.cc -std=gnu++26
compilation failed to produce executable
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.cc -std=gnu++17 (test
for excess errors)
UNRESOLVED: 29_atomics/atomic_flag/test_and_set/explicit.cc -std=gnu++17
compilation failed to produce executable
FAIL: 29_atomics/atomic_flag/test_and_set/implicit.cc -std=gnu++17 (test
for excess errors)
UNRESOLVED: 29_atomics/atomic_flag/test_and_set/implicit.cc -std=gnu++17
compilation failed to produce executable
The linker error is:
undefined reference to `__atomic_test_and_set'
Maybe we need a new variant of dg-require-thread-fence ?
Thanks,
Christophe
Ok to commit?
>
> -- >8 --
> Make __atomic_test_and_set consistent with other __atomic_ and __sync_
> builtins: call a matching library function instead of emitting
> non-atomic code when the target has no direct insn support.
>
> There's special-case code handling targetm.atomic_test_and_set_trueval
> != 1 trying a modified maybe_emit_sync_lock_test_and_set. Previously,
> if that worked but its matching emit_store_flag_force returned NULL,
> we'd segfault later on. Now that the caller handles NULL, gcc_assert
> here instead.
>
> While the referenced PR:s are ARM-specific, the issue is general.
>
> PR target/107567
> PR target/109166
> * builtins.cc (expand_builtin) :
> Handle failure from expand_builtin_atomic_test_and_set.
> * optabs.cc (expand_atomic_test_and_set): When all attempts fail to
> generate atomic code through target support, return NULL
> instead of emitting non-atomic code. Also, for code handling
> targetm.atomic_test_and_set_trueval != 1, gcc_assert result
> from calling emit_store_flag_force instead of returning NULL.
> ---
> gcc/builtins.cc | 5 -
> gcc/optabs.cc | 22 +++---
> 2 files changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/gcc/builtins.cc b/gcc/builtins.cc
> index 6e4274bb2a4e..40dfd36a3197 100644
> --- a/gcc/builtins.cc
> +++ b/gcc/builtins.cc
> @@ -8387,7 +8387,10 @@ expand_builtin (tree exp, rtx target, rtx
> subtarget, machine_mode mode,
>break;
>
> case BUILT_IN_ATOMIC_TEST_AND_SET:
> - return expand_builtin_atomic_test_and_set (exp, target);
> + target = expand_builtin_atomic_test_and_set (exp, target);
> + if (target)
> + return target;
> + break;
>
> case BUILT_IN_ATOMIC_CLEAR:
>return expand_builtin_atomic_clear (exp);
> diff --git a/gcc/optabs.cc b/gcc/optabs.cc
> index 8b96f23aec05..e1898da22808 100644
> --- a/gcc/optabs.cc
> +++ b/gcc/optabs.cc
> @@ -7080,25 +7080,17 @@ expand_atomic_test_and_set (rtx target, rtx mem,
> enum memmodel model)
>/* Recall that the legacy lock_test_and_set optab was allowed to do
> magic
> things with the value 1. Thus we try again without trueval. */
>if (!ret && targetm.atomic_test_and_set_trueval != 1)
> -ret = maybe_emit_sync_lock_test_and_set (subtarget, mem, const1_rtx,
> model);
> -
> - /* Failing all else, assume a single threaded environment and simply
> - perform the operation. */
> - if (!ret)
> {
> - /* If the result is ignored skip the move to target. */
> - if (subtarget != const0_rtx)
> -emit_move_insn (subtarget, mem);
> + ret =
Re: [PATCH 1/2] testsuite: Add and use thread_fence effective-target
ping?
On Sun, 10 Sept 2023 at 21:31, Christophe Lyon
wrote:
> Some targets like arm-eabi with newlib and default settings rely on
> __sync_synchronize() to ensure synchronization. Newlib does not
> implement it by default, to make users aware they have to take special
> care.
>
> This makes a few tests fail to link.
>
> This patch adds a new thread_fence effective target (similar to the
> corresponding one in libstdc++ testsuite), and uses it in the tests
> that need it, making them UNSUPPORTED instead of FAIL and UNRESOLVED.
>
> 2023-09-10 Christophe Lyon
>
> gcc/
> * doc/sourcebuild.texi (Other attributes): Document thread_fence
> effective-target.
>
> gcc/testsuite/
> * g++.dg/init/array54.C: Require thread_fence.
> * gcc.dg/c2x-nullptr-1.c: Likewise.
> * gcc.dg/pr103721-2.c: Likewise.
> * lib/target-supports.exp (check_effective_target_thread_fence):
> New.
> ---
> gcc/doc/sourcebuild.texi | 4
> gcc/testsuite/g++.dg/init/array54.C | 1 +
> gcc/testsuite/gcc.dg/c2x-nullptr-1.c | 1 +
> gcc/testsuite/gcc.dg/pr103721-2.c | 1 +
> gcc/testsuite/lib/target-supports.exp | 12
> 5 files changed, 19 insertions(+)
>
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 1a78b3c1abb..a5f61c29f3b 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -2860,6 +2860,10 @@ Compiler has been configured to support link-time
> optimization (LTO).
> Compiler and linker support link-time optimization relocatable linking
> with @option{-r} and @option{-flto} options.
>
> +@item thread_fence
> +Target implements @code{__atomic_thread_fence} without relying on
> +non-implemented @code{__sync_synchronize()}.
> +
> @item naked_functions
> Target supports the @code{naked} function attribute.
>
> diff --git a/gcc/testsuite/g++.dg/init/array54.C
> b/gcc/testsuite/g++.dg/init/array54.C
> index f6be350ba72..5241e451d6d 100644
> --- a/gcc/testsuite/g++.dg/init/array54.C
> +++ b/gcc/testsuite/g++.dg/init/array54.C
> @@ -1,5 +1,6 @@
> // PR c++/90947
> // { dg-do run { target c++11 } }
> +// { dg-require-effective-target thread_fence }
>
> #include
>
> diff --git a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
> b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
> index 4e440234d52..97a31c27409 100644
> --- a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
> +++ b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
> @@ -1,5 +1,6 @@
> /* Test valid usage of C23 nullptr. */
> /* { dg-do run } */
> +// { dg-require-effective-target thread_fence }
> /* { dg-options "-std=c2x -pedantic-errors -Wall -Wextra
> -Wno-unused-variable" } */
>
> #include
> diff --git a/gcc/testsuite/gcc.dg/pr103721-2.c
> b/gcc/testsuite/gcc.dg/pr103721-2.c
> index aefa1f0f147..e059b1cfc2d 100644
> --- a/gcc/testsuite/gcc.dg/pr103721-2.c
> +++ b/gcc/testsuite/gcc.dg/pr103721-2.c
> @@ -1,4 +1,5 @@
> // { dg-do run }
> +// { dg-require-effective-target thread_fence }
> // { dg-options "-O2" }
>
> extern void abort ();
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index d353cc0aaf0..7ac9e7530cc 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -9107,6 +9107,18 @@ proc check_effective_target_sync_char_short { } {
> || [check_effective_target_mips_llsc] }}]
> }
>
> +# Return 1 if thread_fence does not rely on __sync_synchronize
> +# library function
> +
> +proc check_effective_target_thread_fence {} {
> +return [check_no_compiler_messages thread_fence executable {
> + int main () {
> + __atomic_thread_fence (__ATOMIC_SEQ_CST);
> + return 0;
> + }
> +} ""]
> +}
> +
> # Return 1 if the target uses a ColdFire FPU.
>
> proc check_effective_target_coldfire_fpu { } {
> --
> 2.34.1
>
>
Re: [PATCH] testsuite: Fix gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c
ping? maybe this counts as obvious? On Thu, 14 Sept 2023 at 11:13, Christophe Lyon wrote: > ping? > > On Fri, 8 Sept 2023 at 10:43, Christophe Lyon > wrote: > >> The test was declaring 'int *carry;' and wrote to '*carry' without >> initializing 'carry' first, leading to an attempt to write at address >> zero, and a crash. >> >> Fix by declaring 'int carry;' and passing '' instead of 'carry' >> as parameter. >> >> 2023-09-08 Christophe Lyon >> >> gcc/testsuite/ >> * gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c: Fix. >> --- >> .../arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c | 34 +-- >> 1 file changed, 17 insertions(+), 17 deletions(-) >> >> diff --git >> a/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c >> b/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c >> index a8c6cce67c8..931c9d2f30b 100644 >> --- a/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c >> +++ b/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c >> @@ -7,7 +7,7 @@ >> >> volatile int32x4_t c1; >> volatile uint32x4_t c2; >> -int *carry; >> +int carry; >> >> int >> main () >> @@ -21,45 +21,45 @@ main () >>uint32x4_t inactive2 = vcreateq_u32 (0, 0); >> >>mve_pred16_t p = 0x; >> - (*carry) = 0x; >> + carry = 0x; >> >>__builtin_arm_set_fpscr_nzcvqc (0); >> - c1 = vadcq (a1, b1, carry); >> + c1 = vadcq (a1, b1, ); >>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >> __builtin_abort (); >> - (*carry) = 0x; >> + carry = 0x; >>__builtin_arm_set_fpscr_nzcvqc (0); >> - c2 = vadcq (a2, b2, carry); >> + c2 = vadcq (a2, b2, ); >>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >> __builtin_abort (); >> - (*carry) = 0x; >> + carry = 0x; >>__builtin_arm_set_fpscr_nzcvqc (0); >> - c1 = vsbcq (a1, b1, carry); >> + c1 = vsbcq (a1, b1, ); >>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >> __builtin_abort (); >> - (*carry) = 0x; >> + carry = 0x; >>__builtin_arm_set_fpscr_nzcvqc (0); >> - c2 = vsbcq (a2, b2, carry); >> + c2 = vsbcq (a2, b2, ); >>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >> __builtin_abort (); >> - (*carry) = 0x; >> + carry = 0x; >>__builtin_arm_set_fpscr_nzcvqc (0); >> - c1 = vadcq_m (inactive1, a1, b1, carry, p); >> + c1 = vadcq_m (inactive1, a1, b1, , p); >>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >> __builtin_abort (); >> - (*carry) = 0x; >> + carry = 0x; >>__builtin_arm_set_fpscr_nzcvqc (0); >> - c2 = vadcq_m (inactive2, a2, b2, carry, p); >> + c2 = vadcq_m (inactive2, a2, b2, , p); >>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >> __builtin_abort (); >> - (*carry) = 0x; >> + carry = 0x; >>__builtin_arm_set_fpscr_nzcvqc (0); >> - c1 = vsbcq_m (inactive1, a1, b1, carry, p); >> + c1 = vsbcq_m (inactive1, a1, b1, , p); >>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >> __builtin_abort (); >> - (*carry) = 0x; >> + carry = 0x; >>__builtin_arm_set_fpscr_nzcvqc (0); >> - c2 = vsbcq_m (inactive2, a2, b2, carry, p); >> + c2 = vsbcq_m (inactive2, a2, b2, , p); >>if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) >> __builtin_abort (); >> >> -- >> 2.34.1 >> >>
Re: [PATCH] testsuite: Fix gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c
ping? On Fri, 8 Sept 2023 at 10:43, Christophe Lyon wrote: > The test was declaring 'int *carry;' and wrote to '*carry' without > initializing 'carry' first, leading to an attempt to write at address > zero, and a crash. > > Fix by declaring 'int carry;' and passing '' instead of 'carry' > as parameter. > > 2023-09-08 Christophe Lyon > > gcc/testsuite/ > * gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c: Fix. > --- > .../arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c | 34 +-- > 1 file changed, 17 insertions(+), 17 deletions(-) > > diff --git > a/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c > b/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c > index a8c6cce67c8..931c9d2f30b 100644 > --- a/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c > +++ b/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c > @@ -7,7 +7,7 @@ > > volatile int32x4_t c1; > volatile uint32x4_t c2; > -int *carry; > +int carry; > > int > main () > @@ -21,45 +21,45 @@ main () >uint32x4_t inactive2 = vcreateq_u32 (0, 0); > >mve_pred16_t p = 0x; > - (*carry) = 0x; > + carry = 0x; > >__builtin_arm_set_fpscr_nzcvqc (0); > - c1 = vadcq (a1, b1, carry); > + c1 = vadcq (a1, b1, ); >if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) > __builtin_abort (); > - (*carry) = 0x; > + carry = 0x; >__builtin_arm_set_fpscr_nzcvqc (0); > - c2 = vadcq (a2, b2, carry); > + c2 = vadcq (a2, b2, ); >if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) > __builtin_abort (); > - (*carry) = 0x; > + carry = 0x; >__builtin_arm_set_fpscr_nzcvqc (0); > - c1 = vsbcq (a1, b1, carry); > + c1 = vsbcq (a1, b1, ); >if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) > __builtin_abort (); > - (*carry) = 0x; > + carry = 0x; >__builtin_arm_set_fpscr_nzcvqc (0); > - c2 = vsbcq (a2, b2, carry); > + c2 = vsbcq (a2, b2, ); >if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) > __builtin_abort (); > - (*carry) = 0x; > + carry = 0x; >__builtin_arm_set_fpscr_nzcvqc (0); > - c1 = vadcq_m (inactive1, a1, b1, carry, p); > + c1 = vadcq_m (inactive1, a1, b1, , p); >if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) > __builtin_abort (); > - (*carry) = 0x; > + carry = 0x; >__builtin_arm_set_fpscr_nzcvqc (0); > - c2 = vadcq_m (inactive2, a2, b2, carry, p); > + c2 = vadcq_m (inactive2, a2, b2, , p); >if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) > __builtin_abort (); > - (*carry) = 0x; > + carry = 0x; >__builtin_arm_set_fpscr_nzcvqc (0); > - c1 = vsbcq_m (inactive1, a1, b1, carry, p); > + c1 = vsbcq_m (inactive1, a1, b1, , p); >if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) > __builtin_abort (); > - (*carry) = 0x; > + carry = 0x; >__builtin_arm_set_fpscr_nzcvqc (0); > - c2 = vsbcq_m (inactive2, a2, b2, carry, p); > + c2 = vsbcq_m (inactive2, a2, b2, , p); >if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) > __builtin_abort (); > > -- > 2.34.1 > >
Re: [PATCH] libstdc++: Remove some more unconditional uses of atomics
On Thu, 14 Sept 2023 at 11:06, Jonathan Wakely wrote:
> On Thu, 14 Sept 2023 at 09:41, Christophe Lyon
> wrote:
> >
> >
> >
> > On Thu, 14 Sept 2023 at 10:17, Jonathan Wakely
> wrote:
> >>
> >> On Thu, 14 Sept 2023 at 08:44, Christophe Lyon
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> >
> >> > On Wed, 13 Sept 2023 at 14:32, Jonathan Wakely
> wrote:
> >> >>
> >> >> Tested x86_64-linux and aarch64-linux. I intend to push this to
> trunk.
> >> >>
> >> >> -- >8 --
> >> >>
> >> >> These atomics cause linker errors on arm4t where __sync_synchronize
> is
> >> >> not defined. For single-threaded targets we don't need the atomics.
> >> >>
> >> >
> >> > I ran the tests on arm-eabi default config (so, armv4t) with this
> patch, and here is the list of remaining UNRESOLVED tests:
> >> > 29_atomics/atomic/compare_exchange_padding.cc
> >> > 29_atomics/atomic/cons/value_init.cc
> >> > 29_atomics/atomic_float/value_init.cc
> >> > 29_atomics/atomic_integral/cons/value_init.cc
> >> > 29_atomics/atomic_ref/compare_exchange_padding.cc
> >> > 29_atomics/atomic_ref/generic.cc
> >> > 29_atomics/atomic_ref/integral.cc
> >> > 29_atomics/atomic_ref/pointer.cc
> >> > experimental/polymorphic_allocator/construct_pair.cc
> >> >
> >> > all of them are due to undefined reference to __sync_synchronize
> >> > (some also reference __atomic_compare_exchange_4, etc...)
> >> >
> >> >
> >> > IIUC, this should not be the case for
> experimental/polymorphic_allocator/construct_pair.cc ?
> >> > The reference for __sync_synchronize is near the beginning of
> test0[123]
> >> > from a call to __atomic_load_n line 835 of atomic_base.h
> >> > not sure where it comes from, the .loc directive indicates line 28 of
> the testcase which is the opening brace
> >>
> >> Doh, I removed the atomics from but this is
> >> , which has a separate implementation.
> >>
> >> I'll make a change to as well, thanks
> >> for catching my silly mistake.
> >>
> >
> > You're welcome.
> > So I'll shrink my patch and add dg-require-thread-fence only to the few
> 29_atomics tests listed above.
>
> Great, thanks. That's approved for trunk then.
>
> N.B. if you'd prefer to add { dg-require-effective-target thread_fence
> } instead of { dg-require-thread-fence "" } then that's fine, just
> note that the effective target uses an underscore not a hyphen. The
> dg-require-thread-fence proc just uses the proc that checks the
> thread_fence effective target, so both forms do the same thing.
>
> Ha! Just sent v2, I kept dg-require-thread-fence, because it was used
elsewhere in the libstsdc++ testsuite.
Thanks,
Christophe
[PATCH v2 2/2] libstdc++: Add dg-require-thread-fence in several tests
Some targets like arm-eabi with newlib and default settings rely on
__sync_synchronize() to ensure synchronization. Newlib does not
implement it by default, to make users aware they have to take special
care.
This makes a few tests fail to link.
This patch requires the missing thread-fence effective target in the
tests that need it, making them UNSUPPORTED instead of FAIL and
UNRESOLVED.
2023-09-10 Christophe Lyon
libstdc++-v3/
* testsuite/29_atomics/atomic/compare_exchange_padding.cc: Likewise.
* testsuite/29_atomics/atomic/cons/value_init.cc: Likewise.
* testsuite/29_atomics/atomic_float/value_init.cc: Likewise.
* testsuite/29_atomics/atomic_integral/cons/value_init.cc: Likewise.
* testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc: Likewise.
* testsuite/29_atomics/atomic_ref/generic.cc: Likewise.
* testsuite/29_atomics/atomic_ref/integral.cc: Likewise.
* testsuite/29_atomics/atomic_ref/pointer.cc: Likewise.
---
.../testsuite/29_atomics/atomic/compare_exchange_padding.cc | 1 +
libstdc++-v3/testsuite/29_atomics/atomic/cons/value_init.cc | 1 +
libstdc++-v3/testsuite/29_atomics/atomic_float/value_init.cc | 1 +
.../testsuite/29_atomics/atomic_integral/cons/value_init.cc | 1 +
.../testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc | 1 +
libstdc++-v3/testsuite/29_atomics/atomic_ref/generic.cc | 1 +
libstdc++-v3/testsuite/29_atomics/atomic_ref/integral.cc | 1 +
libstdc++-v3/testsuite/29_atomics/atomic_ref/pointer.cc | 1 +
8 files changed, 8 insertions(+)
diff --git
a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
index c4ab876db2a..2e7ff0307bc 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
@@ -1,5 +1,6 @@
// { dg-options "-std=gnu++20" }
// { dg-do run { target c++20 } }
+// { dg-require-thread-fence "" }
// { dg-add-options libatomic }
#include
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/cons/value_init.cc
b/libstdc++-v3/testsuite/29_atomics/atomic/cons/value_init.cc
index 47d5a5d5b28..b8019486ccf 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic/cons/value_init.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/cons/value_init.cc
@@ -17,6 +17,7 @@
// { dg-options "-std=gnu++2a" }
// { dg-do run { target c++2a } }
+// { dg-require-thread-fence "" }
#include
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_float/value_init.cc
b/libstdc++-v3/testsuite/29_atomics/atomic_float/value_init.cc
index 1cd1efb5422..6e89f2fc2a8 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_float/value_init.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_float/value_init.cc
@@ -17,6 +17,7 @@
// { dg-options "-std=gnu++2a" }
// { dg-do run { target c++2a } }
+// { dg-require-thread-fence "" }
// { dg-add-options libatomic }
#include
diff --git
a/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/value_init.cc
b/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/value_init.cc
index 96615a7d09f..2f6a48d36d8 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/value_init.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_integral/cons/value_init.cc
@@ -17,6 +17,7 @@
// { dg-options "-std=gnu++2a" }
// { dg-do run { target c++2a } }
+// { dg-require-thread-fence "" }
#include
#include
diff --git
a/libstdc++-v3/testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc
b/libstdc++-v3/testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc
index 0dab8a23e10..8469ebf8a14 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc
@@ -1,5 +1,6 @@
// { dg-options "-std=gnu++20" }
// { dg-do run { target c++20 } }
+// { dg-require-thread-fence "" }
// { dg-add-options libatomic }
#include
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_ref/generic.cc
b/libstdc++-v3/testsuite/29_atomics/atomic_ref/generic.cc
index 14f417d1739..adae07f8754 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_ref/generic.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_ref/generic.cc
@@ -17,6 +17,7 @@
// { dg-options "-std=gnu++2a" }
// { dg-do run { target c++2a } }
+// { dg-require-thread-fence "" }
// { dg-add-options libatomic }
#include
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_ref/integral.cc
b/libstdc++-v3/testsuite/29_atomics/atomic_ref/integral.cc
index e03ca921eb9..a98adb7fbba 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_ref/integral.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_ref/integral.cc
@@ -17,6 +17,7 @@
// { dg-optio
Re: [PATCH] libstdc++: Remove some more unconditional uses of atomics
On Thu, 14 Sept 2023 at 10:17, Jonathan Wakely wrote: > On Thu, 14 Sept 2023 at 08:44, Christophe Lyon > wrote: > > > > Hi, > > > > > > On Wed, 13 Sept 2023 at 14:32, Jonathan Wakely > wrote: > >> > >> Tested x86_64-linux and aarch64-linux. I intend to push this to trunk. > >> > >> -- >8 -- > >> > >> These atomics cause linker errors on arm4t where __sync_synchronize is > >> not defined. For single-threaded targets we don't need the atomics. > >> > > > > I ran the tests on arm-eabi default config (so, armv4t) with this patch, > and here is the list of remaining UNRESOLVED tests: > > 29_atomics/atomic/compare_exchange_padding.cc > > 29_atomics/atomic/cons/value_init.cc > > 29_atomics/atomic_float/value_init.cc > > 29_atomics/atomic_integral/cons/value_init.cc > > 29_atomics/atomic_ref/compare_exchange_padding.cc > > 29_atomics/atomic_ref/generic.cc > > 29_atomics/atomic_ref/integral.cc > > 29_atomics/atomic_ref/pointer.cc > > experimental/polymorphic_allocator/construct_pair.cc > > > > all of them are due to undefined reference to __sync_synchronize > > (some also reference __atomic_compare_exchange_4, etc...) > > > > > > IIUC, this should not be the case for > experimental/polymorphic_allocator/construct_pair.cc ? > > The reference for __sync_synchronize is near the beginning of test0[123] > > from a call to __atomic_load_n line 835 of atomic_base.h > > not sure where it comes from, the .loc directive indicates line 28 of > the testcase which is the opening brace > > Doh, I removed the atomics from but this is > , which has a separate implementation. > > I'll make a change to as well, thanks > for catching my silly mistake. > > You're welcome. So I'll shrink my patch and add dg-require-thread-fence only to the few 29_atomics tests listed above. Christophe
Re: [PATCH] libstdc++: Remove some more unconditional uses of atomics
Hi,
On Wed, 13 Sept 2023 at 14:32, Jonathan Wakely wrote:
> Tested x86_64-linux and aarch64-linux. I intend to push this to trunk.
>
> -- >8 --
>
> These atomics cause linker errors on arm4t where __sync_synchronize is
> not defined. For single-threaded targets we don't need the atomics.
>
>
I ran the tests on arm-eabi default config (so, armv4t) with this patch,
and here is the list of remaining UNRESOLVED tests:
29_atomics/atomic/compare_exchange_padding.cc
29_atomics/atomic/cons/value_init.cc
29_atomics/atomic_float/value_init.cc
29_atomics/atomic_integral/cons/value_init.cc
29_atomics/atomic_ref/compare_exchange_padding.cc
29_atomics/atomic_ref/generic.cc
29_atomics/atomic_ref/integral.cc
29_atomics/atomic_ref/pointer.cc
experimental/polymorphic_allocator/construct_pair.cc
all of them are due to undefined reference to __sync_synchronize
(some also reference __atomic_compare_exchange_4, etc...)
IIUC, this should not be the case for
experimental/polymorphic_allocator/construct_pair.cc ?
The reference for __sync_synchronize is near the beginning of test0[123]
from a call to __atomic_load_n line 835 of atomic_base.h
not sure where it comes from, the .loc directive indicates line 28 of the
testcase which is the opening brace
HTH
Christophe
libstdc++-v3/ChangeLog:
>
> * include/experimental/io_context (io_context)
> [!_GLIBCXX_HAS_GTHREADS]:
> Use a plain integer for _M_work_count for single-threaded
> targets.
> * src/c++17/memory_resource.cc [!_GLIBCXX_HAS_GTHREADS]
> (atomic_mem_res): Use unsynchronized type for single-threaded
> targets.
> ---
> libstdc++-v3/include/experimental/io_context | 4 ++
> libstdc++-v3/src/c++17/memory_resource.cc| 49 ++--
> 2 files changed, 29 insertions(+), 24 deletions(-)
>
> diff --git a/libstdc++-v3/include/experimental/io_context
> b/libstdc++-v3/include/experimental/io_context
> index c59f8c8e73b..c878d5a7025 100644
> --- a/libstdc++-v3/include/experimental/io_context
> +++ b/libstdc++-v3/include/experimental/io_context
> @@ -562,7 +562,11 @@ inline namespace v1
> }
>};
>
> +#ifdef _GLIBCXX_HAS_GTHREADS
> atomic _M_work_count;
> +#else
> +count_type _M_work_count;
> +#endif
> mutable execution_context::mutex_type _M_mtx;
> queue>_M_op;
> bool _M_stopped = false;
> diff --git a/libstdc++-v3/src/c++17/memory_resource.cc
> b/libstdc++-v3/src/c++17/memory_resource.cc
> index c0c7cf0cf83..63856eadaf5 100644
> --- a/libstdc++-v3/src/c++17/memory_resource.cc
> +++ b/libstdc++-v3/src/c++17/memory_resource.cc
> @@ -27,9 +27,9 @@
> #include
> #include // has_single_bit, bit_ceil,
> bit_width
> #include
> +#include // std::__exchange
> #if ATOMIC_POINTER_LOCK_FREE != 2
> # include// std::mutex, std::lock_guard
> -# include // std::__exchange
> #endif
>
> #if __has_cpp_attribute(clang::require_constant_initialization)
> @@ -94,10 +94,31 @@ namespace pmr
>
> __constinit constant_init newdel_res{};
> __constinit constant_init null_res{};
> -#if ATOMIC_POINTER_LOCK_FREE == 2
> +
> +#ifndef _GLIBCXX_HAS_GTHREADS
> +# define _GLIBCXX_ATOMIC_MEM_RES_CAN_BE_CONSTANT_INITIALIZED
> +// Single-threaded, no need for synchronization
> +struct atomic_mem_res
> +{
> + constexpr
> + atomic_mem_res(memory_resource* r) : val(r) { }
> +
> + memory_resource* val;
> +
> + memory_resource* load(std::memory_order) const
> + {
> + return val;
> + }
> +
> + memory_resource* exchange(memory_resource* r, std::memory_order)
> + {
> + return std::__exchange(val, r);
> + }
> +};
> +#elif ATOMIC_POINTER_LOCK_FREE == 2
> using atomic_mem_res = atomic;
> # define _GLIBCXX_ATOMIC_MEM_RES_CAN_BE_CONSTANT_INITIALIZED
> -#elif defined(_GLIBCXX_HAS_GTHREADS)
> +#else
> // Can't use pointer-width atomics, define a type using a mutex
> instead:
> struct atomic_mem_res
> {
> @@ -123,27 +144,7 @@ namespace pmr
> return std::__exchange(val, r);
>}
> };
> -#else
> -# define _GLIBCXX_ATOMIC_MEM_RES_CAN_BE_CONSTANT_INITIALIZED
> -// Single-threaded, no need for synchronization
> -struct atomic_mem_res
> -{
> - constexpr
> - atomic_mem_res(memory_resource* r) : val(r) { }
> -
> - memory_resource* val;
> -
> - memory_resource* load(std::memory_order) const
> - {
> - return val;
> - }
> -
> - memory_resource* exchange(memory_resource* r, std::memory_order)
> - {
> - return std::__exchange(val, r);
> - }
> -};
> -#endif // ATOMIC_POINTER_LOCK_FREE == 2
> +#endif
>
> #ifdef _GLIBCXX_ATOMIC_MEM_RES_CAN_BE_CONSTANT_INITIALIZED
> __constinit constant_init
> default_res{_res.obj};
> --
> 2.41.0
>
>
Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests
On Tue, 12 Sept 2023 at 11:07, Jonathan Wakely wrote: > On Tue, 12 Sept 2023 at 08:59, Christophe Lyon > wrote: > > > > > > > > On Mon, 11 Sept 2023 at 18:11, Jonathan Wakely > wrote: > >> > >> On Mon, 11 Sept 2023 at 16:40, Christophe Lyon > >> wrote: > >> > > >> > > >> > > >> > On Mon, 11 Sept 2023 at 17:22, Jonathan Wakely > wrote: > >> >> > >> >> On Mon, 11 Sept 2023 at 14:57, Christophe Lyon > >> >> wrote: > >> >> > > >> >> > > >> >> > > >> >> > On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely > wrote: > >> >> >> > >> >> >> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon > >> >> >> wrote: > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely < > jwak...@redhat.com> wrote: > >> >> >> >> > >> >> >> >> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon > >> >> >> >> wrote: > >> >> >> >> > > >> >> >> >> > Some targets like arm-eabi with newlib and default settings > rely on > >> >> >> >> > __sync_synchronize() to ensure synchronization. Newlib does > not > >> >> >> >> > implement it by default, to make users aware they have to > take special > >> >> >> >> > care. > >> >> >> >> > > >> >> >> >> > This makes a few tests fail to link. > >> >> >> >> > >> >> >> >> Does this mean those features are unusable on the target, or > just that > >> >> >> >> users need to provide their own __sync_synchronize to use them? > >> >> >> > > >> >> >> > > >> >> >> > IIUC the user is expected to provide them. > >> >> >> > Looks like we discussed this in the past :-) > >> >> >> > In > https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01632.html, > >> >> >> > see the pointer to Ramana's comment: > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html > >> >> >> > >> >> >> Oh yes, thanks for the reminder! > >> >> >> > >> >> >> > > >> >> >> > The default arch for arm-eabi is armv4t which is very old. > >> >> >> > When running the testsuite with something more recent (either > as default by configuring GCC --with-arch=XXX or by forcing -march/-mcpu > via dejagnu's target-board), the compiler generates barrier instructions > and there are no such errors. > >> >> >> > >> >> >> Ah yes, that's fine then. > >> >> >> > >> >> >> > For instance, here is a log with the defaults: > >> >> >> > > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-arm_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-arm_eabi > >> >> >> > and a log when we target cortex-m0 which is still a very small > cpu but has barriers: > >> >> >> > > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi > >> >> >> > > >> >> >> > I somehow wanted to get rid of such errors with the default > configuration > >> >> >> > >> >> >> Yep, that makes sense, and we'll still be testing them for newer > >> >> >> arches on the target, so it's not completely disabling those > parts of > >> >> >> the testsuite. > >> >> >> > >> >> >> But I'm still curious why some of those tests need this change. I > >> >> >> think the ones I noted below are probably failing for some other > >> >> >> reasons. > >> >> >> > >> >> > Just looked at 23_containers/span/back_assert_neg.cc, the linker > says it needs > >> >> > arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(debug.o) to resolve > >> >> > ./back_assert_neg-back_assert_neg.o > (std
Re: [PATCH] Tweak language choice in config-list.mk
Hi!
On Thu, 7 Sept 2023 at 11:30, Richard Sandiford via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> When I tried to use config-list.mk, the build for every triple except
> the build machine's failed for m2. This is because, unlike other
> languages, m2 builds target objects during all-gcc. The build will
> therefore fail unless you have access to an appropriate binutils
> (or an equivalent). That's quite a big ask for over 100 targets. :)
>
> This patch therefore makes m2 an optional inclusion.
>
> Doing that wasn't entirely straightforward though. The current
> configure line includes "--enable-languages=all,...", which means
> that the "..." can only force languages to be added that otherwise
> wouldn't have been. (I.e. the only effect of the "..." is to
> override configure autodetection.)
>
> The choice of all,ada and:
>
> # Make sure you have a recent enough gcc (with ada support) in your path
> so
> # that --enable-werror-always will work.
>
> make it clear that lack of GNAT should be a build failure rather than
> silently ignored. This predates the D frontend, which requires GDC
> in the same way that Ada requires GNAT. I don't know of a reason
> why D should be treated differently.
>
> The patch therefore expands the "all" into a specific list of
> languages.
>
> That in turn meant that Fortran had to be handled specially,
> since bpf and mmix don't support Fortran.
>
> Perhaps there's an argument that m2 shouldn't build target objects
> during all-gcc, but (a) it works for practical usage and (b) the
> patch is an easy workaround. I'd be happy for the patch to be
> reverted if the build system changes.
>
> OK to install?
>
> Richard
>
>
> gcc/
> * contrib/config-list.mk (OPT_IN_LANGUAGES): New variable.
> ($(LIST)): Replace --enable-languages=all with a specifc list.
> Disable fortran on bpf and mmix. Enable the languages in
> OPT_IN_LANGUAGES.
> ---
> contrib/config-list.mk | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> index e570b13c71b..50ecb014bc0 100644
> --- a/contrib/config-list.mk
> +++ b/contrib/config-list.mk
> @@ -12,6 +12,11 @@ TEST=all-gcc
> # supply an absolute path.
> GCC_SRC_DIR=../../gcc
>
> +# Define this to ,m2 if you want to build Modula-2. Modula-2 builds
> target
> +# objects during all-gcc, so it can only be included if you've installed
> +# binutils (or an equivalent) for each target.
> +OPT_IN_LANGUAGES=
> +
> # Use -j / -l make arguments and nice to assure a smooth
> resource-efficient
> # load on the build machine, e.g. for 24 cores:
> # svn co svn://gcc.gnu.org/svn/gcc/branches/foo-branch gcc
> @@ -126,17 +131,23 @@ $(LIST): make-log-dir
> TGT=`echo $@ | awk 'BEGIN { FS = "OPT" }; { print $$1 }'`
> &&\
> TGT=`$(GCC_SRC_DIR)/config.sub $$TGT` &&
> \
> case $$TGT in
> \
> - *-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*
> | bpf-*-*)\
> + bpf-*-*)
> \
> ADDITIONAL_LANGUAGES="";
> \
> ;;
> \
> - *)
> \
> + *-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*
> | bpf-*-*)\
>
Am I misreading, or are you matching bpf here and above? From your commit
message, I think bpf should either be only above (and define
ADDITIONAL_LANGUAGES to "") and along with mmix (if it supports go) ?
> + ADDITIONAL_LANGUAGES=",fortran";
> \
> + ;;
> \
> + mmix-*-*)
> \
> ADDITIONAL_LANGUAGES=",go";
> \
> ;;
> \
> + *)
> \
> + ADDITIONAL_LANGUAGES=",fortran,go";
> \
> + ;;
> \
> esac &&
> \
> $(GCC_SRC_DIR)/configure
> \
> --target=$(subst SCRIPTS,`pwd`/../scripts/,$(subst
> OPT,$(empty) -,$@)) \
> --enable-werror-always ${host_options}
> \
> - --enable-languages=all,ada$$ADDITIONAL_LANGUAGES;
> \
> +
>
> --enable-languages=c,ada,c++,d,lto,objc,obj-c++,rust$$ADDITIONAL_LANGUAGES$(OPT_IN_LANGUAGES);
> \
> ) > log/$@-config.out 2>&1
>
> $(LOGFILES) : log/%-make.out : %
> --
> 2.25.1
>
>
Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests
On Mon, 11 Sept 2023 at 18:11, Jonathan Wakely wrote: > On Mon, 11 Sept 2023 at 16:40, Christophe Lyon > wrote: > > > > > > > > On Mon, 11 Sept 2023 at 17:22, Jonathan Wakely > wrote: > >> > >> On Mon, 11 Sept 2023 at 14:57, Christophe Lyon > >> wrote: > >> > > >> > > >> > > >> > On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely > wrote: > >> >> > >> >> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon > >> >> wrote: > >> >> > > >> >> > > >> >> > > >> >> > On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely > wrote: > >> >> >> > >> >> >> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon > >> >> >> wrote: > >> >> >> > > >> >> >> > Some targets like arm-eabi with newlib and default settings > rely on > >> >> >> > __sync_synchronize() to ensure synchronization. Newlib does not > >> >> >> > implement it by default, to make users aware they have to take > special > >> >> >> > care. > >> >> >> > > >> >> >> > This makes a few tests fail to link. > >> >> >> > >> >> >> Does this mean those features are unusable on the target, or just > that > >> >> >> users need to provide their own __sync_synchronize to use them? > >> >> > > >> >> > > >> >> > IIUC the user is expected to provide them. > >> >> > Looks like we discussed this in the past :-) > >> >> > In > https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01632.html, > >> >> > see the pointer to Ramana's comment: > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html > >> >> > >> >> Oh yes, thanks for the reminder! > >> >> > >> >> > > >> >> > The default arch for arm-eabi is armv4t which is very old. > >> >> > When running the testsuite with something more recent (either as > default by configuring GCC --with-arch=XXX or by forcing -march/-mcpu via > dejagnu's target-board), the compiler generates barrier instructions and > there are no such errors. > >> >> > >> >> Ah yes, that's fine then. > >> >> > >> >> > For instance, here is a log with the defaults: > >> >> > > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-arm_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-arm_eabi > >> >> > and a log when we target cortex-m0 which is still a very small cpu > but has barriers: > >> >> > > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi > >> >> > > >> >> > I somehow wanted to get rid of such errors with the default > configuration > >> >> > >> >> Yep, that makes sense, and we'll still be testing them for newer > >> >> arches on the target, so it's not completely disabling those parts of > >> >> the testsuite. > >> >> > >> >> But I'm still curious why some of those tests need this change. I > >> >> think the ones I noted below are probably failing for some other > >> >> reasons. > >> >> > >> > Just looked at 23_containers/span/back_assert_neg.cc, the linker > says it needs > >> > arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(debug.o) to resolve > >> > ./back_assert_neg-back_assert_neg.o (std::__glibcxx_assert_fail(char > const*, int, char const*, char const*)) > >> > and indeed debug.o has a reference to __sync_synchronize > >> > >> Aha, that's just because I put __glibcxx_assert_fail in debug.o, but > >> there are no dependencies on anything else in that file, including the > >> _M_detach member function that uses atomics. > > > > indeed > > > > > >> > >> This would also be solved by -Wl,--gc-sections :-) > > > > :-) > > > >> > >> I think it would be better to move __glibcxx_assert_fail to a new > >> file, so that it doesn't make every assertion unnecessarily depend on > >> __sync_synchronize. I'll do that now. > > > > Sounds like a good ide
Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests
On Mon, 11 Sept 2023 at 17:22, Jonathan Wakely wrote: > On Mon, 11 Sept 2023 at 14:57, Christophe Lyon > wrote: > > > > > > > > On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely > wrote: > >> > >> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon > >> wrote: > >> > > >> > > >> > > >> > On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely > wrote: > >> >> > >> >> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon > >> >> wrote: > >> >> > > >> >> > Some targets like arm-eabi with newlib and default settings rely on > >> >> > __sync_synchronize() to ensure synchronization. Newlib does not > >> >> > implement it by default, to make users aware they have to take > special > >> >> > care. > >> >> > > >> >> > This makes a few tests fail to link. > >> >> > >> >> Does this mean those features are unusable on the target, or just > that > >> >> users need to provide their own __sync_synchronize to use them? > >> > > >> > > >> > IIUC the user is expected to provide them. > >> > Looks like we discussed this in the past :-) > >> > In https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01632.html, > >> > see the pointer to Ramana's comment: > https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html > >> > >> Oh yes, thanks for the reminder! > >> > >> > > >> > The default arch for arm-eabi is armv4t which is very old. > >> > When running the testsuite with something more recent (either as > default by configuring GCC --with-arch=XXX or by forcing -march/-mcpu via > dejagnu's target-board), the compiler generates barrier instructions and > there are no such errors. > >> > >> Ah yes, that's fine then. > >> > >> > For instance, here is a log with the defaults: > >> > > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-arm_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-arm_eabi > >> > and a log when we target cortex-m0 which is still a very small cpu > but has barriers: > >> > > https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi > >> > > >> > I somehow wanted to get rid of such errors with the default > configuration > >> > >> Yep, that makes sense, and we'll still be testing them for newer > >> arches on the target, so it's not completely disabling those parts of > >> the testsuite. > >> > >> But I'm still curious why some of those tests need this change. I > >> think the ones I noted below are probably failing for some other > >> reasons. > >> > > Just looked at 23_containers/span/back_assert_neg.cc, the linker says > it needs > > arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(debug.o) to resolve > > ./back_assert_neg-back_assert_neg.o (std::__glibcxx_assert_fail(char > const*, int, char const*, char const*)) > > and indeed debug.o has a reference to __sync_synchronize > > Aha, that's just because I put __glibcxx_assert_fail in debug.o, but > there are no dependencies on anything else in that file, including the > _M_detach member function that uses atomics. > indeed > This would also be solved by -Wl,--gc-sections :-) > :-) > I think it would be better to move __glibcxx_assert_fail to a new > file, so that it doesn't make every assertion unnecessarily depend on > __sync_synchronize. I'll do that now. > Sounds like a good idea, thanks. > We could also make the atomics in debug.o conditional, so that debug > mode doesn't depend on __sync_synchronize for single-threaded targets. > Does the arm4t arch have pthreads support in newlib? I didn't bother > No ( grep _GLIBCXX_HAS_GTHREADS $objdir/arm-eabi/libstdc++-v3/include/arm-eabi/bits/c++config returns: /* #undef _GLIBCXX_HAS_GTHREADS */ making the use of atomics conditional, because performance is not > really a priority for debug mode bookkeeping. But the problem here > isn't just a slight performance overhead of atomics, it's that they > aren't even supported for arm4t. > OK thanks. So finally, this uncovered at least a "bug" that __glibcxx_assert_fail should be in a dedicated object file :-) I'll revisit my patch once you have moved __glibcxx_assert_fail Thanks, Christophe
Re: [PATCH] analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]
Hi!
On Wed, 6 Sept 2023 at 22:22, David Malcolm via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Wed, 2023-09-06 at 15:50 +0200, Benjamin Priour wrote:
> > Hi David,
> > Thanks for the review.
> >
> >
> >
> > On Tue, Sep 5, 2023 at 1:53 PM David Malcolm
> > wrote:
> >
> > > On Mon, 2023-09-04 at 20:00 +0200, priour...@gmail.com wrote:
> > >
> > >
> > [...snip...]
> >
> >
> > > All of these "new" tests (apart from the "-noexcept" ones) look
> > > like
> > > they're meant to be existing tests that were moved, but where the
> > > copy
> > > of the test in gcc.dg/analyzer didn't get deleted, so they show up
> > > as a
> > > duplicate. See the details below.
> > >
> >
> > > > * c-c++-common/analyzer/file-pr58237-noexcept.c: New test.
> > >
> > > When duplicating a test like this, the test isn't entirely "new",
> > > so
> > > please say something like this in the ChangeLog entry, to make it
> > > clear
> > > where it came from:
> > >
> > >
> > I actually wasn't sure about these -noexcept tests. They were part
> > of gcc.dg/analyzer, thus only gcc was running them. Exceptions
> > were not disabled *explicitly*, but since it was C, they weren't
> > enabled
> > either.
> >
> > Therefore, the -noexcept tests are basically a copy, but with an
> > explicit
> > -fno-exceptions specification.
> > When I duplicated them in that way I was thinking about making it
> > clear
> > that these tests fail in C++ with exceptions enabled, so that we
> > would
> > already
> > have easy-to-spot failing tests to challenge a future exception
> > support.
>
> Ah, OK; let's go with your approach.
>
> >
> > Though perhaps *not* duplicating the tests but rather simply specify
> > -fno-exceptions,
> > with a comment "Fails with exceptions" may be better.
>
> [...snip...]
>
> > > > @@ -45,7 +45,7 @@ void test(int n)
> > > >struct iter *it = iter_new (0, n, 1);
> > > >while (!iter_done_p (it))
> > > > {
> > > > - __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
> > > > "true" {
> > > xfail *-*-* } } */
> > > > + __analyzer_eval (it->val < n); /* { dg-warning "TRUE"
> > > > "true" } */
> > > >/* { dg-bogus "UNKNOWN" "unknown" { xfail *-*-* } .-1 } */
> > > >/* TODO(xfail^^^): ideally we ought to figure out i > 0
> > > > after 1st
> > > iteration. */
> > > >
> > >
> > > Presumably due to the change to
> > > region_model::add_constraints_from_binop, right?
> > > Looking at that dg-bogus "UNKNOWN", do we still get an UNKNOWN
> > > here, or
> > > can that line be removed?
> > > If so, then the 3rd comment can presumably become:
> > >
> > >
> > The bogus here still make sense - without it there is an excess error
> > -.
> > I had checked for it because I too thought it could be removed.
> > If I remember it correctly, we get UNKNOWN during the widening pass.
>
> (nods)
>
> >
> >
> > > >/* TODO: ideally we ought to figure out i > 0 after 1st
> > > iteration. */
> > >
> > > [...snip...]
> > >
> > >
> > >
> > [...snip...]
> >
> > Thanks for spotting the files I forgot to remove from gcc.dg.
> > Sorry about them, I had messed up my test folder when checking for
> > arm-eabi,
> > and I apparently missed some duplicates when retrieving my save.
> >
> > As for the files the likes of inlining-*.c, i.e. noted as Moved
> > to/...here.
> > at the end of the ChangeLog, some tests checking for multiline
> > outputs
> > are so heavily rewritten than git marks them as Removed/New test
> > instead of moved. I've manually edited that, but perhaps I shouldn't
> > ?
> >
> > I have successfully regstrapped the improvements you suggested.
>
> Thanks. Did you want me to doublecheck the updated patch? Otherwise
> feel free to push it to trunk.
>
> Was this patch committed as r14-3823-g50b5199cff6908?
Our CI noticed regression after that revision, on arm-eabi.
I looked at the logs for out-of-bounds-diagram-11.c, where we have:
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c expected multiline
pattern lines 46-61
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c 2 blank line(s) in
output
FAIL: c-c++-common/analyzer/out-of-bounds-diagram-11.c (test for excess
errors)
After visual inspection, I noticed that we emit:
write of '(int32_t) 42'
but expect:
write of '(int) 42'
(that is, we emit 'int32_t' and expect 'int')
I didn't check all the regressions, but does that ring a bell?
Thanks,
Christophe
> > Part 3 of this serie of patches I hope will be regstrapped for
> > Friday.
>
> Thanks; I'm impressed at how much progress you've made on this problem.
>
> Dave
>
>
Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests
On Mon, 11 Sept 2023 at 15:12, Jonathan Wakely wrote:
> On Mon, 11 Sept 2023 at 13:36, Christophe Lyon
> wrote:
> >
> >
> >
> > On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely
> wrote:
> >>
> >> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon
> >> wrote:
> >> >
> >> > Some targets like arm-eabi with newlib and default settings rely on
> >> > __sync_synchronize() to ensure synchronization. Newlib does not
> >> > implement it by default, to make users aware they have to take special
> >> > care.
> >> >
> >> > This makes a few tests fail to link.
> >>
> >> Does this mean those features are unusable on the target, or just that
> >> users need to provide their own __sync_synchronize to use them?
> >
> >
> > IIUC the user is expected to provide them.
> > Looks like we discussed this in the past :-)
> > In https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01632.html,
> > see the pointer to Ramana's comment:
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html
>
> Oh yes, thanks for the reminder!
>
> >
> > The default arch for arm-eabi is armv4t which is very old.
> > When running the testsuite with something more recent (either as default
> by configuring GCC --with-arch=XXX or by forcing -march/-mcpu via dejagnu's
> target-board), the compiler generates barrier instructions and there are no
> such errors.
>
> Ah yes, that's fine then.
>
> > For instance, here is a log with the defaults:
> >
> https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-arm_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-arm_eabi
> > and a log when we target cortex-m0 which is still a very small cpu but
> has barriers:
> >
> https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi
> >
> > I somehow wanted to get rid of such errors with the default
> configuration
>
> Yep, that makes sense, and we'll still be testing them for newer
> arches on the target, so it's not completely disabling those parts of
> the testsuite.
>
> But I'm still curious why some of those tests need this change. I
> think the ones I noted below are probably failing for some other
> reasons.
>
> Just looked at 23_containers/span/back_assert_neg.cc, the linker says it
needs
arm-eabi/libstdc++-v3/src/.libs/libstdc++.a(debug.o) to resolve
./back_assert_neg-back_assert_neg.o (std::__glibcxx_assert_fail(char
const*, int, char const*, char const*))
and indeed debug.o has a reference to __sync_synchronize
>
> >>
> >> >
> >> > This patch requires the missing thread-fence effective target in the
> >> > tests that need it, making them UNSUPPORTED instead of FAIL and
> >> > UNRESOLVED.
> >>
> >> Some of the modified tests should not be using
> >> __gnu_debug::_Safe_sequence_base::_M_detach_all(), because they don't
> >> use the Debug Mode. I don't know where those linker errors come from.
> >> For example, the 23_containers/span/*assert_neg.cc and
> >> 26_numerics/valarray/* tests shouldn't use debug iterators or atomics.
> >> Neither should 25_algorithms/sample/2.cc nor
> >> 26_numerics/bit/bit.pow.two/bit_ceil_neg.cc
> >
> >
> > Ouch! I had the feeling this patch wouldn't count as obvious :-)
> >
> > I confess I didn't analyze the linker map for every single test updated
> by this patch
> > I can have a deeper look based on your comment below, excluding those
> that look "OK"
> >
> >>
> >> The last three in the patch shouldn't use it either:
> >>
> >> > diff --git
> a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> >> > index cb818708aef..372ed6e0c00 100644
> >> > --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> >> > +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> >> > @@ -18,6 +18,7 @@
> >> > // { dg-do run { target c++14 } }
> >> > // { dg-add-options libatomic }
> >> > // { dg-xfail-if "poll not available" { *-*-rtems* } }
> >> > +// { dg-require-thread-fence "" } // needed by
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
> >> >
> >> > #include
> >> > #include
> >> > diff --git
> a/libstdc++-v3/testsu
Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests
On Mon, 11 Sept 2023 at 12:59, Jonathan Wakely wrote:
> On Sun, 10 Sept 2023 at 20:31, Christophe Lyon
> wrote:
> >
> > Some targets like arm-eabi with newlib and default settings rely on
> > __sync_synchronize() to ensure synchronization. Newlib does not
> > implement it by default, to make users aware they have to take special
> > care.
> >
> > This makes a few tests fail to link.
>
> Does this mean those features are unusable on the target, or just that
> users need to provide their own __sync_synchronize to use them?
>
IIUC the user is expected to provide them.
Looks like we discussed this in the past :-)
In https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg01632.html,
see the pointer to Ramana's comment:
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html
The default arch for arm-eabi is armv4t which is very old.
When running the testsuite with something more recent (either as default by
configuring GCC --with-arch=XXX or by forcing -march/-mcpu via
dejagnu's target-board), the compiler generates barrier instructions and
there are no such errors.
For instance, here is a log with the defaults:
https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-arm_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-arm_eabi
and a log when we target cortex-m0 which is still a very small cpu but has
barriers:
https://git.linaro.org/toolchain/ci/base-artifacts/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi.git/tree/00-sumfiles?h=linaro-local/ci/tcwg_gnu_embed_check_gcc/master-thumb_m0_eabi
I somehow wanted to get rid of such errors with the default
configuration
> >
> > This patch requires the missing thread-fence effective target in the
> > tests that need it, making them UNSUPPORTED instead of FAIL and
> > UNRESOLVED.
>
> Some of the modified tests should not be using
> __gnu_debug::_Safe_sequence_base::_M_detach_all(), because they don't
> use the Debug Mode. I don't know where those linker errors come from.
> For example, the 23_containers/span/*assert_neg.cc and
> 26_numerics/valarray/* tests shouldn't use debug iterators or atomics.
> Neither should 25_algorithms/sample/2.cc nor
> 26_numerics/bit/bit.pow.two/bit_ceil_neg.cc
>
Ouch! I had the feeling this patch wouldn't count as obvious :-)
I confess I didn't analyze the linker map for every single test updated by
this patch
I can have a deeper look based on your comment below, excluding those that
look "OK"
> The last three in the patch shouldn't use it either:
>
> > diff --git
> a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> > index cb818708aef..372ed6e0c00 100644
> > --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> > +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> > @@ -18,6 +18,7 @@
> > // { dg-do run { target c++14 } }
> > // { dg-add-options libatomic }
> > // { dg-xfail-if "poll not available" { *-*-rtems* } }
> > +// { dg-require-thread-fence "" } // needed by
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
> >
> > #include
> > #include
> > diff --git
> a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> > index ae51979c3b4..8383e0be6a4 100644
> > --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> > +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> > @@ -18,6 +18,7 @@
> > // { dg-do run { target c++14 } }
> > // { dg-add-options libatomic }
> > // { dg-xfail-if "poll not available" { *-*-rtems* } }
> > +// { dg-require-thread-fence "" } // needed by
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
> >
> > #include
> > #include
> > diff --git
> a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> > index 960c1d253b5..42de45619a8 100644
> > ---
> a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> > +++
> b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> > @@ -16,6 +16,7 @@
> > // <http://www.gnu.org/licenses/>.
> >
> > // { dg-do run { target c++14 } }
> > +// { dg-require-thread-fence "" } // needed by
> __gnu_debug::_Safe_sequence_base::_M_detach_all()
> >
> > #include
> > #include
>
>
> I'm concerned with how much of the testsuite is being completely
> disabled for this target.
>
I think that de
[PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests
Some targets like arm-eabi with newlib and default settings rely on __sync_synchronize() to ensure synchronization. Newlib does not implement it by default, to make users aware they have to take special care. This makes a few tests fail to link. This patch requires the missing thread-fence effective target in the tests that need it, making them UNSUPPORTED instead of FAIL and UNRESOLVED. 2023-09-10 Christophe Lyon libstdc++-v3/ * testsuite/20_util/to_address/debug.cc: Require thread-fence effective target. * testsuite/21_strings/basic_string/cons/char/self_move.cc: Likewise. * testsuite/21_strings/basic_string/debug/1_neg.cc: Likewise. * testsuite/21_strings/basic_string/debug/2_neg.cc: Likewise. * testsuite/21_strings/basic_string/debug/find1_neg.cc: Likewise. * testsuite/21_strings/basic_string/debug/find2_neg.cc: Likewise. * testsuite/21_strings/basic_string/hash/debug.cc: Likewise. * testsuite/21_strings/basic_string/requirements/citerators.cc: Likewise. * testsuite/21_strings/basic_string/requirements/exception/basic.cc: Likewise. * testsuite/21_strings/basic_string/requirements/exception/generation_prohibited.cc: Likewise. * testsuite/21_strings/basic_string/requirements/exception/propagation_consistent.cc: Likewise. * testsuite/21_strings/debug/shrink_to_fit.cc: Likewise. * testsuite/23_containers/array/debug/back1_neg.cc: Likewise. * testsuite/23_containers/array/debug/back2_neg.cc: Likewise. * testsuite/23_containers/array/debug/front1_neg.cc: Likewise. * testsuite/23_containers/array/debug/front2_neg.cc: Likewise. * testsuite/23_containers/array/debug/square_brackets_operator1_neg.cc: Likewise. * testsuite/23_containers/array/debug/square_brackets_operator2_neg.cc: Likewise. * testsuite/23_containers/deque/cons/self_move.cc: Likewise. * testsuite/23_containers/deque/debug/98466.cc: Likewise. * testsuite/23_containers/deque/debug/assign4_neg.cc: Likewise. * testsuite/23_containers/deque/debug/construct4_neg.cc: Likewise. * testsuite/23_containers/deque/debug/insert4_neg.cc: Likewise. * testsuite/23_containers/deque/debug/invalidation/1.cc: Likewise. * testsuite/23_containers/deque/debug/invalidation/2.cc: Likewise. * testsuite/23_containers/deque/debug/invalidation/3.cc: Likewise. * testsuite/23_containers/deque/debug/invalidation/4.cc: Likewise. * testsuite/23_containers/forward_list/cons/self_move.cc: Likewise. * testsuite/23_containers/forward_list/debug/construct4_neg.cc: Likewise. * testsuite/23_containers/forward_list/debug/move_assign_neg.cc: Likewise. * testsuite/23_containers/forward_list/debug/move_neg.cc: Likewise. * testsuite/23_containers/list/cons/self_move.cc: Likewise. * testsuite/23_containers/list/debug/assign4_neg.cc: Likewise. * testsuite/23_containers/list/debug/construct4_neg.cc: Likewise. * testsuite/23_containers/list/debug/insert4_neg.cc: Likewise. * testsuite/23_containers/list/debug/invalidation/1.cc: Likewise. * testsuite/23_containers/list/debug/invalidation/2.cc: Likewise. * testsuite/23_containers/list/debug/invalidation/3.cc: Likewise. * testsuite/23_containers/list/debug/invalidation/4.cc: Likewise. * testsuite/23_containers/map/debug/construct4_neg.cc: Likewise. * testsuite/23_containers/map/debug/construct5_neg.cc: Likewise. * testsuite/23_containers/map/debug/insert4_neg.cc: Likewise. * testsuite/23_containers/map/debug/invalidation/1.cc: Likewise. * testsuite/23_containers/map/debug/invalidation/2.cc: Likewise. * testsuite/23_containers/map/debug/move_assign_neg.cc: Likewise. * testsuite/23_containers/map/debug/move_neg.cc: Likewise. * testsuite/23_containers/map/modifiers/erase/end_neg.cc: Likewise. * testsuite/23_containers/map/modifiers/insert/16813.cc: Likewise. * testsuite/23_containers/multimap/debug/construct4_neg.cc: Likewise. * testsuite/23_containers/multimap/debug/construct5_neg.cc: Likewise. * testsuite/23_containers/multimap/debug/insert4_neg.cc: Likewise. * testsuite/23_containers/multimap/debug/invalidation/1.cc: Likewise. * testsuite/23_containers/multimap/debug/invalidation/2.cc: Likewise. * testsuite/23_containers/multimap/debug/move_assign_neg.cc: Likewise. * testsuite/23_containers/multimap/debug/move_neg.cc: Likewise. * testsuite/23_containers/multiset/debug/construct4_neg.cc: Likewise. * testsuite/23_containers/multiset/debug/construct5_neg.cc: Likewise. * testsuite/23_containers/multiset/debug/insert4_neg.cc: Likewise. * testsuite/23_containers/multiset/debug/invalidation/1.cc: Likewise. * testsuite/23_containers/multiset
[PATCH 1/2] testsuite: Add and use thread_fence effective-target
Some targets like arm-eabi with newlib and default settings rely on
__sync_synchronize() to ensure synchronization. Newlib does not
implement it by default, to make users aware they have to take special
care.
This makes a few tests fail to link.
This patch adds a new thread_fence effective target (similar to the
corresponding one in libstdc++ testsuite), and uses it in the tests
that need it, making them UNSUPPORTED instead of FAIL and UNRESOLVED.
2023-09-10 Christophe Lyon
gcc/
* doc/sourcebuild.texi (Other attributes): Document thread_fence
effective-target.
gcc/testsuite/
* g++.dg/init/array54.C: Require thread_fence.
* gcc.dg/c2x-nullptr-1.c: Likewise.
* gcc.dg/pr103721-2.c: Likewise.
* lib/target-supports.exp (check_effective_target_thread_fence):
New.
---
gcc/doc/sourcebuild.texi | 4
gcc/testsuite/g++.dg/init/array54.C | 1 +
gcc/testsuite/gcc.dg/c2x-nullptr-1.c | 1 +
gcc/testsuite/gcc.dg/pr103721-2.c | 1 +
gcc/testsuite/lib/target-supports.exp | 12
5 files changed, 19 insertions(+)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 1a78b3c1abb..a5f61c29f3b 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2860,6 +2860,10 @@ Compiler has been configured to support link-time
optimization (LTO).
Compiler and linker support link-time optimization relocatable linking
with @option{-r} and @option{-flto} options.
+@item thread_fence
+Target implements @code{__atomic_thread_fence} without relying on
+non-implemented @code{__sync_synchronize()}.
+
@item naked_functions
Target supports the @code{naked} function attribute.
diff --git a/gcc/testsuite/g++.dg/init/array54.C
b/gcc/testsuite/g++.dg/init/array54.C
index f6be350ba72..5241e451d6d 100644
--- a/gcc/testsuite/g++.dg/init/array54.C
+++ b/gcc/testsuite/g++.dg/init/array54.C
@@ -1,5 +1,6 @@
// PR c++/90947
// { dg-do run { target c++11 } }
+// { dg-require-effective-target thread_fence }
#include
diff --git a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
index 4e440234d52..97a31c27409 100644
--- a/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
+++ b/gcc/testsuite/gcc.dg/c2x-nullptr-1.c
@@ -1,5 +1,6 @@
/* Test valid usage of C23 nullptr. */
/* { dg-do run } */
+// { dg-require-effective-target thread_fence }
/* { dg-options "-std=c2x -pedantic-errors -Wall -Wextra -Wno-unused-variable"
} */
#include
diff --git a/gcc/testsuite/gcc.dg/pr103721-2.c
b/gcc/testsuite/gcc.dg/pr103721-2.c
index aefa1f0f147..e059b1cfc2d 100644
--- a/gcc/testsuite/gcc.dg/pr103721-2.c
+++ b/gcc/testsuite/gcc.dg/pr103721-2.c
@@ -1,4 +1,5 @@
// { dg-do run }
+// { dg-require-effective-target thread_fence }
// { dg-options "-O2" }
extern void abort ();
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index d353cc0aaf0..7ac9e7530cc 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -9107,6 +9107,18 @@ proc check_effective_target_sync_char_short { } {
|| [check_effective_target_mips_llsc] }}]
}
+# Return 1 if thread_fence does not rely on __sync_synchronize
+# library function
+
+proc check_effective_target_thread_fence {} {
+return [check_no_compiler_messages thread_fence executable {
+ int main () {
+ __atomic_thread_fence (__ATOMIC_SEQ_CST);
+ return 0;
+ }
+} ""]
+}
+
# Return 1 if the target uses a ColdFire FPU.
proc check_effective_target_coldfire_fpu { } {
--
2.34.1
[PATCH] testsuite: Fix gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c
The test was declaring 'int *carry;' and wrote to '*carry' without initializing 'carry' first, leading to an attempt to write at address zero, and a crash. Fix by declaring 'int carry;' and passing '' instead of 'carry' as parameter. 2023-09-08 Christophe Lyon gcc/testsuite/ * gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c: Fix. --- .../arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c | 34 +-- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c b/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c index a8c6cce67c8..931c9d2f30b 100644 --- a/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c +++ b/gcc/testsuite/gcc.target/arm/mve/mve_vadcq_vsbcq_fpscr_overwrite.c @@ -7,7 +7,7 @@ volatile int32x4_t c1; volatile uint32x4_t c2; -int *carry; +int carry; int main () @@ -21,45 +21,45 @@ main () uint32x4_t inactive2 = vcreateq_u32 (0, 0); mve_pred16_t p = 0x; - (*carry) = 0x; + carry = 0x; __builtin_arm_set_fpscr_nzcvqc (0); - c1 = vadcq (a1, b1, carry); + c1 = vadcq (a1, b1, ); if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) __builtin_abort (); - (*carry) = 0x; + carry = 0x; __builtin_arm_set_fpscr_nzcvqc (0); - c2 = vadcq (a2, b2, carry); + c2 = vadcq (a2, b2, ); if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) __builtin_abort (); - (*carry) = 0x; + carry = 0x; __builtin_arm_set_fpscr_nzcvqc (0); - c1 = vsbcq (a1, b1, carry); + c1 = vsbcq (a1, b1, ); if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) __builtin_abort (); - (*carry) = 0x; + carry = 0x; __builtin_arm_set_fpscr_nzcvqc (0); - c2 = vsbcq (a2, b2, carry); + c2 = vsbcq (a2, b2, ); if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) __builtin_abort (); - (*carry) = 0x; + carry = 0x; __builtin_arm_set_fpscr_nzcvqc (0); - c1 = vadcq_m (inactive1, a1, b1, carry, p); + c1 = vadcq_m (inactive1, a1, b1, , p); if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) __builtin_abort (); - (*carry) = 0x; + carry = 0x; __builtin_arm_set_fpscr_nzcvqc (0); - c2 = vadcq_m (inactive2, a2, b2, carry, p); + c2 = vadcq_m (inactive2, a2, b2, , p); if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) __builtin_abort (); - (*carry) = 0x; + carry = 0x; __builtin_arm_set_fpscr_nzcvqc (0); - c1 = vsbcq_m (inactive1, a1, b1, carry, p); + c1 = vsbcq_m (inactive1, a1, b1, , p); if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) __builtin_abort (); - (*carry) = 0x; + carry = 0x; __builtin_arm_set_fpscr_nzcvqc (0); - c2 = vsbcq_m (inactive2, a2, b2, carry, p); + c2 = vsbcq_m (inactive2, a2, b2, , p); if (__builtin_arm_get_fpscr_nzcvqc () & !0x2000) __builtin_abort (); -- 2.34.1
Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists
On Thu, 7 Sept 2023 at 11:45, Jakub Jelinek wrote: > On Thu, Sep 07, 2023 at 10:20:19AM +0200, Christophe Lyon via Gcc-patches > wrote: > > On Tue, 5 Sept 2023 at 16:38, Tobias Burnus > wrote: > > > > > That's based on the fail > > > https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html > > > and on the discussion on IRC. > > > > > > > Sorry I didn't notice the problem, nor the discussion on IRC, but I can > see > > that my commits created the problem, sorry for that. > > > > I'm not sure how your patch would have prevented me from doing this? > > What happened is that I had 3 patches on top of master > > - HEAD: the one I wanted to push > > - HEAD-1: revert of HEAD-2 > > git reset HEAD^ > instead of committing a revert would be better I think. > The patch I reverted locally was still under discussion, so I wanted to keep it around until we made a decision. But yeah. > > - HEAD-2: libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch > > > > I had actually forgotten about HEAD-1 and HEAD-2, HEAD was unrelated to > > those, so when I pushed, I pushed 3 commits while I thought there was > only > > one. > > I did run contrib/gcc-changelog/git_check_commit.py (I realize I'm not > sure > > whether I used git_check_commit.py or git_commit.py), but only on HEAD > > since I had forgotten about the other two. > > Could you please remove your > 2023-09-04 Christophe Lyon > > PR libstdc++/111238 > * configure: Regenerate. > * configure.ac: Call GLIBCXX_CHECK_LINKER_FEATURES in cross, > non-Canadian builds. > libstdc++-v3/ChangeLog entry if that commit is indeed not in (or add > a Revert: entry for it right after it if you think it needs to be in)? > That is a part I haven't done, my/Arsen's hacks to make the version update > get through basically ignored that revert commit. > > ChangeLog files can be changed by commits which only touch ChangeLog files > and nothing else (ok, date stamp too, but please don't update that), no > ChangeLog in the message needs to be provided for such changes. > Like so: commit d2bb261dbf282bbb258e1e5f17c1b6230327e076 (HEAD -> master) Author: Christophe Lyon Date: Fri Sep 8 08:13:32 2023 + Revert "libstdc++: Use GLIBCXX_CHECK_LINKER_FEATURES for cross-builds (PR111238)" diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 8f7b01e0563..0c60149d7f6 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -4,6 +4,16 @@ for freestanding. * configure: Regenerate. +2023-09-04 Christophe Lyon + + Revert + 2023-09-04 Christophe Lyon + + PR libstdc++/111238 + * configure: Regenerate. + * configure.ac: Call GLIBCXX_CHECK_LINKER_FEATURES in cross, + non-Canadian builds. + 2023-09-04 Christophe Lyon PR libstdc++/111238 I inserted my "Revert" ChangeLog entry between the entry I want to declare reverted and Jonathan's more recent patch about GLIBCXX_ENABLE_BACKTRACE. Is that OK for the commit hooks? Jakub > >
Re: [Patch] contrib/gcc-changelog: Check whether revert-commit exists
Hi! On Tue, 5 Sept 2023 at 16:38, Tobias Burnus wrote: > That's based on the fail > https://gcc.gnu.org/pipermail/gccadmin/2023q3/020349.html > and on the discussion on IRC. > Sorry I didn't notice the problem, nor the discussion on IRC, but I can see that my commits created the problem, sorry for that. I'm not sure how your patch would have prevented me from doing this? What happened is that I had 3 patches on top of master - HEAD: the one I wanted to push - HEAD-1: revert of HEAD-2 - HEAD-2: libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch I had actually forgotten about HEAD-1 and HEAD-2, HEAD was unrelated to those, so when I pushed, I pushed 3 commits while I thought there was only one. I did run contrib/gcc-changelog/git_check_commit.py (I realize I'm not sure whether I used git_check_commit.py or git_commit.py), but only on HEAD since I had forgotten about the other two. Are these scripts executed by the commit hooks too? (and thus they would now warn?) Thanks, Christophe > The problem in for the cron job was that > r14-3661-g084a7cf9fb2d9cb98dfbe7d91602c840ec50b002 > referenced a commit that did not exist. > > This was temporarily fixed by Jakub, but it makes sense to detect this > in the pre-commit hook. > > > With the patch, >contrib/gcc-changelog/git_email.py > 0001-Revert-libstdc-Use-GLIBCXX_CHECK_LINKER_FEATURES-for.patch > now prints: > OK > Warnings: > Cannot obtain info about reverted commit > '46c2e94ca66ed9991c45a6ba6204ed02869efc39' > > while >contrib/gcc-changelog/git_check_commit.py > 084a7cf9fb2d9cb98dfbe7d91602c840ec50b002 > now fails with: >Checking 084a7cf9fb2d9cb98dfbe7d91602c840ec50b002: FAILED >ERR: Cannot find to-be-reverted commit: > "46c2e94ca66ed9991c45a6ba6204ed02869efc39" > > (check_email.py always shows the warning, git_check_commit.py only with > '-v') > > Notes: > - I am not sure whether a sensible testcase can be added - and, hence, I > have not added one. > - I have run "pytest-3' but my python is too old and thus might miss some > checks which >newer pytest/flake8 will find. But at least it did pass here. > - I have not tested the cherry-pick + commit does not exist case, >which now creates a warning as I did not quickly find a testcase. > > Comments, remarks, suggestions, approval? > > Tobias > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > Registergericht München, HRB 106955 >
[PATCH] testsuite: Remove unwanted 'dg-do run' from gcc.dg/vect tests
Tests under gcc.dg/vect use check_vect_support_and_set_flags to set
compilation flags as appropriate for the target, but they also set
dg-do-what-default to 'run' or 'compile', depending on the actual
target hardware (or simulator) capabilities.
For instance on arm, we use options to enable Neon, but set
dg-do-what-default to 'run' only if we cam actually execute Neon
instructions.
Therefore, we would always try to link and execute tests containing
'dg-do run', although dg-do-what-default says otherwise, leading to
uninteresting failures.
Therefore, this patch removes all such unconditionnal 'dg-do run',
thus avoid link errors for instance if GCC has been configured with
multilibs disabled and some --with-{float|cpu|hard} option
incompatible with what check_vect_support_and_set_flags selects.
For exmaple, GCC configured with:
--disable-multilib --with-mode=thumb --with-cpu=cortex-m7 --with-float=hard
and check_vect_support_and_set_flags uses
-mfpu=neon -mfloat-abi=softfp -march=armv7-a
(thus incompatible float-abi options)
Tested on native aarch64-linux-gnu (no change) and several arm-eabi
cases where the FAIL/UNRESOLVED disappear (and we keep only the
'compilation' tests).
2023-09-04 Christophe Lyon
gcc/testsuite/
* gcc.dg/vect/bb-slp-44.c: Remove 'dg-do run'.
* gcc.dg/vect/bb-slp-71.c: Likewise.
* gcc.dg/vect/bb-slp-72.c: Likewise.
* gcc.dg/vect/bb-slp-73.c: Likewise.
* gcc.dg/vect/bb-slp-74.c: Likewise.
* gcc.dg/vect/bb-slp-pr101207.c: Likewise.
* gcc.dg/vect/bb-slp-pr101615-1.c: Likewise.
* gcc.dg/vect/bb-slp-pr101615-2.c: Likewise.
* gcc.dg/vect/bb-slp-pr101668.c: Likewise.
* gcc.dg/vect/bb-slp-pr54400.c: Likewise.
* gcc.dg/vect/bb-slp-pr98516-1.c: Likewise.
* gcc.dg/vect/bb-slp-pr98516-2.c: Likewise.
* gcc.dg/vect/bb-slp-pr98544.c: Likewise.
* gcc.dg/vect/pr101445.c: Likewise.
* gcc.dg/vect/pr105219.c: Likewise.
* gcc.dg/vect/pr107160.c: Likewise.
* gcc.dg/vect/pr107212-1.c: Likewise.
* gcc.dg/vect/pr107212-2.c: Likewise.
* gcc.dg/vect/pr109502.c: Likewise.
* gcc.dg/vect/pr110381.c: Likewise.
* gcc.dg/vect/pr110838.c: Likewise.
* gcc.dg/vect/pr88497-1.c: Likewise.
* gcc.dg/vect/pr88497-7.c: Likewise.
* gcc.dg/vect/pr96783-1.c: Likewise.
* gcc.dg/vect/pr96783-2.c: Likewise.
* gcc.dg/vect/pr97558-2.c: Likewise.
* gcc.dg/vect/pr99253.c: Likewise.
* gcc.dg/vect/slp-mask-store-1.c: Likewise.
* gcc.dg/vect/vect-bic-bitmask-10.c: Likewise.
* gcc.dg/vect/vect-bic-bitmask-11.c: Likewise.
* gcc.dg/vect/vect-bic-bitmask-2.c: Likewise.
* gcc.dg/vect/vect-bic-bitmask-3.c: Likewise.
* gcc.dg/vect/vect-bic-bitmask-4.c: Likewise.
* gcc.dg/vect/vect-bic-bitmask-5.c: Likewise.
* gcc.dg/vect/vect-bic-bitmask-6.c: Likewise.
* gcc.dg/vect/vect-bic-bitmask-8.c: Likewise.
* gcc.dg/vect/vect-bic-bitmask-9.c: Likewise.
* gcc.dg/vect/vect-cond-13.c: Likewise.
* gcc.dg/vect/vect-recurr-1.c: Likewise.
* gcc.dg/vect/vect-recurr-2.c: Likewise.
* gcc.dg/vect/vect-recurr-3.c: Likewise.
* gcc.dg/vect/vect-recurr-4.c: Likewise.
* gcc.dg/vect/vect-recurr-5.c: Likewise.
* gcc.dg/vect/vect-recurr-6.c: Likewise.
---
gcc/testsuite/gcc.dg/vect/bb-slp-44.c | 2 --
gcc/testsuite/gcc.dg/vect/bb-slp-71.c | 2 --
gcc/testsuite/gcc.dg/vect/bb-slp-72.c | 2 --
gcc/testsuite/gcc.dg/vect/bb-slp-73.c | 2 --
gcc/testsuite/gcc.dg/vect/bb-slp-74.c | 1 -
gcc/testsuite/gcc.dg/vect/bb-slp-pr101207.c | 1 -
gcc/testsuite/gcc.dg/vect/bb-slp-pr101615-1.c | 1 -
gcc/testsuite/gcc.dg/vect/bb-slp-pr101615-2.c | 1 -
gcc/testsuite/gcc.dg/vect/bb-slp-pr101668.c | 1 -
gcc/testsuite/gcc.dg/vect/bb-slp-pr54400.c | 1 -
gcc/testsuite/gcc.dg/vect/bb-slp-pr98516-1.c| 2 --
gcc/testsuite/gcc.dg/vect/bb-slp-pr98516-2.c| 2 --
gcc/testsuite/gcc.dg/vect/bb-slp-pr98544.c | 2 --
gcc/testsuite/gcc.dg/vect/pr101445.c| 2 --
gcc/testsuite/gcc.dg/vect/pr105219.c| 1 -
gcc/testsuite/gcc.dg/vect/pr107160.c| 2 --
gcc/testsuite/gcc.dg/vect/pr107212-1.c | 2 --
gcc/testsuite/gcc.dg/vect/pr107212-2.c | 2 --
gcc/testsuite/gcc.dg/vect/pr109502.c| 1 -
gcc/testsuite/gcc.dg/vect/pr110381.c| 1 -
gcc/testsuite/gcc.dg/vect/pr110838.c| 2 --
gcc/testsuite/gcc.dg/vect/pr88497-1.c | 1 -
gcc/testsuite/gcc.dg/vect/pr88497-7.c | 1 -
gcc/testsuite/gcc.dg/vect/pr96783-1.c | 2 --
gcc/testsuite/gcc.dg/vect/pr96783-2.c | 2 --
gcc/testsuite/gcc.dg/vect/pr97558-2.c | 1 -
gcc/testsuite/gcc.dg/vect/pr99253.c | 2 --
gcc/testsuite/gcc.dg/vect/slp-mask-store-1.c| 1 -
gcc/testsuite/gcc.dg/vect/vect
Re: [PATCH] analyzer: Add support of placement new and improved operator new [PR105948,PR94355]
Hi Benjanmin,
On Fri, 1 Sept 2023 at 17:45, David Malcolm via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Fri, 2023-09-01 at 16:48 +0200, Benjamin Priour wrote:
> > Patch has been updated as per your suggestions and successfully
> > regstrapped
> > on x86_64-linux-gnu.
> >
The new testcase placement-new-size.C fails on aarch64:
placement-new-size.C:10:3: error: 'int8_t' was not declared in this scope;
did you mean 'wint_t'?
placement-new-size.C:11:3: error: 'int64_t' was not declared in this scope
placement-new-size.C:11:12: error: 'lp' was not declared in this scope
placement-new-size.C:11:23: error: 's' was not declared in this scope
placement-new-size.C:11:26: error: 'int64_t' does not name a type
placement-new-size.C:34:3: error: 'int32_t' was not declared in this scope
placement-new-size.C:34:12: error: 'i' was not declared in this scope
placement-new-size.C:34:30: error: 'int32_t' does not name a type
I suspect you should include (instead of stdlib.h)
Thanks,
Christophe
> > call_details::maybe_get_arg_region is now
> > /* If argument IDX's svalue at the callsite is of pointer type,
> > return the region it points to.
> > Otherwise return NULL. */
> >
> > const region *
> > call_details::deref_ptr_arg (unsigned idx) const
> > {
> >const svalue *ptr_sval = get_arg_svalue (idx);
> >return m_model->deref_rvalue (ptr_sval, get_arg_tree (idx),
> > m_ctxt);
> > }
> >
> >
> > New test is
> >
> > +
> > +void test_binop ()
> > +{
> > + char *p = (char *) malloc (4);
> > + if (!p)
> > +return;
> > + int32_t *i = ::new (p + 1) int32_t; /* { dg-warning "heap-based
> > buffer
> > overflow" } */
> > + *i = 42; /* { dg-warning "heap-based buffer overflow" } */
> > + free (p);
> > +}
> >
> > Is it OK for trunk ?
> > I didn't resend the whole patch as it otherwise was OK.
>
> Yes, thanks.
>
> Dave
>
>
