[PATCH] xtensa: Enforce return address saving when -Og is specified

[Takayuki 'January June' Suwa via Gcc-patches]

Leaf function often omits saving its return address to the stack slot,
and this feature often makes debugging very confusing, especially for
stack dump analysis.

gcc/ChangeLog:

* config/xtensa/xtensa.cc (xtensa_call_save_reg): Change to return
true if register A0 (return address register) when -Og is specified.
---
 gcc/config/xtensa/xtensa.cc | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index d987f1dfede..1d9e4d1561a 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -3224,8 +3224,11 @@ xtensa_call_save_reg (int regno)
 return false;
 
   if (regno == A0_REG)
-return crtl->profile || !crtl->is_leaf || crtl->calls_eh_return ||
-  df_regs_ever_live_p (regno);
+/* Ensure the return address to be saved to the stack slot in order
+   to assist stack dump analysis when -Og is specified.  */
+return optimize_debug
+  || crtl->profile || !crtl->is_leaf || crtl->calls_eh_return
+  || df_regs_ever_live_p (regno);
 
   if (crtl->calls_eh_return && IN_RANGE (regno, 2, 3))
 return true;
-- 
2.30.2

[PATCH v5] xtensa: Eliminate unnecessary general-purpose reg-reg moves

[Takayuki 'January June' Suwa via Gcc-patches]

Register-register move instructions that can be easily seen as
unnecessary by the human eye may remain in the compiled result.
For example:

/* example */
double test(double a, double b) {
  return __builtin_copysign(a, b);
}

test:
add.n   a3, a3, a3
extui   a5, a5, 31, 1
ssai1
;; Be in the same BB
src a7, a5, a3  ;; Replacing the destination doesn't
;;   violate any constraints of the
;;   operands
;; No CALL insns in this span
;; Both A3 and A7 are irrelevant to
;;   insns in this span
mov.n   a3, a7  ;; An unnecessary reg-reg move
;; A7 is not used after this
ret.n

The last two instructions above, excluding the return instruction,
could be done like this:

src a3, a5, a3

This symptom often occurs when handling DI/DFmode values with SImode
instructions.  This patch solves the above problem using peephole2
pattern.

gcc/ChangeLog:

* config/xtensa/xtensa.md: New peephole2 pattern that eliminates
the occurrence of general-purpose register used only once and for
transferring intermediate value.

gcc/testsuite/ChangeLog:

* gcc.target/xtensa/elim_GP_regmove_[01].c: New.
---
 gcc/config/xtensa/xtensa.md   | 46 +++
 .../gcc.target/xtensa/elim_GP_regmove_0.c | 23 ++
 .../gcc.target/xtensa/elim_GP_regmove_1.c | 10 
 3 files changed, 79 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/xtensa/elim_GP_regmove_0.c
 create mode 100644 gcc/testsuite/gcc.target/xtensa/elim_GP_regmove_1.c

diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index d3996b26cb5..4c1305c05e7 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -3050,3 +3050,49 @@ FALLTHRU:;
   operands[1] = GEN_INT (imm0);
   operands[2] = GEN_INT (imm1);
 })
