Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__

[Andrew Pinski via Gcc-patches]

On Sun, Apr 30, 2023 at 4:15 PM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 4/30/23 12:30, Jeff Law wrote:
> >
> >
> > On 1/12/23 09:02, Longjun Luo via Gcc-patches wrote:
> >>  From 0821df518b264e754d698d399f98be1a62945e32 Mon Sep 17 00:00:00 2001
> >> From: Longjun Luo 
> >> Date: Thu, 12 Jan 2023 23:59:54 +0800
> >> Subject: [PATCH] libcpp: suppress builtin macro redefined warnings for
> >>   __LINE__
> >>
> >> As implied in
> >> gcc.gnu.org/legacy-ml/gcc-patches/2008-09/msg00076.html,
> >> gcc provides -Wno-builtin-macro-redefined to suppress warning when
> >> redefining builtin macro. However, at that time, there was no
> >> scenario for __LINE__ macro.
> >>
> >> But, when we try to build a live-patch, we compare sections by using
> >> -ffunction-sections. Some same functions are considered changed because
> >> of __LINE__ macro.
> >>
> >> At present, to detect such a changed caused by __LINE__ macro, we
> >> have to analyse code and maintain a function list. For example,
> >> in kpatch, check this commit
> >> github.com/dynup/kpatch/commit/0e1b95edeafa36edb7bcf11da6d1c00f76d7e03d.
> >>
> >> So, in this scenario, when we try to compared sections, it would
> >> be better to support suppress builtin macro redefined warnings for
> >> __LINE__ macro.
> >>
> >> Signed-off-by: Longjun Luo 
> >> ---
> >>   gcc/testsuite/gcc.dg/builtin-redefine-1.c | 49 +++
> >>   gcc/testsuite/gcc.dg/builtin-redefine.c   | 24 +--
> >>   libcpp/init.cc|  2 +-
> >>   3 files changed, 70 insertions(+), 5 deletions(-)
> >>   create mode 100755 gcc/testsuite/gcc.dg/builtin-redefine-1.c
> > Thanks.  I added a suitable ChangeLog and pushed this to the trunk.
> This is causing regressions on various targets for a few tests:
>
> lm32-sim: c-c++-common/cpp/pr92296-2.c  -Wc++-compat   (test for
> warnings, line 41)
> lm32-sim: gcc.dg/cpp/undef2.c  (test for warnings, line 9)
> lm32-sim: gcc.dg/cpp/undef2.c (test for excess errors)
>
> I have reverted this patch from the trunk.  Please address the
> regressions and resubmit.

>From c-c++-common/cpp/pr92296-2.c (line 40):
#pragma push_macro("__LINE__")
#undef __LINE__ /* { dg-warning "undefining" } */

gcc.dg/cpp/undef2.c (line 9):
#undef __LINE__ /* { dg-warning "undefining \"__LINE__\"" } */


These testcases are specifically testing #undef of __LINE__ ...

Should we be still warning for this case or not?

Thanks,
Andrew Pinski


>
> Thanks,
> Jeff
>

Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__

[Jeff Law via Gcc-patches]

On 4/30/23 12:30, Jeff Law wrote:



On 1/12/23 09:02, Longjun Luo via Gcc-patches wrote:

 From 0821df518b264e754d698d399f98be1a62945e32 Mon Sep 17 00:00:00 2001
From: Longjun Luo 
Date: Thu, 12 Jan 2023 23:59:54 +0800
Subject: [PATCH] libcpp: suppress builtin macro redefined warnings for
  __LINE__

As implied in
gcc.gnu.org/legacy-ml/gcc-patches/2008-09/msg00076.html,
gcc provides -Wno-builtin-macro-redefined to suppress warning when
redefining builtin macro. However, at that time, there was no
scenario for __LINE__ macro.

But, when we try to build a live-patch, we compare sections by using
-ffunction-sections. Some same functions are considered changed because
of __LINE__ macro.

At present, to detect such a changed caused by __LINE__ macro, we
have to analyse code and maintain a function list. For example,
in kpatch, check this commit
github.com/dynup/kpatch/commit/0e1b95edeafa36edb7bcf11da6d1c00f76d7e03d.

So, in this scenario, when we try to compared sections, it would
be better to support suppress builtin macro redefined warnings for
__LINE__ macro.

Signed-off-by: Longjun Luo 
---
  gcc/testsuite/gcc.dg/builtin-redefine-1.c | 49 +++
  gcc/testsuite/gcc.dg/builtin-redefine.c   | 24 +--
  libcpp/init.cc    |  2 +-
  3 files changed, 70 insertions(+), 5 deletions(-)
  create mode 100755 gcc/testsuite/gcc.dg/builtin-redefine-1.c

Thanks.  I added a suitable ChangeLog and pushed this to the trunk.

This is causing regressions on various targets for a few tests:

lm32-sim: c-c++-common/cpp/pr92296-2.c  -Wc++-compat   (test for 
warnings, line 41)

lm32-sim: gcc.dg/cpp/undef2.c  (test for warnings, line 9)
lm32-sim: gcc.dg/cpp/undef2.c (test for excess errors)

I have reverted this patch from the trunk.  Please address the 
regressions and resubmit.


Thanks,
Jeff

[Committed] Update xstormy16's neghi2 pattern to not clobber the carry flag.

[Roger Sayle]

When I converted xstormy16's neghi2 pattern from a define_expand to a
define_insn, I forgot that define_expand implicitly produces a
sequence of instructions, but a define_insn is an implicit parallel,
thereby messing up the clobber (reg:BI CARRY_REG), which can then cause
an ICE in the auto-generated added_clobbers_hard_reg_p.  Whilst stripping
the superfluous PARALLEL resolves this issue, an even better fix is to
use xstormy16's INC instruction, that (like NOT) doesn't affect the carry
flag, resulting in a neghi2 implementation that can more easily be CSE'd
and scheduled.

Many thanks (again) to Jeff Law for testing/reporting this issue.
This patch has been tested by building a cross compiler to xstormy16-elf
from x86_64-pc-linux-gnu.  Committed as obvious (in hindsight).


2023-04-30  Roger Sayle  

gcc/ChangeLog
* config/stormy16/stormy16.md (neghi2): Rewrite pattern using
inc to avoid clobbering the carry flag.

gcc/testsuite/ChangeLog
* gcc.target/xstormy16/neghi2.c: Update expected implementation.

Sorry for any inconvenience.
Roger
--

