Re: [PATCH] contrib/gcc-changelog: Handle Reviewed-{by,on}

[Frederik Harwath]

Martin Liška  writes:

Hi Martin,

> On 5/19/20 11:45 AM, Frederik Harwath wrote:
> Thank you Frederick for the patch.
>
> Looking at what I grepped:
> https://github.com/marxin/gcc-changelog/issues/1#issuecomment-621910248

I get a 404 error when I try to access this URL. The repository also
does not seem to be in your list of public repositories.


> Can you also add 'Signed-off-by'? And please create a list with these
> exceptions at the beginning of the script.

Yes, I will add it.

> Fine with that.

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

Re: [PATCH 2/2] rs6000: tune loop size for cunroll at O2

[Kewen.Lin via Gcc-patches]

Hi Jeff,

on 2020/5/20 上午11:58, Jiufu Guo via Gcc-patches wrote:
> Hi,
> 
> This patch check the size of a loop to be unrolled/peeled completely,
> and set the limits to a number (24).  This prevents large loop from
> being unrolled, then avoid binary size increasing, and this limit keeps
> performance.
> 
> Bootstrap pass on powerpc64le, ok for trunk?
> 
> Jiufu
> 
> ---
>  gcc/config/rs6000/rs6000.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index a1a3f9cb583..f3abb92d046 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -5142,6 +5142,22 @@ rs6000_loop_unroll_adjust (unsigned nunroll, struct 
> loop *loop)
>return nunroll;
>  }
>  
> +/* Count the number of statements in LOOP.  */
> +
> +static int
> +num_stmt_in_loop (class loop *loop)
> +{
> +  int res = 0;
> +  basic_block *bbs = get_loop_body (loop);
> +  for (unsigned i = 0; i < loop->num_nodes; i++)
> +for (gimple_stmt_iterator bsi = gsi_start_bb (bbs[i]); !gsi_end_p (bsi);
> +  gsi_next ())
> +  if (!is_gimple_debug (gsi_stmt (bsi)))
> + res++;
> +
> +  return res;
> +}
> +

Would it be possible to use tree_num_loop_insns here?
If no, this can be part of tree-ssa-loop.c, and we need to free(bbs).

BR,
Kewen

>  /* Implement targetm.loop_allow_unroll_completely_peel.  */
>  
>  static bool
> @@ -5151,7 +5167,8 @@ rs6000_loop_allow_unroll_completely_peel (HOST_WIDE_INT 
> maxiter, tree niter,
>if (unroll_only_small_loops && optimize == 2)
>  {
>if (maxiter >= 4
> -   && !(TREE_CODE (niter) == INTEGER_CST && single_exit (loop)))
> +   && !(TREE_CODE (niter) == INTEGER_CST && num_stmt_in_loop (loop) < 24
> +&& single_exit (loop)))
>   return false;
>  }
>  
> 

Re: [PATCH v2] c++: Implement DR 2289, Uniqueness of structured binding names [PR94553]

[Marek Polacek via Gcc-patches]

On Tue, May 19, 2020 at 10:39:59AM -0400, Jason Merrill wrote:
> On 5/18/20 5:07 PM, Marek Polacek wrote:
> > On Mon, May 18, 2020 at 04:50:44PM -0400, Jason Merrill via Gcc-patches 
> > wrote:
> > > On 5/13/20 12:22 PM, Marek Polacek wrote:
> > > > DR 2289 clarified that since structured bindings have no C compatibility
> > > > implications, they should be unique in their declarative region, see
> > > > [basic.scope.declarative]/4.2.
> > > > 
> > > > The duplicate_decls hunk is the gist of the patch, but that alone would
> > > > not be enough to detect the 'A' case: 
> > > > cp_parser_decomposition_declaration
> > > > uses
> > > > 
> > > > 13968   tree decl2 = start_decl (declarator, _specs, 
> > > > SD_INITIALIZED,
> > > > 13969NULL_TREE, NULL_TREE, 
> > > > _pushed_scope);
> > > > 
> > > > to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we
> > > > don't do fit_decomposition_lang_decl because the declarator kind is not
> > > > cdk_decomp
> > > 
> > > Why isn't it?  I see
> > > 
> > >cp_declarator *declarator = make_declarator (cdk_decomp);
> > > 
> > > a few lines up.
> > 
> > Right, and we use that for the underlying decomp base VAR_DECL.  But each of
> > the named variables used in a structured binding are created in the
> > FOR_EACH_VEC_ELT loop, and that creates a cdk_id declarator for them:
> > 
> > 13963   if (i == 0)
> > 13964 declarator = make_id_declarator (NULL_TREE, e.get_value (),
> > 13965  sfk_none, e.get_location ());
> 
> Ah, yes.
> 
> You name the new parameter FORCE_LANG_DECL_P and describe it as meaning
> "create a lang decl node for the new decl", but the actual meaning seems to
> be "mark the new decl as DECL_DECOMPOSITION_P", which seems too specific for
> adding a new parameter to a frequently used function.
> 
> How about adding a new SD_DECOMPOSITION value for the initialized parameter,
> or an attribute?

Sounds good, I agree that a new SD_ flag is better than adding a new parameter
for such a corner case.

I've reviewed the uses of the 'initialized' parameter in start_decl{,1},
grokdeclarator, and grokvardecl and adjusted where needed.  It's kind of
tempting to use an enum (possibly scoped one, now that we're in C++11)
instead of a #define but I've resisted doing that thus far.

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

Thanks,

-- >8 --
DR 2289 clarified that since structured bindings have no C compatibility
implications, they should be unique in their declarative region, see
[basic.scope.declarative]/4.2.

The duplicate_decls hunk is the gist of the patch, but that alone would
not be enough to detect the 'A' case: cp_parser_decomposition_declaration
uses

13968   tree decl2 = start_decl (declarator, _specs, SD_INITIALIZED,
13969NULL_TREE, NULL_TREE, _pushed_scope);

to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we
don't do fit_decomposition_lang_decl because the declarator kind is not
cdk_decomp, so then when start_decl calls maybe_push_decl, the decl 'A'
isn't DECL_DECOMPOSITION_P and we don't detect this case.  So I needed a
way to signal to start_decl that it should fit_decomposition_lang_decl.
In this patch, I'm adding SD_DECOMPOSITION flag to say that the variable
is initialized and it should also be marked as DECL_DECOMPOSITION_P.

DR 2289
PR c++/94553
* cp-tree.h (SD_DECOMPOSITION): New flag.
* decl.c (duplicate_decls): Make sure a structured binding is unique
in its declarative region.
(start_decl): If INITIALIZED is SD_DECOMPOSITION, call
fit_decomposition_lang_decl.
(grokdeclarator): Compare INITIALIZED directly to SD_* flags.
* parser.c (cp_parser_decomposition_declaration): Pass SD_DECOMPOSITION
to start_decl.

* g++.dg/cpp1z/decomp52.C: New test.
---
 gcc/cp/cp-tree.h  |  6 --
 gcc/cp/decl.c | 23 +--
 gcc/cp/parser.c   |  2 +-
 gcc/testsuite/g++.dg/cpp1z/decomp52.C | 14 ++
 4 files changed, 36 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/decomp52.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 31c30ff87b3..27707abaadc 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5694,8 +5694,10 @@ enum overload_flags { NO_SPECIAL = 0, DTOR_FLAG, 
TYPENAME_FLAG };
 /* Used with start_decl's initialized parameter.  */
 #define SD_UNINITIALIZED 0
 #define SD_INITIALIZED   1
-#define SD_DEFAULTED 2
-#define SD_DELETED   3
+/* Like SD_INITIALIZED, but also mark the new decl as DECL_DECOMPOSITION_P.  */
+#define SD_DECOMPOSITION 2
+#define SD_DEFAULTED 3
+#define SD_DELETED   4
 
 /* Returns nonzero iff TYPE1 and TYPE2 are the same type, or if TYPE2
is derived from TYPE1, or if TYPE2 is a pointer (reference) to a

Re: [PATCH 2/2] rs6000: tune loop size for cunroll at O2

[Jiufu Guo via Gcc-patches]

Jiufu Guo  writes:

> Hi,
>
> This patch check the size of a loop to be unrolled/peeled completely,
> and set the limits to a number (24).  This prevents large loop from
> being unrolled, then avoid binary size increasing, and this limit keeps
> performance.
>
> Bootstrap pass on powerpc64le, ok for trunk?
>
> Jiufu

ChangeLog
2020-05-20  Jiufu Guo   

PR target/95018
* config/rs6000/rs6000.c (num_stmt_in_loop): New function.
(rs6000_loop_allow_unroll_completely_peel): Call num_stmt_in_loop.

>
> ---
>  gcc/config/rs6000/rs6000.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index a1a3f9cb583..f3abb92d046 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -5142,6 +5142,22 @@ rs6000_loop_unroll_adjust (unsigned nunroll, struct 
> loop *loop)
>return nunroll;
>  }
>  
> +/* Count the number of statements in LOOP.  */
> +
> +static int
> +num_stmt_in_loop (class loop *loop)
> +{
> +  int res = 0;
> +  basic_block *bbs = get_loop_body (loop);
> +  for (unsigned i = 0; i < loop->num_nodes; i++)
> +for (gimple_stmt_iterator bsi = gsi_start_bb (bbs[i]); !gsi_end_p (bsi);
> +  gsi_next ())
> +  if (!is_gimple_debug (gsi_stmt (bsi)))
> + res++;
> +
> +  return res;
> +}
> +
>  /* Implement targetm.loop_allow_unroll_completely_peel.  */
>  
>  static bool
> @@ -5151,7 +5167,8 @@ rs6000_loop_allow_unroll_completely_peel (HOST_WIDE_INT 
> maxiter, tree niter,
>if (unroll_only_small_loops && optimize == 2)
>  {
>if (maxiter >= 4
> -   && !(TREE_CODE (niter) == INTEGER_CST && single_exit (loop)))
> +   && !(TREE_CODE (niter) == INTEGER_CST && num_stmt_in_loop (loop) < 24
> +&& single_exit (loop)))
>   return false;
>  }

[PATCH 2/2] rs6000: tune loop size for cunroll at O2

[Jiufu Guo via Gcc-patches]

Hi,

This patch check the size of a loop to be unrolled/peeled completely,
and set the limits to a number (24).  This prevents large loop from
being unrolled, then avoid binary size increasing, and this limit keeps
performance.

Bootstrap pass on powerpc64le, ok for trunk?

Jiufu

---
 gcc/config/rs6000/rs6000.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index a1a3f9cb583..f3abb92d046 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -5142,6 +5142,22 @@ rs6000_loop_unroll_adjust (unsigned nunroll, struct loop 
*loop)
   return nunroll;
 }
 
+/* Count the number of statements in LOOP.  */
+
+static int
+num_stmt_in_loop (class loop *loop)
+{
+  int res = 0;
+  basic_block *bbs = get_loop_body (loop);
+  for (unsigned i = 0; i < loop->num_nodes; i++)
+for (gimple_stmt_iterator bsi = gsi_start_bb (bbs[i]); !gsi_end_p (bsi);
+gsi_next ())
+  if (!is_gimple_debug (gsi_stmt (bsi)))
+   res++;
+
+  return res;
+}
+
 /* Implement targetm.loop_allow_unroll_completely_peel.  */
 
 static bool
@@ -5151,7 +5167,8 @@ rs6000_loop_allow_unroll_completely_peel (HOST_WIDE_INT 
maxiter, tree niter,
   if (unroll_only_small_loops && optimize == 2)
 {
   if (maxiter >= 4
- && !(TREE_CODE (niter) == INTEGER_CST && single_exit (loop)))
+ && !(TREE_CODE (niter) == INTEGER_CST && num_stmt_in_loop (loop) < 24
+  && single_exit (loop)))
return false;
 }
 
-- 
2.17.1

[PATCH 1/2] rs6000: tune cunroll for simple loops at O2

[Jiufu Guo via Gcc-patches]

Hi,

In r10-4525, and r10-4161, loop unroller was enabled for simply loops at -O2.
At the same time, the GIMPLE cunroll is also enabled, while it is not only for
simple loops.  This patch introduces a hook to check if a loop is suitable to
unroll completely.  The hook can be used to check if a loop is simply enough
for complete unroll, then avoid negative effects like size increasing or
complex loop unrolling at -O2.

This patch could help to handle the code in PR95018 which contains complex
loop, and does not cause obvious performance change on SPEC2017.

Bootstrap/regtest pass on powerpc64le. OK for trunk?

Jiufu

2020-05-20  Jiufu Guo   

PR target/95018
* target.def (loop_allow_unroll_completely_peel): New hook.
* doc/tm.texi (TARGET_LOOP_ALLOW_UNROLL_COMPLETELY_PEEL): New hook.
* doc/tm.texi.in (TARGET_LOOP_ALLOW_UNROLL_COMPLETELY_PEEL): New hook.
* config/rs6000/rs6000.c (TARGET_LOOP_ALLOW_UNROLL_COMPLETELY_PEEL): 
New hook.
(rs6000_loop_allow_unroll_completely_peel): New hook implementation.
* tree-ssa-loop-ivcanon.c (canonicalize_loop_induction_variables): Call
hook loop_allow_unroll_completely_peel.


---
 gcc/config/rs6000/rs6000.c  | 19 +++
 gcc/doc/tm.texi |  9 +
 gcc/doc/tm.texi.in  |  2 ++
 gcc/target.def  | 12 
 gcc/tree-ssa-loop-ivcanon.c |  5 +
 5 files changed, 47 insertions(+)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 8435bc15d72..a1a3f9cb583 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1433,6 +1433,9 @@ static const struct attribute_spec 
rs6000_attribute_table[] =
 #undef TARGET_LOOP_UNROLL_ADJUST
 #define TARGET_LOOP_UNROLL_ADJUST rs6000_loop_unroll_adjust
 
+#undef TARGET_LOOP_ALLOW_UNROLL_COMPLETELY_PEEL
+#define TARGET_LOOP_ALLOW_UNROLL_COMPLETELY_PEEL 
rs6000_loop_allow_unroll_completely_peel
+
 #undef TARGET_INIT_BUILTINS
 #define TARGET_INIT_BUILTINS rs6000_init_builtins
 #undef TARGET_BUILTIN_DECL
@@ -5139,6 +5142,22 @@ rs6000_loop_unroll_adjust (unsigned nunroll, struct loop 
*loop)
   return nunroll;
 }
 
+/* Implement targetm.loop_allow_unroll_completely_peel.  */
+
+static bool
+rs6000_loop_allow_unroll_completely_peel (HOST_WIDE_INT maxiter, tree niter,
+ struct loop *loop)
+{
+  if (unroll_only_small_loops && optimize == 2)
+{
+  if (maxiter >= 4
+ && !(TREE_CODE (niter) == INTEGER_CST && single_exit (loop)))
+   return false;
+}
+
+  return true;
+}
+
 /* Handler for the Mathematical Acceleration Subsystem (mass) interface to a
library with vectorized intrinsics.  */
 
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 6e7d9dc54a9..f7419872c2f 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -11893,6 +11893,15 @@ is required only when the target has special 
constraints like maximum
 number of memory accesses.
 @end deftypefn
 
+@deftypefn {Target Hook} bool TARGET_LOOP_ALLOW_UNROLL_COMPLETELY_PEEL 
(HOST_WIDE_INT @var{maxiter}, tree @var{niter}, class loop *@var{loop})
+This target hook check if the loop @var{loop} is suitable to unroll
+completely on the target. The parameter @var{maxiter} is the possible max
+bound of iterations. The parameter @var{niter} is the number expression of
+iterations the loop is executed. The parameter @var{loop} is a pointer to
+the loop. This target hook is required only when the target has special
+constraints.
+@end deftypefn
+
 @defmac POWI_MAX_MULTS
 If defined, this macro is interpreted as a signed integer C expression
 that specifies the maximum number of floating point multiplications
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 3be984bbd5c..4ae079a650c 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -8010,6 +8010,8 @@ lists.
 
 @hook TARGET_LOOP_UNROLL_ADJUST
 
+@hook TARGET_LOOP_ALLOW_UNROLL_COMPLETELY_PEEL
+
 @defmac POWI_MAX_MULTS
 If defined, this macro is interpreted as a signed integer C expression
 that specifies the maximum number of floating point multiplications
diff --git a/gcc/target.def b/gcc/target.def
index 07059a87caf..3842ba611a2 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -2709,6 +2709,18 @@ number of memory accesses.",
  unsigned, (unsigned nunroll, class loop *loop),
  NULL)
 
+/* Return if a loop is suitable for complete unroll.  */
+DEFHOOK
+(loop_allow_unroll_completely_peel,
+ "This target hook check if the loop @var{loop} is suitable to unroll\n\
+completely on the target. The parameter @var{maxiter} is the possible max\n\
+bound of iterations. The parameter @var{niter} is the number expression of\n\
+iterations the loop is executed. The parameter @var{loop} is a pointer to\n\
+the loop. This target hook is required only when the target has special\n\
+constraints.",
+ bool, (HOST_WIDE_INT maxiter, tree niter, class loop *loop),
+ NULL)
+
 /* True if X is a legitimate MODE-mode immediate operand.  */

[PATCH] c++: spec_hasher and TYPENAME_TYPE resolution [PR95223]

[Patrick Palka via Gcc-patches]

After enabling sanitization of the specialization tables, we are
triggering one of the hash table sanity checks in the below testcase.

The reason is that when looking up the specialization j in the
type_specializations table, the sanity check finds that the existing
entry j::m> compares equal to j but hashes differently.

The discrepancy is due to structural_comptypes looking through
TYPENAME_TYPEs (via resolve_typename_type), something which
iterative_hash_template_arg doesn't do.  So the TYPENAME_TYPE n::m is
considered equal to int, but the hashes of these template arguments are
different.

It seems wrong for the result of a specialization table lookup to depend
on the current scope, so this patch makes structural_comptypes avoid
calling resolve_typename_type when comparing_specializations.

In order for the below testcase to deterministically trigger the
sanitization error without this patch, we also need to fix the location
of the call to hash_table::verify within hash_table::find_with_hash.

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

gcc/ChangeLog:

PR c++/95223
* hash-table.h (hash_table::find_with_hash): Move up the call to
hash_table::verify.

gcc/cp/ChangeLog:

PR c++/95223
* gcc/cp/typeck.c (structural_comptypes): Don't perform
context-dependent resolution of TYPENAME_TYPEs when
comparing_specializations.

gcc/testsuite/ChangeLog:

PR c++/95223
* g++.dg/template/typename23.C: New test.
---
 gcc/cp/typeck.c| 15 +--
 gcc/hash-table.h   | 14 +++---
 gcc/testsuite/g++.dg/template/typename23.C | 10 ++
 3 files changed, 26 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/template/typename23.C

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index d2e6c907622..0181984bb99 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -1256,13 +1256,16 @@ structural_comptypes (tree t1, tree t2, int strict)
 
   gcc_assert (TYPE_P (t1) && TYPE_P (t2));
 
-  /* TYPENAME_TYPEs should be resolved if the qualifying scope is the
- current instantiation.  */
-  if (TREE_CODE (t1) == TYPENAME_TYPE)
-t1 = resolve_typename_type (t1, /*only_current_p=*/true);
+  if (!comparing_specializations)
+{
+  /* TYPENAME_TYPEs should be resolved if the qualifying scope is the
+current instantiation.  */
+  if (TREE_CODE (t1) == TYPENAME_TYPE)
+   t1 = resolve_typename_type (t1, /*only_current_p=*/true);
 
-  if (TREE_CODE (t2) == TYPENAME_TYPE)
-t2 = resolve_typename_type (t2, /*only_current_p=*/true);
+  if (TREE_CODE (t2) == TYPENAME_TYPE)
+   t2 = resolve_typename_type (t2, /*only_current_p=*/true);
+}
 
   if (TYPE_PTRMEMFUNC_P (t1))
 t1 = TYPE_PTRMEMFUNC_FN_TYPE (t1);
diff --git a/gcc/hash-table.h b/gcc/hash-table.h
index a1423c78112..32f3a634e1e 100644
--- a/gcc/hash-table.h
+++ b/gcc/hash-table.h
@@ -912,6 +912,12 @@ hash_table
 
   if (Lazy && m_entries == NULL)
 m_entries = alloc_entries (size);
+
+#if CHECKING_P
+  if (m_sanitize_eq_and_hash)
+verify (comparable, hash);
+#endif
+
   value_type *entry = _entries[index];
   if (is_empty (*entry)
   || (!is_deleted (*entry) && Descriptor::equal (*entry, comparable)))
@@ -928,13 +934,7 @@ hash_table
   entry = _entries[index];
   if (is_empty (*entry)
   || (!is_deleted (*entry) && Descriptor::equal (*entry, comparable)))
-   {
-#if CHECKING_P
- if (m_sanitize_eq_and_hash)
-   verify (comparable, hash);
-#endif
- return *entry;
-   }
+   return *entry;
 }
 }
 
diff --git a/gcc/testsuite/g++.dg/template/typename23.C 
b/gcc/testsuite/g++.dg/template/typename23.C
new file mode 100644
index 000..d2fb0ca72f5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/typename23.C
@@ -0,0 +1,10 @@
+// PR c++/95223
+// { dg-do compile }
+// { dg-additional-options "--param=hash-table-verification-limit=1" }
+
+template  struct j {};
+template  struct n {
+  typedef int m;
+  j::m> p();
+};
+template  j::m> n::p() { return o::f(); }
-- 
2.26.2.626.g172e8ff696

[PATCH] x86: Update VPCLMULQDQ check

[H.J. Lu via Gcc-patches]

Update VPCLMULQDQ check to support processors with AVX version of
VPCLMULQDQ.

PR target/91695
* config/i386/cpuinfo.c (get_available_features): Fix VPCLMULQDQ
check.
---
 libgcc/config/i386/cpuinfo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libgcc/config/i386/cpuinfo.c b/libgcc/config/i386/cpuinfo.c
