[PATCH] middle-end: Prefer no RMW in __builtin_clear_padding implementation where possible

[Jakub Jelinek via Gcc-patches]

Hi!

Currently the __builtin_clear_padding expansion code emits no code for
full words that don't have any padding bits, and most of the time if
the only padding bytes are from the start of the word it attempts to merge
them with previous padding store (via {}) or if the only padding bytes are
from the end of the word, it attempts to merge it with following padding
bytes.  For everything else it was using a RMW, except when it found
an aligned char/short/int covering all the padding bytes and all those
padding bytes were all ones in that store.

The following patch changes it, such that we only use RMW if the padding has
any bytes which have some padding and some non-padding bits (i.e. bitfields
are involved), often it is the same amount of instructions in the end and
avoids being thread-unsafe unless necessary (and avoids having to wait for
the reads to make it into the CPU).  So, if there are no bitfields,
the function will just store some zero bytes, shorts, ints, long longs etc.
where needed.

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

2020-11-24  Jakub Jelinek  

* gimple-fold.c (clear_padding_flush): If a word contains only 0
or 0xff bytes of padding other than all set, all clear, all set
followed by all clear or all clear followed by all set, don't emit
a RMW operation on the whole word or parts of it, but instead
clear the individual bytes of padding.  For paddings of one byte
size, don't use char[1] and {}, but instead just char and 0.

