[PATCH 6/7] ivopts: Add handlings for vector with length IFNs

[Kewen.Lin via Gcc-patches]

gcc/ChangeLog

2020-MM-DD  Kewen Lin  

* tree-ssa-loop-ivopts.c (get_mem_type_for_internal_fn): Handle
IFN_LEN_LOAD and IFN_LEN_STORE.
(get_alias_ptr_type_for_ptr_address): Likewise.


---
 gcc/tree-ssa-loop-ivopts.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 1d2697ae1ba..45b31640e75 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -2436,12 +2436,14 @@ get_mem_type_for_internal_fn (gcall *call, tree *op_p)
 {
 case IFN_MASK_LOAD:
 case IFN_MASK_LOAD_LANES:
+case IFN_LEN_LOAD:
   if (op_p == gimple_call_arg_ptr (call, 0))
return TREE_TYPE (gimple_call_lhs (call));
   return NULL_TREE;
 
 case IFN_MASK_STORE:
 case IFN_MASK_STORE_LANES:
+case IFN_LEN_STORE:
   if (op_p == gimple_call_arg_ptr (call, 0))
return TREE_TYPE (gimple_call_arg (call, 3));
   return NULL_TREE;
@@ -7415,6 +7417,8 @@ get_alias_ptr_type_for_ptr_address (iv_use *use)
 case IFN_MASK_STORE:
 case IFN_MASK_LOAD_LANES:
 case IFN_MASK_STORE_LANES:
+case IFN_LEN_LOAD:
+case IFN_LEN_STORE:
   /* The second argument contains the correct alias type.  */
   gcc_assert (use->op_p = gimple_call_arg_ptr (call, 0));
   return TREE_TYPE (gimple_call_arg (call, 1));
-- 

[PATCH 5/7] vect: Support vector load/store with length in vectorizer

[Kewen.Lin via Gcc-patches]

gcc/ChangeLog

2020-MM-DD  Kewen Lin  

* doc/invoke.texi (vect-with-length-scope): Document new option.
* params.opt (vect-with-length-scope): New.
* tree-vect-loop-manip.c (vect_set_loop_lens_directly): New function.
(vect_set_loop_condition_len): Likewise.
(vect_set_loop_condition): Call vect_set_loop_condition_len for loop 
with
length.
(vect_gen_vector_loop_niters): Use VF as the step for loop with length.
(vect_do_peeling): Adjust for loop with length.
* tree-vect-loop.c (_loop_vec_info::_loop_vec_info): Initialize
can_with_length_p and fully_with_length_p.
(release_vec_loop_lens): New function.
(_loop_vec_info::~_loop_vec_info): Use it to free the loop lens.
(vect_verify_loop_lens): New function.
(vect_analyze_loop_costing): Adjust for loop fully with length.
(determine_peel_for_niter): Don't peel if loop fully with length.
(vect_analyze_loop_2): Save LOOP_VINFO_CAN_WITH_LENGTH_P around retries,
and free the length rgroups before retrying.  Check loop-wide reasons 
for
disabling loops with length.  Make the final decision about use vector
access with length or not.
(vect_analyze_loop): Add handlings for epilogue of loop that can use 
vector
with length but not.
(vect_estimate_min_profitable_iters): Adjust for loop with length.
(vectorizable_reduction): Disable loop with length.
(vectorizable_live_operation): Likewise.
(vect_record_loop_len): New function.
(vect_get_loop_len): Likewise.
(vect_transform_loop): Flag final loop iteration could be partial vector
for loop with length.
* tree-vect-stmts.c (check_load_store_with_len): New function.
(vectorizable_store): Handle vector loop with length.
(vectorizable_load): Likewise.
(vect_gen_len): New function.
* tree-vectorizer.h (struct rgroup_lens): New structure.
(vec_loop_lens): New typedef.
(_loop_vec_info): Add lens, can_with_length_p and fully_with_length_p.
(LOOP_VINFO_CAN_WITH_LENGTH_P): New macro.
(LOOP_VINFO_FULLY_WITH_LENGTH_P): Likewise.
(LOOP_VINFO_LENS): Likewise.
(vect_record_loop_len): New declare.
(vect_get_loop_len): Likewise.
(vect_gen_len): Likewise.


---
 gcc/doc/invoke.texi|   7 +
 gcc/params.opt |   4 +
 gcc/tree-vect-loop-manip.c | 268 -
 gcc/tree-vect-loop.c   | 241 -
 gcc/tree-vect-stmts.c  | 152 +
 gcc/tree-vectorizer.h  |  32 +
 6 files changed, 697 insertions(+), 7 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8b9935dfe65..ac765feab13 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -13079,6 +13079,13 @@ by the copy loop headers pass.
 @item vect-epilogues-nomask
 Enable loop epilogue vectorization using smaller vector size.
 
+@item vect-with-length-scope
+Control the scope of vector memory access with length exploitation.  0 means we
+don't expliot any vector memory access with length, 1 means we only exploit
+vector memory access with length for those loops whose iteration number are
+less than VF, such as very small loop or epilogue, 2 means we want to exploit
+vector memory access with length for any loops if possible.
+
 @item slp-max-insns-in-bb
 Maximum number of instructions in basic block to be
 considered for SLP vectorization.
diff --git a/gcc/params.opt b/gcc/params.opt
index 4aec480798b..d4309101067 100644
--- a/gcc/params.opt
+++ b/gcc/params.opt
@@ -964,4 +964,8 @@ Bound on number of runtime checks inserted by the 
vectorizer's loop versioning f
 Common Joined UInteger Var(param_vect_max_version_for_alignment_checks) 
Init(6) Param Optimization
 Bound on number of runtime checks inserted by the vectorizer's loop versioning 
for alignment check.
 
+-param=vect-with-length-scope=
+Common Joined UInteger Var(param_vect_with_length_scope) Init(0) 
IntegerRange(0, 2) Param Optimization
+Control the vector with length exploitation scope.
+
 ; This comment is to ensure we retain the blank line above.
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 8c5e696b995..3d5dec6f65c 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -747,6 +747,263 @@ vect_set_loop_condition_masked (class loop *loop, 
loop_vec_info loop_vinfo,
   return cond_stmt;
 }
 
+/* Helper for vect_set_loop_condition_len.  Like vect_set_loop_masks_directly,
+   generate definitions for all the lengths in RGL and return a length that is
+   nonzero when the loop needs to iterate.  Add any new preheader statements to
+   PREHEADER_SEQ.  Use LOOP_COND_GSI to insert code before the exit gcond.
+
+   RGL belongs to loop LOOP.  The loop originally iterated NITERS
+   times and has been vectorized according to LOOP_VINFO.  

[PATCH 4/7] hook/rs6000: Add vectorize length mode for vector with length

[Kewen.Lin via Gcc-patches]

gcc/ChangeLog:

2020-MM-DD  Kewen Lin  

* config/rs6000/rs6000.c (TARGET_VECTORIZE_LENGTH_MODE): New macro.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in: New hook.
* target.def: Likewise.


---
 gcc/config/rs6000/rs6000.c | 3 +++
 gcc/doc/tm.texi| 6 ++
 gcc/doc/tm.texi.in | 2 ++
 gcc/target.def | 7 +++
 4 files changed, 18 insertions(+)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 8435bc15d72..c4d9d558b2f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1659,6 +1659,9 @@ static const struct attribute_spec 
rs6000_attribute_table[] =
 #undef TARGET_HAVE_COUNT_REG_DECR_P
 #define TARGET_HAVE_COUNT_REG_DECR_P true
 
+#undef TARGET_VECTORIZE_LENGTH_MODE
+#define TARGET_VECTORIZE_LENGTH_MODE DImode
+
 /* 10 is infinite cost in IVOPTs.  */
 #undef TARGET_DOLOOP_COST_FOR_GENERIC
 #define TARGET_DOLOOP_COST_FOR_GENERIC 10
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 6e7d9dc54a9..5ea8734a191 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -6084,6 +6084,12 @@ The default implementation returns a 
@code{MODE_VECTOR_INT} with the
 same size and number of elements as @var{mode}, if such a mode exists.
 @end deftypefn
 
+@deftypevr {Target Hook} scalar_int_mode TARGET_VECTORIZE_LENGTH_MODE
+For the targets which support vector memory access with length, return
+the scalar int mode to use for the length in bytes.
+The default is to use @code{word_mode}.
+@end deftypevr
+
 @deftypefn {Target Hook} bool TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE 
(unsigned @var{ifn})
 This hook returns true if masked internal function @var{ifn} (really of
 type @code{internal_fn}) should be considered expensive when the mask is
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 3be984bbd5c..83034176b56 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -4181,6 +4181,8 @@ address;  but often a machine-dependent strategy can 
generate better code.
 
 @hook TARGET_VECTORIZE_GET_MASK_MODE
 
+@hook TARGET_VECTORIZE_LENGTH_MODE
+
 @hook TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE
 
 @hook TARGET_VECTORIZE_INIT_COST
diff --git a/gcc/target.def b/gcc/target.def
index 07059a87caf..b58d87e1496 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -1969,6 +1969,13 @@ same size and number of elements as @var{mode}, if such 
a mode exists.",
  (machine_mode mode),
  default_get_mask_mode)
 
+DEFHOOKPOD
+(length_mode,
+ "For the targets which support vector memory access with length, return\n\
+the scalar int mode to use for the length in bytes.\n\
+The default is to use @code{word_mode}.",
+ scalar_int_mode, word_mode)
+
 /* Function to say whether a masked operation is expensive when the
mask is all zeros.  */
 DEFHOOK
-- 

[PATCH 3/7] vect: Factor out codes for niters smaller than vf check

[Kewen.Lin via Gcc-patches]

gcc/ChangeLog:

2020-MM-DD  Kewen Lin  

* tree-vect-loop.c (known_niters_smaller_than_vf): New function, 
factored out from ...
(vect_analyze_loop_costing): ... here.
---
 gcc/tree-vect-loop.c | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 4f94b4baad9..80e33b61be7 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -155,6 +155,7 @@ along with GCC; see the file COPYING3.  If not see
 static void vect_estimate_min_profitable_iters (loop_vec_info, int *, int *);
 static stmt_vec_info vect_is_simple_reduction (loop_vec_info, stmt_vec_info,
   bool *, bool *);
+static bool known_niters_smaller_than_vf (loop_vec_info);
 
 /* Subroutine of vect_determine_vf_for_stmt that handles only one
statement.  VECTYPE_MAYBE_SET_P is true if STMT_VINFO_VECTYPE
@@ -1631,15 +1632,7 @@ vect_analyze_loop_costing (loop_vec_info loop_vinfo)
  vectorization factor.  */
   if (!LOOP_VINFO_FULLY_MASKED_P (loop_vinfo))
 {
-  HOST_WIDE_INT max_niter;
-
-  if (LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo))
-   max_niter = LOOP_VINFO_INT_NITERS (loop_vinfo);
-  else
-   max_niter = max_stmt_executions_int (loop);
-
-  if (max_niter != -1
- && (unsigned HOST_WIDE_INT) max_niter < assumed_vf)
+  if (known_niters_smaller_than_vf (loop_vinfo))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
@@ -9231,3 +9224,23 @@ vect_iv_limit_for_full_masking (loop_vec_info loop_vinfo)
   return iv_limit;
 }
 
+/* If we know the iteration count is smaller than vectorization factor, return
+   true, otherwise return false.  */
+
+static bool
+known_niters_smaller_than_vf (loop_vec_info loop_vinfo)
+{
+  unsigned int assumed_vf = vect_vf_for_cost (loop_vinfo);
+
+  HOST_WIDE_INT max_niter;
+  if (LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo))
+max_niter = LOOP_VINFO_INT_NITERS (loop_vinfo);
+  else
+max_niter = max_stmt_executions_int (LOOP_VINFO_LOOP (loop_vinfo));
+
+  if (max_niter != -1 && (unsigned HOST_WIDE_INT) max_niter < assumed_vf)
+return true;
+
+  return false;
+}
+
-- 

[PATCH 2/7] rs6000: lenload/lenstore optab support

[Kewen.Lin via Gcc-patches]

gcc/ChangeLog:

2020-MM-DD  Kewen Lin  

* config/rs6000/vsx.md (lenloaddi): New define_expand.
(lenstoredi): Likewise.


---
 gcc/config/rs6000/vsx.md | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 2a28215ac5b..cc098d3ccb5 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -5082,6 +5082,36 @@
   operands[3] = gen_reg_rtx (DImode);
 })
 