index 26c1bdca361..cf5f0884bb4 100644
--- a/libgcc/config/i386/cpuinfo.c
+++ b/libgcc/config/i386/cpuinfo.c
@@ -346,6 +346,8 @@ get_available_features (unsigned int ecx, unsigned int edx,
{
  if (ebx & bit_AVX2)
set_feature (FEATURE_AVX2);
+ if (ecx & bit_VPCLMULQDQ)
+   set_feature (FEATURE_VPCLMULQDQ);
}
   if (ebx & bit_BMI2)
set_feature (FEATURE_BMI2);
@@ -373,8 +375,6 @@ get_available_features (unsigned int ecx, unsigned int edx,
set_feature (FEATURE_AVX512VBMI);
  if (ecx & bit_AVX512VBMI2)
set_feature (FEATURE_AVX512VBMI2);
- if (ecx & bit_VPCLMULQDQ)
-   set_feature (FEATURE_VPCLMULQDQ);
  if (ecx & bit_AVX512VNNI)
set_feature (FEATURE_AVX512VNNI);
  if (ecx & bit_AVX512BITALG)
-- 
2.26.2

Re: [PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

[Douglas B Rupp]

Apologies on this test, the problem is -mdejagnu-cpu doesn't get matched 
by the spec logic


If I pass -mcpu=power8, then indeed the test passes fine.

I'm not sure how to fix this cleanly.

Re: V2 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[H.J. Lu via Gcc-patches]

On Tue, May 19, 2020 at 2:07 PM Uros Bizjak  wrote:
>
> On Tue, May 19, 2020 at 9:58 PM H.J. Lu  wrote:
> >
> > On Mon, May 18, 2020 at 10:56 PM Uros Bizjak  wrote:
> > >
> > > On Tue, May 19, 2020 at 4:17 AM H.J. Lu  wrote:
> > > >
> > > > On Mon, May 18, 2020 at 5:57 AM H.J. Lu  wrote:
> > > > >
> > > > > On Mon, May 18, 2020 at 5:43 AM Uros Bizjak  wrote:
> > > > > >
> > > > > > On Mon, May 18, 2020 at 2:34 PM H.J. Lu  wrote:
> > > > > > >
> > > > > > > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Mon, May 18, 2020 at 1:58 PM H.J. Lu  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, 
> > > > > > > > > Ice Lake
> > > > > > > > > and Tiger Lake processor families.
> > > > > > > > >
> > > > > > > > > OK for master?
> > > > > > > >
> > > > > > > > OK.
> > > > > > >
> > > > > > > I am checking in my patch.
> > > > > > >
> > > > > > > > Please also update cpuinfo.c from libgcc and corresponding
> > > > > > >
> > > > > > > I will take a look to see if we share the same CPU detection code 
> > > > > > > between
> > > > > > > libgcc and config/i386/driver-i386.c.
> > > > > >
> > > > > > I don't think it will bring any benefit, this is mainly one huge
> > > > > > switch statement that maps to different stuff in libgcc and
> > > > > > driver-i386.
> > > > >
> > > > > libgcc and config/i386/driver-i386.c differ even before my patch.
> > > > > I think we can do better.
> > > > >
> > > >
> > > > Move cpuinfo.h from libgcc to common/config/i386 so that get_intel_cpu
> > > > can be shared by libgcc, GCC driver, gcc.target/i386/builtin_target.c
> > > > and libgfortran to detect the specific type of Intel CPU.  Update
> > > > libgfortran to use has_cpu_feature to detect x86 CPU features.
> > > >
> > > > Tested on Linux/x86 and Linux/x86-64.  OK for master?
> > >
> > > Handling only Intel targets and not others is a sure way for patch to
> > > be ignored.
> > >
> >
> > Here is the updated patch to cover AMD CPU.  It also fixes:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95212
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95220
> >
> > OK for master?
>
> Huh... I didn't think the solution will be this messy... I have to
> rethink the approach a bit.
>

These can avoid duplication in i386-builtins.c:

/* These are the values for vendor types, cpu types and subtypes in
   cpuinfo.h.  Cpu types and subtypes should be subtracted by the
   corresponding start value.  */

#define M_CPU_TYPE_START (BUILTIN_VENDOR_MAX)
#define M_CPU_SUBTYPE_START \
  (M_CPU_TYPE_START + BUILTIN_CPU_TYPE_MAX)
#define M_VENDOR(a) (a)
#define M_CPU_TYPE(a) (M_CPU_TYPE_START + a)
#define M_CPU_SUBTYPE(a) (M_CPU_SUBTYPE_START + a)

static const _arch_names_table arch_names_table[] =
{
  {"amd", M_VENDOR (VENDOR_AMD)},
  {"intel", M_VENDOR (VENDOR_INTEL)},
  {"atom", M_CPU_TYPE (INTEL_BONNELL)},
  {"slm", M_CPU_TYPE (INTEL_SILVERMONT)},
  {"core2", M_CPU_TYPE (INTEL_CORE2)},
  {"corei7", M_CPU_TYPE (INTEL_COREI7)},
  {"nehalem", M_CPU_SUBTYPE (INTEL_COREI7_NEHALEM)},
  {"westmere", M_CPU_SUBTYPE (INTEL_COREI7_WESTMERE)},
  {"sandybridge", M_CPU_SUBTYPE (INTEL_COREI7_SANDYBRIDGE)},
  {"ivybridge", M_CPU_SUBTYPE (INTEL_COREI7_IVYBRIDGE)},
  {"haswell", M_CPU_SUBTYPE (INTEL_COREI7_HASWELL)},
  {"broadwell", M_CPU_SUBTYPE (INTEL_COREI7_BROADWELL)},
  {"skylake", M_CPU_SUBTYPE (INTEL_COREI7_SKYLAKE)},
  {"skylake-avx512", M_CPU_SUBTYPE (INTEL_COREI7_SKYLAKE_AVX512)},
  {"cannonlake", M_CPU_SUBTYPE (INTEL_COREI7_CANNONLAKE)},
  {"icelake-client", M_CPU_SUBTYPE (INTEL_COREI7_ICELAKE_CLIENT)},
  {"icelake-server", M_CPU_SUBTYPE (INTEL_COREI7_ICELAKE_SERVER)},
  {"cascadelake", M_CPU_SUBTYPE (INTEL_COREI7_CASCADELAKE)},
  {"tigerlake", M_CPU_SUBTYPE (INTEL_COREI7_TIGERLAKE)},
  {"cooperlake", M_CPU_SUBTYPE (INTEL_COREI7_COOPERLAKE)},
  {"bonnell", M_CPU_TYPE (INTEL_BONNELL)},
  {"silvermont", M_CPU_TYPE (INTEL_SILVERMONT)},
  {"goldmont", M_CPU_TYPE (INTEL_GOLDMONT)},
  {"goldmont-plus", M_CPU_TYPE (INTEL_GOLDMONT_PLUS)},
  {"tremont", M_CPU_TYPE (INTEL_TREMONT)},
  {"knl", M_CPU_TYPE (INTEL_KNL)},
  {"knm", M_CPU_TYPE (INTEL_KNM)},
  {"amdfam10h", M_CPU_TYPE (AMDFAM10H)},
  {"barcelona", M_CPU_SUBTYPE (AMDFAM10H_BARCELONA)},
  {"shanghai", M_CPU_SUBTYPE (AMDFAM10H_SHANGHAI)},
  {"istanbul", M_CPU_SUBTYPE (AMDFAM10H_ISTANBUL)},
  {"btver1", M_CPU_TYPE (AMD_BTVER1)},
  {"amdfam15h", M_CPU_TYPE (AMDFAM15H)},
  {"bdver1", M_CPU_SUBTYPE (AMDFAM15H_BDVER1)},
  {"bdver2", M_CPU_SUBTYPE (AMDFAM15H_BDVER2)},
  {"bdver3", M_CPU_SUBTYPE (AMDFAM15H_BDVER3)},
  {"bdver4", M_CPU_SUBTYPE (AMDFAM15H_BDVER4)},
  {"btver2", M_CPU_TYPE (AMD_BTVER2)},
  {"amdfam17h", M_CPU_TYPE (AMDFAM17H)},
  {"znver1", M_CPU_SUBTYPE (AMDFAM17H_ZNVER1)},
  {"znver2", M_CPU_SUBTYPE (AMDFAM17H_ZNVER2)},
};


-- 
H.J.

Re: [PATCH v2] c++: Change the default dialect to C++17.

[Marek Polacek via Gcc-patches]

On Mon, May 18, 2020 at 03:51:36PM -0400, Jason Merrill wrote:
> On 5/16/20 6:34 PM, Marek Polacek wrote:
> > Since GCC 9, C++17 support is no longer experimental.  It was too late
> > to change the default C++ dialect to C++17 in GCC 10, but I think now
> > it's time to pull the trigger (C++14 was made the default in GCC 6.1).
> > We're still missing two C++17 library features, but that shouldn't stop
> > us.  See
> > 
> > and
> > 
> > for the C++17 status.
> > 
> > I won't list all C++17 features here, but just a few heads-up:
> > 
> > - trigraphs were removed (hardly anyone cares, unless your keyboard is
> >missing the # key),
> > - operator++(bool) was removed (so some tests now run in C++14 and down
> >only),
> > - the keyword register was removed (some legacy code might trip on
> >this),
> > - noexcept specification is now part of the type system and C++17 does
> >not allow dynamic exception specifications anymore (the empty throw
> >specification is still available, but it is deprecated),
> > - the evaluation order rules are different in C++17,
> > - static constexpr data members are now implicitly inline (which makes
> >them definitions),
> > - C++17 requires guaranteed copy elision, meaning that a copy/move
> >constructor call might be elided completely.  That means that if
> >something relied on a constructor being instantiated via e.g. copying
> >a function parameter, it might now fail.
> > 
> > Jakub, the last point is actually what I encountered in for-27.C and it
> > looks like an OpenMP issue, in that it wrongly depends on an implicit
> > instantiation.  Am I mistaken?
> > 
> > Due to the 'register' removal, this patch depends on the regenerated
> > cfns.h version I posted earlier today.
> > 
> > I'll post an update for cxx-status.html and add a new caveat to changes.html
> > once this is in.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, aarch64-unknown-linux-gnu,
> > and powerpc64le-unknown-linux-gnu.  Ok for trunk?
> > 
> > * doc/invoke.texi (C Dialect Options): Adjust -std default for C++.
> > * doc/standards.texi (C Language): Correct the default dialect.
> > (C++ Language): Update the default for C++ to gnu++17.
> > 
> > * c-opts.c (c_common_init_options): Default to gnu++17.
> > 
> > * c-c++-common/torture/vector-subscript-3.c: Remove the register
> > keywords.
> > * g++.dg/cpp1z/attributes-enum-1a.C: Update for C++17.
> > * g++.dg/cpp1z/fold7a.C: Likewise.
> > * g++.dg/cpp1z/nontype3a.C: Likewise.
> > * g++.dg/cpp1z/utf8-2a.C: Likewise.
> > * g++.dg/parse/error11.C: Use c++14_down.
> > * g++.dg/torture/pr34850.C: Add -Wno-attribute-warning.
> > * g++.dg/torture/pr49394.C: Add dg-warning.
> > * g++.dg/torture/pr82154.C: Use -std=c++14.
> > * g++.dg/ubsan/pr85029.C: Use -Wno-register.
> > * g++.dg/ubsan/vptr-12.C: Use -fstrong-eval-order=some.
> > * lib/target-supports.exp: Set to C++17.
> > * obj-c++.dg/try-catch-9.mm: Use -Wno-register.
> > 
> > * testsuite/libgomp.c++/atomic-3.C: Use -std=gnu++14.
> > * testsuite/libgomp.c++/for-27.C: Explicitly instantiate the
> > copy constructor for I.
> > ---
> >   gcc/c-family/c-opts.c   | 4 ++--
> >   gcc/doc/invoke.texi | 2 +-
> >   gcc/doc/standards.texi  | 4 ++--
> >   gcc/testsuite/c-c++-common/torture/vector-subscript-3.c | 6 +++---
> >   gcc/testsuite/g++.dg/cpp1z/attributes-enum-1a.C | 4 ++--
> >   gcc/testsuite/g++.dg/cpp1z/fold7a.C | 4 ++--
> >   gcc/testsuite/g++.dg/cpp1z/nontype3a.C  | 4 ++--
> >   gcc/testsuite/g++.dg/cpp1z/utf8-2a.C| 4 ++--
> >   gcc/testsuite/g++.dg/parse/error11.C| 5 +++--
> >   gcc/testsuite/g++.dg/torture/pr34850.C  | 2 +-
> >   gcc/testsuite/g++.dg/torture/pr49394.C  | 2 +-
> >   gcc/testsuite/g++.dg/torture/pr82154.C  | 3 ++-
> >   gcc/testsuite/g++.dg/ubsan/pr85029.C| 2 +-
> >   gcc/testsuite/g++.dg/ubsan/vptr-12.C| 2 +-
> >   gcc/testsuite/lib/target-supports.exp   | 2 +-
> >   gcc/testsuite/obj-c++.dg/try-catch-9.mm | 2 +-
> >   libgomp/testsuite/libgomp.c++/atomic-3.C| 3 ++-
> >   libgomp/testsuite/libgomp.c++/for-27.C  | 6 ++
> >   18 files changed, 35 insertions(+), 26 deletions(-)
> > 
> > diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
> > index 7695e88c130..5b266c06f3b 100644
> > --- a/gcc/c-family/c-opts.c
> > +++ b/gcc/c-family/c-opts.c
> > @@ -256,9 +256,9 @@ c_common_init_options (unsigned int 
> > decoded_options_count,
> >   }
> >   }
> > -  /* Set C++ standard to C++14 if not specified 

Re: [PATCH][GCC][Arm]: Fix bootstrap failure with rtl-checking

[Ramana Radhakrishnan via Gcc-patches]

On Mon, Apr 27, 2020 at 2:22 PM Andre Vieira (lists)
 wrote:
>
> Hi,
>
> The code change that caused this regression was not meant to affect neon
> code-gen, however I missed the REG fall through.  This patch makes sure
> we only get the left-hand of the PLUS if it is indeed a PLUS expr.
>
> I suggest that in gcc-11 this code is cleaned up, as I do not think we
> even need the overlap checks, NEON only loads from or stores to FP
> registers and these can't be used in its addressing modes.
>
> Bootstrapped arm-linux-gnueabihf with '--enable-checking=yes,rtl' for
> armv7-a and amrv8-a.
>
> Is this OK for trunk?
>

Also for GCC-10  ?

Ramana

> gcc/ChangeLog:
> 2020-04-27  Andre Vieira  
>
>  * config/arm/arm.c (output_move_neon): Only get the first operand,
>  if addr is PLUS.
>

[committed] libstdc++: Use RDRAND as fallback if RDSEED keeps failing (PR 94087)

[Jonathan Wakely via Gcc-patches]

It's not difficult for multiple threads to drain the entropy available
to the RDSEED instruction, at which point we throw an exception. This
change will try to use RDRAND after RDSEED fails repeatedly, and only
throw if RDRAND also fails repeatedly. This doesn't guarantee a random
value can always be read, but reduces the likelihood of failure when
using the RDSEED instruction.

PR libstdc++/94087
* src/c++11/random.cc (__x86_rdseed): Allow fallback function to be
passed in.
(__x86_rdseed_rdrand): New function that uses rdseed with rdrand
fallback.
(random_device::_M_init): Use __x86_rdseed_rdrand when both
instructions are available.
* testsuite/26_numerics/random/random_device/94087.cc: New test.

Tested x86_64-linux and powerpc64le-linux, committed to master.


commit a2d196e75cef95c2b70734ad02e94f9da0e769fe
Author: Jonathan Wakely 
Date:   Tue May 19 16:49:21 2020 +0100

libstdc++: Use RDRAND as fallback if RDSEED keeps failing (PR 94087)

It's not difficult for multiple threads to drain the entropy available
to the RDSEED instruction, at which point we throw an exception. This
change will try to use RDRAND after RDSEED fails repeatedly, and only
throw if RDRAND also fails repeatedly. This doesn't guarantee a random
value can always be read, but reduces the likelihood of failure when
using the RDSEED instruction.

PR libstdc++/94087
* src/c++11/random.cc (__x86_rdseed): Allow fallback function to be
passed in.
(__x86_rdseed_rdrand): New function that uses rdseed with rdrand
fallback.
(random_device::_M_init): Use __x86_rdseed_rdrand when both
instructions are available.
* testsuite/26_numerics/random/random_device/94087.cc: New test.

diff --git a/libstdc++-v3/src/c++11/random.cc b/libstdc++-v3/src/c++11/random.cc
index 236eccfc177..62ed274479a 100644
--- a/libstdc++-v3/src/c++11/random.cc
+++ b/libstdc++-v3/src/c++11/random.cc
@@ -97,7 +97,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
 #if USE_RDSEED
 unsigned int
 __attribute__ ((target("rdseed")))
-__x86_rdseed(void*)
+__x86_rdseed(void* fallback)
 {
   unsigned int retries = 100;
   unsigned int val;
@@ -105,12 +105,25 @@ namespace std _GLIBCXX_VISIBILITY(default)
   while (__builtin_ia32_rdseed_si_step() == 0)
{
  if (--retries == 0)
-   std::__throw_runtime_error(__N("random_device: rdseed failed"));
+   {
+ if (auto f = reinterpret_cast(fallback))
+   return f(nullptr);
+ std::__throw_runtime_error(__N("random_device: rdseed failed"));
+   }
  __builtin_ia32_pause();
}
 
   return val;
 }
+
+#if USE_RDRAND
+unsigned int
+__attribute__ ((target("rdseed,rdrnd")))
+__x86_rdseed_rdrand(void*)
+{
+  return __x86_rdseed(reinterpret_cast(&__x86_rdrand));
+}
+#endif
 #endif
 
 #ifdef _GLIBCXX_USE_CRT_RAND_S
@@ -205,6 +218,15 @@ namespace std _GLIBCXX_VISIBILITY(default)
__cpuid_count(7, 0, eax, ebx, ecx, edx);
if (ebx & bit_RDSEED)
  {
+#ifdef USE_RDRAND
+   // CPUID.01H:ECX.RDRAND[bit 30]
+   __cpuid(1, eax, ebx, ecx, edx);
+   if (ecx & bit_RDRND)
+ {
+   _M_func = &__x86_rdseed_rdrand;
+   return;
+ }
+#endif
_M_func = &__x86_rdseed;
return;
  }
diff --git a/libstdc++-v3/testsuite/26_numerics/random/random_device/94087.cc 
b/libstdc++-v3/testsuite/26_numerics/random/random_device/94087.cc
new file mode 100644
index 000..cfcc261906e
--- /dev/null
+++ b/libstdc++-v3/testsuite/26_numerics/random/random_device/94087.cc
@@ -0,0 +1,63 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library 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.
+
+// This library 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 this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run }
+// { dg-options "-pthread"  }
+// { dg-require-effective-target c++11 }
+// { dg-require-effective-target pthread }
+// { dg-require-gthreads "" }
+
+#include 
+#include 
+#include 
+#include 
+
+bool
+random_device_available(const char* token) noexcept
+{
+  try {
+std::random_device dev(token);
+

Re: [PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

[Douglas B Rupp]

On 5/19/20 3:03 PM, Segher Boessenkool wrote:


This is a compile test, so it does not matter at all what the kernel is
doing or not doing.  And the -mcpu=power8 flag should enable altivec.
Apparently it doesn't for you, but why is that?



It's likely the specs file we use for the kernel we are using for 
testing with.


%{mcpu=604:%{!maltivec:%{!mno-altivec:-mno-altivec}}} 
%{mcpu=604:%{!mvsx:%{!mno-vsx:-mno-vsx}}} 
%{!mcpu=*:%{!maltivec:%{!mno-altivec:-mno-altivec}}} 
%{!mcpu=*:%{!mvsx:%{!mno-vsx:-mno-vsx}}}


and

'--with-cpu=604'



This shouldn't be fixed by whack-a-mole on individual testcases.

Perhaps a SUBTARGET_OVERRIDE incantation might work?  Any ideas or 
advice you might have would be welcome.

Re: ChangeLog files - server and client scripts

[Jonathan Wakely via Gcc-patches]

On Tue, 19 May 2020 at 23:19, Jonathan Wakely  wrote:
>
> On Tue, 19 May 2020 at 11:44, Martin Liška  wrote:
> >
> > Hello.
> >
> > We've just installed server git hooks that verify git messages
> > for a correct ChangeLog format. For a limited time period, please
> > still apply ChangeLog changes to the corresponding ChangeLog files.
> > We'll use it for comparison of auto-generated CangeLog entries.
> >
> > The format is documented here:
> > https://gcc.gnu.org/codingconventions.html#ChangeLogs
> >
> > And I would recommend to install the new 'git gcc-verify' hook from:
> > contrib/gcc-git-customization.sh
> >
> > Feel free to contact me about future troubles you'll see.
>
> The --allow-non-strict-mode option seems unnecessarily verbose. It's
> not allowing non-strict mode, it's enabling it. Would --non-strict or
> --relaxed be better?
>
> And I don't understand the help text for it. 'Use non-strict mode
> (change in both ChangeLog and other files.' It seems that non-strict
> mode allows changes to certain "project files" that are not supposed
> to be manually edited, but I can't correlate that to "change in both
> ChangeLog and other files". It's also missing the closing parenthesis.
>
> Would this patch make sense?

Or this one that actually adds the closing parenthesis :-)
diff --git a/contrib/gcc-changelog/git_check_commit.py 
b/contrib/gcc-changelog/git_check_commit.py
index 8553c90a96f..4fa2bb0b4a2 100755
--- a/contrib/gcc-changelog/git_check_commit.py
+++ b/contrib/gcc-changelog/git_check_commit.py
@@ -28,9 +28,9 @@ parser.add_argument('-g', '--git-path', default='.',
 help='Path to git repository')
 parser.add_argument('-p', '--print-changelog', action='store_true',
 help='Print final changelog entires')
-parser.add_argument('-n', '--allow-non-strict-mode', action='store_true',
-help='Allow non-strict mode (change in both ChangeLog and '
-'other files.')
+parser.add_argument('-n', '--non-strict-mode', action='store_true',
+help='Use non-strict mode (allow changes in ChangeLog and '
+'other automatically updated files).')
 args = parser.parse_args()
 
 retval = 0

Re: ChangeLog files - server and client scripts

[Jonathan Wakely via Gcc-patches]

On Tue, 19 May 2020 at 11:44, Martin Liška  wrote:
>
> Hello.
>
> We've just installed server git hooks that verify git messages
> for a correct ChangeLog format. For a limited time period, please
> still apply ChangeLog changes to the corresponding ChangeLog files.
> We'll use it for comparison of auto-generated CangeLog entries.
>
> The format is documented here:
> https://gcc.gnu.org/codingconventions.html#ChangeLogs
>
> And I would recommend to install the new 'git gcc-verify' hook from:
> contrib/gcc-git-customization.sh
>
> Feel free to contact me about future troubles you'll see.

The --allow-non-strict-mode option seems unnecessarily verbose. It's
not allowing non-strict mode, it's enabling it. Would --non-strict or
--relaxed be better?

And I don't understand the help text for it. 'Use non-strict mode
(change in both ChangeLog and other files.' It seems that non-strict
mode allows changes to certain "project files" that are not supposed
to be manually edited, but I can't correlate that to "change in both
ChangeLog and other files". It's also missing the closing parenthesis.

Would this patch make sense?
diff --git a/contrib/gcc-changelog/git_check_commit.py 
b/contrib/gcc-changelog/git_check_commit.py
index 8553c90a96f..d504be9dbde 100755
--- a/contrib/gcc-changelog/git_check_commit.py
+++ b/contrib/gcc-changelog/git_check_commit.py
@@ -28,9 +28,9 @@ parser.add_argument('-g', '--git-path', default='.',
 help='Path to git repository')
 parser.add_argument('-p', '--print-changelog', action='store_true',
 help='Print final changelog entires')
-parser.add_argument('-n', '--allow-non-strict-mode', action='store_true',
-help='Allow non-strict mode (change in both ChangeLog and '
-'other files.')
+parser.add_argument('-n', '--non-strict-mode', action='store_true',
+help='Use non-strict mode (allow changes in ChangeLog and '
+'other automatically updated files.')
 args = parser.parse_args()
 
 retval = 0

Re: [PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

[Segher Boessenkool]

On Tue, May 19, 2020 at 02:41:45PM -0700, Douglas B Rupp wrote:
> 
> On 5/19/20 1:53 PM, Segher Boessenkool wrote:
> >How can altivec not be supported when you use -mcpu=power8?
> >
> For the test in question: builtins-1-be-folded.c:
> 
> The VxWorks header file altivec.h is included by builtins-1.fold.h
> 
> and the error is:
> 
> altivec.h:34:2: error: #error Use the "-maltivec" flag to enable PowerPC 
> AltiVec support
> 
> On VxWorks the kernel has to be configured for altivec regardless of the 
> -mcpu switch, and for unrelated reasons we cannot configure in altivec 
> at this time for our nightly testing.

This is a compile test, so it does not matter at all what the kernel is
doing or not doing.  And the -mcpu=power8 flag should enable altivec.
Apparently it doesn't for you, but why is that?

This shouldn't be fixed by whack-a-mole on individual testcases.


Segher

Re: New mklog script

[Michael Matz]

Hello,

On Tue, 19 May 2020, Jakub Jelinek wrote:

> On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote:
> > This is really a wart in the GNU coding style.  And one reason why I
> > tend to indent such labels by a single space.  It particularly affects
> > things like class definitions where public, private, etc statements
> > often appear in column 0.
> > 
> > IMO, it would be nice to get an official change in the coding style for
> > this, it's really irritating.
> 
> It doesn't have to be just label,
> void
> foo ()
> {
>   ...
> #define X ...
>   ...
> #undef X
>   ...
> }
> does the similar thing for mklog.

That particular one would be a mere bug in mklog then.  diff -p regards 
only members of [[:alpha:]$_] as acceptable start characters of function 
names (i.e. indeed things that can start a C identifier (ignoring details 
like non-base characters) with the '$' extension), of which '#' is none.


Ciao,
Michael.

Re: New mklog script

[Jonathan Wakely via Gcc-patches]

On Tue, 19 May 2020 at 09:26, Jakub Jelinek via Gcc  wrote:
>
> On Tue, May 19, 2020 at 10:11:28AM +0200, Martin Liška wrote:
> > > 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.
> >
> > Let's extend the contrib script.
>
> BTW, concerning mklog, the very common problem is that it doesn't do the
> right thing because the patch doesn't contain enough context to figure out
> what exactly has changed.  If the script would be used together with git
> rather than just on a patch file, perhaps it could handle more, like
> ask git for a patch with unlimited context (like -U1 on patch does).
> The common problems I remember is that e.g. when changing a function comment
> above some function, it is attributed to the previous function rather than
> following, labels in function confusing it:
>  void
>  foo ()
>  {
>...
>  label:
>...
> -  ...
> +  ...
>  }
> will result in (label), GTY markers confusing it
>  struct GTY foobar {
>...
> -  ...
> +  ...
>  };
> resulting in (struct GTY) or so, another common problem is too large
> function names (or more often *.md define_* names); here I'm afraid
> diff doesn't have an argument to not truncate it, or sometimes e.g. changes
> to #define being attributed to something else.
> I know some of the issues can be pretty hard to deal with.

This isn't a complaint, because I don't expect them to work, but
mklog.py (and diff --show-c-function) are useless for libstdc++ code,
they can't handle namespaces and result in nonsense like:

--- a/libstdc++-v3/src/c++11/random.cc
+++ b/libstdc++-v3/src/c++11/random.cc
@@ -97,7 +97,7 @@ namespace std _GLIBCXX_VISIBILITY(default)

and

libstdc++-v3/ChangeLog:

* src/c++11/random.cc (_GLIBCXX_VISIBILITY):
* testsuite/26_numerics/random/random_device/94087.cc: New test.

Re: New mklog script

[Jonathan Wakely via Gcc-patches]

On Tue, 19 May 2020 at 17:13, Joseph Myers wrote:
>
> On Tue, 19 May 2020, Martin Liška wrote:
>
> > On 5/19/20 10:11 AM, Martin Liška wrote:
> > > Can you please share how do you do it? It would be easy to add it.
> >
> > I added the feature via --fill-up-bug-titles option. It uses common
> > request and beatifulsoup packages.
>
> The REST interface is much better to use for extracting bug data than
> screen scraping of HTML output.  Fetch e.g.
> https://gcc.gnu.org/bugzilla/rest.cgi/bug?id=12345_fields=summary
> to get JSON bug data (change or omit include_fields if you want more than
> just the summary).

REST+JSON is probably better for the mklog.py script, but in case this
is useful to anybody else, I get bugzilla info by fetching the XML for
a bug using the URL
https://gcc.gnu.org/bugzilla/show_bug.cgi?ctype=xml= and
applying this stylesheet:


http://www.w3.org/1999/XSL/Transform;
version="1.0">


  
   
  
   
  
  

Re: [PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

[Douglas B Rupp]

On 5/19/20 1:53 PM, Segher Boessenkool wrote:

How can altivec not be supported when you use -mcpu=power8?


For the test in question: builtins-1-be-folded.c:

The VxWorks header file altivec.h is included by builtins-1.fold.h

and the error is:

altivec.h:34:2: error: #error Use the "-maltivec" flag to enable PowerPC 
AltiVec support


On VxWorks the kernel has to be configured for altivec regardless of the 
-mcpu switch, and for unrelated reasons we cannot configure in altivec 
at this time for our nightly testing.

Re: V2 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[H.J. Lu via Gcc-patches]

On Tue, May 19, 2020 at 2:07 PM Uros Bizjak  wrote:
>
> On Tue, May 19, 2020 at 9:58 PM H.J. Lu  wrote:
> >
> > On Mon, May 18, 2020 at 10:56 PM Uros Bizjak  wrote:
> > >
> > > On Tue, May 19, 2020 at 4:17 AM H.J. Lu  wrote:
> > > >
> > > > On Mon, May 18, 2020 at 5:57 AM H.J. Lu  wrote:
> > > > >
> > > > > On Mon, May 18, 2020 at 5:43 AM Uros Bizjak  wrote:
> > > > > >
> > > > > > On Mon, May 18, 2020 at 2:34 PM H.J. Lu  wrote:
> > > > > > >
> > > > > > > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Mon, May 18, 2020 at 1:58 PM H.J. Lu  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, 
> > > > > > > > > Ice Lake
> > > > > > > > > and Tiger Lake processor families.
> > > > > > > > >
> > > > > > > > > OK for master?
> > > > > > > >
> > > > > > > > OK.
> > > > > > >
> > > > > > > I am checking in my patch.
> > > > > > >
> > > > > > > > Please also update cpuinfo.c from libgcc and corresponding
> > > > > > >
> > > > > > > I will take a look to see if we share the same CPU detection code 
> > > > > > > between
> > > > > > > libgcc and config/i386/driver-i386.c.
> > > > > >
> > > > > > I don't think it will bring any benefit, this is mainly one huge
> > > > > > switch statement that maps to different stuff in libgcc and
> > > > > > driver-i386.
> > > > >
> > > > > libgcc and config/i386/driver-i386.c differ even before my patch.
> > > > > I think we can do better.
> > > > >
> > > >
> > > > Move cpuinfo.h from libgcc to common/config/i386 so that get_intel_cpu
> > > > can be shared by libgcc, GCC driver, gcc.target/i386/builtin_target.c
> > > > and libgfortran to detect the specific type of Intel CPU.  Update
> > > > libgfortran to use has_cpu_feature to detect x86 CPU features.
> > > >
> > > > Tested on Linux/x86 and Linux/x86-64.  OK for master?
> > >
> > > Handling only Intel targets and not others is a sure way for patch to
> > > be ignored.
> > >
> >
> > Here is the updated patch to cover AMD CPU.  It also fixes:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95212
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95220
> >
> > OK for master?
>
> Huh... I didn't think the solution will be this messy... I have to
> rethink the approach a bit.

That is what will happen when we have the same info in more than one place
There should only one place for CPU info.

> Can you in the meantime please prepare a simple patch to fix the above
> mentioned PRs and eventually backport it to other release branches? It
> should be simple enough to be committed under obvious rule.
>

Done:

https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546088.html

-- 
H.J.

Re: [PATCH] x86: Add FEATURE_AVX512VP2INTERSECT and update GFNI check

[Uros Bizjak via Gcc-patches]

On Tue, May 19, 2020 at 11:37 PM H.J. Lu  wrote:
>
> Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features
> in libgcc matches enum processor_features in i386-builtins.c.  Update
> GFNI check to support processors with SSE and AVX versions of GFNI.
>
> PR target/95212
> PR target/95220
> * config/i386/cpuinfo.c (get_available_features): Fix
> FEATURE_GFNI check.  Also check FEATURE_AVX512VP2INTERSECT.
> * config/i386/cpuinfo.h (processor_features): Add
> FEATURE_AVX512VP2INTERSECT.

OK for mainline and backports.

Thanks,
Uros.

> ---
>  libgcc/config/i386/cpuinfo.c | 6 --
>  libgcc/config/i386/cpuinfo.h | 1 +
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libgcc/config/i386/cpuinfo.c b/libgcc/config/i386/cpuinfo.c
> index 00322c58622..26c1bdca361 100644
> --- a/libgcc/config/i386/cpuinfo.c
> +++ b/libgcc/config/i386/cpuinfo.c
> @@ -349,6 +349,8 @@ get_available_features (unsigned int ecx, unsigned int 
> edx,
> }
>if (ebx & bit_BMI2)
> set_feature (FEATURE_BMI2);
> +  if (ecx & bit_GFNI)
> +   set_feature (FEATURE_GFNI);
>if (avx512_usable)
> {
>   if (ebx & bit_AVX512F)
> @@ -371,8 +373,6 @@ get_available_features (unsigned int ecx, unsigned int 
> edx,
> set_feature (FEATURE_AVX512VBMI);
>   if (ecx & bit_AVX512VBMI2)
> set_feature (FEATURE_AVX512VBMI2);
> - if (ecx & bit_GFNI)
> -   set_feature (FEATURE_GFNI);
>   if (ecx & bit_VPCLMULQDQ)
> set_feature (FEATURE_VPCLMULQDQ);
>   if (ecx & bit_AVX512VNNI)
> @@ -385,6 +385,8 @@ get_available_features (unsigned int ecx, unsigned int 
> edx,
> set_feature (FEATURE_AVX5124VNNIW);
>   if (edx & bit_AVX5124FMAPS)
> set_feature (FEATURE_AVX5124FMAPS);
> + if (edx & bit_AVX512VP2INTERSECT)
> +   set_feature (FEATURE_AVX512VP2INTERSECT);
>
>   __cpuid_count (7, 1, eax, ebx, ecx, edx);
>   if (eax & bit_AVX512BF16)
> diff --git a/libgcc/config/i386/cpuinfo.h b/libgcc/config/i386/cpuinfo.h
> index 41c4a49a98d..fd6d12a7d68 100644
> --- a/libgcc/config/i386/cpuinfo.h
> +++ b/libgcc/config/i386/cpuinfo.h
> @@ -122,6 +122,7 @@ enum processor_features
>FEATURE_VPCLMULQDQ,
>FEATURE_AVX512VNNI,
>FEATURE_AVX512BITALG,
> +  FEATURE_AVX512VP2INTERSECT,
>FEATURE_AVX512BF16
>  };
>
> --
> 2.26.2
>

[PATCH] Suggest including for bool, true and false

[Mark Wielaard]

Currently gcc suggests to use _Bool instead of bool and doesn't give
any suggestions when true or false are used, but undefined. This patch
makes it so that (for C99 or higher) a fixit hint is emitted to include
.

gcc/c-family/ChangeLog:

* known-headers.cc (get_stdlib_header_for_name): Return
" for "bool", "true" or "false" when STDLIB_C and
flag_isoc99.

gcc/testsuite/ChangeLog:

* gcc.dg/spellcheck-stdbool.c: New test.
---
 gcc/c-family/known-headers.cc |  8 
 gcc/testsuite/gcc.dg/spellcheck-stdbool.c | 17 +
 2 files changed, 25 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/spellcheck-stdbool.c

diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index a21166860c0f..183ce2834afd 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -158,6 +158,14 @@ get_stdlib_header_for_name (const char *name, enum stdlib 
lib)
   for (size_t i = 0; i < num_hints; i++)
 if (strcmp (name, hints[i].name) == 0)
   return hints[i].header[lib];
+
+  /* Only for C99 and higher.  */
+  if (lib == STDLIB_C && flag_isoc99)
+if (strcmp (name, "bool") == 0
+   || strcmp (name, "true") == 0
+   || strcmp (name, "false") == 0)
+  return "";
+
   return NULL;
 }
 
diff --git a/gcc/testsuite/gcc.dg/spellcheck-stdbool.c 
b/gcc/testsuite/gcc.dg/spellcheck-stdbool.c
new file mode 100644
index ..01f12da35cfe
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/spellcheck-stdbool.c
@@ -0,0 +1,17 @@
+/* { dg-options "-std=c99" } */
+/* Missing .  */
+
+bool b; /* { dg-error "unknown type name 'bool'" } */
+/* { dg-message "'bool' is defined in header ''; did you forget to 
'#include '?" "" { target *-*-* } .-1 } */
+
+int test_true (void)
+{
+  return true; /* { dg-error "'true' undeclared" } */
+  /* { dg-message "'true' is defined in header ''; did you forget 
to '#include '?" "" { target *-*-* } .-1 } */
+}
+
+int test_false (void)
+{
+  return false; /* { dg-error "'false' undeclared" } */
+  /* { dg-message "'false' is defined in header ''; did you forget 
to '#include '?" "" { target *-*-* } .-1 } */
+}
-- 
2.20.1

[PATCH] x86: Add FEATURE_AVX512VP2INTERSECT and update GFNI check

[H.J. Lu via Gcc-patches]

Add FEATURE_AVX512VP2INTERSECT to libgcc so that enum processor_features
in libgcc matches enum processor_features in i386-builtins.c.  Update
GFNI check to support processors with SSE and AVX versions of GFNI.

PR target/95212
PR target/95220
* config/i386/cpuinfo.c (get_available_features): Fix
FEATURE_GFNI check.  Also check FEATURE_AVX512VP2INTERSECT.
* config/i386/cpuinfo.h (processor_features): Add
FEATURE_AVX512VP2INTERSECT.
---
 libgcc/config/i386/cpuinfo.c | 6 --
 libgcc/config/i386/cpuinfo.h | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/libgcc/config/i386/cpuinfo.c b/libgcc/config/i386/cpuinfo.c
index 00322c58622..26c1bdca361 100644
--- a/libgcc/config/i386/cpuinfo.c
+++ b/libgcc/config/i386/cpuinfo.c
@@ -349,6 +349,8 @@ get_available_features (unsigned int ecx, unsigned int edx,
}
   if (ebx & bit_BMI2)
set_feature (FEATURE_BMI2);
+  if (ecx & bit_GFNI)
+   set_feature (FEATURE_GFNI);
   if (avx512_usable)
{
  if (ebx & bit_AVX512F)
@@ -371,8 +373,6 @@ get_available_features (unsigned int ecx, unsigned int edx,
set_feature (FEATURE_AVX512VBMI);
  if (ecx & bit_AVX512VBMI2)
set_feature (FEATURE_AVX512VBMI2);
- if (ecx & bit_GFNI)
-   set_feature (FEATURE_GFNI);
  if (ecx & bit_VPCLMULQDQ)
set_feature (FEATURE_VPCLMULQDQ);
  if (ecx & bit_AVX512VNNI)
@@ -385,6 +385,8 @@ get_available_features (unsigned int ecx, unsigned int edx,
set_feature (FEATURE_AVX5124VNNIW);
  if (edx & bit_AVX5124FMAPS)
set_feature (FEATURE_AVX5124FMAPS);
+ if (edx & bit_AVX512VP2INTERSECT)
+   set_feature (FEATURE_AVX512VP2INTERSECT);
 
  __cpuid_count (7, 1, eax, ebx, ecx, edx);
  if (eax & bit_AVX512BF16)
diff --git a/libgcc/config/i386/cpuinfo.h b/libgcc/config/i386/cpuinfo.h
index 41c4a49a98d..fd6d12a7d68 100644
--- a/libgcc/config/i386/cpuinfo.h
+++ b/libgcc/config/i386/cpuinfo.h
@@ -122,6 +122,7 @@ enum processor_features
   FEATURE_VPCLMULQDQ,
   FEATURE_AVX512VNNI,
   FEATURE_AVX512BITALG,
+  FEATURE_AVX512VP2INTERSECT,
   FEATURE_AVX512BF16
 };
 
-- 
2.26.2

Re: V2 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[Uros Bizjak via Gcc-patches]

On Tue, May 19, 2020 at 9:58 PM H.J. Lu  wrote:
>
> On Mon, May 18, 2020 at 10:56 PM Uros Bizjak  wrote:
> >
> > On Tue, May 19, 2020 at 4:17 AM H.J. Lu  wrote:
> > >
> > > On Mon, May 18, 2020 at 5:57 AM H.J. Lu  wrote:
> > > >
> > > > On Mon, May 18, 2020 at 5:43 AM Uros Bizjak  wrote:
> > > > >
> > > > > On Mon, May 18, 2020 at 2:34 PM H.J. Lu  wrote:
> > > > > >
> > > > > > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, May 18, 2020 at 1:58 PM H.J. Lu  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, 
> > > > > > > > Ice Lake
> > > > > > > > and Tiger Lake processor families.
> > > > > > > >
> > > > > > > > OK for master?
> > > > > > >
> > > > > > > OK.
> > > > > >
> > > > > > I am checking in my patch.
> > > > > >
> > > > > > > Please also update cpuinfo.c from libgcc and corresponding
> > > > > >
> > > > > > I will take a look to see if we share the same CPU detection code 
> > > > > > between
> > > > > > libgcc and config/i386/driver-i386.c.
> > > > >
> > > > > I don't think it will bring any benefit, this is mainly one huge
> > > > > switch statement that maps to different stuff in libgcc and
> > > > > driver-i386.
> > > >
> > > > libgcc and config/i386/driver-i386.c differ even before my patch.
> > > > I think we can do better.
> > > >
> > >
> > > Move cpuinfo.h from libgcc to common/config/i386 so that get_intel_cpu
> > > can be shared by libgcc, GCC driver, gcc.target/i386/builtin_target.c
> > > and libgfortran to detect the specific type of Intel CPU.  Update
> > > libgfortran to use has_cpu_feature to detect x86 CPU features.
> > >
> > > Tested on Linux/x86 and Linux/x86-64.  OK for master?
> >
> > Handling only Intel targets and not others is a sure way for patch to
> > be ignored.
> >
>
> Here is the updated patch to cover AMD CPU.  It also fixes:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95212
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95220
>
> OK for master?

Huh... I didn't think the solution will be this messy... I have to
rethink the approach a bit.

Can you in the meantime please prepare a simple patch to fix the above
mentioned PRs and eventually backport it to other release branches? It
should be simple enough to be committed under obvious rule.

Thanks,
Uros.

Re: [PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

[Segher Boessenkool]

Hi!

On Tue, May 19, 2020 at 12:29:40PM -0700, Douglas B Rupp wrote:
> The proposed patch adds some checking for vsx and altivec being 
> supported on several powerpc tests.
> 
> For vxworks, we have to spec particular cpus, so these tests fail when 
> they should show be N/A.

> diff --git gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c 
> gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c
> index 26d10a726e5..f56607a7e4a 100644
> --- gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c
> +++ gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c
> @@ -1,5 +1,6 @@
>  /* { dg-do compile { target { powerpc-*-* } } } */
>  /* { dg-options "-mdejagnu-cpu=power8 -O2 -mfold-gimple" } */
> +/* { dg-require-effective-target powerpc_altivec_ok } */

How can altivec not be supported when you use -mcpu=power8?

> diff --git gcc/testsuite/gcc.target/powerpc/pr70010-4.c 
> gcc/testsuite/gcc.target/powerpc/pr70010-4.c
> index c575cff1b52..87f07adf783 100644
> --- gcc/testsuite/gcc.target/powerpc/pr70010-4.c
> +++ gcc/testsuite/gcc.target/powerpc/pr70010-4.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_vsx_ok } */
>  /* { dg-options "-O2 -mvsx" } */
>  
>  vector int c, a, b;

Does your assembler not support VMX and VSX maybe?

Is there some other configuration problem?

powerpc_vsx_ok does not test if you can use -mvsx.  Instead, it merely
tests if the assembler can handle VSX at all.  If you use GNU binutils
at least, you are supposed to use one that isn't much older than the
GCC you are using (on other platforms the user cannot always easily
get a fully working assembler and linker :-/ )

So what are you seeing without this patch?


Segher

Re: [patch] move value_range_equiv class to own file

[Jeff Law via Gcc-patches]

On Tue, 2020-05-19 at 09:09 +0200, Richard Biener wrote:
> On Mon, May 18, 2020 at 8:13 PM Aldy Hernandez via Gcc-patches
>  wrote:
> > We already moved the value_range class into its own class in the last
> > release.  I think it's time to move the value_range_equiv stuff into its
> > own class, as it's a distraction from the VRP code.
> > 
> > I've moved it to value-range-equiv.*, and gave it a semblance of order,
> > by putting the constructors and setters at the beginning, the dumpers at
> > the bottom, etc.
> > 
> > No functional changes.
> > 
> > OK for mainline?
> 
> Just a note - I dislike spreading all the VRP code across so many files.
> It gets harder and harder to find pieces that once were just in the single
> tree-vrp.c file ...
> 
> But I'm staying out of here as promised.
> 
> It would be much more useful if, for example, the -Warray-bound
> warning were split out from the "old" VRP code and put somewhere
> else (preferably not another walk over the IL but combined with a
> diagnostic pass already performing a EVRP dom walk).
We've been looking at doing it as part of the path isolation code so that we can
(conditionally) turn the out of range references into traps.


> 
> Likewise for the jump-threading bits.
VRP jump threading should just go away.  BUt that's blocked on getting the 
Ranger
bits in which is what all this is leading up to.

jeff

Avoid SCC hashing on unmergeable trees

[Jan Hubicka]

Hi,
this is new incarantion of patch to identify unmergeable tree at streaming out
time rather than streaming in and to avoid pickling them to sccs with with hash
codes.

Building cc1 plus this patch reduces:

[WPA] read 4452927 SCCs of average size 1.986030
[WPA] 8843646 tree bodies read in total
[WPA] tree SCC table: size 524287, 205158 elements, collision ratio: 0.505204
[WPA] tree SCC max chain length 43 (size 1)
[WPA] Compared 947551 SCCs, 780270 collisions (0.823460)
[WPA] Merged 944038 SCCs
[WPA] Merged 5253521 tree bodies
[WPA] Merged 590027 types
...
[WPA] Size of mmap'd section decls: 99229066 bytes
[WPA] Size of mmap'd section function_body: 18398837 bytes
[WPA] Size of mmap'd section refs: 733678 bytes
[WPA] Size of mmap'd section jmpfuncs: 2965981 bytes
[WPA] Size of mmap'd section pureconst: 170248 bytes
[WPA] Size of mmap'd section profile: 17985 bytes
[WPA] Size of mmap'd section symbol_nodes: 3392736 bytes
[WPA] Size of mmap'd section inline: 2693920 bytes
[WPA] Size of mmap'd section icf: 435557 bytes
[WPA] Size of mmap'd section offload_table: 0 bytes
[WPA] Size of mmap'd section lto: 4320 bytes
[WPA] Size of mmap'd section ipa_sra: 651660 bytes

... to ...

[WPA] read 3312246 unshared trees
[WPA] read 1144381 mergeable SCCs of average size 4.833785
[WPA] 8843938 tree bodies read in total
[WPA] tree SCC table: size 524287, 197767 elements, collision ratio: 0.506446
[WPA] tree SCC max chain length 43 (size 1)
[WPA] Compared 946614 SCCs, 775077 collisions (0.818789)
[WPA] Merged 943798 SCCs
[WPA] Merged 5253336 tree bodies
[WPA] Merged 590105 types

[WPA] Size of mmap'd section decls: 81262144 bytes
[WPA] Size of mmap'd section function_body: 14702611 bytes
[WPA] Size of mmap'd section ext_symtab: 0 bytes
[WPA] Size of mmap'd section refs: 733695 bytes
[WPA] Size of mmap'd section jmpfuncs: 2332150 bytes
[WPA] Size of mmap'd section pureconst: 170292 bytes
[WPA] Size of mmap'd section profile: 17986 bytes
[WPA] Size of mmap'd section symbol_nodes: 3393358 bytes
[WPA] Size of mmap'd section inline: 2567939 bytes
[WPA] Size of mmap'd section icf: 435633 bytes
[WPA] Size of mmap'd section lto: 4320 bytes
[WPA] Size of mmap'd section ipa_sra: 651824 bytes

so results in about 22% reduction in global decl stream and 24% reduction on
function bodies stream (which is read mostly by ICF)

Martin, the zstd compression breaks the compression statistics (it works when
GCC is configured for zlib)

At first ltrans I get:

[LTRANS] Size of mmap'd section decls: 3734248 bytes
[LTRANS] Size of mmap'd section function_body: 4895962 bytes

... to ...

[LTRANS] Size of mmap'd section decls: 3479850 bytes
[LTRANS] Size of mmap'd section function_body: 3722935 bytes

So 7% reduction of global stream and 31% reduction of function bodies.

Stream in seems to get about 3% faster and stream out about 5% but it is
close to noise factor of my experiment.  I expect bigger speedups on
Firefox but I did not test it today since my Firefox setup broke again.
GCC is not very good example on the problem with anonymous namespace
types since we do not have so many of them.

Sice of object files in gcc directory is reduced by 11% (because hash
numbers do not compress well I guess).

The patch makes DFS walk to recognize trees that are not merged (anonymous
namespace, local function/variable decls, anonymous types etc).  As discussed
on IRC this is now done during the SCC walk rather than during the hash
computation.  When local tree is discovered we know that SCC components of 
everything that is on
the stack reffers to it and thus is also local. Moreover we mark trees into 
hash set in output block
so if we get a cross edge referring to local tree it gets marked too.

Patch also takes care of avoiding SCC wrappers around some trees. In particular
 1) singleton unmergeable SCCs are now streamed inline in global decl stream
This includes INTEGER_CSTs and IDENTIFIER_NODEs that are shared by different
code than rest of tree merging.
 2) We use LTO_trees instead of LTO_tree_scc to wrap unmergeable SCC components.
It is still necessary to mark them because of forward references.  LTO_trees
has simple header with number of trees and then things are streamed same way
as for LTO_tree_scc. That is tree headers first followed by pickled 
references
so things may point to future.

Of course it is not necessary for LTO_tree_scc to be single component and
streamer out may group more components together, but I decided to not 
snowball
the patch even more
 3) In local streams when lto_output_tree is called and the topmost SCC 
components
turns out to be singleton we stream the tree directly 
instead of LTO_tree_scc, hash code, pickled tree, reference to just 
stremaed tree.

LTO_trees is used to wrap all trees needed to represent tree being streamed.
It would make sense again to use only one LTO_trees rather than one per SCC
but I think this can be done incrementally.

In general 

[PATCH 5/5] or1k: Fixup exception header data encodings

[Stafford Horne via Gcc-patches]

While running glibc tests several *-textrel tests failed showing that
relocations remained against read only sections.  It turned out this was
related to exception headers data encoding being wrong.

By default pointer encoding will always use the DW_EH_PE_absptr format.

This patch uses format DW_EH_PE_pcrel and DW_EH_PE_sdata4.  Optionally
DW_EH_PE_indirect is included for global symbols.  This eliminates the
relocations.

gcc/ChangeLog:

* config/or1k/or1k.h (ASM_PREFERRED_EH_DATA_FORMAT): New macro.
---
 gcc/config/or1k/or1k.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/config/or1k/or1k.h b/gcc/config/or1k/or1k.h
index 0d6fed5f4ca..2fe62f0b90c 100644
--- a/gcc/config/or1k/or1k.h
+++ b/gcc/config/or1k/or1k.h
@@ -408,4 +408,8 @@ do {\
 ((N) < 4 ? HW_TO_GCC_REGNO (25) + (N) : INVALID_REGNUM)
 #define EH_RETURN_STACKADJ_RTX gen_rtx_REG (Pmode, EH_RETURN_REGNUM)
 
+/* Select a format to encode pointers in exception handling data.  */
+#define ASM_PREFERRED_EH_DATA_FORMAT(CODE, GLOBAL) \
+  (((GLOBAL) ? DW_EH_PE_indirect : 0) | DW_EH_PE_pcrel | DW_EH_PE_sdata4)
+
 #endif /* GCC_OR1K_H */
-- 
2.26.2

[PATCH 2/5] or1k: Add builtin define to detect hard float

[Stafford Horne via Gcc-patches]

This is used in libgcc and now glibc to detect when hardware floating
point operations are supported by the target.

gcc/ChangeLog:

* config/or1k/or1k.h (TARGET_CPU_CPP_BUILTINS): Add builtin
  define for __or1k_hard_float__.
---
 gcc/config/or1k/or1k.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/config/or1k/or1k.h b/gcc/config/or1k/or1k.h
index be089900fd4..0d6fed5f4ca 100644
--- a/gcc/config/or1k/or1k.h
+++ b/gcc/config/or1k/or1k.h
@@ -30,6 +30,8 @@
   builtin_define ("__or1k__"); \
   if (TARGET_CMOV) \
builtin_define ("__or1k_cmov__");   \
+  if (TARGET_HARD_FLOAT)   \
+   builtin_define ("__or1k_hard_float__"); \
   builtin_assert ("cpu=or1k"); \
   builtin_assert ("machine=or1k"); \
 }  \
-- 
2.26.2

[PATCH 3/5] or1k: Support for softfloat to emulate hw exceptions

[Stafford Horne via Gcc-patches]

This allows the openrisc softfloat implementation to set exceptions.
This also sets the correct tininess after rounding value to be
consistent with hardware and simulator implementations.

libgcc/ChangeLog:

* config/or1k/sfp-machine.h (FP_RND_NEAREST, FP_RND_ZERO,
FP_RND_PINF, FP_RND_MINF, FP_RND_MASK, FP_EX_OVERFLOW,
FP_EX_UNDERFLOW, FP_EX_INEXACT, FP_EX_INVALID, FP_EX_DIVZERO,
FP_EX_ALL): New constant macros.
(_FP_DECL_EX, FP_ROUNDMODE, FP_INIT_ROUNDMODE,
FP_HANDLE_EXCEPTIONS): New macros.
(_FP_TININESS_AFTER_ROUNDING): Change to 1.
---
 libgcc/config/or1k/sfp-machine.h | 41 +++-
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/libgcc/config/or1k/sfp-machine.h b/libgcc/config/or1k/sfp-machine.h
index 5da9e84990d..eebe5b0578e 100644
--- a/libgcc/config/or1k/sfp-machine.h
+++ b/libgcc/config/or1k/sfp-machine.h
@@ -41,12 +41,51 @@
 R##_c = FP_CLS_NAN;\
   } while (0)
 