+
+(define_peephole2
+  [(set (match_operand 0 "register_operand")
+   (match_operand 1 "register_operand"))]
+  "REG_NREGS (operands[0]) == 1 && GP_REG_P (REGNO (operands[0]))
+   && REG_NREGS (operands[1]) == 1 && GP_REG_P (REGNO (operands[1]))
+   && peep2_reg_dead_p (1, operands[1])"
+  [(const_int 0)]
+{
+  basic_block bb = BLOCK_FOR_INSN (curr_insn);
+  rtx_insn *head = BB_HEAD (bb), *insn;
+  rtx dest = operands[0], src = operands[1], pattern, t_dest, dest_orig;
+  for (insn = PREV_INSN (curr_insn);
+   insn && insn != head;
+   insn = PREV_INSN (insn))
+if (CALL_P (insn))
+  break;
+else if (INSN_P (insn))
+  {
+   if (GET_CODE (pattern = PATTERN (insn)) == SET
+   && REG_P (t_dest = SET_DEST (pattern))
+   && REG_NREGS (t_dest) == 1
+   && REGNO (t_dest) == REGNO (src))
+   {
+ dest_orig = SET_DEST (pattern);
+ SET_DEST (pattern) = gen_rtx_REG (GET_MODE (t_dest),
+   REGNO (dest));
+ extract_insn (insn);
+ if (!constrain_operands (true, get_enabled_alternatives (insn)))
+   {
+ SET_DEST (pattern) = dest_orig;
+ goto ABORT;
+   }
+ df_insn_rescan (insn);
+ goto FALLTHRU;
+   }
+   if (reg_overlap_mentioned_p (dest, pattern)
+   || reg_overlap_mentioned_p (src, pattern)
+   || set_of (dest, insn)
+   || set_of (src, insn))
+ break;
+  }
+ABORT:
+  FAIL;
+FALLTHRU:;
+})
diff --git a/gcc/testsuite/gcc.target/xtensa/elim_GP_regmove_0.c 
b/gcc/testsuite/gcc.target/xtensa/elim_GP_regmove_0.c
new file mode 100644
index 000..5c195c357dc
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/elim_GP_regmove_0.c
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fpeephole2" } */
+
+/* can be processed */
+double test0(double a, double b) {
+  return __builtin_copysign(a, b);
+}
+
+/* cannot be processed: due to violate '0' constraint of the 2nd source 
operand.  */
+int test1(int a, int b) {
+  int c;
+  asm volatile ("" : "=a"(c) : "r"(a), "0"(b));
+  return c;
+}
+
+/* cannot be processed: due to violate '&' constraint of the destination 
operand.  */
+int test2(int a) {
+  int b;
+  asm volatile ("" : "="(b) : "r"(a));
+  return b;
+}
+
+/* { dg-final { scan-assembler-times "mov\t|mov.n\t" 2 } } */
diff --git a/gcc/testsuite/gcc.target/xtensa/elim_GP_regmove_1.c 
b/gcc/testsuite/gcc.target/xtensa/elim_GP_regmove_1.c
new file mode 100644
index 000..a13ef818827
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/elim_GP_regmove_1.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fpeephole2 -mabi=windowed" } */
+
+/* cannot be processed: due to violate 'a' constraint of the destination 
operand of the stack adjustment instruction.  */
+void test(void) {
+  int buffer[8192];
+  asm volatile ("" : 

'#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc' (was: [gcc r13-5533] gccrs: const folding port)

[Thomas Schwinge]

Hi!

On 2023-01-31T13:14:10+, Arthur Cohen via Gcc-cvs  
wrote:
> commit r13-5533-ge66fec8e6ba35edf01f86c2bf6514109aba4ded2
> Author: Faisal Abbas <90.abbasfai...@gmail.com>
> Date:   Mon Jun 27 16:05:49 2022 +0100
>
> gccrs: const folding port

> --- a/gcc/rust/backend/rust-tree.cc
> +++ b/gcc/rust/backend/rust-tree.cc
> @@ -21,12 +21,37 @@
>  #include "stringpool.h"
>  #include "attribs.h"
>  #include "escaped_string.h"
> +#include "libiberty.h"
> +#include "stor-layout.h"
> +#include "hash-map.h"
> +#include "diagnostic.h"
> +#include "timevar.h"
> +#include "convert.h"
> +#include "gimple-expr.h"
> +#include "gimplify.h"
> +#include "function.h"
> +#include "gcc-rich-location.h"
> +#include "target.h"
> +#include "file-prefix-map.h"
> +#include "cgraph.h"
> +
> +#include "output.h"

GCC's '#include' is a m...ystery -- I've pushed to master branch
commit 27a89f84c458ae938bc3eb92ad0d594c06fc3b42
"'#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc'", see attached.


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 27a89f84c458ae938bc3eb92ad0d594c06fc3b42 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 17 Feb 2023 23:36:20 +0100
Subject: [PATCH] '#include "tm_p.h"' in 'gcc/rust/backend/rust-tree.cc'
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

... to resolve issues like:

 "Upstream GCC broken for --target=pdp11-aout":

In file included from ./tm.h:18:0,
 from [...]/gcc/target.h:52,
 from [...]/gcc/rust/backend/rust-tree.cc:34:
[...]/gcc/rust/backend/rust-tree.cc: In function ‘void Rust::mark_exp_read(tree)’:
[...]/gcc/config/pdp11/pdp11.h:572:48: error: ‘pdp11_gen_int_label’ was not declared in this scope
   pdp11_gen_int_label ((LABEL), (PREFIX), (NUM))
^
[...]/gcc/rust/backend/rust-tree.cc:53:3: note: in expansion of macro ‘ASM_GENERATE_INTERNAL_LABEL’
   ASM_GENERATE_INTERNAL_LABEL (tmp_name, "Lsrc_loc", 1);
   ^
[...]/gcc/rust/backend/rust-tree.cc: In function ‘tree_node* Rust::fold_builtin_source_location(location_t)’:
[...]/gcc/config/pdp11/pdp11.h:572:48: error: ‘pdp11_gen_int_label’ was not declared in this scope
   pdp11_gen_int_label ((LABEL), (PREFIX), (NUM))
^
[...]/gcc/rust/backend/rust-tree.cc:4799:7: note: in expansion of macro ‘ASM_GENERATE_INTERNAL_LABEL’
   ASM_GENERATE_INTERNAL_LABEL (tmp_name, "Lsrc_loc", source_location_id++);
   ^
make[1]: *** [rust/rust-tree.o] Error 1

 "New build failure on upstream GCC for --target=powerpc-ibm-aix7.{1,2}":

In file included from ./tm.h:22:0,
 from [...]/gcc/target.h:52,
 from [...]/gcc/rust/backend/rust-tree.cc:34:
[...]/gcc/rust/backend/rust-tree.cc: In function ‘void Rust::mark_exp_read(tree)’:
[...]/gcc/config/rs6000/xcoff.h:206:63: error: ‘rs6000_xcoff_strip_dollar’ was not declared in this scope
   sprintf (LABEL, "*%s..%u", rs6000_xcoff_strip_dollar (PREFIX), (unsigned) (NUM))
   ^
[...]/gcc/rust/backend/rust-tree.cc:53:3: note: in expansion of macro ‘ASM_GENERATE_INTERNAL_LABEL’
   ASM_GENERATE_INTERNAL_LABEL (tmp_name, "Lsrc_loc", 1);
   ^
[...]/gcc/rust/backend/rust-tree.cc: In function ‘tree_node* Rust::fold_builtin_source_location(location_t)’:
[...]/gcc/config/rs6000/xcoff.h:206:63: error: ‘rs6000_xcoff_strip_dollar’ was not declared in this scope
   sprintf (LABEL, "*%s..%u", rs6000_xcoff_strip_dollar (PREFIX), (unsigned) (NUM))
   ^
[...]/gcc/rust/backend/rust-tree.cc:4799:7: note: in expansion of macro ‘ASM_GENERATE_INTERNAL_LABEL’
   ASM_GENERATE_INTERNAL_LABEL (tmp_name, "Lsrc_loc", source_location_id++);
   ^
make[1]: *** [rust/rust-tree.o] Error 1

Fix-up for recent commit e66fec8e6ba35edf01f86c2bf6514109aba4ded2
"gccrs: const folding port".

	gcc/rust/
	* backend/rust-tree.cc: '#include "tm_p.h"'.
---
 gcc/rust/backend/rust-tree.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/rust/backend/rust-tree.cc b/gcc/rust/backend/rust-tree.cc
index 47506d6792a..e2595b59aa8 100644
--- a/gcc/rust/backend/rust-tree.cc
+++ b/gcc/rust/backend/rust-tree.cc
@@ -34,8 +34,8 @@
 #include "target.h"
 #include "file-prefix-map.h"
 #include "cgraph.h"
-
 #include "output.h"
+#include "tm_p.h"
 
 // forked from gcc/c-family/c-common.cc c_global_trees
 tree c_global_trees[CTI_MAX];
-- 
2.25.1

[PATCH resend] Make -Wuse-after-free=3 the default one in -Wall

[Alejandro Colomar via Gcc-patches]

Link: 

Link: 
Cc: Andreas Schwab 
Cc: David Malcolm 
Cc: Florian Weimer 
Cc: Iker Pedrosa 
Cc: Jens Gustedt 
Cc: Jonathan Wakely 
Cc: Mark Wielaard 
Cc: Martin Uecker 
Cc: Michael Kerrisk 
Cc: Paul Eggert 
Cc: Sam James 
Cc: Siddhesh Poyarekar 
Cc: Yann Droneaud 
Signed-off-by: Alejandro Colomar 
---

This is a resend of the same patch previously sent to gcc@.

 gcc/c-family/c.opt  | 4 ++--
 gcc/doc/invoke.texi | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index c0fea56a8f5..1a3fc2c5d74 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1411,11 +1411,11 @@ C ObjC C++ ObjC++ Joined RejectNegative UInteger 
Var(warn_unused_const_variable)
 Warn when a const variable is unused.
 
 ; Defining this option here in addition to common.opt is necessary
-; in order for the default -Wall setting of -Wuse-after-free=2 to take
+; in order for the default -Wall setting of -Wuse-after-free=3 to take
 ; effect.
 
 Wuse-after-free=
-LangEnabledBy(C ObjC C++ LTO ObjC++, Wall,2,0)
+LangEnabledBy(C ObjC C++ LTO ObjC++, Wall,3,0)
 ; in common.opt
 
 Wvariadic-macros
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7b308cd3c31..d910052ce0c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4720,7 +4720,7 @@ instead of pointers.  This approach obviates needing to 
adjust the stored
 pointers after reallocation.
 @end table
 
-@option{-Wuse-after-free=2} is included in @option{-Wall}.
+@option{-Wuse-after-free=3} is included in @option{-Wall}.
 
 @item -Wuseless-cast @r{(C++ and Objective-C++ only)}
 @opindex Wuseless-cast
-- 
2.39.1

Re: [PATCH RFC] c++: static_assert (false) in template [DR2518]

[Marek Polacek via Gcc-patches]

On Fri, Feb 17, 2023 at 03:32:09PM -0500, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu.  This isn't really a regression fix, but it's very
> safe, and fixes a longstanding annoyance, so I'm leaning toward putting it 
> into
> GCC 13.  Thoughts?

LGTM.
 
> -- 8< --
> 
> For a long time, people have expected to be able to write
> static_assert (false) in a template and only have it diagnosed if the
> template is instantiated, but we (and other implementations) gave an error
> about the uninstantiated template because the standard says that if no valid
> instantiation of the template is possible, the program is ill-formed, no
> diagnostic required, and we try to diagnose IFNDR things when feasible.
> 
> At the meeting last week we were looking at CWG2518, which wanted to specify
> that an implementation must not accept a program containing a failing #error
> or static_assert.  We also looked at P2593, which proposed allowing
> static_assert in an uninstantiated template.  We ended up combining these
> two in order to avoid requiring implementations to reject programs with
> static_assert (false) in uninstantiated templates.
> 
> The committee accepted this as a DR, so I'm making the change to all
> standard modes.  This behavior was also conformant previously, since no
> diagnostic was required in this case.
> 
> We continue to diagnose non-constant or otherwise ill-formed conditions, so
> no changes to existing tests were needed.
> 
>   DR 2518
>   PR c++/52809
>   PR c++/53638
>   PR c++/87389
>   PR c++/89741
>   PR c++/92099
>   PR c++/104041
>   PR c++/104691
> 
> gcc/cp/ChangeLog:
> 
>   * semantics.cc (finish_static_assert): Don't diagnose in
>   template context.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/DRs/dr2518.C: New test.
> ---
>  gcc/cp/semantics.cc   | 17 ++---
>  gcc/testsuite/g++.dg/DRs/dr2518.C |  7 +++
>  2 files changed, 17 insertions(+), 7 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/DRs/dr2518.C
> 
> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> index c2df0b69b30..79b7cc72f21 100644
> --- a/gcc/cp/semantics.cc
> +++ b/gcc/cp/semantics.cc
> @@ -11232,14 +11232,16 @@ finish_static_assert (tree condition, tree message, 
> location_t location,
>if (check_for_bare_parameter_packs (condition))
>  condition = error_mark_node;
>  
> +  /* Save the condition in case it was a concept check.  */
> +  tree orig_condition = condition;
> +
>if (instantiation_dependent_expression_p (condition))
>  {
>/* We're in a template; build a STATIC_ASSERT and put it in
>   the right place. */
> -  tree assertion;
> -
> -  assertion = make_node (STATIC_ASSERT);
> -  STATIC_ASSERT_CONDITION (assertion) = condition;
> +defer:
> +  tree assertion = make_node (STATIC_ASSERT);
> +  STATIC_ASSERT_CONDITION (assertion) = orig_condition;
>STATIC_ASSERT_MESSAGE (assertion) = message;
>STATIC_ASSERT_SOURCE_LOCATION (assertion) = location;
>  
> @@ -11253,9 +11255,6 @@ finish_static_assert (tree condition, tree message, 
> location_t location,
>return;
>  }
>  
> -  /* Save the condition in case it was a concept check.  */
> -  tree orig_condition = condition;
> -
>/* Fold the expression and convert it to a boolean value. */
>condition = contextual_conv_bool (condition, complain);
>condition = fold_non_dependent_expr (condition, complain,
> @@ -11270,6 +11269,10 @@ finish_static_assert (tree condition, tree message, 
> location_t location,
>  
>if (integer_zerop (condition))
>   {
> +   /* CWG2518: static_assert failure in a template is not IFNDR.  */
> +   if (processing_template_decl)
> + goto defer;
> +
> int sz = TREE_INT_CST_LOW (TYPE_SIZE_UNIT
>(TREE_TYPE (TREE_TYPE (message;
> int len = TREE_STRING_LENGTH (message) / sz - 1;
> diff --git a/gcc/testsuite/g++.dg/DRs/dr2518.C 
> b/gcc/testsuite/g++.dg/DRs/dr2518.C
> new file mode 100644
> index 000..240186211e6
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/DRs/dr2518.C
> @@ -0,0 +1,7 @@
> +// CWG 2518
> +// { dg-do compile { target c++11 } }
> +
> +template  void f()
> +{
> +  static_assert (false, "");
> +}
> 
> base-commit: 07f497c2da3600cc99cd7d1b5c6726972fb2b5a1
> -- 
> 2.31.1
> 

Marek

[PATCH v3] c++: ICE with redundant capture [PR108829]

[Marek Polacek via Gcc-patches]

On Fri, Feb 17, 2023 at 04:32:50PM -0500, Patrick Palka wrote:
> On Fri, 17 Feb 2023, Patrick Palka wrote:
> 
> > On Fri, 17 Feb 2023, Marek Polacek wrote:
> > 
> > > On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
> > > > On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> > > > 
> > > > > Here we crash in is_capture_proxy:
> > > > > 
> > > > >   /* Location wrappers should be stripped or otherwise handled by the
> > > > >  caller before using this predicate.  */
> > > > >   gcc_checking_assert (!location_wrapper_p (decl));
> > > > > 
> > > > > so fixed as the comment suggests.  We only crash with the redundant
> > > > > capture:
> > > > > 
> > > > >   int abyPage = [=, abyPage] { ... }
> > > > > 
> > > > > because prune_lambda_captures is only called when there was a default
> > > > > capture, and with [=] only abyPage won't be in 
> > > > > LAMBDA_EXPR_CAPTURE_LIST.
> > > > 
> > > > It's weird that we even get this far in var_to_maybe_prune.  Shouldn't
> > > > LAMBDA_CAPTURE_EXPLICIT_P be true for abyPage?
> > > 
> > > Ug, I was seduced by the ostensible obviousness and failed to notice
> > > that check.  In that light, the correct fix ought to be this.  Thanks!
> > > 
> > > Bootstrap/regtest running on x86_64-pc-linux-gnu, ok for trunk if it
> > > passes?
> > > 
> > > -- >8 --
> > > Here we crash in is_capture_proxy:
> > > 
> > >   /* Location wrappers should be stripped or otherwise handled by the
> > >  caller before using this predicate.  */
> > >   gcc_checking_assert (!location_wrapper_p (decl));
> > > 
> > > We only crash with the redundant capture:
> > > 
> > >   int abyPage = [=, abyPage] { ... }
> > > 
> > > because prune_lambda_captures is only called when there was a default
> > > capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.
> > > 
> > > The problem is that LAMBDA_CAPTURE_EXPLICIT_P wasn't propagated
> > > correctly and so var_to_maybe_prune proceeded where it shouldn't.
> > > 
> > >   PR c++/108829
> > > 
> > > gcc/cp/ChangeLog:
> > > 
> > >   * pt.cc (tsubst_lambda_expr): Propagate LAMBDA_CAPTURE_EXPLICIT_P.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > >   * g++.dg/cpp0x/lambda/lambda-108829.C: New test.
> > > ---
> > >  gcc/cp/pt.cc  |  4 
> > >  gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C | 11 +++
> > >  2 files changed, 15 insertions(+)
> > >  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> > > 
> > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > > index b1ac7d4beb4..f747ce877b5 100644
> > > --- a/gcc/cp/pt.cc
> > > +++ b/gcc/cp/pt.cc
> > > @@ -19992,6 +19992,10 @@ tsubst_lambda_expr (tree t, tree args, 
> > > tsubst_flags_t complain, tree in_decl)
> > > if (id_equal (DECL_NAME (field), "__this"))
> > >   LAMBDA_EXPR_THIS_CAPTURE (r) = field;
> > >   }
> > > +
> > > +  if (LAMBDA_EXPR_CAPTURE_LIST (r))
> > > + LAMBDA_CAPTURE_EXPLICIT_P (LAMBDA_EXPR_CAPTURE_LIST (r))
> > > +   = LAMBDA_CAPTURE_EXPLICIT_P (LAMBDA_EXPR_CAPTURE_LIST (t));
> > 
> > I'm not sure how the flag works for pack captures but it looks like
> > this would only propagate the flag to the last expanded capture if
> > the capture was originally a pack.
> 
> Testcase:
> 
>   template
>   void f(Ts... ts) {
> constexpr int IDX_PAGE_SIZE = 4096;
> int abyPage = [=, ts...] { return IDX_PAGE_SIZE; }();
>   }
>   void h() {
> f<1>(0, 1);
>   }

Thanks a lot for the testacase.  Revised patch below.  Look OK?

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

-- >8 --
Here we crash in is_capture_proxy:

  /* Location wrappers should be stripped or otherwise handled by the
 caller before using this predicate.  */
  gcc_checking_assert (!location_wrapper_p (decl));

We only crash with the redundant capture:

  int abyPage = [=, abyPage] { ... }

because prune_lambda_captures is only called when there was a default
capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.

The problem is that LAMBDA_CAPTURE_EXPLICIT_P wasn't propagated
correctly and so var_to_maybe_prune proceeded where it shouldn't.

PR c++/108829

gcc/cp/ChangeLog:

* pt.cc (prepend_one_capture): Set LAMBDA_CAPTURE_EXPLICIT_P.
(tsubst_lambda_expr): Pass LAMBDA_CAPTURE_EXPLICIT_P to
prepend_one_capture.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-108829-2.C: New test.
* g++.dg/cpp0x/lambda/lambda-108829.C: New test.

Co-Authored by: Patrick Palka 
---
 gcc/cp/pt.cc|  9 ++---
 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829-2.C | 11 +++
 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C   | 11 +++
 3 files changed, 28 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829-2.C
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 

Re: [PATCH] Fixing PR107411

[Jakub Jelinek via Gcc-patches]

On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote:
> +   else if (!DECL_NAME (lhs_var))
> + {
> +   char *lhs_var_name_str
> + = xasprintf ("D.%u", DECL_UID (lhs_var));

Why xasprintf?  D.%u can be sprintfed into a fixed size automatic buffer,
say 3 + (HOST_BITS_PER_INT + 2) / 3 would be a good upper bound for the size
of the buffer.  Then you don't need to free it...

> +   if (strcmp (lhs_var_name_str, var_name_str) == 0)
> + {
> +   free (lhs_var_name_str);
> +   return;
> + }
> +   free (lhs_var_name_str);
> + }
> + }
> gcc_assert (var_name_str && var_def_stmt);
>   }
>  }
> -- 
> 2.31.1

Jakub

[PATCH] Fixing PR107411

[Qing Zhao via Gcc-patches]

This is a bug in tree-ssa-uninit.cc.
When doing the following:

  /* Ignore the call to .DEFERRED_INIT that define the original
 var itself as the following case:
   temp = .DEFERRED_INIT (4, 2, “alt_reloc");
   alt_reloc = temp;
 In order to avoid generating warning for the fake usage
 at alt_reloc = temp.
  */

We need to compare the var name inside the .DEFERRED_INIT call
(the 3rd argument) and the name for the LHS variable. if they are the same,
we will NOT report the warning.

There is one issue when we get the name for the LHS variable. when the
variable doesn't have a DECL_NAME (it's not a user declared variable,
which is the case for this bug):

  _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
  D.2389 = _1;

The current checking just ignores this case, and still report the warning.

The fix is very simple, when getting the name for the LHS variable, we should
consider this case and come up with the name the same way as we construct the
3rd argument for the call to .DEFERRED_INIT (please refer to the routine
"gimple_add_init_for_auto_var")

The patch has been bootstrapped and regression tested on both x86 and aarch64.
Okay for committing?

thanks.

Qing

PR middle-end/107411

gcc/ChangeLog:

PR middle-end/107411
* tree-ssa-uninit.cc (warn_uninit): Handle the case when the
LHS varaible of a .DEFERRED_INIT call doesn't have a DECL_NAME.

gcc/testsuite/ChangeLog:

PR middle-end/107411
* g++.dg/pr107411.C: New test.
---
 gcc/testsuite/g++.dg/pr107411.C | 10 ++
 gcc/tree-ssa-uninit.cc  | 27 ---
 2 files changed, 30 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr107411.C

diff --git a/gcc/testsuite/g++.dg/pr107411.C b/gcc/testsuite/g++.dg/pr107411.C
new file mode 100644
index 000..7eefecae4f3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr107411.C
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-Werror=uninitialized -ftrivial-auto-var-init=zero"  } */
+int t();
+void f(int);
+
+void j()
+{
+  const int& e = t();
+  f(e);
+}
diff --git a/gcc/tree-ssa-uninit.cc b/gcc/tree-ssa-uninit.cc
index c555cf5cd50..b4218900f66 100644
--- a/gcc/tree-ssa-uninit.cc
+++ b/gcc/tree-ssa-uninit.cc
@@ -224,8 +224,6 @@ warn_uninit (opt_code opt, tree t, tree var, gimple 
*context,
 at alt_reloc = temp.
  */
  tree lhs_var = NULL_TREE;
- tree lhs_var_name = NULL_TREE;
- const char *lhs_var_name_str = NULL;
 
  /* Get the variable name from the 3rd argument of call.  */
  tree var_name = gimple_call_arg (var_def_stmt, 2);
@@ -239,11 +237,26 @@ warn_uninit (opt_code opt, tree t, tree var, gimple 
*context,
  else if (TREE_CODE (gimple_assign_lhs (context)) == SSA_NAME)
lhs_var = SSA_NAME_VAR (gimple_assign_lhs (context));
}
- if (lhs_var
- && (lhs_var_name = DECL_NAME (lhs_var))
- && (lhs_var_name_str = IDENTIFIER_POINTER (lhs_var_name))
- && (strcmp (lhs_var_name_str, var_name_str) == 0))
-   return;
+ if (lhs_var)
+   {
+ /* Get the name string for the LHS_VAR.
+Refer to routine gimple_add_init_for_auto_var.  */
+ if (DECL_NAME (lhs_var)
+ && (strcmp (IDENTIFIER_POINTER (DECL_NAME (lhs_var)),
+ var_name_str) == 0))
+   return;
+ else if (!DECL_NAME (lhs_var))
+   {
+ char *lhs_var_name_str
+   = xasprintf ("D.%u", DECL_UID (lhs_var));
+ if (strcmp (lhs_var_name_str, var_name_str) == 0)
+   {
+ free (lhs_var_name_str);
+ return;
+   }
+ free (lhs_var_name_str);
+   }
+   }
  gcc_assert (var_name_str && var_def_stmt);
}
 }
-- 
2.31.1

Re: [C PATCH] Detect all variably modified types [PR108375]

[Joseph Myers]

On Fri, 17 Feb 2023, Martin Uecker via Gcc-patches wrote:

> Here is a patch for PR108375.

This patch is OK.

> and another C FE patch for PR105660:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611817.html

This one is also OK.

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

Re: [PATCH 2/2] Remove #if GIMPLE around 1 - a pattern

[Jeff Law via Gcc-patches]

On 2/17/23 14:45, Andrew Pinski via Gcc-patches wrote:

This removes the "#if GIMPLE" around the
"1 - a" pattern as ssa_name_has_boolean_range
(get_range_query) works when cfun is a nullptr.

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

gcc/ChangeLog:

* match.pd: Remove #if GIMPLE around the
"1 - a" pattern
Both patches in this series are OK.  They're really just a slight 
refinement on a prior approved patch that addressed a regression.


jeff

[PATCH 1/2] Support get_range_query with a nullptr argument

[Andrew Pinski via Gcc-patches]

get_range_query didn't support a nullptr argument
before and would crash.
See also the thread at
https://inbox.sourceware.org/gcc/4f6718af-e17a-41ef-a886-f45e4ac3d...@redhat.com/T/

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

gcc/ChangeLog:

* value-query.h (get_range_query): Return the global ranges
for a nullptr func.
---
 gcc/value-query.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/value-query.h b/gcc/value-query.h
index 63878968118..2d7bf8fcf33 100644
--- a/gcc/value-query.h
+++ b/gcc/value-query.h
@@ -140,7 +140,7 @@ get_global_range_query ()
 ATTRIBUTE_RETURNS_NONNULL inline range_query *
 get_range_query (const struct function *fun)
 {
-  return fun->x_range_query ? fun->x_range_query : _ranges;
+  return (fun && fun->x_range_query) ? fun->x_range_query : _ranges;
 }
 
 // Query the global range of NAME in function F.  Default to cfun.
-- 
2.17.1

[PATCH 2/2] Remove #if GIMPLE around 1 - a pattern

[Andrew Pinski via Gcc-patches]

This removes the "#if GIMPLE" around the
"1 - a" pattern as ssa_name_has_boolean_range
(get_range_query) works when cfun is a nullptr.

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

gcc/ChangeLog:

* match.pd: Remove #if GIMPLE around the
"1 - a" pattern
---
 gcc/match.pd | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gcc/match.pd b/gcc/match.pd
index e7b700349a6..e352bd422f5 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1732,7 +1732,6 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (if (!FIXED_POINT_TYPE_P (type))
  (plus @0 (negate @1
 
-#if GIMPLE
 /* 1 - a is a ^ 1 if a had a bool range. */
 /* This is only enabled for gimple as sometimes
cfun is not set for the function which contains
@@ -1743,7 +1742,6 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
   (if (INTEGRAL_TYPE_P (type)
&& ssa_name_has_boolean_range (@1))
(bit_xor @1 @0)))
-#endif
 
 /* Other simplifications of negation (c.f. fold_negate_expr_1).  */
 (simplify
-- 
2.17.1

Re: [PATCH v2] c++: ICE with redundant capture [PR108829]

[Patrick Palka via Gcc-patches]

On Fri, 17 Feb 2023, Patrick Palka wrote:

> On Fri, 17 Feb 2023, Marek Polacek wrote:
> 
> > On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
> > > On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> > > 
> > > > Here we crash in is_capture_proxy:
> > > > 
> > > >   /* Location wrappers should be stripped or otherwise handled by the
> > > >  caller before using this predicate.  */
> > > >   gcc_checking_assert (!location_wrapper_p (decl));
> > > > 
> > > > so fixed as the comment suggests.  We only crash with the redundant
> > > > capture:
> > > > 
> > > >   int abyPage = [=, abyPage] { ... }
> > > > 
> > > > because prune_lambda_captures is only called when there was a default
> > > > capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.
> > > 
> > > It's weird that we even get this far in var_to_maybe_prune.  Shouldn't
> > > LAMBDA_CAPTURE_EXPLICIT_P be true for abyPage?
> > 
> > Ug, I was seduced by the ostensible obviousness and failed to notice
> > that check.  In that light, the correct fix ought to be this.  Thanks!
> > 
> > Bootstrap/regtest running on x86_64-pc-linux-gnu, ok for trunk if it
> > passes?
> > 
> > -- >8 --
> > Here we crash in is_capture_proxy:
> > 
> >   /* Location wrappers should be stripped or otherwise handled by the
> >  caller before using this predicate.  */
> >   gcc_checking_assert (!location_wrapper_p (decl));
> > 
> > We only crash with the redundant capture:
> > 
> >   int abyPage = [=, abyPage] { ... }
> > 
> > because prune_lambda_captures is only called when there was a default
> > capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.
> > 
> > The problem is that LAMBDA_CAPTURE_EXPLICIT_P wasn't propagated
> > correctly and so var_to_maybe_prune proceeded where it shouldn't.
> > 
> > PR c++/108829
> > 
> > gcc/cp/ChangeLog:
> > 
> > * pt.cc (tsubst_lambda_expr): Propagate LAMBDA_CAPTURE_EXPLICIT_P.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp0x/lambda/lambda-108829.C: New test.
> > ---
> >  gcc/cp/pt.cc  |  4 
> >  gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C | 11 +++
> >  2 files changed, 15 insertions(+)
> >  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> > 
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index b1ac7d4beb4..f747ce877b5 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -19992,6 +19992,10 @@ tsubst_lambda_expr (tree t, tree args, 
> > tsubst_flags_t complain, tree in_decl)
> >   if (id_equal (DECL_NAME (field), "__this"))
> > LAMBDA_EXPR_THIS_CAPTURE (r) = field;
> > }
> > +
> > +  if (LAMBDA_EXPR_CAPTURE_LIST (r))
> > +   LAMBDA_CAPTURE_EXPLICIT_P (LAMBDA_EXPR_CAPTURE_LIST (r))
> > + = LAMBDA_CAPTURE_EXPLICIT_P (LAMBDA_EXPR_CAPTURE_LIST (t));
> 
> I'm not sure how the flag works for pack captures but it looks like
> this would only propagate the flag to the last expanded capture if
> the capture was originally a pack.

Testcase:

  template
  void f(Ts... ts) {
constexpr int IDX_PAGE_SIZE = 4096;
int abyPage = [=, ts...] { return IDX_PAGE_SIZE; }();
  }
  void h() {
f<1>(0, 1);
  }

> 
> >  }
> >  
> >tree type = begin_lambda_type (r);
> > diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C 
> > b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> > new file mode 100644
> > index 000..e621a0d14d0
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> > @@ -0,0 +1,11 @@
> > +// PR c++/108829
> > +// { dg-do compile { target c++11 } }
> > +
> > +template 
> > +void f(void) {
> > +  constexpr int IDX_PAGE_SIZE = 4096;
> > +  int abyPage = [=, abyPage] { return IDX_PAGE_SIZE; }(); // { dg-error 
> > "redundant" }
> > +}
> > +void h() {
> > +  f<1>();
> > +}
> > 
> > base-commit: 5fea1be820508e1fbc610d1a54b61c1add33c36f
> > -- 
> > 2.39.2
> > 
> > 
> 

Re: [PATCH v2] c++: ICE with redundant capture [PR108829]

[Patrick Palka via Gcc-patches]

On Fri, 17 Feb 2023, Marek Polacek wrote:

> On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
> > On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> > 
> > > Here we crash in is_capture_proxy:
> > > 
> > >   /* Location wrappers should be stripped or otherwise handled by the
> > >  caller before using this predicate.  */
> > >   gcc_checking_assert (!location_wrapper_p (decl));
> > > 
> > > so fixed as the comment suggests.  We only crash with the redundant
> > > capture:
> > > 
> > >   int abyPage = [=, abyPage] { ... }
> > > 
> > > because prune_lambda_captures is only called when there was a default
> > > capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.
> > 
> > It's weird that we even get this far in var_to_maybe_prune.  Shouldn't
> > LAMBDA_CAPTURE_EXPLICIT_P be true for abyPage?
> 
> Ug, I was seduced by the ostensible obviousness and failed to notice
> that check.  In that light, the correct fix ought to be this.  Thanks!
> 
> Bootstrap/regtest running on x86_64-pc-linux-gnu, ok for trunk if it
> passes?
> 
> -- >8 --
> Here we crash in is_capture_proxy:
> 
>   /* Location wrappers should be stripped or otherwise handled by the
>  caller before using this predicate.  */
>   gcc_checking_assert (!location_wrapper_p (decl));
> 
> We only crash with the redundant capture:
> 
>   int abyPage = [=, abyPage] { ... }
> 
> because prune_lambda_captures is only called when there was a default
> capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.
> 
> The problem is that LAMBDA_CAPTURE_EXPLICIT_P wasn't propagated
> correctly and so var_to_maybe_prune proceeded where it shouldn't.
> 
>   PR c++/108829
> 
> gcc/cp/ChangeLog:
> 
>   * pt.cc (tsubst_lambda_expr): Propagate LAMBDA_CAPTURE_EXPLICIT_P.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp0x/lambda/lambda-108829.C: New test.
> ---
>  gcc/cp/pt.cc  |  4 
>  gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C | 11 +++
>  2 files changed, 15 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> 
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index b1ac7d4beb4..f747ce877b5 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -19992,6 +19992,10 @@ tsubst_lambda_expr (tree t, tree args, 
> tsubst_flags_t complain, tree in_decl)
> if (id_equal (DECL_NAME (field), "__this"))
>   LAMBDA_EXPR_THIS_CAPTURE (r) = field;
>   }
> +
> +  if (LAMBDA_EXPR_CAPTURE_LIST (r))
> + LAMBDA_CAPTURE_EXPLICIT_P (LAMBDA_EXPR_CAPTURE_LIST (r))
> +   = LAMBDA_CAPTURE_EXPLICIT_P (LAMBDA_EXPR_CAPTURE_LIST (t));

I'm not sure how the flag works for pack captures but it looks like
this would only propagate the flag to the last expanded capture if
the capture was originally a pack.

>  }
>  
>tree type = begin_lambda_type (r);
> diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C 
> b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> new file mode 100644
> index 000..e621a0d14d0
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> @@ -0,0 +1,11 @@
> +// PR c++/108829
> +// { dg-do compile { target c++11 } }
> +
> +template 
> +void f(void) {
> +  constexpr int IDX_PAGE_SIZE = 4096;
> +  int abyPage = [=, abyPage] { return IDX_PAGE_SIZE; }(); // { dg-error 
> "redundant" }
> +}
> +void h() {
> +  f<1>();
> +}
> 
> base-commit: 5fea1be820508e1fbc610d1a54b61c1add33c36f
> -- 
> 2.39.2
> 
> 

Re: [PATCH] doc: Fix typo in -Wall description

[Siddhesh Poyarekar]

On 2023-02-17 14:43, Jeff Law wrote:



On 2/17/23 06:41, Siddhesh Poyarekar wrote:

-Wall enables -Wuse-after-free=2 and not -Wuse-after-free=3.

gcc/ChangeLog:

* gcc/doc/invoke.texi (@item -Wall): Fix typo in
-Wuse-after-free.

Looks obvious to me.  If you haven't committed it already, go ahead.


Pushed, thanks.

Sid

[PATCH v2] c++: ICE with redundant capture [PR108829]

[Marek Polacek via Gcc-patches]

On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
> On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> 
> > Here we crash in is_capture_proxy:
> > 
> >   /* Location wrappers should be stripped or otherwise handled by the
> >  caller before using this predicate.  */
> >   gcc_checking_assert (!location_wrapper_p (decl));
> > 
> > so fixed as the comment suggests.  We only crash with the redundant
> > capture:
> > 
> >   int abyPage = [=, abyPage] { ... }
> > 
> > because prune_lambda_captures is only called when there was a default
> > capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.
> 
> It's weird that we even get this far in var_to_maybe_prune.  Shouldn't
> LAMBDA_CAPTURE_EXPLICIT_P be true for abyPage?

Ug, I was seduced by the ostensible obviousness and failed to notice
that check.  In that light, the correct fix ought to be this.  Thanks!

Bootstrap/regtest running on x86_64-pc-linux-gnu, ok for trunk if it
passes?

-- >8 --
Here we crash in is_capture_proxy:

  /* Location wrappers should be stripped or otherwise handled by the
 caller before using this predicate.  */
  gcc_checking_assert (!location_wrapper_p (decl));

We only crash with the redundant capture:

  int abyPage = [=, abyPage] { ... }

because prune_lambda_captures is only called when there was a default
capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.

The problem is that LAMBDA_CAPTURE_EXPLICIT_P wasn't propagated
correctly and so var_to_maybe_prune proceeded where it shouldn't.

PR c++/108829

gcc/cp/ChangeLog:

* pt.cc (tsubst_lambda_expr): Propagate LAMBDA_CAPTURE_EXPLICIT_P.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-108829.C: New test.
---
 gcc/cp/pt.cc  |  4 
 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C | 11 +++
 2 files changed, 15 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index b1ac7d4beb4..f747ce877b5 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -19992,6 +19992,10 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
  if (id_equal (DECL_NAME (field), "__this"))
LAMBDA_EXPR_THIS_CAPTURE (r) = field;
}
+
+  if (LAMBDA_EXPR_CAPTURE_LIST (r))
+   LAMBDA_CAPTURE_EXPLICIT_P (LAMBDA_EXPR_CAPTURE_LIST (r))
+ = LAMBDA_CAPTURE_EXPLICIT_P (LAMBDA_EXPR_CAPTURE_LIST (t));
 }
 
   tree type = begin_lambda_type (r);
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
new file mode 100644
index 000..e621a0d14d0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
@@ -0,0 +1,11 @@
+// PR c++/108829
+// { dg-do compile { target c++11 } }
+
+template 
+void f(void) {
+  constexpr int IDX_PAGE_SIZE = 4096;
+  int abyPage = [=, abyPage] { return IDX_PAGE_SIZE; }(); // { dg-error 
"redundant" }
+}
+void h() {
+  f<1>();
+}

base-commit: 5fea1be820508e1fbc610d1a54b61c1add33c36f
-- 
2.39.2

Re: [PATCH RFC] c++: static_assert (false) in template [DR2518]

[Jakub Jelinek via Gcc-patches]

On Fri, Feb 17, 2023 at 03:32:09PM -0500, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu.  This isn't really a regression fix, but it's very
> safe, and fixes a longstanding annoyance, so I'm leaning toward putting it 
> into
> GCC 13.  Thoughts?

I think it is ok for GCC 13.

I bet for the testsuite coverage of the whole DR2518 wording we have already
tons of testcases which verify we actually error on #error directives and
warn on #warning directives and error in failed static_assert unless in
uninstantiated templates that it isn't worth repeating them in the
dr2518*.C testcase(s).

I'm a little bit surprised we didn't check for errors from static_asserts
failed asserts in uninstantiated templates...

Jakub

Re: [PATCH] [libstdc++] ensure mutex_pool survives _Safe_sequence_base

[François Dumont via Gcc-patches]

On 17/02/23 09:01, Alexandre Oliva via Libstdc++ wrote:

On Feb 17, 2023, Alexandre Oliva  wrote:


On vxworks, after destroying the semaphore used to implement a mutex,
__gthread_mutex_lock fails and __gnu_cxx::__mutex::lock calls
__throw_concurrence_lock_error.  Nothing ensures the mutex_pool
mutexes survive init-once objects containing _Safe_sequence_base.  If
such an object completes construction before mutex_pool
initialization, it will be registered for atexit destruction after the
mutex_pool mutexes, so the _M_detach_all() call in the
_Safe_sequence_base dtor will use already-destructed mutexes, and
basic_string/requirements/citerators_cc fails calling terminate.