diff --git a/gcc/config/stormy16/stormy16.md b/gcc/config/stormy16/stormy16.md
index be1ee04..91e4bb1 100644
--- a/gcc/config/stormy16/stormy16.md
+++ b/gcc/config/stormy16/stormy16.md
@@ -519,11 +519,10 @@
 ;; Negation
 
 (define_insn "neghi2"
-  [(parallel [(set (match_operand:HI 0 "register_operand" "=r")
-  (neg:HI (match_operand:HI 1 "register_operand" "0")))
- (clobber (reg:BI CARRY_REG))])]
+  [(set (match_operand:HI 0 "register_operand" "=r")
+   (neg:HI (match_operand:HI 1 "register_operand" "0")))]
   ""
-  "not %0 | add %0,#1"
+  "not %0 | inc %0"
   [(set_attr "length" "4")])
 
 ;; 
diff --git a/gcc/testsuite/gcc.target/xstormy16/neghi2.c 
b/gcc/testsuite/gcc.target/xstormy16/neghi2.c
index dd3dd1e..101c6da 100644
--- a/gcc/testsuite/gcc.target/xstormy16/neghi2.c
+++ b/gcc/testsuite/gcc.target/xstormy16/neghi2.c
@@ -5,4 +5,4 @@ short neg(short x)
 {
   return -x;
 }
-/* { dg-final { scan-assembler "not r2 | add r2,#1" } } */
+/* { dg-final { scan-assembler "not r2 | inc r2" } } */

[PATCH] PHIOPT: Improve replace_phi_edge_with_variable for diamond shapped bb

[Andrew Pinski via Gcc-patches]

While looking at differences between what minmax_replacement
and match_simplify_replacement does. I noticed that they sometimes
chose different edges to remove. I decided we should be able to do
better and be able to remove both empty basic blocks in the
case of match_simplify_replacement as that moves the statements.

This also updates the testcases as now match_simplify_replacement
will remove the unused MIN/MAX_EXPR and they were checking for
those.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

* tree-ssa-phiopt.cc (copy_phi_args): New function.
(replace_phi_edge_with_variable): Handle diamond form bb
with forwarder only empty blocks better.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/minmax-15.c: Update test.
* gcc.dg/tree-ssa/minmax-16.c: Update test.
* gcc.dg/tree-ssa/minmax-3.c: Update test.
* gcc.dg/tree-ssa/minmax-4.c: Update test.
* gcc.dg/tree-ssa/minmax-5.c: Update test.
* gcc.dg/tree-ssa/minmax-8.c: Update test.
---
 gcc/testsuite/gcc.dg/tree-ssa/minmax-15.c |  3 +-
 gcc/testsuite/gcc.dg/tree-ssa/minmax-16.c |  9 ++--
 gcc/testsuite/gcc.dg/tree-ssa/minmax-3.c  |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/minmax-4.c  |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/minmax-5.c  |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/minmax-8.c  |  2 +-
 gcc/tree-ssa-phiopt.cc| 51 ++-
 7 files changed, 59 insertions(+), 12 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-15.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-15.c
index 8a39871c938..6731f91e6c3 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-15.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-15.c
@@ -30,5 +30,6 @@ main (void)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "MIN_EXPR" 3 "phiopt1" } } */
+/* There should only be two MIN_EXPR left, the 3rd one was removed. */
+/* { dg-final { scan-tree-dump-times "MIN_EXPR" 2 "phiopt1" } } */
 /* { dg-final { scan-tree-dump-times "MAX_EXPR" 0 "phiopt1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-16.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-16.c
index 623b12b3f74..094364e6424 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-16.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-16.c
@@ -25,11 +25,8 @@ main (void)
   return 0;
 }
 
-/* After phiopt1, there really should be only 3 MIN_EXPR in the IR (including 
debug statements).
-   But the way phiopt does not cleanup the CFG all the time, the PHI might 
still reference the
-   alternative bb's moved statement.
-   Note in the end, we do dce the statement and other debug statements to end 
up with only 2 MIN_EXPR.
-   So check that too. */
-/* { dg-final { scan-tree-dump-times "MIN_EXPR" 4 "phiopt1" } } */
+/* After phiopt1, will be only 2 MIN_EXPR in the IR (including debug 
statements). */
+/* xk will only have the final result so the extra debug info does not change 
anything. */
+/* { dg-final { scan-tree-dump-times "MIN_EXPR" 2 "phiopt1" } } */
 /* { dg-final { scan-tree-dump-times "MIN_EXPR" 2 "optimized" } } */
 /* { dg-final { scan-tree-dump-times "MAX_EXPR" 0 "phiopt1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-3.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-3.c
index 2af10776346..521afe3e4d9 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-3.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-3.c
@@ -25,5 +25,5 @@ main (void)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "MIN_EXPR" 3 "phiopt1" } } */
+/* { dg-final { scan-tree-dump-times "MIN_EXPR" 2 "phiopt1" } } */
 /* { dg-final { scan-tree-dump-times "MAX_EXPR" 0 "phiopt1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-4.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-4.c
index 973f39bfed3..49e27185b5e 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-4.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-4.c
@@ -26,4 +26,4 @@ main (void)
 }
 
 /* { dg-final { scan-tree-dump-times "MIN_EXPR" 0 "phiopt1" } } */
-/* { dg-final { scan-tree-dump-times "MAX_EXPR" 3 "phiopt1" } } */
+/* { dg-final { scan-tree-dump-times "MAX_EXPR" 2 "phiopt1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-5.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-5.c
index 34e4e720511..194c881cc98 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-5.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-5.c
@@ -25,5 +25,5 @@ main (void)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "MIN_EXPR" 2 "phiopt1" } } */
+/* { dg-final { scan-tree-dump-times "MIN_EXPR" 1 "phiopt1" } } */
 /* { dg-final { scan-tree-dump-times "MAX_EXPR" 1 "phiopt1" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/minmax-8.c 
b/gcc/testsuite/gcc.dg/tree-ssa/minmax-8.c
index 0160e573fef..d5cb53145ea 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/minmax-8.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/minmax-8.c
@@ -26,4 +26,4 @@ main (void)
 }
 
 /* { dg-final { scan-tree-dump-times "MIN_EXPR" 1 "phiopt1" } } */