+/* Handle getting and setting rounding mode for soft fp operations.  */
+
+#define FP_RND_NEAREST (0x0 << 1)
+#define FP_RND_ZERO(0x1 << 1)
+#define FP_RND_PINF(0x2 << 1)
+#define FP_RND_MINF(0x3 << 1)
+#define FP_RND_MASK(0x3 << 1)
+
+#define FP_EX_OVERFLOW 1 << 3
+#define FP_EX_UNDERFLOW1 << 4
+#define FP_EX_INEXACT  1 << 8
+#define FP_EX_INVALID  1 << 9
+#define FP_EX_DIVZERO  1 << 11
+#define FP_EX_ALL \
+   (FP_EX_INVALID | FP_EX_DIVZERO | FP_EX_OVERFLOW | FP_EX_UNDERFLOW \
+| FP_EX_INEXACT)
+
+#define _FP_DECL_EX \
+  unsigned int _fpcsr __attribute__ ((unused)) = FP_RND_NEAREST
+
+#define FP_ROUNDMODE (_fpcsr & FP_RND_MASK)
+
+#ifdef __or1k_hard_float__
+#define FP_INIT_ROUNDMODE  \
+do {   \
+  __asm__ volatile ("l.mfspr %0,r0,20" : "=r" (_fpcsr));   \
+} while (0)
+
+#define FP_HANDLE_EXCEPTIONS   \
+do {   \
+  if (__builtin_expect (_fex, 0))  \
+{  \
+  _fpcsr &= ~FP_EX_ALL;\
+  _fpcsr |= _fex;  \
+  __asm__ volatile ("l.mtspr r0,%0,20" : : "r" (_fpcsr));  \
+}  \
+} while (0)
+#endif
+
 #define__LITTLE_ENDIAN 1234
 #define__BIG_ENDIAN4321
 
 #define __BYTE_ORDER __BIG_ENDIAN
 
-#define _FP_TININESS_AFTER_ROUNDING 0
+#define _FP_TININESS_AFTER_ROUNDING 1
 
 /* Define ALIASNAME as a strong alias for NAME.  */
 # define strong_alias(name, aliasname) _strong_alias(name, aliasname)
-- 
2.26.2

[PATCH 1/5] or1k: Implement profile hook calling _mcount

[Stafford Horne via Gcc-patches]

Defining this to not abort as found when working on running tests in
the glibc test suite.

We implement this with a call to _mcount with no arguments.  The required
return address's will be pulled from the stack.  Passing the LR (r9) as
an argument had problems as sometimes r9 is clobbered by the GOT logic
in the prologue before the call to _mcount.

gcc/ChangeLog:

* config/or1k/or1k.h (NO_PROFILE_COUNTERS): Define as 1.
(PROFILE_HOOK): Define to call _mcount.
(FUNCTION_PROFILER): Change from abort to no-op.
---
 gcc/config/or1k/or1k.h | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/gcc/config/or1k/or1k.h b/gcc/config/or1k/or1k.h
index 23db771d8fb..be089900fd4 100644
--- a/gcc/config/or1k/or1k.h
+++ b/gcc/config/or1k/or1k.h
@@ -379,8 +379,19 @@ do {\
 /* Always pass the SYMBOL_REF for direct calls to the expanders.  */
 #define NO_FUNCTION_CSE 1
 
-/* Profiling */
-#define FUNCTION_PROFILER(FILE,LABELNO) (abort (), 0)
+#define NO_PROFILE_COUNTERS 1
+
+/* Emit rtl for profiling.  Output assembler code to call "_mcount" for
+   profiling a function entry.  */
+#define PROFILE_HOOK(LABEL)\
+  {\
+rtx fun;   \
+fun = gen_rtx_SYMBOL_REF (Pmode, "_mcount");   \
+emit_library_call (fun, LCT_NORMAL, VOIDmode); \
+  }
+
+/* All the work is done in PROFILE_HOOK, but this is still required.  */
+#define FUNCTION_PROFILER(STREAM, LABELNO) do { } while (0)
 
 /* Dwarf 2 Support */
 #define DWARF2_DEBUGGING_INFO 1
-- 
2.26.2

[PATCH 0/5] OpenRISC GCC Fixes for Glibc Support

[Stafford Horne via Gcc-patches]

Hello,

I am currently working on the glibc port for OpenRISC.  This is a series of
patches that fix issues and add features that were missing in GCC causing glibc
testsuite failures.

Pretty much all of these changes are just adding macros.

These changes have been tested via the glibc test suite.

-Stafford

Stafford Horne (5):
  or1k: Implement profile hook calling _mcount
  or1k: Add builtin define to detect hard float
  or1k: Support for softfloat to emulate hw exceptions
  or1k: Add note to indicate execstack
  or1k: Fixup exception header data encodings

 gcc/config/or1k/linux.h  |  2 ++
 gcc/config/or1k/or1k.h   | 21 ++--
 libgcc/config/or1k/sfp-machine.h | 41 +++-
 3 files changed, 61 insertions(+), 3 deletions(-)

-- 
2.26.2

[PATCH 4/5] or1k: Add note to indicate execstack

[Stafford Horne via Gcc-patches]

Define TARGET_ASM_FILE_END as file_end_indicate_exec_stack to allow
generation of the ".note.GNU-stack" section note.  This allows binutils
to properly set PT_GNU_STACK in the program header.

This fixes a glibc execstack testsuite test failure found while working
on the OpenRISC glibc port.

gcc/ChangeLog:

* config/or1k/linux.h (TARGET_ASM_FILE_END): Define macro.
---
 gcc/config/or1k/linux.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/config/or1k/linux.h b/gcc/config/or1k/linux.h
index 21cef067dda..8693e884e2a 100644
--- a/gcc/config/or1k/linux.h
+++ b/gcc/config/or1k/linux.h
@@ -42,4 +42,6 @@
  %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}}} \
%{static-pie:-Bstatic -pie --no-dynamic-linker -z text}"
 
+#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
+
 #endif /* GCC_OR1K_LINUX_H */
-- 
2.26.2

[c++] alias template instantiation

[Nathan Sidwell]

Here's a small cleanup discovered by modules.  The alias instantiation 
machinery would setup template_info, and then sometime later overwrite 
that with equivalent info.  The template info, once set, is logically 
immutable.  Let's just not do that.


pushed to master

nathan
--
Nathan Sidwell
2020-05-19  Nathan Sidwell  

	* pt.c (lookup_template_class_1): Do not reinit template_info of an
	alias here.

diff --git i/gcc/cp/pt.c w/gcc/cp/pt.c
index 4d9651acee6..c17a038c6d0 100644
--- i/gcc/cp/pt.c
+++ w/gcc/cp/pt.c
@@ -10062,8 +10062,21 @@ lookup_template_class_1 (tree d1, tree arglist, tree in_decl, tree context,
 	}
 	}
 
-  // Build template info for the new specialization.
-  SET_TYPE_TEMPLATE_INFO (t, build_template_info (found, arglist));
+  /* Build template info for the new specialization.  This can
+	 overwrite the existing TEMPLATE_INFO for T (that points to
+	 its instantiated TEMPLATE_DECL), with this one that points to
+	 the most general template, but that's what we want.  */
+
+  if (TYPE_ALIAS_P (t))
+	{
+	  /* This should already have been constructed during
+	 instantiation of the alias decl.  */
+	  tree ti = DECL_TEMPLATE_INFO (TYPE_NAME (t));
+	  gcc_checking_assert (template_args_equal (TI_ARGS (ti), arglist)
+			   && TI_TEMPLATE (ti) == found);
+	}
+  else
+	SET_TYPE_TEMPLATE_INFO (t, build_template_info (found, arglist));
 
   elt.spec = t;
   slot = type_specializations->find_slot_with_hash (, hash, INSERT);

Re: [patch] move array bounds checking into its own file

[Jeff Law via Gcc-patches]

On Tue, 2020-05-19 at 09:10 +0200, Richard Biener wrote:
> On Mon, May 18, 2020 at 8:21 PM Aldy Hernandez via Gcc-patches
>  wrote:
> > As a follow-up to the patch moving array bounds checking into its own
> > class, this moves the class into its own files.  As I've mentioned
> > previously, having it in tree-vrp just pollutes the file with unrelated
> > stuff.
> > 
> > Jeff, I know you've mentioned you'd like to move the array bounds
> > checking to the path isolation pass at some point.  Would the current
> > approach work for you?  I'm ok, inasmuch as it's gone from tree-vrp.c,
> > the file is bloated enough as it is.
> > wc -l gcc/tree-vrp.c
> 5586 gcc/tree-vrp.c
> > wc -l gcc/vr-values.c
> 4361 gcc/vr-values.c
> > wc -l gcc/range-op.cc
> 3113 gcc/range-op.cc
> 
> I wouldn't call this bloated.  Moving to separate files is hardly
> a good thing on its own.
But there's no good reason to have these bits in VRP to begin with.  The only
reason they're there is they get more accurate data because of the ASSERT_EXPRs
and PHI nodes due to additional definitions.

Jeff

[preprocessor] Some cleanups

[Nathan Sidwell]

I've committed this bunch of cleanups to libcpp.

This fixes a bunch of poorly formatted decls, marks some getters as 
PURE, deletes some C-relevant bool hackery, and finally uses a passed-in 
location rather than deducing a closely-related but not necessarily the 
same location.


nathan

--
Nathan Sidwell
2020-05-18  Nathan Sidwell  

	* include/cpplib.h (cpp_get_otions, cpp_get_callbacks)
	(cpp_get_deps): Mark as PURE.
	* include/line-map.h (get_combined_adhoc_loc)
	(get_location_from_adhoc_loc, get_pure_location): Reformat decls.
	* internal.h (struct lexer_state): Clarify comment.
	* system.h: Remove now-unneeded bool hackery.
	* files.c (_cpp_find_file): Store LOC not highest_location.

