Re: [PATCH, Fortran, pr78672, ctp1, v1] Gfortran test suite failures with a sanitized compiler

[Mikael Morin]

Hello,

Le 08/12/2016 à 23:49, Mikael Morin a écrit :

Le 08/12/2016 à 14:39, Andre Vehreschild a écrit :

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 2e6ef2a..8173ba9 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1019,7 +1019,7 @@ gfc_build_qualified_array (tree decl, gfc_symbol
* sym)
   layout_type (type);
 }

-  if (TYPE_NAME (type) != NULL_TREE
+  if (TYPE_NAME (type) != NULL_TREE && as->rank > 0

I suppose one should replace as->rank with as->rank + as->corank instead
of this.


I remember now that rank can be negative, so your change is fine.


   && GFC_TYPE_ARRAY_UBOUND (type, as->rank - 1) != NULL_TREE
   && VAR_P (GFC_TYPE_ARRAY_UBOUND (type, as->rank - 1)))
 {



Mikael

Re: [PATCH] [AArch64] PR target/71663 Improve Vector Initializtion

[Hurugalawadi, Naveen]

Hi,

Sorry. Missed out the testcase in patch submission.
Added the missing testcase along with the ChangeLog.
Please review the same and let us know if thats okay?

2016-12-09  Andrew PInski  

gcc
    * config/aarch64/aarch64.c (aarch64_expand_vector_init):
    Improve vector initialization code gen.
gcc/testsuite
* gcc.target/aarch64/pr71663.c: New Testcase.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index e87831f..da5b6fa 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11609,11 +11609,54 @@ aarch64_expand_vector_init (rtx target, rtx vals)
   aarch64_expand_vector_init (target, copy);
 }
 
-  /* Insert the variable lanes directly.  */
-
   enum insn_code icode = optab_handler (vec_set_optab, mode);
   gcc_assert (icode != CODE_FOR_nothing);
 
+  /* If there is only varables, try to optimize
+ the inseration using dup for the most common element
+ followed by insertations. */
+  if (n_var == n_elts && n_elts <= 16)
+{
+  int matches[16][2];
+  int nummatches = 0;
+  memset (matches, 0, sizeof(matches));
+  for(int i = 0; i < n_elts; i++)
+	{
+	  for (int j = 0; j <= i; j++)
+	{
+	  if (rtx_equal_p (XVECEXP (vals, 0, i), XVECEXP (vals, 0, j)))
+		{
+		  matches[i][0] = j;
+		  matches[j][1]++;
+		  if (i != j)
+		nummatches++;
+		  break;
+		}
+	}
+	}
+  int maxelement = 0;
+  int maxv = 0;
+  for (int i = 0; i < n_elts; i++)
+	if (matches[i][1] > maxv)
+	  maxelement = i, maxv = matches[i][1];
+
+  /* Create a duplicate of the most common element. */
+  rtx x = copy_to_mode_reg (inner_mode, XVECEXP (vals, 0, maxelement));
+  aarch64_emit_move (target, gen_rtx_VEC_DUPLICATE (mode, x));
+  /* Insert the rest. */
+  for (int i = 0; i < n_elts; i++)
+	{
+	  rtx x = XVECEXP (vals, 0, i);
+	  if (matches[i][0] == maxelement)
+	continue;
+	  x = copy_to_mode_reg (inner_mode, x);
+	  emit_insn (GEN_FCN (icode) (target, x, GEN_INT (i)));
+	}
+  return;
+}
+
+  /* Insert the variable lanes directly.  */
+
   for (int i = 0; i < n_elts; i++)
 {
   rtx x = XVECEXP (vals, 0, i);
diff --git a/gcc/testsuite/gcc.target/aarch64/pr71663.c b/gcc/testsuite/gcc.target/aarch64/pr71663.c
new file mode 100644
index 000..c8df847
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr71663.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+#define vector __attribute__((vector_size(16)))
+
+vector float combine (float a, float b, float c, float d)
+{
+  return (vector float) { a, b, c, d };
+}
+
+/* { dg-final { scan-assembler-not "movi\t" } } */
+/* { dg-final { scan-assembler-not "orr\t" } } */
+/* { dg-final { scan-assembler-times "ins\t" 3 } } */
+/* { dg-final { scan-assembler-times "dup\t" 1 } } */

Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413

[kugan]

Hi Martin,

On 07/12/16 21:08, Martin Jambor wrote:

Hello Kugan,

sorry, I have lost track of this patch and re-discovered it only now.

On Mon, Nov 28, 2016 at 04:25:00PM +1100, kugan wrote:

Hi,

On 24/11/16 19:48, Richard Biener wrote:

On Wed, Nov 23, 2016 at 4:33 PM, Martin Jambor  wrote:

Hi,

On Fri, Nov 18, 2016 at 12:38:18PM +1100, kugan wrote:

Hi,

I was relying on ipa_get_callee_param_type to get type of parameter and then
convert arguments to this type while computing jump functions. However, in
cases like shown in PR78365, ipa_get_callee_param_type, instead of giving
up, would return the wrong type.


At what stage does this happen?  During analysis
(ipa_compute_jump_functions_for_edge) or at WPA
(propagate_constants_accross_call)?  Both?


Hmm, where does jump function compute require the callee type?
In my view the jump function should record

 (expected-incoming-type) arg [OP X]

for each call argument in its body.  Thus required conversions are
done at WPA propagation time.


I think the current uses of
ipa_get_callee_param_type are fine with this.

Attached patch now uses callee's DECL_ARGUMENTS to get the type. If it
cannot be found, then I would give up and set the jump function to varying.


But DECL_ARGUMENTS is not available at WPA stage with LTO so your
patch would make our IPA layer to optimize less with LTO.  This was
the reason to go through the hoops of TYPE_ARG_TYPES in the first
place.

If TYPE_ARG_TYPES cannot be trusted, then I'm afraid we are back to
square one and indeed need to put the correct type in jump functions.


If DECL_ARGUMENTS is not available at WPA stage then I see no other
way than to put the types on the jump functions.


Here is a patch that does this. To fox PR78365, in
ipa_get_callee_param_type, I am now checking DECL_ARGUMENTS first. I lto
bootstrapped and regression tested on x86_64-linux-gnu and ppc64le-linux
with no new regressions. I will build Firefox and measure the memory usage
as Honza suggested based on the feedback.



So, do you have any numbers?
I will do it. How do you measure the gcc's memory usage while building 
Firefox. I saw Honza's LTO blog talks about using vmstat result. Any 
tips please?






diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 2ec671f..3d50041 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1846,11 +1846,11 @@ propagate_bits_accross_jump_function (cgraph_edge *cs, 
int idx, ipa_jump_func *j
 static bool
 propagate_vr_accross_jump_function (cgraph_edge *cs,
ipa_jump_func *jfunc,
-   struct ipcp_param_lattices *dest_plats,
-   tree param_type)
+   struct ipcp_param_lattices *dest_plats)
 {
   struct ipcp_param_lattices *src_lats;
   ipcp_vr_lattice *dest_lat = _plats->m_value_range;
+  tree param_type = jfunc->param_type;

   if (dest_lat->bottom_p ())
 return false;
@@ -1895,9 +1895,9 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
   tree val = ipa_get_jf_constant (jfunc);
   if (TREE_CODE (val) == INTEGER_CST)
{
+ val = fold_convert (param_type, val);
  if (TREE_OVERFLOW_P (val))
val = drop_tree_overflow (val);
- val = fold_convert (param_type, val);
  jfunc->vr_known = true;
  jfunc->m_vr.type = VR_RANGE;
  jfunc->m_vr.min = val;
@@ -2247,7 +2247,6 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
 {
   struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
   struct ipcp_param_lattices *dest_plats;
-  tree param_type = ipa_get_callee_param_type (cs, i);

   dest_plats = ipa_get_parm_lattices (callee_info, i);
   if (availability == AVAIL_INTERPOSABLE)
@@ -2264,8 +2263,7 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
   dest_plats);
  if (opt_for_fn (callee->decl, flag_ipa_vrp))
ret |= propagate_vr_accross_jump_function (cs,
-  jump_func, dest_plats,
-  param_type);
+  jump_func, dest_plats);
  else
ret |= dest_plats->m_value_range.set_to_bottom ();
}
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 90c19fc..235531b 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1651,14 +1651,24 @@ determine_locally_known_aggregate_parts (gcall *call, 
tree arg,
 /* Return the Ith param type of callee associated with call graph
edge E.  */

-tree
+static tree
 ipa_get_callee_param_type (struct cgraph_edge *e, int i)
 {
   int n;
+  tree t = e->callee ? DECL_ARGUMENTS (e->callee->decl) : NULL_TREE;
+  if (t)
+for (n = 0; n < i; n++)
+  {
+   if (!t)
+ return NULL;
+   t = TREE_CHAIN (t);
+  }
+  if (t)
+return TREE_TYPE (t);
   tree type = 

[PATCH] Fix PR78721

[kugan]

Hi,

in propagate_vr_accross_jump_function, drop_tree_overflow should be 
after fold_convert. Attached patch changes this.


Bootstrapped and regression tested on x86_64-linux-gnu with no new 
regressions. Is this OK for trunk?


Thanks,
Kugan

gcc/testsuite/ChangeLog:

2016-12-09  Kugan Vivekanandarajah  

PR ipa/78721
* gcc.dg/pr78721.c: New test.


gcc/ChangeLog:

2016-12-09  Kugan Vivekanandarajah  

PR ipa/78721
* ipa-cp.c (propagate_vr_accross_jump_function): drop_tree_overflow
after fold_convert.










diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 2ec671f..4ec7cc5 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1895,9 +1895,9 @@ propagate_vr_accross_jump_function (cgraph_edge *cs,
   tree val = ipa_get_jf_constant (jfunc);
   if (TREE_CODE (val) == INTEGER_CST)
{
+ val = fold_convert (param_type, val);
  if (TREE_OVERFLOW_P (val))
val = drop_tree_overflow (val);
- val = fold_convert (param_type, val);
  jfunc->vr_known = true;
  jfunc->m_vr.type = VR_RANGE;
  jfunc->m_vr.min = val;
diff --git a/gcc/testsuite/gcc.dg/pr78721.c b/gcc/testsuite/gcc.dg/pr78721.c
index e69de29..fb2ffc3 100644
--- a/gcc/testsuite/gcc.dg/pr78721.c
+++ b/gcc/testsuite/gcc.dg/pr78721.c
@@ -0,0 +1,23 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+int a, b, c;
+
+int fn1 (char e, char f)
+{
+  return !f || (e && f == 1);
+}
+
+void fn2 (char e)
+{
+  while (b)
+e = 0;
+  a = 128;
+  c = fn1 (e, a == e);
+}
+
+int main ()
+{
+  fn2 (0);
+  return 0;
+}

[PATCH] [AArch64] PR target/71663 Improve Vector Initializtion

[Hurugalawadi, Naveen]

Hi,

The AArch64 vector initialization sequence can be optimized to generate
better code. The attached patch handles for the case where the vector
contains only variables. It checks for the common elements in the vector
and inserts the values in optimized way.

Bootstrapped and Regression tested on aarch64-thunder-linux.
Please review the patch and let us know if its okay?

2016-12-09  Andrew PInski  

gcc
* config/aarch64/aarch64.c (aarch64_expand_vector_init):
Improve vector initialization code gen.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index e87831f..da5b6fa 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -11609,11 +11609,54 @@ aarch64_expand_vector_init (rtx target, rtx vals)
   aarch64_expand_vector_init (target, copy);
 }
 
-  /* Insert the variable lanes directly.  */
-
   enum insn_code icode = optab_handler (vec_set_optab, mode);
   gcc_assert (icode != CODE_FOR_nothing);
 
+  /* If there is only varables, try to optimize
+ the inseration using dup for the most common element
+ followed by insertations. */
+  if (n_var == n_elts && n_elts <= 16)
+{
+  int matches[16][2];
+  int nummatches = 0;
+  memset (matches, 0, sizeof(matches));
+  for(int i = 0; i < n_elts; i++)
+	{
+	  for (int j = 0; j <= i; j++)
+	{
+	  if (rtx_equal_p (XVECEXP (vals, 0, i), XVECEXP (vals, 0, j)))
+		{
+		  matches[i][0] = j;
+		  matches[j][1]++;
+		  if (i != j)
+		nummatches++;
+		  break;
+		}
+	}
+	}
+  int maxelement = 0;
+  int maxv = 0;
+  for (int i = 0; i < n_elts; i++)
+	if (matches[i][1] > maxv)
+	  maxelement = i, maxv = matches[i][1];
+
+  /* Create a duplicate of the most common element. */
+  rtx x = copy_to_mode_reg (inner_mode, XVECEXP (vals, 0, maxelement));
+  aarch64_emit_move (target, gen_rtx_VEC_DUPLICATE (mode, x));
+  /* Insert the rest. */
+  for (int i = 0; i < n_elts; i++)
+	{
+	  rtx x = XVECEXP (vals, 0, i);
+	  if (matches[i][0] == maxelement)
+	continue;
+	  x = copy_to_mode_reg (inner_mode, x);
+	  emit_insn (GEN_FCN (icode) (target, x, GEN_INT (i)));
+	}
+  return;
+}
+
+  /* Insert the variable lanes directly.  */
+
   for (int i = 0; i < n_elts; i++)
 {
   rtx x = XVECEXP (vals, 0, i);

Re: [PATCH, rs6000] Use new pass registration framework for analyze_swaps

[Segher Boessenkool]

On Thu, Dec 08, 2016 at 04:53:55PM -0600, Bill Schmidt wrote:
> Back in October
> (https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00256.html), Jakub
> updated the target pass registration framework so that target passes act
> more like regular passes:  their dumps are numbered in proper order, and
> use of dump options like -details now works.  I've finally gotten around
> to updating the rs6000 back end to take advantage of this.
> 
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions.  I've verified that the "swaps" dump now appears with
> proper numbering:
> 
> -rw-rw-r--  1 wschmidt wschmidt 3815 Dec  8 16:40 
> swaps-p8-17.c.232r.dfinit
> -rw-rw-r--  1 wschmidt wschmidt 5092 Dec  8 16:40 swaps-p8-17.c.233r.swaps
> -rw-rw-r--  1 wschmidt wschmidt 9751 Dec  8 16:40 swaps-p8-17.c.234r.cse1
> 
> Is this ok for trunk?

Yes please.  Thanks,


Segher


> 2016-12-08  Bill Schmidt  
> 
>   * config/rs6000/rs6000-passes.def: New file.
>   * config/rs6000/rs6000-protos.h: Declare make_pass_analyze_swaps.
>   * config/rs6000/rs6000.c (rs6000_option_override): Remove
>   registration of machine-specific passes.
>   (pass_analyze_swaps::clone): New function.
>   * config/rs6000/t-rs6000: Define PASSES_EXTRA.

Re: [PATCH, rs6000] Add support for vec_pack and vec_sld built-ins

[Segher Boessenkool]

On Thu, Dec 08, 2016 at 08:28:22AM -0800, Carl E. Love wrote:
> The following patch adds two more built-ins that are missing.
> Specifically:
> 
> vector floatvec_packvector doublevector double
> vector double   vec_sld vector doublevector double
> 
> The patch has been boot strapped and tested on
> powerpc64le-unknown-linux-gnu (Power 8) and on 
> powerpc64-unknown-linux-gnu (Power 7) with no regressions.

> 2016-12-08  Carl Love  
> 
>* config/rs6000/rs6000-c.c: Add built-in support for
>vector float  vec_pack  vector double  vector double
>vector double  vec_sld  vector double  vector double

Add some parens and commas here?

>* config/rs6000/rs6000.c: Add icode check for vsldoi_v2df to allow
>4-bit unsigned literal.
>* config/rs6000/rs6000-builtin.def: Add definition for VSLDOI_2DF
>* doc/extend.texi: Update the built-in documentation file for the
>new powerpc vec_pack and vec_sld built-ins.

Okay for trunk with that.  Thanks,


Segher

Re: [PATCH, rs6000] whitespace fix for p9-dimode tests

[Segher Boessenkool]

Hello,

On Thu, Dec 08, 2016 at 10:18:42AM -0600, Will Schmidt wrote:
> I am seeing some failures in the p9-dimode tests. This appears to
> be due to the scan-assembler strings matching comment portions of the
> generated assembly, versus the actual generated assembly. In
> particular, the dg-final directive  { scan-assembler-not "ld"}
> is matching the "ld" as seen in the string
>   # 19 "/home/willschm/gcc/gcc-mainline-vec_fold/..."
> 
> This is resolved by adding a leading whitespace regex string "\[ \t\]"
> as seen in other tests.

That works; a more future-proof way is writing it as

/* { dg-final { scan-assembler-not {\mld\M}   } } */

which will also not match a future "ldlol" instruction (\m \M are like
\< \> in some other regular expression dialects; see
https://www.tcl.tk/man/tcl8.4/TclCmd/re_syntax.htm ).

Okay either way.  Thanks,


Segher

Re: [PATCH, rs6000] Fix 32-bit BE failure for gcc.target/powerpc/fold-vec-add-7.c

[Segher Boessenkool]

On Wed, Dec 07, 2016 at 09:05:13PM -0600, Bill Schmidt wrote:
> Andreas Schwab observed that the subject test case fails on 32-bit big-endian
> because the test is not restricted to targets that support __int128.  This
> patch rectifies that.
> 
> Tested on powerpc64-unknown-linux-gnu and verified that the test is flagged
> as unsupported for BE, but runs correctly on LE.  Tested on powerpc64le-
> unknown-linux-gnu and verified that the test runs correctly there.  Is this
> ok for trunk?

Yes, thanks!


Segher


> 2016-12-07  Bill Schmidt  
> 
>   * gcc.target/powerpc/fold-vec-add-7.c: Require effective target to
>   support __int128.

Re: [PATCH 5/9] Introduce selftest::locate_file (v4)

[Bernd Schmidt]

On 12/08/2016 10:47 PM, David Malcolm wrote:


Is (A) OK, or would you prefer (B)?   (I prefer (A) fwiw)


Oh well, just keep it as it is.


Bernd

Re: [PATCH] Prevent use of MEM_* attr accessor macros as lvalues

[Bernd Schmidt]

On 12/09/2016 03:02 AM, David Malcolm wrote:

The following patch leads to errors like this for that kind
of mistake:

error: assignment of member 'mem_attrs::offset' in read-only object
MEM_OFFSET (x) = atoi (name.string);
  ^

Successfully bootstrapped on x86_64-pc-linux-gnu.


That easy? Nice. A quick grep through the ports shows nothing of 
concern, so OK.



Bernd

[PATCH] Prevent use of MEM_* attr accessor macros as lvalues

[David Malcolm]

On Thu, 2016-12-08 at 21:08 +0100, Bernd Schmidt wrote:
> On 12/08/2016 09:39 PM, David Malcolm wrote:
> > 
> > OK as adjustments to patches 8a and 8b?
> 
> Ok. Is it possible to adjust these macros to return something like a
> const reference to ensure people can't make this kind of error?
> 
> 
> Bernd

The following patch leads to errors like this for that kind
of mistake:

error: assignment of member 'mem_attrs::offset' in read-only object
MEM_OFFSET (x) = atoi (name.string);
  ^

Successfully bootstrapped on x86_64-pc-linux-gnu.

OK for trunk?

gcc/ChangeLog:
* rtl.h (get_mem_attrs): Add "const" qualifier to returned
pointer.
---
 gcc/rtl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/rtl.h b/gcc/rtl.h
index a5efa28..4f0efa6 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -3355,7 +3355,7 @@ extern struct target_rtl *this_target_rtl;
 
 #ifndef GENERATOR_FILE
 /* Return the attributes of a MEM rtx.  */
-static inline struct mem_attrs *
+static inline const struct mem_attrs *
 get_mem_attrs (const_rtx x)
 {
   struct mem_attrs *attrs;
-- 
1.8.5.3

Re: [PATCH] Fix PR78027

[Jeff Law]

On 12/08/2016 04:05 PM, Cesar Philippidis wrote:

PR78027 was classified as a fortran bug, but the underlying problem
turned out to be more generic. Basically, the IPA-ICF pass usually
ignores functions with omp decl attributes as candidates for aliasing.
Usually that works for OpenACC, because offloaded functions generated by
OpenACC PARALLEL or KERNELS regions usually have an 'omp target
entrypoint' attribute. However that is not the case in two situations:

1. ACC ROUTINES do not have an 'omp target entrypoint' attribute.

2. Nested offloaded regions inside 'omp declare target' functions do not
have 'omp target entrypoint' attributes either.

The solution I chose for this problem is to teach the IPA-ICF pass to
ignore function with 'oacc *' decl attributes. Arguably 2) should be a
parser error when an OpenACC offloaded region is embedded within an
OpenMP offloaded function. The LTO linker does report an error for nvptx
targets, but not the host. With that in mind, this patch is still
necessary for case 1.

Is this OK for trunk?

Cesar


trunk-pr78027.diff


2016-12-08  Cesar Philippidis  

PR fortran/78027

gcc/
* ipa-icf.c (sem_function::parse): Don't process functions with
oacc decl attributes, as they may be OpenACC routines.

gcc/testsuite/
* c-c++-common/goacc/acc-icf.c: New test.
* gfortran.dg/goacc/pr78027.f90: New test.
This follows the same approach as we do for openmp.  This is fine for 
the trunk.


Jeff

Re: [PATCH] warn on overflow in calls to allocation functions (bugs 77531 and 78284)

[Martin Sebor]

+enabled with @option{-Wextra}.

So I think we should in the immediate term not enable this in Wextra.
However, I think for gcc-8 we should revisit after fixing GCC to be
cleaner WRT alloc-zero.

So disable alloc-zero by default, comment typo and potentially adding
the GTY marker to alloc_object_size_limit and this is OK.


Thanks.  Committed in r243470 with the changes above.

Martin

Re: [PATCH] Fix PR78027

[Steve Kargl]

On Thu, Dec 08, 2016 at 03:05:10PM -0800, Cesar Philippidis wrote:

> 2016-12-08  Cesar Philippidis  
> 
>   PR fortran/78027
> 
>   gcc/
>   * ipa-icf.c (sem_function::parse): Don't process functions with
>   oacc decl attributes, as they may be OpenACC routines.
> 
>   gcc/testsuite/
>   * c-c++-common/goacc/acc-icf.c: New test.
>   * gfortran.dg/goacc/pr78027.f90: New test.
> 

The Fortran testcase is OK.  I probably don't have the
necessary background to review the ipa-icf.c code changes.

-- 
Steve

[PATCH] Fix PR78027

[Cesar Philippidis]

PR78027 was classified as a fortran bug, but the underlying problem
turned out to be more generic. Basically, the IPA-ICF pass usually
ignores functions with omp decl attributes as candidates for aliasing.
Usually that works for OpenACC, because offloaded functions generated by
OpenACC PARALLEL or KERNELS regions usually have an 'omp target
entrypoint' attribute. However that is not the case in two situations:

1. ACC ROUTINES do not have an 'omp target entrypoint' attribute.

2. Nested offloaded regions inside 'omp declare target' functions do not
have 'omp target entrypoint' attributes either.

The solution I chose for this problem is to teach the IPA-ICF pass to
ignore function with 'oacc *' decl attributes. Arguably 2) should be a
parser error when an OpenACC offloaded region is embedded within an
OpenMP offloaded function. The LTO linker does report an error for nvptx
targets, but not the host. With that in mind, this patch is still
necessary for case 1.

Is this OK for trunk?

Cesar
2016-12-08  Cesar Philippidis  

	PR fortran/78027

	gcc/
	* ipa-icf.c (sem_function::parse): Don't process functions with
	oacc decl attributes, as they may be OpenACC routines.

	gcc/testsuite/
	* c-c++-common/goacc/acc-icf.c: New test.
	* gfortran.dg/goacc/pr78027.f90: New test.


diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index 553b81e..31061e9 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -1689,6 +1689,10 @@ sem_function::parse (cgraph_node *node, bitmap_obstack *stack)
   if (lookup_attribute_by_prefix ("omp ", DECL_ATTRIBUTES (node->decl)) != NULL)
 return NULL;
 
+  if (lookup_attribute_by_prefix ("oacc ",
+  DECL_ATTRIBUTES (node->decl)) != NULL)
+return NULL;
+
   /* PR ipa/70306.  */
   if (DECL_STATIC_CONSTRUCTOR (node->decl)
   || DECL_STATIC_DESTRUCTOR (node->decl))
diff --git a/gcc/testsuite/c-c++-common/goacc/acc-icf.c b/gcc/testsuite/c-c++-common/goacc/acc-icf.c
new file mode 100644
index 000..ecfe3f2
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/goacc/acc-icf.c
@@ -0,0 +1,49 @@
+/* Ensure that IPA-ICF is disabled on OpenACC routines.  */
+
+/* { dg-additional-options "-fopenacc -O2 -fdump-ipa-icf" }  */
+
+#pragma acc routine gang
+int
+routine1 (int n)
+{
+  int i;
+
+  #pragma acc loop
+  for (i = 0; i < n; i++)
+;
+
+  return n + 1;
+}
+
+#pragma acc routine gang
+int
+routine2 (int n)
+{
+  int i;
+
+  #pragma acc loop
+  for (i = 0; i < n; i++)
+;
+
+  return n + 1;
+}
+
+int
+main ()
+{
+  int i;
+
+  #pragma acc parallel loop
+  for (i = 0; i < 8; i++)
+;
+
+  #pragma acc parallel loop
+  for (i = 0; i < 8; i++)
+;
+
+  return 0;
+}
+
+/* { dg-final { scan-ipa-dump-times "Not parsed function:" 4 "icf" } }  */
+/* { dg-final { scan-ipa-dump "Parsed function:main" "icf" } }  */
+
diff --git a/gcc/testsuite/gfortran.dg/goacc/pr78027.f90 b/gcc/testsuite/gfortran.dg/goacc/pr78027.f90
new file mode 100644
index 000..db65063
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/pr78027.f90
@@ -0,0 +1,20 @@
+! { dg-additional-options "-fopenmp -O2 -fdump-ipa-icf" }
+
+real function f()
+   !$omp declare target(f)
+   f = 1.
+   !$acc parallel
+   !$acc loop
+   do i = 1, 8
+   end do
+   !$acc end parallel
+   !$acc parallel
+   !$acc loop
+   do i = 1, 8
+   end do
+   !$acc end parallel
+ end
+ 
+! { dg-final { scan-ipa-dump "Not parsed function:f_._omp_fn.1" "icf" } }
+! { dg-final { scan-ipa-dump "Not parsed function:f_._omp_fn.0" "icf" } }
+! { dg-final { scan-ipa-dump "Not parsed function:f_" "icf" } }

[PATCH] Add support for Fuchsia (OS)

[Josh Conner]

This patch adds support to gcc for the Fuchsia OS 
(https://fuchsia.googlesource.com/).


OK for mainline?

Thanks -

Josh


2016-12-08  Joshua Conner  


* config/arm/fuchsia-elf.h: New file.

* config/fuchsia.h: New file.

* config.gcc (*-*-fuchsia*): Set native_system_header_dir.

(aarch64*-*-fuchsia*, arm*-*-fuchsia*, x86_64-*-fuchsia*): Add to 
targets.


* config.host: (aarch64*-*-fuchsia*, arm*-*-fuchsia*): Add to hosts.


Index: gcc/config/arm/fuchsia-elf.h
===
--- gcc/config/arm/fuchsia-elf.h(revision 0)
+++ gcc/config/arm/fuchsia-elf.h(working copy)
@@ -0,0 +1,31 @@
+/* Configuration file for ARM Fuchsia ELF targets.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+   Contributed by Google.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+/* Use the BPABI builtins and the generic OS builtins.  */
+#undef  TARGET_SUB_OS_CPP_BUILTINS
+#define TARGET_SUB_OS_CPP_BUILTINS()   \
+  TARGET_BPABI_CPP_BUILTINS()
+
+/* Use the AAPCS ABI by default.  */
+#undef ARM_DEFAULT_ABI
+#define ARM_DEFAULT_ABI ARM_ABI_AAPCS
+
+#define ARM_TARGET2_DWARF_FORMAT (DW_EH_PE_pcrel | DW_EH_PE_indirect)
+
Index: gcc/config/fuchsia.h
===
--- gcc/config/fuchsia.h(revision 0)
+++ gcc/config/fuchsia.h(working copy)
@@ -0,0 +1,64 @@
+/* Base configuration file for all Fuchsia targets.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* Common Fuchsia configuration.  */
+
+#undef  STARTFILE_SPEC
+#define STARTFILE_SPEC "%{!shared: crt1%O%s} crtbegin%O%s"
+
+#undef  ENDFILE_SPEC
+#define ENDFILE_SPEC "crtend%O%s"
+
+/* Build with PIC by default.  */
+#undef  CC1_SPEC
+#define CC1_SPEC "%{!fno-pic:%{!fno-PIC:%{!fpic:%{!fPIC: -fPIC"
+
+#undef  LIB_SPEC
+#define LIB_SPEC "-lmxio -lmagenta -lc -llaunchpad" \
+"%{!static: -lgcc_s}"
+
+#undef  LINK_SPEC
+#define LINK_SPEC "-z max-page-size=4096" \
+ " -z combreloc" \
+ " -z relro" \
+ " -z now" \
+ " -z text" \
+ "%{!hash-style: --hash-style=gnu}" \
+ "%{!no-eh-frame-hdr: --eh-frame-hdr}" \
+ "%{!no-build-id: --build-id}" \
+ "%{shared: -shared}" \
+ "%{!shared:%{!static:%{!dynamic-linker: 
-dynamic-linker=ld.so.1}}}"
+
+/* We are using MUSL as our libc.  */
+#undef  OPTION_MUSL
+#define OPTION_MUSL 1
+
+#ifndef TARGET_SUB_OS_CPP_BUILTINS
+#define TARGET_SUB_OS_CPP_BUILTINS()
+#endif
+
+#undef  TARGET_OS_CPP_BUILTINS
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+  builtin_define ("__fuchsia__");  \
+  TARGET_SUB_OS_CPP_BUILTINS();\
+}  \
+  while (false)
+
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 243452)
+++ gcc/config.gcc  (working copy)
@@ -706,6 +706,9 @@
   esac
   use_gcc_stdint=wrap
   ;;
+*-*-fuchsia*)
+  native_system_header_dir=/include
+  ;;
 *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* | 
*-*-kopensolaris*-gnu)
   extra_options="$extra_options gnu-user.opt"
   gas=yes
@@ -908,7 +911,7 @@
 esac
 
 case ${target} in
-aarch64*-*-elf | aarch64*-*-rtems*)
+aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
tm_file="${tm_file} dbxelf.h elfos.h newlib-stdint.h"
tm_file="${tm_file} aarch64/aarch64-elf.h aarch64/aarch64-elf-raw.h"

