[PATCH 1/8] config: use grep -E instead of egrep

2022-06-23 Thread Xi Ruoyao via Gcc-patches
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.

ChangeLog:

* configure.ac: Use grep -E instead of egrep.
* config.rpath: Likewise.
* configure: Regenerate.

config/ChangeLog:

* lib-ld.m4 (AC_LIB_PROG_LD_GNU): Use grep -E instead of egrep.
(acl_cv_path_LD): Likewise.

gcc/ChangeLog:

* configure: Regenerate.

intl/ChangeLog:

* configure: Regenerate.

libcpp/ChangeLog:

* configure: Regenerate.

libgcc/ChangeLog:

* configure: Regenerate.

libstdc++-v3/ChangeLog:

* configure: Regenerate.
---
 config.rpath   | 8 
 config/lib-ld.m4   | 4 ++--
 configure  | 4 ++--
 configure.ac   | 4 ++--
 gcc/configure  | 8 
 intl/configure | 4 ++--
 libcpp/configure   | 4 ++--
 libgcc/configure   | 2 +-
 libstdc++-v3/configure | 4 ++--
 9 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/config.rpath b/config.rpath
index 4dea75957c2..20ffc3eb241 100755
--- a/config.rpath
+++ b/config.rpath
@@ -143,7 +143,7 @@ if test "$with_gnu_ld" = yes; then
   ld_shlibs=no
   ;;
 beos*)
-  if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+  if $LD --help 2>&1 | grep -E ': supported targets:.* elf' > /dev/null; 
then
 :
   else
 ld_shlibs=no
@@ -162,9 +162,9 @@ if test "$with_gnu_ld" = yes; then
 netbsd*)
   ;;
 solaris* | sysv5*)
-  if $LD -v 2>&1 | egrep 'BFD 2\.8' > /dev/null; then
+  if $LD -v 2>&1 | grep -E 'BFD 2\.8' > /dev/null; then
 ld_shlibs=no
-  elif $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; 
then
+  elif $LD --help 2>&1 | grep -E ': supported targets:.* elf' > /dev/null; 
then
 :
   else
 ld_shlibs=no
@@ -174,7 +174,7 @@ if test "$with_gnu_ld" = yes; then
   hardcode_direct=yes
   ;;
 *)
-  if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+  if $LD --help 2>&1 | grep -E ': supported targets:.* elf' > /dev/null; 
then
 :
   else
 ld_shlibs=no
diff --git a/config/lib-ld.m4 b/config/lib-ld.m4
index 11d0ce77342..e536ff4d115 100644
--- a/config/lib-ld.m4
+++ b/config/lib-ld.m4
@@ -14,7 +14,7 @@ dnl From libtool-1.4. Sets the variable with_gnu_ld to yes or 
no.
 AC_DEFUN([AC_LIB_PROG_LD_GNU],
 [AC_CACHE_CHECK([if the linker ($LD) is GNU ld], acl_cv_prog_gnu_ld,
 [# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 &5; then
+if $LD -v 2>&1 &5; then
   acl_cv_prog_gnu_ld=yes
 else
   acl_cv_prog_gnu_ld=no
@@ -88,7 +88,7 @@ AC_CACHE_VAL(acl_cv_path_LD,
   # Check to see if the program is GNU ld.  I'd rather use --version,
   # but apparently some GNU ld's only accept -v.
   # Break only if it was the GNU/non-GNU ld that we prefer.
-  if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > 
/dev/null; then
+  if "$acl_cv_path_LD" -v 2>&1 < /dev/null | grep -E '(GNU|with BFD)' > 
/dev/null; then
test "$with_gnu_ld" != no && break
   else
test "$with_gnu_ld" != yes && break
diff --git a/configure b/configure
index 5dcaab14ae9..4a22d7ab3f0 100755
--- a/configure
+++ b/configure
@@ -9448,7 +9448,7 @@ if test x${use_gnu_as} = x &&
 fi
 
 if test x${use_gnu_ld} = x &&
-   echo " ${configdirs} " | egrep " (go)?ld " > /dev/null 2>&1 ; then
+   echo " ${configdirs} " | grep -E " (go)?ld " > /dev/null 2>&1 ; then
   with_gnu_ld=yes
   extra_host_args="$extra_host_args --with-gnu-ld"
 fi
@@ -10620,7 +10620,7 @@ case " $build_configdirs " in
 # For an installed makeinfo, we require it to be from texinfo 4.7 or
 # higher, else we use the "missing" dummy.
 if ${MAKEINFO} --version \
-   | egrep 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' 
>/dev/null 2>&1; then
+   | grep -E 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' 
>/dev/null 2>&1; then
   :
 else
   MAKEINFO="$MISSING makeinfo"
diff --git a/configure.ac b/configure.ac
index 85977482aee..06ffa5afbe8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2634,7 +2634,7 @@ if test x${use_gnu_as} = x &&
 fi
 
 if test x${use_gnu_ld} = x &&
-   echo " ${configdirs} " | egrep " (go)?ld " > /dev/null 2>&1 ; then
+   echo " ${configdirs} " | grep -E " (go)?ld " > /dev/null 2>&1 ; then
   with_gnu_ld=yes
   extra_host_args="$extra_host_args --with-gnu-ld"
 fi
@@ -3549,7 +3549,7 @@ changequote(,)
 # For an installed makeinfo, we require it to be from texinfo 4.7 or
 # higher, else we use the "missing" dummy.
 if ${MAKEINFO} --version \
-   | egrep 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' 
>/dev/null 2>&1; then
+   | grep -E 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' 
>/dev/null 2>&1; then
   :
 els

[PATCH 0/8] Stop using obsoleted egrep/fgrep

2022-06-23 Thread Xi Ruoyao via Gcc-patches
egrep and fgrep have been deprecated for a long time, and the next grep
release will emit a warning if egrep or fgrep is invoked:

https://git.savannah.gnu.org/cgit/grep.git/commit/?id=a951562

To prevent us from a lot of these warnings in the future, we should stop
using egrep and fgrep.  These patches will remove most of the use of
egrep or fgrep from GCC building system.  The remaining:

* The configure scripts generated by autoconf-2.69 will still refer to
  "egrep", but they will try "grep -E" first and only try egrep when
  "grep -E" is not available.
* libgo: Left for Ian because I'm not familiar with it.
* maintainer-scripts/update_web_docs_libstdcxx_git: Left for Jonathan
  because I don't think other people will invoke it.
* libffi: Already submitted https://github.com/libffi/libffi/pull/720.
* contrib/gen_autofdo_event.py and gcc/config/i386/gcc-auto-profile:
  I'll make a patch later (now download.01.org seems down so I can't
  test or regenerate gcc-auto-profile) porting gen_autofdo_event.py to
  Python 3.

Xi Ruoyao (8):
  config: use grep -E instead of egrep
  fixincludes: use grep -E/-F instead of egrep/fgrep
  libstdc++: use grep -E instead of egrep in scripts
  libbacktrace: use grep -F instead of fgrep
  intl: stop using fgrep for exgettext
  fortran: use grep -F instead of fgrep
  testsuite: use grep -E instead of egrep
  contrib: use grep -E instead of egrep

 config.rpath|  8 
 config/lib-ld.m4|  4 ++--
 configure   |  4 ++--
 configure.ac|  4 ++--
 contrib/check_GNU_style.sh  | 10 +-
 contrib/test_summary|  2 +-
 contrib/warn_summary|  2 +-
 fixincludes/fixinc.in   |  2 +-
 fixincludes/fixincl.x   | 10 +-
 fixincludes/genfixes|  2 +-
 fixincludes/inclhack.def|  6 +++---
 gcc/configure   |  8 
 gcc/fortran/Make-lang.in|  2 +-
 gcc/po/exgettext|  2 +-
 gcc/testsuite/ada/acats/run_all.sh  |  2 +-
 gcc/testsuite/go.test/go-test.exp   |  2 +-
 intl/configure  |  4 ++--
 libbacktrace/configure  |  2 +-
 libbacktrace/configure.ac   |  2 +-
 libcpp/configure|  4 ++--
 libgcc/configure|  2 +-
 libstdc++-v3/configure  |  4 ++--
 libstdc++-v3/scripts/extract_symvers.in |  4 ++--
 libstdc++-v3/scripts/run_doxygen|  4 ++--
 24 files changed, 48 insertions(+), 48 deletions(-)

-- 
2.36.1




Re: [PATCH] testsuite: Handle default_packed for gcc.dg/builtin-object-size-20.c

2022-06-23 Thread Richard Biener via Gcc-patches
On Thu, Jun 23, 2022 at 11:24 PM Dimitar Dimitrov  wrote:
>
> The gcc.dg/builtin-object-size-20.c test case assumes that the target
> inserts padding between structure members.  Obviously it fails for
> targets which pack structures by default.
>
> Split the cases into two tests, so that the ones requiring structure
> padding can be skipped for default_packed targets.
>
> Ok for trunk?

OK

> gcc/testsuite/ChangeLog:
>
> * gcc.dg/builtin-object-size-20.c: Remove cases which
> work on default_packed targets.
> * gcc.dg/builtin-object-size-22.c: New test with the cases
> removed above.
>
> Signed-off-by: Dimitar Dimitrov 
> ---
>  gcc/testsuite/gcc.dg/builtin-object-size-20.c | 64 +--
>  gcc/testsuite/gcc.dg/builtin-object-size-22.c | 79 +++
>  2 files changed, 81 insertions(+), 62 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-22.c
>
> diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-20.c 
> b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
> index bed973c2c77..f40e3dcc1a9 100644
> --- a/gcc/testsuite/gcc.dg/builtin-object-size-20.c
> +++ b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
> @@ -1,7 +1,8 @@
>  /* PR middle-end/92815 - spurious -Wstringop-overflow writing into
> a flexible array of an extern struct
> { dg-do compile }
> -   { dg-options "-O -Wall -fdump-tree-optimized" } */
> +   { dg-options "-O -Wall -fdump-tree-optimized" }
> +   { dg-skip-if "test assumes that structs have padding" { default_packed } 
> } */
>
>  #define ASSERT(expr) ((expr) ? (void)0 : fail (__LINE__))
>  #define bos0(expr) __builtin_object_size (expr, 1)
> @@ -18,44 +19,6 @@ typedef __SIZE_TYPE__  size_t;
>  extern void fail (int);
>
>
> -/* Verify sizes of a struct with a flexible array member and no padding.  */
> -
> -struct ACX { char n, a[]; };
> -
> -struct ACX ac0 = { };
> -struct ACX ac1 = { 1, { 1 } };
> -struct ACX ac2 = { 2, { 1, 2 } };
> -struct ACX ac3 = { 3, { 1, 2, 3 } };
> -
> -extern struct ACX eacx;
> -
> -void facx (void)
> -{
> -  ASSERT (bos0 (&ac0) == sizeof ac0);
> -  ASSERT (bos0 (&ac1) == 2);
> -  ASSERT (bos0 (&ac2) == 3);
> -  ASSERT (bos0 (&ac3) == 4);
> -  ASSERT (bos0 (&eacx) == (size_t)-1);
> -
> -  ASSERT (bos1 (&ac0) == sizeof ac0);
> -  ASSERT (bos1 (&ac1) == 2);
> -  ASSERT (bos1 (&ac2) == 3);
> -  ASSERT (bos1 (&ac3) == 4);
> -  ASSERT (bos1 (&eacx) == (size_t)-1);
> -
> -  ASSERT (bos2 (&ac0) == sizeof ac0);
> -  ASSERT (bos2 (&ac1) == 2);
> -  ASSERT (bos2 (&ac2) == 3);
> -  ASSERT (bos2 (&ac3) == 4);
> -  ASSERT (bos2 (&eacx) == sizeof eacx);
> -
> -  ASSERT (bos3 (&ac0) == sizeof ac0);
> -  ASSERT (bos3 (&ac1) == 2);
> -  ASSERT (bos3 (&ac2) == 3);
> -  ASSERT (bos3 (&ac3) == 4);
> -  ASSERT (bos3 (&eacx) == sizeof eacx);
> -}
> -
>
>
>  /* Verify sizes of a struct with a flexible array member and 1 byte
> @@ -289,27 +252,4 @@ void fai64cx (void)
>ASSERT (bos3 (&eai64cx) == sizeof eai64cx);
>  }
>
> -
> -/* Also verify sizes of a struct with a zero length array member.  */
> -
> -struct A0C0 { char n, a[0]; };
> -
> -struct A0C0 a0c0 = { };
> -extern struct A0C0 ea0c0;
> -
> -void fa0c0 (void)
> -{
> -  ASSERT (bos0 (&a0c0) == sizeof a0c0);
> -  ASSERT (bos0 (&ea0c0) == sizeof ea0c0);
> -
> -  ASSERT (bos1 (&a0c0) == sizeof a0c0);
> -  ASSERT (bos1 (&a0c0) == sizeof ea0c0);
> -
> -  ASSERT (bos2 (&a0c0) == sizeof a0c0);
> -  ASSERT (bos2 (&a0c0) == sizeof ea0c0);
> -
> -  ASSERT (bos3 (&a0c0) == sizeof a0c0);
> -  ASSERT (bos3 (&a0c0) == sizeof ea0c0);
> -}
> -
>  /* { dg-final { scan-tree-dump-not "fail" "optimized" } } */
> diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-22.c 
> b/gcc/testsuite/gcc.dg/builtin-object-size-22.c
> new file mode 100644
> index 000..1e55229c949
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/builtin-object-size-22.c
> @@ -0,0 +1,79 @@
> +/* PR middle-end/92815 - a variant of gcc.dg/builtin-object-size-20.c
> +   prepared for all targets, irregardless if they pack or not
> +   the structs by default.
> +   { dg-do compile }
> +   { dg-options "-O -Wall -fdump-tree-optimized" } */
> +
> +#define ASSERT(expr) ((expr) ? (void)0 : fail (__LINE__))
> +#define bos0(expr) __builtin_object_size (expr, 1)
> +#define bos1(expr) __builtin_object_size (expr, 1)
> +#define bos2(expr) __builtin_object_size (expr, 2)
> +#define bos3(expr) __builtin_object_size (expr, 3)
> +
> +typedef __SIZE_TYPE__  size_t;
> +
> +
> +extern void fail (int);
> +
> +
> +/* Verify sizes of a struct with a flexible array member and no padding.  */
> +
> +struct ACX { char n, a[]; };
> +
> +struct ACX ac0 = { };
> +struct ACX ac1 = { 1, { 1 } };
> +struct ACX ac2 = { 2, { 1, 2 } };
> +struct ACX ac3 = { 3, { 1, 2, 3 } };
> +
> +extern struct ACX eacx;
> +
> +void facx (void)
> +{
> +  ASSERT (bos0 (&ac0) == sizeof ac0);
> +  ASSERT (bos0 (&ac1) == 2);
> +  ASSERT (bos0 (&ac2) == 3);
> +  ASSERT (bos0 (&ac3) == 4);
> +  ASSERT (bos0 (&eacx) == (size_t)-1);
> +
> +  ASSERT (bos1

Re: [PATCH] testsuite: Rename test-defined macros

2022-06-23 Thread Richard Biener via Gcc-patches
On Thu, Jun 23, 2022 at 11:23 PM Dimitar Dimitrov  wrote:
>
> Epiphany, PRU, ARC and NDS32 may predefine __big_endian__ and
> __little_endian__ macros.  This leads to spurious warnings like:
>   gcc.dg/sso/memcpy-1.c:7: warning: "__little_endian__" redefined
>
> Fix by renaming the macros in the test.
>
> Ok for trunk?

OK

> gcc/testsuite/ChangeLog:
>
> * gcc.dg/sso/memcpy-1.c (__big_endian__, __little_endian__):
> Rename macros to avoid conflicts with predefined ones.
>
> Signed-off-by: Dimitar Dimitrov 
> ---
>  gcc/testsuite/gcc.dg/sso/memcpy-1.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/sso/memcpy-1.c 
> b/gcc/testsuite/gcc.dg/sso/memcpy-1.c
> index b4e1c8786d9..0dea955cbaf 100644
> --- a/gcc/testsuite/gcc.dg/sso/memcpy-1.c
> +++ b/gcc/testsuite/gcc.dg/sso/memcpy-1.c
> @@ -3,20 +3,20 @@
>  typedef unsigned char uint8_t;
>  typedef unsigned int uint32_t;
>
> -#define __big_endian__ scalar_storage_order("big-endian")
> -#define __little_endian__ scalar_storage_order("little-endian")
> +#define __big_endian_attr__ scalar_storage_order("big-endian")
> +#define __little_endian_attr__ scalar_storage_order("little-endian")
>
>  typedef union
>  {
>uint32_t val;
>uint8_t v[4];
> -} __attribute__((__big_endian__)) upal_u32be_t;
> +} __attribute__((__big_endian_attr__)) upal_u32be_t;
>
>  typedef union
>  {
>uint32_t val;
>uint8_t v[4];
> -} __attribute__((__little_endian__)) upal_u32le_t;
> +} __attribute__((__little_endian_attr__)) upal_u32le_t;
>
>  static inline uint32_t native_to_big_endian(uint32_t t)
>  {
> --
> 2.36.1
>


Re: [PATCH] testsuite: Remove reliance on argc in lto/pr101868_0.c

2022-06-23 Thread Richard Biener via Gcc-patches
On Thu, Jun 23, 2022 at 11:23 PM Dimitar Dimitrov  wrote:
>
> Some embedded targets do not pass any argv arguments.  When argc is
> zero, this causes spurious failures for lto/pr101868_0.c.  Fix by
> following the strategy in r0-114701-g2c49569ecea56d.  Use a volatile
> variable instead of argc to inject a runtime value into the test.
>
> I validated the following:
>   - No changes in testresults for x86_64-pc-linux-gnu.
>   - The spurious failures are fixed for PRU target.
>   - lto/pr101868_0.c still fails on x86_64-pc-linux-gnu, if
> the PR/101868 fix (r12-2254-gfedcf3c476aff7) is reverted.
>
> Ok for trunk?

OK

> PR tree-optimization/101868
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/lto/pr101868_0.c (zero): New volatile variable.
> (main): Use it instead of argc.
>
> Signed-off-by: Dimitar Dimitrov 
> ---
>  gcc/testsuite/gcc.dg/lto/pr101868_0.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/lto/pr101868_0.c 
> b/gcc/testsuite/gcc.dg/lto/pr101868_0.c
> index c84d19b0267..03124308267 100644
> --- a/gcc/testsuite/gcc.dg/lto/pr101868_0.c
> +++ b/gcc/testsuite/gcc.dg/lto/pr101868_0.c
> @@ -22,12 +22,13 @@ repro(VALUE dummy, VALUE hash)
>
>  static VALUE (*that)(VALUE dummy, VALUE hash) = repro;
>
> +volatile int zero = 0;
> +
>  int
>  main(int argc, char **argv)
>  {
> -argc--;
> -that(0, argc);
> +that(0, zero);
>
> -rb_check_type(argc, argc);
> +rb_check_type(zero, zero);
>
>  }
> --
> 2.36.1
>


Re: [PATCH] Introduce -nolibstdc++ option

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Alexandre Oliva  wrote:

> Here's the patch.  Regstrapped on x86_64-linux-gnu, also tested with a
> cross to aarch64-rtems6.  Ok to install?

> Introduce -nostdlib++ option

Uhh, I went ahead and installed this.  The earlier patch was approved if
nobody objected, and so, having overcome the objection to the option
spelling, it ended up in my "approved" patchset.

In case there are objections to it, please let me know, and I'll revert
it promptly, but I guess it makes little sense to revert it on the odd
change that someone does.  Thanks for your understanding.

-- 
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.  Ask me about 


Re: [PATCH] libstdc++-v3: check for openat

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Alexandre Oliva  wrote:

>   * aclocal.m4, configure, config.h.in: Rebuilt.

Dropped aclocal.m4 for the checkin, thanks to the ChangeLog checker.

-- 
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.  Ask me about 


Re: [PATCH] aarch64: testsuite: symbol-range compile only

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Alexandre Oliva  wrote:

> for  gcc/testsuite/ChangeLog

>   * doc/sourcebuild.exp (Environment attributes): Document it.

Fixed two problems in the above, thanks for the ChangeLog checker.  It's
.texi, and it belongs in gcc/ChangeLog.

-- 
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.  Ask me about 


Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Alexandre Oliva  wrote:

>   * 
> testsuite/experimental/filesystem/iterators/recursive_directory_itreator.cc

s/itreator/iterator/ for the checkin, thanks to the ChangeLog checker :-)

-- 
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.  Ask me about 


[PATCH v6, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]

2022-06-23 Thread HAO CHEN GUI via Gcc-patches
Hi,
  This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.

  This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate xs[min/max]dp on all
platforms.

  Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.

ChangeLog
2022-06-24 Haochen Gui 

gcc/
PR target/103605
* config/rs6000/rs6000.md (FMINMAX): New.
(minmax_op): New.
(f3): New pattern by UNSPEC_FMAX and UNSPEC_FMIN.
* config/rs6000/rs6000-builtins.def (__builtin_vsx_xsmaxdp): Set
pattern to fmaxdf3.
(__builtin_vsx_xsmindp): Set pattern to fmindf3.

gcc/testsuite/
PR target/103605
* gcc.dg/powerpc/pr103605.c: New.


patch.diff
diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index f4a9f24bcc5..8b735493b40 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -1613,10 +1613,10 @@
 XSCVSPDP vsx_xscvspdp {}

   const double __builtin_vsx_xsmaxdp (double, double);
-XSMAXDP smaxdf3 {}
+XSMAXDP fmaxdf3 {}

   const double __builtin_vsx_xsmindp (double, double);
-XSMINDP smindf3 {}
+XSMINDP fmindf3 {}

   const double __builtin_vsx_xsrdpi (double);
 XSRDPI vsx_xsrdpi {}
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index bf85baa5370..ae0dd98f0f9 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -158,6 +158,8 @@ (define_c_enum "unspec"
UNSPEC_HASHCHK
UNSPEC_XXSPLTIDP_CONST
UNSPEC_XXSPLTIW_CONST
+   UNSPEC_FMAX
+   UNSPEC_FMIN
   ])

 ;;
@@ -5341,6 +5343,22 @@ (define_insn_and_split "*s3_fpr"
   DONE;
 })

+
+(define_int_iterator FMINMAX [UNSPEC_FMAX UNSPEC_FMIN])
+
+(define_int_attr  minmax_op [(UNSPEC_FMAX "max")
+(UNSPEC_FMIN "min")])
+
+(define_insn "f3"
+  [(set (match_operand:SFDF 0 "vsx_register_operand" "=wa")
+   (unspec:SFDF [(match_operand:SFDF 1 "vsx_register_operand" "wa")
+ (match_operand:SFDF 2 "vsx_register_operand" "wa")]
+FMINMAX))]
+  "TARGET_VSX && !flag_finite_math_only"
+  "xsdp %x0,%x1,%x2"
+  [(set_attr "type" "fp")]
+)
+
 (define_expand "movcc"
[(set (match_operand:GPR 0 "gpc_reg_operand")
 (if_then_else:GPR (match_operand 1 "comparison_operator")
diff --git a/gcc/testsuite/gcc.target/powerpc/pr103605.c 
b/gcc/testsuite/gcc.target/powerpc/pr103605.c
new file mode 100644
index 000..1c938d40e61
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr103605.c
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-O2 -mvsx" } */
+/* { dg-final { scan-assembler-times {\mxsmaxdp\M} 3 } } */
+/* { dg-final { scan-assembler-times {\mxsmindp\M} 3 } } */
+
+#include 
+
+double test1 (double d0, double d1)
+{
+  return fmin (d0, d1);
+}
+
+float test2 (float d0, float d1)
+{
+  return fmin (d0, d1);
+}
+
+double test3 (double d0, double d1)
+{
+  return fmax (d0, d1);
+}
+
+float test4 (float d0, float d1)
+{
+  return fmax (d0, d1);
+}
+
+double test5 (double d0, double d1)
+{
+  return __builtin_vsx_xsmindp (d0, d1);
+}
+
+double test6 (double d0, double d1)
+{
+  return __builtin_vsx_xsmaxdp (d0, d1);
+}


Re: [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

2022-06-23 Thread Kewen.Lin via Gcc-patches
Hi Segher,

Thanks for the comments.

on 2022/6/24 03:06, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
>> As PR103353 shows, we may want to continue to expand a MMA built-in
>> function like a normal function, even if we have already emitted
>> error messages about some missing required conditions.  As shown in
>> that PR, without one explicit mov optab on OOmode provided, it would
>> call emit_move_insn recursively.
> 
> First off: lxvp is a VSX insn, not an MMA insn.  So please don't call it
> that -- this confusion is what presumably caused the problem here, so it
> would be good to root it out :-)
> 

I guess the "it" in "don't call it call" is for "MMA built-in function"?
It comes from the current code:

;   mma  Needs special handling for MMA
;   quad MMA instruction using a register quad as an input operand
;   pair MMA instruction using a register pair as an input operand

  v256 __builtin_vsx_lxvp (unsigned long, const v256 *);
LXVP nothing {mma}

  void __builtin_vsx_stxvp (v256, unsigned long, const v256 *);
STXVP nothing {mma,pair}

...

>> +  /* Opaque modes are only expected to be available when MMA is supported,
> 
> Why do people expect that?  It is completely wrong.  The name "opaque"
> itself already says this is not just for MMA, but perhaps more
> importantly, it is a basic VSX insn, doesn't touch any MMA resources,
> and is useful in other contexts as well.
> 

... The above statements are also based on current code, for now, the
related things like built-in functions, mov optab, hard_regno_ok etc.
for these two modes are guarded by TARGET_MMA.

I think I get your points here, you want to separate these opaque
modes from MMA since the underlying lxvp/stxvp are not MMA specific,
so those related things (bifs, mov optabs etc.) are not necessarily
guarded under MMA.

> So this needs some bigger surgery.

Yes, Peter may have more comments on this.

BR,
Kewen


Re: [PATCH] testsuite: Add new target check for no_alignment_constraints

2022-06-23 Thread Andrew Pinski via Gcc-patches
On Thu, Jun 23, 2022 at 2:24 PM Dimitar Dimitrov  wrote:
>
> A few testcases were marked for avr target, which has no alignment
> requirements.  But those tests in fact should filter for any
> target having __BIGGEST_ALIGNMENT__=1.
>
> A new effective target check is introduced: no_alignment_constraints.
> It checks whether __BIGGEST_ALIGNMENT__ is declared as 1.
>
> Alternative names I considered for the new macro are:
>   - !natural_alignment_16
>   - biggest_alignment_1
>
> This change fixes the testsuite cases for PRU target.  I don't have
> environment to test mm32c and cris targets, which also declare
> __BIGGEST_ALIGNMENT__=1.
>
> It was regression-tested on x86_64-pc-linux-gnu.
>
> The following two existing macros were considered, but they check for
> subtly different target behaviour:
>  1. non_strict_align
> If true, non-aligned access is permitted. But it also allows
> variables to be naturally aligned, which is not true for
> no_alignment_constraints.
>
>  2. default_packed
> Whether structures are packed by default is not necessarily
> the same as lacking constraints for any variable alignment.
> For example, BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN
> could be defined for a target.
>
> Ok for trunk?

How is no_alignment_constraints different from default_packed? I
suspect they have the same effect really.

Thanks,
Andrew

>
> Signed-off-by: Dimitar Dimitrov 
> ---
>  gcc/testsuite/c-c++-common/Wcast-align.c |  4 ++--
>  gcc/testsuite/gcc.dg/c11-align-4.c   |  2 +-
>  gcc/testsuite/gcc.dg/strlenopt-10.c  |  6 +++---
>  gcc/testsuite/gcc.dg/strlenopt-11.c  | 14 +++---
>  gcc/testsuite/gcc.dg/strlenopt-13.c  | 16 
>  gcc/testsuite/lib/target-supports.exp| 13 +
>  6 files changed, 34 insertions(+), 21 deletions(-)
>
> diff --git a/gcc/testsuite/c-c++-common/Wcast-align.c 
> b/gcc/testsuite/c-c++-common/Wcast-align.c
> index c296c7fd249..1087b10fd99 100644
> --- a/gcc/testsuite/c-c++-common/Wcast-align.c
> +++ b/gcc/testsuite/c-c++-common/Wcast-align.c
> @@ -16,8 +16,8 @@ struct t { double x; } *q;
>  void
>  foo (void)
>  {
> -  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" } */
> -  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" } */
> +  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" "" { target { ! no_alignment_constraints } } } */
> +  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of 
> target type" "" { target { ! no_alignment_constraints } } } */
>(long long *) p;  /* { dg-bogus "alignment" } */
>(double *) q; /* { dg-bogus "alignment" } */
>  }
> diff --git a/gcc/testsuite/gcc.dg/c11-align-4.c 
> b/gcc/testsuite/gcc.dg/c11-align-4.c
> index 57f93ff05fc..eb9071b9149 100644
> --- a/gcc/testsuite/gcc.dg/c11-align-4.c
> +++ b/gcc/testsuite/gcc.dg/c11-align-4.c
> @@ -2,7 +2,7 @@
> are at least some alignment constraints).  */
>  /* { dg-do compile } */
>  /* { dg-options "-std=c11 -pedantic-errors" } */
> -/* { dg-skip-if "no alignment constraints" { "avr-*-*" } } */
> +/* { dg-skip-if "no alignment constraints" { no_alignment_constraints } } */
>
>  #include 
>
> diff --git a/gcc/testsuite/gcc.dg/strlenopt-10.c 
> b/gcc/testsuite/gcc.dg/strlenopt-10.c
> index ce959c34a80..6e2c2597b27 100644
> --- a/gcc/testsuite/gcc.dg/strlenopt-10.c
> +++ b/gcc/testsuite/gcc.dg/strlenopt-10.c
> @@ -70,10 +70,10 @@ main ()
>  }
>
>  /* { dg-final { scan-tree-dump-times "strlen \\(" 2 "strlen1" } } */
> -/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
> +/* Some targets have BIGGEST_ALIGNMENT 8-bits, allowing 
> fold_builtin_memory_op
> to expand the memcpy call at the end of fn2.  */
> -/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen1" { target { ! 
> avr-*-* } } } } */
> -/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { 
> avr-*-* } } } } */
> +/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen1" { target { ! 
> no_alignment_constraints } } } } */
> +/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { 
> no_alignment_constraints} } } } */
>  /* { dg-final { scan-tree-dump-times "strcpy \\(" 0 "strlen1" } } */
>  /* { dg-final { scan-tree-dump-times "strcat \\(" 0 "strlen1" } } */
>  /* { dg-final { scan-tree-dump-times "strchr \\(" 0 "strlen1" } } */
> diff --git a/gcc/testsuite/gcc.dg/strlenopt-11.c 
> b/gcc/testsuite/gcc.dg/strlenopt-11.c
> index abd9faebed6..952de0730f1 100644
> --- a/gcc/testsuite/gcc.dg/strlenopt-11.c
> +++ b/gcc/testsuite/gcc.dg/strlenopt-11.c
> @@ -59,17 +59,17 @@ main ()
>  }
>
>  /* { dg-final { scan-tree-dump-times "strlen \\(" 3 "strlen1" } } */
> -/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
> +/* Some targets have BIGGEST_ALIGNMENT 8-bits, allowing 
> fold_builtin_memory_op
> to expand the memcpy call at the end of fn1.  */
> -/* { d

[PATCH] or1k: gcc: Add naked attribute

2022-06-23 Thread jesus via Gcc-patches
Hello.

I have added support for naked functions on the OpenRISC 1200 target
it practically inhibits the generation of a function epilogue and
prologue and will warn about variables that might use the stack (to
prevent unintended code being generated).

As well added a table for attributes where the attribute can only
be applied functions, like in the other backends.

gcc/ChangeLog:

* config/or1k/or1k.cc (or1k_handle_naked_attribute):
(has_func_attr): Likewise.
(callee_saved_regno_p): Likewise.
(or1k_save_reg): Likewise.
(or1k_restore_reg): Likewise.
(or1k_expand_prologue): Likewise.
(or1k_expand_epilogue): Likewise.
(or1k_frame_pointer_required): Likewise.
(TARGET_ATTRIBUTE_TABLE): Define.

---
 gcc/config/or1k/or1k.cc | 58 ++---
 1 file changed, 55 insertions(+), 3 deletions(-)

diff --git a/gcc/config/or1k/or1k.cc b/gcc/config/or1k/or1k.cc
index da2f59062ba..c41ac5ab099 100644
--- a/gcc/config/or1k/or1k.cc
+++ b/gcc/config/or1k/or1k.cc
@@ -79,6 +79,41 @@ struct GTY(()) machine_function
   rtx_insn *set_mcount_arg_insn;
 };

+static tree
+or1k_handle_naked_attribute(tree *node, tree name ATTRIBUTE_UNUSED,
+tree args ATTRIBUTE_UNUSED,
+int flags ATTRIBUTE_UNUSED, bool *no_add_attrs)
+{
+  gcc_assert(DECL_P(*node));
+
+  if (TREE_CODE(*node) != FUNCTION_DECL)
+  {
+warning(OPT_Wattributes, "%qE attribute only applies to functions",
+name);
+*no_add_attrs = true;
+  }
+  return NULL_TREE;
+}
+
+static const struct attribute_spec or1k_attribute_table[] = {
+  { "naked", 0, 0, true, false, false, false,
+or1k_handle_naked_attribute, NULL },
+
+  /* End element.  */
+  { NULL, 0, 0, false, false, false, false, NULL, NULL }
+};
+
+/* Returns true if the provided function has the specified attribute.  */
+
+static inline bool
+has_func_attr(const_tree decl, const char *func_attr)
+{
+  if (decl == NULL_TREE)
+decl = current_function_decl;
+
+  return lookup_attribute(func_attr, DECL_ATTRIBUTES(decl)) != NULL_TREE;
+}
+
 /* Zero initialization is OK for all current fields.  */

 static struct machine_function *