diff --git i/libcpp/files.c w/libcpp/files.c
index 260e787c329..f25b58dc394 100644
--- i/libcpp/files.c
+++ w/libcpp/files.c
@@ -635,7 +635,7 @@ _cpp_find_file (cpp_reader *pfile, const char *fname, cpp_dir *start_dir,
   entry = new_file_hash_entry (pfile);
   entry->next = (struct cpp_file_hash_entry *) *hash_slot;
   entry->start_dir = start_dir;
-  entry->location = pfile->line_table->highest_location;
+  entry->location = loc;
   entry->u.file = file;
   *hash_slot = (void *) entry;
 
@@ -648,7 +648,7 @@ _cpp_find_file (cpp_reader *pfile, const char *fname, cpp_dir *start_dir,
   entry = new_file_hash_entry (pfile);
   entry->next = (struct cpp_file_hash_entry *) *hash_slot;
   entry->start_dir = pfile->bracket_include;
-  entry->location = pfile->line_table->highest_location;
+  entry->location = loc;
   entry->u.file = file;
   *hash_slot = (void *) entry;
 }
@@ -659,7 +659,7 @@ _cpp_find_file (cpp_reader *pfile, const char *fname, cpp_dir *start_dir,
   entry = new_file_hash_entry (pfile);
   entry->next = (struct cpp_file_hash_entry *) *hash_slot;
   entry->start_dir = pfile->quote_include;
-  entry->location = pfile->line_table->highest_location;
+  entry->location = loc;
   entry->u.file = file;
   *hash_slot = (void *) entry;
 }
diff --git i/libcpp/include/cpplib.h w/libcpp/include/cpplib.h
index 7f47402f9b9..544735a51af 100644
--- i/libcpp/include/cpplib.h
+++ w/libcpp/include/cpplib.h
@@ -969,10 +969,10 @@ extern void cpp_set_include_chains (cpp_reader *, cpp_dir *, cpp_dir *, int);
call cpp_finish on that reader.  You can either edit the callbacks
through the pointer returned from cpp_get_callbacks, or set them
with cpp_set_callbacks.  */
-extern cpp_options *cpp_get_options (cpp_reader *);
-extern cpp_callbacks *cpp_get_callbacks (cpp_reader *);
+extern cpp_options *cpp_get_options (cpp_reader *) ATTRIBUTE_PURE;
+extern cpp_callbacks *cpp_get_callbacks (cpp_reader *) ATTRIBUTE_PURE;
 extern void cpp_set_callbacks (cpp_reader *, cpp_callbacks *);
-extern class mkdeps *cpp_get_deps (cpp_reader *);
+extern class mkdeps *cpp_get_deps (cpp_reader *) ATTRIBUTE_PURE;
 
 /* This function reads the file, but does not start preprocessing.  It
returns the name of the original file; this is the same as the
diff --git i/libcpp/include/line-map.h w/libcpp/include/line-map.h
index dbbc13762e3..217f916fc35 100644
--- i/libcpp/include/line-map.h
+++ w/libcpp/include/line-map.h
@@ -1024,13 +1024,11 @@ LINEMAPS_LAST_ALLOCATED_MACRO_MAP (const line_maps *set)
   return (line_map_macro *)LINEMAPS_LAST_ALLOCATED_MAP (set, true);
 }
 
-extern location_t get_combined_adhoc_loc (class line_maps *,
-	   location_t,
-	   source_range,
-	   void *);
+extern location_t get_combined_adhoc_loc (line_maps *, location_t,
+	  source_range, void *);
 extern void *get_data_from_adhoc_loc (const line_maps *, location_t);
 extern location_t get_location_from_adhoc_loc (const line_maps *,
-		location_t);
+	   location_t);
 
 extern source_range get_range_from_loc (line_maps *set, location_t loc);
 
@@ -1043,8 +1041,7 @@ pure_location_p (line_maps *set, location_t loc);
 /* Given location LOC within SET, strip away any packed range information
or ad-hoc information.  */
 
-extern location_t get_pure_location (line_maps *set,
-	  location_t loc);
+extern location_t get_pure_location (line_maps *set, location_t loc);
 
 /* Combine LOC and BLOCK, giving a combined adhoc location.  */
 
diff --git i/libcpp/internal.h w/libcpp/internal.h
index 11b6469dccd..765ff9d8206 100644
--- i/libcpp/internal.h
+++ w/libcpp/internal.h
@@ -275,7 +275,7 @@ struct lexer_state
   /* Nonzero to skip evaluating part of an expression.  */
   unsigned int skip_eval;
 
-  /* Nonzero when handling a deferred pragma.  */
+  /* Nonzero when tokenizing a deferred pragma.  */
   unsigned char in_deferred_pragma;
 
   /* Nonzero if the deferred pragma being handled allows macro expansion.  */
diff --git i/libcpp/system.h w/libcpp/system.h
index 37fc262d3b0..0a0629d557f 100644
--- i/libcpp/system.h
+++ w/libcpp/system.h
@@ -422,26 +422,6 @@ extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
 #define 

V2 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[H.J. Lu via Gcc-patches]

On Mon, May 18, 2020 at 10:56 PM Uros Bizjak  wrote:
>
> On Tue, May 19, 2020 at 4:17 AM H.J. Lu  wrote:
> >
> > On Mon, May 18, 2020 at 5:57 AM H.J. Lu  wrote:
> > >
> > > On Mon, May 18, 2020 at 5:43 AM Uros Bizjak  wrote:
> > > >
> > > > On Mon, May 18, 2020 at 2:34 PM H.J. Lu  wrote:
> > > > >
> > > > > On Mon, May 18, 2020 at 5:18 AM Uros Bizjak  wrote:
> > > > > >
> > > > > > On Mon, May 18, 2020 at 1:58 PM H.J. Lu  wrote:
> > > > > > >
> > > > > > > Add cpu model numbers for Intel Airmont, Tremont, Comet Lake, Ice 
> > > > > > > Lake
> > > > > > > and Tiger Lake processor families.
> > > > > > >
> > > > > > > OK for master?
> > > > > >
> > > > > > OK.
> > > > >
> > > > > I am checking in my patch.
> > > > >
> > > > > > Please also update cpuinfo.c from libgcc and corresponding
> > > > >
> > > > > I will take a look to see if we share the same CPU detection code 
> > > > > between
> > > > > libgcc and config/i386/driver-i386.c.
> > > >
> > > > I don't think it will bring any benefit, this is mainly one huge
> > > > switch statement that maps to different stuff in libgcc and
> > > > driver-i386.
> > >
> > > libgcc and config/i386/driver-i386.c differ even before my patch.
> > > I think we can do better.
> > >
> >
> > Move cpuinfo.h from libgcc to common/config/i386 so that get_intel_cpu
> > can be shared by libgcc, GCC driver, gcc.target/i386/builtin_target.c
> > and libgfortran to detect the specific type of Intel CPU.  Update
> > libgfortran to use has_cpu_feature to detect x86 CPU features.
> >
> > Tested on Linux/x86 and Linux/x86-64.  OK for master?
>
> Handling only Intel targets and not others is a sure way for patch to
> be ignored.
>

Here is the updated patch to cover AMD CPU.  It also fixes:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95220

OK for master?

Thanks.

-- 
H.J.
From 113c797d59102d400b3a7342192f68b789bba0de Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 18 May 2020 05:58:41 -0700
Subject: [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

Move cpuinfo.h from libgcc to common/config/i386 so that get_intel_cpu
can be shared by libgcc, GCC driver, gcc.target/i386/builtin_target.c
and libgfortran to detect the specific type of Intel and AMD CPUs.  Use
the same enum processor_features in libgcc and x86 backend.  Add static
assert to x86 backend to verify that libgcc and x86 backend are in sync.

Update processor feature check in in libgcc:

1. Update FEATURE_GFNI check to support SSE, AVX and AVX512 versions of
GFNI.
2. Add missing FEATURE_AVX512VP2INTERSECT.
3. Add FEATURE_XSAVEOPT, FEATURE_CLWB and FEATURE_CLZERO for get_amd_cpu.
4. Always set __cpu_features2 for has_cpu_feature.

Update libgfortran to use has_cpu_feature to detect x86 CPU features.

gcc/

	PR target/95212
	PR target/95220
	* common/config/i386/cpuinfo.h: Moved from libgcc/config/i386.
	(processor_features): Add FEATURE_AVX512VP2INTERSECT,
	FEATURE_XSAVEOPT, FEATURE_CLWB and FEATURE_CLZERO.
	(CHECK___builtin_cpu_is): New.  Defined as empty if not defined.
	(get_amd_cpu): Moved from libgcc/config/i386/cpuinfo.c.  Add
	arguments for BMI, AVX2, XOP, XSAVEOPT, CLWB and CLZERO.  Use
	CHECK___builtin_cpu_is.  Return AMD CPU name.
	(get_intel_cpu): Moved from libgcc/config/i386/cpuinfo.c.  Add
	an argument for AVX512VNNI.  Use CHECK___builtin_cpu_is.  Return
	Intel CPU name.
	(has_cpu_feature): New function.
	* config/i386/driver-i386.c: Include
	"common/config/i386/cpuinfo.h".
	(host_detect_local_cpu): Call get_amd_cpu to get AMD CPU name.
	Call get_intel_cpu to get Intel CPU name.
	* config/i386/i386-builtins.c: Include
	"common/config/i386/cpuinfo.h".
	(processor_features): Removed.  Replace F_XXX with FEATURE_XXX.
	(isa_names_table): Add xsaveopt, clwb and clzero.
	(CHECK_processor_vendor, CHECK_processor_types,
	CHECK_processor_subtypes): New.  Add static assert to x86
	backend to verify that libgcc and x86 backend are in sync.

gcc/testsuite/

	PR target/95212
	PR target/95220
	* gcc.target/i386/builtin_target.c: Include  and
	../../../common/config/i386/cpuinfo.h.
	(CHECK___builtin_cpu_is): New.
	(inline): New.  Defined as empty.
	(check_amd_cpu_model): Removed.
	(check_intel_cpu_model): Likewise,
	(check_detailed): Call get_amd_cpu instead of check_amd_cpu_model.
	Call get_intel_cpu instead of check_intel_cpu_model.

libgcc/

	PR target/95212
	PR target/95220
	* config/i386/cpuinfo.h: Moved to ... gcc/common/config/i386.
	* config/i386/cpuinfo.c: Include "common/config/i386/cpuinfo.h".
	(__cpu_features2): Make it static in libgcc_s.so.1.
	(get_amd_cpu): Moved to ... gcc/common/config/i386/cpuinfo.h.
	(get_intel_cpu): Moved to ... gcc/common/config/i386/cpuinfo.h.
	(get_available_features): Fix FEATURE_GFNI check.  Also check
	FEATURE_AVX512VP2INTERSECT, FEATURE_XSAVEOPT, FEATURE_CLWB and
	FEATURE_CLZERO.  Always set __cpu_features2.
	(__cpu_indicator_init): Call get_available_features before
	calling get_amd_cpu.  Pass has_cpu_feature 

Re: [PATCH] handle std::byte in -Wclass-memaccess (PR 94923)

[Martin Sebor via Gcc-patches]

On 5/18/20 3:04 PM, Jason Merrill wrote:

On 5/8/20 2:16 PM, Martin Sebor wrote:

-Wclass-memaccess is suppressed for write accesses to trivially
copyable but otherwise nontrivial class types by character types
but the suppression neglects to consider the equivalent accesses
by std::byte.  The attached patch extends the same privilege also
to it.

I couldn't find a utility function to check if a type is one of
the four "special" byte types so I added one.  If there already
isn't one hiding somewhere and this type of a query is done in
other places maybe the function should be moved to cp-tree.h.

Rather than adding a new test I extended the existing one that
has all the infrastructure in place to comprehensively exercise
this (maybe even overly so).



+/* Returns true if TYPE is a character type of std::byte.  */


"or"

Let's name the new function is_byte_access_type to clarify that it 
doesn't just mean std::byte.


Let's use the new function in build_cplus_array_type in the initializer 
of "typeless_storage".


OK with those changes.


I (finally) committed it in r11-499.

Martin

[PATCH] Tweak some powerpc tests for altivec_ok and vsx_ok

[Douglas B Rupp]

Greetings,

The proposed patch adds some checking for vsx and altivec being 
supported on several powerpc tests.


For vxworks, we have to spec particular cpus, so these tests fail when 
they should show be N/A.


--Douglas Rupp, AdaCore



diff --git gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c
index 26d10a726e5..f56607a7e4a 100644
--- gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c
+++ gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c
@@ -1,5 +1,6 @@
 /* { dg-do compile { target { powerpc-*-* } } } */
 /* { dg-options "-mdejagnu-cpu=power8 -O2 -mfold-gimple" } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
 
 /* Based on builtins-1-le.c ; ensure that the power8 builtins are accepted by
the compiler, at O2 with gimple folding enabled.  */
diff --git gcc/testsuite/gcc.target/powerpc/builtins-1.c gcc/testsuite/gcc.target/powerpc/builtins-1.c
index 73f8fb54cff..3879990f253 100644
--- gcc/testsuite/gcc.target/powerpc/builtins-1.c
+++ gcc/testsuite/gcc.target/powerpc/builtins-1.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-options "-mdejagnu-cpu=power8 -O0 -mno-fold-gimple -dp" } */
 /* { dg-prune-output "gimple folding of rs6000 builtins has been disabled." } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
 
 #include 
 
diff --git gcc/testsuite/gcc.target/powerpc/builtins-5.c gcc/testsuite/gcc.target/powerpc/builtins-5.c
index c5f5c31b45f..0d167dd002b 100644
--- gcc/testsuite/gcc.target/powerpc/builtins-5.c
+++ gcc/testsuite/gcc.target/powerpc/builtins-5.c
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-options "-mdejagnu-cpu=power8 -O0 -mno-fold-gimple -dp" } */
 /* { dg-prune-output "gimple folding of rs6000 builtins has been disabled." } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
 
 #include 
 
diff --git gcc/testsuite/gcc.target/powerpc/pr70010-4.c gcc/testsuite/gcc.target/powerpc/pr70010-4.c
index c575cff1b52..87f07adf783 100644
--- gcc/testsuite/gcc.target/powerpc/pr70010-4.c
+++ gcc/testsuite/gcc.target/powerpc/pr70010-4.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-O2 -mvsx" } */
 
 vector int c, a, b;
diff --git gcc/testsuite/gcc.target/powerpc/pr70010.c gcc/testsuite/gcc.target/powerpc/pr70010.c
index 679034fae43..62a4cd72bf1 100644
--- gcc/testsuite/gcc.target/powerpc/pr70010.c
+++ gcc/testsuite/gcc.target/powerpc/pr70010.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-O2 -finline-functions -Wno-psabi -mvsx" } */
 /* { dg-final { scan-assembler {\mbl \.?vadd_no_vsx\M} } } */
 
diff --git gcc/testsuite/gcc.target/powerpc/pr83926.c gcc/testsuite/gcc.target/powerpc/pr83926.c
index 2490e1d48ba..8681cd51864 100644
--- gcc/testsuite/gcc.target/powerpc/pr83926.c
+++ gcc/testsuite/gcc.target/powerpc/pr83926.c
@@ -1,6 +1,8 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-options "-O2 -mdejagnu-cpu=power8 -mno-fold-gimple" } */
 /* { dg-prune-output "gimple folding of rs6000 builtins has been disabled." } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
 
 __attribute__ ((altivec(vector__))) long long
 sdiv (__attribute__ ((altivec(vector__))) long long a,
2020-05-19  Douglas B Rupp  

testsuite/
* gcc.target/powerpc/builtins-1-be-folded.c: Check powerpc_altivec_ok.
* gcc.target/powerpc/builtins-1.c: Likewise.
* gcc.target/powerpc/builtins-5.c: Likewise.
* gcc.target/powerpc/pr70010-4.c: Check powerpc_vsx_ok.
* gcc.target/powerpc/pr70010.c: Likewise.
* gcc.target/powerpc/pr83926.c: Check powerpc_{alitvec,vsx}_ok.
:

[PATCH] Add -fuse-ld= to specify an arbitrary executable as the linker

[Fangrui Song via Gcc-patches]

On 2020-04-06, Martin Liška wrote:

On 4/6/20 12:32 AM, Fangrui Song wrote:

On 2020-03-11, Martin Liška wrote:

On 2/10/20 1:02 AM, Fangrui Song via gcc-patches wrote:

Hello.

Thank you for the patch. You haven't received a review because we are right now
in stage4 of the development cycle:
https://gcc.gnu.org/develop.html#stage4


Thanks for the review!
According to https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543028.html "GCC 
10.0 Status Report (2020-04-01)",
I guess GCC is not open for a new development cycle yet.


Yes, it's not opened, but I expect to be opened in 3 weeks from now.


I will just answer a few questions instead of uploading a new patch.


Sure, but don't hesitate to send a patch. It can sit here and wait for next 
stage1 ;)


Thank you! I got around and updated the patch.

Tested locally with -fuse-ld=~/Stable/bin/ld.lld and 
-fuse-ld=~/Dev/binutils-gdb/Debug/ld/ld-new




Anyway, I'm going to provide a review (even though I'm not maintainer of that).

Can you please describe your test-case why you need such option? When using
a different ld, I typically export PATH=/path/to/binutils and then run configure
and make.


I would hope -fuse-ld=ld.bfd and -fuse-ld=ld.gold were used instead of
-fuse-ld=bfd and -fuse-ld=gold, then it would be more natural to have
-fuse-ld=/abs/path/to/ld . https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470


Well, problem with that is that the option values are used and we want to 
preserve
backward compatibility of options (if possible). I mean we can't just rename
-fuse-ld=bfd to -fuse-ld=ld.bfd.



-fuse-ld=bfd, -fuse-ld=gold and -fuse-ld=lld are hard-coded in numerous
places. It is too late to change that.

One idea is to make

-fuse-ld=bfd
-fuse-ld=gold
-fuse-ld=lld

special. For any other value, e.g. -fuse-ld=foo or -fuse-ld=/abs/path, just 
searches the
executable named "foo" (instead of "ld.foo") or /abs/path .


Yes, that seems feasible to me.



Does the scheme sound good? If it is agreed, I can make a similar change to 
clang.


Yes, please send a patch and we can make another round of review process.

Thanks,
Martin




I noticed not ideal error message:

$ gcc -fuse-ld=pes /tmp/foo.c
collect2: fatal error: cannot find ‘ld’
compilation terminated.

while clang prints:

$clang -fuse-ld=pes /tmp/foo.c
clang-9.0: error: invalid linker name in argument '-fuse-ld=pes'

The rest of the patch is comment inline...


Thanks for all the comments.


PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c (driver_handle_option): Likewise.
* collect2.c (main): Likewise.
---
 gcc/ChangeLog   |  8 ++
 gcc/collect2.c  | 67 -
 gcc/common.opt  | 14 ++
 gcc/doc/invoke.texi | 15 +++---
 gcc/gcc.c   | 14 --
 gcc/opts.c  |  4 +--
 6 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index feb2d066d0b..6bcec12d841 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-09  Fangrui Song  
+
+    PR driver/93645
+    * common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
+    * opts.c (common_handle_option): Handle OPT_fuse_ld_.
+    * gcc.c (driver_handle_option): Likewise.
+    * collect2.c (main): Likewise.
+
 2020-02-09  Uroš Bizjak  
 * recog.c: Move pass_split_before_sched2 code in front of
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629141c..a3ef525a93b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -859,18 +859,12 @@ main (int argc, char **argv)
 {
   USE_DEFAULT_LD,
   USE_PLUGIN_LD,
-  USE_GOLD_LD,
-  USE_BFD_LD,
-  USE_LLD_LD,
-  USE_LD_MAX
+  USE_LD
 } selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
 {
   "ld",
-  PLUGIN_LD_SUFFIX,
-  "ld.gold",
-  "ld.bfd",
-  "ld.lld"
+  PLUGIN_LD_SUFFIX
 };
   static const char *const real_ld_suffix = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
@@ -882,7 +876,7 @@ main (int argc, char **argv)
   static const char *const strip_suffix = "strip";
   static const char *const gstrip_suffix = "gstrip";
-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
 #ifdef CROSS_DIRECTORY_STRUCTURE
   /* If we look for a program in the compiler directories, we just use
  the short name, since these directories are already system-specific.
@@ -924,6 +918,7 @@ main (int argc, char **argv)
   const char **ld1;
   bool use_plugin = false;
   bool use_collect_ld = false;
+  const char *use_ld = NULL;
   /* The kinds of symbols we will have to consider when scanning the
  outcome of a first pass link.  This is ALL to start with, then might
@@ -948,7 +943,7 @@ main (int argc, char **argv)
 #endif
   int i;
-  

Re: New mklog script

[Martin Liška]

On 5/19/20 5:53 PM, Joseph Myers wrote:

On Tue, 19 May 2020, Martin Liška wrote:


On 5/19/20 10:11 AM, Martin Liška wrote:

Can you please share how do you do it? It would be easy to add it.


I added the feature via --fill-up-bug-titles option. It uses common
request and beatifulsoup packages.


The REST interface is much better to use for extracting bug data than
screen scraping of HTML output.  Fetch e.g.
https://gcc.gnu.org/bugzilla/rest.cgi/bug?id=12345_fields=summary
to get JSON bug data (change or omit include_fields if you want more than
just the summary).



You are right, there's a patch I'm going to install.

Martin

>From b5a89069a074aff0ae94176c676eda069ff0a1c3 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 19 May 2020 21:14:36 +0200
Subject: [PATCH] Use REST API for bug titles in mklog.

contrib/ChangeLog:

2020-05-19  Martin Liska  

	* mklog.py: Use REST API for bug title downloading.
---
 contrib/mklog.py | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index 45559afbe6b..b27fad0ca2e 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -31,8 +31,6 @@ import os
 import re
 import sys
 
-import bs4
-
 import requests
 
 from unidiff import PatchSet
@@ -46,6 +44,8 @@ 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'<[^<>]*>')
+bugzilla_url = 'https://gcc.gnu.org/bugzilla/rest.cgi/bug?id=%s;' \
+   'include_fields=summary'
 
 function_extensions = set(['.c', '.cpp', '.C', '.cc', '.h', '.inc', '.def'])
 
@@ -106,18 +106,16 @@ def sort_changelog_files(changed_file):
 
 
 def get_pr_titles(prs):
-if not prs:
-return ''
-
 output = ''
 for pr in prs:
 id = pr.split('/')[-1]
-r = requests.get('https://gcc.gnu.org/PR%s' % id)
-html = bs4.BeautifulSoup(r.text, features='lxml')
-title = html.title.text
-title = title[title.find('–') + 1:].strip()
-output += '%s - %s\n' % (pr, title)
-output += '\n'
+r = requests.get(bugzilla_url % id)
+bugs = r.json()['bugs']
+if len(bugs) == 1:
+output += '%s - %s\n' % (pr, bugs[0]['summary'])
+print(output)
+if output:
+output += '\n'
 return output
 
 
-- 
2.26.2

Re: [PATCH] Extend std::copy/std::copy_n char* overload to deque iterator

[François Dumont via Gcc-patches]

No chance to review this ?


On 07/05/20 9:12 am, François Dumont wrote:
    This patch purpose is to make sure that existing 
std::copy/std::copy_n overloads for char* will also be used for 
std::deque iterators when dealing with istreambuf_iterator. It 
also make sure that it still works when _GLIBCXX_DEBUG is activated.


    * include/bits/stl_algo.h (__copy_n_a): Move to ...
    * include/bits/stl_algobase.h (__copy_n_a): ...here. Add __strict
    parameter.
    (__niter_base(const _Safe_iterator<_Ite, _Seq,
    random_access_iterator_tag>&)): New declaration.
    (__copy_move_a2(istreambuf_iterator<>, istreambuf_iterator<>,
    _Deque_iterator<>)): New declaration.
    (__copy_n_a(istreambuf_iterator<>, _Size, _Deque_iterator<>, bool)):
    New declaration.
    * include/bits/deque.tcc
    (__copy_move_a2(istreambuf_iterator<>, istreambuf_iterator<>,
    _Deque_iterator<>)): Add definition.
    (__copy_n_a(istreambuf_iterator<>, _Size, _Deque_iterator<>, bool)):
    Add definition.
    * include/bits/streambuf_iterator.h
    (__copy_n_a(istreambuf_iterator<>, _Size, _CharT*, bool)): Adapt
    definition.
    * include/debug/safe_iterator.tcc (__niter_base): Add definition.
    * testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc 
(test03):

    New.
    * testsuite/25_algorithms/copy/streambuf_iterators/char/debug/
    deque_neg.cc: New.
    * testsuite/25_algorithms/copy_n/debug/istreambuf_ite_deque_neg.cc:
    New.
    * testsuite/25_algorithms/copy_n/istreambuf_iterator/2.cc: New.
    * testsuite/25_algorithms/copy_n/istreambuf_iterator/deque.cc: New.

Already tested for a while on Linux x64 normal and debug modes but I 
am currently rebuilding everything and will commit only once all 
succeeded again.


Ok ?

François

Re: [PATCH] c++: template instantiation during fold_for_warn [PR94038]

[Jason Merrill via Gcc-patches]

On 5/8/20 11:42 AM, Patrick Palka wrote:

On Wed, 6 May 2020, Patrick Palka wrote:


On Wed, 6 May 2020, Patrick Palka wrote:


On Tue, 5 May 2020, Patrick Palka wrote:


On Tue, 5 May 2020, Patrick Palka wrote:


Unfortunately, the previous fix to PR94038 is fragile.  When the
argument to fold_for_warn is a bare CALL_EXPR, then all is well: the
result of maybe_constant_value from fold_for_warn (with
uid_sensitive=true) is reused via the cv_cache in the subsequent call to
maybe_constant_value from cp_fold (with uid_sensitive=false), so we
avoid instantiating bar.

But when the argument to fold_for_warn is more complex, e.g. an
INDIRECT_REF of a CALL_EXPR, as in the testcase below (due to bar()
returning const int& which we need to decay to int) then from
fold_for_warn we call maybe_constant_value on the INDIRECT_REF, and from
cp_fold we call it on the CALL_EXPR, so there is no reuse via the
cv_cache and we therefore end up instantiating bar.

So for a more robust solution to this general issue of warning flags
affecting code generation, it seems that we need a way to globally avoid
template instantiation during constexpr evaluation whenever we're
performing warning-dependent folding.

To that end, this patch replaces the flag constexpr_ctx::uid_sensitive
with a global flag uid_sensitive_constexpr_evaluation_p, and enables it
during fold_for_warn using an RAII helper.

The patch also adds a counter that keeps track of the number of times
uid_sensitive_constexpr_evaluation_p is called, and we use this to
determine whether the result of constexpr evaluation depended on the
flag's value.  This lets us safely update the cv_cache and fold_cache
from fold_for_warn in the most common case where the flag's value was
irrelevant during constexpr evaluation.


Here's some statistics about about the fold cache and cv cache that were
collected when building the testsuite of range-v3 (with the default
build flags which include -O -Wall -Wextra, so warning-dependent folding
applies).

The "naive solution" below refers to the one in which we would refrain
from updating the caches at the end of cp_fold/maybe_constant_value
whenever we're in uid-sensitive constexpr evaluation mode (i.e. whenever
we're called from fold_for_warn), regardless of whether constexpr
evaluation was actually restricted.


FOLD CACHE  | cache hit | cache miss| cache miss|
 |   | cache updated | cache not updated |
+---+---+---+
naive sol'n |   5060779 |  11374667 |  12887790 |
+
this patch  |   6665242 |  19688975 |199137 |
+---+---+---+


CV CACHE| cache hit | cache miss| cache miss|
 |   | cache updated | cache not updated |
+---+---+---+
naive sol'n | 76214 |   3637218 |   6889213 |
+
this patch  |215980 |   9882310 |405513 |
+---+---+---+

-- >8 --

gcc/cp/ChangeLog:

PR c++/94038
* constexpr.c (constexpr_ctx::uid_sensitive): Remove field.
(uid_sensitive_constexpr_evaluation_value): Define.
(uid_sensitive_constexpr_evaluation_true_counter): Define.
(uid_sensitive_constexpr_evaluation_p): Define.
(uid_sensitive_constexpr_evaluation_sentinel): Define its
constructor.
(uid_sensitive_constexpr_evaluation_checker): Define its
constructor and its evaluation_restricted_p method.
(get_fundef_copy): Remove 'ctx' parameter.  Use u_s_c_e_p
instead of constexpr_ctx::uid_sensitive.
(cxx_eval_call_expression): Use u_s_c_e_p instead, and test it
last.  Adjust call to get_fundef_copy.
(instantiate_cx_fn_r): Test u_s_c_e_p so that we increment the
counter if necessary.
(cxx_eval_outermost_constant_expr): Remove 'uid_sensitive'
parameter.  Adjust function body accordingly.
(maybe_constant_value): Remove 'uid_sensitive' parameter and
adjust function body accordingly.  Set up a
uid_sensitive_constexpr_evaluation_checker, and use it to
conditionally update the cv_cache.
* cp-gimplify.h (cp_fold): Set up a
uid_sensitive_constexpr_evaluation_checker, and use it to
conditionally update the fold_cache.
* cp-tree.h (maybe_constant_value): Update declaration.
(struct uid_sensitive_constexpr_evaluation_sentinel): Define.
(struct sensitive_constexpr_evaluation_checker): Define.
* expr.c (fold_for_warn): Set up a
uid_sensitive_constexpr_evaluation_sentinel before calling
the folding subroutines.  Drop all but the first argument to
maybe_constant_value.

gcc/testsuite/ChangeLog:

PR 

Re: collect2.exe errors not pruned

[Joseph Myers]

On Tue, 19 May 2020, Alexandre Oliva wrote:

> > I don't think the error should mention .exe, but I also don't think the 
> > error should mention collect2 (see what I said in 
> > , the existence 
> > of collect2 is an implementation detail).
> 
> I'm not changing collect2, at least not in this patch, but I wouldn't
> mind making the match for the internal executable name optional.  WDYT?
> Untested patch follows.

Allowing a missing executable name is reasonable enough, but I was 
actually thinking that the messages should print "gcc" or whatever command 
the user ran in place of "collect2".

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

[PATCH] Use commit timestamp in git_update_version.py.

[Martin Liška]

Hi.

The patch is about usage of a git commit timestamp for generated
ChangeLog entries.

Installed to master.
Martin

contrib/ChangeLog:

2020-05-19  Martin Liska  

* gcc-changelog/git_commit.py: Add param use_commit_ts
for to_changelog_entries.
* gcc-changelog/git_update_version.py: Se use_commit_ts to True.
---
 contrib/gcc-changelog/git_commit.py | 4 ++--
 contrib/gcc-changelog/git_update_version.py | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)


diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 5214cc36538..f6b9c5b1586 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -500,11 +500,11 @@ class GitCommit:
 err = Error(msg % (entry.folder, changelog_location), file)
 self.errors.append(err)
 
-def to_changelog_entries(self):
+def to_changelog_entries(self, use_commit_ts=False):
 for entry in self.changelog_entries:
 output = ''
 timestamp = entry.datetime
-if not timestamp:
+if not timestamp or use_commit_ts:
 timestamp = self.date.strftime('%Y-%m-%d')
 authors = entry.authors if entry.authors else [self.author]
 # add Co-Authored-By authors to all ChangeLog entries
diff --git a/contrib/gcc-changelog/git_update_version.py b/contrib/gcc-changelog/git_update_version.py
index 2de44f27580..f38e011df45 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -38,7 +38,7 @@ def prepend_to_changelog_files(repo, folder, git_commit):
 print(error)
 # TODO: add error message
 return
-for entry, output in git_commit.to_changelog_entries():
+for entry, output in git_commit.to_changelog_entries(use_commit_ts=True):
 # TODO
 full_path = os.path.join(folder, entry, 'ChangeLog.test')
 print('writting to %s' % full_path)

[PATCH] Add missing store in emission of asan_stack_free.

[Martin Liška]

Hi.

We make direct emission for asan_emit_stack_protection for smaller stacks.
That's fine but we're missing the piece that marks the stack as released
and we run out of pre-allocated stacks. I also included some stack-related
constants that were used in asan.c.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2020-05-19  Martin Liska  

PR sanitizer/94910
* asan.c (asan_emit_stack_protection): Emit
also **SavedFlagPtr(FakeStack) = 0 in order to release
a stack frame.
* asan.h (ASAN_MIN_STACK_FRAME_SIZE_LOG): New.
(ASAN_MAX_STACK_FRAME_SIZE_LOG): Likewise.
(ASAN_MIN_STACK_FRAME_SIZE): Likewise.
(ASAN_MAX_STACK_FRAME_SIZE): Likewise.
---
 gcc/asan.c | 26 ++
 gcc/asan.h |  8 
 2 files changed, 30 insertions(+), 4 deletions(-)


diff --git a/gcc/asan.c b/gcc/asan.c
index c9872f1b007..4cdf294e82b 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1375,7 +1375,7 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb,
   char buf[32];
   HOST_WIDE_INT base_offset = offsets[length - 1];
   HOST_WIDE_INT base_align_bias = 0, offset, prev_offset;
-  HOST_WIDE_INT asan_frame_size = offsets[0] - base_offset;
+  unsigned HOST_WIDE_INT asan_frame_size = offsets[0] - base_offset;
   HOST_WIDE_INT last_offset, last_size, last_size_aligned;
   int l;
   unsigned char cur_shadow_byte = ASAN_STACK_MAGIC_LEFT;
@@ -1428,7 +1428,9 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb,
   str_cst = asan_pp_string (_pp);
 
   /* Emit the prologue sequence.  */
-  if (asan_frame_size > 32 && asan_frame_size <= 65536 && pbase
+  if (asan_frame_size >= ASAN_MIN_STACK_FRAME_SIZE
+  && asan_frame_size <= ASAN_MAX_STACK_FRAME_SIZE
+  && pbase
   && param_asan_use_after_return)
 {
   use_after_return_class = floor_log2 (asan_frame_size - 1) - 5;
@@ -1598,8 +1600,24 @@ asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb,
   if (use_after_return_class < 5
 	  && can_store_by_pieces (sz, builtin_memset_read_str, ,
   BITS_PER_UNIT, true))
-	store_by_pieces (shadow_mem, sz, builtin_memset_read_str, ,
-			 BITS_PER_UNIT, true, RETURN_BEGIN);
+	{
+	  /* Emit:
+	   memset(ShadowBase, kAsanStackAfterReturnMagic, ShadowSize);
+	   **SavedFlagPtr(FakeStack) = 0
+	  */
+	  store_by_pieces (shadow_mem, sz, builtin_memset_read_str, ,
+			   BITS_PER_UNIT, true, RETURN_BEGIN);
+
+	  unsigned HOST_WIDE_INT offset
+	= (1 << (use_after_return_class + ASAN_MIN_STACK_FRAME_SIZE_LOG));
+	  offset -= GET_MODE_SIZE (ptr_mode);
+	  mem = adjust_address (mem, Pmode, offset);
+	  mem = gen_rtx_MEM (ptr_mode, mem);
+	  rtx tmp_reg = gen_reg_rtx (Pmode);
+	  emit_move_insn (tmp_reg, mem);
+	  mem = adjust_address (mem, QImode, 0);
+	  emit_move_insn (mem, const0_rtx);
+	}
   else if (use_after_return_class >= 5
 	   || !set_storage_via_setmem (shadow_mem,
 	   GEN_INT (sz),
diff --git a/gcc/asan.h b/gcc/asan.h
index 9efd33f9b86..5ff0735045f 100644
--- a/gcc/asan.h
+++ b/gcc/asan.h
@@ -58,6 +58,14 @@ extern hash_set  *asan_used_labels;
 
 #define ASAN_MIN_RED_ZONE_SIZE	16
 
+/* Minimal and maximal frame size for a fake stack frame.  */
+
+#define ASAN_MIN_STACK_FRAME_SIZE_LOG 6
+#define ASAN_MAX_STACK_FRAME_SIZE_LOG 16
+
+#define ASAN_MIN_STACK_FRAME_SIZE (1UL << ASAN_MIN_STACK_FRAME_SIZE_LOG)
+#define ASAN_MAX_STACK_FRAME_SIZE (1UL << ASAN_MAX_STACK_FRAME_SIZE_LOG)
+
 /* Shadow memory values for stack protection.  Left is below protected vars,
the first pointer in stack corresponding to that offset contains
ASAN_STACK_FRAME_MAGIC word, the second pointer to a string describing

Re: [PATCH][C] c/95141 - fix bogus integer overflow warning

[Joseph Myers]

On Tue, 19 May 2020, Richard Biener wrote:

> This fixes an integer overflow warning that ultimatively happens because
> of TREE_OVERFLOW propagating through transforms and the existing guard
> against this,
> 
> 375   if (TREE_OVERFLOW_P (ret)
> 376   && !TREE_OVERFLOW_P (op0)
> 377   && !TREE_OVERFLOW_P (op1))
> 378 overflow_warning (EXPR_LOC_OR_LOC (expr, input_location,
> 
> being insufficient.  Rather than trying to use sth like walk_tree to
> exhaustively walk operands (with the possibility of introducing
> quadraticness when folding larger expressions recursively) the
> following amends the above with an ad-hoc test for a binary op0
> with a possibly constant op1.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?

OK.

The test in bug 32643 looks vaguely similar, but that's an older 
regression, do I take it this patch doesn't help with that one?

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

[PR 95149] reimplement raw literal lexing

[Nathan Sidwell]

pr95149 is a false positive static analysis checker.  But it encouranged 
me to fix raw string lexing, which does contain a complicated macro and 
pointers to local variables.  The reimplementation does away with that 
macro.  Part of the complication is we need to undo some of the fresh 
line processing -- trigraph notes and escaped line continuations.  But 
the undone characters need to go through the raw string processing, as 
they can legitimately be part of the prefix marker.  however, in this 
reformulation we only process one line marker at a time[*], so there's a 
limited number of undone characters.  We can arrange the buffering to 
make sure we don't split such an append sequence, and then simply take 
the characters from the append buffer.


The prefix scanner had a switch statement, which I discovered was not 
optimized as well as an if of a bunch of explicit comparisons (pr 95208 
filed).


Finally I adjusted the failure mode.  When we get a bad prefix, we lex 
up until the next '"', thus often swallowing the whole raw string. 
Previously we'd bail and then the lexer would usually generate stupid 
tokens, particularly when meeting the ending '"'.


pushed to master

--
Nathan Sidwell
2020-05-18  Nathan Sidwell  

	PR preprocessor/95149
	libcpp/
	* lex.c (struct lit_accum): New.
	(bufring_append): Replace by lit_accum::append.
	(lex_raw_string): Reimplement, using fragments of the old version.
	(lex_string): Adjust lex_raw_string call.

	gcc/testsuite/
	* c-c++-common/raw-string-14.c: Adjust errors.
	* c-c++-common/raw-string-16.c: Likewise.
	* c-c++-common/raw-string-5.c: Likewise.

diff --git i/libcpp/lex.c w/libcpp/lex.c
index f0ee0f9d4f6..5d94882abe8 100644
--- i/libcpp/lex.c
+++ w/libcpp/lex.c
@@ -1586,35 +1586,74 @@ create_literal (cpp_reader *pfile, cpp_token *token, const uchar *base,
   token->val.str.text = dest;
 }
 
+/* A pair of raw buffer pointers.  The currently open one is [1], the
+   first one is [0].  Used for string literal lexing.  */
+struct lit_accum {
+  _cpp_buff *first;
+  _cpp_buff *last;
+  const uchar *rpos;
+  size_t accum;
+
+  lit_accum ()
+: first (NULL), last (NULL), rpos (0), accum (0)
+  {
+  }
+
+  void append (cpp_reader *, const uchar *, size_t);
+
+  void read_begin (cpp_reader *);
+  bool reading_p () const
+  {
+return rpos != NULL;
+  }
+  char read_char ()
+  {
+char c = *rpos++;
+if (rpos == BUFF_FRONT (last))
+  rpos = NULL;
+return c;
+  }
+};
+
 /* Subroutine of lex_raw_string: Append LEN chars from BASE to the buffer
sequence from *FIRST_BUFF_P to LAST_BUFF_P.  */
 
-static void
-bufring_append (cpp_reader *pfile, const uchar *base, size_t len,
-		_cpp_buff **first_buff_p, _cpp_buff **last_buff_p)
+void
+lit_accum::append (cpp_reader *pfile, const uchar *base, size_t len)
 {
-  _cpp_buff *first_buff = *first_buff_p;
-  _cpp_buff *last_buff = *last_buff_p;
-
-  if (first_buff == NULL)
-first_buff = last_buff = _cpp_get_buff (pfile, len);
-  else if (len > BUFF_ROOM (last_buff))
+  if (!last)
+/* Starting.  */
+first = last = _cpp_get_buff (pfile, len);
+  else if (len > BUFF_ROOM (last))
 {
-  size_t room = BUFF_ROOM (last_buff);
-  memcpy (BUFF_FRONT (last_buff), base, room);
-  BUFF_FRONT (last_buff) += room;
+  /* There is insufficient room in the buffer.  Copy what we can,
+	 and then either extend or create a new one.  */
+  size_t room = BUFF_ROOM (last);
+  memcpy (BUFF_FRONT (last), base, room);
+  BUFF_FRONT (last) += room;
   base += room;
   len -= room;
-  last_buff = _cpp_append_extend_buff (pfile, last_buff, len);
-}
+  accum += room;
+
+  gcc_checking_assert (!rpos);
 
-  memcpy (BUFF_FRONT (last_buff), base, len);
-  BUFF_FRONT (last_buff) += len;
+  last = _cpp_append_extend_buff (pfile, last, len);
+}
 
-  *first_buff_p = first_buff;
-  *last_buff_p = last_buff;
+  memcpy (BUFF_FRONT (last), base, len);
+  BUFF_FRONT (last) += len;
+  accum += len;
 }
 
+void
+lit_accum::read_begin (cpp_reader *pfile)
+{
+  /* We never accumulate more than 4 chars to read.  */
+  if (BUFF_ROOM (last) < 4)
+
+last = _cpp_append_extend_buff (pfile, last, 4);
+  rpos = BUFF_FRONT (last);
+}
 
 /* Returns true if a macro has been defined.
This might not work if compile with -save-temps,
@@ -1657,247 +1696,231 @@ is_macro_not_literal_suffix(cpp_reader *pfile, const uchar *base)
   return is_macro (pfile, base);
 }
 
-/* Lexes a raw string.  The stored string contains the spelling, including
-   double quotes, delimiter string, '(' and ')', any leading
-   'L', 'u', 'U' or 'u8' and 'R' modifier.  It returns the type of the
-   literal, or CPP_OTHER if it was not properly terminated.
+/* Lexes a raw string.  The stored string contains the spelling,
+   including double quotes, delimiter string, '(' and ')', any leading
+   'L', 'u', 'U' or 'u8' and 'R' modifier.  The created token contains
+   the type of the literal, or CPP_OTHER if it was 

[PATCH] Fix FAIL: gcc.target/i386/pr92645-4.c

[Richard Biener]

This adjusts the testcase for the introduced vector promotion/demotion
support.

Pushed.

2020-05-19  Richard Biener  

* gcc.target/i386/pr92645-4.c: Adjust expected pattern.
---
 gcc/testsuite/gcc.target/i386/pr92645-4.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/pr92645-4.c 
b/gcc/testsuite/gcc.target/i386/pr92645-4.c
index 788a97ed117..5d459040846 100644
--- a/gcc/testsuite/gcc.target/i386/pr92645-4.c
+++ b/gcc/testsuite/gcc.target/i386/pr92645-4.c
@@ -47,10 +47,10 @@ void f(char *dst, char *src, unsigned long n, unsigned c)
   }
 }
 
-/* { dg-final { scan-tree-dump-times "vec_unpack_lo" 3 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\\(vector\\(16\\) short unsigned int\\)" 
3 "optimized" } } */
 /* We're missing an opportunity to, after later optimizations, combine
-   a uniform CTOR with a vec_unpack_lo_expr to a CTOR on a converted
+   a uniform CTOR with a vector promotion to a CTOR on a promoted
element.  */
-/* { dg-final { scan-tree-dump-times "vec_unpack_lo" 2 "optimized" { xfail 
*-*-* } } } */
+/* { dg-final { scan-tree-dump-times "\\(vector\\(16\\) short unsigned int\\)" 
2 "optimized" { xfail *-*-* } } } */
 /* { dg-final { scan-tree-dump-times "VEC_PACK_TRUNC" 1 "optimized" } } */
 /* { dg-final { scan-tree-dump-times "BIT_FIELD_REF" 2 "optimized" } } */
-- 
2.26.1

Re: [PATCH] s390: Fix up -Wpsabi diagnostcs + analysis [PR94704]

[Jason Merrill via Gcc-patches]

On 5/19/20 9:34 AM, Ulrich Weigand wrote:

On Tue, Apr 28, 2020 at 02:13:02PM +0200, Jakub Jelinek wrote:


struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { double a; };
struct B : public X { double a; };
struct C : public Y { double a; };
struct D : public Z { double a; };
struct E : public U { double a; };


This is only testing the [[no_unique_address]] attribute in the
most-derived class, but I believe the attribute also affects
members in the base class.  Is this understanding correct?

Specifically, if we were to add two more tests to the above:
struct X2 { X x; };
struct X3 { [[no_unique_address]] X x; };
struct B2 : public X2 { double a; };
struct B3 : public X3 { double a; };
Then we should see that B2 does *not* count as single-element
struct, but B3 *does*.  (That's also what GCC currently does.)

Just trying to get clarity here as I'm about to work on this
for clang ...


That sounds right to me, given that X3 counts as an empty class under

https://itanium-cxx-abi.github.io/cxx-abi/abi.html#definitions

empty class
A class with no non-static data members other than empty data members, 
no unnamed bit-fields other than zero-width bit-fields, no virtual 
functions, no virtual base classes, and no non-empty non-virtual proper 
base classes.


Jason

Re: [PATCH] [aarch64] Fix PR94591: GCC generates invalid rev64 insns

[Richard Sandiford]

Alex Coplan  writes:
> Hello,
>
> This patch fixes PR94591. The problem was the function 
> aarch64_evpc_rev_local()
> matching vector permutations that were not reversals. In particular, prior to
> this patch, this function matched the identity permutation which led to
> generating bogus REV64 insns which were rejected by the assembler.
>
> Testing:
>  - New regression test which passes after applying the patch.
>  - New test passes on an x64 -> aarch64-none-elf cross.
>  - Bootstrap and regtest on aarch64-linux-gnu.
>
> OK to install?
>
> Thanks,
> Alex
>
> ---
>
> gcc/ChangeLog:
>
> 2020-05-19  Alex Coplan  
>
>   PR target/94591
>   * config/aarch64/aarch64.c (aarch64_evpc_rev_local): Don't match
>   identity permutation.
>
> gcc/testsuite/ChangeLog:
>
> 2020-05-19  Alex Coplan  
>
>   PR target/94591
>   * gcc.c-torture/execute/pr94591.c: New test.

OK, thanks.

Richard

> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 70aa2f752b5..79c016f4dc3 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -20191,7 +20191,8 @@ aarch64_evpc_rev_local (struct expand_vec_perm_d *d)
>  
>if (d->vec_flags == VEC_SVE_PRED
>|| !d->one_vector_p
> -  || !d->perm[0].is_constant ())
> +  || !d->perm[0].is_constant ()
> +  || !diff)
>  return false;
>  
>size = (diff + 1) * GET_MODE_UNIT_SIZE (d->vmode);
> diff --git a/gcc/testsuite/gcc.c-torture/execute/pr94591.c 
> b/gcc/testsuite/gcc.c-torture/execute/pr94591.c
> new file mode 100644
> index 000..42271ad8bce
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/execute/pr94591.c
> @@ -0,0 +1,32 @@
> +typedef unsigned __attribute__((__vector_size__(8))) V2SI_u;
> +typedef int __attribute__((__vector_size__(8))) V2SI_d;
> +
> +typedef unsigned long __attribute__((__vector_size__(16))) V2DI_u;
> +typedef long __attribute__((__vector_size__(16))) V2DI_d;
> +
> +void id_V2SI(V2SI_d *v)
> +{
> +  *v = __builtin_shuffle(*v, (V2SI_d)(V2SI_u) { 0, 1 });
> +}
> +
> +void id_V2DI(V2DI_d *v)
> +{
> +  *v = __builtin_shuffle(*v, (V2DI_d)(V2DI_u) { 0, 1 });
> +}
> +
> +extern void abort(void);
> +
> +int main(void)
> +{
> +  V2SI_d si = { 35, 42 };
> +  id_V2SI();
> +
> +  if (si[0] != 35 || si[1] != 42)
> +abort();
> +
> +  V2DI_d di = { 63, 38 };
> +  id_V2DI();
> +
> +  if (di[0] != 63 || di[1] != 38)
> +abort();
> +}

Re: New mklog script

[Jakub Jelinek via Gcc-patches]

On Tue, May 19, 2020 at 05:21:16PM +0100, Richard Earnshaw wrote:
> This is really a wart in the GNU coding style.  And one reason why I
> tend to indent such labels by a single space.  It particularly affects
> things like class definitions where public, private, etc statements
> often appear in column 0.
> 
> IMO, it would be nice to get an official change in the coding style for
> this, it's really irritating.

It doesn't have to be just label,
void
foo ()
{
  ...
#define X ...
  ...
#undef X
  ...
}
does the similar thing for mklog.

Jakub

[PATCH] [aarch64] Fix PR94591: GCC generates invalid rev64 insns

[Alex Coplan]

Hello,

This patch fixes PR94591. The problem was the function aarch64_evpc_rev_local()
matching vector permutations that were not reversals. In particular, prior to
this patch, this function matched the identity permutation which led to
generating bogus REV64 insns which were rejected by the assembler.

Testing:
 - New regression test which passes after applying the patch.
 - New test passes on an x64 -> aarch64-none-elf cross.
 - Bootstrap and regtest on aarch64-linux-gnu.

OK to install?

Thanks,
Alex

---

gcc/ChangeLog:

2020-05-19  Alex Coplan  

PR target/94591
* config/aarch64/aarch64.c (aarch64_evpc_rev_local): Don't match
identity permutation.

gcc/testsuite/ChangeLog:

2020-05-19  Alex Coplan  

PR target/94591
* gcc.c-torture/execute/pr94591.c: New test.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 70aa2f752b5..79c016f4dc3 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -20191,7 +20191,8 @@ aarch64_evpc_rev_local (struct expand_vec_perm_d *d)
 
   if (d->vec_flags == VEC_SVE_PRED
   || !d->one_vector_p
-  || !d->perm[0].is_constant ())
+  || !d->perm[0].is_constant ()
+  || !diff)
 return false;
 
   size = (diff + 1) * GET_MODE_UNIT_SIZE (d->vmode);
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr94591.c b/gcc/testsuite/gcc.c-torture/execute/pr94591.c
new file mode 100644
index 000..42271ad8bce
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr94591.c
@@ -0,0 +1,32 @@
+typedef unsigned __attribute__((__vector_size__(8))) V2SI_u;
+typedef int __attribute__((__vector_size__(8))) V2SI_d;
+
+typedef unsigned long __attribute__((__vector_size__(16))) V2DI_u;
+typedef long __attribute__((__vector_size__(16))) V2DI_d;
+
+void id_V2SI(V2SI_d *v)
+{
+  *v = __builtin_shuffle(*v, (V2SI_d)(V2SI_u) { 0, 1 });
+}
+
+void id_V2DI(V2DI_d *v)
+{
+  *v = __builtin_shuffle(*v, (V2DI_d)(V2DI_u) { 0, 1 });
+}
+
+extern void abort(void);
+
+int main(void)
+{
+  V2SI_d si = { 35, 42 };
+  id_V2SI();
+
+  if (si[0] != 35 || si[1] != 42)
+abort();
+
+  V2DI_d di = { 63, 38 };
+  id_V2DI();
+
+  if (di[0] != 63 || di[1] != 38)
+abort();
+}

Re: New mklog script

[Richard Earnshaw]

On 19/05/2020 15:51, Michael Matz wrote:
> Hello,
> 
> On Tue, 19 May 2020, Martin Liška wrote:
> 
>>> The common problems I remember is that e.g. when changing a function comment
>>> above some function, it is attributed to the previous function rather than
>>> following, labels in function confusing it:
>>>   void
>>>   foo ()
>>>   {
>>> ...
>>>   label:
>>> ...
>>> -  ...
>>> +  ...
>>>   }
>>
>> I've just tested that and it will take function for patch context
>> (sem_variable::equals):
>> @@ -1875,6 +1875,7 @@ sem_variable::equals (tree t1, tree t2)
>>  default:
>>return return_false_with_msg ("Unknown TREE code reached");
>>  }
>> +
>>  }
> 
> No, the problem happens when the label is at column 0, like function names 
> are.  Basically diff -p uses a regexp morally equivalent to 
> '^[[:alpha:]$_]' to detect function headers, and git diff -p and friends 
> followed suit.  But it should use something like
> '^[[:alpha:]$_].*[^:]$' to rule out things ending with ':'.  See also diff 
> -F for GNU diff.
> 
> 
> Ciao,
> Michael.
> 

