Re: Hashtable comment cleanups & renamings

[François Dumont]

On 5/17/19 10:24 PM, Jonathan Wakely wrote:

On 17/05/19 18:19 +0200, François Dumont wrote:

Hi

    I got tired of '__n' being used in _Hashtable for many different 
purposes: node, bucket, bucket count, bucket hint. It makes the code 
difficult to read. This code makes sure that __n is a node except is 
some very limited use cases where the method name is clear enough to 
tell what __n means.


    So I'd like to commit this patch which only change that and some 
comments before moving forward to more serious stuff. The only code 
change is a use of auto return type on _M_allocate_node.


    My main concern is the ChangeLog entry. Is the following entry ok ?

    Rename variables and cleanup comments.
    * include/bits/hashtable_policy.h
    * include/bits/hashtable.h

    Tested under Linux x86_64 (even if it can't be otherwise)

François




@@ -350,24 +347,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _M_base_alloc() { return *this; }

  __bucket_type*
-  _M_allocate_buckets(size_type __n)
+  _M_allocate_buckets(size_type __bkt_count)


This is a much more helpful name, thanks.


@@ -439,30 +436,31 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { }

  explicit
-  _Hashtable(size_type __n,
+  _Hashtable(size_type __bkt_hint,


This seems less helpful. Would __num_bkts_hint be clearer?
Or for consistency, __bkt_count_hint?


I thought also about a longer name like this one but then I considered 
that I didn't want to make it too long and that '__bkt_hint' was enough 
know that this parameter was related to the buckets. But I can use 
__bkt_count_hint if you prefer.





@@ -1415,9 +1414,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
    -> iterator
    {
  __hash_code __code = this->_M_hash_code(__k);
-  std::size_t __n = _M_bucket_index(__k, __code);
-  __node_type* __p = _M_find_node(__n, __k, __code);
-  return __p ? iterator(__p) : end();
+  std::size_t __bkt = _M_bucket_index(__k, __code);
+  __node_type* __n = _M_find_node(__bkt, __k, __code);
+  return __n ? iterator(__n) : end();


Is __n really an improvement over __p here?


Outside any context no but within _Hashtable implementation __n is 
already used most of the time to indicate a node. This is patch just try 
to fix this 'most of the time' part.





If you're changing it, __node or __ptr might be an improvement, but
changing __p to __n seems like unnecessary churn.

I'm not convinced that __n is a big enough improvement over __p to
bother changing dozens of lines, for not much benefit. All those
changes will make it slower to use git blame to track down when thigns
changed, and will make it harder to review diffs between trunk and
older branches.


Yes, this is why I wanted to commit it outside of any real change so 
that this commit can be ignore from any git log or blame more easily.


So I can limit the patch to renaming __n occurences into __bkt, 
__bkt_count_hint, __bkt_count when possible and leave other __n but also 
__p & al untouch.






@@ -1479,17 +1478,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
    -> pair
    {
  __hash_code __code = this->_M_hash_code(__k);
-  std::size_t __n = _M_bucket_index(__k, __code);
-  __node_type* __p = _M_find_node(__n, __k, __code);
+  std::size_t __bkt = _M_bucket_index(__k, __code);
+  __node_type* __n = _M_find_node(__bkt, __k, __code);

-  if (__p)
+  if (__n)
{
-  __node_type* __p1 = __p->_M_next();
-  while (__p1 && _M_bucket_index(__p1) == __n
- && this->_M_equals(__k, __code, __p1))
-    __p1 = __p1->_M_next();
+  __node_type* __n1 = __n->_M_next();


__p1 is not a good name, but __n1 is no better.

At least with __p the second pointer could be __q, which is a fairly
idiomatic pairing of letters :-)

How about __first and __last? Or __n and __next?  Even __n1 and __n2
seems better than __n and __n1. Those pointers end up being used for
the 'first' and 'second' members of a pair, so __n1 and __n2 makes
more sense than setting 'first' from __n and 'second' from __n1.

But I don't feel strongly about it, so if it's just me who dislikes
__n and __n1 then it doesn't matter.

diff --git a/libstdc++-v3/include/bits/hashtable_policy.h 
b/libstdc++-v3/include/bits/hashtable_policy.h

index a4d2a97f4f3..bb2e7b762ff 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -181,7 +181,7 @@ namespace __detail
   *  @tparam _Cache_hash_code  Boolean value. True if the value of
   *  the hash function is stored along with the value. This is a
   *  time-space tradeoff.  Storing it may improve lookup speed by
-   *  reducing the number of times we need to call the _Equal
+   *  reducing the number of times we need to call the _Hash


Doesn't it reduce both?

In _M_equals we don't bother calling the _Equal predicate if the
cached hash code doesn't match the one for the key we're comparing.




Sure it reduces both, I'll just add _Hash (but first)

Deque rotate on current node

[François Dumont]

Hi

  std::deque is supposed to be like a double-queue that you can attack 
from front and back. But currrently its implementation makes it behave 
differently when starting from a fresh deque. If push_back then all goes 
well, it is copy/move to the current internal 'node'. If push_front then 
a new 'node' is created and on next pop_back the initial node will be 
deallocated without having ever be used.


  This patch changes this behavior. As long as deque is empty we can 
play with its state to make it push_back- or push_front-ready. It will 
also benefit to the usage of deque in the std::stack.


  More generally it could really improve scenario in which deque is 
used as queue of elements exchanged between different threads. As you 
need to make sure that consumers are faster than producers then your 
deque should remain empty most of the time and so this proposed patch 
should avoid nodes to be allocated/deallocated all the time.


    * include/bits/deque.tcc (deque<>::_M_push_back_aux):
    Rotate on current node if deque is empty.
    (deue<>::_M_push_front_aux): Likewise.

Tested under Linux x86_64, ok to commit ?

François

diff --git a/libstdc++-v3/include/bits/deque.tcc b/libstdc++-v3/include/bits/deque.tcc
index 2053afe1d69..245e3e712d8 100644
--- a/libstdc++-v3/include/bits/deque.tcc
+++ b/libstdc++-v3/include/bits/deque.tcc
@@ -507,6 +507,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _M_push_back_aux(const value_type& __t)
 #endif
   {
+	if (empty())
+	  {
+	// Move iterators to point to the current node begin.
+	this->_M_impl._M_start._M_cur = this->_M_impl._M_start._M_first;
+	this->_M_impl._M_finish._M_cur = this->_M_impl._M_finish._M_first;
+#if __cplusplus >= 201103L
+	emplace_back(std::forward<_Args>(__args)...);
+#else
+	push_back(__t);
+#endif
+	return;
+	  }
+
 	if (size() == max_size())
 	  __throw_length_error(
 	  __N("cannot create std::deque larger than max_size()"));
@@ -546,6 +559,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   _M_push_front_aux(const value_type& __t)
 #endif
   {
+	if (empty())
+	  {
+	// Move iterators to point to the current node end.
+	this->_M_impl._M_finish._M_cur = this->_M_impl._M_finish._M_last - 1;
+	this->_M_impl._M_start._M_cur = this->_M_impl._M_start._M_last - 1;
+#if __cplusplus >= 201103L
+	emplace_front(std::forward<_Args>(__args)...);
+#else
+	push_front(__t);
+#endif
+	return;
+	  }
+
 	if (size() == max_size())
 	  __throw_length_error(
 	  __N("cannot create std::deque larger than max_size()"));

[PATCH 6/6] rs6000: Delete the "wH" and "wI" constraints

[Segher Boessenkool]

This replaces "wH" by "v", "wI" by "d", and when both are allowed it
uses "wa"; all with isa "p8v".


2019-05-19  Segher Boessenkool  

* config/rs6000/constraints.md (define_register_constraint "wH"):
Delete.
(define_register_constraint "wI"): Delete.
* config/rs6000/rs6000.h (enum r6000_reg_class_enum): Delete
RS6000_CONSTRAINT_wH and RS6000_CONSTRAINT_wI.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Adjust.
(rs6000_init_hard_regno_mode_ok): Adjust.
* config/rs6000/rs6000.md: Replace "wH" and "wI" constraints by "v"
resp. "d", or with "wa" as appropriate, all with "p8v".
* config/rs6000/vsx.md: Ditto.
* doc/md.texi (Machine Constraints): Adjust.

---
 gcc/config/rs6000/constraints.md |   6 --
 gcc/config/rs6000/rs6000.c   |  17 +-
 gcc/config/rs6000/rs6000.h   |   2 -
 gcc/config/rs6000/rs6000.md  | 116 +++
 gcc/config/rs6000/vsx.md |  19 ---
 gcc/doc/md.texi  |   6 --
 6 files changed, 70 insertions(+), 96 deletions(-)

diff --git a/gcc/config/rs6000/constraints.md b/gcc/config/rs6000/constraints.md
index 58394ea..dbcf08c 100644
--- a/gcc/config/rs6000/constraints.md
+++ b/gcc/config/rs6000/constraints.md
@@ -145,12 +145,6 @@ (define_memory_constraint "wF"
   "Memory operand suitable for power8 GPR load fusion"
   (match_operand 0 "fusion_addis_mem_combo_load"))
 
-(define_register_constraint "wH" "rs6000_constraints[RS6000_CONSTRAINT_wH]"
-  "Altivec register to hold 32-bit integers or NO_REGS.")
-
-(define_register_constraint "wI" "rs6000_constraints[RS6000_CONSTRAINT_wI]"
-  "FPR register to hold 32-bit integers or NO_REGS.")
-
 (define_constraint "wL"
   "Int constant that is the element number mfvsrld accesses in a vector."
   (and (match_code "const_int")
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ee5bb7f..b5dc5f3 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -2528,8 +2528,6 @@ rs6000_debug_reg_global (void)
   "wx reg_class = %s\n"
   "wz reg_class = %s\n"
   "wA reg_class = %s\n"
-  "wH reg_class = %s\n"
-  "wI reg_class = %s\n"
   "\n",
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_d]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_f]],
@@ -2554,9 +2552,7 @@ rs6000_debug_reg_global (void)
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_ww]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wx]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wz]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wA]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wH]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wI]]);
+  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wA]]);
 
   nl = "\n";
   for (m = 0; m < NUM_MACHINE_MODES; ++m)
