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

[Richard Biener via Gcc-patches]

On Fri, Jun 24, 2022 at 2:34 AM Andrew Pinski via Gcc-patches
 wrote:
>
> 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.

Different when non-aggregates are involved?  Does default_packed
also apply to scalar types?

Btw, new effective targets should be documented in sourcebuild.texi

Richard.

> 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/

[PATCH 2/8] fixincludes: use grep -E/-F instead of egrep/fgrep

[Xi Ruoyao via Gcc-patches]

egrep/fgrep has been deprecated in favor of grep -E/-F for a long time,
and the next grep release (3.8 or 4.0) will print a warning if egrep or
fgrep is used.  Stop using egrep and fgrep so we won't see the warning.

fixincludes/ChangeLog:

* fixinc.in: Use grep -E instead of egrep.
* inclhack.def: Likewise.
* fixincl.x: Regenerate.
* genfixes: Use grep -F instead of fgrep.
---
 fixincludes/fixinc.in|  2 +-
 fixincludes/fixincl.x| 10 +-
 fixincludes/genfixes |  2 +-
 fixincludes/inclhack.def |  6 +++---
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index 0bd8027a554..b5395805cce 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -448,7 +448,7 @@ while [ $# != 0 ]; do
 chmod a+r $3 2>/dev/null
 if test $VERBOSE -gt 2
 then echo Copied $2 ; fi
-for include in `egrep '^[  ]*#[]*include[  ]*"[^/]' $3 |
+for include in `grep -E '^[]*#[]*include[  ]*"[^/]' $3 |
  sed -e 's/^[  ]*#[]*include[  ]*"\([^"]*\)".*$/\1/'`
 do
  dir=`echo $2 | sed -e s'|/[^/]*$||'`
diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
index bad490453b7..babd83ebd08 100644
--- a/fixincludes/fixincl.x
+++ b/fixincludes/fixincl.x
@@ -2,11 +2,11 @@
  *
  * DO NOT EDIT THIS FILE   (fixincl.x)
  *
- * It has been AutoGen-ed  February 27, 2022 at 07:47:03 PM by AutoGen 5.18.16
+ * It has been AutoGen-ed  June 24, 2022 at 01:40:08 PM by AutoGen 5.18.16
  * From the definitionsinclhack.def
  * and the template file   fixincl
  */
-/* DO NOT SVN-MERGE THIS FILE, EITHER Sun Feb 27 19:47:03 UTC 2022
+/* DO NOT SVN-MERGE THIS FILE, EITHER Fri Jun 24 13:40:08 CST 2022
  *
  * You must regenerate it.  Use the ./genfixes script.
  *
@@ -6547,7 +6547,7 @@ static tTestDesc aMath_Huge_Val_From_Dbl_MaxTests[] = {
  *  Fix Command Arguments for Math_Huge_Val_From_Dbl_Max
  */
 static const char* apzMath_Huge_Val_From_Dbl_MaxPatch[] = { "sh", "-c",
-"\tdbl_max_def=`egrep 'define[ \t]+DBL_MAX[ \t]+.*' float.h | sed 
's/.*DBL_MAX[ \t]*//' 2>/dev/null`\n\n\
+"\tdbl_max_def=`grep -E 'define[ \t]+DBL_MAX[ \t]+.*' float.h | sed 
's/.*DBL_MAX[ \t]*//' 2>/dev/null`\n\n\
 \tif ( test -n \"${dbl_max_def}\" ) > /dev/null 2>&1\n\
 \tthen sed -e '/define[ \t]*HUGE_VAL[ 
\t]*DBL_MAX/s@DBL_MAX@'\"$dbl_max_def@\"\n\
 \telse cat\n\
@@ -10402,9 +10402,9 @@ tSCC zVxworks_Needs_VxworksSelect0[] =
 tSCC zVxworks_Needs_VxworksTest0[] =
" -r types/vxTypesOld.h";
 tSCC zVxworks_Needs_VxworksTest1[] =
-   " -n \"`egrep '#include' $file`\"";
+   " -n \"`grep -E '#include' $file`\"";
 tSCC zVxworks_Needs_VxworksTest2[] =
-   " -n \"`egrep ULONG $file`\"";
+   " -n \"`grep -E ULONG $file`\"";
 
 #defineVXWORKS_NEEDS_VXWORKS_TEST_CT  4
 static tTestDesc aVxworks_Needs_VxworksTests[] = {
diff --git a/fixincludes/genfixes b/fixincludes/genfixes
index 47aad01289d..d2cbb50c39b 100755
--- a/fixincludes/genfixes
+++ b/fixincludes/genfixes
@@ -58,7 +58,7 @@ done
 AG="autogen $AG"
 set -e
 
-if [ -z "`${AG} -v | fgrep ' 5.'`" ]
+if [ -z "`${AG} -v | grep -F ' 5.'`" ]
 then
   echo "AutoGen appears to be out of date or not correctly installed."
   echo "Please download and install from:"
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 7605ac89aa2..7b0f7cae0b1 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -3274,7 +3274,7 @@ fix = {
  *  If we do, we will replace the one in math.h with that one.
  */
 
-"\tdbl_max_def=`egrep 'define[ \t]+DBL_MAX[ \t]+.*' float.h "
+"\tdbl_max_def=`grep -E 'define[ \t]+DBL_MAX[ \t]+.*' float.h "
"| sed 's/.*DBL_MAX[ \t]*//' 2>/dev/null`\n\n"
 
 "\tif ( test -n \"${dbl_max_def}\" ) > /dev/null 2>&1\n"
@@ -5266,8 +5266,8 @@ fix = {
 hackname = vxworks_needs_vxworks;
 files= sys/stat.h;
 test = " -r types/vxTypesOld.h";
-test = " -n \"`egrep '#include' $file`\"";
-test = " -n \"`egrep ULONG $file`\"";
+test = " -n \"`grep -E '#include' $file`\"";
+test = " -n \"`grep -E ULONG $file`\"";
 select   = "#[ \t]define[ \t]+__INCstath";
 
 sed = "/#[ \t]define[ \t][ \t]*__INCstath/a\\\n"
-- 
2.36.1

[PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts

[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.

libstdc++-v3/ChangeLog:

* scripts/extract_symvers.in: Use grep -E instead of egrep.
* libstdc++-v3/scripts/run_doxygen: Likewise.
---
 libstdc++-v3/scripts/extract_symvers.in | 4 ++--
 libstdc++-v3/scripts/run_doxygen| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/scripts/extract_symvers.in 
b/libstdc++-v3/scripts/extract_symvers.in
index dd9f63d4f16..d8ea62355ae 100755
--- a/libstdc++-v3/scripts/extract_symvers.in
+++ b/libstdc++-v3/scripts/extract_symvers.in
@@ -54,8 +54,8 @@ SunOS)
   ${readelf} ${lib} |\
   sed -e 's/ \[: [A-Fa-f0-9]*\] //' -e '/\.dynsym/,/^$/p;d' |\
   sed -e 's/ \[: [0-9]*\] //' |\
-  egrep -v ' (LOCAL|UND) ' |\
-  egrep -v ' 
(_DYNAMIC|_GLOBAL_OFFSET_TABLE_|_PROCEDURE_LINKAGE_TABLE_|_edata|_end|_etext)$' 
|\
+  grep -E -v ' (LOCAL|UND) ' |\
+  grep -E -v ' 
(_DYNAMIC|_GLOBAL_OFFSET_TABLE_|_PROCEDURE_LINKAGE_TABLE_|_edata|_end|_etext)$' 
|\
   sed -e 's/ : / :_/g' |\
   sed -e 's/ : / :_/g' |\
   sed -e 's/ : / :_/g' |\
diff --git a/libstdc++-v3/scripts/run_doxygen b/libstdc++-v3/scripts/run_doxygen
index 86da071d86c..50514c744c9 100644
--- a/libstdc++-v3/scripts/run_doxygen
+++ b/libstdc++-v3/scripts/run_doxygen
@@ -291,7 +291,7 @@ cxxflags="-Og -g -std=gnu++23"
 $gxx $cppflags $cxxflags ${srcdir}/doc/doxygen/stdheader.cc -o ./stdheader || 
exit 1
 # Doxygen outputs something like "\fC#include \fP" and
 # we want that internal header to be replaced with something like .
-problematic=`egrep -l '#include <.*h>' [a-z]*.3`
+problematic=`grep -E -l '#include <.*h>' [a-z]*.3`
 for f in $problematic; do
 # this is also slow, but safe and easy to debug
 oldh=`sed -n '/fC#include .*/\1/p' $f`
@@ -303,7 +303,7 @@ rm stdheader
 # Some of the pages for generated modules have text that confuses certain
 # implementations of man(1), e.g. on GNU/Linux.  We need to have another
 # top-level *roff tag to /stop/ the .SH NAME entry.
-problematic=`egrep --files-without-match '^\.SH SYNOPSIS' [A-Z]*.3`
+problematic=`grep -E --files-without-match '^\.SH SYNOPSIS' [A-Z]*.3`
 #problematic='Containers.3 Sequences.3 Assoc_containers.3 Iterator_types.3'
 
 for f in $problematic; do
-- 
2.36.1

[PATCH 4/8] libbacktrace: use grep -F instead of fgrep

[Xi Ruoyao via Gcc-patches]

fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
Stop using fgrep so we won't see the warning.

libbacktrace/ChangeLog:

* configure.ac: Use grep -F instead of fgrep.
* configure: Regenerate.
---
 libbacktrace/configure| 2 +-
 libbacktrace/configure.ac | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libbacktrace/configure b/libbacktrace/configure
index 17f470a4bec..45173b08fb6 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -13831,7 +13831,7 @@ else
   libbacktrace_cv_objcopy_debuglink=no
 elif ! test -n "${OBJCOPY}"; then
   libbacktrace_cv_objcopy_debuglink=no
-elif ${OBJCOPY} --help | fgrep add-gnu-debuglink >/dev/null 2>&1; then
+elif ${OBJCOPY} --help | grep -F add-gnu-debuglink >/dev/null 2>&1;
then
   libbacktrace_cv_objcopy_debuglink=yes
 else
   libbacktrace_cv_objcopy_debuglink=no
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 597c9705db8..bcce4f31b85 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -500,7 +500,7 @@ AC_CACHE_CHECK([whether objcopy supports debuglink],
   libbacktrace_cv_objcopy_debuglink=no
 elif ! test -n "${OBJCOPY}"; then
   libbacktrace_cv_objcopy_debuglink=no
-elif ${OBJCOPY} --help | fgrep add-gnu-debuglink >/dev/null 2>&1; then
+elif ${OBJCOPY} --help | grep -F add-gnu-debuglink >/dev/null 2>&1;
then
   libbacktrace_cv_objcopy_debuglink=yes
 else
   libbacktrace_cv_objcopy_debuglink=no
-- 
2.36.1

[PATCH 5/8] intl: stop using fgrep for exgettext

[Xi Ruoyao via Gcc-patches]

fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
And, the fgrep command in exgettext is no longer useful after we
migrated from SVN to Git.  Remove the fgrep command so we won't see the
warning.

gcc/ChangeLog:

* po/exgettext: Remove unneeded fgrep command.
---
 gcc/po/exgettext | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/po/exgettext b/gcc/po/exgettext
index 95cb0e75554..43b2e81bd24 100644
--- a/gcc/po/exgettext
+++ b/gcc/po/exgettext
@@ -99,7 +99,7 @@ echo "scanning for keywords, %e and %n strings..." >&2
   lang_subdirs=`echo */config-lang.in */*/config-lang.in | sed -e 
's|/config-lang\.in||g'`
   { for dir in "" c-family/ common/ common/config/ common/config/*/ \
   config/ config/*/ \
-  `find $lang_subdirs -type d -print | fgrep -v .svn | sort | sed -e 
's|$|/|'`
+  `find $lang_subdirs -type d -print | sort | sed -e 's|$|/|'`
 do  for glob in '*.c' '*.cc' '*.h' '*.def'
 do  eval echo $dir$glob
 done
-- 
2.36.1

[PATCH 6/8] fortran: use grep -F instead of fgrep

[Xi Ruoyao via Gcc-patches]

fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
Stop using fgrep so we won't see the warning.

gcc/ChangeLog:

* fortran/Make-lang.in: Use grep -F instead of fgrep.
---
 gcc/fortran/Make-lang.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
index 1cb47cb1a52..51279b03aad 100644
--- a/gcc/fortran/Make-lang.in
+++ b/gcc/fortran/Make-lang.in
@@ -278,7 +278,7 @@ $(DESTDIR)$(man1dir)/$(GFORTRAN_INSTALL_NAME)$(man1ext): 
doc/gfortran.1 \
-chmod a-x $@
 
 fortran.uninstall:
-   if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i 
debian' >/dev/null 2>&1; then \
+   if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i 
debian' >/dev/null 2>&1; then \
  echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) 
$(DESTDIR)$(infodir)/gfortran.info"; \
  install-info --delete --info-dir=$(DESTDIR)$(infodir) 
$(DESTDIR)$(infodir)/gfortran.info || : ; \
else : ; fi; \
-- 
2.36.1

[PATCH 7/8] testsuite: use grep -E instead of egrep

[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.

gcc/testsuite/ChangeLog:

* ada/acats/run_all.sh: Use grep -E instead of egrep.
* go.test/go-test.exp: Likewise.
---
 gcc/testsuite/ada/acats/run_all.sh | 2 +-
 gcc/testsuite/go.test/go-test.exp  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/ada/acats/run_all.sh 
b/gcc/testsuite/ada/acats/run_all.sh
index ac2a86bea6c..a48b492711b 100755
--- a/gcc/testsuite/ada/acats/run_all.sh
+++ b/gcc/testsuite/ada/acats/run_all.sh
@@ -367,7 +367,7 @@ for chapter in $chapters; do
   target_run $dir/tests/$chapter/$i/$binmain > 
$dir/tests/$chapter/$i/${i}.log 2>&1
   cd $dir/tests/$chapter/$i
   cat ${i}.log >> $dir/acats.log
-  egrep -e '( |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
+  grep -E -e '( |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
   if [ $? -ne 0 ]; then
  grep 'tasking not implemented' ${i}.log > /dev/null 2>&1
 
diff --git a/gcc/testsuite/go.test/go-test.exp 
b/gcc/testsuite/go.test/go-test.exp
index 11c178ad7ec..5699d3d248d 100644
--- a/gcc/testsuite/go.test/go-test.exp
+++ b/gcc/testsuite/go.test/go-test.exp
@@ -1207,7 +1207,7 @@ proc go-gc-tests { } {
   || $test_line == "// \$G \$D/empty.go && errchk \$G 
\$D/\$F.go" } {
# These tests import the same package under two different
# names, which gccgo does not support.
-   } elseif { $test_line == "// \$G -S \$D/\$F.go | egrep initdone 
>/dev/null && echo BUG sinit || true" } {
+   } elseif { $test_line == "// \$G -S \$D/\$F.go | grep -E initdone 
>/dev/null && echo BUG sinit || true" } {
# This tests whether initializers are written out
# statically.  gccgo does not provide a way to test that,
# as an initializer will be generated for any code which
-- 
2.36.1

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

[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.

contrib/ChangeLog:

* check_GNU_style.sh: Use grep -E instead of egrep.
* test_summary: Likewise.
* warn_summary: Likewise.
---
 contrib/check_GNU_style.sh | 10 +-
 contrib/test_summary   |  2 +-
 contrib/warn_summary   |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/contrib/check_GNU_style.sh b/contrib/check_GNU_style.sh
index fb7494661ee..535be65f063 100755
--- a/contrib/check_GNU_style.sh
+++ b/contrib/check_GNU_style.sh
@@ -113,7 +113,7 @@ g (){
 
 local found=false
 cat $inp \
-   | egrep $color -- "$arg" \
+   | grep -E $color -- "$arg" \
> "$tmp" && found=true
 
 if $found; then
@@ -130,8 +130,8 @@ ag (){
 
 local found=false
 cat $inp \
-   | egrep $color -- "$arg1" \
-   | egrep $color -- "$arg2" \
+   | grep -E $color -- "$arg1" \
+   | grep -E $color -- "$arg2" \
> "$tmp" && found=true
 
 if $found; then
@@ -148,8 +148,8 @@ vg (){
 
 local found=false
 cat $inp \
-   | egrep -v -- "$varg" \
-   | egrep $color -- "$arg" \
+   | grep -E -v -- "$varg" \
+   | grep -E $color -- "$arg" \
> "$tmp" && found=true
 
 if $found; then
diff --git a/contrib/test_summary b/contrib/test_summary
index 5760b053ec2..30494077aaa 100755
--- a/contrib/test_summary
+++ b/contrib/test_summary
@@ -77,7 +77,7 @@ for file in $files; do
 { $anychange ||
   anychange=`diff $file.sent $file 2>/dev/null |
if test ! -f $file.sent ||
-  egrep '^[<>] (XPASS|FAIL)' >/dev/null; then
+  grep -E '^[<>] (XPASS|FAIL)' >/dev/null; then
echo true
else
echo false
diff --git a/contrib/warn_summary b/contrib/warn_summary
index d4c8b6cdb19..eb88437e79d 100755
--- a/contrib/warn_summary
+++ b/contrib/warn_summary
@@ -57,7 +57,7 @@ subdirectoryFilter()
   else
 if test "$filter" = nosub ; then
   # Omit all subdirectories.
-  egrep -v '/gcc/(ch|cp|f|fortran|ada|intl|fixinc)/'
+  grep -E -v '/gcc/(ch|cp|f|fortran|ada|intl|fixinc)/'
 else
   # Pass through only subdir $filter.
   grep "/gcc/$filter/"
-- 
2.36.1

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

[Rainer Orth]

Hi Xi,

> 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:

please remember that there's a world outside of GNU grep: e.g. Solaris
/bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
unconditionally replacing egrep with grep -E in several places is likely
to break at least the Solaris build.

Please see the autoconf manual for details.  I suspect you'll have to
rework the patch set to use AC_PROG_EGREP and $EGREP instead.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

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

[Richard Biener via Gcc-patches]

On Thu, 23 Jun 2022, Richard Sandiford wrote:

> 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
>

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

[Xi Ruoyao via Gcc-patches]

On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:

> please remember that there's a world outside of GNU grep: e.g. Solaris
> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
> unconditionally replacing egrep with grep -E in several places is
> likely
> to break at least the Solaris build.
> 
> Please see the autoconf manual for details.  I suspect you'll have to
> rework the patch set to use AC_PROG_EGREP and $EGREP instead.

Thanks for the advice.  I'll rework on it.

Is there some way to access a Solaris and do some test?

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

[Rainer Orth]

Hi Xi,

> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
>
>> please remember that there's a world outside of GNU grep: e.g. Solaris
>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
>> unconditionally replacing egrep with grep -E in several places is
>> likely
>> to break at least the Solaris build.
>> 
>> Please see the autoconf manual for details.  I suspect you'll have to
>> rework the patch set to use AC_PROG_EGREP and $EGREP instead.
>
> Thanks for the advice.  I'll rework on it.
>
> Is there some way to access a Solaris and do some test?

Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
farm (https://gcc.gnu.org/wiki/CompileFarm).

Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
moment, but those don't differ in this regard.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[PATCH] profile-count: fix /= and *= operators

[Martin Liška]

Hi.

As noticed in the PR, I wrongly introduced /= and *= operators.
Problem was that these operators need to modify *this object.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR middle-end/106059

gcc/ChangeLog:

* profile-count.h: *= and /= operators need to modify this
object.
---
 gcc/profile-count.h | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/gcc/profile-count.h b/gcc/profile-count.h
index be6e2d57cf7..141a8827001 100644
--- a/gcc/profile-count.h
+++ b/gcc/profile-count.h
@@ -605,9 +605,10 @@ public:
   return apply_scale (num, 1);
 }
 
-  profile_probability operator*= (int64_t den) const
+  profile_probability operator*= (int64_t num)
 {
-  return *this * den;
+  *this = apply_scale (num, 1);
+  return *this;
 }
 
   profile_probability operator/ (int64_t den) const
@@ -615,9 +616,10 @@ public:
   return apply_scale (1, den);
 }
 
-  profile_probability operator/= (int64_t den) const
+  profile_probability operator/= (int64_t den)
 {
-  return *this / den;
+  *this = apply_scale (1, den);
+  return *this;
 }
 
   /* Get the value of the count.  */
@@ -1017,9 +1019,10 @@ public:
   return apply_scale (num, 1);
 }
 
-  profile_count operator*= (int64_t den) const
+  profile_count operator*= (int64_t num)
 {
-  return *this * den;
+  *this = apply_scale (num, 1);
+  return *this;
 }
 
   profile_count operator/ (int64_t den) const
@@ -1027,9 +1030,10 @@ public:
   return apply_scale (1, den);
 }
 
-  profile_count operator/= (int64_t den) const
+  profile_count operator/= (int64_t den)
 {
-  return *this / den;
+  *this = apply_scale (1, den);
+  return *this;
 }
 
   /* Return true when value is not zero and can be used for scaling. 
-- 
2.36.1

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

[Fangrui Song via Gcc-patches]

On 2022-06-24, Rainer Orth wrote:

Hi Xi,


On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:


please remember that there's a world outside of GNU grep: e.g. Solaris
/bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
unconditionally replacing egrep with grep -E in several places is
likely
to break at least the Solaris build.

Please see the autoconf manual for details.  I suspect you'll have to
rework the patch set to use AC_PROG_EGREP and $EGREP instead.


Thanks for the advice.  I'll rework on it.

Is there some way to access a Solaris and do some test?


Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
farm (https://gcc.gnu.org/wiki/CompileFarm).

Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
moment, but those don't differ in this regard.

Rainer


FWIW: glibc recently got the grep -E change and the solution is to use
plain grep -E, without $EGREP things.
Isn't setting PATH a good workaround if Solaris has the problem?

https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html

Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only 
vendor-supported platform I know of where '/usr/bin/grep -E' does not 
work is Solaris 10 (end-of-life January 2024), and that's easily fixed 
by prepending /usr/xpg4/bin to PATH.

Re: Add fnspec attributes to cxa_* functions

[Richard Biener via Gcc-patches]

> Am 23.06.2022 um 16:00 schrieb 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.
> 

Looks OK to me, let’s see if Jason has any comments though.

Richard 

> 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 (f

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

[Andrew Pinski via Gcc-patches]

On Fri, Jun 24, 2022 at 1:27 AM Fangrui Song via Gcc-patches
 wrote:
>
> On 2022-06-24, Rainer Orth wrote:
> >Hi Xi,
> >
> >> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
> >>
> >>> please remember that there's a world outside of GNU grep: e.g. Solaris
> >>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
> >>> unconditionally replacing egrep with grep -E in several places is
> >>> likely
> >>> to break at least the Solaris build.
> >>>
> >>> Please see the autoconf manual for details.  I suspect you'll have to
> >>> rework the patch set to use AC_PROG_EGREP and $EGREP instead.
> >>
> >> Thanks for the advice.  I'll rework on it.
> >>
> >> Is there some way to access a Solaris and do some test?
> >
> >Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
> >farm (https://gcc.gnu.org/wiki/CompileFarm).
> >
> >Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
> >moment, but those don't differ in this regard.
> >
> >   Rainer
>
> FWIW: glibc recently got the grep -E change and the solution is to use
> plain grep -E, without $EGREP things.
> Isn't setting PATH a good workaround if Solaris has the problem?

glibc is a different story partly but I think GCC should go down the
EGREP route. glibc is not as friendly to non-GNU based systems
compared to GCC really.
Though I do find that -E/-F have been part of the POSIX standard since
at least 2004 which is interesting.
https://pubs.opengroup.org/onlinepubs/009696899/utilities/grep.html
Though GCC host/build targets can be older and some non-supported ones still.

Thanks,
Andrew Pinski

>
> https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html
>
> > Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only
> > vendor-supported platform I know of where '/usr/bin/grep -E' does not
> > work is Solaris 10 (end-of-life January 2024), and that's easily fixed
> > by prepending /usr/xpg4/bin to PATH.

Re: [PATCH 2/3] lto-plugin: make claim_file_handler thread-safe

[Richard Biener via Gcc-patches]

> Am 21.06.2022 um 10:43 schrieb Martin Liška :
> 
> On 6/21/22 09:56, Richard Biener wrote:
>>> On Mon, Jun 20, 2022 at 12:20 PM Martin Liška  wrote:
>>> 
>>> On 6/20/22 11:32, Richard Biener wrote:
 On Thu, Jun 16, 2022 at 9:01 AM Martin Liška  wrote:
> 
> lto-plugin/ChangeLog:
> 
>* lto-plugin.c (plugin_lock): New lock.
>(claim_file_handler): Use mutex for critical section.
>(onload): Initialize mutex.
> ---
> lto-plugin/lto-plugin.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
> index 00b760636dc..13118c4983c 100644
> --- a/lto-plugin/lto-plugin.c
> +++ b/lto-plugin/lto-plugin.c
> @@ -55,6 +55,7 @@ along with this program; see the file COPYING3.  If not 
> see
> #include 
> #include 
> #include 
> +#include 
 
 Not sure if we support any non-pthread target for building the LTO
 plugin, but it
 seems we have
 
  # Among non-ELF, only Windows platforms support the lto-plugin so far.
  # Build it unless LTO was explicitly disabled.
  case $target in
*-cygwin* | *-mingw*) build_lto_plugin=$enable_lto ;;
 
 which suggests that at least build validating the above with --enable-lto
>>> 
>>> Verified that it's fine.
>>> 
 
 IIRC we have gthr-*.h in libgcc/, not sure if that's usable in a
 host linker plugin.
 
> #ifdef HAVE_SYS_WAIT_H
> #include 
> #endif
> @@ -157,6 +158,9 @@ enum symbol_style
>   ss_uscore,   /* Underscore prefix all symbols.  */
> };
> 
> +/* Plug-in mutex.  */
> +static pthread_mutex_t plugin_lock;
> +
> static char *arguments_file_name;
> static ld_plugin_register_claim_file register_claim_file;
> static ld_plugin_register_all_symbols_read register_all_symbols_read;
> @@ -1262,15 +1266,18 @@ claim_file_handler (const struct 
> ld_plugin_input_file *file, int *claimed)
>  lto_file.symtab.syms);
>   check (status == LDPS_OK, LDPL_FATAL, "could not add symbols");
> 
> +  pthread_mutex_lock (&plugin_lock);
>   num_claimed_files++;
>   claimed_files =
>xrealloc (claimed_files,
>  num_claimed_files * sizeof (struct plugin_file_info));
>   claimed_files[num_claimed_files - 1] = lto_file;
> +  pthread_mutex_unlock (&plugin_lock);
> 
>   *claimed = 1;
> }
> 
> +  pthread_mutex_lock (&plugin_lock);
>   if (offload_files == NULL)
> {
>   /* Add dummy item to the start of the list.  */
> @@ -1333,11 +1340,12 @@ claim_file_handler (const struct 
> ld_plugin_input_file *file, int *claimed)
>offload_files_last_lto = ofld;
>   num_offload_files++;
> }
> +  pthread_mutex_unlock (&plugin_lock);
> 
>   goto cleanup;
> 
>  err:
> -  non_claimed_files++;
> +  __atomic_fetch_add (&non_claimed_files, 1, __ATOMIC_RELAXED);
 
 is it worth "optimizing" this with yet another need for target specific 
 support
 (just use pthread_mutex here as well?)
>>> 
>>> Sure.
>>> 
>>> May I install the patch with the change?
>> 
>> Can you at least add a configure check for pthread.h and maybe disable
>> locking when not found or erroring out?  I figure we have 
>> GCC_AC_THREAD_HEADER
> 
> All right, let's error out then.
> 
>> for the gthr.h stuff using $target_thread_file (aka --enable-threads=XYZ),
>> but as said that's for the target and I don't see any host uses.  We might 
>> also
>> add an explicit list of hosts (*-linux*?) where we enable thread support for
>> lto-plugin, providing opt-in (so you'd have to wrap the mutex taking or
>> if-def it out).
>> 
>> I think you also need to link lto-plugin with -pthread, no?
> 
> Yep.
> 
> Please see the updated patch.
> 

Please use -pthread instead of -lpthread 

Otherwise looks OK to me.

>> On linux
>> it might work omitting that but I'm not sure other libc have serial pthread
>> stubs in their libc.  BFD ld definitely doesn't link against pthread so
>> dlopening lto-plugin will fail (also not all libc might like
>> initializing threads
>> from a dlopen _init).
> 
> What initializing threads do you mean?

It’s target dependent what kind of global state init need to be done when any 
pthread facility is used.

Richard 

> Martin
> 
>> 
>> Richard.
>> 
>>> Cheers,
>>> Martin
>>> 
 
>   free (lto_file.name);
> 
>  cleanup:
> @@ -1415,6 +1423,12 @@ onload (struct ld_plugin_tv *tv)
>   struct ld_plugin_tv *p;
>   enum ld_plugin_status status;
> 
> +  if (pthread_mutex_init (&plugin_lock, NULL) != 0)
> +{
> +  fprintf (stderr, "mutex init failed\n");
> +  abort ();
> +}
> +
>   p = tv;
>   while (p->tv_tag)
> {
> --
> 2.36

Re: [PATCH] profile-count: fix /= and *= operators

[Richard Biener via Gcc-patches]

> Am 24.06.2022 um 10:14 schrieb Martin Liška :
> 
> Hi.
> 
> As noticed in the PR, I wrongly introduced /= and *= operators.
> Problem was that these operators need to modify *this object.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?

Ok
> Thanks,
> Martin
> 
>PR middle-end/106059
> 
> gcc/ChangeLog:
> 
>* profile-count.h: *= and /= operators need to modify this
>object.
> ---
> gcc/profile-count.h | 20 
> 1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/gcc/profile-count.h b/gcc/profile-count.h
> index be6e2d57cf7..141a8827001 100644
> --- a/gcc/profile-count.h
> +++ b/gcc/profile-count.h
> @@ -605,9 +605,10 @@ public:
>   return apply_scale (num, 1);
> }
> 
> -  profile_probability operator*= (int64_t den) const
> +  profile_probability operator*= (int64_t num)
> {
> -  return *this * den;
> +  *this = apply_scale (num, 1);
> +  return *this;
> }
> 
>   profile_probability operator/ (int64_t den) const
> @@ -615,9 +616,10 @@ public:
>   return apply_scale (1, den);
> }
> 
> -  profile_probability operator/= (int64_t den) const
> +  profile_probability operator/= (int64_t den)
> {
> -  return *this / den;
> +  *this = apply_scale (1, den);
> +  return *this;
> }
> 
>   /* Get the value of the count.  */
> @@ -1017,9 +1019,10 @@ public:
>   return apply_scale (num, 1);
> }
> 
> -  profile_count operator*= (int64_t den) const
> +  profile_count operator*= (int64_t num)
> {
> -  return *this * den;
> +  *this = apply_scale (num, 1);
> +  return *this;
> }
> 
>   profile_count operator/ (int64_t den) const
> @@ -1027,9 +1030,10 @@ public:
>   return apply_scale (1, den);
> }
> 
> -  profile_count operator/= (int64_t den) const
> +  profile_count operator/= (int64_t den)
> {
> -  return *this / den;
> +  *this = apply_scale (1, den);
> +  return *this;
> }
> 
>   /* Return true when value is not zero and can be used for scaling. 
> -- 
> 2.36.1
> 

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

[Rainer Orth]

Hi Fangrui,

> FWIW: glibc recently got the grep -E change and the solution is to use
> plain grep -E, without $EGREP things.
> Isn't setting PATH a good workaround if Solaris has the problem?
>
> https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html

while it's possible, the $PATH solution is fragile and I fear the errors
that one gets all over the place when it's missed are highly unintuitive
and hard to diagnose.

>> Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only
>> vendor-supported platform I know of where '/usr/bin/grep -E' does not 
>> work is Solaris 10 (end-of-life January 2024), and that's easily fixed by
>> prepending /usr/xpg4/bin to PATH.

I'm not concerned about Solaris 10 at all: it's no longer supported by
GCC and GDB and while binutils formally still does, there's not much
value in having current binutils with older gcc etc.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

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

[Richard Sandiford via Gcc-patches]

Richard Biener  writes:
> On Thu, 23 Jun 2022, Richard Sandiford wrote:
>> 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

Re: [PATCH] libstdc++: testsuite: work around bitset namespace pollution

[Sebastian Huber]

On 21.06.22 07:31, Alexandre Oliva via Gcc-patches wrote:

rtems6 declares a global struct bitset in a header file included
indirectly by sys/types.h, that ambiguates the unqualified references
to bitset after "using namespace std" in the testsuite.

Work around the namespace pollution with using declarations of
std::bitset.


I fixed the problem in Newlib. This patch should be no longer necessary.

--
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 3/8] libstdc++: use grep -E instead of egrep in scripts

[Jonathan Wakely via Gcc-patches]

On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
 wrote:
>
> 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.
>
> libstdc++-v3/ChangeLog:
>
> * scripts/extract_symvers.in: Use grep -E instead of egrep.
> * libstdc++-v3/scripts/run_doxygen: Likewise.

This should be just scripts/run_doxygen here. You can use the git
gcc-verify alias to check your changelog format.


With that fixed it's OK for trunk and gcc-12 and gcc-11 branches, thanks!

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

[Jakub Jelinek via Gcc-patches]

On Thu, Jun 23, 2022 at 11:17:50PM +0200, Jakub Jelinek via Gcc-patches wrote:
> 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.

Here is an updated patch that does that.

> > > --- gcc/fortran/trans-intrinsic.cc.jj 2022-05-16 11:14:57.587427707 
> > > +0200
> > > +++ gcc/fortran/trans-intrinsic.cc2022-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.

And this too.

So I believe it should now be fully ABI compatible.

2022-06-24  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 "default" rather than yes if
have__Float128_libc_support is yes.
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): If libquadmath support
is defaulted and have__Float128_libc_support is yes, test
_Float128/_Complex _Float128 support and define and subst
HAVE__FLOAT128.  Remove unused LIBGFOR_BUILD_QUAD conditional.
* 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 o

Re: [PATCH 7/8] testsuite: use grep -E instead of egrep

[Arnaud Charlet 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.

Ada part is OK, thanks.

> gcc/testsuite/ChangeLog:
> 
>   * ada/acats/run_all.sh: Use grep -E instead of egrep.
>   * go.test/go-test.exp: Likewise.
> ---
>  gcc/testsuite/ada/acats/run_all.sh | 2 +-
>  gcc/testsuite/go.test/go-test.exp  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/ada/acats/run_all.sh 
> b/gcc/testsuite/ada/acats/run_all.sh
> index ac2a86bea6c..a48b492711b 100755
> --- a/gcc/testsuite/ada/acats/run_all.sh
> +++ b/gcc/testsuite/ada/acats/run_all.sh
> @@ -367,7 +367,7 @@ for chapter in $chapters; do
>target_run $dir/tests/$chapter/$i/$binmain > 
> $dir/tests/$chapter/$i/${i}.log 2>&1
>cd $dir/tests/$chapter/$i
>cat ${i}.log >> $dir/acats.log
> -  egrep -e '( |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
> +  grep -E -e '( |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
>if [ $? -ne 0 ]; then
>   grep 'tasking not implemented' ${i}.log > /dev/null 2>&1
>  
> diff --git a/gcc/testsuite/go.test/go-test.exp 
> b/gcc/testsuite/go.test/go-test.exp
> index 11c178ad7ec..5699d3d248d 100644
> --- a/gcc/testsuite/go.test/go-test.exp
> +++ b/gcc/testsuite/go.test/go-test.exp
> @@ -1207,7 +1207,7 @@ proc go-gc-tests { } {
>  || $test_line == "// \$G \$D/empty.go && errchk \$G 
> \$D/\$F.go" } {
>   # These tests import the same package under two different
>   # names, which gccgo does not support.
> - } elseif { $test_line == "// \$G -S \$D/\$F.go | egrep initdone 
> >/dev/null && echo BUG sinit || true" } {
> + } elseif { $test_line == "// \$G -S \$D/\$F.go | grep -E initdone 
> >/dev/null && echo BUG sinit || true" } {
>   # This tests whether initializers are written out
>   # statically.  gccgo does not provide a way to test that,
>   # as an initializer will be generated for any code which
> -- 
> 2.36.1
> 
> 

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

[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

Ah, but this patch only added the HAVE_OPENAT check to
src/filesystem/dir.cc not the similar code in src/c++17/fs_dir.cc

So it only affected std::experimental::filesystem and I would expect
the std::filesystem directory iterator tests to fail still.

Nevermind, I'm going to make a change that resolves it anyway.


> 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 
>

Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts

[Xi Ruoyao via Gcc-patches]

On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
>  wrote:
> > 
> > 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.
> > 
> > libstdc++-v3/ChangeLog:
> > 
> >     * scripts/extract_symvers.in: Use grep -E instead of egrep.
> >     * libstdc++-v3/scripts/run_doxygen: Likewise.
> 
> This should be just scripts/run_doxygen here. You can use the git
> gcc-verify alias to check your changelog format.
> 
> 
> With that fixed it's OK for trunk and gcc-12 and gcc-11 branches,
> thanks!

I'll need some rework as Rainer told me "grep -E" may not work on some
Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
is exactly for Solaris...

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH 6/8] fortran: use grep -F instead of fgrep

[Bernhard Reutner-Fischer via Gcc-patches]

On Fri, 24 Jun 2022 15:06:32 +0800
Xi Ruoyao via Gcc-patches  wrote:

> fgrep has been deprecated in favor of grep -F for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of fgrep is used.
> Stop using fgrep so we won't see the warning.
> 
> gcc/ChangeLog:
> 
>   * fortran/Make-lang.in: Use grep -F instead of fgrep.
> ---
>  gcc/fortran/Make-lang.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/fortran/Make-lang.in b/gcc/fortran/Make-lang.in
> index 1cb47cb1a52..51279b03aad 100644
> --- a/gcc/fortran/Make-lang.in
> +++ b/gcc/fortran/Make-lang.in
> @@ -278,7 +278,7 @@ $(DESTDIR)$(man1dir)/$(GFORTRAN_INSTALL_NAME)$(man1ext): 
> doc/gfortran.1 \
>   -chmod a-x $@
>  
>  fortran.uninstall:
> - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i 
> debian' >/dev/null 2>&1; then \
> + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i 
> debian' >/dev/null 2>&1; then \
> echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) 
> $(DESTDIR)$(infodir)/gfortran.info"; \
> install-info --delete --info-dir=$(DESTDIR)$(infodir) 
> $(DESTDIR)$(infodir)/gfortran.info || : ; \
>   else : ; fi; \

I'd replace -s >/dev/null 2>&1 with -q while at it.

But why is -F used here in the first place?
I do not see much in debian that can be interpreted as a regex?

thanks,

Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts

[Jonathan Wakely via Gcc-patches]

On Fri, 24 Jun 2022 at 12:08, Xi Ruoyao via Libstdc++
 wrote:
>
> On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> > On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
> >  wrote:
> > >
> > > 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.
> > >
> > > libstdc++-v3/ChangeLog:
> > >
> > > * scripts/extract_symvers.in: Use grep -E instead of egrep.
> > > * libstdc++-v3/scripts/run_doxygen: Likewise.
> >
> > This should be just scripts/run_doxygen here. You can use the git
> > gcc-verify alias to check your changelog format.
> >
> >
> > With that fixed it's OK for trunk and gcc-12 and gcc-11 branches,
> > thanks!
>
> I'll need some rework as Rainer told me "grep -E" may not work on some
> Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
> is exactly for Solaris...

I checked that, and it's not :-)

The egrep uses in extract_symvers.in are for everything *except*
SunOS. For Solaris we use the scripts/extract_symvers.pl script
instead.

Your change might break generation of Doxygen API docs on Solaris, but
maybe we can live with that.

Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts

[Jonathan Wakely via Gcc-patches]

On Fri, 24 Jun 2022 at 12:18, Jonathan Wakely  wrote:
>
> On Fri, 24 Jun 2022 at 12:08, Xi Ruoyao via Libstdc++
>  wrote:
> >
> > On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> > > On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
> > >  wrote:
> > > >
> > > > 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.
> > > >
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > > * scripts/extract_symvers.in: Use grep -E instead of egrep.
> > > > * libstdc++-v3/scripts/run_doxygen: Likewise.
> > >
> > > This should be just scripts/run_doxygen here. You can use the git
> > > gcc-verify alias to check your changelog format.
> > >
> > >
> > > With that fixed it's OK for trunk and gcc-12 and gcc-11 branches,
> > > thanks!
> >
> > I'll need some rework as Rainer told me "grep -E" may not work on some
> > Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
> > is exactly for Solaris...
>
> I checked that, and it's not :-)
>
> The egrep uses in extract_symvers.in are for everything *except*
> SunOS. For Solaris we use the scripts/extract_symvers.pl script
> instead.
>
> Your change might break generation of Doxygen API docs on Solaris, but
> maybe we can live with that.

/usr/xpg4/bin/grep supports the -E flag, so I was going to say that
it's acceptable to require that version in the PATH when generating
the API docs with doxygen. But in fact that script already assumes GNU
grep anyway, using egrep --files-without-match and POSIX grep does not
support --files-without-match, or the short form of that option, -L.

And in fact, neither of the uses of egrep in scripts/run_doxygen
actually needs to use extended regular expressions. Plain ol' grep
with Basic Regular Expressions will work fine:

problematic=`egrep -l '#include <.*h>' [a-z]*.3`
problematic=`egrep --files-without-match '^\.SH SYNOPSIS' [A-Z]*.3`

There are no ERE special characters here, so itcould just use 'grep'
not 'egrep'. And it won't work with Solaris grep anyway.

Re: [PATCH] Enable some features for RTEMS in libstdc++

[Sebastian Huber]

On 23.06.22 13:39, Sebastian Huber wrote:

Remove RTEMS support from crossconfig.m4 since this code is not used due to
"with_newlib" being "yes".

libstdc++-v3/ChangeLog:

* configure: Regnerate.
* configure.ac (newlib, *-rtems*): Enable TLS support for all RTEMS
targets except bfin, lm32, mips, moxie, or1k, and v850.
For all RTEMS targets, define HAVE_ALIGNED_ALLOC, HAVE_AT_QUICK_EXIT,
HAVE_LINK, HAVE_POLL, HAVE_QUICK_EXIT, HAVE_READLINK, HAVE_SETENV,
HAVE_SLEEP, HAVE_SOCKATMARK, HAVE_STRERROR_L, HAVE_SYMLINK,
HAVE_TRUNCATE, and HAVE_USLEEP.
* crossconfig.m4 (*-rtems*): Remove.


Since this patch touches the global configure script and a 
Newlib-specifc part, I guess I need approval from someone.


--
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 3/8] libstdc++: use grep -E instead of egrep in scripts

[Rainer Orth]

Hi Jonathan,

>> > I'll need some rework as Rainer told me "grep -E" may not work on some
>> > Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
>> > is exactly for Solaris...
>>
>> I checked that, and it's not :-)
>>
>> The egrep uses in extract_symvers.in are for everything *except*
>> SunOS. For Solaris we use the scripts/extract_symvers.pl script
>> instead.
>>
>> Your change might break generation of Doxygen API docs on Solaris, but
>> maybe we can live with that.
>
> /usr/xpg4/bin/grep supports the -E flag, so I was going to say that
> it's acceptable to require that version in the PATH when generating
> the API docs with doxygen. But in fact that script already assumes GNU

indeed: for a niche/developer-only use, the bar of tool requirements can
be higher IMO.  Besides, /usr/gnu/bin/grep is there, too (or could be;
both /usr/xpg4/bin/grep and /usr/gnu/bin/grep live in separate packages
that may or may not be installed).

I just want to make the entry barries for normal builds as low as
possible.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

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

[Richard Biener via Gcc-patches]

On Fri, 24 Jun 2022, Richard Sandiford wrote:

> Richard Biener  writes:
> > On Thu, 23 Jun 2022, Richard Sandiford wrote:
> >> 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 

Re: [PATCH 6/8] fortran: use grep -F instead of fgrep

[Xi Ruoyao via Gcc-patches]

On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:

> > -   if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i 
> > debian' >/dev/null 2>&1; then \
> > +   if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i 
> > debian' >/dev/null 2>&1; then \
> >   echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) 
> > $(DESTDIR)$(infodir)/gfortran.info"; \
> >   install-info --delete --info-dir=$(DESTDIR)$(infodir) 
> > $(DESTDIR)$(infodir)/gfortran.info || : ; \
> > else : ; fi; \
> 
> I'd replace -s >/dev/null 2>&1 with -q while at it.
> 
> But why is -F used here in the first place?
> I do not see much in debian that can be interpreted as a regex?

I'm not sure.  It was there since 2004.  Perhaps the author thinks fgrep
may save several CPU cycles :).  I'll just use a plain grep in PATCH v2.

Rainer: do you have some idea about the availability of "-q" on
different hosts?  If you agree I'll use it instead of -s > /dev/null
too.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH 6/8] fortran: use grep -F instead of fgrep

[Rainer Orth]

Hi Xi,

> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
>
>> > -   if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v
>> > -i debian' >/dev/null 2>&1; then \
>> > +   if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v
>> > -i debian' >/dev/null 2>&1; then \
>> >   echo " install-info --delete --info-dir=$(DESTDIR)$(infodir)
>> > $(DESTDIR)$(infodir)/gfortran.info"; \
>> >   install-info --delete --info-dir=$(DESTDIR)$(infodir)
>> > $(DESTDIR)$(infodir)/gfortran.info || : ; \
>> > else : ; fi; \
>> 
>> I'd replace -s >/dev/null 2>&1 with -q while at it.
>> 
>> But why is -F used here in the first place?
>> I do not see much in debian that can be interpreted as a regex?
>
> I'm not sure.  It was there since 2004.  Perhaps the author thinks fgrep
> may save several CPU cycles :).  I'll just use a plain grep in PATCH v2.
>
> Rainer: do you have some idea about the availability of "-q" on
> different hosts?  If you agree I'll use it instead of -s > /dev/null
> too.

again, the autoconf manual warns agains it, even more so against -s.
That's the first reference for portability issues and shouldn't be
ignored without good reason.

In the GCC and Solaris context, /bin/grep supports both -q and -s in
Solaris 11.3 and 11.4.  It doesn't support -q on Solaris 10, though
(again, no longer relevant for GCC).

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts

[Xi Ruoyao via Gcc-patches]

On Fri, 2022-06-24 at 13:41 +0200, Rainer Orth wrote:
> Hi Jonathan,
> 
> > > > I'll need some rework as Rainer told me "grep -E" may not work on some
> > > > Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
> > > > is exactly for Solaris...
> > > 
> > > I checked that, and it's not :-)
> > > 
> > > The egrep uses in extract_symvers.in are for everything *except*
> > > SunOS. For Solaris we use the scripts/extract_symvers.pl script
> > > instead.

I misread the case statement :(.

> > > Your change might break generation of Doxygen API docs on Solaris, but
> > > maybe we can live with that.
> > 
> > /usr/xpg4/bin/grep supports the -E flag, so I was going to say that
> > it's acceptable to require that version in the PATH when generating
> > the API docs with doxygen. But in fact that script already assumes GNU
> 
> indeed: for a niche/developer-only use, the bar of tool requirements can
> be higher IMO.  Besides, /usr/gnu/bin/grep is there, too (or could be;
> both /usr/xpg4/bin/grep and /usr/gnu/bin/grep live in separate packages
> that may or may not be installed).
> 
> I just want to make the entry barries for normal builds as low as
> possible.

Pushed as r13-1242 with ChangeLog fix, as compatibility-related stuff
"resolved" and this does not depend on other patches in the series.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH 3/8] libstdc++: use grep -E instead of egrep in scripts

[Jonathan Wakely via Gcc-patches]

On Fri, 24 Jun 2022 at 13:37, Xi Ruoyao  wrote:
>
> On Fri, 2022-06-24 at 13:41 +0200, Rainer Orth wrote:
> > Hi Jonathan,
> >
> > > > > I'll need some rework as Rainer told me "grep -E" may not work on some
> > > > > Solaris systems w/o GNU grep, and the code snippet in 
> > > > > extract_symvers.in
> > > > > is exactly for Solaris...
> > > >
> > > > I checked that, and it's not :-)
> > > >
> > > > The egrep uses in extract_symvers.in are for everything *except*
> > > > SunOS. For Solaris we use the scripts/extract_symvers.pl script
> > > > instead.
>
> I misread the case statement :(.
>
> > > > Your change might break generation of Doxygen API docs on Solaris, but
> > > > maybe we can live with that.
> > >
> > > /usr/xpg4/bin/grep supports the -E flag, so I was going to say that
> > > it's acceptable to require that version in the PATH when generating
> > > the API docs with doxygen. But in fact that script already assumes GNU
> >
> > indeed: for a niche/developer-only use, the bar of tool requirements can
> > be higher IMO.  Besides, /usr/gnu/bin/grep is there, too (or could be;
> > both /usr/xpg4/bin/grep and /usr/gnu/bin/grep live in separate packages
> > that may or may not be installed).
> >
> > I just want to make the entry barries for normal builds as low as
> > possible.
>
> Pushed as r13-1242 with ChangeLog fix, as compatibility-related stuff
> "resolved" and this does not depend on other patches in the series.

Great, thanks!

[PATCH] middle-end/106070 - bogus cond-expr folding

[Richard Biener via Gcc-patches]

The following fixes up r13-469-g9a53101caadae1b5 by properly
implementing what operand_equal_for_comparison_p did.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

2022-06-24  Richard Biener  

PR middle-end/106070
* match.pd (a != b ? a : b): Fix translation of
operand_equal_for_comparison_p.

* gcc.dg/torture/pr106070.c: New testcase.
---
 gcc/match.pd| 11 +++
 gcc/testsuite/gcc.dg/torture/pr106070.c | 20 
 2 files changed, 27 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr106070.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 4a570894b2e..e486b4be282 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4574,12 +4574,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (cond (cmp:c (nop_convert1?@c0 @0) (nop_convert2?@c1 @1))
 (convert3? @0) (convert4? @1))
   (if (!HONOR_SIGNED_ZEROS (type)
-   && ((INTEGRAL_TYPE_P (type)
-   /* Allow widening conversions of the data.  */
+   && (/* Allow widening conversions of the compare operands as data.  */
+  (INTEGRAL_TYPE_P (type)
+   && types_match (TREE_TYPE (@c0), TREE_TYPE (@0))
+   && types_match (TREE_TYPE (@c1), TREE_TYPE (@1))
&& TYPE_PRECISION (TREE_TYPE (@0)) <= TYPE_PRECISION (type)
&& TYPE_PRECISION (TREE_TYPE (@1)) <= TYPE_PRECISION (type))
-  || (tree_nop_conversion_p (type, TREE_TYPE (@0))
-  && tree_nop_conversion_p (type, TREE_TYPE (@1)
+  /* Or sign conversions for the comparison.  */
+  || (types_match (type, TREE_TYPE (@0))
+  && types_match (type, TREE_TYPE (@1)
(switch
 (if (cmp == EQ_EXPR)
  (if (VECTOR_TYPE_P (type))
diff --git a/gcc/testsuite/gcc.dg/torture/pr106070.c 
b/gcc/testsuite/gcc.dg/torture/pr106070.c
new file mode 100644
index 000..c36534f8a50
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr106070.c
@@ -0,0 +1,20 @@
+/* { dg-do run } */
+
+unsigned int var_2 = 1;
+int var_4 = -1;
+int var_10 = 4;
+unsigned long arr_252;
+void __attribute__((noipa)) test() {
+  for (int a = 0; a < var_10; a += 2)
+arr_252 = var_2 != (int)var_4 ? (unsigned long)var_4 : (unsigned 
long)var_2;
+}
+
+void test();
+
+int main()
+{
+  test();
+  if (arr_252 != 0x)
+__builtin_abort();
+  return 0;
+}
-- 
2.35.3

Re: [PATCH] Enable some features for RTEMS in libstdc++

[Jeff Law via Gcc-patches]

On 6/24/2022 5:38 AM, Sebastian Huber wrote:

On 23.06.22 13:39, Sebastian Huber wrote:
Remove RTEMS support from crossconfig.m4 since this code is not used 
due to

"with_newlib" being "yes".

libstdc++-v3/ChangeLog:

* configure: Regnerate.
* configure.ac (newlib, *-rtems*): Enable TLS support for all RTEMS
targets except bfin, lm32, mips, moxie, or1k, and v850.
For all RTEMS targets, define HAVE_ALIGNED_ALLOC, 
HAVE_AT_QUICK_EXIT,

HAVE_LINK, HAVE_POLL, HAVE_QUICK_EXIT, HAVE_READLINK, HAVE_SETENV,
HAVE_SLEEP, HAVE_SOCKATMARK, HAVE_STRERROR_L, HAVE_SYMLINK,
HAVE_TRUNCATE, and HAVE_USLEEP.
* crossconfig.m4 (*-rtems*): Remove.


Since this patch touches the global configure script and a 
Newlib-specifc part, I guess I need approval from someone.
Not really.  It's just hitting the rtems parts of those files which 
we've generally considered part of the port.


Or to put it another way, who is likely in a better position to know if 
this is correct, you or someone like myself? :-)


Jeff

Re: [PATCH 6/8] fortran: use grep -F instead of fgrep

[Thomas Koenig via Gcc-patches]

Hi,


On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:


-   if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' 
>/dev/null 2>&1; then \
+   if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian' 
>/dev/null 2>&1; then \
   echo " install-info --delete --info-dir=$(DESTDIR)$(infodir) 
$(DESTDIR)$(infodir)/gfortran.info"; \
   install-info --delete --info-dir=$(DESTDIR)$(infodir) 
$(DESTDIR)$(infodir)/gfortran.info || : ; \
 else : ; fi; \


I'd replace -s >/dev/null 2>&1 with -q while at it.

But why is -F used here in the first place?
I do not see much in debian that can be interpreted as a regex?


I'm not sure.  It was there since 2004.  Perhaps the author thinks fgrep
may save several CPU cycles :).  I'll just use a plain grep in PATCH v2.

Rainer: do you have some idea about the availability of "-q" on
different hosts?  If you agree I'll use it instead of -s > /dev/null
too.


Is there any particular reason why we should not use the result of
AC_PROG_FGREP ?  AC_PROG_GREP should also work.

Re: Add fnspec attributes to cxa_* functions

[Jason Merrill via Gcc-patches]

On 6/23/22 09:59, Jan Hubicka via Gcc-patches wrote:

Note that your email subject line is missing "[PATCH]" and a component 
tag like "c++:".



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.


Makes sense.


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),


It might be helpful to refer to attr_fnspec or attr-fnspec.h, since 
that's where I found the documentation for that string?  OK either way.



+   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",

Re: [PATCH RFA] ubsan: do return check with -fsanitize=unreachable

[Jason Merrill via Gcc-patches]

On 6/22/22 00:04, Jason Merrill wrote:

On 6/20/22 16:16, Jason Merrill wrote:

On 6/20/22 07:05, Jakub Jelinek wrote:

On Fri, Jun 17, 2022 at 05:20:02PM -0400, Jason Merrill wrote:
Related to PR104642, the current situation where we get less return 
checking
with just -fsanitize=unreachable than no sanitize flags seems 
undesirable; I

propose that we do return checking when -fsanitize=unreachable.


__builtin_unreachable itself (unless turned into trap or
__ubsan_handle_builtin_unreachable) is not any kind of return 
checking, it

is just an optimization.


Yes, but I'm talking about "when -fsanitize=unreachable".

Looks like clang just traps on missing return if not 
-fsanitize=return, but

the approach in this patch seems more helpful to me if we're already
sanitizing other should-be-unreachable code.

I'm assuming that the difference in treatment of 
SANITIZE_UNREACHABLE and

SANITIZE_RETURN with regard to loop optimization is deliberate.


return and unreachable are separate sanitizers and such silent one way
implication can have quite unexpected consequences, especially with
-fsanitize-trap=.
Say with -fsanitize=unreachable -fsanitize-trap=unreachable, both 
current
trunk and clang will link without -lubsan, because the only enabled 
UBSan

sanitizers use __builtin_trap () which doesn't need library.
With -fsanitize=unreachable silently meaning 
-fsanitize=unreachable,return

the above would link in -lubsan, because while SANITIZE_UNREACHABLE uses
__builtin_trap, SANITIZE_RETURN doesn't.
Similarly, one has no_sanitize attribute, one could in certain function
__attribute__((no_sanitize ("unreachable"))) and because on the command
line using -fsanitize=unreachable assume other sanitizers aren't 
enabled,

but the silent addition of return sanitizer would break that.


Ah, true.  How about this approach instead?


Or, this approach relies on the PR104642 patch, and just fixes the line 
number issue.  This is less clear about the problem than using the 
return ubsan library function, but avoids using one entry point to 
implement the other sanitizer, if that's important.


Ping?

[PATCH] PR tree-optimization/94026: Simplify (X>>8)&6 != 0 as X&1536 != 0.

[Roger Sayle]

This patch implements the missed optimization described in PR 94026,
where a the shift can be eliminated from the sequence of a shift,
followed by a bit-wise AND followed by an equality/inequality test.
Specifically, ((X << C1) & C2) cmp C3 into (X & (C2 >> C1)) cmp (C3 >> C1)
and likewise ((X >> C1) & C2) cmp C3 into (X & (C2 << C1)) cmp (C3 << C1)
where cmp is == or !=, and C1, C2 and C3 are integer constants.
The example in the subject line is taken from the hot function
self_atari from the Go program Leela (in SPEC CPU 2017).

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, OK for mainline?


2022-06-24  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/94026
* match.pd (((X << C1) & C2) eq/ne C3): New simplification.
(((X >> C1) & C2) eq/ne C3): Likewise.

gcc/testsuite/ChangeLog
PR tree-optimization/94026
* gcc.dg/pr94026.c: New test case.


Thanks in advance,
Roger
--

diff --git a/gcc/match.pd b/gcc/match.pd
index a63b649..5089b07 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3559,6 +3559,29 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 && wi::lshift (wi::to_wide (@0), cand) == wi::to_wide (@2))
  (cmp @1 { build_int_cst (TREE_TYPE (@1), cand); }))
 
+/* Fold ((X << C1) & C2) cmp C3 into (X & (C2 >> C1)) cmp (C3 >> C1)
+   ((X >> C1) & C2) cmp C3 into (X & (C2 << C1)) cmp (C3 << C1).  */
+(for cmp (ne eq)
+ (simplify
+  (cmp (bit_and:s (lshift:s @0 INTEGER_CST@1) INTEGER_CST@2) INTEGER_CST@3)
+  (if (tree_fits_shwi_p (@1)
+   && tree_to_shwi (@1) > 0
+   && tree_to_shwi (@1) < TYPE_PRECISION (TREE_TYPE (@0))
+   && tree_to_shwi (@1) <= wi::ctz (wi::to_wide (@3)))
+   (with { wide_int c1 = wi::to_wide (@1);
+  wide_int c2 = wi::lrshift (wi::to_wide (@2), c1);
+  wide_int c3 = wi::lrshift (wi::to_wide (@3), c1); }
+(cmp (bit_and @0 { wide_int_to_tree (TREE_TYPE (@0), c2); })
+{ wide_int_to_tree (TREE_TYPE (@0), c3); }
+ (simplify
+  (cmp (bit_and:s (rshift:s @0 INTEGER_CST@1) INTEGER_CST@2) INTEGER_CST@3)
+  (if (tree_fits_shwi_p (@1)
+   && tree_to_shwi (@1) > 0
+   && tree_to_shwi (@1) < TYPE_PRECISION (TREE_TYPE (@0))
+   && tree_to_shwi (@1) <= wi::clz (wi::to_wide (@2))
+   && tree_to_shwi (@1) <= wi::clz (wi::to_wide (@3)))
+   (cmp (bit_and @0 (lshift @2 @1)) (lshift @3 @1)
+
 /* Fold (X << C1) & C2 into (X << C1) & (C2 | ((1 << C1) - 1))
 (X >> C1) & C2 into (X >> C1) & (C2 | ~((type) -1 >> C1))
if the new mask might be further optimized.  */
diff --git a/gcc/testsuite/gcc.dg/pr94026.c b/gcc/testsuite/gcc.dg/pr94026.c
new file mode 100644
index 000..489b978
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr94026.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+int f1(int x) { return ((x >> 8) & 6) != 0; }
+int f2(int x) { return ((x << 2) & 24) != 0; }
+int f3(unsigned x) { return ((x << 2) & 15) != 0; }
+int f4(unsigned x) { return ((x >> 2) & 14) != 0; }
+
+int fifth (int c)
+{
+int a = (c >> 8) & 7;
+
+if (a >= 2) {
+   return 1;
+} else {
+   return 0;
+}
+}
+/* { dg-final { scan-tree-dump-not " << " "optimized" } } */
+/* { dg-final { scan-tree-dump-not " >> " "optimized" } } */
+

[PATCH] libgfortran: Avoid using libquadmath powerpc64le fixes

[Jakub Jelinek via Gcc-patches]

Hi!

Testing this on powerpc64le-linux revealed some problems
with the patch when gcc is configured against glibc 2.26 through 2.31.

Here is incremental patch (against the v2 patch) that fixes it.

Built and tested on powerpc64le-linux with glibc 2.28, ok for trunk?

2022-06-24  Jakub Jelinek  

* kinds-override.h (GFC_REAL_17, GFC_COMPLEX_17, GFC_REAL_17_HUGE,
GFC_REAL_17_LITERAL_SUFFIX,GFC_REAL_17_LITERAL): Define differently
if HAVE__FLOAT128 is defined.
* intrinsics/erfc_scaled.c (_THRESH, _M_2_SQRTPI, _ERFC, _EXP):
Likewise.
* m4/mtype.m4: Use f128 suffix for GFC_REAL_17 if not POWER_IEEE128
and HAVE__FLOAT128 is defined.
* io/read.c (convert_real): Handle HAVE__FLOAT128 differently if
POWER_IEEE128 is not defined.
* io/transfer128.c (tmp1, tmp2): Likewise.
* io/write_float.def (gfor_strfromf128): Define even for GFC_REAL_17
if POWERPC_IEEE128 isn't defined and HAVE__FLOAT128 is.
(DTOA2Q, FDTOA2Q): Define differently for GFC_REAL_17 if
POWERPC_IEEE128 isn't defined and HAVE__FLOAT128 is.
* generated/norm2_r17.c: Regenerated.
* generated/bessel_r17.c: Regenerated.

--- libgfortran/kinds-override.h.jj 2022-06-22 12:40:05.170224299 +0200
+++ libgfortran/kinds-override.h2022-06-24 14:19:00.886823630 +0200
@@ -34,13 +34,24 @@ see the files COPYING3 and COPYING.RUNTI
 
 /* Keep these conditions on one line so grep can filter it out.  */
 #if defined(__powerpc64__)  && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__  && 
__SIZEOF_LONG_DOUBLE__ == 16
+#ifdef HAVE__FLOAT128
+typedef _Float128 GFC_REAL_17;
+typedef _Complex _Float128 GFC_COMPLEX_17;
+#else
 typedef __float128 GFC_REAL_17;
 typedef _Complex float __attribute__((mode(KC))) GFC_COMPLEX_17;
+#endif
 #define HAVE_GFC_REAL_17
 #define HAVE_GFC_COMPLEX_17
+#ifdef HAVE__FLOAT128
+#define GFC_REAL_17_HUGE 1.18973149535723176508575932662800702e4932f128
+#define GFC_REAL_17_LITERAL_SUFFIX f128
+#define GFC_REAL_17_LITERAL(X) (X ## f128)
+#else
 #define GFC_REAL_17_HUGE 1.18973149535723176508575932662800702e4932q
 #define GFC_REAL_17_LITERAL_SUFFIX q
 #define GFC_REAL_17_LITERAL(X) (X ## q)
+#endif
 #define GFC_REAL_17_DIGITS 113
 #define GFC_REAL_17_RADIX 2
 #endif
--- libgfortran/intrinsics/erfc_scaled.c.jj 2022-06-24 07:38:55.640826314 
-0400
+++ libgfortran/intrinsics/erfc_scaled.c2022-06-24 09:10:05.311263353 
-0400
@@ -147,12 +147,15 @@ ERFC_SCALED(16)
 /* For quadruple-precision, netlib's implementation is
not accurate enough.  We provide another one.  */
 
-# define _THRESH -106.566990228185312813205074546585730Q
-# define _M_2_SQRTPI M_2_SQRTPIq
+# define _THRESH GFC_REAL_17_LITERAL(-106.566990228185312813205074546585730)
+# define _M_2_SQRTPI GFC_REAL_17_LITERAL(M_2_SQRTPI)
 # define _INF __builtin_inff128()
 # ifdef POWER_IEEE128
 #  define _ERFC(x) __erfcieee128(x)
 #  define _EXP(x) __expieee128(x)
+# elif defined(HAVE__FLOAT128)
+#  define _ERFC(x) erfcf128(x)
+#  define _EXP(x) expf128(x)
 # else
 #  define _ERFC(x) erfcq(x)
 #  define _EXP(x) expq(x)
--- libgfortran/m4/mtype.m4.jj  2022-06-22 13:52:56.987824469 +0200
+++ libgfortran/m4/mtype.m4 2022-06-24 14:21:40.435769659 +0200
@@ -15,6 +15,8 @@ ifelse(kind,17,`1 /* FIXME: figure this
 define(mathfunc_macro,`ifelse(kind,17,dnl
 `#if defined(POWER_IEEE128)
 #define MATHFUNC(funcname) __ ## funcname ## ieee128
+#elif defined(HAVE__FLOAT128)
+#define MATHFUNC(funcname) funcname ## f128
 #else
 #define MATHFUNC(funcname) funcname ## q
 #endif',dnl
--- libgfortran/io/read.c.jj2022-06-22 14:13:35.351567588 +0200
+++ libgfortran/io/read.c   2022-06-24 14:29:43.19939 +0200
@@ -203,6 +203,8 @@ convert_real (st_parameter_dt *dtp, void
 case 17:
 # if defined(POWER_IEEE128)
   *((GFC_REAL_17*) dest) = __strtoieee128 (buffer, &endptr);
+# elif defined(HAVE__FLOAT128)
+  *((GFC_REAL_17*) dest) = strtof128 (buffer, &endptr);
 # else
   *((GFC_REAL_17*) dest) = __qmath_(strtoflt128) (buffer, &endptr);
 # endif
--- libgfortran/io/transfer128.c.jj 2022-06-22 13:20:31.657252114 +0200
+++ libgfortran/io/transfer128.c2022-06-24 14:31:18.616329211 +0200
@@ -67,7 +67,8 @@ export_proto(transfer_complex128_write);
that there is a non-weakref dependence if the quadmath functions
are used. That avoids segfault when libquadmath is statically linked.  */
 # ifndef GFC_REAL_16_IS__FLOAT128
-#  if !defined(HAVE_GFC_REAL_17) || !defined(POWER_IEEE128)
+#  if !defined(HAVE_GFC_REAL_17) \
+  || (!defined(POWER_IEEE128) && !defined(HAVE__FLOAT128))
 static void __attribute__((used)) *tmp1 = strtoflt128;
 static void __attribute__((used)) *tmp2 = quadmath_snprintf;
 #  endif
--- libgfortran/io/write_float.def.jj   2022-06-24 07:38:55.640826314 -0400
+++ libgfortran/io/write_float.def  2022-06-24 09:13:48.653519940 -0400
@@ -837,7 +837,9 @@ snprintf (buffer, size, "%+-#.*e", (prec
 #define DTOA2L(prec,val) \
 snprint

Re: [PATCH 5/8] intl: stop using fgrep for exgettext

[Joseph Myers]

On Fri, 24 Jun 2022, Xi Ruoyao via Gcc-patches wrote:

> fgrep has been deprecated in favor of grep -F for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of fgrep is used.
> And, the fgrep command in exgettext is no longer useful after we
> migrated from SVN to Git.  Remove the fgrep command so we won't see the
> warning.
> 
> gcc/ChangeLog:
> 
>   * po/exgettext: Remove unneeded fgrep command.

OK.

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

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

[Joseph Myers]

On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote:

> Though I do find that -E/-F have been part of the POSIX standard since
> at least 2004 which is interesting.

grep -E and -F are already defined, and egrep and fgrep marked as 
obsolescent, in the 1992/1993 edition of POSIX.2.

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

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

[Iain Sandoe via Gcc-patches]

> On 24 Jun 2022, at 17:09, Joseph Myers  wrote:
> 
> On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote:
> 
>> Though I do find that -E/-F have been part of the POSIX standard since
>> at least 2004 which is interesting.
> 
> grep -E and -F are already defined, and egrep and fgrep marked as 
> obsolescent, in the 1992/1993 edition of POSIX.2.

FWIW, grep -E/F is supported by the oldest Darwin versions I care about
so, I have no objections to these changes.

Iain

Re: [PATCH] Improve reg_or_subregno to return INVALID_REGNUM when the subreg of memory is processed.

[Segher Boessenkool]

Hi!

Please Cc: me on all combine patches, so that I will not miss any.

On Thu, Jun 23, 2022 at 11:39:16AM +0800, liuhongt via Gcc-patches wrote:
>   This is follow-up to [1], return INVALID_REGNUM instead of gcc_assert,
>   also adjust some conditions guarded for reg_or_subregno.
> 
> >OK, but I think that reg_or_subregno should be improved to return
> >INVALID_REGNUM when the subreg of memory is processed.

>   * combine.cc (try_combine): Replace condition with regno !=
>   INVALID_REGNUM.

Not okay.

> --- a/gcc/combine.cc
> +++ b/gcc/combine.cc
> @@ -4245,12 +4245,9 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, 
> rtx_insn *i0,
>if (GET_CODE (x) == PARALLEL)
>   x = XVECEXP (newi2pat, 0, 0);
>  
> -  if (REG_P (SET_DEST (x))
> -   || (GET_CODE (SET_DEST (x)) == SUBREG
> -   && REG_P (SUBREG_REG (SET_DEST (x)
> +  unsigned int regno = reg_or_subregno (SET_DEST (x));
> +  if (regno != INVALID_REGNUM)
>   {
> -   unsigned int regno = reg_or_subregno (SET_DEST (x));

This is at best obfuscation :-(

Subregs of non-reg have been deprecated for ages, and will be completely
phased out soon, and this patch goes in the wrong direction.  But also,
this change is obfuscation, in multiple ways.  Firstly, using a regno to
mean something is not a register at all, but worse, you use a number
that is a valid regnum (but too big to happen in practice of course) to
indicate this.  While in other places the negative -1 is used, which is
a bit more obvious.

> && reg_or_subregno (in) < FIRST_PSEUDO_REGISTER)

... and then statements like this will implicitly do something for
subregs of memory, which is totally not obvious.

The combine pass still has explicit support for subregs of memory, and
the support for subregs is one of the more error-prone and non-obvious
parts of combine in the first place.  Anything that makes things harder
here will not be approved.


Segher

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

[Segher Boessenkool]

Hi!

On Fri, Jun 24, 2022 at 09:03:59AM +0800, Kewen.Lin wrote:
> on 2022/6/24 03:06, Segher Boessenkool wrote:
> > 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:

Your proposed commit message says "MMA built-in function".  It is not
an MMA builtin, or rather, it should not be.

> >> +  /* 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.

Opaque modes are a generic thing, not an rs6000 thing.  It is important
not to conflate completely different things that just happened to
coincide some months ago (but not anymore right now even!)

> 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.

Yup.  This can take some time of course, but in the mean time we should
stop pretending the status quo is correct.

> > So this needs some bigger surgery.
> 
> Yes, Peter may have more comments on this.

Yes.  Can you do a patch that just fixes this PR103353, without adding
more misleading comments?  :-)


Segher

[committed] analyzer: whitespace cleanups

[David Malcolm via Gcc-patches]

Clean up whitespace in preparation for a follow-up patch.

No functional change intended.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1249-g3752e21d8c180b.

gcc/analyzer/ChangeLog:
* call-string.cc (call_string::calc_recursion_depth): Whitespace
cleanups.
(call_string::cmp): Likewise.
(call_string::get_caller_node): Likewise.
(call_string::validate): Likewise.
* engine.cc (dynamic_call_info_t::add_events_to_path): Likewise.
(exploded_graph::get_per_function_data): Likewise.
(exploded_graph::maybe_create_dynamic_call): Likewise.
(exploded_graph::maybe_create_dynamic_call): Likewise.
(exploded_graph::process_node): Likewise.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/call-string.cc |  18 ++-
 gcc/analyzer/engine.cc  | 253 ++--
 2 files changed, 135 insertions(+), 136 deletions(-)

diff --git a/gcc/analyzer/call-string.cc b/gcc/analyzer/call-string.cc
index df55e03d591..2ccd3ccd6fb 100644
--- a/gcc/analyzer/call-string.cc
+++ b/gcc/analyzer/call-string.cc
@@ -206,7 +206,7 @@ call_string::calc_recursion_depth () const
 {
   if (m_elements.is_empty ())
 return 0;
-  const call_string::element_t top_return_sedge 
+  const call_string::element_t top_return_sedge
 = m_elements[m_elements.length () - 1];
 
   int result = 0;
@@ -247,12 +247,12 @@ call_string::cmp (const call_string &a,
   /* Otherwise, compare the node pairs.  */
   const call_string::element_t a_node_pair = a[i];
   const call_string::element_t b_node_pair = b[i];
-  int src_cmp 
-   = a_node_pair.m_callee->m_index - b_node_pair.m_callee->m_index;
+  int src_cmp
+   = a_node_pair.m_callee->m_index - b_node_pair.m_callee->m_index;
   if (src_cmp)
return src_cmp;
-  int dest_cmp 
-   = a_node_pair.m_caller->m_index - b_node_pair.m_caller->m_index;
+  int dest_cmp
+   = a_node_pair.m_caller->m_index - b_node_pair.m_caller->m_index;
   if (dest_cmp)
return dest_cmp;
   i++;
@@ -272,7 +272,7 @@ call_string::get_callee_node () const
 
 /* Return the pointer to caller of the topmost call in the stack,
or NULL if stack is empty.  */
-const supernode * 
+const supernode *
 call_string::get_caller_node () const
 {
   if(m_elements.is_empty ())
@@ -295,10 +295,8 @@ call_string::validate () const
   int i;
   FOR_EACH_VEC_ELT (m_elements, i, e)
 if (i > 0)
-{
-  gcc_assert (e->get_caller_function () == 
- m_elements[i - 1].get_callee_function ());
-}
+  gcc_assert (e->get_caller_function () ==
+ m_elements[i - 1].get_callee_function ());
 }
 
 #endif /* #if ENABLE_ANALYZER */
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 7237cc1a1ca..51dfe298230 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -1853,18 +1853,19 @@ dynamic_call_info_t::add_events_to_path (checker_path 
*emission_path,
   const int dest_stack_depth = dest_point.get_stack_depth ();
 
   if (m_is_returning_call)
-emission_path->add_event (new return_event (eedge, (m_dynamic_call
-   ? 
m_dynamic_call->location
-   : UNKNOWN_LOCATION),
- dest_point.get_fndecl (),
- dest_stack_depth));
+emission_path->add_event (new return_event (eedge,
+   (m_dynamic_call
+? m_dynamic_call->location
+: UNKNOWN_LOCATION),
+   dest_point.get_fndecl (),
+   dest_stack_depth));
   else
-emission_path->add_event (new call_event (eedge, (m_dynamic_call
- ? m_dynamic_call->location
- : UNKNOWN_LOCATION),
- src_point.get_fndecl (),
- src_stack_depth));
-
+emission_path->add_event (new call_event (eedge,
+ (m_dynamic_call
+  ? m_dynamic_call->location
+  : UNKNOWN_LOCATION),
+ src_point.get_fndecl (),
+ src_stack_depth));
 }
 
 /* class rewind_info_t : public custom_edge_info.  */
@@ -2825,7 +2826,7 @@ per_function_data *
 exploded_graph::get_per_function_data (function *fun) const
 {
   if (per_function_data **slot
-= const_cast  (m_per_function_data).get (fun))
+   = const_cast  (m_per_function_data).get (fun))
 return *slot;
 
   return NULL;
@@ -3537,7 +3538,7 @@ state_change_requires_new_enode_p (co

[committed] analyzer: consolidate call_string instances

[David Malcolm via Gcc-patches]

ana::call_string is a wrapper around an auto_vec of callsites, leading
to non-trivial copying when copying around call_string instances, e.g.
in ana::program_point.

This patch consolidates call_string instances within the
region_model_manager: it now owns the root/empty call_string, and
each call_string instance tracks its children, lazily creating them on
demand, so that the call_string instances form a tree-like hierarchy in
memory.  Doing this requires passing the region_model_manager to the
various program_point factory methods, so that they can get at the root
call_string.

Instances of call_string become immutable (apart from their internal
cache for looking up their children); operations that previously
modified them now return the call_string for the result of the
operation.

I wasn't able to observe any performance impact of this, but it
simplifies call_string and program_point management, and thus I hope
will make it easier to improve call summarization.  In particular,
region_model_manager::log_stats will now print a hierarchical dump of
all the call_string instances used in the analysis (in -fdump-analyzer
and -fdump-analyzer-stderr).

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1250-gbb8e93eb1acae3.

gcc/analyzer/ChangeLog:
* call-string.cc: Add includes of "analyzer/analyzer.h"
and "analyzer/analyzer-logging.h".
(call_string::call_string): Delete copy ctor.
(call_string::operator=): Delete.
(call_string::operator==): Delete.
(call_string::hash): Delete.
(call_string::push_call): Make const, returning the resulting
call_string.
(call_string::pop): Delete.
(call_string::cmp_ptr_ptr): New.
(call_string::validate): Assert that m_parent is non-NULL, or
m_elements is empty.
(call_string::call_string): Move default ctor here from
call-string.h and reimplement.  Add ctor taking a parent
and an element.
(call_string::~call_string): New.
(call_string::recursive_log): New.
* call-string.h (call_string::call_string): Move default ctor's
defn to call-string.cc.  Delete copy ctor.  Add ctor taking a
parent and an element.
(call_string::operator=): Delete.
(call_string::operator==): Delete.
(call_string::hash): Delete.
(call_string::push_call): Make const, returning the resulting
call_string.
(call_string::pop): Delete decl.
(call_string::get_parent): New.
(call_string::cmp_ptr_ptr): New decl.
(call_string::get_top_of_stack): New.
(struct call_string::hashmap_traits_t): New.
(class call_string): Add friend class region_model_manager.  Add
DISABLE_COPY_AND_ASSIGN.
(call_string::~call_string): New decl.
(call_string::recursive_log): New decl.
(call_string::m_parent): New field.
(call_string::m_children): New field.
* constraint-manager.cc (selftest::test_many_constants): Pass
model manager to program_point::origin.
* engine.cc (exploded_graph::exploded_graph): Likewise.
(exploded_graph::add_function_entry): Likewise for
program_point::from_function_entry.
(add_tainted_args_callback): Likewise.
(exploded_graph::maybe_process_run_of_before_supernode_enodes):
Update for change to program_point.get_call_string.
(exploded_graph::process_node): Likewise.
(class function_call_string_cluster): Convert m_cs from a
call_string to a const call_string &.
(struct function_call_string): Likewise.
(pod_hash_traits::hash): Use pointer_hash
for m_cs.
(pod_hash_traits::equal): Update for change
to m_cs.
(root_cluster::add_node): Update for change to
function_call_string.
(viz_callgraph_node::dump_dot): Update for change to call_string.
* exploded-graph.h (per_call_string_data::m_key): Convert to a
reference.
(struct eg_call_string_hash_map_traits): Delete.
(exploded_graph::call_string_data_map_t): Remove traits class.
* program-point.cc: Move include of "analyzer/call-string.h" to
after "analyzer/analyzer-logging.h".
(program_point::print): Update for conversion of m_call_string to
a pointer.
(program_point::to_json): Likewise.
(program_point::push_to_call_stack): Update for immutability of
call strings.
(program_point::pop_from_call_stack): Likewise.
(program_point::hash): Use pointer hashing for m_call_string.
(program_point::get_function_at_depth): Update for change to
m_call_string.
(program_point::validate): Update for changes to call_string.
(program_point::on_edge): Likewise.
(program_point::origin): Move here from call-string.h.  Add
region_model_manager param and use it to get empty call string.

Re: kernel sparse annotations vs. compiler attributes and debug_annotate_{type, decl} WAS: Re: [PATCH 0/9] Add debug_annotate attributes

[Yonghong Song via Gcc-patches]

On 6/21/22 9:12 AM, Jose E. Marchesi wrote:



On 6/17/22 10:18 AM, Jose E. Marchesi wrote:

Hi Yonghong.


On 6/15/22 1:57 PM, David Faust wrote:


On 6/14/22 22:53, Yonghong Song wrote:



On 6/7/22 2:43 PM, David Faust wrote:

Hello,

This patch series adds support for:

- Two new C-language-level attributes that allow to associate (to "annotate" or
  to "tag") particular declarations and types with arbitrary strings. As
  explained below, this is intended to be used to, for example, characterize
  certain pointer types.

- The conveyance of that information in the DWARF output in the form of a new
  DIE: DW_TAG_GNU_annotation.

- The conveyance of that information in the BTF output in the form of two new
  kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG.

All of these facilities are being added to the eBPF ecosystem, and support for
them exists in some form in LLVM.

Purpose
===

1)  Addition of C-family language constructs (attributes) to specify free-text
tags on certain language elements, such as struct fields.

The purpose of these annotations is to provide additional information 
about
types, variables, and function parameters of interest to the kernel. A
driving use case is to tag pointer types within the linux kernel and 
eBPF
programs with additional semantic information, such as '__user' or 
'__rcu'.

For example, consider the linux kernel function do_execve with the
following declaration:

  static int do_execve(struct filename *filename,
 const char __user *const __user *__argv,
 const char __user *const __user *__envp);

Here, __user could be defined with these annotations to record semantic
information about the pointer parameters (e.g., they are user-provided) 
in
DWARF and BTF information. Other kernel facilites such as the eBPF 
verifier
can read the tags and make use of the information.

2)  Conveying the tags in the generated DWARF debug info.

The main motivation for emitting the tags in DWARF is that the Linux 
kernel
generates its BTF information via pahole, using DWARF as a source:

++  BTF  BTF   +--+
| pahole |---> vmlinux.btf --->| verifier |
++ +--+
^^
||
  DWARF |BTF |
||
 vmlinux  +-+
 module1.ko   | BPF program |
 module2.ko   +-+
   ...

This is because:

a)  Unlike GCC, LLVM will only generate BTF for BPF programs.

b)  GCC can generate BTF for whatever target with -gbtf, but there is no
support for linking/deduplicating BTF in the linker.

In the scenario above, the verifier needs access to the pointer tags of
both the kernel types/declarations (conveyed in the DWARF and translated
to BTF by pahole) and those of the BPF program (available directly in 
BTF).

Another motivation for having the tag information in DWARF, unrelated to
BPF and BTF, is that the drgn project (another DWARF consumer) also 
wants
to benefit from these tags in order to differentiate between different
kinds of pointers in the kernel.

3)  Conveying the tags in the generated BTF debug info.

This is easy: the main purpose of having this info in BTF is for the
compiled eBPF programs. The kernel verifier can then access the tags
of pointers used by the eBPF programs.


For more information about these tags and the motivation behind them, please
refer to the following linux kernel discussions:

  https://lore.kernel.org/bpf/20210914223004.244411-1-...@fb.com/
  https://lore.kernel.org/bpf/20211012164838.3345699-1-...@fb.com/
  https://lore.kernel.org/bpf/2022012604.1504583-1-...@fb.com/


Implementation Overview
===

To enable these annotations, two new C language attributes are added:
__attribute__((debug_annotate_decl("foo"))) and
__attribute__((debug_annotate_type("bar"))). Both attributes accept a single
arbitrary string constant argument, which will be recorded in the generated
DWARF and/or BTF debug information. They have no effect on code generation.

Note that we are not using the same attribute names as LLVM (btf_decl_tag and
btf_type_tag, respectively). While these attributes are functionally very
similar, they have grown beyond purely BTF-specific uses, so inclusion of "btf"
in the attribute name seems misleading.

DWARF support is enabled via a new DW_TAG_GNU_annotation. When generating DWARF,
dec

PING^2 Re: [PATCH 02/10] Add 'final' and 'override' on dom_walker vfunc impls

[David Malcolm via Gcc-patches]

I'd like to ping this patch again:
  https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595436.html

OK for trunk?

Thanks
Dave
 
On Mon, 2022-06-13 at 14:23 -0400, David Malcolm wrote:
> Ping for this patch:
>   https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595436.html
> 
> OK for tunk?
> 
> Thanks
> Dave
> 
> On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> > gcc/ChangeLog:
> > * compare-elim.cc: Add "final" and "override" to dom_walker
> > vfunc
> > implementations, removing redundant "virtual" as appropriate.
> > * gimple-ssa-strength-reduction.cc: Likewise.
> > * ipa-prop.cc: Likewise.
> > * rtl-ssa/blocks.cc: Likewise.
> > * tree-into-ssa.cc: Likewise.
> > * tree-ssa-dom.cc: Likewise.
> > * tree-ssa-math-opts.cc: Likewise.
> > * tree-ssa-phiopt.cc: Likewise.
> > * tree-ssa-propagate.cc: Likewise.
> > * tree-ssa-sccvn.cc: Likewise.
> > * tree-ssa-strlen.cc: Likewise.
> > * tree-ssa-uncprop.cc: Likewise.
> > 
> > Signed-off-by: David Malcolm 
> > ---
> >  gcc/compare-elim.cc  |  2 +-
> >  gcc/gimple-ssa-strength-reduction.cc |  2 +-
> >  gcc/ipa-prop.cc  |  4 ++--
> >  gcc/rtl-ssa/blocks.cc    |  4 ++--
> >  gcc/tree-into-ssa.cc | 10 +-
> >  gcc/tree-ssa-dom.cc  |  4 ++--
> >  gcc/tree-ssa-math-opts.cc    |  2 +-
> >  gcc/tree-ssa-phiopt.cc   |  4 ++--
> >  gcc/tree-ssa-propagate.cc    |  4 ++--
> >  gcc/tree-ssa-sccvn.cc    |  4 ++--
> >  gcc/tree-ssa-strlen.cc   |  4 ++--
> >  gcc/tree-ssa-uncprop.cc  |  4 ++--
> >  12 files changed, 24 insertions(+), 24 deletions(-)
> > 
> > diff --git a/gcc/compare-elim.cc b/gcc/compare-elim.cc
> > index e869d9d3249..4a23202f8ff 100644
> > --- a/gcc/compare-elim.cc
> > +++ b/gcc/compare-elim.cc
> > @@ -283,7 +283,7 @@ public:
> >    find_comparison_dom_walker (cdi_direction direction)
> >  : dom_walker (direction) {}
> >  
> > -  virtual edge before_dom_children (basic_block);
> > +  edge before_dom_children (basic_block) final override;
> >  };
> >  
> >  /* Return true if conforming COMPARE with EH_NOTE is redundant with
> > comparison
> > diff --git a/gcc/gimple-ssa-strength-reduction.cc b/gcc/gimple-ssa-
> > strength-reduction.cc
> > index 2b559e96fc8..fb2bb9f4e74 100644
> > --- a/gcc/gimple-ssa-strength-reduction.cc
> > +++ b/gcc/gimple-ssa-strength-reduction.cc
> > @@ -1729,7 +1729,7 @@ class find_candidates_dom_walker : public
> > dom_walker
> >  public:
> >    find_candidates_dom_walker (cdi_direction direction)
> >  : dom_walker (direction) {}
> > -  virtual edge before_dom_children (basic_block);
> > +  edge before_dom_children (basic_block) final override;
> >  };
> >  
> >  /* Find strength-reduction candidates in block BB.  */
> > diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
> > index c6c745f84a0..03f0ba2ec75 100644
> > --- a/gcc/ipa-prop.cc
> > +++ b/gcc/ipa-prop.cc
> > @@ -3004,7 +3004,7 @@ public:
> >    analysis_dom_walker (struct ipa_func_body_info *fbi)
> >  : dom_walker (CDI_DOMINATORS), m_fbi (fbi) {}
> >  
> > -  virtual edge before_dom_children (basic_block);
> > +  edge before_dom_children (basic_block) final override;
> >  
> >  private:
> >    struct ipa_func_body_info *m_fbi;
> > @@ -5653,7 +5653,7 @@ public:
> >  : dom_walker (CDI_DOMINATORS), m_fbi (fbi), m_descriptors
> > (descs),
> >    m_aggval (av), m_something_changed (sc) {}
> >  
> > -  virtual edge before_dom_children (basic_block);
> > +  edge before_dom_children (basic_block) final override;
> >    bool cleanup_eh ()
> >  { return gimple_purge_all_dead_eh_edges (m_need_eh_cleanup); }
> >  
> > diff --git a/gcc/rtl-ssa/blocks.cc b/gcc/rtl-ssa/blocks.cc
> > index 959fad8f829..6b03dd03747 100644
> > --- a/gcc/rtl-ssa/blocks.cc
> > +++ b/gcc/rtl-ssa/blocks.cc
> > @@ -85,8 +85,8 @@ class function_info::bb_walker : public dom_walker
> >  {
> >  public:
> >    bb_walker (function_info *, build_info &);
> > -  virtual edge before_dom_children (basic_block);
> > -  virtual void after_dom_children (basic_block);
> > +  edge before_dom_children (basic_block) final override;
> > +  void after_dom_children (basic_block) final override;
> >  
> >  private:
> >    // Information about the function we're building.
> > diff --git a/gcc/tree-into-ssa.cc b/gcc/tree-into-ssa.cc
> > index 46df57ae0e1..9631d8c6556 100644
> > --- a/gcc/tree-into-ssa.cc
> > +++ b/gcc/tree-into-ssa.cc
> > @@ -1462,8 +1462,8 @@ public:
> >    rewrite_dom_walker (cdi_direction direction)
> >  : dom_walker (direction, ALL_BLOCKS, NULL) {}
> >  
> > -  virtual edge before_dom_children (basic_block);
> > -  virtual void after_dom_children (basic_block);
> > +  edge before_dom_children (basic_block) final override;
> > +  void after_dom_children (basic_block) final override;
> >  };
> >  
> >  /* SSA Rewriting Step 1.  Initializa

PING^2 : Re: [PATCH 03/10] expr.cc: use final/override on op_by_pieces_d vfuncs

[David Malcolm via Gcc-patches]

On Mon, 2022-06-13 at 14:25 -0400, David Malcolm wrote:
> Ping on this patch:
>   https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595434.html
> 
> OK for trunk?
> 
> Thanks
> Dave
> 
> On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> > gcc/ChangeLog:
> > * expr.cc: Add "final" and "override" to op_by_pieces_d
> > vfunc
> > implementations as appropriate.
> > 
> > Signed-off-by: David Malcolm 
> > ---
> >  gcc/expr.cc | 14 +++---
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/gcc/expr.cc b/gcc/expr.cc
> > index 7197996cec7..ce58728862a 100644
> > --- a/gcc/expr.cc
> > +++ b/gcc/expr.cc
> > @@ -1357,8 +1357,8 @@ op_by_pieces_d::run ()
> >  class move_by_pieces_d : public op_by_pieces_d
> >  {
> >    insn_gen_fn m_gen_fun;
> > -  void generate (rtx, rtx, machine_mode);
> > -  bool prepare_mode (machine_mode, unsigned int);
> > +  void generate (rtx, rtx, machine_mode) final override;
> > +  bool prepare_mode (machine_mode, unsigned int) final override;
> >  
> >   public:
> >    move_by_pieces_d (rtx to, rtx from, unsigned HOST_WIDE_INT len,
> > @@ -1453,8 +1453,8 @@ move_by_pieces (rtx to, rtx from, unsigned
> > HOST_WIDE_INT len,
> >  class store_by_pieces_d : public op_by_pieces_d
> >  {
> >    insn_gen_fn m_gen_fun;
> > -  void generate (rtx, rtx, machine_mode);
> > -  bool prepare_mode (machine_mode, unsigned int);
> > +  void generate (rtx, rtx, machine_mode) final override;
> > +  bool prepare_mode (machine_mode, unsigned int) final override;
> >  
> >   public:
> >    store_by_pieces_d (rtx to, by_pieces_constfn cfn, void
> > *cfn_data,
> > @@ -1650,9 +1650,9 @@ class compare_by_pieces_d : public
> > op_by_pieces_d
> >    rtx m_accumulator;
> >    int m_count, m_batch;
> >  
> > -  void generate (rtx, rtx, machine_mode);
> > -  bool prepare_mode (machine_mode, unsigned int);
> > -  void finish_mode (machine_mode);
> > +  void generate (rtx, rtx, machine_mode) final override;
> > +  bool prepare_mode (machine_mode, unsigned int) final override;
> > +  void finish_mode (machine_mode) final override;
> >   public:
> >    compare_by_pieces_d (rtx op0, rtx op1, by_pieces_constfn
> > op1_cfn,
> >    void *op1_cfn_data, HOST_WIDE_INT len, int
> > align,
> 

PING^2 : Re: [PATCH 04/10] tree-switch-conversion.h: use final/override for cluster vfunc impls

[David Malcolm via Gcc-patches]

I'd like to ping this patch:
  https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595435.html
 
OK for trunk?

Thanks
Dave
 
On Mon, 2022-06-13 at 14:26 -0400, David Malcolm wrote:
> Ping for this patch:
>   https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595435.html
> 
> OK for trunk?
> 
> Thanks
> Dave
> 
> On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> > gcc/ChangeLog:
> > * tree-switch-conversion.h: Add "final" and "override" to
> > cluster
> > vfunc implementations as appropriate.
> > 
> > Signed-off-by: David Malcolm 
> > ---
> >  gcc/tree-switch-conversion.h | 32 +---
> >  1 file changed, 17 insertions(+), 15 deletions(-)
> > 
> > diff --git a/gcc/tree-switch-conversion.h b/gcc/tree-switch-
> > conversion.h
> > index 2b677d9f7e9..d22515eb296 100644
> > --- a/gcc/tree-switch-conversion.h
> > +++ b/gcc/tree-switch-conversion.h
> > @@ -130,19 +130,19 @@ public:
> >    {}
> >  
> >    cluster_type
> > -  get_type ()
> > +  get_type () final override
> >    {
> >  return SIMPLE_CASE;
> >    }
> >  
> >    tree
> > -  get_low ()
> > +  get_low () final override
> >    {
> >  return m_low;
> >    }
> >  
> >    tree
> > -  get_high ()
> > +  get_high () final override
> >    {
> >  return m_high;
> >    }
> > @@ -153,13 +153,13 @@ public:
> >    }
> >  
> >    void
> > -  debug ()
> > +  debug () final override
> >    {
> >  dump (stderr);
> >    }
> >  
> >    void
> > -  dump (FILE *f, bool details ATTRIBUTE_UNUSED = false)
> > +  dump (FILE *f, bool details ATTRIBUTE_UNUSED = false) final
> > override
> >    {
> >  PRINT_CASE (f, get_low ());
> >  if (get_low () != get_high ())
> > @@ -170,12 +170,12 @@ public:
> >  fprintf (f, " ");
> >    }
> >  
> > -  void emit (tree, tree, tree, basic_block, location_t)
> > +  void emit (tree, tree, tree, basic_block, location_t) final
> > override
> >    {
> >  gcc_unreachable ();
> >    }
> >  
> > -  bool is_single_value_p ()
> > +  bool is_single_value_p () final override
> >    {
> >  return tree_int_cst_equal (get_low (), get_high ());
> >    }
> > @@ -224,24 +224,24 @@ public:
> >    ~group_cluster ();
> >  
> >    tree
> > -  get_low ()
> > +  get_low () final override
> >    {
> >  return m_cases[0]->get_low ();
> >    }
> >  
> >    tree
> > -  get_high ()
> > +  get_high () final override
> >    {
> >  return m_cases[m_cases.length () - 1]->get_high ();
> >    }
> >  
> >    void
> > -  debug ()
> > +  debug () final override
> >    {
> >  dump (stderr);
> >    }
> >  
> > -  void dump (FILE *f, bool details = false);
> > +  void dump (FILE *f, bool details = false) final override;
> >  
> >    /* List of simple clusters handled by the group.  */
> >    vec m_cases;
> > @@ -261,13 +261,14 @@ public:
> >    {}
> >  
> >    cluster_type
> > -  get_type ()
> > +  get_type () final override
> >    {
> >  return JUMP_TABLE;
> >    }
> >  
> >    void emit (tree index_expr, tree index_type,
> > -    tree default_label_expr, basic_block default_bb,
> > location_t loc);
> > +    tree default_label_expr, basic_block default_bb,
> > location_t loc)
> > +    final override;
> >  
> >    /* Find jump tables of given CLUSTERS, where all members of the
> > vector
> >   are of type simple_cluster.  New clusters are returned.  */
> > @@ -366,7 +367,7 @@ public:
> >    {}
> >  
> >    cluster_type
> > -  get_type ()
> > +  get_type () final override
> >    {
> >  return BIT_TEST;
> >    }
> > @@ -388,7 +389,8 @@ public:
> >  There *MUST* be max_case_bit_tests or less unique case
> >  node targets.  */
> >    void emit (tree index_expr, tree index_type,
> > -    tree default_label_expr, basic_block default_bb,
> > location_t loc);
> > +    tree default_label_expr, basic_block default_bb,
> > location_t loc)
> > + final override;
> >  
> >    /* Find bit tests of given CLUSTERS, where all members of the
> > vector
> >   are of type simple_cluster.  New clusters are returned.  */
> 

Re: [PATCH] tilegx: Fix infinite loop in gen-mul-tables generator

[Iain Buclaw via Gcc-patches]

Excerpts from Jeff Law via Gcc-patches's message of Juni 22, 2022 8:16 pm:
> 
> 
> On 6/22/2022 11:30 AM, Iain Buclaw via Gcc-patches wrote:
>> Hi,
>>
>> Since around GCC 10, the condition `j < (INTMAX_MAX / 10)' will get
>> optimized into `j != 922337203685477580', which will result in an
>> infinite loop for certain inputs of `j'.
>>
>> This patch just copies the condition already used by the -DTILEPRO
>> generator code, which doesn't fall into the same trap.
>>
>> OK for mainline?  OK for backporting to all open release branches?
> Sure, but note the tile ports have been deprecated for a long time and 
> I've got a TODO to finally remove them.
> 

Noted, and I wouldn't mind seeing the back of this port either.

I encountered this as I occasionally I run a modified version of
config-list.mk to test the D front-end.  As the target isn't gone yet,
best to ensure it can still build, even when it is assumed broken.

Iain.

PING^2 : Re: [PATCH 08/10] i386: add 'final' and 'override' to scalar_chain vfunc impls

[David Malcolm via Gcc-patches]

I'd like to ping this patch:
   https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595440.html
 
OK for trunk?

Thanks
Dave
 

On Mon, 2022-06-13 at 14:30 -0400, David Malcolm wrote:
> Ping for this patch:
>   https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595440.html
> 
> OK for trunk?
> 
> Thanks
> Dave
> 
> On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> > gcc/ChangeLog:
> > * config/i386/i386-features.h: Add "final" and "override" to
> > scalar_chain vfunc implementations as appropriate.
> > 
> > Signed-off-by: David Malcolm 
> > ---
> >  gcc/config/i386/i386-features.h | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/gcc/config/i386/i386-features.h b/gcc/config/i386/i386-
> > features.h
> > index 5c307607ae5..f46a6d95b74 100644
> > --- a/gcc/config/i386/i386-features.h
> > +++ b/gcc/config/i386/i386-features.h
> > @@ -169,18 +169,18 @@ class general_scalar_chain : public
> > scalar_chain
> >   public:
> >    general_scalar_chain (enum machine_mode smode_, enum machine_mode
> > vmode_);
> >    ~general_scalar_chain ();
> > -  int compute_convert_gain ();
> > +  int compute_convert_gain () final override;
> >   private:
> >    hash_map defs_map;
> >    bitmap insns_conv;
> >    unsigned n_sse_to_integer;
> >    unsigned n_integer_to_sse;
> > -  void mark_dual_mode_def (df_ref def);
> > -  void convert_insn (rtx_insn *insn);
> > +  void mark_dual_mode_def (df_ref def) final override;
> > +  void convert_insn (rtx_insn *insn) final override;
> >    void convert_op (rtx *op, rtx_insn *insn);
> >    void convert_reg (rtx_insn *insn, rtx dst, rtx src);
> >    void make_vector_copies (rtx_insn *, rtx);
> > -  void convert_registers ();
> > +  void convert_registers () final override;
> >    int vector_const_cost (rtx exp);
> >  };
> >  
> > @@ -190,14 +190,14 @@ class timode_scalar_chain : public scalar_chain
> >    timode_scalar_chain () : scalar_chain (TImode, V1TImode) {}
> >  
> >    /* Convert from TImode to V1TImode is always faster.  */
> > -  int compute_convert_gain () { return 1; }
> > +  int compute_convert_gain () final override { return 1; }
> >  
> >   private:
> > -  void mark_dual_mode_def (df_ref def);
> > +  void mark_dual_mode_def (df_ref def) final override;
> >    void fix_debug_reg_uses (rtx reg);
> > -  void convert_insn (rtx_insn *insn);
> > +  void convert_insn (rtx_insn *insn) final override;
> >    /* We don't convert registers to difference size.  */
> > -  void convert_registers () {}
> > +  void convert_registers () final override {}
> >  };
> >  
> >  } // anon namespace
> 

PING^2: Re: [PATCH 10/10] Add 'final' and 'override' in various places

[David Malcolm via Gcc-patches]

On Mon, 2022-06-13 at 14:30 -0400, David Malcolm wrote:
> Ping re this patch:
>   https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595443.html
> 
> OK for trunk?
> 
> Thanks
> Dave
> 
> On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> > gcc/cp/ChangeLog:
> > * cxx-pretty-print.h: Add "final" and "override" to various
> > vfunc
> > implementations, removing redundant "virtual" as
> > appropriate.
> > * module.cc: Likewise.
> > 
> > gcc/ChangeLog:
> > * genmatch.cc: Add "final" and "override" to various vfunc
> > implementations, removing redundant "virtual" as
> > appropriate.
> > * gensupport.cc: Likewise.
> > * gimple-range-cache.h: Likewise.
> > * ipa-icf-gimple.h: Likewise.
> > * ipa-icf.h: Likewise.
> > * read-md.h: Likewise.
> > * read-rtl-function.cc: Likewise.
> > * tree-ssa-loop-ch.cc: Likewise.
> > * tree-ssa-sccvn.cc: Likewise.
> > 
> > gcc/lto/ChangeLog:
> > * lto-dump.cc: Add "final" and "override" to various vfunc
> > implementations, removing redundant "virtual" as
> > appropriate.
> > 
> > Signed-off-by: David Malcolm 
> > ---
> >  gcc/cp/cxx-pretty-print.h | 38 +++
> > ---
> >  gcc/cp/module.cc  |  4 ++--
> >  gcc/genmatch.cc   | 22 +++---
> >  gcc/gensupport.cc |  2 +-
> >  gcc/gimple-range-cache.h  |  4 ++--
> >  gcc/ipa-icf-gimple.h  |  6 --
> >  gcc/ipa-icf.h | 36 ---
> > -
> >  gcc/lto/lto-dump.cc   |  8 
> >  gcc/read-md.h |  2 +-
> >  gcc/read-rtl-function.cc  |  6 +++---
> >  gcc/tree-ssa-loop-ch.cc   |  4 ++--
> >  gcc/tree-ssa-sccvn.cc |  4 ++--
> >  12 files changed, 71 insertions(+), 65 deletions(-)
> > 
> > diff --git a/gcc/cp/cxx-pretty-print.h b/gcc/cp/cxx-pretty-print.h
> > index 5080f70a8e4..593bd91d4f7 100644
> > --- a/gcc/cp/cxx-pretty-print.h
> > +++ b/gcc/cp/cxx-pretty-print.h
> > @@ -36,25 +36,25 @@ public:
> >  
> >    pretty_printer *clone () const override;
> >  
> > -  void constant (tree);
> > -  void id_expression (tree);
> > -  void primary_expression (tree);
> > -  void postfix_expression (tree);
> > -  void unary_expression (tree);
> > -  void multiplicative_expression (tree);
> > -  void conditional_expression (tree);
> > -  void assignment_expression (tree);
> > -  void expression (tree);
> > -  void type_id (tree);
> > -  void statement (tree);
> > -  void declaration (tree);
> > -  void declaration_specifiers (tree);
> > -  void simple_type_specifier (tree);
> > -  void function_specifier (tree);
> > -  void declarator (tree);
> > -  void direct_declarator (tree);
> > -  void abstract_declarator (tree);
> > -  void direct_abstract_declarator (tree);
> > +  void constant (tree) final override;
> > +  void id_expression (tree) final override;
> > +  void primary_expression (tree) final override;
> > +  void postfix_expression (tree) final override;
> > +  void unary_expression (tree) final override;
> > +  void multiplicative_expression (tree) final override;
> > +  void conditional_expression (tree) final override;
> > +  void assignment_expression (tree) final override;
> > +  void expression (tree) final override;
> > +  void type_id (tree) final override;
> > +  void statement (tree) final override;
> > +  void declaration (tree) final override;
> > +  void declaration_specifiers (tree) final override;
> > +  void simple_type_specifier (tree) final override;
> > +  void function_specifier (tree) final override;
> > +  void declarator (tree) final override;
> > +  void direct_declarator (tree) final override;
> > +  void abstract_declarator (tree) final override;
> > +  void direct_abstract_declarator (tree) final override;
> >  
> >    /* This is the enclosing scope of the entity being pretty-
> > printed. 
> > */
> >    tree enclosing_scope;
> > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > index d1dc73724d1..e93151c98c2 100644
> > --- a/gcc/cp/module.cc
> > +++ b/gcc/cp/module.cc
> > @@ -1483,10 +1483,10 @@ private:
> >  
> >  protected:
> >    using allocator::grow;
> > -  virtual char *grow (char *, unsigned needed);
> > +  char *grow (char *, unsigned needed) final override;
> >  #if MAPPED_WRITING
> >    using allocator::shrink;
> > -  virtual void shrink (char *);
> > +  void shrink (char *) final override;
> >  #endif
> >  
> >  public:
> > diff --git a/gcc/genmatch.cc b/gcc/genmatch.cc
> > index 2b84b849330..a0b22c50ae3 100644
> > --- a/gcc/genmatch.cc
> > +++ b/gcc/genmatch.cc
> > @@ -723,9 +723,9 @@ public:
> >    bool force_leaf;
> >    /* If non-zero, the group for optional handling.  */
> >    unsigned char opt_grp;
> > -  virtual void gen_transform (FILE *f, int, const char *, bool,
> > int,
> > - const char *, capture_info *,
> > - dt_operand ** = 0, int = 0);
> > +  void gen_transform (FILE *f, int

[r13-1243 Regression] FAIL: gcc.dg/torture/pr106070.c -Os execution test on Linux/x86_64

[skpandey--- via Gcc-patches]

On Linux/x86_64,

b36a1c964f99758de1f3b169628965d3c3af812b is the first bad commit
commit b36a1c964f99758de1f3b169628965d3c3af812b
Author: Richard Biener 
Date:   Fri Jun 24 13:37:22 2022 +0200

middle-end/106070 - bogus cond-expr folding

caused

FAIL: gcc.dg/torture/pr106070.c   -O0  execution test
FAIL: gcc.dg/torture/pr106070.c   -O1  execution test
FAIL: gcc.dg/torture/pr106070.c   -O2  execution test
FAIL: gcc.dg/torture/pr106070.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  execution test
FAIL: gcc.dg/torture/pr106070.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  execution test
FAIL: gcc.dg/torture/pr106070.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/torture/pr106070.c   -O3 -g  execution test
FAIL: gcc.dg/torture/pr106070.c   -Os  execution test

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r13-1243/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pr106070.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pr106070.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: [PATCH] libcpp: Update cpp_wcwidth() to Unicode 14.0.0

[David Malcolm via Gcc-patches]

On Mon, 2022-06-06 at 17:49 -0400, Lewis Hyatt via Gcc-patches wrote:
> Hello-
> 
> The attached patch upgrades the cpp_wcwidth() function (needed for
> computing display columns in diagnostics output) from Unicode 13 to
> Unicode 14. I just mechanically followed the procedure in
> contrib/unicode/README with nothing unexpected coming up. I attached it
> compressed since it's a bit large, and not really human readable
> anyway. Please let me know if it's OK to commit. I did
> bootstrap/regtest
> all languages with no issues on x86-64 Linux. (Although I had to revert
> locally one unrelated commit that seems to break bootstrap for Ada on
> the
> master branch currently.)
> 
> BTW, is this something simple enough I should just commit it without
> bugging
> the list for approval?

The patch seems reasonable to me, but Joseph seems to be the expert on
i18n-related matters.

Joseph, do we have a policy on this?

Thanks
Dave

> 
> Thanks!
> 
> -Lewis
> 
> ==
> 
> Subject: [PATCH] libcpp: Update cpp_wcwidth() to Unicode 14.0.0
> 
> The procedure detailed in contrib/unicode/README was followed with
> nothing
> notable coming up. The glibc scripts did not require any update, so the
> only change was retrieving new versions of the Unicode data files and
> rerunning gen_wcwidth.py.
> 
> contrib/ChangeLog:
> 
> * unicode/EastAsianWidth.txt: Update to Unicode 14.0.0.
> * unicode/PropList.txt: Likewise.
> * unicode/README: Likewise.
> * unicode/UnicodeData.txt: Likewise.
> 
> libcpp/ChangeLog:
> 
> * generated_cpp_wcwidth.h: Generated from updated Unicode data
> files.

Go patch committed: Use bool for comma-ok if not already boolean

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend uses bool for a comma-ok statement if
the variable already has a type that is not a boolean type.  This is a
statement like

v, ok := m[k]

Otherwise we may try to convert an unnamed bool type to an interface
type, which will fail.  But we don't want to always use bool, because
the type of the comma-ok variable may be a named bool type, in which
case the assignment would fail (or need an explicit conversion).

The test case is https://go.dev/cl/404496.  This fixes
https://go.dev/issue/52535.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
3bfc16d86b29600fd559dd733a6909c9441aac25
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index f882812d219..e20212e990a 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-6b314f7947b4b31a86c09d166fe6664cd9968824
+6a7ba754e5d98efe0875f1f41f40098e976e7958
 
 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/statements.cc b/gcc/go/gofrontend/statements.cc
index b3db843365e..b442830b0b7 100644
--- a/gcc/go/gofrontend/statements.cc
+++ b/gcc/go/gofrontend/statements.cc
@@ -1594,9 +1594,9 @@ Tuple_map_assignment_statement::do_lower(Gogo* gogo, 
Named_object*,
 
   // var present_temp bool
   Temporary_statement* present_temp =
-Statement::make_temporary((this->present_->type()->is_sink_type())
- ? Type::make_boolean_type()
- : this->present_->type(),
+Statement::make_temporary((this->present_->type()->is_boolean_type()
+  ? this->present_->type()
+  : Type::lookup_bool_type()),
  NULL, loc);
   b->add_statement(present_temp);
 
@@ -1789,9 +1789,9 @@ Tuple_receive_assignment_statement::do_lower(Gogo*, 
Named_object*,
 
   // var closed_temp bool
   Temporary_statement* closed_temp =
-Statement::make_temporary((this->closed_->type()->is_sink_type())
- ? Type::make_boolean_type()
- : this->closed_->type(),
+Statement::make_temporary((this->closed_->type()->is_boolean_type()
+  ? this->closed_->type()
+  : Type::lookup_bool_type()),
  NULL, loc);
   b->add_statement(closed_temp);
 
@@ -1965,6 +1965,8 @@ Tuple_type_guard_assignment_statement::do_lower(Gogo*, 
Named_object*,
   b->add_statement(s);
 
   res = Expression::make_call_result(call, 1);
+  if (!this->ok_->type()->is_boolean_type())
+   res = Expression::make_cast(Type::lookup_bool_type(), res, loc);
   s = Statement::make_assignment(this->ok_, res, loc);
   b->add_statement(s);
 }
@@ -2001,7 +2003,9 @@ 
Tuple_type_guard_assignment_statement::lower_to_object_type(
   Temporary_statement* ok_temp = NULL;
   if (!this->ok_->is_sink_expression())
 {
-  ok_temp = Statement::make_temporary(this->ok_->type(),
+  ok_temp = Statement::make_temporary((this->ok_->type()->is_boolean_type()
+  ? this->ok_->type()
+  : Type::lookup_bool_type()),
  NULL, loc);
   b->add_statement(ok_temp);
 }

Re: [PATCH 6/8] fortran: use grep -F instead of fgrep

[Bernhard Reutner-Fischer via Gcc-patches]

On 24 June 2022 14:35:20 CEST, Rainer Orth  
wrote:
>Hi Xi,
>
>> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
>>
>>> > -   if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v
>>> > -i debian' >/dev/null 2>&1; then \
>>> > +   if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v
>>> > -i debian' >/dev/null 2>&1; then \
>>> >   echo " install-info --delete --info-dir=$(DESTDIR)$(infodir)
>>> > $(DESTDIR)$(infodir)/gfortran.info"; \
>>> >   install-info --delete --info-dir=$(DESTDIR)$(infodir)
>>> > $(DESTDIR)$(infodir)/gfortran.info || : ; \
>>> > else : ; fi; \
>>> 
>>> I'd replace -s >/dev/null 2>&1 with -q while at it.
>>> 
>>> But why is -F used here in the first place?
>>> I do not see much in debian that can be interpreted as a regex?
>>
>> I'm not sure.  It was there since 2004.  Perhaps the author thinks fgrep
>> may save several CPU cycles :).  I'll just use a plain grep in PATCH v2.
>>
>> Rainer: do you have some idea about the availability of "-q" on
>> different hosts?  If you agree I'll use it instead of -s > /dev/null
>> too.
>
>again, the autoconf manual warns agains it, even more so against -s.
>That's the first reference for portability issues and shouldn't be
>ignored without good reason.
>
>In the GCC and Solaris context, /bin/grep supports both -q and -s in
>Solaris 11.3 and 11.4.  It doesn't support -q on Solaris 10, though
>(again, no longer relevant for GCC).

The good reason I would bring forward is that the systems mentioned in the 
autoconf docs are all not supported anymore (IRIX, ancient or old Solaris etc).
Furthermore, grep(1) is required by POSIX to support -q since at least 1997; 
see https://pubs.opengroup.org/onlinepubs/007908799/xcu/grep.html

That's about 25 years now, so everybody had plenty of time to implement this 
specific part, which is even trivial to implement for this particular case of 
grep -q.

All in all i think that we should not be held hostage by such systems any 
longer, at least for such cases that are trivial to fix to conformance. Of 
course that may be just /me.

Iff fixing egrep or fgrep occurrences though,  we should use plain grep where 
applicable, like in this case, IMO.

thanks,

Re: PING^2: Re: [PATCH 01/10] Add 'final' and 'override' to opt_pass vfunc impls

[Jeff Law via Gcc-patches]

On 6/24/2022 12:08 PM, David Malcolm via Gcc-patches wrote:

On Mon, 2022-06-13 at 14:22 -0400, David Malcolm wrote:

Ping for this patch:
   https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595444.html

OK for trunk?
Sorry, I though the series had been approved at some point.   In 
general, adding final/override and removing redundant virtuals should be 
considered trivial IMHO.


So just to be clear, OK for the trunk.

jeff

[committed] d: Merge upstream dmd 529110f66, druntime 148608b7.

[Iain Buclaw via Gcc-patches]

Hi,

This patch merges the D front-end with upstream dmd 529110f66.

The git revision hash of libdruntime has also been bumped, though the
only changes made have been outside what is merged downstream.

D front-end changes:

- Import latest bug fixes to mainline.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 529110f66.
* decl.cc (DeclVisitor::visit (TupleDeclaration *)): Update for new
front-end interface.
* types.cc (layout_aggregate_members): Likewise.

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime 148608b7.
---
 gcc/d/decl.cc |   6 +-
 gcc/d/dmd/MERGE   |   2 +-
 gcc/d/dmd/canthrow.d  |  13 +-
 gcc/d/dmd/cparse.d|  34 -
 gcc/d/dmd/declaration.d   |  63 +
 gcc/d/dmd/dinterpret.d|  17 +--
 gcc/d/dmd/dmangle.d   |  18 ++-
 gcc/d/dmd/dsymbolsem.d|  33 +++--
 gcc/d/dmd/dtoh.d  | 128 +-
 gcc/d/dmd/expression.d|   8 +-
 gcc/d/dmd/expressionsem.d | 104 ++
 gcc/d/dmd/foreachvar.d|  14 +-
 gcc/d/dmd/importc.d   |   4 +
 gcc/d/dmd/ob.d|  22 +--
 gcc/d/dmd/parse.d |  11 +-
 gcc/d/dmd/root/filename.d |  27 ++--
 gcc/d/dmd/semantic2.d |   5 +
 gcc/d/dmd/semantic3.d |   2 +-
 gcc/d/types.cc|   6 +-
 .../compilable/dtoh_AnonDeclaration.d |  14 +-
 .../compilable/dtoh_StructDeclaration.d   |  18 ++-
 .../compilable/dtoh_TemplateDeclaration.d |   6 +-
 .../gdc.test/compilable/dtoh_mangling.d   |   8 +-
 .../gdc.test/compilable/dtoh_protection.d |  28 +++-
 gcc/testsuite/gdc.test/compilable/test23168.d |  30 
 gcc/testsuite/gdc.test/compilable/test23169.d |  14 ++
 gcc/testsuite/gdc.test/compilable/testparse.d |  10 ++
 gcc/testsuite/gdc.test/runnable/test23010.d   |  43 ++
 libphobos/libdruntime/MERGE   |   2 +-
 29 files changed, 464 insertions(+), 226 deletions(-)
 create mode 100644 gcc/testsuite/gdc.test/compilable/test23168.d
 create mode 100644 gcc/testsuite/gdc.test/compilable/test23169.d
 create mode 100644 gcc/testsuite/gdc.test/runnable/test23010.d

diff --git a/gcc/d/decl.cc b/gcc/d/decl.cc
index 8676a1b588b..b82e2d55c13 100644
--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -225,9 +225,9 @@ public:
RootObject *o = (*d->objects)[i];
if (o->dyncast () == DYNCAST_EXPRESSION)
  {
-   DsymbolExp *de = ((Expression *) o)->isDsymbolExp ();
-   if (de != NULL && de->s->isDeclaration ())
- this->build_dsymbol (de->s);
+   VarExp *ve = ((Expression *) o)->isVarExp ();
+   if (ve)
+ this->build_dsymbol (ve->var);
  }
   }
   }
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index d1e3dc16312..f5c42f0ff00 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-6203135dcf0112d3211add0cbfb22fecc5df1af4
+529110f66d7d301d62d943a4e4482edaddeb46ea
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/canthrow.d b/gcc/d/dmd/canthrow.d
index a38cbb1610b..fe6e1e344b9 100644
--- a/gcc/d/dmd/canthrow.d
+++ b/gcc/d/dmd/canthrow.d
@@ -270,18 +270,7 @@ private CT Dsymbol_canThrow(Dsymbol s, FuncDeclaration 
func, bool mustNotThrow)
 }
 else if (auto td = s.isTupleDeclaration())
 {
-for (size_t i = 0; i < td.objects.dim; i++)
-{
-RootObject o = (*td.objects)[i];
-if (o.dyncast() == DYNCAST.expression)
-{
-Expression eo = cast(Expression)o;
-if (auto se = eo.isDsymbolExp())
-{
-result |= Dsymbol_canThrow(se.s, func, mustNotThrow);
-}
-}
-}
+td.foreachVar(&symbolDg);
 }
 return result;
 }
diff --git a/gcc/d/dmd/cparse.d b/gcc/d/dmd/cparse.d
index 62ba889cc13..dff76345fa5 100644
--- a/gcc/d/dmd/cparse.d
+++ b/gcc/d/dmd/cparse.d
@@ -2413,11 +2413,19 @@ final class CParser(AST) : Parser!AST
 if (scw & scwx)
 error("duplicate storage class");
 scw |= scwx;
+// C11 6.7.1-2 At most one storage-class may be given, except 
that
+// _Thread_local may appear with static or extern.
 const scw2 = scw & (SCW.xstatic | SCW.xextern | SCW.xauto | 
SCW.xregister | SCW.xtypedef);
 if (scw2 & (scw2 - 1) ||
-scw & (SCW.xa

[committed] d: Construct indexes of ARRAY_TYPE using ARRAY_REF.

[Iain Buclaw via Gcc-patches]

Hi,

This patch changes the D front-end code generation of index expressions
to use an ARRAY_REF when the array expression is a ARRAY_TYPE.

This is a small simplification over `((T *)&array)[index]', which also
allows eliding an unneccesary marking of TREE_ADDRESSABLE when the array
expression is a parameter or variable declaration.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* d-codegen.cc (build_array_index): Rename to...
(build_pointer_index): ...this.
* d-tree.h (build_array_index): Rename declaration to...
(build_pointer_index): ...this.
* expr.cc (ExprVisitor::visit (IndexExp *)): Construct indexes of
ARRAY_TYPE using ARRAY_REF.
(ExprVisitor::visit (SliceExp *)): Update.
* intrinsics.cc (expand_intrinsic_bt): Update.
---
 gcc/d/d-codegen.cc  |  2 +-
 gcc/d/d-tree.h  |  2 +-
 gcc/d/expr.cc   | 38 +++---
 gcc/d/intrinsics.cc |  4 ++--
 4 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 0e14654e56b..3a201149d74 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -1626,7 +1626,7 @@ build_deref (tree exp)
 /* Builds pointer offset expression PTR[INDEX].  */
 
 tree
-build_array_index (tree ptr, tree index)
+build_pointer_index (tree ptr, tree index)
 {
   if (error_operand_p (ptr) || error_operand_p (index))
 return error_mark_node;
diff --git a/gcc/d/d-tree.h b/gcc/d/d-tree.h
index 751746395e6..a6c38119458 100644
--- a/gcc/d/d-tree.h
+++ b/gcc/d/d-tree.h
@@ -578,7 +578,7 @@ extern tree imaginary_part (tree);
 extern tree complex_expr (tree, tree, tree);
 extern tree indirect_ref (tree, tree);
 extern tree build_deref (tree);
-extern tree build_array_index (tree, tree);
+extern tree build_pointer_index (tree, tree);
 extern tree build_offset_op (tree_code, tree, tree);
 extern tree build_offset (tree, tree);
 extern tree build_memref (tree, tree, tree);
diff --git a/gcc/d/expr.cc b/gcc/d/expr.cc
index fba397bed35..bf750924594 100644
--- a/gcc/d/expr.cc
+++ b/gcc/d/expr.cc
@@ -1222,9 +1222,8 @@ public:
   }
 else
   {
-   /* Get the data pointer and length for static and dynamic arrays.  */
+   /* Get the array and length for static and dynamic arrays.  */
tree array = d_save_expr (build_expr (e->e1));
-   tree ptr = convert_expr (array, tb1, tb1->nextOf ()->pointerTo ());
 
tree length = NULL_TREE;
if (tb1->ty != TY::Tpointer)
@@ -1245,10 +1244,35 @@ public:
if (tb1->ty != TY::Tpointer)
  index = build_bounds_index_condition (e, index, length);
 
-   /* Index the .ptr.  */
-   ptr = void_okay_p (ptr);
-   this->result_ = indirect_ref (TREE_TYPE (TREE_TYPE (ptr)),
- build_array_index (ptr, index));
+   /* Convert vectors to their underlying array type.  */
+   if (VECTOR_TYPE_P (TREE_TYPE (array)))
+ {
+   tree array_type =
+ build_array_type_nelts (TREE_TYPE (TREE_TYPE (array)),
+ TYPE_VECTOR_SUBPARTS (TREE_TYPE (array)));
+   d_mark_addressable (array);
+   array = build1 (VIEW_CONVERT_EXPR, array_type, array);
+ }
+
+   if (TREE_CODE (TREE_TYPE (array)) == ARRAY_TYPE)
+ {
+   /* Generate `array[index]'.  When the index is non-constant, we must
+  mark the array as addressable because we'll need to do pointer
+  arithmetic on its address.  */
+   if (TREE_CODE (index) != INTEGER_CST)
+ d_mark_addressable (array);
+
+   this->result_ = build4 (ARRAY_REF, TREE_TYPE (TREE_TYPE (array)),
+   array, index, NULL_TREE, NULL_TREE);
+ }
+   else
+ {
+   /* Generate `array.ptr[index]'.  */
+   tree ptr = convert_expr (array, tb1, tb1->nextOf ()->pointerTo ());
+   ptr = void_okay_p (ptr);
+   this->result_ = indirect_ref (TREE_TYPE (TREE_TYPE (ptr)),
+ build_pointer_index (ptr, index));
+ }
   }
   }
 
@@ -1347,7 +1371,7 @@ public:
 if (!integer_zerop (lwr_tree))
   {
tree ptrtype = TREE_TYPE (ptr);
-   ptr = build_array_index (void_okay_p (ptr), lwr_tree);
+   ptr = build_pointer_index (void_okay_p (ptr), lwr_tree);
ptr = build_nop (ptrtype, ptr);
   }
 
diff --git a/gcc/d/intrinsics.cc b/gcc/d/intrinsics.cc
index 4222b8a0290..0f96284473f 100644
--- a/gcc/d/intrinsics.cc
+++ b/gcc/d/intrinsics.cc
@@ -306,8 +306,8 @@ expand_intrinsic_bt (intrinsic_code intrinsic, tree callexp)
   tree bitsize = fold_convert (type, TYPE_SIZE (TREE_TYPE (ptr)));
 
   /* ptr[bitnum / bitsize]  */
-  ptr = build_array_index (ptr, fold_build2 (TRUNC_DIV_EXPR, type,
-bitnum, bitsize));
+ 

[committed] d: Add `@register' attribute to compiler and library (PR105413)

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds a new `@register' attribute to the D compiler and
library.  Addressing a feature request in PR105413.

The `@register` attribute specifies that a local or `__gshared` variable
is to be given a register storage-class in the C sense of the term, and
will be placed into a register named `registerName`.

The variable needs to boiled down to a data type that fits the target
register.  It also cannot have either thread-local or `extern` storage.
It is an error to take the address of a register variable.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* d-attribs.cc (d_handle_register_attribute): New function.
(d_langhook_attribute_table): Add register attribute.
* d-codegen.cc (d_mark_addressable): Error if taken address of
register variable.
(build_frame_type): Error if register variable has non-local
references.
* d-tree.h (d_mark_addressable): Add complain parameter.
* decl.cc (get_symbol_decl): Mark register varibles DECL_REGISTER.
Error when register variable declared thread-local or extern.
* expr.cc (ExprVisitor::visit (IndexExp *)): Don't complain about
marking register vectors as addressable in an ARRAY_REF.

libphobos/ChangeLog:

* libdruntime/gcc/attributes.d (register): Define.

gcc/testsuite/ChangeLog:

* gdc.dg/attr_register1.d: New test.
* gdc.dg/attr_register2.d: New test.
* gdc.dg/attr_register3.d: New test.
---
 gcc/d/d-attribs.cc | 40 ++-
 gcc/d/d-codegen.cc | 32 ---
 gcc/d/d-tree.h |  2 +-
 gcc/d/decl.cc  | 24 ++-
 gcc/d/expr.cc  |  2 +-
 gcc/testsuite/gdc.dg/attr_register1.d  | 55 ++
 gcc/testsuite/gdc.dg/attr_register2.d  | 11 ++
 gcc/testsuite/gdc.dg/attr_register3.d  | 22 +++
 libphobos/libdruntime/gcc/attributes.d | 28 +
 9 files changed, 204 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/attr_register1.d
 create mode 100644 gcc/testsuite/gdc.dg/attr_register2.d
 create mode 100644 gcc/testsuite/gdc.dg/attr_register3.d

diff --git a/gcc/d/d-attribs.cc b/gcc/d/d-attribs.cc
index 4b54426be39..23bbe3946fb 100644
--- a/gcc/d/d-attribs.cc
+++ b/gcc/d/d-attribs.cc
@@ -75,6 +75,7 @@ static tree d_handle_weak_attribute (tree *, tree, tree, int, 
bool *) ;
 static tree d_handle_noplt_attribute (tree *, tree, tree, int, bool *) ;
 static tree d_handle_alloc_size_attribute (tree *, tree, tree, int, bool *);
 static tree d_handle_cold_attribute (tree *, tree, tree, int, bool *);
+static tree d_handle_register_attribute (tree *, tree, tree, int, bool *);
 static tree d_handle_restrict_attribute (tree *, tree, tree, int, bool *);
 static tree d_handle_used_attribute (tree *, tree, tree, int, bool *);
 static tree d_handle_visibility_attribute (tree *, tree, tree, int, bool *);
@@ -223,6 +224,8 @@ const attribute_spec d_langhook_attribute_table[] =
 d_handle_cold_attribute, attr_cold_hot_exclusions),
   ATTR_SPEC ("no_sanitize", 1, -1, true, false, false, false,
 d_handle_no_sanitize_attribute, NULL),
+  ATTR_SPEC ("register", 1, 1, true, false, false, false,
+d_handle_register_attribute, NULL),
   ATTR_SPEC ("restrict", 0, 0, true, false, false, false,
 d_handle_restrict_attribute, NULL),
   ATTR_SPEC ("used", 0, 0, true, false, false, false,
@@ -1409,8 +1412,41 @@ d_handle_no_sanitize_attribute (tree *node, tree name, 
tree args, int,
   else
 {
   DECL_ATTRIBUTES (*node) = tree_cons (get_identifier ("no_sanitize"),
-  build_int_cst (d_uint_type, flags),
-  DECL_ATTRIBUTES (*node));
+  build_int_cst (d_uint_type, flags),
+  DECL_ATTRIBUTES (*node));
+}
+
+  return NULL_TREE;
+}
+
+/* Handle a "register" attribute; arguments as in
+   struct attribute_spec.handler.  */
+
+static tree
+d_handle_register_attribute (tree *node, tree name, tree args, int,
+bool *no_add_attrs)
+{
+  if (!VAR_P (*node))
+{
+  warning (OPT_Wattributes, "%qE attribute ignored", name);
+  *no_add_attrs = true;
+}
+  else if (TREE_CODE (TREE_VALUE (args)) != STRING_CST)
+{
+  error ("%qE attribute argument not a string constant", name);
+  *no_add_attrs = true;
+}
+  else if (TREE_STRING_LENGTH (TREE_VALUE (args)) == 0
+  || TREE_STRING_POINTER (TREE_VALUE (args))[0] == '\0')
+{
+  error ("register name not specified for %q+D", *node);
+  *no_add_attrs = true;
+}
+  else
+{
+  DECL_REGISTER (*node) = 1;
+  set_user_assembler_name (*node, TREE_STRING_POINTER (TREE_VALUE (args)));

[committed] d: Give consistent error message when attribute argument not a string constant

[Iain Buclaw via Gcc-patches]

Hi,

This patch adjusts all the "not a string" errors in the D attribute
handlers to use the same format string for consistency.

Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.

Regards,
Iain.

---
gcc/d/ChangeLog:

* d-attribs.cc (d_handle_section_attribute): Update error message.
(d_handle_symver_attribute): Likewise.
(d_handle_no_sanitize_attribute): Likewise.
(d_handle_visibility_attribute): Likewise.

gcc/testsuite/ChangeLog:

* gdc.dg/attr_section1.d: Update dg-error.
* gdc.dg/attr_visibility1.d: Likewise.
---
 gcc/d/d-attribs.cc  | 11 ++-
 gcc/testsuite/gdc.dg/attr_section1.d|  2 +-
 gcc/testsuite/gdc.dg/attr_visibility1.d |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/gcc/d/d-attribs.cc b/gcc/d/d-attribs.cc
index 23bbe3946fb..b7b014f72be 100644
--- a/gcc/d/d-attribs.cc
+++ b/gcc/d/d-attribs.cc
@@ -1015,7 +1015,7 @@ d_handle_section_attribute (tree *node, tree name, tree 
args, int flags,
 
   if (TREE_CODE (TREE_VALUE (args)) != STRING_CST)
 {
-  error ("section attribute argument not a string constant");
+  error ("%qE attribute argument not a string constant", name);
   *no_add_attrs = true;
   return NULL_TREE;
 }
@@ -1065,7 +1065,8 @@ d_handle_section_attribute (tree *node, tree name, tree 
args, int flags,
struct attribute_spec.handler.  */
 
 static tree
-d_handle_symver_attribute (tree *node, tree, tree args, int, bool 
*no_add_attrs)
+d_handle_symver_attribute (tree *node, tree name, tree args, int,
+  bool *no_add_attrs)
 {
   if (TREE_CODE (*node) != FUNCTION_DECL && TREE_CODE (*node) != VAR_DECL)
 {
@@ -1088,7 +1089,7 @@ d_handle_symver_attribute (tree *node, tree, tree args, 
int, bool *no_add_attrs)
   tree symver = TREE_VALUE (args);
   if (TREE_CODE (symver) != STRING_CST)
{
- error ("% attribute argument not a string constant");
+ error ("%qE attribute argument not a string constant", name);
  *no_add_attrs = true;
  return NULL_TREE;
}
@@ -1391,7 +1392,7 @@ d_handle_no_sanitize_attribute (tree *node, tree name, 
tree args, int,
   tree id = TREE_VALUE (args);
   if (TREE_CODE (id) != STRING_CST)
{
- error ("%qE argument not a string", name);
+ error ("%qE attribute argument not a string constant", name);
  return NULL_TREE;
}
 
@@ -1525,7 +1526,7 @@ d_handle_visibility_attribute (tree *node, tree name, 
tree args,
   tree id = TREE_VALUE (args);
   if (TREE_CODE (id) != STRING_CST)
 {
-  error ("visibility argument not a string");
+  error ("%qE attribute argument not a string constant", name);
   return NULL_TREE;
 }
 
diff --git a/gcc/testsuite/gdc.dg/attr_section1.d 
b/gcc/testsuite/gdc.dg/attr_section1.d
index c24634f7fd5..759b203dd44 100644
--- a/gcc/testsuite/gdc.dg/attr_section1.d
+++ b/gcc/testsuite/gdc.dg/attr_section1.d
@@ -7,7 +7,7 @@ import gcc.attributes;
 struct S {} // { dg-warning ".section. attribute does not apply to types" }
 
 @attribute("section", 123)
-int f1(); // { dg-error "section attribute argument not a string constant" }
+int f1(); // { dg-error ".section. attribute argument not a string constant" }
 
 int f2(@section("param") int a) // { dg-error "section attribute not allowed 
for .a." }
 {
diff --git a/gcc/testsuite/gdc.dg/attr_visibility1.d 
b/gcc/testsuite/gdc.dg/attr_visibility1.d
index a7ed4065605..932e6e6051f 100644
--- a/gcc/testsuite/gdc.dg/attr_visibility1.d
+++ b/gcc/testsuite/gdc.dg/attr_visibility1.d
@@ -13,7 +13,7 @@ void nested()
 }
 
 @attribute("visibility", 123)
-int not_a_string(); // { dg-error "visibility argument not a string" }
+int not_a_string(); // { dg-error ".visibility. attribute argument not a 
string constant" }
 
 @attribute("visibility", "invalid argument")
 int invalid_argument(); // { dg-error ".visibility. argument must be one of" }
-- 
2.34.1

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

[Jeff Law via Gcc-patches]

On 6/23/2022 3:21 PM, Dimitar Dimitrov wrote:

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.

OK.
jeff

Re: [PATCH] libcpp: Update cpp_wcwidth() to Unicode 14.0.0

[Joseph Myers]

On Fri, 24 Jun 2022, David Malcolm via Gcc-patches wrote:

> > BTW, is this something simple enough I should just commit it without
> > bugging
> > the list for approval?
> 
> The patch seems reasonable to me, but Joseph seems to be the expert on
> i18n-related matters.
> 
> Joseph, do we have a policy on this?

I don't think we have a policy on Unicode updates specifically, but the 
general principle for updating files maintained outside GCC and copied 
verbatim into the GCC sources doesn't require prior approval.

(Note that Unicode data is also used to generate ucnid.h - data for 
Unicode characters in identifiers - we should probably also include 
DerivedNormalizationProps.txt and DerivedCoreProperties.txt in the 
checked-in Unicode data for that purpose.)

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

[PATCH, committed] Fortran: fix checking of arguments to UNPACK when MASK is a variable [PR105813]

[Harald Anlauf via Gcc-patches]

Dear all,

we failed to fully check arguments to UNPACK when the MASK
argument was not simplified and considered a variable instead
of an array.  The fix is a one-liner.

Regtested on x86_64-pc-linux-gnu and committed to mainline
as obvious after an OK by Steve in the PR.

Thanks,
Harald

From f21f17f95c0237f4f987a5fa9f1fa9c7e0db3c40 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Fri, 24 Jun 2022 22:21:39 +0200
Subject: [PATCH] Fortran: fix checking of arguments to UNPACK when MASK is a
 variable [PR105813]

gcc/fortran/ChangeLog:

	PR fortran/105813
	* check.cc (gfc_check_unpack): Try to simplify MASK argument to
	UNPACK so that checking of the VECTOR argument can work when MASK
	is a variable.

gcc/testsuite/ChangeLog:

	PR fortran/105813
	* gfortran.dg/unpack_vector_1.f90: New test.
---
 gcc/fortran/check.cc  |  2 ++
 gcc/testsuite/gfortran.dg/unpack_vector_1.f90 | 12 
 2 files changed, 14 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/unpack_vector_1.f90

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 0c2cb50c6a7..91d87a1b2c1 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6353,6 +6353,8 @@ gfc_check_unpack (gfc_expr *vector, gfc_expr *mask, gfc_expr *field)
   if (!same_type_check (vector, 0, field, 2))
 return false;

+  gfc_simplify_expr (mask, 0);
+
   if (mask->expr_type == EXPR_ARRAY
   && gfc_array_size (vector, &vector_size))
 {
diff --git a/gcc/testsuite/gfortran.dg/unpack_vector_1.f90 b/gcc/testsuite/gfortran.dg/unpack_vector_1.f90
new file mode 100644
index 000..5347c111e8f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unpack_vector_1.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/105813
+! Fix checking of VECTOR argument to UNPACK when MASK is a variable.
+! Contributed by G.Steinmetz
+
+program p
+  logical, parameter :: mask(2,2) = reshape ([.true.,  .true.,  &
+  .false., .true.], &
+  shape (mask))
+  print *, unpack ([1,2,3], mask, 0) ! OK
+  print *, unpack ([1,2],   mask, 0) ! { dg-error "must provide at least" }
+end
--
2.35.3

Re: PING^2 : Re: [PATCH 08/10] i386: add 'final' and 'override' to scalar_chain vfunc impls

[Uros Bizjak via Gcc-patches]

On Fri, Jun 24, 2022 at 8:19 PM David Malcolm  wrote:
>
> I'd like to ping this patch:
>https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595440.html
>
> OK for trunk?

I have no idea what patch does, but if all other targets do the same,
x86 shouldn't be left behind.

So, rubber-stamping OK.

Thanks,
Uros.

>
> Thanks
> Dave
>
>
> On Mon, 2022-06-13 at 14:30 -0400, David Malcolm wrote:
> > Ping for this patch:
> >   https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595440.html
> >
> > OK for trunk?
> >
> > Thanks
> > Dave
> >
> > On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> > > gcc/ChangeLog:
> > > * config/i386/i386-features.h: Add "final" and "override" to
> > > scalar_chain vfunc implementations as appropriate.
> > >
> > > Signed-off-by: David Malcolm 
> > > ---
> > >  gcc/config/i386/i386-features.h | 16 
> > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/gcc/config/i386/i386-features.h b/gcc/config/i386/i386-
> > > features.h
> > > index 5c307607ae5..f46a6d95b74 100644
> > > --- a/gcc/config/i386/i386-features.h
> > > +++ b/gcc/config/i386/i386-features.h
> > > @@ -169,18 +169,18 @@ class general_scalar_chain : public
> > > scalar_chain
> > >   public:
> > >general_scalar_chain (enum machine_mode smode_, enum machine_mode
> > > vmode_);
> > >~general_scalar_chain ();
> > > -  int compute_convert_gain ();
> > > +  int compute_convert_gain () final override;
> > >   private:
> > >hash_map defs_map;
> > >bitmap insns_conv;
> > >unsigned n_sse_to_integer;
> > >unsigned n_integer_to_sse;
> > > -  void mark_dual_mode_def (df_ref def);
> > > -  void convert_insn (rtx_insn *insn);
> > > +  void mark_dual_mode_def (df_ref def) final override;
> > > +  void convert_insn (rtx_insn *insn) final override;
> > >void convert_op (rtx *op, rtx_insn *insn);
> > >void convert_reg (rtx_insn *insn, rtx dst, rtx src);
> > >void make_vector_copies (rtx_insn *, rtx);
> > > -  void convert_registers ();
> > > +  void convert_registers () final override;
> > >int vector_const_cost (rtx exp);
> > >  };
> > >
> > > @@ -190,14 +190,14 @@ class timode_scalar_chain : public scalar_chain
> > >timode_scalar_chain () : scalar_chain (TImode, V1TImode) {}
> > >
> > >/* Convert from TImode to V1TImode is always faster.  */
> > > -  int compute_convert_gain () { return 1; }
> > > +  int compute_convert_gain () final override { return 1; }
> > >
> > >   private:
> > > -  void mark_dual_mode_def (df_ref def);
> > > +  void mark_dual_mode_def (df_ref def) final override;
> > >void fix_debug_reg_uses (rtx reg);
> > > -  void convert_insn (rtx_insn *insn);
> > > +  void convert_insn (rtx_insn *insn) final override;
> > >/* We don't convert registers to difference size.  */
> > > -  void convert_registers () {}
> > > +  void convert_registers () final override {}
> > >  };
> > >
> > >  } // anon namespace
> >
>
>

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

[Harald Anlauf via Gcc-patches]

Hi Jakub,

Am 24.06.22 um 12:29 schrieb Jakub Jelinek via Gcc-patches:

On Thu, Jun 23, 2022 at 11:17:50PM +0200, Jakub Jelinek via Gcc-patches wrote:

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.


Here is an updated patch that does that.


very good!


--- 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.


And this too.

So I believe it should now be fully ABI compatible.


Great, thanks!

Harald

Add -Woverloaded-virtual to -Wall

[Michel Zou via Gcc-patches]

Hi,

Here is a patch to add -Woverloaded-virtual to -Wall:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=49021

It should address this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729

Regards,

Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to set the lowpart.

[Jeff Law via Gcc-patches]

On 6/15/2022 5:36 AM, Richard Sandiford wrote:

Jeff Law via Gcc-patches  writes:

On 6/13/2022 5:54 AM, Richard Biener wrote:

On Sun, Jun 12, 2022 at 7:27 PM Jeff Law via Gcc-patches
 wrote:
[...]

On a related topic, any thoughts on keeping complex objects as complex
types/modes through gimple and into at least parts of the RTL pipeline?

The way complex arithmetic instructions work on our chip is going to be
extremely tough to utilize in GCC -- we really need to the complex
types/arithmetic up through RTL generation at the least. Ideally we'd
even expose complex modes all the way to final.Is that something
y'all could benefit from as well?  Have y'all poked at this problem at all?

Since you are going to need to "recover" complex operations from people
open-coding them (both fortran and C and also C++ with std::complex) it
should be less work to just do that ;)  I think that complex modes and types
exist solely for ABI purposes.

I don't see any reasonable way to do that.  Without going into all the
details, our complex ops work on low elements within a vector
register.   Trying to recover them after gimple->rtl expansion would be
similar to trying to SLP vectorize on RTL, something I'm not keen to chase.

It would be a hell of a lot easier to leave the complex ops as complex
ops to the expanders, then make the decision to use the complex
instructions or decompose into components.

Realise you might not be in a position to answer this for confidentiality
reasons, but: would normal tree SLP not help here?  We already try to
recognise complex add & multiply, and in principle we could do the same
for other operations as well.  It shouldn't matter that a vector
multiply on 2 elements is really just a single-data operation.
That's the only viable option I see for our target if we keep the model 
where complex operations are broken down into their component operations 
in the gimple passes.


jeff

[pushed] c++: Include -Woverloaded-virtual in -Wall [PR87729]

[Jason Merrill via Gcc-patches]

This seems like a good warning to have in -Wall, as requested.  But as
pointed out in PR20423, some users want a warning only when a derived
function doesn't override any base function.  So let's put that lesser
version in -Wall (and -Woverloaded-virtual=1) while leaving the semantics
for the existing option the same.

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

PR c++/87729
PR c++/20423

gcc/c-family/ChangeLog:

* c.opt (Woverloaded-virtual): Add levels, include in -Wall.

gcc/ChangeLog:

* doc/invoke.texi: Document changes.

gcc/cp/ChangeLog:

* class.cc (warn_hidden): Handle -Woverloaded-virtual=1.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Woverloaded-virt1.C: New test.
* g++.dg/warn/Woverloaded-virt2.C: New test.
---
 gcc/doc/invoke.texi   | 26 ++-
 gcc/c-family/c.opt|  6 -
 gcc/cp/class.cc   | 17 +---
 gcc/testsuite/g++.dg/warn/Woverloaded-virt1.C | 14 ++
 gcc/testsuite/g++.dg/warn/Woverloaded-virt2.C | 15 +++
 5 files changed, 72 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Woverloaded-virt1.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Woverloaded-virt2.C

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index f794edd49e1..dfaa561c8b8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4039,6 +4039,7 @@ a C++ program.  The new-style casts (@code{dynamic_cast},
 less vulnerable to unintended effects and much easier to search for.
 
 @item -Woverloaded-virtual @r{(C++ and Objective-C++ only)}
+@itemx -Woverloaded-virtual=@var{n}
 @opindex Woverloaded-virtual
 @opindex Wno-overloaded-virtual
 @cindex overloaded virtual function, warning
@@ -4052,7 +4053,7 @@ struct A @{
 @};
 
 struct B: public A @{
-  void f(int);
+  void f(int); // does not override
 @};
 @end smallexample
 
@@ -4067,6 +4068,29 @@ b->f();
 @noindent
 fails to compile.
 
+The optional level suffix controls the behavior when all the
+declarations in the derived class override virtual functions in the
+base class, even if not all of the base functions are overridden:
+
+@smallexample
+struct C @{
+  virtual void f();
+  virtual void f(int);
+@};
+
+struct D: public C @{
+  void f(int); // does override
+@}
+@end smallexample
+
+This pattern is less likely to be a mistake; if D is only used
+virtually, the user might have decided that the base class semantics
+for some of the overloads are fine.
+
+At level 1, this case does not warn; at level 2, it does.
+@option{-Woverloaded-virtual} by itself selects level 2.  Level 1 is
+included in @option{-Wall}.
+
 @item -Wno-pmf-conversions @r{(C++ and Objective-C++ only)}
 @opindex Wno-pmf-conversions
 @opindex Wpmf-conversions
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 41a20bc625e..44e1a60ce24 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1126,7 +1126,11 @@ C ObjC C++ ObjC++ Var(warn_overlength_strings) Warning 
LangEnabledBy(C ObjC C++
 Warn if a string is longer than the maximum portable length specified by the 
standard.
 
 Woverloaded-virtual
-C++ ObjC++ Var(warn_overloaded_virtual) Warning
+C++ ObjC++ Warning Alias(Woverloaded-virtual=,2,0)
+Warn about overloaded virtual function names.
+
+Woverloaded-virtual=
+C++ ObjC++ Joined UInteger IntegerRange(0,2) Var(warn_overloaded_virtual) 
Warning LangEnabledBy(C++ ObjC++,Wall,1,0)
 Warn about overloaded virtual function names.
 
 Woverride-init
diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index 3c195b35396..17683f421a7 100644
--- a/gcc/cp/class.cc
+++ b/gcc/cp/class.cc
@@ -3034,6 +3034,7 @@ warn_hidden (tree t)
  continue;
 
/* Remove any overridden functions.  */
+   bool seen_non_override = false;
for (tree fndecl : ovl_range (fns))
  {
if (TREE_CODE (fndecl) == FUNCTION_DECL
@@ -3045,20 +3046,28 @@ warn_hidden (tree t)
for (size_t k = 0; k < base_fndecls.length (); k++)
  if (base_fndecls[k]
  && same_signature_p (fndecl, base_fndecls[k]))
-   base_fndecls[k] = NULL_TREE;
+   {
+ base_fndecls[k] = NULL_TREE;
+ goto next;
+   }
  }
+   seen_non_override = true;
+ next:;
  }
 
+   if (!seen_non_override && warn_overloaded_virtual == 1)
+ /* All the derived fns override base virtuals.  */
+ return;
+
/* Now give a warning for all base functions without overriders,
   as they are hidden.  */
-   tree base_fndecl;
-   FOR_EACH_VEC_ELT (base_fndecls, j, base_fndecl)
+   for (tree base_fndecl : base_fndecls)
  if (base_fndecl)
{
  auto_diagnostic_group d;
  /* Here we know it is a hider, and no overrider exists.  */
  if (warning_at (location_of (base_fndecl),
-   

Re: [PATCH] tilegx: Fix infinite loop in gen-mul-tables generator

[Jeff Law via Gcc-patches]

On 6/24/2022 12:19 PM, Iain Buclaw wrote:

Excerpts from Jeff Law via Gcc-patches's message of Juni 22, 2022 8:16 pm:


On 6/22/2022 11:30 AM, Iain Buclaw via Gcc-patches wrote:

Hi,

Since around GCC 10, the condition `j < (INTMAX_MAX / 10)' will get
optimized into `j != 922337203685477580', which will result in an
infinite loop for certain inputs of `j'.

This patch just copies the condition already used by the -DTILEPRO
generator code, which doesn't fall into the same trap.

OK for mainline?  OK for backporting to all open release branches?

Sure, but note the tile ports have been deprecated for a long time and
I've got a TODO to finally remove them.


Noted, and I wouldn't mind seeing the back of this port either.

I encountered this as I occasionally I run a modified version of
config-list.mk to test the D front-end.  As the target isn't gone yet,
best to ensure it can still build, even when it is assumed broken.
Understood.  I've got no objection to you going ahead and installing the 
patch if it makes your life easier...  Just wanted to make you aware if 
you were looking to do something more with that port.


jeff

[PATCH v2] c++: fix broken copy elision with nested TARGET_EXPRs [PR105550]

[Marek Polacek via Gcc-patches]

On Thu, Jun 02, 2022 at 05:08:54PM -0400, Jason Merrill wrote:
> On 5/26/22 11:01, Marek Polacek wrote:
> > In this problem, we are failing to properly perform copy elision with
> > a conditional operator, so this:
> > 
> >constexpr A a = true ? A{} : A{};
> > 
> > fails with:
> > 
> >error: 'A{((const A*)(&))}' is not a constant expression
> > 
> > The whole initializer is
> > 
> >TARGET_EXPR  > &}> : TARGET_EXPR  > *) &}>>
> > 
> > where the outermost TARGET_EXPR is elided, but not the nested ones.
> > Then we end up replacing the PLACEHOLDER_EXPRs with the temporaries the
> > TARGET_EXPRs represent, which is precisely what should *not* happen with
> > copy elision.
> > 
> > I've tried the approach of tweaking ctx->object, but I ran into gazillion
> > problems with that.  I thought that I would let cxx_eval_constant_expression
> > /TARGET_EXPR create a new object only when ctx->object was null, then
> > adjust setting of ctx->object in places like cxx_bind_parameters_in_call
> > and cxx_eval_component_reference but that failed completely.  Sometimes
> > ctx->object has to be reset, sometimes it cannot be reset, 'this' needed
> > special handling, etc.  I gave up.
> > > But now that we have potential_prvalue_result_of, a simple but less
> > elegant solution is the following.  I thought about setting a flag on
> > a TARGET_EXPR to avoid adding ctx.full_expr, but a new flag would be
> > overkill and using TARGET_EXPR_DIRECT_INIT_P broke things.

Sorry it's taken me so long to get back to this.
 
> This doesn't seem like a general solution; the same issue would also apply
> to ?: of TARGET_EXPR when it's a subexpression rather than the full
> expression, like f(true ? A{} : B{}).

You're right.
 
> Another simple approach, but more general, would be to routinely strip
> TARGET_EXPR from the operands of ?: like we do in various other places in
> constexpr.c.

How about this, then?

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
In this problem, we are failing to properly perform copy elision with
a conditional operator, so this:

  constexpr A a = true ? A{} : A{};

fails with:

  error: 'A{((const A*)(&))}' is not a constant expression

The whole initializer is

  TARGET_EXPR }> : TARGET_EXPR }>>

where the outermost TARGET_EXPR is elided, but not the nested ones.
Then we end up replacing the PLACEHOLDER_EXPRs with the temporaries the
TARGET_EXPRs represent, which is precisely what should *not* happen with
copy elision.

I've tried the approach of tweaking ctx->object, but I ran into gazillion
problems with that.  I thought that I would let cxx_eval_constant_expression
/TARGET_EXPR create a new object only when ctx->object was null, then
adjust setting of ctx->object in places like cxx_bind_parameters_in_call
and cxx_eval_component_reference but that failed completely.  Sometimes
ctx->object has to be reset, sometimes it cannot be reset, 'this' needed
special handling, etc.  I gave up.

Instead, this patch strips TARGET_EXPRs from the operands of ?: like
we do in various other places in constexpr.c.

PR c++/105550

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_conditional_expression): Strip TARGET_EXPRs.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/nsdmi-aggr16.C: Remove FIXME.
* g++.dg/cpp1y/nsdmi-aggr17.C: Remove FIXME.
* g++.dg/cpp0x/constexpr-elision1.C: New test.
* g++.dg/cpp1y/constexpr-elision1.C: New test.
---
 gcc/cp/constexpr.cc   |  7 +++
 .../g++.dg/cpp0x/constexpr-elision1.C | 16 ++
 .../g++.dg/cpp1y/constexpr-elision1.C | 53 +++
 gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr16.C |  5 +-
 gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr17.C |  5 +-
 5 files changed, 80 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-elision1.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-elision1.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 0dc94d9445d..5f7fc6f8f0c 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -3507,6 +3507,13 @@ cxx_eval_conditional_expression (const constexpr_ctx 
*ctx, tree t,
 val = TREE_OPERAND (t, 1);
   if (TREE_CODE (t) == IF_STMT && !val)
 val = void_node;
+  /* A TARGET_EXPR may be nested inside another TARGET_EXPR, but still
+ serve as the initializer for the same object as the outer TARGET_EXPR,
+ as in
+   A a = true ? A{} : A{};
+ so strip the inner TARGET_EXPR so we don't materialize a temporary.  */
+  if (TREE_CODE (val) == TARGET_EXPR)
+val = TARGET_EXPR_INITIAL (val);
   return cxx_eval_constant_expression (ctx, val, lval, non_constant_p,
   overflow_p, jump_target);
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-elision1.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-elision1.C
new file mode 100644
index 000..9e7b9ec3405
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-elision1.C
@@ -0,

Re: [PATCH 5/8] intl: stop using fgrep for exgettext

[Xi Ruoyao via Gcc-patches]

On Fri, 2022-06-24 at 16:06 +, Joseph Myers wrote:
> On Fri, 24 Jun 2022, Xi Ruoyao via Gcc-patches wrote:
> 
> > fgrep has been deprecated in favor of grep -F for a long time, and
> > the
> > next grep release (3.8 or 4.0) will print a warning of fgrep is
> > used.
> > And, the fgrep command in exgettext is no longer useful after we
> > migrated from SVN to Git.  Remove the fgrep command so we won't see
> > the
> > warning.
> > 
> > gcc/ChangeLog:
> > 
> > * po/exgettext: Remove unneeded fgrep command.
> 
> OK.

Pushed as r13-1264 with ChangeLog fix (gcc/po/ChangeLog should be used),
as it does not depend on other parts in the series.