Re: [PATCH] Fix MIN_EXPR/MAX_EXPR expansion for vector types (PR rtl-optimization/79901)

[Richard Biener]

On Mon, 6 Mar 2017, Jakub Jelinek wrote:

> Hi!
> 
> This is the middle-end for the same PR.  While supporting min/max for
> avx512f V8DI generates of course better code, when the backend claims it is
> not available, we should not ICE on that by trying to expand the vector
> min/max by expanding comparison and jump.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard.

> 2017-03-06  Jakub Jelinek  
> 
>   PR rtl-optimization/79901
>   * expr.c (expand_expr_real_2): For vector MIN/MAX, if there is no
>   min/max expander, expand it using expand_vec_cond_expr.
> 
> --- gcc/expr.c.jj 2017-03-02 10:15:32.0 +0100
> +++ gcc/expr.c2017-03-06 16:07:56.159868534 +0100
> @@ -8943,6 +8943,18 @@ expand_expr_real_2 (sepops ops, rtx targ
>if (temp != 0)
>   return temp;
>  
> +  /* For vector MIN , expand it a VEC_COND_EXPR 
> +  and similarly for MAX .  */
> +  if (VECTOR_TYPE_P (type))
> + {
> +   tree t0 = make_tree (type, op0);
> +   tree t1 = make_tree (type, op1);
> +   tree comparison = build2 (code == MIN_EXPR ? LE_EXPR : GE_EXPR,
> + type, t0, t1);
> +   return expand_vec_cond_expr (type, comparison, t0, t1,
> +original_target);
> + }
> +
>/* At this point, a MEM target is no longer useful; we will get better
>code without it.  */
>  
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH] i386: Do not align small stack slots to 16 bytes

[Jakub Jelinek]

On Tue, Mar 07, 2017 at 08:23:17AM +0100, Uros Bizjak wrote:
> On Mon, Mar 6, 2017 at 6:51 PM, Segher Boessenkool
>  wrote:
> > As Shmuel reported in 
> > ,
> > on x86-64 small structures in automatic storage are aligned to 16 bytes.
> > This seems to be because of a mix-up between bits and bytes in the i386
> > target code.
> >
> > Is this okay for trunk?
> >
> >
> > Segher
> >
> >
> > 2017-03-06  Segher Boessenkool  
> >
> > * gcc/config/i386/i386.c (ix86_local_alignment): Align most 
> > aggregates
> > of 16 bytes and more to 16 bytes, not those of 16 bits and more.
> 
> OK for trunk and backports.

Just without gcc/ prefix in ChangeLog ;)

Jakub

Re: [PATCH] i386: Do not align small stack slots to 16 bytes

[Uros Bizjak]

On Mon, Mar 6, 2017 at 6:51 PM, Segher Boessenkool
 wrote:
> As Shmuel reported in ,
> on x86-64 small structures in automatic storage are aligned to 16 bytes.
> This seems to be because of a mix-up between bits and bytes in the i386
> target code.
>
> Is this okay for trunk?
>
>
> Segher
>
>
> 2017-03-06  Segher Boessenkool  
>
> * gcc/config/i386/i386.c (ix86_local_alignment): Align most aggregates
> of 16 bytes and more to 16 bytes, not those of 16 bits and more.

OK for trunk and backports.

Thanks,
Uros.

> ---
>  gcc/config/i386/i386.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 754c016..f03e71a 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -30467,7 +30467,7 @@ ix86_local_alignment (tree exp, machine_mode mode,
>   != TYPE_MAIN_VARIANT (va_list_type_node)))
>   && TYPE_SIZE (type)
>   && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
> - && wi::geu_p (TYPE_SIZE (type), 16)
> + && wi::geu_p (TYPE_SIZE (type), 128)
>   && align < 128)
> return 128;
>  }
> --
> 1.9.3
>

Re: [PATCH] Fix {s,u}{min,max}v[842]di3 expanders (PR rtl-optimization/79901)

[Uros Bizjak]

On Mon, Mar 6, 2017 at 9:59 PM, Jakub Jelinek  wrote:
> Hi!
>
> vp{min,max}{s,u}q instructions are available already on avx512f (for
> 128-bit/256-bit EVEX encoded with avx512vl), the expander has been
> incorrectly requiring avx512bw for V8DImode.
> The first hunk is just fpr consistency, the insns don't require avx512bw
> anywhere, so naming it that way is misleading.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2017-03-06  Jakub Jelinek  
>
> PR rtl-optimization/79901
> * config/i386/sse.md (*avx512bw_3): Renamed to
> ...
> (*avx512f_3): ... this.
> (3 with maxmin code iterator): Use VI8_AVX2_AVX512F
> iterator instead of VI8_AVX2_AVX512BW.
>
> * gcc.target/i386/pr79901.c: New test.

OK.

Thanks,
Uros.