[PATCH, rs6000] Use new pass registration framework for analyze_swaps

[Bill Schmidt]

Hi,

Back in October
(https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00256.html), Jakub
updated the target pass registration framework so that target passes act
more like regular passes:  their dumps are numbered in proper order, and
use of dump options like -details now works.  I've finally gotten around
to updating the rs6000 back end to take advantage of this.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  I've verified that the "swaps" dump now appears with
proper numbering:

-rw-rw-r--  1 wschmidt wschmidt 3815 Dec  8 16:40 swaps-p8-17.c.232r.dfinit
-rw-rw-r--  1 wschmidt wschmidt 5092 Dec  8 16:40 swaps-p8-17.c.233r.swaps
-rw-rw-r--  1 wschmidt wschmidt 9751 Dec  8 16:40 swaps-p8-17.c.234r.cse1

Is this ok for trunk?

Thanks,
Bill


2016-12-08  Bill Schmidt  

* config/rs6000/rs6000-passes.def: New file.
* config/rs6000/rs6000-protos.h: Declare make_pass_analyze_swaps.
* config/rs6000/rs6000.c (rs6000_option_override): Remove
registration of machine-specific passes.
(pass_analyze_swaps::clone): New function.
* config/rs6000/t-rs6000: Define PASSES_EXTRA.


Index: gcc/config/rs6000/rs6000-passes.def
===
--- gcc/config/rs6000/rs6000-passes.def (revision 0)
+++ gcc/config/rs6000/rs6000-passes.def (working copy)
@@ -0,0 +1,27 @@
+/* Description of target passes for rs6000
+   Copyright (C) 2016 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/*
+   Macros that can be used in this file:
+   INSERT_PASS_AFTER (PASS, INSTANCE, TGT_PASS)
+   INSERT_PASS_BEFORE (PASS, INSTANCE, TGT_PASS)
+   REPLACE_PASS (PASS, INSTANCE, TGT_PASS)
+ */
+
+  INSERT_PASS_BEFORE (pass_cse, 1, pass_analyze_swaps);
Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h   (revision 243441)
+++ gcc/config/rs6000/rs6000-protos.h   (working copy)
@@ -258,4 +258,11 @@ extern unsigned char rs6000_class_max_nregs[][LIM_
 extern unsigned char rs6000_hard_regno_nregs[][FIRST_PSEUDO_REGISTER];
 
 extern bool rs6000_linux_float_exceptions_rounding_supported_p (void);
+
+/* Pass management.  */
+namespace gcc { class context; }
+class rtl_opt_pass;
+
+extern rtl_opt_pass *make_pass_analyze_swaps (gcc::context *);
+
 #endif  /* rs6000-protos.h */
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 243441)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5203,15 +5203,6 @@ static void
 rs6000_option_override (void)
 {
   (void) rs6000_option_override_internal (true);
-
-  /* Register machine-specific passes.  This needs to be done at start-up.
- It's convenient to do it here (like i386 does).  */
-  opt_pass *pass_analyze_swaps = make_pass_analyze_swaps (g);
-
-  struct register_pass_info analyze_swaps_info
-= { pass_analyze_swaps, "cse1", 1, PASS_POS_INSERT_BEFORE };
-
-  register_pass (_swaps_info);
 }
 
 
@@ -41865,6 +41856,11 @@ class pass_analyze_swaps : public rtl_opt_pass
   return rs6000_analyze_swaps (fun);
 }
 
+  opt_pass *clone ()
+{
+  return new pass_analyze_swaps (m_ctxt);
+}
+
 }; // class pass_analyze_swaps
 
 rtl_opt_pass *
Index: gcc/config/rs6000/t-rs6000
===
--- gcc/config/rs6000/t-rs6000  (revision 243441)
+++ gcc/config/rs6000/t-rs6000  (working copy)
@@ -20,6 +20,7 @@
 
 TM_H += $(srcdir)/config/rs6000/rs6000-builtin.def
 TM_H += $(srcdir)/config/rs6000/rs6000-cpus.def
+PASSES_EXTRA += $(srcdir)/config/rs6000/rs6000-passes.def
 
 rs6000-c.o: $(srcdir)/config/rs6000/rs6000-c.c
$(COMPILE) $<

Re: [PATCH, Fortran, pr78672, ctp1, v1] Gfortran test suite failures with a sanitized compiler

[Mikael Morin]

Le 08/12/2016 à 14:39, Andre Vehreschild a écrit :

Hi all, hi Dominique,