@@ -103,6 +138,10 @@ or1k_option_override (void)
 static bool
 callee_saved_regno_p (int regno)
 {
+  /* Naked functions do not save anything, so let's say NO! */
+  if (has_func_attr(NULL_TREE, "naked"))
+return false;
+
   /* Check call-saved registers.  */
   if (!call_used_or_fixed_reg_p (regno) && df_regs_ever_live_p (regno))
 return true;
@@ -185,6 +224,9 @@ or1k_compute_frame_layout (void)
 static void
 or1k_save_reg (int regno, HOST_WIDE_INT offset)
 {
+  if (has_func_attr(NULL_TREE, "naked"))
+warning(0, "stack usage on naked function %s", current_function_name());
+
   rtx reg = gen_rtx_REG (Pmode, regno);
   rtx mem = gen_frame_mem (SImode, plus_constant (Pmode, stack_pointer_rtx,
  offset));
@@ -198,6 +240,9 @@ or1k_save_reg (int regno, HOST_WIDE_INT offset)
 static rtx
 or1k_restore_reg (int regno, HOST_WIDE_INT offset, rtx cfa_restores)
 {
+  if (has_func_attr(NULL_TREE, "naked"))
+warning(0, "stack usage on naked function %s", current_function_name());
+
   rtx reg = gen_rtx_REG (Pmode, regno);
   rtx mem = gen_frame_mem (SImode, plus_constant (Pmode, stack_pointer_rtx,
  offset));
@@ -217,8 +262,8 @@ or1k_expand_prologue (void)
   if (flag_stack_usage_info)
 current_function_static_stack_size = -sp_offset;

-  /* Early exit for frameless functions.  */
-  if (sp_offset == 0)
+  /* Early exit for frameless functions */
+  if (sp_offset == 0 || has_func_attr(NULL_TREE, "naked"))
 goto fini;

   /* Adjust the stack pointer.  For large stack offsets we will
@@ -325,7 +370,7 @@ or1k_expand_epilogue (void)
   rtx insn, cfa_restores = NULL;

   sp_offset = cfun->machine->total_size;
-  if (sp_offset == 0)
+  if (sp_offset == 0 || has_func_attr(NULL_TREE, "naked"))
 return;

   reg_offset = cfun->machine->local_vars_size + cfun->machine->args_size;
@@ -509,6 +554,10 @@ or1k_return_addr (int, rtx frame)
 static bool
 or1k_frame_pointer_required ()
 {
+  /* Frame pointer is not required for naked functions */
+  if (has_func_attr(NULL_TREE, "naked"))
+return false;
+
   /* ??? While IRA checks accesses_prior_frames, reload does not.
  We do want the frame pointer for this case.  */
   return (crtl->accesses_prior_frames);
@@ -2212,6 +2261,9 @@ or1k_output_mi_thunk (FILE *file, tree thunk_fndecl,
 #undef  TARGET_HAVE_SPECULATION_SAFE_VALUE
 #define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed

+#undef  TARGET_ATTRIBUTE_TABLE
+#define TARGET_ATTRIBUTE_TABLE or1k_attribute_table
+
 /* Calling Conventions.  */
 #undef  TARGET_FUNCTION_VALUE
 #define TARGET_FUNCTION_VALUE or1k_function_value
-- 
2.30.2


[PATCH] testsuite: Add new target check for no_alignment_constraints

2022-06-23 Thread Dimitar Dimitrov
A few testcases were marked for avr target, which has no alignment
requirements.  But those tests in fact should filter for any
target having __BIGGEST_ALIGNMENT__=1.

A new effective target check is introduced: no_alignment_constraints.
It checks whether __BIGGEST_ALIGNMENT__ is declared as 1.

Alternative names I considered for the new macro are:
  - !natural_alignment_16
  - biggest_alignment_1

This change fixes the testsuite cases for PRU target.  I don't have
environment to test mm32c and cris targets, which also declare
__BIGGEST_ALIGNMENT__=1.

It was regression-tested on x86_64-pc-linux-gnu.

The following two existing macros were considered, but they check for
subtly different target behaviour:
 1. non_strict_align
If true, non-aligned access is permitted. But it also allows
variables to be naturally aligned, which is not true for
no_alignment_constraints.

 2. default_packed
Whether structures are packed by default is not necessarily
the same as lacking constraints for any variable alignment.
For example, BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN
could be defined for a target.

Ok for trunk?

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/c-c++-common/Wcast-align.c |  4 ++--
 gcc/testsuite/gcc.dg/c11-align-4.c   |  2 +-
 gcc/testsuite/gcc.dg/strlenopt-10.c  |  6 +++---
 gcc/testsuite/gcc.dg/strlenopt-11.c  | 14 +++---
 gcc/testsuite/gcc.dg/strlenopt-13.c  | 16 
 gcc/testsuite/lib/target-supports.exp| 13 +
 6 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/Wcast-align.c 
b/gcc/testsuite/c-c++-common/Wcast-align.c
index c296c7fd249..1087b10fd99 100644
--- a/gcc/testsuite/c-c++-common/Wcast-align.c
+++ b/gcc/testsuite/c-c++-common/Wcast-align.c
@@ -16,8 +16,8 @@ struct t { double x; } *q;
 void
 foo (void)
 {
-  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of target 
type" } */
-  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of target 
type" } */
+  y = (c *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of target 
type" "" { target { ! no_alignment_constraints } } } */
+  z = (d *) x;  /* { dg-warning "7:cast \[^\n\r]* required alignment of target 
type" "" { target { ! no_alignment_constraints } } } */
   (long long *) p;  /* { dg-bogus "alignment" } */
   (double *) q; /* { dg-bogus "alignment" } */
 }
diff --git a/gcc/testsuite/gcc.dg/c11-align-4.c 
b/gcc/testsuite/gcc.dg/c11-align-4.c
index 57f93ff05fc..eb9071b9149 100644
--- a/gcc/testsuite/gcc.dg/c11-align-4.c
+++ b/gcc/testsuite/gcc.dg/c11-align-4.c
@@ -2,7 +2,7 @@
are at least some alignment constraints).  */
 /* { dg-do compile } */
 /* { dg-options "-std=c11 -pedantic-errors" } */
-/* { dg-skip-if "no alignment constraints" { "avr-*-*" } } */
+/* { dg-skip-if "no alignment constraints" { no_alignment_constraints } } */
 
 #include 
 
diff --git a/gcc/testsuite/gcc.dg/strlenopt-10.c 
b/gcc/testsuite/gcc.dg/strlenopt-10.c
index ce959c34a80..6e2c2597b27 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-10.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-10.c
@@ -70,10 +70,10 @@ main ()
 }
 
 /* { dg-final { scan-tree-dump-times "strlen \\(" 2 "strlen1" } } */
-/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
+/* Some targets have BIGGEST_ALIGNMENT 8-bits, allowing fold_builtin_memory_op
to expand the memcpy call at the end of fn2.  */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen1" { target { ! 
avr-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { 
avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 8 "strlen1" { target { ! 
no_alignment_constraints } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { 
no_alignment_constraints} } } } */
 /* { dg-final { scan-tree-dump-times "strcpy \\(" 0 "strlen1" } } */
 /* { dg-final { scan-tree-dump-times "strcat \\(" 0 "strlen1" } } */
 /* { dg-final { scan-tree-dump-times "strchr \\(" 0 "strlen1" } } */
diff --git a/gcc/testsuite/gcc.dg/strlenopt-11.c 
b/gcc/testsuite/gcc.dg/strlenopt-11.c
index abd9faebed6..952de0730f1 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-11.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-11.c
@@ -59,17 +59,17 @@ main ()
 }
 
 /* { dg-final { scan-tree-dump-times "strlen \\(" 3 "strlen1" } } */
-/* avr has BIGGEST_ALIGNMENT 8, allowing fold_builtin_memory_op
+/* Some targets have BIGGEST_ALIGNMENT 8-bits, allowing fold_builtin_memory_op
to expand the memcpy call at the end of fn1.  */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { ! 
avr-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 6 "strlen1" { target { 
avr-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 7 "strlen1" { target { ! 
no_alignment_constraints } } } } */
+/* { dg-final { scan-tree-dump-times "memcpy \\(" 6 "strlen1" { target { 
no_alignment_constraints }

[PATCH] testsuite: Handle default_packed for gcc.dg/builtin-object-size-20.c

2022-06-23 Thread Dimitar Dimitrov
The gcc.dg/builtin-object-size-20.c test case assumes that the target
inserts padding between structure members.  Obviously it fails for
targets which pack structures by default.

Split the cases into two tests, so that the ones requiring structure
padding can be skipped for default_packed targets.

Ok for trunk?

gcc/testsuite/ChangeLog:

* gcc.dg/builtin-object-size-20.c: Remove cases which
work on default_packed targets.
* gcc.dg/builtin-object-size-22.c: New test with the cases
removed above.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/builtin-object-size-20.c | 64 +--
 gcc/testsuite/gcc.dg/builtin-object-size-22.c | 79 +++
 2 files changed, 81 insertions(+), 62 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-22.c

diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-20.c 
b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
index bed973c2c77..f40e3dcc1a9 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-20.c
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
@@ -1,7 +1,8 @@
 /* PR middle-end/92815 - spurious -Wstringop-overflow writing into
a flexible array of an extern struct
{ dg-do compile }
-   { dg-options "-O -Wall -fdump-tree-optimized" } */
+   { dg-options "-O -Wall -fdump-tree-optimized" }
+   { dg-skip-if "test assumes that structs have padding" { default_packed } } 
*/
 
 #define ASSERT(expr) ((expr) ? (void)0 : fail (__LINE__))
 #define bos0(expr) __builtin_object_size (expr, 1)
@@ -18,44 +19,6 @@ typedef __SIZE_TYPE__  size_t;
 extern void fail (int);
 
 
-/* Verify sizes of a struct with a flexible array member and no padding.  */
-
-struct ACX { char n, a[]; };
-
-struct ACX ac0 = { };
-struct ACX ac1 = { 1, { 1 } };
-struct ACX ac2 = { 2, { 1, 2 } };
-struct ACX ac3 = { 3, { 1, 2, 3 } };
-
-extern struct ACX eacx;
-
-void facx (void)
-{
-  ASSERT (bos0 (&ac0) == sizeof ac0);
-  ASSERT (bos0 (&ac1) == 2);
-  ASSERT (bos0 (&ac2) == 3);
-  ASSERT (bos0 (&ac3) == 4);
-  ASSERT (bos0 (&eacx) == (size_t)-1);
-
-  ASSERT (bos1 (&ac0) == sizeof ac0);
-  ASSERT (bos1 (&ac1) == 2);
-  ASSERT (bos1 (&ac2) == 3);
-  ASSERT (bos1 (&ac3) == 4);
-  ASSERT (bos1 (&eacx) == (size_t)-1);
-
-  ASSERT (bos2 (&ac0) == sizeof ac0);
-  ASSERT (bos2 (&ac1) == 2);
-  ASSERT (bos2 (&ac2) == 3);
-  ASSERT (bos2 (&ac3) == 4);
-  ASSERT (bos2 (&eacx) == sizeof eacx);
-
-  ASSERT (bos3 (&ac0) == sizeof ac0);
-  ASSERT (bos3 (&ac1) == 2);
-  ASSERT (bos3 (&ac2) == 3);
-  ASSERT (bos3 (&ac3) == 4);
-  ASSERT (bos3 (&eacx) == sizeof eacx);
-}
-
 
 
 /* Verify sizes of a struct with a flexible array member and 1 byte
@@ -289,27 +252,4 @@ void fai64cx (void)
   ASSERT (bos3 (&eai64cx) == sizeof eai64cx);
 }
 
-
-/* Also verify sizes of a struct with a zero length array member.  */
-
-struct A0C0 { char n, a[0]; };
-
-struct A0C0 a0c0 = { };
-extern struct A0C0 ea0c0;
-
-void fa0c0 (void)
-{
-  ASSERT (bos0 (&a0c0) == sizeof a0c0);
-  ASSERT (bos0 (&ea0c0) == sizeof ea0c0);
-
-  ASSERT (bos1 (&a0c0) == sizeof a0c0);
-  ASSERT (bos1 (&a0c0) == sizeof ea0c0);
-
-  ASSERT (bos2 (&a0c0) == sizeof a0c0);
-  ASSERT (bos2 (&a0c0) == sizeof ea0c0);
-
-  ASSERT (bos3 (&a0c0) == sizeof a0c0);
-  ASSERT (bos3 (&a0c0) == sizeof ea0c0);
-}
-
 /* { dg-final { scan-tree-dump-not "fail" "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-22.c 
b/gcc/testsuite/gcc.dg/builtin-object-size-22.c
new file mode 100644
index 000..1e55229c949
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-22.c
@@ -0,0 +1,79 @@
+/* PR middle-end/92815 - a variant of gcc.dg/builtin-object-size-20.c
+   prepared for all targets, irregardless if they pack or not
+   the structs by default.
+   { dg-do compile }
+   { dg-options "-O -Wall -fdump-tree-optimized" } */
+
+#define ASSERT(expr) ((expr) ? (void)0 : fail (__LINE__))
+#define bos0(expr) __builtin_object_size (expr, 1)
+#define bos1(expr) __builtin_object_size (expr, 1)
+#define bos2(expr) __builtin_object_size (expr, 2)
+#define bos3(expr) __builtin_object_size (expr, 3)
+
+typedef __SIZE_TYPE__  size_t;
+
+
+extern void fail (int);
+
+
+/* Verify sizes of a struct with a flexible array member and no padding.  */
+
+struct ACX { char n, a[]; };
+
+struct ACX ac0 = { };
+struct ACX ac1 = { 1, { 1 } };
+struct ACX ac2 = { 2, { 1, 2 } };
+struct ACX ac3 = { 3, { 1, 2, 3 } };
+
+extern struct ACX eacx;
+
+void facx (void)
+{
+  ASSERT (bos0 (&ac0) == sizeof ac0);
+  ASSERT (bos0 (&ac1) == 2);
+  ASSERT (bos0 (&ac2) == 3);
+  ASSERT (bos0 (&ac3) == 4);
+  ASSERT (bos0 (&eacx) == (size_t)-1);
+
+  ASSERT (bos1 (&ac0) == sizeof ac0);
+  ASSERT (bos1 (&ac1) == 2);
+  ASSERT (bos1 (&ac2) == 3);
+  ASSERT (bos1 (&ac3) == 4);
+  ASSERT (bos1 (&eacx) == (size_t)-1);
+
+  ASSERT (bos2 (&ac0) == sizeof ac0);
+  ASSERT (bos2 (&ac1) == 2);
+  ASSERT (bos2 (&ac2) == 3);
+  ASSERT (bos2 (&ac3) == 4);
+  ASSERT (bos2 (&eacx) == sizeof eacx);
+
+  ASSERT (bos3 (&ac0) == sizeo

[PATCH] testsuite: Rename test-defined macros

2022-06-23 Thread Dimitar Dimitrov
Epiphany, PRU, ARC and NDS32 may predefine __big_endian__ and
__little_endian__ macros.  This leads to spurious warnings like:
  gcc.dg/sso/memcpy-1.c:7: warning: "__little_endian__" redefined

Fix by renaming the macros in the test.

Ok for trunk?

gcc/testsuite/ChangeLog:

* gcc.dg/sso/memcpy-1.c (__big_endian__, __little_endian__):
Rename macros to avoid conflicts with predefined ones.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/sso/memcpy-1.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/sso/memcpy-1.c 
b/gcc/testsuite/gcc.dg/sso/memcpy-1.c
index b4e1c8786d9..0dea955cbaf 100644
--- a/gcc/testsuite/gcc.dg/sso/memcpy-1.c
+++ b/gcc/testsuite/gcc.dg/sso/memcpy-1.c
@@ -3,20 +3,20 @@
 typedef unsigned char uint8_t;
 typedef unsigned int uint32_t;
 
-#define __big_endian__ scalar_storage_order("big-endian")
-#define __little_endian__ scalar_storage_order("little-endian")
+#define __big_endian_attr__ scalar_storage_order("big-endian")
+#define __little_endian_attr__ scalar_storage_order("little-endian")
 
 typedef union
 {
   uint32_t val;
   uint8_t v[4];
-} __attribute__((__big_endian__)) upal_u32be_t;
+} __attribute__((__big_endian_attr__)) upal_u32be_t;
 
 typedef union
 {
   uint32_t val;
   uint8_t v[4];
-} __attribute__((__little_endian__)) upal_u32le_t;
+} __attribute__((__little_endian_attr__)) upal_u32le_t;
 
 static inline uint32_t native_to_big_endian(uint32_t t)
 {
-- 
2.36.1



[PATCH] testsuite: Remove reliance on argc in lto/pr101868_0.c

2022-06-23 Thread Dimitar Dimitrov
Some embedded targets do not pass any argv arguments.  When argc is
zero, this causes spurious failures for lto/pr101868_0.c.  Fix by
following the strategy in r0-114701-g2c49569ecea56d.  Use a volatile
variable instead of argc to inject a runtime value into the test.

I validated the following:
  - No changes in testresults for x86_64-pc-linux-gnu.
  - The spurious failures are fixed for PRU target.
  - lto/pr101868_0.c still fails on x86_64-pc-linux-gnu, if
the PR/101868 fix (r12-2254-gfedcf3c476aff7) is reverted.

Ok for trunk?

PR tree-optimization/101868

gcc/testsuite/ChangeLog:

* gcc.dg/lto/pr101868_0.c (zero): New volatile variable.
(main): Use it instead of argc.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/lto/pr101868_0.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/lto/pr101868_0.c 
b/gcc/testsuite/gcc.dg/lto/pr101868_0.c
index c84d19b0267..03124308267 100644
--- a/gcc/testsuite/gcc.dg/lto/pr101868_0.c
+++ b/gcc/testsuite/gcc.dg/lto/pr101868_0.c
@@ -22,12 +22,13 @@ repro(VALUE dummy, VALUE hash)
 
 static VALUE (*that)(VALUE dummy, VALUE hash) = repro;
 
+volatile int zero = 0;
+
 int
 main(int argc, char **argv)
 {
-argc--;
-that(0, argc);
+that(0, zero);
 
-rb_check_type(argc, argc);
+rb_check_type(zero, zero);
 
 }
-- 
2.36.1



[PATCH] testsuite: Skip btf-bitfields-1.c if int is less than 32-bits

2022-06-23 Thread Dimitar Dimitrov
This test spuriously fails on AVR with:
   error: width of 'bitfield_c' exceeds its type

8-bit and 16-bit microcontrollers do not seem to be the target audience
for BTF file format.  So the least intrusive fix is to simply skip the
test for them.

Ok for trunk?

gcc/testsuite/ChangeLog:

* gcc.dg/debug/btf/btf-bitfields-1.c: Skip if int is less than
32-bits.

CC: Jose E. Marchesi 
Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
index 4cb7ee84f83..793b4c8db82 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
@@ -10,6 +10,7 @@
 
 /* { dg-do compile )  */
 /* { dg-options "-O0 -gbtf -dA" } */
+/* { dg-require-effective-target int32plus } */
 
 /* { dg-final { scan-assembler-times "\[\t \]0x8404\[\t 
\]+\[^\n\]*btt_info" 1 } } */
 
-- 
2.36.1



[PATCH] testsuite: Adjust btf-bitfields-1.c for default_packed

2022-06-23 Thread Dimitar Dimitrov
If target packs structures by default, the bitfield offset which the
tests validates must be adjusted to not include padding.

Ok for trunk?

gcc/testsuite/ChangeLog:

* gcc.dg/debug/btf/btf-bitfields-1.c: Adjust the checked offsets
for targets which pack structures by default.

CC: Jose E. Marchesi 
Signed-off-by: Dimitar Dimitrov 
---
 gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
index c6bf52130dc..4cb7ee84f83 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-1.c
@@ -5,7 +5,8 @@
  (bit_size << 24) | bit_offset
  - (0xa  << 24) | 0x20
  - (0x7  << 24) | 0x2a
- - (0x13 << 24) | 0x40 - note that this is aligned to 0x40.  */
+ - (0x13 << 24) | 0x40 - note that this is aligned to 0x40.
+ - (0x13 << 24) | 0x31 - in case structures are packed.  */
 
 /* { dg-do compile )  */
 /* { dg-options "-O0 -gbtf -dA" } */
@@ -14,7 +15,8 @@
 
 /* { dg-final { scan-assembler-times "\[\t \]0xa20\[\t 
\]+\[^\n\]*btm_offset" 1 } } */
 /* { dg-final { scan-assembler-times "\[\t \]0x72a\[\t 
\]+\[^\n\]*btm_offset" 1 } } */
-/* { dg-final { scan-assembler-times "\[\t \]0x1340\[\t 
\]+\[^\n\]*btm_offset" 1 } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x1340\[\t 
\]+\[^\n\]*btm_offset" 1 { target { ! default_packed } } } } */
+/* { dg-final { scan-assembler-times "\[\t \]0x1331\[\t 
\]+\[^\n\]*btm_offset" 1 { target { default_packed } } } } */
 
 struct bitt {
   int a;
-- 
2.36.1



Re: [PATCH] fortran, libgfortran: Avoid using libquadmath for glibc 2.26+

2022-06-23 Thread Jakub Jelinek via Gcc-patches
On Thu, Jun 23, 2022 at 10:49:55PM +0200, Harald Anlauf wrote:
> > We need both a compiler change (so that for glibc 2.26+ it uses *f128 APIs
> > instead of *q) and library change.
> 
> this is quite an important change in the gfortran ABI, as it will
> require recompilation of (library) code using quad precision.
> Not that I am particularly affected, but this should be highlighted
> for users.

We currently use
%rename lib liborig
*lib: %{static-libgfortran:--as-needed} -lquadmath 
%{static-libgfortran:--no-as-needed} -lm %(libgcc) %(liborig)
in libgfortran.spec (on targets where we do configure in libquadmath).
So, I believe the patch as is is an ABI change for *.o files if they use
real(kind=16) math functions (one needs to recompile them), but not
for linked shared libraries or executables, because the above aranges
for them to be linked with -lquadmath or for -static-libgfortran with
--as-needed -lquadmath --no-as-needed.  The former adds libquadmath.so.0
automatically to anything gfortran links, the latter to anything that
actually needs it (i.e. has undefined math/complex *q symbols).

Note, libgfortran.so.5 itself is ABI compatible, just no longer has
DT_NEEDED libquadmath.so.0 and uses the *f128 APIs + str{to,from}f128
instead of *q APIs + strtoflt128 and quadmath_snprintf.

Now, what we could do if we'd want to also preserve *.o file compatibility,
would be for gcc configured on glibc 2.26+ change libgfortran.spec to
*lib: --as-needed -lquadmath --no-as-needed -lm %(libgcc) %(liborig)
so that we even without -static-libgfortran link in libquadmath.so.0
only if it is needed.  So, if there will be any gcc <= 12 compiled
*.o files or *.o files compiled by gcc 13 if it was configured against
glibc 2.25 or older, we'd link -lquadmath in, but if there are just
*.o files referencing *f128 symbols, we wouldn't.

> Am I right in assuming that this also effectively fixes PR46539?
> (Add -static-libquadmath).

That was one of the intents of the patch.
But sure, it doesn't introduce -static-libquadmath, nor arranges for
-static-libgfortran to link libquadmath statically, just in some cases
(gcc configured on glibc 2.26 or later) and when everything that calls
real(kind=16) math functions has been recompiled arranges for libquadmath
not to be used at all.

> > --- gcc/fortran/trans-intrinsic.cc.jj   2022-05-16 11:14:57.587427707 
> > +0200
> > +++ gcc/fortran/trans-intrinsic.cc  2022-06-23 11:42:03.355899271 +0200
> > @@ -155,7 +155,7 @@ builtin_decl_for_precision (enum built_i
> > else if (precision == TYPE_PRECISION (double_type_node))
> >   i = m->double_built_in;
> > else if (precision == TYPE_PRECISION (long_double_type_node)
> > -  && (!gfc_real16_is_float128
> > +  && ((!gfc_real16_is_float128 & !gfc_real16_is__Float128)
> 
> Shouldn't this be && instead of & ?

You're right, will fix.

Jakub



[pushed] c++: designated init cleanup [PR105925]

2022-06-23 Thread Jason Merrill via Gcc-patches
build_aggr_conv expects to run after reshape_init, which will usually have
filled out all the CONSTRUCTOR indexes; there's no reason to limit using
those to the case where the user gave an explicit designator.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/105925

gcc/cp/ChangeLog:

* call.cc (build_aggr_conv): Don't depend on
CONSTRUCTOR_IS_DESIGNATED_INIT.
---
 gcc/cp/call.cc | 60 +-
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 4710c3777c5..f1dd8377628 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -969,7 +969,8 @@ build_aggr_conv (tree type, tree ctor, int flags, 
tsubst_flags_t complain)
   tree empty_ctor = NULL_TREE;
   hash_set pset;
 
-  /* We already called reshape_init in implicit_conversion.  */
+  /* We already called reshape_init in implicit_conversion, but it might not
+ have done anything in the case of parenthesized aggr init.  */
 
   /* The conversions within the init-list aren't affected by the enclosing
  context; they're always simple copy-initialization.  */
@@ -979,49 +980,48 @@ build_aggr_conv (tree type, tree ctor, int flags, 
tsubst_flags_t complain)
  to corresponding TREE_TYPE (ce->index) and mark those FIELD_DECLs as
  visited.  In the following loop then ignore already visited
  FIELD_DECLs.  */
-  if (CONSTRUCTOR_IS_DESIGNATED_INIT (ctor))
+  tree idx, val;
+  FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (ctor), i, idx, val)
 {
-  tree idx, val;
-  FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (ctor), i, idx, val)
+  if (!idx)
+   break;
+
+  gcc_checking_assert (TREE_CODE (idx) == FIELD_DECL);
+
+  tree ftype = TREE_TYPE (idx);
+  bool ok;
+
+  if (TREE_CODE (ftype) == ARRAY_TYPE)
+   ok = can_convert_array (ftype, val, flags, complain);
+  else
+   ok = can_convert_arg (ftype, TREE_TYPE (val), val, flags,
+ complain);
+
+  if (!ok)
+   return NULL;
+
+  /* For unions, there should be just one initializer.  */
+  if (TREE_CODE (type) == UNION_TYPE)
{
- if (idx && TREE_CODE (idx) == FIELD_DECL)
-   {
- tree ftype = TREE_TYPE (idx);
- bool ok;
-
- if (TREE_CODE (ftype) == ARRAY_TYPE)
-   ok = can_convert_array (ftype, val, flags, complain);
- else
-   ok = can_convert_arg (ftype, TREE_TYPE (val), val, flags,
- complain);
-
- if (!ok)
-   return NULL;
- /* For unions, there should be just one initializer.  */
- if (TREE_CODE (type) == UNION_TYPE)
-   {
- field = NULL_TREE;
- i = 1;
- break;
-   }
- pset.add (idx);
-   }
- else
-   return NULL;
+ field = NULL_TREE;
+ i = 1;
+ break;
}
+  pset.add (idx);
 }
 
   for (; field; field = next_aggregate_field (DECL_CHAIN (field)))
 {
   tree ftype = TREE_TYPE (field);
-  tree val;
   bool ok;
 
   if (!pset.is_empty () && field_in_pset (pset, field))
continue;
   if (i < CONSTRUCTOR_NELTS (ctor))
{
- val = CONSTRUCTOR_ELT (ctor, i)->value;
+ constructor_elt *ce = CONSTRUCTOR_ELT (ctor, i);
+ gcc_checking_assert (!ce->index);
+ val = ce->value;
  ++i;
}
   else if (DECL_INITIAL (field))

base-commit: d610ae121e8ecd738de4dc01e6ac11ecf7c2327e
-- 
2.27.0



[pushed] c++: anon union designated init [PR105925]

2022-06-23 Thread Jason Merrill via Gcc-patches
This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR.  So set the flag when we see a designator rather
than relying on copying it from another CONSTRUCTOR.

This avoids some redundant errors on desig4.C because we stop setting
CONSTRUCTOR_IS_DESIGNATED_INIT on _Complex CONSTRUCTORs where it's
nonsense.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/105925

gcc/cp/ChangeLog:

* decl.cc (reshape_init_array_1): Set
CONSTRUCTOR_IS_DESIGNATED_INIT here.
(reshape_init_class): And here.
(reshape_init): Not here.

gcc/testsuite/ChangeLog:

* g++.dg/ext/desig4.C: Remove extra errors.
* g++.dg/cpp2a/desig26.C: New test.
---
 gcc/cp/decl.cc   |  6 +-
 gcc/testsuite/g++.dg/cpp2a/desig26.C | 22 ++
 gcc/testsuite/g++.dg/ext/desig4.C|  4 
 3 files changed, 27 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/desig26.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 29fc36534c2..aa6cf3c6c2e 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -6505,6 +6505,8 @@ reshape_init_array_1 (tree elt_type, tree max_index, 
reshape_iter *d,
   tree elt_init;
   constructor_elt *old_cur = d->cur;
 
+  if (d->cur->index)
+   CONSTRUCTOR_IS_DESIGNATED_INIT (new_init) = true;
   check_array_designated_initializer (d->cur, index);
   elt_init = reshape_init_r (elt_type, d,
 /*first_initializer_p=*/NULL_TREE,
@@ -6674,6 +6676,7 @@ reshape_init_class (tree type, reshape_iter *d, bool 
first_initializer_p,
}
  else if (TREE_CODE (d->cur->index) == IDENTIFIER_NODE)
{
+ CONSTRUCTOR_IS_DESIGNATED_INIT (new_init) = true;
  field = get_class_binding (type, d->cur->index);
  direct_desig = true;
}
@@ -7158,7 +7161,8 @@ reshape_init (tree type, tree init, tsubst_flags_t 
complain)
 CONSTRUCTOR_IS_DIRECT_INIT (new_init) = true;
   if (CONSTRUCTOR_IS_DESIGNATED_INIT (init)
   && BRACE_ENCLOSED_INITIALIZER_P (new_init))
-CONSTRUCTOR_IS_DESIGNATED_INIT (new_init) = true;
+gcc_checking_assert (CONSTRUCTOR_IS_DESIGNATED_INIT (new_init)
+|| seen_error ());
 
   return new_init;
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/desig26.C 
b/gcc/testsuite/g++.dg/cpp2a/desig26.C
new file mode 100644
index 000..443fa3d089d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/desig26.C
@@ -0,0 +1,22 @@
+// PR c++/105925
+// { dg-do compile { target c++20 } }
+
+struct V
+{
+int i;
+double d;
+};
+
+struct X
+{
+union
+{
+int x;
+V y;
+};
+};
+
+X foo()
+{
+return {.y = {0, 0.0}};
+}
diff --git a/gcc/testsuite/g++.dg/ext/desig4.C 
b/gcc/testsuite/g++.dg/ext/desig4.C
index 902bd1ff0b6..9b92a6de249 100644
--- a/gcc/testsuite/g++.dg/ext/desig4.C
+++ b/gcc/testsuite/g++.dg/ext/desig4.C
@@ -6,13 +6,9 @@ int a = { .foo = 6 };   // { dg-error "designator" 
}
 int b = { [0] = 1 };// { dg-error "12:designator .0." }
 _Complex float c = { .foo = 0,  1 }; // { dg-error "designator" }
 // { dg-error "either all initializer 
clauses should be designated or none of them should be" "" { target c++2a } .-1 
}
-// { dg-error "cannot convert" "" { target 
*-*-* } .-2 }
 _Complex float d = { [0] = 0,  1 };  // { dg-error "23:designator .0." }
 // { dg-error "either all initializer 
clauses should be designated or none of them should be" "" { target c++2a } .-1 
}
-// { dg-error "cannot convert" "" { target 
*-*-* } .-2 }
 _Complex float e = { 0, .foo = 1 };  // { dg-error "designator" }
 // { dg-error "either all initializer 
clauses should be designated or none of them should be" "" { target c++2a } .-1 
}
-// { dg-error "cannot convert" "" { target 
*-*-* } .-2 }
 _Complex float f = { 0, [0] = 1 };   // { dg-error "26:designator .0." }
 // { dg-error "either all initializer 
