Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Richard Biener via Gcc-patches]

On Thu, May 14, 2020 at 11:53 PM Jason Merrill via Gcc-patches
 wrote:
>
> There seemed to be general agreement last November that we would move to
> allowing C++11 features to be used in GCC 11; this patch implements that
> direction.  Are changes needed anywhere else?
>
> ChangeLog
> 2020-05-14  Jason Merrill  
>
> * configure.ac: Update bootstrap dialect to -std=gnu++11.
>
> gcc/ChangeLog
> 2020-05-14  Jason Merrill  
>
> * doc/install.texi (Prerequisites): Update boostrap compiler
> requirement to C++11/GCC 4.8.
> ---
>  gcc/doc/install.texi | 14 --
>  configure.ac |  6 +++---
>  ChangeLog|  4 
>  configure|  6 +++---
>  4 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 876b04f9c45..f47e3c76f73 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -238,15 +238,17 @@ described below.
>
>  @heading Tools/packages necessary for building GCC
>  @table @asis
> -@item ISO C++98 compiler
> -Necessary to bootstrap GCC, although versions of GCC prior
> -to 4.8 also allow bootstrapping with a ISO C89 compiler and versions
> -of GCC prior to 3.4 also allow bootstrapping with a traditional
> -(K&R) C compiler.
> +@item ISO C++11 compiler
> +Necessary to bootstrap GCC.
> +
> +Versions of GCC prior to 11 also allow bootstrapping with an ISO C++98
> +compiler, versions of GCC prior to 4.8 also allow bootstrapping with a
> +ISO C89 compiler, and versions of GCC prior to 3.4 also allow
> +bootstrapping with a traditional (K&R) C compiler.
>
>  To build all languages in a cross-compiler or other configuration where
>  3-stage bootstrap is not performed, you need to start with an existing
> -GCC binary (version 3.4 or later) because source code for language
> +GCC binary (version 4.8 or later) because source code for language
>  frontends other than C might use GCC extensions.
>
>  Note that to bootstrap GCC with versions of GCC earlier than 3.4, you
> diff --git a/configure.ac b/configure.ac
> index c78d9cbea62..63d92b73061 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1462,10 +1462,10 @@ case "$have_compiler:$host:$target:$enable_bootstrap" 
> in
>  ;;
>  esac
>
> -# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a
> -# C++98 compiler can still start the bootstrap.
> +# When bootstrapping with GCC, build stage 1 in C++11 mode to ensure that a
> +# C++11 compiler can still start the bootstrap.
>  if test "$enable_bootstrap:$GXX" = "yes:yes"; then
> -  CXX="$CXX -std=gnu++98"
> +  CXX="$CXX -std=gnu++11"

So I just spotted this - since we're requiring a ISO C++11 compiler shouldn't
we build stage1 with -std=c++11 rather than gnu++11 (whatever the detailed
differences are here)?  Also not sure what level of -pedantic we'd need to
avoid GNU extensions even with -std=c++11.  Of course there are (I hope)
a lot less GNU extensions for C++ than there were for C and hopefully
no extra in gnu++11 compared to gnu++98 which we checked previously.

Note I think what's missing is some general blurb in our coding conventions
as to how much of C++11 we are supposed to use in non-infrastructure parts
of GCC (I expect things like hash-table.h to use more C++ features than,
say, tree-ssa-alias.c).

There also does not seem to be a configure check which may present
users with a more useful error message than later cryptic fail of build?
I suppose we cannot simply check __cplusplus for this, can we?  Do
other common host compilers need additional options to enable C++11?
Should we try to second guess such flags via configury?  For example
GCC 4.8 defaults to -std=gnu++98 and the above only seems to apply
to the bootstrap case so GCC 4.8 cannot be used to build cross compilers
without adjusting CC and CXX?

Thanks,
Richard.

>  fi
>
>  # Used for setting $lt_cv_objdir
> diff --git a/ChangeLog b/ChangeLog
> index a7fcf77b9b2..1d281855a3e 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2020-05-14  Jason Merrill  
> +
> +   * configure.ac: Update bootstrap dialect to -std=gnu++11.
> +
>  2020-04-29  Thomas Schwinge  
>
> PR target/92713
> diff --git a/configure b/configure
> index 4cc938ebb7d..9b39035bbcc 100755
> --- a/configure
> +++ b/configure
> @@ -5523,10 +5523,10 @@ $as_echo "$as_me: WARNING: trying to bootstrap a 
> cross compiler" >&2;}
>  ;;
>  esac
>
> -# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a
> -# C++98 compiler can still start the bootstrap.
> +# When bootstrapping with GCC, build stage 1 in C++11 mode to ensure that a
> +# C++11 compiler can still start the bootstrap.
>  if test "$enable_bootstrap:$GXX" = "yes:yes"; then
> -  CXX="$CXX -std=gnu++98"
> +  CXX="$CXX -std=gnu++11"
>  fi
>
>  # Used for setting $lt_cv_objdir
>
> base-commit: 4e1592f8e1d6366699e05c0824fc3dc39ca7314b
> --
> 2.18.1
>

Re: [PATCH] x86: Add -mavoid-libcall for -mgeneral-regs-only

[Richard Biener via Gcc-patches]

On Fri, May 15, 2020 at 8:27 AM Uros Bizjak via Gcc-patches
 wrote:
>
> On Fri, May 15, 2020 at 1:13 AM H.J. Lu  wrote:
> >
> > The -mgeneral-regs-only option generates code that uses only the
> > general-purpose registers.  It prevents the compiler from using vector
> > registers.  But GCC may still generate calls to memcpy, memmove, memset
> > and memcmp library functions.  In the GNU C library, these library
> > functions are implementated with vector registers, which makes the
> > -mgeneral-regs-only option less effective.  The new -mavoid-libcall
> > option expands memcpy, memmove and memset into REP MOVSB and REP STOSB
> > sequence.  This option can be further enhanced with a cmpmem pattern
> > to expand memcmp into REP CMPSB sequence in the future.
> >
> > Tested on Linux/x86 and Linux/x86-64.  OK for master?
>
> No. Library should provide functions that are appropriate for your
> target. There are probably other places in the library that use XMM
> registers, so there is no point working around only some specific
> functions.

For those specific functions -minline-all-stringops should also work, no?

Richard.

> Uros.
>
> > Thanks.
> >
> > H.J.
> > ---
> > gcc/
> >
> > PR target/95134
> > * config/i386/i386-expand.c (alg_usable_p): Return false for
> > libcall with -mavoid-libcall.
> > (decide_alg): Avoid libcall and rep_prefix_1_byte instead of
> > libcall with -mavoid-libcall.
> > * config/i386/i386.opt: Add -mavoid-libcall.
> > * doc/invoke.texi: Document -mavoid-libcall.
> >
> > gcc/testsuite/
> >
> > PR target/95134
> > * gcc.target/i386/pr95134-1.c: New test.
> > * gcc.target/i386/pr95134-2.c: Likewise.
> > * gcc.target/i386/pr95134-3.c: Likewise.
> > * gcc.target/i386/pr95134-4.c: Likewise.
> > ---
> >  gcc/config/i386/i386-expand.c | 15 ++-
> >  gcc/config/i386/i386.opt  |  6 +-
> >  gcc/doc/invoke.texi   | 10 +-
> >  gcc/testsuite/gcc.target/i386/pr95134-1.c | 18 ++
> >  gcc/testsuite/gcc.target/i386/pr95134-2.c | 18 ++
> >  gcc/testsuite/gcc.target/i386/pr95134-3.c | 18 ++
> >  gcc/testsuite/gcc.target/i386/pr95134-4.c | 11 +++
> >  7 files changed, 89 insertions(+), 7 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr95134-1.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr95134-2.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr95134-3.c
> >  create mode 100644 gcc/testsuite/gcc.target/i386/pr95134-4.c
> >
> > diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
> > index 26531585c5f..b38463bf88c 100644
> > --- a/gcc/config/i386/i386-expand.c
> > +++ b/gcc/config/i386/i386-expand.c
> > @@ -6816,7 +6816,7 @@ alg_usable_p (enum stringop_alg alg, bool memset, 
> > bool have_as)
> >   || (memset ? fixed_regs[AX_REG] : fixed_regs[SI_REG]))
> > return false;
> >  }
> > -  return true;
> > +  return !flag_avoid_libcall || alg != libcall;
> >  }
> >
> >  /* Given COUNT and EXPECTED_SIZE, decide on codegen of string operation.  
> > */
> > @@ -6889,7 +6889,7 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT 
> > expected_size,
> >   setup.  */
> >else if (expected_size != -1 && expected_size < 4)
> >  return loop_1_byte;
> > -  else if (expected_size != -1)
> > +  else if (expected_size != -1 && !flag_avoid_libcall)
> >  {
> >enum stringop_alg alg = libcall;
> >bool alg_noalign = false;
> > @@ -6934,6 +6934,9 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT 
> > expected_size,
> > }
> > }
> >  }
> > +
> > +  enum stringop_alg alg;
> > +
> >/* When asked to inline the call anyway, try to pick meaningful choice.
> >   We look for maximal size of block that is faster to copy by hand and
> >   take blocks of at most of that size guessing that average size will
> > @@ -6945,7 +6948,6 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT 
> > expected_size,
> >&& (algs->unknown_size == libcall
> >   || !alg_usable_p (algs->unknown_size, memset, have_as)))
> >  {
> > -  enum stringop_alg alg;
> >HOST_WIDE_INT new_expected_size = (max > 0 ? max : 4096) / 2;
> >
> >/* If there aren't any usable algorithms or if recursing already,
> > @@ -6967,8 +6969,11 @@ decide_alg (HOST_WIDE_INT count, HOST_WIDE_INT 
> > expected_size,
> > gcc_assert (alg != libcall);
> >return alg;
> >  }
> > -  return (alg_usable_p (algs->unknown_size, memset, have_as)
> > - ? algs->unknown_size : libcall);
> > +  alg = (alg_usable_p (algs->unknown_size, memset, have_as)
> > +? algs->unknown_size : libcall);
> > +  if (flag_avoid_libcall && alg == libcall)
> > +alg = rep_prefix_1_byte;
> > +  return alg;
> >  }
> >
> >  /* Decide on alignment.  We know that the operand is already aligned to 
>

[committed] i386: Add V2SFmode hadd/hsub instructions [PR95046]

[Uros Bizjak via Gcc-patches]

PFACC/PFNACC 3dNow! instructions got their corresponding SSE alternative
in SSE3, so these can't be implemented with TARGET_MMX_WITH_SSE, which
implies SSE2.  These instructions are only generated via builtins, and
since several 3dNow! insns have no corresponding SSE alternative,
we can't avoid MMX registers with 3dNow! builtins anyway.

Add SSE3/AVX alternatives to the insn pattern, so compiler will be able
to use XMM registers when available, but don't prevent MMX registers,
since they are needed when SSE3 is not active.

Add additional generic insn patterns, used by the combiner to
synthesize horizontal V2SFmode add/sub instructions.  These patterns
are active for TARGET_MMX_WITH_SSE only, and use only XMM registers.

gcc/ChangeLog:

2020-05-15  Uroš Bizjak  

PR target/95046
* config/i386/i386.md (isa): Add sse3_noavx.
(enabled): Handle sse3_noavx.

* config/i386/mmx.md (mmx_haddv2sf3): New expander.
(*mmx_haddv2sf3): Rename from mmx_haddv2sf3.  Add SSE/AVX
alternatives.  Match commutative vec_select selector operands.
(*mmx_haddv2sf3_low): New insn pattern.

(*mmx_hsubv2sf3): Add SSE/AVX alternatives.
(*mmx_hsubv2sf3_low): New insn pattern.

testsuite/ChangeLog:

2020-05-15  Uroš Bizjak  

PR target/95046
* gcc.target/i386/pr95046-8.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 722eb9b5ec8..b555c165647 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -803,8 +803,8 @@
 
 ;; Used to control the "enabled" attribute on a per-instruction basis.
 (define_attr "isa" "base,x64,x64_sse2,x64_sse4,x64_sse4_noavx,x64_avx,nox64,
-   sse_noavx,sse2,sse2_noavx,sse3,sse4,sse4_noavx,avx,noavx,
-   avx2,noavx2,bmi,bmi2,fma4,fma,avx512f,noavx512f,
+   sse_noavx,sse2,sse2_noavx,sse3,sse3_noavx,sse4,sse4_noavx,
+   avx,noavx,avx2,noavx2,bmi,bmi2,fma4,fma,avx512f,noavx512f,
avx512bw,noavx512bw,avx512dq,noavx512dq,
avx512vl,noavx512vl,x64_avx512dq,x64_avx512bw"
   (const_string "base"))
@@ -834,6 +834,8 @@
 (eq_attr "isa" "sse2_noavx")
   (symbol_ref "TARGET_SSE2 && !TARGET_AVX")
 (eq_attr "isa" "sse3") (symbol_ref "TARGET_SSE3")
+(eq_attr "isa" "sse3_noavx")
+  (symbol_ref "TARGET_SSE3 && !TARGET_AVX")
 (eq_attr "isa" "sse4") (symbol_ref "TARGET_SSE4_1")
 (eq_attr "isa" "sse4_noavx")
   (symbol_ref "TARGET_SSE4_1 && !TARGET_AVX")
diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md
index 2955ca2898f..f73c8452651 100644
--- a/gcc/config/i386/mmx.md
+++ b/gcc/config/i386/mmx.md
@@ -530,43 +530,109 @@
(set_attr "prefix_extra" "1")
(set_attr "mode" "V2SF")])
 
-(define_insn "mmx_haddv2sf3"
-  [(set (match_operand:V2SF 0 "register_operand" "=y")
+(define_expand "mmx_haddv2sf3"
+  [(set (match_operand:V2SF 0 "register_operand")
(vec_concat:V2SF
  (plus:SF
(vec_select:SF
- (match_operand:V2SF 1 "register_operand" "0")
- (parallel [(const_int  0)]))
+ (match_operand:V2SF 1 "register_operand")
+ (parallel [(const_int 0)]))
(vec_select:SF (match_dup 1) (parallel [(const_int 1)])))
  (plus:SF
-(vec_select:SF
- (match_operand:V2SF 2 "nonimmediate_operand" "ym")
- (parallel [(const_int  0)]))
+   (vec_select:SF
+ (match_operand:V2SF 2 "nonimmediate_operand")
+ (parallel [(const_int 0)]))
(vec_select:SF (match_dup 2) (parallel [(const_int 1)])]
-  "TARGET_3DNOW"
-  "pfacc\t{%2, %0|%0, %2}"
-  [(set_attr "type" "mmxadd")
-   (set_attr "prefix_extra" "1")
-   (set_attr "mode" "V2SF")])
+  "TARGET_3DNOW")
+
+(define_insn "*mmx_haddv2sf3"
+  [(set (match_operand:V2SF 0 "register_operand" "=y,x,x")
+   (vec_concat:V2SF
+ (plus:SF
+   (vec_select:SF
+ (match_operand:V2SF 1 "register_operand" "0,0,x")
+ (parallel [(match_operand:SI 3 "const_0_to_1_operand")]))
+   (vec_select:SF (match_dup 1)
+   (parallel [(match_operand:SI 4 "const_0_to_1_operand")])))
+ (plus:SF
+(vec_select:SF
+ (match_operand:V2SF 2 "nonimmediate_operand" "ym,x,x")
+ (parallel [(match_operand:SI 5 "const_0_to_1_operand")]))
+   (vec_select:SF (match_dup 2)
+   (parallel [(match_operand:SI 6 "const_0_to_1_operand")])]
+  "TARGET_3DNOW
+   && INTVAL (operands[3]) != INTVAL (operands[4])
+   && INTVAL (operands[5]) != INTVAL (operands[6])"
+  "@
+   pfacc\t{%2, %0|%0, %2}
+   haddps\t{%2, %0|%0, %2}
+   vhaddps\t{%2, %1, %0|%0, %1, %2}"
+  [(set_attr "isa" "*,sse3_noavx,avx")
+   (set_attr "type" "mmxadd,sseadd,sseadd")
+   (set_attr "prefix_extra" "1,*,*")
+   (set_attr "prefix" "*,orig,vex")
+   (set_attr "mode" "V2SF,V4SF,V

[PATCH] tree-optimization/95133 - avoid abnormal edges in path splitting

[Richard Biener]

When path splitting tries to detect a CFG diamond make sure it
is composed of normal (non-EH, not abnormal) edges.  Otherwise
CFG manipulation later may fail.

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2020-05-15  Richard Biener  

PR tree-optimization/95133
* gimple-ssa-split-paths.c
(find_block_to_duplicate_for_splitting_paths): Check for
normal edges.

* gcc.dg/pr95133.c: New testcase.
---
 gcc/gimple-ssa-split-paths.c   | 10 --
 gcc/testsuite/gcc.dg/pr95133.c | 14 ++
 2 files changed, 22 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr95133.c

diff --git a/gcc/gimple-ssa-split-paths.c b/gcc/gimple-ssa-split-paths.c
index 1a56868f6a3..b3efd43c7ef 100644
--- a/gcc/gimple-ssa-split-paths.c
+++ b/gcc/gimple-ssa-split-paths.c
@@ -67,8 +67,14 @@ find_block_to_duplicate_for_splitting_paths (basic_block 
latch)
 region.  Verify that it is.
 
 First, verify that BB has two predecessors (each arm of the
-IF-THEN-ELSE) and two successors (the latch and exit).  */
-  if (EDGE_COUNT (bb->preds) == 2 && EDGE_COUNT (bb->succs) == 2)
+IF-THEN-ELSE) and two successors (the latch and exit) and that
+all edges are normal.  */
+  if (EDGE_COUNT (bb->preds) == 2
+ && !(EDGE_PRED (bb, 0)->flags & EDGE_COMPLEX)
+ && !(EDGE_PRED (bb, 1)->flags & EDGE_COMPLEX)
+ && EDGE_COUNT (bb->succs) == 2
+ && !(EDGE_SUCC (bb, 0)->flags & EDGE_COMPLEX)
+ && !(EDGE_SUCC (bb, 1)->flags & EDGE_COMPLEX))
{
  /* Now verify that BB's immediate dominator ends in a
 conditional as well.  */
diff --git a/gcc/testsuite/gcc.dg/pr95133.c b/gcc/testsuite/gcc.dg/pr95133.c
new file mode 100644
index 000..523decaf90e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr95133.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" } */
+
+extern int a[16];
+void f (int *ip, int x)
+{
+  int *xp = a;
+  for (int i=0; i<8; ++i)
+  {
+base: if (x) return;
+  }
+  *xp++ = *ip;
+  goto *(&&base + *ip);
+}
-- 
2.26.1

Re: [PATCH] x86: Default CET run-time support to auto

[Richard Biener]

On Thu, 14 May 2020, Jeff Law wrote:

> On Fri, 2020-05-08 at 06:44 -0700, H.J. Lu wrote:
> > CET has been added since GCC 8.  This patch defaults CET run-time support
> > to auto.  It enables CET run-time support if asssembler supports CET
> > instructions and multi-byte NOPs are enabled via SSE2.
> > 
> > OK for master?
> > 
> > Thanks.
> > 
> > H.J.
> > ---
> > config/
> > 
> > * cet.m4 (GCC_CET_FLAGS): Change default to auto.
> > 
> > libatomic/
> > 
> > * configure: Regenerated.
> > 
> > libbacktrace/
> > 
> > * configure: Regenerated.
> > 
> > libgcc/
> > 
> > * configure: Regenerated.
> > 
> > libgfortran/
> > 
> > * configure: Regenerated.
> > 
> > libgomp/
> > 
> > * configure: Regenerated.
> > 
> > libitm/
> > 
> > * configure: Regenerated.
> > 
> > libobjc/
> > 
> > * configure: Regenerated.
> > 
> > libquadmath/
> > 
> > * configure: Regenerated.
> > 
> > libsanitizer/
> > 
> > * configure: Regenerated.
> > 
> > libssp/
> > 
> > * configure: Regenerated.
> > 
> > libstdc++-v3/
> > 
> > * configure: Regenerated.
> > 
> > libvtv/
> > 
> > * configure: Regenerated.
> OK

This caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95147

Richard.

> jeff
> > 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Richard Sandiford]

Richard Biener via Gcc-patches  writes:
> Note I think what's missing is some general blurb in our coding conventions
> as to how much of C++11 we are supposed to use in non-infrastructure parts
> of GCC (I expect things like hash-table.h to use more C++ features than,
> say, tree-ssa-alias.c).

I guess there are two aspects to that:

- Are there any specific features we should avoid using at all?
  TBH I hope not.  Trying to police this based on C++ feature sounds
  difficulty and might be counterproductive.

  IMO it should just (continue to) be based on principles like avoiding
  abstraction for abstraction's sake, and keeping compiler performance
  and code size in mind.  Even tree-ssa-alias.c should be able to use
  any C++ feature if there's a justification.

- Coding conventions for when features should be used.  "auto" is an
  obvious one.  Maybe also lambdas (which should help avoid the horrible
  "void *" callback parameters we have all over the place now).

Maybe also guidelines to actively use certain features, e.g.

- use "= default" where possible

- prefer range-based for loops to macros

- mark "operator bool()" conversions as explicit

- use "override" where applicable

(all obvious I guess), etc.

Thanks,
Richard

[committed] libiberty: Handle @live attribute in D demangler.

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds support for demangling D functions annotated with the
new ownership/borrowing system attribute.

Following Jeff's advice from the last patch review, this has been
regression tested and committed to mainline.  Firstly, as it is assumed
this falls under my D front-end maintainer status, secondly, this change
is quite obvious, so there ought to be no objections to it.

Regards
Iain.

---
libiberty/ChangeLog:

* d-demangle.c (dlang_attributes): Add @live attribute.
* testsuite/d-demangle-expected: Add new tests.
---
 libiberty/d-demangle.c  | 4 
 libiberty/testsuite/d-demangle-expected | 8 
 2 files changed, 12 insertions(+)

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 5856bc2930f..f2d6946ecad 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -578,6 +578,10 @@ dlang_attributes (string *decl, const char *mangled)
  mangled++;
  string_append (decl, "scope ");
  continue;
+   case 'm': /* @live */
+ mangled++;
+ string_append (decl, "@live ");
+ continue;
 
default: /* unknown attribute */
  return NULL;
diff --git a/libiberty/testsuite/d-demangle-expected 
b/libiberty/testsuite/d-demangle-expected
index 47b24ea48ae..e3f32e31d7b 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -462,6 +462,10 @@ _D8demangle4testFDFNiZaZv
 demangle.test(char() @nogc delegate)
 #
 --format=dlang
+_D8demangle4testFDFNmZaZv
+demangle.test(char() @live delegate)
+#
+--format=dlang
 _D8demangle4testFDFNaNbZaZv
 demangle.test(char() pure nothrow delegate)
 #
@@ -538,6 +542,10 @@ _D8demangle4testFPFNiZaZv
 demangle.test(char() @nogc function)
 #
 --format=dlang
+_D8demangle4testFPFNmZaZv
+demangle.test(char() @live function)
+#
+--format=dlang
 _D8demangle4testFPFNaNbZaZv
 demangle.test(char() pure nothrow function)
 #
-- 
2.20.1

New mklog script

[Martin Liška]

Hi.

Since we moved to git world and we're in the preparation for ChangeLog messages
being in git commit messages, I think it's the right time to also simplify mklog
script.

I'm sending a new version (which should eventually replace contrib/mklog and 
contrib/mklog.pl).
Changes made in the version:

- the script uses unifdiff - it rapidly simplifies parsing of the '+-!' lines 
that is done
  in contrib/mklog
- no author nor date stamp is used - that all can be get from git
- --inline option is not supported - I don't see a use-case for it now
- the new script has a unit tests (just few of them for now)

I compares results in between the old Python script for last 80 commits and 
it's very close,
in some cases it does even better.

I'm planning to maintain and improve the script for the future.

Thoughts?
Martin
>From 9fa5d13856f0f5ba153801baf57d4a732829f609 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 15 May 2020 00:44:07 +0200
Subject: [PATCH] Add mklog-ng.py and gcc-mklog git alias.

contrib/ChangeLog:

	* gcc-git-customization.sh: Add gcc-mklog alias.
	* mklog_ng.py: New file.
	* test_mklog_ng.py: New file.
---
 contrib/gcc-git-customization.sh |   2 +
 contrib/mklog_ng.py  | 192 +++
 contrib/test_mklog_ng.py | 158 +
 3 files changed, 352 insertions(+)
 create mode 100755 contrib/mklog_ng.py
 create mode 100755 contrib/test_mklog_ng.py

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index a932bf8c06a..b7b97327be3 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -25,6 +25,8 @@ git config alias.svn-rev '!f() { rev=$1; shift; git log --all --grep="^From-SVN:
 git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then c=\${2:-master}; r=\$(git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' \$c | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p'); expr match \${r:-no} '^r[0-9]\\+\$' >/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master}); else c=\${1:-master}; r=\$(git describe --all --match 'basepoints/gcc-[0-9]*' \$c | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)\$,r\\2-0,p'); fi; if test -n \$r; then o=\$(git config --get gcc-config.upstream); rr=\$(echo \$r | sed -n 's,^r\\([0-9]\\+\\)-[0-9]\\+\\(-g[0-9a-f]\\+\\)\\?\$,\\1,p'); if git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$rr >/dev/null; then m=releases/gcc-\$rr; else m=master; fi; git merge-base --is-ancestor \$c \${o:-origin}/\$m && \echo \${r}; fi; }; f"
 git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream); r=\$(echo \$1 | sed -n 's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 && exit 1; h=\$(git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$r); test -z \$h && h=\$(git rev-parse --verify --quiet \${o:-origin}/master); p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\2,p;s,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+\$,0,p'); git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
 
+git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog_ng.py" $@; } ; f'
+
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
 # *.mddiff=md
diff --git a/contrib/mklog_ng.py b/contrib/mklog_ng.py
new file mode 100755
index 000..a67fc007759
--- /dev/null
+++ b/contrib/mklog_ng.py
@@ -0,0 +1,192 @@
+#!/usr/bin/env python3
+
+# Copyright (C) 2020 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 COPYING.  If not, write to
+# the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301, USA.
+
+# This script parses a .diff file generated with 'diff -up' or 'diff -cp'
+# and adds a skeleton ChangeLog file to the file. It does not try to be
+# too smart when parsing function names, but it produces a reasonable
+# approximation.
+#
+# Author: Martin Liska 
+
+import argparse
+import os
+import re
+import sys
+
+from unidiff import PatchSet
+
+pr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PPR [a-z+-]+\/[0-9]+)')
+identifier_regex = re.compile(r'^([a-zA-Z0-9_#].*)')
+comment_re

[PATCH] tree-optimization/92260 - improve fix

[Richard Biener]

This improves the fix for PR92260 changing the number of vector
computation to the canonical one, not needing to look at the
using stmt.

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

2020-05-15  Richard Biener  

PR tree-optimization/92260
* tree-vect-slp.c (vect_get_constant_vectors): Compute
the number of vector stmts in a canonical way.
---
 gcc/tree-vect-slp.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 6f623955ce5..15eea74d8d1 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3561,19 +3561,12 @@ vect_get_constant_vectors (vec_info *vinfo,
   else
 vector_type = get_vectype_for_scalar_type (vinfo, TREE_TYPE (op), op_node);
 
-  /* ???  For lane-reducing ops we should also have the required number
- of vector stmts initialized rather than second-guessing here.  */
-  unsigned int number_of_vectors;
-  if (is_gimple_assign (stmt_vinfo->stmt)
-  && (gimple_assign_rhs_code (stmt_vinfo->stmt) == SAD_EXPR
- || gimple_assign_rhs_code (stmt_vinfo->stmt) == DOT_PROD_EXPR
- || gimple_assign_rhs_code (stmt_vinfo->stmt) == WIDEN_SUM_EXPR))
-number_of_vectors = SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node);
-  else
-number_of_vectors
-  = vect_get_num_vectors (SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node)
- * TYPE_VECTOR_SUBPARTS (stmt_vectype),
- vector_type);
+  poly_uint64 vf = 1;
+  if (loop_vec_info loop_vinfo = dyn_cast  (vinfo))
+vf = loop_vinfo->vectorization_factor;
+  unsigned int number_of_vectors
+= vect_get_num_vectors (vf * group_size, vector_type);
+
   vec_oprnds->create (number_of_vectors);
   auto_vec voprnds (number_of_vectors);
 
-- 
2.25.1

Re: [PATCH] x86: Allow vector register pushes

[Uros Bizjak via Gcc-patches]

On Wed, May 13, 2020 at 5:58 PM H.J. Lu  wrote:

> > > > The question is, why STV pass creates its funny sequence? The original
> > > > sequence should be easily solved by storing DImode from XMM register
> > > > and (with patched gcc) pushing DImode value from the same XMM
> > > > register.
> > >
> > > STV pass is mostly OK since it has to use XMM to move upper and lower
> > > 32 bits of a 64-bit integer.  The problem is that push XMM becomes very
> > > expensive later.
> >
> > As shown in the patch, XMM push should be just decrement of SP reg and
> > move to the created stack slot.
>
> OK for master if there are no regressions?

diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 78fb373db6e..6cad125fa83 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -1264,7 +1264,8 @@ has_non_address_hard_reg (rtx_insn *insn)
   FOR_EACH_INSN_DEF (ref, insn)
 if (HARD_REGISTER_P (DF_REF_REAL_REG (ref))
 && !DF_REF_FLAGS_IS_SET (ref, DF_REF_MUST_CLOBBER)
-&& DF_REF_REGNO (ref) != FLAGS_REG)
+&& DF_REF_REGNO (ref) != FLAGS_REG
+&& DF_REF_REGNO (ref) != SP_REG)
   return true;

I don't think this part is correct. The function comment says:

/* Return 1 if INSN uses or defines a hard register.
   Hard register uses in a memory address are ignored.
   Clobbers and flags definitions are ignored.  */

and you are putting SP_REG into clobber part.

