Re: Analyzer status

[Richard Biener]

On Mon, 13 Jan 2020, David Malcolm wrote:

> I posted the initial version of the analyzer patch kit on 2019-11-15,
> shortly before the close of stage 1.
> 
> Jeff reviewed (most of) the latest version of the kit on Friday, and
> said:
> 
> > I'm not going to have time to finish #22 or #37 -- hell, I'm not even
> > supposed to be working today :-)
> > 
> > I'd suggest committing now and we can iterate on any issues.  The code
> > is appropriately conditionalized, so it shouldn't affect anyone that
> > doesn't ask for it and it was submitted prior to stage1 close.
> > 
> > I would also suggest that we have a fairly loose policy for these bits
> > right now.  Again, they're conditionally compiled and it's effectively
> > "tech preview", so if we muck something up, the after-effects are
> > relatively small.
> 
> Unfortunately, I didn't resolve the hash_table/hash_map issue
> referred to here:
>   https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00734.html
> where r279139 on 2019-12-09 introduced the assumption that empty
> hash_table entries and empty hash_map keys are all zeroes.
> 
> The analyzer uses hash_map::empty in a single place with a hash_map
> where the "empty" key value is all-ones.
> 
> Unfortunately, without a fix for this issue, the analyzer can hang,
> leading to DejaGnu hanging, which I clearly don't want to push to
> master as-is.
> 
> The patch here fixes the issue:
>   https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00776.html
> but Jakub has expressed concern about the effect on code generated
> for the compiler.
> 
> As noted here:
>   https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00651.html
> gcc successfully converts this back to a memset to 0 for hash_table
> at -O2, but not for hash_map, since it can't "know" that it's OK to
> clobber the values as well as the keys; it instead generates a loop
> that zeroes the keys without touching the values.
> 
> I've been experimenting with adding template specializations to try
> to allow for memset to 0 for hash_map, but haven't been successful
> (e.g. std::is_pod is C++11-only); my closest attempt so far is at:
>   
> https://dmalcolm.fedorapeople.org/gcc/2020-01-13/0001-FIXME-experiments-with-fixing-hash_map-empty.patch
> which at least expresses the memset to 0 without needing
> optimization for hash_table of *pointer* types, but I wasn't able to
> do the same for hash_map, today at least.
> 
> If the hash_map::empty patch is unacceptable, I've also successfully
> B the following kludge to the analyzer, which avoids using
> hash_map::empty at the single place where it's problematic.  This
> kludge is entirely confined to the analyzer.
> 
> I'd like to get the analyzer code into gcc 10, but I appreciate it's
> now stage 4.  Jakub suggested on IRC that with approval before the
> end of stage 3 (which it was), there may be some flexibility if we
> get it in soon and I take steps to minimize disruption.
> 
> Some options:
> (a) the patch to fix hash_table::empty, and the analyzer kit
> (b) the analyzer kit with the following kludge
> (c) someone with better C++-fu than me figure out a way to get the
> memset optimization for hash_map with 0-valued empty (or to give me
> some suggestions)
> (d) not merge the analyzer for gcc 10
> 
> My preferred approach is option (a), but option (b) is confined to
> the analyzer.
> 
> Thoughts?

(b)

we can iterate on (a)/(c) if deemed necessary but also this can be done
during next stage1.

> I also have a series of followup patches to the analyzer (and
> diagnostic subsystem, for diagnostic_path-handling) to fix bugs
> found since I posted the kit, which I've been posting to gcc-patches
> since November with an "analyzer: " prefix in the subject line.
> I wonder if it's OK for me to take Jeff's message about "fairly
> loose policy" above as blanket pre-approval to make bug fixes to the
> analyzer subdirectory?

If the analyzer is defaulted to be disabled at compile-time then
changes cannot disrupt anything release critical.  In that case
I'd be fine with you mucking at will inside analyzer/ with your
own risk ask shipping something unusable.

Richard.

> (See also:
>   https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer )
> 
> Here's the analyzer-specific kludge for the hash_map::empty issue:
> 
> ---
>  gcc/analyzer/program-state.cc | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/gcc/analyzer/program-state.cc b/gcc/analyzer/program-state.cc
> index 04346ae9dc8..4c6c82cdf5d 100644
> --- a/gcc/analyzer/program-state.cc
> +++ b/gcc/analyzer/program-state.cc
> @@ -405,7 +405,19 @@ sm_state_map::remap_svalue_ids (const svalue_id_map )
>  }
>  
>/* Clear the existing values.  */
> +  /* FIXME: hash_map::empty and hash_table::empty make the assumption that
> + the empty value for the key is all zeroes, which isn't the case for
> + this hash_map.  See
> +   https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00776.html
> + and
> +   

[PATCH 1/2] hash-table.h: support non-zero empty values in empty_slow (v2)

[David Malcolm]

On Mon, 2020-01-13 at 21:58 -0500, David Malcolm wrote:
> On Tue, 2020-01-14 at 00:55 +0100, Jakub Jelinek wrote:
> > On Mon, Jan 13, 2020 at 06:42:06PM -0500, David Malcolm wrote:
> > > Thanks.  Does it have warnings, though?
> > > 
> > > My attempt was similar, but ran into warnings from -Wclass-
> > > memaccess in
> > > four places, like this:
> > > 
> > > ../../src/gcc/hash-map-traits.h:102:12: warning: ‘void*
> > > memset(void*,
> > > int, size_t)’ clearing an object of type ‘struct
> > > hash_map > > std::pair >::hash_entry’ with no trivial
> > > copy-
> > > assignment; use assignment or value-initialization instead [-
> > > Wclass-
> > > memaccess]
> > >102 | memset (entry, 0, sizeof (T) * count);
> > >| ~~~^~
> > > 
> > > where the types in question are:
> > > 
> > > (1)
> > >struct hash_map
> > > > ::hash_entry
> > >../../src/gcc/tree-data-ref.c:844:17:   required from here
> > 
> > I don't understand how there could be new warnings.
> > The patch doesn't add any new memsets, all it does is if (0) code
> > in
> > alloc_entries for certain traits and in empty_slow stops using
> > memset
> > for some traits and uses mark_empty loop there instead.
> 
> Your patch didn't add new memsets; mine did - clearly I misspoke when
> saying they were similar, mine had a somewhat different approach.
> 
> Sorry for the noise, and thanks for your patch.
> 
> I've extended your patch to cover the various hash traits in the
> analyzer and it passes the analyzer's tests.  I also added in the
> selftests from my older patch.
> 
> I examined the generated code, and it seems correct:
> 
> * cfg.s correctly has a call to memset (even with no optimization)
> for
> hash_table::empty_slow
> 
> * the hash_map example with nonzero empty for the analyzer:
> analyzer/program-state.s: sm_state_map::remap_svalue_ids:   hash_map
>  map_t; correctly shows a loop of calls to
> mark_empty
> 
> * a hash_map example with zero empty: tree-ssa.s edge_var_maps
> correctly has a memset in the empty_slow, even with no optimization.
> 
> ...which is promising.
> 
> 
> For the graphite case, I wondered what happens if both is_empty and
> is_deleted are true; looking at hash-table.h, sometimes one is
> checked
> first, sometimes the other, but I don't think it matters for this
> case:; you have empty_zero_p = false,so it uses mark_empty, rather
> than
> trying to memset, which is correct - empty_zero_p being true can be
> thought of as a "it is safe to optimize this hash_table/hash_map by
> treating empty slots as all zero", if you will.
> 
> 
> I'm trying a bootstrap build and full regression suite now, for all
> languages (with graphite enabled, I believe).  Will post the patches
> if
> it succeeds...
> 
> > This was non-bootstrapped build, but I didn't see new warnings in
> > there,
> > and for tree-data-ref.c which you've mentioned I've tried to
> > compile
> > with installed trunk compiler and didn't get any warnings either.
> > 
> >Jakub
> 
> Thanks!  Sorry again about getting this wrong.
> 
> Dave

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu (in
conjuction with the analyzer patch kit, which it fixes)

OK for master?

gcc/cp/ChangeLog:  Jakub Jelinek  
* cp-gimplify.c (source_location_table_entry_hash::empty_zero_p):
New static constant.
* cp-tree.h (named_decl_hash::empty_zero_p): Likewise.
(struct named_label_hash::empty_zero_p): Likewise.
* decl2.c (mangled_decl_hash::empty_zero_p): Likewise.

gcc/ChangeLog:  Jakub Jelinek  ,
David Malcolm  
* attribs.c (excl_hash_traits::empty_zero_p): New static constant.
* gcov.c (function_start_pair_hash::empty_zero_p): Likewise.
* graphite.c (struct sese_scev_hash::empty_zero_p): Likewise.
* hash-map-tests.c (selftest::test_nonzero_empty_key): New selftest.
(selftest::hash_map_tests_c_tests): Call it.
* hash-map-traits.h (simple_hashmap_traits::empty_zero_p):
New static constant, using the value of = H::empty_zero_p.
(unbounded_hashmap_traits::empty_zero_p): Likewise, using the value
from default_hash_traits .
* hash-map.h (hash_map::empty_zero_p): Likewise, using the value
from Traits.
* hash-set-tests.c (value_hash_traits::empty_zero_p): Likewise.
* hash-table.h (hash_table::alloc_entries): Guard the loop of
calls to mark_empty with !Descriptor::empty_zero_p.
(hash_table::empty_slow): Conditionalize the memset call with a
check that Descriptor::empty_zero_p; otherwise, loop through the
entries calling mark_empty on them.
* hash-traits.h (int_hash::empty_zero_p): New static constant.
(pointer_hash::empty_zero_p): Likewise.
(pair_hash::empty_zero_p): Likewise.
* ipa-devirt.c (default_hash_traits ::empty_zero_p):
Likewise.
* ipa-prop.c (ipa_bit_ggc_hash_traits::empty_zero_p): 

[PATCH 2/2] analyzer: add empty_zero_p for the various hash traits

[David Malcolm]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu

OK for master?

gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (dedupe_hash_map_traits::empty_zero_p):
New static constant.
* engine.cc
(default_hash_traits::empty_zero_p): Likewise.
* exploded-graph.h (eg_hash_map_traits::empty_zero_p): Likewise.
(eg_point_hash_map_traits::empty_zero_p): Likewise.
(eg_call_string_hash_map_traits::empty_zero_p): Likewise.
* program-state.h (default_hash_traits::empty_zero_p):
Likewise.
* state-purge.h
(default_hash_traits::empty_zero_p): Likewise.
---
 gcc/analyzer/diagnostic-manager.cc | 2 +-
 gcc/analyzer/engine.cc | 1 +
 gcc/analyzer/exploded-graph.h  | 3 +++
 gcc/analyzer/program-state.h   | 1 +
 gcc/analyzer/state-purge.h | 1 +
 5 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index 12b8e5a4ac4..cd2c3bf2076 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -265,7 +265,7 @@ public:
   {
 return entry.m_key == NULL;
   }
-
+  static const bool empty_zero_p = true;
 };
 
 /* A class for deduplicating diagnostics and finding (and emitting) the
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 3e3d8a120b7..720fa219d16 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -2913,6 +2913,7 @@ struct function_call_string
 template <> struct default_hash_traits
 : public pod_hash_traits
 {
+  static const bool empty_zero_p = false;
 };
 
 template <>
diff --git a/gcc/analyzer/exploded-graph.h b/gcc/analyzer/exploded-graph.h
index ddc5e06b3b6..8c29e552cac 100644
--- a/gcc/analyzer/exploded-graph.h
+++ b/gcc/analyzer/exploded-graph.h
@@ -407,6 +407,7 @@ struct eg_hash_map_traits
   {
 return entry.m_key == NULL;
   }
+  static const bool empty_zero_p = false;
 };
 
 /* Per-program_point data for an exploded_graph.  */
@@ -473,6 +474,7 @@ struct eg_point_hash_map_traits
   {
 return entry.m_key == NULL;
   }
+  static const bool empty_zero_p = false;
 };
 
 /* Data about a particular call_string within an exploded_graph.  */
@@ -539,6 +541,7 @@ struct eg_call_string_hash_map_traits
   {
 return entry.m_key == NULL;
   }
+  static const bool empty_zero_p = false;
 };
 
 /* Data about a particular function within an exploded_graph.  */
diff --git a/gcc/analyzer/program-state.h b/gcc/analyzer/program-state.h
index 37fb7cc4101..75b65b780c9 100644
--- a/gcc/analyzer/program-state.h
+++ b/gcc/analyzer/program-state.h
@@ -50,6 +50,7 @@ public:
 template <> struct default_hash_traits
 : public pod_hash_traits
 {
+  static const bool empty_zero_p = false;
 };
 
 template <>
diff --git a/gcc/analyzer/state-purge.h b/gcc/analyzer/state-purge.h
index 77b7f622bbd..e33733a6cc5 100644
--- a/gcc/analyzer/state-purge.h
+++ b/gcc/analyzer/state-purge.h
@@ -26,6 +26,7 @@ along with GCC; see the file COPYING3.  If not see
 template <> struct default_hash_traits
 : public pod_hash_traits
 {
+  static const bool empty_zero_p = false;
 };
 
 template <>
-- 
2.21.0

Re: [PATCH] Add Optimization for various IPA parameters.

[luoxhu]

On 2020/1/11 20:20, Tamar Christina wrote:

Hi Martin,

This change (r280099) is causing a major performance regression on exchange2 in 
SPEC2017 dropping the benchmark by more than 30%.

It seems the parameters no longer do anything. i.e. -flto --param 
ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=80 doesn't have any effect 
anymore.


Strange that you don't need -fno-inline to achieve the 30% performance 
boost, I found that some specialized nodes are recursively inlined cause 
register spill and no performance improve.  What's your platform and could 
you please try it with -fno-inline and see any difference please?


Thanks
Xiong Hu


Thanks,
Tamar


-Original Message-
From: gcc-patches-ow...@gcc.gnu.org 
On Behalf Of Martin Jambor
Sent: Wednesday, January 8, 2020 4:14 PM
To: Martin Liška ; gcc-patches@gcc.gnu.org
Cc: hubi...@ucw.cz; Richard Biener 
Subject: Re: [PATCH] Add Optimization for various IPA parameters.

Hi,

On Fri, Jan 03 2020, Martin Liška wrote:

Hi.

This is similar transformation for IPA passes. This time, one needs to
use opt_for_fn in order to get the right parameter values.

@Martin, Honza:
There are last few remaining parameters which should use
opt_for_fn:

param_ipa_cp_unit_growth


So as we discussed, picking this one from one particular node is not what one
would expect to happen, but inlining does it too and so anyway:


IPA-CP: Always access param_ipcp_unit_growth through opt_for_fn

2020-01-07  Martin Jambor  

* params.opt (param_ipcp_unit_growth): Mark as Optimization.
* ipa-cp.c (max_new_size): Removed.
(orig_overall_size): New variable.
(get_max_overall_size): New function.
(estimate_local_effects): Use it.  Adjust dump.
(decide_about_value): Likewise.
(ipcp_propagate_stage): Do not calculate max_new_size, just store
orig_overall_size.  Adjust dump.
(ipa_cp_c_finalize): Clear orig_overall_size instead of max_new_size.
---
  gcc/ipa-cp.c   | 39 ++-
  gcc/params.opt |  2 +-
  2 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c index 9e20e278eff..c2572e3e0e8
100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -375,7 +375,7 @@ static profile_count max_count;

  /* Original overall size of the program.  */

-static long overall_size, max_new_size;
+static long overall_size, orig_overall_size;

  /* Node name to unique clone suffix number map.  */  static
hash_map *clone_num_suffixes; @@ -3395,6
+3395,23 @@ perform_estimation_of_a_value (cgraph_node *node,
vec known_csts,
val->local_size_cost = size;
  }

+/* Get the overall limit oof growth based on parameters extracted from
growth.
+   it does not really make sense to mix functions with different overall
growth
+   limits but it is possible and if it happens, we do not want to select one
+   limit at random.  */
+
+static long
+get_max_overall_size (cgraph_node *node) {
+  long max_new_size = orig_overall_size;
+  long large_unit = opt_for_fn (node->decl, param_large_unit_insns);
+  if (max_new_size < large_unit)
+max_new_size = large_unit;
+  int unit_growth = opt_for_fn (node->decl, param_ipcp_unit_growth);
+  max_new_size += max_new_size * unit_growth / 100 + 1;
+  return max_new_size;
+}
+
  /* Iterate over known values of parameters of NODE and estimate the local
 effects in terms of time and size they have.  */

@@ -3457,7 +3474,7 @@ estimate_local_effects (struct cgraph_node *node)
   stats.freq_sum, stats.count_sum,
   size))
{
- if (size + overall_size <= max_new_size)
+ if (size + overall_size <= get_max_overall_size (node))
{
  info->do_clone_for_all_contexts = true;
  overall_size += size;
@@ -3467,8 +3484,8 @@ estimate_local_effects (struct cgraph_node *node)
 "known contexts, growth deemed beneficial.\n");
}
  else if (dump_file && (dump_flags & TDF_DETAILS))
-   fprintf (dump_file, "   Not cloning for all contexts because "
-"max_new_size would be reached with %li.\n",
+   fprintf (dump_file, "  Not cloning for all contexts because "
+"maximum unit size would be reached with %li.\n",
 size + overall_size);
}
else if (dump_file && (dump_flags & TDF_DETAILS)) @@ -3860,14
+3877,10 @@ ipcp_propagate_stage (class ipa_topo_info *topo)
  max_count = max_count.max (node->count.ipa ());
}

-  max_new_size = overall_size;
-  if (max_new_size < param_large_unit_insns)
-max_new_size = param_large_unit_insns;
-  max_new_size += max_new_size * param_ipcp_unit_growth / 100 + 1;
+  orig_overall_size = overall_size;

