Re: [PATCH] Don't DCE const/pure calls that can throw if cfg can't be altered (PR rtl-optimization/88870)

2019-01-17 Thread Arnaud Charlet
> > >   PR rtl-optimization/88870
> > >   * dce.c (deletable_insn_p): Never delete const/pure calls that can
> > >   throw if we can't alter the cfg or delete dead exceptions.
> > >   (mark_insn): Don't call find_call_stack_args for such calls.
> > > 
> > >   * gcc.dg/pr88870.c: New test.
> > OK.  Though I wonder if we want to continue to support
> > -fnon-call-exceptions.  With GCJ gone is there any value left in that
> > capability?  There's little doubt in my mind other parts of GCC are not
> > -fnon-call-exception safe.
> 
> AFAIK Ada and Go use -fnon-call-exceptions by default and heavily rely on
> it.

Agreed.


[PATCH] Fix PR86736

2019-01-17 Thread Richard Biener


The following reportedly fixes PR86736, a dwarf2out ICE with
-gpubnames (default on darwin) when compiling with -g0
(default on darwin) but linking with -g.  pubnames (and types)
are really part of early debug - there is no point in emitting
those late (but the early part also fails, see PR88878 I opened).

Committed to trunk.

Richard.

2019-01-17  Richard Biener  