+;; Define optab for vector access with length vectorization exploitation.
+(define_expand "lenloaddi"
+  [(match_operand:VEC_A 0 "vlogical_operand")
+   (match_operand:VEC_A 1 "memory_operand")
+   (match_operand:DI 2 "int_reg_operand")]
+  "TARGET_P9_VECTOR && TARGET_64BIT"
+{
+  rtx mem = XEXP (operands[1], 0);
+  mem = force_reg (DImode, mem);
+  rtx res = gen_reg_rtx (V16QImode);
+  emit_insn (gen_lxvl (res, mem, operands[2]));
+  emit_move_insn (operands[0], gen_lowpart (mode, res));
+  DONE;
+})
+
+(define_expand "lenstoredi"
+  [(match_operand:VEC_A 0 "memory_operand")
+   (match_operand:VEC_A 1 "vlogical_operand")
+   (match_operand:DI 2 "int_reg_operand")
+  ]
+  "TARGET_P9_VECTOR && TARGET_64BIT"
+{
+  rtx val = gen_reg_rtx (V16QImode);
+  emit_move_insn (val, gen_lowpart (V16QImode, operands[1]));
+  rtx mem = XEXP (operands[0], 0);
+  mem = force_reg (DImode, mem);
+  emit_insn (gen_stxvl (val, mem, operands[2]));
+  DONE;
+})
+
 (define_insn "*stxvl"
   [(set (mem:V16QI (match_operand:DI 1 "gpc_reg_operand" "b"))
(unspec:V16QI
-- 

[PATCH 1/7] ifn/optabs: Support vector load/store with length

[Kewen.Lin via Gcc-patches]

gcc/ChangeLog:

2020-MM-DD  Kewen Lin  

* doc/md.texi (lenload@var{m}@var{n}): Document.
(lenstore@var{m}@var{n}): Likewise.
* internal-fn.c (len_load_direct): New macro.
(len_store_direct): Likewise.
(expand_len_load_optab_fn): Likewise.
(expand_len_store_optab_fn): Likewise.
(direct_len_load_optab_supported_p): Likewise.
(direct_len_store_optab_supported_p): Likewise.
(internal_load_fn_p): Handle IFN_LEN_LOAD.
(internal_store_fn_p): Handle IFN_LEN_STORE.
(internal_fn_stored_value_index): Handle IFN_LEN_STORE.
* internal-fn.def (LEN_LOAD): New internal function.
(LEN_STORE): Likewise.
* optabs.def (lenload_optab, lenstore_optab): New optab.


---
 gcc/doc/md.texi | 16 
 gcc/internal-fn.c   | 13 +++--
 gcc/internal-fn.def |  6 ++
 gcc/optabs.def  |  2 ++
 4 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 2c67c818da5..b0c19cd3b81 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -5167,6 +5167,22 @@ mode @var{n}.
 
 This pattern is not allowed to @code{FAIL}.
 
+@cindex @code{lenload@var{m}@var{n}} instruction pattern
+@item @samp{lenload@var{m}@var{n}}
+Perform a vector load with length from memory operand 1 of mode @var{m}
+into register operand 0.  Length is provided in register operand 2 of
+mode @var{n}.
+
+This pattern is not allowed to @code{FAIL}.
+
+@cindex @code{lenstore@var{m}@var{n}} instruction pattern
+@item @samp{lenstore@var{m}@var{n}}
+Perform a vector store with length from register operand 1 of mode @var{m}
+into memory operand 0.  Length is provided in register operand 2 of
+mode @var{n}.
+
+This pattern is not allowed to @code{FAIL}.
+
 @cindex @code{vec_perm@var{m}} instruction pattern
 @item @samp{vec_perm@var{m}}
 Output a (variable) vector permutation.  Operand 0 is the destination
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 5e9aa60721e..be64cd86c07 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -104,10 +104,12 @@ init_internal_fns ()
 #define load_lanes_direct { -1, -1, false }
 #define mask_load_lanes_direct { -1, -1, false }
 #define gather_load_direct { 3, 1, false }
+#define len_load_direct { -1, 2, false }
 #define mask_store_direct { 3, 2, false }
 #define store_lanes_direct { 0, 0, false }
 #define mask_store_lanes_direct { 0, 0, false }
 #define scatter_store_direct { 3, 1, false }
+#define len_store_direct { 3, 2, false }
 #define unary_direct { 0, 0, true }
 #define binary_direct { 0, 0, true }
 #define ternary_direct { 0, 0, true }
@@ -2478,7 +2480,7 @@ expand_call_mem_ref (tree type, gcall *stmt, int index)
   return fold_build2 (MEM_REF, type, addr, build_int_cst (alias_ptr_type, 0));
 }
 
-/* Expand MASK_LOAD{,_LANES} call STMT using optab OPTAB.  */
+/* Expand MASK_LOAD{,_LANES} and LEN_LOAD call STMT using optab OPTAB.  */
 
 static void
 expand_mask_load_optab_fn (internal_fn, gcall *stmt, convert_optab optab)
@@ -2514,8 +2516,9 @@ expand_mask_load_optab_fn (internal_fn, gcall *stmt, 
convert_optab optab)
 }
 
 #define expand_mask_load_lanes_optab_fn expand_mask_load_optab_fn
+#define expand_len_load_optab_fn expand_mask_load_optab_fn
 
-/* Expand MASK_STORE{,_LANES} call STMT using optab OPTAB.  */
+/* Expand MASK_STORE{,_LANES} and LEN_STORE call STMT using optab OPTAB.  */
 
 static void
 expand_mask_store_optab_fn (internal_fn, gcall *stmt, convert_optab optab)
@@ -2547,6 +2550,7 @@ expand_mask_store_optab_fn (internal_fn, gcall *stmt, 
convert_optab optab)
 }
 
 #define expand_mask_store_lanes_optab_fn expand_mask_store_optab_fn
+#define expand_len_store_optab_fn expand_mask_store_optab_fn
 
 static void
 expand_ABNORMAL_DISPATCHER (internal_fn, gcall *)
@@ -3128,10 +3132,12 @@ multi_vector_optab_supported_p (convert_optab optab, 
tree_pair types,
 #define direct_load_lanes_optab_supported_p multi_vector_optab_supported_p
 #define direct_mask_load_lanes_optab_supported_p multi_vector_optab_supported_p
 #define direct_gather_load_optab_supported_p convert_optab_supported_p
+#define direct_len_load_optab_supported_p direct_optab_supported_p
 #define direct_mask_store_optab_supported_p direct_optab_supported_p
 #define direct_store_lanes_optab_supported_p multi_vector_optab_supported_p
 #define direct_mask_store_lanes_optab_supported_p 
multi_vector_optab_supported_p
 #define direct_scatter_store_optab_supported_p convert_optab_supported_p
+#define direct_len_store_optab_supported_p direct_optab_supported_p
 #define direct_while_optab_supported_p convert_optab_supported_p
 #define direct_fold_extract_optab_supported_p direct_optab_supported_p
 #define direct_fold_left_optab_supported_p direct_optab_supported_p
@@ -3498,6 +3504,7 @@ internal_load_fn_p (internal_fn fn)
 case IFN_MASK_LOAD_LANES:
 case IFN_GATHER_LOAD:
 case IFN_MASK_GATHER_LOAD:
+case IFN_LEN_LOAD:
   return true;
 
 default:
@@ -3517,6 +3524,7 @@ 

[PATCH 0/7] Support vector load/store with length

[Kewen.Lin via Gcc-patches]

Hi all,

This patch set adds support for vector load/store with length, Power 
ISA 3.0 brings instructions lxvl/stxvl to perform vector load/store with
length, it's good to be exploited for those cases we don't have enough
stuffs to fill in the whole vector like epilogues.

This support mainly refers to the handlings for fully-predicated loop
but it also covers the epilogue usage.  Now it supports two modes
controlled by parameter vect-with-length-scope, it can support any
loops fully with length or just for those cases with small iteration
counts less than VF like epilogue, for now I don't have ready env to
benchmark it, but based on the current inefficient length generation,
I don't think it's a good idea to adopt vector with length for any loops.
For the main loop which used to be vectorized, it increases register
pressure and introduces extra computation for length, the pro for icache
seems not comparable.  But I think it might be a good idea to keep this
parameter there for functionality testing, further benchmarking and other
ports' potential future supports.

As we don't have any benchmarking, this support isn't enabled by default
for any particular cpus, all testings are with explicit parameter setting.

Bootstrapped on powerpc64le-linux-gnu P9 with all vect-with-length-scope
settings (0/1/2).  Regress-test passed with vector-with-length-scope 0,
for the other twos, several vector related cases need to be updated, no
remarkable failures found.  BTW, P9 is the one which supports the
functionality but not ready to evaluate the performance.

Here still are many things to be supported or improved, not limited to:
  - reduction/live-out support
  - Cost model adding/tweaking
  - IFN gimple folding
  - Some unnecessary ops improvements eg: vector_size check
  - Some possible refactoring
I'll support/post the patches gradually.

Any comments are highly appreciated.

BR,
Kewen
-

Patch set outline:
  [PATCH 1/7] ifn/optabs: Support vector load/store with length
  [PATCH 2/7] rs6000: lenload/lenstore optab support
  [PATCH 3/7] vect: Factor out codes for niters smaller than vf check
  [PATCH 4/7] hook/rs6000: Add vectorize length mode for vector with length
  [PATCH 5/7] vect: Support vector load/store with length in vectorizer
  [PATCH 6/7] ivopts: Add handlings for vector with length IFNs
  [PATCH 7/7] rs6000/testsuite: Vector with length test cases

 gcc/config/rs6000/rs6000.c  |   3 +
 gcc/config/rs6000/vsx.md|  30 ++
 gcc/doc/invoke.texi |   7 +++
 gcc/doc/md.texi |  16 ++
 gcc/doc/tm.texi |   6 ++
 gcc/doc/tm.texi.in  |   2 +
 gcc/internal-fn.c   |  13 -
 gcc/internal-fn.def |   6 ++
 gcc/optabs.def  |   2 +
 gcc/params.opt  |   4 ++
 gcc/target.def  |   7 +++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-1.h  |  18 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-2.h  |  17 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-3.h  |  31 +++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-4.h  |  24 
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-5.h  |  29 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-6.h  |  32 +++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-1.c |  15 +
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-2.c |  15 +
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-3.c |  18 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-4.c |  15 +
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-5.c |  15 +
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-6.c |  16 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-1.c |  10 
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-2.c |  10 
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-3.c |  10 
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-4.c |  10 
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-5.c |  10 
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-epil-run-6.c |  10 
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-1.c |  16 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-2.c |  16 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-3.c |  17 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-4.c |  16 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-5.c |  16 ++
 gcc/testsuite/gcc.target/powerpc/p9-vec-length-full-6.c |  16 ++
 

Re: ChangeLog files - server and client scripts

[Alexandre Oliva]

On May 25, 2020, Martin Liška  wrote:

> On 5/21/20 5:14 PM, Rainer Orth wrote:
>> * In changelog_location, you allow only (among others) "a/b/c/" and
>> "\ta/b/c/".  Please also accept the "a/b/c:" and "\ta/b/c:" forms
>> here: especially the second seems quite common.

> Ok, I believe these formats are supported as well. Feel free to mention
> some git revisions that are not recognized.

I've long used the following syntax to start ChangeLog entries:

for  /ChangeLog

It was introduced over 20 years ago, with the (so far never formally
released) GNU CVS-Utilities.  Among other goodies, there were scripts to
turn diffs for ChangeLog files into the above format, and vice-versa,
that I've used to this day.  It went through cvs, svn and git.  It would
be quite nice if I could keep on using it with GCC.

The patch below seems to be enough to pass gcc-verify, and to recognize
and print the expected ChangeLog files.  I suppose I'll have to adjust
the formatting to be able to push it, but, aside from that, is it ok to
install?

Do any hooks need to be adjusted to match?


I'm also a little concerned about '*/ChangeLog.*' files.  Are we no
longer supposed to introduce them, or new ChangeLog entries to them?  Or
should the scripts be extended to cover them?


for  contrib/ChangeLog

* gcc-changelog/git_commit.py (changelog_regex): Accept optional
'for' prefix.

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 2cfdbc8..b8362c1 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -144,7 +144,7 @@ misc_files = [
 author_line_regex = \
 re.compile(r'^(?P\d{4}-\d{2}-\d{2})\ {2}(?P.*  <.*>)')
 additional_author_regex = re.compile(r'^\t(?P\ *)?(?P.*  <.*>)')
-changelog_regex = re.compile(r'^([a-z0-9+-/]*)/ChangeLog:?')
+changelog_regex = re.compile(r'^(?:[fF]or +)([a-z0-9+-/]*)/ChangeLog:?')
 pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?([0-9]+)$')
 dr_regex = re.compile(r'\tDR ([0-9]+)$')
 star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')



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

Re: ChangeLog files - server and client scripts

[Alexandre Oliva]

On May 25, 2020, Martin Liška  wrote:

> On 5/21/20 5:14 PM, Rainer Orth wrote:
>> * In changelog_location, you allow only (among others) "a/b/c/" and
>> "\ta/b/c/".  Please also accept the "a/b/c:" and "\ta/b/c:" forms
>> here: especially the second seems quite common.

> Ok, I believe these formats are supported as well. Feel free to mention
> some git revisions that are not recognized.

I've long used the following syntax to start ChangeLog entries:

for  /ChangeLog

It was introduced over 20 years ago, with the (so far never formally
released) GNU CVS-Utilities.  Among other goodies, there were scripts to
turn diffs for ChangeLog files into the above format, and vice-versa,
that I've used to this day.  It went through cvs, svn and git.  It would
be quite nice if I could keep on using it with GCC.

The patch below seems to be enough to pass gcc-verify, and to recognize
and print the expected ChangeLog files.  I suppose I'll have to adjust
the formatting to be able to push it, but, aside from that, is it ok to
install?

Do any hooks need to be adjusted to match?


I'm also a little concerned about '*/ChangeLog.*' files.  Are we no
longer supposed to introduce them, or new ChangeLog entries to them?  Or
should the scripts be extended to cover them?


for  contrib/ChangeLog

* gcc-changelog/git_commit.py (changelog_regex): Accept optional
'for' prefix.

diff --git a/contrib/gcc-changelog/git_commit.py 
b/contrib/gcc-changelog/git_commit.py
index 2cfdbc8..b8362c1 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -144,7 +144,7 @@ misc_files = [
 author_line_regex = \
 re.compile(r'^(?P\d{4}-\d{2}-\d{2})\ {2}(?P.*  <.*>)')
 additional_author_regex = re.compile(r'^\t(?P\ *)?(?P.*  <.*>)')
-changelog_regex = re.compile(r'^([a-z0-9+-/]*)/ChangeLog:?')
+changelog_regex = re.compile(r'^(?:[fF]or +)([a-z0-9+-/]*)/ChangeLog:?')
 pr_regex = re.compile(r'\tPR (?P[a-z+-]+\/)?([0-9]+)$')
 dr_regex = re.compile(r'\tDR ([0-9]+)$')
 star_prefix_regex = re.compile(r'\t\*(?P\ *)(?P.*)')



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

[Bug c++/95326] GCC can not detect signed-integer-overflow correctly

[haoxintu at gmail dot com]

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

Haoxin Tu  changed:

   What|Removed |Added

Version|11.0|10.0

--- Comment #1 from Haoxin Tu  ---
I also found another case example.cpp

#include 

unsigned short g_var_ushort = 52781U;
const unsigned int g_const_uint = 2331271054U;

int main () {
//test_function();
short l_var_short = -14674;
volatile unsigned char l_volatile_uchar = 151U;
long l_var_long = 572469544701421587L;

g_var_ushort = l_volatile_uchar - l_var_short % g_const_uint * l_var_long;
std::cout << "hello" << std::endl;
return 0;
}

$g++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
hello

$clang++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
example.cpp:12:66: runtime error: signed integer overflow: 1963681568 *
572469544701421587 cannot be represented in type 'long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior example.cpp:12:66 in 
hello

My g++ version is
$g++ --version
g++ (GCC) 10.0.1 20200420 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I have tested all GCC versions including GCC-8, GCC-9, GCC-10, and GCC-Trunk in
Godbolt, they can not detect this UB as well.

Re: [IMPORTANT] ChangeLog related changes

[Hongtao Liu via Gcc]

On Tue, May 26, 2020 at 6:49 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> Hi!
>
> I've turned the strict mode of Martin Liška's hook changes,
> which means that from now on no commits to the trunk or release branches
> should be changing any ChangeLog files together with the other files,
> ChangeLog entry should be solely in the commit message.
> The DATESTAMP bumping script will be updating the ChangeLog files for you.
Oh, no wonder my patch was rejected by git hook with error message
---
ChangeLog files, DATESTAMP, BASE-VER and DEV-PHASE can be modified
only separately from other files
---
> If somebody makes a mistake in that, please wait 24 hours (at least until
i commit a separate patch alone only for ChangeLog files, should i revert it?
> after 00:16 UTC after your commit) so that the script will create the
> ChangeLog entries, and afterwards it can be fixed by adjusting the ChangeLog
> files.  But you can only touch the ChangeLog files in that case (and
> shouldn't write a ChangeLog entry for that in the commit message).
>
> If anything goes wrong, please let me, other RMs and Martin Liška know.
>
> Jakub
>

-- 
BR,
Hongtao

Re: [IMPORTANT] ChangeLog related changes

[Hongtao Liu via Gcc-patches]

On Tue, May 26, 2020 at 6:49 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> Hi!
>
> I've turned the strict mode of Martin Liška's hook changes,
> which means that from now on no commits to the trunk or release branches
> should be changing any ChangeLog files together with the other files,
> ChangeLog entry should be solely in the commit message.
> The DATESTAMP bumping script will be updating the ChangeLog files for you.
Oh, no wonder my patch was rejected by git hook with error message
---
ChangeLog files, DATESTAMP, BASE-VER and DEV-PHASE can be modified
only separately from other files
---
> If somebody makes a mistake in that, please wait 24 hours (at least until
i commit a separate patch alone only for ChangeLog files, should i revert it?
> after 00:16 UTC after your commit) so that the script will create the
> ChangeLog entries, and afterwards it can be fixed by adjusting the ChangeLog
> files.  But you can only touch the ChangeLog files in that case (and
> shouldn't write a ChangeLog entry for that in the commit message).
>
> If anything goes wrong, please let me, other RMs and Martin Liška know.
>
> Jakub
>

-- 
BR,
Hongtao

Re: [PATCH 1/2] Seperate -funroll-loops for GIMPLE unroller and RTL unroller

[Jiufu Guo via Gcc-patches]

David Edelsohn  writes:

> On Mon, May 25, 2020 at 1:58 PM Richard Biener
>  wrote:
>>
>> On May 25, 2020 7:40:00 PM GMT+02:00, Segher Boessenkool 
>>  wrote:
>> >On Mon, May 25, 2020 at 02:14:02PM +0200, Richard Biener wrote:
>> >> On Mon, May 25, 2020 at 1:10 PM guojiufu 
>> >wrote:
>> >> Since a new flag is not needed to fix the regression please avoid
>> >> adding -fcomplete-unroll-loops.
>> >>
>> >> For -frtl-unroll-loops you should be able to use
>> >
>> >Erm.  That *is* a new command-line option (the internal flags I do not
>> >care about so much: new implementation details are *good*).  And a new
>> >name that is a mistake in my opinion, for many reasons (users do not
>> >know and should not have to care about "rtl"; the name is not
>> >descriptive; it is useless churn, it is not the same name as we have
>> >had for decades now; it is adding a new option for a future where we
>> >will do most unrolling at gimple level, a future we do not know will
>> >ever exist, and we do not know what that will look like anyway; it is
>> >an extra level of indirection (in the name)).
>> >
>> >We should not have an -frtl-unroll-loops if we do not have a
>> >-ftree-unroll-loops (or whatever).
>> >
>> >Unrolling early is not a good idea in general (the problems with the
>> >very trivial complete unrolling case just underline that).  But we
>> >*should* know which code we expect to unroll later, for better costing.
>> >Adding names like "rtl-unroll-loops" only stands in the way of getting
>> >a better design here.
>>
>> You folks made ppc specific hacks instead of a better design. Those
>> now stand in the way as well. But sure, simply do not expose the
>> flag to the users, use
>> Var(flag_rtl_unroll_loops). My other points still stand.
>>
>> Feel free to ignore the regression part on the branch and come up
>> with a great design. But don't expect to backport that then.
>
> I completely agree.

Thanks a lot for all your comments, suggestions, and tips in the
discussion.  Thank Richar, Segher, David, Hanza, and all!

I may have an explanation about the intention of this work.

We know that loop unrolling is a complex and tickly thing.  It could
help some kinds of code in a great manner.  Sometimes there are side
effects.  For different types of loop and different platforms, it may
result in different effects.
It would makes sense to tune the loop unrolling accordingly.  And so, to
help and tune loop unrolling is what we want to do.

Currently, we have loop unroller at GIMPLE part (cunroll/cunrolli) and
RTL part.  There are some options (like -funroll-loops) and --params to
control unrollers.

Through target hook, it would be helpful for different platforms to tune
unroller: checking the type of loops, check optimization level.
Existing hooks may help with something, like turn --params.

Adding separate flags(or options) may be helpful to control different
behaviors independently.  This is one reason for the patch which
introduces internal undocumented options.

One previous patch, r10-4525, is tunning for ppc at -O2. Which
implements an existing hook for rs6000 to check simple loops for RTL
unroller. For cunroll, it just enables it even increasing size at -O2
directly, without check the type of the loops.  And then the
side/negative effects of cunroll are also visible at -O2 besides
positive effects.  In PR95018, the side effect is shown on complex loop
(early exit, and more peeling).
One idea is for cunroll to tune it to avoid side effects. And if the
heuristic is suitable, it would be helpful for other usage, like -O3 and
-funroll-loops.

Thanks for any comments!

Jiufu

>
> This path is digging a deeper and deeper hole.
>
> - David

[Bug c++/95326] New: UBsan can not detect signed-integer-overflow correctly

[haoxintu at gmail dot com]

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

Bug ID: 95326
   Summary: UBsan can not detect signed-integer-overflow correctly
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This case example.cpp

#include 

volatile wchar_t g_volatile_wchar = 2082494266;
volatile unsigned short g_volatile_ushort = 31503U;

int main () {
unsigned long l_var_ulong = 526562505494506029UL;
const wchar_t l_const_wchar = 1188246531;
g_volatile_ushort = l_var_ulong + l_const_wchar * g_volatile_wchar;
std::cout << "hello" << std::endl;
return 0;
}

can not detect signed-integer-overflow runtime error in gcc-trunk

$g++ -fsanitize=signed-integer-overflow example.cpp ; ./a.out
hello

But in clang-trunk
$clang++ -fsanitize=signed-integer-overflow test.cc ; ./a.out
example.cpp:9:53: runtime error: signed integer overflow: 1188246531 *
2082494266 cannot be represented in type 'int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior example.cpp:9:53 in 
hello

godbolt clang-trunk : https://godbolt.org/z/s4-AqW
godbolt gcc-trunk : https://godbolt.org/z/k7NhG6

Re: collect2.exe errors not pruned

[Alexandre Oliva]

On May 19, 2020, Joseph Myers  wrote:

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

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

Uhh, that would require matching pretty much anything, considering all
the potential per-language driver names, for pre-install testing, and
the arbitrary transforms, most commonly s,^,$target-, for post-install
testing.

Should we make the regexps '\[^\n\]*', as in so many other pruned
messages?

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

RE: [PATCH PR94026] combine missed opportunity to simplify comparisons with zero

[Yangfei (Felix)]

Hi,

> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Tuesday, May 26, 2020 12:27 AM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A) 
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
> comparisons with zero

Snip...

> > I am using Outlook and I didn't find the place to change the MIME type
> > : - (
> 
> The simplest option is to use a different email client, one that plays nicely
> with others.  You use git, maybe you could even use git-send-email?

The bad news is that it would be hard to switch to a different email client 
with my company's IT policy  :-( 
But I think I can ask IT if that is possible. Sorry for the trouble.

> I'll paste things manually...
> 
> > From a19238c02c1e6ab9593a14a13e1e3dff90ed Mon Sep 17 00:00:00
> 2001
> > From: Fei Yang 
> > Date: Mon, 25 May 2020 10:19:30 +0800
> > Subject: [PATCH] combine: missed opportunity to simplify comparisons
> > with zero  [PR94026]
> 
> (Capital "M" on "Missed" please)
> 
> But, the subject should say what the patch *does*.  So maybe
>   combine: Simplify more comparisons with zero (PR94026)

OK. 

> > If we have (and (lshiftrt X C) M) and M is a constant that would
> > select a field of bits within an item, but not the entire word, fold
> > this into a simple AND if we are in an equality comparison against zero.
> 
> But that subject doesn't really describe what the patch does, anyway?

OK.  Modified in the v4 patch.  Does it look better?

> > gcc/
> > PR rtl-optimization/94026
> > * combine.c (make_compound_operation_int): If we have (and
> > (lshiftrt X C) M) and M is a constant that would select a field
> > of bits within an item, but not the entire word, fold this into
> > a simple AND if we are in an equality comparison.
> >
> > gcc/testsuite/
> > PR rtl-optimization/94026
> > * gcc.dg/pr94026.c: New test.
> 
> > --- a/gcc/ChangeLog
> > +++ b/gcc/ChangeLog
> > @@ -1,3 +1,11 @@
> > +2020-05-25  Felix Yang  
> > +
> > +   PR rtl-optimization/94026
> > +   * combine.c (make_compound_operation_int): If we have (and
> > +   (lshiftrt X C) M) and M is a constant that would select a field
> > +   of bits within an item, but not the entire word, fold this into
> > +   a simple AND if we are in an equality comparison.
> 
> Don't put the changelog in the patch.

OK.  I paste it here:

gcc/ChangeLog

+2020-05-26  Felix Yang  
+
+   PR rtl-optimization/94026
+   * combine.c (make_compound_operation_int): If we have (and
+   (lshiftrt X C) M) and M is a constant that would select a field
+   of bits within an item, but not the entire word, fold this into
+   a simple AND if we are in an equality comparison.

gcc/testsuite/ChangeLog

+2020-05-26  Felix Yang  
+
+   PR rtl-optimization/94026
+   * gcc.dg/pr94026.c: New test.

> > diff --git a/gcc/combine.c b/gcc/combine.c index
> > b044f29fd36..76d62b0bd17 100644
> > --- a/gcc/combine.c
> > +++ b/gcc/combine.c
> > @@ -8178,6 +8178,10 @@ make_compound_operation_int
> (scalar_int_mode mode, rtx *x_ptr,
> >if (!CONST_INT_P (XEXP (x, 1)))
> > break;
> >
> > +  HOST_WIDE_INT pos;
> > +  unsigned HOST_WIDE_INT len;
> > +  pos = get_pos_from_mask (UINTVAL (XEXP (x, 1)), );
> 
>   unsigned HOST_WIDE_INT len;
>   HOST_WIDE_INT pos = get_pos_from_mask (UINTVAL (XEXP (x, 1)), );
> 
> > @@ -8231,6 +8235,22 @@ make_compound_operation_int
> (scalar_int_mode mode, rtx *x_ptr,
> >   new_rtx = make_compound_operation (new_rtx, in_code);
> > }
> >
> > +  /* If we have (and (lshiftrt X C) M) and M is a constant that would
> select
> > +a field of bits within an item, but not the entire word, this might be
> > +representable by a simple AND if we are in an equality comparison.
> */
> > +  else if (pos > 0 && equality_comparison
> 
> That "&& equality_comparison" should be on a separate line as well.

OK.

> > +  && GET_CODE (XEXP (x, 0)) == LSHIFTRT
> > +  && CONST_INT_P (XEXP (XEXP (x, 0), 1))
> > +  && pos + UINTVAL (XEXP (XEXP (x, 0), 1))
> > + <= GET_MODE_BITSIZE (mode))
> > +   {
> > + new_rtx = make_compound_operation (XEXP (XEXP (x, 0), 0),
> next_code);
> > + HOST_WIDE_INT real_pos = pos + UINTVAL (XEXP (XEXP (x, 0), 1));
> > + unsigned HOST_WIDE_INT mask = ((unsigned HOST_WIDE_INT)1 <<
> len) -
> > +1;
> 
> Space after cast.

OK.

> > + new_rtx = gen_rtx_AND (mode, new_rtx,
> > +gen_int_mode (mask << real_pos, mode));
> > +   }
> 
> So this changes
>   ((X >> C) & M) == ...
> to
>   (X & (M << C)) == ...
> ?
> 
> Where then does it check what ... is?  This is only valid like this if that 
> is zero.
> 
> Why should this go in combine and not in simplify-rtx instead?

True.  This is only valid when ... is zero.
That's why we need the "&& equality_comparison " condition here.

> > --- /dev/null
> > +++ 

[Bug target/95256] [11 Regression] ICE in convert_move, at expr.c:278 since r11-263-g7c355156aa20eaec

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:9d0dc47de6ed9609fe7445ea0941a6a822c80f88

commit r11-621-g9d0dc47de6ed9609fe7445ea0941a6a822c80f88
Author: liuhongt 
Date:   Tue May 26 11:14:31 2020 +0800

Fix non-comforming expander for
floatv2div2sf2,floatunsv2div2sf2,fix_truncv2sfv2di,fixuns_truncv2sfv2di.

2020-05-26  Hongtao Liu  
Uroš Bizjak  

gcc/ChangeLog:
PR target/95211
PR target/95256
* config/i386/sse.md (v2div2sf2): New expander.
(fix_truncv2sfv2di2): Ditto.
(avx512dq_floatv2div2sf2): Renaming from
floatv2div2sf2.
(avx512dq_fix_truncv2sfv2di2):
Renaming from fix_truncv2sfv2di2.
(vec_pack_float_): Adjust icode name.
(vec_unpack_fix_trunc_lo_): Ditto.
(vec_unpack_fix_trunc_hi_): Ditto.
* config/i386/i386-builtin.def: Ditto.
* emit-rtl.c (validate_subreg): Allow use of *paradoxical* vector
subregs when both omode and imode are vector mode and
have the same inner mode.

gcc/testsuite/ChangeLog
* gcc.target/i386/pr95211.c: New test.

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:9d0dc47de6ed9609fe7445ea0941a6a822c80f88

commit r11-621-g9d0dc47de6ed9609fe7445ea0941a6a822c80f88
Author: liuhongt 
Date:   Tue May 26 11:14:31 2020 +0800

Fix non-comforming expander for
floatv2div2sf2,floatunsv2div2sf2,fix_truncv2sfv2di,fixuns_truncv2sfv2di.

2020-05-26  Hongtao Liu  
Uroš Bizjak  

gcc/ChangeLog:
PR target/95211
PR target/95256
* config/i386/sse.md (v2div2sf2): New expander.
(fix_truncv2sfv2di2): Ditto.
(avx512dq_floatv2div2sf2): Renaming from
floatv2div2sf2.
(avx512dq_fix_truncv2sfv2di2):
Renaming from fix_truncv2sfv2di2.
(vec_pack_float_): Adjust icode name.
(vec_unpack_fix_trunc_lo_): Ditto.
(vec_unpack_fix_trunc_hi_): Ditto.
* config/i386/i386-builtin.def: Ditto.
* emit-rtl.c (validate_subreg): Allow use of *paradoxical* vector
subregs when both omode and imode are vector mode and
have the same inner mode.

gcc/testsuite/ChangeLog
* gcc.target/i386/pr95211.c: New test.

[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"

[bouanto at zoho dot com]

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

--- Comment #1 from bouanto at zoho dot com ---
A similar error happens for the builtin "memcpy":

error: unimplemented primitive type for builtin: 38

[Bug jit/95325] New: Support 128-bit integers

[bouanto at zoho dot com]

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

Bug ID: 95325
   Summary: Support 128-bit integers
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
Would it be possible to add support for 128-bit integers in libgccjit?
Thanks.

[Bug c++/95324] New: Segmentation fault when using variadic lambda template in concept definition

[ivan.pogrebnyak at gmail dot com]

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

Bug ID: 95324
   Summary: Segmentation fault when using variadic lambda template
in concept definition
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivan.pogrebnyak at gmail dot com
  Target Milestone: ---

Created attachment 48600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48600=edit
gcc version, output, and -save-temps

Definition of the following concept (using C++20) causes segmentation fault in
GCC 10.1.0.

template 
concept Applyable =
  [](std::index_sequence) {
return std::is_invocable_v...>;
  }(std::make_index_sequence>{});

Refactoring the definition into a `constexpr bool` and using it in the concept
definition works.

See the attachment for details.

[Bug c++/95222] [10/11 Regression] GCC 10.1 x86 issue with function pointers with calling convention attribute and template specialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jason Merrill  ---
Fixed for 8.5/9.4/10.2/11.

[Bug c++/90212] [8 Regression] by-ref capture of constexpr class object rejected

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8 Regression] by-ref
   |by-ref capture of constexpr |capture of constexpr class
   |class object rejected   |object rejected

--- Comment #5 from Jason Merrill  ---
Fixed for 9.4/10.2/11.  Is this important to fix in GCC 8?

[IMPORTANT] ChangeLog related changes

[Jakub Jelinek via Gcc]

Hi!

I've turned the strict mode of Martin Liška's hook changes,
which means that from now on no commits to the trunk or release branches
should be changing any ChangeLog files together with the other files,
ChangeLog entry should be solely in the commit message.
The DATESTAMP bumping script will be updating the ChangeLog files for you.
If somebody makes a mistake in that, please wait 24 hours (at least until
after 00:16 UTC after your commit) so that the script will create the
ChangeLog entries, and afterwards it can be fixed by adjusting the ChangeLog
files.  But you can only touch the ChangeLog files in that case (and
shouldn't write a ChangeLog entry for that in the commit message).

If anything goes wrong, please let me, other RMs and Martin Liška know.

Jakub

[IMPORTANT] ChangeLog related changes

[Jakub Jelinek via Gcc-patches]

Hi!

I've turned the strict mode of Martin Liška's hook changes,
which means that from now on no commits to the trunk or release branches
should be changing any ChangeLog files together with the other files,
ChangeLog entry should be solely in the commit message.
The DATESTAMP bumping script will be updating the ChangeLog files for you.
If somebody makes a mistake in that, please wait 24 hours (at least until
after 00:16 UTC after your commit) so that the script will create the
ChangeLog entries, and afterwards it can be fixed by adjusting the ChangeLog
files.  But you can only touch the ChangeLog files in that case (and
shouldn't write a ChangeLog entry for that in the commit message).

If anything goes wrong, please let me, other RMs and Martin Liška know.

Jakub

[Bug c++/90749] [8/9/10 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13462

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Jason Merrill  ---
Fixed for 8.5/9.4/10.2/11.

[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jason Merrill  ---
Fixed for 8.5/9.4/10.2/11.

[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:487f16a7f2a6f849497a0d2f8fff61225e2270f6

commit r8-10272-g487f16a7f2a6f849497a0d2f8fff61225e2270f6
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: generic lambda and -fsanitize=vla-bound [PR93822]

Within the generic lambda the VLA capture proxy VAR_DECL has
DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy.  The problem here was
that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
different (though equivalent) types.  Then gimplify_type_sizes fixed up the
type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
to sadness.

Fixed by directly reusing the type from the DECL.

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

PR c++/93822
* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
the same type as the variable.

[Bug c++/90749] [8/9/10 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13462

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:bc721725161c6ee3813870a734c0b0c18429a922

commit r8-10274-gbc721725161c6ee3813870a734c0b0c18429a922
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: Local class DMI using local static [PR90749]

For default member initializers in templates it's important to push into
the
right context during get_nsdmi.  But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.

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

PR c++/90749
* init.c (get_nsdmi): Don't push_to_top_level for a local class.

[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:09831707ce65606f951c97632d882f083ad3ed02

commit r8-10273-g09831707ce65606f951c97632d882f083ad3ed02
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: -fmerge-all-constants vs. destructors [PR91529]

cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants
was
converting an automatic variable to static while leaving TREE_READONLY set.

Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerge-all-constants.

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

PR c++/91529
* decl.c (cp_finish_decl): Also clear TREE_READONLY if
-fmerge-all-constants.

[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:f76202e096fc0be4db21761399b55f10cd09b20d

commit r9-8621-gf76202e096fc0be4db21761399b55f10cd09b20d
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: -fmerge-all-constants vs. destructors [PR91529]

cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants
was
converting an automatic variable to static while leaving TREE_READONLY set.

Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerge-all-constants.

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

PR c++/91529
* decl.c (cp_finish_decl): Also clear TREE_READONLY if
-fmerge-all-constants.

[Bug c++/90212] [8/9/10/11 Regression] by-ref capture of constexpr class object rejected

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:0296697cf9893dc9509cdcd8e3fd4ba9fe422527

commit r9-8623-g0296697cf9893dc9509cdcd8e3fd4ba9fe422527
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: constexpr and lambda capture [PR90212]

This is the same issue as PR86429, just in potential_constant_expression_1
rather than cxx_eval_constant_expression.  As in that case, when we're
trying to evaluate a constant expression within a lambda, we don't have a
constant closure object to refer to, but we can try to refer directly to
the
captured variable.

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

PR c++/90212
* constexpr.c (potential_constant_expression_1): In a lambda
function, consider a captured variable directly.

[Bug target/90479] gcc-arm-none-eabi-8-2018-q4-major [c99 plus -pg not working]

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:e153e0ef3a35c2c72e8bf89bd905fe27f8877852

commit r9-8622-ge153e0ef3a35c2c72e8bf89bd905fe27f8877852
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: Local class DMI using local static [PR90479]

For default member initializers in templates it's important to push into
the
right context during get_nsdmi.  But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.

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

PR c++/90479
* init.c (get_nsdmi): Don't push_to_top_level for a local class.

[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:91664c43c0acf56fd86643530e4b0be78a06446c

commit r9-8620-g91664c43c0acf56fd86643530e4b0be78a06446c
Author: Jason Merrill 
Date:   Mon May 25 18:38:09 2020 -0400

c++: generic lambda and -fsanitize=vla-bound [PR93822]

Within the generic lambda the VLA capture proxy VAR_DECL has
DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy.  The problem here was
that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
different (though equivalent) types.  Then gimplify_type_sizes fixed up the
type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
to sadness.

Fixed by directly reusing the type from the DECL.

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

PR c++/93822
* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
the same type as the variable.

[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:01ff88c5619897198117b1a460d48774cfcdf396

commit r10-8181-g01ff88c5619897198117b1a460d48774cfcdf396
Author: Jason Merrill 
Date:   Mon May 25 18:04:39 2020 -0400

c++: -fmerge-all-constants vs. destructors [PR91529]

cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants
was
converting an automatic variable to static while leaving TREE_READONLY set.

Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerge-all-constants.

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

PR c++/91529
* decl.c (cp_finish_decl): Also clear TREE_READONLY if
-fmerge-all-constants.

[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:4cee81365ad32ef947f500e4cf4b3514d88236c9

commit r10-8180-g4cee81365ad32ef947f500e4cf4b3514d88236c9
Author: Jason Merrill 
Date:   Mon May 25 18:04:39 2020 -0400

c++: generic lambda and -fsanitize=vla-bound [PR93822]

Within the generic lambda the VLA capture proxy VAR_DECL has
DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy.  The problem here was
that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
different (though equivalent) types.  Then gimplify_type_sizes fixed up the
type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
to sadness.

Fixed by directly reusing the type from the DECL.

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

PR c++/93822
* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
the same type as the variable.

[Bug target/90479] gcc-arm-none-eabi-8-2018-q4-major [c99 plus -pg not working]

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:c79e664b153bd4cfdeec77b495d595e50b97c752

commit r10-8182-gc79e664b153bd4cfdeec77b495d595e50b97c752
Author: Jason Merrill 
Date:   Mon May 25 18:04:39 2020 -0400

c++: Local class DMI using local static [PR90749]

For default member initializers in templates it's important to push into
the
right context during get_nsdmi.  But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.

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

PR c++/90479
* init.c (get_nsdmi): Don't push_to_top_level for a local class.

[Bug c++/90212] [8/9/10/11 Regression] by-ref capture of constexpr class object rejected

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:aa613a81831bdc044840a95a7a7803a235608503

commit r10-8183-gaa613a81831bdc044840a95a7a7803a235608503
Author: Jason Merrill 
Date:   Mon May 25 18:04:39 2020 -0400

c++: constexpr and lambda capture [PR90212]

This is the same issue as PR86429, just in potential_constant_expression_1
rather than cxx_eval_constant_expression.  As in that case, when we're
trying to evaluate a constant expression within a lambda, we don't have a
constant closure object to refer to, but we can try to refer directly to
the
captured variable.

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

PR c++/90212
* constexpr.c (potential_constant_expression_1): In a lambda
function, consider a captured variable directly.

[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-25
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jim Wilson  ---
It appears to be failing in the rename register (rnreg) pass.  This is because
the unspec patterns for the save/restore calls don't mention the registers that
they use/modify.  This confuses rename reg into thinking that live regs are
dead, and it accidentally clobbers them before the save call.  This worked OK
when save/restore calls could only be at the beginning or end of a function. 
But now that this works with tail calls and shrink wrapping, we can get them in
inner blocks.  Since the different save/restore calls use/modify different sets
of registers, fixing this gets a little complicated.  Maybe we can just use the
max list of registers because listing extra ones shouldn't matter?

Another solution is to disable the rename register pass when -msave-restore is
used.  This isn't doing any checking for whether regs can be used in compressed
instructions or not.  This is currently encoded in REG_ALLOC_ORDER which this
pass doesn't use.  The result is that this is probably increasing code size
which is undesirable when -msave-restore it used.  Disabling this would reduce
code size and fix the -msave-restore problem.

The rename register pass does use the PREFERRED_RENAME_CLASS hook that we
haven't defined.  We should try defining this to convert registers classes to
subsets that only include the regs that can be used in compressed instructions.
 This might result in a code size decrease.  If this works, then the rename reg
pass should not be disabled, and we should find a way to fix the save/restore
pattern register lists instead.

I need to do some builds and experiments to verify this info.

Re: [PATCH RFC] gcc-git: Add prepare-commit-msg hook.

[Jason Merrill via Gcc-patches]

On 5/25/20 4:15 PM, Martin Liška wrote:

On 5/25/20 10:08 PM, Jason Merrill wrote:

Like so:


I like the patch, thanks!

The last question I have: Do we want to make installation of the hook
optional in gcc-git-customization.sh?


Sure:

>From 04429ee04769e15842093f154e8c7887f75d9476 Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Fri, 22 May 2020 18:40:35 -0400
Subject: [PATCH] gcc-git: Add prepare-commit-msg hook.
To: gcc-patches@gcc.gnu.org

This patch introduces a prepare-commit-msg hook that appends a ChangeLog
skeleton to a commit message when the GCC_FORCE_MKLOG environment variable
is set, and a 'git commit-mklog' command set that variable while running
'git commit'.

contrib/ChangeLog:

	* prepare-commit-msg: New file.
	* gcc-git-customization.sh: Install it.  Add commit-mklog alias.
	* mklog.py: Add new option -c which appends
	to a ChangeLog file.
---
 contrib/gcc-git-customization.sh | 13 
 contrib/mklog.py | 23 -
 contrib/prepare-commit-msg   | 57 
 3 files changed, 92 insertions(+), 1 deletion(-)
 create mode 100755 contrib/prepare-commit-msg

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 7a950ae5f38..dcc42683fa6 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -30,6 +30,8 @@ git config alias.gcc-backport '!f() { rev=$1; git cherry-pick -x $@; } ; f'
 
 git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
 
+git config alias.commit-mklog '!f() { GCC_FORCE_MKLOG=1 git commit "$@"; }; f'
+
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
 # *.mddiff=md
@@ -127,6 +129,17 @@ echo "(local branches starting / can be pushed directly to your"
 ask "personal area on the gcc server)" $old_pfx new_pfx
 git config "gcc-config.userpfx" "$new_pfx"
 
+echo
+ask "Install prepare-commit-msg git hook for 'git commit-mklog' alias" yes dohook
+if [ "x$dohook" = xyes ]; then
+hookdir=`git rev-parse --git-path hooks`
+if [ -f "$hookdir/prepare-commit-msg" ]; then
+	echo " Moving existing prepare-commit-msg hook to prepare-commit-msg.bak"
+	mv "$hookdir/prepare-commit-msg" "$hookdir/prepare-commit-msg.bak"
+fi
+install -c "`git rev-parse --show-toplevel`/contrib/prepare-commit-msg" "$hookdir"
+fi
+
 # Scan the existing settings to see if there are any we need to rewrite.
 vendors=$(git config --get-all "remote.${upstream}.fetch" "refs/vendors/" | sed -r "s:.*refs/vendors/([^/]+)/.*:\1:" | sort | uniq)
 url=$(git config --get "remote.${upstream}.url")
diff --git a/contrib/mklog.py b/contrib/mklog.py
index 7a19b5d0949..fb58661b5eb 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -30,6 +30,7 @@ import argparse
 import os
 import re
 import sys
+from itertools import takewhile
 
 import requests
 
@@ -221,6 +222,9 @@ if __name__ == '__main__':
 help='Do not generate function names in ChangeLogs')
 parser.add_argument('-p', '--fill-up-bug-titles', action='store_true',
 help='Download title of mentioned PRs')
+parser.add_argument('-c', '--changelog',
+help='Append the ChangeLog to a git commit message '
+ 'file')
 args = parser.parse_args()
 if args.input == '-':
 args.input = None
@@ -229,4 +233,21 @@ if __name__ == '__main__':
 data = input.read()
 output = generate_changelog(data, args.no_functions,
 args.fill_up_bug_titles)
-print(output, end='')
+if args.changelog:
+lines = open(args.changelog).read().split('\n')
+start = list(takewhile(lambda l: not l.startswith('#'), lines))
+end = lines[len(start):]
+with open(args.changelog, 'w') as f:
+if start:
+# appent empty line
+if start[-1] != '':
+start.append('')
+else:
+# append 2 empty lines
+start = 2 * ['']
+f.write('\n'.join(start))
+f.write('\n')
+f.write(output)
+f.write('\n'.join(end))
+else:
+print(output, end='')
diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
new file mode 100755
index 000..820dacc7e42
--- /dev/null
+++ b/contrib/prepare-commit-msg
@@ -0,0 +1,57 @@
+#!/bin/sh
+
+# Copyright (C) 2020 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR 

[no subject]

[اسد فاهم via Gcc]

تنزيل الغه العربيه

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Brett Neumeier from comment #9)
> Confirmed, the issue does not occur with 2.33.1. Thank you for your
> attention and help!

Please CC me on the binutils bug (just so I can keep track of it).

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

Brett Neumeier  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||bneumeier at gmail dot com
 Status|WAITING |RESOLVED

--- Comment #9 from Brett Neumeier  ---
Confirmed, the issue does not occur with 2.33.1. Thank you for your attention
and help!

[Bug tree-optimization/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
  Component|fortran |tree-optimization
 Status|WAITING |NEW

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to David Binderman from comment #3)
> (In reply to anlauf from comment #1)
> > local.f90:3: Error: Can't open included file 'SIZES'
> > 
> > Please include everything needed to reproduce.
> 
> Done.
> 
> > Are you sure this is a fortran bug, rather than tree-optimization?
> 
> Not using -O2 makes the code compile, so something in the optimiser
> is going wrong, triggered by Fortran source code.

OK, using -O0, -Og, or -Os makes the code compile, -O1, -O2 or higher ICEs.

This looks fishy.

I'd prefer someone with better middle-end knowledge to look at it.

[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Patch submmitted for review:

https://gcc.gnu.org/pipermail/fortran/2020-May/054385.html

[PATCH] PR fortran/95089 - ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[Harald Anlauf]

Another rather obvious case of a buffer too small to hold a name-mangled symbol,
this time with coarrays enabled.

OK for master?

Thanks,
Harald


PR fortran/95089 - ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

For long module name, derive type and component name, the
generated name-mangled symbol did not fit into a buffer when
coarrays were enabled.  Provide sufficiently large temporary.

gcc/fortran/

2020-05-25  Harald Anlauf  

PR fortran/95089
* trans-types.c (gfc_get_derived_type): Enlarge temporary to hold
mangled name "_caf_symbol".

gcc/testsuite/

2020-05-25  Harald Anlauf  

PR fortran/95089
* gfortran.dg/pr95089.f90: New test.
diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index b7712dc74d1..99844812505 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2836,9 +2836,10 @@ copy_derived_types:
 	  && (c->attr.allocatable || c->attr.pointer)
 	  && !derived->attr.is_class)
 	{
-	  char caf_name[GFC_MAX_SYMBOL_LEN];
+	  /* Provide sufficient space to hold "_caf_symbol".  */
+	  char caf_name[GFC_MAX_SYMBOL_LEN + 6];
 	  gfc_component *token;
-	  snprintf (caf_name, GFC_MAX_SYMBOL_LEN, "_caf_%s", c->name);
+	  snprintf (caf_name, sizeof (caf_name), "_caf_%s", c->name);
 	  token = gfc_find_component (derived, caf_name, true, true, NULL);
 	  gcc_assert (token);
 	  c->caf_token = token->backend_decl;
diff --git a/gcc/testsuite/gfortran.dg/pr95089.f90 b/gcc/testsuite/gfortran.dg/pr95089.f90
new file mode 100644
index 000..1cd20f0ccc5
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr95089.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+!
+! PR fortran/95089 - ICE in gfc_get_derived_type, at fortran/trans-types.c:2843
+
+module m23456789012345678901234567890123456789012345678901234567890123
+  type t23456789012345678901234567890123456789012345678901234567890123
+ type (t23456789012345678901234567890123456789012345678901234567890123), &
+  pointer :: z23456789012345678901234567890123456789012345678901234567890123
+  end type t23456789012345678901234567890123456789012345678901234567890123
+end

[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Obvious fix:

diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index b7712dc74d1..99844812505 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2836,9 +2836,10 @@ copy_derived_types:
  && (c->attr.allocatable || c->attr.pointer)
  && !derived->attr.is_class)
{
- char caf_name[GFC_MAX_SYMBOL_LEN];
+ /* Provide sufficient space to hold "_caf_symbol".  */
+ char caf_name[GFC_MAX_SYMBOL_LEN + 6];
  gfc_component *token;
- snprintf (caf_name, GFC_MAX_SYMBOL_LEN, "_caf_%s", c->name);
+ snprintf (caf_name, sizeof (caf_name), "_caf_%s", c->name);
  token = gfc_find_component (derived, caf_name, true, true, NULL);
  gcc_assert (token);
  c->caf_token = token->backend_decl;

[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to anlauf from comment #1)
> local.f90:3: Error: Can't open included file 'SIZES'
> 
> Please include everything needed to reproduce.

Done.

> Are you sure this is a fortran bug, rather than tree-optimization?

Not using -O2 makes the code compile, so something in the optimiser
is going wrong, triggered by Fortran source code.

Re: ChangeLog files - server and client scripts

[Ian Lance Taylor via Gcc]

On Mon, May 25, 2020 at 12:48 AM Martin Liška  wrote:
>
> On 5/23/20 12:14 AM, Ian Lance Taylor wrote:
> > Sure, I can wait.  Thanks for looking at it.
>
> Hello.
>
> Thank you for patience. There's a patch that fixes that,
> I'm going to install it.

Thanks.  I was able to push my change to master.

Ian

Re: ChangeLog files - server and client scripts

[Ian Lance Taylor via Gcc-patches]

On Mon, May 25, 2020 at 12:48 AM Martin Liška  wrote:
>
> On 5/23/20 12:14 AM, Ian Lance Taylor wrote:
> > Sure, I can wait.  Thanks for looking at it.
>
> Hello.
>
> Thank you for patience. There's a patch that fixes that,
> I'm going to install it.

Thanks.  I was able to push my change to master.

Ian

[Bug fortran/95089] [Coarray] ICE in gfc_get_derived_type, at fortran/trans-types.c:2843

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-05-25
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
Summary|ICE in  |[Coarray] ICE in
   |gfc_get_derived_type, at|gfc_get_derived_type, at
   |fortran/trans-types.c:2843  |fortran/trans-types.c:2843
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
All versions from 7 to 11 (master) ICE.

Confirmed.

libgo patch committed: update x/sys/cpu after gccgo support added

[Ian Lance Taylor via Gcc-patches]

This libgo patch updates the x/sys/cpu directory with better support
for gccgo on AIX.  Bootstrapped and ran Go tests on
x86_64-pc-linux-gnu.  Committed to master.

Ian
e479602af14fc5e76c9040846b2f5e85e126a472
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index bc9c1f07eda..284374820b0 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-bc27341f245a5cc54ac7530d037a609db72b677c
+ea58b8491064fbed18a220571a3043c38dccf7c7
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/golang.org/x/sys/cpu/cpu_aix.go 
b/libgo/go/golang.org/x/sys/cpu/cpu_aix.go
new file mode 100644
index 000..02d03129e50
--- /dev/null
+++ b/libgo/go/golang.org/x/sys/cpu/cpu_aix.go
@@ -0,0 +1,32 @@
+// Copyright 2019 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// +build aix
+
+package cpu
+
+const (
+   // getsystemcfg constants
+   _SC_IMPL = 2
+   _IMPL_POWER8 = 0x1
+   _IMPL_POWER9 = 0x2
+)
+
+func init() {
+   impl := getsystemcfg(_SC_IMPL)
+   if impl&_IMPL_POWER8 != 0 {
+   PPC64.IsPOWER8 = true
+   }
+   if impl&_IMPL_POWER9 != 0 {
+   PPC64.IsPOWER9 = true
+   }
+
+   Initialized = true
+}
+
+func getsystemcfg(label int) (n uint64) {
+   r0, _ := callgetsystemcfg(label)
+   n = uint64(r0)
+   return
+}
diff --git a/libgo/go/golang.org/x/sys/cpu/cpu_aix_ppc64.go 
b/libgo/go/golang.org/x/sys/cpu/cpu_aix_ppc64.go
deleted file mode 100644
index b0ede112d4e..000
--- a/libgo/go/golang.org/x/sys/cpu/cpu_aix_ppc64.go
+++ /dev/null
@@ -1,32 +0,0 @@
-// Copyright 2019 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-// +build aix,ppc64
-
-package cpu
-
-const (
-   // getsystemcfg constants
-   _SC_IMPL = 2
-   _IMPL_POWER8 = 0x1
-   _IMPL_POWER9 = 0x2
-)
-
-func init() {
-   impl := getsystemcfg(_SC_IMPL)
-   if impl&_IMPL_POWER8 != 0 {
-   PPC64.IsPOWER8 = true
-   }
-   if impl&_IMPL_POWER9 != 0 {
-   PPC64.IsPOWER9 = true
-   }
-
-   Initialized = true
-}
-
-func getsystemcfg(label int) (n uint64) {
-   r0, _ := callgetsystemcfg(label)
-   n = uint64(r0)
-   return
-}
diff --git a/libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go 
b/libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go
new file mode 100644
index 000..2609cc49ae7
--- /dev/null
+++ b/libgo/go/golang.org/x/sys/cpu/syscall_aix_gccgo.go
@@ -0,0 +1,27 @@
+// Copyright 2020 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// Recreate a getsystemcfg syscall handler instead of
+// using the one provided by x/sys/unix to avoid having
+// the dependency between them. (See golang.org/issue/32102)
+// Morover, this file will be used during the building of
+// gccgo's libgo and thus must not use a CGo method.
+
+// +build aix
+// +build gccgo
+
+package cpu
+
+import (
+   "syscall"
+)
+
+//extern getsystemcfg
+func gccgoGetsystemcfg(label uint32) (r uint64)
+
+func callgetsystemcfg(label int) (r1 uintptr, e1 syscall.Errno) {
+   r1 = uintptr(gccgoGetsystemcfg(uint32(label)))
+   e1 = syscall.GetErrno()
+   return
+}

[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Created attachment 48599
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48599=edit
Fortran header file

[Bug fortran/95323] ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-25
 Status|UNCONFIRMED |WAITING

--- Comment #1 from anlauf at gcc dot gnu.org ---
local.f90:3: Error: Can't open included file 'SIZES'

Please include everything needed to reproduce.

Are you sure this is a fortran bug, rather than tree-optimization?

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
Note I think it is related to the fixes that was done for
https://sourceware.org/bugzilla/show_bug.cgi?id=2 which was fixed in 2.34.

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Brett Neumeier from comment #6)
> I can try again with 2.33.1 and see if I get different results, if that
> would help?

If it works with 2.33.1, can you report this directly to binutils:
https://sourceware.org/bugzilla ?  Since this is a bug in binutils as far as I
can tell.

Re: [PATCH RFC] gcc-git: Add prepare-commit-msg hook.

[Martin Liška]

On 5/25/20 10:08 PM, Jason Merrill wrote:

Like so:


I like the patch, thanks!

The last question I have: Do we want to make installation of the hook
optional in gcc-git-customization.sh?

Martin

New Swedish PO file for 'gcc' (version 10.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-10.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.

Re: [PATCH RFC] gcc-git: Add prepare-commit-msg hook.

[Jason Merrill via Gcc-patches]

On Mon, May 25, 2020 at 3:50 PM Jason Merrill  wrote:
> On Mon, May 25, 2020 at 2:14 PM Martin Liška  wrote:
> >
> > On 5/23/20 11:39 PM, Jason Merrill via Gcc-patches wrote:
> > > This patch introduces a prepare-commit-msg hook that appends a ChangeLog
> > > skeleton to a commit message that doesn't already have one, and a 'git
> > > amend-mklog' command to amend and append a new ChangeLog skeleton (to be
> > > edited together with existing entries by hand).
> >
> > As mentioned in the previous email, I prefer to make it opt-in, not opt-out.
> >
> > So I'm suggesting the 'git commit-mklog' alias that add the skeleton to
> > a git commit message.
> >
> > I also changed the hook to use named variables. And I would like to preserve
> > the ending '# Please enter the commit message for your changes. Lines 
> > starting'
> > section, so I use the mklog.py to put the skeleton to a proper place.
> >
> > Example:
> >
> > gcc/ChangeLog:
> >
> > * ipa-icf.c (make_pass_ipa_icf):
> >
> > # Please enter the commit message for your changes. Lines starting
> > # with '#' will be ignored, and an empty message aborts the commit.
> > #
> > # On branch me/add-prepare-commit-msg-hook
> > # Changes to be committed:
> > #   modified:   gcc/ipa-icf.c
> > #
> >
> > Thoughts?
>
> I'll integrate your changes with mine.

Like so:
From 47424e02f3d7c5e01e292c43e0d5f5d932178d31 Mon Sep 17 00:00:00 2001
From: Jason Merrill 
Date: Fri, 22 May 2020 18:40:35 -0400
Subject: [PATCH] gcc-git: Add prepare-commit-msg hook.
To: gcc-patches@gcc.gnu.org

This patch introduces a prepare-commit-msg hook that appends a ChangeLog
skeleton to a commit message when the GCC_FORCE_MKLOG environment variable
is set, and a 'git commit-mklog' command set that variable while running
'git commit'.

contrib/ChangeLog:

	* prepare-commit-msg: New file.
	* gcc-git-customization.sh: Install it.  Add commit-mklog alias.
	* mklog.py: Add new option -c which appends
	to a ChangeLog file.
---
 contrib/gcc-git-customization.sh |  5 +++
 contrib/mklog.py | 23 -
 contrib/prepare-commit-msg   | 57 
 3 files changed, 84 insertions(+), 1 deletion(-)
 create mode 100755 contrib/prepare-commit-msg

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 7a950ae5f38..a3f7da8d20b 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -30,6 +30,11 @@ git config alias.gcc-backport '!f() { rev=$1; git cherry-pick -x $@; } ; f'
 
 git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
 
+hookdir=`git rev-parse --git-path hooks`
+install "`git rev-parse --show-toplevel`/contrib/prepare-commit-msg" "$hookdir"
+
+git config alias.commit-mklog '!f() { GCC_FORCE_MKLOG=1 git commit "$@"; }; f'
+
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
 # *.mddiff=md
diff --git a/contrib/mklog.py b/contrib/mklog.py
index 7a19b5d0949..fb58661b5eb 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -30,6 +30,7 @@ import argparse
 import os
 import re
 import sys
+from itertools import takewhile
 
 import requests
 
@@ -221,6 +222,9 @@ if __name__ == '__main__':
 help='Do not generate function names in ChangeLogs')
 parser.add_argument('-p', '--fill-up-bug-titles', action='store_true',
 help='Download title of mentioned PRs')
+parser.add_argument('-c', '--changelog',
+help='Append the ChangeLog to a git commit message '
+ 'file')
 args = parser.parse_args()
 if args.input == '-':
 args.input = None
@@ -229,4 +233,21 @@ if __name__ == '__main__':
 data = input.read()
 output = generate_changelog(data, args.no_functions,
 args.fill_up_bug_titles)
-print(output, end='')
+if args.changelog:
+lines = open(args.changelog).read().split('\n')
+start = list(takewhile(lambda l: not l.startswith('#'), lines))
+end = lines[len(start):]
+with open(args.changelog, 'w') as f:
+if start:
+# appent empty line
+if start[-1] != '':
+start.append('')
+else:
+# append 2 empty lines
+start = 2 * ['']
+f.write('\n'.join(start))
+f.write('\n')
+f.write(output)
+f.write('\n'.join(end))
+else:
+print(output, end='')
diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
new file mode 100755
index 000..820dacc7e42
--- /dev/null
+++ b/contrib/prepare-commit-msg
@@ -0,0 +1,57 @@
+#!/bin/sh
+
+# Copyright (C) 2020 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU 

Re: [PATCH RFC] gcc-git: Add prepare-commit-msg hook.

[Jason Merrill via Gcc-patches]

I'll integrate your changes with mine.

On Mon, May 25, 2020 at 2:14 PM Martin Liška  wrote:
>
> On 5/23/20 11:39 PM, Jason Merrill via Gcc-patches wrote:
> > This patch introduces a prepare-commit-msg hook that appends a ChangeLog
> > skeleton to a commit message that doesn't already have one, and a 'git
> > amend-mklog' command to amend and append a new ChangeLog skeleton (to be
> > edited together with existing entries by hand).
>
> As mentioned in the previous email, I prefer to make it opt-in, not opt-out.
>
> So I'm suggesting the 'git commit-mklog' alias that add the skeleton to
> a git commit message.
>
> I also changed the hook to use named variables. And I would like to preserve
> the ending '# Please enter the commit message for your changes. Lines 
> starting'
> section, so I use the mklog.py to put the skeleton to a proper place.
>
> Example:
>
> gcc/ChangeLog:
>
> * ipa-icf.c (make_pass_ipa_icf):
>
> # Please enter the commit message for your changes. Lines starting
> # with '#' will be ignored, and an empty message aborts the commit.
> #
> # On branch me/add-prepare-commit-msg-hook
> # Changes to be committed:
> #   modified:   gcc/ipa-icf.c
> #
>
> Thoughts?
> Martin

Re: [PATCH] Port libgccjit to Windows.

[Nicolas Bértolo via Gcc-patches]

Hi Dave,

Thanks for your feedback.

> Do you have copyright assignment paperwork on file?
> https://gcc.gnu.org/contribute.html#legal

My paperwork is done.

> The autotools are not my strongest suit.

> In a previous life I was a Windows developer, but I think it's been
> about 18 years since I've done any coding on Windows, so I'm going to
> have to trust your Windows expertise.

I guess the best solution would be to use libtool and Automake, but
that require major changes in the GCC build system. I came up with a
solution that uses an if statement to choose the way to build the
dynamic library.

> > It is not necessary to use --enable-host-shared in Windows (I tested
> it),
> > but I
> > don't know the proper way to disable that check.

I used case statement to check the value of $(target).

> What's the issue with fchmod on Windows?  Does it not exist, or does it
> not work?
> Please add a comment explaining why.

fchmod does not exist in Windows.

> Please can you fix the indentation here to stay within 80 columns.
> It looks like there's very similar (identical?) code to this below in
> several places.
> Can it be put in a subroutine to avoid repetition?

I created a new file "jit-w32.{h,c}" to store the definitions of
win_mkdtemp() and print_last_error().

> Is there a cast to HMODULE everywhere that m_dso_handle is used?
> If so, does it make the code cleaner if the field becomes an HMODULE on
> Windows?

I added a new type "result::handle_t" that abstracts over this
difference.

> This seems like a very awkward way to get a temporary directory, but
> perhaps it's the best that can be done on Windows?

We could copy an implementation of mkdtemp () for Windows or write
something using a random number generator. I did it this way because
it was the fastest.

> Sorry if this seems excessively like nitpicking - thanks again for the
> patch.

No problem.

Here is a new version.

Nico.


0001-Port-libgccjit-to-Windows.patch
Description: Binary data

[Bug fortran/95323] New: ice in compute_live_loop_exits, at tree-ssa-loop-manip.c:247

[dcb314 at hotmail dot com]

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

Bug ID: 95323
   Summary: ice in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 48598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48598=edit
fortran source code

For the attached Fortran code, recent gfortran trunk does this:

$ gfortran -O2 -w  -c local.f
during GIMPLE pass: lim
local.f:1:0:

1 |   SUBROUTINE LOCAL(C,MDIM,NOCC,EIG)
  |
internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
0xef51a9 compute_live_loop_exits(bitmap_head*, bitmap_head*, bitmap_head**,
basic_block_def*)
../../trunk.git/gcc/tree-ssa-loop-manip.c:247
0xef51a9 add_exit_phis_var(tree_node*, bitmap_head*, bitmap_head**)
../../trunk.git/gcc/tree-ssa-loop-manip.c:334
0xef51a9 add_exit_phis(bitmap_head*, bitmap_head**, bitmap_head**)
../../trunk.git/gcc/tree-ssa-loop-manip.c:356
0xef51a9 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
../../trunk.git/gcc/tree-ssa-loop-manip.c:678

The bug first seems to occur sometime between 20200521 and 20200522

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

--- Comment #6 from Brett Neumeier  ---
The host binutils (used to compile the cross-toolchain):

$ as --version
GNU assembler (GNU Binutils) 2.34.0.20200507
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-pc-linux-gnu'.

The cross-binutils is:

$ ./aarch64-cbl-linux-gnu-as --version
GNU assembler (GNU Binutils) 2.34.0.20200517
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `aarch64-cbl-linux-gnu'.

So, pretty much the same, the cross-toolchain has more updates from the
binutils 2.34 branch.

I can try again with 2.33.1 and see if I get different results, if that would
help?

Re: New mklog script

[Jason Merrill via Gcc]

On Mon, May 25, 2020 at 5:23 AM Martin Liška  wrote:
>
> On 5/22/20 11:01 PM, Jason Merrill wrote:
> > On Thu, May 21, 2020 at 6:03 PM Jason Merrill  wrote:
> >>
> >> On Fri, May 15, 2020 at 11:39 AM Martin Liška  wrote:
> >>>
> >>> On 5/15/20 3:22 PM, Marek Polacek wrote:
>  On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> > On 5/15/20 2:42 PM, Marek Polacek wrote:
> >> I actually use mklog -i all the time.  But I can work around it if it
> >> disappears.
> >
> > Ah, I can see a consumer.
> > There's an updated version that supports that.
> >
> > For the future, will you still use the option? Wouldn't be better
> > to put the ChangeLog content directly to commit message? Note
> > that you won't have to copy the entries to a particular ChangeLog file.
> 
>  The way I do it is to generate a patch using format-patch, use mklog -i
>  on it, then add the ChangeLog entry to the commit message via commit 
>  --amend.
> >>>
> >>> Hmm, you can do much better with:
> >>>
> >>> $ git diff | ./contrib/mklog > changelog && git commit -a -t changelog
> >>>
> >>> Or for an already created commit you can do:
> >>>
> >>> $ git diff HEAD~ | ./contrib/mklog > changelog && git commit -a --amend 
> >>> -e -F changelog
> >>
> >> With these git aliases:
> >>
> >>  mklog-editor = "!f() { git show | git gcc-mklog >> $1; }; f"
> >>  addlog = "!f() { GIT_EDITOR='git mklog-editor' git commit 
> >> --amend; }; f"
> >>
> >> I can 'git addlog' to append the output of mklog to the current
> >> commit.  Probably better would be to do something with
> >> prepare-commit-msg.
> >
> > This is pretty rudimentary, but good enough as a start:
>
> I like the idea of usage of the prepare commit hook.
>
> >
> > #!/bin/sh
> >
> > #COMMIT_MSG_FILE=$1
> > #COMMIT_SOURCE=$2
> > #SHA1=$3
>
> It's better to use the named arguments.
>
> >
> > if ! [ -f "$1" ]; then exit 0; fi
> >
> > #echo "# $0 $1 $2 $3" >> $1
> >
> > if fgrep 'ChangeLog:' $1 > /dev/null 2>&1; then exit 0; fi
> >
> > if [ -z "$2" ]; then
> >  cmd="diff --cached"
> > elif [ $2 == commit ]; then
> >  cmd="show $3"
> > else
> >  exit 0
> > fi
> >
> > git $cmd | git gcc-mklog >> $1
> >
>
> Well, that will generate changelog entry for each commit.
> For a user branch development, it's not desirable.

It isn't that useful for intermediate commits, but I was thinking it
wasn't harmful either.  But I can remove the on-by-default aspects.

> What about more explicit approach:
>
> 1) making an alias for: git diff | git gcc-mklog > commit.msg
> 2) hook:
>
> if test -f commit.msg; then
>cat commit.msg >> "$COMMIT_MSG_FILE"
>rm commit.msg
> fi
>
> So the changelog is created explicitly and included implicitly.

How about this?
commit 787893dc41fb8288994a2350943c22e2388476e7
Author: Jason Merrill 
Date:   Fri May 22 18:40:35 2020 -0400

gcc-git: Add prepare-commit-msg.

This patch introduces a prepare-commit-msg hook that appends a ChangeLog
skeleton to a commit message when the GCC_FORCE_MKLOG environment variable
is set, and a 'git commit-mklog' command set that variable while running
'git commit'.

contrib/ChangeLog:

* prepare-commit-msg: New file.
* gcc-git-customization.sh: Install it.  Add commit-mklog alias.

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 7a950ae5f38..a3f7da8d20b 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -30,6 +30,11 @@ git config alias.gcc-backport '!f() { rev=$1; git cherry-pick -x $@; } ; f'
 
 git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
 
+hookdir=`git rev-parse --git-path hooks`
+install "`git rev-parse --show-toplevel`/contrib/prepare-commit-msg" "$hookdir"
+
+git config alias.commit-mklog '!f() { GCC_FORCE_MKLOG=1 git commit "$@"; }; f'
+
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
 # *.mddiff=md
diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
new file mode 100644
index 000..b06080b927c
--- /dev/null
+++ b/contrib/prepare-commit-msg
@@ -0,0 +1,43 @@
+#!/bin/sh
+
+COMMIT_MSG_FILE=$1
+COMMIT_SOURCE=$2
+SHA1=$3
+
+#echo "# $*" > $HOME/prepare-commit-msg-args
+
+# Can't do anything if $COMMIT_MSG_FILE isn't a file.
+if ! [ -f "$COMMIT_MSG_FILE" ]; then exit 0; fi
+
+# Don't do anything unless requested to.
+if [ -z "$GCC_FORCE_MKLOG" ]; then exit 0; fi
+
+if [ -z "$COMMIT_SOURCE" ] || [ $COMMIT_SOURCE = template ]; then
+# No source or "template" means new commit.
+cmd="diff --cached"
+
+elif [ $COMMIT_SOURCE = message ]; then
+# "message" means -m, assume a new commit if there are any changes staged.
+if ! git diff --cached --quiet; then
+	cmd="diff --cached"
+else
+	cmd="diff --cached HEAD^"
+fi
+
+# Add a blank line before 

Re: New mklog script

[Jason Merrill via Gcc-patches]

On Mon, May 25, 2020 at 5:23 AM Martin Liška  wrote:
>
> On 5/22/20 11:01 PM, Jason Merrill wrote:
> > On Thu, May 21, 2020 at 6:03 PM Jason Merrill  wrote:
> >>
> >> On Fri, May 15, 2020 at 11:39 AM Martin Liška  wrote:
> >>>
> >>> On 5/15/20 3:22 PM, Marek Polacek wrote:
>  On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> > On 5/15/20 2:42 PM, Marek Polacek wrote:
> >> I actually use mklog -i all the time.  But I can work around it if it
> >> disappears.
> >
> > Ah, I can see a consumer.
> > There's an updated version that supports that.
> >
> > For the future, will you still use the option? Wouldn't be better
> > to put the ChangeLog content directly to commit message? Note
> > that you won't have to copy the entries to a particular ChangeLog file.
> 
>  The way I do it is to generate a patch using format-patch, use mklog -i
>  on it, then add the ChangeLog entry to the commit message via commit 
>  --amend.
> >>>
> >>> Hmm, you can do much better with:
> >>>
> >>> $ git diff | ./contrib/mklog > changelog && git commit -a -t changelog
> >>>
> >>> Or for an already created commit you can do:
> >>>
> >>> $ git diff HEAD~ | ./contrib/mklog > changelog && git commit -a --amend 
> >>> -e -F changelog
> >>
> >> With these git aliases:
> >>
> >>  mklog-editor = "!f() { git show | git gcc-mklog >> $1; }; f"
> >>  addlog = "!f() { GIT_EDITOR='git mklog-editor' git commit 
> >> --amend; }; f"
> >>
> >> I can 'git addlog' to append the output of mklog to the current
> >> commit.  Probably better would be to do something with
> >> prepare-commit-msg.
> >
> > This is pretty rudimentary, but good enough as a start:
>
> I like the idea of usage of the prepare commit hook.
>
> >
> > #!/bin/sh
> >
> > #COMMIT_MSG_FILE=$1
> > #COMMIT_SOURCE=$2
> > #SHA1=$3
>
> It's better to use the named arguments.
>
> >
> > if ! [ -f "$1" ]; then exit 0; fi
> >
> > #echo "# $0 $1 $2 $3" >> $1
> >
> > if fgrep 'ChangeLog:' $1 > /dev/null 2>&1; then exit 0; fi
> >
> > if [ -z "$2" ]; then
> >  cmd="diff --cached"
> > elif [ $2 == commit ]; then
> >  cmd="show $3"
> > else
> >  exit 0
> > fi
> >
> > git $cmd | git gcc-mklog >> $1
> >
>
> Well, that will generate changelog entry for each commit.
> For a user branch development, it's not desirable.

It isn't that useful for intermediate commits, but I was thinking it
wasn't harmful either.  But I can remove the on-by-default aspects.

> What about more explicit approach:
>
> 1) making an alias for: git diff | git gcc-mklog > commit.msg
> 2) hook:
>
> if test -f commit.msg; then
>cat commit.msg >> "$COMMIT_MSG_FILE"
>rm commit.msg
> fi
>
> So the changelog is created explicitly and included implicitly.

How about this?
commit 787893dc41fb8288994a2350943c22e2388476e7
Author: Jason Merrill 
Date:   Fri May 22 18:40:35 2020 -0400

gcc-git: Add prepare-commit-msg.

This patch introduces a prepare-commit-msg hook that appends a ChangeLog
skeleton to a commit message when the GCC_FORCE_MKLOG environment variable
is set, and a 'git commit-mklog' command set that variable while running
'git commit'.

contrib/ChangeLog:

* prepare-commit-msg: New file.
* gcc-git-customization.sh: Install it.  Add commit-mklog alias.

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 7a950ae5f38..a3f7da8d20b 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -30,6 +30,11 @@ git config alias.gcc-backport '!f() { rev=$1; git cherry-pick -x $@; } ; f'
 
 git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
 
+hookdir=`git rev-parse --git-path hooks`
+install "`git rev-parse --show-toplevel`/contrib/prepare-commit-msg" "$hookdir"
+
+git config alias.commit-mklog '!f() { GCC_FORCE_MKLOG=1 git commit "$@"; }; f'
+
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
 # *.mddiff=md
diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
new file mode 100644
index 000..b06080b927c
--- /dev/null
+++ b/contrib/prepare-commit-msg
@@ -0,0 +1,43 @@
+#!/bin/sh
+
+COMMIT_MSG_FILE=$1
+COMMIT_SOURCE=$2
+SHA1=$3
+
+#echo "# $*" > $HOME/prepare-commit-msg-args
+
+# Can't do anything if $COMMIT_MSG_FILE isn't a file.
+if ! [ -f "$COMMIT_MSG_FILE" ]; then exit 0; fi
+
+# Don't do anything unless requested to.
+if [ -z "$GCC_FORCE_MKLOG" ]; then exit 0; fi
+
+if [ -z "$COMMIT_SOURCE" ] || [ $COMMIT_SOURCE = template ]; then
+# No source or "template" means new commit.
+cmd="diff --cached"
+
+elif [ $COMMIT_SOURCE = message ]; then
+# "message" means -m, assume a new commit if there are any changes staged.
+if ! git diff --cached --quiet; then
+	cmd="diff --cached"
+else
+	cmd="diff --cached HEAD^"
+fi
+
+# Add a blank line before 

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
The assembler code works for me with binutils 2.33.1.  So again which version
of binutils are you using for the cross compiler?

[Bug middle-end/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|bootstrap   |middle-end
   Last reconfirmed||2020-05-25
 Ever confirmed|0   |1
   Keywords||assemble-failure, build

--- Comment #4 from Andrew Pinski  ---
What binutils version you are using?

orr x4, x4, x7
.LVL33:
.loc 1 170 12 view .LVU92
.LBE26:
.LBE25:
.LBE24:
.loc 1 263 7 is_stmt 1 view .LVU93
.p2align 3,,7
.L36:
.loc 1 281 4 view .LVU94
.loc 1 282 35 is_stmt 0 view .LVU95
and w6, w5, 112

This seems like a bug in binutils to me.
The only difference between with/without -fno-align-loops is the line marked
with .

[Bug libstdc++/95322] New: std::list | take | transform, expression does not work cbegin() == end()

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 95322
   Summary: std::list | take | transform, expression does not work
cbegin() == end()
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hello gcc-team,

I'm not sure if this is intended behaviour, or if this is a defect in the
standard, or something that you should never write in a generic context.

ASFAIK you can use that expression on any container and on any view, but not on
some(?!) combinations of views? This is a bit unexpected.

```c++
#include 
#include 
#include 

int main()
{

std::list v{0,1 ,2, 3, 4, 5, 5, 6}; // works if std::vector

auto view1 = v | std::views::take(5);
auto view2 = v | std::views::transform([] (int i) { return i + 3;});
auto view3 = view1 | std::views::transform([] (int i) { return i + 3;});

std::ranges::cbegin(view1) == std::ranges::end(view1); // works
std::ranges::cbegin(view2) == std::ranges::end(view2); // works
std::ranges::cbegin(view3) == std::ranges::end(view3); // does not work
return 0;
}
```

https://godbolt.org/z/4Nzr69

Re: [PATCH RFC] gcc-git: Add prepare-commit-msg hook.

[Martin Liška]

On 5/23/20 11:39 PM, Jason Merrill via Gcc-patches wrote:

This patch introduces a prepare-commit-msg hook that appends a ChangeLog
skeleton to a commit message that doesn't already have one, and a 'git
amend-mklog' command to amend and append a new ChangeLog skeleton (to be
edited together with existing entries by hand).


As mentioned in the previous email, I prefer to make it opt-in, not opt-out.

So I'm suggesting the 'git commit-mklog' alias that add the skeleton to
a git commit message.

I also changed the hook to use named variables. And I would like to preserve
the ending '# Please enter the commit message for your changes. Lines starting'
section, so I use the mklog.py to put the skeleton to a proper place.

Example:

gcc/ChangeLog:

* ipa-icf.c (make_pass_ipa_icf):

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch me/add-prepare-commit-msg-hook
# Changes to be committed:
#   modified:   gcc/ipa-icf.c
#

Thoughts?
Martin
>From bbceb70bcf56d6feac9e7f90eefa06147417e4d0 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 25 May 2020 19:38:00 +0200
Subject: [PATCH] Add prepare-commit-msg hook/

contrib/ChangeLog:

	* gcc-git-customization.sh: Install new hook.
	* mklog.py: Add new option -c which append
	to a ChangeLog file.
	* prepare-commit-msg: New file.
---
 contrib/gcc-git-customization.sh |  5 +
 contrib/mklog.py | 23 ++-
 contrib/prepare-commit-msg   | 32 
 3 files changed, 59 insertions(+), 1 deletion(-)
 create mode 100644 contrib/prepare-commit-msg

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 7a950ae5f38..110f661f5e5 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -30,6 +30,11 @@ git config alias.gcc-backport '!f() { rev=$1; git cherry-pick -x $@; } ; f'
 
 git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
 
+hookdir=`git rev-parse --git-path hooks`
+install "`git rev-parse --show-toplevel`/contrib/prepare-commit-msg" "$hookdir"
+
+git config alias.commit-mklog '!f() { GCC_PREPARE_COMMIT=1 git commit "$@"; }; f'
+
 # Make diff on MD files use "(define" as a function marker.
 # Use this in conjunction with a .gitattributes file containing
 # *.mddiff=md
diff --git a/contrib/mklog.py b/contrib/mklog.py
index 7a19b5d0949..fb58661b5eb 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -30,6 +30,7 @@ import argparse
 import os
 import re
 import sys
+from itertools import takewhile
 
 import requests
 
@@ -221,6 +222,9 @@ if __name__ == '__main__':
 help='Do not generate function names in ChangeLogs')
 parser.add_argument('-p', '--fill-up-bug-titles', action='store_true',
 help='Download title of mentioned PRs')
+parser.add_argument('-c', '--changelog',
+help='Append the ChangeLog to a git commit message '
+ 'file')
 args = parser.parse_args()
 if args.input == '-':
 args.input = None
@@ -229,4 +233,21 @@ if __name__ == '__main__':
 data = input.read()
 output = generate_changelog(data, args.no_functions,
 args.fill_up_bug_titles)
-print(output, end='')
+if args.changelog:
+lines = open(args.changelog).read().split('\n')
+start = list(takewhile(lambda l: not l.startswith('#'), lines))
+end = lines[len(start):]
+with open(args.changelog, 'w') as f:
+if start:
+# appent empty line
+if start[-1] != '':
+start.append('')
+else:
+# append 2 empty lines
+start = 2 * ['']
+f.write('\n'.join(start))
+f.write('\n')
+f.write(output)
+f.write('\n'.join(end))
+else:
+print(output, end='')
diff --git a/contrib/prepare-commit-msg b/contrib/prepare-commit-msg
new file mode 100644
index 000..a14b2ece042
--- /dev/null
+++ b/contrib/prepare-commit-msg
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+COMMIT_MSG_FILE=$1
+COMMIT_SOURCE=$2
+SHA1=$3
+
+# Can't do anything if $COMMIT_MSG_FILE isn't a file.
+if ! [ -f "$COMMIT_MSG_FILE" ]; then exit 0; fi
+
+# Don't mess with existing entries unless requested to.
+if [ -z "$GCC_PREPARE_COMMIT" ]; then exit 0; fi
+
+if [ -z "$COMMIT_SOURCE" ] || [ $COMMIT_SOURCE == template ]; then
+# No source or "template" means new commit.
+cmd="diff --cached"
+elif [ $COMMIT_SOURCE == message ]; then
+# "message" means -m, but could be either a new commit or --amend.
+# Guess which based on whether there are any changes staged.
+if git diff --cached --quiet; then
+	cmd="show"
+else
+	cmd="diff --cached"
+fi
+elif [ $COMMIT_SOURCE == commit ]; then
+# The message of an 

[Bug c++/95321] Run-time crash on valid destructor code

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #3 from Francois-Xavier Coudert  ---
I don't have certainty it's not undefined behaviour, sorry. Closing.

Re: [PATCH 1/2] Seperate -funroll-loops for GIMPLE unroller and RTL unroller

[Segher Boessenkool]

On Mon, May 25, 2020 at 07:58:09PM +0200, Richard Biener wrote:
> You folks made ppc specific hacks instead of a better design. Those now stand 
> in the way as well. But sure, simply do not expose the flag to the users, use
> Var(flag_rtl_unroll_loops). My other points still stand. 
> 
> Feel free to ignore the regression part on the branch and come up with a 
> great design. But don't expect to backport that then. 

I just do not think fixing the regression should make things worse for
a long time, if that can be avoided.


Segher

[Bug target/95211] [11 Regression] ICE in emit_unop_insn, at optabs.c:3622

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
(In reply to Uroš Bizjak from comment #5)
> This testcase is fixed by [1]
> 
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546408.html

Interesting. I've done quite a bit of cooperlake specific testing and 
found some bugs in gcc trunk.

AFAIK cooperlake is recent Intel. Is there a newer -march
setting I could usefully test or is cooperlake recent enough ?

Also, AFAIK Zen version 2 is a recent AMD -march setting.
Is there a newer AMD -march setting I could usefully test ?

A complete compile of Fedora Linux, with about 6,700 packages,
seems to be a good testcase for recent gcc trunk.

Re: [PATCH 1/2] Seperate -funroll-loops for GIMPLE unroller and RTL unroller

[David Edelsohn via Gcc-patches]

On Mon, May 25, 2020 at 1:58 PM Richard Biener
 wrote:
>
> On May 25, 2020 7:40:00 PM GMT+02:00, Segher Boessenkool 
>  wrote:
> >On Mon, May 25, 2020 at 02:14:02PM +0200, Richard Biener wrote:
> >> On Mon, May 25, 2020 at 1:10 PM guojiufu 
> >wrote:
> >> Since a new flag is not needed to fix the regression please avoid
> >> adding -fcomplete-unroll-loops.
> >>
> >> For -frtl-unroll-loops you should be able to use
> >
> >Erm.  That *is* a new command-line option (the internal flags I do not
> >care about so much: new implementation details are *good*).  And a new
> >name that is a mistake in my opinion, for many reasons (users do not
> >know and should not have to care about "rtl"; the name is not
> >descriptive; it is useless churn, it is not the same name as we have
> >had for decades now; it is adding a new option for a future where we
> >will do most unrolling at gimple level, a future we do not know will
> >ever exist, and we do not know what that will look like anyway; it is
> >an extra level of indirection (in the name)).
> >
> >We should not have an -frtl-unroll-loops if we do not have a
> >-ftree-unroll-loops (or whatever).
> >
> >Unrolling early is not a good idea in general (the problems with the
> >very trivial complete unrolling case just underline that).  But we
> >*should* know which code we expect to unroll later, for better costing.
> >Adding names like "rtl-unroll-loops" only stands in the way of getting
> >a better design here.
>
> You folks made ppc specific hacks instead of a better design. Those now stand 
> in the way as well. But sure, simply do not expose the flag to the users, use
> Var(flag_rtl_unroll_loops). My other points still stand.
>
> Feel free to ignore the regression part on the branch and come up with a 
> great design. But don't expect to backport that then.

I completely agree.

This path is digging a deeper and deeper hole.

- David

Re: [PATCH 1/2] Seperate -funroll-loops for GIMPLE unroller and RTL unroller

[Richard Biener via Gcc-patches]

On May 25, 2020 7:40:00 PM GMT+02:00, Segher Boessenkool 
 wrote:
>On Mon, May 25, 2020 at 02:14:02PM +0200, Richard Biener wrote:
>> On Mon, May 25, 2020 at 1:10 PM guojiufu 
>wrote:
>> Since a new flag is not needed to fix the regression please avoid
>> adding -fcomplete-unroll-loops.
>> 
>> For -frtl-unroll-loops you should be able to use
>
>Erm.  That *is* a new command-line option (the internal flags I do not
>care about so much: new implementation details are *good*).  And a new
>name that is a mistake in my opinion, for many reasons (users do not
>know and should not have to care about "rtl"; the name is not
>descriptive; it is useless churn, it is not the same name as we have
>had for decades now; it is adding a new option for a future where we
>will do most unrolling at gimple level, a future we do not know will
>ever exist, and we do not know what that will look like anyway; it is
>an extra level of indirection (in the name)).
>
>We should not have an -frtl-unroll-loops if we do not have a
>-ftree-unroll-loops (or whatever).
>
>Unrolling early is not a good idea in general (the problems with the
>very trivial complete unrolling case just underline that).  But we
>*should* know which code we expect to unroll later, for better costing.
>Adding names like "rtl-unroll-loops" only stands in the way of getting
>a better design here.

You folks made ppc specific hacks instead of a better design. Those now stand 
in the way as well. But sure, simply do not expose the flag to the users, use
Var(flag_rtl_unroll_loops). My other points still stand. 

Feel free to ignore the regression part on the branch and come up with a great 
design. But don't expect to backport that then. 

Richard. 

>
>Segher

Re: How to update .debug_frame CFA offset for function epilogues?

[Segher Boessenkool]

Hi!

On Mon, May 25, 2020 at 06:20:49PM +0100, Jozef Lawrynowicz wrote:
> On Tue, Mar 31, 2020 at 04:49:53PM -0500, Segher Boessenkool wrote:
> > You need reg_notes for more than just the stack updates: importantly,
> > also for the restores of any saved register.
> 
> Thanks for the advice, indeed the reason I was having problems was
> because not all stack operations were properly annotated with reg notes.
> 
> The reason I was seeing the ICE was because of unspec insns which were marked
> as frame related but didn't have accompanything reg notes, of course it
> is now clear that stack modifications in an unspec need to be explicitly
> described.

One thing that helps debugging this is  readelf -wframe  (but there are
other methods).  A bit late for help to you ;-)

> (Apologies for the late response, but I figure I may as well document
> the conclusion came to with this.)

No, thanks, it is good to hear it helped!


Segher

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

[Segher Boessenkool]

On Mon, May 25, 2020 at 02:39:54PM +0200, Richard Biener wrote:
> On Fri, May 22, 2020 at 6:54 PM Segher Boessenkool
>  wrote:
> > > The split above allows the "bug" to be fixed (even on the branch)
> > > without introducing even more target specialities.
> >
> > So does any split.  Or I don't see what you mean?
> 
> Well, a split that does not affect behavior for non-ppc architectures
> when the flags by users are unchanged.  Because that allows
> the ppc regression to be fixed on the branch.
> 
> Then, on trunk, we can think of a better overall flag design.  Note

Oh, as just a (very) temporary thing, it is fine of course (it should
say it is then though).

> that cunroll/cunrolli are not controlled by a flag currently, they
> are gated on optimize >= [2|3] - it's just that either -funroll-loops
> or -fpeel-loops causes its heuristics to allow code-size growth
> by its own metrics according to the unroll --params.
> 
> So it's a bit difficult to retrofit the heuristic behavior onto new
> flags unless we want to completely move that over to a --param
> that may be gets adjusted by -funroll-loops.

Yes, cunroll does not have its own option, and that is a problem.  But
that is easy to fix!  Either with an option, or just with params (the
option wouldn't do more than set params anyway?)


Segher

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

[H.J. Lu via Gcc-patches]

On Mon, May 25, 2020 at 2:52 AM Martin Liška  wrote:
>
> Hello.
>
> I really welcome the unification patch and I have some comments (ideas):
>
> 1)
>
> > +static inline int
> > +has_cpu_feature (struct __processor_model *cpu_model,
> > +  unsigned int *cpu_features2,
> > +  enum processor_features f)
> > +{
> > +  unsigned int i;
> > +  if (f < 32)
> > +return cpu_model->__cpu_features[0] & (1U << (f & 31));
> > +  for (i = 0; i < SIZE_OF_CPU_FEATURES; i++)
> > +if (f < (32 + 32 + i * 32))
> > +return cpu_features2[i] & (1U << ((f - (32 + i * 32)) & 31));
> > +  gcc_unreachable ();
> > +}
> > +
> > +static inline void
> > +set_cpu_feature (struct __processor_model *cpu_model,
> > +  unsigned int *cpu_features2,
> > +  enum processor_features f)
> > +{
> > +  unsigned int i;
> > +  if (f < 32)
> > +{
> > +  cpu_model->__cpu_features[0] |= (1U << (f & 31));
> > +  return;
> > +}
> > +  for (i = 0; i < SIZE_OF_CPU_FEATURES; i++)
> > +if (f < (32 + 32 + i * 32))
> > +  {
> > + cpu_features2[i] |= (1U << ((f - (32 + i * 32)) & 31));
> > + return;
> > +  }
> > +  gcc_unreachable ();
> > +}
>
> Can you please add comment about the '32 + 32' and '32 + i * 32', it's 
> unclear from the patch.

Done.

> 2) Can we remove all the:
>
> > +  unsigned int has_lahf_lm, has_sse4a;
> > +  unsigned int has_longmode, has_3dnowp, has_3dnow;
> > +  unsigned int has_movbe, has_sse4_1, has_sse4_2;
> > +  unsigned int has_popcnt, has_aes, has_avx, has_avx2;
> > +  unsigned int has_pclmul, has_abm, has_lwp;
> > +  unsigned int has_fma, has_fma4, has_xop;
> > +  unsigned int has_bmi, has_bmi2, has_tbm, has_lzcnt;
>
> ...
>
> > +  has_sse4a = has_feature (FEATURE_SSE4_A);
> > +  has_fma4 = has_feature (FEATURE_FMA4);
> > +  has_xop = has_feature (FEATURE_XOP);
> > +  has_fma = has_feature (FEATURE_FMA);
>
> ...
>
>if (arch)
>  {
>const char *mmx = has_mmx ? " -mmmx" : " -mno-mmx";
>const char *mmx3dnow = has_3dnow ? " -m3dnow" : " -mno-3dnow";
>const char *sse = has_sse ? " -msse" : " -mno-sse";
> ...
>
>options = concat (options, mmx, mmx3dnow, sse, sse2, sse3, ssse3,
> sse4a, cx16, sahf, movbe, aes, sha, pclmul,
> popcnt, abm, lwp, fma, fma4, xop, bmi, sgx, bmi2,
> pconfig, wbnoinvd,
> tbm, avx, avx2, sse4_2, sse4_1, lzcnt, rtm,
> hle, rdrnd, f16c, fsgsbase, rdseed, prfchw, adx,
> fxsr, xsave, xsaveopt, avx512f, avx512er,
> avx512cd, avx512pf, prefetchwt1, clflushopt,
> xsavec, xsaves, avx512dq, avx512bw, avx512vl,
> avx512ifma, avx512vbmi, avx5124fmaps, avx5124vnniw,
> clwb, mwaitx, clzero, pku, rdpid, gfni, shstk,
> avx512vbmi2, avx512vnni, vaes, vpclmulqdq,
> avx512bitalg, avx512vpopcntdq, movdiri, movdir64b,
> waitpkg, cldemote, ptwrite, avx512bf16, enqcmd,
> avx512vp2intersect, serialize, tsxldtrk, NULL);
>
> and instead mark flags in 'isa_names_table' that should be used for 
> -match=native option emission.
> We know names of the flags, their value (has_feature) and so we can generate 
> that automatically?

Done.

> 3) Similarly we can we do automatically all the:
>
> +  if (has_feature (FEATURE_AVX512VBMI2))
> +assert (__builtin_cpu_supports ("avx512vbmi2"));
>
> We should have both information in 'isa_names_table'.
>

Done.

Here is the updated patch.  OK for master?

Thanks,

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

Move cpuinfo.h from libgcc to common/config/i386 and move isa_names_table
to common/config/i386 so that get_intel_cpu can be shared by libgcc, GCC
driver and gcc.target/i386/builtin_target.c to detect the specific type
of Intel and AMD CPUs:

1. Use the same enum processor_features in libgcc and x86 backend.
2. Add more processor features to enum processor_features.
3. Use the same isa_names_table in i386-builtins.c, driver-i386.c and
gcc.target/i386/builtin_target.c.
4. Use isa_names_table to generate ISA command-line options.
5. Use isa_names_table to generate __builtin_cpu_supports tests.
6. Add M_VENDOR, M_CPU_TYPE and M_CPU_SUBTYPE in i386-builtins.c to
avoid duplication in.
7. Use cpu_indicator_init, has_cpu_feature, get_amd_cpu and get_intel_cpu
in driver-i386.c and builtin_target.c.

gcc/

	PR target/95259
	* common/config/i386/cpuinfo-builtins.h: Moved from
	libgcc/config/i386/cpuinfo.h.
	(processor_vendor): Add VENDOR_CENTAUR, VENDOR_CYRIX, VENDOR_NSC
	and BUILTIN_VENDOR_MAX.
	(processor_types): Add BUILTIN_CPU_TYPE_MAX.
	(processor_features): Add FEATURE_3DNOW, 

Re: [PATCH 1/2] Seperate -funroll-loops for GIMPLE unroller and RTL unroller

[Segher Boessenkool]

On Mon, May 25, 2020 at 02:14:02PM +0200, Richard Biener wrote:
> On Mon, May 25, 2020 at 1:10 PM guojiufu  wrote:
> Since a new flag is not needed to fix the regression please avoid
> adding -fcomplete-unroll-loops.
> 
> For -frtl-unroll-loops you should be able to use

Erm.  That *is* a new command-line option (the internal flags I do not
care about so much: new implementation details are *good*).  And a new
name that is a mistake in my opinion, for many reasons (users do not
know and should not have to care about "rtl"; the name is not
descriptive; it is useless churn, it is not the same name as we have
had for decades now; it is adding a new option for a future where we
will do most unrolling at gimple level, a future we do not know will
ever exist, and we do not know what that will look like anyway; it is
an extra level of indirection (in the name)).

We should not have an -frtl-unroll-loops if we do not have a
-ftree-unroll-loops (or whatever).

Unrolling early is not a good idea in general (the problems with the
very trivial complete unrolling case just underline that).  But we
*should* know which code we expect to unroll later, for better costing.
Adding names like "rtl-unroll-loops" only stands in the way of getting
a better design here.


Segher

[Bug c++/95321] Run-time crash on valid destructor code

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> I don't think this is valid:
> BY the time operator delete gets called the deconstructor is called and
> therefor the object no longer exists therefor:
> void operator delete (void * ptr)
> {
> if (ptr != nullptr) static_cast(ptr)->Destroy();
> }
> 
> Is invalid code as the vtable in ptr is no longer valid.
s/invalid/undefined/

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
@egallager: Why did you add 'deferred' keyword? I sent a patch for it to GCC
patches mailing list.

[Bug c++/95321] Run-time crash on valid destructor code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-25
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I don't think this is valid:
BY the time operator delete gets called the deconstructor is called and
therefor the object no longer exists therefor:
void operator delete (void * ptr)
{
if (ptr != nullptr) static_cast(ptr)->Destroy();
}

Is invalid code as the vtable in ptr is no longer valid.

Where is this code from?

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
I see no conversion there?

But, why does it it store to memory at all?

Re: How to update .debug_frame CFA offset for function epilogues?

[Jozef Lawrynowicz]

Hi Segher,

On Tue, Mar 31, 2020 at 04:49:53PM -0500, Segher Boessenkool wrote:
> Hi Jozef,
> 
> On Thu, Mar 26, 2020 at 12:33:38PM +, Jozef Lawrynowicz wrote:
> > In some cases, I can fix the CFA offset by marking these epilogue insns as
> > frame_related anyway, and adding reg notes which describe the stack pointer
> > operations. For some other epilogue insns, marking them frame_related 
> > results in
> > an ICE, which I'm assuming comes back to the fact that epilogue insns 
> > shouldn't
> > be marked frame related.
> 
> > What is the standard way for updating the CFA offset in the epilogue?
> 
> What you already say you do: add notes, and often frame_related is set
> as well.  I agree that shouldn't be done, but it often is harmless.
> 
> You need reg_notes for more than just the stack updates: importantly,
> also for the restores of any saved register.

Thanks for the advice, indeed the reason I was having problems was
because not all stack operations were properly annotated with reg notes.

The reason I was seeing the ICE was because of unspec insns which were marked
as frame related but didn't have accompanything reg notes, of course it
is now clear that stack modifications in an unspec need to be explicitly
described.

(Apologies for the late response, but I figure I may as well document
the conclusion came to with this.)

Jozef

> 
> 
> Segher

[Bug c++/95321] New: Run-time crash on valid destructor code

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 95321
   Summary: Run-time crash on valid destructor code
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

// Run-time crash with g++ >= 9 and -Ox, x > 1
// Works perfectly with g++ <= 8.3
class IDestroyable
{
protected:
virtual void  Destroy() = 0;

public:
void operator delete (void * ptr)
{
if (ptr != nullptr) static_cast(ptr)->Destroy();
}
};

class IToto
{
public:
virtual void  Toto() = 0;
};

class ITotoDestroyable : public IToto, public IDestroyable
{
public:
void operator delete (void * ptr)
{
if (ptr != nullptr) delete static_cast(static_cast(ptr));
}
};

template 
class DestroyableBase : public INTERFACE
{
protected:
virtual void  Destroy()
{
::delete this;
}

public:
virtual ~DestroyableBase()
{
}

void operator delete (void * ptr)
{
::operator delete (ptr);
}
};

#include 

class TotoDestroyable : public DestroyableBase
{
public:
~TotoDestroyable()
{
std::cout << "OK Destroyed !\n";
}

void  Toto()
{
std::cout << "Toto !\n";
}
};

int main()
{
ITotoDestroyable * foo = new TotoDestroyable();
// Uncomment to workaround the crash
// foo->Toto();
delete foo;
}



Segfaults at runtime when compiled with G++ >= 9 and -O1 or higher.

Process 52619 launched: '/tmp/a.out' (x86_64)
Process 52619 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x00010d44 a.out`main [inlined] IDestroyable::operator
delete(ptr=0x000100604858) at a.cpp:11:70
   8public:
   9void operator delete (void * ptr)
   10   {
-> 11   if (ptr != nullptr) static_cast(ptr)->Destroy();
   12   }
   13   };
   14

Re: [Patch][OpenMP] Fix mapping of artificial variables (PR94874)

[Tobias Burnus]

On 5/12/20 1:02 PM, Jakub Jelinek wrote:


I think we want a new hook, the clear cases (mostly DECL_ARTIFICIAL ones,
if it is really something compiler created and not something under user's
control) …


Attached is one version, which is somewhat minimalist; I did not check
what happens with __FUNCTION__ and also the Fortran part is not very extended
but it is a start.

Additionally, I fixed the comments for the existing c_omp_predetermined_sharing.

OK for the trunk?

Tobias

PS: Not tested with an actually offloading compiler due to PR ipa/95320.

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

	* c-common.h (c_omp_predetermined_mapping): Declare.
	* c-omp.c (c_omp_predetermined_mapping): New.

gcc/c/ChangeLog:

	* c-objc-common.h (LANG_HOOKS_OMP_PREDETERMINED_MAPPING): Redefine.

gcc/cp/ChangeLog:

	* cp-gimplify.c (cxx_omp_predetermined_mapping): New.
	* cp-objcp-common.h (LANG_HOOKS_OMP_PREDETERMINED_MAPPING): Redfine.
	* cp-tree.h (cxx_omp_predetermined_mapping): Declare.

gcc/fortran/ChangeLog:

	* f95-lang.c (LANG_HOOKS_OMP_PREDETERMINED_MAPPING): Redefine.
	* trans-openmp.c (gfc_omp_predetermined_mapping): New.
	* trans.h (gfc_omp_predetermined_mapping): Declare.

gcc/ChangeLog:

	* gimplify.c (omp_notice_variable): Use new hook.
	* langhooks-def.h (lhd_omp_predetermined_mapping): Declare.
	(LANG_HOOKS_OMP_PREDETERMINED_MAPPING): Define
	(LANG_HOOKS_DECLS): Add it.
	* langhooks.c (lhd_omp_predetermined_sharing): Remove bogus unused attr.
	(lhd_omp_predetermined_mapping): New.
	* langhooks.h (struct lang_hooks_for_decls): Add new hook.

gcc/testsuite/ChangeLog
2020-05-25  Thomas Schwinge  
Tobias Burnus  

PR middle-end/94874
* c-c++-common/gomp/pr94874.c: New.

 gcc/c-family/c-common.h   |  1 +
 gcc/c-family/c-omp.c  | 24 +++-
 gcc/c/c-objc-common.h |  3 +++
 gcc/cp/cp-gimplify.c  | 27 ++-
 gcc/cp/cp-objcp-common.h  |  2 ++
 gcc/cp/cp-tree.h  |  1 +
 gcc/fortran/f95-lang.c|  2 ++
 gcc/fortran/trans-openmp.c| 25 -
 gcc/fortran/trans.h   |  1 +
 gcc/gimplify.c|  6 +-
 gcc/langhooks-def.h   |  3 +++
 gcc/langhooks.c   | 13 -
 gcc/langhooks.h   |  4 
 gcc/testsuite/c-c++-common/gomp/pr94874.c | 27 +++
 14 files changed, 134 insertions(+), 5 deletions(-)

diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 7c1a6370aae..c74b23db05c 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1206,6 +1206,7 @@ extern tree c_omp_declare_simd_clauses_to_numbers (tree, tree);
 extern void c_omp_declare_simd_clauses_to_decls (tree, tree);
 extern bool c_omp_predefined_variable (tree);
 extern enum omp_clause_default_kind c_omp_predetermined_sharing (tree);
+extern enum omp_clause_defaultmap_kind c_omp_predetermined_mapping (tree);
 extern tree c_omp_check_context_selector (location_t, tree);
 extern void c_omp_mark_declare_variant (location_t, tree, tree);
 extern const char *c_omp_map_clause_name (tree, bool);
diff --git a/gcc/c-family/c-omp.c b/gcc/c-family/c-omp.c
index 51c18a4ba08..6f8fba350ed 100644
--- a/gcc/c-family/c-omp.c
+++ b/gcc/c-family/c-omp.c
@@ -2104,7 +2104,8 @@ c_omp_predefined_variable (tree decl)
   return false;
 }
 
-/* True if OpenMP sharing attribute of DECL is predetermined.  */
+/* OMP_CLAUSE_DEFAULT_UNSPECIFIED unless OpenMP sharing attribute of DECL
+   is predetermined.  */
 
 enum omp_clause_default_kind
 c_omp_predetermined_sharing (tree decl)
@@ -2123,6 +2124,27 @@ c_omp_predetermined_sharing (tree decl)
   return OMP_CLAUSE_DEFAULT_UNSPECIFIED;
 }
 
+/* OMP_CLAUSE_DEFAULTMAP_CATEGORY_UNSPECIFIED unless OpenMP mapping attribute
+   of DECL is predetermined.  */
+
+enum omp_clause_defaultmap_kind
+c_omp_predetermined_mapping (tree decl)
+{
+  /* Predetermine artificial variables holding integral values, those
+ are usually result of gimplify_one_sizepos or SAVE_EXPR
+ gimplification.  */
+  if (VAR_P (decl)
+  && DECL_ARTIFICIAL (decl)
+  && INTEGRAL_TYPE_P (TREE_TYPE (decl)))
+return OMP_CLAUSE_DEFAULTMAP_FIRSTPRIVATE;
+
+  if (c_omp_predefined_variable (decl))
+return OMP_CLAUSE_DEFAULTMAP_TO;
+
+  return OMP_CLAUSE_DEFAULTMAP_CATEGORY_UNSPECIFIED;
+}
+
+
 /* Diagnose errors in an OpenMP context selector, return CTX if
it is correct or error_mark_node otherwise.  */
 
diff --git a/gcc/c/c-objc-common.h b/gcc/c/c-objc-common.h
index bfdb2797ff4..5471fc7e355 100644
--- a/gcc/c/c-objc-common.h
+++ b/gcc/c/c-objc-common.h
@@ -107,6 +107,9 @@ along with GCC; see the 

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

[Eric Gallager via Gcc]

On 5/25/20, Arseny Solokha  wrote:
> Hi,
>
>
>>> >> PRs from the second group were filed by me, so if there's consensus to
>>> >> close all
>>> >> of them, the ones from this second group I can close myself. I don't
>>> >> have the
>>> >> right permissions to modify PRs reported by someone else, so I'd like
>>> >> to ask a
>>> >> volunteer to step up and close the ones from the first group.
>>> >>
>>> >> WDYT?
>>> >
>>> > I can do both, if you want, or just the first group?  Your choice.
>>> >
>>> > But let's hear other opinions first.
>>>
>>> Thanks. I think I'll close the second group myself, as they constitute
>>> almost
>>> half of the total amount.
>>
>> Okido, thanks!
>
> Two full weeks have passed without any new input from either former port
> maintainer or global maintainers, so it's probably about time to go ahead
> and
> wrap it up.
>

Agreed; a reduction in the number of open bugs in my searches will be
most welcome.

[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
Forgot to mention: That's still the cc1 compiler
(libexec/gcc/x86_64-none-linux-gnu/11.0.0/cc1) not yet an offloading LTO.

The problem seems to be the followingat ipa-utils.h:246:
  /* We do not have this information when not in LTO, but we do not need
 to care, since it is used only for type merging.  */
  gcc_checking_assert (in_lto_p || flag_lto);


Here, we do not compile with LTO but write LTO for offloading.

That code is called by local_tree_p which was added by
r11-525-g03d90a20a1afcbb9c30da8d4adf4922b0685061f , Honza's
  "Avoid SCC hashing on unmergeable trees"
patch of May 20, 2020.

[Bug c++/95197] libgomp/testsuite/libgomp.c++/for-27.C fails with -std=c++17

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-25

--- Comment #3 from Jakub Jelinek  ---
Created attachment 48597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48597=edit
gcc11-pr95197.patch

Untested fix.

Re: [PATCH v1 1/2][PPC64] [PR88877]

[Iain Sandoe via Gcc-patches]

Jakub Jelinek via Gcc-patches  wrote:


On Mon, May 25, 2020 at 06:37:57PM +0200, Richard Biener wrote:

I thought of using std::tuple  but it requires c++11 support.
I am not sure we always build gcc with c++11?


https://gcc.gnu.org/install/prerequisites.html

We do for GCC 11 :-)  Since we pay the price for progress, let's reap
the
benefits as well :-)


Not sure if the benefit is enough to warrant an extra (complex?)  
standard header in almost every TU.


Yeah, especially when one can just define the 3 fields of the small struct
to be descriptive, rather than being first/second/third.

+1,
tuple (and pair) have the property that the use of the fields might be  
obvious to the code author, but probably will not be to the code reader.   
IMO most of the time as Jakub says something descriptive is better - and I  
don’t believe it’s a performance penalty.


Iain

[Bug ipa/95320] New: [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[burnus at gcc dot gnu.org]

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

Bug ID: 95320
   Summary: [11 Regression] ICE in odr_type_p, at ipa-utils.h:246,
during IPA pass: pure-const
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

For some reason, this only occurs when compiling for AMDGCN and it seems to be
a recent regression.

The issue seems to affect nearly all testcases in libgomp, I get 2500+ FAIL.

For instance
  gcc -fopenmp libgomp/testsuite/libgomp.c-c++-common/for-11.c
fails as:

during IPA pass: fnsummary
src/gcc-mainline/libgomp/testsuite/libgomp.c-c++-common/for-11.c:5: internal
compiler error: in odr_type_p, at ipa-utils.h:246
0x8b3ccf odr_type_p(tree_node const*)
gcc-mainline/gcc/ipa-utils.h:246
0x8b3ccf local_tree_p
gcc-mainline/gcc/lto-streamer-out.c:594
0x8b3ccf DFS::DFS(output_block*, tree_node*, bool, bool, bool)
gcc-mainline/gcc/lto-streamer-out.c:639


Breakpoint 1, DFS::DFS(output_block*, tree_node*, bool, bool, bool) () at
gcc-mainline/gcc/lto-streamer-out.c:639
639   if (ob->local_trees && local_tree_p (expr))
(gdb) p ob
$1 = 
(gdb) p expr
$2 = (tree) 0x7734ac78
(gdb) p debug_tree(expr)
 

Re: [PATCH v1 1/2][PPC64] [PR88877]

[Jakub Jelinek via Gcc-patches]

On Mon, May 25, 2020 at 06:37:57PM +0200, Richard Biener wrote:
> >> I thought of using std::tuple  but it requires c++11 support.
> >> I am not sure we always build gcc with c++11?
> >
> >https://gcc.gnu.org/install/prerequisites.html
> >
> >We do for GCC 11 :-)  Since we pay the price for progress, let's reap
> >the
> >benefits as well :-)
> 
> Not sure if the benefit is enough to warrant an extra (complex?) standard 
> header in almost every TU. 

Yeah, especially when one can just define the 3 fields of the small struct
to be descriptive, rather than being first/second/third.

Jakub

Re: [PATCH v1 1/2][PPC64] [PR88877]

[Richard Biener]

On May 25, 2020 6:31:29 PM GMT+02:00, Segher Boessenkool 
 wrote:
>On Mon, May 25, 2020 at 12:46:02PM +0530, kamlesh kumar wrote:
>> > OTOH, you don't need to name Tuple at all...  It should not *have*
>a
>> > constructor, since you declared it as class...  But you can just
>use
>> > std::tuple here?
>> 
>> I thought of using std::tuple  but it requires c++11 support.
>> I am not sure we always build gcc with c++11?
>
>https://gcc.gnu.org/install/prerequisites.html
>
>We do for GCC 11 :-)  Since we pay the price for progress, let's reap
>the
>benefits as well :-)

Not sure if the benefit is enough to warrant an extra (complex?) standard 
header in almost every TU. 

>> > > (emit_library_call): Added default arg unsigned_p.
>> > > (emit_library_call_value): Added default arg unsigned_p.
>> >
>> > Yeah, eww.  Default arguments have all the problems you had before,
>> > except now it is hidden and much more surprising.
>> >
>> > Those functions really should take rtx_mode_t arguments?
>> 
>> I was thinking the same. will incorporate this.
>
>Thanks!
>
>
>Segher

[Bug c++/95319] New: Regression from gcc9.3 when inserting into a vector with an initializer list. Error: a GNU-style designated initializer for class

[haldormnk at hotmail dot com]

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

Bug ID: 95319
   Summary: Regression from gcc9.3 when inserting into a vector
with an initializer list. Error: a GNU-style
designated initializer for class
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haldormnk at hotmail dot com
  Target Milestone: ---

https://godbolt.org/z/zZtP9z

#include 
#include 
#include 
int main() {
using Array = std::array;
using ArrayVector = std::vector;
auto vector = ArrayVector();
vector.emplace_back(Array({1,1,1})); // works
vector.insert(std::end(vector),{{2,2,2}}); // fails in gcc10.1
}

With gcc9.3 it compiles, but with gcc10.1, there is an error in the last line:

error: '[0] =' used in a GNU-style designated initializer for class
'std::array'

Re: [PATCH v1 1/2][PPC64] [PR88877]

[Segher Boessenkool]

On Mon, May 25, 2020 at 12:46:02PM +0530, kamlesh kumar wrote:
> > OTOH, you don't need to name Tuple at all...  It should not *have* a
> > constructor, since you declared it as class...  But you can just use
> > std::tuple here?
> 
> I thought of using std::tuple  but it requires c++11 support.
> I am not sure we always build gcc with c++11?

https://gcc.gnu.org/install/prerequisites.html

We do for GCC 11 :-)  Since we pay the price for progress, let's reap the
benefits as well :-)

> > > (emit_library_call): Added default arg unsigned_p.
> > > (emit_library_call_value): Added default arg unsigned_p.
> >
> > Yeah, eww.  Default arguments have all the problems you had before,
> > except now it is hidden and much more surprising.
> >
> > Those functions really should take rtx_mode_t arguments?
> 
> I was thinking the same. will incorporate this.

Thanks!


Segher

[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

--- Comment #3 from Brett Neumeier  ---
Created attachment 48596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48596=edit
result of compilation with -fno-align-loop specified

[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

--- Comment #2 from Brett Neumeier  ---
Created attachment 48595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48595=edit
result of compilation with default settings

[Bug bootstrap/95318] New: gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

Bug ID: 95318
   Summary: gcc 10.1 on x86_64 fails to build aarch64
cross-compiler when using default optimization
settings
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bneumeier at gmail dot com
  Target Milestone: ---

This issue is seen when building an X86_64-to-AArch64 cross-compiler
using GCC 10.1.

`gcc -v` on the host computer reports:
--
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/cbl/cbltools/libexec/gcc/x86_64-pc-linux-gnu/10.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /path/to/gcc-10.1.0/configure
  --prefix=/home/cbl/cbltools --with-local-prefix=/home/cbl/cbltools
  --disable-multilib --disable-nls --enable-shared
  --enable-languages=c,c++ --enable-c99 --enable-long-long
  --enable-threads=posix --with-gmp=/home/cbl/cbltools
  --with-mpfr=/home/cbl/cbltools --with-mpc=/home/cbl/cbltools
  --with-isl=/home/cbl/cbltools
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.1 20200507 (GCC)
--

The cross-compiler build was configured with:

../gcc-10.1.0/configure --prefix=/home/cbl/work/cross-tools
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=aarch64-cbl-linux-gnu --with-sysroot=/home/cbl/work/sysroot
--with-build-sysroot=/home/cbl/work/sysroot --disable-decimal-float
--disable-libgomp --disable-libmudflap --disable-libssp --disable-multilib
--disable-nls --disable-shared --disable-threads --enable-languages=c,c++
--with-newlib --without-headers --with-gmp=/home/cbl/cbltools
--with-mpfr=/home/cbl/cbltools --with-mpc=/home/cbl/cbltools
--with-isl=/home/cbl/cbltools --enable-fix-cortex-a53-835769
--enable-fix-cortex-a53-843419 --with-cpu=cortex-a72.cortex-a53

The issue is encountered after successfully completing the `all-gcc` make
target, and running `make all-target-libgcc`. Compilation of libgcc/unwind-c.c
produces errors:

/home/cbl/work/build/build-gcc-2/./gcc/xgcc
-B/home/cbl/work/build/build-gcc-2/./gcc/
-B/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/bin/
-B/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/lib/ -isystem
/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/include -isystem
/home/cbl/work/cross-tools/aarch64-cbl-linux-gnu/sys-include
--sysroot=/home/cbl/work/sysroot   -g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include   -fPIC -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -fPIC -I.
-I. -I../.././gcc -I/home/cbl/work/build/gcc-10.1.0/libgcc
-I/home/cbl/work/build/gcc-10.1.0/libgcc/.
-I/home/cbl/work/build/gcc-10.1.0/libgcc/../gcc
-I/home/cbl/work/build/gcc-10.1.0/libgcc/../include  -DHAVE_CC_TLS  -o
unwind-c.o -MT unwind-c.o -MD -MP -MF unwind-c.dep -fexceptions -c
/home/cbl/work/build/gcc-10.1.0/libgcc/unwind-c.c -fvisibility=hidden
-DHIDE_EXPORTS

/tmp/cc3usGId.s: Assembler messages:
/tmp/cc3usGId.s: Error: invalid operands (*ABS* and *GAS `expr' section*
sections) for `*' when setting `.LVU94'
/tmp/cc3usGId.s: Error: can't resolve value for symbol `.LVU94'

If I add the `-fno-align-loops` directive, this avoids the errors.

I'm attaching the preprocessed source `unwind-c.i`, and the compiled
`unwind-c.s` both with `-fno-align-loops` (working) and without (error).

After adding `-fno-align-loops` as a workaround, the cross-compiler build
completes without further issues. However, actually using the resulting
cross-compiler to build a target-native GCC (again, unless -fno-align-loops is
specified) fails with similar error messages on several other files, e.g.:

aarch64-cbl-linux-gnu-g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
-I/home/cbl/work/build/gcc-10.1.0/gcc -I/home/cbl/work/build/gcc-10.1.0/gcc/.
-I/home/cbl/work/build/gcc-10.1.0/gcc/../include
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libcpp/include
-I/home/cbl/work/sysroot/scaffolding/include
-I/home/cbl/work/sysroot/scaffolding/include
-I/home/cbl/work/sysroot/scaffolding/include 
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libdecnumber
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/cbl/work/build/gcc-10.1.0/gcc/../libbacktrace
-I/home/cbl/work/sysroot/scaffolding/include  -o gimple-low.o -MT gimple-low.o
-MMD -MP -MF ./.deps/gimple-low.TPo
/home/cbl/work/build/gcc-10.1.0/gcc/gimple-low.c
/tmp/ccMqyaI0.s: 

[Bug bootstrap/95318] gcc 10.1 on x86_64 fails to build aarch64 cross-compiler when using default optimization settings

[bneumeier at gmail dot com]

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

--- Comment #1 from Brett Neumeier  ---
Created attachment 48594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48594=edit
preprocessed source

Re: [PATCH 2/2] Provide diagnostic hints for missing C++ cinttypes string constants.

[Jason Merrill via Gcc-patches]

On 5/23/20 8:30 PM, Mark Wielaard wrote:

When reporting an error in cp_parser and we notice a string literal
followed by an unknown name check whether there is a known standard
header containing a string macro with the same name, then add a hint
to the error message to include that header.

gcc/c-family/ChangeLog:

* known-headers.cc (get_cp_stdlib_header_for_string_macro_name):
New function.
* known-headers.h (get_c_stdlib_header_for_string_macro_name):


Missing 'p'.


New function definition.


Declaration, not definition.

The C++ changes are OK with these ChangeLog corrections.


gcc/cp/ChangeLog:

* parser.c (cp_lexer_safe_previous_token): New function.
(cp_parser_error_1): Add name_hint if the previous token is
a string literal and next token is a CPP_NAME and we have a
missing header suggestion for the name.

gcc/testsuite/ChangeLog:

* g++.dg/spellcheck-inttypes.C: Add string-literal testcases.
---
  gcc/c-family/known-headers.cc  |  8 +
  gcc/c-family/known-headers.h   |  1 +
  gcc/cp/parser.c| 36 
  gcc/testsuite/g++.dg/spellcheck-inttypes.C | 39 ++
  4 files changed, 84 insertions(+)

diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index c07cfd1db815..977230a586db 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -268,6 +268,14 @@ get_c_stdlib_header_for_string_macro_name (const char 
*name)
return get_string_macro_hint (name, STDLIB_C);
  }
  
+/* Given non-NULL NAME, return the header name defining a string macro

+   within the C++ standard library (with '<' and '>'), or NULL.  */
+const char *
+get_cp_stdlib_header_for_string_macro_name (const char *name)
+{
+  return get_string_macro_hint (name, STDLIB_CPLUSPLUS);
+}
+
  /* Implementation of class suggest_missing_header.  */
  
  /* suggest_missing_header's ctor.  */

diff --git a/gcc/c-family/known-headers.h b/gcc/c-family/known-headers.h
index a69bbbf28e76..f0c89dc9019d 100644
--- a/gcc/c-family/known-headers.h
+++ b/gcc/c-family/known-headers.h
@@ -24,6 +24,7 @@ extern const char *get_c_stdlib_header_for_name (const char 
*name);
  extern const char *get_cp_stdlib_header_for_name (const char *name);
  
  extern const char *get_c_stdlib_header_for_string_macro_name (const char *n);

+extern const char *get_cp_stdlib_header_for_string_macro_name (const char *n);
  
  /* Subclass of deferred_diagnostic for suggesting to the user

 that they have missed a #include.  */
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 54ca875ce54c..95b8c635fc65 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.  If not see
  #include "tree-iterator.h"
  #include "cp-name-hint.h"
  #include "memmodel.h"
+#include "c-family/known-headers.h"
  
  

  /* The lexer.  */
@@ -776,6 +777,20 @@ cp_lexer_previous_token (cp_lexer *lexer)
return cp_lexer_token_at (lexer, tp);
  }
  
+/* Same as above, but return NULL when the lexer doesn't own the token

+   buffer or if the next_token is at the start of the token
+   vector.  */
+
+static cp_token *
+cp_lexer_safe_previous_token (cp_lexer *lexer)
+{
+  if (lexer->buffer)
+if (lexer->next_token != lexer->buffer->address ())
+  return cp_lexer_previous_token (lexer);
+
+  return NULL;
+}
+
  /* Overload for make_location, taking the lexer to mean the location of the
 previous token.  */
  
@@ -2919,6 +2934,7 @@ cp_parser_error_1 (cp_parser* parser, const char* gmsgid,

}
  }
  
+  auto_diagnostic_group d;

gcc_rich_location richloc (input_location);
  
bool added_matching_location = false;

@@ -2941,6 +2957,26 @@ cp_parser_error_1 (cp_parser* parser, const char* gmsgid,
  = richloc.add_location_if_nearby (matching_location);
  }
  
+  /* If we were parsing a string-literal and there is an unknown name

+ token right after, then check to see if that could also have been
+ a literal string by checking the name against a list of known
+ standard string literal constants defined in header files. If
+ there is one, then add that as an hint to the error message. */
+  name_hint h;
+  cp_token *prev_token = cp_lexer_safe_previous_token (parser->lexer);
+  if (prev_token && cp_parser_is_string_literal (prev_token)
+  && token->type == CPP_NAME)
+{
+  tree name = token->u.value;
+  const char *token_name = IDENTIFIER_POINTER (name);
+  const char *header_hint
+   = get_cp_stdlib_header_for_string_macro_name (token_name);
+  if (header_hint != NULL)
+   h = name_hint (NULL, new suggest_missing_header (token->location,
+token_name,
+header_hint));
+}
+
/* Actually emit the error.  */
c_parse_error (gmsgid,