> --- gcc/config/i386/sse.md.jj   2017-03-06 12:35:27.0 +0100
> +++ gcc/config/i386/sse.md  2017-03-06 15:32:54.484585101 +0100
> @@ -10841,7 +10841,7 @@ (define_expand "3_mask"
>"TARGET_AVX512F"
>"ix86_fixup_binary_operands_no_copy (, mode, operands);")
>
> -(define_insn "*avx512bw_3"
> +(define_insn "*avx512f_3"
>[(set (match_operand:VI48_AVX512VL 0 "register_operand" "=v")
> (maxmin:VI48_AVX512VL
>   (match_operand:VI48_AVX512VL 1 "nonimmediate_operand" "%v")
> @@ -10865,10 +10865,10 @@ (define_insn "
> (set_attr "mode" "")])
>
>  (define_expand "3"
> -  [(set (match_operand:VI8_AVX2_AVX512BW 0 "register_operand")
> -   (maxmin:VI8_AVX2_AVX512BW
> - (match_operand:VI8_AVX2_AVX512BW 1 "register_operand")
> - (match_operand:VI8_AVX2_AVX512BW 2 "register_operand")))]
> +  [(set (match_operand:VI8_AVX2_AVX512F 0 "register_operand")
> +   (maxmin:VI8_AVX2_AVX512F
> + (match_operand:VI8_AVX2_AVX512F 1 "register_operand")
> + (match_operand:VI8_AVX2_AVX512F 2 "register_operand")))]
>"TARGET_SSE4_2"
>  {
>if (TARGET_AVX512F
> --- gcc/testsuite/gcc.target/i386/pr79901.c.jj  2017-03-06 15:34:19.969487037 
> +0100
> +++ gcc/testsuite/gcc.target/i386/pr79901.c 2017-03-06 15:34:02.0 
> +0100
> @@ -0,0 +1,22 @@
> +/* PR rtl-optimization/79901 */
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -mavx512f -fno-ssa-phiopt" } */
> +
> +unsigned int
> +foo (const unsigned long long x)
> +{
> +  if (x < 0)
> +return 0;
> +  else if ( x > ~0U)
> +return ~0U;
> +  else
> +return (unsigned int) x;
> +}
> +
> +void
> +bar (unsigned x, unsigned int *y, unsigned int z)
> +{
> +  unsigned i;
> +  for (i = 0; i < x; i++)
> +y[i] = foo (y[i] * (unsigned long long) z);
> +}
>
> Jakub

Re: [PATCH] Fix ubsan ICE (PR sanitizer/79897)

[Jeff Law]

On 03/06/2017 03:58 PM, Jakub Jelinek wrote:

Hi!

Apparently fold_build_addr_expr doesn't make the argument addressable,
it is only made addressable during following gimplification and that is too
late here.
Yea.  There's some special stuff going on here.  I've never dug into the 
details myself -- Richi knows it better than I.





Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2017-03-06  Jakub Jelinek  

PR sanitizer/79897
* ubsan.c (ubsan_encode_value): Call mark_addressable on the
temporary.

IMHO, you've got carte blanche in the sanitizer bits.  So Ok.

jeff

[committed] Fix varargs padding on hppa64 target

[John David Anglin]

The attached change fixes PR target/77850 on hppa64.  The define for 
PAD_VARARGS_DOWN needs
to match the behaviour selected in pa_function_arg_padding().  That is complex 
and vector types should
not be padded down.

Tested on hppa64-hp-hpux11.11.  Committed to trunk, gcc-6 and gcc-5 branches.

Dave
--
John David Anglin   dave.ang...@bell.net

2017-03-06  John David Anglin  

PR target/77850
* config/pa/pa-64.h (PAD_VARARGS_DOWN): Don't pad down complex and
vector types.

Index: config/pa/pa-64.h
===
--- config/pa/pa-64.h   (revision 245894)
+++ config/pa/pa-64.h   (working copy)
@@ -83,7 +83,10 @@
arguments are padded down when BYTES_BIG_ENDIAN is true.  We don't
want aggregates padded down.  */
 
-#define PAD_VARARGS_DOWN (!AGGREGATE_TYPE_P (type))
+#define PAD_VARARGS_DOWN \
+  (!AGGREGATE_TYPE_P (type) \
+   && TREE_CODE (type) != COMPLEX_TYPE \
+   && TREE_CODE (type) != VECTOR_TYPE)
 
 /* In the PA architecture, it is not possible to directly move data
between GENERAL_REGS and FP_REGS.  On the 32-bit port, we use the

[PATCH] Fix ubsan ICE (PR sanitizer/79897)

[Jakub Jelinek]

Hi!

Apparently fold_build_addr_expr doesn't make the argument addressable,
it is only made addressable during following gimplification and that is too
late here.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2017-03-06  Jakub Jelinek  

PR sanitizer/79897
* ubsan.c (ubsan_encode_value): Call mark_addressable on the
temporary.

--- gcc/ubsan.c.jj  2017-02-21 09:03:57.0 +0100
+++ gcc/ubsan.c 2017-03-06 21:37:32.013422810 +0100
@@ -145,6 +145,7 @@ ubsan_encode_value (tree t, bool in_expa
 code by making vars unnecessarily addressable.  */
  tree var = create_tmp_var (type);
  tree tem = build2 (MODIFY_EXPR, void_type_node, var, t);
+ mark_addressable (var);
  if (in_expand_p)
{
  rtx mem
--- gcc/testsuite/c-c++-common/ubsan/pr79897.c.jj   2017-03-06 
21:48:01.007297214 +0100
+++ gcc/testsuite/c-c++-common/ubsan/pr79897.c  2017-03-06 21:42:56.505230894 
+0100
@@ -0,0 +1,15 @@
+/* PR sanitizer/79897 */
+/* { dg-do compile } */
+/* { dg-options "-fsanitize=enum -O2" } */
+
+enum E
+{
+  A = 0,
+  B = ~0U + 1LL
+} x = A;
+
+int
+main ()
+{
+  return x != A;
+}

Jakub

Re: [PATCH] Fix GC PCH bug in dwarf2out.c (PR c++/79821)

[Jason Merrill]

OK.

On Mon, Mar 6, 2017 at 3:56 PM, Jakub Jelinek  wrote:
> Hi!
>
> gengtype.c considers all GC arrays with char/unsigned char/signed char
> element type as strings, for which it computes size e.g. in gt_pch_note_object
> using:
>   if (note_ptr_fn == gt_pch_p_S)
> (*slot)->size = strlen ((const char *)obj) + 1;
>   else
> (*slot)->size = ggc_get_size (obj);
> That is really undesirable if the array is actually a collection of random
> bytes rather than a NUL terminated string - then we can either compute
> smaller size if there are zeros in the array, or if unlucky enough and there
> are no zero bytes until end of mapped region, segfault.
>
> Fixed by avoiding the gt_pch_*_S handling by using void * pointer instead.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, and Rainer has kindly
> tested it on sparc*-solaris* where it caused bootstrap issues.  Ok for
> trunk?
>
> 2017-03-06  Jakub Jelinek  
>
> PR c++/79821
> * dwarf2out.h (dw_vec_const): Change array type from unsigned char *
> to void * for PCH reasons.
> * dwarf2out.c (output_loc_operands, output_die): Cast
> v.val_vec.array to unsigned char *.
>
> --- gcc/dwarf2out.h.jj  2017-01-01 12:45:37.0 +0100
> +++ gcc/dwarf2out.h 2017-03-06 12:13:48.809589411 +0100
> @@ -163,7 +163,7 @@ enum dw_val_class
>  /* Describe a floating point constant value, or a vector constant value.  */
>
>  struct GTY(()) dw_vec_const {
> -  unsigned char * GTY((atomic)) array;
> +  void * GTY((atomic)) array;
>unsigned length;
>unsigned elt_size;
>  };
> --- gcc/dwarf2out.c.jj  2017-02-25 09:17:44.0 +0100
> +++ gcc/dwarf2out.c 2017-03-06 12:15:52.668958458 +0100
> @@ -2020,7 +2020,7 @@ output_loc_operands (dw_loc_descr_ref lo
> elt_size /= 2;
> len *= 2;
>   }
> -   for (i = 0, p = val2->v.val_vec.array;
> +   for (i = 0, p = (unsigned char *) val2->v.val_vec.array;
>  i < len;
>  i++, p += elt_size)
>   dw2_asm_output_data (elt_size, extract_int (p, elt_size),
> @@ -2273,7 +2273,7 @@ output_loc_operands (dw_loc_descr_ref lo
>   elt_size /= 2;
>   len *= 2;
> }
> - for (i = 0, p = val2->v.val_vec.array;
> + for (i = 0, p = (unsigned char *) val2->v.val_vec.array;
>i < len;
>i++, p += elt_size)
> dw2_asm_output_data (elt_size, extract_int (p, elt_size),
> @@ -10105,7 +10105,7 @@ output_die (dw_die_ref die)
> elt_size /= 2;
> len *= 2;
>   }
> -   for (i = 0, p = a->dw_attr_val.v.val_vec.array;
> +   for (i = 0, p = (unsigned char *) a->dw_attr_val.v.val_vec.array;
>  i < len;
>  i++, p += elt_size)
>   dw2_asm_output_data (elt_size, extract_int (p, elt_size),
>
> Jakub

C PATCH to fix ICE with old-style parameter declarations with initializers (PR sanitizer/79757)

[Marek Polacek]

This is an ICE with -fsanitize=undefined on invalid code involving old-style
parameter declarations and nested functions.  Ugh.

Old-style parameter declarations cannot have initializers, and start_decl
errors when it sees that something's trying to initialize a PARM_DECL, but
nonetheless, we still attempt to parse the initializer, eventually arriving in
build_binary_op, which means we will instrument the bogus initializer.

This causes a crash in ubsan_encode_value -> create_tmp_var -> declare_vars: it
thinks it's processing a nested function, but the body of the function is null,
leading to the crash.

I suppose the best fix is to avoid instrumenting such bogus initializers.  In
c_parser_declaration_or_fndef it's easy to determine if we're initializing a
PARM_DECL -- just check DECL's code, but with __auto_type that's not possible,
because start_decl is called *after* parsing the initializer.  So instead of
DECL's code I'm checking nested && !empty_ok.

But we still want to instrument variables with initializers in nested
functions, so I've added two run-time tests for that.

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

2017-03-06  Marek Polacek  

PR sanitizer/79757
* c-parser.c (c_parser_declaration_or_fndef): Don't sanitize old-style
parameter declarations with initializers.

* gcc.dg/ubsan/pr79757-1.c: New test.
* gcc.dg/ubsan/pr79757-2.c: New test.
* gcc.dg/ubsan/pr79757-3.c: New test.
* gcc.dg/ubsan/pr79757-4.c: New test.
* gcc.dg/ubsan/pr79757-5.c: New test.

diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index fa4e950..6ff023c 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -1859,7 +1859,13 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
fndef_ok,
  init_loc = c_parser_peek_token (parser)->location;
  rich_location richloc (line_table, init_loc);
  start_init (NULL_TREE, asm_name, global_bindings_p (), 
&richloc);
+ /* A parameter is initialized, which is invalid.  Don't
+attempt to instrument the initializer.  */
+ int flag_sanitize_save = flag_sanitize;
+ if (nested && !empty_ok)
+   flag_sanitize = 0;
  init = c_parser_expr_no_commas (parser, NULL);
+ flag_sanitize = flag_sanitize_save;
  if (TREE_CODE (init.value) == COMPONENT_REF
  && DECL_C_BIT_FIELD (TREE_OPERAND (init.value, 1)))
error_at (here,
@@ -1917,7 +1923,13 @@ c_parser_declaration_or_fndef (c_parser *parser, bool 
fndef_ok,
  init_loc = c_parser_peek_token (parser)->location;
  rich_location richloc (line_table, init_loc);
  start_init (d, asm_name, global_bindings_p (), &richloc);
+ /* A parameter is initialized, which is invalid.  Don't
+attempt to instrument the initializer.  */
+ int flag_sanitize_save = flag_sanitize;
+ if (TREE_CODE (d) == PARM_DECL)
+   flag_sanitize = 0;
  init = c_parser_initializer (parser);
+ flag_sanitize = flag_sanitize_save;
  finish_init ();
}
  if (oacc_routine_data)
diff --git gcc/testsuite/gcc.dg/ubsan/pr79757-1.c 
gcc/testsuite/gcc.dg/ubsan/pr79757-1.c
index e69de29..ca074bc 100644
--- gcc/testsuite/gcc.dg/ubsan/pr79757-1.c
+++ gcc/testsuite/gcc.dg/ubsan/pr79757-1.c
@@ -0,0 +1,24 @@
+/* PR sanitizer/79757 */
+/* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
+/* { dg-options "-fsanitize=undefined" } */
+
+unsigned __int128 x, y;
+
+void
+fn1 (void)
+{
+  int a (z)
+unsigned long long z = x / y; /* { dg-error "parameter 'z' is initialized" 
} */
+  {
+  }
+}
+
+void
+fn2 (void)
+{
+  int a (z)
+unsigned long long z = x >> y; /* { dg-error "parameter 'z' is 
initialized" } */
+  {
+  }
+}
diff --git gcc/testsuite/gcc.dg/ubsan/pr79757-2.c 
gcc/testsuite/gcc.dg/ubsan/pr79757-2.c
index e69de29..b3e1939 100644
--- gcc/testsuite/gcc.dg/ubsan/pr79757-2.c
+++ gcc/testsuite/gcc.dg/ubsan/pr79757-2.c
@@ -0,0 +1,18 @@
+/* PR sanitizer/79757 */
+/* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
+/* { dg-options "-fsanitize=undefined" } */
+
+unsigned __int128 x, y;
+
+void
+fn1 (z)
+  unsigned long long z = x / y; /* { dg-error "parameter 'z' is initialized" } 
*/
+{
+}
+
+void
+fn2 (z)
+  unsigned long long z = x >> y; /* { dg-error "parameter 'z' is initialized" 
} */
+{
+}
diff --git gcc/testsuite/gcc.dg/ubsan/pr79757-3.c 
gcc/testsuite/gcc.dg/ubsan/pr79757-3.c
index e69de29..22fe3de 100644
--- gcc/testsuite/gcc.dg/ubsan/pr79757-3.c
+++ gcc/testsuite/gcc.dg/ubsan/pr79757-3.c
@@ -0,0 +1,18 @@
+/* PR sanitizer/79757 */
+/* { dg-do compile } */
+/* { dg-require-effective-target int128 } */
+/* { dg-options "-fsanitize=undefined" } */
+
+unsigned __int128 x, 

[PATCH] Fix MIN_EXPR/MAX_EXPR expansion for vector types (PR rtl-optimization/79901)

[Jakub Jelinek]

Hi!

This is the middle-end for the same PR.  While supporting min/max for
avx512f V8DI generates of course better code, when the backend claims it is
not available, we should not ICE on that by trying to expand the vector
min/max by expanding comparison and jump.

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

2017-03-06  Jakub Jelinek  

PR rtl-optimization/79901
* expr.c (expand_expr_real_2): For vector MIN/MAX, if there is no
min/max expander, expand it using expand_vec_cond_expr.

--- gcc/expr.c.jj   2017-03-02 10:15:32.0 +0100
+++ gcc/expr.c  2017-03-06 16:07:56.159868534 +0100
@@ -8943,6 +8943,18 @@ expand_expr_real_2 (sepops ops, rtx targ
   if (temp != 0)
return temp;
 
+  /* For vector MIN , expand it a VEC_COND_EXPR 
+and similarly for MAX .  */
+  if (VECTOR_TYPE_P (type))
+   {
+ tree t0 = make_tree (type, op0);
+ tree t1 = make_tree (type, op1);
+ tree comparison = build2 (code == MIN_EXPR ? LE_EXPR : GE_EXPR,
+   type, t0, t1);
+ return expand_vec_cond_expr (type, comparison, t0, t1,
+  original_target);
+   }
+
   /* At this point, a MEM target is no longer useful; we will get better
 code without it.  */
 

Jakub

[PATCH] Fix {s,u}{min,max}v[842]di3 expanders (PR rtl-optimization/79901)

[Jakub Jelinek]

Hi!

vp{min,max}{s,u}q instructions are available already on avx512f (for
128-bit/256-bit EVEX encoded with avx512vl), the expander has been
incorrectly requiring avx512bw for V8DImode.
The first hunk is just fpr consistency, the insns don't require avx512bw
anywhere, so naming it that way is misleading.

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

2017-03-06  Jakub Jelinek  

PR rtl-optimization/79901
* config/i386/sse.md (*avx512bw_3): Renamed to
...
(*avx512f_3): ... this.
(3 with maxmin code iterator): Use VI8_AVX2_AVX512F
iterator instead of VI8_AVX2_AVX512BW.

* gcc.target/i386/pr79901.c: New test.

--- gcc/config/i386/sse.md.jj   2017-03-06 12:35:27.0 +0100
+++ gcc/config/i386/sse.md  2017-03-06 15:32:54.484585101 +0100
@@ -10841,7 +10841,7 @@ (define_expand "3_mask"
   "TARGET_AVX512F"
   "ix86_fixup_binary_operands_no_copy (, mode, operands);")
 
-(define_insn "*avx512bw_3"
+(define_insn "*avx512f_3"
   [(set (match_operand:VI48_AVX512VL 0 "register_operand" "=v")
(maxmin:VI48_AVX512VL
  (match_operand:VI48_AVX512VL 1 "nonimmediate_operand" "%v")
@@ -10865,10 +10865,10 @@ (define_insn "
(set_attr "mode" "")])
 
 (define_expand "3"
-  [(set (match_operand:VI8_AVX2_AVX512BW 0 "register_operand")
-   (maxmin:VI8_AVX2_AVX512BW
- (match_operand:VI8_AVX2_AVX512BW 1 "register_operand")
- (match_operand:VI8_AVX2_AVX512BW 2 "register_operand")))]
+  [(set (match_operand:VI8_AVX2_AVX512F 0 "register_operand")
+   (maxmin:VI8_AVX2_AVX512F
+ (match_operand:VI8_AVX2_AVX512F 1 "register_operand")
+ (match_operand:VI8_AVX2_AVX512F 2 "register_operand")))]
   "TARGET_SSE4_2"
 {
   if (TARGET_AVX512F
--- gcc/testsuite/gcc.target/i386/pr79901.c.jj  2017-03-06 15:34:19.969487037 
+0100
+++ gcc/testsuite/gcc.target/i386/pr79901.c 2017-03-06 15:34:02.0 
+0100
@@ -0,0 +1,22 @@
+/* PR rtl-optimization/79901 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -mavx512f -fno-ssa-phiopt" } */
+
+unsigned int
+foo (const unsigned long long x)
+{
+  if (x < 0)
+return 0;
+  else if ( x > ~0U)
+return ~0U;
+  else
+return (unsigned int) x;
+}
+
+void
+bar (unsigned x, unsigned int *y, unsigned int z)
+{
+  unsigned i;
+  for (i = 0; i < x; i++)
+y[i] = foo (y[i] * (unsigned long long) z);
+}

Jakub

[PATCH] Fix GC PCH bug in dwarf2out.c (PR c++/79821)

[Jakub Jelinek]

Hi!

gengtype.c considers all GC arrays with char/unsigned char/signed char
element type as strings, for which it computes size e.g. in gt_pch_note_object
using:
  if (note_ptr_fn == gt_pch_p_S)
(*slot)->size = strlen ((const char *)obj) + 1;
  else
(*slot)->size = ggc_get_size (obj);
That is really undesirable if the array is actually a collection of random
bytes rather than a NUL terminated string - then we can either compute
smaller size if there are zeros in the array, or if unlucky enough and there
are no zero bytes until end of mapped region, segfault.

Fixed by avoiding the gt_pch_*_S handling by using void * pointer instead.

Bootstrapped/regtested on x86_64-linux and i686-linux, and Rainer has kindly
tested it on sparc*-solaris* where it caused bootstrap issues.  Ok for
trunk?

2017-03-06  Jakub Jelinek  

PR c++/79821
* dwarf2out.h (dw_vec_const): Change array type from unsigned char *
to void * for PCH reasons.
* dwarf2out.c (output_loc_operands, output_die): Cast
v.val_vec.array to unsigned char *.

--- gcc/dwarf2out.h.jj  2017-01-01 12:45:37.0 +0100
+++ gcc/dwarf2out.h 2017-03-06 12:13:48.809589411 +0100
@@ -163,7 +163,7 @@ enum dw_val_class
 /* Describe a floating point constant value, or a vector constant value.  */
 
 struct GTY(()) dw_vec_const {
-  unsigned char * GTY((atomic)) array;
+  void * GTY((atomic)) array;
   unsigned length;
   unsigned elt_size;
 };
--- gcc/dwarf2out.c.jj  2017-02-25 09:17:44.0 +0100
+++ gcc/dwarf2out.c 2017-03-06 12:15:52.668958458 +0100
@@ -2020,7 +2020,7 @@ output_loc_operands (dw_loc_descr_ref lo
elt_size /= 2;
len *= 2;
  }
-   for (i = 0, p = val2->v.val_vec.array;
+   for (i = 0, p = (unsigned char *) val2->v.val_vec.array;
 i < len;
 i++, p += elt_size)
  dw2_asm_output_data (elt_size, extract_int (p, elt_size),
@@ -2273,7 +2273,7 @@ output_loc_operands (dw_loc_descr_ref lo
  elt_size /= 2;
  len *= 2;
}
- for (i = 0, p = val2->v.val_vec.array;
+ for (i = 0, p = (unsigned char *) val2->v.val_vec.array;
   i < len;
   i++, p += elt_size)
dw2_asm_output_data (elt_size, extract_int (p, elt_size),
@@ -10105,7 +10105,7 @@ output_die (dw_die_ref die)
elt_size /= 2;
len *= 2;
  }
-   for (i = 0, p = a->dw_attr_val.v.val_vec.array;
+   for (i = 0, p = (unsigned char *) a->dw_attr_val.v.val_vec.array;
 i < len;
 i++, p += elt_size)
  dw2_asm_output_data (elt_size, extract_int (p, elt_size),

Jakub

Re: patch to fix PR79571

[Jakub Jelinek]

On Mon, Mar 06, 2017 at 09:35:08PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 06, 2017 at 03:31:49PM -0500, Vladimir Makarov wrote:
> > 
> > Sorry the ChangeLog entry had typos.  Here is the final variant
> > 
> > 2017-03-06  Vladimir Makarov  
> > 
> > PR rtl-optimization/79571
> > * lra-constraints.c (process_alt_operands): Calculate static
> 
> One more: Calculate ?

Ignore me, too tired.

> > reject and subtract it from overall when only addresses will be
> > reloaded.

Jakub

Re: patch to fix PR79571

[Jakub Jelinek]

On Mon, Mar 06, 2017 at 03:31:49PM -0500, Vladimir Makarov wrote:
> 
> Sorry the ChangeLog entry had typos.  Here is the final variant
> 
> 2017-03-06  Vladimir Makarov  
> 
> PR rtl-optimization/79571
> * lra-constraints.c (process_alt_operands): Calculate static

One more: Calculate ?

> reject and subtract it from overall when only addresses will be
> reloaded.

Jakub

Re: patch to fix PR79571

[Vladimir Makarov]

Sorry the ChangeLog entry had typos.  Here is the final variant

2017-03-06  Vladimir Makarov  

PR rtl-optimization/79571
* lra-constraints.c (process_alt_operands): Calculate static
reject and subtract it from overall when only addresses will be
reloaded.

patch to fix PR79571

[Vladimir Makarov]

A patch in the attachment fixes

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

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

Committed as rev. 245928

Index: ChangeLog
===
--- ChangeLog	(revision 245927)
+++ ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2017-03-06  Vladimir Makarov  
+
+	PR rtl-optimization/79571
+	* lra-constraints.c (process_alt_operands): Claculate static
+	reject and subtract it from overal when there will be only address
+	reloads.
+
 2017-03-06  Julia Koval  
 
 	PR target/79793
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 245843)
+++ lra-constraints.c	(working copy)
@@ -1867,11 +1867,15 @@ process_alt_operands (int only_alternati
   /* LOSERS counts the operands that don't fit this alternative and
  would require loading.  */
   int losers;
+  int addr_losers;
   /* REJECT is a count of how undesirable this alternative says it is
  if any reloading is required.  If the alternative matches exactly
  then REJECT is ignored, but otherwise it gets this much counted
  against it in addition to the reloading needed.  */
   int reject;
+  /* This is defined by '!' or '?' alternative constraint and added to
+ reject.  But in some cases it can be ignored.  */
+  int static_reject;
   int op_reject;
   /* The number of elements in the following array.  */
   int early_clobbered_regs_num;
@@ -1948,7 +1952,8 @@ process_alt_operands (int only_alternati
   if (!TEST_BIT (preferred, nalt))
 	continue;
 
-  overall = losers = reject = reload_nregs = reload_sum = 0;
+  overall = losers = addr_losers = 0;
+  static_reject = reject = reload_nregs = reload_sum = 0;
   for (nop = 0; nop < n_operands; nop++)
 	{
 	  int inc = (curr_static_id
@@ -1956,8 +1961,9 @@ process_alt_operands (int only_alternati
 	  if (lra_dump_file != NULL && inc != 0)
 	fprintf (lra_dump_file,
 		 "Staticly defined alt reject+=%d\n", inc);
-	  reject += inc;
+	  static_reject += inc;
 	}
+  reject += static_reject;
   early_clobbered_regs_num = 0;
 
   for (nop = 0; nop < n_operands; nop++)
@@ -2704,6 +2710,9 @@ process_alt_operands (int only_alternati
 		   nop);
 		  reject++;
 		}
+
+	  if (MEM_P (op) && offmemok)
+		addr_losers++;
 	}
 
 	  if (early_clobber_p && ! scratch_p)
@@ -2718,7 +2727,8 @@ process_alt_operands (int only_alternati
 	 Should we update the cost (may be approximately) here
 	 because of early clobber register reloads or it is a rare
 	 or non-important thing to be worth to do it.  */
-	  overall = losers * LRA_LOSER_COST_FACTOR + reject;
+	  overall = (losers * LRA_LOSER_COST_FACTOR + reject
+		 - (addr_losers == losers ? static_reject : 0));
 	  if ((best_losers == 0 || losers != 0) && best_overall < overall)
 {
   if (lra_dump_file != NULL)
@@ -2742,6 +2752,7 @@ process_alt_operands (int only_alternati
 	  if (early_clobber_p && operand_reg[nop] != NULL_RTX)
 	early_clobbered_nops[early_clobbered_regs_num++] = nop;
 	}
+
   if (curr_insn_set != NULL_RTX && n_operands == 2
 	  /* Prevent processing non-move insns.  */
 	  && (GET_CODE (SET_SRC (curr_insn_set)) == SUBREG
@@ -2753,9 +2764,15 @@ process_alt_operands (int only_alternati
 		   || reg_in_class_p (no_subreg_reg_operand[1], curr_alt[0])))
 	  || (! curr_alt_win[0] && curr_alt_win[1]
 		  && REG_P (no_subreg_reg_operand[1])
+		  /* Check that we reload memory not the memory
+		 address.  */
+		  && !curr_alt_offmemok[0]
 		  && reg_in_class_p (no_subreg_reg_operand[1], curr_alt[0]))
 	  || (curr_alt_win[0] && ! curr_alt_win[1]
 		  && REG_P (no_subreg_reg_operand[0])
+		  /* Check that we reload memory not the memory
+		 address.  */
+		  && !curr_alt_offmemok[1]
 		  && reg_in_class_p (no_subreg_reg_operand[0], curr_alt[1])
 		  && (! CONST_POOL_OK_P (curr_operand_mode[1],
 	 no_subreg_reg_operand[1])
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 245927)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2017-03-06  Vladimir Makarov  
+
+	PR rtl-optimization/79571
+	* gcc.target/i386/pr79571.c: New.
+
 2017-03-06  Marek Polacek  
 
 	PR c++/79796 - ICE with NSDMI and this pointer
Index: testsuite/gcc.target/i386/pr79571.c
===
--- testsuite/gcc.target/i386/pr79571.c	(nonexistent)
+++ testsuite/gcc.target/i386/pr79571.c	(working copy)
@@ -0,0 +1,25 @@
+/* PR rtl-optimization/79571 */
+/* { dg-do compile } */
+/* { dg-options "-O -mno-sse -w" } */
+
+struct a
+{
+  int b;
+  int *c
+} h;
+struct d
+{
+  struct a e
+};
+struct fd
+{
+  struct d *d
+} i;
+g;
+j ()
+{
+  unsigned a = g;
+  i = (struct fd){a & 3};
+  struct fd f = i;
+  h = f.d->e;
+}

Re: [PATCH, rs6000][GCC6] Fix PR78543, ICE in push_reload on powerpc64le-linux-gnu

[Segher Boessenkool]

On Mon, Mar 06, 2017 at 12:16:58PM -0600, Peter Bergner wrote:

[ big snip, thanks for the thorough explanation! ]

> The following patch passes bootstrap and regtesting on powerpc64le-linux.
> Ok for the GCC 6 branch?

Please also test on BE and 32-bit.

> We don't hit this on trunk, because we're using LRA there, so I'm not
> sure whether we want to add this there this late in the release cycle.

I prefer to have it on trunk as well.  We *do* still support non-LRA
on trunk, just not by default.

This is okay if all testing works out.  Thanks!


Segher

[PATCH, rs6000][GCC6] Fix PR78543, ICE in push_reload on powerpc64le-linux-gnu

[Peter Bergner]

PR78543 has two related test cases that have similar insns that need
reloading (pseudo 185 in this case) due to spills:

(insn 142 144 146 20 (parallel [
(set (reg:HI 4 4 [orig:260 p ] [260])
(bswap:HI (subreg/s/v:HI (reg:DI 185 [ load_dst_59 ]) 0)))
(clobber (scratch:SI))
]) pr78543.i:23 144 {bswaphi2_internal}
 (expr_list:REG_DEAD (reg:DI 185 [ load_dst_59 ])
(nil)))

In simplify_subreg, we execute the following code:

  /* If we have a SUBREG of a register that we are replacing and we are
 replacing it with a MEM, make a new MEM and try replacing the
 SUBREG with it.  Don't do this if the MEM has a mode-dependent address
 or if we would be widening it.  */

  if (MEM_P (op)
  && ! mode_dependent_address_p (XEXP (op, 0), MEM_ADDR_SPACE (op))
  /* Allow splitting of volatile memory references in case we don't
 have instruction to move the whole thing.  */
  && (! MEM_VOLATILE_P (op)
  || ! have_insn_for (SET, innermode))
  && GET_MODE_SIZE (outermode) <= GET_MODE_SIZE (GET_MODE (op)))
return adjust_address_nv (op, outermode, byte);

The address we pass to mode_dependent_address_p() is:

(plus:DI (reg/f:DI 1 1)
 (const_int 65648 [0x10070]))

...which rs6000_mode_dependent_address() says *is* mode dependent, so we
do not end up calling adjust_address_nv() to adjust the stack address.
This ends up leaving us with the followng insn to handle:

  (subreg/s/v:HI (mem/c:DI (plus:DI (plus:DI (reg/f:DI 1 1)
  (const_int 65536 [0x1]))
  (const_int 112 [0x70])) [5 %sfp+65648 S8 A64]) 0)

Which triggers the gcc_assert at reload.c:1348:

  /* Optional output reloads are always OK even if we have no register class,
 since the function of these reloads is only to have spill_reg_store etc.
 set, so that the storing insn can be deleted later.  */
  gcc_assert (rclass != NO_REGS
  || (optional != 0 && type == RELOAD_FOR_OUTPUT));

where: rclass = NO_REGS, optional = 0, type = RELOAD_FOR_INPUT

If we look at rs6000_mode_dependent_address(), it accepts some addresses
as not being mode dependent:

case PLUS:
  /* Any offset from virtual_stack_vars_rtx and arg_pointer_rtx
 is considered a legitimate address before reload, so there
 are no offset restrictions in that case.  Note that this
 condition is safe in strict mode because any address involving
 virtual_stack_vars_rtx or arg_pointer_rtx would already have
 been rejected as illegitimate.  */
  if (XEXP (addr, 0) != virtual_stack_vars_rtx
  && XEXP (addr, 0) != arg_pointer_rtx
  && GET_CODE (XEXP (addr, 1)) == CONST_INT)
{
  unsigned HOST_WIDE_INT val = INTVAL (XEXP (addr, 1));
  return val + 0x8000 >= 0x1 - (TARGET_POWERPC64 ? 8 : 12);
}
  break;

It seems wrong that we accept addresses based off virtual_stack_vars_rtx
and arg_pointer_rtx, but not stack_pointer_rtx (ie, r1) like we have in
these test cases.  Adding a change to accept stack_pointer_rtx, allows
us to call adjust_address_nv() which ends up transforming the:

  (mem:DI (plus (reg:1) (const_int 65648)))
into:
  (mem:HI (plus (reg:1) (const_int 65648)))

allowing us to eliminate the subreg insn below:

  (subreg/s/v:HI (mem/c:DI (plus:DI (plus:DI (reg/f:DI 1 1)
  (const_int 65536 [0x1]))
  (const_int 112 [0x70])) [5 %sfp+65648 S8 A64]) 0)

which solves our ICE.

The following patch passes bootstrap and regtesting on powerpc64le-linux.
Ok for the GCC 6 branch?

We don't hit this on trunk, because we're using LRA there, so I'm not
sure whether we want to add this there this late in the release cycle.

Peter

gcc/
PR target/78543
* config/rs6000/rs6000.c (rs6000_mode_dependent_address): Handle
stack_pointer_rtx.

gcc/testsuite/
PR target/78543
* gcc.target/powerpc/pr78543.c: New test.
* gcc.target/powerpc/pr78543-2.c: Likewise.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 245904)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -8988,6 +8988,7 @@
 been rejected as illegitimate.  */
   if (XEXP (addr, 0) != virtual_stack_vars_rtx
  && XEXP (addr, 0) != arg_pointer_rtx
+ && XEXP (addr, 0) != stack_pointer_rtx
  && GET_CODE (XEXP (addr, 1)) == CONST_INT)
{
  unsigned HOST_WIDE_INT val = INTVAL (XEXP (addr, 1));
Index: gcc/testsuite/gcc.target/powerpc/pr78543-2.c
===
--- gcc/testsuite/gcc.target/powerpc/pr78543-2.c(nonexistent)
+++ gcc/testsuite/gcc.target/powerpc/pr78543-2.c(working copy)
@@ -0,0 +1,60 @@
+/* PR target/78543 */
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { p

[PATCH] i386: Do not align small stack slots to 16 bytes

[Segher Boessenkool]

As Shmuel reported in ,
on x86-64 small structures in automatic storage are aligned to 16 bytes.
This seems to be because of a mix-up between bits and bytes in the i386
target code.

Is this okay for trunk?


Segher


2017-03-06  Segher Boessenkool  

* gcc/config/i386/i386.c (ix86_local_alignment): Align most aggregates
of 16 bytes and more to 16 bytes, not those of 16 bits and more.

---
 gcc/config/i386/i386.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 754c016..f03e71a 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -30467,7 +30467,7 @@ ix86_local_alignment (tree exp, machine_mode mode,
  != TYPE_MAIN_VARIANT (va_list_type_node)))
  && TYPE_SIZE (type)
  && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
- && wi::geu_p (TYPE_SIZE (type), 16)
+ && wi::geu_p (TYPE_SIZE (type), 128)
  && align < 128)
return 128;
 }
-- 
1.9.3

Re: C++ PATCH to fix ICE with NSDMI and this pointer (PR c++/79796)

[Jason Merrill]

OK.

On Fri, Mar 3, 2017 at 6:34 AM, Marek Polacek  wrote:
> We weren't replacing  PLACEHOLDER_EXPR in the following testcase, leading to a
> crash in the gimplifier.  The fix seems to be to use replace_placeholders, the
> question is where.  These three functions have it:
> cp_gimplify_init_expr
> store_init_value
> build_new_1
> But we call neither so I tried adding the call to build_over_call, right
> after we create the MODIFY_EXPR with the NSDMI, and that seemed to work
> out.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2017-03-03  Marek Polacek  
>
> PR c++/79796 - ICE with NSDMI and this pointer
> * call.c (build_over_call): Handle NSDMI with a 'this' by calling
> replace_placeholders.
>
> * g++.dg/cpp0x/nsdmi13.C: New test.
>
> diff --git gcc/cp/call.c gcc/cp/call.c
> index dc629b96..b821224 100644
> --- gcc/cp/call.c
> +++ gcc/cp/call.c
> @@ -8047,6 +8047,9 @@ build_over_call (struct z_candidate *cand, int flags, 
> tsubst_flags_t complain)
> {
>   arg = cp_build_indirect_ref (arg, RO_NULL, complain);
>   val = build2 (MODIFY_EXPR, TREE_TYPE (to), to, arg);
> + if (cxx_dialect >= cxx14)
> +   /* Handle NSDMI that refer to the object being initialized.  */
> +   replace_placeholders (arg, to);
> }
>else
> {
> diff --git gcc/testsuite/g++.dg/cpp0x/nsdmi13.C 
> gcc/testsuite/g++.dg/cpp0x/nsdmi13.C
> index e69de29..2751da3 100644
> --- gcc/testsuite/g++.dg/cpp0x/nsdmi13.C
> +++ gcc/testsuite/g++.dg/cpp0x/nsdmi13.C
> @@ -0,0 +1,13 @@
> +// PR c++/79796
> +// { dg-do compile { target c++11 } }
> +
> +struct A
> +{
> +  A* p = this;
> +};
> +
> +void foo()
> +{
> +  A a;
> +  a = A({});
> +}
>
> Marek

C PATCH to tidy implicit_decl_warning

[Marek Polacek]

I didn't like that the function implicit_decl_warning is
a) missing a comment,
b) missing braces in an if were confusing,
b) wrongly formatted,
   else
 if ()
   is ugly.

This patches fixes the above.

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

2017-03-06  Marek Polacek  

* c-decl.c (implicit_decl_warning): Add a comment.  Fix formatting.

diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 645304a..0f674e9 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -3117,45 +3117,52 @@ pushdecl_top_level (tree x)
   return x;
 }
 
+
+/* Issue a warning about implicit function declaration.  ID is the function
+   identifier, OLDDECL is a declaration of the function in a different scope,
+   or NULL_TREE.  */
+
 static void
 implicit_decl_warning (location_t loc, tree id, tree olddecl)
 {
-  if (warn_implicit_function_declaration)
-{
-  bool warned;
-  const char *hint = NULL;
-  if (!olddecl)
-   hint = lookup_name_fuzzy (id, FUZZY_LOOKUP_FUNCTION_NAME);
+  if (!warn_implicit_function_declaration)
+return;
 
-  if (flag_isoc99)
-   if (hint)
- {
-   gcc_rich_location richloc (loc);
-   richloc.add_fixit_replace (hint);
-   warned = pedwarn_at_rich_loc
- (&richloc, OPT_Wimplicit_function_declaration,
-  "implicit declaration of function %qE; did you mean %qs?",
-  id, hint);
- }
-   else
- warned = pedwarn (loc, OPT_Wimplicit_function_declaration,
-   "implicit declaration of function %qE", id);
+  bool warned;
+  const char *hint = NULL;
+  if (!olddecl)
+hint = lookup_name_fuzzy (id, FUZZY_LOOKUP_FUNCTION_NAME);
+
+  if (flag_isoc99)
+{
+  if (hint)
+   {
+ gcc_rich_location richloc (loc);
+ richloc.add_fixit_replace (hint);
+ warned = pedwarn_at_rich_loc
+   (&richloc, OPT_Wimplicit_function_declaration,
+"implicit declaration of function %qE; did you mean %qs?",
+id, hint);
+   }
   else
-   if (hint)
- {
-   gcc_rich_location richloc (loc);
-   richloc.add_fixit_replace (hint);
-   warned = warning_at_rich_loc
- (&richloc, OPT_Wimplicit_function_declaration,
-  G_("implicit declaration of function %qE; did you mean %qs?"),
-  id, hint);
- }
-   else
- warned = warning_at (loc, OPT_Wimplicit_function_declaration,
-  G_("implicit declaration of function %qE"), id);
-  if (olddecl && warned)
-   locate_old_decl (olddecl);
+   warned = pedwarn (loc, OPT_Wimplicit_function_declaration,
+ "implicit declaration of function %qE", id);
 }
+  else if (hint)
+{
+  gcc_rich_location richloc (loc);
+  richloc.add_fixit_replace (hint);
+  warned = warning_at_rich_loc
+   (&richloc, OPT_Wimplicit_function_declaration,
+G_("implicit declaration of function %qE; did you mean %qs?"),
+id, hint);
+}
+  else
+warned = warning_at (loc, OPT_Wimplicit_function_declaration,
+G_("implicit declaration of function %qE"), id);
+
+  if (olddecl && warned)
+locate_old_decl (olddecl);
 }
 
 /* This function represents mapping of a function code FCODE

Marek

Re: [C++ PATCH] Fix ICE on empty statement expression (PR c++/79822)

[Jason Merrill]

OK.

On Fri, Mar 3, 2017 at 9:34 AM, Jakub Jelinek  wrote:
> Hi!
>
> Seems callers of cxx_eval_constant_expression don't really like if it
> returns NULL, which is what cxx_eval_statement_list returns for empty
> STATEMENT_LIST.  In statement expressions we treat those the same
> as (void) 0 or any other statement with void value.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2017-03-03  Jakub Jelinek  
>
> PR c++/79822
> * constexpr.c (cxx_eval_statement_list): Treat empty ({ }) like
> ({ (void) 0; }).
>
> * g++.dg/cpp0x/constexpr-79822.C: New test.
>
> --- gcc/cp/constexpr.c.jj   2017-02-22 23:03:12.0 +0100
> +++ gcc/cp/constexpr.c  2017-03-03 12:42:02.391773591 +0100
> @@ -3725,8 +3725,9 @@ cxx_eval_statement_list (const constexpr
>  {
>tree_stmt_iterator i;
>tree local_target;
> -  /* In a statement-expression we want to return the last value.  */
> -  tree r = NULL_TREE;
> +  /* In a statement-expression we want to return the last value.
> + For empty statement expression return void_node.  */
> +  tree r = void_node;
>if (!jump_target)
>  {
>local_target = NULL_TREE;
> --- gcc/testsuite/g++.dg/cpp0x/constexpr-79822.C.jj 2017-03-03 
> 12:49:41.595614494 +0100
> +++ gcc/testsuite/g++.dg/cpp0x/constexpr-79822.C2017-03-03 
> 12:50:51.753673495 +0100
> @@ -0,0 +1,12 @@
> +// PR c++/79822
> +// { dg-do compile }
> +// { dg-options "" }
> +
> +bool
> +foo ()
> +{
> +  bool a = ({ }) && false; // { dg-error "could not convert" }
> +  bool b = ({ ; }) && false;   // { dg-error "could not convert" }
> +  bool c = ({ (void) 1; }) && false;   // { dg-error "could not convert" }
> +  return a && b && c;
> +}
>
> Jakub

Re: C++ PATCH for C++17 class template argument deduction issues

[Jason Merrill]

On Thu, Mar 2, 2017 at 3:26 PM, Jason Merrill  wrote:
> On Wed, Mar 1, 2017 at 3:58 PM, Jason Merrill  wrote:
>> On Tue, Feb 28, 2017 at 1:56 PM, Jason Merrill  wrote:
>>> This patch implements some proposed resolutions to open issues with
>>> C++17 class template argument deduction.
>
> This patch handles the issues of references to members of the class
> template differently, by also allowing explicit guides to refer to
> them:

The committee didn't like this direction, so I'm reverting it.
commit 522ce181ad77238b7e314377bf21f45579e7b6e8
Author: Jason Merrill 
Date:   Sat Mar 4 13:18:47 2017 -1000

Revert "Allow deduction guides to look into primary template."

* cp-tree.h, parser.c, pt.c, search.c: Revert.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 7583672..68f2722 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1272,7 +1272,6 @@ struct GTY(()) saved_scope {
   vec *lang_base;
   tree lang_name;
   tree template_parms;
-  tree deduction_guide_type;
   cp_binding_level *x_previous_class_level;
   tree x_saved_tree;
 
@@ -5423,9 +5422,6 @@ struct cp_decl_specifier_seq {
   BOOL_BITFIELD gnu_thread_keyword_p : 1;
   /* True iff the type is a decltype.  */
   BOOL_BITFIELD decltype_p : 1;
-  /* True iff the declaration declares a constructor or C++17 deduction
- guide.  */
-  BOOL_BITFIELD constructor_p : 1;
 };
 
 /* The various kinds of declarators.  */
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index fbe864f..e684870 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13313,8 +13313,6 @@ cp_parser_decl_specifier_seq (cp_parser* parser,
   && constructor_possible_p
   && (cp_parser_constructor_declarator_p
   (parser, decl_spec_seq_has_spec_p (decl_specs, ds_friend;
-  if (constructor_p)
-   decl_specs->constructor_p = true;
 
   /* If we don't have a DECL_SPEC yet, then we must be looking at
 a type-specifier.  */
@@ -19012,7 +19010,7 @@ cp_parser_init_declarator (cp_parser* parser,
   enum cpp_ttype initialization_kind;
   bool is_direct_init = false;
   bool is_non_constant_init;
-  int ctor_dtor_or_conv_p = decl_specifiers->constructor_p ? -1 : 0;
+  int ctor_dtor_or_conv_p;
   bool friend_p = cp_parser_friend_p (decl_specifiers);
   tree pushed_scope = NULL_TREE;
   bool range_for_decl_p = false;
@@ -19050,9 +19048,6 @@ cp_parser_init_declarator (cp_parser* parser,
 
   parser->default_arg_ok_p = saved_default_arg_ok_p;
 
-  if (cxx_dialect >= cxx1z)
-scope_chain->deduction_guide_type = NULL_TREE;
-
   /* If the DECLARATOR was erroneous, there's no need to go
  further.  */
   if (declarator == cp_error_declarator)
@@ -19100,6 +19095,25 @@ cp_parser_init_declarator (cp_parser* parser,
 
   if (function_declarator_p (declarator))
 {
+  /* Handle C++17 deduction guides.  */
+  if (!decl_specifiers->type
+ && ctor_dtor_or_conv_p <= 0
+ && cxx_dialect >= cxx1z)
+   {
+ cp_declarator *id = get_id_declarator (declarator);
+ tree name = id->u.id.unqualified_name;
+ parser->scope = id->u.id.qualifying_scope;
+ tree tmpl = cp_parser_lookup_name_simple (parser, name, id->id_loc);
+ if (tmpl
+ && (DECL_CLASS_TEMPLATE_P (tmpl)
+ || DECL_TEMPLATE_TEMPLATE_PARM_P (tmpl)))
+   {
+ id->u.id.unqualified_name = dguide_name (tmpl);
+ id->u.id.sfk = sfk_deduction_guide;
+ ctor_dtor_or_conv_p = 1;
+   }
+   }
+
   /* Check to see if the token indicates the start of a
 function-definition.  */
   if (cp_parser_token_starts_function_definition_p (token))
@@ -19418,10 +19432,8 @@ cp_parser_init_declarator (cp_parser* parser,
 
If CTOR_DTOR_OR_CONV_P is not NULL, *CTOR_DTOR_OR_CONV_P is used to
detect constructors, destructors, deduction guides, or conversion operators.
-   The caller should set it before the call, to -1 if parsing the
-   decl-specifier-seq determined that we're declaring a constructor or
-   deduction guide, or 0 otherwise.  This function sets it to -1 if the
-   declarator is a name, and +1 if it is a function. Usually you just want to
+   It is set to -1 if the declarator is a name, and +1 if it is a
+   function. Otherwise it is set to zero. Usually you just want to
test for >0, but internally the negative value is used.
 
(The reason for CTOR_DTOR_OR_CONV_P is that a declaration must have
@@ -19452,6 +19464,11 @@ cp_parser_declarator (cp_parser* parser,
   tree class_type;
   tree gnu_attributes = NULL_TREE, std_attributes = NULL_TREE;
 
+  /* Assume this is not a constructor, destructor, or type-conversion
+ operator.  */
+  if (ctor_dtor_or_conv_p)
+*ctor_dtor_or_conv_p = 0;
+
   if (cp_parser_allow_gnu_extensions_p (parser))
 gnu_attributes = cp_parser_gnu_attributes_opt (parser);
 
@@ -19749,6 +19766,9 @@ cp_parser_direct_declarator (cp_parser* parser,
  /* Parse an array-dec

[PATCH,testsuite] Add check_effective_target_rdynamic and use it in g++.dg/lto/pr69589_0.C.

[Toma Tabacu]

Hi,

g++.dg/lto/pr69589_0.C is currently failing for mips-mti-elf with the following 
error:

xg++: error: unrecognized command line option '-rdynamic'

However, it passes just fine for mips-mti-linux-gnu.
I think that we should skip this test for mips-mti-elf.

This patch achieves this by adding support for check_effective_target_rdynamic
and then using it in g++.dg/lto/pr69589_0.C.

This patch also removes the existing dg-skip-if, as it is made redundant by the
effective target check. The latter is also more convenient, as we won't have to
keep tweaking the dg-skip-if for failing targets anymore.

This is similar to my recent check_effective_target_gettimeofday patch,
which was greatly improved by Rainer Orth's review.

Tested with mips-mti-elf and mips-mti-linux-gnu.

Does this look good ?

Regards,
Toma

gcc/
* doc/sourcebuild.texi (Effective-Target Keywords, Other attributes):
Document rdynamic.

gcc/testsuite/

* g++.dg/lto/pr69589_0.C: Add dg-require-effective-target for
rdynamic.  Remove dg-skip-if for targets which don't support -rdynamic.
* lib/target-supports.exp (check_effective_target_rdynamic):
New proc.

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 0dc4348..d75e078 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2065,6 +2065,9 @@ Target supports @option{-mpe-aligned-commons}.
 @item pie
 Target supports @option{-pie}, @option{-fpie} and @option{-fPIE}.
 
+@item rdynamic
+Target supports @option{-rdynamic}.
+
 @item section_anchors
 Target supports section anchors.
 
diff --git a/gcc/testsuite/g++.dg/lto/pr69589_0.C 
b/gcc/testsuite/g++.dg/lto/pr69589_0.C
index 11766f1..599d5d4 100644
--- a/gcc/testsuite/g++.dg/lto/pr69589_0.C
+++ b/gcc/testsuite/g++.dg/lto/pr69589_0.C
@@ -1,7 +1,7 @@
 // { dg-lto-do link }
 // { dg-lto-options "-O2 -rdynamic" }
 // { dg-extra-ld-options "-r -nostdlib" }
-// { dg-skip-if "Skip targets without -rdynamic support" { arm*-none-eabi 
aarch64*-*-elf nios2-*-elf } { "*" } { "" } }
+// { dg-require-effective-target rdynamic }
 
 #pragma GCC visibility push(hidden)
 struct A { int &operator[] (long); };
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 2766af4..f46f0ba 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1484,6 +1484,16 @@ proc check_effective_target_static_libgfortran { } {
 } "-static"]
 }
 
+# Return 1 if we can use the -rdynamic option, 0 otherwise.
+#
+# When the target name changes, replace the cached result.
+
+proc check_effective_target_rdynamic { } {
+  return [check_no_compiler_messages rdynamic executable {
+ int main() { return 0; }
+  } "-rdynamic"]
+}
+
 # Return 1 if cilk-plus is supported by the target, 0 otherwise.
  
 proc check_effective_target_cilkplus { } {

[PATCH] Use array_at_struct_end_p in tree-chkp.c (PR middle-end/68270).

[Martin Liška]

Hello.

As mentioned by Richard ([1]), the function should be used instead of
DECL_CHAIN(..) checking.

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

Ready to be installed?
Martin


[1] https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00172.html
>From 617a2c5dea8895be593ba0ac68e0b6d038943af3 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 3 Mar 2017 14:22:23 +0100
Subject: [PATCH] Use array_at_struct_end_p in tree-chkp.c (PR
 middle-end/68270).

gcc/ChangeLog:

2017-03-03  Martin Liska  

	PR middle-end/68270
	* tree-chkp.c (chkp_may_narrow_to_field): Add new argument ref.
	Use array_at_struct_end_p instead of DECL_CHAIN (field).
	(chkp_narrow_bounds_for_field): Likewise.
	(chkp_parse_array_and_component_ref): Pass one more argument to
	call.

gcc/testsuite/ChangeLog:

2017-03-03  Martin Liska  

	PR middle-end/68270
	* g++.dg/pr68270.C: New test.
---
 gcc/testsuite/g++.dg/pr68270.C | 16 
 gcc/tree-chkp.c| 20 +++-
 2 files changed, 27 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr68270.C

diff --git a/gcc/testsuite/g++.dg/pr68270.C b/gcc/testsuite/g++.dg/pr68270.C
new file mode 100644
index 000..441fca3e85f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr68270.C
@@ -0,0 +1,16 @@
+/* PR71633 */
+/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && { ! x32 } } } } */
+/* { dg-options "-Werror=chkp -mmpx -fcheck-pointer-bounds -O1 -fchkp-flexible-struct-trailing-arrays" } */
+
+struct a
+{
+  struct
+  {
+int e[1];
+  } f;
+};
+
+int g(a *ptr)
+{
+  return ptr->f.e[1];
+}
diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
index 02ae2d2d2c7..b7b412efcef 100644
--- a/gcc/tree-chkp.c
+++ b/gcc/tree-chkp.c
@@ -3266,15 +3266,15 @@ chkp_intersect_bounds (tree bounds1, tree bounds2, gimple_stmt_iterator *iter)
 }
 
 /* Return 1 if we are allowed to narrow bounds for addressed FIELD
-   and 0 othersize.  */
+   and 0 othersize.  REF is reference to the field.  */
+
 static bool
-chkp_may_narrow_to_field (tree field)
+chkp_may_narrow_to_field (tree ref, tree field)
 {
   return DECL_SIZE (field) && TREE_CODE (DECL_SIZE (field)) == INTEGER_CST
 && tree_to_uhwi (DECL_SIZE (field)) != 0
 && !(flag_chkp_flexible_struct_trailing_arrays
-	 && TREE_CODE(TREE_TYPE(field)) == ARRAY_TYPE
-	 && !DECL_CHAIN (field))
+	 && array_at_struct_end_p (ref, true))
 && (!DECL_FIELD_OFFSET (field)
 	|| TREE_CODE (DECL_FIELD_OFFSET (field)) == INTEGER_CST)
 && (!DECL_FIELD_BIT_OFFSET (field)
@@ -3284,14 +3284,15 @@ chkp_may_narrow_to_field (tree field)
 }
 
 /* Return 1 if bounds for FIELD should be narrowed to
-   field's own size.  */
+   field's own size.  REF is reference to the field.  */
+
 static bool
-chkp_narrow_bounds_for_field (tree field)
+chkp_narrow_bounds_for_field (tree ref, tree field)
 {
   HOST_WIDE_INT offs;
   HOST_WIDE_INT bit_offs;
 
-  if (!chkp_may_narrow_to_field (field))
+  if (!chkp_may_narrow_to_field (ref, field))
 return false;
 
   /* Accesse to compiler generated fields should not cause
@@ -3428,7 +3429,8 @@ chkp_parse_array_and_component_ref (tree node, tree *ptr,
 	  if (flag_chkp_narrow_bounds
 	  && !flag_chkp_narrow_to_innermost_arrray
 	  && (!last_comp
-		  || chkp_may_narrow_to_field (TREE_OPERAND (last_comp, 1
+		  || chkp_may_narrow_to_field (var,
+	   TREE_OPERAND (last_comp, 1
 	{
 	  comp_to_narrow = last_comp;
 	  break;
@@ -3440,7 +3442,7 @@ chkp_parse_array_and_component_ref (tree node, tree *ptr,
 
 	  if (innermost_bounds
 	  && !array_ref_found
-	  && chkp_narrow_bounds_for_field (field))
+	  && chkp_narrow_bounds_for_field (var, field))
 	comp_to_narrow = var;
 	  last_comp = var;
 
-- 
2.11.1

RE: [PATCH,testsuite] Skip gcc.dg/lto/pr60449_0.c for mips*-*-elf* targets.

[Toma Tabacu]

> From: Catherine Moore
> 
> This patch fixes my original objection.  Thanks.
> 

Committed as r245921.

Thanks,
Toma

Re: [RFC] VEC_SELECT sanity checking in genrecog (arm, aarch64, mips)

[Jakub Jelinek]

On Mon, Mar 06, 2017 at 12:27:31PM +, Matthew Fortune wrote:
> Jakub Jelinek  writes:
> > >
> > > ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2
> > > elements, expected 4
> > > ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2
> > > elements, expected 4
> 
> Thanks for reporting. These were actually in progress already but without
> a PR (I believe these are the same ones as shown above). Patch was
> approved earlier today:
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00229.html

Nice.  So just arm, aarch64 and rs6000 to go.

Jakub

Re: [PATCH] S/390: Disable vectorization for loops with few iterations

[Andreas Krebbel]

> gcc/ChangeLog:
> 
> 2017-03-02  Robin Dapp  
> 
>   * config/s390/s390.c (s390_option_override_internal): Set
>   PARAM_MIN_VECT_LOOP_BOUND

Applied. Thanks!

-Andreas-

Re: [PATCH] S/390: Change 2-byte NOPs

[Andreas Krebbel]

> gcc/ChangeLog:
> 
> 2017-03-02  Robin Dapp  
> 
>   * config/s390/s390.c (s390_asm_output_function_label): Use nopr %r0.
>   * config/s390/s390.md: Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> 2017-03-02  Robin Dapp  
> 
>   * gcc.target/s390/hotpatch-1.c: Check for nopr %r0.
>   * gcc.target/s390/hotpatch-10.c: Likewise.
>   * gcc.target/s390/hotpatch-11.c: Likewise.
>   * gcc.target/s390/hotpatch-12.c: Likewise.
>   * gcc.target/s390/hotpatch-13.c: Likewise.
>   * gcc.target/s390/hotpatch-14.c: Likewise.
>   * gcc.target/s390/hotpatch-15.c: Likewise.
>   * gcc.target/s390/hotpatch-16.c: Likewise.
>   * gcc.target/s390/hotpatch-17.c: Likewise.
>   * gcc.target/s390/hotpatch-18.c: Likewise.
>   * gcc.target/s390/hotpatch-19.c: Likewise.
>   * gcc.target/s390/hotpatch-2.c: Likewise.
>   * gcc.target/s390/hotpatch-26.c: Likewise.
>   * gcc.target/s390/hotpatch-27.c: Likewise.
>   * gcc.target/s390/hotpatch-28.c: Likewise.
>   * gcc.target/s390/hotpatch-3.c: Likewise.
>   * gcc.target/s390/hotpatch-4.c: Likewise.
>   * gcc.target/s390/hotpatch-5.c: Likewise.
>   * gcc.target/s390/hotpatch-6.c: Likewise.
>   * gcc.target/s390/hotpatch-7.c: Likewise.
>   * gcc.target/s390/hotpatch-8.c: Likewise.
>   * gcc.target/s390/hotpatch-9.c: Likewise.

Applied. Thanks!

-Andreas-

RE: [RFC] VEC_SELECT sanity checking in genrecog (arm, aarch64, mips)

[Matthew Fortune]

Jakub Jelinek  writes:
> >
> > ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2
> > elements, expected 4
> > ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2
> > elements, expected 4

Thanks for reporting. These were actually in progress already but without
a PR (I believe these are the same ones as shown above). Patch was
approved earlier today:

https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00229.html

Thanks,
Matthew

RE: [PR79793] Fixes interrupt stack alignment

[Koval, Julia]

Uhhh, copypaste error, sorry.

PR target/79793
gcc/
* config/i386/i386.c (ix86_minimum_incoming_stack_boundary): Set 
incoming
stack boundary to 128 for 64-bit targets.

gcc/testsuite/
* gcc.target/i386/interrupt-12.c: Update scan-assembler-times 
directives.
* gcc.target/i386/interrupt-13.c: Ditto. 
* gcc.target/i386/interrupt-14.c: Ditto. 
* gcc.target/i386/interrupt-15.c: Ditto.


-Original Message-
From: Koval, Julia 
Sent: Monday, March 06, 2017 1:03 PM
To: 'Uros Bizjak' 
Cc: GCC Patches ; H.J. Lu 
Subject: RE: [PR79793] Fixes interrupt stack alignment

Ok, fixed it. Can you please commit it for me?

PR target/79731
gcc/
* config/i386/i386.c (ix86_minimum_incoming_stack_boundary): Set 
incoming
stack boundary to 128 for 64-bit targets.

gcc/testsuite/
* gcc.target/i386/interrupt-12.c: Update scan-assembler-times 
directives.
* gcc.target/i386/interrupt-13.c: Ditto. 
* gcc.target/i386/interrupt-14.c: Ditto. 
* gcc.target/i386/interrupt-15.c: Ditto.

Thanks,
Julia

-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com] 
Sent: Friday, March 03, 2017 4:29 PM
To: Koval, Julia 
Cc: GCC Patches ; H.J. Lu 
Subject: Re: [PR79793] Fixes interrupt stack alignment

On Fri, Mar 3, 2017 at 4:20 PM, Koval, Julia  wrote:
> Hi,
> This patch fixes PR79731. Ok for trunk?
>
> gcc/
> * config/i386/i386.c (ix86_minimum_incoming_stack_boundary): Fix 
> boundary for interrupt

...: Set incoming stack boundary to 128 for 64-bit targets.

> gcc/testsuite/
> * gcc.target/i386/interrupt-12.c: Fix test.
> * gcc.target/i386/interrupt-13.c: Ditto.
> * gcc.target/i386/interrupt-14.c: Ditto.
> * gcc.target/i386/interrupt-15.c: Ditto.

...: Update scan-assembler-times directives.

Please also add "PR target/79731" to the top of ChangeLog entry.

OK with the above ChangeLog changes.

Thanks,
Uros.

[PATCH] Fix PR79887

[Richard Biener]

This fixes a crash when we try to re-use a folded loop_vectorized_call
when vectorizing an epilogue.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2017-03-06  Richard Biener  

PR tree-optimization/79894
* tree-vectorizer.c (vectorize_loops): Set loop_vectorized_call
to NULL after folding it.

* gcc.dg/vect/pr79887.c: New testcase.

Index: gcc/tree-vectorizer.c
===
--- gcc/tree-vectorizer.c   (revision 245908)
+++ gcc/tree-vectorizer.c   (working copy)
@@ -651,6 +651,7 @@ vectorize_loops (void)
 "basic block vectorized\n");
fold_loop_vectorized_call (loop_vectorized_call,
   boolean_true_node);
+   loop_vectorized_call = NULL;
ret |= TODO_cleanup_cfg;
  }
  }
@@ -703,6 +704,7 @@ vectorize_loops (void)
if (loop_vectorized_call)
  {
fold_loop_vectorized_call (loop_vectorized_call, boolean_true_node);
+   loop_vectorized_call = NULL;
ret |= TODO_cleanup_cfg;
  }
 
Index: gcc/testsuite/gcc.dg/vect/pr79887.c
===
--- gcc/testsuite/gcc.dg/vect/pr79887.c (nonexistent)
+++ gcc/testsuite/gcc.dg/vect/pr79887.c (working copy)
@@ -0,0 +1,14 @@
+/* Test for pr79887.  */
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_condition } */
+/* { dg-additional-options "-fno-trapping-math --param 
vect-epilogues-nomask=1" } */
+/* { dg-additional-options "-mavx512ifma" { target x86_64-*-* i?86-*-* } } */
+
+void
+foo (float a[32], float b[2][32])
+{
+  int i;
+  for (i = 0; i < 32; i++)
+a[i] = (b[0][i] > b[1][i]) ? b[0][i] : b[1][i];
+}
+

[PATCH] Fix PR79824

[Richard Biener]

The following fixes too aggressive disabling of peeling for gaps for
interleaving and load-lanes (as well as fixing the test so it applies
for multi-element as well).

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2017-03-06  Richard Biener  

PR tree-optimization/79824
* tree-vect-stmts.c (get_group_load_store_type): Fix alignment
check disabling peeling for gaps.

* gcc.dg/vect/pr79824-1.c: New testcase.
* gcc.dg/vect/pr79824-2.c: Likewise.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 245908)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -1731,7 +1731,7 @@ get_group_load_store_type (gimple *stmt,
   bool single_element_p = (stmt == first_stmt
   && !GROUP_NEXT_ELEMENT (stmt_info));
   unsigned HOST_WIDE_INT gap = GROUP_GAP (vinfo_for_stmt (first_stmt));
-  int nunits = TYPE_VECTOR_SUBPARTS (vectype);
+  unsigned nunits = TYPE_VECTOR_SUBPARTS (vectype);
 
   /* True if the vectorized statements would access beyond the last
  statement in the group.  */
@@ -1794,9 +1794,13 @@ get_group_load_store_type (gimple *stmt,
   /* If there is a gap at the end of the group then these optimizations
 would access excess elements in the last iteration.  */
   bool would_overrun_p = (gap != 0);
-  /* If the access is aligned an overrun is fine.  */
+  /* If the access is aligned an overrun is fine, but only if the
+ overrun is not inside an unused vector (if the gap is as large
+or larger than a vector).  */
   if (would_overrun_p
- && aligned_access_p (STMT_VINFO_DATA_REF (stmt_info)))
+ && gap < nunits
+ && aligned_access_p
+   (STMT_VINFO_DATA_REF (vinfo_for_stmt (first_stmt
would_overrun_p = false;
   if (!STMT_VINFO_STRIDED_P (stmt_info)
  && (can_overrun_p || !would_overrun_p)
Index: gcc/testsuite/gcc.dg/vect/pr79824-1.c
===
--- gcc/testsuite/gcc.dg/vect/pr79824-1.c   (nonexistent)
+++ gcc/testsuite/gcc.dg/vect/pr79824-1.c   (working copy)
@@ -0,0 +1,46 @@
+/* { dg-require-effective-target mmap } */
+
+#include 
+#include 
+#include "tree-vect.h"
+
+#define COUNT 320
+#define MMAP_SIZE 0x1
+#define ADDRESS 0x112200
+#define TYPE double
+
+#ifndef MAP_ANONYMOUS
+#define MAP_ANONYMOUS MAP_ANON
+#endif
+
+void __attribute__((noinline))
+foo (TYPE *__restrict a, TYPE *__restrict b)
+{
+  int n;
+
+  b = __builtin_assume_aligned (b, sizeof (TYPE) * 2);
+  a = __builtin_assume_aligned (a, sizeof (TYPE) * 2);
+  for (n = 0; n < COUNT; n++)
+a[n] = b[n * 4];
+}
+
+int
+main (void)
+{
+  void *x;
+  size_t b_offset;
+
+  check_vect ();
+
+  x = mmap ((void *) ADDRESS, MMAP_SIZE, PROT_READ | PROT_WRITE,
+   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+  if (x == MAP_FAILED)
+{
+  perror ("mmap");
+  return 1;
+}
+
+  b_offset = MMAP_SIZE - (4 * COUNT - 2) * sizeof (TYPE);
+  foo ((TYPE *) x, (TYPE *) ((char *) x + b_offset));
+  return 0;
+}
Index: gcc/testsuite/gcc.dg/vect/pr79824-2.c
===
--- gcc/testsuite/gcc.dg/vect/pr79824-2.c   (nonexistent)
+++ gcc/testsuite/gcc.dg/vect/pr79824-2.c   (working copy)
@@ -0,0 +1,48 @@
+/* { dg-require-effective-target mmap } */
+
+#include 
+#include 
+#include "tree-vect.h"
+
+#define COUNT 320
+#define MMAP_SIZE 0x1
+#define ADDRESS 0x112200
+#define TYPE double
+
+#ifndef MAP_ANONYMOUS
+#define MAP_ANONYMOUS MAP_ANON
+#endif
+
+void __attribute__((noinline))
+foo (TYPE *__restrict a, TYPE *__restrict b)
+{
+  int n;
+
+  b = __builtin_assume_aligned (b, sizeof (TYPE) * 2);
+  a = __builtin_assume_aligned (a, sizeof (TYPE) * 2);
+  for (n = 0; n < COUNT; n++)
+{
+  a[n] = b[n * 4] + b[n * 4 + 1];
+}
+}
+
+int
+main (void)
+{
+  void *x;
+  size_t b_offset;
+
+  check_vect ();
+
+  x = mmap ((void *) ADDRESS, MMAP_SIZE, PROT_READ | PROT_WRITE,
+   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+  if (x == MAP_FAILED)
+{
+  perror ("mmap");
+  return 1;
+}
+
+  b_offset = MMAP_SIZE - (4 * COUNT - 2) * sizeof (TYPE);
+  foo ((TYPE *) x, (TYPE *) ((char *) x + b_offset));
+  return 0;
+}

Re: [PATCH] Fix PR79894

[Thomas Koenig]

Am 06.03.2017 um 13:01 schrieb Richard Biener:


The Fortran FE creates non-1:1 type compatible complex-expr /
realpart-expr in this case and thus like other FEs it can't expect
fold to end up with 1:1 type compatible results.

Testing on x86_64-unknown-linux-gnu in progress.

Ok for trunk?


Ok.

Thanks for the patch!

Regards

Thomas

Re: [RFC] VEC_SELECT sanity checking in genrecog (arm, aarch64, mips)

[Ramana Radhakrishnan]

On Mon, Mar 6, 2017 at 11:48 AM, Jakub Jelinek  wrote:
> Hi!
>
> CCing also arm, aarch64 and mips maintainers on the issues in their
> backends.  It is likely if such VEC_SELECTs are visible to simplify-rtx.c,
> it would ICE on them.

Kyrill, could you take a look at ARM and AArch64 ? I'm still in the
middle of travels.

Ramana
>
> On Fri, Mar 03, 2017 at 05:28:27PM +0100, Jakub Jelinek wrote:
>> ../../gcc/config/aarch64/aarch64-simd.md:79:1: DImode of first vec_select 
>> operand is not a vector mode
>> ../../gcc/config/aarch64/aarch64-simd.md:79:1: DFmode of first vec_select 
>> operand is not a vector mode
>> ../../gcc/config/aarch64/aarch64-simd.md:588:1: DImode of first vec_select 
>> operand is not a vector mode
>> ../../gcc/config/aarch64/aarch64-simd.md:588:1: DFmode of first vec_select 
>> operand is not a vector mode
>> ../../gcc/config/aarch64/aarch64-simd.md:3192:1: DFmode of first vec_select 
>> operand is not a vector mode
>>
>> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between 
>> vec_select HImode and its operand QImode
>> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between 
>> vec_select SImode and its operand QImode
>> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between 
>> vec_select QImode and its operand HImode
>> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between 
>> vec_select SImode and its operand HImode
>> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between 
>> vec_select QImode and its operand SImode
>> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between 
>> vec_select HImode and its operand SImode
>> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between 
>> vec_select HImode and its operand QImode
>> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between 
>> vec_select SImode and its operand QImode
>> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between 
>> vec_select QImode and its operand HImode
>> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between 
>> vec_select SImode and its operand HImode
>> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between 
>> vec_select QImode and its operand SImode
>> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between 
>> vec_select HImode and its operand SImode
>> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between 
>> vec_select HImode and its operand QImode
>> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between 
>> vec_select SImode and its operand QImode
>> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between 
>> vec_select QImode and its operand HImode
>> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between 
>> vec_select SImode and its operand HImode
>> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between 
>> vec_select QImode and its operand SImode
>> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between 
>> vec_select HImode and its operand SImode
>> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between 
>> vec_select HImode and its operand QImode
>> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between 
>> vec_select SImode and its operand QImode
>> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between 
>> vec_select QImode and its operand HImode
>> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between 
>> vec_select SImode and its operand HImode
>> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between 
>> vec_select QImode and its operand SImode
>> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between 
>> vec_select HImode and its operand SImode
>>
>> ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 
>> elements, expected 4
>> ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 
>> elements, expected 4
>>
>> 2017-03-03  Jakub Jelinek  
>>
>>   * genrecog.c (validate_pattern): Add VEC_SELECT validation.
>>   * g

Re: [RFC] VEC_SELECT sanity checking in genrecog (arm, aarch64, mips)

[Kyrill Tkachov]

Hi Jakub,

On 06/03/17 11:48, Jakub Jelinek wrote:

Hi!

CCing also arm, aarch64 and mips maintainers on the issues in their
backends.  It is likely if such VEC_SELECTs are visible to simplify-rtx.c,
it would ICE on them.

On Fri, Mar 03, 2017 at 05:28:27PM +0100, Jakub Jelinek wrote:

../../gcc/config/aarch64/aarch64-simd.md:79:1: DImode of first vec_select 
operand is not a vector mode
../../gcc/config/aarch64/aarch64-simd.md:79:1: DFmode of first vec_select 
operand is not a vector mode
../../gcc/config/aarch64/aarch64-simd.md:588:1: DImode of first vec_select 
operand is not a vector mode
../../gcc/config/aarch64/aarch64-simd.md:588:1: DFmode of first vec_select 
operand is not a vector mode
../../gcc/config/aarch64/aarch64-simd.md:3192:1: DFmode of first vec_select 
operand is not a vector mode

../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
HImode and its operand QImode
../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
SImode and its operand QImode
../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
QImode and its operand HImode
../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
SImode and its operand HImode
../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
QImode and its operand SImode
../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
HImode and its operand SImode
../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
HImode and its operand QImode
../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
SImode and its operand QImode
../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
QImode and its operand HImode
../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
SImode and its operand HImode
../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
QImode and its operand SImode
../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
HImode and its operand SImode
../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
HImode and its operand QImode
../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
SImode and its operand QImode
../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
QImode and its operand HImode
../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
SImode and its operand HImode
../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
QImode and its operand SImode
../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
HImode and its operand SImode
../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
HImode and its operand QImode
../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
SImode and its operand QImode
../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
QImode and its operand HImode
../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
SImode and its operand HImode
../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
QImode and its operand SImode
../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
HImode and its operand SImode


Could you file a PR for these please?
I think I see the issue with some of the NEON patterns (using VW and VQI 
iterators simultaneously I think)
but it'd take some time to do the testing for the fixes properly.

Thanks,
Kyrill


../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 elements, 
expected 4
../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 elements, 
expected 4

2017-03-03  Jakub Jelinek  

* genrecog.c (validate_pattern): Add VEC_SELECT validation.
* genmodes.c (emit_min_insn_modes_c): Call emit_mode_nunits
and emit_mode_inner.

Jakub

RE: [PR79793] Fixes interrupt stack alignment

[Koval, Julia]

Ok, fixed it. Can you please commit it for me?

PR target/79731
gcc/
* config/i386/i386.c (ix86_minimum_incoming_stack_boundary): Set 
incoming
stack boundary to 128 for 64-bit targets.

gcc/testsuite/
* gcc.target/i386/interrupt-12.c: Update scan-assembler-times 
directives.
* gcc.target/i386/interrupt-13.c: Ditto. 
* gcc.target/i386/interrupt-14.c: Ditto. 
* gcc.target/i386/interrupt-15.c: Ditto.

Thanks,
Julia

-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com] 
Sent: Friday, March 03, 2017 4:29 PM
To: Koval, Julia 
Cc: GCC Patches ; H.J. Lu 
Subject: Re: [PR79793] Fixes interrupt stack alignment

On Fri, Mar 3, 2017 at 4:20 PM, Koval, Julia  wrote:
> Hi,
> This patch fixes PR79731. Ok for trunk?
>
> gcc/
> * config/i386/i386.c (ix86_minimum_incoming_stack_boundary): Fix 
> boundary for interrupt

...: Set incoming stack boundary to 128 for 64-bit targets.

> gcc/testsuite/
> * gcc.target/i386/interrupt-12.c: Fix test.
> * gcc.target/i386/interrupt-13.c: Ditto.
> * gcc.target/i386/interrupt-14.c: Ditto.
> * gcc.target/i386/interrupt-15.c: Ditto.

...: Update scan-assembler-times directives.

Please also add "PR target/79731" to the top of ChangeLog entry.

OK with the above ChangeLog changes.

Thanks,
Uros.

[PATCH] Fix PR79894

[Richard Biener]

The Fortran FE creates non-1:1 type compatible complex-expr / 
realpart-expr in this case and thus like other FEs it can't expect
fold to end up with 1:1 type compatible results.

Testing on x86_64-unknown-linux-gnu in progress.

Ok for trunk?

Thanks,
Richard.

2017-03-06  Richard Biener  

PR fortran/79894
* trans.c (gfc_add_modify_loc): Weaken assert.

Index: gcc/fortran/trans.c
===
--- gcc/fortran/trans.c (revision 245913)
+++ gcc/fortran/trans.c (working copy)
@@ -151,11 +151,11 @@ gfc_add_modify_loc (location_t loc, stmt
   tree t1, t2;
   t1 = TREE_TYPE (rhs);
   t2 = TREE_TYPE (lhs);
-  /* Make sure that the types of the rhs and the lhs are the same
+  /* Make sure that the types of the rhs and the lhs are compatible
  for scalar assignments.  We should probably have something
  similar for aggregates, but right now removing that check just
  breaks everything.  */
-  gcc_checking_assert (t1 == t2
+  gcc_checking_assert (TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
   || AGGREGATE_TYPE_P (TREE_TYPE (lhs)));
 
   tmp = fold_build2_loc (loc, MODIFY_EXPR, void_type_node, lhs,

Re: [RFC] VEC_SELECT sanity checking in genrecog

[Richard Biener]

On Fri, 3 Mar 2017, Jakub Jelinek wrote:

> Hi!
> 
> When working on PR79812 which was caused by bugs in x86 define_insn
> (used vec_select with parallel as last operand with incorrect number of
> operands), I wrote following sanity checking.
> 
> The thing is that e.g. simplify-rtx.c already has such assertions:
>   if (!VECTOR_MODE_P (mode))
> {
>   gcc_assert (VECTOR_MODE_P (GET_MODE (trueop0)));
>   gcc_assert (mode == GET_MODE_INNER (GET_MODE (trueop0)));
>   gcc_assert (GET_CODE (trueop1) == PARALLEL);
>   gcc_assert (XVECLEN (trueop1, 0) == 1);
>   gcc_assert (CONST_INT_P (XVECEXP (trueop1, 0, 0)));
> ...
>   else
> {
>   gcc_assert (VECTOR_MODE_P (GET_MODE (trueop0)));
>   gcc_assert (GET_MODE_INNER (mode)
>   == GET_MODE_INNER (GET_MODE (trueop0)));
>   gcc_assert (GET_CODE (trueop1) == PARALLEL);
> 
>   if (GET_CODE (trueop0) == CONST_VECTOR)
> {
>   int elt_size = GET_MODE_UNIT_SIZE (mode);
>   unsigned n_elts = (GET_MODE_SIZE (mode) / elt_size);
>   rtvec v = rtvec_alloc (n_elts);
>   unsigned int i;
> 
>   gcc_assert (XVECLEN (trueop1, 0) == (int) n_elts);
> ...
> and documentation says:
> @findex vec_select
> @item (vec_select:@var{m} @var{vec1} @var{selection})
> This describes an operation that selects parts of a vector.  @var{vec1} is
> the source vector, and @var{selection} is a @code{parallel} that contains a
> @code{const_int} for each of the subparts of the result vector, giving the
> number of the source subpart that should be stored into it.
> The result mode @var{m} is either the submode for a single element of
> @var{vec1} (if only one subpart is selected), or another vector mode
> with that element submode (if multiple subparts are selected).
> 
> Unfortunately, even after fixing 2 x86 bugs with that, I'm seeing tons
> of issues on other targets (many others are ok though) below.  So, is the
> verification the right thing and are all these md bugs that should be fixed
> (and then the verification added)?  If not, I'd be afraid if people are
> unlucky and combiner constant propagates something or some other pass,
> we can ICE on those in simplify-rtx.c.  E.g. in vsx.md the thing is that
> the pattern uses an iterator with 2 V2?? modes in it and then V1TI mode,
> and uses exactly two elements in paralle, which doesn't make any sense
> for V1TI.
> 
> ../../gcc/config/rs6000/vsx.md:2063:1: vec_select parallel with 2 elements, 
> expected 1
> ../../gcc/config/rs6000/vsx.md:2112:1: vec_select parallel with 2 elements, 
> expected 1
> ../../gcc/config/rs6000/vsx.md:2161:1: vec_select parallel with 2 elements, 
> expected 1
> 
> ../../gcc/config/aarch64/aarch64-simd.md:79:1: DImode of first vec_select 
> operand is not a vector mode
> ../../gcc/config/aarch64/aarch64-simd.md:79:1: DFmode of first vec_select 
> operand is not a vector mode
> ../../gcc/config/aarch64/aarch64-simd.md:588:1: DImode of first vec_select 
> operand is not a vector mode
> ../../gcc/config/aarch64/aarch64-simd.md:588:1: DFmode of first vec_select 
> operand is not a vector mode
> ../../gcc/config/aarch64/aarch64-simd.md:3192:1: DFmode of first vec_select 
> operand is not a vector mode
> 
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> HImode and its operand SImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> HImode and its operand SImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
> HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
> SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between ve

Re: [RFC] VEC_SELECT sanity checking in genrecog (arm, aarch64, mips)

[Jakub Jelinek]

Hi!

CCing also arm, aarch64 and mips maintainers on the issues in their
backends.  It is likely if such VEC_SELECTs are visible to simplify-rtx.c,
it would ICE on them.

On Fri, Mar 03, 2017 at 05:28:27PM +0100, Jakub Jelinek wrote:
> ../../gcc/config/aarch64/aarch64-simd.md:79:1: DImode of first vec_select 
> operand is not a vector mode
> ../../gcc/config/aarch64/aarch64-simd.md:79:1: DFmode of first vec_select 
> operand is not a vector mode
> ../../gcc/config/aarch64/aarch64-simd.md:588:1: DImode of first vec_select 
> operand is not a vector mode
> ../../gcc/config/aarch64/aarch64-simd.md:588:1: DFmode of first vec_select 
> operand is not a vector mode
> ../../gcc/config/aarch64/aarch64-simd.md:3192:1: DFmode of first vec_select 
> operand is not a vector mode
> 
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select 
> HImode and its operand SImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select 
> HImode and its operand SImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
> HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
> SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
> QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
> SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
> QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select 
> HImode and its operand SImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
> HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
> SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
> QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
> SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
> QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select 
> HImode and its operand SImode
> 
> ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 
> elements, expected 4
> ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 
> elements, expected 4
> 
> 2017-03-03  Jakub Jelinek  
> 
>   * genrecog.c (validate_pattern): Add VEC_SELECT validation.
>   * genmodes.c (emit_min_insn_modes_c): Call emit_mode_nunits
>   and emit_mode_inner.

Jakub

RE: [PATCH,testsuite] MIPS: Force O32 ABI for inline-memcpy-3.c.

[Toma Tabacu]

> From: Matthew Fortune
> 
> Toma Tabacu writes:
> > gcc/testsuite/
> >
> > * gcc.target/mips/inline-memcpy-3.c (dg-options): Add -mabi=32.
> 
> OK, thanks. Sorry for the slow reply.
> 
> Matthew

Committed as r245914.

Thanks,
Toma

Re: [PATCH v4] aarch64: Add split-stack initial support

[Adhemerval Zanella]

Ping.

On 15/02/2017 21:23, Adhemerval Zanella wrote:
> This is an update patch from my previous version (v3) based mainly on
> glibc comments on exported loader symbol [1].  The changes from previous
> version are:
> 
>- Remove __tcb_private_ss call on libgcc and emit a data usage on
>  glibc symbol when split-stack is used.  This removes the runtime
>  errors when running on older glibc and instead make the loader
>  fails with a missing symbol.
> 
>- Add glibc version check on split-stack support check.
> 
>- Some comments fixes on morestack.S.
> 
>- Remove some compile warnings on morestack-c.c.
> 
> --
> 
> This patch adds the split-stack support on aarch64 (PR #67877).  As for
> other ports this patch should be used along with glibc and gold support.
> 
> The support is done similar to other architectures: a split-stack field
> is allocated before TCB by glibc, a target-specific __morestack implementation
> and helper functions are added in libgcc and compiler supported in adjusted
> (split-stack prologue, va_start for argument handling).  I also plan to
> send the gold support to adjust stack allocation acrosss split-stack
> and default code calls.
> 
> Current approach is to set the final stack adjustments using a 2 instructions
> at most (mov/movk) which limits stack allocation to upper limit of 4GB.
> The morestack call is non standard with x10 hollding the requested stack
> pointer, x11 the argument pointer (if required), and x12 to return
> continuation address.  Unwinding is handled by a personality routine that
> knows how to find stack segments.
> 
> Split-stack prologue on function entry is as follow (this goes before the
> usual function prologue):
> 
> function:
>   mrsx9, tpidr_el0
>   movx10, 
>   movk   x10, #0x0, lsl #16
>   subx10, sp, x10
>   movx11, sp  # if function has stacked arguments
>   adrp   x12, main_fn_entry
>   addx12, x12, :lo12:.L2
>   cmpx9, x10
>   b.lt   
>   b  __morestack
> main_fn_entry:
>   [function prologue]
> 
> Notes:
> 
> 1. Even if a function does not allocate a stack frame, a split-stack prologue
>is created.  It is to avoid issues with tail call for external symbols
>which might require linker adjustment (libgo/runtime/go-varargs.c).
> 
> 2. Basic-block reordering (enabled with -O2) will move split-stack TCB ldr
>to after the required stack calculation.
> 
> 3. Similar to powerpc, When the linker detects a call from split-stack to
>non-split-stack code, it adds 16k (or more) to the value found in 
> "allocate"
>instructions (so non-split-stack code gets a larger stack).  The amount is
>tunable by a linker option.  The edit means aarch64 does not need to
>implement __morestack_non_split, necessary on x86 because insufficient
>space is available there to edit the stack comparison code.  This feature
>is only implemented in the GNU gold linker.
> 
> 4. AArch64 does not handle >4G stack initially and although it is possible
>to implement it, limiting to 4G allows to materize the allocation with
>only 2 instructions (mov + movk) and thus simplifying the linker
>adjustments required.  Supporting multiple threads each requiring more
>than 4G of stack is probably not that important, and likely to OOM at
>run time.
> 
> 5. The TCB support on GLIBC is meant to be included in version 2.26.
> 
> 6. The continuation address materialized on x12 is done using 'adrp'
>plus add and a static relocation.  Current code uses the
>aarch64_expand_mov_immediate function and since a better alternative
>would be 'adp', it could be a future optimization (not implemented
>in this patch).
> 
> [1] https://sourceware.org/ml/libc-alpha/2017-02/msg00272.html
> 
> libgcc/ChangeLog:
> 
>   * libgcc/config.host: Use t-stack and t-statck-aarch64 for
>   aarch64*-*-linux.
>   * libgcc/config/aarch64/morestack-c.c: New file.
>   * libgcc/config/aarch64/morestack.S: Likewise.
>   * libgcc/config/aarch64/t-stack-aarch64: Likewise.
>   * libgcc/generic-morestack.c (__splitstack_find): Add aarch64-specific
>   code.
> 
> gcc/ChangeLog:
> 
>   * common/config/aarch64/aarch64-common.c
>   (aarch64_supports_split_stack): New function.
>   (TARGET_SUPPORTS_SPLIT_STACK): New macro.
>   * gcc/config/aarch64/aarch64-linux.h (TARGET_ASM_FILE_END): Remove
>   macro.
>   * gcc/config/aarch64/aarch64-protos.h: Add
>   aarch64_expand_split_stack_prologue and
>   aarch64_split_stack_space_check.
>   * gcc/config/aarch64/aarch64.c (aarch64_gen_far_branch): Add suport
>   to emit 'b' instruction to rtx different than LABEL_REF.
>   (aarch64_expand_builtin_va_start): Use internal argument pointer
>   instead of virtual_incoming_args_rtx.
>   (morestack_ref): New symbol.
>   (aarch64_load_split_stack_value): New function.
>   (aarch64_expand_split_s

RE: [PATCH,testsuite] MIPS: Force O32 ABI for inline-memcpy-3.c.

[Matthew Fortune]

Toma Tabacu  writes:
> gcc/testsuite/
> 
>   * gcc.target/mips/inline-memcpy-3.c (dg-options): Add -mabi=32.

OK, thanks. Sorry for the slow reply.

Matthew

Re: [PATCH] Fix avx512 vpermq (PR target/79812)

[Uros Bizjak]

On Fri, Mar 3, 2017 at 8:42 PM, Jakub Jelinek  wrote:
> Hi!
>
> vpermq/vpermpd instructions for 512-bit vectors use bogus RTL and if
> we happen to simplify-rtx.c it, we ICE.
> The problem is that for V8D[IF]mode VEC_SELECT we need to use a PARALLEL
> with 8 elements, not 4.
> The _vec_dup_1 change is unrelated to this, spotted
> first by manual inspection and verified by the genrecog.c verify_pattern
> patch; the broadcast wants to broadcast the first element, so it should be
> a scalar vec_select in vec_duplicate, rather than same size vector as
> vec_select's operand.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2017-03-03  Jakub Jelinek  
>
> PR target/79812
> * config/i386/sse.md (VI8F_256_512): Remove mode iterator.
> (_perm): Rename to ...
> (avx2_perm): ... this.  Use VI8F_256 iterator instead
> of VI8F_256_512.
> (_perm_mask): Rename to ...
> (avx512vl_perm_mask): ... this.  Use VI8F_256 iterator instead
> of VI8F_256_512.
> (_perm_1): Rename to ...
> (avx2_perm_1 instead of VI8F_256_512.
> (avx512f_perm): New define_expand.
> (avx512f_perm_mask): Likewise.
> (avx512f_perm_1): New define_insn.
> (_vec_dup_1): Fix up vec_select mode.
>
> * gcc.target/i386/avx512f-vpermq-imm-3.c: New test.

LGTM.

Thanks,
Uros.

> --- gcc/config/i386/sse.md.jj   2017-03-02 10:19:07.0 +0100
> +++ gcc/config/i386/sse.md  2017-03-03 16:10:42.317111636 +0100
> @@ -549,8 +549,6 @@ (define_mode_iterator VI4F_128 [V4SI V4S
>  (define_mode_iterator VI8F_128 [V2DI V2DF])
>  (define_mode_iterator VI4F_256 [V8SI V8SF])
>  (define_mode_iterator VI8F_256 [V4DI V4DF])
> -(define_mode_iterator VI8F_256_512
> -  [V4DI V4DF (V8DI "TARGET_AVX512F") (V8DF "TARGET_AVX512F")])
>  (define_mode_iterator VI48F_256_512
>[V8SI V8SF
>(V16SI "TARGET_AVX512F") (V16SF "TARGET_AVX512F")
> @@ -17306,43 +17304,43 @@ (define_insn "_permvar (set_attr "prefix" "")
> (set_attr "mode" "")])
>
> -(define_expand "_perm"
> -  [(match_operand:VI8F_256_512 0 "register_operand")
> -   (match_operand:VI8F_256_512 1 "nonimmediate_operand")
> +(define_expand "avx2_perm"
> +  [(match_operand:VI8F_256 0 "register_operand")
> +   (match_operand:VI8F_256 1 "nonimmediate_operand")
> (match_operand:SI 2 "const_0_to_255_operand")]
>"TARGET_AVX2"
>  {
>int mask = INTVAL (operands[2]);
> -  emit_insn (gen__perm_1 (operands[0], operands[1],
> - GEN_INT ((mask >> 0) & 3),
> - GEN_INT ((mask >> 2) & 3),
> - GEN_INT ((mask >> 4) & 3),
> - GEN_INT ((mask >> 6) & 3)));
> +  emit_insn (gen_avx2_perm_1 (operands[0], operands[1],
> +   GEN_INT ((mask >> 0) & 3),
> +   GEN_INT ((mask >> 2) & 3),
> +   GEN_INT ((mask >> 4) & 3),
> +   GEN_INT ((mask >> 6) & 3)));
>DONE;
>  })
>
> -(define_expand "_perm_mask"
> -  [(match_operand:VI8F_256_512 0 "register_operand")
> -   (match_operand:VI8F_256_512 1 "nonimmediate_operand")
> +(define_expand "avx512vl_perm_mask"
> +  [(match_operand:VI8F_256 0 "register_operand")
> +   (match_operand:VI8F_256 1 "nonimmediate_operand")
> (match_operand:SI 2 "const_0_to_255_operand")
> -   (match_operand:VI8F_256_512 3 "vector_move_operand")
> +   (match_operand:VI8F_256 3 "vector_move_operand")
> (match_operand: 4 "register_operand")]
> -  "TARGET_AVX512F"
> +  "TARGET_AVX512VL"
>  {
>int mask = INTVAL (operands[2]);
>emit_insn (gen__perm_1_mask (operands[0], operands[1],
> -  GEN_INT ((mask >> 0) & 3),
> -  GEN_INT ((mask >> 2) & 3),
> -  GEN_INT ((mask >> 4) & 3),
> -  GEN_INT ((mask >> 6) & 3),
> -  operands[3], operands[4]));
> + GEN_INT ((mask >> 0) & 3),
> + GEN_INT ((mask >> 2) & 3),
> + GEN_INT ((mask >> 4) & 3),
> + GEN_INT ((mask >> 6) & 3),
> + operands[3], operands[4]));
>DONE;
>  })
>
> -(define_insn "_perm_1"
> -  [(set (match_operand:VI8F_256_512 0 "register_operand" "=v")
> -   (vec_select:VI8F_256_512
> - (match_operand:VI8F_256_512 1 "nonimmediate_operand" "vm")
> +(define_insn "avx2_perm_1"
> +  [(set (match_operand:VI8F_256 0 "register_operand" "=v")
> +   (vec_select:VI8F_256
> + (match_operand:VI8F_256 1 "nonimmediate

RE: [PATCH][MIPS]MSA min,max insn family RTL fixes

[Matthew Fortune]

Prachi Godbole  writes:
> 2017-03-06  Prachi Godbole  
> 
> gcc/
>   * config/mips/mips-msa.md (msa_fmax_a_,
> msa_fmin_a_,
>   msa_max_a_, msa_min_a_): Introduce mode interator
> for
>   if_then_else.
>   (smin3, smax3): Change operand print code from 'B' to
> 'E'.
> 
> gcc/testsuite/
>   * gcc.target/mips/msa-minmax.c: New tests.

OK, thanks.
Matthew

RE: [PATCH][MIPS]MSA dotp.d, dpadd.d, dpsub.d insn RTL - fix MODE

[Matthew Fortune]

Prachi Godbole  writes:
> 2017-03-06  Prachi Godbole  
> 
> gcc/
>   * config/mips/mips-msa.md (msa_dotp__d, msa_dpadd__d,
>   msa_dpsub__d): Fix MODE for vec_select.
> 
> gcc/testsuite/
>   * gcc.target/mips/msa-dotp.c: New tests.

OK, thanks.

Matthew

RE: [PATCH][MIPS]MSA AND.d optimization to generate BCLRI.d

[Matthew Fortune]

Prachi Godbole  writes:
> 2017-03-06  Prachi Godbole  
> 
> gcc/
>   * config/mips/mips.c (mips_gen_const_int_vector): Change type of
> last
>   argument.
>   * config/mips/mips-protos.h (mips_gen_const_int_vector): Likewise.
> 
> gcc/testsuite/
>   * gcc.target/mips/msa-bclri.c: New test.

OK, Thanks.

Matthew

[PATCH] Fix some PR79851 issues

[Richard Biener]

Built on x86_64-unknown-linux-gnu, applied.

Richard.

2017-03-06  Richard Biener  

* lto-streamer.c (lto_check_version): Use %qs in diagnostics.
* plugin.c (register_plugin_info): Likewise.
* tree-chkp.c (chkp_make_static_const_bounds): Likewise.

Index: gcc/lto-streamer.c
===
--- gcc/lto-streamer.c  (revision 245908)
+++ gcc/lto-streamer.c  (working copy)
@@ -380,7 +380,7 @@ lto_check_version (int major, int minor,
 {
   if (major != LTO_major_version || minor != LTO_minor_version)
 fatal_error (input_location,
-"bytecode stream in file '%s' generated with LTO version "
+"bytecode stream in file %qs generated with LTO version "
 "%d.%d instead of the expected %d.%d",
 file_name,
 major, minor,
Index: gcc/plugin.c
===
--- gcc/plugin.c(revision 245908)
+++ gcc/plugin.c(working copy)
@@ -334,7 +334,7 @@ register_plugin_info (const char* name,
 
   if (slot == NULL)
 {
-  error ("unable to register info for plugin '%s' - plugin name not found",
+  error ("unable to register info for plugin %qs - plugin name not found",
 name);
   return;
 }
Index: gcc/tree-chkp.c
===
--- gcc/tree-chkp.c (revision 245908)
+++ gcc/tree-chkp.c (working copy)
@@ -1991,7 +1991,7 @@ chkp_make_static_const_bounds (HOST_WIDE
   /* We don't allow this symbol usage for non bounds.  */
   if (snode->type != SYMTAB_VARIABLE
  || !POINTER_BOUNDS_P (snode->decl))
-   sorry ("-fcheck-pointer-bounds requires '%s' "
+   sorry ("-fcheck-pointer-bounds requires %qs "
   "name for internal usage",
   IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (var)));
 

[PATCH] Use fixed_nonglobal_reg_set to deduce ok_regs (PR rtl-optimization/79728)

[Xi Ruoyao]

Hi,

After Bernd fixed PR44281 (r235809), the registers fixed only because
they are global can be selected by IRA. However, since they are not
in ok_regs, the move cost estimation about them are wrong. Then an
assertion in ira.c failed and then ICE.

To fix this, add these registers into ok_regs.

Bootstrapped/regtested on x86_64-linux-gnu. Is this ok for trunk?

2017-03-06  Xi Ruoyao  

PR rtl-optimization/79728
* reginfo.c (init_reg_sets_1): Use fixed_nonglobal_reg_set
(instead of fixed_regs) to deduce ok_regs.

* gcc.target/i386/pr79728.c: New test.

diff --git a/gcc/reginfo.c b/gcc/reginfo.c
index a2e0b68..85e2695 100644
--- a/gcc/reginfo.c
+++ b/gcc/reginfo.c
@@ -471,7 +471,8 @@ init_reg_sets_1 (void)
   HARD_REG_SET ok_regs;
   CLEAR_HARD_REG_SET (ok_regs);
   for (j = 0; j < FIRST_PSEUDO_REGISTER; j++)
-   if (!fixed_regs [j] && HARD_REGNO_MODE_OK (j, (machine_mode) m))
+   if (!TEST_HARD_REG_BIT (fixed_nonglobal_reg_set, j) &&
+   HARD_REGNO_MODE_OK (j, (machine_mode) m))
      SET_HARD_REG_BIT (ok_regs, j);
 
   for (i = 0; i < N_REG_CLASSES; i++)
diff --git a/gcc/testsuite/gcc.target/i386/pr79728.c 
b/gcc/testsuite/gcc.target/i386/pr79728.c
new file mode 100644
index 000..2f3dede
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr79728.c
@@ -0,0 +1,11 @@
+/* Test for ICE with global register variable assigned to
+   xmm0.  PR79728.  */
+/* { dg-do compile } */
+/* { dg-options "-w -msse" } */
+
+register int a __asm__ ("xmm0");
+
+int foo ()
+{
+  return 0;
+}

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: Fix ICE in use-after-scope w/ -fno-tree-dce (PR, sanitize/79783).

[Jakub Jelinek]

On Mon, Mar 06, 2017 at 08:59:09AM +0100, Martin Liška wrote:
> >> --- a/gcc/asan.c
> >> +++ b/gcc/asan.c
> >> @@ -3107,7 +3107,10 @@ asan_expand_poison_ifn (gimple_stmt_iterator *iter,
> >>  {
> >>gimple *g = gsi_stmt (*iter);
> >>tree poisoned_var = gimple_call_lhs (g);
> >> -  if (!poisoned_var)
> >> +
> >> +  /* It can happen with inlining and -fno-tree-dce that VAR_DECL for a SSA
> >> + NAME was removed and thus the poisoning should not have any usage.  
> >> */
> >> +  if (!poisoned_var || SSA_NAME_VAR (poisoned_var) == NULL_TREE)
> > 
> > I wonder if it wouldn't be better to do:
> >   if (!poisoned_var || has_zero_uses (poisoned_var))
> > 
> > perhaps with -fno-tree-dce we could end up with SSA_NAME_VAR being
> > non-NULL, yet no uses; in that case there is nothing to warn about.
> > On the other side, in theory we could also end up with anonymous SSA_NAME
> > and some uses - in that case perhaps it would be better to warn.
> > So do:
> >   if (SSA_NAME_VAR (poisoned_var) == NULL_TREE)
> > SSA_NAME_VAR (poisoned_var) = create_tmp_var (TREE_TYPE (poisoned_var));
> >   tree shadow_var = create_asan_shadow_var (SSA_NAME_VAR (poisoned_var),
> > shadow_vars_mapping);
> > or so?  We'll need SSA_NAME_VAR non-NULL so that we can use a default def
> > later.
> 
> Ok, I've just prepared and tested following patch that does what Jakub 
> suggested.Hi.
> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
> --- a/gcc/asan.c
> +++ b/gcc/asan.c

Can you please add also the suggested
 {   
   gimple *g = gsi_stmt (*iter);
   tree poisoned_var = gimple_call_lhs (g);
-  if (!poisoned_var)
+  if (!poisoned_var || has_zero_uses (poisoned_var))
 {
   gsi_remove (iter, true);
   return true;
hunk into the same function?  If we don't do DCE, we can end up with
ASAN_POISON with lhs but not really used anywhere.  If there are no uses,
it is a poisoned use.

> @@ -3113,6 +3113,10 @@ asan_expand_poison_ifn (gimple_stmt_iterator *iter,
>return true;
>  }
>  
> +  if (SSA_NAME_VAR (poisoned_var) == NULL_TREE)
> +SET_SSA_NAME_VAR_OR_IDENTIFIER (poisoned_var,
> + create_tmp_var (TREE_TYPE (poisoned_var)));
> +
>tree shadow_var = create_asan_shadow_var (SSA_NAME_VAR (poisoned_var),
>   shadow_vars_mapping);
>  

Ok with that change.

Jakub