OTOH, SP_REG in:

(insn 28 27 29 3 (set (mem:DI (pre_dec:SI (reg/f:SI 7 sp)) [2  S8 A64])
(reg/v:DI 85 [ target ])) "x.i":19:5 40 {*pushdi2}

is inside memory, so REG_SP should already be ignored. Please
investigate, why it is not the case.

+(define_insn "*pushv1ti2"
+  [(set (match_operand:V1TI 0 "push_operand" "=<")
+(match_operand:V1TI 1 "general_no_elim_operand" "v"))]
+  ""
+  "#"
+  [(set_attr "type" "multi")
+   (set_attr "mode" "TI")])
+
+(define_split
+  [(set (match_operand:V1TI 0 "push_operand" "")
+(match_operand:V1TI 1 "sse_reg_operand" ""))]
+  "TARGET_64BIT && reload_completed"
+  [(set (reg:P SP_REG) (plus:P (reg:P SP_REG) (match_dup 2)))
+(set (match_dup 0) (match_dup 1))]
+{
+  operands[2] = GEN_INT (-PUSH_ROUNDING (16));
+  /* Preserve memory attributes. */
+  operands[0] = replace_equiv_address (operands[0], stack_pointer_rtx);
+})

The above part is wrong on many levels, e.g. using wrong predicate,
unnecessary rounding, it should be defined as define_insn_and_split,
conditionalized on TARGET_64BIT && TARGET_STV and put nearby existing
pushti patterns.

I will implement push changes (modulo V1T1mode) by myself, since they
are independent of STV stuff.

Uros.

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Richard Biener via Gcc-patches]

On Fri, May 15, 2020 at 10:30 AM Richard Sandiford
 wrote:
>
> Richard Biener via Gcc-patches  writes:
> > Note I think what's missing is some general blurb in our coding conventions
> > as to how much of C++11 we are supposed to use in non-infrastructure parts
> > of GCC (I expect things like hash-table.h to use more C++ features than,
> > say, tree-ssa-alias.c).
>
> I guess there are two aspects to that:
>
> - Are there any specific features we should avoid using at all?
>   TBH I hope not.  Trying to police this based on C++ feature sounds
>   difficulty and might be counterproductive.
>
>   IMO it should just (continue to) be based on principles like avoiding
>   abstraction for abstraction's sake, and keeping compiler performance
>   and code size in mind.  Even tree-ssa-alias.c should be able to use
>   any C++ feature if there's a justification.
>
> - Coding conventions for when features should be used.  "auto" is an
>   obvious one.  Maybe also lambdas (which should help avoid the horrible
>   "void *" callback parameters we have all over the place now).
>
> Maybe also guidelines to actively use certain features, e.g.
>
> - use "= default" where possible
>
> - prefer range-based for loops to macros
>
> - mark "operator bool()" conversions as explicit
>
> - use "override" where applicable
>
> (all obvious I guess), etc.

I think the most important thing is that refactoring for the sake
of refactoring is bad iff it does not improve on consistency
throughout the code base.  We should really try hard to use
C++ features consistently - this makes the code base easier
to understand.

We've moved more and more to stronly-typed data structures
so I'd not like to see 'auto' everywhere - it should be still
obvious what kind of objects we're working with where they
matter.  IMHO they do not matter for example for iterators.
I don't care about the iterator type but about the type of
the object and the container.

Richard.

> Thanks,
> Richard

Re: ChangeLog files - server and client scripts

[Martin Liška]

On 5/14/20 6:47 PM, Joseph Myers wrote:

On Thu, 14 May 2020, Martin Liška wrote:


On 5/13/20 7:53 PM, Joseph Myers wrote:

On Wed, 13 May 2020, Martin Liška wrote:


I'm sending the gcc-changelog relates scripts which should be added to
contrib
folder. The patch contains:
- git_check_commit.py - checking script that verifies git message format


We need a documentation patch to contribute.html or gitwrite.html that
describes the exact commit message format being used.


Sure, I'm sending patch for that.


Thanks.  There are references to author timestamps there.  The date in a
ChangeLog entry should always be a commit timestamp, not an author one, so
author timestamps present either in commit messages or in the git commit
metadata should be ignored, with only the committer timestamps from the
git commit metadata being used when generating ChangeLog files.


You are fully right, a committer date is what should be used.
Fixed in the documentation, note that the scripts use committed date.

Martin

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index f4732ef6..d2e73962 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -112,9 +112,14 @@ maintained and kept up to date.  In particular:
 
 ChangeLogs
 
-GCC requires ChangeLog entries for documentation changes; for the web
-pages (apart from java/ and libstdc++/) the CVS
-commit logs are sufficient.
+
+ChangeLog entries are part of git commit messages and are automatically put
+into a corresponding ChangeLog file.  A ChangeLog template can be easily generated
+with ./contrib/mklog script.  GCC offers a checking script that
+verifies a proper ChangeLog formatting (see git gcc-verify git alias).
+for a particular git commit.  The checking script covers most commonly used ChangeLog
+formats and the following paragraphs explain what it supports.
+
 
 See also what the http://www.gnu.org/prep/standards_toc.html";>GNU Coding
@@ -124,19 +129,95 @@ in comments rather than the ChangeLog, though a single line overall
 description of the changes may be useful above the ChangeLog entry for
 a large batch of changes.
 
-For changes that are ported from another branch, we recommend to
-use a single entry whose body contains a verbatim copy of the original
-entries describing the changes on that branch, possibly preceded by a
-single-line overall description of the changes.
+Components
+
+
+git_description - a leading text with git commit description
+committer_timestamp - line with timestamp and an author name and email (2 spaces before and after name) 
+example: 2020-04-23␣␣Martin Liska␣␣
+additional_author - line with additional commit author name and email (starting with a tabular and 4 spaces) 
+example: \tMartin Liska␣␣
+changelog_location - a location to a ChangeLog file 
+supported formats: a/b/c/ChangeLog, a/b/c/ChangeLog:, a/b/c/ (where ChangeLog file lives in the folder), \ta/b/c/ and a/b/c
+pr_entry - bug report reference 
+example: \tPR component/12345
+changelog_file - a modified file mentined in a ChangeLog:
+supported formats: \t* a/b/c/file.c:, \t* a/b/c/file.c (function):, \t* a/b/c/file1.c, a/b/c/file2.c:
+changelog_file_comment - line that follows a changelog_file with description of changes in the file;
+must start with \t
+co_authored_by - https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors";>GitHub format for a Co-Authored-By
+
+
+Format rules
+
+
+git_description - optional; ends right before one of the other compoments is found
+committer_timestamp - optional; when found before a changelog_file, then it is added
+to each changelog entry
+additional_author - optional
+changelog_location - optional; parser attempts to identify ChangeLog file based
+on modified files; $changelog_location belonging to a different ChangeLog must
+be separated with an empty line
+pr_entry - optional; can contain any number of PR entries
+changelog_file - each changelog_location must contain at least one file
+changelog_file_comment - optional
+co_authored_by - optional, can contain more than one
+
+
+Documented behaviour
+
+
+a missing changelog_location file location can be deduced based on group of changelog_files
+script automatically generates missing "New file." entries for files that are added in a commit
+changed files that are not mentioned in a ChangeLog file generate an error
+similarly for unchanged files that are mentioned in a ChangeLog file
+a commit author and committer date stamp can be automatically deduced from a git commit - we recommend to use it
+co_authored_by is added to each ChangeLog entry
+a PR component is checked against list of valid components
+ChangeLog files, DATESTAMP, BASE-VER and DEV-PHASE can be modified only separately from other file

Re: [PATCH 2/2] arm: Add support for interrupt routines to reg_needs_saving_p

[Ramana Radhakrishnan via Gcc-patches]

On Fri, May 15, 2020 at 7:36 AM Christophe Lyon
 wrote:
>
> On Thu, 14 May 2020 at 17:58, Ramana Radhakrishnan
>  wrote:
> >
> > >  static bool reg_needs_saving_p (unsigned reg)
> > >  {
> > >unsigned long func_type = arm_current_func_type ();
> >
> > Ah ok , you needed it here.
>
> Yes sorry.
> Is this patch (2/2) OK?
>

This looks ok to me as long as there are no regressions and you rejig
the hunks between 1/2 and 2/2

regards
Ramana

> Thanks,
>
> Christophe
>
> >
> > Ramana

Re: [stage1][PATCH] Make TOPN counter dynamically allocated.

[Martin Liška]

We're in stage1: PING^1

On 4/6/20 10:03 AM, Martin Liška wrote:

Hi.

We've started discussion the patch with Honza when we started working on
reproducibility of -fprofile-generate/use. The patch replaces pre-allocated
TOP N counters with a dynamical linked list allocation that happens during
profiling. The similar approach is used by Clang and it provides these benefits:

1) addition to linked list is being done atomically, we should not end up
    with corrupted profiles
2) we waste a pointer per each key-value-pair, but we reduce memory footprint
    for counters that are not used
3) the method provide better stability results, there are collected stats for 
GCC
    PGO build:

Covered threshold: 0.25
== Stats for /home/marxin/Programming/gcc/objdir/gcc ==
stats for indirect_call:
Total: 9240, total freq: 5999706513, covered freq: 4309848999 (71.83%), missing 
freq: 14248293 (0.24%)
Total tuples: 8759 (size before: 9*N=83160, after: 2*N + (2*TUPLE_COUNT)=35998
Histogram:
  0 tracked:  6278 (67.94%), >=0.25:    0 (cov. freq:    0 (0.00%))
  1 tracked:  1784 (19.31%), >=0.25: 1784 (cov. freq:   2276692405 (37.95%))
  2 tracked:   222 (2.40%), >=0.25:  300 (cov. freq:    575634854 (9.59%))
  3 tracked:    79 (0.85%), >=0.25:  143 (cov. freq:    220498760 (3.68%))
  4 tracked:    78 (0.84%), >=0.25:  135 (cov. freq:    160196399 (2.67%))
  5 tracked:   105 (1.14%), >=0.25:  162 (cov. freq: 48169245 (0.80%))
  6 tracked:   239 (2.59%), >=0.25:  369 (cov. freq:    115649188 (1.93%))
  7 tracked:   135 (1.46%), >=0.25:  210 (cov. freq: 11660200 (0.19%))
  8 tracked:   224 (2.42%), >=0.25:  260 (cov. freq:    313294659 (5.22%))
  9 tracked:    62 (0.67%), >=0.25:   50 (cov. freq:    222127899 (3.70%))
     10 tracked: 2 (0.02%), >=0.25:    3 (cov. freq:   334914 (0.01%))
     11 tracked: 2 (0.02%), >=0.25:    1 (cov. freq:  2454696 (0.04%))
     12 tracked: 2 (0.02%), >=0.25:    3 (cov. freq:   981658 (0.02%))
     13 tracked: 4 (0.04%), >=0.25:    3 (cov. freq: 23617640 (0.39%))
     14 tracked: 4 (0.04%), >=0.25:    4 (cov. freq:  9493736 (0.16%))
     17 tracked: 2 (0.02%), >=0.25:    3 (cov. freq:  8416719 (0.14%))
     20 tracked: 1 (0.01%), >=0.25:    1 (cov. freq:  5041813 (0.08%))
     21 tracked: 3 (0.03%), >=0.25:    4 (cov. freq: 23487922 (0.39%))
     27 tracked: 1 (0.01%), >=0.25:    1 (cov. freq: 99561333 (1.66%))
     28 tracked: 1 (0.01%), >=0.25:    2 (cov. freq: 64012144 (1.07%))
     30 tracked: 1 (0.01%), >=0.25:    1 (cov. freq:    114573384 (1.91%))
     32 tracked:    11 (0.12%), >=0.25:    8 (cov. freq: 13949431 (0.23%))

stats for topn:
Total: 1519, total freq: 1660520369, covered freq: 767273373 (46.21%), missing 
freq: 84286328 (5.08%)
Total tuples: 5365 (size before: 9*N=13671, after: 2*N + (2*TUPLE_COUNT)=13768
Histogram:
  0 tracked:  1032 (67.94%), >=0.25:    0 (cov. freq:    0 (0.00%))
  1 tracked:   154 (10.14%), >=0.25:  154 (cov. freq:    240913892 (14.51%))
  2 tracked:    43 (2.83%), >=0.25:   62 (cov. freq: 28671331 (1.73%))
  3 tracked:    38 (2.50%), >=0.25:   56 (cov. freq: 72179614 (4.35%))
  4 tracked:    23 (1.51%), >=0.25:   38 (cov. freq:  9598177 (0.58%))
  5 tracked:    36 (2.37%), >=0.25:   48 (cov. freq: 89840680 (5.41%))
  6 tracked:    13 (0.86%), >=0.25:   17 (cov. freq:  4548625 (0.27%))
  7 tracked: 8 (0.53%), >=0.25:   10 (cov. freq: 23456524 (1.41%))
  8 tracked: 6 (0.39%), >=0.25:    6 (cov. freq:   357781 (0.02%))
  9 tracked: 2 (0.13%), >=0.25:    2 (cov. freq:   266881 (0.02%))
     10 tracked: 5 (0.33%), >=0.25:    5 (cov. freq:    68985 (0.00%))
     11 tracked: 6 (0.39%), >=0.25:    7 (cov. freq:  6216337 (0.37%))
     12 tracked: 1 (0.07%), >=0.25:    1 (cov. freq:  892 (0.00%))
     13 tracked:    11 (0.72%), >=0.25:   11 (cov. freq: 70639704 (4.25%))
     14 tracked: 3 (0.20%), >=0.25:    1 (cov. freq:    16524 (0.00%))
     15 tracked: 1 (0.07%), >=0.25:    0 (cov. freq:    0 (0.00%))
     16 tracked: 1 (0.07%), >=0.25:    1 (cov. freq:   106363 (0.01%))
     17 tracked: 1 (0.07%), >=0.25:    0 (cov. freq:    0 (0.00%))
     18 tracked: 2 (0.13%), >=0.25:    3 (cov. freq:    32033 (0.00%))
     20 tracked: 1 (0.07%), >=0.25:    0 (cov. freq:    0 (0.00%))
     21 tracked: 3 (0.20%), >=0.25:    2 (cov. freq:   355742 (0.02%))
     22 tracked: 1 (0.07%), >=0.25:    1 (cov. freq:  624 (0.00%))
     24 tracked: 3 (0.20%), >=0.25:    2 (cov. freq:  1684949 (0.10%))
     25 tracked: 1 (0.07%), >=0.25:    1 (cov. freq:  655 (0.00%))
     26 tracked: 2 (0.13%), >=0.25:    2 (cov. freq:    72971 (0.00%))
     27 tracked: 1 (0.07%), >=0.25:    0 (cov. freq:    0 (0.00%))

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

[Martin Liška]

We're in stage1: PING^1

On 4/3/20 8:15 PM, Egeyar Bagcioglu wrote:



On 3/18/20 10:05 AM, Martin Liška wrote:

On 3/17/20 7:43 PM, Egeyar Bagcioglu wrote:

Hi Martin,

I like the patch. It definitely serves our purposes at Oracle and provides 
another way to do what my previous patches did as well.

1) It keeps the backwards compatibility regarding -frecord-gcc-switches; 
therefore, removes my related doubts about your previous patch.

2) It still makes use of -frecord-gcc-switches. The new option is only to 
control the format. This addresses some previous objections to having a new 
option doing something similar. Now the new option controls the behaviour of 
the existing one and that behaviour can be further extended.

3) It uses an environment variable as Jakub suggested.

The patch looks good and I confirm that it works for our purposes.


Hello.

Thank you for the support.



Having said that, I have to ask for recognition in this patch for my and my 
company's contributions. Can you please keep my name and my work email in the 
changelog and in the commit message?


Sure, sorry I forgot.


Hi Martin,

I noticed that some comments in the patch were still referring to 
--record-gcc-command-line, the option I suggested earlier. I updated those 
comments to mention -frecord-gcc-switches-format instead and also added my name 
to the patch as you agreed above. I attached the updated patch. We are starting 
to use this patch in the specific domain where we need its functionality.

Regards
Egeyar




Martin



Thanks
Egeyar



On 3/17/20 2:53 PM, Martin Liška wrote:

Hi.

I'm sending enhanced patch that makes the following changes:
- a new option -frecord-gcc-switches-format is added; the option
  selects format (processed, driver) for all options that record
  GCC command line
- Dwarf gen_produce_string is now used in -fverbose-asm
- The .s file is affected in the following way:

BEFORE:

# GNU C17 (SUSE Linux) version 9.2.1 20200128 [revision 
83f65674e78d97d27537361de1a9d74067ff228d] (x86_64-suse-linux)
#    compiled by GNU C version 9.2.1 20200128 [revision 
83f65674e78d97d27537361de1a9d74067ff228d], GMP version 6.2.0, MPFR version 
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP

# GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
# options passed:  -fpreprocessed test.i -march=znver1 -mmmx -mno-3dnow
# -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha
# -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx
# -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1
# -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw
# -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd
# -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves
# -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi
# -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero -mno-pku
# -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni
# -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b
# -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32
# --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=znver1
# -grecord-gcc-switches -g -fverbose-asm -frecord-gcc-switches
# options enabled:  -faggressive-loop-optimizations -fassume-phsa
# -fasynchronous-unwind-tables -fauto-inc-dec -fcommon
# -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining
# -feliminate-unused-debug-types -ffp-int-builtin-inexact -ffunction-cse
# -fgcse-lm -fgnu-runtime -fgnu-unique -fident -finline-atomics
# -fipa-stack-alignment -fira-hoist-pressure -fira-share-save-slots
# -fira-share-spill-slots -fivopts -fkeep-static-consts
# -fleading-underscore -flifetime-dse -flto-odr-type-merging -fmath-errno
# -fmerge-debug-strings -fpeephole -fplt -fprefetch-loop-arrays
# -frecord-gcc-switches -freg-struct-return -fsched-critical-path-heuristic
# -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
# -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
# -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fschedule-fusion
# -fsemantic-interposition -fshow-column -fshrink-wrap-separate
# -fsigned-zeros -fsplit-ivs-in-unroller -fssa-backprop -fstdarg-opt
# -fstrict-volatile-bitfields -fsync-libcalls -ftrapping-math -ftree-cselim
# -ftree-forwprop -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
# -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop
# -ftree-reassoc -ftree-scev-cprop -funit-at-a-time -funwind-tables
# -fverbose-asm -fzero-initialized-in-bss -m128bit-long-double -m64 -m80387
# -mabm -madx -maes -malign-stringops -mavx -mavx2
# -mavx256-split-unaligned-store -mbmi -mbmi2 -mclflushopt -mclzero -mcx16
# -mf16c -mfancy-math-387 -mfma -mfp-ret-in-387 -mfsgsbase -mfxsr -mglibc
# -mieee-fp -mlong-double-80 -mlzcnt -mmmx -mmovbe -mmwaitx -mpclmul
# -mpopcnt -mprfchw -mpush-args -mrdrnd -mrdseed -mred-

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Richard Sandiford]

Richard Biener  writes:
> On Fri, May 15, 2020 at 10:30 AM Richard Sandiford
>  wrote:
>>
>> Richard Biener via Gcc-patches  writes:
>> > Note I think what's missing is some general blurb in our coding conventions
>> > as to how much of C++11 we are supposed to use in non-infrastructure parts
>> > of GCC (I expect things like hash-table.h to use more C++ features than,
>> > say, tree-ssa-alias.c).
>>
>> I guess there are two aspects to that:
>>
>> - Are there any specific features we should avoid using at all?
>>   TBH I hope not.  Trying to police this based on C++ feature sounds
>>   difficulty and might be counterproductive.
>>
>>   IMO it should just (continue to) be based on principles like avoiding
>>   abstraction for abstraction's sake, and keeping compiler performance
>>   and code size in mind.  Even tree-ssa-alias.c should be able to use
>>   any C++ feature if there's a justification.
>>
>> - Coding conventions for when features should be used.  "auto" is an
>>   obvious one.  Maybe also lambdas (which should help avoid the horrible
>>   "void *" callback parameters we have all over the place now).
>>
>> Maybe also guidelines to actively use certain features, e.g.
>>
>> - use "= default" where possible
>>
>> - prefer range-based for loops to macros
>>
>> - mark "operator bool()" conversions as explicit
>>
>> - use "override" where applicable
>>
>> (all obvious I guess), etc.
>
> I think the most important thing is that refactoring for the sake
> of refactoring is bad iff it does not improve on consistency
> throughout the code base.  We should really try hard to use
> C++ features consistently - this makes the code base easier
> to understand.

Agreed.  One of the reasons I'm keen to have something in the
coding standards is that things became less consistent after
the C->C++ switch.

Maybe we should reconsider some of the existing coding standards too.
E.g.:

  Define all members outside the class definition.
  That is, there are no function bodies or member initializers
  inside the class definition.

isn't widely followed.  That's a bit of a tangent though.
(FTR, I've no attachment to the current conventions and didn't
contribute anything to them.  More consistency would be good though.)

> We've moved more and more to stronly-typed data structures
> so I'd not like to see 'auto' everywhere - it should be still
> obvious what kind of objects we're working with where they
> matter.  IMHO they do not matter for example for iterators.
> I don't care about the iterator type but about the type of
> the object and the container.

Also agreed. :-)  How about this as a starting point:

---
Use auto for:

- the result of casts or other expressions that give the type
  explicitly.  E.g.:

if (auto *table = dyn_cast  (insn))

  instead of:

if (rtx_jump_table_data *table = dyn_cast  (insn))

- iterator types.  E.g.:

auto it = foo.begin ();

  instead of:

foo_type::iterator it = foo.begin ();

- expressions that provide an alternative view of something,
  when the expression is bound to a read-only temporary.  E.g.:

auto val1 = wi::to_wide (...);
auto val2 = wi::uhwi (12, 16);

  instead of:

wide_int val1 = wi::to_wide (...);
wide_int val2 = wi::uhwi (12, 16);

  (Using "wide_int" is less efficient than using the natural type of
  the expression.)

- the type of a lambda expression.  E.g.:

auto f = [] (int x) { return x + 1; };

Do not use auto otherwise.
---

One thing I wondered about is whether we should encourage auto
for normal integer results.  It would avoid problems with values
being silently truncated to a narrower type (e.g. HOST_WIDE_INT->int).
On the other hand, that kind of truncation will still happen in things
like function calls and member variable assignments.  Using "auto" could
also hide important signedness choices.  So not using "auto" is probably
better there...

Richard

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Richard Biener via Gcc-patches]

On Fri, May 15, 2020 at 11:58 AM Richard Sandiford
 wrote:
>
> Richard Biener  writes:
> > On Fri, May 15, 2020 at 10:30 AM Richard Sandiford
> >  wrote:
> >>
> >> Richard Biener via Gcc-patches  writes:
> >> > Note I think what's missing is some general blurb in our coding 
> >> > conventions
> >> > as to how much of C++11 we are supposed to use in non-infrastructure 
> >> > parts
> >> > of GCC (I expect things like hash-table.h to use more C++ features than,
> >> > say, tree-ssa-alias.c).
> >>
> >> I guess there are two aspects to that:
> >>
> >> - Are there any specific features we should avoid using at all?
> >>   TBH I hope not.  Trying to police this based on C++ feature sounds
> >>   difficulty and might be counterproductive.
> >>
> >>   IMO it should just (continue to) be based on principles like avoiding
> >>   abstraction for abstraction's sake, and keeping compiler performance
> >>   and code size in mind.  Even tree-ssa-alias.c should be able to use
> >>   any C++ feature if there's a justification.
> >>
> >> - Coding conventions for when features should be used.  "auto" is an
> >>   obvious one.  Maybe also lambdas (which should help avoid the horrible
> >>   "void *" callback parameters we have all over the place now).
> >>
> >> Maybe also guidelines to actively use certain features, e.g.
> >>
> >> - use "= default" where possible
> >>
> >> - prefer range-based for loops to macros
> >>
> >> - mark "operator bool()" conversions as explicit
> >>
> >> - use "override" where applicable
> >>
> >> (all obvious I guess), etc.
> >
> > I think the most important thing is that refactoring for the sake
> > of refactoring is bad iff it does not improve on consistency
> > throughout the code base.  We should really try hard to use
> > C++ features consistently - this makes the code base easier
> > to understand.
>
> Agreed.  One of the reasons I'm keen to have something in the
> coding standards is that things became less consistent after
> the C->C++ switch.

Yeah.  I'm really hoping that we can unify all of the various iteration
styles used.  In general, even if I don't like it too much personally,
I'm leaning towards STL style of thing because of the idea
"C++ attracts more developers".  Now C++ range-for makes me
like it much more so that's one good reason for adopting C++11,
turn all of them over to range-for style (only!).

> Maybe we should reconsider some of the existing coding standards too.
> E.g.:
>
>   Define all members outside the class definition.
>   That is, there are no function bodies or member initializers
>   inside the class definition.
>
> isn't widely followed.  That's a bit of a tangent though.
> (FTR, I've no attachment to the current conventions and didn't
> contribute anything to them.  More consistency would be good though.)
>
> > We've moved more and more to stronly-typed data structures
> > so I'd not like to see 'auto' everywhere - it should be still
> > obvious what kind of objects we're working with where they
> > matter.  IMHO they do not matter for example for iterators.
> > I don't care about the iterator type but about the type of
> > the object and the container.
>
> Also agreed. :-)  How about this as a starting point:
>
> ---
> Use auto for:
>
> - the result of casts or other expressions that give the type
>   explicitly.  E.g.:
>
> if (auto *table = dyn_cast  (insn))
>
>   instead of:
>
> if (rtx_jump_table_data *table = dyn_cast  (insn))
>
> - iterator types.  E.g.:
>
> auto it = foo.begin ();
>
>   instead of:
>
> foo_type::iterator it = foo.begin ();
>
> - expressions that provide an alternative view of something,
>   when the expression is bound to a read-only temporary.  E.g.:
>
> auto val1 = wi::to_wide (...);
> auto val2 = wi::uhwi (12, 16);
>
>   instead of:
>
> wide_int val1 = wi::to_wide (...);
> wide_int val2 = wi::uhwi (12, 16);
>
>   (Using "wide_int" is less efficient than using the natural type of
>   the expression.)
>
> - the type of a lambda expression.  E.g.:
>
> auto f = [] (int x) { return x + 1; };

Those are all good examples.  Mind putting that into a patch
for the coding conventions?

> Do not use auto otherwise.
> ---
>
> One thing I wondered about is whether we should encourage auto
> for normal integer results.  It would avoid problems with values
> being silently truncated to a narrower type (e.g. HOST_WIDE_INT->int).
> On the other hand, that kind of truncation will still happen in things
> like function calls and member variable assignments.  Using "auto" could
> also hide important signedness choices.  So not using "auto" is probably
> better there...

Agreed.

Richard.

> Richard

[OBVIOUS][PATCH] Fix clang [-Wmisleading-indentation] in hsa-gen.c.

[Martin Liška]

Hi.

One fix of indentation that leads to -Wmisleading-indentation in Clang.

I'm going to install the patch.
Martin

gcc/ChangeLog:

2020-05-15  Martin Liska  

* hsa-gen.c (get_symbol_for_decl): Fix misleading indentation
warning.
---
 gcc/hsa-gen.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)


diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
index d407bcf503a..43baa2e82c8 100644
--- a/gcc/hsa-gen.c
+++ b/gcc/hsa-gen.c
@@ -882,13 +882,13 @@ get_symbol_for_decl (tree decl)
 
 	 Iterate elements whether a symbol is already in m_global_symbols
 	 of not.  */
-if (is_in_global_vars && !sym->m_emitted_to_brig)
-	  {
-	for (unsigned i = 0; i < hsa_cfun->m_global_symbols.length (); i++)
-	  if (hsa_cfun->m_global_symbols[i] == sym)
-		return *slot;
-	hsa_cfun->m_global_symbols.safe_push (sym);
-	  }
+  if (is_in_global_vars && !sym->m_emitted_to_brig)
+	{
+	  for (unsigned i = 0; i < hsa_cfun->m_global_symbols.length (); i++)
+	if (hsa_cfun->m_global_symbols[i] == sym)
+	  return *slot;
+	  hsa_cfun->m_global_symbols.safe_push (sym);
+	}
 
   return *slot;
 }

testsuite: clarify scan-dump file globbing behavior

[Frederik Harwath]

Hi,

The test commands for scanning optimization dump files
perform globbing on the argument that specifies the suffix
of the dump files to be scanned. This behavior is currently
undocumented. Furthermore, the current implementation of
"scan-dump" and related procedures yields an error whenever
the file name globbing matches more than one file (due to an
attempt to call "open" on multiple files) while a failure to
match any file at all results in an unresolved test.

This patch documents the globbing behavior. The dump
scanning procedures are changed to make the test unresolved
if globbing matches more than one file.

The procedures in scandump.exp all perform the file name expansion in
essentially the same way and I have extracted this into a new
procedure. But there is one very minor exception:

> @@ -67,10 +95,10 @@ proc scan-dump { args } {
>  set dumpbase [dump-base $src [lindex $args 3]]
> -set output_file "[glob -nocomplain $dumpbase.[lindex $args 2]]"
> +
> +set pattern "$dumpbase.[lindex $args 2]"
> +set output_file "[glob-dump-file $testcase $pattern]"
>  if { $output_file == "" } {
> - verbose -log "$testcase: dump file does not exist"
> - verbose -log "dump file: $dumpbase.$suf"

"scan-dump" is the only procedure that prints the "dump file: ..." line.
Should this be kept or is it ok to remove this as I have done in the
patch? $dumpbase.$suf does not emit the correct file name anyway
(a random example from my testing: "dump file: stdatomic-init.c.dce*")
and the name of the files can be inferred from the test name easily.

I have tested the changes by running "make check" (with a
--enable-languages=C only build, but this covers lots of uses
of the affected test procedures) and observed no regressions.

Ok to commit this to master?

Best regards,
Frederik

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 6912e03d51d360dbbcf7eb1dc8d77d08c2a6e54c Mon Sep 17 00:00:00 2001
From: Frederik Harwath 
Date: Fri, 15 May 2020 10:35:48 +0200
Subject: [PATCH] testsuite: clarify scan-dump file globbing behavior

The test commands for scanning optimization dump files
perform globbing on the argument that specifies the suffix
of the dump files to be scanned.  This behavior is currently
undocumented.  Furthermore, the current implementation of
"scan-dump" and similar procedures yields an error whenever
the file name globbing matches more than one file (due to an
attempt to call "open" on multiple files) while a failure to
match any file results in an unresolved test.

This commit documents the globbing behavior.  The dump
scanning procedures are changed to make the test unresolved
if globbing matches more than one file.

gcc/ChangeLog:

2020-05-15  Frederik Harwath  

	* doc/sourcebuild.texi: Describe globbing of the
	dump file scanning commands "suffix" argument.

gcc/testsuite/ChangeLog:

2020-05-15  Frederik Harwath  

	* lib/scandump.exp (glob-dump-file): New proc.
	(scan-dump): Use glob-dump-file for file name expansion.
	(scan-dump-times): Likewise.
	(scan-dump-dem): Likewise.
	(scan-dump-dem-not): Likewise.
---
 gcc/doc/sourcebuild.texi   |  4 ++-
 gcc/testsuite/lib/scandump.exp | 54 +++---
 2 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 240d6e4b08e..b6c5a21cb71 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2888,7 +2888,9 @@ stands for zero or more unmatched lines; the whitespace after
 
 These commands are available for @var{kind} of @code{tree}, @code{ltrans-tree},
 @code{offload-tree}, @code{rtl}, @code{offload-rtl}, @code{ipa}, and
-@code{wpa-ipa}.
+@code{wpa-ipa}.  The @var{suffix} argument which describes the dump file
+to be scanned may contain a glob pattern that must expand to exactly one
+file name.
 
 @table @code
 @item scan-@var{kind}-dump @var{regex} @var{suffix} [@{ target/xfail @var{selector} @}]
diff --git a/gcc/testsuite/lib/scandump.exp b/gcc/testsuite/lib/scandump.exp
index d6ba350acc8..f3a991b590a 100644
--- a/gcc/testsuite/lib/scandump.exp
+++ b/gcc/testsuite/lib/scandump.exp
@@ -39,6 +39,34 @@ proc dump-base { args } {
 return $dumpbase
 }
 
+# Expand dump file name pattern to exactly one file.
+# Return a single dump file name or an empty string
+# if the pattern matches no file or more than one file.
+#
+# Argument 0 is the testcase name
+# Argument 1 is the dump file glob pattern
+proc glob-dump-file { args } {
+
+set pattern [lindex $args 1]
+set dump_file "[glob -nocomplain $pattern]"
+set num_files [llength $dump_file]
+
+if { $num_files != 1 } {
+	set testcase [lindex $args 0]
+	if { $num_files == 0 } {
+	verbose -log "$testcase: dump file does not exist"
+	}
+
+	if { $num_files > 1 } {
+	verbose -log "$testcase: multiple dump files found"
+	}
+
+	retur

[PATCH] [arm] Don't generate invalid LDRD insns

[Alex Coplan]

Hello,

This patch fixes a bug in the arm backend where GCC generates invalid LDRD
instructions. The LDRD instruction requires the first transfer register to be
even, but GCC attempts to use odd registers here. For example, with the
following C code:

struct c {
  double a;
} __attribute((aligned)) __attribute((packed));
struct c d;
struct c f(struct c);
void e() { f(d); }

The struct d is passed in registers r1 and r2 to the function f, and GCC
attempts to do this with a LDRD instruction when compiling with -march=armv7-a
on a soft float toolchain.

The fix is analogous to the corresponding one for STRD in the same function:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=52057dc4ac5295caebf83147f688d769c93cbc8d

Testing:
 - New unit tests which pass after applying the patch.
 - Tested on an x64 -> arm-none-eabi cross.
 - Bootstrapped and regtested on arm-none-linux-gnueabihf (in both thumb and arm
   modes).

OK for master?

Thanks,
Alex

---

gcc/ChangeLog:

2020-05-15  Alex Coplan  
* config/arm/arm.c (output_move_double): Fix codegen when loading into
a register pair with an odd base register.

gcc/testsuite/ChangeLog:

2020-05-15  Alex Coplan  
* gcc.c-torture/compile/packed-aligned-1.c: New test.
* gcc.c-torture/execute/packed-aligned.c: New test.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index d50781953c0..0ac1961696e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -19551,6 +19551,7 @@ output_move_double (rtx *operands, bool emit, int 
*count)
   if (code0 == REG)
 {
   unsigned int reg0 = REGNO (operands[0]);
+  const bool can_ldrd = TARGET_LDRD && (TARGET_THUMB2 || (reg0 % 2 == 0));
 
   otherops[0] = gen_rtx_REG (SImode, 1 + reg0);
 
@@ -19562,7 +19563,7 @@ output_move_double (rtx *operands, bool emit, int 
*count)
 
  if (emit)
{
- if (TARGET_LDRD
+ if (can_ldrd
  && !(fix_cm3_ldrd && reg0 == REGNO(XEXP (operands[1], 0
output_asm_insn ("ldrd%?\t%0, [%m1]", operands);
  else
@@ -19571,7 +19572,7 @@ output_move_double (rtx *operands, bool emit, int 
*count)
  break;
 
case PRE_INC:
- gcc_assert (TARGET_LDRD);
+ gcc_assert (can_ldrd);
  if (emit)
output_asm_insn ("ldrd%?\t%0, [%m1, #8]!", operands);
  break;
@@ -19579,7 +19580,7 @@ output_move_double (rtx *operands, bool emit, int 
*count)
case PRE_DEC:
  if (emit)
{
- if (TARGET_LDRD)
+ if (can_ldrd)
output_asm_insn ("ldrd%?\t%0, [%m1, #-8]!", operands);
  else
output_asm_insn ("ldmdb%?\t%m1!, %M0", operands);
@@ -19589,7 +19590,7 @@ output_move_double (rtx *operands, bool emit, int 
*count)
case POST_INC:
  if (emit)
{
- if (TARGET_LDRD)
+ if (can_ldrd)
output_asm_insn ("ldrd%?\t%0, [%m1], #8", operands);
  else
output_asm_insn ("ldmia%?\t%m1!, %M0", operands);
@@ -19597,7 +19598,7 @@ output_move_double (rtx *operands, bool emit, int 
*count)
  break;
 
case POST_DEC:
- gcc_assert (TARGET_LDRD);
+ gcc_assert (can_ldrd);
  if (emit)
output_asm_insn ("ldrd%?\t%0, [%m1], #-8", operands);
  break;
@@ -19619,6 +19620,7 @@ output_move_double (rtx *operands, bool emit, int 
*count)
  /* Registers overlap so split out the increment.  */
  if (emit)
{
+ gcc_assert (can_ldrd);
  output_asm_insn ("add%?\t%1, %1, %2", otherops);
  output_asm_insn ("ldrd%?\t%0, [%1] @split", otherops);
}
@@ -19630,10 +19632,11 @@ output_move_double (rtx *operands, bool emit, int 
*count)
  /* Use a single insn if we can.
 FIXME: IWMMXT allows offsets larger than ldrd can
 handle, fix these up with a pair of ldr.  */
- if (TARGET_THUMB2
+ if (can_ldrd
+ && (TARGET_THUMB2
  || !CONST_INT_P (otherops[2])
  || (INTVAL (otherops[2]) > -256
- && INTVAL (otherops[2]) < 256))
+ && INTVAL (otherops[2]) < 256)))
{
  if (emit)
output_asm_insn ("ldrd%?\t%0, [%1, %2]!", otherops);
@@ -19656,10 +19659,11 @@ output_move_double (rtx *operands, bool emit, int 
*count)
  /* Use a single insn if we can.
 FIXME: IWMMXT allows offsets larger than ldrd can handle,
 fix these up with a pair of ldr.  */
- if (TARGET_THUMB2
+ if (can_ldrd
+ && (TARGET_THUMB2
  || !CONST_INT_P (otherops[2])
  || (INTVAL (ot

[committed] amdgcn: use unsigned extend for lshiftrt

[Andrew Stubbs]

This patch fixes a bug in which 8 and 16-bit vector shifts used the 
wrong kind of extend, thus causing wrong results.  It was simply a 
thinko in the insn code, so easily fixed.


Andrew


P.S. Apologies for the "work-in-progress" tag on the commit subject. 
Obviously that was meant to be removed, but I didn't notice it until 
after the push. :-(
WIP amdgcn: use unsigned extend for lshiftrt

This fixes a wrong-code logic error in a previous patch.
Detected by gcc.c-torture/execute/pr53645-2.c.

2020-05-15  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-valu.md (v3): Fix unsignedp.

diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index a43d6b6c6f3..d31fe5063b9 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -2113,7 +2113,7 @@
   ""
   {
 enum {ashift, lshiftrt, ashiftrt};
-bool unsignedp = ( == ashift ||  == ashiftrt);
+bool unsignedp = ( == lshiftrt);
 rtx insi1 = gen_reg_rtx (mode);
 rtx insi2 = gen_reg_rtx (mode);
 rtx outsi = gen_reg_rtx (mode);

[ARM][wwwdocs]: Document Armv8.1-M, Helium Intrinsics and Cortex-M55 changes.

[Srinath Parvathaneni]

M-profile related changes in GCC-10.


### Attachment also inlined for ease of reply###


diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 
d1a7df0a9259292d097c1c3b9daeab56329ea435..57ca749da72ed64da37b3eb5404cf5cde8be44dd
 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -717,6 +717,7 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
  Arm Cortex-A77 (cortex-a77).
  Arm Cortex-A76AE (cortex-a76ae).
  Arm Cortex-M35P (cortex-m35p).
+ Arm Cortex-M55 (cortex-m55).

The GCC identifiers can be used
as arguments to the -mcpu or -mtune options,
@@ -733,6 +734,16 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
   added: this M-profile feature is no longer restricted to targets
   with MOVT. For example, -mcpu=cortex-m0
   now supports this option.
+  Support for the
+  https://developer.arm.com/architectures/cpu-architecture/m-profile";>
+  Armv8.1-M Mainline Architecture has been added.
+  
+ Armv8.1-M Mainline can be enabled by using the 
-march=armv8.1-m.main command line option.
+  
+  Support for the
+  https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/helium-intrinsics";>
+  MVE beta ACLE intrinsics has been added. These intrinsics can be enabled 
by including the arm_mve.h header file
+  and passing the +mve or +mve.fp option extensions 
(for example: -march=armv8.1-m.main+mve).
   Support for the Custom Datapath Extension beta ACLE
   https://developer.arm.com/docs/101028/0010/custom-datapath-extension";>
   intrinsics has been added.

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 
d1a7df0a9259292d097c1c3b9daeab56329ea435..57ca749da72ed64da37b3eb5404cf5cde8be44dd
 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -717,6 +717,7 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
  Arm Cortex-A77 (cortex-a77).
  Arm Cortex-A76AE (cortex-a76ae).
  Arm Cortex-M35P (cortex-m35p).
+ Arm Cortex-M55 (cortex-m55).

The GCC identifiers can be used
as arguments to the -mcpu or -mtune options,
@@ -733,6 +734,16 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
   added: this M-profile feature is no longer restricted to targets
   with MOVT. For example, -mcpu=cortex-m0
   now supports this option.
+  Support for the
+  https://developer.arm.com/architectures/cpu-architecture/m-profile";>
+  Armv8.1-M Mainline Architecture has been added.
+  
+ Armv8.1-M Mainline can be enabled by using the 
-march=armv8.1-m.main command line option.
+  
+  Support for the
+  https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/helium-intrinsics";>
+  MVE beta ACLE intrinsics has been added. These intrinsics can be enabled 
by including the arm_mve.h header file
+  and passing the +mve or +mve.fp option extensions 
(for example: -march=armv8.1-m.main+mve).
   Support for the Custom Datapath Extension beta ACLE
   https://developer.arm.com/docs/101028/0010/custom-datapath-extension";>
   intrinsics has been added.

RE: [ARM][wwwdocs]: Document Armv8.1-M, Helium Intrinsics and Cortex-M55 changes.

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 15 May 2020 11:36
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> 
> Subject: [ARM][wwwdocs]: Document Armv8.1-M, Helium Intrinsics and
> Cortex-M55 changes.
> 
> M-profile related changes in GCC-10.

Ok.
Thanks,
Kyrill

> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index
> d1a7df0a9259292d097c1c3b9daeab56329ea435..57ca749da72ed64da37b3e
> b5404cf5cde8be44dd 100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -717,6 +717,7 @@ typedef svbool_t pred512
> __attribute__((arm_sve_vector_bits(512)));
>   Arm Cortex-A77 (cortex-a77).
>   Arm Cortex-A76AE (cortex-a76ae).
>   Arm Cortex-M35P (cortex-m35p).
> + Arm Cortex-M55 (cortex-m55).
> 
> The GCC identifiers can be used
> as arguments to the -mcpu or -mtune
> options,
> @@ -733,6 +734,16 @@ typedef svbool_t pred512
> __attribute__((arm_sve_vector_bits(512)));
>added: this M-profile feature is no longer restricted to targets
>with MOVT. For example, -mcpu=cortex-m0
>now supports this option.
> +  Support for the
> +  https://developer.arm.com/architectures/cpu-architecture/m-
> profile">
> +  Armv8.1-M Mainline Architecture has been added.
> +  
> + Armv8.1-M Mainline can be enabled by using the -
> march=armv8.1-m.main command line option.
> +  
> +  Support for the
> +  https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/helium-intrinsics">
> +  MVE beta ACLE intrinsics has been added. These intrinsics can be
> enabled by including the arm_mve.h header file
> +  and passing the +mve or +mve.fp option
> extensions (for example: -march=armv8.1-m.main+mve).
>Support for the Custom Datapath Extension beta ACLE
>https://developer.arm.com/docs/101028/0010/custom-datapath-
> extension">
>intrinsics has been added.

[Patch][Fortran] OpenMP 5 – permit more sharing clauses for SIMD (PR94690)

[Tobias Burnus]

Another issue found when looking into PR94690 and its
regression/additional issues.

This patch lifts a restriction of 2.15.1.1. Data-sharing Attribute
Rules for Variables Referenced in a Construct.

OpenMP 4.5 had:
* The loop iteration variable(s) in the associated do-loop(s) of a
  do, parallel do, taskloop, or distribute construct may be listed in
  a *private* or *lastprivate* clause.
* The loop iteration variable in the associated do-loop of a simd
  construct with just one associated do-loop may be listed in a
  *linear* clause with a linear-step that is the increment of the
  associated loop.
* The loop iteration variables in the associated do-loops of a simd
  construct with multiple associated do-loops may be listed in a
  *lastprivate* clause.


OpenMP 5.0 changed this in 2.19.1.1 to
* (unchanged)
* ... a simd construct with just one associated for-loop may be
  listed in a private, lastprivate, or linear ...
* simd construct with multiple associated for-loops may be listed
  in a private or lastprivate clause

Namely: private + lastprivate is now allowed in all cases.

OK for the trunk?

Tobias

PS: The remaining issue of the PR (PR94690) is about predetermined
'private' for loop variables to which complicated rules apply. Those
have been implemented on the ME side which does not recognize Fortran
loops ("while(1)" constructs*); OpenMP-ed loops use "for(..." and those
are handled by the ME.

For that reason, the FE adds a bunch of 'private' but not always to
the right OpenMP construct and not always recognizing that the user
already had specified one. (Causing ICEs or reject value issues.)
teams/distribute + workshare cause the extra complexity.

[* The while(1) loops are used be the FE to match the Fortran semantic
regarding overflowing handling for  "i + step" exceeding INT_MAX
(stop iteration instead of overflowing and continuing).]

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
[Fortran] OpenMP 5 – permit more sharing clauses for SIMD (PR94690)

gcc/fortran/
	PR fortran/94690
	* openmp.c (resolve_omp_do):

gcc/testsuite/
	PR fortran/94690
	* gfortran.dg/gomp/openmp-simd-4.f90: New test.

 gcc/fortran/openmp.c | 17 +++
 gcc/testsuite/gfortran.dg/gomp/openmp-simd-4.f90 | 65 
 2 files changed, 71 insertions(+), 11 deletions(-)

diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 310d4e030d2..b24630827c9 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -5847,26 +5847,21 @@ resolve_omp_do (gfc_code *code)
 		   "at %L", name, &do_code->loc);
   if (code->ext.omp_clauses)
 	for (list = 0; list < OMP_LIST_NUM; list++)
-	  if (!is_simd
+	  if (!is_simd || code->ext.omp_clauses->collapse > 1
 	  ? (list != OMP_LIST_PRIVATE && list != OMP_LIST_LASTPRIVATE)
-	  : code->ext.omp_clauses->collapse > 1
-	  ? (list != OMP_LIST_LASTPRIVATE)
-	  : (list != OMP_LIST_LINEAR))
+	  : (list != OMP_LIST_PRIVATE && list != OMP_LIST_LASTPRIVATE
+		 && list != OMP_LIST_LINEAR))
 	for (n = code->ext.omp_clauses->lists[list]; n; n = n->next)
 	  if (dovar == n->sym)
 		{
-		  if (!is_simd)
+		  if (!is_simd || code->ext.omp_clauses->collapse > 1)
 		gfc_error ("%s iteration variable present on clause "
 			   "other than PRIVATE or LASTPRIVATE at %L",
 			   name, &do_code->loc);
-		  else if (code->ext.omp_clauses->collapse > 1)
-		gfc_error ("%s iteration variable present on clause "
-			   "other than LASTPRIVATE at %L",
-			   name, &do_code->loc);
 		  else
 		gfc_error ("%s iteration variable present on clause "
-			   "other than LINEAR at %L",
-			   name, &do_code->loc);
+			   "other than PRIVATE, LASTPRIVATE or "
+			   "LINEAR at %L", name, &do_code->loc);
 		  break;
 		}
   if (i > 1)
diff --git a/gcc/testsuite/gfortran.dg/gomp/openmp-simd-4.f90 b/gcc/testsuite/gfortran.dg/gomp/openmp-simd-4.f90
new file mode 100644
index 000..4a17fb9820e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/openmp-simd-4.f90
@@ -0,0 +1,65 @@
+! { dg-do compile }
+
+integer :: i, j, k
+integer :: x(5), y(2,5)
+
+!$omp parallel do private(i)
+do i = 1, 5
+  x(i) = 42
+end do
+
+!$omp parallel do lastprivate(i)
+do i = 1, 5
+  x(i) = 42
+end do
+
+
+!$omp simd private(i)
+do i = 1, 5
+  x(i) = 42
+end do
+
+!$omp simd linear(i)
+do i = 1, 5
+  x(i) = 42
+end do
+
+!$omp simd lastprivate(i)
+do i = 1, 5
+  x(i) = 42
+end do
+
+
+!$omp simd private(i) lastprivate(j) collapse(2)
+do i = 1, 5
+  do j = 1, 2
+y(j, i) = 52
+  end do
+end do
+
+!$omp simd lastprivate(i) private(j) collapse(2)
+do i = 1, 5
+  do j = 1, 2
+y(j, i) = 52
+  end do
+end do
+
+!$omp parallel do firstprivate(i)
+do i = 1, 5  ! { dg-error "PARALLEL DO iteration variable present on clause other than PRIVATE or LASTPRIVATE" }
+  x(i) = 42
+end do
+
+!

RE: [PATCH] [arm] Don't generate invalid LDRD insns

[Kyrylo Tkachov]

Hi Alex,

> -Original Message-
> From: Alex Coplan 
> Sent: 15 May 2020 11:36
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; ni...@redhat.com; Richard Earnshaw
> ; Ramana Radhakrishnan
> ; Kyrylo Tkachov
> 
> Subject: [PATCH] [arm] Don't generate invalid LDRD insns
> 
> Hello,
> 
> This patch fixes a bug in the arm backend where GCC generates invalid LDRD
> instructions. The LDRD instruction requires the first transfer register to be
> even, but GCC attempts to use odd registers here. For example, with the
> following C code:
> 
> struct c {
>   double a;
> } __attribute((aligned)) __attribute((packed));
> struct c d;
> struct c f(struct c);
> void e() { f(d); }
> 
> The struct d is passed in registers r1 and r2 to the function f, and GCC
> attempts to do this with a LDRD instruction when compiling with -
> march=armv7-a
> on a soft float toolchain.
> 
> The fix is analogous to the corresponding one for STRD in the same function:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=52057dc4ac5295caebf83147f6
> 88d769c93cbc8d
> 
> Testing:
>  - New unit tests which pass after applying the patch.
>  - Tested on an x64 -> arm-none-eabi cross.
>  - Bootstrapped and regtested on arm-none-linux-gnueabihf (in both thumb
> and arm
>modes).
> 
> OK for master?

Ok.
Please apply for write-after-approval commit access to the repo by filling the 
form at:
https://sourceware.org/cgi-bin/pdw/ps_form.cgi
listing me as your sponsor.
You can then push the patch yourself.

Thanks,
Kyrill

> 
> Thanks,
> Alex
> 
> ---
> 
> gcc/ChangeLog:
> 
> 2020-05-15  Alex Coplan  
> * config/arm/arm.c (output_move_double): Fix codegen when loading
> into
> a register pair with an odd base register.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-05-15  Alex Coplan  
> * gcc.c-torture/compile/packed-aligned-1.c: New test.
> * gcc.c-torture/execute/packed-aligned.c: New test.

Re: New mklog script

[David Malcolm via Gcc-patches]

On Fri, 2020-05-15 at 10:59 +0200, Martin Liška wrote:
> Hi.
> 
> Since we moved to git world and we're in the preparation for
> ChangeLog messages
> being in git commit messages, I think it's the right time to also
> simplify mklog
> script.
> 
> I'm sending a new version (which should eventually replace
> contrib/mklog and contrib/mklog.pl).
> Changes made in the version:
> 
> - the script uses unifdiff - it rapidly simplifies parsing of the '+-
> !' lines that is done
>in contrib/mklog
> - no author nor date stamp is used - that all can be get from git
> - --inline option is not supported - I don't see a use-case for it
> now
> - the new script has a unit tests (just few of them for now)
> 
> I compares results in between the old Python script for last 80
> commits and it's very close,
> in some cases it does even better.
> 
> I'm planning to maintain and improve the script for the future.
> 
> Thoughts?
> Martin

> +class TestMklog(unittest.TestCase):
> +def test_macro_definition(self):
> +changelog = generate_changelog(PATCH1)
> +assert changelog == EXPECTED1
> +
> +def test_changed_argument(self):
> +changelog = generate_changelog(PATCH2)
> +assert changelog == EXPECTED2
> +
> +def test_enum_and_struct(self):
> +changelog = generate_changelog(PATCH3)
> +assert changelog == EXPECTED3
> +
> +def test_no_function(self):
> +changelog = generate_changelog(PATCH3, True)
> +assert changelog == EXPECTED3B

Use self.assertEqual(a, b) rather than assert a == b, so that if it
fails you get a multiline diff:

e.g.:

import unittest

class TestMklog(unittest.TestCase):
def test_macro_definition(self):
self.assertEqual('''
first
second
third''', '''
first
SECOND
third''')

unittest.main()


has this output:

F
==
FAIL: test_macro_definition (__main__.TestMklog)
--
Traceback (most recent call last):
  File "/tmp/foo.py", line 11, in test_macro_definition
third''')
AssertionError: '\nfirst\nsecond\nthird' != '\nfirst\nSECOND\nthird'
  
  first
- second
+ SECOND
  third

--
Ran 1 test in 0.000s

FAILED (failures=1)

which is much easier to debug than the output from assert a == b, which
is just:

F
==
FAIL: test_macro_definition (__main__.TestMklog)
--
Traceback (most recent call last):
  File "/tmp/foo.py", line 11, in test_macro_definition
third''')
AssertionError

--
Ran 1 test in 0.000s

FAILED (failures=1)

Re: [stage1][PATCH] Make TOPN counter dynamically allocated.

[Jan Hubicka]

> We're in stage1: PING^1

I wonder, did we somehow solved the issue with Firefox breaking due to
malloc instrumentation?

Honza
> 
> On 4/6/20 10:03 AM, Martin Liška wrote:
> > Hi.
> > 
> > We've started discussion the patch with Honza when we started working on
> > reproducibility of -fprofile-generate/use. The patch replaces pre-allocated
> > TOP N counters with a dynamical linked list allocation that happens during
> > profiling. The similar approach is used by Clang and it provides these 
> > benefits:
> > 
> > 1) addition to linked list is being done atomically, we should not end up
> >     with corrupted profiles
> > 2) we waste a pointer per each key-value-pair, but we reduce memory 
> > footprint
> >     for counters that are not used
> > 3) the method provide better stability results, there are collected stats 
> > for GCC
> >     PGO build:
> > 
> > Covered threshold: 0.25
> > == Stats for /home/marxin/Programming/gcc/objdir/gcc ==
> > stats for indirect_call:
> > Total: 9240, total freq: 5999706513, covered freq: 4309848999 (71.83%), 
> > missing freq: 14248293 (0.24%)
> > Total tuples: 8759 (size before: 9*N=83160, after: 2*N + 
> > (2*TUPLE_COUNT)=35998
> > Histogram:
> >   0 tracked:  6278 (67.94%), >=0.25:    0 (cov. freq:    0 
> > (0.00%))
> >   1 tracked:  1784 (19.31%), >=0.25: 1784 (cov. freq:   2276692405 
> > (37.95%))
> >   2 tracked:   222 (2.40%), >=0.25:  300 (cov. freq:    575634854 
> > (9.59%))
> >   3 tracked:    79 (0.85%), >=0.25:  143 (cov. freq:    220498760 
> > (3.68%))
> >   4 tracked:    78 (0.84%), >=0.25:  135 (cov. freq:    160196399 
> > (2.67%))
> >   5 tracked:   105 (1.14%), >=0.25:  162 (cov. freq: 48169245 
> > (0.80%))
> >   6 tracked:   239 (2.59%), >=0.25:  369 (cov. freq:    115649188 
> > (1.93%))
> >   7 tracked:   135 (1.46%), >=0.25:  210 (cov. freq: 11660200 
> > (0.19%))
> >   8 tracked:   224 (2.42%), >=0.25:  260 (cov. freq:    313294659 
> > (5.22%))
> >   9 tracked:    62 (0.67%), >=0.25:   50 (cov. freq:    222127899 
> > (3.70%))
> >      10 tracked: 2 (0.02%), >=0.25:    3 (cov. freq:   334914 
> > (0.01%))
> >      11 tracked: 2 (0.02%), >=0.25:    1 (cov. freq:  2454696 
> > (0.04%))
> >      12 tracked: 2 (0.02%), >=0.25:    3 (cov. freq:   981658 
> > (0.02%))
> >      13 tracked: 4 (0.04%), >=0.25:    3 (cov. freq: 23617640 
> > (0.39%))
> >      14 tracked: 4 (0.04%), >=0.25:    4 (cov. freq:  9493736 
> > (0.16%))
> >      17 tracked: 2 (0.02%), >=0.25:    3 (cov. freq:  8416719 
> > (0.14%))
> >      20 tracked: 1 (0.01%), >=0.25:    1 (cov. freq:  5041813 
> > (0.08%))
> >      21 tracked: 3 (0.03%), >=0.25:    4 (cov. freq: 23487922 
> > (0.39%))
> >      27 tracked: 1 (0.01%), >=0.25:    1 (cov. freq: 99561333 
> > (1.66%))
> >      28 tracked: 1 (0.01%), >=0.25:    2 (cov. freq: 64012144 
> > (1.07%))
> >      30 tracked: 1 (0.01%), >=0.25:    1 (cov. freq:    114573384 
> > (1.91%))
> >      32 tracked:    11 (0.12%), >=0.25:    8 (cov. freq: 13949431 
> > (0.23%))
> > 
> > stats for topn:
> > Total: 1519, total freq: 1660520369, covered freq: 767273373 (46.21%), 
> > missing freq: 84286328 (5.08%)
> > Total tuples: 5365 (size before: 9*N=13671, after: 2*N + 
> > (2*TUPLE_COUNT)=13768
> > Histogram:
> >   0 tracked:  1032 (67.94%), >=0.25:    0 (cov. freq:    0 
> > (0.00%))
> >   1 tracked:   154 (10.14%), >=0.25:  154 (cov. freq:    240913892 
> > (14.51%))
> >   2 tracked:    43 (2.83%), >=0.25:   62 (cov. freq: 28671331 
> > (1.73%))
> >   3 tracked:    38 (2.50%), >=0.25:   56 (cov. freq: 72179614 
> > (4.35%))
> >   4 tracked:    23 (1.51%), >=0.25:   38 (cov. freq:  9598177 
> > (0.58%))
> >   5 tracked:    36 (2.37%), >=0.25:   48 (cov. freq: 89840680 
> > (5.41%))
> >   6 tracked:    13 (0.86%), >=0.25:   17 (cov. freq:  4548625 
> > (0.27%))
> >   7 tracked: 8 (0.53%), >=0.25:   10 (cov. freq: 23456524 
> > (1.41%))
> >   8 tracked: 6 (0.39%), >=0.25:    6 (cov. freq:   357781 
> > (0.02%))
> >   9 tracked: 2 (0.13%), >=0.25:    2 (cov. freq:   266881 
> > (0.02%))
> >      10 tracked: 5 (0.33%), >=0.25:    5 (cov. freq:    68985 
> > (0.00%))
> >      11 tracked: 6 (0.39%), >=0.25:    7 (cov. freq:  6216337 
> > (0.37%))
> >      12 tracked: 1 (0.07%), >=0.25:    1 (cov. freq:  892 
> > (0.00%))
> >      13 tracked:    11 (0.72%), >=0.25:   11 (cov. freq: 70639704 
> > (4.25%))
> >      14 tracked: 3 (0.20%), >=0.25:    1 (cov. freq:    16524 
> > (0.00%))
> >      15 tracked: 1 (0.07%), >=0.25:    0 (cov. freq:    0 
> > (0.00%))
> >      16 tracked: 1 (0.07%), >=0.25:    1 (cov. freq:   106363 
> > (0.01%))
> >      17 tracked: 1 (0.07%), >=0.25:    0 (cov. freq:    0 
> > (0.00%))
> >      18 tracked: 2 (0.13%

Re: [PATCH 2/2] arm: Add support for interrupt routines to reg_needs_saving_p

[Christophe Lyon via Gcc-patches]

On Fri, 15 May 2020 at 11:38, Ramana Radhakrishnan
 wrote:
>
> On Fri, May 15, 2020 at 7:36 AM Christophe Lyon
>  wrote:
> >
> > On Thu, 14 May 2020 at 17:58, Ramana Radhakrishnan
> >  wrote:
> > >
> > > >  static bool reg_needs_saving_p (unsigned reg)
> > > >  {
> > > >unsigned long func_type = arm_current_func_type ();
> > >
> > > Ah ok , you needed it here.
> >
> > Yes sorry.
> > Is this patch (2/2) OK?
> >
>
> This looks ok to me as long as there are no regressions and you rejig
> the hunks between 1/2 and 2/2
>
Ok, thanks!

> regards
> Ramana
>
> > Thanks,
> >
> > Christophe
> >
> > >
> > > Ramana

Re: [stage1][PATCH] Make TOPN counter dynamically allocated.

[Martin Liška]

On 5/15/20 1:03 PM, Jan Hubicka wrote:

I wonder, did we somehow solved the issue with Firefox breaking due to
malloc instrumentation?


Yes, you proposed a patch:
https://hg.mozilla.org/try/rev/e1358ef2d82c035b12f8995712580c77bd9f8d43

Which I believe was sent to Firefox?

Martin

Re: New mklog script

[Martin Liška]

On 5/15/20 12:58 PM, David Malcolm wrote:

On Fri, 2020-05-15 at 10:59 +0200, Martin Liška wrote:

Hi.

Since we moved to git world and we're in the preparation for
ChangeLog messages
being in git commit messages, I think it's the right time to also
simplify mklog
script.

I'm sending a new version (which should eventually replace
contrib/mklog and contrib/mklog.pl).
Changes made in the version:

- the script uses unifdiff - it rapidly simplifies parsing of the '+-
!' lines that is done
in contrib/mklog
- no author nor date stamp is used - that all can be get from git
- --inline option is not supported - I don't see a use-case for it
now
- the new script has a unit tests (just few of them for now)

I compares results in between the old Python script for last 80
commits and it's very close,
in some cases it does even better.

I'm planning to maintain and improve the script for the future.

Thoughts?
Martin



+class TestMklog(unittest.TestCase):
+def test_macro_definition(self):
+changelog = generate_changelog(PATCH1)
+assert changelog == EXPECTED1
+
+def test_changed_argument(self):
+changelog = generate_changelog(PATCH2)
+assert changelog == EXPECTED2
+
+def test_enum_and_struct(self):
+changelog = generate_changelog(PATCH3)
+assert changelog == EXPECTED3
+
+def test_no_function(self):
+changelog = generate_changelog(PATCH3, True)
+assert changelog == EXPECTED3B


Thank you David for review.

However I see the same output for both operator== and assertEqual. Probably
because of usage of pytest version 4?

assertEqual:

$ pytest contrib/test_mklog_ng.py
Test session starts (platform: linux, Python 3.8.2, pytest 4.6.9, pytest-sugar 
0.9.3)
benchmark: 3.2.3 (defaults: timer=time.perf_counter disable_gc=False 
min_rounds=5 min_time=0.05 max_time=1.0 calibration_precision=10 
warmup=False warmup_iterations=10)
rootdir: /home/marxin/Programming/gcc
plugins: xdist-1.32.0, sugar-0.9.3, forked-1.1.3, benchmark-3.2.3, 
aspectlib-1.5.0, cov-2.8.1, flake8-1.0.5
collecting ...
 contrib/test_mklog_ng.py ✓ 


  25% ██▌


 TestMklog.test_enum_and_struct 


self = 

def test_enum_and_struct(self):
changelog = generate_changelog(PATCH3)

  self.assertEqual(changelog, EXPECTED3)

E   AssertionError: 'libc[23 chars]clude/cpplib.h (enum c_lang):\n\t(struct 
cpp_options):\n\n' != 'libc[23 chars]clude/cppli22b.h (enum c_lang):\n\t(struct 
cpp_optio44ns):\n\n'
E libcpp/ChangeLog:
E
E   -   * include/cpplib.h (enum c_lang):
E   +   * include/cppli22b.h (enum c_lang):
E   ?  ++
E   -   (struct cpp_options):
E   +   (struct cpp_optio44ns):
E   ?++

contrib/test_mklog_ng.py:154: AssertionError

operator==:

pytest contrib/test_mklog_ng.py
Test session starts (platform: linux, Python 3.8.2, pytest 4.6.9, pytest-sugar 
0.9.3)
benchmark: 3.2.3 (defaults: timer=time.perf_counter disable_gc=False 
min_rounds=5 min_time=0.05 max_time=1.0 calibration_precision=10 
warmup=False warmup_iterations=10)
rootdir: /home/marxin/Programming/gcc
plugins: xdist-1.32.0, sugar-0.9.3, forked-1.1.3, benchmark-3.2.3, 
aspectlib-1.5.0, cov-2.8.1, flake8-1.0.5
collecting ...
 contrib/test_mklog_ng.py ✓ 


  25% ██▌


 TestMklog.test_enum_and_struct 


self = 

def test_enum_and_struct(self):
changelog = generate_changelog(PATCH3)

  assert changelog == EXPECTED3

E   AssertionError: assert 'libcpp/Chang...options):\n\n' == 
'libcpp/Change...tio44ns):\n\n'
E   libcpp/ChangeLog:
E
E - * include/cpplib.h (enum c_lang):
E + * include/cppli22b.h (enum c_lang):
E ?++
E - (struct cpp_options):
E + (struct cpp_optio44ns):...
E
E ...Full output truncated (3 lines hidden), use '-vv' to show

Martin



Use self.assertEqual(a, b) rather than assert a == b, so that if it
fails you get a multiline diff:

e.g.:

import unittest

class 

Re: [Patch][Fortran] OpenMP 5 – permit more sharing clauses for SIMD (PR94690)

[Jakub Jelinek via Gcc-patches]

On Fri, May 15, 2020 at 12:53:41PM +0200, Tobias Burnus wrote:
> [Fortran] OpenMP 5 – permit more sharing clauses for SIMD (PR94690)
> 
> gcc/fortran/
>   PR fortran/94690
>   * openmp.c (resolve_omp_do):

I'd hope Martin's script would reject such a commit.  You didn't say what
you've changed.

> gcc/testsuite/
>   PR fortran/94690
>   * gfortran.dg/gomp/openmp-simd-4.f90: New test.

Otherwise LGTM, except that I think (but that can be done incrementally)
that it would be highly desirable to have also a runtime testcase that tests
the values after the loop when lastprivate or linear clauses are used
or are predetermined.  Some of that is hopefully already in the testsuite
somewhere (the cases that were valid before), and one really can't test
after private (explicit or predetermined), because the value is undefined.
So that boils down to lastprivate on simd collapse(1) or simd without
collapse, and various kinds of do loops (step 1, -1, constant other,
variable), ideally some that can be actually vectorized.  And that
test doesn't need to be in libgomp, but could be in gfortran.dg/vect/
with -fopenmp-simd.

Jakub

[ARM][wwwdocs]: Document Armv8.1-M Mainline Security Extensions changes.

[Srinath Parvathaneni]

Armv8.1-M Mainline Security Extensions related changes in GCC-10.


### Attachment also inlined for ease of reply###


diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 
57ca749da72ed64da37b3eb5404cf5cde8be44dd..10bf3b78c7769b73c808bd2c2fe60ebbfc9c887e
 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -747,6 +747,9 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
   Support for the Custom Datapath Extension beta ACLE
   https://developer.arm.com/docs/101028/0010/custom-datapath-extension";>
   intrinsics has been added.
+  Support for Armv8.1-M Mainline Security Extensions architecture has been 
added. The -mcmse option,
+  when used in combination with an Armv8.1-M Mainline architecture (for 
example, -march=armv8.1.m.main -mcmse),
+  now leads to the generation of improved code sequences when changing 
security states.
 
 
 

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 
57ca749da72ed64da37b3eb5404cf5cde8be44dd..10bf3b78c7769b73c808bd2c2fe60ebbfc9c887e
 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -747,6 +747,9 @@ typedef svbool_t pred512 
__attribute__((arm_sve_vector_bits(512)));
   Support for the Custom Datapath Extension beta ACLE
   https://developer.arm.com/docs/101028/0010/custom-datapath-extension";>
   intrinsics has been added.
+  Support for Armv8.1-M Mainline Security Extensions architecture has been 
added. The -mcmse option,
+  when used in combination with an Armv8.1-M Mainline architecture (for 
example, -march=armv8.1.m.main -mcmse),
+  now leads to the generation of improved code sequences when changing 
security states.
 
 
 

[PATCH] fixup BB vectorization constant generation place

[Richard Biener]

This adjusts the way we compute the stmt insert location for
invariants in BB vectorization context to deal with eventually
sharing invariant SLP nodes for multiple uses.  We can no longer
use a single use stmt location then but there's a simple way out.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

2020-05-15  Richard Biener  

* tree-vect-slp.c (vect_get_constant_vectors): Really place
init stmt after scalar defs.
---
 gcc/tree-vect-slp.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 6f623955ce5..3886cede283 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3604,7 +3604,7 @@ vect_get_constant_vectors (vec_info *vinfo,
   constant_p = true;
   tree_vector_builder elts (vector_type, nunits, 1);
   elts.quick_grow (nunits);
-  bool place_after_defs = false;
+  stmt_vec_info insert_after = NULL;
   for (j = 0; j < number_of_copies; j++)
 {
   for (i = group_size - 1; op_node->ops.iterate (i, &op); i--)
@@ -3663,12 +3663,20 @@ vect_get_constant_vectors (vec_info *vinfo,
  elts[number_of_places_left_in_vector] = op;
  if (!CONSTANT_CLASS_P (op))
constant_p = false;
+ /* For BB vectorization we have to compute an insert location
+when a def is inside the analyzed region since we cannot
+simply insert at the BB start in this case.  */
+ stmt_vec_info opdef;
  if (TREE_CODE (orig_op) == SSA_NAME
  && !SSA_NAME_IS_DEFAULT_DEF (orig_op)
  && is_a  (vinfo)
- && (as_a  (vinfo)->bb
- == gimple_bb (SSA_NAME_DEF_STMT (orig_op
-   place_after_defs = true;
+ && (opdef = vinfo->lookup_def (orig_op)))
+   {
+ if (!insert_after)
+   insert_after = opdef;
+ else
+   insert_after = get_later_stmt (insert_after, opdef);
+   }
 
   if (number_of_places_left_in_vector == 0)
 {
@@ -3685,12 +3693,11 @@ vect_get_constant_vectors (vec_info *vinfo,
  vec_cst = permute_results[number_of_vectors - j - 1];
}
  tree init;
- gimple_stmt_iterator gsi;
- if (place_after_defs)
+ if (insert_after)
{
- stmt_vec_info last_stmt_info
-   = vect_find_last_scalar_stmt_in_slp (slp_node);
- gsi = gsi_for_stmt (last_stmt_info->stmt);
+ gimple_stmt_iterator gsi = gsi_for_stmt (insert_after->stmt);
+ /* vect_init_vector inserts before.  */
+ gsi_next (&gsi);
  init = vect_init_vector (vinfo, stmt_vinfo, vec_cst,
   vector_type, &gsi);
}
@@ -3699,12 +3706,13 @@ vect_get_constant_vectors (vec_info *vinfo,
 vector_type, NULL);
  if (ctor_seq != NULL)
{
- gsi = gsi_for_stmt (SSA_NAME_DEF_STMT (init));
+ gimple_stmt_iterator gsi
+   = gsi_for_stmt (SSA_NAME_DEF_STMT (init));
  gsi_insert_seq_before (&gsi, ctor_seq, GSI_SAME_STMT);
  ctor_seq = NULL;
}
  voprnds.quick_push (init);
- place_after_defs = false;
+ insert_after = NULL;
   number_of_places_left_in_vector = nunits;
  constant_p = true;
  elts.new_vector (vector_type, nunits, 1);
-- 
2.12.3

Re: New mklog script

[Marek Polacek via Gcc-patches]

On Fri, May 15, 2020 at 10:59:56AM +0200, Martin Liška wrote:
> Hi.
> 
> Since we moved to git world and we're in the preparation for ChangeLog 
> messages
> being in git commit messages, I think it's the right time to also simplify 
> mklog
> script.
> 
> I'm sending a new version (which should eventually replace contrib/mklog and 
> contrib/mklog.pl).
> Changes made in the version:
> 
> - the script uses unifdiff - it rapidly simplifies parsing of the '+-!' lines 
> that is done
>   in contrib/mklog

Nice!

> - no author nor date stamp is used - that all can be get from git

This is good.

> - --inline option is not supported - I don't see a use-case for it now

I actually use mklog -i all the time.  But I can work around it if it
disappears.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: New mklog script

[David Malcolm via Gcc-patches]

On Fri, 2020-05-15 at 13:20 +0200, Martin Liška wrote:
> On 5/15/20 12:58 PM, David Malcolm wrote:
> > On Fri, 2020-05-15 at 10:59 +0200, Martin Liška wrote:
> > > Hi.
> > > 
> > > Since we moved to git world and we're in the preparation for
> > > ChangeLog messages
> > > being in git commit messages, I think it's the right time to also
> > > simplify mklog
> > > script.
> > > 
> > > I'm sending a new version (which should eventually replace
> > > contrib/mklog and contrib/mklog.pl).
> > > Changes made in the version:
> > > 
> > > - the script uses unifdiff - it rapidly simplifies parsing of the
> > > '+-
> > > !' lines that is done
> > > in contrib/mklog
> > > - no author nor date stamp is used - that all can be get from git
> > > - --inline option is not supported - I don't see a use-case for
> > > it
> > > now
> > > - the new script has a unit tests (just few of them for now)
> > > 
> > > I compares results in between the old Python script for last 80
> > > commits and it's very close,
> > > in some cases it does even better.
> > > 
> > > I'm planning to maintain and improve the script for the future.
> > > 
> > > Thoughts?
> > > Martin
> > > +class TestMklog(unittest.TestCase):
> > > +def test_macro_definition(self):
> > > +changelog = generate_changelog(PATCH1)
> > > +assert changelog == EXPECTED1
> > > +
> > > +def test_changed_argument(self):
> > > +changelog = generate_changelog(PATCH2)
> > > +assert changelog == EXPECTED2
> > > +
> > > +def test_enum_and_struct(self):
> > > +changelog = generate_changelog(PATCH3)
> > > +assert changelog == EXPECTED3
> > > +
> > > +def test_no_function(self):
> > > +changelog = generate_changelog(PATCH3, True)
> > > +assert changelog == EXPECTED3B
> 
> Thank you David for review.
> 
> However I see the same output for both operator== and assertEqual.
> Probably
> because of usage of pytest version 4?

Ah, yes.  pytest does "magical" things with frame inspection IIRC to
scrape the locals out of the failing python stack frame.

Dave

Re: New mklog script

[Martin Liška]

On 5/15/20 2:42 PM, Marek Polacek wrote:

I actually use mklog -i all the time.  But I can work around it if it
disappears.


Ah, I can see a consumer.
There's an updated version that supports that.

For the future, will you still use the option? Wouldn't be better
to put the ChangeLog content directly to commit message? Note
that you won't have to copy the entries to a particular ChangeLog file.

Martin
>From d7d5e3aa7450449a8b0cb30d6bf485538990ea3f Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 15 May 2020 00:44:07 +0200
Subject: [PATCH] Add mklog-ng.py and gcc-mklog git alias.

contrib/ChangeLog:

	* gcc-git-customization.sh: Add gcc-mklog alias.
	* mklog_ng.py: New file.
	* test_mklog_ng.py: New file.
---
 contrib/gcc-git-customization.sh |   2 +
 contrib/mklog_ng.py  | 209 +++
 contrib/test_mklog_ng.py | 158 +++
 3 files changed, 369 insertions(+)
 create mode 100755 contrib/mklog_ng.py
 create mode 100755 contrib/test_mklog_ng.py

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index a932bf8c06a..b7b97327be3 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -25,6 +25,8 @@ git config alias.svn-rev '!f() { rev=$1; shift; git log --all --grep="^From-SVN:
 git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then c=\${2:-master}; r=\$(git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' \$c | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p'); expr match \${r:-no} '^r[0-9]\\+\$' >/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master}); else c=\${1:-master}; r=\$(git describe --all --match 'basepoints/gcc-[0-9]*' \$c | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)\$,r\\2-0,p'); fi; if test -n \$r; then o=\$(git config --get gcc-config.upstream); rr=\$(echo \$r | sed -n 's,^r\\([0-9]\\+\\)-[0-9]\\+\\(-g[0-9a-f]\\+\\)\\?\$,\\1,p'); if git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$rr >/dev/null; then m=releases/gcc-\$rr; else m=master; fi; git merge-base --is-ancestor \$c \${o:-origin}/\$m && \echo \${r}; fi; }; f"
 git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream); r=\$(echo \$1 | sed -n 's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 && exit 1; h=\$(git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$r); test -z \$h && h=\$(git rev-parse --verify --quiet \${o:-origin}/master); p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\2,p;s,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+\$,0,p'); git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
 
+git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog_ng.py" $@; } ; f'
+
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
 # *.mddiff=md
diff --git a/contrib/mklog_ng.py b/contrib/mklog_ng.py
new file mode 100755
index 000..8dca6dbeef0
--- /dev/null
+++ b/contrib/mklog_ng.py
@@ -0,0 +1,209 @@
+#!/usr/bin/env python3
+
+# Copyright (C) 2020 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 COPYING.  If not, write to
+# the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301, USA.
+
+# This script parses a .diff file generated with 'diff -up' or 'diff -cp'
+# and adds a skeleton ChangeLog file to the file. It does not try to be
+# too smart when parsing function names, but it produces a reasonable
+# approximation.
+#
+# Author: Martin Liska 
+
+import argparse
+import os
+import re
+import sys
+import tempfile
+
+from unidiff import PatchSet
+
+pr_regex = re.compile(r'(\/(\/|\*)|[Cc*!])\s+(?PPR [a-z+-]+\/[0-9]+)')
+identifier_regex = re.compile(r'^([a-zA-Z0-9_#].*)')
+comment_regex = re.compile(r'^\/\*')
+struct_regex = re.compile(r'^((class|struct|union|enum)\s+[a-zA-Z0-9_]+)')
+macro_regex = re.compile(r'#\s*(define|undef)\s+([a-zA-Z0-9_]+)')
+super_macro_regex = re.compile(r'^DEF[A-Z0-9_]+\s*\(([a-zA-Z0-9_]+)')
+fn_regex = re.compile(r'([a-zA-Z_][^()\s]*)\s*\([^*]')
+template_and_param_regex = re.compile(r'<[^<>]*>')
+
+function_extensions = set(['.c', '.cpp', '.C', '.

[PATCH] x86: Also check if -fcf-protection works

[H.J. Lu via Gcc-patches]

When defaulting CET run-time support to auto, check if -fcf-protection
works.  Even if the stage1 GCC doesn't support -fcf-protection, since
the final GCC does, CET run-time support will be enabled by default if
binutils support CET.

config/

PR bootstrap/95147
* cet.m4 (GCC_CET_FLAGS): Also check if -fcf-protection works
when defaulting to auto.

libatomic/

PR bootstrap/95147
* configure: Regenerated.

libbacktrace/

PR bootstrap/95147
* configure: Regenerated.

libgcc/

PR bootstrap/95147
* configure: Regenerated.

libgfortran/

PR bootstrap/95147
* configure: Regenerated.

libgomp/

PR bootstrap/95147
* configure: Regenerated.

libitm/

PR bootstrap/95147
* configure: Regenerated.

libobjc/

PR bootstrap/95147
* configure: Regenerated.

libphobos/

PR bootstrap/95147
* configure: Regenerated.

libquadmath/

PR bootstrap/95147
* configure: Regenerated.

libsanitizer/

PR bootstrap/95147
* configure: Regenerated.

libssp/

PR bootstrap/95147
* configure: Regenerated.

libstdc++-v3/

PR bootstrap/95147
* configure: Regenerated.

libvtv/

PR bootstrap/95147
* configure: Regenerated.

zlib/

PR bootstrap/95147
* configure: Regenerated.
---
 config/cet.m4  |  3 +++
 libatomic/configure|  3 +++
 libbacktrace/configure |  3 +++
 libgcc/configure   |  3 +++
 libgfortran/configure  |  7 +--
 libgomp/configure  |  3 +++
 libitm/configure   |  3 +++
 libobjc/configure  |  7 +--
 libphobos/configure| 11 +++
 libquadmath/configure  |  3 +++
 libsanitizer/configure |  3 +++
 libssp/configure   |  7 +--
 libstdc++-v3/configure |  3 +++
 libvtv/configure   |  3 +++
 zlib/configure |  7 +--
 15 files changed, 57 insertions(+), 12 deletions(-)

diff --git a/config/cet.m4 b/config/cet.m4
index 63c6ea9ee02..2bb2c8a95ac 100644
--- a/config/cet.m4
+++ b/config/cet.m4
@@ -13,6 +13,8 @@ case "$host" in
   auto)
# Check if target supports multi-byte NOPs
# and if assembler supports CET insn.
+   save_CFLAGS="$CFLAGS"
+   CFLAGS="$CFLAGS -fcf-protection"
AC_COMPILE_IFELSE(
 [AC_LANG_PROGRAM(
  [],
@@ -25,6 +27,7 @@ asm ("setssbsy");
  ])],
 [enable_cet=yes],
 [enable_cet=no])
+   CFLAGS="$save_CFLAGS"
;;
   yes)
# Check if assembler supports CET.
diff --git a/libatomic/configure b/libatomic/configure
index c4b4714abc0..478670a6fe7 100755
--- a/libatomic/configure
+++ b/libatomic/configure
@@ -15595,6 +15595,8 @@ case "$host" in
   auto)
# Check if target supports multi-byte NOPs
# and if assembler supports CET insn.
+   save_CFLAGS="$CFLAGS"
+   CFLAGS="$CFLAGS -fcf-protection"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
@@ -15618,6 +15620,7 @@ else
   enable_cet=no
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+   CFLAGS="$save_CFLAGS"
;;
   yes)
# Check if assembler supports CET.
diff --git a/libbacktrace/configure b/libbacktrace/configure
index 95d06c60be1..d851e807d2d 100755
--- a/libbacktrace/configure
+++ b/libbacktrace/configure
@@ -12169,6 +12169,8 @@ case "$host" in
   auto)
# Check if target supports multi-byte NOPs
# and if assembler supports CET insn.
+   save_CFLAGS="$CFLAGS"
+   CFLAGS="$CFLAGS -fcf-protection"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
@@ -12192,6 +12194,7 @@ else
   enable_cet=no
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+   CFLAGS="$save_CFLAGS"
;;
   yes)
# Check if assembler supports CET.
diff --git a/libgcc/configure b/libgcc/configure
index a5d5ab84607..5d0c79bcd75 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -4913,6 +4913,8 @@ case "$host" in
   auto)
# Check if target supports multi-byte NOPs
# and if assembler supports CET insn.
+   save_CFLAGS="$CFLAGS"
+   CFLAGS="$CFLAGS -fcf-protection"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
@@ -4936,6 +4938,7 @@ else
   enable_cet=no
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+   CFLAGS="$save_CFLAGS"
;;
   yes)
# Check if assembler supports CET.
diff --git a/libgfortran/configure b/libgfortran/configure
index 3c8be061ede..97d9616e425 100755
--- a/libgfortran/configure
+++ b/libgfortran/configure
@@ -6014,6 +6014,8 @@ case "$host" in
   auto)
# Check if target supports multi-byte NOPs
# and if assembler supports CET insn.
+   save_CFLAGS="$CFLAGS"
+   CFLAGS="$CFLAGS -fcf-protection"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
@@ -6037,6 +60

Re: New mklog script

[Marek Polacek via Gcc-patches]

On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> On 5/15/20 2:42 PM, Marek Polacek wrote:
> > I actually use mklog -i all the time.  But I can work around it if it
> > disappears.
> 
> Ah, I can see a consumer.
> There's an updated version that supports that.
> 
> For the future, will you still use the option? Wouldn't be better
> to put the ChangeLog content directly to commit message? Note
> that you won't have to copy the entries to a particular ChangeLog file.

The way I do it is to generate a patch using format-patch, use mklog -i
on it, then add the ChangeLog entry to the commit message via commit --amend.

Anything that has to do with ChangeLogs is pointless make-work, so the less
I have to do, the better.  ;-)

Marek

Re: testsuite: clarify scan-dump file globbing behavior

[Thomas Schwinge]

Hi Frederik!

(We had internally discussed this.)

I can't formally approve testsuite patches, but did a review anyway:

On 2020-05-15T12:31:54+0200, Frederik Harwath  wrote:
> The test commands for scanning optimization dump files
> perform globbing on the argument that specifies the suffix
> of the dump files to be scanned. This behavior is currently
> undocumented. Furthermore, the current implementation of
> "scan-dump" and related procedures yields an error whenever
> the file name globbing matches more than one file (due to an
> attempt to call "open" on multiple files) while a failure to
> match any file at all results in an unresolved test.
>
> This patch documents the globbing behavior.

ACK.

> The dump
> scanning procedures are changed to make the test unresolved
> if globbing matches more than one file.

(The code changes look good, but I have not tested that specific aspect.)

> The procedures in scandump.exp all perform the file name expansion in
> essentially the same way and I have extracted this into a new
> procedure.

Thanks, that looks like I thought it should.

> But there is one very minor exception:
>
>> @@ -67,10 +95,10 @@ proc scan-dump { args } {
>>  set dumpbase [dump-base $src [lindex $args 3]]
>> -set output_file "[glob -nocomplain $dumpbase.[lindex $args 2]]"
>> +
>> +set pattern "$dumpbase.[lindex $args 2]"
>> +set output_file "[glob-dump-file $testcase $pattern]"
>>  if { $output_file == "" } {
>> - verbose -log "$testcase: dump file does not exist"
>> - verbose -log "dump file: $dumpbase.$suf"
>
> "scan-dump" is the only procedure that prints the "dump file: ..." line.
> Should this be kept or is it ok to remove this as I have done in the
> patch? $dumpbase.$suf does not emit the correct file name anyway
> (a random example from my testing: "dump file: stdatomic-init.c.dce*")
> and the name of the files can be inferred from the test name easily.

OK to remove, as far as I'm concerned.

> I have tested the changes by running "make check" (with a
> --enable-languages=C only build, but this covers lots of uses
> of the affected test procedures) and observed no regressions.

I did a full 'make check' on powerpc64le-unknown-linux-gnu -- no issues
found.

> Ok to commit this to master?

As I said, not an approval, and minor comments (see below), but still:

Reviewed-by: Thomas Schwinge 

Do we have to similarly also audit/alter other testsuite infrastructure
files, anything that uses '[glob [...]]'?  (..., and then generalize
'glob-dump-file' into 'glob-one-file', or similar.)  That can be done
incrementally, as far as I'm concerned.

> From 6912e03d51d360dbbcf7eb1dc8d77d08c2a6e54c Mon Sep 17 00:00:00 2001
> From: Frederik Harwath 
> Date: Fri, 15 May 2020 10:35:48 +0200
> Subject: [PATCH] testsuite: clarify scan-dump file globbing behavior
>
> The test commands for scanning optimization dump files
> perform globbing on the argument that specifies the suffix
> of the dump files to be scanned.  This behavior is currently
> undocumented.  Furthermore, the current implementation of
> "scan-dump" and similar procedures yields an error whenever
> the file name globbing matches more than one file (due to an
> attempt to call "open" on multiple files) while a failure to
> match any file results in an unresolved test.
>
> This commit documents the globbing behavior.  The dump
> scanning procedures are changed to make the test unresolved
> if globbing matches more than one file.
>
> gcc/ChangeLog:
>
> 2020-05-15  Frederik Harwath  
>
>   * doc/sourcebuild.texi: Describe globbing of the
>   dump file scanning commands "suffix" argument.
>
> gcc/testsuite/ChangeLog:
>
> 2020-05-15  Frederik Harwath  
>
>   * lib/scandump.exp (glob-dump-file): New proc.
>   (scan-dump): Use glob-dump-file for file name expansion.
>   (scan-dump-times): Likewise.
>   (scan-dump-dem): Likewise.
>   (scan-dump-dem-not): Likewise.
> ---
>  gcc/doc/sourcebuild.texi   |  4 ++-
>  gcc/testsuite/lib/scandump.exp | 54 +++---
>  2 files changed, 46 insertions(+), 12 deletions(-)
>
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 240d6e4b08e..b6c5a21cb71 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -2888,7 +2888,9 @@ stands for zero or more unmatched lines; the whitespace 
> after
>
>  These commands are available for @var{kind} of @code{tree}, 
> @code{ltrans-tree},
>  @code{offload-tree}, @code{rtl}, @code{offload-rtl}, @code{ipa}, and
> -@code{wpa-ipa}.
> +@code{wpa-ipa}.  The @var{suffix} argument which describes the dump file

(You can add your new sentence addition on a new line.)

> +to be scanned may contain a glob pattern that must expand to exactly one
> +file name.

May also make this more useful/explicit:

This is useful if, for example, if a pass has several static
instances [correct terminology?], and depending on torture testing
command-line fl

Re: [C++] template arg comparison

[Nathan Sidwell]

On 5/14/20 3:17 PM, Arseny Solokha wrote:

Hi,



-  if (TREE_CODE (nt) == TREE_VEC)
+  if (TREE_CODE (nt) == TREE_VEC || TREE_CODE (nt) == TREE_VEC)


Shouldn't there be

   if (TREE_CODE (ot) == TREE_VEC || TREE_CODE (nt) == TREE_VEC)



+  else if (TYPE_P (nt) || TYPE_P (nt))


And here:

   else if (TYPE_P (ot) || TYPE_P (nt))


Whoops, I flubbed that.  Fixed thusly.

In other news, someone's reading my patches!  Seriously, thanks!

nathan

--
Nathan Sidwell
2020-05-15  Nathan Sidwell  

	* pt.c (template_args_equal): Fix thinkos in previous 'cleanup'.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 2a0b18f5517..bfeeebc2b38 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -9087,7 +9087,7 @@ template_args_equal (tree ot, tree nt, bool partial_order /* = false */)
   if (class_nttp_const_wrapper_p (ot))
 ot = TREE_OPERAND (ot, 0);
 
-  if (TREE_CODE (nt) == TREE_VEC || TREE_CODE (nt) == TREE_VEC)
+  if (TREE_CODE (nt) == TREE_VEC || TREE_CODE (ot) == TREE_VEC)
 /* For member templates */
 return TREE_CODE (ot) == TREE_CODE (nt) && comp_template_args (ot, nt);
   else if (PACK_EXPANSION_P (ot) || PACK_EXPANSION_P (nt))
@@ -9100,7 +9100,7 @@ template_args_equal (tree ot, tree nt, bool partial_order /* = false */)
 return cp_tree_equal (ot, nt);
   else if (TREE_CODE (ot) == ARGUMENT_PACK_SELECT)
 gcc_unreachable ();
-  else if (TYPE_P (nt) || TYPE_P (nt))
+  else if (TYPE_P (nt) || TYPE_P (ot))
 {
   if (!(TYPE_P (nt) && TYPE_P (ot)))
 	return false;

Re: libgo patch committed: Build syscall test with -static

[Rainer Orth]

Hi Ian,

> On Thu, May 14, 2020 at 12:43 PM Rainer Orth
>  wrote:
>>
>> > This libgo patch builds the syscall test with -static.  This avoids
>> > problems finding libgo.so when running the test as root, which invokes
>> > the test as a child process in various limited environments.  This
>> > fixes GCC PR 95061.  Bootstrapped and ran Go tests on
>> > x86_64-pc-linux-gnu.  Committed to mainline.
>>
>> this patch broke the syscall test on Solaris:
>>
>> ld: fatal: library -lpthread: not found
>> ld: fatal: library -lm: not found
>> ld: fatal: library -lc: not found
>> ld: fatal: library -lc: not found
>> collect2: error: ld returned 1 exit status
>> FAIL: syscall
>>
>> There are no static versions of system libraries.
>
> Sorry about that.  The issue only arises on GNU/Linux, so committed
> this patch after testing to at least fix the problem on Solaris.

thanks.  However, during today's Linux/x86_64 bootstrap I see that the
test fails there and indeed glibc-static isn't installed.

Rainer

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

New Swedish PO file for 'cpplib' (version 10.1-b20200209)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/sv.po

(This file, 'cpplib-10.1-b20200209.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-10.1-b20200209.sv.po'

[Translation Project Robot]

cpplib-10.1-b20200209.sv.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

[no subject]

[Richard Sandiford]

>> > We've moved more and more to stronly-typed data structures
>> > so I'd not like to see 'auto' everywhere - it should be still
>> > obvious what kind of objects we're working with where they
>> > matter.  IMHO they do not matter for example for iterators.
>> > I don't care about the iterator type but about the type of
>> > the object and the container.
>>
>> Also agreed. :-)  How about this as a starting point:
>>
>> ---
>> Use auto for:
>>
>> - the result of casts or other expressions that give the type
>>   explicitly.  E.g.:
>>
>> if (auto *table = dyn_cast  (insn))
>>
>>   instead of:
>>
>> if (rtx_jump_table_data *table = dyn_cast  (insn))
>>
>> - iterator types.  E.g.:
>>
>> auto it = foo.begin ();
>>
>>   instead of:
>>
>> foo_type::iterator it = foo.begin ();
>>
>> - expressions that provide an alternative view of something,
>>   when the expression is bound to a read-only temporary.  E.g.:
>>
>> auto val1 = wi::to_wide (...);
>> auto val2 = wi::uhwi (12, 16);
>>
>>   instead of:
>>
>> wide_int val1 = wi::to_wide (...);
>> wide_int val2 = wi::uhwi (12, 16);
>>
>>   (Using "wide_int" is less efficient than using the natural type of
>>   the expression.)
>>
>> - the type of a lambda expression.  E.g.:
>>
>> auto f = [] (int x) { return x + 1; };
>
> Those are all good examples.  Mind putting that into a patch
> for the coding conventions?

How's this?  I added "new" expressions as another example of the
first category.

I'm sure I've missed other good uses, but we can always add to the
list later if necessary.

Thanks,
Richard

>From 10b27e367de0fa9d5bf91544385401cdcbdb8c00 Mon Sep 17 00:00:00 2001
From: Richard Sandiford 
Date: Fri, 15 May 2020 14:58:46 +0100
Subject: [PATCH] Describe coding conventions surrounding "auto"

---
 htdocs/codingconventions.html | 53 +++
 htdocs/codingrationale.html   | 17 +++
 2 files changed, 70 insertions(+)

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index f4732ef6..ae49fb91 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -51,6 +51,7 @@ the conventions separately from any other changes to the 
code.
 Language Use
 
 Variable Definitions
+Use of auto
 Struct Definitions
 Class Definitions
 Constructors and Destructors
@@ -884,6 +885,58 @@ Variables may be simultaneously defined and tested in 
control expressions.
 Rationale and Discussion
 
 
+Use of auto
+
+auto should be used in the following circumstances:
+
+  when the expression gives the C++ type explicitly.  For example
+
+
+if (auto *table = dyn_cast  
(insn)) // OK
+  ...
+if (rtx_jump_table_data *table = dyn_cast  
(insn))  // Avoid
+  ...
+auto *map = new hash_map ;   
 // OK
+hash_map  *map = new hash_map ; // 
Avoid
+
+This rule does not apply to abbreviated type names embedded in
+an identifier, such as the result of tree_to_shwi.
+  
+  
+when the expression simply provides an alternative view of an object
+and is bound to a read-only temporary.  For example:
+
+
+auto wioff = wi::to_wide (off); // OK
+wide_int wioff = wi::to_wide (off); // Avoid if wioff is read-only
+auto minus1 = std::shwi (-1, prec); // OK
+wide_int minus1 = std::shwi (-1, prec); // Avoid if minus1 is 
read-only
+
+In principle this rule applies to other views of an object too,
+such as a reversed view of a list, or a sequential view of a
+hash_set.  It does not apply to general temporaries.
+  
+  
+the type of an iterator.  For example:
+
+
+auto it = std::find (names.begin (), names.end (), needle); 
   // OK
+vector ::iterator it = std::find (names.begin (),
+names.end (), needle); // 
Avoid
+  
+  
+the type of a lambda expression.  For example:
+
+
+auto f = [] (int x) { return x + 1; }; // 
OK
+  
+
+
+auto should not be used in other contexts.
+
+
+Rationale and Discussion
+
 
 Struct Definitions
 
diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
index 0b44f1da..a919023c 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -50,6 +50,23 @@ if (info *q = get_any_available_info ()) {
 }
 
 
+Use of auto
+
+The reason for preferring auto in expressions like:
+auto wioff = wi::to_wide (off);
+is that using the natural type of the expression is more efficient than
+converting it to types like wide_int.
+
+The reason for excluding other uses of auto is that
+in most other cases the type carries useful information.  For example:
+for (const std::pair  &elt : 
indirect_pool)
+  ...
+makes it obvious that elt is a pair and gives the types of
+elt.first and elt.second.  In co

[committed] i386: Allow SI, DI and TImode pushes from XMM registers

[Uros Bizjak via Gcc-patches]

Also change XMM register constraint from "x" to "v" in FP push insns.

gcc/ChangeLog:

2020-05-15  Uroš Bizjak  

* config/i386/i386.md (SWI48DWI): New mode iterator.
(*push2): Allow XMM registers.
(*pushdi2_rex64): Ditto.
(*pushsi2_rex64): Ditto.
(*pushsi2): Ditto.
(push XMM reg splitter): New splitter

(*pushdf) Change "x" operand constraint to "v".
(*pushsf_rex64): Ditto.
(*pushsf): Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index b555c165647..1bf0c1a7f01 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -1051,6 +1051,9 @@
 ;; SWI and DWI together.
 (define_mode_iterator SWIDWI [QI HI SI DI (TI "TARGET_64BIT")])
 
+;; SWI48 and DWI together.
+(define_mode_iterator SWI48DWI [SI DI (TI "TARGET_64BIT")])
+
 ;; GET_MODE_SIZE for selected modes.  As GET_MODE_SIZE is not
 ;; compile time constant, it is faster to use  than
 ;; GET_MODE_SIZE (mode).  For XFmode which depends on
@@ -1672,8 +1675,8 @@
 ;; Push/pop instructions.
 
 (define_insn "*push2"
-  [(set (match_operand:DWI 0 "push_operand" "=<")
-   (match_operand:DWI 1 "general_no_elim_operand" "riF*o"))]
+  [(set (match_operand:DWI 0 "push_operand" "=<,<")
+   (match_operand:DWI 1 "general_no_elim_operand" "riF*o,*v"))]
   ""
   "#"
   [(set_attr "type" "multi")
@@ -1687,13 +1690,14 @@
   "ix86_split_long_move (operands); DONE;")
 
 (define_insn "*pushdi2_rex64"
-  [(set (match_operand:DI 0 "push_operand" "=<,!<")
-   (match_operand:DI 1 "general_no_elim_operand" "re*m,n"))]
+  [(set (match_operand:DI 0 "push_operand" "=<,<,!<")
+   (match_operand:DI 1 "general_no_elim_operand" "re*m,*v,n"))]
   "TARGET_64BIT"
   "@
push{q}\t%1
+   #
#"
-  [(set_attr "type" "push,multi")
+  [(set_attr "type" "push,multi,multi")
(set_attr "mode" "DI")])
 
 ;; Convert impossible pushes of immediate to existing instructions.
@@ -1727,34 +1731,53 @@
 plus_constant (Pmode, stack_pointer_rtx, 4));
 })
 
+;; For TARGET_64BIT we always round up to 8 bytes.
+(define_insn "*pushsi2_rex64"
+  [(set (match_operand:SI 0 "push_operand" "=X,X")
+   (match_operand:SI 1 "nonmemory_no_elim_operand" "ri,*v"))]
+  "TARGET_64BIT"
+  "@
+   push{q}\t%q1
+   #"
+  [(set_attr "type" "push,multi")
+   (set_attr "mode" "DI")])
+
 (define_insn "*pushsi2"
-  [(set (match_operand:SI 0 "push_operand" "=<")
-   (match_operand:SI 1 "general_no_elim_operand" "ri*m"))]
+  [(set (match_operand:SI 0 "push_operand" "=<,<")
+   (match_operand:SI 1 "general_no_elim_operand" "ri*m,*v"))]
   "!TARGET_64BIT"
-  "push{l}\t%1"
-  [(set_attr "type" "push")
+  "@
+   push{l}\t%1
+   #"
+  [(set_attr "type" "push,multi")
(set_attr "mode" "SI")])
 
-;; emit_push_insn when it calls move_by_pieces requires an insn to
-;; "push a byte/word".  But actually we use pushl, which has the effect
-;; of rounding the amount pushed up to a word.
+(define_split
+  [(set (match_operand:SWI48DWI 0 "push_operand")
+   (match_operand:SWI48DWI 1 "sse_reg_operand"))]
+  "TARGET_SSE && reload_completed"
+  [(set (reg:P SP_REG) (plus:P (reg:P SP_REG) (match_dup 2)))
+(set (match_dup 0) (match_dup 1))]
+{
+  operands[2] = GEN_INT (-PUSH_ROUNDING (GET_MODE_SIZE (mode)));
+  /* Preserve memory attributes. */
+  operands[0] = replace_equiv_address (operands[0], stack_pointer_rtx);
+})
 
-;; For TARGET_64BIT we always round up to 8 bytes.
-(define_insn "*push2_rex64"
-  [(set (match_operand:SWI124 0 "push_operand" "=X")
-   (match_operand:SWI124 1 "nonmemory_no_elim_operand" "r"))]
-  "TARGET_64BIT"
-  "push{q}\t%q1"
-  [(set_attr "type" "push")
-   (set_attr "mode" "DI")])
+;; emit_push_insn when it calls move_by_pieces requires an insn to
+;; "push a byte/word".  But actually we use push{l,q}, which has
+;; the effect of rounding the amount pushed up to a word.
 
 (define_insn "*push2"
   [(set (match_operand:SWI12 0 "push_operand" "=X")
(match_operand:SWI12 1 "nonmemory_no_elim_operand" "rn"))]
-  "!TARGET_64BIT"
-  "push{l}\t%k1"
+  ""
+  "* return TARGET_64BIT ? \"push{q}\t%q1\" : \"push{l}\t%k1\";"
   [(set_attr "type" "push")
-   (set_attr "mode" "SI")])
+   (set (attr "mode")
+   (if_then_else (match_test "TARGET_64BIT")
+ (const_string "DI")
+ (const_string "SI")))])
 
 (define_insn "*push2_prologue"
   [(set (match_operand:W 0 "push_operand" "=<")
@@ -3031,7 +3054,7 @@
 
 (define_insn "*pushdf"
   [(set (match_operand:DF 0 "push_operand" "=<,<,<,<,<,<")
-   (match_operand:DF 1 "general_no_elim_operand" "f,r,*r,oF,rmC,x"))]
+   (match_operand:DF 1 "general_no_elim_operand" "f,r,*r,oF,rmC,v"))]
   ""
 {
   /* This insn should be already split before reg-stack.  */
@@ -3064,7 +3087,7 @@
 
 (define_insn "*pushsf_rex64"
   [(set (match_operand:SF 0 "push_operand" "=X,X,X")
-   (match_operand:SF 1 "nonmemory_no_elim_operand" "f,rF,x"))]
+   (match_operand:SF 1 

Re: New mklog script

[Martin Sebor via Gcc-patches]

On 5/15/20 2:59 AM, Martin Liška wrote:

Hi.

Since we moved to git world and we're in the preparation for ChangeLog 
messages
being in git commit messages, I think it's the right time to also 
simplify mklog

script.

I'm sending a new version (which should eventually replace contrib/mklog 
and contrib/mklog.pl).

Changes made in the version:

- the script uses unifdiff - it rapidly simplifies parsing of the '+-!' 
lines that is done

   in contrib/mklog
- no author nor date stamp is used - that all can be get from git
- --inline option is not supported - I don't see a use-case for it now
- the new script has a unit tests (just few of them for now)

I compares results in between the old Python script for last 80 commits 
and it's very close,

in some cases it does even better.

I'm planning to maintain and improve the script for the future.

Thoughts?


It's pretty nice.  I have a script of my own that does the same thing
in a slightly different way.  Here's an example of its output:
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20200323/5437db5a/attachment-0001.bin

I find this format more helpful for the reasons below so unless your
script can be tweaked to do something similar I'd like to be able to
continue to use mine going forward with the new infrastructure.

As for my comments on mklog_ng.py: In the one test I did the script
produced a single long ChangeLog entry with all the files in the diff
I gave it, tests and all, in alphabetical order.  The script fills in
"New test." for new tests.  The rest has to be edited as one would
expect.

I would find the output easier to work with if it a) grouped files by
"subsystem" corresponding to each ChangeLog directory (and if it also
identified each subsystem), b) put the testsuite section last, and
(as a bonus) c) grouped all new files in each section together.

First, I find this logical grouping helpful in thinking about how
the changes are structured (e.g., would it make sense to restructure
them or break things up to reduce coupling and make review easier),
and whom they need to be reviewed by.

Second, this is the grouping I'm already used to from my own script
(so YMMV here of course).

Finally, my script also looks up bugs in Bugzilla and adds a line with
each bug number and its Summary at the top of the patch.  This helps me
double-check the spelling of the bug id(s) in case I transpose digits
etc.

Martin

PS My script modifies the patch file in place: it adds the ChangeLog
section if it doesn't exist yet, but it doesn't do anything it does.
I'd love for it to check the existing ChangeLog if it exists and
update it when it finds differences between it and the latest patch
that aren't reflected there.

Without this, each time a patch changes I have to review the entry
and update it as necessary.  That makes it too easy to miss things.

Re: [PATCH] x86: Also check if -fcf-protection works

[Richard Biener]

On May 15, 2020 3:16:38 PM GMT+02:00, "H.J. Lu"  wrote:
>When defaulting CET run-time support to auto, check if -fcf-protection
>works.  Even if the stage1 GCC doesn't support -fcf-protection, since
>the final GCC does, CET run-time support will be enabled by default if
>binutils support CET.

OK. 

Richard. 

>config/
>
>   PR bootstrap/95147
>   * cet.m4 (GCC_CET_FLAGS): Also check if -fcf-protection works
>   when defaulting to auto.
>
>libatomic/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libbacktrace/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libgcc/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libgfortran/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libgomp/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libitm/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libobjc/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libphobos/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libquadmath/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libsanitizer/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libssp/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libstdc++-v3/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>libvtv/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>
>zlib/
>
>   PR bootstrap/95147
>   * configure: Regenerated.
>---
> config/cet.m4  |  3 +++
> libatomic/configure|  3 +++
> libbacktrace/configure |  3 +++
> libgcc/configure   |  3 +++
> libgfortran/configure  |  7 +--
> libgomp/configure  |  3 +++
> libitm/configure   |  3 +++
> libobjc/configure  |  7 +--
> libphobos/configure| 11 +++
> libquadmath/configure  |  3 +++
> libsanitizer/configure |  3 +++
> libssp/configure   |  7 +--
> libstdc++-v3/configure |  3 +++
> libvtv/configure   |  3 +++
> zlib/configure |  7 +--
> 15 files changed, 57 insertions(+), 12 deletions(-)
>
>diff --git a/config/cet.m4 b/config/cet.m4
>index 63c6ea9ee02..2bb2c8a95ac 100644
>--- a/config/cet.m4
>+++ b/config/cet.m4
>@@ -13,6 +13,8 @@ case "$host" in
>   auto)
>   # Check if target supports multi-byte NOPs
>   # and if assembler supports CET insn.
>+  save_CFLAGS="$CFLAGS"
>+  CFLAGS="$CFLAGS -fcf-protection"
>   AC_COMPILE_IFELSE(
>[AC_LANG_PROGRAM(
> [],
>@@ -25,6 +27,7 @@ asm ("setssbsy");
> ])],
>[enable_cet=yes],
>[enable_cet=no])
>+  CFLAGS="$save_CFLAGS"
>   ;;
>   yes)
>   # Check if assembler supports CET.
>diff --git a/libatomic/configure b/libatomic/configure
>index c4b4714abc0..478670a6fe7 100755
>--- a/libatomic/configure
>+++ b/libatomic/configure
>@@ -15595,6 +15595,8 @@ case "$host" in
>   auto)
>   # Check if target supports multi-byte NOPs
>   # and if assembler supports CET insn.
>+  save_CFLAGS="$CFLAGS"
>+  CFLAGS="$CFLAGS -fcf-protection"
>   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> /* end confdefs.h.  */
> 
>@@ -15618,6 +15620,7 @@ else
>   enable_cet=no
> fi
> rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
>+  CFLAGS="$save_CFLAGS"
>   ;;
>   yes)
>   # Check if assembler supports CET.
>diff --git a/libbacktrace/configure b/libbacktrace/configure
>index 95d06c60be1..d851e807d2d 100755
>--- a/libbacktrace/configure
>+++ b/libbacktrace/configure
>@@ -12169,6 +12169,8 @@ case "$host" in
>   auto)
>   # Check if target supports multi-byte NOPs
>   # and if assembler supports CET insn.
>+  save_CFLAGS="$CFLAGS"
>+  CFLAGS="$CFLAGS -fcf-protection"
>   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> /* end confdefs.h.  */
> 
>@@ -12192,6 +12194,7 @@ else
>   enable_cet=no
> fi
> rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
>+  CFLAGS="$save_CFLAGS"
>   ;;
>   yes)
>   # Check if assembler supports CET.
>diff --git a/libgcc/configure b/libgcc/configure
>index a5d5ab84607..5d0c79bcd75 100755
>--- a/libgcc/configure
>+++ b/libgcc/configure
>@@ -4913,6 +4913,8 @@ case "$host" in
>   auto)
>   # Check if target supports multi-byte NOPs
>   # and if assembler supports CET insn.
>+  save_CFLAGS="$CFLAGS"
>+  CFLAGS="$CFLAGS -fcf-protection"
>   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> /* end confdefs.h.  */
> 
>@@ -4936,6 +4938,7 @@ else
>   enable_cet=no
> fi
> rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
>+  CFLAGS="$save_CFLAGS"
>   ;;
>   yes)
>   # Check if assembler supports CET.
>diff --git a/libgfortran/configure b/libgfortran/configure
>index 3c8be061ede..97d9616e425 100755
>--- a/libgfortran/configure
>+++ b/libgfortran/configure
>@@ -6014,6 +6014,8 @@ case "$host" in
>   auto)
>   # Check if target supports multi-byte NOPs
>   # and if 