PR lto/86736
* dwarf2out.c (want_pubnames): Never generate pubnames sections
and friends for the LTO part of debug info.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index a1b5a5eaf19..cd2e889a8cc 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -11074,7 +11074,9 @@ output_comp_unit (dw_die_ref die, int output_if_empty,
 static inline bool
 want_pubnames (void)
 {
-  if (debug_info_level <= DINFO_LEVEL_TERSE)
+  if (debug_info_level <= DINFO_LEVEL_TERSE
+  /* Names and types go to the early debug part only.  */
+  || in_lto_p)
 return false;
   if (debug_generate_pub_sections != -1)
 return debug_generate_pub_sections;


Re: [PATCH][AArch64] Initial -mcpu=ares tuning

2019-01-17 Thread Kyrill Tkachov

Hi James,

On 16/01/19 18:27, James Greenhalgh wrote:

On Tue, Jan 15, 2019 at 09:29:46AM -0600, Kyrill Tkachov wrote:

Hi all,

This patch adds a tuning struct for the Arm Ares CPU and uses it for 
-m{cpu,tune}=ares.
The tunings are an initial attempt and may be improved upon in the future, but 
they serve
as a decent starting point for GCC 9.

With this I see a 1.3% improvement on SPEC2006 int and 0.3% on SPEC2006 fp with 
-mcpu=ares.
On SPEC2017 I see a 0.6% improvement in intrate and changes in the noise for 
fprate.

Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?

This only changes non-default tuning.

OK.


Thanks.



Are we nearly done with these types of changes in AArch64 for GCC 9? I'd
like to see us start acting like it is stage 4 soon!


I believe there's a CPU tuning patch from Wuyuan waiting for review at:
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00777.html

Kyrill



James


2019-01-15  Kyrylo Tkachov  

  * config/aarch64/aarch64.c (ares_tunings): Define.
  * config/aarch64/aarch64-cores.def (ares): Use the above.




Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI

2019-01-17 Thread Richard Sandiford
Steve Ellcey  writes:
> +/* Return true for types that could be supported as SIMD return or
> +   argument types.  */
> +
> +static bool supported_simd_type (tree t)

Missing line break after "static bool".

> +{
> +  if (SCALAR_FLOAT_TYPE_P (t) || INTEGRAL_TYPE_P (t) || POINTER_TYPE_P (t))
> +{
> +  HOST_WIDE_INT s = tree_to_shwi (TYPE_SIZE_UNIT (t));
> +  return s == 1 || s == 2 || s == 4 || s == 8;
> +}
> +  return false;
> +}
> +
> +/* Return true for types that currently are supported as SIMD return
> +   or argument types.  */
> +
> +static bool currently_supported_simd_type (tree t, tree b)

Same here.

> +{
> +  if (COMPLEX_FLOAT_TYPE_P (t))
> +return false;
> +
> +  if (TYPE_SIZE (t) != TYPE_SIZE (b))
> +return false;
> +
> +  return supported_simd_type (t);
> +}
> +
> +/* Implement TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN.  */
> +
> +static int
> +aarch64_simd_clone_compute_vecsize_and_simdlen (struct cgraph_node *node,
> + struct cgraph_simd_clone *clonei,
> + tree base_type, int num)
> +{
> +  tree t, ret_type, arg_type;
> +  unsigned int elt_bits, vec_bits, count;
> +
> +  if (!TARGET_SIMD)
> +return 0;
> +
> +  if (clonei->simdlen
> +  && (clonei->simdlen < 2
> +   || clonei->simdlen > 1024
> +   || (clonei->simdlen & (clonei->simdlen - 1)) != 0))
> +{
> +  warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
> +   "unsupported simdlen %d", clonei->simdlen);
> +  return 0;
> +}
> +
> +  ret_type = TREE_TYPE (TREE_TYPE (node->decl));
> +  if (TREE_CODE (ret_type) != VOID_TYPE
> +  && !currently_supported_simd_type (ret_type, base_type))
> +{
> +  if (TYPE_SIZE (ret_type) != TYPE_SIZE (base_type))
> + warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
> + "GCC does not currently support mixed size types "
> + "for % functions");
> +  else if (supported_simd_type (ret_type))
> + warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
> + "GCC does not currently support return type %qT "
> + "for % functions", ret_type);
> +  else
> + warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
> + "unsupported return type %qT for % functions",
> + ret_type);
> +  return 0;
> +}
> +
> +  for (t = DECL_ARGUMENTS (node->decl); t; t = DECL_CHAIN (t))
> +{
> +  arg_type = TREE_TYPE (t);
> +
> +  if (!currently_supported_simd_type (arg_type, base_type))
> + {
> +   if (TYPE_SIZE (arg_type) != TYPE_SIZE (base_type))
> + warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
> + "GCC does not currently support mixed size types "
> + "for % functions");
> +   else
> + warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
> + "GCC does not currently support argument type %qT "
> + "for % functions", arg_type);
> +   return 0;
> + }
> +}
> +
> +  clonei->vecsize_mangle = 'n';
> +  clonei->mask_mode = VOIDmode;
> +  elt_bits = GET_MODE_BITSIZE (SCALAR_TYPE_MODE (base_type));
> +  if (clonei->simdlen == 0)
> +{
> +  count = 2;
> +  vec_bits = (num == 0 ? 64 : 128);
> +  clonei->simdlen = vec_bits / elt_bits;
> +}
> +  else
> +{
> +  count = 1;
> +  vec_bits = clonei->simdlen * elt_bits;
> +  if (vec_bits != 64 && vec_bits != 128)
> +{
> +   warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
> +   "GCC does not currently support simdlen %d for type %qT",
> +   clonei->simdlen, base_type);
> +  return 0;

The return should use tab indentation.

OK otherwise, thanks.

Richard


RE: [Vectorizer] Add SLP support for masked loads

2019-01-17 Thread Alejandro Martinez Vicente
> -Original Message-
> From: Richard Biener 
> Sent: 17 January 2019 07:53
> To: Alejandro Martinez Vicente 
> Cc: GCC Patches ; nd ; Richard
> Sandiford 
> Subject: Re: [Vectorizer] Add SLP support for masked loads
> 
> On Wed, Jan 16, 2019 at 2:37 PM Alejandro Martinez Vicente
>  wrote:
> >
> > Hi,
> >
> > Current vectorizer doesn't support masked loads for SLP. We should add
> > that, to allow things like:
> >
> > void
> > f (int *restrict x, int *restrict y, int *restrict z, int n) {
> >   for (int i = 0; i < n; i += 2)
> > {
> >   x[i] = y[i] ? z[i] : 1;
> >   x[i + 1] = y[i + 1] ? z[i + 1] : 2;
> > }
> > }
> >
> > to be vectorized using contiguous loads rather than LD2 and ST2.
> >
> > This patch was motivated by SVE, but it is completely generic and
> > should apply to any architecture with masked loads.
> >
> > After the patch is applied, the above code generates this output
> > (-march=armv8.2-a+sve -O2 -ftree-vectorize):
> >
> >  :
> >0:   717fcmp w3, #0x0
> >4:   540002cdb.le5c 
> >8:   51000464sub w4, w3, #0x1
> >c:   d283mov x3, #0x0// #0
> >   10:   9005adrpx5, 0 
> >   14:   25d8e3e0ptrue   p0.d
> >   18:   53017c84lsr w4, w4, #1
> >   1c:   91a5add x5, x5, #0x0
> >   20:   11000484add w4, w4, #0x1
> >   24:   85c0e0a1ld1rd   {z1.d}, p0/z, [x5]
> >   28:   2598e3e3ptrue   p3.s
> >   2c:   d37ff884lsl x4, x4, #1
> >   30:   25a41fe2whilelo p2.s, xzr, x4
> >   34:   d503201fnop
> >   38:   a5434820ld1w{z0.s}, p2/z, [x1, x3, lsl #2]
> >   3c:   25808c11cmpne   p1.s, p3/z, z0.s, #0
> >   40:   25808810cmpne   p0.s, p2/z, z0.s, #0
> >   44:   a5434040ld1w{z0.s}, p0/z, [x2, x3, lsl #2]
> >   48:   05a1c400sel z0.s, p1, z0.s, z1.s
> >   4c:   e5434800st1w{z0.s}, p2, [x0, x3, lsl #2]
> >   50:   04b0e3e3incwx3
> >   54:   25a41c62whilelo p2.s, x3, x4
> >   58:   5401b.ne38   // b.any
> >   5c:   d65f03c0ret
> >
> >
> > I tested this patch in an aarch64 machine bootstrapping the compiler
> > and running the checks.
> 
> Thanks for implementing this - note this is stage1 material and I will have a
> look when time allows unless Richard beats me to it.
> 


I agree, this is for GCC 10. I'll ping you guys when we're at stage1.

> It might be interesting to note that "non-SLP" code paths are likely to go
> away in GCC 10 to streamline the vectorizer and make further changes easier
> (so you'll see group_size == 1 SLP instances).
> 

Cool, thanks for the heads up.

Alejandro

> There are quite a few other cases missing SLP handling.
> 
> Richard.
> 
> > Alejandro
> >
> > gcc/Changelog:
> >
> > 2019-01-16  Alejandro Martinez  
> >
> > * config/aarch64/aarch64-sve.md (copysign3): New
> define_expand.
> > (xorsign3): Likewise.
> > internal-fn.c: Marked mask_load_direct and mask_store_direct as
> > vectorizable.
> > tree-data-ref.c (data_ref_compare_tree): Fixed comment typo.
> > tree-vect-data-refs.c (can_group_stmts_p): Allow masked loads to be
> > combined even if masks different.
> > (slp_vect_only_p): New function to detect masked loads that are only
> > vectorizable using SLP.
> > (vect_analyze_data_ref_accesses): Mark SLP only vectorizable groups.
> > tree-vect-loop.c (vect_dissolve_slp_only_groups): New function to
> > dissolve SLP-only vectorizable groups when SLP has been discarded.
> > (vect_analyze_loop_2): Call vect_dissolve_slp_only_groups when
> needed.
> > tree-vect-slp.c (vect_get_and_check_slp_defs): Check masked loads
> > masks.
> > (vect_build_slp_tree_1): Fixed comment typo.
> > (vect_build_slp_tree_2): Include masks from masked loads in SLP 
> > tree.
> > tree-vect-stmts.c (vect_get_vec_defs_for_operand): New function to
> get
> > vec_defs for operand with optional SLP and vectype.
> > (vectorizable_load): Allow vectorizaion of masked loads for SLP 
> > only.
> > tree-vectorizer.h (_stmt_vec_info): Added flag for SLP-only
> > vectorizable.
> > tree-vectorizer.c (vec_info::new_stmt_vec_info): Likewise.
> >
> > gcc/testsuite/Changelog:
> >
> > 2019-01-16  Alejandro Martinez  
> >
> > * gcc.target/aarch64/sve/mask_load_slp_1.c: New test for SLP
> > vectorized masked loads.


[C++ Patch] In grokdeclarator, use typespec_loc in error messages about 'auto' and trailing return type

2019-01-17 Thread Paolo Carlini

Hi,

just use in more places the carefully constructed typespec_loc. Note for 
another time: the 'type name' we print for tests like cpp0x/auto52.C 
doesn't seem particularly clear to me. Tested x86_64-linux, as usual.


Thanks, Paolo.



/cp
2019-01-17  Paolo Carlini  

* decl.c (grokdeclarator): Use typespec_loc in error messages
about 'auto' and trailing return type.

/testsuite
2019-01-17  Paolo Carlini  

* g++.dg/cpp0x/auto52.C: Test locations too.
* g++.dg/cpp0x/trailing2.C: Likewise.
* g++.dg/cpp1y/auto-fn18.C: Likewise.
* g++.dg/cpp1y/auto-fn25.C: Likewise.
* g++.dg/cpp1y/auto-fn52.C: Likewise.
* g++.dg/cpp1y/auto-fn53.C: Likewise.
* g++.dg/cpp1y/auto-fn54.C: Likewise.
Index: cp/decl.c
===
--- cp/decl.c   (revision 267986)
+++ cp/decl.c   (working copy)
@@ -11287,35 +11288,37 @@ grokdeclarator (const cp_declarator *declarator,
  /* OK for C++11 lambdas.  */;
else if (cxx_dialect < cxx14)
  {
-   error ("%qs function uses "
-  "% type specifier without trailing "
-  "return type", name);
-   inform (input_location, "deduced return type "
-   "only available with -std=c++14 or "
-   "-std=gnu++14");
+   error_at (typespec_loc, "%qs function uses "
+ "% type specifier without "
+ "trailing return type", name);
+   inform (typespec_loc,
+   "deduced return type only available "
+   "with -std=c++14 or -std=gnu++14");
  }
else if (virtualp)
  {
-   error ("virtual function cannot "
-  "have deduced return type");
+   error_at (typespec_loc, "virtual function "
+ "cannot have deduced return type");
virtualp = false;
  }
  }
else if (!is_auto (type) && sfk != sfk_conversion)
  {
-   error ("%qs function with trailing return type has"
-  " %qT as its type rather than plain %",
-  name, type);
+   error_at (typespec_loc, "%qs function with trailing "
+ "return type has %qT as its type rather "
+ "than plain %", name, type);
return error_mark_node;
  }
else if (is_auto (type) && AUTO_IS_DECLTYPE (type))
  {
if (funcdecl_p)
- error ("%qs function with trailing return type has "
-"% as its type rather than "
-"plain %", name);
+ error_at (typespec_loc,
+   "%qs function with trailing return type "
+   "has % as its type "
+   "rather than plain %", name);
else
- error ("invalid use of %");
+ error_at (typespec_loc,
+   "invalid use of %");
return error_mark_node;
  }
tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node);
@@ -11359,11 +11362,13 @@ grokdeclarator (const cp_declarator *declarator,
if (cxx_dialect < cxx11)
  /* Not using maybe_warn_cpp0x because this should
 always be an error.  */
- error ("trailing return type only available with "
-"-std=c++11 or -std=gnu++11");
+ error_at (typespec_loc,
+   "trailing return type only available "
+   "with -std=c++11 or -std=gnu++11");
else
- error ("%qs function with trailing return type not "
-"declared with % type specifier", name);
+ error_at (typespec_loc, "%qs function with trailing "
+   "return type not declared with % "
+   "type specifier", name);
return error_mark_node;
  }
  }
Index: testsuite/g++.dg/cpp0x/auto52.C
=

Re: [PATCH] Reset proper type on vector types (PR middle-end/88587).

2019-01-17 Thread Martin Liška
On 1/16/19 1:06 PM, Richard Biener wrote:
> On Wed, Jan 16, 2019 at 10:20 AM Martin Liška  wrote:
>>
>> Hi.
>>
>> The patch is about resetting TYPE_MODE of vector types. This is problematic
>> when an inlining among different ISAs happen. Then we end up with a different
>> mode than when it's expected from debug info.
>>
>> When creating a new function decl in target_clones, we must 
>> valid_attribute_p early
>> so that the declaration has a proper cl_target_.. node and so that inliner 
>> can
>> fix modes.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
> 
> I don't like the new failure mode too much.  It looks like
> create_version_clone_with_body
> can fail so why not simply return NULL when
> targetm.target_option.valid_attribute_p
> returns false and handle that case in multi-versioning?
> 
> That is,
> 
> +  return !seen_error ();
> 
> that looks very wrong to me.

Yep, update patch should be better.

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

Ready to be installed?
Thanks,
Martin

> 
> Richard.
> 
>> Thanks,
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2019-01-16  Martin Liska  
>> Richard Biener  
>>
>> PR middle-end/88587
>> * cgraph.h (create_version_clone_with_body): Add new argument
>> with attributes.
>> * cgraphclones.c (cgraph_node::create_version_clone): Add
>> DECL_ATTRIBUTES to a newly created decl.  And call
>> valid_attribute_p so that proper cl_target_optimization_node
>> is set for the newly created declaration.
>> * multiple_target.c (create_target_clone): Set DECL_ATTRIBUTES
>> for declaration.
>> (expand_target_clones): Do not call valid_attribute_p, it must
>> be already done.
>> * tree-inline.c (copy_decl_for_dup_finish): Reset mode for
>> vector types.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2019-01-16  Martin Liska  
>>
>> PR middle-end/88587
>> * g++.target/i386/pr88587.C: New test.
>> * gcc.target/i386/mvc13.c: New test.
>> ---
>>  gcc/cgraph.h|  7 +-
>>  gcc/cgraphclones.c  | 18 +-
>>  gcc/multiple_target.c   | 32 -
>>  gcc/testsuite/g++.target/i386/pr88587.C | 15 
>>  gcc/testsuite/gcc.target/i386/mvc13.c   |  9 +++
>>  gcc/tree-inline.c   |  4 
>>  6 files changed, 61 insertions(+), 24 deletions(-)
>>  create mode 100644 gcc/testsuite/g++.target/i386/pr88587.C
>>  create mode 100644 gcc/testsuite/gcc.target/i386/mvc13.c
>>
>>

>From 3deeb24418fa5078a407ff6fee6d9d958b9ea869 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 16 Jan 2019 09:05:02 +0100
Subject: [PATCH] Reset proper type on vector types (PR middle-end/88587).

gcc/ChangeLog:

2019-01-16  Martin Liska  
	Richard Biener  

	PR middle-end/88587
	* cgraph.h (create_version_clone_with_body): Add new argument
	with attributes.
	* cgraphclones.c (cgraph_node::create_version_clone): Add
	DECL_ATTRIBUTES to a newly created decl.  And call
	valid_attribute_p so that proper cl_target_optimization_node
	is set for the newly created declaration.
	* multiple_target.c (create_target_clone): Set DECL_ATTRIBUTES
	for declaration.
	(expand_target_clones): Do not call valid_attribute_p, it must
	be already done.
	* tree-inline.c (copy_decl_for_dup_finish): Reset mode for
	vector types.

gcc/testsuite/ChangeLog:

2019-01-16  Martin Liska  

	PR middle-end/88587
	* g++.target/i386/pr88587.C: New test.
	* gcc.target/i386/mvc13.c: New test.
---
 gcc/cgraph.h|  7 -
 gcc/cgraphclones.c  | 20 +-
 gcc/multiple_target.c   | 36 ++---
 gcc/testsuite/g++.target/i386/pr88587.C | 15 +++
 gcc/testsuite/gcc.target/i386/mvc13.c   |  9 +++
 gcc/tree-inline.c   |  4 +++
 6 files changed, 67 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/i386/pr88587.C
 create mode 100644 gcc/testsuite/gcc.target/i386/mvc13.c

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index c016da3875c..bb231833328 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -1019,12 +1019,17 @@ public:
  If non-NULL BLOCK_TO_COPY determine what basic blocks to copy.
  If non_NULL NEW_ENTRY determine new entry BB of the clone.
 
+ If TARGET_ATTRIBUTES is non-null, when creating a new declaration,
+ add the attributes to DECL_ATTRIBUTES.  And call valid_attribute_p
+ that will promote value of the attribute DECL_FUNCTION_SPECIFIC_TARGET
+ of the declaration.
+
  Return the new version's cgraph node.  */
   cgraph_node *create_version_clone_with_body
 (vec redirect_callers,
  vec *tree_map, bitmap args_to_skip,
  bool skip_return, bitmap bbs_to_copy, basic_block new_entry_block,
- const char *clone_name);
+ const char *clone_name, tree

Re: [PATCH] Don't DCE const/pure calls that can throw if cfg can't be altered (PR rtl-optimization/88870)

2019-01-17 Thread Eric Botcazou
> AFAIK Ada and Go use -fnon-call-exceptions by default and heavily rely on
> it.

Right, the Ada compiler uses -fnon-call-exceptions -fdelete-dead-exceptions 
and ACATS could not be passed with optimization enabled without the former.

Btw, there are a couple of improper direct uses of flag_non_call_exceptions in 
the sources, may I change them to cfun->can_throw_non_call_exceptions?

gimple-ssa-isolate-paths.c:  if (!flag_non_call_exceptions)
gimple-ssa-isolate-paths.c:  if (!flag_non_call_exceptions
tree-ssa-alias.c:  if (flag_non_call_exceptions && pi->pt.null)

-- 
Eric Botcazou


Re: [PATCH] Don't DCE const/pure calls that can throw if cfg can't be altered (PR rtl-optimization/88870)

2019-01-17 Thread Jakub Jelinek
On Thu, Jan 17, 2019 at 12:27:31PM +0100, Eric Botcazou wrote:
> > AFAIK Ada and Go use -fnon-call-exceptions by default and heavily rely on
> > it.
> 
> Right, the Ada compiler uses -fnon-call-exceptions -fdelete-dead-exceptions 
> and ACATS could not be passed with optimization enabled without the former.
> 
> Btw, there are a couple of improper direct uses of flag_non_call_exceptions 
> in 
> the sources, may I change them to cfun->can_throw_non_call_exceptions?

Yes.

> gimple-ssa-isolate-paths.c:  if (!flag_non_call_exceptions)
> gimple-ssa-isolate-paths.c:  if (!flag_non_call_exceptions
> tree-ssa-alias.c:  if (flag_non_call_exceptions && pi->pt.null)

Jakub


Re: [PATCH] C++: Fix ICE when adding overloaded operator via using_decl (PR c++/88699)

2019-01-17 Thread Nathan Sidwell

On 1/16/19 6:44 PM, David Malcolm wrote:

PR c++/88699 reports an ICE within this assertion in add_method:

   gcc_assert (!current_fns || !DECL_DESTRUCTOR_P (method));

when adding an overloaded operator to a class via a using_decl, due to
DECL_DESTRUCTOR_P requiring a FUNCTION_DECL, but "method" being a
USING_DECL.

This patch weakens the assertion to avoid testing DECL_DESTRUCTOR_P
for the case where "via_using" is true, fixing the ICE.

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

OK for trunk?

gcc/cp/ChangeLog:
PR c++/88699
* class.c (add_method): Don't use DECL_DESTRUCTOR_P on
USING_DECLs.

gcc/testsuite/ChangeLog:
PR c++/88699
* g++.dg/template/pr88699.C: New test.


ok thanks


--
Nathan Sidwell


Re: [PATCH] Reset proper type on vector types (PR middle-end/88587).

2019-01-17 Thread Richard Biener
On Thu, Jan 17, 2019 at 12:21 PM Martin Liška  wrote:
>
> On 1/16/19 1:06 PM, Richard Biener wrote:
> > On Wed, Jan 16, 2019 at 10:20 AM Martin Liška  wrote:
> >>
> >> Hi.
> >>
> >> The patch is about resetting TYPE_MODE of vector types. This is problematic
> >> when an inlining among different ISAs happen. Then we end up with a 
> >> different
> >> mode than when it's expected from debug info.
> >>
> >> When creating a new function decl in target_clones, we must 
> >> valid_attribute_p early
> >> so that the declaration has a proper cl_target_.. node and so that inliner 
> >> can
> >> fix modes.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >>
> >> Ready to be installed?
> >
> > I don't like the new failure mode too much.  It looks like
> > create_version_clone_with_body
> > can fail so why not simply return NULL when
> > targetm.target_option.valid_attribute_p
> > returns false and handle that case in multi-versioning?
> >
> > That is,
> >
> > +  return !seen_error ();
> >
> > that looks very wrong to me.
>
> Yep, update patch should be better.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

OK.

Thanks,
Richard.

> Thanks,
> Martin
>
> >
> > Richard.
> >
> >> Thanks,
> >> Martin
> >>
> >> gcc/ChangeLog:
> >>
> >> 2019-01-16  Martin Liska  
> >> Richard Biener  
> >>
> >> PR middle-end/88587
> >> * cgraph.h (create_version_clone_with_body): Add new argument
> >> with attributes.
> >> * cgraphclones.c (cgraph_node::create_version_clone): Add
> >> DECL_ATTRIBUTES to a newly created decl.  And call
> >> valid_attribute_p so that proper cl_target_optimization_node
> >> is set for the newly created declaration.
> >> * multiple_target.c (create_target_clone): Set DECL_ATTRIBUTES
> >> for declaration.
> >> (expand_target_clones): Do not call valid_attribute_p, it must
> >> be already done.
> >> * tree-inline.c (copy_decl_for_dup_finish): Reset mode for
> >> vector types.
> >>
> >> gcc/testsuite/ChangeLog:
> >>
> >> 2019-01-16  Martin Liska  
> >>
> >> PR middle-end/88587
> >> * g++.target/i386/pr88587.C: New test.
> >> * gcc.target/i386/mvc13.c: New test.
> >> ---
> >>  gcc/cgraph.h|  7 +-
> >>  gcc/cgraphclones.c  | 18 +-
> >>  gcc/multiple_target.c   | 32 -
> >>  gcc/testsuite/g++.target/i386/pr88587.C | 15 
> >>  gcc/testsuite/gcc.target/i386/mvc13.c   |  9 +++
> >>  gcc/tree-inline.c   |  4 
> >>  6 files changed, 61 insertions(+), 24 deletions(-)
> >>  create mode 100644 gcc/testsuite/g++.target/i386/pr88587.C
> >>  create mode 100644 gcc/testsuite/gcc.target/i386/mvc13.c
> >>
> >>
>


Re: [PATCH v3 00/10] AMD GCN Port v3

2019-01-17 Thread Andrew Stubbs

On 14/01/2019 13:55, Andrew Stubbs wrote:
I will now rebase, retest, change all the dates to 2019, and get it 
committed.


This is now done! :-)

THe Newlib port is also committed, so all the pieces needed for testing 
GCN should be available to everybody now.


To be clear, the libgomp port needed to support OpenMP still needs to be 
cleaned up and submitted, and the middle-end patches required to support 
OpenACC are likewise to-do (and currently depend on the openacc 
development branches, in any case).


Many thanks to Jeff, both Richards, Mike, and others for reviewing the 
patches.


Andrew


Re: [PATCH v3 00/10] AMD GCN Port v3

2019-01-17 Thread Richard Biener
On Thu, Jan 17, 2019 at 1:51 PM Andrew Stubbs  wrote:
>
> On 14/01/2019 13:55, Andrew Stubbs wrote:
> > I will now rebase, retest, change all the dates to 2019, and get it
> > committed.
>
> This is now done! :-)
>
> THe Newlib port is also committed, so all the pieces needed for testing
> GCN should be available to everybody now.
>
> To be clear, the libgomp port needed to support OpenMP still needs to be
> cleaned up and submitted, and the middle-end patches required to support
> OpenACC are likewise to-do (and currently depend on the openacc
> development branches, in any case).
>
> Many thanks to Jeff, both Richards, Mike, and others for reviewing the
> patches.

Please make notes in gcc-9/changes.html and update the ports matrix
in (... go find it!) and also add a news entry to index.html.

Richard.

> Andrew


Re: V2 [PATCH] c-family: Update unaligned adress of packed member check

2019-01-17 Thread H.J. Lu
On Wed, Jan 16, 2019 at 8:57 PM H.J. Lu  wrote:
>
> On Wed, Jan 16, 2019 at 01:28:26PM +0100, Jakub Jelinek wrote:
> > On Wed, Jan 16, 2019 at 04:11:44AM -0800, H.J. Lu wrote:
> > > > Why?  What is so special about C and (implicit?) casts where the rhs 
> > > > isn't
> > > > ADDR_EXPR?  Aren't all casts (explicit or implicit) from one pointer 
> > > > type
> > > > to another pointer and satisfy the rules something that should be warned
> > >
> > > -Wincompatible-pointer-types is C only.   In C++,  incompatible pointer 
> > > types
> > > aren't allowed at all.
> >
> > How so?  You can certainly:
> > struct B { int i; };
> > struct C { struct B b; } __attribute__ ((packed));
> >
> > extern struct C *p;
> > long* g8 (void) { return (long *)p; }
> >
> > and similarly for C.  So, why is explicit cast something that shouldn't
> > be warned about in this case and implicit cast should get a warning,
> > especially when it already does get one (and one even enabled by default,
> > -Wincompatible-pointer-types)?
> > Either such casts are problematic and then it should treat explicit and
> > implicit casts the same, or they aren't, and then
> > -Wincompatible-pointer-types is all you need.
> >
>
> I am testing this patch.
>

There is no regression.

> H.J.
> ---
> Check unaligned pointer conversion and strip NOPS.
>
> gcc/c-family/
>
> PR c/51628
> PR c/88664
> * c-common.h (warn_for_address_or_pointer_of_packed_member):
> Remove the boolean argument.
> * c-warn.c (check_address_of_packed_member): Renamed to ...
> (check_address_or_pointer_of_packed_member): This.  Also
> warn pointer conversion.
> (check_and_warn_address_of_packed_member): Renamed to ...
> (check_and_warn_address_or_pointer_of_packed_member): This.
> Also warn pointer conversion.
> (warn_for_address_or_pointer_of_packed_member): Remove the
> boolean argument.  Don't check pointer conversion here.
>
> gcc/c
>
> PR c/51628
> PR c/88664
> * c-typeck.c (convert_for_assignment): Upate the
> warn_for_address_or_pointer_of_packed_member call.
>
> gcc/cp
>
> PR c/51628
> PR c/88664
> * call.c (convert_for_arg_passing): Upate the
> warn_for_address_or_pointer_of_packed_member call.
> * typeck.c (convert_for_assignment): Likewise.
>
> gcc/testsuite/
>
> PR c/51628
> PR c/88664
> * c-c++-common/pr51628-33.c: New test.
> * c-c++-common/pr51628-35.c: New test.
> * c-c++-common/pr88664-1.c: Likewise.
> * c-c++-common/pr88664-2.c: Likewise.
> * gcc.dg/pr51628-34.c: Likewise.
> ---
>  gcc/c-family/c-common.h |   2 +-
>  gcc/c-family/c-warn.c   | 154 +---
>  gcc/c/c-typeck.c|   6 +-
>  gcc/cp/call.c   |   2 +-
>  gcc/cp/typeck.c |   2 +-
>  gcc/testsuite/c-c++-common/pr51628-33.c |  19 +++
>  gcc/testsuite/c-c++-common/pr51628-35.c |  15 +++
>  gcc/testsuite/c-c++-common/pr88664-1.c  |  20 +++
>  gcc/testsuite/c-c++-common/pr88664-2.c  |  22 
>  gcc/testsuite/gcc.dg/pr51628-34.c   |  25 
>  10 files changed, 190 insertions(+), 77 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/pr51628-33.c
>  create mode 100644 gcc/testsuite/c-c++-common/pr51628-35.c
>  create mode 100644 gcc/testsuite/c-c++-common/pr88664-1.c
>  create mode 100644 gcc/testsuite/c-c++-common/pr88664-2.c
>  create mode 100644 gcc/testsuite/gcc.dg/pr51628-34.c
>
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index db16ae94b64..460954fefd8 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -1284,7 +1284,7 @@ extern void c_do_switch_warnings (splay_tree, 
> location_t, tree, tree, bool,
>   bool);
>  extern void warn_for_omitted_condop (location_t, tree);
>  extern bool warn_for_restrict (unsigned, tree *, unsigned);
> -extern void warn_for_address_or_pointer_of_packed_member (bool, tree, tree);
> +extern void warn_for_address_or_pointer_of_packed_member (tree, tree);
>
>  /* Places where an lvalue, or modifiable lvalue, may be required.
> Used to select diagnostic messages in lvalue_error and
> diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
> index 79b2d8ad449..5df17ba2e1b 100644
> --- a/gcc/c-family/c-warn.c
> +++ b/gcc/c-family/c-warn.c
> @@ -2713,12 +2713,14 @@ check_alignment_of_packed_member (tree type, tree 
> field)
>return NULL_TREE;
>  }
>
> -/* Return struct or union type if the right hand value, RHS, takes the
> -   unaligned address of packed member of struct or union when assigning
> -   to TYPE.  Otherwise, return NULL_TREE.  */
> +/* Return struct or union type if the right hand value, RHS:
> +   1. Is a pointer value which isn't aligned to a pointer type TYPE.
> +   2. Is an address which takes the unaligned address of packe

[PATCH] Read avx512vl-vfixupimms*-2.c testcases (PR target/88489)

2019-01-17 Thread Jakub Jelinek
On Wed, Jan 16, 2019 at 07:12:56PM +0800, Wei Xiao wrote:
> > > Yes, but please test the compiler after the revert. Please also create
> > > a runtime testcase out of the testcase in the PR.
> Yes, we have tested it but current runtime testcase can't cover the corner
> case to expose the incorrectness of SDM. We will add some after the revert.
> 
> > For r267160, I'd expect you want to revert just the config/i386/ part and
> > keep the testcases, they should work even with the changes reverted, right?
> >
> The testcase part also need to be reverted since we have changed them
> according to the incorrect intrinsic list in SDM.

I don't really understand this.

The testcases succeed just fine for me in the current trunk with all the
reversions and test something the current state of the testsuite doesn't
check normally, in particular that the testcases run correctly even when
-mavx512vl is used.  As that misbehaved in the past, we should make sure we
don't break that again.

Uros, is it ok to reapply this to current trunk?

2019-01-17  Jakub Jelinek  

Reapply:
2018-12-15  Jakub Jelinek  

PR target/88489
* gcc.target/i386/avx512vl-vfixupimmsd-2.c: New test.
* gcc.target/i386/avx512vl-vfixupimmss-2.c: New test.

--- gcc/testsuite/gcc.target/i386/avx512vl-vfixupimmsd-2.c  (nonexistent)
+++ gcc/testsuite/gcc.target/i386/avx512vl-vfixupimmsd-2.c  (revision 
268010)
@@ -0,0 +1,20 @@
+/* { dg-do run } */
+/* { dg-options "-mavx512vl -O2 -std=gnu99" } */
+/* { dg-require-effective-target avx512vl } */
+/* { dg-require-effective-target c99_runtime } */
+
+#define AVX512VL
+#define AVX512F_LEN 512
+#define AVX512F_LEN_HALF 256
+#include "avx512f-vfixupimmsd-2.c"
+
+static void
+test_256 (void)
+{
+  test_512 ();
+}
+
+static void
+test_128 (void)
+{
+}
--- gcc/testsuite/gcc.target/i386/avx512vl-vfixupimmss-2.c  (nonexistent)
+++ gcc/testsuite/gcc.target/i386/avx512vl-vfixupimmss-2.c  (revision 
268010)
@@ -0,0 +1,20 @@
+/* { dg-do run } */
+/* { dg-options "-mavx512vl -O2 -std=gnu99" } */
+/* { dg-require-effective-target avx512vl } */
+/* { dg-require-effective-target c99_runtime } */
+
+#define AVX512VL
+#define AVX512F_LEN 512
+#define AVX512F_LEN_HALF 256
+#include "avx512f-vfixupimmss-2.c"
+
+static void
+test_256 (void)
+{
+  test_512 ();
+}
+
+static void
+test_128 (void)
+{
+}


Jakub


Re: Set inline-unit-growth to 40

2019-01-17 Thread Christophe Lyon
On Mon, 14 Jan 2019 at 17:40, Jan Hubicka  wrote:
>
> Hello,
> > > Index: params.def
> > > ===
> > > --- params.def  (revision 267882)
> > > +++ params.def  (working copy)
> > > @@ -227,7 +227,7 @@ DEFPARAM(PARAM_LARGE_UNIT_INSNS,
> > >  DEFPARAM(PARAM_INLINE_UNIT_GROWTH,
> > >  "inline-unit-growth",
> > >  "How much can given compilation unit grow because of the 
> > > inlining (in percent).",
> > > -20, 0, 0)
> > > +40, 0, 0)
> > >  DEFPARAM(PARAM_IPCP_UNIT_GROWTH,
> > >  "ipcp-unit-growth",
> > >  "How much can given compilation unit grow because of the 
> > > interprocedural constant propagation (in percent).",
> >
> > This patch introduces a regression in libstdc++:
> > FAIL: ext/pb_ds/regression/list_update_map_rand.cc execution test
> > on a few arm targets.
> >
> > For instance:
> > arm-none-linux-gnueabihf
> > --with-mode arm
> > --with-cpu cortex-a5
> > --with-fpu vfpv3-d16-fp16
>
> Adjusting inliner heuiristics should not trigger correcness issues, so
> this seems like a bug that was previously latent.  I guess it may
> legally break correct code only if stack usage gets too large.
>

Indeed I didn't expect such a change to involve correctness issues.


> Do you have any idea what breaks in this testcase?
>

Hmm, I've just seen this test fail then pass again in validations
that did not involve any change related to it.
So there's some "randomness", and the logs are not very helpful
(no message saying memory exhaustion or similar)


> Honza
> >
> > Using --with-mode thumb and the same other configure options makes the
> > test pass.
> > I'm seeing this with other configurations --with-mode arm and
> > --with-fpu vfp* (as opposed to neon*)
> >
> > The .log file has:
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > qemu: uncaught target signal 11 (Segmentation fault) - core 
> > dumped
> >
> > The (incomplete?) qemu execution trace ends with:
> > 
> > IN:
> > 0x40ada6b8:  e5910008  ldr  r0, [r1, #8]
> > 0x40ada6bc:  e156  cmp  r6, r0
> > 0x40ada6c0:  1a4f  bne  #0x40ada804
> > 
> > IN:
> > 0x40ada6c4:  e5960004  ldr  r0, [r6, #4]
> > 0x40ada6c8:  e582100c  str  r1, [r2, #0xc]
> > 0x40ada6cc:  e3500c02  cmp  r0, #0x200
> > 0x40ada6d0:  e5812008  str  r2, [r1, #8]
> > 0x40ada6d4:  3a02  blo  #0x40ada6e4
> > 
> > IN:
> > 0x40adb880:  ea3e  b#0x40adb580
> > 
> > IN: 
> > _ZN10__gnu_pbds4test6detail30container_rand_regression_testINS_11list_updateINS0_10basic_typeES4_St8equal_toIS4_ENS0_26lu_move_to_front_policy_t_EN9__gnu_cxx22throw_allocator_randomIS4_E13subscript_impENSt3tr117integral_constantIiLi0EEE
> > 0x0001ffc4:  e3a06000  mov  r6, #0
> > 0x0001ffc8:  ea88  b#0x1fdf0
> > 
> > IN: 
> > _ZN10__gnu_pbds4test6detail30container_rand_regression_testINS_11list_updateINS0_10basic_typeES4_St8equal_toIS4_ENS0_26lu_move_to_front_policy_t_EN9__gnu_cxx22throw_allocator_randomIS4_E13subscript_impENSt3tr117integral_constantIiLi0EEE
> > 0x0001fdf0:  ee180a10  vmov r0, s16
> > 0x0001fdf4:  ebffcd12  bl   #0x13244
> >
> > Christophe


[PATCH] Improve stack variable reuse with inlining with exceptions (PR tree-optimization/86214)

2019-01-17 Thread Jakub Jelinek
Hi!

As the following testcases show, we are unable to share stack slots
for (large) variables from inline functions if something in those inline
functions can throw externally.

The issue is that the clobbers we have even in the EH paths
are usually removed by ehcleanup1 which attempts to make the functions
smaller before inlining; if the only reason to throw internally and then
rethrow externally are clobber stmts, that is too high cost and so we
optimize them away.

If such functions are inlined into a function that has some EH landing pads
active for the inlined functions though, those EH landing pads are where
the local variables are all considered to conflict between different
inlines, because there is no clobber on that path.

The following patch fixes it by adding clobbers at the start of the EH
landing pad in the inlining function's caller if it was external throw
before and now is internal throw (i.e. when we add an edge from newly added
bb in the inlining to bb in the function from before inlining).

If we throw externally from a function (even if it is inline function), all
local variables in that function are out of scope.

I've bootstrapped/regtested an earlier version of this patch which just had
another basic_block member id->eh_landing_pad_bb used to assert that there
is at most one such landing pad (which survived x86_64-linux and i686-linux
bootstrap/regtest), ok for trunk if this patch passes bootstrap/regtest too?

2019-01-17  Jakub Jelinek  

PR tree-optimization/86214
* tree-inline.h (struct copy_body_data): Add
add_clobbers_to_eh_landing_pads member.
* tree-inline.c (add_clobbers_to_eh_landing_pad): New function.
(copy_edges_for_bb): Call it if EH edge destination is <
id->add_clobbers_to_eh_landing_pads.  Fix a comment typo.
(expand_call_inline): Set id->add_clobbers_to_eh_landing_pads
if flag_stack_reuse != SR_NONE and clear it afterwards.

* g++.dg/opt/pr86214-1.C: New test.
* g++.dg/opt/pr86214-2.C: New test.

--- gcc/tree-inline.h.jj2019-01-17 13:19:56.678539594 +0100
+++ gcc/tree-inline.h   2019-01-17 14:22:56.138496295 +0100
@@ -155,6 +155,12 @@ struct copy_body_data
   /* A list of addressable local variables remapped into the caller
  when inlining a call within an OpenMP SIMD-on-SIMT loop.  */
   vec *dst_simt_vars;
+
+  /* If clobbers for local variables from the inline function
+ that need to live in memory should be added to EH landing pads
+ outside of the inlined function, this should be the number
+ of basic blocks in the caller before inlining.  Zero otherwise.  */
+  int add_clobbers_to_eh_landing_pads;
 };
 
 /* Weights of constructions for estimate_num_insns.  */
--- gcc/tree-inline.c.jj2019-01-17 13:19:56.668539756 +0100
+++ gcc/tree-inline.c   2019-01-17 14:23:42.364746520 +0100
@@ -2190,6 +2190,40 @@ update_ssa_across_abnormal_edges (basic_
   }
 }
 
+/* Insert clobbers for automatic variables of inlined ID->src_fn
+   function at the start of basic block BB.  */
+
+static void
+add_clobbers_to_eh_landing_pad (basic_block bb, copy_body_data *id)
+{
+  tree var;
+  unsigned int i;
+  FOR_EACH_VEC_SAFE_ELT (id->src_cfun->local_decls, i, var)
+if (VAR_P (var)
+   && !DECL_HARD_REGISTER (var)
+   && !TREE_THIS_VOLATILE (var)
+   && !DECL_HAS_VALUE_EXPR_P (var)
+   && !is_gimple_reg (var)
+   && auto_var_in_fn_p (var, id->src_fn))
+  {
+   tree *t = id->decl_map->get (var);
+   if (!t)
+ continue;
+   tree new_var = *t;
+   if (VAR_P (new_var)
+   && !DECL_HARD_REGISTER (new_var)
+   && !TREE_THIS_VOLATILE (new_var)
+   && !DECL_HAS_VALUE_EXPR_P (new_var)
+   && !is_gimple_reg (new_var)
+   && auto_var_in_fn_p (new_var, id->dst_fn))
+ {
+   gimple_stmt_iterator gsi = gsi_after_labels (bb);
+   tree clobber = build_clobber (TREE_TYPE (new_var));
+   gimple *clobber_stmt = gimple_build_assign (new_var, clobber);
+   gsi_insert_before (&gsi, clobber_stmt, GSI_NEW_STMT);
+ }
+  }
+}
 
 /* Copy edges from BB into its copy constructed earlier, scale profile
accordingly.  Edges will be taken care of later.  Assume aux
@@ -2232,7 +2266,7 @@ copy_edges_for_bb (basic_block bb, profi
   if (bb->index == ENTRY_BLOCK || bb->index == EXIT_BLOCK)
 return false;
 
-  /* When doing function splitting, we must decreate count of the return block
+  /* When doing function splitting, we must decrease count of the return block
  which was previously reachable by block we did not copy.  */
   if (single_succ_p (bb) && single_succ_edge (bb)->dest->index == EXIT_BLOCK)
 FOR_EACH_EDGE (old_edge, ei, bb->preds)
@@ -2317,8 +2351,16 @@ copy_edges_for_bb (basic_block bb, profi
  e->probability = old_edge->probability;

   FOR_EACH_EDGE (e, ei, copy_stmt_bb->succs)
-   if ((e->flags & 

[PATCH] Fix arm_neon.h #pragma GCC target syntax (PR target/88734)

2019-01-17 Thread Jakub Jelinek
Hi!

arm_neon.h on both targets contained a couple of spots with invalid
#pragma GCC target syntax.  This doesn't result in errors, just warnings and
those warnings are surpressed in system headers, so are visible with
-Wsystem-headers only.  Anyway, the end result was that these pragmas were
ignored, when they meant to be there.

The following patch fixes it.  Also, on aarch64 the sha3 intrinsics were
wrapped with arch=armv8.2-a+crypto rather than arch=armv8.2-a+sha3, but
because of the invalid syntax it wasn't covered in the testsuite.

Without the patch, besides -Wsystem-headers warnings on it, if somebody
attempts to use those intrinsics in code compiled with target options that
do not include the necessary ISA features, one will get ICEs rather than
errors.

Bootstrapped/regtested on aarch64-linux, ok for trunk?

Note, I haven't included a testcase, as I'm not familiar enough with
gcc.target/aarch64/ test style, but a test would be roughly include the
testcase from the PR, compile it with -march=something that doesn't include
the needed ISA options, probably have a dg-skip-if if somebody overrides it
from the --target_board and make sure it emits a dg-error message rather
than ICE.

2019-01-17  Jakub Jelinek  

PR target/88734
* config/arm/arm_neon.h: Fix #pragma GCC target syntax - replace
(("..."))) with ("...").
* config/aarch64/arm_neon.h: Likewise.  Use arch=armv8.2-a+sha3
instead of arch=armv8.2-a+crypto for vsha512hq_u64 etc. intrinsics.

--- gcc/config/arm/arm_neon.h.jj2019-01-10 11:43:20.100283845 +0100
+++ gcc/config/arm/arm_neon.h   2019-01-16 17:28:32.830228005 +0100
@@ -18310,12 +18310,12 @@ vfmlsl_laneq_high_u32 (float32x2_t __r,
 /* AdvSIMD Complex numbers intrinsics.  */
 #if __ARM_ARCH >= 8
 #pragma GCC push_options
-#pragma GCC target(("arch=armv8.3-a"))
+#pragma GCC target ("arch=armv8.3-a")
 
 
 #if defined (__ARM_FP16_FORMAT_IEEE) || defined (__ARM_FP16_FORMAT_ALTERNATIVE)
 #pragma GCC push_options
-#pragma GCC target(("+fp16"))
+#pragma GCC target ("+fp16")
 __extension__ extern __inline float16x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 vcadd_rot90_f16 (float16x4_t __a, float16x4_t __b)
--- gcc/config/aarch64/arm_neon.h.jj2019-01-10 11:43:18.620308158 +0100
+++ gcc/config/aarch64/arm_neon.h   2019-01-16 17:27:30.170252504 +0100
@@ -33070,7 +33070,7 @@ vdotq_laneq_s32 (int32x4_t __r, int8x16_
 #pragma GCC pop_options
 
 #pragma GCC push_options
-#pragma GCC target(("arch=armv8.2-a+sm4"))
+#pragma GCC target ("arch=armv8.2-a+sm4")
 
 __extension__ extern __inline uint32x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
@@ -33137,7 +33137,7 @@ vsm4ekeyq_u32 (uint32x4_t __a, uint32x4_
 #pragma GCC pop_options
 
 #pragma GCC push_options
-#pragma GCC target(("arch=armv8.2-a+crypto"))
+#pragma GCC target ("arch=armv8.2-a+sha3")
 
 __extension__ extern __inline uint64x2_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
@@ -33299,10 +33299,10 @@ vbcaxq_s64 (int64x2_t __a, int64x2_t __b
 /* AdvSIMD Complex numbers intrinsics.  */
 
 #pragma GCC push_options
-#pragma GCC target(("arch=armv8.3-a"))
+#pragma GCC target ("arch=armv8.3-a")
 
 #pragma GCC push_options
-#pragma GCC target(("+fp16"))
+#pragma GCC target ("+fp16")
 __extension__ extern __inline float16x4_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
 vcadd_rot90_f16 (float16x4_t __a, float16x4_t __b)
@@ -33773,7 +33773,7 @@ vcmlaq_rot270_laneq_f32 (float32x4_t __r
 #pragma GCC pop_options
 
 #pragma GCC push_options
-#pragma GCC target(("arch=armv8.2-a+fp16fml"))
+#pragma GCC target ("arch=armv8.2-a+fp16fml")
 
 __extension__ extern __inline float32x2_t
 __attribute__ ((__always_inline__, __gnu_inline__, __artificial__))

Jakub


Re: [PATCH 9/9] [libbacktrace] Add printdwarftest_dwz_cmp.sh test-case

2019-01-17 Thread Tom de Vries
Hi,

now that the rest of the patch series has been committed, here's an
updated version of this patch that applies to trunk.

Thanks,
- Tom
[libbacktrace] Add printdwarftest_dwz_cmp.sh test-case

Add test-case that verifies that libbacktrace can find the same debug
information with and without dwz compression.

2018-12-10  Tom de Vries  

	* Makefile.am (TESTS): Add printdwarftest_dwz_cmp.sh.
	* Makefile.in: Regenerate.
	* printdwarftest.c: New file.
	* printdwarftest_dwz_cmp.sh: New file.

---
 libbacktrace/Makefile.am   |  11 ++
 libbacktrace/Makefile.in   |  71 +++---
 libbacktrace/printdwarftest.c  | 241 +
 libbacktrace/printdwarftest_dwz_cmp.sh |   8 ++
 4 files changed, 313 insertions(+), 18 deletions(-)

diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index bf90ebdb2d5..61dfca6256e 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -190,6 +190,17 @@ if HAVE_DWZ
 
 TESTS += btest_dwz
 
+printdwarftest.lo: dwarf.c
+
+printdwarftest_SOURCES = printdwarftest.c testlib.c
+printdwarftest_LDADD = libbacktrace.la
+
+check_PROGRAMS += printdwarftest
+
+printdwarftest_dwz_cmp.sh: printdwarftest_dwz
+
+TESTS += printdwarftest_dwz_cmp.sh
+
 endif HAVE_DWZ
 
 stest_SOURCES = stest.c
diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index d55e0501171..06edf592f34 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -120,18 +120,22 @@ POST_UNINSTALL = :
 build_triplet = @build@
 host_triplet = @host@
 target_triplet = @target@
-check_PROGRAMS = $(am__EXEEXT_1) $(am__EXEEXT_2) $(am__EXEEXT_3)
+check_PROGRAMS = $(am__EXEEXT_1) $(am__EXEEXT_2) $(am__EXEEXT_3) \
+	$(am__EXEEXT_4) $(am__EXEEXT_5)
 @NATIVE_TRUE@am__append_1 = test_elf test_xcoff_32 test_xcoff_64 \
 @NATIVE_TRUE@	test_pecoff test_unknown unittest unittest_alloc \
-@NATIVE_TRUE@	allocfail btest btest_alloc stest stest_alloc \
-@NATIVE_TRUE@	ztest ztest_alloc edtest edtest_alloc
+@NATIVE_TRUE@	allocfail btest btest_alloc
 @NATIVE_TRUE@am__append_2 = allocfail.sh
-@HAVE_DWZ_TRUE@@NATIVE_TRUE@am__append_3 = btest_dwz
-@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_4 = -lz
-@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_5 = -lz
-@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@am__append_6 = ttest ttest_alloc
-@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_7 = dtest
-@HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@am__append_8 = ctestg ctesta \
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@am__append_3 = btest_dwz \
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@	printdwarftest_dwz_cmp.sh
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@am__append_4 = printdwarftest
+@NATIVE_TRUE@am__append_5 = stest stest_alloc ztest ztest_alloc edtest \
+@NATIVE_TRUE@	edtest_alloc
+@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_6 = -lz
+@HAVE_ZLIB_TRUE@@NATIVE_TRUE@am__append_7 = -lz
+@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@am__append_8 = ttest ttest_alloc
+@HAVE_OBJCOPY_DEBUGLINK_TRUE@@NATIVE_TRUE@am__append_9 = dtest
+@HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@am__append_10 = ctestg ctesta \
 @HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@	ctestg_alloc \
 @HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@	ctesta_alloc
 subdir = .
@@ -184,13 +188,14 @@ libbacktrace_noformat_la_OBJECTS =  \
 @NATIVE_TRUE@	test_xcoff_64$(EXEEXT) test_pecoff$(EXEEXT) \
 @NATIVE_TRUE@	test_unknown$(EXEEXT) unittest$(EXEEXT) \
 @NATIVE_TRUE@	unittest_alloc$(EXEEXT) allocfail$(EXEEXT) \
-@NATIVE_TRUE@	btest$(EXEEXT) btest_alloc$(EXEEXT) \
-@NATIVE_TRUE@	stest$(EXEEXT) stest_alloc$(EXEEXT) \
+@NATIVE_TRUE@	btest$(EXEEXT) btest_alloc$(EXEEXT)
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@am__EXEEXT_2 = printdwarftest$(EXEEXT)
+@NATIVE_TRUE@am__EXEEXT_3 = stest$(EXEEXT) stest_alloc$(EXEEXT) \
 @NATIVE_TRUE@	ztest$(EXEEXT) ztest_alloc$(EXEEXT) \
 @NATIVE_TRUE@	edtest$(EXEEXT) edtest_alloc$(EXEEXT)
-@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@am__EXEEXT_2 = ttest$(EXEEXT) \
+@HAVE_PTHREAD_TRUE@@NATIVE_TRUE@am__EXEEXT_4 = ttest$(EXEEXT) \
 @HAVE_PTHREAD_TRUE@@NATIVE_TRUE@	ttest_alloc$(EXEEXT)
-@HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@am__EXEEXT_3 =  \
+@HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@am__EXEEXT_5 =  \
 @HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@	ctestg$(EXEEXT) \
 @HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@	ctesta$(EXEEXT) \
 @HAVE_COMPRESSED_DEBUG_TRUE@@NATIVE_TRUE@	ctestg_alloc$(EXEEXT) \
@@ -258,6 +263,12 @@ edtest_OBJECTS = $(am_edtest_OBJECTS)
 @NATIVE_TRUE@am_edtest_alloc_OBJECTS = $(am__objects_5)
 edtest_alloc_OBJECTS = $(am_edtest_alloc_OBJECTS)
 @NATIVE_TRUE@edtest_alloc_DEPENDENCIES = libbacktrace_alloc.la
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@am_printdwarftest_OBJECTS =  \
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@	printdwarftest.$(OBJEXT) \
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@	testlib.$(OBJEXT)
+printdwarftest_OBJECTS = $(am_printdwarftest_OBJECTS)
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@printdwarftest_DEPENDENCIES =  \
+@HAVE_DWZ_TRUE@@NATIVE_TRUE@	libbacktrace.la
 @NATIVE_TRUE@am_stest_OBJECTS = stest.$(OBJEXT)
 stest_OBJECTS = $(am_stest_OBJECTS)
 @NATIVE_TRUE@stest_DEPENDENCIES = libbacktrace.la
@@ -373,8 +384,8 @@ SOURCES = 

Re: [PATCH] Improve stack variable reuse with inlining with exceptions (PR tree-optimization/86214)

2019-01-17 Thread Richard Biener
On Thu, 17 Jan 2019, Jakub Jelinek wrote:

> Hi!
> 
> As the following testcases show, we are unable to share stack slots
> for (large) variables from inline functions if something in those inline
> functions can throw externally.
> 
> The issue is that the clobbers we have even in the EH paths
> are usually removed by ehcleanup1 which attempts to make the functions
> smaller before inlining; if the only reason to throw internally and then
> rethrow externally are clobber stmts, that is too high cost and so we
> optimize them away.
> 
> If such functions are inlined into a function that has some EH landing pads
> active for the inlined functions though, those EH landing pads are where
> the local variables are all considered to conflict between different
> inlines, because there is no clobber on that path.
> 
> The following patch fixes it by adding clobbers at the start of the EH
> landing pad in the inlining function's caller if it was external throw
> before and now is internal throw (i.e. when we add an edge from newly added
> bb in the inlining to bb in the function from before inlining).
> 
> If we throw externally from a function (even if it is inline function), all
> local variables in that function are out of scope.
> 
> I've bootstrapped/regtested an earlier version of this patch which just had
> another basic_block member id->eh_landing_pad_bb used to assert that there
> is at most one such landing pad (which survived x86_64-linux and i686-linux
> bootstrap/regtest), ok for trunk if this patch passes bootstrap/regtest too?
> 
> 2019-01-17  Jakub Jelinek  
> 
>   PR tree-optimization/86214
>   * tree-inline.h (struct copy_body_data): Add
>   add_clobbers_to_eh_landing_pads member.
>   * tree-inline.c (add_clobbers_to_eh_landing_pad): New function.
>   (copy_edges_for_bb): Call it if EH edge destination is <
>   id->add_clobbers_to_eh_landing_pads.  Fix a comment typo.
>   (expand_call_inline): Set id->add_clobbers_to_eh_landing_pads
>   if flag_stack_reuse != SR_NONE and clear it afterwards.
> 
>   * g++.dg/opt/pr86214-1.C: New test.
>   * g++.dg/opt/pr86214-2.C: New test.
> 
> --- gcc/tree-inline.h.jj  2019-01-17 13:19:56.678539594 +0100
> +++ gcc/tree-inline.h 2019-01-17 14:22:56.138496295 +0100
> @@ -155,6 +155,12 @@ struct copy_body_data
>/* A list of addressable local variables remapped into the caller
>   when inlining a call within an OpenMP SIMD-on-SIMT loop.  */
>vec *dst_simt_vars;
> +
> +  /* If clobbers for local variables from the inline function
> + that need to live in memory should be added to EH landing pads
> + outside of the inlined function, this should be the number
> + of basic blocks in the caller before inlining.  Zero otherwise.  */
> +  int add_clobbers_to_eh_landing_pads;
>  };
>  
>  /* Weights of constructions for estimate_num_insns.  */
> --- gcc/tree-inline.c.jj  2019-01-17 13:19:56.668539756 +0100
> +++ gcc/tree-inline.c 2019-01-17 14:23:42.364746520 +0100
> @@ -2190,6 +2190,40 @@ update_ssa_across_abnormal_edges (basic_
>}
>  }
>  
> +/* Insert clobbers for automatic variables of inlined ID->src_fn
> +   function at the start of basic block BB.  */
> +
> +static void
> +add_clobbers_to_eh_landing_pad (basic_block bb, copy_body_data *id)
> +{
> +  tree var;
> +  unsigned int i;
> +  FOR_EACH_VEC_SAFE_ELT (id->src_cfun->local_decls, i, var)
> +if (VAR_P (var)
> + && !DECL_HARD_REGISTER (var)
> + && !TREE_THIS_VOLATILE (var)
> + && !DECL_HAS_VALUE_EXPR_P (var)
> + && !is_gimple_reg (var)
> + && auto_var_in_fn_p (var, id->src_fn))
> +  {
> + tree *t = id->decl_map->get (var);
> + if (!t)
> +   continue;
> + tree new_var = *t;
> + if (VAR_P (new_var)
> + && !DECL_HARD_REGISTER (new_var)
> + && !TREE_THIS_VOLATILE (new_var)
> + && !DECL_HAS_VALUE_EXPR_P (new_var)
> + && !is_gimple_reg (new_var)
> + && auto_var_in_fn_p (new_var, id->dst_fn))
> +   {
> + gimple_stmt_iterator gsi = gsi_after_labels (bb);
> + tree clobber = build_clobber (TREE_TYPE (new_var));
> + gimple *clobber_stmt = gimple_build_assign (new_var, clobber);
> + gsi_insert_before (&gsi, clobber_stmt, GSI_NEW_STMT);
> +   }
> +  }

So we do not care to optimize this to only clobber the vars that
are appear live over the EH edge?

> +}
>  
>  /* Copy edges from BB into its copy constructed earlier, scale profile
> accordingly.  Edges will be taken care of later.  Assume aux
> @@ -2232,7 +2266,7 @@ copy_edges_for_bb (basic_block bb, profi
>if (bb->index == ENTRY_BLOCK || bb->index == EXIT_BLOCK)
>  return false;
>  
> -  /* When doing function splitting, we must decreate count of the return 
> block
> +  /* When doing function splitting, we must decrease count of the return 
> block
>   which was previously reachable by block we did not copy.  */
>if (single_succ_p (bb) && single_s

Re: [PATCH 7/9] [libbacktrace] Handle DW_FORM_GNU_ref_alt

2019-01-17 Thread Tom de Vries
On 17-01-19 01:35, Ian Lance Taylor wrote:
> On Wed, Jan 16, 2019 at 4:17 PM Tom de Vries  wrote:
>>
>> this handles DW_FORM_GNU_ref_alt which references the .debug_info
>> section in the .gnu_debugaltlink file.
>>
>> OK for trunk?
>>
>> Thanks,
>> - Tom
>>
>> On 11-12-18 11:14, Tom de Vries wrote:
>>> 2018-12-10  Tom de Vries  
>>>
>>>   * dwarf.c (enum attr_val_encoding): Add ATTR_VAL_REF_ALT_INFO.
>>>   (struct unit): Add low and high fields.
>>>   (struct unit_vector): New type.
>>>   (struct dwarf_data): Add units and units_counts fields.
>>>   (read_attribute): Handle DW_FORM_GNU_ref_alt using
>>>   ATTR_VAL_REF_ALT_INFO.
>>>   (find_unit): New function.
>>>   (find_address_ranges): Add and handle unit_tag parameter.
>>>   (build_address_map): Add and handle units_vec parameter.
>>>   (read_referenced_name_1): Handle DW_FORM_GNU_ref_alt.
>>>   (build_dwarf_data): Pass units_vec to build_address_map.  Store 
>>> resulting
>>>   units vector.
> 
> 
>>> @@ -281,6 +283,10 @@ struct unit
>>>/* The offset of UNIT_DATA from the start of the information for
>>>   this compilation unit.  */
>>>size_t unit_data_offset;
>>> +  /* Start of the compilation unit.  */
>>> +  size_t low;
>>> +  /* End of the compilation unit.  */
>>> +  size_t high;
> 
> The comments should say what low and high are measured in, which I
> guess is file offset.  Or is it offset from the start of UNIT_DATA?
> Either way, If that is right, then the fields should be named
> low_offset and high_offset.  Otherwise it seems easy to confuse with
> function_addrs, where low and high refer to PC values.
> 

Done.

> Also if they are offsets from UNIT_DATA then size_t is OK, but if the
> are file offsets they should be off_t.
> 

AFAIU, in the case where off_t vs size_t would make a difference, we're
running into trouble much earlier.  I've filed PR 88890 - "libbacktrace
on 32-bit system with _FILE_OFFSET_BITS == 64" (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88890 ) about this.

Anyway, I've made the conservative choice of using off_t for now (but I
could argue that it's a memory offset, given that the assumption is that
the entire debug section is read into memory).

>>> @@ -2144,6 +2198,22 @@ read_referenced_name_1 (struct dwarf_data *ddata, 
>>> struct unit *u,
>>>|| val->encoding == ATTR_VAL_REF_UNIT)
>>>  return read_referenced_name (ddata, u, val->u.uint, error_callback, 
>>> data);
>>>
>>> +  if (val->encoding == ATTR_VAL_REF_ALT_INFO)
>>> +{
>>> +  struct unit *alt_unit
>>> + = find_unit (ddata->altlink->units, ddata->altlink->units_count,
>>> +  val->u.uint);
>>> +  if (alt_unit == NULL)
>>> + {
>>> +   error_callback (data,
>>> +   "Could not find unit for DW_FORM_GNU_ref_alt", 0);
> 
> s/Could/could/
> 
> or maybe just skip this error_callback call as discussed earlier.
> 
> 

Skipped.

>>> +   return NULL;
>>> + }
>>> +  uint64_t unit_offset = val->u.uint - alt_unit->low;
> 
> Earlier a unit_offset was the offset of the unit within unit_data, but
> here this is an offset within a single unit.  This should just be
> called offset, which is the name used by read_referenced_name.
> 

Done.

> This is OK with those changes.

Committed in two parts.

First part ...


[libbacktrace] Add find_unit

Add a function that finds the unit given an offset into .debug_info.

2018-12-10  Tom de Vries  

	* dwarf.c (struct unit): Add low_offset and high_offset fields.
	(struct unit_vector): New type.
	(struct dwarf_data): Add units and units_counts fields.
	(find_unit): New function.
	(find_address_ranges): Add and handle unit_tag parameter.
	(build_address_map): Add and handle units_vec parameter.
	(build_dwarf_data): Pass units_vec to build_address_map.  Store resulting
	units vector.

---
 libbacktrace/dwarf.c | 87 +---
 1 file changed, 76 insertions(+), 11 deletions(-)

diff --git a/libbacktrace/dwarf.c b/libbacktrace/dwarf.c
index 45691b4ba69..6f56c46774b 100644
--- a/libbacktrace/dwarf.c
+++ b/libbacktrace/dwarf.c
@@ -281,6 +281,12 @@ struct unit
   /* The offset of UNIT_DATA from the start of the information for
  this compilation unit.  */
   size_t unit_data_offset;
+  /* Offset of the start of the compilation unit from the start of the
+ .debug_info section.  */
+  off_t low_offset;
+  /* Offset of the end of the compilation unit from the start of the
+ .debug_info section.  */
+  off_t high_offset;
   /* DWARF version.  */
   int version;
   /* Whether unit is DWARF64.  */
@@ -339,6 +345,14 @@ struct unit_addrs_vector
   size_t count;
 };
 
+/* A growable vector of compilation unit pointer.  */
+
+struct unit_vector
+{
+  struct backtrace_vector vec;
+  size_t count;
+};
+
 /* The information we need to map a PC to a file and line.  */
 
 struct dwarf_data
@@ -353,6 +367,10 @@ struct dwarf_data
   struct unit_addrs *addrs;
   /* Num

Re: [PATCH 7/9] [libbacktrace] Handle DW_FORM_GNU_ref_alt

2019-01-17 Thread Tom de Vries
On 17-01-19 15:14, Tom de Vries wrote:
> On 17-01-19 01:35, Ian Lance Taylor wrote:
>> On Wed, Jan 16, 2019 at 4:17 PM Tom de Vries  wrote:
>>>
>>> this handles DW_FORM_GNU_ref_alt which references the .debug_info
>>> section in the .gnu_debugaltlink file.
>>>
>>> OK for trunk?
>>>
>>> Thanks,
>>> - Tom
>>>
>>> On 11-12-18 11:14, Tom de Vries wrote:
 2018-12-10  Tom de Vries  

   * dwarf.c (enum attr_val_encoding): Add ATTR_VAL_REF_ALT_INFO.
   (struct unit): Add low and high fields.
   (struct unit_vector): New type.
   (struct dwarf_data): Add units and units_counts fields.
   (read_attribute): Handle DW_FORM_GNU_ref_alt using
   ATTR_VAL_REF_ALT_INFO.
   (find_unit): New function.
   (find_address_ranges): Add and handle unit_tag parameter.
   (build_address_map): Add and handle units_vec parameter.
   (read_referenced_name_1): Handle DW_FORM_GNU_ref_alt.
   (build_dwarf_data): Pass units_vec to build_address_map.  Store 
 resulting
   units vector.
>>
>>
 @@ -281,6 +283,10 @@ struct unit
/* The offset of UNIT_DATA from the start of the information for
   this compilation unit.  */
size_t unit_data_offset;
 +  /* Start of the compilation unit.  */
 +  size_t low;
 +  /* End of the compilation unit.  */
 +  size_t high;
>>
>> The comments should say what low and high are measured in, which I
>> guess is file offset.  Or is it offset from the start of UNIT_DATA?
>> Either way, If that is right, then the fields should be named
>> low_offset and high_offset.  Otherwise it seems easy to confuse with
>> function_addrs, where low and high refer to PC values.
>>
> 
> Done.
> 
>> Also if they are offsets from UNIT_DATA then size_t is OK, but if the
>> are file offsets they should be off_t.
>>
> 
> AFAIU, in the case where off_t vs size_t would make a difference, we're
> running into trouble much earlier.  I've filed PR 88890 - "libbacktrace
> on 32-bit system with _FILE_OFFSET_BITS == 64" (
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88890 ) about this.
> 
> Anyway, I've made the conservative choice of using off_t for now (but I
> could argue that it's a memory offset, given that the assumption is that
> the entire debug section is read into memory).
> 
 @@ -2144,6 +2198,22 @@ read_referenced_name_1 (struct dwarf_data *ddata, 
 struct unit *u,
|| val->encoding == ATTR_VAL_REF_UNIT)
  return read_referenced_name (ddata, u, val->u.uint, error_callback, 
 data);

 +  if (val->encoding == ATTR_VAL_REF_ALT_INFO)
 +{
 +  struct unit *alt_unit
 + = find_unit (ddata->altlink->units, ddata->altlink->units_count,
 +  val->u.uint);
 +  if (alt_unit == NULL)
 + {
 +   error_callback (data,
 +   "Could not find unit for DW_FORM_GNU_ref_alt", 0);
>>
>> s/Could/could/
>>
>> or maybe just skip this error_callback call as discussed earlier.
>>
>>
> 
> Skipped.
> 
 +   return NULL;
 + }
 +  uint64_t unit_offset = val->u.uint - alt_unit->low;
>>
>> Earlier a unit_offset was the offset of the unit within unit_data, but
>> here this is an offset within a single unit.  This should just be
>> called offset, which is the name used by read_referenced_name.
>>
> 
> Done.
> 
>> This is OK with those changes.
> 
> Committed in two parts.
> 
> First part ...
> 

And second part.

Thanks,
- Tom



[libbacktrace] Handle DW_FORM_GNU_ref_alt

Handle DW_FORM_GNU_ref_alt which references the .debug_info section in the
.gnu_debugaltlink file.

2018-12-10  Tom de Vries  

	PR libbacktrace/82857
	* dwarf.c (enum attr_val_encoding): Add ATTR_VAL_REF_ALT_INFO.
	(read_attribute): Handle DW_FORM_GNU_ref_alt using
	ATTR_VAL_REF_ALT_INFO.
	(read_referenced_name_from_attr): Handle DW_FORM_GNU_ref_alt.

---
 libbacktrace/dwarf.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/libbacktrace/dwarf.c b/libbacktrace/dwarf.c
index 6f56c46774b..aacbd3a453d 100644
--- a/libbacktrace/dwarf.c
+++ b/libbacktrace/dwarf.c
@@ -143,6 +143,8 @@ enum attr_val_encoding
   ATTR_VAL_REF_UNIT,
   /* An offset to other data within the .dwarf_info section.  */
   ATTR_VAL_REF_INFO,
+  /* An offset to other data within the alt .dwarf_info section.  */
+  ATTR_VAL_REF_ALT_INFO,
   /* An offset to data in some other section.  */
   ATTR_VAL_REF_SECTION,
   /* A type signature.  */
@@ -858,7 +860,7 @@ read_attribute (enum dwarf_form form, struct dwarf_buf *buf,
 	  val->encoding = ATTR_VAL_NONE;
 	  return 1;
 	}
-  val->encoding = ATTR_VAL_REF_SECTION;
+  val->encoding = ATTR_VAL_REF_ALT_INFO;
   return 1;
 case DW_FORM_GNU_strp_alt:
   {
@@ -2200,6 +2202,19 @@ read_referenced_name_from_attr (struct dwarf_data *ddata, struct unit *u,
   || val->encoding == ATTR_VAL_REF_UNIT)
 return read_referenced_name (ddata, 

Re: [PATCH] [RFC] PR target/52813 and target/11807

2019-01-17 Thread Christophe Lyon
On Fri, 11 Jan 2019 at 23:59, Jeff Law  wrote:
>
> On 1/8/19 5:03 AM, Richard Sandiford wrote:
> > Bernd Edlinger  writes:
> >> On 1/7/19 10:23 AM, Jakub Jelinek wrote:
> >>> On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
>  -  /* Clobbering the STACK POINTER register is an error.  */
>  +  /* Clobbered STACK POINTER register is not saved/restored by GCC,
>  + which is often unexpected by users.  See PR52813.  */
> if (overlaps_hard_reg_set_p (regset, Pmode, STACK_POINTER_REGNUM))
>   {
>  -  error ("Stack Pointer register clobbered by %qs in %", 
>  regname);
>  +  warning (0, "Stack Pointer register clobbered by %qs in %",
>  + regname);
>  +  warning (0, "GCC has always ignored Stack Pointer % 
>  clobbers");
> >>>
> >>> Why do we write Stack Pointer rather than stack pointer?  That is really
> >>> weird.  The second warning would be a note based on the first one, i.e.
> >>> if (warning ()) note ();
> >>> and better have some -W* option to silence the warning.
> >>>
> >>
> >> Yes, thanks for this suggestion.
> >>
> >> Meanwhile I found out, that the stack clobber has only been ignored up to
> >> gcc-5 (at least with lra targets, not really sure about reload targets).
> >> From gcc-6 on, with the exception of PR arm/77904 which was a regression 
> >> due
> >> to the underlying lra change, but fixed later, and back-ported to 
> >> gcc-6.3.0,
> >> this works for all targets I tried so far.
> >>
> >> To me, it starts to look like a rather unique and useful feature, that I 
> >> would
> >> like to keep working.
> >
> > Not sure what you mean by "unique".  But forcing a frame is a bit of
> > a slippery concept.  Force it where?  For the asm only, or the whole
> > function?  This depends on optimisation and hasn't been consistent
> > across GCC versions, since it depends on the shrink-wrapping
> > optimisation.  (There was a similar controversy a while ago about
> > to what extent -fno-omit-frame-pointer should "force a frame".)
> >
> > The effect on the redzone seems like something that should be specified
> > explicitly rather than as an (accidental?) side effect of listing the
> > sp in the clobber list.  Maybe this would be another use for the "asm
> > attributes" proposal.  "noreturn" was another attribute suggested on
> > IRC yesterday.
> >
> > But either way, the general feeling seems to be that going straight to a
> > hard error is too harsh, since there's quite a bit of existing code that
> > has the clobber.  This patch implements the compromise discussed on IRC
> > yesterday of making it a -Wdeprecated warning instead.
> >
> > Tested on x86_64-linux-gnu and aarch64-linux-gnu.  OK to install?
> >
> > Richard
> >
> > Dimitar: sorry the run-around on this patch, and thanks for the
> > submission.  It looks from all the controversy like it was a
> > long-festering PR for a reason. :-/
> >
> >
> > 2019-01-07  Richard Sandiford  
> >
> > gcc/
> >   PR inline-asm/52813
> >   * doc/extend.texi: Document that listing the stack pointer in the
> >   clobber list of an asm is a deprecated feature.
> >   * common.opt (Wdeprecated): Moved from c-family/c.opt.
> >   * cfgexpand.c (asm_clobber_reg_is_valid): Issue a -Wdeprecated
> >   warning instead of an error for clobbers of the stack pointer.
> >   Add a note explaining why.
> >
> > gcc/c-family/
> >   PR inline-asm/52813
> >   * c.opt (Wdeprecated): Move documentation and variable to common.opt.
> >
> > gcc/d/
> >   PR inline-asm/52813
> >   * lang.opt (Wdeprecated): Reference common.opt instead of c.opt.
> >
> > gcc/testsuite/
> >   PR inline-asm/52813
> >   * gcc.target/i386/pr52813.c (test1): Turn the diagnostic into a
> >   -Wdeprecated warning and expect a following note:.
> OK.
>
> FWIW the number of packages affected in Fedora was in single digits,
> some of which have already been fixed.
>
> But if folks want to go with a deprecated warning instead of straight to
> an error, I won't complain.
>
> jeff


Hi,

I originally complained because the arm test for pr77904.c was failing.
Since Richard's change that test emits a warning rather than an error,
but still fails. This small patch adds the missing dg-warning.

OK?

Thanks,

Christophe
2019-01-17  Christophe Lyon  

* gcc.target/arm/pr77904.c: Add dg-warning for sp clobber.

diff --git a/gcc/testsuite/gcc.target/arm/pr77904.c 
b/gcc/testsuite/gcc.target/arm/pr77904.c
index 76728c0..f279ec8 100644
--- a/gcc/testsuite/gcc.target/arm/pr77904.c
+++ b/gcc/testsuite/gcc.target/arm/pr77904.c
@@ -4,7 +4,8 @@
 __attribute__ ((noinline, noclone)) void
 clobber_sp (void)
 {
-  __asm volatile ("" : : : "sp");
+  __asm volatile ("" : : : "sp"); /* { dg-warning "listing the stack pointer 
register 'sp' in a clobber list is deprecated" } */
+
 }
 
 int


Re: [PATCH] PR target/85596 Add --with-multilib-list doc for aarch64

2019-01-17 Thread Christophe Lyon
Ping? I think that kind of patch is OK for stage4?

On Mon, 7 Jan 2019 at 16:07, Christophe Lyon  wrote:
>
> Hi,
>
> This small patch adds a short description of --with-multilib-list for aarch64.
> OK?
>
> Thanks,
>
> Christophe


Re: [PATCH] Improve stack variable reuse with inlining with exceptions (PR tree-optimization/86214)

2019-01-17 Thread Jakub Jelinek
On Thu, Jan 17, 2019 at 03:06:57PM +0100, Richard Biener wrote:
> > +   tree new_var = *t;
> > +   if (VAR_P (new_var)
> > +   && !DECL_HARD_REGISTER (new_var)
> > +   && !TREE_THIS_VOLATILE (new_var)
> > +   && !DECL_HAS_VALUE_EXPR_P (new_var)
> > +   && !is_gimple_reg (new_var)
> > +   && auto_var_in_fn_p (new_var, id->dst_fn))
> > + {
> > +   gimple_stmt_iterator gsi = gsi_after_labels (bb);
> > +   tree clobber = build_clobber (TREE_TYPE (new_var));
> > +   gimple *clobber_stmt = gimple_build_assign (new_var, clobber);
> > +   gsi_insert_before (&gsi, clobber_stmt, GSI_NEW_STMT);
> > + }
> > +  }
> 
> So we do not care to optimize this to only clobber the vars that
> are appear live over the EH edge?

Wouldn't that be quite expensive (especially at that spot in the inliner)?
I could surely defer that (at the spot in copy_edges_for_bb just remember
which bb was it and handle it before destroying the decl_map in
expand_call_inline, but:
1) are the extra CLOBBERs that big a deal?
2) if they are, shouldn't we have a pass that does it generically after IPA
   and removes all CLOBBERs for vars already known dead, whether they come
   from inlining or whatever else (we have many in the IL already that are
   dead for other reasons, e.g. a variable where the destructor is inlined
   and has one CLOBBER in itself, but have another CLOBBER in the caller too
   when the var goes out of scope); tree DSE is able to remove CLOBBERs for
   the same var if they are adjacent; in either case, what would be the
   algorithm for that?  Something like add_scope_conflicts algorithm, just
   not build any conflicts, but just propagate the var is live bitmaps
   and when the propagation terminates, go through all bbs and if it sees
   a clobber on a var that isn't live at that point, remove the clobber?

> > @@ -2317,8 +2351,16 @@ copy_edges_for_bb (basic_block bb, profi
> >   e->probability = old_edge->probability;
> > 
> >FOR_EACH_EDGE (e, ei, copy_stmt_bb->succs)
> > -   if ((e->flags & EDGE_EH) && !e->probability.initialized_p ())
> > - e->probability = profile_probability::never ();
> > +   if (e->flags & EDGE_EH)
> > + {
> > +   if (!e->probability.initialized_p ())
> > + e->probability = profile_probability::never ();
> > +   if (e->dest->index < id->add_clobbers_to_eh_landing_pads)
> > + {
> 
> Why don't we need to watch out for EDGE_COUNT (e->dest->preds) != 1?

That is the usual case.

> Is it that we just don't care?

That was the intention, if say the EH pad has 4 predecessors,
3 of them from 3 different inline functions and the last one from something
else, then the alternatives to what the patch does (i.e. have clobbers
for variables from all those 3 inline functions, the EH pad is initially
in the caller, so the vars from those inline functions can't be magically
still live there) would be either do nothing and keep this PR open and
have inlining increase stack sizes much more than it expects to in its
estimations, or split those EH pads, have special EH pad for one inline
function and have that set of clobber there, another one for another etc.
and branch to the same spot.  But that means worse code generation unless we
optimize that away (and, either we optimize that by throwing the CLOBBERs
out and we are back to this PR, or we optimize them by moving all the
CLOBBERs into the same EH pad (essentially sinking the CLOBBERs to the
common fallthru, but that means what this patch does)).

Note, analysis of what variables are dead could be useful e.g. for
tail-merge pass, e.g. on:
int bar (int n);
void baz (char *x, int n);

int
foo (int x, int y)
{
  switch (x)
{
case 1:
  {
char buf[8192];
baz (buf, 4);
if (y != 5)
  return 4;
bar (2);
bar (3);
bar (4);
bar (5);
bar (6);
bar (7);
bar (9);
break;
  }
case 2:
  {
char buf[8192];
baz (buf, 124);
if (y != 7)
  return 19;
bar (2);
break;
  }
case 3:
  {
char buf[8192];
baz (buf, 51);
if (y != 19)
  return 26;
bar (2);
bar (3);
bar (4);
bar (5);
bar (6);
bar (7);
bar (9);
break;
  }
default:
  {
char buf[8192];
baz (buf, 18);
if (y != 21)
  return 28;
bar (2);
bar (3);
bar (4);
bar (5);
bar (6);
bar (7);
bar (9);
break;
  }
}
  bar (8);
  return 7;
}

we don't optimize this at -O2, but do with -O2 -fstack-reuse=none when
we don't have the CLOBBERs around.  If tail-merge pass could run this
analysis and find out that while the basic blocks under consideration have
different sets of clobbers, the vars from clobbers from the other sets are dead
in 

Re: [PATCH] c-family: Update unaligned adress of packed member check

2019-01-17 Thread H.J. Lu
On Wed, Jan 16, 2019 at 3:09 PM Jakub Jelinek  wrote:
>
> On Mon, Jan 14, 2019 at 03:23:07PM -0800, H.J. Lu wrote:
> > There are no regressions with this patch:
> >
> > https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00792.html
>
> As the patch seems to be a step forward and fixes an important regression,
> the patch is ok for trunk, but I'd like to keep discussions on the convert_p
> stuff afterwards (see other mail).
>

I posted an updated patch:

https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00982.html


-- 
H.J.


[PATCH][GCC][Arm] Rewrite arm testcase to use intrinsics

2019-01-17 Thread Tamar Christina
Hi All,

This test was added back when builtins were being used instead of ACLE
intrinsics.  The test as far as I can tell is really testing vcombine,
however some of these builtins no longer exist and causes an ICE.

This fixes the testcase by changing it to use neon intrinsics.

Regtested on arm-none-eabi and no issues.

Ok for trunk?

Thanks,
Tamar

gcc/testsuite/ChangeLog:

2019-01-17  Tamar Christina  

PR target/88850
* gcc.target/arm/pr51968.c: Use neon intrinsics.

-- 
diff --git a/gcc/testsuite/gcc.target/arm/pr51968.c b/gcc/testsuite/gcc.target/arm/pr51968.c
index 99bdb961757bfa62aec5ef1426137425e57898b0..781470223db0d85214bced0b64fda68b4c43967f 100644
--- a/gcc/testsuite/gcc.target/arm/pr51968.c
+++ b/gcc/testsuite/gcc.target/arm/pr51968.c
@@ -1,14 +1,10 @@
 /* PR target/51968 */
 /* { dg-do compile } */
-/* { dg-options "-O2 -Wno-implicit-function-declaration -march=armv7-a -mfloat-abi=softfp -mfpu=neon" } */
+/* { dg-options "-O2 -march=armv7-a -mfloat-abi=softfp -mfpu=neon" } */
 /* { dg-require-effective-target arm_neon_ok } */
+#include 
 
-typedef __builtin_neon_qi int8x8_t __attribute__ ((__vector_size__ (8)));
-typedef __builtin_neon_uqi uint8x8_t __attribute__ ((__vector_size__ (8)));
-typedef __builtin_neon_qi int8x16_t __attribute__ ((__vector_size__ (16)));
-typedef __builtin_neon_hi int16x8_t __attribute__ ((__vector_size__ (16)));
-typedef __builtin_neon_si int32x4_t __attribute__ ((__vector_size__ (16)));
-struct T { int8x8_t val[2]; };
+struct T { int8x8x2_t val; };
 int y;
 
 void
@@ -17,16 +13,16 @@ foo (int8x8_t z, int8x8_t x, int16x8_t b, int8x8_t n)
   if (y)
 {
   struct T m;
-  __builtin_neon_vuzpv8qi (&m.val[0], z, x);
+  m.val = vuzp_s8 (z, x);
 }
   for (;;)
 {
   int8x16_t g;
   int8x8_t h, j, k;
   struct T m;
-  j = __builtin_neon_vqmovunv8hi (b);
-  g = __builtin_neon_vcombinev8qi (j, h);
-  k = __builtin_neon_vget_lowv16qi (g);
-  __builtin_neon_vuzpv8qi (&m.val[0], k, n);
+  j = vqmovn_s16 (b);
+  g = vcombine_s8 (j, h);
+  k = vget_low_s8 (g);
+  m.val = vuzp_s8 (k, n);
 }
 }



Re: [PATCH,Fortran][RFC] PR 87939, 87326 - STAT= and ERRMSG= specifiers in several image control statements; NEW_INDEX= specifier in FORM TEAM statement

2019-01-17 Thread Nathan Weeks
Hi Steve,

I currently do not, but I will contact appropriate personnel & try to get
one submitted soon.

--
Nathan


On Wed, Jan 16, 2019 at 8:24 PM Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:

> Nathan,
>
> Thanks for taking an interesting in improving gfortran.  A
> scan of the bug database certainly suggests we can use the
> help particularly with coarray bugs.  Before we can go much
> further, do you have a copyright assignment on file the FSF.
> If not, please see https://gcc.gnu.org/contribute.html
>
> --
> steve
>
> On Wed, Jan 16, 2019 at 06:16:12PM -0600, Nathan Weeks wrote:
> > Hi all,
> >
> > To facilitate more complete Fortran 2018 failed images support, I'm
> > particularly interested in interested in seeing PR 87939 eventually
> > resolved (i.e., allow STAT= and ERRMSG= specifiers in FORM TEAM,
> > CHANGE TEAM, SYNC TEAM, END TEAM, and CRITICAL statements). To get the
> > ball rolling (I realize that the boat has been missed for this kind of
> > change in GCC 9 trunk), I've attempted the following patch (which,
> > since it was convenient to do while modifying FORM TEAM-related code,
> > also adds the NEW_INDEX= specifier to the FORM TEAM statement as
> > desired in PR 87326).
> >
> > This is the first gfortran patch I've attempted, and I certainly could
> > have made some noob mistakes, so verbose feedback would be
> > appreciated.
> >
> > A few comments:
> >
> > * In resolve.c, the newly-added functions that type check STAT= and
> > ERRMSG= arguments for FORM TEAM, CHANGE TEAM, and SYNC TEAM also add
> > (previously-absent) type checking for their TEAM_TYPE arguments. If
> > it's more appropriate, I could separate this change into its own PR.
> >
> > * The existing -fcoarray=lib implementation of CRITICAL acquires a
> > LOCK on a lock variable on image 1 (in the current team). However, a
> > CRITICAL statement stat-value of STAT_FAILED_IMAGE (i.e., the image
> > that enter the CRITICAL construct failed) is analogous to the LOCK
> > stat-value of STAT_UNLOCKED_FAILED_IMAGE (i.e., the image that
> > acquired the lock failed---see section 11.6.11 (7 & 10) in Fortran
> > 2018 draft N2146), whereas a LOCK STAT_FAILED_IMAGE means the image on
> > which the lock variable resides has failed (no analog in the CRITICAL
> > statement, which is oblivious to this underlying implementation). So
> > in addition to adding the stat value STAT_UNLOCKED_FAILED_IMAGE to
> > libgfortran.h & libcaf.h, I had CRITICAL swap a LOCK
> > STAT_UNLOCKED_FAILED_IMAGE for STAT_FAILED_IMAGE, and (perhaps
> > unimaginatively) a LOCK STAT_FAILED_IMAGE for
> > STAT_UNLOCKED_FAILED_IMAGE (which, while it has no defined meaning for
> > a CRITICAL statement, fits the definition of a "processor-dependent
> > value other than STAT_FAILED_IMAGE").
> >
> > * A couple negative tests for syntax errors (coarray_critical_2.f90 &
> > team_end_2.f90) fail due to spurious "Error: Expecting END PROGRAM
> > statement at (1)" errors that are also emitted by gfortran 8.2.0 as
> > well.
> >
> > Thanks,
> >
> > --
> > Nathan
> >
> > frontend:
> >
> > 2019-01-16  Nathan Weeks  
> >
> > PR fortran/87939
> > PR fortran/87326
> > * gfortran.h: Add an additional gfc_expr member to struct
> gfc_code.
> > * libcaf.h: Add support for STAT_UNLOCKED_FAILED_IMAGE.
> > * match.c (gfc_match_critical): Add STAT= and ERRMSG=.
> > (gfc_match_change_team): Likewise.
> > (gfc_match_end_team): Likewise.
> > (gfc_match_sync_team): Likewise.
> > (gfc_match_form_team): Add STAT=, ERRMSG=, and NEW_INDEX=.
> > * resolve.c (resolve_form_team): New. Type check team-variable
> > argument in
> > addition to new STAT= and ERRMSG= arguments.
> > (resolve_change_sync_team): New. Adds type checking for
> team-value
> > argument.
> > (resolve_end_team): New.
> > (resolve_critical): Add STAT= and ERRMSG=.
> > * trans-decl.c (gfc_build_builtin_function_decls): Additional
> stat,
> > errmsg, and errmsg_len arguments to _gfortran_caf_form_team(),
> > _gfortran_caf_change_team(), _gfortran_caf_end_team(), and
> > _gfortran_caf_sync_team(), and additional new_index argument to
> > _gfortran_caf_form_team().
> > * trans-stmt.c (gfc_trans_form_team): Support STAT=, ERRMSG=, and
> > NEW_INDEX=.
> > (gfc_trans_change_team): Support STAT= and ERRMSG=.
> > (gfc_trans_end_team): Likewise.
> > (gfc_trans_sync_team): Likewise.
> > (gfc_trans_critical): Likewise. Also support assigning
> STAT_FAILED_IMAGE
> > to a stat-variable.
> >
> > libgfortran:
> >
> > 2019-01-16  Nathan Weeks  
> >
> > PR fortran/87939
> > * libgfortran.h: Add support for STAT_UNLOCKED_FAILED_IMAGE
> >
> > testsuite:
> >
> > 2019-01-16  Nathan Weeks  
> >
> > PR fortran/87939
> > PR fortran/87326
> > * gfortran.dg/coarray_critical_2.f90: New test
> >   

Re: [PATCH][GCC][Arm] Rewrite arm testcase to use intrinsics

2019-01-17 Thread Ramana Radhakrishnan
On 17/01/2019 15:02, Tamar Christina wrote:
> Hi All,
> 
> This test was added back when builtins were being used instead of ACLE
> intrinsics.  The test as far as I can tell is really testing vcombine,
> however some of these builtins no longer exist and causes an ICE.
> 
> This fixes the testcase by changing it to use neon intrinsics.
> 
> Regtested on arm-none-eabi and no issues.
> 
> Ok for trunk?
> 
> Thanks,
> Tamar
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-01-17  Tamar Christina  
> 
>   PR target/88850
>   * gcc.target/arm/pr51968.c: Use neon intrinsics.
> 

Ok.

Looks pretty obvious to me.

Ramana


[PATCH] PR libstdc++/88881 adjust filesystem::status and tests for mingw semantics

2019-01-17 Thread Jonathan Wakely

On Windows stat("foo/bar/../.") will resolve to "foo" even if that is a
non-directory and "foo/bar" does not exist. This is the expected
behaviour and consistent with boost::filesystem, so don't try to correct
it. The only unwanted behaviour is that stat("baz/") fails due to a
mingw bug (fixed in mingw-w64 v6.0.0) so add a workaround.

PR libstdc++/1
* src/c++17/fs_ops.cc (canonical(const path&, error_code&))
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Normalize path, to match behaviour
of filesystem::exists.
(create_directories(const path&, error_code&)): Add assertions.
(status(const path&, error_code&)) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]:
Add workaround for bug in _wstat for paths with trailing slash.
* testsuite/27_io/filesystem/operations/create_directories.cc: Adjust
for expected behaviour on mingw.
* testsuite/experimental/filesystem/operations/create_directories.cc:
Likewise.
* testsuite/27_io/filesystem/operations/temp_directory_path.cc: Use
"TMP" instead of "TMPDIR" and clean environment before each test. Do
not test permissions on mingw targets.

Tested x86_64-linux and x86_64-w64-mingw32, committed to trunk.

commit 812d6bac4fff9ad466d524f911e985cf37a47f4b
Author: Jonathan Wakely 
Date:   Thu Jan 17 11:56:58 2019 +

PR libstdc++/1 adjust filesystem::status and tests for mingw semantics

On Windows stat("foo/bar/../.") will resolve to "foo" even if that is a
non-directory and "foo/bar" does not exist. This is the expected
behaviour and consistent with boost::filesystem, so don't try to correct
it. The only unwanted behaviour is that stat("baz/") fails due to a
mingw bug (fixed in mingw-w64 v6.0.0) so add a workaround.

PR libstdc++/1
* src/c++17/fs_ops.cc (canonical(const path&, error_code&))
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Normalize path, to match behaviour
of filesystem::exists.
(create_directories(const path&, error_code&)): Add assertions.
(status(const path&, error_code&)) [_GLIBCXX_FILESYSTEM_IS_WINDOWS]:
Add workaround for bug in _wstat for paths with trailing slash.
* testsuite/27_io/filesystem/operations/create_directories.cc: 
Adjust
for expected behaviour on mingw.
* 
testsuite/experimental/filesystem/operations/create_directories.cc:
Likewise.
* testsuite/27_io/filesystem/operations/temp_directory_path.cc: Use
"TMP" instead of "TMPDIR" and clean environment before each test. Do
not test permissions on mingw targets.

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 7ece478b62a..5f8be5b7848 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -144,7 +144,11 @@ fs::path
 fs::canonical(const path& p, error_code& ec)
 {
   path result;
+#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  const path pa = absolute(p.lexically_normal(), ec);
+#else
   const path pa = absolute(p, ec);
+#endif
   if (ec)
 return result;
 
@@ -483,6 +487,9 @@ fs::create_directories(const path& p, error_code& ec)
   return false;
 }
 
+  __glibcxx_assert(st.type() == file_type::not_found);
+  // !exists(p) so there must be at least one non-existent component in p.
+
   std::stack missing;
   path pp = p;
 
@@ -526,6 +533,8 @@ fs::create_directories(const path& p, error_code& ec)
 }
   while (st.type() == file_type::not_found);
 
+  __glibcxx_assert(!missing.empty());
+
   bool created;
   do
 {
@@ -1318,8 +1327,35 @@ fs::file_status
 fs::status(const fs::path& p, error_code& ec) noexcept
 {
   file_status status;
+  auto str = p.c_str();
+
+#if _GLIBCXX_FILESYSTEM_IS_WINDOWS
+#if ! defined __MINGW64_VERSION_MAJOR || __MINGW64_VERSION_MAJOR < 6
+  // stat() fails if there's a trailing slash (PR 1)
+  path p2;
+  if (p.has_relative_path())
+{
+  wstring_view s = p.native();
+  const auto len = s.find_last_not_of(L"/\\") + wstring_view::size_type(1);
+  if (len != 0 && len != s.length())
+   {
+ __try
+   {
+ p2.assign(s.substr(0, len));
+   }
+ __catch(const bad_alloc&)
+   {
+ ec = std::make_error_code(std::errc::not_enough_memory);
+ return status;
+   }
+ str = p2.c_str();
+   }
+}
+#endif
+#endif
+
   stat_type st;
-  if (posix::stat(p.c_str(), &st))
+  if (posix::stat(str, &st))
 {
   int err = errno;
   ec.assign(err, std::generic_category());
diff --git 
a/libstdc++-v3/testsuite/27_io/filesystem/operations/create_directories.cc 
b/libstdc++-v3/testsuite/27_io/filesystem/operations/create_directories.cc
index 9ad5ef09f4a..c4411dfc1e7 100644
--- a/libstdc++-v3/testsuite/27_io/filesystem/operations/create_directories.cc
+++ b/libstdc++-v3/testsuite/27_io/filesystem/operations/create

[PATCH] PR libstdc++/88884 fix filesystem::absolute("//") for mingw

2019-01-17 Thread Jonathan Wakely

PR libstdc++/4
* src/c++17/fs_ops.cc (absolute(const path&, error_code&)): Do nothing
if the path is already absolute.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Normalize root-directory.
[!_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Pass error_code to current_path.

Tested x86_64-linux and x86_64-w64-mingw32, committed to trunk.


commit c008f75f5be810a9c6788680b7ee4816ccbaae9c
Author: Jonathan Wakely 
Date:   Thu Jan 17 13:44:47 2019 +

PR libstdc++/4 fix filesystem::absolute("//") for mingw

PR libstdc++/4
* src/c++17/fs_ops.cc (absolute(const path&, error_code&)): Do 
nothing
if the path is already absolute.
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Normalize root-directory.
[!_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Pass error_code to current_path.

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 5f8be5b7848..c4b99fb36ce 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -85,14 +85,35 @@ fs::absolute(const path& p, error_code& ec)
   ec = make_error_code(std::errc::no_such_file_or_directory);
   return ret;
 }
+  ec.clear();
+  if (p.is_absolute())
+{
+  ret = p;
+  return ret;
+}
+
 #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-  const wstring& s = p.native();
+  wstring_view s = p.native();
+
+  if (p.has_root_directory()) // implies !p.has_root_name()
+{
+  // GetFullPathNameW("//") gives unwanted result (PR 4).
+  // If there are multiple directory separators at the start,
+  // skip all but the last of them.
+  const auto pos = s.find_first_not_of(L"/\\");
+  __glibcxx_assert(pos != 0);
+  s.remove_prefix(std::min(s.length(), pos) - 1);
+}
+
+  // s must be null-terminated
+  __glibcxx_assert(!s.empty() && s.back() == 0);
+
   uint32_t len = 1024;
   wstring buf;
   do
 {
   buf.resize(len);
-  len = GetFullPathNameW(s.c_str(), len, buf.data(), nullptr);
+  len = GetFullPathNameW(s.data(), len, buf.data(), nullptr);
 }
   while (len > buf.size());
 
@@ -100,13 +121,11 @@ fs::absolute(const path& p, error_code& ec)
 ec.assign((int)GetLastError(), std::system_category());
   else
 {
-  ec.clear();
   buf.resize(len);
   ret = std::move(buf);
 }
 #else
-  ec.clear();
-  ret = current_path();
+  ret = current_path(ec);
   ret /= p;
 #endif
   return ret;


[PATCH] Fix filesystem::equivalent for mingw

2019-01-17 Thread Jonathan Wakely

* src/c++17/fs_ops.cc
(equivalent(const path&, const path&, error_code&))
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use GetFileInformationByHandle to
compare files instead of relying on incomplete info returned by stat.

Tested x86_64-linux and x86_64-w64-mingw32, committed to trunk.

commit 6c860ebca6e0b486e9b95231e175fb4084ca3f0a
Author: Jonathan Wakely 
Date:   Thu Jan 17 14:18:38 2019 +

Fix filesystem::equivalent for mingw

* src/c++17/fs_ops.cc
(equivalent(const path&, const path&, error_code&))
[_GLIBCXX_FILESYSTEM_IS_WINDOWS]: Use GetFileInformationByHandle to
compare files instead of relying on incomplete info returned by 
stat.

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index c4b99fb36ce..3ff0ded1c66 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -851,7 +851,49 @@ fs::equivalent(const path& p1, const path& p2, error_code& 
ec) noexcept
   ec.clear();
   if (is_other(s1) || is_other(s2))
return false;
+#if _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  // st_ino is not set, so can't be used to distinguish files
+  if (st1.st_mode != st2.st_mode || st1.st_dev != st2.st_dev)
+   return false;
+
+  struct auto_handle {
+   explicit auto_handle(const path& p_)
+   : handle(CreateFileW(p_.c_str(), 0,
+ FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE,
+ 0, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, 0))
+   { }
+
+   ~auto_handle()
+   { if (*this) CloseHandle(handle); }
+
+   explicit operator bool() const
+   { return handle != INVALID_HANDLE_VALUE; }
+
+   bool get_info()
+   { return GetFileInformationByHandle(handle, &info); }
+
+   HANDLE handle;
+   BY_HANDLE_FILE_INFORMATION info;
+  };
+  auto_handle h1(p1);
+  auto_handle h2(p2);
+  if (!h1 || !h2)
+   {
+ if (!h1 && !h2)
+   ec.assign((int)GetLastError(), generic_category());
+ return false;
+   }
+  if (!h1.get_info() || !h2.get_info())
+   {
+ ec.assign((int)GetLastError(), generic_category());
+ return false;
+   }
+  return h1.info.dwVolumeSerialNumber == h2.info.dwVolumeSerialNumber
+   && h1.info.nFileIndexHigh == h2.info.nFileIndexHigh
+   && h1.info.nFileIndexLow == h2.info.nFileIndexLow;
+#else
   return st1.st_dev == st2.st_dev && st1.st_ino == st2.st_ino;
+#endif
 }
   else if (!exists(s1) && !exists(s2))
 ec = std::make_error_code(std::errc::no_such_file_or_directory);


Re: V2 [PATCH] c-family: Update unaligned adress of packed member check

2019-01-17 Thread Jakub Jelinek
On Wed, Jan 16, 2019 at 08:57:25PM -0800, H.J. Lu wrote:
> Check unaligned pointer conversion and strip NOPS.

> -check_address_of_packed_member (tree type, tree rhs)
> +check_address_or_pointer_of_packed_member (tree type, tree rhs)
>  {
>if (INDIRECT_REF_P (rhs))
>  rhs = TREE_OPERAND (rhs, 0);
> @@ -2726,6 +2728,36 @@ check_address_of_packed_member (tree type, tree rhs)
>if (TREE_CODE (rhs) == ADDR_EXPR)
>  rhs = TREE_OPERAND (rhs, 0);
>  
> +  if (!TYPE_P (type) || POINTER_TYPE_P (type))
> +  type = TREE_TYPE (type);

Bad formatting.  Plus, when would you pass around a non-type here?
And, isn't type always a POINTER_TYPE_P here anyway?  If not, whether
you use TREE_TYPE on it or not shouldn't depend on whether it is a pointer,
but on some other conditions, because a field can have pointer type too,
so if you come in through sometimes type being the address of the var and
sometimes the type of its value, the bug is in allowing that.
> +
> +  if (TREE_CODE (rhs) == PARM_DECL || TREE_CODE (rhs) == VAR_DECL)

VAR_P (rhs) instead of TREE_CODE (rhs) == VAR_DECL.  What about RESULT_DECL?

>  static void
> -check_and_warn_address_of_packed_member (tree type, tree rhs)
> +check_and_warn_address_or_pointer_of_packed_member (tree type, tree rhs)
>  {
> +  bool nop_p;
> +
> +  if (TREE_CODE (rhs) == NOP_EXPR)

This should be probably if (CONVERT_EXPR_P (rhs)) or maybe just do
  tree orig_rhs = rhs;
  STRIP_NOPS (rhs);
  nop_p = orig_rhs != rhs;
?

I must say I don't fully understand the nop_p stuff, why you handle
it differently if there were any nops vs. if there were none.
And, e.g. if you have NOP_EXPR around COND_EXPR, that outer nop_p isn't
taken into account.  So, again, what exactly do you want to achieve,
why do you care if there are any conversions in between or not.
Isn't all that matters what the innermost ADDR_EXPR is and what the
outermost type is?

>if (TREE_CODE (rhs) != COND_EXPR)

I think it would be more readable to do:
  if (TREE_CODE (rhs) == COND_EXPR)
{
  recurse;
  recurse;
  return;
}
and handle the remaining code (longer) normally indented below that.

Another thing is, the NOP_EXPRs/CONVERT_EXPRs, COMPOUND_EXPRs and
COND_EXPRs can be arbitrarily nested, while you handle only a subset
of those cases.  You could e.g. move the
  while (TREE_CODE (rhs) == COMPOUND_EXPR)
   rhs = TREE_OPERAND (rhs, 1);

before the if (TREE_CODE (rhs) == COND_EXPR) check and stick another
STRIP_NOPS in between.

> @@ -2795,58 +2862,5 @@ warn_for_address_or_pointer_of_packed_member (bool 
> convert_p, tree type,
>while (TREE_CODE (rhs) == COMPOUND_EXPR)
>  rhs = TREE_OPERAND (rhs, 1);

and then it would be pointless to do this here.

Jakub


[wwwdocs] Mention AMD GCN on the website

2019-01-17 Thread Andrew Stubbs

AMD GCN has now been committed to the trunk.

Is the attached OK for the website? Most of the wording has been 
modelled on the existing C-SKY announcements.


Thanks

Andrew
diff --git a/htdocs/backends.html b/htdocs/backends.html
index bb70aa6..eecd09a 100644
--- a/htdocs/backends.html
+++ b/htdocs/backends.html
@@ -81,6 +81,7 @@ csky   |  b   ia
 epiphany   | C   gi   s
 fr30   | ??FI B  pb mgs
 frv| ??   B   b   i   s
+gcn|   S C D  qa e
 h8300  |   FI B cgs
 i386   |   ? Qq   b   ia
 ia64   |   ? Q   Cqr  b m i
diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index a35d911..f70a39a 100644
--- a/htdocs/gcc-9/changes.html
+++ b/htdocs/gcc-9/changes.html
@@ -216,6 +216,18 @@ a work-in-progress.
   
 
 
+AMD GCN
+
+  
+A new back end targeting AMD GCN GPUs has been contributed to GCC.  The
+following devices are supported (GCC identifiers in parentheses):
+
+  Fiji (fiji).
+  Vega 10 (gfx900).
+
+  
+
+
 ARC
 
   LRA is now on by default for the ARC target.  This can be
diff --git a/htdocs/index.html b/htdocs/index.html
index 181d479..8b39ff3 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -54,6 +54,11 @@ mission statement.
 News
 
 
+AMD GCN support
+[2019-01-17]
+GCC support for AMD GCN Fiji and Vega GPUs has been added.  This back
+  end was contributed by Mentor Graphics.
+
 GCC 7.4 released
 [2018-12-06]
 


Re: [C++ Patch] In grokdeclarator, use typespec_loc in error messages about 'auto' and trailing return type

2019-01-17 Thread Jason Merrill

On 1/17/19 4:59 AM, Paolo Carlini wrote:

Hi,

just use in more places the carefully constructed typespec_loc. Note for 
another time: the 'type name' we print for tests like cpp0x/auto52.C 
doesn't seem particularly clear to me. Tested x86_64-linux, as usual.


OK.

Jason



Re: [wwwdocs] Mention AMD GCN on the website

2019-01-17 Thread Andi Kleen
Andrew Stubbs  writes:
>  
> +AMD GCN
> +
> +  
> +A new back end targeting AMD GCN GPUs has been contributed to GCC.  The
> +following devices are supported (GCC identifiers in parentheses):

Can you add a few words on the current limitations?

-Andi


Re: PATCH: Updated error messages for ill-formed cases of array initialization by string literal

2019-01-17 Thread Jason Merrill

On 1/15/19 12:59 PM, Joseph Myers wrote:

On Tue, 15 Jan 2019, Jason Merrill wrote:


I actually incorporated the C++ part of these changes into yesterday's commit,
using Martin's first suggestion.  Here's the adjusted C patch, which I'd like
a C maintainer to approve.


The front-end changes are OK.  However, in the testcase changes, some of
the new expected diagnostics are hardcoding that "unsigned int" is th
type of char32_t, which isn't correct for all platforms (for example, it's
definitely not the type when int is 16-bit).  In principle the same
applies to diagnostics hardcoding the choice of char16_t, although
variations are at least less likely there.


This updated patch removes {short ,}unsigned int from the expected 
diagnostics.  And also improves error_init to accept additional 
arguments, like pedwarn_init already does.


Tested x86_64-pc-linux-gnu.

Jason
commit 7760281e48c2eee881c44ff255d2fbf72b5461b8
Author: Jason Merrill 
Date:   Wed Jan 9 15:01:53 2019 -0500

Improve the C error for mismatched array string literal initialization.

* c-typeck.c (digest_init): Revised the error message produced for
ill-formed cases of array initialization with a string literal.
(error_init): Make variadic.

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 63d177f7a6f..6da1f321835 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -6339,17 +6339,21 @@ convert_to_anonymous_field (location_t location, tree type, tree rhs)
GMSGID identifies the message.
The component name is taken from the spelling stack.  */
 
-static void
-error_init (location_t loc, const char *gmsgid)
+static void ATTRIBUTE_GCC_DIAG (2,0)
+error_init (location_t loc, const char *gmsgid, ...)
 {
   char *ofwhat;
 
   auto_diagnostic_group d;
 
   /* The gmsgid may be a format string with %< and %>. */
-  error_at (loc, gmsgid);
+  va_list ap;
+  va_start (ap, gmsgid);
+  bool warned = emit_diagnostic_valist (DK_ERROR, loc, -1, gmsgid, &ap);
+  va_end (ap);
+
   ofwhat = print_spelling ((char *) alloca (spelling_length () + 1));
-  if (*ofwhat)
+  if (*ofwhat && warned)
 inform (loc, "(near initialization for %qs)", ofwhat);
 }
 
@@ -7722,6 +7726,7 @@ digest_init (location_t init_loc, tree type, tree init, tree origtype,
 	{
 	  struct c_expr expr;
 	  tree typ2 = TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (inside_init)));
+	  bool incompat_string_cst = false;
 	  expr.value = inside_init;
 	  expr.original_code = (strict_string ? STRING_CST : ERROR_MARK);
 	  expr.original_type = NULL;
@@ -7738,27 +7743,18 @@ digest_init (location_t init_loc, tree type, tree init, tree origtype,
 	  if (char_array)
 	{
 	  if (typ2 != char_type_node)
-		{
-		  error_init (init_loc, "char-array initialized from wide "
-			  "string");
-		  return error_mark_node;
-		}
-	}
-	  else
-	{
-	  if (typ2 == char_type_node)
-		{
-		  error_init (init_loc, "wide character array initialized "
-			  "from non-wide string");
-		  return error_mark_node;
-		}
-	  else if (!comptypes(typ1, typ2))
-		{
-		  error_init (init_loc, "wide character array initialized "
-			  "from incompatible wide string");
-		  return error_mark_node;
-		}
+		incompat_string_cst = true;
 	}
+	  else if (!comptypes (typ1, typ2))
+	incompat_string_cst = true;
+
+  if (incompat_string_cst)
+{
+	  error_init (init_loc, "cannot initialize array of %qT from "
+			  "a string literal with type array of %qT",
+			  typ1, typ2);
+	  return error_mark_node;
+}
 
 	  if (TYPE_DOMAIN (type) != NULL_TREE
 	  && TYPE_SIZE (type) != NULL_TREE
diff --git a/gcc/testsuite/gcc.dg/init-string-2.c b/gcc/testsuite/gcc.dg/init-string-2.c
index 9efd44b3d2f..ded9bf27708 100644
--- a/gcc/testsuite/gcc.dg/init-string-2.c
+++ b/gcc/testsuite/gcc.dg/init-string-2.c
@@ -28,8 +28,8 @@ uchar a8[] = "foo"; /* { dg-error "string constant" "a8" } */
 const schar a9[] = "foo"; /* { dg-error "string constant" "a9" } */
 short a10[] = L"foo"; /* { dg-error "string constant" "a10" } */
 const sshrt a11[] = L"foo"; /* { dg-error "string constant" "a11" } */
-char a12[] = L"foo"; /* { dg-error "from wide string" "a12" } */
-wchar_t a13[] = "foo"; /* { dg-error "non-wide string" "a13" } */
+char a12[] = L"foo"; /* { dg-error "from a string literal with type array of" "a12" } */
+wchar_t a13[] = "foo"; /* { dg-error "from a string literal with type array of .char." "a13" } */
 
 char b0[] = { "foo" };
 const signed char b2[4] = { "foo" };
@@ -43,8 +43,8 @@ uchar b8[] = { "foo" }; /* { dg-error "string constant" "b8" } */
 const schar b9[] = { "foo" }; /* { dg-error "string constant" "b9" } */
 short b10[] = { L"foo" }; /* { dg-error "string constant" "b10" } */
 const sshrt b11[] = { L"foo" }; /* { dg-error "string constant" "b11" } */
-char b12[] = { L"foo" }; /* { dg-error "from wide string" "b12" } */
-wchar_t b13[] = { "foo" }; /* { dg-error "non-wide string" "b13" } */
+char b12[

Re: [wwwdocs] Mention AMD GCN on the website

2019-01-17 Thread Andrew Stubbs

On 17/01/2019 17:39, Andi Kleen wrote:

Can you add a few words on the current limitations?


How's this?

Andrew
diff --git a/htdocs/backends.html b/htdocs/backends.html
index bb70aa6..eecd09a 100644
--- a/htdocs/backends.html
+++ b/htdocs/backends.html
@@ -81,6 +81,7 @@ csky   |  b   ia
 epiphany   | C   gi   s
 fr30   | ??FI B  pb mgs
 frv| ??   B   b   i   s
+gcn|   S C D  qa e
 h8300  |   FI B cgs
 i386   |   ? Qq   b   ia
 ia64   |   ? Q   Cqr  b m i
diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index a35d911..db9ac24 100644
--- a/htdocs/gcc-9/changes.html
+++ b/htdocs/gcc-9/changes.html
@@ -216,6 +216,21 @@ a work-in-progress.
   
 
 
+AMD GCN
+
+  
+A new back end targeting AMD GCN GPUs has been contributed to GCC.  The
+implementation is currently limited to compiling single-threaded,
+stand-alone programs.  Future versions will add support for offloading
+multi-threaded kernels via OpenMP and OpenACC.  The following devices are
+supported (GCC identifiers in parentheses):
+
+  Fiji (fiji).
+  Vega 10 (gfx900).
+
+  
+
+
 ARC
 
   LRA is now on by default for the ARC target.  This can be
diff --git a/htdocs/index.html b/htdocs/index.html
index 181d479..8b39ff3 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -54,6 +54,11 @@ mission statement.
 News
 
 
+AMD GCN support
+[2019-01-17]
+GCC support for AMD GCN Fiji and Vega GPUs has been added.  This back
+  end was contributed by Mentor Graphics.
+
 GCC 7.4 released
 [2018-12-06]
 


Re: [wwwdocs] Mention AMD GCN on the website

2019-01-17 Thread Andi Kleen
On Thu, Jan 17, 2019 at 05:51:39PM +, Andrew Stubbs wrote:
> On 17/01/2019 17:39, Andi Kleen wrote:
> > Can you add a few words on the current limitations?
> 
> How's this?

Looks good.

-Andi


C++ PATCH for c++/88815 - narrowing conversion lost in decltype.

2019-01-17 Thread Marek Polacek
When r265789 changed instantiation_dependent_r in such a way that
TEMPLATE_PARM_INDEXes are instantiation-dependent only when their
types are dependent, it broke this test.  The test uses a combination
of SFINAE and narrow conversions to detect if an expression is constexpr.
"p" is a template parameter whose type is not dependent, so now it's not
considered instantiation-dependent.

The problem is that when finish_decltype_type sees something that isn't
instantiation_dependent_uneval_expression_p, it just looks at the type
of the expression and lets it go.  But it misses a narrowing conversion in

  decltype(int{(p(), 0U)})

which is narrowing or not depending on if p() is constant.  To figure that
out we need to create a DECLTYPE_TYPE so that we actually instantiate the
expression.

The question is what, specifically, should we check in
instantiation_dependent_r.  I went with checking if a compound literal has
something value dependent, then we need to instantion so as not to lose
a possible narrowing conversion.

In a non-SFINAE context we don't give any narrowing warnings, that's a bug
I have another patch for, but it's not dependent on this patch.  Though I
can imagine there's a patch fixing both these cases.

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

2019-01-17  Marek Polacek  

PR c++/88815 - narrowing conversion lost in decltype.
* pt.c (instantiation_dependent_r): Consider a compound literal
with a value-dependent expression dependent.

* g++.dg/cpp0x/constexpr-decltype3.C: New test.

diff --git gcc/cp/pt.c gcc/cp/pt.c
index e4f76478f54..d0f5dbeec8e 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -25800,6 +25800,14 @@ instantiation_dependent_r (tree *tp, int 
*walk_subtrees,
return *tp;
   break;
 
+case CONSTRUCTOR:
+  /* A compound literal with a value-dependent expression
+might contain narrowing conversion.  */
+  if (TREE_HAS_CONSTRUCTOR (*tp)
+ && value_dependent_expression_p (*tp))
+   return *tp;
+  break;
+
 default:
   break;
 }
diff --git gcc/testsuite/g++.dg/cpp0x/constexpr-decltype3.C 
gcc/testsuite/g++.dg/cpp0x/constexpr-decltype3.C
new file mode 100644
index 000..fd05366de50
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-decltype3.C
@@ -0,0 +1,25 @@
+// PR c++/88815
+// { dg-do compile { target c++11 } }
+
+struct true_type {
+constexpr operator bool() const { return true; }
+};
+
+struct false_type {
+constexpr operator bool() const { return false; }
+};
+
+template
+true_type is_constexpr_impl(decltype(int{(p(), 0U)}));
+
+template
+false_type is_constexpr_impl(...);
+
+template
+using is_constexpr = decltype(is_constexpr_impl(0));
+
+constexpr int f() { return 0; }
+int g() { return 0; }
+
+static_assert(is_constexpr(), "");
+static_assert(!is_constexpr(), "");


C++ PATCH for c++/78244 - narrowing conversion in template not detected, part 2

2019-01-17 Thread Marek Polacek
This patch ought to fix the rest of 78244, a missing narrowing warning in
decltype.

As I explained in Bugzilla, there can be three scenarios:

1) decltype is in a template and it has no dependent expressions, which
is the problematical case.  finish_compound_literal just returns the
compound literal without checking narrowing if processing_template_decl.
But finish_decltype_type sees an expr that is not instantiation-dependent,
so it just takes its unlowered_expr_type and returns it, without calling
check_narrowing.

2) decltype is in a template and has dependent expressions
This works, because while finish_compound_literal just returns the compound
literal, finish_decltype_type sees an expr that is instantiation-dependent,
so it creates a DECLTYPE_TYPE.
tsubst_copy_and_build then calls
  RETURN (finish_compound_literal (type, r, complain, cl));
while substituting the CONSTRUCTOR.  Now processing_template_decl is 0, so
finish_compound_literal calls check_narrowing, so we detect it.

3) decltype is not in a template
finish_compound_literal calls check_narrowing and the narrowing is detected.


I think it's better not to blithely instantiate such decltypes just for the
benefit of check_narrowing, but we can still try to check narrowing even in a
template.  check_narrowing calls instantiation_dependent_expression_p, so it
does nothing when there are dependent expressions.

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

2019-01-17  Marek Polacek  

PR c++/78244 - narrowing conversion in template not detected.
* semantics.c (finish_compound_literal): When processing a template,
try to check narrowing.

* g++.dg/cpp0x/Wnarrowing15.C: New test.
* g++.dg/cpp1y/Wnarrowing1.C: New test.

diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index bc9d53800f7..828f1578697 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -2797,6 +2797,14 @@ finish_compound_literal (tree type, tree 
compound_literal,
 
   if (processing_template_decl)
 {
+  /* If there are no dependent expressions, we can detect narrowing
+conversions.  */
+  if (SCALAR_TYPE_P (type)
+ && CONSTRUCTOR_NELTS (compound_literal) == 1
+ && !check_narrowing (type,
+  CONSTRUCTOR_ELT (compound_literal, 0)->value,
+  complain))
+   return error_mark_node;
   TREE_TYPE (compound_literal) = type;
   /* Mark the expression as a compound literal.  */
   TREE_HAS_CONSTRUCTOR (compound_literal) = 1;
diff --git gcc/testsuite/g++.dg/cpp0x/Wnarrowing15.C 
gcc/testsuite/g++.dg/cpp0x/Wnarrowing15.C
new file mode 100644
index 000..4e7c17dcfca
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/Wnarrowing15.C
@@ -0,0 +1,14 @@
+// PR c++/78244
+// { dg-do compile { target c++11 } }
+
+template 
+auto f1() -> decltype(int{2.0}, void()) { } // { dg-error "narrowing 
conversion" }
+
+template 
+auto f2() -> decltype(int{2.0}) { return 1; } // { dg-error "narrowing 
conversion" }
+
+template 
+auto f3() -> decltype(void(), int{2.0}) { return 1; } // { dg-error "narrowing 
conversion" }
+
+template 
+auto f4() -> decltype((int{2.0})) { return 1; } // { dg-error "narrowing 
conversion" }
diff --git gcc/testsuite/g++.dg/cpp1y/Wnarrowing1.C 
gcc/testsuite/g++.dg/cpp1y/Wnarrowing1.C
new file mode 100644
index 000..e1e499542f0
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1y/Wnarrowing1.C
@@ -0,0 +1,5 @@
+// PR c++/78244
+// { dg-do compile { target c++14 } }
+
+template
+decltype(int{1.1}) v; // { dg-error "narrowing conversion" }


Re: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI

2019-01-17 Thread Steve Ellcey
On Thu, 2019-01-17 at 09:10 +, Richard Sandiford wrote:
> 
> > +static bool supported_simd_type (tree t)
> 
> Missing line break after "static bool".

Fixed.

> > +static bool currently_supported_simd_type (tree t, tree b)
> 
> Same here.

Fixed.

> > +  return 0;
> 
> The return should use tab indentation.

Fixed.
> 
> OK otherwise, thanks.
> 
> Richard

Thanks for the reviews Richard, I made those changes and checked in the
patch.  That is the last of the Aarch64 SIMD / Vector ABI patches I
have so everything should be checked in and working now.

Steve Ellcey
sell...@marvell.com


Re: PATCH: Updated error messages for ill-formed cases of array initialization by string literal

2019-01-17 Thread Joseph Myers
On Thu, 17 Jan 2019, Jason Merrill wrote:

> This updated patch removes {short ,}unsigned int from the expected
> diagnostics.  And also improves error_init to accept additional arguments,
> like pedwarn_init already does.

This version is OK.

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


V2 [PATCH] c-family: Update unaligned adress of packed member check

2019-01-17 Thread H.J. Lu
On Thu, Jan 17, 2019 at 7:36 AM Jakub Jelinek  wrote:
>
> On Wed, Jan 16, 2019 at 08:57:25PM -0800, H.J. Lu wrote:
> > Check unaligned pointer conversion and strip NOPS.
>
> > -check_address_of_packed_member (tree type, tree rhs)
> > +check_address_or_pointer_of_packed_member (tree type, tree rhs)
> >  {
> >if (INDIRECT_REF_P (rhs))
> >  rhs = TREE_OPERAND (rhs, 0);
> > @@ -2726,6 +2728,36 @@ check_address_of_packed_member (tree type, tree rhs)
> >if (TREE_CODE (rhs) == ADDR_EXPR)
> >  rhs = TREE_OPERAND (rhs, 0);
> >
> > +  if (!TYPE_P (type) || POINTER_TYPE_P (type))
> > +  type = TREE_TYPE (type);
>
> Bad formatting.  Plus, when would you pass around a non-type here?
> And, isn't type always a POINTER_TYPE_P here anyway?  If not, whether
> you use TREE_TYPE on it or not shouldn't depend on whether it is a pointer,
> but on some other conditions, because a field can have pointer type too,
> so if you come in through sometimes type being the address of the var and
> sometimes the type of its value, the bug is in allowing that.

Fixed.

> > +
> > +  if (TREE_CODE (rhs) == PARM_DECL || TREE_CODE (rhs) == VAR_DECL)
>
> VAR_P (rhs) instead of TREE_CODE (rhs) == VAR_DECL.  What about RESULT_DECL?

Fixed.  I couldn't get RESULT_DECL.  I checked CALL_EXPR instead
with a testcase.

> >  static void
> > -check_and_warn_address_of_packed_member (tree type, tree rhs)
> > +check_and_warn_address_or_pointer_of_packed_member (tree type, tree rhs)
> >  {
> > +  bool nop_p;
> > +
> > +  if (TREE_CODE (rhs) == NOP_EXPR)
>
> This should be probably if (CONVERT_EXPR_P (rhs)) or maybe just do
>   tree orig_rhs = rhs;
>   STRIP_NOPS (rhs);
>   nop_p = orig_rhs != rhs;
> ?

Fixed.

> I must say I don't fully understand the nop_p stuff, why you handle
> it differently if there were any nops vs. if there were none.
> And, e.g. if you have NOP_EXPR around COND_EXPR, that outer nop_p isn't
> taken into account.  So, again, what exactly do you want to achieve,
> why do you care if there are any conversions in between or not.
> Isn't all that matters what the innermost ADDR_EXPR is and what the
> outermost type is?
>
> >if (TREE_CODE (rhs) != COND_EXPR)
>
> I think it would be more readable to do:
>   if (TREE_CODE (rhs) == COND_EXPR)
> {
>   recurse;
>   recurse;
>   return;
> }
> and handle the remaining code (longer) normally indented below that.

Fixed.

> Another thing is, the NOP_EXPRs/CONVERT_EXPRs, COMPOUND_EXPRs and
> COND_EXPRs can be arbitrarily nested, while you handle only a subset
> of those cases.  You could e.g. move the
>   while (TREE_CODE (rhs) == COMPOUND_EXPR)
>rhs = TREE_OPERAND (rhs, 1);
>
> before the if (TREE_CODE (rhs) == COND_EXPR) check and stick another
> STRIP_NOPS in between.

Fixed.

> > @@ -2795,58 +2862,5 @@ warn_for_address_or_pointer_of_packed_member (bool 
> > convert_p, tree type,
> >while (TREE_CODE (rhs) == COMPOUND_EXPR)
> >  rhs = TREE_OPERAND (rhs, 1);
>
> and then it would be pointless to do this here.

Fixed.

Here is the updated patch I am testing.

-- 
H.J.
From 1db08f118643bf4c28bd819014350dbca8590f8d Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Sat, 12 Jan 2019 21:03:50 -0800
Subject: [PATCH] c-family: Update unaligned adress of packed member check

Check unaligned pointer conversion and strip NOPS.

gcc/c-family/

	PR c/51628
	PR c/88664
	* c-common.h (warn_for_address_or_pointer_of_packed_member):
	Remove the boolean argument.
	* c-warn.c (check_address_of_packed_member): Renamed to ...
	(check_address_or_pointer_of_packed_member): This.  Also
	warn pointer conversion.
	(check_and_warn_address_of_packed_member): Renamed to ...
	(check_and_warn_address_or_pointer_of_packed_member): This.
	Also warn pointer conversion.
	(warn_for_address_or_pointer_of_packed_member): Remove the
	boolean argument.  Don't check pointer conversion here.

gcc/c

	PR c/51628
	PR c/88664
	* c-typeck.c (convert_for_assignment): Upate the
	warn_for_address_or_pointer_of_packed_member call.

gcc/cp

	PR c/51628
	PR c/88664
	* call.c (convert_for_arg_passing): Upate the
	warn_for_address_or_pointer_of_packed_member call.
	* typeck.c (convert_for_assignment): Likewise.

gcc/testsuite/

	PR c/51628
	PR c/88664
	* c-c++-common/pr51628-33.c: New test.
	* c-c++-common/pr51628-35.c: New test.
	* c-c++-common/pr88664-1.c: Likewise.
	* c-c++-common/pr88664-2.c: Likewise.
	* gcc.dg/pr51628-34.c: Likewise.
---
 gcc/c-family/c-common.h |   2 +-
 gcc/c-family/c-warn.c   | 175 +---
 gcc/c/c-typeck.c|   6 +-
 gcc/cp/call.c   |   2 +-
 gcc/cp/typeck.c |   2 +-
 gcc/testsuite/c-c++-common/pr51628-33.c |  19 +++
 gcc/testsuite/c-c++-common/pr51628-35.c |  23 
 gcc/testsuite/c-c++-common/pr88664-1.c  |  20 +++
 gcc/testsuite/c-c++-common/pr88664-2.c  |  22 +++
 gcc/testsuite/gcc.dg/pr51628-34.c   |  25 
 10 files changed, 208 insertions(

[C++ PATCH] PR c++/86740, ICE with constexpr if and nested generic lambdas.

2019-01-17 Thread Jason Merrill
When we partially instantiate the constexpr if, we walk through its body to
see what it uses from the enclosing local_specializations.  That walk was
overlooking the use of 'count' in the captures of the innermost lambda,
because we weren't walking into the capture list.

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

* tree.c (cp_walk_subtrees): Handle LAMBDA_EXPR.
---
 gcc/cp/tree.c   |  8 ++
 gcc/testsuite/g++.dg/cpp1z/constexpr-if25.C | 27 +
 gcc/cp/ChangeLog|  5 
 3 files changed, 40 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/constexpr-if25.C

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 50002161500..be33d4186f9 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -4933,6 +4933,14 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p, 
walk_tree_fn func,
}
   break;
 
+case LAMBDA_EXPR:
+  /* Don't walk into the body of the lambda, but the capture initializers
+are part of the enclosing context.  */
+  for (tree cap = LAMBDA_EXPR_CAPTURE_LIST (*tp); cap;
+  cap = TREE_CHAIN (cap))
+   WALK_SUBTREE (TREE_VALUE (cap));
+  break;
+
 default:
   return NULL_TREE;
 }
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if25.C 
b/gcc/testsuite/g++.dg/cpp1z/constexpr-if25.C
new file mode 100644
index 000..144139ea196
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if25.C
@@ -0,0 +1,27 @@
+// PR c++/86740
+// { dg-do compile { target c++17 } }
+
+struct Constant
+{
+  static constexpr int value = 0;
+};
+template
+void invokeWithConstant(F &&f)
+{
+  f(Constant{});
+}
+int foo()
+{
+  int count = 0;
+  invokeWithConstant
+([&] (auto id1)
+ {
+   invokeWithConstant
+([&] (auto id2)
+ {
+   if constexpr (id1.value == 0  &&  id2.value == 0)
+ [&] { count = 1; } ();
+ });
+ });
+  return count;
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 05e8566e493..01a57601f4c 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2019-01-17  Jason Merrill  
+
+   PR c++/86740, ICE with constexpr if and nested generic lambdas.
+   * tree.c (cp_walk_subtrees): Handle LAMBDA_EXPR.
+
 2019-01-17  Paolo Carlini  
 
* decl.c (grokdeclarator): Use typespec_loc in error messages

base-commit: 7e351bf905bf4b0ad84bf9dae79032f8c41f0e03
-- 
2.20.1



Re: C++ PATCH for c++/78244 - narrowing conversion in template not detected, part 2

2019-01-17 Thread Jason Merrill

On 1/17/19 2:09 PM, Marek Polacek wrote:

This patch ought to fix the rest of 78244, a missing narrowing warning in
decltype.

As I explained in Bugzilla, there can be three scenarios:

1) decltype is in a template and it has no dependent expressions, which
is the problematical case.  finish_compound_literal just returns the
compound literal without checking narrowing if processing_template_decl.


This is the sort of thing that we've been gradually fixing: if the 
compound literal isn't dependent at all, we want to do the normal 
processing.  And then usually return a result based on the original 
trees rather than the result of processing.  For instance, 
finish_call_expr.  Something like that ought to work here, too, and be 
more generally applicable; this shouldn't be limited to casting to a 
scalar type, casting to a known class type can also involve narrowing.


The check in the other patch that changes instantiation_dependent_r 
should be more similar to the one in finish_compound_literal.  Or 
perhaps you could set a flag here in finish_compound_literal to indicate 
that it's instantiation-dependent, and just check that in 
instantiation_dependent_r.


Jason


[committed] avoid handling anti-ranges when checking built-in pointers (PR 88273)

2019-01-17 Thread Martin Sebor

The code that detects out-of-bounds pointers in calls to built-ins
like memcpy with POINTER_PLUS_EXPR arguments tried a little too
hard to detect out-of-bounds offsets and didn't handle anti-ranges
correctly.  I don't see how it could have ever worked and there
were no tests for it in the test suite.  PR 88273, however, has
a test case that triggers the bug and causes a false positive.
The attached patch removes the incorrect anti-range handling and
replaces it with the varying fallback when no range info is
available.

Removing my own buggy code seems like an obviously correct and safe
solution so I committed it in r268048 after testing on x86_64-linux
and verifying the test case with a powerpc-linux cross (with which
the bug was first discovered).  Since this regression affects both
GCC 9 and 8 I will backport it to 8 as well.

Martin
PR middle-end/88273 - [8/9 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16]

gcc/ChangeLog:

	PR middle-end/88273
	* gimple-ssa-warn-restrict.c (builtin_memref::extend_offset_range):
	Handle anti-ranges the same as no range at all.

gcc/testsuite/ChangeLog:

	PR middle-end/88273
	* gcc.dg/Warray-bounds-38.c: New test.

Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c	(revision 268037)
+++ gcc/gimple-ssa-warn-restrict.c	(working copy)
@@ -319,13 +319,9 @@ builtin_memref::extend_offset_range (tree offset)
 	  offrange[0] += offset_int::from (min, SIGNED);
 	  offrange[1] += offset_int::from (max, SIGNED);
 	}
-  else if (rng == VR_ANTI_RANGE)
-	{
-	  offrange[0] += offset_int::from (max + 1, SIGNED);
-	  offrange[1] += offset_int::from (min - 1, SIGNED);
-	}
   else
 	{
+	  /* Handle an anti-range the same as no range at all.  */
 	  gimple *stmt = SSA_NAME_DEF_STMT (offset);
 	  tree type;
 	  if (is_gimple_assign (stmt)
Index: gcc/testsuite/gcc.dg/Warray-bounds-38.c
===
--- gcc/testsuite/gcc.dg/Warray-bounds-38.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/Warray-bounds-38.c	(working copy)
@@ -0,0 +1,30 @@
+/* PR middle-end/88273 - bogus warning: 'memcpy' offset [-527, -529]
+   is out of the bounds [0, 16]
+   { dg-do compile }
+   { dg-options "-O2 -Wall" }  */
+
+typedef __SIZE_TYPE__ size_t;
+
+void *q;
+
+size_t x, y;
+
+inline void f (char *p, int i, size_t j)
+{
+  size_t n = y ? y : j;
+
+  p += x - i;
+
+  __builtin_memcpy (q, p, n);   /* { dg-bogus "bounds" } */
+
+  x = n;
+}
+
+void g (void)
+{
+  struct { char a[16]; } s;
+
+  f (q, 0, sizeof s);
+
+  f (s.a, 33 * sizeof s, 1);
+}


Re: [PATCH] PR target/85596 Add --with-multilib-list doc for aarch64

2019-01-17 Thread James Greenhalgh
On Mon, Jan 07, 2019 at 09:07:35AM -0600, Christophe Lyon wrote:
> Hi,
> 
> This small patch adds a short description of --with-multilib-list for aarch64.
> OK?

OK.

Thanks,
James

> 
> Thanks,
> 
> Christophe

> 2019-01-07  Christophe Lyon  
> 
>   PR target/85596
>   * doc/install.texi (with-multilib-list): Document for aarch64.
> 


Re: [PATCH] Fix arm_neon.h #pragma GCC target syntax (PR target/88734)

2019-01-17 Thread James Greenhalgh
On Thu, Jan 17, 2019 at 07:47:32AM -0600, Jakub Jelinek wrote:
> Hi!
> 
> arm_neon.h on both targets contained a couple of spots with invalid
> #pragma GCC target syntax.  This doesn't result in errors, just warnings and
> those warnings are surpressed in system headers, so are visible with
> -Wsystem-headers only.  Anyway, the end result was that these pragmas were
> ignored, when they meant to be there.
> 
> The following patch fixes it.  Also, on aarch64 the sha3 intrinsics were
> wrapped with arch=armv8.2-a+crypto rather than arch=armv8.2-a+sha3, but
> because of the invalid syntax it wasn't covered in the testsuite.
> 
> Without the patch, besides -Wsystem-headers warnings on it, if somebody
> attempts to use those intrinsics in code compiled with target options that
> do not include the necessary ISA features, one will get ICEs rather than
> errors.
> 
> Bootstrapped/regtested on aarch64-linux, ok for trunk?
> 
> Note, I haven't included a testcase, as I'm not familiar enough with
> gcc.target/aarch64/ test style, but a test would be roughly include the
> testcase from the PR, compile it with -march=something that doesn't include
> the needed ISA options, probably have a dg-skip-if if somebody overrides it
> from the --target_board and make sure it emits a dg-error message rather
> than ICE.

AArch64 parts of this are OK by me. Thanks for the fix.

James

> 
> 2019-01-17  Jakub Jelinek  
> 
>   PR target/88734
>   * config/arm/arm_neon.h: Fix #pragma GCC target syntax - replace
>   (("..."))) with ("...").
>   * config/aarch64/arm_neon.h: Likewise.  Use arch=armv8.2-a+sha3
>   instead of arch=armv8.2-a+crypto for vsha512hq_u64 etc. intrinsics.


Re: add tsv110 pipeline scheduling

2019-01-17 Thread James Greenhalgh
On Mon, Jan 14, 2019 at 08:02:45AM -0600, wuyuan (E) wrote:
> Hi  Kyrill:
>  The gcc 7.3.0 does not discard the store1 and load1 command; I did 
> not expect the community's latest gcc changes so large .   
>  now I downloaded the latest GCC code, put the patch into GCC source 
> code, the compiler can pass, thank you very much for your work!
>   
> Best Regards,
>   
> wuyuan

Please check your modeling of Advanced SIMD operations.

> +(define_insn_reservation
> +  "tsv110_neon_ld4_lane" 9
> +  (and (eq_attr "tune" "tsv110")
> +   (eq_attr "type" "neon_load4_all_lanes,neon_load4_all_lanes_q,\
> +neon_load4_one_lane,neon_load4_one_lane_q"))
> +  "((tsv110_ls1*8)|(tsv110_ls2*8)|(tsv110_fsu1*8)|(tsv110_fsu2*8))")
> +

This model says you will reserve
 LS1 for 8 cycles,
  OR LS2 for 8 cycles,
  OR FSU1 for 8 cycles,
  OR FSU2 for 8 cycles.

> +(define_insn_reservation  "tsv110_neon_abd_aba" 4
> +  (and (eq_attr "tune" "tsv110")
> +   (eq_attr "type" "neon_abd,neon_arith_acc"))
> +  "tsv110_fsu1,tsv110_fsu2")

This model says you will reserve
   FSU1 for 1 cycle,
  THEN FSU2 for 1 cycle.

> +(define_insn_reservation  "tsv110_neon_abd_aba_q" 4
> +  (and (eq_attr "tune" "tsv110")
> +   (eq_attr "type" "neon_arith_acc_q"))
> +  "(tsv110_fsu1,tsv110_fsu2)+(tsv110_fsu1,tsv110_fsu2)")
> +

This model says you will reserve:
  FSU1 for 1 cycle,
 THEN FSU2 for 1 cycle
  AND
  FSU1 for 1 cycle,
 THEN FSU2 for 1 cycle

Which would be a redundant AND.

Is that how you intend to model these operations?

Remember,

If you are looking to model a 'THEN' relationship you can use the ',' operator,
If you are looking to model an 'AND' relationship you can use the '+' operator,
If you are looking to model an 'OR' relationship you can use the '|' operator.

Taking Cortex-A57 as an example:

> (define_insn_reservation
>   "cortex_a57_neon_load_d" 11
>   (and (eq_attr "tune" "cortexa57")
>(eq_attr "cortex_a57_neon_type" "neon_load_d"))
>   "ca57_cx1_issue+ca57_cx2_issue,
>ca57_ls_issue+ca57_ls_issue,ca57_ldr*2")

This model says you will reserve:

   CX1_ISSUE AND CX2_ISSUE,
  THEN LS_ISSUE AND LS_ISSUE,
  THEN LDR for 2 cycles.

Please let me know if you plan to update the model. If I have misunderstood
your intentions, please accept my apologies.

Best Regards,
James Greenhalgh


> 
> 
>   * config/aarch64/aarch64-cores.def (tsv1100): Change scheduling model.
>   * config/aarch64/aarch64.md : Add "tsv110.md"
>   * config/aarch64/tsv110.md: New file.


V3 [PATCH] c-family: Update unaligned adress of packed member check

2019-01-17 Thread H.J. Lu
On Thu, Jan 17, 2019 at 12:27 PM H.J. Lu  wrote:
>
> On Thu, Jan 17, 2019 at 7:36 AM Jakub Jelinek  wrote:
> >
> > On Wed, Jan 16, 2019 at 08:57:25PM -0800, H.J. Lu wrote:
> > > Check unaligned pointer conversion and strip NOPS.
> >
> > > -check_address_of_packed_member (tree type, tree rhs)
> > > +check_address_or_pointer_of_packed_member (tree type, tree rhs)
> > >  {
> > >if (INDIRECT_REF_P (rhs))
> > >  rhs = TREE_OPERAND (rhs, 0);
> > > @@ -2726,6 +2728,36 @@ check_address_of_packed_member (tree type, tree 
> > > rhs)
> > >if (TREE_CODE (rhs) == ADDR_EXPR)
> > >  rhs = TREE_OPERAND (rhs, 0);
> > >
> > > +  if (!TYPE_P (type) || POINTER_TYPE_P (type))
> > > +  type = TREE_TYPE (type);
> >
> > Bad formatting.  Plus, when would you pass around a non-type here?
> > And, isn't type always a POINTER_TYPE_P here anyway?  If not, whether
> > you use TREE_TYPE on it or not shouldn't depend on whether it is a pointer,
> > but on some other conditions, because a field can have pointer type too,
> > so if you come in through sometimes type being the address of the var and
> > sometimes the type of its value, the bug is in allowing that.
>
> Fixed.
>
> > > +
> > > +  if (TREE_CODE (rhs) == PARM_DECL || TREE_CODE (rhs) == VAR_DECL)
> >
> > VAR_P (rhs) instead of TREE_CODE (rhs) == VAR_DECL.  What about RESULT_DECL?
>
> Fixed.  I couldn't get RESULT_DECL.  I checked CALL_EXPR instead
> with a testcase.
>
> > >  static void
> > > -check_and_warn_address_of_packed_member (tree type, tree rhs)
> > > +check_and_warn_address_or_pointer_of_packed_member (tree type, tree rhs)
> > >  {
> > > +  bool nop_p;
> > > +
> > > +  if (TREE_CODE (rhs) == NOP_EXPR)
> >
> > This should be probably if (CONVERT_EXPR_P (rhs)) or maybe just do
> >   tree orig_rhs = rhs;
> >   STRIP_NOPS (rhs);
> >   nop_p = orig_rhs != rhs;
> > ?
>
> Fixed.
>
> > I must say I don't fully understand the nop_p stuff, why you handle
> > it differently if there were any nops vs. if there were none.
> > And, e.g. if you have NOP_EXPR around COND_EXPR, that outer nop_p isn't
> > taken into account.  So, again, what exactly do you want to achieve,
> > why do you care if there are any conversions in between or not.
> > Isn't all that matters what the innermost ADDR_EXPR is and what the
> > outermost type is?
> >
> > >if (TREE_CODE (rhs) != COND_EXPR)
> >
> > I think it would be more readable to do:
> >   if (TREE_CODE (rhs) == COND_EXPR)
> > {
> >   recurse;
> >   recurse;
> >   return;
> > }
> > and handle the remaining code (longer) normally indented below that.
>
> Fixed.
>
> > Another thing is, the NOP_EXPRs/CONVERT_EXPRs, COMPOUND_EXPRs and
> > COND_EXPRs can be arbitrarily nested, while you handle only a subset
> > of those cases.  You could e.g. move the
> >   while (TREE_CODE (rhs) == COMPOUND_EXPR)
> >rhs = TREE_OPERAND (rhs, 1);
> >
> > before the if (TREE_CODE (rhs) == COND_EXPR) check and stick another
> > STRIP_NOPS in between.
>
> Fixed.
>
> > > @@ -2795,58 +2862,5 @@ warn_for_address_or_pointer_of_packed_member (bool 
> > > convert_p, tree type,
> > >while (TREE_CODE (rhs) == COMPOUND_EXPR)
> > >  rhs = TREE_OPERAND (rhs, 1);
> >
> > and then it would be pointless to do this here.
>
> Fixed.
>
> Here is the updated patch I am testing.
>

Here is the patch I tested without regressions.

-- 
H.J.
From bed69225767e064db7df58c7cb93b6ab14eee27d Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Sat, 12 Jan 2019 21:03:50 -0800
Subject: [PATCH] c-family: Update unaligned adress of packed member check

Check unaligned pointer conversion and strip NOPS.

gcc/c-family/

	PR c/51628
	PR c/88664
	* c-common.h (warn_for_address_or_pointer_of_packed_member):
	Remove the boolean argument.
	* c-warn.c (check_address_of_packed_member): Renamed to ...
	(check_address_or_pointer_of_packed_member): This.  Also
	warn pointer conversion.
	(check_and_warn_address_of_packed_member): Renamed to ...
	(check_and_warn_address_or_pointer_of_packed_member): This.
	Also warn pointer conversion.
	(warn_for_address_or_pointer_of_packed_member): Remove the
	boolean argument.  Don't check pointer conversion here.

gcc/c

	PR c/51628
	PR c/88664
	* c-typeck.c (convert_for_assignment): Upate the
	warn_for_address_or_pointer_of_packed_member call.

gcc/cp

	PR c/51628
	PR c/88664
	* call.c (convert_for_arg_passing): Upate the
	warn_for_address_or_pointer_of_packed_member call.
	* typeck.c (convert_for_assignment): Likewise.

gcc/testsuite/

	PR c/51628
	PR c/88664
	* c-c++-common/pr51628-33.c: New test.
	* c-c++-common/pr51628-35.c: New test.
	* c-c++-common/pr88664-1.c: Likewise.
	* c-c++-common/pr88664-2.c: Likewise.
	* gcc.dg/pr51628-34.c: Likewise.
---
 gcc/c-family/c-common.h |   2 +-
 gcc/c-family/c-warn.c   | 177 +---
 gcc/c/c-typeck.c|   6 +-
 gcc/cp/call.c   |   2 +-
 gcc/cp/typeck.c |   2 +-
 gcc/tests

[PATCH, libphobos] Commited OSX bindings for core.sys.posix.aio

2019-01-17 Thread Iain Buclaw
Hi,

This patch fixes build failure found when testing on OSX.

Bootstrapped and tested on x86_64-linux-gnu, though have verified is
correct on OSX.

Committed to trunk as r268050.

-- 
Iain
---
diff --git a/libphobos/libdruntime/core/sys/posix/aio.d b/libphobos/libdruntime/core/sys/posix/aio.d
index 99bd0b3475b..8300d920ca9 100644
--- a/libphobos/libdruntime/core/sys/posix/aio.d
+++ b/libphobos/libdruntime/core/sys/posix/aio.d
@@ -63,6 +63,19 @@ version (CRuntime_Glibc)
 }
 }
 }
+else version (OSX)
+{
+struct aiocb
+{
+int aio_filedes;
+off_t aio_offset;
+void* aio_buf;   // volatile
+size_t aio_nbytes;
+int reqprio;
+sigevent aio_sigevent;
+int aio_lio_opcode;
+}
+}
 else version (FreeBSD)
 {
 struct __aiocb_private
@@ -158,6 +171,15 @@ version (CRuntime_Glibc)
 AIO_ALLDONE
 }
 }
+else version (OSX)
+{
+enum
+{
+AIO_ALLDONE = 0x1,
+AIO_CANCELED = 0x2,
+AIO_NOTCANCELED = 0x4,
+}
+}
 else version (Solaris)
 {
 enum
@@ -187,6 +209,15 @@ version (CRuntime_Glibc)
 LIO_NOP
 }
 }
+else version (OSX)
+{
+enum
+{
+LIO_NOP = 0x0,
+LIO_READ = 0x1,
+LIO_WRITE = 0x2,
+}
+}
 else version (Solaris)
 {
 enum
@@ -215,6 +246,14 @@ version (CRuntime_Glibc)
 LIO_NOWAIT
 }
 }
+else version (OSX)
+{
+enum
+{
+LIO_NOWAIT = 0x1,
+LIO_WAIT = 0x2,
+}
+}
 else version (Solaris)
 {
 enum
diff --git a/libphobos/libdruntime/core/sys/posix/signal.d b/libphobos/libdruntime/core/sys/posix/signal.d
index a592f6f1eb0..1ddcba91049 100644
--- a/libphobos/libdruntime/core/sys/posix/signal.d
+++ b/libphobos/libdruntime/core/sys/posix/signal.d
@@ -3465,6 +3465,14 @@ else version (DragonFlyBSD)
 }
 else version (Darwin)
 {
+struct sigevent
+{
+int sigev_notify;
+int sigev_signo;
+sigval sigev_value;
+void function(sigval) sigev_notify_function;
+pthread_attr_t* sigev_notify_attributes;
+}
 }
 else version (Solaris)
 {


[PATCH] PR fortran/88898 - fix tests to check for warnings on aarch64 only

2019-01-17 Thread Steve Ellcey
I am going to check this patch in as obvious.  My earlier patch for Aarch64
SIMD support added some warning tests to three Fortran gomp tests as they were
needed for aarch64.  Unfortunately, I forgot to add '{ target aarch64-*-* }'
to the warning checks so the tests failed on x86 where the warning is not 
generated.
The fix is just to add the target check to the new warnings I added earlier
today.

Sorry for the noise.

Steve Ellcey
sell...@marvell.com


2018-01-17  Steve Ellcey  

PR fortran/88898
* gfortran.dg/gomp/declare-simd-2.f90: Add aarch64 target specifier to
warning checks.
* gfortran.dg/gomp/pr79154-1.f90: Ditto.
* gfortran.dg/gomp/pr83977.f90: Ditto.



diff --git a/gcc/testsuite/gfortran.dg/gomp/declare-simd-2.f90 b/gcc/testsuite/gfortran.dg/gomp/declare-simd-2.f90
index fd4e119744d..5852122a7de 100644
--- a/gcc/testsuite/gfortran.dg/gomp/declare-simd-2.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/declare-simd-2.f90
@@ -1,6 +1,6 @@
 ! { dg-do compile }
 
-function f1 (a, b, c, d, e, f) ! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" }
+function f1 (a, b, c, d, e, f) ! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" "" { target aarch64-*-* } }
   integer, value :: a, b, c
   integer :: d, e, f, f1
 !$omp declare simd (f1) uniform(b) linear(c, d) linear(uval(e)) linear(ref(f))
@@ -12,7 +12,7 @@ function f1 (a, b, c, d, e, f) ! { dg-warning "GCC does not currently support mi
   f = f + 1
   f1 = a + b + c + d + e + f
 end function f1
-integer function f2 (a, b) ! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" }
+integer function f2 (a, b) ! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" "" { target aarch64-*-* } }
   integer :: a, b
 !$omp declare simd uniform(b) linear(ref(a):b)
   a = a + 1
diff --git a/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90 b/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
index 953dcadd786..29a570a990f 100644
--- a/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
@@ -1,7 +1,7 @@
 ! PR fortran/79154
 ! { dg-do compile }
 
-pure real function foo (a, b)		! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" }
+pure real function foo (a, b)		! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" "" { target aarch64-*-* } }
 !$omp declare simd(foo)			! { dg-bogus "may not appear in PURE or ELEMENTAL" }
   real, intent(in) :: a, b
   foo = a + b
@@ -20,7 +20,7 @@ pure real function baz (a, b)
   real, intent(in) :: a, b
   baz = a + b
 end function baz
-elemental real function fooe (a, b)	! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" }
+elemental real function fooe (a, b)	! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" "" { target aarch64-*-* } }
 !$omp declare simd(fooe)		! { dg-bogus "may not appear in PURE or ELEMENTAL" }
   real, intent(in) :: a, b
   fooe = a + b
diff --git a/gcc/testsuite/gfortran.dg/gomp/pr83977.f90 b/gcc/testsuite/gfortran.dg/gomp/pr83977.f90
index 6dfdbc32c2d..35fe2cc5edc 100644
--- a/gcc/testsuite/gfortran.dg/gomp/pr83977.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/pr83977.f90
@@ -1,7 +1,7 @@
 ! PR middle-end/83977
 ! { dg-do compile }
 
-integer function foo (a, b) ! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" }
+integer function foo (a, b) ! { dg-warning "GCC does not currently support mixed size types for 'simd' functions" "" { target aarch64-*-* } }
integer :: a, b
 !$omp declare simd uniform(b) linear(ref(a):b)
a = a + 1


[PATCH, libphobos] Committed hppa-linux-gnu bindings

2019-01-17 Thread Iain Buclaw
Hi,

This patch adds one part of libphobos support for hppa-linux-gnu, as
posted by John.  Apologies for it taking a while to get round to
downstreaming this.

Preliminary testsuite runs have been done which show some promising
results, but still a little more to do, particularly with handling the
stack growth direction.

Bootstrapped and regression tested on x86_64-linux-gnu, which only
verifies that all scoping is correct.

Committed to trunk as r268055.

-- 
Iain
---
diff --git a/libphobos/libdruntime/core/stdc/errno.d b/libphobos/libdruntime/core/stdc/errno.d
index eaf4867a942..03c88d79cb8 100644
--- a/libphobos/libdruntime/core/stdc/errno.d
+++ b/libphobos/libdruntime/core/stdc/errno.d
@@ -25,6 +25,7 @@ else version (WatchOS)
 
 version (ARM) version = ARM_Any;
 version (AArch64) version = ARM_Any;
+version (HPPA)version = HPPA_Any;
 version (MIPS32)  version = MIPS_Any;
 version (MIPS64)  version = MIPS_Any;
 version (PPC) version = PPC_Any;
@@ -421,6 +422,112 @@ else version (linux)
 enum ERFKILL= 132;///
 enum EHWPOISON  = 133;///
 }
+else version (HPPA_Any)
+{
+enum ENOMSG = 35; ///
+enum EIDRM  = 36; ///
+enum ECHRNG = 37; ///
+enum EL2NSYNC   = 38; ///
+enum EL3HLT = 39; ///
+enum EL3RST = 40; ///
+enum ELNRNG = 41; ///
+enum EUNATCH= 42; ///
+enum ENOCSI = 43; ///
+enum EL2HLT = 44; ///
+enum EDEADLK= 45; ///
+enum EDEADLOCK  = EDEADLK;///
+enum ENOLCK = 46; ///
+enum EILSEQ = 47; ///
+enum ENONET = 50; ///
+enum ENODATA= 51; ///
+enum ETIME  = 52; ///
+enum ENOSR  = 53; ///
+enum ENOSTR = 54; ///
+enum ENOPKG = 55; ///
+enum ENOLINK= 57; ///
+enum EADV   = 58; ///
+enum ESRMNT = 59; ///
+enum ECOMM  = 60; ///
+enum EPROTO = 61; ///
+enum EMULTIHOP  = 64; ///
+enum EDOTDOT= 66; ///
+enum EBADMSG= 67; ///
+enum EUSERS = 68; ///
+enum EDQUOT = 69; ///
+enum ESTALE = 70; ///
+enum EREMOTE= 71; ///
+enum EOVERFLOW  = 72; ///
+enum EBADE  = 160;///
+enum EBADR  = 161;///
+enum EXFULL = 162;///
+enum ENOANO = 163;///
+enum EBADRQC= 164;///
+enum EBADSLT= 165;///
+enum EBFONT = 166;///
+enum ENOTUNIQ   = 167;///
+enum EBADFD = 168;///
+enum EREMCHG= 169;///
+enum ELIBACC= 170;///
+enum ELIBBAD= 171;///
+enum ELIBSCN= 172;///
+enum ELIBMAX= 173;///
+enum ELIBEXEC   = 174;///
+enum ERESTART   = 175;///
+enum ESTRPIPE   = 176;///
+enum EUCLEAN= 177;///
+enum ENOTNAM= 178;///
+enum ENAVAIL= 179;///
+enum EISNAM = 180;///
+enum EREMOTEIO  = 181;///
+enum ENOMEDIUM  = 182;///
+enum EMEDIUMTYPE= 183;///
+enum ENOKEY = 184;///
+enum EKEYEXPIRED= 185;///
+enum EKEYREVOKED= 186;///
+enum EKEYREJECTED   = 187;///
+enum ENOSYM = 215;///
+enum ENOTSOCK   = 216;///
+enum EDESTADDRREQ   = 217;///
+enum EMSGSIZE   = 218;///
+enum EPROTOTYPE = 219;///
+enum ENOPROTOOPT= 220;///
+enum EPROTONOSUPPORT= 221;///
+enum ESOCKTNOSUPPORT= 221;///
+enum EOPNOTSUPP = 223;///
+enum EPFNOSUPPORT   = 224;///
+enum EAFNOSUPPORT   = 225;///
+enum EADDRINUSE = 226;///
+enum EADDRNOTAVAIL  = 227;///
+enum ENETDOWN   = 228;///
+enu

[PATCH, libphobos] Committed Fiber/Thread support for StackGrowsUp

2019-01-17 Thread Iain Buclaw
Hi,

This patch fixes getStackBottom in core.thread to support targets
where the stack grows up, notably hppa configurations.  After other
fixes in the compiler, this allows core.thread unittests to pass, as
well as the garbage collector to work correctly on hppa-linux-gnu.

Bootstrapped and regression tested on x86_64-linux-gnu.

Committed to trunk as r268056.

-- 
Iain
---
diff --git a/libphobos/libdruntime/core/thread.d b/libphobos/libdruntime/core/thread.d
index 98a81425f47..e502072be7a 100644
--- a/libphobos/libdruntime/core/thread.d
+++ b/libphobos/libdruntime/core/thread.d
@@ -3254,7 +3254,9 @@ private void* getStackBottom() nothrow @nogc
 pthread_getattr_np(pthread_self(), &attr);
 pthread_attr_getstack(&attr, &addr, &size);
 pthread_attr_destroy(&attr);
-return addr + size;
+version (StackGrowsDown)
+addr += size;
+return addr;
 }
 else version (FreeBSD)
 {
@@ -3265,7 +3267,9 @@ private void* getStackBottom() nothrow @nogc
 pthread_attr_get_np(pthread_self(), &attr);
 pthread_attr_getstack(&attr, &addr, &size);
 pthread_attr_destroy(&attr);
-return addr + size;
+version (StackGrowsDown)
+addr += size;
+return addr;
 }
 else version (NetBSD)
 {
@@ -3276,7 +3280,9 @@ private void* getStackBottom() nothrow @nogc
 pthread_attr_get_np(pthread_self(), &attr);
 pthread_attr_getstack(&attr, &addr, &size);
 pthread_attr_destroy(&attr);
-return addr + size;
+version (StackGrowsDown)
+addr += size;
+return addr;
 }
 else version (Solaris)
 {
@@ -3293,7 +3299,9 @@ private void* getStackBottom() nothrow @nogc
 pthread_getattr_np(pthread_self(), &attr);
 pthread_attr_getstack(&attr, &addr, &size);
 pthread_attr_destroy(&attr);
-return addr + size;
+version (StackGrowsDown)
+addr += size;
+return addr;
 }
 else
 static assert(false, "Platform not supported.");
diff --git a/libphobos/libdruntime/gc/impl/conservative/gc.d b/libphobos/libdruntime/gc/impl/conservative/gc.d
index 1437846f48b..b7bb9b0c36f 100644
--- a/libphobos/libdruntime/gc/impl/conservative/gc.d
+++ b/libphobos/libdruntime/gc/impl/conservative/gc.d
@@ -30,12 +30,6 @@ module gc.impl.conservative.gc;
 //debug = INVARIANT;// enable invariants
 //debug = PROFILE_API;  // profile API calls for config.profile > 1
 
-/*** Configuration */
-
-version = STACKGROWSDOWN;   // growing the stack means subtracting from the stack pointer
-// (use for Intel X86 CPUs)
-// else growing the stack means adding to the stack pointer
-
 /***/
 
 import gc.bits;


Re: [PATCH] Read avx512vl-vfixupimms*-2.c testcases (PR target/88489)

2019-01-17 Thread Wei Xiao
> > > For r267160, I'd expect you want to revert just the config/i386/ part and
> > > keep the testcases, they should work even with the changes reverted, 
> > > right?
> > >
> > The testcase part also need to be reverted since we have changed them
> > according to the incorrect intrinsic list in SDM.
>
> I don't really understand this.
>
> The testcases succeed just fine for me in the current trunk with all the
> reversions and test something the current state of the testsuite doesn't
> check normally, in particular that the testcases run correctly even when
> -mavx512vl is used.  As that misbehaved in the past, we should make sure we
> don't break that again.
>

You're right. The testcases need to be kept to prevent regression.

> Uros, is it ok to reapply this to current trunk?


libgo patch committed: In sigprof, skip to sigtrampgo if we don't find sigtramp

2019-01-17 Thread Ian Lance Taylor
This patch to libgo change the runtime function sigprof to skip to
sigtrampgo if we don't find sigtramp.  This fixes GCC PR 88202.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Bootstrapped and ran runtime/pprof test on aarch64-linux-gnu.
Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268001)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-d6576c83016d856217758c06d945bfc363ffb817
+d16e9181a760796802c067730bb030b92b63fb2c
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/proc.go
===
--- libgo/go/runtime/proc.go(revision 268001)
+++ libgo/go/runtime/proc.go(working copy)
@@ -3600,10 +3600,17 @@ func sigprof(pc uintptr, gp *g, mp *m) {
// To ensure a sane profile, walk through the frames in
// "stklocs" until we find the "runtime.sigtramp" frame, then
// report only those frames below the frame one down from
-   // that. If for some reason "runtime.sigtramp" is not present,
-   // don't make any changes.
+   // that. On systems that don't split stack, "sigtramp" can
+   // do a sibling call to "sigtrampgo", so use "sigtrampgo"
+   // if we don't find "sigtramp". If for some reason
+   // neither "runtime.sigtramp" nor "runtime.sigtrampgo" is
+   // present, don't make any changes.
framesToDiscard := 0
for i := 0; i < n; i++ {
+   if stklocs[i].function == "runtime.sigtrampgo" && i+2 < 
n {
+   framesToDiscard = i + 2
+   n -= framesToDiscard
+   }
if stklocs[i].function == "runtime.sigtramp" && i+2 < n 
{
framesToDiscard = i + 2
n -= framesToDiscard


[C++ PATCH] PR c++/86205 - ICE with ?: of throw and template-id.

2019-01-17 Thread Jason Merrill
My patch for 64372 removed a bogus lvalue-rvalue conversion for one arm of a
?: expression where the other arm is a throw.  But we still need to require
any overload to be resolved, even though we aren't getting that from
decay_conversion anymore.

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

* pt.c (resolve_nondeduced_context_or_error): Split out from...
* typeck.c (decay_conversion): ...here.
* call.c (build_conditional_expr_1): Use it.
---
 gcc/cp/cp-tree.h   |  1 +
 gcc/cp/call.c  | 13 +
 gcc/cp/pt.c| 15 +++
 gcc/cp/typeck.c|  8 +---
 gcc/testsuite/g++.dg/cpp0x/cond2.C | 14 ++
 gcc/cp/ChangeLog   |  5 +
 6 files changed, 49 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/cond2.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 5cc8f88d522..23d4a0e3c69 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6831,6 +6831,7 @@ extern tree get_template_innermost_arguments  
(const_tree);
 extern tree get_template_argument_pack_elems   (const_tree);
 extern tree get_function_template_decl (const_tree);
 extern tree resolve_nondeduced_context (tree, tsubst_flags_t);
+extern tree resolve_nondeduced_context_or_error(tree, tsubst_flags_t);
 extern hashval_t iterative_hash_template_arg (tree arg, hashval_t val);
 extern tree coerce_template_parms   (tree, tree, tree);
 extern tree coerce_template_parms   (tree, tree, tree, 
tsubst_flags_t);
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 4f04b610004..c639f5f23e8 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -5067,6 +5067,19 @@ build_conditional_expr_1 (const op_location_t &loc,
   arg3_type = unlowered_expr_type (arg3);
   if (VOID_TYPE_P (arg2_type) || VOID_TYPE_P (arg3_type))
 {
+  /* 'void' won't help in resolving an overloaded expression on the
+other side, so require it to resolve by itself.  */
+  if (arg2_type == unknown_type_node)
+   {
+ arg2 = resolve_nondeduced_context_or_error (arg2, complain);
+ arg2_type = TREE_TYPE (arg2);
+   }
+  if (arg3_type == unknown_type_node)
+   {
+ arg3 = resolve_nondeduced_context_or_error (arg3, complain);
+ arg3_type = TREE_TYPE (arg3);
+   }
+
   /* [expr.cond]
 
 One of the following shall hold:
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index e4f76478f54..48c180cc13b 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21147,6 +21147,21 @@ resolve_nondeduced_context (tree orig_expr, 
tsubst_flags_t complain)
   return orig_expr;
 }
 
+/* As above, but error out if the expression remains overloaded.  */
+
+tree
+resolve_nondeduced_context_or_error (tree exp, tsubst_flags_t complain)
+{
+  exp = resolve_nondeduced_context (exp, complain);
+  if (type_unknown_p (exp))
+{
+  if (complain & tf_error)
+   cxx_incomplete_type_error (exp, TREE_TYPE (exp));
+  return error_mark_node;
+}
+  return exp;
+}
+
 /* Subroutine of resolve_overloaded_unification; does deduction for a single
overload.  Fills TARGS with any deduced arguments, or error_mark_node if
different overloads deduce different arguments for a given parm.
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index fc61991de35..2fff2625bee 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -2009,13 +2009,7 @@ decay_conversion (tree exp,
   if (type == error_mark_node)
 return error_mark_node;
 
-  exp = resolve_nondeduced_context (exp, complain);
-  if (type_unknown_p (exp))
-{
-  if (complain & tf_error)
-   cxx_incomplete_type_error (exp, TREE_TYPE (exp));
-  return error_mark_node;
-}
+  exp = resolve_nondeduced_context_or_error (exp, complain);
 
   code = TREE_CODE (type);
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/cond2.C 
b/gcc/testsuite/g++.dg/cpp0x/cond2.C
new file mode 100644
index 000..ec82dee10b7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/cond2.C
@@ -0,0 +1,14 @@
+// PR c++/86205
+// { dg-do compile { target c++11 } }
+
+bool b;
+
+template < class T > int f ()
+{
+  return 0;
+}
+
+template < class T > auto g () -> decltype (b ? f < int > : throw 0)
+{
+  return b ? f : throw 0;
+}
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 01a57601f4c..3fb1a895b5a 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,10 @@
 2019-01-17  Jason Merrill  
 
+   PR c++/86205 - ICE with ?: of throw and template-id.
+   * pt.c (resolve_nondeduced_context_or_error): Split out from...
+   * typeck.c (decay_conversion): ...here.
+   * call.c (build_conditional_expr_1): Use it.
+
PR c++/86740, ICE with constexpr if and nested generic lambdas.
* tree.c (cp_walk_subtrees): Handle LAMBDA_EXPR.
 

base-commit: 978cfaf23536dc8eefd4fe79c38f564de931e1af
-- 
2.20.1



[SVE ACLE] Implements svmulh

2019-01-17 Thread Kugan Vivekanandarajah
I committed the following patch which implements svmulh to
aarch64/sve-acle-branch. branch

Thanks,
Kugan
From 33b76de8ef5f370dfacba0addef2fe0b1f2a61db Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Fri, 18 Jan 2019 07:33:26 +1100
Subject: [PATCH] [SVE ACLE] Implements svmulh

Change-Id: Iaf4bd9898f46a53950e574750f68bdc709adbc1d
---
 gcc/config/aarch64/aarch64-sve-builtins.c  |  14 ++
 gcc/config/aarch64/aarch64-sve.md  |  50 +++-
 gcc/config/aarch64/iterators.md|   2 +
 .../gcc.target/aarch64/sve-acle/asm/mulh_s16.c | 254 +
 .../gcc.target/aarch64/sve-acle/asm/mulh_s32.c | 254 +
 .../gcc.target/aarch64/sve-acle/asm/mulh_s64.c | 254 +
 .../gcc.target/aarch64/sve-acle/asm/mulh_s8.c  | 254 +
 .../gcc.target/aarch64/sve-acle/asm/mulh_u16.c | 254 +
 .../gcc.target/aarch64/sve-acle/asm/mulh_u32.c | 254 +
 .../gcc.target/aarch64/sve-acle/asm/mulh_u64.c | 254 +
 .../gcc.target/aarch64/sve-acle/asm/mulh_u8.c  | 254 +
 gcc/tree-core.h|   8 +-
 12 files changed, 2101 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/mulh_s16.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/mulh_s32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/mulh_s64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/mulh_s8.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/mulh_u16.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/mulh_u32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/mulh_u64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/mulh_u8.c

diff --git a/gcc/config/aarch64/aarch64-sve-builtins.c b/gcc/config/aarch64/aarch64-sve-builtins.c
index c039ceb..b1deee9 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins.c
+++ b/gcc/config/aarch64/aarch64-sve-builtins.c
@@ -169,6 +169,7 @@ enum function {
   FUNC_svmls,
   FUNC_svmsb,
   FUNC_svmul,
+  FUNC_svmulh,
   FUNC_svneg,
   FUNC_svnot,
   FUNC_svptrue,
@@ -463,6 +464,7 @@ private:
   rtx expand_mla ();
   rtx expand_mls ();
   rtx expand_mul ();
+  rtx expand_mulh ();
   rtx expand_neg ();
   rtx expand_not ();
   rtx expand_ptrue ();
@@ -1088,6 +1090,7 @@ arm_sve_h_builder::get_attributes (const function_instance &instance)
 case FUNC_svmls:
 case FUNC_svmsb:
 case FUNC_svmul:
+case FUNC_svmulh:
 case FUNC_svneg:
 case FUNC_svnot:
 case FUNC_svqadd:
@@ -1700,6 +1703,7 @@ gimple_folder::fold ()
 case FUNC_svmls:
 case FUNC_svmsb:
 case FUNC_svmul:
+case FUNC_svmulh:
 case FUNC_svneg:
 case FUNC_svnot:
 case FUNC_svqadd:
@@ -1808,6 +1812,9 @@ function_expander::expand ()
 case FUNC_svmul:
   return expand_mul ();
 
+case FUNC_svmulh:
+  return expand_mulh ();
+
 case FUNC_svneg:
   return expand_neg ();
 
@@ -2033,6 +2040,13 @@ function_expander::expand_mul ()
 return expand_via_pred_direct_optab (cond_smul_optab);
 }
 
+/* Expand a call to svmulh.  */
+rtx
+function_expander::expand_mulh ()
+{
+  return expand_signed_pred_op (UNSPEC_SMUL_HIGHPART, UNSPEC_UMUL_HIGHPART, 0);
+}
+
 /* Expand a call to svneg.  */
 rtx
 function_expander::expand_neg ()
diff --git a/gcc/config/aarch64/aarch64-sve.md b/gcc/config/aarch64/aarch64-sve.md
index 944de82..6944d2b 100644
--- a/gcc/config/aarch64/aarch64-sve.md
+++ b/gcc/config/aarch64/aarch64-sve.md
@@ -1210,7 +1210,7 @@
 )
 
 ;; Predicated highpart multiplication.
-(define_insn "*mul3_highpart"
+(define_insn "@aarch64_pred_"
   [(set (match_operand:SVE_I 0 "register_operand" "=w, ?&w")
 	(unspec:SVE_I
 	  [(match_operand: 1 "register_operand" "Upl, Upl")
@@ -1225,6 +1225,54 @@
   [(set_attr "movprfx" "*,yes")]
 )
 
+;; Predicated MULH with select.
+(define_expand "@cond_"
+  [(set (match_operand:SVE_I 0 "register_operand")
+	(unspec:SVE_I
+	  [(match_operand: 1 "register_operand")
+	   (unspec:SVE_I
+	 [(match_operand:SVE_I 2 "register_operand")
+	  (match_operand:SVE_I 3 "register_operand")]
+	 MUL_HIGHPART)
+	   (match_operand:SVE_I 4 "aarch64_simd_reg_or_zero")]
+	  UNSPEC_SEL))]
+  "TARGET_SVE"
+)
+
+;; Predicated MULH with select matching the first input.
+(define_insn "*cond__2"
+  [(set (match_operand:SVE_I 0 "register_operand" "=w, ?&w")
+	(unspec:SVE_I
+	  [(match_operand: 1 "register_operand" "Upl, Upl")
+	   (unspec:SVE_I
+	 [(match_operand:SVE_I 2 "register_operand" "0, w")
+	  (match_operand:SVE_I 3 "register_operand" "w, w")]
+	 MUL_HIGHPART)
+	   (match_dup 2)]
+	  UNSPEC_SEL))]
+  "TARGET_SVE"
+  "@
+   mulh\t%0., %1/m, %0., %3.
+   movprfx\t%0, %2\;mulh\t%0., %1/m, %0., %3."
+  [(set_attr "movprfx" "*,yes")])
+
+;; Predicated MULH with select matching zero.
+(define

[SVE ACLE] Implements svdot

2019-01-17 Thread Kugan Vivekanandarajah
I committed the following patch which implements  svdot to
aarch64/sve-acle-branch. branch

Thanks,
Kugan
From b75cd8ba8f911c137380677b85882c22a6467bf6 Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Fri, 18 Jan 2019 09:07:10 +1100
Subject: [PATCH] [SVE ACLE] Implements svdot

Change-Id: I9d9f77f814a62e03db2ccd749f41bd35fea16035
---
 gcc/config/aarch64/aarch64-sve-builtins.c  | 148 +
 gcc/config/aarch64/aarch64-sve-builtins.def|   1 +
 gcc/config/aarch64/aarch64-sve.md  |  14 ++
 gcc/config/aarch64/iterators.md|   6 +-
 .../aarch64/sve-acle/general-c++/dot_1.C   |   9 ++
 .../aarch64/sve-acle/general-c++/dot_2.C   |  17 +++
 .../gcc.target/aarch64/sve-acle/asm/dot_s32.c  | 111 
 .../gcc.target/aarch64/sve-acle/asm/dot_s64.c  | 111 
 .../gcc.target/aarch64/sve-acle/asm/dot_u32.c  | 111 
 .../gcc.target/aarch64/sve-acle/asm/dot_u64.c  | 111 
 .../aarch64/sve-acle/asm/test_sve_acle.h   |  48 +++
 .../gcc.target/aarch64/sve-acle/general-c/dot_1.c  |  13 ++
 .../gcc.target/aarch64/sve-acle/general-c/dot_2.c  |  15 +++
 13 files changed, 714 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.target/aarch64/sve-acle/general-c++/dot_1.C
 create mode 100644 gcc/testsuite/g++.target/aarch64/sve-acle/general-c++/dot_2.C
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/dot_s32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/dot_s64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/dot_u32.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/asm/dot_u64.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/general-c/dot_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/sve-acle/general-c/dot_2.c

diff --git a/gcc/config/aarch64/aarch64-sve-builtins.c b/gcc/config/aarch64/aarch64-sve-builtins.c
index 35ed531..f080a67 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins.c
+++ b/gcc/config/aarch64/aarch64-sve-builtins.c
@@ -115,6 +115,10 @@ enum function_shape {
  sv_t svfoo[_n_t0](sv_t, sv_t, _t).  */
   SHAPE_ternary_opt_n,
 
+  /* sv_t svfoo[_t0](sv_t, sv_t, sv_t)
+ sv_t svfoo[_n_t0](sv_t, sv_t, _t).  */
+  SHAPE_ternary_qq_opt_n,
+
   /* sv_t svfoo[_n_t0])(sv_t, uint64_t)
 
  The final argument must be an integer constant expression in the
@@ -161,6 +165,7 @@ enum function {
   FUNC_svasrd,
   FUNC_svdiv,
   FUNC_svdivr,
+  FUNC_svdot,
   FUNC_svdup,
   FUNC_sveor,
   FUNC_svindex,
@@ -261,6 +266,8 @@ struct GTY(()) function_instance {
 
   tree scalar_type (unsigned int) const;
   tree vector_type (unsigned int) const;
+  tree quarter_vector_type (unsigned int i) const;
+  tree quarter_scalar_type (unsigned int i) const;
 
   /* The explicit "enum"s are required for gengtype.  */
   enum group_id group;
@@ -321,7 +328,9 @@ private:
   void sig_000 (const function_instance &, vec &);
   void sig_n_000 (const function_instance &, vec &);
   void sig_ (const function_instance &, vec &);
+  void sig_qq_ (const function_instance &, vec &);
   void sig_n_ (const function_instance &, vec &);
+  void sig_qq_n_ (const function_instance &, vec &);
   void sig_n_00i (const function_instance &, vec &);
 
   void apply_predication (const function_instance &, vec &);
@@ -361,6 +370,7 @@ public:
 
 private:
   tree resolve_uniform (unsigned int);
+  tree resolve_dot ();
   tree resolve_uniform_imm (unsigned int, unsigned int);
 
   bool check_first_vector_argument (unsigned int, unsigned int &,
@@ -459,6 +469,7 @@ private:
   rtx expand_and ();
   rtx expand_asrd ();
   rtx expand_div (bool);
+  rtx expand_dot ();
   rtx expand_dup ();
   rtx expand_eor ();
   rtx expand_index ();
@@ -618,6 +629,7 @@ DEF_SVE_TYPES_ARRAY (all_integer);
 DEF_SVE_TYPES_ARRAY (all_data);
 DEF_SVE_TYPES_ARRAY (all_sdi_and_float);
 DEF_SVE_TYPES_ARRAY (all_signed_and_float);
+DEF_SVE_TYPES_ARRAY (sdi);
 
 /* Used by functions in aarch64-sve-builtins.def that have no governing
predicate.  */
@@ -668,6 +680,43 @@ find_vector_type (const_tree type)
   return NUM_VECTOR_TYPES;
 }
 
+/* Return the type suffix associated with integer elements that have
+   ELEM_BITS bits and the signedness given by UNSIGNED_P.  Return
+   NUM_TYPE_SUFFIXES if no such element exists.  */
+static type_suffix
+maybe_find_integer_type_suffix (bool unsigned_p, unsigned int elem_bits)
+{
+  for (unsigned int i = 0; i < NUM_TYPE_SUFFIXES; ++i)
+{
+  if (type_suffixes[i].integer_p
+	  && type_suffixes[i].unsigned_p == unsigned_p
+	  && type_suffixes[i].elem_bits == elem_bits)
+	return type_suffix (i);
+}
+  return NUM_TYPE_SUFFIXES;
+}
+
+/* Return the type suffix for elements that are a quarter the size of integer
+   type suffix TYPE.  Return NUM_TYPE_SUFFIXES if no such element exists.  */
+static type_suffix
+maybe_find_quarter_type_suffix (type_suffi

[PATCH] Add myself to MAINTAINERS

2019-01-17 Thread Li Jia He

Hi,

this adds myself to MAINTAINERS in the Write After Approval section.

Committed to trunk as 268059.


---

Index: ChangeLog
===
--- ChangeLog    (revision 268058)
+++ ChangeLog    (working copy)
@@ -1,3 +1,7 @@
+2019-01-18  Li Jia He  
+
+    * MAINTAINERS (Write After Approval): Add myself.
+
 2019-01-17  Andrew Stubbs  
     Kwok Cheung Yeung  
     Julian Brown  
Index: MAINTAINERS
===
--- MAINTAINERS    (revision 268058)
+++ MAINTAINERS    (working copy)
@@ -409,6 +409,7 @@
 Pat Haugen                    
 Michael Hayes 
 Alan Hayward                    
+Li Jia He                    
 Mark Heffernan                    
 George Helffrich                
 Daniel Hellstrom                



[C++ PATCH] [PR87770] test partial specializations for type dependence

2019-01-17 Thread Alexandre Oliva
When instantiating a partial specialization of a template member
function for a full specialization of a class template, we test
whether the context of variables local to the partial specialization,
i.e., the partial specialization itself, is dependent, and this ICEs
in type_dependent_expression_p, when checking that the function type
isn't type-dependent because it is not in a type-dependent scope.

We shouldn't have got that far: the previous block in
type_dependent_expression_p catches cases in which the function itself
takes template arguments of its own, but it only did so for primary
templates, not for partial specializations.  This patch fixes that.

Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?


for  gcc/cp/ChangeLog

PR c++/87770
* pt.c (type_dependent_expression_p): Check partial
specializations for taking template arguments.

for  gcc/testsuite/ChangeLog

PR c++/87770
* g++.dg/pr87770.C: New.
---
 gcc/cp/pt.c|3 ++-
 gcc/testsuite/g++.dg/pr87770.C |   11 +++
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/pr87770.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index e4f76478f543..fb8993f1959e 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25607,7 +25607,8 @@ type_dependent_expression_p (tree expression)
 that come from the template-id; the template arguments for the
 enclosing class do not make it type-dependent unless they are used in
 the type of the decl.  */
-  if (PRIMARY_TEMPLATE_P (DECL_TI_TEMPLATE (expression))
+  if ((PRIMARY_TEMPLATE_P (DECL_TI_TEMPLATE (expression))
+  || DECL_TEMPLATE_SPECIALIZATION (DECL_TI_TEMPLATE (expression)))
  && (any_dependent_template_arguments_p
  (INNERMOST_TEMPLATE_ARGS (DECL_TI_ARGS (expression)
return true;
diff --git a/gcc/testsuite/g++.dg/pr87770.C b/gcc/testsuite/g++.dg/pr87770.C
new file mode 100644
index ..69eff4a786fe
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr87770.C
@@ -0,0 +1,11 @@
+// { dg-do compile }
+
+template  struct d {
+  template  d(e);
+};
+template <> template  d::d(e);
+template <> template  d::d(e) {
+  long g;
+  (void)g;
+}
+template d::d(char);


-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe


Re: [PATCH] Read avx512vl-vfixupimms*-2.c testcases (PR target/88489)

2019-01-17 Thread Uros Bizjak
On Fri, Jan 18, 2019 at 3:42 AM Wei Xiao  wrote:
>
> > > > For r267160, I'd expect you want to revert just the config/i386/ part 
> > > > and
> > > > keep the testcases, they should work even with the changes reverted, 
> > > > right?
> > > >
> > > The testcase part also need to be reverted since we have changed them
> > > according to the incorrect intrinsic list in SDM.
> >
> > I don't really understand this.
> >
> > The testcases succeed just fine for me in the current trunk with all the
> > reversions and test something the current state of the testsuite doesn't
> > check normally, in particular that the testcases run correctly even when
> > -mavx512vl is used.  As that misbehaved in the past, we should make sure we
> > don't break that again.
> >
>
> You're right. The testcases need to be kept to prevent regression.
>
> > Uros, is it ok to reapply this to current trunk?

Yes, please reapply the tests.

Thanks,
Uros.