--- gcc/gimple-fold.c.jj2020-11-23 11:59:18.790279409 +0100
+++ gcc/gimple-fold.c   2020-11-23 15:48:36.723510615 +0100
@@ -4033,7 +4033,9 @@ clear_padding_flush (clear_padding_struc
 {
   size_t nonzero_first = wordsize;
   size_t nonzero_last = 0;
-  bool all_ones = true;
+  size_t zero_first = wordsize;
+  size_t zero_last = 0;
+  bool all_ones = true, bytes_only = true;
   if ((unsigned HOST_WIDE_INT) (buf->off + i + wordsize)
  > (unsigned HOST_WIDE_INT) buf->sz)
{
@@ -4055,9 +4057,19 @@ clear_padding_flush (clear_padding_struc
all_ones = false;
  nonzero_last = j + 1 - i;
}
+ else
+   {
+ if (zero_first == wordsize)
+   zero_first = j - i;
+ zero_last = j + 1 - i;
+   }
  if (buf->buf[j] != 0 && buf->buf[j] != (unsigned char) ~0)
-   all_ones = false;
+   {
+ all_ones = false;
+ bytes_only = false;
+   }
}
+  size_t padding_end = i;
   if (padding_bytes)
{
  if (nonzero_first == 0
@@ -4069,7 +4081,6 @@ clear_padding_flush (clear_padding_struc
  padding_bytes += wordsize;
  continue;
}
- size_t padding_end = i;
  if (all_ones && nonzero_first == 0)
{
  padding_bytes += nonzero_last;
@@ -4077,12 +4088,27 @@ clear_padding_flush (clear_padding_struc
  nonzero_first = wordsize;
  nonzero_last = 0;
}
- tree atype = build_array_type_nelts (char_type_node, padding_bytes);
+ else if (bytes_only && nonzero_first == 0)
+   {
+ gcc_assert (zero_first && zero_first != wordsize);
+ padding_bytes += zero_first;
+ padding_end += zero_first;
+   }
+ tree atype, src;
+ if (padding_bytes == 1)
+   {
+ atype = char_type_node;
+ src = build_zero_cst (char_type_node);
+   }
+ else
+   {
+ atype = build_array_type_nelts (char_type_node, padding_bytes);
+ src = build_constructor (atype, NULL);
+   }
  tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base,
 build_int_cst (buf->alias_type,
buf->off + padding_end
- padding_bytes));
- tree src = build_constructor (atype, NULL);
  gimple *g = gimple_build_assign (dst, src);
  gimple_set_location (g, buf->loc);
  gsi_insert_before (buf->gsi, g, GSI_SAME_STMT);
@@ -4099,6 +4125,45 @@ clear_padding_flush (clear_padding_struc
  padding_bytes = nonzero_last - nonzero_first;
  continue;
}
+  if (bytes_only)
+   {
+ /* If bitfields aren't involved in this word, prefer storing
+individual bytes or groups of them over performing a RMW
+operation on the whole word.  */
+ gcc_assert (i + zero_last <= end);
+ for (size_t j = padding_end; j < i + zero_last; j++)
+   {
+ if (buf->buf[j])
+   {
+ size_t k;
+ for (k = j; k < i + zero_last; k++)
+   if (buf->buf[k] == 0)
+ break;
+ HOST_WIDE_INT off =

[PATCH] i386: Add *setcc_hi_1* define_insn_and_split [PR97950]

[Jakub Jelinek via Gcc-patches]

Hi!

As the following testcase shows, unlike char, int or long long sized
__builtin_*_overflow{,_p}, for short sized one in most cases the ce1 pass
doesn't optimize the jo/jno or jc/jnc jumps with setting of a pseudo to 0/1
into seto/setc.  The reason is missing *setcc_hi_1* pattern.  The following
patch implements it using mode iterators so that on i486 and pentium?
one can get the zero extension through and instead of movzbw.

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

2020-11-24  Jakub Jelinek  

PR target/97950
* config/i386/i386.md (*setcc_si_1_and): Macroize into...
(*setcc__1_and): New define_insn_and_split with SWI24 iterator.
(*setcc_si_1_movzbl): Macroize into...
(*setcc__1_movzbl): New define_insn_and_split with SWI24
iterator.

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

--- gcc/config/i386/i386.md.jj  2020-11-23 17:01:48.235055044 +0100
+++ gcc/config/i386/i386.md 2020-11-23 21:29:43.425842870 +0100
@@ -12714,9 +12714,9 @@ (define_insn_and_split "*setcc_di_1"
   operands[2] = gen_lowpart (QImode, operands[0]);
 })
 
-(define_insn_and_split "*setcc_si_1_and"
-  [(set (match_operand:SI 0 "register_operand" "=q")
-   (match_operator:SI 1 "ix86_comparison_operator"
+(define_insn_and_split "*setcc__1_and"
+  [(set (match_operand:SWI24 0 "register_operand" "=q")
+   (match_operator:SWI24 1 "ix86_comparison_operator"
  [(reg FLAGS_REG) (const_int 0)]))
(clobber (reg:CC FLAGS_REG))]
   "!TARGET_PARTIAL_REG_STALL
@@ -12724,7 +12724,7 @@ (define_insn_and_split "*setcc_si_1_and"
   "#"
   "&& reload_completed"
   [(set (match_dup 2) (match_dup 1))
-   (parallel [(set (match_dup 0) (zero_extend:SI (match_dup 2)))
+   (parallel [(set (match_dup 0) (zero_extend:SWI24 (match_dup 2)))
  (clobber (reg:CC FLAGS_REG))])]
 {
   operands[1] = shallow_copy_rtx (operands[1]);
@@ -12732,16 +12732,16 @@ (define_insn_and_split "*setcc_si_1_and"
   operands[2] = gen_lowpart (QImode, operands[0]);
 })
 
-(define_insn_and_split "*setcc_si_1_movzbl"
-  [(set (match_operand:SI 0 "register_operand" "=q")
-   (match_operator:SI 1 "ix86_comparison_operator"
+(define_insn_and_split "*setcc__1_movzbl"
+  [(set (match_operand:SWI24 0 "register_operand" "=q")
+   (match_operator:SWI24 1 "ix86_comparison_operator"
  [(reg FLAGS_REG) (const_int 0)]))]
   "!TARGET_PARTIAL_REG_STALL
&& (!TARGET_ZERO_EXTEND_WITH_AND || optimize_function_for_size_p (cfun))"
   "#"
   "&& reload_completed"
   [(set (match_dup 2) (match_dup 1))
-   (set (match_dup 0) (zero_extend:SI (match_dup 2)))]
+   (set (match_dup 0) (zero_extend:SWI24 (match_dup 2)))]
 {
   operands[1] = shallow_copy_rtx (operands[1]);
   PUT_MODE (operands[1], QImode);
--- gcc/testsuite/gcc.target/i386/pr97950.c.jj  2020-11-23 17:20:33.481605139 
+0100
+++ gcc/testsuite/gcc.target/i386/pr97950.c 2020-11-23 21:32:53.593734242 
+0100
@@ -0,0 +1,153 @@
+/* PR target/95950 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mtune=generic" } */
+/* { dg-final { scan-assembler-times "\tseta\t" 4 } } */
+/* { dg-final { scan-assembler-times "\tseto\t" 16 } } */
+/* { dg-final { scan-assembler-times "\tsetc\t" 4 } } */
+/* { dg-final { scan-assembler-not "\tjn?a\t" } } */
+/* { dg-final { scan-assembler-not "\tjn?o\t" } } */
+/* { dg-final { scan-assembler-not "\tjn?c\t" } } */
+
+char
+f1 (short a, short b)
+{
+  return __builtin_mul_overflow_p (a, b, (short) 0);
+}
+
+char
+f2 (short a, short b)
+{
+  return __builtin_add_overflow_p (a, b, (short) 0);
+}
+
+char
+f3 (short a, short b)
+{
+  return __builtin_sub_overflow_p (a, b, (short) 0);
+}
+
+char
+f4 (unsigned short a, unsigned short b)
+{
+  return __builtin_mul_overflow_p (a, b, (unsigned short) 0);
+}
+
+char
+f5 (unsigned short a, unsigned short b)
+{
+  return __builtin_add_overflow_p (a, b, (unsigned short) 0);
+}
+
+char
+f6 (unsigned short a, unsigned short b)
+{
+  return __builtin_sub_overflow_p (a, b, (unsigned short) 0);
+}
+
+char
+f7 (short a, short b)
+{
+  return __builtin_mul_overflow_p (a, b, (short) 0);
+}
+
+char
+f8 (short a, short b)
+{
+  return __builtin_add_overflow_p (a, b, (short) 0);
+}
+
+char
+f9 (short a, short b)
+{
+  return __builtin_sub_overflow_p (a, b, (short) 0);
+}
+
+char
+f10 (unsigned short a, unsigned short b)
+{
+  return __builtin_mul_overflow_p (a, b, (unsigned short) 0);
+}
+
+char
+f11 (unsigned short a, unsigned short b)
+{
+  return __builtin_add_overflow_p (a, b, (unsigned short) 0);
+}
+
+char
+f12 (unsigned short a, unsigned short b)
+{
+  return __builtin_sub_overflow_p (a, b, (unsigned short) 0);
+}
+
+unsigned short
+f13 (short a, short b)
+{
+  return __builtin_mul_overflow_p (a, b, (short) 0);
+}
+
+unsigned short
+f14 (short a, short b)
+{
+  return __builtin_add_overflow_p (a, b, (short) 0);
+}
+
+unsigned short
+f15 (short a, short b)
+{
+  return __builtin_sub_overflow_p (a, b, (short) 0);
+}
+
+unsigned short
+f16 (unsigned short a, un

Re: [PATCH] i386: Add *setcc_hi_1* define_insn_and_split [PR97950]

[Uros Bizjak via Gcc-patches]

On Tue, Nov 24, 2020 at 9:20 AM Jakub Jelinek  wrote:
>
> Hi!
>
> As the following testcase shows, unlike char, int or long long sized
> __builtin_*_overflow{,_p}, for short sized one in most cases the ce1 pass
> doesn't optimize the jo/jno or jc/jnc jumps with setting of a pseudo to 0/1
> into seto/setc.  The reason is missing *setcc_hi_1* pattern.  The following
> patch implements it using mode iterators so that on i486 and pentium?
> one can get the zero extension through and instead of movzbw.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-11-24  Jakub Jelinek  
>
> PR target/97950
> * config/i386/i386.md (*setcc_si_1_and): Macroize into...
> (*setcc__1_and): New define_insn_and_split with SWI24 iterator.
> (*setcc_si_1_movzbl): Macroize into...
> (*setcc__1_movzbl): New define_insn_and_split with SWI24
> iterator.
>
> * gcc.target/i386/pr97950.c: New test.

OK.

Thanks,
Uros.

>
> --- gcc/config/i386/i386.md.jj  2020-11-23 17:01:48.235055044 +0100
> +++ gcc/config/i386/i386.md 2020-11-23 21:29:43.425842870 +0100
> @@ -12714,9 +12714,9 @@ (define_insn_and_split "*setcc_di_1"
>operands[2] = gen_lowpart (QImode, operands[0]);
>  })
>
> -(define_insn_and_split "*setcc_si_1_and"
> -  [(set (match_operand:SI 0 "register_operand" "=q")
> -   (match_operator:SI 1 "ix86_comparison_operator"
> +(define_insn_and_split "*setcc__1_and"
> +  [(set (match_operand:SWI24 0 "register_operand" "=q")
> +   (match_operator:SWI24 1 "ix86_comparison_operator"
>   [(reg FLAGS_REG) (const_int 0)]))
> (clobber (reg:CC FLAGS_REG))]
>"!TARGET_PARTIAL_REG_STALL
> @@ -12724,7 +12724,7 @@ (define_insn_and_split "*setcc_si_1_and"
>"#"
>"&& reload_completed"
>[(set (match_dup 2) (match_dup 1))
> -   (parallel [(set (match_dup 0) (zero_extend:SI (match_dup 2)))
> +   (parallel [(set (match_dup 0) (zero_extend:SWI24 (match_dup 2)))
>   (clobber (reg:CC FLAGS_REG))])]
>  {
>operands[1] = shallow_copy_rtx (operands[1]);
> @@ -12732,16 +12732,16 @@ (define_insn_and_split "*setcc_si_1_and"
>operands[2] = gen_lowpart (QImode, operands[0]);
>  })
>
> -(define_insn_and_split "*setcc_si_1_movzbl"
> -  [(set (match_operand:SI 0 "register_operand" "=q")
> -   (match_operator:SI 1 "ix86_comparison_operator"
> +(define_insn_and_split "*setcc__1_movzbl"
> +  [(set (match_operand:SWI24 0 "register_operand" "=q")
> +   (match_operator:SWI24 1 "ix86_comparison_operator"
>   [(reg FLAGS_REG) (const_int 0)]))]
>"!TARGET_PARTIAL_REG_STALL
> && (!TARGET_ZERO_EXTEND_WITH_AND || optimize_function_for_size_p (cfun))"
>"#"
>"&& reload_completed"
>[(set (match_dup 2) (match_dup 1))
> -   (set (match_dup 0) (zero_extend:SI (match_dup 2)))]
> +   (set (match_dup 0) (zero_extend:SWI24 (match_dup 2)))]
>  {
>operands[1] = shallow_copy_rtx (operands[1]);
>PUT_MODE (operands[1], QImode);
> --- gcc/testsuite/gcc.target/i386/pr97950.c.jj  2020-11-23 17:20:33.481605139 
> +0100
> +++ gcc/testsuite/gcc.target/i386/pr97950.c 2020-11-23 21:32:53.593734242 
> +0100
> @@ -0,0 +1,153 @@
> +/* PR target/95950 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mtune=generic" } */
> +/* { dg-final { scan-assembler-times "\tseta\t" 4 } } */
> +/* { dg-final { scan-assembler-times "\tseto\t" 16 } } */
> +/* { dg-final { scan-assembler-times "\tsetc\t" 4 } } */
> +/* { dg-final { scan-assembler-not "\tjn?a\t" } } */
> +/* { dg-final { scan-assembler-not "\tjn?o\t" } } */
> +/* { dg-final { scan-assembler-not "\tjn?c\t" } } */
> +
> +char
> +f1 (short a, short b)
> +{
> +  return __builtin_mul_overflow_p (a, b, (short) 0);
> +}
> +
> +char
> +f2 (short a, short b)
> +{
> +  return __builtin_add_overflow_p (a, b, (short) 0);
> +}
> +
> +char
> +f3 (short a, short b)
> +{
> +  return __builtin_sub_overflow_p (a, b, (short) 0);
> +}
> +
> +char
> +f4 (unsigned short a, unsigned short b)
> +{
> +  return __builtin_mul_overflow_p (a, b, (unsigned short) 0);
> +}
> +
> +char
> +f5 (unsigned short a, unsigned short b)
> +{
> +  return __builtin_add_overflow_p (a, b, (unsigned short) 0);
> +}
> +
> +char
> +f6 (unsigned short a, unsigned short b)
> +{
> +  return __builtin_sub_overflow_p (a, b, (unsigned short) 0);
> +}
> +
> +char
> +f7 (short a, short b)
> +{
> +  return __builtin_mul_overflow_p (a, b, (short) 0);
> +}
> +
> +char
> +f8 (short a, short b)
> +{
> +  return __builtin_add_overflow_p (a, b, (short) 0);
> +}
> +
> +char
> +f9 (short a, short b)
> +{
> +  return __builtin_sub_overflow_p (a, b, (short) 0);
> +}
> +
> +char
> +f10 (unsigned short a, unsigned short b)
> +{
> +  return __builtin_mul_overflow_p (a, b, (unsigned short) 0);
> +}
> +
> +char
> +f11 (unsigned short a, unsigned short b)
> +{
> +  return __builtin_add_overflow_p (a, b, (unsigned short) 0);
> +}
> +
> +char
> +f12 (unsigned short a, unsigned short b)
> +{
> +  return __builtin_sub_overflow_p (a, b, (un

[committed] openmp: Fix C ICE on OpenMP atomics [PR97958]

[Jakub Jelinek via Gcc-patches]

Hi!

c_parser_binary_expression was using build2 to create a temporary holder
for binary expression that c_parser_atomic and c_finish_omp_atomic can then
handle.  The latter performs then all the needed checking.

Unfortunately, build2 performs some checking too, e.g. PLUS_EXPR vs.
POINTER_PLUS_EXPR or matching types of the arguments, nothing we can guarantee
at the parsing time.  So we need something like C++ build_min_nt*.  This
patch implements that inline.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
queued for backporting.

2020-11-24  Jakub Jelinek  

PR c/97958
* c-parser.c (c_parser_binary_expression): For omp atomic binary
expressions, use make_node instead of build2 to avoid checking build2
performs.

* c-c++-common/gomp/pr97958.c: New test.

--- gcc/c/c-parser.c.jj 2020-11-14 10:40:11.063411474 +0100
+++ gcc/c/c-parser.c2020-11-23 18:35:40.242698775 +0100
@@ -7865,9 +7865,13 @@ c_parser_binary_expression (c_parser *pa
&& stack[1].expr.value != error_mark_node \
&& (c_tree_equal (stack[0].expr.value, omp_atomic_lhs)\
|| c_tree_equal (stack[1].expr.value, omp_atomic_lhs)))   \
-  stack[0].expr.value\
-   = build2 (stack[1].op, TREE_TYPE (stack[0].expr.value),   \
- stack[0].expr.value, stack[1].expr.value);  \
+  {
  \
+   tree t = make_node (stack[1].op); \
+   TREE_TYPE (t) = TREE_TYPE (stack[0].expr.value);  \
+   TREE_OPERAND (t, 0) = stack[0].expr.value;\
+   TREE_OPERAND (t, 1) = stack[1].expr.value;\
+   stack[0].expr.value = t;  \
+  }
  \
 else \
   stack[sp - 1].expr = parser_build_binary_op (stack[sp].loc,\
   stack[sp].op,  \
--- gcc/testsuite/c-c++-common/gomp/pr97958.c.jj2020-11-23 
18:39:12.143349754 +0100
+++ gcc/testsuite/c-c++-common/gomp/pr97958.c   2020-11-23 18:38:49.637599241 
+0100
@@ -0,0 +1,17 @@
+/* PR c/97958 */
+
+int *p;
+
+void
+foo (void)
+{
+  #pragma omp atomic
+  p = p + 1;
+}
+
+void
+bar (void)
+{
+  #pragma omp atomic   /* { dg-error "invalid expression type for '#pragma omp 
atomic'" } */
+  bar = bar + 1;
+}


Jakub

RE: [PATCH] middle-end: Support complex Addition

[Richard Biener]

On Mon, 23 Nov 2020, Tamar Christina wrote:

> Hi Richi,
> 
> > -Original Message-
> > From: Richard Biener 
> > Sent: Monday, November 23, 2020 3:51 PM
> > To: Tamar Christina 
> > Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz;
> > hongtao@intel.com
> > Subject: Re: [PATCH] middle-end: Support complex Addition
> > 
> > On Mon, 23 Nov 2020, Tamar Christina wrote:
> > 
> > > Hi All,
> > >
> > > This patch adds support for
> > >
> > >   * Complex Addition with rotation of 90 and 270.
> > >
> > >   Addition with rotation of the second argument around the Argand plane.
> > > Supported rotations are 90 and 180.
> > >
> > > c = a + (b * I) and c = a + (b * I * I * I)
> > >
> > > For the full code I have pushed a branch at
> > refs/users/tnfchris/heads/complex-numbers.
> > >
> > > As a side note, I still needed to set
> > >
> > > STMT_SLP_TYPE (call_stmt_info) = pure_slp;
> > >
> > > as the new hybrid detection code only runs for loop aware SLP.
> > >
> > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues, but
> > > sorting out the testcases as TCL is processed before the CPP..
> > >
> > > Ok for master?
> > 
> > So I failed to apply this patch (and after manual fixup build).
> > I went ahead and checked out the branch, patching the tree with
> > x86 support for cadd90 with -msse3 or -mavx2 using the attached
> > patch.
> > 
> 
> It requires a patch you have previously approved pending the rest so it's not 
> committed yet ?

Ah, I missed that.

> > For
> > 
> > double c[1024], b[1024], a[1024];
> > 
> > void foo ()
> > {
> >   for (int i = 0; i < 512; ++i)
> > {
> >   c[2*i] = a[2*i] - b[2*i+1];
> >   c[2*i+1] = a[2*i+1] + b[2*i];
> > }
> > }
> > 
> > I then see
> > 
> > t.c:5:21: note:Analyzing SLP tree 0x39c0010 for patterns
> > t.c:5:21: note:Found COMPLEX_ADD_ROT90 pattern in SLP tree
> > t.c:5:21: note:Target supports COMPLEX_ADD_ROT90 vectorization with
> > mode vector(2) double
> > t.c:5:21: note:Pattern matched SLP tree
> > t.c:5:21: note:node 0x39c0010 (max_nunits=2, refcnt=2)
> > t.c:5:21: note:op template: c[_1] = _5;
> > t.c:5:21: note: stmt 0 c[_1] = _5;
> > t.c:5:21: note: stmt 1 c[_3] = _8;
> > t.c:5:21: note: children 0x39c0080
> > t.c:5:21: note:node 0x39c0080 (max_nunits=2, refcnt=2)
> > t.c:5:21: note:op template: slp_patt_29 = .COMPLEX_ADD_ROT90 (_5, _5);
> > t.c:5:21: note: stmt 0 _5 = _2 - _4;
> > t.c:5:21: note: stmt 1 _8 = _6 + _7;
> > t.c:5:21: note: lane permutation { 0[0] 1[1] }
> > t.c:5:21: note: children 0x39c00f0 0x39c02b0
> > t.c:5:21: note:node 0x39c00f0 (max_nunits=2, refcnt=2)
> > t.c:5:21: note:op template: _2 = a[_1];
> > t.c:5:21: note: stmt 0 _2 = a[_1];
> > t.c:5:21: note: stmt 1 _6 = a[_3];
> > t.c:5:21: note: load permutation { 0 1 }
> > t.c:5:21: note:node 0x39c02b0 (max_nunits=1, refcnt=1)
> > t.c:5:21: note:op: VEC_PERM_EXPR
> > t.c:5:21: note: { }
> > t.c:5:21: note: lane permutation { 0[1] 0[0] }
> > t.c:5:21: note: children 0x39c0160
> > t.c:5:21: note:node 0x39c0160 (max_nunits=2, refcnt=2)
> > t.c:5:21: note:op template: _4 = b[_3];
> > t.c:5:21: note: stmt 0 _4 = b[_3];
> > t.c:5:21: note: stmt 1 _7 = b[_1];
> > t.c:5:21: note: load permutation { 1 0 }
> > 
> > I'm confused about the lane permutation in the .COMPLEX_ADD_ROT90
> > node (I guess this permutation is simply ignored by code-generation).
> > Should it not be there?
> 
> Yes, I had completely missed that. I forgot to blank it out.

Btw, in this context

  /* Unfortunately still need this on the new pattern because non-loop 
SLP
 doesn't call vect_detect_hybrid_slp so it never updates it.  */
  STMT_SLP_TYPE (call_stmt_info) = pure_slp;

this isnt' about the hybrid marker but about vect_mark_slp_stmts
which marks all stmts participating in the SLP graph with pure_slp
which only marks SLP_TREE_SCALAR_STMTS but not SLP_TREE_REPRESENTATIVE.
I think that's OK and thus the above setting of pure_slp is OK as well,
just the comment is off.  Maybe make it "Make sure to mark the
representative statement pure_slp and relevant".

> > 
> > Otherwise the outcome is now as expected.  Permute optimization
> > later produces
> > 
> > t.c:5:21: note:   node 0x39c0080 (max_nunits=2, refcnt=1)
> > t.c:5:21: note:   op template: slp_patt_29 = .COMPLEX_ADD_ROT90 (_5, _5);
> > t.c:5:21: note: stmt 0 _5 = _2 - _4;
> > t.c:5:21: note: stmt 1 _8 = _6 + _7;
> > t.c:5:21: note: lane permutation { 0[0] 1[1] }
> > t.c:5:21: note: children 0x39c00f0 0x39c02b0
> > ...
> > t.c:5:21: note:   node 0x39c02b0 (max_nunits=1, refcnt=1)
> > t.c:5:21: note:   op: VEC_PERM_EXPR
> > t.c:5:21: note: { }
> > t.c:5:21: note: lane permutation { 0[0] 0[1] }
> > t.c:5:21: note: children 0x39c0160
> > t.c:5:21: note:   node 0x39c0160 (max_nunits=2, re

Re: [PATCH] middle-end: Prefer no RMW in __builtin_clear_padding implementation where possible

[Richard Biener]

On Tue, 24 Nov 2020, Jakub Jelinek wrote:

> Hi!
> 
> Currently the __builtin_clear_padding expansion code emits no code for
> full words that don't have any padding bits, and most of the time if
> the only padding bytes are from the start of the word it attempts to merge
> them with previous padding store (via {}) or if the only padding bytes are
> from the end of the word, it attempts to merge it with following padding
> bytes.  For everything else it was using a RMW, except when it found
> an aligned char/short/int covering all the padding bytes and all those
> padding bytes were all ones in that store.
> 
> The following patch changes it, such that we only use RMW if the padding has
> any bytes which have some padding and some non-padding bits (i.e. bitfields
> are involved), often it is the same amount of instructions in the end and
> avoids being thread-unsafe unless necessary (and avoids having to wait for
> the reads to make it into the CPU).  So, if there are no bitfields,
> the function will just store some zero bytes, shorts, ints, long longs etc.
> where needed.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

> 2020-11-24  Jakub Jelinek  
> 
>   * gimple-fold.c (clear_padding_flush): If a word contains only 0
>   or 0xff bytes of padding other than all set, all clear, all set
>   followed by all clear or all clear followed by all set, don't emit
>   a RMW operation on the whole word or parts of it, but instead
>   clear the individual bytes of padding.  For paddings of one byte
>   size, don't use char[1] and {}, but instead just char and 0.
> 
> --- gcc/gimple-fold.c.jj  2020-11-23 11:59:18.790279409 +0100
> +++ gcc/gimple-fold.c 2020-11-23 15:48:36.723510615 +0100
> @@ -4033,7 +4033,9 @@ clear_padding_flush (clear_padding_struc
>  {
>size_t nonzero_first = wordsize;
>size_t nonzero_last = 0;
> -  bool all_ones = true;
> +  size_t zero_first = wordsize;
> +  size_t zero_last = 0;
> +  bool all_ones = true, bytes_only = true;
>if ((unsigned HOST_WIDE_INT) (buf->off + i + wordsize)
> > (unsigned HOST_WIDE_INT) buf->sz)
>   {
> @@ -4055,9 +4057,19 @@ clear_padding_flush (clear_padding_struc
>   all_ones = false;
> nonzero_last = j + 1 - i;
>   }
> +   else
> + {
> +   if (zero_first == wordsize)
> + zero_first = j - i;
> +   zero_last = j + 1 - i;
> + }
> if (buf->buf[j] != 0 && buf->buf[j] != (unsigned char) ~0)
> - all_ones = false;
> + {
> +   all_ones = false;
> +   bytes_only = false;
> + }
>   }
> +  size_t padding_end = i;
>if (padding_bytes)
>   {
> if (nonzero_first == 0
> @@ -4069,7 +4081,6 @@ clear_padding_flush (clear_padding_struc
> padding_bytes += wordsize;
> continue;
>   }
> -   size_t padding_end = i;
> if (all_ones && nonzero_first == 0)
>   {
> padding_bytes += nonzero_last;
> @@ -4077,12 +4088,27 @@ clear_padding_flush (clear_padding_struc
> nonzero_first = wordsize;
> nonzero_last = 0;
>   }
> -   tree atype = build_array_type_nelts (char_type_node, padding_bytes);
> +   else if (bytes_only && nonzero_first == 0)
> + {
> +   gcc_assert (zero_first && zero_first != wordsize);
> +   padding_bytes += zero_first;
> +   padding_end += zero_first;
> + }
> +   tree atype, src;
> +   if (padding_bytes == 1)
> + {
> +   atype = char_type_node;
> +   src = build_zero_cst (char_type_node);
> + }
> +   else
> + {
> +   atype = build_array_type_nelts (char_type_node, padding_bytes);
> +   src = build_constructor (atype, NULL);
> + }
> tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base,
>build_int_cst (buf->alias_type,
>   buf->off + padding_end
>   - padding_bytes));
> -   tree src = build_constructor (atype, NULL);
> gimple *g = gimple_build_assign (dst, src);
> gimple_set_location (g, buf->loc);
> gsi_insert_before (buf->gsi, g, GSI_SAME_STMT);
> @@ -4099,6 +4125,45 @@ clear_padding_flush (clear_padding_struc
> padding_bytes = nonzero_last - nonzero_first;
> continue;
>   }
> +  if (bytes_only)
> + {
> +   /* If bitfields aren't involved in this word, prefer storing
> +  individual bytes or groups of them over performing a RMW
> +  operation on the whole word.  */
> +   gcc_assert (i + zero_last <= end);
> +   for (size_t j = padding_end; j < i + zero_last; j++)
> + {
> +   if (buf->buf[j])
> + {
> +   size_t k;
> +   for (k =

Re: [PATCH] dumpfile.c: use prefixes other that 'note: ' for MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}

[Thomas Schwinge]

Hi!

On 2020-11-13T15:06:24-0700, Jeff Law  wrote:
> On 11/6/20 1:38 AM, Thomas Schwinge wrote:
>> Subject: [PATCH] [testsuite] Enable column location checking for
>>  'dg-optimized', 'dg-missed'

> OK

Thanks, pushed "[testsuite] Enable column location checking for
'dg-optimized', 'dg-missed'" to master branch in commit
24b553d0f73ffea2551a77c67859ad6fe44110a6, and backported to
releases/gcc-10 branch in commit
f696775c43cc38233b037bf677f72b9b9c0b2cba, and releases/gcc-9 branch in
commit c71d97549d4dca17d452b4a47e406c5f6b2a1a56, see attached.
(Functionality not present in releases/gcc-8 branch.)


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 24b553d0f73ffea2551a77c67859ad6fe44110a6 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 6 Nov 2020 09:18:06 +0100
Subject: [PATCH] [testsuite] Enable column location checking for
 'dg-optimized', 'dg-missed'

'process-message' would like the 'msgprefix' argument without trailing space.

This is a small bug-fix for commit ed2d9d3720adef3a260b8a55e17e744352a901fc
"dumpfile.c: use prefixes other than 'note: ' for
MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}", which added 'dg-optimized',
'dg-missed'.

	gcc/testsuite/
	* lib/gcc-dg.exp (dg-optimized, dg-missed): Fix 'process-message'
	call.
	* gcc.dg/vect/nodump-vect-opt-info-1.c: Demonstrate.
	* gcc.dg/vect/nodump-vect-opt-info-2.c: Likewise.
---
 gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-1.c | 4 ++--
 gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-2.c | 4 ++--
 gcc/testsuite/lib/gcc-dg.exp   | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-1.c b/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-1.c
index 3bfe498ef0a..6834b9a9d0b 100644
--- a/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-1.c
+++ b/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-1.c
@@ -5,8 +5,8 @@ void
 vadd (int *dst, int *op1, int *op2, int count)
 {
 /* { dg-prune-output " version\[^\n\r]* alignment" } */
-/* { dg-optimized "loop vectorized" "" { target *-*-* } .+2 } */
-/* { dg-optimized "loop versioned for vectorization because of possible aliasing" "" { target *-*-* } .+1 } */
+/* { dg-optimized "21: loop vectorized" "" { target *-*-* } .+2 } */
+/* { dg-optimized "21: loop versioned for vectorization because of possible aliasing" "" { target *-*-* } .+1 } */
   for (int i = 0; i < count; ++i)
 dst[i] = op1[i] + op2[i];
 }
diff --git a/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-2.c b/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-2.c
index 94c55a92bb4..23a3b39fbb3 100644
--- a/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-2.c
+++ b/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-2.c
@@ -6,7 +6,7 @@ extern void accumulate (int x, int *a);
 int test_missing_function_defn (int *arr, int n) /* { dg-message "vectorized 0 loops in function" } */
 {
   int sum = 0;
-  for (int i = 0; i < n; ++i) /* { dg-missed "couldn't vectorize loop" } */
-accumulate (arr[i], &sum); /* { dg-missed "statement clobbers memory: accumulate \\(.*\\);" } */
+  for (int i = 0; i < n; ++i) /* { dg-missed "21: couldn't vectorize loop" } */
+accumulate (arr[i], &sum); /* { dg-missed "5: statement clobbers memory: accumulate \\(.*\\);" } */
   return sum;
 }
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index e8ad3052657..0e1aafec82f 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -1232,7 +1232,7 @@ proc dg-optimized { args } {
 # Make this variable available here and to the saved proc.
 upvar dg-messages dg-messages
 
-process-message saved-dg-error "optimized: " "$args"
+process-message saved-dg-error "optimized:" "$args"
 }
 
 # Handle output from -fopt-info for MSG_MISSED_OPTIMIZATION:
@@ -1242,7 +1242,7 @@ proc dg-missed { args } {
 # Make this variable available here and to the saved proc.
 upvar dg-messages dg-messages
 
-process-message saved-dg-error "missed: " "$args"
+process-message saved-dg-error "missed:" "$args"
 }
 
 # Check the existence of a gdb in the path, and return true if there
-- 
2.17.1

>From f696775c43cc38233b037bf677f72b9b9c0b2cba Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 6 Nov 2020 09:18:06 +0100
Subject: [PATCH] [testsuite] Enable column location checking for
 'dg-optimized', 'dg-missed'

'process-message' would like the 'msgprefix' argument without trailing space.

This is a small bug-fix for commit ed2d9d3720adef3a260b8a55e17e744352a901fc
"dumpfile.c: use prefixes other than 'note: ' for
MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}", which added 'dg-optimized',
'dg-missed'.

	gcc/testsuite/
	* lib/gcc-dg.exp (dg-optimized, dg-missed): Fix 'process-message'
	call.
	* gcc.dg/vect/nodump-vect-opt-info-1.c: Demonstrate.
	* gcc.dg/vect/nodump-vect-opt-info-2.c: Likewise.

[committed] testsuite: Add testcase for already fixed bug [PR97964]

[Jakub Jelinek via Gcc-patches]

Hi!

This testcase started failing with r8-2090 and works again starting
with r11-4755.

Tested on x86_64-linux, committed to trunk as obvious.

2020-11-24  Jakub Jelinek  

PR tree-optimization/97964
* gcc.dg/tree-ssa/pr97964.c: New test.

--- gcc/testsuite/gcc.dg/tree-ssa/pr97964.c.jj  2020-11-24 10:41:09.855529730 
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr97964.c 2020-11-24 10:40:52.555724821 
+0100
@@ -0,0 +1,18 @@
+/* PR tree-optimization/97964 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-not "link_failure \\\(\\\);" "optimized" } } */
+
+void link_failure (void);
+
+void
+foo (int a)
+{
+  long b = -2;
+  int c = a > 0;
+  int d = b * c;
+  int e = 1 - d;
+  int t = (-1 / e) == 1;
+  if (t != 0)
+link_failure ();
+}

Jakub

Re: [PATCH] dumpfile.c: use prefixes other that 'note: ' for MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}

[Thomas Schwinge]

Hi!

On 2020-11-13T15:06:45-0700, Jeff Law  wrote:
> On 11/6/20 1:50 AM, Thomas Schwinge wrote:
>> On 2018-09-25T16:00:14-0400, David Malcolm  wrote:
>>> The patch adds "dg-optimized" and "dg-missed" directives

>> These currently print "(test for *errors*, line [...])".  However, these
>> diagnostics are not actually error diagnostics (fatal, meaning: causes
>> compilation to fail) but rather warning diagnostics (non-fatal, doesn't
>> cause compilation to fail).  Thus, same as 'dg-message', these should use
>> 'saved-dg-warning' instead of 'saved-dg-error', which will print: "(test
>> for *warnings*, line [...])".  OK to change that after regression
>> testing?
>
> Yes.

Thanks, pushed "[testsuite] Emit 'warning' instead of 'error' diagnostics
for 'dg-optimized', 'dg-missed'" to master branch in commit
54f72078fc05b865601645edafbc6b21701ea546, and backported to
releases/gcc-10 branch in commit
51bec3f6aa1218aeaa8e5e8cdef28fe712ba2902, and releases/gcc-9 branch in
commit b5eabef5daa1393763f2f6df6562d0c4c8ef63ab, see attached.
(Functionality not present in releases/gcc-8 branch.)


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 54f72078fc05b865601645edafbc6b21701ea546 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 6 Nov 2020 09:51:16 +0100
Subject: [PATCH] [testsuite] Emit 'warning' instead of 'error' diagnostics for
 'dg-optimized', 'dg-missed'

The diagnostics produced by 'dg-optimized', 'dg-missed' aren't error
diagnostics (fatal, meaning: causes compilation to fail) but rather warning
diagnostics (non-fatal, doesn't cause compilation to fail).  Thus, same as
'dg-message', these should use 'saved-dg-warning' instead of 'saved-dg-error',
which then prints: "(test for *warnings*, line [...]) instead of currently:
"(test for *errors*, line [...])".

This is a small bug-fix for commit ed2d9d3720adef3a260b8a55e17e744352a901fc
"dumpfile.c: use prefixes other than 'note: ' for
MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}", which added 'dg-optimized',
'dg-missed'.

	gcc/testsuite/
	* lib/gcc-dg.exp (dg-optimized, dg-missed): Use 'saved-dg-warning'
	instead of 'saved-dg-error'.
---
 gcc/testsuite/lib/gcc-dg.exp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 0e1aafec82f..700529afbe2 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -1232,7 +1232,7 @@ proc dg-optimized { args } {
 # Make this variable available here and to the saved proc.
 upvar dg-messages dg-messages
 
-process-message saved-dg-error "optimized:" "$args"
+process-message saved-dg-warning "optimized:" "$args"
 }
 
 # Handle output from -fopt-info for MSG_MISSED_OPTIMIZATION:
@@ -1242,7 +1242,7 @@ proc dg-missed { args } {
 # Make this variable available here and to the saved proc.
 upvar dg-messages dg-messages
 
-process-message saved-dg-error "missed:" "$args"
+process-message saved-dg-warning "missed:" "$args"
 }
 
 # Check the existence of a gdb in the path, and return true if there
-- 
2.17.1

>From 51bec3f6aa1218aeaa8e5e8cdef28fe712ba2902 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 6 Nov 2020 09:51:16 +0100
Subject: [PATCH] [testsuite] Emit 'warning' instead of 'error' diagnostics for
 'dg-optimized', 'dg-missed'

The diagnostics produced by 'dg-optimized', 'dg-missed' aren't error
diagnostics (fatal, meaning: causes compilation to fail) but rather warning
diagnostics (non-fatal, doesn't cause compilation to fail).  Thus, same as
'dg-message', these should use 'saved-dg-warning' instead of 'saved-dg-error',
which then prints: "(test for *warnings*, line [...]) instead of currently:
"(test for *errors*, line [...])".

This is a small bug-fix for commit ed2d9d3720adef3a260b8a55e17e744352a901fc
"dumpfile.c: use prefixes other than 'note: ' for
MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION}", which added 'dg-optimized',
'dg-missed'.

	gcc/testsuite/
	* lib/gcc-dg.exp (dg-optimized, dg-missed): Use 'saved-dg-warning'
	instead of 'saved-dg-error'.

(cherry picked from commit 54f72078fc05b865601645edafbc6b21701ea546)
---
 gcc/testsuite/lib/gcc-dg.exp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index cc331214a1f..58519b0421b 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -1216,7 +1216,7 @@ proc dg-optimized { args } {
 # Make this variable available here and to the saved proc.
 upvar dg-messages dg-messages
 
-process-message saved-dg-error "optimized:" "$args"
+process-message saved-dg-warning "optimized:" "$args"
 }
 
 # Handle output from -fopt-info for MSG_MISSED_OPTIMIZATION:
@@ -1226,7 +1226,7 @@ proc dg-missed { args } {
 # Make this variable available here and to the save

Re: Add 'dg-note' next to 'dg-optimized', 'dg-missed' (was: [PATCH] dumpfile.c: use prefixes other that 'note: ' for MSG_{OPTIMIZED_LOCATIONS|MISSED_OPTIMIZATION})

[Thomas Schwinge]

Hi!

Ping.


Grüße
 Thomas


On 2020-11-06T10:26:46+0100, I wrote:
> Hi, again!
>
> On 2018-09-25T16:00:14-0400, David Malcolm  wrote:
>> As noted at Cauldron, dumpfile.c currently emits "note: " for all kinds
>> of dump message, so that (after filtering) there's no distinction between
>> MSG_OPTIMIZED_LOCATIONS vs MSG_NOTE vs MSG_MISSED_OPTIMIZATION in the
>> textual output.
>>
>> This patch changes dumpfile.c so that the "note: " varies to show
>> which MSG_* was used, with the string prefix matching that used for
>> filtering in -fopt-info, hence e.g.
>>   directive_unroll_3.f90:24:0: optimized: loop unrolled 7 times
>> and:
>>   pr19210-1.c:24:3: missed: missed loop optimization: niters analysis ends 
>> up with assumptions.
>
> (However, 'MSG_NOTE'/'note: ' also still remains used for "general
> optimization info".)
>
>> The patch adds "dg-optimized" and "dg-missed" directives
>
>> --- a/gcc/testsuite/lib/gcc-dg.exp
>> +++ b/gcc/testsuite/lib/gcc-dg.exp
>
>> +# Handle output from -fopt-info for MSG_OPTIMIZED_LOCATIONS:
>> +# a successful optimization.
>> +
>> +proc dg-optimized { args } {
>> +# Make this variable available here and to the saved proc.
>> +upvar dg-messages dg-messages
>> +
>> +process-message saved-dg-error "optimized: " "$args"
>> +}
>> +
>> +# Handle output from -fopt-info for MSG_MISSED_OPTIMIZATION:
>> +# a missed optimization.
>> +
>> +proc dg-missed { args } {
>> +# Make this variable available here and to the saved proc.
>> +upvar dg-messages dg-messages
>> +
>> +process-message saved-dg-error "missed: " "$args"
>> +}
>> +
>
> Next to these, I'm proposing to add 'dg-note', see attached "[WIP] Add
> 'dg-note' next to 'dg-optimized'", which may be used instead of generic
> 'dg-message' (which in current uses in testcases often doesn't scan for
> the 'note: ' prefix, by the way).
>
> The proposed 'dg-note' has the additional property that "if dg-note is
> used once, [notes] must *all* be handled explicitly".  The rationale is
> that either you're not interested in notes at all (default behavior of
> pruning all notes), but often, when you're interested in one note, you're
> in fact interested in all notes, and especially interested if
> *additional* notes appear over time, as GCC evolves.  It seemed somewhat
> useful, but I'm not insisting on coupling the disabling of notes pruning
> on 'dg-note' usage, so if anyone feels strongly about that, please speak
> up.
>
> TODO document (also 'dg-optimized', 'dg-missed')
>
> TODO 'gcc/testsuite/lib/lto.exp' change necessary/desirable?
>
> The latter got added in commit 824721f0905478ebc39e6a295cc8e95c22fa9d17
> "lto, testsuite: Fix ICE in -Wodr (PR lto/83121)".  David, do you happen
> to have an opinion on that one?
>
>
> Grüße
>  Thomas
>
>
> From bb293fff7580025a3b78fc1619d8bf0d8f8b8a1a Mon Sep 17 00:00:00 2001
> From: Thomas Schwinge 
> Date: Fri, 6 Nov 2020 09:01:26 +0100
> Subject: [PATCH] [WIP] Add 'dg-note' next to 'dg-optimized', 'dg-missed'
>
> TODO document (also 'dg-optimized', 'dg-missed')
>
> TODO 'gcc/testsuite/lib/lto.exp' change necessary/desirable?
> ---
>  .../gcc.dg/vect/nodump-vect-opt-info-2.c  |  4 ++-
>  gcc/testsuite/lib/gcc-dg.exp  | 26 +++
>  gcc/testsuite/lib/lto.exp |  7 +++--
>  gcc/testsuite/lib/prune.exp   |  7 +++--
>  4 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-2.c 
> b/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-2.c
> index 23a3b39fbb32..bcdf7f076715 100644
> --- a/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-2.c
> +++ b/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-2.c
> @@ -3,7 +3,9 @@
>
>  extern void accumulate (int x, int *a);
>
> -int test_missing_function_defn (int *arr, int n) /* { dg-message "vectorized 
> 0 loops in function" } */
> +int test_missing_function_defn (int *arr, int n) /* { dg-note "5: vectorized 
> 0 loops in function" } */
> +/* { dg-prune-output "note: " } as we're not interested in matching any 
> further
> +   notes.  */
>  {
>int sum = 0;
>for (int i = 0; i < n; ++i) /* { dg-missed "21: couldn't vectorize loop" } 
> */
> diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
> index 700529afbe25..c6ff07ab1376 100644
> --- a/gcc/testsuite/lib/gcc-dg.exp
> +++ b/gcc/testsuite/lib/gcc-dg.exp
> @@ -1012,6 +1012,8 @@ if { [info procs saved-dg-test] == [list] } {
>   }
>   unset save_linenr_varnames
>   }
> +
> + initialize_prune_notes
>  }
>
>  proc dg-test { args } {
> @@ -1245,6 +1247,30 @@ proc dg-missed { args } {
>  process-message saved-dg-warning "missed:" "$args"
>  }
>
> +# Handle output from -fopt-info for MSG_NOTE:
> +# a general optimization info.
> +# By default, such notes are pruned, but if dg-note is used once, they must 
> all
> +# be handled explicitly.
> +
> +variable prune_notes
> +
> +proc initialize_prune_notes { } {
> +global 

Re: H8 cc0 conversion

[Hans-Peter Nilsson]

On Mon, 23 Nov 2020, Jeff Law wrote:

> On 11/23/20 9:49 PM, Hans-Peter Nilsson wrote:
> > On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote:
> >> This is the primary patch for cc0 removal on the H8 port.? It doesn't
> >> have any of the optimization work and many patterns are simply disabled
> >> at this time.? It's working well enough to not regress the testsuite.
> >>
> >> The H8 is similar to the m68k and other ports in that the vast majority
> >> of instructions clobber the condition codes, including most of the
> >> arithmetic insns that reload needs to use. While there's a special
> >> adds/subs that does not modify the condition codes, they only accept
> >> constant addends of 1, 2 and 4. With that in mind, this port does not
> >> expose cc0 until after reload. So most patterns are defined using
> >> define_insn_and_split. The splitter adds the appropriate clobbers.
> > JFTR (as I'm repeating a previous note for another port): if
> > you'd went for exposing cc0 *before* reload (adding a clobber to
> > each pattern that clobbers, then specifying exceptions removing
> > them), the amount of (required) define_insn_and_splits would
> > have been zero; typically much less churn in the port.  That
> > approach also has the benefit of insns not "silently" changing
> > behavior at reload-time.
> >
> > You might think a parallel with a clobber for each insn hampers
> > some rtl optimizations, but I found that to be not an issue at
> > all, doing that for CRIS (at least when comparing to the cc0
> > version).
> I've definitely seen cases where exposing the clobber early hurts, so I
> went with exposing after reload.

I'm intested in any notes, however vague, on that matter.  I was
a bit surprised to see that myself...that is, after fixing
*some* related regressions, like the one in combine.  (Did I
actually miss something?)

> I also had someone else doing most of the grunt work, my son :-)

Given horsework, for sure!

brgds, H-P

[Ada] Remove SPARK-specific expansion of array aggregates

[Pierre-Marie de Rodat]

With analysis of the original array aggregate expressions (and not of
the copies, as it used to be) and without removing references to index
parameters of iterated_component_associations (which only need to be
removed when expander is active) we no longer need any SPARK-specific
code for array aggregates.

This change only affects GNATprove; the compiler is unaffected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_spark.adb (Expand_SPARK_Array_Aggregate,
Expand_SPARK_N_Aggregate): Remove, no longer needed.
* sem_aggr.adb (Resolve_Iterated_Component_Association): Only
remove references in the analyzed expression when generating
code and the expression needs to be analyzed anew after being
rewritten into a loop.diff --git a/gcc/ada/exp_spark.adb b/gcc/ada/exp_spark.adb
--- a/gcc/ada/exp_spark.adb
+++ b/gcc/ada/exp_spark.adb
@@ -52,16 +52,6 @@ package body Exp_SPARK is
-- Local Subprograms --
---
 
-   procedure Expand_SPARK_Array_Aggregate (N : Node_Id; Index : Node_Id);
-   --  Perform array-aggregate-specific expansion of an array sub-aggregate N
-   --  corresponding to the Index of the outer-most aggregate. This routine
-   --  mimics Resolve_Array_Aggregate which only checks the aggregate for being
-   --  well-formed, but doesn't analyze nor apply range checks to
-   --  iterated_component_associations.
-
-   procedure Expand_SPARK_N_Aggregate (N : Node_Id);
-   --  Perform aggregate-specific expansion
-
procedure Expand_SPARK_N_Attribute_Reference (N : Node_Id);
--  Perform attribute-reference-specific expansion
 
@@ -112,9 +102,6 @@ package body Exp_SPARK is
  =>
 Qualify_Entity_Names (N);
 
- when N_Aggregate =>
-Expand_SPARK_N_Aggregate (N);
-
  --  Replace occurrences of System'To_Address by calls to
  --  System.Storage_Elements.To_Address.
 
@@ -161,107 +148,6 @@ package body Exp_SPARK is
end Expand_SPARK;
 
--
-   -- Expand_SPARK_Array_Aggregate --
-   --
-
-   procedure Expand_SPARK_Array_Aggregate (N : Node_Id; Index : Node_Id) is
-
-  procedure Expand_Aggr_Expr (Expr : Node_Id);
-  --  If Expr is a subaggregate, then process it recursively; otherwise it
-  --  is an expression for the array components which might not have been
-  --  analyzed and where scalar range checks could be missing.
-
-  --
-  -- Expand_Aggr_Expr --
-  --
-
-  procedure Expand_Aggr_Expr (Expr : Node_Id) is
- Nxt_Ind : constant Node_Id := Next_Index (Index);
-  begin
- if Present (Nxt_Ind) then
-Expand_SPARK_Array_Aggregate (Expr, Index => Nxt_Ind);
- else
-declare
-   Comp_Type : constant Entity_Id := Component_Type (Etype (N));
-begin
-   Analyze_And_Resolve (Expr, Comp_Type);
-
-   if Is_Scalar_Type (Comp_Type) then
-  Apply_Scalar_Range_Check (Expr, Comp_Type);
-   end if;
-end;
- end if;
-  end Expand_Aggr_Expr;
-
-  --  Local variables
-
-  Assoc : Node_Id := First (Component_Associations (N));
-
-   --  Start of processing for Expand_SPARK_Array_Aggregate
-
-   begin
-  while Present (Assoc) loop
- --  For iterated_component_association we must apply range check to
- --  discrete choices and re-analyze the expression, because frontend
- --  only checks its legality and then analyzes the expanded loop code.
-
- if Nkind (Assoc) = N_Iterated_Component_Association then
-declare
-   Choice : Node_Id;
-begin
-   --  Analyze discrete choices
-
-   Choice := First (Discrete_Choices (Assoc));
-
-   while Present (Choice) loop
-
-  --  The index denotes a range of elements where range checks
-  --  have been already applied.
-
-  if Nkind (Choice) in N_Others_Choice
- | N_Range
- | N_Subtype_Indication
-  then
- null;
-
-  --  Otherwise the index denotes a single element (or a
-  --  subtype name which doesn't require range checks).
-
-  else pragma Assert (Nkind (Choice) in N_Subexpr);
- Apply_Scalar_Range_Check (Choice, Etype (Index));
-  end if;
-
-  Next (Choice);
-   end loop;
-
-   --  Keep processing the expression with index parameter in scope
-
-   Push_Scope (Scope (Defining_Identifier (Assoc)));
-   Enter_Name (Defining_Identifier (Assoc));
-   Expand_Aggr_Expr (Expression (Assoc));
-   End_Scope;
-end;
-
-   

[Ada] Fix resolution of subtype_indication in delta aggregates

[Pierre-Marie de Rodat]

For a Subtype_Indication in ordinary array aggregates we explicitly call
Resolve_Discrete_Subtype_Indication; for a Subtype_Indication in delta
array aggregates we implicitly call Sem_Ch3.Analyze_Subtype_Indication,
which is only meant to be used in declarations, not in expressions.

This subtle difference causes a crash in GNATprove mode when delta
aggregate appears inside a body that is inlined-for-proof (which
involves an unusual combination of flags Expander_Active, Full_Analysis
and GNATprove_Mode).

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_aggr.adb (Resolve_Delta_Array_Aggregate): If the choice is
a subtype_indication then call
Resolve_Discrete_Subtype_Indication; both for choices
immediately inside array delta aggregates and inside
iterated_component_association within array delta aggregates.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -3072,6 +3072,10 @@ package body Sem_Aggr is
   Error_Msg_N
 ("others not allowed in delta aggregate", Choice);
 
+   elsif Nkind (Choice) = N_Subtype_Indication then
+  Resolve_Discrete_Subtype_Indication
+(Choice, Base_Type (Index_Type));
+
else
   Analyze_And_Resolve (Choice, Index_Type);
end if;
@@ -3109,28 +3113,31 @@ package body Sem_Aggr is
  else
 Choice := First (Choice_List (Assoc));
 while Present (Choice) loop
+   Analyze (Choice);
+
if Nkind (Choice) = N_Others_Choice then
   Error_Msg_N
 ("others not allowed in delta aggregate", Choice);
 
-   else
-  Analyze (Choice);
+   elsif Is_Entity_Name (Choice)
+ and then Is_Type (Entity (Choice))
+   then
+  --  Choice covers a range of values
 
-  if Is_Entity_Name (Choice)
-and then Is_Type (Entity (Choice))
+  if Base_Type (Entity (Choice)) /=
+ Base_Type (Index_Type)
   then
- --  Choice covers a range of values
-
- if Base_Type (Entity (Choice)) /=
-Base_Type (Index_Type)
- then
-Error_Msg_NE
-  ("choice does not match index type of &",
-   Choice, Typ);
- end if;
-  else
- Resolve (Choice, Index_Type);
+ Error_Msg_NE
+   ("choice does not match index type of &",
+Choice, Typ);
   end if;
+
+   elsif Nkind (Choice) = N_Subtype_Indication then
+  Resolve_Discrete_Subtype_Indication
+(Choice, Base_Type (Index_Type));
+
+   else
+  Resolve (Choice, Index_Type);
end if;
 
Next (Choice);

[Ada] Use high-level Present instead of low-level equality test

[Pierre-Marie de Rodat]

Routine Present for Unit_Name_Type was introduced precisely to avoid
equality tests with No_Unit_Name. Code cleanup only; semantics is
unaffected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* lib-load.adb, lib-writ.adb, lib.adb, par-load.adb,
rtsfind.adb, sem_ch10.adb: Use Present where possible.diff --git a/gcc/ada/lib-load.adb b/gcc/ada/lib-load.adb
--- a/gcc/ada/lib-load.adb
+++ b/gcc/ada/lib-load.adb
@@ -551,7 +551,7 @@ package body Lib.Load is
   --  Note: Unit_Name (Main_Unit) is not set if we are parsing gnat.adc.
 
   if Present (Error_Node)
-and then Unit_Name (Main_Unit) /= No_Unit_Name
+and then Present (Unit_Name (Main_Unit))
   then
  --  It seems like In_Extended_Main_Source_Unit (Error_Node) would
  --  do the trick here, but that's wrong, it is much too early to


diff --git a/gcc/ada/lib-writ.adb b/gcc/ada/lib-writ.adb
--- a/gcc/ada/lib-writ.adb
+++ b/gcc/ada/lib-writ.adb
@@ -837,7 +837,7 @@ package body Lib.Writ is
 --  preprocessing data and definition files, there is no Unit_Name,
 --  check for that first.
 
-if Unit_Name (J) /= No_Unit_Name
+if Present (Unit_Name (J))
   and then (With_Flags (J) or else Unit_Name (J) = Pname)
 then
Num_Withs := Num_Withs + 1;


diff --git a/gcc/ada/lib.adb b/gcc/ada/lib.adb
--- a/gcc/ada/lib.adb
+++ b/gcc/ada/lib.adb
@@ -275,7 +275,7 @@ package body Lib is
begin
   --  First unregister the old name, if any
 
-  if Old_N /= No_Unit_Name and then Unit_Names.Get (Old_N) = U then
+  if Present (Old_N) and then Unit_Names.Get (Old_N) = U then
  Unit_Names.Set (Old_N, No_Unit);
   end if;
 


diff --git a/gcc/ada/par-load.adb b/gcc/ada/par-load.adb
--- a/gcc/ada/par-load.adb
+++ b/gcc/ada/par-load.adb
@@ -318,7 +318,7 @@ begin
 
   Spec_Name := Get_Parent_Spec_Name (Unit_Name (Cur_Unum));
 
-  if Spec_Name /= No_Unit_Name then
+  if Present (Spec_Name) then
  Unum :=
Load_Unit
  (Load_Name  => Spec_Name,


diff --git a/gcc/ada/rtsfind.adb b/gcc/ada/rtsfind.adb
--- a/gcc/ada/rtsfind.adb
+++ b/gcc/ada/rtsfind.adb
@@ -423,7 +423,7 @@ package body Rtsfind is
  (Unit_Name (Current_Sem_Unit));
 
   begin
- if Parent_Name /= No_Unit_Name then
+ if Present (Parent_Name) then
 Get_Name_String (Parent_Name);
 
 declare


diff --git a/gcc/ada/sem_ch10.adb b/gcc/ada/sem_ch10.adb
--- a/gcc/ada/sem_ch10.adb
+++ b/gcc/ada/sem_ch10.adb
@@ -768,7 +768,7 @@ package body Sem_Ch10 is
 Unum := Get_Cunit_Unit_Number (N);
 Par_Spec_Name := Get_Parent_Spec_Name (Unit_Name (Unum));
 
-if Par_Spec_Name /= No_Unit_Name then
+if Present (Par_Spec_Name) then
Unum :=
  Load_Unit
(Load_Name  => Par_Spec_Name,

[Ada] Fix spurious error on child library-level subprogram with aspects

[Pierre-Marie de Rodat]

GNAT used to reject such code with a spurious error about the aspect not
being attached to the initial declaration. Now fixed. The workaround is
to declare a library-level spec for the subprogram, to which the aspects
are attached.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch10.adb (Analyze_Compilation_Unit): Move aspects from
body to the newly created spec.diff --git a/gcc/ada/sem_ch10.adb b/gcc/ada/sem_ch10.adb
--- a/gcc/ada/sem_ch10.adb
+++ b/gcc/ada/sem_ch10.adb
@@ -828,6 +828,7 @@ package body Sem_Ch10 is
  --  of the child unit does not act as spec any longer.
 
  Set_Acts_As_Spec (N, False);
+ Move_Aspects (From => Unit_Node, To => Unit (Lib_Unit));
  Set_Is_Child_Unit (Defining_Entity (Unit_Node));
  Set_Debug_Info_Needed (Defining_Entity (Unit (Lib_Unit)));
  Set_Comes_From_Source_Default (SCS);

[Ada] Implement Big_Integer.From_String fully

[Pierre-Marie de Rodat]

The previous implementation only supported up to 128bits integers, now
provide a full implementation for unbounded integers.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/a-nbnbin.adb (From_String): Implement fully.diff --git a/gcc/ada/libgnat/a-nbnbin.adb b/gcc/ada/libgnat/a-nbnbin.adb
--- a/gcc/ada/libgnat/a-nbnbin.adb
+++ b/gcc/ada/libgnat/a-nbnbin.adb
@@ -236,11 +236,196 @@ package body Ada.Numerics.Big_Numbers.Big_Integers is
-
 
function From_String (Arg : String) return Big_Integer is
+  procedure Scan_Decimal
+(Arg : String; J : in out Natural; Result : out Big_Integer);
+  --  Scan decimal value starting at Arg (J). Store value in Result if
+  --  successful, raise Constraint_Error if not. On exit, J points to the
+  --  first index past the decimal value.
+
+  --
+  -- Scan_Decimal --
+  --
+
+  procedure Scan_Decimal
+(Arg : String; J : in out Natural; Result : out Big_Integer)
+  is
+ Initial_J : constant Natural := J;
+ Ten   : constant Big_Integer := To_Big_Integer (10);
+  begin
+ Result := To_Big_Integer (0);
+
+ while J <= Arg'Last loop
+if Arg (J) in '0' .. '9' then
+   Result :=
+ Result * Ten + To_Big_Integer (Character'Pos (Arg (J))
+  - Character'Pos ('0'));
+
+elsif Arg (J) = '_' then
+   if J in Initial_J | Arg'Last
+ or else Arg (J - 1) not in '0' .. '9'
+ or else Arg (J + 1) not in '0' .. '9'
+   then
+  raise Constraint_Error with "invalid integer value: " & Arg;
+   end if;
+else
+   exit;
+end if;
+
+J := J + 1;
+ end loop;
+  end Scan_Decimal;
+
   Result : Big_Integer;
+
begin
-  --  ??? only support Long_Long_Long_Integer, good enough for now
+  --  First try the fast path via Long_Long_Long_Integer'Value
+
   Set_Bignum (Result, To_Bignum (Long_Long_Long_Integer'Value (Arg)));
   return Result;
+
+   exception
+  when Constraint_Error =>
+ --  Then try the slow path
+
+ declare
+Neg: Boolean  := False;
+Base_Found : Boolean  := False;
+Base_Int   : Positive := 10;
+J  : Natural  := Arg'First;
+Val: Natural;
+Base   : Big_Integer;
+Exp: Big_Integer;
+
+ begin
+--  Scan past leading blanks
+
+while J <= Arg'Last and then Arg (J) = ' ' loop
+   J := J + 1;
+end loop;
+
+if J > Arg'Last then
+   raise;
+end if;
+
+--  Scan and store negative sign if found
+
+if Arg (J) = '-' then
+   Neg := True;
+   J   := J + 1;
+end if;
+
+--  Scan decimal value: either the result itself, or the base
+--  value if followed by a '#'.
+
+Scan_Decimal (Arg, J, Result);
+
+--  Scan explicit base if requested
+
+if J <= Arg'Last and then Arg (J) = '#' then
+   Base_Int := To_Integer (Result);
+
+   if Base_Int not in 2 .. 16 then
+  raise;
+   end if;
+
+   Base_Found := True;
+   Base   := Result;
+   Result := To_Big_Integer (0);
+   J  := J + 1;
+
+   while J <= Arg'Last loop
+  case Arg (J) is
+ when '0' .. '9' =>
+Val := Character'Pos (Arg (J)) - Character'Pos ('0');
+
+if Val >= Base_Int then
+   raise;
+end if;
+
+Result := Result * Base + To_Big_Integer (Val);
+
+ when 'a' .. 'f' =>
+Val :=
+  10 + Character'Pos (Arg (J)) - Character'Pos ('a');
+
+if Val >= Base_Int then
+   raise;
+end if;
+
+Result := Result * Base + To_Big_Integer (Val);
+
+ when 'A' .. 'F' =>
+Val :=
+  10 + Character'Pos (Arg (J)) - Character'Pos ('A');
+
+if Val >= Base_Int then
+   raise;
+end if;
+
+Result := Result * Base + To_Big_Integer (Val);
+
+ when '_' =>
+
+--  We only allow _ preceded and followed by a valid
+--  number and not any other character.
+
+if J in Arg'First | Arg'Last
+  or else Arg (J - 1) in

[Ada] Wrong finalization in call with if expression

[Pierre-Marie de Rodat]

Changes made for "Bad access checks on if/case expression as actual"
introduced a regression when dealing with transient objects: the
processing of function calls in Add_Cond_Expression_Extra_Actual would
remove the setting of the "hook" variable needed for proper
finalization.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_ch6.adb (Add_Cond_Expression_Extra_Actual): Simplify
handling of function calls and remove bug in handling of
transient objects.  Minor reformatting along the way.diff --git a/gcc/ada/exp_ch6.adb b/gcc/ada/exp_ch6.adb
--- a/gcc/ada/exp_ch6.adb
+++ b/gcc/ada/exp_ch6.adb
@@ -2879,17 +2879,10 @@ package body Exp_Ch6 is
 (Formal : Entity_Id)
   is
  Decl : Node_Id;
-
- --  Suppress warning for the final removal loop
- pragma Warnings (Off, Decl);
-
  Lvl  : Entity_Id;
- Res  : Entity_Id;
- Temp : Node_Id;
- Typ  : Node_Id;
 
  procedure Insert_Level_Assign (Branch : Node_Id);
- --  Recursivly add assignment of the level temporary on each branch
+ --  Recursively add assignment of the level temporary on each branch
  --  while moving through nested conditional expressions.
 
  -
@@ -2917,12 +2910,10 @@ package body Exp_Ch6 is
--  There are more nested conditional expressions so we must go
--  deeper.
 
-   if Nkind (Expression (Res_Assn)) =
-N_Expression_With_Actions
+   if Nkind (Expression (Res_Assn)) = N_Expression_With_Actions
  and then
-   Nkind
- (Original_Node (Expression (Res_Assn)))
-   in N_Case_Expression | N_If_Expression
+   Nkind (Original_Node (Expression (Res_Assn)))
+ in N_Case_Expression | N_If_Expression
then
   Insert_Level_Assign
 (Expression (Res_Assn));
@@ -2932,9 +2923,7 @@ package body Exp_Ch6 is
else
   Insert_Before_And_Analyze (Res_Assn,
 Make_Assignment_Statement (Loc,
-  Name   =>
-New_Occurrence_Of
-  (Lvl, Loc),
+  Name   => New_Occurrence_Of (Lvl, Loc),
   Expression =>
 Accessibility_Level
   (Expression (Res_Assn), Dynamic_Level)));
@@ -2956,9 +2945,7 @@ package body Exp_Ch6 is
 
 Cond := First (Actions (Branch));
 while Present (Cond) loop
-   exit when Nkind (Cond) in
-   N_Case_Statement | N_If_Statement;
-
+   exit when Nkind (Cond) in N_Case_Statement | N_If_Statement;
Next (Cond);
 end loop;
 
@@ -2981,7 +2968,6 @@ package body Exp_Ch6 is
Alt := First (Alternatives (Cond));
while Present (Alt) loop
   Expand_Branch (Last (Statements (Alt)));
-
   Next (Alt);
end loop;
 end if;
@@ -3000,7 +2986,7 @@ package body Exp_Ch6 is
  New_Occurrence_Of (Standard_Natural, Loc));
 
  --  Install the declaration and perform necessary expansion if we
- --  are dealing with a function call.
+ --  are dealing with a procedure call.
 
  if Nkind (Call_Node) = N_Procedure_Call_Statement then
 --  Generate:
@@ -3019,57 +3005,27 @@ package body Exp_Ch6 is
 
 Insert_Before_And_Analyze (Call_Node, Decl);
 
- --  A function call must be transformed into an expression with
- --  actions.
+ --  Ditto for a function call. Note that we do not wrap the function
+ --  call into an expression with action to avoid bad interactions with
+ --  Exp_Ch4.Process_Transient_In_Expression.
 
  else
 --  Generate:
---do
---  Lvl : Natural;
---in Call (do{
---   If_Exp_Res : Typ
---   if Cond then
--- Lvl := 0; --  Access level
--- If_Exp_Res := Exp;
---   in If_Exp_Res end;},
--- Lvl,
--- ...
--- )
---end;
-
-Res  := Make_Temporary (Loc, 'R');
-Typ  := Etype (Call_Node);
-Temp := Relocate_Node (Call_Node);
-
---  Perform the rewrite with the dummy
-
-Rewrite (Call_Node,
-
-  Make_Expression_With_Actions (Loc,
-Expression => New_Occurrence_Of (Res, Loc),
-Actions=> New_List (
-  Decl,
-
-  Make_Object_Declaration (Loc,
-Defining_Identifi

[Ada] Premature finalization on build in place return and case expression

[Pierre-Marie de Rodat]

Is_Finalizable_Transient does not properly handle the case of a return
containing an N_Expression_With_Actions (e.g. a case expression),
causing a premature finalization of the return object.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_util.adb (Is_Finalizable_Transient): Take into account return
statements containing N_Expression_With_Actions. Also clean up a
condition to make it more readable.
* exp_ch6.adb: Fix typo.diff --git a/gcc/ada/exp_ch6.adb b/gcc/ada/exp_ch6.adb
--- a/gcc/ada/exp_ch6.adb
+++ b/gcc/ada/exp_ch6.adb
@@ -5499,7 +5499,7 @@ package body Exp_Ch6 is
  (Expression (Original_Node (Ret_Obj_Decl)))
 
   --  It is a BIP object declaration that displaces the pointer
-  --  to the object to reference a convered interface type.
+  --  to the object to reference a converted interface type.
 
   or else
 Present (Unqual_BIP_Iface_Function_Call


diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb
--- a/gcc/ada/exp_util.adb
+++ b/gcc/ada/exp_util.adb
@@ -7854,6 +7854,10 @@ package body Exp_Util is
   --  is in the process of being iterated in the statement list starting
   --  from First_Stmt.
 
+  function Is_Part_Of_BIP_Return_Statement (N : Node_Id) return Boolean;
+  --  Return True if N is directly part of a build-in-place return
+  --  statement.
+
   ---
   -- Initialized_By_Access --
   ---
@@ -8183,6 +8187,35 @@ package body Exp_Util is
  return False;
   end Is_Iterated_Container;
 
+  -
+  -- Is_Part_Of_BIP_Return_Statement --
+  -
+
+  function Is_Part_Of_BIP_Return_Statement (N : Node_Id) return Boolean is
+ Subp: constant Entity_Id := Current_Subprogram;
+ Context : Node_Id;
+  begin
+ --  First check if N is part of a BIP function
+
+ if No (Subp)
+   or else not Is_Build_In_Place_Function (Subp)
+ then
+return False;
+ end if;
+
+ --  Then check whether N is a complete part of a return statement
+ --  Should we consider other node kinds to go up the tree???
+
+ Context := N;
+ loop
+case Nkind (Context) is
+   when N_Expression_With_Actions => Context := Parent (Context);
+   when N_Simple_Return_Statement => return True;
+   when others=> return False;
+end case;
+ end loop;
+  end Is_Part_Of_BIP_Return_Statement;
+
   --  Local variables
 
   Desig : Entity_Id := Obj_Typ;
@@ -8201,6 +8234,7 @@ package body Exp_Util is
   and then Needs_Finalization (Desig)
   and then Requires_Transient_Scope (Desig)
   and then Nkind (Rel_Node) /= N_Simple_Return_Statement
+  and then not Is_Part_Of_BIP_Return_Statement (Rel_Node)
 
   --  Do not consider a transient object that was already processed
 
@@ -8220,9 +8254,8 @@ package body Exp_Util is
   --  initialized by a function that returns a pointer or acts as a
   --  renaming of another pointer.
 
-  and then
-(not Is_Access_Type (Obj_Typ)
-   or else not Initialized_By_Access (Obj_Id))
+  and then not
+(Is_Access_Type (Obj_Typ) and then Initialized_By_Access (Obj_Id))
 
   --  Do not consider transient objects which act as indirect aliases
   --  of build-in-place function results.

[Ada] Wrong resolution of universal_access = operators

[Pierre-Marie de Rodat]

The universal_access = and /= operators were not properly taken into
account in all cases.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_type.adb (Add_One_Interp.Is_Universal_Operation): Account
for universal_access = operator.
(Disambiguate): Take into account preference on universal_access
= operator when relevant.
(Disambiguate.Is_User_Defined_Anonymous_Access_Equality): New.diff --git a/gcc/ada/sem_type.adb b/gcc/ada/sem_type.adb
--- a/gcc/ada/sem_type.adb
+++ b/gcc/ada/sem_type.adb
@@ -326,8 +326,19 @@ package body Sem_Type is
 return False;
 
  elsif Nkind (N) in N_Binary_Op then
-return Present (Universal_Interpretation (Left_Opnd (N)))
-  and then Present (Universal_Interpretation (Right_Opnd (N)));
+if Present (Universal_Interpretation (Left_Opnd (N)))
+  and then Present (Universal_Interpretation (Right_Opnd (N)))
+then
+   return True;
+elsif Nkind (N) in N_Op_Eq | N_Op_Ne
+  and then
+(Is_Anonymous_Access_Type (Etype (Left_Opnd (N)))
+  or else Is_Anonymous_Access_Type (Etype (Right_Opnd (N
+then
+   return True;
+else
+   return False;
+end if;
 
  elsif Nkind (N) in N_Unary_Op then
 return Present (Universal_Interpretation (Right_Opnd (N)));
@@ -1338,6 +1349,13 @@ package body Sem_Type is
   --  for special handling of expressions with universal operands, see
   --  comments to Has_Abstract_Interpretation below.
 
+  function Is_User_Defined_Anonymous_Access_Equality
+(User_Subp, Predef_Subp : Entity_Id) return Boolean;
+  --  Check for Ada 2005, AI-020: If the context involves an anonymous
+  --  access operand, recognize a user-defined equality (User_Subp) with
+  --  the proper signature, declared in the same declarative list as the
+  --  type and not hiding a predefined equality Predef_Subp.
+
   ---
   -- Inherited_From_Actual --
   ---
@@ -1743,6 +1761,37 @@ package body Sem_Type is
  end if;
   end Standard_Operator;
 
+  ---
+  -- Is_User_Defined_Anonymous_Access_Equality --
+  ---
+
+  function Is_User_Defined_Anonymous_Access_Equality
+(User_Subp, Predef_Subp : Entity_Id) return Boolean is
+  begin
+ return Present (User_Subp)
+
+ --  Check for Ada 2005 and use of anonymous access
+
+   and then Ada_Version >= Ada_2005
+   and then Etype (User_Subp) = Standard_Boolean
+   and then Is_Anonymous_Access_Type (Operand_Type)
+
+ --  This check is only relevant if User_Subp is visible and not in
+ --  an instance
+
+   and then (In_Open_Scopes (Scope (User_Subp))
+  or else Is_Potentially_Use_Visible (User_Subp))
+   and then not In_Instance
+   and then not Hides_Op (User_Subp, Predef_Subp)
+
+ --  Is User_Subp declared in the same declarative list as the type?
+
+   and then
+ In_Same_Declaration_List
+   (Designated_Type (Operand_Type),
+Unit_Declaration_Node (User_Subp));
+  end Is_User_Defined_Anonymous_Access_Equality;
+
--  Start of processing for Disambiguate
 
begin
@@ -1856,17 +1905,41 @@ package body Sem_Type is
   Arg2 := Next_Actual (Arg1);
end if;
 
-   if Present (Arg2)
- and then Present (Universal_Interpretation (Arg1))
- and then Universal_Interpretation (Arg2) =
-  Universal_Interpretation (Arg1)
-   then
-  Get_First_Interp (N, I, It);
-  while Scope (It.Nam) /= Standard_Standard loop
- Get_Next_Interp (I, It);
-  end loop;
+   if Present (Arg2) then
+  if Ekind (Nam1) = E_Operator then
+ Predef_Subp := Nam1;
+ User_Subp   := Nam2;
+  elsif Ekind (Nam2) = E_Operator then
+ Predef_Subp := Nam2;
+ User_Subp   := Nam1;
+  else
+ Predef_Subp := Empty;
+ User_Subp   := Empty;
+  end if;
 
-  return It;
+  --  Take into account universal interpretation as well as
+  --  universal_access equality, as long as AI05-0020 does not
+  --  trigger.
+
+  if (Present (Universal_Interpretation (Arg1))
+   and then Universal_Interpretation (Arg2) =
+Universal_Interpretation (Arg1))
+or else
+  

[Ada] Fix String_Literal aspect spec checking problem for scalars.

[Pierre-Marie de Rodat]

Result type compatibility checking for the specified String_Literal
function of a type was too strict, causing valid aspect specifications
to be incorrectly rejected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch13.adb (Validate_Literal_Aspect): Call to Base_Type
needed in order to correctly check result type of String_Literal
function when the first named subtype differs from the base
type (e.g.:
type T is range 1 .. 10 with String_Literal => ... ;
).diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb
--- a/gcc/ada/sem_ch13.adb
+++ b/gcc/ada/sem_ch13.adb
@@ -16228,7 +16228,7 @@ package body Sem_Ch13 is
  Is_Match := False;
 
  if Ekind (It.Nam) = E_Function
-   and then Base_Type (Etype (It.Nam)) = Typ
+   and then Base_Type (Etype (It.Nam)) = Base_Type (Typ)
  then
 declare
Params : constant List_Id :=

[Ada] Fix internal error on multiple nested instantiations

[Pierre-Marie de Rodat]

This prevents the compiler from placing the freeze node of a package
instance, used as actual parameter in a second instantiation, after this
second instance, thus triggering an internal error later.  The freezing
code in Analyze_Associations already knows how to deal with this case,
but the mechanism was incorrectly disabled in this specific case.

The change contains a pair of secondary fixes for the placement of the
freeze node of instances relatively to that of their parent instance:
the special delayed placement must be used only when the Sloc of the
parent instance is strictly greater than that of the instance.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch12.adb (Analyze_Associations) : Test
that the instance is in a statement sequence instead of local scope.
(Freeze_Subprogram_Body): Use the special delayed placement with
regard to the parent instance only if its Sloc is strictly greater.
(Install_Body): Likewise.diff --git a/gcc/ada/sem_ch12.adb b/gcc/ada/sem_ch12.adb
--- a/gcc/ada/sem_ch12.adb
+++ b/gcc/ada/sem_ch12.adb
@@ -1998,7 +1998,7 @@ package body Sem_Ch12 is
 Gen_Par : Entity_Id;
 
 Needs_Freezing : Boolean;
-S  : Entity_Id;
+P  : Node_Id;
 
 procedure Check_Generic_Parent;
 --  The actual may be an instantiation of a unit
@@ -2102,18 +2102,15 @@ package body Sem_Ch12 is
 
Needs_Freezing := True;
 
-   S := Current_Scope;
-   while Present (S) loop
-  if Ekind (S) in E_Block
-| E_Function
-| E_Loop
-| E_Procedure
+   P := Parent (I_Node);
+   while Nkind (P) /= N_Compilation_Unit loop
+  if Nkind (P) = N_Handled_Sequence_Of_Statements
   then
  Needs_Freezing := False;
  exit;
   end if;
 
-  S := Scope (S);
+  P := Parent (P);
end loop;
 
if Needs_Freezing then
@@ -9084,7 +9081,7 @@ package body Sem_Ch12 is
  --
  --procedure P ...  --  this body freezes Parent_Inst
  --
- --package Inst is new ...
+ --procedure Inst is new ...
  --
  --  In this particular scenario, the freeze node for Inst must be
  --  inserted in the same manner as that of Parent_Inst - before the
@@ -9097,7 +9094,7 @@ package body Sem_Ch12 is
 
  elsif List_Containing (Get_Unit_Instantiation_Node (Par)) =
List_Containing (Inst_Node)
-   and then Sloc (Freeze_Node (Par)) < Sloc (Inst_Node)
+   and then Sloc (Freeze_Node (Par)) <= Sloc (Inst_Node)
  then
 Insert_Freeze_Node_For_Instance (Inst_Node, F_Node);
 
@@ -9938,7 +9935,7 @@ package body Sem_Ch12 is
 
if Parent (List_Containing (Get_Unit_Instantiation_Node (Par)))
 = Parent (List_Containing (N))
- and then Sloc (Freeze_Node (Par)) < Sloc (N)
+ and then Sloc (Freeze_Node (Par)) <= Sloc (N)
then
   Insert_Freeze_Node_For_Instance (N, F_Node);
else

[Ada] Handle correctly current instance of PO in local subprogram Global

[Pierre-Marie de Rodat]

SPARK defines the current instance of a protected object as non-volatile
for internal calls, which allows to use it in the Global contract of a
local non-volatile function. This was not handled correctly, now fixed.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_prag.adb (Analyze_Global_Item): Handle specially the
current instance of a PO.
* sem_util.ads (Is_Effectively_Volatile,
Is_Effectively_Volatile_For_Reading): Add parameter
Ignore_Protected.
* sem_util.adb (Is_Effectively_Volatile,
Is_Effectively_Volatile_For_Reading): Add parameter
Ignore_Protected to compute the query results ignoring protected
objects/types.
(Is_Effectively_Volatile_Object,
Is_Effectively_Volatile_Object_For_Reading): Adapt to new
signature.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -2476,11 +2476,22 @@ package body Sem_Prag is
  and then Ekind (Item_Id) = E_Variable
  and then Is_Effectively_Volatile_For_Reading (Item_Id)
then
+  --  The current instance of a protected unit is not an
+  --  effectively volatile object, unless the protected unit
+  --  is already volatile for another reason (SPARK RM 7.1.2).
+
+  if Is_Single_Protected_Object (Item_Id)
+and then Is_CCT_Instance (Etype (Item_Id), Spec_Id)
+and then not Is_Effectively_Volatile_For_Reading
+  (Item_Id, Ignore_Protected => True)
+  then
+ null;
+
   --  An effectively volatile object for reading cannot appear
   --  as a global item of a nonvolatile function (SPARK RM
   --  7.1.3(8)).
 
-  if Ekind (Spec_Id) in E_Function | E_Generic_Function
+  elsif Ekind (Spec_Id) in E_Function | E_Generic_Function
 and then not Is_Volatile_Function (Spec_Id)
   then
  Error_Msg_NE


diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -16582,7 +16582,9 @@ package body Sem_Util is
-- Is_Effectively_Volatile --
-
 
-   function Is_Effectively_Volatile (Id : Entity_Id) return Boolean is
+   function Is_Effectively_Volatile
+ (Id   : Entity_Id;
+  Ignore_Protected : Boolean := False) return Boolean is
begin
   if Is_Type (Id) then
 
@@ -16610,15 +16612,16 @@ package body Sem_Util is
   --  Test for presence of ancestor, as the full view of a
   --  private type may be missing in case of error.
 
-  return
-Present (Anc)
-  and then Is_Effectively_Volatile (Component_Type (Anc));
+  return Present (Anc)
+and then Is_Effectively_Volatile
+  (Component_Type (Anc), Ignore_Protected);
end;
 end if;
 
- --  A protected type is always volatile
+ --  A protected type is always volatile unless Ignore_Protected is
+ --  True.
 
- elsif Is_Protected_Type (Id) then
+ elsif Is_Protected_Type (Id) and then not Ignore_Protected then
 return True;
 
  --  A descendant of Ada.Synchronous_Task_Control.Suspension_Object is
@@ -16644,7 +16647,7 @@ package body Sem_Util is
 and then not
   (Ekind (Id) = E_Variable and then No_Caching_Enabled (Id)))
  or else Has_Volatile_Components (Id)
- or else Is_Effectively_Volatile (Etype (Id));
+ or else Is_Effectively_Volatile (Etype (Id), Ignore_Protected);
   end if;
end Is_Effectively_Volatile;
 
@@ -16653,15 +16656,19 @@ package body Sem_Util is
-
 
function Is_Effectively_Volatile_For_Reading
- (Id : Entity_Id) return Boolean
+ (Id   : Entity_Id;
+  Ignore_Protected : Boolean := False) return Boolean
is
begin
-  --  A concurrent type is effectively volatile for reading
+  --  A concurrent type is effectively volatile for reading, except for a
+  --  protected type when Ignore_Protected is True.
 
-  if Is_Concurrent_Type (Id) then
+  if Is_Task_Type (Id)
+or else (Is_Protected_Type (Id) and then not Ignore_Protected)
+  then
  return True;
 
-  elsif Is_Effectively_Volatile (Id) then
+  elsif Is_Effectively_Volatile (Id, Ignore_Protected) then
 
 --  Other volatile types and objects are effectively volatile for
 --  reading when they have property Async_Writers or Effective_Reads
@@ -16689,10 +16696,9 @@ package body Sem_Util is
--  Test for presence of ancestor,

[Ada] Fix crash in GNATprove on inlined subprogram in default expression

[Pierre-Marie de Rodat]

The special inlining in GNATprove mode should recognize specially calls
inside default expressions, which cannot be inlined. This was not done
for calls in default expressions for discriminants, because the right
analysis context was not set in that case. Now fixed.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch3.adb (Process_Discriminants): Correctly set right
context for analyzing default value of discriminant.diff --git a/gcc/ada/sem_ch3.adb b/gcc/ada/sem_ch3.adb
--- a/gcc/ada/sem_ch3.adb
+++ b/gcc/ada/sem_ch3.adb
@@ -20093,7 +20093,7 @@ package body Sem_Ch3 is
  --  Per-Object Expressions" in spec of package Sem).
 
  if Present (Expression (Discr)) then
-Preanalyze_Spec_Expression (Expression (Discr), Discr_Type);
+Preanalyze_Default_Expression (Expression (Discr), Discr_Type);
 
 --  Legaity checks
 

[Ada] Accept local objects in the prefix of attribute Loop_Entry

[Pierre-Marie de Rodat]

Fix implementation of SPARK RM 5.5.3.1(5) by accepting objects declared
within the prefix of attribute Loop_Variant itself. This previous code
didn't implement the "... but not within the prefix itself" part of the
rule.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_attr.adb (Declared_Within): Return True for objects
declared within the attribute Loop_Entry prefix itself.diff --git a/gcc/ada/sem_attr.adb b/gcc/ada/sem_attr.adb
--- a/gcc/ada/sem_attr.adb
+++ b/gcc/ada/sem_attr.adb
@@ -4375,7 +4375,8 @@ package body Sem_Attr is
 --  within the related loop.
 
 function Declared_Within (Nod : Node_Id) return Boolean;
---  Determine whether Nod appears in the subtree of Loop_Decl
+--  Determine whether Nod appears in the subtree of Loop_Decl but
+--  not within the subtree of the prefix P itself.
 
 -
 -- Check_Reference --
@@ -4411,6 +4412,9 @@ package body Sem_Attr is
   if Stmt = Loop_Decl then
  return True;
 
+  elsif Stmt = P then
+ return False;
+
   --  Prevent the search from going too far
 
   elsif Is_Body_Or_Package_Declaration (Stmt) then

[Ada] Implement No_Unrecognized_{Aspects,Pragmas} restrictions

[Pierre-Marie de Rodat]

This commit implements the No_Unrecognized_Aspects and
No_Unrecognized_Pragmas restrictions described in AI12-0389.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/s-rident.ads (System.Rident): Register new restriction
IDs.
* par-ch13.adb (Get_Aspect_Specifications): Add restriction check.
* par-prag.adb (Process_Restrictions_Or_Restriction_Warnings):
Register No_Unrecognized_Aspects restriction.
* sem_prag.adb (Analyze_Pragma): Add restriction check.
* snames.ads-tmpl: Create restriction names.diff --git a/gcc/ada/libgnat/s-rident.ads b/gcc/ada/libgnat/s-rident.ads
--- a/gcc/ada/libgnat/s-rident.ads
+++ b/gcc/ada/libgnat/s-rident.ads
@@ -184,6 +184,8 @@ package System.Rident is
   No_Implicit_Loops, -- GNAT
   No_Elaboration_Code,   -- GNAT
   No_Obsolescent_Features,   -- Ada 2005 AI-368
+  No_Unrecognized_Aspects,   -- AI12-0389-1/02
+  No_Unrecognized_Pragmas,   -- AI12-0389-1/02
   No_Wide_Characters,-- GNAT
   Static_Dispatch_Tables,-- GNAT
   SPARK_05,  -- GNAT


diff --git a/gcc/ada/par-ch13.adb b/gcc/ada/par-ch13.adb
--- a/gcc/ada/par-ch13.adb
+++ b/gcc/ada/par-ch13.adb
@@ -23,6 +23,8 @@
 --  --
 --
 
+with Rident;use Rident;
+with Restrict; use Restrict;
 pragma Style_Checks (All_Checks);
 --  Turn off subprogram body ordering check. Subprograms are in order
 --  by RM section rather than alphabetical
@@ -264,20 +266,28 @@ package body Ch13 is
  --  The aspect mark is not recognized
 
  if A_Id = No_Aspect then
-Error_Msg_Warn := not Debug_Flag_2;
-Error_Msg_N ("<<& is not a valid aspect identifier", Token_Node);
-OK := False;
-
---  Check bad spelling
-
-for J in Aspect_Id_Exclude_No_Aspect loop
-   if Is_Bad_Spelling_Of (Token_Name, Aspect_Names (J)) then
-  Error_Msg_Name_1 := Aspect_Names (J);
-  Error_Msg_N -- CODEFIX
-("\<
+  Set_Restriction
+ (No_Unrecognized_Aspects,
+  Pragma_Node,
+  Prag_Id = Pragma_Restriction_Warnings);
+
when others =>
   null;
 end case;


diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -11364,19 +11364,26 @@ package body Sem_Prag is
   --  Deal with unrecognized pragma
 
   if not Is_Pragma_Name (Pname) then
- if Warn_On_Unrecognized_Pragma then
-Error_Msg_Name_1 := Pname;
-Error_Msg_N ("?g?unrecognized pragma%!", Pragma_Identifier (N));
-
-for PN in First_Pragma_Name .. Last_Pragma_Name loop
-   if Is_Bad_Spelling_Of (Pname, PN) then
-  Error_Msg_Name_1 := PN;
-  Error_Msg_N -- CODEFIX
-("\?g?possible misspelling of %!", Pragma_Identifier (N));
-  exit;
-   end if;
-end loop;
- end if;
+ declare
+Msg_Issued : Boolean := False;
+ begin
+Check_Restriction
+  (Msg_Issued, No_Unrecognized_Pragmas, Pragma_Identifier (N));
+if not Msg_Issued and then Warn_On_Unrecognized_Pragma then
+   Error_Msg_Name_1 := Pname;
+   Error_Msg_N ("?g?unrecognized pragma%!", Pragma_Identifier (N));
+
+   for PN in First_Pragma_Name .. Last_Pragma_Name loop
+  if Is_Bad_Spelling_Of (Pname, PN) then
+ Error_Msg_Name_1 := PN;
+ Error_Msg_N -- CODEFIX
+   ("\?g?possible misspelling of %!",
+Pragma_Identifier (N));
+ exit;
+  end if;
+   end loop;
+end if;
+ end;
 
  return;
   end if;


diff --git a/gcc/ada/snames.ads-tmpl b/gcc/ada/snames.ads-tmpl
--- a/gcc/ada/snames.ads-tmpl
+++ b/gcc/ada/snames.ads-tmpl
@@ -839,6 +839,8 @@ package Snames is
Name_No_Use_Of_Entity   : constant Name_Id := N + $;
Name_No_Use_Of_Pragma   : constant Name_Id := N + $;
Name_No_Unroll  : constant Name_Id := N + $;
+   Name_No_Unrecognized_Aspects: constant Name_Id := N + $;
+   Name_No_Unrecognized_Pragmas: constant Name_Id := N + $;
Name_No_Vector  : constant Name_Id := N + $;
Name_Nominal: constant Name_Id := N + $;
Name_Non_Volatile   : constant Name_Id := N + $;

[Ada] AI12-0394 Named Numbers and User-Defined Numeric Literals

[Pierre-Marie de Rodat]

Integer named numbers may now be used with types that have an
Integer_Literal aspect.  Real named numbers may be used with types that
have a Real_Literal aspect with an overloading that takes two strings.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_ch13.adb (Validate_Literal_Aspect): Add support for named
numbers and in particular overload of the Real_Literal function.
* sem_res.adb (Resolve): Add support for named numbers in
Real_Literal and Integer_Literal resolution.
* einfo.adb, einfo.ads (Related_Expression,
Set_Related_Expression): Allow E_Function.
* uintp.ads (UI_Image_Max): Bump size of buffer to avoid loosing
precision.
* sem_eval.adb: Fix typo in comment.
* libgnat/a-nbnbin.adb, libgnat/a-nbnbin.ads (From_String):
Return a Valid_Big_Integer.
* libgnat/a-nbnbre.adb, libgnat/a-nbnbre.ads (From_String): New
variant taking two strings. Return a Valid_Big_Real.diff --git a/gcc/ada/einfo.adb b/gcc/ada/einfo.adb
--- a/gcc/ada/einfo.adb
+++ b/gcc/ada/einfo.adb
@@ -3202,7 +3202,8 @@ package body Einfo is
 
function Related_Expression (Id : E) return N is
begin
-  pragma Assert (Ekind (Id) in Type_Kind | E_Constant | E_Variable);
+  pragma Assert
+(Ekind (Id) in Type_Kind | E_Constant | E_Variable | E_Function);
   return Node24 (Id);
end Related_Expression;
 
@@ -6478,7 +6479,8 @@ package body Einfo is
procedure Set_Related_Expression (Id : E; V : N) is
begin
   pragma Assert
-(Ekind (Id) in Type_Kind | E_Constant | E_Variable | E_Void);
+(Ekind (Id) in
+   Type_Kind | E_Constant | E_Variable | E_Function | E_Void);
   Set_Node24 (Id, V);
end Set_Related_Expression;
 


diff --git a/gcc/ada/einfo.ads b/gcc/ada/einfo.ads
--- a/gcc/ada/einfo.ads
+++ b/gcc/ada/einfo.ads
@@ -4115,14 +4115,16 @@ package Einfo is
 --   only for type-related error messages.
 
 --Related_Expression (Node24)
---   Defined in variables and types. When Set for internally generated
---   entities, it may be used to denote the source expression whose
---   elaboration created the variable declaration. If set, it is used
+--   Defined in variables, types and functions. When Set for internally
+--   generated entities, it may be used to denote the source expression
+--   whose elaboration created the variable declaration. If set, it is used
 --   for generating clearer messages from CodePeer. It is used on source
 --   entities that are variables in iterator specifications, to provide
 --   a link to the container that is the domain of iteration. This allows
 --   for better cross-reference information when the loop modifies elements
 --   of the container, and suppresses spurious warnings.
+--   Finally this node is used on functions specified via the Real_Literal
+--   aspect, to denote the 2-parameter overloading, if found.
 --
 --   Shouldn't it also be used for the same purpose in errout? It seems
 --   odd to have two mechanisms here???


diff --git a/gcc/ada/libgnat/a-nbnbin.adb b/gcc/ada/libgnat/a-nbnbin.adb
--- a/gcc/ada/libgnat/a-nbnbin.adb
+++ b/gcc/ada/libgnat/a-nbnbin.adb
@@ -235,7 +235,7 @@ package body Ada.Numerics.Big_Numbers.Big_Integers is
-- From_String --
-
 
-   function From_String (Arg : String) return Big_Integer is
+   function From_String (Arg : String) return Valid_Big_Integer is
   procedure Scan_Decimal
 (Arg : String; J : in out Natural; Result : out Big_Integer);
   --  Scan decimal value starting at Arg (J). Store value in Result if


diff --git a/gcc/ada/libgnat/a-nbnbin.ads b/gcc/ada/libgnat/a-nbnbin.ads
--- a/gcc/ada/libgnat/a-nbnbin.ads
+++ b/gcc/ada/libgnat/a-nbnbin.ads
@@ -113,7 +113,7 @@ is
  Post   => To_String'Result'First = 1,
  Global => null;
 
-   function From_String (Arg : String) return Big_Integer
+   function From_String (Arg : String) return Valid_Big_Integer
  with Global => null;
 
procedure Put_Image (S : in out Sink'Class; V : Big_Integer);


diff --git a/gcc/ada/libgnat/a-nbnbre.adb b/gcc/ada/libgnat/a-nbnbre.adb
--- a/gcc/ada/libgnat/a-nbnbre.adb
+++ b/gcc/ada/libgnat/a-nbnbre.adb
@@ -318,7 +318,7 @@ package body Ada.Numerics.Big_Numbers.Big_Reals is
-- From_String --
-
 
-   function From_String (Arg : String) return Big_Real is
+   function From_String (Arg : String) return Valid_Big_Real is
   Ten   : constant Big_Integer := To_Big_Integer (10);
   Frac  : Big_Integer;
   Exp   : Integer := 0;
@@ -373,6 +373,13 @@ package body Ada.Numerics.Big_Numbers.Big_Reals is
   end;
end From_String;
 
+   function From_String
+ (Numerator, Denominator : String) return Valid_Big_Real is
+   begin
+  return Big_Integers.From_String (Numerator) /
+Big_Integers.From_String (Denominator);
+   end From_String;
+

[Ada] Small cleanup in the Ada.Text_IO hierarchy

[Pierre-Marie de Rodat]

This removes an implementation subtype declared in the Ada.Text_IO
hierarchy that no longer seems to serve any useful purpose.

No functional changes.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* libgnat/a-wtdeio.adb (TFT): Delete and adjust throughout.
* libgnat/a-wtenau.adb (TFT): Likewise.
* libgnat/a-wtfiio.adb (TFT): Likewise.
* libgnat/a-wtflio.adb (TFT): Likewise.
* libgnat/a-wtinio.adb (TFT): Likewise.
* libgnat/a-wtinio__128.adb (TFT): Likewise.
* libgnat/a-wtmoio.adb (TFT): Likewise.
* libgnat/a-wtmoio__128.adb (TFT): Likewise.
* libgnat/a-ztdeio.adb (TFT): Likewise.
* libgnat/a-ztenau.adb (TFT): Likewise.
* libgnat/a-ztfiio.adb (TFT): Likewise.
* libgnat/a-ztflio.adb (TFT): Likewise.
* libgnat/a-ztinio.adb (TFT): Likewise.
* libgnat/a-ztinio__128.adb (TFT): Likewise.
* libgnat/a-ztmoio.adb (TFT): Likewise.
* libgnat/a-ztmoio__128.adb (TFT): Likewise.diff --git a/gcc/ada/libgnat/a-wtdeio.adb b/gcc/ada/libgnat/a-wtdeio.adb
--- a/gcc/ada/libgnat/a-wtdeio.adb
+++ b/gcc/ada/libgnat/a-wtdeio.adb
@@ -36,9 +36,6 @@ with System.WCh_WtS; use System.WCh_WtS;
 
 package body Ada.Wide_Text_IO.Decimal_IO is
 
-   subtype TFT is Ada.Wide_Text_IO.File_Type;
-   --  File type required for calls to routines in Aux
-
package Aux renames Ada.Wide_Text_IO.Decimal_Aux;
 
Scale : constant Integer := Num'Scale;
@@ -54,9 +51,9 @@ package body Ada.Wide_Text_IO.Decimal_IO is
is
begin
   if Num'Size > Integer'Size then
- Item := Num'Fixed_Value (Aux.Get_LLD (TFT (File), Width, Scale));
+ Item := Num'Fixed_Value (Aux.Get_LLD (File, Width, Scale));
   else
- Item := Num'Fixed_Value (Aux.Get_Dec (TFT (File), Width, Scale));
+ Item := Num'Fixed_Value (Aux.Get_Dec (File, Width, Scale));
   end if;
exception
   when Constraint_Error => raise Data_Error;
@@ -112,11 +109,11 @@ package body Ada.Wide_Text_IO.Decimal_IO is
begin
   if Num'Size > Integer'Size then
  Aux.Put_LLD
-   (TFT (File), Long_Long_Integer'Integer_Value (Item),
+   (File, Long_Long_Integer'Integer_Value (Item),
 Fore, Aft, Exp, Scale);
   else
  Aux.Put_Dec
-   (TFT (File), Integer'Integer_Value (Item), Fore, Aft, Exp, Scale);
+   (File, Integer'Integer_Value (Item), Fore, Aft, Exp, Scale);
   end if;
end Put;
 


diff --git a/gcc/ada/libgnat/a-wtenau.adb b/gcc/ada/libgnat/a-wtenau.adb
--- a/gcc/ada/libgnat/a-wtenau.adb
+++ b/gcc/ada/libgnat/a-wtenau.adb
@@ -36,9 +36,6 @@ with System.WCh_Con;   use System.WCh_Con;
 
 package body Ada.Wide_Text_IO.Enumeration_Aux is
 
-   subtype TFT is Ada.Wide_Text_IO.File_Type;
-   --  File type required for calls to routines in Aux
-
---
-- Local Subprograms --
---
@@ -69,8 +66,8 @@ package body Ada.Wide_Text_IO.Enumeration_Aux is
 
begin
   Buflen := 0;
-  Load_Skip (TFT (File));
-  ch := Nextc (TFT (File));
+  Load_Skip (File);
+  ch := Nextc (File);
 
   --  Character literal case. If the initial character is a quote, then
   --  we read as far as we can without backup (see ACVC test CE3905L)
@@ -79,7 +76,7 @@ package body Ada.Wide_Text_IO.Enumeration_Aux is
  Get (File, WC);
  Store_Char (WC, Buf, Buflen);
 
- ch := Nextc (TFT (File));
+ ch := Nextc (File);
 
  if ch = LM or else ch = EOF then
 return;
@@ -88,7 +85,7 @@ package body Ada.Wide_Text_IO.Enumeration_Aux is
  Get (File, WC);
  Store_Char (WC, Buf, Buflen);
 
- ch := Nextc (TFT (File));
+ ch := Nextc (File);
 
  if ch /= Character'Pos (''') then
 return;
@@ -117,7 +114,7 @@ package body Ada.Wide_Text_IO.Enumeration_Aux is
 Get (File, WC);
 Store_Char (WC, Buf, Buflen);
 
-ch := Nextc (TFT (File));
+ch := Nextc (File);
 
 exit when ch = EOF;
 
@@ -155,7 +152,7 @@ package body Ada.Wide_Text_IO.Enumeration_Aux is
 Integer'Max (Integer (Width), Item'Length);
 
begin
-  Check_On_One_Line (TFT (File), Actual_Width);
+  Check_On_One_Line (File, Actual_Width);
 
   if Set = Lower_Case and then Item (Item'First) /= ''' then
  declare


diff --git a/gcc/ada/libgnat/a-wtfiio.adb b/gcc/ada/libgnat/a-wtfiio.adb
--- a/gcc/ada/libgnat/a-wtfiio.adb
+++ b/gcc/ada/libgnat/a-wtfiio.adb
@@ -35,9 +35,6 @@ with System.WCh_WtS; use System.WCh_WtS;
 
 package body Ada.Wide_Text_IO.Fixed_IO is
 
-   subtype TFT is Ada.Wide_Text_IO.File_Type;
-   --  File type required for calls to routines in Aux
-
package Aux renames Ada.Wide_Text_IO.Float_Aux;
 
-
@@ -50,7 +47,7 @@ package body Ada.Wide_Text_IO.Fixed_IO is
   Width : Field := 0)
is
begin
-  Aux.Get (TFT (File), Long_Long_Float 

[Ada] Recognize delta and extension aggregates as objects

[Pierre-Marie de Rodat]

Ada RM 3.3 says that "aggregate" is an object, but GNAT represents
"aggregate" either as N_Aggregate, N_Delta_Aggregate or
N_Extension_Aggregate.

With this patch both extension and delta aggregates are accepted where
object is required, e.g. as a prefix of attribute Size.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_util.adb (Is_Object_Reference): Delta and extension
aggregates are objects.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -18324,7 +18324,10 @@ package body Sem_Util is
 
 --  In Ada 95 an aggregate is an object reference
 
-when N_Aggregate =>
+when N_Aggregate
+   | N_Delta_Aggregate
+   | N_Extension_Aggregate
+=>
return Ada_Version >= Ada_95;
 
 --  A string literal is not an object reference, but it might come

[Ada] Compiler crash on assertion pragma in ghost region

[Pierre-Marie de Rodat]

This patch fixes an error in the compiler whereby an assertion pragma
within a ghost context whose expression causes the freezing of a
non-ghost type causes the compiler to crash during compilation when
ghost mode is disabled.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_prag.adb (Analyze_Pragma): Mark relevant pragmas as ghost
when they are within a ghost region.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -11437,6 +11437,12 @@ package body Sem_Prag is
  end if;
   end if;
 
+  --  Mark assertion pragmas as Ghost depending on their enclosing context
+
+  if Assertion_Expression_Pragma (Prag_Id) then
+ Mark_Ghost_Pragma (N, Current_Scope);
+  end if;
+
   --  Preset arguments
 
   Arg_Count := 0;

[Ada] Fix inconsistent parameter of SPARK_Msg_NE

[Pierre-Marie de Rodat]

All calls to SPARK_Msg_NE except one were taking an entity as its second
parameter; this patch does the same for one call that took an
identifier.

Code cleanup only; behaviour is unaffected, because both entity and
identifier works in the same when given to SPARK_Msg_NE routine.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* sem_prag.adb (Analyze_Global_Item): Call SPARK_Msg_NE with the
entity, not with its identifier.diff --git a/gcc/ada/sem_prag.adb b/gcc/ada/sem_prag.adb
--- a/gcc/ada/sem_prag.adb
+++ b/gcc/ada/sem_prag.adb
@@ -2385,7 +2385,7 @@ package body Sem_Prag is
 
   if Ekind (Item_Id) in Named_Kind then
  SPARK_Msg_NE
-   ("\named number & is not an object", Item, Item);
+   ("\named number & is not an object", Item, Item_Id);
   end if;
 
   return;

[Ada] Replace chained if-then-elsif with case stmt for attribute ids

[Pierre-Marie de Rodat]

Handle attribute ids in SPARK-specific expansion with a case statement,
just like they are handled in ordinary expansion. Code cleanup only, in
preparation for fix related to attribute Constrained; semantics is
unaffected.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* exp_spark.adb (Expand_SPARK_N_Attribute_Reference): Rewrite
with a CASE statement.diff --git a/gcc/ada/exp_spark.adb b/gcc/ada/exp_spark.adb
--- a/gcc/ada/exp_spark.adb
+++ b/gcc/ada/exp_spark.adb
@@ -374,101 +374,105 @@ package body Exp_SPARK is
   Expr: Node_Id;
 
begin
-  if Attr_Id = Attribute_To_Address then
+  case Attr_Id is
+ when Attribute_To_Address =>
 
- --  Extract and convert argument to expected type for call
+--  Extract and convert argument to expected type for call
 
- Expr :=
-   Make_Type_Conversion (Loc,
- Subtype_Mark =>
-   New_Occurrence_Of (RTE (RE_Integer_Address), Loc),
- Expression   => Relocate_Node (First (Expressions (N;
+Expr :=
+  Make_Type_Conversion (Loc,
+Subtype_Mark =>
+  New_Occurrence_Of (RTE (RE_Integer_Address), Loc),
+Expression   => Relocate_Node (First (Expressions (N;
 
- --  Replace attribute reference with call
+--  Replace attribute reference with call
 
- Rewrite (N,
-   Make_Function_Call (Loc,
- Name   =>
-   New_Occurrence_Of (RTE (RE_To_Address), Loc),
- Parameter_Associations => New_List (Expr)));
- Analyze_And_Resolve (N, Typ);
-
-  elsif Attr_Id = Attribute_Object_Size
-or else Attr_Id = Attribute_Size
-or else Attr_Id = Attribute_Value_Size
-or else Attr_Id = Attribute_VADS_Size
-  then
- Exp_Attr.Expand_Size_Attribute (N);
-
-  --  For attributes which return Universal_Integer, introduce a conversion
-  --  to the expected type with the appropriate check flags set.
-
-  elsif Attr_Id = Attribute_Alignment
-or else Attr_Id = Attribute_Bit
-or else Attr_Id = Attribute_Bit_Position
-or else Attr_Id = Attribute_Descriptor_Size
-or else Attr_Id = Attribute_First_Bit
-or else Attr_Id = Attribute_Last_Bit
-or else Attr_Id = Attribute_Length
-or else Attr_Id = Attribute_Max_Size_In_Storage_Elements
-or else Attr_Id = Attribute_Pos
-or else Attr_Id = Attribute_Position
-or else Attr_Id = Attribute_Range_Length
-or else Attr_Id = Attribute_Aft
-or else Attr_Id = Attribute_Max_Alignment_For_Allocation
-  then
- --  If the expected type is Long_Long_Integer, there will be no check
- --  flag as the compiler assumes attributes always fit in this type.
- --  Since in SPARK_Mode we do not take Storage_Error into account, we
- --  cannot make this assumption and need to produce a check.
- --  ??? It should be enough to add this check for attributes
- --  'Length, 'Range_Length and 'Pos when the type is as big
- --  as Long_Long_Integer.
-
- declare
-Typ : Entity_Id;
- begin
-if Attr_Id = Attribute_Range_Length
-  or else Attr_Id = Attribute_Pos
-then
-   Typ := Etype (Prefix (N));
+Rewrite
+  (N,
+   Make_Function_Call (Loc,
+ Name   =>
+   New_Occurrence_Of (RTE (RE_To_Address), Loc),
+ Parameter_Associations => New_List (Expr)));
+Analyze_And_Resolve (N, Typ);
 
-elsif Attr_Id = Attribute_Length then
-   Typ := Get_Index_Subtype (N);
+ when Attribute_Object_Size
+| Attribute_Size
+| Attribute_Value_Size
+| Attribute_VADS_Size
+ =>
+Exp_Attr.Expand_Size_Attribute (N);
+
+ --  For attributes which return Universal_Integer, introduce a
+ --  conversion to the expected type with the appropriate check flags
+ --  set.
+
+ when Attribute_Aft
+| Attribute_Alignment
+| Attribute_Bit
+| Attribute_Bit_Position
+| Attribute_Descriptor_Size
+| Attribute_First_Bit
+| Attribute_Last_Bit
+| Attribute_Length
+| Attribute_Max_Alignment_For_Allocation
+| Attribute_Max_Size_In_Storage_Elements
+| Attribute_Pos
+| Attribute_Position
+| Attribute_Range_Length
+ =>
+--  If the expected type is Long_Long_Integer, there will be no
+--  check flag as the compiler assumes attributes always fit in
+--  this type. Since in SPARK_Mode we do not take Storage_Error
+--  into account, we cannot make this assumption and need

[Ada] Cannot process -S -o with GNAT LLVM

[Pierre-Marie de Rodat]

This is fixed by recognizing -S in Scan_Compiler_Args and taking it into
account in Set_Output_Object_File_Name.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

* opt.ads (Generate_Asm): New flag.
* osint-c.adb (Set_Output_Object_File_Name): Accept any
extension when generating assembly.
* adabkend.adb (Scan_Compiler_Args): Recognize -S.diff --git a/gcc/ada/adabkend.adb b/gcc/ada/adabkend.adb
--- a/gcc/ada/adabkend.adb
+++ b/gcc/ada/adabkend.adb
@@ -218,6 +218,9 @@ package body Adabkend is
end case;
 end if;
 
+ elsif Switch_Chars (First .. Last) = "S" then
+Generate_Asm := True;
+
  --  Ignore all other back-end switches
 
  elsif Is_Back_End_Switch (Switch_Chars) then


diff --git a/gcc/ada/opt.ads b/gcc/ada/opt.ads
--- a/gcc/ada/opt.ads
+++ b/gcc/ada/opt.ads
@@ -719,6 +719,10 @@ package Opt is
--  the name is of the form .xxx, then to name.xxx where name is the source
--  file name with extension stripped.
 
+   Generate_Asm : Boolean := False;
+   --  GNAT
+   --  True if generating assembly instead of an object file, via the -S switch
+
Generate_C_Code : Boolean := False;
--  GNAT, GNATBIND
--  If True, the Cprint circuitry to generate C code output is activated.


diff --git a/gcc/ada/osint-c.adb b/gcc/ada/osint-c.adb
--- a/gcc/ada/osint-c.adb
+++ b/gcc/ada/osint-c.adb
@@ -480,6 +480,7 @@ package body Osint.C is
  or else
   (Name (NL - EL + Name'First .. Name'Last) /= Ext
  and then Name (NL - 2 + Name'First .. Name'Last) /= ".o"
+ and then not Generate_Asm
  and then
(not Generate_C_Code
   or else Name (NL - 2 + Name'First .. Name'Last) /= ".c"))

Re: OpenACC 'kernels' testsuite failures

[Thomas Schwinge]

Hi!

On 2020-11-21T10:50:10-0500, David Edelsohn  wrote:
> I see
>
> "during GIMPLE pass: omplower"
>
> message for kernels-decompose-ice-2.c.  kernels-decompose-ice-1.c
> explicitly prunes that output, but kernels-decompose-ice-2.c does not.
> Is there a reason that the second testcase does not prune that output
> or can we add it?

So, the expectation (as verified by my x86_64-pc-linux-gnu and
powerpc64le-unknown-linux-gnu testing) is that
'c-c++-common/goacc/kernels-decompose-ice-1.c' (currently) runs into an
ICE "during GIMPLE pass: omplower", and
'c-c++-common/goacc/kernels-decompose-ice-2.c' (currently) runs into an
ICE "during GIMPLE pass: omp_oacc_kernels_decompose".

Now, you're reporting that for the latter testcase you're instead also
seeing an ICE "during GIMPLE pass: omplower".  Can you please show the
full ICE report/backtrace, so that we verify that it's not yet another
separate issue?  Maybe the AIX system configuration (ABI?)
mandates/causes some slight difference in how front ends set attributes
such as 'TREE_ADDRESSABLE' on DECLs, which 'omp_oacc_kernels_decompose'
(currently) is sensitive to (hence the ICEs).  If you confirm that for
'c-c++-common/goacc/kernels-decompose-ice-2.c' you're seeing the same
ICE "during GIMPLE pass: omplower" as seen for
'c-c++-common/goacc/kernels-decompose-ice-1.c', then it shall be fine to
simply add 'dg-prune-output "during GIMPLE pass: omplower"' to
'c-c++-common/goacc/kernels-decompose-ice-2.c', too.  (Please do it once
you've verified/tested that, or I can do it later.)

That said, I shall soon work on resolving these ICEs, so holding your
breath until that happens would be another option.  ;-)


Then, for the Tcl issue:

> On Tue, Nov 17, 2020 at 8:18 PM David Edelsohn  wrote:
>> The patch resolves the "no such variable" error message [...]
>>
>> I installed Tcl 8.6 with Expect 5.45.  This removes the "no such
>> variable" error messages for C and C++ test cases

OK, thanks for confirming that.

>> but they still
>> occur for Fortran.

(That's unexpected; it's the very same testsuite/Tcl constructs.  Maybe
just a manual testing glitch?)

>> I guess that the patch is necessary because there seems to be
>> something else still behaving differently on AIX.
>>
>> Any insights?

>> On Tue, Nov 17, 2020 at 10:03 AM David Edelsohn  wrote:
>> > The standard version of Tcl installed on AIX currently is Tcl 8.4.

Aha, thanks for confirming -- that indeed does explain the issue, good.

>> > I'll see if I can have a newer version on the side.

That's good for testing/confirming (as noted above), but I don't want to
make Tcl 8.5+ a requirement just because of these testcases, so...

>> > The patch resolves the "no such variable" error message.  (Great!
>> > Thanks!)

... I pushed "[testsuite] Avoid Tcl 8.5-specific behavior" to master
branch in commit f72175357d04b0e71d2043be48551d7904a233b6, see attached.


Grüße
 Thomas


>> > On Mon, Nov 16, 2020 at 11:46 AM Thomas Schwinge
>> >  wrote:
>> > >
>> > > Hi David!
>> > >
>> > > While you were writing your email, I've also been busy:
>> > >
>> > > On 2020-11-16T11:32:46-0500, David Edelsohn  wrote:
>> > > > On Mon, Nov 16, 2020 at 9:16 AM Thomas Schwinge 
>> > > >  wrote:
>> > > >> On 2020-11-15T15:47:15-0500, David Edelsohn  wrote:
>> > > >> > I am seeing a number of new failures on AIX related to the OpenACC
>> > > >> > kernels patches.
>> > > >> >
>> > > >> > c-c++-common/goacc/kernels-decompose-1.c
>> > > >> > c-c++-common/goacc/kernels-decompose-2.c
>> > > >> > gfortran.dg/goacc/kernels-decompose-1.f95
>> > > >> > gfortran.dg/goacc/kernels-decompose-2.f95
>> > > >> > libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-decompose-1.c
>> > > >> > libgomp.oacc-fortran/pr94358-1.f90
>> > > >>
>> > > >> I suppose what you're asking about is what appears in
>> > > >>  reports as:
>> > > >>
>> > > >> ERROR: c-c++-common/goacc/kernels-decompose-1.c: can't read 
>> > > >> "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] 
>> > > >> "
>> > > >> UNRESOLVED: c-c++-common/goacc/kernels-decompose-1.c: can't read 
>> > > >> "c_loop_i": no such variable for " dg-line 24 l_loop_i[incr c_loop_i] 
>> > > >> "
>> > > >>
>> > > >> Etc.
>> > >
>> > > In the mean time, I did remember that weeks ago, I had noticed this
>> > > following "detail": on  we
>> > > read that "Starting with the Tcl 8.5 release, the variable 'varName'
>> > > passed to 'incr' may be unset, and in that case, it will be set to
>> > > [...]".  Tcl 8.5 has been released in 2007.
>> > >
>> > > Per 'gcc/doc/install.texi' we require:
>> > >
>> > > @item DejaGnu 1.4.4
>> > > @itemx Expect
>> > > @itemx Tcl
>> > >
>> > > Necessary to run the GCC testsuite; [...]
>> > >
>> > > DejaGnu has been released in 2004 (so cannot have required Tcl 8.5
>> > > released in 2007).
>> > >
>> > > >> However, per the reports posted there, these really only (!) appear to
>> > > >> fail for your "

[PATCH] middle-end: Reject flexible array members in __builtin_clear_padding [PR97943]

[Jakub Jelinek via Gcc-patches]

Hi!

As mentioned in the PR, we currently ICE on flexible array members in
structs and unions during __builtin_clear_padding processing.

Jason said in the PR he'd prefer an error in these cases over forcefully
handling it as [0] arrays (everything is padding then) or consider the
arrays to have as many whole elements as would fit into the tail padding.

So, this patch implements that.

Ok for trunk if it passes bootstrap/regtest?  So far has been tested just
on the dg.exp=builtin-clear-padding* dg-torture.exp=builtin-clear-padding*
check-gcc check-c++-all testsuite, but the builtin is currently not used
in anything else.

2020-11-24  Jakub Jelinek  

PR middle-end/97943
* gimple-fold.c (clear_padding_union, clear_padding_type): Error on and
ignore flexible array member fields.  Ignore fields with
error_mark_node type.

* c-c++-common/builtin-clear-padding-2.c: New test.
* c-c++-common/builtin-clear-padding-3.c: New test.
* g++.dg/ext/builtin-clear-padding-1.C: New test.
* gcc.dg/builtin-clear-padding-2.c: New test.

--- gcc/gimple-fold.c.jj2020-11-23 17:01:48.255054823 +0100
+++ gcc/gimple-fold.c   2020-11-24 09:53:17.724943252 +0100
@@ -4255,6 +4255,17 @@ clear_padding_union (clear_padding_struc
   for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
 if (TREE_CODE (field) == FIELD_DECL)
   {
+   if (DECL_SIZE_UNIT (field) == NULL_TREE)
+ {
+   if (TREE_TYPE (field) == error_mark_node)
+ continue;
+   gcc_assert (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
+   && !COMPLETE_TYPE_P (TREE_TYPE (field)));
+   error_at (buf->loc, "flexible array member %qD does not have "
+   "well defined padding bits for %qs",
+ field, "__builtin_clear_padding");
+   continue;
+ }
HOST_WIDE_INT fldsz = tree_to_shwi (DECL_SIZE_UNIT (field));
gcc_assert (union_buf->size == 0);
union_buf->off = start_off;
@@ -4372,11 +4383,12 @@ clear_padding_type (clear_padding_struct
   for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
if (TREE_CODE (field) == FIELD_DECL)
  {
+   tree ftype = TREE_TYPE (field);
if (DECL_BIT_FIELD (field))
  {
if (DECL_NAME (field) == NULL_TREE)
  continue;
-   HOST_WIDE_INT fldsz = TYPE_PRECISION (TREE_TYPE (field));
+   HOST_WIDE_INT fldsz = TYPE_PRECISION (ftype);
if (fldsz == 0)
  continue;
HOST_WIDE_INT pos = int_byte_position (field);
@@ -4439,6 +4451,16 @@ clear_padding_type (clear_padding_struct
  }
  }
  }
+   else if (DECL_SIZE_UNIT (field) == NULL_TREE)
+ {
+   if (ftype == error_mark_node)
+ continue;
+   gcc_assert (TREE_CODE (ftype) == ARRAY_TYPE
+   && !COMPLETE_TYPE_P (ftype));
+   error_at (buf->loc, "flexible array member %qD does not have "
+   "well defined padding bits for %qs",
+ field, "__builtin_clear_padding");
+ }
else
  {
HOST_WIDE_INT pos = int_byte_position (field);
--- gcc/testsuite/c-c++-common/builtin-clear-padding-2.c.jj 2020-11-24 
09:54:36.331055770 +0100
+++ gcc/testsuite/c-c++-common/builtin-clear-padding-2.c2020-11-24 
10:16:30.468221320 +0100
@@ -0,0 +1,17 @@
+/* PR middle-end/97943 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+struct S { int a; char b[] __attribute__((aligned (2 * sizeof (int; };
+struct T { int a; struct S b; };
+union U { int a; struct S b; };
+struct V { int a; union U b; };
+
+void
+foo (struct S *s, struct T *t, union U *u, struct V *v)
+{
+  __builtin_clear_padding (s); /* { dg-error "flexible array member '(S::)?b' 
does not have well defined padding bits for '__builtin_clear_padding'" } */
+  __builtin_clear_padding (t); /* { dg-error "flexible array member '(S::)?b' 
does not have well defined padding bits for '__builtin_clear_padding'" } */
+  __builtin_clear_padding (u); /* { dg-error "flexible array member '(S::)?b' 
does not have well defined padding bits for '__builtin_clear_padding'" } */
+  __builtin_clear_padding (v); /* { dg-error "flexible array member '(S::)?b' 
does not have well defined padding bits for '__builtin_clear_padding'" } */
+}
--- gcc/testsuite/c-c++-common/builtin-clear-padding-3.c.jj 2020-11-24 
10:09:34.735913452 +0100
+++ gcc/testsuite/c-c++-common/builtin-clear-padding-3.c2020-11-24 
10:16:41.732094196 +0100
@@ -0,0 +1,15 @@
+/* PR middle-end/97943 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+union U { int a; char b[] __attribute__((aligned (2 * sizeof (int; };  
/* { dg-error "flexible

Re: [OpenACC 7/11] execution model

[Thomas Schwinge]

Hi!

On 2015-10-21T15:42:26-0400, Nathan Sidwell  wrote:
> This patch is the early lowering part of OpenACC loops.  Rather than 
> piggy-back
> onto expand_omp_for_static_nochunk & expand_omp_for_static_chunk, we have a 
> new
> function 'expand_oacc_for', which does the OpenACC equivalent
> expension.  [...]

Aye!

(These changes got committed in r229472.)

> +static void
> +expand_oacc_for (struct omp_region *region, struct omp_for_data *fd)
> +{
> +  [...]
> +  bool chunking = !gimple_in_ssa_p (cfun);;
> +  [...]
> +  if (gimple_in_ssa_p (cfun))
> +{
> +  offset_init = gimple_omp_for_index (for_stmt, 0);
> +  gcc_assert (integer_zerop (fd->loop.n1));
> +  /* The SSA parallelizer does gang parallelism.  */
> +  gwv = build_int_cst (integer_type_node, GOMP_DIM_MASK (GOMP_DIM_GANG));
> +}
> +  [etc.]

That's, uhm, a bit "non-obvious" ;-) what's going on there, that (citing
from my patch/commit) "some of the 'gimple_in_ssa_p (cfun)' conditionals
are for SSA specifics, and some are for 'parloops' OpenACC
'kernels'-parallelized specifics".  To clarify that, I've pushed "More
explicit checking of which OMP constructs we're expecting, part II" to
master branch in commit 8c3aa359ce33732273bbd61c5f9a2c607779b32e, and
backported to releases/gcc-10 branch in commit
6e8837438148d6ed3e512099b2d12d06836c2a45, see attached.


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 8c3aa359ce33732273bbd61c5f9a2c607779b32e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 20 Nov 2020 10:41:46 +0100
Subject: [PATCH] More explicit checking of which OMP constructs we're
 expecting, part II

In particular, more precisely highlight what applies generally vs. the special
handling for the current 'parloops'-based OpenACC 'kernels' implementation.

	gcc/
	* omp-expand.c (expand_oacc_for): More explicit checking of which
	OMP constructs we're expecting.
---
 gcc/omp-expand.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index c0e94e5e323..928644b099c 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -7413,6 +7413,21 @@ expand_omp_taskloop_for_inner (struct omp_region *region,
 static void
 expand_oacc_for (struct omp_region *region, struct omp_for_data *fd)
 {
+  bool is_oacc_kernels_parallelized
+= (lookup_attribute ("oacc kernels parallelized",
+			 DECL_ATTRIBUTES (current_function_decl)) != NULL);
+  {
+bool is_oacc_kernels
+  = (lookup_attribute ("oacc kernels",
+			   DECL_ATTRIBUTES (current_function_decl)) != NULL);
+if (is_oacc_kernels_parallelized)
+  gcc_checking_assert (is_oacc_kernels);
+  }
+  gcc_assert (gimple_in_ssa_p (cfun) == is_oacc_kernels_parallelized);
+  /* In the following, some of the 'gimple_in_ssa_p (cfun)' conditionals are
+ for SSA specifics, and some are for 'parloops' OpenACC
+ 'kernels'-parallelized specifics.  */
+
   tree v = fd->loop.v;
   enum tree_code cond_code = fd->loop.cond_code;
   enum tree_code plus_code = PLUS_EXPR;
-- 
2.17.1

>From 6e8837438148d6ed3e512099b2d12d06836c2a45 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 20 Nov 2020 10:41:46 +0100
Subject: [PATCH] More explicit checking of which OMP constructs we're
 expecting, part II

In particular, more precisely highlight what applies generally vs. the special
handling for the current 'parloops'-based OpenACC 'kernels' implementation.

	gcc/
	* omp-expand.c (expand_oacc_for): More explicit checking of which
	OMP constructs we're expecting.

(cherry picked from commit 8c3aa359ce33732273bbd61c5f9a2c607779b32e)
---
 gcc/omp-expand.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/gcc/omp-expand.c b/gcc/omp-expand.c
index 735e263c8f8..27adbaf15cb 100644
--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -5998,6 +5998,21 @@ expand_omp_taskloop_for_inner (struct omp_region *region,
 static void
 expand_oacc_for (struct omp_region *region, struct omp_for_data *fd)
 {
+  bool is_oacc_kernels_parallelized
+= (lookup_attribute ("oacc kernels parallelized",
+			 DECL_ATTRIBUTES (current_function_decl)) != NULL);
+  {
+bool is_oacc_kernels
+  = (lookup_attribute ("oacc kernels",
+			   DECL_ATTRIBUTES (current_function_decl)) != NULL);
+if (is_oacc_kernels_parallelized)
+  gcc_checking_assert (is_oacc_kernels);
+  }
+  gcc_assert (gimple_in_ssa_p (cfun) == is_oacc_kernels_parallelized);
+  /* In the following, some of the 'gimple_in_ssa_p (cfun)' conditionals are
+ for SSA specifics, and some are for 'parloops' OpenACC
+ 'kernels'-parallelized specifics.  */
+
   tree v = fd->loop.v;
   enum tree_code cond_code = fd->loop.cond_code;
   enum tree_code plus_code = PLUS_EXPR;
-- 
2.17.1

Re: Fix hanlding of gimple_clobber in ICF

[Thomas Schwinge]

Hi Honza!

On 2020-11-19T13:33:53+0100, Jan Hubicka  wrote:
> --- a/gcc/ipa-icf-gimple.c
> +++ b/gcc/ipa-icf-gimple.c
> @@ -245,6 +245,14 @@ func_checker::hash_operand (const_tree arg, 
> inchash::hash &hstate,
>break;
>  }
>
> +  /* In gimple all clobbers can be considered equal: while comparaing two
> + gimple clobbers we match the left hand memory accesses.  */
> +  if (TREE_CLOBBER_P (arg))
> +{
> +  hstate.add_int (0xc10bbe5);
> +  return;
> +}
> +
>return operand_compare::hash_operand (arg, hstate, flags);
>  }

I understand correctly that 0xc10bbe5 here just a "random"/fixed number
(maybe should be documented as such?), so that we get stable behavior for
any 'TREE_CLOBBER_P (arg)' cases, and it isn't meant to convey any
meaning (that I'm not seeing)?


Grüße
 Thomas


> @@ -306,6 +314,10 @@ func_checker::operand_equal_p (const_tree t1, const_tree 
> t2,
>  default:
>break;
>  }
> +  /* In gimple all clobbers can be considered equal.  We match the right hand
> + memory accesses.  */
> +  if (TREE_CLOBBER_P (t1) || TREE_CLOBBER_P (t2))
> +return TREE_CLOBBER_P (t1) == TREE_CLOBBER_P (t2);
>
>return operand_compare::operand_equal_p (t1, t2, flags);
>  }
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: [PATCH 1,2] Darwin : Update libtool and dependencies for Darwin20 [PR97865]

[Jonathan Wakely via Gcc-patches]

On 23/11/20 20:01 +, Iain Sandoe wrote:

Hi

This fixes a blocker for x86_64 darwin20 (a.k.a macOS 11)
It is needed on all open branches too.

(probably this comes under my Dariwn hat - but since it involves
regenerating all the configure scripts… I’d welcome another pair
of eyes)

tested on:
darwin8-darwin20, powerpc, i686, x86_64, arm64(aarch64).
aix (cfarm gcc119), aarch64 (cfarm gcc115), powerpc64 (BE) - (cfarm gcc110)
powerpc64 (LE) - (cfarm gcc135), sparc solaris 2.11 (gcc211)
x86_64-linux-gnu (cfarm gcc123)

OK for master?

OK for backports?

thanks
iain

N.B. I am attaching the second patch which is the uninteresting 
regenerated files.


=

The change in major version (and the increment from Darwin19 to 20)
caused libtool tests to fail which resulted in incorrect build settings
for shared libraries.

We take this opportunity to sort out the shared undefined symbols state
rather than propagating the current unsound behaviour into a new rev.

This change means that we default to the case that missing symbols are
considered an error, and if one wants to allow this intentionally, the
confiuration for that case should be set appropriately.

We use intentional missing symbols to emulate the ELF behaviour when
we have a weak undefined extern.

So, three existing cases need undefined dynamic lookup:
libitm, where there is already a configuration mechanism to add the
flags.
libsanitizer, likewise
libcc1, where we add simple configuration to add the flags for Darwin.

libcc1/ChangeLog:

PR target/97865
* Makefile.am: Add dynamic_lookup to LD flags for Darwin.
* configure.ac: Test for Darwin host and set a flag.

libitm/ChangeLog:

PR target/97865
* configure.tgt: Add dynamic_lookup to XLDFLAGS for Darwin.

libsanitizer/ChangeLog:

PR target/97865
* configure.tgt: Add dynamic_lookup to EXTRA_CXXFLAGS for
Darwin.

ChangeLog:

PR target/97865
* libtool.m4: Update handling of Darwin platform link flags
for Darwin20.


---
libcc1/Makefile.am |  3 +++
libcc1/configure.ac|  6 ++
libitm/configure.tgt   |  9 -
libsanitizer/configure.tgt |  1 +
libtool.m4 | 32 +---
5 files changed, 35 insertions(+), 16 deletions(-)

diff --git a/libcc1/Makefile.am b/libcc1/Makefile.am
index ab6f839ecae..173b84f9cdb 100644
--- a/libcc1/Makefile.am
+++ b/libcc1/Makefile.am
@@ -25,6 +25,9 @@ CPPFLAGS_FOR_C_FAMILY = -I $(srcdir)/../gcc/c-family \
CPPFLAGS_FOR_C = $(CPPFLAGS_FOR_C_FAMILY) -I $(srcdir)/../gcc/c
CPPFLAGS_FOR_CXX = $(CPPFLAGS_FOR_C_FAMILY) -I $(srcdir)/../gcc/cp
AM_CXXFLAGS = $(WARN_FLAGS) $(WERROR) $(visibility) $(CET_HOST_FLAGS)
+if DARWIN_DYNAMIC_LOOKUP
+AM_CXXFLAGS += -Wl,-undefined,dynamic_lookup
+endif
override CXXFLAGS := $(filter-out -fsanitize=address,$(CXXFLAGS))
override LDFLAGS := $(filter-out -fsanitize=address,$(LDFLAGS))
# Can be simplified when libiberty becomes a normal convenience library.
diff --git a/libcc1/configure.ac b/libcc1/configure.ac
index 8d3b8d14748..262e0a61e6f 100644
--- a/libcc1/configure.ac
+++ b/libcc1/configure.ac
@@ -104,6 +104,12 @@ AC_CACHE_CHECK([for socket libraries], 
libcc1_cv_lib_sockets,

])
LIBS="$LIBS $libcc1_cv_lib_sockets"

+case "$host" in
+  *-*-darwin*) darwin_dynamic_lookup=yes ;;
+  *) darwin_dynamic_lookup= ;;
+esac
+AM_CONDITIONAL(DARWIN_DYNAMIC_LOOKUP, test $darwin_dynamic_lookup = yes)
+
# If any of these functions are missing, simply don't bother building
# this plugin.
GCC_ENABLE_PLUGINS
diff --git a/libitm/configure.tgt b/libitm/configure.tgt
index 04109160e91..d1beb5c9ec8 100644
--- a/libitm/configure.tgt
+++ b/libitm/configure.tgt
@@ -43,6 +43,7 @@ if test "$gcc_cv_have_tls" = yes ; then
*-*-linux*)
XCFLAGS="${XCFLAGS} -ftls-model=initial-exec"
;;
+
  esac
fi

@@ -144,10 +145,16 @@ case "${target}" in
  *-*-gnu* | *-*-k*bsd*-gnu \
  | *-*-netbsd* | *-*-freebsd* | *-*-openbsd* \
  | *-*-solaris2* | *-*-sysv4* | *-*-hpux11* \
-  | *-*-darwin* | *-*-aix* | *-*-dragonfly*)
+  | *-*-aix* | *-*-dragonfly*)
# POSIX system.  The OS is supported.
;;

+  *-*-darwin*)
+   # The OS is supported, but we need dynamic lookup to support undefined
+   # weak symbols at link-time.
+   XLDFLAGS="${XLDFLAGS} -Wl,-undefined,dynamic_lookup"
+   ;;
+
  *)# Non-POSIX, or embedded system
UNSUPPORTED=1
;;
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index ef9150209c4..f73d410dedf 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -64,6 +64,7 @@ case "${target}" in
;;
  x86_64-*-darwin2* | x86_64-*-darwin1[2-9]* | i?86-*-darwin1[2-9]*)
TSAN_SUPPORTED=no
+   EXTRA_CXXFLAGS+="-Wl,-undefined,dynamic_lookup"
;;
  x86_64-*-solaris2.11* | i?86-*-solaris2.11*)
;;
diff --git a/libtool.m4 b/libtool.m4
index e194e899fcf..9b14b9470df 100644
--- a/libtool.m4
+++ b/libto

Re: Fix hanlding of gimple_clobber in ICF

[Jan Hubicka]

> Hi Honza!
> 
> On 2020-11-19T13:33:53+0100, Jan Hubicka  wrote:
> > --- a/gcc/ipa-icf-gimple.c
> > +++ b/gcc/ipa-icf-gimple.c
> > @@ -245,6 +245,14 @@ func_checker::hash_operand (const_tree arg, 
> > inchash::hash &hstate,
> >break;
> >  }
> >
> > +  /* In gimple all clobbers can be considered equal: while comparaing two
> > + gimple clobbers we match the left hand memory accesses.  */
> > +  if (TREE_CLOBBER_P (arg))
> > +{
> > +  hstate.add_int (0xc10bbe5);
> > +  return;
> > +}
> > +
> >return operand_compare::hash_operand (arg, hstate, flags);
> >  }
> 
> I understand correctly that 0xc10bbe5 here just a "random"/fixed number
> (maybe should be documented as such?), so that we get stable behavior for
> any 'TREE_CLOBBER_P (arg)' cases, and it isn't meant to convey any
> meaning (that I'm not seeing)?

Yes, we need to avoid calling hash_operand becaue we do not want to
include additional info it hashes and we want to have good chance not
colliding with other items operand hashing adds.  It usually (apparently
not always) adds first gimple code, so hashing it random large number is
quite safe. 

Honza
> 
> 
> Grüße
>  Thomas
> 
> 
> > @@ -306,6 +314,10 @@ func_checker::operand_equal_p (const_tree t1, 
> > const_tree t2,
> >  default:
> >break;
> >  }
> > +  /* In gimple all clobbers can be considered equal.  We match the right 
> > hand
> > + memory accesses.  */
> > +  if (TREE_CLOBBER_P (t1) || TREE_CLOBBER_P (t2))
> > +return TREE_CLOBBER_P (t1) == TREE_CLOBBER_P (t2);
> >
> >return operand_compare::operand_equal_p (t1, t2, flags);
> >  }
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, 
> Alexander Walter

RE: [PATCH] middle-end: Support complex Addition

[Richard Biener]

On Tue, 24 Nov 2020, Richard Biener wrote:

> On Mon, 23 Nov 2020, Tamar Christina wrote:
> 
> > Hi Richi,
> > 
> > > -Original Message-
> > > From: Richard Biener 
> > > Sent: Monday, November 23, 2020 3:51 PM
> > > To: Tamar Christina 
> > > Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz;
> > > hongtao@intel.com
> > > Subject: Re: [PATCH] middle-end: Support complex Addition
> > > 
> > > On Mon, 23 Nov 2020, Tamar Christina wrote:
> > > 
> > > > Hi All,
> > > >
> > > > This patch adds support for
> > > >
> > > >   * Complex Addition with rotation of 90 and 270.
> > > >
> > > >   Addition with rotation of the second argument around the Argand plane.
> > > > Supported rotations are 90 and 180.
> > > >
> > > > c = a + (b * I) and c = a + (b * I * I * I)
> > > >
> > > > For the full code I have pushed a branch at
> > > refs/users/tnfchris/heads/complex-numbers.
> > > >
> > > > As a side note, I still needed to set
> > > >
> > > > STMT_SLP_TYPE (call_stmt_info) = pure_slp;
> > > >
> > > > as the new hybrid detection code only runs for loop aware SLP.
> > > >
> > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues, but
> > > > sorting out the testcases as TCL is processed before the CPP..
> > > >
> > > > Ok for master?
> > > 
> > > So I failed to apply this patch (and after manual fixup build).
> > > I went ahead and checked out the branch, patching the tree with
> > > x86 support for cadd90 with -msse3 or -mavx2 using the attached
> > > patch.
> > > 
> > 
> > It requires a patch you have previously approved pending the rest so it's 
> > not committed yet ?
> 
> Ah, I missed that.
> 
> > > For
> > > 
> > > double c[1024], b[1024], a[1024];
> > > 
> > > void foo ()
> > > {
> > >   for (int i = 0; i < 512; ++i)
> > > {
> > >   c[2*i] = a[2*i] - b[2*i+1];
> > >   c[2*i+1] = a[2*i+1] + b[2*i];
> > > }
> > > }
> > > 
> > > I then see
> > > 
> > > t.c:5:21: note:Analyzing SLP tree 0x39c0010 for patterns
> > > t.c:5:21: note:Found COMPLEX_ADD_ROT90 pattern in SLP tree
> > > t.c:5:21: note:Target supports COMPLEX_ADD_ROT90 vectorization with
> > > mode vector(2) double
> > > t.c:5:21: note:Pattern matched SLP tree
> > > t.c:5:21: note:node 0x39c0010 (max_nunits=2, refcnt=2)
> > > t.c:5:21: note:op template: c[_1] = _5;
> > > t.c:5:21: note: stmt 0 c[_1] = _5;
> > > t.c:5:21: note: stmt 1 c[_3] = _8;
> > > t.c:5:21: note: children 0x39c0080
> > > t.c:5:21: note:node 0x39c0080 (max_nunits=2, refcnt=2)
> > > t.c:5:21: note:op template: slp_patt_29 = .COMPLEX_ADD_ROT90 (_5, _5);
> > > t.c:5:21: note: stmt 0 _5 = _2 - _4;
> > > t.c:5:21: note: stmt 1 _8 = _6 + _7;
> > > t.c:5:21: note: lane permutation { 0[0] 1[1] }
> > > t.c:5:21: note: children 0x39c00f0 0x39c02b0
> > > t.c:5:21: note:node 0x39c00f0 (max_nunits=2, refcnt=2)
> > > t.c:5:21: note:op template: _2 = a[_1];
> > > t.c:5:21: note: stmt 0 _2 = a[_1];
> > > t.c:5:21: note: stmt 1 _6 = a[_3];
> > > t.c:5:21: note: load permutation { 0 1 }
> > > t.c:5:21: note:node 0x39c02b0 (max_nunits=1, refcnt=1)
> > > t.c:5:21: note:op: VEC_PERM_EXPR
> > > t.c:5:21: note: { }
> > > t.c:5:21: note: lane permutation { 0[1] 0[0] }
> > > t.c:5:21: note: children 0x39c0160
> > > t.c:5:21: note:node 0x39c0160 (max_nunits=2, refcnt=2)
> > > t.c:5:21: note:op template: _4 = b[_3];
> > > t.c:5:21: note: stmt 0 _4 = b[_3];
> > > t.c:5:21: note: stmt 1 _7 = b[_1];
> > > t.c:5:21: note: load permutation { 1 0 }
> > > 
> > > I'm confused about the lane permutation in the .COMPLEX_ADD_ROT90
> > > node (I guess this permutation is simply ignored by code-generation).
> > > Should it not be there?
> > 
> > Yes, I had completely missed that. I forgot to blank it out.
> 
> Btw, in this context
> 
>   /* Unfortunately still need this on the new pattern because non-loop 
> SLP
>  doesn't call vect_detect_hybrid_slp so it never updates it.  */
>   STMT_SLP_TYPE (call_stmt_info) = pure_slp;
> 
> this isnt' about the hybrid marker but about vect_mark_slp_stmts
> which marks all stmts participating in the SLP graph with pure_slp
> which only marks SLP_TREE_SCALAR_STMTS but not SLP_TREE_REPRESENTATIVE.
> I think that's OK and thus the above setting of pure_slp is OK as well,
> just the comment is off.  Maybe make it "Make sure to mark the
> representative statement pure_slp and relevant".
> 
> > > 
> > > Otherwise the outcome is now as expected.  Permute optimization
> > > later produces
> > > 
> > > t.c:5:21: note:   node 0x39c0080 (max_nunits=2, refcnt=1)
> > > t.c:5:21: note:   op template: slp_patt_29 = .COMPLEX_ADD_ROT90 (_5, _5);
> > > t.c:5:21: note: stmt 0 _5 = _2 - _4;
> > > t.c:5:21: note: stmt 1 _8 = _6 + _7;
> > > t.c:5:21: note: lane permutation { 0[0] 1[1] }
> > > t.c:5:21: note: children 0x39c00f0 0x39c02b0
> > 

[wwwdocs] Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies

[Ulrich Weigand via Gcc-patches]

On Sat, Nov 21, 2020 at 01:57:32PM -0600, Segher Boessenkool wrote:
> On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> > On 2/11/20 11:43 AM, Ulrich Weigand wrote:
> > > 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
> > >is explicitly set (or reset) on the command line, this should override
> > >any implicit change due to -f(no-)fast-math, no matter in which order
> > >the flags come on the command line.  This change affects all flags.
> > >
> > > 2. Any component flag modified from its default by -ffast-math should
> > >be reset to the default by -fno-fast-math.  This was previously
> > >not done for the following flags:
> > >   -fcx-limited-range
> > >   -fexcess-precision=
> > >
> > > 3. Once -ffinite-math-only is true, the -f(no-)signaling-nans flag has
> > >no meaning (if we have no NaNs at all, it does not matter whether
> > >there is a difference between quiet and signaling NaNs).  Therefore,
> > >it does not make sense for -ffast-math to imply -fno-signaling-nans.
> > >This is also a documentation change.
> > >
> > > 4. -ffast-math is documented to imply -fno-rounding-math, however the
> > >latter setting is the default anyway; therefore it does not make
> > >sense to try to modify it from its default setting.
> > >
> > > 5. The __FAST_MATH__ preprocessor macro should be defined if and only
> > >if all the component flags of -ffast-math are set to the value that
> > >is documented as the effect of -ffast-math.  The following flags
> > >were currently *not* so tested:
> > >  -fcx-limited-range
> > >  -fassociative-math
> > >  -freciprocal-math
> > >  -frounding-math
> > >(Note that we should still *test* for -fno-rounding-math here even
> > >though it is not set as per 4.  -ffast-math -frounding-math should
> > >not set the __FAST_MATH__ macro.)
> > >This is also a documentation change.
> 
> > It appears this was dropped on the floor.? It looks reasonable to me.?
> > Please retest and commit.? Thanks!

I've now retested on s390x-ibm-linux and committed to mainline.
Thanks for the review!

> It all makes sense, and is a nice improvement :-)  But please mention it
> in the release notes?  No doubt people did use non-sensical flag
> combinations, and they will be affected.  Thanks!

Here's a proposed patch to update the gcc-11 changes.hmtl.

OK to commit?

Bye,
Ulrich

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 46a6a37..c0f896a 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -58,6 +58,29 @@ a work-in-progress.
   is deprecated and will be removed in a future release. It should be
   possible to use --enable-cheaders=c_global (the default)
   with no change in behaviour. 
+
+  Some inconsistencies in handling combinations of 
-ffast-math,
+  -fno-fast-math, -funsafe-math-optimizations,
+  -fno-unsafe-math-optimizations, and their component flags
+  have been fixed.  This might change the behavior of the compiler when
+  invoked with certain combinations of such command line options.
+  The behavior is now consistently:
+  
+  If a component flag of -ffast-math or 
+  -funsafe-math-optimizations is explicitly set or reset
+  on the command line, this will override any implicit change, no 
matter
+  in which order the flags come on the command line.
+  Any component flag (which is not explicity set or reset on the 
command
+  line) that was modified from its default by -ffast-math 
or
+  -funsafe-math-optimizations is always reset to its 
default
+  by a subsequent -fno-fast-math or
+  -fno-unsafe-math-optimizations.
+  -ffast-math no longer implicitly changes
+  -fsignaling-math.
+  The __FAST_MATH__ preprocessor macro is set if and
+  only if all component flags of -ffast-math are set
+  to the value documented as the effect of 
-ffast-math.
+  
 
 
 



-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Re: [PATCH] middle-end: Reject flexible array members in __builtin_clear_padding [PR97943]

[Richard Biener]

On Tue, 24 Nov 2020, Jakub Jelinek wrote:

> Hi!
> 
> As mentioned in the PR, we currently ICE on flexible array members in
> structs and unions during __builtin_clear_padding processing.
> 
> Jason said in the PR he'd prefer an error in these cases over forcefully
> handling it as [0] arrays (everything is padding then) or consider the
> arrays to have as many whole elements as would fit into the tail padding.
> 
> So, this patch implements that.
> 
> Ok for trunk if it passes bootstrap/regtest?  So far has been tested just
> on the dg.exp=builtin-clear-padding* dg-torture.exp=builtin-clear-padding*
> check-gcc check-c++-all testsuite, but the builtin is currently not used
> in anything else.

So code-gen wise this will still elide the builtin but error, right?

OK then.

Note it still leaves struct { int n; char c[1]; } to be handled
which I think is the actual way we'll face "flexarray" members.

IMHO we need to treat them as data but maybe we should emit a warning?

Richard.

> 2020-11-24  Jakub Jelinek  
> 
>   PR middle-end/97943
>   * gimple-fold.c (clear_padding_union, clear_padding_type): Error on and
>   ignore flexible array member fields.  Ignore fields with
>   error_mark_node type.
> 
>   * c-c++-common/builtin-clear-padding-2.c: New test.
>   * c-c++-common/builtin-clear-padding-3.c: New test.
>   * g++.dg/ext/builtin-clear-padding-1.C: New test.
>   * gcc.dg/builtin-clear-padding-2.c: New test.
> 
> --- gcc/gimple-fold.c.jj  2020-11-23 17:01:48.255054823 +0100
> +++ gcc/gimple-fold.c 2020-11-24 09:53:17.724943252 +0100
> @@ -4255,6 +4255,17 @@ clear_padding_union (clear_padding_struc
>for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
>  if (TREE_CODE (field) == FIELD_DECL)
>{
> + if (DECL_SIZE_UNIT (field) == NULL_TREE)
> +   {
> + if (TREE_TYPE (field) == error_mark_node)
> +   continue;
> + gcc_assert (TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE
> + && !COMPLETE_TYPE_P (TREE_TYPE (field)));
> + error_at (buf->loc, "flexible array member %qD does not have "
> + "well defined padding bits for %qs",
> +   field, "__builtin_clear_padding");
> + continue;
> +   }
>   HOST_WIDE_INT fldsz = tree_to_shwi (DECL_SIZE_UNIT (field));
>   gcc_assert (union_buf->size == 0);
>   union_buf->off = start_off;
> @@ -4372,11 +4383,12 @@ clear_padding_type (clear_padding_struct
>for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN 
> (field))
>   if (TREE_CODE (field) == FIELD_DECL)
> {
> + tree ftype = TREE_TYPE (field);
>   if (DECL_BIT_FIELD (field))
> {
>   if (DECL_NAME (field) == NULL_TREE)
> continue;
> - HOST_WIDE_INT fldsz = TYPE_PRECISION (TREE_TYPE (field));
> + HOST_WIDE_INT fldsz = TYPE_PRECISION (ftype);
>   if (fldsz == 0)
> continue;
>   HOST_WIDE_INT pos = int_byte_position (field);
> @@ -4439,6 +4451,16 @@ clear_padding_type (clear_padding_struct
> }
> }
> }
> + else if (DECL_SIZE_UNIT (field) == NULL_TREE)
> +   {
> + if (ftype == error_mark_node)
> +   continue;
> + gcc_assert (TREE_CODE (ftype) == ARRAY_TYPE
> + && !COMPLETE_TYPE_P (ftype));
> + error_at (buf->loc, "flexible array member %qD does not have "
> + "well defined padding bits for %qs",
> +   field, "__builtin_clear_padding");
> +   }
>   else
> {
>   HOST_WIDE_INT pos = int_byte_position (field);
> --- gcc/testsuite/c-c++-common/builtin-clear-padding-2.c.jj   2020-11-24 
> 09:54:36.331055770 +0100
> +++ gcc/testsuite/c-c++-common/builtin-clear-padding-2.c  2020-11-24 
> 10:16:30.468221320 +0100
> @@ -0,0 +1,17 @@
> +/* PR middle-end/97943 */
> +/* { dg-do compile } */
> +/* { dg-options "" } */
> +
> +struct S { int a; char b[] __attribute__((aligned (2 * sizeof (int; };
> +struct T { int a; struct S b; };
> +union U { int a; struct S b; };
> +struct V { int a; union U b; };
> +
> +void
> +foo (struct S *s, struct T *t, union U *u, struct V *v)
> +{
> +  __builtin_clear_padding (s);   /* { dg-error "flexible array member 
> '(S::)?b' does not have well defined padding bits for 
> '__builtin_clear_padding'" } */
> +  __builtin_clear_padding (t);   /* { dg-error "flexible array member 
> '(S::)?b' does not have well defined padding bits for 
> '__builtin_clear_padding'" } */
> +  __builtin_clear_padding (u);   /* { dg-error "flexible array member 
> '(S::)?b' does not have well defined padding bits for 
> '__builtin_clear_padding'" } */
> +  __builtin_clear_padding (v);   /* { dg-error "flexible array member 
> '(S::)?b' does not have

Re: [PATCH] middle-end: Reject flexible array members in __builtin_clear_padding [PR97943]

[Jakub Jelinek via Gcc-patches]

On Tue, Nov 24, 2020 at 10:56:46AM +, Richard Biener wrote:
> On Tue, 24 Nov 2020, Jakub Jelinek wrote:
> > As mentioned in the PR, we currently ICE on flexible array members in
> > structs and unions during __builtin_clear_padding processing.
> > 
> > Jason said in the PR he'd prefer an error in these cases over forcefully
> > handling it as [0] arrays (everything is padding then) or consider the
> > arrays to have as many whole elements as would fit into the tail padding.
> > 
> > So, this patch implements that.
> > 
> > Ok for trunk if it passes bootstrap/regtest?  So far has been tested just
> > on the dg.exp=builtin-clear-padding* dg-torture.exp=builtin-clear-padding*
> > check-gcc check-c++-all testsuite, but the builtin is currently not used
> > in anything else.
> 
> So code-gen wise this will still elide the builtin but error, right?

Yes.
 
> OK then.
>
> Note it still leaves struct { int n; char c[1]; } to be handled
> which I think is the actual way we'll face "flexarray" members.
> 
> IMHO we need to treat them as data but maybe we should emit a warning?

This is only about std::atomic used with such type, for the above, one
can safely use on common ABIs only at most 4 elements of the array, more
just wouldn't work anyway.  And for the warning I'd think people would be
annoyed by that then they treat it like an array (i.e. the only thing the
standard allows, because they don't do anything wrong and it would be hard
to avoid the warning (only add pragmas somewhere, but where exactly, on all
the method calls of the atomic and constructors?), rather than poor man's
flexible array member.

Jakub

Re: [PATCH v2 01/31] PR target/58901: reload: Handle SUBREG of MEM with a mode-dependent address

[Eric Botcazou]

> First posted at: .
> 
> 2020-11-24  Matt Thomas  
>   Maciej W. Rozycki  
> 
>   gcc/
>   PR target/58901
>   * reload.c (push_reload): Also reload the inner expression of a
>   SUBREG for pseudos associated with a mode-dependent memory
>   reference.
>   (find_reloads): Force a reload likewise.

Thanks for pursuing this.  Although the duplication is unfortunate, I think 
that this version is more in line with the existing processing so I would go 
for it.  You probably need a formal ack from Ulrich(?) or Jeff though.

-- 
Eric Botcazou

Re: H8 cc0 conversion

[Eric Botcazou]

> I'm intested in any notes, however vague, on that matter.  I was
> a bit surprised to see that myself...that is, after fixing
> *some* related regressions, like the one in combine.  (Did I
> actually miss something?)

My recollection for the Visium port would align with what Jeff saw but, on the 
other hand, this could have been very marginal a phenomenon in the end.

-- 
Eric Botcazou

[PATCH] IBM Z: Restrict vec_cmp on z13

[Ilya Leoshkevich via Gcc-patches]

Bootstrapped and regtested on s390x-redhat-linux.  Ok for master?



Commit 5d9ade39b872 ("IBM Z: Fix PR97326: Enable fp compares in
vec_cmp") made it possible to create rtxes that describe signaling
comparisons on z13, which are not supported by the hardware.  Restrict
this by using vcond_comparison_operator predicate.

gcc/ChangeLog:

2020-11-24  Ilya Leoshkevich  

* config/s390/vector.md: Use vcond_comparison_operator
predicate.
---
 gcc/config/s390/vector.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
index fef68644625..029ee0886c2 100644
--- a/gcc/config/s390/vector.md
+++ b/gcc/config/s390/vector.md
@@ -1561,7 +1561,7 @@ (define_expand "copysign3"
 
 (define_expand "vec_cmp"
   [(set (match_operand:  0 "register_operand" "")
-   (match_operator: 1 ""
+   (match_operator: 1 "vcond_comparison_operator"
  [(match_operand:V_HW 2 "register_operand" "")
   (match_operand:V_HW 3 "register_operand" "")]))]
   "TARGET_VX"
-- 
2.25.4

Re: Update: [PATCH 5/X] libsanitizer: mid-end: Introduce stack variable handling for HWASAN

[Hongtao Liu via Gcc-patches]

Hi:
  I'm learning about this patch, and I see one place that might be
slighted improved.

+  poly_int64 size = (top - bot);
+
+  /* Assert the edge of each variable is aligned to the HWASAN tag granule
+size.  */
+  gcc_assert (multiple_p (top, HWASAN_TAG_GRANULE_SIZE));
+  gcc_assert (multiple_p (bot, HWASAN_TAG_GRANULE_SIZE));
+  gcc_assert (multiple_p (size, HWASAN_TAG_GRANULE_SIZE));
+

The last gcc_assert looks redundant?

On Sat, Nov 21, 2020 at 2:48 AM Matthew Malcomson via Gcc-patches
 wrote:
>
>
>
> Hi there,
>
> I was just doing some double-checks and noticed I'd placed the
> documentation in the wrong section of tm.texi.  The `MEMTAG` hooks were
> documented in the `Register Classes` section, so I've now moved it to
> the `Misc` section.
>
> That's the only change, Ok for trunk?
>
> Matthew
>
>
> 
>
>
>
> Handling stack variables has three features.
>
> 1) Ensure HWASAN required alignment for stack variables
>
> When tagging shadow memory, we need to ensure that each tag granule is
> only used by one variable at a time.
>
> This is done by ensuring that each tagged variable is aligned to the tag
> granule representation size and also ensure that the end of each
> object is aligned to ensure the start of any other data stored on the
> stack is in a different granule.
>
> This patch ensures the above by forcing the stack pointer to be aligned
> before and after allocating any stack objects. Since we are forcing
> alignment we also use `align_local_variable` to ensure this new alignment
> is advertised properly through SET_DECL_ALIGN.
>
> 2) Put tags into each stack variable pointer
>
> Make sure that every pointer to a stack variable includes a tag of some
> sort on it.
>
> The way tagging works is:
>   1) For every new stack frame, a random tag is generated.
>   2) A base register is formed from the stack pointer value and this
>  random tag.
>   3) References to stack variables are now formed with RTL describing an
>  offset from this base in both tag and value.
>
> The random tag generation is handled by a backend hook.  This hook
> decides whether to introduce a random tag or use the stack background
> based on the parameter hwasan-random-frame-tag.  Using the stack
> background is necessary for testing and bootstrap.  It is necessary
> during bootstrap to avoid breaking the `configure` test program for
> determining stack direction.
>
> Using the stack background means that every stack frame has the initial
> tag of zero and variables are tagged with incrementing tags from 1,
> which also makes debugging a bit easier.
>
> Backend hooks define the size of a tag, the layout of the HWASAN shadow
> memory, and handle emitting the code that inserts and extracts tags from a
> pointer.
>
> 3) For each stack variable, tag and untag the shadow stack on function
>prologue and epilogue.
>
> On entry to each function we tag the relevant shadow stack region for
> each stack variable. This stack region is tagged to match the tag added to
> each pointer to that variable.
>
> This is the first patch where we use the HWASAN shadow space, so we need
> to add in the libhwasan initialisation code that creates this shadow
> memory region into the binary we produce.  This instrumentation is done
> in `compile_file`.
>
> When exiting a function we need to ensure the shadow stack for this
> function has no remaining tags.  Without clearing the shadow stack area
> for this stack frame, later function calls could get false positives
> when those later function calls check untagged areas (such as parameters
> passed on the stack) against a shadow stack area with left-over tag.
>
> Hence we ensure that the entire stack frame is cleared on function exit.
>
> config/ChangeLog:
>
> * bootstrap-hwasan.mk: Disable random frame tags for stack-tagging
> during bootstrap.
>
> ChangeLog:
>
> * gcc/asan.c (struct hwasan_stack_var): New.
> (hwasan_sanitize_p): New.
> (hwasan_sanitize_stack_p): New.
> (hwasan_sanitize_allocas_p): New.
> (initialize_sanitizer_builtins): Define new builtins.
> (ATTR_NOTHROW_LIST): New macro.
> (hwasan_current_frame_tag): New.
> (hwasan_frame_base): New.
> (stack_vars_base_reg_p): New.
> (hwasan_maybe_init_frame_base_init): New.
> (hwasan_record_stack_var): New.
> (hwasan_get_frame_extent): New.
> (hwasan_increment_frame_tag): New.
> (hwasan_record_frame_init): New.
> (hwasan_emit_prologue): New.
> (hwasan_emit_untag_frame): New.
> (hwasan_finish_file): New.
> (hwasan_truncate_to_tag_size): New.
> * gcc/asan.h (hwasan_record_frame_init): New declaration.
> (hwasan_record_stack_var): New declaration.
> (hwasan_emit_prologue): New declaration.
> (hwasan_emit_untag_frame): New declaration.
> (hwasan_get_frame

Re: [PATCH] IBM Z: Restrict vec_cmp on z13

[Andreas Krebbel via Gcc-patches]

On 24.11.20 12:55, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux.  Ok for master?
> 
> 
> 
> Commit 5d9ade39b872 ("IBM Z: Fix PR97326: Enable fp compares in
> vec_cmp") made it possible to create rtxes that describe signaling
> comparisons on z13, which are not supported by the hardware.  Restrict
> this by using vcond_comparison_operator predicate.
> 
> gcc/ChangeLog:
> 
> 2020-11-24  Ilya Leoshkevich  
> 
>   * config/s390/vector.md: Use vcond_comparison_operator
>   predicate.

Ok. Thanks!

Andreas

Re: [PATCH] middle-end: Support complex Addition

[Hongtao Liu via Gcc-patches]

On Mon, Nov 23, 2020 at 11:54 PM Richard Biener  wrote:
>
> On Mon, 23 Nov 2020, Tamar Christina wrote:
>
> > Hi All,
> >
> > This patch adds support for
> >
> >   * Complex Addition with rotation of 90 and 270.
> >
> >   Addition with rotation of the second argument around the Argand plane.
> > Supported rotations are 90 and 180.
> >
> > c = a + (b * I) and c = a + (b * I * I * I)
> >
> > For the full code I have pushed a branch at 
> > refs/users/tnfchris/heads/complex-numbers.
> >
> > As a side note, I still needed to set
> >
> > STMT_SLP_TYPE (call_stmt_info) = pure_slp;
> >
> > as the new hybrid detection code only runs for loop aware SLP.
> >
> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues, but
> > sorting out the testcases as TCL is processed before the CPP..
> >
> > Ok for master?
>
> So I failed to apply this patch (and after manual fixup build).
> I went ahead and checked out the branch, patching the tree with
> x86 support for cadd90 with -msse3 or -mavx2 using the attached
> patch.
>
> For
>
> double c[1024], b[1024], a[1024];
>
> void foo ()
> {
>   for (int i = 0; i < 512; ++i)
> {
>   c[2*i] = a[2*i] - b[2*i+1];
>   c[2*i+1] = a[2*i+1] + b[2*i];
> }
> }
>
> I then see
>
> t.c:5:21: note:Analyzing SLP tree 0x39c0010 for patterns
> t.c:5:21: note:Found COMPLEX_ADD_ROT90 pattern in SLP tree
> t.c:5:21: note:Target supports COMPLEX_ADD_ROT90 vectorization with
> mode vector(2) double
> t.c:5:21: note:Pattern matched SLP tree
> t.c:5:21: note:node 0x39c0010 (max_nunits=2, refcnt=2)
> t.c:5:21: note:op template: c[_1] = _5;
> t.c:5:21: note: stmt 0 c[_1] = _5;
> t.c:5:21: note: stmt 1 c[_3] = _8;
> t.c:5:21: note: children 0x39c0080
> t.c:5:21: note:node 0x39c0080 (max_nunits=2, refcnt=2)
> t.c:5:21: note:op template: slp_patt_29 = .COMPLEX_ADD_ROT90 (_5, _5);
> t.c:5:21: note: stmt 0 _5 = _2 - _4;
> t.c:5:21: note: stmt 1 _8 = _6 + _7;
> t.c:5:21: note: lane permutation { 0[0] 1[1] }
> t.c:5:21: note: children 0x39c00f0 0x39c02b0
> t.c:5:21: note:node 0x39c00f0 (max_nunits=2, refcnt=2)
> t.c:5:21: note:op template: _2 = a[_1];
> t.c:5:21: note: stmt 0 _2 = a[_1];
> t.c:5:21: note: stmt 1 _6 = a[_3];
> t.c:5:21: note: load permutation { 0 1 }
> t.c:5:21: note:node 0x39c02b0 (max_nunits=1, refcnt=1)
> t.c:5:21: note:op: VEC_PERM_EXPR
> t.c:5:21: note: { }
> t.c:5:21: note: lane permutation { 0[1] 0[0] }
> t.c:5:21: note: children 0x39c0160
> t.c:5:21: note:node 0x39c0160 (max_nunits=2, refcnt=2)
> t.c:5:21: note:op template: _4 = b[_3];
> t.c:5:21: note: stmt 0 _4 = b[_3];
> t.c:5:21: note: stmt 1 _7 = b[_1];
> t.c:5:21: note: load permutation { 1 0 }
>
> I'm confused about the lane permutation in the .COMPLEX_ADD_ROT90
> node (I guess this permutation is simply ignored by code-generation).
> Should it not be there?
>
> Otherwise the outcome is now as expected.  Permute optimization
> later produces
>
> t.c:5:21: note:   node 0x39c0080 (max_nunits=2, refcnt=1)
> t.c:5:21: note:   op template: slp_patt_29 = .COMPLEX_ADD_ROT90 (_5, _5);
> t.c:5:21: note: stmt 0 _5 = _2 - _4;
> t.c:5:21: note: stmt 1 _8 = _6 + _7;
> t.c:5:21: note: lane permutation { 0[0] 1[1] }
> t.c:5:21: note: children 0x39c00f0 0x39c02b0
> ...
> t.c:5:21: note:   node 0x39c02b0 (max_nunits=1, refcnt=1)
> t.c:5:21: note:   op: VEC_PERM_EXPR
> t.c:5:21: note: { }
> t.c:5:21: note: lane permutation { 0[0] 0[1] }
> t.c:5:21: note: children 0x39c0160
> t.c:5:21: note:   node 0x39c0160 (max_nunits=2, refcnt=1)
> t.c:5:21: note:   op template: _4 = b[_3];
> t.c:5:21: note: stmt 0 _7 = b[_1];
> t.c:5:21: note: stmt 1 _4 = b[_3];
>
> where the noop permute is correctly costed (and thus is just a
> cosmetic annoyance):
>
> 0x3a13870 a[_1] 1 times vector_load costs 12 in body
> 0x3a13870 b[_1] 1 times vector_load costs 12 in body
> 0x3a13870  0 times vec_perm costs 0 in body
> 0x3a13870 .COMPLEX_ADD_ROT90 (_5, _5) 1 times vector_stmt costs 12 in body
> 0x3a13870 _5 1 times vector_store costs 12 in body
>
> Code generated is also superior (-msse3):
>
> .L2:
> movapd  a(%rax), %xmm0
> addsubpdb(%rax), %xmm0
> addq$16, %rax
> movaps  %xmm0, c-16(%rax)
> cmpq$8192, %rax
> jne .L2
>
> compared to GCC 10 where we have an extra permute
>
> .L2:
> movapd  b(%rax), %xmm0
> movapd  a(%rax), %xmm1
> addq$16, %rax
> shufpd  $1, %xmm0, %xmm0
> addsubpd%xmm0, %xmm1
> movaps  %xmm1, c-16(%rax)
> cmpq$8192, %rax
> jne .L2
>
> which of course makes me wonder whether I have done the x86
> support correctly.  Ah, I have not.  The x86 instructions
> do not embed the even/odd lane swap, they just do the mixed
> sign ope

Re: [PATCH][PR target/97642] Fix incorrect replacement of vmovdqu32 with vpblendd.

[Jakub Jelinek via Gcc-patches]

On Tue, Nov 24, 2020 at 10:36:49AM +0800, Hongtao Liu via Gcc-patches wrote:
> > >   * gcc.target/i386/pr97642-2.c: New test.
> > So in the BZ Jakub asked for the all-ones mask case to be specially
> > handled to emit a normal load.  I don't see where we're handling that.
> > ISTM that we'd want a test for that too.  Right?
> >
> 
> all-ones mask would be simplified to a simple load but with unspec in
> set_src and would be handled by the following
> 
> +(define_insn_and_split "*_load"
> +  [(set (match_operand:V48_AVX512VL 0 "register_operand")
> + (unspec:V48_AVX512VL
> +   [(match_operand:V48_AVX512VL 1 "memory_operand")]
> +   UNSPEC_MASKLOAD))]
> +  "TARGET_AVX512F"
> +  "#"
> +  "&& 1"
> +  [(set (match_dup 0) (match_dup 1))])

It is certainly good to have these insns and splitters, but
the reason I think it is very much desirable to handle this during expansion
too is to avoid creating the UNSPECs in the very common case where
either already from the user, or from all the GIMPLE optimizations the
mask is optimized into all ones.  The UNSPECs then can prevent various
optimizations before splitting is performed, because generic RTL optimizers
don't know anything about what it does.  While for all ones mask it is
easily expressible in RTL by having the most simple RTL for that, plain
load.

Jakub

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

[Stefan Kanthak]

Andreas Schwab wrote 2020-11-11:

> On Nov 10 2020, Stefan Kanthak wrote:
> 
>> Eric Botcazou  wrote:
>>
 The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() 
 functions
 is rather bad, it yields bad machine code at least on i386 and AMD64. Since
 GCC knows how to shift integers twice the register size these functions can
 be written as one-liners.
>>> 
>>> These functions are precisely meant to be used when GCC cannot do that.
>>
>> On which processor(s) is GCC unable to generate code for DWtype shifts?
> 
> On most 32-bit targets with -Os.

--- counter-FUD-example.c ---
long long __ashldi3 (long long value, int count) {
return value << count;
}

long long __ashrdi3 (unsigned long long value, int count) {
return value >> count;
}

unsigned long long __lshrdi3 (unsigned long long value, int count) {
return value >> count;
}

// just for completeness sake:

unsigned long long __lshldi3 (unsigned long long value, int count) {
return value << count;
}

extern   signed long long  left,  right;
extern unsigned long long uleft, uright;

int main(int argc, char **argv) {
   left <<= argc;
   right >>= argc;
   uleft <<= argc;
   uright >>= argc;
}
--- EOF ---

lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
...
Model name:AMD EPYC 7262 8-Core Processor
...
gcc -m32  -o- -Os -S counter-FUD-example.c | fgrep 'call'
gcc -m32 -mno-sse -o- -Os -S counter-FUD-example.c | fgrep 'call'

'nuff said
Stefan

JTFR: without -mno-sse, GCC (at least version 8.4) generates rather
  awful and DEFINITELY LONGER code (42 vs. 38) bytes than with
  -mno-sse, i.e. -Os is buggy too!

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

[Andreas Schwab]

On Nov 24 2020, Stefan Kanthak wrote:

> 'nuff said

What's your point?

Andreas.

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

[committed] libstdc++: Use __libc_single_threaded for locale initialization

[Jonathan Wakely via Gcc-patches]

Most initialization of locales and facets happens before main() during
startup, when the program is likely to only have one thread. By using
the new __gnu_cxx::__is_single_threaded() function instead of checking
__gthread_active_p() we can avoid using pthread_once or atomics for the
common case.

That said, I'm not sure why we don't just use a local static variable
instead, as __cxa_guard_acquire() already optimizes for the
single-threaded case:

  static const bool init = (_S_initialize_once(), true);

I'll revisit that for GCC 12.

libstdc++-v3/ChangeLog:

* src/c++98/locale.cc (locale::facet::_S_get_c_locale())
(locale::id::_M_id() const): Use __is_single_threaded.
* src/c++98/locale_init.cc (locale::_S_initialize()):
Likewise.

Tested powerpc64le-linux. Committed to trunk.

commit e253d36214015ed10ffd335e3628ccaac22dd5c7
Author: Jonathan Wakely 
Date:   Tue Nov 24 12:29:30 2020

libstdc++: Use __libc_single_threaded for locale initialization

Most initialization of locales and facets happens before main() during
startup, when the program is likely to only have one thread. By using
the new __gnu_cxx::__is_single_threaded() function instead of checking
__gthread_active_p() we can avoid using pthread_once or atomics for the
common case.

That said, I'm not sure why we don't just use a local static variable
instead, as __cxa_guard_acquire() already optimizes for the
single-threaded case:

  static const bool init = (_S_initialize_once(), true);

I'll revisit that for GCC 12.

libstdc++-v3/ChangeLog:

* src/c++98/locale.cc (locale::facet::_S_get_c_locale())
(locale::id::_M_id() const): Use __is_single_threaded.
* src/c++98/locale_init.cc (locale::_S_initialize()):
Likewise.

diff --git a/libstdc++-v3/src/c++98/locale.cc b/libstdc++-v3/src/c++98/locale.cc
index 06422412039c..9b3fc3515152 100644
--- a/libstdc++-v3/src/c++98/locale.cc
+++ b/libstdc++-v3/src/c++98/locale.cc
@@ -214,7 +214,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   locale::facet::_S_get_c_locale()
   {
 #ifdef __GTHREADS
-if (__gthread_active_p())
+if (!__gnu_cxx::__is_single_threaded())
   __gthread_once(&_S_once, _S_initialize_once);
 else
 #endif
@@ -515,7 +515,7 @@ namespace {
 #endif
 
 #ifdef __GTHREADS
-   if (__gthread_active_p())
+   if (!__gnu_cxx::__is_single_threaded())
  {
if (__atomic_always_lock_free(sizeof(_M_index), &_M_index))
  {
diff --git a/libstdc++-v3/src/c++98/locale_init.cc 
b/libstdc++-v3/src/c++98/locale_init.cc
index c3841ccbd3c9..fc8416ba01a6 100644
--- a/libstdc++-v3/src/c++98/locale_init.cc
+++ b/libstdc++-v3/src/c++98/locale_init.cc
@@ -320,7 +320,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   locale::_S_initialize()
   {
 #ifdef __GTHREADS
-if (__gthread_active_p())
+if (!__gnu_cxx::__is_single_threaded())
   __gthread_once(&_S_once, _S_initialize_once);
 #endif
 if (!_S_classic)

[committed] libstdc++: Throw instead of segfaulting in std::thread constructor [PR 67791]

[Jonathan Wakely via Gcc-patches]

This turns a mysterious segfault into an exception with a more useful
message. If the exception isn't caught, the user sees this instead of
just a segfault:

terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted
Aborted (core dumped)

libstdc++-v3/ChangeLog:

PR libstdc++/67791
* src/c++11/thread.cc (thread::_M_start_thread(_State_ptr, void (*)())):
Check that gthreads is available before calling __gthread_create.

Tested powerpc64le-linux. Committed to trunk.

commit 4bbd5d0c5fb2b7527938ad44a6d8a2f2ef8bbe12
Author: Jonathan Wakely 
Date:   Tue Nov 24 12:48:31 2020

libstdc++: Throw instead of segfaulting in std::thread constructor [PR 
67791]

This turns a mysterious segfault into an exception with a more useful
message. If the exception isn't caught, the user sees this instead of
just a segfault:

terminate called after throwing an instance of 'std::system_error'
  what():  Enable multithreading to use std::thread: Operation not permitted
Aborted (core dumped)

libstdc++-v3/ChangeLog:

PR libstdc++/67791
* src/c++11/thread.cc (thread::_M_start_thread(_State_ptr, void 
(*)())):
Check that gthreads is available before calling __gthread_create.

diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index e4dd1687a4b2..a9c928049599 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -133,6 +133,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   void
   thread::_M_start_thread(_State_ptr state, void (*)())
   {
+if (!__gthread_active_p())
+  {
+#if __cpp_exceptions
+   throw system_error(make_error_code(errc::operation_not_permitted),
+  "Enable multithreading to use std::thread");
+#else
+   __builtin_abort();
+#endif
+  }
+
 const int err = __gthread_create(&_M_id._M_thread,
 &execute_native_thread_routine,
 state.get());

[committed] amdgcn: Tweak plugin-gcn defines

[Andrew Stubbs]

This tiny patch just cleans up some defines in the libgomp GCN plugin.

The code wouldn't compile, as it was, if elf.h is updated to support GCN 
relocations. This should fix that. The other user, mkoffload.c, was 
already fixed.


Andrew
Tweak plugin-gcn.c defines

Ensure the code will continue to compile when elf.h gets these definitions.

libgomp/ChangeLog:

	* plugin/plugin-gcn.c: Don't redefine relocations if elf.h has them.
	(reserved): Delete unused define.

diff --git a/libgomp/plugin/plugin-gcn.c b/libgomp/plugin/plugin-gcn.c
index 0be350bba28..ebb6fbcfdba 100644
--- a/libgomp/plugin/plugin-gcn.c
+++ b/libgomp/plugin/plugin-gcn.c
@@ -52,6 +52,7 @@
 #define HSA_AMD_AGENT_INFO_COMPUTE_UNIT_COUNT 0xA002
 
 /* These probably won't be in elf.h for a while.  */
+#ifndef R_AMDGPU_NONE
 #define R_AMDGPU_NONE		0
 #define R_AMDGPU_ABS32_LO	1	/* (S + A) & 0x  */
 #define R_AMDGPU_ABS32_HI	2	/* (S + A) >> 32  */
@@ -64,8 +65,8 @@
 #define R_AMDGPU_GOTPCREL32_HI	9	/* (G + GOT + A - P) >> 32  */
 #define R_AMDGPU_REL32_LO	10	/* (S + A - P) & 0x  */
 #define R_AMDGPU_REL32_HI	11	/* (S + A - P) >> 32  */
-#define reserved		12
 #define R_AMDGPU_RELATIVE64	13	/* B + A  */
+#endif
 
 /* GCN specific definitions for asynchronous queues.  */
 

[committed] aarch64: Fix aapcs64 testsuite failures

[Richard Sandiford via Gcc-patches]

Various aapcs64 tests were failing at -O1 and above because
the assignments to testfunc_ptr were being deleted as dead.
That in turn happened because FUNC_VAL_CHECK hid the tail call
to myfunc using an LR asm trick:

asm volatile ("mov %0, x30" : "=r" (saved_return_address));
asm volatile ("mov x30, %0" : : "r" ((unsigned long long) myfunc));

and so the compiler couldn't see any calls that might read
testfunc_ptr.

That in itself could be fixed by adding a memory clobber to the
second asm above, forcing the compiler to keep both the testfunc_ptr
and the saved_return_address assignments.  But since this is an ABI
test, it seems better to make sure that we don't do any IPA at all.
The fact that doing IPA caused a problem was kind-of helpful and
so it might be better to avoid making the test “work” in the
presence of IPA.

The patch therefore just replaced “noinline” with “noipa”.

Tested on aarch64-linux-gnu and applied.

Richard


gcc/testsuite/
* gcc.target/aarch64/aapcs64/abitest.h (FUNC_VAL_CHECK): Use
noipa rather than noinline.
* gcc.target/aarch64/aapcs64/abitest-2.h (FUNC_VAL_CHECK): Likewise.
---
 gcc/testsuite/gcc.target/aarch64/aapcs64/abitest-2.h | 2 +-
 gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.h   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest-2.h 
b/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest-2.h
index 57492197e5f..b917938884b 100644
--- a/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest-2.h
+++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest-2.h
@@ -66,7 +66,7 @@ MYFUNCTYPE myfunc () PCSATTR;
of bugs like a short vector being returned in X0 after copied from V0.  */
 #undef FUNC_VAL_CHECK
 #define FUNC_VAL_CHECK(id, type, var, offset, layout)\
-__attribute__ ((noinline)) type FUNC_NAME (id) (int i, double d, type t)  \
+__attribute__ ((noipa)) type FUNC_NAME (id) (int i, double d, type t)\
   {  \
 asm (""::"r" (i),"r" (d)); /* asm prevents function from getting  \
  optimized away.  Using i and d prevents \
diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.h 
b/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.h
index af70937e047..667f4d0f2dd 100644
--- a/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.h
+++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/abitest.h
@@ -73,7 +73,7 @@ MYFUNCTYPE myfunc(
 
 /* Dummy function to help reset parameter passing registers, i.e. X0-X7
and V0-V7 (by being passed 0 in W0-W7 and 0.f in S0-S7).  */
-__attribute__ ((noinline)) void
+__attribute__ ((noipa)) void
 dummy_func (int w0, int w1, int w2, int w3, int w4, int w5, int w6, int w7,
float s0, float s1, float s2, float s3, float s4, float s5,
float s6, float s7)

Re: [PATCH] libstdc++: Ensure __gthread_self doesn't call undefined weak symbol [PR 95989]

[Jonathan Wakely via Gcc-patches]

On 19/11/20 21:42 +, Jonathan Wakely wrote:

On 12/11/20 17:34 +, Jonathan Wakely wrote:

On 11/11/20 19:08 +0100, Jakub Jelinek via Libstdc++ wrote:

On Wed, Nov 11, 2020 at 05:24:42PM +, Jonathan Wakely wrote:

--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -684,7 +684,14 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
static inline __gthread_t
__gthread_self (void)
{
+#if __GLIBC_PREREQ(2, 27)


What if it is a non-glibc system where __GLIBC_PREREQ macro isn't defined?
I think you'd get then
error: missing binary operator before token "("
So I think you want
#if defined __GLIBC__ && defined __GLIBC_PREREQ
#if __GLIBC_PREREQ(2, 27)
return pthread_self ();
#else
return __gthrw_(pthread_self) ();
#else
return __gthrw_(pthread_self) ();
#endif
or similar.



Here's a fixed version of the patch.

I've moved the glibc-specific code in this_thread::get_id() into a new
macro defined in config/os/gnu-linux/os_defines.h (where we already
know we are dealing with glibc). That means we don't do the
__GLIBC_PREREQ check directly in , it's hidden away in a
target-specific header.

Tested powerpc64le-linux (glibc 2.17 and 2.32), sparc-solaris2.11 and
powerpc-aix.


I've committed this version which only fixes this_thread::get_id() in
libstdc++, and doesn't change __gthread_self in gthr-posix.h

Due to a recent change to replace other uses of __gthread_self with
calls to this_thread::get_id(), fixing it there fixes all uses in
libstdc++.

Tested x86_64-linux, powerpc-aix, sparc-solaris2.11, committed to
trunk.




diff --git a/libstdc++-v3/testsuite/30_threads/jthread/95989.cc 
b/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
new file mode 100644
index ..46444b5ccabc
--- /dev/null
+++ b/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
@@ -0,0 +1,54 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+// { dg-require-gthreads {} }
+// { dg-additional-options "-pthread" { target pthread } }
+// { dg-additional-options "-static" { target static } }
+
+#include 
+
+// PR libstdc++/95989
+// Segfault compiling with static libraries and using jthread::request_stop
+
+void
+test01()
+{
+  std::jthread t{ [] () {} };
+}
+
+void
+test02()
+{
+  std::jthread t{ [] () {} };
+  t.request_stop();
+}
+
+void
+test03()
+{
+  std::jthread t{ [] {} };
+  std::stop_callback cb(t.get_stop_token(), [] () {});
+}
+
+int
+main()
+{
+  test01();
+  test01();
+}


This test runs test01 twice, which isn't what I meant to do.

Fixed by this patch (but the test is still failing, see PR 97944).

Committed to trunk.


commit 7e0078f8643f9204777152ed0f915b52072a05c8
Author: Jonathan Wakely 
Date:   Tue Nov 24 13:11:13 2020

libstdc++: Run all tests in file

libstdc++-v3/ChangeLog:

* testsuite/30_threads/jthread/95989.cc: Run all three test
functions, not just the first one twice.

diff --git a/libstdc++-v3/testsuite/30_threads/jthread/95989.cc b/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
index 46444b5ccabc..c7a9430eee90 100644
--- a/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
+++ b/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
@@ -50,5 +50,6 @@ int
 main()
 {
   test01();
-  test01();
+  test02();
+  test03();
 }

Free more of CFG in release_function_body

[Jan Hubicka]

Hi,
at the end of processing function body we loop over basic blocks and
free all edges while we do not free the rest.  I think this is leftover
from time eges was not garbage collected and we was not using ggc_free.
It makes more sense to free all associated structures (which is
importnat for WPA memory footprint).

Bootstrapped/regtested x86_64-linux, OK?

Honza

* cfg.c (free_block): New function.
(clear_edges): Rename to 
(free_cfg): ... this one; also free BBs and vectors.
(expunge_block): Update comment.
* cfg.h (clear_edges): Rename to ...
(free_cfg): ... this one.
* cgraph.c (release_function_body): Use free_cfg.
diff --git a/gcc/cfg.c b/gcc/cfg.c
index de0e71db850..fc78e48d6e1 100644
--- a/gcc/cfg.c
+++ b/gcc/cfg.c
@@ -25,7 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 
Available functionality:
  - Initialization/deallocation
-init_flow, clear_edges
+init_flow, free_cfg
  - Low level basic block manipulation
 alloc_block, expunge_block
  - Edge manipulation
@@ -83,7 +83,7 @@ init_flow (struct function *the_fun)
   the_fun->cfg->bb_flags_allocated = BB_ALL_FLAGS;
 }
 
-/* Helper function for remove_edge and clear_edges.  Frees edge structure
+/* Helper function for remove_edge and free_cffg.  Frees edge structure
without actually removing it from the pred/succ arrays.  */
 
 static void
@@ -93,29 +93,41 @@ free_edge (function *fn, edge e)
   ggc_free (e);
 }
 
-/* Free the memory associated with the edge structures.  */
+/* Free basic block BB.  */
+
+static void
+free_block (basic_block bb)
+{
+   vec_free (bb->succs);
+   vec_free (bb->preds);
+   ggc_free (bb);
+}
+
+/* Free the memory associated with the CFG in FN.  */
 
 void
-clear_edges (struct function *fn)
+free_cfg (struct function *fn)
 {
-  basic_block bb;
   edge e;
   edge_iterator ei;
+  basic_block next;
 
-  FOR_EACH_BB_FN (bb, fn)
+  for (basic_block bb = ENTRY_BLOCK_PTR_FOR_FN (fn); bb; bb = next)
 {
+  next = bb->next_bb;
   FOR_EACH_EDGE (e, ei, bb->succs)
free_edge (fn, e);
-  vec_safe_truncate (bb->succs, 0);
-  vec_safe_truncate (bb->preds, 0);
+  free_block (bb);
 }
 
-  FOR_EACH_EDGE (e, ei, ENTRY_BLOCK_PTR_FOR_FN (fn)->succs)
-free_edge (fn, e);
-  vec_safe_truncate (EXIT_BLOCK_PTR_FOR_FN (fn)->preds, 0);
-  vec_safe_truncate (ENTRY_BLOCK_PTR_FOR_FN (fn)->succs, 0);
-
   gcc_assert (!n_edges_for_fn (fn));
+  /* Sanity check that dominance tree is freed.  */
+  gcc_assert (!fn->cfg->x_dom_computed[0] && !fn->cfg->x_dom_computed[1]);
+  
+  vec_free (fn->cfg->x_label_to_block_map);
+  vec_free (basic_block_info_for_fn (fn));
+  ggc_free (fn->cfg);
+  fn->cfg = NULL;
 }
 
 /* Allocate memory for basic_block.  */
@@ -190,8 +202,8 @@ expunge_block (basic_block b)
   /* We should be able to ggc_free here, but we are not.
  The dead SSA_NAMES are left pointing to dead statements that are pointing
  to dead basic blocks making garbage collector to die.
- We should be able to release all dead SSA_NAMES and at the same time we 
should
- clear out BB pointer of dead statements consistently.  */
+ We should be able to release all dead SSA_NAMES and at the same time we
+ should clear out BB pointer of dead statements consistently.  */
 }
 
 /* Connect E to E->src.  */
diff --git a/gcc/cfg.h b/gcc/cfg.h
index 93fde6df2bf..a9c8300f173 100644
--- a/gcc/cfg.h
+++ b/gcc/cfg.h
@@ -82,7 +82,7 @@ struct GTY(()) control_flow_graph {
 
 
 extern void init_flow (function *);
-extern void clear_edges (function *);
+extern void free_cfg (function *);
 extern basic_block alloc_block (void);
 extern void link_block (basic_block, basic_block);
 extern void unlink_block (basic_block);
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 19dfe2be23b..5c48a1bb92b 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -1811,7 +1811,7 @@ release_function_body (tree decl)
  gcc_assert (!dom_info_available_p (fn, CDI_DOMINATORS));
  gcc_assert (!dom_info_available_p (fn, CDI_POST_DOMINATORS));
  delete_tree_cfg_annotations (fn);
- clear_edges (fn);
+ free_cfg (fn);
  fn->cfg = NULL;
}
   if (fn->value_histograms)

Re: H8 cc0 conversion

[Jeff Law via Gcc-patches]

On 11/24/20 4:08 AM, Eric Botcazou wrote:
>> I'm intested in any notes, however vague, on that matter.  I was
>> a bit surprised to see that myself...that is, after fixing
>> *some* related regressions, like the one in combine.  (Did I
>> actually miss something?)
> My recollection for the Visium port would align with what Jeff saw but, on 
> the 
> other hand, this could have been very marginal a phenomenon in the end.
I never tried to quantify it myself.  I certainly saw improvements
dropping the unnecessary clobbers from the shifting patterns on the H8
independently of the cc0 converseion.

jeff

libsanitizer: Hwasan reporting check for dladdr failing

[Matthew Malcomson via Gcc-patches]

Hello there,

This is the compiler-rt patch I'd like to cherry-pick so that the hwasan tests
pass.

It is in LLVM as commit 83ac18205ec69a00ac2be3b603bc3a61293fbe89.

Ok for trunk?

Also is the libhwasan library merge from the below email OK for trunk?
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558999.html
(Note I would also add a line to README.gcc mentioning compiler-rt/lib/hwasan
on top of the changes in that patch).

I would guess so, but wasn't certain the OK had ever been said anywhere.

Regards,
Matthew

-


In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the
current address.  `dladdr` returns 0 if it failed.
During testing on Linux this returned 0 to indicate failure, and
populated the `info` structure with a NULL pointer which was
dereferenced later.

This patch checks for `dladdr` returning 0, and in that case returns 0
from `GetGlobalSizeFromDescriptor` to indicate failure of identifying
the address.

This occurs when `GetModuleNameAndOffsetForPC` succeeds for some address
not in a dynamically loaded library.  One example is when the found
"module" is '[stack]' having come from parsing /proc/self/maps.

Cherry-pick from 83ac18205ec69a00ac2be3b603bc3a61293fbe89.

Differential Revision: https://reviews.llvm.org/D91344


### Attachment also inlined for ease of reply###


diff --git a/libsanitizer/hwasan/hwasan_report.cpp 
b/libsanitizer/hwasan/hwasan_report.cpp
index 
0be7deeaee1a0bd523d9e0fe1dc3b1311b3920e2..894a149775f291bae9cad833b1ac54914212f405
 100644
--- a/libsanitizer/hwasan/hwasan_report.cpp
+++ b/libsanitizer/hwasan/hwasan_report.cpp
@@ -254,7 +254,8 @@ static bool TagsEqual(tag_t tag, tag_t *tag_ptr) {
 static uptr GetGlobalSizeFromDescriptor(uptr ptr) {
   // Find the ELF object that this global resides in.
   Dl_info info;
-  dladdr(reinterpret_cast(ptr), &info);
+  if (dladdr(reinterpret_cast(ptr), &info) == 0)
+return 0;
   auto *ehdr = reinterpret_cast(info.dli_fbase);
   auto *phdr_begin = reinterpret_cast(
   reinterpret_cast(ehdr) + ehdr->e_phoff);

diff --git a/libsanitizer/hwasan/hwasan_report.cpp 
b/libsanitizer/hwasan/hwasan_report.cpp
index 
0be7deeaee1a0bd523d9e0fe1dc3b1311b3920e2..894a149775f291bae9cad833b1ac54914212f405
 100644
--- a/libsanitizer/hwasan/hwasan_report.cpp
+++ b/libsanitizer/hwasan/hwasan_report.cpp
@@ -254,7 +254,8 @@ static bool TagsEqual(tag_t tag, tag_t *tag_ptr) {
 static uptr GetGlobalSizeFromDescriptor(uptr ptr) {
   // Find the ELF object that this global resides in.
   Dl_info info;
-  dladdr(reinterpret_cast(ptr), &info);
+  if (dladdr(reinterpret_cast(ptr), &info) == 0)
+return 0;
   auto *ehdr = reinterpret_cast(info.dli_fbase);
   auto *phdr_begin = reinterpret_cast(
   reinterpret_cast(ehdr) + ehdr->e_phoff);

Re: How to traverse all the local variables that declared in the current routine?

[Qing Zhao via Gcc-patches]

> On Nov 24, 2020, at 1:32 AM, Richard Biener  
> wrote:
> 
> On Tue, Nov 24, 2020 at 12:05 AM Qing Zhao via Gcc-patches
>  wrote:
>> 
>> Hi,
>> 
>> Does gcc provide an iterator to traverse all the local variables that are 
>> declared in the current routine?
>> 
>> If not, what’s the best way to traverse the local variables?
> 
> Depends on what for.  There's the source level view you get by walking
> BLOCK_VARS of the
> scope tree, theres cfun->local_variables (FOR_EACH_LOCAL_DECL) and
> there's SSA names
> (FOR_EACH_SSA_NAME).

I am planing to add a new phase immediately after 
“pass_late_warn_uninitialized” to initialize all auto-variables that are
not explicitly initialized in the declaration, the basic idea is following:

** The proposal:

A. add a new GCC option: (same name and meaning as CLANG)
-ftrivial-auto-var-init=[pattern|zero], similar pattern init as CLANG;

B. add a new attribute for variable:
__attribute((uninitialized)
the marked variable is uninitialized intentionaly for performance purpose.

C. The implementation needs to keep the current static warning on uninitialized
variables untouched in order to avoid "forking the language".


** The implementation:

There are two major requirements for the implementation:

1. all auto-variables that do not have an explicit initializer should be 
initialized to
zero by this option.  (Same behavior as CLANG)

2. keep the current static warning on uninitialized variables untouched.

In order to satisfy 1, we should check whether an auto-variable has initializer
or not;
In order to satisfy 2, we should add this new transformation after
"pass_late_warn_uninitialized".

So, we should be able to check whether an auto-variable has initializer or not 
after “pass_late_warn_uninitialized”, 
If Not, then insert an initialization for it. 

For this purpose, I guess that “FOR_EACH_LOCAL_DECL” might be better?

Another issue is, in order to check whether an auto-variable has initializer, I 
plan to add a new bit in “decl_common” as:
  /* In a VAR_DECL, this is DECL_IS_INITIALIZED.  */
  unsigned decl_is_initialized :1;

/* IN VAR_DECL, set when the decl is initialized at the declaration.  */
#define DECL_IS_INITIALIZED(NODE) \
  (DECL_COMMON_CHECK (NODE)->decl_common.decl_is_initialized)

set this bit when setting DECL_INITIAL for the variables in FE. then keep it
even though DECL_INITIAL might be NULLed.

Do you have any comment and suggestions?

Thanks a lot for the help.

Qing

> Richard.
> 
>> 
>> Thanks.
>> 
>> Qing

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

[Stefan Kanthak]

Andreas Schwab wrote:

> On Nov 24 2020, Stefan Kanthak wrote:
> 
>> 'nuff said
> 
> What's your point?

Pinpoint deficiencies and bugs in GCC and libgcc, plus a counter
example to your "argument"!
I recommend careful reading.

Stefan

Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function

[Andreas Schwab]

On Nov 24 2020, Stefan Kanthak wrote:

> Pinpoint deficiencies and bugs in GCC and libgcc, plus a counter
> example to your "argument"!

In which way?

> I recommend careful reading.

Yes, I do.

Andreas.

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

Re: Free more of CFG in release_function_body

[Richard Biener]

On Tue, 24 Nov 2020, Jan Hubicka wrote:

> Hi,
> at the end of processing function body we loop over basic blocks and
> free all edges while we do not free the rest.  I think this is leftover
> from time eges was not garbage collected and we was not using ggc_free.
> It makes more sense to free all associated structures (which is
> importnat for WPA memory footprint).
> 
> Bootstrapped/regtested x86_64-linux, OK?

OK.

> Honza
> 
>   * cfg.c (free_block): New function.
>   (clear_edges): Rename to 
>   (free_cfg): ... this one; also free BBs and vectors.
>   (expunge_block): Update comment.
>   * cfg.h (clear_edges): Rename to ...
>   (free_cfg): ... this one.
>   * cgraph.c (release_function_body): Use free_cfg.
> diff --git a/gcc/cfg.c b/gcc/cfg.c
> index de0e71db850..fc78e48d6e1 100644
> --- a/gcc/cfg.c
> +++ b/gcc/cfg.c
> @@ -25,7 +25,7 @@ along with GCC; see the file COPYING3.  If not see
>  
> Available functionality:
>   - Initialization/deallocation
> -  init_flow, clear_edges
> +  init_flow, free_cfg
>   - Low level basic block manipulation
>alloc_block, expunge_block
>   - Edge manipulation
> @@ -83,7 +83,7 @@ init_flow (struct function *the_fun)
>the_fun->cfg->bb_flags_allocated = BB_ALL_FLAGS;
>  }
>  
> -/* Helper function for remove_edge and clear_edges.  Frees edge structure
> +/* Helper function for remove_edge and free_cffg.  Frees edge structure
> without actually removing it from the pred/succ arrays.  */
>  
>  static void
> @@ -93,29 +93,41 @@ free_edge (function *fn, edge e)
>ggc_free (e);
>  }
>  
> -/* Free the memory associated with the edge structures.  */
> +/* Free basic block BB.  */
> +
> +static void
> +free_block (basic_block bb)
> +{
> +   vec_free (bb->succs);
> +   vec_free (bb->preds);
> +   ggc_free (bb);
> +}
> +
> +/* Free the memory associated with the CFG in FN.  */
>  
>  void
> -clear_edges (struct function *fn)
> +free_cfg (struct function *fn)
>  {
> -  basic_block bb;
>edge e;
>edge_iterator ei;
> +  basic_block next;
>  
> -  FOR_EACH_BB_FN (bb, fn)
> +  for (basic_block bb = ENTRY_BLOCK_PTR_FOR_FN (fn); bb; bb = next)
>  {
> +  next = bb->next_bb;
>FOR_EACH_EDGE (e, ei, bb->succs)
>   free_edge (fn, e);
> -  vec_safe_truncate (bb->succs, 0);
> -  vec_safe_truncate (bb->preds, 0);
> +  free_block (bb);
>  }
>  
> -  FOR_EACH_EDGE (e, ei, ENTRY_BLOCK_PTR_FOR_FN (fn)->succs)
> -free_edge (fn, e);
> -  vec_safe_truncate (EXIT_BLOCK_PTR_FOR_FN (fn)->preds, 0);
> -  vec_safe_truncate (ENTRY_BLOCK_PTR_FOR_FN (fn)->succs, 0);
> -
>gcc_assert (!n_edges_for_fn (fn));
> +  /* Sanity check that dominance tree is freed.  */
> +  gcc_assert (!fn->cfg->x_dom_computed[0] && !fn->cfg->x_dom_computed[1]);
> +  
> +  vec_free (fn->cfg->x_label_to_block_map);
> +  vec_free (basic_block_info_for_fn (fn));
> +  ggc_free (fn->cfg);
> +  fn->cfg = NULL;
>  }
>  
>  /* Allocate memory for basic_block.  */
> @@ -190,8 +202,8 @@ expunge_block (basic_block b)
>/* We should be able to ggc_free here, but we are not.
>   The dead SSA_NAMES are left pointing to dead statements that are 
> pointing
>   to dead basic blocks making garbage collector to die.
> - We should be able to release all dead SSA_NAMES and at the same time we 
> should
> - clear out BB pointer of dead statements consistently.  */
> + We should be able to release all dead SSA_NAMES and at the same time we
> + should clear out BB pointer of dead statements consistently.  */
>  }
>  
>  /* Connect E to E->src.  */
> diff --git a/gcc/cfg.h b/gcc/cfg.h
> index 93fde6df2bf..a9c8300f173 100644
> --- a/gcc/cfg.h
> +++ b/gcc/cfg.h
> @@ -82,7 +82,7 @@ struct GTY(()) control_flow_graph {
>  
>  
>  extern void init_flow (function *);
> -extern void clear_edges (function *);
> +extern void free_cfg (function *);
>  extern basic_block alloc_block (void);
>  extern void link_block (basic_block, basic_block);
>  extern void unlink_block (basic_block);
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 19dfe2be23b..5c48a1bb92b 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -1811,7 +1811,7 @@ release_function_body (tree decl)
> gcc_assert (!dom_info_available_p (fn, CDI_DOMINATORS));
> gcc_assert (!dom_info_available_p (fn, CDI_POST_DOMINATORS));
> delete_tree_cfg_annotations (fn);
> -   clear_edges (fn);
> +   free_cfg (fn);
> fn->cfg = NULL;
>   }
>if (fn->value_histograms)
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend

RE: libsanitizer: Hwasan reporting check for dladdr failing

[Kyrylo Tkachov via Gcc-patches]

Hi Matthew,

> -Original Message-
> From: Gcc-patches  On Behalf Of
> Matthew Malcomson via Gcc-patches
> Sent: 24 November 2020 15:47
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford 
> Subject: libsanitizer: Hwasan reporting check for dladdr failing
> 
> Hello there,
> 
> This is the compiler-rt patch I'd like to cherry-pick so that the hwasan tests
> pass.
> 
> It is in LLVM as commit 83ac18205ec69a00ac2be3b603bc3a61293fbe89.
> 
> Ok for trunk?
> 
> Also is the libhwasan library merge from the below email OK for trunk?
> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558999.html
> (Note I would also add a line to README.gcc mentioning compiler-
> rt/lib/hwasan
> on top of the changes in that patch).
> 
> I would guess so, but wasn't certain the OK had ever been said anywhere.

I believe merges from an upstream are generally considered pre-approved. In any 
case, I see that merge committed as 98f792ff538109c71d85ab2a61461cd090f3b9f3

Thanks,
Kyrill

> 
> Regards,
> Matthew
> 
> -
> 
> 
> In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the
> current address.  `dladdr` returns 0 if it failed.
> During testing on Linux this returned 0 to indicate failure, and
> populated the `info` structure with a NULL pointer which was
> dereferenced later.
> 
> This patch checks for `dladdr` returning 0, and in that case returns 0
> from `GetGlobalSizeFromDescriptor` to indicate failure of identifying
> the address.
> 
> This occurs when `GetModuleNameAndOffsetForPC` succeeds for some
> address
> not in a dynamically loaded library.  One example is when the found
> "module" is '[stack]' having come from parsing /proc/self/maps.
> 
> Cherry-pick from 83ac18205ec69a00ac2be3b603bc3a61293fbe89.
> 
> Differential Revision: https://reviews.llvm.org/D91344
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/libsanitizer/hwasan/hwasan_report.cpp
> b/libsanitizer/hwasan/hwasan_report.cpp
> index
> 0be7deeaee1a0bd523d9e0fe1dc3b1311b3920e2..894a149775f291bae9cad8
> 33b1ac54914212f405 100644
> --- a/libsanitizer/hwasan/hwasan_report.cpp
> +++ b/libsanitizer/hwasan/hwasan_report.cpp
> @@ -254,7 +254,8 @@ static bool TagsEqual(tag_t tag, tag_t *tag_ptr) {
>  static uptr GetGlobalSizeFromDescriptor(uptr ptr) {
>// Find the ELF object that this global resides in.
>Dl_info info;
> -  dladdr(reinterpret_cast(ptr), &info);
> +  if (dladdr(reinterpret_cast(ptr), &info) == 0)
> +return 0;
>auto *ehdr = reinterpret_cast(info.dli_fbase);
>auto *phdr_begin = reinterpret_cast(
>reinterpret_cast(ehdr) + ehdr->e_phoff);

Re: [PATCH] dump type attributes in dump_function_to_file

[Martin Sebor via Gcc-patches]

On 11/23/20 9:31 PM, Jeff Law wrote:



On 11/20/20 4:14 PM, Jeff Law wrote:


On 11/20/20 11:12 AM, Martin Sebor via Gcc-patches wrote:

dump_function_to_file prints DECL_ATTRIBUTES but not TYPE_ATTRIBUTES
when both can be important and helpful for debugging, especially with
attributes that are added implicitly (such attribute access and
the proposed internal attribute *dealloc).  The function also prints
function arguments (and their types) but not its return type, again,
leaving out a useful detail.  The attached tweak adds both to
the dump.

Martin

gcc-dump-type-attr.diff

gcc/ChangeLog:

* gcc/tree-cfg.c (dump_function_to_file): Print type attributes
and return type.

gcc/testsuite/ChangeLog:
* gcc.dg/attr-access-4.c: New test.

So was this actually regression tested?  Even tests that change dump
files need to be regression tested because some of the tests scan those
dump files.

I'm seeing this on several targets:

Tests that now fail, but worked before (6 tests):

xstormy16-sim: gcc.dg/tree-ssa/pr23401.c scan-tree-dump-times gimple "int" 5
xstormy16-sim: gcc.dg/tree-ssa/pr23401.c scan-tree-dump-times gimple "int" 5
xstormy16-sim: gcc.dg/tree-ssa/pr27810.c scan-tree-dump-times gimple "int" 3
xstormy16-sim: gcc.dg/tree-ssa/pr27810.c scan-tree-dump-times gimple "int" 3
xstormy16-sim: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\* 
" 9
xstormy16-sim: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\* 
" 9



 From my quick reading, these tests are likely failing across the board.


It was tested with the results below.  I looked onto the jit
failures (test-combination.c.exe etc.) but overlooked those
in the tree-ssa directory because of all the perpetual guality
clutter.

!  FAIL: gcc.dg/atomic/pr65345-4.c (4: +4)ESC[0m
!  FAIL: gcc.dg/guality/loop-1.c (1: +1)ESC[0m
!  FAIL: gcc.dg/guality/pr36728-2.c (28: +28)ESC[0m
!  FAIL: gcc.dg/guality/pr36728-4.c (4: +4)ESC[0m
!  FAIL: gcc.dg/guality/pr41616-1.c (3: +3)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-1.c (8: +8)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-2.c (2: +2)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-3.c (8: +8)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-4.c (2: +2)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-5.c (2: +2)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-6.c (1: +1)ESC[0m
!  FAIL: gcc.dg/guality/pr56154-1.c (1: +1)ESC[0m
!  FAIL: gcc.dg/guality/pr59776.c (6: +6)ESC[0m
!  FAIL: gcc.dg/guality/pr90074.c (2: +2)ESC[0m
!  FAIL: gcc.dg/guality/pr90716.c (1: +1)ESC[0m
!  FAIL: gcc.dg/guality/sra-1.c (16: +16)ESC[0m
!  FAIL: gcc.dg/guality/vla-1.c (8: +8)ESC[0m
!  FAIL: gcc.dg/tree-ssa/pr23401.c (1: +1)ESC[0m
!  FAIL: gcc.dg/tree-ssa/pr27810.c (1: +1)ESC[0m
!  FAIL: gcc.dg/tree-ssa/slsr-8.c (1: +1)ESC[0m
!  FAIL: gdc.dg/intrinsics.d (3: +3)ESC[0m
!  FAIL: g++.dg/guality/pr55665.C (1: +1)ESC[0m
!  FAIL: gfortran.dg/gomp/declare-target-4.f90 (8: +8)ESC[0m
!  FAIL: test-combination.c.exe (1: +1)ESC[0m
!  FAIL: test-functions.c.exe (1: +1)ESC[0m
!  FAIL: test-pr66779.c.exe (1: +1)ESC[0m
!  FAIL: test-threads.c.exe (1: +1)ESC[0m
! XPASS: gcc.dg/analyzer/pr94851-1.c (1: +1)ESC[0m
! XPASS: gcc.dg/guality/example.c (3: +3)ESC[0m
! XPASS: gcc.dg/guality/guality.c (8: +8)ESC[0m
! XPASS: gcc.dg/guality/inline-params.c (5: +5)ESC[0m
! XPASS: gcc.dg/guality/pr41353-1.c (2: +2)ESC[0m
! XPASS: gcc.dg/guality/pr54970.c (16: +16)ESC[0m
! XPASS: gcc.dg/guality/pr59776.c (2: +2)ESC[0m



jeff

Re: How to traverse all the local variables that declared in the current routine?

[Richard Biener via Gcc-patches]

On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao  wrote:
>
>
>
> > On Nov 24, 2020, at 1:32 AM, Richard Biener  
> > wrote:
> >
> > On Tue, Nov 24, 2020 at 12:05 AM Qing Zhao via Gcc-patches
> >  wrote:
> >>
> >> Hi,
> >>
> >> Does gcc provide an iterator to traverse all the local variables that are 
> >> declared in the current routine?
> >>
> >> If not, what’s the best way to traverse the local variables?
> >
> > Depends on what for.  There's the source level view you get by walking
> > BLOCK_VARS of the
> > scope tree, theres cfun->local_variables (FOR_EACH_LOCAL_DECL) and
> > there's SSA names
> > (FOR_EACH_SSA_NAME).
>
> I am planing to add a new phase immediately after 
> “pass_late_warn_uninitialized” to initialize all auto-variables that are
> not explicitly initialized in the declaration, the basic idea is following:
>
> ** The proposal:
>
> A. add a new GCC option: (same name and meaning as CLANG)
> -ftrivial-auto-var-init=[pattern|zero], similar pattern init as CLANG;
>
> B. add a new attribute for variable:
> __attribute((uninitialized)
> the marked variable is uninitialized intentionaly for performance purpose.
>
> C. The implementation needs to keep the current static warning on 
> uninitialized
> variables untouched in order to avoid "forking the language".
>
>
> ** The implementation:
>
> There are two major requirements for the implementation:
>
> 1. all auto-variables that do not have an explicit initializer should be 
> initialized to
> zero by this option.  (Same behavior as CLANG)
>
> 2. keep the current static warning on uninitialized variables untouched.
>
> In order to satisfy 1, we should check whether an auto-variable has 
> initializer
> or not;
> In order to satisfy 2, we should add this new transformation after
> "pass_late_warn_uninitialized".
>
> So, we should be able to check whether an auto-variable has initializer or 
> not after “pass_late_warn_uninitialized”,
> If Not, then insert an initialization for it.
>
> For this purpose, I guess that “FOR_EACH_LOCAL_DECL” might be better?

Yes, but do you want to catch variables promoted to register as well
or just variables
on the stack?

> Another issue is, in order to check whether an auto-variable has initializer, 
> I plan to add a new bit in “decl_common” as:
>   /* In a VAR_DECL, this is DECL_IS_INITIALIZED.  */
>   unsigned decl_is_initialized :1;
>
> /* IN VAR_DECL, set when the decl is initialized at the declaration.  */
> #define DECL_IS_INITIALIZED(NODE) \
>   (DECL_COMMON_CHECK (NODE)->decl_common.decl_is_initialized)
>
> set this bit when setting DECL_INITIAL for the variables in FE. then keep it
> even though DECL_INITIAL might be NULLed.

For locals it would be more reliable to set this flag during gimplification.

> Do you have any comment and suggestions?

As said above - do you want to cover registers as well as locals?  I'd do
the actual zeroing during RTL expansion instead since otherwise you
have to figure youself whether a local is actually used (see expand_stack_vars)

Note that optimization will already made have use of "uninitialized" state
of locals so depending on what the actual goal is here "late" may be too late.

Richard.

>
> Thanks a lot for the help.
>
> Qing
>
> > Richard.
> >
> >>
> >> Thanks.
> >>
> >> Qing
>

Re: libsanitizer: Hwasan reporting check for dladdr failing

[Matthew Malcomson via Gcc-patches]

On 24/11/2020 15:53, Kyrylo Tkachov wrote:

Hi Matthew,


-Original Message-
From: Gcc-patches  On Behalf Of
Matthew Malcomson via Gcc-patches
Sent: 24 November 2020 15:47
To: gcc-patches@gcc.gnu.org
Cc: Richard Sandiford 
Subject: libsanitizer: Hwasan reporting check for dladdr failing

Hello there,

This is the compiler-rt patch I'd like to cherry-pick so that the hwasan tests
pass.

It is in LLVM as commit 83ac18205ec69a00ac2be3b603bc3a61293fbe89.

Ok for trunk?

Also is the libhwasan library merge from the below email OK for trunk?
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558999.html
(Note I would also add a line to README.gcc mentioning compiler-
rt/lib/hwasan
on top of the changes in that patch).

I would guess so, but wasn't certain the OK had ever been said anywhere.


I believe merges from an upstream are generally considered pre-approved. In any 
case, I see that merge committed as 98f792ff538109c71d85ab2a61461cd090f3b9f3

Thanks,
Kyrill


Thanks Kyrill,

For the record, 98f792ff538109c71d85ab2a61461cd090f3b9f3 is the merge 
without libhwasan part, while I was asking about the libhwasan part.


However, given the standard pre-approved merge from upstream status I 
guess it doesn't matter -- and that's good to know for the future too.


Thanks!
Matthew





Regards,
Matthew

-


In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the
current address.  `dladdr` returns 0 if it failed.
During testing on Linux this returned 0 to indicate failure, and
populated the `info` structure with a NULL pointer which was
dereferenced later.

This patch checks for `dladdr` returning 0, and in that case returns 0
from `GetGlobalSizeFromDescriptor` to indicate failure of identifying
the address.

This occurs when `GetModuleNameAndOffsetForPC` succeeds for some
address
not in a dynamically loaded library.  One example is when the found
"module" is '[stack]' having come from parsing /proc/self/maps.

Cherry-pick from 83ac18205ec69a00ac2be3b603bc3a61293fbe89.

Differential Revision: https://reviews.llvm.org/D91344


### Attachment also inlined for ease of reply
###


diff --git a/libsanitizer/hwasan/hwasan_report.cpp
b/libsanitizer/hwasan/hwasan_report.cpp
index
0be7deeaee1a0bd523d9e0fe1dc3b1311b3920e2..894a149775f291bae9cad8
33b1ac54914212f405 100644
--- a/libsanitizer/hwasan/hwasan_report.cpp
+++ b/libsanitizer/hwasan/hwasan_report.cpp
@@ -254,7 +254,8 @@ static bool TagsEqual(tag_t tag, tag_t *tag_ptr) {
  static uptr GetGlobalSizeFromDescriptor(uptr ptr) {
// Find the ELF object that this global resides in.
Dl_info info;
-  dladdr(reinterpret_cast(ptr), &info);
+  if (dladdr(reinterpret_cast(ptr), &info) == 0)
+return 0;
auto *ehdr = reinterpret_cast(info.dli_fbase);
auto *phdr_begin = reinterpret_cast(
reinterpret_cast(ehdr) + ehdr->e_phoff);

RE: libsanitizer: Hwasan reporting check for dladdr failing

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Matthew Malcomson 
> Sent: 24 November 2020 16:20
> To: Kyrylo Tkachov 
> Cc: Richard Sandiford ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: libsanitizer: Hwasan reporting check for dladdr failing
> 
> On 24/11/2020 15:53, Kyrylo Tkachov wrote:
> > Hi Matthew,
> >
> >> -Original Message-
> >> From: Gcc-patches  On Behalf Of
> >> Matthew Malcomson via Gcc-patches
> >> Sent: 24 November 2020 15:47
> >> To: gcc-patches@gcc.gnu.org
> >> Cc: Richard Sandiford 
> >> Subject: libsanitizer: Hwasan reporting check for dladdr failing
> >>
> >> Hello there,
> >>
> >> This is the compiler-rt patch I'd like to cherry-pick so that the hwasan 
> >> tests
> >> pass.
> >>
> >> It is in LLVM as commit 83ac18205ec69a00ac2be3b603bc3a61293fbe89.
> >>
> >> Ok for trunk?
> >>
> >> Also is the libhwasan library merge from the below email OK for trunk?
> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558999.html
> >> (Note I would also add a line to README.gcc mentioning compiler-
> >> rt/lib/hwasan
> >> on top of the changes in that patch).
> >>
> >> I would guess so, but wasn't certain the OK had ever been said anywhere.
> >
> > I believe merges from an upstream are generally considered pre-approved.
> In any case, I see that merge committed as
> 98f792ff538109c71d85ab2a61461cd090f3b9f3
> >
> > Thanks,
> > Kyrill
> 
> Thanks Kyrill,
> 
> For the record, 98f792ff538109c71d85ab2a61461cd090f3b9f3 is the merge
> without libhwasan part, while I was asking about the libhwasan part.
> 
> However, given the standard pre-approved merge from upstream status I
> guess it doesn't matter -- and that's good to know for the future too.

Ah, I suppose in the sanitiser case as there are local modifications maybe it's 
not a straightforward pre-approval, so don't take my word on it 😉
Martin will probably know the rules here.
Thanks,
Kyrill

> 
> Thanks!
> Matthew
> 
> >
> >>
> >> Regards,
> >> Matthew
> >>
> >> -
> >>
> >>
> >> In `GetGlobalSizeFromDescriptor` we use `dladdr` to get info on the the
> >> current address.  `dladdr` returns 0 if it failed.
> >> During testing on Linux this returned 0 to indicate failure, and
> >> populated the `info` structure with a NULL pointer which was
> >> dereferenced later.
> >>
> >> This patch checks for `dladdr` returning 0, and in that case returns 0
> >> from `GetGlobalSizeFromDescriptor` to indicate failure of identifying
> >> the address.
> >>
> >> This occurs when `GetModuleNameAndOffsetForPC` succeeds for some
> >> address
> >> not in a dynamically loaded library.  One example is when the found
> >> "module" is '[stack]' having come from parsing /proc/self/maps.
> >>
> >> Cherry-pick from 83ac18205ec69a00ac2be3b603bc3a61293fbe89.
> >>
> >> Differential Revision: https://reviews.llvm.org/D91344
> >>
> >>
> >> ### Attachment also inlined for ease of reply
> >> ###
> >>
> >>
> >> diff --git a/libsanitizer/hwasan/hwasan_report.cpp
> >> b/libsanitizer/hwasan/hwasan_report.cpp
> >> index
> >>
> 0be7deeaee1a0bd523d9e0fe1dc3b1311b3920e2..894a149775f291bae9cad8
> >> 33b1ac54914212f405 100644
> >> --- a/libsanitizer/hwasan/hwasan_report.cpp
> >> +++ b/libsanitizer/hwasan/hwasan_report.cpp
> >> @@ -254,7 +254,8 @@ static bool TagsEqual(tag_t tag, tag_t *tag_ptr) {
> >>   static uptr GetGlobalSizeFromDescriptor(uptr ptr) {
> >> // Find the ELF object that this global resides in.
> >> Dl_info info;
> >> -  dladdr(reinterpret_cast(ptr), &info);
> >> +  if (dladdr(reinterpret_cast(ptr), &info) == 0)
> >> +return 0;
> >> auto *ehdr = reinterpret_cast(info.dli_fbase);
> >> auto *phdr_begin = reinterpret_cast(
> >> reinterpret_cast(ehdr) + ehdr->e_phoff);
> >

[PATCH] testsuite/libstdc++: Fix required locales of a testcase

[Marius Hillenbrand via Gcc-patches]

The testsuite for libstdc++ aims to skips test cases for which not all
required locales are installed. This patch adds missing directives about
required locales to one test case to avoid false positive test failures
on systems that have a partial set of locales installed.

Verified by test suite runs that this patch changes the test case from
FAIL to UNSUPPORTED when not all required locales are available and that
the test case will run and PASS when the necessary locales have been
added.

Please review and merge this patch if you agree. While this patch is
trivial, it may safe others a few minutes of confusion ;-)

Marius


libstdc++-v3/ChangeLog:

2020-11-24  Marius Hillenbrand  

* testsuite/22_locale/locale/cons/5.cc: Add missing directives
for required locales.
---
 libstdc++-v3/testsuite/22_locale/locale/cons/5.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc 
b/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
index 8fd73960abb..49e863ec85c 100644
--- a/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
+++ b/libstdc++-v3/testsuite/22_locale/locale/cons/5.cc
@@ -1,5 +1,7 @@
-// { dg-require-namedlocale "en_PH" }
 // { dg-require-namedlocale "de_DE" }
+// { dg-require-namedlocale "en_PH" }
+// { dg-require-namedlocale "es_MX" }
+// { dg-require-namedlocale "fr_FR" }
 // { dg-require-namedlocale "it_IT" }
 
 // 2000-09-13 Benjamin Kosnik 
-- 
2.26.2

preprocessor: Add deferred macros

[Nathan Sidwell]

this completes the libcpp changes for C++ modules.  It is slightly 
different to the patch I posted earlier, as I discovered I'd added a 
bitfield I didn't end up using.  so that's now removed.


Deferred macros are needed for C++ modules.  Header units may export
macro definitions and undefinitions.  These are resolved lazily at the
point of (potential) use.  (The language specifies that, it's not just
a useful optimization.)  Thus, identifier nodes grow a 'deferred'
field, which fortunately doesn't expand the structure on 64-bit
systems as there was padding there.  This is non-zero on NT_MACRO
nodes, if the macro is deferred.  When such an identifier is lexed, it
is resolved via a callback that I added recently.  That will either
provide the macro definition, or discover it there was an overriding
undef.  Either way the identifier is no longer a deferred macro.
Notice it is now possible for NT_MACRO nodes to have a NULL macro
expansion.

libcpp/
* include/cpplib.h (struct cpp_hashnode): Add deferred field.
(cpp_set_deferred_macro): Define.
(cpp_get_deferred_macro): Declare.
(cpp_macro_definition): Reformat, add overload.
(cpp_macro_definition_location): Deal with deferred macro.
(cpp_alloc_token_string, cpp_compare_macro): Declare.
* internal.h (_cpp_notify_macro_use): Return bool
(_cpp_maybe_notify_macro_use): Likewise.
* directives.c (do_undef): Check macro is not undef before
warning.
(do_ifdef, do_ifndef): Deal with deferred macro.
* expr.c (parse_defined): Likewise.
* lex.c (cpp_allocate_token_string): Break out of ...
(create_literal): ... here.  Call it.
(cpp_maybe_module_directive): Deal with deferred macro.
* macro.c (cpp_get_token_1): Deal with deferred macro.
(warn_of_redefinition): Deal with deferred macro.
(compare_macros): Rename to ...
(cpp_compare_macro): ... here.  Make extern.
(cpp_get_deferred_macro): New.
(_cpp_notify_macro_use): Deal with deferred macro, return bool
indicating definedness.
(cpp_macro_definition): Deal with deferred macro.

pushing to trunk

nathan
--
Nathan Sidwell
diff --git i/libcpp/directives.c w/libcpp/directives.c
index bffdc913adb..fa66b5c5f71 100644
--- i/libcpp/directives.c
+++ w/libcpp/directives.c
@@ -667,7 +667,8 @@ do_undef (cpp_reader *pfile)
    pfile->directive_line, 0,
    "undefining \"%s\"", NODE_NAME (node));
 
-	  if (CPP_OPTION (pfile, warn_unused_macros))
+	  if (node->value.macro
+	  && CPP_OPTION (pfile, warn_unused_macros))
 	_cpp_warn_if_unused_macro (pfile, node, NULL);
 
 	  _cpp_free_definition (node);
@@ -1981,8 +1982,10 @@ do_ifdef (cpp_reader *pfile)
   if (node)
 	{
 	  skip = !_cpp_defined_macro_p (node);
+	  if (!_cpp_maybe_notify_macro_use (pfile, node, pfile->directive_line))
+	/* It wasn't a macro after all.  */
+	skip = true;
 	  _cpp_mark_macro_used (node);
-	  _cpp_maybe_notify_macro_use (pfile, node, pfile->directive_line);
 	  if (pfile->cb.used)
 	pfile->cb.used (pfile, pfile->directive_line, node);
 	  check_eol (pfile, false);
@@ -2006,8 +2009,10 @@ do_ifndef (cpp_reader *pfile)
   if (node)
 	{
 	  skip = _cpp_defined_macro_p (node);
+	  if (!_cpp_maybe_notify_macro_use (pfile, node, pfile->directive_line))
+	/* It wasn't a macro after all.  */
+	skip = false;
 	  _cpp_mark_macro_used (node);
-	  _cpp_maybe_notify_macro_use (pfile, node, pfile->directive_line);
 	  if (pfile->cb.used)
 	pfile->cb.used (pfile, pfile->directive_line, node);
 	  check_eol (pfile, false);
diff --git i/libcpp/expr.c w/libcpp/expr.c
index b98c0386eb5..2ba7726d61c 100644
--- i/libcpp/expr.c
+++ w/libcpp/expr.c
@@ -1068,6 +1068,7 @@ parse_defined (cpp_reader *pfile)
 	}
 }
 
+  bool is_defined = false;
   if (node)
 {
   if ((pfile->context != initial_context
@@ -1075,9 +1076,11 @@ parse_defined (cpp_reader *pfile)
 	  && CPP_OPTION (pfile, warn_expansion_to_defined))
 cpp_pedwarning (pfile, CPP_W_EXPANSION_TO_DEFINED,
 		"this use of \"defined\" may not be portable");
-
+  is_defined = _cpp_defined_macro_p (node);
+  if (!_cpp_maybe_notify_macro_use (pfile, node, token->src_loc))
+	/* It wasn't a macro after all.  */
+	is_defined = false;
   _cpp_mark_macro_used (node);
-  _cpp_maybe_notify_macro_use (pfile, node, token->src_loc);
 
   /* A possible controlling macro of the form #if !defined ().
 	 _cpp_parse_expr checks there was no other junk on the line.  */
@@ -1093,7 +1096,7 @@ parse_defined (cpp_reader *pfile)
   result.unsignedp = false;
   result.high = 0;
   result.overflow = false;
-  result.low = node && _cpp_defined_macro_p (node);
+  result.low = is_defined;
   return result;
 }
 
diff --git i/libcpp/include/cpplib.h w/libcpp/include/cpplib.h
index 91226cfc248..2becd2e8e54 100644
--- i/libcpp/include/cpplib.h
+++ w/libcpp/include/cpplib.h
@@ -901,7 

[COMMITTED] patch to fix PR97933

[Vladimir Makarov via Gcc-patches]

The following patch fixes

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

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


commit fb352136db34a7adbc7be6a1e4e90b56bc632ebd (HEAD -> master)
Author: Vladimir N. Makarov 
Date:   Tue Nov 24 11:25:16 2020 -0500

[PR97933] LRA: find correctly last empty dest block.

gcc/

2020-11-24  Vladimir Makarov  

PR bootstrap/97933
* lra.c (lra_process_new_insns): Stop on the first real insn after
head of e->dest.

diff --git a/gcc/lra.c b/gcc/lra.c
index b318cfd7456..4ec0f466376 100644
--- a/gcc/lra.c
+++ b/gcc/lra.c
@@ -1908,11 +1908,9 @@ lra_process_new_insns (rtx_insn *insn, rtx_insn *before, rtx_insn *after,
 		  tmp = NEXT_INSN (tmp);
 		if (NOTE_INSN_BASIC_BLOCK_P (tmp))
 		  tmp = NEXT_INSN (tmp);
-		for (curr = tmp;
-		 curr != NULL
-		   && (!INSN_P (curr) || BLOCK_FOR_INSN (curr) == e->dest);
-		 curr = NEXT_INSN (curr))
-		  ;
+		for (curr = tmp; curr != NULL; curr = NEXT_INSN (curr))
+		  if (INSN_P (curr))
+		break;
 		/* Do not put reload insns if it is the last BB
 		   without actual insns.  In this case the reload insns
 		   can get null BB after emitting.  */

[PATCH] arm: correctly handle negating INT_MIN in arm_split_atomic_op [PR97534]

[Richard Earnshaw (lists) via Gcc-patches]

arm_split_atomic_op handles subtracting a constant by converting it
into addition of the negated constant.  But if the type of the operand
is int and the constant is -1 we currently end up generating invalid
RTL which can lead to an abort later on.

The problem is that in a HOST_WIDE_INT, INT_MIN is represented as
0x8000 and the negation of this is 0x8000, but
that's not a valid constant for use in SImode operations.

The fix is straight-forward which is to use gen_int_mode rather than
simply GEN_INT.  This knows how to correctly sign-extend the negated
constant when this is needed.

gcc/
PR target/97534
* config/arm/arm.c (arm_split_atomic_op): Use gen_int_mode when
negating a const_int.
gcc/testsuite/
* gcc.dg/pr97534.c: New test.
---
 gcc/config/arm/arm.c   | 2 +-
 gcc/testsuite/gcc.dg/pr97534.c | 9 +
 2 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr97534.c

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 568e1530f24..56ed556b098 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -30824,7 +30824,7 @@ arm_split_atomic_op (enum rtx_code code, rtx old_out, 
rtx new_out, rtx mem,
 case MINUS:
   if (CONST_INT_P (value))
{
- value = GEN_INT (-INTVAL (value));
+ value = gen_int_mode (-INTVAL (value), wmode);
  code = PLUS;
}
   /* FALLTHRU */
diff --git a/gcc/testsuite/gcc.dg/pr97534.c b/gcc/testsuite/gcc.dg/pr97534.c
new file mode 100644
index 000..b363a322aa5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr97534.c
@@ -0,0 +1,9 @@
+/* PR target/97534 - ICE in decompose on arm*-*-*.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c11 -O2 -g" } */
+
+int f (int a)
+{
+  int b;
+  __atomic_fetch_sub(&b, (int)(-__INT_MAX__ - 1), (int)0);
+}
-- 
2.17.1

Re: Update: [PATCH 5/X] libsanitizer: mid-end: Introduce stack variable handling for HWASAN

[Matthew Malcomson via Gcc-patches]

On 24/11/2020 12:30, Hongtao Liu wrote:

Hi:
   I'm learning about this patch, and I see one place that might be
slighted improved.

+  poly_int64 size = (top - bot);
+
+  /* Assert the edge of each variable is aligned to the HWASAN tag granule
+size.  */
+  gcc_assert (multiple_p (top, HWASAN_TAG_GRANULE_SIZE));
+  gcc_assert (multiple_p (bot, HWASAN_TAG_GRANULE_SIZE));
+  gcc_assert (multiple_p (size, HWASAN_TAG_GRANULE_SIZE));
+

The last gcc_assert looks redundant?


Hi

I think you're right.

Just FYI I'm planning on making that change as an obvious fix after the 
patchset as it is now goes in.


That way I can say I ran all my tests on the patch series that I applied 
without going through the all the tests again.


Thanks for the catch!

Matthew


On Sat, Nov 21, 2020 at 2:48 AM Matthew Malcomson via Gcc-patches
 wrote:

Re: How to traverse all the local variables that declared in the current routine?

[Qing Zhao via Gcc-patches]

> On Nov 24, 2020, at 9:55 AM, Richard Biener  
> wrote:
> 
> On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao  wrote:
>> 
>> 
>> 
>>> On Nov 24, 2020, at 1:32 AM, Richard Biener  
>>> wrote:
>>> 
>>> On Tue, Nov 24, 2020 at 12:05 AM Qing Zhao via Gcc-patches
>>>  wrote:
 
 Hi,
 
 Does gcc provide an iterator to traverse all the local variables that are 
 declared in the current routine?
 
 If not, what’s the best way to traverse the local variables?
>>> 
>>> Depends on what for.  There's the source level view you get by walking
>>> BLOCK_VARS of the
>>> scope tree, theres cfun->local_variables (FOR_EACH_LOCAL_DECL) and
>>> there's SSA names
>>> (FOR_EACH_SSA_NAME).
>> 
>> I am planing to add a new phase immediately after 
>> “pass_late_warn_uninitialized” to initialize all auto-variables that are
>> not explicitly initialized in the declaration, the basic idea is following:
>> 
>> ** The proposal:
>> 
>> A. add a new GCC option: (same name and meaning as CLANG)
>> -ftrivial-auto-var-init=[pattern|zero], similar pattern init as CLANG;
>> 
>> B. add a new attribute for variable:
>> __attribute((uninitialized)
>> the marked variable is uninitialized intentionaly for performance purpose.
>> 
>> C. The implementation needs to keep the current static warning on 
>> uninitialized
>> variables untouched in order to avoid "forking the language".
>> 
>> 
>> ** The implementation:
>> 
>> There are two major requirements for the implementation:
>> 
>> 1. all auto-variables that do not have an explicit initializer should be 
>> initialized to
>> zero by this option.  (Same behavior as CLANG)
>> 
>> 2. keep the current static warning on uninitialized variables untouched.
>> 
>> In order to satisfy 1, we should check whether an auto-variable has 
>> initializer
>> or not;
>> In order to satisfy 2, we should add this new transformation after
>> "pass_late_warn_uninitialized".
>> 
>> So, we should be able to check whether an auto-variable has initializer or 
>> not after “pass_late_warn_uninitialized”,
>> If Not, then insert an initialization for it.
>> 
>> For this purpose, I guess that “FOR_EACH_LOCAL_DECL” might be better?
> 
> Yes, but do you want to catch variables promoted to register as well
> or just variables
> on the stack?

I think both as long as they are source-level auto-variables. Then which one is 
better?

> 
>> Another issue is, in order to check whether an auto-variable has 
>> initializer, I plan to add a new bit in “decl_common” as:
>>  /* In a VAR_DECL, this is DECL_IS_INITIALIZED.  */
>>  unsigned decl_is_initialized :1;
>> 
>> /* IN VAR_DECL, set when the decl is initialized at the declaration.  */
>> #define DECL_IS_INITIALIZED(NODE) \
>>  (DECL_COMMON_CHECK (NODE)->decl_common.decl_is_initialized)
>> 
>> set this bit when setting DECL_INITIAL for the variables in FE. then keep it
>> even though DECL_INITIAL might be NULLed.
> 
> For locals it would be more reliable to set this flag during gimplification.

You mean I can set the flag “DECL_IS_INITIALIZED (decl)”  inside the routine 
“gimpley_decl_expr” (gimplify.c) as following:

  if (VAR_P (decl) && !DECL_EXTERNAL (decl))
{
  tree init = DECL_INITIAL (decl);
...
  if (init && init != error_mark_node)
{
  if (!TREE_STATIC (decl))
{
  DECL_IS_INITIALIZED(decl) = 1;
}

Is this enough for all Frontends? Are there other places that I need to 
maintain this bit? 


> 
>> Do you have any comment and suggestions?
> 
> As said above - do you want to cover registers as well as locals?

All the locals from the source-code point of view should be covered.   (From my 
study so far,  looks like that Clang adds that phase in FE). 
If GCC adds this phase in FE, then the following design requirement

C. The implementation needs to keep the current static warning on uninitialized
variables untouched in order to avoid "forking the language”.

cannot be satisfied.  Since gcc’s uninitialized variables analysis is applied 
quite late. 

So, we have to add this new phase after “pass_late_warn_uninitialized”. 

>  I'd do
> the actual zeroing during RTL expansion instead since otherwise you
> have to figure youself whether a local is actually used (see 
> expand_stack_vars)

Adding  this new transformation during RTL expansion is okay.  I will check on 
this in more details to see how to add it to RTL expansion phase. 
> 
> Note that optimization will already made have use of "uninitialized" state
> of locals so depending on what the actual goal is here "late" may be too late.

This is a really good point… 

In order to avoid optimization  to use the “uninitialized” state of locals, we 
should add the zeroing phase as early as possible (adding it in FE might be 
best 
for this issue). However, if we have to met the following requirement:

C. The implementation needs to keep the current static warning on uninitialized
variables untouched in order to avoid "forking the language”.

We h

Re: [PATCH] dump type attributes in dump_function_to_file

[Martin Sebor via Gcc-patches]

On 11/24/20 8:53 AM, Martin Sebor wrote:

On 11/23/20 9:31 PM, Jeff Law wrote:



On 11/20/20 4:14 PM, Jeff Law wrote:


On 11/20/20 11:12 AM, Martin Sebor via Gcc-patches wrote:

dump_function_to_file prints DECL_ATTRIBUTES but not TYPE_ATTRIBUTES
when both can be important and helpful for debugging, especially with
attributes that are added implicitly (such attribute access and
the proposed internal attribute *dealloc).  The function also prints
function arguments (and their types) but not its return type, again,
leaving out a useful detail.  The attached tweak adds both to
the dump.

Martin

gcc-dump-type-attr.diff

gcc/ChangeLog:

* gcc/tree-cfg.c (dump_function_to_file): Print type attributes
and return type.

gcc/testsuite/ChangeLog:
* gcc.dg/attr-access-4.c: New test.

So was this actually regression tested?  Even tests that change dump
files need to be regression tested because some of the tests scan those
dump files.

I'm seeing this on several targets:

Tests that now fail, but worked before (6 tests):

xstormy16-sim: gcc.dg/tree-ssa/pr23401.c scan-tree-dump-times gimple 
"int" 5
xstormy16-sim: gcc.dg/tree-ssa/pr23401.c scan-tree-dump-times gimple 
"int" 5
xstormy16-sim: gcc.dg/tree-ssa/pr27810.c scan-tree-dump-times gimple 
"int" 3
xstormy16-sim: gcc.dg/tree-ssa/pr27810.c scan-tree-dump-times gimple 
"int" 3
xstormy16-sim: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized 
" w?\\* " 9
xstormy16-sim: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized 
" w?\\* " 9




 From my quick reading, these tests are likely failing across the board.


It was tested with the results below.  I looked onto the jit
failures (test-combination.c.exe etc.) but overlooked those
in the tree-ssa directory because of all the perpetual guality
clutter.


I committed r11-5321 to fix up the gfortran.dg/gomp/declare-target-4.f90
regex pattern.  Thank you for cleaning up the others.



!  FAIL: gcc.dg/atomic/pr65345-4.c (4: +4)ESC[0m
!  FAIL: gcc.dg/guality/loop-1.c (1: +1)ESC[0m
!  FAIL: gcc.dg/guality/pr36728-2.c (28: +28)ESC[0m
!  FAIL: gcc.dg/guality/pr36728-4.c (4: +4)ESC[0m
!  FAIL: gcc.dg/guality/pr41616-1.c (3: +3)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-1.c (8: +8)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-2.c (2: +2)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-3.c (8: +8)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-4.c (2: +2)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-5.c (2: +2)ESC[0m
!  FAIL: gcc.dg/guality/pr54519-6.c (1: +1)ESC[0m
!  FAIL: gcc.dg/guality/pr56154-1.c (1: +1)ESC[0m
!  FAIL: gcc.dg/guality/pr59776.c (6: +6)ESC[0m
!  FAIL: gcc.dg/guality/pr90074.c (2: +2)ESC[0m
!  FAIL: gcc.dg/guality/pr90716.c (1: +1)ESC[0m
!  FAIL: gcc.dg/guality/sra-1.c (16: +16)ESC[0m
!  FAIL: gcc.dg/guality/vla-1.c (8: +8)ESC[0m
!  FAIL: gcc.dg/tree-ssa/pr23401.c (1: +1)ESC[0m
!  FAIL: gcc.dg/tree-ssa/pr27810.c (1: +1)ESC[0m
!  FAIL: gcc.dg/tree-ssa/slsr-8.c (1: +1)ESC[0m
!  FAIL: gdc.dg/intrinsics.d (3: +3)ESC[0m
!  FAIL: g++.dg/guality/pr55665.C (1: +1)ESC[0m
!  FAIL: gfortran.dg/gomp/declare-target-4.f90 (8: +8)ESC[0m
!  FAIL: test-combination.c.exe (1: +1)ESC[0m
!  FAIL: test-functions.c.exe (1: +1)ESC[0m
!  FAIL: test-pr66779.c.exe (1: +1)ESC[0m
!  FAIL: test-threads.c.exe (1: +1)ESC[0m
! XPASS: gcc.dg/analyzer/pr94851-1.c (1: +1)ESC[0m
! XPASS: gcc.dg/guality/example.c (3: +3)ESC[0m
! XPASS: gcc.dg/guality/guality.c (8: +8)ESC[0m
! XPASS: gcc.dg/guality/inline-params.c (5: +5)ESC[0m
! XPASS: gcc.dg/guality/pr41353-1.c (2: +2)ESC[0m
! XPASS: gcc.dg/guality/pr54970.c (16: +16)ESC[0m
! XPASS: gcc.dg/guality/pr59776.c (2: +2)ESC[0m



jeff

Re: [wwwdocs] Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies

[Segher Boessenkool]

Hi!

On Tue, Nov 24, 2020 at 11:55:23AM +0100, Ulrich Weigand wrote:
> On Sat, Nov 21, 2020 at 01:57:32PM -0600, Segher Boessenkool wrote:
> > It all makes sense, and is a nice improvement :-)  But please mention it
> > in the release notes?  No doubt people did use non-sensical flag
> > combinations, and they will be affected.  Thanks!
> 
> Here's a proposed patch to update the gcc-11 changes.hmtl.
> 
> OK to commit?

This looks perfect to me.  It even looks like fine HTML (but I would
trust the W3C validator over me on that, hehe.

> diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
> index 46a6a37..c0f896a 100644
> --- a/htdocs/gcc-11/changes.html
> +++ b/htdocs/gcc-11/changes.html
> @@ -58,6 +58,29 @@ a work-in-progress.
>is deprecated and will be removed in a future release. It should be
>possible to use --enable-cheaders=c_global (the default)
>with no change in behaviour. 
> +
> +  Some inconsistencies in handling combinations of 
> -ffast-math,
> +  -fno-fast-math, -funsafe-math-optimizations,
> +  -fno-unsafe-math-optimizations, and their component flags
> +  have been fixed.  This might change the behavior of the compiler when
> +  invoked with certain combinations of such command line options.
> +  The behavior is now consistently:
> +  
> +  If a component flag of -ffast-math or 

(trailing space, if you care)

> +  -funsafe-math-optimizations is explicitly set or reset
> +  on the command line, this will override any implicit change, no 
> matter
> +  in which order the flags come on the command line.
> +  Any component flag (which is not explicity set or reset on the 
> command
> +  line) that was modified from its default by 
> -ffast-math or
> +  -funsafe-math-optimizations is always reset to its 
> default
> +  by a subsequent -fno-fast-math or
> +  -fno-unsafe-math-optimizations.
> +  -ffast-math no longer implicitly changes
> +  -fsignaling-math.
> +  The __FAST_MATH__ preprocessor macro is set if and
> +  only if all component flags of -ffast-math are set
> +  to the value documented as the effect of 
> -ffast-math.
> +  
>  

Thanks,


Segher

Re: [PATCH] warn for integer overflow in allocation calls (PR 96838)

[Andrew MacLeod via Gcc-patches]

On 11/23/20 4:38 PM, Martin Sebor wrote:

On 11/21/20 6:26 AM, Andrew MacLeod wrote:

On 11/21/20 12:07 AM, Jeff Law wrote:


On 11/9/20 9:00 AM, Martin Sebor wrote:

Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html

Jeff, I don't expect to have the cycles to reimplement this patch
using the Ranger APIs before stage 1 closes.  I'm open to giving
it a try in stage 3 if it's still in scope for GCC 11. Otherwise,
is this patch okay to commit?

So all we're going to get from the ranger is ranges of operands, right?
Meaning that we still need to either roll our own evaluator
(eval_size_vflow) or overload range_for_stmt with our own, which likely
looks like eval_size_vflow anyway, right?

My hope was to avoid the roll our own evaluator, but that doesn't look
like it's in the cards in the reasonably near future.


Is there a PR open showing what exactly you are looking for?
I'm using open PRs to track enhancement requests, and they will all 
feed back into the development roadmap  I am working on.


Not that I know of.  The background is upthread, in particular in
Aldy's response here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554242.html

I like the suggestion and if/when I have the time I'd like to give
it a try.  Until then, I think the patch is useful on its own so
I'll go with it for now.

Longer term, I do hope we can revisit the idea of computing either
mathematically correct ranges alongside those required by the language
semantics, or tracking signed overflow or unsigned wraparound. E.g.,
in:

  void* f (int n)
  {
    if (n < INT_MAX / 3)
  n = INT_MAX / 3;

    n *= sizeof (int);
    // n is [(INT_MAX / 3) * 4, INF] mathematically
    // undefined due to overflow in C
    // but [INT_MIN, INT_MAX] according to VRP


but sizeof returns a size_t.. which is an unsigned. thus the multiply is 
promoted to an unsigned multiply  which means there is lots of wrapping 
and I don't see how you can conclude those ranges?    [INT_MIN, INT_MAX] 
are all possible outcomes based on the code that is generated.


If I change that to
  n *= (int) sizeof (int) to keep it as signed arithmetic, I see:


Folding statement: n_4 = n_1 * 4;
EVRP:hybrid: RVRP found singleton 2147483647
Queued stmt for removal.  Folds to: 2147483647
evrp visiting stmt _7 = malloc (n_4);

extract_range_from_stmt visiting:
_7 = foo (n_4);
Folding statement: _7 = foo (n_4);
EVRP:hybrid: RVRP found singleton 2147483647
Folded into: _7 = malloc (2147483647);

So I'm not sure what exactly you want to do?  We are calculating what 
the program can produce?


Why do we care about alternative calculations?

Andrew

Re: [PATCH] warn for integer overflow in allocation calls (PR 96838)

[Andrew MacLeod via Gcc-patches]

On 11/24/20 12:42 PM, Andrew MacLeod wrote:

On 11/23/20 4:38 PM, Martin Sebor wrote:

On 11/21/20 6:26 AM, Andrew MacLeod wrote:

On 11/21/20 12:07 AM, Jeff Law wrote:


On 11/9/20 9:00 AM, Martin Sebor wrote:

Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html

Jeff, I don't expect to have the cycles to reimplement this patch
using the Ranger APIs before stage 1 closes.  I'm open to giving
it a try in stage 3 if it's still in scope for GCC 11. Otherwise,
is this patch okay to commit?
So all we're going to get from the ranger is ranges of operands, 
right?

Meaning that we still need to either roll our own evaluator
(eval_size_vflow) or overload range_for_stmt with our own, which 
likely

looks like eval_size_vflow anyway, right?

My hope was to avoid the roll our own evaluator, but that doesn't look
like it's in the cards in the reasonably near future.


Is there a PR open showing what exactly you are looking for?
I'm using open PRs to track enhancement requests, and they will all 
feed back into the development roadmap  I am working on.


Not that I know of.  The background is upthread, in particular in
Aldy's response here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554242.html

I like the suggestion and if/when I have the time I'd like to give
it a try.  Until then, I think the patch is useful on its own so
I'll go with it for now.

Longer term, I do hope we can revisit the idea of computing either
mathematically correct ranges alongside those required by the language
semantics, or tracking signed overflow or unsigned wraparound. E.g.,
in:

  void* f (int n)
  {
    if (n < INT_MAX / 3)
  n = INT_MAX / 3;

    n *= sizeof (int);
    // n is [(INT_MAX / 3) * 4, INF] mathematically
    // undefined due to overflow in C
    // but [INT_MIN, INT_MAX] according to VRP


but sizeof returns a size_t.. which is an unsigned. thus the multiply 
is promoted to an unsigned multiply  which means there is lots of 
wrapping and I don't see how you can conclude those ranges?    
[INT_MIN, INT_MAX] are all possible outcomes based on the code that is 
generated.


If I change that to
  n *= (int) sizeof (int) to keep it as signed arithmetic, I see:


Folding statement: n_4 = n_1 * 4;
EVRP:hybrid: RVRP found singleton 2147483647
Queued stmt for removal.  Folds to: 2147483647
evrp visiting stmt _7 = malloc (n_4);

extract_range_from_stmt visiting:
_7 = foo (n_4);
Folding statement: _7 = foo (n_4);
EVRP:hybrid: RVRP found singleton 2147483647
Folded into: _7 = malloc (2147483647);

So I'm not sure what exactly you want to do?  We are calculating what 
the program can produce?


Why do we care about alternative calculations?


Or rather, why do we want to do this?

Re: [PATCH] warn for integer overflow in allocation calls (PR 96838)

[Martin Sebor via Gcc-patches]

On 11/24/20 10:44 AM, Andrew MacLeod wrote:

On 11/24/20 12:42 PM, Andrew MacLeod wrote:

On 11/23/20 4:38 PM, Martin Sebor wrote:

On 11/21/20 6:26 AM, Andrew MacLeod wrote:

On 11/21/20 12:07 AM, Jeff Law wrote:


On 11/9/20 9:00 AM, Martin Sebor wrote:

Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html

Jeff, I don't expect to have the cycles to reimplement this patch
using the Ranger APIs before stage 1 closes.  I'm open to giving
it a try in stage 3 if it's still in scope for GCC 11. Otherwise,
is this patch okay to commit?
So all we're going to get from the ranger is ranges of operands, 
right?

Meaning that we still need to either roll our own evaluator
(eval_size_vflow) or overload range_for_stmt with our own, which 
likely

looks like eval_size_vflow anyway, right?

My hope was to avoid the roll our own evaluator, but that doesn't look
like it's in the cards in the reasonably near future.


Is there a PR open showing what exactly you are looking for?
I'm using open PRs to track enhancement requests, and they will all 
feed back into the development roadmap  I am working on.


Not that I know of.  The background is upthread, in particular in
Aldy's response here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554242.html

I like the suggestion and if/when I have the time I'd like to give
it a try.  Until then, I think the patch is useful on its own so
I'll go with it for now.

Longer term, I do hope we can revisit the idea of computing either
mathematically correct ranges alongside those required by the language
semantics, or tracking signed overflow or unsigned wraparound. E.g.,
in:

  void* f (int n)
  {
    if (n < INT_MAX / 3)
  n = INT_MAX / 3;

    n *= sizeof (int);
    // n is [(INT_MAX / 3) * 4, INF] mathematically
    // undefined due to overflow in C
    // but [INT_MIN, INT_MAX] according to VRP


but sizeof returns a size_t.. which is an unsigned. thus the multiply 
is promoted to an unsigned multiply  which means there is lots of 
wrapping and I don't see how you can conclude those ranges? [INT_MIN, 
INT_MAX] are all possible outcomes based on the code that is generated.


If I change that to
  n *= (int) sizeof (int) to keep it as signed arithmetic, I see:


Folding statement: n_4 = n_1 * 4;
EVRP:hybrid: RVRP found singleton 2147483647
Queued stmt for removal.  Folds to: 2147483647
evrp visiting stmt _7 = malloc (n_4);

extract_range_from_stmt visiting:
_7 = foo (n_4);
Folding statement: _7 = foo (n_4);
EVRP:hybrid: RVRP found singleton 2147483647
Folded into: _7 = malloc (2147483647);

So I'm not sure what exactly you want to do?  We are calculating what 
the program can produce?


Why do we care about alternative calculations?


Or rather, why do we want to do this?


When computing the sizes of things, programmers commonly forget
to consider unsigned wrapping (or signed overflow).  We simply
assume it can't happen and that (for instance) N * sizeof (X)
is necessarily big enough for N elements of type X.  (Grepping
any code base for the pattern '\* sizeof' and looking for code
that tests that the result doesn't wrap is revealing.)

When overflow or wrapping does happen (typically because of poor
precondition checking) it often leads to bugs when we end up
allocating less space than we need and use.  A simple example
to help illustrate what I mean:

  void* g (int *a, int n)
  {
a = realloc (a, n * sizeof (int) + 32);
for (int i = n; i != n + 32; ++i)
  a[i] = f ();
  }

In ILP32, if (n > INT_MAX / 4 - 32) holds, n * sizeof(int) will
wrap around zero.  The realloc call will end up allocating less
space than expected, and the loop will write past the end of
the allocated block.

(The bug above can only be detected if we know n's range.
I left that part out.)

Historically, bugs caused by integer overflow and wrapping have
been among the most serious security weaknesses.  Detecting these
mistakes will help prevent some of these.

The problem is that according to C/C++, nothing in the function
above is undefined except for the buffer overflow in the loop,
and the buffer overflow only happens because of the well-defined
integer wrapping.  To detect the wrapping, we either need to do
the computation in as-if infinite math and compare the final result
to the result we get under C's truncating rules, or we need to set
and propagate the "wraparound" bit throughout the computation.

Martin

Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies

[Ulrich Weigand via Gcc-patches]

On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> > * doc/invoke.texi (-ffast-math): Remove mention of -fno-signaling-nans.
> > Clarify conditions when __FAST_MATH__ preprocessor macro is defined.
> >
> > * opts.c (common_handle_option): Pass OPTS_SET to set_fast_math_flags
> > and set_unsafe_math_optimizations_flags.
> > (set_fast_math_flags): Add OPTS_SET argument, and use it to avoid
> > setting flags already explicitly set on the command line.  In the !set
> > case, also reset x_flag_cx_limited_range and x_flag_excess_precision.
> > Never reset x_flag_signaling_nans or x_flag_rounding_math.
> > (set_unsafe_math_optimizations_flags): Add OPTS_SET argument, and use
> > it to avoid setting flags already explicitly set on the command line.
> > (fast_math_flags_set_p): Also test x_flag_cx_limited_range,
> > x_flag_associative_math, x_flag_reciprocal_math, and
> > x_flag_rounding_math.
> It appears this was dropped on the floor. It looks reasonable to me.
> Please retest and commit. Thanks!

This did handle flag_excess_precision incorrectly, causing in particular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970

I've reverted for now and will post a modified patch later.
Sorry for the breakage!

At a first glance, it appears the problem is that -fexcess-precision=fast
is already the default, so it does not make sense for -fno-fast-math to
"reset" this back to default.  Probably the best is for fast-math to
simply not touch excess precision at all:
- if it is set explicitly on the command line, fast-math should not
  affect it in any case;
- if it is not set explicitly on the command line, the default either
  with fast-math or no-fast-math is excess-precision=fast, so again
  it should not be touched.

I'll still need to look into the language-specific handling of the
excess precision setting to make sure this works for all languages.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

[PATCH v2] rs6000, vector integer multiply/divide/modulo instructions

[Carl Love via Gcc-patches]

Segher:

I have addressed the various issues you and Pat mentioned. 
Specifically:

  - Added parenthesis around the macro arguments in altivec.h.
  - Removed VIlong_char, using  instead.
  - Reimplemented define_insn "vmulhs_" and define_insn 
"vmulhs_" to not use an UNSPEC.  Also changed the type to
veccomplex.
  - Fixed the header and index value "i" in documentation file  
extend.texi as requested.
  - Changed attribute type from vecsimple to vecdiv in dives_,
diveu_, div3, udiv3, mods_, modu_.
  - Added the size attribute of 128 to mods_ and modu_.
  - Changed the set attribute to veccomplex for define_insn "mulv2di3.
  - Added "signed" or "unsigned" to the error print statements in the
test program to clarify what case had failed.

In addition to testing on Power 9, I was able to test the updated patch
on Power 10.

Please let me know if the above changes are all acceptable and if there
are any additional changes needed.  Thanks.

Carl 


-
GCC maintainers:

The following patch adds new builtins for the vector integer multiply,
divide and modulo operations.  The builtins are:  
vec_mulh(), vec_div(), vec_dive(), vec_mod() for signed and unsigned
integers and long long integers.  Support for signed and unsigned long
long integers the exiting vec_mul() is added.  Note that the existing
support for the vec_div()and vec_mul() builtins emulate the vector
operations with multiple scalar instructions.  This patch adds support
for these builtins to use the new vector instructions.

The patch was compiled and tested on:

  powerpc64le-unknown-linux-gnu (Power 9 LE) 
  powerpc64le-unknown-linux-gnu (Power 10 LE)
  
with no regressions. Additionally the new test case was compiled and
executed by hand on Mambo to verify the test case passes.

Please let me know if this patch is acceptable for mainline.  Thanks.

Carl Love



---


2020-11-23  Carl Love  

gcc/
* config/rs6000/altivec.h (vec_mulh, vec_div, vec_dive, vec_mod): New
defines.
* config/rs6000/altivec.md (VIlong): Move define to file vsx.md.
* config/rs6000/rs6000-builtin.def (DIVES_V4SI, DIVES_V2DI,
DIVEU_V4SI, DIVEU_V2DI, DIVS_V4SI, DIVS_V2DI, DIVU_V4SI,
DIVU_V2DI, MODS_V2DI, MODS_V4SI, MODU_V2DI, MODU_V4SI,
MULHS_V2DI, MULHS_V4SI, MULHU_V2DI, MULHU_V4SI, MULLD_V2DI):
Add builtin define.
(MULH, DIVE, MOD):  Add new BU_P10_OVERLOAD_2 definitions.
* config/rs6000/rs6000-call.c (VSX_BUILTIN_VEC_DIV,
P10_BUILTIN_VEC_VDIVE, P10_BUILTIN_VEC_VMOD, P10_BUILTIN_VEC_VMULH):
New overloaded definitions.
(builtin_function_type) [P10V_BUILTIN_DIVEU_V4SI,
P10V_BUILTIN_DIVEU_V2DI, P10V_BUILTIN_DIVU_V4SI,
P10V_BUILTIN_DIVU_V2DI, P10V_BUILTIN_MODU_V2DI,
P10V_BUILTIN_MODU_V4SI, P10V_BUILTIN_MULHU_V2DI,
P10V_BUILTIN_MULHU_V4SI, P10V_BUILTIN_MULLD_V2DI]: Add case
statement for builtins.
* config/rs6000/vsx.md (VIlong_char): Add define_mod_attribute.
(UNSPEC_VDIVES, UNSPEC_VDIVEU): Add enum for UNSPECs.
(vsx_mul_v2di, vsx_udiv_v2di): Add if TARGET_POWER10 statement.
(dives_, diveu_, div3, uvdiv3,
mods_, modu_, mulhs_, mulhu_, mulv2di3):
Add define_insn, mode is VIlong.
* doc/extend.texi (vec_mulh, vec_mul, vec_div, vec_dive, vec_mod): Add
builtin descriptions.

gcc/testsuite/
* gcc.target/powerpc/builtins-1-p10-runnable.c: New test file.
---
 gcc/config/rs6000/altivec.h   |   5 +
 gcc/config/rs6000/altivec.md  |   2 -
 gcc/config/rs6000/rs6000-builtin.def  |  22 +
 gcc/config/rs6000/rs6000-call.c   |  49 +++
 gcc/config/rs6000/vsx.md  | 213 +++---
 gcc/doc/extend.texi   | 120 ++
 .../powerpc/builtins-1-p10-runnable.c | 398 ++
 7 files changed, 757 insertions(+), 52 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c

diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
index e1884f51bd8..12ccbd2fc2f 100644
--- a/gcc/config/rs6000/altivec.h
+++ b/gcc/config/rs6000/altivec.h
@@ -750,6 +750,11 @@ __altivec_scalar_pred(vec_any_nle,
 #define vec_strir_p(a) __builtin_vec_strir_p (a)
 #define vec_stril_p(a) __builtin_vec_stril_p (a)
 
+#define vec_mulh(a, b) __builtin_vec_mulh ((a), (b))
+#define vec_div(a, b) __builtin_vec_div ((a), (b))
+#define vec_dive(a, b) __builtin_vec_dive ((a), (b))
+#define vec_mod(a, b) __builtin_vec_mod ((a), (b))
+
 /* VSX Mask Manipulation builtin. */
 #define vec_genbm __builtin_vec_mtvsrbm
 #define vec_genhm __builtin_vec_mtvsrhm
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 6a6ce0f84ed..f10f1cdd8a7 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/

Re: [PATCH 1/4] rs6000: Change rs6000_expand_vector_set param

[Segher Boessenkool]

On Sat, Oct 10, 2020 at 03:08:22AM -0500, Xionghu Luo wrote:
> rs6000_expand_vector_set could accept insert either to constant position
> or variable position, so change the operand to reg_or_cint_operand.

This is okay for trunk.  Thank you!


Segher


> 2020-10-10  Xionghu Luo  
> 
>   * config/rs6000/rs6000-call.c (altivec_expand_vec_set_builtin):
>   Change call param 2 from type int to rtx.
>   * config/rs6000/rs6000-protos.h (rs6000_expand_vector_set):
>   Likewise.
>   * config/rs6000/rs6000.c (rs6000_expand_vector_init):
>   Change call param 2 from type int to rtx.
>   (rs6000_expand_vector_set): Likewise.
>   * config/rs6000/vector.md (vec_set): Support both constant
>   and variable index vec_set.

[pushed] c++: ICE with int{} in template. [PR97899]

[Jason Merrill via Gcc-patches]

split_nonconstant_init_1 was confused by a CONSTRUCTOR with non-aggregate
type, which (with COMPOUND_LITERAL_P set) we use in a template to represent
a braced functional cast.  It seems to me that there's no good reason to do
split_nonconstant_init at all in a template.

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

gcc/cp/ChangeLog:

PR c++/97899
* typeck2.c (store_init_value): Don't split_nonconstant_init in a
template.

gcc/testsuite/ChangeLog:

PR c++/97899
* g++.dg/cpp0x/initlist-template3.C: New test.
---
 gcc/cp/typeck2.c|  1 +
 gcc/testsuite/g++.dg/cpp0x/initlist-template3.C | 13 +
 2 files changed, 14 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-template3.C

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 412869946a5..721987e8502 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -806,6 +806,7 @@ store_init_value (tree decl, tree init, vec** 
cleanups, int flags)
  the bits that are constant, and then return an expression that
  will perform the dynamic initialization.  */
   if (value != error_mark_node
+  && !processing_template_decl
   && (TREE_SIDE_EFFECTS (value)
  || vla_type_p (type)
  || ! reduced_constant_expression_p (value)))
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-template3.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist-template3.C
new file mode 100644
index 000..b65a8473a09
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist-template3.C
@@ -0,0 +1,13 @@
+// PR c++/97899
+// { dg-do compile { target c++11 } }
+
+template 
+int fn()
+{
+  return 1;
+}
+
+template 
+void bar() {
+  const int i = int{fn()};
+}

base-commit: 1805dbc58bac78a823e9cff075b9dc993f29c360
-- 
2.18.4

Re: [PATCH] use TYPE_SIZE instead of DECL_SIZE for classes (PR 97595)

[Jason Merrill via Gcc-patches]

On 11/23/20 7:06 PM, Martin Sebor wrote:

On 11/16/20 11:54 PM, Jason Merrill wrote:

On 11/16/20 9:41 PM, Martin Sebor wrote:

The result of DECL_SIZE_UNIT doesn't always reflect the size
of data members of virtual classes.  This can lead to objects
of such types appearing smaller than they are to warnings like
-Warray-bounds or -Wstringop-overflow, causing false positives.

To avoid these false positives, the attached replaces the use
of DECL_SIZE_UNIT in component_ref_size in the middle end with
TYPE_SIZE_UNIT.


Unfortunately, that's not enough; the offset between the intermediate 
base and the virtual base could be greater than the TYPE_SIZE of the 
intermediate base:


extern "C" int printf (const char *, ...);

struct A { char ar1[24]; };
struct B: virtual A { };
struct C { char ar2[42]; };
struct D: B, C { };

int main()
{
   D d;
   printf ("size %d, offset %d\n", sizeof (B), d.ar1 - (char*)(B*)&d);
}

Here base C is allocated between base B and its virtual base A, so the 
offset between them is 50, while the size of B is only 32.


The difference between TYPE_SIZE and DECL_SIZE could be a way to 
recognize the case of bases with virtual bases, and then either hunt 
down all the virtual bases or just use the bounds of the enclosing 
most-derived object.


An advanced analysis of classes with virtual bases is beyond what
I have cycles to tackle at this point (it seems it would also need
to be done in the C++ front end?)  It will have to wait until I have
more time or the next stage 1.

So for now, I've changed component_ref_size to fail when DECL_SIZE
isn't equal TYPE_SIZE.


OK.


+    /* DECL_SIZE may be less than TYPE_SIZE in C++ when referring
+   to the type of a virtual base class which doesn't reflect
+   the size of the virtual's members (see pr97595).  */


The problem isn't with the virtual base class itself (A), but with the 
intermediate base class subobject (B), for which DECL_SIZE doesn't 
include the size of the virtual base A, because the A base subobject 
is allocated separately.


I've also adjusted the comments above the _SIZE macros in tree.h
to more closely reflect what happens there.  My main goal isn't
to describe when they don't match with perfect accuracy, just to
point that they may be unequal and (roughly) when.


Sure, but why not be precise?  e.g.

May be less than TYPE_SIZE for a C++ FIELD_DECL representing a base 
class subobject with its own virtual base classes (which are laid out 
separately).


Jason

Re: OpenACC 'kernels' testsuite failures

[David Edelsohn via Gcc-patches]

On Tue, Nov 24, 2020 at 5:19 AM Thomas Schwinge  wrote:
>
> Hi!
>
> On 2020-11-21T10:50:10-0500, David Edelsohn  wrote:
> > I see
> >
> > "during GIMPLE pass: omplower"
> >
> > message for kernels-decompose-ice-2.c.  kernels-decompose-ice-1.c
> > explicitly prunes that output, but kernels-decompose-ice-2.c does not.
> > Is there a reason that the second testcase does not prune that output
> > or can we add it?
>
> So, the expectation (as verified by my x86_64-pc-linux-gnu and
> powerpc64le-unknown-linux-gnu testing) is that
> 'c-c++-common/goacc/kernels-decompose-ice-1.c' (currently) runs into an
> ICE "during GIMPLE pass: omplower", and
> 'c-c++-common/goacc/kernels-decompose-ice-2.c' (currently) runs into an
> ICE "during GIMPLE pass: omp_oacc_kernels_decompose".
>
> Now, you're reporting that for the latter testcase you're instead also
> seeing an ICE "during GIMPLE pass: omplower".  Can you please show the
> full ICE report/backtrace, so that we verify that it's not yet another
> separate issue?  Maybe the AIX system configuration (ABI?)
> mandates/causes some slight difference in how front ends set attributes
> such as 'TREE_ADDRESSABLE' on DECLs, which 'omp_oacc_kernels_decompose'
> (currently) is sensitive to (hence the ICEs).  If you confirm that for
> 'c-c++-common/goacc/kernels-decompose-ice-2.c' you're seeing the same
> ICE "during GIMPLE pass: omplower" as seen for
> 'c-c++-common/goacc/kernels-decompose-ice-1.c', then it shall be fine to
> simply add 'dg-prune-output "during GIMPLE pass: omplower"' to
> 'c-c++-common/goacc/kernels-decompose-ice-2.c', too.  (Please do it once
> you've verified/tested that, or I can do it later.)

The error messages reported on AIX are:

Executing on host: /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/
/nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c
   -fdiagnostics-plain-output   -fopenacc -fopenacc-kernels=decompose
-S -o kernels-decompose-ice-2.s
   (timeout = 300)
spawn -ignore SIGHUP /tmp/GCC/gcc/xgcc -B/tmp/GCC/gcc/
/nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c
-fdiagnostics-plain-output -fopenacc -fopenacc-kernels=decompose -S -o
kernels-decompose-ice-2.s
during GIMPLE pass: omplower
/nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c:
In function 'main':
/nasfarm/edelsohn/src/src/gcc/testsuite/c-c++-common/goacc/kernels-decompose-ice-2.c:13:9:
internal compiler error: in lower_omp_target, at omp-low.c:12216
ranges offset out of range
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1

Thanks, David

Re: [PATCH 1/3] PowerPC: Add long double target-supports.

[Michael Meissner via Gcc-patches]

On Mon, Nov 23, 2020 at 02:28:57PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Sat, Nov 21, 2020 at 12:33:52AM -0500, Michael Meissner wrote:
> > +# See if the target is a powerpc with the long double format that uses the 
> > IBM
> > +# extended double format.
> 
> "Return 1 if the target is PowerPC, and long double is IBM extended double."
> 
> > @@ -7939,6 +7992,9 @@ proc is-effective-target { arg } {
> >   "power10_hw" { set selected [check_power10_hw_available] }
> >   "ppc_float128_sw" { set selected [check_ppc_float128_sw_available] }
> >   "ppc_float128_hw" { set selected [check_ppc_float128_hw_available] }
> > + "ppc_long_double_ibm" { set selected [check_ppc_long_double_ibm] }
> > + "ppc_long_double_ieee" { set selected [check_ppc_long_double_ieee] }
> > + "ppc_long_double_64bit" { set selected [check_ppc_long_double_64bit] }
> >   "ppc_recip_hw"   { set selected [check_ppc_recip_hw_available] }
> >   "ppc_cpu_supports_hw" { set selected 
> > [check_ppc_cpu_supports_hw_available] }
> >   "ppc_mma_hw" { set selected [check_ppc_mma_hw_available] }
> 
> Why this?  It just defines aliases to the exact same name?

If you remove those lines you get the failure from the default case:

  default  { error "unknown effective target keyword `$arg'" }

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

[Jason Merrill via Gcc-patches]

On 11/22/20 3:05 AM, Bernd Edlinger wrote:

Hi,

this avoids the need to use -fno-threadsafe-statics on
arm-none-eabi or working around that problem by supplying
a dummy __sync_synchronize function which might
just lead to silent code failure of the worst kind
(non-reproducable, racy) at runtime, as was pointed out
on previous discussions here.

When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.

This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.


Instead of a new target macro, can't you follow 
fold_builtin_atomic_always_lock_free/can_atomic_load_p?


Jason

Re: [PATCH] c++: Implement -Wuninitialized for mem-initializers [PR19808]

[Jason Merrill via Gcc-patches]

On 11/20/20 6:08 PM, Martin Sebor wrote:

On 11/19/20 11:41 AM, Jason Merrill wrote:

On 11/17/20 3:44 AM, Jan Hubicka wrote:
On Tue, Nov 17, 2020 at 01:33:48AM -0500, Jason Merrill via 
Gcc-patches wrote:

Why doesn't the middle-end warning work for inline functions?


It does but only when they're called (and, as usual, also unless
the uninitialized use is eliminated).


Yes, but why?  I assume because we don't bother going through all 
the phases
of compilation for unused inlines, but couldn't we change that when 
we're

asking for (certain) warnings?


CCing Richard and Honza on this.

I think for unused functions we don't even gimplify unused 
functions, the
cgraph code just throws them away.  Even trying just to run the 
first few

passes (gimplification up to uninit1) would have several high costs,

Note that uninit1 is a late pass so it is not just few passes we speak
about.  Late passes are run only on cocde that really lands in .s file
so enabling them would mean splitting the pass queue and running another
unreachable code somewhere.  That would confuse inliner and other IPA
passes since they will have to somehow deal with dead code in their
program size estimate and also affect LTO.

Even early passes are run only on reachable portion of program, since
functions are analyzed by cgraphunit on demand (only if they are
analyzed by someone else). Simlar logic is also done be C++ FE to decide
what templates.  Changling this would also have quite some compile
time/memory use impact.

There is -fkeep-inline-functions.


OK, thanks for the explanation.  -fkeep-inline-functions seems like an 
acceptable answer for people who want a warning audit of their library 
header inlines.


Martin, I notice that the middle-end warning doesn't currently catch 
this:


struct B { int i,j; };

struct A
{
   B b;
   A(): b({b.i}) { }
};

A a;

It does warn if B only has one member; adding the second wrongly 
silences the warning.


The GIMPLE for A's ctor looks like this:

A::A (struct A * const this)
{
   *this = {CLOBBER};
   {
     this->b = {};
     _1 = this->b.i;
     this->b.i = _1;
   }
}

so the b member is cleared first before it's read from and there's
nothing to warn about.  This happens for C structs too:

void f (void*);

struct A { int i, j; };

void g (void)
{
   struct A a = { a.i };
   f (&a);
}

The uninitialized read is in the original dump (below) so the zero
initialization happens in the gimplifier and could be diagnosed
there.

;; enabled by -tree-original


{
   struct A a = {.i=a.i};

     struct A a = {.i=a.i};
   f ((void *) &a);
}


Ah, yes, because gimplify_init_constructor leaves the first assignment 
to clear the whole object if there aren't initializers for all the members.


Jason

[committed] avoid more invalid redeclarations (PR 97955)

[Martin Sebor via Gcc-patches]

The attached trivial patch, committed in r11-5325, avoids failing
with an ICE when attempting to check the arguments of an invalid
function redeclaration.

Martin
PR c/97955 - ICE in build_array_type_1 on invalid redeclaration of function with VLA parameter

gcc/c-family/ChangeLog:

	* c-warn.c (warn_parm_array_mismatch): Avoid invalid redeclarations.

gcc/testsuite/ChangeLog:

	* gcc.dg/pr97955.c: New test.

diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index 6d22a113ad0..91abafe49b1 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -3379,8 +3379,9 @@ warn_parm_array_mismatch (location_t origloc, tree fndecl, tree newparms)
 	return;
 
   /* Only check pointers and C++ references.  */
+  tree curptype = TREE_TYPE (curp);
   tree newptype = TREE_TYPE (newp);
-  if (!POINTER_TYPE_P (newptype))
+  if (!POINTER_TYPE_P (curptype) || !POINTER_TYPE_P (newptype))
 	continue;
 
   /* Skip mismatches in __builtin_va_list that is commonly
@@ -3430,7 +3431,6 @@ warn_parm_array_mismatch (location_t origloc, tree fndecl, tree newparms)
   if (origloc == UNKNOWN_LOCATION)
 	origloc = newloc;
 
-  tree curptype = TREE_TYPE (curp);
   const std::string newparmstr = newa->array_as_string (newptype);
   const std::string curparmstr = cura->array_as_string (curptype);
   if (new_vla_p && !cur_vla_p)
diff --git a/gcc/testsuite/gcc.dg/pr97955.c b/gcc/testsuite/gcc.dg/pr97955.c
new file mode 100644
index 000..a5236c76c94
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr97955.c
@@ -0,0 +1,7 @@
+/* PR 97955 - ICE in build_array_type_1 on invalid redeclaration of function
+   with VLA parameter
+   { dg-do compile }
+   { dg-options "-Wall" } */
+
+void f (int n, int a[n]);
+void f (int *b) { }   // { dg-error "conflicting types" }

Re: [PATCH 2/4] rs6000: Support variable insert and Expand vec_insert in expander [PR79251]

[Segher Boessenkool]

Hi!

On Sat, Oct 10, 2020 at 03:08:23AM -0500, Xionghu Luo wrote:
> vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
> to be insert, arg2 is the place to insert arg1 to arg0.  Current expander
> generates stxv+stwx+lxv if arg2 is variable instead of constant, which
> causes serious store hit load performance issue on Power.  This patch tries
>  1) Build VIEW_CONVERT_EXPR for vec_insert (i, v, n) like v[n&3] = i to
> unify the gimple code, then expander could use vec_set_optab to expand.
>  2) Expand the IFN VEC_SET to fast instructions: lvsr+insert+lvsl.
> In this way, "vec_insert (i, v, n)" and "v[n&3] = i" won't be expanded too
> early in gimple stage if arg2 is variable, avoid generating store hit load
> instructions.
> 
> For Power9 V4SI:
>   addi 9,1,-16
>   rldic 6,6,2,60
>   stxv 34,-16(1)
>   stwx 5,9,6
>   lxv 34,-16(1)
> =>
>   rlwinm 6,6,2,28,29
>   mtvsrwz 0,5
>   lvsr 1,0,6
>   lvsl 0,0,6
>   xxperm 34,34,33
>   xxinsertw 34,0,12
>   xxperm 34,34,32

It still takes me quite some time to verify this, tricky bit-fiddling!

But the code that generates this is easier to read :-)

> +/* Insert VAL into IDX of TARGET, VAL size is same of the vector element, IDX
> +   is variable and also counts by vector element size.  */

"Set vector element IDX of TARGET to VAL.  IDX is not a constant
integer."?


Okay for trunk (with an improved comment).  Thanks!


Segher

Re: [PATCH] c++: Don't form a templated TARGET_EXPR in finish_compound_literal

[Jason Merrill via Gcc-patches]

On 11/16/20 5:45 PM, Patrick Palka wrote:

On Mon, 16 Nov 2020, Jason Merrill wrote:


On 11/13/20 10:43 AM, Patrick Palka wrote:

On Thu, 12 Nov 2020, Jason Merrill wrote:


On 11/12/20 1:27 PM, Patrick Palka wrote:

The atom_cache in normalize_atom relies on the assumption that two
equivalent (templated) trees (in the sense of cp_tree_equal) must use
the same template parameters (according to find_template_parameters).

This assumption unfortunately doesn't always hold for TARGET_EXPRs,
because cp_tree_equal ignores an artificial target of a TARGET_EXPR, but
find_template_parameters walks this target (and its DECL_CONTEXT).

Hence two TARGET_EXPRs built by force_target_expr with the same
initializer but under different settings of current_function_decl may
compare equal according to cp_tree_equal, but find_template_parameters
returns a different set of template parameters for them.  This breaks
the below testcase because during normalization we build two such
TARGET_EXPRs (one under current_function_decl=f and another under =g),
and then use the same ATOMIC_CONSTR for the two corresponding atoms,
leading to a crash during satisfaction of g's associated constraints.

This patch works around this assumption violation by removing the source
of these templated TARGET_EXPRs.  The relevant call to get_target_expr
was
added in r9-6043, but it seems it's no longer necessary (according to
https://gcc.gnu.org/pipermail/gcc-patches/2019-February/517323.html, the
call was added in order to avoid regressing on initlist109.C at the
time).

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?


OK.  I wonder what else asserting !processing_template_decl in
build_target_expr would find...


FWIW, testing exposed seven distinct paths that trigger such an assert,
five of which go through build_cplus_new:


Most of these are built as part of overload resolution and then thrown away,
only using the result for its type.  But I wonder about the build_aggr_init
instance.


0x6b3983 build_target_expr
  /gcc/gcc/cp/tree.c:496
0xa94ec8 build_cplus_new(tree_node*, tree_node*, int)
  /gcc/gcc/cp/tree.c:728
0x91712b force_rvalue(tree_node*, int)
  /gcc/gcc/cp/cvt.c:569
0x8b8310 build_conditional_expr_1
  /gcc/gcc/cp/call.c:5592
0x8ba08c build_conditional_expr(op_location_t const&, tree_node*,
tree_node*, tree_node*, int)
  /gcc/gcc/cp/call.c:5777
0xaa70fb build_x_conditional_expr(unsigned int, tree_node*, tree_node*,
tree_node*, int)
  /gcc/gcc/cp/typeck.c:7133
0x9cc9fa cp_parser_assignment_expression
  /gcc/gcc/cp/parser.c:9964


This one gets discarded by build_x_conditional_expr.


0x6b3983 build_target_expr
  /gcc/gcc/cp/tree.c:496
0xa94ec8 build_cplus_new(tree_node*, tree_node*, int)
  /gcc/gcc/cp/tree.c:728
0x97d185 expand_default_init
  /gcc/gcc/cp/init.c:1924
0x97d185 expand_aggr_init_1
  /gcc/gcc/cp/init.c:2101
0x97f026 build_aggr_init(tree_node*, tree_node*, int, int)
  /gcc/gcc/cp/init.c:1835
0x92c88d build_aggr_init_full_exprs
  /gcc/gcc/cp/decl.c:6696
0x92c88d check_initializer
  /gcc/gcc/cp/decl.c:6857
0x950982 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
  /gcc/gcc/cp/decl.c:7699
0x960c7e grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
  /gcc/gcc/cp/decl2.c:1000
0xa02ceb cp_parser_member_declaration
  /gcc/gcc/cp/parser.c:25755


This one looks dubious.  Which testcase?


IIRC many constexpr testcases trigger this one, for instance
g++.dg/cpp0x/constexpr-initlist9.C and g++.dg/cpp0x/constexpr-static6.C:

gcc/testsuite/g++.dg/cpp0x/constexpr-initlist9.C: In function ‘void 
generate_sudoku(T)’:
gcc/testsuite/g++.dg/cpp0x/constexpr-initlist9.C:34:50: internal compiler 
error: in build_target_expr, at cp/tree.c:495
34 |   constexpr auto positions = make_grid_positions(); // fail
   |  ^
0x6b3c47 build_target_expr
 /home/patrick/code/gcc/gcc/cp/tree.c:495
0xa97248 build_cplus_new(tree_node*, tree_node*, int)
 /home/patrick/code/gcc/gcc/cp/tree.c:727
0x97eed5 expand_default_init
 /home/patrick/code/gcc/gcc/cp/init.c:1924
0x97eed5 expand_aggr_init_1
 /home/patrick/code/gcc/gcc/cp/init.c:2101
0x980d76 build_aggr_init(tree_node*, tree_node*, int, int)
 /home/patrick/code/gcc/gcc/cp/init.c:1835
0x92e5cd build_aggr_init_full_exprs
 /home/patrick/code/gcc/gcc/cp/decl.c:6696
0x92e5cd check_initializer
 /home/patrick/code/gcc/gcc/cp/decl.c:6857
0x9525c2 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
 /home/patrick/code/gcc/gcc/cp/decl.c:7699
0x9fcdf7 cp_parser_init_declarator
 /home/patrick/code/gcc/gcc/cp/parser.c:21362


gcc/testsuite/g++.dg/cpp0x/constexpr-static6.C:17:28: internal compiler error: 
in build_target_expr, at cp/tree.c:495
17 |   constexpr stat

Re: [PATCH v2] Fix -ffast-math flags handling inconsistencies

[Segher Boessenkool]

Hi Ulrich,

On Tue, Nov 24, 2020 at 07:42:47PM +0100, Ulrich Weigand wrote:
> This did handle flag_excess_precision incorrectly, causing in particular
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970
> 
> I've reverted for now and will post a modified patch later.
> Sorry for the breakage!
> 
> At a first glance, it appears the problem is that -fexcess-precision=fast
> is already the default, so it does not make sense for -fno-fast-math to
> "reset" this back to default.  Probably the best is for fast-math to
> simply not touch excess precision at all:
> - if it is set explicitly on the command line, fast-math should not
>   affect it in any case;
> - if it is not set explicitly on the command line, the default either
>   with fast-math or no-fast-math is excess-precision=fast, so again
>   it should not be touched.
> 
> I'll still need to look into the language-specific handling of the
> excess precision setting to make sure this works for all languages.

At least C uses "standard" (instead of "fast") for the strict ISO C
dialects.


Segher

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 21/11/20 16:36 -0800, H.J. Lu wrote:

On Sat, Nov 21, 2020 at 9:40 AM Jonathan Wakely via Gcc-patches
 wrote:


On 21/11/20 17:04 +, Jonathan Wakely wrote:
>On 21/11/20 16:16 +0100, Andreas Schwab wrote:
>>In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
>>from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:
 In member function 'void std::atomic_flag::wait(bool, std::memory_order) const':
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 error: no matching function for call to '__atomic_wait(const __atomic_flag_data_type*, 
bool&, std::atomic_flag::wait(bool, std::memory_order) const::)'
>>In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:41,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
>>from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note: candidate: 'template void std::__atomic_wait(const 
_Tp*, _Tp, _Pred)'
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note:   template argument deduction/substitution failed:
>>In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
>>from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
>>from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
>>/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 note:   deduced conflicting types for parameter '_Tp' ('unsigned char' and 'bool')
>
>I'm testing this.

I'm committing this instead, it's the same but also disables
29_atomics/atomic/wait_notify/generic.cc on non-linux targets.

Tested sparc-solaris2.11 and powerpc64le-linux.

There are still some timeouts on linux:

FAIL: 30_threads/latch/3.cc execution test
FAIL: 30_threads/semaphore/try_acquire_for.cc execution test



I opened:

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


I've disabled the failing tests for now. They can be re-enabled after
the problem is found and fixed.

Committed to trunk.


commit a3313a2214a6253672ab4fa37a2dcf57fd0f8dce
Author: Jonathan Wakely 
Date:   Tue Nov 24 23:22:01 2020

libstdc++: Disable failing tests [PR 97936]

These tests are unstable and causing failures due to timeouts. Disable
them until the cause can be found, so that testing doesn't have to wait
for them to timeout.

libstdc++-v3/ChangeLog:

PR libstdc++/97936
PR libstdc++/97944
* testsuite/29_atomics/atomic_integral/wait_notify.cc: Disable.
Do not require pthreads, but add -pthread when appropriate.
* testsuite/30_threads/jthread/95989.cc: Likewise.
* testsuite/30_threads/latch/3.cc: Likewise.
* testsuite/30_threads/semaphore/try_acquire_until.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc b/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc
index abf2bfdbee96..762583cf8c76 100644
--- a/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc
+++ b/libstdc++-v3/testsuite/29_atomics/atomic_integral/wait_notify.cc
@@ -1,8 +1,9 @@
-// { dg-options "-std=gnu++2a -pthread" }
+// { dg-options "-std=gnu++2a" }
 // { dg-do run { target c++2a } }
-// { dg-require-effective-target pthread }
 // { dg-require-gthreads "" }
 // { dg-add-options libatomic }
+// { dg-additional-options "-pthread" { target pthread } }
+// { dg-skip-if "

Re: [PATCH 1/3] PowerPC: Add long double target-supports.

[Segher Boessenkool]

On Tue, Nov 24, 2020 at 04:44:19PM -0500, Michael Meissner wrote:
> On Mon, Nov 23, 2020 at 02:28:57PM -0600, Segher Boessenkool wrote:
> > On Sat, Nov 21, 2020 at 12:33:52AM -0500, Michael Meissner wrote:
> > > +# See if the target is a powerpc with the long double format that uses 
> > > the IBM
> > > +# extended double format.
> > 
> > "Return 1 if the target is PowerPC, and long double is IBM extended double."
> > 
> > > @@ -7939,6 +7992,9 @@ proc is-effective-target { arg } {
> > > "power10_hw" { set selected [check_power10_hw_available] }
> > > "ppc_float128_sw" { set selected [check_ppc_float128_sw_available] }
> > > "ppc_float128_hw" { set selected [check_ppc_float128_hw_available] }
> > > +   "ppc_long_double_ibm" { set selected [check_ppc_long_double_ibm] }
> > > +   "ppc_long_double_ieee" { set selected [check_ppc_long_double_ieee] }
> > > +   "ppc_long_double_64bit" { set selected [check_ppc_long_double_64bit] }
> > > "ppc_recip_hw"   { set selected [check_ppc_recip_hw_available] }
> > > "ppc_cpu_supports_hw" { set selected 
> > > [check_ppc_cpu_supports_hw_available] }
> > > "ppc_mma_hw" { set selected [check_ppc_mma_hw_available] }
> > 
> > Why this?  It just defines aliases to the exact same name?
> 
> If you remove those lines you get the failure from the default case:
> 
> default  { error "unknown effective target keyword `$arg'" }

So name the functions check_effective_target_ppc_long_double_ibm etc.?
Then it is all handled by the generic code, and yes you can use these
same names in the testcases.


Segher

Re: [PATCH] c++: v2: Add __builtin_bit_cast to implement std::bit_cast [PR93121]

[Jeff Law via Gcc-patches]

On 11/2/20 12:21 PM, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jul 30, 2020 at 10:16:46AM -0400, Jason Merrill via Gcc-patches wrote:
>>> The following patch adds __builtin_bit_cast builtin, similarly to
>>> clang or MSVC which implement std::bit_cast using such an builtin too.
>> Great!
> Sorry for the long delay.
>
> The following patch implements what you've requested in the review.
> It doesn't deal with the padding bits being (sometimes) well defined, but if
> we e.g. get a new CONSTRUCTOR bit that would request that (and corresponding
> gimplifier change to pre-initialize to all zeros), it could be easily
> adjusted (just for such CONSTRUCTORs memset the whole mask portion
> (total_bytes) and set mask to NULL).  If there are other cases where
> such handling is desirable (e.g. I wonder about bit_cast being called on
> non-automatic const variables where their CONSTRUCTOR at least
> implementation-wise would end up being on pre-zeroed .rodata (or .data)
> memory), that can be handled too.
>
> In the previous version I was using next_initializable_field, that is
> something that isn't available in the middle-end, so all I do right now
> is just skip non-FIELD_DECLs, unnamed bit-fields and fields with zero size.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-11-02  Jakub Jelinek  
>
>   PR libstdc++/93121
>   * fold-const.h (native_encode_initializer): Add mask argument
>   defaulted to nullptr.
>   (find_bitfield_repr_type): Declare.
>   * fold-const.c (find_bitfield_repr_type): New function.
>   (native_encode_initializer): Add mask argument and support for
>   filling it.  Handle also some bitfields without integral
>   DECL_BIT_FIELD_REPRESENTATIVE.
>
>   * c-common.h (enum rid): Add RID_BUILTIN_BIT_CAST.
>   * c-common.c (c_common_reswords): Add __builtin_bit_cast.
>
>   * cp-tree.h (cp_build_bit_cast): Declare.
>   * cp-tree.def (BIT_CAST_EXPR): New tree code.
>   * cp-objcp-common.c (names_builtin_p): Handle RID_BUILTIN_BIT_CAST.
>   (cp_common_init_ts): Handle BIT_CAST_EXPR.
>   * cxx-pretty-print.c (cxx_pretty_printer::postfix_expression):
>   Likewise.
>   * parser.c (cp_parser_postfix_expression): Handle
>   RID_BUILTIN_BIT_CAST.
>   * semantics.c (cp_build_bit_cast): New function.
>   * tree.c (cp_tree_equal): Handle BIT_CAST_EXPR.
>   (cp_walk_subtrees): Likewise.
>   * pt.c (tsubst_copy): Likewise.
>   * constexpr.c (check_bit_cast_type, cxx_native_interpret_aggregate,
>   cxx_eval_bit_cast): New functions.
>   (cxx_eval_constant_expression): Handle BIT_CAST_EXPR.
>   (potential_constant_expression_1): Likewise.
>   * cp-gimplify.c (cp_genericize_r): Likewise.
>
>   * g++.dg/cpp2a/bit-cast1.C: New test.
>   * g++.dg/cpp2a/bit-cast2.C: New test.
>   * g++.dg/cpp2a/bit-cast3.C: New test.
>   * g++.dg/cpp2a/bit-cast4.C: New test.
>   * g++.dg/cpp2a/bit-cast5.C: New test.
Just looking at the fold-const and c-common bits.  Jason is going to
look the the cp/ stuff per today's meeting.

FIrst, do we need to document the new builtin? 

> --- gcc/fold-const.c.jj   2020-10-15 15:09:49.079725120 +0200
> +++ gcc/fold-const.c  2020-11-02 17:20:43.784633491 +0100
> @@ -7998,6 +8083,8 @@ native_encode_initializer (tree init, un
>   if (ptr)
> memcpy (ptr + (curpos - o), ptr + (pos - o),
> fieldsize);
> + if (mask)
> +   memcpy (mask + curpos, mask + pos, fieldsize);
> }
>   else if (!native_encode_initializer (val,
>ptr
Presumably we've already determined that the memcpy won't have an
overlap between the source and destination here?

Assuming that's true, then it looks good to me.

jeff

[PATCH] make POINTER_PLUS offset sizetype (PR 97956)

[Martin Sebor via Gcc-patches]

Offsets in pointer expressions are signed but GCC prefers to
represent them as sizetype instead, and sometimes (though not
always) crashes during GIMPLE verification when they're not.
The sometimes-but-not-always part makes it easy for mistakes
to slip in and go undetected for months, until someone either
trips over it by accident, or deliberately tries to break
things (the test case in the bug relies on declaring memchr
with the third argument of type signed long which is what's
apparently needed to trigger the ICE).  The attached patch
corrects a couple of such mistakes.

Martin

PS It would save us the time and effort dealing with these
bugs to either detect (or even correct) the mistakes early,
at the time the POINTER_PLUS_EXPR is built.  Adding an assert
to gimple_build_assign()) to verify that it has the expected
type (or converting the operand to sizetype) as in the change
below does that.  I'm pretty sure I submitted a patch like it
in the past but it was rejected.  If I'm wrong or if there are
no objections to it now I'll be happy to commit it as well.

Both patches were tested on x86_64-linux.

diff --git a/gcc/gimple.c b/gcc/gimple.c
index e3e508daf2f..8e88bab9e41 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -489,6 +489,9 @@ gassign *
 gimple_build_assign (tree lhs, enum tree_code subcode, tree op1,
 tree op2 MEM_STAT_DECL)
 {
+  if (subcode == POINTER_PLUS_EXPR)
+gcc_checking_assert (ptrofftype_p (TREE_TYPE (op2)));
+
   return gimple_build_assign_1 (lhs, subcode, op1, op2, NULL_TREE
PASS_MEM_STAT);
 }
PR middle-end/97956 - ICE due to type mismatch in pointer_plus_expr during memchr folding

gcc/ChangeLog:

	PR middle-end/97956
	* expr.c (constant_byte_string): Use sizetype for pointer offsets.
	* gimple-fold.c (gimple_fold_builtin_memchr): Ditto.

gcc/testsuite/ChangeLog:

	PR middle-end/97956
	* gcc.dg/memchr-3.c: New test.

diff --git a/gcc/expr.c b/gcc/expr.c
index 25e93b6d46f..b2197f613c7 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -11893,7 +11893,7 @@ constant_byte_string (tree arg, tree *ptr_offset, tree *mem_size, tree *decl,
   init = TREE_OPERAND (init, 0);
 
   *mem_size = size_int (TREE_STRING_LENGTH (init));
-  *ptr_offset = wide_int_to_tree (ssizetype, base_off);
+  *ptr_offset = wide_int_to_tree (sizetype, base_off);
 
   if (decl)
 	*decl = array;
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 905c0a057cb..2e98a2c70cd 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -2689,7 +2689,7 @@ gimple_fold_builtin_memchr (gimple_stmt_iterator *gsi)
 	  gimple_seq stmts = NULL;
 	  if (lhs != NULL_TREE)
 	{
-	  tree offset_cst = build_int_cst (TREE_TYPE (len), offset);
+	  tree offset_cst = build_int_cst (sizetype, offset);
 	  gassign *stmt = gimple_build_assign (lhs, POINTER_PLUS_EXPR,
 		   arg1, offset_cst);
 	  gimple_seq_add_stmt_without_update (&stmts, stmt);
diff --git a/gcc/testsuite/gcc.dg/memchr-3.c b/gcc/testsuite/gcc.dg/memchr-3.c
new file mode 100644
index 000..c1f4e9e10dc
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/memchr-3.c
@@ -0,0 +1,25 @@
+/* PR middle-end/97956 - ICE due to type mismatch in pointer_plus_expr
+   during memchr folding
+   { dg-do compile }
+   { dg-options "-O2 -Wall" } */
+
+typedef __INT8_TYPE__  int8_t;
+typedef __INT32_TYPE__ int32_t;
+
+extern void* memchr (const void*, int, long);
+
+struct SX
+{
+  int32_t n;
+  int8_t a[];
+};
+
+const struct SX sx = { 0x1221 };
+const char sx_rep[] = { };
+
+void test_find (void)
+{
+  int n = 0, nb = (const char*)&sx.a - (const char*)&sx;
+  const char *p = (const char*)&sx, *q = sx_rep;
+  n += p + 1 == memchr (p, q[1], nb);
+}

Re: [PATCH] libstdc++: Add C++2a synchronization support

[Jonathan Wakely via Gcc-patches]

On 24/11/20 23:45 +, Jonathan Wakely wrote:

On 21/11/20 16:36 -0800, H.J. Lu wrote:

On Sat, Nov 21, 2020 at 9:40 AM Jonathan Wakely via Gcc-patches
 wrote:


On 21/11/20 17:04 +, Jonathan Wakely wrote:

On 21/11/20 16:16 +0100, Andreas Schwab wrote:

In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
   from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:
 In member function 'void std::atomic_flag::wait(bool, std::memory_order) 
const':
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 error: no matching function for call to '__atomic_wait(const __atomic_flag_data_type*, 
bool&, std::atomic_flag::wait(bool, std::memory_order) const::)'
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:41,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
   from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note: candidate: 'template void 
std::__atomic_wait(const _Tp*, _Tp, _Pred)'
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_wait.h:265:
 note:   template argument deduction/substitution failed:
In file included from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/memory:78,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/stdc++.h:82,
   from 
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/m68k-linux/bits/extc++.h:32,
   from 
/daten/aranym/gcc/gcc-20201121/libstdc++-v3/testsuite/17_intro/headers/c++2020/all_attributes.cc:37:
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/atomic_base.h:239:
 note:   deduced conflicting types for parameter '_Tp' ('unsigned char' and 
'bool')


I'm testing this.


I'm committing this instead, it's the same but also disables
29_atomics/atomic/wait_notify/generic.cc on non-linux targets.

Tested sparc-solaris2.11 and powerpc64le-linux.

There are still some timeouts on linux:

FAIL: 30_threads/latch/3.cc execution test
FAIL: 30_threads/semaphore/try_acquire_for.cc execution test



I opened:

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


I've disabled the failing tests for now. They can be re-enabled after
the problem is found and fixed.


I was finally able to reproduce the hangs, and I think this is the
fix:

--- a/libstdc++-v3/include/bits/atomic_wait.h
+++ b/libstdc++-v3/include/bits/atomic_wait.h
@@ -100,9 +100,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
auto __e = syscall (SYS_futex, static_cast(__addr),
  
static_cast(__futex_wait_flags::__wait_private),
__val, nullptr);
-   if (!__e)
+   if (!__e || errno == EAGAIN)
  break;
-   else if (!(errno == EINTR || errno == EAGAIN))
+   else if (errno != EINTR)
  __throw_system_error(__e);
  }
   }

The problem is that we're going into a busy loop when SYS_futex
returns EAGAIN, but that means the current value doesn't match the
expected value, so we should return not keep waiting for the value to
change.

[PATCH] clean up more -Wformat-diag (PR 94982)

[Martin Sebor via Gcc-patches]

The attached patch cleans up most remaining -Wformat-diag instances
in an x86_64-build.  I tried to minimize using #pragma diagnostic
so I tweaked the code instead.  A preferable solution might be to
introduce a new format attribute and used it to exempt the pp_printf()
and verbatim() functions from some of the -Wformat-diag checks but that
would require more surgery on the warning code than I think is called
for at this point.

Tested by bootstrapping all of the languages below (same set I test
all my patches with) and regtesting:
  ada,brig,c,c++,d,fortran,jit,lto,objc,obj-c++

Martin
Clean up -Wformat-diag warnings (PR bootstrap/97622, PR bootstrap/94982)

gcc/c-family/ChangeLog:

	PR bootstrap/94982
	* c-attribs.c (handle_patchable_function_entry_attribute): Avoid
	-Wformat-diag.

gcc/cp/ChangeLog:

	PR bootstrap/94982
	* constraint.cc (debug_argument_list): Avoid -Wformat-diag.
	* error.c (function_category): Same.
	(print_template_differences): Same.
	* logic.cc (debug): Same.
	* name-lookup.c (lookup_using_decl): Same.
	* parser.c (maybe_add_cast_fixit): Same.
	(cp_parser_template_introduction): Same.
	* typeck.c (access_failure_info::add_fixit_hint): Same.

gcc/ChangeLog:

	PR bootstrap/97622
	PR bootstrap/94982
	* digraph.cc (struct test_edge): Avoid -Wformat-diag.
	* dumpfile.c (dump_loc): Same.
	(dump_context::begin_scope): Same.
	* edit-context.c (edited_file::print_diff): Same.
	(edited_file::print_diff_hunk): Same.
	* json.cc (object::print): Same.
	* lto-wrapper.c (merge_and_complain): Same.
	* reload.c (find_reloads): Same.
	* tree-diagnostic-path.cc (print_path_summary_as_text): Same.
	* ubsan.c (ubsan_type_descriptor): Same.

gcc/jit/ChangeLog:

	PR bootstrap/94982
	* jit-recording.c (recording::function::dump_to_dot): Avoid
	-Wformat-diag.
	(recording::block::dump_to_dot): Same.

gcc/testsuite/ChangeLog:

	PR bootstrap/94982
	* c-c++-common/patchable_function_entry-error-3.c: Adjust text
	of expected warning.

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 6d515dca05a..99b663085f2 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -5191,8 +5191,8 @@ handle_patchable_function_entry_attribute (tree *, tree name, tree args,
   if (tree_to_uhwi (val) > USHRT_MAX)
 	{
 	  warning (OPT_Wattributes,
-		   "%qE attribute argument %qE is out of range (> 65535)",
-		   name, val);
+		   "%qE attribute argument %qE exceeds %u",
+		   name, val, USHRT_MAX);
 	  *no_add_attrs = true;
 	  return NULL_TREE;
 	}
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 8691281d5f1..00d2f2ea9a8 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -533,9 +533,9 @@ debug_argument_list (tree args)
 {
   tree arg = TREE_VEC_ELT (args, i);
   if (TYPE_P (arg))
-	verbatim ("ARG %qT", arg);
+	verbatim ("argument %qT", arg);
   else
-	verbatim ("ARG %qE", arg);
+	verbatim ("argument %qE", arg);
 }
 }
 
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index d27545d1223..85249f4a539 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -3553,6 +3553,14 @@ function_category (tree fn)
 return _("In function %qs");
 }
 
+/* Disable warnings about missing quoting in GCC diagnostics for
+   the pp_verbatim calls.  Their format strings deliberately don't
+   follow GCC diagnostic conventions.  */
+#if __GNUC__ >= 10
+#  pragma GCC diagnostic push
+#  pragma GCC diagnostic ignored "-Wformat-diag"
+#endif
+
 /* Report the full context of a current template instantiation,
onto BUFFER.  */
 static void
@@ -4053,6 +4061,10 @@ print_template_differences (pretty_printer *pp, tree type_a, tree type_b,
   pp_printf (pp, ">");
 }
 
+#if __GNUC__ >= 10
+#  pragma GCC diagnostic pop
+#endif
+
 /* As type_to_string, but for a template, potentially colorizing/eliding
in comparison with PEER.
For example, if TYPE is map and PEER is map,
diff --git a/gcc/cp/logic.cc b/gcc/cp/logic.cc
index 6701488bc1c..5592680b08e 100644
--- a/gcc/cp/logic.cc
+++ b/gcc/cp/logic.cc
@@ -303,9 +303,10 @@ debug (formula& f)
 {
   for (formula::iterator i = f.begin(); i != f.end(); ++i)
 {
-  verbatim ("(((");
+  /* Format punctuators via %s to avoid -Wformat-diag.  */
+  verbatim ("%s", "(((");
   debug (*i);
-  verbatim (")))");
+  verbatim ("%s", ")))");
 }
 }
 
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index bf05e7bbcd1..837c0ea89af 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -4613,7 +4613,8 @@ lookup_using_decl (tree scope, name_lookup &lookup)
 	{
 	  if (!TYPE_P (current))
 	{
-	  error ("non-member using-decl names constructor of %qT", scope);
+	  error ("non-member using-declaration names constructor of %qT",
+		 scope);
 	  return NULL_TREE;
 	}
 	  maybe_warn_cpp0x (CPP0X_INHERITING_CTORS);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 88021243ee4..d11900a7dd5 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -9382,7 +9382,8 @@ maybe_add_cast_fixit (ri

Re: [PATCH v2] rs6000, vector integer multiply/divide/modulo instructions

[Pat Haugen via Gcc-patches]

On 11/24/20 12:59 PM, Carl Love via Gcc-patches wrote:
> +
> +(define_insn "dives_"
> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> +(unspec:VIlong [(match_operand:VIlong 1 "vsx_register_operand" "v")
> + (match_operand:VIlong 2 "vsx_register_operand" "v")]
> +UNSPEC_VDIVES))]
> +  "TARGET_POWER10"
> +  "vdives %0,%1,%2"
> +  [(set_attr "type" "vecdiv")
> +   (set_attr "size" "128")])
> +
> +(define_insn "diveu_"
> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> +(unspec: VIlong [(match_operand:VIlong 1 "vsx_register_operand" "v")
> +  (match_operand:VIlong 2 "vsx_register_operand" "v")]
> + UNSPEC_VDIVEU))]
> +  "TARGET_POWER10"
> +  "vdiveu %0,%1,%2"
> +  [(set_attr "type" "vecdiv")
> +   (set_attr "size" "128")])
> +
> +(define_insn "div3"
> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> + (div:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v")
> + (match_operand:VIlong 2 "vsx_register_operand" "v")))]
> +  "TARGET_POWER10"
> +  "vdivs %0,%1,%2"
> +  [(set_attr "type" "vecdiv")
> +   (set_attr "size" "128")])
> +
> +(define_insn "udiv3"
> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> + (udiv:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v")
> + (match_operand:VIlong 2 "vsx_register_operand" "v")))]
> +  "TARGET_POWER10"
> +  "vdivu %0,%1,%2"
> +  [(set_attr "type" "vecdiv")
> +   (set_attr "size" "128")])
> +
> +(define_insn "mods_"
> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> + (mod:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v")
> + (match_operand:VIlong 2 "vsx_register_operand" "v")))]
> +  "TARGET_POWER10"
> +  "vmods %0,%1,%2"
> +  [(set_attr "type" "vecdiv")
> +   (set_attr "size" "128")])
> +
> +(define_insn "modu_"
> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> + (umod:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v")
> +  (match_operand:VIlong 2 "vsx_register_operand" "v")))]
> +  "TARGET_POWER10"
> +  "vmodu %0,%1,%2"
> +  [(set_attr "type" "vecdiv")
> +   (set_attr "size" "128")])

We should only be setting "size" "128" for instructions that operate on scalar 
128-bit data items (i.e. 'vdivesq' etc). Since the above insns are either 
V2DI/V4SI (ala VIlong mode_iterator), they shouldn't be marked as size 128. If 
you want to set the size based on mode, (set_attr "size" "") should do 
the trick I believe.

-Pat

Re: [PATCH v2] rs6000, vector integer multiply/divide/modulo instructions

[Pat Haugen via Gcc-patches]

On 11/24/20 8:17 PM, Pat Haugen via Gcc-patches wrote:
> On 11/24/20 12:59 PM, Carl Love via Gcc-patches wrote:
>> +
>> +(define_insn "dives_"
>> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
>> +(unspec:VIlong [(match_operand:VIlong 1 "vsx_register_operand" "v")
>> +(match_operand:VIlong 2 "vsx_register_operand" "v")]
>> +   UNSPEC_VDIVES))]
>> +  "TARGET_POWER10"
>> +  "vdives %0,%1,%2"
>> +  [(set_attr "type" "vecdiv")
>> +   (set_attr "size" "128")])
>> +
>> +(define_insn "diveu_"
>> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
>> +(unspec: VIlong [(match_operand:VIlong 1 "vsx_register_operand" "v")
>> + (match_operand:VIlong 2 "vsx_register_operand" "v")]
>> +UNSPEC_VDIVEU))]
>> +  "TARGET_POWER10"
>> +  "vdiveu %0,%1,%2"
>> +  [(set_attr "type" "vecdiv")
>> +   (set_attr "size" "128")])
>> +
>> +(define_insn "div3"
>> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
>> +(div:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v")
>> +(match_operand:VIlong 2 "vsx_register_operand" "v")))]
>> +  "TARGET_POWER10"
>> +  "vdivs %0,%1,%2"
>> +  [(set_attr "type" "vecdiv")
>> +   (set_attr "size" "128")])
>> +
>> +(define_insn "udiv3"
>> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
>> +(udiv:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v")
>> +(match_operand:VIlong 2 "vsx_register_operand" "v")))]
>> +  "TARGET_POWER10"
>> +  "vdivu %0,%1,%2"
>> +  [(set_attr "type" "vecdiv")
>> +   (set_attr "size" "128")])
>> +
>> +(define_insn "mods_"
>> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
>> +(mod:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v")
>> +(match_operand:VIlong 2 "vsx_register_operand" "v")))]
>> +  "TARGET_POWER10"
>> +  "vmods %0,%1,%2"
>> +  [(set_attr "type" "vecdiv")
>> +   (set_attr "size" "128")])
>> +
>> +(define_insn "modu_"
>> +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
>> +(umod:VIlong (match_operand:VIlong 1 "vsx_register_operand" "v")
>> + (match_operand:VIlong 2 "vsx_register_operand" "v")))]
>> +  "TARGET_POWER10"
>> +  "vmodu %0,%1,%2"
>> +  [(set_attr "type" "vecdiv")
>> +   (set_attr "size" "128")])
> 
> We should only be setting "size" "128" for instructions that operate on 
> scalar 128-bit data items (i.e. 'vdivesq' etc). Since the above insns are 
> either V2DI/V4SI (ala VIlong mode_iterator), they shouldn't be marked as size 
> 128. If you want to set the size based on mode, (set_attr "size" "") 
> should do the trick I believe.

Well, after you update "(define_mode_attr bits" in rs6000.md for V2DI/V4SI.