Re: New mklog script

[Martin Liška]

On 5/15/20 3:22 PM, Marek Polacek wrote:

On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:

On 5/15/20 2:42 PM, Marek Polacek wrote:

I actually use mklog -i all the time.  But I can work around it if it
disappears.


Ah, I can see a consumer.
There's an updated version that supports that.

For the future, will you still use the option? Wouldn't be better
to put the ChangeLog content directly to commit message? Note
that you won't have to copy the entries to a particular ChangeLog file.


The way I do it is to generate a patch using format-patch, use mklog -i
on it, then add the ChangeLog entry to the commit message via commit --amend.


Hmm, you can do much better with:

$ git diff | ./contrib/mklog > changelog && git commit -a -t changelog

Or for an already created commit you can do:

$ git diff HEAD~ | ./contrib/mklog > changelog && git commit -a --amend -e -F 
changelog

That said, I believe usage of -i is legacy.

Martin



Anything that has to do with ChangeLogs is pointless make-work, so the less
I have to do, the better.  ;-)

Marek

Re: [PATCH] Optimize store_expr from STRING_CST [PR95052]

[Jeff Law via Gcc-patches]

On Thu, 2020-05-14 at 18:51 +0200, Jakub Jelinek wrote:
> On Thu, May 14, 2020 at 10:10:55AM -0600, Jeff Law wrote:
> > On Tue, 2020-05-12 at 10:12 +0200, Jakub Jelinek wrote:
> > > Hi!
> > > 
> > > In the following testcase, store_expr of e.g. 97 bytes long string literal
> > > into 1MB long array is implemented by copying the 97 bytes from .rodata
> > > section, followed by clearing the remaining bytes.  But, as the STRING_CST
> > > has type char[1024*1024], we actually allocate whole 1MB in .rodata 
> > > section
> > > for it, even when we only use the first 97 bytes from that.
> > > 
> > > The following patch tweaks it so that if we are going to initialize only
> > > the
> > > small part from it, we don't emit all the zeros that we never use after 
> > > it.
> > > 
> > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > > 
> > > 2020-05-12  Jakub Jelinek  
> > > 
> > >   PR middle-end/95052
> > >   * expr.c (store_expr): If expr_size is constant and significantly
> > >   larger than TREE_STRING_LENGTH, set temp to just the
> > >   TREE_STRING_LENGTH portion of the STRING_CST.
> > > 
> > >   * gcc.target/i386/pr95052.c: New test.
> > OK.  Initially I had a number of concerns, but this only affects the .rodata
> > that's used to initialize the real object.  The .rodata bits have no other
> > purpose and aren't otherwise accessable.
> 
> I wasn't sure if it wouldn't be safer to add some bool flag set to true by
> the new code and then add gcc_assert in all the other paths, like following
> incremental patch.  I believe none of the asserts can trigger right now,
> but the code is still adjusting what it plans to use as source before actually
> only copying fewer bytes from it, so if somebody changes it later...
> 
> Thoughts on that?
Can't hurt, and debugging the assert tripping is likely a hell of a lot easier
than debugging the resultant incorrect code.   So if it passes, then I'd say go
for it.