This is really a wart in the GNU coding style.  And one reason why I
tend to indent such labels by a single space.  It particularly affects
things like class definitions where public, private, etc statements
often appear in column 0.

IMO, it would be nice to get an official change in the coding style for
this, it's really irritating.

R.

Re: [PATCH 02/13] OpenACC reference count overhaul

[Thomas Schwinge]

Hi Julian!

On 2019-12-17T22:02:27-0800, Julian Brown  wrote:
> --- a/libgomp/oacc-mem.c
> +++ b/libgomp/oacc-mem.c

(Unhelpful diff trimmed.)

> +/* Unmap variables for OpenACC "exit data", with optional finalization
> +   (affecting all mappings in this operation).  */

> +static void
> +goacc_exit_data_internal (struct gomp_device_descr *acc_dev, size_t mapnum,
> +   void **hostaddrs, size_t *sizes,
> +   unsigned short *kinds, bool finalize, goacc_aq aq)
> +{
> +  gomp_mutex_lock (_dev->lock);

> +  for (size_t i = 0; i < mapnum; ++i)
>  {

> +  unsigned char kind = kinds[i] & 0xff;
> +  bool copyfrom = false;

> +  switch (kind)

> + case GOMP_MAP_FROM:
> + case GOMP_MAP_FORCE_FROM:
> + case GOMP_MAP_ALWAYS_FROM:
> +   copyfrom = true;
> +   /* Fallthrough.  */

What is the case that a 'GOMP_MAP_ALWAYS_FROM' would be generated for
OpenACC code?  Putting an 'assert' here, it never triggers, given the
current set of libgomp test cases.  If there is such a case, we should
add a test case, otherwise, I suggest we do put an 'assert' here (whilst
leaving in the supposedly correct code, if you'd like), to document that
this not currently expected, and thus not tested?

> +
> + case GOMP_MAP_TO_PSET:
> + case GOMP_MAP_POINTER:
> + case GOMP_MAP_DELETE:
> + case GOMP_MAP_RELEASE:
> +   {
> + struct splay_tree_key_s cur_node;
> + cur_node.host_start = (uintptr_t) hostaddrs[i];
> + cur_node.host_end = cur_node.host_start
> + + (kind == GOMP_MAP_POINTER
> +? sizeof (void *) : sizes[i]);
> + splay_tree_key n
> +   = splay_tree_lookup (_dev->mem_map, _node);
> +
> + if (n == NULL)
> +   continue;
> +
> + if (finalize)
> +   {
> + if (n->refcount != REFCOUNT_INFINITY)
> +   n->refcount -= n->virtual_refcount;
> + n->virtual_refcount = 0;
> +   }
> +
> + if (n->virtual_refcount > 0)
> +   {
> + if (n->refcount != REFCOUNT_INFINITY)
> +   n->refcount--;
> + n->virtual_refcount--;
> +   }
> + else if (n->refcount > 0 && n->refcount != REFCOUNT_INFINITY)
> +   n->refcount--;
> +
> + if (copyfrom
> + && (kind != GOMP_MAP_FROM || n->refcount == 0))
> +   gomp_copy_dev2host (acc_dev, aq, (void *) cur_node.host_start,
> +   (void *) (n->tgt->tgt_start + n->tgt_offset
> + + cur_node.host_start
> + - n->host_start),
> +   cur_node.host_end - cur_node.host_start);

That 'kind != GOMP_MAP_FROM' conditional looks wrong to me.  This should
instead be 'kind == GOMP_MAP_ALWAYS_FROM'?  Or, get removed, together
with the 'GOMP_MAP_ALWAYS_FROM' handling above?  But definitely
'GOMP_MAP_FORCE_FROM' and 'GOMP_MAP_FROM' need to be handled the same, as
far as I can tell?

> +
> + if (n->refcount == 0)
> +   gomp_remove_var_async (acc_dev, n, aq);
> +   }
> +   break;
> + default:
> +   gomp_fatal (" goacc_exit_data_internal UNHANDLED kind 0x%.2x",
> +   kind);
>   }
>  }
>
>gomp_mutex_unlock (_dev->lock);

>  }


Grüße
 Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: New mklog script

[Joseph Myers]

On Tue, 19 May 2020, Martin Liška wrote:

> On 5/19/20 10:11 AM, Martin Liška wrote:
> > Can you please share how do you do it? It would be easy to add it.
> 
> I added the feature via --fill-up-bug-titles option. It uses common
> request and beatifulsoup packages.

The REST interface is much better to use for extracting bug data than 
screen scraping of HTML output.  Fetch e.g. 
https://gcc.gnu.org/bugzilla/rest.cgi/bug?id=12345_fields=summary 
to get JSON bug data (change or omit include_fields if you want more than 
just the summary).

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

Re: [PATCH 02/13] OpenACC reference count overhaul

[Thomas Schwinge]

Hi Julian!

On 2019-12-17T22:02:27-0800, Julian Brown  wrote:
> --- a/libgomp/oacc-mem.c
> +++ b/libgomp/oacc-mem.c

(Unhelpful diff trimmed.)

> +/* Some types of (pointer) variables use several consecutive mappings, which
> +   must be treated as a group for enter/exit data directives.  This function
> +   returns the last mapping in such a group (inclusive), or POS for singleton
> +   mappings.  */

> +static int
> +find_group_last (int pos, size_t mapnum, unsigned short *kinds)
>  {

> +  unsigned char kind0 = kinds[pos] & 0xff;
> +  int first_pos = pos, last_pos = pos;

> +  if (kind0 == GOMP_MAP_TO_PSET)
>  {

> +  while (pos + 1 < mapnum && (kinds[pos + 1] & 0xff) == GOMP_MAP_POINTER)
> + last_pos = ++pos;
> +  /* We expect at least one GOMP_MAP_POINTER after a GOMP_MAP_TO_PSET.  
> */
> +  assert (last_pos > first_pos);
> +}
> +  else
> +{
> +  /* GOMP_MAP_ALWAYS_POINTER can only appear directly after some other
> +  mapping.  */
> +  if (pos + 1 < mapnum
> +   && (kinds[pos + 1] & 0xff) == GOMP_MAP_ALWAYS_POINTER)
> + return pos + 1;

What is the case that a 'GOMP_MAP_ALWAYS_POINTER' would be generated for
OpenACC code?  Putting an 'assert' here, it never triggers, given the
current set of libgomp test cases.  If there is such a case, we should
add a test case, otherwise, I suggest we do put an 'assert' here (whilst
leaving in the supposedly correct code, if you'd like), to document that
this not currently expected, and thus not tested?

> +
> +  /* We can have one or several GOMP_MAP_POINTER mappings after a to/from
> +  (etc.) mapping.  */
> +  while (pos + 1 < mapnum && (kinds[pos + 1] & 0xff) == GOMP_MAP_POINTER)
> + last_pos = ++pos;
>  }

> +  return last_pos;
>  }


Grüße
 Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: [PATCH 02/13] OpenACC reference count overhaul

[Thomas Schwinge]

Hi Julian!

On 2019-12-17T22:02:27-0800, Julian Brown  wrote:
> --- a/libgomp/oacc-mem.c
> +++ b/libgomp/oacc-mem.c

> @@ -571,14 +570,16 @@ present_create_copy (unsigned f, void *h, size_t s, int 
> async)
>
>goacc_aq aq = get_goacc_asyncqueue (async);
>
> -  tgt = gomp_map_vars_async (acc_dev, aq, mapnum, , NULL, ,
> -  , true, GOMP_MAP_VARS_OPENACC);
> -  n = tgt->list[0].key;
> -  assert (n->refcount == 1);
> -  assert (n->dynamic_refcount == 0);
> -  n->dynamic_refcount++;
> +  gomp_map_vars_async (acc_dev, aq, mapnum, , NULL, , ,
> +true, GOMP_MAP_VARS_OPENACC_ENTER_DATA);
>
> -  d = tgt->to_free;
> +  gomp_mutex_lock (_dev->lock);
> +  n = lookup_host (acc_dev, h, s);
> +  assert (n != NULL);
> +  assert (n->tgt_offset == 0);
> +  assert ((uintptr_t) h == n->host_start);
> +  d = (void *) n->tgt->tgt_start;
> +  gomp_mutex_unlock (_dev->lock);
>  }

Notwithstanding the open question of the "'gomp_map_vars' locking
protocol" (discussed in a different thread, to be resolved
independently), is there a reason that you changed this code to look up
'n = lookup_host ([...])'?  This is the case that 'gomp_map_vars' enters
a new mapping, so by construction, 'n = tgt->list[0].key' must hold?  I
tested the following:

--- libgomp/oacc-mem.c
+++ libgomp/oacc-mem.c
@@ -555,16 +555,17 @@ goacc_enter_datum (void **hostaddrs, size_t *sizes, 
void *kinds, int async)

   goacc_aq aq = get_goacc_asyncqueue (async);

-  gomp_map_vars_async (acc_dev, aq, mapnum, hostaddrs, NULL, sizes, 
kinds,
-  true, GOMP_MAP_VARS_OPENACC_ENTER_DATA);
+  struct target_mem_desc *tgt
+   = gomp_map_vars_async (acc_dev, aq, mapnum, hostaddrs, NULL, sizes, 
kinds,
+  true, GOMP_MAP_VARS_OPENACC_ENTER_DATA);
+  assert (tgt);
+  n = tgt->list[0].key;
+  assert (n->refcount == 1);
+  assert (n->virtual_refcount == 0);

-  gomp_mutex_lock (_dev->lock);
-  n = lookup_host (acc_dev, hostaddrs[0], sizes[0]);
-  assert (n != NULL);
   assert (n->tgt_offset == 0);
   assert ((uintptr_t) hostaddrs[0] == n->host_start);
   d = (void *) n->tgt->tgt_start;
-  gomp_mutex_unlock (_dev->lock);
 }

..., and don't see any regressions.  If approving this patch, please
respond with "Reviewed-by: NAME " so that your effort will be
recorded in the commit log, see .


Grüße
 Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

[Patch, fortran] PR fortran/66833,67938,95214 ICE on using assumed rank character array

[José Rui Faustino de Sousa via Gcc-patches]

Hi all!

Proposed patch to PRs 66833, 67938 and 95214 ICE(s) on using assumed 
rank character array in different situations.


Patch tested only on x86_64-pc-linux-gnu.

Simple patch only add assumed-rank to the list of possible attributes.

Thank you very much.

Best regards,
José Rui


2020-5-19  José Rui Faustino de Sousa  

 PR fortran/95214
 * trans-expr.c (gfc_maybe_dereference_var): Add assumed-rank to
 character dummy arguments list of possible attributes.

2020-5-19  José Rui Faustino de Sousa  

 PR fortran/95214
 * PR95214.f90: New test.


diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 33fc061..435eaeb 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -2613,7 +2613,8 @@ gfc_maybe_dereference_var (gfc_symbol *sym, tree var, 
bool descriptor_only_p,
 {
   /* Dereference character pointer dummy arguments
 or results.  */
-  if ((sym->attr.pointer || sym->attr.allocatable)
+  if ((sym->attr.pointer || sym->attr.allocatable
+  || (sym->as && sym->as->type == AS_ASSUMED_RANK))
  && (sym->attr.dummy
  || sym->attr.function
  || sym->attr.result))
diff --git a/gcc/testsuite/gfortran.dg/PR95214.f90 
b/gcc/testsuite/gfortran.dg/PR95214.f90
new file mode 100644
index 000..682ef63
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR95214.f90
@@ -0,0 +1,84 @@
+! { dg-do run }
+!
+! PR fortran/95214
+!
+
+program chr_p
+
+  implicit none
+
+  integer, parameter :: u = 65
+  
+  integer, parameter :: n = 26
+  
+  character :: c(n)
+  integer   :: i
+
+  c = [(achar(i), i=u,u+n-1)]
+  call chr_s(c, c)
+  call gfc_descriptor_c_char(c)
+  call s1(c)
+  call s1s_a(c)
+  call s1s_b(c)
+  call s2(c)
+  stop
+  
+contains
+
+  subroutine chr_s(a, b)
+character, intent(in) :: a(..)
+character, intent(in) :: b(:)
+
+integer :: i
+
+select rank(a)
+rank(1)
+  do i = 1, size(a)
+if(a(i)/=b(i)) stop 1
+  end do
+rank default
+  stop 1001
+end select
+return
+  end subroutine chr_s
+
+  ! From Bug 66833
+  ! Contributed by Damian Rouson 
+  subroutine gfc_descriptor_c_char(a)
+character a(..)
+if(rank(a)/=1) stop 2001 ! ICE (also for lbound, ubound, and c_loc)
+  end subroutine gfc_descriptor_c_char
+
+
+  ! From Bug 67938
+  ! Contributed by Gerhard Steinmetz 
+  
+  ! example z1.f90
+  subroutine s1(x)
+character(1) :: x(..)
+if(any(lbound(x)/=[1])) stop 3001
+if(any(ubound(x)/=[n])) stop 3002
+  end subroutine s1
+  
+  ! example z1s.f90
+  subroutine s1s_a(x)
+character :: x(..)
+if(size(x)/=n) stop 4001
+  end subroutine s1s_a
+  
+  subroutine s1s_b(x)
+character(77) :: x(..)
+if(size(x)/=n) stop 5001
+  end subroutine s1s_b
+  
+  ! example z2.f90
+  subroutine s2(x)
+character(1) :: x(..)
+if(lbound(x, dim=1)/=1) stop 6001
+if(ubound(x, dim=1)/=n) stop 6002
+if(size(x, dim=1)/=n)   stop 6003
+  end subroutine s2
+  
+end program chr_p
+
+

Re: New mklog script

[Michael Matz]

Hello,

On Tue, 19 May 2020, Martin Liška wrote:

> > The common problems I remember is that e.g. when changing a function comment
> > above some function, it is attributed to the previous function rather than
> > following, labels in function confusing it:
> >   void
> >   foo ()
> >   {
> > ...
> >   label:
> > ...
> > -  ...
> > +  ...
> >   }
> 
> I've just tested that and it will take function for patch context
> (sem_variable::equals):
> @@ -1875,6 +1875,7 @@ sem_variable::equals (tree t1, tree t2)
>  default:
>return return_false_with_msg ("Unknown TREE code reached");
>  }
> +
>  }

No, the problem happens when the label is at column 0, like function names 
are.  Basically diff -p uses a regexp morally equivalent to 
'^[[:alpha:]$_]' to detect function headers, and git diff -p and friends 
followed suit.  But it should use something like
'^[[:alpha:]$_].*[^:]$' to rule out things ending with ':'.  See also diff 
-F for GNU diff.


Ciao,
Michael.

Re: [PATCH] c++: Implement DR 2289, Uniqueness of structured binding names [PR94553]

[Jason Merrill via Gcc-patches]

On 5/18/20 5:07 PM, Marek Polacek wrote:

On Mon, May 18, 2020 at 04:50:44PM -0400, Jason Merrill via Gcc-patches wrote:

On 5/13/20 12:22 PM, Marek Polacek wrote:

DR 2289 clarified that since structured bindings have no C compatibility
implications, they should be unique in their declarative region, see
[basic.scope.declarative]/4.2.

The duplicate_decls hunk is the gist of the patch, but that alone would
not be enough to detect the 'A' case: cp_parser_decomposition_declaration
uses

13968   tree decl2 = start_decl (declarator, _specs, SD_INITIALIZED,
13969NULL_TREE, NULL_TREE, _pushed_scope);

to create the 'A' VAR_DECL but in this start_decl's grokdeclarator we
don't do fit_decomposition_lang_decl because the declarator kind is not
cdk_decomp


Why isn't it?  I see

   cp_declarator *declarator = make_declarator (cdk_decomp);

a few lines up.


Right, and we use that for the underlying decomp base VAR_DECL.  But each of
the named variables used in a structured binding are created in the
FOR_EACH_VEC_ELT loop, and that creates a cdk_id declarator for them:

13963   if (i == 0)
13964 declarator = make_id_declarator (NULL_TREE, e.get_value (),
13965  sfk_none, e.get_location ());


Ah, yes.

You name the new parameter FORCE_LANG_DECL_P and describe it as meaning 
"create a lang decl node for the new decl", but the actual meaning seems 
to be "mark the new decl as DECL_DECOMPOSITION_P", which seems too 
specific for adding a new parameter to a frequently used function.


How about adding a new SD_DECOMPOSITION value for the initialized 
parameter, or an attribute?


Jason

'gomp_map_vars' locking protocol (was: [OpenACC] Update OpenACC data clause semantics to the 2.5 behavior - runtime)

[Thomas Schwinge]

Hi Jakub, Julian!

Can you please help me understand the following:

On 2018-06-19T10:01:20-0700, Cesar Philippidis  wrote:
> This patch implements the OpenACC 2.5 data clause semantics in libgomp.

(This got committed as r261813, 2018-06-20.  The code has seen some
changes in the mean time, but the underlying issue remains.)

> --- a/libgomp/oacc-mem.c
> +++ b/libgomp/oacc-mem.c

> @@ -347,6 +347,7 @@ acc_map_data (void *h, void *d, size_t s)
>
>tgt = gomp_map_vars (acc_dev, mapnum, , , ,
>  , true, GOMP_MAP_VARS_OPENACC);
> +  tgt->list[0].key->refcount = REFCOUNT_INFINITY;
>  }
>
>gomp_mutex_lock (_dev->lock);

Without 'acc_dev->lock' locked, we here touch the 'refcount' (via
'tgt->list[0].key->refcount'), as returned from 'gomp_map_vars' in the
case when entering a new mapping.

> @@ -483,6 +492,8 @@ present_create_copy (unsigned f, void *h, size_t s)
>
>tgt = gomp_map_vars (acc_dev, mapnum, , NULL, , , 
> true,
>  GOMP_MAP_VARS_OPENACC);
> +  /* Initialize dynamic refcount.  */
> +  tgt->list[0].key->dynamic_refcount = 1;
>
>gomp_mutex_lock (_dev->lock);

Likewise here, for the 'dynamic_refcount' (via
'tgt->list[0].key->dynamic_refcount'), as returned from 'gomp_map_vars'
in the case when entering a new mapping.

By construction, it is safe to assume that 'tgt->list[0].key' is the 'n'
we're looking to modify: this is the case where we're entering a new
mapping.

But: is it safe to access this unlocked?  It may seem so, as the new
mapping has not yet been exposed to user code, so only exists internal in
the respective libgomp functions.  Yet, could still a concurrent
'acc_unmap_data'/'acc_delete'/etc. already "see" it (that is, look it up,
as it already has been entered into the mapping table), and unmap while
we're accessing 'tgt->list[0].key' here?

(Hmm, and actually a similar issue, if we consider the case of two
'gomp_map_vars' running concurrently?)