if (dump_file)
-fprintf (dump_file, "\noverall_size: %li, max_new_size: %li\n",
-overall_size, max_new_size);
+fprintf (dump_file, 

Re: Analyzer status

[David Malcolm]

On Tue, 2020-01-14 at 00:55 +0100, Jakub Jelinek wrote:
> On Mon, Jan 13, 2020 at 06:42:06PM -0500, David Malcolm wrote:
> > Thanks.  Does it have warnings, though?
> > 
> > My attempt was similar, but ran into warnings from -Wclass-
> > memaccess in
> > four places, like this:
> > 
> > ../../src/gcc/hash-map-traits.h:102:12: warning: ‘void*
> > memset(void*,
> > int, size_t)’ clearing an object of type ‘struct
> > hash_map > std::pair >::hash_entry’ with no trivial
> > copy-
> > assignment; use assignment or value-initialization instead [-
> > Wclass-
> > memaccess]
> >   102 | memset (entry, 0, sizeof (T) * count);
> >   | ~~~^~
> > 
> > where the types in question are:
> > 
> > (1)
> >   struct hash_map
> > > ::hash_entry
> >   ../../src/gcc/tree-data-ref.c:844:17:   required from here
> 
> I don't understand how there could be new warnings.
> The patch doesn't add any new memsets, all it does is if (0) code in
> alloc_entries for certain traits and in empty_slow stops using memset
> for some traits and uses mark_empty loop there instead.

Your patch didn't add new memsets; mine did - clearly I misspoke when
saying they were similar, mine had a somewhat different approach.

Sorry for the noise, and thanks for your patch.

I've extended your patch to cover the various hash traits in the
analyzer and it passes the analyzer's tests.  I also added in the
selftests from my older patch.

I examined the generated code, and it seems correct:

* cfg.s correctly has a call to memset (even with no optimization) for
hash_table::empty_slow

* the hash_map example with nonzero empty for the analyzer:
analyzer/program-state.s: sm_state_map::remap_svalue_ids:   hash_map
 map_t; correctly shows a loop of calls to
mark_empty

* a hash_map example with zero empty: tree-ssa.s edge_var_maps
correctly has a memset in the empty_slow, even with no optimization.

...which is promising.


For the graphite case, I wondered what happens if both is_empty and
is_deleted are true; looking at hash-table.h, sometimes one is checked
first, sometimes the other, but I don't think it matters for this
case:; you have empty_zero_p = false,so it uses mark_empty, rather than
trying to memset, which is correct - empty_zero_p being true can be
thought of as a "it is safe to optimize this hash_table/hash_map by
treating empty slots as all zero", if you will.


I'm trying a bootstrap build and full regression suite now, for all
languages (with graphite enabled, I believe).  Will post the patches if
it succeeds...

> This was non-bootstrapped build, but I didn't see new warnings in
> there,
> and for tree-data-ref.c which you've mentioned I've tried to compile
> with installed trunk compiler and didn't get any warnings either.
> 
>   Jakub

Thanks!  Sorry again about getting this wrong.

Dave

[PATCH] PR c++/92746 - ICE with noexcept of function concept check.

[Jason Merrill]

Another place that needs to specially handle Concepts TS function-style
concepts.

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

* except.c (check_noexcept_r): Handle concept-check.
---
 gcc/cp/except.c | 2 ++
 gcc/testsuite/g++.dg/concepts/fn-concept3.C | 6 ++
 2 files changed, 8 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/concepts/fn-concept3.C

diff --git a/gcc/cp/except.c b/gcc/cp/except.c
index e073bd4d2bc..55b4b6af442 100644
--- a/gcc/cp/except.c
+++ b/gcc/cp/except.c
@@ -1117,6 +1117,8 @@ check_noexcept_r (tree *tp, int * /*walk_subtrees*/, void 
* /*data*/)
 
  We could use TREE_NOTHROW (t) for !TREE_PUBLIC fns, though... */
   tree fn = cp_get_callee (t);
+  if (concept_check_p (fn))
+   return NULL_TREE;
   tree type = TREE_TYPE (fn);
   gcc_assert (INDIRECT_TYPE_P (type));
   type = TREE_TYPE (type);
diff --git a/gcc/testsuite/g++.dg/concepts/fn-concept3.C 
b/gcc/testsuite/g++.dg/concepts/fn-concept3.C
new file mode 100644
index 000..ecb7f6b12f7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/fn-concept3.C
@@ -0,0 +1,6 @@
+// PR c++/92746
+// { dg-do compile { target c++17_only } }
+// { dg-options "-fconcepts" }
+
+template concept bool C3() { return true; }
+static_assert(noexcept(C3()), "function concept should be treated as if 
noexcept(true) specified");

base-commit: 64378144aabf65bf3df2313191250accc042170e
-- 
2.18.1

[PATCH] PR c++/92582 - ICE with member template as requirement.

[Jason Merrill]

Here, we weren't recognizing that the template parameter of A is used by the
reference to d in the requires-clause of f.  Fixed by passing down the
active template parameters in the context of normalization, and adding to
the mapping any such parameters shared by a member template used in the
constraint-expression.

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

* pt.c (struct find_template_parameter_info): Add ctx_parms.
(any_template_parm_r): Handle TEMPLATE_DECL.
(find_template_parameters): Take parms instead of their depth.
* constraint.cc (build_parameter_mapping): Pass them.
---
 gcc/cp/cp-tree.h  |  2 +-
 gcc/cp/constraint.cc  |  9 ++---
 gcc/cp/pt.c   | 39 ---
 .../g++.dg/cpp2a/concepts-memtmpl3.C  | 12 ++
 4 files changed, 51 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-memtmpl3.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index c0f780df685..01fcf663a29 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7865,7 +7865,7 @@ extern bool constraints_satisfied_p   (tree, 
tree);
 extern void clear_satisfaction_cache   ();
 extern bool* lookup_subsumption_result  (tree, tree);
 extern bool save_subsumption_result (tree, tree, bool);
-extern tree find_template_parameters   (tree, int);
+extern tree find_template_parameters   (tree, tree);
 extern bool equivalent_constraints  (tree, tree);
 extern bool equivalently_constrained(tree, tree);
 extern bool subsumes_constraints(tree, tree);
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 11f58075701..128ab8ae0b2 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -559,12 +559,11 @@ map_arguments (tree parms, tree args)
 static tree
 build_parameter_mapping (tree expr, tree args, tree decl)
 {
-  int depth = 0;
+  tree ctx_parms = NULL_TREE;
   if (decl)
 {
   gcc_assert (TREE_CODE (decl) == TEMPLATE_DECL);
-  tree parms = DECL_TEMPLATE_PARMS (decl);
-  depth = TREE_INT_CST_LOW (TREE_PURPOSE (parms));
+  ctx_parms = DECL_TEMPLATE_PARMS (decl);
 }
   else if (current_template_parms)
 {
@@ -572,10 +571,10 @@ build_parameter_mapping (tree expr, tree args, tree decl)
 point of declaration of concepts is currently set after the
 initializer, the template parameter lists are not available
 when normalizing concept definitions, hence the case above.  */
-  depth = TMPL_PARMS_DEPTH (current_template_parms);
+  ctx_parms = current_template_parms;
 }
 
-  tree parms = find_template_parameters (expr, depth);
+  tree parms = find_template_parameters (expr, ctx_parms);
   tree map = map_arguments (parms, args);
   return map;
 }
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 29c3aecd831..fa82ecad233 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10364,12 +10364,14 @@ for_each_template_parm (tree t, tree_fn_t fn, void* 
data,
 
 struct find_template_parameter_info
 {
-  explicit find_template_parameter_info (int d)
-: max_depth (d)
+  explicit find_template_parameter_info (tree ctx_parms)
+: ctx_parms (ctx_parms),
+  max_depth (TMPL_PARMS_DEPTH (ctx_parms))
   {}
 
   hash_set visited;
   hash_set parms;
+  tree ctx_parms;
   int max_depth;
 };
 
@@ -10459,6 +10461,29 @@ any_template_parm_r (tree t, void *data)
   WALK_SUBTREE (TREE_TYPE (t));
   break;
 
+case TEMPLATE_DECL:
+  {
+   /* If T is a member template that shares template parameters with
+  ctx_parms, we need to mark all those parameters for mapping.  */
+   tree dparms = DECL_TEMPLATE_PARMS (t);
+   tree cparms = ftpi->ctx_parms;
+   while (TMPL_PARMS_DEPTH (dparms) > ftpi->max_depth)
+ dparms = TREE_CHAIN (dparms);
+   while (dparms
+  && (TREE_TYPE (TREE_VALUE (dparms))
+  != TREE_TYPE (TREE_VALUE (cparms
+ dparms = TREE_CHAIN (dparms),
+   cparms = TREE_CHAIN (cparms);
+   if (dparms)
+ {
+   int ddepth = TMPL_PARMS_DEPTH (dparms);
+   tree dargs = TI_ARGS (get_template_info (DECL_TEMPLATE_RESULT (t)));
+   for (int i = 0; i < ddepth; ++i)
+ WALK_SUBTREE (TMPL_ARGS_LEVEL (dargs, i+1));
+ }
+  }
+  break;
+
 default:
   break;
 }
@@ -10467,12 +10492,16 @@ any_template_parm_r (tree t, void *data)
   return 0;
 }
 
-/* Returns a list of unique template parameters found within T.  */
+/* Returns a list of unique template parameters found within T, where CTX_PARMS
+   are the template parameters in scope.  */
 
 tree
-find_template_parameters (tree t, int depth)
+find_template_parameters (tree t, tree ctx_parms)
 {
-  find_template_parameter_info ftpi (depth);
+  if (!ctx_parms)
+return NULL_TREE;
+
+  find_template_parameter_info ftpi (ctx_parms);

Re: Analyzer status

[Jakub Jelinek]

On Mon, Jan 13, 2020 at 06:42:06PM -0500, David Malcolm wrote:
> Thanks.  Does it have warnings, though?
> 
> My attempt was similar, but ran into warnings from -Wclass-memaccess in
> four places, like this:
> 
> ../../src/gcc/hash-map-traits.h:102:12: warning: ‘void* memset(void*,
> int, size_t)’ clearing an object of type ‘struct hash_map std::pair >::hash_entry’ with no trivial copy-
> assignment; use assignment or value-initialization instead [-Wclass-
> memaccess]
>   102 | memset (entry, 0, sizeof (T) * count);
>   | ~~~^~
> 
> where the types in question are:
> 
> (1)
>   struct hash_map
> >::hash_entry
>   ../../src/gcc/tree-data-ref.c:844:17:   required from here

I don't understand how there could be new warnings.
The patch doesn't add any new memsets, all it does is if (0) code in
alloc_entries for certain traits and in empty_slow stops using memset
for some traits and uses mark_empty loop there instead.
This was non-bootstrapped build, but I didn't see new warnings in there,
and for tree-data-ref.c which you've mentioned I've tried to compile
with installed trunk compiler and didn't get any warnings either.

Jakub

Re: Analyzer status

[David Malcolm]

On Tue, 2020-01-14 at 00:26 +0100, Jakub Jelinek wrote:
> On Mon, Jan 13, 2020 at 11:56:14PM +0100, Jakub Jelinek wrote:
> > > Some options:
> > > (a) the patch to fix hash_table::empty, and the analyzer kit
> > > (b) the analyzer kit with the following kludge
> > > (c) someone with better C++-fu than me figure out a way to get
> > > the
> > > memset optimization for hash_map with 0-valued empty (or to give
> > > me
> > > some suggestions)
> > > (d) not merge the analyzer for gcc 10
> > 
> > For (c), I see right now we have 37 mark_empty definitions:
> > find -type f | grep -v 'testsuite/\|ChangeLog' | xargs grep
> > mark_empty | wc -l
> > 37
> > > From quick skimming of them, most of them are just zeroing one or
> > > more
> > fields, exceptions are profile.c, attribs.c (this one only in self-
> > tests
> > and it is unclear why deleted is two NULLs and empty two ""s rather
> > than
> > vice versa), and gcov.c.  Also, int_hash can be zero or non-zero,
> > depending
> > on template argument, e.g.
> > typedef hash_map, unsigned int>
> > live_vars_map;
> > struct uid_hash : int_hash  {};
> > are not either.
> > Can't we add next to the mark_empty and is_empty methods also a
> > static const
> > bool data member empty_zero_p or similar and use it in in the two
> > hash-table.h spots where this would make a difference?
> > In alloc_entries the
> >   for (size_t i = 0; i < n; i++)
> > mark_empty (nentries[i]);
> > loop could be conditionalized on !Descriptor::empty_zero_p because
> > both
> > allocation paths actually allocate cleared memory, and in the spot
> > you are talking about.
> 
> Just as a proof of concept, the following compiles (but haven't done
> any
> testing beoyond that, not even looked if/when the memcpy vs. loop is
> in
> there), the formatting/placement of the static data members could be
> adjusted, in graphite.c I just gave up (it is weird, empty is when
> one field
> is NULL, deleted when another field is NULL, but what is zeroed
> memory, is
> that both empty and deleted at the same time?).

Thanks.  Does it have warnings, though?

My attempt was similar, but ran into warnings from -Wclass-memaccess in
four places, like this:

../../src/gcc/hash-map-traits.h:102:12: warning: ‘void* memset(void*,
int, size_t)’ clearing an object of type ‘struct hash_map >::hash_entry’ with no trivial copy-
assignment; use assignment or value-initialization instead [-Wclass-
memaccess]
  102 | memset (entry, 0, sizeof (T) * count);
  | ~~~^~

where the types in question are:

(1)
  struct hash_map
>::hash_entry
  ../../src/gcc/tree-data-ref.c:844:17:   required from here

(2)
  struct hash_map
>::hash_entry
  ../../src/gcc/tree-ssa-strlen.c:5925:32:   required from here

(3)
  struct hash_map >::hash_entry
  ../../src/gcc/tree-ssa.c:130:27:   required from here

(4)
  struct hash_map::hash_entry
  ../../src/gcc/cp/parser.c:31073:20:   required from here


I tried to use std::is_pod, but got stuck.

Dave


> 
> diff --git a/gcc/attribs.c b/gcc/attribs.c
> index ca89443eb3e..c66d4ae2c06 100644
> --- a/gcc/attribs.c
> +++ b/gcc/attribs.c
> @@ -2048,6 +2048,8 @@ struct excl_hash_traits:
> typed_noop_remove
>  x = value_type (NULL, NULL);
>}
>  
> +  static const bool empty_zero_p = false;
> +
>static void mark_empty (value_type )
>{
>  x = value_type ("", "");
> diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
> index 3d764bb6928..f3aeb7475da 100644
> --- a/gcc/cp/cp-gimplify.c
> +++ b/gcc/cp/cp-gimplify.c
> @@ -3045,6 +3045,8 @@ struct source_location_table_entry_hash
>  ref.var = NULL_TREE;
>}
>  
> +  static const bool empty_zero_p = true;
> +
>static void
>mark_empty (source_location_table_entry )
>{
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index 98572bdbad1..c3ca4c8dace 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -900,6 +900,7 @@ struct named_decl_hash : ggc_remove 
>inline static hashval_t hash (const value_type decl);
>inline static bool equal (const value_type existing, compare_type
> candidate);
>  
> +  static const bool empty_zero_p = true;
>static inline void mark_empty (value_type ) {p = NULL_TREE;}
>static inline bool is_empty (value_type p) {return !p;}
>  
> @@ -1870,6 +1871,7 @@ struct named_label_hash : ggc_remove
> 
>inline static hashval_t hash (value_type);
>inline static bool equal (const value_type, compare_type);
>  
> +  static const bool empty_zero_p = true;
>inline static void mark_empty (value_type ) {p = NULL;}
>inline static bool is_empty (value_type p) {return !p;}
>  
> diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
> index a641667991f..042d6fa12df 100644
> --- a/gcc/cp/decl2.c
> +++ b/gcc/cp/decl2.c
> @@ -120,6 +120,7 @@ struct mangled_decl_hash : ggc_remove 
>  return candidate == name;
>}
>  
> +  static const bool empty_zero_p = true;
>static inline void mark_empty (value_type ) {p = NULL_TREE;}
>static 

Re: Analyzer status

[Jakub Jelinek]

On Mon, Jan 13, 2020 at 11:56:14PM +0100, Jakub Jelinek wrote:
> > Some options:
> > (a) the patch to fix hash_table::empty, and the analyzer kit
> > (b) the analyzer kit with the following kludge
> > (c) someone with better C++-fu than me figure out a way to get the
> > memset optimization for hash_map with 0-valued empty (or to give me
> > some suggestions)
> > (d) not merge the analyzer for gcc 10
> 
> For (c), I see right now we have 37 mark_empty definitions:
> find -type f | grep -v 'testsuite/\|ChangeLog' | xargs grep mark_empty | wc -l
> 37
> >From quick skimming of them, most of them are just zeroing one or more
> fields, exceptions are profile.c, attribs.c (this one only in self-tests
> and it is unclear why deleted is two NULLs and empty two ""s rather than
> vice versa), and gcov.c.  Also, int_hash can be zero or non-zero, depending
> on template argument, e.g.
> typedef hash_map, unsigned int> live_vars_map;
> struct uid_hash : int_hash  {};
> are not either.
> Can't we add next to the mark_empty and is_empty methods also a static const
> bool data member empty_zero_p or similar and use it in in the two
> hash-table.h spots where this would make a difference?
> In alloc_entries the
>   for (size_t i = 0; i < n; i++)
> mark_empty (nentries[i]);
> loop could be conditionalized on !Descriptor::empty_zero_p because both
> allocation paths actually allocate cleared memory, and in the spot
> you are talking about.

Just as a proof of concept, the following compiles (but haven't done any
testing beoyond that, not even looked if/when the memcpy vs. loop is in
there), the formatting/placement of the static data members could be
adjusted, in graphite.c I just gave up (it is weird, empty is when one field
is NULL, deleted when another field is NULL, but what is zeroed memory, is
that both empty and deleted at the same time?).

diff --git a/gcc/attribs.c b/gcc/attribs.c
index ca89443eb3e..c66d4ae2c06 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -2048,6 +2048,8 @@ struct excl_hash_traits: typed_noop_remove
 x = value_type (NULL, NULL);
   }
 
+  static const bool empty_zero_p = false;
+
   static void mark_empty (value_type )
   {
 x = value_type ("", "");
diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index 3d764bb6928..f3aeb7475da 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -3045,6 +3045,8 @@ struct source_location_table_entry_hash
 ref.var = NULL_TREE;
   }
 
+  static const bool empty_zero_p = true;
+
   static void
   mark_empty (source_location_table_entry )
   {
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 98572bdbad1..c3ca4c8dace 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -900,6 +900,7 @@ struct named_decl_hash : ggc_remove 
   inline static hashval_t hash (const value_type decl);
   inline static bool equal (const value_type existing, compare_type candidate);
 
+  static const bool empty_zero_p = true;
   static inline void mark_empty (value_type ) {p = NULL_TREE;}
   static inline bool is_empty (value_type p) {return !p;}
 
@@ -1870,6 +1871,7 @@ struct named_label_hash : ggc_remove 
   inline static hashval_t hash (value_type);
   inline static bool equal (const value_type, compare_type);
 
+  static const bool empty_zero_p = true;
   inline static void mark_empty (value_type ) {p = NULL;}
   inline static bool is_empty (value_type p) {return !p;}
 
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index a641667991f..042d6fa12df 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -120,6 +120,7 @@ struct mangled_decl_hash : ggc_remove 
 return candidate == name;
   }
 
+  static const bool empty_zero_p = true;
   static inline void mark_empty (value_type ) {p = NULL_TREE;}
   static inline bool is_empty (value_type p) {return !p;}
 
diff --git a/gcc/gcov.c b/gcc/gcov.c
index 1dca3049777..a291bac3e9e 100644
--- a/gcc/gcov.c
+++ b/gcc/gcov.c
@@ -1225,6 +1225,8 @@ struct function_start_pair_hash : typed_noop_remove 

 ref.start_line = ~1U;
   }
 
+  static const bool empty_zero_p = false;
+
   static void
   mark_empty (function_start )
   {
diff --git a/gcc/graphite.c b/gcc/graphite.c
index 0ac46766b15..27f1e486e1f 100644
--- a/gcc/graphite.c
+++ b/gcc/graphite.c
@@ -233,6 +233,7 @@ struct sese_scev_hash : typed_noop_remove 
&& operand_equal_p (key1.expr, key2.expr, 0));
   }
   static void mark_deleted (seir_cache_key ) { key.expr = NULL_TREE; }
+  static const bool empty_zero_p = false;
   static void mark_empty (seir_cache_key ) { key.entry_dest = 0; }
   static bool is_deleted (const seir_cache_key ) { return !key.expr; }
   static bool is_empty (const seir_cache_key ) { return key.entry_dest == 
0; }
diff --git a/gcc/hash-map-traits.h b/gcc/hash-map-traits.h
index 4764380b364..3b16be35f7d 100644
--- a/gcc/hash-map-traits.h
+++ b/gcc/hash-map-traits.h
@@ -36,6 +36,7 @@ struct simple_hashmap_traits
   static inline hashval_t hash (const key_type &);
   static inline bool equal_keys (const key_type &, const 

Re: Analyzer status

[Jakub Jelinek]

On Mon, Jan 13, 2020 at 05:10:24PM -0500, David Malcolm wrote:
> Unfortunately, I didn't resolve the hash_table/hash_map issue
> referred to here:
>   https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00734.html
> where r279139 on 2019-12-09 introduced the assumption that empty
> hash_table entries and empty hash_map keys are all zeroes.
> 
> The analyzer uses hash_map::empty in a single place with a hash_map
> where the "empty" key value is all-ones.
> 
> Unfortunately, without a fix for this issue, the analyzer can hang,
> leading to DejaGnu hanging, which I clearly don't want to push to
> master as-is.
> 
> The patch here fixes the issue:
>   https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00776.html
> but Jakub has expressed concern about the effect on code generated
> for the compiler.
> 
> As noted here:
>   https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00651.html
> gcc successfully converts this back to a memset to 0 for hash_table
> at -O2, but not for hash_map, since it can't "know" that it's OK to
> clobber the values as well as the keys; it instead generates a loop
> that zeroes the keys without touching the values.

I guess in some cases the loop could be better (e.g. if the values are
large and/or keys too and mark_empty only sets something small), but I bet
in most cases the memset will be better.

> Some options:
> (a) the patch to fix hash_table::empty, and the analyzer kit
> (b) the analyzer kit with the following kludge
> (c) someone with better C++-fu than me figure out a way to get the
> memset optimization for hash_map with 0-valued empty (or to give me
> some suggestions)
> (d) not merge the analyzer for gcc 10

For (c), I see right now we have 37 mark_empty definitions:
find -type f | grep -v 'testsuite/\|ChangeLog' | xargs grep mark_empty | wc -l
37
From quick skimming of them, most of them are just zeroing one or more
fields, exceptions are profile.c, attribs.c (this one only in self-tests
and it is unclear why deleted is two NULLs and empty two ""s rather than
vice versa), and gcov.c.  Also, int_hash can be zero or non-zero, depending
on template argument, e.g.
typedef hash_map, unsigned int> live_vars_map;
struct uid_hash : int_hash  {};
are not either.
Can't we add next to the mark_empty and is_empty methods also a static const
bool data member empty_zero_p or similar and use it in in the two
hash-table.h spots where this would make a difference?
In alloc_entries the
  for (size_t i = 0; i < n; i++)
mark_empty (nentries[i]);
loop could be conditionalized on !Descriptor::empty_zero_p because both
allocation paths actually allocate cleared memory, and in the spot
you are talking about.

Or isn't there (e), tweak whatever hash_table traits you use so that
empty case is all zeros?

Jakub

Analyzer status

[David Malcolm]

I posted the initial version of the analyzer patch kit on 2019-11-15,
shortly before the close of stage 1.

Jeff reviewed (most of) the latest version of the kit on Friday, and
said:

> I'm not going to have time to finish #22 or #37 -- hell, I'm not even
> supposed to be working today :-)
> 
> I'd suggest committing now and we can iterate on any issues.  The code
> is appropriately conditionalized, so it shouldn't affect anyone that
> doesn't ask for it and it was submitted prior to stage1 close.
> 
> I would also suggest that we have a fairly loose policy for these bits
> right now.  Again, they're conditionally compiled and it's effectively
> "tech preview", so if we muck something up, the after-effects are
> relatively small.

Unfortunately, I didn't resolve the hash_table/hash_map issue
referred to here:
  https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00734.html
where r279139 on 2019-12-09 introduced the assumption that empty
hash_table entries and empty hash_map keys are all zeroes.

The analyzer uses hash_map::empty in a single place with a hash_map
where the "empty" key value is all-ones.

Unfortunately, without a fix for this issue, the analyzer can hang,
leading to DejaGnu hanging, which I clearly don't want to push to
master as-is.

The patch here fixes the issue:
  https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00776.html
but Jakub has expressed concern about the effect on code generated
for the compiler.

As noted here:
  https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00651.html
gcc successfully converts this back to a memset to 0 for hash_table
at -O2, but not for hash_map, since it can't "know" that it's OK to
clobber the values as well as the keys; it instead generates a loop
that zeroes the keys without touching the values.

I've been experimenting with adding template specializations to try
to allow for memset to 0 for hash_map, but haven't been successful
(e.g. std::is_pod is C++11-only); my closest attempt so far is at:
  
https://dmalcolm.fedorapeople.org/gcc/2020-01-13/0001-FIXME-experiments-with-fixing-hash_map-empty.patch
which at least expresses the memset to 0 without needing
optimization for hash_table of *pointer* types, but I wasn't able to
do the same for hash_map, today at least.

If the hash_map::empty patch is unacceptable, I've also successfully
B the following kludge to the analyzer, which avoids using
hash_map::empty at the single place where it's problematic.  This
kludge is entirely confined to the analyzer.

I'd like to get the analyzer code into gcc 10, but I appreciate it's
now stage 4.  Jakub suggested on IRC that with approval before the
end of stage 3 (which it was), there may be some flexibility if we
get it in soon and I take steps to minimize disruption.

Some options:
(a) the patch to fix hash_table::empty, and the analyzer kit
(b) the analyzer kit with the following kludge
(c) someone with better C++-fu than me figure out a way to get the
memset optimization for hash_map with 0-valued empty (or to give me
some suggestions)
(d) not merge the analyzer for gcc 10

My preferred approach is option (a), but option (b) is confined to
the analyzer.

Thoughts?

I also have a series of followup patches to the analyzer (and
diagnostic subsystem, for diagnostic_path-handling) to fix bugs
found since I posted the kit, which I've been posting to gcc-patches
since November with an "analyzer: " prefix in the subject line.
I wonder if it's OK for me to take Jeff's message about "fairly
loose policy" above as blanket pre-approval to make bug fixes to the
analyzer subdirectory?

(See also:
  https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer )

Here's the analyzer-specific kludge for the hash_map::empty issue:

---
 gcc/analyzer/program-state.cc | 12 
 1 file changed, 12 insertions(+)

diff --git a/gcc/analyzer/program-state.cc b/gcc/analyzer/program-state.cc
index 04346ae9dc8..4c6c82cdf5d 100644
--- a/gcc/analyzer/program-state.cc
+++ b/gcc/analyzer/program-state.cc
@@ -405,7 +405,19 @@ sm_state_map::remap_svalue_ids (const svalue_id_map )
 }
 
   /* Clear the existing values.  */
+  /* FIXME: hash_map::empty and hash_table::empty make the assumption that
+ the empty value for the key is all zeroes, which isn't the case for
+ this hash_map.  See
+   https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00776.html
+ and
+   https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00651.html  */
+#if 0
   m_map.empty ();
+#else
+  /* Workaround: manually remove each element.  */
+  while (!m_map.is_empty ())
+m_map.remove ((*m_map.begin ()).first);
+#endif
 
   /* Copy over from intermediate map.  */
   for (typename map_t::iterator iter = tmp_map.begin ();
-- 
2.21.0

Re: Replace update_web_docs_svn with update_web_docs_git

[Jonathan Wakely]

On 13/01/20 21:42 +, Joseph Myers wrote:

On Mon, 13 Jan 2020, Jonathan Wakely wrote:


On 13/01/20 17:46 +, Joseph Myers wrote:
> This patch replaces the update_web_docs_svn script, that updates
> online documentation from its sources in the GCC repository, run once
> a day from cron, with update_web_docs_git.
>
> Applied to mainline.

And this does the same for the update_web_docs_libstdcxx_svn script.

OK for trunk?


Yes.


Should I do a `git pull` in the gcc-checkout dir on sourceware after
pushing this?


Yes, and install the new crontab (right now the installed crontab has the
call to update_web_docs_libstdcxx_svn commented out, but with this patch
we'll be able to use the checked-in crontab verbatim again).


OK, that's done.

Re: [PATCH] libstdc++/91223 Improve unordered containers == operator

[Jonathan Wakely]

On 13/01/20 22:41 +0100, François Dumont wrote:

On 1/10/20 11:01 PM, Jonathan Wakely wrote:

On 10/01/20 18:54 +0100, François Dumont wrote:

Hi

    Here is my attempt to improve == operator.

    There is a small optimization for the std::unordered_mutiXXX 
containers but the main enhancement rely on some partial template 
specialization of the _Equality type. I limit it to usage of 
unordered containers with std::equal_to to be sure that the 
container _Equal functor is like the key type ==.


I think we can assume that for any _Equal, not just std::equal_to:
http://eel.is/c++draft/unord.req#12.sentence-5

However ...


Ok but...



    Do I need to also consider user partial template 
specialization of std::equal_to ? It is a well know bad practice 
so I hope the Standard says that such a partial specialization 
leads to undefined behavior.


It's certainly not undefined to specialize equal_to, and I'm not sure
how to make your optimisations valid in that case.


This proposal is indeed invalid if you use a std::equal_to partial 
specialization, this is why I asked.




Consider:

struct X
{
  int i;
  int rounded() const { return i - (i % 10); }
  bool operator==(X x) const { return i == x.i; }
};

template<> struct std::equal_to
{
  bool operator()(X l, X r) const
  { return l.rounded() == r.rounded(); }
};

template<> std::hash
{
  bool operator()(X x) const { return hash()(x.rounded()); }
};

std::unordered_multiset u{ X{10}, X{11}, X{12} };
std::unordered_multiset v{ X{15}, X{16}, X{17} };
bool b1 = u == v;
bool b2 = std::is_permutation(u.begin(), u.end(), v.begin());
assert(b1 == b2);

I think the last new specialization in your patch would be used for
this case, and because __x_count == v.count(*u.begin()) it will say
they're equal. But the is_permutation call says they're not.

So I think the assertion would fail, but the standard says it should
pass. Am I mistaken?


I agree, it would fail and the Standard says it should pass.

So here is a new proposal. For the unique keys case I think we are 
good, I do not see any other optimization.


For the multi-keys we could still avoid redundant comparisons when 
_Equal is just doing == on the key type. On unordered_multiset we 
could just avoids the call to is_permuation and on the 
unordered_multimap we could check the is_permutation only on the 
associated value rather than on the std::pair.


In order to detect that _Equal is the std::equal_to from 
stl_function.h it would be great to have something like a 
__builtin_is_system returning true for types defined in system 
headers. For now I try to propose something similar without compiler 
help.


I don't think that's necessary, or helpful.

The idea of https://gcc.gnu.org/ml/libstdc++/2020-01/msg00070.html is
that you shouldn't be using _Equal at all, and therefore it doesn't
matter whether it's std::equal_to or not.

Re: Replace update_web_docs_svn with update_web_docs_git

[Joseph Myers]

On Mon, 13 Jan 2020, Jonathan Wakely wrote:

> On 13/01/20 17:46 +, Joseph Myers wrote:
> > This patch replaces the update_web_docs_svn script, that updates
> > online documentation from its sources in the GCC repository, run once
> > a day from cron, with update_web_docs_git.
> > 
> > Applied to mainline.
> 
> And this does the same for the update_web_docs_libstdcxx_svn script.
> 
> OK for trunk?

Yes.

> Should I do a `git pull` in the gcc-checkout dir on sourceware after
> pushing this?

Yes, and install the new crontab (right now the installed crontab has the 
call to update_web_docs_libstdcxx_svn commented out, but with this patch 
we'll be able to use the checked-in crontab verbatim again).

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

Re: [PATCH] libstdc++/91223 Improve unordered containers == operator

[François Dumont]

On 1/10/20 11:01 PM, Jonathan Wakely wrote:

On 10/01/20 18:54 +0100, François Dumont wrote:

Hi

    Here is my attempt to improve == operator.

    There is a small optimization for the std::unordered_mutiXXX 
containers but the main enhancement rely on some partial template 
specialization of the _Equality type. I limit it to usage of 
unordered containers with std::equal_to to be sure that the container 
_Equal functor is like the key type ==.


I think we can assume that for any _Equal, not just std::equal_to:
http://eel.is/c++draft/unord.req#12.sentence-5

However ...


Ok but...



    Do I need to also consider user partial template specialization 
of std::equal_to ? It is a well know bad practice so I hope the 
Standard says that such a partial specialization leads to undefined 
behavior.


It's certainly not undefined to specialize equal_to, and I'm not sure
how to make your optimisations valid in that case.


This proposal is indeed invalid if you use a std::equal_to partial 
specialization, this is why I asked.




Consider:

struct X
{
  int i;
  int rounded() const { return i - (i % 10); }
  bool operator==(X x) const { return i == x.i; }
};

template<> struct std::equal_to
{
  bool operator()(X l, X r) const
  { return l.rounded() == r.rounded(); }
};

template<> std::hash
{
  bool operator()(X x) const { return hash()(x.rounded()); }
};

std::unordered_multiset u{ X{10}, X{11}, X{12} };
std::unordered_multiset v{ X{15}, X{16}, X{17} };
bool b1 = u == v;
bool b2 = std::is_permutation(u.begin(), u.end(), v.begin());
assert(b1 == b2);

I think the last new specialization in your patch would be used for
this case, and because __x_count == v.count(*u.begin()) it will say
they're equal. But the is_permutation call says they're not.

So I think the assertion would fail, but the standard says it should
pass. Am I mistaken?


I agree, it would fail and the Standard says it should pass.

So here is a new proposal. For the unique keys case I think we are good, 
I do not see any other optimization.


For the multi-keys we could still avoid redundant comparisons when 
_Equal is just doing == on the key type. On unordered_multiset we could 
just avoids the call to is_permuation and on the unordered_multimap we 
could check the is_permutation only on the associated value rather than 
on the std::pair.


In order to detect that _Equal is the std::equal_to from stl_function.h 
it would be great to have something like a __builtin_is_system returning 
true for types defined in system headers. For now I try to propose 
something similar without compiler help.


François


diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h
index 8fac385570b..9e721aad8cc 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -337,6 +337,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	   bool _Constant_iteratorsa>
 	friend struct __detail::_Insert;
 
+  template
+	friend struct __detail::_Equality;
+
 public:
   using size_type = typename __hashtable_base::size_type;
   using difference_type = typename __hashtable_base::difference_type;
diff --git a/libstdc++-v3/include/bits/hashtable_policy.h b/libstdc++-v3/include/bits/hashtable_policy.h
index 7bbfdfd375b..55c020f93d1 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -34,6 +34,7 @@
 #include 		// for std::tuple, std::forward_as_tuple
 #include 		// for std::numeric_limits
 #include 	// for std::min.
+#include 	// for std::is_permutation.
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -1815,65 +1816,6 @@ namespace __detail
 _M_eq() const { return _EqualEBO::_M_cget(); }
   };
 
-  /**
-   *  struct _Equality_base.
-   *
-   *  Common types and functions for class _Equality.
-   */
-  struct _Equality_base
-  {
-  protected:
-template
-  static bool
-  _S_is_permutation(_Uiterator, _Uiterator, _Uiterator);
-  };
-
-  // See std::is_permutation in N3068.
-  template
-bool
-_Equality_base::
-_S_is_permutation(_Uiterator __first1, _Uiterator __last1,
-		  _Uiterator __first2)
-{
-  for (; __first1 != __last1; ++__first1, ++__first2)
-	if (!(*__first1 == *__first2))
-	  break;
-
-  if (__first1 == __last1)
-	return true;
-
-  _Uiterator __last2 = __first2;
-  std::advance(__last2, std::distance(__first1, __last1));
-
-  for (_Uiterator __it1 = __first1; __it1 != __last1; ++__it1)
-	{
-	  _Uiterator __tmp =  __first1;
-	  while (__tmp != __it1 && !bool(*__tmp == *__it1))
-	++__tmp;
-
-	  // We've seen this one before.
-	  if (__tmp != __it1)
-	continue;
-
-	  std::ptrdiff_t __n2 = 0;
-	  for (__tmp = __first2; __tmp != __last2; ++__tmp)
-	if (*__tmp == *__it1)
-	  ++__n2;
-
-	  if (!__n2)
-	return false;
-
-	  std::ptrdiff_t __n1 = 0;
-	  for (__tmp = __it1; __tmp != __last1; ++__tmp)
-	if (*__tmp == *__it1)
-	  ++__n1;
-
-	  if (__n1 != 

Re: Replace update_web_docs_svn with update_web_docs_git

[Jonathan Wakely]

On 13/01/20 17:46 +, Joseph Myers wrote:

This patch replaces the update_web_docs_svn script, that updates
online documentation from its sources in the GCC repository, run once
a day from cron, with update_web_docs_git.

Applied to mainline.


And this does the same for the update_web_docs_libstdcxx_svn script.

OK for trunk?

Should I do a `git pull` in the gcc-checkout dir on sourceware after
pushing this?

commit 837a33b15533232bf8c86b794e824be32899c2c4
Author: Jonathan Wakely 
Date:   Mon Jan 13 21:26:54 2020 +

Replace update_web_docs_libstdcxx_svn with update_web_docs_libstdcxx_git

This patch replaces the update_web_docs_libstdcxx_svn script, that
updates online documentation from its sources in the GCC repository, run
once a day from cron, with update_web_docs_libstdcxx_git.

* update_web_docs_libstdcxx_git: New file.
* update_web_docs_libstdcxx_svn: Remove.
* crontab: Use update_web_docs_libstdcxx_git.

diff --git a/maintainer-scripts/crontab b/maintainer-scripts/crontab
index 64edcc126fb..9470f3345bb 100644
--- a/maintainer-scripts/crontab
+++ b/maintainer-scripts/crontab
@@ -1,6 +1,6 @@
 16  0 * * * sh /home/gccadmin/scripts/update_version_git
 50  0 * * * sh /home/gccadmin/scripts/update_web_docs_git
-55  0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
+55  0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_git
 32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 8:releases/gcc-8 -l -d /sourceware/snapshot-tmp/gcc all
 32 22 * * 6 sh /home/gccadmin/scripts/gcc_release -s 9:releases/gcc-9 -l -d /sourceware/snapshot-tmp/gcc all
 32 22 * * 7 sh /home/gccadmin/scripts/gcc_release -s 10:master -l -d /sourceware/snapshot-tmp/gcc all
diff --git a/maintainer-scripts/update_web_docs_libstdcxx_svn b/maintainer-scripts/update_web_docs_libstdcxx_git
similarity index 84%
rename from maintainer-scripts/update_web_docs_libstdcxx_svn
rename to maintainer-scripts/update_web_docs_libstdcxx_git
+++ b/maintainer-scripts/update_web_docs_libstdcxx_git
@@ -1,16 +1,14 @@
 #!/bin/bash
 
 
-# "sh update_web_docs_libstdcxx.sh"
+# "sh update_web_docs_libstdcxx_git"
 # Checks out a copy of the libstdc++-v3 "inner" documentation and puts
 # it in the onlinedocs area.  For an initial description of "inner"
 # docs, see the thread starting with 
 # http://gcc.gnu.org/ml/libstdc++/2000-11/msg00475.html
-#
-# Id: update_v3_web_docs.sh,v 1.4 2000/12/25 05:02:14 pedwards Exp
 #
 
-SVNROOT=${SVNROOT:-"file:///svn/gcc"}
+GITROOT=${GITROOT:-"/git/gcc.git"}
 GETTHIS='libstdc++-v3/doc/html'
 WWWDIR=/www/gcc/htdocs/onlinedocs/libstdc++
 #WWWDIR=/tmp/fake-onlinedocs-testing
@@ -22,7 +20,7 @@ WWWDIR=/www/gcc/htdocs/onlinedocs/libstdc++
 FILTER="newer or same age version exists|0 blocks"
 
 PATH=/usr/local/bin:$PATH
-export SVNROOT
+export GITROOT
 
 test -d $WWWDIR || /bin/mkdir $WWWDIR
 test -d $WWWDIR || { echo something is very wrong ; exit 1; }
@@ -34,9 +32,8 @@ cd $WORKDIR
 
 
 # checkout all the HTML files, get down into an interesting directory
-svn -q export $SVNROOT/trunk/$GETTHIS doc
-cd doc
-rm -f Makefile
+git -C $GITROOT archive master $GETTHIS | tar xf -
+cd $GETTHIS
 
 # copy the tree to the onlinedocs area, preserve directory structure
 find . -depth -print | cpio -pd $WWWDIR 2>&1 | egrep -v "$FILTER"

[committed] testsuite: remove unused dg-line directive

[David Malcolm]

On Mon, 2020-01-13 at 10:46 +0100, Rainer Orth wrote:
> Hi David,
> 
> > On Fri, 2020-01-10 at 08:38 -0700, Jeff Law wrote:
> > > On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:

[...]

> > I've gone ahead and committed this to trunk (r280142) after testing
> > it
> > separately from the rest of the kit, given that it's theoretically
> > of
> > use to plugin authors even without the analyzer.
> 
> this patch (gcc.dg/plugin/diagnostic-test-paths-2.c in particular)
> caused DejaGnu to complain:
> 
> WARNING: dg-line var PyList_New defined, but not used
> 
>   Rainer
>

Oops; sorry.  This was copy error on my part.

Fixed by the following (successfully regrtested and manually inspected).

I've pushed it to master (as 20571289868b98dfff95f754fa174f395dec00af)

Thanks
Dave


gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic-test-paths-2.c: Remove unused dg-line
directive.
---
 gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-2.c 
b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-2.c
index 391aeb9ec30..946a234dd23 100644
--- a/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-2.c
+++ b/gcc/testsuite/gcc.dg/plugin/diagnostic-test-paths-2.c
@@ -22,7 +22,7 @@ make_a_list_of_random_ints_badly(PyObject *self,
 return NULL;
   }
 
-  list = PyList_New(0); /* { dg-line PyList_New } */
+  list = PyList_New(0);

   for (i = 0; i < count; i++) {
 item = PyLong_FromLong(random());
-- 
2.21.0

Re: [PATCH GCC11]Improve uninitialized warning with value range info

[Jeff Law]

On Wed, 2020-01-08 at 12:58 +0800, bin.cheng wrote:
> Hi,
> 
> Function use_pred_not_overlap_with_undef_path_pred of 
> pass_late_warn_uninitialized
> checks if predicate of variable use overlaps with predicate of undefined 
> control flow path.
> For now, it only checks ssa_var comparing against constant, this can be 
> improved where
> ssa_var compares against another ssa_var with value range info, as described 
> in comment:
> 
> + /* Check value range info of rhs, do following transforms:
> +  flag_var < [min, max]  ->  flag_var < max
> +  flag_var > [min, max]  ->  flag_var > min
> +
> +We can also transform LE_EXPR/GE_EXPR to LT_EXPR/GT_EXPR:
> +  flag_var <= [min, max] ->  flag_var < [min, max+1]
> +  flag_var >= [min, max] ->  flag_var > [min-1, max]
> +if no overflow/wrap.  */
> 
> This change can avoid some false warning.  Bootstrap and test on x86_64, any 
> comment?
> 
> Thanks,
> bin
> 
> 2020-01-08  Bin Cheng  
> 
>   * tree-ssa-uninit.c (find_var_cmp_const): New function.
>   (use_pred_not_overlap_with_undef_path_pred): Call above.
Totally agree with Richi in that it's a good idea.  I've always
expected that as we make ranges first class citizens that we'd find
more places to use 'em.


Jeff

Re: [PATCH 0/2] Make C front end share the C++ tree representation of loops and switches

[Jeff Law]

On Mon, 2020-01-13 at 13:32 -0500, Jason Merrill wrote:
> On 12/12/19 3:44 PM, Jason Merrill wrote:
> > On Wed, Dec 11, 2019 at 1:37 PM Jeff Law  > > wrote:
> > On Wed, 2019-12-11 at 00:03 -0700, Sandra Loosemore wrote:
> >  > On 12/6/19 3:41 PM, Jeff Law wrote:
> >  > > On Wed, 2019-11-13 at 09:27 -0700, Sandra Loosemore wrote:
> >  > > > I bootstrapped and regression-tested this on x86_64-linux-
> >  > > > gnu.  There
> >  > > > are a few regressions involving these tests:
> >  > > >
> >  > > > gcc.dg/tree-ssa/pr77445-2.c
> >  > > I believe tihs is another instance of the FSA optimization.  I'd
> >  > > need
> >  > > to see the before/after dumps to know if it's regressed.  The main
> >  > > purpose of the test was to verify that we didn't muck up the
> >  > > profile
> >  > > estimation after the FSA optimization.
> >  > >
> >  > >
> >  > > > gcc.dg/tree-ssa/ssa-dce-3.c
> >  > > So I think this one is supposed to collapse into a trivial infinite
> >  > > loop.  Anything else would be a regression.
> >  > >
> >  > >
> >  > > > gcc.dg/tree-ssa/ssa-dom-thread-7.c
> >  > > This is the FSA optimization.  Unfortunately checking for it being
> >  > > done
> >  > > right is exceedingly painful.  If you pass along the before/after
> >  > > dumps
> >  > > I can probably help determine whether or not we just need an update
> >  > > to
> >  > > the scanned bits.
> >  > >
> >  > > Given how much pressure there was to handle the FSA optimization,
> >  > > I'd
> >  > > prefer to make sure we're still doing it before moving forward.
> >  >
> >  > I poked at these 3 test cases some more.  FWIW, it appears that if
> >  > you
> >  > use an unmodified build to compile them as C++ instead of C, the
> >  > same
> >  > problems appear.  So I guess it is an existing bug in
> >  > something-or-another that we are not presently optimizing code output
> >  > by
> >  > the C++ front end as well as that from the C front end.  :-S  (At
> >  > least,
> >  > the ssa-dce-3.c optimization failure is a bug; the other two might
> >  > be
> >  > fragile test cases.)
> >  >
> >  > The C++ front end used to lower loops in exactly the same way as the
> >  > C
> >  > front end.  This is the patch that changed it:
> >  >
> >  > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01994.html
> >  >
> >  > There wasn't much discussion about how this affected optimization
> >  > beyond
> >  > noting a slight decrease in code size for a single benchmark, and no
> >  > consideration at all of whether it wouldn't be better to have the C
> >  > and
> >  > C++ front ends use the same lowering strategy for loops, whichever
> >  > way
> >  > produced better code, so that the optimizers can better recognize
> >  > the
> >  > common patterns from both languages.
> >  >
> >  > Anyway, I'm no longer expecting to get this front end patch into GCC
> >  > 10,
> >  > but it would be helpful to get some guidance on how to proceed for
> >  > resubmission when stage 1 re-opens.  E.g. from where I'm sitting
> >  > now,
> >  > fixing the C++ constexpr evaluator to handle gotos (if it doesn't
> >  > already?) and reverting to the C way of lowering loops seems like a
> >  > much
> >  > more bounded problem than fixing optimizers and trying to benchmark
> >  > their effectiveness.  :-S  OTOH, somebody more familiar with these
> >  > optimizations might see easy fixes.  Or I could re-jigger my patches
> >  > to
> >  > continue to use different loop lowering strategies for C and C++ so
> >  > it
> >  > at least wouldn't make things any worse for either language than it
> >  > already is.
> > Well, I'm happy to look at the before/after dumps if you pass them
> > along.   I'd certainly like to see the two front-ends sharing these
> > bits.
> > 
> > Here are the dumps from ssa-dom-thread-7.c made to compile as C++; 
> > cx-current is the dumps with current trunk; cx-old is changed to use the 
> > old goto-based lowering like C.
> 
> Have you had a chance to look at these at all?  Does it make sense to 
> check in my patch to revert C++ loop lowering to be like C again?
Sorry, I haven't.  Too much time prepping Fedora for LTO...

jeff

[PING^4][PATCH v3] Add `--with-toolexeclibdir=' configuration option

[Maciej W. Rozycki]

On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:

> Provide means, in the form of a `--with-toolexeclibdir=' configuration 
> option, to override the default installation directory for target 
> libraries, otherwise known as $toolexeclibdir.  This is so that it is 
> possible to get newly-built libraries, particularly the shared ones, 
> installed in a common place, so that they can be readily used by the 
> target system as their host libraries, possibly over NFS, without a need 
> to manually copy them over from the currently hardcoded location they 
> would otherwise be installed in.

 Ping for:



  Maciej

[PING^6][PATCH 0/4] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki]

On Fri, 20 Dec 2019, Mike Stump wrote:

> >> This patch series addresses a problem with the testsuite compiler being 
> >> set up across libatomic, libffi, libgo, libgomp with no correlation 
> >> whatsoever to the target compiler being used in GCC compilation.  
> >> Consequently there in no arrangement made to set up the compilation 
> >> sysroot according to the build sysroot specified for GCC compilation, 
> >> causing a catastrophic failure across the testsuites affected from the 
> >> inability to link executables.
> > 
> > Ping for:
> > 
> > 
> > 
> > 
> 
> Hum...  I'm wondering who should review this...  Feels like I should, 
> the problem is it intertwines with the build system as well.  So, let me 
> approve the testsuite parts so that can clear the way for someone else 
> to approve the remaining bits (if not obvious).

 Ping for the build system parts of:




  Maciej

Re: [PATCH] doc: Note that some warnings depend on optimizations (PR 92757)

[Jonathan Wakely]

On 13/01/20 17:27 +, Martin Sebor wrote:

On 12/2/19 9:35 PM, Jonathan Wakely wrote:

PR driver/92757
* doc/invoke.texi (Warning Options): Add caveat about some warnings
depending on optimization settings.

The bug reporter wants this clarified. I'm not entirely convinced it's
necessary, but it doesn't seem to do any harm.

OK for trunk?


I think adding something to the manual about this interplay would
be useful but I'm not sure that saying only that some warnings have
this dependency will help all that much.  I think each warning that
significantly depends on optimization should document it and,
ideally, explain to what extent.  That way users will be clear on
what to expect.  I suspect I might have been responsible for at least
some of the confusion here (I've added warnings that work both with
and without optimization but that do a much better job with it than
without), so I should probably take an AI to review the manual and
try to add some clarity.


Some of them already do say it, the bug report was that users
shouldn't have to read every individual option to learn that
diagnostic quality varies with optimisations.

Re: [C++ PATCH RFC] PR c++/80265 - constexpr __builtin_mem*.

[Jakub Jelinek]

On Mon, Jan 13, 2020 at 06:38:23PM +, Jonathan Wakely wrote:
> > > On 11/01/20 00:03 -0500, Jason Merrill wrote:
> > > >The library has already worked around this issue, but I was curious about
> > > >why it wasn't working.  The answer: because we were passing  to fold,
> > > >which doesn't know about the constexpr values hash table.  Fixed by
> > > passing
> > > >&"str" instead.
> > > >
> > > >Tested x86_64-pc-linux-gnu.  Does this seem useful even though it isn't
> > > >necessary anymore?
> > > 
> > > I'd still like to be able to use memcpy and memmove in constexpr
> > > evaluation. We've added our own "std::__memmove" for use at compile
> > > time, but it doesn't really have the same semantics. We could fix
> > > that, but it would be better to just use the real thing.
> > > 
> > 
> > Ah, supporting memcpy/memmove would be more work than the cmp/chr
> > functions, I'd have to reimplement them entirely in constexpr.c.
> 
> Ah, OK, nevermind then. We'll reimplement just what we need in the
> library.

Guess the hardest part is write helper functions that reads or stores a
single byte at specific address, the builtins then could be easily
implemented by just calling those in a way simplest C implementation of
those functions would do.  But if we have those, we could handle easily many
of the str/mem* functions that way.

Jakub

Re: [C++ PATCH RFC] PR c++/80265 - constexpr __builtin_mem*.

[Jonathan Wakely]

On 13/01/20 12:53 -0500, Jason Merrill wrote:

On Mon, Jan 13, 2020 at 6:11 AM Jonathan Wakely  wrote:


On 11/01/20 00:03 -0500, Jason Merrill wrote:
>The library has already worked around this issue, but I was curious about
>why it wasn't working.  The answer: because we were passing  to fold,
>which doesn't know about the constexpr values hash table.  Fixed by
passing
>&"str" instead.
>
>Tested x86_64-pc-linux-gnu.  Does this seem useful even though it isn't
>necessary anymore?

I'd still like to be able to use memcpy and memmove in constexpr
evaluation. We've added our own "std::__memmove" for use at compile
time, but it doesn't really have the same semantics. We could fix
that, but it would be better to just use the real thing.



Ah, supporting memcpy/memmove would be more work than the cmp/chr
functions, I'd have to reimplement them entirely in constexpr.c.


Ah, OK, nevermind then. We'll reimplement just what we need in the
library.

Re: [PATCH 0/2] Make C front end share the C++ tree representation of loops and switches

[Jason Merrill]

On 12/12/19 3:44 PM, Jason Merrill wrote:
On Wed, Dec 11, 2019 at 1:37 PM Jeff Law > wrote:

On Wed, 2019-12-11 at 00:03 -0700, Sandra Loosemore wrote:
 > On 12/6/19 3:41 PM, Jeff Law wrote:
 > > On Wed, 2019-11-13 at 09:27 -0700, Sandra Loosemore wrote:
 > > > I bootstrapped and regression-tested this on x86_64-linux-
 > > > gnu.  There
 > > > are a few regressions involving these tests:
 > > >
 > > > gcc.dg/tree-ssa/pr77445-2.c
 > > I believe tihs is another instance of the FSA optimization.  I'd
 > > need
 > > to see the before/after dumps to know if it's regressed.  The main
 > > purpose of the test was to verify that we didn't muck up the
 > > profile
 > > estimation after the FSA optimization.
 > >
 > >
 > > > gcc.dg/tree-ssa/ssa-dce-3.c
 > > So I think this one is supposed to collapse into a trivial infinite
 > > loop.  Anything else would be a regression.
 > >
 > >
 > > > gcc.dg/tree-ssa/ssa-dom-thread-7.c
 > > This is the FSA optimization.  Unfortunately checking for it being
 > > done
 > > right is exceedingly painful.  If you pass along the before/after
 > > dumps
 > > I can probably help determine whether or not we just need an update
 > > to
 > > the scanned bits.
 > >
 > > Given how much pressure there was to handle the FSA optimization,
 > > I'd
 > > prefer to make sure we're still doing it before moving forward.
 >
 > I poked at these 3 test cases some more.  FWIW, it appears that if
 > you
 > use an unmodified build to compile them as C++ instead of C, the
 > same
 > problems appear.  So I guess it is an existing bug in
 > something-or-another that we are not presently optimizing code output
 > by
 > the C++ front end as well as that from the C front end.  :-S  (At
 > least,
 > the ssa-dce-3.c optimization failure is a bug; the other two might
 > be
 > fragile test cases.)
 >
 > The C++ front end used to lower loops in exactly the same way as the
 > C
 > front end.  This is the patch that changed it:
 >
 > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01994.html
 >
 > There wasn't much discussion about how this affected optimization
 > beyond
 > noting a slight decrease in code size for a single benchmark, and no
 > consideration at all of whether it wouldn't be better to have the C
 > and
 > C++ front ends use the same lowering strategy for loops, whichever
 > way
 > produced better code, so that the optimizers can better recognize
 > the
 > common patterns from both languages.
 >
 > Anyway, I'm no longer expecting to get this front end patch into GCC
 > 10,
 > but it would be helpful to get some guidance on how to proceed for
 > resubmission when stage 1 re-opens.  E.g. from where I'm sitting
 > now,
 > fixing the C++ constexpr evaluator to handle gotos (if it doesn't
 > already?) and reverting to the C way of lowering loops seems like a
 > much
 > more bounded problem than fixing optimizers and trying to benchmark
 > their effectiveness.  :-S  OTOH, somebody more familiar with these
 > optimizations might see easy fixes.  Or I could re-jigger my patches
 > to
 > continue to use different loop lowering strategies for C and C++ so
 > it
 > at least wouldn't make things any worse for either language than it
 > already is.
Well, I'm happy to look at the before/after dumps if you pass them
along.   I'd certainly like to see the two front-ends sharing these
bits.

Here are the dumps from ssa-dom-thread-7.c made to compile as C++; 
cx-current is the dumps with current trunk; cx-old is changed to use the 
old goto-based lowering like C.


Have you had a chance to look at these at all?  Does it make sense to 
check in my patch to revert C++ loop lowering to be like C again?


Jason

Re: Replace update_web_docs_svn with update_web_docs_git

[Joseph Myers]

I've also applied this corresponding web page update.

diff --git a/htdocs/releasing.html b/htdocs/releasing.html
index 5d08550c..48853f9c 100644
--- a/htdocs/releasing.html
+++ b/htdocs/releasing.html
@@ -89,9 +89,9 @@ the main web page, and add a proper news item there as 
well.
 and add a link from the main buildstat.html page.
 
 Generate online documentation for the new release with
-update_web_docs_svn.  The appropriate command to run (as gccadmin)
-to generate the documentation would be scripts/update_web_docs_svn
--rgcc_3_0_2_release -dgcc-3.0.2 (with the current version
+update_web_docs_git.  The appropriate command to run (as gccadmin)
+to generate the documentation would be scripts/update_web_docs_git
+-r3.0.2 -dgcc-3.0.2 (with the current version
 number inserted).  Link to it from onlinedocs/index.html
 (but don't break URLs to documentation for previous releases even if
 you remove the links to it).  Create additionally

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

Re: [PATCH] Clean up references to Subversion in documentation sources.

[Eric S. Raymond]

Jonathan Wakely :
> Email the patches to gcc-patches@gcc.gnu.org, that's how things get
> merged.
> 
> We're not looking to change any workflows now.

Roger that.

Once the dust from the conversion has settled, though, there is a
related issue I intend to bring up on the main list.

You've only collected about 60% of the potential benefits from git
by adopting git itself.  The other 40% would come from moving
to to one of the modern git-centric forges like GitHub or GitLab.

I'm as old-school as any of you guys, so take me seriously when I say
these are not popular for merely faddish reasns. The integration of
repository management, issue tracking, and continuous integration they
offer really does offer a major step up in productivity and
auditability.

I *will* be nudging the GCC project community to think about this.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

IPA: Avoid segfault in devirtualization_time_bonus (PR 93223)

[Martin Jambor]

Hi,

the following patch fixes a segfault happening when IPA-CP tried to
evaluate benefits of inlining a function specifically compiled with -O0,
which therefore does not have an inline summary.   The fix is simply to
add the check.  Bootstrapped on x86_64-linux, Honza has just approved it
offline and I will commit it momentarily.

Thanks,

Martin


2020-01-13  Martin Jambor  

PR ipa/93223
* ipa-cp.c (devirtualization_time_bonus): Check whether isummary is
NULL.

testsuite/
* g++.dg/ipa/pr93223.C: New test.
---
 gcc/ipa-cp.c   |  2 +-
 gcc/testsuite/g++.dg/ipa/pr93223.C | 62 ++
 2 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr93223.C

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 1c1103ca32b..1b8a5104a3d 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -3158,7 +3158,7 @@ devirtualization_time_bonus (struct cgraph_node *node,
   if (avail < AVAIL_AVAILABLE)
continue;
   isummary = ipa_fn_summaries->get (callee);
-  if (!isummary->inlinable)
+  if (!isummary || !isummary->inlinable)
continue;
 
   int size = ipa_size_summaries->get (callee)->size;
diff --git a/gcc/testsuite/g++.dg/ipa/pr93223.C 
b/gcc/testsuite/g++.dg/ipa/pr93223.C
new file mode 100644
index 000..87f98b5e244
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr93223.C
@@ -0,0 +1,62 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -std=gnu++14" } */
+
+template 
+bool run(const int item_count,
+ Function && process_range,
+ const int max_parallelism,
+ int* progress = nullptr)
+{
+if (max_parallelism <= 1)
+{
+if (progress == nullptr)
+{
+return process_range(0);
+}
+else
+{
+auto result = true;
+for (int i = 0; i != item_count && result; ++i)
+{
+(*progress)++;
+result = process_range(i);
+}
+return result;
+}
+}
+
+if (max_parallelism > 10)
+{
+if (progress == nullptr)
+{
+return process_range(0);
+}
+else
+{
+auto result = true;
+for (int i = 0; i != item_count && result; ++i)
+{
+(*progress)++;
+result = process_range(i);
+}
+return result;
+}
+}
+return false;
+}
+
+namespace
+{
+__attribute__((optimize(0))) bool worker_fun(const int)
+{
+return true;
+}
+}
+
+void demo(int n)
+{
+for (int i = 0; i < n; ++i)
+{
+run(n, _fun, n);
+}
+}
-- 
2.24.1

Re: [PATCH] Fix ctz issues (PR93231)

[Jakub Jelinek]

On Mon, Jan 13, 2020 at 05:30:23PM +, Wilco Dijkstra wrote:
> Further improve the ctz recognition: Avoid ICEing on negative shift
> counts or multiply constants.  Check the type is 8 bits for the string
> constant case to avoid accidentally matching a wide STRING_CST.
> Add a tree_expr_nonzero_p check to allow the optimization even if
> CTZ_DEFINED_VALUE_AT_ZERO returns 0 or 1.  Add extra test cases.
> 
> (note the diff uses the old tree and includes Jakub's bootstrap fixes)

You should rebase it because you'll be committing it against trunk
which already has those changes.

> @@ -1879,7 +1879,7 @@ optimize_count_trailing_zeroes (tree array_ref, tree x, 
> tree mulc,
>if (!low || !integer_zerop (low))
>  return false;
>  
> -  unsigned shiftval = tree_to_uhwi (tshift);
> +  unsigned shiftval = tree_to_shwi (tshift);

This relies on the FEs to narrow the type of say:
x >> (((__uint128_t) 0x12 << 64) | 0x1234567812345678ULL)

> @@ -1889,12 +1889,13 @@ optimize_count_trailing_zeroes (tree array_ref, tree 
> x, tree mulc,
>if (!ctor)
>  return false;
>  
> -  unsigned HOST_WIDE_INT val = tree_to_uhwi (mulc);
> +  /* Extract the binary representation of the multiply constant.  */
> +  unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (mulc);

Will it work properly with the signed types though?
The difference is whether the C code we are matching will use logical or
arithmetic right shift.  And if the power of two times mulc ever can have
sign bit set, it will then use negative indexes into the array.

> -  if (TREE_CODE (ctor) == STRING_CST)
> +  if (TREE_CODE (ctor) == STRING_CST && TYPE_PRECISION (type) == 8)

Isn't another precondition that BITS_PER_UNIT is 8 (because STRING_CSTs are
really bytes)?

>  return check_ctz_string (ctor, val, zero_val, shiftval, input_bits);
>  
>return false;
> @@ -1920,15 +1921,24 @@ simplify_count_trailing_zeroes (gimple_stmt_iterator 
> *gsi)
> res_ops[1], res_ops[2], zero_val))
>  {
>tree type = TREE_TYPE (res_ops[0]);
> -  HOST_WIDE_INT ctzval;
> +  HOST_WIDE_INT ctz_val = 0;
>HOST_WIDE_INT type_size = tree_to_shwi (TYPE_SIZE (type));
> -  bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), ctzval) == 
> 2;
> +  bool zero_ok =
> + CTZ_DEFINED_VALUE_AT_ZERO (SCALAR_INT_TYPE_MODE (type), ctz_val) == 2;

= shouldn't be at the end of line.

Jakub

Re: [C++ PATCH RFC] PR c++/80265 - constexpr __builtin_mem*.

[Jason Merrill]

On Mon, Jan 13, 2020 at 6:11 AM Jonathan Wakely  wrote:

> On 11/01/20 00:03 -0500, Jason Merrill wrote:
> >The library has already worked around this issue, but I was curious about
> >why it wasn't working.  The answer: because we were passing  to fold,
> >which doesn't know about the constexpr values hash table.  Fixed by
> passing
> >&"str" instead.
> >
> >Tested x86_64-pc-linux-gnu.  Does this seem useful even though it isn't
> >necessary anymore?
>
> I'd still like to be able to use memcpy and memmove in constexpr
> evaluation. We've added our own "std::__memmove" for use at compile
> time, but it doesn't really have the same semantics. We could fix
> that, but it would be better to just use the real thing.
>

Ah, supporting memcpy/memmove would be more work than the cmp/chr
functions, I'd have to reimplement them entirely in constexpr.c.

Jason

Replace update_web_docs_svn with update_web_docs_git

[Joseph Myers]

This patch replaces the update_web_docs_svn script, that updates
online documentation from its sources in the GCC repository, run once
a day from cron, with update_web_docs_git.

Applied to mainline.

2020-01-13  Joseph Myers  

* update_web_docs_git: New file.
* update_web_docs_svn: Remove.
* crontab: Use update_web_docs_svn.

diff --git a/maintainer-scripts/crontab b/maintainer-scripts/crontab
index 0cf342fdf3a..64edcc126fb 100644
--- a/maintainer-scripts/crontab
+++ b/maintainer-scripts/crontab
@@ -1,5 +1,5 @@
 16  0 * * * sh /home/gccadmin/scripts/update_version_git
-50  0 * * * sh /home/gccadmin/scripts/update_web_docs_svn
+50  0 * * * sh /home/gccadmin/scripts/update_web_docs_git
 55  0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
 32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 8:releases/gcc-8 -l -d 
/sourceware/snapshot-tmp/gcc all
 32 22 * * 6 sh /home/gccadmin/scripts/gcc_release -s 9:releases/gcc-9 -l -d 
/sourceware/snapshot-tmp/gcc all
diff --git a/maintainer-scripts/update_web_docs_svn 
b/maintainer-scripts/update_web_docs_git
similarity index 95%
rename from maintainer-scripts/update_web_docs_svn
rename to maintainer-scripts/update_web_docs_git
index 16abfee3278..d87a5982f98 100755
--- a/maintainer-scripts/update_web_docs_svn
+++ b/maintainer-scripts/update_web_docs_git
@@ -3,14 +3,14 @@
 # Generate HTML documentation from GCC Texinfo docs.
 #
 # If you want to run this on a machine different from gcc.gnu.org, you
-# may need to adjust SVNROOT and WWWBASE below (or override them via the
+# may need to adjust GITROOT and WWWBASE below (or override them via the
 # environment).
 
 set -e
 
 # Run this from /tmp.
-SVNROOT=${SVNROOT:-"file:///svn/gcc"}
-export SVNROOT
+GITROOT=${GITROOT:-"/git/gcc.git"}
+export GITROOT
 
 PATH=/usr/local/bin:$PATH
 
@@ -104,7 +104,7 @@ if [ ! -d $DOCSDIR ]; then
 fi
 
 if [ -z "$RELEASE" ]; then
-  RELEASE=trunk
+  RELEASE=master
 fi
 
 WORKDIR=/tmp/gcc-doc-update.$$
@@ -112,11 +112,12 @@ WORKDIR=/tmp/gcc-doc-update.$$
 rm -rf $WORKDIR
 mkdir $WORKDIR
 cd $WORKDIR
-if [ "$RELEASE" = "trunk" ]; then
-  svn -q export $SVNROOT/$RELEASE gcc
+if [ "$RELEASE" = "master" ]; then
+  git clone -q $GITROOT gcc
 else
-  svn -q export $SVNROOT/tags/$RELEASE gcc
+  git clone -q -b releases/gcc-$RELEASE $GITROOT gcc
 fi
+rm -rf gcc/.git
 
 # Remove all unwanted files.  This is needed to avoid packaging all the
 # sources instead of only documentation sources.
@@ -259,7 +260,7 @@ find jit \
 cd $DOCSDIR
 
 # Finally, generate the installation documentation
-if [ "$RELEASE" = "trunk" ]; then
+if [ "$RELEASE" = "master" ]; then
   SOURCEDIR=$WORKDIR/gcc/gcc/doc
   DESTDIR=$WWWBASE_PREFORMATTED/install
   export SOURCEDIR

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

Re: [PATCH] Clean up references to Subversion in documentation sources.

[Jonathan Wakely]

On 13/01/20 12:24 -0500, Eric S. Raymond wrote:

Joseph Myers :

I think you'll need to commit this for Eric (using --author= to set the
git author, whenever you commit a patch for someone else).  The libstdc++
maintainers can probably handle regenerating the HTML version of the
libstdc++ documentation.


I'm hesitant to request push access this soon, but...you don't seem to
have an MR capability, and I have some other housekeeping/documentation
patches in mind.


Email the patches to gcc-patches@gcc.gnu.org, that's how things get
merged.

We're not looking to change any workflows now.

[PATCH] Fix ctz issues (PR93231)

[Wilco Dijkstra]

Further improve the ctz recognition: Avoid ICEing on negative shift
counts or multiply constants.  Check the type is 8 bits for the string
constant case to avoid accidentally matching a wide STRING_CST.
Add a tree_expr_nonzero_p check to allow the optimization even if
CTZ_DEFINED_VALUE_AT_ZERO returns 0 or 1.  Add extra test cases.

(note the diff uses the old tree and includes Jakub's bootstrap fixes)

Bootstrap OK on AArch64 and x64.

ChangeLog:
2020-01-13  Wilco Dijkstra  

PR tree-optimization/93231
* tree-ssa-forwprop.c
(optimize_count_trailing_zeroes): Use tree_to_shwi for shift
and TREE_INT_CST_LOW for multiply constants.  Check CST_STRING
element size is 8 bits.
(simplify_count_trailing_zeroes): Add test to handle known non-zero
inputs more efficiently.

testsuite/
* gcc.dg/pr90838.c: New test.
* gcc.dg/pr93231.c: New test.
---

diff --git a/gcc/testsuite/gcc.dg/pr90838.c b/gcc/testsuite/gcc.dg/pr90838.c
new file mode 100644
index 
..8070d439f6404dc6884a11e58f1db41c435e61fb
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr90838.c
@@ -0,0 +1,59 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-forwprop2-details" } */
+
+int ctz1 (unsigned x)
+{
+  static const char table[32] = "\x00\x01\x1c\x02\x1d\x0e\x18\x03\x1e\x16\x14"
+"\x0f\x19\x11\x04\b\x1f\x1b\r\x17\x15\x13\x10\x07\x1a\f\x12\x06\v\x05\n\t";
+
+  return table[((unsigned)((x & -x) * 0x077CB531U)) >> 27];
+}
+
+int ctz2 (unsigned x)
+{
+  const int u = 0;
+  static short table[64] =
+{
+  32, 0, 1,12, 2, 6, u,13, 3, u, 7, u, u, u, u,14,
+  10, 4, u, u, 8, u, u,25, u, u, u, u, u,21,27,15,
+  31,11, 5, u, u, u, u, u, 9, u, u,24, u, u,20,26,
+  30, u, u, u, u,23, u,19,29, u,22,18,28,17,16, u
+};
+
+  x = (x & -x) * 0x0450FBAF;
+  return table[x >> 26];
+}
+
+int ctz3 (unsigned x)
+{
+  static int table[32] =
+{
+  0, 1, 2,24, 3,19, 6,25, 22, 4,20,10,16, 7,12,26,
+  31,23,18, 5,21, 9,15,11,30,17, 8,14,29,13,28,27
+};
+
+  if (x == 0) return 32;
+  x = (x & -x) * 0x04D7651F;
+  return table[x >> 27];
+}
+
+static const unsigned long long magic = 0x03f08c5392f756cdULL;
+
+static const char table[64] = {
+ 0,  1, 12,  2, 13, 22, 17,  3,
+14, 33, 23, 36, 18, 58, 28,  4,
+62, 15, 34, 26, 24, 48, 50, 37,
+19, 55, 59, 52, 29, 44, 39,  5,
+63, 11, 21, 16, 32, 35, 57, 27,
+61, 25, 47, 49, 54, 51, 43, 38,
+10, 20, 31, 56, 60, 46, 53, 42,
+ 9, 30, 45, 41,  8, 40,  7,  6,
+};
+
+int ctz4 (unsigned long x)
+{
+  unsigned long lsb = x & -x;
+  return table[(lsb * magic) >> 58];
+}
+
+/* { dg-final { scan-tree-dump-times {= \.CTZ} 4 "forwprop2" { target 
aarch64*-*-* } } } */
diff --git a/gcc/testsuite/gcc.dg/pr93231.c b/gcc/testsuite/gcc.dg/pr93231.c
new file mode 100644
index 
..80853bad23b28abbe51bb6e2b9f8beeb06618e2f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr93231.c
@@ -0,0 +1,35 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-forwprop2-details -Wno-shift-count-negative" 
} */
+
+int ctz_ice1 (int x)
+{
+  static const char table[32] =
+{
+  0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
+  31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
+};
+
+  return table[((int)((x & -x) * -0x077CB531)) >> 27];
+}
+
+int ctz_ice2 (unsigned x)
+{
+  static const char table[32] =
+{
+  0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
+  31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
+};
+
+  return table[((unsigned)((x & -x) * 0x077CB531U)) >> -27];
+}
+
+// This should never match
+int ctz_fail (int x)
+{
+  static const unsigned short int table[32] =
+
u"\x0100\x021c\x0e1d\x0318\x161e\x0f14\x1119\x0804\x1b1f\x170d\x1315\x0710\x0c1a\x0612\x050b\x090a";
+
+  return table[((int)((x & -x) * 0x077CB531)) >> 27];
+}
+
+/* { dg-final { scan-tree-dump-not {= \.CTZ} "forwprop2" } } */
diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
index 
aced6eb2d9139cae277593022415bc5efdf45175..afc52e5dfbaea29cb07707fee6cbbd3e0c969eda
 100644
--- a/gcc/tree-ssa-forwprop.c
+++ b/gcc/tree-ssa-forwprop.c
@@ -1864,8 +1864,8 @@ optimize_count_trailing_zeroes (tree array_ref, tree x, 
tree mulc,
   tree input_type = TREE_TYPE (x);
   unsigned input_bits = tree_to_shwi (TYPE_SIZE (input_type));
 
-  /* Check the array is not wider than integer type and the input is a 32-bit
- or 64-bit type.  */
+  /* Check the array element type is not wider than 32 bits and the input is
+ a 32-bit or 64-bit type.  */
   if (TYPE_PRECISION (type) > 32)
 return false;
   if (input_bits != 32 && input_bits != 64)
@@ -1879,7 +1879,7 @@ optimize_count_trailing_zeroes (tree array_ref, tree x, 
tree mulc,
   if (!low || !integer_zerop (low))
 return false;
 
-  unsigned shiftval = tree_to_uhwi (tshift);
+  unsigned shiftval = tree_to_shwi (tshift);
 
   /* Check the 

Re: [PATCH] doc: Note that some warnings depend on optimizations (PR 92757)

[Martin Sebor]

On 12/2/19 9:35 PM, Jonathan Wakely wrote:

 PR driver/92757
 * doc/invoke.texi (Warning Options): Add caveat about some warnings
 depending on optimization settings.

The bug reporter wants this clarified. I'm not entirely convinced it's
necessary, but it doesn't seem to do any harm.

OK for trunk?


I think adding something to the manual about this interplay would
be useful but I'm not sure that saying only that some warnings have
this dependency will help all that much.  I think each warning that
significantly depends on optimization should document it and,
ideally, explain to what extent.  That way users will be clear on
what to expect.  I suspect I might have been responsible for at least
some of the confusion here (I've added warnings that work both with
and without optimization but that do a much better job with it than
without), so I should probably take an AI to review the manual and
try to add some clarity.

Martin

Re: [PATCH] Clean up references to Subversion in documentation sources.

[Eric S. Raymond]

Joseph Myers :
> I think you'll need to commit this for Eric (using --author= to set the 
> git author, whenever you commit a patch for someone else).  The libstdc++ 
> maintainers can probably handle regenerating the HTML version of the 
> libstdc++ documentation.

I'm hesitant to request push access this soon, but...you don't seem to
have an MR capability, and I have some other housekeeping/documentation
patches in mind.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: [PATCH, GCC/ARM, 4/10] Clear GPR with CLRM

[Kyrill Tkachov]

On 12/18/19 1:26 PM, Mihail Ionescu wrote:

Hi Kyrill,

On 12/17/2019 10:26 AM, Kyrill Tkachov wrote:

Hi Mihail,

On 12/16/19 6:29 PM, Mihail Ionescu wrote:

Hi Kyrill,

On 11/12/2019 09:55 AM, Kyrill Tkachov wrote:

Hi Mihail,

On 10/23/19 10:26 AM, Mihail Ionescu wrote:

[PATCH, GCC/ARM, 4/10] Clear GPR with CLRM

Hi,

=== Context ===

This patch is part of a patch series to add support for Armv8.1-M
Mainline Security Extensions architecture. Its purpose is to improve
code density of functions with the cmse_nonsecure_entry attribute and
when calling function with the cmse_nonsecure_call attribute by using
CLRM to do all the general purpose registers clearing as well as
clearing the APSR register.

=== Patch description ===

This patch adds a new pattern for the CLRM instruction and guards the
current clearing code in output_return_instruction() and thumb_exit()
on Armv8.1-M Mainline instructions not being present.
cmse_clear_registers () is then modified to use the new CLRM 
instruction

when targeting Armv8.1-M Mainline while keeping Armv8-M register
clearing code for VFP registers.

For the CLRM instruction, which does not mandated APSR in the 
register

list, checking whether it is the right volatile unspec or a clearing
register is done in clear_operation_p.

Note that load/store multiple were deemed sufficiently different in
terms of RTX structure compared to the CLRM pattern for a different
function to be used to validate the match_parallel.

ChangeLog entries are as follows:

*** gcc/ChangeLog ***

2019-10-23  Mihail-Calin Ionescu 
2019-10-23  Thomas Preud'homme 

    * config/arm/arm-protos.h (clear_operation_p): Declare.
    * config/arm/arm.c (clear_operation_p): New function.
    (cmse_clear_registers): Generate clear_multiple 
instruction pattern if

    targeting Armv8.1-M Mainline or successor.
    (output_return_instruction): Only output APSR register 
clearing if

    Armv8.1-M Mainline instructions not available.
    (thumb_exit): Likewise.
    * config/arm/predicates.md (clear_multiple_operation): New 
predicate.

    * config/arm/thumb2.md (clear_apsr): New define_insn.
    (clear_multiple): Likewise.
    * config/arm/unspecs.md (VUNSPEC_CLRM_APSR): New volatile 
unspec.


*** gcc/testsuite/ChangeLog ***

2019-10-23  Mihail-Calin Ionescu 
2019-10-23  Thomas Preud'homme 

    * gcc.target/arm/cmse/bitfield-1.c: Add check for CLRM.
    * gcc.target/arm/cmse/bitfield-2.c: Likewise.
    * gcc.target/arm/cmse/bitfield-3.c: Likewise.
    * gcc.target/arm/cmse/struct-1.c: Likewise.
    * gcc.target/arm/cmse/cmse-14.c: Likewise.
    * gcc.target/arm/cmse/cmse-1.c: Likewise. Restrict checks 
for Armv8-M

    GPR clearing when CLRM is not available.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-4.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-5.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-6.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-7.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-8.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/bitfield-9.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard-sp/cmse-13.c: 
Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard-sp/cmse-5.c: 
Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard-sp/cmse-7.c: 
Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard-sp/cmse-8.c: 
Likewise.

    * gcc.target/arm/cmse/mainline/8_1m/hard/cmse-13.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard/cmse-5.c: likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard/cmse-7.c: likewise.
    * gcc.target/arm/cmse/mainline/8_1m/hard/cmse-8.c: likewise.
    * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-13.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-5.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-7.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/soft/cmse-8.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp-sp/cmse-5.c: 
Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp-sp/cmse-7.c: 
Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp-sp/cmse-8.c: 
Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp/cmse-13.c: 
Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp/cmse-5.c: 
Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp/cmse-7.c: 
Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/softfp/cmse-8.c: 
Likewise.

    * gcc.target/arm/cmse/mainline/8_1m/union-1.c: Likewise.
    * gcc.target/arm/cmse/mainline/8_1m/union-2.c: Likewise.

Testing: bootstrapped on arm-linux-gnueabihf and testsuite shows no
regression.

Is this ok for trunk?

Best regards,

Mihail


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



diff --git a/gcc/config/arm/arm-protos.h 
b/gcc/config/arm/arm-protos.h
index 

Re: [PATCH] Clean up references to Subversion in documentation sources.

[Jonathan Wakely]

On 13/01/20 16:21 +, Jonathan Wakely wrote:

On 13/01/20 09:09 -0700, Sandra Loosemore wrote:

On 1/13/20 7:02 AM, Eric S. Raymond wrote:

Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.


This is OK, although the set of changes for the libstdc++ manual 
like this gave me pause:



diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
index 2b05ff6601a..cf5722377a6 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
@@ -18,7 +18,7 @@ This status table is based on the table of contents of 
ISO/IEC 14882:2003.


-This page describes the C++ support in mainline GCC SVN, not in any
+This page describes the C++ support in mainline GCC, not in any
particular release.



IIUC the statements being modified here are incorrect; since the 
manuals are packaged with the GCC sources, they go in lock step with 
the source version, and the text of the manual describes the GCC 
version being built, not mainline.  Perhaps the libstdc++ 
documentation maintainers would like to correct this separately?


I did so on the gcc-7 branch, so it says "This page describes the
C++11 support in the GCC 7 series." I have forgotten to do that on the
gcc-8 and gcc-9 branches though, so they lie. I'll do that.


Here's what I've committed to releases/gcc-9, I'll do something
similar for gcc-8.


commit c6f60a62b0b89a0f8c252970f3a4cf0bc2d220ce
Author: Jonathan Wakely 
Date:   Mon Jan 13 16:25:01 2020 +

libstdc++: Fix documentation claiming to refer to mainline

* doc/xml/manual/status_cxx1998.xml: Replace incorrect statement
about documenting mainline.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.
* doc/xml/manual/status_cxx2020.xml: Likewise.
* doc/xml/manual/status_cxxtr1.xml: Likewise.
* doc/xml/manual/status_cxxtr24733.xml: Likewise.
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
index 2b05ff6601a..44a042c2724 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
@@ -18,8 +18,7 @@ This status table is based on the table of contents of ISO/IEC 14882:2003.
 
 
 
-This page describes the C++ support in mainline GCC SVN, not in any
-particular release.
+This page describes the C++ support in the GCC 9 series.
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index 0fa4bc0dffe..568102823b0 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
@@ -27,8 +27,7 @@ presence of the required flag.
 
 
 
-This page describes the C++11 support in mainline GCC SVN, not in any
-particular release.
+This page describes the C++11 support in the GCC 9 series.
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
index a33b4ec1611..7b604307c8e 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
@@ -20,8 +20,7 @@ presence of the required flag.
 
 
 
-This page describes the C++14 and library TS support in mainline GCC SVN,
-not in any particular release.
+This page describes the C++14 and library TS support in the GCC 9 series.
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
index 40fe7cd2037..e1513142415 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -20,8 +20,7 @@ presence of the required flag.
 
 
 
-This section describes the C++17 and library TS support in mainline GCC SVN,
-not in any particular release.
+This section describes the C++17 and library TS support in the GCC 9 series.
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
index ccf38185a6c..fc7fe0a3d9f 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
@@ -20,8 +20,7 @@ presence of the required flag.
 
 
 
-This section describes the C++20 and library TS support in mainline GCC SVN,
-not in any particular release.
+This section describes the C++20 and library TS support in the GCC 9 series.
 
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml b/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml
index 32ad20a2fb2..c1e65752156 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml
@@ -22,8 +22,7 @@ In this implementation the header names are prefixed by
 
 
 
-This page describes the TR1 support in mainline 

Fix handling of overflow in C casts in integer constant expressions (PR c/93241)

[Joseph Myers]

Bug 93241 reports a case where certain C expressions involving casts,
that would not be valid in an evaluated part of an integer constant
expression (because of e.g. involving integer overflow), are wrongly
rejected in an unevaluated part of an integer constant expression even
though all the operands and operations are ones that are valid in that
context.  This is a rejects-valid regression in GCC 4.5 and later
relative to 4.4 (for some testcases; the one in the bug uses
_Static_assert which isn't supported in those older releases).

The rule in the C front end is that an expression with those
properties (valid in an unevaluated part of an integer constant
expression but not an evaluated part) must be represented either as an
INTEGER_CST with TREE_OVERFLOW set or as a C_MAYBE_CONST_EXPR with
C_MAYBE_CONST_EXPR_INT_OPERANDS set.  This patch fixes build_c_cast to
check for that case and call note_integer_operands as needed.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Applied to 
mainline.  Will backport to GCC 9 and 8 branches.

gcc/c:
2020-01-13  Joseph Myers  

PR c/93241
* c-typeck.c (build_c_cast): Check for expressions with integer
operands that can occur in an unevaluated part of an integer
constant expression and call note_integer_operands as needed.

gcc/testsuite:
2020-01-13  Joseph Myers  

PR c/93241
* gcc.dg/c11-static-assert-10.c, gcc.dg/c99-const-expr-15.c: New
tests.

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index c746f23b336..9866c83faf2 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -5709,6 +5709,8 @@ build_c_cast (location_t loc, tree type, tree expr)
 {
   tree value;
 
+  bool int_operands = EXPR_INT_CONST_OPERANDS (expr);
+
   if (TREE_CODE (expr) == EXCESS_PRECISION_EXPR)
 expr = TREE_OPERAND (expr, 0);
 
@@ -5943,6 +5945,14 @@ build_c_cast (location_t loc, tree type, tree expr)
   || TREE_CODE (expr) == COMPLEX_CST)))
   value = build1 (NOP_EXPR, type, value);
 
+  /* If the expression has integer operands and so can occur in an
+ unevaluated part of an integer constant expression, ensure the
+ return value reflects this.  */
+  if (int_operands
+  && INTEGRAL_TYPE_P (type)
+  && !EXPR_INT_CONST_OPERANDS (value))
+value = note_integer_operands (value);
+
   protected_set_expr_location (value, loc);
   return value;
 }
diff --git a/gcc/testsuite/gcc.dg/c11-static-assert-10.c 
b/gcc/testsuite/gcc.dg/c11-static-assert-10.c
new file mode 100644
index 000..2fe210b6cc8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c11-static-assert-10.c
@@ -0,0 +1,9 @@
+/* Test for constant expressions: casts with integer overflow.  PR
+   c/93241.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+#include 
+
+_Static_assert (0 ? (_Bool) (INT_MAX + 1) : 1, "");
+_Static_assert (0 ? (short) ((INT_MAX + 1) != 0) : 1, "");
diff --git a/gcc/testsuite/gcc.dg/c99-const-expr-15.c 
b/gcc/testsuite/gcc.dg/c99-const-expr-15.c
new file mode 100644
index 000..b1744b67182
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c99-const-expr-15.c
@@ -0,0 +1,9 @@
+/* Test for constant expressions: casts with integer overflow.  PR
+   c/93241.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c99 -pedantic-errors" } */
+
+#include 
+
+struct s { int a : (0 ? (_Bool) (INT_MAX + 1) : 1); };
+struct t { int a : (0 ? (short) ((INT_MAX + 1) != 0) : 1); };

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

Re: [PATCH] Clean up references to Subversion in documentation sources.

[Jonathan Wakely]

On 13/01/20 09:09 -0700, Sandra Loosemore wrote:

On 1/13/20 7:02 AM, Eric S. Raymond wrote:

Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.


This is OK, although the set of changes for the libstdc++ manual like 
this gave me pause:



diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
index 2b05ff6601a..cf5722377a6 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
@@ -18,7 +18,7 @@ This status table is based on the table of contents of 
ISO/IEC 14882:2003.
 
 
-This page describes the C++ support in mainline GCC SVN, not in any
+This page describes the C++ support in mainline GCC, not in any
 particular release.
 


IIUC the statements being modified here are incorrect; since the 
manuals are packaged with the GCC sources, they go in lock step with 
the source version, and the text of the manual describes the GCC 
version being built, not mainline.  Perhaps the libstdc++ 
documentation maintainers would like to correct this separately?


I did so on the gcc-7 branch, so it says "This page describes the
C++11 support in the GCC 7 series." I have forgotten to do that on the
gcc-8 and gcc-9 branches though, so they lie. I'll do that.

For similar reasons, I suggest backporting this patch to all active 
GCC release branches, namely GCC 8 and GCC 9, so that manuals packaged 
with upcoming releases from those branches will correctly point to the 
GIT repository instead of SVN.


Agreed.

Re: contrib: script to setup git to pull a vendors branches

[Richard Earnshaw (lists)]

On 10/01/2020 15:04, Richard Earnshaw (lists) wrote:
> This simple script is intended to setup a new git configuration to pull
> the branches and tags for a specific vendor.  This should simplify some
> of the steps needed for working with a vendor's branches.
> 
> * git-fetch-vendor.sh: New file.
> 

I've now checked this in.

R.

Re: [PATCH] Clean up references to Subversion in documentation sources.

[Joseph Myers]

On Mon, 13 Jan 2020, Sandra Loosemore wrote:

> On 1/13/20 7:02 AM, Eric S. Raymond wrote:
> > Clean up references to SVN in in the GCC docs, redirecting to Git
> > documentation as appropriate.
> 
> This is OK, although the set of changes for the libstdc++ manual like this
> gave me pause:

I think you'll need to commit this for Eric (using --author= to set the 
git author, whenever you commit a patch for someone else).  The libstdc++ 
maintainers can probably handle regenerating the HTML version of the 
libstdc++ documentation.

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

Re: [PATCH] Clean up references to Subversion in documentation sources.

[Sandra Loosemore]

On 1/13/20 7:02 AM, Eric S. Raymond wrote:

Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.


This is OK, although the set of changes for the libstdc++ manual like 
this gave me pause:



diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
index 2b05ff6601a..cf5722377a6 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
@@ -18,7 +18,7 @@ This status table is based on the table of contents of 
ISO/IEC 14882:2003.
  
  
  

-This page describes the C++ support in mainline GCC SVN, not in any
+This page describes the C++ support in mainline GCC, not in any
  particular release.
  


IIUC the statements being modified here are incorrect; since the manuals 
are packaged with the GCC sources, they go in lock step with the source 
version, and the text of the manual describes the GCC version being 
built, not mainline.  Perhaps the libstdc++ documentation maintainers 
would like to correct this separately?


For similar reasons, I suggest backporting this patch to all active GCC 
release branches, namely GCC 8 and GCC 9, so that manuals packaged with 
upcoming releases from those branches will correctly point to the GIT 
repository instead of SVN.


-Sandra

Re: Update gcc_release for move to git

[Joseph Myers]

I've now also copied the latest gcc_release version to GCC 9 and 8 
branches, since the git support will be needed there for future releases 
from those branches.

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

Re: [PATCHv2] Add initial octeontx2 support.

[Richard Sandiford]

 writes:
> From: Andrew Pinski 
>
> This adds octeontx2 naming.  It currently uses the cortexa57
> cost model and schedule model until I submit this.  This is
> more a place holder to get the naming of the cores in GCC 10.
> I will submit the cost model in the next couple of days.
>
> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.

OK, thanks.

Richard

> v2 changes: Add documentation and fix minor whitespace issues before the `,'.
>
> Thanks,
> Andrew Pinski
>
> ChangeLog:
> * config/aarch64/aarch64-cores.def (octeontx2): New define.
> (octeontx2t98): New define.
> (octeontx2t96): New define.
> (octeontx2t93): New define.
> (octeontx2f95): New define.
> (octeontx2f95n): New define.
> (octeontx2f95mm): New define.
> * config/aarch64/aarch64-tune.md: Regenerate.
> * doc/invoke.texi (-mcpu=): Document the new cpu types.
>
> Signed-off-by: Andrew Pinski 
> ---
>  gcc/config/aarch64/aarch64-cores.def | 10 ++
>  gcc/config/aarch64/aarch64-tune.md   |  2 +-
>  gcc/doc/invoke.texi  |  6 +-
>  3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/aarch64/aarch64-cores.def 
> b/gcc/config/aarch64/aarch64-cores.def
> index 2dd2b86bd92..ea9b98b4b0a 100644
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -109,6 +109,16 @@ AARCH64_CORE("ares",  ares, cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_F
>  AARCH64_CORE("neoverse-n1",  neoversen1, cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | 
> AARCH64_FL_DOTPROD | AARCH64_FL_PROFILE, neoversen1, 0x41, 0xd0c, -1)
>  AARCH64_CORE("neoverse-e1",  neoversee1, cortexa53, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_F16 | AARCH64_FL_RCPC | 
> AARCH64_FL_DOTPROD | AARCH64_FL_SSBS, cortexa73, 0x41, 0xd4a, -1)
>  
> +/* Cavium ('C') cores. */
> +AARCH64_CORE("octeontx2",  octeontx2,  cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_PROFILE, cortexa57, 
> 0x43, 0x0b0, -1)
> +AARCH64_CORE("octeontx2t98",   octeontx2t98,   cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_PROFILE, cortexa57, 
> 0x43, 0x0b1, -1)
> +AARCH64_CORE("octeontx2t96",   octeontx2t96,   cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_PROFILE, cortexa57, 
> 0x43, 0x0b2, -1)
> +/* Note OcteonTX2 T93 is an alias to OcteonTX2 T96. */
> +AARCH64_CORE("octeontx2t93",   octeontx2t93,   cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_PROFILE, cortexa57, 
> 0x43, 0x0b2, -1)
> +AARCH64_CORE("octeontx2f95",   octeontx2f95,   cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_PROFILE, cortexa57, 
> 0x43, 0x0b3, -1)
> +AARCH64_CORE("octeontx2f95n",  octeontx2f95n,  cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_PROFILE, cortexa57, 
> 0x43, 0x0b4, -1)
> +AARCH64_CORE("octeontx2f95mm", octeontx2f95mm, cortexa57, 8_2A,  
> AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_PROFILE, cortexa57, 
> 0x43, 0x0b5, -1)
> +
>  /* HiSilicon ('H') cores. */
>  AARCH64_CORE("tsv110",  tsv110, tsv110, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | 
> AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, 
> tsv110,   0x48, 0xd01, -1)
>  
> diff --git a/gcc/config/aarch64/aarch64-tune.md 
> b/gcc/config/aarch64/aarch64-tune.md
> index a6a14b7fc77..3cc1c4d761f 100644
> --- a/gcc/config/aarch64/aarch64-tune.md
> +++ b/gcc/config/aarch64/aarch64-tune.md
> @@ -1,5 +1,5 @@
>  ;; -*- buffer-read-only: t -*-
>  ;; Generated automatically by gentune.sh from aarch64-cores.def
>  (define_attr "tune"
> - 
> "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
> + 
> "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
>   (const (symbol_ref "((enum attr_tune) aarch64_tune)")))
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index f2c805c0a64..279b97f51ba 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -16323,7 +16323,11 @@ performance of the code.  Permissible values for 
> 

[PATCH] Clean up references to Subversion in documentation sources.

[Eric S. Raymond]

Clean up references to SVN in in the GCC docs, redirecting to Git
documentation as appropriate.

Where references to "the source code repository" rather than a
specific VCS make sensxse, I have used them. You might, after
all, change VCSes again someday.

I have not modified either generated HTML files nor maintainer scripts.
These changes should be complete with repect to the documentation tree.
---
 gcc/doc/contribute.texi   |  4 +--
 gcc/doc/install.texi  | 32 ++-
 libstdc++-v3/doc/xml/faq.xml  | 21 +++-
 .../doc/xml/manual/appendix_contributing.xml  |  9 ++
 .../doc/xml/manual/status_cxx1998.xml |  2 +-
 .../doc/xml/manual/status_cxx2011.xml |  2 +-
 .../doc/xml/manual/status_cxx2014.xml |  2 +-
 .../doc/xml/manual/status_cxx2017.xml |  2 +-
 .../doc/xml/manual/status_cxx2020.xml |  2 +-
 libstdc++-v3/doc/xml/manual/status_cxxtr1.xml |  2 +-
 .../doc/xml/manual/status_cxxtr24733.xml  |  2 +-
 11 files changed, 33 insertions(+), 47 deletions(-)

diff --git a/gcc/doc/contribute.texi b/gcc/doc/contribute.texi
index 3c711554419..b0b3b44b6a7 100644
--- a/gcc/doc/contribute.texi
+++ b/gcc/doc/contribute.texi
@@ -6,8 +6,8 @@
 @chapter Contributing to GCC Development
 
 If you would like to help pretest GCC releases to assure they work well,
-current development sources are available by SVN (see
-@uref{http://gcc.gnu.org/svn.html}).  Source and binary snapshots are
+current development sources are available via Git (see
+@uref{http://gcc.gnu.org/git.html}).  Source and binary snapshots are
 also available for FTP; see @uref{http://gcc.gnu.org/snapshots.html}.
 
 If you would like to work on improvements to GCC, please read the
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index e62b3dae545..643f3bb311f 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -356,8 +356,9 @@ and up works.
 Necessary when regenerating @file{Makefile} dependencies in libiberty.
 Necessary when regenerating @file{libiberty/functions.texi}.
 Necessary when generating manpages from Texinfo manuals.
-Used by various scripts to generate some files included in SVN (mainly
-Unicode-related and rarely changing) from source tables.
+Used by various scripts to generate some files included in the source
+repository (mainly Unicode-related and rarely changing) from source
+tables.
 
 Used by @command{automake}.
 
@@ -482,8 +483,8 @@ Necessary to regenerate the top level @file{Makefile.in} 
file from
 Necessary when modifying @file{*.l} files.
 
 Necessary to build GCC during development because the generated output
-files are not included in the SVN repository.  They are included in
-releases.
+files are not included in the version-controlled source repository.
+They are included in releases.
 
 @item Texinfo version 4.7 (or later)
 
@@ -495,7 +496,7 @@ create printable documentation in DVI or PDF format.  
Texinfo version
 4.8 or later is required for @command{make pdf}.
 
 Necessary to build GCC documentation during development because the
-generated output files are not included in the SVN repository.  They are
+generated output files are not included in the repository.  They are
 included in releases.
 
 @item @TeX{} (any working version)
@@ -509,10 +510,10 @@ DVI or PDF files, respectively.
 Necessary to regenerate @file{jit/docs/_build/texinfo} from the @file{.rst}
 files in the directories below @file{jit/docs}.
 
-@item SVN (any version)
+@item git (any version)
 @itemx SSH (any version)
 
-Necessary to access the SVN repository.  Public releases and weekly
+Necessary to access the source repository.  Public releases and weekly
 snapshots of the development sources are also available via HTTPS@.
 
 @item GNU diffutils version 2.7 (or later)
@@ -547,7 +548,7 @@ own sources.
 @cindex Downloading GCC
 @cindex Downloading the Source
 
-GCC is distributed via @uref{http://gcc.gnu.org/svn.html,,SVN} and via
+GCC is distributed via @uref{http://gcc.gnu.org/git.html,,git} and via
 HTTPS as tarballs compressed with @command{gzip} or @command{bzip2}.
 
 Please refer to the @uref{http://gcc.gnu.org/releases.html,,releases web page}
@@ -606,9 +607,10 @@ for both native and cross targets.
 We use @var{srcdir} to refer to the toplevel source directory for
 GCC; we use @var{objdir} to refer to the toplevel build/object directory.
 
-If you obtained the sources via SVN, @var{srcdir} must refer to the top
-@file{gcc} directory, the one where the @file{MAINTAINERS} file can be
-found, and not its @file{gcc} subdirectory, otherwise the build will fail.
+If you obtained the sources by cloning the repository, @var{srcdir}
+must refer to the top @file{gcc} directory, the one where the
+@file{MAINTAINERS} file can be found, and not its @file{gcc}
+subdirectory, otherwise the build will fail.
 
 If either @var{srcdir} or @var{objdir} is located on an automounted NFS
 file system, the shell's built-in 

Re: Some local customization enhancements when using git

[Richard Earnshaw (lists)]

On 13/01/2020 13:44, Richard Earnshaw (lists) wrote:
> On 10/01/2020 14:26, Richard Earnshaw (lists) wrote:
>> On 10/01/2020 13:23, Richard Earnshaw (lists) wrote:
>>> This patch is intended to help with folks setting up a git work
>>> environment for use with GCC following the transition to git.  It
>>> currently does a couple of things.
>>>
>>> 1) Add an alias 'svn-rev' to git so that you can look up a legacy
>>> commit by its svn revision number.  This enables you to type
>>> git svn-rev 1234
>>> and git will show the commit log entry relating to SVN r1234.
>>>
>>> 2) Sets up tracking information for the user's private name area in
>>> the git repo.  It tries to figure out some sensible answers to the
>>> data it needs, but allows the user to override the values.  It then
>>> creates the fetch and push entries that are needed for tracking the
>>> extra refs. This implements one part of the recommendations that I've
>>> proposed in svnwrite.html for dealing with private branches.
>>>
>>> It should be possible to run the script more than once and for it to
>>> DTRT.  If you change your answers the configuration should be
>>> correctly updated.
>>>
>>> 2020-01-10  Richard Earnshaw  
>>>
>>>  * gcc-git-customization: New file.
>>>
>>
>> Updated to add better support for diff-ing .md files.
>>
>> R.
> 
> A couple more tweaks to this file and I've now checked it in.
> 
> 1) Added the ability to select the prefix for the personal namespace.
> This will be cached.  If you change it, then the push operations will be
> updated (but any local branches you will have to rename if you want them
> to continue working afterwards).
> 2) Removed the + from the added push spec.
> 

And one more tweak I forgot to mention:

3) an optional 'r' can now be used in front of an svn revision number in
'git svn-rev'.

> R.
> 

Re: [PATCH 2/2] [ARM] Add support for -mpure-code in thumb-1 (v6m)

[Kyrill Tkachov]

Hi Christophe,

On 12/17/19 3:31 PM, Kyrill Tkachov wrote:


On 12/17/19 2:33 PM, Christophe Lyon wrote:

On Tue, 17 Dec 2019 at 11:34, Kyrill Tkachov
 wrote:

Hi Christophe,

On 11/18/19 9:00 AM, Christophe Lyon wrote:

On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
 wrote:

On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
 wrote:

On 18/10/2019 14:18, Christophe Lyon wrote:

+  bool not_supported = arm_arch_notm || flag_pic ||

TARGET_NEON;
This is a poor name in the context of the function as a whole.  
What's
not supported.  Please think of a better name so that I have some 
idea

what the intention is.

That's to keep most of the code common when checking if -mpure-code
and -mslow-flash-data are supported.
These 3 cases are common to the two compilation flags, and
-mslow-flash-data still needs to check TARGET_HAVE_MOVT in addition.

Would "common_unsupported_modes" work better for you?
Or I can duplicate the "arm_arch_notm || flag_pic || TARGET_NEON" in
the two tests.


Hi,

Here is an updated version, using "common_unsupported_modes" instead
of "not_supported", and fixing the typo reported by Kyrill.
The ChangeLog is still the same.

OK?


The name looks ok to me. Richard had a concern about Armv8-M Baseline,
but I do see it being supported as you pointed out.

So I believe all the concerns are addressed.

OK, thanks!


Thus the code is ok. However, please also updated the documentation for
-mpure-code in invoke.texi (it currently states that a MOVT instruction
is needed).


I didn't think about this :(
It currently says: "This option is only available when generating
non-pic code for M-profile targets with the MOVT instruction."

I suggest to remove the "with the MOVT instruction" part. Is that OK
if I commit my patch and this doc change?


Yes, I think that is simplest correct change to make.



Can you also send a patch to the changes.html page for GCC 10 making 
users aware that this restriction is now lifted?


Thanks,

Kyrill



Thanks,

Kyrill



Christophe


Thanks,

Kyrill




Thanks,

Christophe


Thanks,

Christophe


R.

Re: Some local customization enhancements when using git

[Richard Earnshaw (lists)]

On 10/01/2020 14:26, Richard Earnshaw (lists) wrote:
> On 10/01/2020 13:23, Richard Earnshaw (lists) wrote:
>> This patch is intended to help with folks setting up a git work
>> environment for use with GCC following the transition to git.  It
>> currently does a couple of things.
>>
>> 1) Add an alias 'svn-rev' to git so that you can look up a legacy
>> commit by its svn revision number.  This enables you to type
>> git svn-rev 1234
>> and git will show the commit log entry relating to SVN r1234.
>>
>> 2) Sets up tracking information for the user's private name area in
>> the git repo.  It tries to figure out some sensible answers to the
>> data it needs, but allows the user to override the values.  It then
>> creates the fetch and push entries that are needed for tracking the
>> extra refs. This implements one part of the recommendations that I've
>> proposed in svnwrite.html for dealing with private branches.
>>
>> It should be possible to run the script more than once and for it to
>> DTRT.  If you change your answers the configuration should be
>> correctly updated.
>>
>> 2020-01-10  Richard Earnshaw  
>>
>>  * gcc-git-customization: New file.
>>
> 
> Updated to add better support for diff-ing .md files.
> 
> R.

A couple more tweaks to this file and I've now checked it in.

1) Added the ability to select the prefix for the personal namespace.
This will be cached.  If you change it, then the push operations will be
updated (but any local branches you will have to rename if you want them
to continue working afterwards).
2) Removed the + from the added push spec.

R.



gcc-git-customization.sh
Description: application/shellscript

[PATCH] libstdc++: Ensure root-dir converted to forward slash (PR93244)

[Jonathan Wakely]

PR libstdc++/93244
* include/bits/fs_path.h (path::generic_string)
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Convert root-dir to forward-slash.
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Check
root-dir is converted to forward slash in generic pathname.
* testsuite/27_io/filesystem/path/generic/utf.cc: New test.
* testsuite/27_io/filesystem/path/generic/wchar_t.cc: New test.

Tested powerpc64le-linux, committed to master.


commit fe7cc34fd5186cce3771e2bce2f4aacb81b9058c
Author: Jonathan Wakely 
Date:   Mon Jan 13 10:02:39 2020 +

libstdc++: Ensure root-dir converted to forward slash (PR93244)

PR libstdc++/93244
* include/bits/fs_path.h (path::generic_string)
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Convert root-dir to forward-slash.
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Check
root-dir is converted to forward slash in generic pathname.
* testsuite/27_io/filesystem/path/generic/utf.cc: New test.
* testsuite/27_io/filesystem/path/generic/wchar_t.cc: New test.

diff --git a/libstdc++-v3/include/bits/fs_path.h 
b/libstdc++-v3/include/bits/fs_path.h
index 235408b65f4..bf1f09929c3 100644
--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -1136,6 +1136,13 @@ namespace __detail
  bool __add_slash = false;
  for (auto& __elem : *this)
{
+#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+ if (__elem._M_type() == _Type::_Root_dir)
+   {
+ __str += __slash;
+ continue;
+   }
+#endif
  if (__add_slash)
__str += __slash;
  __str += __elem._M_pathname;
diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/generic_string.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/generic_string.cc
index 676605cc09c..677f5f5d1c4 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/generic_string.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/generic_string.cc
@@ -46,8 +46,19 @@ test01()
   VERIFY( path("/a//b//.").generic_string() == "/a/b/." );
 }
 
+void
+test02()
+{
+  // PR libstdc++/93244
+  path p("C:");
+  p += path::preferred_separator;
+  p += "foo/bar";
+  VERIFY( p.generic_string() == "C:/foo/bar" );
+}
+
 int
 main()
 {
   test01();
+  test02();
 }
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/utf.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/utf.cc
new file mode 100644
index 000..9a2f579ebab
--- /dev/null
+++ b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/utf.cc
@@ -0,0 +1,64 @@
+// { dg-options "-std=gnu++17" }
+// { dg-do run { target c++17 } }
+
+// Copyright (C) 2017-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
+// .
+
+// C++17 30.10.7.4.7 path generic format observers [fs.path.generic.obs]
+
+#include 
+#include 
+
+using std::filesystem::path;
+
+void
+test01()
+{
+  VERIFY( path().generic_u32string() == U"" );
+  VERIFY( path("/").generic_u32string() == U"/" );
+  VERIFY( path("").generic_u32string() == U"/" );
+#ifdef __CYGWIN__
+  VERIFY( path("//a").generic_u32string() == U"//a" );
+  VERIFY( path("//a/").generic_u32string() == U"//a/" );
+  VERIFY( path("//a/b").generic_u32string() == U"//a/b" );
+#else
+  VERIFY( path("//a").generic_u32string() == U"/a" );
+  VERIFY( path("//a/").generic_u32string() == U"/a/" );
+  VERIFY( path("//a/b").generic_u32string() == U"/a/b" );
+#endif
+  VERIFY( path("/a//b").generic_u32string() == U"/a/b" );
+  VERIFY( path("/a//b/").generic_u32string() == U"/a/b/" );
+  VERIFY( path("/a//b//").generic_u32string() == U"/a/b/" );
+  VERIFY( path("/a//b//.").generic_u32string() == U"/a/b/." );
+}
+
+void
+test02()
+{
+  // PR libstdc++/93244
+  path p("C:");
+  p += path::preferred_separator;
+  p += "foo/bar";
+  VERIFY( p.generic_u32string() == U"C:/foo/bar" );
+}
+
+int
+main()
+{
+  test01();
+  test02();
+}
diff --git a/libstdc++-v3/testsuite/27_io/filesystem/path/generic/wchar_t.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/path/generic/wchar_t.cc
new file mode 100644
index 000..5dacedc7de4
--- /dev/null
+++ 

Update gcc_release for move to git

[Joseph Myers]

This patch updates the gcc_release script, used for snapshots and
releases, to use git instead of SVN.

The parts of the changes used in building snapshots have been tested.
The parts used for building releases have not, so it's likely further
fixes may turn out to be needed there when releases are first built
from git.

Committed.

2020-01-13  Joseph Myers  

* gcc_release: Use git instead of SVN.
* crontab: Update gcc_release calls.

diff --git a/maintainer-scripts/crontab b/maintainer-scripts/crontab
index f064d6fb45e..0cf342fdf3a 100644
--- a/maintainer-scripts/crontab
+++ b/maintainer-scripts/crontab
@@ -1,6 +1,6 @@
 16  0 * * * sh /home/gccadmin/scripts/update_version_git
 50  0 * * * sh /home/gccadmin/scripts/update_web_docs_svn
 55  0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
-32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 8:branches/gcc-8-branch 
-l -d /sourceware/snapshot-tmp/gcc all
-32 22 * * 6 sh /home/gccadmin/scripts/gcc_release -s 9:branches/gcc-9-branch 
-l -d /sourceware/snapshot-tmp/gcc all
-32 22 * * 7 sh /home/gccadmin/scripts/gcc_release -s 10:trunk -l -d 
/sourceware/snapshot-tmp/gcc all
+32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 8:releases/gcc-8 -l -d 
/sourceware/snapshot-tmp/gcc all
+32 22 * * 6 sh /home/gccadmin/scripts/gcc_release -s 9:releases/gcc-9 -l -d 
/sourceware/snapshot-tmp/gcc all
+32 22 * * 7 sh /home/gccadmin/scripts/gcc_release -s 10:master -l -d 
/sourceware/snapshot-tmp/gcc all
diff --git a/maintainer-scripts/gcc_release b/maintainer-scripts/gcc_release
index 10da704f95f..8be870154f7 100755
--- a/maintainer-scripts/gcc_release
+++ b/maintainer-scripts/gcc_release
@@ -64,19 +64,19 @@ inform() {
 usage() {
 cat < BASE-VER) || \
error "Could not update BASE-VER"
-   svnciargs="${svnciargs} gcc/BASE-VER"
+   commit_files="${commit_files} gcc/BASE-VER"
   else
error "Release number ${RELEASE} does not immediately follow BASE-VER"
   fi
@@ -177,16 +178,15 @@ EOF
 (changedir ${SOURCE_DIRECTORY}/gcc && \
  : > DEV-PHASE) || \
 error "Could not update DEV-PHASE"
-svnciargs="${svnciargs} gcc/DEV-PHASE"
+commit_files="${commit_files} gcc/DEV-PHASE"
 
 (changedir ${SOURCE_DIRECTORY} && \
- ${SVN} -q ci -m 'Update ChangeLog and version files for release' 
${svnciargs}) || \
+ ${GIT} commit -q -m 'Update ChangeLog and version files for release' 
${commit_files} && \
+ ${GIT} push) || \
 error "Could not commit ChangeLog and version file updates"
 
 # Make sure we tag the sources for a final release.
-TAG="tags/gcc_`echo ${RELEASE} | tr . _`_release"
-
-rm -rf ${SOURCE_DIRECTORY}
+TAG="releases/gcc-${RELEASE}"
   fi
 
   # Tag the sources.
@@ -195,30 +195,43 @@ EOF
 # We don't want to overwrite an existing tag.  So, if the tag
 # already exists, issue an error message; the release manager can
 # manually remove the tag if appropriate.
-echo "${SVN} ls ${SVNROOT}/${TAG}/ChangeLog" 
-if ${SVN} ls "${SVNROOT}/${TAG}/ChangeLog"; then 
+if (changedir ${SOURCE_DIRECTORY} && \
+   ${GIT} rev-parse "refs/tags/${TAG}" > /dev/null 2>&1); then
   error "Tag ${TAG} already exists"
 fi
-${SVN} -m "Tagging source as ${TAG}" cp "${SVNROOT}/${SVNBRANCH}" 
"${SVNROOT}/${TAG}" || \
+(changedir ${SOURCE_DIRECTORY} && \
+ ${GIT} tag -s -m "GCC ${RELEASE} release" "${TAG}" && \
+ ${GIT} push origin tag "${TAG}") || \
   error "Could not tag sources"
-SVNBRANCH=${TAG}
+GITBRANCH=${TAG}
   fi
-  SVNREV=`${SVN} info "${SVNROOT}/${SVNBRANCH}"|awk '/Revision:/ {print $2}'`
 
-  # Export the current sources.
-  inform "Retrieving sources (svn export -r ${SVNREV} ${SVNROOT}/${SVNBRANCH})"
+  GITREV=`cd ${SOURCE_DIRECTORY} && ${GIT} rev-parse HEAD`
+  inform "Sources are commit ${GITREV}"
+
+  # Make sure there are no uncommitted changes in the sources.
+  status=${WORKING_DIRECTORY}/gitstatus.$$
+  (changedir ${SOURCE_DIRECTORY} && \
+   ${GIT} status --porcelain --ignored > "$status") || \
+error "Could not get source directory status"
+  if [ -s "$status" ]; then
+cat "$status"
+error "Source directory has unexpected changes"
+  fi
+  rm "$status"
 
-  ${SVN} -q export -r${SVNREV} "${SVNROOT}/${SVNBRANCH}" "`basename 
${SOURCE_DIRECTORY}`" ||\
-error "Could not retrieve sources"
+  # Remove .git from the sources.
+  rm -rf "${SOURCE_DIRECTORY}/.git" || \
+error "Could not remove .git from sources"
 
   # Run gcc_update on them to set up the timestamps nicely, and (re)write
-  # the LAST_UPDATED file containing the SVN tag/revision used.
+  # the LAST_UPDATED file containing the git tag/revision used.
   changedir "gcc-${RELEASE}"
   contrib/gcc_update --touch
-  echo "Obtained from SVN: ${SVNBRANCH} revision ${SVNREV}" > LAST_UPDATED
+  echo "Obtained from git: ${GITBRANCH} revision ${GITREV}" > LAST_UPDATED
 
   # For a prerelease or real release, we need to generate additional
-  # 

Replace update_version_svn with update_version_git

[Joseph Myers]

This patch replaces the update_version_svn script, that updates the
DATESTAMP files from cron, with update_version_git.

Applied to mainline.  Note: I don't know why pushing a DATESTAMP
update from this script is slow (as noted at
) when it's fast
over git+ssh.  It's still slow even now sourceware is using git 2.24.1
and the repository is packed using delta islands.  Slowness does
increase the window where someone committing to a branch would
conflict with this script and result in a DATESTMP update not getting
pushed (since unlike in SVN, any commit to a branch conflicts with
pushing a DATESTAMP update on that branch, whereas in SVN only a
commit to the same file would conflict).  The script does repeat the
pull immediately before updating DATESTAMP on each branch to reduce
that window.

2020-01-13  Joseph Myers  

* update_version_git: New file.
* update_version:svn: Remove.
* crontab: Use update_version_git.

diff --git a/maintainer-scripts/crontab b/maintainer-scripts/crontab
index 80a4a4845d5..f064d6fb45e 100644
--- a/maintainer-scripts/crontab
+++ b/maintainer-scripts/crontab
@@ -1,4 +1,4 @@
-16  0 * * * sh /home/gccadmin/scripts/update_version_svn
+16  0 * * * sh /home/gccadmin/scripts/update_version_git
 50  0 * * * sh /home/gccadmin/scripts/update_web_docs_svn
 55  0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
 32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 8:branches/gcc-8-branch 
-l -d /sourceware/snapshot-tmp/gcc all
diff --git a/maintainer-scripts/update_version_git 
b/maintainer-scripts/update_version_git
new file mode 100755
index 000..b1b5f4c9cf9
--- /dev/null
+++ b/maintainer-scripts/update_version_git
@@ -0,0 +1,85 @@
+#!/bin/sh
+#
+# Update the current version date in all files in the tree containing
+# it.  Consider all single-component-version release branches except
+# those matching the regular expression in $IGNORE_BRANCHES, and also
+# consider those branches listed in the space separated list in
+# $ADD_BRANCHES.
+
+GITROOT=${GITROOT:-"/git/gcc.git"}
+IGNORE_BRANCHES='releases/gcc-(.*\..*|5|6|7)'
+ADD_BRANCHES='master'
+
+# Run this from /tmp.
+export GITROOT
+BASEDIR=/tmp/$$
+/bin/rm -rf "$BASEDIR"
+/bin/mkdir "$BASEDIR"
+cd "$BASEDIR"
+
+GIT=${GIT:-/usr/local/bin/git}
+
+# Compute the branches which we should update.
+BRANCHES=`(cd $GITROOT \
+  && ${GIT} for-each-ref --format='%(refname)' \
+'refs/heads/releases/gcc-*') \
+ | sed -e 's/refs\/heads\///' \
+  | egrep -v $IGNORE_BRANCHES`
+# Always update the mainline.
+BRANCHES="${ADD_BRANCHES} ${BRANCHES}"
+
+# This is put into the datestamp files.
+CURR_DATE=`/bin/date +"%Y%m%d"`
+
+datestamp_FILES="gcc/DATESTAMP"
+
+
+# Assume all will go well.
+RESULT=0
+SUBDIR=$BASEDIR/gcc
+for BRANCH in $BRANCHES; do
+  echo "Working on \"$BRANCH\"."
+  # Check out the files on the branch.
+  if [ -d "$SUBDIR" ]; then
+cd "$SUBDIR"
+${GIT} pull -q
+${GIT} checkout -q "$BRANCH"
+  else
+${GIT} clone -q -b "$BRANCH" "$GITROOT" "$SUBDIR"
+  fi
+
+  # There are no files to commit yet.
+  COMMIT_FILES=""
+
+  cd "$SUBDIR"
+  for file in $datestamp_FILES; do
+if test -f $file; then
+  echo "${CURR_DATE}" > $file.new
+
+  if /usr/bin/cmp -s $file $file.new; then
+   rm -f $file.new
+  else
+   mv -f $file.new $file
+COMMIT_FILES="$COMMIT_FILES $file"
+  fi
+fi
+  done
+
+  if test -n "$COMMIT_FILES"; then
+for i in $COMMIT_FILES; do
+echo "Attempting to commit $i"
+if ${GIT} commit -m "Daily bump." $i; then
+  if ! ${GIT} push origin "$BRANCH"; then
+# If we could not push the files, indicate failure.
+RESULT=1
+  fi
+else
+  # If we could not commit the files, indicate failure.
+  RESULT=1
+fi
+done
+  fi
+done
+
+/bin/rm -rf $BASEDIR
+exit $RESULT
diff --git a/maintainer-scripts/update_version_svn 
b/maintainer-scripts/update_version_svn
deleted file mode 100755
index dfbaee6e44a..000
--- a/maintainer-scripts/update_version_svn
+++ /dev/null
@@ -1,85 +0,0 @@
-#!/bin/sh
-#
-# Update the current version date in all files in the tree containing
-# it.  Consider all release branches except those matching the regular
-# expression in $IGNORE_BRANCHES, and also consider those branches listed
-# in the space separated list in $ADD_BRANCHES.
-
-SVNROOT=${SVNROOT:-"file:///svn/gcc"}
-IGNORE_BRANCHES='gcc-(2_95|3_0|3_1|3_2|3_3|3_4|4_0|4_1|4_2|4_3|4_4|4_5|4_6|4_7|4_8|4_9|5|6|7)-branch'
-ADD_BRANCHES='HEAD'
-
-# Run this from /tmp.
-export SVNROOT
-/bin/rm -rf /tmp/$$
-/bin/mkdir /tmp/$$
-cd /tmp/$$
-
-SVN=${SVN:-/usr/bin/svn}
-
-# Compute the branches which we should update.
-BRANCHES=`$SVN ls $SVNROOT/branches \
- | sed -e 's/\///' \
-  | egrep 'gcc-[0-9]+(_[0-9]+)?-branch$' \
-  | egrep -v $IGNORE_BRANCHES`
-# Always update the mainline.
-BRANCHES="${BRANCHES} 

[PATCH] contrib: git descr/undescr aliases

[Jakub Jelinek]

On Fri, Jan 10, 2020 at 02:26:53PM +, Richard Earnshaw (lists) wrote:
> Updated to add better support for diff-ing .md files.

The following patch adds the descr/undescr aliases (for converting to
monotonically increasing revision numbers and back) there next to svn-rev.
Both have been changed to use basepoints/gcc-* tags instead of
branchpoints/gcc-*, the first one now supports --full option, where
$ git descr origin/master
r10-5835
$ git descr --full origin/master
r10-5835-g1fc15853e301337b46d7f1234966a6244ef0cdab
where the second form is what is used in gcc-cvs mail bodies and bugzilla
comments from commits, the former what is used in the subjects.
The second alias has been tweaked to use git config --get gcc-config.upstream
with fallback to origin to be able to deal with non-default upstream
configurations.

Ok for trunk once your changes are in (and once the basepoints are pushed
into the upstream repository)?

2020-01-13  Jakub Jelinek  

* contrib/gcc-git-customization: Add git descr and undescr aliases.

--- contrib/gcc-git-customization.jj2020-01-12 00:25:19.697684793 +0100
+++ contrib/gcc-git-customization   2020-01-13 12:27:33.154283245 +0100
@@ -20,6 +20,11 @@ ask () {
 # Add a git command to find the git commit equivalent to legacy SVN revision 
NNN
 git config alias.svn-rev '!f() { rev=$1; shift; git log --all 
--grep="From-SVN: r$rev\\b" "${@}"; } ; f'
 
+# Add git commands to convert git commit to monotonically increasing revision 
number
+# and vice versa
+git config alias.descr \!"f() { if test \${1:-no} = --full; then r=\$(git 
describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' \${2:-master} | sed 
-n 's,^tags/basepoints/gcc-,r,p'); expr match \${r:-no} '^r[0-9]\\+\$' 
>/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master}); test -n \$r && echo 
\${r}; else git describe --all --match 'basepoints/gcc-[0-9]*' \${1:-master} | 
sed -n 
's,^tags/basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\1-\\2,p;s,^tags/basepoints/gcc-\\([0-9]\\+\\)\$,r\\1-0,p';
 fi; }; f"
+git config alias.undescr \!"f() { o=\$(git config --get gcc-config.upstream); 
r=\$(echo \$1 | sed -n 's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | 
sed -n 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id 
\$1 && exit 1; h=\$(git rev-parse --verify --quiet 
\${o:-origin}/releases/gcc-\$r); test -z \$h && h=\$(git rev-parse --verify 
--quiet \${o:-origin}/master); p=\$(git describe --all --match 
'basepoints/gcc-'\$r \$h | sed -n 
's,^tags/basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\1,p;s,^tags/basepoints/gcc-[0-9]\\+\$,0,p');
 git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
+
 # Make diff on MD files uses "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
 # *.mddiff=md


Jakub

[PATCH][AArch64] Enable CLI for Armv8.6-A f64mm

[Matthew Malcomson]

This patch is necessary for sve-ld1ro intrinsic I posted in
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00466.html .

I had mistakenly thought this option was already enabled upstream.

This provides the option +f64mm, that turns on the 64 bit floating point
matrix multiply extension.  This extension is only available for
AArch64.  Turning on this extension also turns on the SVE extension.

This extension is optional and only available at Armv8.2-A and onward.

We also add the ACLE defined macro for this extension.

Tested on aarch64 cross compiler from x86.

gcc/ChangeLog:

2020-01-13  Matthew Malcomson  

* config/aarch64/aarch64-c.c (_ARM_FEATURE_MATMUL_FLOAT64):
Introduce this ACLE specified predefined macro.
* config/aarch64/aarch64-option-extensions.def (f64mm): New.
(fp): Disabling this disables f64mm.
(simd): Disabling this disables f64mm.
(fp16): Disabling this disables f64mm.
(sve): Disabling this disables f64mm.
* config/aarch64/aarch64.h (AARCH64_FL_F64MM): New.
(AARCH64_ISA_F64MM): New.
(TARGET_F64MM): New.
* doc/invoke.texi (f64mm): Document new option.

gcc/testsuite/ChangeLog:

2020-01-13  Matthew Malcomson  

* gcc.target/aarch64/pragma_cpp_predefs_2.c: Check for f64mm
predef.



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


diff --git a/gcc/config/aarch64/aarch64-c.c b/gcc/config/aarch64/aarch64-c.c
index 
9ccca422b045fcd6875f192680220b2af9d59d31..22fc4a5e337acb4cdd96618b57736f55892bd0e7
 100644
--- a/gcc/config/aarch64/aarch64-c.c
+++ b/gcc/config/aarch64/aarch64-c.c
@@ -166,6 +166,7 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
   aarch64_def_or_undef (TARGET_MEMTAG, "__ARM_FEATURE_MEMORY_TAGGING", pfile);
 
   aarch64_def_or_undef (TARGET_I8MM, "__ARM_FEATURE_MATMUL_INT8", pfile);
+  aarch64_def_or_undef (TARGET_F64MM, "__ARM_FEATURE_MATMUL_FP64", pfile);
   aarch64_def_or_undef (TARGET_BF16_SIMD,
"__ARM_FEATURE_BF16_VECTOR_ARITHMETIC", pfile);
   aarch64_def_or_undef (TARGET_BF16_FP,
diff --git a/gcc/config/aarch64/aarch64-option-extensions.def 
b/gcc/config/aarch64/aarch64-option-extensions.def
index 
5022a1b3552f35364e35b3955bf2c39a33ab0752..6057b33033a0f3a8be7d656dc1e459d4d93b2842
 100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -53,26 +53,26 @@
 /* Enabling "fp" just enables "fp".
Disabling "fp" also disables "simd", "crypto", "fp16", "aes", "sha2",
"sha3", sm3/sm4, "sve", "sve2", "sve2-aes", "sve2-sha3", "sve2-sm4",
-   "sve2-bitperm", "i8mm" and "bf16".  */
+   "sve2-bitperm", "i8mm", "f64mm", and "bf16".  */
 AARCH64_OPT_EXTENSION("fp", AARCH64_FL_FP, 0, AARCH64_FL_SIMD | \
  AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | \
  AARCH64_FL_SHA2 | AARCH64_FL_SHA3 | AARCH64_FL_SM4 | \
  AARCH64_FL_SVE | AARCH64_FL_SVE2 | AARCH64_FL_SVE2_AES | \
  AARCH64_FL_SVE2_SHA3 | AARCH64_FL_SVE2_SM4 | \
  AARCH64_FL_SVE2_BITPERM | AARCH64_FL_I8MM | \
- AARCH64_FL_BF16, false, "fp")
+ AARCH64_FL_F64MM | AARCH64_FL_BF16, false, "fp")
 
 /* Enabling "simd" also enables "fp".
Disabling "simd" also disables "crypto", "dotprod", "aes", "sha2", "sha3",
"sm3/sm4", "sve", "sve2", "sve2-aes", "sve2-sha3", "sve2-sm4",
-   "sve2-bitperm", and "i8mm".  */
+   "sve2-bitperm", "i8mm", and "f64mm".  */
 AARCH64_OPT_EXTENSION("simd", AARCH64_FL_SIMD, AARCH64_FL_FP, \
  AARCH64_FL_CRYPTO | AARCH64_FL_DOTPROD | \
  AARCH64_FL_AES | AARCH64_FL_SHA2 | AARCH64_FL_SHA3 | \
  AARCH64_FL_SM4 | AARCH64_FL_SVE | AARCH64_FL_SVE2 | \
  AARCH64_FL_SVE2_AES | AARCH64_FL_SVE2_SHA3 | \
  AARCH64_FL_SVE2_SM4 | AARCH64_FL_SVE2_BITPERM | \
- AARCH64_FL_I8MM, false, \
+ AARCH64_FL_I8MM | AARCH64_FL_F64MM, false, \
  "asimd")
 
 /* Enabling "crypto" also enables "fp", "simd", "aes" and "sha2".
@@ -92,12 +92,13 @@ AARCH64_OPT_EXTENSION("crc", AARCH64_FL_CRC, 0, 0, false, 
"crc32")
 AARCH64_OPT_EXTENSION("lse", AARCH64_FL_LSE, 0, 0, false, "atomics")
 
 /* Enabling "fp16" also enables "fp".
-   Disabling "fp16" disables "fp16", "fp16fml", "sve", "sve2", "sve2-aes",
-   "sve2-sha3", "sve2-sm4", and "bitperm".  */
+   Disabling "fp16" disables "fp16", "fp16fml", "sve", "f64mm", "sve2",
+   "sve2-aes", "sve2-sha3", "sve2-sm4", and "bitperm".  */
 AARCH64_OPT_EXTENSION("fp16", AARCH64_FL_F16, AARCH64_FL_FP, \
- AARCH64_FL_F16FML | AARCH64_FL_SVE | AARCH64_FL_SVE2 | \
- AARCH64_FL_SVE2_AES | AARCH64_FL_SVE2_SHA3 | \
- AARCH64_FL_SVE2_SM4 | AARCH64_FL_SVE2_BITPERM, false, \
+ AARCH64_FL_F16FML | 

Re: [PATCH 6/X] [libsanitizer] Add hwasan pass and associated gimple changes

[Matthew Malcomson]

> On 12/12/19 4:19 PM, Matthew Malcomson wrote:
>> - if (is_store && !param_asan_instrument_writes)
>> + if (is_store
>> + && (!param_asan_instrument_writes || !param_hwasan_instrument_writes))
>> return;
>> - if (!is_store && !param_asan_instrument_reads)
>> + if (!is_store
>> + && (!param_asan_instrument_reads || !param_hwasan_instrument_reads))
>> return;
> 
> I know it's very unlikely, but one can use -fsanitize=address and
> --param hwasan-instrument-reads=0 which will drop instrumentation of reads
> for ASAN.

Ah! Thanks for the catch.
Updated patch is attached and has been tested.

I've also attached the patch including the new `Optimization` keyword to the
hwasan parameters to this email -- (putting both on this email to avoid a bit of
email spam).

> 
> Similarly for other parameters.
> 
> Martin


Inlining the new bit that avoids the problem you pointed out above, since
the implementation of that is the only new part someone might object to.


###

diff --git a/gcc/asan.c b/gcc/asan.c
index 
fe6841b4f084f75be534cc9653079ca0a5bdc94e..55723bf4d5d2a4111eb574d169f21332f6eb33ff
 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -326,6 +326,25 @@ asan_sanitize_allocas_p (void)
   return (asan_sanitize_stack_p () && param_asan_protect_allocas);
 }
 
+bool
+asan_instrument_reads (void)
+{
+  return (sanitize_flags_p (SANITIZE_ADDRESS) && param_asan_instrument_reads);
+}
+
+bool
+asan_instrument_writes (void)
+{
+  return (sanitize_flags_p (SANITIZE_ADDRESS) && param_asan_instrument_writes);
+}
+
+bool
+asan_memintrin (void)
+{
+  return (sanitize_flags_p (SANITIZE_ADDRESS) && param_asan_memintrin);
+}
+
+
 /* Checks whether section SEC should be sanitized.  */
 
 static bool
@@ -1382,6 +1673,28 @@ hwasan_sanitize_allocas_p (void)
   return (hwasan_sanitize_stack_p () && param_hwasan_protect_allocas);
 }
 
+/* Should we instrument reads?  */
+bool
+hwasan_instrument_reads (void)
+{
+  return (hwasan_sanitize_p () && param_hwasan_instrument_reads);
+}
+
+/* Should we instrument writes?  */
+bool
+hwasan_instrument_writes (void)
+{
+  return (hwasan_sanitize_p () && param_hwasan_instrument_writes);
+}
+
+/* Should we instrument builtin calls?  */
+bool
+hwasan_memintrin (void)
+{
+  return (hwasan_sanitize_p () && param_hwasan_memintrin);
+}
+
+
 /* Insert code to protect stack vars.  The prologue sequence should be emitted
directly, epilogue sequence returned.  BASE is the register holding the
stack base, against which OFFSETS array offsets are relative to, OFFSETS
@@ -2220,9 +2539,9 @@ static void
 instrument_derefs (gimple_stmt_iterator *iter, tree t,
   location_t location, bool is_store)
 {
-  if (is_store && !param_asan_instrument_writes)
+  if (is_store && !(asan_instrument_writes () || hwasan_instrument_writes ()))
 return;
-  if (!is_store && !param_asan_instrument_reads)
+  if (!is_store && !(asan_instrument_reads () || hwasan_instrument_reads ()))
 return;
 
   tree type, base;
@@ -2376,7 +2696,7 @@ instrument_mem_region_access (tree base, tree len,
 static bool
 instrument_builtin_call (gimple_stmt_iterator *iter)
 {
-  if (!param_asan_memintrin)
+  if (!(asan_memintrin () || hwasan_memintrin ()))
 return false;
 
   bool iter_advanced_p = false;

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 
77649e839c968c38485ea30d332576b9b089effe..c5746e3c89283ef0652de85cf6b94e76263aba38
 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -54,6 +54,8 @@ static tree handle_cold_attribute (tree *, tree, tree, int, 
bool *);
 static tree handle_no_sanitize_attribute (tree *, tree, tree, int, bool *);
 static tree handle_no_sanitize_address_attribute (tree *, tree, tree,
  int, bool *);
+static tree handle_no_sanitize_hwaddress_attribute (tree *, tree, tree,
+   int, bool *);
 static tree handle_no_sanitize_thread_attribute (tree *, tree, tree,
 int, bool *);
 static tree handle_no_address_safety_analysis_attribute (tree *, tree, tree,
@@ -412,6 +414,8 @@ const struct attribute_spec c_common_attribute_table[] =
  handle_no_sanitize_attribute, NULL },
   { "no_sanitize_address",0, 0, true, false, false, false,
  handle_no_sanitize_address_attribute, NULL },
+  { "no_sanitize_hwaddress",0, 0, true, false, false, false,
+ handle_no_sanitize_hwaddress_attribute, NULL },
   { "no_sanitize_thread", 0, 0, true, false, false, false,
  handle_no_sanitize_thread_attribute, NULL },
   { "no_sanitize_undefined",  0, 0, true, false, false, false,
@@ -946,6 +950,22 @@ handle_no_sanitize_address_attribute (tree *node, tree 
name, tree, int,
   return NULL_TREE;
 }
 
+/* Handle a "no_sanitize_hwaddress" attribute; 

Re: [C++ PATCH RFC] PR c++/80265 - constexpr __builtin_mem*.

[Jonathan Wakely]

On 11/01/20 00:03 -0500, Jason Merrill wrote:

The library has already worked around this issue, but I was curious about
why it wasn't working.  The answer: because we were passing  to fold,
which doesn't know about the constexpr values hash table.  Fixed by passing
&"str" instead.

Tested x86_64-pc-linux-gnu.  Does this seem useful even though it isn't
necessary anymore?


I'd still like to be able to use memcpy and memmove in constexpr
evaluation. We've added our own "std::__memmove" for use at compile
time, but it doesn't really have the same semantics. We could fix
that, but it would be better to just use the real thing.

Re: [PATCH 4/4] Make total scalarization also copy padding (PR 92486)

[Martin Jambor]

One more thing...

On Mon, Jan 13 2020, Martin Jambor wrote:
> Hi,
>
> On Tue, Jan 07 2020, Richard Biener wrote:
>> On Tue, 17 Dec 2019, Martin Jambor wrote:
>>
>>> Hi,
>>> 
>>> PR 92486 shows that DSE, when seeing a "normal" gimple aggregate
>>> assignment coming from a C struct assignment and one a representing a
>>> folded memcpy, can kill the latter and keep in place only the former,
>>> which does not copy padding - at least when SRA decides to totally
>>> scalarize a least one of the aggregates (when not doing total
>>> scalarization, SRA cares about padding)
>>> 
>>> Mind you, SRA would not totally scalarize an aggregate if it saw that
>>> it takes part in a gimple assignment which is a folded memcpy (see how
>>> type_changing_p is set in contains_vce_or_bfcref_p) but it doesn't
>>> because of the DSE decisions.
>>> 
>>> I was asked to modify SRA to take padding into account - and to copy
>>> it around - when totally scalarizing, which is what the patch below
>>> does.
>>> 
>>> I believe the patch is correct in the sense that it will not cause
>>> miscompilations but after I have seen inlining propagate the useless
>>> (and small and ugly and certainly damaging) accesses far and wide, I
>>> am more convinced that before that this is not the correct approach
>>> and DSE should simple be able to discern between the two assignment
>>> too - and that the semantics of a "normal" gimple assignments should
>>> not include copying of padding.
>>> 
>>> But if the decision will be to make gimple aggregate always a solid
>>> block copy, the patch can do it, and has passed bootstrap and testing
>>> on x86_64-linux and a very similar one on aarch64-linux and
>>> i686-linux.  I suppose that at least the way how it figures out the
>>> type for copying will need change, but even then I'd rather not commit
>>> it.
>>
>> I think both GENERIC and GIMPLE always had assignments being
>> block-copies.  I know we've changed memcpy folding to be more
>> explicit recently to avoid this very same issue but clearly
>> having a GIMPLE stmt like
>>
>>  *p = *q;
>>
>> decomposing into loads/stores of multiple discontiguous memory
>> ranges looks very wrong and would be quite awkward to correctly
>> represent throughout the compiler (and the alias infrastructure).
>
> Well, OK.  I suppose that's another reason for me to start thinking how
> to kill total scalarization.
>
>>
>> So even if the C standard says for aggregates the elements are
>> copied and contents of padding is unspecified the actual GIMPLE
>> primitive should always copy everything unless we can prove the
>> padding is not used.  The frontends could always choose to
>> make not copying the padding explicit (but usually copying it
>> _is_ more efficient unless you add artificial very large one).
>>
>> From an SRA analysis perspective I wonder if you can produce a
>> fix that doesn't depend on the earlier patches in this series?
>> It might be as "simple" as, in completely_scalarize, for
>> FIELD_DECLs with following padding to artificially enlarge
>> the field (I wonder if we can do w/o the 'ref' arg to
>> scalarize_elem for that - we'd build a MEM_REF then?).
>
> Such access would automatically conflict with any real access to the
> field, which would have to be reconciled throughout the pass.  Perhaps
> most importantly, we would have to load/store all of it when replacing a
> scalar copy but create a BIT_FIELD_REF into the replacement when
> replacing a pre-existing access to the field.  But I guess I can give it
> a go.
>
> In any case, unless one can somehow tell just by looking at FILED_DECL
> that it has padding (as opposed to figuring out that the next one simply
> starts later because the next one might not be in the same struct type),
> detecting the situation is actually much easier on top of the other
> patches in the series.
>
> And just to save myself work, unless you outright reject the previous
> two patches, I'd prefer not to attempt this independently.
>

...doing this will make me change the most radical patch in the series
to track pointer to the previous encountered/created access (as opposed
to the pointer to its next pointer) which should however make it more
readable (by getting rid of the triple indirections).

I'll try to come up with a new series quickly (but I'm juggling a few
high-priority tasks at the moment).

Thanks,

Martin

> Thanks,
>
> Martin
>
>>> 2019-12-13  Martin Jambor  
>>> 
>>> PR tree-optimization/92486
>>> * tree-sra.c: Include langhooks.h.
>>> (total_scalarization_fill_padding): New function.
>>> (total_skip_all_accesses_until_pos): Also create accesses for padding.
>>> (total_should_skip_creating_access): Pass new parameters to
>>> total_skip_all_accesses_until_pos, update how much area is already
>>> covered in cases of success.
>>> (totally_scalarize_subtree): Track how much of an aggregate is
>>> covered, create accesses for trailing padding.

Re: [PATCH 4/4] Make total scalarization also copy padding (PR 92486)

[Martin Jambor]

Hi,

On Tue, Jan 07 2020, Richard Biener wrote:
> On Tue, 17 Dec 2019, Martin Jambor wrote:
>
>> Hi,
>> 
>> PR 92486 shows that DSE, when seeing a "normal" gimple aggregate
>> assignment coming from a C struct assignment and one a representing a
>> folded memcpy, can kill the latter and keep in place only the former,
>> which does not copy padding - at least when SRA decides to totally
>> scalarize a least one of the aggregates (when not doing total
>> scalarization, SRA cares about padding)
>> 
>> Mind you, SRA would not totally scalarize an aggregate if it saw that
>> it takes part in a gimple assignment which is a folded memcpy (see how
>> type_changing_p is set in contains_vce_or_bfcref_p) but it doesn't
>> because of the DSE decisions.
>> 
>> I was asked to modify SRA to take padding into account - and to copy
>> it around - when totally scalarizing, which is what the patch below
>> does.
>> 
>> I believe the patch is correct in the sense that it will not cause
>> miscompilations but after I have seen inlining propagate the useless
>> (and small and ugly and certainly damaging) accesses far and wide, I
>> am more convinced that before that this is not the correct approach
>> and DSE should simple be able to discern between the two assignment
>> too - and that the semantics of a "normal" gimple assignments should
>> not include copying of padding.
>> 
>> But if the decision will be to make gimple aggregate always a solid
>> block copy, the patch can do it, and has passed bootstrap and testing
>> on x86_64-linux and a very similar one on aarch64-linux and
>> i686-linux.  I suppose that at least the way how it figures out the
>> type for copying will need change, but even then I'd rather not commit
>> it.
>
> I think both GENERIC and GIMPLE always had assignments being
> block-copies.  I know we've changed memcpy folding to be more
> explicit recently to avoid this very same issue but clearly
> having a GIMPLE stmt like
>
>  *p = *q;
>
> decomposing into loads/stores of multiple discontiguous memory
> ranges looks very wrong and would be quite awkward to correctly
> represent throughout the compiler (and the alias infrastructure).

Well, OK.  I suppose that's another reason for me to start thinking how
to kill total scalarization.

>
> So even if the C standard says for aggregates the elements are
> copied and contents of padding is unspecified the actual GIMPLE
> primitive should always copy everything unless we can prove the
> padding is not used.  The frontends could always choose to
> make not copying the padding explicit (but usually copying it
> _is_ more efficient unless you add artificial very large one).
>
> From an SRA analysis perspective I wonder if you can produce a
> fix that doesn't depend on the earlier patches in this series?
> It might be as "simple" as, in completely_scalarize, for
> FIELD_DECLs with following padding to artificially enlarge
> the field (I wonder if we can do w/o the 'ref' arg to
> scalarize_elem for that - we'd build a MEM_REF then?).

Such access would automatically conflict with any real access to the
field, which would have to be reconciled throughout the pass.  Perhaps
most importantly, we would have to load/store all of it when replacing a
scalar copy but create a BIT_FIELD_REF into the replacement when
replacing a pre-existing access to the field.  But I guess I can give it
a go.

In any case, unless one can somehow tell just by looking at FILED_DECL
that it has padding (as opposed to figuring out that the next one simply
starts later because the next one might not be in the same struct type),
detecting the situation is actually much easier on top of the other
patches in the series.

And just to save myself work, unless you outright reject the previous
two patches, I'd prefer not to attempt this independently.

Thanks,

Martin

>> 2019-12-13  Martin Jambor  
>> 
>>  PR tree-optimization/92486
>>  * tree-sra.c: Include langhooks.h.
>>  (total_scalarization_fill_padding): New function.
>>  (total_skip_all_accesses_until_pos): Also create accesses for padding.
>>  (total_should_skip_creating_access): Pass new parameters to
>>  total_skip_all_accesses_until_pos, update how much area is already
>>  covered in cases of success.
>>  (totally_scalarize_subtree): Track how much of an aggregate is
>>  covered, create accesses for trailing padding.

Re: Fix type mismatch in SLPed constructors

[Richard Biener]

On Fri, Jan 10, 2020 at 4:04 PM Richard Sandiford
 wrote:
>
> Having the "same" vector types with different modes means that we can
> end up vectorising a constructor with a different mode from the lhs.
> This patch adds a VIEW_CONVERT_EXPR in that case.
>
> This showed up on existing tests when testing with fixed-length
> -msve-vector-bits=128.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

OK.

Richard.

> Richard
>
>
> 2020-01-10  Richard Sandiford  
>
> gcc/
> * tree-vect-slp.c (vectorize_slp_instance_root_stmt): Use a
> VIEW_CONVERT_EXPR if the vectorized constructor has a diffeent
> type from the lhs.
>
> Index: gcc/tree-vect-slp.c
> ===
> --- gcc/tree-vect-slp.c 2020-01-06 17:59:49.126752227 +
> +++ gcc/tree-vect-slp.c 2020-01-10 15:01:13.780190287 +
> @@ -4306,6 +4306,10 @@ vectorize_slp_instance_root_stmt (slp_tr
> {
>   tree vect_lhs = gimple_get_lhs (child_stmt_info->stmt);
>   tree root_lhs = gimple_get_lhs (instance->root_stmt->stmt);
> + if (!useless_type_conversion_p (TREE_TYPE (root_lhs),
> + TREE_TYPE (vect_lhs)))
> +   vect_lhs = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (root_lhs),
> +  vect_lhs);
>   rstmt = gimple_build_assign (root_lhs, vect_lhs);
>   break;
> }

Re: [PATCH] Make warn_inline Optimization option.

[Richard Biener]

On Mon, Jan 13, 2020 at 9:47 AM Martin Liška  wrote:
>
> Hi.
>
> I've got a patch that restores --help=optimize to what we had for GCC 9.
> That means it will not print parameters (and the warn_inline warning).
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

OK.

Richard.

> Thanks,
> Martin

Re: [PATCH] Fix typo and avoid possible memory leak

[Richard Sandiford]

"Kewen.Lin"  writes:
> Hi,
>
> Function average_num_loop_insns forgets to free loop body in early return.  
> Besides, overflow comparison checks 100 (e6) but the return value is
> 10 (e5), I guess it's unexpected, a typo?
>
> Bootstrapped and regress tested on powerpc64le-linux-gnu.  
> I guess this should go to GCC11? Is it ok?

OK for GCC 10, thanks.  This is a regression from GCC 7.

Richard

>
> BR,
> Kewen
>
> gcc/ChangeLog
>
> 2020-01-13  Kewen Lin  
>
>   * cfgloopanal.c (average_num_loop_insns): Free bbs when early return,
>   fix typo on return value.
>
>  
>
> diff --git a/gcc/cfgloopanal.c b/gcc/cfgloopanal.c
> index 199c20b..65d239a 100644
> --- a/gcc/cfgloopanal.c
> +++ b/gcc/cfgloopanal.c
> @@ -219,7 +219,10 @@ average_num_loop_insns (const class loop *loop)
>ninsns += (sreal)binsns * bb->count.to_sreal_scale 
> (loop->header->count);
>/* Avoid overflows.   */
>if (ninsns > 100)
> - return 10;
> + {
> +   free (bbs);
> +   return 100;
> + }
>  }
>free (bbs);

Re: [GCC][PATCH][ARM] Add Bfloat16_t scalar type, vector types and machine modes to ARM back-end [2/2]

[Kyrill Tkachov]

Hi Stam,

On 1/10/20 6:47 PM, Stam Markianos-Wright wrote:

Hi all,

This patch is part 2 of Bfloat16_t enablement in the ARM back-end.

This new type is constrained using target hooks TARGET_INVALID_CONVERSION,
TARGET_INVALID_UNARY_OP, TARGET_INVALID_BINARY_OP so that it may only 
be used

through ACLE intrinsics (will be provided in later patches).

Regression testing on arm-none-eabi passed successfully.

Ok for trunk?



Ok.

Thanks,

Kyrill




Cheers,
Stam


ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest

Details on ARM Bfloat can be found here:
https://community.arm.com/developer/ip-products/processors/b/ml-ip-blog/posts/bfloat16-processing-for-neural-networks-on-armv8_2d00_a 





gcc/ChangeLog:

2020-01-10  Stam Markianos-Wright 

    * config/arm/arm.c
    (arm_invalid_conversion): New function for target hook.
    (arm_invalid_unary_op): New function for target hook.
    (arm_invalid_binary_op): New function for target hook.

2020-01-10  Stam Markianos-Wright 

    * gcc.target/arm/bfloat16_scalar_typecheck.c: New test.
    * gcc.target/arm/bfloat16_vector_typecheck_1.c: New test.
    * gcc.target/arm/bfloat16_vector_typecheck_2.c: New test.

Re: Document --with-build-config=bootstrap-asan option.

[Matthew Malcomson]

On 11/01/2020 07:19, Gerald Pfeifer wrote:
> On Thu, 12 Dec 2019, Matthew Malcomson wrote:
>> gcc/ChangeLog:
>>
>> 2019-12-12  Matthew Malcomson  
>>
>>  * doc/install.texi: Document bootstrap-asan configuration option.
> 
> I see this introduces a new table.
> 
>> +Some examples of build configurations designed for developers of GCC are:
> 
> @samp{bootstrap-time}, @samp{bootstrap-debug-ckovw} and others appear
> to fall into the same camp, essentially expected to be used by maintainers
> only.
> 
> Would it make sense to add your new option to the existing table, or
> perhaps see which other options from the existing table to move into
> your new one?  Thoughts?

Sounds good me.


> 
> 
> The patch is okay modulo the question above.
> 
> Thanks,
> Gerald
> 

Patch with above suggestion.

#

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 
80b47812fe66a8ef50edf3aad9708ab3409ba7dc..0705759c69f64c6d06e91f7ae83bb8c1ad210f34
 
100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -2668,6 +2668,10 @@ Arranges for the run time of each program started 
by the GCC driver,
  built in any stage, to be logged to @file{time.log}, in the top level of
  the build tree.

+@item @samp{bootstrap-asan}
+Compiles GCC itself using Address Sanitization in order to catch 
invalid memory
+accesses within the GCC code.
+
  @end table

  @section Building a cross compiler

Re: [PATCH] Further bootstrap unbreak (was Re: [PATCH] PR90838: Support ctz idioms)

[Wilco Dijkstra]

Hi Jakub,

On Sat, Jan 11, 2020 at 05:30:52PM +0100, Jakub Jelinek wrote:
> On Sat, Jan 11, 2020 at 05:24:19PM +0100, Andreas Schwab wrote:
> > ../../gcc/tree-ssa-forwprop.c: In function 'bool 
> > simplify_count_trailing_zeroes(gimple_stmt_iterator*)':
> > ../../gcc/tree-ssa-forwprop.c:1925:23: error: variable 'mode' set but not 
> > used [-Werror=unused-but-set-variable]
> >  1925 |   scalar_int_mode mode = SCALAR_INT_TYPE_MODE (type);
> >   |   ^~~~
> 
> Oops, then I think we need following, but can't commit it until Monday.

Thanks for sorting this out so quickly, Jakub! It looks like we need to convert 
these macros
to targetm hooks given it's too difficult to get them to compile without 
warnings/errors...
That would also allow us to fix the odd interface of CTZ_DEFINED_VALUE_AT_ZERO
and remove the 1 vs 2 distinction.

Cheers,
Wilco

Re: [RFA (gimplify) PATCH] PR c++/33799 - destroy return value if local cleanup throws.

[Richard Biener]

On Sat, Jan 11, 2020 at 6:13 AM Jason Merrill  wrote:
>
> This is a pretty rare situation since the C++11 change to make all
> destructors default to noexcept, but it is still possible to define throwing
> destructors, and if a destructor for a local variable throws during the
> return, we've already constructed the return value, so now we need to
> destroy it.  I handled this somewhat like the new-expression cleanup; as in
> that case, this cleanup can't properly nest with the cleanups for local
> variables, so I introduce a cleanup region around the whole function and a
> flag variable to indicate whether the return value actually needs to be
> destroyed.
>
> Setting the flag requires giving a COMPOUND_EXPR as the operand of a
> RETURN_EXPR.  Simply allowing that in gimplify_return_expr makes the most
> sense to me, is it OK for trunk?

It works for me.

Richard.

> This doesn't currently work with deduced return type because we don't know
> the type when we're deciding whether to introduce the cleanup region.
>
> Tested x86_64-pc-linux-gnu.
>
> gcc/
> * gimplify.c (gimplify_return_expr): Handle COMPOUND_EXPR.
> gcc/cp/
> * cp-tree.h (current_retval_sentinel): New macro.
> * decl.c (start_preparsed_function): Set up cleanup for retval.
> * typeck.c (check_return_expr): Set current_retval_sentinel.
> ---
>  gcc/cp/cp-tree.h  |  7 ++
>  gcc/cp/decl.c | 14 +++
>  gcc/cp/typeck.c   |  9 +++
>  gcc/gimplify.c|  8 +++
>  gcc/testsuite/g++.dg/eh/return1.C | 40 +++
>  5 files changed, 78 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/eh/return1.C
>
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index 98572bdbad1..c0f780df685 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -1952,6 +1952,13 @@ struct GTY(()) language_function {
>
>  #define current_vtt_parm cp_function_chain->x_vtt_parm
>
> +/* A boolean flag to control whether we need to clean up the return value if 
> a
> +   local destructor throws.  Only used in functions that return by value a
> +   class with a destructor.  Which 'tors don't, so we can use the same
> +   field as current_vtt_parm.  */
> +
> +#define current_retval_sentinel current_vtt_parm
> +
>  /* Set to 0 at beginning of a function definition, set to 1 if
> a return statement that specifies a return value is seen.  */
>
> diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> index 094e32edf58..52da0deef40 100644
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -16418,6 +16418,20 @@ start_preparsed_function (tree decl1, tree attrs, 
> int flags)
>if (!DECL_OMP_DECLARE_REDUCTION_P (decl1))
>  start_lambda_scope (decl1);
>
> +  /* If cleaning up locals on return throws an exception, we need to destroy
> + the return value that we just constructed.  */
> +  if (!processing_template_decl
> +  && TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TREE_TYPE (TREE_TYPE (decl1
> +{
> +  tree retval = DECL_RESULT (decl1);
> +  tree dtor = build_cleanup (retval);
> +  current_retval_sentinel = get_temp_regvar (boolean_type_node,
> +boolean_false_node);
> +  dtor = build3 (COND_EXPR, void_type_node, current_retval_sentinel,
> +dtor, void_node);
> +  push_cleanup (retval, dtor, /*eh-only*/true);
> +}
> +
>return true;
>  }
>
> diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
> index 7b653cebca0..8288b662ec0 100644
> --- a/gcc/cp/typeck.c
> +++ b/gcc/cp/typeck.c
> @@ -10088,6 +10088,15 @@ check_return_expr (tree retval, bool *no_warning)
>if (retval && retval != result)
>  retval = build2 (INIT_EXPR, TREE_TYPE (result), result, retval);
>
> +  if (TYPE_HAS_NONTRIVIAL_DESTRUCTOR (valtype)
> +  /* FIXME doesn't work with deduced return type.  */
> +  && current_retval_sentinel)
> +{
> +  tree set = build2 (MODIFY_EXPR, boolean_type_node,
> +current_retval_sentinel, boolean_true_node);
> +  retval = build2 (COMPOUND_EXPR, void_type_node, retval, set);
> +}
> +
>return retval;
>  }
>
> diff --git a/gcc/gimplify.c b/gcc/gimplify.c
> index fe7236de4c3..05d7922116b 100644
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -1599,6 +1599,14 @@ gimplify_return_expr (tree stmt, gimple_seq *pre_p)
>
>if (VOID_TYPE_P (TREE_TYPE (TREE_TYPE (current_function_decl
>  result_decl = NULL_TREE;
> +  else if (TREE_CODE (ret_expr) == COMPOUND_EXPR)
> +{
> +  /* Used in C++ for handling EH cleanup of the return value if a local
> +cleanup throws.  Assume the front-end knows what it's doing.  */
> +  result_decl = DECL_RESULT (current_function_decl);
> +  /* But crash if we end up trying to modify ret_expr below.  */
> +  ret_expr = NULL_TREE;
> +}
>else
>  {
>result_decl = TREE_OPERAND (ret_expr, 0);
> diff --git 

Re: [PATCH 3/4] Also propagate SRA accesses from LHS to RHS (PR 92706)

[Martin Jambor]

Hi,

sorry for taking so long to reply...

On Wed, Dec 18 2019, Richard Biener wrote:
> On December 17, 2019 1:43:15 PM GMT+01:00, Martin Jambor  
> wrote:
>>Hi,
>>
>>the previous patch unfortunately does not fix the first testcase in PR
>>92706 and since I am afraid it might be the important one, I also
>>focused on that.  The issue here is again total scalarization accesses
>>clashing with those representing accesses in the IL - on another
>>aggregate but here the sides are switched.  Whereas in the previous
>>case the total scalarization accesses prevented propagation along
>>assignments, here we have the user accesses on the LHS, so even though
>>we do not create anything there, we totally scalarize the RHS and
>>again end up with assignments with different scalarizations leading to
>>bad code.
>>
>>So we clearly need to propagate information about accesses from RHSs
>>to LHSs too, which the patch below does.  Because the intent is only
>>preventing bad total scalarization - which the last patch now performs
>>late enough - and do not care about grp_write flag and so forth, the
>>propagation is a bit simpler and so I did not try to unify all of the
>>code for both directions.
>
>  But can we really propagate the directions independently? Lacc to racc 
> propagation would induce accesses to different racc to Lacc branches of the 
> access tree of the parent, no? So in full generality the access links Form an 
> undirected graph where you perform propagation in both directions of edges 
> (and you'd have to consider cycles). 'linked parts' of the graph then need to 
> have the same (or at least a compatible) scalarization, and three would be 
> the possibility to compute the optimal 'conflict border' where to fix the 
> conflict we'd keep one node in the graph unscalarized. 
>
> The way you did it might be sufficient in practice of course and we should 
> probably go with that for now?

I think it should be - at least I think I would not be able to come up
with an implementation quickly enough for GCC 10 - I assumed that was
the target.  And also because there is that one important difference
between the propagation, the RHS->LHS also propagates
"actually-contains-data" whereas the other direction is just to prevent
total scalarization to create conflicts - and it is sufficient to do
that and I suppose in any search for optimal scalarization we'd give
total scalarization the smallest priority anyway.

Thanks,

Martin

>
> Richard. 
>
>>I still think that even with this patch the total scalarization has to
>>follow the declared type of the aggregate and cannot be done using
>>integers of the biggest suitable power, at least in early SRA, because
>>these propagations of course do not work interprocedurally but
>>inlining can and does eventually bring accesses from two functions
>>together which could (and IMHO would) lead to same problems.
>>
>>Bootstrapped and LTO-bootstrapped and tested on an x86_64-linux and
>>bootstrapped and tested it on aarch64 and i686 (except that on i686
>>the testcase will need to be skipped because __int128_t is not
>>available there).  I expect that review will lead to requests to
>>change things but as far as I am concerned, this is ready for trunk
>>too.
>>
>>Thanks,
>>
>>Martin
>>
>>2019-12-11  Martin Jambor  
>>
>>  PR tree-optimization/92706
>>  * tree-sra.c (struct access): Fields first_link, last_link,
>>  next_queued and grp_queued renamed to first_rhs_link, last_rhs_link,
>>  next_rhs_queued and grp_rhs_queued respectively, new fields
>>  first_lhs_link, last_lhs_link, next_lhs_queued and grp_lhs_queued.
>>  (struct assign_link): Field next renamed to next_rhs, new field
>>  next_lhs.  Updated comment.
>>  (work_queue_head): Renamed to rhs_work_queue_head.
>>  (lhs_work_queue_head): New variable.
>>  (add_link_to_lhs): New function.
>>  (relink_to_new_repr): Also relink LHS lists.
>>  (add_access_to_work_queue): Renamed to add_access_to_rhs_work_queue.
>>  (add_access_to_lhs_work_queue): New function.
>>  (pop_access_from_work_queue): Renamed to
>>  pop_access_from_rhs_work_queue.
>>  (pop_access_from_lhs_work_queue): New function.
>>  (build_accesses_from_assign): Also add links to LHS lists and to LHS
>>  work_queue.
>>  (child_would_conflict_in_lacc): Renamed to
>>  child_would_conflict_in_acc.  Adjusted parameter names.
>>  (create_artificial_child_access): New parameter set_grp_read, use it.
>>  (subtree_mark_written_and_enqueue): Renamed to
>>  subtree_mark_written_and_rhs_enqueue.
>>  (propagate_subaccesses_across_link): Renamed to
>>  propagate_subaccesses_from_rhs.
>>  (propagate_subaccesses_from_lhs): New function.
>>  (propagate_all_subaccesses): Also propagate subaccesses from LHSs to
>>  RHSs.
>>
>>  testsuite/
>>  * gcc.dg/tree-ssa/pr92706-1.c: New test.

Re: [GCC][PATCH][ARM] Add Bfloat16_t scalar type, vector types and machine modes to ARM back-end [1/2]

[Kyrill Tkachov]

Hi Stam,

On 1/10/20 6:45 PM, Stam Markianos-Wright wrote:

Hi all,

This is a respin of patch:

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html

which has now been split into two (similar to the Aarch64 version).

This is patch 1 of 2 and adds Bfloat type support to the ARM back-end.
It also adds a new machine_mode (BFmode) for this type and 
accompanying Vector

modes V4BFmode and V8BFmode.

The second patch in this series uses existing target hooks to restrict 
type use.


Regression testing on arm-none-eabi passed successfully.

This patch depends on:

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00857.html

for test suite effective_target update.

Ok for trunk?


This is ok, thanks.

You can commit it once the git conversion goes through :)

Kyrill




Cheers,
Stam


ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest

Details on ARM Bfloat can be found here:
https://community.arm.com/developer/ip-products/processors/b/ml-ip-blog/posts/bfloat16-processing-for-neural-networks-on-armv8_2d00_a 





gcc/ChangeLog:

2020-01-10  Stam Markianos-Wright 

    * config.gcc: Add arm_bf16.h.
    * config/arm/arm-builtins.c (arm_mangle_builtin_type):  Fix 
comment.

    (arm_simd_builtin_std_type): Add BFmode.
    (arm_init_simd_builtin_types): Define element types for vector 
types.

    (arm_init_bf16_types):  New function.
    (arm_init_builtins): Add arm_init_bf16_types function call.
    * config/arm/arm-modes.def: Add BFmode and V4BF, V8BF vector 
modes.

    * config/arm/arm-simd-builtin-types.def: Add V4BF, V8BF.
    * config/arm/arm.c (aapcs_vfp_sub_candidate):  Add BFmode.
    (arm_hard_regno_mode_ok): Add BFmode and tidy up statements.
    (arm_vector_mode_supported_p): Add V4BF, V8BF.
    (arm_mangle_type):
    * config/arm/arm.h: Add V4BF, V8BF to VALID_NEON_DREG_MODE,
  VALID_NEON_QREG_MODE respectively. Add export 
arm_bf16_type_node,

  arm_bf16_ptr_type_node.
    * config/arm/arm.md: New enabled_for_bfmode_scalar,
  enabled_for_bfmode_vector attributes. Add BFmode to movhf 
expand.

  pattern and define_split between ARM registers.
    * config/arm/arm_bf16.h: New file.
    * config/arm/arm_neon.h: Add arm_bf16.h and Bfloat vector types.
    * config/arm/iterators.md (ANY64_BF, VDXMOV, VHFBF, HFBF, 
fporbf): New.

  (VQXMOV): Add V8BF.
    * config/arm/neon.md: Add BF vector types to NEON move patterns.
    * config/arm/vfp.md: Add BFmode to movhf patterns.

gcc/testsuite/ChangeLog:

2020-01-10  Stam Markianos-Wright 

    * g++.dg/abi/mangle-neon.C: Add Bfloat vector types.
    * g++.dg/ext/arm-bf16/bf16-mangle-1.C: New test.
    * gcc.target/arm/bfloat16_scalar_1_1.c: New test.
    * gcc.target/arm/bfloat16_scalar_1_2.c: New test.
    * gcc.target/arm/bfloat16_scalar_2_1.c: New test.
    * gcc.target/arm/bfloat16_scalar_2_2.c: New test.
    * gcc.target/arm/bfloat16_scalar_3_1.c: New test.
    * gcc.target/arm/bfloat16_scalar_3_2.c: New test.
    * gcc.target/arm/bfloat16_scalar_4.c: New test.
    * gcc.target/arm/bfloat16_simd_1_1.c: New test.
    * gcc.target/arm/bfloat16_simd_1_2.c: New test.
    * gcc.target/arm/bfloat16_simd_2_1.c: New test.
    * gcc.target/arm/bfloat16_simd_2_2.c: New test.
    * gcc.target/arm/bfloat16_simd_3_1.c: New test.
    * gcc.target/arm/bfloat16_simd_3_2.c: New test.

GCC 10.0 Status Report (2020-01-13), Stage 4 in effect now

[Richard Biener]

Status
==

Stage 3 ended, GCC trunk is open for regression and documentation
fixes only, stage 4.


Quality Data


Priority  #   Change from last report
---   ---
P1   20   +  14
P2  196   -   5
P3  163   +  34
P4  151   
P5   23   
---   ---
Total P1-P3 379   +  43
Total   553   +  43


Previous Report
===

https://gcc.gnu.org/ml/gcc/2019-11/msg00117.html

Re: [PATCH] Add Optimization for various IPA parameters.

[Martin Jambor]

Hi,

On Mon, Jan 13 2020, Martin Liška wrote:
> On 1/11/20 1:20 PM, Tamar Christina wrote:
>> It seems the parameters no longer do anything. i.e. -flto --param 
>> ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=80 doesn't have any 
>> effect anymore.
>
> Hi.
>
> You are right, the param '--param ipa-cp-unit-growth' is really unused.
> It's cause by Martin's commit f7725a488382, where we again reinvented
> renamed param name. It will be fixed with the following obvious commit.
>
> I'm going to install it once git will be opened for committing.

Oh, sorry, somehow the conflict marks tricked me into thinking you
canonicialized the ipa cp parameters the other way round.

Thanks,

Martin

>
> Martin
> From 72f42e55f3a2cbfd73d142de0b3799b6d787d05f Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Mon, 13 Jan 2020 10:00:35 +0100
> Subject: [PATCH] Remove usage of legacy param_ipa_cp_unit_growth.
>
> gcc/ChangeLog:
>
> 2020-01-13  Martin Liska  
>
>   * ipa-cp.c (get_max_overall_size): Use newly
>   renamed param param_ipa_cp_unit_growth.
>   * params.opt: Remove legacy param name.

Re: [PATCH 06/41] Add diagnostic paths

[Rainer Orth]

Hi David,

> On Fri, 2020-01-10 at 08:38 -0700, Jeff Law wrote:
>> On Wed, 2020-01-08 at 04:02 -0500, David Malcolm wrote:
>> > I believe I can self-approve this with my "diagnostic messages"
>> > maintainer hat on.  It has dependencies on the auto_delete_vec
>> > and the -fdiagnostics-nn-line-numbers patches.
>> > 
>> > Changed in v5:
>> > - updated copyright years to include 2020
>> > 
>> > Changed in v4:
>> > - Add support for paths for signal-handlers:
>> >   https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00215.html
>> > - Fix comment
>> > 
>> > Changed in v3:
>> > - Fixup for rebase (r278634): c-format.c: get_pointer_to_named_type
>> > -> get_named_type
>> > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00530.html
>> > 
>> > Changed in v2:
>> > - Fixup for rebase (r277284) for json::number ->
>> > json::integer_number
>> > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02035.html
>> > 
>> > This patch adds support for associating a "diagnostic_path" with a
>> > diagnostic: a sequence of events predicted by the compiler that
>> > leads to
>> > the problem occurring, with their locations in the user's source,
>> > text descriptions, and stack information (for handling
>> > interprocedural
>> > paths).
>> > 
>> > For example, the following (hypothetical) error has a 3-event
>> > intraprocedural path:
>> > 
>> > test.c: In function 'demo':
>> > test.c:29:5: error: passing NULL as argument 1 to 'PyList_Append'
>> > which
>> >   requires a non-NULL parameter
>> >29 | PyList_Append(list, item);
>> >   | ^
>> >   'demo': events 1-3
>> >  |
>> >  |   25 |   list = PyList_New(0);
>> >  |  |  ^
>> >  |  |  |
>> >  |  |  (1) when 'PyList_New' fails, returning NULL
>> >  |   26 |
>> >  |   27 |   for (i = 0; i < count; i++) {
>> >  |  |   ~~~
>> >  |  |   |
>> >  |  |   (2) when 'i < count'
>> >  |   28 | item = PyLong_FromLong(random());
>> >  |   29 | PyList_Append(list, item);
>> >  |  | ~
>> >  |  | |
>> >  |  | (3) when calling 'PyList_Append', passing NULL
>> > from (1) as argument 1
>> >  |
>> > 
>> > The patch adds a new "%@" format code for printing event IDs, so
>> > that
>> > in the above, the description of event (3) mentions event (1),
>> > showing
>> > the user where the bogus NULL value comes from (the event IDs are
>> > colorized to draw the user's attention to them).
>> > 
>> > There is a separation between data vs presentation: the above shows
>> > how
>> > the diagnostic-printing code has consolidated the path into a
>> > single run
>> > of events, since all the events are near each other and within the
>> > same
>> > function; more complicated examples (such as interprocedural paths)
>> > might be printed as multiple runs of events.
>> > 
>> > Examples of how interprocedural paths are printed can be seen in
>> > the
>> > test suite (which uses a plugin to exercise the code without
>> > relying
>> > on specific warnings using this functionality).
>> > 
>> > Other output formats include
>> > - JSON,
>> > - printing each event as a separate "note", and
>> > - to not emit paths.
>> > 
>> > (I have a separate script that can generate HTML from the JSON, but
>> > HTML
>> > is not my speciality; help from a web front-end expert to make it
>> > look
>> > good would be appreciated).
>> > 
>> > gcc/ChangeLog:
>> >* Makefile.in (OBJS): Add tree-diagnostic-path.o.
>> >* common.opt (fdiagnostics-path-format=): New option.
>> >(diagnostic_path_format): New enum.
>> >(fdiagnostics-show-path-depths): New option.
>> >* coretypes.h (diagnostic_event_id_t): New forward decl.
>> >* diagnostic-color.c (color_dict): Add "path".
>> >* diagnostic-event-id.h: New file.
>> >* diagnostic-format-json.cc (json_from_expanded_location): Make
>> >non-static.
>> >(json_end_diagnostic): Call context->make_json_for_path if it
>> >exists and the diagnostic has a path.
>> >(diagnostic_output_format_init): Clear context->print_path.
>> >* diagnostic-path.h: New file.
>> >* diagnostic-show-locus.c (colorizer::set_range): Special-case
>> >when printing a run of events in a diagnostic_path so that they
>> >all get the same color.
>> >(layout::m_diagnostic_path_p): New field.
>> >(layout::layout): Initialize it.
>> >(layout::print_any_labels): Don't colorize the label text for
>> > an
>> >event in a diagnostic_path.
>> >(gcc_rich_location::add_location_if_nearby): Add
>> >"restrict_to_current_line_spans" and "label" params.  Pass the
>> >former to layout.maybe_add_location_range; pass the latter
>> >when calling add_range.
>> >* diagnostic.c: Include "diagnostic-path.h".
>> >(diagnostic_initialize): Initialize context->path_format and
>> >context->show_path_depths.
>> >(diagnostic_show_any_path): New 

Re: [PATCH] Further bootstrap unbreak (was Re: [PATCH] PR90838: Support ctz idioms)

[Richard Biener]

On Mon, 13 Jan 2020, Jakub Jelinek wrote:

> On Sat, Jan 11, 2020 at 05:30:52PM +0100, Jakub Jelinek wrote:
> > On Sat, Jan 11, 2020 at 05:24:19PM +0100, Andreas Schwab wrote:
> > > ../../gcc/tree-ssa-forwprop.c: In function 'bool 
> > > simplify_count_trailing_zeroes(gimple_stmt_iterator*)':
> > > ../../gcc/tree-ssa-forwprop.c:1925:23: error: variable 'mode' set but not 
> > > used [-Werror=unused-but-set-variable]
> > >  1925 |   scalar_int_mode mode = SCALAR_INT_TYPE_MODE (type);
> > >   |   ^~~~
> > 
> > Oops, then I think we need following, but can't commit it until Monday.
> 
> Unfortunately, at least when testing x86_64-linux to s390x-linux cross,
> there are two warnings instead of just one:
> ../../gcc/tree-ssa-forwprop.c: In function ‘bool 
> simplify_count_trailing_zeroes(gimple_stmt_iterator*)’:
> ../../gcc/tree-ssa-forwprop.c:1925:23: warning: variable ‘mode’ set but not 
> used [-Wunused-but-set-variable]
>scalar_int_mode mode = SCALAR_INT_TYPE_MODE (type);
>^~~~
> ../../gcc/tree-ssa-forwprop.c:1932:7: warning: ‘ctzval’ may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>if (zero_val != ctzval && !(zero_val == 0 && ctzval == type_size))
>^~
> at -O0 and just the first one at -O2.
> The first warning (or with error with -Werror) can be cured by the
> patch I've posted on Saturday, I've successfully bootstrapped/regtested
> it in the mean time on x86_64-linux and i686-linux, tested on aarch64-linux
> including the testcase and tested on s390x-linux.
> 
> Or we could also initialize ctzval as in the following patch to e.g. match
> what we do in vr-values.c with *_DEFINED_VALUE_AT_ZERO.  Except for the
> x86_64-linux/i686-linux bootstrap/regtest, tested similarly to the above.
> 
> So, ok for trunk and which one?

OK, the one below looks good to me.

> 2020-01-13  Jakub Jelinek  
> 
>   PR tree-optimization/90838
>   * tree-ssa-forwprop.c (simplify_count_trailing_zeroes): Use
>   SCALAR_INT_TYPE_MODE directly in CTZ_DEFINED_VALUE_AT_ZERO macro
>   argument rather than to initialize temporary for targets that
>   don't use the mode argument at all.  Initialize ctzval to avoid
>   warning at -O0.
> 
> --- gcc/tree-ssa-forwprop.c
> +++ gcc/tree-ssa-forwprop.c
> @@ -1920,10 +1920,10 @@ simplify_count_trailing_zeroes (gimple_stmt_iterator 
> *gsi)
> res_ops[1], res_ops[2], zero_val))
>  {
>tree type = TREE_TYPE (res_ops[0]);
> -  HOST_WIDE_INT ctzval;
> +  HOST_WIDE_INT ctzval = 0;
>HOST_WIDE_INT type_size = tree_to_shwi (TYPE_SIZE (type));
> -  scalar_int_mode mode = SCALAR_INT_TYPE_MODE (type);
> -  bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (mode, ctzval) == 2;
> +  bool zero_ok
> + = CTZ_DEFINED_VALUE_AT_ZERO (SCALAR_INT_TYPE_MODE (type), ctzval) == 2;
>  
>/* Skip if there is no value defined at zero, or if we can't easily
>return the correct value for zero.  */
> 
>   Jakub

Re: [PATCH][vect] PR92429: do not fold when updating epilogue statements

[Richard Biener]

On Fri, 10 Jan 2020, Andre Vieira (lists) wrote:

> Hi,
> 
> This patch addresses the problem reported in PR92429.  When creating an
> epilogue for vectorization we have to replace the SSA_NAMEs in the
> PATTERN_DEF_SEQs and RELATED_STMTs of the epilogue's loop_vec_infos. When
> doing this we were using simplify_replace_tree which always folds the
> replacement.  This may lead to a different tree-node than the one which was
> analyzed in vect_loop_analyze.  In turn the new tree-node may require a
> different vectorization than the one we had prepared for which caused the ICE
> in question.
> 
> This patch adds a parameter to the simplify_replace_tree function such that we
> can optionally disable folding as this patch does in
> update_epilogue_loop_vinfo.
> 
> Bootstrapped and regression tested on x86_64.
> 
> Is this OK for trunk?

OK.

Thanks,
Richard.

> gcc/ChangeLog:
> 2020-01-10  Andre Vieira  
> 
> PR tree-optimization/92429
> * tree-ssa-loop-niter.h (simplify_replace_tree): Add parameter.
> * tree-ssa-loop-niter.c (simplify_replace_tree): Add parameter
> to control folding.
> * tree-vect-loop.c (update_epilogue_vinfo): Do not fold when
> replacing tree.
> 
> gcc/testsuite/ChangeLog:
> 2020-01-10  Andre Vieira  
> 
> PR tree-optimization/92429
> * gcc.dg/vect/pr92429.c
> 
> 

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

Vérification du véhicule

[Damien Ganthier via gcc-patches]

Bonjour,
 
Les entrepreneurs qui surveillent les véhicules de l'entreprise en temps réel, 
y compris le kilométrage et la consommation de carburant, réduisent les coûts 
d'entretien du parc de près de 20% et améliorent l'organisation des livraisons.
 
Seriez-vous intéressé par ce type de solution?
N'hésitez pas à me contacter pour toute question que vous auriez.
Veuillez recevoir mes plus cordiales salutations.
Damien Ganthier
dam...@realbizit.com

Re: [PATCH] Add Optimization for various IPA parameters.

[Martin Liška]

On 1/11/20 1:20 PM, Tamar Christina wrote:

It seems the parameters no longer do anything. i.e. -flto --param 
ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=80 doesn't have any effect 
anymore.


Hi.

You are right, the param '--param ipa-cp-unit-growth' is really unused.
It's cause by Martin's commit f7725a488382, where we again reinvented
renamed param name. It will be fixed with the following obvious commit.

I'm going to install it once git will be opened for committing.

Martin
>From 72f42e55f3a2cbfd73d142de0b3799b6d787d05f Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 13 Jan 2020 10:00:35 +0100
Subject: [PATCH] Remove usage of legacy param_ipa_cp_unit_growth.

gcc/ChangeLog:

2020-01-13  Martin Liska  

	* ipa-cp.c (get_max_overall_size): Use newly
	renamed param param_ipa_cp_unit_growth.
	* params.opt: Remove legacy param name.
---
 gcc/ipa-cp.c   | 2 +-
 gcc/params.opt | 6 +-
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 1c1103ca32b..612f3d0a89b 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -3432,7 +3432,7 @@ get_max_overall_size (cgraph_node *node)
   long large_unit = opt_for_fn (node->decl, param_large_unit_insns);
   if (max_new_size < large_unit)
 max_new_size = large_unit;
-  int unit_growth = opt_for_fn (node->decl, param_ipcp_unit_growth);
+  int unit_growth = opt_for_fn (node->decl, param_ipa_cp_unit_growth);
   max_new_size += max_new_size * unit_growth / 100 + 1;
   return max_new_size;
 }
diff --git a/gcc/params.opt b/gcc/params.opt
index a669bbc1aa5..31cc20031b1 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -215,7 +215,7 @@ Common Joined UInteger Var(param_ipa_cp_single_call_penalty) Init(15) IntegerRan
 Percentage penalty functions containing a single call to another function will receive when they are evaluated for cloning.
 
 -param=ipa-cp-unit-growth=
-Common Joined UInteger Var(param_ipa_cp_unit_growth) Init(10) Param
+Common Joined UInteger Var(param_ipa_cp_unit_growth) Init(10) Param Optimization
 How much can given compilation unit grow because of the interprocedural constant propagation (in percent).
 
 -param=ipa-cp-value-list-size=
@@ -246,10 +246,6 @@ Maximum pieces that IPA-SRA tracks per formal parameter, as a consequence, also
 Common Joined UInteger Var(param_ipa_sra_ptr_growth_factor) Init(2) Param Optimization
 Maximum allowed growth of number and total size of new parameters that ipa-sra replaces a pointer to an aggregate with.
 
--param=ipcp-unit-growth=
-Common Joined UInteger Var(param_ipcp_unit_growth) Optimization Init(10) Param
-How much can given compilation unit grow because of the interprocedural constant propagation (in percent).
-
 -param=ira-loop-reserved-regs=
 Common Joined UInteger Var(param_ira_loop_reserved_regs) Init(2) Param Optimization
 The number of registers in each class kept unused by loop invariant motion.
-- 
2.24.1

[PATCH] Further bootstrap unbreak (was Re: [PATCH] PR90838: Support ctz idioms)

[Jakub Jelinek]

On Sat, Jan 11, 2020 at 05:30:52PM +0100, Jakub Jelinek wrote:
> On Sat, Jan 11, 2020 at 05:24:19PM +0100, Andreas Schwab wrote:
> > ../../gcc/tree-ssa-forwprop.c: In function 'bool 
> > simplify_count_trailing_zeroes(gimple_stmt_iterator*)':
> > ../../gcc/tree-ssa-forwprop.c:1925:23: error: variable 'mode' set but not 
> > used [-Werror=unused-but-set-variable]
> >  1925 |   scalar_int_mode mode = SCALAR_INT_TYPE_MODE (type);
> >   |   ^~~~
> 
> Oops, then I think we need following, but can't commit it until Monday.

Unfortunately, at least when testing x86_64-linux to s390x-linux cross,
there are two warnings instead of just one:
../../gcc/tree-ssa-forwprop.c: In function ‘bool 
simplify_count_trailing_zeroes(gimple_stmt_iterator*)’:
../../gcc/tree-ssa-forwprop.c:1925:23: warning: variable ‘mode’ set but not 
used [-Wunused-but-set-variable]
   scalar_int_mode mode = SCALAR_INT_TYPE_MODE (type);
   ^~~~
../../gcc/tree-ssa-forwprop.c:1932:7: warning: ‘ctzval’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   if (zero_val != ctzval && !(zero_val == 0 && ctzval == type_size))
   ^~
at -O0 and just the first one at -O2.
The first warning (or with error with -Werror) can be cured by the
patch I've posted on Saturday, I've successfully bootstrapped/regtested
it in the mean time on x86_64-linux and i686-linux, tested on aarch64-linux
including the testcase and tested on s390x-linux.

Or we could also initialize ctzval as in the following patch to e.g. match
what we do in vr-values.c with *_DEFINED_VALUE_AT_ZERO.  Except for the
x86_64-linux/i686-linux bootstrap/regtest, tested similarly to the above.

So, ok for trunk and which one?

2020-01-13  Jakub Jelinek  

PR tree-optimization/90838
* tree-ssa-forwprop.c (simplify_count_trailing_zeroes): Use
SCALAR_INT_TYPE_MODE directly in CTZ_DEFINED_VALUE_AT_ZERO macro
argument rather than to initialize temporary for targets that
don't use the mode argument at all.  Initialize ctzval to avoid
warning at -O0.

--- gcc/tree-ssa-forwprop.c
+++ gcc/tree-ssa-forwprop.c
@@ -1920,10 +1920,10 @@ simplify_count_trailing_zeroes (gimple_stmt_iterator 
*gsi)
  res_ops[1], res_ops[2], zero_val))
 {
   tree type = TREE_TYPE (res_ops[0]);
-  HOST_WIDE_INT ctzval;
+  HOST_WIDE_INT ctzval = 0;
   HOST_WIDE_INT type_size = tree_to_shwi (TYPE_SIZE (type));
-  scalar_int_mode mode = SCALAR_INT_TYPE_MODE (type);
-  bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (mode, ctzval) == 2;
+  bool zero_ok
+   = CTZ_DEFINED_VALUE_AT_ZERO (SCALAR_INT_TYPE_MODE (type), ctzval) == 2;
 
   /* Skip if there is no value defined at zero, or if we can't easily
 return the correct value for zero.  */

Jakub

Re: [PATCH] Make warn_inline Optimization option.

[Martin Liška]

Hi.

I've got a patch that restores --help=optimize to what we had for GCC 9.
That means it will not print parameters (and the warn_inline warning).

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

Ready to be installed?
Thanks,
Martin
>From 44870c6ac7e97a36cbd0ca102bbe73ab9e808835 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Fri, 10 Jan 2020 16:45:54 +0100
Subject: [PATCH] Exclude CL_WARNING and CL_PARAM from --help=optimize.

---
 gcc/opts.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/opts.c b/gcc/opts.c
index fa4804c8d15..33a662b54f5 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2137,6 +2137,11 @@ print_help (struct gcc_options *opts, unsigned int lang_mask,
   a = comma + 1;
 }
 
+  /* We started using PerFunction/Optimization for parameters and
+ a warning.  We should exclude these from optimization options.  */
+  if (include_flags & CL_OPTIMIZATION)
+exclude_flags |= CL_WARNING | CL_PARAMS;
+
   if (include_flags)
 print_specific_help (include_flags, exclude_flags, 0, opts,
 			 lang_mask);
-- 
2.24.1

Re: [wwwdocs] Git transition - how to access private user and vendor branches

[Iain Sandoe]

Segher Boessenkool  wrote:


On Sun, Jan 12, 2020 at 01:31:13PM +, Iain Sandoe wrote:

Segher Boessenkool  wrote:

Why would people want to name their local branches "me/thing" instead
of just "thing", btw?


it’s a way of making things distinct and allows the push rule to be  
present for them

but absent for more dangerous pushes.


That's a weird setting imo.  Potentially destroying your own work *is*
dangerous :-)

Pretty much anything you mess up locally in Git can be easily restored.
Restoring remote branches can be much harder.  To start with, this
requires knowing *what* to restore, which can require direct access to
the remote repository, or its backups.  So doing an unexpected non-ff
push is probably not a good idea.

You can also add a "+" manually when you want to overwrite the remote
branch, or configure your setup to always do that for certain branches.


(FAOD) I wasn’t suggesting to add the ‘+’ (I never set anything to force  
push)

just commenting that putting one’s own work in a separate namespace isn’t
a bad plan.


It all depends on personal preference and work habits, of course.  But
I think it isn't the best idea to recommend people take up dangerous
habits :-)


So if one renames origin to something else
e.g. fsf or upstream, and there are no automatic push rules, it’s one  
more small

protection against an accidental push?


If you haven't configured push rules for your remote, you get what you
have in "push.default" for that remote.  Since Git 2.0 the default has
been "push.default = simple", and no non-ff pushes are allowed by default
anyway?

I guess it makes some sense to group together locally the branches you
have in users/ on our shared server.  But then "me/" is not a great
name :-)


no, I usually duplicate the ‘userid’.

Iain