jeff
> 

Re: [PATCH] tree-optimization: Fix use of uninitialized variables warnings [PR94952]

[Jeff Law via Gcc-patches]

On Tue, 2020-05-05 at 20:16 +0200, Stefan Schulze Frielinghaus via Gcc-patches
wrote:
> While bootstrapping GCC on S/390 with --enable-checking=release several
> warnings about use of uninitialized variables bitpos, bitregion_start, and
> bitregion_end of function pass_store_merging::process_store are raised.
> According to PR94952 these seem to be false positives which are silenced by
> initialising the mentioned variables.
> 
> Bootstrapped on S/390.  Ok for master and releases/gcc-10 assuming that
> regtest succeeds (still running but I don't see a reason why it
> should fail)?
> 
> gcc/ChangeLog:
> 
> 2020-05-05  Stefan Schulze Frielinghaus  
> 
>   PR tree-optimization/94952
>   * gimple-ssa-store-merging.c (pass_store_merging::process_store):
>   Initialize variables bitpos, bitregion_start, and bitregion_end in
>   order to silence warnings about use of uninitialized variables.
OK, including into release branches as appropriate.

jeff
> 

[PATCH] TESTSUITE: Fix tests for 16-bit targets

[Jozef Lawrynowicz]

The attached patch fixes many GCC and G++ tests for 16-bit targets. These
targets can have the following properties:
- "int", "size_t", "ptrdiff_t", "void *" are 16-bit types
- sizeof(int) == sizeof(short)

These properties cause problems for a number of tests in the testsuite,
where int is often assumed to be a 32-bit type (and the test relies on that
property to run as expected or to not generate any unexpected warnings).
Other failures occur when arrays larger than what is supported for 16-bit
targets are declared, or the "short" type is expected to be smaller than "int".

The fixes fall into a few different categories:
- Explicitly defining a 32-bit int type and using that in place of "int" or
  "unsigned int".
- Skipping tests which rely on arrays sized larger than what is supported by the
  target.
- Adding or adjusting dg-{warning,error} directives
- Other testcase specific adjustments.

I've successfully regtested the patch on x86_64-pc-linux-gnu and msp430-elf in
the default, -mlarge and -mcpu=msp430 configurations.

There are no absolute changes to testresults on x86_64-pc-linux-gnu, but because
of changes to the line number of dg-{warning,message,error,etc} directives, the
results comparison shows:
UNTESTED->FAIL: 8 tests
UNTESTED->PASS: 986 tests
PASS->UNTESTED: 986 tests
FAIL->UNTESTED: 8 tests

Across the 3 configurations for msp430, the total is:
PASS->FAIL: 0 tests
FAIL->PASS: 1108 tests
UNTESTED->FAIL: 24 tests
UNTESTED->PASS: 2924 tests
FAIL->UNTESTED: 807 tests
PASS->UNTESTED: 2564 tests

Ok for trunk?

What about for gcc-10 branch? It would be nice to clean up the testresults for
MSP430, but I understand if it is undesirable to cause these line number changes
to appear on the stable branch.

Jozef
>From 7696941c75cf7d0cfbfb25dfd9c239e28314f570 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Tue, 12 May 2020 14:27:41 +0100
Subject: [PATCH] TESTSUITE: Fix tests for 16-bit targets

gcc/ChangeLog:

2020-05-15  Jozef Lawrynowicz  

* doc/sourcebuild.texi: Document new short_eq_int, ptr_eq_short,
ptr_eq_int, msp430_large_memory_model and size24plus DejaGNU effective
targets.
Improve grammar in descriptions for size20plus and size32plus effective
targets.

gcc/testsuite/ChangeLog:

2020-05-15  Jozef Lawrynowicz  

* c-c++-common/builtin-has-attribute-7.c: Require size24plus.
* c-c++-common/cpp/pr63831-1.c: Store result in _has_cpp_attribute in a
long.
* c-c++-common/pr81376.c: Skip scan-tree-dump for short_eq_int. Extend
test for short_eq_int.
* g++.dg/abi/scoped1.C: Skip dg-warning tests for short_eq_int.
* g++.dg/cpp0x/constexpr-70001-1.C: Require size24plus.
* g++.dg/cpp0x/constexpr-bitfield3.C: Require int32plus.
* g++.dg/cpp0x/enum13.C: Skip dg-warning for short_eq_int.
* g++.dg/cpp0x/initlist5.C: Add dg-error for short_eq_int.
* g++.dg/cpp0x/initlist7.C: Add dg-warning for !int32plus.
* g++.dg/cpp0x/nullptr04.C: Skip dg-error for ptr_eq_short.
* g++.dg/cpp0x/variadic-value1.C: Add typedef for int32_t.
* g++.dg/cpp1y/constexpr-arith-overflow.C: Fix test for
sizeof(int) == sizeof(short).
* g++.dg/cpp1y/digit-sep-neg.C: Add typedef for int32_t.
* g++.dg/cpp1y/pr57644.C: Add typedef for uint32_t.
* g++.dg/cpp1y/pr77321.C: Require size24plus.
* g++.dg/cpp1y/var-templ4.C: Add typedef for int32_t.
* g++.dg/cpp1z/direct-enum-init1.C: Skip dg-error for short_eq_int.
* g++.dg/delayedfold/fwrapv1.C: Skip for int16.
* g++.dg/expr/bitfield9.C: Add typedef for int32_t.
* g++.dg/ext/attribute-test-1.C: Add typedef for uint32_t.
* g++.dg/ext/bitfield1.C: Add typedef for int32_t.
* g++.dg/ext/flexary13.C: Add typedef for int32_t.
* g++.dg/ext/utf-cvt.C: Adjust dg-warning for int16.
* g++.dg/ext/vector28.C: Add typedef for int32_t.
* g++.dg/ext/vla15.C: Add typedef for int32_t.
* g++.dg/init/array11.C: Require size32plus.
* g++.dg/init/array15.C: Require size24plus.
* g++.dg/init/array4.C: Require size20plus.
* g++.dg/init/const7.C: Skip dg-message for ptr_eq_int.
* g++.dg/init/new38.C: Relax regex in dg-error.
* g++.dg/init/new44.C: Skip dg-error for when ptr_eq_int.
Adjust test for 16-bit size_t.
Add special case for msp430 -mlarge.
* g++.dg/init/value9.C: Add typedef for int32_t.
* g++.dg/ipa/pr77333.C: Add typedef for int32_t.
* g++.dg/lto/20080908-1_0.C: Add typedef for int32_t.
* g++.dg/opt/pr55717.C: Add typedef for uint32_t.
* g++.dg/opt/pr60597.C: Add typedef for int32_t.
* g++.dg/opt/pr81715.C: Require size20plus.
* g++.dg/opt/reload3.C: Add typedef for uint32_t.
* g++.dg/opt/temp2.C: Require size20plus.
* g++.dg/opt/thunk1.C: Likewise.
* g++.dg/other/error23.C: Dont assume __SIZEOF_INT_

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Jason Merrill via Gcc-patches]