-/* { dg-final { scan-tree-dump-times "MAX_EXPR" 2 "phiopt1" } } */
+/* { dg-final 

[PATCH] PHIOPT: small refactoring of match_simplify_replacement.

[Andrew Pinski via Gcc-patches]

When I added diamond shaped form bb to match_simplify_replacement,
I copied the code to move the statement rather than factoring it
out to a new function. This does the refactoring to a new function
to avoid the duplicated code. It will make adding support for having
two statements to move easier (the second statement will only be a
conversion).

OK? Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

* tree-ssa-phiopt.cc (move_stmt): New function.
(match_simplify_replacement): Use move_stmt instead
of the inlined version.
---
 gcc/tree-ssa-phiopt.cc | 57 ++
 1 file changed, 24 insertions(+), 33 deletions(-)

diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
index 024a4362093..65b3deea34a 100644
--- a/gcc/tree-ssa-phiopt.cc
+++ b/gcc/tree-ssa-phiopt.cc
@@ -643,6 +643,28 @@ empty_bb_or_one_feeding_into_p (basic_block bb,
   return true;
 }
 
+/* Move STMT to before GSI and insert its defining
+   name into INSERTED_EXPRS bitmap. */
+static void
+move_stmt (gimple *stmt, gimple_stmt_iterator *gsi, auto_bitmap 
_exprs)
+{
+  if (!stmt)
+return;
+  if (dump_file && (dump_flags & TDF_DETAILS))
+{
+  fprintf (dump_file, "statement un-sinked:\n");
+  print_gimple_stmt (dump_file, stmt, 0,
+TDF_VOPS|TDF_MEMSYMS);
+}
+
+  tree name = gimple_get_lhs (stmt);
+  // Mark the name to be renamed if there is one.
+  bitmap_set_bit (inserted_exprs, SSA_NAME_VERSION (name));
+  gimple_stmt_iterator gsi1 = gsi_for_stmt (stmt);
+  gsi_move_before (, gsi);
+  reset_flow_sensitive_info (name);
+}
+
 /*  The function match_simplify_replacement does the main work of doing the
 replacement using match and simplify.  Return true if the replacement is 
done.
 Otherwise return false.
@@ -727,39 +749,8 @@ match_simplify_replacement (basic_block cond_bb, 
basic_block middle_bb,
 
   /* If there was a statement to move, move it to right before
  the original conditional.  */
-  if (stmt_to_move)
-{
-  if (dump_file && (dump_flags & TDF_DETAILS))
-   {
- fprintf (dump_file, "statement un-sinked:\n");
- print_gimple_stmt (dump_file, stmt_to_move, 0,
-  TDF_VOPS|TDF_MEMSYMS);
-   }
-
-  tree name = gimple_get_lhs (stmt_to_move);
-  // Mark the name to be renamed if there is one.
-  bitmap_set_bit (inserted_exprs, SSA_NAME_VERSION (name));
-  gimple_stmt_iterator gsi1 = gsi_for_stmt (stmt_to_move);
-  gsi_move_before (, );
-  reset_flow_sensitive_info (name);
-}
-
-  if (stmt_to_move_alt)
-{
-  if (dump_file && (dump_flags & TDF_DETAILS))
-   {
- fprintf (dump_file, "statement un-sinked:\n");
- print_gimple_stmt (dump_file, stmt_to_move_alt, 0,
-  TDF_VOPS|TDF_MEMSYMS);
-   }
-
-  tree name = gimple_get_lhs (stmt_to_move_alt);
-  // Mark the name to be renamed if there is one.
-  bitmap_set_bit (inserted_exprs, SSA_NAME_VERSION (name));
-  gimple_stmt_iterator gsi1 = gsi_for_stmt (stmt_to_move_alt);
-  gsi_move_before (, );
-  reset_flow_sensitive_info (name);
-}
+  move_stmt (stmt_to_move, , inserted_exprs);
+  move_stmt (stmt_to_move_alt, , inserted_exprs);
 
   replace_phi_edge_with_variable (cond_bb, e1, phi, result, inserted_exprs);
 
-- 
2.31.1

[PATCH] MATCH: Port CLRSB part of builtin_zero_pattern

[Andrew Pinski via Gcc-patches]

This ports the clrsb builtin part of builtin_zero_pattern
to match.pd. A simple pattern to port.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/ChangeLog:

* match.pd (a != 0 ? CLRSB(a) : CST -> CLRSB(a)): New
pattern.
---
 gcc/match.pd | 8 
 1 file changed, 8 insertions(+)

diff --git a/gcc/match.pd b/gcc/match.pd
index 0e782cde71d..bf918ba70ce 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7787,6 +7787,14 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (cond (ne @0 integer_zerop@1) (func@4 (convert? @2)) integer_zerop@3)
   @4))
 