this is the "compile time part 1" (ctp1) patch to fix the issues reported in
gfortran by a sanitized compiler when compiling the testsuite. The patch
addresses all issues besides leaks (ASAN_OPTIONS="detect_leaks=false". Most of
the issues were about assuming certain kinds of data without explicitly
checking, e.g., taking a component-ref for an array-ref and similar.

So this patch only addresses the -fsanitize=address,undefined reports (without
leaks) for running the compiler. I liked to keep this patch small to get it
reviewed quickly.

I see some other areas of work:

compile time part 2: address the leaks
testsuite run time: address the runtime issues (might have to be split in
others and leaks, too)

So far, is this patch bootstrapping and regtesting fine on x86_64-linux/f23. Ok
for trunk?

Regards,
Andre

PS: @Dominique: I will not commit before you are better and had the time to
test this.


diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c
index 139ce88..4f835b3 100644
--- a/gcc/fortran/data.c
+++ b/gcc/fortran/data.c
@@ -186,7 +186,7 @@ create_character_initializer (gfc_expr *init, gfc_typespec 
*ts,
   for (i = 0; i < len; i++)
dest[start+i] = rvalue->representation.string[i];
 }
-  else
+  else if (rvalue->value.character.string)

This one looks fishy.
Either rvalue is a character constant and its string should be set, or 
it’s not a character constant and the value.character.string should not 
be accessed at all.




 memcpy ([start], rvalue->value.character.string,
len * sizeof (gfc_char_t));

diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 8afba84..4e4d17c 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2803,6 +2803,7 @@ compare_actual_formal (gfc_actual_arglist **ap, 
gfc_formal_arglist *formal,
   int i, n, na;
   unsigned long actual_size, formal_size;
   bool full_array = false;
+  gfc_ref *actual_arr_ref;

   actual = *ap;

@@ -2942,37 +2943,38 @@ compare_actual_formal (gfc_actual_arglist **ap, 
gfc_formal_arglist *formal,
 and assumed-shape dummies, the string length needs to match
 exactly.  */
   if (a->expr->ts.type == BT_CHARACTER
-  && a->expr->ts.u.cl && a->expr->ts.u.cl->length
-  && a->expr->ts.u.cl->length->expr_type == EXPR_CONSTANT
-  && f->sym->ts.u.cl && f->sym->ts.u.cl && f->sym->ts.u.cl->length
-  && f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT
-  && (f->sym->attr.pointer || f->sym->attr.allocatable
-  || (f->sym->as && f->sym->as->type == AS_ASSUMED_SHAPE))
-  && (mpz_cmp (a->expr->ts.u.cl->length->value.integer,
-   f->sym->ts.u.cl->length->value.integer) != 0))
-{
-  if (where && (f->sym->attr.pointer || f->sym->attr.allocatable))
-gfc_warning (OPT_Wargument_mismatch,
- "Character length mismatch (%ld/%ld) between actual "
- "argument and pointer or allocatable dummy argument "
- "%qs at %L",
- mpz_get_si (a->expr->ts.u.cl->length->value.integer),
- mpz_get_si (f->sym->ts.u.cl->length->value.integer),
- f->sym->name, >expr->where);
-  else if (where)
-gfc_warning (OPT_Wargument_mismatch,
- "Character length mismatch (%ld/%ld) between actual "
- "argument and assumed-shape dummy argument %qs "
- "at %L",
- mpz_get_si (a->expr->ts.u.cl->length->value.integer),
- mpz_get_si (f->sym->ts.u.cl->length->value.integer),
- f->sym->name, >expr->where);
-  return 0;
-}
+ && a->expr->ts.u.cl && a->expr->ts.u.cl->length
+ && a->expr->ts.u.cl->length->expr_type == EXPR_CONSTANT
+ && f->sym->ts.type == BT_CHARACTER && f->sym->ts.u.cl
+ && f->sym->ts.u.cl->length
+ && f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT
+ && (f->sym->attr.pointer || f->sym->attr.allocatable
+ || (f->sym->as && f->sym->as->type == AS_ASSUMED_SHAPE))
+ && (mpz_cmp (a->expr->ts.u.cl->length->value.integer,
+  f->sym->ts.u.cl->length->value.integer) != 0))
+   {
+ if (where && (f->sym->attr.pointer || f->sym->attr.allocatable))
+   gfc_warning (OPT_Wargument_mismatch,
+"Character length mismatch (%ld/%ld) between actual "
+"argument and pointer or allocatable dummy argument "
+"%qs at %L",
+mpz_get_si (a->expr->ts.u.cl->length->value.integer),
+mpz_get_si (f->sym->ts.u.cl->length->value.integer),
+f->sym->name, >expr->where);
+ else 

Re: parallel_algorithm_assert2.cc

[David Edelsohn]

On Thu, Dec 8, 2016 at 10:03 AM, Jonathan Wakely  wrote:
> On 8 December 2016 at 17:09, David Edelsohn wrote:
>> Jonathan,
>>
>> I'm seeing a new failure on AIX.
>>
>> FAIL: 25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
>> (test for excess errors)
>> Excess errors:
>> xg++: error: libgomp.spec: No such file or directory
>>
>> Does the testsuite driver assume that libgomp.spec already is
>> installed in the correct install location?
>
> Ah, I think the DG directives are in the wrong order.
>
> Does this help?
>
> --- 
> a/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
> +++ 
> b/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
> @@ -1,6 +1,6 @@
> -// { dg-require-parallel-mode "" }
>  // { dg-options "-fopenmp -D_GLIBCXX_PARALLEL" { target *-*-* } }
>  // { dg-do run }
> +// { dg-require-parallel-mode "" }
>
>  // Copyright (C) 2016 Free Software Foundation, Inc.
>  //

Placing the dg-do run directive first fixes the problem.  That is what
I committed.

Thanks, David

Re: [Patch, fortran, RFC] Add warning for missing location information

[Mikael Morin]

Le 08/12/2016 à 22:50, Thomas Koenig a écrit :

Am 08.12.2016 um 21:01 schrieb Mikael Morin:

Le 08/12/2016 à 20:26, Thomas Koenig a écrit :

Hi Andre,


Thomas, your part of the patch looks ok to me, too. I haven't tracked
the
discussion on whether it is ok to add your part of the patch.
Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So
it should
be applied.


Based on the feedback so far, I will this apply during the weekend
after another regression test unless somebody objects.



Hello,

I have one comment.

This error;
+gfc_warning_internal (0, "No location in statement statement");

is not very helpful, especially without location.



Could you at least provide the statement type? There is
gfc_ascii_statement you can use for that.


gfc_ascii_statement works with gfc_statement only,
here, we are dealing with gfc_exec_op.


Of course. :-(


What I could do is to add a gfc_debug_code function to
dump-parse-tree and add a comment that, if this part of
the code is encountered, you should examine the expression
using that particular function call using a debugger.

Of course, I could also just dump the statement to stderr,
but somehow that does not quite conform to all the elegang
error handling infrastructure in gcc :-)


Yes, please don’t do that.


So, what do people think?

As the code is disabled for releases anyway, I don’t mind the patch 
getting in as is. So OK from my side.

[C++ PATCH] P0490R0 GB 20: decomposition declaration should commit to tuple interpretation early

[Jakub Jelinek]

Hi!

Issaquah papers have been recently published and there are two
decomp changes.  One I've sent a partially working patch privately and am
lost with, the other one is that whenever std::tuple_size is a
complete type, we should commit to the std::tuple* way - so if it is
missing value static data member/enum or it isn't a constant expression
we should just error out instead of trying to decompose as other structs.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or shall I move the diagnostics from get_tuple_size to the caller (only
return error_mark_node from there)?

2016-12-08  Jakub Jelinek  

P0490R0 GB 20: decomposition declaration should commit to tuple
interpretation early
* decl.c (get_tuple_size): Add LOC argument, make static.  If
inst is error_mark_node or non-complete type, return NULL_TREE,
otherwise if lookup_qualified_name fails or doesn't fold into
INTEGER_CST, complain and return error_mark_node.
(get_tuple_element_type, get_tuple_decomp_init): Make static.
(cp_finish_decomp): Pass LOC to get_tuple_size.  If it returns
error_mark_node, fail.

* g++.dg/cpp1z/decomp10.C (f1): Adjust expected diagnostics.

--- gcc/cp/decl.c.jj2016-12-07 17:19:10.0 +0100
+++ gcc/cp/decl.c   2016-12-08 16:52:10.029095252 +0100
@@ -7259,8 +7259,8 @@ find_decomp_class_base (location_t loc,
 
 /* Return std::tuple_size::value.  */
 
-tree
-get_tuple_size (tree type)
+static tree
+get_tuple_size (location_t loc, tree type)
 {
   tree args = make_tree_vec (1);
   TREE_VEC_ELT (args, 0) = type;
@@ -7268,6 +7268,11 @@ get_tuple_size (tree type)
 /*in_decl*/NULL_TREE,
 /*context*/std_node,
 /*entering_scope*/false, tf_none);
+  if (inst == error_mark_node)
+return NULL_TREE;
+  inst = complete_type (inst);
+  if (!COMPLETE_TYPE_P (inst))
+return NULL_TREE;
   tree val = lookup_qualified_name (inst, get_identifier ("value"),
/*type*/false, /*complain*/false);
   if (TREE_CODE (val) == VAR_DECL || TREE_CODE (val) == CONST_DECL)
@@ -7275,12 +7280,16 @@ get_tuple_size (tree type)
   if (TREE_CODE (val) == INTEGER_CST)
 return val;
   else
-return NULL_TREE;
+{
+  error_at (loc, "%::value%> is not an integral "
+"constant expression", type);
+  return error_mark_node;
+}
 }
 
 /* Return std::tuple_element::type.  */
 
-tree
+static tree
 get_tuple_element_type (tree type, unsigned i)
 {
   tree args = make_tree_vec (2);
@@ -7297,7 +7306,7 @@ get_tuple_element_type (tree type, unsig
 
 /* Return e.get() or get(e).  */
 
-tree
+static tree
 get_tuple_decomp_init (tree decl, unsigned i)
 {
   tree get_id = get_identifier ("get");
@@ -7342,6 +7351,7 @@ store_decomp_type (tree v, tree t)
 decomp_type_table = hash_map::create_ggc (13);
   decomp_type_table->put (v, t);
 }
+
 tree
 lookup_decomp_type (tree v)
 {
@@ -7500,8 +7510,10 @@ cp_finish_decomp (tree decl, tree first,
  DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
}
 }
-  else if (tree tsize = get_tuple_size (type))
+  else if (tree tsize = get_tuple_size (loc, type))
 {
+  if (tsize == error_mark_node)
+   goto error_out;
   eltscnt = tree_to_uhwi (tsize);
   if (count != eltscnt)
goto cnt_mismatch;
--- gcc/testsuite/g++.dg/cpp1z/decomp10.C.jj2016-11-15 09:57:00.0 
+0100
+++ gcc/testsuite/g++.dg/cpp1z/decomp10.C   2016-12-08 16:48:55.833555410 
+0100
@@ -7,7 +7,7 @@ namespace std {
 
 struct A1 { int i,j; } a1;
 template<> struct std::tuple_size {  };
-void f1() { auto [ x ] = a1; } // { dg-error "decomposes into 2" }
+void f1() { auto [ x ] = a1; } // { dg-error "is not an integral constant 
expression" }
 
 struct A2 { int i,j; } a2;
 template<> struct std::tuple_size { enum { value = 5 }; };


Jakub

[PATCH] Reassoc zero_one_operation fixes (PR tree-optimization/78726)

[Jakub Jelinek]

Hi!

The following testcases show two bugs in zero_one_operation (used during
undistribute optimization) and functions it calls.
The first one (wrong-code) is fixed by the
+  tree orig_def = *def;
and
-  if (stmts_to_fix.length () > 0)
+  if (stmts_to_fix.length () > 0 || *def == orig_def)
changes in zero_one_operation - e.g. in the testcase we have before reassoc
  _6 = _5 * a_11;
  _7 = _5 * _6;
and call zero_one_operation for _7 with op a_11.  The last stmt isn't pushed
into stmts_to_fix, the *def stmt is handled specially in
make_new_ssa_for_all_defs.  And the previous one, while it is pushed, it is
popped from there again, because the stmt is removed and instead _6 use
is replaced with _5.  That changes what value _7 holds, so we want to use
a new SSA_NAME for it (or deal with debug stmts and reset flow sensitive
info etc.).

The second one is wrong-debug, make_new_ssa_for_def replaces the uses of old
lhs with the new lhs (which is fine in the code uses, but for debug info
because we zeroed out a_11 we want to say that previous uses of _7 are now
the _7's replacement * a_11.  Which is what the rest of the patch does
and there is a guality testcase that verifies it (previously it would fail).

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

2016-12-08  Jakub Jelinek  

PR tree-optimization/78726
* tree-ssa-reassoc.c (make_new_ssa_for_def): Add OPCODE and OP
argument.  For lhs uses in debug stmts, don't replace lhs with
new_lhs, but with a debug temp set to new_lhs opcode op.
(make_new_ssa_for_all_defs): Add OPCODE argument, pass OPCODE and
OP down to make_new_ssa_for_def.
(zero_one_operation): Call make_new_ssa_for_all_defs even when
stmts_to_fix is empty, if *def has not changed yet.  Pass
OPCODE to make_new_ssa_for_all_defs.

* gcc.c-torture/execute/pr78726.c: New test.
* gcc.dg/guality/pr78726.c: New test.

--- gcc/tree-ssa-reassoc.c.jj   2016-11-09 16:34:58.0 +0100
+++ gcc/tree-ssa-reassoc.c  2016-12-08 15:53:13.768894146 +0100
@@ -1153,12 +1153,12 @@ decrement_power (gimple *stmt)
SSA.  Also return the new SSA.  */
 
 static tree
-make_new_ssa_for_def (gimple *stmt)
+make_new_ssa_for_def (gimple *stmt, enum tree_code opcode, tree op)
 {
   gimple *use_stmt;
   use_operand_p use;
   imm_use_iterator iter;
-  tree new_lhs;
+  tree new_lhs, new_debug_lhs = NULL_TREE;
   tree lhs = gimple_get_lhs (stmt);
 
   new_lhs = make_ssa_name (TREE_TYPE (lhs));
@@ -1167,8 +1167,28 @@ make_new_ssa_for_def (gimple *stmt)
   /* Also need to update GIMPLE_DEBUGs.  */
   FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
 {
+  tree repl = new_lhs;
+  if (is_gimple_debug (use_stmt))
+   {
+ if (new_debug_lhs == NULL_TREE)
+   {
+ new_debug_lhs = make_node (DEBUG_EXPR_DECL);
+ gdebug *def_temp
+   = gimple_build_debug_bind (new_debug_lhs,
+  build2 (opcode, TREE_TYPE (lhs),
+  new_lhs, op),
+  stmt);
+ DECL_ARTIFICIAL (new_debug_lhs) = 1;
+ TREE_TYPE (new_debug_lhs) = TREE_TYPE (lhs);
+ SET_DECL_MODE (new_debug_lhs, TYPE_MODE (TREE_TYPE (lhs)));
+ gimple_set_uid (def_temp, gimple_uid (stmt));
+ gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
+ gsi_insert_after (, def_temp, GSI_SAME_STMT);
+   }
+ repl = new_debug_lhs;
+   }
   FOR_EACH_IMM_USE_ON_STMT (use, iter)
-   SET_USE (use, new_lhs);
+   SET_USE (use, repl);
   update_stmt (use_stmt);
 }
   return new_lhs;
@@ -1179,7 +1199,7 @@ make_new_ssa_for_def (gimple *stmt)
if *DEF is not OP.  */
 
 static void
-make_new_ssa_for_all_defs (tree *def, tree op,
+make_new_ssa_for_all_defs (tree *def, enum tree_code opcode, tree op,
   vec _to_fix)
 {
   unsigned i;
@@ -1189,10 +1209,10 @@ make_new_ssa_for_all_defs (tree *def, tr
   && TREE_CODE (*def) == SSA_NAME
   && (stmt = SSA_NAME_DEF_STMT (*def))
   && gimple_code (stmt) != GIMPLE_NOP)
-*def = make_new_ssa_for_def (stmt);
+*def = make_new_ssa_for_def (stmt, opcode, op);
 
   FOR_EACH_VEC_ELT (stmts_to_fix, i, stmt)
-make_new_ssa_for_def (stmt);
+make_new_ssa_for_def (stmt, opcode, op);
 }
 
 /* Find the single immediate use of STMT's LHS, and replace it
@@ -1232,6 +1252,7 @@ propagate_op_to_single_use (tree op, gim
 static void
 zero_one_operation (tree *def, enum tree_code opcode, tree op)
 {
+  tree orig_def = *def;
   gimple *stmt = SSA_NAME_DEF_STMT (*def);
   /* PR72835 - Record the stmt chain that has to be updated such that
  we dont use the same LHS when the values computed are different.  */
@@ -1335,8 +1356,8 @@ zero_one_operation (tree *def, enum tree
 }
   while (1);
 
-  if (stmts_to_fix.length () > 0)
-

Re: [Patch, fortran, RFC] Add warning for missing location information

[Thomas Koenig]

Am 08.12.2016 um 21:01 schrieb Mikael Morin:

Le 08/12/2016 à 20:26, Thomas Koenig a écrit :

Hi Andre,


Thomas, your part of the patch looks ok to me, too. I haven't tracked
the
discussion on whether it is ok to add your part of the patch.
Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So
it should
be applied.


Based on the feedback so far, I will this apply during the weekend
after another regression test unless somebody objects.



Hello,

I have one comment.

This error;
+gfc_warning_internal (0, "No location in statement statement");

is not very helpful, especially without location.



Could you at least provide the statement type? There is
gfc_ascii_statement you can use for that.


gfc_ascii_statement works with gfc_statement only,
here, we are dealing with gfc_exec_op.

What I could do is to add a gfc_debug_code function to
dump-parse-tree and add a comment that, if this part of
the code is encountered, you should examine the expression
using that particular function call using a debugger.

Of course, I could also just dump the statement to stderr,
but somehow that does not quite conform to all the elegang
error handling infrastructure in gcc :-)

So, what do people think?

Regards

Thomas

Re: [PATCH 5/9] Introduce selftest::locate_file (v4)

[David Malcolm]

On Thu, 2016-12-01 at 14:29 +0100, Bernd Schmidt wrote:
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > +  /* Makefile.in has -fself-test=$(srcdir)/testsuite/selftests, so
> > that
> > + flag_self_test contains the path to the selftest subdirectory
> > of the
> > + source tree (without a trailing slash).  Copy it up to
> > + path_to_selftest_files, to avoid selftest.c depending on
> > + option-handling.  */
> > +  path_to_selftest_files = flag_self_test;
> > +
> 
> What kind of dependency are you avoiding? If it's just one include
> I'd 
> prefer to get rid of the extraneous variable.
> 
> Otherwise ok.

I attempted to eliminate the global, and include "options.h" from
selftest.c, and to use flag_self_test directly (implicitly accessing
the global_options global).

The *code* changes were relatively simple, with only one extra
#include.

However, from a linker perspective, it's more awkward.  selftest.o is
used by (amongst other things) OBJS-libcommon: libcommon.a currently
has selftest.o, but doesn't have options.o.  Various things in
libcommon.a use selftest.o for selftests and thus libcommon.a needs
selftest.o.

Hence doing so brings in a dependency on the option-handling objects
into libcommon.a, which seems wrong to me.

It seems simplest to go with either:

(A) the approach in the patch, with an extra global, keeping the
selftest code independent from gcc's option-handling code (both at
compile time and link time) or

(B) add the path as an extra param, passing it in at all callsites,
so that every
   locate_file (some_path)
in the kit becomes
   locate_file (flag_self_test, some_path)

Is (A) OK, or would you prefer (B)?   (I prefer (A) fwiw)

Thanks
Dave

[PATCH, middle-end]: Fix PR78738, unrecognized insn with -ffast-math

[Uros Bizjak]

Hello!

Attached patch fixes fall-out from excess-precision improvements
patch. As shown in the PR, the code throughout the compiler assumes
FLAG_PRECISION_FAST when flag_unsafe_math_optimizations flag is in
effect. The patch puts back two lines, removed by excess-precision
improvements patch.

2016-12-08  Uros Bizjak  

PR middle-end/78738
* toplev.c (init_excess_precision): Initialize flag_excess_precision
to EXCESS_PRECISION_FAST for flag_unsafe_math_optimizations.

testsuite/ChangeLog:

2016-12-08  Uros Bizjak  

PR middle-end/78738
* gcc.target/i386/pr78738.c: New test.

Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

OK for mainline?

Uros.
Index: testsuite/gcc.target/i386/pr78738.c
===
--- testsuite/gcc.target/i386/pr78738.c (nonexistent)
+++ testsuite/gcc.target/i386/pr78738.c (working copy)
@@ -0,0 +1,10 @@
+/* PR middle-end/78738 */
+/* { dg-do compile } */
+/* { dg-options "-O -std=c99 -ffast-math -mfpmath=387" } */
+
+double round (double);
+
+int foo (double a)
+{
+  return round (a);
+}
Index: toplev.c
===
--- toplev.c(revision 243456)
+++ toplev.c(working copy)
@@ -1691,6 +1691,8 @@ init_excess_precision (void)
 {
   gcc_assert (flag_excess_precision_cmdline != EXCESS_PRECISION_DEFAULT);
   flag_excess_precision = flag_excess_precision_cmdline;
+  if (flag_unsafe_math_optimizations)
+flag_excess_precision = EXCESS_PRECISION_FAST;
 }
 
 /* Initialize things that are both lang-dependent and target-dependent.

Re: [PATCH] PR fortran/65173 -- kill off old_cl_list from gfc_namespace.

[Steve Kargl]

On Thu, Dec 08, 2016 at 07:58:37AM +0100, Paul Richard Thomas wrote:
> 
> "Accidence" == state of fixing non-deterministic ICEs? :-)
> 
> OK for trunk.
> 
> Thanks for dealing with this kind of dead wood.
> 

Committed revision 243463.

-- 
Steve

patch to fix PR78671

[Vladimir N Makarov]

The following patch fixes

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

The patch was successfully bootstrapped and tested on x86-64.

Committed as rev. 243462.


Index: ChangeLog
===
--- ChangeLog	(revision 243461)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2016-12-08  Vladimir Makarov  
+
+	PR rtl-optimization/78671
+	* lra-assign.c (lra-assigns.c): Check prohibited regs for an
+	allocno class.
+
 2016-12-08  Uros Bizjak  
 
 	* gcc.target/i386/i386.h (HARD_REGNO_NREGS): Use GENERAL_REGNO_P.
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 243461)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2016-12-08  Vladimir Makarov  
+
+	PR rtl-optimization/78671
+	* gcc.target/i386/pr78671.c: New.
+
 2015-12-08  Wilco Dijkstra  
 
 	PR target/78733
Index: lra-assigns.c
===
--- lra-assigns.c	(revision 243305)
+++ lra-assigns.c	(working copy)
@@ -628,9 +628,13 @@ find_hard_regno_for_1 (int regno, int *c
 	hard_regno = ira_class_hard_regs[rclass][i];
   if (! overlaps_hard_reg_set_p (conflict_set,
  PSEUDO_REGNO_MODE (regno), hard_regno)
-	  /* We can not use prohibited_class_mode_regs because it is
-	 not defined for all classes.  */
 	  && HARD_REGNO_MODE_OK (hard_regno, PSEUDO_REGNO_MODE (regno))
+	  /* We can not use prohibited_class_mode_regs for all classes
+	 because it is not defined for all classes.  */
+	  && (ira_allocno_class_translate[rclass] != rclass
+	  || ! TEST_HARD_REG_BIT (ira_prohibited_class_mode_regs
+  [rclass][PSEUDO_REGNO_MODE (regno)],
+  hard_regno))
 	  && ! TEST_HARD_REG_BIT (impossible_start_hard_regs, hard_regno)
 	  && (nregs_diff == 0
 	  || (WORDS_BIG_ENDIAN
Index: testsuite/gcc.target/i386/pr78671.c
===
--- testsuite/gcc.target/i386/pr78671.c	(revision 0)
+++ testsuite/gcc.target/i386/pr78671.c	(working copy)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-march=skylake-avx512 -Og" } */
+
+typedef unsigned __int128 u128;
+typedef unsigned __int128 v64u128 __attribute__ ((vector_size (64)));
+
+v64u128
+foo (u128 u128_3, v64u128 v64u128_3, v64u128 v64u128_2, v64u128 v64u128_1,
+ v64u128 v64u128_0)
+{
+  v64u128_0 <<= 1;
+  v64u128_2 >>= 0 != v64u128_2;
+  v64u128_3[v64u128_3[0]] &= 1;
+  v64u128_3 = v64u128_3 & 1;
+  v64u128_2 = v64u128_2 >> 1 | v64u128_2 << v64u128_1[0];
+  v64u128_0[0] >>= 127;
+  return u128_3 + v64u128_0 + v64u128_2 + v64u128_3;
+}

Fix ICE with __builtin_va_list on i?86 (PR middle-end/78716)

[Marek Polacek]

This test ICEs since r240072 where Tom disallowed using va_list * as a first
argument to va_arg.  I think the problem is in the ADDR_EXPR check in
gimplify_va_arg_expr.  It's meant to handle Case 1, but the valist doesn't
always have to be ADDR_EXPR.  E.g. for this testcase build_va_arg creates
VA_ARG_EXPR <&*s>
but during clone_body this is transformed into
VA_ARG_EXPR 
so we have a valid valist, but it's not an ADDR_EXPR, so we don't call
targetm.canonical_va_list_type and crash on the subsequent assert.

Tom, does this make sense to you?  [Although I haven't seen Tom here on ML
lately...]

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

2016-12-08  Marek Polacek  

PR middle-end/78716
* gimplify.c (gimplify_va_arg_expr): Don't require ADDR_EXPR for
Case 1.

* g++.dg/other/vararg-5.C: New.

diff --git gcc/gimplify.c gcc/gimplify.c
index 8611060..08c4faa 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -12642,8 +12642,7 @@ gimplify_va_arg_expr (tree *expr_p, gimple_seq *pre_p,
   if (have_va_type == error_mark_node)
 return GS_ERROR;
   have_va_type = targetm.canonical_va_list_type (have_va_type);
-  if (have_va_type == NULL_TREE
-  && TREE_CODE (valist) == ADDR_EXPR)
+  if (have_va_type == NULL_TREE)
 /* Handle 'Case 1: Not an array type' from c-common.c/build_va_arg.  */
 have_va_type
   = targetm.canonical_va_list_type (TREE_TYPE (TREE_TYPE (valist)));
diff --git gcc/testsuite/g++.dg/other/vararg-5.C 
gcc/testsuite/g++.dg/other/vararg-5.C
index e69de29..9327bd6 100644
--- gcc/testsuite/g++.dg/other/vararg-5.C
+++ gcc/testsuite/g++.dg/other/vararg-5.C
@@ -0,0 +1,24 @@
+// PR middle-end/78716
+// { dg-do compile }
+
+template 
+  struct a;
+  template  struct b;
+  template  class e : 
b::c {
+public:
+typedef e f;
+  typedef typename b::c g;
+e(__builtin_va_list *s) : g(__builtin_va_arg(*s, 
int)) {}
+  };
+template <> struct b { typedef e<> c; };
+template <> struct e<> { template  e(h); };
+template  class a : public e {};
+template 
+class a : e::f> {
+  public:
+  template 
+ a(a) : a::f(0) {}
+};
+template  a<> r(i, j, k, l);
+void q() { a(r(4, 6, 9, 7)); }

Marek

Re: Merge from trunk to gccgo branch

[Ian Lance Taylor]

I now merged trunk revision 243459 to the gccgo branch.

Ian

libgo patch committed: mark unused parameters as unused

[Ian Lance Taylor]

This patch to libgo marks the unused parameters in the non-x86 code of
the new file aeshash.c as unused, to avoid build warnings.
Bootstrapped on x86_64-pc-linux-gnu, test compiled using an ARM
cross-compiler.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 243445)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-78e3527fcaf4ffd33b22e39a56e5d076844302be
+ac59bb383e1b446c68465af793722dd0e84abefb
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/runtime/aeshash.c
===
--- libgo/runtime/aeshash.c (revision 243445)
+++ libgo/runtime/aeshash.c (working copy)
@@ -575,7 +575,10 @@ uintptr aeshashbody(void* p, uintptr see
 
 #else // !defined(__i386__) && !defined(__x86_64__)
 
-uintptr aeshashbody(void* p, uintptr seed, uintptr size, Slice aeskeysched) {
+uintptr aeshashbody(void* p __attribute__((unused)),
+   uintptr seed __attribute__((unused)),
+   uintptr size __attribute__((unused)),
+   Slice aeskeysched __attribute__((unused))) {
// We should never get here on a non-x86 system.
runtime_throw("impossible call to aeshashbody");
 }

Re: C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Martin Sebor]

On 12/08/2016 01:28 PM, Marek Polacek wrote:

On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:

On 12/08/2016 01:05 PM, Jason Merrill wrote:

If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.


What about:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob"){}
};

?  That ICEs in the same way.


My patch would make GCC to reject this too, but the new 'else' needs to
be removed from the patch, i.e.


Clang accepts this test case although it does reject the originally
submitted test case with the messages below.  I think GCC should
accept the latter case for compatibility.  If it is accepted then
rejecting the original test case will make the array initialization
irregular.  I think it would be nice if they both could accepted
but I don't know how much work it would be to make it work.

Martin

t.C:4:12: warning: in-class initialization of non-static data member is 
a C++11

  extension [-Wc++11-extensions]
  char a[] = "foo";
   ^
t.C:4:12: error: array bound cannot be deduced from an in-class initializer
t.C:3:8: warning: private field 'b' is not used [-Wunused-private-field]
  bool b;
   ^
t.C:4:8: warning: private field 'a' is not used [-Wunused-private-field]
  char a[] = "foo";
   ^
3 warnings and 1 error generated.

Re: Default associative containers constructors/destructor/assignment

[François Dumont]

On 06/12/2016 12:54, Jonathan Wakely wrote:

On 20/11/16 19:14 +0100, François Dumont wrote:
Talking about _M_color I just realize that move semantic doesn't copy 
_M_color. Shouldn't we capture it along with all the other _M_header 
information ?


Is it needed? I think the current code does the right thing, doesn't
it? I'd prefer not to change it without a testcase showing why we need
to.


I was hoping you knew it. So I kept it unchanged and will add to my TODO 
to check this.


Committed now.

François

Re: C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Marek Polacek]

On Thu, Dec 08, 2016 at 02:56:56PM -0500, Nathan Sidwell wrote:
> On 12/08/2016 01:05 PM, Jason Merrill wrote:
> > If the problem is the member initializer, we can diagnose that
> > directly rather than wait until we're in a constructor.
> 
> What about:
> struct Foo {
> int a;
> char ary[];
> Foo () : ary ("bob"){}
> };
> 
> ?  That ICEs in the same way.

My patch would make GCC to reject this too, but the new 'else' needs to
be removed from the patch, i.e.

2016-12-08  Marek Polacek  

PR c++/72775
* init.c (perform_member_init): Diagnose initialization of a flexible
array member in a constructor.

* g++.dg/ext/flexary20.C: New.

diff --git gcc/cp/init.c gcc/cp/init.c
index b4b6cdb..01009c9 100644
--- gcc/cp/init.c
+++ gcc/cp/init.c
@@ -800,6 +800,10 @@ perform_member_init (tree member, tree init)
   in that case.  */
init = build_x_compound_expr_from_list (init, ELK_MEM_INIT,
tf_warning_or_error);
+  if (TREE_CODE (type) == ARRAY_TYPE
+  && TYPE_DOMAIN (type) == NULL_TREE)
+   error_at (DECL_SOURCE_LOCATION (member),
+ "initialization of a flexible array member in a constructor");
 
   if (init)
finish_expr_stmt (cp_build_modify_expr (input_location, decl,
diff --git gcc/testsuite/g++.dg/ext/flexary20.C 
gcc/testsuite/g++.dg/ext/flexary20.C
index e69de29..ff97b06 100644
--- gcc/testsuite/g++.dg/ext/flexary20.C
+++ gcc/testsuite/g++.dg/ext/flexary20.C
@@ -0,0 +1,49 @@
+// PR c++/72775
+// { dg-do compile { target c++11 } }
+// { dg-options -Wno-pedantic }
+
+struct S {
+  int i;
+  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+  S () {}
+};
+
+struct T {
+  int i;
+  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+};
+
+struct U {
+  int i;
+  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+  U ();
+};
+
+U::U() {}
+
+int
+main ()
+{
+  struct T t;
+}
+
+struct V {
+  int i;
+  struct W {
+int j;
+char a[] = "foo"; // { dg-error "initialization of a flexible array member 
in a constructor" }
+  } w;
+  V () {}
+};
+
+template 
+struct X {
+  int i;
+  T a[] = "foo"; // { dg-error "initialization of a flexible array member in a 
constructor" }
+};
+
+void
+fn ()
+{
+  struct X x;
+}

Marek

Merge from trunk to gccgo branch

[Ian Lance Taylor]

I merged trunk revision 243445 to the gccgo branch.

Ian

Re: [PATCH] Fix bug in MEM parsing in patches 8a/8b

[Bernd Schmidt]

On 12/08/2016 09:39 PM, David Malcolm wrote:


OK as adjustments to patches 8a and 8b?


Ok. Is it possible to adjust these macros to return something like a 
const reference to ensure people can't make this kind of error?



Bernd

[PATCH] Fix bug in MEM parsing in patches 8a/8b

[David Malcolm]

Testing the patch kit on i686 showed numerous failures of this
assertion in set_mem_attributes_minus_bitpos in emit-rtl.c:

  1821gcc_assert (!defattrs->offset_known_p);

when expanding "main" in the rtl.exp test files, after parsing
an __RTL-tagged function.

Root cause is various assignments within the RTL parser of the
form:

1222  MEM_OFFSET (x) = atoi (name.string);

where a MEM_* macro appears on the left-hand side of an assignment.

These macros are defined as a field lookup on the result of a call
to get_mem_attrs, e.g.:

  #define MEM_OFFSET(RTX) (get_mem_attrs (RTX)->offset)

get_mem_attrs can return the struct mem_attrs * of an rtx, but if
it isn't set, it returns:
   mode_mem_attrs[(int) GET_MODE (x)];

which is this field within struct GTY(()) target_rtl:
  /* The default memory attributes for each mode.  */
  struct mem_attrs *x_mode_mem_attrs[(int) MAX_MACHINE_MODE];

These assignments in the parser were erroneously writing to these
default per-mode values, rather than assigning to a unique-per-rtx
instance of struct mem_attrs.

The fix is to call the appropriate set_mem_ functions in the
parser, e.g. set_mem_offset; the patch below is intended as a tweak
to patch 8a of the kit, and would be merged with it before committing.

The patch also adds extra test coverage for MEM parsing.  This extends
the target-independent selftests, and so would go into patch 8b.

Tested for targets x86_64-pc-linux-gnu, i686-pc-linux-gnu,
and aarch64-linux-gnu, and on powerpc-ibm-aix7.1.3.0.

OK as adjustments to patches 8a and 8b?

For patch 8a:
  gcc/ChangeLog:
* read-rtl-function.c
(function_reader::handle_any_trailing_information): Replace writes
through macros MEM_ALIAS_SET, MEM_OFFSET, MEM_SIZE, MEM_ALIGN,
and MEM_ADDR_SPACE with calls to set_mem_ functions.  Add missing
call to unread_char when handling "A" for alignment.

For patch 8b:
  gcc/ChangeLog:
* read-rtl-function.c (selftest::test_loading_mem): New function.
(selftest::read_rtl_function_c_tests): Call it.
  gcc/testsuite/ChangeLog:
* selftests/mem.rtl: New file.
---
 gcc/read-rtl-function.c | 55 -
 gcc/testsuite/selftests/mem.rtl |  9 +++
 2 files changed, 58 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/selftests/mem.rtl

diff --git a/gcc/read-rtl-function.c b/gcc/read-rtl-function.c
index 5188b86..c3f5c64 100644
--- a/gcc/read-rtl-function.c
+++ b/gcc/read-rtl-function.c
@@ -1201,7 +1201,7 @@ function_reader::handle_any_trailing_information (rtx x)
  int ch;
  require_char_ws ('[');
  read_name ();
- MEM_ALIAS_SET (x) = atoi (name.string);
+ set_mem_alias_set (x, atoi (name.string));
  /* We have either a MEM_EXPR, or a space.  */
  if (peek_char () != ' ')
{
@@ -1218,8 +1218,7 @@ function_reader::handle_any_trailing_information (rtx x)
  if (ch == '+')
{
  read_name ();
- MEM_OFFSET_KNOWN_P (x) = 1;
- MEM_OFFSET (x) = atoi (name.string);
+ set_mem_offset (x, atoi (name.string));
}
  else
unread_char (ch);
@@ -1229,7 +1228,7 @@ function_reader::handle_any_trailing_information (rtx x)
  if (ch == 'S')
{
  read_name ();
- MEM_SIZE (x) = atoi (name.string);
+ set_mem_size (x, atoi (name.string));
}
  else
unread_char (ch);
@@ -1239,8 +1238,10 @@ function_reader::handle_any_trailing_information (rtx x)
  if (ch == 'A' && peek_char () != 'S')
{
  read_name ();
- MEM_ALIGN (x) = atoi (name.string);
+ set_mem_align (x, atoi (name.string));
}
+ else
+   unread_char (ch);
 
  /* Handle optional " AS" for MEM_ADDR_SPACE.  */
  ch = read_skip_spaces ();
@@ -1248,7 +1249,7 @@ function_reader::handle_any_trailing_information (rtx x)
{
  read_char ();
  read_name ();
- MEM_ADDR_SPACE (x) = atoi (name.string);
+ set_mem_addr_space (x, atoi (name.string));
}
  else
unread_char (ch);
@@ -2102,6 +2103,47 @@ test_loading_bb_index ()
   ASSERT_EQ (42, bb42->index);
 }
 
+/* Verify that function_reader::handle_any_trailing_information correctly
+   parses all the possible items emitted for a MEM.  */
+
+static void
+test_loading_mem ()
+{
+  rtl_dump_test t (SELFTEST_LOCATION, locate_file ("mem.rtl"));
+
+  ASSERT_STREQ ("test_mem", IDENTIFIER_POINTER (DECL_NAME (cfun->decl)));
+  ASSERT_TRUE (cfun);
+
+  /* Verify parsing of "[42 i+17 S8 A128 AS5]".  */
+  rtx_insn *insn_1 = get_insn_by_uid (1);
+  rtx set1 = single_set (insn_1);
+  rtx mem1 = SET_DEST (set1);
+  ASSERT_EQ (42, MEM_ALIAS_SET (mem1));
+  /* "+17".  */
+  ASSERT_TRUE (MEM_OFFSET_KNOWN_P (mem1));
+  

Re: [Patch, fortran, RFC] Add warning for missing location information

[Mikael Morin]

Le 08/12/2016 à 20:26, Thomas Koenig a écrit :

Hi Andre,


Thomas, your part of the patch looks ok to me, too. I haven't tracked the
discussion on whether it is ok to add your part of the patch.
Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So
it should
be applied.


Based on the feedback so far, I will this apply during the weekend
after another regression test unless somebody objects.



Hello,

I have one comment.

This error;
+gfc_warning_internal (0, "No location in statement statement");

is not very helpful, especially without location.
Could you at least provide the statement type? There is 
gfc_ascii_statement you can use for that.


Thanks
Mikael

Re: C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Nathan Sidwell]

On 12/08/2016 01:05 PM, Jason Merrill wrote:

If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.


What about:
struct Foo {
int a;
char ary[];
Foo () : ary ("bob"){}
};

?  That ICEs in the same way.

nathan

--
Nathan Sidwell

Re: [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

[Bernd Edlinger]

Hi Wilco,

On 11/30/16 18:01, Bernd Edlinger wrote:
> I attached the completely untested follow-up patch now, but I would
> like to post that one again for review, after I applied my current
> patch, which is still waiting for final review (please feel pinged!).
>
>
> This is really exciting...
>
>


when testing the follow-up patch I discovered a single regression
in gcc.dg/fixed-point/convert-sat.c that was caused by a mis-compilation
of the libgcc function __gnu_satfractdasq.

I think it triggerd a latent bug in the carryin_compare patterns.

everything is as expected until reload.  First what is left over
of a split cmpdi_insn followed by a former cmpdi_unsigned, if the
branch is not taken.

(insn 109 10 110 2 (set (reg:CC 100 cc)
 (compare:CC (reg:SI 0 r0 [orig:124 _10 ] [124])
 (const_int 0 [0]))) 
"../../../gcc-trunk/libgcc/fixed-bit.c":785 196 {*arm_cmpsi_insn}
  (nil))
(insn 110 109 13 2 (parallel [
 (set (reg:CC 100 cc)
 (compare:CC (reg:SI 1 r1 [orig:125 _10+4 ] [125])
 (const_int -1 [0x])))
 (set (reg:SI 3 r3 [123])
 (minus:SI (plus:SI (reg:SI 1 r1 [orig:125 _10+4 ] [125])
 (const_int -1 [0x]))
 (ltu:SI (reg:CC_C 100 cc)
 (const_int 0 [0]
 ]) "../../../gcc-trunk/libgcc/fixed-bit.c":785 32 
{*subsi3_carryin_compare_const}
  (nil))
(jump_insn 13 110 31 2 (set (pc)
 (if_then_else (ge (reg:CC_NCV 100 cc)
 (const_int 0 [0]))
 (label_ref:SI 102)
 (pc))) "../../../gcc-trunk/libgcc/fixed-bit.c":785 204 
{arm_cond_branch}
  (int_list:REG_BR_PROB 6400 (nil))

(note 31 13 97 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(note 97 31 114 3 NOTE_INSN_DELETED)
(insn 114 97 113 3 (set (reg:SI 2 r2 [orig:127+4 ] [127])
 (const_int -1 [0x])) 
"../../../gcc-trunk/libgcc/fixed-bit.c":831 630 {*arm_movsi_vfp}
  (expr_list:REG_EQUIV (const_int -1 [0x])
 (nil)))
(insn 113 114 107 3 (set (reg:SI 3 r3 [126])
 (const_int 2147483647 [0x7fff])) 
"../../../gcc-trunk/libgcc/fixed-bit.c":831 630 {*arm_movsi_vfp}
  (expr_list:REG_EQUIV (const_int 2147483647 [0x7fff])
 (nil)))
(insn 107 113 108 3 (set (reg:CC 100 cc)
 (compare:CC (reg:SI 1 r1 [orig:125 _10+4 ] [125])
 (reg:SI 2 r2 [orig:127+4 ] [127]))) 
"../../../gcc-trunk/libgcc/fixed-bit.c":831 196 {*arm_cmpsi_insn}
  (nil))


Note that the CC register is not really set as implied by insn 110,
because the C flag depends on the comparison of r1, 0x and the
carry flag from insn 109.  Therefore in the postreload pass the
insn 107 appears to be unnecessary, as if should compute
exactly the same CC flag, as insn 110, i.e. not dependent on
previous CC flag.  I think all carryin_compare patterns are
wrong because they do not describe the true value of the CC reg.

I think the CC reg is actually dependent on left, right and CC-in
value, as in the new version of the patch it must be a computation
in DI mode without overflow, as in my new version of the patch.

I attached an update of the followup patch which is not yet adjusted
on your pending negdi patch.  Reg-testing is no yet done, but the
mis-compilation on libgcc is fixed at least.

What do you think?


Thanks
Bernd.
2016-12-08  Bernd Edlinger  

	PR target/77308
	* config/arm/arm.md (subdi3_compare1, subsi3_carryin_compare,
	subsi3_carryin_compare_const, negdi2_compare): Fix the CC reg dataflow.
	(*arm_negdi2, *arm_cmpdi_unsigned): Split early except for
TARGET_NEON and TARGET_IWMMXT.
	(*arm_cmpdi_insn): Split early except for
	TARGET_NEON and TARGET_IWMMXT.  Fix the CC reg dataflow.
	* config/arm/thumb2.md (*thumb2_negdi2): Split early except for
	TARGET_NEON and TARGET_IWMMXT.

testsuite:
2016-12-08  Bernd Edlinger  

	PR target/77308
	* gcc.target/arm/pr77308-2.c: New test.

--- gcc/config/arm/arm.md.orig	2016-12-08 16:01:43.290595127 +0100
+++ gcc/config/arm/arm.md	2016-12-08 19:04:22.251065848 +0100
@@ -1086,8 +1086,8 @@
 })
 
 (define_insn_and_split "subdi3_compare1"
-  [(set (reg:CC CC_REGNUM)
-	(compare:CC
+  [(set (reg:CC_NCV CC_REGNUM)
+	(compare:CC_NCV
 	  (match_operand:DI 1 "register_operand" "r")
 	  (match_operand:DI 2 "register_operand" "r")))
(set (match_operand:DI 0 "register_operand" "=")
@@ -1098,10 +1098,15 @@
   [(parallel [(set (reg:CC CC_REGNUM)
 		   (compare:CC (match_dup 1) (match_dup 2)))
 	  (set (match_dup 0) (minus:SI (match_dup 1) (match_dup 2)))])
-   (parallel [(set (reg:CC CC_REGNUM)
-		   (compare:CC (match_dup 4) (match_dup 5)))
-	 (set (match_dup 3) (minus:SI (minus:SI (match_dup 4) (match_dup 5))
-			   (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0])]
+   (parallel [(set (reg:CC_C CC_REGNUM)
+		   (compare:CC_C
+		 (zero_extend:DI (match_dup 4))
+		

Re: [Patch, fortran, RFC] Add warning for missing location information

[Thomas Koenig]

Hi Andre,


Thomas, your part of the patch looks ok to me, too. I haven't tracked the
discussion on whether it is ok to add your part of the patch. Therefore I don't
have committed your patch. My opinion is, that it does do no harm. So it should
be applied.


Based on the feedback so far, I will this apply during the weekend
after another regression test unless somebody objects.

Regards

Thomas

Re: [PATCH] Fix c++/78621 generic lambda mangling

[Nathan Sidwell]

On 12/08/2016 02:08 PM, Jason Merrill wrote:


Right.  Which is because they act as normal template parameters rather
than like the auto type-specifier does in, say, a variable declaration.
But indeed this produces bad mangling, and using Da in the mangling of a
generic lambda seems reasonable.  You've probably seen my mail to the
ABI list about it.  Are you still on that list?


Yes, thanks.


This use of tsubst can meet {TYPE,EXPR}_PARAMETER_PACKs, so I had to
extend tsubst to process those objects.


Hmm, we have deliberately avoided this in the past, since pack
expansions mean different things in different contexts.  Can you use
tsubst_arg_types instead?


... will investigate.


Also, the name "make_auto_for_mangle" doesn't really indicate that it's
doing a substitution of the function parameter types.


yeah, probably not the best name anymore. (it started out as just 
creating the single auto type, but then I moved all the other stuff into 
it.)


nathan
--
Nathan Sidwell

Re: [PATCH][AArch64] Fix PR78733

[Wilco Dijkstra]

James Greenhalgh wrote:
>
> I presume you also made a testsuite run?
> 
> You should be able to do something like:
> 
>  make check RUNTESTFLAGS="--target_board=unix/-mpc-relative-literal-loads"

Yes the results of that looked OK, the 250 new failures are gone. I've 
committed the fix.

Wilco

[PATCH, i386]: Use GENERAL_REGNO_P some more

[Uros Bizjak]

No functional changes.

2016-12-08  Uros Bizjak  

* gcc.target/i386/i386.h (HARD_REGNO_NREGS): Use GENERAL_REGNO_P.
(HARD_REGNO_NREGS_HAS_PADDING): Ditto.  Simplify macro.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 83ffd4e..8bc31f9 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1080,22 +1080,19 @@ extern const char *host_detect_local_cpu (int argc, 
const char **argv);
applied to them.  */
 
 #define HARD_REGNO_NREGS(REGNO, MODE)  \
-  (STACK_REGNO_P (REGNO) || SSE_REGNO_P (REGNO) || MMX_REGNO_P (REGNO) \
-   || MASK_REGNO_P (REGNO) || BND_REGNO_P (REGNO)  \
-   ? (COMPLEX_MODE_P (MODE) ? 2 :  \
-  (((MODE == V64SFmode) || (MODE == V64SImode)) ? 4 : 1))  \
-   : ((MODE) == XFmode \
+  (GENERAL_REGNO_P (REGNO) \
+   ? ((MODE) == XFmode \
   ? (TARGET_64BIT ? 2 : 3) \
   : ((MODE) == XCmode  \
 ? (TARGET_64BIT ? 4 : 6)   \
-: CEIL (GET_MODE_SIZE (MODE), UNITS_PER_WORD
+: CEIL (GET_MODE_SIZE (MODE), UNITS_PER_WORD)))\
+   : (COMPLEX_MODE_P (MODE) ? 2 :  \
+  (((MODE == V64SFmode) || (MODE == V64SImode)) ? 4 : 1)))
 
 #define HARD_REGNO_NREGS_HAS_PADDING(REGNO, MODE)  \
-  ((TARGET_128BIT_LONG_DOUBLE && !TARGET_64BIT)
\
-   ? (STACK_REGNO_P (REGNO) || SSE_REGNO_P (REGNO) || MMX_REGNO_P (REGNO) \
-  ? 0  \
-  : ((MODE) == XFmode || (MODE) == XCmode))
\
-   : 0)
+  (TARGET_128BIT_LONG_DOUBLE && !TARGET_64BIT  \
+   && GENERAL_REGNO_P (REGNO)  \
+   && ((MODE) == XFmode || (MODE) == XCmode))
 
 #define HARD_REGNO_NREGS_WITH_PADDING(REGNO, MODE) ((MODE) == XFmode ? 4 : 8)
 

Re: [PATCH] Fix c++/78621 generic lambda mangling

[Jason Merrill]

On 12/07/2016 01:30 PM, Nathan Sidwell wrote:

This patch fixes the generic lambda mangling bug that caused the
demangler to infinitely recurse (78252).  The generic's auto parms fail
the is_auto check because that's testing for the 'auto' identifier,
whereas the parms are distinct template type parms named 'auto:$N'.


Right.  Which is because they act as normal template parameters rather 
than like the auto type-specifier does in, say, a variable declaration. 
But indeed this produces bad mangling, and using Da in the mangling of a 
generic lambda seems reasonable.  You've probably seen my mail to the 
ABI list about it.  Are you still on that list?



Amending is_auto to do a textual compare of the identifier breaks
things, and is insufficient anyway.  The mangler's squangling must (a)
squangle subsequent auto uses as expected and (b) NOT squangle
subsequent template type parm references to refer the the lambda's autos.


Wow, I haven't seen the term "squangling" in more than a decade.  Did we 
ever use that in reference to the new ABI?



This use of tsubst can meet {TYPE,EXPR}_PARAMETER_PACKs, so I had to
extend tsubst to process those objects.


Hmm, we have deliberately avoided this in the past, since pack 
expansions mean different things in different contexts.  Can you use 
tsubst_arg_types instead?


Also, the name "make_auto_for_mangle" doesn't really indicate that it's 
doing a substitution of the function parameter types.


Jason

New Spanish PO file for 'gcc' (version 6.2.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/gcc/es.po

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

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: C++ PATCH to reject initializating flexible array members in constructors (PR c++/72775)

[Jason Merrill]

If the problem is the member initializer, we can diagnose that
directly rather than wait until we're in a constructor.

On Wed, Dec 7, 2016 at 3:26 PM, Marek Polacek  wrote:
> We were crashing in finish_expr_stmt here:
>  676   /* If we ran into a problem, make sure we complained.  */
>  677   gcc_assert (expr != error_mark_node || seen_error ());
> Well, we ran into a problem, but never raised an error.  The problem was that
> we couldn't determine the max index of the array when default-initizalizing 
> the
> members (at the beginning of cp_parser_ctor_initializer_opt).  Jason's
> preference seems to be to disable initialization of a flexible array member in
> a constructor and that is what this patch attempts to do.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2016-12-07  Marek Polacek  
>
> PR c++/72775
> * init.c (perform_member_init): Diagnose initialization of a flexible
> array member in a constructor.
>
> * g++.dg/ext/flexary20.C: New.
>
> diff --git gcc/cp/init.c gcc/cp/init.c
> index b4b6cdb..01009c9 100644
> --- gcc/cp/init.c
> +++ gcc/cp/init.c
> @@ -800,6 +800,10 @@ perform_member_init (tree member, tree init)
>in that case.  */
> init = build_x_compound_expr_from_list (init, ELK_MEM_INIT,
> tf_warning_or_error);
> +  else if (TREE_CODE (type) == ARRAY_TYPE
> +  && TYPE_DOMAIN (type) == NULL_TREE)
> +   error_at (DECL_SOURCE_LOCATION (member),
> + "initialization of a flexible array member in a 
> constructor");
>
>if (init)
> finish_expr_stmt (cp_build_modify_expr (input_location, decl,
> diff --git gcc/testsuite/g++.dg/ext/flexary20.C 
> gcc/testsuite/g++.dg/ext/flexary20.C
> index e69de29..ff97b06 100644
> --- gcc/testsuite/g++.dg/ext/flexary20.C
> +++ gcc/testsuite/g++.dg/ext/flexary20.C
> @@ -0,0 +1,49 @@
> +// PR c++/72775
> +// { dg-do compile { target c++11 } }
> +// { dg-options -Wno-pedantic }
> +
> +struct S {
> +  int i;
> +  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
> in a constructor" }
> +  S () {}
> +};
> +
> +struct T {
> +  int i;
> +  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
> in a constructor" }
> +};
> +
> +struct U {
> +  int i;
> +  char a[] = "foo"; // { dg-error "initialization of a flexible array member 
> in a constructor" }
> +  U ();
> +};
> +
> +U::U() {}
> +
> +int
> +main ()
> +{
> +  struct T t;
> +}
> +
> +struct V {
> +  int i;
> +  struct W {
> +int j;
> +char a[] = "foo"; // { dg-error "initialization of a flexible array 
> member in a constructor" }
> +  } w;
> +  V () {}
> +};
> +
> +template 
> +struct X {
> +  int i;
> +  T a[] = "foo"; // { dg-error "initialization of a flexible array member in 
> a constructor" }
> +};
> +
> +void
> +fn ()
> +{
> +  struct X x;
> +}
>
> Marek

Re: [PATCH] fix c++/78551 ICE in constexpr

[Jason Merrill]

On Wed, Dec 7, 2016 at 3:31 PM, Nathan Sidwell  wrote:
> This patch fixes 78551.  The union was a red herring.  The underlying
> problem is that we first initialize a char array with a string constant, and
> then zap a random element of that array.  That zapping expects to see a
> CONSTRUCTOR, not a STRING_CST.  Fixed by expanding the STRING_CST into a
> CONSTRUCTOR for each element, when we encounter this situation.
>
> Patch tested on HEAD and gcc-6 branch.

OK.

> Is gcc-5 still live (testcase is marked as a  5/6/7 regression)?

It is; you can check gcc.gnu.org to see current release status.

Incidentally, would you mind naming your attachments .diff rather than
.patch?  Gmail mishandles the latter.

Jason

Re: parallel_algorithm_assert2.cc

[Jonathan Wakely]

On 8 December 2016 at 17:09, David Edelsohn wrote:
> Jonathan,
>
> I'm seeing a new failure on AIX.
>
> FAIL: 25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
> (test for excess errors)
> Excess errors:
> xg++: error: libgomp.spec: No such file or directory
>
> Does the testsuite driver assume that libgomp.spec already is
> installed in the correct install location?

Ah, I think the DG directives are in the wrong order.

Does this help?

--- 
a/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
+++ 
b/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
@@ -1,6 +1,6 @@
-// { dg-require-parallel-mode "" }
 // { dg-options "-fopenmp -D_GLIBCXX_PARALLEL" { target *-*-* } }
 // { dg-do run }
+// { dg-require-parallel-mode "" }

 // Copyright (C) 2016 Free Software Foundation, Inc.
 //

Re: [Patch, fortran] Ping! - PR77903 - [F08] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces

[Paul Richard Thomas]

On 5 December 2016 at 21:01, Paul Richard Thomas
 wrote:
> Dear All,
>
> It took me an excessively long time to realise that processing the
> typespec for an explicitly typed module procedure was wiping out the
> interface symbol and so preventing the comparison of characteristics
> between the interface and the separate module procedure. Transferring
> the module interface symbol to the tlink field, rather than the
> interface, fixed the problem without doing anything else.
>
> Note the comment in the gfortran.h about the use of the tlink field.
> It has been a while since this was used for change management. If it
> is preferred, I could introduce a union between tlink and some other
> suitable name; eg mod_proc_interface.
>
> Bootstraps and regtests on FC21/x86_64.
>
> OK for trunk and, after a decent interval, 6-branch?
>
> Paul
>
> 2016-12-06  Paul Thomas  
>
> PR fortran/77903
> * decl.c (get_proc_name): Use the symbol tlink field instead of
> the typespec interface field.
> (gfc_match_function_decl, gfc_match_submod_proc): Ditto.
> * gfortran.h : Since the symbol tlink field is no longer used
> by the frontend for change management, change the comment to
> reflect its current uses.
> * parse.c (get_modproc_result): Same as decl.c changes.
> * resolve.c (resolve_fl_procedure): Ditto.
>
> 2016-12-06  Paul Thomas  
>
> PR fortran/77903
> * gfortran.dg/submodule_20.f08: New test.



-- 
If you're walking down the right path and you're willing to keep
walking, eventually you'll make progress.

Barack Obama

Re: [PATCH][AArch64] Fix PR78733

[James Greenhalgh]

On Thu, Dec 08, 2016 at 03:30:59PM +, Wilco Dijkstra wrote:
> This patch fixes an issue in aarch64_classify_address.  TImode and TFmode
> can either use a 64-bit LDP/STP or 128-bit LDR/STR.  The addressing mode
> must be carefully modelled as the intersection of both.  This is done for
> the immediate offsets, however load_store_pair_p must be set as well to
> avoid LDP with a PC-relative address if aarch64_pcrelative_literal_loads
> is true.
> 
> Bootstrap passes with aarch64_pcrelative_literal_loads=true.

I presume you also made a testsuite run?

You should be able to do something like:

  make check RUNTESTFLAGS="--target_board=unix/-mpc-relative-literal-loads"

To run the entire testsuite with -mpc-relative-literal-loads.

Thanks for the prompt fix.

This is OK assuming you've run the testsuite and it has come back clean.

Thanks,
James

> 
> ChangeLog:
> 2015-12-08  Wilco Dijkstra  
> 
>   PR target/78733
>   * config/aarch64/aarch64.c (aarch64_classify_address):
>   Set load_store_pair_p for TImode and TFmode.
> 
> /testsuite
>   * gcc.target/aarch64/pr78733.c: New test.

Re: [PATCH] Print 2 digits after decimal delimiter for BB frequencies

[Martin Liška]

On 12/08/2016 05:39 PM, Martin Sebor wrote:
> On 12/08/2016 05:55 AM, Martin Liška wrote:
>> With the patch applied, one can distinguish between PROB_VERY_UNLIKELY and
>> real zero probability:
> 
> I tried to see if formatting the expression
> 
>   e->probability * 100.0 / REG_BR_PROB_BASE
> 
> with "%.2f" is guaranteed to output non-zero when e->probability
> is non-zero.  If I got the values right then the smallest non-zero
> e->probability can be as low as 1, and REG_BR_PROB_BASE is 1.
> That evaluates to 0.0099985 which Glibc formats as
> 0.01 because (AFAIK) its printf rounds to nearest.

Thank you for playing with that.

> 
> If this is guaranteed then I think it's fine.  Otherwise, if there
> is a chance that the printed result could be 0.00% for a non-zero
> probability it might be worth to detect it and make sure it's at
> least 0.01% to avoid the same confusion I had with the 0.00%.

Yep, I like that assumption.

> 
> FWIW, if GCC uses integers rather than floats internally to make
> decisions (I don't know) then also printing integers would give
> the most accurate results.  E.g., something like
>   printf ("%2u.%u%%", e->probability / 100, e->probability % 100)

That's bit tricky as you need "%2u.%02u%%", where '02u' depends on result of 
REG_BR_PROB_BASE / 100. We plan with Honza to utilize probably sreal type
instead of the scaled integers. So that I prepared a new patch (not tested yet).

Ideas?
Thanks,
Martin


> 
> Thanks
> Martin
> 
>>
>> f ()
>> {
>>   int _1;
>>
>>[100.00%]:
>>   _1 = __builtin_sprintf (, "%i", 12);
>>   if (_1 != 2)
>> goto ; [0.04%]
>>   else
>> goto ; [99.96%]
>>
>>[0.04%]:
>>   __builtin_abort ();
>>
>>[99.96%]:
>>   return;
>>
>> }
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>> Martin
>>
> 

>From afbc46f8ebcdf00d320a066b692537399cd189c0 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 1 Dec 2016 10:55:55 +0100
Subject: [PATCH] Print 2 digits after decimal delimiter for BB frequencies

gcc/ChangeLog:

2016-12-01  Martin Liska  

	* gimple-pretty-print.c (dump_probability): New function.
	(dump_edge_probability): Use the function.
	(dump_gimple_label): Likewise.
	(dump_gimple_bb_header): Likewise.

gcc/testsuite/ChangeLog:

2016-12-02  Martin Liska  

	* gcc.dg/tree-ssa/20040703-1.c: Update scanned pattern.
	* gcc.dg/tree-ssa/dump-2.c: Likewise.
---
 gcc/gimple-pretty-print.c  | 30 --
 gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/dump-2.c |  2 +-
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c
index b5e866d..27a22c4 100644
--- a/gcc/gimple-pretty-print.c
+++ b/gcc/gimple-pretty-print.c
@@ -72,13 +72,32 @@ debug_gimple_stmt (gimple *gs)
   print_gimple_stmt (stderr, gs, 0, TDF_VOPS|TDF_MEMSYMS);
 }
 
+
+/* Return formatted string of a VALUE probability
+   (biased by REG_BR_PROB_BASE).  Returned string is allocated
+   by xstrdup_for_dump.  */
+
+static const char *
+dump_probability (int value)
+{
+  char buf[16];
+  float minimum = 0.01f;
+
+  gcc_assert (0 <= value && value <= REG_BR_PROB_BASE);
+  float fvalue = value * 100.0f / REG_BR_PROB_BASE;
+  if (fvalue < minimum && value > 0)
+return "[0.01%]";
+
+  sprintf (buf, "[%.2f%%]", fvalue);
+  return xstrdup_for_dump (buf);
+}
+
 /* Dump E probability to BUFFER.  */
 
 static void
 dump_edge_probability (pretty_printer *buffer, edge e)
 {
-  pp_scalar (buffer, " [%.1f%%]",
-	 e->probability * 100.0 / REG_BR_PROB_BASE);
+  pp_scalar (buffer, " %s", dump_probability (e->probability));
 }
 
 /* Print GIMPLE statement G to FILE using SPC indentation spaces and
@@ -1023,8 +1042,7 @@ dump_gimple_label (pretty_printer *buffer, glabel *gs, int spc, int flags)
   dump_generic_node (buffer, label, spc, flags, false);
   basic_block bb = gimple_bb (gs);
   if (bb && !(flags & TDF_GIMPLE))
-	pp_scalar (buffer, " [%.1f%%]",
-		   bb->frequency * 100.0 / REG_BR_PROB_BASE);
+	pp_scalar (buffer, " %s", dump_probability (bb->frequency));
   pp_colon (buffer);
 }
   if (flags & TDF_GIMPLE)
@@ -2590,8 +2608,8 @@ dump_gimple_bb_header (FILE *outf, basic_block bb, int indent, int flags)
 	  if (flags & TDF_GIMPLE)
 	fprintf (outf, "%*sbb_%d:\n", indent, "", bb->index);
 	  else
-	fprintf (outf, "%*s [%.1f%%]:\n", indent, "", bb->index,
-		 bb->frequency * 100.0 / REG_BR_PROB_BASE);
+	fprintf (outf, "%*s %s:\n",
+		 indent, "", bb->index, dump_probability (bb->frequency));
 	}
 }
 }
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c b/gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c
index 2980047..eb9fb56 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c
@@ -9,4 +9,4 @@ float foo(float x)
 }
 
 /* We should *not* fold the 

Re: Calling 'abort' on bounds violations in libmpx

[Ilya Enkovich]

2016-12-08 12:21 GMT+03:00 Alexander Ivchenko :
> I've tested the patch on MPX HW, no new regressions. Attached the
> final version below, would that be ok to submit?

The patch is OK.

Ilya

>
>
> 2016-11-29  Alexander Ivchenko  
>
> * mpxrt/libtool-version: New version.
> * mpxrt/mpxrt-utils.c (set_mpx_rt_stop_handler): New function.
> (print_help): Add help for CHKP_RT_STOP_HANDLER environment
> variable.
> (__mpxrt_init_env_vars): Add initialization of stop_handler.
> (__mpxrt_stop_handler): New function.
> (__mpxrt_stop): Ditto.
> * mpxrt/mpxrt-utils.h (mpx_rt_stop_mode_handler_t): New enum.
>
> diff --git a/libmpx/mpxrt/libtool-version b/libmpx/mpxrt/libtool-version
> index 7d99255..736d763 100644
> --- a/libmpx/mpxrt/libtool-version
> +++ b/libmpx/mpxrt/libtool-version
> @@ -3,4 +3,4 @@
>  # a separate file so that version updates don't involve re-running
>  # automake.
>  # CURRENT:REVISION:AGE
> -2:0:0
> +2:1:0
> diff --git a/libmpx/mpxrt/mpxrt-utils.c b/libmpx/mpxrt/mpxrt-utils.c
> index 057a355..63ee7c6 100644
> --- a/libmpx/mpxrt/mpxrt-utils.c
> +++ b/libmpx/mpxrt/mpxrt-utils.c
> @@ -60,6 +60,9 @@
>  #define MPX_RT_MODE "CHKP_RT_MODE"
>  #define MPX_RT_MODE_DEFAULT MPX_RT_COUNT
>  #define MPX_RT_MODE_DEFAULT_STR "count"
> +#define MPX_RT_STOP_HANDLER "CHKP_RT_STOP_HANDLER"
> +#define MPX_RT_STOP_HANDLER_DEFAULT MPX_RT_STOP_HANDLER_ABORT
> +#define MPX_RT_STOP_HANDLER_DEFAULT_STR "abort"
>  #define MPX_RT_HELP "CHKP_RT_HELP"
>  #define MPX_RT_ADDPID "CHKP_RT_ADDPID"
>  #define MPX_RT_BNDPRESERVE "CHKP_RT_BNDPRESERVE"
> @@ -84,6 +87,7 @@ typedef struct {
>  static int summary;
>  static int add_pid;
>  static mpx_rt_mode_t mode;
> +static mpx_rt_stop_mode_handler_t stop_handler;
>  static env_var_list_t env_var_list;
>  static verbose_type verbose_val;
>  static FILE *out;
> @@ -226,6 +230,23 @@ set_mpx_rt_mode (const char *env)
>}
>  }
>
> +static mpx_rt_stop_mode_handler_t
> +set_mpx_rt_stop_handler (const char *env)
> +{
> +  if (env == 0)
> +return MPX_RT_STOP_HANDLER_DEFAULT;
> +  else if (strcmp (env, "abort") == 0)
> +return MPX_RT_STOP_HANDLER_ABORT;
> +  else if (strcmp (env, "exit") == 0)
> +return MPX_RT_STOP_HANDLER_EXIT;
> +  {
> +__mpxrt_print (VERB_ERROR, "Illegal value '%s' for %s. Legal values are"
> +   "[abort | exit]\nUsing default value %s\n",
> +   env, MPX_RT_STOP_HANDLER, MPX_RT_STOP_HANDLER_DEFAULT);
> +return MPX_RT_STOP_HANDLER_DEFAULT;
> +  }
> +}
> +
>  static void
>  print_help (void)
>  {
> @@ -244,6 +265,11 @@ print_help (void)
>fprintf (out, "%s \t\t set MPX runtime behavior on #BR exception."
> " [stop | count]\n"
> "\t\t\t [default: %s]\n", MPX_RT_MODE, MPX_RT_MODE_DEFAULT_STR);
> +  fprintf (out, "%s \t set the handler function MPX runtime will call\n"
> +   "\t\t\t on #BR exception when %s is set to \'stop\'."
> +   " [abort | exit]\n"
> +   "\t\t\t [default: %s]\n", MPX_RT_STOP_HANDLER, MPX_RT_MODE,
> +   MPX_RT_STOP_HANDLER_DEFAULT_STR);
>fprintf (out, "%s \t\t generate out,err file for each process.\n"
> "\t\t\t generated file will be MPX_RT_{OUT,ERR}_FILE.pid\n"
> "\t\t\t [default: no]\n", MPX_RT_ADDPID);
> @@ -357,6 +383,10 @@ __mpxrt_init_env_vars (int* bndpreserve)
>env_var_list_add (MPX_RT_MODE, env);
>mode = set_mpx_rt_mode (env);
>
> +  env = secure_getenv (MPX_RT_STOP_HANDLER);
> +  env_var_list_add (MPX_RT_STOP_HANDLER, env);
> +  stop_handler = set_mpx_rt_stop_handler (env);
> +
>env = secure_getenv (MPX_RT_BNDPRESERVE);
>env_var_list_add (MPX_RT_BNDPRESERVE, env);
>validate_bndpreserve (env, bndpreserve);
> @@ -487,6 +517,22 @@ __mpxrt_mode (void)
>return mode;
>  }
>
> +mpx_rt_mode_t
> +__mpxrt_stop_handler (void)
> +{
> +  return stop_handler;
> +}
> +
> +void __attribute__ ((noreturn))
> +__mpxrt_stop (void)
> +{
> +  if (__mpxrt_stop_handler () == MPX_RT_STOP_HANDLER_ABORT)
> +abort ();
> +  else if (__mpxrt_stop_handler () == MPX_RT_STOP_HANDLER_EXIT)
> +exit (255);
> +  __builtin_unreachable ();
> +}
> +
>  void
>  __mpxrt_print_summary (uint64_t num_brs, uint64_t l1_size)
>  {
> diff --git a/libmpx/mpxrt/mpxrt-utils.h b/libmpx/mpxrt/mpxrt-utils.h
> index d62937d..6da12cc 100644
> --- a/libmpx/mpxrt/mpxrt-utils.h
> +++ b/libmpx/mpxrt/mpxrt-utils.h
> @@ -54,6 +54,11 @@ typedef enum {
>MPX_RT_STOP
>  } mpx_rt_mode_t;
>
> +typedef enum {
> +  MPX_RT_STOP_HANDLER_ABORT,
> +  MPX_RT_STOP_HANDLER_EXIT
> +} mpx_rt_stop_mode_handler_t;
> +
>  void __mpxrt_init_env_vars (int* bndpreserve);
>  void __mpxrt_write_uint (verbose_type vt, uint64_t val, unsigned base);
>  void __mpxrt_write (verbose_type vt, const char* str);
> diff --git a/libmpx/mpxrt/mpxrt.c b/libmpx/mpxrt/mpxrt.c
> index b52906b..76d11f7 100644
> --- a/libmpx/mpxrt/mpxrt.c
> +++ b/libmpx/mpxrt/mpxrt.c
> @@ -252,7 +252,7 @@ handler (int sig __attribute__ ((unused)),
>uctxt->uc_mcontext.gregs[REG_IP_IDX] =
>  

Re: [PATCH] [PR78112] Remove the g++.dg/pr78112.C testcase

[Mike Stump]

On Dec 8, 2016, at 3:04 AM, Pierre-Marie de Rodat  wrote:
> Thank you for the pre-approval: I’ve just pushed this fix. For the record, 
> I’ve checked it runs fine on x86_64-linux and x86_64-apple-darwin-16.3.0 and 
> I’ve checked manually we have the correct number of attributes with a partial 
> arm-none-abi compiler (i.e. just cc1plus).

Thanks.

parallel_algorithm_assert2.cc

[David Edelsohn]

Jonathan,

I'm seeing a new failure on AIX.

FAIL: 25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
(test for excess errors)
Excess errors:
xg++: error: libgomp.spec: No such file or directory

Does the testsuite driver assume that libgomp.spec already is
installed in the correct install location?

Thanks, David

Re: [PATCH] Print 2 digits after decimal delimiter for BB frequencies

[Martin Sebor]

On 12/08/2016 05:55 AM, Martin Liška wrote:

With the patch applied, one can distinguish between PROB_VERY_UNLIKELY and
real zero probability:


I tried to see if formatting the expression

  e->probability * 100.0 / REG_BR_PROB_BASE

with "%.2f" is guaranteed to output non-zero when e->probability
is non-zero.  If I got the values right then the smallest non-zero
e->probability can be as low as 1, and REG_BR_PROB_BASE is 1.
That evaluates to 0.0099985 which Glibc formats as
0.01 because (AFAIK) its printf rounds to nearest.

If this is guaranteed then I think it's fine.  Otherwise, if there
is a chance that the printed result could be 0.00% for a non-zero
probability it might be worth to detect it and make sure it's at
least 0.01% to avoid the same confusion I had with the 0.00%.

FWIW, if GCC uses integers rather than floats internally to make
decisions (I don't know) then also printing integers would give
the most accurate results.  E.g., something like
  printf ("%2u.%u%%", e->probability / 100, e->probability % 100)

Thanks
Martin



f ()
{
  int _1;

   [100.00%]:
  _1 = __builtin_sprintf (, "%i", 12);
  if (_1 != 2)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin_abort ();

   [99.96%]:
  return;

}

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin

libgo patch committed: Copy hash code from Go 1.7 runtime

[Ian Lance Taylor]

This patch to libgo copies the memory hashing code from the Go 1.7
runtime.  This is particular important because we earlier copied the
hashmap code from Go 1.7, and that changed hash table sizes from prime
numbers to powers of two.  The memory hashing code used before this
patch was fine for prime numbers but for powers of two tended to hash
many values to the same bucket, making maps much much slower than they
should be.

I rewrote the AES hashing code from gc assembler to C code using
intrinsics.  The resulting code generates the same hash code for the
same input as the gc code--that doesn't matter as such, but testing it
ensures that the C code does something useful.

I changed mips64pe32le to mips64p32le in configure script--noticed
during CL review.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu, both with
and without the AES hashing code.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 243444)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-2442fca7be8a4f51ddc91070fa69ef66e24593ac
+78e3527fcaf4ffd33b22e39a56e5d076844302be
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 243321)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -1648,7 +1648,7 @@ Type::type_functions(Gogo* gogo, Named_t
   const char* equal_fnname;
   if (this->compare_is_identity(gogo))
 {
-  hash_fnname = "__go_type_hash_identity";
+  hash_fnname = "runtime.memhash";
   equal_fnname = "__go_type_equal_identity";
 }
   else
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 243084)
+++ libgo/Makefile.am   (working copy)
@@ -422,6 +422,7 @@ endif
 endif
 
 runtime_files = \
+   runtime/aeshash.c \
runtime/go-assert.c \
runtime/go-breakpoint.c \
runtime/go-caller.c \
Index: libgo/configure.ac
===
--- libgo/configure.ac  (revision 243084)
+++ libgo/configure.ac  (working copy)
@@ -197,7 +197,7 @@ AC_SUBST(USE_DEJAGNU)
 # supported by the gofrontend and all architectures supported by the
 # gc toolchain.
 # N.B. Keep in sync with gcc/testsuite/go.test/go-test.exp (go-set-goarch).
-ALLGOARCH="386 alpha amd64 amd64p32 arm armbe arm64 arm64be ia64 m68k mipso32 
mipsn32 mipso64 mipsn64 mips mipsle mips64 mips64le mips64p32 mips64pe32le ppc 
ppc64 ppc64le s390 s390x sparc sparc64"
+ALLGOARCH="386 alpha amd64 amd64p32 arm armbe arm64 arm64be ia64 m68k mipso32 
mipsn32 mipso64 mipsn64 mips mipsle mips64 mips64le mips64p32 mips64p32le ppc 
ppc64 ppc64le s390 s390x sparc sparc64"
 
 # All known GOARCH_FAMILY values.
 ALLGOARCHFAMILY="I386 ALPHA AMD64 ARM ARM64 IA64 M68K MIPS MIPS64 PPC PPC64 
S390 S390X SPARC SPARC64"
Index: libgo/go/runtime/alg.go
===
--- libgo/go/runtime/alg.go (revision 243084)
+++ libgo/go/runtime/alg.go (working copy)
@@ -23,12 +23,29 @@ import (
 //go:linkname efacevaleq runtime.efacevaleq
 //go:linkname eqstring runtime.eqstring
 //go:linkname cmpstring runtime.cmpstring
+//
+// Temporary to be called from C code.
+//go:linkname alginit runtime.alginit
 
 const (
c0 = uintptr((8-sys.PtrSize)/4*2860486313 + 
(sys.PtrSize-4)/4*33054211828000289)
c1 = uintptr((8-sys.PtrSize)/4*326713 + 
(sys.PtrSize-4)/4*23344194077549503)
 )
 
+var useAeshash bool
+
+// in C code
+func aeshashbody(p unsafe.Pointer, h, s uintptr, sched []byte) uintptr
+
+func aeshash(p unsafe.Pointer, h, s uintptr) uintptr {
+   return aeshashbody(p, h, s, aeskeysched[:])
+}
+
+func aeshashstr(p unsafe.Pointer, h uintptr) uintptr {
+   ps := (*stringStruct)(p)
+   return aeshashbody(unsafe.Pointer(ps.str), h, uintptr(ps.len), 
aeskeysched[:])
+}
+
 func interhash(p unsafe.Pointer, h uintptr, size uintptr) uintptr {
a := (*iface)(p)
tab := a.tab
@@ -198,7 +215,35 @@ func cmpstring(x, y string) int {
 
 // Force the creation of function descriptors for equality and hash
 // functions.  These will be referenced directly by the compiler.
+var _ = memhash
 var _ = interhash
 var _ = interequal
 var _ = nilinterhash
 var _ = nilinterequal
+
+const hashRandomBytes = sys.PtrSize / 4 * 64
+
+// used in asm_{386,amd64}.s to seed the hash function
+var aeskeysched [hashRandomBytes]byte
+
+// used in hash{32,64}.go to seed the hash function
+var hashkey [4]uintptr
+
+func alginit() {
+   // Install aes hash algorithm if we have the instructions we need
+   if (GOARCH == "386" || GOARCH == "amd64") &&
+   GOOS != "nacl" &&
+   cpuid_ecx&(1<<25) != 0 && // aes (aesenc)
+  

[PATCH] Fix 78550 ICE with bit-field initialization

[Nathan Sidwell]

This patch fixes 78550, where we ICE in varasm as we discover a 
code-generating NOP_EXPR of an INTEGER_CST.  output_constructor 
(varasm.c) has a STRIP_NOPs, but that leaves the NOP alone, as it is 
truncating a regular QI mode operand to a 1 bit type.


That tree is generated in convert.c:
  /* If TYPE is an enumeral type or a type with a precision less
 than the number of bits in its mode, do the conversion to the
 type corresponding to its mode, then do a nop conversion
 to TYPE.  */

  return fold_build1_loc (dofold, loc, NOP_EXPR, type, ...);
}
Fixed by changing it to maybe_fold_build1_loc.  Surrounding code uses 
that function.


ok?

nathan
--
Nathan Sidwell
2016-12-08  Nathan Sidwell  

	PR c++/78550
	* convert.c (convert_to_integer_1): Maybe fold conversions to
	integral types with fewer bits than its mode.

	testsuite/
	PR c++/78550
	* g++.dg/cpp1y/pr78550.C: New.

Index: convert.c
===
--- convert.c	(revision 243438)
+++ convert.c	(working copy)
@@ -646,10 +646,11 @@ convert_to_integer_1 (tree type, tree ex
 	 to TYPE.  */
   else if (TREE_CODE (type) == ENUMERAL_TYPE
 	   || outprec != GET_MODE_PRECISION (TYPE_MODE (type)))
-	return build1 (NOP_EXPR, type,
-		   convert (lang_hooks.types.type_for_mode
-(TYPE_MODE (type), TYPE_UNSIGNED (type)),
-expr));
+	{
+	  expr = convert (lang_hooks.types.type_for_mode
+			  (TYPE_MODE (type), TYPE_UNSIGNED (type)), expr);
+	  return maybe_fold_build1_loc (dofold, loc, NOP_EXPR, type, expr);
+	}
 
   /* Here detect when we can distribute the truncation down past some
 	 arithmetic.  For example, if adding two longs and converting to an
Index: testsuite/g++.dg/cpp1y/pr78550.C
===
--- testsuite/g++.dg/cpp1y/pr78550.C	(revision 0)
+++ testsuite/g++.dg/cpp1y/pr78550.C	(working copy)
@@ -0,0 +1,22 @@
+// { dg-do compile { target c++14 } }
+
+// PR 78550 ICE with initializer_list and bitfield member
+
+namespace std
+{
+  template 
+  struct initializer_list
+{
+  const T *a;
+  __SIZE_TYPE__ b;
+  constexpr initializer_list (const T *x, __SIZE_TYPE__ y) : a(x), b(y) { }
+};
+}
+template 
+struct A {
+  A (std::initializer_list);
+};
+struct B {
+  int k : 1;
+};
+A a{{0}};

[PATCH, rs6000] Add support for vec_pack and vec_sld built-ins

[Carl E. Love]

GCC maintainers:

The following patch adds two more built-ins that are missing.
Specifically:

vector floatvec_packvector doublevector double
vector double   vec_sld vector doublevector double

The patch has been boot strapped and tested on
powerpc64le-unknown-linux-gnu (Power 8) and on 
powerpc64-unknown-linux-gnu (Power 7) with no regressions.

Is this OK for trunk?

Carl Love

2016-12-08  Carl Love  

   * config/rs6000/rs6000-c.c: Add built-in support for
   vector float  vec_pack  vector double  vector double
   vector double  vec_sld  vector double  vector double
   * config/rs6000/rs6000.c: Add icode check for vsldoi_v2df to allow
   4-bit unsigned literal.
   * config/rs6000/rs6000-builtin.def: Add definition for VSLDOI_2DF
   * doc/extend.texi: Update the built-in documentation file for the
   new powerpc vec_pack and vec_sld built-ins.

gcc/testsuite/ChangeLog:

2016-12-08 Carl Love  

* gcc.target/powerpc/builtins-3.c: Add new test of the test suite
file.
* gcc.target/powerpc/builtins-3.c: Add new test of the test suite
file.
---
 gcc/config/rs6000/rs6000-builtin.def |  1 +
 gcc/config/rs6000/rs6000-c.c |  4 
 gcc/config/rs6000/rs6000.c   |  1 +
 gcc/doc/extend.texi  |  3 +++
 gcc/testsuite/gcc.target/powerpc/builtins-3-p8.c | 10 +-
 gcc/testsuite/gcc.target/powerpc/builtins-3.c|  9 -
 6 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-builtin.def 
b/gcc/config/rs6000/rs6000-builtin.def
index d21f275..68f0936 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -958,6 +958,7 @@ BU_ALTIVEC_3 (VSLDOI_16QI,"vsldoi_16qi",CONST,  
altivec_vsldoi_v16qi)
 BU_ALTIVEC_3 (VSLDOI_8HI, "vsldoi_8hi", CONST, 
altivec_vsldoi_v8hi)
 BU_ALTIVEC_3 (VSLDOI_4SI, "vsldoi_4si", CONST, 
altivec_vsldoi_v4si)
 BU_ALTIVEC_3 (VSLDOI_4SF, "vsldoi_4sf", CONST, 
altivec_vsldoi_v4sf)
+BU_ALTIVEC_3 (VSLDOI_2DF, "vsldoi_2df", CONST, 
altivec_vsldoi_v2df)
 
 /* Altivec DST builtins.  */
 BU_ALTIVEC_D (DST,   "dst",MISC,   altivec_dst)
diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index 4f332d7..bf01a11 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -2118,6 +2118,8 @@ const struct altivec_builtin_types 
altivec_overloaded_builtins[] = {
 RS6000_BTI_unsigned_V4SI, RS6000_BTI_unsigned_V2DI, 
RS6000_BTI_unsigned_V2DI, 0 },
   { ALTIVEC_BUILTIN_VEC_PACK, P8V_BUILTIN_VPKUDUM,
 RS6000_BTI_bool_V4SI, RS6000_BTI_bool_V2DI, RS6000_BTI_bool_V2DI, 0 },
+  { ALTIVEC_BUILTIN_VEC_PACK, P8V_BUILTIN_VPKUDUM,
+RS6000_BTI_V4SF, RS6000_BTI_V2DF, RS6000_BTI_V2DF, 0 },
   { ALTIVEC_BUILTIN_VEC_VPKUWUM, ALTIVEC_BUILTIN_VPKUWUM,
 RS6000_BTI_V8HI, RS6000_BTI_V4SI, RS6000_BTI_V4SI, 0 },
   { ALTIVEC_BUILTIN_VEC_VPKUWUM, ALTIVEC_BUILTIN_VPKUWUM,
@@ -3193,6 +3195,8 @@ const struct altivec_builtin_types 
altivec_overloaded_builtins[] = {
 RS6000_BTI_unsigned_V16QI, RS6000_BTI_unsigned_V16QI, 
RS6000_BTI_unsigned_V16QI, RS6000_BTI_NOT_OPAQUE },
   { ALTIVEC_BUILTIN_VEC_SLD, ALTIVEC_BUILTIN_VSLDOI_16QI,
 RS6000_BTI_bool_V16QI, RS6000_BTI_bool_V16QI, RS6000_BTI_bool_V16QI, 
RS6000_BTI_NOT_OPAQUE },
+  { ALTIVEC_BUILTIN_VEC_SLD, ALTIVEC_BUILTIN_VSLDOI_2DF,
+RS6000_BTI_V2DF, RS6000_BTI_V2DF, RS6000_BTI_V2DF, RS6000_BTI_NOT_OPAQUE },
   { ALTIVEC_BUILTIN_VEC_ST, ALTIVEC_BUILTIN_STVX_V2DF,
 RS6000_BTI_void, RS6000_BTI_V2DF, RS6000_BTI_INTSI, ~RS6000_BTI_V2DF },
   { ALTIVEC_BUILTIN_VEC_ST, ALTIVEC_BUILTIN_STVX_V2DI,
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 59bd3fe..228a6e2 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -15096,6 +15096,7 @@ rs6000_expand_ternop_builtin (enum insn_code icode, 
tree exp, rtx target)
  with identical values.  We'd never reach here at runtime in
  this case.  */
   if (icode == CODE_FOR_altivec_vsldoi_v4sf
+  || icode == CODE_FOR_altivec_vsldoi_v2df
   || icode == CODE_FOR_altivec_vsldoi_v4si
   || icode == CODE_FOR_altivec_vsldoi_v8hi
   || icode == CODE_FOR_altivec_vsldoi_v16qi)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index a8402e1..9477446 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -16513,6 +16513,8 @@ vector unsigned char vec_vslb (vector unsigned char,
vector unsigned char);
 
 vector float vec_sld (vector float, vector float, const int);
+vector double vec_sld (vector double, vector double, const int);
+
 vector signed int vec_sld (vector signed int,
vector signed int,
const int);
@@ -17745,6 +17747,7 @@ vector int vec_pack 

[PATCH, rs6000] whitespace fix for p9-dimode tests

[Will Schmidt]

Hi, 

I am seeing some failures in the p9-dimode tests. This appears to
be due to the scan-assembler strings matching comment portions of the
generated assembly, versus the actual generated assembly. In
particular, the dg-final directive  { scan-assembler-not "ld"}
is matching the "ld" as seen in the string
  # 19 "/home/willschm/gcc/gcc-mainline-vec_fold/..."

This is resolved by adding a leading whitespace regex string "\[ \t\]"
as seen in other tests.

OK for trunk?
Thanks,
-Will

2016-12-08  Will Schmidt 

gcc/testsuite/
* gcc.target/powerpc/dimode-1.c: Update syntax on scan-assembler
strings
* gcc.target/powerpc/dimode-2.c: Likewise.


diff --git a/gcc/testsuite/gcc.target/powerpc/p9-dimode1.c 
b/gcc/testsuite/gcc.target/powerpc/p9-dimode1.c
index 6ba610b..c29b69d 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-dimode1.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-dimode1.c
@@ -43,8 +43,8 @@ p9_minus_1 (void)
   return ret;
 }
 
-/* { dg-final { scan-assembler "xxspltib" } } */
-/* { dg-final { scan-assembler-not "mtvsrd"   } } */
-/* { dg-final { scan-assembler-not "lfd"  } } */
-/* { dg-final { scan-assembler-not "ld"   } } */
-/* { dg-final { scan-assembler-not "lxsd" } } */
+/* { dg-final { scan-assembler "\[ \t\]xxspltib" } } */
+/* { dg-final { scan-assembler-not "\[ \t\]mtvsrd"   } } */
+/* { dg-final { scan-assembler-not "\[ \t\]lfd"  } } */
+/* { dg-final { scan-assembler-not "\[ \t\]ld"   } } */
+/* { dg-final { scan-assembler-not "\[ \t\]lxsd" } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-dimode2.c 
b/gcc/testsuite/gcc.target/powerpc/p9-dimode2.c
index 0567a65..f33d18c 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-dimode2.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-dimode2.c
@@ -21,7 +21,7 @@ p9_large (void)
   return ret;
 }
 
-/* { dg-final { scan-assembler "mtvsrd"   } } */
-/* { dg-final { scan-assembler-not "ld"   } } */
-/* { dg-final { scan-assembler-not "lfd"  } } */
-/* { dg-final { scan-assembler-not "lxsd" } } */
+/* { dg-final { scan-assembler "\[ \t\]mtvsrd" } } */
+/* { dg-final { scan-assembler-not "\[ \t\]ld" } } */
+/* { dg-final { scan-assembler-not "\[ \t\]lfd"} } */
+/* { dg-final { scan-assembler-not "\[ \t\]lxsd"   } } */

Re: Fix PR libstdc++/78264

[Ville Voutilainen]

On 8 December 2016 at 17:53, Eric Botcazou  wrote:
> As documented a few lines below in the same file (but I presume that the
> BADNAMES file is long gone), using _N wreaks havoc on Solaris:


I think this documentation has the same content as BADNAMES used to have?
https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html

libgo patch committed: Allocate _panic struct on heap

[Ian Lance Taylor]

The gc library allocates a _panic struct on the stack. This does not
work for gccgo, because when a deferred function recovers the panic we
unwind the stack up to that point so that returning from the function
will work correctly.

Allocating on the stack fine if the panic is not recovered, and it
works fine if the panic is recovered by a function that returns.
However, it fails if the panic is recovered by a function that itself
panics, and if that second panic is then recovered by a function
higher up on the stack. When we unwind the stack to that second panic,
the g will wind up pointing at a panic farther down on the stack. Even
then everything will often work fine, except when the deferred
function catching the second panic makes a bunch of calls that use
stack space before returning. In that case the code can overwrite the
panic struct, which will then cause disaster when we remove the struct
from the linked list, as the link field will be garbage. This case is
rare enough that all the x86 tests were passing, but there was a
failure on ppc64le.

Before https://golang.org/cl/33414 we allocated the panic struct on
the heap, so go back to doing that again.

This fixes https://golang.org/issue18228.

Patch bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Verified that failing test now passes on ppc64le-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 243442)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-7a941ba323660ec7034cd92d4eab466024a3c72c
+2442fca7be8a4f51ddc91070fa69ef66e24593ac
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/runtime/panic.go
===
--- libgo/go/runtime/panic.go   (revision 243084)
+++ libgo/go/runtime/panic.go   (working copy)
@@ -415,10 +415,19 @@ func gopanic(e interface{}) {
throw("panic holding locks")
}
 
-   var p _panic
-   p.arg = e
-   p.link = gp._panic
-   gp._panic = (*_panic)(noescape(unsafe.Pointer()))
+   // The gc compiler allocates this new _panic struct on the
+   // stack. We can't do that, because when a deferred function
+   // recovers the panic we unwind the stack. We unlink this
+   // entry before unwinding the stack, but that doesn't help in
+   // the case where we panic, a deferred function recovers and
+   // then panics itself, that panic is in turn recovered, and
+   // unwinds the stack past this stack frame.
+
+   p := &_panic{
+   arg:  e,
+   link: gp._panic,
+   }
+   gp._panic = p
 
for {
d := gp._defer

Fix PR libstdc++/78264

[Eric Botcazou]

As documented a few lines below in the same file (but I presume that the 
BADNAMES file is long gone), using _N wreaks havoc on Solaris:

// This marks string literals in header files to be extracted for eventual
// translation.  It is primarily used for messages in thrown exceptions; see
// src/functexcept.cc.  We use __N because the more traditional _N is used
// for something else under certain OSes (see BADNAMES).
#define __N(msgid) (msgid)

Tested on x86-64/Linux and SPARC/Solaris, applied on mainline as obvious.


2016-12-08  Eric Botcazou  

PR libstdc++/78264
* include/bits/c++config (_GLIBCXX_NOEXCEPT_PARM): Turn _N into _NE.
(_GLIBCXX_NOEXCEPT_QUAL): Likewise.

-- 
Eric BotcazouIndex: include/bits/c++config
===
--- include/bits/c++config	(revision 24)
+++ include/bits/c++config	(working copy)
@@ -147,8 +147,8 @@
 #endif
 
 #if __cpp_noexcept_function_type
-#define _GLIBCXX_NOEXCEPT_PARM , bool _N
-#define _GLIBCXX_NOEXCEPT_QUAL noexcept (_N)
+#define _GLIBCXX_NOEXCEPT_PARM , bool _NE
+#define _GLIBCXX_NOEXCEPT_QUAL noexcept (_NE)
 #else
 #define _GLIBCXX_NOEXCEPT_PARM
 #define _GLIBCXX_NOEXCEPT_QUAL

Go patch committed: Make Slice_construction_expression::do_flatten idempotent

[Ian Lance Taylor]

Because of the way the Go frontend handles call expressions with
multiple results, it's possible for expressions to be flattened more
than once.  In the case of Slice_construction_expression, allocating
the slice storage multiple times caused a compiler crash as one of the
Temporary_statement's wound up not getting a backend expression.  This
patch fixes the problem.

The test case for this is https://golang.org/cl/34020.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 243424)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-08d221726e3f50cb197a931ba385fac67f66a028
+7a941ba323660ec7034cd92d4eab466024a3c72c
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 243321)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -12951,8 +12951,8 @@ Slice_construction_expression::do_flatte
   // Base class flattening first
   this->Array_construction_expression::do_flatten(gogo, no, inserter);
 
-  // Create an stack-allocated storage temp if storage won't escape
-  if (!this->storage_escapes_)
+  // Create a stack-allocated storage temp if storage won't escape
+  if (!this->storage_escapes_ && this->slice_storage_ == NULL)
 {
   Location loc = this->location();
   this->array_val_ = create_array_val();

Re: [Patch, Fortran, OOP] PR 61767: ICE in generate_finalization_wrapper at fortran/class.c:1491

[Janus Weil]

Hi Andre,

> so when I interpret the testcase correctly, than the finalizer should not be
> called, right? So adding a call abort() in the Finalize and allocating and
> deallocating M in the main program should do no harm, but make the testcase 
> IMO
> more feasible. What do you think?

thanks for the comment. Indeed it can not hurt to extend it into a
runtime test. New version attached (according to your suggestions). Ok
with this?

Cheers,
Janus



> On Thu, 8 Dec 2016 13:56:29 +0100
> Janus Weil  wrote:
>
>> Hi all,
>>
>> the attached patch fixes an ice-on-valid problem with finalization.
>> The ICE turned out to be caused by a bug in 'has_finalizer_component':
>> According to the documentation, this function is supposed to detect
>> whether a derived type has any nonpointer nonallocatable components
>> that have a finalizer. However it triggered also on pointer components
>> with a finalizer. Fixing this makes the ICE go away.
>>
>> The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?
>>
>> Cheers,
>> Janus
>>
>>
>> 2016-12-08  Janus Weil  
>>
>> PR fortran/61767
>> * class.c (has_finalizer_component): Fix this function to detect only
>> non-pointer non-allocatable components which have a finalizer.
>>
>> 2016-12-08  Janus Weil  
>>
>> PR fortran/61767
>> * gfortran.dg/finalize_31.f90: New test.
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
! { dg-do run }
!
! PR 61767: [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1491
!
! Contributed by 

module Communicator_Form
  implicit none
  type :: CommunicatorForm
  contains
final :: Finalize
  end type
  type :: MessageTemplate
type ( CommunicatorForm ), pointer :: Communicator
  end type
contains
  subroutine Finalize ( C )
type ( CommunicatorForm ) :: C
! should not be called
call abort()
  end subroutine
end module

program p
  use Communicator_Form
  implicit none
  class ( MessageTemplate ), pointer :: M
  allocate(M)
  deallocate(M)
end

[PATCH, testsuite] MIPS: Skip msa-builtins-err.c if there is no assembly output.

[Toma Tabacu]

Hi,

The msa-builtins-err.c test is failing in the following configuration:
-O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
This is because the errors it is checking for are triggered by assembly
generation, which is prevented by -fno-fat-lto-objects.

This patch fixes this by adding a dg-skip-if for -fno-fat-lto-objects.

Tested with mips-mti-elf.

Regards,
Toma Tabacu

gcc/testsuite/ChangeLog:

* gcc.target/mips/msa-builtins-err.c (dg-skip-if): Do not run the test
if -fno-fat-lto-objects is present.

diff --git a/gcc/testsuite/gcc.target/mips/msa-builtins-err.c 
b/gcc/testsuite/gcc.target/mips/msa-builtins-err.c
index 041b7f5..57acee0 100644
--- a/gcc/testsuite/gcc.target/mips/msa-builtins-err.c
+++ b/gcc/testsuite/gcc.target/mips/msa-builtins-err.c
@@ -1,6 +1,7 @@
 /* Test builtins for MIPS MSA ASE instructions */
 /* { dg-do compile } */
 /* { dg-options "-mfp64 -mhard-float -mmsa" } */
+/* { dg-skip-if "needs asm output" { *-*-* } { "-fno-fat-lto-objects" } { "" } 
} */
 
 #include 
 

[PATCH][AArch64] Fix PR78733

[Wilco Dijkstra]

This patch fixes an issue in aarch64_classify_address.  TImode and TFmode
can either use a 64-bit LDP/STP or 128-bit LDR/STR.  The addressing mode
must be carefully modelled as the intersection of both.  This is done for
the immediate offsets, however load_store_pair_p must be set as well to
avoid LDP with a PC-relative address if aarch64_pcrelative_literal_loads
is true.

Bootstrap passes with aarch64_pcrelative_literal_loads=true.

ChangeLog:
2015-12-08  Wilco Dijkstra  

PR target/78733
* config/aarch64/aarch64.c (aarch64_classify_address):
Set load_store_pair_p for TImode and TFmode.

/testsuite
* gcc.target/aarch64/pr78733.c: New test.

--
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 
48efa37b89551264e25effab1dddbcb490fad085..a95f9c183fcd1db95a8366d1d5b5aa878ee51a6c
 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -4230,8 +4230,11 @@ aarch64_classify_address (struct aarch64_address_info 
*info,
   enum rtx_code code = GET_CODE (x);
   rtx op0, op1;
 
-  /* On BE, we use load/store pair for all large int mode load/stores.  */
+  /* On BE, we use load/store pair for all large int mode load/stores.
+ TI/TFmode may also use a load/store pair.  */
   bool load_store_pair_p = (outer_code == PARALLEL
+   || mode == TImode
+   || mode == TFmode
|| (BYTES_BIG_ENDIAN
&& aarch64_vect_struct_mode_p (mode)));
 
diff --git a/gcc/testsuite/gcc.target/aarch64/pr78733.c 
b/gcc/testsuite/gcc.target/aarch64/pr78733.c
new file mode 100644
index 
..ce462cedf9f049feb03addfb010b2f339972c337
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr78733.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mpc-relative-literal-loads" } */
+
+__int128
+t (void)
+{
+  return (__int128)1 << 80;
+}
+
+/* { dg-final { scan-assembler "adr" } } */

Re: [PATCH] Avoid double unread_char (c) in patch 8a of RTL frontend

[Bernd Schmidt]

On 12/08/2016 04:01 AM, David Malcolm wrote:

gcc/ChangeLog:
* read-md.c (md_reader::read_name_1): Write out the location of
the start of the name, rather than the end, eliminating
unread_char and read_char calls.


For avoidance of doubt, ok to check in the currently approved patches 
with this change as well.


-  unread_char (c);
-  *out_loc = get_current_location ();
-  read_char ();


Might be worth trying to look for this pattern in other parts of the 
patch kit to see if it can be replaced.



Bernd

Re: [PATCH] Escape non-printable chars in dumped strings.

[Martin Liška]

There's a patch that adds a new test-case for that.

Martin
>From e8805309edca43153721ce3c79252a4f4a3b2073 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 8 Dec 2016 15:59:28 +0100
Subject: [PATCH] New test

gcc/testsuite/ChangeLog:

2016-12-08  Martin Liska  

	* gcc.dg/tree-ssa/dump-3.c: New test.
---
 gcc/testsuite/gcc.dg/tree-ssa/dump-3.c | 271 +
 1 file changed, 271 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/dump-3.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/dump-3.c b/gcc/testsuite/gcc.dg/tree-ssa/dump-3.c
new file mode 100644
index 000..8533124
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/dump-3.c
@@ -0,0 +1,271 @@
+/* { dg-do compile } */
+/* { dg-options "-O0 -fdump-tree-optimized" } */
+
+int main()
+{
+  char string_0[] = "\x0";
+  char string_1[] = "\x1";
+  char string_2[] = "\x2";
+  char string_3[] = "\x3";
+  char string_4[] = "\x4";
+  char string_5[] = "\x5";
+  char string_6[] = "\x6";
+  char string_7[] = "\x7";
+  char string_8[] = "\x8";
+  char string_9[] = "\x9";
+  char string_10[] = "\xa";
+  char string_11[] = "\xb";
+  char string_12[] = "\xc";
+  char string_13[] = "\xd";
+  char string_14[] = "\xe";
+  char string_15[] = "\xf";
+  char string_16[] = "\x10";
+  char string_17[] = "\x11";
+  char string_18[] = "\x12";
+  char string_19[] = "\x13";
+  char string_20[] = "\x14";
+  char string_21[] = "\x15";
+  char string_22[] = "\x16";
+  char string_23[] = "\x17";
+  char string_24[] = "\x18";
+  char string_25[] = "\x19";
+  char string_26[] = "\x1a";
+  char string_27[] = "\x1b";
+  char string_28[] = "\x1c";
+  char string_29[] = "\x1d";
+  char string_30[] = "\x1e";
+  char string_31[] = "\x1f";
+  char string_32[] = "\x20";
+  char string_33[] = "\x21";
+  char string_34[] = "\x22";
+  char string_35[] = "\x23";
+  char string_36[] = "\x24";
+  char string_37[] = "\x25";
+  char string_38[] = "\x26";
+  char string_39[] = "\x27";
+  char string_40[] = "\x28";
+  char string_41[] = "\x29";
+  char string_42[] = "\x2a";
+  char string_43[] = "\x2b";
+  char string_44[] = "\x2c";
+  char string_45[] = "\x2d";
+  char string_46[] = "\x2e";
+  char string_47[] = "\x2f";
+  char string_48[] = "\x30";
+  char string_49[] = "\x31";
+  char string_50[] = "\x32";
+  char string_51[] = "\x33";
+  char string_52[] = "\x34";
+  char string_53[] = "\x35";
+  char string_54[] = "\x36";
+  char string_55[] = "\x37";
+  char string_56[] = "\x38";
+  char string_57[] = "\x39";
+  char string_58[] = "\x3a";
+  char string_59[] = "\x3b";
+  char string_60[] = "\x3c";
+  char string_61[] = "\x3d";
+  char string_62[] = "\x3e";
+  char string_63[] = "\x3f";
+  char string_64[] = "\x40";
+  char string_65[] = "\x41";
+  char string_66[] = "\x42";
+  char string_67[] = "\x43";
+  char string_68[] = "\x44";
+  char string_69[] = "\x45";
+  char string_70[] = "\x46";
+  char string_71[] = "\x47";
+  char string_72[] = "\x48";
+  char string_73[] = "\x49";
+  char string_74[] = "\x4a";
+  char string_75[] = "\x4b";
+  char string_76[] = "\x4c";
+  char string_77[] = "\x4d";
+  char string_78[] = "\x4e";
+  char string_79[] = "\x4f";
+  char string_80[] = "\x50";
+  char string_81[] = "\x51";
+  char string_82[] = "\x52";
+  char string_83[] = "\x53";
+  char string_84[] = "\x54";
+  char string_85[] = "\x55";
+  char string_86[] = "\x56";
+  char string_87[] = "\x57";
+  char string_88[] = "\x58";
+  char string_89[] = "\x59";
+  char string_90[] = "\x5a";
+  char string_91[] = "\x5b";
+  char string_92[] = "\x5c";
+  char string_93[] = "\x5d";
+  char string_94[] = "\x5e";
+  char string_95[] = "\x5f";
+  char string_96[] = "\x60";
+  char string_97[] = "\x61";
+  char string_98[] = "\x62";
+  char string_99[] = "\x63";
+  char string_100[] = "\x64";
+  char string_101[] = "\x65";
+  char string_102[] = "\x66";
+  char string_103[] = "\x67";
+  char string_104[] = "\x68";
+  char string_105[] = "\x69";
+  char string_106[] = "\x6a";
+  char string_107[] = "\x6b";
+  char string_108[] = "\x6c";
+  char string_109[] = "\x6d";
+  char string_110[] = "\x6e";
+  char string_111[] = "\x6f";
+  char string_112[] = "\x70";
+  char string_113[] = "\x71";
+  char string_114[] = "\x72";
+  char string_115[] = "\x73";
+  char string_116[] = "\x74";
+  char string_117[] = "\x75";
+  char string_118[] = "\x76";
+  char string_119[] = "\x77";
+  char string_120[] = "\x78";
+  char string_121[] = "\x79";
+  char string_122[] = "\x7a";
+  char string_123[] = "\x7b";
+  char string_124[] = "\x7c";
+  char string_125[] = "\x7d";
+  char string_126[] = "\x7e";
+  char string_127[] = "\x7f";
+  char string_128[] = "\x80";
+  char string_129[] = "\x81";
+  char string_130[] = "\x82";
+  char string_131[] = "\x83";
+  char string_132[] = "\x84";
+  char string_133[] = "\x85";
+  char string_134[] = "\x86";
+  char string_135[] = "\x87";
+  char string_136[] = "\x88";
+  char string_137[] = "\x89";
+  char string_138[] = 

Re: [PATCH] Enable -fsanitize-address-use-after-scope only if -fsanitize=address is enabled

[Dmitry Vyukov]

On Wed, Dec 7, 2016 at 10:57 PM, Sandra Loosemore
 wrote:
> On 12/07/2016 12:30 PM, Dmitry Vyukov wrote:
>>
>> On Wed, Dec 7, 2016 at 8:23 PM, Sandra Loosemore
>>  wrote:
>>>
>>>
>>> You need to fix doc/invoke.texi as well to reflect this change.
>>
>>
>> Done.
>>
>> Attached updated patch.
>
>
> The documentation change is OK.


Submitted in 243441

Re: Ping [PATCH, Fortran, pr78505, v1] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[Andre Vehreschild]

Ping!

On Fri, 2 Dec 2016 16:46:29 +0100
Andre Vehreschild  wrote:

> Hi all,
> 
> attached patch adds a call to sync_all after an ALLOCATE allocating a coarray.
> This is to adhere to standard wanting:
> 
> ..., execution of the segment (11.6.2) following the statement is delayed
> until all other active images in the current team have executed the same
> statement the same number of times in this team.
> 
> This, esp. the "statement", means that assigning the SOURCE= is to come before
> the sync all, which means we have to do it explicitly after that assignment.
> Or the other way around the sync all can be done in library caf_register().
> 
> Bootstraps and regtests ok on x86_64-linux/F23. Ok for trunk?
> 
> Regards,
>   Andre


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2016-12-02  Andre Vehreschild  

PR fortran/78505
* trans-stmt.c (gfc_trans_allocate): Add sync all after the execution
of the whole allocate-statement to adhere to the standard.

gcc/testsuite/ChangeLog:

2016-12-02  Andre Vehreschild  

PR fortran/78505
* gfortran.dg/coarray_alloc_with_implicit_sync_1.f90: New test.


diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 514db28..2219bcc 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5506,7 +5506,7 @@ gfc_trans_allocate (gfc_code * code)
   stmtblock_t block;
   stmtblock_t post;
   tree nelems;
-  bool upoly_expr, tmp_expr3_len_flag = false, al_len_needs_set;
+  bool upoly_expr, tmp_expr3_len_flag = false, al_len_needs_set, is_coarray ;
   gfc_symtree *newsym = NULL;
 
   if (!code->ext.alloc.list)
@@ -5516,6 +5516,7 @@ gfc_trans_allocate (gfc_code * code)
   expr3 = expr3_vptr = expr3_len = expr3_esize = NULL_TREE;
   label_errmsg = label_finish = errmsg = errlen = NULL_TREE;
   e3_is = E3_UNSET;
+  is_coarray = false;
 
   gfc_init_block ();
   gfc_init_block ();
@@ -,8 +5556,9 @@ gfc_trans_allocate (gfc_code * code)
  expression.  */
   if (code->expr3)
 {
-  bool vtab_needed = false, temp_var_needed = false,
-	  is_coarray = gfc_is_coarray (code->expr3);
+  bool vtab_needed = false, temp_var_needed = false;
+
+  is_coarray = gfc_is_coarray (code->expr3);
 
   /* Figure whether we need the vtab from expr3.  */
   for (al = code->ext.alloc.list; !vtab_needed && al != NULL;
@@ -6093,6 +6095,9 @@ gfc_trans_allocate (gfc_code * code)
 	  tree caf_decl, token;
 	  gfc_se caf_se;
 
+	  /* Set flag, to add synchronize after the allocate.  */
+	  is_coarray = true;
+
 	  gfc_init_se (_se, NULL);
 
 	  caf_decl = gfc_get_tree_for_caf_expr (expr);
@@ -6114,6 +6119,11 @@ gfc_trans_allocate (gfc_code * code)
 	}
   else
 	{
+	  /* Allocating coarrays needs a sync after the allocate executed.
+	 Set the flag to add the sync after all objects are allocated.  */
+	  is_coarray = is_coarray || (gfc_caf_attr (expr).codimension
+  && flag_coarray == GFC_FCOARRAY_LIB);
+
 	  if (expr->ts.type == BT_CHARACTER && al_len != NULL_TREE
 	  && expr3_len != NULL_TREE)
 	{
@@ -6357,6 +6367,15 @@ gfc_trans_allocate (gfc_code * code)
   gfc_add_modify (, se.expr, tmp);
 }
 
+  if (is_coarray && flag_coarray == GFC_FCOARRAY_LIB)
+{
+  /* Add a sync all after the allocation has been executed.  */
+  tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_sync_all,
+ 3, null_pointer_node, null_pointer_node,
+ integer_zero_node);
+  gfc_add_expr_to_block (, tmp);
+}
+
   gfc_add_block_to_block (, );
   gfc_add_block_to_block (, );
 
diff --git a/gcc/testsuite/gfortran.dg/coarray_alloc_with_implicit_sync_1.f90 b/gcc/testsuite/gfortran.dg/coarray_alloc_with_implicit_sync_1.f90
new file mode 100644
index 000..1dbbcb7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_alloc_with_implicit_sync_1.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+! { dg-options "-fdump-tree-original -fcoarray=lib" }
+! Check that allocating a coarray adds an implicit sync all.
+ 
+ implicit none
+ integer, allocatable :: f(:)[:]
+ allocate( f(20)[*], source = 1 )
+end
+
+! { dg-final { scan-tree-dump-times "_gfortran_caf_sync_all \\(" 1 "original" } }

Re: Ping [PATCH, Fortran, v1] Fix deallocation of nested derived typed components

[Andre Vehreschild]

Ping!

On Fri, 2 Dec 2016 13:28:40 +0100
Andre Vehreschild  wrote:

> Hi all,
> 
> attached patch fixes on ICE, when freeing a scalar allocatable component in a
> derived typed coarray.
> 
> Furthermore does it fix freeing of nested derived typed allocatable
> components. A simple code explains the bug that is solved by the patch:
> 
> type inner
>   integer, allocatable :: i
> end type
> type outer
>   type(inner), allocatable :: link
> end type
> 
> type(outer), allocatable :: obj
> 
> allocate(obj)
> allocate(obj%link)
> allocate(obj%link%i)
> 
> deallocate(obj%link)
> deallocate(obj) ! <- this will generate pseudo-pseudo-code of the kind:
> 
> if (obj.link.i != 0)  // But link is already NULL, i.e. a crash occurs.
>   free(obj.link.i)
> 
> The patch fixes this by moving the code for freeing link.i into the check if
> link is allocated, i.e.:
> 
> if (obj.link != 0) {
>   if (obj.link.i != 0)  {
> free (obj.link.i);
> obj.link.i = 0;
>   }
>   free (obj.link);
>   obj.link = 0;
> }
> 
> Furthermore does the patch ensure that the handle of an allocatable component
> is set to 0.
> 
> Bootstraped and regtested ok on x86_64-linux/F23. Ok for trunk?
> 
> Regards,
>   Andre


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2016-12-02  Andre Vehreschild  

* trans-array.c (structure_alloc_comps): Restructure deallocation of
(nested) allocatable components.  Insert dealloc of sub-component into
the block guarded by the if != NULL for the component.
* trans.c (gfc_deallocate_with_status): Allow deallocation of scalar
and arrays as well as coarrays.
(gfc_deallocate_scalar_with_status): Get the data member for coarrays
only when freeing an array with descriptor.
* trans.h: Change prototype of gfc_deallocate_with_status to allow
adding statements into the block guarded by the if (pointer != 0) and
supply a coarray handle.

gcc/testsuite/ChangeLog:

2016-12-02  Andre Vehreschild  

* gfortran.dg/coarray_alloc_comp_3.f08: New test.
* gfortran.dg/finalize_18.f90: Add count for additional guard against
accessing null-pointer.

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index ac90a4b..a5deb42 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -8157,8 +8157,11 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
   tree null_cond = NULL_TREE;
   tree add_when_allocated;
   tree dealloc_fndecl;
-  bool called_dealloc_with_status;
+  tree caf_token;
   gfc_symbol *vtab;
+  int caf_dereg_mode;
+  symbol_attribute *attr;
+  bool deallocate_called;
 
   gfc_init_block ();
 
@@ -8265,7 +8268,8 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
   bool cmp_has_alloc_comps = (c->ts.type == BT_DERIVED
   || c->ts.type == BT_CLASS)
 && c->ts.u.derived->attr.alloc_comp;
-  bool same_type = c->ts.type == BT_DERIVED && der_type == c->ts.u.derived;
+  bool same_type = (c->ts.type == BT_DERIVED && der_type == c->ts.u.derived)
+	|| (c->ts.type == BT_CLASS && der_type == CLASS_DATA (c)->ts.u.derived);
 
   cdecl = c->backend_decl;
   ctype = TREE_TYPE (cdecl);
@@ -8274,112 +8278,120 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
 	{
 	case DEALLOCATE_ALLOC_COMP:
 
-	  /* gfc_deallocate_scalar_with_status calls gfc_deallocate_alloc_comp
-	 (i.e. this function) so generate all the calls and suppress the
-	 recursion from here, if necessary.  */
-	  called_dealloc_with_status = false;
 	  gfc_init_block ();
 
-	  if ((c->ts.type == BT_DERIVED && !c->attr.pointer)
-	  || (c->ts.type == BT_CLASS && !CLASS_DATA (c)->attr.class_pointer))
-	{
-	  comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
-  decl, cdecl, NULL_TREE);
+	  comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
+  decl, cdecl, NULL_TREE);
 
-	  /* The finalizer frees allocatable components.  */
-	  called_dealloc_with_status
-		= gfc_add_comp_finalizer_call (, comp, c,
-	   purpose == DEALLOCATE_ALLOC_COMP
-	   && caf_enabled (caf_mode));
-	}
+	  /* Shortcut to get the attributes of the component.  */
+	  if (c->ts.type == BT_CLASS)
+	attr = _DATA (c)->attr;
 	  else
-	comp = NULL_TREE;
+	attr = >attr;
 
-	  if (c->attr.allocatable && !c->attr.proc_pointer && !same_type
-	  && (c->attr.dimension
-		  || (caf_enabled (caf_mode)
-		  && (caf_in_coarray (caf_mode) || c->attr.codimension
-	{
-	  /* Allocatable arrays or coarray'ed components (scalar or
-		 array).  */
-	  int caf_dereg_mode
-		  = (caf_in_coarray (caf_mode) || c->attr.codimension)
-		  ? (gfc_caf_is_dealloc_only (caf_mode)
-		 ? GFC_CAF_COARRAY_DEALLOCATE_ONLY
-		 : GFC_CAF_COARRAY_DEREGISTER)
-		  : GFC_CAF_COARRAY_NOCOARRAY;
-	  if (comp == NULL_TREE)
-		comp = fold_build3_loc 

[PATCH, Fortran, pr78672, ctp1, v1] Gfortran test suite failures with a sanitized compiler

[Andre Vehreschild]

Hi all, hi Dominique,

this is the "compile time part 1" (ctp1) patch to fix the issues reported in
gfortran by a sanitized compiler when compiling the testsuite. The patch
addresses all issues besides leaks (ASAN_OPTIONS="detect_leaks=false". Most of
the issues were about assuming certain kinds of data without explicitly
checking, e.g., taking a component-ref for an array-ref and similar.

So this patch only addresses the -fsanitize=address,undefined reports (without
leaks) for running the compiler. I liked to keep this patch small to get it
reviewed quickly. 

I see some other areas of work:

compile time part 2: address the leaks
testsuite run time: address the runtime issues (might have to be split in
others and leaks, too)

So far, is this patch bootstrapping and regtesting fine on x86_64-linux/f23. Ok
for trunk?

Regards,
Andre

PS: @Dominique: I will not commit before you are better and had the time to
test this.
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2016-12-08  Andre Vehreschild  

PR fortran/78672
* data.c (create_character_initializer): Prevent accessing NULL-ptr.
* interface.c (compare_actual_formal): Access the last array-ref.
Prevent taking a REF_COMPONENT for a REF_ARRAY.  Correct indentation.
* module.c (load_omp_udrs): Clear typespec before reading into it.
* trans-decl.c (gfc_build_qualified_array): Prevent accessing the array
when it is a coarray.
* trans-expr.c (gfc_conv_cst_int_power): Use wi::abs()-function instead
of crutch preventing sanitizer's bickering here.
* trans-stmt.c (gfc_trans_deallocate): Only get data-component when it
is a descriptor-array here.


diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c
index 139ce88..4f835b3 100644
--- a/gcc/fortran/data.c
+++ b/gcc/fortran/data.c
@@ -186,7 +186,7 @@ create_character_initializer (gfc_expr *init, gfc_typespec *ts,
   for (i = 0; i < len; i++)
 	dest[start+i] = rvalue->representation.string[i];
 }
-  else
+  else if (rvalue->value.character.string)
 memcpy ([start], rvalue->value.character.string,
 	len * sizeof (gfc_char_t));
 
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 8afba84..4e4d17c 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2803,6 +2803,7 @@ compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
   int i, n, na;
   unsigned long actual_size, formal_size;
   bool full_array = false;
+  gfc_ref *actual_arr_ref;
 
   actual = *ap;
 
@@ -2942,37 +2943,38 @@ compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
 	 and assumed-shape dummies, the string length needs to match
 	 exactly.  */
   if (a->expr->ts.type == BT_CHARACTER
-	   && a->expr->ts.u.cl && a->expr->ts.u.cl->length
-	   && a->expr->ts.u.cl->length->expr_type == EXPR_CONSTANT
-	   && f->sym->ts.u.cl && f->sym->ts.u.cl && f->sym->ts.u.cl->length
-	   && f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT
-	   && (f->sym->attr.pointer || f->sym->attr.allocatable
-	   || (f->sym->as && f->sym->as->type == AS_ASSUMED_SHAPE))
-	   && (mpz_cmp (a->expr->ts.u.cl->length->value.integer,
-			f->sym->ts.u.cl->length->value.integer) != 0))
-	 {
-	   if (where && (f->sym->attr.pointer || f->sym->attr.allocatable))
-	 gfc_warning (OPT_Wargument_mismatch,
-			  "Character length mismatch (%ld/%ld) between actual "
-			  "argument and pointer or allocatable dummy argument "
-			  "%qs at %L",
-			  mpz_get_si (a->expr->ts.u.cl->length->value.integer),
-			  mpz_get_si (f->sym->ts.u.cl->length->value.integer),
-			  f->sym->name, >expr->where);
-	   else if (where)
-	 gfc_warning (OPT_Wargument_mismatch,
-			  "Character length mismatch (%ld/%ld) between actual "
-			  "argument and assumed-shape dummy argument %qs "
-			  "at %L",
-			  mpz_get_si (a->expr->ts.u.cl->length->value.integer),
-			  mpz_get_si (f->sym->ts.u.cl->length->value.integer),
-			  f->sym->name, >expr->where);
-	   return 0;
-	 }
+	  && a->expr->ts.u.cl && a->expr->ts.u.cl->length
+	  && a->expr->ts.u.cl->length->expr_type == EXPR_CONSTANT
+	  && f->sym->ts.type == BT_CHARACTER && f->sym->ts.u.cl
+	  && f->sym->ts.u.cl->length
+	  && f->sym->ts.u.cl->length->expr_type == EXPR_CONSTANT
+	  && (f->sym->attr.pointer || f->sym->attr.allocatable
+	  || (f->sym->as && f->sym->as->type == AS_ASSUMED_SHAPE))
+	  && (mpz_cmp (a->expr->ts.u.cl->length->value.integer,
+		   f->sym->ts.u.cl->length->value.integer) != 0))
+	{
+	  if (where && (f->sym->attr.pointer || f->sym->attr.allocatable))
+	gfc_warning (OPT_Wargument_mismatch,
+			 "Character length mismatch (%ld/%ld) between actual "
+			 "argument and pointer or allocatable dummy argument "
+			 "%qs at %L",
+			 mpz_get_si (a->expr->ts.u.cl->length->value.integer),
+			 mpz_get_si (f->sym->ts.u.cl->length->value.integer),
+			 f->sym->name, >expr->where);
+	  

[PATCH] Escape non-printable chars in dumped strings.

[Martin Liška]

Hello.

Following patch changes behavior in pretty_print_string, where all non-printable
characters are encoded as \x%x. Currently, when some non-printable characters 
are directly
printed to a dump file stream. That makes it complicated to read a dump file 
for instance
via a Python script.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From 0241ee4a366d3c4912def45770945b17c528f920 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 8 Dec 2016 11:22:44 +0100
Subject: [PATCH] Escape non-printable chars in strings.

gcc/ChangeLog:

2016-12-08  Martin Liska  

	* tree-pretty-print.c (pretty_print_string): Escape non-printable
	chars in strings.
---
 gcc/tree-pretty-print.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-pretty-print.c b/gcc/tree-pretty-print.c
index 95db710..5b3e23e 100644
--- a/gcc/tree-pretty-print.c
+++ b/gcc/tree-pretty-print.c
@@ -3869,7 +3869,14 @@ pretty_print_string (pretty_printer *pp, const char *str)
 	  break;
 
 	default:
-	  pp_character (pp, str[0]);
+	  if (!ISPRINT (str[0]))
+	{
+	  char buf[5];
+	  sprintf (buf, "\\x%x", (unsigned char)str[0]);
+	  pp_string (pp, buf);
+	}
+	  else
+	pp_character (pp, str[0]);
 	  break;
 	}
   str++;
-- 
2.10.2

Re: [v3 PATCH] LWG 2766, LWG 2749

[Jonathan Wakely]

On 26/11/16 14:47 +0200, Ville Voutilainen wrote:

--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -287,6 +287,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
swap(array<_Tp, _Nm>& __one, array<_Tp, _Nm>& __two)
noexcept(noexcept(__one.swap(__two)))
{ __one.swap(__two); }
+#if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or gnu++11
+  template
+inline
+typename enable_if<
+  !_GLIBCXX_STD_C::__array_traits<_Tp, _Nm>::_Is_swappable::value>::type
+swap(array<_Tp, _Nm>&, array<_Tp, _Nm>&) = delete;
+#endif

  template
constexpr _Tp&


We need to also delete std::swap for the debug mode version of
array.

I'm removing the 'inline' keyword on these deleted overloads, because
it doesn't do anything.

* include/debug/array (swap): Add deleted overload.
* include/bits/stl_pair.h (swap): Remove redundant inline keyword
from deleted overload.
* include/bits/unique_ptr.h (swap): Likewise.
* include/std/array (swap): Likewise.
* include/std/optional (swap): Likewise.
* include/std/tuple (swap): Likewise.
* include/std/variant (swap): Likewise.
* testsuite/23_containers/array/tuple_interface/get_debug_neg.cc:
Adjust dg-error line numbers.
   * testsuite/23_containers/array/tuple_interface/get_neg.cc: Likewise.
* testsuite/23_containers/array/tuple_interface/
tuple_element_debug_neg.cc: Likewise.
   * testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc:
   Likewise.

Tested powerpc64le-linux, committed to trunk.

commit e217847dc333862d70cf8376c09c0b96296d6b54
Author: Jonathan Wakely 
Date:   Thu Dec 8 12:03:39 2016 +

Delete std::swap for debug mode array

	* include/debug/array (swap): Add deleted overload.
	* include/bits/stl_pair.h (swap): Remove redundant inline keyword
	from deleted overload.
	* include/bits/unique_ptr.h (swap): Likewise.
	* include/std/array (swap): Likewise.
	* include/std/optional (swap): Likewise.
	* include/std/tuple (swap): Likewise.
	* include/std/variant (swap): Likewise.
	* testsuite/23_containers/array/tuple_interface/get_debug_neg.cc:
	Adjust dg-error line numbers.
	* testsuite/23_containers/array/tuple_interface/get_neg.cc: Likewise.
	* testsuite/23_containers/array/tuple_interface/
	tuple_element_debug_neg.cc: Likewise.
	* testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc:
	Likewise.

diff --git a/libstdc++-v3/include/bits/stl_pair.h b/libstdc++-v3/include/bits/stl_pair.h
index 981dbeb..01c7134 100644
--- a/libstdc++-v3/include/bits/stl_pair.h
+++ b/libstdc++-v3/include/bits/stl_pair.h
@@ -481,7 +481,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or gnu++11
   template
-inline
 typename enable_if,
 			   __is_swappable<_T2>>::value>::type
 swap(pair<_T1, _T2>&, pair<_T1, _T2>&) = delete;
diff --git a/libstdc++-v3/include/bits/unique_ptr.h b/libstdc++-v3/include/bits/unique_ptr.h
index 03f9bfc..56e6ec0 100644
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -652,7 +652,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or gnu++11
   template
-inline
 typename enable_if::value>::type
 swap(unique_ptr<_Tp, _Dp>&,
 	 unique_ptr<_Tp, _Dp>&) = delete;
diff --git a/libstdc++-v3/include/debug/array b/libstdc++-v3/include/debug/array
index 48ab2fd..63e6808 100644
--- a/libstdc++-v3/include/debug/array
+++ b/libstdc++-v3/include/debug/array
@@ -260,6 +260,14 @@ namespace __debug
 { return !(__one < __two); }
 
   // Specialized algorithms.
+
+#if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or gnu++11
+  template
+typename enable_if<
+  !_GLIBCXX_STD_C::__array_traits<_Tp, _Nm>::_Is_swappable::value>::type
+swap(array<_Tp, _Nm>&, array<_Tp, _Nm>&) = delete;
+#endif
+
   template
 inline void
 swap(array<_Tp, _Nm>& __one, array<_Tp, _Nm>& __two)
diff --git a/libstdc++-v3/include/std/array b/libstdc++-v3/include/std/array
index fa7bac6..f5028c9 100644
--- a/libstdc++-v3/include/std/array
+++ b/libstdc++-v3/include/std/array
@@ -290,7 +290,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 
 #if __cplusplus > 201402L || !defined(__STRICT_ANSI__) // c++1z or gnu++11
   template
-inline
 typename enable_if<
   !_GLIBCXX_STD_C::__array_traits<_Tp, _Nm>::_Is_swappable::value>::type
 swap(array<_Tp, _Nm>&, array<_Tp, _Nm>&) = delete;
diff --git a/libstdc++-v3/include/std/optional b/libstdc++-v3/include/std/optional
index 191d64b..3d69e10 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -930,7 +930,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { __lhs.swap(__rhs); }
 
   template
-inline enable_if_t && is_swappable_v<_Tp>)>
+

Re: [Patch, Fortran, OOP] PR 61767: ICE in generate_finalization_wrapper at fortran/class.c:1491

[Andre Vehreschild]

Hi Janus,

so when I interpret the testcase correctly, than the finalizer should not be
called, right? So adding a call abort() in the Finalize and allocating and
deallocating M in the main program should do no harm, but make the testcase IMO
more feasible. What do you think?

- Andre


On Thu, 8 Dec 2016 13:56:29 +0100
Janus Weil  wrote:

> Hi all,
> 
> the attached patch fixes an ice-on-valid problem with finalization.
> The ICE turned out to be caused by a bug in 'has_finalizer_component':
> According to the documentation, this function is supposed to detect
> whether a derived type has any nonpointer nonallocatable components
> that have a finalizer. However it triggered also on pointer components
> with a finalizer. Fixing this makes the ICE go away.
> 
> The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?
> 
> Cheers,
> Janus
> 
> 
> 2016-12-08  Janus Weil  
> 
> PR fortran/61767
> * class.c (has_finalizer_component): Fix this function to detect only
> non-pointer non-allocatable components which have a finalizer.
> 
> 2016-12-08  Janus Weil  
> 
> PR fortran/61767
> * gfortran.dg/finalize_31.f90: New test.


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

[Patch, Fortran, OOP] PR 61767: ICE in generate_finalization_wrapper at fortran/class.c:1491

[Janus Weil]

Hi all,

the attached patch fixes an ice-on-valid problem with finalization.
The ICE turned out to be caused by a bug in 'has_finalizer_component':
According to the documentation, this function is supposed to detect
whether a derived type has any nonpointer nonallocatable components
that have a finalizer. However it triggered also on pointer components
with a finalizer. Fixing this makes the ICE go away.

The patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?

Cheers,
Janus


2016-12-08  Janus Weil  

PR fortran/61767
* class.c (has_finalizer_component): Fix this function to detect only
non-pointer non-allocatable components which have a finalizer.

2016-12-08  Janus Weil  

PR fortran/61767
* gfortran.dg/finalize_31.f90: New test.
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revision 243433)
+++ gcc/fortran/class.c (working copy)
@@ -841,20 +841,19 @@ has_finalizer_component (gfc_symbol *derived)
gfc_component *c;
 
   for (c = derived->components; c; c = c->next)
-{
-  if (c->ts.type == BT_DERIVED && c->ts.u.derived->f2k_derived
- && c->ts.u.derived->f2k_derived->finalizers)
-   return true;
+if (c->ts.type == BT_DERIVED && !c->attr.pointer && !c->attr.allocatable)
+  {
+   if (c->ts.u.derived->f2k_derived
+   && c->ts.u.derived->f2k_derived->finalizers)
+ return true;
 
-  /* Stop infinite recursion through this function by inhibiting
-calls when the derived type and that of the component are
-the same.  */
-  if (c->ts.type == BT_DERIVED
- && !gfc_compare_derived_types (derived, c->ts.u.derived)
- && !c->attr.pointer && !c->attr.allocatable
- && has_finalizer_component (c->ts.u.derived))
-   return true;
-}
+   /* Stop infinite recursion through this function by inhibiting
+ calls when the derived type and that of the component are
+ the same.  */
+   if (!gfc_compare_derived_types (derived, c->ts.u.derived)
+   && has_finalizer_component (c->ts.u.derived))
+ return true;
+  }
   return false;
 }
 
! { dg-do compile }
!
! PR 61767: [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1491
!
! Contributed by 

module Communicator_Form
  implicit none
  type :: CommunicatorForm
  contains
final :: Finalize
  end type
  type :: MessageTemplate
type ( CommunicatorForm ), pointer :: Communicator
  end type
contains
  subroutine Finalize ( C )
type ( CommunicatorForm ) :: C
  end subroutine
end module

program p
  use Communicator_Form
  implicit none
  class ( MessageTemplate ), pointer :: M
end

[PATCH] Print 2 digits after decimal delimiter for BB frequencies

[Martin Liška]

With the patch applied, one can distinguish between PROB_VERY_UNLIKELY and
real zero probability:

f ()
{
  int _1;

   [100.00%]:
  _1 = __builtin_sprintf (, "%i", 12);
  if (_1 != 2)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin_abort ();

   [99.96%]:
  return;

} 

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Ready to be installed?
Martin
>From 18f0fa35f91db675f5abf6a0aa8cf3582e79c772 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Thu, 1 Dec 2016 10:55:55 +0100
Subject: [PATCH] Print 2 digits after decimal delimiter for BB frequencies

gcc/ChangeLog:

2016-12-01  Martin Liska  

	* gimple-pretty-print.c (dump_edge_probability): Use newly
	defined PROBABILITY_FORMAT.
	(dump_gimple_label): Likewise.
	(dump_gimple_bb_header): Likewise.

gcc/testsuite/ChangeLog:

2016-12-02  Martin Liska  

	* gcc.dg/tree-ssa/20040703-1.c: Update scanned pattern.
	* gcc.dg/tree-ssa/dump-2.c: Likewise.
---
 gcc/gimple-pretty-print.c  | 12 +---
 gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/dump-2.c |  2 +-
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c
index b5e866d..de57e89 100644
--- a/gcc/gimple-pretty-print.c
+++ b/gcc/gimple-pretty-print.c
@@ -72,12 +72,17 @@ debug_gimple_stmt (gimple *gs)
   print_gimple_stmt (stderr, gs, 0, TDF_VOPS|TDF_MEMSYMS);
 }
 
+/* Print format used for displaying probability of an edge or frequency
+   of a basic block.  */
+
+#define PROBABILITY_FORMAT "[%.2f%%]"
+
 /* Dump E probability to BUFFER.  */
 
 static void
 dump_edge_probability (pretty_printer *buffer, edge e)
 {
-  pp_scalar (buffer, " [%.1f%%]",
+  pp_scalar (buffer, " " PROBABILITY_FORMAT,
 	 e->probability * 100.0 / REG_BR_PROB_BASE);
 }
 
@@ -1023,7 +1028,7 @@ dump_gimple_label (pretty_printer *buffer, glabel *gs, int spc, int flags)
   dump_generic_node (buffer, label, spc, flags, false);
   basic_block bb = gimple_bb (gs);
   if (bb && !(flags & TDF_GIMPLE))
-	pp_scalar (buffer, " [%.1f%%]",
+	pp_scalar (buffer, " " PROBABILITY_FORMAT,
 		   bb->frequency * 100.0 / REG_BR_PROB_BASE);
   pp_colon (buffer);
 }
@@ -2590,7 +2595,8 @@ dump_gimple_bb_header (FILE *outf, basic_block bb, int indent, int flags)
 	  if (flags & TDF_GIMPLE)
 	fprintf (outf, "%*sbb_%d:\n", indent, "", bb->index);
 	  else
-	fprintf (outf, "%*s [%.1f%%]:\n", indent, "", bb->index,
+	fprintf (outf, "%*s " PROBABILITY_FORMAT ":\n",
+		 indent, "", bb->index,
 		 bb->frequency * 100.0 / REG_BR_PROB_BASE);
 	}
 }
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c b/gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c
index 2980047..eb9fb56 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/20040703-1.c
@@ -9,4 +9,4 @@ float foo(float x)
 }
 
 /* We should *not* fold the arithmetic.  */
-/* { dg-final { scan-tree-dump-times "0\\.0\[^%\]" 0 "dom2"} } */
+/* { dg-final { scan-tree-dump-times "0\\.0\[^%0\]" 0 "dom2"} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/dump-2.c b/gcc/testsuite/gcc.dg/tree-ssa/dump-2.c
index 11cde92..8a63af4 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/dump-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/dump-2.c
@@ -6,4 +6,4 @@ int f(void)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump " \\\[100\\\.0%\\\]:" "optimized" } } */
+/* { dg-final { scan-tree-dump " \\\[100\\\.00%\\\]:" "optimized" } } */
-- 
2.10.2

Re: [RFC][PATCH] Speed-up use-after-scope (re-writing to SSA)

[Martin Liška]

On 12/02/2016 01:29 PM, Richard Biener wrote:
> On Thu, Dec 1, 2016 at 5:30 PM, Martin Liška  wrote:
>> On 11/23/2016 03:13 PM, Jakub Jelinek wrote:
>>> On Wed, Nov 23, 2016 at 02:57:07PM +0100, Martin Liška wrote:
 I started review process in libsanitizer: https://reviews.llvm.org/D26965
 And I have a question that was asked in the review: can we distinguish 
 between load and store
 in case of having usage of ASAN_POISON?
>>>
>>> I think with ASAN_POISON it is indeed just loads from after scope that can
>>> be caught, a store overwrites the variable with a new value and when turning
>>> the store after we make the var no longer addressable into SSA form, we
>>> loose information about the out of scope store.  Furthermore, if there is
>>> first a store and then a read, like:
>>>   if (argc != 12312)
>>> {
>>>   char my_char;
>>>   ptr = _char;
>>> }
>>>   *ptr = i + 26;
>>>   return *ptr;
>>> we don't notice even the read.  Not sure what could be done against that
>>> though.  I think we'd need to hook into the into-ssa framework, there it
>>> should know the current value of the variable at the point of the store is
>>> result of ASAN_POISON and be able to instead of turning that
>>>   my_char = _23;
>>> into
>>>   my_char_35 = _23;
>>> turn it into:
>>>   my_char_35 = ASAN_POISON (_23);
>>> which would represent after scope store into my_char.
>>>
>>> Not really familiar with into-ssa though to know where to do it.
>>>
>>>   Jakub
>>>
>>
>> Richi, may I ask you for help with this question?
> 
> Probably where we handle the CLOBBER case (rewrite_stmt, maybe_register_def),
> we do this for -Wuninitialized.
> 
> Richard.

Thanks for the tip, however as the optimization of memory address store + load 
happens
before we rewrite my_char into SSA, it would be probably hard to guess which 
memory
stores and loads should be preserved:

use-after-scope-20.c.032t.ccp1:
main (int argc, char * * argv)
{
  int my_char;
  int * ptr;
  int _1;
  int _11;

   [0.0%]:
  if (argc_4(D) != 12312)
goto ; [0.0%]
  else
goto ; [0.0%]

   [0.0%]:
  ASAN_MARK (2, _char, 4);
  ptr_8 = _char;
  ASAN_MARK (1, _char, 4);

   [0.0%]:
  # ptr_2 = PHI 
  _1 = argc_4(D) + 26;
  *ptr_2 = _1;
  _11 = *ptr_2;
  return _11;

}

I sent updated version of patch to LLVM phabricator:
https://reviews.llvm.org/D26965

Hopefully we can cherry pick the patch very soon to our trunk.

M.

> 
>> Thanks,
>> Martin
>>

[PATCH] Fix filesystem test that fails in debug mode

[Jonathan Wakely]

One of the test strings is empty, so we shouldn't use front() on it.

* testsuite/experimental/filesystem/path/construct/range.cc: Don't
use basic_string::front() when string might be empty.

Tested x86_64-linux, committing to trunk.

commit 116f2615e837bb6f4ed6f6b951205a5be717e910
Author: Jonathan Wakely 
Date:   Thu Dec 8 12:37:04 2016 +

Fix filesystem test that fails in debug mode

* testsuite/experimental/filesystem/path/construct/range.cc: Don't
use basic_string::front() when string might be empty.

diff --git 
a/libstdc++-v3/testsuite/experimental/filesystem/path/construct/range.cc 
b/libstdc++-v3/testsuite/experimental/filesystem/path/construct/range.cc
index 3dfec2f..9e51e0a 100644
--- a/libstdc++-v3/testsuite/experimental/filesystem/path/construct/range.cc
+++ b/libstdc++-v3/testsuite/experimental/filesystem/path/construct/range.cc
@@ -59,13 +59,14 @@ test01()
 using __gnu_test::test_container;
 using __gnu_test::input_iterator_wrapper;
 // Test with input iterators and const value_types
+
 test_container
-  r1((), () + s.size());
+  r1((char*)s.c_str(), (char*)s.c_str() + s.size());
 path p9(r1.begin(), r1.end());
 compare_paths(p1, p9);
 
 test_container
-  r2((), () + s.size() + 1); // includes null-terminator
+  r2((char*)s.c_str(), (char*)s.c_str() + s.size() + 1); // includes 
null-terminator
 path p10(r2.begin());
 compare_paths(p1, p10);
 
@@ -82,12 +83,12 @@ test01()
 #if _GLIBCXX_USE_WCHAR_T
 // Test with input iterators and const value_types
 test_container
-  r5((), () + ws.size());
+  r5((wchar_t*)ws.c_str(), (wchar_t*)ws.c_str() + ws.size());
 path p13(r5.begin(), r5.end());
 compare_paths(p1, p13);
 
 test_container
-  r6((), () + ws.size() + 1); // includes null-terminator
+  r6((wchar_t*)ws.c_str(), (wchar_t*)ws.c_str() + ws.size() + 1); // 
includes null-terminator
 path p14(r6.begin());
 compare_paths(p1, p14);
 

cprop fix for PR78626

[Bernd Schmidt]

This is another case where an optimization turns a trap_if 
unconditional. We have to defer changing the CFG, since the rest of 
cprop seems to blow up when we modify things while scanning.


Bootstrapped and tested on x86_64-linux, and reportedly fixes the 
problem on ppc, ok?



Bernd
	PR rtl-optimization/78626
	* cprop.c (one_cprop_pass): Collect unconditional traps in the middle
	of a block, and split such blocks after everything else is finished.

	PR rtl-optimization/78626
	* gcc.dg/torture/pr78626.c: New test.

Index: gcc/cprop.c
===
--- gcc/cprop.c	(revision 243310)
+++ gcc/cprop.c	(working copy)
@@ -1794,7 +1794,7 @@ one_cprop_pass (void)
   if (set_hash_table.n_elems > 0)
 {
   basic_block bb;
-  rtx_insn *insn;
+  auto_vec uncond_traps;
 
   alloc_cprop_mem (last_basic_block_for_fn (cfun),
 		   set_hash_table.n_elems);
@@ -1810,6 +1810,9 @@ one_cprop_pass (void)
 		  EXIT_BLOCK_PTR_FOR_FN (cfun),
 		  next_bb)
 	{
+	  rtx_insn *first_uncond_trap = NULL;
+	  rtx_insn *insn;
+
 	  /* Reset tables used to keep track of what's still valid [since
 	 the start of the block].  */
 	  reset_opr_set_tables ();
@@ -1825,11 +1828,26 @@ one_cprop_pass (void)
 		   insn into a NOTE, or deleted the insn.  */
 		if (! NOTE_P (insn) && ! insn->deleted ())
 		  mark_oprs_set (insn);
+
+		if (first_uncond_trap == NULL
+		&& GET_CODE (PATTERN (insn)) == TRAP_IF
+		&& XEXP (PATTERN (insn), 0) == const1_rtx)
+		  first_uncond_trap = insn;
 	  }
+	  if (first_uncond_trap != NULL && first_uncond_trap != BB_END (bb))
+	uncond_traps.safe_push (first_uncond_trap);
 	}
 
   changed |= bypass_conditional_jumps ();
 
+  while (!uncond_traps.is_empty ())
+	{
+	  rtx_insn *insn = uncond_traps.pop ();
+	  basic_block to_split = BLOCK_FOR_INSN (insn);
+	  remove_edge (split_block (to_split, insn));
+	  emit_barrier_after_bb (to_split);
+	}
+
   FREE_REG_SET (reg_set_bitmap);
   free_cprop_mem ();
 }
Index: gcc/testsuite/gcc.dg/torture/pr78626.c
===
--- gcc/testsuite/gcc.dg/torture/pr78626.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr78626.c	(working copy)
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+
+int qs;
+
+void
+ms (int g1)
+{
+  int cy;
+  int *fr = 
+
+  for (;;)
+{
+  *fr = 1;
+  fr = 
+
+  while (qs != 0)
+{
+  if (qs | cy)
+qs = g1 / 0; /* { dg-warning "division" } */
+  ++qs;
+}
+
+  cy = 1;
+  while (cy != 0)
+cy = 2;
+}
+}

[PATCH] PR71856 try to fix Parallel Mode assertions again

[Jonathan Wakely]

This should fix this bug properly, by renaming __glibcxx_assert to
__glibcxx_assert_impl, and then using it as __glibcxx_assert when
_GLIBCXX_ASSERTIONS is defined, and/or using it as
_GLIBCXX_PARALLEL_ASSERT when _GLIBCXX_PARALLEL_ASSERTIONS is defined.

This allows us to enable __glibcxx_assert and _GLIBCXX_PARALLEL_ASSERT
independently, so that turning on Parallel Mode assertions doesn't
turn on assertions in the rest of the library.

PR libstdc++/71856
* doc/xml/manual/using.xml: Document macro.
* include/bits/c++config [_GLIBCXX_DEBUG || _GLIBCXX_PARALLEL]
(__glibcxx_assert): Rename to __glibcxx_assert_impl.
[_GLIBCXX_DEBUG] (__glibcxx_assert): Expand to __glibcxx_assert_impl.
* include/parallel/base.h [_GLIBCXX_PARALLEL_ASSERTIONS]
(_GLIBCXX_PARALLEL_ASSERT): Expand to __glibcxx_assert_impl.
[!_GLIBCXX_PARALLEL_ASSERTIONS] (_GLIBCXX_PARALLEL_ASSERT): Define as
empty.
* testsuite/25_algorithms/headers/algorithm/
parallel_algorithm_assert2.cc: New test.

Tested powerpc64le-linux, committed to trunk.

commit 49fca73d71a0f3906347686b278ce0573b1ab8e2
Author: Jonathan Wakely 
Date:   Wed Oct 5 18:04:57 2016 +0100

PR71856 try to fix Parallel Mode assertions again

PR libstdc++/71856
* doc/xml/manual/using.xml: Document macro.
* include/bits/c++config [_GLIBCXX_DEBUG || _GLIBCXX_PARALLEL]
(__glibcxx_assert): Rename to __glibcxx_assert_impl.
[_GLIBCXX_DEBUG] (__glibcxx_assert): Expand to __glibcxx_assert_impl.
* include/parallel/base.h [_GLIBCXX_PARALLEL_ASSERTIONS]
(_GLIBCXX_PARALLEL_ASSERT): Expand to __glibcxx_assert_impl.
[!_GLIBCXX_PARALLEL_ASSERTIONS] (_GLIBCXX_PARALLEL_ASSERT): Define as
empty.
* testsuite/25_algorithms/headers/algorithm/
parallel_algorithm_assert2.cc: New test.

diff --git a/libstdc++-v3/doc/xml/manual/using.xml 
b/libstdc++-v3/doc/xml/manual/using.xml
index ee76fef..c06ce16 100644
--- a/libstdc++-v3/doc/xml/manual/using.xml
+++ b/libstdc++-v3/doc/xml/manual/using.xml
@@ -948,6 +948,15 @@ g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc 
-o test.exe
mode.
   
 
+_GLIBCXX_PARALLEL_ASSERTIONS
+
+  Undefined by default, but when any parallel mode header is included
+  this macro will be defined to a non-zero value if
+  _GLIBCXX_ASSERTIONS has a non-zero value, otherwise to zero.
+  When defined to a non-zero value, it enables extra error checking and
+  assertions in the parallel mode.
+  
+
 
 _GLIBCXX_PROFILE
 
diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index 8a27d14..39e55f4 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -434,9 +434,8 @@ namespace std
 #endif
 
 // Assert.
-#if !defined(_GLIBCXX_ASSERTIONS) && !defined(_GLIBCXX_PARALLEL)
-# define __glibcxx_assert(_Condition)
-#else
+#if defined(_GLIBCXX_ASSERTIONS) \
+  || defined(_GLIBCXX_PARALLEL) || defined(_GLIBCXX_PARALLEL_ASSERTIONS)
 namespace std
 {
   // Avoid the use of assert, because we're trying to keep the 
@@ -450,7 +449,7 @@ namespace std
 __builtin_abort();
   }
 }
-#define __glibcxx_assert(_Condition)\
+#define __glibcxx_assert_impl(_Condition)   \
   do\
   { \
 if (! (_Condition))  \
@@ -459,6 +458,12 @@ namespace std
   } while (false)
 #endif
 
+#if defined(_GLIBCXX_ASSERTIONS)
+# define __glibcxx_assert(_Condition) __glibcxx_assert_impl(_Condition)
+#else
+# define __glibcxx_assert(_Condition)
+#endif
+
 // Macros for race detectors.
 // _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(A) and
 // _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(A) should be used to explain
diff --git a/libstdc++-v3/include/parallel/base.h 
b/libstdc++-v3/include/parallel/base.h
index 7d4b69e..721c42d 100644
--- a/libstdc++-v3/include/parallel/base.h
+++ b/libstdc++-v3/include/parallel/base.h
@@ -419,7 +419,11 @@ namespace __gnu_parallel
}
 }
 
-#define _GLIBCXX_PARALLEL_ASSERT(_Condition) __glibcxx_assert(_Condition)
+#if _GLIBCXX_PARALLEL_ASSERTIONS && defined(__glibcxx_assert_impl)
+#define _GLIBCXX_PARALLEL_ASSERT(_Condition) __glibcxx_assert_impl(_Condition)
+#else
+#define _GLIBCXX_PARALLEL_ASSERT(_Condition)
+#endif
 
 } //namespace __gnu_parallel
 
diff --git 
a/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
 
b/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
new file mode 100644
index 000..c40985e
--- /dev/null
+++ 
b/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
@@ -0,0 +1,50 @@
+// { 

Re: [PATCH][ARM] PR target/71436: Restrict *load_multiple pattern till after LRA

[Kyrill Tkachov]

Ping.
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg03078.html

Thanks,
Kyrill

On 30/11/16 16:47, Kyrill Tkachov wrote:

Hi all,

In this awkward ICE we have a *load_multiple pattern that is being transformed 
in reload from:
(insn 55 67 151 3 (parallel [
(set (reg:SI 0 r0)
(mem/u/c:SI (reg/f:SI 147) [2 c+0 S4 A32]))
(set (reg:SI 158 [ c+4 ])
(mem/u/c:SI (plus:SI (reg/f:SI 147)
(const_int 4 [0x4])) [2 c+4 S4 A32]))
]) arm-crash.c:25 393 {*load_multiple}
 (expr_list:REG_UNUSED (reg:SI 0 r0)
(nil)))


into the invalid:
(insn 55 67 70 3 (parallel [
(set (reg:SI 0 r0)
(mem/u/c:SI (reg/f:SI 5 r5 [147]) [2 c+0 S4 A32]))
(set (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -4 [0xfffc])) [4 %sfp+-12 S4 
A32])
(mem/u/c:SI (plus:SI (reg/f:SI 5 r5 [147])
(const_int 4 [0x4])) [2 c+4 S4 A32]))
]) arm-crash.c:25 393 {*load_multiple}
 (nil))

The operands of *load_multiple are not validated through constraints like LRA 
is used to, but rather through
a match_parallel predicate which ends up calling ldm_stm_operation_p to 
validate the multiple sets.
But this means that LRA cannot reason about the constraints properly.
This two-regiseter load should not have used *load_multiple anyway, it should 
have used *ldm2_ from ldmstm.md
and indeed it did until the loop2_invariant pass which copied the ldm2_ pattern:
(insn 27 23 28 4 (parallel [
(set (reg:SI 0 r0)
(mem/u/c:SI (reg/f:SI 147) [2 c+0 S4 A32]))
(set (reg:SI 1 r1)
(mem/u/c:SI (plus:SI (reg/f:SI 147)
(const_int 4 [0x4])) [2 c+4 S4 A32]))
]) "ldm.c":25 385 {*ldm2_}
 (nil))

into:
(insn 55 19 67 3 (parallel [
(set (reg:SI 0 r0)
(mem/u/c:SI (reg/f:SI 147) [2 c+0 S4 A32]))
(set (reg:SI 158)
(mem/u/c:SI (plus:SI (reg/f:SI 147)
(const_int 4 [0x4])) [2 c+4 S4 A32]))
]) "ldm.c":25 404 {*load_multiple}
 (expr_list:REG_UNUSED (reg:SI 0 r0)
(nil)))

Note that it now got recognised as load_multiple because the second register is 
not a hard register but the pseudo 158.
In any case, the solution suggested in the PR (and I agree with it) is to 
restrict *load_multiple to after reload.
The similar pattern *load_multiple_with_writeback also has a similar condition 
and the comment above *load_multiple says that
it's used to generate epilogues, which is done after reload anyway. For 
pre-reload load-multiples the patterns in ldmstm.md
should do just fine.

Bootstrapped and tested on arm-none-linux-gnueabihf.

Ok for trunk?

Thanks,
Kyrill

2016-11-30  Kyrylo Tkachov  

PR target/71436
* config/arm/arm.md (*load_multiple): Add reload_completed to
matching condition.

2016-11-30  Kyrylo Tkachov  

PR target/71436
* gcc.c-torture/compile/pr71436.c: New test.

Re: [PATCH] improve string find algorithm

[Jonathan Wakely]

On 07/12/16 11:46 -0600, Aditya Kumar wrote:

Here is an improved version of basic_string::find. The idea is to
split the string find in two parts:
1. search for the first match by using traits_type::find (this gets converted 
to memchr for x86)
2. see if there is a match (this gets converted to memcmp for x86)


This is a good approach, and more portable than my own attempt using
the GNU memmem function.

I'll run some tests of my own...

Re: [PATCH] [PR78112] Remove the g++.dg/pr78112.C testcase

[Pierre-Marie de Rodat]

Hello Mike,

On 11/30/2016 09:12 PM, Mike Stump wrote:

So, I noticed this and didn't see who you wanted to review it so,
since it was C++, I thought I'd take a look at it.  Ick.  Complex
issue.


I did not have anyone special in mind actually, so thank you for having 
had a look. :-)



One way to test this would be to have a internal check in the
compiler for the thing you don't want to happen as an assert, and
then have the unpatched compiler abort when given the test case
before the work that cause fixed the original PR.  The test case then
shows the failure, and should anyone break it, the internal check
will catch the problem and abort, thus causing the test case to then
fail (again).


I guess the internal check of relevance here would be “check that when 
adding an attribute to a DIE, existing attributes on this DIE don’t have 
the same DW_AT_* kind”. Unfortunately, we know this invariant is still 
violated (and was before my first changes affecting this), so I don’t 
think this is possible right now unless someone spends more time 
investigating why there are duplicate attributes and how to fix them.



Then, you only need to compile the test case and expect a non-zero
output from the compilation.  On darwin, the excess message from
dsymutil should be findable by dejagnu and should also be able to
fail the test case on darwin.


That being said, I’m still wondering why dsymutil produces no error even 
though there are still duplicate attributes (less of them, but still 
some). Maybe because DW_AT_object_pointer is not emitted on Darwin 
(which uses -gdwarf-2 by default) and because the DW_AT_inline duplicate 
does not appear there as well? Anyway…



If you like that design (and a dwarf maintainer likes that design),
then you can fix this test case by removing:


-/* { dg-final { scan-assembler-times DW_AT_inline 6 { xfail *-*-aix* } } } */
-/* { dg-final { scan-assembler-times DW_AT_object_pointer 37 { xfail *-*-aix* 
} } } */


alone and otherwise keep the full test case.


I’m fine with keeping this testcase and updating it as you said. It will 
be useful only for Darwin users, though, but I guess that’s better than 
nothing as it will clearly relate the regression to this whole 
discussion when there is a failure on this platform.



When looking at the test case, I wonder just how reduced it really
was.  The last possible option would be to reduce the test case
further and see if the problem can be eliminated that way.  Again,
I'll pre-approve the test suite part of any of those solutions you
like best.


I already tried to reduce it as much as possible: see 
. On my 
x86_64-linux box, I tried to build several cross-compilers 
(x86_64-apple-darwin16.3.0 and arm-none-eabi) in order to see how this 
reduced reproducer behaves: it looks like we have a consistent number of 
DW_AT_object_pointer attributes for it as long as we force -gdwarf-4 
(the default is -gdwarf-2 on Darwin), which is: 18 times. So here is an 
updated patch that removes the trouble some check in pr78112.C and that 
adds the reduced testcase as pr78112-2.C.


Thank you for the pre-approval: I’ve just pushed this fix. For the 
record, I’ve checked it runs fine on x86_64-linux and 
x86_64-apple-darwin-16.3.0 and I’ve checked manually we have the correct 
number of attributes with a partial arm-none-abi compiler (i.e. just 
cc1plus).


--
Pierre-Marie de Rodat
>From fa8d7ca05a8711e261b5c4cfeec885c3ecede508 Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat 
Date: Wed, 30 Nov 2016 13:57:34 +0100
Subject: [PATCH] [PR78112] Remove platform-dependent checks in
 g++.dg/pr78112.C

... as there checks failed on many platforms. As a replacement, this
commit also adds a new testcase from source reduction. The hope is that
this new testcase will get a consistent output across all platforms.

gcc/testsuite/
	PR debug/78112
	* g++.dg/pr78112.C: Remove platform-dependent checks.
	* g++.dg/pr78112-2.C: New testcase.
---
 gcc/testsuite/g++.dg/pr78112-2.C | 13 +
 gcc/testsuite/g++.dg/pr78112.C   |  2 --
 2 files changed, 13 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr78112-2.C

diff --git a/gcc/testsuite/g++.dg/pr78112-2.C b/gcc/testsuite/g++.dg/pr78112-2.C
new file mode 100644
index 000..d9d18ff
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr78112-2.C
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-g -dA -gdwarf-4 -std=gnu++11" } */
+/* { dg-options "-g -dA -std=gnu++11 -gdwarf-4" } */
+/* { dg-final { scan-assembler-times DW_AT_object_pointer 18 } } */
+
+void run (int *int_p, void(*func)(int *)) { func (int_p); }
+namespace foo {
+   struct Foo {
+  int a;
+  Foo() { run (, [](int *int_p) { *int_p = 0; }); }
+   };
+}
+int main (void) { foo::Foo f; }
diff --git a/gcc/testsuite/g++.dg/pr78112.C b/gcc/testsuite/g++.dg/pr78112.C
index 986171d..8312292 100644
--- a/gcc/testsuite/g++.dg/pr78112.C
+++ 

Re: [PATCH][AArch64] Improve TI mode address offsets

[James Greenhalgh]

On Tue, Dec 06, 2016 at 05:00:25PM +, James Greenhalgh wrote:
> On Fri, Nov 11, 2016 at 01:14:15PM +, Wilco Dijkstra wrote:
> > Richard Earnshaw wrote:
> > 
> > > Has this patch been truncated?  The last line above looks to be part-way
> > > through a hunk.
> > 
> > Oops sorry, it seems the last few lines are missing. Here is the full 
> > version:
> 
> OK.

This patch has caused around 250 new failures when using the tiny memory
model or when using -mfix-cortex-a53-843419 (causing a bootstrap failure
with --enable-fix-cortex-a53-843419 )

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78733 for more details.

Thanks,
James

> > 
> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> > index 
> > 3045e6d6447d5c1860feb51708eeb2a21d2caca9..45f44e96ba9e9d3c8c41d977aa509fa13398a8fd
> >  100644
> > --- a/gcc/config/aarch64/aarch64.c
> > +++ b/gcc/config/aarch64/aarch64.c
> > @@ -4066,7 +4066,8 @@ aarch64_classify_address (struct aarch64_address_info 
> > *info,
> >  instruction memory accesses.  */
> >   if (mode == TImode || mode == TFmode)
> > return (aarch64_offset_7bit_signed_scaled_p (DImode, offset)
> > -   && offset_9bit_signed_unscaled_p (mode, offset));
> > +   && (offset_9bit_signed_unscaled_p (mode, offset)
> > +   || offset_12bit_unsigned_scaled_p (mode, offset)));
> >  
> >   /* A 7bit offset check because OImode will emit a ldp/stp
> >  instruction (only big endian will get here).
> > @@ -4270,18 +4271,19 @@ aarch64_legitimate_address_p (machine_mode mode, 
> > rtx x,
> >  /* Split an out-of-range address displacement into a base and offset.
> > Use 4KB range for 1- and 2-byte accesses and a 16KB range otherwise
> > to increase opportunities for sharing the base address of different 
> > sizes.
> > -   For TI/TFmode and unaligned accesses use a 256-byte range.  */
> > +   For unaligned accesses and TI/TF mode use the signed 9-bit range.  */
> >  static bool
> >  aarch64_legitimize_address_displacement (rtx *disp, rtx *off, machine_mode 
> > mode)
> >  {
> > -  HOST_WIDE_INT mask = GET_MODE_SIZE (mode) < 4 ? 0xfff : 0x3fff;
> > +  HOST_WIDE_INT offset = INTVAL (*disp);
> > +  HOST_WIDE_INT base = offset & ~(GET_MODE_SIZE (mode) < 4 ? 0xfff : 
> > 0x3ffc);
> >  
> > -  if (mode == TImode || mode == TFmode ||
> > -  (INTVAL (*disp) & (GET_MODE_SIZE (mode) - 1)) != 0)
> > -mask = 0xff;
> > +  if (mode == TImode || mode == TFmode
> > +  || (offset & (GET_MODE_SIZE (mode) - 1)) != 0)
> > +base = (offset + 0x100) & ~0x1ff;
> >  
> > -  *off = GEN_INT (INTVAL (*disp) & ~mask);
> > -  *disp = GEN_INT (INTVAL (*disp) & mask);
> > +  *off = GEN_INT (base);
> > +  *disp = GEN_INT (offset - base);
> >return true;
> >  }
> >  
> > @@ -5148,12 +5150,10 @@ aarch64_legitimize_address (rtx x, rtx /* orig_x  
> > */, machine_mode mode)
> >   x = gen_rtx_PLUS (Pmode, base, offset_rtx);
> > }
> >  
> > -  /* Does it look like we'll need a load/store-pair operation?  */
> > +  /* Does it look like we'll need a 16-byte load/store-pair operation? 
> >  */
> >HOST_WIDE_INT base_offset;
> > -  if (GET_MODE_SIZE (mode) > 16
> > - || mode == TImode)
> > -   base_offset = ((offset + 64 * GET_MODE_SIZE (mode))
> > -  & ~((128 * GET_MODE_SIZE (mode)) - 1));
> > +  if (GET_MODE_SIZE (mode) > 16)
> > +   base_offset = (offset + 0x400) & ~0x7f0;
> >/* For offsets aren't a multiple of the access size, the limit is
> >  -256...255.  */
> >else if (offset & (GET_MODE_SIZE (mode) - 1))
> > @@ -5167,6 +5167,8 @@ aarch64_legitimize_address (rtx x, rtx /* orig_x  */, 
> > machine_mode mode)
> >/* Small negative offsets are supported.  */
> >else if (IN_RANGE (offset, -256, 0))
> > base_offset = 0;
> > +  else if (mode == TImode || mode == TFmode)
> > +   base_offset = (offset + 0x100) & ~0x1ff;
> >/* Use 12-bit offset by access size.  */
> >else
> > base_offset = offset & (~0xfff * GET_MODE_SIZE (mode));
> > diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> > index 
> > 24b7288976dd0452f41475e40f02750fc56a2a20..62eda569f9b642ac569a61718d7debf7eae1b59e
> >  100644
> > --- a/gcc/config/aarch64/aarch64.md
> > +++ b/gcc/config/aarch64/aarch64.md
> > @@ -1094,9 +1094,9 @@
> >  
> >  (define_insn "*movti_aarch64"
> >[(set (match_operand:TI 0
> > -"nonimmediate_operand"  "=r, *w,r ,*w,r  ,Ump,Ump,*w,m")
> > +"nonimmediate_operand"  "=r, *w,r ,*w,r,m,m,*w,m")
> > (match_operand:TI 1
> > -"aarch64_movti_operand" " rn,r ,*w,*w,Ump,r  ,Z  , m,*w"))]
> > +"aarch64_movti_operand" " rn,r ,*w,*w,m,r,Z, m,*w"))]
> >"(register_operand (operands[0], TImode)
> >  || aarch64_reg_or_zero (operands[1], TImode))"
> >"@
> > @@ -1211,9 +1211,9 @@
> >  
> >  (define_insn "*movtf_aarch64"
> >[(set (match_operand:TF 0
> > -"nonimmediate_operand" 

[PATCH][AArch64] Split X-reg UBFX into W-reg LSR when possible

[Kyrill Tkachov]

Hi all,

In this patch we split X-register UBFX instructions that extract up to the edge 
of a W-register into
a W-register LSR instruction. So for the example in the testcase instead of:
UBFXX0, X0, 24, 8

we'd generate:
LSR w0, w0, 24

An LSR is a simpler instruction and there's a higher chance that it can be 
combined with other instructions.

To do this the patch separates the sign_extract case from the zero_extract case in the 
* ANY_EXTRACT
pattern and further splits the SImode/DImode patterns from the resulting 
zrero_extract pattern.
The DImode zero_extract pattern then becomes a define_insn_and_split that 
splits into a zero_extend of an lshiftrt
when the bitposition and width of the zero_extract add up to 32.

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

Since we're in stage 3 perhaps this is not for GCC 6, but it is fairly low risk.
I'm happy for it to wait for the next release if necessary.

Thanks,
Kyrill

2016-12-08  Kyrylo Tkachov  

* config/aarch64/aarch64.md (*): Split into...
(*extv): ...This...
(*extzvsi): ...This...
(*extzvdi:): ... And this.  Add splitting to lshiftrt when possible.

2016-12-08  Kyrylo Tkachov  

* gcc.target/aarch64/ubfx_lsr_1.c: New test.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 6b4d0ba633af2a549ded2f18962d9ed300f56e12..a6f659c26bb5156d652b6c1f09123e682e9ff648 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -4327,16 +4327,51 @@ (define_expand ""
 )
 
 
-(define_insn "*"
+(define_insn "*extv"
   [(set (match_operand:GPI 0 "register_operand" "=r")
-	(ANY_EXTRACT:GPI (match_operand:GPI 1 "register_operand" "r")
+	(sign_extract:GPI (match_operand:GPI 1 "register_operand" "r")
 			 (match_operand 2
 			   "aarch64_simd_shift_imm_offset_" "n")
 			 (match_operand 3
 			   "aarch64_simd_shift_imm_" "n")))]
   "IN_RANGE (INTVAL (operands[2]) + INTVAL (operands[3]),
 	 1, GET_MODE_BITSIZE (mode) - 1)"
-  "bfx\\t%0, %1, %3, %2"
+  "sbfx\\t%0, %1, %3, %2"
+  [(set_attr "type" "bfx")]
+)
+
+(define_insn "*extzvsi"
+  [(set (match_operand:SI 0 "register_operand" "=r")
+	(zero_extract:SI (match_operand:SI 1 "register_operand" "r")
+			 (match_operand 2
+			   "aarch64_simd_shift_imm_offset_si" "n")
+			 (match_operand 3
+			   "aarch64_simd_shift_imm_si" "n")))]
+  "IN_RANGE (INTVAL (operands[2]) + INTVAL (operands[3]),
+	 1, GET_MODE_BITSIZE (SImode) - 1)"
+  "ubfx\\t%w0, %w1, %3, %2"
+  [(set_attr "type" "bfx")]
+)
+
+(define_insn_and_split "*extzvdi"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+	(zero_extract:DI (match_operand:DI 1 "register_operand" "r")
+			 (match_operand 2
+			   "aarch64_simd_shift_imm_offset_di" "n")
+			 (match_operand 3
+			   "aarch64_simd_shift_imm_di" "n")))]
+  "IN_RANGE (INTVAL (operands[2]) + INTVAL (operands[3]),
+	 1, GET_MODE_BITSIZE (DImode) - 1)"
+  "ubfx\\t%x0, %x1, %3, %2"
+  ;; When the bitposition and width add up to 32 we can use a W-reg LSR
+  ;; instruction taking advantage of the implicit zero-extension of the X-reg.
+  "&& (INTVAL (operands[2]) + INTVAL (operands[3]))
+	== GET_MODE_BITSIZE (SImode)"
+  [(set (match_dup 0)
+	(zero_extend:DI (lshiftrt:SI (match_dup 4) (match_dup 3]
+  {
+operands[4] = gen_lowpart (SImode, operands[1]);
+  }
   [(set_attr "type" "bfx")]
 )
 
diff --git a/gcc/testsuite/gcc.target/aarch64/ubfx_lsr_1.c b/gcc/testsuite/gcc.target/aarch64/ubfx_lsr_1.c
new file mode 100644
index ..bc083862976a88190dbef97a247be8a10b277a12
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/ubfx_lsr_1.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* Check that an X-reg UBFX can be simplified into a W-reg LSR.  */
+
+int
+f (unsigned long long x)
+{
+   x = (x >> 24) & 255;
+   return x + 1;
+}
+
+/* { dg-final { scan-assembler "lsr\tw" } } */
+/* { dg-final { scan-assembler-not "ubfx\tx" } } */

[PATCH][AArch64] Split X-reg UBFIZ into W-reg LSL when possible

[Kyrill Tkachov]

Hi all,

Similar to the previous patch this transforms X-reg UBFIZ instructions into 
W-reg LSL instructions
when the UBFIZ operands add up to 32, so we can take advantage of the implicit 
zero-extension to DImode
when writing to a W-register.

This is done by splitting the existing *andim_ashift_bfi pattern into its 
two SImode and DImode
specialisations and changing the DImode pattern into a define_insn_and_split 
that splits into a
zero-extended SImode ashift when the operands match up.

So for the code in the testcase we generate:
LSL W0, W0, 5

instead of:
UBFIZ   X0, X0, 5, 27

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

Since we're in stage 3 perhaps this is not for GCC 6, but it is fairly low risk.
I'm happy for it to wait for the next release if necessary.

Thanks,
Kyrill

2016-12-08  Kyrylo Tkachov  

* config/aarch64/aarch64.md (*andim_ashift_bfiz): Split into...
(*andim_ashiftsi_bfiz): ...This...
(*andim_ashiftdi_bfiz): ...And this.  Add split to ashift when
possible.

2016-12-08  Kyrylo Tkachov  

* gcc.target/aarch64/ubfiz_lsl_1.c: New test.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index a6f659c26bb5156d652b6c1f09123e682e9ff648..d1083381876572616a61f8f59d523f258dd077f4 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -4459,13 +4459,33 @@ (define_insn "*_shft_"
 
 ;; XXX We should match (any_extend (ashift)) here, like (and (ashift)) below
 
-(define_insn "*andim_ashift_bfiz"
-  [(set (match_operand:GPI 0 "register_operand" "=r")
-	(and:GPI (ashift:GPI (match_operand:GPI 1 "register_operand" "r")
+(define_insn "*andim_ashiftsi_bfiz"
+  [(set (match_operand:SI 0 "register_operand" "=r")
+	(and:SI (ashift:SI (match_operand:SI 1 "register_operand" "r")
+			 (match_operand 2 "const_int_operand" "n"))
+		 (match_operand 3 "const_int_operand" "n")))]
+  "aarch64_mask_and_shift_for_ubfiz_p (SImode, operands[3], operands[2])"
+  "ubfiz\\t%w0, %w1, %2, %P3"
+  [(set_attr "type" "bfx")]
+)
+
+(define_insn_and_split "*andim_ashiftdi_bfiz"
+  [(set (match_operand:DI 0 "register_operand" "=r")
+	(and:DI (ashift:DI (match_operand:DI 1 "register_operand" "r")
 			 (match_operand 2 "const_int_operand" "n"))
 		 (match_operand 3 "const_int_operand" "n")))]
-  "aarch64_mask_and_shift_for_ubfiz_p (mode, operands[3], operands[2])"
-  "ubfiz\\t%0, %1, %2, %P3"
+  "aarch64_mask_and_shift_for_ubfiz_p (DImode, operands[3], operands[2])"
+  "ubfiz\\t%x0, %x1, %2, %P3"
+  ;; When the bitposition and width of the equivalent extraction add up to 32
+  ;; we can use a W-reg LSL instruction taking advantage of the implicit
+  ;; zero-extension of the X-reg.
+  "&& (INTVAL (operands[2]) + popcount_hwi (INTVAL (operands[3])))
+  == GET_MODE_BITSIZE (SImode)"
+  [(set (match_dup 0)
+	(zero_extend:DI (ashift:SI (match_dup 4) (match_dup 2]
+  {
+operands[4] = gen_lowpart (SImode, operands[1]);
+  }
   [(set_attr "type" "bfx")]
 )
 
diff --git a/gcc/testsuite/gcc.target/aarch64/ubfiz_lsl_1.c b/gcc/testsuite/gcc.target/aarch64/ubfiz_lsl_1.c
new file mode 100644
index ..d3fd3f234f2324d71813298210fdcf0660ac45b4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/ubfiz_lsl_1.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+/* Check that an X-reg UBFIZ can be simplified into a W-reg LSL.  */
+
+long long
+f2 (long long x)
+{
+  return (x << 5) & 0x;
+}
+
+/* { dg-final { scan-assembler "lsl\tw" } } */
+/* { dg-final { scan-assembler-not "ubfiz\tx" } } */

Re: Calling 'abort' on bounds violations in libmpx

[Alexander Ivchenko]

I've tested the patch on MPX HW, no new regressions. Attached the
final version below, would that be ok to submit?


2016-11-29  Alexander Ivchenko  

* mpxrt/libtool-version: New version.
* mpxrt/mpxrt-utils.c (set_mpx_rt_stop_handler): New function.
(print_help): Add help for CHKP_RT_STOP_HANDLER environment
variable.
(__mpxrt_init_env_vars): Add initialization of stop_handler.
(__mpxrt_stop_handler): New function.
(__mpxrt_stop): Ditto.
* mpxrt/mpxrt-utils.h (mpx_rt_stop_mode_handler_t): New enum.

diff --git a/libmpx/mpxrt/libtool-version b/libmpx/mpxrt/libtool-version
index 7d99255..736d763 100644
--- a/libmpx/mpxrt/libtool-version
+++ b/libmpx/mpxrt/libtool-version
@@ -3,4 +3,4 @@
 # a separate file so that version updates don't involve re-running
 # automake.
 # CURRENT:REVISION:AGE
-2:0:0
+2:1:0
diff --git a/libmpx/mpxrt/mpxrt-utils.c b/libmpx/mpxrt/mpxrt-utils.c
index 057a355..63ee7c6 100644
--- a/libmpx/mpxrt/mpxrt-utils.c
+++ b/libmpx/mpxrt/mpxrt-utils.c
@@ -60,6 +60,9 @@
 #define MPX_RT_MODE "CHKP_RT_MODE"
 #define MPX_RT_MODE_DEFAULT MPX_RT_COUNT
 #define MPX_RT_MODE_DEFAULT_STR "count"
+#define MPX_RT_STOP_HANDLER "CHKP_RT_STOP_HANDLER"
+#define MPX_RT_STOP_HANDLER_DEFAULT MPX_RT_STOP_HANDLER_ABORT
+#define MPX_RT_STOP_HANDLER_DEFAULT_STR "abort"
 #define MPX_RT_HELP "CHKP_RT_HELP"
 #define MPX_RT_ADDPID "CHKP_RT_ADDPID"
 #define MPX_RT_BNDPRESERVE "CHKP_RT_BNDPRESERVE"
@@ -84,6 +87,7 @@ typedef struct {
 static int summary;
 static int add_pid;
 static mpx_rt_mode_t mode;
+static mpx_rt_stop_mode_handler_t stop_handler;
 static env_var_list_t env_var_list;
 static verbose_type verbose_val;
 static FILE *out;
@@ -226,6 +230,23 @@ set_mpx_rt_mode (const char *env)
   }
 }

+static mpx_rt_stop_mode_handler_t
+set_mpx_rt_stop_handler (const char *env)
+{
+  if (env == 0)
+return MPX_RT_STOP_HANDLER_DEFAULT;
+  else if (strcmp (env, "abort") == 0)
+return MPX_RT_STOP_HANDLER_ABORT;
+  else if (strcmp (env, "exit") == 0)
+return MPX_RT_STOP_HANDLER_EXIT;
+  {
+__mpxrt_print (VERB_ERROR, "Illegal value '%s' for %s. Legal values are"
+   "[abort | exit]\nUsing default value %s\n",
+   env, MPX_RT_STOP_HANDLER, MPX_RT_STOP_HANDLER_DEFAULT);
+return MPX_RT_STOP_HANDLER_DEFAULT;
+  }
+}
+
 static void
 print_help (void)
 {
@@ -244,6 +265,11 @@ print_help (void)
   fprintf (out, "%s \t\t set MPX runtime behavior on #BR exception."
" [stop | count]\n"
"\t\t\t [default: %s]\n", MPX_RT_MODE, MPX_RT_MODE_DEFAULT_STR);
+  fprintf (out, "%s \t set the handler function MPX runtime will call\n"
+   "\t\t\t on #BR exception when %s is set to \'stop\'."
+   " [abort | exit]\n"
+   "\t\t\t [default: %s]\n", MPX_RT_STOP_HANDLER, MPX_RT_MODE,
+   MPX_RT_STOP_HANDLER_DEFAULT_STR);
   fprintf (out, "%s \t\t generate out,err file for each process.\n"
"\t\t\t generated file will be MPX_RT_{OUT,ERR}_FILE.pid\n"
"\t\t\t [default: no]\n", MPX_RT_ADDPID);
@@ -357,6 +383,10 @@ __mpxrt_init_env_vars (int* bndpreserve)
   env_var_list_add (MPX_RT_MODE, env);
   mode = set_mpx_rt_mode (env);

+  env = secure_getenv (MPX_RT_STOP_HANDLER);
+  env_var_list_add (MPX_RT_STOP_HANDLER, env);
+  stop_handler = set_mpx_rt_stop_handler (env);
+
   env = secure_getenv (MPX_RT_BNDPRESERVE);
   env_var_list_add (MPX_RT_BNDPRESERVE, env);
   validate_bndpreserve (env, bndpreserve);
@@ -487,6 +517,22 @@ __mpxrt_mode (void)
   return mode;
 }

+mpx_rt_mode_t
+__mpxrt_stop_handler (void)
+{
+  return stop_handler;
+}
+
+void __attribute__ ((noreturn))
+__mpxrt_stop (void)
+{
+  if (__mpxrt_stop_handler () == MPX_RT_STOP_HANDLER_ABORT)
+abort ();
+  else if (__mpxrt_stop_handler () == MPX_RT_STOP_HANDLER_EXIT)
+exit (255);
+  __builtin_unreachable ();
+}
+
 void
 __mpxrt_print_summary (uint64_t num_brs, uint64_t l1_size)
 {
diff --git a/libmpx/mpxrt/mpxrt-utils.h b/libmpx/mpxrt/mpxrt-utils.h
index d62937d..6da12cc 100644
--- a/libmpx/mpxrt/mpxrt-utils.h
+++ b/libmpx/mpxrt/mpxrt-utils.h
@@ -54,6 +54,11 @@ typedef enum {
   MPX_RT_STOP
 } mpx_rt_mode_t;

+typedef enum {
+  MPX_RT_STOP_HANDLER_ABORT,
+  MPX_RT_STOP_HANDLER_EXIT
+} mpx_rt_stop_mode_handler_t;
+
 void __mpxrt_init_env_vars (int* bndpreserve);
 void __mpxrt_write_uint (verbose_type vt, uint64_t val, unsigned base);
 void __mpxrt_write (verbose_type vt, const char* str);
diff --git a/libmpx/mpxrt/mpxrt.c b/libmpx/mpxrt/mpxrt.c
index b52906b..76d11f7 100644
--- a/libmpx/mpxrt/mpxrt.c
+++ b/libmpx/mpxrt/mpxrt.c
@@ -252,7 +252,7 @@ handler (int sig __attribute__ ((unused)),
   uctxt->uc_mcontext.gregs[REG_IP_IDX] =
 (greg_t)get_next_inst_ip ((uint8_t *)ip);
   if (__mpxrt_mode () == MPX_RT_STOP)
-exit (255);
+__mpxrt_stop ();
   return;

  default:
@@ -269,7 +269,7 @@ handler (int sig __attribute__ ((unused)),
   __mpxrt_write (VERB_ERROR, ", ip = 0x");
   __mpxrt_write_uint (VERB_ERROR, ip, 16);
   __mpxrt_write (VERB_ERROR, "\n");
-  exit (255);
+  __mpxrt_stop ();
 

Re: [ARM][PATCH] Fix failing poly64 tests on ARM

[Kyrill Tkachov]

On 08/12/16 09:07, Christophe Lyon wrote:

Sending again, after removing ARM's "company disclaimer or privacy notice"...


And resending the "ok" without the disclaimer...
Ok.
Thanks,
Kyrill



On 8 December 2016 at 10:03, Christophe Lyon  wrote:

Hi,

On 6 December 2016 at 11:55, Tamar Christina  wrote:

Hi Christophe,

Aarch64 seems to still pass. It seems the types are really unused after I moved 
the other tests to p64_p128.


I checked the attached patch fixes the failing tests on ARM/AArch64
(no advsimd-intrinsic test
fail after this patch is applied).

OK for trunk?

Thanks,

Christophe



Thanks,
Tamar


From: Christophe Lyon 
Sent: Monday, December 5, 2016 6:33:43 PM
To: Kyrill Tkachov
Cc: Tamar Christina; GCC Patches; ni...@redhat.com; Richard Earnshaw
Subject: Re: [ARM][PATCH] Fix failing poly64 tests on ARM

Hi Tamar,


On 5 December 2016 at 16:32, Kyrill Tkachov  wrote:

On 05/12/16 10:39, Tamar Christina wrote:

Hi All,

This patch fixes test failures on arm-none-eabi.
Poly64 was being used by files that were not supposed
to be testing poly64 types.

I have added a new MACRO that must be defined in addition
to having CRYPTO available before use of Poly64 types are
allowed in the header arm-neon-ref.h.

Ok for trunk?

gcc/testsuite/
2016-12-01  Tamar Christina  

 * gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h: Gate use
of Poly64 on USE_CRYPTO_TYPES.
 * gcc.target/aarch64/advsimd-intrinsics/p64_p128.c: Define
USE_CRYPTO_TYPES.
 * gcc.target/aarch64/advsimd-intrinsics/vreinterpret_p128.c:
Likewise.
 * gcc.target/aarch64/advsimd-intrinsics/vreinterpret_p64.c:
Likewise.


Ok, but please make sure the line length in the ChangeLog doesn't go over 80
characters.
Kyrill

Since 'expected_poly64x[12]' isn't used, there is no need to declare it,
and the attached patch seems to work (tested only on arm-none-linux-gnueabihf
--target-board=-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard

All the tests for poly64 use dedicated output buffers, at least for the moment.

Does my patch break aarch64?

Christophe

Re: [PATCH, GCC/ARM] Fix ICE when compiling empty FIQ interrupt handler in ARM mode

[Christophe Lyon]

On 8 December 2016 at 10:09, Thomas Preudhomme
 wrote:
>
>
> On 08/12/16 08:46, Christophe Lyon wrote:
>>
>> On 21 November 2016 at 12:03, Thomas Preudhomme
>>  wrote:
>>>
>>> On 17/11/16 20:04, Thomas Preudhomme wrote:


 Hi Christophe,

 On 17/11/16 13:36, Christophe Lyon wrote:
>
>
> On 16 November 2016 at 10:39, Kyrill Tkachov
>  wrote:
>>
>>
>>
>> On 09/11/16 16:19, Thomas Preudhomme wrote:
>>>
>>>
>>>
>>> Hi,
>>>
>>> This patch fixes the following ICE when building when compiling an
>>> empty
>>> FIQ interrupt handler in ARM mode:
>>>
>>> empty_fiq_handler.c:5:1: error: insn does not satisfy its
>>> constraints:
>>>  }
>>>  ^
>>>
>>> (insn/f 13 12 14 (set (reg/f:SI 13 sp)
>>> (plus:SI (reg/f:SI 11 fp)
>>> (const_int 4 [0x4]))) irq.c:5 4 {*arm_addsi3}
>>>  (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 13 sp)
>>> (plus:SI (reg/f:SI 11 fp)
>>> (const_int 4 [0x4])))
>>> (nil)))
>>>
>>> The ICE was provoked by missing an alternative to reflect that ARM
>>> mode
>>> can do an add of general register into sp which is unpredictable in
>>> Thumb
>>> mode add immediate.
>>>
>>> ChangeLog entries are as follow:
>>>
>>> *** gcc/ChangeLog ***
>>>
>>> 2016-11-04  Thomas Preud'homme  
>>>
>>> * config/arm/arm.md (arm_addsi3): Add alternative for
>>> addition
>>> of
>>> general register with general register or ARM constant into
>>> SP
>>> register.
>>>
>>>
>>> *** gcc/testsuite/ChangeLog ***
>>>
>>> 2016-11-04  Thomas Preud'homme  
>>>
>>> * gcc.target/arm/empty_fiq_handler.c: New test.
>>>
>>>
>>> Testing: bootstrapped on ARMv7-A ARM mode & testsuite shows no
>>> regression.
>>>
>>> Is this ok for trunk?
>>>
>>
>> I see that "r" does not include the stack pointer (STACK_REG is
>> separate
>> from GENERAL_REGs) so we are indeed missing
>> that constraint.
>>
>> Ok for trunk.
>> Thanks,
>> Kyrill
>>
>>> Best regards,
>>>
>>> Thomas
>>
>>
>>
>>
>
> Hi Thomas,
>
> The new test fails when compiled with -mthumb -march=armv5t:
> gcc.target/arm/empty_fiq_handler.c: In function 'fiq_handler':
> gcc.target/arm/empty_fiq_handler.c:11:1: error: interrupt Service
> Routines cannot be coded in Thumb mode



 Right, interrupt handler can only be compiled in the mode where the CPU
 boots.
 So for non Thumb-only targets it should be compiled with -marm. I'll
 push
 a
 patch tomorrow.
>>>
>>>
>>>
>>> I've committed the following patch as obvious:
>>>
>>> Interrupt handlers on ARM can only be compiled in the execution mode
>>> where
>>> the processor boot. That is -mthumb for Thumb-only devices, -marm
>>> otherwise.
>>> This changes the empty_fiq_handler to skip the test when -mthumb is
>>> passed
>>> but the processor boot in ARM mode.
>>>
>>> ChangeLog entry is as follows:
>>>
>>> *** gcc/testsuite/ChangeLog ***
>>>
>>> 2016-11-17  Thomas Preud'homme  
>>>
>>> * gcc.target/arm/empty_fiq_handler.c: Skip if -mthumb is passed
>>> in
>>> and
>>> target is Thumb-only.
>>>
>>
>> Hi Thomas,
>>
>> As for another patch of yours, this doesn't work in GCC was configured
>> --with-mode=thumb
>> (the test is not skipped). But I guess you know that already :-)
>
>
> Oh no! I wasn't aware this patch also had the issue on trunk. Ok, I better
> get going with adding a dejagnu procedure to check --with-mode.
>
> Thanks for the feedback and sorry for that.
>

No problem, I know it's a nightmare to cover all the combinations :(

> Best regards,
>
> Thomas

[Ping[[PATCH][Aarch64] Add support for overflow add and sub operations

[Michael Collison]

Ping.

Link to original post: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg03119.html

Re: [PATCH, GCC/ARM] Fix ICE when compiling empty FIQ interrupt handler in ARM mode

[Thomas Preudhomme]

On 08/12/16 08:46, Christophe Lyon wrote:

On 21 November 2016 at 12:03, Thomas Preudhomme
 wrote:

On 17/11/16 20:04, Thomas Preudhomme wrote:


Hi Christophe,

On 17/11/16 13:36, Christophe Lyon wrote:


On 16 November 2016 at 10:39, Kyrill Tkachov
 wrote:



On 09/11/16 16:19, Thomas Preudhomme wrote:



Hi,

This patch fixes the following ICE when building when compiling an
empty
FIQ interrupt handler in ARM mode:

empty_fiq_handler.c:5:1: error: insn does not satisfy its constraints:
 }
 ^

(insn/f 13 12 14 (set (reg/f:SI 13 sp)
(plus:SI (reg/f:SI 11 fp)
(const_int 4 [0x4]))) irq.c:5 4 {*arm_addsi3}
 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 13 sp)
(plus:SI (reg/f:SI 11 fp)
(const_int 4 [0x4])))
(nil)))

The ICE was provoked by missing an alternative to reflect that ARM mode
can do an add of general register into sp which is unpredictable in
Thumb
mode add immediate.

ChangeLog entries are as follow:

*** gcc/ChangeLog ***

2016-11-04  Thomas Preud'homme  

* config/arm/arm.md (arm_addsi3): Add alternative for addition
of
general register with general register or ARM constant into SP
register.


*** gcc/testsuite/ChangeLog ***

2016-11-04  Thomas Preud'homme  

* gcc.target/arm/empty_fiq_handler.c: New test.


Testing: bootstrapped on ARMv7-A ARM mode & testsuite shows no
regression.

Is this ok for trunk?



I see that "r" does not include the stack pointer (STACK_REG is separate
from GENERAL_REGs) so we are indeed missing
that constraint.

Ok for trunk.
Thanks,
Kyrill


Best regards,

Thomas






Hi Thomas,

The new test fails when compiled with -mthumb -march=armv5t:
gcc.target/arm/empty_fiq_handler.c: In function 'fiq_handler':
gcc.target/arm/empty_fiq_handler.c:11:1: error: interrupt Service
Routines cannot be coded in Thumb mode



Right, interrupt handler can only be compiled in the mode where the CPU
boots.
So for non Thumb-only targets it should be compiled with -marm. I'll push
a
patch tomorrow.



I've committed the following patch as obvious:

Interrupt handlers on ARM can only be compiled in the execution mode where
the processor boot. That is -mthumb for Thumb-only devices, -marm otherwise.
This changes the empty_fiq_handler to skip the test when -mthumb is passed
but the processor boot in ARM mode.

ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-11-17  Thomas Preud'homme  

* gcc.target/arm/empty_fiq_handler.c: Skip if -mthumb is passed in
and
target is Thumb-only.



Hi Thomas,

As for another patch of yours, this doesn't work in GCC was configured
--with-mode=thumb
(the test is not skipped). But I guess you know that already :-)


Oh no! I wasn't aware this patch also had the issue on trunk. Ok, I better get 
going with adding a dejagnu procedure to check --with-mode.


Thanks for the feedback and sorry for that.

Best regards,

Thomas

Re: [ARM][PATCH] Fix failing poly64 tests on ARM

[Christophe Lyon]

Sending again, after removing ARM's "company disclaimer or privacy notice"...


On 8 December 2016 at 10:03, Christophe Lyon  wrote:
> Hi,
>
> On 6 December 2016 at 11:55, Tamar Christina  wrote:
>> Hi Christophe,
>>
>> Aarch64 seems to still pass. It seems the types are really unused after I 
>> moved the other tests to p64_p128.
>>
>
> I checked the attached patch fixes the failing tests on ARM/AArch64
> (no advsimd-intrinsic test
> fail after this patch is applied).
>
> OK for trunk?
>
> Thanks,
>
> Christophe
>
>
>> Thanks,
>> Tamar
>>
>> 
>> From: Christophe Lyon 
>> Sent: Monday, December 5, 2016 6:33:43 PM
>> To: Kyrill Tkachov
>> Cc: Tamar Christina; GCC Patches; ni...@redhat.com; Richard Earnshaw
>> Subject: Re: [ARM][PATCH] Fix failing poly64 tests on ARM
>>
>> Hi Tamar,
>>
>>
>> On 5 December 2016 at 16:32, Kyrill Tkachov  
>> wrote:
>>>
>>> On 05/12/16 10:39, Tamar Christina wrote:

 Hi All,

 This patch fixes test failures on arm-none-eabi.
 Poly64 was being used by files that were not supposed
 to be testing poly64 types.

 I have added a new MACRO that must be defined in addition
 to having CRYPTO available before use of Poly64 types are
 allowed in the header arm-neon-ref.h.

 Ok for trunk?

 gcc/testsuite/
 2016-12-01  Tamar Christina  

 * gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h: Gate use
 of Poly64 on USE_CRYPTO_TYPES.
 * gcc.target/aarch64/advsimd-intrinsics/p64_p128.c: Define
 USE_CRYPTO_TYPES.
 * gcc.target/aarch64/advsimd-intrinsics/vreinterpret_p128.c:
 Likewise.
 * gcc.target/aarch64/advsimd-intrinsics/vreinterpret_p64.c:
 Likewise.
>>>
>>>
>>> Ok, but please make sure the line length in the ChangeLog doesn't go over 80
>>> characters.
>>> Kyrill
>>
>> Since 'expected_poly64x[12]' isn't used, there is no need to declare it,
>> and the attached patch seems to work (tested only on arm-none-linux-gnueabihf
>> --target-board=-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard
>>
>> All the tests for poly64 use dedicated output buffers, at least for the 
>> moment.
>>
>> Does my patch break aarch64?
>>
>> Christophe
gcc/testsuite/ChangeLog:

2016-12-08  Christophe Lyon  

* gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
(CHECK_CRYPTO): Remove.
(expected_poly64x1_t, expected_poly64x2_t): Remove

diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h 
b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
index beaf6ac..4728639 100644
--- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
+++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
@@ -99,13 +99,6 @@ extern size_t strlen(const char *);
 fprintf(stderr, "CHECKED %s %s\n", STR(VECT_TYPE(T, W, N)), MSG);  \
   }
 
-#if defined (__ARM_FEATURE_CRYPTO)
-#define CHECK_CRYPTO(MSG,T,W,N,FMT,EXPECTED,COMMENT) \
-  CHECK(MSG,T,W,N,FMT,EXPECTED,COMMENT)
-#else
-#define CHECK_CRYPTO(MSG,T,W,N,FMT,EXPECTED,COMMENT)
-#endif
-
 /* Floating-point variant.  */
 #define CHECK_FP(MSG,T,W,N,FMT,EXPECTED,COMMENT)   \
   {\
@@ -198,9 +191,6 @@ extern ARRAY(expected, uint, 32, 2);
 extern ARRAY(expected, uint, 64, 1);
 extern ARRAY(expected, poly, 8, 8);
 extern ARRAY(expected, poly, 16, 4);
-#if defined (__ARM_FEATURE_CRYPTO)
-extern ARRAY(expected, poly, 64, 1);
-#endif
 extern ARRAY(expected, hfloat, 16, 4);
 extern ARRAY(expected, hfloat, 32, 2);
 extern ARRAY(expected, hfloat, 64, 1);
@@ -214,9 +204,6 @@ extern ARRAY(expected, uint, 32, 4);
 extern ARRAY(expected, uint, 64, 2);
 extern ARRAY(expected, poly, 8, 16);
 extern ARRAY(expected, poly, 16, 8);
-#if defined (__ARM_FEATURE_CRYPTO)
-extern ARRAY(expected, poly, 64, 2);
-#endif
 extern ARRAY(expected, hfloat, 16, 8);
 extern ARRAY(expected, hfloat, 32, 4);
 extern ARRAY(expected, hfloat, 64, 2);
@@ -233,7 +220,6 @@ extern ARRAY(expected, hfloat, 64, 2);
 CHECK(test_name, uint, 64, 1, PRIx64, EXPECTED, comment);  \
 CHECK(test_name, poly, 8, 8, PRIx8, EXPECTED, comment);\
 CHECK(test_name, poly, 16, 4, PRIx16, EXPECTED, comment);  \
-CHECK_CRYPTO(test_name, poly, 64, 1, PRIx64, EXPECTED, comment);   \
 CHECK_FP(test_name, float, 32, 2, PRIx32, EXPECTED, comment);  \
\
 CHECK(test_name, int, 8, 16, PRIx8, EXPECTED, comment);\
@@ -246,7 +232,6 @@ extern ARRAY(expected, hfloat, 64, 2);
 CHECK(test_name, uint, 64, 2, PRIx64, EXPECTED, comment);  \
 CHECK(test_name, poly, 8, 16, PRIx8, 

Re: [PATCH, GCC/ARM] Fix ICE when compiling empty FIQ interrupt handler in ARM mode

[Christophe Lyon]

On 21 November 2016 at 12:03, Thomas Preudhomme
 wrote:
> On 17/11/16 20:04, Thomas Preudhomme wrote:
>>
>> Hi Christophe,
>>
>> On 17/11/16 13:36, Christophe Lyon wrote:
>>>
>>> On 16 November 2016 at 10:39, Kyrill Tkachov
>>>  wrote:


 On 09/11/16 16:19, Thomas Preudhomme wrote:
>
>
> Hi,
>
> This patch fixes the following ICE when building when compiling an
> empty
> FIQ interrupt handler in ARM mode:
>
> empty_fiq_handler.c:5:1: error: insn does not satisfy its constraints:
>  }
>  ^
>
> (insn/f 13 12 14 (set (reg/f:SI 13 sp)
> (plus:SI (reg/f:SI 11 fp)
> (const_int 4 [0x4]))) irq.c:5 4 {*arm_addsi3}
>  (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 13 sp)
> (plus:SI (reg/f:SI 11 fp)
> (const_int 4 [0x4])))
> (nil)))
>
> The ICE was provoked by missing an alternative to reflect that ARM mode
> can do an add of general register into sp which is unpredictable in
> Thumb
> mode add immediate.
>
> ChangeLog entries are as follow:
>
> *** gcc/ChangeLog ***
>
> 2016-11-04  Thomas Preud'homme  
>
> * config/arm/arm.md (arm_addsi3): Add alternative for addition
> of
> general register with general register or ARM constant into SP
> register.
>
>
> *** gcc/testsuite/ChangeLog ***
>
> 2016-11-04  Thomas Preud'homme  
>
> * gcc.target/arm/empty_fiq_handler.c: New test.
>
>
> Testing: bootstrapped on ARMv7-A ARM mode & testsuite shows no
> regression.
>
> Is this ok for trunk?
>

 I see that "r" does not include the stack pointer (STACK_REG is separate
 from GENERAL_REGs) so we are indeed missing
 that constraint.

 Ok for trunk.
 Thanks,
 Kyrill

> Best regards,
>
> Thomas



>>>
>>> Hi Thomas,
>>>
>>> The new test fails when compiled with -mthumb -march=armv5t:
>>> gcc.target/arm/empty_fiq_handler.c: In function 'fiq_handler':
>>> gcc.target/arm/empty_fiq_handler.c:11:1: error: interrupt Service
>>> Routines cannot be coded in Thumb mode
>>
>>
>> Right, interrupt handler can only be compiled in the mode where the CPU
>> boots.
>> So for non Thumb-only targets it should be compiled with -marm. I'll push
>> a
>> patch tomorrow.
>
>
> I've committed the following patch as obvious:
>
> Interrupt handlers on ARM can only be compiled in the execution mode where
> the processor boot. That is -mthumb for Thumb-only devices, -marm otherwise.
> This changes the empty_fiq_handler to skip the test when -mthumb is passed
> but the processor boot in ARM mode.
>
> ChangeLog entry is as follows:
>
> *** gcc/testsuite/ChangeLog ***
>
> 2016-11-17  Thomas Preud'homme  
>
> * gcc.target/arm/empty_fiq_handler.c: Skip if -mthumb is passed in
> and
> target is Thumb-only.
>

Hi Thomas,

As for another patch of yours, this doesn't work in GCC was configured
--with-mode=thumb
(the test is not skipped). But I guess you know that already :-)

Christophe

> Best regards,
>
> Thomas

Re: [ARM] PR 78253 do not resolve weak ref locally

[Christophe Lyon]

Ping?

On 1 December 2016 at 15:27, Christophe Lyon  wrote:
> Hi,
>
>
> On 10 November 2016 at 15:10, Christophe Lyon
>  wrote:
>> On 10 November 2016 at 11:05, Richard Earnshaw
>>  wrote:
>>> On 09/11/16 21:29, Christophe Lyon wrote:
 Hi,

 PR 78253 shows that the handling of weak references has changed for
 ARM with gcc-5.

 When r220674 was committed, default_binds_local_p_2 gained a new
 parameter (weak_dominate), which, when true, implies that a reference
 to a weak symbol defined locally will be resolved locally, even though
 it could be overridden by a strong definition in another object file.

 With r220674, default_binds_local_p forces weak_dominate=true,
 effectively changing the previous behavior.

 The attached patch introduces default_binds_local_p_4 which is a copy
 of default_binds_local_p_2, but using weak_dominate=false, and updates
 the ARM target to call default_binds_local_p_4 instead of
 default_binds_local_p_2.

 I ran cross-tests on various arm* configurations with no regression,
 and checked that the test attached to the original bugzilla now works
 as expected.

 I am not sure why weak_dominate defaults to true, and I couldn't
 really understand why by reading the threads related to r220674 and
 following updates to default_binds_local_p_* which all deal with other
 corner cases and do not discuss the weak_dominate parameter.

 Or should this patch be made more generic?

>>>
>>> I certainly don't think it should be ARM specific.
>> That was my feeling too.
>>
>>>
>>> The questions I have are:
>>>
>>> 1) What do other targets do today.  Are they the same, or different?
>>
>> arm, aarch64, s390 use default_binds_local_p_2 since PR 65780, and
>> default_binds_local_p before that. Both have weak_dominate=true
>> i386 has its own version, calling default_binds_local_p_3 with true
>> for weak_dominate
>>
>> But the behaviour of default_binds_local_p changed with r220674 as I said 
>> above.
>> See https://gcc.gnu.org/viewcvs/gcc?view=revision=220674 and
>> notice how weak_dominate was introduced
>>
>> The original bug report is about a different case:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
>>
>> The original patch submission is
>> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00410.html
>> and the 1st version with weak_dominate is in:
>> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00469.html
>> but it's not clear to me why this was introduced
>>
>>> 2) If different why?
>> on aarch64, although binds_local_p returns true, the relocations used when
>> building the function pointer is still the same (still via the GOT).
>>
>> aarch64 has different logic than arm when accessing a symbol
>> (eg aarch64_classify_symbol)
>>
>>> 3) Is the current behaviour really what was intended by the patch?  ie.
>>> Was the old behaviour actually wrong?
>>>
>> That's what I was wondering.
>> Before r220674, calling a weak function directly or via a function
>> pointer had the same effect (in other words, the function pointer
>> points to the actual implementation: the strong one if any, the weak
>> one otherwise).
>>
>> After r220674, on arm the function pointer points to the weak
>> definition, which seems wrong to me, it should leave the actual
>> resolution to the linker.
>>
>>
>
> After looking at the aarch64 port, I think that references to weak symbols
> have to be handled carefully, to make sure they cannot be resolved
> by the assembler, since the weak symbol can be overridden by a strong
> definition at link-time.
>
> Here is a new patch which does that.
> Validated on arm* targets with no regression, and I checked that the
> original testcase now executes as expected.
>
> Christophe
>
>
>>> R.
 Thanks,

 Christophe

>>>

Backports from trunk to 6 branch

[Jakub Jelinek]

Hi!

I've backported a couple of patches from trunk to 6 branch,
bootstrapped/regtested on x86_64-linux and i686-linux, committed
to 6.x.

Jakub
2016-12-07  Jakub Jelinek  

Backported from mainline
2016-09-16  Jakub Jelinek  

PR c++/77375
* class.c (check_bases): Set CLASSTYPE_HAS_MUTABLE if any
TYPE_HAS_MUTABLE_P for any bases.

* g++.dg/cpp0x/mutable1.C: New test.

--- gcc/cp/class.c  (revision 240194)
+++ gcc/cp/class.c  (revision 240195)
@@ -1796,6 +1796,8 @@ check_bases (tree t,
   SET_CLASSTYPE_REF_FIELDS_NEED_INIT
(t, CLASSTYPE_REF_FIELDS_NEED_INIT (t)
 | CLASSTYPE_REF_FIELDS_NEED_INIT (basetype));
+  if (TYPE_HAS_MUTABLE_P (basetype))
+   CLASSTYPE_HAS_MUTABLE (t) = 1;
 
   /*  A standard-layout class is a class that:
  ...
--- gcc/testsuite/g++.dg/cpp0x/mutable1.C   (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/mutable1.C   (revision 240195)
@@ -0,0 +1,12 @@
+// PR c++/77375
+// { dg-do run { target c++11 } }
+
+struct Base { mutable int i; };
+struct Derived : Base {};
+const Derived foo{};
+
+int
+main ()
+{
+  foo.i = 42;
+}
2016-12-07  Jakub Jelinek  

Backported from mainline
2016-09-16  Jakub Jelinek  

PR c++/77482
* error.c (dump_simple_decl): Only check DECL_DECLARED_CONCEPT_P
if DECL_LANG_SPECIFIC is non-NULL.  Fix up formatting.

PR c++/77482
* g++.dg/cpp0x/constexpr-77482.C: New test.

--- gcc/cp/error.c  (revision 240197)
+++ gcc/cp/error.c  (revision 240198)
@@ -959,14 +959,13 @@ dump_simple_decl (cxx_pretty_printer *pp
 {
   if (flags & TFF_DECL_SPECIFIERS)
 {
-  if (VAR_P (t)
- && DECL_DECLARED_CONSTEXPR_P (t))
-{
-  if (DECL_DECLARED_CONCEPT_P (t))
-pp_cxx_ws_string (pp, "concept");
-  else
-   pp_cxx_ws_string (pp, "constexpr");
-}
+  if (VAR_P (t) && DECL_DECLARED_CONSTEXPR_P (t))
+{
+ if (DECL_LANG_SPECIFIC (t) && DECL_DECLARED_CONCEPT_P (t))
+   pp_cxx_ws_string (pp, "concept");
+ else
+   pp_cxx_ws_string (pp, "constexpr");
+   }
   dump_type_prefix (pp, type, flags & ~TFF_UNQUALIFIED_NAME);
   pp_maybe_space (pp);
 }
--- gcc/testsuite/g++.dg/cpp0x/constexpr-77482.C(revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/constexpr-77482.C(revision 240198)
@@ -0,0 +1,6 @@
+// PR c++/77482
+// { dg-do compile { target c++11 } }
+
+constexpr auto x;  // { dg-error "declaration\[^\n\r]*has no initializer" }
+extern struct S s;
+constexpr auto y = s;  // { dg-error "has incomplete type" }
2016-12-07  Jakub Jelinek  

Backported from mainline
2016-09-19  Jakub Jelinek  
Jan Hubicka  

PR target/77587
* cgraph.c (cgraph_node::rtl_info): Pass  to
ultimate_alias_target call, return NULL if avail < AVAIL_AVAILABLE.
Call ultimate_alias_target just once, not up to 4 times.

* gcc.dg/pr77587.c: New test.
* gcc.dg/pr77587a.c: New file.

--- gcc/cgraph.c(revision 240231)
+++ gcc/cgraph.c(revision 240232)
@@ -1955,14 +1955,17 @@ cgraph_node::rtl_info (tree decl)
   cgraph_node *node = get (decl);
   if (!node)
 return NULL;
-  node = node->ultimate_alias_target ();
-  if (node->decl != current_function_decl
-  && !TREE_ASM_WRITTEN (node->decl))
+  enum availability avail;
+  node = node->ultimate_alias_target ();
+  if (decl != current_function_decl
+  && (avail < AVAIL_AVAILABLE
+ || (node->decl != current_function_decl
+ && !TREE_ASM_WRITTEN (node->decl
 return NULL;
-  /* Allocate if it doesnt exist.  */
-  if (node->ultimate_alias_target ()->rtl == NULL)
-node->ultimate_alias_target ()->rtl = ggc_cleared_alloc 
();
-  return node->ultimate_alias_target ()->rtl;
+  /* Allocate if it doesn't exist.  */
+  if (node->rtl == NULL)
+node->rtl = ggc_cleared_alloc ();
+  return node->rtl;
 }
 
 /* Return a string describing the failure REASON.  */
--- gcc/testsuite/gcc.dg/pr77587.c  (revision 0)
+++ gcc/testsuite/gcc.dg/pr77587.c  (revision 240232)
@@ -0,0 +1,14 @@
+/* PR target/77587 */
+/* { dg-do run } */
+/* { dg-require-weak-override "" } */
+/* { dg-additional-sources "pr77587a.c" } */
+
+void
+bar (long x, long y, long z)
+{
+  struct __attribute__((aligned (16))) S { long a, b, c, d; } s;
+  char *p = (char *) 
+  __asm ("" : "+r" (p));
+  if (((__UINTPTR_TYPE__) p) & 15)
+__builtin_abort ();
+}
--- gcc/testsuite/gcc.dg/pr77587a.c (revision 0)
+++ gcc/testsuite/gcc.dg/pr77587a.c (revision 240232)
@@ -0,0 +1,23 @@
+/* PR target/77587 */
+/* { dg-do compile } */
+/* { dg-require-weak-override "" } */
+
+void
+foo (long x, long y, long z)
+{
+}
+
+void bar (long x, long y,