On Fri, May 15, 2020 at 3:15 AM Richard Biener 
wrote:

> > +# When bootstrapping with GCC, build stage 1 in C++11 mode to ensure
> that a
> > +# C++11 compiler can still start the bootstrap.
> >  if test "$enable_bootstrap:$GXX" = "yes:yes"; then
> > +  CXX="$CXX -std=gnu++11"
>
> So I just spotted this - since we're requiring a ISO C++11 compiler
> shouldn't
> we build stage1 with -std=c++11 rather than gnu++11 (whatever the detailed
> differences are here)?  Also not sure what level of -pedantic we'd need to
> avoid GNU extensions even with -std=c++11.  Of course there are (I hope)
> a lot less GNU extensions for C++ than there were for C and hopefully
> no extra in gnu++11 compared to gnu++98 which we checked previously.
>

When we first moved to C++ I tried using -std=c++98, but there were too
many places where we were assuming that if we're building with GCC, we can
use GNU C extensions.

I'll see if that's still a problem for -std=c++11.

Note I think what's missing is some general blurb in our coding conventions
> as to how much of C++11 we are supposed to use in non-infrastructure parts
> of GCC (I expect things like hash-table.h to use more C++ features than,
> say, tree-ssa-alias.c).
>
> There also does not seem to be a configure check which may present
> users with a more useful error message than later cryptic fail of build?
> I suppose we cannot simply check __cplusplus for this, can we?  Do
> other common host compilers need additional options to enable C++11?
>

Good point, I'll add that.


> Should we try to second guess such flags via configury?  For example
> GCC 4.8 defaults to -std=gnu++98 and the above only seems to apply
> to the bootstrap case so GCC 4.8 cannot be used to build cross compilers
> without adjusting CC and CXX?
>

Older GCC is still GCC and will get the flag automatically.

Jason

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Jason Merrill via Gcc-patches]

On Fri, May 15, 2020 at 5:58 AM Richard Sandiford 
wrote:

> Richard Biener  writes:
> > On Fri, May 15, 2020 at 10:30 AM Richard Sandiford
> >  wrote:
> >>
> >> Richard Biener via Gcc-patches  writes:
> >> > Note I think what's missing is some general blurb in our coding
> conventions
> >> > as to how much of C++11 we are supposed to use in non-infrastructure
> parts
> >> > of GCC (I expect things like hash-table.h to use more C++ features
> than,
> >> > say, tree-ssa-alias.c).
> >>
> >> I guess there are two aspects to that:
> >>
> >> - Are there any specific features we should avoid using at all?
> >>   TBH I hope not.  Trying to police this based on C++ feature sounds
> >>   difficulty and might be counterproductive.
> >>
> >>   IMO it should just (continue to) be based on principles like avoiding
> >>   abstraction for abstraction's sake, and keeping compiler performance
> >>   and code size in mind.  Even tree-ssa-alias.c should be able to use
> >>   any C++ feature if there's a justification.
> >>
> >> - Coding conventions for when features should be used.  "auto" is an
> >>   obvious one.  Maybe also lambdas (which should help avoid the horrible
> >>   "void *" callback parameters we have all over the place now).
> >>
> >> Maybe also guidelines to actively use certain features, e.g.
> >>
> >> - use "= default" where possible
> >>
> >> - prefer range-based for loops to macros
> >>
> >> - mark "operator bool()" conversions as explicit
> >>
> >> - use "override" where applicable
> >>
> >> (all obvious I guess), etc.
> >
> > I think the most important thing is that refactoring for the sake
> > of refactoring is bad iff it does not improve on consistency
> > throughout the code base.  We should really try hard to use
> > C++ features consistently - this makes the code base easier
> > to understand.
>
> Agreed.  One of the reasons I'm keen to have something in the
> coding standards is that things became less consistent after
> the C->C++ switch.
>
> Maybe we should reconsider some of the existing coding standards too.
> E.g.:
>
>   Define all members outside the class definition.
>   That is, there are no function bodies or member initializers
>   inside the class definition.
>
> isn't widely followed.  That's a bit of a tangent though.
> (FTR, I've no attachment to the current conventions and didn't
> contribute anything to them.  More consistency would be good though.)
>
> > We've moved more and more to stronly-typed data structures
> > so I'd not like to see 'auto' everywhere - it should be still
> > obvious what kind of objects we're working with where they
> > matter.  IMHO they do not matter for example for iterators.
> > I don't care about the iterator type but about the type of
> > the object and the container.
>
> Also agreed. :-)  How about this as a starting point:
>
> ---
> Use auto for:
>
> - the result of casts or other expressions that give the type
>   explicitly.  E.g.:
>
> if (auto *table = dyn_cast  (insn))
>
>   instead of:
>
> if (rtx_jump_table_data *table = dyn_cast 
> (insn))
>
> - iterator types.  E.g.:
>
> auto it = foo.begin ();
>
>   instead of:
>
> foo_type::iterator it = foo.begin ();
>
> - expressions that provide an alternative view of something,
>   when the expression is bound to a read-only temporary.  E.g.:
>
> auto val1 = wi::to_wide (...);
> auto val2 = wi::uhwi (12, 16);
>
>   instead of:
>
> wide_int val1 = wi::to_wide (...);
> wide_int val2 = wi::uhwi (12, 16);
>
>   (Using "wide_int" is less efficient than using the natural type of
>   the expression.)
>
> - the type of a lambda expression.  E.g.:
>
> auto f = [] (int x) { return x + 1; };
>
> Do not use auto otherwise.
>

We probably also want to use auto for local variables in templates where
the initializer is type-dependent.

Jason

[pushed] PR c++/93286 - ICE with __is_constructible and variadic template.

[Jason Merrill via Gcc-patches]

My GCC 10 patch for 93286 fixed the missing piece in tsubst's handling of
lists vs. that in tsubst_copy_and_build, but it would be better to share the
code between them.

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

gcc/cp/ChangeLog
2020-05-15  Jason Merrill  

PR c++/93286 - ICE with __is_constructible and variadic template.
* pt.c (tsubst_tree_list): New.
(tsubst, tsubst_copy_and_build): Use it.
* decl2.c (is_late_template_attribute): Handle error_mark_node args.
---
 gcc/cp/cp-tree.h |   2 +-
 gcc/cp/decl2.c   |   3 +
 gcc/cp/pt.c  | 272 ---
 3 files changed, 94 insertions(+), 183 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 827b03dd5d5..3f7ded4798f 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6953,7 +6953,7 @@ extern tree tsubst_default_argument   (tree, 
int, tree, tree,
 tsubst_flags_t);
 extern tree tsubst (tree, tree, tsubst_flags_t, tree);
 extern tree tsubst_copy_and_build  (tree, tree, tsubst_flags_t,
-tree, bool, bool);
+tree, bool = false, bool = 
false);
 extern tree tsubst_expr (tree, tree, tsubst_flags_t,
  tree, bool);
 extern tree tsubst_pack_expansion  (tree, tree, tsubst_flags_t, 
tree);
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 4767d53adef..449c86c66c9 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -1173,6 +1173,9 @@ is_late_template_attribute (tree attr, tree decl)
   && is_attribute_p ("omp declare simd", name))
 return true;
 
+  if (args == error_mark_node)
+return false;
+
   /* An attribute pack is clearly dependent.  */
   if (args && PACK_EXPANSION_P (args))
 return true;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index bfeeebc2b38..cad5b217f3c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -15044,6 +15044,94 @@ tsubst_exception_specification (tree fntype,
   return new_specs;
 }
 
+/* Substitute through a TREE_LIST of types or expressions, handling pack
+   expansions.  */
+
+tree
+tsubst_tree_list (tree t, tree args, tsubst_flags_t complain, tree in_decl)
+{
+  if (t == void_list_node)
+return t;
+
+  tree purpose = TREE_PURPOSE (t);
+  tree purposevec = NULL_TREE;
+  if (!purpose)
+;
+  else if (PACK_EXPANSION_P (purpose))
+{
+  purpose = tsubst_pack_expansion (purpose, args, complain, in_decl);
+  if (TREE_CODE (purpose) == TREE_VEC)
+   purposevec = purpose;
+}
+  else if (TYPE_P (purpose))
+purpose = tsubst (purpose, args, complain, in_decl);
+  else
+purpose = tsubst_copy_and_build (purpose, args, complain, in_decl);
+  if (purpose == error_mark_node || purposevec == error_mark_node)
+return error_mark_node;
+
+  tree value = TREE_VALUE (t);
+  tree valuevec = NULL_TREE;
+  if (!value)
+;
+  else if (PACK_EXPANSION_P (value))
+{
+  value = tsubst_pack_expansion (value, args, complain, in_decl);
+  if (TREE_CODE (value) == TREE_VEC)
+   valuevec = value;
+}
+  else if (TYPE_P (value))
+value = tsubst (value, args, complain, in_decl);
+  else
+value = tsubst_copy_and_build (value, args, complain, in_decl);
+  if (value == error_mark_node || valuevec == error_mark_node)
+return error_mark_node;
+
+  tree chain = TREE_CHAIN (t);
+  if (!chain)
+;
+  else if (TREE_CODE (chain) == TREE_LIST)
+chain = tsubst_tree_list (chain, args, complain, in_decl);
+  else if (TYPE_P (chain))
+chain = tsubst (chain, args, complain, in_decl);
+  else
+chain = tsubst_copy_and_build (chain, args, complain, in_decl);
+  if (chain == error_mark_node)
+return error_mark_node;
+
+  if (purpose == TREE_PURPOSE (t)
+  && value == TREE_VALUE (t)
+  && chain == TREE_CHAIN (t))
+return t;
+
+  int len;
+  /* Determine the number of arguments.  */
+  if (purposevec)
+{
+  len = TREE_VEC_LENGTH (purposevec);
+  gcc_assert (!valuevec || len == TREE_VEC_LENGTH (valuevec));
+}
+  else if (valuevec)
+len = TREE_VEC_LENGTH (valuevec);
+  else
+len = 1;
+
+  for (int i = len; i-- > 0; )
+{
+  if (purposevec)
+   purpose = TREE_VEC_ELT (purposevec, i);
+  if (valuevec)
+   value = TREE_VEC_ELT (valuevec, i);
+
+  if (value && TYPE_P (value))
+   chain = hash_tree_cons (purpose, value, chain);
+  else
+   chain = tree_cons (purpose, value, chain);
+}
+
+  return chain;
+}
+
 /* Take the tree structure T and replace template parameters used
therein with the argument vector ARGS.  IN_DECL is an associated
decl for diagnostics.  If an error occurs, returns ERROR_MARK_NODE.
@@ -15463,104 +15551,7 @@ tsubst (tree t, tree args, tsubst_flags_t complain, 
tree in_decl)
   }
 
 case TREE_LIST:
-  {
-   tree purpose, value, chain;
-
-   i

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Richard Biener via Gcc-patches]

On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill  wrote:
>On Fri, May 15, 2020 at 3:15 AM Richard Biener
>
>wrote:
>
>> > +# When bootstrapping with GCC, build stage 1 in C++11 mode to
>ensure
>> that a
>> > +# C++11 compiler can still start the bootstrap.
>> >  if test "$enable_bootstrap:$GXX" = "yes:yes"; then
>> > +  CXX="$CXX -std=gnu++11"
>>
>> So I just spotted this - since we're requiring a ISO C++11 compiler
>> shouldn't
>> we build stage1 with -std=c++11 rather than gnu++11 (whatever the
>detailed
>> differences are here)?  Also not sure what level of -pedantic we'd
>need to
>> avoid GNU extensions even with -std=c++11.  Of course there are (I
>hope)
>> a lot less GNU extensions for C++ than there were for C and hopefully
>> no extra in gnu++11 compared to gnu++98 which we checked previously.
>>
>
>When we first moved to C++ I tried using -std=c++98, but there were too
>many places where we were assuming that if we're building with GCC, we
>can
>use GNU C extensions.
>
>I'll see if that's still a problem for -std=c++11.
>
>Note I think what's missing is some general blurb in our coding
>conventions
>> as to how much of C++11 we are supposed to use in non-infrastructure
>parts
>> of GCC (I expect things like hash-table.h to use more C++ features
>than,
>> say, tree-ssa-alias.c).
>>
>> There also does not seem to be a configure check which may present
>> users with a more useful error message than later cryptic fail of
>build?
>> I suppose we cannot simply check __cplusplus for this, can we?  Do
>> other common host compilers need additional options to enable C++11?
>>
>
>Good point, I'll add that.
>
>
>> Should we try to second guess such flags via configury?  For example
>> GCC 4.8 defaults to -std=gnu++98 and the above only seems to apply
>> to the bootstrap case so GCC 4.8 cannot be used to build cross
>compilers
>> without adjusting CC and CXX?
>>
>
>Older GCC is still GCC and will get the flag automatically.

But yes:yes suggests that when building a cross compiler this doesn't apply? 

Richard. 

>Jason

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

[Patrick Palka via Gcc-patches]

On Wed, 15 Apr 2020, Patrick Palka wrote:
> On Wed, 15 Apr 2020, Martin Sebor via Gcc-patches wrote:
> > On 4/13/20 8:43 PM, Jason Merrill wrote:
> > > On 4/12/20 5:49 PM, Martin Sebor wrote:
> > > > On 4/10/20 8:52 AM, Jason Merrill wrote:
> > > > > On 4/9/20 4:23 PM, Martin Sebor wrote:
> > > > > > On 4/9/20 1:32 PM, Jason Merrill wrote:
> > > > > > > On 4/9/20 3:24 PM, Martin Sebor wrote:
> > > > > > > > On 4/9/20 1:03 PM, Jason Merrill wrote:
> > > > > > > > > On 4/8/20 1:23 PM, Martin Sebor wrote:
> > > > > > > > > > On 4/7/20 3:36 PM, Marek Polacek wrote:
> > > > > > > > > > > On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On 4/7/20 1:50 PM, Marek Polacek wrote:
> > > > > > > > > > > > > On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor
> > > > > > > > > > > > > via Gcc-patches wrote:
> > > > > > > > > > > > > > Among the numerous regressions introduced by the
> > > > > > > > > > > > > > change committed
> > > > > > > > > > > > > > to GCC 9 to allow string literals as template
> > > > > > > > > > > > > > arguments is a failure
> > > > > > > > > > > > > > to recognize the C++ nullptr and GCC's __null
> > > > > > > > > > > > > > constants as pointers.
> > > > > > > > > > > > > > For one, I didn't realize that nullptr, being a null
> > > > > > > > > > > > > > pointer constant,
> > > > > > > > > > > > > > doesn't have a pointer type, and two, I didn't think
> > > > > > > > > > > > > > of __null (which
> > > > > > > > > > > > > > is a special integer constant that NULL sometimes
> > > > > > > > > > > > > > expands to).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The attached patch adjusts the special handling of
> > > > > > > > > > > > > > trailing zero
> > > > > > > > > > > > > > initializers in reshape_init_array_1 to recognize 
> > > > > > > > > > > > > > both
> > > > > > > > > > > > > > kinds of
> > > > > > > > > > > > > > constants and avoid treating them as zeros of the
> > > > > > > > > > > > > > array integer
> > > > > > > > > > > > > > element type.  This restores the expected 
> > > > > > > > > > > > > > diagnostics
> > > > > > > > > > > > > > when either
> > > > > > > > > > > > > > constant is used in the initializer list.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Martin
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > PR c++/94510 - nullptr_t implicitly cast to zero 
> > > > > > > > > > > > > > twice
> > > > > > > > > > > > > > in std::array
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > gcc/cp/ChangeLog:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > PR c++/94510
> > > > > > > > > > > > > > * decl.c (reshape_init_array_1): Exclude
> > > > > > > > > > > > > > mismatches with all kinds
> > > > > > > > > > > > > > of pointers.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > gcc/testsuite/ChangeLog:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > PR c++/94510
> > > > > > > > > > > > > > * g++.dg/init/array57.C: New test.
> > > > > > > > > > > > > > * g++.dg/init/array58.C: New test.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> > > > > > > > > > > > > > index a127734af69..692c8ed73f4 100644
> > > > > > > > > > > > > > --- a/gcc/cp/decl.c
> > > > > > > > > > > > > > +++ b/gcc/cp/decl.c
> > > > > > > > > > > > > > @@ -6041,9 +6041,14 @@ reshape_init_array_1 (tree
> > > > > > > > > > > > > > elt_type, tree max_index, reshape_iter *d,
> > > > > > > > > > > > > >    TREE_CONSTANT (new_init) = false;
> > > > > > > > > > > > > >  /* Pointers initialized to strings must be
> > > > > > > > > > > > > > treated as non-zero
> > > > > > > > > > > > > > - even if the string is empty.  */
> > > > > > > > > > > > > > + even if the string is empty.  Handle all kinds
> > > > > > > > > > > > > > of pointers,
> > > > > > > > > > > > > > + including std::nullptr and GCC's __nullptr,
> > > > > > > > > > > > > > neither of which
> > > > > > > > > > > > > > + has a pointer type.  */
> > > > > > > > > > > > > >  tree init_type = TREE_TYPE (elt_init);
> > > > > > > > > > > > > > -  if (POINTER_TYPE_P (elt_type) != 
> > > > > > > > > > > > > > POINTER_TYPE_P
> > > > > > > > > > > > > > (init_type)
> > > > > > > > > > > > > > +  bool init_is_ptr = (POINTER_TYPE_P 
> > > > > > > > > > > > > > (init_type)
> > > > > > > > > > > > > > +  || NULLPTR_TYPE_P (init_type)
> > > > > > > > > > > > > > +  || null_node_p (elt_init));
> > > > > > > > > > > > > > +  if (POINTER_TYPE_P (elt_type) != init_is_ptr
> > > > > > > > > > > > > >  || !type_initializer_zero_p (elt_type,
> > > > > > > > > > > > > > elt_init))
> > > > > > > > > > > > > >    last_nonzero = index;
> > > > > > > > > > > > > 
> > > > > > > > > > > > > It looks like this still won't handle e.g. pointers to
> > > > > > > > > > > > > member functions,
> > > > > > > > > > > > > 

Re: [PATCH] TESTSUITE: Fix tests for 16-bit targets

[Jeff Law via Gcc-patches]

On Fri, 2020-05-15 at 18:26 +0100, Jozef Lawrynowicz wrote:
> The attached patch fixes many GCC and G++ tests for 16-bit targets. These
> targets can have the following properties:
> - "int", "size_t", "ptrdiff_t", "void *" are 16-bit types
> - sizeof(int) == sizeof(short)
> 
> These properties cause problems for a number of tests in the testsuite,
> where int is often assumed to be a 32-bit type (and the test relies on that
> property to run as expected or to not generate any unexpected warnings).
> Other failures occur when arrays larger than what is supported for 16-bit
> targets are declared, or the "short" type is expected to be smaller than 
> "int".
> 
> The fixes fall into a few different categories:
> - Explicitly defining a 32-bit int type and using that in place of "int" or
>   "unsigned int".
> - Skipping tests which rely on arrays sized larger than what is supported by
> the
>   target.
> - Adding or adjusting dg-{warning,error} directives
> - Other testcase specific adjustments.
> 
> I've successfully regtested the patch on x86_64-pc-linux-gnu and msp430-elf in
> the default, -mlarge and -mcpu=msp430 configurations.
> 
> There are no absolute changes to testresults on x86_64-pc-linux-gnu, but
> because
> of changes to the line number of dg-{warning,message,error,etc} directives, 
> the
> results comparison shows:
> UNTESTED->FAIL: 8 tests
> UNTESTED->PASS: 986 tests
> PASS->UNTESTED: 986 tests
> FAIL->UNTESTED: 8 tests
> 
> Across the 3 configurations for msp430, the total is:
> PASS->FAIL: 0 tests
> FAIL->PASS: 1108 tests
> UNTESTED->FAIL: 24 tests
> UNTESTED->PASS: 2924 tests
> FAIL->UNTESTED: 807 tests
> PASS->UNTESTED: 2564 tests
> 
> Ok for trunk?
> 
> What about for gcc-10 branch? It would be nice to clean up the testresults for
> MSP430, but I understand if it is undesirable to cause these line number
> changes
> to appear on the stable branch.
OK for the trunk.  I suspect the release managers wouldn't want it for the 
branch
though.  

jeff

[PATCH 4/5] rs6000/testsuite: Use the int128 selector where needed

[Segher Boessenkool]

Tests that use the __int128 type need to use the int128 selector.

2020-05-15  Segher Boessenkool  

gcc/testsuite/
* gcc.target/powerpc/vec-gnb-0.c: Use int128 effective target.
* gcc.target/powerpc/vec-gnb-1.c: Ditto.
* gcc.target/powerpc/vec-gnb-2.c: Ditto.
* gcc.target/powerpc/vec-ternarylogic-8.c: Ditto.
* gcc.target/powerpc/vec-ternarylogic-9.c: Ditto.
* gcc.target/powerpc/vec-ternarylogic-10.c: Ditto.
---
 gcc/testsuite/gcc.target/powerpc/vec-gnb-0.c   | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-gnb-1.c   | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-gnb-2.c   | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-10.c | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-8.c  | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-9.c  | 1 +
 6 files changed, 6 insertions(+)

diff --git a/gcc/testsuite/gcc.target/powerpc/vec-gnb-0.c 
b/gcc/testsuite/gcc.target/powerpc/vec-gnb-0.c
index f18bb16..e4c31eb 100644
--- a/gcc/testsuite/gcc.target/powerpc/vec-gnb-0.c
+++ b/gcc/testsuite/gcc.target/powerpc/vec-gnb-0.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/powerpc/vec-gnb-1.c 
b/gcc/testsuite/gcc.target/powerpc/vec-gnb-1.c
index ee9c44f..88b509f 100644
--- a/gcc/testsuite/gcc.target/powerpc/vec-gnb-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/vec-gnb-1.c
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target powerpc_future_hw } */
+/* { dg-require-effective-target int128 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/powerpc/vec-gnb-2.c 
b/gcc/testsuite/gcc.target/powerpc/vec-gnb-2.c
index 591f701..89e63c8 100644
--- a/gcc/testsuite/gcc.target/powerpc/vec-gnb-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/vec-gnb-2.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-10.c 
b/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-10.c
index 868fb23..d8aaebb 100644
--- a/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-10.c
+++ b/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-10.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-8.c 
b/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-8.c
index 0d6b9e7..fc13e77 100644
--- a/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-8.c
+++ b/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-8.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 #include 
diff --git a/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-9.c 
b/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-9.c
index b611359..65562ce 100644
--- a/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-9.c
+++ b/gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-9.c
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target powerpc_future_hw } */
+/* { dg-require-effective-target int128 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 #include 
-- 
1.8.3.1

[PATCH 3/5] rs6000/testsuite: Use lp64 in cnttzdm-0.c

[Segher Boessenkool]

2020-05-15  Segher Boessenkool  

gcc/testsuite/
* gcc.target/powerpc/cnttzdm-0.c: Use lp64.
---
 gcc/testsuite/gcc.target/powerpc/cnttzdm-0.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.target/powerpc/cnttzdm-0.c 
b/gcc/testsuite/gcc.target/powerpc/cnttzdm-0.c
index 36acc0b..0b434be 100644
--- a/gcc/testsuite/gcc.target/powerpc/cnttzdm-0.c
+++ b/gcc/testsuite/gcc.target/powerpc/cnttzdm-0.c
@@ -1,3 +1,4 @@
+/* { dg-require-effective-target lp64 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
-- 
1.8.3.1

[PATCH 0/5] rs6000: Fixes for Future, mostly testsuite

[Segher Boessenkool]

Some fixes for -mcpu=future, mostly testsuite.  This also cleans up
some other testsuite problems.

Tested on powerpc64-linux {-m32,-m64}; committing to trunk.  This
hopefully cleans up some of the AIX problems here as well.


Segher


Segher Boessenkool (5):
  rs6000/testsuite: Use -mdejagnu-cpu= instead of -mcpu=
  rs6000/testsuite: Don't use powerpc64 effective target
  rs6000/testsuite: Use lp64 in cnttzdm-0.c
  rs6000/testsuite: Use the int128 selector where needed
  rs6000: BU_FUTURE_MISC_2 requires powerpc64

 gcc/config/rs6000/rs6000-builtin.def   | 3 ++-
 gcc/testsuite/gcc.target/powerpc/cntlzdm-0.c   | 2 +-
 gcc/testsuite/gcc.target/powerpc/cntlzdm-1.c   | 2 +-
 gcc/testsuite/gcc.target/powerpc/cnttzdm-0.c   | 1 +
 gcc/testsuite/gcc.target/powerpc/cnttzdm-1.c   | 2 +-
 gcc/testsuite/gcc.target/powerpc/pdep-0.c  | 4 ++--
 gcc/testsuite/gcc.target/powerpc/pdep-1.c  | 4 ++--
 gcc/testsuite/gcc.target/powerpc/pextd-0.c | 4 ++--
 gcc/testsuite/gcc.target/powerpc/pextd-1.c | 4 ++--
 gcc/testsuite/gcc.target/powerpc/pr90763.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr91275.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr92796.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr93658.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr93800.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbceq.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbcge.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbcgt.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbcle.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbclt.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbcne.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbceq.c| 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbcge.c| 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbcgt.c| 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbcle.c| 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbclt.c| 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbcne.c| 2 +-
 gcc/testsuite/gcc.target/powerpc/vec-gnb-0.c   | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-gnb-1.c   | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-gnb-2.c   | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-10.c | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-8.c  | 1 +
 gcc/testsuite/gcc.target/powerpc/vec-ternarylogic-9.c  | 1 +
 gcc/testsuite/gcc.target/powerpc/xxgenpc-runnable.c| 2 +-
 33 files changed, 38 insertions(+), 30 deletions(-)

-- 
1.8.3.1

[PATCH 2/5] rs6000/testsuite: Don't use powerpc64 effective target

[Segher Boessenkool]

The powerpc64 effective target unfortunately does not mean the target
has 64-bit instructions enabled (i.e., -mpowerpc64): instead, it means
that the assembler supports it.

Let's use the lp64 effective target instead for these tests.

2020-05-15  Segher Boessenkool  

gcc/testsuite/
* gcc.target/powerpc/cntlzdm-0.c: Use lp64 instead of powerpc64.
* gcc.target/powerpc/cntlzdm-1.c: Ditto.
* gcc.target/powerpc/cnttzdm-1.c: Ditto.
* gcc.target/powerpc/pdep-0.c: Ditto.
* gcc.target/powerpc/pdep-1.c: Ditto.
* gcc.target/powerpc/pextd-0.c: Ditto.
* gcc.target/powerpc/pextd-1.c: Ditto.
---
 gcc/testsuite/gcc.target/powerpc/cntlzdm-0.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/cntlzdm-1.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/cnttzdm-1.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/pdep-0.c| 2 +-
 gcc/testsuite/gcc.target/powerpc/pdep-1.c| 2 +-
 gcc/testsuite/gcc.target/powerpc/pextd-0.c   | 2 +-
 gcc/testsuite/gcc.target/powerpc/pextd-1.c   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/cntlzdm-0.c 
b/gcc/testsuite/gcc.target/powerpc/cntlzdm-0.c
index 8cdd261..45e7d78 100644
--- a/gcc/testsuite/gcc.target/powerpc/cntlzdm-0.c
+++ b/gcc/testsuite/gcc.target/powerpc/cntlzdm-0.c
@@ -1,4 +1,4 @@
-/* { dg-require-effective-target powerpc64 } */
+/* { dg-require-effective-target lp64 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
diff --git a/gcc/testsuite/gcc.target/powerpc/cntlzdm-1.c 
b/gcc/testsuite/gcc.target/powerpc/cntlzdm-1.c
index d5a087f..3239c38 100644
--- a/gcc/testsuite/gcc.target/powerpc/cntlzdm-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/cntlzdm-1.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target powerpc_future_hw } */
-/* { dg-require-effective-target powerpc64 } */
+/* { dg-require-effective-target lp64 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
diff --git a/gcc/testsuite/gcc.target/powerpc/cnttzdm-1.c 
b/gcc/testsuite/gcc.target/powerpc/cnttzdm-1.c
index cb11976..d04b119 100644
--- a/gcc/testsuite/gcc.target/powerpc/cnttzdm-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/cnttzdm-1.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target powerpc_future_hw } */
-/* { dg-require-effective-target powerpc64 } */
+/* { dg-require-effective-target lp64 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
diff --git a/gcc/testsuite/gcc.target/powerpc/pdep-0.c 
b/gcc/testsuite/gcc.target/powerpc/pdep-0.c
index bdf90dd..b75b2a8 100644
--- a/gcc/testsuite/gcc.target/powerpc/pdep-0.c
+++ b/gcc/testsuite/gcc.target/powerpc/pdep-0.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target powerpc64 } */
+/* { dg-require-effective-target lp64 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
diff --git a/gcc/testsuite/gcc.target/powerpc/pdep-1.c 
b/gcc/testsuite/gcc.target/powerpc/pdep-1.c
index 62eb6b2..e2c7615 100644
--- a/gcc/testsuite/gcc.target/powerpc/pdep-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pdep-1.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target powerpc_future_hw } */
-/* { dg-require-effective-target powerpc64 } */
+/* { dg-require-effective-target lp64 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
diff --git a/gcc/testsuite/gcc.target/powerpc/pextd-0.c 
b/gcc/testsuite/gcc.target/powerpc/pextd-0.c
index 1a8ccad..47a230d 100644
--- a/gcc/testsuite/gcc.target/powerpc/pextd-0.c
+++ b/gcc/testsuite/gcc.target/powerpc/pextd-0.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-require-effective-target powerpc64 } */
+/* { dg-require-effective-target lp64 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
diff --git a/gcc/testsuite/gcc.target/powerpc/pextd-1.c 
b/gcc/testsuite/gcc.target/powerpc/pextd-1.c
index 462af98..004d2dd 100644
--- a/gcc/testsuite/gcc.target/powerpc/pextd-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pextd-1.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target powerpc_future_hw } */
-/* { dg-require-effective-target powerpc64 } */
+/* { dg-require-effective-target lp64 } */
 /* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
-- 
1.8.3.1

[PATCH 1/5] rs6000/testsuite: Use -mdejagnu-cpu= instead of -mcpu=

[Segher Boessenkool]

A bunch of new cases snuck in.

2020-05-15  Segher Boessenkool  

gcc/testsuite/
* gcc.target/powerpc/pdep-0.c: Change -mcpu= to -mdejagnu-cpu=.
* gcc.target/powerpc/pdep-1.c: Ditto.
* gcc.target/powerpc/pextd-0.c: Ditto.
* gcc.target/powerpc/pextd-1.c: Ditto.
* gcc.target/powerpc/pr90763.c: Ditto.
* gcc.target/powerpc/pr91275.c: Ditto.
* gcc.target/powerpc/pr92796.c: Ditto.
* gcc.target/powerpc/pr93658.c: Ditto.
* gcc.target/powerpc/pr93800.c: Ditto.
* gcc.target/powerpc/setbceq.c: Ditto.
* gcc.target/powerpc/setbcge.c: Ditto.
* gcc.target/powerpc/setbcgt.c: Ditto.
* gcc.target/powerpc/setbcle.c: Ditto.
* gcc.target/powerpc/setbclt.c: Ditto.
* gcc.target/powerpc/setbcne.c: Ditto.
* gcc.target/powerpc/setnbceq.c: Ditto.
* gcc.target/powerpc/setnbcge.c: Ditto.
* gcc.target/powerpc/setnbcgt.c: Ditto.
* gcc.target/powerpc/setnbcle.c: Ditto.
* gcc.target/powerpc/setnbclt.c: Ditto.
* gcc.target/powerpc/setnbcne.c: Ditto.
* gcc.target/powerpc/xxgenpc-runnable.c: Ditto.
---
 gcc/testsuite/gcc.target/powerpc/pdep-0.c   | 2 +-
 gcc/testsuite/gcc.target/powerpc/pdep-1.c   | 2 +-
 gcc/testsuite/gcc.target/powerpc/pextd-0.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/pextd-1.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr90763.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr91275.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr92796.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr93658.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/pr93800.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbceq.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbcge.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbcgt.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbcle.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbclt.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/setbcne.c  | 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbceq.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbcge.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbcgt.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbcle.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbclt.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/setnbcne.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/xxgenpc-runnable.c | 2 +-
 22 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/pdep-0.c 
b/gcc/testsuite/gcc.target/powerpc/pdep-0.c
index 5c6afb3..bdf90dd 100644
--- a/gcc/testsuite/gcc.target/powerpc/pdep-0.c
+++ b/gcc/testsuite/gcc.target/powerpc/pdep-0.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target powerpc64 } */
-/* { dg-options "-mcpu=future" } */
+/* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pdep-1.c 
b/gcc/testsuite/gcc.target/powerpc/pdep-1.c
index 40532ee..62eb6b2 100644
--- a/gcc/testsuite/gcc.target/powerpc/pdep-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pdep-1.c
@@ -1,7 +1,7 @@
 /* { dg-do run } */
 /* { dg-require-effective-target powerpc_future_hw } */
 /* { dg-require-effective-target powerpc64 } */