Here's an alternative approach, with zero runtime overhead.  Negative
overhead, if you count the time it would have taken to destruct the
mutex pool :-) But it fails to destruct them, which is presumably of no
consequence.

[libstdc++] do not destruct mutex_pool mutexes

[Copy of the paragraph quoted above omitted here]

This patch fixes this problem by ensuring the mutex pool mutexes are
constructed on demand, on a statically-allocated buffer, but never
destructed.

Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

for  libstdc++-v3/ChangeLog

* src/c++11/shared_ptr.cc (__gnu_internal::get_mutex):
Avoid destruction of the mutex pool.
---
  libstdc++-v3/src/c++11/shared_ptr.cc |6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++11/shared_ptr.cc 
b/libstdc++-v3/src/c++11/shared_ptr.cc
index bc70134359c87..74e879e582896 100644
--- a/libstdc++-v3/src/c++11/shared_ptr.cc
+++ b/libstdc++-v3/src/c++11/shared_ptr.cc
@@ -36,7 +36,11 @@ namespace __gnu_internal _GLIBCXX_VISIBILITY(hidden)
{
  // increase alignment to put each lock on a separate cache line
  struct alignas(64) M : __gnu_cxx::__mutex { };
-static M m[mask + 1];
+// Use a static buffer, so that the mutexes are not destructed
+// before potential users (or at all)

I guess you meant 'before potential use'

+static __attribute__ ((aligned(__alignof__(M
+  char buffer[(sizeof (M)) * (mask + 1)];
+static M *m = new (buffer) M[mask + 1];
  return m[i];
}
  }

[PATCH RFC] c++: static_assert (false) in template [DR2518]

[Jason Merrill via Gcc-patches]

Tested x86_64-pc-linux-gnu.  This isn't really a regression fix, but it's very
safe, and fixes a longstanding annoyance, so I'm leaning toward putting it into
GCC 13.  Thoughts?

-- 8< --

For a long time, people have expected to be able to write
static_assert (false) in a template and only have it diagnosed if the
template is instantiated, but we (and other implementations) gave an error
about the uninstantiated template because the standard says that if no valid
instantiation of the template is possible, the program is ill-formed, no
diagnostic required, and we try to diagnose IFNDR things when feasible.

At the meeting last week we were looking at CWG2518, which wanted to specify
that an implementation must not accept a program containing a failing #error
or static_assert.  We also looked at P2593, which proposed allowing
static_assert in an uninstantiated template.  We ended up combining these
two in order to avoid requiring implementations to reject programs with
static_assert (false) in uninstantiated templates.

The committee accepted this as a DR, so I'm making the change to all
standard modes.  This behavior was also conformant previously, since no
diagnostic was required in this case.

We continue to diagnose non-constant or otherwise ill-formed conditions, so
no changes to existing tests were needed.

DR 2518
PR c++/52809
PR c++/53638
PR c++/87389
PR c++/89741
PR c++/92099
PR c++/104041
PR c++/104691

gcc/cp/ChangeLog:

* semantics.cc (finish_static_assert): Don't diagnose in
template context.

gcc/testsuite/ChangeLog:

* g++.dg/DRs/dr2518.C: New test.
---
 gcc/cp/semantics.cc   | 17 ++---
 gcc/testsuite/g++.dg/DRs/dr2518.C |  7 +++
 2 files changed, 17 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/DRs/dr2518.C

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index c2df0b69b30..79b7cc72f21 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -11232,14 +11232,16 @@ finish_static_assert (tree condition, tree message, 
location_t location,
   if (check_for_bare_parameter_packs (condition))
 condition = error_mark_node;
 
+  /* Save the condition in case it was a concept check.  */
+  tree orig_condition = condition;
+
   if (instantiation_dependent_expression_p (condition))
 {
   /* We're in a template; build a STATIC_ASSERT and put it in
  the right place. */
-  tree assertion;
-
-  assertion = make_node (STATIC_ASSERT);
-  STATIC_ASSERT_CONDITION (assertion) = condition;
+defer:
+  tree assertion = make_node (STATIC_ASSERT);
+  STATIC_ASSERT_CONDITION (assertion) = orig_condition;
   STATIC_ASSERT_MESSAGE (assertion) = message;
   STATIC_ASSERT_SOURCE_LOCATION (assertion) = location;
 
@@ -11253,9 +11255,6 @@ finish_static_assert (tree condition, tree message, 
location_t location,
   return;
 }
 
-  /* Save the condition in case it was a concept check.  */
-  tree orig_condition = condition;
-
   /* Fold the expression and convert it to a boolean value. */
   condition = contextual_conv_bool (condition, complain);
   condition = fold_non_dependent_expr (condition, complain,
@@ -11270,6 +11269,10 @@ finish_static_assert (tree condition, tree message, 
location_t location,
 
   if (integer_zerop (condition))
{
+ /* CWG2518: static_assert failure in a template is not IFNDR.  */
+ if (processing_template_decl)
+   goto defer;
+
  int sz = TREE_INT_CST_LOW (TYPE_SIZE_UNIT
 (TREE_TYPE (TREE_TYPE (message;
  int len = TREE_STRING_LENGTH (message) / sz - 1;
diff --git a/gcc/testsuite/g++.dg/DRs/dr2518.C 
b/gcc/testsuite/g++.dg/DRs/dr2518.C
new file mode 100644
index 000..240186211e6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/DRs/dr2518.C
@@ -0,0 +1,7 @@
+// CWG 2518
+// { dg-do compile { target c++11 } }
+
+template  void f()
+{
+  static_assert (false, "");
+}

base-commit: 07f497c2da3600cc99cd7d1b5c6726972fb2b5a1
-- 
2.31.1

Re: [PATCH] c++: ICE with redundant capture [PR108829]

[Patrick Palka via Gcc-patches]

On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:

> Here we crash in is_capture_proxy:
> 
>   /* Location wrappers should be stripped or otherwise handled by the
>  caller before using this predicate.  */
>   gcc_checking_assert (!location_wrapper_p (decl));
> 
> so fixed as the comment suggests.  We only crash with the redundant
> capture:
> 
>   int abyPage = [=, abyPage] { ... }
> 
> because prune_lambda_captures is only called when there was a default
> capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.

It's weird that we even get this far in var_to_maybe_prune.  Shouldn't
LAMBDA_CAPTURE_EXPLICIT_P be true for abyPage?

> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12?
> 
>   PR c++/108829
> 
> gcc/cp/ChangeLog:
> 
>   * lambda.cc (var_to_maybe_prune): Strip location wrappers before
>   checking for a capture proxy.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp0x/lambda/lambda-108829.C: New test.
> ---
>  gcc/cp/lambda.cc  |  1 +
>  gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C | 11 +++
>  2 files changed, 12 insertions(+)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> 
> diff --git a/gcc/cp/lambda.cc b/gcc/cp/lambda.cc
> index c752622816d..a12b9c183c2 100644
> --- a/gcc/cp/lambda.cc
> +++ b/gcc/cp/lambda.cc
> @@ -1700,6 +1700,7 @@ var_to_maybe_prune (tree cap)
>  return NULL_TREE;
>  
>tree init = TREE_VALUE (cap);
> +  STRIP_ANY_LOCATION_WRAPPER (init);
>if (is_normal_capture_proxy (init))
>  init = DECL_CAPTURED_VARIABLE (init);
>if (decl_constant_var_p (init))
> diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C 
> b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> new file mode 100644
> index 000..e621a0d14d0
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
> @@ -0,0 +1,11 @@
> +// PR c++/108829
> +// { dg-do compile { target c++11 } }
> +
> +template 
> +void f(void) {
> +  constexpr int IDX_PAGE_SIZE = 4096;
> +  int abyPage = [=, abyPage] { return IDX_PAGE_SIZE; }(); // { dg-error 
> "redundant" }
> +}
> +void h() {
> +  f<1>();
> +}
> 
> base-commit: 6245441e124846d0c3551f312d2feef598fe251c
> -- 
> 2.39.2
> 
> 

Re: [PATCH] Drop need for constant I in ctf test

[Mike Stump via Gcc-patches]

On Feb 16, 2023, at 10:59 PM, Alexandre Oliva  wrote:
> 
> Though I is supposed to be a constant expression, this is not the case
> on vxworks, but this is not what this debug information format test is
> testing for, so use real constants to initialize complex variables.
> 
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

Ok.

Re: [PATCH] [arm] xfail fp-uint64-convert-double-* on all arm targets

[Mike Stump via Gcc-patches]

On Feb 16, 2023, at 10:20 PM, Alexandre Oliva  wrote:
> 
> It wasn't long ago that I xfailed these tests on arm-*-eabi, but the
> fail is expected on all other arm targets: even when hard float is
> available, conversions between 64-bit integers and double are always
> emulated on ARM, and the emulation disregards rounding modes.  So,
> bump the xfail to all of arm-*-*.
> 
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

Ok.

Re: [arm] [testsuite] asm-flag-4.c: match quotes in expected message

[Mike Stump via Gcc-patches]

On Feb 16, 2023, at 10:15 PM, Alexandre Oliva  wrote:
> 
> Quotes were added around the "asm" keyword in the message expected by
> the test, so the test needs adjusting.
> 
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).
> Ok to install?

Ok.

Re: [PATCH] Fix PR target/90458

[Jeff Law via Gcc-patches]

On 2/17/23 01:56, NightStrike via Gcc-patches wrote:

On Thu, Feb 16, 2023 at 3:16 AM Eric Botcazou  wrote:



This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!


Try the attached patch.


Well... that patch just marks all of the tests as unsupported.  But
for example, the ones quoted above run, work, and pass.  And when they
didn't pass, they highlighted the ICE that you fixed.  So running the
test despite the nature of stack protection on Windows still has
value.  It is useful to ensure for example that stack protection
continues to work even if options are passed to disable it.  But the
tests that remain are looking for rtl patterns that (I assume)
shouldn't exist.  So it's perhaps useful to modify the test to say
that on windows, the scan-rtl-dump-times check should have zero hits.
If it found a match, that would be an error.
Those tests may compile, work and pass, but they're really there to 
check the probing decisions.  Windows has a totally different model and 
none of those tests really make sense in that model.


Is there a way to say that the test results should be inverted on a
particular platform (instead of purely unsupported)?
You can express all kinds of things, I'm just not sure it's worth the 
effort for these tests.

Re: [PATCH] doc: Fix typo in -Wall description

[Jeff Law via Gcc-patches]

On 2/17/23 06:41, Siddhesh Poyarekar wrote:

-Wall enables -Wuse-after-free=2 and not -Wuse-after-free=3.

gcc/ChangeLog:

* gcc/doc/invoke.texi (@item -Wall): Fix typo in
-Wuse-after-free.

Looks obvious to me.  If you haven't committed it already, go ahead.

jeff

[PATCH] c++: ICE with redundant capture [PR108829]

[Marek Polacek via Gcc-patches]

Here we crash in is_capture_proxy:

  /* Location wrappers should be stripped or otherwise handled by the
 caller before using this predicate.  */
  gcc_checking_assert (!location_wrapper_p (decl));

so fixed as the comment suggests.  We only crash with the redundant
capture:

  int abyPage = [=, abyPage] { ... }

because prune_lambda_captures is only called when there was a default
capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.

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

PR c++/108829

gcc/cp/ChangeLog:

* lambda.cc (var_to_maybe_prune): Strip location wrappers before
checking for a capture proxy.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-108829.C: New test.
---
 gcc/cp/lambda.cc  |  1 +
 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C | 11 +++
 2 files changed, 12 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C

diff --git a/gcc/cp/lambda.cc b/gcc/cp/lambda.cc
index c752622816d..a12b9c183c2 100644
--- a/gcc/cp/lambda.cc
+++ b/gcc/cp/lambda.cc
@@ -1700,6 +1700,7 @@ var_to_maybe_prune (tree cap)
 return NULL_TREE;
 
   tree init = TREE_VALUE (cap);
+  STRIP_ANY_LOCATION_WRAPPER (init);
   if (is_normal_capture_proxy (init))
 init = DECL_CAPTURED_VARIABLE (init);
   if (decl_constant_var_p (init))
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
new file mode 100644
index 000..e621a0d14d0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-108829.C
@@ -0,0 +1,11 @@
+// PR c++/108829
+// { dg-do compile { target c++11 } }
+
+template 
+void f(void) {
+  constexpr int IDX_PAGE_SIZE = 4096;
+  int abyPage = [=, abyPage] { return IDX_PAGE_SIZE; }(); // { dg-error 
"redundant" }
+}
+void h() {
+  f<1>();
+}

base-commit: 6245441e124846d0c3551f312d2feef598fe251c
-- 
2.39.2

[C PATCH] Detect all variably modified types [PR108375]

[Martin Uecker via Gcc-patches]

Here is a patch for PR108375.

Bootstrapped and regession tested on x86_64-linux-gnu


Also there is a middle-end patch for PR107557 and PR108423:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611562.html
and another C FE patch for PR105660:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611817.html

All regressions.



C: Detect all variably modified types [PR108375]

Some variably modified types were not detected correctly.
Define C_TYPE_VARIABLY_MODIFIED via TYPE_LANG_FLAG 6 in the CFE.
This flag records whether a type is variably modified and is
set for all such types including arrays with variably modified
element type or structures and unions with variably modified
members. This is then used to detect such types in the C FE
and middle-end (via the existing language hook).

PR 108375

gcc/c/

* c/c-decl.c (decl_jump_unsafe): Use c_type_variably_modified_p.
(diagnose_mismatched_decl): Dito.
(warn_about_goto): Dito:
(c_check_switch_jump_warnings): Dito.
(finish_decl): Dito.
(finish_struct): Dito.
(grokdeclarator): Set C_TYPE_VARIABLY_MODIFIED.
(finish_struct): Set C_TYPE_VARIABLY_MODIFIED.
* c/c-objc-common.cc (c_var_mod_p): New function.
(c_var_unspec_p): Remove.
* c/c-objc-common.h: Set lang hook.
* c/c-parser.cc (c_parser_declararion_or_fndef): Use 
c_type_variably_modified_p.
(c_parser_typeof_specifier): Dito.
(c_parser_has_attribute_expression): Dito.
(c_parser_generic_selection): Dito.
* c/c-tree.h: Define C_TYPE_VARIABLY_MODIFIED and define 
c_var_mode_p.
* c/c-typeck.h: Remove c_vla_mod_p and use C_TYPE_VARIABLY_MODIFIED.

gcc/testsuite/

* gcc.dg/pr108375-1.c: New test.
* gcc.dg/pr108375-2.c: New test.


diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 20e7d1855bf..08078eadeb8 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -683,7 +683,7 @@ decl_jump_unsafe (tree decl)
 
   /* Always warn about crossing variably modified types.  */
   if ((VAR_P (decl) || TREE_CODE (decl) == TYPE_DECL)
-  && variably_modified_type_p (TREE_TYPE (decl), NULL_TREE))
+  && c_type_variably_modified_p (TREE_TYPE (decl)))
 return true;
 
   /* Otherwise, only warn if -Wgoto-misses-init and this is an
@@ -2247,7 +2247,7 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
  || warning_suppressed_p (olddecl, OPT_Wpedantic))
return true;  /* Allow OLDDECL to continue in use.  */
 
-  if (variably_modified_type_p (newtype, NULL))
+  if (c_type_variably_modified_p (newtype))
{
  error ("redefinition of typedef %q+D with variably modified type",
 newdecl);
@@ -3975,7 +3975,7 @@ static void
 warn_about_goto (location_t goto_loc, tree label, tree decl)
 {
   auto_diagnostic_group d;
-  if (variably_modified_type_p (TREE_TYPE (decl), NULL_TREE))
+  if (c_type_variably_modified_p (TREE_TYPE (decl)))
 error_at (goto_loc,
  "jump into scope of identifier with variably modified type");
   else
@@ -4249,7 +4249,7 @@ c_check_switch_jump_warnings (struct c_spot_bindings 
*switch_bindings,
{
  auto_diagnostic_group d;
  bool emitted;
- if (variably_modified_type_p (TREE_TYPE (b->decl), NULL_TREE))
+ if (c_type_variably_modified_p (TREE_TYPE (b->decl)))
{
  saw_error = true;
  error_at (case_loc,
@@ -5862,7 +5862,7 @@ finish_decl (tree decl, location_t init_loc, tree init,
   if (TREE_CODE (decl) == TYPE_DECL)
 {
   if (!DECL_FILE_SCOPE_P (decl)
- && variably_modified_type_p (TREE_TYPE (decl), NULL_TREE))
+ && c_type_variably_modified_p (TREE_TYPE (decl)))
add_stmt (build_stmt (DECL_SOURCE_LOCATION (decl), DECL_EXPR, decl));
 
   rest_of_decl_compilation (decl, DECL_FILE_SCOPE_P (decl), 0);
@@ -6682,7 +6682,7 @@ grokdeclarator (const struct c_declarator *declarator,
 
   if ((decl_context == NORMAL || decl_context == FIELD)
   && current_scope == file_scope
-  && variably_modified_type_p (type, NULL_TREE))
+  && c_type_variably_modified_p (type))
 {
   if (name)
error_at (loc, "variably modified %qE at file scope", name);
@@ -6928,6 +6928,8 @@ grokdeclarator (const struct c_declarator *declarator,
  array_parm_static = false;
}
 
+  bool varmod = C_TYPE_VARIABLY_MODIFIED (type);
+
   switch (declarator->kind)
{
case cdk_attrs:
@@ -7282,8 +7284,7 @@ grokdeclarator (const struct c_declarator *declarator,
   variable size, so the enclosing shared array type
   must too.  */
if (size && TREE_CODE (size) == INTEGER_CST)
- type
- 

Re: [PATCH] rs6000: fmr gets used instead of faster xxlor [PR93571]

[Segher Boessenkool]

Hi!

On Fri, Feb 17, 2023 at 10:28:41PM +0530, Ajit Agarwal wrote:
> This patch replaces fmr instruction (6 cycles) with xxlor instruction ( 2 
> cycles)
> Bootstrapped and regtested on powerpc64-linux-gnu.

You tested this on a CPU that does have VSX.  It is incorrect on other
(older) CPUs.

> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -8436,7 +8436,7 @@
>"@
> stfd%U0%X0 %1,%0
> lfd%U1%X1 %0,%1
> -   fmr %0,%1
> +   xxlor %0,%1,%1
> lxsd %0,%1
> stxsd %1,%0
> lxsdx %x0,%y1

This is the *mov_hardfloat64 pattern.  You can add some magic to
your Git config so that will show in the patch: in .git/config:

[diff "md"]
xfuncname = "^\\(define.*$"

(As it says in .gitattributes:
  # Make diff on MD files use "(define" as a function marker.
  # Use together with git config diff.md.xfuncname '^\(define.*$'
  # which is run by contrib/gcc-git-customization.sh too.
  *.md diff=md
)

The third alternative to this insn, the fmr one, has "d" as both input
and output constraint, and has "*" as isa attribute, so it will be used
on any CPU that has floating point registers.  The eight alternative
(the existing xxlor one) has "wa" constraints (via ) so it
implicitly requires VSX to be enabled.  You need to do something similar
for what you want, but you also need to still allow fmr.


Segher

Re: [PATCH] Accept pmf-vbit-in-delta extra warning

[Jason Merrill via Gcc-patches]

On 2/17/23 23:02, Alexandre Oliva wrote:


cp_build_binary_op, that issues -Waddress warnings, issues an extra
warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect
when comparing a pointer-to-member-function literal with null.

The reason for the extra warning is that, on arm targets,
TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, which
causes a different path to be taken, that extracts the
pointer-to-function and the delta fields (minus the vbit) and compares
each one with zero.  It's when comparing this pointer-to-function with
zero, in a recursive cp_build_binary_op, that another warning is
issued.

I suppose there should be a way to skip the warning in this recursive
call, without disabling other warnings that might be issued there, but


warning_sentinel ws (warn_address)

?


this patch only arranges for the test to tolerate the extra warning.

Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?


OK


for  gcc/testsuite/ChangeLog

* g++.dg/warn/Waddress-5.C: Tolerate extra -Waddress warning.
---
  gcc/testsuite/g++.dg/warn/Waddress-5.C |6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/warn/Waddress-5.C 
b/gcc/testsuite/g++.dg/warn/Waddress-5.C
index b1287b2fac316..1de88076f7767 100644
--- a/gcc/testsuite/g++.dg/warn/Waddress-5.C
+++ b/gcc/testsuite/g++.dg/warn/Waddress-5.C
@@ -23,7 +23,11 @@ void T (bool);
  void warn_memptr_if ()
  {
// Exercise warnings for addresses of nonstatic member functions.
-  if (::f == 0) // { dg-warning "the address '::f'" }
+  // On targets with TARGET_PTRMEMFUNC_VBIT_LOCATION ==
+  // ptrmemfunc_vbit_in_delta, cp_build_binary_op recurses to compare
+  // the pfn from the ptrmemfunc with null, so we get two warnings.
+  // This matches both.  ??? Should we disable one of them?
+  if (::f == 0) // { dg-warning "A::f" }
  T (0);
  
if (::vf) // { dg-warning "-Waddress" }

Re: [PATCH] rs6000: fmr gets used instead of faster xxlor [PR93571]

[Andrew Pinski via Gcc-patches]

On Fri, Feb 17, 2023 at 8:59 AM Ajit Agarwal via Gcc-patches
 wrote:
>
>
> Hello All:
>
> This patch replaces fmr instruction (6 cycles) with xxlor instruction ( 2 
> cycles)
> Bootstrapped and regtested on powerpc64-linux-gnu.

I don't think this can be unconditionally replaced.
xxlor only exists in newer Power ISA.

Thanks,
Andrew Pinski

>
> copyright assignment form is still in the process of being sent.
>
> Thanks & Regards
> Ajit
>
> rs6000: fmr gets used instead of faster xxlor [PR93571]
>
> This patch replaces 6 cycles fmr instruction with xxlor
> 2 cycles.
>
> 2023-02-17  Ajit Kumar Agarwal  
>
> gcc/ChangeLog:
>
> * config/rs6000/rs6000.md (*movdf_hardfloat64): Replace fmr with 
> xxlor instruction.
> ---
>  gcc/config/rs6000/rs6000.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index 4a7812fa592..dfd6c73ffcb 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -8436,7 +8436,7 @@
>"@
> stfd%U0%X0 %1,%0
> lfd%U1%X1 %0,%1
> -   fmr %0,%1
> +   xxlor %0,%1,%1
> lxsd %0,%1
> stxsd %1,%0
> lxsdx %x0,%y1
> --
> 2.31.1
>
>

Re: [PATCH] [vxworks] make wint_t and wchar_t the same distinct type

[Jason Merrill via Gcc-patches]

On 2/17/23 23:04, Alexandre Oliva wrote:


We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
wchar_t


And fixing that isn't an option?  Do the integer builtins work properly 
if we force them to use wchar_t instead of an integer type?



headers got included in the test that declared functions that
take wint_t parameters, and those conflicted with the builtin
declarations that had wint_t mapped to the underlying integral type.

The problem is that, in C++, wchar_t is a distinct type.  Having
wint_t be a typedef to wchar_t in the headers, but a typedef to
wchar_t's underlying integral type in builtins, makes for mismatches
between the declarations.

This patch defines WINT_TYPE to "wchar_t" for vxworks, and adjusts the
fallout, namely:

- since wchar_t may not have been defined yet when
   c_common_nodes_and_builtins runs, use the node already reserved for
   wchar_t for wint_t when WINT_TYPE is defined to wchar_t.

- for the same reason, when WINT_TYPE is wchar_t and we're not
   compiling C++ where wchar_t is a compiler built-in, define
   __WINT_TYPE__ to WCHAR_TYPE rather than WINT_TYPE, because wchar_t
   may not even be defined in the translation unit.

- recognize and handle wchar_type_node when type_suffix is called for
   wint_type_node.

Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

for  gcc/ChangeLog

* config/vx-common.h (WINT_TYPE): Alias to "wchar_t".

for  gcc/c-family/ChangeLog

* c-common.cc (c_common_nodes_and_builtins): Take
wchar_type_node for wint_type_node when aliased.
(c_stddef_cpp_builtins): Define __WINT_TYPE__, when aliased to
wchar_t, to the underlying type rather than wchar_t in
non-C++.
* c-cppbuiltin.cc (type_suffix): Handle wchar_type_node.
---
  gcc/c-family/c-common.cc |   16 +---
  gcc/c-family/c-cppbuiltin.cc |2 ++
  gcc/config/vx-common.h   |2 +-
  3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index ae92cd5adaf5e..a92597c2f544f 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -4576,8 +4576,11 @@ c_common_nodes_and_builtins (void)
char32_array_type_node
  = build_array_type (char32_type_node, array_domain_type);
  
-  wint_type_node =

-TREE_TYPE (identifier_global_value (get_identifier (WINT_TYPE)));
+  if (strcmp (WINT_TYPE, "wchar_t") == 0)
+wint_type_node = wchar_type_node;
+  else
+wint_type_node =
+  TREE_TYPE (identifier_global_value (get_identifier (WINT_TYPE)));
  
intmax_type_node =

  TREE_TYPE (identifier_global_value (get_identifier (INTMAX_TYPE)));
@@ -5359,7 +5362,14 @@ c_stddef_cpp_builtins(void)
builtin_define_with_value ("__SIZE_TYPE__", SIZE_TYPE, 0);
builtin_define_with_value ("__PTRDIFF_TYPE__", PTRDIFF_TYPE, 0);
builtin_define_with_value ("__WCHAR_TYPE__", MODIFIED_WCHAR_TYPE, 0);
-  builtin_define_with_value ("__WINT_TYPE__", WINT_TYPE, 0);
+  /* C++ has wchar_t as a builtin type, C doesn't, so if WINT_TYPE
+ maps to wchar_t, define it to the underlying WCHAR_TYPE in C, and
+ to wchar_t in C++, so the desired type equivalence holds.  */
+  if (!c_dialect_cxx ()
+  && strcmp (WINT_TYPE, "wchar_t") == 0)
+builtin_define_with_value ("__WINT_TYPE__", WCHAR_TYPE, 0);
+  else
+builtin_define_with_value ("__WINT_TYPE__", WINT_TYPE, 0);
builtin_define_with_value ("__INTMAX_TYPE__", INTMAX_TYPE, 0);
builtin_define_with_value ("__UINTMAX_TYPE__", UINTMAX_TYPE, 0);
if (flag_char8_t)
diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index b333f97fd3237..98f5aef2af95d 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -1903,6 +1903,8 @@ type_suffix (tree type)
  systems use it anyway.  */
   || type == char_type_node)
  is_long = 0;
+  else if (type == wchar_type_node)
+return type_suffix (underlying_wchar_type_node);
else
  gcc_unreachable ();
  
diff --git a/gcc/config/vx-common.h b/gcc/config/vx-common.h

index 83580d0dec288..9733c90fe4c6f 100644
--- a/gcc/config/vx-common.h
+++ b/gcc/config/vx-common.h
@@ -69,7 +69,7 @@ along with GCC; see the file COPYING3.  If not see
  #undef WINT_TYPE_SIZE
  #define WINT_TYPE_SIZE WCHAR_TYPE_SIZE
  #undef WINT_TYPE
-#define WINT_TYPE WCHAR_TYPE
+#define WINT_TYPE "wchar_t"
  
  /* -- Debug and unwind info formats --  */
  

RE: 3D Printing Software - Gcc

[Zoe Smith via Gcc-patches]

Hello ,

Hope you're doing good.

I'm writing to thank you for your time and kindly let me know your thoughts on 
below email, so that I can revert you with the more information on the same.

Regards,
Zoe Smith

From: Zoe Smith
Sent: 15 February 2023 09:25 AM
To: Gcc 
Subject: 3D Printing Software - Gcc
Importance: High


Hello  Gcc ,



Hope You are doing well!



I Quickly wanted to understand if would you be interested in reaching out for 
the mailing list of " 3D Printing Software" Users, Clients & Customers across 
the world?



We also have the data list of below mentioned users:



ü  Fusion 360.

ü  SOLIDWORKS.

ü  Onshape.

ü  Tinkercad.

ü  Solid Edge.

ü  Siemens NX.

ü  Blender.

ü  Ultimaker Cura



Send me your target users and geographical location, so that I can give count 
and pricing details for your review.



Hence, I am sure this can increase your resources and also connect you to the 
right people in a quick and easier manner.



Appreciate your time and look forward to hear from you.



Thanks & Best regards,

Zoe Smith |Demand Generation Manager



   If you do not wish to hear from us again, please respond back with "Cancel" 
and we will honour your request.

[PATCH] rs6000: fmr gets used instead of faster xxlor [PR93571]

[Ajit Agarwal via Gcc-patches]

Hello All:

This patch replaces fmr instruction (6 cycles) with xxlor instruction ( 2 
cycles)
Bootstrapped and regtested on powerpc64-linux-gnu.

copyright assignment form is still in the process of being sent.
 
Thanks & Regards
Ajit

rs6000: fmr gets used instead of faster xxlor [PR93571]

This patch replaces 6 cycles fmr instruction with xxlor
2 cycles.

2023-02-17  Ajit Kumar Agarwal  

gcc/ChangeLog:

* config/rs6000/rs6000.md (*movdf_hardfloat64): Replace fmr with xxlor 
instruction.
---
 gcc/config/rs6000/rs6000.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 4a7812fa592..dfd6c73ffcb 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -8436,7 +8436,7 @@
   "@
stfd%U0%X0 %1,%0
lfd%U1%X1 %0,%1
-   fmr %0,%1
+   xxlor %0,%1,%1
lxsd %0,%1
stxsd %1,%0
lxsdx %x0,%y1
-- 
2.31.1

[PATCH] i386: Generate QImode binary ops with high-part input register [PR108831]

[Uros Bizjak via Gcc-patches]

Following testcase:

--cut here--
struct S
{
  unsigned char pad1;
  unsigned char val;
  unsigned short pad2;
};

unsigned char
test_add (unsigned char a, struct S b)
{
  a += b.val;

  return a;
}
--cut here--

should be compiled to something like:

addb %dh, %al

but is currently compiled to:

movzbl  %dh, %edx
addl%edx, %eax

The patch implements insn patterns that model QImode binary ops with
high-part QImode input register.  These ops can not be encoded with
REX prefix, so only Q registers and constant memory output operands
are allowed on x86_64 targets.

2023-02-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/108831
* config/i386/predicates.md
(nonimm_x64constmem_operand): New predicate.
* config/i386/i386.md (*addqi_ext_0): New insn pattern.
(*subqi_ext_0): Ditto.
(*andqi_ext_0): Ditto.
(*qi_ext_0): Ditto.

gcc/testsuite/ChangeLog:

PR target/108831
* gcc.target/i386/pr108831-1.c: New test.
* gcc.target/i386/pr108831-2.c: Ditto.

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

Pushed to master.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 198f06e0769..55042e7ae15 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -6641,6 +6641,22 @@ (define_insn "*add_5"
(const_string "*")))
(set_attr "mode" "")])
 
+(define_insn "*addqi_ext_0"
+  [(set (match_operand:QI 0 "nonimm_x64constmem_operand" "=QBc,m")
+   (plus:QI
+ (subreg:QI
+   (zero_extract:SWI248
+ (match_operand 2 "int248_register_operand" "Q,Q")
+ (const_int 8)
+ (const_int 8)) 0)
+ (match_operand:QI 1 "nonimm_x64constmem_operand" "0,0")))
+   (clobber (reg:CC FLAGS_REG))]
+  ""
+  "add{b}\t{%h2, %0|%0, %h2}"
+  [(set_attr "isa" "*,nox64")
+   (set_attr "type" "alu")
+   (set_attr "mode" "QI")])
+
 (define_expand "addqi_ext_1"
   [(parallel
  [(set (zero_extract:HI (match_operand:HI 0 "register_operand")
@@ -7265,6 +7281,22 @@ (define_insn "*subsi_2_zext"
   [(set_attr "type" "alu")
(set_attr "mode" "SI")])
 
+(define_insn "*subqi_ext_0"
+  [(set (match_operand:QI 0 "nonimm_x64constmem_operand" "=QBc,m")
+   (minus:QI
+ (match_operand:QI 1 "nonimm_x64constmem_operand" "0,0")
+ (subreg:QI
+   (zero_extract:SWI248
+ (match_operand 2 "int248_register_operand" "Q,Q")
+ (const_int 8)
+ (const_int 8)) 0)))
+   (clobber (reg:CC FLAGS_REG))]
+  ""
+  "sub{b}\t{%h2, %0|%0, %h2}"
+  [(set_attr "isa" "*,nox64")
+   (set_attr "type" "alu")
+   (set_attr "mode" "QI")])
+
 (define_insn "*subqi_ext_2"
   [(set (zero_extract:SWI248
  (match_operand 0 "int248_register_operand" "+Q")
@@ -10528,6 +10560,22 @@ (define_insn "*and_2"
   [(set_attr "type" "alu")
(set_attr "mode" "")])
 
+(define_insn "*andqi_ext_0"
+  [(set (match_operand:QI 0 "nonimm_x64constmem_operand" "=QBc,m")
+   (and:QI
+ (subreg:QI
+   (zero_extract:SWI248
+ (match_operand 2 "int248_register_operand" "Q,Q")
+ (const_int 8)
+ (const_int 8)) 0)
+ (match_operand:QI 1 "nonimm_x64constmem_operand" "0,0")))
+   (clobber (reg:CC FLAGS_REG))]
+  ""
+  "and{b}\t{%h2, %0|%0, %h2}"
+  [(set_attr "isa" "*,nox64")
+   (set_attr "type" "alu")
+   (set_attr "mode" "QI")])
+
 (define_expand "andqi_ext_1"
   [(parallel
  [(set (zero_extract:HI (match_operand:HI 0 "register_operand")
@@ -11269,6 +11317,22 @@ (define_insn "*_3"
   [(set_attr "type" "alu")
(set_attr "mode" "")])
 
+(define_insn "*qi_ext_0"
+  [(set (match_operand:QI 0 "nonimm_x64constmem_operand" "=QBc,m")
+   (any_or:QI
+ (subreg:QI
+   (zero_extract:SWI248
+ (match_operand 2 "int248_register_operand" "Q,Q")
+ (const_int 8)
+ (const_int 8)) 0)
+ (match_operand:QI 1 "nonimm_x64constmem_operand" "0,0")))
+   (clobber (reg:CC FLAGS_REG))]
+  ""
+  "{b}\t{%h2, %0|%0, %h2}"
+  [(set_attr "isa" "*,nox64")
+   (set_attr "type" "alu")
+   (set_attr "mode" "QI")])
+
 (define_insn "*qi_ext_1"
   [(set (zero_extract:SWI248
  (match_operand 0 "int248_register_operand" "+Q,Q")
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 2f079a6fad8..7b3db0cc851 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -109,6 +109,13 @@ (define_special_predicate "int_nonimmediate_operand"
(match_test "GET_MODE (op) == HImode")
(match_test "GET_MODE (op) == QImode"
 
+;; Match nonimmediate operand, but exclude non-constant addresses for x86_64.
+(define_predicate "nonimm_x64constmem_operand"
+  (ior (match_operand 0 "register_operand")
+   (and (match_operand 0 "memory_operand")
+   (ior (not (match_test "TARGET_64BIT"))
+(match_test "constant_address_p (XEXP (op, 0))")
+
 ;; Match register operands, but include memory operands for 

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

[Steve Kargl via Gcc-patches]

On Fri, Feb 17, 2023 at 12:13:52PM +0100, Tobias Burnus wrote:
> Short version:
> 
> This fixes potential and real bugs related to 'len=:' character variables
> as for the length/byte size an old/saved expression is used instead of
> the current value. - That's fine but not for allocatable/pointer with 'len=:'.
> 
> 
> Main part of the patch: Strip the SAVE_EXPR from the size expression:
> 
>   if (len && deferred && TREE_CODE (TYPE_SIZE (type)) == SAVE_EXPR)
> {
>   gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (type)) == SAVE_EXPR);
>   TYPE_SIZE (type) = TREE_OPERAND (TYPE_SIZE (type), 0);
>   TYPE_SIZE_UNIT (type) = TREE_OPERAND (TYPE_SIZE_UNIT (type), 0);
> }
> 
> 
> OK for mainline?

Short version: no.

> 
> * * *
> 
> Long version:
> 
> BACKGROUND:
> 
> 
> (A) VLA / EXPLICIT-SIZE ARRAYS + LEN= STRINGS
> 
> 
> C knows something like VLA (variable length arrays), likewise Fortran
> knows explicit size array and character length where the length/size
> depends on an variable set before the current scoping unit. Examples:
> 
> void f(int N)
> {
>   int vla[N*5];
> }
> 
> subroutine foo(n)
>   integer :: n
>   integer :: array(n*5)
>   integer :: my_len
>   ...
>   my_len = 5
>   block
> character(len=my_len, kind=4) :: str
> 
> my_len = 99
> print *, len(str)  ! still shows 5 - not 99
>   end block
> end

Are you sure about the above comment?  At the time 
that str is declared, it is given a kind type parameter
of len=5 and kind=4.  After changing my_len to 99
the kind type parameter of str does not change.


8.3 Automatic data objects

If a type parameter in a declaration-type-spec or in a char-length
in an entity-decl for a local variable of a subprogram or BLOCK
construct is defined by an expression that is not a constant
expression, the type parameter value is established on entry to a
procedure defined by the subprogram, or on execution of the BLOCK
statement, and is not affected by any redefinition or undefinition
of the variables in the expression during execution of the
procedure or BLOCK construct.

-- 
steve

Re: [PATCH] simplify-rtx: Fix VOIDmode operand handling in simplify_subreg [PR108805]

[Uros Bizjak via Gcc-patches]

On Fri, Feb 17, 2023 at 12:31 PM Richard Biener  wrote:
>
> On Fri, 17 Feb 2023, Uros Bizjak wrote:
>
> > On Fri, Feb 17, 2023 at 8:38 AM Richard Biener  wrote:
> > >
> > > On Thu, 16 Feb 2023, Uros Bizjak wrote:
> > >
> > > > simplify_subreg can return VOIDmode const_int operand and will
> > > > cause ICE in simplify_gen_subreg when this operand is passed to it.
> > > >
> > > > The patch prevents VOIDmode temporary from entering simplify_gen_subreg.
> > > > We can't process const_int operand any further, since outermode
> > > > is not an integer mode here.
> > >
> > > But if it's a CONST_INT then we know it's of int_outermode, no? That is,
> > > doesn't simplify_subreg (mode, ...) always return something in 'mode'
> > > and thus we can always pass just 'mode' as third argument to the
> > > following simplify_gen_subreg call?
> >
> > You are right. I am testing the attached patch that works too.
>
> OK if that works.

Thanks, pushed with the following ChangeLog:

simplify-rtx: Fix VOIDmode operand handling in simplify_subreg [PR108805]

simplify_subreg can return VOIDmode const_int operand and will
cause ICE in simplify_gen_subreg when this operand is passed to it.

The patch uses int_outermode instead of GET_MODE of temporary as the
innermode argument of simplify_gen_subreg.

2023-02-17  Uroš Bizjak  

gcc/ChangeLog:

PR target/108805
* simplify_rtx.cc (simplify_context::simplify_subreg): Use
int_outermode instead of GET_MODE (tem) to prevent
VOIDmode from entering simplify_gen_subreg.

Uros.


gcc/testsuite/ChangeLog:

PR target/108805
* gcc.dg/pr108805.c: New test.

Uros.

Re: [PATCH] diagnostics: fix crash with -fdiagnostics-format=json-file

[Martin Liška]

PING^3

On 2/1/23 14:13, Martin Liška wrote:
> PING^2
> 
> On 1/24/23 14:34, Martin Liška wrote:
>> PING^1
>>
>> On 1/10/23 16:10, Martin Liška wrote:
>>> On 1/6/23 14:21, David Malcolm wrote:
 On Fri, 2023-01-06 at 12:33 +0100, Martin Liška wrote:
> Patch can bootstrap on x86_64-linux-gnu and survives regression
> tests.

 Thanks for the patch.

 I noticed that you marked PR 108307 as a dup of this, which covers
 -fdiagnostics-format=sarif-file (and a .S file as input).

 The patch doesn't add any test coverage (for either of the diagnostic
 formats).

 If we try to emit a diagnostic and base_file_name is NULL, and the user
 requested one of -fdiagnostics-format={json,sarif}-file, where do the
 diagnostics go?  Where should they go?
>>>
>>> Hey.
>>>
>>> I've done a new version of the patch where I utilize x_main_input_basename.
>>>
>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>>
>>> Ready to be installed?
>>> Thanks,
>>> Martin
>>
> 

Re: [PING] Re: [PATCH 2/2] Corrected pr25521.c target matching.

[Cupertino Miranda via Gcc-patches]

PING !

Cupertino Miranda via Gcc-patches writes:

> Hi Jeff,
>
> Can you please confirm if the patch is Ok?
>
> Thanks,
> Cupertino
>
>> Cupertino Miranda via Gcc-patches writes:
>>
>>> Thank you for the comments and suggestions.
>>> I have changed the patch.
>>>
>>> Unfortunately in case of rx target I could not make
>>> scan-assembler-symbol-section to match. I believe it is because the
>>> .section and .global entries order is reversed in this target.
>>>
>>> Patch in inlined below. looking forward to your comments.
>>>
>>> Cupertino
>>>
>>> diff --git a/gcc/testsuite/gcc.dg/pr25521.c b/gcc/testsuite/gcc.dg/pr25521.c
>>> index 63363a03b9f..82b4cd88ec0 100644
>>> --- a/gcc/testsuite/gcc.dg/pr25521.c
>>> +++ b/gcc/testsuite/gcc.dg/pr25521.c
>>> @@ -2,9 +2,10 @@
>>> sections.
>>>
>>> { dg-require-effective-target elf }
>>> -   { dg-do compile } */
>>> +   { dg-do compile }
>>> +   { dg-skip-if "" { ! const_volatile_readonly_section } } */
>>>
>>>  const volatile int foo = 30;
>>>
>>> -
>>> -/* { dg-final { scan-assembler "\\.s\?rodata" } } */
>>> +/* { dg-final { scan-assembler {.section C,} { target { rx-*-* } } } } */
>>> +/* { dg-final { scan-assembler-symbol-section {^_?foo$} 
>>> {^\.(const|s?rodata)} { target { ! "rx-*-*" } } } } */
>>> diff --git a/gcc/testsuite/lib/target-supports.exp 
>>> b/gcc/testsuite/lib/target-supports.exp
>>> index c0694af2338..91aafd89909 100644
>>> --- a/gcc/testsuite/lib/target-supports.exp
>>> +++ b/gcc/testsuite/lib/target-supports.exp
>>> @@ -12295,3 +12295,13 @@ proc check_is_prog_name_available { prog } {
>>>
>>>  return 1
>>>  }
>>> +
>>> +# returns 1 if target does selects a readonly section for const volatile 
>>> variables.
>>> +proc check_effective_target_const_volatile_readonly_section { } {
>>> +
>>> +if { [istarget powerpc-*-*]
>>> + || [check-flags { "" { powerpc64-*-* } { -m32 } }] } {
>>> +   return 0
>>> +}
>>> +  return 1
>>> +}
>>>
>>>
>>> Jeff Law writes:
>>>
 On 12/7/22 08:45, Cupertino Miranda wrote:
>
>> On 12/2/22 10:52, Cupertino Miranda via Gcc-patches wrote:
>>> This commit is a follow up of bugzilla #107181.
>>> The commit /a0aafbc/ changed the default implementation of the
>>> SELECT_SECTION hook in order to match clang/llvm behaviour w.r.t the
>>> placement of `const volatile' objects.
>>> However, the following targets use target-specific selection functions
>>> and they choke on the testcase pr25521.c:
>>>*rx - target sets its const variables as '.section C,"a",@progbits'.
>> That's presumably a constant section.  We should instead twiddle the 
>> test to
>> recognize that section.
> Although @progbits is indeed a constant section, I believe it is
> more interesting to detect if the `rx' starts selecting more
> standard sections instead of the current @progbits.
> That was the reason why I opted to XFAIL instead of PASSing it.
> Can I keep it as such ?
 I'm not aware of any ongoing development for that port, so I would not let
 concerns about the rx port changing behavior dominate how we approach this
 problem.

 The rx port is using a different name for the section.  That's  valid 
 thing to
 do and to the extent we can, we should support that in the test rather than
 (incorrectly IMHO) xfailing the test just becuase the name isn't what we
 expected.

 To avoid over-eagerly matching, I would probably search for "C,"  I 
 wouldn't do
 that for the const or rodata sections as they often have a suffix like 1, 
 2, 4,
 8 for different sized rodata sections.

 PPC32 is explicitly doing something different and placing those objects 
 into an
 RW section.  So for PPC32 it makes more sense to skip the test rather than 
 xfail
 it.

 Jeff

RISC-V: Add divmod instruction support

[Matevos Mehrabyan via Gcc-patches]

Hi all,
If we have division and remainder calculations with the same operands:

  a = b / c;
  d = b % c;

We can replace the calculation of remainder with multiplication +
subtraction, using the result from the previous division:

  a = b / c;
  d = a * c;
  d = b - d;

Which will be faster.
Currently, it isn't done for RISC-V.

I've added an expander for DIVMOD which replaces 'rem' with 'mul + sub'.

Best regards,
Matevos.

gcc/ChangeLog:

* config/riscv/riscv.md: Added divmod expander.

gcc/testsuite/ChangeLog:
* gcc.target/riscv/divmod.c: New testcase.

--- inline copy of the patch ---

diff --git a/gcc/config/riscv/iterators.md b/gcc/config/riscv/iterators.md
index f95dd405e12..d941483d9f1 100644
--- a/gcc/config/riscv/iterators.md
+++ b/gcc/config/riscv/iterators.md
@@ -148,6 +148,11 @@
 ;; from the same template.
 (define_code_iterator any_mod [mod umod])

+;; These code iterators allow unsigned and signed divmod to be generated
+;; from the same template.
+(define_code_iterator only_div [div udiv])
+(define_code_attr paired_mod [(div "mod") (udiv "umod")])
+
 ;; These code iterators allow the signed and unsigned scc operations to use
 ;; the same template.
 (define_code_iterator any_gt [gt gtu])
@@ -175,7 +180,8 @@
  (gt "") (gtu "u")
  (ge "") (geu "u")
  (lt "") (ltu "u")
- (le "") (leu "u")])
+ (le "") (leu "u")
+ (div "") (udiv "u")])

 ;;  is like , but the signed form expands to "s" rather than "".
 (define_code_attr su [(sign_extend "s") (zero_extend "u")])
diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index c8adc5af5d2..2d48ff3f8de 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -1044,6 +1044,22 @@
   [(set_attr "type" "idiv")
(set_attr "mode" "DI")])

+(define_expand "divmod4"
+  [(parallel
+ [(set (match_operand:GPR 0 "register_operand")
+   (only_div:GPR (match_operand:GPR 1 "register_operand")
+ (match_operand:GPR 2 "register_operand")))
+  (set (match_operand:GPR 3 "register_operand")
+   (:GPR (match_dup 1) (match_dup 2)))])]
+  "TARGET_DIV"
+  {
+  rtx tmp = gen_reg_rtx (mode);
+  emit_insn (gen_div3 (operands[0], operands[1],
operands[2]));
+  emit_insn (gen_mul3 (tmp, operands[0], operands[2]));
+  emit_insn (gen_sub3 (operands[3], operands[1], tmp));
+  DONE;
+  })
+
 (define_insn "*si3_extended"
   [(set (match_operand:DI 0 "register_operand" "=r")
  (sign_extend:DI
diff --git a/gcc/testsuite/gcc.target/riscv/divmod.c
b/gcc/testsuite/gcc.target/riscv/divmod.c
new file mode 100644
index 000..254b25e654d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/divmod.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-O1" "-Og" } } */
+
+void
+foo(int a, int b, int *c, int *d)
+{
+   *c = a / b;
+   *d = a % b;
+}
+
+/* { dg-final { scan-assembler-not "rem" } } */
+/* { dg-final { scan-assembler-times "mul" 1 } } */
+/* { dg-final { scan-assembler-times "sub" 1 } } */

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

[Qing Zhao via Gcc-patches]

Ping…

Qing

> On Feb 10, 2023, at 7:50 PM, Qing Zhao  wrote:
> 
> on structure with C99 flexible array member being nested in another structure.
> 
> This is also fixed PR77650.
> 
> " GCC extension accepts a structure containing a ISO C99 "flexible array
> member", or a union containing such a structure (possibly recursively)
> to be a member of a structure.
> 
> There are three situations:
> 
>   * The structure with a C99 flexible array member is the last field of
> another structure, for example:
> 
>  struct flex  { int length; char data[]; };
> 
>  struct out_flex { int m; struct flex flex_data; };
> 
> In the above, 'flex_data.data[]' is considered as a flexible array
> too.
> 
>   * The structure with a C99 flexible array member is the field of
> another union, for example:
> 
>  struct flex1  { int length1; char data1[]; }
>  struct flex2  { int length2; char data2[]; }
> 
>  union out_flex { struct flex1 flex_data1; struct flex2 flex_data2; }
> 
> In the above, 'flex_data1.data1[]' or 'flex_data2.data2[]' is
> considered as flexible arrays too.
> 
>   * The structure with a C99 flexible array member is the middle field
> of another structure, for example:
> 
>  struct flex  { int length; char data[]; };
> 
>  struct mid_flex { int m; struct flex flex_data; int n; };
> 
> In the above, 'flex_data.data[]' is allowed to be extended flexibly
> to the padding.  E.g, up to 4 elements.
> 
> However, relying on space in struct padding is a bad programming
> practice, compilers do not handle such extension consistently, Any
> code relying on this behavior should be modified to ensure that
> flexible array members only end up at the ends of structures.
> 
> Please use warning option '-Wgnu-variable-sized-type-not-at-end' to
> identify all such cases in the source code and modify them.  This
> extension will be deprecated from gcc in the next release. "
> 
> gcc/c-family/ChangeLog:
> 
>   PR c/77650
>   * c.opt: New option -Wgnu-variable-sized-type-not-at-end.
> 
> gcc/c/ChangeLog:
> 
>   PR c/77650
>   * c-decl.cc (finish_struct): Issue warnings for new option.
> 
> gcc/ChangeLog:
> 
>   PR c/77650
>   * doc/extend.texi: Document GCC extension on a structure containing
>   a flexible array member to be a member of another structure.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c/77650
>   * gcc.dg/variable-sized-type-flex-array.c: New test.
> ---
> gcc/c-family/c.opt|  5 ++
> gcc/c/c-decl.cc   |  7 +++
> gcc/doc/extend.texi   | 58 ++-
> .../gcc.dg/variable-sized-type-flex-array.c   | 31 ++
> 4 files changed, 100 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.dg/variable-sized-type-flex-array.c
> 
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index c0fea56a8f5..fd720538800 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -737,6 +737,11 @@ Wformat-truncation=
> C ObjC C++ LTO ObjC++ Joined RejectNegative UInteger Var(warn_format_trunc) 
> Warning LangEnabledBy(C ObjC C++ LTO ObjC++,Wformat=, warn_format >= 1, 0) 
> IntegerRange(0, 2)
> Warn about calls to snprintf and similar functions that truncate output.
> 
> +Wgnu-variable-sized-type-not-at-end
> +C C++ Var(warn_variable_sized_type_not_at_end) Warning
> +Warn about structures or unions with C99 flexible array members are not
> +at the end of a structure.
> +
> Wif-not-aligned
> C ObjC C++ ObjC++ Var(warn_if_not_aligned) Init(1) Warning
> Warn when the field in a struct is not aligned.
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index 741a37560b0..041df4355da 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -9289,6 +9289,13 @@ finish_struct (location_t loc, tree t, tree fieldlist, 
> tree attributes,
>  && is_last_field)
>   TYPE_INCLUDE_FLEXARRAY (t) = true;
> 
> +  if (warn_variable_sized_type_not_at_end
> +   && !is_last_field
> +   && TYPE_INCLUDE_FLEXARRAY (TREE_TYPE (x)))
> + warning_at (DECL_SOURCE_LOCATION (x),
> + OPT_Wgnu_variable_sized_type_not_at_end,
> + "variable sized type not at the end of a struct");
> +
>   if (DECL_NAME (x)
> || RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)))
>   saw_named_field = true;
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 5a026c4b48c..737228b35ac 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -1748,7 +1748,63 @@ Flexible array members may only appear as the last 
> member of a
> A structure containing a flexible array member, or a union containing
> such a structure (possibly recursively), may not be a member of a
> structure or an element of an array.  (However, these uses are
> -permitted by GCC as extensions.)
> +permitted by GCC as extensions, see details below.)
> +@end itemize

Re: [v3][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

[Qing Zhao via Gcc-patches]

Ping…

Qing

> On Feb 10, 2023, at 7:50 PM, Qing Zhao  wrote:
> 
> GCC extension accepts the case when a struct with a C99 flexible array member
> is embedded into another struct or union (possibly recursively).
> __builtin_object_size should treat such struct as flexible size.
> 
> gcc/c/ChangeLog:
> 
>   PR tree-optimization/101832
>   * c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for
>   struct/union type.
> 
> gcc/cp/ChangeLog:
> 
>   PR tree-optimization/101832
>   * module.cc (trees_out::core_bools): Stream out new bit
>   type_include_flexarray.
>   (trees_in::core_bools): Stream in new bit type_include_flexarray.
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/101832
>   * print-tree.cc (print_node): Print new bit type_include_flexarray.
>   * tree-core.h (struct tree_type_common): New bit
>   type_include_flexarray.
>   * tree-object-size.cc (addr_object_size): Handle structure/union type
>   when it has flexible size.
>   * tree-streamer-in.cc (unpack_ts_type_common_value_fields): Stream
>   in new bit type_include_flexarray.
>   * tree-streamer-out.cc (pack_ts_type_common_value_fields): Stream
>   out new bit type_include_flexarray.
>   * tree.h (TYPE_INCLUDE_FLEXARRAY): New macro
>   TYPE_INCLUDE_FLEXARRAY.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/101832
>   * gcc.dg/builtin-object-size-pr101832.c: New test.
> ---
> gcc/c/c-decl.cc   |  12 ++
> gcc/cp/module.cc  |   2 +
> gcc/print-tree.cc |   5 +
> .../gcc.dg/builtin-object-size-pr101832.c | 134 ++
> gcc/tree-core.h   |   4 +-
> gcc/tree-object-size.cc   |  79 +++
> gcc/tree-streamer-in.cc   |   1 +
> gcc/tree-streamer-out.cc  |   1 +
> gcc/tree.h|   6 +
> 9 files changed, 215 insertions(+), 29 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
> 
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index 20e7d1855bf..741a37560b0 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -9277,6 +9277,18 @@ finish_struct (location_t loc, tree t, tree fieldlist, 
> tree attributes,
>   /* Set DECL_NOT_FLEXARRAY flag for FIELD_DECL x.  */
>   DECL_NOT_FLEXARRAY (x) = !is_flexible_array_member_p (is_last_field, x);
> 
> +  /* Set TYPE_INCLUDE_FLEXARRAY for the context of x, t
> +   * when x is an array.  */
> +  if (TREE_CODE (TREE_TYPE (x)) == ARRAY_TYPE)
> + TYPE_INCLUDE_FLEXARRAY (t) = flexible_array_member_type_p (TREE_TYPE 
> (x)) ;
> +  /* Recursively set TYPE_INCLUDE_FLEXARRAY for the context of x, t
> +  when x is the last field.  */
> +  else if ((TREE_CODE (TREE_TYPE (x)) == RECORD_TYPE
> + || TREE_CODE (TREE_TYPE (x)) == UNION_TYPE)
> +&& TYPE_INCLUDE_FLEXARRAY (TREE_TYPE (x))
> +&& is_last_field)
> + TYPE_INCLUDE_FLEXARRAY (t) = true;
> +
>   if (DECL_NAME (x)
> || RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)))
>   saw_named_field = true;
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index ac2fe66b080..c750361b704 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -5371,6 +5371,7 @@ trees_out::core_bools (tree t)
>   WB (t->type_common.lang_flag_5);
>   WB (t->type_common.lang_flag_6);
>   WB (t->type_common.typeless_storage);
> +  WB (t->type_common.type_include_flexarray);
> }
> 
>   if (CODE_CONTAINS_STRUCT (code, TS_DECL_COMMON))
> @@ -5551,6 +5552,7 @@ trees_in::core_bools (tree t)
>   RB (t->type_common.lang_flag_5);
>   RB (t->type_common.lang_flag_6);
>   RB (t->type_common.typeless_storage);
> +  RB (t->type_common.type_include_flexarray);
> }
> 
>   if (CODE_CONTAINS_STRUCT (code, TS_DECL_COMMON))
> diff --git a/gcc/print-tree.cc b/gcc/print-tree.cc
> index 1f3afcbbc86..efacdb7686f 100644
> --- a/gcc/print-tree.cc
> +++ b/gcc/print-tree.cc
> @@ -631,6 +631,11 @@ print_node (FILE *file, const char *prefix, tree node, 
> int indent,
> && TYPE_CXX_ODR_P (node))
>   fputs (" cxx-odr-p", file);
> 
> +  if ((code == RECORD_TYPE
> +|| code == UNION_TYPE)
> +   && TYPE_INCLUDE_FLEXARRAY (node))
> + fputs (" include-flexarray", file);
> +
>   /* The transparent-union flag is used for different things in
>different nodes.  */
>   if ((code == UNION_TYPE || code == RECORD_TYPE)
> diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c 
> b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
> new file mode 100644
> index 000..60078e11634
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
> @@ -0,0 +1,134 @@
> +/* PR 101832: 
> +   GCC extension accepts the case when a struct with a C99 flexible array
> +   member is embedded into 

Re: [v3][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

[Qing Zhao via Gcc-patches]

Ping…

Qing

> On Feb 10, 2023, at 7:50 PM, Qing Zhao  wrote:
> 
> These are the 3rd version of the patches for PR101832, to fix
> builtin_object_size to correctly handle component_ref to a
> structure/union field that includes a flexible array member.
> 
> also includes a documentation update for the GCC extension on embedding
> a structure/union with flexible array member into another structure.
> which includes a fix to PR77650.
> 
> compared to the 2nd version of the patch, the major changes are:
> 1. only include C99 flexible array member to this extension, trailing [0], [1]
>   and [4] are all excluded.
> 2. for the new bit type_include_flexarray in tree_type_common, print it
>   and also stream in/out it. 
> 3. update testing cases.
> 4. more clarification on the documentation. warnings for deprecating the 
>   case when the structure with C99 FAM is embedded in the middle of
>   another structure. 
> 5. add a new warning option -Wgnu-variable-sized-type-not-at-end for
>   identifing all such cases.
> 
> bootstrapped and regression tested on aarch64 and x86.
> 
> Okay for commit?
> 
> thanks.
> 
> Qing
> 

[PATCH] doc: Fix typo in -Wall description

[Siddhesh Poyarekar]

-Wall enables -Wuse-after-free=2 and not -Wuse-after-free=3.

gcc/ChangeLog:

* gcc/doc/invoke.texi (@item -Wall): Fix typo in
-Wuse-after-free.

Signed-off-by: Siddhesh Poyarekar 
---
 gcc/doc/invoke.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 51447a78584..20d41e19b3c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -6083,7 +6083,7 @@ Options} and @ref{Objective-C and Objective-C++ Dialect 
Options}.
 -Wunused-label @gol
 -Wunused-value @gol
 -Wunused-variable  @gol
--Wuse-after-free=3  @gol
+-Wuse-after-free=2  @gol
 -Wvla-parameter @r{(C and Objective-C only)} @gol
 -Wvolatile-register-var  @gol
 -Wzero-length-bounds}
-- 
2.38.1

Re: [PR100127] Test for coroutine header in clang-compatible tests

[Iain Sandoe]

Hi,

> On 17 Feb 2023, at 06:42, Alexandre Oliva via Gcc-patches 
>  wrote:
> 
> 
> The test is compatible with clang as well as gcc, but ISTM that
> testing for the __clang__ macro is just as potentially error-prone as
> macros that used to be GCC-specific are now defined in compilers that
> aim for GCC compatibility.

It remains useful to be able to check tests on both compilers.

As a matter of interest, do you know of any other compiler claiming “__clang__” 
(I have
treated that as safe so far).

>  Use a __has_include feature test instead.

I think we need to do

#if __has_include()
…
#elif __has_include()
…

because newer clang has the include in the standard place.
Iain

> 
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?
> 
> for  gcc/testsuite/ChangeLog
> 
>   PR c++/100127
>   * g++.dg/coroutines/pr100127.C: Test for header rather than
>   compiler macro.
> ---
> gcc/testsuite/g++.dg/coroutines/pr100127.C   |2 +-
> gcc/testsuite/g++.dg/coroutines/pr100772-a.C |2 +-
> gcc/testsuite/g++.dg/coroutines/pr100772-b.C |2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/testsuite/g++.dg/coroutines/pr100127.C 
> b/gcc/testsuite/g++.dg/coroutines/pr100127.C
> index 374cd710077af..1eaa72ff0acdd 100644
> --- a/gcc/testsuite/g++.dg/coroutines/pr100127.C
> +++ b/gcc/testsuite/g++.dg/coroutines/pr100127.C
> @@ -1,4 +1,4 @@
> -#ifdef __clang__
> +#if __has_include() // for __clang__
> #include 
> namespace std {
>   using namespace std::experimental;
> diff --git a/gcc/testsuite/g++.dg/coroutines/pr100772-a.C 
> b/gcc/testsuite/g++.dg/coroutines/pr100772-a.C
> index a325d384fc390..724c377c82e5b 100644
> --- a/gcc/testsuite/g++.dg/coroutines/pr100772-a.C
> +++ b/gcc/testsuite/g++.dg/coroutines/pr100772-a.C
> @@ -1,5 +1,5 @@
> //  { dg-additional-options "-fsyntax-only " }
> -#ifdef __clang__
> +#if __has_include() // for __clang__
> #include 
> namespace std {
>   using namespace std::experimental;
> diff --git a/gcc/testsuite/g++.dg/coroutines/pr100772-b.C 
> b/gcc/testsuite/g++.dg/coroutines/pr100772-b.C
> index 6cdf8d1e529e5..4cf31e5f9e0c2 100644
> --- a/gcc/testsuite/g++.dg/coroutines/pr100772-b.C
> +++ b/gcc/testsuite/g++.dg/coroutines/pr100772-b.C
> @@ -1,4 +1,4 @@
> -#ifdef __clang__
> +#if __has_include() // for __clang__
> #include 
> namespace std {
>   using namespace std::experimental;
> 
> -- 
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>   Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

Re: [PATCH] [PR77760] [libstdc++] encode __time_get_state in tm

[Jakub Jelinek via Gcc-patches]

On Fri, Feb 17, 2023 at 04:47:45AM -0300, Alexandre Oliva wrote:
> 
> On platforms that fail the ptrtomemfn-cast-to-pfn hack, such as
> arm-*-vxworks*, time_get fails with %I and %p because the state is not
> preserved across do_get calls.
> 
> This patch introduces an alternate hack, that encodes the state in
> unused bits of struct tm before calling do_get, extracts them in
> do_get, does the processing, and encodes it back, so that get extracts
> it.
> 
> The finalizer is adjusted for idempotence, because both do_get and get
> may call it.

As I said in the PR, I'm worried about this approach, but Jonathan
is the expert on the standard...
My worry is that people often invoke the time_get APIs on uninitialized
struct tm.
https://eel.is/c++draft/locale.time.get#general-1 says that corresponding
members of the struct tm are set, in the past we used to set mostly just
a single tm_* for ultimate format specifiers, with the addition of state
we try to set some further ones as well in the spirit of what strptime
does in glibc.  But still, say if the format specifiers only mention
hours/minutes/seconds, we don't try to update year/day/month related stuff
and vice versa.  Or say minute format specifier will only update tm_min
and nothing else.
For the encoding in get, the questions are:
1) if it is ok if we clear some normally unused bits of certain tm_*
   fields even if they wouldn't be otherwise touched; perhaps nothing
   will care, but it is still a user visible change
2) when those tm_* fields we want to encode the state into are unitialized,
   don't we effectively invoke UB by using the uninitialized member
   (admittedly we just overwrite some bits in it and leave others as is,
   but won't that e.g. cause -Wuninitialized warnings)?
More importantly, in the do_get the questions are:
3) while do_get is protected, are we guaranteed that it will never be called
   except from the public members of time_get?  I mean, if we are called
   from the libstdc++ time_get::get, then there is a state and it is already
   encoded in struct tm, so those bits are initialized and all is fine;
   but if it is called from elsewhere (either a class derived from
   time_get which just calls do_get alone on uninitialized struct tm,
   or say get in a derived class which calls do_get but doesn't encode the
   state, or even mixing of older GCC compiled get with newer GCC compiled
   do_get - get can be inlined into user code, while do_get is called
   through vtable and so could come up from another shared library), those
   struct tm bits could be effectively random and we'd finalize the state
   on the random stuff
4) I think we even shouldn't __state._M_finalize_state(__tm); in do_get
   if it is nested, then you wouldn't need to tweak src/c++98/locale_facets.cc;
   generally state should be finalized once everything is parsed together,
   not many times in between (of course if user code will parse stuff
   separately that will not work, say get with "%I" in one call, then get
   with "%h" in another one etc., but that is user's decision).  That
   would be another ABI issue, if the _M_finalize_state is called in
   do_get and the containing get calls it as well, then depending on which
   _M_finalize_state is used at runtime it would either cope well with the
   double finalization or not; now, if users never called time_get stuff
   on uninitialized struct tm, we could just add another bit to the state,
   whether the state has been actually encoded there, and call
   _M_finalize_state in do_get only if it hasn't been.

Just curious, why doesn't the pmf hack work on arm-vxworks7?
Sure, clang++ doesn't support it and if one derives a class from time_get
and overrides do_get and/or get things will not work properly either.

Jakub

[COMMITTED] fixincludes: Bypass solaris_math_12 on newer Solaris 11.4

[Rainer Orth]

Solaris 11  long had this snippet

#if __cplusplus >= 201103L
#undef  _GLIBCXX_USE_C99_MATH
#undef  _GLIBCXX_USE_C99_MATH_TR1
#endif

which badly broke libstdc++.  This has long been undone using
fixincludes in

[fixincludes, v3] Don't define libstdc++-internal macros in Solaris 10+ 

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

However, the issue came up again recently when that code broke the LLVM
build, too, which unfortunately doesn't know about GCC's include-fixed
directory.  The issue was reinvestigated and it turned out that the
workaround/hack is only needed for specific old versions of the Sun/Oracle
Studio compilers.  So  now looks like

/* Accommodate historical C++11 -std=c++03 behavior of Studio 12.4 and 12.5 */
#if (__cplusplus >= 201103L) &&  \
((__SUNPRO_CC == 0x5130) || (__SUNPRO_CC == 0x5140) ||  \
 defined(__MATH_PREEMPTS_GLIBCXX_C99_MATH)) 
#ifdef _GLIBCXX_USE_C99_MATH 
#undef _GLIBCXX_USE_C99_MATH
#endif
#ifdef _GLIBCXX_USE_C99_MATH_TR1
#undef _GLIBCXX_USE_C99_MATH_TR1
#endif
#endif

If this change is in place, there's no longer a need for the fixincludes
fix, so this patch bypasses it as appropriate.

Tested on Solaris 11.3 (without the fixed header) and recent 11.4 (with
the fixed header).

Committed to trunk.  I may backport to the gcc-11 and gcc-12 branches,
too.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2022-11-01  Rainer Orth  

fixincludes:
* inclhack.def (solaris_math_12): Add bypass.
* fixincl.x: Regenerate.

# HG changeset patch
# Parent  76f1a1965f9296be97f6edc2b9610d6600036de1
fixincludes: Bypass solaris_math_12 on newer Solaris 11.4

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -4306,6 +4306,7 @@ fix = {
 files = math.h;
 mach  = '*-*-solaris2*';
 select= '#undef.*_GLIBCXX_USE_C99_MATH';
+bypass= '__MATH_PREEMPTS_GLIBCXX_C99_MATH';
 sed   = "/#undef[ \t]*_GLIBCXX_USE_C99_MATH/d";
 test_text = << _EOText_
 #if __cplusplus >= 201103L

[COMMITTED] contrib: Fix make_sunver.pl warning

[Rainer Orth]

Petr informed me that perl 5.32 bundled with Solaris 11.4 warns about
make_sunver.pl:

Unescaped left brace in regex is passed through in regex; marked by <-- HERE in 
m/^([ \t]*){ <-- HERE $/ at 
/vol/gcc/src/hg/master/local/libgomp/../contrib/make_sunver.pl line 216.

I didn't notice since I'm using a common installation of perl 5.12
across Solaris versions that doesn't show that warning.

His patch fixes the issue.  Tested on Solaris 11.3 (perl 5.12) and 11.4
(perl 5.32).

Committed to trunk.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


2023-01-20  Petr Sumbera  

contrib:
* make_sunver.pl: Escape brace.

# HG changeset patch
# Parent  a9c533b97d6828dce4fa8418864a1fa65f5c46b3
contrib: Fix make_sunver.pl warning

diff --git a/contrib/make_sunver.pl b/contrib/make_sunver.pl
--- a/contrib/make_sunver.pl
+++ b/contrib/make_sunver.pl
@@ -213,7 +213,7 @@ while () {
 if (/^[ \t]*$/) { print; next; }
 
 # Lines of the form '{'
-if (/^([ \t]*){$/) {
+if (/^([ \t]*)\{$/) {
 	if ($in_extern) {
 	print "$1##{\n";
 	} else {

[PATCHv2] openmp: Add support for 'present' modifier

[Kwok Cheung Yeung]

Hello

This is a revised version of the patch for the 'present' modifier for 
OpenMP. Compared to the first version, three improvements have been made:


- A bug which caused bootstrapping with a '-m32' multilib on x86-64 to 
fail due to pointer size issues has been fixed.

- The Fortran parse tree dump now shows clauses with 'present' applied.
- The reordering of OpenMP clauses has been moved to 
gimplify_scan_omp_clauses, where the other clause reordering rules are 
applied.


Thanks

KwokFrom 24b6225578bb08bbd745d6ec653aab60802dd220 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Fri, 3 Feb 2023 13:04:21 +
Subject: [PATCH] openmp: Add support for the 'present' modifier

This implements support for the OpenMP 5.1 'present' modifier, which can be
used in map clauses in the 'target', 'target data', 'target data enter' and
'target data exit' constructs, and in the 'to' and 'from' clauses of the
'target update' construct.  It is also supported in defaultmap.

The modifier triggers a fatal runtime error if the data specified by the
clause is not already present on the target device.  It can also be combined
with 'always' in map clauses.

2023-02-01  Kwok Cheung Yeung  

gcc/c/
* c-parser.cc (c_parser_omp_variable_list): Set default motion
modifier.
(c_parser_omp_var_list_parens): Add new parameter with default.  Parse
'present' motion modifier and apply.
(c_parser_omp_clause_defaultmap): Parse 'present' in defaultmap.
(c_parser_omp_clause_map): Parse 'present' modifier in map clauses.
(c_parser_omp_clause_to): Allow use of 'present' in variable list.
(c_parser_omp_clause_from): Likewise.
(c_parser_omp_target_data): Allow map clauses with 'present'
modifiers.
(c_parser_omp_target_enter_data): Likewise.
(c_parser_omp_target_exit_data): Likewise.
(c_parser_omp_target): Likewise.

gcc/cp/
* parser.cc (cp_parser_omp_var_list_no_open): Add new parameter with
default.  Parse 'present' motion modifier and apply.
(cp_parser_omp_clause_defaultmap): Parse 'present' in defaultmap.
(cp_parser_omp_clause_map): Parse 'present' modifier in map clauses.
(cp_parser_omp_all_clauses): Allow use of 'present' in 'to' and 'from'
clauses.
(cp_parser_omp_target_data): Allow map clauses with 'present'
modifiers.
(cp_parser_omp_target_enter_data): Likewise.
(cp_parser_omp_target_exit_data): Likewise.
* semantics.cc (finish_omp_target): Accept map clauses with 'present'
modifiers.

gcc/fortran/
* dump-parse-tree.cc (show_omp_namelist): Display 'present' map
modifier.
(show_omp_clauses): Display 'present' motion modifier for 'to'
and 'from' clauses.
* gfortran.h (enum gfc_omp_map_op): Add entries with 'present'
modifiers.
(enum gfc_omp_motion_modifier): New.
(struct gfc_omp_namelist): Add motion_modifier field.
* openmp.cc (gfc_match_omp_variable_list): Add new parameter with
default.  Parse 'present' motion modifier and apply.
(gfc_match_omp_clauses): Parse 'present' in defaultmap, 'from'
clauses, 'map' clauses and 'to' clauses.
(resolve_omp_clauses): Allow 'present' modifiers on 'target',
'target data', 'target enter' and 'target exit' directives.
* trans-openmp.cc (gfc_trans_omp_clauses): Apply 'present' modifiers
to tree node for 'map', 'to' and 'from' clauses.  Apply 'present' for
defaultmap.

gcc/
* gimplify.cc (omp_notice_variable): Apply GOVD_MAP_ALLOC_ONLY flag
and defaultmap flags if the defaultmap has GOVD_MAP_FORCE_PRESENT flag
set.
(omp_get_attachment): Handle map clauses with 'present' modifier.
(omp_group_base): Likewise.
(gimplify_scan_omp_clauses): Reorder present maps to come first.
Set GOVD flags for present defaultmaps.
(gimplify_adjust_omp_clauses_1): Set map kind for present defaultmaps.
* omp-low.cc (scan_sharing_clauses): Handle 'always, present' map
clauses.
(lower_omp_target): Handle map clauses with 'present' modifier.
Handle 'to' and 'from' clauses with 'present'.
* tree-core.h (enum omp_clause_defaultmap_kind): Add
OMP_CLAUSE_DEFAULTMAP_PRESENT defaultmap kind.
(enum omp_clause_motion_modifier): New.
(struct tree_omp_clause): Add motion_modifier field.
* tree-pretty-print.cc (dump_omp_clause): Handle 'map', 'to' and
'from' clauses with 'present' modifier.  Handle present defaultmap.
* tree.h (OMP_CLAUSE_MOTION_MODIFIER): New.
(OMP_CLAUSE_SET_MOTION_MODIFIER): New.

gcc/testsuite/
* c-c++-common/gomp/defaultmap-4.c: New.
* c-c++-common/gomp/map-6.c: Update expected error messages.
* c-c++-common/gomp/map-8.c: New.
* 

[PATCH] tree-optimization/108821 - store motion and volatiles

[Richard Biener via Gcc-patches]

The following fixes store motion to not re-issue volatile stores
to preserve TBAA behavior since that will result in the number
of volatile accesses changing.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed to trunk.

PR tree-optimization/108821
* tree-ssa-loop-im.cc (sm_seq_valid_bb): We can also not
move volatile accesses.

* gcc.dg/tree-ssa/ssa-lim-24.c: New testcase.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-24.c | 25 ++
 gcc/tree-ssa-loop-im.cc|  4 +++-
 2 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-24.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-24.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-24.c
new file mode 100644
index 000..6b463490a91
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-24.c
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-lim2-details -fdump-tree-optimized" } */
+
+extern volatile int *x;
+static int gCrc;
+
+static int __attribute__((noinline)) crc16Add(int crc, int b)
+{
+  return crc + b;
+}
+
+void f(int data, int dataSz)
+{
+  int i;
+
+  for(i=0;iref == UNANALYZABLE_MEM_ID)
return -1;
   /* Stop at memory references which we can't move.  */
-  else if (memory_accesses.refs_list[data->ref]->mem.ref == 
error_mark_node)
+  else if (memory_accesses.refs_list[data->ref]->mem.ref == error_mark_node
+  || TREE_THIS_VOLATILE
+   (memory_accesses.refs_list[data->ref]->mem.ref))
{
  /* Mark refs_not_in_seq as unsupported.  */
  bitmap_ior_into (refs_not_supported, refs_not_in_seq);
-- 
2.35.3

Re: [PATCH] simplify-rtx: Fix VOIDmode operand handling in simplify_subreg [PR108805]

[Richard Biener via Gcc-patches]

On Fri, 17 Feb 2023, Uros Bizjak wrote:

> On Fri, Feb 17, 2023 at 8:38 AM Richard Biener  wrote:
> >
> > On Thu, 16 Feb 2023, Uros Bizjak wrote:
> >
> > > simplify_subreg can return VOIDmode const_int operand and will
> > > cause ICE in simplify_gen_subreg when this operand is passed to it.
> > >
> > > The patch prevents VOIDmode temporary from entering simplify_gen_subreg.
> > > We can't process const_int operand any further, since outermode
> > > is not an integer mode here.
> >
> > But if it's a CONST_INT then we know it's of int_outermode, no? That is,
> > doesn't simplify_subreg (mode, ...) always return something in 'mode'
> > and thus we can always pass just 'mode' as third argument to the
> > following simplify_gen_subreg call?
> 
> You are right. I am testing the attached patch that works too.

OK if that works.

Thanks,
Richard.

[PATCH] Fix wrong-code issue in VN

[Richard Biener via Gcc-patches]

The following fixes the wrong removed dead store discovered on the
PR108657 testcase when the reported DSE issue is not fixed.
The issue is we were using ssa_undefined_value_p on virtual operands
which returns a result based on the real definition of the definition
statement.  That doesn't make sense so this patch guards the calls
properly and makes sure nobody else does the same mistake.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

* tree-ssa.cc (ssa_undefined_value_p): Assert we are not
called on virtual operands.
* tree-ssa-sccvn.cc (vn_phi_lookup): Guard
ssa_undefined_value_p calls.
(vn_phi_insert): Likewise.
(set_ssa_val_to): Likewise.
(visit_phi): Avoid extra work with equivalences for
virtual operand PHIs.
---
 gcc/tree-ssa-sccvn.cc | 20 +++-
 gcc/tree-ssa.cc   |  2 ++
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index 8ee77fd2b78..d5b081a309f 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -4824,7 +4824,8 @@ vn_phi_lookup (gimple *phi, bool backedges_varying_p)
   if (TREE_CODE (def) == SSA_NAME
  && (!backedges_varying_p || !(e->flags & EDGE_DFS_BACK)))
{
- if (ssa_undefined_value_p (def, false))
+ if (!virtual_operand_p (def)
+ && ssa_undefined_value_p (def, false))
def = VN_TOP;
  else
def = SSA_VAL (def);
@@ -4877,7 +4878,8 @@ vn_phi_insert (gimple *phi, tree result, bool 
backedges_varying_p)
   if (TREE_CODE (def) == SSA_NAME
  && (!backedges_varying_p || !(e->flags & EDGE_DFS_BACK)))
{
- if (ssa_undefined_value_p (def, false))
+ if (!virtual_operand_p (def)
+ && ssa_undefined_value_p (def, false))
def = VN_TOP;
  else
def = SSA_VAL (def);
@@ -5059,6 +5061,7 @@ set_ssa_val_to (tree from, tree to)
}
   curr_invariant = is_gimple_min_invariant (currval);
   curr_undefined = (TREE_CODE (currval) == SSA_NAME
+   && !virtual_operand_p (currval)
&& ssa_undefined_value_p (currval, false));
   if (currval != VN_TOP
  && !curr_invariant
@@ -5081,6 +5084,7 @@ set_ssa_val_to (tree from, tree to)
   else if (currval != VN_TOP
   && !curr_undefined
   && TREE_CODE (to) == SSA_NAME
+  && !virtual_operand_p (to)
   && ssa_undefined_value_p (to, false))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
@@ -5116,6 +5120,7 @@ set_and_exit:
  PR82320 for a testcase were we'd otherwise not terminate iteration.  
*/
   && !(curr_undefined
   && TREE_CODE (to) == SSA_NAME
+  && !virtual_operand_p (to)
   && ssa_undefined_value_p (to, false))
   /* ???  For addresses involving volatile objects or types operand_equal_p
  does not reliably detect ADDR_EXPRs as equal.  We know we are only
@@ -5880,7 +5885,14 @@ visit_phi (gimple *phi, bool *inserted, bool 
backedges_varying_p)
sameval = def;
sameval_e = e;
  }
-   else if (!expressions_equal_p (def, sameval))
+   else if (expressions_equal_p (def, sameval))
+ sameval_e = NULL;
+   else if (virtual_operand_p (def))
+ {
+   sameval = NULL_TREE;
+   break;
+ }
+   else
  {
/* We know we're arriving only with invariant addresses here,
   try harder comparing them.  We can do some caching here
@@ -5957,8 +5969,6 @@ visit_phi (gimple *phi, bool *inserted, bool 
backedges_varying_p)
sameval = NULL_TREE;
break;
  }
-   else
- sameval_e = NULL;
   }
 
   /* If the value we want to use is flowing over the backedge and we
diff --git a/gcc/tree-ssa.cc b/gcc/tree-ssa.cc
index 5126020d40f..a5cad2d344e 100644
--- a/gcc/tree-ssa.cc
+++ b/gcc/tree-ssa.cc
@@ -1320,6 +1320,8 @@ ssa_undefined_value_p (tree t, bool partial)
 {
   gimple *def_stmt;
 
+  gcc_checking_assert (!virtual_operand_p (t));
+
   if (ssa_defined_default_def_p (t))
 return false;
 
-- 
2.35.3

[Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

[Tobias Burnus]

Short version:

This fixes potential and real bugs related to 'len=:' character variables
as for the length/byte size an old/saved expression is used instead of
the current value. - That's fine but not for allocatable/pointer with 'len=:'.


Main part of the patch: Strip the SAVE_EXPR from the size expression:

  if (len && deferred && TREE_CODE (TYPE_SIZE (type)) == SAVE_EXPR)
{
  gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (type)) == SAVE_EXPR);
  TYPE_SIZE (type) = TREE_OPERAND (TYPE_SIZE (type), 0);
  TYPE_SIZE_UNIT (type) = TREE_OPERAND (TYPE_SIZE_UNIT (type), 0);
}


OK for mainline?

* * *

Long version:

BACKGROUND:


(A) VLA / EXPLICIT-SIZE ARRAYS + LEN= STRINGS


C knows something like VLA (variable length arrays), likewise Fortran
knows explicit size array and character length where the length/size
depends on an variable set before the current scoping unit. Examples:

void f(int N)
{
  int vla[N*5];
}

subroutine foo(n)
  integer :: n
  integer :: array(n*5)
  integer :: my_len
  ...
  my_len = 5
  block
character(len=my_len, kind=4) :: str

my_len = 99
print *, len(str)  ! still shows 5 - not 99
  end block
end


In all cases, the size / length is not known at compile time but it won't 
change.
Thus, expressions like (pseudo code)
   byte_size = n * 5 * sizeof(integer)
can be saved and re-used and do not have to be re-calculated every time the
   TYPE_SIZE or TYPE_UNIT_SIZE
is used.

In particular, the 'my_len' example shows that just using the current value of
'my_len' would be wrong as it can be overridden.


* * *


(B) DEFERRED-LENGTH STRINGS ('character(len=:), pointer/allocatable')


But with deferred-length strings, such as

  character(len=:), pointer :: pstr(:)
  ...
  allocate(character(len=2) :: pstr(5))
  ...
  !$omp target enter data map(alloc: pstr(2:5))


this leads to code like:

  integer(kind=8) .pstr;
  struct array01_character(kind=1) pstr;

  D.4302 = (sizetype) NON_LVALUE_EXPR <.pstr>;
  pstr.dtype = {.elem_len=(unsigned long) .pstr, .rank=1, .type=6};
...
.pstr = 2;  // during allocation/pointer assignment
...
  parm.1.data = pstr.data + (sizetype) ((~pstr.dim[0].lbound * D.4287)
* (integer(kind=8)) SAVE_EXPR );

And here D.4302 is the pre-calculated value instead of the current value,
which can be either 0 or some random value.


Such code happens when using code like:
elemsz = TYPE_SIZE_UNIT (gfc_get_element_type (type));

Of course, there are various ways to avoid this – like obtaining somehow the
string length directly - either from the expression or from the type such as
  TYPE_DOMAIN (type)
but it can easily go wrong.

 * * *

IDEAL SOLUTION:

I think from the middle-end perspective, we should do:
  build_range_type (type, 0, NULL_TREE)
leaving the upper bound unspecified – which should also help with
type-is-the-same middle-end analysis.


PRACTICAL SOLUTION:

But as code like TYPE_SIZE_UNIT is very widely used - and we currently lack
a place to store the tree decl for the length, I propose the following as 
discussed
with Jakub yesterday:

We just remove SAVE_EXPR after generating the type.

Side note: In some cases, the type is already constructed with len = NULL; I 
have not
checked when. In that case, using TYPE_SIZE will fail at compile time.
(That remains unchanged by this patch.)

 * * *

OK for mainline?

Tobias

 * * *

PS: I have no real opinion whether we want to have any backports, thoughts?


PPS: I don't have any real example I want to add as most cases have been 
work-around
fixed in the meanwhile. If you want to test it, the following fails. I intent 
to add
an extended tests as part of a larger follow-up patch which fixes more OpenMP 
issues:

  character(len=:), pointer :: pstr(:)
  allocate(character(len=2) :: pstr(5))
  !$omp target enter data map(alloc: pstr(2:5))
end


Compile with -fopenmp -fdump-tree-original (or a later dump).


BEFORE the patch:

  integer(kind=8) .pstr;
  ...
  D.4291 = (sizetype) NON_LVALUE_EXPR <.pstr>;
  pstr.dtype = {.elem_len=(unsigned long) .pstr, .rank=1, .type=6};
  ...
.pstr = 2;
  ...
pstr.data = __builtin_malloc (10);
  ...
  parm.1.data = pstr.data + (sizetype) (((2 - pstr.dim[0].lbound) * D.4287)
* (integer(kind=8)) SAVE_EXPR );

AFTER the patch:
  .
  parm.1.data = pstr.data + (sizetype) (((2 - pstr.dim[0].lbound) * D.4287)
* NON_LVALUE_EXPR <.pstr>);
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
Fortran: Avoid SAVE_EXPR for deferred-len char types

Using TYPE_SIZE/TYPE_SIZE_UNIT with deferred-length character variables,
i.e. 'character(len=:), allocatable/pointer' used a SAVE_EXPR, i.e. the
value on entry to the scope instead of the 

Re: [PATCH] [libstdc++] ensure mutex_pool survives _Safe_sequence_base

[Jonathan Wakely via Gcc-patches]

On Fri, 17 Feb 2023, 08:02 Alexandre Oliva via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

> On Feb 17, 2023, Alexandre Oliva  wrote:
>
> > On vxworks, after destroying the semaphore used to implement a mutex,
> > __gthread_mutex_lock fails and __gnu_cxx::__mutex::lock calls
> > __throw_concurrence_lock_error.  Nothing ensures the mutex_pool
> > mutexes survive init-once objects containing _Safe_sequence_base.  If
> > such an object completes construction before mutex_pool
> > initialization, it will be registered for atexit destruction after the
> > mutex_pool mutexes, so the _M_detach_all() call in the
> > _Safe_sequence_base dtor will use already-destructed mutexes, and
> > basic_string/requirements/citerators_cc fails calling terminate.
>
> Here's an alternative approach, with zero runtime overhead.  Negative
> overhead, if you count the time it would have taken to destruct the
> mutex pool :-) But it fails to destruct them, which is presumably of no
> consequence.
>

Agreed, I was going to suggest we immortalise them like this.



> [libstdc++] do not destruct mutex_pool mutexes
>
> [Copy of the paragraph quoted above omitted here]
>
> This patch fixes this problem by ensuring the mutex pool mutexes are
> constructed on demand, on a statically-allocated buffer, but never
> destructed.
>
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?
>


OK, thanks.



> for  libstdc++-v3/ChangeLog
>
> * src/c++11/shared_ptr.cc (__gnu_internal::get_mutex):
> Avoid destruction of the mutex pool.
> ---
>  libstdc++-v3/src/c++11/shared_ptr.cc |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/src/c++11/shared_ptr.cc
> b/libstdc++-v3/src/c++11/shared_ptr.cc
> index bc70134359c87..74e879e582896 100644
> --- a/libstdc++-v3/src/c++11/shared_ptr.cc
> +++ b/libstdc++-v3/src/c++11/shared_ptr.cc
> @@ -36,7 +36,11 @@ namespace __gnu_internal _GLIBCXX_VISIBILITY(hidden)
>{
>  // increase alignment to put each lock on a separate cache line
>  struct alignas(64) M : __gnu_cxx::__mutex { };
> -static M m[mask + 1];
> +// Use a static buffer, so that the mutexes are not destructed
> +// before potential users (or at all)
> +static __attribute__ ((aligned(__alignof__(M
> +  char buffer[(sizeof (M)) * (mask + 1)];
> +static M *m = new (buffer) M[mask + 1];
>  return m[i];
>}
>  }
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 
>

Re: [PATCH] [libstdc++] xfail noreplace tests on vxworks

[Jonathan Wakely via Gcc-patches]

On Fri, 17 Feb 2023, 07:40 Alexandre Oliva via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

>
> vxworks ignores O_EXCL in open, so noreplace open succeeds when it is
> expected to fail.  xfail the tests.
>
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?
>


OK, thanks.

(We need a similar change for hp-ux and Solaris, at least. Which means we
need to change the impl to not assume it works.)




> for  libstdc++-v3/ChangeLog
>
> * testsuite/27_io/basic_ofstream/open/char/noreplace.cc: xfail
> on vxworks.
> * testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc:
> Likewise.
> ---
>  .../27_io/basic_ofstream/open/char/noreplace.cc|2 +-
>  .../27_io/basic_ofstream/open/wchar_t/noreplace.cc |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
> a/libstdc++-v3/testsuite/27_io/basic_ofstream/open/char/noreplace.cc
> b/libstdc++-v3/testsuite/27_io/basic_ofstream/open/char/noreplace.cc
> index 56ff2d7cead3c..2e99707df86d0 100644
> --- a/libstdc++-v3/testsuite/27_io/basic_ofstream/open/char/noreplace.cc
> +++ b/libstdc++-v3/testsuite/27_io/basic_ofstream/open/char/noreplace.cc
> @@ -1,4 +1,4 @@
> -// { dg-do run }
> +// { dg-do run { xfail *-*-vxworks* } }
>
>  #include 
>
> diff --git
> a/libstdc++-v3/testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc
> b/libstdc++-v3/testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc
> index f0425cdab3d23..ddb7fd691608c 100644
> --- a/libstdc++-v3/testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc
> +++ b/libstdc++-v3/testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc
> @@ -1,4 +1,4 @@
> -// { dg-do run }
> +// { dg-do run { xfail *-*-vxworks* } }
>
>  #include 
>
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 
>

Re: [libstdc++] [testsuite] intro/names.cc: undef func on vxw7krn

[Jonathan Wakely via Gcc-patches]

On Fri, 17 Feb 2023, 06:19 Alexandre Oliva via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

>
> The '#define func' added in 2021, to test that system headers don't
> violate the user namespace, exposes such a bug in the vxworks sysLib.h
> header, so add yet another such annotated workaround.
>
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?
>

OK, thanks.



> for  libstdc++-v3/ChangeLog
>
> * testsuite/17_intro/names.cc: Undef func on vxworks >= 7 in
> kernel mode.
> ---
>  libstdc++-v3/testsuite/17_intro/names.cc |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libstdc++-v3/testsuite/17_intro/names.cc
> b/libstdc++-v3/testsuite/17_intro/names.cc
> index d3e0db9bab6b9..c2d67ebe01276 100644
> --- a/libstdc++-v3/testsuite/17_intro/names.cc
> +++ b/libstdc++-v3/testsuite/17_intro/names.cc
> @@ -329,6 +329,8 @@
>  #undef d
>  #undef e
>  #undef f
> +// in sysLib.h, func appears as a formal parameter name
> +#undef func
>  #endif // __RTP__
>
>  #endif // VxWorks Major >= 7
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 
>

Re: [libstdc++] Use __gthread_join in jthread/95989

[Jonathan Wakely via Gcc-patches]

On Fri, 17 Feb 2023, 06:40 Alexandre Oliva via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

>
> Ref: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570617.html
>
> Bernd Edlinger  reported that the 95989.cc
> test fails without pthread_join at the end of main,


Yes, but that doesn't mean we want to do that.


but pthread_join
> is no good for a test that doesn't require pthreads.
>
> This patch adds a __gthread_join call instead.
>
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?
>

Nope, the test is correct, if it needs that there's a bug somewhere else.
Papering over it in the test doesn't help.

Each of test01, test02, and test03 creates a thread, joins it, and returns,
which needs to work with no additional code. The change happens to "work"
because it causes a non-weak reference to pthread_join, which otherwise
doesn't get linked in from libpthread.a on ubuntu.

The proper fix is to ensure the program has a non-weak reference to
pthread_join without extra help (or use a recent glibc where it always
works).




> for  libstdc++-v3/ChangeLog
>
> * testsuite/30_threads/jthread/95989.cc (main): Call
> __gthread_join at the end.
> ---
>  libstdc++-v3/testsuite/30_threads/jthread/95989.cc |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
> b/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
> index e98836d094531..407b52748438c 100644
> --- a/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
> +++ b/libstdc++-v3/testsuite/30_threads/jthread/95989.cc
> @@ -52,4 +52,5 @@ main()
>test01();
>test02();
>test03();
> +  __gthread_join(0, NULL);
>  }
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 
>

[PATCH] optabs: Fix up expand_doubleword_shift_condmove for shift_mask == 0 [PR108803]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase is miscompiled on aarch64.  The problem is that
aarch64 with TARGET_SIMD is !SHIFT_COUNT_TRUNCATED target with
targetm.shift_truncation_mask (DImode) == 0 which has HAVE_conditional_move
true.  If a doubleword shift (in this case TImode) doesn't have its own
expander (as is the case of e.g. x86) and is handled in generic code,
there are 3 possible expansions.  One is when the shift count is constant,
the code computes in that case superword_op1 as op1 - BITS_PER_WORD,
and chooses at compile time which of expand_superword_shift or
expand_subword_shift to call, which ensures that whatever is used
actually has its shift count (superword_op1 or op1) in [0, BITS_PER_WORD - 1]
range.  If !HAVE_conditional_move or that expansion fails, the function
handles non-constant op1 similarly (there are some special cases for
shift_mask >= BITS_PER_WORD - 1 but let's talk here just about
shift_mask < BITS_PER_WORD - 1), except that the selection is done at
runtime, with branches around the stuff.  While superword_op1 can be
[-BITS_PER_WORD, BITS_PER_WORD - 1] and op1 [0, 2 * BITS_PER_WORD - 1],
the runtime selection ensures that the instructions executed at runtime
have their corresponding shift count again in the right range of
[0, BITS_PER_WORD - 1].
The problematic is the HAVE_conditional_move case, which emits both
sequences into the actually executed code, so necessarily one of them
has an out of range shift count and then using 2 conditional moves
picks up a result.
Now, in the testcase because -Og doesn't perform VRP/EVRP the shift
count isn't optimized to constant during GIMPLE passes, but is determined
to be constant during/after expansion into RTL.  The shift count is
actually const0_rtx later, so superword_op1 is (const_int -64) and we end
up with miscompilation during combine because of that.
I'm afraid on targetm.shift_truncation_mask (DImode) == 0 targets we have
to mask the shift counts when the doubleshift count is in range but
one of subword_op1/superword_op1 is not, which is what the following
patch does and what fixes the wrong-code.  Now, targets like x86 or aarch64,
while they are !SHIFT_COUNT_TRUNCATED, have actually patterns to catch
shift with masked counter, so the ANDs can be optimized out.  On the other
side, when we know the result will be masked this way we can use the
simpler ~op1 instead of (BITS_PER_WORD - 1) - op1 in expand_subword_shift.
So, say on
__attribute__((noipa)) __int128
foo (__int128 a, unsigned k)
{
  return a << k;
}
on aarch64 at -Og the difference is:
 foo:
subsw5, w2, #64
-   lsl x6, x0, x5
+   lsl x4, x0, x2
lsr x3, x0, 1
-   mov w4, 63
-   sub w4, w4, w2
-   lsr x3, x3, x4
+   mvn w6, w2
+   and w2, w2, 63
+   lsr x3, x3, x6
lsl x1, x1, x2
orr x1, x3, x1
lsl x0, x0, x2
cselx0, xzr, x0, pl
-   cselx1, x6, x1, pl
+   cselx1, x4, x1, pl
ret
We could do even better and optimize the and w2, w2, 63 instruction out,
but it is a matter of costs and so IMHO should be handled incrementally.
For that case consider say:
void corge (int, int, int);

void
qux (int x, int y, int z, int n)
{
  n &= 31;
  corge (x << n, y << n, z >> n);
}
with -O2 -fno-tree-vectorize, on x86_64 one gets
sarl%cl, %edx
sall%cl, %esi
sall%cl, %edi
jmp corge
but on aarch64
and w3, w3, 31
lsl w0, w0, w3
lsl w1, w1, w3
asr w2, w2, w3
b   corge
The reason it works on x86 is that its rtx_costs hook recognizes
that the AND in shift+mask patterns is for free.
Trying 9 -> 11:
9: {r85:SI=r96:SI&0x1f;clobber flags:CC;}
  REG_UNUSED flags:CC
   11: {r91:SI=r87:SI< 11:
9: r95:SI=r106:SI&0x1f
  REG_DEAD r106:SI
   11: r101:SI=r104:SI<

PR middle-end/108803
* optabs.cc (expand_subword_shift): Add MASK_COUNT argument,
if true, use ~op1 & (BITS_PER_WORD - 1) instead of
(BITS_PER_WORD - 1) - op1 as tmp and op1 & (BITS_PER_WORD - 1)
instead of op1 on the other two shifts.
(expand_doubleword_shift_condmove): Use
superword_op1 & (BITS_PER_WORD - 1) instead of superword_op1.  Pass
shift_mask < BITS_PER_WORD - 1 as MASK_COUNT to expand_subword_shift.
(expand_doubleword_shift): Pass false as MASK_COUNT to
expand_subword_shift.

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

--- gcc/optabs.cc.jj2023-01-02 09:32:53.309838465 +0100
+++ gcc/optabs.cc   2023-02-16 20:44:21.862031535 +0100
@@ -507,7 +507,7 @@ expand_subword_shift (scalar_int_mode op
  rtx outof_input, rtx into_input, rtx op1,
  rtx outof_target, rtx into_target,
  int unsignedp, enum optab_methods methods,
- unsigned HOST_WIDE_INT shift_mask)
+ unsigned HOST_WIDE_INT shift_mask, bool 

[PATCH] rs6000: Fix vector_set_var_p9 by considering BE [PR108807]

[Kewen.Lin via Gcc-patches]

Hi,

As PR108807 exposes, the current handling in function
rs6000_expand_vector_set_var_p9 doesn't take care of big
endianness.  Currently the function is to rotate the
target vector by moving element to-be-set to element 0,
set element 0 with the given val, then rotate back.  To
get the permutation control vector for the rotation, it
makes use of lvsr and lvsl, but the element ordering is
different for BE and LE (like element 0 is the most
significant one on BE while the least significant one on
LE), this patch is to add consideration for BE and make
sure permutation control vectors for rotations are expected.

As tested, it helped to fix the below failures:

FAIL: gcc.target/powerpc/pr79251-run.p9.c execution test
FAIL: gcc.target/powerpc/pr89765-mc.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-11d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-14d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-16d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-18d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-9d.c execution test

Bootstrapped and regtested on powerpc64-linux-gnu P{8,9}
and powerpc64le-linux-gnu P10.

Is it ok for trunk?

BR,
Kewen
-
PR target/108807

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_expand_vector_set_var_p9): Fix gen
function for permutation control vector by considering big endianness.
---
 gcc/config/rs6000/rs6000.cc | 48 +
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 16ca3a31757..774eb2963d9 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -7235,22 +7235,26 @@ rs6000_expand_vector_set_var_p9 (rtx target, rtx val, 
rtx idx)

   machine_mode shift_mode;
   rtx (*gen_ashl)(rtx, rtx, rtx);
-  rtx (*gen_lvsl)(rtx, rtx);
-  rtx (*gen_lvsr)(rtx, rtx);
+  rtx (*gen_pcvr1)(rtx, rtx);
+  rtx (*gen_pcvr2)(rtx, rtx);

   if (TARGET_POWERPC64)
 {
   shift_mode = DImode;
   gen_ashl = gen_ashldi3;
-  gen_lvsl = gen_altivec_lvsl_reg_di;
-  gen_lvsr = gen_altivec_lvsr_reg_di;
+  gen_pcvr1 = BYTES_BIG_ENDIAN ? gen_altivec_lvsl_reg_di
+  : gen_altivec_lvsr_reg_di;
+  gen_pcvr2 = BYTES_BIG_ENDIAN ? gen_altivec_lvsr_reg_di
+  : gen_altivec_lvsl_reg_di;
 }
   else
 {
   shift_mode = SImode;
   gen_ashl = gen_ashlsi3;
-  gen_lvsl = gen_altivec_lvsl_reg_si;
-  gen_lvsr = gen_altivec_lvsr_reg_si;
+  gen_pcvr1 = BYTES_BIG_ENDIAN ? gen_altivec_lvsl_reg_si
+  : gen_altivec_lvsr_reg_si;
+  gen_pcvr2 = BYTES_BIG_ENDIAN ? gen_altivec_lvsr_reg_si
+  : gen_altivec_lvsl_reg_si;
 }
   /* Generate the IDX for permute shift, width is the vector element size.
  idx = idx * width.  */
@@ -7259,25 +7263,29 @@ rs6000_expand_vector_set_var_p9 (rtx target, rtx val, 
rtx idx)

   emit_insn (gen_ashl (tmp, idx, GEN_INT (shift)));

-  /*  lvsrv1,0,idx.  */
-  rtx pcvr = gen_reg_rtx (V16QImode);
-  emit_insn (gen_lvsr (pcvr, tmp));
-
-  /*  lvslv2,0,idx.  */
-  rtx pcvl = gen_reg_rtx (V16QImode);
-  emit_insn (gen_lvsl (pcvl, tmp));
+  /* Generate one permutation control vector used for rotating the element
+ at to-insert position to element zero in target vector.  lvsl is
+ used for big endianness while lvsr is used for little endianness:
+ lvs[lr]v1,0,idx.  */
+  rtx pcvr1 = gen_reg_rtx (V16QImode);
+  emit_insn (gen_pcvr1 (pcvr1, tmp));

   rtx sub_target = simplify_gen_subreg (V16QImode, target, mode, 0);
+  rtx perm1 = gen_altivec_vperm_v8hiv16qi (sub_target, sub_target, sub_target,
+  pcvr1);
+  emit_insn (perm1);

-  rtx permr
-= gen_altivec_vperm_v8hiv16qi (sub_target, sub_target, sub_target, pcvr);
-  emit_insn (permr);
-
+  /* Insert val into element 0 of target vector.  */
   rs6000_expand_vector_set (target, val, const0_rtx);

-  rtx perml
-= gen_altivec_vperm_v8hiv16qi (sub_target, sub_target, sub_target, pcvl);
-  emit_insn (perml);
+  /* Rotate back with a reversed permutation control vector generated from:
+ lvs[rl]   v2,0,idx.  */
+  rtx pcvr2 = gen_reg_rtx (V16QImode);
+  emit_insn (gen_pcvr2 (pcvr2, tmp));
+
+  rtx perm2 = gen_altivec_vperm_v8hiv16qi (sub_target, sub_target, sub_target,
+  pcvr2);
+  emit_insn (perm2);
 }

 /* Insert VAL into IDX of TARGET, VAL size is same of the vector element, IDX
--
2.39.1

[PATCH v2] rs6000: Fix vector parity support [PR108699]

[Kewen.Lin via Gcc-patches]

Hi,

The failures on the original failed case builtin-bitops-1.c
and the associated test case pr108699.c here show that the
current support of parity vector mode is wrong on Power.
The hardware insns vprtyb[wdq] which operate on the least
significant bit of each byte per element, they doesn't match
what RTL opcode parity needs, but the current implementation
expands it with them wrongly.  This patch is to fix the
handling with one more pre-insn vpopcntb.

Bootstrapped and regtested on powerpc64-linux-gnu P{8,9}
and powerpc64le-linux-gnu P10.

Is it ok for trunk?

BR,
Kewen
-
PR target/108699

gcc/ChangeLog:

* config/rs6000/altivec.md (*p9v_parity2): Rename to ...
(parityb2): ... this.
* config/rs6000/rs6000-builtins.def (VPRTYBD): Replace parityv2di2 with
paritybv2di2.
(VPRTYBW): Replace parityv4si2 with paritybv4si2.
(VPRTYBQ): Replace parityv1ti2 with paritybv1ti2.
* config/rs6000/vector.md (parity2 with VEC_IP): Expand with
popcountv16qi2 and the corresponding vector parity byte parityb2.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/p9-vparity.c: Add scan-assembler-not for vpopcntb
to distinguish vector parity byte from vector parity.
* gcc.target/powerpc/pr108699.c: New test.
---
 gcc/config/rs6000/altivec.md  |  8 ++--
 gcc/config/rs6000/rs6000-builtins.def |  6 +--
 gcc/config/rs6000/vector.md   | 11 -
 gcc/testsuite/gcc.target/powerpc/p9-vparity.c |  1 +
 gcc/testsuite/gcc.target/powerpc/pr108699.c   | 42 +++
 5 files changed, 61 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr108699.c

diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 30606b8ab21..6d229fb4296 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -4195,9 +4195,11 @@ (define_insn "*p8v_popcount2"
   [(set_attr "type" "vecsimple")])

 ;; Vector parity
-(define_insn "*p9v_parity2"
-  [(set (match_operand:VParity 0 "register_operand" "=v")
-(parity:VParity (match_operand:VParity 1 "register_operand" "v")))]
+(define_insn "parityb2"
+  [(set (match_operand:VEC_IP 0 "register_operand" "=v")
+(unspec:VEC_IP
+  [(match_operand:VEC_IP 1 "register_operand" "v")]
+  UNSPEC_PARITY))]
   "TARGET_P9_VECTOR"
   "vprtyb %0,%1"
   [(set_attr "type" "vecsimple")])
diff --git a/gcc/config/rs6000/rs6000-builtins.def 
b/gcc/config/rs6000/rs6000-builtins.def
index e0d9f5adc97..a6544903286 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -2666,13 +2666,13 @@
 VMSUMUDM altivec_vmsumudm {}

   const vsll __builtin_altivec_vprtybd (vsll);
-VPRTYBD parityv2di2 {}
+VPRTYBD paritybv2di2 {}

   const vsq __builtin_altivec_vprtybq (vsq);
-VPRTYBQ parityv1ti2 {}
+VPRTYBQ paritybv1ti2 {}

   const vsi __builtin_altivec_vprtybw (vsi);
-VPRTYBW parityv4si2 {}
+VPRTYBW paritybv4si2 {}

   const vsll __builtin_altivec_vrldmi (vsll, vsll, vsll);
 VRLDMI altivec_vrldmi {}
diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
index 12fd5f976ed..fcb8fbc0d12 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -1226,7 +1226,16 @@ (define_expand "popcount2"
 (define_expand "parity2"
   [(set (match_operand:VEC_IP 0 "register_operand")
(parity:VEC_IP (match_operand:VEC_IP 1 "register_operand")))]
-  "TARGET_P9_VECTOR")
+  "TARGET_P9_VECTOR"
+{
+  rtx op1 = gen_lowpart (V16QImode, operands[1]);
+  rtx res = gen_reg_rtx (V16QImode);
+  emit_insn (gen_popcountv16qi2 (res, op1));
+  emit_insn (gen_parityb2 (operands[0],
+gen_lowpart (mode, res)));
+
+  DONE;
+})



 ;; Same size conversions
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-vparity.c 
b/gcc/testsuite/gcc.target/powerpc/p9-vparity.c
index f4aba1567cd..8f6f1239f7a 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-vparity.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-vparity.c
@@ -105,3 +105,4 @@ parity_ti_4u (__uint128_t a)
 /* { dg-final { scan-assembler "vprtybd" } } */
 /* { dg-final { scan-assembler "vprtybq" } } */
 /* { dg-final { scan-assembler "vprtybw" } } */
+/* { dg-final { scan-assembler-not "vpopcntb" } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr108699.c 
b/gcc/testsuite/gcc.target/powerpc/pr108699.c
new file mode 100644
index 000..f02bac130cc
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr108699.c
@@ -0,0 +1,42 @@
+/* { dg-run } */
+/* { dg-options "-O2 -ftree-vectorize -fno-vect-cost-model" } */
+
+#define N 16
+
+unsigned long long vals[N];
+unsigned int res[N];
+unsigned int expects[N] = {0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0};
+
+unsigned long long inputs[N]
+  = {0xULL, 0x0001ULL, 0x8000ULL,
+ 0x0002ULL, 0x4000ULL, 0x0001ULL,
+ 

Re: [PATCH] Fix PR target/90458

[Eric Botcazou via Gcc-patches]

> Is there a way to say that the test results should be inverted on a
> particular platform (instead of purely unsupported)?

Yes, you can do pretty much what you want with the testsuite harness.

-- 
Eric Botcazou

Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Alexandre Oliva  wrote:

> Now, really, I did not get as far as trying to make sense of the
> algorithm in there (get_ref definitely doesn't do what its name suggests
> to me), I just saw a bunch of weirdnesses in blackbox testing and
> failing variations, that seemed to suggest some fundamental issue, that
> would hopefully be obvious to someone more familiar with that code.

Here's one more: the stores hash_set seems to be intended to help catch
overwrites, so as to detect assignments of pointers-to-auto-locals to
escaping pointers that reach exits, without flagging those that are
definitely overwritten afterwards.

In a linear backwards scan, that makes sense, but once blocks recurse
for their preds, ISTM it could suppress the desired warning in e.g.:

  if (condition)
*incoming_ptr = 
  else
*incoming_ptr = 0;

in case we scan the else bb before the then bb.


But how about asynchronous exceptions?  They might leave those dangling
pointers if they hit at an undesirable spot.  So should we really
suppress those warnings?

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Fix PR target/90458

[NightStrike via Gcc-patches]

On Thu, Feb 16, 2023 at 3:16 AM Eric Botcazou  wrote:
>
> > This fixes dg.exp/stack-check-2.c, -7, 8, and -16.c, which is great!
>
> Try the attached patch.

Well... that patch just marks all of the tests as unsupported.  But
for example, the ones quoted above run, work, and pass.  And when they
didn't pass, they highlighted the ICE that you fixed.  So running the
test despite the nature of stack protection on Windows still has
value.  It is useful to ensure for example that stack protection
continues to work even if options are passed to disable it.  But the
tests that remain are looking for rtl patterns that (I assume)
shouldn't exist.  So it's perhaps useful to modify the test to say
that on windows, the scan-rtl-dump-times check should have zero hits.
If it found a match, that would be an error.

Is there a way to say that the test results should be inverted on a
particular platform (instead of purely unsupported)?

Re: [PATCH] simplify-rtx: Fix VOIDmode operand handling in simplify_subreg [PR108805]

[Uros Bizjak via Gcc-patches]

On Fri, Feb 17, 2023 at 8:38 AM Richard Biener  wrote:
>
> On Thu, 16 Feb 2023, Uros Bizjak wrote:
>
> > simplify_subreg can return VOIDmode const_int operand and will
> > cause ICE in simplify_gen_subreg when this operand is passed to it.
> >
> > The patch prevents VOIDmode temporary from entering simplify_gen_subreg.
> > We can't process const_int operand any further, since outermode
> > is not an integer mode here.
>
> But if it's a CONST_INT then we know it's of int_outermode, no? That is,
> doesn't simplify_subreg (mode, ...) always return something in 'mode'
> and thus we can always pass just 'mode' as third argument to the
> following simplify_gen_subreg call?

You are right. I am testing the attached patch that works too.

Uros.
diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index 0a1dd88b0a8..3955929bb70 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -7665,7 +7665,7 @@ simplify_context::simplify_subreg (machine_mode 
outermode, rtx op,
 {
   rtx tem = simplify_subreg (int_outermode, op, innermode, byte);
   if (tem)
-   return simplify_gen_subreg (outermode, tem, GET_MODE (tem), 0);
+   return simplify_gen_subreg (outermode, tem, int_outermode, 0);
 }
 
   /* If OP is a vector comparison and the subreg is not changing the

RE: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Li, Pan2 via Gcc-patches]

Cool, thank you!

Hi Richard S,

Could you please help to do me a fever for this change when you free? Thank you!

Pan

-Original Message-
From: Richard Biener  
Sent: Friday, February 17, 2023 3:36 PM
To: juzhe.zhong 
Cc: incarnation.p@outlook.com; gcc-patches@gcc.gnu.org; 
kito.ch...@sifive.com; Li, Pan2 ; richard.sandif...@arm.com
Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

On Thu, 16 Feb 2023, juzhe.zhong wrote:

> Thanks for the great work to fix this issue for rvv.Hi，richard. This 
> is the patch to differentiate mask mode of same bytesize. Adjust the 
> precision correctly according to rvv isa. Would you mind helping us 
> with this patch ？
> Since it‘s very important for rvv support in gcc

If adjusting the precision works fine then I suppose the patch looks 
reasonable.  I'll defer to Richard S. though since he's the one knowing the 
mode stuff better.  I'd have integrated the precision adjustment with the 
ADJUST_NITER hook since that is also documented to adjust the precision btw.

Richard.

> Thanks.
>  Replied Message 
> From
> incarnation.p@outlook.com
> Date
> 02/16/2023 23:12
> To
> gcc-patches@gcc.gnu.org
> Cc
> juzhe.zh...@rivai.ai,
> kito.ch...@sifive.com,
> rguent...@suse.de,
> pan2...@intel.com
> Subject
> [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
> From: Pan Li 
> 
>    Fix the bug of the rvv bool mode precision with the adjustment.
>    The bits size of vbool*_t will be adjusted to
>    [1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
>    adjusted mode precison of vbool*_t will help underlying pass to
>    make the right decision for both the correctness and optimization.
> 
>    Given below sample code:
>    void test_1(int8_t * restrict in, int8_t * restrict out)
>    {
>      vbool8_t v2 = *(vbool8_t*)in;
>      vbool16_t v5 = *(vbool16_t*)in;
>      *(vbool16_t*)(out + 200) = v5;
>      *(vbool8_t*)(out + 100) = v2;
>    }
> 
>    Before the precision adjustment:
>    addi    a4,a1,100
>    vsetvli a5,zero,e8,m1,ta,ma
>    addi    a1,a1,200
>    vlm.v   v24,0(a0)
>    vsm.v   v24,0(a4)
>    // Need one vsetvli and vlm.v for correctness here.
>    vsm.v   v24,0(a1)
> 
>    After the precision adjustment:
>    csrr    t0,vlenb
>    slli    t1,t0,1
>    csrr    a3,vlenb
>    sub sp,sp,t1
>    slli    a4,a3,1
>    add a4,a4,sp
>    sub a3,a4,a3
>    vsetvli a5,zero,e8,m1,ta,ma
>    addi    a2,a1,200
>    vlm.v   v24,0(a0)
>    vsm.v   v24,0(a3)
>    addi    a1,a1,100
>    vsetvli a4,zero,e8,mf2,ta,ma
>    csrr    t0,vlenb
>    vlm.v   v25,0(a3)
>    vsm.v   v25,0(a2)
>    slli    t1,t0,1
>    vsetvli a5,zero,e8,m1,ta,ma
>    vsm.v   v24,0(a1)
>    add sp,sp,t1
>    jr  ra
> 
>    However, there may be some optimization opportunates after
>    the mode precision adjustment. It can be token care of in
>    the RISC-V backend in the underlying separted PR(s).
> 
>    PR 108185
>    PR 108654
> 
> gcc/ChangeLog:
> 
>    * config/riscv/riscv-modes.def (ADJUST_PRECISION):
>    * config/riscv/riscv.cc (riscv_v_adjust_precision):
>    * config/riscv/riscv.h (riscv_v_adjust_precision):
>    * genmodes.cc (ADJUST_PRECISION):
>    (emit_mode_adjustments):
> 
> gcc/testsuite/ChangeLog:
> 
>    * gcc.target/riscv/pr108185-1.c: New test.
>    * gcc.target/riscv/pr108185-2.c: New test.
>    * gcc.target/riscv/pr108185-3.c: New test.
>    * gcc.target/riscv/pr108185-4.c: New test.
>    * gcc.target/riscv/pr108185-5.c: New test.
>    * gcc.target/riscv/pr108185-6.c: New test.
>    * gcc.target/riscv/pr108185-7.c: New test.
>    * gcc.target/riscv/pr108185-8.c: New test.
> 
> Signed-off-by: Pan Li 
> ---
> gcc/config/riscv/riscv-modes.def    |  8 +++ 
> gcc/config/riscv/riscv.cc   | 12  
> gcc/config/riscv/riscv.h    |  1 + gcc/genmodes.cc    
>  
> | 25 ++- gcc/testsuite/gcc.target/riscv/pr108185-1.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-2.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-3.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-4.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-5.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-6.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-7.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-8.c | 77 
> +
> 12 files changed, 598 insertions(+), 1 deletion(-) create mode 100644 
> gcc/testsuite/gcc.target/riscv/pr108185-1.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-2.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-3.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-4.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-5.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-6.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-7.c
> 

[PATCH] Add pattern for clo

[Junxian Zhu]

From: Junxian Zhu 

gcc/ChangeLog:

* config/mips/mips.md (*clo2): New pattern.

gcc/testsuite/ChangeLog:

* gcc.target/mips/clz.c: New test.
* gcc.target/mips/clz.c: New test.
* gcc.target/mips/mips.exp: New option HAS_CLZ.

Signed-off-by: Junxian Zhu 
---
 gcc/config/mips/mips.md|  9 +
 gcc/testsuite/gcc.target/mips/clo.c| 11 +++
 gcc/testsuite/gcc.target/mips/clz.c| 10 ++
 gcc/testsuite/gcc.target/mips/mips.exp |  3 +++
 4 files changed, 33 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/mips/clo.c
 create mode 100644 gcc/testsuite/gcc.target/mips/clz.c

diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index e3bf32a3430..10607a57efc 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -3165,6 +3165,15 @@
   [(set_attr "type" "clz")
(set_attr "mode" "")])
 
+
+(define_insn "*clo2"
+  [(set (match_operand:GPR 0 "register_operand" "=d")
+   (clz:GPR (not:GPR (match_operand:GPR 1 "register_operand" "d"]
+  "ISA_HAS_CLZ_CLO"
+  "clo\t%0,%1"
+  [(set_attr "type" "clz")
+   (set_attr "mode" "")])
+
 ;;
 ;;  ...
 ;;
diff --git a/gcc/testsuite/gcc.target/mips/clo.c 
b/gcc/testsuite/gcc.target/mips/clo.c
new file mode 100644
index 000..91f29a1322a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/clo.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "(HAS_CLZ)" } */
+/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
+
+NOMIPS16 unsigned int foo(unsigned int x)
+{
+  return  __builtin_clz (~x);
+}
+
+/* { dg-final { scan-assembler-not "\tclz\t" } } */
+/* { dg-final { scan-assembler "\tclo\t" } } */
diff --git a/gcc/testsuite/gcc.target/mips/clz.c 
b/gcc/testsuite/gcc.target/mips/clz.c
new file mode 100644
index 000..74e6edb90aa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/clz.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "(HAS_CLZ)" } */
+/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
+
+NOMIPS16 unsigned int foo(unsigned int x)
+{
+  return  __builtin_clz (x);
+}
+
+/* { dg-final { scan-assembler "\tclz\t" } } */
diff --git a/gcc/testsuite/gcc.target/mips/mips.exp 
b/gcc/testsuite/gcc.target/mips/mips.exp
index 025fbe78359..ac3ab129541 100644
--- a/gcc/testsuite/gcc.target/mips/mips.exp
+++ b/gcc/testsuite/gcc.target/mips/mips.exp
@@ -252,6 +252,7 @@ set mips_option_groups {
 warnings "-w"
 dump "-fdump-.*"
 ins "HAS_INS"
+   clz "HAS_CLZ"
 dmul "NOT_HAS_DMUL"
 ldc "HAS_LDC"
 movn "HAS_MOVN"
@@ -1198,11 +1199,13 @@ proc mips-dg-options { args } {
#
 #   - paired-single instructions(*)
 #   - odd numbered single precision registers
+   #   - clz clo instructions
 #
# (*) Note that we don't support MIPS V at the moment.
} elseif { $isa_rev < 1
   && ([mips_have_test_option_p options "-mpaired-single"]
   || ([mips_have_test_option_p options "-modd-spreg"]
+  || [mips_have_test_option_p options "HAS_CLZ"]
   && ![mips_have_test_option_p options "-mfp64"]))} {
if { $gp_size == 32 } {
mips_make_test_option options "-mips32"
-- 
2.39.1

Re: [PATCH] -Wdangling-pointer: don't mark SSA lhs sets as stores

[Alexandre Oliva via Gcc-patches]

Hi, richi,

On Feb 17, 2023, Richard Biener  wrote:

> It seems the case should run into

Yeah, but when the stmt is _7 = this_2(D), lhs is _7, whereas
lhs_ref.ref is this_2(D), a parm decl's default def, so def_stmt is a
gimple_nop, and this is not a decl_by_reference, so we don't skip
stores.add, and any subsequent stores into fields of *this fails
stores.add.  This looks so fishy that I couldn't guess what was supposed
or expected to happen there :-(

> ?  I wonder what the circumstances are that we want the latter to happen if
> the former condition is true?

Note that what I'm testing for, to skip non-store stmts, is the actual
lhs, whereas lhs_ref.ref may very well have been resolved to the rhs (as
in the cases I saw), and even if it could be an SSA_NAME, whether the
stmt is a store depends on the actual lhs, not on properties of the rhs
that get_ref resolved lhs to, right?

Now, really, I did not get as far as trying to make sense of the
algorithm in there (get_ref definitely doesn't do what its name suggests
to me), I just saw a bunch of weirdnesses in blackbox testing and
failing variations, that seemed to suggest some fundamental issue, that
would hopefully be obvious to someone more familiar with that code.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[PATCH] Hazard barrier return support

[Junxian Zhu]

From: Junxian Zhu 

This patch allows a function to request clearing of all instruction and 
execution
hazards upon normal return via __attribute__ ((use_hazard_barrier_return)).

2017-04-25  Prachi Godbole  

gcc/ChangeLog:

* config/mips/mips.h (machine_function): New variable
use_hazard_barrier_return_p.
* config/mips/mips.md (UNSPEC_JRHB): New unspec.
(mips_hb_return_internal): New insn pattern.
* config/mips/mips.c (mips_attribute_table): Add attribute
use_hazard_barrier_return.
(mips_use_hazard_barrier_return_p): New static function.
(mips_function_attr_inlinable_p): Likewise.
(mips_compute_frame_info): Set use_hazard_barrier_return_p.
Emit error for unsupported architecture choice.
(mips_function_ok_for_sibcall, mips_can_use_return_insn):
Return false for use_hazard_barrier_return.
(mips_expand_epilogue): Emit hazard barrier return.
* doc/extend.texi: Document use_hazard_barrier_return.

gcc/testsuite/ChangeLog:

* gcc.target/mips/hazard-barrier-return-attribute.c: New test.

Signed-off-by: Junxian Zhu 
---
(dragan.mladjeno...@mediatek.com): Rehash of original patch posted by Prachi
with minimal changes. Tested against mips-mti-elf with mips32r2/-EB and
mips32r2/-EB/-micromips.

(zhujunx...@oss.cipunited.com): Rebase and set minimal requirement to R2
---
 gcc/config/mips/mips.cc   |  1 +
 gcc/config/mips/mips.h|  3 +++
 gcc/config/mips/mips.md   | 15 ++
 gcc/doc/extend.texi   |  6 ++
 .../mips/hazard-barrier-return-attribute.c| 20 +++
 5 files changed, 45 insertions(+)
 create mode 100644 
gcc/testsuite/gcc.target/mips/hazard-barrier-return-attribute.c

diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index 0b25db47a22..b066a2cda75 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -630,6 +630,7 @@ static const struct attribute_spec mips_attribute_table[] = 
{
 mips_handle_use_shadow_register_set_attr, NULL },
   { "keep_interrupts_masked",  0, 0, false, true,  true, false, NULL, NULL },
   { "use_debug_exception_return", 0, 0, false, true, true, false, NULL, NULL },
+  { "use_hazard_barrier_return", 0, 0, true, false, false, false, NULL, NULL },
   { NULL, 0, 0, false, false, false, false, NULL, NULL }
 };
 
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index fbb4372864f..f664d3044e1 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -3386,6 +3386,9 @@ struct GTY(())  machine_function {
 
   /* True if GCC stored callee saved registers in the frame header.  */
   bool use_frame_header_for_callee_saved_regs;
+
+  /* True if the function should generate hazard barrier return.  */
+  bool use_hazard_barrier_return_p;
 };
 #endif
 
diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 10607a57efc..ac1d77afc7d 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -159,6 +159,7 @@
 
   ;; The `.insn' pseudo-op.
   UNSPEC_INSN_PSEUDO
+  UNSPEC_JRHB
 ])
 
 (define_constants
@@ -6679,6 +6680,20 @@
   [(set_attr "type""jump")
(set_attr "mode""none")])
 
+;; Insn to clear execution and instruction hazards while returning.
+;; However, it doesn't clear hazards created by the insn in its delay slot.
+;; Thus, explicitly place a nop in its delay slot.
+
+(define_insn "mips_hb_return_internal"
+  [(return)
+   (unspec_volatile [(match_operand 0 "pmode_register_operand" "")]
+   UNSPEC_JRHB)]
+  ""
+  {
+return "%(jr.hb\t$31%/%)";
+  }
+  [(set_attr "insn_count" "2")])
+
 ;; Normal return.
 
 (define_insn "_internal"
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 1ae68b0f20a..11920d5f07e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -5653,6 +5653,12 @@ On MIPS targets, you can use the @code{nocompression} 
function attribute
 to locally turn off MIPS16 and microMIPS code generation.  This attribute
 overrides the @option{-mips16} and @option{-mmicromips} options on the
 command line (@pxref{MIPS Options}).
+
+@item use_hazard_barrier_return
+@cindex @code{use_hazard_barrier_return} function attribute, MIPS
+This function attribute instructs the compiler to generate a hazard barrier
+return that clears all execution and instruction hazards while returning,
+instead of generating a normal return instruction.
 @end table
 
 @node MSP430 Function Attributes
diff --git a/gcc/testsuite/gcc.target/mips/hazard-barrier-return-attribute.c 
b/gcc/testsuite/gcc.target/mips/hazard-barrier-return-attribute.c
new file mode 100644
index 000..3575af44dcd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/hazard-barrier-return-attribute.c
@@ -0,0 +1,20 @@
+/* Test attribute for clearing hazards while returning.  */
+/* { dg-do compile } */
+/* { dg-options "isa_rev>=2 -mno-mips16" } */
+
+extern int bar ();
+
+static 

Re: [og12] Attempt to register OpenMP pinned memory using a device instead of 'mlock' (was: [PATCH] libgomp, openmp: pinned memory)

[Thomas Schwinge]

Hi Andrew!

On 2023-02-16T23:06:44+0100, I wrote:
> On 2023-02-16T16:17:32+, "Stubbs, Andrew via Gcc-patches" 
>  wrote:
>> The mmap implementation was not optimized for a lot of small allocations, 
>> and I can't see that issue changing here
>
> That's correct, 'mmap' remains.  Under the hood, 'cuMemHostRegister' must
> surely also be doing some 'mlock'-like thing, so I figured it's best to
> feed page-boundary memory regions to it, which 'mmap' gets us.
>
>> so I don't know if this can be used for mlockall replacement.
>>
>> I had assumed that using the Cuda allocator would fix that limitation.
>
> From what I've read (but no first-hand experiments), there's non-trivial
> overhead with 'cuMemHostRegister' (just like with 'mlock'), so routing
> all small allocations individually through it probably isn't a good idea
> either.  Therefore, I suppose, we'll indeed want to use some local
> allocator if we wish this "optimized for a lot of small allocations".

Eh, I suppose your point indirectly was that instead of 'mmap' plus
'cuMemHostRegister' we ought to use 'cuMemAllocHost'/'cuMemHostAlloc', as
we assume those already do implement such a local allocator.  Let me
quickly change that indeed -- we don't currently have a need to use
'cuMemHostRegister' instead of 'cuMemAllocHost'/'cuMemHostAlloc'.

> And, getting rid of 'mlockall' is yet another topic.

Here, the need to use 'cuMemHostRegister' may then again come up, as
begun to discuss as my "different idea" re "-foffload-memory=pinned",
.
(Let's continue that discussion there.)


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [PATCH] [libstdc++] ensure mutex_pool survives _Safe_sequence_base

[Alexandre Oliva via Gcc-patches]

On Feb 17, 2023, Alexandre Oliva  wrote:

> On vxworks, after destroying the semaphore used to implement a mutex,
> __gthread_mutex_lock fails and __gnu_cxx::__mutex::lock calls
> __throw_concurrence_lock_error.  Nothing ensures the mutex_pool
> mutexes survive init-once objects containing _Safe_sequence_base.  If
> such an object completes construction before mutex_pool
> initialization, it will be registered for atexit destruction after the
> mutex_pool mutexes, so the _M_detach_all() call in the
> _Safe_sequence_base dtor will use already-destructed mutexes, and
> basic_string/requirements/citerators_cc fails calling terminate.

Here's an alternative approach, with zero runtime overhead.  Negative
overhead, if you count the time it would have taken to destruct the
mutex pool :-) But it fails to destruct them, which is presumably of no
consequence.

[libstdc++] do not destruct mutex_pool mutexes

[Copy of the paragraph quoted above omitted here]

This patch fixes this problem by ensuring the mutex pool mutexes are
constructed on demand, on a statically-allocated buffer, but never
destructed.

Regstrapped on x86_64-linux-gnu.
Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?

for  libstdc++-v3/ChangeLog

* src/c++11/shared_ptr.cc (__gnu_internal::get_mutex):
Avoid destruction of the mutex pool.
---
 libstdc++-v3/src/c++11/shared_ptr.cc |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/c++11/shared_ptr.cc 
b/libstdc++-v3/src/c++11/shared_ptr.cc
index bc70134359c87..74e879e582896 100644
--- a/libstdc++-v3/src/c++11/shared_ptr.cc
+++ b/libstdc++-v3/src/c++11/shared_ptr.cc
@@ -36,7 +36,11 @@ namespace __gnu_internal _GLIBCXX_VISIBILITY(hidden)
   {
 // increase alignment to put each lock on a separate cache line
 struct alignas(64) M : __gnu_cxx::__mutex { };
-static M m[mask + 1];
+// Use a static buffer, so that the mutexes are not destructed
+// before potential users (or at all)
+static __attribute__ ((aligned(__alignof__(M
+  char buffer[(sizeof (M)) * (mask + 1)];
+static M *m = new (buffer) M[mask + 1];
 return m[i];
   }
 }

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about