@@ -3180,9 +3176,7 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
wv - Altivec register for ISA 2.06 VSX DF/DI load/stores.
ww - Register class to do SF conversions in with VSX operations.
wx - Float register if we can do 32-bit int stores.
-   wz - Float register if we can do 32-bit unsigned int loads.
-   wH - Altivec register if SImode is allowed in VSX registers.
-   wI - Float register if SImode is allowed in VSX registers.  */
+   wz - Float register if we can do 32-bit unsigned int loads.  */
 
   if (TARGET_HARD_FLOAT)
 {
@@ -3250,13 +3244,6 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
   if (TARGET_DIRECT_MOVE_128)
 rs6000_constraints[RS6000_CONSTRAINT_we] = VSX_REGS;
 
-  /* Support small integers in VSX registers.  */
-  if (TARGET_P8_VECTOR)
-{
-  rs6000_constraints[RS6000_CONSTRAINT_wH] = ALTIVEC_REGS;
-  rs6000_constraints[RS6000_CONSTRAINT_wI] = FLOAT_REGS;
-}
-
   /* Set up the reload helper and direct move functions.  */
   if (TARGET_VSX || TARGET_ALTIVEC)
 {
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 96471d7..eaf309b 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -1269,8 +1269,6 @@ enum r6000_reg_class_enum {
   RS6000_CONSTRAINT_wx,/* FPR register for STFIWX */
   RS6000_CONSTRAINT_wz,/* FPR register for LFIWZX */
   RS6000_CONSTRAINT_wA,/* BASE_REGS if 64-bit.  */
-  RS6000_CONSTRAINT_wH,/* Altivec register for 32-bit 
integers.  */
-  RS6000_CONSTRAINT_wI,/* VSX register for 32-bit integers.  */
   RS6000_CONSTRAINT_MAX
 };
 
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 984fe9e..b2bba5d 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -726,8 +726,8 @@ (define_mode_iterator ALTIVEC_DFORM [DF
 ;; complex forms.  Basic data transfer is done later.
 
 

[PATCH 5/6] rs6000: Delete the "wy" constraint

[Segher Boessenkool]

This replaces the "wy" constraint by "wa", with isa "p8v".  It also
creates a new attribute , used together with all .


2019-05-19  Segher Boessenkool  

* config/rs6000/constraints.md (define_register_constraint "wy"):
Delete.
* config/rs6000/rs6000.h (enum r6000_reg_class_enum): Delete
RS6000_CONSTRAINT_wy.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Adjust.
(rs6000_init_hard_regno_mode_ok): Adjust.
* config/rs6000/rs6000.md: Replace "wy" constraint by "wa" with "p8v".
Use "" as "isa" in all alternatives that use "".
(define_mode_attr Fisa): New.
* config/rs6000/vsx.md: Replace "wy" constraint by "wa" with "p8v".
* doc/md.texi (Machine Constraints): Adjust.

---
 gcc/config/rs6000/constraints.md |  3 --
 gcc/config/rs6000/rs6000.c   |  8 +---
 gcc/config/rs6000/rs6000.h   |  1 -
 gcc/config/rs6000/rs6000.md  | 84 +---
 gcc/config/rs6000/vsx.md |  5 ++-
 gcc/doc/md.texi  |  5 +--
 6 files changed, 57 insertions(+), 49 deletions(-)

diff --git a/gcc/config/rs6000/constraints.md b/gcc/config/rs6000/constraints.md
index f9bbb7f..58394ea 100644
--- a/gcc/config/rs6000/constraints.md
+++ b/gcc/config/rs6000/constraints.md
@@ -118,9 +118,6 @@ (define_register_constraint "ww" 
"rs6000_constraints[RS6000_CONSTRAINT_ww]"
 (define_register_constraint "wx" "rs6000_constraints[RS6000_CONSTRAINT_wx]"
   "Floating point register if the STFIWX instruction is enabled or NO_REGS.")
 
-(define_register_constraint "wy" "rs6000_constraints[RS6000_CONSTRAINT_wy]"
-  "FP or VSX register to perform ISA 2.07 float ops or NO_REGS.")
-
 (define_register_constraint "wz" "rs6000_constraints[RS6000_CONSTRAINT_wz]"
   "Floating point register if the LFIWZX instruction is enabled or NO_REGS.")
 
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 7e2dbf9..ee5bb7f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -2526,7 +2526,6 @@ rs6000_debug_reg_global (void)
   "wv reg_class = %s\n"
   "ww reg_class = %s\n"
   "wx reg_class = %s\n"
-  "wy reg_class = %s\n"
   "wz reg_class = %s\n"
   "wA reg_class = %s\n"
   "wH reg_class = %s\n"
@@ -2554,7 +2553,6 @@ rs6000_debug_reg_global (void)
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wv]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_ww]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wx]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wy]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wz]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wA]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wH]],
@@ -3182,7 +3180,6 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
wv - Altivec register for ISA 2.06 VSX DF/DI load/stores.
ww - Register class to do SF conversions in with VSX operations.
wx - Float register if we can do 32-bit int stores.
-   wy - Register class to do ISA 2.07 SF operations.
wz - Float register if we can do 32-bit unsigned int loads.
wH - Altivec register if SImode is allowed in VSX registers.
wI - Float register if SImode is allowed in VSX registers.  */
@@ -3232,10 +3229,7 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
 }
 
   if (TARGET_P8_VECTOR)/* 
SFmode  */
-{
-  rs6000_constraints[RS6000_CONSTRAINT_wy] = VSX_REGS;
-  rs6000_constraints[RS6000_CONSTRAINT_ww] = VSX_REGS;
-}
+rs6000_constraints[RS6000_CONSTRAINT_ww] = VSX_REGS;
   else if (TARGET_VSX)
 rs6000_constraints[RS6000_CONSTRAINT_ww] = FLOAT_REGS;
 
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 6d30561..96471d7 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -1267,7 +1267,6 @@ enum r6000_reg_class_enum {
   RS6000_CONSTRAINT_wv,/* Altivec register for double 
load/stores.  */
   RS6000_CONSTRAINT_ww,/* FP or VSX register for vsx float 
ops.  */
   RS6000_CONSTRAINT_wx,/* FPR register for STFIWX */
-  RS6000_CONSTRAINT_wy,/* VSX register for SF */
   RS6000_CONSTRAINT_wz,/* FPR register for LFIWZX */
   RS6000_CONSTRAINT_wA,/* BASE_REGS if 64-bit.  */
   RS6000_CONSTRAINT_wH,/* Altivec register for 32-bit 
integers.  */
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index c5def74..984fe9e 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -530,7 +530,10 @@ (define_mode_attr Fv   [(SF "ww") (DF "ws") 
(DI "wi")])
 ; SF/DF constraint for arithmetic on VSX registers.  This is intended to be
 ; used for DFmode instructions added in ISA 2.06 (power7) and 

[PATCH 4/6] rs6000: Delete the "wu" constraint

[Segher Boessenkool]

This replaces the "wu" constraint by "v", with isa "p8v".  Or, in most
cases, use "wa", since the instructions allow all VSX registers, and it
does not change how GCC behaves, so it is clearer that way.

This also delete the unused .


2019-05-19  Segher Boessenkool  

* config/rs6000/constraints.md (define_register_constraint "wu"):
Delete.
* config/rs6000/rs6000.h (enum r6000_reg_class_enum): Delete
RS6000_CONSTRAINT_wu.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Adjust.
(rs6000_init_hard_regno_mode_ok): Adjust.
* config/rs6000/rs6000.md: Replace "wu" constraint by "v" or "wa",
both with "p8v".
(define_mode_attr Fa): Delete.
* config/rs6000/vsx.md: Ditto.
* doc/md.texi (Machine Constraints): Adjust.

---
 gcc/config/rs6000/constraints.md |  3 ---
 gcc/config/rs6000/rs6000.c   |  4 
 gcc/config/rs6000/rs6000.h   |  1 -
 gcc/config/rs6000/rs6000.md  | 52 +++-
 gcc/doc/md.texi  |  5 +---
 5 files changed, 25 insertions(+), 40 deletions(-)

diff --git a/gcc/config/rs6000/constraints.md b/gcc/config/rs6000/constraints.md
index 38a4307..f9bbb7f 100644
--- a/gcc/config/rs6000/constraints.md
+++ b/gcc/config/rs6000/constraints.md
@@ -109,9 +109,6 @@ (define_register_constraint "ws" 
"rs6000_constraints[RS6000_CONSTRAINT_ws]"
 (define_register_constraint "wt" "rs6000_constraints[RS6000_CONSTRAINT_wt]"
   "VSX vector register to hold 128 bit integer or NO_REGS.")
 
-(define_register_constraint "wu" "rs6000_constraints[RS6000_CONSTRAINT_wu]"
-  "Altivec register to use for float/32-bit int loads/stores  or NO_REGS.")
-
 (define_register_constraint "wv" "rs6000_constraints[RS6000_CONSTRAINT_wv]"
   "Altivec register to use for double loads/stores  or NO_REGS.")
 
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 1a43a8d..7e2dbf9 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -2523,7 +2523,6 @@ rs6000_debug_reg_global (void)
   "wr reg_class = %s\n"
   "ws reg_class = %s\n"
   "wt reg_class = %s\n"
-  "wu reg_class = %s\n"
   "wv reg_class = %s\n"
   "ww reg_class = %s\n"
   "wx reg_class = %s\n"
@@ -2552,7 +2551,6 @@ rs6000_debug_reg_global (void)
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wr]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_ws]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wt]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wu]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wv]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_ww]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wx]],
@@ -3181,7 +3179,6 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
wr - GPR if 64-bit mode is permitted.
ws - Register class to do ISA 2.06 DF operations.
wt - VSX register for TImode in VSX registers.
-   wu - Altivec register for ISA 2.07 VSX SF/SI load/stores.
wv - Altivec register for ISA 2.06 VSX DF/DI load/stores.
ww - Register class to do SF conversions in with VSX operations.
wx - Float register if we can do 32-bit int stores.
@@ -3236,7 +3233,6 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
 
   if (TARGET_P8_VECTOR)/* 
SFmode  */
 {
-  rs6000_constraints[RS6000_CONSTRAINT_wu] = ALTIVEC_REGS;
   rs6000_constraints[RS6000_CONSTRAINT_wy] = VSX_REGS;
   rs6000_constraints[RS6000_CONSTRAINT_ww] = VSX_REGS;
 }
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 85dd841..6d30561 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -1264,7 +1264,6 @@ enum r6000_reg_class_enum {
   RS6000_CONSTRAINT_wr,/* GPR register if 64-bit  */
   RS6000_CONSTRAINT_ws,/* VSX register for DF */
   RS6000_CONSTRAINT_wt,/* VSX register for TImode */
-  RS6000_CONSTRAINT_wu,/* Altivec register for float 
load/stores.  */
   RS6000_CONSTRAINT_wv,/* Altivec register for double 
load/stores.  */
   RS6000_CONSTRAINT_ww,/* FP or VSX register for vsx float 
ops.  */
   RS6000_CONSTRAINT_wx,/* FPR register for STFIWX */
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index b5ccb03..c5def74 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -532,9 +532,6 @@ (define_mode_attr Fv[(SF "ww") (DF "ws") 
(DI "wi")])
 ; instructions added in ISA 2.07 (power8)
 (define_mode_attr Fv2  [(SF "wy") (DF "ws") (DI "wi")])
 
-; SF/DF constraint for arithmetic on altivec registers
-(define_mode_attr Fa   [(SF "wu") (DF "wv")])
-
 ; s/d suffix for things like sdiv/ddiv
 (define_mode_attr Fs

[PATCH 2/6] rs6000: Delete the "wb" constraint

[Segher Boessenkool]

This replaces the "wb" constraint by "v", with isa "p9v".


2019-05-19  Segher Boessenkool  

* config/rs6000/constraints.md (define_register_constraint "wb"):
Delete.
* config/rs6000/rs6000.h (enum r6000_reg_class_enum): Delete
RS6000_CONSTRAINT_wb.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Adjust.
(rs6000_init_hard_regno_mode_ok): Adjust.
* config/rs6000/rs6000.md: Replace "wb" constraint by "v" with "p9v".
* config/rs6000/vsx.md: Ditto.
* doc/md.texi (Machine Constraints): Adjust.

---
 gcc/config/rs6000/constraints.md |  3 --
 gcc/config/rs6000/rs6000.c   |  6 
 gcc/config/rs6000/rs6000.h   |  1 -
 gcc/config/rs6000/rs6000.md  | 76 +---
 gcc/config/rs6000/vsx.md | 10 +++---
 gcc/doc/md.texi  |  3 --
 6 files changed, 45 insertions(+), 54 deletions(-)

diff --git a/gcc/config/rs6000/constraints.md b/gcc/config/rs6000/constraints.md
index c11dc0e..1bbfe71 100644
--- a/gcc/config/rs6000/constraints.md
+++ b/gcc/config/rs6000/constraints.md
@@ -56,9 +56,6 @@ (define_register_constraint "z" "CA_REGS"
 (define_register_constraint "wa" "rs6000_constraints[RS6000_CONSTRAINT_wa]"
   "Any VSX register if the -mvsx option was used or NO_REGS.")
 
-(define_register_constraint "wb" "rs6000_constraints[RS6000_CONSTRAINT_wb]"
-  "Altivec register if the -mpower9-dform option was used or NO_REGS.")
-
 ;; NOTE: For compatibility, "wc" is reserved to represent individual CR bits.
 ;; It is currently used for that purpose in LLVM.
 
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 18fa3ac..f89a86f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -2508,7 +2508,6 @@ rs6000_debug_reg_global (void)
   "f  reg_class = %s\n"
   "v  reg_class = %s\n"
   "wa reg_class = %s\n"
-  "wb reg_class = %s\n"
   "wd reg_class = %s\n"
   "we reg_class = %s\n"
   "wf reg_class = %s\n"
@@ -2540,7 +2539,6 @@ rs6000_debug_reg_global (void)
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_f]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_v]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wa]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wb]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wd]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_we]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wf]],
@@ -3264,10 +3262,6 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
rs6000_constraints[RS6000_CONSTRAINT_wp] = VSX_REGS;/* TFmode  */
 }
 
