Re: [PATCH] rs6000: Simplify *rotl3_insert_4 by removing DImode

[Kewen.Lin via Gcc-patches]

Hi Segher!

on 2022/6/28 00:02, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Jun 27, 2022 at 05:35:03PM +0800, Kewen.Lin wrote:
>> -(define_insn "*rotl3_insert_4"
>> -  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
>> -(ior:GPR (and:GPR (match_operand:GPR 3 "gpc_reg_operand" "0")
>> -  (match_operand:GPR 4 "const_int_operand" "n"))
>> - (lshiftrt:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
>> +; It's unable to extend this define_insn for DImode, because the
>> +; corresponding hardware instruction for DImode is rldimi, which only has
>> +; four operands and the end of mask is always (63 - SH) rather than 63
>> +; that is required for this pattern.
>> +(define_insn "*rotlsi3_insert_4"
>> +  [(set (match_operand:SI 0 "gpc_reg_operand" "=r")
>> +(ior:SI (and:SI (match_operand:SI 3 "gpc_reg_operand" "0")
>> +  (match_operand:SI 4 "const_int_operand" "n"))
>> + (lshiftrt:SI (match_operand:SI 1 "gpc_reg_operand" "r")
>> (match_operand:SI 2 "const_int_operand" "n"]
> 
> (Broken indentation here, on all of the last three lines differently
> wrong:
> 
>   [(set (match_operand:SI 0 "gpc_reg_operand" "=r")
>   (ior:SI (and:SI (match_operand:SI 3 "gpc_reg_operand" "0")
>   (match_operand:SI 4 "const_int_operand" "n"))
>   (lshiftrt:SI (match_operand:SI 1 "gpc_reg_operand" "r")
>(match_operand:SI 2 "const_int_operand" "n"]
> 
> is better.)
> 

Thanks for catching, I forgot to re-indent after substituting. :(

>> -  "mode == SImode &&
>> -   GET_MODE_PRECISION (mode)
>> -   == INTVAL (operands[2]) + exact_log2 (-UINTVAL (operands[4]))"
>> -{
>> -  operands[2] = GEN_INT (GET_MODE_PRECISION (mode)
>> - - INTVAL (operands[2]));
>> -  if (mode == SImode)
>> -return "rlwimi %0,%1,%h2,32-%h2,31";
>> -  else
>> -return "rldimi %0,%1,%H2,64-%H2";
>> -}
>> +  "INTVAL (operands[2]) + exact_log2 (-UINTVAL (operands[4])) == 32"
>> +  "rlwimi %0,%1,32-%h2,%h2,31"
>>[(set_attr "type" "insert")])
> 
> I was going to say this is not an improvement at all, because now you
> need that big comment.  There are many tricky details here, more
> important ones than the comment talks about.  It is better to show such
> things in the code instead.
> 
> But it already does show that :-)  The patch is okay with that four-line
> comment deleted (and the indentation fixed).  Thanks!
> 

Thanks!  It's adjusted as your comments and committed in r13-1313.

BR,
Kewen

RE: [PATCH] MAINTAINERS: Add myself for write after approval

[Kong, Lingling via Gcc-patches]

Thanks a lot! I fixed it.

ChangeLog:

* MAINTAINERS (Write After Approval): Add myself.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 54d8ad41a6f..151770f59f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -478,6 +478,7 @@ Jeff Knaggs 

 Michael Koch   
 Nicolas Koenig 
 Boris Kolpackov

+Lingling Kong  
 Dave Korn  
 Julia Koval
 Matt Kraai 
-- 
2.18.2

> -Original Message-
> From: Hongyu Wang 
> Sent: Monday, June 27, 2022 4:32 PM
> To: Kong, Lingling 
> Cc: Liu, Hongtao ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] MAINTAINERS: Add myself for write after approval
> 
> Sorry, should be between
> 
> Boris Kolpackov  Dave Korn
> 
> 
> Hongyu Wang  于2022年6月27日周一 16:29
> 写道：
> >
> > According to the official guide, please sort your last name in
> > alphabetical order, which means you shold put your name between
> >
> > Dave Korn  Julia Koval
> > 
> >
> > Kong, Lingling via Gcc-patches  于2022年6月27
> 日周一
> > 16:05写道：
> >
> > >
> > > Hi,
> > >
> > > I want to add myself in MAINTANINER for write after approval.
> > >
> > > OK for master?
> > >
> > > ChangeLog:
> > >
> > > * MAINTAINERS (Write After Approval): Add myself.
> > > ---
> > >  MAINTAINERS | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS index
> > > 54d8ad41a6f..49627e5d113 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -698,6 +698,7 @@ Shujing Zhao
> 
> > >  Jon Ziegler
> > >  Roman Zippel   
> > >  Josef Zlomek   
> > > +Lingling Kong  
> > >
> > > Bug database only accounts
> > >
> > > --
> > > 2.18.1
> > >

[PATCH gcc 1/1] target: Fix asm generation for AVX builtins when using -masm=intel [PR106095]

[~antoyo via Gcc-patches]

From: Antoni Boucher 

gcc/ChangeLog:
PR target/106095
* config/i386/sse.md: Fix asm generation.

gcc/testsuite/ChangeLog:
PR target/106095
* gcc.target/i386/pr106095.c: Add test using those AVX builtins.
---
 gcc/config/i386/sse.md   | 10 ++---
 gcc/testsuite/gcc.target/i386/pr106095.c | 47 
 2 files changed, 52 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr106095.c

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 8cd0f617bf3..f2f72e8fb05 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -8859,7 +8859,7 @@
   "@
cvtsd2ss\t{%2, %0|%0, %2}
cvtsd2ss\t{%2, %0|%0, %q2}
-   vcvtsd2ss\t{%2, %1, %0|%0, 
%1, %q2}"
+   vcvtsd2ss\t{%2, %1, %0|%0, 
%1, %q2}"
   [(set_attr "isa" "noavx,noavx,avx")
(set_attr "type" "ssecvt")
(set_attr "athlon_decode" "vector,double,*")
@@ -8903,7 +8903,7 @@
   "@
cvtss2sd\t{%2, %0|%0, %2}
cvtss2sd\t{%2, %0|%0, %k2}
-   vcvtss2sd\t{%2, %1, 
%0|%0, %1, %k2}"
+   vcvtss2sd\t{%2, %1, 
%0|%0, %1, %k2}"
   [(set_attr "isa" "noavx,noavx,avx")
(set_attr "type" "ssecvt")
(set_attr "amdfam10_decode" "vector,double,*")
@@ -14406,8 +14406,8 @@
   "TARGET_AVX512VL"
 {
   if (GET_MODE_SIZE (GET_MODE_INNER (mode)) == 4)
-return "vpmov\t{%1, %0%{%2%}|%0%{%2%}, %t1}";
-  return "vpmov\t{%1, %0%{%2%}|%0%{%2%}, %g1}";
+return "vpmov\t{%1, %0%{%2%}|%0%{%2%}, %1}";
+  return "vpmov\t{%1, %0%{%2%}|%0%{%2%}, %1}";
 }
   [(set_attr "type" "ssemov")
(set_attr "memory" "store")
@@ -14506,7 +14506,7 @@
  (match_dup 0)
  (match_operand:QI 2 "register_operand" "Yk")))]
   "TARGET_AVX512VL"
-  "vpmovqw\t{%1, %0%{%2%}|%0%{%2%}, %g1}"
+  "vpmovqw\t{%1, %0%{%2%}|%0%{%2%}, %1}"
   [(set_attr "type" "ssemov")
(set_attr "memory" "store")
(set_attr "prefix" "evex")
diff --git a/gcc/testsuite/gcc.target/i386/pr106095.c 
b/gcc/testsuite/gcc.target/i386/pr106095.c
new file mode 100644
index 000..dfa6136500f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr106095.c
@@ -0,0 +1,47 @@
+/* PR gcc/106095 */
+/* { dg-do assemble } */
+/* { dg-options "-mavx512vl -masm=intel" } */
+/* { dg-require-effective-target masm_intel } */
+
+#include 
+#include 
+
+typedef int v4si __attribute__ ((vector_size (16)));
+typedef long long v2di __attribute__ ((vector_size (16)));
+typedef long long v4di __attribute__ ((vector_size (32)));
+typedef double v2df __attribute__ ((vector_size (16)));
+typedef float v4sf __attribute__ ((vector_size (16)));
+
+void bug1(void) {
+v4si ints4 = {0, 1, 2, 3};
+unsigned long long *addr = malloc(sizeof(*addr));
+__builtin_ia32_pmovdw128mem_mask(addr, ints4, 0);
+}
+
+int bug2(void) {
+v2df a = {0.0, 0.0};
+v4sf b = {0.0, 0.0, 0.0, 0.0};
+v2df src = {0.0, 0.0};
+v2df res = __builtin_ia32_cvtss2sd_mask_round(a, b, src, 0, 
_MM_FROUND_NO_EXC);
+return (int)res[0];
+}
+
+int bug3(void) {
+v4sf a = {0.0, 0.0, 0.0, 0.0};
+v2df b = {0.0, 0.0};
+v4sf src = {0.0, 0.0, 0.0, 0.0};
+v4sf res = __builtin_ia32_cvtsd2ss_mask_round(a, b, src, 0, 
_MM_FROUND_NO_EXC);
+return (int)res[0];
+}
+
+int bug4(void) {
+v4di ints4 = {0, 1, 2, 3};
+unsigned long long *addr = malloc(sizeof(*addr));
+__builtin_ia32_pmovqw256mem_mask(addr, ints4, 0);
+}
+
+int bug5(void) {
+v2di ints4 = {0, 1};
+unsigned int *addr = malloc(sizeof(*addr));
+__builtin_ia32_pmovqw128mem_mask(addr, ints4, 0);
+}
-- 
2.34.2

[PATCH gcc 0/1] [PATCH] target: Fix asm generation for AVX builtins when using -masm=intel [PR106095]

[~antoyo via Gcc-patches]

Hi.

This fixes the following bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106095

It's the first time I work outside of the jit component, so please tell
me if I forgot anything.

Here are the results of running the test:

=== gcc Summary ===

# of expected passes182481
# of unexpected failures91
# of unexpected successes   20
# of expected failures  1475
# of unsupported tests  2535

=== g++ Summary ===

# of expected passes231596
# of unexpected failures1
# of expected failures  2083
# of unsupported tests  9948

=== jit Summary ===

# of expected passes14542
# of unexpected failures1

=== libstdc++ Summary ===

# of expected passes15538
# of expected failures  95
# of unsupported tests  653

=== libgomp Summary ===

# of expected passes5012
# of expected failures  33
# of unsupported tests  323

=== libitm Summary ===

# of expected passes44
# of expected failures  3
# of unsupported tests  1

=== libatomic Summary ===

# of expected passes54

It's the first time I run the whole testsuite, so I'm not sure if those
failures are normal. I got more unexpected failures for the gcc tests
than what is shown in https://gcc.gnu.org/pipermail/gcc-
testresults/2022-June/764154.html. In any case, I get the same failures
when running the testsuite on master. Perhaps my configure command is
wrong? I used the following:

../../gcc/configure --enable-host-shared --enable-
languages=c,jit,c++,lto --enable-checking=release
--prefix=(pwd)/../install

Thanks for the review.

Antoni Boucher (1):
  target: Fix asm generation for AVX builtins when using -masm=intel
[PR106095]

 gcc/config/i386/sse.md   | 10 ++---
 gcc/testsuite/gcc.target/i386/pr106095.c | 47 
 2 files changed, 52 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr106095.c

-- 
2.34.2

[PATCH] jit: avoid calloc() poisoning on musl [PR106102]

[Sergei Trofimovich via Gcc-patches]

From: Sergei Trofimovich 

On musl  uses calloc() (via ). jit/ includes
it directly and exposes use of poisoned calloc():

/build/build/./prev-gcc/xg++ ... 
../../gcc-13-20220626/gcc/jit/jit-playback.cc
make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
 from ../../gcc-13-20220626/gcc/jit/jit-playback.cc:44:
/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use 
poisoned "calloc"
   84 | void *calloc(size_t, size_t);
  |   ^
/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use 
poisoned "calloc"
  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
  |^

The change moves sys-specific header before "system.h" inclusion
to evade poisoning.

gcc/jit/

PR c++/106102
* jit-playback.cc: Include  before "system.h" to avoid 
calloc()
poisoning.
* jit-recording.cc: Ditto.
* libgccjit.cc: Ditto.
---
 gcc/jit/jit-playback.cc  | 5 +++--
 gcc/jit/jit-recording.cc | 4 +++-
 gcc/jit/libgccjit.cc | 4 +++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index 6be6bdf8dea..4ab7b59cab9 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -19,6 +19,9 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+/*  has to go before "system.h" as it pull in to-be-poisoned
+   symbols on musl like calloc().  */
+#include 
 #include "system.h"
 #include "coretypes.h"
 #include "target.h"
@@ -41,8 +44,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "diagnostic.h"
 #include "stmt.h"
 
-#include 
-
 #include "jit-playback.h"
 #include "jit-result.h"
 #include "jit-builtins.h"
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 697dee66e73..9505ed3b279 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -19,13 +19,15 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+/*  has to go before "system.h" as it pull in to-be-poisoned
+   symbols on musl like calloc().  */
+#include 
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
 #include "pretty-print.h"
 #include "toplev.h"
 
-#include 
 
 #include "jit-builtins.h"
 #include "jit-recording.h"
diff --git a/gcc/jit/libgccjit.cc b/gcc/jit/libgccjit.cc
index 0e76097b4ba..6a0ac8aaba2 100644
--- a/gcc/jit/libgccjit.cc
+++ b/gcc/jit/libgccjit.cc
@@ -19,12 +19,14 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #include "config.h"
+/*  has to go before "system.h" as it pull in to-be-poisoned
+   symbols on musl like calloc().  */
+#include 
 #include "system.h"
 #include "coretypes.h"
 #include "timevar.h"
 #include "typed-splay-tree.h"
 #include "cppbuiltin.h"
-#include 
 
 #include "libgccjit.h"
 #include "jit-recording.h"
-- 
2.36.1

Re: [PATCH] libcpp: Update ucnid.h to Unicode 14

[Lewis Hyatt via Gcc-patches]

Re-sending this without the large attachment, since it was rejected by the
list. The second attachment was just the Unicode data files to be added:

ftp://ftp.unicode.org/Public/UNIDATA/DerivedNormalizationProps.txt
ftp://ftp.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt

Thanks!

-Lewis

On Sun, Jun 26, 2022 at 07:53:05PM -0400, Lewis Hyatt wrote:
> Hello-
> 
> As we were briefly discussing here:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597272.html
> 
> In contrib/unicode we have 3 Unicode data files added to source control as 
> well
> as a README file which contains a procedure for using them to update
> libcpp/generated_wcwidth.h.  This patch updates the procedure to also contain
> instructions for updating libcpp/ucnid.h, and adds two more Unicode data files
> required to do that (DerivedNormalizationProps.txt and
> DerivedCoreProperties.txt). This should make it simpler to update all
> Unicode-related stuff at the same time.
> 
> I also went ahead and applied the procedure to update ucnid.h from Unicode 13 
> to
> 14. Please let me know if this looks OK to push? I split out the
> addition of the Unicode files into a separate gzipped file below, since it's
> rather large and not that useful to see. Thanks!
> 
> (BTW I did bootstrap + regtest on x86-64 Linux also, no new failures 
> reported.)
> 
> -Lewis
[PATCH] libcpp: Update ucnid.h to Unicode 14

This patch updates ucnid.h from Unicode 13 to Unicode 14.  Additionally, the
procedure detailed in contrib/unicode/README, which updates
generated_wcwidth.h, has been expanded with instructions for updating this
file as well, so that both may be done at the same time conveniently.  Two
additional Unicode data files which are needed to create ucnid.h are also
added to source control in contrib/unicode.

contrib/ChangeLog:

* unicode/README: Added instructions for updating ucnid.h.
* unicode/DerivedCoreProperties.txt: New file added to source
control from Unicode 14.0 release.
* unicode/DerivedNormalizationProps.txt: Likewise.

libcpp/ChangeLog:

* ucnid.h: Regenerated for Unicode 14.0.

diff --git a/contrib/unicode/README b/contrib/unicode/README
index 45a74068c89..fae4f76d524 100644
--- a/contrib/unicode/README
+++ b/contrib/unicode/README
@@ -1,15 +1,19 @@
 This directory contains a mechanism for GCC to have its own internal
-implementation of wcwidth functionality.  (cpp_wcwidth () in libcpp/charset.c).
+implementation of wcwidth functionality (cpp_wcwidth () in libcpp/charset.c),
+as well as a mechanism to update the information about codepoints permitted in
+identifiers, which is encoded in libcpp/ucnid.h.
 
-The idea is to produce the necessary lookup table
-(../../libcpp/generated_cpp_wcwidth.h) in a reproducible way, starting from the
-following files that are distributed by the Unicode Consortium:
+The idea is to produce the necessary lookup tables
+(../../libcpp/{ucnid.h,generated_cpp_wcwidth.h}) in a reproducible way, 
starting
+from the following files that are distributed by the Unicode Consortium:
 
 ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt
 ftp://ftp.unicode.org/Public/UNIDATA/EastAsianWidth.txt
 ftp://ftp.unicode.org/Public/UNIDATA/PropList.txt
+ftp://ftp.unicode.org/Public/UNIDATA/DerivedNormalizationProps.txt
+ftp://ftp.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt
 
-These three files have been added to source control in this directory;
+These files have been added to source control in this directory;
 please see unicode-license.txt for the relevant copyright information.
 
 In order to keep in sync with glibc's wcwidth as much as possible, it is
@@ -25,14 +29,15 @@ localedata/unicode-gen/utf8_gen.py
 And the most recent versions added to GCC are from glibc git commit:
 f6032247061fb37d59565f2e9667e242c8a98e76
 
-Finally, the script gen_wcwidth.py found here contains the GCC-specific code to
+The script gen_wcwidth.py found here contains the GCC-specific code to
 map glibc's output to the lookup tables we require.  This script should not 
need
 to change, unless there are structural changes to the Unicode data files or to
-the glibc code.
+the glibc code.  Similarly, makeucnid.cc in ../../libcpp contains the logic to
+produce ucnid.h.
 
-The procedure to update GCC's wcwidth tables is the following:
+The procedure to update GCC's Unicode support is the following:
 
-1.  Update the three Unicode data files from the above URLs.
+1.  Update the five Unicode data files from the above URLs.
 
 2.  Update the two glibc files in from_glibc/ from glibc's git.  Update
 the commit number above in this README.
@@ -41,4 +46,10 @@ The procedure to update GCC's wcwidth tables is the 
following:
 (where X.Y is the version of the Unicode standard corresponding to the
 Unicode data files being used, most recently, 14.0.0).
 
-After that, GCC's wcwidth will match the most recent glibc.
+4.  Compile makeucnid, e.g. with:
+  gcc -O2 ../../libcpp/makeucnid.cc -o 

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

[Alexandre Oliva via Gcc-patches]

On Jun 27, 2022, Jonathan Wakely  wrote:

> -#if _GLIBCXX_HAVE_DIRFD
> +#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT

Thanks, I had this bit in the WIP _At_path patch, as well as my updated
remove_all patch, in the latest round of tests.

I confirm that I don't get any errors with it on an x86_64-linux-gnu
native built with openat and unlinkat forced disabled in libstdc++, but
on aarch64-rtems6, there are some fails that are not making much sense
to me.  I haven't looked into any but 27_io/.../copy.cc, so I can't tell
whether they've regressed, but copy.cc's test01 did when I put this (or
variants thereof) in.

Tomorrow I'll look into building libstdc++ with -Og or something else
with less optimization than the default, to help me make sense of what's
going on that causes copy() to return without as much as creating the
destination.


FAILED: default@libstdc++,27_io,filesystem,operations,copy_cc
FAILED: default@libstdc++,experimental,filesystem,operations,copy_cc

.../27_io/filesystem/operations/copy.cc:5[67]: void test01(): Assertion 
'!exists(to)' failed.



FAILED: default@libstdc++,27_io,filesystem,operations,copy_file_cc
FAILED: default@libstdc++,experimental,filesystem,operations,copy_file_cc

terminate called after throwing an instance of 
'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: cannot copy file: File exists 
[filesystem-test.01-copy_file] [filesystem-test.01-copy_file]


FAILED: default@libstdc++,27_io,filesystem,operations,equivalent_cc
FAILED: default@libstdc++,experimental,filesystem,operations,equivalent_cc

.../27_io/filesystem/operations/equivalent.cc:4[45]: void test01(): Assertion 
'!result' failed.


FAILED: default@libstdc++,27_io,filesystem,operations,relative_cc

.../27_io/filesystem/operations/relative.cc:32: void test01(): Assertion 'r == 
".."/p' failed.


Also still present:

.../20_util/from_chars/4.cc:304: error: 'log2' is not a member of 'std'; did 
you mean 'log'?

(IIRC we used to have two of these, we're now down to one)

-- 
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: [Ada] Remove useless pragma Warnings Off from runtime units

[Alexandre Oliva via Gcc-patches]

Hello, Jan-Benedict,

On Jun 27, 2022, Jan-Benedict Glaw  wrote:

> For me, this patch broke building a basic cross compiler using Debian
> sid's "gcc-snapshot" package as the build/host compiler

Thanks for reporting the problem you've encountered, and for your
interest.

AFAIK the general recommendation for building GCC is to either bootstrap
it, using a native compiler that meets the build documented
requirements, or use the same precompiled version of the compiler that
you wish to cross-build.

IIRC, this latter requirement is particularly important for canadian
crosses, but it applies as a general recommendation, and GNAT often
takes advantage of that to use features that will be disregarded by
stage1 (no optimization, no fatal warnings, limited runtime, etc), but
that must be available in later stages and in cross builds, which is
easy to satisfy by using the same compiler version, and which is a given
when bootstrapping.

Of course it isn't always the case that you will run into problems when
deviating from these recommendations, so it's perfectly possible that
you get lucky building it all using compilers that don't meet the
recommendations to get started, but that's counting on luck, not on a
reliable procedure.

See note Prerequisites in the GCC Installation manual for more details.

I hope this helps,

-- 
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: PING^2 : Re: [PATCH 08/10] i386: add 'final' and 'override' to scalar_chain vfunc impls

[David Malcolm via Gcc-patches]

On Fri, 2022-06-24 at 22:58 +0200, Uros Bizjak wrote:
> 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, 

Sorry for any confusion; there was a description in the cover letter to
the kit, but you won't have seen that due to me CCing you to just this
one.

This is a C++11 feature, which helps document our intentions in those 
places where we're using virtual functions.  We can add "final" and
"override" to the decls of virtual function in derived classes, which
document to both human and automated readers of the code that the decl
is intended to override a virtual function in a base class.  In
particular, it can help catch commom mistakes where we intended to
override a virtual function, but messed up the prototypes and so merely
introduced a similar-looking function that never gets called.  For
example, G++ has a -Wsuggest-override warning (which I hope we'll
eventually be able to turn on during our bootstraps).


> but if all other targets do the same,
> x86 shouldn't be left behind.
> So, rubber-stamping OK.


Thanks.  As it happens, x86 is actually the only patch I've done this
cleanup for - but Jeff declared this cleanup to be obvious when
reviewing another patch in the kit, so I've pushed this (as r13-1309-
g0a8333ade9a03f), along with the rest of the kit.

Hope this makes sense
Dave



> 
> 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: PING^2: Re: [PATCH 01/10] Add 'final' and 'override' to opt_pass vfunc impls

[David Malcolm via Gcc-patches]

On Fri, 2022-06-24 at 12:45 -0600, Jeff Law via Gcc-patches wrote:
> 
> 
> 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.

Thanks; I've pushed the remaining patches as r13-1305-g725793af78064f
through r13-1310-g26f77c4d19b827.

I had to do some minor refreshing of the patches against trunk to avoid
conflicts; I bootstrapped and regression-tested the result on x86_64-
pc-linux-gnu before pushing.

Dave

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

[Joseph Myers]

On Mon, 27 Jun 2022, Jakub Jelinek via Gcc-patches wrote:

> On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote:
> > I don’t like the _Float128 vs __float128 business, it’s confusing.
> > And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
> > they seem to be basically the same thing, so it’s also redundant.
> 
> I thought __float128 and _Float128 are distinct and incompatible in the FEs
> and equivalent in middle-end and back-end, but apparently they are
> considered equivalent even for _Generic.

Yes, when both are supported, they are the same type.  The main 
differences (not relevant for this patch, I think) are:

* _Float128 is supported on systems where long double has the IEEE 
binary128 format (as a distinct type from long double even when they have 
the same format); __float128 generally isn't supported on such systems.

* __float128 is supported in C++, _Float128 isn't (though we've discussed 
adding support for _FloatN type names and corresponding fN constant 
suffixes in C++; see the thread on the gcc list in March 2021).

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

Re: [PATCH v2 3/7] libbacktrace: use grep instead of fgrep

[Ian Lance Taylor via Gcc-patches]

On Sun, Jun 26, 2022 at 11:10 PM Xi Ruoyao via Gcc-patches
 wrote:
>
> libbacktrace/ChangeLog:
>
> * configure.ac (AC_PROG_FGREP): Use grep instead of fgrep.
> * configure: Regenerate.

Thanks.  Committed to mainline.

Ian

RE: [PING][PATCH] Add instruction level discriminator support.

[Eugene Rozenfeld via Gcc-patches]

Another ping for 
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596065.html .

I got a review from Andi 
(https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596549.html) but I also 
need a review from someone who can approve the changes.

Thanks,

Eugene

-Original Message-
From: Eugene Rozenfeld 
Sent: Friday, June 10, 2022 12:03 PM
To: gcc-patches@gcc.gnu.org; Andi Kleen ; Jan Hubicka 

Subject: [PING][PATCH] Add instruction level discriminator support.

Hello,

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

Thanks,

Eugene

-Original Message-
From: Gcc-patches  On 
Behalf Of Eugene Rozenfeld via Gcc-patches
Sent: Thursday, June 02, 2022 12:22 AM
To: gcc-patches@gcc.gnu.org; Andi Kleen ; Jan Hubicka 

Subject: [EXTERNAL] [PATCH] Add instruction level discriminator support.

This is the first in a series of patches to enable discriminator support in 
AutoFDO.

This patch switches to tracking discriminators per statement/instruction 
instead of per basic block. Tracking per basic block was problematic since not 
all statements in a basic block needed a discriminator and, also, later 
optimizations could move statements between basic blocks making correlation 
during AutoFDO compilation unreliable. Tracking per statement also allows us to 
assign different discriminators to multiple function calls in the same basic 
block. A subsequent patch will add that support.

The idea of this patch is based on commit 
4c311d95cf6d9519c3c20f641cc77af7df491fdf
by Dehao Chen in vendors/google/heads/gcc-4_8 but uses a slightly different 
approach. In Dehao's work special (normally unused) location ids and side 
tables were used to keep track of locations with discriminators. Things have 
changed since then and I don't think we have unused location ids anymore. 
Instead, I made discriminators a part of ad-hoc locations.

The difference from Dehao's work also includes support for discriminator 
reading/writing in lto streaming and in modules.

Tested on x86_64-pc-linux-gnu.


0001-Add-instruction-level-discriminator-support.patch
Description: 0001-Add-instruction-level-discriminator-support.patch

[PATCH] Remove legacy EVRP code.

[Aldy Hernandez via Gcc-patches]

With DOM converted to ranger, there are no longer any uses of the EVRP
engine.  For that matter, we haven't used the legacy mode in quite a
while, so I think it's safe to remove any associated code.

There are some methods in vr_values which should now be private, but I
didn't bother changing them, as most of the vr_values class will be
removed when VRP1 is converted to ranger.

Does anyone have any issues with me pushing this?

gcc/ChangeLog:

* Makefile.in: Remove gimple-ssa-evrp.o and gimple-ssa-evrp-analyze.o.
* flag-types.h (enum evrp_mode): Remove.
* params.opt: Remove --param=evrp-mode.
* tree-vrp.cc (make_pass_early_vrp): New.
(pass_vrp::execute): Call early VRP instance.
* gimple-ssa-evrp-analyze.cc: Removed.
* gimple-ssa-evrp-analyze.h: Removed.
* gimple-ssa-evrp.cc: Removed.
---
 gcc/Makefile.in |   2 -
 gcc/flag-types.h|   9 -
 gcc/gimple-ssa-evrp-analyze.cc  | 456 
 gcc/gimple-ssa-evrp-analyze.h   |  58 
 gcc/gimple-ssa-evrp.cc  | 395 ---
 gcc/params.opt  |  19 --
 gcc/testsuite/g++.dg/pr100774.C |   2 +-
 gcc/testsuite/gcc.dg/pr100781.c |   2 +-
 gcc/tree-vrp.cc |  34 ++-
 9 files changed, 31 insertions(+), 946 deletions(-)
 delete mode 100644 gcc/gimple-ssa-evrp-analyze.cc
 delete mode 100644 gcc/gimple-ssa-evrp-analyze.h
 delete mode 100644 gcc/gimple-ssa-evrp.cc

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index b6dcc45a58a..86257a8b84f 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1413,8 +1413,6 @@ OBJS = \
gimple-range-infer.o \
gimple-range-trace.o \
gimple-ssa-backprop.o \
-   gimple-ssa-evrp.o \
-   gimple-ssa-evrp-analyze.o \
gimple-ssa-isolate-paths.o \
gimple-ssa-nonnull-compare.o \
gimple-ssa-split-paths.o \
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 2c8498169e0..a11f99af887 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -479,15 +479,6 @@ enum threader_debug
   THREADER_DEBUG_ALL = 1
 };
 
-/* EVRP mode.  */
-enum evrp_mode
-{
-  EVRP_MODE_RVRP_ONLY,
-  EVRP_MODE_EVRP_ONLY,
-  EVRP_MODE_EVRP_FIRST,
-  EVRP_MODE_RVRP_FIRST
-};
-
 /* VRP modes.  */
 enum vrp_mode
 {
diff --git a/gcc/gimple-ssa-evrp-analyze.cc b/gcc/gimple-ssa-evrp-analyze.cc
deleted file mode 100644
index 82142db7976..000
--- a/gcc/gimple-ssa-evrp-analyze.cc
+++ /dev/null
@@ -1,456 +0,0 @@
-/* Support routines for Value Range Propagation (VRP).
-   Copyright (C) 2005-2022 Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 3, or (at your option)
-any later version.
-
-GCC is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-.  */
-
-#include "config.h"
-#include "system.h"
-#include "coretypes.h"
-#include "backend.h"
-#include "tree.h"
-#include "gimple.h"
-#include "tree-pass.h"
-#include "ssa.h"
-#include "gimple-pretty-print.h"
-#include "cfganal.h"
-#include "gimple-iterator.h"
-#include "gimple-fold.h"
-#include "tree-eh.h"
-#include "tree-cfg.h"
-#include "tree-ssa-loop-manip.h"
-#include "tree-ssa-loop.h"
-#include "cfgloop.h"
-#include "tree-scalar-evolution.h"
-#include "tree-ssa-propagate.h"
-#include "alloc-pool.h"
-#include "domwalk.h"
-#include "tree-cfgcleanup.h"
-#include "vr-values.h"
-#include "gimple-ssa-evrp-analyze.h"
-
-evrp_range_analyzer::evrp_range_analyzer (bool update_global_ranges)
-  : stack (10), m_update_global_ranges (update_global_ranges)
-{
-  edge e;
-  edge_iterator ei;
-  basic_block bb;
-  FOR_EACH_BB_FN (bb, cfun)
-{
-  bb->flags &= ~BB_VISITED;
-  FOR_EACH_EDGE (e, ei, bb->preds)
-e->flags |= EDGE_EXECUTABLE;
-}
-}
-
-/* Push an unwinding marker onto the unwinding stack.  */
-
-void
-evrp_range_analyzer::push_marker ()
-{
-  stack.safe_push (std::make_pair (NULL_TREE, (value_range_equiv *)NULL));
-}
-
-/* Analyze ranges as we enter basic block BB.  */
-
-void
-evrp_range_analyzer::enter (basic_block bb)
-{
-  if (!optimize)
-return;
-  push_marker ();
-  record_ranges_from_incoming_edge (bb);
-  record_ranges_from_phis (bb);
-  bb->flags |= BB_VISITED;
-}
-
-/* Find new range for NAME such that (OP CODE LIMIT) is true.  */
-value_range_equiv *
-evrp_range_analyzer::try_find_new_range (tree name,
-tree op, tree_code code, tree limit)
-{
-  value_range_equiv vr;
-  const value_range_equiv *old_vr = get_value_range (name);
-

Re: [COMMITTED] Implement vrange::supports_type_p.

[Aldy Hernandez via Gcc-patches]

The conversion for loop-ch is trivial, since the range of a
GIMPLE_COND is always an integer.

OK for trunk?

p.s. The loop unswitch code requires a bit more thought, since there
are numerous range temporaries in the code that are not necessarily
integers.

On Mon, Jun 13, 2022 at 11:44 AM Richard Biener
 wrote:
>
> On Fri, Jun 3, 2022 at 9:31 AM Aldy Hernandez  wrote:
> >
> > [I have conservatively assumed that both the loop-ch and loop-unswitch
> > passes, which also use the ranger, only support integers and pointers.
> > If the goal is to handle other types as well, irange::supports_p()
> > should be Value_Range::supports_type_p(), and any uses of
> > int_range_max should be converted to Value_Range.  I can help in the
> > conversion if you'd like.]
>
> Both should also support float ranges, so yes - if you can send simple
> patches I'll review them.
>
> > As discussed, this patch disambiguates the use of supports_type_p
> > throughout, as what ranger supports is a totally different question
> > than what a given range variant (irange, frange, etc) supports.
> >
> > Unfortunately we need both a static method and a virtual method, and
> > they can't be named the same.  The uses are documented in the vrange
> > class:
> >
> > +// To query what types ranger and the entire ecosystem can support,
> > +// use Value_Range::supports_type_p(tree type).  This is a static
> > +// method available independently of any vrange object.
> > +//
> > +// To query what a given vrange variant can support, use:
> > +//irange::supports_p ()
> > +//frange::supports_p ()
> > +//etc
> > +//
> > +// To query what a range object can support, use:
> > +//void foo (vrange , irange , frange )
> > +//{
> > +// if (v.supports_type_p (type)) ...
> > +// if (i.supports_type_p (type)) ...
> > +// if (f.supports_type_p (type)) ...
> > +//}
> >
> > The value_range_equiv::supports_p() method can be use to determine
> > what legacy VRP supports, as irange::supports_p() will no longer be
> > applicable in the evrp analyzer code base once irange and prange are
> > split.
> >
> > Tested on x86-64 Linux.
> >
> > gcc/ChangeLog:
> >
> > * gimple-range-edge.cc (gimple_outgoing_range_stmt_p): Adjust for
> > an object level supports_type_p for irange and a static
> > Value_Range::supports_type_p.
> > * gimple-range-fold.cc (fold_using_range::range_of_range_op): Same.
> > (fold_using_range::range_of_address): Same.
> > (fold_using_range::range_of_builtin_call): Same.
> > * gimple-range-fold.h (gimple_range_type): Same.
> > (gimple_range_ssa_p): Same.
> > * gimple-range-path.cc (path_range_query::internal_range_of_expr):
> > Same.
> > (path_range_query::range_of_stmt): Same.
> > (path_range_query::add_to_imports): Same.
> > * gimple-range.cc (gimple_ranger::range_on_edge): Same.
> > (gimple_ranger::export_global_ranges): Same.
> > * gimple-ssa-evrp-analyze.cc
> > (evrp_range_analyzer::record_ranges_from_phis):  Same.
> > * range-op.cc (range_operator::wi_fold): Same.
> > (range_operator::fold_range): Same.
> > * tree-ssa-loop-ch.cc (entry_loop_condition_is_static): Same.
> > * tree-ssa-loop-unswitch.cc (struct unswitch_predicate): Same.
> > (evaluate_control_stmt_using_entry_checks): Same.
> > * tree-ssa-threadedge.cc
> > (hybrid_jt_simplifier::compute_ranges_from_state): Same.
> > * tree-vrp.cc (supported_types_p): Same.
> > * value-query.cc (range_query::value_of_expr): Same.
> > (range_query::value_on_edge): Same.
> > (range_query::value_of_stmt): Same.
> > (range_query::get_tree_range): Same.
> > (get_range_global): Same.
> > (global_range_query::range_of_expr): Same.
> > * value-range-equiv.h (class value_range_equiv): Same.
> > * value-range.cc (irange::supports_type_p): Same.
> > (unsupported_range::supports_type_p): Same.
> > * value-range.h (enum value_range_discriminator): Same.
> > (Value_Range::init): Same.
> > (Value_Range::supports_type_p): Same.
> > (irange::supports_type_p): Same.
> > (irange::supports_p): Same.
> > (vrange::supports_type_p): Same.
> > (vrange_allocator::alloc_vrange): Same.
> > ---
> >  gcc/gimple-range-edge.cc   |  3 +--
> >  gcc/gimple-range-fold.cc   |  5 ++--
> >  gcc/gimple-range-fold.h|  4 +--
> >  gcc/gimple-range-path.cc   |  6 ++---
> >  gcc/gimple-range.cc|  4 +--
> >  gcc/gimple-ssa-evrp-analyze.cc |  2 +-
> >  gcc/range-op.cc|  4 +--
> >  gcc/tree-ssa-loop-ch.cc|  2 +-
> >  gcc/tree-ssa-loop-unswitch.cc  |  6 ++---
> >  gcc/tree-ssa-threadedge.cc |  2 +-
> >  gcc/tree-vrp.cc|  4 +--
> >  gcc/value-query.cc | 16 ++--
> >  gcc/value-range-equiv.h|  4 +++
> 

Re: [Ada] Remove useless pragma Warnings Off from runtime units

[Jan-Benedict Glaw]

Hi!


On Thu, 2022-05-12 12:40:09 +, Pierre-Marie de Rodat via Gcc-patches 
 wrote:
> GNAT does not issue a warning anymore on a postcondition of True (used
> here to prevent inining inside GNATprove for proof).
> 
> Tested on x86_64-pc-linux-gnu, committed on trunk
> 
> gcc/ada/
> 
>   * libgnat/s-valuei.ads: Remove pragma Warnings Off.
>   * libgnat/s-valueu.ads: Same.
>   * libgnat/s-valuti.ads: Same.

> diff --git a/gcc/ada/libgnat/s-valuei.ads b/gcc/ada/libgnat/s-valuei.ads
> --- a/gcc/ada/libgnat/s-valuei.ads
> +++ b/gcc/ada/libgnat/s-valuei.ads
> @@ -37,8 +37,6 @@ pragma Assertion_Policy (Pre=> Ignore,
>   Contract_Cases => Ignore,
>   Ghost  => Ignore,
>   Subprogram_Variant => Ignore);
> -pragma Warnings (Off, "postcondition does not mention function result");
> ---  True postconditions are used to avoid inlining for GNATprove

For me, this patch broke building a basic cross compiler using Debian
sid's "gcc-snapshot" package as the build/host compiler:

../gcc/configure '--with-pkgversion=basepoints/gcc-13-1183-g70454c50b45, built 
at 1655800680' --prefix=/var/lib/laminar/run/gcc-vax-linux/5/toolchain-install 
--enable-werror-always --enable-languages=all --disable-gcov --disable-shared 
--disable-threads --target=vax-linux --without-headers
[...]

make V=1 all-gcc
[...]
/usr/lib/gcc-snapshot/bin/gcc -c -g -O2-gnatpg -gnata -W -Wall -nostdinc 
-I- -I. -Iada/generated -Iada -I../../gcc/gcc/ada -Iada/libgnat 
-I../../gcc/gcc/ada/libgnat -Iada/gcc-interface 
-I../../gcc/gcc/ada/gcc-interface ../../gcc/gcc/ada/libgnat/s-valint.adb -o 
ada/libgnat/s-valint.o
mkdir -p ada/libgnat/
/usr/lib/gcc-snapshot/bin/gcc -c -g -O2-gnatpg -gnata -W -Wall -nostdinc 
-I- -I. -Iada/generated -Iada -I../../gcc/gcc/ada -Iada/libgnat 
-I../../gcc/gcc/ada/libgnat -Iada/gcc-interface 
-I../../gcc/gcc/ada/gcc-interface ../../gcc/gcc/ada/libgnat/s-valuns.adb -o 
ada/libgnat/s-valuns.o
mkdir -p ada/libgnat/
/usr/lib/gcc-snapshot/bin/gcc -c -g -O2-gnatpg -gnata -W -Wall -nostdinc 
-I- -I. -Iada/generated -Iada -I../../gcc/gcc/ada -Iada/libgnat 
-I../../gcc/gcc/ada/libgnat -Iada/gcc-interface 
-I../../gcc/gcc/ada/gcc-interface ../../gcc/gcc/ada/libgnat/s-valuti.adb -o 
ada/libgnat/s-valuti.o
s-valuti.ads:63:06: warning: postcondition does not mention function result 
[-gnatw.t]
make[1]: *** [../../gcc/gcc/ada/gcc-interface/Make-lang.in:167: 
ada/libgnat/s-valuti.o] Error 1
make[1]: Leaving directory 
'/var/lib/laminar/run/gcc-vax-linux/5/toolchain-build/gcc'
make: *** [Makefile:4615: all-gcc] Error 2




I'm not an Ada developer, just keeping an eye on GCC and doing
automated builds. Looking at the patch it seems that switching off the
"postcondition does not mention function result" warning was done
under the impression that only a _very_ new GCC is used and my
"gcc-snapshot" package is too old to already contain the fixes
submitted in the patches before this pragma removal.

  If that's correct, that boils down to a specific minimum version to
build with, or adding back the pragmas to allow a bootstrap with an
older compiler version.

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

[pushed] c++: Add fixed test [PR89197]

[Marek Polacek via Gcc-patches]

Fixed since bug 97899 was fixed.

PR c++/89197

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist130.C: New test.
---
 gcc/testsuite/g++.dg/cpp0x/initlist130.C | 5 +
 1 file changed, 5 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist130.C

diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist130.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist130.C
new file mode 100644
index 000..662a5a3ce3f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist130.C
@@ -0,0 +1,5 @@
+// PR c++/89197
+// { dg-options "-Wno-c++11-extensions" }
+// This used to ICE with std=c++03, therefore we run it in C++03 too.
+
+template  void foo(int i) { const int c = int{i}; }

base-commit: 5f6b6494035fb984d745efa28d334f7893e7272b
-- 
2.36.1

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

[Dimitar Dimitrov]

A few testcases were marked for avr target, which has no alignment
requirements.  But those tests in fact should filter for any
target having __BIGGEST_ALIGNMENT__=1.

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

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 non-aggregate types.
For example, BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN
could be defined for a target as something other than
BIGGEST_ALIGNMENT.

gcc/ChangeLog:

* doc/sourcebuild.texi: Document new no_alignment_constraints
effective target check.

gcc/testsuite/ChangeLog:

* c-c++-common/Wcast-align.c: Silence warnings for targets with
no_alignment_constraints.
* gcc.dg/c11-align-4.c: Skip for no_alignment_constraints.
* gcc.dg/strlenopt-10.c: Replace checks for avr with checks for
any target with no_alignment_constraints.
* gcc.dg/strlenopt-11.c: Ditto.
* gcc.dg/strlenopt-13.c: Ditto.
* lib/target-supports.exp
(check_effective_target_no_alignment_constraints): New.


Signed-off-by: Dimitar Dimitrov 
---
Changes since patch V1:
  - Documented the new check in gcc/doc/sourcebuild.texi.

 gcc/doc/sourcebuild.texi |  9 +
 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 +
 7 files changed, 43 insertions(+), 21 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 3696a58fbf2..760ff9559a6 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2716,6 +2716,7 @@ Target supports @option{-branch-cost=N}.
 Target uses @code{__cxa_atexit}.
 
 @item default_packed
+@anchor{default_packed}
 Target has packed layout of structure members by default.
 
 @item exceptions
@@ -2786,6 +2787,14 @@ Target uses natural alignment (aligned to type size) for 
types of
 Target uses natural alignment (aligned to type size) for types of
 64 bits or less.
 
+@item no_alignment_constraints
+Target defines __BIGGEST_ALIGNMENT__=1.  Hence target imposes
+no alignment constraints.  This is similar, but not necessarily
+the same as @ref{default_packed}.  Although @code{BIGGEST_FIELD_ALIGNMENT}
+defaults to @code{BIGGEST_ALIGNMENT} for most targets, it is possible
+for a target to set those two with different values and have different
+alignment constraints for aggregate and non-aggregate types.
+
 @item noinit
 Target supports the @code{noinit} variable attribute.
 
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 

Re: [PATCH] mksysinfo: add support for musl libc

[Ian Lance Taylor via Gcc-patches]

On Mon, Jun 27, 2022 at 9:47 AM  wrote:
>
> From: Sören Tempel 
>
> This patch addresses two minor compatibility issues with musl libc:
>
> * On some architecture (e.g. PowerPC), musl has more than one field
>   prefixed with st_{a,m,c}tim in struct stat. This causes the sed(1)
>   invocation to not work correctly (since it will only replace the first
>   occurrence) [1]. This can be fixed by passing the 'g' flag to replace
>   all occurrences.
> * Since version 1.2.3, musl defines SYS_SECCOMP in signal.h [2]. This
>   conflicts with mksysinfo extraction of syscall numbers [3]. By
>   restricting the grep expression to only match lower case characters we
>   can avoid a redefinition of SYS_SECCOMP. This is GCC PR 105225.
>
> This patch combines two Alpine Linux patches which have been written by
> Ariadne Conill and Natanael Copa. I haven't tested this with glibc but I
> strongly suspect that both changes should not introduce any issue with
> glibc.

Given that pretty much every one of these musl patches has led to
problems on some glibc systems, it would be very nice if you could do
some testing with glibc.  Thanks.

Can you expand on the st_atim issue?  What does the musl type look
like in gen-sysinfo.go?

What is the value of SYS_SECCOMP in musl?  Is it a system call number?
 What does it look like in gen-sysinfo.go?

Thanks.

Ian

Go patch committed: Don't use sink as method expression thunk parameter

[Ian Lance Taylor via Gcc-patches]

This Go frontend patch avoids using a sink name (_) as a parameter
name when creating a method expression thunk.  The patch also fixes a
couple of cases where the error led to a later compiler crash.  The
test case is https://go.dev/cl/414336.  This fixes
https://go.dev/issue/52871.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
5f6b6494035fb984d745efa28d334f7893e7272b
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index f84347ea575..16d274ce99d 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-6edae0ef6521569e8f949fa9dc1139825051
+927528cdc112fc51e0d07ee79e7a1254b586eabe
 
 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/expressions.cc b/gcc/go/gofrontend/expressions.cc
index 135dae02262..f59f61d19ad 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -1426,7 +1426,12 @@ Sink_expression::do_get_backend(Translate_context* 
context)
   Gogo* gogo = context->gogo();
   if (this->bvar_ == NULL)
 {
-  go_assert(this->type_ != NULL && !this->type_->is_sink_type());
+  if (this->type_ == NULL || this->type_->is_sink_type())
+   {
+ go_assert(saw_errors());
+ return gogo->backend()->error_expression();
+   }
+
   Named_object* fn = context->function();
   go_assert(fn != NULL);
   Bfunction* fn_ctx = fn->func_value()->get_or_make_decl(gogo, fn);
@@ -15235,7 +15240,7 @@ Selector_expression::lower_method_expression(Gogo* gogo)
   p != method_parameters->end();
   ++p, ++i)
{
- if (!p->name().empty())
+ if (!p->name().empty() && !Gogo::is_sink_name(p->name()))
parameters->push_back(*p);
  else
{
diff --git a/gcc/go/gofrontend/types.cc b/gcc/go/gofrontend/types.cc
index 39aea769eb2..e82be6840aa 100644
--- a/gcc/go/gofrontend/types.cc
+++ b/gcc/go/gofrontend/types.cc
@@ -4654,8 +4654,11 @@ class Sink_type : public Type
   { return false; }
 
   Btype*
-  do_get_backend(Gogo*)
-  { go_unreachable(); }
+  do_get_backend(Gogo* gogo)
+  {
+go_assert(saw_errors());
+return gogo->backend()->error_type();
+  }
 
   Expression*
   do_type_descriptor(Gogo*, Named_type*)

Go patch committed: Always initialize mpfr in integer import

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend corrects the integer import code to
always initialize an mpfr value.  The test case for this is
https://go.dev/cl/413980.  This fixes https://go.dev/issue/52862.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
722750a44a93ce7d23e09df240d8ab700a2d30e6
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index e20212e990a..f84347ea575 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-6a7ba754e5d98efe0875f1f41f40098e976e7958
+6edae0ef6521569e8f949fa9dc1139825051
 
 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/expressions.cc b/gcc/go/gofrontend/expressions.cc
index 734ecb9492e..135dae02262 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -2715,7 +2715,7 @@ Integer_expression::do_import(Import_expression* imp, 
Location loc)
  return Expression::make_error(loc);
}
   if (pos == std::string::npos)
-   mpfr_set_ui(real, 0, MPFR_RNDN);
+   mpfr_init_set_ui(real, 0, MPFR_RNDN);
   else
{
  std::string real_str = num.substr(0, pos);

[PATCH] mksysinfo: add support for musl libc

[soeren--- via Gcc-patches]

From: Sören Tempel 

This patch addresses two minor compatibility issues with musl libc:

* On some architecture (e.g. PowerPC), musl has more than one field
  prefixed with st_{a,m,c}tim in struct stat. This causes the sed(1)
  invocation to not work correctly (since it will only replace the first
  occurrence) [1]. This can be fixed by passing the 'g' flag to replace
  all occurrences.
* Since version 1.2.3, musl defines SYS_SECCOMP in signal.h [2]. This
  conflicts with mksysinfo extraction of syscall numbers [3]. By
  restricting the grep expression to only match lower case characters we
  can avoid a redefinition of SYS_SECCOMP. This is GCC PR 105225.

This patch combines two Alpine Linux patches which have been written by
Ariadne Conill and Natanael Copa. I haven't tested this with glibc but I
strongly suspect that both changes should not introduce any issue with
glibc.

[1]: https://git.musl-libc.org/cgit/musl/tree/arch/powerpc/bits/stat.h
[2]: 
https://git.musl-libc.org/cgit/musl/commit/?id=3dcbd896907d9d474da811b7c6b769342abaf651
[3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105225

Signed-off-by: Sören Tempel 
---
 libgo/mksysinfo.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index 5aa30915..72044624 100755
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -126,7 +126,7 @@ if ! grep '^const SIGCLD ' ${OUT} >/dev/null 2>&1; then
 fi
 
 # The syscall numbers.  We force the names to upper case.
-grep '^const _SYS_' gen-sysinfo.go | \
+grep '^const _SYS_[a-z]' gen-sysinfo.go | \
   sed -e 's/const _\(SYS_[^= ]*\).*$/\1/' | \
   while read sys; do
 sup=`echo $sys | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ`
@@ -506,7 +506,7 @@ fi
 
 # For historical reasons Go uses the suffix "timespec" instead of "tim" for
 # stat_t's time fields on NetBSD.
-st_times='-e s/st_atim/Atim/ -e s/st_mtim/Mtim/ -e s/st_ctim/Ctim/'
+st_times='-e s/st_atim/Atim/g -e s/st_mtim/Mtim/g -e s/st_ctim/Ctim/g'
 if test "${GOOS}" = "netbsd"; then
 st_times='-e s/st_atim/Atimespec/ -e s/st_mtim/Mtimespec/ -e 
s/st_ctim/Ctimespec/'
 fi

[committed][OG11] andgcn, openmp: Unified Shared Memory

[Andrew Stubbs]

I've pushed these three patches to the devel/omp/gcc-11 branch ("OG11"). 
I'll be submitting mainline versions soonish.


The patches add a means to track "requires unified_shared_memory" from 
the frontend, through the backend compiler, and on to the runtime, plus 
all the bits needed to implement USM in the GCN backend and libgomp runtime.


I'll add proper documentation when I do the forward-port.

Andrewamdgcn, openmp: Auto-detect USM mode and set HSA_XNACK

The AMD GCN runtime must be set to the correct mode for Unified Shared Memory
to work, but this is not always clear at compile and link time due to the split
nature of the offload compilation pipeline.

This patch sets a new attribute on OpenMP offload functions to ensure that the
information is passed all the way to the backend.  The backend then places a
marker in the assembler code for mkoffload to find. Finally mkoffload places a
constructor function into the final program to ensure that the HSA_XNACK
environment variable passes the correct mode to the GPU.

The HSA_XNACK variable must be set before the HSA runtime is even loaded, so
it makes more sense to have this set within the constructor than at some point
later within libgomp or the GCN plugin.

gcc/ChangeLog:

* config/gcn/gcn.c (unified_shared_memory_enabled): New variable.
(gcn_init_cumulative_args): Handle attribute "omp unified memory".
(gcn_hsa_declare_function_name): Emit "MKOFFLOAD OPTIONS: USM+".
* config/gcn/mkoffload.c (TEST_XNACK_OFF): New macro.
(process_asm): Detect "MKOFFLOAD OPTIONS: USM+".
Emit configure_xnack constructor, as required.
* omp-low.c (create_omp_child_function): Add attribute "omp unified
memory".

diff --git a/gcc/config/gcn/gcn.c b/gcc/config/gcn/gcn.c
index 5317e18a78e..8193f5b1d30 100644
--- a/gcc/config/gcn/gcn.c
+++ b/gcc/config/gcn/gcn.c
@@ -68,6 +68,11 @@ static bool ext_gcn_constants_init = 0;
 
 enum gcn_isa gcn_isa = ISA_GCN3;   /* Default to GCN3.  */
 
+/* Record whether the host compiler added "omp unifed memory" attributes to
+   any functions.  We can then pass this on to mkoffload to ensure xnack is
+   compatible there too.  */
+static bool unified_shared_memory_enabled = false;
+
 /* Reserve this much space for LDS (for propagating variables from
worker-single mode to worker-partitioned mode), per workgroup.  Global
analysis could calculate an exact bound, but we don't do that yet.
@@ -2541,6 +2546,25 @@ gcn_init_cumulative_args (CUMULATIVE_ARGS *cum /* 
Argument info to init */ ,
   if (!caller && cfun->machine->normal_function)
 gcn_detect_incoming_pointer_arg (fndecl);
 
+  if (fndecl && lookup_attribute ("omp unified memory",
+ DECL_ATTRIBUTES (fndecl)))
+{
+  unified_shared_memory_enabled = true;
+
+  switch (gcn_arch)
+   {
+   case PROCESSOR_FIJI:
+   case PROCESSOR_VEGA10:
+   case PROCESSOR_VEGA20:
+ error ("GPU architecture does not support Unified Shared Memory");
+   default:
+ ;
+   }
+
+  if (flag_xnack == HSACO_ATTR_OFF)
+   error ("Unified Shared Memory is enabled, but XNACK is disabled");
+}
+
   reinit_regs ();
 }
 
@@ -5430,12 +5454,14 @@ gcn_hsa_declare_function_name (FILE *file, const char 
*name, tree)
   assemble_name (file, name);
   fputs (":\n", file);
 
-  /* This comment is read by mkoffload.  */
+  /* These comments are read by mkoffload.  */
   if (flag_openacc)
 fprintf (file, "\t;; OPENACC-DIMS: %d, %d, %d : %s\n",
 oacc_get_fn_dim_size (cfun->decl, GOMP_DIM_GANG),
 oacc_get_fn_dim_size (cfun->decl, GOMP_DIM_WORKER),
 oacc_get_fn_dim_size (cfun->decl, GOMP_DIM_VECTOR), name);
+  if (unified_shared_memory_enabled)
+fprintf (asm_out_file, "\t;; MKOFFLOAD OPTIONS: USM+\n");
 }
 
 /* Implement TARGET_ASM_SELECT_SECTION.
diff --git a/gcc/config/gcn/mkoffload.c b/gcc/config/gcn/mkoffload.c
index febc8461197..7bd1d2f7692 100644
--- a/gcc/config/gcn/mkoffload.c
+++ b/gcc/config/gcn/mkoffload.c
@@ -80,6 +80,8 @@
 == EF_AMDGPU_FEATURE_XNACK_ANY_V4)
 #define TEST_XNACK_ON(VAR) ((VAR & EF_AMDGPU_FEATURE_XNACK_V4) \
== EF_AMDGPU_FEATURE_XNACK_ON_V4)
+#define TEST_XNACK_OFF(VAR) ((VAR & EF_AMDGPU_FEATURE_XNACK_V4) \
+== EF_AMDGPU_FEATURE_XNACK_OFF_V4)
 
 #define SET_SRAM_ECC_ON(VAR) VAR = ((VAR & ~EF_AMDGPU_FEATURE_SRAMECC_V4) \
| EF_AMDGPU_FEATURE_SRAMECC_ON_V4)
@@ -474,6 +476,7 @@ static void
 process_asm (FILE *in, FILE *out, FILE *cfile)
 {
   int fn_count = 0, var_count = 0, dims_count = 0, regcount_count = 0;
+  bool unified_shared_memory_enabled = false;
   struct obstack fns_os, dims_os, regcounts_os;
   obstack_init (_os);
   obstack_init (_os);
@@ -498,6 +501,7 @@ process_asm (FILE *in, FILE *out, FILE *cfile)
   fn_count += 2;
 
   char buf[1000];
+  char dummy;
   enum
 { 

Re: [PATCH] c++, v2: Add support for __real__/__imag__ modifications in constant expressions [PR88174]

[Jakub Jelinek via Gcc-patches]

On Mon, Jun 20, 2022 at 04:03:50PM -0400, Jason Merrill wrote:
> > +  if (code == COMPLEX_TYPE)
> > +   {
> > + if (TREE_CODE (*valp) == COMPLEX_CST)
> > +   *valp = build2 (COMPLEX_EXPR, type, TREE_REALPART (*valp),
> > +   TREE_IMAGPART (*valp));
> > + else if (TREE_CODE (*valp) == CONSTRUCTOR
> > +  && CONSTRUCTOR_NELTS (*valp) == 0
> > +  && CONSTRUCTOR_NO_CLEARING (*valp))
> > +   {
> > + tree r = build_constructor (reftype, NULL);
> > + CONSTRUCTOR_NO_CLEARING (r) = 1;
> > + *valp = build2 (COMPLEX_EXPR, type, r, r);
> > +   }
> > + gcc_assert (TREE_CODE (*valp) == COMPLEX_EXPR);
> > + ctors.safe_push (valp);
> > + vec_safe_push (indexes, index);
> > + valp = _OPERAND (*valp, TREE_CODE (index) == IMAGPART_EXPR);
> > + gcc_checking_assert (refs->is_empty ());
> > + type = reftype;
> > + break;
> > +   }
...
> > @@ -5949,6 +5986,28 @@ cxx_eval_store_expression (const constex
> > valp = ctx->global->values.get (object);
> > for (unsigned i = 0; i < vec_safe_length (indexes); i++)
> > {
> > + ctors[i] = valp;
> > + if (TREE_CODE (indexes[i]) == REALPART_EXPR
> > + || TREE_CODE (indexes[i]) == IMAGPART_EXPR)
> > +   {
> > + if (TREE_CODE (*valp) == COMPLEX_CST)
> > +   *valp = build2 (COMPLEX_EXPR, TREE_TYPE (*valp),
> > +   TREE_REALPART (*valp),
> > +   TREE_IMAGPART (*valp));
> > + else if (TREE_CODE (*valp) == CONSTRUCTOR
> > +  && CONSTRUCTOR_NELTS (*valp) == 0
> > +  && CONSTRUCTOR_NO_CLEARING (*valp))
> > +   {
> > + tree r = build_constructor (TREE_TYPE (TREE_TYPE (*valp)),
> > + NULL);
> > + CONSTRUCTOR_NO_CLEARING (r) = 1;
> > + *valp = build2 (COMPLEX_EXPR, TREE_TYPE (*valp), r, r);
> > +   }
> > + gcc_assert (TREE_CODE (*valp) == COMPLEX_EXPR);
> > + valp = _OPERAND (*valp,
> > +   TREE_CODE (indexes[i]) == IMAGPART_EXPR);
> > + break;
> > +   }
> 
> Hmm, why do we need to handle complex in the !preeval case?  I'd think we
> want to preevaluate all complex values or components thereof.

Because the late evaluation of the initializer could have touched
the destination, so we need to reevaluate it.
Same reason why we call get_or_insert_ctor_field again in the second
loop as we call it in the first loop.
If it would help, I could move that repeated part into:
tree
canonicalize_complex_to_complex_expr (tree t)
{
  if (TREE_CODE (t) == COMPLEX_CST)
   t = build2 (COMPLEX_EXPR, TREE_TYPE (t),
   TREE_REALPART (t), TREE_IMAGPART (t));
  else if (TREE_CODE (t) == CONSTRUCTOR
   && CONSTRUCTOR_NELTS (t) == 0
   && CONSTRUCTOR_NO_CLEARING (t))
{
  tree r = build_constructor (TREE_TYPE (TREE_TYPE (t)), NULL);
  CONSTRUCTOR_NO_CLEARING (r) = 1;
  t = build2 (COMPLEX_EXPR, TREE_TYPE (t), r, r);
}
  return t;
}
and use that to shorten the code.

> 
> >   constructor_elt *cep
> > = get_or_insert_ctor_field (*valp, indexes[i], index_pos_hints[i]);
> >   valp = >value;
> > @@ -6012,17 +6071,41 @@ cxx_eval_store_expression (const constex
> > bool c = TREE_CONSTANT (init);
> > bool s = TREE_SIDE_EFFECTS (init);
> > if (!c || s || activated_union_member_p)
> > -for (tree elt : *ctors)
> > +for (tree *elt : ctors)
> > {
> > +   if (TREE_CODE (*elt) != CONSTRUCTOR)
> > + continue;
> > if (!c)
> > - TREE_CONSTANT (elt) = false;
> > + TREE_CONSTANT (*elt) = false;
> > if (s)
> > - TREE_SIDE_EFFECTS (elt) = true;
> > + TREE_SIDE_EFFECTS (*elt) = true;
> > /* Clear CONSTRUCTOR_NO_CLEARING since we've activated a member of
> >this union.  */
> > -   if (TREE_CODE (TREE_TYPE (elt)) == UNION_TYPE)
> > - CONSTRUCTOR_NO_CLEARING (elt) = false;
> > +   if (TREE_CODE (TREE_TYPE (*elt)) == UNION_TYPE)
> > + CONSTRUCTOR_NO_CLEARING (*elt) = false;
> > }
> > +  if (!indexes->is_empty ())
> > +{
> > +  tree last = indexes->last ();
> > +  if (TREE_CODE (last) == REALPART_EXPR
> > + || TREE_CODE (last) == IMAGPART_EXPR)
> > +   {
> > + tree *cexpr = ctors.last ();
> > + if (tree c = const_binop (COMPLEX_EXPR, TREE_TYPE (*cexpr),
> > +   TREE_OPERAND (*cexpr, 0),
> > +   TREE_OPERAND (*cexpr, 1)))
> > +   *cexpr = c;
> > + else
> > +   {
> > + TREE_CONSTANT (*cexpr)
> > +   = (TREE_CONSTANT (TREE_OPERAND (*cexpr, 0))
> > +  & TREE_CONSTANT (TREE_OPERAND (*cexpr, 1)));
> > + TREE_SIDE_EFFECTS (*cexpr)
> > +   = (TREE_SIDE_EFFECTS (TREE_OPERAND (*cexpr, 0))
> > +  | TREE_SIDE_EFFECTS (TREE_OPERAND (*cexpr, 1)));
> 
> This seems like it 

Re: [PATCH] Enhance _Hashtable for range insertion 0/5

[Jonathan Wakely via Gcc-patches]

On Sun, 26 Jun 2022 at 21:06, François Dumont  wrote:
>
> I knew you were going to ask for it but was to impatient to propose
> those patches to wait anymore.

Heh, OK :-)

I've started reviewing them, but I thought I'd ask that question first.

>
> Attached you'll find what I start to work on. But I am quite
> disappointed by the results. At least it's showing  that results are not
> worst.
>
> To be honest I was also hoping some feedback from potential users
> interesting in testing those patches. And maybe there are some well
> known (and free) benches that I could challenge ?

I don't know of any, sorry :-(

It would be very useful to have a good set of std::lib benchmarking tests.

https://github.com/hiraditya/std-benchmark does have a umap.cpp test
but it's *very* basic (like most of the tests there - that project
only seems to have good benchmarks for strings).

Re: [PATCH] rs6000: Simplify *rotl3_insert_4 by removing DImode

[Segher Boessenkool]

Hi!

On Mon, Jun 27, 2022 at 05:35:03PM +0800, Kewen.Lin wrote:
> -(define_insn "*rotl3_insert_4"
> -  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
> - (ior:GPR (and:GPR (match_operand:GPR 3 "gpc_reg_operand" "0")
> -   (match_operand:GPR 4 "const_int_operand" "n"))
> -  (lshiftrt:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
> +; It's unable to extend this define_insn for DImode, because the
> +; corresponding hardware instruction for DImode is rldimi, which only has
> +; four operands and the end of mask is always (63 - SH) rather than 63
> +; that is required for this pattern.
> +(define_insn "*rotlsi3_insert_4"
> +  [(set (match_operand:SI 0 "gpc_reg_operand" "=r")
> + (ior:SI (and:SI (match_operand:SI 3 "gpc_reg_operand" "0")
> +   (match_operand:SI 4 "const_int_operand" "n"))
> +  (lshiftrt:SI (match_operand:SI 1 "gpc_reg_operand" "r")
>  (match_operand:SI 2 "const_int_operand" "n"]

(Broken indentation here, on all of the last three lines differently
wrong:

  [(set (match_operand:SI 0 "gpc_reg_operand" "=r")
(ior:SI (and:SI (match_operand:SI 3 "gpc_reg_operand" "0")
(match_operand:SI 4 "const_int_operand" "n"))
(lshiftrt:SI (match_operand:SI 1 "gpc_reg_operand" "r")
 (match_operand:SI 2 "const_int_operand" "n"]

is better.)

> -  "mode == SImode &&
> -   GET_MODE_PRECISION (mode)
> -   == INTVAL (operands[2]) + exact_log2 (-UINTVAL (operands[4]))"
> -{
> -  operands[2] = GEN_INT (GET_MODE_PRECISION (mode)
> -  - INTVAL (operands[2]));
> -  if (mode == SImode)
> -return "rlwimi %0,%1,%h2,32-%h2,31";
> -  else
> -return "rldimi %0,%1,%H2,64-%H2";
> -}
> +  "INTVAL (operands[2]) + exact_log2 (-UINTVAL (operands[4])) == 32"
> +  "rlwimi %0,%1,32-%h2,%h2,31"
>[(set_attr "type" "insert")])

I was going to say this is not an improvement at all, because now you
need that big comment.  There are many tricky details here, more
important ones than the comment talks about.  It is better to show such
things in the code instead.

But it already does show that :-)  The patch is okay with that four-line
comment deleted (and the indentation fixed).  Thanks!


Segher

Re: [PATCH] c++: avoid poisoning on musl [PR106102]

[Richard Biener via Gcc-patches]

> Am 27.06.2022 um 16:50 schrieb Sergei Trofimovich :
> 
> From: Sergei Trofimovich 
> 
> On musl  uses calloc() (via ).  includes
> it indirectly and exposes use of poisoned calloc() when module code
> is built:
> 
>/build/build/./prev-gcc/xg++ ... 
> ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc
>In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
> from 
> /build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h:35,
> 
> from 
> /build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/memory:77,
> from ../../gcc-13-20220626/gcc/../libcody/cody.hh:24,
> from 
> ../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.h:25,
> from 
> ../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.cc:23,
> from ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc:32:
>/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use 
> poisoned "calloc"
>   84 | void *calloc(size_t, size_t);
>  |   ^
>/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use 
> poisoned "calloc"
>  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
>  |^
> 
>gcc/cp/
>* mapper-client.cc: Include  via "system.h".
>* mapper-resolver.cc: Ditto.
>* module.cc: Ditto.
> 
>libcc1/
>* libcc1plugin.cc: Ditto.

You should repeat the actual entry for the different ChangeLog.

Ok wir that change

Richard 
>* libcp1plugin.cc: Ditto.
> ---
> gcc/cp/mapper-client.cc   | 1 +
> gcc/cp/mapper-resolver.cc | 1 +
> gcc/cp/module.cc  | 1 +
> libcc1/libcc1plugin.cc| 1 +
> libcc1/libcp1plugin.cc| 1 +
> 5 files changed, 5 insertions(+)
> 
> diff --git a/gcc/cp/mapper-client.cc b/gcc/cp/mapper-client.cc
> index 8603a886a09..fe9544b5ba4 100644
> --- a/gcc/cp/mapper-client.cc
> +++ b/gcc/cp/mapper-client.cc
> @@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.  If not see
> #define INCLUDE_STRING
> #define INCLUDE_VECTOR
> #define INCLUDE_MAP
> +#define INCLUDE_MEMORY
> #include "system.h"
> 
> #include "line-map.h"
> diff --git a/gcc/cp/mapper-resolver.cc b/gcc/cp/mapper-resolver.cc
> index e3d29fb5ada..e70d1b4ae2c 100644
> --- a/gcc/cp/mapper-resolver.cc
> +++ b/gcc/cp/mapper-resolver.cc
> @@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
> #define INCLUDE_VECTOR
> #define INCLUDE_ALGORITHM
> #define INCLUDE_MAP
> +#define INCLUDE_MEMORY
> #include "system.h"
> 
> // We don't want or need to be aware of networking
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index e7ce40ef464..99f10733d4b 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -206,6 +206,7 @@ Classes used:
> 
> #define _DEFAULT_SOURCE 1 /* To get TZ field of struct tm, if available.  */
> #include "config.h"
> +#define INCLUDE_MEMORY
> #define INCLUDE_STRING
> #define INCLUDE_VECTOR
> #include "system.h"
> diff --git a/libcc1/libcc1plugin.cc b/libcc1/libcc1plugin.cc
> index 12ab5a57c8d..bdd0bdabe77 100644
> --- a/libcc1/libcc1plugin.cc
> +++ b/libcc1/libcc1plugin.cc
> @@ -31,6 +31,7 @@
> #undef PACKAGE_TARNAME
> #undef PACKAGE_VERSION
> 
> +#define INCLUDE_MEMORY
> #include "gcc-plugin.h"
> #include "system.h"
> #include "coretypes.h"
> diff --git a/libcc1/libcp1plugin.cc b/libcc1/libcp1plugin.cc
> index 83dab7f58b1..e2d5039a0a1 100644
> --- a/libcc1/libcp1plugin.cc
> +++ b/libcc1/libcp1plugin.cc
> @@ -32,6 +32,7 @@
> #undef PACKAGE_TARNAME
> #undef PACKAGE_VERSION
> 
> +#define INCLUDE_MEMORY
> #include "gcc-plugin.h"
> #include "system.h"
> #include "coretypes.h"
> -- 
> 2.36.1
> 

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

[Jonathan Wakely via Gcc-patches]

On Mon, 27 Jun 2022 at 15:00, Jonathan Wakely  wrote:
>
> On Mon, 27 Jun 2022 at 14:32, Jonathan Wakely  wrote:
> >
> > On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva  wrote:
> > >
> > > On Jun 27, 2022, Alexandre Oliva  wrote:
> > >
> > > > It looks like the atp.pathname is missing the nonexistent_path
> > > > assigned to variable dir in test_pr99290, so we attempt to open
> > > > subdirs thereof as if with openat.
> > >
> > > This appears to be caused by the early return in fs::_Dir's ctor:
> > >
> > >   _Dir(const fs::path& p, bool skip_permission_denied, bool nofollow,
> > >[[maybe_unused]] bool filename_only, error_code& ec)
> > >   : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec)
> > >   {
> > > #if _GLIBCXX_HAVE_DIRFD // && 0
> > > if (filename_only)
> > >   return; // Do not store path p when we aren't going to use it.
> > > #endif
> >
> > Yes, this needs a fix. If we don't have openat then we always need a
> > full path relative to the CWD, not just a filename relative to a file
> > descriptor for the parent directory.
> >
> > I think we need to store the directory's path if any of dirfd, openat
> > or unlinkat is missing.

i.e.

--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -48,7 +48,7 @@ struct fs::_Dir : _Dir_base
   [[maybe_unused]] bool filename_only, error_code& ec)
  : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec)
  {
-#if _GLIBCXX_HAVE_DIRFD
+#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT
if (filename_only)
  return; // Do not store path p when we aren't going to use it.
#endif



> >
> >
> > >
> > > if (!ec)
> > >   path = p;
> > >   }
> > >
> > > but somehow disabling the early return to force the saving of path
> > > appears to break copy(): copy.cc's test01() succeeded without the '&& 0'
> > > that I've commented-out above, but started failing to create 'to' in the
> > > copy at line copy.cc:54 when I put it in to prevent the early return.

N.B. it's not supposed to create 'to' there, that line is checking
that it fails and reports an error.

Could the FAIL simply be that rtems gives a different error, not
EISDIR as the test expects?

  VERIFY( ec == std::make_error_code(std::errc::is_a_directory) );

Although that shouldn't depend on anything target-specific, because
the libstdc++ code itself reports that error:

  else if (is_directory(f) && create_symlinks)
ec = std::make_error_code(errc::is_a_directory);

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

[Jakub Jelinek via Gcc-patches]

On Wed, Jun 22, 2022 at 12:04:59AM -0400, 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".

The usual case is that people just use -fsanitize=undefined
and get both return and unreachable sanitization, for fall through
into end of functions returning non-void done through return sanitization.

In the rare case people use something different like
-fsanitize=undefined -fno-sanitize=return
or
-fsanitize=unreachable
etc., they presumably don't want the fall through from end of function
diagnosed at runtime.

I think the behavior we want is:
1) -fsanitize=return is on -> use ubsan_instrument_return
   (__ubsan_missing_return_data or __builtin_trap depending on
-fsanitize-trap=return); otherwise
2) -funreachable-traps is on (from -O0/-Og by default or explicit),
   emit __builtin_trap; otherwise
3) -fsanitize=unreachable is on, not emit anything (__builtin_unreachable
   would be just an optimization, but user asked not to instrument returns,
   only unreachable, so honor user's decision and avoid confusion); otherwise
4) -O0 is on, not emit anything (__builtin_unreachable wouldn't be much
   of an optimization, just surprising and hard to debug effect); otherwise
5) emit __builtin_unreachable

Current trunk with your PR104642 fix in implements 1), will do 2)
only if -fsanitize=unreachable is not on, will do 3), will do 4) and 5).

So, I'd change cp-gimplify.cc (cp_maybe_instrument_return), change:
  if (!sanitize_flags_p (SANITIZE_RETURN, fndecl)
  && ((!optimize && !flag_unreachable_traps)
  || sanitize_flags_p (SANITIZE_UNREACHABLE, fndecl)))
return;
to
  if (!sanitize_flags_p (SANITIZE_RETURN, fndecl)
  && !flag_unreachable_traps
  && (!optimize || sanitize_flags_p (SANITIZE_UNREACHABLE, fndecl)))
return;
and
  if (sanitize_flags_p (SANITIZE_RETURN, fndecl))
t = ubsan_instrument_return (loc);
  else
t = build_builtin_unreachable (BUILTINS_LOCATION);
to
  if (sanitize_flags_p (SANITIZE_RETURN, fndecl))
t = ubsan_instrument_return (loc);
  else if (flag_unreachable_traps)
t = build_call_expr_loc (BUILTINS_LOCATION,
 builtin_decl_explicit (BUILT_IN_TRAP), 0);
  else
t = build_builtin_unreachable (BUILTINS_LOCATION);

Jakub

Re: [x86 PATCH] PR rtl-optimization/96692: ((A|B)^C)^A using andn with -mbmi.

[Segher Boessenkool]

Hi!

On Sun, Jun 26, 2022 at 07:07:35PM +0200, Uros Bizjak via Gcc-patches wrote:
> On Sun, Jun 26, 2022 at 2:04 PM Roger Sayle  
> wrote:
> > I'll investigate whether this optimization can also be implemented
> > more generically in simplify_rtx when the backend provides
> > accurate rtx_costs for "(and (not ..." (as there's no optab for
> > andn).

"Accurate rtx_cost" is a fallacy.  insn_cost can be seen as somewhat
accurate (in some simplified model of reality), but rtx_cost always
misses too much context to be useful as anything but a rough estimate.

> *combine splitter is described in the documentation as the splitter
> pattern that does *not* match any existing insn pattern.

Yeah, that documentation is somewhat misleading, in both directions :-(

combine can and will and does use any splitter, whether or not there is
an insn with that insn pattern.  If there is an insn that passes recog()
combine will not even try a split, but this is not the same thing at
all: if the insn conditions are not met, the insn does not recog().  It
is quite common to have the same instruction pattern with different
insn conditions.

In the other direction, other passes can call split_insns as well, of
course.  Nothing currently does, but that does not change much :-)


Segher

[PATCH] c++: avoid poisoning on musl [PR106102]

[Sergei Trofimovich via Gcc-patches]

From: Sergei Trofimovich 

On musl  uses calloc() (via ).  includes
it indirectly and exposes use of poisoned calloc() when module code
is built:

/build/build/./prev-gcc/xg++ ... 
../../gcc-13-20220626/gcc/cp/mapper-resolver.cc
In file included from /<>/musl-1.2.3-dev/include/pthread.h:30,
 from 
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h:35,
 
 from 
/build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/memory:77,
 from ../../gcc-13-20220626/gcc/../libcody/cody.hh:24,
 from ../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.h:25,
 from 
../../gcc-13-20220626/gcc/cp/../../c++tools/resolver.cc:23,
 from ../../gcc-13-20220626/gcc/cp/mapper-resolver.cc:32:
/<>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use 
poisoned "calloc"
   84 | void *calloc(size_t, size_t);
  |   ^
/<>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use 
poisoned "calloc"
  124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
  |^

gcc/cp/
* mapper-client.cc: Include  via "system.h".
* mapper-resolver.cc: Ditto.
* module.cc: Ditto.

libcc1/
* libcc1plugin.cc: Ditto.
* libcp1plugin.cc: Ditto.
---
 gcc/cp/mapper-client.cc   | 1 +
 gcc/cp/mapper-resolver.cc | 1 +
 gcc/cp/module.cc  | 1 +
 libcc1/libcc1plugin.cc| 1 +
 libcc1/libcp1plugin.cc| 1 +
 5 files changed, 5 insertions(+)

diff --git a/gcc/cp/mapper-client.cc b/gcc/cp/mapper-client.cc
index 8603a886a09..fe9544b5ba4 100644
--- a/gcc/cp/mapper-client.cc
+++ b/gcc/cp/mapper-client.cc
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.  If not see
 #define INCLUDE_STRING
 #define INCLUDE_VECTOR
 #define INCLUDE_MAP
+#define INCLUDE_MEMORY
 #include "system.h"
 
 #include "line-map.h"
diff --git a/gcc/cp/mapper-resolver.cc b/gcc/cp/mapper-resolver.cc
index e3d29fb5ada..e70d1b4ae2c 100644
--- a/gcc/cp/mapper-resolver.cc
+++ b/gcc/cp/mapper-resolver.cc
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 #define INCLUDE_VECTOR
 #define INCLUDE_ALGORITHM
 #define INCLUDE_MAP
+#define INCLUDE_MEMORY
 #include "system.h"
 
 // We don't want or need to be aware of networking
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index e7ce40ef464..99f10733d4b 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -206,6 +206,7 @@ Classes used:
 
 #define _DEFAULT_SOURCE 1 /* To get TZ field of struct tm, if available.  */
 #include "config.h"
+#define INCLUDE_MEMORY
 #define INCLUDE_STRING
 #define INCLUDE_VECTOR
 #include "system.h"
diff --git a/libcc1/libcc1plugin.cc b/libcc1/libcc1plugin.cc
index 12ab5a57c8d..bdd0bdabe77 100644
--- a/libcc1/libcc1plugin.cc
+++ b/libcc1/libcc1plugin.cc
@@ -31,6 +31,7 @@
 #undef PACKAGE_TARNAME
 #undef PACKAGE_VERSION
 
+#define INCLUDE_MEMORY
 #include "gcc-plugin.h"
 #include "system.h"
 #include "coretypes.h"
diff --git a/libcc1/libcp1plugin.cc b/libcc1/libcp1plugin.cc
index 83dab7f58b1..e2d5039a0a1 100644
--- a/libcc1/libcp1plugin.cc
+++ b/libcc1/libcp1plugin.cc
@@ -32,6 +32,7 @@
 #undef PACKAGE_TARNAME
 #undef PACKAGE_VERSION
 
+#define INCLUDE_MEMORY
 #include "gcc-plugin.h"
 #include "system.h"
 #include "coretypes.h"
-- 
2.36.1

Re: [rs6000 PATCH] Improve constant integer multiply using rldimi.

[Segher Boessenkool]

Hi!

[Something is wrong with your mail program.  It puts white lines
everywhere, and prefixes a space to the existing white lines.]

On Sun, Jun 26, 2022 at 09:56:07PM +0100, Roger Sayle wrote:
> It turns out this optimization already exists in the form of a combine
> splitter in rs6000.md, but the constraints on combine splitters,
> requiring three of four input instructions (and generating one or two
> output instructions) mean it doesn't get applied as often as it could.

There are no such constraints.  Or, it is more complicated, it depends
on your viewpoint :-)

Combine works on two to four related insns.  It combines those insns to
one (and one only) instruction, hopefully in canonical form.  If that
insn is not recognised by recog combine tries to split up this
instruction.  It has multiple strategies to do that.  One is to try a
define_split, which indeed is only done if there are at least three
input insns.  This is left that way even after 2->2 combines: firstly
because various backends depend on this, but also because it would cause
a lot of code movement without improvement.

> This patch converts the define_split into a define_insn_and_split to
> catch more cases (such as the one above).
>  
> The one bit that's tricky/controversial is the use of RTL's
> nonzero_bits which is accurate during the combine pass when this
> pattern is first recognized, but not as advanced (not kept up to
> date) when this pattern is eventually split.  To support this,
> I've used a "|| reload_completed" idiom.  Does this approach seem
> reasonable? [I've another patch of x86 that uses the same idiom].

No, this does not work.  All passes after combine and until reload has
completed can then get a nonzero_bits that is a subset of the one
combine saw, and thus, the insn no longer matches (as Ke Wen has
encountered.  Often you do not see this in your testing, but almost
always someone will report an ICE within days!)

[Btw, you posted the patch as quoted-printable, which means other
people can not apply the patch.]


Segher

[committed] amdgcn: test global constructors

[Andrew Stubbs]

This setting is way out of date; global constructors have worked on GCN 
for a while now.


Andrewamdgcn: test global constructors

The tests are disabled for historical reasons only.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_global_constructor):
Remove amdgcn.

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 20171f9d985..e481a2a71ff 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -851,7 +851,6 @@ proc check_effective_target_nonlocal_goto {} {
 
 proc check_effective_target_global_constructor {} {
 if { [istarget nvptx-*-*]
-|| [istarget amdgcn-*-*]
 || [istarget bpf-*-*] } {
return 0
 }

[GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

[Qing Zhao via Gcc-patches]

Hi, 

Per our discussion in the bug report, I came up with the following patch:

===

PR101836: Add a new option -fstrict-flex-array[=n]

Add the new option and use it in __builtin_object_size.

Treat the trailing array of a structure as a flexible array member in a
stricter way.  The value of 'n' controls the level of strictness.
'n'=0 is the least strict, all trailing arrays of structures are treated
as flexible array members; This is the default behavior of GCC without specify
this option.
'n'=3 is the strictest, only when the trailing array is declared as a
flexible array member per C99 standard onwards ([]), it is treated as a
flexible array member;
There are two more levels in between 0 and 3, which are provided to support
older codes that use GCC zero-length array extension ([0]), or one-size array as
flexible array member ([1]):
When 'n' is 1, the trailing array is treated as a flexible array member
when it is declared as either [], [0], or [1];
When 'n' is 2, the trailing array is treated as a flexible array member
when it is declared as either [], or [0].

There are other places in GCC that conservatively treat flexible array members.
A follow-up patch will make -ftrict-flex-array option to control all these
places consistently.

Bootstrapped and regression tested on both X86 and aarch64, no issues.

Any comment and suggestion?

Okay for commit to Gcc13?

thanks.

Qing

===

gcc/

   PR tree-optimization/101836
   * common.opt (fstrict-flex-array, fstrict-flex-array=): New options.
   * doc/invoke.texi (-fstrict-flex-array, -fstrict-flex-array=): Document.
   * tree-object-size.cc (addr_object_size): Call is_flexible_array_p to
   check whether an array is a flexible array.
   * tree.cc (special_array_member_type): New routine.
   (is_flexible_array_p): New routine.
   (component_ref_size): Call special_array_member_type to decide the
   type of special array member.
   * tree.h (enum struct special_array_member): Add is_vla, trail_flex.
   (special_array_member_type): New prototype.
   (is_flexible_array_p): New prototype.

gcc/testsuite/

   PR tree-optimization/101836
   * gcc.dg/pr101836.c: New test.
   * gcc.dg/pr101836_1.c: New test.
   * gcc.dg/pr101836_2.c: New test.
   * gcc.dg/pr101836_3.c: New test.
   * gcc.dg/pr101836_4.c: New test.
   * gcc.dg/pr101836_5.c: New test.


The complete patch is:



0001-PR101836-Add-a-new-option-fstrict-flex-array-n.patch
Description: 0001-PR101836-Add-a-new-option-fstrict-flex-array-n.patch

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

[Jonathan Wakely via Gcc-patches]

On Mon, 27 Jun 2022 at 14:32, Jonathan Wakely  wrote:
>
> On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva  wrote:
> >
> > On Jun 27, 2022, Alexandre Oliva  wrote:
> >
> > > It looks like the atp.pathname is missing the nonexistent_path
> > > assigned to variable dir in test_pr99290, so we attempt to open
> > > subdirs thereof as if with openat.
> >
> > This appears to be caused by the early return in fs::_Dir's ctor:
> >
> >   _Dir(const fs::path& p, bool skip_permission_denied, bool nofollow,
> >[[maybe_unused]] bool filename_only, error_code& ec)
> >   : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec)
> >   {
> > #if _GLIBCXX_HAVE_DIRFD // && 0
> > if (filename_only)
> >   return; // Do not store path p when we aren't going to use it.
> > #endif
>
> Yes, this needs a fix. If we don't have openat then we always need a
> full path relative to the CWD, not just a filename relative to a file
> descriptor for the parent directory.
>
> I think we need to store the directory's path if any of dirfd, openat
> or unlinkat is missing.
>
>
> >
> > if (!ec)
> >   path = p;
> >   }
> >
> > but somehow disabling the early return to force the saving of path
> > appears to break copy(): copy.cc's test01() succeeded without the '&& 0'
> > that I've commented-out above, but started failing to create 'to' in the
> > copy at line copy.cc:54 when I put it in to prevent the early return.
> >
> > Does that make any sense to you?
>
> No, I'll have to debug the test. I thought that not storing the path
> was just an optimization (to avoid parsing, decomposing, and
> allocating a path object that we will never use).

If I add the && 0 (so we don't store the path) and bodge
 so that HAVE_OPENAT and HAVE_UNLINKAT are both
undefined, I do not see any new FAIL in the
filesystem/operations/copy.cc tests. filesystem::copy doesn't even use
recursive_directory_iterator, and the filename_only bool should always
be false for non-recursive directory_iterator, and so the early return
should never happen anyway.

(I do have an uncommitted patch to avoid storing that path in more
cases, including for non-recursive directory iterators, but it still
wouldn't be true for filesystem::copy).

Re: Pushed patch to convert DOM from EVRP to Ranger

[Andrew MacLeod via Gcc-patches]

On 6/26/22 11:38, Aldy Hernandez wrote:

Thanks for pushing this.

The patch triggered a (known) regression on
g++.dg/warn/Wstringop-overflow-4.C.  In the original submission I
mentioned I would XFAIL it, but forgot to do so.  I have pushed the
attached patch.

Note that since this was the last user of EVRP, I think it is now safe
to remove its code, along with any options on params.def.  Andrew, are
you OK with removing the legacy evrp code (gimple-ssa-evrp-analyze.*,
and any relevant bits)?  Of course, the core VRP code would still
remain, as VRP1 still uses it.



I think that would be OK.  We have not turned legacy evrp on for 
anything for some time.  And then any leftover bits that cant be removed 
are probably being invoked from range-ops or somewhere else and we can 
relocate them to where they belong and possibly better consolidate 
them.   At least go thru the excercise and produce the patch and see 
what comes out.  Maybe theres a surprise awaiting you :-)   then we can 
further discuss it.


Im currently  working towards turning ranger on by deafult for VRP1, i 
Just  have a few issues to address.   That'll still probably be a few weeks.


Andfrewe



Aldy

On Sun, Jun 26, 2022 at 1:08 AM Jeff Law  wrote:

This is 99.99% Aldy's work.  My only real contribution was twiddling one
MIPS specific test in response to a regression after adding this patch
to my tester.

In simplest terms, this patch converts DOM to use the Ranger
infrastructure rather than the EVRP infrastructure.  I'd basically
approved it before Aldy went on PTO and it's been sitting in my tester
ever since.  So I figured it was time to go ahead and push it.

Jeff

Re: [PATCH][gdb/build] Fix build breaker with --enabled-shared

[Tom de Vries via Gcc-patches]

On 6/27/22 15:03, Tom de Vries wrote:

Hi,

When building gdb with --enabled-shared, I run into:
...
ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
   `.rodata' can not be used when making a shared object; recompile with -fPIC
ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
   `inflateResetKeep' in read-only section `.text'
collect2: error: ld returned 1 exit status
make[3]: *** [libbfd.la] Error 1
...

This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver
build with -fsanitize=thread").

The problem is that a single case statement in configure is shared to handle
special requirements for both the host libiberty and host zlib, which has the
effect that only one is handled.

Fix this by handling libiberty and zlib each in its own case statement.

Build on x86_64-linux, with and without --enable-shared.

OK for gcc trunk?



To fix the buildbot breakage, I already pushed to the gdb repo.

Thanks,
- Tom



[gdb/build] Fix build breaker with --enabled-shared

ChangeLog:

2022-06-27  Tom de Vries  

* configure.ac: Set extra_host_libiberty_configure_flags and
extra_host_zlib_configure_flags in separate case statements.
* configure: Regenerate.

---
  configure| 8 ++--
  configure.ac | 8 ++--
  2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index aac80b88d70..be433ef6d5d 100755
--- a/configure
+++ b/configure
@@ -6962,13 +6962,18 @@ fi
  
  # Sometimes we have special requirements for the host libiberty.

  extra_host_libiberty_configure_flags=
-extra_host_zlib_configure_flags=
  case " $configdirs " in
*" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
  # When these are to be built as shared libraries, the same applies to
  # libiberty.
  extra_host_libiberty_configure_flags=--enable-shared
  ;;
+esac
+
+
+# Sometimes we have special requirements for the host zlib.
+extra_host_zlib_configure_flags=
+case " $configdirs " in
*" bfd "*)
  # When bfd is to be built as a shared library, the same applies to
  # zlib.
@@ -6979,7 +6984,6 @@ case " $configdirs " in
  esac
  
  
-

  # Produce a warning message for the subdirs we can't configure.
  # This isn't especially interesting in the Cygnus tree, but in the individual
  # FSF releases, it's important to let people know when their machine isn't
diff --git a/configure.ac b/configure.ac
index 29f74d10b5a..1651cbf3b02 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2342,13 +2342,18 @@ fi
  
  # Sometimes we have special requirements for the host libiberty.

  extra_host_libiberty_configure_flags=
-extra_host_zlib_configure_flags=
  case " $configdirs " in
*" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
  # When these are to be built as shared libraries, the same applies to
  # libiberty.
  extra_host_libiberty_configure_flags=--enable-shared
  ;;
+esac
+AC_SUBST(extra_host_libiberty_configure_flags)
+
+# Sometimes we have special requirements for the host zlib.
+extra_host_zlib_configure_flags=
+case " $configdirs " in
*" bfd "*)
  # When bfd is to be built as a shared library, the same applies to
  # zlib.
@@ -2357,7 +2362,6 @@ case " $configdirs " in
  fi
  ;;
  esac
-AC_SUBST(extra_host_libiberty_configure_flags)
  AC_SUBST(extra_host_zlib_configure_flags)
  
  # Produce a warning message for the subdirs we can't configure.

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

[Jonathan Wakely via Gcc-patches]

On Mon, 27 Jun 2022 at 14:29, Alexandre Oliva  wrote:
>
> On Jun 23, 2022, Alexandre Oliva  wrote:
>
> > libstdc++: testsuite: conditionalize symlink tests
>
>
> libstdc++: testsuite: conditionalize another symlink test
>
> In the recent patch that introduced NO_SYMLINKS, I missed one of the
> testcases that created symlinks.
>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?

OK.


>
>
>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
> (test06): Don't create symlinks when NO_SYMLINKS is defined.
> ---
>  .../iterators/recursive_directory_iterator.cc  |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git 
> a/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
>  
> b/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
> index e67e2cf38f754..e2f3613a3d07e 100644
> --- 
> a/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
> +++ 
> b/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
> @@ -187,7 +187,7 @@ test05()
>  void
>  test06()
>  {
> -#if !(defined __MINGW32__ || defined __MINGW64__)
> +#ifndef NO_SYMLINKS
>auto p = __gnu_test::nonexistent_path();
>create_directories(p/"d1/d2");
>create_directory_symlink("d1", p/"link");
>
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 
>

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

[Jonathan Wakely via Gcc-patches]

On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva  wrote:
>
> On Jun 27, 2022, Alexandre Oliva  wrote:
>
> > It looks like the atp.pathname is missing the nonexistent_path
> > assigned to variable dir in test_pr99290, so we attempt to open
> > subdirs thereof as if with openat.
>
> This appears to be caused by the early return in fs::_Dir's ctor:
>
>   _Dir(const fs::path& p, bool skip_permission_denied, bool nofollow,
>[[maybe_unused]] bool filename_only, error_code& ec)
>   : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec)
>   {
> #if _GLIBCXX_HAVE_DIRFD // && 0
> if (filename_only)
>   return; // Do not store path p when we aren't going to use it.
> #endif

Yes, this needs a fix. If we don't have openat then we always need a
full path relative to the CWD, not just a filename relative to a file
descriptor for the parent directory.

I think we need to store the directory's path if any of dirfd, openat
or unlinkat is missing.


>
> if (!ec)
>   path = p;
>   }
>
> but somehow disabling the early return to force the saving of path
> appears to break copy(): copy.cc's test01() succeeded without the '&& 0'
> that I've commented-out above, but started failing to create 'to' in the
> copy at line copy.cc:54 when I put it in to prevent the early return.
>
> Does that make any sense to you?

No, I'll have to debug the test. I thought that not storing the path
was just an optimization (to avoid parsing, decomposing, and
allocating a path object that we will never use).

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

[Jakub Jelinek via Gcc-patches]

On Mon, Jun 27, 2022 at 01:56:10PM +0200, Mikael Morin wrote:
> Le 27/06/2022 à 09:54, Jakub Jelinek a écrit :
> > Still, using __float128 when the APIs are declared for __float128 and
> > _Float128 when the APIs are declared for _Float128 can be better for
> > consistency.
> > 
> I agree with that.
> I was implicitly suggesting to change the libquadmath API to use the
> standard syntax and types, with the assumption that it’s an internal thing
> used only by fortran (on the frontend side and on the library side). After
> documenting myself further, it seems that’s a wrong assumption.
> 
> 
> > If HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 stand for
> > _Float128 and libquadmath or *f128 APIs, we'd need some macro
> > to tell which APIs to use, say
> > USE_LIBQUADMATH and USE_IEC_60559.
> 
> That would be my preference, even if we keep both __float128 and _Float128,
> as it avoids exposing the detail of the provider of the math functions in
> many places it’s not needed.
> Half of the changes from your patch have pattern blah__float128 ||
> blah_Float128 or the negation of that, and wouldn’t be needed if the
> *FLOAT128 conditions spanned both __float128 and _Float128 (or libquadmath
> and libc).

Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all
of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal
constants etc. when using libquadmath and f128/F128 otherwise.
This patch also includes the incremental powerpc64le fixes.

Ok if it passes testing?

2022-06-27  Jakub Jelinek  

gcc/fortran/
* gfortran.h (gfc_real_info): Add use_iec_60559 bitfield.
* trans-types.h (gfc_real16_use_iec_60559): Declare.
* trans-types.cc (gfc_real16_use_iec_60559): Define.
(gfc_init_kinds): When building powerpc64le-linux libgfortran
on glibc 2.26 to 2.31, set gfc_real16_use_iec_60559 and
use_iec_60559.
(gfc_build_real_type): Set gfc_real16_use_iec_60559 and use_iec_60559
on glibc 2.26 or later.
* trans-intrinsic.cc (gfc_build_intrinsic_lib_fndecls): Adjust
comment.  Handle gfc_real16_use_iec_60559.
(gfc_get_intrinsic_lib_fndecl): Handle use_iec_60559.
libgfortran/
* configure.ac: Check for strtof128 and strfromf128.
Check for math and complex *f128 functions.  Set
have_iec_60559_libc_support to yes if *f128 support is around, for
--enable-libquadmath-support default to "default" rather than yes if
have_iec_60559_libc_support is yes.
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Test
_Float128/_Complex _Float128 rather than __float128 and
_Complex float __attribute__((mode(TC))).  If libquadmath support
is defaulted and have_iec_60559_libc_support is yes, define and subst
USE_IEC_60559.  Remove unused LIBGFOR_BUILD_QUAD conditional.
* Makefile.am (kinds.h): Pass @USE_IEC_60559@ as an extra
mk-kinds-h.sh argument.
* mk-kinds-h.sh: Accept 4th use_iec_60559 argument.  Use
_Float128/_Complex _Float128 types instead of __float128 and
_Complex float __attribute__((mode(TC))), and if use_iec_60559 is yes,
use f128 suffix instead of q and define GFC_REAL_16_USE_IEC_60559.
* kinds-override.h: Use _Float128/_Complex _Float128 types instead of
__float128 and _Complex float __attribute__((mode(TC))), if
USE_IEC_60559 is defined, use f128 suffixes instead of q and
define GFC_REAL_17_USE_IEC_60559.
* libgfortran.h: Don't include quadmath_weak.h if USE_IEC_60559 is
defined.
(GFC_REAL_16_INFINITY, GFC_REAL_16_QUIET_NAN): Define
for GFC_REAL_16_USE_IEC_60559 differently.
* caf/single.c (convert_type): Use _Float128/_Complex _Float128
instead of __float128 and _Complex float __attribute__((mode(TC))).
For HAVE_GFC_REAL_10 when HAVE_GFC_REAL_16 isn't defined use
_Complex long double instead of long double.
* ieee/issignaling_fallback.h (ieee854_float128_shape_type): Use
_Float128 instead of __float128.
(__issignalingf128): Change argument type to _Float128.
(issignaling): Use _Float128 instead of __float128 in _Generic.
* intrinsics/cshift0.c (cshift0): Use _Float128 instead of __float128
in a comment.  Fix a comment typo, logn double -> long double.
* intrinsics/erfc_scaled.c (_THRESH, _M_2_SQRTPI, _INF, _ERFC, _EXP):
Use different definitions if GFC_REAL_16_USE_IEC_60559.
(_THRESH, _M_2_SQRTPI): Use GFC_REAL_17_LITERAL macro.
(_ERFC, _EXP): Use different definitions if GFC_REAL_17_USE_IEC_60559.
* intrinsics/spread_generic.c (spread, spread_scalar): Use _Float128
instead of __float128 in a comment.  Fix a comment typo,
logn double -> long double.
* intrinsics/trigd.c (ENABLE_SIND, ENABLE_COSD, ENABLE_TAND): Handle
GFC_REAL_16_USE_IEC_60559.
* intrinsics/pack_generic.c (pack): 

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

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Alexandre Oliva  wrote:

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

And then, having enabled pipe(), disabled the internal xfail machinery,
and added -Wl,--gc-sections after -lbsd as recommended, I found that
net/timer/waitable/cons.cc passed; that the other waitable tests failed
to link because of poll(), not pipes; and that the resolver tests failed
for other reasons.

So here's the adjusted patch I'm using now, and that I'll check in
shortly.


libstdc++: xfail experimental/net tests on rtems

Some net/timer/waitable tests fail on rtems because poll() is not
available.

The above, as well as net/internet/resolver/ops tests and
net/timer/waitable/cons.cc, will fail early at runtime unless mkfifo
is enabled in the RTEMS configuration, because the io_context ctor
throws when pipe() fails.

However, even enabling pipes and adjusting the net_ts link command to
use --gc-sections for -lbsd as recommended, both
net/internet/resolver/ops still fail at runtime.

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


for  libstdc++-v3/ChangeLog

* testsuite/lib/dg-options.exp (add_options_for_net_ts):
Add -Wl,--gc-sections for RTEMS targets.
* testsuite/experimental/net/timer/waitable/dest.cc: Link-time
xfail on RTEMS.
* testsuite/experimental/net/timer/waitable/ops.cc: Likewise.
* testsuite/experimental/net/internet/resolver/ops/lookup.cc:
Execution-time xfail on RTEMS.
* testsuite/experimental/net/internet/resolver/ops/reverse.cc:
Likewise.
---
 .../net/internet/resolver/ops/lookup.cc|1 +
 .../net/internet/resolver/ops/reverse.cc   |1 +
 .../experimental/net/timer/waitable/dest.cc|1 +
 .../experimental/net/timer/waitable/ops.cc |1 +
 libstdc++-v3/testsuite/lib/dg-options.exp  |6 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
index eb411dea8369c..0ac9cb3513d7e 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/lookup.cc
@@ -18,6 +18,7 @@
 // { dg-do run { target c++14 } }
 // { dg-require-effective-target net_ts_ip }
 // { dg-add-options net_ts }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
index 361df2676efc8..dfdf855c68cd7 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/resolver/ops/reverse.cc
@@ -18,6 +18,7 @@
 // { dg-do run { target c++14 } }
 // { dg-require-effective-target net_ts_ip }
 // { dg-add-options net_ts }
+// { dg-xfail-run-if "io_context requires a working pipe" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc 
b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
index f571f4a8d861a..384f768c2b56d 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-if "poll not available" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc 
b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
index 97ab629b893a9..815ad71578035 100644
--- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
+++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
@@ -17,6 +17,7 @@
 
 // { dg-do run { target c++14 } }
 // { dg-add-options libatomic }
+// { dg-xfail-if "poll not available" { *-*-rtems* } }
 
 #include 
 #include 
diff --git a/libstdc++-v3/testsuite/lib/dg-options.exp 
b/libstdc++-v3/testsuite/lib/dg-options.exp
index b61c4c0cb8fcd..cc312edc172e4 100644
--- a/libstdc++-v3/testsuite/lib/dg-options.exp
+++ b/libstdc++-v3/testsuite/lib/dg-options.exp
@@ -281,11 +281,7 @@ proc add_options_for_net_ts { flags } {
 if { [istarget *-*-solaris2*] } {
return "$flags -lsocket -lnsl"
 } elseif { [istarget *-*-rtems*] } {
-   # Adding -Wl,--gc-sections would enable a few more tests to
-   # link, but all of them fail at runtime anyway, because the
-   # io_context ctor calls pipe(), which always fails, and thus
-   # the ctor throws a system error.
-   return "$flags -lbsd"
+   return "$flags -lbsd -Wl,--gc-sections"
 }
 return $flags
 }


-- 
Alexandre Oliva, happy 

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

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Alexandre Oliva  wrote:

> libstdc++: testsuite: conditionalize symlink tests


libstdc++: testsuite: conditionalize another symlink test

In the recent patch that introduced NO_SYMLINKS, I missed one of the
testcases that created symlinks.

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



for  libstdc++-v3/ChangeLog

* testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
(test06): Don't create symlinks when NO_SYMLINKS is defined.
---
 .../iterators/recursive_directory_iterator.cc  |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
 
b/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
index e67e2cf38f754..e2f3613a3d07e 100644
--- 
a/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
+++ 
b/libstdc++-v3/testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc
@@ -187,7 +187,7 @@ test05()
 void
 test06()
 {
-#if !(defined __MINGW32__ || defined __MINGW64__)
+#ifndef NO_SYMLINKS
   auto p = __gnu_test::nonexistent_path();
   create_directories(p/"d1/d2");
   create_directory_symlink("d1", p/"link");


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] libstdc++: retry removal of dir entries if dir removal fails

[Alexandre Oliva via Gcc-patches]

On Jun 22, 2022, Jonathan Wakely  wrote:

> I haven't properly reviewed it yet

Nevermind that one, it's broken because I hadn't realized the recursive
iteration.  It fails and throws/errors out when we attempt to __erase a
subdir that wasn't successfully emptied because some of its entries were
skipped.

Here's an improved version that appears to work, despite the few(er)
remaining fails.  I've convinced myself it can't possibly introduce
symlink races because, if it doesn't follow symlinks in the first try,
it won't follow them in retries.  Potential races related with moving
directories into or out of the remove_all root remain.

On POSIX-compliant filesystems, the first name that fails to be removed
is most likely to be the first to be encountered in the retry, so
removal will terminate with the failure immediately.  There's a
potential for retries to end up removing other dirs moved into the
remove_all root, but moving them in while remove_all is still running
may remove them, so I don't see that it changes anything.

On RTEMS, the first name that would have failed to be removed, say
because of permissions, may be skipped by the iterator, so we may
proceed to remove later dir entries under the same parent before failing
to remove the parent and starting a retry.  There may thus be an
unbounded number of retries, one for each subdirectory with more than
one entry in the remove_all tree.  I see two potential ways to avoid
this: (i) call remove_all recursively upon failure to remove an entry,
instead of restarting iteration; or (ii) arrange for
recursive_directory_iterator to rewind a dir from which entries have
been _erase()d before returning to the parent dir.  I have not
implemented either of these alternatives, though.

This one is regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6.  Ok to install?



libstdc++: retry removal of dir entries if dir removal fails

From: Alexandre Oliva 

On some target systems (e.g. rtems6.0), removing directory components
while iterating over directory entries may cause some of the directory
entries to be skipped, which prevents the removal of the parent
directory from succeeding.

Advancing the iterator before removing a member proved not to be
enough, so I've instead arranged for remove_all to retry the removal
of components if the removal of the parent dir fails after removing at
least one entry.  The fail will be permanent only if no components got
removed in the current try.


for  libstdc++-v3/ChangeLog

* src/c++17/fs_ops.cc (remove_all): Retry removal of
directory entries.
---
 libstdc++-v3/src/c++17/fs_ops.cc |   40 ++
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 435368fa5c5ff..de99e02af4c34 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -1286,6 +1286,8 @@ fs::remove_all(const path& p)
 {
   error_code ec;
   uintmax_t count = 0;
+ retry:
+  uintmax_t init_count = count;
   recursive_directory_iterator dir(p, directory_options{64|128}, ec);
   switch (ec.value()) // N.B. assumes ec.category() == std::generic_category()
   {
@@ -1295,7 +1297,16 @@ fs::remove_all(const path& p)
   const recursive_directory_iterator end;
   while (dir != end)
{
- dir.__erase(); // throws on error
+ /* Avoid exceptions if we may retry on fail on systems that
+miss dir entries when removing while iterating.  */
+ if (count > init_count)
+   {
+ dir.__erase();
+ if (ec)
+   goto retry;
+   }
+ else
+   dir.__erase(); // throws on error
  ++count;
}
 }
@@ -1303,7 +1314,7 @@ fs::remove_all(const path& p)
 break;
   case ENOENT:
 // Our work here is done.
-return 0;
+return count;
   case ENOTDIR:
   case ELOOP:
 // Not a directory, will remove below.
@@ -1313,6 +1324,18 @@ fs::remove_all(const path& p)
 _GLIBCXX_THROW_OR_ABORT(filesystem_error("cannot remove all", p, ec));
   }
 
+  if (count > init_count)
+{
+  if (int last = fs::remove(p, ec); !ec)
+   return count + last;
+  else
+   // Some systems seem to skip entries in the dir iteration if
+   // you remove dir entries while iterating, so if we removed
+   // anything in the dir in this round, and failed to remove
+   // the dir (presumably because it wasn't empty), retry.
+   goto retry;
+}
+
   // Remove p itself, which is either a non-directory or is now empty.
   return count + fs::remove(p);
 }
@@ -1321,6 +1344,8 @@ std::uintmax_t
 fs::remove_all(const path& p, error_code& ec)
 {
   uintmax_t count = 0;
+ retry:
+  uintmax_t init_count = count;
   recursive_directory_iterator dir(p, directory_options{64|128}, ec);
   switch (ec.value()) // N.B. assumes ec.category() == std::generic_category()
   {
@@ -1332,7 

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

[Alexandre Oliva via Gcc-patches]

On Jun 27, 2022, Alexandre Oliva  wrote:

> It looks like the atp.pathname is missing the nonexistent_path
> assigned to variable dir in test_pr99290, so we attempt to open
> subdirs thereof as if with openat.

This appears to be caused by the early return in fs::_Dir's ctor:

  _Dir(const fs::path& p, bool skip_permission_denied, bool nofollow,
   [[maybe_unused]] bool filename_only, error_code& ec)
  : _Dir_base(p.c_str(), skip_permission_denied, nofollow, ec)
  {
#if _GLIBCXX_HAVE_DIRFD // && 0
if (filename_only)
  return; // Do not store path p when we aren't going to use it.
#endif

if (!ec)
  path = p;
  }

but somehow disabling the early return to force the saving of path
appears to break copy(): copy.cc's test01() succeeded without the '&& 0'
that I've commented-out above, but started failing to create 'to' in the
copy at line copy.cc:54 when I put it in to prevent the early return.

Does that make any sense to you?

-- 
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: PING^1 [PATCH] x86: Skip ENDBR when emitting direct call/jmp to local function

[H.J. Lu via Gcc-patches]

On Sun, Jun 26, 2022 at 10:50 PM Hongtao Liu  wrote:
>
> On Tue, Jun 21, 2022 at 3:50 AM Uros Bizjak via Gcc-patches
>  wrote:
> >
> > On Mon, Jun 20, 2022 at 8:14 PM H.J. Lu  wrote:
> > >
> > > On Tue, May 10, 2022 at 9:25 AM H.J. Lu  wrote:
> > > >
> > > > Mark a function with SYMBOL_FLAG_FUNCTION_ENDBR when inserting ENDBR at
> > > > function entry.  Skip the 4-byte ENDBR when emitting a direct call/jmp
> > > > to a local function with ENDBR at function entry.
> > > >
> > > > This has been tested on Linux kernel.
> > > >
> > > > gcc/
> > > >
> > > > PR target/102953
> > > > * config/i386/i386-features.cc
> > > > (rest_of_insert_endbr_and_patchable_area): Set
> > > > SYMBOL_FLAG_FUNCTION_ENDBR when inserting ENDBR.
> > > > * config/i386/i386.cc (ix86_print_operand): Skip the 4-byte 
> > > > ENDBR
> > > > when calling the local function with ENDBR at function entry.
> > > > * config/i386/i386.h (SYMBOL_FLAG_FUNCTION_ENDBR): New.
> > > > (SYMBOL_FLAG_FUNCTION_ENDBR_P): Likewise.
> > > >
> > > > gcc/testsuite/
> > > >
> > > > PR target/102953
> > > > * gcc.target/i386/pr102953-1.c: New test.
> > > > * gcc.target/i386/pr102953-2.c: Likewise.
> The patch looks good to me.
> For direct call, endbr64 should not be used as a marker, right?

Correct.

> > > > ---
> > > >  gcc/config/i386/i386-features.cc   |  2 ++
> > > >  gcc/config/i386/i386.cc| 11 +++-
> > > >  gcc/config/i386/i386.h |  5 
> > > >  gcc/testsuite/gcc.target/i386/pr102953-1.c | 25 ++
> > > >  gcc/testsuite/gcc.target/i386/pr102953-2.c | 30 ++
> > > >  5 files changed, 72 insertions(+), 1 deletion(-)
> > > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-1.c
> > > >  create mode 100644 gcc/testsuite/gcc.target/i386/pr102953-2.c
> > > >
> > > > diff --git a/gcc/config/i386/i386-features.cc 
> > > > b/gcc/config/i386/i386-features.cc
> > > > index 6fe41c3c24f..3ca1131ed59 100644
> > > > --- a/gcc/config/i386/i386-features.cc
> > > > +++ b/gcc/config/i386/i386-features.cc
> > > > @@ -1979,6 +1979,8 @@ rest_of_insert_endbr_and_patchable_area (bool 
> > > > need_endbr,
> > > >   || (TARGET_DLLIMPORT_DECL_ATTRIBUTES
> > > >   && DECL_DLLIMPORT_P (cfun->decl
> > > > {
> > > > + rtx symbol = XEXP (DECL_RTL (cfun->decl), 0);
> > > > + SYMBOL_REF_FLAGS (symbol) |= SYMBOL_FLAG_FUNCTION_ENDBR;
> > > >   if (crtl->profile && flag_fentry)
> > > > {
> > > >   /* Queue ENDBR insertion to x86_function_profiler.
> > > > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > > > index 86752a6516a..ad1de239bef 100644
> > > > --- a/gcc/config/i386/i386.cc
> > > > +++ b/gcc/config/i386/i386.cc
> > > > @@ -13787,7 +13787,16 @@ ix86_print_operand (FILE *file, rtx x, int 
> > > > code)
> > > >else if (flag_pic || MACHOPIC_INDIRECT)
> > > > output_pic_addr_const (file, x, code);
> > > >else
> > > > -   output_addr_const (file, x);
> > > > +   {
> > > > + /* Skip ENDBR when emitting a direct call/jmp to a local
> > > > +function with ENDBR at function entry.  */
> > > > + if (code == 'P'
> > > > + && GET_CODE (x) == SYMBOL_REF
> > > > + && SYMBOL_REF_LOCAL_P (x)
> > > > + && SYMBOL_FLAG_FUNCTION_ENDBR_P (x))
> > > > +   x = gen_rtx_PLUS (Pmode, x, GEN_INT (4));
> > > > + output_addr_const (file, x);
> > > > +   }
> > > >  }
> > > >  }
> > > >
> > > > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> > > > index 363082ba47b..7a6317fea57 100644
> > > > --- a/gcc/config/i386/i386.h
> > > > +++ b/gcc/config/i386/i386.h
> > > > @@ -2792,6 +2792,11 @@ extern GTY(()) tree ms_va_list_type_node;
> > > >  #define SYMBOL_REF_STUBVAR_P(X) \
> > > > ((SYMBOL_REF_FLAGS (X) & SYMBOL_FLAG_STUBVAR) != 0)
> > > >
> > > > +/* Flag to mark a function with ENDBR at entry.  */
> > > > +#define SYMBOL_FLAG_FUNCTION_ENDBR (SYMBOL_FLAG_MACH_DEP << 5)
> > > > +#define SYMBOL_FLAG_FUNCTION_ENDBR_P(X) \
> > > > +   ((SYMBOL_REF_FLAGS (X) & SYMBOL_FLAG_FUNCTION_ENDBR) != 0)
> > > > +
> > > >  extern void debug_ready_dispatch (void);
> > > >  extern void debug_dispatch_window (int);
> > > >
> > > > diff --git a/gcc/testsuite/gcc.target/i386/pr102953-1.c 
> > > > b/gcc/testsuite/gcc.target/i386/pr102953-1.c
> > > > new file mode 100644
> > > > index 000..2afad391baf
> > > > --- /dev/null
> > > > +++ b/gcc/testsuite/gcc.target/i386/pr102953-1.c
> > > > @@ -0,0 +1,25 @@
> > > > +/* { dg-do compile { target { ! *-*-darwin* } } } */
> > > > +/* { dg-options "-O2 -fno-pic -fplt -fcf-protection" } */
> > > > +
> > > > +extern int func (int);
> > > > +
> > > > +extern int i;
> > > > +
> > > > +__attribute__ ((noclone, noinline, noipa))
> > > > +static int
> > > > +bar 

[PATCH][gdb/build] Fix build breaker with --enabled-shared

[Tom de Vries via Gcc-patches]

Hi,

When building gdb with --enabled-shared, I run into:
...
ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
  `.rodata' can not be used when making a shared object; recompile with -fPIC
ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
  `inflateResetKeep' in read-only section `.text'
collect2: error: ld returned 1 exit status
make[3]: *** [libbfd.la] Error 1
...

This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver
build with -fsanitize=thread").

The problem is that a single case statement in configure is shared to handle
special requirements for both the host libiberty and host zlib, which has the
effect that only one is handled.

Fix this by handling libiberty and zlib each in its own case statement.

Build on x86_64-linux, with and without --enable-shared.

OK for gcc trunk?

Thanks,
- Tom

[gdb/build] Fix build breaker with --enabled-shared

ChangeLog:

2022-06-27  Tom de Vries  

* configure.ac: Set extra_host_libiberty_configure_flags and
extra_host_zlib_configure_flags in separate case statements.
* configure: Regenerate.

---
 configure| 8 ++--
 configure.ac | 8 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index aac80b88d70..be433ef6d5d 100755
--- a/configure
+++ b/configure
@@ -6962,13 +6962,18 @@ fi
 
 # Sometimes we have special requirements for the host libiberty.
 extra_host_libiberty_configure_flags=
-extra_host_zlib_configure_flags=
 case " $configdirs " in
   *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
 # When these are to be built as shared libraries, the same applies to
 # libiberty.
 extra_host_libiberty_configure_flags=--enable-shared
 ;;
+esac
+
+
+# Sometimes we have special requirements for the host zlib.
+extra_host_zlib_configure_flags=
+case " $configdirs " in
   *" bfd "*)
 # When bfd is to be built as a shared library, the same applies to
 # zlib.
@@ -6979,7 +6984,6 @@ case " $configdirs " in
 esac
 
 
-
 # Produce a warning message for the subdirs we can't configure.
 # This isn't especially interesting in the Cygnus tree, but in the individual
 # FSF releases, it's important to let people know when their machine isn't
diff --git a/configure.ac b/configure.ac
index 29f74d10b5a..1651cbf3b02 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2342,13 +2342,18 @@ fi
 
 # Sometimes we have special requirements for the host libiberty.
 extra_host_libiberty_configure_flags=
-extra_host_zlib_configure_flags=
 case " $configdirs " in
   *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
 # When these are to be built as shared libraries, the same applies to
 # libiberty.
 extra_host_libiberty_configure_flags=--enable-shared
 ;;
+esac
+AC_SUBST(extra_host_libiberty_configure_flags)
+
+# Sometimes we have special requirements for the host zlib.
+extra_host_zlib_configure_flags=
+case " $configdirs " in
   *" bfd "*)
 # When bfd is to be built as a shared library, the same applies to
 # zlib.
@@ -2357,7 +2362,6 @@ case " $configdirs " in
 fi
 ;;
 esac
-AC_SUBST(extra_host_libiberty_configure_flags)
 AC_SUBST(extra_host_zlib_configure_flags)
 
 # Produce a warning message for the subdirs we can't configure.

[committed] amdgcn: remove obsolete assembler workarounds

[Andrew Stubbs]

This patch removed some workarounds that were required for old versions 
of the LLVM assembler.  The minimum supported version is now 13.0.1 so 
the workarounds are no longer needed.


Andrewamdgcn: remove obsolete assembler workarounds

This nonsense is no longer required, now that the minimum supported
assembler version is LLVM 13.0.1.

gcc/ChangeLog:

* config/gcn/gcn.md (*movbi): Remove assembler bug workarounds.
(jump): Likewise.
(movdi_symbol_save_scc): Likewise.

diff --git a/gcc/config/gcn/gcn.md b/gcc/config/gcn/gcn.md
index 53e846e15d1..033c1708e88 100644
--- a/gcc/config/gcn/gcn.md
+++ b/gcc/config/gcn/gcn.md
@@ -481,14 +481,7 @@ (define_insn "*movbi"
we emit bytes directly as a workaround.  */
 switch (which_alternative) {
 case 0:
-  if (REG_P (operands[1]) && REGNO (operands[1]) == SCC_REG)
-   return "; s_mov_b32\t%0,%1 is not supported by the assembler.\;"
-  ".byte\t0xfd\;"
-  ".byte\t0x0\;"
-  ".byte\t0x80|%R0\;"
-  ".byte\t0xbe";
-  else
-   return "s_mov_b32\t%0, %1";
+  return "s_mov_b32\t%0, %1";
 case 1:
   if (REG_P (operands[1]) && REGNO (operands[1]) == SCC_REG)
return "; v_mov_b32\t%0, %1\;"
@@ -505,16 +498,8 @@ (define_insn "*movbi"
 case 4:
   return "v_cmp_ne_u32\tvcc, 0, %1";
 case 5:
-  if (REGNO (operands[1]) == SCC_REG)
-   return "; s_mov_b32\t%0, %1 is not supported by the assembler.\;"
-  ".byte\t0xfd\;"
-  ".byte\t0x0\;"
-  ".byte\t0xea\;"
-  ".byte\t0xbe\;"
-  "s_mov_b32\tvcc_hi, 0";
-  else
-   return "s_mov_b32\tvcc_lo, %1\;"
-  "s_mov_b32\tvcc_hi, 0";
+  return "s_mov_b32\tvcc_lo, %1\;"
+"s_mov_b32\tvcc_hi, 0";
 case 6:
   return "s_load_dword\t%0, %A1\;s_waitcnt\tlgkmcnt(0)";
 case 7:
@@ -739,8 +724,7 @@ (define_insn "jump"
   return "s_branch\t%0";
 else
   /* !!! This sequence clobbers EXEC_SAVE_REG and CC_SAVE_REG.  */
-  return "; s_mov_b32\ts22, scc is not supported by the assembler.\;"
-".long\t0xbe9600fd\;"
+  return "s_mov_b32\ts22, scc\;"
 "s_getpc_b64\ts[20:21]\;"
 "s_add_u32\ts20, s20, %0@rel32@lo+4\;"
 "s_addc_u32\ts21, s21, %0@rel32@hi+4\;"
@@ -801,11 +785,7 @@ (define_insn "cjump"
  }
else
  return "s_cbranch%c1\t.Lskip%=\;"
-"; s_mov_b32\ts22, scc is not supported by the assembler.\;"
-".byte\t0xfd\;"
-".byte\t0x0\;"
-".byte\t0x80|22\;"
-".byte\t0xbe\;"
+"s_mov_b32\ts22, scc\;"
 "s_getpc_b64\ts[20:21]\;"
 "s_add_u32\ts20, s20, %0@rel32@lo+4\;"
 "s_addc_u32\ts21, s21, %0@rel32@hi+4\;"
@@ -890,8 +870,7 @@ (define_insn "movdi_symbol_save_scc"
 
 if (SYMBOL_REF_P (operands[1])
&& SYMBOL_REF_WEAK (operands[1]))
-   return "; s_mov_b32\ts22, scc is not supported by the assembler.\;"
-  ".long\t0xbe9600fd\;"
+   return "s_mov_b32\ts22, scc\;"
   "s_getpc_b64\t%0\;"
   "s_add_u32\t%L0, %L0, %1@gotpcrel32@lo+4\;"
   "s_addc_u32\t%H0, %H0, %1@gotpcrel32@hi+4\;"
@@ -899,8 +878,7 @@ (define_insn "movdi_symbol_save_scc"
   "s_cmpk_lg_u32\ts22, 0\;"
   "s_waitcnt\tlgkmcnt(0)";
 
-return "; s_mov_b32\ts22, scc is not supported by the assembler.\;"
-  ".long\t0xbe9600fd\;"
+return "s_mov_b32\ts22, scc\;"
   "s_getpc_b64\t%0\;"
   "s_add_u32\t%L0, %L0, %1@rel32@lo+4\;"
   "s_addc_u32\t%H0, %H0, %1@rel32@hi+4\;"

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

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Jonathan Wakely  wrote:

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

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

*nod*, I've amended your patch in my local tree to reverse them both.

> This passes tests on x86_64-linux.

Have you by any chance tried it while forcing libstdc++ not to use
openat?

I'm debugging 27_io/.../copy.cc on rtems with a fixed remove_all (there
were bugs in the previous version I posted), and hitting an exception
within the very first call of dir.__erase() in the remove_all at the end
of test_pr99290, after an attempt to open "source" fails.  It looks like
the atp.pathname is missing the nonexistent_path assigned to variable
dir in test_pr99290, so we attempt to open subdirs thereof as if with
openat.

-- 
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] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+

[Mikael Morin]

Le 27/06/2022 à 09:54, Jakub Jelinek a écrit :

Still, using __float128 when the APIs are declared for __float128 and
_Float128 when the APIs are declared for _Float128 can be better for
consistency.


I agree with that.
I was implicitly suggesting to change the libquadmath API to use the 
standard syntax and types, with the assumption that it’s an internal 
thing used only by fortran (on the frontend side and on the library 
side). After documenting myself further, it seems that’s a wrong 
assumption.




If HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 stand for
_Float128 and libquadmath or *f128 APIs, we'd need some macro
to tell which APIs to use, say
USE_LIBQUADMATH and USE_IEC_60559.


That would be my preference, even if we keep both __float128 and 
_Float128, as it avoids exposing the detail of the provider of the math 
functions in many places it’s not needed.
Half of the changes from your patch have pattern blah__float128 || 
blah_Float128 or the negation of that, and wouldn’t be needed if the 
*FLOAT128 conditions spanned both __float128 and _Float128 (or 
libquadmath and libc).

[OG11][committed] Fix gfortran.dg/gomp/affinity-clause-1.f90 / Fix gfortran.dg/gomp/num-teams-2.f90

[Tobias Burnus]

Committed to fix OG11-only fails. For details, see commit log + patch
(attached) – with two commits.

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
commit 88c73dbc2de129c5d4f1af95c6e5433447d847a2
Author: Tobias Burnus 
Date:   Mon Jun 27 13:44:36 2022 +0200

Fix gfortran.dg/gomp/affinity-clause-1.f90

The patch
[OG11][committed][PATCH 01/22] Fortran: delinearize multi-dimensional array accesses
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584716.html
OG11 commit e208eefbaa3f9f590171fce79c7366636770b348 causes a different
dump - update the testcase accordingly.

gcc/testsuite/
* gfortran.dg/gomp/affinity-clause-1.f90: Fix scan-tree-dump-times.
---
 gcc/testsuite/gfortran.dg/gomp/affinity-clause-1.f90 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gfortran.dg/gomp/affinity-clause-1.f90 b/gcc/testsuite/gfortran.dg/gomp/affinity-clause-1.f90
index 08c7740cf0d..9e70bd769d4 100644
--- a/gcc/testsuite/gfortran.dg/gomp/affinity-clause-1.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/affinity-clause-1.f90
@@ -22,7 +22,7 @@ end
 
 ! { dg-final { scan-tree-dump-times "D\\.\[0-9\]+ = .integer.kind=4.. __builtin_cosf ..real.kind=4.. a \\+ 1.0e\\+0\\);" 2 "original" } }
 
-! { dg-final { scan-tree-dump-times "#pragma omp task affinity\\(iterator\\(integer\\(kind=4\\) jj=2:5:2, integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):b\\\[.* ? \\+ -1\\\]\\) affinity\\(iterator\\(integer\\(kind=4\\) jj=2:5:2, integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):d\\\[\\(.*jj \\* 5 \\+ .* ?\\) \\+ -6\\\]\\)" 1 "original" } }
+! { dg-final { scan-tree-dump-times "#pragma omp task affinity\\(iterator\\(integer\\(kind=4\\) jj=2:5:2, integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):b\\\[.* ? \\+ -1\\\]\\) affinity\\(iterator\\(integer\\(kind=4\\) jj=2:5:2, integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):\\(\\(integer\\(kind=4\\)\\\[1:5\\\]\\\[1:5\\\]\\) d\\)\\\[\[^ \]* *jj\\\]{lb: 1 sz: 20}\\\[\[^ \]* *i\\\]{lb: 1 sz: 4}\\)" 1 "original" } }
 
 ! { dg final { scan-tree-dump-times "#pragma omp task affinity\\(iterator\\(integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):b\\\[\\(.* ? \\+ -1\\\]\\) affinity\\(iterator\\(integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):d\\\[\\(\\(integer\\(kind=8\\)\\) i \\+ -1\\) \\* 6\\\]\\)"  1 "original" } }
 

commit 1cbfde1cc2ce51488808d068a1afa3e5581b709c
Author: Tobias Burnus 
Date:   Mon Jun 27 13:26:43 2022 +0200

Fix gfortran.dg/gomp/num-teams-2.f90

OG11 contrary to mainline issues an error for resolve_positive_int_expr
(-> OG11 commit a14b3f29681da1d2465e15f98b8cf8d5c64a2c3c). Update
testcase accordingly.

gcc/testsuite/
* gfortran.dg/gomp/num-teams-2.f90: Use dg-error not dg-warning.
---
 gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90 | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90 b/gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90
index e7814a11a5a..f3031481d4a 100644
--- a/gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/num-teams-2.f90
@@ -9,13 +9,13 @@ subroutine foo (i)
   !$omp teams num_teams (6 : 4)		! { dg-warning "NUM_TEAMS lower bound at .1. larger than upper bound at .2." }
   !$omp end teams
 
-  !$omp teams num_teams (-7)		! { dg-warning "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
+  !$omp teams num_teams (-7)		! { dg-error "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
   !$omp end teams
 
-  !$omp teams num_teams (i : -7)		! { dg-warning "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
+  !$omp teams num_teams (i : -7)		! { dg-error "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
   !$omp end teams
 
-  !$omp teams num_teams (-7 : 8)		! { dg-warning "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
+  !$omp teams num_teams (-7 : 8)		! { dg-error "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
   !$omp end teams
 end
 
@@ -25,13 +25,13 @@ subroutine bar (i)
   !$omp target teams num_teams (6 : 4)	! { dg-warning "NUM_TEAMS lower bound at .1. larger than upper bound at .2." }
   !$omp end target teams
 
-  !$omp target teams num_teams (-7)	! { dg-warning "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
+  !$omp target teams num_teams (-7)	! { dg-error "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
   !$omp end target teams
 
-  !$omp target teams num_teams (i : -7)	! { dg-warning "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
+  !$omp target teams num_teams (i : -7)	! { dg-error "INTEGER expression of NUM_TEAMS clause at .1. must be positive" }
   !$omp end target teams
 
-  !$omp target 

Re: [PATCH] libstdc++: testsuite: require cmath for exp simd

[Jonathan Wakely via Gcc-patches]

On Tue, 21 Jun 2022 at 06:38, Alexandre Oliva via Libstdc++
 wrote:
>
>
> simd_math.h assumes declarations for many C99 functions to be present,
> that libstdc++ doesn't add to target systems that don't have them in
> the C library.
>
> Add the C99 math requirement to tests for simd features, so that they
> don't fail because of limitations of the target C library.
>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?

OK

Re: [PATCH] libstdc++: testsuite: use cmath long double overloads

[Jonathan Wakely via Gcc-patches]

On Tue, 21 Jun 2022 at 06:39, Alexandre Oliva via Libstdc++
 wrote:
>
>
> In case we need to supplement the C standard library with additional
> definitions for float and long double, the declarations expected to be
> in the C headers may not be there.  Rely on the cmath overloads
> instead.
>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?

OK


>
>
> for  libstdc++-v3/ChangeLog
>
> * testsuite/20_util/to_chars/long_double.cc: Use cmath
> long double overloads for nexttoward and ldexp.
> ---
>  .../testsuite/20_util/to_chars/long_double.cc  |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc 
> b/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
> index 0b1c2c2936fdc..498388110b179 100644
> --- a/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
> +++ b/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
> @@ -54,11 +54,11 @@ namespace detail
>  {
>long double
>nextupl(long double x)
> -  { return nexttowardl(x, numeric_limits::infinity()); }
> +  { return nexttoward(x, numeric_limits::infinity()); }
>
>long double
>nextdownl(long double x)
> -  { return nexttowardl(x, -numeric_limits::infinity()); }
> +  { return nexttoward(x, -numeric_limits::infinity()); }
>  }
>
>  // The long double overloads of std::to_chars currently just go through 
> printf
> @@ -138,7 +138,7 @@ test01()
>for (int exponent : {-11000, -3000, -300, -50, -7, 0, 7, 50, 300, 3000, 
> 11000})
>  for (long double testcase : hex_testcases)
>{
> -   testcase = ldexpl(testcase, exponent);
> +   testcase = ldexp(testcase, exponent);
> if (testcase == 0.0L || isinf(testcase))
>   continue;
>
>
> --
> 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] testsuite: Fix up pr106070.c test [PR106070]

[Richard Biener via Gcc-patches]

On Mon, 27 Jun 2022, Jakub Jelinek wrote:

> Hi!
> 
> The test FAILs on 32-bit targets, because when unsigned long
> is 32-bit, (unsigned long) -1 isn't 0x.
> The options to fix this would be either using -1UL, or switch
> to unsigned long long and using -1ULL, I chose the latter because
> the test then FAILs in r13-1242 even on 32-bit targets.
> And while at it, some deobfuscation and formatting tweaks.
> 
> Tested on x86_64-linux with -m32/-m64 with a week old gcc (where it
> FAILs now on both) and current gcc (where it succeeds), ok for trunk?

OK.

Thanks,
Richard.

> 2022-06-27  Jakub Jelinek  
> 
>   PR tree-optimization/106070
>   * gcc.dg/torture/pr106070.c: Use unsigned long long instead of
>   unsigned long and -1ULL instead of 0x, deobcuscate
>   and improve formatting.
> 
> --- gcc/testsuite/gcc.dg/torture/pr106070.c.jj2022-06-26 
> 23:11:16.120254567 +0200
> +++ gcc/testsuite/gcc.dg/torture/pr106070.c   2022-06-27 11:30:02.475765731 
> +0200
> @@ -1,20 +1,22 @@
>  /* { 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;
> -}
> +unsigned int a = 1;
> +int b = -1;
> +int c = 4;
> +unsigned long long d;
>  
> -void test();
> +void __attribute__((noipa))
> +test (void)
> +{
> +  for (int i = 0; i < c; i += 2)
> +d = a != (int) b ? (unsigned long long) b : (unsigned long long) a;
> +}
>  
> -int main()
> +int
> +main ()
>  {
> -  test();
> -  if (arr_252 != 0x)
> -__builtin_abort();
> +  test ();
> +  if (d != -1ULL)
> +__builtin_abort ();
>return 0;
>  }
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstra

Re: [PATCH] libstdc++: testsuite: require cmath for exp simd

[Alexandre Oliva via Gcc-patches]

On Jun 21, 2022, Alexandre Oliva  wrote:

>   * testsuite/experimental/simd/standard_abi_usable.cc: Require
>   cmath support.
>   * testsuite/experimental/simd/standard_abi_usable_2.cc:
>   Likewise.

Ping?

https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596920.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] libstdc++-v3: testsuite: complex proj requirements

[Jonathan Wakely via Gcc-patches]

On Mon, 27 Jun 2022 at 11:09, Alexandre Oliva via Libstdc++
 wrote:
>
> On Jun 21, 2022, Alexandre Oliva  wrote:
>
> >   * testsuite/26_numerics/complex/proj.cc: Skip test in the
> >   circumstances in which the implementation of proj is known to
> >   be broken.
>
> Ping?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596922.html
>
> (I've dropped the '-v3' from the summary line after noticing it)

OK


>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

Re: [PATCH] libstdc++: testsuite: use cmath long double overloads

[Alexandre Oliva via Gcc-patches]

On Jun 21, 2022, Alexandre Oliva  wrote:

>   * testsuite/20_util/to_chars/long_double.cc: Use cmath
>   long double overloads for nexttoward and ldexp.

Ping?

https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596921.html

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

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

[Jonathan Wakely via Gcc-patches]

On Mon, 27 Jun 2022 at 10:32, Alexandre Oliva  wrote:
>
> On Jun 23, 2022, Jonathan Wakely  wrote:
>
> > The attached makes this a bit more efficient, and makes more of the
> > code common to the mkstemp and non-mkstmp branches. I'll wait to hear
> > back from you before pushing it (since it has Joel's name on the
> > patch).
>
> Thanks, I've given it a spin, both trunk and gcc-11, and I confirm it
> works for us.


I've pushed it to trunk now.

[committed] libstdc++: testsuite: Add missing header

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* testsuite/ext/mt_allocator/22309_thread.cc: Include .
---
 libstdc++-v3/testsuite/ext/mt_allocator/22309_thread.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libstdc++-v3/testsuite/ext/mt_allocator/22309_thread.cc 
b/libstdc++-v3/testsuite/ext/mt_allocator/22309_thread.cc
index 2d94ea3a111..99cbb0ffbb8 100644
--- a/libstdc++-v3/testsuite/ext/mt_allocator/22309_thread.cc
+++ b/libstdc++-v3/testsuite/ext/mt_allocator/22309_thread.cc
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void
 check_dlopen(void*& h)
-- 
2.36.1

[committed] libstdc++: testsuite: avoid predicable mkstemp

[Jonathan Wakely via Gcc-patches]

From: Joel Brobecker 

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

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

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

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

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

Co-authored-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

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

diff --git a/libstdc++-v3/testsuite/util/testsuite_fs.h 
b/libstdc++-v3/testsuite/util/testsuite_fs.h
index 29d0b029b75..908fcdbcaee 100644
--- a/libstdc++-v3/testsuite/util/testsuite_fs.h
+++ b/libstdc++-v3/testsuite/util/testsuite_fs.h
@@ -32,14 +32,14 @@ namespace test_fs = std::experimental::filesystem;
 #endif
 #include 
 #include 
+#include// std::random_device
 #include 
+#include 
 #include 
 #include  // unlink, close, getpid, geteuid
 
 #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200112L
 #include  // mkstemp
-#else
-#include// std::random_device
 #endif
 
 #ifndef _GLIBCXX_HAVE_SYMLINK
@@ -123,32 +123,51 @@ namespace __gnu_test
 if (pos != file.npos)
   file.erase(0, pos+1);
 
+file.reserve(file.size() + 40);
+file.insert(0, "filesystem-test.");
+
+// A counter, starting from a random value, to be included as part
+// of the filename being returned, and incremented each time
+// this function is used.  It allows us to ensure that two calls
+// to this function can never return the same filename, something
+// testcases do when they need multiple non-existent filenames
+// for their purposes.
+static unsigned counter = std::random_device{}();
+file += '.';
+file += std::to_string(counter++);
+file += '.';
+
 test_fs::path p;
 #if defined(_GNU_SOURCE) || _XOPEN_SOURCE >= 500 || _POSIX_C_SOURCE >= 200112L
-char tmp[] = "filesystem-test.XX";
-int fd = ::mkstemp(tmp);
+
+// Use mkstemp to determine the name of a file which does not exist yet.
+//
+// Note that we have seen on some systems (such as RTEMS, for instance)
+// that mkstemp behaves very predictably, causing it to always try
+// the same sequence of file names.  In other words, if we call mkstemp
+// with a pattern, delete the file it created (which is what we do, here),
+// and call mkstemp with the same pattern again, it returns the same
+// filename once more.  While most implementations introduce a degree
+// of randomness, it is not mandated by the standard, and this is why
+// we also include a counter in the template passed to mkstemp.
+file += "XX";
+int fd = ::mkstemp([0]);
 if (fd == -1)
   throw test_fs::filesystem_error("mkstemp failed",
  std::error_code(errno, std::generic_category()));
-::unlink(tmp);
+::unlink(file.c_str());
 ::close(fd);
-if (!file.empty())
-  file.insert(0, 1, '-');
-file.insert(0, tmp);
-p = file;
+p = std::move(file);
 #else
 if (file.length() > 64)
   file.resize(64);
-char buf[128];
-static unsigned counter = std::random_device{}();
-#if _GLIBCXX_USE_C99_STDIO
-std::snprintf(buf, 128,
-#else
-std::sprintf(buf,
-#endif
-  "filesystem-test.%u.%lu-%s", counter++, (unsigned long) ::getpid(),
-  file.c_str());
-p = buf;
+// The combination of random counter and PID should be unique for a given
+// run of the testsuite.
+file += std::to_string(::getpid());
+p = std::move(file);
+if (test_fs::exists(p))
+  throw test_fs::filesystem_error("Failed to generate unique pathname", p,
+ std::make_error_code(std::errc::file_exists));
 #endif
 return p;
   }
-- 
2.36.1

[committed] libstdc++: Make std::move_only_function never valueless in std::variant

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

This is not suitable to backport, as it affects the ABI of std::variant
and so isn't appropriate for a release branch.

libstdc++-v3/ChangeLog:

* include/bits/move_only_function.h (_Never_valueless_alt):
Define partial specialization for std::move_only_function.
---
 libstdc++-v3/include/bits/move_only_function.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/libstdc++-v3/include/bits/move_only_function.h 
b/libstdc++-v3/include/bits/move_only_function.h
index f96552a7c89..71d52074978 100644
--- a/libstdc++-v3/include/bits/move_only_function.h
+++ b/libstdc++-v3/include/bits/move_only_function.h
@@ -183,6 +183,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 constexpr bool __is_move_only_function_v> = true;
   /// @endcond
 
+  namespace __detail::__variant
+  {
+template struct _Never_valueless_alt; // see 
+
+// Provide the strong exception-safety guarantee when emplacing a
+// move_only_function into a variant.
+template
+  struct _Never_valueless_alt>
+  : true_type
+  { };
+  }  // namespace __detail::__variant
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 
-- 
2.36.1

[committed] libstdc++: Simplify std::variant construction using variable templates

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/std/variant (_Build_FUN::_S_fun): Define fallback case
as deleted.
(__accepted_index, _Extra_visit_slot_needed): Replace class
templates with variable templates.
---
 libstdc++-v3/include/std/variant | 43 
 1 file changed, 21 insertions(+), 22 deletions(-)

diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
index c5f25ef6b47..5ff1e3edcdf 100644
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -764,7 +764,7 @@ namespace __variant
 {
   // This function means 'using _Build_FUN::_S_fun;' is valid,
   // but only static functions will be considered in the call below.
-  void _S_fun();
+  void _S_fun() = delete;
 };
 
   // "... for which Ti x[] = {std::forward(t)}; is well-formed."
@@ -795,29 +795,28 @@ namespace __variant
 
   // The index selected for FUN(std::forward(t)), or variant_npos if none.
   template
-struct __accepted_index
-: integral_constant
-{ };
+inline constexpr size_t
+__accepted_index = variant_npos;
 
   template
-struct __accepted_index<_Tp, _Variant, void_t<_FUN_type<_Tp, _Variant>>>
-: _FUN_type<_Tp, _Variant>
-{ };
+inline constexpr size_t
+__accepted_index<_Tp, _Variant, void_t<_FUN_type<_Tp, _Variant>>>
+  = _FUN_type<_Tp, _Variant>::value;
 
-  template 
-struct _Extra_visit_slot_needed
-{
-  template  struct _Variant_never_valueless;
+  template>
+inline constexpr bool
+__extra_visit_slot_needed = false;
 
-  template 
-   struct _Variant_never_valueless>
-   : bool_constant<__variant::__never_valueless<_Types...>()> {};
+  template
+inline constexpr bool
+__extra_visit_slot_needed<__variant_cookie, _Var, variant<_Types...>>
+  = !__variant::__never_valueless<_Types...>();
 
-  static constexpr bool value =
-   (is_same_v<_Maybe_variant_cookie, __variant_cookie>
-|| is_same_v<_Maybe_variant_cookie, __variant_idx_cookie>)
-   && !_Variant_never_valueless<__remove_cvref_t<_Variant>>::value;
-};
+  template
+inline constexpr bool
+__extra_visit_slot_needed<__variant_idx_cookie, _Var, variant<_Types...>>
+  = !__variant::__never_valueless<_Types...>();
 
   // Used for storing a multi-dimensional vtable.
   template
@@ -874,7 +873,7 @@ namespace __variant
   using _Variant = typename _Nth_type<__index, _Variants...>::type;
 
   static constexpr int __do_cookie =
-   _Extra_visit_slot_needed<_Ret, _Variant>::value ? 1 : 0;
+   __extra_visit_slot_needed<_Ret, _Variant> ? 1 : 0;
 
   using _Tp = _Ret(*)(_Visitor, _Variants...);
 
@@ -953,7 +952,7 @@ namespace __variant
_S_apply_all_alts(_Array_type& __vtable,
  std::index_sequence<__var_indices...>)
{
- if constexpr (_Extra_visit_slot_needed<_Result_type, _Next>::value)
+ if constexpr (__extra_visit_slot_needed<_Result_type, _Next>)
(_S_apply_single_alt(
  __vtable._M_arr[__var_indices + 1],
  &(__vtable._M_arr[0])), ...);
@@ -1372,7 +1371,7 @@ namespace __variant
 
   template
static constexpr size_t __accepted_index
- = __detail::__variant::__accepted_index<_Tp, variant>::value;
+ = __detail::__variant::__accepted_index<_Tp, variant>;
 
   template>
using __to_type = typename _Nth_type<_Np, _Types...>::type;
-- 
2.36.1

[committed] libstdc++: Simplify fs::path construction using variable template

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/bits/fs_path.h (__is_path_iter_src): Replace class
template with variable template.
---
 libstdc++-v3/include/bits/fs_path.h | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/bits/fs_path.h 
b/libstdc++-v3/include/bits/fs_path.h
index d6202fd275a..6e7b366d104 100644
--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -102,19 +102,16 @@ namespace __detail
 #endif
 
   template
-struct __is_path_iter_src
-: false_type
-{ };
+inline constexpr bool __is_path_iter_src = false;
 
   template
-struct __is_path_iter_src<_Iter_traits,
- void_t>
-: bool_constant<__is_encoded_char>
-{ };
+inline constexpr bool
+__is_path_iter_src<_Iter_traits, void_t>
+  = __is_encoded_char;
 
   template
 inline constexpr bool __is_path_src
-  = __is_path_iter_src>>::value;
+  = __is_path_iter_src>>;
 
   template<>
 inline constexpr bool __is_path_src = false;
@@ -150,7 +147,7 @@ namespace __detail
 
   // SFINAE constraint for InputIterator parameters as required by [fs.req].
   template>
-using _Path2 = enable_if_t<__is_path_iter_src<_Tr>::value, path>;
+using _Path2 = enable_if_t<__is_path_iter_src<_Tr>, path>;
 
 #if __cpp_lib_concepts
   template
-- 
2.36.1

[committed] libstdc++: Invert relationship between std::is_clock and std::is_clock_v

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

This redefines std::is_clock in terms of std::is_clock_v, instead of the
other way around. This avoids instantiatng the class template for code
that only uses the variable template.

libstdc++-v3/ChangeLog:

* include/bits/chrono.h (is_clock_v): Define to false.
(is_clock_v): Define partial specialization for true cases.
(is_clock): Define in terms of is_clock_v.
---
 libstdc++-v3/include/bits/chrono.h | 49 --
 1 file changed, 20 insertions(+), 29 deletions(-)

diff --git a/libstdc++-v3/include/bits/chrono.h 
b/libstdc++-v3/include/bits/chrono.h
index 745f9a81357..05987ca09df 100644
--- a/libstdc++-v3/include/bits/chrono.h
+++ b/libstdc++-v3/include/bits/chrono.h
@@ -273,16 +273,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #endif // C++17
 
 #if __cplusplus > 201703L
-template
-  struct is_clock;
-
-template
-  inline constexpr bool is_clock_v = is_clock<_Tp>::value;
-
 #if __cpp_lib_concepts
 template
-  struct is_clock : false_type
-  { };
+  inline constexpr bool is_clock_v = false;
 
 template
   requires requires {
@@ -298,32 +291,30 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
requires same_as;
   }
-  struct is_clock<_Tp> : true_type
-  { };
+inline constexpr bool is_clock_v<_Tp> = true;
 #else
 template
-  struct __is_clock_impl : false_type
-  { };
+  inline constexpr bool is_clock_v = false;
 
 template
-  struct __is_clock_impl<_Tp,
-void_t>
-  : __and_>,
-  is_same,
-  is_same,
-  is_same>::type
-  { };
-
-template
-  struct is_clock : __is_clock_impl<_Tp>::type
-  { };
+  inline constexpr bool
+  is_clock_v<_Tp, void_t>
+   = __and_v>,
+ is_same,
+ is_same,
+ is_same>;
 #endif
+
+template
+  struct is_clock
+  : bool_constant>
+  { };
 #endif // C++20
 
 #if __cplusplus >= 201703L
-- 
2.36.1

Re: [PATCH] libstdc++-v3: testsuite: complex proj requirements

[Alexandre Oliva via Gcc-patches]

On Jun 21, 2022, Alexandre Oliva  wrote:

>   * testsuite/26_numerics/complex/proj.cc: Skip test in the
>   circumstances in which the implementation of proj is known to
>   be broken.

Ping?

https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596922.html

(I've dropped the '-v3' from the summary line after noticing it)

-- 
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: [rs6000 PATCH] Improve constant integer multiply using rldimi.

[Kewen.Lin via Gcc-patches]

Hi Roger,

on 2022/6/27 04:56, Roger Sayle wrote:
>  
> 
> This patch tweaks the code generated on POWER for integer multiplications
> 
> by a constant, by making use of rldimi instructions.  Much like x86's
> 
> lea instruction, rldimi can be used to implement a shift and add pair
> 
> in some circumstances.  For rldimi this is when the shifted operand
> 
> is known to have no bits in common with the added operand.
> 
>  
> 
> Hence for the new testcase below:
> 
>  
> 
> int foo(int x)
> 
> {
> 
>   int t = x & 42;
> 
>   return t * 0x2001;
> 
> }
> 
>  
> 
> when compiled with -O2, GCC currently generates:
> 
>  
> 
> andi. 3,3,0x2a
> 
> slwi 9,3,13
> 
> add 3,9,3
> 
> extsw 3,3
> 
> blr
> 
>  
> 
> with this patch, we now generate:
> 
>  
> 
> andi. 3,3,0x2a
> 
> rlwimi 3,3,13,0,31-13
> 
> extsw 3,3
> 
> blr
> 
>  
> 
> It turns out this optimization already exists in the form of a combine
> 
> splitter in rs6000.md, but the constraints on combine splitters,
> 
> requiring three of four input instructions (and generating one or two
> 
> output instructions) mean it doesn't get applied as often as it could.
> 
> This patch converts the define_split into a define_insn_and_split to
> 
> catch more cases (such as the one above).
> 
>  
> 
> The one bit that's tricky/controversial is the use of RTL's
> 
> nonzero_bits which is accurate during the combine pass when this
> 
> pattern is first recognized, but not as advanced (not kept up to
> 
> date) when this pattern is eventually split.  To support this,
> 
> I've used a "|| reload_completed" idiom.  Does this approach seem
> 
> reasonable? [I've another patch of x86 that uses the same idiom].
> 
>  

I tested this patch on powerpc64-linux-gnu, it caused the below ICE
against test case gcc/testsuite/gcc.c-torture/compile/pr93098.c.

gcc/testsuite/gcc.c-torture/compile/pr93098.c: In function ‘foo’:
gcc/testsuite/gcc.c-torture/compile/pr93098.c:10:1: error: unrecognizable insn:
(insn 104 32 34 2 (set (reg:SI 185 [+4 ])
(ior:SI (and:SI (reg:SI 200 [+4 ])
(const_int 4294967295 [0x]))
(ashift:SI (reg:SI 140)
(const_int 32 [0x20] 
"gcc/testsuite/gcc.c-torture/compile/pr93098.c":6:11 -1
 (nil))
during RTL pass: subreg3
dump file: pr93098.c.291r.subreg3
gcc/testsuite/gcc.c-torture/compile/pr93098.c:10:1: internal compiler error: in 
extract_insn, at recog.cc:2791
0x101f664b _fatal_insn(char const*, rtx_def const*, char const*, int, char 
const*)
gcc/rtl-error.cc:108
0x101f6697 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
gcc/rtl-error.cc:116
0x10ae427f extract_insn(rtx_insn*)
gcc/recog.cc:2791
0x11b239bb decompose_multiword_subregs
gcc/lower-subreg.cc:1555
0x11b25013 execute
gcc/lower-subreg.cc:1818

The above trace shows we fails to recog the pattern again due to
the inaccurate nonzero_bits information as you pointed out above.

There was another patch [1] which wasn't on trunk but touched this
same define_split, not sure if that can help or we can follow the
similar idea.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2021-December/585841.html

BR,
Kewen

Re: [PATCH v2 2/7] fixincludes: use grep instead of egrep/fgrep

[Eric Gallager via Gcc-patches]

On Mon, Jun 27, 2022 at 2:10 AM Xi Ruoyao via Gcc-patches
 wrote:
>
> 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.
>
> But, we can't simply replace egrep to grep -E or fgrep to grep -F or the
> build will break with some non-GNU grep implementations (lacking -E or
> -F support).  autoconf documentation suggests to use AC_PROG_EGREP and
> $EGREP or AC_PROG_FGREP and FGREP, but doing so is too complicated for
> fixincludes.
>
> So we simply adjust the patterns for a plain grep, instead of relying on
> the behavior of grep -E/-F.
>
> Q: Why "[ \t][ \t]*" instead of "[ \t]\\+"?
> A: POSIX does not allow escaping + in BRE.
>
> fixincludes/ChangeLog:
>
> * fixinc.in: Use grep instead of egrep.
> * inclhack.def: Use grep instead of egrep, and adjust an
> regular expression to make it a BRE.
> * genfixes: Use grep instead of egrep, and escape "." in the
> pattern.
> * fixincl.x: Regenerate.
> ---
>  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..a4cd3d0fbb4 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 '^[   ]*#[]*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..c9b4cf504f2 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 25, 2022 at 12:44:14 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 Sat Jun 25 12:44:14 CST 2022

So, this is kind of a tangent, but since GCC has migrated from SVN to
git, perhaps it's time to update this comment?

>   *
>   * 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 'define[ \t][ \t]*DBL_MAX[ \t][ \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 '#include' $file`\"";
>  tSCC zVxworks_Needs_VxworksTest2[] =
> -   " -n \"`egrep ULONG $file`\"";
> +   " -n \"`grep ULONG $file`\"";
>
>  #defineVXWORKS_NEEDS_VXWORKS_TEST_CT  4
>  static tTestDesc aVxworks_Needs_VxworksTests[] = {
> diff --git a/fixincludes/genfixes b/fixincludes/genfixes
> index 47aad01289d..3a4c05c832b 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 ' 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..080bbc010dc 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 'define[ \t][ \t]*DBL_MAX[ \t][ \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   

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

[Jonathan Wakely via Gcc-patches]

On Mon, 27 Jun 2022 at 10:49, Alexandre Oliva  wrote:
>
> On Jun 24, 2022, Jonathan Wakely  wrote:
>
> > 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
>
> Doh!  It was such a long and goof-ful day :-(
>
> Thanks for catching it.
>
> Unless you ask me not to, I'd like to install this to complete the
> earlier patch.

OK, although I'll just remove it again as part of the _At_path patch
that makes this extra check unnecessary. But this part would be a
candidate for backporting.

>  I've given it some testing, along with your _At_path
> patch, and results are looking promising.  There are still a few
> remaining fails.
>
>
> libstdc++: check for openat with dirfd in std::filesystem
>
> From: Alexandre Oliva 
>
> In the recent patch to check for openat, I missed an occurrence of
> dirfd in std::filesystem.
>
>
> for  libstdc++-v3/ChangeLog
>
> * src/c++17/fs_dir.cc (dir_and_pathname): Use dirfd if
> _GLIBCXX_HAVE_OPENAT.
> ---
>  libstdc++-v3/src/c++17/fs_dir.cc |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/src/c++17/fs_dir.cc 
> b/libstdc++-v3/src/c++17/fs_dir.cc
> index c67fe76bc14f8..25b33baa875fb 100644
> --- a/libstdc++-v3/src/c++17/fs_dir.cc
> +++ b/libstdc++-v3/src/c++17/fs_dir.cc
> @@ -124,7 +124,7 @@ struct fs::_Dir : _Dir_base
>dir_and_pathname() const noexcept
>{
>  const fs::path& p = entry.path();
> -#if _GLIBCXX_HAVE_DIRFD
> +#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT
>  if (!p.empty())
>return {::dirfd(this->dirp), std::prev(p.end())->c_str()};
>  #endif
>
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 
>

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

[Alexandre Oliva via Gcc-patches]

On Jun 24, 2022, Jonathan Wakely  wrote:

> 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

Doh!  It was such a long and goof-ful day :-(

Thanks for catching it.

Unless you ask me not to, I'd like to install this to complete the
earlier patch.  I've given it some testing, along with your _At_path
patch, and results are looking promising.  There are still a few
remaining fails.


libstdc++: check for openat with dirfd in std::filesystem

From: Alexandre Oliva 

In the recent patch to check for openat, I missed an occurrence of
dirfd in std::filesystem.


for  libstdc++-v3/ChangeLog

* src/c++17/fs_dir.cc (dir_and_pathname): Use dirfd if
_GLIBCXX_HAVE_OPENAT.
---
 libstdc++-v3/src/c++17/fs_dir.cc |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index c67fe76bc14f8..25b33baa875fb 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -124,7 +124,7 @@ struct fs::_Dir : _Dir_base
   dir_and_pathname() const noexcept
   {
 const fs::path& p = entry.path();
-#if _GLIBCXX_HAVE_DIRFD
+#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT
 if (!p.empty())
   return {::dirfd(this->dirp), std::prev(p.end())->c_str()};
 #endif


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] testsuite: Fix up pr106070.c test [PR106070]

[Jakub Jelinek via Gcc-patches]

Hi!

The test FAILs on 32-bit targets, because when unsigned long
is 32-bit, (unsigned long) -1 isn't 0x.
The options to fix this would be either using -1UL, or switch
to unsigned long long and using -1ULL, I chose the latter because
the test then FAILs in r13-1242 even on 32-bit targets.
And while at it, some deobfuscation and formatting tweaks.

Tested on x86_64-linux with -m32/-m64 with a week old gcc (where it
FAILs now on both) and current gcc (where it succeeds), ok for trunk?

2022-06-27  Jakub Jelinek  

PR tree-optimization/106070
* gcc.dg/torture/pr106070.c: Use unsigned long long instead of
unsigned long and -1ULL instead of 0x, deobcuscate
and improve formatting.

--- gcc/testsuite/gcc.dg/torture/pr106070.c.jj  2022-06-26 23:11:16.120254567 
+0200
+++ gcc/testsuite/gcc.dg/torture/pr106070.c 2022-06-27 11:30:02.475765731 
+0200
@@ -1,20 +1,22 @@
 /* { 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;
-}
+unsigned int a = 1;
+int b = -1;
+int c = 4;
+unsigned long long d;
 
-void test();
+void __attribute__((noipa))
+test (void)
+{
+  for (int i = 0; i < c; i += 2)
+d = a != (int) b ? (unsigned long long) b : (unsigned long long) a;
+}
 
-int main()
+int
+main ()
 {
-  test();
-  if (arr_252 != 0x)
-__builtin_abort();
+  test ();
+  if (d != -1ULL)
+__builtin_abort ();
   return 0;
 }

Jakub

[PATCH] rs6000: Simplify *rotl3_insert_4 by removing DImode

[Kewen.Lin via Gcc-patches]

Hi,

define_insn *rotl3_insert_4 use mode iterator GPR which
consists of SImode and conditional DImode, but the condition
of this define_insn requires the mode should be SImode.  By
further checking, it's found that the rldimi instruction can
not be used for this pattern since the required mask can not
be represented correctly.  We can have the fixed mask end 31
with rlwimi, but can not have the fixed mask end with rldimi
as it has to be (63 - SH) always.

So this patch simplifies the define_insn to use SImode only.

Tested on powerpc64-linux-gnu P8 and powerpc64le-linux-gnu P9
and P10.

Is it ok for trunk?

BR,
Kewen
-
gcc/ChangeLog:

* config/rs6000/rs6000.md (*rotl3_insert_4): Replace mode
iterator GPR with SImode, adjust the condition and output template,
rename to ...
(*rotlsi3_insert_4): ... this.
---
 gcc/config/rs6000/rs6000.md | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index c55ee7e171a..aef88e94576 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -4206,23 +4206,18 @@ (define_split
   operands[4] = GEN_INT ((HOST_WIDE_INT_1U << INTVAL (operands[2])) - 1);
 })

-(define_insn "*rotl3_insert_4"
-  [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
-   (ior:GPR (and:GPR (match_operand:GPR 3 "gpc_reg_operand" "0")
- (match_operand:GPR 4 "const_int_operand" "n"))
-(lshiftrt:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
+; It's unable to extend this define_insn for DImode, because the
+; corresponding hardware instruction for DImode is rldimi, which only has
+; four operands and the end of mask is always (63 - SH) rather than 63
+; that is required for this pattern.
+(define_insn "*rotlsi3_insert_4"
+  [(set (match_operand:SI 0 "gpc_reg_operand" "=r")
+   (ior:SI (and:SI (match_operand:SI 3 "gpc_reg_operand" "0")
+ (match_operand:SI 4 "const_int_operand" "n"))
+(lshiftrt:SI (match_operand:SI 1 "gpc_reg_operand" "r")
   (match_operand:SI 2 "const_int_operand" "n"]
-  "mode == SImode &&
-   GET_MODE_PRECISION (mode)
-   == INTVAL (operands[2]) + exact_log2 (-UINTVAL (operands[4]))"
-{
-  operands[2] = GEN_INT (GET_MODE_PRECISION (mode)
-- INTVAL (operands[2]));
-  if (mode == SImode)
-return "rlwimi %0,%1,%h2,32-%h2,31";
-  else
-return "rldimi %0,%1,%H2,64-%H2";
-}
+  "INTVAL (operands[2]) + exact_log2 (-UINTVAL (operands[4])) == 32"
+  "rlwimi %0,%1,32-%h2,%h2,31"
   [(set_attr "type" "insert")])

 (define_insn "*rotlsi3_insert_5"
--
2.32.0

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

[Alexandre Oliva via Gcc-patches]

On Jun 23, 2022, Jonathan Wakely  wrote:

> The attached makes this a bit more efficient, and makes more of the
> code common to the mkstemp and non-mkstmp branches. I'll wait to hear
> back from you before pushing it (since it has Joel's name on the
> patch).

Thanks, I've given it a spin, both trunk and gcc-11, and I confirm it
works for us.

-- 
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 v2 3/7] libbacktrace: use grep instead of fgrep

[Jonathan Wakely via Gcc-patches]

On Mon, 27 Jun 2022 at 07:09, Xi Ruoyao 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.
> But, we can't simply replace fgrep to grep -F, or the build will break
> with some non-GNU grep implementations (lacking -F support).
>
> As "add-gnu-debuglink" is definitely not a non-trivial regex, simply
> replace fgrep with grep.

FWIW, GNU grep will be just as fast when using grep as fgrep in this
case, because it detects that the pattern is a fixed string that
contains no special characters and automatically uses the same
matching engine as fgrep. So for GNU grep, there's no downside to this
change.

Re: [PATCH v2 6/7] contrib: use grep -E instead of egrep

[Jonathan Wakely via Gcc-patches]

On Mon, 27 Jun 2022 at 07:12, Xi Ruoyao  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.
>
> Some non-POSIX grep implementations does not support -E option, so for
> test_summary and warn_summary we prefer grep -E, but fallback to egrep
> if grep -E does not work.  For check_GNU_style.sh, I think it is only
> used by developers so hard coding grep -E is OK.
>
> contrib/ChangeLog:
>
> * check_GNU_style.sh: Use grep -E instead of egrep.
> * test_summary: Use grep -E instead of egrep if it works.
> * warn_summary: Likewise.
> ---
>  contrib/check_GNU_style.sh | 10 +-
>  contrib/test_summary   | 13 -
>  contrib/warn_summary   | 13 -
>  3 files changed, 29 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..f17bf54f8ec 100755
> --- a/contrib/test_summary
> +++ b/contrib/test_summary
> @@ -54,6 +54,17 @@ if test -z "$AWK" ; then
>done
>  fi
>
> +# Prefer "grep -E" which should work with POSIX-conform grep, but fallback

"POSIX-conforming"

> +# to "egrep" (which is deprecated for a long time) if grep does not support

I'd just say "to deprecate egrep" or "to egrep (which is deprecated)".
There's no need to say anything about how long it's been deprecated.


> +# -E.
> +if test -z "$EGREP" ; then
> +  if echo a | grep -E '(a|b)' > /dev/null 2> /dev/null; then
> +EGREP="grep -E"
> +  else
> +EGREP="egrep"
> +  fi
> +fi
> +
>  : ${filesuffix=}; export filesuffix
>  : ${move=true}; export move
>  : ${forcemail=false}; export forcemail
> @@ -77,7 +88,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
> +  $EGREP '^[<>] (XPASS|FAIL)' >/dev/null; then
> echo true
> else
> echo false
> diff --git a/contrib/warn_summary b/contrib/warn_summary
> index d4c8b6cdb19..afa11802ee1 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)/'
> +  $EGREP -v '/gcc/(ch|cp|f|fortran|ada|intl|fixinc)/'
>  else
># Pass through only subdir $filter.
>grep "/gcc/$filter/"
> @@ -155,6 +155,17 @@ if test -z "$AWK" ; then
>done
>  fi
>
> +# Prefer "grep -E" which should work with POSIX-conform grep, but fallback
> +# to "egrep" (which is deprecated for a long time) if grep does not support

Ditto.

> +# -E.
> +if test -z "$EGREP" ; then
> +  if echo a | grep -E '(a|b)' > /dev/null 2> /dev/null; then
> +EGREP="grep -E"
> +  else
> +EGREP="egrep"
> +  fi
> +fi
> +
>  # Parse command line arguments.
>  while test -n "$1" ; do
>   case "$1" in
> --
> 2.36.1
>
>

Re: [PATCH] MAINTAINERS: Add myself for write after approval

[Hongyu Wang via Gcc-patches]

Sorry, should be between

Boris Kolpackov 
Dave Korn 

Hongyu Wang  于2022年6月27日周一 16:29写道：
>
> According to the official guide, please sort your last name in
> alphabetical order, which means you shold put your name between
>
> Dave Korn 
> Julia Koval 
>
> Kong, Lingling via Gcc-patches  于2022年6月27日周一 
> 16:05写道：
>
> >
> > Hi,
> >
> > I want to add myself in MAINTANINER for write after approval.
> >
> > OK for master?
> >
> > ChangeLog:
> >
> > * MAINTAINERS (Write After Approval): Add myself.
> > ---
> >  MAINTAINERS | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 54d8ad41a6f..49627e5d113 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -698,6 +698,7 @@ Shujing Zhao
> > 
> >  Jon Ziegler
> >  Roman Zippel   
> >  Josef Zlomek   
> > +Lingling Kong  
> >
> > Bug database only accounts
> >
> > --
> > 2.18.1
> >

Re: [PATCH] MAINTAINERS: Add myself for write after approval

[Hongyu Wang via Gcc-patches]

According to the official guide, please sort your last name in
alphabetical order, which means you shold put your name between

Dave Korn 
Julia Koval 

Kong, Lingling via Gcc-patches  于2022年6月27日周一 16:05写道：

>
> Hi,
>
> I want to add myself in MAINTANINER for write after approval.
>
> OK for master?
>
> ChangeLog:
>
> * MAINTAINERS (Write After Approval): Add myself.
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 54d8ad41a6f..49627e5d113 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -698,6 +698,7 @@ Shujing Zhao
> 
>  Jon Ziegler
>  Roman Zippel   
>  Josef Zlomek   
> +Lingling Kong  
>
> Bug database only accounts
>
> --
> 2.18.1
>

[PATCH] MAINTAINERS: Add myself for write after approval

[Kong, Lingling via Gcc-patches]

Hi,

I want to add myself in MAINTANINER for write after approval.

OK for master?

ChangeLog:

* MAINTAINERS (Write After Approval): Add myself.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 54d8ad41a6f..49627e5d113 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -698,6 +698,7 @@ Shujing Zhao

 Jon Ziegler
 Roman Zippel   
 Josef Zlomek   
+Lingling Kong  
 
Bug database only accounts
 
-- 
2.18.1

[PATCH v3] c: Extend the -Wpadded message with actual padding size

[Vit Kabele]

Hello,

after further discussion I changed the ! default_packed to attribute
aligned, so that the test passes also on targets where 4 bytes types are
aligned on 2 byte boundaries.

Best regards,
Vit Kabele

-- >8 --
Subject: [PATCH v3] c: Extend the -Wpadded message with actual padding size

When the compiler warns about padding struct to alignment boundary, it
now also informs the user about the size of the alignment that needs to
be added to get rid of the warning.

This removes the need of using pahole or similar tools, or manually
determining the padding size.

Tested for x86_64-pc-linux-gnu and cris-elf targets.

gcc/ChangeLog:

* stor-layout.cc (finalize_record_size): Extend warning message.

gcc/testsuite/ChangeLog:

* c-c++-common/Wpadded.c: New test.

Signed-off-by: Vit Kabele 
---
 gcc/stor-layout.cc   |  7 ++-
 gcc/testsuite/c-c++-common/Wpadded.c | 14 ++
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/c-c++-common/Wpadded.c

diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
index 765f22f68b9..88923c4136b 100644
--- a/gcc/stor-layout.cc
+++ b/gcc/stor-layout.cc
@@ -1781,7 +1781,12 @@ finalize_record_size (record_layout_info rli)
   && simple_cst_equal (unpadded_size, TYPE_SIZE (rli->t)) == 0
   && input_location != BUILTINS_LOCATION
   && !TYPE_ARTIFICIAL (rli->t))
-warning (OPT_Wpadded, "padding struct size to alignment boundary");
+  {
+   tree pad_size
+ = size_binop (MINUS_EXPR, TYPE_SIZE_UNIT (rli->t), 
unpadded_size_unit);
+ warning (OPT_Wpadded,
+   "padding struct size to alignment boundary with %E bytes", 
pad_size);
+  }
 
   if (warn_packed && TREE_CODE (rli->t) == RECORD_TYPE
   && TYPE_PACKED (rli->t) && ! rli->packed_maybe_necessary
diff --git a/gcc/testsuite/c-c++-common/Wpadded.c 
b/gcc/testsuite/c-c++-common/Wpadded.c
new file mode 100644
index 000..c5be4686822
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Wpadded.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-Wpadded" } */
+
+/*
+ * The struct is on single line, because C++ compiler emits the -Wpadded
+ * warning at the first line of the struct definition, while the C compiler at
+ * the last line. This way the test passes on both.
+ *
+ * Attribute aligned is needed for the test to pass on targets where
+ * the default behaviour is to pack the struct and also on targets that align
+ * 4 byte fields to 2 byte boundary.
+ */
+struct S { __UINT32_TYPE__ i; char c; } __attribute__((aligned(4))); /* { 
dg-warning "padding struct size to alignment boundary with 3 bytes" } */
+
-- 
2.30.2

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

[Jakub Jelinek via Gcc-patches]

On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote:
> I don’t like the _Float128 vs __float128 business, it’s confusing.
> And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
> they seem to be basically the same thing, so it’s also redundant.

I thought __float128 and _Float128 are distinct and incompatible in the FEs
and equivalent in middle-end and back-end, but apparently they are
considered equivalent even for _Generic.
Still, using __float128 when the APIs are declared for __float128 and
_Float128 when the APIs are declared for _Float128 can be better for
consistency.

But if you feel strongly that we should use _Float128 and F128/f128
suffixes on floating point constants everywhere, we'd need more work
(e.g. because we use those same suffixes also for the functions where
we need to differentiate, or on macros like M_PI etc. where it is
significant too), and we'd need to come up with new macros to differentiate
which API set to use.
In the patch I've posted,
HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 defines stand for
__float128 + libquadmath APIs,
HAVE__FLOAT128 and GFC_REAL_16_IS__FLOAT128 stand for
_Float128 and C *f128 APIs.
If HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 stand for
_Float128 and libquadmath or *f128 APIs, we'd need some macro
to tell which APIs to use, say
USE_LIBQUADMATH and USE_IEC_60559.
And the hardest part would be that we that GFC_REAL_{16,17}_LITERAL{,_SUFFIX}
is currently used everywhere while for library APIs and M_* constants
we need to differentiate.  Perhaps we could just use *q suffixes even when
using _Float128 when USE_LIBQUADMATH.

Jakub

RE: [PATCH 2/2]middle-end: Support recognition of three-way max/min.

[Richard Biener via Gcc-patches]

On Tue, 21 Jun 2022, Tamar Christina wrote:

> > -Original Message-
> > From: Richard Biener 
> > Sent: Tuesday, June 21, 2022 2:15 PM
> > To: Tamar Christina 
> > Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com
> > Subject: RE: [PATCH 2/2]middle-end: Support recognition of three-way
> > max/min.
> > 
> > On Mon, 20 Jun 2022, Tamar Christina wrote:
> > 
> > > > -Original Message-
> > > > From: Richard Biener 
> > > > Sent: Monday, June 20, 2022 9:36 AM
> > > > To: Tamar Christina 
> > > > Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com
> > > > Subject: Re: [PATCH 2/2]middle-end: Support recognition of three-way
> > > > max/min.
> > > >
> > > > On Thu, 16 Jun 2022, Tamar Christina wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > This patch adds support for three-way min/max recognition in phi-opts.
> > > > >
> > > > > Concretely for e.g.
> > > > >
> > > > > #include 
> > > > >
> > > > > uint8_t three_min (uint8_t xc, uint8_t xm, uint8_t xy) {
> > > > >   uint8_t  xk;
> > > > > if (xc < xm) {
> > > > > xk = (uint8_t) (xc < xy ? xc : xy);
> > > > > } else {
> > > > > xk = (uint8_t) (xm < xy ? xm : xy);
> > > > > }
> > > > > return xk;
> > > > > }
> > > > >
> > > > > we generate:
> > > > >
> > > > >[local count: 1073741824]:
> > > > >   _5 = MIN_EXPR ;
> > > > >   _7 = MIN_EXPR ;
> > > > >   return _7;
> > > > >
> > > > > instead of
> > > > >
> > > > >   :
> > > > >   if (xc_2(D) < xm_3(D))
> > > > > goto ;
> > > > >   else
> > > > > goto ;
> > > > >
> > > > >   :
> > > > >   xk_5 = MIN_EXPR ;
> > > > >   goto ;
> > > > >
> > > > >   :
> > > > >   xk_6 = MIN_EXPR ;
> > > > >
> > > > >   :
> > > > >   # xk_1 = PHI 
> > > > >   return xk_1;
> > > > >
> > > > > The same function also immediately deals with turning a
> > > > > minimization problem into a maximization one if the results are
> > > > > inverted.  We do this here since doing it in match.pd would end up
> > > > > changing the shape of the BBs and adding additional instructions
> > > > > which would prevent various
> > > > optimizations from working.
> > > >
> > > > Can you explain a bit more?
> > >
> > > I'll respond to this one first In case it changes how you want me to 
> > > proceed.
> > >
> > > I initially had used a match.pd rule to do the min to max conversion,
> > > but a number of testcases started to fail.  The reason was that a lot
> > > of the foldings checked that the BB contains only a single SSA and that 
> > > that
> > SSA is a phi node.
> > >
> > > By changing the min into max, the negation of the result ends up In
> > > the same BB and so the optimizations are skipped leading to less optimal
> > code.
> > >
> > > I did look into relaxing those phi opts but it felt like I'd make a
> > > rather arbitrary exception for minus and seemed better to handle it in the
> > minmax folding.
> > 
> > That's a possibility but we try to maintain a single place for a transform 
> > which
> > might be in match.pd which would then also handle this when there's a RHS
> > COND_EXPR connecting the stmts rather than a PHI node.
> 
> Sorry, I am probably missing something here.  Just to be clear at the moment 
> I just do it all in
> minmax_replacement, so everything is already in one place.  It's a simple 
> extension of the code
> already there.
> 
> Are you suggesting I have to move it all to match.pd?  That's non-trivial..

I was hoping Andrew was going to respond with an estimate as to how
far he is along moving the minmax replacement to match.pd.

I'm just after less overall work.  But then improving minmax_replacement
is OK (see my comments on the actual patch), it just will make the
match.pd attempt more complex because of the need to handle diamonds.

Richard.

> Thanks,
> Tamar
> 
> > 
> > Richard.
> > 
> > > Thanks,
> > > Tamar
> > >
> > > >
> > > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> > > > >
> > > > > Ok for master?
> > > > >
> > > > > Thanks,
> > > > > Tamar
> > > > >
> > > > > gcc/ChangeLog:
> > > > >
> > > > >   * tree-ssa-phiopt.cc (minmax_replacement): Optionally search for
> > > > the phi
> > > > >   sequence of a three-way conditional.
> > > > >   (replace_phi_edge_with_variable): Support deferring of BB 
> > > > > removal.
> > > > >   (tree_ssa_phiopt_worker): Detect diamond phi structure for 
> > > > > three-
> > > > way
> > > > >   min/max.
> > > > >   (strip_bit_not, invert_minmax_code): New.
> > > > >
> > > > > gcc/testsuite/ChangeLog:
> > > > >
> > > > >   * gcc.dg/tree-ssa/split-path-1.c: Disable phi-opts so we don't
> > > > optimize
> > > > >   code away.
> > > > >   * gcc.dg/tree-ssa/minmax-3.c: New test.
> > > > >   * gcc.dg/tree-ssa/minmax-4.c: New test.
> > > > >   * gcc.dg/tree-ssa/minmax-5.c: New test.
> > > > >   * gcc.dg/tree-ssa/minmax-6.c: New test.
> > > > >   * gcc.dg/tree-ssa/minmax-7.c: New test.
> > > > >   * gcc.dg/tree-ssa/minmax-8.c: New test.
> > > > >

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Hi,

all 11k regression tests pass with the new linking implementation (on
devel/m2link).  I plan to migrate the patches back to devel/modula-2 and
then remove devel/m2link.  Thereafter {polish,test} and generate new
patch sets.  Thanks for the clear explanation on how the dynamic
scaffold should work!

regards,
Gaius

Re: [PATCH v2 5/7] testsuite: stop using obsoleted 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.
> 
> However, simply replacing egrep with grep -E will break build on some
> systems (notably Solaris) w/o a POSIX-conform grep.  We detect a
> suitable command with AC_PROG_EGREP, and pass it to run_acats.sh for
> Ada.
> 
> For Go, simply use grep instead of egrep as the pattern does not need
> any ERE features.
> 
> gcc/ChangeLog:
> 
>   * Makefile.in (EGREP): New variable.
>   * configure.ac (AC_PROG_EGREP): Call it.
>   * configure: Regenerate.
> 
> gcc/ada/ChangeLog:
> 
>   * gcc-interface/Make-lang.in: Pass EGREP to run_acats.sh.

The Ada change is OK

Arno

[PATCH 7/7] libffi: Use $EGREP instead of egrep

[Xi Ruoyao via Gcc-patches]

Cherry-pick libffi commit 280fe78d37f58927b280e2e316a2ae19201f2b83,
and regenerate configure.

libffi/ChangeLog:

* configure.ac: Call AC_PROG_EGREP, and use $EGREP instead of
egrep.
* configure: Regenerate.
---
 libffi/configure| 270 ++--
 libffi/configure.ac |   3 +-
 2 files changed, 137 insertions(+), 136 deletions(-)

diff --git a/libffi/configure b/libffi/configure
index 575641cca1d..3e490ba22d1 100755
--- a/libffi/configure
+++ b/libffi/configure
@@ -198,6 +198,7 @@ test -x / || exit 1"
   as_lineno_2=";as_suggested=$as_suggested$LINENO;as_suggested=$as_suggested" 
as_lineno_2a=\$LINENO
   eval 'test \"x\$as_lineno_1'\$as_run'\" != \"x\$as_lineno_2'\$as_run'\" &&
   test \"x\`expr \$as_lineno_1'\$as_run' + 1\`\" = 
\"x\$as_lineno_2'\$as_run'\"' || exit 1
+test \$(( 1 + 1 )) = 2 || exit 1
 
   test -n \"\${ZSH_VERSION+set}\${BASH_VERSION+set}\" || (
 
ECHO='\\'
@@ -205,8 +206,7 @@ test -x / || exit 1"
 ECHO=\$ECHO\$ECHO\$ECHO\$ECHO\$ECHO\$ECHO
 PATH=/empty FPATH=/empty; export PATH FPATH
 test \"X\`printf %s \$ECHO\`\" = \"X\$ECHO\" \\
-  || test \"X\`print -r -- \$ECHO\`\" = \"X\$ECHO\" ) || exit 1
-test \$(( 1 + 1 )) = 2 || exit 1"
+  || test \"X\`print -r -- \$ECHO\`\" = \"X\$ECHO\" ) || exit 1"
   if (eval "$as_required") 2>/dev/null; then :
   as_have_required=yes
 else
@@ -683,10 +683,10 @@ ac_ct_DUMPBIN
 DUMPBIN
 LD
 FGREP
-EGREP
-GREP
 SED
 LIBTOOL
+EGREP
+GREP
 am__fastdepCCAS_FALSE
 am__fastdepCCAS_TRUE
 CCASDEPMODE
@@ -5103,6 +5103,136 @@ fi
 
 
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for grep that handles long 
lines and -e" >&5
+$as_echo_n "checking for grep that handles long lines and -e... " >&6; }
+if ${ac_cv_path_GREP+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if test -z "$GREP"; then
+  ac_path_GREP_found=false
+  # Loop through the user's path and test for each of PROGNAME-LIST
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH$PATH_SEPARATOR/usr/xpg4/bin
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+for ac_prog in grep ggrep; do
+for ac_exec_ext in '' $ac_executable_extensions; do
+  ac_path_GREP="$as_dir/$ac_prog$ac_exec_ext"
+  as_fn_executable_p "$ac_path_GREP" || continue
+# Check for GNU ac_path_GREP and select it if it is found.
+  # Check for GNU $ac_path_GREP
+case `"$ac_path_GREP" --version 2>&1` in
+*GNU*)
+  ac_cv_path_GREP="$ac_path_GREP" ac_path_GREP_found=:;;
+*)
+  ac_count=0
+  $as_echo_n 0123456789 >"conftest.in"
+  while :
+  do
+cat "conftest.in" "conftest.in" >"conftest.tmp"
+mv "conftest.tmp" "conftest.in"
+cp "conftest.in" "conftest.nl"
+$as_echo 'GREP' >> "conftest.nl"
+"$ac_path_GREP" -e 'GREP$' -e '-(cannot match)-' < "conftest.nl" 
>"conftest.out" 2>/dev/null || break
+diff "conftest.out" "conftest.nl" >/dev/null 2>&1 || break
+as_fn_arith $ac_count + 1 && ac_count=$as_val
+if test $ac_count -gt ${ac_path_GREP_max-0}; then
+  # Best one so far, save it but keep looking for a better one
+  ac_cv_path_GREP="$ac_path_GREP"
+  ac_path_GREP_max=$ac_count
+fi
+# 10*(2^10) chars as input seems more than enough
+test $ac_count -gt 10 && break
+  done
+  rm -f conftest.in conftest.tmp conftest.nl conftest.out;;
+esac
+
+  $ac_path_GREP_found && break 3
+done
+  done
+  done
+IFS=$as_save_IFS
+  if test -z "$ac_cv_path_GREP"; then
+as_fn_error $? "no acceptable grep could be found in 
$PATH$PATH_SEPARATOR/usr/xpg4/bin" "$LINENO" 5
+  fi
+else
+  ac_cv_path_GREP=$GREP
+fi
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_path_GREP" >&5
+$as_echo "$ac_cv_path_GREP" >&6; }
+ GREP="$ac_cv_path_GREP"
+
+
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
+$as_echo_n "checking for egrep... " >&6; }
+if ${ac_cv_path_EGREP+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
+   then ac_cv_path_EGREP="$GREP -E"
+   else
+ if test -z "$EGREP"; then
+  ac_path_EGREP_found=false
+  # Loop through the user's path and test for each of PROGNAME-LIST
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH$PATH_SEPARATOR/usr/xpg4/bin
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+for ac_prog in egrep; do
+for ac_exec_ext in '' $ac_executable_extensions; do
+  ac_path_EGREP="$as_dir/$ac_prog$ac_exec_ext"
+  as_fn_executable_p "$ac_path_EGREP" || continue
+# Check for GNU ac_path_EGREP and select it if it is found.
+  # Check for GNU $ac_path_EGREP
+case `"$ac_path_EGREP" --version 2>&1` in
+*GNU*)
+  ac_cv_path_EGREP="$ac_path_EGREP" ac_path_EGREP_found=:;;
+*)
+  ac_count=0
+  $as_echo_n 0123456789 >"conftest.in"
+  while :
+  do
+cat 

[PATCH v2 4/7] fortran: use grep 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.

We can't hard code grep -F here or it may break build on hosts w/o GNU
grep.  autoconf documentation contains a warning about this issue and
suggest to use AC_PROG_FGREP and $FGREP, but these are too overkill in
the specific case: there is no way "debian" could be interpreted as an
non-trivial regex, so we can use a plain grep here.

gcc/fortran/ChangeLog:

* Make-lang.in: Use grep 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..6eb597d0ca0 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 -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

Re: [PATCH 1/2]AArch64 Add fallback case using sdot for usdot

[Richard Biener via Gcc-patches]

On Mon, Jun 27, 2022 at 7:25 AM Tamar Christina via Gcc-patches
 wrote:
>
> > -Original Message-
> > From: Richard Sandiford 
> > Sent: Thursday, June 16, 2022 7:54 PM
> > To: Tamar Christina 
> > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> > ; Marcus Shawcroft
> > ; Kyrylo Tkachov 
> > Subject: Re: [PATCH 1/2]AArch64 Add fallback case using sdot for usdot
> >
> > Richard Sandiford via Gcc-patches  writes:
> > > Tamar Christina  writes:
> > >> Hi All,
> > >>
> > >> The usdot operation is common in video encoder and decoders including
> > >> some of the most widely used ones.
> > >>
> > >> This patch adds a +dotprod version of the optab as a fallback for
> > >> when you do have sdot but not usdot available.
> > >>
> > >> The fallback works by adding a bias to the unsigned argument to
> > >> convert it to a signed value and then correcting for the bias later on.
> > >>
> > >> Essentially it relies on (x - 128)y + 128y == xy where x is unsigned
> > >> and y is signed (assuming both are 8-bit values).  Because the range
> > >> of a signed byte is only to 127 we split the bias correction into:
> > >>
> > >>(x - 128)y + 127y + y
> > >
> > > I bet you knew this question was coming, but: this technique isn't
> > > target-specific, so wouldn't it be better to handle it in
> > > tree-vect-patterns.cc instead?
>
> Ok, so after many hours of trying I don't know how to make this work.
> DOT_PROD_EXPR is a reduction, but emitting them as additional pattern
> statement doesn't work because they'll be marked as internal_def rather than
> reduction_def.  I tried marking the new vec_stmt_info that I create 
> explicitly as
> reduction_def but this gets overwritten during analysis.
>
> I then looked into getting it as a vectorizable_operation but has this 
> obvious problems
> In that it no longer treats it as a reduction and so tries to decompose into 
> hi/lo.
>
> I then looked into treating additional patterns from  a reduction as 
> reductions themselves
> but this is obviously wrong as non-reduction statements also get marked as 
> reductions.
>
> The conclusion is that I don't think the vectorizer allows additional 
> reductions to be
> emitted from patterns.

Indeed.  DOT_PROD is a weird beast and it doesn't define which lanes are
reduced to which so it's only usable when the result is reduced to a
single lane.

An SLP pattern might work if you use reduc-plus for the reduced lanes and keep
the multiply separate?

Richard.

> > Also, how about doing (x - 128)y + 64y + 64y instead, to reduce the number
> > of hoisted constants?
> >
> > Thanks,
> > Richard
> >
> > > Thanks,
> > > Richard
> > >
> > >> Concretely for:
> > >>
> > >> #define N 480
> > >> #define SIGNEDNESS_1 unsigned
> > >> #define SIGNEDNESS_2 signed
> > >> #define SIGNEDNESS_3 signed
> > >> #define SIGNEDNESS_4 unsigned
> > >>
> > >> SIGNEDNESS_1 int __attribute__ ((noipa)) f (SIGNEDNESS_1 int res,
> > >> SIGNEDNESS_3 char *restrict a,
> > >>SIGNEDNESS_4 char *restrict b)
> > >> {
> > >>   for (__INTPTR_TYPE__ i = 0; i < N; ++i)
> > >> {
> > >>   int av = a[i];
> > >>   int bv = b[i];
> > >>   SIGNEDNESS_2 short mult = av * bv;
> > >>   res += mult;
> > >> }
> > >>   return res;
> > >> }
> > >>
> > >> we generate:
> > >>
> > >> moviv5.16b, 0x7f
> > >> mov x3, 0
> > >> moviv4.16b, 0x1
> > >> moviv3.16b, 0xff80
> > >> moviv0.4s, 0
> > >> .L2:
> > >> ldr q2, [x2, x3]
> > >> ldr q1, [x1, x3]
> > >> add x3, x3, 16
> > >> sub v2.16b, v2.16b, v3.16b
> > >> sdotv0.4s, v2.16b, v1.16b
> > >> sdotv0.4s, v5.16b, v1.16b
> > >> sdotv0.4s, v4.16b, v1.16b
> > >> cmp x3, 480
> > >> bne .L2
> > >>
> > >> instead of:
> > >>
> > >> moviv0.4s, 0
> > >> mov x3, 0
> > >> .L2:
> > >> ldr q2, [x1, x3]
> > >> ldr q1, [x2, x3]
> > >> add x3, x3, 16
> > >> sxtlv4.8h, v2.8b
> > >> sxtl2   v3.8h, v2.16b
> > >> uxtlv2.8h, v1.8b
> > >> uxtl2   v1.8h, v1.16b
> > >> mul v2.8h, v2.8h, v4.8h
> > >> mul v1.8h, v1.8h, v3.8h
> > >> saddw   v0.4s, v0.4s, v2.4h
> > >> saddw2  v0.4s, v0.4s, v2.8h
> > >> saddw   v0.4s, v0.4s, v1.4h
> > >> saddw2  v0.4s, v0.4s, v1.8h
> > >> cmp x3, 480
> > >> bne .L2
> > >>
> > >> The new sequence is significantly faster as the operations it uses
> > >> are well optimized.  Note that execution tests are already in the mid-end
> > testsuite.
> > >>
> > >> Thanks to James Greenhalgh for the tip-off.
> > >>
> > >> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> > >>
> > >> Ok for master?
> > >>
> > >> Thanks,
> > >> Tamar
> > >>
> > >> gcc/ChangeLog:
> > >>
> > >>* config/aarch64/aarch64-simd.md (usdot_prod): Generate
> > fallback
> > >>or 

[PATCH] contrib: modernize gen_autofdo_event.py

[Xi Ruoyao via Gcc-patches]

Python 2 has been EOL'ed for two years.  egrep has been deprecated
for many years and the next grep release will start to print warning if
it is used.

-E option may be unsupported by some non-POSIX grep implementations, but
gcc-auto-profile won't work on non-Linux systems anyway.

contrib/ChangeLog:

* gen_autofdo_event.py: Port to Python 3, and use grep -E
instead of egrep.

gcc/ChangeLog:

* config/i386/gcc-auto-profile: Regenerate.
---
 contrib/gen_autofdo_event.py | 80 
 gcc/config/i386/gcc-auto-profile | 31 +++--
 2 files changed, 57 insertions(+), 54 deletions(-)

diff --git a/contrib/gen_autofdo_event.py b/contrib/gen_autofdo_event.py
index 1eb6f1d6d85..7da2876530d 100755
--- a/contrib/gen_autofdo_event.py
+++ b/contrib/gen_autofdo_event.py
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 # Generate Intel taken branches Linux perf event script for autofdo profiling.
 
 # Copyright (C) 2016 Free Software Foundation, Inc.
@@ -26,18 +26,19 @@
 # Requires internet (https) access. This may require setting up a proxy
 # with export https_proxy=...
 #
-import urllib2
+import urllib.request
 import sys
 import json
 import argparse
 import collections
+import os
 
 baseurl = "https://download.01.org/perfmon;
 
-target_events = (u'BR_INST_RETIRED.NEAR_TAKEN',
- u'BR_INST_EXEC.TAKEN',
- u'BR_INST_RETIRED.TAKEN_JCC',
- u'BR_INST_TYPE_RETIRED.COND_TAKEN')
+target_events = ('BR_INST_RETIRED.NEAR_TAKEN',
+ 'BR_INST_EXEC.TAKEN',
+ 'BR_INST_RETIRED.TAKEN_JCC',
+ 'BR_INST_TYPE_RETIRED.COND_TAKEN')
 
 ap = argparse.ArgumentParser()
 ap.add_argument('--all', '-a', help='Print for all CPUs', action='store_true')
@@ -71,47 +72,46 @@ def get_cpustr():
 return "%s-%d-%X" % tuple(cpu)[:3]
 
 def find_event(eventurl, model):
-print >>sys.stderr, "Downloading", eventurl
-u = urllib2.urlopen(eventurl)
+print("Downloading", eventurl, file = sys.stderr)
+u = urllib.request.urlopen(eventurl)
 events = json.loads(u.read())
 u.close()
 
 found = 0
 for j in events:
-if j[u'EventName'] in target_events:
-event = "cpu/event=%s,umask=%s/" % (j[u'EventCode'], j[u'UMask'])
-if u'PEBS' in j and j[u'PEBS'] > 0:
+if j['EventName'] in target_events:
+event = "cpu/event=%s,umask=%s/" % (j['EventCode'], j['UMask'])
+if 'PEBS' in j and int(j['PEBS']) > 0:
 event += "p"
 if args.script:
 eventmap[event].append(model)
 else:
-print j[u'EventName'], "event for model", model, "is", event
+print(j['EventName'], "event for model", model, "is", event)
 found += 1
 return found
 
 if not args.all:
-cpu = get_cpu_str()
+cpu = get_cpustr()
 if not cpu:
 sys.exit("Unknown CPU type")
 
 url = baseurl + "/mapfile.csv"
-print >>sys.stderr, "Downloading", url
-u = urllib2.urlopen(url)
+print("Downloading", url, file = sys.stderr)
+u = urllib.request.urlopen(url)
 found = 0
 cpufound = 0
 for j in u:
-n = j.rstrip().split(',')
+n = j.rstrip().decode().split(',')
 if len(n) >= 4 and (args.all or n[0] == cpu) and n[3] == "core":
-if args.all:
-components = n[0].split("-")
-model = components[2]
-model = int(model, 16)
+components = n[0].split("-")
+model = components[2]
+model = int(model, 16)
 cpufound += 1
 found += find_event(baseurl + n[2], model)
 u.close()
 
 if args.script:
-print '''#!/bin/sh
+print('''#!/bin/sh
 # Profile workload for gcc profile feedback (autofdo) using Linux perf.
 # Auto generated. To regenerate for new CPUs run
 # contrib/gen_autofdo_event.py --script --all in gcc source
@@ -146,27 +146,27 @@ if grep -q hypervisor /proc/cpuinfo ; then
   echo >&2 "Warning: branch profiling may not be functional in VMs"
 fi
 
-case `egrep -q "^cpu family\s*: 6" /proc/cpuinfo &&
-  egrep "^model\s*:" /proc/cpuinfo | head -n1` in'''
-for event, mod in eventmap.iteritems():
+case `grep -E -q "^cpu family\s*: 6" /proc/cpuinfo &&
+  grep -E "^model\s*:" /proc/cpuinfo | head -n1` in''')
+for event, mod in eventmap.items():
 for m in mod[:-1]:
-print "model*:\ %s|\\" % m
-print 'model*:\ %s) E="%s$FLAGS" ;;' % (mod[-1], event)
-print '''*)
+print("model*:\ %s|\\" % m)
+print('model*:\ %s) E="%s$FLAGS" ;;' % (mod[-1], event))
+print('''*)
 echo >&2 "Unknown CPU. Run contrib/gen_autofdo_event.py --all --script to 
update script."
-   exit 1 ;;'''
-print "esac"
-print "set -x"
-print 'if ! perf record -e $E -b "$@" ; then'
-print '  # PEBS may not actually be working even if the processor supports 
it'
-print '  # (e.g., in a virtual machine). Trying to run without /p.'
-print 

[PATCH v2 6/7] 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.

Some non-POSIX grep implementations does not support -E option, so for
test_summary and warn_summary we prefer grep -E, but fallback to egrep
if grep -E does not work.  For check_GNU_style.sh, I think it is only
used by developers so hard coding grep -E is OK.

contrib/ChangeLog:

* check_GNU_style.sh: Use grep -E instead of egrep.
* test_summary: Use grep -E instead of egrep if it works.
* warn_summary: Likewise.
---
 contrib/check_GNU_style.sh | 10 +-
 contrib/test_summary   | 13 -
 contrib/warn_summary   | 13 -
 3 files changed, 29 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..f17bf54f8ec 100755
--- a/contrib/test_summary
+++ b/contrib/test_summary
@@ -54,6 +54,17 @@ if test -z "$AWK" ; then
   done
 fi
 
+# Prefer "grep -E" which should work with POSIX-conform grep, but fallback
+# to "egrep" (which is deprecated for a long time) if grep does not support
+# -E.
+if test -z "$EGREP" ; then
+  if echo a | grep -E '(a|b)' > /dev/null 2> /dev/null; then
+EGREP="grep -E"
+  else
+EGREP="egrep"
+  fi
+fi
+
 : ${filesuffix=}; export filesuffix
 : ${move=true}; export move
 : ${forcemail=false}; export forcemail
@@ -77,7 +88,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
+  $EGREP '^[<>] (XPASS|FAIL)' >/dev/null; then
echo true
else
echo false
diff --git a/contrib/warn_summary b/contrib/warn_summary
index d4c8b6cdb19..afa11802ee1 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)/'
+  $EGREP -v '/gcc/(ch|cp|f|fortran|ada|intl|fixinc)/'
 else
   # Pass through only subdir $filter.
   grep "/gcc/$filter/"
@@ -155,6 +155,17 @@ if test -z "$AWK" ; then
   done
 fi
 
+# Prefer "grep -E" which should work with POSIX-conform grep, but fallback
+# to "egrep" (which is deprecated for a long time) if grep does not support
+# -E.
+if test -z "$EGREP" ; then
+  if echo a | grep -E '(a|b)' > /dev/null 2> /dev/null; then
+EGREP="grep -E"
+  else
+EGREP="egrep"
+  fi
+fi
+
 # Parse command line arguments.
 while test -n "$1" ; do
  case "$1" in
-- 
2.36.1

[PATCH v2 5/7] testsuite: stop using obsoleted 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.

However, simply replacing egrep with grep -E will break build on some
systems (notably Solaris) w/o a POSIX-conform grep.  We detect a
suitable command with AC_PROG_EGREP, and pass it to run_acats.sh for
Ada.

For Go, simply use grep instead of egrep as the pattern does not need
any ERE features.

gcc/ChangeLog:

* Makefile.in (EGREP): New variable.
* configure.ac (AC_PROG_EGREP): Call it.
* configure: Regenerate.

gcc/ada/ChangeLog:

* gcc-interface/Make-lang.in: Pass EGREP to run_acats.sh.

gcc/testsuite/ChangeLog:

* ada/acats/run_all.sh: Use $EGREP instead of egrep.
* go.test/go-test.exp: Use grep intead of egrep.
---
 gcc/Makefile.in|  1 +
 gcc/ada/gcc-interface/Make-lang.in |  3 +-
 gcc/configure  | 71 +-
 gcc/configure.ac   |  1 +
 gcc/testsuite/ada/acats/run_all.sh |  8 +++-
 gcc/testsuite/go.test/go-test.exp  |  2 +-
 6 files changed, 81 insertions(+), 5 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index b6dcc45a58a..8b95ee20b46 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1090,6 +1090,7 @@ BACKENDLIBS = $(ISLLIBS) $(GMPLIBS) $(PLUGINLIBS) 
$(HOST_LIBS) \
 SYSLIBS = @GNAT_LIBEXC@
 
 # Used from ada/gcc-interface/Make-lang.in
+EGREP = @EGREP@
 GNATBIND = @GNATBIND@
 GNATMAKE = @GNATMAKE@
 
diff --git a/gcc/ada/gcc-interface/Make-lang.in 
b/gcc/ada/gcc-interface/Make-lang.in
index 1e245ed3b0f..e0cbb6ab1ed 100644
--- a/gcc/ada/gcc-interface/Make-lang.in
+++ b/gcc/ada/gcc-interface/Make-lang.in
@@ -1050,7 +1050,8 @@ check-acats:
  rm -rf $(ACATSDIR)-parallel; \
  mkdir $(ACATSDIR)-parallel; \
  ( testdir=`cd ${srcdir}/${ACATSDIR} && ${PWD_COMMAND}`; \
-   export testdir; \
+   EGREP="$EGREP"; \
+   export testdir EGREP; \
cd $(ACATSDIR) && $(SHELL) $${testdir}/$(ACATSCMD) NONE ) \
|| exit 1; \
  GCC_RUNTEST_PARALLELIZE_DIR=$$rootme/$(ACATSDIR)-parallel; \
diff --git a/gcc/configure b/gcc/configure
index c58ec9b2273..8bd384c3fcc 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -8416,6 +8416,73 @@ case ${AWK} in
   "") as_fn_error $? "can't build without awk, bailing out" "$LINENO" 5 ;;
 esac
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for egrep" >&5
+$as_echo_n "checking for egrep... " >&6; }
+if ${ac_cv_path_EGREP+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  if echo a | $GREP -E '(a|b)' >/dev/null 2>&1
+   then ac_cv_path_EGREP="$GREP -E"
+   else
+ if test -z "$EGREP"; then
+  ac_path_EGREP_found=false
+  # Loop through the user's path and test for each of PROGNAME-LIST
+  as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
+for as_dir in $PATH$PATH_SEPARATOR/usr/xpg4/bin
+do
+  IFS=$as_save_IFS
+  test -z "$as_dir" && as_dir=.
+for ac_prog in egrep; do
+for ac_exec_ext in '' $ac_executable_extensions; do
+  ac_path_EGREP="$as_dir/$ac_prog$ac_exec_ext"
+  as_fn_executable_p "$ac_path_EGREP" || continue
+# Check for GNU ac_path_EGREP and select it if it is found.
+  # Check for GNU $ac_path_EGREP
+case `"$ac_path_EGREP" --version 2>&1` in
+*GNU*)
+  ac_cv_path_EGREP="$ac_path_EGREP" ac_path_EGREP_found=:;;
+*)
+  ac_count=0
+  $as_echo_n 0123456789 >"conftest.in"
+  while :
+  do
+cat "conftest.in" "conftest.in" >"conftest.tmp"
+mv "conftest.tmp" "conftest.in"
+cp "conftest.in" "conftest.nl"
+$as_echo 'EGREP' >> "conftest.nl"
+"$ac_path_EGREP" 'EGREP$' < "conftest.nl" >"conftest.out" 2>/dev/null || 
break
+diff "conftest.out" "conftest.nl" >/dev/null 2>&1 || break
+as_fn_arith $ac_count + 1 && ac_count=$as_val
+if test $ac_count -gt ${ac_path_EGREP_max-0}; then
+  # Best one so far, save it but keep looking for a better one
+  ac_cv_path_EGREP="$ac_path_EGREP"
+  ac_path_EGREP_max=$ac_count
+fi
+# 10*(2^10) chars as input seems more than enough
+test $ac_count -gt 10 && break
+  done
+  rm -f conftest.in conftest.tmp conftest.nl conftest.out;;
+esac
+
+  $ac_path_EGREP_found && break 3
+done
+  done
+  done
+IFS=$as_save_IFS
+  if test -z "$ac_cv_path_EGREP"; then
+as_fn_error $? "no acceptable egrep could be found in 
$PATH$PATH_SEPARATOR/usr/xpg4/bin" "$LINENO" 5
+  fi
+else
+  ac_cv_path_EGREP=$EGREP
+fi
+
+   fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_path_EGREP" >&5
+$as_echo "$ac_cv_path_EGREP" >&6; }
+ EGREP="$ac_cv_path_EGREP"
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether ln -s works" >&5
 $as_echo_n "checking whether ln -s works... " >&6; }
 if ${gcc_cv_prog_LN_S+:} false; then :
@@ -19675,7 +19742,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19678 

[PATCH v2 3/7] libbacktrace: use grep 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.
But, we can't simply replace fgrep to grep -F, or the build will break
with some non-GNU grep implementations (lacking -F support).

As "add-gnu-debuglink" is definitely not a non-trivial regex, simply
replace fgrep with grep.

libbacktrace/ChangeLog:

* configure.ac (AC_PROG_FGREP): Use grep 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..537486d34f2 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 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..857987a2859 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 add-gnu-debuglink >/dev/null 2>&1; then
   libbacktrace_cv_objcopy_debuglink=yes
 else
   libbacktrace_cv_objcopy_debuglink=no
-- 
2.36.1

[PATCH v2 2/7] fixincludes: use grep 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.

But, we can't simply replace egrep to grep -E or fgrep to grep -F or the
build will break with some non-GNU grep implementations (lacking -E or
-F support).  autoconf documentation suggests to use AC_PROG_EGREP and
$EGREP or AC_PROG_FGREP and FGREP, but doing so is too complicated for
fixincludes.

So we simply adjust the patterns for a plain grep, instead of relying on
the behavior of grep -E/-F.

Q: Why "[ \t][ \t]*" instead of "[ \t]\\+"?
A: POSIX does not allow escaping + in BRE.

fixincludes/ChangeLog:

* fixinc.in: Use grep instead of egrep.
* inclhack.def: Use grep instead of egrep, and adjust an
regular expression to make it a BRE.
* genfixes: Use grep instead of egrep, and escape "." in the
pattern.
* fixincl.x: Regenerate.
---
 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..a4cd3d0fbb4 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 '^[   ]*#[]*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..c9b4cf504f2 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 25, 2022 at 12:44:14 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 Sat Jun 25 12:44:14 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 'define[ \t][ \t]*DBL_MAX[ \t][ \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 '#include' $file`\"";
 tSCC zVxworks_Needs_VxworksTest2[] =
-   " -n \"`egrep ULONG $file`\"";
+   " -n \"`grep ULONG $file`\"";
 
 #defineVXWORKS_NEEDS_VXWORKS_TEST_CT  4
 static tTestDesc aVxworks_Needs_VxworksTests[] = {
diff --git a/fixincludes/genfixes b/fixincludes/genfixes
index 47aad01289d..3a4c05c832b 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 ' 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..080bbc010dc 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 'define[ \t][ \t]*DBL_MAX[ \t][ \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 '#include' $file`\"";
+test = " -n \"`grep ULONG $file`\"";
 select   = "#[ \t]define[ \t]+__INCstath";
 
 sed = "/#[ \t]define[ \t][ \t]*__INCstath/a\\\n"
-- 
2.36.1

[PATCH v2 1/7] config: use $EGREP instead of egrep

[Xi Ruoyao via Gcc-patches]

egrep has been deprecated in favor of grep -E for a long time, and the
next GNU grep release (3.8 or 4.0) will print a warning if egrep is used.
Unfortunately, old hosts with non-GNU grep may lack the support for -E
option.  Use AC_PROG_EGREP and $EGREP variable so we'll work fine on
both old and new platforms.

ChangeLog:

* configure.ac: Call AC_PROG_EGREP, and use $EGREP instead of
egrep.
* config.rpath: Use $EGREP instead of egrep.
* configure: Regenerate.

config/ChangeLog:

* lib-ld.m4 (AC_LIB_PROG_LD_GNU): Call AC_PROG_EGREP, and use
$EGREP instead of egrep.
(acl_cv_path_LD): Likewise.
* lib-link.m4 (AC_LIB_RPATH): Call AC_PROG_EGREP, and pass
$EGREP to config.rpath.

gcc/ChangeLog:

* configure: Regenerate.

intl/ChangeLog:

* configure: Regenerate.

libcpp/ChangeLog:

* configure: Regenerate.

libgcc/ChangeLog:

* configure: Regenerate.

libstdc++-v3/ChangeLog:

* configure: Regenerate.
---
 config.rpath   |  10 +--
 config/lib-ld.m4   |   6 +-
 config/lib-link.m4 |   4 +-
 configure  | 136 -
 configure.ac   |   5 +-
 gcc/configure  |  13 ++--
 intl/configure |   9 +--
 libcpp/configure   |   9 +--
 libgcc/configure   |   2 +-
 libstdc++-v3/configure |   9 +--
 10 files changed, 172 insertions(+), 31 deletions(-)

diff --git a/config.rpath b/config.rpath
index 4dea75957c2..4ada7468c22 100755
--- a/config.rpath
+++ b/config.rpath
@@ -29,7 +29,7 @@
 #CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
 # or
 #CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
-# The environment variables CC, GCC, LDFLAGS, LD, with_gnu_ld
+# The environment variables CC, GCC, EGREP, LDFLAGS, LD, with_gnu_ld
 # should be set by the caller.
 #
 # The set of defined variables is at the end of this script.
@@ -143,7 +143,7 @@ if test "$with_gnu_ld" = yes; then
   ld_shlibs=no
   ;;
 beos*)
-  if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+  if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null; 
then
 :
   else
 ld_shlibs=no
@@ -162,9 +162,9 @@ if test "$with_gnu_ld" = yes; then
 netbsd*)
   ;;
 solaris* | sysv5*)
-  if $LD -v 2>&1 | egrep 'BFD 2\.8' > /dev/null; then
+  if $LD -v 2>&1 | $EGREP 'BFD 2\.8' > /dev/null; then
 ld_shlibs=no
-  elif $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; 
then
+  elif $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null; 
then
 :
   else
 ld_shlibs=no
@@ -174,7 +174,7 @@ if test "$with_gnu_ld" = yes; then
   hardcode_direct=yes
   ;;
 *)
-  if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; then
+  if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null; 
then
 :
   else
 ld_shlibs=no
diff --git a/config/lib-ld.m4 b/config/lib-ld.m4
index 11d0ce77342..88a014b7a74 100644
--- a/config/lib-ld.m4
+++ b/config/lib-ld.m4
@@ -14,7 +14,8 @@ dnl From libtool-1.4. Sets the variable with_gnu_ld to yes or 
no.
 AC_DEFUN([AC_LIB_PROG_LD_GNU],
 [AC_CACHE_CHECK([if the linker ($LD) is GNU ld], acl_cv_prog_gnu_ld,
 [# I'd rather use --version here, but apparently some GNU ld's only accept -v.
-if $LD -v 2>&1 &5; then
+AC_REQUIRE([AC_PROG_EGREP])dnl
+if $LD -v 2>&1 &5; then
   acl_cv_prog_gnu_ld=yes
 else
   acl_cv_prog_gnu_ld=no
@@ -28,6 +29,7 @@ AC_DEFUN([AC_LIB_PROG_LD],
 [  --with-gnu-ld   assume the C compiler uses GNU ld [default=no]],
 test "$withval" = no || with_gnu_ld=yes, with_gnu_ld=no)
 AC_REQUIRE([AC_PROG_CC])dnl
+AC_REQUIRE([AC_PROG_EGREP])dnl
 AC_REQUIRE([AC_CANONICAL_HOST])dnl
 # Prepare PATH_SEPARATOR.
 # The user is always right.
@@ -88,7 +90,7 @@ AC_CACHE_VAL(acl_cv_path_LD,
   # Check to see if the program is GNU ld.  I'd rather use --version,
   # but apparently some GNU ld's only accept -v.
   # Break only if it was the GNU/non-GNU ld that we prefer.
-  if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > 
/dev/null; then
+  if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' > 
/dev/null; then
test "$with_gnu_ld" != no && break
   else
test "$with_gnu_ld" != yes && break
diff --git a/config/lib-link.m4 b/config/lib-link.m4
index 20e281fd323..5bbbd999de0 100644
--- a/config/lib-link.m4
+++ b/config/lib-link.m4
@@ -99,8 +99,10 @@ AC_DEFUN([AC_LIB_RPATH],
   AC_REQUIRE([AC_LIB_PROG_LD])dnl we use $LD, $with_gnu_ld
   AC_REQUIRE([AC_CANONICAL_HOST]) dnl we use $host
   AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT]) dnl we use $ac_aux_dir
+  AC_REQUIRE([AC_PROG_EGREP]) dnl we use $GREP
   AC_CACHE_CHECK([for shared library run path origin], acl_cv_rpath, [
-CC="$CC" GCC="$GCC" LDFLAGS="$LDFLAGS" LD="$LD" with_gnu_ld="$with_gnu_ld" 
\
+

[PATCH v2 0/7] Avoid using obsoleted egrep/fgrep

[Xi Ruoyao via Gcc-patches]

egrep and fgrep have been deprecated for a long time, and the next grep
release will emit a warning if egrep or fgrep is invoked:

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

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

I've not touched libgo because I'm not familiar with it.  And, for
contrib/gen_auto_fdo_event.py and gcc/config/i386/gcc-auto-profile I'll
submit a patch porting gen_auto_fdo_event.py to Python 3 and regenerate
gcc-auto-profile separately and include the egrep fix in that patch.

Bootstrapped and regtested on x86_64-linux-gnu and sparc-sun-solaris2.11
(gcc211.fsffrance.org, where grep does not support -E and autoconf sets
EGREP="ggrep -E").

Xi Ruoyao (7):
  config: use $EGREP instead of egrep
  fixincludes: use grep instead of egrep/fgrep
  libbacktrace: use grep instead of fgrep
  fortran: use grep instead of fgrep
  testsuite: stop using obsoleted egrep
  contrib: use grep -E instead of egrep
  libffi: Use $EGREP instead of egrep

 config.rpath   |  10 +-
 config/lib-ld.m4   |   6 +-
 config/lib-link.m4 |   4 +-
 configure  | 136 ++-
 configure.ac   |   5 +-
 contrib/check_GNU_style.sh |  10 +-
 contrib/test_summary   |  13 +-
 contrib/warn_summary   |  13 +-
 fixincludes/fixinc.in  |   2 +-
 fixincludes/fixincl.x  |  10 +-
 fixincludes/genfixes   |   2 +-
 fixincludes/inclhack.def   |   6 +-
 gcc/Makefile.in|   1 +
 gcc/ada/gcc-interface/Make-lang.in |   3 +-
 gcc/configure  |  80 -
 gcc/configure.ac   |   1 +
 gcc/fortran/Make-lang.in   |   2 +-
 gcc/testsuite/ada/acats/run_all.sh |   8 +-
 gcc/testsuite/go.test/go-test.exp  |   2 +-
 intl/configure |   9 +-
 libbacktrace/configure |   2 +-
 libbacktrace/configure.ac  |   2 +-
 libcpp/configure   |   9 +-
 libffi/configure   | 270 ++---
 libffi/configure.ac|   3 +-
 libgcc/configure   |   2 +-
 libstdc++-v3/configure |   9 +-
 27 files changed, 430 insertions(+), 190 deletions(-)

-- 
2.36.1