In that case, I suppose we should change the 'gomp_map_vars' interface
and all callers so that 'gomp_map_vars' always takes the device locked.
That doesn't appear problematic: locking the device is one of the first
things 'gomp_map_vars' does anyway (just not in the 'mapnum == 0' case,
but I suppose it's OK to pessimize that one?), and it remains locked
until the end of the function.


Grüße
 Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

gcc/testsuite/go: increase memory in issue4085b.go

[CHIGOT, CLEMENT via Gcc-patches]

Description: 
  On aix/ppc64, it's possible to allocate an array of 1<<50 int, because of the
  wider address space. Thus, increase it to 1<<59 like in Golang toolchain in
  order to trigger the panic.

Changelog:
2020-05-19 Clement Chigot 
  * go.test/test/fixedbugs/issue4085b.go: increase the size of n2 in 64bit


Please apply for me if approved.
Could it be backported in gcc-8 and gcc-9 branch too ? 

Thanks,
Clément Chigot



gcc-8.4.0-gcc-testsuite-go-increase-memory-in-issue4085b.go.patch
Description: gcc-8.4.0-gcc-testsuite-go-increase-memory-in-issue4085b.go.patch

Re: [PATCH] s390: Fix up -Wpsabi diagnostcs + analysis [PR94704]

[Ulrich Weigand via Gcc-patches]

On Tue, Apr 28, 2020 at 02:13:02PM +0200, Jakub Jelinek wrote:

> struct X { };
> struct Y { int : 0; };
> struct Z { int : 0; Y y; };
> struct U : public X { X q; };
> struct A { double a; };
> struct B : public X { double a; };
> struct C : public Y { double a; };
> struct D : public Z { double a; };
> struct E : public U { double a; };

This is only testing the [[no_unique_address]] attribute in the
most-derived class, but I believe the attribute also affects
members in the base class.  Is this understanding correct?

Specifically, if we were to add two more tests to the above:
struct X2 { X x; };
struct X3 { [[no_unique_address]] X x; };
struct B2 : public X2 { double a; };
struct B3 : public X3 { double a; };
Then we should see that B2 does *not* count as single-element
struct, but B3 *does*.  (That's also what GCC currently does.)

Just trying to get clarity here as I'm about to work on this
for clang ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

[PR 95182] ICE with EOF in macro args

[Nathan Sidwell]

This was another latent case of us losing an EOF token, but succeeding 
anyway.  Since my patch to make us pay more attention to EOFs it came to 
light.  We also need to keep the EOF if we fall off the end of the main 
file.  Forced includes look like regular nested includes at this point.


pushed to trunk

nathan
--
Nathan Sidwell
2020-05-18  Nathan Sidwell  

	PR preprocessor/95182
	libcpp/
	* macro.c (collect_args): Preserve EOFif we fell out of the main
	file.
	(cpp_get_token_1): Reformat a couple of short lines.

diff --git c/libcpp/macro.c w/libcpp/macro.c
index dc4366ffefd..2c7d7322e09 100644
--- c/libcpp/macro.c
+++ w/libcpp/macro.c
@@ -1258,11 +1258,13 @@ collect_args (cpp_reader *pfile, const cpp_hashnode *node,
 
   if (token->type == CPP_EOF)
 {
-  /* We still need the CPP_EOF to end directives, and to end
-	 pre-expansion of a macro argument.  Step back is not
-	 unconditional, since we don't want to return a CPP_EOF to our
-	 callers at the end of an -include-d file.  */
-  if (pfile->context->prev || pfile->state.in_directive)
+  /* We still need the CPP_EOF to end directives, to end
+	 pre-expansion of a macro argument, and at the end of the main
+	 file.  We do not want it at the end of a -include'd (forced)
+	 header file.  */
+  if (pfile->state.in_directive
+	  || !pfile->line_table->depth
+	  || pfile->context->prev)
 	_cpp_backup_tokens (pfile, 1);
   cpp_error (pfile, CPP_DL_ERROR,
 		 "unterminated argument list invoking macro \"%s\"",
@@ -2870,8 +2872,7 @@ cpp_get_token_1 (cpp_reader *pfile, location_t *location)
   || (peek_tok->flags & PREV_WHITE));
 		  node = pfile->cb.macro_to_expand (pfile, result);
 		  if (node)
-		ret = enter_macro_context (pfile, node, result,
-	   virt_loc);
+		ret = enter_macro_context (pfile, node, result, virt_loc);
 		  else if (whitespace_after)
 		{
 		  /* If macro_to_expand hook returned NULL and it
@@ -2888,8 +2889,7 @@ cpp_get_token_1 (cpp_reader *pfile, location_t *location)
 		}
 	}
 	  else
-	ret = enter_macro_context (pfile, node, result, 
-   virt_loc);
+	ret = enter_macro_context (pfile, node, result, virt_loc);
 	  if (ret)
  	{
 	  if (pfile->state.in_directive || ret == 2)
diff --git c/gcc/testsuite/c-c++-common/cpp/eof-1.c w/gcc/testsuite/c-c++-common/cpp/eof-1.c
new file mode 100644
index 000..0a06f091d93
--- /dev/null
+++ w/gcc/testsuite/c-c++-common/cpp/eof-1.c
@@ -0,0 +1,7 @@
+/* PR preprocess/95183  */
+
+/* { dg-do preprocess } */
+
+#define f(x) x
+
+f( /* { dg-error "-:unterminated" "unterminated macro" } */
diff --git c/gcc/testsuite/c-c++-common/cpp/eof-2.c w/gcc/testsuite/c-c++-common/cpp/eof-2.c
new file mode 100644
index 000..3a4af7f6850
--- /dev/null
+++ w/gcc/testsuite/c-c++-common/cpp/eof-2.c
@@ -0,0 +1,8 @@
+/* PR preprocess/95183  */
+
+/* { dg-do preprocess } */
+
+#define f(x) x
+
+#include "eof-2.h"
+ /* { dg-regexp {[^\n]*eof-2.h:4: error: unterminated argument list invoking macro "f"\n} } */
diff --git c/gcc/testsuite/c-c++-common/cpp/eof-2.h w/gcc/testsuite/c-c++-common/cpp/eof-2.h
new file mode 100644
index 000..48ad85791db
--- /dev/null
+++ w/gcc/testsuite/c-c++-common/cpp/eof-2.h
@@ -0,0 +1,4 @@
+
+#define f(x) x
+
+f( /* Error here  */
diff --git c/gcc/testsuite/c-c++-common/cpp/eof-3.c w/gcc/testsuite/c-c++-common/cpp/eof-3.c
new file mode 100644
index 000..316918e3a6c
--- /dev/null
+++ w/gcc/testsuite/c-c++-common/cpp/eof-3.c
@@ -0,0 +1,8 @@
+/* PR preprocess/95183  */
+
+/* { dg-do preprocess } */
+/* { dg-additional-options "-include $srcdir/c-c++-common/cpp/eof-2.h" } */
+
+ /* { dg-regexp {[^\n]*eof-2.h:4: error: unterminated argument list invoking macro "f"\n} } */
+
+token )

Re: [PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

[Tobias Burnus]

Hi Mark,

On 5/18/20 9:35 AM, Mark Eggleston wrote:

Please find attached a patch for PR39695 (this time it is attached).


Looks okay – with the "dg-(do )compile" change as remarked by Manfred.

[I did wonder whether BLOCK could cause problems with ns->proc_name, but
I couldn't come up with a case where one could have both a
function-return value issue and block.]

Thanks,

Tobias



Commit message:

Fortran  : ProcPtr function results: 'ppr@' in error message PR39695

The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.

2020-05-18  Mark Eggleston 

gcc/fortran/

PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending on
whether the result attribute is set.  For PROCEDURE/RESULT
conflict use the name in sym->ns->proc_name->name.
* symbol.c (gfc_add_type): Add check for function and result
attributes use sym->ns->proc_name->name if both are set.
Where the symbol cannot have a type use the name in
sym->ns->proc_name->name.

2020-05-18  Mark Eggleston 

gcc/testsuite/

PR fortran/39695
* gfortran.dg/pr39695_1.f90: New test.
* gfortran.dg/pr39695_2.f90: New test.
* gfortran.dg/pr39695_3.f90: New test.
* gfortran.dg/pr39695_4.f90: New test.

Tested on x86_64 using make check-fortran for master, gcc-8, gcc-9 and
gcc-10.

OK to to commit and backport?


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: [PATCH] tsan: Add optional support for distinguishing volatiles

[Martin Liška]

On 5/18/20 1:52 PM, Dmitry Vyukov via Gcc-patches wrote:

Jakub, could you please give some update. Do we just wait? That's
fine, just want to understand because there are some interesting
discussions in the kernel re bumping compiler requirements.
Thanks


Hello.

We switched to stage1 and we're currently working on some infrastructure changes
related ChangeLog entries, -std= default change and others.

If you need the patches for your fuzzing, please install them locally to a GCC 
10.1.0,
or to the current master.

We'll review the changes as soon as possible.
Martin

Re: [PATCH] Fix component mappings with derived types for OpenACC

[Thomas Schwinge]

Hi!

On 2020-01-28T13:41:00+, Julian Brown  wrote:
> On Fri, 24 Jan 2020 10:58:49 +0100
> Tobias Burnus  wrote:
>> the gfortran part is rather obvious and it and the test case look
>> fine to me → OK.
>> The oacc-mem.c also looks okay, but I assume Thomas needs to
>> rubber-stamp it.
>
> I understand that Thomas is unavailable for the time being, so won't be
> able to use his rubber-stamp powers. I added the offending libgomp code
> to start with though, so I think I can go ahead and commit the patch.
> I'll hold off for 24 hours though in case there are any objections
> (Jakub?).

So, in the end you didn't commit this, and now we've got the "un-fixed"
OpenACC/Fortran code generation in the GCC 10.1 release, so have to deal
with it in one way or another going forward, regarding libgomp ABI
compatibility.  (Ideally), we need to make sure that "un-fixed" GCC
10.1-built executables continue to work "as good as before" when
dynamically linked/running against "fixed" GCC 10.1+ shared libraries.

Do we get such desired behavior by the patch quoted below?  In
particular: removing the 'GOMP_MAP_STRUCT' handling code, but leaving in
the empty 'case GOMP_MAP_STRUCT:' as a no-op, so that we don't run into
'default:' case 'goacc_exit_data_internal UNHANDLED kind'?  Is that
sufficient?

Is my understanding correct that "fixed" GCC won't generate such
'GOMP_MAP_STRUCT' anymore (I have't studied in detail), and this empty
'case GOMP_MAP_STRUCT:' only remains in here for backwards compatibility?
In this case, please add a comment to the code, stating this.  Otherwise,
please add a comment why "do nothing" is appropriate for
'GOMP_MAP_STRUCT'.  In particular, for both scenarios, why we don't need
to skip the following 'sizes[i]' mappings?


Grüße
 Thomas


>> On 1/10/20 2:49 AM, Julian Brown wrote:
>> > This patch fixes a bug with mapping Fortran components (i.e. with
>> > the manual deep-copy support) which themselves have derived types.
>> > I've also added a couple of new tests to make sure such mappings
>> > are lowered correctly, and to check for the case that Tobias found
>> > in the message:
>> >
>> >https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00215.html
>> >
>> > The previous incorrect mapping was causing the error condition
>> > mentioned in that message to fail to trigger, and I think (my!)
>> > code in libgomp (goacc_exit_data_internal) to handle
>> > GOMP_MAP_STRUCT specially was papering over the bad mapping also.
>> > Oops!
>> >
>> > I haven't attempted to implement the (harder) sub-copy detection, if
>> > that is indeed supposed to be forbidden by the spec. This patch
>> > should get us to the same behaviour in Fortran as in C & C++ though.
>> >
>> > Tested with offloading to nvptx, also with the (uncommitted)
>> > reference-count self-checking patch enabled.
>> >
>> > OK?
>> >
>> > Thanks,
>> >
>> > Julian
>> >
>> > ChangeLog
>> >
>> >  gcc/fortran/
>> >  * trans-openmp.c (gfc_trans_omp_clauses): Use inner not decl
>> > for components with derived types.
>> >
>> >  gcc/testsuite/
>> >  * gfortran.dg/goacc/mapping-tests-3.f90: New test.
>> >  * gfortran.dg/goacc/mapping-tests-4.f90: New test.
>> >
>> >  libgomp/
>> >  * oacc-mem.c (goacc_exit_data_internal): Remove special
>> > (no-copyback) behaviour for GOMP_MAP_STRUCT.
>> >
>> > component-mappings-derived-types-1.diff
>> >
>> > commit 5e9d8846bbaa33a9bdb08adcf1ee9f224a8e8fc0
>> > Author: Julian Brown
>> > Date:   Wed Jan 8 15:57:46 2020 -0800
>> >
>> >  Fix component mappings with derived types for OpenACC
>> >
>> >  gcc/fortran/
>> >  * trans-openmp.c (gfc_trans_omp_clauses): Use inner
>> > not decl for components with derived types.
>> >
>> >  gcc/testsuite/
>> >  * gfortran.dg/goacc/mapping-tests-3.f90: New test.
>> >  * gfortran.dg/goacc/mapping-tests-4.f90: New test.
>> >
>> >  libgomp/
>> >  * oacc-mem.c (goacc_exit_data_internal): Remove
>> > special (no-copyback) behaviour for GOMP_MAP_STRUCT.
>> >
>> > diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
>> > index 9835d2aae3c..efc392d7fa6 100644
>> > --- a/gcc/fortran/trans-openmp.c
>> > +++ b/gcc/fortran/trans-openmp.c
>> > @@ -2783,9 +2783,9 @@ gfc_trans_omp_clauses (stmtblock_t *block,
>> > gfc_omp_clauses *clauses, }
>> >  else
>> >{
>> > -OMP_CLAUSE_DECL (node) = decl;
>> > +OMP_CLAUSE_DECL (node) = inner;
>> >  OMP_CLAUSE_SIZE (node)
>> > -  = TYPE_SIZE_UNIT (TREE_TYPE (decl));
>> > +  = TYPE_SIZE_UNIT (TREE_TYPE (inner));
>> >}
>> >}
>> >  else if (lastcomp->next
>> > diff --git a/gcc/testsuite/gfortran.dg/goacc/mapping-tests-3.f90
>> > b/gcc/testsuite/gfortran.dg/goacc/mapping-tests-3.f90 new file mode
>> > 100644 index 000..312f596461e
>> > --- /dev/null
>> 

[PATCH] x86: Add cmpmemsi for -minline-all-stringops

[H.J. Lu via Gcc-patches]

On Tue, May 19, 2020 at 1:48 AM Uros Bizjak  wrote:
>
> On Sun, May 17, 2020 at 7:06 PM H.J. Lu  wrote:
> >
> > Duplicate the cmpstrn pattern for cmpmem.  The only difference is that
> > the length argument of cmpmem is guaranteed to be less than or equal to
> > lengths of 2 memory areas.  Since "repz cmpsb" can be much slower than
> > memcmp function implemented with vector instruction, see
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
> >
> > expand cmpmem to "repz cmpsb" only with -mgeneral-regs-only.
>
> If there is no benefit compared to the library implementation, then
> enable these patterns only when -minline-all-stringops is used.

Fixed.

> Eventually these should be reimplemented with SSE4 string instructions.
>
> Honza is the author of the block handling x86 system, I'll leave the
> review to him.

We used to expand memcmp to "repz cmpsb" via cmpstrnsi.  It was changed
by

commit 9b0f6f5e511ca512e4faeabc81d2fd3abad9b02f
Author: Nick Clifton 
Date:   Fri Aug 12 16:26:11 2011 +

builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi pattern.

* builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi
pattern.
* doc/md.texi (cmpstrn): Note that the comparison stops if both
fetched bytes are zero.
(cmpstr): Likewise.
(cmpmem): Note that the comparison does not stop if both of the
fetched bytes are zero.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151

is a regression.

Honza, can you take a look at this?

Thanks.

--
H.J.
From ec91a57f3f91168034f7f5eb391949c301741680 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Thu, 14 May 2020 13:06:23 -0700
Subject: [PATCH] x86: Add cmpmemsi for -minline-all-stringops
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

We used to expand memcmp to "repz cmpsb" via cmpstrnsi.  It was changed
by

commit 9b0f6f5e511ca512e4faeabc81d2fd3abad9b02f
Author: Nick Clifton 
Date:   Fri Aug 12 16:26:11 2011 +

builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi pattern.

* builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi
pattern.
* doc/md.texi (cmpstrn): Note that the comparison stops if both
fetched bytes are zero.
(cmpstr): Likewise.
(cmpmem): Note that the comparison does not stop if both of the
fetched bytes are zero.

Duplicate the cmpstrn pattern for cmpmem.  The only difference is that
the length argument of cmpmem is guaranteed to be less than or equal to
lengths of 2 memory areas.  Since "repz cmpsb" can be much slower than
memcmp function implemented with vector instruction, see

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

expand cmpmem to "repz cmpsb" only for -minline-all-stringops.

gcc/

	PR target/95151
	* config/i386/i386-expand.c (ix86_expand_cmpstrn_or_cmpmem): New
	function.
	* config/i386/i386-protos.h (ix86_expand_cmpstrn_or_cmpmem): New
	prototype.
	* config/i386/i386.md (cmpmemsi): New pattern.

gcc/testsuite/

	PR target/95151
	* gcc.target/i386/pr95151-1.c: New test.
	* gcc.target/i386/pr95151-2.c: Likewise.
	* gcc.target/i386/pr95151-3.c: Likewise.
	* gcc.target/i386/pr95151-4.c: Likewise.
---
 gcc/config/i386/i386-expand.c | 80 +++
 gcc/config/i386/i386-protos.h |  1 +
 gcc/config/i386/i386.md   | 80 ++-
 gcc/testsuite/gcc.target/i386/pr95151-1.c | 17 +
 gcc/testsuite/gcc.target/i386/pr95151-2.c | 10 +++
 gcc/testsuite/gcc.target/i386/pr95151-3.c | 18 +
 gcc/testsuite/gcc.target/i386/pr95151-4.c | 11 
 7 files changed, 158 insertions(+), 59 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr95151-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr95151-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr95151-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr95151-4.c

diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 79f827fd653..d3f4280ad58 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -7656,6 +7656,86 @@ ix86_expand_set_or_cpymem (rtx dst, rtx src, rtx count_exp, rtx val_exp,
   return true;
 }
 
+/* Expand cmpstrn or memcmp.  */
+
+bool
+ix86_expand_cmpstrn_or_cmpmem (rtx result, rtx src1, rtx src2,
+			   rtx length, rtx align, bool is_cmpstrn)
+{
+  if (optimize_insn_for_size_p () && !TARGET_INLINE_ALL_STRINGOPS)
+return false;
+
+  /* Can't use this if the user has appropriated ecx, esi or edi.  */
+  if (fixed_regs[CX_REG] || fixed_regs[SI_REG] || fixed_regs[DI_REG])
+return false;
+
+  if (is_cmpstrn)
+{
+  /* For strncmp, length is the maximum length, which can be larger
+	 than actual string lengths.  We can expand the cmpstrn pattern
+	 to "repz cmpsb" only if one of the strings is a constant so
+	 that expand_builtin_strncmp() can write the length argument to
+	 be the 

Re: openmp: Add basic library allocator support

[Jakub Jelinek via Gcc-patches]

On Tue, May 19, 2020 at 04:56:51AM -0700, H.J. Lu wrote:
> > 2020-05-19  Jakub Jelinek  
> >
> > * omp.h.in (omp_uintptr_t): New typedef.
> > (__GOMP_UINTPTR_T_ENUM): Define.
> > (omp_memspace_handle_t, omp_allocator_handle_t, 
> > omp_alloctrait_key_t,
> > omp_alloctrait_value_t, omp_alloctrait_t): New typedefs.
> > (__GOMP_DEFAULT_NULL_ALLOCATOR): Define.
> > (omp_init_allocator, omp_destroy_allocator, 
> > omp_set_default_allocator,
> > omp_get_default_allocator, omp_alloc, omp_free): Declare.
> > * libgomp.h (struct gomp_team_state): Add def_allocator field.
> > (gomp_def_allocator): Declare.
> > * libgomp.map (OMP_5.0.1): Export omp_set_default_allocator,
> > omp_get_default_allocator, omp_init_allocator, 
> > omp_destroy_allocator,
> > omp_alloc and omp_free.
> > * team.c (gomp_team_start): Copy over ts.def_allocator.
> > * env.c (gomp_def_allocator): New variable.
> > (parse_wait_policy): Adjust function comment.
> > (parse_allocator): New function.
> > (handle_omp_display_env): Print OMP_ALLOCATOR.
> > (initialize_env): Call parse_allocator.
> > * Makefile.am (libgomp_la_SOURCES): Add allocator.c.
> > * allocator.c: New file.
> > * icv.c (omp_set_default_allocator, omp_get_default_allocator): New
> > functions.
> > * testsuite/libgomp.c-c++-common/alloc-1.c: New test.
> > * testsuite/libgomp.c-c++-common/alloc-2.c: New test.
> > * testsuite/libgomp.c-c++-common/alloc-3.c: New test.
> > * Makefile.in: Regenerated.
> 
> Did you check in allocator.c?

Forgot to git add it, fixed in r11-494-ge107157171af25f6c89be02d62b0a7235a5c988d
On the bright side, Martin's pre-commit-hook would reject it because of
that, but I've committed it immediately before installing the hook :(.
Sorry.

Jakub

Re: [PATCH][PPC64] [PR88877]

[kamlesh kumar via Gcc-patches]

can someone look at the patch, please?


On Wed, Apr 8, 2020 at 9:29 PM Jeff Law  wrote:

> On Mon, 2020-04-06 at 14:58 +0530, kamlesh kumar via Gcc-patches wrote:
> > Hi Richard,
> > Here is a discussion we did some time ago
> > https://gcc.gnu.org/pipermail/gcc/2019-January/227834.html
> > please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 for more
> > info regarding the bug.
> >
> > We incorporated below Jakub's suggestion in this patch.
> >
> > Jakub wrote:
> > ""
> > Yeah, all the callers of emit_library_call* would need to be changed to
> pass
> > triplets rtx, machine_mode, int/bool /*unsignedp*/, instead of just
> > rtx_mode_t pair.
> > Jakub
> > ""
> I think you're generally on the right track here, but I'm deferring this
> to gcc11
> (other maintainers are, of course, welcome to push it for gcc10 as it's a
> code
> correctness issue).
>
> Jeff
> >
>
>

Re: openmp: Add basic library allocator support

[H.J. Lu via Gcc-patches]

On Tue, May 19, 2020 at 1:27 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> Hi!
>
> This patch adds very basic allocator support (omp_{init,destroy}_allocator,
> omp_{alloc,free}, omp_[sg]et_default_allocator).
> The plan is to use memkind (likely dlopened) for high bandwidth memory, but
> that part isn't implemented yet, probably mlock for pinned memory and see
> what other options there are for other kinds of memory.
> For offloading targets, we need to decide if we want to support the
> dynamic allocators (and on which targets), or if e.g. all we do is at compile
> time replace omp_alloc/omp_free calls with constexpr predefined allocators
> with something special.
>
> And allocate directive and allocator/uses_allocators clauses are future work
> too.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
>
> 2020-05-19  Jakub Jelinek  
>
> * omp.h.in (omp_uintptr_t): New typedef.
> (__GOMP_UINTPTR_T_ENUM): Define.
> (omp_memspace_handle_t, omp_allocator_handle_t, omp_alloctrait_key_t,
> omp_alloctrait_value_t, omp_alloctrait_t): New typedefs.
> (__GOMP_DEFAULT_NULL_ALLOCATOR): Define.
> (omp_init_allocator, omp_destroy_allocator, omp_set_default_allocator,
> omp_get_default_allocator, omp_alloc, omp_free): Declare.
> * libgomp.h (struct gomp_team_state): Add def_allocator field.
> (gomp_def_allocator): Declare.
> * libgomp.map (OMP_5.0.1): Export omp_set_default_allocator,
> omp_get_default_allocator, omp_init_allocator, omp_destroy_allocator,
> omp_alloc and omp_free.
> * team.c (gomp_team_start): Copy over ts.def_allocator.
> * env.c (gomp_def_allocator): New variable.
> (parse_wait_policy): Adjust function comment.
> (parse_allocator): New function.
> (handle_omp_display_env): Print OMP_ALLOCATOR.
> (initialize_env): Call parse_allocator.
> * Makefile.am (libgomp_la_SOURCES): Add allocator.c.
> * allocator.c: New file.
> * icv.c (omp_set_default_allocator, omp_get_default_allocator): New
> functions.
> * testsuite/libgomp.c-c++-common/alloc-1.c: New test.
> * testsuite/libgomp.c-c++-common/alloc-2.c: New test.
> * testsuite/libgomp.c-c++-common/alloc-3.c: New test.
> * Makefile.in: Regenerated.

Did you check in allocator.c?

-- 
H.J.

[PATCH] mklog.py: improve parsing of struct names (ignore GTY).

[Martin Liška]

Hi.

It's a small tweak to the newly added script.

Installed.

Martin

* mklog.py: Skip GTY for struct names.  Make flake8 happy.
* test_mklog.py: Add test for GTY.
---
 contrib/ChangeLog |  5 +
 contrib/mklog.py  | 12 
 contrib/test_mklog.py | 29 +
 3 files changed, 42 insertions(+), 4 deletions(-)


diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index ca2834e541f..5ef08f41a92 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,8 @@
+2020-05-19  Martin Liska  
+
+	* mklog.py: Skip GTY for struct names.  Make flake8 happy.
+	* test_mklog.py: Add test for GTY.
+
 2020-05-19  Martin Liska  
 
 	* gcc-changelog/git_update_version.py:
diff --git a/contrib/mklog.py b/contrib/mklog.py
index cc3f937c253..45559afbe6b 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -27,18 +27,21 @@
 # Author: Martin Liska 
 
 import argparse
-import bs4
 import os
 import re
-import requests
 import sys
 
+import bs4
+
+import requests
+
 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_]+)')
+struct_regex = re.compile(r'^(class|struct|union|enum)\s+'
+  r'(GTY\(.*\)\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*\([^*]')
@@ -73,7 +76,7 @@ def extract_function_name(line):
 m = struct_regex.search(line)
 if m:
 # Struct declaration
-return m.group(1)
+return m.group(1) + ' ' + m.group(3)
 m = macro_regex.search(line)
 if m:
 # Macro definition
@@ -117,6 +120,7 @@ def get_pr_titles(prs):
 output += '\n'
 return output
 
+
 def generate_changelog(data, no_functions=False, fill_pr_titles=False):
 changelogs = {}
 changelog_list = []
diff --git a/contrib/test_mklog.py b/contrib/test_mklog.py
index ca7b9e79d95..774b6ea62d0 100755
--- a/contrib/test_mklog.py
+++ b/contrib/test_mklog.py
@@ -319,6 +319,31 @@ gcc/testsuite/ChangeLog:
 
 '''
 
+PATCH6 = '''\
+diff --git a/gcc/cgraph.h b/gcc/cgraph.h
+index 5ddeb65269b..cfae6e91da9 100644
+--- a/gcc/cgraph.h
 b/gcc/cgraph.h
+@@ -937,7 +937,8 @@ struct GTY((tag ("SYMTAB_FUNCTION"))) cgraph_node : public symtab_node
+   split_part (false), indirect_call_target (false), local (false),
+   versionable (false), can_change_signature (false),
+   redefined_extern_inline (false), tm_may_enter_irr (false),
+-  ipcp_clone (false), m_uid (uid), m_summary_id (-1)
++  ipcp_clone (false), declare_variant_alt (false),
++  calls_declare_variant_alt (false), m_uid (uid), m_summary_id (-1)
+   {}
+ 
+   /* Remove the node from cgraph and all inline clones inlined into it.
+
+'''
+
+EXPECTED6 = '''\
+gcc/ChangeLog:
+
+	* cgraph.h (struct cgraph_node):
+
+'''
+
 class TestMklog(unittest.TestCase):
 def test_macro_definition(self):
 changelog = generate_changelog(PATCH1)
@@ -343,3 +368,7 @@ class TestMklog(unittest.TestCase):
 def test_pr_bugzilla_download(self):
 changelog = generate_changelog(PATCH5, fill_pr_titles=True)
 assert changelog == EXPECTED5
+
+def test_gty_in_struct(self):
+changelog = generate_changelog(PATCH6, fill_pr_titles=True)
+assert changelog == EXPECTED6

Re: [PATCH][WIP] enfoce SLP_TREE_VECTYPE a bit

[Richard Biener]

On Tue, 19 May 2020, Richard Sandiford wrote:

> Richard Biener  writes:
> > So I came up with this, yet another overload of vect_is_simple_use (ick).
> > But at least for the two functions I tackled it seems to be 
> > straight-forward.
> >
> > I'll see to enforce a type on all invariants in vect_get_constant_vectors
> > and thus try to adjust all other vectorizable_* (but I'm sure I'll miss
> > some...).
> >
> > Comments still welcome.  The patch below passes vect.exp testing on
> > x86_64-linux.
> 
> LGTM FWIW.  Just wondering...
> 
> > @@ -11710,6 +11735,58 @@ vect_is_simple_use (tree operand, vec_info *vinfo, 
> > enum vect_def_type *dt,
> >return true;
> >  }
> >  
> > +/* Function vect_is_simple_use.
> > +
> > +   Same as vect_is_simple_use but determines the operand by operand
> > +   position OPERAND from either STMT or SLP_NODE, filling in *OP
> > +   and *SLP_DEF (when SLP_NODE is not NULL).  */
> > +
> > +bool
> > +vect_is_simple_use (vec_info *vinfo, stmt_vec_info stmt, slp_tree slp_node,
> > +   unsigned operand, tree *op, slp_tree *slp_def,
> > +   enum vect_def_type *dt,
> > +   tree *vectype, stmt_vec_info *def_stmt_info_out)
> > +{
> > +  if (slp_node)
> > +{
> > +  if (operand >= SLP_TREE_CHILDREN (slp_node).length ())
> > +   return false;
> 
> ...which case needs the return false?  Asserting for out-of-range
> indices (like for !slp_node) feels like it would hide fewer bugs.

vectorizable_operation happily puts rhs1 from a load stmt to
vect_is_simple_use ... it has a "negative" list of things it
doesn't want to handle (ick) and goes through for all the rest.

I agree though, I'll see to adjust this (the particular case being
easy).

Richard.

> Thanks,
> Richard
> 
> > +  slp_tree child = SLP_TREE_CHILDREN (slp_node)[operand];
> > +  *slp_def = child;
> > +  if (SLP_TREE_DEF_TYPE (child) == vect_internal_def)
> > +   *op = gimple_get_lhs (SLP_TREE_SCALAR_STMTS (child)[0]->stmt);
> > +  else
> > +   *op = SLP_TREE_SCALAR_OPS (child)[0];
> > +}
> > +  else
> > +{
> > +  if (gassign *ass = dyn_cast  (stmt->stmt))
> > +   *op = gimple_op (ass, operand + 1);
> > +  else if (gcall *call = dyn_cast  (stmt->stmt))
> > +   *op = gimple_call_arg (call, operand);
> > +  else
> > +   gcc_unreachable ();
> > +}
> > +
> > +  /* ???  We might want to update *vectype from *slp_def here though
> > + when sharing nodes this would prevent unsharing in the caller.  */
> > +  return vect_is_simple_use (*op, vinfo, dt, vectype, def_stmt_info_out);
> > +}
> > +
> > +/* If OP is not NULL and is external or constant update its vector
> > +   type with VECTYPE.  Returns true if successful or false if not,
> > +   for example when conflicting vector types are present.  */
> > +
> > +bool
> > +vect_maybe_update_slp_op_vectype (slp_tree op, tree vectype)
> > +{
> > +  if (!op || SLP_TREE_DEF_TYPE (op) == vect_internal_def)
> > +return true;
> > +  if (SLP_TREE_VECTYPE (op))
> > +return types_compatible_p (SLP_TREE_VECTYPE (op), vectype);
> > +  SLP_TREE_VECTYPE (op) = vectype;
> > +  return true;
> > +}
> >  
> >  /* Function supportable_widening_operation
> >  
> > diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
> > index 38a0a1d278b..5b4188d08a3 100644
> > --- a/gcc/tree-vectorizer.h
> > +++ b/gcc/tree-vectorizer.h
> > @@ -1695,6 +1695,11 @@ extern bool vect_is_simple_use (tree, vec_info *, 
> > enum vect_def_type *,
> >  extern bool vect_is_simple_use (tree, vec_info *, enum vect_def_type *,
> > tree *, stmt_vec_info * = NULL,
> > gimple ** = NULL);
> > +extern bool vect_is_simple_use (vec_info *, stmt_vec_info, slp_tree,
> > +   unsigned, tree *, slp_tree *,
> > +   enum vect_def_type *,
> > +   tree *, stmt_vec_info * = NULL);
> > +extern bool vect_maybe_update_slp_op_vectype (slp_tree, tree);
> >  extern bool supportable_widening_operation (vec_info *,
> > enum tree_code, stmt_vec_info,
> > tree, tree, enum tree_code *,
> 

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

Re: [PATCH][WIP] enfoce SLP_TREE_VECTYPE a bit

[Richard Sandiford]

Richard Biener  writes:
> So I came up with this, yet another overload of vect_is_simple_use (ick).
> But at least for the two functions I tackled it seems to be straight-forward.
>
> I'll see to enforce a type on all invariants in vect_get_constant_vectors
> and thus try to adjust all other vectorizable_* (but I'm sure I'll miss
> some...).
>
> Comments still welcome.  The patch below passes vect.exp testing on
> x86_64-linux.

LGTM FWIW.  Just wondering...

> @@ -11710,6 +11735,58 @@ vect_is_simple_use (tree operand, vec_info *vinfo, 
> enum vect_def_type *dt,
>return true;
>  }
>  
> +/* Function vect_is_simple_use.
> +
> +   Same as vect_is_simple_use but determines the operand by operand
> +   position OPERAND from either STMT or SLP_NODE, filling in *OP
> +   and *SLP_DEF (when SLP_NODE is not NULL).  */
> +
> +bool
> +vect_is_simple_use (vec_info *vinfo, stmt_vec_info stmt, slp_tree slp_node,
> + unsigned operand, tree *op, slp_tree *slp_def,
> + enum vect_def_type *dt,
> + tree *vectype, stmt_vec_info *def_stmt_info_out)
> +{
> +  if (slp_node)
> +{
> +  if (operand >= SLP_TREE_CHILDREN (slp_node).length ())
> + return false;

...which case needs the return false?  Asserting for out-of-range
indices (like for !slp_node) feels like it would hide fewer bugs.

Thanks,
Richard

> +  slp_tree child = SLP_TREE_CHILDREN (slp_node)[operand];
> +  *slp_def = child;
> +  if (SLP_TREE_DEF_TYPE (child) == vect_internal_def)
> + *op = gimple_get_lhs (SLP_TREE_SCALAR_STMTS (child)[0]->stmt);
> +  else
> + *op = SLP_TREE_SCALAR_OPS (child)[0];
> +}
> +  else
> +{
> +  if (gassign *ass = dyn_cast  (stmt->stmt))
> + *op = gimple_op (ass, operand + 1);
> +  else if (gcall *call = dyn_cast  (stmt->stmt))
> + *op = gimple_call_arg (call, operand);
> +  else
> + gcc_unreachable ();
> +}
> +
> +  /* ???  We might want to update *vectype from *slp_def here though
> + when sharing nodes this would prevent unsharing in the caller.  */
> +  return vect_is_simple_use (*op, vinfo, dt, vectype, def_stmt_info_out);
> +}
> +
> +/* If OP is not NULL and is external or constant update its vector
> +   type with VECTYPE.  Returns true if successful or false if not,
> +   for example when conflicting vector types are present.  */
> +
> +bool
> +vect_maybe_update_slp_op_vectype (slp_tree op, tree vectype)
> +{
> +  if (!op || SLP_TREE_DEF_TYPE (op) == vect_internal_def)
> +return true;
> +  if (SLP_TREE_VECTYPE (op))
> +return types_compatible_p (SLP_TREE_VECTYPE (op), vectype);
> +  SLP_TREE_VECTYPE (op) = vectype;
> +  return true;
> +}
>  
>  /* Function supportable_widening_operation
>  
> diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
> index 38a0a1d278b..5b4188d08a3 100644
> --- a/gcc/tree-vectorizer.h
> +++ b/gcc/tree-vectorizer.h
> @@ -1695,6 +1695,11 @@ extern bool vect_is_simple_use (tree, vec_info *, enum 
> vect_def_type *,
>  extern bool vect_is_simple_use (tree, vec_info *, enum vect_def_type *,
>   tree *, stmt_vec_info * = NULL,
>   gimple ** = NULL);
> +extern bool vect_is_simple_use (vec_info *, stmt_vec_info, slp_tree,
> + unsigned, tree *, slp_tree *,
> + enum vect_def_type *,
> + tree *, stmt_vec_info * = NULL);
> +extern bool vect_maybe_update_slp_op_vectype (slp_tree, tree);
>  extern bool supportable_widening_operation (vec_info *,
>   enum tree_code, stmt_vec_info,
>   tree, tree, enum tree_code *,

[PATCH][OBVIOUS] Fill up entries in reverse order.

[Martin Liška]

Hi.

Older entries should be added first.

Installed.

contrib/ChangeLog:

* gcc-changelog/git_update_version.py:
Fill up entries in reverse order.
---
 contrib/gcc-changelog/git_update_version.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/contrib/gcc-changelog/git_update_version.py b/contrib/gcc-changelog/git_update_version.py
index c66b4d68e68..2de44f27580 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -93,7 +93,7 @@ for ref in origin.refs:
 # TODO: set strict=True after testing period
 commits = parse_git_revisions(args.git_path, '%s..HEAD'
   % commit.hexsha, strict=False)
-for git_commit in commits:
+for git_commit in reversed(commits):
 prepend_to_changelog_files(repo, args.git_path, git_commit)
 # update timestamp
 with open(datestamp_path, 'w+') as f:

[COMMITTED 1/2] bpf: add support for the -mxbpf option

[Jose E. Marchesi via Gcc-patches]

This patch adds support for a new option -mxbpf.  This tells GCC to
generate code for an expanded version of BPF that relaxes some of the
restrictions imposed by BPF.

2020-05-19  Jose E. Marchesi  

gcc/
* config/bpf/bpf.opt (mxbpf): New option.
* doc/invoke.texi (Option Summary): Add -mxbpf.
(eBPF Options): Document -mxbbpf.
---
 gcc/ChangeLog  | 6 ++
 gcc/config/bpf/bpf.opt | 6 ++
 gcc/doc/invoke.texi| 6 +-
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 418fec484ae..ef3bcee3911 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-05-19  Jose E. Marchesi  
+
+   * config/bpf/bpf.opt (mxbpf): New option.
+   * doc/invoke.texi (Option Summary): Add -mxbpf.
+   (eBPF Options): Document -mxbbpf.
+
 2020-05-19  Uroš Bizjak  
 
PR target/92658
diff --git a/gcc/config/bpf/bpf.opt b/gcc/config/bpf/bpf.opt
index 78b93c55575..6aa858408f1 100644
--- a/gcc/config/bpf/bpf.opt
+++ b/gcc/config/bpf/bpf.opt
@@ -108,6 +108,12 @@ Enum(bpf_kernel) String(5.1) Value(LINUX_V5_1)
 EnumValue
 Enum(bpf_kernel) String(5.2) Value(LINUX_V5_2)
 
+; Use xBPF extensions.
+
+mxbpf
+Target Report Mask(XBPF)
+Generate xBPF.
+
 ; Selecting big endian or little endian targets.
 
 mbig-endian
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 850aeac033d..0c33deb830b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -862,7 +862,7 @@ Objective-C and Objective-C++ Dialects}.
 
 @emph{eBPF Options}
 @gccoptlist{-mbig-endian -mlittle-endian -mkernel=@var{version}
--mframe-limit=@var{bytes}}
+-mframe-limit=@var{bytes} -mxbpf}
 
 @emph{FR30 Options}
 @gccoptlist{-msmall-model  -mno-lsim}
@@ -21013,6 +21013,10 @@ Generate code for a big-endian target.
 @item -mlittle-endian
 @opindex mlittle-endian
 Generate code for a little-endian target.  This is the default.
+
+@item -mxbpf
+Generate code for an expanded version of BPF, which relaxes some of
+the restrictions imposed by the BPF architecture.
 @end table
 
 @node FR30 Options
-- 
2.25.0.2.g232378479e

[COMMITTED 2/2] bpf: do not save/restore callee-saved registers in function prolog/epilog

[Jose E. Marchesi via Gcc-patches]

BPF considers that every call to a function allocates a fresh set of
registers that are available to the callee, of which the first five
may have bee initialized with the function arguments.  This is
implemented by both interpreter and JIT in the Linux kernel.

This is enforced by the kernel BPF verifier, which will reject any
code in which non-initialized registers are accessed before being
written.  Consequently, the spill instructions generated in function
prologue were causing the verifier to reject our compiled programs.

This patch makes GCC to not save/restore callee-saved registers in
function prologue/epilogue, unless xBPF mode is enabled.

2020-05-19  Jose E. Marchesi  

gcc/
* config/bpf/bpf.c (bpf_compute_frame_layout): Include space for
callee saved registers only in xBPF.
(bpf_expand_prologue): Save callee saved registers only in xBPF.
(bpf_expand_epilogue): Likewise for restoring.
* doc/invoke.texi (eBPF Options): Document this is activated by
-mxbpf.

gcc/testsuite/
* gcc.target/bpf/xbpf-callee-saved-regs-1.c: New test.
* gcc.target/bpf/xbpf-callee-saved-regs-2.c: Likewise.
---
 gcc/ChangeLog |   9 ++
 gcc/config/bpf/bpf.c  | 133 ++
 gcc/doc/invoke.texi   |   6 +-
 gcc/testsuite/ChangeLog   |   5 +
 .../gcc.target/bpf/xbpf-callee-saved-regs-1.c |  17 +++
 .../gcc.target/bpf/xbpf-callee-saved-regs-2.c |  17 +++
 6 files changed, 129 insertions(+), 58 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/bpf/xbpf-callee-saved-regs-1.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/xbpf-callee-saved-regs-2.c

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ef3bcee3911..8447bd56d98 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2020-05-19  Jose E. Marchesi  
+
+   * config/bpf/bpf.c (bpf_compute_frame_layout): Include space for
+   callee saved registers only in xBPF.
+   (bpf_expand_prologue): Save callee saved registers only in xBPF.
+   (bpf_expand_epilogue): Likewise for restoring.
+   * doc/invoke.texi (eBPF Options): Document this is activated by
+   -mxbpf.
+
 2020-05-19  Jose E. Marchesi  
 
* config/bpf/bpf.opt (mxbpf): New option.
diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
index 368b99c199e..36e08338630 100644
--- a/gcc/config/bpf/bpf.c
+++ b/gcc/config/bpf/bpf.c
@@ -267,15 +267,18 @@ bpf_compute_frame_layout (void)
 
   cfun->machine->local_vars_size += padding_locals;
 
-  /* Set the space used in the stack by callee-saved used registers in
- the current function.  There is no need to round up, since the
- registers are all 8 bytes wide.  */
-  for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
-if ((df_regs_ever_live_p (regno)
-&& !call_used_or_fixed_reg_p (regno))
-   || (cfun->calls_alloca
-   && regno == STACK_POINTER_REGNUM))
-  cfun->machine->callee_saved_reg_size += 8;
+  if (TARGET_XBPF)
+{
+  /* Set the space used in the stack by callee-saved used
+registers in the current function.  There is no need to round
+up, since the registers are all 8 bytes wide.  */
+  for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
+   if ((df_regs_ever_live_p (regno)
+&& !call_used_or_fixed_reg_p (regno))
+   || (cfun->calls_alloca
+   && regno == STACK_POINTER_REGNUM))
+ cfun->machine->callee_saved_reg_size += 8;
+}
 
   /* Check that the total size of the frame doesn't exceed the limit
  imposed by eBPF.  */
@@ -299,38 +302,50 @@ bpf_compute_frame_layout (void)
 void
 bpf_expand_prologue (void)
 {
-  int regno, fp_offset;
   rtx insn;
   HOST_WIDE_INT size;
 
   size = (cfun->machine->local_vars_size
  + cfun->machine->callee_saved_reg_size);
-  fp_offset = -cfun->machine->local_vars_size;
 
-  /* Save callee-saved hard registes.  The register-save-area starts
- right after the local variables.  */
-  for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
+  /* The BPF "hardware" provides a fresh new set of registers for each
+ called function, some of which are initialized to the values of
+ the arguments passed in the first five registers.  In doing so,
+ it saves the values of the registers of the caller, and restored
+ them upon returning.  Therefore, there is no need to save the
+ callee-saved registers here.  What is worse, the kernel
+ implementation refuses to run programs in which registers are
+ referred before being initialized.  */
+  if (TARGET_XBPF)
 {
-  if ((df_regs_ever_live_p (regno)
-  && !call_used_or_fixed_reg_p (regno))
- || (cfun->calls_alloca
- && regno == STACK_POINTER_REGNUM))
-   {
- rtx mem;
+  int regno;
+  int fp_offset = -cfun->machine->local_vars_size;
 
- if (!IN_RANGE (fp_offset, -1 

[COMMITTED 0/2][BPF] Introduce -mxbpf and first extension

[Jose E. Marchesi via Gcc-patches]

Hi people!

I just committed these two BPF-specific small patches.  See each
commit for a description.

Hope I didn't screw up with the ChangeLog entries in the commit
message! :)

Salud!

Jose E. Marchesi (2):
  bpf: add support for the -mxbpf option
  bpf: do not save/restore callee-saved registers in function
prolog/epilog

 gcc/ChangeLog |  15 ++
 gcc/config/bpf/bpf.c  | 133 ++
 gcc/config/bpf/bpf.opt|   6 +
 gcc/doc/invoke.texi   |  10 +-
 gcc/testsuite/ChangeLog   |   5 +
 .../gcc.target/bpf/xbpf-callee-saved-regs-1.c |  17 +++
 .../gcc.target/bpf/xbpf-callee-saved-regs-2.c |  17 +++
 7 files changed, 145 insertions(+), 58 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/bpf/xbpf-callee-saved-regs-1.c
 create mode 100644 gcc/testsuite/gcc.target/bpf/xbpf-callee-saved-regs-2.c

-- 
2.25.0.2.g232378479e

[PATCH][WIP] enfoce SLP_TREE_VECTYPE a bit

[Richard Biener]

So I came up with this, yet another overload of vect_is_simple_use (ick).
But at least for the two functions I tackled it seems to be straight-forward.

I'll see to enforce a type on all invariants in vect_get_constant_vectors
and thus try to adjust all other vectorizable_* (but I'm sure I'll miss
some...).

Comments still welcome.  The patch below passes vect.exp testing on
x86_64-linux.

Thanks,
Richard.


This tries to enforce a set SLP_TREE_VECTYPE in vect_get_constant_vectors
and provides some infrastructure for setting it in the vectorizable_*
functions.

2020-05-19  Richard Biener  

* tree-vectorizer.h (vect_is_simple_use): New overload.
(vect_maybe_update_slp_op_vectype): New.
* tree-vect-stmts.c (vect_is_simple_use): New overload
accessing operands of SLP vs. non-SLP operation transparently.
(vect_maybe_update_slp_op_vectype): New function updating
the possibly shared SLP operands vector type.
(vectorizable_operation): Be a bit more SLP vs non-SLP agnostic
using the new vect_is_simple_use overload;  update SLP invariant
operand nodes vector type.
(vectorizable_comparison): Likewise.

* tree-vect-slp.c (vect_get_constant_vectors): Use
SLP_TREE_VECTYPE when set, check it matches previous
behavior.  Enforce SLP_TREE_VECTYPE for boolean vectors.
---
 gcc/tree-vect-slp.c   | 17 +++-
 gcc/tree-vect-stmts.c | 99 ++-
 gcc/tree-vectorizer.h |  5 +++
 3 files changed, 108 insertions(+), 13 deletions(-)

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 69a2002717f..32e0b6677b3 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -3640,9 +3640,22 @@ vect_get_constant_vectors (vec_info *vinfo,
   tree stmt_vectype = STMT_VINFO_VECTYPE (stmt_vinfo);
   if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
   && vect_mask_constant_operand_p (vinfo, stmt_vinfo, op_num))
-vector_type = truth_type_for (stmt_vectype);
+{
+  /* We always want SLP_TREE_VECTYPE (op_node) here correctly set
+as first step.  */
+  vector_type = SLP_TREE_VECTYPE (op_node);
+  gcc_assert (vector_type
+ && types_compatible_p (vector_type,
+truth_type_for (stmt_vectype)));
+}
   else
-vector_type = get_vectype_for_scalar_type (vinfo, TREE_TYPE (op), op_node);
+{
+  vector_type = get_vectype_for_scalar_type (vinfo,
+TREE_TYPE (op), op_node);
+  gcc_assert (!SLP_TREE_VECTYPE (op_node)
+ || types_compatible_p (SLP_TREE_VECTYPE (op_node),
+vector_type));
+}
 
   poly_uint64 vf = 1;
   if (loop_vec_info loop_vinfo = dyn_cast  (vinfo))
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 94f233e2e27..0daf70a4a68 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -5993,8 +5993,9 @@ vectorizable_operation (vec_info *vinfo,
   return false;
 }
 
-  op0 = gimple_assign_rhs1 (stmt);
-  if (!vect_is_simple_use (op0, vinfo, [0], ))
+  slp_tree slp_op0;
+  if (!vect_is_simple_use (vinfo, stmt_info, slp_node,
+  0, , _op0, [0], ))
 {
   if (dump_enabled_p ())
 dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
@@ -6043,10 +6044,11 @@ vectorizable_operation (vec_info *vinfo,
 return false;
 
   tree vectype2 = NULL_TREE, vectype3 = NULL_TREE;
+  slp_tree slp_op1 = NULL, slp_op2 = NULL;
   if (op_type == binary_op || op_type == ternary_op)
 {
-  op1 = gimple_assign_rhs2 (stmt);
-  if (!vect_is_simple_use (op1, vinfo, [1], ))
+  if (!vect_is_simple_use (vinfo, stmt_info, slp_node,
+  1, , _op1, [1], ))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
@@ -6056,8 +6058,8 @@ vectorizable_operation (vec_info *vinfo,
 }
   if (op_type == ternary_op)
 {
-  op2 = gimple_assign_rhs3 (stmt);
-  if (!vect_is_simple_use (op2, vinfo, [2], ))
+  if (!vect_is_simple_use (vinfo, stmt_info, slp_node,
+  2, , _op2, [2], ))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
@@ -6169,6 +6171,18 @@ vectorizable_operation (vec_info *vinfo,
   vectype, NULL);
}
 
+  /* Put types on constant and invariant SLP children.  */
+  if (slp_node
+ && (!vect_maybe_update_slp_op_vectype (slp_op0, vectype)
+ || !vect_maybe_update_slp_op_vectype (slp_op1, vectype)
+ || !vect_maybe_update_slp_op_vectype (slp_op2, vectype)))
+   {
+ if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"incompatible vector types for invariants\n");
+ return false;
+   }
+
 

Re: [PATCH] contrib/gcc-changelog: Handle Reviewed-{by,on}

[Martin Liška]

On 5/19/20 11:45 AM, Frederik Harwath wrote:

Hi,
the new contrib/gcc-changelog/git_check_commit.py script
(which, by the way, is very useful!) does not handle "Reviewed-by" and
"Reviewed-on" lines yet and hence it expects those lines to be indented
by a tab although those lines are usually not indented. The script
already knows about "Co-Authored-By" lines and I have extended it to
handle the "Reviewed-{by,on}" lines in a similar way. The information
from those lines is not processed further since the review information
apparantly does not get included in the ChangeLogs.


Thank you Frederick for the patch.

Looking at what I grepped:
https://github.com/marxin/gcc-changelog/issues/1#issuecomment-621910248

Can you also add 'Signed-off-by'? And please create a list with these
exceptions at the beginning of the script.

Fine with that.
Martin



Ok to commit the patch?

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

Re: [PATCH] testsuite: Match ASCII color code for ubsan's test pattern.

[Kito Cheng]

Hi Jakub:

> s/Ditoo/Ditto/g
Thank for catching that.

> I think I'd prefer instead exporting some env var for all the ubsan
> tests in ubsan.exp that would disable the colorization.

Sounds like it's a better solution, it seems like it can be disable by
UBSAN_OPTIONS=color=never,
I'll try and send another patch later :)

Thanks

[PATCH] contrib/gcc-changelog: Handle Reviewed-{by,on}

[Frederik Harwath]

Hi,
the new contrib/gcc-changelog/git_check_commit.py script
(which, by the way, is very useful!) does not handle "Reviewed-by" and
"Reviewed-on" lines yet and hence it expects those lines to be indented
by a tab although those lines are usually not indented. The script
already knows about "Co-Authored-By" lines and I have extended it to
handle the "Reviewed-{by,on}" lines in a similar way. The information
from those lines is not processed further since the review information
apparantly does not get included in the ChangeLogs.

Ok to commit the patch?

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 0dc9b201bc1607de36cb9b3604a87cc3646292e3 Mon Sep 17 00:00:00 2001
From: Frederik Harwath 
Date: Tue, 19 May 2020 11:15:28 +0200
Subject: [PATCH] contrib/gcc-changelog: Handle Reviewed-{by,on}

git-check-commit.py does not know about "Reviewed-by" and
"Reviewed-on" lines and hence it expects those lines which
follow the ChangeLog entries to be indented by a tab.

This commit makes the script skip those lines.  No further
processing is attempted because the review information
is not part of the ChangeLogs.

contrib/

2020-05-19  Frederik Harwath  

	* gcc-changelog/git_commit.py: Skip over lines starting
	with "Reviewed-by: " or "Reviewed-on: ".
---
 contrib/gcc-changelog/git_commit.py | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index 5214cc36538..ebcf853f02f 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -150,6 +150,8 @@ star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')
 LINE_LIMIT = 100
 TAB_WIDTH = 8
 CO_AUTHORED_BY_PREFIX = 'co-authored-by: '
+REVIEWED_BY_PREFIX = 'reviewed-by: '
+REVIEWED_ON_PREFIX = 'reviewed-on: '
 
 
 class Error:
@@ -344,12 +346,19 @@ class GitCommit:
 else:
 pr_line = line.lstrip()
 
-if line.lower().startswith(CO_AUTHORED_BY_PREFIX):
+lowered_line = line.lower()
+if lowered_line.startswith(CO_AUTHORED_BY_PREFIX):
 name = line[len(CO_AUTHORED_BY_PREFIX):]
 author = self.format_git_author(name)
 self.co_authors.append(author)
 continue
 
+# Skip over review information for now.
+# This avoids errors due to missing tabs on these lines below.
+if lowered_line.startswith((REVIEWED_BY_PREFIX,\
+REVIEWED_ON_PREFIX)):
+continue
+
 # ChangeLog name will be deduced later
 if not last_entry:
 if author_tuple:
-- 
2.17.1

Re: New mklog script

[Martin Liška]

On 5/19/20 10:53 AM, Martin Liška wrote:

On 5/19/20 10:11 AM, Martin Liška wrote:

Can you please share how do you do it? It would be easy to add it.


I added the feature via --fill-up-bug-titles option. It uses common
request and beatifulsoup packages.

Martin


Ok, I'm going to install the following 2 patches that put 2 legacy scripts
into contrib/legacy folder. And a new 'git gcc-mklog' alias is added for the
new one.

Hope other are fine with the change. I'm planning to work on the new script
and fix future limitations.

Martin
>From 577083b84f6851eee0b2d36e26aef42f69676942 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 15 May 2020 00:44:07 +0200
Subject: [PATCH 2/2] New mklog script.

contrib/ChangeLog:

2020-05-15  Martin Liska  

	* gcc-git-customization.sh: Add
	alias.gcc-mklog new hook.
	* mklog.py: New file.
	* test_mklog.py: New file.
---
 contrib/gcc-git-customization.sh |   2 +
 contrib/mklog.py | 223 
 contrib/test_mklog.py| 345 +++
 3 files changed, 570 insertions(+)
 create mode 100755 contrib/mklog.py
 create mode 100755 contrib/test_mklog.py

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index ce293d1fe42..91d378ba32a 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -27,6 +27,8 @@ git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream)
 
 git config alias.gcc-verify '!f() { "`git rev-parse --show-toplevel`/contrib/gcc-changelog/git_check_commit.py" $@; } ; f'
 
+git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.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.py b/contrib/mklog.py
new file mode 100755
index 000..cc3f937c253
--- /dev/null
+++ b/contrib/mklog.py
@@ -0,0 +1,223 @@
+#!/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 bs4
+import os
+import re
+import requests
+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_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', '.cc', '.h', '.inc', '.def'])
+
+help_message = """\
+Generate ChangeLog template for PATCH.
+PATCH must be generated using diff(1)'s -up or -cp options
+(or their equivalent in git).
+"""
+
+script_folder = os.path.realpath(__file__)
+gcc_root = os.path.dirname(os.path.dirname(script_folder))
+
+
+def find_changelog(path):
+folder = os.path.split(path)[0]
+while True:
+if os.path.exists(os.path.join(gcc_root, folder, 'ChangeLog')):
+return folder
+folder = os.path.dirname(folder)
+if folder == '':
+return folder
+raise AssertionError()
+
+
+def extract_function_name(line):
+if comment_regex.match(line):
+return None
+m = struct_regex.search(line)
+if m:
+# Struct declaration
+return m.group(1)
+m = macro_regex.search(line)
+if m:
+# Macro definition
+return m.group(2)
+m = super_macro_regex.search(line)
+if m:
+# Supermacro
+return m.group(1)
+m = fn_regex.search(line)
+if m:
+# Discard template and function parameters.
+fn = m.group(1)
+fn = re.sub(template_and_param_regex, '', fn)
+return fn.rstrip()
+return None
+
+
+def try_add_function(functions, line):
+fn = 

Re: [PATCH] Describe coding conventions surrounding "auto"

[Nicholas Krause via Gcc-patches]

On 5/18/20 6:51 PM, Martin Sebor via Gcc-patches wrote:

On 5/18/20 12:02 PM, Richard Sandiford wrote:

Martin Sebor  writes:

On 5/16/20 4:43 AM, Richard Sandiford wrote:

Sorry for the empty subject line earlier...

Jason Merrill  writes:

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


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

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 rtx_jump_table_data

* (insn)) // OK

+  ...
+if (rtx_jump_table_data *table = dyn_cast 
rtx_jump_table_data *

(insn))  // Avoid

+  ...
+auto *map = new hash_map tree, size_t;

  // OK
+hash_map tree, size_t *map = new hash_map tree, 
size_t;

// 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 name_map::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 const char *, tree

elt : indirect_pool)

+  ...
+makes it obvious that elt is a pair and gives the 
types of

+elt.first and elt.second.  In contrast:
+for (const auto elt : indirect_pool)
+  ...
+gives no immediate indication what elt is or what can
+be done with it.


...there are countless constructs in C++ 98 as well in C where there
is no such indication yet we don't (and very well can't) try to avoid
using them.  Examples include macros, members of structures defined
far away from the point of their use, results of ordinary function
calls, results of overloaded functions or templates, default function
arguments, default template parameters, etc.

By way of a random example from genrecog.c:

   int_set::iterator end
  = std::set_union (trans1->labels.begin (), 
trans1->labels.end (),

    combined->begin (), combined->end (),
    next->begin ());

There is no immediate indication precisely what type 

Re: drop -aux{dir,base}, revamp -dump{dir,base}

[Richard Biener]

On Tue, 19 May 2020, Alexandre Oliva wrote:

> On May 19, 2020, Alexandre Oliva  wrote:
> 
> > - fix spurious outputs.exp test failures on targets that do not support
> >   -gsplit-dwarf
> 
> cope with -gsplit-dwarf errors
> 
> From: Alexandre Oliva 
> 
> On targets that did not support -gsplit-dwarf, we'd get tons of
> spurious failures.  This patch tests for support early on, and drops
> the option and disregards the absence of .dwo files if unsupported.

OK.

> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.misc-tests/outputs.exp (gsplit_dwarf): New.  Use it
> instead of -gsplit-dwarf all over.
>   (outest): Disregard .dwo expectations if unsupported.
> ---
>  gcc/testsuite/gcc.misc-tests/outputs.exp |  452 
> +++---
>  1 file changed, 232 insertions(+), 220 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp 
> b/gcc/testsuite/gcc.misc-tests/outputs.exp
> index a063334..6cb2c64 100644
> --- a/gcc/testsuite/gcc.misc-tests/outputs.exp
> +++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
> @@ -36,6 +36,13 @@ if ![gcc_parallel_test_run_p $b] {
>  }
>  gcc_parallel_test_enable 0
>  
> +set gsplit_dwarf "-gsplit-dwarf"
> +if ![check_no_compiler_messages gsplitdwarf object {
> +void foo (void) { }
> +} "$gsplit_dwarf"] {
> +set gsplit_dwarf ""
> +}
> +
>  # For the test named TEST, run the compiler with SOURCES and OPTS, and
>  # look in DIRS for OUTPUTS.  SOURCES is a list of suffixes for source
>  # files starting with $b in $srcdir/$subdir, OPTS is a string with
> @@ -56,6 +63,7 @@ proc outest { test sources opts dirs outputs } {
>  global b
>  global srcdir
>  global subdir
> +global gsplit_dwarf
>  set src {}
>  foreach s $sources {
>   lappend src $srcdir/$subdir/$b$s
> @@ -78,8 +86,8 @@ proc outest { test sources opts dirs outputs } {
>  foreach d $dirs olist $outputs {
>   foreach og $olist {
>   if { [string index $og 0] == "-" } then {
> - if { [string index $og 1] == "-" || \
> -  [string index $og 1] == "." } then {
> + if { [string index $og 1] == "-" \
> +  || [string index $og 1] == "." } then {
>   set o "$b-$b[string range $og 1 end]"
>   } else {
>   set o "$b$og"
> @@ -93,6 +101,10 @@ proc outest { test sources opts dirs outputs } {
>   } else {
>   set o "$og"
>   }
> + if { "$gsplit_dwarf" == "" \
> +  && [string match "*.dwo" "$og"] } then {
> + continue
> + }
>   if { [file exists $d$o] } then {
>   pass "$test: $d$o"
>   file delete $d$o
> @@ -267,102 +279,102 @@ outest "$b exe ddstovr namedir2" $mult "-o $b.exe 
> -save-temps -dumpdir o/" {o/}
>  # Compiler- and driver-generated aux and dump outputs.
>  # -fdump-rtl-final creates a .c.???r.final dump in the compiler.
>  # -fstack-usage creates a .su aux output in the compiler.
> -# -gsplit-dwarf extracts a .dwo aux output from the .o in the driver.
> -outest "$b asm auxdump 1" $sing "-S -g -fdump-rtl-final -fstack-usage 
> -gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.s}}
> -outest "$b asm auxdump 2" $mult "-S -g -fdump-rtl-final -fstack-usage 
> -gsplit-dwarf" {} {{-1.c.???r.final -1.su -1.s -2.c.???r.final -2.su -2.s}}
> -outest "$b obj auxdump unnamed1" $sing "-c -g -fdump-rtl-final -fstack-usage 
> -gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.dwo -0.o}}
> -outest "$b obj auxdump unnamed2" $mult "-c -g -fdump-rtl-final -fstack-usage 
> -gsplit-dwarf" {} {{-1.c.???r.final -1.su -1.dwo -1.o -2.c.???r.final -2.su 
> -2.dwo -2.o}}
> -
> -outest "$b cpp auxdump named0" $sing "-E -o $b-0.i -g -fdump-rtl-final 
> -fstack-usage -gsplit-dwarf" {} {{-0.i}}
> -outest "$b asm auxdump named0" $sing "-S -o $b-0.s -g -fdump-rtl-final 
> -fstack-usage -gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.s}}
> -outest "$b obj auxdump named0" $sing "-c -o $b-0.o -g -fdump-rtl-final 
> -fstack-usage -gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.dwo -0.o}}
> -outest "$b cpp auxdump namedb" $sing "-E -o $b.i -g -fdump-rtl-final 
> -fstack-usage -gsplit-dwarf" {} {{.i}}
> -outest "$b asm auxdump namedb" $sing "-S -o $b.s -g -fdump-rtl-final 
> -fstack-usage -gsplit-dwarf" {} {{.c.???r.final .su .s}}
> -outest "$b obj auxdump namedb" $sing "-c -o $b.o -g -fdump-rtl-final 
> -fstack-usage -gsplit-dwarf" {} {{.c.???r.final .su .dwo .o}}
> -
> -outest "$b exe auxdump unnamed1" $sing "-g -fdump-rtl-final -fstack-usage 
> -gsplit-dwarf" {} {{a--0.c.???r.final a--0.su a--0.dwo a.{out,exe}}}
> -outest "$b exe auxdump unnamed2" $mult "-g -fdump-rtl-final -fstack-usage 
> -gsplit-dwarf" {} {{a--1.c.???r.final a--1.su a--1.dwo a--2.c.???r.final 
> a--2.su a--2.dwo a.{out,exe}}}
> -outest "$b exe auxdump named0" $sing "-o $b-0.exe -g -fdump-rtl-final 
> -fstack-usage -gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.dwo -0.exe}}
> -outest "$b exe auxdump namedb" $sing "-o 

Re: drop -aux{dir,base}, revamp -dump{dir,base}

[Richard Biener]

On Tue, 19 May 2020, Alexandre Oliva wrote:

> On May 19, 2020, Alexandre Oliva  wrote:
> 
> > - fix a build problem when targeting platforms with an executable suffix
> 
> aux and dump revamp: fix target exec suffix handling
> 
> HAVE_TARGET_EXECUTABLE_SUFFIX is defined only in gcc.c, and in a way
> that requires testing whether it's defined, rather than for nonzero.
> Fixed the new use in gcc.c, copied the fix and the definition to
> lto-wrapper.c.

OK.

> 
> for  gcc/ChangeLog
> 
>   * lto-wrapper.c (HAVE_TARGET_EXECUTABLE_SUFFIX): Define if...
>   (TARGET_EXECUTABLE_SUFFIX): ... is defined; define this to the
>   empty string otherwise.
>   (run_gcc): Test for HAVE_TARGET_EXECUTABLE_SUFFIX with defined.
>   * gcc.c (process_command): Likewise.
> ---
>  gcc/gcc.c |2 +-
>  gcc/lto-wrapper.c |9 -
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/gcc.c b/gcc/gcc.c
> index 1e4ac9d..8c851d7 100644
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -4966,7 +4966,7 @@ process_command (unsigned int decoded_options_count,
> : ((temp = strrchr (obase + 1, '.'))
>&& (xlen = strlen (temp))
>&& (strcmp (temp, ".exe") == 0
> -#if HAVE_TARGET_EXECUTABLE_SUFFIX
> +#if defined(HAVE_TARGET_EXECUTABLE_SUFFIX)
>|| strcmp (temp, TARGET_EXECUTABLE_SUFFIX) == 0
>  #endif
>|| strcmp (obase, "a.out") == 0)))
> diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
> index 026c419..d565b08 100644
> --- a/gcc/lto-wrapper.c
> +++ b/gcc/lto-wrapper.c
> @@ -53,6 +53,13 @@ along with GCC; see the file COPYING3.  If not see
> driver to lto-wrapper.  */
>  #define OFFLOAD_TARGET_NAMES_ENV "OFFLOAD_TARGET_NAMES"
>  
> +/* By default there is no special suffix for target executables.  */
> +#ifdef TARGET_EXECUTABLE_SUFFIX
> +#define HAVE_TARGET_EXECUTABLE_SUFFIX
> +#else
> +#define TARGET_EXECUTABLE_SUFFIX ""
> +#endif
> +
>  enum lto_mode_d {
>LTO_MODE_NONE, /* Not doing LTO.  */
>LTO_MODE_LTO,  /* Normal LTO.  */
> @@ -1509,7 +1516,7 @@ run_gcc (unsigned argc, char *argv[])
> if ((temp = strrchr (obase + 1, '.'))
> && (xlen = strlen (temp))
> && (strcmp (temp, ".exe") == 0
> -#if HAVE_TARGET_EXECUTABLE_SUFFIX
> +#if defined(HAVE_TARGET_EXECUTABLE_SUFFIX)
> || strcmp (temp, TARGET_EXECUTABLE_SUFFIX) == 0
>  #endif
> || strcmp (obase, "a.out") == 0))
> 
> 
> 

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

Re: [PATCH] Describe coding conventions surrounding "auto"

[Richard Sandiford]

Martin Sebor  writes:
>> By way of a random example from genrecog.c:
>>
>>int_set::iterator end
>>   = std::set_union (trans1->labels.begin (), trans1->labels.end 
>> (),
>> combined->begin (), combined->end (),
>> next->begin ());
>>
>> There is no immediate indication precisely what type int_set::iterator
>> is.  All we can tell is that that it's some sort of an iterator, and
>> that should be good enough.  It lets us (even forces us to) write code
>> that satisfies the requirements of the abstraction (whatever it happens
>> to be), and avoid tying it closely to the implementation.  That's
>> a good thing.

 Do you mean that this example should or shouldn't use "auto"?
 Iterators are included in the list above, so the idea was that using
 "auto" would be the recommended style here.
>>>
>>> I meant it as a general example where the exact type isn't (and isn't
>>> supposed to be) apparent to the caller because it's an implementation
>>> detail.
>> 
>> But like I say, the proposal was that this example should use "auto",
>> and it sounds like you might agree.  In that case I don't think the
>> example really helps make the decision about whether the coding
>> standards are useful or not.
>> 
>> Do you have other examples that you think would be better written
>> using "auto" that aren't covered by the list, and aren't covered
>> by Jason's point about template-dependent types?
>
> I think it applies any time mentioning the exact type isn't
> necessary, not just because it might introduce a dependency on
> details that the code doesn't need, but also because it's more
> verbose than the alternative.  The for range loop mentioned
> upthread is an example.
>
> But auto is just one of a number of new core language features
> new in C++.  Unlike some other C++ features(*), I don't think
> it's easily misused, at least not to such an extent to justify
> adding a guideline for us to use safely, consistently, or simply
> in good taste.

I agree a guideline like that would be pointless.  It'd be like
saying "be good". :-)  But the idea with the patch was instead
to have conventions that use objective conditions.  (The rationale
was more subjective of course.)

> Martin
>
> [*] I could see value in guidelines around rvalue references
> or deleted and defaulted functions, for instance, since those
> are easily used in dangerous ways.
>
> PS Herb Sutter has a nice article (as usual) where he summarizes
> commonly raised concerns with auto and his thoughts on them:
> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

Almost always using "auto" seems a bit drastic when we're starting with
a codebase that doesn't use "auto" at all.

TBH I don't find the argument in that article convincing, especially
the part about types often being implicit within expressions.  E.g.
it's true that:

if( find(begin(c), end(c), v) == end(c) )
c.emplace_back(v); 
assert( !c.empty() );

is readable without having any explicit types.  But it doesn't follow
that larger blocks of code are just readable without having explicit
types.  That would be like saying that GCC's 1000-line functions are
just as readable as small functions, since each statement is readable
in isolation.

The article seems to be concentrating on examples that are likely to
crop up in templatised library code rather than in (say) IL processing.
E.g.: take:

   auto size = compute_objsize (ref, ostype, pdecl, poff);

Is that size a tree, some form of wide_int, or a plain HWI?  The answer
decides what you can do with the size.  Using auto here forces you to
look at the prototype of compute_objsize (which eventually might itself
return "auto" on the AAA principle), or look around to see how "size"
is used in practice.

That's not likely to confuse the person writing the code.  But:

   tree size = compute_objsize (ref, ostype, pdecl, poff);

either makes life easier for whoever comes next, or doesn't make
any difference to them either way.  And that's true for longer type
names too.

Like Jason says, the default position if we don't add any guidelines
is that whether "auto" is appropriate is a question for code review.
Maybe some reviewers would accept patches that follow the "almost
always auto" principle.  Others probably would probably reject the
patches and ask for more explicit types to be added.  Others might
accept something in between.

If we don't add any guidelines, that would be the review process
operating correctly.

Thanks,
Richard

Re: ChangeLog files - server and client scripts

[Martin Liška]

Hello.

We've just installed server git hooks that verify git messages
for a correct ChangeLog format. For a limited time period, please
still apply ChangeLog changes to the corresponding ChangeLog files.
We'll use it for comparison of auto-generated CangeLog entries.

The format is documented here:
https://gcc.gnu.org/codingconventions.html#ChangeLogs

And I would recommend to install the new 'git gcc-verify' hook from:
contrib/gcc-git-customization.sh

Feel free to contact me about future troubles you'll see.

Thanks,
Martin

Re: [PATCH] testsuite: Match ASCII color code for ubsan's test pattern.

[Jakub Jelinek via Gcc-patches]

On Tue, May 19, 2020 at 05:13:39PM +0800, Kito Cheng wrote:
> Run gcc testsuite with qemu will print out ascii color code like that:
> 
> ^[[1mc-c++-common/ubsan/builtin-1.c:11:10:^[[1m^[[31m runtime error: 
> ^[[1m^[[0m^[[1mpassing zero to ctz(), which is not a valid 
> argument^[[1m^[[0m^M
> 
> But the match logic in some testcase e.g c-c++-common/ubsan/builtin-1.c, 
> didn't
> consider that:
> 
> (\[^\n\r]*runtime error: passing zero to ctz\\\(\\\), which is not a valid 
> argument\[^\n\r]*(\n|\r\n|\r)){4}
> 
>  - Verified on native X86 and RISC-V qemu full system mode and user mode.

s/Ditoo/Ditto/g
I think I'd prefer instead exporting some env var for all the ubsan
tests in ubsan.exp that would disable the colorization.

Jakub

Re: [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386

[Thomas Koenig via Gcc-patches]

Am 19.05.20 um 04:16 schrieb H.J. Lu via Fortran:

Tested on Linux/x86 and Linux/x86-64.  OK for master?


Libfortran parts are OK.

Regards

Thomas

Re: collect2.exe errors not pruned

[Alexandre Oliva]

Hello, Joseph, Andrew,

Thanks for your feedback.

On Feb 28, 2020, Joseph Myers  wrote:

> On Fri, 28 Feb 2020, Alexandre Oliva wrote:

>> I'm not sure it's appropriate for the error to not omit the host
>> platform's executable suffix, just as it omits directory components from
>> argv[0], so I'm undecided between fixing collect2.c's initialization of
>> progname or extending the regexp, as in the (untested) patchlet below.

> I don't think the error should mention .exe, but I also don't think the 
> error should mention collect2 (see what I said in 
> , the existence 
> of collect2 is an implementation detail).

I'm not changing collect2, at least not in this patch, but I wouldn't
mind making the match for the internal executable name optional.  WDYT?
Untested patch follows.


match .exe when prunning collect2 errors

From: Alexandre Oliva 

When collect* programs have an executable suffix, they may include it
in their outputs.  Match them when pruning gcc output, but prepare to
have the name of internal program names removed from the messages.


for  gcc/testsuite/ChangeLog

* lib/prune.exp (prune_gcc_output): Optionally match executable
suffix in collect messages, or no collect name whatsoever.
---
 gcc/testsuite/lib/prune.exp |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/prune.exp b/gcc/testsuite/lib/prune.exp
index eea4bf3..6fc07d0 100644
--- a/gcc/testsuite/lib/prune.exp
+++ b/gcc/testsuite/lib/prune.exp
@@ -38,8 +38,8 @@ proc prune_gcc_output { text } {
 regsub -all "(^|\n)\[^\n\]*:   in .constexpr. expansion \[^\n\]*" $text "" 
text
 regsub -all "(^|\n)\[^\n\]*:   in requirements \[^\n\]*" $text "" text
 regsub -all "(^|\n)inlined from \[^\n\]*" $text "" text
-regsub -all "(^|\n)collect2: error: ld returned \[^\n\]*" $text "" text
-regsub -all "(^|\n)collect: re(compiling|linking)\[^\n\]*" $text "" text
+regsub -all "(^|\n)(collect2(\.exe)?)?: error: ld returned \[^\n\]*" $text 
"" text
+regsub -all "(^|\n)(collect(\.exe)?)?: re(compiling|linking)\[^\n\]*" 
$text "" text
 regsub -all "(^|\n)Please submit.*instructions\[^\n\]*" $text "" text
 regsub -all "(^|\n)\[0-9\]\[0-9\]* errors\." $text "" text
 regsub -all "(^|\n)(In file included|\[ \]+from)\[^\n\]*" $text "" text


On Feb 28, 2020, Andrew Pinski  wrote:

> On Thu, Feb 27, 2020 at 9:17 PM Alexandre Oliva  wrote:
>> -regsub -all "(^|\n)collect2: error: ld returned \[^\n\]*" $text "" text
>> +regsub -all "(^|\n)collect2(\.exe)?: error: ld returned \[^\n\]*" $text 
>> "" text

> If you touch that line
> You may as well also touch this line too:

>> regsub -all "(^|\n)collect: re(compiling|linking)\[^\n\]*" $text "" text

Is collect, particularly the C++ template repo messages, still ever used?
Well, I guess it doesn't hurt to add the suffix to the match regardless...


match .exe when prunning collect2 errors

From: Alexandre Oliva 

When collect* programs have an executable suffix, they may include it
in their outputs.  Match them when pruning gcc output.

This was regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/testsuite/ChangeLog

* lib/prune.exp (prune_gcc_output): Optionally match executable
suffix in collect messages.
---
 gcc/testsuite/lib/prune.exp |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/prune.exp b/gcc/testsuite/lib/prune.exp
index eea4bf3..6fc07d0 100644
--- a/gcc/testsuite/lib/prune.exp
+++ b/gcc/testsuite/lib/prune.exp
@@ -38,8 +38,8 @@ proc prune_gcc_output { text } {
 regsub -all "(^|\n)\[^\n\]*:   in .constexpr. expansion \[^\n\]*" $text "" 
text
 regsub -all "(^|\n)\[^\n\]*:   in requirements \[^\n\]*" $text "" text
 regsub -all "(^|\n)inlined from \[^\n\]*" $text "" text
-regsub -all "(^|\n)collect2: error: ld returned \[^\n\]*" $text "" text
-regsub -all "(^|\n)collect: re(compiling|linking)\[^\n\]*" $text "" text
+regsub -all "(^|\n)collect2(\.exe)?: error: ld returned \[^\n\]*" $text "" 
text
+regsub -all "(^|\n)collect(\.exe)?: re(compiling|linking)\[^\n\]*" $text 
"" text
 regsub -all "(^|\n)Please submit.*instructions\[^\n\]*" $text "" text
 regsub -all "(^|\n)\[0-9\]\[0-9\]* errors\." $text "" text
 regsub -all "(^|\n)(In file included|\[ \]+from)\[^\n\]*" $text "" text



-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

[PATCH] testsuite: Match ASCII color code for ubsan's test pattern.

[Kito Cheng]

Run gcc testsuite with qemu will print out ascii color code like that:

^[[1mc-c++-common/ubsan/builtin-1.c:11:10:^[[1m^[[31m runtime error: 
^[[1m^[[0m^[[1mpassing zero to ctz(), which is not a valid argument^[[1m^[[0m^M

But the match logic in some testcase e.g c-c++-common/ubsan/builtin-1.c, didn't
consider that:

(\[^\n\r]*runtime error: passing zero to ctz\\\(\\\), which is not a valid 
argument\[^\n\r]*(\n|\r\n|\r)){4}

 - Verified on native X86 and RISC-V qemu full system mode and user mode.

ChangeLog

gcc/testsuite/

Kito Cheng  

* c-c++-common/ubsan/builtin-1.c: Match ascii code.
* c-c++-common/ubsan/float-cast-overflow-1.c: Ditoo.
* c-c++-common/ubsan/float-cast-overflow-2.c: Ditoo.
* c-c++-common/ubsan/float-cast-overflow-3.c: Ditoo.
* c-c++-common/ubsan/float-cast-overflow-4.c: Ditoo.
* c-c++-common/ubsan/float-cast-overflow-8.c: Ditoo.
* c-c++-common/ubsan/object-size-1.c: Ditoo.
* c-c++-common/ubsan/object-size-10.c: Ditoo.
* c-c++-common/ubsan/object-size-11.c: Ditoo.
* c-c++-common/ubsan/object-size-4.c: Ditoo.
* c-c++-common/ubsan/object-size-5.c: Ditoo.
* c-c++-common/ubsan/object-size-7.c: Ditoo.
* c-c++-common/ubsan/object-size-8.c: Ditoo.
* c-c++-common/ubsan/object-size-9.c: Ditoo.
* c-c++-common/ubsan/overflow-int128.c: Ditoo.
* c-c++-common/ubsan/ptr-overflow-2.c: Ditoo.
* g++.dg/ubsan/float-cast-overflow-bf.C: Ditoo.
* g++.dg/ubsan/null-1.C: Ditoo.
* g++.dg/ubsan/null-3.C: Ditoo.
* g++.dg/ubsan/pr70035.C: Ditoo.
* g++.dg/ubsan/pr70147-2.C: Ditoo.
* g++.dg/ubsan/static-init-2.C: Ditoo.
* g++.dg/ubsan/static-init-3.C: Ditoo.
* g++.dg/ubsan/vptr-1.C: Ditoo.
* g++.dg/ubsan/vptr-12.C: Ditoo.
* g++.dg/ubsan/vptr-2.C: Ditoo.
* g++.dg/ubsan/vptr-3.C: Ditoo.
* g++.dg/ubsan/vptr-8.C: Ditoo.
* g++.dg/ubsan/vptr-9.C: Ditoo.
* gcc.dg/ubsan/float-cast-overflow-bf.c: Ditoo.
* gcc.dg/ubsan/object-size-9.c: Ditoo.
---
 gcc/testsuite/c-c++-common/ubsan/builtin-1.c  |   4 +-
 .../ubsan/float-cast-overflow-1.c | 224 +-
 .../ubsan/float-cast-overflow-2.c |  82 +++
 .../ubsan/float-cast-overflow-3.c |  24 +-
 .../ubsan/float-cast-overflow-4.c |  40 ++--
 .../ubsan/float-cast-overflow-8.c |  78 +++---
 .../c-c++-common/ubsan/object-size-1.c|  22 +-
 .../c-c++-common/ubsan/object-size-10.c   |   6 +-
 .../c-c++-common/ubsan/object-size-11.c   |   8 +-
 .../c-c++-common/ubsan/object-size-4.c|   4 +-
 .../c-c++-common/ubsan/object-size-5.c|   4 +-
 .../c-c++-common/ubsan/object-size-7.c|   2 +-
 .../c-c++-common/ubsan/object-size-8.c|   2 +-
 .../c-c++-common/ubsan/object-size-9.c|  10 +-
 .../c-c++-common/ubsan/overflow-int128.c  |  18 +-
 .../c-c++-common/ubsan/ptr-overflow-2.c   |  34 +--
 .../g++.dg/ubsan/float-cast-overflow-bf.C |  16 +-
 gcc/testsuite/g++.dg/ubsan/null-1.C   |   8 +-
 gcc/testsuite/g++.dg/ubsan/null-3.C   |   8 +-
 gcc/testsuite/g++.dg/ubsan/pr70035.C  |   6 +-
 gcc/testsuite/g++.dg/ubsan/pr70147-2.C|  24 +-
 gcc/testsuite/g++.dg/ubsan/static-init-2.C|   4 +-
 gcc/testsuite/g++.dg/ubsan/static-init-3.C|   4 +-
 gcc/testsuite/g++.dg/ubsan/vptr-1.C   |  54 ++---
 gcc/testsuite/g++.dg/ubsan/vptr-12.C  |   4 +-
 gcc/testsuite/g++.dg/ubsan/vptr-2.C   |  54 ++---
 gcc/testsuite/g++.dg/ubsan/vptr-3.C   |  54 ++---
 gcc/testsuite/g++.dg/ubsan/vptr-8.C   |   6 +-
 gcc/testsuite/g++.dg/ubsan/vptr-9.C   |   6 +-
 .../gcc.dg/ubsan/float-cast-overflow-bf.c |  44 ++--
 gcc/testsuite/gcc.dg/ubsan/object-size-9.c|   2 +-
 31 files changed, 428 insertions(+), 428 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/ubsan/builtin-1.c 
b/gcc/testsuite/c-c++-common/ubsan/builtin-1.c
index 2f340e3e70f1..d7160a681868 100644
--- a/gcc/testsuite/c-c++-common/ubsan/builtin-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/builtin-1.c
@@ -30,7 +30,7 @@ main ()
 }
 
 /* { dg-output "FOO MARKER1(\n|\r\n|\r)" } */
-/* { dg-output "(\[^\n\r]*runtime error: passing zero to ctz\\\(\\\), which is 
not a valid argument\[^\n\r]*(\n|\r\n|\r)){4}" } */
+/* { dg-output "(\[^\n\r]*runtime error: \[^\n\r]*passing zero to ctz\\\(\\\), 
which is not a valid argument\[^\n\r]*(\n|\r\n|\r)){4}" } */
 /* { dg-output "FOO MARKER2(\n|\r\n|\r)" } */
-/* { dg-output "(\[^\n\r]*runtime error: passing zero to clz\\\(\\\), which is 
not a valid argument\[^\n\r]*(\n|\r\n|\r)){4}" } */
+/* { dg-output "(\[^\n\r]*runtime error: \[^\n\r]*passing zero to clz\\\(\\\), 
which is not a valid argument\[^\n\r]*(\n|\r\n|\r)){4}" } */
 /* { dg-output "FOO MARKER3" } */
diff --git a/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c 

Re: [PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

[Mark Eggleston]

On 19/05/2020 09:08, Manfred Schwarb wrote:

Am 18.05.20 um 09:35 schrieb Mark Eggleston:

Please find attached a patch for PR39695 (this time it is attached).

Commit message:

Fortran  : ProcPtr function results: 'ppr@' in error message PR39695

The value 'ppr@' is set in the name of result symbol, the actual
name of the symbol is in the procedure name symbol pointed
to by the result symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.

2020-05-18  Mark Eggleston 

gcc/fortran/

     PR fortran/39695
     * resolve.c (resolve_fl_procedure): Set name depending on
     whether the result attribute is set.  For PROCEDURE/RESULT
     conflict use the name in sym->ns->proc_name->name.
     * symbol.c (gfc_add_type): Add check for function and result
     attributes use sym->ns->proc_name->name if both are set.
     Where the symbol cannot have a type use the name in
     sym->ns->proc_name->name.

2020-05-18  Mark Eggleston 

gcc/testsuite/

     PR fortran/39695
     * gfortran.dg/pr39695_1.f90: New test.
     * gfortran.dg/pr39695_2.f90: New test.
     * gfortran.dg/pr39695_3.f90: New test.
     * gfortran.dg/pr39695_4.f90: New test.

Tested on x86_64 using make check-fortran for master, gcc-8, gcc-9 and gcc-10.

OK to to commit and backport?



--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr39695_1.f90
@@ -0,0 +1,8 @@
+! { dg-compile }
+!
etc. etc.

It should read { dg-do compile }

Fixed.

--
https://www.codethink.co.uk/privacy.html

Re: drop -aux{dir,base}, revamp -dump{dir,base}

[Richard Biener]

On Tue, 19 May 2020, Alexandre Oliva wrote:

> I've refreshed the patch, approved back on Jan 22 for gcc-11, in
> refs/users/aoliva/heads/aux-dump-revamp, and committed 3 other related
> patches on top of it, that I hope to get approved for folding and joint
> installation:

Thanks again for doing this.  May I also suggest to prepare a short
entry for gcc-11/changes.html with these things (like "Output of
auxiliary files changed.  See https://gcc.gnu.org/ml/gcc-patches/...
for details")?

Richard.

> - fix a build problem when targeting platforms with an executable suffix
> 
> - fix spurious outputs.exp test failures on targets that do not support
>   -gsplit-dwarf
> 
> - fix for outputs.exp for platforms with nonempty ldflags, libs,
>   ldscripts, or output_format in the dejagnu board configuration, and
>   for link tests with aux dumps in the testsuite when ldflags, libs or
>   ldscripts in the board config name files that gcc would regard as
>   additional inputs.
> 
> I'll post followups with each of the patches for review.

Re: drop -aux{dir,base}, revamp -dump{dir,base}

[Alexandre Oliva]

On May 19, 2020, Alexandre Oliva  wrote:

> - fix for outputs.exp for platforms with nonempty ldflags, libs,
>   ldscripts, or output_format in the dejagnu board configuration, and
>   for link tests with aux dumps in the testsuite when ldflags, libs or
>   ldscripts in the board config name files that gcc would regard as
>   additional inputs.

protect filenames in linker flags with -Wl,

From: Alexandre Oliva 

outputs.exp is not suited for remote compilation, so disable it if
host is remote.  Make it so that any extra data that complements fail
messages goes in a separate line, instead of appearing to be part of
the test name.

ldflags, libs, ldscripts and output_format flags that would normally
be passed to the compiler driver when linking would not be passed in
our special arrangement that bypasses the dejagnu requirement of
naming an output file when creating an executable.  With this patch we
collect them into a variable and add them to the options when running
linking tests.

Another issue with linking tests is that any object or library names
in these board configuration knobs would be taken by the compiler
driver as another input, changing the name of auxiliary outputs such
as those that -save-temps creates.  Tests that look for the auxiliary
outputs for single-inputs would not find them, and end up UNSUPPORTED.
This is fixed by prependig "-Wl," to any filename that appears in
ldflags, libs or ldscripts.


for  gcc/testsuite/ChangeLog

* gcc.misc-tests/outputs.exp: Skip if host is remote.
(link_options): New.  Compute once, use in all link tests.
(outest): Move extra notes for fails to separate line.
* lib/gcc-defs.exp (gcc_adjusted_linker_flags): New.
(gcc_adjust_linker_flags): New.
(dg-additional-files-options): Call it.
---
 gcc/testsuite/gcc.misc-tests/outputs.exp |   36 +++---
 gcc/testsuite/lib/gcc-defs.exp   |   42 ++
 2 files changed, 74 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp 
b/gcc/testsuite/gcc.misc-tests/outputs.exp
index 6cb2c64..889db17 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -31,7 +31,7 @@ set b "outputs"
 # doesn't return the same values, so disable parallelization
 # of this *.exp file.  The first parallel runtest to reach
 # this will run all the tests serially.
-if ![gcc_parallel_test_run_p $b] {
+if {![gcc_parallel_test_run_p $b] || [is_remote host]} {
 return
 }
 gcc_parallel_test_enable 0
@@ -43,6 +43,29 @@ if ![check_no_compiler_messages gsplitdwarf object {
 set gsplit_dwarf ""
 }
 
+# Prepare additional options to be used for linking.
+# We do not compile to an executable, because that requires naming an output.
+set link_options ""
+set dest [target_info name]
+foreach i { ldflags libs ldscripts } {
+if {[board_info $dest exists $i]} {
+   set skip ""
+   foreach opt [split [board_info $dest $i]] {
+   if { $skip != "" } then {
+   set skip ""
+   } elseif { $opt == "-Xlinker" } then {
+   set skip $opt
+   } elseif { ![string match "-*" $opt] && [file isfile $opt] } {
+   set opt "-Wl,$opt"
+   }
+   append link_options " additional_flags=$opt"
+   }
+}
+}
+if {[board_info $dest exists output_format]} {
+append link_options " additional_flags=-Wl,-oformat,[board_info $dest 
output_format]"
+}
+
 # For the test named TEST, run the compiler with SOURCES and OPTS, and
 # look in DIRS for OUTPUTS.  SOURCES is a list of suffixes for source
 # files starting with $b in $srcdir/$subdir, OPTS is a string with
@@ -79,7 +102,12 @@ proc outest { test sources opts dirs outputs } {
 }
 set options ""
 foreach opt [split $opts " "] {
-   set options "$options additional_flags=$opt"
+   append options " additional_flags=$opt"
+}
+# Add linker flags if we're linking
+if {![string match "* -\[ESc\] *" " $opts "]} {
+   global link_options
+   append options "$link_options"
 }
 set gcc_output [gcc_target_compile $src "" none "$options"]
 set outs {}
@@ -136,13 +164,13 @@ proc outest { test sources opts dirs outputs } {
 if { [llength $outs] == 0 } then {
pass "$test: extra"
 } else {
-   fail "$test: extra $outs"
+   fail "$test: extra\n$outs"
 }
 
 if { [string equal "$gcc_output" ""] } then {
pass "$test: std out"
 } else {
-   fail "$test: std out $gcc_output"
+   fail "$test: std out\n$gcc_output"
 }
 
 }
diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
index 4abb2b3..fc7e8e2 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -285,11 +285,53 @@ proc dg-additional-files { args } {
 set additional_files [lindex $args 1]
 }
 
+set gcc_adjusted_linker_flags 0
+
+# Add -Wl, before any file names in 

Re: drop -aux{dir,base}, revamp -dump{dir,base}

[Alexandre Oliva]

On May 19, 2020, Alexandre Oliva  wrote:

> - fix a build problem when targeting platforms with an executable suffix

aux and dump revamp: fix target exec suffix handling

HAVE_TARGET_EXECUTABLE_SUFFIX is defined only in gcc.c, and in a way
that requires testing whether it's defined, rather than for nonzero.
Fixed the new use in gcc.c, copied the fix and the definition to
lto-wrapper.c.


for  gcc/ChangeLog

* lto-wrapper.c (HAVE_TARGET_EXECUTABLE_SUFFIX): Define if...
(TARGET_EXECUTABLE_SUFFIX): ... is defined; define this to the
empty string otherwise.
(run_gcc): Test for HAVE_TARGET_EXECUTABLE_SUFFIX with defined.
* gcc.c (process_command): Likewise.
---
 gcc/gcc.c |2 +-
 gcc/lto-wrapper.c |9 -
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 1e4ac9d..8c851d7 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -4966,7 +4966,7 @@ process_command (unsigned int decoded_options_count,
  : ((temp = strrchr (obase + 1, '.'))
 && (xlen = strlen (temp))
 && (strcmp (temp, ".exe") == 0
-#if HAVE_TARGET_EXECUTABLE_SUFFIX
+#if defined(HAVE_TARGET_EXECUTABLE_SUFFIX)
 || strcmp (temp, TARGET_EXECUTABLE_SUFFIX) == 0
 #endif
 || strcmp (obase, "a.out") == 0)))
diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 026c419..d565b08 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -53,6 +53,13 @@ along with GCC; see the file COPYING3.  If not see
driver to lto-wrapper.  */
 #define OFFLOAD_TARGET_NAMES_ENV   "OFFLOAD_TARGET_NAMES"
 
+/* By default there is no special suffix for target executables.  */
+#ifdef TARGET_EXECUTABLE_SUFFIX
+#define HAVE_TARGET_EXECUTABLE_SUFFIX
+#else
+#define TARGET_EXECUTABLE_SUFFIX ""
+#endif
+
 enum lto_mode_d {
   LTO_MODE_NONE,   /* Not doing LTO.  */
   LTO_MODE_LTO,/* Normal LTO.  */
@@ -1509,7 +1516,7 @@ run_gcc (unsigned argc, char *argv[])
  if ((temp = strrchr (obase + 1, '.'))
  && (xlen = strlen (temp))
  && (strcmp (temp, ".exe") == 0
-#if HAVE_TARGET_EXECUTABLE_SUFFIX
+#if defined(HAVE_TARGET_EXECUTABLE_SUFFIX)
  || strcmp (temp, TARGET_EXECUTABLE_SUFFIX) == 0
 #endif
  || strcmp (obase, "a.out") == 0))


-- 
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist  Stallman was right, but he's left :(
GNU Toolchain Engineer   Live long and free, and prosper ethically

Re: drop -aux{dir,base}, revamp -dump{dir,base}

[Alexandre Oliva]

On May 19, 2020, Alexandre Oliva  wrote:

> - fix spurious outputs.exp test failures on targets that do not support
>   -gsplit-dwarf

cope with -gsplit-dwarf errors

From: Alexandre Oliva 

On targets that did not support -gsplit-dwarf, we'd get tons of
spurious failures.  This patch tests for support early on, and drops
the option and disregards the absence of .dwo files if unsupported.


for  gcc/testsuite/ChangeLog

* gcc.misc-tests/outputs.exp (gsplit_dwarf): New.  Use it
instead of -gsplit-dwarf all over.
(outest): Disregard .dwo expectations if unsupported.
---
 gcc/testsuite/gcc.misc-tests/outputs.exp |  452 +++---
 1 file changed, 232 insertions(+), 220 deletions(-)

diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp 
b/gcc/testsuite/gcc.misc-tests/outputs.exp
index a063334..6cb2c64 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -36,6 +36,13 @@ if ![gcc_parallel_test_run_p $b] {
 }
 gcc_parallel_test_enable 0
 
+set gsplit_dwarf "-gsplit-dwarf"
+if ![check_no_compiler_messages gsplitdwarf object {
+void foo (void) { }
+} "$gsplit_dwarf"] {
+set gsplit_dwarf ""
+}
+
 # For the test named TEST, run the compiler with SOURCES and OPTS, and
 # look in DIRS for OUTPUTS.  SOURCES is a list of suffixes for source
 # files starting with $b in $srcdir/$subdir, OPTS is a string with
@@ -56,6 +63,7 @@ proc outest { test sources opts dirs outputs } {
 global b
 global srcdir
 global subdir
+global gsplit_dwarf
 set src {}
 foreach s $sources {
lappend src $srcdir/$subdir/$b$s
@@ -78,8 +86,8 @@ proc outest { test sources opts dirs outputs } {
 foreach d $dirs olist $outputs {
foreach og $olist {
if { [string index $og 0] == "-" } then {
-   if { [string index $og 1] == "-" || \
-[string index $og 1] == "." } then {
+   if { [string index $og 1] == "-" \
+|| [string index $og 1] == "." } then {
set o "$b-$b[string range $og 1 end]"
} else {
set o "$b$og"
@@ -93,6 +101,10 @@ proc outest { test sources opts dirs outputs } {
} else {
set o "$og"
}
+   if { "$gsplit_dwarf" == "" \
+&& [string match "*.dwo" "$og"] } then {
+   continue
+   }
if { [file exists $d$o] } then {
pass "$test: $d$o"
file delete $d$o
@@ -267,102 +279,102 @@ outest "$b exe ddstovr namedir2" $mult "-o $b.exe 
-save-temps -dumpdir o/" {o/}
 # Compiler- and driver-generated aux and dump outputs.
 # -fdump-rtl-final creates a .c.???r.final dump in the compiler.
 # -fstack-usage creates a .su aux output in the compiler.
-# -gsplit-dwarf extracts a .dwo aux output from the .o in the driver.
-outest "$b asm auxdump 1" $sing "-S -g -fdump-rtl-final -fstack-usage 
-gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.s}}
-outest "$b asm auxdump 2" $mult "-S -g -fdump-rtl-final -fstack-usage 
-gsplit-dwarf" {} {{-1.c.???r.final -1.su -1.s -2.c.???r.final -2.su -2.s}}
-outest "$b obj auxdump unnamed1" $sing "-c -g -fdump-rtl-final -fstack-usage 
-gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.dwo -0.o}}
-outest "$b obj auxdump unnamed2" $mult "-c -g -fdump-rtl-final -fstack-usage 
-gsplit-dwarf" {} {{-1.c.???r.final -1.su -1.dwo -1.o -2.c.???r.final -2.su 
-2.dwo -2.o}}
-
-outest "$b cpp auxdump named0" $sing "-E -o $b-0.i -g -fdump-rtl-final 
-fstack-usage -gsplit-dwarf" {} {{-0.i}}
-outest "$b asm auxdump named0" $sing "-S -o $b-0.s -g -fdump-rtl-final 
-fstack-usage -gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.s}}
-outest "$b obj auxdump named0" $sing "-c -o $b-0.o -g -fdump-rtl-final 
-fstack-usage -gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.dwo -0.o}}
-outest "$b cpp auxdump namedb" $sing "-E -o $b.i -g -fdump-rtl-final 
-fstack-usage -gsplit-dwarf" {} {{.i}}
-outest "$b asm auxdump namedb" $sing "-S -o $b.s -g -fdump-rtl-final 
-fstack-usage -gsplit-dwarf" {} {{.c.???r.final .su .s}}
-outest "$b obj auxdump namedb" $sing "-c -o $b.o -g -fdump-rtl-final 
-fstack-usage -gsplit-dwarf" {} {{.c.???r.final .su .dwo .o}}
-
-outest "$b exe auxdump unnamed1" $sing "-g -fdump-rtl-final -fstack-usage 
-gsplit-dwarf" {} {{a--0.c.???r.final a--0.su a--0.dwo a.{out,exe}}}
-outest "$b exe auxdump unnamed2" $mult "-g -fdump-rtl-final -fstack-usage 
-gsplit-dwarf" {} {{a--1.c.???r.final a--1.su a--1.dwo a--2.c.???r.final 
a--2.su a--2.dwo a.{out,exe}}}
-outest "$b exe auxdump named0" $sing "-o $b-0.exe -g -fdump-rtl-final 
-fstack-usage -gsplit-dwarf" {} {{-0.c.???r.final -0.su -0.dwo -0.exe}}
-outest "$b exe auxdump namedb" $sing "-o $b.exe -g -fdump-rtl-final 
-fstack-usage -gsplit-dwarf" {} {{--0.c.???r.final --0.su --0.dwo .exe}}
-outest "$b exe auxdump named2" $mult "-o $b.exe -g -fdump-rtl-final 
-fstack-usage -gsplit-dwarf" {} {{--1.c.???r.final