+/* a != 0 ? FUN(a) : CST -> Fun(a) for some CLRSB builtins
+   where CST is precision-1. */
+(for func (CLRSB)
+ (simplify
+  (cond (ne @0 integer_zerop@1) (func@5 (convert?@4 @2)) INTEGER_CST@3)
+  (if (wi::to_widest (@3) == TYPE_PRECISION (TREE_TYPE (@4)) - 1)
+   @5)))
+
 #if GIMPLE
 /* a != 0 ? CLZ(a) : CST -> .CLZ(a) where CST is the result of the internal 
function for 0. */
 (for func (CLZ)
-- 
2.31.1

PING [C PATCH - backport 12] Fix ICE related to implicit access attributes for VLA arguments [PR105660]

[Martin Uecker via Gcc-patches]

Ok for 12.3 ? 

Am Mittwoch, dem 19.04.2023 um 18:39 +0200 schrieb Martin Uecker:
> Ok to cherrypick for 12?   It is in GCC 13 and fixes an
> annoying ICE.
> 
> Martin
> 
> 
> 
> Here is a fix for PR105660.
> 
> Bootstrapped and regression tested on x86-64.
> 
> 
> Fix ICE related to implicit access attributes for VLA arguments [PR105660]
> 
> 
> When constructing the specifier string when merging an access attribute
> that encodes information about VLA arguments, the string was constructed
> in random order by iterating through a hash table. Fix this by iterating
> though the list of arguments.
> 
> 
> PR c/105660
> 
> 
> gcc/Changelog
> * c-family/c-attribs.cc (append_access_attr): Use order
> of arguments when construction string.
> (append_access_attr_idxs): Rename and make static.
> * c-familty/c-warn.cc (warn_parm_array_mismatch): Add assertion.
> 
> 
> gcc/testsuite/ChangeLog:
> * gcc.dg/pr105660-1.c: New test.
> * gcc.dg/pr105660-2.c: New test.
> 
> 
> diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
> index 4667f6de311..072cfb69147 100644
> --- a/gcc/c-family/c-attribs.cc
> +++ b/gcc/c-family/c-attribs.cc
> @@ -4728,22 +4728,27 @@ append_access_attr (tree node[3], tree attrs, const 
> char *attrstr,
>    rdwr_map cur_idxs;
>    init_attr_rdwr_indices (_idxs, attrs);
>  
> 
> +  tree args = TYPE_ARG_TYPES (node[0]);
> +  int argpos = 0;
>    std::string spec;
> -  for (auto it = new_idxs.begin (); it != new_idxs.end (); ++it)
> +  for (tree arg = args; arg; arg = TREE_CHAIN (arg), argpos++)
>  {
> -  const auto  = *it;
> +  const attr_access* const newa = new_idxs.get (argpos);
> +
> +  if (!newa)
> + continue;
>  
> 
>    /* The map has two equal entries for each pointer argument that
>    has an associated size argument.  Process just the entry for
>    the former.  */
> -  if ((unsigned)newaxsref.first != newaxsref.second.ptrarg)
> +  if ((unsigned)argpos != newa->ptrarg)
>   continue;
>  
> 
> -  const attr_access* const cura = cur_idxs.get (newaxsref.first);
> +  const attr_access* const cura = cur_idxs.get (argpos);
>    if (!cura)
>   {
>     /* The new attribute needs to be added.  */
> -   tree str = newaxsref.second.to_internal_string ();
> +   tree str = newa->to_internal_string ();
>     spec += TREE_STRING_POINTER (str);
>     continue;
>   }
> @@ -4751,7 +4756,6 @@ append_access_attr (tree node[3], tree attrs, const 
> char *attrstr,
>    /* The new access spec refers to an array/pointer argument for
>    which an access spec already exists.  Check and diagnose any
>    conflicts.  If no conflicts are found, merge the two.  */
> -  const attr_access* const newa = 
>  
> 
>    if (!attrstr)
>   {
> @@ -4886,7 +4890,7 @@ append_access_attr (tree node[3], tree attrs, const 
> char *attrstr,
>   continue;
>  
> 
>    /* Merge the CURA and NEWA.  */
> -  attr_access merged = newaxsref.second;
> +  attr_access merged = *newa;
>  
> 
>    /* VLA seen in a declaration takes precedence.  */
>    if (cura->minsize == HOST_WIDE_INT_M1U)
> @@ -4912,9 +4916,9 @@ append_access_attr (tree node[3], tree attrs, const 
> char *attrstr,
>  
> 
>  /* Convenience wrapper for the above.  */
>  
> 
> -tree
> -append_access_attr (tree node[3], tree attrs, const char *attrstr,
> - char code, HOST_WIDE_INT idxs[2])
> +static tree
> +append_access_attr_idxs (tree node[3], tree attrs, const char *attrstr,
> +  char code, HOST_WIDE_INT idxs[2])
>  {
>    char attrspec[80];
>    int n = sprintf (attrspec, "%c%u", code, (unsigned) idxs[0] - 1);
> @@ -5204,7 +5208,7 @@ handle_access_attribute (tree node[3], tree name, tree 
> args, int flags,
>   attributes specified on previous declarations of the same type
>   and if not, concatenate the two.  */
>    const char code = attr_access::mode_chars[mode];
> -  tree new_attrs = append_access_attr (node, attrs, attrstr, code, idxs);
> +  tree new_attrs = append_access_attr_idxs (node, attrs, attrstr, code, 
> idxs);
>    if (!new_attrs)
>  return NULL_TREE;
>  
> 
> @@ -5217,7 +5221,7 @@ handle_access_attribute (tree node[3], tree name, tree 
> args, int flags,
>  {
>    /* Repeat for the previously declared type.  */
>    attrs = TYPE_ATTRIBUTES (TREE_TYPE (node[1]));
> -  new_attrs = append_access_attr (node, attrs, attrstr, code, idxs);
> +  new_attrs = append_access_attr_idxs (node, attrs, attrstr, code, idxs);
>    if (!new_attrs)
>   return NULL_TREE;
>  
> 
> diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
> index 29efce3f2c0..a6fb95b1e80 100644
> --- a/gcc/c-family/c-warn.cc
> +++ b/gcc/c-family/c-warn.cc
> @@ -3617,6 +3617,8 @@ warn_parm_array_mismatch (location_t origloc, tree 
> fndecl, tree newparms)
>    

Re: [PATCH] Turn on LRA on all targets

[Jeff Law via Gcc-patches]

On 4/23/23 10:47, Segher Boessenkool wrote:

This minimal patch enables LRA for all targets.  It does not clean up
the target code, nor does it do anything to generic code: it just
deletes all target definitions of TARGET_LRA_P.

There are three kinds of changes:

1) Targets that already always have LRA, but that redefine the hook
anyway.  These are gcn, pdp11, rx, sparc, vax, and xtensa.  Nothing
really changes for these targets with this patch (but later patches
will delete the superfluous hook implementations).
2) Targets that have LRA selectable.  Some of those are probably fine,
since they default to using LRA (arc, mips, s390).  Two others don't
though, maybe because there are problems (ft32 and sh).  I'd love to
hear from all targets in this category what the status is, how easy it
was to convert, etc.
3) Targets that as of yet never used LRA.  Many of those will be fine,
but some others will need a little tuning, and a few might need some
actual improvements to LRA itself.  These are cris, epiphany, fr30,
frv, h8300, ia64, iq2000, lm32, m32c, m32r, m68k, mcore, microblaze,
mmix, mn10300, msp430, nvptx, pa, rl78, stormy16, and visium.  We'll
find out how many of those targets are ever tested, and how many of
those work with LRA without further changes, and how well.

I send this patch now so that people can start testing.  I don't plan to
commit this for another week at least, for a week after GCC 13 release I
guess?  How does that plan sound to people?

This is an RFC, so no changelog, no one can accidentally commit it :-)
I thought about Cc:ing lots and lots of people, should I do that?ISTM that we ought to go through the non-LRA targets one by one to see 
which can be trivially converted and will still work.  Any that meet 
that criteria should just be converted.


While we may have some performance deltas, I would argue we just move 
forward.  The maintainers can and should be participating in getting us 
moved away from reload.


Of the list you mentioned, I would just remove m32c.  It hasn't been 
able to even build newlib in years and while I did spend some time 
debugging it, my conclusion was it was not salvagable.  It should just 
be deprecated.


For epiphany, it faults semi-randomly in reload last I looked and I 
haven't even tried to have the tester build newlib on that platform in 
eons.  I think epiphany should be deprecated as well.



Jeff

Re: [PATCH 5/5] match.pd: Use splits in makefile and make configurable.

[Jeff Law via Gcc-patches]

On 4/28/23 04:44, Tamar Christina via Gcc-patches wrote:

Hi All,

This updates the build system to split up match.pd files into chunks of 10.
This also introduces a new flag --with-matchpd-partitions which can be used to
change the number of partitions.

For the analysis of why 10 please look at the previous patch in the series.

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

PR bootstrap/84402
* Makefile.in (NUM_MATCH_SPLITS, MATCH_SPLITS_SEQ,
GIMPLE_MATCH_PD_SEQ_SRC, GIMPLE_MATCH_PD_SEQ_O,
GENERIC_MATCH_PD_SEQ_SRC, GENERIC_MATCH_PD_SEQ_O): New.
(OBJS, MOSTLYCLEANFILES, .PRECIOUS): Use them.
(s-match): Split into s-generic-match and s-gimple-match.
* configure.ac (with-matchpd-partitions,
DEFAULT_MATCHPD_PARTITIONS): New.
* configure: Regenerate.
This looks pretty reasonable to me.  Are there any patches left in this 
series that need review?  I'm very much looking forward to build time 
provements related to this patch, particularly for targets that I 
bootstrap with qemu emulation -- we take multiple hours to build 
gimple-match and the ability to parallelize those component builds 
should be a significant win.


jeff

[PATCH (pushed)] hwasan: adjust wording in expected output in tests

[Martin Liška]

gcc/testsuite/ChangeLog:

* c-c++-common/hwasan/asan-pr70541.c: Adjust wording of expected
output.
* c-c++-common/hwasan/heap-overflow.c: Likewise.
* c-c++-common/hwasan/sanity-check-pure-c.c: Likewise.
* c-c++-common/hwasan/use-after-free.c: Likewise.
---
 gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c| 2 +-
 gcc/testsuite/c-c++-common/hwasan/heap-overflow.c   | 4 ++--
 gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c | 4 ++--
 gcc/testsuite/c-c++-common/hwasan/use-after-free.c  | 4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c 
b/gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c
index ba2ed496e6e..be534dfd231 100644
--- a/gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c
+++ b/gcc/testsuite/c-c++-common/hwasan/asan-pr70541.c
@@ -33,4 +33,4 @@ int main() {
 /* { dg-output "HWAddressSanitizer: tag-mismatch on address 0x\[0-9a-f\]*.*" } 
*/
 /* { dg-output "READ of size 4 at 0x\[0-9a-f\]* tags: 
\[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\] \\(ptr/mem\\) 
in thread T0.*" } */
 /* { dg-output "freed by thread T0 here:.*" } */
-/* { dg-output "previously allocated here:" } */
+/* { dg-output "previously allocated by thread T0 here:" } */
diff --git a/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c 
b/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c
index a5a37715925..e424d8bcb12 100644
--- a/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c
+++ b/gcc/testsuite/c-c++-common/hwasan/heap-overflow.c
@@ -24,6 +24,6 @@ int main(int argc, char **argv) {
 
 /* { dg-output "HWAddressSanitizer: tag-mismatch on address 0x\[0-9a-f\]*.*" } 
*/
 /* { dg-output "READ of size 1 at 0x\[0-9a-f\]* tags: 
\[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\].* 
\\(ptr/mem\\) in thread T0.*" } */
-/* { dg-output "located 0 bytes after 10-byte region.*" } */
-/* { dg-output "allocated here:.*" } */
+/* { dg-output "located 0 bytes after a 10-byte region.*" } */
+/* { dg-output "allocated by thread T0 here:.*" } */
 /* { dg-output "#1 0x\[0-9a-f\]+ +in _*main \[^\n\r]*heap-overflow.c:18" } */
diff --git a/gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c 
b/gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c
index a42921bb44c..4e557000458 100644
--- a/gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c
+++ b/gcc/testsuite/c-c++-common/hwasan/sanity-check-pure-c.c
@@ -20,6 +20,6 @@ int main() {
 
 /* { dg-output "HWAddressSanitizer: tag-mismatch on address 0x\[0-9a-f\]*.*" } 
*/
 /* { dg-output "READ of size 1 at 0x\[0-9a-f\]* tags: 
\[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\] \\(ptr/mem\\) 
in thread T0.*" } */
-/* { dg-output "located 5 bytes inside of 10-byte region.*" } */
+/* { dg-output "located 5 bytes inside a 10-byte region.*" } */
 /* { dg-output "freed by thread T0 here:.*" } */
-/* { dg-output "previously allocated here:" } */
+/* { dg-output "previously allocated by thread T0 here:" } */
diff --git a/gcc/testsuite/c-c++-common/hwasan/use-after-free.c 
b/gcc/testsuite/c-c++-common/hwasan/use-after-free.c
index 41a356999aa..b058982935f 100644
--- a/gcc/testsuite/c-c++-common/hwasan/use-after-free.c
+++ b/gcc/testsuite/c-c++-common/hwasan/use-after-free.c
@@ -21,8 +21,8 @@ int main() {
 
 /* { dg-output "HWAddressSanitizer: tag-mismatch on address 0x\[0-9a-f\]*.*" } 
*/
 /* { dg-output "READ of size 1 at 0x\[0-9a-f\]* tags: 
\[\[:xdigit:\]\]\[\[:xdigit:\]\]/\[\[:xdigit:\]\]\[\[:xdigit:\]\] \\(ptr/mem\\) 
in thread T0.*" } */
-/* { dg-output "is located 5 bytes inside of 10-byte region.*" } */
+/* { dg-output "is located 5 bytes inside a 10-byte region.*" } */
 /* { dg-output "freed by thread T0 here:.*" } */
 /* { dg-output "#1\[^\n\r]*main\[^\n\r]*use-after-free.c:17.*" } */
-/* { dg-output "previously allocated here:.*" } */
+/* { dg-output "previously allocated by thread T0 here:.*" } */
 /* { dg-output "#1\[^\n\r]*main\[^\n\r]*use-after-free.c:16" } */
-- 
2.40.1

Re: [PATCH] Canonicalize vec_merge when mask is constant.

[Jeff Law via Gcc-patches]

On 4/19/23 21:58, liuhongt via Gcc-patches wrote:

Use swap_communattive_operands_p for canonicalization. When both value
has same operand precedence value, then first bit in the mask should
select first operand.

The canonicalization should help backends for pattern match. .i.e. x86
backend has lots of vec_merge patterns, combine will create any form
of vec_merge(mask, or inverted mask), then backend need to add 2
patterns to match exact 1 instruction. The canonicalization can
simplify 2 patterns to 1.

Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}, aarch64-linux-gnu.
Ok for trunk?

gcc/ChangeLog:

* combine.cc (maybe_swap_commutative_operands): Canonicalize
vec_merge when mask is constant.
ISTM that if we're going to call this the canonical form, then we should 
document it in rtl.texi.


Otherwise it looks pretty good to me.  So let's get the docs updated and 
get this installed.


jeff

[PATCH (pushed)] libsanitizer: link hwasan against lsan library

[Martin Liška]

Similarly to libasan.so, libhwasan.so also utilizes some
of the symbols from lsan library.

PR sanitizer/109674

libsanitizer/ChangeLog:

* hwasan/Makefile.am: Depend on liblsan.
* hwasan/Makefile.in: Re-generate.
---
 libsanitizer/hwasan/Makefile.am | 2 +-
 libsanitizer/hwasan/Makefile.in | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/libsanitizer/hwasan/Makefile.am b/libsanitizer/hwasan/Makefile.am
index 5a89189f6d8..bb7f8fa0b7b 100644
--- a/libsanitizer/hwasan/Makefile.am
+++ b/libsanitizer/hwasan/Makefile.am
@@ -38,7 +38,7 @@ hwasan_files = \
hwasan_type_test.cpp
 
 libhwasan_la_SOURCES = $(hwasan_files)
-libhwasan_la_LIBADD = $(top_builddir)/sanitizer_common/libsanitizer_common.la
+libhwasan_la_LIBADD = $(top_builddir)/sanitizer_common/libsanitizer_common.la 
$(top_builddir)/lsan/libsanitizer_lsan.la
 if !USING_MAC_INTERPOSE
 libhwasan_la_LIBADD += $(top_builddir)/interception/libinterception.la
 endif
diff --git a/libsanitizer/hwasan/Makefile.in b/libsanitizer/hwasan/Makefile.in
index 4240aa90147..58bc26b44b9 100644
--- a/libsanitizer/hwasan/Makefile.in
+++ b/libsanitizer/hwasan/Makefile.in
@@ -148,7 +148,8 @@ LTLIBRARIES = $(toolexeclib_LTLIBRARIES)
 am__DEPENDENCIES_1 =
 libhwasan_la_DEPENDENCIES =  \
$(top_builddir)/sanitizer_common/libsanitizer_common.la \
-   $(am__append_1) $(am__append_2) $(am__DEPENDENCIES_1)
+   $(top_builddir)/lsan/libsanitizer_lsan.la $(am__append_1) \
+   $(am__append_2) $(am__DEPENDENCIES_1)
 am__objects_1 = hwasan_allocation_functions.lo hwasan_allocator.lo \
hwasan.lo hwasan_dynamic_shadow.lo hwasan_exceptions.lo \
hwasan_fuchsia.lo hwasan_globals.lo hwasan_interceptors.lo \
@@ -444,7 +445,8 @@ hwasan_files = \
 libhwasan_la_SOURCES = $(hwasan_files)
 libhwasan_la_LIBADD =  \
$(top_builddir)/sanitizer_common/libsanitizer_common.la \
-   $(am__append_1) $(am__append_2) $(LIBSTDCXX_RAW_CXX_LDFLAGS)
+   $(top_builddir)/lsan/libsanitizer_lsan.la $(am__append_1) \
+   $(am__append_2) $(LIBSTDCXX_RAW_CXX_LDFLAGS)
 libhwasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` 
$(link_libhwasan)
 
 # Work around what appears to be a GNU make bug handling MAKEFLAGS
-- 
2.40.1

Re: [PATCH 2/2] MATCH: add some of what phiopt's builtin_zero_pattern did

[Jeff Law via Gcc-patches]

On 4/28/23 11:02, Andrew Pinski via Gcc-patches wrote:

This adds the patterns for
POPCOUNT BSWAP FFS PARITY CLZ and CTZ.
For "a != 0 ? FUNC(a) : CST".
CLRSB, CLRSBL, and CLRSBLL will be moved next.

Note this is not enough to remove
cond_removal_in_builtin_zero_pattern as we need to handle
the case where there is an NOP_CONVERT inside the conditional
to move out of the condition inside match_simplify_replacement.

OK? Bootstrapped and tested on x86_64-linux-gnu.

gcc/ChangeLog:

* match.pd: Add patterns for "a != 0 ? FUNC(a) : CST"
for FUNC of POPCOUNT BSWAP FFS PARITY CLZ and CTZ.

OK
jeff

Re: [PATCH 1/2] PHIOPT: Allow moving of some builtin calls

[Jeff Law via Gcc-patches]

On 4/28/23 11:02, Andrew Pinski via Gcc-patches wrote:

While moving working on moving
cond_removal_in_builtin_zero_pattern to match, I noticed
that functions were not allowed to move as we reject all
non-assignments.
This changes to allowing a few calls which are known not
to throw/trap. Right now it is restricted to ones
which cond_removal_in_builtin_zero_pattern handles but
adding more is just adding it to the switch statement.

gcc/ChangeLog:

* tree-ssa-phiopt.cc (empty_bb_or_one_feeding_into_p):
Allow some builtin/internal function calls which
are known not to trap/throw.
(phiopt_worker::match_simplify_replacement):
Use name instead of getting the lhs again.

OK
jeff

Re: [PATCH V5] Use reg mode to move sub blocks for parameters and returns

[Jeff Law via Gcc-patches]

On 3/16/23 21:39, Jiufu Guo wrote:

Hi,

When assigning a parameter to a variable, or assigning a variable to
return value with struct type, and the parameter/return is passed
through registers.
For this kind of case, it would be better to use the nature mode of
the registers to move the content for the assignment.

As the example code (like code in PR65421):

typedef struct SA {double a[3];} A;
A ret_arg_pt (A *a) {return *a;} // on ppc64le, expect only 3 lfd(s)
A ret_arg (A a) {return a;} // just empty fun body
void st_arg (A a, A *p) {*p = a;} //only 3 stfd(s)

Comparing with previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609394.html
This version refine code to eliminated reductant code in  the sub
routine "move_sub_blocks".

Bootstrap and regtest pass on ppc64{,le}.
Is this ok for trunk?

BR,
Jeff (Jiufu)

PR target/65421

gcc/ChangeLog:

* cfgexpand.cc (expand_used_vars): Update to mark DECL_USEDBY_RETURN_P
for returns.
* expr.cc (move_sub_blocks): New function.
(expand_assignment): Update assignment code about returns/parameters.
* function.cc (assign_parm_setup_block): Update to mark
DECL_REGS_TO_STACK_P for parameter.
* tree-core.h (struct tree_decl_common): Add comment.
* tree.h (DECL_USEDBY_RETURN_P): New define.
(DECL_REGS_TO_STACK_P): New define.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr65421-1.c: New test.
* gcc.target/powerpc/pr65421.c: New test.

---
  gcc/cfgexpand.cc | 14 +
  gcc/expr.cc  | 61 
  gcc/function.cc  |  3 +
  gcc/tree-core.h  |  4 +-
  gcc/tree.h   |  9 +++
  gcc/testsuite/gcc.target/powerpc/pr65421-1.c |  6 ++
  gcc/testsuite/gcc.target/powerpc/pr65421.c   | 33 +++
  7 files changed, 129 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr65421-1.c
  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr65421.c

diff --git a/gcc/expr.cc b/gcc/expr.cc
index 15be1c8db99..97a7be9542e 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -5559,6 +5559,41 @@ mem_ref_refers_to_non_mem_p (tree ref)
return non_mem_decl_p (base);
  }
  
+/* Sub routine of expand_assignment, invoked when assigning from a

+   parameter or assigning to a return val on struct type which may
+   be passed through registers.  The mode of register is used to
+   move the content for the assignment.
+
+   This routine generates code for expression FROM which is BLKmode,
+   and move the generated content to TO_RTX by su-blocks in SUB_MODE.  */
+
+static void
+move_sub_blocks (rtx to_rtx, tree from, machine_mode sub_mode)
+{
+  gcc_assert (MEM_P (to_rtx));
+
+  HOST_WIDE_INT size = MEM_SIZE (to_rtx).to_constant ();
Consider the case of a BLKmode return value.  Isn't TO_RTX in this case 
a BLKmode object?


It looks pretty good at this point.

jeff

Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__

[Jeff Law via Gcc-patches]

On 1/12/23 09:02, Longjun Luo via Gcc-patches wrote:

 From 0821df518b264e754d698d399f98be1a62945e32 Mon Sep 17 00:00:00 2001
From: Longjun Luo 
Date: Thu, 12 Jan 2023 23:59:54 +0800
Subject: [PATCH] libcpp: suppress builtin macro redefined warnings for
  __LINE__

As implied in
gcc.gnu.org/legacy-ml/gcc-patches/2008-09/msg00076.html,
gcc provides -Wno-builtin-macro-redefined to suppress warning when
redefining builtin macro. However, at that time, there was no
scenario for __LINE__ macro.

But, when we try to build a live-patch, we compare sections by using
-ffunction-sections. Some same functions are considered changed because
of __LINE__ macro.

At present, to detect such a changed caused by __LINE__ macro, we
have to analyse code and maintain a function list. For example,
in kpatch, check this commit
github.com/dynup/kpatch/commit/0e1b95edeafa36edb7bcf11da6d1c00f76d7e03d.

So, in this scenario, when we try to compared sections, it would
be better to support suppress builtin macro redefined warnings for
__LINE__ macro.

Signed-off-by: Longjun Luo 
---
  gcc/testsuite/gcc.dg/builtin-redefine-1.c | 49 +++
  gcc/testsuite/gcc.dg/builtin-redefine.c   | 24 +--
  libcpp/init.cc    |  2 +-
  3 files changed, 70 insertions(+), 5 deletions(-)
  create mode 100755 gcc/testsuite/gcc.dg/builtin-redefine-1.c

Thanks.  I added a suitable ChangeLog and pushed this to the trunk.

jeff

Re: [PATCH v5 06/11] RISC-V: Strengthen atomic stores

[Jeff Law via Gcc-patches]

On 4/28/23 15:42, Hans Boehm wrote:
The concern with making the new behavior non-default is of course that 
the generated code will eventually end up on an A.7-capable platform.
Yea, certainly a significant concern in general, though probably not for 
Ventana.  I expect we'll have folks rebuilding as they go from V1 to V2 
due to the ventanacondops -> condops change.





An A.6-classic option for compiling code that will never run on a newer 
machine seems OK. But I'm not sure that seq_cst stores are dynamically 
frequent enough in C++ code for this to be worth the trouble. 
Unlike loads, they are also costly on x86, programmers may also have 
been somewhat trained to avoid them where possible. (And probably where 
not possible, too :-( )
I was more worried about the kernel, perhaps because I'm less familiar 
with it these days than ever.  WRT C++, I can ping Jon@RedHat, he's got 
a great sense what's in the standard library obviously, but also a 
reasonable sense of what folks are doing in the wild.


Jeff

Re: [PATCH v5 00/11] RISC-V: Implement ISA Manual Table A.6 Mappings

[Jeff Law via Gcc-patches]

On 4/28/23 12:45, Hans Boehm wrote:
We're certainly pushing for the same ABI (A.6 + trailing fence on store) 
in LLVM as well. I'm about to upload a pull request for the psABI 
document that describes this version of the ABI, and a bit of the 
rationale for it. I'll attach the current draft here.


I agree that compatibility is critical here, not just across llvm and 
gcc, but also with other language implementations. That's part of the 
reason to get this correct asap.


I believe that standardizing on A.6 + trailing fence on store, though 
initially suboptimal, is by far the best bet to get us to an efficient 
ABI in the long term. I expect the A.7 ABI to perform well. A.6, even 
without the trailing store fence, has annoyingly expensive seq_cst 
loads, which I would really like to get away from.
Thanks for the additional info.  This stuff is well outside my area of 
expertise, so having someone with your background to give key insights 
is definitely appreciated.


jeff

Re: [PATCH v2] gcc: Use ld -r when checking for HAVE_LD_RO_RW_SECTION_MIXING

[Jeff Law via Gcc-patches]

On 12/5/22 06:43, Joakim Nohlgård wrote:

Fall back to ld -r if ld -shared fails during configure. The check for
HAVE_LD_RO_RW_SECTION_MIXING can fail on targets where ld does not
support shared objects, even though the answer to the test should be
'read-write'. One such target is riscv64-unknown-elf. Failing this test
results in a libgcc crtbegin.o which has a writable .eh_frame section
leading to the default linker scripts placing the .eh_frame section in a
writable memory segment, or a linker warning when using ld scripts that
place .eh_frame unconditionally in ROM.

gcc/ChangeLog:

* configure: Regenerate.
* configure.ac: Use ld -r in the check for HAVE_LD_RO_RW_SECTION_MIXING

Thanks.  I've pushed this to the trunk.
jeff

Re: [PATCH 2/2] Improve error message for excess elements in array initializer from {"a"}

[Jeff Law via Gcc-patches]

On 11/30/22 10:18, apinski--- via Gcc-patches wrote:

From: Andrew Pinski 

So char arrays are not the only type that be initialized from {"a"}.
We can have wchar_t (L"") and char16_t (u"") types too. So let's
print out the type of the array instead of just saying char.

Note in the testsuite I used regex . to match '[' and ']' as
I could not figure out how many '\' I needed.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

gcc/c/ChangeLog:

* c-typeck.cc (process_init_element): Print out array type
for excessive elements.

gcc/testsuite/ChangeLog:

* gcc.dg/init-bad-1.c: Update error message.
* gcc.dg/init-bad-2.c: Likewise.
* gcc.dg/init-bad-3.c: Likewise.
* gcc.dg/init-excess-3.c: Likewise.
* gcc.dg/pr61096-1.c: Likewise.

OK
jeff

Re: [PATCH 1/2] Fix C/107926: Wrong error message when initializing char array

[Jeff Law via Gcc-patches]

On 11/30/22 10:18, apinski--- via Gcc-patches wrote:

From: Andrew Pinski 

The problem here is the code which handles {"a"} is supposed
to handle the case where the is something after the string but
it only handles the case where there is another string so
we go down the other path and error out saying "excess elements
in struct initializer" even though this was a character array.
To fix this, we need to move the ckeck if the initializer is
a string after the check for array and initializer.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

Thanks,
Adnrew Pinski

gcc/c/ChangeLog:

PR c/107926
* c-typeck.cc (process_init_element):
Move the ceck for string cst until
after the error message.

gcc/testsuite/ChangeLog:

PR c/107926
* gcc.dg/init-excess-3.c: New test.

OK
jeff

Re: libsanitizer: sync from master

[Andrew Pinski via Gcc-patches]

On Tue, Nov 15, 2022 at 7:47 AM Martin Liška  wrote:
>
> Hi.
>
> I've just pushed libsanitizer update that was tested on x86_64-linux and 
> ppc64le-linux systems.
> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
> abidiff.

This broke hwasan on aarch64. See https://gcc.gnu.org/PR109674 .

Thanks,
Andrew

>
> Pushed as r13-4068-g3037f11fb86eda.
>
> Cheers,
> Martin

RE: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to VMSET

[Li, Pan2 via Gcc-patches]

Thanks all for comments. Summary what I have learned from the mail thread as 
below. Please feel free to correct me if any mistake.

1. The RVV VMSET has tail policy and the high bits of target register can be 
overridden to 1 or retain the value they held according to the ISA.
2. The semantics of tail policy is different with s390 according the macro 
comment " /* The truth element value for vector comparisons.  Our instructions 
always generate -1 in that case.  */ ".
3. We still have a lot of work to do for the RISC-V besides compiler.
4. The RTL pattern of PATCH v1 models tail policy and vector length as well.

Pan

-Original Message-
From: Kito Cheng  
Sent: Sunday, April 30, 2023 9:40 AM
To: Jeff Law 
Cc: Li, Pan2 ; gcc-patches@gcc.gnu.org; 
juzhe.zh...@rivai.ai; Wang, Yanzhang ; Andrew Waterman 

Subject: Re: [PATCH] RISC-V: Allow RVV VMS{Compare}(V1, V1) simplify to VMSET

Hi Jeff:

The RTL pattern already models tail element and vector length well, so I don't 
feel the first version of Pan's patch has any problem?

Input RTL pattern:

#(insn 10 7 12 2 (set (reg:VNx2BI 134 [ _1 ])
#(if_then_else:VNx2BI (unspec:VNx2BI [
#(const_vector:VNx2BI repeat [
#(const_int 1 [0x1])
#])  # all-1 mask
#(reg:DI 143)  # AVL reg, or vector length
#(const_int 2 [0x2]) # mask policy
#(const_int 0 [0])   # avl type
#(reg:SI 66 vl)
#(reg:SI 67 vtype)
#] UNSPEC_VPREDICATE)
#(geu:VNx2BI (reg/v:VNx2QI 137 [ v1 ])
#(reg/v:VNx2QI 137 [ v1 ]))
#(unspec:VNx2BI [
#(reg:SI 0 zero)
#] UNSPEC_VUNDEF))) # maskoff and tail operand
# (expr_list:REG_DEAD (reg:DI 143)
#(expr_list:REG_DEAD (reg/v:VNx2QI 137 [ v1 ])
#(nil

And the split pattern, only did on tail/maskoff element with undefined value:

(define_split
 [(set (match_operand:VB  0 "register_operand")
   (if_then_else:VB
 (unspec:VB
   [(match_operand:VB 1 "vector_all_trues_mask_operand")
(match_operand4 "vector_length_operand")
(match_operand5 "const_int_operand")
(match_operand6 "const_int_operand")
(reg:SI VL_REGNUM)
(reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
 (match_operand:VB3 "vector_move_operand")
 (match_operand:VB2 "vector_undef_operand")))] # maskoff
and tail operand, only match undef value

Then it turns into vmset, and also discard mask policy operand (since maskoff 
is undef means don't care IMO):

(insn 10 7 12 2 (set (reg:VNx2BI 134 [ _1 ])
   (if_then_else:VNx2BI (unspec:VNx2BI [
   (const_vector:VNx2BI repeat [
   (const_int 1 [0x1])
   ])  # all-1 mask
   (reg:DI 143) # AVL reg, or vector length
   (const_int 2 [0x2]) # mask policy
   (reg:SI 66 vl)
   (reg:SI 67 vtype)
   ] UNSPEC_VPREDICATE)
   (const_vector:VNx2BI repeat [
   (const_int 1 [0x1])
   ])# all-1
   (unspec:VNx2BI [
   (reg:SI 0 zero)
   ] UNSPEC_VUNDEF))) # still vundef
(expr_list:REG_DEAD (reg:DI 143)
   (nil)))



On Sat, Apr 29, 2023 at 11:05 PM Jeff Law  wrote:
>
>
>
> On 4/28/23 20:55, Li, Pan2 wrote:
> > Thanks Jeff for comments.
> >
> > It makes sense to me. For the EQ operator we should have CONSTM1.
> That's not the way I interpret the RVV documentation.  Of course it's
> not terribly clear.I guess one could do some experiments with qemu
> or try to dig into the sail code and figure out the intent from those.
>
>
>
> Does this mean s390 parts has similar issue here? Then for 
> instructions like VMSEQ, we need to adjust the simplify_rtx up to a point.
> You'd have to refer to the s390 instruction set reference to 
> understand precisely how the vector compares work.
>
> But as it stands this really isn't a simplify-rtx question, but a
> question of the semantics of risc-v.   What happens with the high bits
> in the destination mask register is critical -- and if risc-v doesn't 
> set them to all ones in this case, then that would mean that defining 
> that macro is simply wrong for risc-v.
>
> jeff

Re: libsanitizer: sync from master

[Martin Liška]

On 4/28/23 11:23, Florian Weimer wrote:
> * Martin Liška:
> 
>> On 4/26/23 20:31, Florian Weimer wrote:
>>> * Martin Liška:
>>>
 On 11/15/22 16:47, Martin Liška wrote:
> Hi.
>
> I've just pushed libsanitizer update that was tested on x86_64-linux and 
> ppc64le-linux systems.
> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
> abidiff.

 Hello.

 And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>>>
>>> So … we have the issue that involves interceptors outside of libc.so.6,
>>> namely crypt, crypt_r, and I posted an upstream patch for this:
>>>
>>>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>>>   
>>>
>>> Can we just apply this downstream for now?  It blocks various folks from
>>> using the sanitizers in their projects.
>>
>> Hello.
>>
>> Your upstream revision has been already accepted, so please apply it
>> and I'm going to do one more merge from upstream in the following
>> days. Does it work for you?
> 
> It's moving in a different direction now: 
> 
> But that's okay for me as well.
> 
> Thanks,
> Florian
> 

Hello.

I've just pushed merged libsanitizer that contains both crypt-related changes
and x32 fix from H.J.

Cheers,
Martin