-/* { dg-options "-mcpu=future" } */
+/* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pextd-0.c 
b/gcc/testsuite/gcc.target/powerpc/pextd-0.c
index 23a952d..1a8ccad 100644
--- a/gcc/testsuite/gcc.target/powerpc/pextd-0.c
+++ b/gcc/testsuite/gcc.target/powerpc/pextd-0.c
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-require-effective-target powerpc64 } */
-/* { dg-options "-mcpu=future" } */
+/* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pextd-1.c 
b/gcc/testsuite/gcc.target/powerpc/pextd-1.c
index 814ce43..462af98 100644
--- a/gcc/testsuite/gcc.target/powerpc/pextd-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/pextd-1.c
@@ -1,7 +1,7 @@
 /* { dg-do run } */
 /* { dg-require-effective-target powerpc_future_hw } */
 /* { dg-require-effective-target powerpc64 } */
-/* { dg-options "-mcpu=future" } */
+/* { dg-options "-mdejagnu-cpu=future" } */
 
 extern void abort (void);
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr90763.c 
b/gcc/testsuite/gcc.target/powerpc/pr90763.c
index 55f1d46..33a4621 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr90763.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr90763.c
@@ -1,6 +1,6 @@
 /* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
 /* { dg-require-effective-target powerpc_p9vector_ok } */
-/* { dg-options "-mcpu=power9 -O2" } */
+/* { dg-options "-mdejagnu-cpu=power9 -O2" } */
 
 /* PR90763: PowerPC vec_xl_len should take const.
 */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr91275.c 
b/gcc/testsuite/gcc.target/powerpc/pr91275.c
index bcceec1..39fcd73

[PATCH 5/5] rs6000: BU_FUTURE_MISC_2 requires powerpc64

[Segher Boessenkool]

BU_FUTURE_MISC_2 is (currently) only used for instructions that require
64-bit registers.

2020-05-15  Segher Boessenkool  

* config/rs6000/rs6000-builtin.def (BU_FUTURE_MISC_2): Also require
RS6000_BTM_POWERPC64.
---
 gcc/config/rs6000/rs6000-builtin.def | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index e58edec..8b1ddb0 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -1036,7 +1036,8 @@
 #define BU_FUTURE_MISC_2(ENUM, NAME, ATTR, ICODE)  \
   RS6000_BUILTIN_2 (FUTURE_BUILTIN_ ## ENUM,   /* ENUM */  \
"__builtin_" NAME,  /* NAME */  \
-   RS6000_BTM_FUTURE,  /* MASK */  \
+   RS6000_BTM_FUTURE   \
+   | RS6000_BTM_POWERPC64, /* MASK */  \
(RS6000_BTC_ ## ATTR/* ATTR */  \
 | RS6000_BTC_BINARY),  \
CODE_FOR_ ## ICODE) /* ICODE */
-- 
1.8.3.1

PR fortran/95053 - division by zero constants

[Harald Anlauf]

Here's a new attempt to finally fix this PR and any known fallout.

In order to handle division by zero in declarations, but still accept the
code snippet adapted from 521.wrf_r (from spec2017), I removed the hunk
that was added to fix PR94399, and deferred the handling to a later stage.

One case regarding array shapes is handled in variable_decl in decl.c, the
other one regarding PDTs is handled in gfc_get_pdt_instance in the same
file.  While at it, I improved the error message to notify the user if an
expression that should be of INTEGER type isn't.

Regtests with no new failures on x86_64-pc-linux-gnu, after adjusting
error messages for test dec_structure_23.f90.

OK for trunk?

Thanks,
Harald


PR fortran/95053 - division by zero constants

Partially revert the fix for PR93499.  Replace by checks for valid
expressions in the declaration of array shape and PDT KIND and LEN
expressions at a later stage.

gcc/fortran/

2020-05-15  Harald Anlauf  

PR fortran/95053
* arith.c (gfc_divide): Revert hunk introduced by patch for
PR93499.
* decl.c (variable_decl): Generate error for array shape not being
an INTEGER constant.
(gfc_get_pdt_instance): Generate error if KIND or LEN expressions
in declaration of a PDT instance do not simplify to INTEGER
constants.

gcc/testsuite/

2020-05-15  Harald Anlauf  

PR fortran/95053
* gfortran.dg/dec_structure_23.f90: Adjust to new error messages.
* gfortran.dg/pr95053_2.f90: New test.
* gfortran.dg/pr95053_3.f90: New test.

diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
index dd72f44d377..c770569eb81 100644
--- a/gcc/fortran/arith.c
+++ b/gcc/fortran/arith.c
@@ -1806,38 +1806,6 @@ gfc_multiply (gfc_expr *op1, gfc_expr *op2)
 gfc_expr *
 gfc_divide (gfc_expr *op1, gfc_expr *op2)
 {
-  if (op2 && op2->expr_type == EXPR_CONSTANT)
-{
-  arith rc = ARITH_OK;
-  switch (op2->ts.type)
-	{
-	case BT_INTEGER:
-	  /* non-integer divided by integer 0 is handled elsewhere.  */
-	  if (mpz_sgn (op2->value.integer) == 0
-	  && op1->ts.type == BT_INTEGER)
-	rc = ARITH_DIV0;
-	  break;
-	case BT_REAL:
-	  if (mpfr_sgn (op2->value.real) == 0
-	  && flag_range_check == 1)
-	rc = ARITH_DIV0;
-	  break;
-	case BT_COMPLEX:
-	  if (mpc_cmp_si_si (op2->value.complex, 0, 0) == 0
-	  && flag_range_check == 1)
-	rc = ARITH_DIV0;
-	  break;
-	default:
-	  /* basic type is non-numeric, handle this elsewhere.  */
-	  break;
-	}
-  if (rc == ARITH_DIV0)
-	{
-	  gfc_seen_div0 = true;
-	  gfc_error ("Division by zero at %L", &op2->where);
-	  return NULL;
-	}
-}
   return eval_intrinsic_f3 (INTRINSIC_DIVIDE, gfc_arith_divide, op1, op2);
 }

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 9cc81361f43..3ad5559c3ec 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2607,6 +2607,14 @@ variable_decl (int elem)
 	  gfc_free_expr (e);
 	}

+	  if (not_constant && e->ts.type != BT_INTEGER)
+	{
+	  gfc_error ("Explicit array shape at %C must be constant of "
+			 "INTEGER type and not %s type",
+			 gfc_basic_typename (e->ts.type));
+	  m = MATCH_ERROR;
+	  goto cleanup;
+	}
 	  if (not_constant)
 	{
 	  gfc_error ("Explicit shaped array with nonconstant bounds at %C");
@@ -3741,8 +3749,9 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list, gfc_symbol **sym,
   if (kind_expr)
 	{
 	  /* Try simplification even for LEN expressions.  */
+	  bool ok;
 	  gfc_resolve_expr (kind_expr);
-	  gfc_simplify_expr (kind_expr, 1);
+	  ok = gfc_simplify_expr (kind_expr, 1);
 	  /* Variable expressions seem to default to BT_PROCEDURE.
 	 TODO find out why this is and fix it.  */
 	  if (kind_expr->ts.type != BT_INTEGER
@@ -3753,6 +3762,12 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list, gfc_symbol **sym,
 			 gfc_basic_typename (kind_expr->ts.type));
 	  goto error_return;
 	}
+	  if (kind_expr->ts.type == BT_INTEGER && !ok)
+	{
+	  gfc_error ("The parameter expression at %C does not "
+			 "simplify to an INTEGER constant");
+	  goto error_return;
+	}

 	  tail->expr = gfc_copy_expr (kind_expr);
 	}
diff --git a/gcc/testsuite/gfortran.dg/dec_structure_23.f90 b/gcc/testsuite/gfortran.dg/dec_structure_23.f90
index 78db344e0fc..39e5369c056 100644
--- a/gcc/testsuite/gfortran.dg/dec_structure_23.f90
+++ b/gcc/testsuite/gfortran.dg/dec_structure_23.f90
@@ -13,8 +13,8 @@ program p
   integer :: nn
   real :: rr
   structure /s/
-integer x(n)/1/   ! { dg-error "array with nonconstant bounds" }
+integer x(n)/1/   ! { dg-error "must be constant of INTEGER type" }
 integer xx(nn)  /1/   ! { dg-error "array with nonconstant bounds" }
-integer xxx(rr) /1.0/ ! { dg-error "array with nonconstant bounds" }
+integer xxx(rr) /1.0/ ! { dg-error "must be constant of INTEGER type" }
   end structure
 end
diff --git a/gcc/testsuite/gfortran.dg/pr9505

Re: libstdc++ PR 57272 Fancy pointer support in Hashtable

[François Dumont via Gcc-patches]

I think I completed this evolution.

I eventually used ref to node pointer as much as possible and even use 
move semantic on it.


My prerequisite for this to work is that nullptr can be assign on the 
fancy pointer and that a fancy pointer to __node_type is assignable 
implicitely to a fancy pointer to __node_base.


    * include/bits/hashtable_policy.h (_Hashtable_base): Add _Alloc
    template parameter.
    (_ReuseOrAllocNode<>::__node_type): Remove.
    (_ReuseOrAllocNode<>::__node_pointer): New.
    (_ReuseOrAllocNode(__node_pointer, __hashtable_alloc&)): Adapt 
to use

    latter.
    (_ReuseOrAllocNode<>::operator()(_Arg&&)): Return latter.
    (_AllocNode<>::__node_type): Remove.
    (_AllocNode<>::__node_pointer): New.
    (_AllocNode<>::operator()<>(_Arg&&)): Return latter.
    (_Hash_node_base<>): Add _NodePtr template parameter.
    (_Hash_node_value_base<>): Likewise.
    (_Hash_node<>): Add _Ptr template parameter.
    (_Hash_node<>::_M_next()): Remove.
    (_Node_iterator_base<>): Use _NodePtr template parameter.
    (operator==(const _Node_iterator_base&, const 
_Node_iterator_base&)):

    Make inline friend.
    (operator!=(const _Node_iterator_base&, const 
_Node_iterator_base&)):

    Likewise.
    (_Node_iterator<>): Use _NodePtr template parameter.
    (_Node_const_iterator<>): Use _NodePtr template parameter.
    (_Map_base<>::__node_type): Remove.
    (_Map_base<>::__node_pointer): New.
    (_Hash_code_base<>): Add _Alloc template parameter.
    (_Hash_code_base<>::__pointer): New.
    (_Hash_code_base<>::__node_pointer): New.
    (_Hash_code_base<>::__node_ptr_arg_t): New.
    (_Local_iterator_base<>): Add _Alloc template parameter. 
Inherit from

    _Node_iterator_base<>.
    (_Local_iterator_base<>::__base_node_iter): New.
    (_Local_iterator_base<>::_M_cur): Remove.
    (_Local_iterator_base<>::_M_incr()): Adapt.
    (_Local_iterator_base<>::_M_curr()): Remove.
    (operator==(const _Local_iterator_base<>&,
    const _Local_iterator_base<>&)): Remove.
    (operator!=(const _Local_iterator_base<>&,
    const _Local_iterator_base<>&)): Remove.
    (_Local_iterator<>): Add _Alloc and _NodePtr template parameters.
    (_Local_const_iterator<>): Likewise.
    (_Hashtable_base<>): Add _Alloc template parameter.
    (_Hashtable_alloc<>::__node_pointer): New.
    (_Hashtable_alloc<>::__bucket_pointer): New.
    (_Hashtable_alloc<>::_M_allocate_node): Adapt.
    (_Hashtable_alloc<>::_M_deallocate_node): Adapt.
    (_Hashtable_alloc<>::_M_deallocate_node_ptr): Adapt.
    (_Hashtable_alloc<>::_M_deallocate_nodes): Adapt.
    (_Hashtable_alloc<>::_M_allocate_buckets): Adapt.
    (_Hashtable_alloc<>::_M_deallocate_buckets): Adapt.
    * include/bits/hashtable.h (_Hashtable<>): Adapt.
    (_Hashtable<>::_M_begin()): Remove.
    * include/debug/unordered_map: Adapt.
    * include/debug/unordered_set: Adapt.
    * testsuite/23_containers/unordered_map/allocator/ext_ptr.cc: New.
    * 
testsuite/23_containers/unordered_multimap/allocator/ext_ptr.cc: New.
    * 
testsuite/23_containers/unordered_multiset/allocator/ext_ptr.cc: New.

    * testsuite/23_containers/unordered_set/allocator/ext_ptr.cc

Tested under Linux x86_64.

Ok to commit ?

François

On 19/04/20 7:31 pm, François Dumont wrote:
Here is my work in progress to use allocator pointer type. This type 
is used both as the node pointer and as the buckets pointer.


Rather than adapting _Local_iterator_base like _Node_iterator_base I 
prefer to just make it inherits from _Node_iterator_base. It 
simplifies its implementation and avoids to provided dedicated 
comparison operators.


Now I wonder if I need to consider Phil Bouchard comment regarding how 
node pointers are being passed, either by value or reference. I 
already chose to pass them as rvalue references in some occasions and 
even lvalue reference like in _M_bucket_index method. Do you think I 
need to continue this way ? Maybe I should use some conditional type, 
if raw pointer we pass by value and otherwise we pass by ref ?


François



diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h
index b00319a668b..b735291bb56 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -171,7 +171,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	   typename _H1, typename _H2, typename _Hash,
 	   typename _RehashPolicy, typename _Traits>
 class _Hashtable
-: public __detail::_Hashtable_base<_Key, _Value, _ExtractKey, _Equal,
+: public __detail::_Hashtable_base<_Key, _Value, _Alloc,
+   _ExtractKey, _Equal,
    _H1, _H2, _Hash, _Traits>,
   public __detail::_Map_base<_Key, _Value, _Alloc, _ExtractKey, _Equal,
  _H1, _H2, _Hash, _RehashPolicy, _Traits>,
@@ -182,9 +183,9 @@ _GLIBC

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Jason Merrill via Gcc-patches]

On 5/15/20 2:21 PM, Richard Biener wrote:

On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill  wrote:

On Fri, May 15, 2020 at 3:15 AM Richard Biener

wrote:


+# When bootstrapping with GCC, build stage 1 in C++11 mode to

ensure

that a

+# C++11 compiler can still start the bootstrap.
  if test "$enable_bootstrap:$GXX" = "yes:yes"; then
+  CXX="$CXX -std=gnu++11"


So I just spotted this - since we're requiring a ISO C++11 compiler shouldn't
we build stage1 with -std=c++11 rather than gnu++11 (whatever the detailed
differences are here)?  Also not sure what level of -pedantic we'd need to
avoid GNU extensions even with -std=c++11.  Of course there are (I hope)
a lot less GNU extensions for C++ than there were for C and hopefully
no extra in gnu++11 compared to gnu++98 which we checked previously.


Building stage 1 with -std=c++11 -pedantic-errors works with 8.3.1, but 
fails pretty badly with 4.8.5,



When we first moved to C++ I tried using -std=c++98, but there were too
many places where we were assuming that if we're building with GCC, we can
use GNU C extensions.

I'll see if that's still a problem for -std=c++11.


It doesn't seem to be, so I've made that change.


There also does not seem to be a configure check which may present
users with a more useful error message than later cryptic fail of build?
I suppose we cannot simply check __cplusplus for this, can we?  Do
other common host compilers need additional options to enable C++11?


Good point, I'll add that.


This patch uses a test from the autoconf archive to add any needed 
flags.  Tested with GCC 4.8.5 and clang 3.4.2 (with the above stage 1 
-std=c++11 disabled).



Should we try to second guess such flags via configury?  For example
GCC 4.8 defaults to -std=gnu++98 and the above only seems to apply
to the bootstrap case so GCC 4.8 cannot be used to build cross

compilers

without adjusting CC and CXX?


Older GCC is still GCC and will get the flag automatically.


But yes:yes suggests that when building a cross compiler this doesn't apply?


True, but the new test should cover that case.

OK for trunk?
commit f466a9f3f121f16b97071162806255fb464718f2
Author: Jason Merrill 
Date:   Fri May 15 17:15:38 2020 -0400

bootstrap: Update requirement to C++11.

There was general agreement last November that we would move to allowing
C++11 features to be used in GCC 11; this patch implements that direction.

ChangeLog
2020-05-15  Jason Merrill  

* configure.ac: Update bootstrap dialect to -std=c++11.

config/ChangeLog
2020-05-15  Jason Merrill  

* ax_cxx_compile_stdcxx.m4: Import from autoconf archive with
an adjustment to try the default mode.

gcc/ChangeLog
2020-05-15  Jason Merrill  

* aclocal.m4: Add ax_cxx_compile_stdcxx.m4.
* configure.ac: Use AX_CXX_COMPILE_STDCXX(11).

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 876b04f9c45..c367f4f66e3 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -238,18 +238,20 @@ described below.
 
 @heading Tools/packages necessary for building GCC
 @table @asis
-@item ISO C++98 compiler
-Necessary to bootstrap GCC, although versions of GCC prior
-to 4.8 also allow bootstrapping with a ISO C89 compiler and versions
-of GCC prior to 3.4 also allow bootstrapping with a traditional
-(K&R) C compiler.
+@item ISO C++11 compiler
+Necessary to bootstrap GCC.
+
+Versions of GCC prior to 11 also allow bootstrapping with an ISO C++98
+compiler, versions of GCC prior to 4.8 also allow bootstrapping with a
+ISO C89 compiler, and versions of GCC prior to 3.4 also allow
+bootstrapping with a traditional (K&R) C compiler.
 
 To build all languages in a cross-compiler or other configuration where
 3-stage bootstrap is not performed, you need to start with an existing
-GCC binary (version 3.4 or later) because source code for language
+GCC binary (version 4.8 or later) because source code for language
 frontends other than C might use GCC extensions.
 
-Note that to bootstrap GCC with versions of GCC earlier than 3.4, you
+Note that to bootstrap GCC with versions of GCC earlier than 4.8, you
 may need to use @option{--disable-stage1-checking}, though
 bootstrapping the compiler with such earlier compilers is strongly
 discouraged.
diff --git a/config/ax_cxx_compile_stdcxx.m4 b/config/ax_cxx_compile_stdcxx.m4
new file mode 100644
index 000..9413da624d2
--- /dev/null
+++ b/config/ax_cxx_compile_stdcxx.m4
@@ -0,0 +1,962 @@
+# ===
+#  https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html
+# ===
+#
+# SYNOPSIS
+#
+#   AX_CXX_COMPILE_STDCXX(VERSION, [ext|noext], [mandatory|optional])
+#
+# DESCRIPTION
+#
+#   Check for baseline language coverage in the compiler for the specified
+#   version of the C++ stand

Re: [PATCH] c++: decltype of invalid non-dependent expr [PR57943]

[Jason Merrill via Gcc-patches]

On 5/14/20 4:19 PM, Patrick Palka wrote:

We sometimes fail to reject a invalid non-dependent operand to decltype
when inside a template, because finish_decltype_type resolves the
decltype to the TREE_TYPE of the operand before we ever instantiate and
fully process the operand.  Fix this by adding a call to
instantiate_non_dependent_expr_sfinae in finish_decltype_type.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
commit?


OK.


gcc/cp/ChangeLog:

PR c++/57943
* semantics.c (finish_decltype_type): Call
instantiate_non_dependent_expr_sfinae on the decltype's operand.

gcc/testsuite/ChangeLog:

PR c++/57943
* g++.dg/cpp0x/decltype76.C: New test.
---
  gcc/cp/semantics.c  | 8 
  gcc/testsuite/g++.dg/cpp0x/decltype76.C | 7 +++
  2 files changed, 15 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype76.C

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index d90816eabc9..64587c791c6 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -9746,6 +9746,14 @@ finish_decltype_type (tree expr, bool 
id_expression_or_member_access_p,
  
return type;

  }
+  else if (processing_template_decl)
+{
+  ++cp_unevaluated_operand;
+  expr = instantiate_non_dependent_expr_sfinae (expr, complain);
+  --cp_unevaluated_operand;
+  if (expr == error_mark_node)
+   return error_mark_node;
+}
  
/* The type denoted by decltype(e) is defined as follows:  */
  
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype76.C b/gcc/testsuite/g++.dg/cpp0x/decltype76.C

new file mode 100644
index 000..239fe6d2a8f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype76.C
@@ -0,0 +1,7 @@
+// PR c+/57943
+// { dg-do compile { target c++11 } }
+
+struct a { };
+
+template  // { dg-error "" }
+void f() { }

Re: [ARM][wwwdocs]: Document Armv8.1-M Mainline Security Extensions changes.

[Ramana Radhakrishnan via Gcc-patches]

On Fri, May 15, 2020 at 12:31 PM Srinath Parvathaneni
 wrote:
>
> Armv8.1-M Mainline Security Extensions related changes in GCC-10.
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index 
> 57ca749da72ed64da37b3eb5404cf5cde8be44dd..10bf3b78c7769b73c808bd2c2fe60ebbfc9c887e
>  100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -747,6 +747,9 @@ typedef svbool_t pred512 
> __attribute__((arm_sve_vector_bits(512)));
>Support for the Custom Datapath Extension beta ACLE
> href="https://developer.arm.com/docs/101028/0010/custom-datapath-extension";>
>intrinsics has been added.
> +  Support for Armv8.1-M Mainline Security Extensions architecture has 
> been added. The -mcmse option,
> +  when used in combination with an Armv8.1-M Mainline architecture (for 
> example, -march=armv8.1.m.main -mcmse),
> +  now leads to the generation of improved code sequences when changing 
> security states.
>  
>

Ok.

Ramana

>
>

Re: libgo patch committed: Build syscall test with -static

[Ian Lance Taylor via Gcc-patches]

On Fri, May 15, 2020 at 6:42 AM Rainer Orth  
wrote:
>
> > On Thu, May 14, 2020 at 12:43 PM Rainer Orth
> >  wrote:
> >>
> >> > This libgo patch builds the syscall test with -static.  This avoids
> >> > problems finding libgo.so when running the test as root, which invokes
> >> > the test as a child process in various limited environments.  This
> >> > fixes GCC PR 95061.  Bootstrapped and ran Go tests on
> >> > x86_64-pc-linux-gnu.  Committed to mainline.
> >>
> >> this patch broke the syscall test on Solaris:
> >>
> >> ld: fatal: library -lpthread: not found
> >> ld: fatal: library -lm: not found
> >> ld: fatal: library -lc: not found
> >> ld: fatal: library -lc: not found
> >> collect2: error: ld returned 1 exit status
> >> FAIL: syscall
> >>
> >> There are no static versions of system libraries.
> >
> > Sorry about that.  The issue only arises on GNU/Linux, so committed
> > this patch after testing to at least fix the problem on Solaris.
>
> thanks.  However, during today's Linux/x86_64 bootstrap I see that the
> test fails there and indeed glibc-static isn't installed.

Ah, well.  Committed following to mainline.  This time for sure.

Ian
e210e6a965f65a7ae70e1bd8744e024999172a35
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 4776f78e5fa..bc9c1f07eda 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-cae8d4c388d4cc701c7f8fc221c9f6431760d93a
+bc27341f245a5cc54ac7530d037a609db72b677c
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/Makefile.am b/libgo/Makefile.am
index 0bbe54cfe1b..5b1807228ad 100644
--- a/libgo/Makefile.am
+++ b/libgo/Makefile.am
@@ -967,8 +967,8 @@ endif
 # Also use -fno-inline to get better results from the memory profiler.
 runtime_pprof_check_GOCFLAGS = -static-libgo -fno-inline
 
-if LIBGO_IS_LINUX
-# Use -static for the syscall tests, because otherwise when
+if HAVE_STATIC_LINK
+# Use -static for the syscall tests if possible, because otherwise when
 # running as root the re-execs ignore LD_LIBRARY_PATH.
 syscall_check_GOCFLAGS = -static
 endif
diff --git a/libgo/configure.ac b/libgo/configure.ac
index f800d44a0e9..235d867ccda 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -881,6 +881,17 @@ if test "x$libgo_cv_as_x86_aes" = xyes; then
[Define if your assembler supports AES instructions.])
 fi
 
+dnl Test whether the linker supports the -static option.
+AC_CACHE_CHECK([whether -static is supported],
+[libgo_cv_ld_static],
+[LDFLAGS_hold=$LDFLAGS
+LDFLAGS="$LDFLAGS -static"
+AC_LINK_IFELSE([AC_LANG_PROGRAM(,)],
+[libgo_cv_ld_static=yes],
+[libgo_cv_ld_static=no])
+LDFLAGS=$LDFLAGS_hold])
+AM_CONDITIONAL(HAVE_STATIC_LINK, test "$libgo_cv_ld_static" = yes)
+
 AC_CACHE_SAVE
 
 if test ${multilib} = yes; then

Re: [PATCH] TESTSUITE: Fix tests for 16-bit targets

[Joseph Myers]

On Fri, 15 May 2020, Jozef Lawrynowicz wrote:

> The attached patch fixes many GCC and G++ tests for 16-bit targets. These
> targets can have the following properties:
> - "int", "size_t", "ptrdiff_t", "void *" are 16-bit types
> - sizeof(int) == sizeof(short)

Some of the tests are disabled by the patch for the case where pointers 
are the same size as int.  Were those tests all previously failing for 
32-bit targets where that's the case?  If not, ptr_eq_int seems an 
inappropriate condition for disabling them.

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

[PATCH] warn on uninitialized accesses by function calls (PR 10138)

[Martin Sebor via Gcc-patches]