clauses should be designated or none of them should be" "" { target c++2a } .-1 
}
-// { dg-error "cannot convert" "" { target 
*-*-* } .-2 }

base-commit: b00b95198e6720eb23a2618870d67800f6180fdd
-- 
2.27.0



Re: [PATCH] fortran, libgfortran: Avoid using libquadmath for glibc 2.26+

2022-06-23 Thread Harald Anlauf via Gcc-patches

Hi Jakub,

Am 23.06.22 um 14:04 schrieb Jakub Jelinek via Gcc-patches:

Hi!

As mentioned by Joseph in PR105101, glibc 2.26 or later has on x86
(both -m32/-m64), powerpc64le, ia64 and mips support for
*f128 math/complex APIs plus strtof128 and strfromf128, and these APIs allow
us to avoid libquadmath for Fortran purposes on these architectures,
replace *q math/complex APIs, strtof128 instead of strtoflt128 and,
while strfromf128 unfortunately isn't a perfect replacement to
quadmath_snprintf, it can be made to work.

The advantage of this is that when configured against such glibcs
(2.26 is now almost 5 years old), we can avoid linking against an extra shared
library and the math support in glibc is maintained better than libquadmath.

We need both a compiler change (so that for glibc 2.26+ it uses *f128 APIs
instead of *q) and library change.


this is quite an important change in the gfortran ABI, as it will
require recompilation of (library) code using quad precision.
Not that I am particularly affected, but this should be highlighted
for users.

Am I right in assuming that this also effectively fixes PR46539?
(Add -static-libquadmath).


So far lightly tested on x86_64-linux with glibc 2.35 (removed libgfortran
dirs, rebuilt stage3 f951 and make all-target-libgfortran + make
check-gfortran), ok for trunk if it passes full testing?


I did not look into all details, but noticed the following:


--- gcc/fortran/trans-intrinsic.cc.jj   2022-05-16 11:14:57.587427707 +0200
+++ gcc/fortran/trans-intrinsic.cc  2022-06-23 11:42:03.355899271 +0200
@@ -155,7 +155,7 @@ builtin_decl_for_precision (enum built_i
else if (precision == TYPE_PRECISION (double_type_node))
  i = m->double_built_in;
else if (precision == TYPE_PRECISION (long_double_type_node)
-  && (!gfc_real16_is_float128
+  && ((!gfc_real16_is_float128 & !gfc_real16_is__Float128)


Shouldn't this be && instead of & ?


   || long_double_type_node != gfc_float128_type_node))
  i = m->long_double_built_in;
else if (precision == TYPE_PRECISION (gfc_float128_type_node))
@@ -175,7 +175,7 @@ gfc_builtin_decl_for_float_kind (enum bu
  {
int i = gfc_validate_kind (BT_REAL, kind, false);

-  if (gfc_real_kinds[i].c_float128)
+  if (gfc_real_kinds[i].c_float128 || gfc_real_kinds[i].c__Float128)
  {
/* For _Float128, the story is a bit different, because we return
 a decl to a library function rather than a built-in.  */
@@ -688,7 +688,7 @@ gfc_build_intrinsic_lib_fndecls (void)
gfc_intrinsic_map_t *m;
tree quad_decls[END_BUILTINS + 1];

-  if (gfc_real16_is_float128)
+  if (gfc_real16_is_float128 || gfc_real16_is__Float128)
{
  /* If we have soft-float types, we create the decls for their
 C99-like library functions.  For now, we only handle _Float128
@@ -739,7 +739,10 @@ gfc_build_intrinsic_lib_fndecls (void)
 builtin_decl_for_float_type(). The others are all constructed by
 gfc_get_intrinsic_lib_fndecl().  */
  #define OTHER_BUILTIN(ID, NAME, TYPE, CONST) \
-  quad_decls[BUILT_IN_ ## ID] = define_quad_builtin (NAME "q", func_ ## TYPE, 
CONST);
+quad_decls[BUILT_IN_ ## ID]
\
+  = define_quad_builtin (gfc_real16_is__Float128   \
+? NAME "f128" : NAME "q", func_ ## TYPE,   \
+CONST);

  #include "mathbuiltins.def"

@@ -751,8 +754,9 @@ gfc_build_intrinsic_lib_fndecls (void)
  /* There is one built-in we defined manually, because it gets called
 with builtin_decl_for_precision() or builtin_decl_for_float_type()
 even though it is not an OTHER_BUILTIN: it is SQRT.  */
-quad_decls[BUILT_IN_SQRT] = define_quad_builtin ("sqrtq", func_1, true);
-
+quad_decls[BUILT_IN_SQRT]
+  = define_quad_builtin (gfc_real16_is__Float128
+? "sqrtf128" : "sqrtq", func_1, true);
}

/* Add GCC builtin functions.  */
@@ -775,7 +779,7 @@ gfc_build_intrinsic_lib_fndecls (void)
m->complex10_decl
  = builtin_decl_explicit (m->complex_long_double_built_in);

-  if (!gfc_real16_is_float128)
+  if (!gfc_real16_is_float128 && !gfc_real16_is__Float128)
{
  if (m->long_double_built_in != END_BUILTINS)
m->real16_decl = builtin_decl_explicit (m->long_double_built_in);
@@ -876,6 +880,9 @@ gfc_get_intrinsic_lib_fndecl (gfc_intrin
else if (gfc_real_kinds[n].c_float128)
snprintf (name, sizeof (name), "%s%s%s",
  ts->type == BT_COMPLEX ? "c" : "", m->name, "q");
+  else if (gfc_real_kinds[n].c__Float128)
+   snprintf (name, sizeof (name), "%s%s%s",
+ ts->type == BT_COMPLEX ? "c" : "", m->name, "f128");
else
gcc_unreachable ();
  }
--- gcc/fortran/trans-expr.cc.jj2022-04-23 10:10:51.146097072 +0200
+++ gcc/fortran/trans-expr.cc   2022-06-23 11:49:31.191964727 +0200

Go patch committed: In Sort_bindings handle same value passed twice

2022-06-23 Thread Ian Lance Taylor via Gcc-patches
This patch by zhangjian to the Go frontend changes Sort_bindings to
return false if comparing a value to itself.  Apparently some versions
of std::sort may pass elements at the same iterator location.  This
fixes https://go.dev/issue/53483.  Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
5ee8e1d1b0c0d9f6310d27a37a6162e0be80e413
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 629bc666dc0..f882812d219 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-6c3752315dc9b82d0f3f3ac646a1e7376818f84a
+6b314f7947b4b31a86c09d166fe6664cd9968824
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/export.cc b/gcc/go/gofrontend/export.cc
index a30b11af31e..7373deee310 100644
--- a/gcc/go/gofrontend/export.cc
+++ b/gcc/go/gofrontend/export.cc
@@ -530,6 +530,9 @@ struct Sort_bindings
   bool
   operator()(const Named_object* n1, const Named_object* n2) const
   {
+if (n1 == n2)
+  return false;
+
 if (n1->package() != n2->package())
   {
if (n1->package() == NULL)


Go patch committed: unalias types for hash/equality functions

2022-06-23 Thread Ian Lance Taylor via Gcc-patches
This patch to the Go frontend makes sure to unalias types when
creating hash/equality functions.  This fixes
https://go.dev/issue/52846.  There is a test case at
https://go.dev/cl/413694.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
3e134d9c6716f6acaf3e17458c603c3786003fb2
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 737bc483274..629bc666dc0 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-77821de1a149c2e6ef9c154ae384c16292173039
+6c3752315dc9b82d0f3f3ac646a1e7376818f84a
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/gcc/go/gofrontend/gogo.cc b/gcc/go/gofrontend/gogo.cc
index d35c6baf582..e13df0da22b 100644
--- a/gcc/go/gofrontend/gogo.cc
+++ b/gcc/go/gofrontend/gogo.cc
@@ -2811,7 +2811,7 @@ Specific_type_functions::type(Type* t)
 
 case Type::TYPE_MAP:
   {
-   Type* key_type = t->map_type()->key_type();
+   Type* key_type = t->map_type()->key_type()->unalias();
if (key_type->needs_specific_type_functions(this->gogo_))
  key_type->hash_function(this->gogo_, NULL);
   }
diff --git a/gcc/go/gofrontend/types.cc b/gcc/go/gofrontend/types.cc
index eb3afd94682..39aea769eb2 100644
--- a/gcc/go/gofrontend/types.cc
+++ b/gcc/go/gofrontend/types.cc
@@ -1764,6 +1764,9 @@ Type::needs_specific_type_functions(Gogo* gogo)
 Named_object*
 Type::hash_function(Gogo* gogo, Function_type* hash_fntype)
 {
+  if (this->named_type() != NULL)
+go_assert(!this->named_type()->is_alias());
+
   if (!this->is_comparable())
 return NULL;
 
@@ -2067,6 +2070,9 @@ Type::write_identity_hash(Gogo* gogo, int64_t size)
 Named_object*
 Type::equal_function(Gogo* gogo, Named_type* name, Function_type* equal_fntype)
 {
+  if (this->named_type() != NULL)
+go_assert(!this->named_type()->is_alias());
+
   // If the unaliased type is not a named type, then the type does not
   // have a name after all.
   if (name != NULL)
@@ -6700,7 +6706,8 @@ Struct_type::write_hash_function(Gogo* gogo, 
Function_type* hash_fntype)
   subkey = Expression::make_cast(key_arg_type, subkey, bloc);
 
   // Get the hash function to use for the type of this field.
-  Named_object* hash_fn = pf->type()->hash_function(gogo, hash_fntype);
+  Named_object* hash_fn =
+   pf->type()->unalias()->hash_function(gogo, hash_fntype);
 
   // Call the hash function for the field, passing retval as the seed.
   ref = Expression::make_temporary_reference(retval, bloc);
@@ -7553,8 +7560,8 @@ Array_type::write_hash_function(Gogo* gogo, 
Function_type* hash_fntype)
   gogo->start_block(bloc);
 
   // Get the hash function for the element type.
-  Named_object* hash_fn = this->element_type_->hash_function(gogo,
-hash_fntype);
+  Named_object* hash_fn =
+this->element_type_->unalias()->hash_function(gogo, hash_fntype);
 
   // Get a pointer to this element in the loop.
   Expression* subkey = Expression::make_temporary_reference(key, bloc);
@@ -8441,8 +8448,8 @@ Map_type::do_type_descriptor(Gogo* gogo, Named_type* name)
   ++p;
   go_assert(p->is_field_name("hasher"));
   Function_type* hasher_fntype = p->type()->function_type();
-  Named_object* hasher_fn = this->key_type_->hash_function(gogo,
-  hasher_fntype);
+  Named_object* hasher_fn =
+this->key_type_->unalias()->hash_function(gogo, hasher_fntype);
   if (hasher_fn == NULL)
 vals->push_back(Expression::make_cast(hasher_fntype,
  Expression::make_nil(bloc),


Re: [PATCH] c++: constexpr folding in unevaluated context [PR105931]

2022-06-23 Thread Jason Merrill via Gcc-patches

On 6/23/22 11:06, Patrick Palka wrote:

Changing the type of N from int to unsigned in decltype82.C from
r12-8472-g47ea22015c90df reveals another spot where we perform
constexpr evaluation in an unevaluated context for sake of diagnostics,
this time from the call to shorten_compare in cp_build_binary_op,
which calls fold_for_warn.

We could (and probably should?) suppress the shorten_compare diagnostics
when in an unevaluated context, but there's probably other spots
that have the same bug.  So this patch takes the approach of suppressing
fold_for_warn more generally when in an unevaluated context.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?


OK.


PR c++/105931

gcc/cp/ChangeLog:

* expr.cc (fold_for_warn): Don't fold when in an unevaluated
context.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/decltype82a.C: New test.
---
  gcc/cp/expr.cc   |  5 +
  gcc/testsuite/g++.dg/cpp0x/decltype82a.C | 11 +++
  2 files changed, 16 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype82a.C

diff --git a/gcc/cp/expr.cc b/gcc/cp/expr.cc
index 31fe0980337..b71245f937d 100644
--- a/gcc/cp/expr.cc
+++ b/gcc/cp/expr.cc
@@ -397,6 +397,11 @@ fold_for_warn (tree x)
  {
/* C++ implementation.  */
  
+  if (cp_unevaluated_operand)

+/* In an unevaluated context, we don't care about the reduced value
+   of an expression, so neither should any warnings.  */
+return x;
+
/* Prevent warning-dependent constexpr evaluation from changing
   DECL_UID (which breaks -fcompare-debug) and from instantiating
   templates.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype82a.C 
b/gcc/testsuite/g++.dg/cpp0x/decltype82a.C
new file mode 100644
index 000..cbbcdfd8e58
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype82a.C
@@ -0,0 +1,11 @@
+// PR c++/105931
+// { dg-do compile { target c++11 } }
+// A version of decltype82.C where N is unsigned.
+
+template
+void f() {
+  using ty1 = decltype((5 % N) == 0);
+  using ty2 = decltype((5 / N) == 0);
+}
+
+template void f<0>();




Re: [PATCH] c++: context completion in lookup_template_class [PR105982]

2022-06-23 Thread Jason Merrill via Gcc-patches

On 6/23/22 10:48, Patrick Palka wrote:

The below testcase demonstrates that completion of the substituted
context during lookup_template_class can end up registering the desired
specialization for us in more cases than r13-1045-gcb7fd1ea85feea
anticipated.  In particular, it can happen for a non-dependent
specialization of a nested class as well.

During overload resolution with A's guides, we substitute the deduced
argument T=int into the TYPENAME_TYPE B::C (*).  This substitution calls
lookup_template_class for A::B with T=int, which completes A
for the first time, which recursively registers the desired specialization
of B for us.  The parent call to lookup_template_class then tries
registering the same specialization, which leads to a crash.

This patch fixes this by making lookup_template_class check the
specializations table after completion of the context iff necessary,
i.e. when the call to complete_type actually has an effect.

(*): Note that the TYPE_CONTEXT of this TYPENAME_TYPE is just the
RECORD_TYPE B instead of TYPENAME_TYPE A::B.  Is this expected?
I'd think maybe_dependent_member_ref would rewrite the reference to B
in terms of another TYPENAME_TYPE.  This is why the testcase needs to
use 'typename B::C' instead of just 'B' -- maybe_dependent_member_ref
rewrites the use of B in the latter case but not the former.


Hmm, perhaps maybe_dependent_member_ref needs to consider rewriting ctx 
as well.



Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?


OK.


PR c++/105982

gcc/cp/ChangeLog:

* pt.cc (lookup_template_class): After completion of the
substituted context, check the table again iff the type was
previously incomplete and complete_type made it complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction111.C: New test.
---
  gcc/cp/pt.cc  | 21 +++
  .../g++.dg/cpp1z/class-deduction111.C | 10 +
  2 files changed, 22 insertions(+), 9 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction111.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 28edc6ae988..eeae867a816 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10089,16 +10089,19 @@ lookup_template_class (tree d1, tree arglist, tree 
in_decl, tree context,
{
  context = tsubst_aggr_type (context, arglist,
  complain, in_decl, true);
- context = complete_type (context);
- if (is_dependent_type && arg_depth > 1)
+ /* Try completing the enclosing context if it's not already so.  
*/
+ if (context != error_mark_node
+ && !COMPLETE_TYPE_P (context))
{
+ context = complete_type (context);
+ if (COMPLETE_TYPE_P (context))
+   {
+ /* Completion could have caused us to register the desired
+specialization for us, so check the table again.  */
+ entry = type_specializations->find_with_hash (&elt, hash);
+ if (entry)
+   return entry->spec;
+   }
}
}
}
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C
new file mode 100644
index 000..2406529ea5a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C
@@ -0,0 +1,10 @@
+// PR c++/105982
+// { dg-do compile { target c++17 } }
+
+template
+struct A {
+  struct B { struct C { }; };
+  A(T, typename B::C);
+};
+
+A a(0, {});




Re: [PATCH v3] rs6000: Adjust mov optabs for opaque modes [PR103353]

2022-06-23 Thread Segher Boessenkool
Hi!

On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
> As PR103353 shows, we may want to continue to expand a MMA built-in
> function like a normal function, even if we have already emitted
> error messages about some missing required conditions.  As shown in
> that PR, without one explicit mov optab on OOmode provided, it would
> call emit_move_insn recursively.

First off: lxvp is a VSX insn, not an MMA insn.  So please don't call it
that -- this confusion is what presumably caused the problem here, so it
would be good to root it out :-)

> +  /* Opaque modes are only expected to be available when MMA is supported,

Why do people expect that?  It is completely wrong.  The name "opaque"
itself already says this is not just for MMA, but perhaps more
importantly, it is a basic VSX insn, doesn't touch any MMA resources,
and is useful in other contexts as well.

So this needs some bigger surgery.


Segher


Re: [PATCH 01/12] diagnostics: add ability to associate diagnostics with rules from coding standards

2022-06-23 Thread David Malcolm via Gcc-patches
On Wed, 2022-06-22 at 18:34 -0400, David Malcolm wrote:
> gcc/ChangeLog:
> * common.opt (fdiagnostics-show-rules): New option.
> * diagnostic-format-json.cc
> (diagnostic_output_format_init_json):
> Fix up context->show_rules.
> * diagnostic-format-sarif.cc
> (diagnostic_output_format_init_sarif): Likewise.
> * diagnostic-metadata.h (diagnostic_metadata::rule): New
> class.
> (diagnostic_metadata::precanned_rule): New class.
> (diagnostic_metadata::add_rule): New.
> (diagnostic_metadata::get_num_rules): New.
> (diagnostic_metadata::get_rule): New.
> (diagnostic_metadata::m_rules): New field.
> * diagnostic.cc (diagnostic_initialize): Initialize
> show_rules.
> (print_any_rules): New.
> (diagnostic_report_diagnostic): Call it.
> * diagnostic.h (diagnostic_context::show_rules): New field.
> * doc/invoke.texi (-fno-diagnostics-show-rules): New option.
> * opts.cc (common_handle_option): Handle
> OPT_fdiagnostics_show_rules.
> * toplev.cc (general_init): Set up global_dc->show_rules.
> 
> gcc/testsuite/ChangeLog:
> * gcc.dg/plugin/diagnostic-test-metadata.c: Expect " [STR34-
> C]" to
> be emitted at the "gets" call.
> * gcc.dg/plugin/diagnostic_plugin_test_metadata.c
> (pass_test_metadata::execute): Associate the "gets"
> diagnostic
> with a rule named "STR34-C".
> 
> Signed-off-by: David Malcolm 

This one seems potentially useful to plugin authors without the rest of
the patch kit, so I've pushed it to trunk as: r13-1221-g0b14f590e3e9d9
(after a successful bootstrap & regression test on x86_64-pc-linux-gnu)

Dave



Re: [PATCH] libstdc++-v3: check for openat

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 15:05, Alexandre Oliva  wrote:
>
> On Jun 23, 2022, Jonathan Wakely  wrote:
>
> > On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva  wrote:
> >>
> >> On Jun 22, 2022, Jonathan Wakely  wrote:
> >>
> >> > There are other interactions between AT_CDCWD and ::openat not covered
> >> > by this patch. I this this also needs to check HAVE_OPENAT:
> >>
> >> Here's an updated version, tested with this additional change.
>
> > Did this improve your test results for directory iterators?
>
> 'fraid the bad results I posted earlier today had this patch in.  I
> can't tell whether it improved anything because I didn't save earlier
> results to compare.
>
> > In the unlikely even that the target has ::unlinkat but not ::openat
>
> c++config.h on the target says:
>
> /* #undef _GLIBCXX_HAVE_UNLINKAT */
>
> Thanks for the concern,


Here's what I'm thinking of so that the derived _Dir class doesn't
need to know whether the base _Dir_base::openat function will actually
use ::openat or not.

It defines a new _At_path type which contains a {fd, path} pair (to be
used together by openat and unlinkat) and a separate path to be used
on its own. This allows identifying a file within a directory
unambiguously, without being concerned with whether HAVE_OPENAT and
HAVE_UNLINKAT are defined.

With this change I don't think your patch to make dir_and_pathname()
check HAVE_OPENAT is needed.

This passes tests on x86_64-linux.
diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index c67fe76bc14..fb752239e1f 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -46,7 +46,7 @@ struct fs::_Dir : _Dir_base
 {
   _Dir(const fs::path& p, bool skip_permission_denied, bool nofollow,
[[maybe_unused]] bool filename_only, error_code& ec)
-  : _Dir_base(fdcwd(), p.c_str(), skip_permission_denied, nofollow, ec)
+  : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec)
   {
 #if _GLIBCXX_HAVE_DIRFD
 if (filename_only)
@@ -120,15 +120,15 @@ struct fs::_Dir : _Dir_base
   // Return a file descriptor for the directory and current entry's path.
   // If dirfd is available, use it and return only the filename.
   // Otherwise, return AT_FDCWD and return the full path.
-  pair
+  _At_path
   dir_and_pathname() const noexcept
   {
 const fs::path& p = entry.path();
 #if _GLIBCXX_HAVE_DIRFD
 if (!p.empty())
-  return {::dirfd(this->dirp), std::prev(p.end())->c_str()};
+  return {::dirfd(this->dirp), std::prev(p.end())->c_str(), p.c_str()};
 #endif
-return {this->fdcwd(), p.c_str()};
+return p.c_str();
   }
 
   // Create a new _Dir for the directory this->entry.path().
@@ -136,8 +136,7 @@ struct fs::_Dir : _Dir_base
   open_subdir(bool skip_permission_denied, bool nofollow,
  error_code& ec) const noexcept
   {
-auto [dirfd, pathname] = dir_and_pathname();
-_Dir_base d(dirfd, pathname, skip_permission_denied, nofollow, ec);
+_Dir_base d(dir_and_pathname(), skip_permission_denied, nofollow, ec);
 // If this->path is empty, the new _Dir should have an empty path too.
 const fs::path& p = this->path.empty() ? this->path : this->entry.path();
 return _Dir(std::move(d), p);
@@ -147,7 +146,7 @@ struct fs::_Dir : _Dir_base
   do_unlink(bool is_directory, error_code& ec) const noexcept
   {
 #if _GLIBCXX_HAVE_UNLINKAT
-auto [dirfd, pathname] = dir_and_pathname();
+auto [dirfd, pathname, _] = dir_and_pathname();
 if (::unlinkat(dirfd, pathname, is_directory ? AT_REMOVEDIR : 0) == -1)
   {
ec.assign(errno, std::generic_category());
diff --git a/libstdc++-v3/src/filesystem/dir-common.h 
b/libstdc++-v3/src/filesystem/dir-common.h
index 365fd527f4d..5f7f4909ad3 100644
--- a/libstdc++-v3/src/filesystem/dir-common.h
+++ b/libstdc++-v3/src/filesystem/dir-common.h
@@ -91,12 +91,37 @@ is_permission_denied_error(int e)
 
 struct _Dir_base
 {
+  struct _At_path
+  {
+_At_path(const char* p) noexcept
+: dir_fd(fdcwd()), path_from_dir(p), pathname(p)
+{ }
+
+_At_path(int fd, const char* p1, const char* p2)
+: dir_fd(fd), path_from_dir(p1), pathname(p2)
+{ }
+
+int dir_fd; // A directory descriptor (either the parent dir, or AT_FDCWD).
+const posix::char_type* path_from_dir; // Path relative to dir_fd.
+const posix::char_type* pathname; // Full path relative to CWD.
+
+static constexpr int
+fdcwd() noexcept
+{
+#ifdef AT_FDCWD
+  return AT_FDCWD;
+#else
+  return -1; // Use invalid fd if AT_FDCWD isn't supported.
+#endif
+}
+  };
+
   // If no error occurs then dirp is non-null,
   // otherwise null (even if a permission denied error is ignored).
-  _Dir_base(int fd, const posix::char_type* pathname,
+  _Dir_base(const _At_path& atp,
bool skip_permission_denied, bool nofollow,
error_code& ec) noexcept
-  : dirp(_Dir_base::openat(fd, pathname, nofollow))
+  : dirp(_Dir_base::openat(atp, nofollow))
   {
 if (dirp)
 

Ping^2: [PATCH v2] diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

2022-06-23 Thread Lewis Hyatt via Gcc-patches
Hello-

https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49

Would a C++ maintainer have some time to take a look at this patch
please? I feel like the PR is still worth resolving. If this doesn't
seem like a good way, I am happy to try another -- would really
appreciate any feedback. Thanks!

-Lewis

On Tue, May 24, 2022 at 5:28 PM Lewis Hyatt  wrote:
>
> Hello-
>
> Now that we're back in stage 1, I thought it might be a better time to
> ask for feedback on this pair of patches that tries to resolve PR53431
> please?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587357.html
> https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587358.html
>
> Part 1/2 is a trivial cleanup in the C++ parser that simplifies
> adding the support for early pragma handling.
>
> Part 2/2 adds the concept of early pragma handling and makes the C++
> and preprocessor frontends use it.
>
> The patches required some minor rebasing, so I have attached updated
> versions here.
>
> bootstrap + regtest all languages still looks good:
>
> FAIL 103 103
> PASS 541178 541213
> UNSUPPORTED 15177 15177
> UNTESTED 136 136
> XFAIL 4140 4140
> XPASS 17 17
>
> Thanks! If this approach doesn't seem like the right one, I am happy
> to try another way.
>
> -Lewis
>
>
> On Fri, Dec 24, 2021 at 04:23:08PM -0500, Lewis Hyatt wrote:
> > Hello-
> >
> > I would like please to follow up on this patch submitted for PR53431 here:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586191.html
> >
> > However, it was suggested on the PR that part of it could be split into a
> > separate simpler patch. I have now done that, and also made a few tweaks to
> > the first version at the same time, so may I please request that you review
> > this version 2 instead? This email contains the first smaller cleanup patch,
> > and the next email contains the main part of it. Thanks very much.
> >
> > bootstrap and regtest were performed on x86-64 Linux, all tests look the 
> > same
> > before + after, plus the new passing testcases.
> >
> > FAIL 112 112
> > PASS 528007 528042
> > UNSUPPORTED 14888 14888
> > UNTESTED 132 132
> > XFAIL 3238 3238
> > XPASS 17 17
> >
> > -Lewis
>
> > From: Lewis Hyatt 
> > Date: Thu, 23 Dec 2021 17:03:04 -0500
> > Subject: [PATCH] c++: Minor cleanup in parser.c
> >
> > The code to determine whether a given token starts a module directive is
> > currently repeated in 4 places in parser.c. I am about to submit a patch
> > that needs to add it in a 5th place, so since the code is not completely
> > trivial (needing to check for 3 different token types), it seems worthwhile
> > to factor this logic into its own function.
> >
> > gcc/cp/ChangeLog:
> >
> >   * parser.c (cp_token_is_module_directive): New function
> >   refactoring common code.
> >   (cp_parser_skip_to_closing_parenthesis_1): Use the new function.
> >   (cp_parser_skip_to_end_of_statement): Likewise.
> >   (cp_parser_skip_to_end_of_block_or_statement): Likewise.
> >   (cp_parser_declaration): Likewise.
> >
> > diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> > index 33fb40a5b59..9b7446655be 100644
> > --- a/gcc/cp/parser.c
> > +++ b/gcc/cp/parser.c
> > @@ -629,6 +629,16 @@ cp_lexer_alloc (void)
> >return lexer;
> >  }
> >
> > +/* Return TRUE if token is the start of a module declaration that will be
> > +   terminated by a CPP_PRAGMA_EOL token.  */
> > +static inline bool
> > +cp_token_is_module_directive (cp_token *token)
> > +{
> > +  return token->keyword == RID__EXPORT
> > +|| token->keyword == RID__MODULE
> > +|| token->keyword == RID__IMPORT;
> > +}
> > +
> >  /* Create a new main C++ lexer, the lexer that gets tokens from the
> > preprocessor.  */
> >
> > @@ -3805,9 +3815,7 @@ cp_parser_skip_to_closing_parenthesis_1 (cp_parser 
> > *parser,
> > break;
> >
> >   case CPP_KEYWORD:
> > -   if (token->keyword != RID__EXPORT
> > -   && token->keyword != RID__MODULE
> > -   && token->keyword != RID__IMPORT)
> > +   if (!cp_token_is_module_directive (token))
> >   break;
> > /* FALLTHROUGH  */
> >
> > @@ -3908,9 +3916,7 @@ cp_parser_skip_to_end_of_statement (cp_parser* parser)
> > break;
> >
> >   case CPP_KEYWORD:
> > -   if (token->keyword != RID__EXPORT
> > -   && token->keyword != RID__MODULE
> > -   && token->keyword != RID__IMPORT)
> > +   if (!cp_token_is_module_directive (token))
> >   break;
> > /* FALLTHROUGH  */
> >
> > @@ -3997,9 +4003,7 @@ cp_parser_skip_to_end_of_block_or_statement 
> > (cp_parser* parser)
> > break;
> >
> >   case CPP_KEYWORD:
> > -   if (token->keyword != RID__EXPORT
> > -   && token->keyword != RID__MODULE
> > -   && token->keyword != RID__IMPORT)
> > +   if (!cp_token_is_module_directive (token))
> >   break;
> > /* FALLTHROUGH  */
> >
> > @@ -14860,9 +14864,7 @@ c

Re: [PATCH] RISC-V: Split unordered FP comparisons into individual RTL insns

2022-06-23 Thread Kito Cheng via Gcc-patches
Hi Maciej:

Thanks for detail analysis and performance number report, I am concern
about this patch might let compiler schedule the fsflags/frflags with
other floating point instructions, and the major issue is we didn't
model fflags right in GCC as you mentioned in the first email.

So I think we should model this right before we split that, I guess
that would be a bunch of work:
1. Add fflags to the hard register list.
2. Add (clobber (reg fflags)) or (set (reg fflags) (fpop
(operands...))) to those floating point operations which might change
fflags
3. Rewrite riscv_frflags and riscv_fsflags pattern by right RTL
pattern: (set (reg) (reg fflags)) and (set (reg fflags) (reg)).
4. Then split *f_quiet4_default and
*f_quiet4_snan pattern.

However I am not sure about the code gen impact of 2, especially the
impact to the combine pass, not sure if you are interested to give a
try?

And, I did some hack for part of this approach (1+3+4) got following
result for "__builtin_isless (x, y) + __builtin_isless (x, z)":

fltlt:
   frflags a4  # 8 [c=4 l=4]  riscv_frflags
   flt.d   a5,fa0,fa1  # 14[c=4 l=4]  *cstoredfdi4
   flt.d   a0,fa0,fa2  # 17[c=4 l=4]  *cstoredfdi4
   fsflags a4  # 18[c=4 l=4]  riscv_fsflags
   add a0,a0,a5# 30[c=4 l=4]  adddi3/0
   ret # 40[c=0 l=4]  simple_return

Verbose version:
fltlt:
#(insn 8 5 9 (set (reg:SI 14 a4 [88])
#(reg:SI 66 fflags)) "x.c":5:10 258 {riscv_frflags}
# (expr_list:REG_DEAD (reg:SI 66 fflags)
#(nil)))
   frflags a4  # 8 [c=4 l=4]  riscv_frflags
#(insn 14 11 15 (parallel [
#(set (reg:DI 15 a5 [90])
#(lt:DI (reg/v:DF 42 fa0 [orig:81 x ] [81])
#(reg:DF 43 fa1 [101])))
#(clobber:SI (reg:SI 66 fflags))
#]) "x.c":5:10 197 {*cstoredfdi4}
# (expr_list:REG_DEAD (reg:DF 43 fa1 [101])
#(expr_list:REG_UNUSED (reg:SI 66 fflags)
#(nil
   flt.d   a5,fa0,fa1  # 14[c=4 l=4]  *cstoredfdi4
#(insn 17 15 18 (parallel [
#(set (reg:DI 10 a0 [94])
#(lt:DI (reg/v:DF 42 fa0 [orig:81 x ] [81])
#(reg:DF 44 fa2 [102])))
#(clobber:SI (reg:SI 66 fflags))
#]) "x.c":5:36 197 {*cstoredfdi4}
# (expr_list:REG_DEAD (reg:DF 44 fa2 [102])
#(expr_list:REG_DEAD (reg/v:DF 42 fa0 [orig:81 x ] [81])
#(expr_list:REG_UNUSED (reg:SI 66 fflags)
#(nil)
   flt.d   a0,fa0,fa2  # 17[c=4 l=4]  *cstoredfdi4
#(insn 18 17 19 (set (reg:SI 66 fflags)
#(reg:SI 14 a4 [88])) "x.c":5:36 259 {riscv_fsflags}
# (expr_list:REG_DEAD (reg:SI 14 a4 [88])
#(nil)))
   fsflags a4  # 18[c=4 l=4]  riscv_fsflags
#(insn 30 25 31 (set (reg/i:DI 10 a0)
#(plus:DI (reg:DI 10 a0 [94])
#(reg:DI 15 a5 [90]))) "x.c":6:1 4 {adddi3}
# (expr_list:REG_DEAD (reg:DI 15 a5 [90])
#(nil)))
   add a0,a0,a5# 30[c=4 l=4]  adddi3/0
#(jump_insn 40 39 41 (simple_return) "x.c":6:1 244 {simple_return}
# (nil)
# -> simple_return)
   ret # 40[c=0 l=4]  simple_return


But this hack add an extra use of fflags to prevent FFLAGS getting
CSEed, patch attached.
From 1116422bb5a69d8361f5c5bc334a122fecbaa306 Mon Sep 17 00:00:00 2001
From: Kito Cheng 
Date: Fri, 24 Jun 2022 00:41:55 +0800
Subject: [PATCH] model fflags

---
 gcc/config/riscv/riscv.h  | 12 +--
 gcc/config/riscv/riscv.md | 42 ---
 gcc/function.cc   |  1 +
 3 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 6f7f4d3fbdc..c4e6efe9885 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -291,7 +291,7 @@ ASM_MISA_SPEC
 	- ARG_POINTER_REGNUM
 	- FRAME_POINTER_REGNUM */
 
-#define FIRST_PSEUDO_REGISTER 66
+#define FIRST_PSEUDO_REGISTER 67
 
 /* x0, sp, gp, and tp are fixed.  */
 
@@ -303,7 +303,7 @@ ASM_MISA_SPEC
   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,			\
   0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,			\
   /* Others.  */			\
-  1, 1	\
+  1, 1, 1\
 }
 
 /* a0-a7, t0-t6, fa0-fa7, and ft0-ft11 are volatile across calls.
@@ -317,7 +317,7 @@ ASM_MISA_SPEC
   1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1,			\
   1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1,			\
   /* Others.  */			\
-  1, 1	\
+  1, 1, 1,\
 }
 
 /* Select a register mode required for caller save of hard regno REGNO.
@@ -472,7 +472,7 @@ enum reg_class
   { 0x, 0x, 0x },	/* GR_REGS */		\
   { 0x, 0x, 0x },	/* FP_REGS */		\
   { 0x, 0x, 0x0003 },	/* FRAME_REGS */	\
-  { 0x, 0x, 0x0003 }	/* ALL_REGS */		\
+  { 0x, 0x, 0x0007 }	/* ALL_REGS */		\
 }
 
 /* A C expression whose value is a register class cont

Re: [PATCH 03/12] Add more emit_diagnostic overloads

2022-06-23 Thread Joseph Myers
On Wed, 22 Jun 2022, David Malcolm via Gcc-patches wrote:

>  extern bool emit_diagnostic (diagnostic_t, rich_location *, int,
>const char *, ...) ATTRIBUTE_GCC_DIAG(4,5);
> +extern bool emit_diagnostic (diagnostic_t, rich_location *,
> +  const diagnostic_metadata *, int,
> +  const char *, ...) ATTRIBUTE_GCC_DIAG(5,6);

Note that functions that take translatable diagnostic strings (*msgid 
parameters) can't have overloads with the diagnostic string argument in 
different positions because that breaks xgettext (see commit 
40fecdd62f7d293a214dd71b81de5e0f1099bba7).

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [PATCH] libstdc++: testsuite: avoid predictable mkstemp

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 12:39, Alexandre Oliva  wrote:
>
> On Jun 22, 2022, Jonathan Wakely  wrote:
>
> > On Wed, 22 Jun 2022 at 07:05, Alexandre Oliva via Libstdc++
> >  wrote:
>
> >> It was prompted by a target system with a non-random implementation of
> >> mkstemp, that returns a predictable sequence of filenames and selects
> >> the first one that isn't already taken.
>
> > OK
>
> And here's the patch that enabled me to stop worrying about the above.
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?
>
>
> __gnu_test::nonexistent_path: Always include counter in filename returned
>
> From: Joel Brobecker 
>
> We have noticed that, on RTEMS, a small number of testscases are
> failing because two calls to this method return the same filename.
> This happens for instance in 27_io/filesystem/operations/copy_file.cc
> where it does:
>
>   auto from = __gnu_test::nonexistent_path();
>   auto to = __gnu_test::nonexistent_path();
>
> We tracked this issue down to the fact that the implementation of
> mkstemp on that system appears to use a very predictable algorithm
> for chosing the name of the temporary file, where the same filename
> appears to be tried in the same order, regardless of past calls.
> So, as long as the file gets deleted after a call to mkstemp (something
> we do here in our nonexistent_path method), the next call to mkstemps
> ends up returning the same filename, causing the collision we se above.
>
> This commit enhances the __gnu_test::nonexistent_path method to
> introduce in the filename being returned a counter which gets
> incremented at every call of this method.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/util/testsuite_fs.h (__gnu_test::nonexistent_path):
> Always include a counter in the filename returned.
> ---
>  libstdc++-v3/testsuite/util/testsuite_fs.h |   31 
> 
>  1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
> b/libstdc++-v3/testsuite/util/testsuite_fs.h
> index 037d9ffc0f429..206ea67779003 100644
> --- a/libstdc++-v3/testsuite/util/testsuite_fs.h
> +++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
> @@ -38,9 +38,9 @@ namespace test_fs = std::experimental::filesystem;
>
>  #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 
> 200112L
>  #include  // mkstemp
> -#else
> -#include// std::random_device
> +#include  // strcpy
>  #endif
> +#include// std::random_device
>
>  #if defined(__MINGW32__) || defined(__MINGW64__) \
>|| !defined (_GLIBCXX_HAVE_SYMLINK)
> @@ -125,8 +125,32 @@ namespace __gnu_test
>file.erase(0, pos+1);
>
>  test_fs::path p;
> +// A counter, starting from a random value, to be included as part
> +// of the filename being returned, and incremented each time
> +// this method is used.  It allows us to ensure that two calls
> +// to this method can never return the same filename, something
> +// testcases do when they need multiple non-existent filenames
> +// for their purposes.
> +static unsigned counter = std::random_device{}();
> +
>  #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 
> 200112L
> -char tmp[] = "filesystem-test.XX";
> +// Use mkstemp to determine the name of a file which does not exist yet.
> +//
> +// Note that we have seen on some systems (such as RTEMS, for instance)
> +// that mkstemp behaves very predictably, causing it to always try
> +// the same sequence of file names.  In other words, if we call mkstemp
> +// with a pattern, delete the file it created (which is what we do, 
> here),
> +// and call mkstemp with the same pattern again, it returns the same
> +// filename once more.  While most implementations introduce a degree
> +// of randomness, it is not mandated by the standard, and this is why
> +// we include a counter in the template passed to mkstemp.
> +std::string mkstemp_template ("filesystem-test.");
> +mkstemp_template.append(std::to_string (counter++));
> +mkstemp_template.append(".XX");
> +
> +char tmp[mkstemp_template.length() + 1];
> +std::strcpy (tmp, mkstemp_template.c_str());

std::string::copy can be used to copy a string into a buffer, but
there's no reason to use another buffer anyway.

The attached makes this a bit more efficient, and makes more of the
code common to the mkstemp and non-mkstmp branches. I'll wait to hear
back from you before pushing it (since it has Joel's name on the
patch).
commit 87d861e3126f6304e8bc9d8e743022a21424
Author: Joel Brobecker 
Date:   Thu Jun 23 13:12:12 2022

libstdc++: testsuite: avoid predicable mkstemp

We have noticed that, on RTEMS, a small number of testscases are
failing because two calls to this method return the same filename.
This happens for instance in 27_io/filesystem/operations/copy_file.cc
where it does:

  auto fro

Re: [PATCH] Inline memchr with a small constant string

2022-06-23 Thread H.J. Lu via Gcc-patches
On Wed, Jun 22, 2022 at 11:03 PM Richard Biener
 wrote:
>
> On Wed, Jun 22, 2022 at 7:13 PM H.J. Lu  wrote:
> >
> > On Wed, Jun 22, 2022 at 4:39 AM Richard Biener
> >  wrote:
> > >
> > > On Tue, Jun 21, 2022 at 11:03 PM H.J. Lu via Gcc-patches
> > >  wrote:
> > > >
> > > > When memchr is applied on a constant string of no more than the bytes of
> > > > a word, inline memchr by checking each byte in the constant string.
> > > >
> > > > int f (int a)
> > > > {
> > > >return  __builtin_memchr ("eE", a, 2) != 0;
> > > > }
> > > >
> > > > is simplified to
> > > >
> > > > int f (int a)
> > > > {
> > > >   return (char) a == 'e' || (char) a == 'E';
> > > > }
> > > >
> > > > gcc/
> > > >
> > > > PR tree-optimization/103798
> > > > * match.pd (__builtin_memchr (const_str, a, N)): Inline memchr
> > > > with constant strings of no more than the bytes of a word.
> > >
> > > Please do this in strlenopt or so, with match.pd you will end up moving
> > > the memchr loads across possible aliasing stores to the point of the
> > > comparison.
> >
> > strlenopt is run after many other passes.  The code won't be well optimized.
>
> What followup optimizations do you expect?  That is, other builtins are only

reassociation and dce turn

  _5 = a_2(D) == 101;
  _6 = a_2(D) == 69;
  _1 = _5 | _6;
  _4 = (int) _1;

into

  _7 = a_2(D) & -33;
  _8 = _7 == 69;
  _1 = _8;
  _4 = (int) _1;

> expanded inline at RTL expansion time?

Some high level optimizations will be missed and
TARGET_GIMPLE_FOLD_BUILTIN improves builtins
codegen.

> > Since we are only optimizing
> >
> > __builtin_memchr ("eE", a, 2) != 0;
> >
> > I don't see any aliasing store issues here.
>
> Ah, I failed to see the STRING_CST restriction.  Note that when optimizing for
> size this doesn't look very good.

True.

> I would expect a target might produce some vector code for
> memchr ("aAbBcCdDeE...", c, 9) != 0 by splatting 'c', doing
> a v16qimode compare, masking off excess elements beyond length
> and then comparing against zero or for == 0 against all-ones.
>
> The repetitive pattern result also suggests an implementation elsewhere,
> if you think strlenopt is too late there would be forwprop as well.

forwprop seems a good place.

Thanks.

> Richard.
>
>
>
> > > Richard.
> > >
> > > > gcc/testsuite/
> > > >
> > > > PR tree-optimization/103798
> > > > * c-c++-common/pr103798-1.c: New test.
> > > > * c-c++-common/pr103798-2.c: Likewise.
> > > > * c-c++-common/pr103798-3.c: Likewise.
> > > > * c-c++-common/pr103798-4.c: Likewise.
> > > > * c-c++-common/pr103798-5.c: Likewise.
> > > > * c-c++-common/pr103798-6.c: Likewise.
> > > > * c-c++-common/pr103798-7.c: Likewise.
> > > > * c-c++-common/pr103798-8.c: Likewise.
> > > > ---
> > > >  gcc/match.pd| 136 
> > > >  gcc/testsuite/c-c++-common/pr103798-1.c |  28 +
> > > >  gcc/testsuite/c-c++-common/pr103798-2.c |  30 ++
> > > >  gcc/testsuite/c-c++-common/pr103798-3.c |  28 +
> > > >  gcc/testsuite/c-c++-common/pr103798-4.c |  28 +
> > > >  gcc/testsuite/c-c++-common/pr103798-5.c |  26 +
> > > >  gcc/testsuite/c-c++-common/pr103798-6.c |  27 +
> > > >  gcc/testsuite/c-c++-common/pr103798-7.c |  27 +
> > > >  gcc/testsuite/c-c++-common/pr103798-8.c |  27 +
> > > >  9 files changed, 357 insertions(+)
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-1.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-2.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-3.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-4.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-5.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-6.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-7.c
> > > >  create mode 100644 gcc/testsuite/c-c++-common/pr103798-8.c
> > > >
> > > > diff --git a/gcc/match.pd b/gcc/match.pd
> > > > index a63b649841b..aa4766749af 100644
> > > > --- a/gcc/match.pd
> > > > +++ b/gcc/match.pd
> > > > @@ -7976,3 +7976,139 @@ and,
> > > >  (match (bitwise_induction_p @0 @2 @3)
> > > >   (bit_not
> > > >(nop_convert1? (bit_xor@0 (convert2? (lshift integer_onep@1 @2)) 
> > > > @3
> > > > +
> > > > +#if GIMPLE
> > > > +/* __builtin_memchr (const_str, a, N) != 0 ->
> > > > +   a == const_str[0] .. || a == const_str[N-1]
> > > > +   __builtin_memchr (const_str, a, N) == 0 ->
> > > > +   a != const_str[0] .. && a != const_str[N-1]
> > > > +   where N is less than the string size.  */
> > > > +(for cmp (eq ne)
> > > > + icmp (ne eq)
> > > > + bit_op (bit_and bit_ior)
> > > > + (simplify (cmp:c @0 (BUILT_IN_MEMCHR ADDR_EXPR@1 @2 INTEGER_CST@3))
> > > > +  (if (UNITS_PER_WORD <= 8
> > > > +   && CHAR_TYPE_SIZE == 8
> > > > +   && BITS_PER_UNIT == 8
> > > > +   && CHAR_BIT == 8
> > > > +   && integer_zerop (@0)
> > > > +  

[committed] libstdc++: Properly remove temporary directories in filesystem tests

2022-06-23 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux, pushed to trunk.

-- >8 --

Although these tests use filesystem::remove_all to clean up, that fails
because it uses recursive_directory_iterator which is intentionally
bodged by the custom readdir defined in the test.

Just use POSIX rmdir to clean up. We don't need to use _rmdir or _wrmdir
for Windows, because we'll never reach test02() on targets where the
custom readdir doesn't interpose the one from libc.

libstdc++-v3/ChangeLog:

* testsuite/27_io/filesystem/iterators/error_reporting.cc: Use
rmdir to remove directories.
* testsuite/experimental/filesystem/iterators/error_reporting.cc:
Likewise.
---
 .../27_io/filesystem/iterators/error_reporting.cc| 9 +++--
 .../experimental/filesystem/iterators/error_reporting.cc | 9 +++--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
index 1c8ea4c9249..a26b29f0974 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/iterators/error_reporting.cc
@@ -107,7 +107,7 @@ void
 test02()
 {
   namespace fs = std::filesystem;
-  auto dir = __gnu_test::nonexistent_path();
+  const auto dir = __gnu_test::nonexistent_path();
   fs::create_directories(dir/"subdir");
 
   std::error_code ec;
@@ -137,7 +137,12 @@ test02()
   }
 #endif
 
-  fs::remove_all(dir, ec);
+  // Cannot use fs::remove_all here because that uses
+  // recursive_directory_iterator which would use the fake readdir above.
+#ifndef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  ::rmdir((dir/"subdir").c_str());
+  ::rmdir(dir.c_str());
+#endif
 }
 
 int
diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
index 806c511ebef..f005b7d5293 100644
--- 
a/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
+++ 
b/libstdc++-v3/testsuite/experimental/filesystem/iterators/error_reporting.cc
@@ -99,7 +99,7 @@ void
 test02()
 {
   namespace fs = std::experimental::filesystem;
-  auto dir = __gnu_test::nonexistent_path();
+  const auto dir = __gnu_test::nonexistent_path();
   fs::create_directories(dir/"subdir");
 
   std::error_code ec;
@@ -129,7 +129,12 @@ test02()
   }
 #endif
 
-  fs::remove_all(dir, ec);
+  // Cannot use fs::remove_all here because that depends on
+  // recursive_directory_iterator which would use the fake readdir above.
+#ifndef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  ::rmdir((dir/"subdir").c_str());
+  ::rmdir(dir.c_str());
+#endif
 }
 
 int
-- 
2.36.1



[PATCH, libgomp] Fix chunk_size<1 for dynamic schedule

2022-06-23 Thread Chung-Lin Tang

Hi Jakub,
with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:

(1) chunk_size <= -1: wraps into large unsigned value, seems to work though.
(2) chunk_size == 0:  infinite loop

The (2) behavior is obviously not desired. This patch fixes this by changing
the chunk_size initialization in gomp_loop_init to "max(1,chunk_size)"

The OMP_SCHEDULE parsing in libgomp/env.c has also been adjusted to reject
negative values.

Tested without regressions, and a new testcase for the infinite loop behavior 
added.
Okay for trunk?

Thanks,
Chung-Lin

libgomp/ChangeLog:
* env.c (parse_schedule): Make negative values invalid for chunk_size.
* loop.c (gomp_loop_init): For non-STATIC schedule and chunk_size <= 0,
set initialized chunk_size to 1.

* testsuite/libgomp.c/loop-28.c: New test.diff --git a/libgomp/env.c b/libgomp/env.c
index 1c4ee894515..dff07617e15 100644
--- a/libgomp/env.c
+++ b/libgomp/env.c
@@ -182,6 +182,8 @@ parse_schedule (void)
 goto invalid;
 
   errno = 0;
+  if (*env == '-')
+goto invalid;
   value = strtoul (env, &end, 10);
   if (errno || end == env)
 goto invalid;
diff --git a/libgomp/loop.c b/libgomp/loop.c
index be85162bb1e..018b4e9a8bd 100644
--- a/libgomp/loop.c
+++ b/libgomp/loop.c
@@ -41,7 +41,7 @@ gomp_loop_init (struct gomp_work_share *ws, long start, long 
end, long incr,
enum gomp_schedule_type sched, long chunk_size)
 {
   ws->sched = sched;
-  ws->chunk_size = chunk_size;
+  ws->chunk_size = (sched == GFS_STATIC || chunk_size > 1) ? chunk_size : 1;
   /* Canonicalize loops that have zero iterations to ->next == ->end.  */
   ws->end = ((incr > 0 && start > end) || (incr < 0 && start < end))
? start : end;
diff --git a/libgomp/testsuite/libgomp.c/loop-28.c 
b/libgomp/testsuite/libgomp.c/loop-28.c
new file mode 100644
index 000..e3f852046f4
--- /dev/null
+++ b/libgomp/testsuite/libgomp.c/loop-28.c
@@ -0,0 +1,17 @@
+/* { dg-do run } */
+/* { dg-timeout 10 } */
+
+void __attribute__((noinline))
+foo (int a[], int n, int chunk_size)
+{
+  #pragma omp parallel for schedule (dynamic,chunk_size)
+  for (int i = 0; i < n; i++)
+a[i] = i;
+}
+
+int main (void)
+{
+  int a[100];
+  foo (a, 100, 0);
+  return 0;
+}


[pushed] c++: -Waddress and if constexpr [PR94554]

2022-06-23 Thread Jason Merrill via Gcc-patches
Like we avoid various warnings for seemingly tautological expressions when
substituting a template, we should avoid warning for the implicit conversion
to bool in an if statement.  I considered also doing this for the conditions
in loop expressions, but that seems unnecessary, as a loop condition is
unlikely to be a constant.

The change to finish_if_stmt_cond isn't necessary since dependent_operand_p
looks through IMPLICIT_CONV_EXPR, but makes it more constent with
e.g. build_x_binary_op that determines the type of an expression and then
builds it using the original operands.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/94554

gcc/cp/ChangeLog:

* pt.cc (dependent_operand_p): Split out from...
(tsubst_copy_and_build): ...here.
(tsubst_expr) [IF_STMT]: Use it.
* semantics.cc (finish_if_stmt_cond): Keep the pre-conversion
condition in the template tree.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if38.C: New test.
---
 gcc/cp/pt.cc| 43 +++--
 gcc/cp/semantics.cc | 10 +++--
 gcc/testsuite/g++.dg/cpp1z/constexpr-if38.C | 16 
 3 files changed, 55 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if38.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 4535c14c26a..12a2b57d9e3 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -18547,6 +18547,29 @@ lookup_init_capture_pack (tree decl)
   return r;
 }
 
+/* T is an operand of a template tree being substituted.  Return whether
+   T is dependent such that we should suppress some warnings that would
+   make sense if the substituted expression were written directly, like
+ template  bool f() { return I == 2; }
+   We don't want to warn when instantiating f that comparing two constants
+   always has the same value.
+
+   This is a more limited concept of dependence than instantiation-dependent;
+   here we don't care whether substitution could fail.  */
+
+static bool
+dependent_operand_p (tree t)
+{
+  while (TREE_CODE (t) == IMPLICIT_CONV_EXPR)
+t = TREE_OPERAND (t, 0);
+  ++processing_template_decl;
+  bool r = (potential_constant_expression (t)
+   ? value_dependent_expression_p (t)
+   : type_dependent_expression_p (t));
+  --processing_template_decl;
+  return r;
+}
+
 /* Like tsubst_copy for expressions, etc. but also does semantic
processing.  */
 
@@ -18872,8 +18895,13 @@ tsubst_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl,
   IF_STMT_CONSTEVAL_P (stmt) = IF_STMT_CONSTEVAL_P (t);
   if (IF_STMT_CONSTEXPR_P (t))
args = add_extra_args (IF_STMT_EXTRA_ARGS (t), args, complain, in_decl);
-  tmp = RECUR (IF_COND (t));
-  tmp = finish_if_stmt_cond (tmp, stmt);
+  {
+   tree cond = IF_COND (t);
+   bool was_dep = dependent_operand_p (cond);
+   cond = RECUR (cond);
+   warning_sentinel s1(warn_address, was_dep);
+   tmp = finish_if_stmt_cond (cond, stmt);
+  }
   if (IF_STMT_CONSTEXPR_P (t)
  && instantiation_dependent_expression_p (tmp))
{
@@ -20422,15 +20450,8 @@ tsubst_copy_and_build (tree t,
   warnings that depend on the range of the types involved.  */
tree op0 = TREE_OPERAND (t, 0);
tree op1 = TREE_OPERAND (t, 1);
-   auto dep_p = [](tree t) {
- ++processing_template_decl;
- bool r = (potential_constant_expression (t)
-   ? value_dependent_expression_p (t)
-   : type_dependent_expression_p (t));
- --processing_template_decl;
- return r;
-   };
-   const bool was_dep = dep_p (op0) || dep_p (op1);
+   const bool was_dep = (dependent_operand_p (op0)
+ || dependent_operand_p (op1));
op0 = RECUR (op0);
op1 = RECUR (op1);
 
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 24cca99e909..2344b5eea00 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -1029,9 +1029,9 @@ maybe_warn_for_constant_evaluated (tree cond, bool 
constexpr_if)
IF_STMT.  */
 
 tree
-finish_if_stmt_cond (tree cond, tree if_stmt)
+finish_if_stmt_cond (tree orig_cond, tree if_stmt)
 {
-  cond = maybe_convert_cond (cond);
+  tree cond = maybe_convert_cond (orig_cond);
   if (IF_STMT_CONSTEXPR_P (if_stmt)
   && !type_dependent_expression_p (cond)
   && require_constant_expression (cond)
@@ -1045,7 +1045,11 @@ finish_if_stmt_cond (tree cond, tree if_stmt)
   cond = cxx_constant_value (cond, NULL_TREE);
 }
   else
-maybe_warn_for_constant_evaluated (cond, /*constexpr_if=*/false);
+{
+  maybe_warn_for_constant_evaluated (cond, /*constexpr_if=*/false);
+  if (processing_template_decl)
+   cond = orig_cond;
+}
   finish_cond (&IF_COND (if_stmt), cond);
   add_stmt (if_stmt);
   THEN_CLAUSE (if_stmt) = push_stmt_list ();
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if38.C 
b/gcc/testsuit

[pushed] c++: -Waddress and value-dependent expr [PR105885]

2022-06-23 Thread Jason Merrill via Gcc-patches
We already suppress various warnings for code that would be tautological if
written directly, but not when it's the result of template substitution.  It
seems we need to do this for -Waddress as well.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/105885

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build): Also suppress -Waddress for
comparison of dependent operands.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if37.C: New test.
---
 gcc/cp/pt.cc|  1 +
 gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C | 21 +
 2 files changed, 22 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 80d2bec2348..4535c14c26a 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -20438,6 +20438,7 @@ tsubst_copy_and_build (tree t,
warning_sentinel s2(warn_div_by_zero, was_dep);
warning_sentinel s3(warn_logical_op, was_dep);
warning_sentinel s4(warn_tautological_compare, was_dep);
+   warning_sentinel s5(warn_address, was_dep);
 
tree r = build_x_binary_op
  (input_location, TREE_CODE (t),
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C 
b/gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C
new file mode 100644
index 000..e11e02cfa0e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if37.C
@@ -0,0 +1,21 @@
+// PR c++/105885
+// { dg-do compile { target c++17 } }
+// { dg-additional-options -Wall }
+
+int i;
+
+template
+void test() {
+  if constexpr(ARG == nullptr) {
+++i;
+  } else {
+--i;
+  }
+}
+
+const char CONSTSTR[] = {'\n', '\t', ' ', '\0'};
+
+int main() {
+  test();
+  test();
+}

base-commit: 8a15cd3396aa08dc2633982481fe392af0aa9e78
-- 
2.27.0



[PATCH] c++: constexpr folding in unevaluated context [PR105931]

2022-06-23 Thread Patrick Palka via Gcc-patches
Changing the type of N from int to unsigned in decltype82.C from
r12-8472-g47ea22015c90df reveals another spot where we perform
constexpr evaluation in an unevaluated context for sake of diagnostics,
this time from the call to shorten_compare in cp_build_binary_op,
which calls fold_for_warn.

We could (and probably should?) suppress the shorten_compare diagnostics
when in an unevaluated context, but there's probably other spots
that have the same bug.  So this patch takes the approach of suppressing
fold_for_warn more generally when in an unevaluated context.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/12?

PR c++/105931

gcc/cp/ChangeLog:

* expr.cc (fold_for_warn): Don't fold when in an unevaluated
context.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/decltype82a.C: New test.
---
 gcc/cp/expr.cc   |  5 +
 gcc/testsuite/g++.dg/cpp0x/decltype82a.C | 11 +++
 2 files changed, 16 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype82a.C

diff --git a/gcc/cp/expr.cc b/gcc/cp/expr.cc
index 31fe0980337..b71245f937d 100644
--- a/gcc/cp/expr.cc
+++ b/gcc/cp/expr.cc
@@ -397,6 +397,11 @@ fold_for_warn (tree x)
 {
   /* C++ implementation.  */
 
+  if (cp_unevaluated_operand)
+/* In an unevaluated context, we don't care about the reduced value
+   of an expression, so neither should any warnings.  */
+return x;
+
   /* Prevent warning-dependent constexpr evaluation from changing
  DECL_UID (which breaks -fcompare-debug) and from instantiating
  templates.  */
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype82a.C 
b/gcc/testsuite/g++.dg/cpp0x/decltype82a.C
new file mode 100644
index 000..cbbcdfd8e58
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype82a.C
@@ -0,0 +1,11 @@
+// PR c++/105931
+// { dg-do compile { target c++11 } }
+// A version of decltype82.C where N is unsigned.
+
+template
+void f() {
+  using ty1 = decltype((5 % N) == 0);
+  using ty2 = decltype((5 / N) == 0);
+}
+
+template void f<0>();
-- 
2.37.0.rc1



[PATCH] c++: context completion in lookup_template_class [PR105982]

2022-06-23 Thread Patrick Palka via Gcc-patches
The below testcase demonstrates that completion of the substituted
context during lookup_template_class can end up registering the desired
specialization for us in more cases than r13-1045-gcb7fd1ea85feea
anticipated.  In particular, it can happen for a non-dependent
specialization of a nested class as well.

During overload resolution with A's guides, we substitute the deduced
argument T=int into the TYPENAME_TYPE B::C (*).  This substitution calls
lookup_template_class for A::B with T=int, which completes A
for the first time, which recursively registers the desired specialization
of B for us.  The parent call to lookup_template_class then tries
registering the same specialization, which leads to a crash.

This patch fixes this by making lookup_template_class check the
specializations table after completion of the context iff necessary,
i.e. when the call to complete_type actually has an effect.

(*): Note that the TYPE_CONTEXT of this TYPENAME_TYPE is just the
RECORD_TYPE B instead of TYPENAME_TYPE A::B.  Is this expected?
I'd think maybe_dependent_member_ref would rewrite the reference to B
in terms of another TYPENAME_TYPE.  This is why the testcase needs to
use 'typename B::C' instead of just 'B' -- maybe_dependent_member_ref
rewrites the use of B in the latter case but not the former.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

PR c++/105982

gcc/cp/ChangeLog:

* pt.cc (lookup_template_class): After completion of the
substituted context, check the table again iff the type was
previously incomplete and complete_type made it complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction111.C: New test.
---
 gcc/cp/pt.cc  | 21 +++
 .../g++.dg/cpp1z/class-deduction111.C | 10 +
 2 files changed, 22 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction111.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 28edc6ae988..eeae867a816 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10089,16 +10089,19 @@ lookup_template_class (tree d1, tree arglist, tree 
in_decl, tree context,
{
  context = tsubst_aggr_type (context, arglist,
  complain, in_decl, true);
- context = complete_type (context);
- if (is_dependent_type && arg_depth > 1)
+ /* Try completing the enclosing context if it's not already so.  
*/
+ if (context != error_mark_node
+ && !COMPLETE_TYPE_P (context))
{
- /* If this is a dependent nested specialization such as
-A::B [with T=int, U=U], then completion of A
-could have caused to register the desired specialization
-of B already, so check the table again (33959).  */
- entry = type_specializations->find_with_hash (&elt, hash);
- if (entry)
-   return entry->spec;
+ context = complete_type (context);
+ if (COMPLETE_TYPE_P (context))
+   {
+ /* Completion could have caused us to register the desired
+specialization for us, so check the table again.  */
+ entry = type_specializations->find_with_hash (&elt, hash);
+ if (entry)
+   return entry->spec;
+   }
}
}
}
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C
new file mode 100644
index 000..2406529ea5a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction111.C
@@ -0,0 +1,10 @@
+// PR c++/105982
+// { dg-do compile { target c++17 } }
+
+template
+struct A {
+  struct B { struct C { }; };
+  A(T, typename B::C);
+};
+
+A a(0, {});
-- 
2.37.0.rc1



Re: [PATCH] libstdc++-v3: check for openat

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Jonathan Wakely  wrote:

> On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva  wrote:
>> 
>> On Jun 22, 2022, Jonathan Wakely  wrote:
>> 
>> > There are other interactions between AT_CDCWD and ::openat not covered
>> > by this patch. I this this also needs to check HAVE_OPENAT:
>> 
>> Here's an updated version, tested with this additional change.

> Did this improve your test results for directory iterators?

'fraid the bad results I posted earlier today had this patch in.  I
can't tell whether it improved anything because I didn't save earlier
results to compare.

> In the unlikely even that the target has ::unlinkat but not ::openat

c++config.h on the target says:

/* #undef _GLIBCXX_HAVE_UNLINKAT */

Thanks for the concern,

-- 
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.  Ask me about 


Add fnspec attributes to cxa_* functions

2022-06-23 Thread Jan Hubicka via Gcc-patches
Hi,
this patch adds fnspecs for cxa_* functions in except.cc.  Main goal is to make
modref to see proper side-effects of functions which may throw. So in general
we get
 - cxa_allocate_exception
which gets the same annotations as malloc (since it is kind of same thing)
 - cxa_free_exception
which gets the same annotations as free
 - cxa_throw which is marked as const except for first parameter which is 
believed
that it makes it escape (which is necessary) and modify (which is not 
necessary
but it would matter inly if we would like to do constant propagation across
EH edges.

Honza
 
gcc/cp/ChangeLog:

2022-06-23  Jan Hubicka  

* except.cc (declare_library_fn_1): Add fnspec parameter.
(declare_library_fn): Add fnspec parameter.
(do_allocate_exception): Declare fnspecs.
(do_free_exception): Declare fnspecs.
(build_throw): Declare fnspecs.

gcc/testsuite/ChangeLog:

2022-06-23  Jan Hubicka  

* g++.dg/opt/eh6.C: New test.
* g++.dg/tree-ssa/kill.C: New test.

diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
index da0a65c613d..bb9a5aee6da 100644
--- a/gcc/cp/except.cc
+++ b/gcc/cp/except.cc
@@ -133,13 +133,14 @@ build_exc_ptr (void)
 }
 
 /* Declare an exception ABI entry point called NAME.
-   ECF are the library flags, RTYPE the return type and ARGS[NARGS]
+   ECF are the library flags, FNSPEC is the attr "fn spec" string (or NULL),
+   RTYPE the return type and ARGS[NARGS]
the parameter types.  We return the DECL -- which might be one
found via the symbol table pushing, if the user already declared
it.  If we pushed a new decl, the user will see it.  */
 
 static tree
-declare_library_fn_1 (const char *name, int ecf,
+declare_library_fn_1 (const char *name, int ecf, const char *fnspec,
  tree rtype, int nargs, tree args[])
 {
   tree ident = get_identifier (name);
@@ -150,6 +151,14 @@ declare_library_fn_1 (const char *name, int ecf,
   for (unsigned ix = nargs; ix--;)
 arg_list = tree_cons (NULL_TREE, args[ix], arg_list);
   tree fntype = build_function_type (rtype, arg_list);
+  if (fnspec)
+{
+  tree attr_args = build_tree_list (NULL_TREE,
+   build_string (strlen (fnspec), fnspec));
+  tree attrs = tree_cons (get_identifier ("fn spec"),
+ attr_args, TYPE_ATTRIBUTES (fntype));
+  fntype = build_type_attribute_variant (fntype, attrs);
+}
   tree res = push_library_fn (ident, fntype, except, ecf);
 
   return res;
@@ -157,7 +166,8 @@ declare_library_fn_1 (const char *name, int ecf,
 
 /* Find or declare a function NAME, returning RTYPE, taking a single
parameter PTYPE, with an empty exception specification. ECF are the
-   library fn flags.  If TM_ECF is non-zero, also find or create a
+   library fn flags.  FNSPEC is the attr "fn spec" string (or NULL).
+   If TM_ECF is non-zero, also find or create a
transaction variant and record it as a replacement, when flag_tm is
in effect.
 
@@ -167,9 +177,10 @@ declare_library_fn_1 (const char *name, int ecf,
 
 static tree
 declare_library_fn (const char *name, tree rtype, tree ptype,
-   int ecf, int tm_ecf)
+   int ecf, int tm_ecf, const char *fnspec = NULL)
 {
-  tree res = declare_library_fn_1 (name, ecf, rtype, ptype ? 1 : 0, &ptype);
+  tree res = declare_library_fn_1 (name, ecf, fnspec,
+  rtype, ptype ? 1 : 0, &ptype);
   if (res == error_mark_node)
 return res;
 
@@ -177,7 +188,7 @@ declare_library_fn (const char *name, tree rtype, tree 
ptype,
 {
   char *tm_name = concat ("_ITM_", name + 2, NULL_TREE);
 
-  tree tm_fn = declare_library_fn_1 (tm_name, ecf | tm_ecf, rtype,
+  tree tm_fn = declare_library_fn_1 (tm_name, ecf | tm_ecf, fnspec, rtype,
 ptype ? 1 : 0, &ptype);
   free (tm_name);
   if (tm_fn != error_mark_node)
@@ -547,7 +558,8 @@ do_allocate_exception (tree type)
 allocate_exception_fn
   = declare_library_fn ("__cxa_allocate_exception",
ptr_type_node, size_type_node,
-   ECF_NOTHROW | ECF_MALLOC | ECF_COLD, ECF_TM_PURE);
+   ECF_NOTHROW | ECF_MALLOC | ECF_COLD, ECF_TM_PURE,
+   "mc");
 
   return cp_build_function_call_nary (allocate_exception_fn,
  tf_warning_or_error,
@@ -565,7 +577,8 @@ do_free_exception (tree ptr)
 free_exception_fn
   = declare_library_fn ("__cxa_free_exception",
void_type_node, ptr_type_node,
-   ECF_NOTHROW | ECF_LEAF, ECF_TM_PURE);
+   ECF_NOTHROW | ECF_LEAF, ECF_TM_PURE,
+   ".co ");
 
   return cp_build_function_call_nary (free_exception_fn,
  tf_warning_or_error, ptr, NULL_TREE);
@@ -653,11 +666,1

Re: Fix stmt_kills_ref_p wrt external throws

2022-06-23 Thread Richard Biener via Gcc-patches
On Thu, 23 Jun 2022, Jan Hubicka wrote:

> Hi,
> this patch adds missing check to stmt_kills_ref_p for case that function
> is terminated by EH before call return value kills the ref. In the PR
> I tried to construct testcase but I don't know how to do that until I 
> annotate EH code with fnspec attributes which I will do in separate patch
> and add a testcase.
> 
> Bootstrapped/regtested x86_64-linux, OK?
> 
>   PR ipa/106057
>   * tree-ssa-alias.cc (stmt_kills_ref_p): Check for external throw.
> diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
> index b1e7a2d5afc..e427ee6744a 100644
> --- a/gcc/tree-ssa-alias.cc
> +++ b/gcc/tree-ssa-alias.cc
> @@ -87,10 +87,11 @@ along with GCC; see the file COPYING3.  If not see
>  
>   This function tries to disambiguate two reference trees.
>  
> -   bool ptr_deref_may_alias_global_p (tree)
> +   bool ptr_deref_may_alias_global_p (tree, bool)
>  
>   This function queries if dereferencing a pointer variable may
> - alias global memory.
> + alias global memory.  If bool argument is true, global memory
> + is considered to also include function local memory that escaped.
>  
> More low-level disambiguators are available and documented in
> this file.  Low-level disambiguators dealing with points-to
> @@ -,11 +3334,18 @@ stmt_kills_ref_p (gimple *stmt, ao_ref *ref)
>&& TREE_CODE (gimple_get_lhs (stmt)) != SSA_NAME
>/* The assignment is not necessarily carried out if it can throw
>and we can catch it in the current function where we could inspect
> -  the previous value.
> +  the previous value.  Similarly if the function can throw externally
> +  and the ref does not diea on the function return.

die.

>???  We only need to care about the RHS throwing.  For aggregate
>assignments or similar calls and non-call exceptions the LHS
> -  might throw as well.  */
> -  && !stmt_can_throw_internal (cfun, stmt))
> +  might throw as well.
> +  ???  We also should care about possible longjmp, but since we
> +  do not understand that longjmp is not using global memory we will
> +  not consider a kill here since the function call will be considered
> +  as possibly using REF.  */
> +  && !stmt_can_throw_internal (cfun, stmt)
> +  && (!stmt_can_throw_external (cfun, stmt)
> +   || !ref_may_alias_global_p (ref, false)))
>  {
>tree lhs = gimple_get_lhs (stmt);
>/* If LHS is literally a base of the access we are done.  */
> @@ -3434,8 +3442,12 @@ stmt_kills_ref_p (gimple *stmt, ao_ref *ref)
> && node->binds_to_current_def_p ()
> && (summary = get_modref_function_summary (node)) != NULL
> && summary->kills.length ()
> +   /* Check that we can not trap while evaulating function
> +  parameters.  This check is overly conservative.  */
> && (!cfun->can_throw_non_call_exceptions
> -   || !stmt_can_throw_internal (cfun, stmt)))
> +   || (!stmt_can_throw_internal (cfun, stmt)
> +   && (!stmt_can_throw_external (cfun, stmt)
> +   || !ref_may_alias_global_p (ref, stmt)

you wanted , false here instead of , stmt?

OK otherwise.

Thanks,
Richard.

>   {
> for (auto kill : summary->kills)
>   {
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstra


Fix stmt_kills_ref_p wrt external throws

2022-06-23 Thread Jan Hubicka via Gcc-patches
Hi,
this patch adds missing check to stmt_kills_ref_p for case that function
is terminated by EH before call return value kills the ref. In the PR
I tried to construct testcase but I don't know how to do that until I 
annotate EH code with fnspec attributes which I will do in separate patch
and add a testcase.

Bootstrapped/regtested x86_64-linux, OK?

PR ipa/106057
* tree-ssa-alias.cc (stmt_kills_ref_p): Check for external throw.
diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
index b1e7a2d5afc..e427ee6744a 100644
--- a/gcc/tree-ssa-alias.cc
+++ b/gcc/tree-ssa-alias.cc
@@ -87,10 +87,11 @@ along with GCC; see the file COPYING3.  If not see
 
  This function tries to disambiguate two reference trees.
 
-   bool ptr_deref_may_alias_global_p (tree)
+   bool ptr_deref_may_alias_global_p (tree, bool)
 
  This function queries if dereferencing a pointer variable may
- alias global memory.
+ alias global memory.  If bool argument is true, global memory
+ is considered to also include function local memory that escaped.
 
More low-level disambiguators are available and documented in
this file.  Low-level disambiguators dealing with points-to
@@ -,11 +3334,18 @@ stmt_kills_ref_p (gimple *stmt, ao_ref *ref)
   && TREE_CODE (gimple_get_lhs (stmt)) != SSA_NAME
   /* The assignment is not necessarily carried out if it can throw
 and we can catch it in the current function where we could inspect
-the previous value.
+the previous value.  Similarly if the function can throw externally
+and the ref does not diea on the function return.
 ???  We only need to care about the RHS throwing.  For aggregate
 assignments or similar calls and non-call exceptions the LHS
-might throw as well.  */
-  && !stmt_can_throw_internal (cfun, stmt))
+might throw as well.
+???  We also should care about possible longjmp, but since we
+do not understand that longjmp is not using global memory we will
+not consider a kill here since the function call will be considered
+as possibly using REF.  */
+  && !stmt_can_throw_internal (cfun, stmt)
+  && (!stmt_can_throw_external (cfun, stmt)
+ || !ref_may_alias_global_p (ref, false)))
 {
   tree lhs = gimple_get_lhs (stmt);
   /* If LHS is literally a base of the access we are done.  */
@@ -3434,8 +3442,12 @@ stmt_kills_ref_p (gimple *stmt, ao_ref *ref)
  && node->binds_to_current_def_p ()
  && (summary = get_modref_function_summary (node)) != NULL
  && summary->kills.length ()
+ /* Check that we can not trap while evaulating function
+parameters.  This check is overly conservative.  */
  && (!cfun->can_throw_non_call_exceptions
- || !stmt_can_throw_internal (cfun, stmt)))
+ || (!stmt_can_throw_internal (cfun, stmt)
+ && (!stmt_can_throw_external (cfun, stmt)
+ || !ref_may_alias_global_p (ref, stmt)
{
  for (auto kill : summary->kills)
{


Re: [PATCH] RISC-V: Split unordered FP comparisons into individual RTL insns

2022-06-23 Thread Maciej W. Rozycki
On Thu, 9 Jun 2022, Maciej W. Rozycki wrote:

>  I'm yet running some benchmarking to see if the use of UNSPEC_VOLATILEs 
> makes any noticeable performance difference, but I suspect it does not as 
> the compiler could not do much about the original multiple-instruction 
> single RTL insns anyway.

 This has now finally completed.  I used SPECfp 2006 built at `-O3' and 
statically linked, which needs ~33 hours per run with the HiFive Unmatched 
board at its standard 1196MHz clock rate.  Here are the results merged by 
hand from original reports:

   Base Base Base Base   Est Base  Est Base  Est Base   
Benchmarks Ref.   Run Time Run Time Run Time   Ratio Ratio Ratio  
   (base)  (length) (split)   (base)   (length)   (split)  
- --  ---  ---  ---       
410.bwaves 135901035310396103701.31  1.31  1.31   
416.gamess 19580 9080 9410 92842.16  2.08  2.11   
433.milc9180 5465 5475 56101.68  1.68  1.64   
434.zeusmp  9100 5773 5767 57611.58  1.58  1.58   
435.gromacs 7140 3605 3561 35451.98  2.00  2.01   
436.cactusADM  11950 7779 7658 76801.54  1.56  1.56   
437.leslie3d94001028010697102740.914 0.879 0.915  
444.namd8020 3141 3120 31292.55  2.57  2.56   
447.dealII 11440 3459 3490 34953.31  3.28  3.27   
450.soplex  8340 4698 4899 47811.78  1.70  1.74   
453.povray  5320 1953 1922 19162.72  2.77  2.78   
454.calculix8250 4844 4857 48211.70  1.70  1.71   
459.GemsFDTD   10610 8703 8957 90281.22  1.18  1.18   
465.tonto   9840 4585 4539 46202.15  2.17  2.13   
470.lbm137401017210945107891.35  1.26  1.27   
481.wrf11170 8516 8646 85841.31  1.29  1.30   
482.sphinx319490 9240 9267 92802.11  2.10  2.10   
==

The execution time reference (second column) is for a Sun Ultra Enterprise 
2 system from 1997, based on a 296MHz UltraSPARC II CPU, times are given 
in seconds (lower is better) and the ratios calculated are in relation to 
the reference (higher is better).

In the table above "base" results are with upstream master as at commit 
7b98910406b5 ("c++: ICE with template NEW_EXPR [PR105803]".  Then "length" 
results are with commit 72b185189f91 ("RISC-V: Reset the length to the 
default of 4 for FP comparisons") applied on top, as it does make changes 
to code produced even at `-O3' (where size matters less than speed), e.g.:

46b2c:  8d01b787fld fa5,-1840(gp) # 7760a8 
<__SDATA_BEGIN__+0xd0>
-   46b30:  66f4b027fsd fa5,1632(s1)
-   46b34:  a029j   46b3e 
-   46b36:  8c01b787fld fa5,-1856(gp) # 776098 
<__SDATA_BEGIN__+0xc0>
-   46b3a:  66f4b027fsd fa5,1632(s1)
-   46b3e:  00ab67b7lui a5,0xab6
-   46b42:  0a07b707fld fa4,160(a5) # ab60a0 
-   46b46:  8d81b787fld fa5,-1832(gp) # 7760b0 
<__SDATA_BEGIN__+0xd8>
-   46b4a:  a2f727d3feq.d   a5,fa4,fa5
-   46b4e:  18079fe3bneza5,474ec 
-   46b52:  00afd7b7lui a5,0xafd
-   46b56:  4607a703lw  a4,1120(a5) # afd460 

-   46b5a:  4785li  a5,1
-   46b5c:  18f708e3beq a4,a5,474ec 
-   46b60:  00aaeab7lui s5,0xaae
-   46b64:  d70a8a93addis5,s5,-656 # aadd70 
-   46b68:  008aa783lw  a5,8(s5)
-   46b6c:  8301b707fld fa4,-2000(gp) # 776008 
<__SDATA_BEGIN__+0x30>
-   46b70:  37fdaddiw   a5,a5,-1
+   46b30:  00ab67b7lui a5,0xab6
+   46b34:  0a07b707fld fa4,160(a5) # ab60a0 
+   46b38:  66f4b027fsd fa5,1632(s1)
+   46b3c:  8d81b787fld fa5,-1832(gp) # 7760b0 
<__SDATA_BEGIN__+0xd8>
+   46b40:  a2f727d3feq.d   a5,fa4,fa5
+   46b44:  c39dbeqza5,46b6a 
+   46b46:  8901b787fld fa5,-1904(gp) # 776068 
<__SDATA_BEGIN__+0x90>
+   46b4a:  66f4b027fsd fa5,1632(s1)
+   46b4e:  a02dj   46b78 
+   46b50:  8c01b787fld fa5,-1856(gp) # 776098 
<__SDATA_BEGIN__+0xc0>
+   46b54:  66f4b027fsd fa5,1632(s1)
+   46b58:  00ab6

[PATCH][PUSHED] c++: properly initialize UBSAN built-ins

2022-06-23 Thread Martin Liška
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Pushed based on Jakub's approval.

Thanks,
Martin

PR c++/106062

gcc/ChangeLog:

* ubsan.cc (sanitize_unreachable_fn): Change order of calls
in order to initialize UBSAN built-ins.

gcc/testsuite/ChangeLog:

* gfortran.dg/ubsan/pr106062.f90: New test.
---
 gcc/testsuite/gfortran.dg/ubsan/pr106062.f90 | 11 +++
 gcc/ubsan.cc |  3 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/ubsan/pr106062.f90

diff --git a/gcc/testsuite/gfortran.dg/ubsan/pr106062.f90 
b/gcc/testsuite/gfortran.dg/ubsan/pr106062.f90
new file mode 100644
index 000..879a67eb749
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/ubsan/pr106062.f90
@@ -0,0 +1,11 @@
+! PR c++/106062
+! { dg-do compile }
+! { dg-options "-O2 -fsanitize=undefined" }
+
+call test (reshape ((/ 'a', 'b', 'c', 'd' /), (/ 2, 2 /)))
+contains
+  subroutine test (a)
+character (*), dimension (:, :) :: a
+if (len (a) .ne. 1) STOP 
+  end  
+end
diff --git a/gcc/ubsan.cc b/gcc/ubsan.cc
index f15026872a1..b6c4301dfaf 100644
--- a/gcc/ubsan.cc
+++ b/gcc/ubsan.cc
@@ -654,9 +654,10 @@ sanitize_unreachable_fn (tree *data, location_t loc)
 }
   else if (san)
 {
-  fn = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE);
+  /* Call ubsan_create_data first as it initializes SANITIZER built-ins.  
*/
   *data = ubsan_create_data ("__ubsan_unreachable_data", 1, &loc,
 NULL_TREE, NULL_TREE);
+  fn = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_BUILTIN_UNREACHABLE);
   *data = build_fold_addr_expr_loc (loc, *data);
 }
   else
-- 
2.36.1



Re: [PATCH] libstdc++: testsuite: fs rename to self may fail

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Jonathan Wakely  wrote:

>> Regstrapped on x86_64-linux-gnu, also tested with a cross to
>> aarch64-rtems6.  Ok to install?

> OK, thanks.

Sorry, I failed to refresh this one too.
Here's what I'm going to install:

libstdc++: xfail rename tests on rtems

From: Alexandre Oliva 

::rename on RTEMS does not meet several POSIX requirements, despite
compliance with C and C++ standards.  ::std::filesystem::rename, in
turn, has requirements borrowed from POSIX, so it would have to be a
lot more than a simple wrapper around ::rename on RTEMS, and even then
fall short.

Until RTEMS reimplements ::rename for POSIX compliance, expect
filesystem rename tests to fail on it.


for  libstdc++-v3/ChangeLog

* testsuite/27_io/filesystem/operations/rename.cc: xfail on
rtems.
* testsuite/experimental/filesystem/operations/rename.cc:
Likewise.
---
 .../27_io/filesystem/operations/rename.cc  |1 +
 .../experimental/filesystem/operations/rename.cc   |1 +
 2 files changed, 2 insertions(+)

diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
index b74e1133a7618..983374f42e448 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++17 } }
 // { dg-require-filesystem-ts "" }
+// { dg-xfail-run-if "rename is not POSIX-compliant" { *-*-rtems* } }
 
 #include 
 #include 
diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
index 37e743b770fdf..762b943888f9e 100644
--- a/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
+++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
@@ -18,6 +18,7 @@
 // { dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" }
 // { dg-do run { target c++11 } }
 // { dg-require-filesystem-ts "" }
+// { dg-xfail-run-if "rename is not POSIX-compliant" { *-*-rtems* } }
 
 #include 
 #include 


-- 
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.  Ask me about 


Re: [PATCH] libstdc++: testsuite: use -lbsd for net_ts on RTEMS

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Jonathan Wakely  wrote:

> On Thu, 23 Jun 2022 at 12:26, Alexandre Oliva via Libstdc++
>  wrote:

>> I was using something like this internally.  Regstrapped on
>> x86_64-linux-gnu, also tested with a cross to aarch64-rtems6.  Ok to
>> install?

> OK, thanks.

Sorry, I goofed when testing this, and another internal xfail machinery
hid the bug: I had to use dg-xfail-run-if instead.

I caught that later, but it looks like I failed to refresh the xfail
patchfiles I posted :-(

I'm going ahead and check it in assuming this is what you meant to
approve, but only after catching some sleep, because it's been a long
day and I don't want any more goofs ;-)


libstdc++: xfail io_context/pipe users on rtems

From: Alexandre Oliva 

A handful of tests fail on rtems because pipe() always returns -1, and
the io_context ctor throws a system error when pipe() fails.


for  libstdc++-v3/ChangeLog

* testsuite/experimental/net/timer/waitable/cons.cc: xfail on
RTEMS.
* testsuite/experimental/net/timer/waitable/dest.cc: Likewise.
* testsuite/experimental/net/timer/waitable/ops.cc: Likewise.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc:
Likewise.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc:
Likewise.

TN: V617-003
---
 .../net/internet/resolver/ops/lookup.cc|1 +
 .../net/internet/resolver/ops/reverse.cc   |1 +
 .../experimental/net/timer/waitable/cons.cc|1 +
 .../experimental/net/timer/waitable/dest.cc|1 +
 .../experimental/net/timer/waitable/ops.cc |1 +
 5 files changed, 5 insertions(+)

diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
index eb411dea8369c..0ac9cb3513d7e 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
@@ -18,6 +18,7 @@
 // { dg-do run { target c++14 } }
 // { dg-require-effective-target net_ts_ip }
 // { dg-add-options net_ts }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
index 361df2676efc8..dfdf855c68cd7 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
@@ -18,6 +18,7 @@
 // { dg-do run { target c++14 } }
 // { dg-require-effective-target net_ts_ip }
 // { dg-add-options net_ts }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc 
b/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
index 40ae5b965a2b0..f013278675d33 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc 
b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
index f571f4a8d861a..dc557d01a9136 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #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 97ab629b893a9..f7549def38925 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 


-- 
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.  Ask me about 


Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 13:36, Alexandre Oliva  wrote:
>
> On Jun 23, 2022, Jonathan Wakely  wrote:
>
> > Could this new arg be given a default value, so every caller doesn't
> > have to pass "" to it?
>
> > proc v3_check_preprocessor_condition { name cond {inc ""} } {
>
> Oh, nice, I didn't know about this convenient notation for default args
> in tcl, and the one I knew about I found too cumbersome.  Thanks for the
> tip, I put it in the patch below.
>
> > #ifndef _GLIBCXX_HAVE_SYMLINK
>
> And this too.
>
> > And if the definition of NO_SYMLINKS gets more complicated in future
> > (e.g. we add something like && !defined __foo__) then using
> > NO_SYMLINKS in the dg proc will keep them in sync.
>
> 'zactly my thinking.
>
>
> Here's what I'm testing (same way).  Ok to install if it passes?

Yes please, thanks for iterating to get this here.



Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Jonathan Wakely  wrote:

> Could this new arg be given a default value, so every caller doesn't
> have to pass "" to it?

> proc v3_check_preprocessor_condition { name cond {inc ""} } {

Oh, nice, I didn't know about this convenient notation for default args
in tcl, and the one I knew about I found too cumbersome.  Thanks for the
tip, I put it in the patch below.

> #ifndef _GLIBCXX_HAVE_SYMLINK

And this too.

> And if the definition of NO_SYMLINKS gets more complicated in future
> (e.g. we add something like && !defined __foo__) then using
> NO_SYMLINKS in the dg proc will keep them in sync.

'zactly my thinking.


Here's what I'm testing (same way).  Ok to install if it passes?


libstdc++: testsuite: conditionalize symlink tests

From: Alexandre Oliva 

Several filesystem tests expect to be able to create symlinks even
when !defined (_GLIBCXX_HAVE_SYMLINK), and fail predictably, reducing
the amount of testing of other filesystem features.

They are already skipped for mingw targets.  I've extended the
skipping to other targets in which _GLIBCXX_HAVE_SYMLINK is undefined,
through a new NO_SYMLINKS macro in testsuite_fs.h that guards
skippable portions of tests, and dg-require-target-fs-symlinks for
tests that would be reduced to nothing.


for  libstdc++-v3/ChangeLog

* testsuite/util/testsuite_fs.h (NO_SYMLINKS): Define on
mingw and when create_symlink is a dummy.
* testsuite/27_io/filesystem/operations/symlink_status.cc:
Drop mingw xfail.
(test01, test02): Don't create symlinks when NO_SYMLINKS is
defined.
* testsuite/27_io/filesystem/operations/canonical.cc (test03):
Likewise.
* testsuite/27_io/filesystem/operations/copy.cc (test02):
Likewise.
* testsuite/27_io/filesystem/operations/create_directories.cc
(test04): Likewise.
* testsuite/27_io/filesystem/operations/create_directory.cc
(test01): Likewise.
* testsuite/27_io/filesystem/operations/permissions.cc
(test03, test04): Likewise.
* testsuite/27_io/filesystem/operations/remove.cc (test01):
Likewise.
* testsuite/27_io/filesystem/operations/remove_all.cc (test01):
Likewise.
* testsuite/27_io/filesystem/operations/rename.cc
(test_symlinks): Likewise.
* testsuite/27_io/filesystem/operations/weakly_canonical.cc
(test01): Likewise.
* 
testsuite/experimental/filesystem/iterators/recursive_directory_itreator.cc
(test06): Likewise.
* testsuite/experimental/filesystem/operations/copy.cc
(test01): Likewise.
* testsuite/experimental/filesystem/operations/create_directories.cc
(test04): Likewise.
* testsuite/experimental/filesystem/operations/create_directory.cc
(test01): Likewise.
* testsuite/experimental/filesystem/operations/permissions.cc
(test03, test04): Likewise.
* testsuite/experimental/filesystem/operations/remove.cc
(test01): Likewise.
* testsuite/experimental/filesystem/operations/remove_all.cc
(test01): Likewise.
* testsuite/experimental/filesystem/operations/rename.cc
(test01): Likewise.
* testsuite/lib/libstdc++.exp
(v3_check_preprocessor_condition): Add optional inc parameter.
Add it to the test program after include bits/c++config.h.
(check_v3_target_fs_symlinks): New.
* testsuite/lib/dg-options.exp
(dg-require-target-fs-symlinks): New.
* testsuite/27_io/filesystem/operations/read_symlink.cc:
Replace mingw xfail with require target-fs-symlinks.
* testsuite/experimental/filesystem/operations/read_symlink.cc:
Likewise.
---
 .../27_io/filesystem/operations/canonical.cc   |5 -
 .../testsuite/27_io/filesystem/operations/copy.cc  |7 ++-
 .../filesystem/operations/create_directories.cc|4 +---
 .../filesystem/operations/create_directory.cc  |4 +---
 .../27_io/filesystem/operations/permissions.cc |4 
 .../27_io/filesystem/operations/read_symlink.cc|2 +-
 .../27_io/filesystem/operations/remove.cc  |4 +---
 .../27_io/filesystem/operations/remove_all.cc  |4 +---
 .../27_io/filesystem/operations/rename.cc  |4 +---
 .../27_io/filesystem/operations/symlink_status.cc  |5 -
 .../filesystem/operations/weakly_canonical.cc  |4 +---
 .../iterators/recursive_directory_iterator.cc  |2 +-
 .../experimental/filesystem/operations/copy.cc |7 ++-
 .../filesystem/operations/create_directories.cc|4 +---
 .../filesystem/operations/create_directory.cc  |4 +---
 .../filesystem/operations/permissions.cc   |4 
 .../filesystem/operations/read_symlink.cc  |2 +-
 .../experimental/filesystem/operations/remove.cc   |5 +
 .../filesystem/operations/remove_all.cc|4 +---
 .../experimental/f

c++: Prune unneeded macro locations

2022-06-23 Thread Nathan Sidwell via Gcc-patches


This implements garbage collection on locations within macro
expansions, when streaming out a CMI.  When doing the reachability
walks, we now note which macro locations we need and then only write
those locations.  The complication here is that every macro expansion
location has an independently calculated offset.  This complicates
writing, but reading remains the same -- the macro locations of a CMI
continue to form a contiguous block.

For std headers this reduced the number of macro maps by 40% and the
number of locations by 16%.  For a GMF including iostream, it reduced
it by 80% and 60% respectively.

Ordinary locations are still transformed en-mass.  They are somewhat
more complicated to apply a similar optimization to.

nathan

--
Nathan SidwellFrom 445cc1266ff8b9b8f96eceafa3c1116da54de967 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell 
Date: Wed, 22 Jun 2022 05:54:30 -0700
Subject: [PATCH] c++: Prune unneeded macro locations

This implements garbage collection on locations within macro
expansions, when streaming out a CMI.  When doing the reachability
walks, we now note which macro locations we need and then only write
those locations.  The complication here is that every macro expansion
location has an independently calculated offset.  This complicates
writing, but reading remains the same -- the macro locations of a CMI
continue to form a contiguous block.

For std headers this reduced the number of macro maps by 40% and the
number of locations by 16%.  For a GMF including iostream, it reduced
it by 80% and 60% respectively.

Ordinary locations are still transformed en-mass.  They are somewhat
more complicated to apply a similar optimization to.

	gcc/cp/
	* module.cc (struct macro_info): New.
	(struct macro_traits): New.
	(macro_remap, macro_table): New globals.
	(depset::hash::find_dependencies): Note namespace location.
	(module_for_macro_loc): Adjust.
	(module_state::note_location): New.
	(module_state::Write_location): Note location when not
	streaming. Adjust macro location streaming.
	(module_state::read_location): Adjust macro location
	streaming.
	(module_state::write_init_maps): New.
	(module_state::write_prepare_maps): Reimplement macro map
	preparation.
	(module_state::write_macro_maps): Reimplement.
	(module_state::read_macro_maps): Likewise.
	(module_state::write_begin): Adjust.
	gcc/testsuite/
	* g++.dg/modules/loc-prune-1.C: New.
	* g++.dg/modules/loc-prune-2.C: New.
	* g++.dg/modules/loc-prune-3.C: New.
	* g++.dg/modules/pr98718_a.C: Adjust.
	* g++.dg/modules/pr98718_b.C: Adjust.
---
 gcc/cp/module.cc   | 349 ++---
 gcc/testsuite/g++.dg/modules/loc-prune-1.C |  19 ++
 gcc/testsuite/g++.dg/modules/loc-prune-2.C |  14 +
 gcc/testsuite/g++.dg/modules/loc-prune-3.C |  16 +
 gcc/testsuite/g++.dg/modules/pr98718_a.C   |   4 +-
 gcc/testsuite/g++.dg/modules/pr98718_b.C   |   6 +-
 6 files changed, 290 insertions(+), 118 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/loc-prune-1.C
 create mode 100644 gcc/testsuite/g++.dg/modules/loc-prune-2.C
 create mode 100644 gcc/testsuite/g++.dg/modules/loc-prune-3.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index d735d7e8b30..7ee779d06b9 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -3238,6 +3238,65 @@ public:
 };
 
 static loc_spans spans;
+
+/* Information about macro locations we stream out.  */
+struct macro_info
+{
+  const line_map_macro *src;// original expansion
+  unsigned remap;	  // serialization
+
+  static int compare (const void *a_, const void *b_)
+  {
+auto *a = static_cast (a_);
+auto *b = static_cast (b_);
+
+gcc_checking_assert (MAP_START_LOCATION (a->src)
+			 != MAP_START_LOCATION (b->src));
+if (MAP_START_LOCATION (a->src) < MAP_START_LOCATION (b->src))
+  return -1;
+else
+  return +1;
+  }
+};
+struct macro_traits
+{
+  typedef macro_info value_type;
+  typedef const line_map_macro *compare_type;
+
+  static const bool empty_zero_p = false;
+
+  static hashval_t hash (compare_type p)
+  {
+return pointer_hash::hash (p);
+  }
+  static hashval_t hash (const value_type &v)
+  {
+return hash (v.src);
+  }
+  static bool equal (const value_type &v, const compare_type p)
+  {
+return v.src == p;
+  }
+
+  static void mark_empty (value_type &v)
+  {
+v.src = nullptr;
+  }
+  static bool is_empty (value_type &v)
+  {
+return !v.src;
+  }
+
+  static bool is_deleted (value_type &) { return false; }
+  static void mark_deleted (value_type &) { gcc_unreachable (); }
+  
+  static void remove (value_type &) {}
+};
+/* Table keyed by line_map_macro, used for noting.  */
+static  hash_table *macro_table;
+/* Sorted vector, used for writing.  */
+static vec *macro_remap;
+
 /* Indirection to allow bsearching imports by ordinary location.  */
 static vec *ool;
 
@@ -3398,7 +3457,7 @@ class GTY((chain_next ("%h.parent"), for_user)) module_state {
   /* Location ranges for this module.  adhoc-locs are decomposed, so
 

[PATCH] fortran, libgfortran: Avoid using libquadmath for glibc 2.26+

2022-06-23 Thread Jakub Jelinek via Gcc-patches
Hi!

As mentioned by Joseph in PR105101, glibc 2.26 or later has on x86
(both -m32/-m64), powerpc64le, ia64 and mips support for
*f128 math/complex APIs plus strtof128 and strfromf128, and these APIs allow
us to avoid libquadmath for Fortran purposes on these architectures,
replace *q math/complex APIs, strtof128 instead of strtoflt128 and,
while strfromf128 unfortunately isn't a perfect replacement to
quadmath_snprintf, it can be made to work.

The advantage of this is that when configured against such glibcs
(2.26 is now almost 5 years old), we can avoid linking against an extra shared
library and the math support in glibc is maintained better than libquadmath.

We need both a compiler change (so that for glibc 2.26+ it uses *f128 APIs
instead of *q) and library change.

The above mentioned problem with strfromf128 is that the strfrom* functions
are severely restricted versions of snprintf.  In libgfortran, we handle
!isfinite differently and just use snprintf/quadmath_snprintf for
%+-#.*{L,Q}{f,e} printing.
strfrom* doesn't allow +, -, # modifiers and it only supports .34 or
similar precision, not .* .  The L/Q etc. letters are omitted.
The + is there to force + sign at the start if it is positive.
Workaround in the patch is to add the + at the start manually for
!signbit (val).
The - (left alignment instead of right) I don't understand why we need it,
when minimum field width isn't specified (for strfrom* can't be specified),
no padding is ever added anywhere I believe.
The # is to force adding . - workaround is to search for first . or e or '\0'
character, if it is '\0', just append ., if it is e, insert . before e and
memmove the rest (which is just a few bytes, e, +/- and at most a few digits)
one byte later.
The .* case is handled by creating the format string for strfrom* by
snprintf into a temporary buffer.

So far lightly tested on x86_64-linux with glibc 2.35 (removed libgfortran
dirs, rebuilt stage3 f951 and make all-target-libgfortran + make
check-gfortran), ok for trunk if it passes full testing?

On powerpc64le-linux, guess we'll need to test 3 configurations, glibc < 2.26,
glibc 2.26 to 2.31 and glibc 2.32 and later.

2022-06-23  Jakub Jelinek  

gcc/fortran/
* gfortran.h (gfc_real_inf0: Add c__Float128 bitfield.
* trans-types.h (gfc_real16_is_float128): Update comment.
(gfc_real16_is__Float128): Declare.
* trans-types.cc (gfc_real16_is__Float128): Define.
(gfc_init_kinds): When building powerpc64le-linux libgfortran
on glibc 2.26 to 2.31, set gfc_real16_is__Float128 and
c__Float128 instead of gfc_real16_is_float128 and c_float128.
(gfc_build_real_type): Don't set c_long_double if c__Float128.
Set gfc_real16_is__Float128 and c__Float128 instead of
gfc_real16_is_float128 and c_float128 on glibc 2.26 or later.
(gfc_init_types): Handle c__Float128 like c_float128.
* trans-intrinsic.cc (builtin_decl_for_precision): Handle
gfc_real16_is__Float128 like gfc_real16_is_float128.
(gfc_builtin_decl_for_float_kind): Handle c__Float128 like c_float128.
(gfc_build_intrinsic_lib_fndecls): For gfc_real16_is__Float128
use *f128 APIs rather than *q APIs used for gfc_real16_is_float128.
(gfc_get_intrinsic_lib_fndecl): Likewise.
* trans-expr.cc (gfc_conv_power_op): Handle gfc_real16_is__Float128
like gfc_real16_is_float128.
libgfortran/
* configure.ac: Check for strtof128 and strfromf128.
Check for math and complex *f128 functions.  Set
have__Float128_libc_support to yes if *f128 support is around, for
--enable-libquadmath-support default to no rather than yes if
have__Float128_libc_support is yes.
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): If libquadmath support
isn't enabled and have__Float128_libc_support is yes, test
_Float128/_Complex _Float128 support and define and subst
HAVE__FLOAT128.
* Makefile.am (kinds.h): Pass @HAVE__FLOAT128@ as an extra
mk-kinds-h.sh argument.
* mk-kinds-h.sh: Accept 4th have__float128 argument, if it is yes,
use _Float128/_Complex _Float128 types insted of __float128 and
_Complex float __attribute__((mode(TC))), use f128 suffix instead
of q and define GFC_REAL_16_IS__FLOAT128 instead of
GFC_REAL_16_IS_FLOAT128.
* kinds-override.h: Add consistency check for GFC_REAL_16_IS__FLOAT128.
* libgfortran.h (GFC_REAL_16_INFINITY, GFC_REAL_16_QUIET_NAN): Define
for GFC_REAL_16_IS__FLOAT128.
* caf/single.c (convert_type): Use _Float128/_Complex _Float128 for
GFC_REAL_16_IS__FLOAT128.  For HAVE_GFC_REAL_10 when HAVE_GFC_REAL_16
isn't defined use _Complex long double instead of long double.
* ieee/issignaling_fallback.h (__issignalingf128): Handle
GFC_REAL_16_IS__FLOAT128.
(issignaling): Likewise.
* ieee/ieee_helper.c: Handle GFC_REAL_16_I

[PATCH] RFC: Optimise SLP permutes of non-consecutive loads

2022-06-23 Thread Richard Sandiford via Gcc-patches
In a reduction pair like:

  typedef float T;

  void
  f1 (T *x)
  {
T res1 = 0;
T res2 = 0;
for (int i = 0; i < 100; ++i)
  {
res1 += x[i * 2];
res2 += x[i * 2 + 1];
  }
x[0] = res1;
x[1] = res2;
  }

it isn't easy to predict whether the initial reduction group will
be { res1, res2 } or { res2, res1 }.  If the initial group ends up
being { res2, res1 }, vect_optimize_slp will try to swap it around
in order to remove an unncessary permute on the load.  This gives:

f1:
.LFB0:
.cfi_startproc
moviv0.4s, 0
mov x1, x0
add x2, x0, 800
.p2align 3,,7
.L2:
ldr q1, [x1], 16
faddv0.4s, v0.4s, v1.4s
cmp x2, x1
bne .L2
dup d1, v0.d[1]
faddv0.2s, v0.2s, v1.2s
str d0, [x0]
ret

But there are no specific ordering constraints for non-consecutive
loads.  For example, in:

  void
  f2 (T *x)
  {
T res1 = 0;
T res2 = 0;
for (int i = 0; i < 100; ++i)
  {
res1 += x[i * 4];
res2 += x[i * 4 + 2];
  }
x[0] = res1;
x[1] = res2;
  }

the reduction group happens to be { res2, res1 }, and so we get
a load permutation of { 2, 0, 6, 4 }.  On aarch64 this gives:

f2:
.LFB1:
.cfi_startproc
adrpx2, .LC0
mov x1, x0
moviv2.4s, 0
ldr q3, [x2, #:lo12:.LC0]
add x2, x0, 1568
.p2align 3,,7
.L6:
ldp q0, q1, [x1]
add x1, x1, 32
tbl v0.16b, {v0.16b - v1.16b}, v3.16b
faddv2.4s, v2.4s, v0.4s
cmp x1, x2
bne .L6
...untidy code, 18 insns...
ret

where we have to load the permute selector from memory and use
the general TBL instruction.  If the order happened to be { res1, res2 }
instead we would generate the much tidier:

f2:
.LFB1:
.cfi_startproc
moviv1.4s, 0
mov x1, x0
add x2, x0, 1568
.p2align 3,,7
.L6:
ldp q0, q2, [x1]
add x1, x1, 32
uzp1v0.4s, v0.4s, v2.4s
faddv1.4s, v1.4s, v0.4s
cmp x1, x2
bne .L6
ldr d0, [x0, 1568]
ldr d5, [x0, 1576]
ldr s2, [x0, 1584]
dup d3, v1.d[1]
ldr s4, [x0, 1592]
zip1v0.2s, v0.2s, v5.2s
ins v2.s[1], v4.s[0]
faddv0.2s, v0.2s, v2.2s
faddv0.2s, v0.2s, v1.2s
faddv0.2s, v0.2s, v3.2s
str d0, [x0]
ret

This WIP patch makes vect_optimize_slp try to put load permutations
into index order.  However, this new transform might be a loss if it
forces permutations elsewhere.  For example, given:

void
f3 (T *restrict x, T *restrict y, T *restrict z)
{
  for (int i = 0; i < 100; ++i)
{
  x[i * 2] = y[i * 4 + 2] + z[i * 4 + 2];
  x[i * 2 + 1] = y[i * 4] + z[i * 4];
}
}

we would generate:

.L9:
ldr q0, [x1, x3]
ldr q3, [x6, x3]
ldr q1, [x2, x3]
ldr q2, [x5, x3]
add x3, x3, 32
uzp1v0.4s, v0.4s, v3.4s
uzp1v1.4s, v1.4s, v2.4s
faddv0.4s, v0.4s, v1.4s
rev64   v0.4s, v0.4s
str q0, [x4], 16
cmp x3, 1568
bne .L9

(3 permutes) rather than:

.L9:
ldr q0, [x1, x3]
ldr q1, [x6, x3]
ldr q2, [x2, x3]
ldr q3, [x5, x3]
tbl v0.16b, {v0.16b - v1.16b}, v4.16b
add x3, x3, 32
tbl v2.16b, {v2.16b - v3.16b}, v4.16b
faddv0.4s, v0.4s, v2.4s
str q0, [x4], 16
cmp x3, 1568
bne .L9

(2 permutes).

One simple(ish) fix would be to conditionalise the new case on
whether all "roots" of the load are reduction groups.  Alternatively,
we could treat the new case as a soft preference and back out if it
would require any new VEC_PERM_EXPR nodes to be created.  This would
require a propagation back from uses to definitions.

WDYT?  Does this look like a feasible direction?  If so, any thoughts
on when the new case should be enabled?

The patch keeps the bijection requirement, since relaxing that seems
like separate work.

Tested on aarch64-linux-gnu, no regressions.

Thanks,
Richard

---
 gcc/tree-vect-slp.cc | 41 ++---
 1 file changed, 14 insertions(+), 27 deletions(-)

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index dab5daddcc5..fde35d8c954 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -20,6 +20,7 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+#define INCLUDE_ALGORITHM
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
@@ -3698,43 +3699,29 @@ vect_optimize_slp (vec_info *vinfo)
   if (!STMT_VINFO_GROUPED_ACCESS (dr_stmt))
continue;
   dr_stmt = DR_GROUP_FIRST_ELEMENT (dr_stmt);
-

Re: [PATCH] testsuite: Compile slsr-39.c without vectorisation

2022-06-23 Thread Richard Biener via Gcc-patches
On Thu, Jun 23, 2022 at 12:51 PM Richard Sandiford via Gcc-patches
 wrote:
>
> The fix for PR106019 regressed slsr-39.c for -m32 -march=cascadelake
> because we are now able to vectorise the code.  (Whether the code model
> should be allowing that is a different question -- the vectorised code
> looked worse to me.)
>
> The test runs at -O2 and predates vectorisation being enabled at -O2,
> so this patch just adds -fno-tree-vectorize.
>
> Tested on x86_64-linux-gnu.  Perhaps bordering on the obvious,
> but just in case: OK to install?

OK.

> (We do still share the multiplication, it's just that with
> vectorisation we share it fewer times.)
>
> Richard
>
>
> gcc/testsuite/
> * gcc.dg/tree-ssa/slsr-39.c: Force vectorization off.
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c
> index 4a27ede1541..33e34fab7ca 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c
> @@ -6,7 +6,7 @@
>  *PINDEX:   C1 + (C2 * C3) + C4  */
>
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -fdump-tree-slsr-details" } */
> +/* { dg-options "-O2 -fno-tree-vectorize -fdump-tree-slsr-details" } */
>
>  typedef int arr_2[50][50];
>
> --
> 2.25.1
>


Re: [PATCH] libstdc++: testsuite: use -lbsd for net_ts on RTEMS

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 12:26, Alexandre Oliva via Libstdc++
 wrote:
>
> On Jun 23, 2022, Jonathan Wakely  wrote:
>
> > On Thu, 23 Jun 2022, 10:02 Sebastian Huber, <
> > sebastian.hu...@embedded-brains.de> wrote:
>
> >> On 22/06/2022 07:24, Alexandre Oliva via Gcc-patches wrote:
> >> > +} elseif { [istarget *-*-rtems*] } {
> >> > + # Adding -Wl,--gc-sections would enable a few more tests to
> >> > + # link, but all of them fail at runtime anyway, because the
> >> > + # io_context ctor calls pipe(), which always fails, and thus
> >> > + # the ctor throws a system error.
> >> > + return "$flags -lbsd"
> >>
> >> Using -Wl,--gc-sections is mandatory if you want to link against
> >> libbsd.a.
>
> Weirdly, it worked for all other testcases.
>
> >> For pipe() support in RTEMS, you currently need the
>
> >> #define CONFIGURE_IMFS_ENABLE_MKFIFO
>
> Thanks, I'll reach out to the person in charge of our rtems
> configuration for this project, and suggest enabling it on our end.
>
>
> > It would also be fine to just xfail the networking tests for rtems.
>
> I was using something like this internally.  Regstrapped on
> x86_64-linux-gnu, also tested with a cross to aarch64-rtems6.  Ok to
> install?

OK, thanks.


>
>
> libstdc++: xfail io_context/pipe users on rtems
>
> From: Alexandre Oliva 
>
> A handful of tests fail on rtems because pipe() always returns -1, and
> the io_context ctor throws a system error when pipe() fails.
>
>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/experimental/net/timer/waitable/cons.cc: xfail on
> RTEMS.
> * testsuite/experimental/net/timer/waitable/dest.cc: Likewise.
> * testsuite/experimental/net/timer/waitable/ops.cc: Likewise.
> * testsuite/experimental/net/internet/resolver/ops/lookup.cc:
> Likewise.
> * testsuite/experimental/net/internet/resolver/ops/reverse.cc:
> Likewise.
>
> TN: V617-003
> ---
>  .../net/internet/resolver/ops/lookup.cc|1 +
>  .../net/internet/resolver/ops/reverse.cc   |1 +
>  .../experimental/net/timer/waitable/cons.cc|1 +
>  .../experimental/net/timer/waitable/dest.cc|1 +
>  .../experimental/net/timer/waitable/ops.cc |1 +
>  5 files changed, 5 insertions(+)
>
> diff --git 
> a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc 
> b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
> index eb411dea8369c..7684c21012dfb 100644
> --- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
> +++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
> @@ -18,6 +18,7 @@
>  // { dg-do run { target c++14 } }
>  // { dg-require-effective-target net_ts_ip }
>  // { dg-add-options net_ts }
> +// { dg-xfail-if "io_context requires a working pipe" { *-*-rtems* } }
>
>  #include 
>  #include 
> diff --git 
> a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc 
> b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
> index 361df2676efc8..3ef51f9ebe848 100644
> --- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
> +++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
> @@ -18,6 +18,7 @@
>  // { dg-do run { target c++14 } }
>  // { dg-require-effective-target net_ts_ip }
>  // { dg-add-options net_ts }
> +// { dg-xfail-if "io_context requires a working pipe" { *-*-rtems* } }
>
>  #include 
>  #include 
> diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc 
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
> index 40ae5b965a2b0..4e055eadb20a0 100644
> --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
> +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
> @@ -17,6 +17,7 @@
>
>  // { dg-do run { target c++14 } }
>  // { dg-add-options libatomic }
> +// { dg-xfail-if "io_context requires a working pipe" { *-*-rtems* } }
>
>  #include 
>  #include 
> diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc 
> b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> index f571f4a8d861a..2f2e425fa0b33 100644
> --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> @@ -17,6 +17,7 @@
>
>  // { dg-do run { target c++14 } }
>  // { dg-add-options libatomic }
> +// { dg-xfail-if "io_context requires a working pipe" { *-*-rtems* } }
>
>  #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 97ab629b893a9..a52f3259193c4 100644
> --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> @@ -17,6 +17,7 @@
>
>  // { dg-do run { target c++14 } }
>  // { dg-add-options libatomic }
> +//

Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 11:53, Alexandre Oliva  wrote:
>
> On Jun 22, 2022, Jonathan Wakely  wrote:
>
> > Which tests are failing? I might be able to point you to the cause
> > much faster than you can debug it yourself.
>
> With commit 7e2db5d102dd05ffa9c46b89616f7a700a9889f8 (current
> refs/users/aoliva/heads/testme) I get:
[...]
> UNRESOLVED: 26_numerics/random/random_device/entropy.cc compilation failed to 
> produce executable
>  error: 'log2' is not a member of 'std'; did you mean 'log'?

That one should be fixed by r13-1214-g78fd15fd4a641c



Re: [PATCH] libstdc++: testsuite: avoid predictable mkstemp

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 22, 2022, Jonathan Wakely  wrote:

> On Wed, 22 Jun 2022 at 07:05, Alexandre Oliva via Libstdc++
>  wrote:

>> It was prompted by a target system with a non-random implementation of
>> mkstemp, that returns a predictable sequence of filenames and selects
>> the first one that isn't already taken.

> OK

And here's the patch that enabled me to stop worrying about the above.
Regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6.  Ok to install?


__gnu_test::nonexistent_path: Always include counter in filename returned

From: Joel Brobecker 

We have noticed that, on RTEMS, a small number of testscases are
failing because two calls to this method return the same filename.
This happens for instance in 27_io/filesystem/operations/copy_file.cc
where it does:

  auto from = __gnu_test::nonexistent_path();
  auto to = __gnu_test::nonexistent_path();

We tracked this issue down to the fact that the implementation of
mkstemp on that system appears to use a very predictable algorithm
for chosing the name of the temporary file, where the same filename
appears to be tried in the same order, regardless of past calls.
So, as long as the file gets deleted after a call to mkstemp (something
we do here in our nonexistent_path method), the next call to mkstemps
ends up returning the same filename, causing the collision we se above.

This commit enhances the __gnu_test::nonexistent_path method to
introduce in the filename being returned a counter which gets
incremented at every call of this method.

libstdc++-v3/ChangeLog:

* testsuite/util/testsuite_fs.h (__gnu_test::nonexistent_path):
Always include a counter in the filename returned.
---
 libstdc++-v3/testsuite/util/testsuite_fs.h |   31 
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
b/libstdc++-v3/testsuite/util/testsuite_fs.h
index 037d9ffc0f429..206ea67779003 100644
--- a/libstdc++-v3/testsuite/util/testsuite_fs.h
+++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
@@ -38,9 +38,9 @@ namespace test_fs = std::experimental::filesystem;
 
 #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200112L
 #include  // mkstemp
-#else
-#include// std::random_device
+#include  // strcpy
 #endif
+#include// std::random_device
 
 #if defined(__MINGW32__) || defined(__MINGW64__) \
   || !defined (_GLIBCXX_HAVE_SYMLINK)
@@ -125,8 +125,32 @@ namespace __gnu_test
   file.erase(0, pos+1);
 
 test_fs::path p;
+// A counter, starting from a random value, to be included as part
+// of the filename being returned, and incremented each time
+// this method is used.  It allows us to ensure that two calls
+// to this method can never return the same filename, something
+// testcases do when they need multiple non-existent filenames
+// for their purposes.
+static unsigned counter = std::random_device{}();
+
 #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200112L
-char tmp[] = "filesystem-test.XX";
+// Use mkstemp to determine the name of a file which does not exist yet.
+//
+// Note that we have seen on some systems (such as RTEMS, for instance)
+// that mkstemp behaves very predictably, causing it to always try
+// the same sequence of file names.  In other words, if we call mkstemp
+// with a pattern, delete the file it created (which is what we do, here),
+// and call mkstemp with the same pattern again, it returns the same
+// filename once more.  While most implementations introduce a degree
+// of randomness, it is not mandated by the standard, and this is why
+// we include a counter in the template passed to mkstemp.
+std::string mkstemp_template ("filesystem-test.");
+mkstemp_template.append(std::to_string (counter++));
+mkstemp_template.append(".XX");
+
+char tmp[mkstemp_template.length() + 1];
+std::strcpy (tmp, mkstemp_template.c_str());
+
 int fd = ::mkstemp(tmp);
 if (fd == -1)
   throw test_fs::filesystem_error("mkstemp failed",
@@ -141,7 +165,6 @@ namespace __gnu_test
 if (file.length() > 64)
   file.resize(64);
 char buf[128];
-static unsigned counter = std::random_device{}();
 #if _GLIBCXX_USE_C99_STDIO
 std::snprintf(buf, 128,
 #else


-- 
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.  Ask me about 


Re: [PATCH] libstdc++: testsuite: fs rename to self may fail

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 12:21, Alexandre Oliva  wrote:
>
> On Jun 23, 2022, Jonathan Wakely  wrote:
>
> > On Thu, 23 Jun 2022 at 07:26, Alexandre Oliva wrote:
> >> Would a patch to add:
> >>
> >> // { dg-xfail-if "::rename is not POSIX-compliant" { target *-*-rtems* } }
> >>
> >> to rename.cc tests be acceptable?
>
> > Yes, I think that's definitely the way to go.
>
> The "target" above shouldn't have been there, and the :: appears to get
> tcl/expect/dejagnu confused.  Here's the patch.
>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?

OK, thanks.


>
>
> libstdc++: xfail rename tests on rtems
>
> ::rename on RTEMS does not meet several POSIX requirements, despite
> compliance with C and C++ standards.  ::std::filesystem::rename, in
> turn, has requirements borrowed from POSIX, so it would have to be a
> lot more than a simple wrapper around ::rename on RTEMS, and even then
> fall short.
>
> Until RTEMS reimplements ::rename for POSIX compliance, expect
> filesystem rename tests to fail on it.
>
>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/27_io/filesystem/operations/rename.cc: xfail on
> rtems.
> * testsuite/experimental/filesystem/operations/rename.cc:
> Likewise.
> ---
>  .../27_io/filesystem/operations/rename.cc  |1 +
>  .../experimental/filesystem/operations/rename.cc   |1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc 
> b/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
> index b74e1133a7618..62543158e5241 100644
> --- a/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
> +++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
> @@ -17,6 +17,7 @@
>
>  // { dg-do run { target c++17 } }
>  // { dg-require-filesystem-ts "" }
> +// { dg-xfail-if "rename is not POSIX-compliant" { *-*-rtems* } }
>
>  #include 
>  #include 
> diff --git 
> a/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc 
> b/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
> index 37e743b770fdf..3c501757bff17 100644
> --- a/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
> +++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
> @@ -18,6 +18,7 @@
>  // { dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" }
>  // { dg-do run { target c++11 } }
>  // { dg-require-filesystem-ts "" }
> +// { dg-xfail-if "rename is not POSIX-compliant" { *-*-rtems* } }
>
>  #include 
>  #include 
>
>
> --
> 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.  Ask me about 
>



Re: [PATCH] libstdc++-v3: check for openat

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva  wrote:
>
> On Jun 22, 2022, Jonathan Wakely  wrote:
>
> > There are other interactions between AT_CDCWD and ::openat not covered
> > by this patch. I this this also needs to check HAVE_OPENAT:
>
> Here's an updated version, tested with this additional change.

Did this improve your test results for directory iterators?

In the unlikely even that the target has ::unlinkat but not ::openat
this will cause a behaviour regression, because now _Dir::do_unlink
will use {AT_FDCWD, "full/path/to/file"} instead of
{dirfd(dirp),"file"} but I doubt there are targets that have unlinkat
without openat. I'll try to improve this code later as discussed
anyway, so this is fine for now.

OK for trunk, thanks.



>
>
> libstdc++: check for openat
>
> From: Alexandre Oliva 
>
> rtems6.0 has fdopendir, and fcntl.h defines AT_FDCWD and declares
> openat, but there's no openat in libc.  Adjust dir-common.h to not
> assume ::openat just because of AT_FDCWD.
>
>
> for  libstdc++-v3/ChangeLog
>
> * acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for
> openat.
> * aclocal.m4, configure, config.h.in: Rebuilt.
> * src/filesystem/dir-common.h (openat): Use ::openat if
> _GLIBCXX_HAVE_OPENAT.
> * src/filesystem/dir.cc (dir_and_pathname): Use dirfd if
> _GLIBCXX_HAVE_OPENAT.
> ---
>  libstdc++-v3/acinclude.m4|   12 +++
>  libstdc++-v3/config.h.in |3 ++
>  libstdc++-v3/configure   |   55 
> ++
>  libstdc++-v3/src/filesystem/dir-common.h |2 +
>  libstdc++-v3/src/filesystem/dir.cc   |2 +
>  5 files changed, 72 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> index 138bd58d86cb9..e3cc3a8e867d3 100644
> --- a/libstdc++-v3/acinclude.m4
> +++ b/libstdc++-v3/acinclude.m4
> @@ -4772,6 +4772,18 @@ dnl
>if test $glibcxx_cv_dirfd = yes; then
>  AC_DEFINE(HAVE_DIRFD, 1, [Define if dirfd is available in .])
>fi
> +dnl
> +  AC_CACHE_CHECK([for openat],
> +glibcxx_cv_openat, [dnl
> +GCC_TRY_COMPILE_OR_LINK(
> +  [#include ],
> +  [int fd = ::openat(AT_FDCWD, "", 0);],
> +  [glibcxx_cv_openat=yes],
> +  [glibcxx_cv_openat=no])
> +  ])
> +  if test $glibcxx_cv_openat = yes; then
> +AC_DEFINE(HAVE_OPENAT, 1, [Define if openat is available in .])
> +  fi
>  dnl
>AC_CACHE_CHECK([for unlinkat],
>  glibcxx_cv_unlinkat, [dnl
> diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
> index f30a8c51c458c..2a3972eef5412 100644
> --- a/libstdc++-v3/config.h.in
> +++ b/libstdc++-v3/config.h.in
> @@ -292,6 +292,9 @@
>  /* Define if  defines obsolete isnan function. */
>  #undef HAVE_OBSOLETE_ISNAN
>
> +/* Define if openat is available in . */
> +#undef HAVE_OPENAT
> +
>  /* Define if poll is available in . */
>  #undef HAVE_POLL
>
> diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
> index 9b94fd71e4248..eac6039212168 100755
> --- a/libstdc++-v3/configure
> +++ b/libstdc++-v3/configure
> @@ -77177,6 +77177,61 @@ $as_echo "$glibcxx_cv_dirfd" >&6; }
>
>  $as_echo "#define HAVE_DIRFD 1" >>confdefs.h
>
> +  fi
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openat" >&5
> +$as_echo_n "checking for openat... " >&6; }
> +if ${glibcxx_cv_openat+:} false; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +  if test x$gcc_no_link = xyes; then
> +  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +#include 
> +int
> +main ()
> +{
> +int fd = ::openat(AT_FDCWD, "", 0);
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_cxx_try_compile "$LINENO"; then :
> +  glibcxx_cv_openat=yes
> +else
> +  glibcxx_cv_openat=no
> +fi
> +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +else
> +  if test x$gcc_no_link = xyes; then
> +  as_fn_error $? "Link tests are not allowed after GCC_NO_EXECUTABLES." 
> "$LINENO" 5
> +fi
> +cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +#include 
> +int
> +main ()
> +{
> +int fd = ::openat(AT_FDCWD, "", 0);
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_cxx_try_link "$LINENO"; then :
> +  glibcxx_cv_openat=yes
> +else
> +  glibcxx_cv_openat=no
> +fi
> +rm -f core conftest.err conftest.$ac_objext \
> +conftest$ac_exeext conftest.$ac_ext
> +fi
> +
> +fi
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $glibcxx_cv_openat" >&5
> +$as_echo "$glibcxx_cv_openat" >&6; }
> +  if test $glibcxx_cv_openat = yes; then
> +
> +$as_echo "#define HAVE_OPENAT 1" >>confdefs.h
> +
>fi
>{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for unlinkat" >&5
>  $as_echo_n "checking for unlinkat... " >&6; }
> diff --git a/libstdc++-v3/src/filesystem/dir-common.h 
> b/libstdc++-v3/src/filesystem/dir-common.h
> index 365fd527f4d68..669780ea23fe5 100644
> --- a/libstdc++-v3/src/filesystem/dir-common.h
> +++ b/libstdc++-v3/src/filesystem/dir-common.h
> @@ -199,7 +199,7 @@ struc

Re: [PATCH] libstdc++: 60241.cc: tolerate slightly shorter aggregate sleep

2022-06-23 Thread Sebastian Huber

On 23/06/2022 13:33, Alexandre Oliva wrote:

Anyway...  I was considering this xfail patch before, and I wonder if it
would still be appropriate to install something like it, narrowed down
to rtems < 6.1, or if it would be better to let it fail noisily so that
people look it up, find the fix proper and merge it.


I would not make it an xfail. It is now likely fixed and if someone uses 
a broken RTEMS version getting an error message would be nice.


--
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: [PATCH] libstdc++: async: tolerate slightly shorter sleep

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 22, 2022, Alexandre Oliva  wrote:

> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?

The early wakeups are fixed for rtems6.1, so the same question raised at
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597102.html apply to
this one:

libstdc++: xfail nanosleep tests on rtems

From: Alexandre Oliva 

Since it has been determined that nanosleep may return slightly too
early on RTEMS, due to clock resolution differences, expect
30_thread/async tests that have detected too-early wakeups to fail on
RTEMS targets.


for  libstdc++-v3/ChangeLog

* testsuite/30_threads/async/async.cc: xfail on RTEMS.

TN: V608-048
---
 libstdc++-v3/testsuite/30_threads/async/async.cc |1 +
 1 file changed, 1 insertion(+)

diff --git a/libstdc++-v3/testsuite/30_threads/async/async.cc 
b/libstdc++-v3/testsuite/30_threads/async/async.cc
index 38943ff1a9a5e..e0b731186c459 100644
--- a/libstdc++-v3/testsuite/30_threads/async/async.cc
+++ b/libstdc++-v3/testsuite/30_threads/async/async.cc
@@ -2,6 +2,7 @@
 // { dg-additional-options "-pthread" { target pthread } }
 // { dg-require-effective-target c++11 }
 // { dg-require-gthreads "" }
+// { dg-xfail-if "nanosleep may wake up too early" { *-*-rtems* } }
 
 // Copyright (C) 2010-2022 Free Software Foundation, Inc.
 //


-- 
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.  Ask me about 


[committed] libstdc++: Simplify test by not using std::log2

2022-06-23 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux, pushed to trunk.

-- >8 --

This test uses std::log2 without including , but it doesn't need
to use it at all. Just get the number of digits from numeric_limits
instead.

libstdc++-v3/ChangeLog:

* testsuite/26_numerics/random/random_device/entropy.cc: Use
numeric_limits::digits.
---
 .../testsuite/26_numerics/random/random_device/entropy.cc  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/26_numerics/random/random_device/entropy.cc 
b/libstdc++-v3/testsuite/26_numerics/random/random_device/entropy.cc
index 63b7043bf9b..9f529f5d814 100644
--- a/libstdc++-v3/testsuite/26_numerics/random/random_device/entropy.cc
+++ b/libstdc++-v3/testsuite/26_numerics/random/random_device/entropy.cc
@@ -1,6 +1,7 @@
 // { dg-do run { target c++11 } }
 
 #include 
+#include 
 #include 
 #include 
 
@@ -12,7 +13,7 @@ test01()
   VERIFY( std::random_device(token).entropy() == 0.0 );
 
   using result_type = std::random_device::result_type;
-  const double max = std::log2(std::numeric_limits::max() + 1.0);
+  const double max = std::numeric_limits::digits;
 
   for (auto token : { "/dev/random", "/dev/urandom" })
 if (__gnu_test::random_device_available(token))
-- 
2.34.3



Re: [PATCH] libstdc++: 60241.cc: tolerate slightly shorter aggregate sleep

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Sebastian Huber  wrote:

> On 23/06/2022 08:44, Sebastian Huber wrote:
>> http://devel.rtems.org/ticket/4669

Thanks!

> This problem should be fixed now in the RTEMS master branch.

Double thanks!  I've applied the patch, and I haven't seen the fails any
more.  It's a little too soon to confirm it fixed, but the patch makes
plenty of sense.

> I had to adjust the test case so that it works in a system with only
> one processor:

*nod*, I ran into that myself, and IIRC I've pushed an equivalent fix
earlier this week.


Anyway...  I was considering this xfail patch before, and I wonder if it
would still be appropriate to install something like it, narrowed down
to rtems < 6.1, or if it would be better to let it fail noisily so that
people look it up, find the fix proper and merge it.


libstdc++: xfail nanosleep tests on rtems

Since it has been determined that nanosleep may return slightly too
early on RTEMS, due to clock resolution differences, expect
30_thread/this_thread tests that have detected too-early wakeups to
fail on RTEMS targets.


for  libstdc++-v3/ChangeLog

* testsuite/30_threads/this_thread/60421.cc: xfail on RTEMS.
---
 .../testsuite/30_threads/this_thread/60421.cc  |1 +
 1 file changed, 1 insertion(+)

diff --git a/libstdc++-v3/testsuite/30_threads/this_thread/60421.cc 
b/libstdc++-v3/testsuite/30_threads/this_thread/60421.cc
index 12dbeba1cc492..4d86e0df20de4 100644
--- a/libstdc++-v3/testsuite/30_threads/this_thread/60421.cc
+++ b/libstdc++-v3/testsuite/30_threads/this_thread/60421.cc
@@ -23,6 +23,7 @@
 // { dg-require-gthreads "" }
 // { dg-require-time "" }
 // { dg-require-sleep "" }
+// { dg-xfail-if "nanosleep may wake up too early" { *-*-rtems* } }
 
 #include 
 #include 


-- 
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.  Ask me about 


Re: [PATCH] libstdc++: testsuite: skip fs space tests if not available

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 12:06, Alexandre Oliva  wrote:
>
> On Jun 22, 2022, Jonathan Wakely  wrote:
>
> > This could be done once in testsuite_fs.h as well.
>
> Done.  Erhm, I posted the new revision of the patch for this thread in
> the last_write_time thread, so I'm posting the last_write_time one here.

Heh, yeah, I just noticed that.


> This one also depends on dg infrastructure added in the NO_SYMLINKS patch.
>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?

OK, thanks.

>
> libstdc++: testsuite: skip fs last_write_time tests if dummy
>
> The last_write_time functions are defined in ways that are useful, or
> that fail immediately, depending on various macros.  When they fail
> immediately, the filesystem last_write_time.cc tests fail noisily, but
> the fail is entirely expected.
>
> Define NO_LAST_WRITE_TIME in the last_write_time.cc tests, according
> to the macros that select implementations of last_write_time, and use
> it through the new dg-require-target-fs-lwt to skip tests that are
> expected to fail.
>
>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/util/testsuite_fs.h (NO_LAST_WRITE_TIME): Define
> when appropriate.
> * testsuite/lib/libstdc++.exp
> (check_v3_target_fs_last_write_time): New.
> * testsuite/lib/dg-options.exp (dg-require-target-fs-lwt):
> New.
> * testsuite/27_io/filesystem/operations/last_write_time.cc:
> Skip the test if the features are unavailable.
> * testsuite/experimental/filesystem/operations/last_write_time.cc:
> Likewise.
> ---
>  .../27_io/filesystem/operations/last_write_time.cc |1 +
>  .../filesystem/operations/last_write_time.cc   |1 +
>  libstdc++-v3/testsuite/lib/dg-options.exp  |9 +
>  libstdc++-v3/testsuite/lib/libstdc++.exp   |8 
>  libstdc++-v3/testsuite/util/testsuite_fs.h |5 +
>  5 files changed, 24 insertions(+)
>
> diff --git 
> a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc 
> b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
> index 7d6468a512424..f6460fb83d70d 100644
> --- a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
> +++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
> @@ -17,6 +17,7 @@
>
>  // { dg-do run { target c++17 } }
>  // { dg-require-filesystem-ts "" }
> +// { dg-require-target-fs-lwt "" }
>
>  // 15.25 Permissions [fs.op.last_write_time]
>
> diff --git 
> a/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
>  
> b/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
> index 38fafc392ca9e..a0bf01ea935c5 100644
> --- 
> a/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
> +++ 
> b/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
> @@ -18,6 +18,7 @@
>  // { dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" }
>  // { dg-do run { target c++11 } }
>  // { dg-require-filesystem-ts "" }
> +// { dg-require-target-fs-lwt "" }
>
>  // 15.25 Permissions [fs.op.last_write_time]
>
> diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
> b/libstdc++-v3/testsuite/lib/dg-options.exp
> index 81bb8f448bd44..b61c4c0cb8fcd 100644
> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
> +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
> @@ -259,6 +259,15 @@ proc dg-require-target-fs-space { args } {
>  return
>  }
>
> +proc dg-require-target-fs-lwt { args } {
> +if { ![ check_v3_target_fs_last_write_time ] } {
> +   upvar dg-do-what dg-do-what
> +   set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
> +   return
> +}
> +return
> +}
> +
>  proc add_options_for_no_pch { flags } {
>  # This forces any generated and possibly included PCH to be invalid.
>  return "-D__GLIBCXX__="
> diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
> b/libstdc++-v3/testsuite/lib/libstdc++.exp
> index 22fdde8d66374..ca515c6f3548b 100644
> --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> @@ -1286,6 +1286,14 @@ proc check_v3_target_fs_space { } {
>  return [v3_check_preprocessor_condition fs_space $cond $inc]
>  }
>
> +# Return 1 if the libstdc++ filesystem implementation of
> +# last_write_time is not an always-failing dummy.
> +proc check_v3_target_fs_last_write_time { } {
> +set inc "#include "
> +set cond "!defined NO_LAST_WRITE_TIME"
> +return [v3_check_preprocessor_condition fs_last_write_time $cond $inc]
> +}
> +
>  # Return 1 if the "cxx11" ABI is in use using the current flags, 0 otherwise.
>  # Any flags provided by RUNTESTFLAGS or a target board will be used here.
>  # Flags added in the test by dg-options or dg-add-options will not be used.
> diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
> b/libstdc++-v3/testsuite/util/testsuite_fs.h
> index 89042e5534139..03

Re: [PATCH] libstdc++: testsuite: skip fs last_write_time tests if not available

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 12:05, Alexandre Oliva  wrote:
>
> On Jun 22, 2022, Jonathan Wakely  wrote:
>
> > And again, this could be a macro defined in testsuite_fs.h
>
> Done.  (it depends on dg changes in the symlink patch)
>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?

OK (after the NO_SYMLINKS one gets finished and committed obviously).

>
>
> libstdc++: testsuite: skip fs space tests on dummy implementations
>
> The do_space function is defined in ways that are useful, or that fail
> immediately, depending on various macros.  When it fails immediately,
> the filesystem space.cc tests fail noisily, but the fail is entirely
> expected.
>
> Define NO_SPACE in testsuite_fs.h, according to the macros that select
> implementations of do_space, and use it to skip tests that are
> expected to fail, through a new dg-require.
>
>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/util/testsuite_fs.h (NO_SPACE): Define if
> appropriate.
> * testsuite/lib/libstdc++.exp (check_v3_target_fs_space): New.
> * testsuite/lib/dg-options.exp (dg-require-target-fs-space):
> New.
> * testsuite/27_io/filesystem/operations/space.cc: Require
> target-fs-space.
> * testsuite/experimental/filesystem/operations/space.cc:
> Likewise.
> ---
>  .../testsuite/27_io/filesystem/operations/space.cc |1 +
>  .../experimental/filesystem/operations/space.cc|1 +
>  libstdc++-v3/testsuite/lib/dg-options.exp  |9 +
>  libstdc++-v3/testsuite/lib/libstdc++.exp   |8 
>  libstdc++-v3/testsuite/util/testsuite_fs.h |5 +
>  5 files changed, 24 insertions(+)
>
> diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc 
> b/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
> index 05997cac1dfa4..daa1ce439f30d 100644
> --- a/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
> +++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
> @@ -17,6 +17,7 @@
>
>  // { dg-do run { target c++17 } }
>  // { dg-require-filesystem-ts "" }
> +// { dg-require-target-fs-space "" }
>
>  // 30.10.14.3 Permissions [fs.op.space]
>
> diff --git 
> a/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc 
> b/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
> index 10ee0f06871df..c3745a2686635 100644
> --- a/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
> +++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
> @@ -18,6 +18,7 @@
>  // { dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" }
>  // { dg-do run { target c++11 } }
>  // { dg-require-filesystem-ts "" }
> +// { dg-require-target-fs-space "" }
>
>  // 30.10.14.3 Permissions [fs.op.space]
>
> diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
> b/libstdc++-v3/testsuite/lib/dg-options.exp
> index e624a69460ed6..81bb8f448bd44 100644
> --- a/libstdc++-v3/testsuite/lib/dg-options.exp
> +++ b/libstdc++-v3/testsuite/lib/dg-options.exp
> @@ -250,6 +250,15 @@ proc dg-require-target-fs-symlinks { args } {
>  return
>  }
>
> +proc dg-require-target-fs-space { args } {
> +if { ![ check_v3_target_fs_space ] } {
> +   upvar dg-do-what dg-do-what
> +   set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
> +   return
> +}
> +return
> +}
> +
>  proc add_options_for_no_pch { flags } {
>  # This forces any generated and possibly included PCH to be invalid.
>  return "-D__GLIBCXX__="
> diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
> b/libstdc++-v3/testsuite/lib/libstdc++.exp
> index d71d88fb99837..22fdde8d66374 100644
> --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> @@ -1278,6 +1278,14 @@ proc check_v3_target_fs_symlinks { } {
>  return [v3_check_preprocessor_condition fs_symlinks $cond $inc]
>  }
>
> +# Return 1 if the libstdc++ filesystem implementation of space is not an
> +# always-failing dummy.
> +proc check_v3_target_fs_space { } {
> +set inc "#include "
> +set cond "!defined NO_SPACE"
> +return [v3_check_preprocessor_condition fs_space $cond $inc]
> +}
> +
>  # Return 1 if the "cxx11" ABI is in use using the current flags, 0 otherwise.
>  # Any flags provided by RUNTESTFLAGS or a target board will be used here.
>  # Flags added in the test by dg-options or dg-add-options will not be used.
> diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
> b/libstdc++-v3/testsuite/util/testsuite_fs.h
> index 048f03103e436..89042e5534139 100644
> --- a/libstdc++-v3/testsuite/util/testsuite_fs.h
> +++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
> @@ -47,6 +47,11 @@ namespace test_fs = std::experimental::filesystem;
>  #define NO_SYMLINKS
>  #endif
>
> +#if !defined (_GLIBCXX_HAVE_SYS_STATVFS_H) \
> +  && !defined (_GLIBCXX_FILESYSTEM_IS_WINDOWS)
> +#define NO_SPACE
> +#endif
> +
>  namespace __gnu_test
>  {
>  #define PATH_C

Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 12:28, Jonathan Wakely  wrote:
>
> On Thu, 23 Jun 2022 at 12:02, Alexandre Oliva  wrote:
> >
> > On Jun 22, 2022, Jonathan Wakely  wrote:
> >
> > > OK.
> >
> > > I'd like to clean this up so the tests don't rely on the "internal"
> > > HAVE_SYMLINK macro. We could add something like this to
> > > testsuite/util/testsuite_fs.h
> >
> > > #if defined(__MINGW32__) || defined(__MINGW64__) \
> > >   || !defined (_GLIBCXX_HAVE_SYMLINK)
> > > # define NO_SYMLINKS
> > > #endif
> >
> > I took your suggestion, and took it a little further.  Here's the
> > result.
>
> Nice, thanks!
>
> >
> > Regstrapped on x86_64-linux-gnu, also tested with a cross to
> > aarch64-rtems6.  Ok to install?
>
> All the changes to the actual tests are fine.
>
> > diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
> > b/libstdc++-v3/testsuite/lib/libstdc++.exp
> > index 93fdfee687ddb..d71d88fb99837 100644
> > --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> > +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> > @@ -974,13 +974,16 @@ proc v3_try_preprocess { name code flags } {
> >  }
> >
> >  # Return 1 if COND evaluates to true in the preprocessor, 0 otherwise.
> > -# The  config header is included.
> > -proc v3_check_preprocessor_condition { name cond } {
> > +# The  config header is included, and INC, if given,
> > +# is pasted between it and the condition evaluation, so it can be used
> > +# for additional #include's.
> > +proc v3_check_preprocessor_condition { name cond inc } {
>
> Could this new arg be given a default value, so every caller doesn't
> have to pass "" to it?
>
> proc v3_check_preprocessor_condition { name cond {inc ""} } {
>
> > diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
> > b/libstdc++-v3/testsuite/util/testsuite_fs.h
> > index 9358a04e56c1f..048f03103e436 100644
> > --- a/libstdc++-v3/testsuite/util/testsuite_fs.h
> > +++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
> > @@ -42,6 +42,11 @@ namespace test_fs = std::experimental::filesystem;
> >  #include// std::random_device
> >  #endif
> >
> > +#if defined(__MINGW32__) || defined(__MINGW64__) \
> > +  || !defined (_GLIBCXX_HAVE_SYMLINK)
> > +#define NO_SYMLINKS
> > +#endif
>
> I think this could be simplified to just
> #ifndef _GLIBCXX_HAVE_SYMLINK
> because that is false on mingw:
> $ grep HAVE_SYMLINK include/x86_64-w64-mingw32/bits/c++config.h
> /* #undef _GLIBCXX_HAVE_SYMLINK */
>
> Windows uses CreateSymbolicLinkA to create its symlinks.
>
> And if NO_SYMLINKS just becomes a "public" name for
> _GLIBCXX_HAVE_SYMLINK that we can use in tests, then the dg
> check_v3_target_fs_symlinks proc could just test that macro too,
> without needing to include  to test NO_SYMLINKS. I
> don't feel strongly about that though. The $inc addition to
> v3_check_preprocessor_condition seems useful (although it will slow
> down evaluation of that condition, because  includes a
> lot of other headers).
> And if the definition of NO_SYMLINKS gets more complicated in future
> (e.g. we add something like && !defined __foo__) then using
> NO_SYMLINKS in the dg proc will keep them in sync.

Oh, and we need to be able to include  for the similar
NO_SPACE macro in your next patch, so we might as well check
NO_SYMLINKS the same way.

> I'd like the default argument for v3_check_preprocessor_condition so
> we don't need to add "" everywhere in that file, but the rest of the
> patch is OK as-is or simplified as above, I don't mind. Even keeping
> the MINGW tests in the NO_SYMLINKS definition is OK (it certainly
> doesn't hurt, it's just a bit redundant).



Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 12:02, Alexandre Oliva  wrote:
>
> On Jun 22, 2022, Jonathan Wakely  wrote:
>
> > OK.
>
> > I'd like to clean this up so the tests don't rely on the "internal"
> > HAVE_SYMLINK macro. We could add something like this to
> > testsuite/util/testsuite_fs.h
>
> > #if defined(__MINGW32__) || defined(__MINGW64__) \
> >   || !defined (_GLIBCXX_HAVE_SYMLINK)
> > # define NO_SYMLINKS
> > #endif
>
> I took your suggestion, and took it a little further.  Here's the
> result.

Nice, thanks!

>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?

All the changes to the actual tests are fine.

> diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
> b/libstdc++-v3/testsuite/lib/libstdc++.exp
> index 93fdfee687ddb..d71d88fb99837 100644
> --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> @@ -974,13 +974,16 @@ proc v3_try_preprocess { name code flags } {
>  }
>
>  # Return 1 if COND evaluates to true in the preprocessor, 0 otherwise.
> -# The  config header is included.
> -proc v3_check_preprocessor_condition { name cond } {
> +# The  config header is included, and INC, if given,
> +# is pasted between it and the condition evaluation, so it can be used
> +# for additional #include's.
> +proc v3_check_preprocessor_condition { name cond inc } {

Could this new arg be given a default value, so every caller doesn't
have to pass "" to it?

proc v3_check_preprocessor_condition { name cond {inc ""} } {

> diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
> b/libstdc++-v3/testsuite/util/testsuite_fs.h
> index 9358a04e56c1f..048f03103e436 100644
> --- a/libstdc++-v3/testsuite/util/testsuite_fs.h
> +++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
> @@ -42,6 +42,11 @@ namespace test_fs = std::experimental::filesystem;
>  #include// std::random_device
>  #endif
>
> +#if defined(__MINGW32__) || defined(__MINGW64__) \
> +  || !defined (_GLIBCXX_HAVE_SYMLINK)
> +#define NO_SYMLINKS
> +#endif

I think this could be simplified to just
#ifndef _GLIBCXX_HAVE_SYMLINK
because that is false on mingw:
$ grep HAVE_SYMLINK include/x86_64-w64-mingw32/bits/c++config.h
/* #undef _GLIBCXX_HAVE_SYMLINK */

Windows uses CreateSymbolicLinkA to create its symlinks.

And if NO_SYMLINKS just becomes a "public" name for
_GLIBCXX_HAVE_SYMLINK that we can use in tests, then the dg
check_v3_target_fs_symlinks proc could just test that macro too,
without needing to include  to test NO_SYMLINKS. I
don't feel strongly about that though. The $inc addition to
v3_check_preprocessor_condition seems useful (although it will slow
down evaluation of that condition, because  includes a
lot of other headers).
And if the definition of NO_SYMLINKS gets more complicated in future
(e.g. we add something like && !defined __foo__) then using
NO_SYMLINKS in the dg proc will keep them in sync.

I'd like the default argument for v3_check_preprocessor_condition so
we don't need to add "" everywhere in that file, but the rest of the
patch is OK as-is or simplified as above, I don't mind. Even keeping
the MINGW tests in the NO_SYMLINKS definition is OK (it certainly
doesn't hurt, it's just a bit redundant).



Re: [PATCH] Introduce -nolibstdc++ option

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 22, 2022, Alexandre Oliva  wrote:

> Yeah, I suppose that makes sense, it's beneficial for users to avoid the
> cognitive overload of dealing with equivalent options with different
> spellings.  I'll swallow my dislike for the spelling and change the
> patch to use -nostdlib++.

Here's the patch.  Regstrapped on x86_64-linux-gnu, also tested with a
cross to aarch64-rtems6.  Ok to install?


Introduce -nostdlib++ option

Using g++ to link without libstdc++, as in g++.dg/abi/pure-virtual1.C,
is error prone, because there's no way to tell g++ to drop libstdc++
without also dropping libc and any other libraries that the target
implicitly links in.

This has often led to the need for manual adjustments to this
testcase.

I figured adding support for -nostdlib++, even though redundant, makes
some sense.  One could presumably use gcc rather than g++ for linking,
for the same effect, but sometimes changing the link command is harder
than adding an option, as in our testsuite.

Since clang already had an option with this effect, we've adopted the
same spelling.


for  gcc/ChangeLog

* common.opt (nostdlib++): New.
* doc/invoke.texi (-nostdlib++): Document it.

for  gcc/cp/ChangeLog

* g++spec.cc (lang_specific_driver): Implement -nostdlib++.

for  gcc/testsuite/ChangeLog

* g++.dg/abi/pure-virtual1.C: Use -nostdlib++.
---
 gcc/common.opt   |3 +++
 gcc/cp/g++spec.cc|1 +
 gcc/doc/invoke.texi  |6 +-
 gcc/testsuite/g++.dg/abi/pure-virtual1.C |2 +-
 4 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 32917aafcaec1..0845e083247af 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3459,6 +3459,9 @@ Driver
 nostdlib
 Driver
 
+nostdlib++
+Driver
+
 o
 Common Driver Joined Separate Var(asm_file_name) MissingArgError(missing 
filename after %qs)
 -o   Place output into .
diff --git a/gcc/cp/g++spec.cc b/gcc/cp/g++spec.cc
index 8174d652776b1..b63d8350ba113 100644
--- a/gcc/cp/g++spec.cc
+++ b/gcc/cp/g++spec.cc
@@ -159,6 +159,7 @@ lang_specific_driver (struct cl_decoded_option 
**in_decoded_options,
   switch (decoded_options[i].opt_index)
{
case OPT_nostdlib:
+   case OPT_nostdlib__:
case OPT_nodefaultlibs:
  library = -1;
  break;
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index fb506364702b7..a7ab29335c84a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -652,7 +652,7 @@ Objective-C and Objective-C++ Dialects}.
 @item Linker Options
 @xref{Link Options,,Options for Linking}.
 @gccoptlist{@var{object-file-name}  -fuse-ld=@var{linker}  -l@var{library} @gol
--nostartfiles  -nodefaultlibs  -nolibc  -nostdlib @gol
+-nostartfiles  -nodefaultlibs  -nolibc  -nostdlib  -nostdlib++ @gol
 -e @var{entry}  --entry=@var{entry} @gol
 -pie  -pthread  -r  -rdynamic @gol
 -s  -static  -static-pie  -static-libgcc  -static-libstdc++ @gol
@@ -16822,6 +16822,10 @@ library subroutines.
 constructors are called; @pxref{Collect2,,@code{collect2}, gccint,
 GNU Compiler Collection (GCC) Internals}.)
 
+@item -nostdlib++
+@opindex nostdlib++
+Do not implicitly link with standard C++ libraries.
+
 @item -e @var{entry}
 @itemx --entry=@var{entry}
 @opindex e
diff --git a/gcc/testsuite/g++.dg/abi/pure-virtual1.C 
b/gcc/testsuite/g++.dg/abi/pure-virtual1.C
index 538e2cb097a0d..59eaf22562049 100644
--- a/gcc/testsuite/g++.dg/abi/pure-virtual1.C
+++ b/gcc/testsuite/g++.dg/abi/pure-virtual1.C
@@ -1,7 +1,7 @@
 // Test that we don't need libsupc++ just for __cxa_pure_virtual.
 // { dg-do link }
 // { dg-require-weak }
-// { dg-additional-options "-fno-rtti -nodefaultlibs -lc" }
+// { dg-additional-options "-fno-rtti -nostdlib++" }
 // { dg-additional-options "-Wl,-undefined,dynamic_lookup" { target 
*-*-darwin* } }
 // { dg-xfail-if "AIX weak" { powerpc-ibm-aix* } }
 


-- 
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.  Ask me about 


Re: [PATCH] libstdc++: testsuite: use -lbsd for net_ts on RTEMS

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Jonathan Wakely  wrote:

> On Thu, 23 Jun 2022, 10:02 Sebastian Huber, <
> sebastian.hu...@embedded-brains.de> wrote:

>> On 22/06/2022 07:24, Alexandre Oliva via Gcc-patches wrote:
>> > +} elseif { [istarget *-*-rtems*] } {
>> > + # Adding -Wl,--gc-sections would enable a few more tests to
>> > + # link, but all of them fail at runtime anyway, because the
>> > + # io_context ctor calls pipe(), which always fails, and thus
>> > + # the ctor throws a system error.
>> > + return "$flags -lbsd"
>> 
>> Using -Wl,--gc-sections is mandatory if you want to link against
>> libbsd.a.

Weirdly, it worked for all other testcases.

>> For pipe() support in RTEMS, you currently need the

>> #define CONFIGURE_IMFS_ENABLE_MKFIFO

Thanks, I'll reach out to the person in charge of our rtems
configuration for this project, and suggest enabling it on our end.


> It would also be fine to just xfail the networking tests for rtems.

I was using something like this internally.  Regstrapped on
x86_64-linux-gnu, also tested with a cross to aarch64-rtems6.  Ok to
install?


libstdc++: xfail io_context/pipe users on rtems

From: Alexandre Oliva 

A handful of tests fail on rtems because pipe() always returns -1, and
the io_context ctor throws a system error when pipe() fails.


for  libstdc++-v3/ChangeLog

* testsuite/experimental/net/timer/waitable/cons.cc: xfail on
RTEMS.
* testsuite/experimental/net/timer/waitable/dest.cc: Likewise.
* testsuite/experimental/net/timer/waitable/ops.cc: Likewise.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc:
Likewise.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc:
Likewise.

TN: V617-003
---
 .../net/internet/resolver/ops/lookup.cc|1 +
 .../net/internet/resolver/ops/reverse.cc   |1 +
 .../experimental/net/timer/waitable/cons.cc|1 +
 .../experimental/net/timer/waitable/dest.cc|1 +
 .../experimental/net/timer/waitable/ops.cc |1 +
 5 files changed, 5 insertions(+)

diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
index eb411dea8369c..7684c21012dfb 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
@@ -18,6 +18,7 @@
 // { dg-do run { target c++14 } }
 // { dg-require-effective-target net_ts_ip }
 // { dg-add-options net_ts }
+// { dg-xfail-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
index 361df2676efc8..3ef51f9ebe848 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
@@ -18,6 +18,7 @@
 // { dg-do run { target c++14 } }
 // { dg-require-effective-target net_ts_ip }
 // { dg-add-options net_ts }
+// { dg-xfail-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc 
b/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
index 40ae5b965a2b0..4e055eadb20a0 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/cons.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc 
b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
index f571f4a8d861a..2f2e425fa0b33 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #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 97ab629b893a9..a52f3259193c4 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply 

Re: [PATCH] libstdc++: testsuite: fs rename to self may fail

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 23, 2022, Jonathan Wakely  wrote:

> On Thu, 23 Jun 2022 at 07:26, Alexandre Oliva wrote:
>> Would a patch to add:
>> 
>> // { dg-xfail-if "::rename is not POSIX-compliant" { target *-*-rtems* } }
>> 
>> to rename.cc tests be acceptable?

> Yes, I think that's definitely the way to go.

The "target" above shouldn't have been there, and the :: appears to get
tcl/expect/dejagnu confused.  Here's the patch.

Regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6.  Ok to install?


libstdc++: xfail rename tests on rtems

::rename on RTEMS does not meet several POSIX requirements, despite
compliance with C and C++ standards.  ::std::filesystem::rename, in
turn, has requirements borrowed from POSIX, so it would have to be a
lot more than a simple wrapper around ::rename on RTEMS, and even then
fall short.

Until RTEMS reimplements ::rename for POSIX compliance, expect
filesystem rename tests to fail on it.


for  libstdc++-v3/ChangeLog

* testsuite/27_io/filesystem/operations/rename.cc: xfail on
rtems.
* testsuite/experimental/filesystem/operations/rename.cc:
Likewise.
---
 .../27_io/filesystem/operations/rename.cc  |1 +
 .../experimental/filesystem/operations/rename.cc   |1 +
 2 files changed, 2 insertions(+)

diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
index b74e1133a7618..62543158e5241 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++17 } }
 // { dg-require-filesystem-ts "" }
+// { dg-xfail-if "rename is not POSIX-compliant" { *-*-rtems* } }
 
 #include 
 #include 
diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
index 37e743b770fdf..3c501757bff17 100644
--- a/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
+++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/rename.cc
@@ -18,6 +18,7 @@
 // { dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" }
 // { dg-do run { target c++11 } }
 // { dg-require-filesystem-ts "" }
+// { dg-xfail-if "rename is not POSIX-compliant" { *-*-rtems* } }
 
 #include 
 #include 


-- 
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.  Ask me about 


Re: [PATCH] libstdc++-v3: check for openat

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 22, 2022, Jonathan Wakely  wrote:

> There are other interactions between AT_CDCWD and ::openat not covered
> by this patch. I this this also needs to check HAVE_OPENAT:

Here's an updated version, tested with this additional change.


libstdc++: check for openat

From: Alexandre Oliva 

rtems6.0 has fdopendir, and fcntl.h defines AT_FDCWD and declares
openat, but there's no openat in libc.  Adjust dir-common.h to not
assume ::openat just because of AT_FDCWD.


for  libstdc++-v3/ChangeLog

* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for
openat.
* aclocal.m4, configure, config.h.in: Rebuilt.
* src/filesystem/dir-common.h (openat): Use ::openat if
_GLIBCXX_HAVE_OPENAT.
* src/filesystem/dir.cc (dir_and_pathname): Use dirfd if
_GLIBCXX_HAVE_OPENAT.
---
 libstdc++-v3/acinclude.m4|   12 +++
 libstdc++-v3/config.h.in |3 ++
 libstdc++-v3/configure   |   55 ++
 libstdc++-v3/src/filesystem/dir-common.h |2 +
 libstdc++-v3/src/filesystem/dir.cc   |2 +
 5 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 138bd58d86cb9..e3cc3a8e867d3 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4772,6 +4772,18 @@ dnl
   if test $glibcxx_cv_dirfd = yes; then
 AC_DEFINE(HAVE_DIRFD, 1, [Define if dirfd is available in .])
   fi
+dnl
+  AC_CACHE_CHECK([for openat],
+glibcxx_cv_openat, [dnl
+GCC_TRY_COMPILE_OR_LINK(
+  [#include ],
+  [int fd = ::openat(AT_FDCWD, "", 0);],
+  [glibcxx_cv_openat=yes],
+  [glibcxx_cv_openat=no])
+  ])
+  if test $glibcxx_cv_openat = yes; then
+AC_DEFINE(HAVE_OPENAT, 1, [Define if openat is available in .])
+  fi
 dnl
   AC_CACHE_CHECK([for unlinkat],
 glibcxx_cv_unlinkat, [dnl
diff --git a/libstdc++-v3/config.h.in b/libstdc++-v3/config.h.in
index f30a8c51c458c..2a3972eef5412 100644
--- a/libstdc++-v3/config.h.in
+++ b/libstdc++-v3/config.h.in
@@ -292,6 +292,9 @@
 /* Define if  defines obsolete isnan function. */
 #undef HAVE_OBSOLETE_ISNAN
 
+/* Define if openat is available in . */
+#undef HAVE_OPENAT
+
 /* Define if poll is available in . */
 #undef HAVE_POLL
 
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 9b94fd71e4248..eac6039212168 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -77177,6 +77177,61 @@ $as_echo "$glibcxx_cv_dirfd" >&6; }
 
 $as_echo "#define HAVE_DIRFD 1" >>confdefs.h
 
+  fi
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for openat" >&5
+$as_echo_n "checking for openat... " >&6; }
+if ${glibcxx_cv_openat+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if test x$gcc_no_link = xyes; then
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include 
+int
+main ()
+{
+int fd = ::openat(AT_FDCWD, "", 0);
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_compile "$LINENO"; then :
+  glibcxx_cv_openat=yes
+else
+  glibcxx_cv_openat=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+else
+  if test x$gcc_no_link = xyes; then
+  as_fn_error $? "Link tests are not allowed after GCC_NO_EXECUTABLES." 
"$LINENO" 5
+fi
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include 
+int
+main ()
+{
+int fd = ::openat(AT_FDCWD, "", 0);
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_link "$LINENO"; then :
+  glibcxx_cv_openat=yes
+else
+  glibcxx_cv_openat=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+conftest$ac_exeext conftest.$ac_ext
+fi
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $glibcxx_cv_openat" >&5
+$as_echo "$glibcxx_cv_openat" >&6; }
+  if test $glibcxx_cv_openat = yes; then
+
+$as_echo "#define HAVE_OPENAT 1" >>confdefs.h
+
   fi
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for unlinkat" >&5
 $as_echo_n "checking for unlinkat... " >&6; }
diff --git a/libstdc++-v3/src/filesystem/dir-common.h 
b/libstdc++-v3/src/filesystem/dir-common.h
index 365fd527f4d68..669780ea23fe5 100644
--- a/libstdc++-v3/src/filesystem/dir-common.h
+++ b/libstdc++-v3/src/filesystem/dir-common.h
@@ -199,7 +199,7 @@ struct _Dir_base
 #endif
 
 
-#ifdef AT_FDCWD
+#if _GLIBCXX_HAVE_OPENAT && defined AT_FDCWD
 fd = ::openat(fd, pathname, flags);
 #else
 // If we cannot use openat, there's no benefit to using posix::open unless
diff --git a/libstdc++-v3/src/filesystem/dir.cc 
b/libstdc++-v3/src/filesystem/dir.cc
index b451902c4a1b1..e64489162e5ff 100644
--- a/libstdc++-v3/src/filesystem/dir.cc
+++ b/libstdc++-v3/src/filesystem/dir.cc
@@ -120,7 +120,7 @@ struct fs::_Dir : std::filesystem::_Dir_base
   dir_and_pathname() const noexcept
   {
 const fs::path& p = entry.path();
-#if _GLIBCXX_HAVE_DIRFD
+#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT
 return {::dirfd(this->dirp), std::prev(p.end())->c_str()};
 #endif
 return {this->fdcwd(), p.c_str()};


-- 
Alexandre O

Re: [PATCH] libstdc++: testsuite: skip fs space tests if not available

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 22, 2022, Jonathan Wakely  wrote:

> This could be done once in testsuite_fs.h as well.

Done.  Erhm, I posted the new revision of the patch for this thread in
the last_write_time thread, so I'm posting the last_write_time one here.
This one also depends on dg infrastructure added in the NO_SYMLINKS patch.

Regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6.  Ok to install?


libstdc++: testsuite: skip fs last_write_time tests if dummy

The last_write_time functions are defined in ways that are useful, or
that fail immediately, depending on various macros.  When they fail
immediately, the filesystem last_write_time.cc tests fail noisily, but
the fail is entirely expected.

Define NO_LAST_WRITE_TIME in the last_write_time.cc tests, according
to the macros that select implementations of last_write_time, and use
it through the new dg-require-target-fs-lwt to skip tests that are
expected to fail.


for  libstdc++-v3/ChangeLog

* testsuite/util/testsuite_fs.h (NO_LAST_WRITE_TIME): Define
when appropriate.
* testsuite/lib/libstdc++.exp
(check_v3_target_fs_last_write_time): New.
* testsuite/lib/dg-options.exp (dg-require-target-fs-lwt):
New.
* testsuite/27_io/filesystem/operations/last_write_time.cc:
Skip the test if the features are unavailable.
* testsuite/experimental/filesystem/operations/last_write_time.cc:
Likewise.
---
 .../27_io/filesystem/operations/last_write_time.cc |1 +
 .../filesystem/operations/last_write_time.cc   |1 +
 libstdc++-v3/testsuite/lib/dg-options.exp  |9 +
 libstdc++-v3/testsuite/lib/libstdc++.exp   |8 
 libstdc++-v3/testsuite/util/testsuite_fs.h |5 +
 5 files changed, 24 insertions(+)

diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
index 7d6468a512424..f6460fb83d70d 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/last_write_time.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++17 } }
 // { dg-require-filesystem-ts "" }
+// { dg-require-target-fs-lwt "" }
 
 // 15.25 Permissions [fs.op.last_write_time]
 
diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
index 38fafc392ca9e..a0bf01ea935c5 100644
--- 
a/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
+++ 
b/libstdc++-v3/testsuite/experimental/filesystem/operations/last_write_time.cc
@@ -18,6 +18,7 @@
 // { dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" }
 // { dg-do run { target c++11 } }
 // { dg-require-filesystem-ts "" }
+// { dg-require-target-fs-lwt "" }
 
 // 15.25 Permissions [fs.op.last_write_time]
 
diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
b/libstdc++-v3/testsuite/lib/dg-options.exp
index 81bb8f448bd44..b61c4c0cb8fcd 100644
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -259,6 +259,15 @@ proc dg-require-target-fs-space { args } {
 return
 }
 
+proc dg-require-target-fs-lwt { args } {
+if { ![ check_v3_target_fs_last_write_time ] } {
+   upvar dg-do-what dg-do-what
+   set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
+   return
+}
+return
+}
+
 proc add_options_for_no_pch { flags } {
 # This forces any generated and possibly included PCH to be invalid.
 return "-D__GLIBCXX__="
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 22fdde8d66374..ca515c6f3548b 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1286,6 +1286,14 @@ proc check_v3_target_fs_space { } {
 return [v3_check_preprocessor_condition fs_space $cond $inc]
 }
 
+# Return 1 if the libstdc++ filesystem implementation of
+# last_write_time is not an always-failing dummy.
+proc check_v3_target_fs_last_write_time { } {
+set inc "#include "
+set cond "!defined NO_LAST_WRITE_TIME"
+return [v3_check_preprocessor_condition fs_last_write_time $cond $inc]
+}
+
 # Return 1 if the "cxx11" ABI is in use using the current flags, 0 otherwise.
 # Any flags provided by RUNTESTFLAGS or a target board will be used here.
 # Flags added in the test by dg-options or dg-add-options will not be used.
diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
b/libstdc++-v3/testsuite/util/testsuite_fs.h
index 89042e5534139..037d9ffc0f429 100644
--- a/libstdc++-v3/testsuite/util/testsuite_fs.h
+++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
@@ -52,6 +52,11 @@ namespace test_fs = std::experimental::filesystem;
 #define NO_SPACE
 #endif
 
+#if !(_GLIBCXX_HAVE_SYS_STAT_H \
+  && (_GLIBCXX_USE_UTIMENSAT || _GLIBCXX_USE_UTIME))
+#define NO_

Re: [PATCH] libstdc++: testsuite: skip fs last_write_time tests if not available

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 22, 2022, Jonathan Wakely  wrote:

> And again, this could be a macro defined in testsuite_fs.h

Done.  (it depends on dg changes in the symlink patch)

Regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6.  Ok to install?


libstdc++: testsuite: skip fs space tests on dummy implementations

The do_space function is defined in ways that are useful, or that fail
immediately, depending on various macros.  When it fails immediately,
the filesystem space.cc tests fail noisily, but the fail is entirely
expected.

Define NO_SPACE in testsuite_fs.h, according to the macros that select
implementations of do_space, and use it to skip tests that are
expected to fail, through a new dg-require.


for  libstdc++-v3/ChangeLog

* testsuite/util/testsuite_fs.h (NO_SPACE): Define if
appropriate.
* testsuite/lib/libstdc++.exp (check_v3_target_fs_space): New.
* testsuite/lib/dg-options.exp (dg-require-target-fs-space):
New.
* testsuite/27_io/filesystem/operations/space.cc: Require
target-fs-space.
* testsuite/experimental/filesystem/operations/space.cc:
Likewise.
---
 .../testsuite/27_io/filesystem/operations/space.cc |1 +
 .../experimental/filesystem/operations/space.cc|1 +
 libstdc++-v3/testsuite/lib/dg-options.exp  |9 +
 libstdc++-v3/testsuite/lib/libstdc++.exp   |8 
 libstdc++-v3/testsuite/util/testsuite_fs.h |5 +
 5 files changed, 24 insertions(+)

diff --git a/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
index 05997cac1dfa4..daa1ce439f30d 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++17 } }
 // { dg-require-filesystem-ts "" }
+// { dg-require-target-fs-space "" }
 
 // 30.10.14.3 Permissions [fs.op.space]
 
diff --git a/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
index 10ee0f06871df..c3745a2686635 100644
--- a/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
+++ b/libstdc++-v3/testsuite/experimental/filesystem/operations/space.cc
@@ -18,6 +18,7 @@
 // { dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" }
 // { dg-do run { target c++11 } }
 // { dg-require-filesystem-ts "" }
+// { dg-require-target-fs-space "" }
 
 // 30.10.14.3 Permissions [fs.op.space]
 
diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
b/libstdc++-v3/testsuite/lib/dg-options.exp
index e624a69460ed6..81bb8f448bd44 100644
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -250,6 +250,15 @@ proc dg-require-target-fs-symlinks { args } {
 return
 }
 
+proc dg-require-target-fs-space { args } {
+if { ![ check_v3_target_fs_space ] } {
+   upvar dg-do-what dg-do-what
+   set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
+   return
+}
+return
+}
+
 proc add_options_for_no_pch { flags } {
 # This forces any generated and possibly included PCH to be invalid.
 return "-D__GLIBCXX__="
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index d71d88fb99837..22fdde8d66374 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1278,6 +1278,14 @@ proc check_v3_target_fs_symlinks { } {
 return [v3_check_preprocessor_condition fs_symlinks $cond $inc]
 }
 
+# Return 1 if the libstdc++ filesystem implementation of space is not an
+# always-failing dummy.
+proc check_v3_target_fs_space { } {
+set inc "#include "
+set cond "!defined NO_SPACE"
+return [v3_check_preprocessor_condition fs_space $cond $inc]
+}
+
 # Return 1 if the "cxx11" ABI is in use using the current flags, 0 otherwise.
 # Any flags provided by RUNTESTFLAGS or a target board will be used here.
 # Flags added in the test by dg-options or dg-add-options will not be used.
diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
b/libstdc++-v3/testsuite/util/testsuite_fs.h
index 048f03103e436..89042e5534139 100644
--- a/libstdc++-v3/testsuite/util/testsuite_fs.h
+++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
@@ -47,6 +47,11 @@ namespace test_fs = std::experimental::filesystem;
 #define NO_SYMLINKS
 #endif
 
+#if !defined (_GLIBCXX_HAVE_SYS_STATVFS_H) \
+  && !defined (_GLIBCXX_FILESYSTEM_IS_WINDOWS)
+#define NO_SPACE
+#endif
+
 namespace __gnu_test
 {
 #define PATH_CHK(p1, p2, fn) \


-- 
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.  Ask me about 


Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 22, 2022, Jonathan Wakely  wrote:

> OK.

> I'd like to clean this up so the tests don't rely on the "internal"
> HAVE_SYMLINK macro. We could add something like this to
> testsuite/util/testsuite_fs.h

> #if defined(__MINGW32__) || defined(__MINGW64__) \
>   || !defined (_GLIBCXX_HAVE_SYMLINK)
> # define NO_SYMLINKS
> #endif

I took your suggestion, and took it a little further.  Here's the
result.

Regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6.  Ok to install?


libstdc++: testsuite: conditionalize symlink tests

Several filesystem tests expect to be able to create symlinks even
when !defined (_GLIBCXX_HAVE_SYMLINK), and fail predictably, reducing
the amount of testing of other filesystem features.

They are already skipped for mingw targets.  I've extended the
skipping to other targets in which _GLIBCXX_HAVE_SYMLINK is undefined,
through a new NO_SYMLINKS macro in testsuite_fs.h that guards
skippable portions of tests, and dg-require-target-fs-symlinks for
tests that would be reduced to nothing.


for  libstdc++-v3/ChangeLog

* testsuite/util/testsuite_fs.h (NO_SYMLINKS): Define on
mingw and when create_symlink is a dummy.
* testsuite/27_io/filesystem/operations/symlink_status.cc:
Drop mingw xfail.
(test01, test02): Don't create symlinks when NO_SYMLINKS is
defined.
* testsuite/27_io/filesystem/operations/canonical.cc (test03):
Likewise.
* testsuite/27_io/filesystem/operations/copy.cc (test02):
Likewise.
* testsuite/27_io/filesystem/operations/create_directories.cc
(test04): Likewise.
* testsuite/27_io/filesystem/operations/create_directory.cc
(test01): Likewise.
* testsuite/27_io/filesystem/operations/permissions.cc
(test03, test04): Likewise.
* testsuite/27_io/filesystem/operations/remove.cc (test01):
Likewise.
* testsuite/27_io/filesystem/operations/remove_all.cc (test01):
Likewise.
* testsuite/27_io/filesystem/operations/rename.cc
(test_symlinks): Likewise.
* testsuite/27_io/filesystem/operations/weakly_canonical.cc
(test01): Likewise.
* 
testsuite/experimental/filesystem/iterators/recursive_directory_itreator.cc
(test06): Likewise.
* testsuite/experimental/filesystem/operations/copy.cc
(test01): Likewise.
* testsuite/experimental/filesystem/operations/create_directories.cc
(test04): Likewise.
* testsuite/experimental/filesystem/operations/create_directory.cc
(test01): Likewise.
* testsuite/experimental/filesystem/operations/permissions.cc
(test03, test04): Likewise.
* testsuite/experimental/filesystem/operations/remove.cc
(test01): Likewise.
* testsuite/experimental/filesystem/operations/remove_all.cc
(test01): Likewise.
* testsuite/experimental/filesystem/operations/rename.cc
(test01): Likewise.
* testsuite/lib/libstdc++.exp
(v3_check_preprocessor_condition): Add inc parameter.  Include
it after bits/c++config.h.  Adjust all callers.
(check_v3_target_fs_symlinks): New.
* testsuite/lib/dg-options.exp
(dg-require-target-fs-symlinks): New.
* testsuite/27_io/filesystem/operations/read_symlink.cc:
Replace mingw xfail with require target-fs-symlinks.
* testsuite/experimental/filesystem/operations/read_symlink.cc:
Likewise.
---
 .../27_io/filesystem/operations/canonical.cc   |5 +-
 .../testsuite/27_io/filesystem/operations/copy.cc  |7 +--
 .../filesystem/operations/create_directories.cc|4 -
 .../filesystem/operations/create_directory.cc  |4 -
 .../27_io/filesystem/operations/permissions.cc |4 +
 .../27_io/filesystem/operations/read_symlink.cc|2 -
 .../27_io/filesystem/operations/remove.cc  |4 -
 .../27_io/filesystem/operations/remove_all.cc  |4 -
 .../27_io/filesystem/operations/rename.cc  |4 -
 .../27_io/filesystem/operations/symlink_status.cc  |5 +-
 .../filesystem/operations/weakly_canonical.cc  |4 -
 .../iterators/recursive_directory_iterator.cc  |2 -
 .../experimental/filesystem/operations/copy.cc |7 +--
 .../filesystem/operations/create_directories.cc|4 -
 .../filesystem/operations/create_directory.cc  |4 -
 .../filesystem/operations/permissions.cc   |4 +
 .../filesystem/operations/read_symlink.cc  |2 -
 .../experimental/filesystem/operations/remove.cc   |5 --
 .../filesystem/operations/remove_all.cc|4 -
 .../experimental/filesystem/operations/rename.cc   |4 -
 libstdc++-v3/testsuite/lib/dg-options.exp  |9 +++
 libstdc++-v3/testsuite/lib/libstdc++.exp   |   55 
 libstdc++-v3/testsuite/util/testsuite_fs.h |5 ++
 23 files changed, 81 insertions(+), 71 dele

Re: [PATCH] aarch64: testsuite: symbol-range compile only

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 22, 2022, Richard Sandiford  wrote:

> Other selectors don't use CamelCase, so I guess it should be
> two_plus_gigs instead.  There also needs to be an entry in
> sourcebuild.texi.

Thanks for the reminder, I keep forgetting about this.

> OK with those changes, thanks.

Here's what I'm going to install.


aarch64: testsuite: symbol-range fallback to compile

On some of our embedded aarch64 targets, RAM size is too small for
this test to fit.  It doesn't look like this test requires linking,
and if it does, the -tiny version may presumably get most of the
coverage without going overboard in target system requirements.

Still, linking may be useful, so introduce a two_plus_gigs effective
target, that checks for the ability to link a program with 2GiB of
sbss, and use that to select whether to link or just compile
symbol-range.c.


for  gcc/testsuite/ChangeLog

* lib/target-supports.exp
(check_effective_target_two_plus_gigs): New.
* doc/sourcebuild.exp (Environment attributes): Document it.
* gcc.target/aarch64/symbol-range.c: Link only on
two_plus_gigs targets, compile otherwise.
---
 gcc/doc/sourcebuild.texi|3 +++
 gcc/testsuite/gcc.target/aarch64/symbol-range.c |3 ++-
 gcc/testsuite/lib/target-supports.exp   |9 +
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 606ab85a11668..3696a58fbf2bc 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2681,6 +2681,9 @@ Target supports @code{sysconf}.
 @item trampolines
 Target supports trampolines.
 
+@item two_plus_gigs
+Target supports linking programs with 2+GiB of data.
+
 @item uclibc
 Target supports uClibc.
 
diff --git a/gcc/testsuite/gcc.target/aarch64/symbol-range.c 
b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
index d8e82fa1b2829..6b15f0872024c 100644
--- a/gcc/testsuite/gcc.target/aarch64/symbol-range.c
+++ b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
@@ -1,4 +1,5 @@
-/* { dg-do link } */
+/* { dg-do link { target two_plus_gigs } } */
+/* { dg-do compile { target { ! two_plus_gigs } } } */
 /* { dg-options "-O3 -save-temps -mcmodel=small" } */
 
 char fixed_regs[0x8000];
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index d1f4eb7641fa7..20171f9d98584 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2906,6 +2906,15 @@ proc check_effective_target_le { } {
 }]
 }
 
+# Return 1 if we can link a program with 2+GB of data.
+
+proc check_effective_target_two_plus_gigs { } {
+return [check_no_compiler_messages two_plus_gigs executable {
+   int dummy[0x8000];
+   int main () { return 0; }
+}]
+}
+
 # Return 1 if we're generating 32-bit code using default options, 0
 # otherwise.
 


-- 
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.  Ask me about 


Re: [PATCH] libstdc++: testsuite: test symlnks ifdef _GLIBCXX_HAVE_SYMLINK

2022-06-23 Thread Alexandre Oliva via Gcc-patches
On Jun 22, 2022, Jonathan Wakely  wrote:

> Which tests are failing? I might be able to point you to the cause
> much faster than you can debug it yourself.

With commit 7e2db5d102dd05ffa9c46b89616f7a700a9889f8 (current
refs/users/aoliva/heads/testme) I get:


FAIL: 27_io/filesystem/iterators/caching.cc execution test
FAIL: 27_io/filesystem/iterators/error_reporting.cc execution test
FAIL: 27_io/filesystem/iterators/pop.cc execution test
FAIL: 27_io/filesystem/iterators/recursion_pending.cc execution test
FAIL: 27_io/filesystem/iterators/recursive_directory_iterator.cc execution test

terminate called after throwing an instance of 
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot increment recursive directory iterator: No 
such file or directory


FAIL: 27_io/filesystem/operations/canonical.cc execution test
FAIL: 27_io/filesystem/operations/copy.cc execution test

terminate called after throwing an instance of 
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot remove all: No such file or directory [...] 
[...]



FAIL: 27_io/filesystem/operations/create_directories.cc execution test
FAIL: experimental/filesystem/operations/create_directories.cc execution test

.../libstdc++-v3/testsuite/.../filesystem/operations/create_directories.cc:{84,78}:
 void test01(): Assertion 'count == 6' failed.


FAIL: 27_io/filesystem/operations/create_directory.cc execution test
FAIL: experimental/filesystem/operations/create_directory.cc execution test

[times out]


FAIL: 27_io/filesystem/operations/is_empty.cc execution test
FAIL: experimental/filesystem/operations/is_empty.cc execution test

Skipping tests that depend on filesystem permissions
[times out]


FAIL: 27_io/filesystem/operations/remove_all.cc execution test
FAIL: experimental/filesystem/operations/remove_all.cc execution test

.../libstdc++-v3/testsuite/.../filesystem/operations/remove_all.cc:6{7,8}: void 
test01(): Assertion '!ec' failed.


FAIL: 27_io/filesystem/operations/rename.cc execution test
FAIL: experimental/filesystem/operations/rename.cc execution test

.../libstdc++-v3/testsuite/.../filesystem/operations/rename.cc:5{1,2}: void 
test01(): Assertion '!ec' failed.


Also noteworthy, though unrelated with filesystem:

UNRESOLVED: 20_util/from_chars/4.cc compilation failed to produce executable
UNRESOLVED: 26_numerics/random/random_device/entropy.cc compilation failed to 
produce executable
 error: 'log2' is not a member of 'std'; did you mean 'log'?



-- 
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.  Ask me about 


[PATCH] testsuite: Compile slsr-39.c without vectorisation

2022-06-23 Thread Richard Sandiford via Gcc-patches
The fix for PR106019 regressed slsr-39.c for -m32 -march=cascadelake
because we are now able to vectorise the code.  (Whether the code model
should be allowing that is a different question -- the vectorised code
looked worse to me.)

The test runs at -O2 and predates vectorisation being enabled at -O2,
so this patch just adds -fno-tree-vectorize.

Tested on x86_64-linux-gnu.  Perhaps bordering on the obvious,
but just in case: OK to install?

(We do still share the multiplication, it's just that with
vectorisation we share it fewer times.)

Richard


gcc/testsuite/
* gcc.dg/tree-ssa/slsr-39.c: Force vectorization off.
---
 gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c 
b/gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c
index 4a27ede1541..33e34fab7ca 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/slsr-39.c
@@ -6,7 +6,7 @@
 *PINDEX:   C1 + (C2 * C3) + C4  */
 
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-slsr-details" } */
+/* { dg-options "-O2 -fno-tree-vectorize -fdump-tree-slsr-details" } */
 
 typedef int arr_2[50][50];
 
-- 
2.25.1



Re: [PATCH] libstdc++-v3: check for openat

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 05:41, Alexandre Oliva  wrote:
>
> On Jun 22, 2022, Jonathan Wakely  wrote:
>
> > Otherwise, if rterms defines HAVE_DIRFD this function will return a
> > file descriptor and a filename (not a full path) but then
> > _Dir_base::openat doesn't use ::openat and so ignores the file
> > descriptor, and needs a full path.
>
> Yuck.  It does.  This may explain some of the fails I've observed and
> not looked into yet.

Yes, that's what I was thinking too.


> How about introducing an internal wrapper class that can hold a ref to
> base path or an fd for a dir, or an iterator that could resolve to
> either, and that can be passed around instead of a dirfd that assumes
> openat, enabling uses of openat where available and falling back to
> paths otherwise?  I don't have much of a sense of all the uses involved,
> but given the AFAICT impossibility of turning a dirfd into a pathname
> (even in non-pathological cases of removed or out-of-chroot dirfds),
> ISTM this wrapper class could demand base paths or CWD in the
> !HAVE_OPENAT case, and enable both uses otherwise, offering some
> additional type safety that the current abstraction doesn't.
>
> Does that make sense to you?

I don't think that quite works. I think what we want is more like:

struct multipath /* need better name */
{
  int fd;
  const char* filename;
  const char* pathname;
};

I already prototyped something like this, let me finish it off and
send the patch.



Re: [PATCH] libstdc++: testsuite: fs rename to self may fail

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022 at 07:26, Alexandre Oliva wrote:
> This feels more and more like a case for xfail until it gets fixed in
> the kernel, where atomic filesystem operations belong :-(
>
> Would a patch to add:
>
> // { dg-xfail-if "::rename is not POSIX-compliant" { target *-*-rtems* } }
>
> to rename.cc tests be acceptable?  I'm afraid I can't go further down
> this rabbit hole, and my choices ATM seem to be limited to XFAIL
> patches, whether accepted by the GCC community or carried internally.


Yes, I think that's definitely the way to go.



Re: [PATCH] libstdc++: testsuite: use -lbsd for net_ts on RTEMS

2022-06-23 Thread Jonathan Wakely via Gcc-patches
On Thu, 23 Jun 2022, 10:02 Sebastian Huber, <
sebastian.hu...@embedded-brains.de> wrote:

> On 22/06/2022 07:24, Alexandre Oliva via Gcc-patches wrote:
> > +} elseif { [istarget *-*-rtems*] } {
> > + # Adding -Wl,--gc-sections would enable a few more tests to
> > + # link, but all of them fail at runtime anyway, because the
> > + # io_context ctor calls pipe(), which always fails, and thus
> > + # the ctor throws a system error.
> > + return "$flags -lbsd"
>
> Using -Wl,--gc-sections is mandatory if you want to link against
> libbsd.a. In general, it is recommended for RTEMS applications.
>
> For pipe() support in RTEMS, you currently need the
>
> #define CONFIGURE_IMFS_ENABLE_MKFIFO
>
> application configuration option.
>


It would also be fine to just xfail the networking tests for rtems. Our
implementation of the Networking TS is incomplete, buggy, and unlikely to
evolve much until the C++ committee makes progress on standardized
networking.

Anybody who wants to use the Networking TS model has to use Boost.Asio for
real work, our partial implementation isn't good enough. So making it work
and pass tests on rtems isn't important.


Re: [PATCH] libstdc++: testsuite: use -lbsd for net_ts on RTEMS

2022-06-23 Thread Sebastian Huber

On 22/06/2022 07:24, Alexandre Oliva via Gcc-patches wrote:

+} elseif { [istarget *-*-rtems*] } {
+   # Adding -Wl,--gc-sections would enable a few more tests to
+   # link, but all of them fail at runtime anyway, because the
+   # io_context ctor calls pipe(), which always fails, and thus
+   # the ctor throws a system error.
+   return "$flags -lbsd"


Using -Wl,--gc-sections is mandatory if you want to link against 
libbsd.a. In general, it is recommended for RTEMS applications.


For pipe() support in RTEMS, you currently need the

#define CONFIGURE_IMFS_ENABLE_MKFIFO

application configuration option.

--
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: [PATCH] libstdc++: 60241.cc: tolerate slightly shorter aggregate sleep

2022-06-23 Thread Sebastian Huber

On 23/06/2022 08:44, Sebastian Huber wrote:

On 23/06/2022 02:19, Alexandre Oliva wrote:
On Jun 22, 2022, Sebastian Huber  
wrote:



The clock_nanosleep() uses the coarse resolution which may give a time
before now().

Uhh, sorry, hit send too early.

I also meant to ask whether you'd like me to file an RTEMS ticket about
this issue.


I already created a ticket for this and work on it:

http://devel.rtems.org/ticket/4669


This problem should be fixed now in the RTEMS master branch. I had to 
adjust the test case so that it works in a system with only one processor:


  while (!sleeping)
  {
// Wait for the thread to start sleeping.
std::this_thread::yield();
  }

--
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: [x86 PATCH] PR target/105930: Split *xordi3_doubleword after reload.

2022-06-23 Thread Uros Bizjak via Gcc-patches
On Wed, Jun 22, 2022 at 1:39 PM Roger Sayle  wrote:
>
>
> This patch addresses PR target/105930 which is an ia32 stack frame size
> regression in high-register pressure XOR-rich cryptography functions
> reported by Linus Torvalds.  The underlying problem is once the limited
> number of registers on the x86 are exhausted, the register allocator
> has to decide which to spill, where some eviction choices lead to much
> poorer code, but these consequences are difficult to predict in advance.
>
> The patch below, which splits xordi3_doubleword and iordi3_doubleword
> after reload (instead of before), significantly reduces the amount of
> spill code and stack frame size, in what might appear to be an arbitrary
> choice.
>
> My explanation of this behaviour is that the mixing of pre-reload split
> SImode instructions and post-reload split DImode instructions is
> confusing some of the heuristics used by reload.  One might think
> that splitting early gives the register allocator more freedom to
> use available registers, but in practice the constraint that double
> word values occupy consecutive registers (when ultimately used as a
> DImode value) is the greater constraint.  Instead, I believe in this
> case, the pseudo registers used in memory addressing, appear to be
> double counted for split SImode instructions compared to unsplit
> DImode instructions.  For the reduced test case in comment #13, this
> leads to %eax being used to hold the long-lived argument pointer "v",
> blocking the use of the ax:dx pair for processing double word values.
> The important lines are at the very top of the assembly output:
>
> GCC 11  [use %ecx to address memory, require a 24-byte stack frame]
> sub esp, 24
> mov ecx, DWORD PTR [esp+40]
>
> GCC 12 [use %eax to address memory, require a 44-byte stack frame]
> sub esp, 44
> mov eax, DWORD PTR [esp+64]

The pre-reload vs. post-reload approach is a constant source of
various regressions, since one or the other has its benefits and
drawbacks. Please note that arithmetic and shift instructions remain
on a post-reload approach, since there were various regressions w.r.t.
register allocator observed.

I think that the best approach for now would be to move *all*
double-word splitters to the post-reload approach. As you exposed
above, mixing pre-reload and post-reload approaches confuses reload
too much due to the blocking of the part of a register pair.

> Jakub's alternative proposed patch in comment #17 is to improve
> consistency by splitting more instructions (rotates) before reload,
> which shows a small improvement, but not to GCC v11 levels.

So, I guess the experiment shows that we should revert to post-reload
splitters, while keeping the improvements splitters gain from
post-reload implementation.

> I have some follow-up patches (based on other approaches I've tried),
> including splitting rotations by 32 after reload, and supporting
> TImode operations via , notice this same pattern is mentioned in
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596201.html
> but this patch below is the core minimal fix that's hopefully
> suitable for benchmarking and possibly backporting to the 12 branch.
> I believe that changes to the register allocator itself, to tweak how
> stack slots are assigned and which values can be cheaply materialized
> are out-of-scope for the release branches.

I assume that and/andnot should also be moved to a post-reload split approach.
>
>
> I'm curious what folks (especially Uros and Jakub) think?
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures.  CSiBE also shows a (minor) code size reduction.
> It would be great if someone could benchmark this patch, or alternatively
> it can be baked on mainline to let the automatic benchmarking evaluate it,
> then revert the patch if there are any observed performance issues.
>
> Thoughts?
>
>
> 2022-06-22  Roger Sayle  
>
> gcc/ChangeLog
> PR target/105930
> * config/i386/i386.md (*di3_doubleword): Split after
> reload.  Use rtx_equal_p to avoid creating memory-to-memory moves,
> and emit NOTE_INSN_DELETED if operand[2] is zero (i.e. with -O0).
> (define_insn _1): Renamed from *mode_1
> to provide gen_si_1 functions.

Is there a reason to not use ix86_expand_{binary|unary}_operator? It
fits perfectly here.

Otherwise, the patch looks OK to me.

Uros.