-  /* Support for new D-form instructions.  */
-  if (TARGET_P9_VECTOR)
-rs6000_constraints[RS6000_CONSTRAINT_wb] = ALTIVEC_REGS;
-
   /* Support for new direct moves (ISA 3.0 + 64bit).  */
   if (TARGET_DIRECT_MOVE_128)
 rs6000_constraints[RS6000_CONSTRAINT_we] = VSX_REGS;
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index d59f4c7..2f2e45f 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -1249,7 +1249,6 @@ enum r6000_reg_class_enum {
   RS6000_CONSTRAINT_f, /* fpr registers for single values */
   RS6000_CONSTRAINT_v, /* Altivec registers */
   RS6000_CONSTRAINT_wa,/* Any VSX register */
-  RS6000_CONSTRAINT_wb,/* Altivec register if ISA 3.0 vector. 
*/
   RS6000_CONSTRAINT_wd,/* VSX register for V2DF */
   RS6000_CONSTRAINT_we,/* VSX register if ISA 3.0 vector. */
   RS6000_CONSTRAINT_wf,/* VSX register for V4SF */
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index c56c585..791aca7 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -477,7 +477,7 @@ (define_mode_attr f64_dm  [(DF "wk") (DD "wh")])
 (define_mode_attr f64_av  [(DF "wv") (DD "wn")])
 
 ; Definitions for 64-bit access to ISA 3.0 (power9) vector
-(define_mode_attr f64_p9  [(DF "wb") (DD "wn")])
+(define_mode_attr f64_p9  [(DF "v") (DD "wn")])
 
 ; These modes do not fit in integer registers in 32-bit mode.
 (define_mode_iterator DIFD [DI DF DD])
@@ -4769,7 +4769,7 @@ (define_expand "extendsfdf2"
 })
 
 (define_insn_and_split "*extendsfdf2_fpr"
-  [(set (match_operand:DF 0 "gpc_reg_operand" "=d,?d,d,ws,?ws,wu,wb")
+  [(set (match_operand:DF 0 "gpc_reg_operand" "=d,?d,d,ws,?ws,wu,v")
(float_extend:DF (match_operand:SF 1 "reg_or_mem_operand" 
"0,f,m,0,wy,Z,wY")))]
   "TARGET_HARD_FLOAT && !HONOR_SNANS (SFmode)"
   "@
@@ -4786,7 +4786,8 @@ (define_insn_and_split "*extendsfdf2_fpr"
   emit_note (NOTE_INSN_DELETED);
   DONE;
 }
-  [(set_attr "type" "fp,fpsimple,fpload,fp,fpsimple,fpload,fpload")])
+  [(set_attr "type" "fp,fpsimple,fpload,fp,fpsimple,fpload,fpload")
+   (set_attr "isa" "*,*,*,*,*,*,p9v")])
 
 (define_insn 

[PATCH 1/6] rs6000: Delete the "wo" constraint

[Segher Boessenkool]

This replaces the "wo" constraint by "wa", with isa "p9v".


2019-05-19  Segher Boessenkool  

* config/rs6000/constraints.md (define_register_constraint "wo"):
Delete.
* config/rs6000/rs6000.h (enum r6000_reg_class_enum): Delete
RS6000_CONSTRAINT_wo.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Adjust.
(rs6000_init_hard_regno_mode_ok): Adjust.
* config/rs6000/rs6000.md: Replace "wo" constraint by "wa" with "p9v".
* config/rs6000/altivec.md: Ditto.
* doc/md.texi (Machine Constraints): Adjust.

---
 gcc/config/rs6000/altivec.md | 54 ++--
 gcc/config/rs6000/constraints.md |  3 ---
 gcc/config/rs6000/rs6000.c   | 11 ++--
 gcc/config/rs6000/rs6000.h   |  1 -
 gcc/config/rs6000/rs6000.md  | 40 +++--
 gcc/config/rs6000/vsx.md | 23 +++--
 gcc/doc/md.texi  |  5 +---
 7 files changed, 75 insertions(+), 62 deletions(-)

diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 4a1150e..b6a22d9 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -2023,28 +2023,30 @@ (define_expand "altivec_vperm_"
 
 ;; Slightly prefer vperm, since the target does not overlap the source
 (define_insn "altivec_vperm__direct"
-  [(set (match_operand:VM 0 "register_operand" "=v,?wo")
-   (unspec:VM [(match_operand:VM 1 "register_operand" "v,wo")
+  [(set (match_operand:VM 0 "register_operand" "=v,?wa")
+   (unspec:VM [(match_operand:VM 1 "register_operand" "v,wa")
(match_operand:VM 2 "register_operand" "v,0")
-   (match_operand:V16QI 3 "register_operand" "v,wo")]
+   (match_operand:V16QI 3 "register_operand" "v,wa")]
   UNSPEC_VPERM))]
   "TARGET_ALTIVEC"
   "@
vperm %0,%1,%2,%3
xxperm %x0,%x1,%x3"
-  [(set_attr "type" "vecperm")])
+  [(set_attr "type" "vecperm")
+   (set_attr "isa" "*,p9v")])
 
 (define_insn "altivec_vperm_v8hiv16qi"
-  [(set (match_operand:V16QI 0 "register_operand" "=v,?wo")
-   (unspec:V16QI [(match_operand:V8HI 1 "register_operand" "v,wo")
+  [(set (match_operand:V16QI 0 "register_operand" "=v,?wa")
+   (unspec:V16QI [(match_operand:V8HI 1 "register_operand" "v,wa")
   (match_operand:V8HI 2 "register_operand" "v,0")
-  (match_operand:V16QI 3 "register_operand" "v,wo")]
+  (match_operand:V16QI 3 "register_operand" "v,wa")]
   UNSPEC_VPERM))]
   "TARGET_ALTIVEC"
   "@
vperm %0,%1,%2,%3
xxperm %x0,%x1,%x3"
-  [(set_attr "type" "vecperm")])
+  [(set_attr "type" "vecperm")
+   (set_attr "isa" "*,p9v")])
 
 (define_expand "altivec_vperm__uns"
   [(set (match_operand:VM 0 "register_operand")
@@ -2062,16 +2064,17 @@ (define_expand "altivec_vperm__uns"
 })
 
 (define_insn "*altivec_vperm__uns_internal"
-  [(set (match_operand:VM 0 "register_operand" "=v,?wo")
-   (unspec:VM [(match_operand:VM 1 "register_operand" "v,wo")
+  [(set (match_operand:VM 0 "register_operand" "=v,?wa")
+   (unspec:VM [(match_operand:VM 1 "register_operand" "v,wa")
(match_operand:VM 2 "register_operand" "v,0")
-   (match_operand:V16QI 3 "register_operand" "v,wo")]
+   (match_operand:V16QI 3 "register_operand" "v,wa")]
   UNSPEC_VPERM_UNS))]
   "TARGET_ALTIVEC"
   "@
vperm %0,%1,%2,%3
xxperm %x0,%x1,%x3"
-  [(set_attr "type" "vecperm")])
+  [(set_attr "type" "vecperm")
+   (set_attr "isa" "*,p9v")])
 
 (define_expand "vec_permv16qi"
   [(set (match_operand:V16QI 0 "register_operand")
@@ -2088,16 +2091,17 @@ (define_expand "vec_permv16qi"
 })
 
 (define_insn "*altivec_vpermr__internal"
-  [(set (match_operand:VM 0 "register_operand" "=v,?wo")
-   (unspec:VM [(match_operand:VM 1 "register_operand" "v,wo")
+  [(set (match_operand:VM 0 "register_operand" "=v,?wa")
+   (unspec:VM [(match_operand:VM 1 "register_operand" "v,wa")
(match_operand:VM 2 "register_operand" "v,0")
-   (match_operand:V16QI 3 "register_operand" "v,wo")]
+   (match_operand:V16QI 3 "register_operand" "v,wa")]
   UNSPEC_VPERMR))]
   "TARGET_P9_VECTOR"
   "@
vpermr %0,%1,%2,%3
xxpermr %x0,%x1,%x3"
-  [(set_attr "type" "vecperm")])
+  [(set_attr "type" "vecperm")
+   (set_attr "isa" "*,p9v")])
 
 (define_insn "altivec_vrfip"   ; ceil
   [(set (match_operand:V4SF 0 "register_operand" "=v")
@@ -3245,28 +3249,30 @@ (define_expand "vec_unpacks_lo_"
   "")
 
 (define_insn "vperm_v8hiv4si"
-  [(set (match_operand:V4SI 0 "register_operand" "=v,?wo")
-(unspec:V4SI [(match_operand:V8HI 1 "register_operand" "v,wo")
+  [(set (match_operand:V4SI 0 "register_operand" "=v,?wa")
+(unspec:V4SI [(match_operand:V8HI 1 "register_operand" "v,wa")
  (match_operand:V4SI 2 

[PATCH 3/6] rs6000: Delete "wJ" and "wK" constraints

[Segher Boessenkool]

This replaces "wJ" by "wI", and "wK by "wH", both with isa "p9v".


2019-05-19  Segher Boessenkool  

* config/rs6000/constraints.md (define_register_constraint "wJ"):
Delete.
(define_register_constraint "wK"): Delete.
* config/rs6000/rs6000.h (enum r6000_reg_class_enum): Delete
RS6000_CONSTRAINT_wJ and RS6000_CONSTRAINT_wK.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Adjust.
(rs6000_init_hard_regno_mode_ok): Adjust.
* config/rs6000/rs6000.md: Replace "wJ" constraint by "wI" with "p9v".
Replace "wK" constraint by "wH" with "p9v".
* config/rs6000/vsx.md: Ditto.
* doc/md.texi (Machine Constraints): Adjust.

---
 gcc/config/rs6000/constraints.md |   6 --
 gcc/config/rs6000/rs6000.c   |  15 +
 gcc/config/rs6000/rs6000.h   |   2 -
 gcc/config/rs6000/rs6000.md  | 126 ++-
 gcc/config/rs6000/vsx.md |  39 +++-
 gcc/doc/md.texi  |   6 --
 6 files changed, 95 insertions(+), 99 deletions(-)

diff --git a/gcc/config/rs6000/constraints.md b/gcc/config/rs6000/constraints.md
index 1bbfe71..38a4307 100644
--- a/gcc/config/rs6000/constraints.md
+++ b/gcc/config/rs6000/constraints.md
@@ -157,12 +157,6 @@ (define_register_constraint "wH" 
"rs6000_constraints[RS6000_CONSTRAINT_wH]"
 (define_register_constraint "wI" "rs6000_constraints[RS6000_CONSTRAINT_wI]"
   "FPR register to hold 32-bit integers or NO_REGS.")
 
-(define_register_constraint "wJ" "rs6000_constraints[RS6000_CONSTRAINT_wJ]"
-  "FPR register to hold 8/16-bit integers or NO_REGS.")
-
-(define_register_constraint "wK" "rs6000_constraints[RS6000_CONSTRAINT_wK]"
-  "Altivec register to hold 8/16-bit integers or NO_REGS.")
-
 (define_constraint "wL"
   "Int constant that is the element number mfvsrld accesses in a vector."
   (and (match_code "const_int")
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index f89a86f..1a43a8d 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -2532,8 +2532,6 @@ rs6000_debug_reg_global (void)
   "wA reg_class = %s\n"
   "wH reg_class = %s\n"
   "wI reg_class = %s\n"
-  "wJ reg_class = %s\n"
-  "wK reg_class = %s\n"
   "\n",
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_d]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_f]],
@@ -2562,9 +2560,7 @@ rs6000_debug_reg_global (void)
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wz]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wA]],
   reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wH]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wI]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wJ]],
-  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wK]]);
+  reg_class_names[rs6000_constraints[RS6000_CONSTRAINT_wI]]);
 
   nl = "\n";
   for (m = 0; m < NUM_MACHINE_MODES; ++m)
@@ -3192,9 +3188,7 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
wy - Register class to do ISA 2.07 SF operations.
wz - Float register if we can do 32-bit unsigned int loads.
wH - Altivec register if SImode is allowed in VSX registers.
-   wI - Float register if SImode is allowed in VSX registers.
-   wJ - Float register if QImode/HImode are allowed in VSX registers.
-   wK - Altivec register if QImode/HImode are allowed in VSX registers.  */
+   wI - Float register if SImode is allowed in VSX registers.  */
 
   if (TARGET_HARD_FLOAT)
 {
@@ -3271,11 +3265,6 @@ rs6000_init_hard_regno_mode_ok (bool global_init_p)
 {
   rs6000_constraints[RS6000_CONSTRAINT_wH] = ALTIVEC_REGS;
   rs6000_constraints[RS6000_CONSTRAINT_wI] = FLOAT_REGS;
-  if (TARGET_P9_VECTOR)
-   {
- rs6000_constraints[RS6000_CONSTRAINT_wJ] = FLOAT_REGS;
- rs6000_constraints[RS6000_CONSTRAINT_wK] = ALTIVEC_REGS;
-   }
 }
 
   /* Set up the reload helper and direct move functions.  */
diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
index 2f2e45f..85dd841 100644
--- a/gcc/config/rs6000/rs6000.h
+++ b/gcc/config/rs6000/rs6000.h
@@ -1273,8 +1273,6 @@ enum r6000_reg_class_enum {
   RS6000_CONSTRAINT_wA,/* BASE_REGS if 64-bit.  */
   RS6000_CONSTRAINT_wH,/* Altivec register for 32-bit 
integers.  */
   RS6000_CONSTRAINT_wI,/* VSX register for 32-bit integers.  */
-  RS6000_CONSTRAINT_wJ,/* VSX register for 8/16-bit integers.  
*/
-  RS6000_CONSTRAINT_wK,/* Altivec register for 16/32-bit 
integers.  */
   RS6000_CONSTRAINT_MAX
 };
 
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 791aca7..b5ccb03 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -726,15 +726,16 @@ (define_mode_iterator ALTIVEC_DFORM [DF
 ;; 

[PATCH 0/6] rs6000: Use the "enabled" attribute, first batch

[Segher Boessenkool]

This is the first batch of patches using the "enabled" and "isa"
attributes.  Tested on Power7 powerpc64-linux {-m32,-m64}, and on
Power9 powerpc64le-linux.  Committing to trunk.


Segher


Segher Boessenkool (6):
  rs6000: Delete the "wo" constraint
  rs6000: Delete the "wb" constraint
  rs6000: Delete "wJ" and "wK" constraints
  rs6000: Delete the "wu" constraint
  rs6000: Delete the "wy" constraint
  rs6000: Delete the "wH" and "wI" constraints

 gcc/config/rs6000/altivec.md |  54 +++---
 gcc/config/rs6000/constraints.md |  24 ---
 gcc/config/rs6000/rs6000.c   |  53 +-
 gcc/config/rs6000/rs6000.h   |   8 -
 gcc/config/rs6000/rs6000.md  | 364 ++-
 gcc/config/rs6000/vsx.md |  82 +
 gcc/doc/md.texi  |  28 +--
 7 files changed, 290 insertions(+), 323 deletions(-)

-- 
1.8.3.1

C++ PATCH for c++/85679 and CWG 2094 - volatile scalars are trivially copyable

[Marek Polacek]

CWG 2094 partially reverts CWG 496, which means that volatile-qualified scalars
are, once again, trivially copyable; [basic.types] now says "Scalar types,
trivially copyable class types, arrays of such types, and cv-qualified
versions of these types are collectively called trivially copyable types."

This previously changed in c++/63959 and this patch pretty much just reverts it.

I'm CCing libstdc++ because a test in libstdc++ needed updating.

Links to aforementioned CWGs:



Bootstrapped/regtested on x86_64-linux, ok for trunk?  Not planning to backport
this.

2019-05-19  Marek Polacek  

CWG 2094 - volatile scalars are trivially copyable.
PR c++/85679
* tree.c (trivially_copyable_p): Don't check CP_TYPE_VOLATILE_P for
scalar types.

* g++.dg/ext/is_trivially_constructible1.C: Change the expected result
for volatile int.
* g++.dg/ext/is_trivially_copyable.C: New test.

* testsuite/20_util/is_trivially_copyable/value.cc: Change the expected
result for volatile int.

diff --git gcc/gcc/cp/tree.c gcc/gcc/cp/tree.c
index 8d7f7a2c3e7..821f2b79a67 100644
--- gcc/gcc/cp/tree.c
+++ gcc/gcc/cp/tree.c
@@ -4098,7 +4098,8 @@ trivially_copyable_p (const_tree t)
&& !TYPE_HAS_COMPLEX_MOVE_ASSIGN (t)
&& TYPE_HAS_TRIVIAL_DESTRUCTOR (t));
   else
-return !CP_TYPE_VOLATILE_P (t) && scalarish_type_p (t);
+/* CWG 2094 makes volatile-qualified scalars trivially copyable.  */
+return scalarish_type_p (t);
 }
 
 /* Returns 1 iff type T is a trivial type, as defined in [basic.types] and
diff --git gcc/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C 
gcc/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
index 191b69601e6..d28f2f7b24e 100644
--- gcc/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
+++ gcc/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
@@ -48,7 +48,9 @@ SA(!__is_trivially_constructible(int*, const int*));
 SA(!__is_trivially_constructible(D));
 
 SA(__is_trivially_copyable(int));
-SA(!__is_trivially_copyable(volatile int));
+// Changed in CWG 2094, which made volatile-qualified scalars trivially
+// copyable.
+SA(__is_trivially_copyable(volatile int));
 
 struct E1 {const int val;};
 SA(__is_trivially_copyable(E1));
diff --git gcc/gcc/testsuite/g++.dg/ext/is_trivially_copyable.C 
gcc/gcc/testsuite/g++.dg/ext/is_trivially_copyable.C
new file mode 100644
index 000..6f93602c8c2
--- /dev/null
+++ gcc/gcc/testsuite/g++.dg/ext/is_trivially_copyable.C
@@ -0,0 +1,16 @@
+// CWG 2094 - volatile scalars are trivially copyable.
+// PR c++/85679
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert((X),#X)
+
+struct S{};
+
+SA(__is_trivially_copyable(S volatile));
+SA(__is_trivially_copyable(S volatile[]));
+SA(__is_trivially_copyable(S const volatile));
+SA(__is_trivially_copyable(S const volatile[]));
+SA(__is_trivially_copyable(int volatile));
+SA(__is_trivially_copyable(int volatile[]));
+SA(__is_trivially_copyable(int const volatile));
+SA(__is_trivially_copyable(int const volatile[]));
diff --git gcc/libstdc++-v3/testsuite/20_util/is_trivially_copyable/value.cc 
gcc/libstdc++-v3/testsuite/20_util/is_trivially_copyable/value.cc
index cce620daf4d..022f0c0b248 100644
--- gcc/libstdc++-v3/testsuite/20_util/is_trivially_copyable/value.cc
+++ gcc/libstdc++-v3/testsuite/20_util/is_trivially_copyable/value.cc
@@ -46,8 +46,10 @@ void test01()
 
   static_assert(test_property(true), "");
+  // Changed in CWG 2094, which made volatile-qualified scalars trivially
+  // copyable.
   static_assert(test_property(false), "");
+   volatile int>(true), "");
   static_assert(test_property(true), "");
   static_assert(test_property

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Marek Polacek]

On Sun, May 19, 2019 at 01:00:45PM -0700, Andrew Pinski wrote:
> On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
>  wrote:
> >
> > On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> > > On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > > > On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > > > > Do we really need a commit integer numbers after the transition? I 
> > > > > know
> > > > > we're used to it.
> > > > > But git commit hash provides that same.
> > > >
> > > > Revision numbers are nice short text strings, and from a revision number
> > > > you can see approximately when it happened, and from two revision 
> > > > numbers
> > > > on the same branch you can trivially tell which one is older.  Those are
> > > > nice features.  But we can live without it, IMO.
> > >
> > > Since I do many bisections a day, losing this capability would be Very 
> > > Bad.
> > > Without it, there's no range, and without a range, there's nothing to 
> > > _bisect_.
> > >
> > > I bisect by hand, so if I have cc1plus.25 (good) and cc1plus.26 
> > > (bad),
> > > I know the commit I'm looking for is within that range, and I can easily 
> > > split
> > > the range, and it's at most log n steps.  Whereas if we had e.g. 
> > > cc1plus.de28b0
> > > and cc1plus.a9bd4d, I couldn't do it anymore.
> >
> > Git can bisect automatically just fine, there is no upside to doing things
> > manually.  In git there are various handy ways of referring to commits; you
> > can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
> > commit back on branch "zut", etc.  See "man gitrevisions".
> 
> Well one thing is if you have prebuilt cc1/cc1plus.  So it is not
> really doing a manual bisect per-say but rather it is doing a manual
> bisect using prebuilt binaries and knowing which one comes before
> which one.

Exactly, we have many TBs of prebuilt binaries.

> One way is store the binaries based on the date that commit happened
> instead.  This is a bit more complex but still doable.

Yeah, I guess we'll have to do something like that, then.  :/

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

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Andrew Pinski]

On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
 wrote:
>
> On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> > On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > > On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > > > Do we really need a commit integer numbers after the transition? I know
> > > > we're used to it.
> > > > But git commit hash provides that same.
> > >
> > > Revision numbers are nice short text strings, and from a revision number
> > > you can see approximately when it happened, and from two revision numbers
> > > on the same branch you can trivially tell which one is older.  Those are
> > > nice features.  But we can live without it, IMO.
> >
> > Since I do many bisections a day, losing this capability would be Very Bad.
> > Without it, there's no range, and without a range, there's nothing to 
> > _bisect_.
> >
> > I bisect by hand, so if I have cc1plus.25 (good) and cc1plus.26 
> > (bad),
> > I know the commit I'm looking for is within that range, and I can easily 
> > split
> > the range, and it's at most log n steps.  Whereas if we had e.g. 
> > cc1plus.de28b0
> > and cc1plus.a9bd4d, I couldn't do it anymore.
>
> Git can bisect automatically just fine, there is no upside to doing things
> manually.  In git there are various handy ways of referring to commits; you
> can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
> commit back on branch "zut", etc.  See "man gitrevisions".

Well one thing is if you have prebuilt cc1/cc1plus.  So it is not
really doing a manual bisect per-say but rather it is doing a manual
bisect using prebuilt binaries and knowing which one comes before
which one.
One way is store the binaries based on the date that commit happened
instead.  This is a bit more complex but still doable.

Thanks,
Andrew Pinski

>
>
> Segher

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > > Do we really need a commit integer numbers after the transition? I know 
> > > we're used to it.
> > > But git commit hash provides that same.
> > 
> > Revision numbers are nice short text strings, and from a revision number
> > you can see approximately when it happened, and from two revision numbers
> > on the same branch you can trivially tell which one is older.  Those are
> > nice features.  But we can live without it, IMO.
> 
> Since I do many bisections a day, losing this capability would be Very Bad.
> Without it, there's no range, and without a range, there's nothing to 
> _bisect_.
> 
> I bisect by hand, so if I have cc1plus.25 (good) and cc1plus.26 (bad),
> I know the commit I'm looking for is within that range, and I can easily split
> the range, and it's at most log n steps.  Whereas if we had e.g. 
> cc1plus.de28b0
> and cc1plus.a9bd4d, I couldn't do it anymore.

Git can bisect automatically just fine, there is no upside to doing things
manually.  In git there are various handy ways of referring to commits; you
can say  master@{3 days ago}  for example, or zut@{31}  to get the 31st
commit back on branch "zut", etc.  See "man gitrevisions".


Segher

Re: [PATCH] libfortran/90038 Reap dead children when wait=.false.

[Janne Blomqvist]

On Sun, May 19, 2019 at 9:26 PM Steve Kargl
 wrote:
>
> On Sun, May 19, 2019 at 09:10:57PM +0300, Janne Blomqvist wrote:
> > On Sun, May 19, 2019 at 7:15 PM Steve Kargl
> >  wrote:
> > >
> > > On Sun, May 19, 2019 at 01:40:59PM +0300, Janne Blomqvist wrote:
> > > >
> > > > +#if defined(HAVE_SIGACTION) && defined(HAVE_WAITPID)
> > > > +  static bool sig_init_saved;
> > > > +  bool sig_init = __atomic_load_n (_init_saved, 
> > > > __ATOMIC_RELAXED);
> > > > +  if (!sig_init)
> > > > + {
> > > > +   struct sigaction sa;
> > > > +   sa.sa_handler = _handler;
> > > > +   sigemptyset(_mask);
> > > > +   sa.sa_flags = SA_RESTART | SA_NOCLDSTOP;
> > > > +   sigaction(SIGCHLD, , 0);
> > > > +   __atomic_store_n (_init_saved, true, __ATOMIC_RELAXED);
> > > > + }
> > > > +#endif
> > >
> > > Where do the prototypes for __atomic_load_n and __atomic_store_n
> > > come from?  On FreeBSD, it seems these are in stdatomic.h.  Do
> > > we need a HAVE_ATOMIC to include the header?
> >
> > They are GCC atomic builtins, they are always available, no need to
> > include a header:
> > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
>
> Thanks for the clarification.  OK for trunk.

Thanks, committed as r271384.

> > > On a slightly different note, the nonstandard SYSTEM intrinsic
> > > uses system(3) to execute a command.  I believe that it will
> > > leave zombies/orphaned children if a process is interrupted.
> > > Perhap, SYSTEM should be reworked to use your EXECUTE_COMMAND_LINE.
> >
> > I believe any competent implementation of system() would wait for the
> > child process. Since system() is synchronous, it can do the waiting
> > inline without having to use a signal handler.
>
> I'll need to check.  I recall that
>
> program foo
>call system("Something_that_takes_along_time_to_execute")
> end program foo
>
> gfortran -o foo foo.f90
>
> % foo
> ^C
>
> Results in termination of the parent foo, and
> Something_that_takes_along_time_to_execute is orphaned and
> continues to run.  It would probably be better to deliver
> SIGKILL to child.  I suppose that that is for another day.

I guess the expected behavior is that is the parent dies, the child
gets orphaned and thus re-parented to PID 1 (that is, init) which
takes care of wait()'ing for it so it's not left as a zombie when it
dies. Not sure it's possible to change this is a robust and portable
way. But if someone figures it out, we can think about it then.



-- 
Janne Blomqvist

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Andreas Schwab]

On Mai 19 2019, Marek Polacek  wrote:

> On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
>> On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
>> > Do we really need a commit integer numbers after the transition? I know 
>> > we're used to it.
>> > But git commit hash provides that same.
>> 
>> Revision numbers are nice short text strings, and from a revision number
>> you can see approximately when it happened, and from two revision numbers
>> on the same branch you can trivially tell which one is older.  Those are
>> nice features.  But we can live without it, IMO.
>
> Since I do many bisections a day, losing this capability would be Very Bad.
> Without it, there's no range, and without a range, there's nothing to 
> _bisect_.

What's wrong with git bisect?  It does everything you need.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Marek Polacek]

On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > Do we really need a commit integer numbers after the transition? I know 
> > we're used to it.
> > But git commit hash provides that same.
> 
> Revision numbers are nice short text strings, and from a revision number
> you can see approximately when it happened, and from two revision numbers
> on the same branch you can trivially tell which one is older.  Those are
> nice features.  But we can live without it, IMO.

Since I do many bisections a day, losing this capability would be Very Bad.
Without it, there's no range, and without a range, there's nothing to _bisect_.

I bisect by hand, so if I have cc1plus.25 (good) and cc1plus.26 (bad),
I know the commit I'm looking for is within that range, and I can easily split
the range, and it's at most log n steps.  Whereas if we had e.g. cc1plus.de28b0
and cc1plus.a9bd4d, I couldn't do it anymore.

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

State of the reposurgeon conversion

[Eric S. Raymond]

First, my apologies for not responding five days ago. Joseph's mail
issued as I was transitioning to a new machine and the day before I
spent some hours in the ER of my local hospital, and I missed it in
the confusion.

In case you missed it on the main list, git-svn is *not safe* for
histories within even three orders of magnitude of ggc's complexity.
See

http://esr.ibiblio.org/?p=6778

for the PSA I wrote last time I heard about an attempt to use it for
an important conversion.

Joseph Myers wrote:
>ESR, can you give an update on the status of the conversion with 
>reposurgeon?  You said "another serious attack on the repository 
>conversion is probably about two months out" in 
>.  Is it on target to be 
>done by the time of the GNU Tools Cauldron in Montreal in September?

I'd say that's about a 65% chance.  Better than even, not high enough for
me to make any hard promises.

I just took delivery of a newer, faster surgical machine - an AMD
Threadripper cranking 4.2Ghz on 64 hardware threads (thank you,
System76 for the donation). I upgraded specifically to tackle the GCC
problem.  Early benchmarks on repocutter-in-Go suggest I'll get at
least a 15x speedup relative to the Python version of reposurgeon,
possibly rather more.  That should reduce test conversion cycles to
less than an hour, which ought to be fast enough that I can converge
on a solution in reasonable time.

The main source of uncertainty here is how long it will take me to
finish the Go translation of reposurgeon. Once that's done I don't
expect a finished conversion to take more than a couple of weeks to
produce. The good news is the translation is now over 90% done; the bad
news is that the part still pending includes the part you really care
about, the Subversion dump interpreter.

I realize this may not be the best place to ask, but the most
effective way to speed things up would be to second me somebody with
Go skills to help with finishing and debugging the translation. The
blocker is not Go knowledge per se, it's the intrinsic complexity of
the code I'm translating. Even with my skills and domain expertise
this is a tough job.

I will further add that a really motivated expert C programmer would do
for the help. Go is an easy enough transition for a C expert that it would
be practical to learn the language while assisting with this.

>And, could you bring git://thyrsus.com/repositories/gcc-conversion.git up 
>to date with changes since Jan 2018, or push the latest version of that 
>repository to some other public hosting location?

Done.

https://gitlab.com/esr/gcc-conversion

Interested parties here can have dev permissions if they like.

>  That repository 
>represents what I consider the collaboratively built consensus on such 
>things as the desired author map (including handling of the ambiguous 
>author name), which directories represent branches and tags, and what tags 
>should be kept or removed - but building up such a consensus and keeping 
>it up to date over time (for new committers etc.) requires that the public 
>repository actually reflects the latest version of the conversion 
>machinery, day by day as the consensus develops.  Review of that 
>repository will be important for reviewing the details of whether the 
>conversion is being done as desired - the details of the machinery will 
>help suggest things to spot-check in a converted repository.

I concur totally with that philosophy.

(About that ER visit: I'll be OK.  I have an injury called an
osteochondral lesion in my right angle resulting from an ankle sprain
in kung fu class, with arthroscopic surgery scheduled to correct it in
June.  On the 15th my ankle gave out while I was cooking breakfast; I
fell down and hit my head on a chair leg. A short but expensive visit
to the ER later I had three staples in my scalp and an MRI showing no
brain damage. That could have gone far worse; joke about this if you
like but we should all be thankful that I happen to have a rather
thicker, tougher skull than average.)
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: [PATCH] libfortran/90038 Reap dead children when wait=.false.

[Steve Kargl]

On Sun, May 19, 2019 at 09:10:57PM +0300, Janne Blomqvist wrote:
> On Sun, May 19, 2019 at 7:15 PM Steve Kargl
>  wrote:
> >
> > On Sun, May 19, 2019 at 01:40:59PM +0300, Janne Blomqvist wrote:
> > >
> > > +#if defined(HAVE_SIGACTION) && defined(HAVE_WAITPID)
> > > +  static bool sig_init_saved;
> > > +  bool sig_init = __atomic_load_n (_init_saved, 
> > > __ATOMIC_RELAXED);
> > > +  if (!sig_init)
> > > + {
> > > +   struct sigaction sa;
> > > +   sa.sa_handler = _handler;
> > > +   sigemptyset(_mask);
> > > +   sa.sa_flags = SA_RESTART | SA_NOCLDSTOP;
> > > +   sigaction(SIGCHLD, , 0);
> > > +   __atomic_store_n (_init_saved, true, __ATOMIC_RELAXED);
> > > + }
> > > +#endif
> >
> > Where do the prototypes for __atomic_load_n and __atomic_store_n
> > come from?  On FreeBSD, it seems these are in stdatomic.h.  Do
> > we need a HAVE_ATOMIC to include the header?
> 
> They are GCC atomic builtins, they are always available, no need to
> include a header:
> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

Thanks for the clarification.  OK for trunk.

> > On a slightly different note, the nonstandard SYSTEM intrinsic
> > uses system(3) to execute a command.  I believe that it will
> > leave zombies/orphaned children if a process is interrupted.
> > Perhap, SYSTEM should be reworked to use your EXECUTE_COMMAND_LINE.
> 
> I believe any competent implementation of system() would wait for the
> child process. Since system() is synchronous, it can do the waiting
> inline without having to use a signal handler.

I'll need to check.  I recall that

program foo
   call system("Something_that_takes_along_time_to_execute")
end program foo

gfortran -o foo foo.f90

% foo
^C

Results in termination of the parent foo, and
Something_that_takes_along_time_to_execute is orphaned and
continues to run.  It would probably be better to deliver
SIGKILL to child.  I suppose that that is for another day.

-- 
Steve

Re: [PATCH] libfortran/90038 Reap dead children when wait=.false.

[Janne Blomqvist]

On Sun, May 19, 2019 at 7:15 PM Steve Kargl
 wrote:
>
> On Sun, May 19, 2019 at 01:40:59PM +0300, Janne Blomqvist wrote:
> >
> > +#if defined(HAVE_SIGACTION) && defined(HAVE_WAITPID)
> > +  static bool sig_init_saved;
> > +  bool sig_init = __atomic_load_n (_init_saved, __ATOMIC_RELAXED);
> > +  if (!sig_init)
> > + {
> > +   struct sigaction sa;
> > +   sa.sa_handler = _handler;
> > +   sigemptyset(_mask);
> > +   sa.sa_flags = SA_RESTART | SA_NOCLDSTOP;
> > +   sigaction(SIGCHLD, , 0);
> > +   __atomic_store_n (_init_saved, true, __ATOMIC_RELAXED);
> > + }
> > +#endif
>
> Where do the prototypes for __atomic_load_n and __atomic_store_n
> come from?  On FreeBSD, it seems these are in stdatomic.h.  Do
> we need a HAVE_ATOMIC to include the header?

They are GCC atomic builtins, they are always available, no need to
include a header:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

> On a slightly different note, the nonstandard SYSTEM intrinsic
> uses system(3) to execute a command.  I believe that it will
> leave zombies/orphaned children if a process is interrupted.
> Perhap, SYSTEM should be reworked to use your EXECUTE_COMMAND_LINE.

I believe any competent implementation of system() would wait for the
child process. Since system() is synchronous, it can do the waiting
inline without having to use a signal handler.

-- 
Janne Blomqvist

New Swedish PO file for 'gcc' (version 9.1.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[i386] Fold __builtin_ia32_shufpd to VEC_PERM_EXPR

[Marc Glisse]

Hello,

dropping the builtin as early as possible seems like it can only help us 
optimize the code. Jakub suggested in the PR that he liked this approach 
better than using __builtin_shuffle in the header. There is already some 
coverage in the testsuite (as I noticed when I tried to restrict the 
argument to [0, 3]...).


If this one is ok, I may add a few more (say shufps to begin with) later.

Bootstrap+regtest on x86_64-pc-linux-gnu.

2019-05-20  Marc Glisse  

PR rtl-optimization/43147
* config/i386/i386.c (ix86_gimple_fold_builtin): Handle
IX86_BUILTIN_SHUFPD.


--
Marc GlisseIndex: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 271376)
+++ gcc/config/i386/i386.c  (working copy)
@@ -17290,21 +17290,21 @@ ix86_fold_builtin (tree fndecl, int n_ar
 
 bool
 ix86_gimple_fold_builtin (gimple_stmt_iterator *gsi)
 {
   gimple *stmt = gsi_stmt (*gsi);
   tree fndecl = gimple_call_fndecl (stmt);
   gcc_checking_assert (fndecl && fndecl_built_in_p (fndecl, BUILT_IN_MD));
   int n_args = gimple_call_num_args (stmt);
   enum ix86_builtins fn_code = (enum ix86_builtins) DECL_FUNCTION_CODE 
(fndecl);
   tree decl = NULL_TREE;
-  tree arg0, arg1;
+  tree arg0, arg1, arg2;
   enum rtx_code rcode;
   unsigned HOST_WIDE_INT count;
   bool is_vshift;
 
   switch (fn_code)
 {
 case IX86_BUILTIN_TZCNT32:
   decl = builtin_decl_implicit (BUILT_IN_CTZ);
   goto fold_tzcnt_lzcnt;
 
@@ -17594,20 +17594,46 @@ ix86_gimple_fold_builtin (gimple_stmt_it
 arithmetic right shift the result is zero.  */
  location_t loc = gimple_location (stmt);
  gimple *g = gimple_build_assign (gimple_call_lhs (stmt),
   build_zero_cst (TREE_TYPE (arg0)));
  gimple_set_location (g, loc);
  gsi_replace (gsi, g, false);
  return true;
}
   break;
 
+case IX86_BUILTIN_SHUFPD:
+  arg2 = gimple_call_arg (stmt, 2);
+  if (TREE_CODE (arg2) == INTEGER_CST)
+   {
+ location_t loc = gimple_location (stmt);
+ unsigned HOST_WIDE_INT imask = TREE_INT_CST_LOW (arg2);
+ arg0 = gimple_call_arg (stmt, 0);
+ arg1 = gimple_call_arg (stmt, 1);
+ tree itype = long_long_integer_type_node;
+ tree vtype = build_vector_type (itype, 2); /* V2DI */
+ tree_vector_builder elts (vtype, 2, 1);
+ /* Ignore bits other than the lowest 2.  */
+ elts.quick_push (build_int_cst (itype, imask & 1));
+ imask >>= 1;
+ elts.quick_push (build_int_cst (itype, 2 + (imask & 1)));
+ tree omask = elts.build ();
+ gimple *g = gimple_build_assign (gimple_call_lhs (stmt),
+  VEC_PERM_EXPR,
+  arg0, arg1, omask);
+ gimple_set_location (g, loc);
+ gsi_replace (gsi, g, false);
+ return true;
+   }
+  // Do not error yet, the constant could be propagated later?
+  break;
+
 default:
   break;
 }
 
   return false;
 }
 
 /* Handler for an SVML-style interface to
a library with vectorized intrinsics.  */
 

[PATCH, committed] Update my email address in MAINTAINERS

[Peter Bergner]

I committed the following to update my email address.

Peter

* MAINTAINERS: Update my email address.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 271381)
+++ MAINTAINERS (revision 271382)
@@ -286,7 +286,7 @@ loop optimizer  Zdenek Dvorak   

 LTO plugin Cary Coutant
 Plugin Le-Chun Wu  
-register allocationPeter Bergner   
+register allocationPeter Bergner   
 register allocationKenneth Zadeck  
 register allocationSeongbae Park   
 RTL optimizers Steven Bosscher 

Tweak gcc.dg/torture/pta-ptrarith-3.c

[Marc Glisse]

Hello,

this patch lets the test match q_10, which can happen if you modify gcc a 
bit... It seems better to me to improve the test now, but if you think it 
is better that I wait until I have a gcc patch that actually requires it, 
that's fine with me as well.


gcc/testsuite/

2019-05-20  Marc Glisse  

* gcc.dg/torture/pta-ptrarith-3.c: Relax the matched pattern.

--
Marc GlisseIndex: gcc/testsuite/gcc.dg/torture/pta-ptrarith-3.c
===
--- gcc/testsuite/gcc.dg/torture/pta-ptrarith-3.c   (revision 271376)
+++ gcc/testsuite/gcc.dg/torture/pta-ptrarith-3.c   (working copy)
@@ -26,11 +26,11 @@ int main()
 {
   if (foo(1, 2, 3, -1) != 1)
 abort ();
   if (foo(1, 2, 3, 0) != 2)
 abort ();
   if (foo(1, 2, 3, 1) != 3)
 abort ();
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "q_. = { i j k }" "alias" } } */
+/* { dg-final { scan-tree-dump "q_\[0-9\]* = { i j k }" "alias" } } */

apply unary op to both sides of (vec_cond x cst1 cst2)

[Marc Glisse]

Hello,

I noticed this one with BIT_NOT_EXPR a while ago. C++ testcase because I 
haven't looked at gimplefe yet...


2019-05-20  Marc Glisse  

gcc/
* match.pd (~(vec?cst1:cst2)); New transformation.

gcc/testsuite/
* g++.dg/tree-ssa/cprop-vcond.C

--
Marc GlisseIndex: gcc/match.pd
===
--- gcc/match.pd(revision 271376)
+++ gcc/match.pd(working copy)
@@ -2911,20 +2913,26 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
@2)
   (if (!VOID_TYPE_P (TREE_TYPE (@1)) || VOID_TYPE_P (type))
@1)))
 (simplify
  (vec_cond VECTOR_CST@0 @1 @2)
  (if (integer_all_onesp (@0))
   @1
   (if (integer_zerop (@0))
@2)))
 
+/* Sink unary operations to constant branches.  */
+(for op (negate bit_not abs absu)
+ (simplify
+  (op (vec_cond @0 VECTOR_CST@1 VECTOR_CST@2))
+  (vec_cond @0 (op @1) (op @2
+
 /* Simplification moved from fold_cond_expr_with_comparison.  It may also
be extended.  */
 /* This pattern implements two kinds simplification:
 
Case 1)
(cond (cmp (convert1? x) c1) (convert2? x) c2) -> (minmax (x c)) if:
  1) Conversions are type widening from smaller type.
  2) Const c1 equals to c2 after canonicalizing comparison.
  3) Comparison has tree code LT, LE, GT or GE.
This specific pattern is needed when (cmp (convert x) c) may not
Index: gcc/testsuite/g++.dg/tree-ssa/cprop-vcond.C
===
--- gcc/testsuite/g++.dg/tree-ssa/cprop-vcond.C (nonexistent)
+++ gcc/testsuite/g++.dg/tree-ssa/cprop-vcond.C (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-forwprop1-raw" } */
+
+typedef long vec __attribute__((vector_size(2*sizeof(long;
+void f(vec*v){
+  vec t = { 5, 16 };
+  vec f = { 27, -11 };
+  vec r = *v ? t : f;
+  *v = -r;
+}
+
+/* { dg-final { scan-tree-dump-not "negate_expr" "forwprop1" } } */

Simplify more EXACT_DIV_EXPR comparisons

[Marc Glisse]

Hello,

2 pieces:

- the first one handles the case where the denominator is negative. It 
doesn't happen often with exact_div, so I don't handle it everywhere, but 
this one looked trivial


- handle the case where a pointer difference is cast to an unsigned type 
before being compared to a constant (I hit this in std::vector). With some 
range info we could probably handle some non-constant cases as well...


The second piece breaks Walloca-13.c (-Walloca-larger-than=100 -O2)

void f (void*);
void g (int *p, int *q)
{
  __SIZE_TYPE__ n = (__SIZE_TYPE__)(p - q);
  if (n < 100)
f (__builtin_alloca (n));
}

At the time of walloca2, we have

  _1 = p_5(D) - q_6(D);
  # RANGE [-2305843009213693952, 2305843009213693951]
  _2 = _1 /[ex] 4;
  # RANGE ~[2305843009213693952, 16140901064495857663]
  n_7 = (long unsigned intD.10) _2;
  _11 = (long unsigned intD.10) _1;
  if (_11 <= 396)
[...]
  _3 = allocaD.1059 (n_7);

and warn. However, DOM3 later produces

  _1 = p_5(D) - q_6(D);
  _11 = (long unsigned intD.10) _1;
  if (_11 <= 396)
[...]
  # RANGE [0, 99] NONZERO 127
  _2 = _1 /[ex] 4;
  # RANGE [0, 99] NONZERO 127
  n_7 = (long unsigned intD.10) _2;
  _3 = allocaD.1059 (n_7);

so I am tempted to say that the walloca2 pass is too early, xfail the 
testcase and file an issue...


A single_use restriction would also probably fix this testcase, but I 
don't think that's a good idea, the new code is better because the 
division is now in the branch.


2019-05-20  Marc Glisse  

gcc/
* match.pd (X/[ex]DIndex: gcc/match.pd
===
--- gcc/match.pd(revision 271376)
+++ gcc/match.pd(working copy)
@@ -1490,21 +1490,23 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& (wi::to_wide (@2)
== wi::max_value (TYPE_PRECISION (TREE_TYPE (@0)), SIGNED) - 1))
 (with { tree stype = signed_type_for (TREE_TYPE (@0)); }
  (icmp (convert:stype @0) { build_int_cst (stype, 0); })
 
 /* X / 4 < Y / 4 iff X < Y when the division is known to be exact.  */
 (for cmp (simple_comparison)
  (simplify
   (cmp (exact_div @0 INTEGER_CST@2) (exact_div @1 @2))
   (if (wi::gt_p (wi::to_wide (@2), 0, TYPE_SIGN (TREE_TYPE (@2
-   (cmp @0 @1
+   (cmp @0 @1)
+   (if (wi::lt_p (wi::to_wide (@2), 0, TYPE_SIGN (TREE_TYPE (@2
+(cmp @1 @0)
 
 /* X / C1 op C2 into a simple range test.  */
 (for cmp (simple_comparison)
  (simplify
   (cmp (trunc_div:s @0 INTEGER_CST@1) INTEGER_CST@2)
   (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& integer_nonzerop (@1)
&& !TREE_OVERFLOW (@1)
&& !TREE_OVERFLOW (@2))
(with { tree lo, hi; bool neg_overflow;
@@ -3626,20 +3634,47 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   wi::overflow_type ovf;
   wide_int prod = wi::mul (wi::to_wide (@2), wi::to_wide (@1),
   TYPE_SIGN (TREE_TYPE (@1)), );
 }
 (if (ovf)
  { constant_boolean_node (wi::lt_p (wi::to_wide (@2), 0,
TYPE_SIGN (TREE_TYPE (@2)))
  != (cmp == LT_EXPR || cmp == LE_EXPR), type); }
  (cmp @0 { wide_int_to_tree (TREE_TYPE (@0), prod); }))
 
+/* Fold (size_t)(A /[ex] B) CMP C to (size_t)A CMP (size_t)B * C or A CMP' 0.
+
+   For small C (less than max/B), this is (size_t)A CMP (size_t)B * C.
+   For large C (more than min/B+2^size), this is also true, with the
+   multiplication computed modulo 2^size.
+   For intermediate C, this just tests the sign of A.  */
+(for cmp  (lt le gt ge)
+ cmp2 (ge ge lt lt)
+ (simplify
+  (cmp (convert (exact_div @0 INTEGER_CST@1)) INTEGER_CST@2)
+  (if (tree_nop_conversion_p (TREE_TYPE (@0), TREE_TYPE (@2))
+   && TYPE_UNSIGNED (TREE_TYPE (@2)) && !TYPE_UNSIGNED (TREE_TYPE (@0))
+   && wi::gt_p (wi::to_wide (@1), 0, TYPE_SIGN (TREE_TYPE (@1
+   (with
+{
+  tree utype = TREE_TYPE (@2);
+  wide_int denom = wi::to_wide (@1);
+  wide_int right = wi::to_wide (@2);
+  wide_int smax = wi::sdiv_trunc (wi::max_value (TREE_TYPE (@0)), denom);
+  wide_int smin = wi::sdiv_trunc (wi::min_value (TREE_TYPE (@0)), denom);
+  bool small = wi::leu_p (right, smax);
+  bool large = wi::geu_p (right, smin);
+}
+(if (small || large)
+ (cmp (convert:utype @0) (mult @2 (convert @1)))
+ (cmp2 @0 { build_zero_cst (TREE_TYPE (@0)); }))
+
 /* Unordered tests if either argument is a NaN.  */
 (simplify
  (bit_ior (unordered @0 @0) (unordered @1 @1))
  (if (types_match (@0, @1))
   (unordered @0 @1)))
 (simplify
  (bit_and (ordered @0 @0) (ordered @1 @1))
  (if (types_match (@0, @1))
   (ordered @0 @1)))
 (simplify
Index: gcc/testsuite/gcc.dg/tree-ssa/cmpexactdiv-3.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/cmpexactdiv-3.c   (nonexistent)
+++ gcc/testsuite/gcc.dg/tree-ssa/cmpexactdiv-3.c   (working copy)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options 

Re: [PATCH] libfortran/90038 Reap dead children when wait=.false.

[Steve Kargl]

On Sun, May 19, 2019 at 01:40:59PM +0300, Janne Blomqvist wrote:
>  
> +#if defined(HAVE_SIGACTION) && defined(HAVE_WAITPID)
> +  static bool sig_init_saved;
> +  bool sig_init = __atomic_load_n (_init_saved, __ATOMIC_RELAXED);
> +  if (!sig_init)
> + {
> +   struct sigaction sa;
> +   sa.sa_handler = _handler;
> +   sigemptyset(_mask);
> +   sa.sa_flags = SA_RESTART | SA_NOCLDSTOP;
> +   sigaction(SIGCHLD, , 0);
> +   __atomic_store_n (_init_saved, true, __ATOMIC_RELAXED);
> + }
> +#endif

Where do the prototypes for __atomic_load_n and __atomic_store_n
come from?  On FreeBSD, it seems these are in stdatomic.h.  Do
we need a HAVE_ATOMIC to include the header?

On a slightly different note, the nonstandard SYSTEM intrinsic
uses system(3) to execute a command.  I believe that it will
leave zombies/orphaned children if a process is interrupted.
Perhap, SYSTEM should be reworked to use your EXECUTE_COMMAND_LINE.

-- 
Steve

CPUID Patch for IDT Winchip

[tedheadster]

I have confirmed that the IDT Winchip 2 does not expressly set %ecx
after a call to cpuid() with %eax = 1, and this causes incorrect
reporting of cpu capabilities. The %ecx register should return 0x0
(and likely %ebx should too) on this hardware. This patch proposes a
fix.

The symptoms of this arose on a Winchip 2 system when systemd called
cpuid() with %eax = 1 and it incorrectly reported rdrand() support
(bit 30 set in %ecx). A call to the supposedly supported rdrand()
function triggered an illegal instruction exception, causing the
system to panic early in booting.

The IDT Winchip documentation is silent on what happens to %ecx and
%ebx after such a call (see below). It appears to leave whatever is in
%ecx untouched instead of zeroing it. This patch defensively zeroes
out %ebx:%ecx:%edx before such a call in cpuid.h.

I should be able to test the earlier Winchip C6 model in the future. I
wlll also check older AMD, Cyrix, and VIA processors.

Thanks to Mike Gilbert for suggesting the solution. Thank you also to
Segher Boessenkool for helping get the inline assembly syntax correct.

Here is the assembly code fragment the patch generates with comments:

   0xb7e21498 <+88>:xor%edi,%edi <--- zeroes %edi for use below
   0xb7e2149a <+90>:mov%edi,%eax
   0xb7e2149c <+92>:cpuid
   0xb7e2149e <+94>:test   %eax,%eax
   0xb7e214a0 <+96>:je 0xb7e214c0 
   0xb7e214a2 <+98>:mov%edi,%ebx <--- zeroes %ebx
   0xb7e214a4 <+100>:   mov%edi,%ecx <--- zeroes %ecx
   0xb7e214a6 <+102>:   mov%edi,%edx <--- zeroes %edx
   0xb7e214a8 <+104>:   mov$0x1,%eax <--- call cpuid with %eax = 1
   0xb7e214ad <+109>:   cpuid
   0xb7e214af <+111>:   shr$0x1e

References:

http://datasheets.chipdb.org/IDT/x86/WinChip2/wc2ds.pdf
http://datasheets.chipdb.org/IDT/x86/C6/c6_data_sheet.pdf

- Matthew Whitehead

diff --git a/gcc/config/i386/cpuid.h b/gcc/config/i386/cpuid.h
index b3b0f91..7f6d726 100644
--- a/gcc/config/i386/cpuid.h
+++ b/gcc/config/i386/cpuid.h
@@ -251,6 +251,15 @@ __get_cpuid (unsigned int __leaf,
   if (__maxlevel == 0 || __maxlevel < __leaf)
 return 0;

+  /* At least one confirmed cpu (Winchip 2) does not set %ecx correctly for
+cpuid() %eax = 1, and leaves garbage in it (usually containing the results
+of a previous call to cpuid() %eax = 0, which puts 'auls' in %ecx from
+'CentaurHauls' in %ebx:%edx:%ecx, the vendor identification string).
+Forcibly zero the three registers before calling cpuid() as a
precaution. */
+
+  *__ebx = *__ecx = *__edx = 0;
+  asm volatile("" : "+b" (*__ebx), "+c" (*__ecx), "+d" (*__edx));
+
   __cpuid (__leaf, *__eax, *__ebx, *__ecx, *__edx);
   return 1;
 }

Re: [patch, fortran] Put workaround for broken C/Lapack wrappers behind flag

[Steve Kargl]

On Sun, May 19, 2019 at 10:26:54AM +0200, Thomas Koenig wrote:
> Hi Steve,
> 
> > Looks good to me.  I wonder if we should add a reference
> > to the option that can produce C prototypes for a Fortran
> > procedure in the description of -fbroken-caller.
> 
> Thanks, I added a reference to that option (see attached patch).
> Committed as r271376.
> 

Thanks.

-- 
steve

Re: Strenghten aliasing_component_refs_p

[Jan Hubicka]

> On Fri, 17 May 2019, Jan Hubicka wrote:
> 
> > Hi,
> > this patch cuts walks in aliasing_component_refs_p if the type we look for
> > can not fit into a given type by comparing their sizes. Similar logic
> > already exists in indirect_ref_may_alias_decl_p.
> > 
> > When we walk reference a.b.c.d.e looking for type x we only need to do
> > it if sizeof(a)>=sizeof(x) and continue woking from e until
> > sizeof(e)<=sizeof(x). We do not need to compare types where sizes are
> > known to be different.
> > 
> > This saves some work (by not walking refs and not comparing their types
> > if they can not match) but also increases number of disambiguations
> > quite noticably. This is because same_type_for_tbaa often returns -1 and
> > makes aliasing_compinent_refs_p to give up.  Using the simple size check
> > prevents hitting such problematic type pairs in many common cases.
> > 
> > Stats on tramp3d lto build change From:
> > 
> > Alias oracle query stats:
> >   refs_may_alias_p: 0 disambiguations, 0 queries
> >   ref_maybe_used_by_call_p: 6451 disambiguations, 25578 queries
> >   call_may_clobber_ref_p: 817 disambiguations, 817 queries
> >   aliasing_component_ref_p: 14 disambiguations, 12528 queries
> >   TBAA oracle: 1468347 disambiguations 3010562 queries
> >550690 are in alias set 0
> >614235 queries asked about the same object
> >0 queries asked about the same alias set
> >0 access volatile
> >260937 are dependent in the DAG
> >116353 are aritificially in conflict with void *
> > 
> > to:
> > 
> > Alias oracle query stats:
> >   refs_may_alias_p: 0 disambiguations, 0 queries
> >   ref_maybe_used_by_call_p: 6451 disambiguations, 25580 queries
> >   call_may_clobber_ref_p: 817 disambiguations, 817 queries
> >   aliasing_component_ref_p: 118 disambiguations, 12552 queries
> >   TBAA oracle: 1468413 disambiguations 3010714 queries
> >550719 are in alias set 0
> >614247 queries asked about the same object
> >0 queries asked about the same alias set
> >0 access volatile
> >260970 are dependent in the DAG
> >116365 are aritificially in conflict with void *
> > 
> > So disambiguations are up from 14 to 118 which is still quite low.
> > 
> > A followup patch making types_same_for_tbaa to not give up for
> > TYPE_STRUCTURAL_EQUALITY pointers and arrays improves hitrate to 2723.
> > 
> > Bootstrapped/regtested x86_64-linux, OK?
> > 
> > * tree-ssa-alias.c (type_big_enough_for_type_p): New function.
> > (aliasing_component_refs_p): Use it.
> > Index: tree-ssa-alias.c
> > ===
> > --- tree-ssa-alias.c(revision 271292)
> > +++ tree-ssa-alias.c(working copy)
> > @@ -735,6 +735,27 @@ ao_ref_init_from_ptr_and_size (ao_ref *r
> >ref->volatile_p = false;
> >  }
> >  
> > +/* Return true if TYPE1 may contain TYPE2 by its size.  */
> > +
> > +static bool
> > +type_big_enough_for_type_p (tree type1, tree type2)
> > +{
> > +  if (!TYPE_SIZE (type1) || !TYPE_SIZE (type2))
> > +return true;
> > +  /* Be conservative for arrays and vectors.  We want to support partial
> > + overlap on int[3] and int[3] as tested in gcc.dg/torture/alias-2.c.  
> > */
> > +  while (TREE_CODE (type2) == ARRAY_TYPE
> > +|| TREE_CODE (type2) == VECTOR_TYPE)
> > +type2 = TREE_TYPE (type2);
> 
> Eww ;)  I guess this means same-type can never return true for
> array or vectors?
> 
> > +  if (!poly_int_tree_p (TYPE_SIZE (type1))
> > +  || !poly_int_tree_p (TYPE_SIZE (type2)))
> > +return true;
> 
> Use
> 
> poly_uint64 size1;
> if (!poly_int_tree_p (TYPE_SIZE (type1), )
>  ...
> 
> > +  if (known_lt (wi::to_poly_widest (TYPE_SIZE (type1)),
> > +   wi::to_poly_widest (TYPE_SIZE (type2
> 
> and
> 
>  if (known_lt (size1, size2))
> 
> I wonder if you can compute whether type1 fits in type2 and
> the other way around at the same time, saving seemingly
> redundant work since you test both ways most of the time below.
> So sth like type_size_compare_for_fitting () returning
> -1, 0, 1 and use zero for "don't know"?

Hi,
this patch implements the three way compare and also merges the code
with same logic in indirect_ref_may_alias_decl_p.
We end up doing more known_lt calls than necessary because sometimes we
do not care about the three way outcome, but I asusme that this should
be relatively cheap once we pass the earlier test and tree to poly_int
conversion.

Bootstrapped/regtested x86_64-linux, OK?

* tree-ssa-alias.c (compare_sizes): New function.
(sompare_type_sizes): New function
(aliasing_component_refs_p): Use it.
(indirect_ref_may_alias_decl_p): Likewise.
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 271379)
+++ 

Re: dg-require-ifunc syntax

[Iain Sandoe]

Hi Dominique,

> On 19 May 2019, at 15:10, Dominique d'Humières  wrote:
> 
> AFAICT the syntax for dg-require-ifunc seems to be
> 
> /* { dg-require-ifunc "" } */
> 
> with two sets of exceptions:
> 
> (1) gcc.target/i386/pr90500-*.c
> 
> which explains
> 
> FAIL: gcc.target/i386/pr90500-1.c  (test for errors, line 6)
> FAIL: gcc.target/i386/pr90500-1.c  (test for warnings, line 6)
> FAIL: gcc.target/i386/pr90500-1.c (test for excess errors)
> FAIL: gcc.target/i386/pr90500-2.c  (test for errors, line 6)
> FAIL: gcc.target/i386/pr90500-2.c  (test for warnings, line 6)
> FAIL: gcc.target/i386/pr90500-2.c (test for excess errors)
> 
> and is fixed with the trivial patch
> 
> --- ../_clean/gcc/testsuite/gcc.target/i386/pr90500-1.c   2019-05-16 
> 17:34:09.0 +0200
> +++ gcc/testsuite/gcc.target/i386/pr90500-1.c 2019-05-18 14:28:12.0 
> +0200
> @@ -1,6 +1,6 @@
> /* PR middle-end/84723 */
> /* { dg-do compile } */
> -/* { dg-require-ifunc } */
> +/* { dg-require-ifunc "" } */
> 
> __attribute__((target_clones("arch=haswell", "default"))) int __tanh() {}
> __typeof(__tanh) tanhf64 __attribute__((alias("__tanh")))/* { dg-error 
> "clones for .target_clones. attribute cannot be created" } */

From a Darwin point of view, this is OK (it seems obvious to me, also).

> --- ../_clean/gcc/testsuite/gcc.target/i386/pr90500-2.c   2019-05-16 
> 17:34:09.0 +0200
> +++ gcc/testsuite/gcc.target/i386/pr90500-2.c 2019-05-18 14:28:25.0 
> +0200
> @@ -1,6 +1,6 @@
> /* PR middle-end/84723 */
> /* { dg-do compile } */
> -/* { dg-require-ifunc } */
> +/* { dg-require-ifunc "" } */
> 
> __attribute__((target_clones("arch=haswell", "default"))) int __tanh() {}
> __typeof(__tanh) tanhf64 
> __attribute__((alias("__tanh"),target_clones("arch=haswell", "default"))); /* 
> { dg-error "clones for .target_clones. attribute cannot be created" } */
> 
> (2) gcc.target/i386/pr84723-*.c
> 
> which succeed on darwin. What is the suitable fix for that?

My assumption here is that the tests should not be run on a non-ifuncs target, 
but that it happens to be that they are testing for an erroneous condition 
- which by chance also gives the correct error on a non-ifuncs target.
> 
> (a) Fix the dg-require-ifunc as above?

I would prefer this, (it’s confusing to run tests for an unsupported 
functionality)
- unless there is some other value to running the tests (will wait for comments
on that).

thanks for the patch.
Iain

> (b) Remove the line?
> 
> TIA
> 
> Dominique
> 

dg-require-ifunc syntax

[Dominique d'Humières]

AFAICT the syntax for dg-require-ifunc seems to be

/* { dg-require-ifunc "" } */

with two sets of exceptions:

(1) gcc.target/i386/pr90500-*.c

which explains

FAIL: gcc.target/i386/pr90500-1.c  (test for errors, line 6)
FAIL: gcc.target/i386/pr90500-1.c  (test for warnings, line 6)
FAIL: gcc.target/i386/pr90500-1.c (test for excess errors)
FAIL: gcc.target/i386/pr90500-2.c  (test for errors, line 6)
FAIL: gcc.target/i386/pr90500-2.c  (test for warnings, line 6)
FAIL: gcc.target/i386/pr90500-2.c (test for excess errors)

and is fixed with the trivial patch

--- ../_clean/gcc/testsuite/gcc.target/i386/pr90500-1.c 2019-05-16 
17:34:09.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr90500-1.c   2019-05-18 14:28:12.0 
+0200
@@ -1,6 +1,6 @@
 /* PR middle-end/84723 */
 /* { dg-do compile } */
-/* { dg-require-ifunc } */
+/* { dg-require-ifunc "" } */
 
 __attribute__((target_clones("arch=haswell", "default"))) int __tanh() {}
 __typeof(__tanh) tanhf64 __attribute__((alias("__tanh")))/* { dg-error "clones 
for .target_clones. attribute cannot be created" } */
--- ../_clean/gcc/testsuite/gcc.target/i386/pr90500-2.c 2019-05-16 
17:34:09.0 +0200
+++ gcc/testsuite/gcc.target/i386/pr90500-2.c   2019-05-18 14:28:25.0 
+0200
@@ -1,6 +1,6 @@
 /* PR middle-end/84723 */
 /* { dg-do compile } */
-/* { dg-require-ifunc } */
+/* { dg-require-ifunc "" } */
 
 __attribute__((target_clones("arch=haswell", "default"))) int __tanh() {}
 __typeof(__tanh) tanhf64 
__attribute__((alias("__tanh"),target_clones("arch=haswell", "default"))); /* { 
dg-error "clones for .target_clones. attribute cannot be created" } */

(2) gcc.target/i386/pr84723-*.c

which succeed on darwin. What is the suitable fix for that?

(a) Fix the dg-require-ifunc as above?
(b) Remove the line?

TIA

Dominique

Re: Go patch committed: Intrinsify runtime/internal/atomic functions

[Andreas Schwab]

I'm getting this crash on riscv:

/daten/riscv64/gcc/gcc-20190518/Build/./gcc/gccgo 
-B/daten/riscv64/gcc/gcc-20190518/Build/./gcc/ -B/usr/riscv64-suse-linux/bin/ 
-B/usr/riscv64-suse-linux/lib/ -isystem /usr/riscv64-suse-linux/include 
-isystem /usr/riscv64-suse-linux/sys-include -O2 -g -I . -c 
-fgo-pkgpath=runtime -fgo-c-header=runtime.inc.raw -fgo-compiling-runtime 
../../../libgo/go/runtime/alg.go ../../../libgo/go/runtime/atomic_pointer.go 
../../../libgo/go/runtime/cgo_gccgo.go ../../../libgo/go/runtime/cgocall.go 
../../../libgo/go/runtime/cgocheck.go ../../../libgo/go/runtime/chan.go 
../../../libgo/go/runtime/compiler.go ../../../libgo/go/runtime/cpuprof.go 
../../../libgo/go/runtime/cputicks.go ../../../libgo/go/runtime/debug.go 
../../../libgo/go/runtime/env_posix.go ../../../libgo/go/runtime/error.go 
../../../libgo/go/runtime/extern.go ../../../libgo/go/runtime/fastlog2.go 
../../../libgo/go/runtime/fastlog2table.go ../../../libgo/go/runtime/ffi.go 
../../../libgo/go/runtime/float.go ../../../libgo/go/runtime/hash64.go 
../../../libgo/go/runtime/heapdump.go ../../../libgo/go/runtime/iface.go 
../../../libgo/go/runtime/lfstack.go ../../../libgo/go/runtime/lfstack_64bit.go 
../../../libgo/go/runtime/lock_futex.go ../../../libgo/go/runtime/malloc.go 
../../../libgo/go/runtime/map.go ../../../libgo/go/runtime/map_fast32.go 
../../../libgo/go/runtime/map_fast64.go 
../../../libgo/go/runtime/map_faststr.go ../../../libgo/go/runtime/mbarrier.go 
../../../libgo/go/runtime/mbitmap.go ../../../libgo/go/runtime/mcache.go 
../../../libgo/go/runtime/mcentral.go ../../../libgo/go/runtime/mem_gccgo.go 
../../../libgo/go/runtime/mfinal.go ../../../libgo/go/runtime/mfixalloc.go 
../../../libgo/go/runtime/mgc.go ../../../libgo/go/runtime/mgc_gccgo.go 
../../../libgo/go/runtime/mgclarge.go ../../../libgo/go/runtime/mgcmark.go 
../../../libgo/go/runtime/mgcsweep.go ../../../libgo/go/runtime/mgcsweepbuf.go 
../../../libgo/go/runtime/mgcwork.go ../../../libgo/go/runtime/mheap.go 
../../../libgo/go/runtime/mprof.go ../../../libgo/go/runtime/msan0.go 
../../../libgo/go/runtime/msize.go ../../../libgo/go/runtime/mstats.go 
../../../libgo/go/runtime/mwbbuf.go ../../../libgo/go/runtime/netpoll.go 
../../../libgo/go/runtime/netpoll_epoll.go 
../../../libgo/go/runtime/os_gccgo.go ../../../libgo/go/runtime/os_linux.go 
../../../libgo/go/runtime/os_linux_noauxv.go ../../../libgo/go/runtime/panic.go 
../../../libgo/go/runtime/print.go ../../../libgo/go/runtime/proc.go 
../../../libgo/go/runtime/profbuf.go ../../../libgo/go/runtime/proflabel.go 
../../../libgo/go/runtime/race0.go ../../../libgo/go/runtime/rdebug.go 
../../../libgo/go/runtime/relax_stub.go ../../../libgo/go/runtime/runtime.go 
../../../libgo/go/runtime/runtime1.go ../../../libgo/go/runtime/runtime2.go 
../../../libgo/go/runtime/rwmutex.go ../../../libgo/go/runtime/select.go 
../../../libgo/go/runtime/sema.go ../../../libgo/go/runtime/signal_gccgo.go 
../../../libgo/go/runtime/signal_sighandler.go 
../../../libgo/go/runtime/signal_unix.go ../../../libgo/go/runtime/sigqueue.go 
../../../libgo/go/runtime/sizeclasses.go ../../../libgo/go/runtime/slice.go 
../../../libgo/go/runtime/string.go ../../../libgo/go/runtime/stubs.go 
../../../libgo/go/runtime/stubs2.go ../../../libgo/go/runtime/stubs3.go 
../../../libgo/go/runtime/stubs_linux.go ../../../libgo/go/runtime/symtab.go 
../../../libgo/go/runtime/time.go ../../../libgo/go/runtime/timestub.go 
../../../libgo/go/runtime/timestub2.go ../../../libgo/go/runtime/trace.go 
../../../libgo/go/runtime/traceback_gccgo.go ../../../libgo/go/runtime/type.go 
../../../libgo/go/runtime/typekind.go ../../../libgo/go/runtime/unaligned1.go 
../../../libgo/go/runtime/utf8.go ../../../libgo/go/runtime/write_err.go 
runtime_sysinfo.go sigtab.go  -fPIC -o .libs/runtime.o
during RTL pass: expand
../../../libgo/go/runtime/mbitmap.go: In function 
‘runtime.setMarked.runtime.markBits’:
../../../libgo/go/runtime/mbitmap.go:291:9: internal compiler error: 
Segmentation fault
  291 |  atomic.Or8(m.bytep, m.mask)
  | ^
0x6a02b7 crash_signal
../../gcc/toplev.c:326
0x917cf6 get_callee_fndecl(tree_node const*)
../../gcc/tree.c:9570
0x2c2e6b expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:3364
0x2aa3e9 expand_builtin_atomic_fetch_op
../../gcc/builtins.c:6541
0x2b5981 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.c:8220
0x3bdfef expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11030
0x2d4ee5 expand_expr
../../gcc/expr.h:279
0x2d4ee5 expand_call_stmt
../../gcc/cfgexpand.c:2724
0x2d4ee5 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3700
0x2d5847 expand_gimple_stmt
../../gcc/cfgexpand.c:3859
0x2da083 expand_gimple_basic_block
../../gcc/cfgexpand.c:5895
0x2dbff3 execute
../../gcc/cfgexpand.c:6518

Andreas.

-- 
Andreas Schwab, 

[PATCH] libfortran/90038 Reap dead children when wait=.false.

[Janne Blomqvist]

When using posix_spawn or fork to launch a child process, the parent
needs to wait for the child, otherwise the dead child is left as a
zombie process. For this purpose one can install a signal handler for
SIGCHLD.

2019-05-19  Janne Blomqvist  

PR libfortran/90038
* intrinsics/execute_command_line (sigchld_handler): New function.
(execute_command_line): Install handler for SIGCHLD.
* configure.ac: Check for presence of sigaction and waitpid.
* config.h.in: Regenerated.
* configure: Regenerated.

Regtested on x86_64-pc-linux-gnu, Ok for trunk?
---
 libgfortran/configure.ac  |  2 +-
 libgfortran/intrinsics/execute_command_line.c | 25 +++
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 8fd5a1a30a9..7cfce28ab69 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -314,7 +314,7 @@ if test "${hardwire_newlib:-0}" -eq 1; then
 else
AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \
ftruncate chsize chdir getentropy getlogin gethostname kill link symlink \
-   sleep ttyname \
+   sleep ttyname sigaction waitpid \
alarm access fork posix_spawn setmode fcntl writev \
gettimeofday stat fstat lstat getpwuid vsnprintf dup \
getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \
diff --git a/libgfortran/intrinsics/execute_command_line.c 
b/libgfortran/intrinsics/execute_command_line.c
index 2ef2324b243..1a471632172 100644
--- a/libgfortran/intrinsics/execute_command_line.c
+++ b/libgfortran/intrinsics/execute_command_line.c
@@ -36,6 +36,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #include 
 extern char **environ;
 #endif
+#if defined(HAVE_POSIX_SPAWN) || defined(HAVE_FORK)
+#include 
+#endif
 
 enum { EXEC_SYNCHRONOUS = -2, EXEC_NOERROR = 0, EXEC_SYSTEMFAILED,
EXEC_CHILDFAILED, EXEC_INVALIDCOMMAND };
@@ -62,6 +65,14 @@ set_cmdstat (int *cmdstat, int value)
 }
 
 
+#if defined(HAVE_WAITPID) && defined(HAVE_SIGACTION)
+static void
+sigchld_handler (int signum __attribute__((unused)))
+{
+  while (waitpid ((pid_t)(-1), NULL, WNOHANG) > 0) {}
+}
+#endif
+
 static void
 execute_command_line (const char *command, bool wait, int *exitstat,
  int *cmdstat, char *cmdmsg,
@@ -82,6 +93,20 @@ execute_command_line (const char *command, bool wait, int 
*exitstat,
 
   set_cmdstat (cmdstat, EXEC_NOERROR);
 
+#if defined(HAVE_SIGACTION) && defined(HAVE_WAITPID)
+  static bool sig_init_saved;
+  bool sig_init = __atomic_load_n (_init_saved, __ATOMIC_RELAXED);
+  if (!sig_init)
+   {
+ struct sigaction sa;
+ sa.sa_handler = _handler;
+ sigemptyset(_mask);
+ sa.sa_flags = SA_RESTART | SA_NOCLDSTOP;
+ sigaction(SIGCHLD, , 0);
+ __atomic_store_n (_init_saved, true, __ATOMIC_RELAXED);
+   }
+#endif
+
 #ifdef HAVE_POSIX_SPAWN
   const char * const argv[] = {"sh", "-c", cmd, NULL};
   if (posix_spawn (, "/bin/sh", NULL, NULL,
-- 
2.17.1

Re: [PATCH] Fix __builtin_init_dwarf_reg_size_table when built with -mfpxx

[Dragan Mladjenovic]

Thank you.


What can I do to ensure this gets back-ported as further back as possible? I 
assume that it can go all the way back to gcc 7 branch.


Best regards,

Dragan



From: Jeff Law 
Sent: Friday, May 17, 2019 6:28 PM
To: Dragan Mladjenovic; gcc-patches@gcc.gnu.org
Cc: Jakub Jelinek; Matthew Fortune
Subject: Re: [PATCH] Fix __builtin_init_dwarf_reg_size_table when built with 
-mfpxx

On 5/16/19 7:15 AM, Dragan Mladjenovic wrote:
> Ping.
>
>
> 
> From: Dragan Mladjenovic
> Sent: Thursday, May 9, 2019 12:29 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Dragan Mladjenovic; Jakub Jelinek; Matthew Fortune
> Subject: [PATCH] Fix __builtin_init_dwarf_reg_size_table when built with 
> -mfpxx
>
> From: "Dragan Mladjenovic" 
>
>
> Hi all,
>
> For TARGET_FLOATXX the odd-numbered FP registers in SFmode are
> HARD_REGNO_CALL_PART_CLOBBERED. This causes dwarf_frame_reg_mode to fall
> back to VOIDmode and for __builtin_init_dwarf_reg_size_table to fill them
> as zero sized.
>
> This prevents libgcc's unwinder form ever restoring high parts of
> calle-saved double precision registers.
>
> This patch fixes the issue by forcing dwarf_frame_reg_mode to use SImode
> for FP registers.
>
> Bootstrapped and done regression tests on mipsel-unknown-linux-gnu -
> no new failures found.
>
>
> Best regards,
> Dragan
>
>
> gcc/ChangeLog:
>
> 2019-04-23  Dragan Mladjenovic  
>
>   * gcc/config/mips/mips.c(mips_dwarf_frame_reg_mode): Replace TARGET_FLOAT64
>   with !TARGET_FLOAT32, thus handling both fp64 and fpxx modes.
>
> gcc/testsuite/ChangeLog:
>
> 2019-04-23  Dragan Mladjenovic  
>
>   * g++.dg/eh/o32-fp.C: New.
>   * gcc.target/mips/dwarfregtable-1.c: New.
>   * gcc.target/mips/dwarfregtable-2.c: New.
>   * gcc.target/mips/dwarfregtable-3.c: New.
>   * gcc.target/mips/dwarfregtable-4.c: New.
>   * gcc.target/mips/dwarfregtable.h: New.
THanks.  I've installed this on the trunk.
jeff

Re: [Patch, fortran] PR90498 - [8/9/10 Regression] ICE with select type/associate and derived type argument containing class(*)

[Dominique d'Humières]

Hi Paul,

s:PR fortran/90948:PR fortran/90498:g

TIA

Dominique

Re: [patch, fortran] Put workaround for broken C/Lapack wrappers behind flag

[Thomas Koenig]

Hi Steve,


Looks good to me.  I wonder if we should add a reference
to the option that can produce C prototypes for a Fortran
procedure in the description of -fbroken-caller.


Thanks, I added a reference to that option (see attached patch).
Committed as r271376.

Regards

Thomas
Index: ChangeLog
===
--- ChangeLog	(Revision 271375)
+++ ChangeLog	(Arbeitskopie)
@@ -1,3 +1,11 @@
+2019-05-19  Thomas Koenig  
+
+	PR fortran/90329
+	* invoke.texi: Document -fbroken-callers.
+	* lang.opt: Add -fbroken-callers.
+	* trans-decl.c (create_function_arglist): Only set
+	DECL_HIDDEN_STRING_LENGTH if flag_broken_callers is set.
+
 2019-05-17  Thomas Schwinge  
 
 	PR fortran/89433
Index: invoke.texi
===
--- invoke.texi	(Revision 271371)
+++ invoke.texi	(Arbeitskopie)
@@ -181,7 +181,7 @@ and warnings}.
 @item Code Generation Options
 @xref{Code Gen Options,,Options for code generation conventions}.
 @gccoptlist{-faggressive-function-elimination -fblas-matmul-limit=@var{n} @gol
--fbounds-check -fcheck-array-temporaries @gol
+-fbounds-check -fbroken-callers -fcheck-array-temporaries @gol
 -fcheck=@var{} @gol
 -fcoarray=@var{} -fexternal-blas -ff2c
 -ffrontend-loop-interchange @gol
@@ -1617,6 +1617,34 @@ warnings for generated array temporaries.
 @c Note: This option is also referred in gcc's manpage
 Deprecated alias for @option{-fcheck=bounds}.
 
+@item -fbroken-callers
+@opindex @code{broken-callers}
+Some C interfaces to Fortran codes violate the gfortran ABI by
+omitting the hidden character length arguments as described in
+@xref{Argument passing conventions}.  This can lead to crashes
+because pushing arguments for tail calls can overflow the stack.
+
+To provide a workaround for existing binary packages, this option
+disables tail call optimization for gfortran procedures with character
+arguments.
+
+Using this option can lead to problems including crashes due to
+insufficient stack space.
+
+It is @emph{very strongly} recommended to fix the code in question.
+The @option{-fc-prototypes-external} option can be used to generate
+prototypes which conform to gfortran's ABI, for inclusion in the
+source code.
+
+Support for this option will likely be withdrawn in a future release
+of gfortran.
+
+The negative form, @option{-fno-broken-callers}, can be used to
+disable this option.
+
+Default is currently @option{-fbroken-callers}, this will change
+in future releases.
+
 @item -fcheck-array-temporaries
 @opindex @code{fcheck-array-temporaries}
 Deprecated alias for @option{-fcheck=array-temps}.
Index: lang.opt
===
--- lang.opt	(Revision 271371)
+++ lang.opt	(Arbeitskopie)
@@ -397,6 +397,10 @@ fblas-matmul-limit=
 Fortran RejectNegative Joined UInteger Var(flag_blas_matmul_limit) Init(30)
 -fblas-matmul-limit=	Size of the smallest matrix for which matmul will use BLAS.
 
+fbroken-callers
+Fortran Var(flag_broken_callers) Init(1)
+Disallow tail call optimization when a calling routine may have omitted character lenghts.
+
 fcheck-array-temporaries
 Fortran
 Produce a warning at runtime if a array temporary has been created for a procedure argument.
Index: trans-decl.c
===
--- trans-decl.c	(Revision 271371)
+++ trans-decl.c	(Arbeitskopie)
@@ -2516,7 +2516,11 @@ create_function_arglist (gfc_symbol * sym)
 	  DECL_ARG_TYPE (length) = len_type;
 	  TREE_READONLY (length) = 1;
 	  gfc_finish_decl (length);
-	  if (f->sym->ts.u.cl
+
+	  /* Marking the length DECL_HIDDEN_STRING_LENGTH will lead
+	 to tail calls being disabled.  Only do that if we
+	 potentially have broken callers.  */
+	  if (flag_broken_callers && f->sym->ts.u.cl
 	  && f->sym->ts.u.cl->length
 	  && f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT)
 	DECL_HIDDEN_STRING_LENGTH (length) = 1;

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Segher Boessenkool]

On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> Do we really need a commit integer numbers after the transition? I know 
> we're used to it.
> But git commit hash provides that same.

Revision numbers are nice short text strings, and from a revision number
you can see approximately when it happened, and from two revision numbers
on the same branch you can trivially tell which one is older.  Those are
nice features.  But we can live without it, IMO.


Segher

Re: [PATCH][RFC] Fix PR90510, VEC_PERM -> BIT_INSERT folding

[Richard Sandiford]

Richard Biener  writes:
> This adds, incrementally ontop of moving VEC_PERM_EXPR folding
> to match.pd (but not incremental patch - sorry...), folding
> of single-element insert permutations to BIT_INSERT_EXPR.
>
> Things are quite awkward with the new poly-int vec-perm stuff
> so effectively this doesn't work for SVE and is still very
> ugly.  I wonder how to make it generic enough so SVE would
> be happy and / or how to make the code prettier.
>
> I also can't find a helper to read a specific vector element
> from a VECTOR_CST/CONSTRUCTOR (can I even do that "generally"
> with a poly-int index?!), but there surely must be one.

Yeah, would be nice to have a helper that handles both VECTOR_CST
and CONSTRUCTOR, even if just for constant indices.

CONSTRUCTORs are still very much fixed-length, so it wouldn't really
make sense to fold a poly_int index at compile time.  The only case we
could handle is when the index is known to be beyond the last nonzero
element.

We could fold some poly_int VECTOR_CST_ELT indices to poly_ints, but
it'd depend on the values involved.

Indexing specific poly_int elements of a single vector is a bit dubious
in length-agnostic code though.  Not saying it'll never be useful, but
it's certainly not a native SVE operation.  So I think even for SVE,
constant VECTOR_CST/CONSTRUCTOR elements are the only interesting case
for now.

> [...]
> @@ -11774,61 +11777,7 @@ fold_ternary_loc (location_t loc, enum t
> poly_uint64 nelts = TYPE_VECTOR_SUBPARTS (type);
> bool single_arg = (op0 == op1);
> vec_perm_indices sel (builder, single_arg ? 1 : 2, nelts);
> -
> -   /* Check for cases that fold to OP0 or OP1 in their original
> -  element order.  */
> -   if (sel.series_p (0, 1, 0, 1))
> - return op0;
> -   if (sel.series_p (0, 1, nelts, 1))
> - return op1;
> -
> -   if (!single_arg)
> - {
> -   if (sel.all_from_input_p (0))
> - op1 = op0;
> -   else if (sel.all_from_input_p (1))
> - {
> -   op0 = op1;
> -   sel.rotate_inputs (1);
> - }
> - }

Since this isn't an incremental patch... :-)

One of the holes of the current code is that we still allow two
permute indices for the same permutation, e.g.  { 4, 1, 2, 3 } and
{ 0, 5, 6, 7 }.  IMO we should canonicalize it so that the first index
selects from the first vector.  So maybe the above should be:

  if (!single_arg)
{
  if (known_ge (sel[0], nunits))
{
  std::swap (op0, op1);
  sel.rotate_inputs (1);
}
  if (sel.all_from_input_p (0))
op1 = op0;
}

> [...]
> + /* See if the permutation is performing a single element
> +insert from a CONSTRUCTOR or constant and use a BIT_INSERT_EXPR
> +in that case.  */
> + unsigned HOST_WIDE_INT cnelts;
> +if ((TREE_CODE (cop0) == VECTOR_CST
> +  || TREE_CODE (cop0) == CONSTRUCTOR
> +  || TREE_CODE (cop1) == VECTOR_CST
> +  || TREE_CODE (cop1) == CONSTRUCTOR)
> + && nelts.is_constant ())
> +  {
> + unsigned first = 0, first_oo = 0, first_i;
> + unsigned second = 0, second_oo = 0, second_i;
> + HOST_WIDE_INT idx;
> + for (unsigned HOST_WIDE_INT i = 0; i < cnelts; ++i)
> +   if (!sel[i].is_constant ())
> + {
> +   first = second = 0;
> +   break;
> + }
> +   else if ((unsigned HOST_WIDE_INT)idx < cnelts)
> + {
> +   first_i = i;
> +   first++;
> +   first_oo += (unsigned HOST_WIDE_INT)idx != i;
> + }
> +   else
> + {
> +   second_i = i;
> +   second++;
> +   second_oo += (unsigned HOST_WIDE_INT)idx != i + cnelts;
> + }

This won't handle the case in which the inserted element comes from
the same vector.

If we add the extra canonicalization above, we'd only ever be inserting
into the second vector at element 0.   The test for that would be:

   if (sel.series_p (1, 1, nelts + 1, 1))
 // insert sel[0] into index 0 of the second vector

I think the SVE-friendly way of doing the check for the first vector
would be:

   unsigned int encoded_nelts = sel.encoding ().encoded_nelts ();
   unsigned int i = 0;
   for (; i < encoded_nelts; ++i)
 if (maybe_ne (sel[i], i))
   break;
   if (i < encoded_nelts && sel.series_p (i + 1, 1, i + 1, 1))
 // insert sel[i] into index i of the first vector

Although that's two searches, one of them will halt very early.

The SVE-friendly way of getting the VECTOR_CST/CONSTRUCTOR element would be:

  poly_uint64 idx = sel[i];
  unsigned HOST_WIDE_INT const_idx;
  if (known_le (idx, nelts) && idx.is_constant (_idx))
// const_idx from first vector
  else if (known_ge (idx, nelts) && (idx - 

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 5/17/19 2:39 PM, Jakub Jelinek wrote:

On Fri, May 17, 2019 at 02:22:47PM +0200, Martin Liška wrote:

On 5/17/19 1:06 AM, Joseph Myers wrote:

That repository
represents what I consider the collaboratively built consensus on such
things as the desired author map (including handling of the ambiguous
author name), which directories represent branches and tags, and what tags
should be kept or removed - but building up such a consensus and keeping


About the map. I agree with Richard that we should do best approach and not
to fully reconstruct history of people who has switched email address multi
times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
a clean up:

- for logins with duplicite emails I chose the latest one used on gcc-patches 
mailing list
- comments were removed
- a few entries contained timezone and I stripped that

Final version of the map can be seen here:
https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map

@Maxim: would it be possible to update your script so that it will use:
--authors-file=gcc.map ?

Is it desired for the transition to use the author map? Do we want it?


Can people proposing the conversion also come up with the precommit hooks
etc. scripts we'll need?


Can you please point out to a discussion where these were mentioned?
I'm aware of 'no-merge-commits hook' and a hook that will paste commit
message to bugzilla entries.


I'd think we want to enforce linear history (and stress that every commit
should be bootstrappable, with git it is much easier to screw that up by
pushing many git commits at once, even with rebase actually not testing each
of them).
And something to keep the numeric commit numbers working for
http://gcc.gnu.org/rNN (I believe a roughly working scheme has been
identified, but not implemented).


Do we really need a commit integer numbers after the transition? I know we're 
used to it.
But git commit hash provides that same.

Martin



Jakub

Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Martin Liška]

On 5/17/19 4:59 PM, Maxim Kuvyrkov wrote:

On May 17, 2019, at 3:22 PM, Martin Liška  wrote:

On 5/17/19 1:06 AM, Joseph Myers wrote:

That repository
represents what I consider the collaboratively built consensus on such
things as the desired author map (including handling of the ambiguous
author name), which directories represent branches and tags, and what tags
should be kept or removed - but building up such a consensus and keeping


About the map. I agree with Richard that we should do best approach and not
to fully reconstruct history of people who has switched email address multi
times. I cloned git://thyrsus.com/repositories/gcc-conversion.git and made
a clean up:

- for logins with duplicite emails I chose the latest one used on gcc-patches 
mailing list
- comments were removed
- a few entries contained timezone and I stripped that

Final version of the map can be seen here:
https://github.com/marxin/gcc-git-conversion/blob/cleanup/gcc.map

@Maxim: would it be possible to update your script so that it will use:
--authors-file=gcc.map ?


Should not be a problem.  I'll try that.



Is it desired for the transition to use the author map? Do we want it?


IIUC, the downside is that converted repo will not match current git mirror 
unless we do log re-writing, which would add extra info on the side.


Just to be clear: I don't insist on the authors map and I see @Segher is 
strongly against (@Richard probably as well).
I'm just saying that we have a pretty compete authors map and we can liberally 
decide whether to use it or not
(with all pros and cons).

Martin



--
Maxim Kuvyrkov
www.linaro.org