Besides better buffer overflow checking, the new GCC 10 attribute
access also provides an opportunity to detect other kinds of bugs,
including uninitialized accesses by user-defined functions.
The attached patch implements this enhancement.

In addition, the closely related PR 10138 requests that GCC warn when
passing the address of an uninitialized variable to a const-qualified
pointer function argument.  Const pointers almost always imply a read
access of the object, so the patch also enables the warning in these
cases.  (There are situations when a const pointer doesn't imply it
and the warning takes care not to trigger overly enthusiastically.)
Since pointers often point to allocated objects it seemed natural
(and was surprisingly easy) to also detect uninitialized reads from
those.

For optimum results I slightly enhanced the detection of the referenced
decls and allocations.  In the process, I also noticed and fixed a small
bug in the existing code.   This helps both find more uninitialized
variables and reduce the rate of false positives in existing warnings.

Besides the usual GCC bootstrap/regtest I validated the changes by
building a number of packages, including Binutils/GDB, Glibc, and
the Linux kernel.  It found a decent number of likely bugs (about
half a doze by my count) but also triggered a few false positives.
One class of such problems was due to the kernel's function

  __check_object_size (const void*, unsigned, bool)

used to validate the sizes of objects without ever accessing them.
To accommodate this idiom the patch adds a new  mode to attribute
access: none.

Martin
PR middle-end/10138 - warn for uninitialized arrays passed as const arguments

gcc/c-family/ChangeLog:

	PR middle-end/10138
	* c-attribs.c (append_access_attrs): Handle attr_access::none.
	(handle_access_attribute): Same.

gcc/ChangeLog:

	PR middle-end/10138
	* attribs.c (init_attr_rdwr_indices): Move function here
	* attribs.h (attr_access): Add 'none'.
	(rdwr_map): Define.
	(init_attr_rdwr_indices): Declared function.
	* builtins.c (warn_for_access)): New function.
	(check_access): Call it.
	* builtins.h (checK-access): Add an optional argument.
	* calls.c (rdwr_access_hash, rdwr_map): Move to attribs.h.
	(append_attrname): Handle attr_access::none.
	(maybe_warn_rdwr_sizes): Same.
	(initialize_argument_information): Update comments.
	* doc/extend.texi (attribute access): Document 'none'.
	* tree-ssa-uninit.c (struct wlimits): New.
	(maybe_warn_operand): New function.
	(warn_uninitialized_vars): Refactor code into maybe_warn_operand.
	Also call for function calls.
	(pass_late_warn_uninitialized::execute): Adjust comments.
	(execute_early_warn_uninitialized): Same.

gcc/testsuite/ChangeLog:

	PR middle-end/10138
	* c-c++-common/Wsizeof-pointer-memaccess1.c: Prune out valid
	Wuninitialized.
	* c-c++-common/uninit-pr51010.c: Adjust expected warning format.
	* c-c++-common/goacc/uninit-dim-clause.c: Same.
	* c-c++-common/goacc/uninit-firstprivate-clause.c: Same.
	* c-c++-common/goacc/uninit-if-clause.c: Same.
	* c-c++-common/gomp/pr70550-1.c: Same.
	* g++.dg/20090107-1.C: Same.
	* gcc.dg/Warray-bounds-54.c: Prune out valid -Wuninitialized.
	* gcc.dg/Wstringop-overflow-33.c: New test.
	* gcc.dg/attr-access-none.c: New test.
	* gcc.dg/pr71581.c: Adjust text of expected warning.
	* gcc.dg/uninit-15.c: Same.
	* gcc.dg/uninit-32.c: New test.
	* gcc.dg/uninit-33.c: New test.
	* gcc.dg/uninit-34.c: New test.
	* gcc.dg/uninit-36.c: New test.
	* gcc.dg/uninit-B-O0.c: Adjust text of expected warning.
	* gcc.dg/uninit-I-O0.c: Same.
	* gcc.dg/uninit-pr19430-O0.c: Same.
	* gcc.dg/uninit-pr19430.c (foo): Same.
	* gcc.dg/uninit-pr95136.c: New test.

diff --git a/gcc/attribs.c b/gcc/attribs.c
index 7d0f4b5b7b4..71dae123af8 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -2017,6 +2017,65 @@ maybe_diag_alias_attributes (tree alias, tree target)
 }
 }
 
+/* Initialize a mapping for a call to function FNDECL declared with
+   attribute access.  Each attribute positional operand inserts one
+   entry into the mapping with the operand number as the key.  */
+
+void
+init_attr_rdwr_indices (rdwr_map *rwm, tree fntype)
+{
+  if (!fntype)
+return;
+
+  for (tree access = TYPE_ATTRIBUTES (fntype);
+   (access = lookup_attribute ("access", access));
+   access = TREE_CHAIN (access))
+{
+  /* The TREE_VALUE of an attribute is a TREE_LIST whose TREE_VALUE
+	 is the attribute argument's value.  */
+  tree mode = TREE_VALUE (access);
+  gcc_assert (TREE_CODE (mode) == TREE_LIST);
+  mode = TREE_VALUE (mode);
+  gcc_assert (TREE_CODE (mode) == STRING_CST);
+
+  const char *modestr = TREE_STRING_POINTER (mode);
+  for (const char *m = modestr; *m; )
+	{
+	  attr_access acc = { };
+
+	  switch (*m)
+	{
+	case 'r': acc.mode = acc.read_only; break;
+	case 'w': acc.mode = acc.write_only; break;
+	case 'x': acc.mode = acc.read_write; break;
+	case '-': acc.mode = acc.none; break;
+	d

[PATCH] libiberty: Handle function return type and variable declaration type in D demangler.

[Witold Baryluk via Gcc-patches]

Adds support for DMGL_RET_POSTFIX in D demangler, so it shows the type
of the declared variable, or function return type. Postfix notation is
used with space.

libiberty/ChangeLog:

* d-demangle.c: Add DMGL_RET_POSTFIX support.
* testsuite/d-demangle-expected: Add new tests.

Signed-off-by: Witold Baryluk 
---
 libiberty/ChangeLog |  5 ++
 libiberty/d-demangle.c  | 18 +-
 libiberty/testsuite/d-demangle-expected | 84 +
 3 files changed, 104 insertions(+), 3 deletions(-)

diff --git a/libiberty/ChangeLog b/libiberty/ChangeLog
index 45dcc6d61..32cc8ff23 100644
--- a/libiberty/ChangeLog
+++ b/libiberty/ChangeLog
@@ -1,3 +1,8 @@
+2020-05-15  Witold Baryluk  
+
+   * d-demangle.c: Add DMGL_RET_POSTFIX support.
+   * testsuite/d-demangle-expected: Add new tests.
+
 2020-05-15  Iain Buclaw  
 
* d-demangle.c (dlang_attributes): Add @live attribute.
diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index f2d6946ec..318c21c8d 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -167,6 +167,8 @@ struct dlang_info
   const char *s;
   /* The index of the last back reference.  */
   int last_backref;
+  /* Demangler options passed to dlang_demangle.  */
+  int option;
 };
 
 /* Pass as the LEN to dlang_parse_template if symbol length is not known.  */
@@ -1553,6 +1555,15 @@ dlang_parse_mangle (string *decl, const char *mangled, 
struct dlang_info *info)
 
  string_init (&type);
  mangled = dlang_type (&type, mangled, info);
+
+ /* If requested return the return type of a function or type of
+a variable in postfix notation with space as separator.  */
+ if ((info->option & DMGL_RET_POSTFIX) != 0)
+   {
+ string_append (decl, " ");
+ string_appendn (decl, type.b, string_length (&type));
+   }
+
  string_delete (&type);
}
 }
@@ -1860,17 +1871,18 @@ dlang_parse_template (string *decl, const char *mangled,
 /* Initialize the information structure we use to pass around information.  */
 static void
 dlang_demangle_init_info (const char *mangled, int last_backref,
- struct dlang_info *info)
+ int option, struct dlang_info *info)
 {
   info->s = mangled;
   info->last_backref = last_backref;
+  info->option = option;
 }
 
 /* Extract and demangle the symbol in MANGLED.  Returns the demangled
signature on success or NULL on failure.  */
 
 char *
-dlang_demangle (const char *mangled, int option ATTRIBUTE_UNUSED)
+dlang_demangle (const char *mangled, int option)
 {
   string decl;
   char *demangled = NULL;
@@ -1891,7 +1903,7 @@ dlang_demangle (const char *mangled, int option 
ATTRIBUTE_UNUSED)
 {
   struct dlang_info info;
 
-  dlang_demangle_init_info (mangled, strlen (mangled), &info);
+  dlang_demangle_init_info (mangled, strlen (mangled), option, &info);
   mangled = dlang_parse_mangle (&decl, mangled, &info);
 
   /* Check that the entire symbol was successfully demangled.  */
diff --git a/libiberty/testsuite/d-demangle-expected 
b/libiberty/testsuite/d-demangle-expected
index e3f32e31d..778058b40 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -1406,3 +1406,87 @@ 
std.algorithm.iteration.FilterResult!(std.typecons.Tuple!(int, "a", int, "b", in
 --format=dlang
 
_D3std3uni__T6toCaseS_DQvQt12toLowerIndexFNaNbNiNewZtVii1043S_DQCjQCi10toLowerTabFNaNbNiNemZwSQDo5ascii7toLowerTAyaZQDzFNaNeQmZ14__foreachbody2MFNaNeKmKwZ14__foreachbody3MFNaNeKwZi
 std.uni.toCase!(std.uni.toLowerIndex(dchar), 1043, std.uni.toLowerTab(ulong), 
std.ascii.toLower, 
immutable(char)[]).toCase(immutable(char)[]).__foreachbody2(ref ulong, ref 
dchar).__foreachbody3(ref dchar)
+#
+--format=dlang
+_D3std8datetime9stopwatch9StopWatch6__ctorMFNbNcNiNfEQBz8typecons__T4FlagVAyaa9_6175746f5374617274ZQBfZSQDyQDxQDrQDk
+std.datetime.stopwatch.StopWatch.this(std.typecons.Flag!("autoStart").Flag)
+#
+--format=dlang
+_D4core4time8Duration__T8opBinaryVAyaa1_2bTSQBqQBoQBmZQBeMxFNaNbNiNfQzZQBc
+core.time.Duration.opBinary!("+", 
core.time.Duration).opBinary(core.time.Duration) const
+#
+--format=dlang
+_D4core4sync5mutex5Mutex__T12lock_nothrowTOCQBqQBoQBmQBjZQBeMOFNbNiNeZv
+core.sync.mutex.Mutex.lock_nothrow!(shared(core.sync.mutex.Mutex)).lock_nothrow()
 shared
+#
+--format=dlang
+_D4core8internal5array8capacity__T22_d_arraysetlengthTImplHTAPmTQdZ18_d_arraysetlengthTFNaNbNeMNkKQBmmZm
+core.internal.array.capacity._d_arraysetlengthTImpl!(ulong*[], 
ulong*)._d_arraysetlengthT(scope return ref ulong*[], ulong)
+#
+--format=dlang
+_D3std6random__T7uniformVAyaa2_5b29TiTiTSQBnQBm__T21MersenneTwisterEngineTkVmi32Vmi624Vmi397Vmi31Vki2567483615Vmi11Vki4294967295Vmi7Vki2636928640Vmi15Vki4022730752Vmi18Vki1812433253ZQFcZQGoFNaNfiiKQGbZi
+std.random.uniform!("[)", int, int, std.random.MersenneTwisterEngine!(uint, 
32uL, 624uL, 397uL, 31uL, 256748

Re:

[Martin Sebor via Gcc-patches]

On 5/15/20 8:08 AM, Richard Sandiford wrote:

We've moved more and more to stronly-typed data structures
so I'd not like to see 'auto' everywhere - it should be still
obvious what kind of objects we're working with where they
matter.  IMHO they do not matter for example for iterators.
I don't care about the iterator type but about the type of
the object and the container.

Also agreed. :-)  How about this as a starting point:

---
Use auto for:

- the result of casts or other expressions that give the type
   explicitly.  E.g.:

 if (auto *table = dyn_cast  (insn))

   instead of:

 if (rtx_jump_table_data *table = dyn_cast  (insn))

- iterator types.  E.g.:

 auto it = foo.begin ();

   instead of:

 foo_type::iterator it = foo.begin ();

- expressions that provide an alternative view of something,
   when the expression is bound to a read-only temporary.  E.g.:

 auto val1 = wi::to_wide (...);
 auto val2 = wi::uhwi (12, 16);

   instead of:

 wide_int val1 = wi::to_wide (...);
 wide_int val2 = wi::uhwi (12, 16);

   (Using "wide_int" is less efficient than using the natural type of
   the expression.)

- the type of a lambda expression.  E.g.:

 auto f = [] (int x) { return x + 1; };

Those are all good examples.  Mind putting that into a patch
for the coding conventions?

How's this?  I added "new" expressions as another example of the
first category.

I'm sure I've missed other good uses, but we can always add to the
list later if necessary.

Thanks,
Richard


0001-Describe-coding-conventions-surrounding-auto.patch

 From 10b27e367de0fa9d5bf91544385401cdcbdb8c00 Mon Sep 17 00:00:00 2001
From: Richard Sandiford
Date: Fri, 15 May 2020 14:58:46 +0100
Subject: [PATCH] Describe coding conventions surrounding "auto"

---
  htdocs/codingconventions.html | 53 +++
  htdocs/codingrationale.html   | 17 +++
  2 files changed, 70 insertions(+)

diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index f4732ef6..ae49fb91 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -51,6 +51,7 @@ the conventions separately from any other changes to the 
code.
  Language Use
  
  Variable Definitions
+Use of auto
  Struct Definitions
  Class Definitions
  Constructors and Destructors
@@ -884,6 +885,58 @@ Variables may be simultaneously defined and tested in 
control expressions.
  Rationale and Discussion
  
  
+Use of auto

+
+auto should be used in the following circumstances:
+
+  when the expression gives the C++ type explicitly.  For example
+
+
+if (auto *table = dyn_cast  
(insn)) // OK
+  ...
+if (rtx_jump_table_data *table = dyn_cast  
(insn))  // Avoid
+  ...
+auto *map = new hash_map ;   
 // OK
+hash_map  *map = new hash_map ; // 
Avoid
+
+This rule does not apply to abbreviated type names embedded in
+an identifier, such as the result of tree_to_shwi.
+  
+  
+when the expression simply provides an alternative view of an object
+and is bound to a read-only temporary.  For example:
+
+
+auto wioff = wi::to_wide (off); // OK
+wide_int wioff = wi::to_wide (off); // Avoid if wioff is read-only
+auto minus1 = std::shwi (-1, prec); // OK
+wide_int minus1 = std::shwi (-1, prec); // Avoid if minus1 is 
read-only
+
+In principle this rule applies to other views of an object too,
+such as a reversed view of a list, or a sequential view of a
+hash_set.  It does not apply to general temporaries.
+  
+  
+the type of an iterator.  For example:
+
+
+auto it = std::find (names.begin (), names.end (), needle); 
   // OK
+vector ::iterator it = std::find (names.begin (),
+names.end (), needle); // 
Avoid
+  
+  
+the type of a lambda expression.  For example:
+
+
+auto f = [] (int x) { return x + 1; }; // 
OK
+  
+
+
+auto should not be used in other contexts.


This seems like a severe (and unnecessary) restriction...


+
+
+Rationale and Discussion
+
  
  Struct Definitions
  
diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html

index 0b44f1da..a919023c 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -50,6 +50,23 @@ if (info *q = get_any_available_info ()) {
  }
  
  
+Use of auto

+
+The reason for preferring auto in expressions like:
+auto wioff = wi::to_wide (off);
+is that using the natural type of the expression is more efficient than
+converting it to types like wide_int.
+
+The reason for excluding other uses of auto is that
+in most other cases the type carries useful information.  For example:
+for (const std::pair  &elt : 
indirect_pool)
+  ...
+makes it obvious that elt i

Re:

[Jason Merrill via Gcc-patches]

On Fri, May 15, 2020 at 9:47 PM Martin Sebor  wrote:

> On 5/15/20 8:08 AM, Richard Sandiford wrote:
>  We've moved more and more to stronly-typed data structures
>  so I'd not like to see 'auto' everywhere - it should be still
>  obvious what kind of objects we're working with where they
>  matter.  IMHO they do not matter for example for iterators.
>  I don't care about the iterator type but about the type of
>  the object and the container.
> >>> Also agreed. :-)  How about this as a starting point:
> >>>
> >>> ---
> >>> Use auto for:
> >>>
> >>> - the result of casts or other expressions that give the type
> >>>explicitly.  E.g.:
> >>>
> >>>  if (auto *table = dyn_cast  (insn))
> >>>
> >>>instead of:
> >>>
> >>>  if (rtx_jump_table_data *table = dyn_cast 
> (insn))
> >>>
> >>> - iterator types.  E.g.:
> >>>
> >>>  auto it = foo.begin ();
> >>>
> >>>instead of:
> >>>
> >>>  foo_type::iterator it = foo.begin ();
> >>>
> >>> - expressions that provide an alternative view of something,
> >>>when the expression is bound to a read-only temporary.  E.g.:
> >>>
> >>>  auto val1 = wi::to_wide (...);
> >>>  auto val2 = wi::uhwi (12, 16);
> >>>
> >>>instead of:
> >>>
> >>>  wide_int val1 = wi::to_wide (...);
> >>>  wide_int val2 = wi::uhwi (12, 16);
> >>>
> >>>(Using "wide_int" is less efficient than using the natural type of
> >>>the expression.)
> >>>
> >>> - the type of a lambda expression.  E.g.:
> >>>
> >>>  auto f = [] (int x) { return x + 1; };
> >> Those are all good examples.  Mind putting that into a patch
> >> for the coding conventions?
> > How's this?  I added "new" expressions as another example of the
> > first category.
> >
> > I'm sure I've missed other good uses, but we can always add to the
> > list later if necessary.
> >
> > Thanks,
> > Richard
> >
> >
> > 0001-Describe-coding-conventions-surrounding-auto.patch
> >
> >  From 10b27e367de0fa9d5bf91544385401cdcbdb8c00 Mon Sep 17 00:00:00 2001
> > From: Richard Sandiford
> > Date: Fri, 15 May 2020 14:58:46 +0100
> > Subject: [PATCH] Describe coding conventions surrounding "auto"
> >
> > ---
> >   htdocs/codingconventions.html | 53 +++
> >   htdocs/codingrationale.html   | 17 +++
> >   2 files changed, 70 insertions(+)
> >
> > diff --git a/htdocs/codingconventions.html
> b/htdocs/codingconventions.html
> > index f4732ef6..ae49fb91 100644
> > --- a/htdocs/codingconventions.html
> > +++ b/htdocs/codingconventions.html
> > @@ -51,6 +51,7 @@ the conventions separately from any other changes to
> the code.
> >   Language Use
> >   
> >   Variable Definitions
> > +Use of auto
> >   Struct Definitions
> >   Class Definitions
> >   Constructors and
> Destructors
> > @@ -884,6 +885,58 @@ Variables may be simultaneously defined and tested
> in control expressions.
> >   Rationale and Discussion
> >   
> >
> > +Use of auto
> > +
> > +auto should be used in the following circumstances:
> > +
> > +  when the expression gives the C++ type explicitly.  For
> example
> > +
> > +
> > +if (auto *table = dyn_cast  *> (insn)) // OK
> > +  ...
> > +if (rtx_jump_table_data *table = dyn_cast 
> (insn))  // Avoid
> > +  ...
> > +auto *map = new hash_map ;
> // OK
> > +hash_map  *map = new hash_map ;
> // Avoid
> > +
> > +This rule does not apply to abbreviated type names embedded in
> > +an identifier, such as the result of tree_to_shwi.
> > +  
> > +  
> > +when the expression simply provides an alternative view of an
> object
> > +and is bound to a read-only temporary.  For example:
> > +
> > +
> > +auto wioff = wi::to_wide (off); // OK
> > +wide_int wioff = wi::to_wide (off); // Avoid if wioff is read-only
> > +auto minus1 = std::shwi (-1, prec); // OK
> > +wide_int minus1 = std::shwi (-1, prec); // Avoid if minus1 is
> read-only
> > +
> > +In principle this rule applies to other views of an object too,
> > +such as a reversed view of a list, or a sequential view of a
> > +hash_set.  It does not apply to general
> temporaries.
> > +  
> > +  
> > +the type of an iterator.  For example:
> > +
> > +
> > +auto it = std::find (names.begin (), names.end (),
> needle);// OK
> > +vector ::iterator it = std::find (names.begin (),
> > +names.end (), needle); //
> Avoid
> > +  
> > +  
> > +the type of a lambda expression.  For example:
> > +
> > +
> > +auto f = [] (int x) { return x + 1; }; //
> OK
> > +  
> > +
> > +
> > +auto should not be used in other contexts.
>
> This seems like a severe (and unnecessary) restriction...
>
> > +
> > +
> > +Rationale and Discussion
> > +
> >
> >   Struct Definitions
>

[committed] Simplify and improve some H8 peepholes

[Jeff Law via Gcc-patches]

A couple minor improvements to the H8 port I spotted while doing the cc0->CC_REG
transition.

First is consolidation of 3 peepholes into a single peephole using a mode
iterator.  This has zero impact on the code we generate, but means fewer 
patterns
that I ultimately have to convert.

Second is two conceptual improvements to peepholes that combine stack 
allocations
with stores into the stack by turning the store into a pre-decrement address
mode.

First, the peepholes should work just as well with SFmode as they do with 
SImode.
So a new iterator is introduced so that we don't need separate patterns for
SFmode.  Second we failed to optimize stack adjustments of 8 bytes.  If we use
subs the sequence would take 8 bytes, but after the peephole it's just 6 bytes.

This saves a few hundred bytes and makes it easier to compare the baseline
against the converted port for regressions.  I remove the clock counts -- they
don't look right (perhaps they were for the original H8/300).

jeff


diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 3ae73f21560..4f48d443235 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2020-05-15 Jeff Law  
+
+	* config/h8300/h8300.md (SFI iterator): New iterator for
+	SFmode and SImode.
+	* config/h8300/peepholes.md (memory comparison): Use mode
+	iterator to consolidate 3 patterns into one.
+	(stack allocation and stack store): Handle SFmode.  Handle
+	8 byte allocations.
+
 2020-05-15  Segher Boessenkool  
 
 	* config/rs6000/rs6000-builtin.def (BU_FUTURE_MISC_2): Also require
diff --git a/gcc/config/h8300/h8300.md b/gcc/config/h8300/h8300.md
index e9b598d375a..46ab2442576 100644
--- a/gcc/config/h8300/h8300.md
+++ b/gcc/config/h8300/h8300.md
@@ -191,6 +191,8 @@
 
 (define_mode_iterator QHSIF [QI HI SI SF])
 
+(define_mode_iterator SFI [SF SI])
+
 (define_code_iterator shifts [ashift ashiftrt lshiftrt])
 
 (define_code_iterator ors [ior xor])
diff --git a/gcc/config/h8300/peepholes.md b/gcc/config/h8300/peepholes.md
index 9086bddcf57..a0f5af28a53 100644
--- a/gcc/config/h8300/peepholes.md
+++ b/gcc/config/h8300/peepholes.md
@@ -551,9 +551,9 @@
 ;; Convert a memory comparison to a move if there is a scratch register.
 
 (define_peephole2
-  [(match_scratch:QI 1 "r")
+  [(match_scratch:QHSI 1 "r")
(set (cc0)
-	(compare (match_operand:QI 0 "memory_operand" "")
+	(compare (match_operand:QHSI 0 "memory_operand" "")
 		 (const_int 0)))]
   ""
   [(set (match_dup 1)
@@ -562,31 +562,6 @@
 		   (const_int 0)))]
   "")
 
-(define_peephole2
-  [(match_scratch:HI 1 "r")
-   (set (cc0)
-	(compare (match_operand:HI 0 "memory_operand" "")
-		 (const_int 0)))]
-  ""
-  [(set (match_dup 1)
-	(match_dup 0))
-   (set (cc0) (compare (match_dup 1)
-		   (const_int 0)))]
-  "")
-
-(define_peephole2
-  [(match_scratch:SI 1 "r")
-   (set (cc0)
-	(compare (match_operand:SI 0 "memory_operand" "")
-		 (const_int 0)))]
-  ""
-  [(set (match_dup 1)
-	(match_dup 0))
-   (set (cc0) (compare (match_dup 1)
-		   (const_int 0)))]
-  "")
-
-
 ;; (compare (reg:HI) (const_int)) takes 4 bytes, so we try to achieve
 ;; the equivalent with shorter sequences.  Here is the summary.  Cases
 ;; are grouped for each define_peephole2.
@@ -1418,31 +1393,48 @@
 
 ;; stack adjustment of -4, generate one push
 ;;
-;; before : 6 bytes, 10 clocks
-;; after  : 4 bytes, 10 clocks
+;; before : 6 bytes
+;; after  : 4 bytes
 
 (define_peephole2
   [(set (reg:SI SP_REG)
 	(plus:SI (reg:SI SP_REG)
 		 (const_int -4)))
-   (set (mem:SI (reg:SI SP_REG))
-	(match_operand:SI 0 "register_operand" ""))]
+   (set (mem:SFI (reg:SI SP_REG))
+	(match_operand:SFI 0 "register_operand" ""))]
   "!TARGET_NORMAL_MODE && REGNO (operands[0]) != SP_REG"
-  [(set (mem:SI (pre_dec:SI (reg:SI SP_REG)))
-	(match_dup 0))]
-  "")
+  [(set (mem:SFI (pre_dec:SI (reg:SI SP_REG)))
+	(match_dup 0))])
+
+;; stack adjustment of -8, generate one push
+;;
+;; before : 8 bytes
+;; after  : 6 bytes
+
+(define_peephole2
+  [(set (reg:SI SP_REG)
+	(plus:SI (reg:SI SP_REG)
+		 (const_int -8)))
+   (set (mem:SFI (reg:SI SP_REG))
+	(match_operand:SFI 0 "register_operand" ""))]
+  "!TARGET_NORMAL_MODE && REGNO (operands[0]) != SP_REG"
+  [(set (reg:SI SP_REG)
+	(plus:SI (reg:SI SP_REG)
+		 (const_int -4)))
+   (set (mem:SFI (pre_dec:SI (reg:SI SP_REG)))
+	(match_dup 0))])
 
 ;; stack adjustment of -12, generate one push
 ;;
-;; before : 10 bytes, 14 clocks
-;; after  :  8 bytes, 14 clocks
+;; before : 10 bytes
+;; after  :  8 bytes
 
 (define_peephole2
   [(set (reg:SI SP_REG)
 	(plus:SI (reg:SI SP_REG)
 		 (const_int -12)))
-   (set (mem:SI (reg:SI SP_REG))
-	(match_operand:SI 0 "register_operand" ""))]
+   (set (mem:SFI (reg:SI SP_REG))
+	(match_operand:SFI 0 "register_operand" ""))]
   "!TARGET_NORMAL_MODE && REGNO (operands[0]) != SP_REG"
   [(set (reg:SI SP_REG)
 	(plus:SI (reg:SI SP_REG)
@@ -1450,9 +1442,8 @@
(set (reg:SI SP_REG)
 	(plus:SI (reg:SI SP_REG)
 		 (const_int -4)))
-   (set (mem:SI (pre_dec:SI (reg:SI SP_REG)))
-	(match_dup 0))]
-

Re: [PATCH RFC] bootstrap: Update requirement to C++11.

[Richard Biener via Gcc-patches]

On May 15, 2020 11:53:42 PM GMT+02:00, Jason Merrill  wrote:
>On 5/15/20 2:21 PM, Richard Biener wrote:
>> On May 15, 2020 7:30:38 PM GMT+02:00, Jason Merrill
> wrote:
>>> On Fri, May 15, 2020 at 3:15 AM Richard Biener
>>> 
>>> wrote:
>>>
> +# When bootstrapping with GCC, build stage 1 in C++11 mode to
>>> ensure
 that a
> +# C++11 compiler can still start the bootstrap.
>   if test "$enable_bootstrap:$GXX" = "yes:yes"; then
> +  CXX="$CXX -std=gnu++11"

 So I just spotted this - since we're requiring a ISO C++11 compiler
>shouldn't
 we build stage1 with -std=c++11 rather than gnu++11 (whatever the
>detailed
 differences are here)?  Also not sure what level of -pedantic we'd
>need to
 avoid GNU extensions even with -std=c++11.  Of course there are (I
>hope)
 a lot less GNU extensions for C++ than there were for C and
>hopefully
 no extra in gnu++11 compared to gnu++98 which we checked
>previously.
>
>Building stage 1 with -std=c++11 -pedantic-errors works with 8.3.1, but
>
>fails pretty badly with 4.8.5,
>
>>> When we first moved to C++ I tried using -std=c++98, but there were
>too
>>> many places where we were assuming that if we're building with GCC,
>we can
>>> use GNU C extensions.
>>>
>>> I'll see if that's still a problem for -std=c++11.
>
>It doesn't seem to be, so I've made that change.
>
 There also does not seem to be a configure check which may present
 users with a more useful error message than later cryptic fail of
>build?
 I suppose we cannot simply check __cplusplus for this, can we?  Do
 other common host compilers need additional options to enable
>C++11?
>>>
>>> Good point, I'll add that.
>
>This patch uses a test from the autoconf archive to add any needed 
>flags.  Tested with GCC 4.8.5 and clang 3.4.2 (with the above stage 1 
>-std=c++11 disabled).
>
 Should we try to second guess such flags via configury?  For
>example
 GCC 4.8 defaults to -std=gnu++98 and the above only seems to apply
 to the bootstrap case so GCC 4.8 cannot be used to build cross
>>> compilers
 without adjusting CC and CXX?
>>>
>>> Older GCC is still GCC and will get the flag automatically.
>> 
>> But yes:yes suggests that when building a cross compiler this doesn't
>apply?
>
>True, but the new test should cover that case.
>
>OK for trunk?

OK if there are no further comments over the weekend. 

Thanks, 
Richard.