Re: [PATCH] Refine ranges using relations in GORI.

[Bernhard Reutner-Fischer via Gcc-patches]

Hi Andrew!

On Thu, 29 Sep 2022 18:36:53 -0400
Andrew MacLeod via Gcc-patches  wrote:

> diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
> index 57a7e820749..b37d03cddda 100644
> --- a/gcc/gimple-range-gori.cc
> +++ b/gcc/gimple-range-gori.cc
> @@ -934,6 +934,115 @@ gori_compute::compute_logical_operands (vrange 
> _range, vrange _range,
>  src.get_operand (false_range, name);
>  }
>  
> +
> +// This routine will try to refine the ranges of OP1 and OP2 given a relation
> +// K between them.  In order to perform this refinement, one of the operands
> +// must be in the definition chain of the other.  The use is refined using
> +// op1/op2_range on the statement, and the defintion is then recalculated
> +// using the relation.

s/defintion/definition/g
And i'd add a 'kind' before K: given a relation_kind K

We've accumulated quite some "defintion" in the meantime. I think arm
expresses it quite well:
gcc/config/arm/unspecs.md:;; Unspec defintions.
nvptx OTOH only supports weak defintions.
Either way, maybe you can correct this typo in at
least gimple-range-gori.cc and value-query.cc ?

> +
> +bool
> +gori_compute::refine_using_relation (tree op1, vrange _range,
> +tree op2, vrange _range,
> +fur_source , relation_kind k)
> +{
> +  gcc_checking_assert (TREE_CODE (op1) == SSA_NAME);
> +  gcc_checking_assert (TREE_CODE (op2) == SSA_NAME);
> +  gcc_checking_assert (k != VREL_VARYING && k != VREL_UNDEFINED);
> +
> +  bool change = false;
> +  bool op1_def_p = in_chain_p (op2, op1);
> +  if (!op1_def_p)
> +if (!in_chain_p (op1, op2))
> +  return false;
> +
> +  tree def_op = op1_def_p ? op1 : op2;
> +  tree use_op = op1_def_p ? op2 : op1;
> +
> +  if (!op1_def_p)
> +k = relation_swap (k);
> +
> +  // op1_def is true if we want to look up op1, otherwise we want op2.
> +  // if neither is the case, we returned in the above check.

I think this comment should be moved up to before setting def_op and
s/op1_def/op1_def_p/
And i hope this ends up as a single if block even if written like above
:)

> +
> +  gimple *def_stmt = SSA_NAME_DEF_STMT (def_op);
> +  gimple_range_op_handler op_handler (def_stmt);
> +  if (!op_handler)
> +return false;
> +  tree def_op1 = op_handler.operand1 ();
> +  tree def_op2 = op_handler.operand2 ();
> +  // if the def isn't binary, the relation will not be useful.
> +  if (!def_op2)
> +return false;
> +
> +  // Determine if op2 is directly referenced as an operand.
> +  if (def_op1 == use_op)
> +{
> +  // def_stmt has op1 in the 1st operand position.
> +  Value_Range other_op (TREE_TYPE (def_op2));
> +  src.get_operand (other_op, def_op2);
> +
> +  // Using op1_range as the LHS, and relation REL, evaluate op2.
> +  tree type = TREE_TYPE (def_op1);
> +  Value_Range new_result (type);
> +  if (!op_handler.op1_range (new_result, type,
> +  op1_def_p ? op1_range : op2_range,
> +  other_op, k))
> + return false;
> +  if (op1_def_p)
> + {
> +   change |= op2_range.intersect (new_result);
> +   // Recalculate op2.
> +   if (op_handler.fold_range (new_result, type, op2_range, other_op))
> + {
> +   change |= op1_range.intersect (new_result);
> + }
> + }
> +  else
> + {
> +   change |= op1_range.intersect (new_result);
> +   // Recalculate op1.
> +   if (op_handler.fold_range (new_result, type, op1_range, other_op))
> + {
> +   change |= op2_range.intersect (new_result);
> + }
> + }
> +}
> +  else if (def_op2 == use_op)
> +{
> +  // def_stmt has op1 in the 1st operand position.

Maybe i'm confused by the swapping, but that's the 2nd operand
position, isn't it? Maybe you forgot to adjust the comments in one of
the blocks?
thanks,

> +  Value_Range other_op (TREE_TYPE (def_op1));
> +  src.get_operand (other_op, def_op1);
> +
> +  // Using op1_range as the LHS, and relation REL, evaluate op2.
> +  tree type = TREE_TYPE (def_op2);
> +  Value_Range new_result (type);
> +  if (!op_handler.op2_range (new_result, type,
> +  op1_def_p ? op1_range : op2_range,
> +  other_op, k))
> + return false;
> +  if (op1_def_p)
> + {
> +   change |= op2_range.intersect (new_result);
> +   // Recalculate op1.
> +   if (op_handler.fold_range (new_result, type, other_op, op2_range))
> + {
> +   change |= op1_range.intersect (new_result);
> + }
> + }
> +  else
> + {
> +   change |= op1_range.intersect (new_result);
> +   // Recalculate op2.
> +   if (op_handler.fold_range (new_result, type, other_op, op1_range))
> + {
> +   change |= op2_range.intersect (new_result);
> + }
> + }
> +}
> +  return change;
> +}
> +
>  // Calculate a range for NAME from the 

[committed][PATCH] Improve Z flag handling on H8

[Jeff Law via Gcc-patches]

This patch improves handling of the Z bit in the status register in a 
variety of ways to improve either the code size or code speed on various 
H8 subtargets.


For example, we can test the zero/nonzero status of the upper byte of a 
16 bit register using mov.b, we can move the Z or an inverted Z into a 
QImode register profitably on some subtargets. We can move Z or an 
inverted Z into the sign bit on the H8/SX profitably, etc.


I've actually had this patch in my tester for over a year, but got crazy 
busy and hadn't bothered to upstream it until now. Naturally it has been 
working all that time without regressions.


Pushed to the trunk.


Jeff


commit 2555071c954aa5796eb3432c15739dcaae457bc3
Author: Jeff Law 
Date:   Sat Oct 1 00:42:15 2022 -0400

Improve Z flag handling on H8

This patch improves handling of the Z bit in the status register in a
variety of ways to improve either the code size or code speed on various
H8 subtargets.

For example, we can test the zero/nonzero status of the upper byte of a
16 bit register using mov.b, we can move the Z or an inverted Z into a
QImode register profitably on some subtargets.  We can move Z or an
inverted Z into the sign bit on the H8/SX profitably, etc.

gcc/

* config/h8300/h8300.md (HSI2): New iterator.
(eqne_invert): Similarly.
* config/h8300/testcompare.md (testhi_upper_z): New pattern.
(cmpqi_z, cmphi_z, cmpsi_z): Likewise.
(store_z_qi, store_z_i_qi, store_z_hi, store_z_hi_sb): New
define_insn_and_splits and/or define_insns.
(store_z_hi_neg, store_z_hi_and, store_z_): Likewise.
(store_z__neg, store_z__and, store_z): Likewise.

diff --git a/gcc/config/h8300/h8300.md b/gcc/config/h8300/h8300.md
index 2da7e7d8a7d..f592af1d5f7 100644
--- a/gcc/config/h8300/h8300.md
+++ b/gcc/config/h8300/h8300.md
@@ -221,6 +221,7 @@
 (define_mode_iterator QHI [QI HI])
 
 (define_mode_iterator HSI [HI SI])
+(define_mode_iterator HSI2 [HI SI])
 
 (define_mode_iterator QHSI [QI HI SI])
 (define_mode_iterator QHSI2 [QI HI SI])
@@ -236,6 +237,7 @@
 (define_code_iterator ors [ior xor])
 
 (define_code_iterator eqne [eq ne])
+(define_code_attr eqne_invert [(eq "ne") (ne "eq")])
 
 ;; For storing the C flag, map from the unsigned comparison to the right
 ;; code for testing the C bit.
diff --git a/gcc/config/h8300/testcompare.md b/gcc/config/h8300/testcompare.md
index 0ee3e360bea..81dce1d0bc1 100644
--- a/gcc/config/h8300/testcompare.md
+++ b/gcc/config/h8300/testcompare.md
@@ -61,6 +61,15 @@
   "mov.b   %t0,%t0"
   [(set_attr "length" "2")])
 
+(define_insn "*tsthi_upper_z"
+  [(set (reg:CCZ CC_REG)
+   (compare (and:HI (match_operand:HI 0 "register_operand" "r")
+(const_int -256))
+(const_int 0)))]
+  "reload_completed"
+  "mov.b   %t0,%t0"
+  [(set_attr "length" "2")])
+
 (define_insn "*tstsi_upper"
   [(set (reg:CCZN CC_REG)
(compare (and:SI (match_operand:SI 0 "register_operand" "r")
@@ -86,6 +95,30 @@
   }
   [(set_attr "length_table" "add")])
 
+(define_insn "*cmpqi_z"
+  [(set (reg:CCZ CC_REG)
+   (eq (match_operand:QI 0 "h8300_dst_operand" "rQ")
+   (match_operand:QI 1 "h8300_src_operand" "rQi")))]
+  "reload_completed"
+  { return "cmp.b  %X1,%X0"; }
+  [(set_attr "length_table" "add")])
+
+(define_insn "*cmphi_z"
+  [(set (reg:CCZ CC_REG)
+   (eq (match_operand:HI 0 "h8300_dst_operand" "rQ")
+   (match_operand:HI 1 "h8300_src_operand" "rQi")))]
+  "reload_completed"
+  { return "cmp.w  %T1,%T0"; }
+  [(set_attr "length_table" "add")])
+
+(define_insn "*cmpsi_z"
+  [(set (reg:CCZ CC_REG)
+   (eq (match_operand:SI 0 "h8300_dst_operand" "rQ")
+   (match_operand:SI 1 "h8300_src_operand" "rQi")))]
+  "reload_completed"
+  { return "cmp.l  %S1,%S0"; }
+  [(set_attr "length_table" "add")])
+
 (define_insn "*cmpqi"
   [(set (reg:CC CC_REG)
(compare (match_operand:QI 0 "h8300_dst_operand" "rQ")
@@ -209,6 +242,8 @@
  return "xor.l\t%S0,%S0\;bist\t#0,%w0";
gcc_unreachable ();
   }
+else
+  gcc_unreachable ();
   }
   [(set (attr "length") (symbol_ref "mode == SImode ? 6 : 4"))])
 
@@ -340,3 +375,235 @@
(ashift:QHSI (:QHSI (reg:CCC CC_REG) (const_int 0))
 (match_dup 3)))])
 
+;; Storing Z into a QImode destination is fairly easy on the H8/S and
+;; newer as the stc; shift; mask is just 3 insns/6 bytes.  On the H8/300H
+;; it is 4 insns/8 bytes which is a speed improvement, but a size
+;; regression relative to the branchy sequence
+;;
+;; Storing inverted Z in QImode is not profitable on the H8/300H, but
+;; is a speed improvement on the H8S.
+(define_insn_and_split "*store_z_qi"
+  [(set (match_operand:QI 0 "register_operand" "=r")
+   (eq:QI (match_operand:HI 1 "register_operand" "r")
+  (match_operand:HI 2 "register_operand" "r")))]
+  

[pushed] c++: loop through array CONSTRUCTOR

[Jason Merrill via Gcc-patches]

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

-- >8 --

I noticed that we were ignoring all the special rules for when to use a
simple INIT_EXPR for array initialization from a CONSTRUCTOR, because
split_nonconstant_init_1 was also passing 1 to the from_array parameter.
Arguably that's the real bug, but I think we can be flexible.

The test that I noticed this with no longer fails without it.

gcc/cp/ChangeLog:

* init.cc (build_vec_init): Clear from_array for CONSTRUCTOR
initializer.
---
 gcc/cp/init.cc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index a85c3032130..bf46578c08b 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -4394,6 +4394,10 @@ build_vec_init (tree base, tree maxindex, tree init,
}
 }
 
+  /* from_array doesn't apply to initialization from CONSTRUCTOR.  */
+  if (init && TREE_CODE (init) == CONSTRUCTOR)
+from_array = 0;
+
   /* If we have a braced-init-list or string constant, make sure that the array
  is big enough for all the initializers.  */
   bool length_check = (init
@@ -4493,7 +4497,7 @@ build_vec_init (tree base, tree maxindex, tree init,
   /* If initializing one array from another, initialize element by
  element.  We rely upon the below calls to do the argument
  checking.  Evaluate the initializer before entering the try block.  */
-  if (from_array && init && TREE_CODE (init) != CONSTRUCTOR)
+  if (from_array)
 {
   if (lvalue_kind (init) & clk_rvalueref)
xvalue = true;

base-commit: aa360fbf68b11e54017e8fa5b1bdb87ce7c19188
prerequisite-patch-id: 69446a92a4457ed6068289cdcdb5a4c74b4d
-- 
2.31.1

[pushed] c++: cast split_nonconstant_init return val to void

[Jason Merrill via Gcc-patches]

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

-- >8 --

We were already converting the result of expand_vec_init_expr to void; we
need to do the same for split_nonconstant_init.

The test that I noticed this with no longer fails without it.

gcc/cp/ChangeLog:

* cp-gimplify.cc (cp_genericize_init): Also convert the result of
split_nonconstant_init to void.
---
 gcc/cp/cp-gimplify.cc | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 7354783..cca3b9fea33 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -892,13 +892,9 @@ omp_cxx_notice_variable (struct cp_genericize_omp_taskreg 
*omp_ctx, tree decl)
 static void
 cp_genericize_init (tree *replace, tree from, tree to)
 {
+  tree init = NULL_TREE;
   if (TREE_CODE (from) == VEC_INIT_EXPR)
-{
-  tree init = expand_vec_init_expr (to, from, tf_warning_or_error);
-
-  /* Make cp_gimplify_init_expr call replace_decl.  */
-  *replace = fold_convert (void_type_node, init);
-}
+init = expand_vec_init_expr (to, from, tf_warning_or_error);
   else if (flag_exceptions
   && TREE_CODE (from) == CONSTRUCTOR
   && TREE_SIDE_EFFECTS (from)
@@ -906,7 +902,16 @@ cp_genericize_init (tree *replace, tree from, tree to)
 {
   to = cp_stabilize_reference (to);
   replace_placeholders (from, to);
-  *replace = split_nonconstant_init (to, from);
+  init = split_nonconstant_init (to, from);
+}
+
+  if (init)
+{
+  if (*replace == from)
+   /* Make cp_gimplify_init_expr call replace_decl on this
+  TARGET_EXPR_INITIAL.  */
+   init = fold_convert (void_type_node, init);
+  *replace = init;
 }
 }
 

base-commit: aa360fbf68b11e54017e8fa5b1bdb87ce7c19188
-- 
2.31.1

Re: [PATCH] Fix the build of record_edge_info()

[Palmer Dabbelt]

On Fri, 30 Sep 2022 18:01:00 PDT (-0700), jeffreya...@gmail.com wrote:


On 9/30/22 18:57, Palmer Dabbelt wrote:

As of 1214196da79 ("More gimple const/copy propagation opportunities"),
I'm getting some build failures during bootstrap

 ../../gcc/tree-ssa-dom.cc: In function ‘void 
record_edge_info(basic_block)’:
 ../../gcc/tree-ssa-dom.cc:689:27: error: ‘dst’ was not declared in this 
scope; did you mean ‘dse’?
   689 |   if (dst == PHI_ARG_DEF (phi, !alternative))
   |   ^~~
   |   dse
 In file included from ../../gcc/gimple-ssa.h:24,
  from ../../gcc/ssa.h:27,
  from ../../gcc/tree-ssa-dom.cc:28:
 ../../gcc/tree-ssa-dom.cc:689:47: error: ‘phi’ was not declared in this 
scope; did you mean ‘gphi’?
   689 |   if (dst == PHI_ARG_DEF (phi, !alternative))
   |   ^~~
 ../../gcc/tree-ssa-operands.h:82:54: note: in definition of macro 
‘PHI_ARG_DEF’
82 | #define PHI_ARG_DEF(PHI, I) gimple_phi_arg_def ((PHI), (I))
   |

I've never looked at this stuff before so I've sort of just pattern
matched this, it at least fixes the build.  Happy to go try and
understand what's going on here, but I'm in the middle of a few things
so I figured it'd be better to just send it along in case anyone else is
running into the same issue -- it's more of a bug report than a fix,
though.

gcc/ChangeLog

* tree-ssa-dom.c (record_edge_info): Move the alternative check
below the phi definition.
---


You got it right, but it's already fixed on the trunk (I pushed the
wrong version of the patch).


Thanks, I must have just had some unlucky timing ;)

Re: [PATCH] Fix the build of record_edge_info()

[Jeff Law via Gcc-patches]

On 9/30/22 18:57, Palmer Dabbelt wrote:

As of 1214196da79 ("More gimple const/copy propagation opportunities"),
I'm getting some build failures during bootstrap

 ../../gcc/tree-ssa-dom.cc: In function ‘void 
record_edge_info(basic_block)’:
 ../../gcc/tree-ssa-dom.cc:689:27: error: ‘dst’ was not declared in this 
scope; did you mean ‘dse’?
   689 |   if (dst == PHI_ARG_DEF (phi, !alternative))
   |   ^~~
   |   dse
 In file included from ../../gcc/gimple-ssa.h:24,
  from ../../gcc/ssa.h:27,
  from ../../gcc/tree-ssa-dom.cc:28:
 ../../gcc/tree-ssa-dom.cc:689:47: error: ‘phi’ was not declared in this 
scope; did you mean ‘gphi’?
   689 |   if (dst == PHI_ARG_DEF (phi, !alternative))
   |   ^~~
 ../../gcc/tree-ssa-operands.h:82:54: note: in definition of macro 
‘PHI_ARG_DEF’
82 | #define PHI_ARG_DEF(PHI, I) gimple_phi_arg_def ((PHI), (I))
   |

I've never looked at this stuff before so I've sort of just pattern
matched this, it at least fixes the build.  Happy to go try and
understand what's going on here, but I'm in the middle of a few things
so I figured it'd be better to just send it along in case anyone else is
running into the same issue -- it's more of a bug report than a fix,
though.

gcc/ChangeLog

* tree-ssa-dom.c (record_edge_info): Move the alternative check
below the phi definition.
---


You got it right, but it's already fixed on the trunk (I pushed the 
wrong version of the patch).



jeff

[PATCH] Fix the build of record_edge_info()

[Palmer Dabbelt]

As of 1214196da79 ("More gimple const/copy propagation opportunities"),
I'm getting some build failures during bootstrap

../../gcc/tree-ssa-dom.cc: In function ‘void record_edge_info(basic_block)’:
../../gcc/tree-ssa-dom.cc:689:27: error: ‘dst’ was not declared in this 
scope; did you mean ‘dse’?
  689 |   if (dst == PHI_ARG_DEF (phi, !alternative))
  |   ^~~
  |   dse
In file included from ../../gcc/gimple-ssa.h:24,
 from ../../gcc/ssa.h:27,
 from ../../gcc/tree-ssa-dom.cc:28:
../../gcc/tree-ssa-dom.cc:689:47: error: ‘phi’ was not declared in this 
scope; did you mean ‘gphi’?
  689 |   if (dst == PHI_ARG_DEF (phi, !alternative))
  |   ^~~
../../gcc/tree-ssa-operands.h:82:54: note: in definition of macro 
‘PHI_ARG_DEF’
   82 | #define PHI_ARG_DEF(PHI, I) gimple_phi_arg_def ((PHI), (I))
  |

I've never looked at this stuff before so I've sort of just pattern
matched this, it at least fixes the build.  Happy to go try and
understand what's going on here, but I'm in the middle of a few things
so I figured it'd be better to just send it along in case anyone else is
running into the same issue -- it's more of a bug report than a fix,
though.

gcc/ChangeLog

* tree-ssa-dom.c (record_edge_info): Move the alternative check
below the phi definition.
---
 gcc/tree-ssa-dom.cc | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/tree-ssa-dom.cc b/gcc/tree-ssa-dom.cc
index 8d8312ca350..e6b8dace5e9 100644
--- a/gcc/tree-ssa-dom.cc
+++ b/gcc/tree-ssa-dom.cc
@@ -684,11 +684,6 @@ record_edge_info (basic_block bb)
   !gsi_end_p (gsi);
   gsi_next ())
{
- /* If the other alternative is the same as the result,
-then this is a degenerate and can be ignored.  */
- if (dst == PHI_ARG_DEF (phi, !alternative))
-   continue;
-
  /* Now get the EDGE_INFO class so we can append
 it to our list.  We want the successor edge
 where the destination is not the source of
@@ -697,6 +692,11 @@ record_edge_info (basic_block bb)
  tree src = PHI_ARG_DEF (phi, alternative);
  tree dst = PHI_RESULT (phi);
 
+ /* If the other alternative is the same as the result,
+then this is a degenerate and can be ignored.  */
+ if (dst == PHI_ARG_DEF (phi, !alternative))
+   continue;
+
  if (EDGE_SUCC (bb, 0)->dest
  != EDGE_PRED (bb, !alternative)->src)
edge_info = (class edge_info *)EDGE_SUCC (bb, 0)->aux;
-- 
2.34.1

Re: [committed] Minor cleanup/prep in DOM

[Jeff Law]

On 9/30/22 18:07, H.J. Lu wrote:

On Fri, Sep 30, 2022 at 4:06 PM Jeff Law  wrote:


It's a bit weird that free_dom_edge_info leaves a dangling pointer in
e->aux.  Not sure what I was thinking.


There's two callers.  One wipes e->aux immediately after the call, the
other attaches a newly created object immediately after the call.  So we
can wipe e->aux within the call and simplify one of the two call sites.

This is preparatory work for a minor optimization where we want to
detect another class of edge equivalences in DOM (until something better
is available) and either attach them an existing edge_info structure or
create a new one if one doesn't currently exist for a given edge.

Bootstrapped and regression tested on x86_64.  Installing on the trunk.


I got


[ ... ]

Pushed wrong version.  Sorry about that.  Fixed by attached patch which 
just moves the test down to its proper position.



Jeff


commit aa360fbf68b11e54017e8fa5b1bdb87ce7c19188
Author: Jeff Law 
Date:   Fri Sep 30 20:46:04 2022 -0400

Install correct patch version.

gcc/
* tree-ssa-dom.cc (record_edge_info): Install correct version of
patch.

diff --git a/gcc/tree-ssa-dom.cc b/gcc/tree-ssa-dom.cc
index 8d8312ca350..e6b8dace5e9 100644
--- a/gcc/tree-ssa-dom.cc
+++ b/gcc/tree-ssa-dom.cc
@@ -684,11 +684,6 @@ record_edge_info (basic_block bb)
   !gsi_end_p (gsi);
   gsi_next ())
{
- /* If the other alternative is the same as the result,
-then this is a degenerate and can be ignored.  */
- if (dst == PHI_ARG_DEF (phi, !alternative))
-   continue;
-
  /* Now get the EDGE_INFO class so we can append
 it to our list.  We want the successor edge
 where the destination is not the source of
@@ -697,6 +692,11 @@ record_edge_info (basic_block bb)
  tree src = PHI_ARG_DEF (phi, alternative);
  tree dst = PHI_RESULT (phi);
 
+ /* If the other alternative is the same as the result,
+then this is a degenerate and can be ignored.  */
+ if (dst == PHI_ARG_DEF (phi, !alternative))
+   continue;
+
  if (EDGE_SUCC (bb, 0)->dest
  != EDGE_PRED (bb, !alternative)->src)
edge_info = (class edge_info *)EDGE_SUCC (bb, 0)->aux;

Re: [committed] Minor cleanup/prep in DOM

[H.J. Lu via Gcc-patches]

On Fri, Sep 30, 2022 at 4:06 PM Jeff Law  wrote:
>
>
> It's a bit weird that free_dom_edge_info leaves a dangling pointer in
> e->aux.  Not sure what I was thinking.
>
>
> There's two callers.  One wipes e->aux immediately after the call, the
> other attaches a newly created object immediately after the call.  So we
> can wipe e->aux within the call and simplify one of the two call sites.
>
> This is preparatory work for a minor optimization where we want to
> detect another class of edge equivalences in DOM (until something better
> is available) and either attach them an existing edge_info structure or
> create a new one if one doesn't currently exist for a given edge.
>
> Bootstrapped and regression tested on x86_64.  Installing on the trunk.
>

I got


/export/gnu/import/git/sources/gcc/gcc/tree-ssa-dom.cc: In function
‘void record_edge_info(basic_block)’:
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-dom.cc:689:27: error:
‘dst’ was not declared in this scope; did you mean ‘dse’?
  689 |   if (dst == PHI_ARG_DEF (phi, !alternative))
  |   ^~~
  |   dse
In file included from /export/gnu/import/git/sources/gcc/gcc/gimple-ssa.h:24,
 from /export/gnu/import/git/sources/gcc/gcc/ssa.h:27,
 from /export/gnu/import/git/sources/gcc/gcc/tree-ssa-dom.cc:28:
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-dom.cc:689:47: error:
‘phi’ was not declared in this scope; did you mean ‘gphi’?
  689 |   if (dst == PHI_ARG_DEF (phi, !alternative))
  |   ^~~
/export/gnu/import/git/sources/gcc/gcc/tree-ssa-operands.h:82:54:
note: in definition of macro ‘PHI_ARG_DEF’
   82 | #define PHI_ARG_DEF(PHI, I) gimple_phi_arg_def ((PHI), (I))
  |  ^~~
make: *** [Makefile:1146: tree-ssa-dom.o] Error 1

-- 
H.J.

[committed] More gimple const/copy propagation opportunities

[Jeff Law]

While investigating a benchmark for optimization opportunities I came 
across single block loop which either iterates precisely once or 
forever.    This is an interesting scenario as we can ignore the 
infinite looping path and treat any PHI nodes as degenerates. So more 
concretely let's consider this trivial testcase:


volatile void abort (void);

void
foo(int a)
{
 int b = 0;

 while (1)
   {
 if (!a)
   break;
 b = 1;
   }

 if (b != 0)
   abort ();
}




Quick analysis shows that b's initial value is 0 and its value only 
changes if we enter an infinite loop.  So if we get to the test b != 0, 
the only possible value b could have would be 0 and the test and its 
true arm can be eliminated.



The DOM3 dump looks something like this:

;;   basic block 2, loop depth 0, count 118111600 (estimated locally), 
maybe hot

;;    prev block 0, next block 3, flags: (NEW, VISITED)
;;    pred:   ENTRY [always]  count:118111600 (estimated locally) 
(FALLTHRU,EXECUTABLE)
;;    succ:   3 [always]  count:118111600 (estimated locally) 
(FALLTHRU,EXECUTABLE)


;;   basic block 3, loop depth 1, count 1073741824 (estimated locally), 
maybe hot

;;    prev block 2, next block 4, flags: (NEW, VISITED)
;;    pred:   2 [always]  count:118111600 (estimated locally) 
(FALLTHRU,EXECUTABLE)
;;    3 [89.0% (guessed)]  count:955630224 (estimated 
locally) (FALSE_VALUE,EXECUTABLE)

  # b_1 = PHI <0(2), 1(3)>
  if (a_3(D) == 0)
    goto ; [11.00%]
  else
    goto ; [89.00%]
;;    succ:   4 [11.0% (guessed)]  count:118111600 (estimated 
locally) (TRUE_VALUE,EXECUTABLE)
;;    3 [89.0% (guessed)]  count:955630224 (estimated 
locally) (FALSE_VALUE,EXECUTABLE)


;;   basic block 4, loop depth 0, count 118111600 (estimated locally), 
maybe hot

;;    prev block 3, next block 5, flags: (NEW, VISITED)
;;    pred:   3 [11.0% (guessed)]  count:118111600 (estimated 
locally) (TRUE_VALUE,EXECUTABLE)

  if (b_1 != 0)
    goto ; [0.00%]
  else
    goto ; [100.00%]
;;    succ:   5 [never]  count:0 (precise) (TRUE_VALUE,EXECUTABLE)
;;    6 [always]  count:118111600 (estimated locally) 
(FALSE_VALUE,EXECUTABLE)


This is a good representative of what the benchmark code looks like.


The primary effect we want to capture is to realize that the test if 
(b_1 != 0) is always false and optimize it accordingly.



In the benchmark, this opportunity is well hidden until after the loop 
optimizers have completed, so the first chance to capture this case is 
in DOM3.  Furthermore, DOM wants loops normalized with latch 
blocks/edges.  So instead of bb3 looping back to itself, there's an 
intermediate empty block during DOM.


I originally thought this was likely to only affect the benchmark.  But 
when I instrumented the optimization and bootstrapped GCC, much to my 
surprise there were several hundred similar cases identified in GCC 
itself.  So it's not as benchmark specific as I'd initially feared.



Anyway, detecting this in DOM is pretty simple.   We detect the infinite 
loop, including the latch block.  Once we've done that, we walk the PHI 
nodes and attach equivalences to the appropriate outgoing edge.   That's 
all we need to do as the rest of DOM is already prepared to handle 
equivalences on edges.



Pushed to the trunk,


Jeff
commit 1214196da79aabbe5c14ed36e5a28012e141f04c
Author: Jeff Law 
Date:   Fri Sep 30 19:26:31 2022 -0400

More gimple const/copy propagation opportunities

While investigating a benchmark for optimization opportunities I came 
across single block loop which either iterates precisely once or forever.
This is an interesting scenario as we can ignore the infinite looping path and 
treat any PHI nodes as degenerates.  So more concretely let's consider this 
trivial testcase:

volatile void abort (void);

void
foo(int a)
{
 int b = 0;

 while (1)
   {
 if (!a)
   break;
 b = 1;
   }

 if (b != 0)
   abort ();
}

Quick analysis shows that b's initial value is 0 and its value only changes 
if we enter an infinite loop.  So if we get to the test b != 0, the only 
possible value b could have would be 0 and the test and its true arm can be 
eliminated.

The DOM3 dump looks something like this:

;;   basic block 2, loop depth 0, count 118111600 (estimated locally), 
maybe hot
;;prev block 0, next block 3, flags: (NEW, VISITED)
;;pred:   ENTRY [always]  count:118111600 (estimated locally) 
(FALLTHRU,EXECUTABLE)
;;succ:   3 [always]  count:118111600 (estimated locally) 
(FALLTHRU,EXECUTABLE)

;;   basic block 3, loop depth 1, count 1073741824 (estimated locally), 
maybe hot
;;prev block 2, next block 4, flags: (NEW, VISITED)
;;pred:   2 [always]  count:118111600 (estimated locally) 
(FALLTHRU,EXECUTABLE)
;;3 [89.0% (guessed)]  count:955630224 (estimated 

[committed] Minor cleanup/prep in DOM

[Jeff Law]

It's a bit weird that free_dom_edge_info leaves a dangling pointer in 
e->aux.  Not sure what I was thinking.



There's two callers.  One wipes e->aux immediately after the call, the 
other attaches a newly created object immediately after the call.  So we 
can wipe e->aux within the call and simplify one of the two call sites.


This is preparatory work for a minor optimization where we want to 
detect another class of edge equivalences in DOM (until something better 
is available) and either attach them an existing edge_info structure or 
create a new one if one doesn't currently exist for a given edge.


Bootstrapped and regression tested on x86_64.  Installing on the trunk.


Jeff

commit fbd95c027edcc169cc3b40806375fbabc08500e0
Author: Jeff Law 
Date:   Fri Sep 30 18:59:24 2022 -0400

Minor cleanup/prep in DOM

It's a bit weird that free_dom_edge_info leaves a dangling pointer in 
e->aux.
Not sure what I was thinking.

There's two callers.  One wipes e->aux immediately after the call, the other
attaches a newly created object immediately after the call.  So we can wipe
e->aux within the call and simplify one of the two call sites.

This is preparatory work for a minor optimization where we want to detect
another class of edge equivalences in DOM (until something better is 
available)
and either attach them an existing edge_info structure or create a new one 
if
one doesn't currently exist for a given edge.

gcc/
* tree-ssa-dom.cc (free_dom_edge_info): Clear e->aux too.
(free_all_edge_infos): Do not clear e->aux here.

diff --git a/gcc/tree-ssa-dom.cc b/gcc/tree-ssa-dom.cc
index 84bef798f52..fa43dbe6c44 100644
--- a/gcc/tree-ssa-dom.cc
+++ b/gcc/tree-ssa-dom.cc
@@ -393,7 +393,8 @@ edge_info::record_simple_equiv (tree lhs, tree rhs)
 simple_equivalences.safe_push (equiv_pair (lhs, rhs));
 }
 
-/* Free the edge_info data attached to E, if it exists.  */
+/* Free the edge_info data attached to E, if it exists and
+   clear e->aux.  */
 
 void
 free_dom_edge_info (edge e)
@@ -402,6 +403,7 @@ free_dom_edge_info (edge e)
 
   if (edge_info)
 delete edge_info;
+  e->aux = NULL;
 }
 
 /* Free all EDGE_INFO structures associated with edges in the CFG.
@@ -420,10 +422,7 @@ free_all_edge_infos (void)
   FOR_EACH_BB_FN (bb, cfun)
 {
   FOR_EACH_EDGE (e, ei, bb->preds)
-{
- free_dom_edge_info (e);
- e->aux = NULL;
-   }
+   free_dom_edge_info (e);
 }
 }
 

Re: [PATCH] Document -fexcess-precision=16 in tm.texi

[Palmer Dabbelt]

On Fri, 30 Sep 2022 15:51:02 PDT (-0700), H.J. Lu wrote:

On Fri, Sep 30, 2022 at 3:25 PM Palmer Dabbelt  wrote:


On Sat, 24 Sep 2022 19:13:36 PDT (-0700), san...@codesourcery.com wrote:
> On 9/18/22 02:47, Palmer Dabbelt wrote:
>> On Fri, 09 Sep 2022 02:46:40 PDT (-0700), Palmer Dabbelt wrote:
>>> I just happened to stuble on this one while trying to sort out the
>>> RISC-V bits.
>>>
>>> gcc/ChangeLog
>>>
>>> * doc/tm.texi (TARGET_C_EXCESS_PRECISION): Add 16.
>>> ---
>>>  gcc/doc/tm.texi | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
>>> index 858bfb80cec..7590924f2ca 100644
>>> --- a/gcc/doc/tm.texi
>>> +++ b/gcc/doc/tm.texi
>>> @@ -1009,7 +1009,7 @@ of the excess precision explicitly added.  For
>>>  @code{EXCESS_PRECISION_TYPE_FLOAT16}, and
>>>  @code{EXCESS_PRECISION_TYPE_FAST}, the target should return the
>>>  explicit excess precision that should be added depending on the
>>> -value set for @option{-fexcess-precision=@r{[}standard@r{|}fast@r{]}}.
>>> +value set for
>>> @option{-fexcess-precision=@r{[}standard@r{|}fast@r{|}16@r{]}}.
>>>  Note that unpredictable explicit excess precision does not make sense,
>>>  so a target should never return @code{FLT_EVAL_METHOD_UNPREDICTABLE}
>>>  when @var{type} is @code{EXCESS_PRECISION_TYPE_STANDARD},
>>
>> Just pinging this one as I'm not sure if it's OK to self-approve -- no
>> rush on my end, I already figured it out so I don't need the
>> documentation any more.
>
> This is fine, looks like a trivial correction.

Thanks, committed.


tm.texi is a generated file.  I am checking in this patch to restore bootstrap.


Sorry about that, and thanks for fixing it.

Re: [PATCH] Document -fexcess-precision=16 in tm.texi

[H.J. Lu via Gcc-patches]

On Fri, Sep 30, 2022 at 3:25 PM Palmer Dabbelt  wrote:
>
> On Sat, 24 Sep 2022 19:13:36 PDT (-0700), san...@codesourcery.com wrote:
> > On 9/18/22 02:47, Palmer Dabbelt wrote:
> >> On Fri, 09 Sep 2022 02:46:40 PDT (-0700), Palmer Dabbelt wrote:
> >>> I just happened to stuble on this one while trying to sort out the
> >>> RISC-V bits.
> >>>
> >>> gcc/ChangeLog
> >>>
> >>> * doc/tm.texi (TARGET_C_EXCESS_PRECISION): Add 16.
> >>> ---
> >>>  gcc/doc/tm.texi | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> >>> index 858bfb80cec..7590924f2ca 100644
> >>> --- a/gcc/doc/tm.texi
> >>> +++ b/gcc/doc/tm.texi
> >>> @@ -1009,7 +1009,7 @@ of the excess precision explicitly added.  For
> >>>  @code{EXCESS_PRECISION_TYPE_FLOAT16}, and
> >>>  @code{EXCESS_PRECISION_TYPE_FAST}, the target should return the
> >>>  explicit excess precision that should be added depending on the
> >>> -value set for @option{-fexcess-precision=@r{[}standard@r{|}fast@r{]}}.
> >>> +value set for
> >>> @option{-fexcess-precision=@r{[}standard@r{|}fast@r{|}16@r{]}}.
> >>>  Note that unpredictable explicit excess precision does not make sense,
> >>>  so a target should never return @code{FLT_EVAL_METHOD_UNPREDICTABLE}
> >>>  when @var{type} is @code{EXCESS_PRECISION_TYPE_STANDARD},
> >>
> >> Just pinging this one as I'm not sure if it's OK to self-approve -- no
> >> rush on my end, I already figured it out so I don't need the
> >> documentation any more.
> >
> > This is fine, looks like a trivial correction.
>
> Thanks, committed.

tm.texi is a generated file.  I am checking in this patch to restore bootstrap.

-- 
H.J.
--
diff --git a/gcc/target.def b/gcc/target.def
index 4d49ffc2c88..a3d3b04a165 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -6181,7 +6181,7 @@ of the excess precision explicitly added.  For\n\
 @code{EXCESS_PRECISION_TYPE_FLOAT16}, and\n\
 @code{EXCESS_PRECISION_TYPE_FAST}, the target should return the\n\
 explicit excess precision that should be added depending on the\n\
-value set for @option{-fexcess-precision=@r{[}standard@r{|}fast@r{]}}.\n\
+value set for 
@option{-fexcess-precision=@r{[}standard@r{|}fast@r{|}16@r{]}}.\n\
 Note that unpredictable explicit excess precision does not make sense,\n\
 so a target should never return @code{FLT_EVAL_METHOD_UNPREDICTABLE}\n\
 when @var{type} is @code{EXCESS_PRECISION_TYPE_STANDARD},\n\

Re: [PATCH RFC] c++: fix broken conversion in coroutines

[Iain Sandoe]

Hi Jason,

> On 30 Sep 2022, at 23:06, Jason Merrill  wrote:
> 
> You can't use CONVERT_EXPR to convert between two class types, and it was
> breaking copy elision.
> 
> Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where
> susp_type is Loopy::handle_type.  How is this supposed to work?

We are trying to save a type-erased handle (which the symmetric transfer makes
and indirect call through, nothing else).

so, I suppose the equivalent could be:

conthand = coroutine_handle::from_address (suspend.address())

or, is there some cast version that would be valid here?
Iain

> 
> gcc/cp/ChangeLog:
> 
>   * coroutines.cc (expand_one_await_expression): Change conversion
>   to assert.
> ---
> gcc/cp/coroutines.cc | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> index eca01abcb7a..568f2edf67d 100644
> --- a/gcc/cp/coroutines.cc
> +++ b/gcc/cp/coroutines.cc
> @@ -1728,7 +1728,9 @@ expand_one_await_expression (tree *stmt, tree 
> *await_expr, void *d)
> }
>   else
> {
> -  r = build1_loc (loc, CONVERT_EXPR, void_coro_handle_type, suspend);
> +  gcc_checking_assert (same_type_ignoring_top_level_qualifiers_p
> +(void_coro_handle_type, susp_type));
> +  r = suspend;
>   r = build2_loc (loc, INIT_EXPR, void_coro_handle_type, data->conthand, 
> r);
>   r = build1 (CONVERT_EXPR, void_type_node, r);
>   append_to_statement_list (r, _list);
> 
> base-commit: 43faf3e5445b571731e52faa1be085ecd0a09323
> -- 
> 2.31.1
> 

Re: [PATCH] Document -fexcess-precision=16 in tm.texi

[Palmer Dabbelt]

On Sat, 24 Sep 2022 19:13:36 PDT (-0700), san...@codesourcery.com wrote:

On 9/18/22 02:47, Palmer Dabbelt wrote:

On Fri, 09 Sep 2022 02:46:40 PDT (-0700), Palmer Dabbelt wrote:

I just happened to stuble on this one while trying to sort out the
RISC-V bits.

gcc/ChangeLog

* doc/tm.texi (TARGET_C_EXCESS_PRECISION): Add 16.
---
 gcc/doc/tm.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 858bfb80cec..7590924f2ca 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -1009,7 +1009,7 @@ of the excess precision explicitly added.  For
 @code{EXCESS_PRECISION_TYPE_FLOAT16}, and
 @code{EXCESS_PRECISION_TYPE_FAST}, the target should return the
 explicit excess precision that should be added depending on the
-value set for @option{-fexcess-precision=@r{[}standard@r{|}fast@r{]}}.
+value set for
@option{-fexcess-precision=@r{[}standard@r{|}fast@r{|}16@r{]}}.
 Note that unpredictable explicit excess precision does not make sense,
 so a target should never return @code{FLT_EVAL_METHOD_UNPREDICTABLE}
 when @var{type} is @code{EXCESS_PRECISION_TYPE_STANDARD},


Just pinging this one as I'm not sure if it's OK to self-approve -- no
rush on my end, I already figured it out so I don't need the
documentation any more.


This is fine, looks like a trivial correction.


Thanks, committed.

Re: [PATCH] RISC-V: Support -fexcess-precision=16

[Palmer Dabbelt]

On Fri, 09 Sep 2022 02:56:26 PDT (-0700), Kito Cheng wrote:

LGTM, seems like you have landed now, see you soon :)


Committed.



On Fri, Sep 9, 2022 at 5:44 PM Palmer Dabbelt  wrote:


This fixes f19a327077e ("Support -fexcess-precision=16 which will enable
FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.") on
RISC-V targets.

gcc/ChangeLog

PR target/106815
* config/riscv/riscv.cc (riscv_excess_precision): Add support
for EXCESS_PRECISION_TYPE_FLOAT16.
---
 gcc/config/riscv/riscv.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 675d92c0961..9b6d3e95b1b 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5962,6 +5962,7 @@ riscv_excess_precision (enum excess_precision_type type)
   return (TARGET_ZFH ? FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16
 : FLT_EVAL_METHOD_PROMOTE_TO_FLOAT);
 case EXCESS_PRECISION_TYPE_IMPLICIT:
+case EXCESS_PRECISION_TYPE_FLOAT16:
   return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16;
 default:
   gcc_unreachable ();
--
2.34.1


To:  gcc-patches@gcc.gnu.org
CC:  gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] RISC-V: Support -fexcess-precision=16
In-Reply-To: 


On Fri, 09 Sep 2022 02:56:26 PDT (-0700), gcc-patches@gcc.gnu.org wrote:

LGTM, seems like you have landed now, see you soon :)

On Fri, Sep 9, 2022 at 5:44 PM Palmer Dabbelt  wrote:


This fixes f19a327077e ("Support -fexcess-precision=16 which will enable
FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.") on
RISC-V targets.

gcc/ChangeLog

PR target/106815
* config/riscv/riscv.cc (riscv_excess_precision): Add support
for EXCESS_PRECISION_TYPE_FLOAT16.
---
 gcc/config/riscv/riscv.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 675d92c0961..9b6d3e95b1b 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5962,6 +5962,7 @@ riscv_excess_precision (enum excess_precision_type type)
   return (TARGET_ZFH ? FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16
 : FLT_EVAL_METHOD_PROMOTE_TO_FLOAT);
 case EXCESS_PRECISION_TYPE_IMPLICIT:
+case EXCESS_PRECISION_TYPE_FLOAT16:
   return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16;
 default:
   gcc_unreachable ();
--
2.34.1

[PATCH RFC] c++: fix broken conversion in coroutines

[Jason Merrill via Gcc-patches]

You can't use CONVERT_EXPR to convert between two class types, and it was
breaking copy elision.

Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where
susp_type is Loopy::handle_type.  How is this supposed to work?

gcc/cp/ChangeLog:

* coroutines.cc (expand_one_await_expression): Change conversion
to assert.
---
 gcc/cp/coroutines.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index eca01abcb7a..568f2edf67d 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1728,7 +1728,9 @@ expand_one_await_expression (tree *stmt, tree 
*await_expr, void *d)
 }
   else
 {
-  r = build1_loc (loc, CONVERT_EXPR, void_coro_handle_type, suspend);
+  gcc_checking_assert (same_type_ignoring_top_level_qualifiers_p
+  (void_coro_handle_type, susp_type));
+  r = suspend;
   r = build2_loc (loc, INIT_EXPR, void_coro_handle_type, data->conthand, 
r);
   r = build1 (CONVERT_EXPR, void_type_node, r);
   append_to_statement_list (r, _list);

base-commit: 43faf3e5445b571731e52faa1be085ecd0a09323
-- 
2.31.1

Re: [PATCH] testsuite: Windows paths use \ and not /

[Jonathan Wakely via Gcc-patches]

On Fri, 30 Sept 2022 at 19:13, Jonathan Wakely via Libstdc++
 wrote:
>
> On Fri, 30 Sept 2022 at 19:07, Jonathan Wakely  wrote:
> >
> > On Fri, 30 Sept 2022 at 19:04, Jonathan Wakely  wrote:
> > >
> > > On Fri, 30 Sept 2022 at 18:55, Jakub Jelinek  wrote:
> > > >
> > > > On Fri, Sep 30, 2022 at 06:47:07PM +0100, Jonathan Wakely via 
> > > > Gcc-patches wrote:
> > > > > On Fri, 30 Sept 2022 at 17:26, Jonathan Wakely wrote:
> > > > > >
> > > > > > On Fri, 30 Sept 2022 at 17:04, Torbjörn SVENSSON
> > > > > >  wrote:
> > > > > > >
> > > > > > > libstdc++-v3/testsuite:
> > > > > > >
> > > > > > > * 20_util/bind/ref_neg.cc: Prune Windows paths too.
> > > > > >
> > > > > > Please CC the libstdc++ for libstdc++ patches.
> > > > > >
> > > > > > OK for trunk, thanks.
> > > > >
> > > > > I'm seeing errors now on x86_64-linux:
> > > > >
> > > > > ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> > > > > dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "
> > > > >
> > > > > ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> > > > > dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "
> > > >
> > > > Bet it should be
> > > > // { dg-prune-output "\[/\\](functional|bits\[/\\]invoke.h):" }
> > > > or so.  Completely untested.
> > >
> > > That fixes the error, but now the regex doesn't match so there are
> > > still excess errors. It needs to be:
> > >
> > > // { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):.*" }
> > >
> > > Without any regex special characters, there's an implicit .* before
> > > and after the pattern. But when you use any regex special characters
> > > in the pattern, it stops working. I can't remember why. I figured it
> > > out once.
> >
> > It looks like just adding .* at the start is enough:
> >
> > // { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):" }
> >
> > But that's so ugly, I'm tempted to replace that prune with something 
> > different.
>
> I'll finish testing this and push it.

I committed this instead, with no .* in the pattern.
commit 7069d03ba4ad6133225b89d433d9e86f0b0745b8
Author: Jonathan Wakely 
Date:   Fri Sep 30 19:10:29 2022

libstdc++: Fix broken dg-prune-output

The new pattern in the dg-prune-output directive doesn't work. Instead
of a messy regex full of leaning toothpicks, just match on the
diagnostic text instead of the header paths.

libstdc++-v3/ChangeLog:

* testsuite/20_util/bind/ref_neg.cc: Fix dg-prune-output
directive.

diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
index 1e9f3e7fece..a78935775c2 100644
--- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
@@ -50,7 +50,7 @@ void test02()
 
 // Ignore the reasons for deduction/substitution failure in the headers.
 // Arrange for the match to work on installed trees as well as build trees.
-// { dg-prune-output "[/\\](functional|bits/invoke.h):" }
+// { dg-prune-output "no type named 'type' in 'struct std::result_of" }
 
 int main()
 {

[committed] libstdc++: Remove dependency from std::bitset::to_ulong() test

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

There's no need to use a stringstream to test the to_ulong() member.
This will allow the test to be used in freestanding mode.

libstdc++-v3/ChangeLog:

* testsuite/20_util/bitset/access/to_ulong.cc: Construct bitset
from binary literal instead of using stringstream.
---
 .../testsuite/20_util/bitset/access/to_ulong.cc | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/libstdc++-v3/testsuite/20_util/bitset/access/to_ulong.cc 
b/libstdc++-v3/testsuite/20_util/bitset/access/to_ulong.cc
index 8163701e342..edc021c209c 100644
--- a/libstdc++-v3/testsuite/20_util/bitset/access/to_ulong.cc
+++ b/libstdc++-v3/testsuite/20_util/bitset/access/to_ulong.cc
@@ -20,22 +20,11 @@
 // 23.3.5.2 bitset members
 
 #include 
-#include 
-#include 
 #include 
 
 void test03()
 {
-  std::bitset<5>  b;
-  std::stringstream   ss("101");
-  ss.exceptions(std::ios_base::eofbit);
-
-  try
-  {
-ss >> b;
-  }
-  catch (std::exception&) { }
-
+  std::bitset<5>  b(0b101);
   VERIFY( b.to_ulong() == 5 );
 }
 
-- 
2.37.3

[committed] libstdc++: Remove non-standard public members in std::bitset

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

This makes _M_copy_from_ptr, _M_copy_from_string and _M_copy_to_string
private, and declares operator<< and operator>> as friends.

Also remove the historical _M_copy_from_string and _M_copy_to_string
overloads. Those were used before DR 396 was implemented but are
not needed now. There are no tests or docs describing them, so I don't
think we intend to support them as extensions.

libstdc++-v3/ChangeLog:

* include/std/bitset (_M_copy_from_ptr, _M_copy_from_string)
(_M_copy_to_string): Change access to private.
(_M_copy_from_string(const basic_string&, size_t, size_t)):
Remove.
(_M_copy_to_string(const basic_string&)): Remove.
---
 libstdc++-v3/include/std/bitset | 69 -
 1 file changed, 33 insertions(+), 36 deletions(-)

diff --git a/libstdc++-v3/include/std/bitset b/libstdc++-v3/include/std/bitset
index 3fe8b18735c..757da020ffe 100644
--- a/libstdc++-v3/include/std/bitset
+++ b/libstdc++-v3/include/std/bitset
@@ -1321,42 +1321,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
return to_string,
 std::allocator >(__zero, __one);
   }
-
-  // Helper functions for string operations.
-  template
-   _GLIBCXX23_CONSTEXPR
-void
-_M_copy_from_ptr(const _CharT*, size_t, size_t, size_t,
-_CharT, _CharT);
-
-  template
-   _GLIBCXX23_CONSTEXPR
-   void
-   _M_copy_from_string(const std::basic_string<_CharT,
-   _Traits, _Alloc>& __s, size_t __pos, size_t __n,
-   _CharT __zero, _CharT __one)
-   { _M_copy_from_ptr<_CharT, _Traits>(__s.data(), __s.size(), __pos, __n,
-   __zero, __one); }
-
-  template
-   _GLIBCXX23_CONSTEXPR
-   void
-_M_copy_to_string(std::basic_string<_CharT, _Traits, _Alloc>&,
- _CharT, _CharT) const;
-
-  // NB: Backward compat.
-  template
-   _GLIBCXX23_CONSTEXPR
-   void
-   _M_copy_from_string(const std::basic_string<_CharT,
-   _Traits, _Alloc>& __s, size_t __pos, size_t __n)
-   { _M_copy_from_string(__s, __pos, __n, _CharT('0'), _CharT('1')); }
-
-  template
-   _GLIBCXX23_CONSTEXPR
-   void
-_M_copy_to_string(std::basic_string<_CharT, _Traits,_Alloc>& __s) const
-   { _M_copy_to_string(__s, _CharT('0'), _CharT('1')); }
 #endif // HOSTED
 
   /// Returns the number of bits which are set.
@@ -1463,6 +1427,39 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   size_t
   _Find_next(size_t __prev) const _GLIBCXX_NOEXCEPT
   { return this->_M_do_find_next(__prev, _Nb); }
+
+private:
+  // Helper functions for string operations.
+  template
+   _GLIBCXX23_CONSTEXPR
+void
+_M_copy_from_ptr(const _CharT*, size_t, size_t, size_t,
+_CharT, _CharT);
+
+#if _GLIBCXX_HOSTED
+  template
+   _GLIBCXX23_CONSTEXPR
+   void
+   _M_copy_from_string(const std::basic_string<_CharT,
+   _Traits, _Alloc>& __s, size_t __pos, size_t __n,
+   _CharT __zero, _CharT __one)
+   { _M_copy_from_ptr<_CharT, _Traits>(__s.data(), __s.size(), __pos, __n,
+   __zero, __one); }
+
+  template
+   _GLIBCXX23_CONSTEXPR
+   void
+_M_copy_to_string(std::basic_string<_CharT, _Traits, _Alloc>&,
+ _CharT, _CharT) const;
+
+  template
+   friend std::basic_istream<_CharT, _Traits>&
+   operator>>(std::basic_istream<_CharT, _Traits>&, bitset<_Nb2>&);
+
+  template 
+   friend std::basic_ostream<_CharT, _Traits>&
+   operator<<(std::basic_ostream<_CharT, _Traits>&, const bitset<_Nb2>&);
+#endif
 };
 
 #if _GLIBCXX_HOSTED
-- 
2.37.3

[committed] libstdc++: Optimize operator>> for std::bitset

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

We can improve performance by using a char buffer instead of
basic_string. The loop bound already means we can't overflow the buffer,
and we don't need to keep writing a null character after every character
written to the buffer.

We could just use basic_string::resize(N) to zero-init the whole string,
then overwrite those chars. But that zero-init of all N chars would be
wasted in the case where we are writing to a bitset with large N, but
only end up extracting one or two chars from the stream.

With this change we just use buffer of uninitialized chars.  For a
small-ish bitset (currently <= 256) we can improve performance further
by using alloca instead of the heap.

libstdc++-v3/ChangeLog:

* include/std/bitset (operator>>): Use a simple buffer instead
of std::basic_string.
---
 libstdc++-v3/include/std/bitset | 36 -
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/std/bitset b/libstdc++-v3/include/std/bitset
index 757da020ffe..1038cc65138 100644
--- a/libstdc++-v3/include/std/bitset
+++ b/libstdc++-v3/include/std/bitset
@@ -1563,8 +1563,22 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   typedef std::basic_istream<_CharT, _Traits>  __istream_type;
   typedef typename __istream_type::ios_base__ios_base;
 
-  std::basic_string<_CharT, _Traits> __tmp;
-  __tmp.reserve(_Nb);
+  struct _Buffer
+  {
+   _Buffer()
+   : _M_base(_Nb > 256 ? new _CharT[_Nb] : (_CharT*)__builtin_alloca(_Nb))
+   { }
+
+   ~_Buffer()
+   {
+ if _GLIBCXX17_CONSTEXPR (_Nb > 256)
+   delete[] _M_base;
+   }
+
+   _CharT* const _M_base;
+  };
+  _Buffer __buf;
+  _CharT* __ptr = __buf._M_base;
 
   // _GLIBCXX_RESOLVE_LIB_DEFECTS
   // 303. Bitset input operator underspecified
@@ -1591,9 +1605,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{
  const char_type __c2 = _Traits::to_char_type(__c1);
  if (_Traits::eq(__c2, __zero))
-   __tmp.push_back(__zero);
+   *__ptr++ = __zero;
  else if (_Traits::eq(__c2, __one))
-   __tmp.push_back(__one);
+   *__ptr++ = __one;
  else if (_Traits::
   eq_int_type(__is.rdbuf()->sputbackc(__c2),
   __eof))
@@ -1613,11 +1627,15 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{ __is._M_setstate(__ios_base::badbit); }
}
 
-  if (__tmp.empty() && _Nb)
-   __state |= __ios_base::failbit;
-  else if _GLIBCXX17_CONSTEXPR (_Nb)
-   __x._M_copy_from_string(__tmp, static_cast(0), _Nb,
-   __zero, __one);
+  if _GLIBCXX17_CONSTEXPR (_Nb)
+  {
+   if (size_t __len = __ptr - __buf._M_base)
+ __x.template _M_copy_from_ptr<_CharT, _Traits>(__buf._M_base, __len,
+0, __len,
+__zero, __one);
+   else
+ __state |= __ios_base::failbit;
+  }
   if (__state)
__is.setstate(__state);
   return __is;
-- 
2.37.3

Re: [PATCH] c++, c: Implement C++23 P1774R8 - Portable assumptions [PR106654]

[Jason Merrill via Gcc-patches]

On 9/22/22 05:55, Jakub Jelinek wrote:

Hi!

The following patch implements C++23 P1774R8 - Portable assumptions
paper, by introducing support for [[assume (cond)]]; attribute for C++.
In addition to that the patch adds [[gnu::assume (cond)]]; and
__attribute__((assume (cond))); support to both C and C++.
As described in C++23, the attribute argument is conditional-expression
rather than the usual assignment-expression for attribute arguments,
the condition is contextually converted to bool (for C truthvalue conversion
is done on it) and is never evaluated at runtime.
For C++ constant expression evaluation, I only check the simplest conditions
for undefined behavior, because otherwise I'd need to undo changes to
*ctx->global which happened during the evaluation (but I believe the spec
allows that and we can further improve later).
The patch uses a new internal function, .ASSUME, to hold the condition
in the FEs.  At gimplification time, if the condition is simple/without
side-effects, it is gimplified as if (cond) ; else __builtin_unreachable ();
and otherwise for now dropped on the floor.  The intent is to incrementally
outline the conditions into separate artificial functions and use
.ASSUME further to tell the ranger and perhaps other optimization passes
about the assumptions, as detailed in the PR.

When implementing it, I found that assume entry hasn't been added to
https://eel.is/c++draft/cpp.cond#6
Jonathan said he'll file a NB comment about it, this patch assumes it
has been added into the table as 202207L when the paper has been voted in.

With the attributes for both C/C++, I'd say we don't need to add
__builtin_assume with similar purpose, especially when __builtin_assume
in LLVM is just weird.  It is strange for side-effects in function call's
argument not to be evaluated, and LLVM in that case (annoyingly) warns
and ignores the side-effects (but doesn't do then anything with it),
if there are no side-effects, it will work like our
if (!cond) __builtin_unreachable ();

During bootstrap/regtest, I've discovered a problem with the way we
handle scoped attributes.  For declaration or type attributes for attributes
we don't know anything about we just don't add them to the declarations or
types, so later in the FEs and middle-end it is fine to use lookup_attribute
etc. which just check the attribute name and not namespace because
non-standard non-GNU attributes just won't show there.  But in the case of
attributes on statements, nothing has filtered out the unknown attributes,
so with my earlier patch e.g. c-c++-common/Wno-attributes-6.c test failed
because it uses:
[[vendor::assume(1 + 1 == 2)]];
with -Wno-attributes=vendor::assume and lookup_attribute ("assume", )
finds such attribute and handled it that way.
So, for those cases, this patch introduces lookup_attribute and
remove_attribute overloads which specify also the namespace.
I think the fallthrough, hot, cold, likely, unlikely attribute handling
will need to use the new APIs too, so that we don't handle
msft::fallthrough attribute as something we'd know.


Sounds good.


Earlier version (without the attribs.{h,cc} changes and the 3 argument
lookup_attribute/remove_attribute uses instead of 2) has been successfully
bootstrapped/regtested on x86_64-linux and i686-linux with the
FAIL: c-c++-common/Wno-attributes-6.c  -Wc++-compat  (test for excess errors)
regression, ok for trunk if this passes full bootstrap/regtest again
(note, I've of course checked it already with
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-gcc check-g++ \
   RUNTESTFLAGS="dg.exp='feat* attr-assume* Wno-attrib*'"
)?

2022-09-22  Jakub Jelinek  

PR c++/106654
gcc/
* internal-fn.def (ASSUME): New internal function.
* internal-fn.h (expand_ASSUME): Declare.
* internal-fn.cc (expand_ASSUME): Define.
* gimplify.cc (gimplify_call_expr): Gimplify IFN_ASSUME.
* fold-const.h (simple_operand_p_2): Declare.


This needs a better name if it's going to be a public interface.

The usage also needs rationale for why this is the right predicate for 
assume, rather than just no-side-effects.  Surely the latter is right 
for constexpr, at least?



* fold-const.cc (simple_operand_p_2): Remove forward declaration.
No longer static.  Adjust function comment and fix a typo in it.
(simple_operand_p): Adjust function comment.
* attribs.h (remove_attribute): Declare overload with additional
attr_ns argument.
(private_lookup_attribute): Declare overload with additional
attr_ns and attr_ns_len arguments.
(lookup_attribute): New overload with additional attr_ns argument.
* attribs.cc (remove_attribute): New overload with additional
attr_ns argument.
(private_lookup_attribute): New overload with additional
attr_ns and attr_ns_len arguments.
* doc/extend.texi: Document assume attribute.  Move fallthrough
attribute example to its 

Re: [PATCH RFC] c++: streamline process for adding new builtin trait

[Jason Merrill via Gcc-patches]

On 9/30/22 11:14, Patrick Palka wrote:

On Thu, 29 Sep 2022, Jason Merrill wrote:


On 9/29/22 11:05, Patrick Palka wrote:

Adding a new builtin trait currently involves some boilerplate (as can
be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
CPTK_ enumerators and adding them to various switch statements across
many files.  The exact switch statements we need to change is determined
by whether the proposed trait yields a type or an expression.

This RFC patch attempts to streamline this process via a centralized
cp-trait.def file for declaring the important parts about a builtin trait
(whether it yields a type or an expression, its code, its spelling and
its arity) and using this file to automate away the switch statement
addition boilerplate.  It also converts 9 traits to use this approach
by way of example (we can convert all the traits once the design is
settled).

After this change, the process of adding a new builtin trait is just
(modulo tests): declare it in cp-trait.def, define its behavior in
finish_trait_type/expr, and handle it in diagnose_trait_expr if it's
an expression-yielding trait (this last step is unfortunate but since
the switch has no default case, we'll at least get a diagnostic if we
forget to do it).

Does this look like a good approach?


OK.


Thanks a lot, I committed the following (which migrates all the
C++-specific traits to the new approach):

-- >8 --

Subject: [PATCH] c++: streamline built-in trait addition process

Adding a new built-in trait currently involves manual boilerplate
consisting of defining an rid enumerator for the identifier as well as a
corresponding cp_trait_kind enumerator and handling them in various switch
statements, the exact set of which depends on whether the proposed trait
yields (and thus is recognized as) a type or an expression.

To streamline the process, this patch adds a central cp-trait.def file
that tabulates the essential details about each built-in trait (whether
it yields a type or an expression, its code, its spelling and its arity)
and uses this file to automate away the manual boilerplate.  It also
migrates all the existing C++-specific built-in traits to use this
approach.

After this change, adding a new built-in trait just entails declaring
it in cp-trait.def and defining its behavior in finish_trait_expr/type
(and handling it in diagnose_trait_expr, if it's an expression-yielding
trait).

gcc/c-family/ChangeLog:

* c-common.cc (c_common_reswords): Use cp/cp-trait.def to handle
C++ traits.
* c-common.h (enum rid): Likewise.

gcc/cp/ChangeLog:

* constraint.cc (diagnose_trait_expr): Likewise.
* cp-objcp-common.cc (names_builtin_p): Likewise.
* cp-tree.h (enum cp_trait_kind): Likewise.
* cxx-pretty-print.cc (pp_cxx_trait): Likewise.
* parser.cc (cp_keyword_starts_decl_specifier_p): Likewise.
(cp_parser_primary_expression): Likewise.
(cp_parser_trait): Likewise.
(cp_parser_simple_type_specifier): Likewise.
* cp-trait.def: New file.
---
  gcc/c-family/c-common.cc   |  54 ++---
  gcc/c-family/c-common.h|  33 ++
  gcc/cp/constraint.cc   |  12 +-
  gcc/cp/cp-objcp-common.cc  |  44 +---
  gcc/cp/cp-trait.def| 106 ++
  gcc/cp/cp-tree.h   |  46 +---
  gcc/cp/cxx-pretty-print.cc | 126 +
  gcc/cp/parser.cc   | 217 -
  8 files changed, 161 insertions(+), 477 deletions(-)
  create mode 100644 gcc/cp/cp-trait.def

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 6e0af863a49..3c60a89bfe2 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -378,7 +378,6 @@ const struct c_common_resword c_common_reswords[] =
{ "__attribute",  RID_ATTRIBUTE,  0 },
{ "__attribute__",RID_ATTRIBUTE,  0 },
{ "__auto_type",  RID_AUTO_TYPE,  D_CONLY },
-  { "__bases",  RID_BASES, D_CXXONLY },
{ "__builtin_addressof", RID_ADDRESSOF, D_CXXONLY },
{ "__builtin_bit_cast", RID_BUILTIN_BIT_CAST, D_CXXONLY },
{ "__builtin_call_with_static_chain",
@@ -401,44 +400,12 @@ const struct c_common_resword c_common_reswords[] =
{ "__const__",RID_CONST,  0 },
{ "__constinit",  RID_CONSTINIT,  D_CXXONLY },
{ "__decltype",   RID_DECLTYPE,   D_CXXONLY },
-  { "__direct_bases",   RID_DIRECT_BASES, D_CXXONLY },
{ "__extension__",RID_EXTENSION,  0 },
{ "__func__", RID_C99_FUNCTION_NAME, 0 },
-  { "__has_nothrow_assign", RID_HAS_NOTHROW_ASSIGN, D_CXXONLY },
-  { "__has_nothrow_constructor", RID_HAS_NOTHROW_CONSTRUCTOR, D_CXXONLY },
-  { "__has_nothrow_copy", RID_HAS_NOTHROW_COPY, D_CXXONLY },
-  { "__has_trivial_assign", RID_HAS_TRIVIAL_ASSIGN, D_CXXONLY },
-  { "__has_trivial_constructor", RID_HAS_TRIVIAL_CONSTRUCTOR, D_CXXONLY },
-  { "__has_trivial_copy", RID_HAS_TRIVIAL_COPY, D_CXXONLY },
-  { "__has_trivial_destructor", 

Re: [PATCH] c++: make some cp_trait_kind switch statements exhaustive

[Jason Merrill via Gcc-patches]

On 9/30/22 13:37, Patrick Palka wrote:


On Fri, 30 Sep 2022, Patrick Palka wrote:


This replaces the unreachable default case in some cp_trait_kind
switches with an exhaustive listing of the _unexpected_ trait codes,
so that when adding a new trait we'll get a -Wswitch diagnostic if we
forget to handle the trait code in one of these switches.

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

gcc/cp/ChangeLog:

* semantics.cc (trait_expr_value): Make cp_trait_kind switch
exhaustive.
(finish_trait_expr): Likewise.
(finish_trait_type): Likewise.
---
  gcc/cp/semantics.cc | 31 +--
  1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 66ee2186a84..91ad8aa340f 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12052,10 +12052,15 @@ trait_expr_value (cp_trait_kind kind, tree type1, 
tree type2)
  case CPTK_REF_CONVERTS_FROM_TEMPORARY:
return ref_xes_from_temporary (type1, type2, /*direct_init=*/false);
  
-default:

-  gcc_unreachable ();
-  return false;
+#define DEFTRAIT_TYPE(CODE, NAME, ARITY) \
+case CPTK_##CODE:
+#include "cp-trait.def"
+#undef DEFTRAIT_EXPR


Whoops, this should be #undef DEFTRAIT_TYPE


OK with that fix.


+  /* These are handled by finish_trait_type.  */
+  break;
  }
+
+  gcc_unreachable ();
  }
  
  /* Returns true if TYPE meets the requirements for the specified KIND,

@@ -12204,7 +12209,11 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, 
tree type1, tree type2)
return error_mark_node;
break;
  
-default:

+#define DEFTRAIT_TYPE(CODE, NAME, ARITY) \
+case CPTK_##CODE:
+#include "cp-trait.def"
+#undef DEFTRAIT_TYPE
+  /* These are handled by finish_trait_type.  */
gcc_unreachable ();
  }
  
@@ -12250,9 +12259,19 @@ finish_trait_type (cp_trait_kind kind, tree type1, tree type2)

if (TYPE_REF_P (type1))
type1 = TREE_TYPE (type1);
return cv_unqualified (type1);
-default:
-  gcc_unreachable ();
+
+#define DEFTRAIT_EXPR(CODE, NAME, ARITY) \
+case CPTK_##CODE:
+#include "cp-trait.def"
+#undef DEFTRAIT_EXPR
+  /* These are handled by finish_trait_expr.  */
+case CPTK_BASES:
+case CPTK_DIRECT_BASES:
+  /* These are handled by finish_bases.  */
+  break;
  }
+
+  gcc_unreachable ();
  }
  
  /* Do-nothing variants of functions to handle pragma FLOAT_CONST_DECIMAL64,

--
2.38.0.rc2

Re: [PATCH] arm, aarch64, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

[Jason Merrill via Gcc-patches]

On 9/30/22 13:13, Jakub Jelinek wrote:

On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote:

Note, there is one further problem on aarch64/arm, types with HFmode
(_Float16 and __fp16) are there mangled as Dh (which is standard
Itanium mangling:
   ::= Dh # IEEE 754r half-precision floating point (16 bits)
   ::= DF  _ # ISO/IEC TS 18661 binary floating point 
type _FloatN (N bits)
so in theory is also ok, but DF16_ is more specific.  Should we just
change Dh to DF16_ in those backends, or should __fp16 there be distinct
type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?


You argued for keeping __float128 separate from _Float128, does the same
argument not apply to this case?


Actually, they already were distinct types that just mangled the same.
So the same issue that had to be solved on i?86, ia64 and rs6000 for
_Float64x vs. long double is a problem on arm and aarch64 with _Float16
vs. __fp16.
The following patch fixes it.


And there is csky, which mangles __fp16 (but only if type's name is __fp16,
not _Float16) as __fp16, that looks clearly invalid to me as it isn't
valid in the mangling grammar.  So perhaps just nuke csky's mangle_type
and have it mangled as DF16_ by the generic code?


And seems even on csky __fp16 is distinct type from _Float16 (which is a
good thing for consistency, these 3 targets are the only ones that have
__fp16 type), so instead the patch handles it the same as on arm/aarch64,
Dh mangling for __fp16 and DF16_ for _Float16.

Tested with cross-compilers, ok for trunk?


OK.


2022-09-30  Jakub Jelinek  

PR c++/107080
* config/arm/arm.cc (arm_mangle_type): Mangle just __fp16 as Dh
and _Float16 as DF16_.
* config/aarch64/aarch64.cc (aarch64_mangle_type): Likewise.
* config/csky/csky.cc (csky_init_builtins): Fix a comment typo.
(csky_mangle_type): Mangle __fp16 as Dh and _Float16 as DF16_
rather than mangling __fp16 as __fp16.

* g++.target/arm/pr107080.C: New test.
* g++.target/aarch64/pr107080.C: New test.

--- gcc/config/arm/arm.cc.jj2022-09-29 18:11:28.746750048 +0200
+++ gcc/config/arm/arm.cc   2022-09-30 19:01:48.774286551 +0200
@@ -30359,6 +30359,8 @@ arm_mangle_type (const_tree type)
/* Half-precision floating point types.  */
if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
  {
+  if (TYPE_MAIN_VARIANT (type) == float16_type_node)
+   return NULL;
if (TYPE_MODE (type) == BFmode)
return "u6__bf16";
else
--- gcc/config/aarch64/aarch64.cc.jj2022-09-29 18:11:34.806667210 +0200
+++ gcc/config/aarch64/aarch64.cc   2022-09-30 19:02:02.079108171 +0200
@@ -20664,6 +20664,8 @@ aarch64_mangle_type (const_tree type)
/* Half-precision floating point types.  */
if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
  {
+  if (TYPE_MAIN_VARIANT (type) == float16_type_node)
+   return NULL;
if (TYPE_MODE (type) == BFmode)
return "u6__bf16";
else
--- gcc/config/csky/csky.cc.jj  2022-09-08 13:01:19.239779562 +0200
+++ gcc/config/csky/csky.cc 2022-09-30 19:06:09.126794587 +0200
@@ -7300,7 +7300,7 @@ csky_init_cumulative_args (CUMULATIVE_AR
  void
  csky_init_builtins (void)
  {
-  /* Inint fp16.  */
+  /* Init fp16.  */
static tree csky_floatHF_type_node = make_node (REAL_TYPE);
TYPE_PRECISION (csky_floatHF_type_node) = GET_MODE_PRECISION (HFmode);
layout_type (csky_floatHF_type_node);
@@ -7313,10 +7313,10 @@ csky_init_builtins (void)
  static const char *
  csky_mangle_type (const_tree type)
  {
-  if (TYPE_NAME (type) && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
-  && DECL_NAME (TYPE_NAME (type))
-  && !strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type))), "__fp16"))
-return "__fp16";
+  if (TREE_CODE (type) == REAL_TYPE
+  && TYPE_PRECISION (type) == 16
+  && TYPE_MAIN_VARIANT (type) != float16_type_node)
+return "Dh";
  
/* Use the default mangling.  */

return NULL;
--- gcc/testsuite/g++.target/arm/pr107080.C.jj  2022-09-30 18:56:08.885797047 
+0200
+++ gcc/testsuite/g++.target/arm/pr107080.C 2022-09-30 18:58:07.812221153 
+0200
@@ -0,0 +1,16 @@
+// PR c++/107080
+// { dg-do compile }
+// { dg-options "-mfp16-format=ieee" }
+
+template 
+int
+foo (T x, T1 y)
+{
+  return 3;
+}
+
+int
+main ()
+{
+  return (foo (0.0f16, 0.0f16) + foo (0.0f16, (__fp16) 0.0)) != 6;
+}
--- gcc/testsuite/g++.target/aarch64/pr107080.C.jj  2022-09-30 
18:56:08.885797047 +0200
+++ gcc/testsuite/g++.target/aarch64/pr107080.C 2022-09-30 18:56:04.805851530 
+0200
@@ -0,0 +1,16 @@
+// PR c++/107080
+// { dg-do compile }
+// { dg-options "" }
+
+template 
+int
+foo (T x, T1 y)
+{
+  return 3;
+}
+
+int
+main ()
+{
+  return (foo (0.0f16, 0.0f16) + foo (0.0f16, (__fp16) 0.0)) != 6;
+}


Jakub

Re: [PATCH] x86: Check corrupted return address when unwinding stack

[Jeff Law via Gcc-patches]

On 9/21/22 14:42, H.J. Lu via Gcc-patches wrote:

If shadow stack is enabled, when unwinding stack, we count how many stack
frames we pop to reach the landing pad and adjust shadow stack by the same
amount.  When counting the stack frame, we compare the return address on
normal stack against the return address on shadow stack.  If they don't
match, return _URC_FATAL_PHASE2_ERROR for the corrupted return address on
normal stack.  Don't check the return address for

1. Non-catchable exception where exception_class == 0.  Process will be
terminated.
2. Zero return address which marks the outermost stack frame.
3. Signal stack frame since kernel puts a restore token on shadow stack.

* unwind-generic.h (_Unwind_Frames_Increment): Add the EXC
argument.
* unwind.inc (_Unwind_RaiseException_Phase2): Pass EXC to
_Unwind_Frames_Increment.
(_Unwind_ForcedUnwind_Phase2): Likewise.
* config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
Take the EXC argument.  Return _URC_FATAL_PHASE2_ERROR if the
return address on normal stack doesn't match the return address
on shadow stack.


The generic bits are fine.  While I'm aware of one other target that 
_might_ need adjustment, it's an out-of-tree target and thus clearly not 
your responsibility.



jeff

Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support

[Jonathan Wakely via Gcc-patches]

On Fri, 30 Sept 2022 at 19:38, Jakub Jelinek  wrote:
>
> On Fri, Sep 30, 2022 at 06:21:04PM +, Joseph Myers wrote:
> > On Fri, 30 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> >
> > > What isn't in the patch but I think we'll need to also change are some
> > > minimal set of __builtin_*bf16 builtins.  Seems for _Float16, GCC provides
> > > all the __builtin_*f16 (and for C/ObjC even with *f16 names), but there is
> > > no glibc support for any of that, so builtins that are expanded by the
> > > compiler are fine, but what should be fall back to libm won't work.
> > > Maybe at least for now it is acceptable to implement most  and
> > >  std::float16_t and std::bfloat16_t overloads with using
> > > __builtin_*f and explicitly narrow down, but I think at least nextafter
> > > (and apparently nexttoward as an alias for it for extended floating
> > > point types) needs to be specific for the particular floating point 
> > > format.
> >
> > C doesn't have nexttoward (the function whose second argument is always
> > long double, independent of the type of the first argument) for any of the
> > _FloatN or _FloatNx types; why does C++ have in (but with second argument
> > the same type as the first?) for those types?
>
> No idea.
> https://eel.is/c++draft/cmath.syn
> has (since that std::float*_t/std::bfloat16_t paper)
> constexpr floating-point-type nextafter(floating-point-type x, 
> floating-point-type y);
> constexpr float nextafterf(float x, float y);
> constexpr long double nextafterl(long double x, long double y);
>
> constexpr floating-point-type nexttoward(floating-point-type x, 
> floating-point-type y);
> constexpr float nexttowardf(float x, long double y);
> constexpr long double nexttowardl(long double x, long double y);
>
> That is certainly wrong for double, because it is a backwards incompatible
> change, where
> constexpr double nexttoward(double x, long double y);
> is gone and
> constexpr double nexttoward(double x, double y);
> is added.
> IMHO the nexttoward case just shouldn't be changed, so it should remain:
> constexpr float nexttoward(float x, long double y);
> constexpr double nexttoward(double x, long double y);
> constexpr long double nexttoward(long double x, long double y);
> constexpr float nexttowardf(float x, long double y);
> constexpr long double nexttowardl(long double x, long double y);

Right, this is a defect. The author of P1467 reported that as an
accidental change (which we all missed). It should be in the LWG
issues list by Monday, and (I hope) will be voted Tentatively Ready
immediately.

> Having
> constexpr floating-point-type nexttoward(floating-point-type x, long double 
> y);
> would be problematic, because long double might have unordered floating
> point rank to floating-point-type (say powerpc IBM extended long double
> vs. std::float128_t), or could have smaller floating point rank (say if
> it is IEEE double).
> But like nexttowardl or nexttoward(long double, long double) aren't very
> useful because they are the same thing as nextafterl or
> nextafter(long double, long double), introducing other nexttoward overloads
> doesn't seem useful.
>
> Jakub
>

Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support

[Jakub Jelinek via Gcc-patches]

On Fri, Sep 30, 2022 at 06:21:04PM +, Joseph Myers wrote:
> On Fri, 30 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> 
> > What isn't in the patch but I think we'll need to also change are some
> > minimal set of __builtin_*bf16 builtins.  Seems for _Float16, GCC provides
> > all the __builtin_*f16 (and for C/ObjC even with *f16 names), but there is
> > no glibc support for any of that, so builtins that are expanded by the
> > compiler are fine, but what should be fall back to libm won't work.
> > Maybe at least for now it is acceptable to implement most  and
> >  std::float16_t and std::bfloat16_t overloads with using
> > __builtin_*f and explicitly narrow down, but I think at least nextafter
> > (and apparently nexttoward as an alias for it for extended floating
> > point types) needs to be specific for the particular floating point format.
> 
> C doesn't have nexttoward (the function whose second argument is always 
> long double, independent of the type of the first argument) for any of the 
> _FloatN or _FloatNx types; why does C++ have in (but with second argument 
> the same type as the first?) for those types?

No idea.
https://eel.is/c++draft/cmath.syn
has (since that std::float*_t/std::bfloat16_t paper)
constexpr floating-point-type nextafter(floating-point-type x, 
floating-point-type y);
constexpr float nextafterf(float x, float y);
constexpr long double nextafterl(long double x, long double y);

constexpr floating-point-type nexttoward(floating-point-type x, 
floating-point-type y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);

That is certainly wrong for double, because it is a backwards incompatible
change, where
constexpr double nexttoward(double x, long double y);
is gone and
constexpr double nexttoward(double x, double y);
is added.
IMHO the nexttoward case just shouldn't be changed, so it should remain:
constexpr float nexttoward(float x, long double y);
constexpr double nexttoward(double x, long double y);
constexpr long double nexttoward(long double x, long double y);
constexpr float nexttowardf(float x, long double y);
constexpr long double nexttowardl(long double x, long double y);
Having
constexpr floating-point-type nexttoward(floating-point-type x, long double y);
would be problematic, because long double might have unordered floating
point rank to floating-point-type (say powerpc IBM extended long double
vs. std::float128_t), or could have smaller floating point rank (say if
it is IEEE double).
But like nexttowardl or nexttoward(long double, long double) aren't very
useful because they are the same thing as nextafterl or
nextafter(long double, long double), introducing other nexttoward overloads
doesn't seem useful.

Jakub

Re: [PATCH] testsuite: Windows paths use \ and not /

[Andreas Schwab]

On Sep 30 2022, Jonathan Wakely via Gcc-patches wrote:

> That fixes the error, but now the regex doesn't match so there are
> still excess errors. It needs to be:
>
> // { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):.*" }

In Tcl "." matches newlines, thus this will prune too much.

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

Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support

[Joseph Myers]

On Fri, 30 Sep 2022, Jakub Jelinek via Gcc-patches wrote:

> What isn't in the patch but I think we'll need to also change are some
> minimal set of __builtin_*bf16 builtins.  Seems for _Float16, GCC provides
> all the __builtin_*f16 (and for C/ObjC even with *f16 names), but there is
> no glibc support for any of that, so builtins that are expanded by the
> compiler are fine, but what should be fall back to libm won't work.
> Maybe at least for now it is acceptable to implement most  and
>  std::float16_t and std::bfloat16_t overloads with using
> __builtin_*f and explicitly narrow down, but I think at least nextafter
> (and apparently nexttoward as an alias for it for extended floating
> point types) needs to be specific for the particular floating point format.

C doesn't have nexttoward (the function whose second argument is always 
long double, independent of the type of the first argument) for any of the 
_FloatN or _FloatNx types; why does C++ have in (but with second argument 
the same type as the first?) for those types?

(C2x also doesn't have fmax or fmin for the _FloatN or _FloatNx types, but 
that's because the operations those are bound to are replaced in IEEE 
754-2019 by different max/min operations with different corresponding 
functions; glibc still provides the fmax and fmin operations for _FloatN 
and _FloatNx, as in TS 18661-3, as extensions.)

Providing a full set of _Float16 operations in glibc would be reasonable 
(modulo the issues with implications for the minimum GCC version for 
building glibc for a given architecture).  It's rather less clear that 
__bf16 operations would be appropriate.

There may also be double rounding considerations for implementing some 
functions (that are required to be correctly rounded) via operations on 
float; at least for fma (if the result of fmaf is half way between two 
representable values of the narrower type, but not exactly equal to the 
value of a*b+c).

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

Re: [PATCH 00/10] c-family,libstdc++: P1642 and related changes

[Jonathan Wakely via Gcc-patches]

On Fri, 30 Sept 2022 at 17:46, Arsen Arsenović via Libstdc++
 wrote:
>
> Hi,
>
> This patchset:
> - Implements the P1642 WG21 paper, with a fair few extensions,
> - Fixes libstdc++' build system on systems --without-headers,
> - Ports (a large chunk of) the libstdc++ testsuite to freestanding, and
> - Changes the semantics of `int main' in freestanding (!!).

Thanks for all this work, Arsen!

I'm testing these and will approve and commit all except [PATCH 5/10]
which is outside libstdc++ and needs review.


>
> Thanks,
>
> Arsen Arsenović (7):
>   libstdc++: Filter out unconditional  default include
>   libstdc++: Mark headers that must be hosted as such [PR103626]
>   c-family: Implement new `int main' semantics in freestanding
>   libstdc++: Rework how freestanding install works [PR106953]
>   libstdc++: Make some tests work on freestanding [PR103626]
>   libstdc++: Re-enable std::hash in freestanding [PR103626]
>   libstdc++: Disable hosted-only tests [PR103626]
>
> Jonathan Wakely (3):
>   libstdc++: Make _GLIBCXX_HOSTED respect -ffreestanding [PR103626]
>   libstdc++: Adjust precompiled headers for freestanding
>   libstdc++: Add effective-target 'hosted' for testsuite [PR103626]
>
>  gcc/c-family/c-common.cc  |   6 +
>  gcc/c-family/c-common.h   |  10 +
>  gcc/c/c-decl.cc   |   4 +-
>  gcc/c/c-objc-common.cc|   9 +-
>  gcc/cp/cp-tree.h  |  12 +-
>  gcc/doc/invoke.texi   |  20 +-
>  .../freestanding-main-implicitly-returns.C|   5 +
>  gcc/testsuite/g++.dg/no-builtin-main.C|   5 +
>  gcc/testsuite/gcc.dg/c11-noreturn-4.c |   2 +-
>  .../freestanding-main-implicitly-returns.c|   5 +
>  gcc/testsuite/gcc.dg/inline-10.c  |   2 +-
>  gcc/testsuite/gcc.dg/no-builtin-main.c|   5 +
>  gcc/testsuite/gcc.dg/noreturn-4.c |   2 +-

Re: [PATCH] testsuite: Windows paths use \ and not /

[Jonathan Wakely via Gcc-patches]

On Fri, 30 Sept 2022 at 19:07, Jonathan Wakely  wrote:
>
> On Fri, 30 Sept 2022 at 19:04, Jonathan Wakely  wrote:
> >
> > On Fri, 30 Sept 2022 at 18:55, Jakub Jelinek  wrote:
> > >
> > > On Fri, Sep 30, 2022 at 06:47:07PM +0100, Jonathan Wakely via Gcc-patches 
> > > wrote:
> > > > On Fri, 30 Sept 2022 at 17:26, Jonathan Wakely wrote:
> > > > >
> > > > > On Fri, 30 Sept 2022 at 17:04, Torbjörn SVENSSON
> > > > >  wrote:
> > > > > >
> > > > > > libstdc++-v3/testsuite:
> > > > > >
> > > > > > * 20_util/bind/ref_neg.cc: Prune Windows paths too.
> > > > >
> > > > > Please CC the libstdc++ for libstdc++ patches.
> > > > >
> > > > > OK for trunk, thanks.
> > > >
> > > > I'm seeing errors now on x86_64-linux:
> > > >
> > > > ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> > > > dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "
> > > >
> > > > ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> > > > dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "
> > >
> > > Bet it should be
> > > // { dg-prune-output "\[/\\](functional|bits\[/\\]invoke.h):" }
> > > or so.  Completely untested.
> >
> > That fixes the error, but now the regex doesn't match so there are
> > still excess errors. It needs to be:
> >
> > // { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):.*" }
> >
> > Without any regex special characters, there's an implicit .* before
> > and after the pattern. But when you use any regex special characters
> > in the pattern, it stops working. I can't remember why. I figured it
> > out once.
>
> It looks like just adding .* at the start is enough:
>
> // { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):" }
>
> But that's so ugly, I'm tempted to replace that prune with something 
> different.

I'll finish testing this and push it.
commit 8d10c215fcf8425b4c514e1d10a15a6086aa8442
Author: Jonathan Wakely 
Date:   Fri Sep 30 19:10:29 2022

libstdc++: Fix broken dg-prune-output

The new pattern in the dg-prune-output directive doesn't work. Instead
of a messy regex full of leaning toothpicks, just match on the
diagnostic text instead of the header paths.

libstdc++-v3/ChangeLog:

* testsuite/20_util/bind/ref_neg.cc: Fix dg-prune-output
directive.

diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
index 1e9f3e7fece..1d4b1b66c76 100644
--- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
@@ -50,7 +50,7 @@ void test02()
 
 // Ignore the reasons for deduction/substitution failure in the headers.
 // Arrange for the match to work on installed trees as well as build trees.
-// { dg-prune-output "[/\\](functional|bits/invoke.h):" }
+// { dg-prune-output "no type named 'type' in .*std::result_of" }
 
 int main()
 {

Re: [PATCH] testsuite: Windows paths use \ and not /

[Jonathan Wakely via Gcc-patches]

On Fri, 30 Sept 2022 at 19:04, Jonathan Wakely  wrote:
>
> On Fri, 30 Sept 2022 at 18:55, Jakub Jelinek  wrote:
> >
> > On Fri, Sep 30, 2022 at 06:47:07PM +0100, Jonathan Wakely via Gcc-patches 
> > wrote:
> > > On Fri, 30 Sept 2022 at 17:26, Jonathan Wakely wrote:
> > > >
> > > > On Fri, 30 Sept 2022 at 17:04, Torbjörn SVENSSON
> > > >  wrote:
> > > > >
> > > > > libstdc++-v3/testsuite:
> > > > >
> > > > > * 20_util/bind/ref_neg.cc: Prune Windows paths too.
> > > >
> > > > Please CC the libstdc++ for libstdc++ patches.
> > > >
> > > > OK for trunk, thanks.
> > >
> > > I'm seeing errors now on x86_64-linux:
> > >
> > > ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> > > dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "
> > >
> > > ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> > > dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "
> >
> > Bet it should be
> > // { dg-prune-output "\[/\\](functional|bits\[/\\]invoke.h):" }
> > or so.  Completely untested.
>
> That fixes the error, but now the regex doesn't match so there are
> still excess errors. It needs to be:
>
> // { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):.*" }
>
> Without any regex special characters, there's an implicit .* before
> and after the pattern. But when you use any regex special characters
> in the pattern, it stops working. I can't remember why. I figured it
> out once.

It looks like just adding .* at the start is enough:

// { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):" }

But that's so ugly, I'm tempted to replace that prune with something different.

Re: [PATCH] testsuite: Windows paths use \ and not /

[Jonathan Wakely via Gcc-patches]

On Fri, 30 Sept 2022 at 18:55, Jakub Jelinek  wrote:
>
> On Fri, Sep 30, 2022 at 06:47:07PM +0100, Jonathan Wakely via Gcc-patches 
> wrote:
> > On Fri, 30 Sept 2022 at 17:26, Jonathan Wakely wrote:
> > >
> > > On Fri, 30 Sept 2022 at 17:04, Torbjörn SVENSSON
> > >  wrote:
> > > >
> > > > libstdc++-v3/testsuite:
> > > >
> > > > * 20_util/bind/ref_neg.cc: Prune Windows paths too.
> > >
> > > Please CC the libstdc++ for libstdc++ patches.
> > >
> > > OK for trunk, thanks.
> >
> > I'm seeing errors now on x86_64-linux:
> >
> > ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> > dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "
> >
> > ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> > dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "
>
> Bet it should be
> // { dg-prune-output "\[/\\](functional|bits\[/\\]invoke.h):" }
> or so.  Completely untested.

That fixes the error, but now the regex doesn't match so there are
still excess errors. It needs to be:

// { dg-prune-output ".*\[/\\](functional|bits\[/\\]invoke.h):.*" }

Without any regex special characters, there's an implicit .* before
and after the pattern. But when you use any regex special characters
in the pattern, it stops working. I can't remember why. I figured it
out once.

Re: [PATCH] testsuite: Windows paths use \ and not /

[Jakub Jelinek via Gcc-patches]

On Fri, Sep 30, 2022 at 06:47:07PM +0100, Jonathan Wakely via Gcc-patches wrote:
> On Fri, 30 Sept 2022 at 17:26, Jonathan Wakely wrote:
> >
> > On Fri, 30 Sept 2022 at 17:04, Torbjörn SVENSSON
> >  wrote:
> > >
> > > libstdc++-v3/testsuite:
> > >
> > > * 20_util/bind/ref_neg.cc: Prune Windows paths too.
> >
> > Please CC the libstdc++ for libstdc++ patches.
> >
> > OK for trunk, thanks.
> 
> I'm seeing errors now on x86_64-linux:
> 
> ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "
> 
> ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
> dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "

Bet it should be
// { dg-prune-output "\[/\\](functional|bits\[/\\]invoke.h):" }
or so.  Completely untested.

> > > Co-Authored-By: Yvan ROUX  
> > > Signed-off-by: Torbjörn SVENSSON  
> > > ---
> > >  libstdc++-v3/testsuite/20_util/bind/ref_neg.cc | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
> > > b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
> > > index e779d2f20bd..1e9f3e7fece 100644
> > > --- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
> > > +++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
> > > @@ -50,7 +50,7 @@ void test02()
> > >
> > >  // Ignore the reasons for deduction/substitution failure in the headers.
> > >  // Arrange for the match to work on installed trees as well as build 
> > > trees.
> > > -// { dg-prune-output "/(functional|bits/invoke.h):" }
> > > +// { dg-prune-output "[/\\](functional|bits/invoke.h):" }
> > >
> > >  int main()
> > >  {
> > > --
> > > 2.25.1
> > >

Jakub

Re: [PATCH] arm, aarch64, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

[Jakub Jelinek via Gcc-patches]

On Fri, Sep 30, 2022 at 06:38:39PM +0100, Richard Sandiford wrote:
> OK for the aarch64 part, thanks.  But could you add some scan-assemblers
> to the test to check for the mangled names?  I assume they should be:

Ok, about to commit the aarch64 part, will await review of the rest
afterwards.
> 
> _Z3fooIDF16_DF16_EiT_T0_
> _Z3fooIDF16_DhEiT_T0_
> 
> (which is what clang produces).

Indeed, that is what we now get.  Added.

2022-09-30  Jakub Jelinek  

PR c++/107080
* config/arm/arm.cc (arm_mangle_type): Mangle just __fp16 as Dh
and _Float16 as DF16_.
* config/aarch64/aarch64.cc (aarch64_mangle_type): Likewise.
* config/csky/csky.cc (csky_init_builtins): Fix a comment typo.
(csky_mangle_type): Mangle __fp16 as Dh and _Float16 as DF16_
rather than mangling __fp16 as __fp16.

* g++.target/arm/pr107080.C: New test.
* g++.target/aarch64/pr107080.C: New test.

--- gcc/config/arm/arm.cc.jj2022-09-29 18:11:28.746750048 +0200
+++ gcc/config/arm/arm.cc   2022-09-30 19:01:48.774286551 +0200
@@ -30359,6 +30359,8 @@ arm_mangle_type (const_tree type)
   /* Half-precision floating point types.  */
   if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
 {
+  if (TYPE_MAIN_VARIANT (type) == float16_type_node)
+   return NULL;
   if (TYPE_MODE (type) == BFmode)
return "u6__bf16";
   else
--- gcc/config/aarch64/aarch64.cc.jj2022-09-29 18:11:34.806667210 +0200
+++ gcc/config/aarch64/aarch64.cc   2022-09-30 19:02:02.079108171 +0200
@@ -20664,6 +20664,8 @@ aarch64_mangle_type (const_tree type)
   /* Half-precision floating point types.  */
   if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
 {
+  if (TYPE_MAIN_VARIANT (type) == float16_type_node)
+   return NULL;
   if (TYPE_MODE (type) == BFmode)
return "u6__bf16";
   else
--- gcc/config/csky/csky.cc.jj  2022-09-08 13:01:19.239779562 +0200
+++ gcc/config/csky/csky.cc 2022-09-30 19:06:09.126794587 +0200
@@ -7300,7 +7300,7 @@ csky_init_cumulative_args (CUMULATIVE_AR
 void
 csky_init_builtins (void)
 {
-  /* Inint fp16.  */
+  /* Init fp16.  */
   static tree csky_floatHF_type_node = make_node (REAL_TYPE);
   TYPE_PRECISION (csky_floatHF_type_node) = GET_MODE_PRECISION (HFmode);
   layout_type (csky_floatHF_type_node);
@@ -7313,10 +7313,10 @@ csky_init_builtins (void)
 static const char *
 csky_mangle_type (const_tree type)
 {
-  if (TYPE_NAME (type) && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
-  && DECL_NAME (TYPE_NAME (type))
-  && !strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type))), "__fp16"))
-return "__fp16";
+  if (TREE_CODE (type) == REAL_TYPE
+  && TYPE_PRECISION (type) == 16
+  && TYPE_MAIN_VARIANT (type) != float16_type_node)
+return "Dh";
 
   /* Use the default mangling.  */
   return NULL;
--- gcc/testsuite/g++.target/arm/pr107080.C.jj  2022-09-30 18:56:08.885797047 
+0200
+++ gcc/testsuite/g++.target/arm/pr107080.C 2022-09-30 18:58:07.812221153 
+0200
@@ -0,0 +1,19 @@
+// PR c++/107080
+// { dg-do compile }
+// { dg-options "-mfp16-format=ieee" }
+
+template  
+int
+foo (T x, T1 y)
+{
+  return 3;
+}
+
+int
+main ()
+{
+  return (foo (0.0f16, 0.0f16) + foo (0.0f16, (__fp16) 0.0)) != 6;
+}
+
+// { dg-final { scan-assembler "_Z3fooIDF16_DF16_EiT_T0_" } }
+// { dg-final { scan-assembler "_Z3fooIDF16_DhEiT_T0_" } }
--- gcc/testsuite/g++.target/aarch64/pr107080.C.jj  2022-09-30 
18:56:08.885797047 +0200
+++ gcc/testsuite/g++.target/aarch64/pr107080.C 2022-09-30 19:45:08.657342253 
+0200
@@ -0,0 +1,19 @@
+// PR c++/107080
+// { dg-do compile }
+// { dg-options "" }
+
+template  
+int
+foo (T x, T1 y)
+{
+  return 3;
+}
+
+int
+main ()
+{
+  return (foo (0.0f16, 0.0f16) + foo (0.0f16, (__fp16) 0.0)) != 6;
+}
+
+// { dg-final { scan-assembler "_Z3fooIDF16_DF16_EiT_T0_" } }
+// { dg-final { scan-assembler "_Z3fooIDF16_DhEiT_T0_" } }

Jakub

Re: [PATCH] Adjust the symbol for SECTION_LINK_ORDER linked_to section [PR99889]

[Segher Boessenkool]

On Fri, Sep 30, 2022 at 08:47:53PM +0800, Kewen.Lin wrote:
> on 2022/9/30 04:31, Segher Boessenkool wrote:
> > Please don't define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY at all,
> > instead, and remove this whole function?
> 
> This hook is still needed for "ELFv2 support rework" which
> was just committed in r13-2984.  There is also a note
> explaining this in the original mail: 
> 
> "btw, rs6000_print_patchable_function_entry can be dropped
> but there is another rs6000 patch which needs this rs6000
> specific hook rs6000_print_patchable_function_entry, not
> sure which one gets landed first, so just leave it here."

Ah, so this would be just churn?  Okay then :-)

Thanks,


Segher

Re: [PATCH] testsuite: Windows paths use \ and not /

[Jonathan Wakely via Gcc-patches]

On Fri, 30 Sept 2022 at 17:26, Jonathan Wakely wrote:
>
> On Fri, 30 Sept 2022 at 17:04, Torbjörn SVENSSON
>  wrote:
> >
> > libstdc++-v3/testsuite:
> >
> > * 20_util/bind/ref_neg.cc: Prune Windows paths too.
>
> Please CC the libstdc++ for libstdc++ patches.
>
> OK for trunk, thanks.

I'm seeing errors now on x86_64-linux:

ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "

ERROR: 20_util/bind/ref_neg.cc: unknown dg option: /\\ for "
dg-prune-output 53 "[/\\](functional|bits/invoke.h):" "





>
>
> >
> > Co-Authored-By: Yvan ROUX  
> > Signed-off-by: Torbjörn SVENSSON  
> > ---
> >  libstdc++-v3/testsuite/20_util/bind/ref_neg.cc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
> > b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
> > index e779d2f20bd..1e9f3e7fece 100644
> > --- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
> > +++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
> > @@ -50,7 +50,7 @@ void test02()
> >
> >  // Ignore the reasons for deduction/substitution failure in the headers.
> >  // Arrange for the match to work on installed trees as well as build trees.
> > -// { dg-prune-output "/(functional|bits/invoke.h):" }
> > +// { dg-prune-output "[/\\](functional|bits/invoke.h):" }
> >
> >  int main()
> >  {
> > --
> > 2.25.1
> >

Re: [GCC13][Patch][V4][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_arrays

[Martin Sebor via Gcc-patches]

On 9/28/22 13:17, Qing Zhao wrote:

Hi, Martin,

Thanks for the comments. And sorry for my late reply till now (I just came back 
home from LPC, GNU Cauldron and then a one-week vacation after that…)


On Sep 12, 2022, at 12:42 PM, Martin Sebor  wrote:

On 9/6/22 18:28, Qing Zhao wrote:

Add the following new option -fstrict-flex-arrays[=n] and a corresponding
attribute strict_flex_arrays to GCC:
'-fstrict-flex-arrays'
  Treat the trailing array of a structure as a flexible array member
  in a stricter way.


A minor problem with this phrasing was pointed out in the review
of the Clang option: https://reviews.llvm.org/D126864#inline-1282716
It would be good to avoid it here.

Yes, I agree.


  (I think qualifying the sentence
by adding "for the purposes of accessing the elements of such arrays"
might be one way to do it).


How about:

'-fstrict-flex-arrays’
  Treat the trailing array of a structure as a variable-length array
   in a stricter way.
?


I don't think talking about variable length arrays in this context
would be appropriate (they're a different thing).  The concern in
the review above was that the a in something like

  struct { int n, a[1]; } s;

is treated as a flexible array member only for the purposes of
accessing a's elements, but not also in a sizeof expression, for
instance.  sizeof s.a is 1 regardless of the -fstrict-flex-arrays
argument, but if s.a were considered a flexible array member then
sizeof s.a would a constraint violation.  Similarly, if s.a were
treated as a FAM the definition of s would pedantically speaking
be invalid, and s's size would be equal to sizeof (int) because
GCC accepts the defintion but adds no padding.

One way to avoid implying that might be qualifying the description
with what I suggested above:

  Control when to treat the trailing array of a structure as
  a flexible array member for the purposes of accessing
  the elements of such an array.

But I'm sure there are better ways to put it.

In addition, it should probably also be made clear whether this
stays the same when an object of such a structure is itself
a subobject of another aggregate (array or struct).  E.g.,

  struct A { int n, a[1]; };
  struct A a[2];   // is a.a treated as a FAM?
  struct B { struct A a; } b;  // is b.a.a treated as a FAM?
  struct C { struct A a; int i; } c;   // how about c.a.a?

Finally, and with the caveat that I haven't been very close
attention to the GCC patches so this may not be an issue, but I have
the impression that the decision in Clang is to let -Warray-bounds
trigger (at least somewhat) independently of -fstrict-flex-arrays.
The goal is to make it possible to diagnose misuses without causing
runtime errors.  This has also been the historical GCC behavior that
I think it should be maintained going forward.

Martin






The positive form is equivalent to
  '-fstrict-flex-arrays=3', which is the strictest.  A trailing array
  is treated as a flexible array member only when it is declared as a
  flexible array member per C99 standard onwards.  The negative form
  is equivalent to '-fstrict-flex-arrays=0', which is the least
  strict.  All trailing arrays of structures are treated as flexible
  array members.
'-fstrict-flex-arrays=LEVEL'
  Treat the trailing array of a structure as a flexible array member
  in a stricter way.  The value of LEVEL controls the level of
  strictness.
  The possible values of LEVEL are the same as for the
  'strict_flex_arrays' attribute (*note Variable Attributes::).
  You can control this behavior for a specific trailing array field
  of a structure by using the variable attribute 'strict_flex_arrays'
  attribute (*note Variable Attributes::).
'strict_flex_arrays (LEVEL)'
  The 'strict_flex_arrays' attribute should be attached to the
  trailing array field of a structure.  It specifies the level of
  strictness of treating the trailing array field of a structure as a
  flexible array member.  LEVEL must be an integer betwen 0 to 3.



Since the attribute applies to just a single array declaration it
seems that its name should be strict_flex_array (i.e., singular,
without the trailing 's').


Will make the change as you suggested.

Thanks.

Qing


Martin


  LEVEL=0 is the least strict level, all trailing arrays of
  structures are treated as flexible array members.  LEVEL=3 is the
  strictest level, only when the trailing array is declared as a
  flexible array member per C99 standard onwards ('[]'), it is
  treated as a flexible array member.
  There are two more levels in between 0 and 3, which are provided to
  support older codes that use GCC zero-length array extension
  ('[0]') or one-size array as flexible array member ('[1]'): When
  LEVEL is 1, the trailing array is treated as a flexible array
  member when it is declared as either '[]', '[0]', or '[1]'; When
  

Re: [PATCH] arm, aarch64, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

[Richard Sandiford via Gcc-patches]

Jakub Jelinek  writes:
> On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote:
>> > Note, there is one further problem on aarch64/arm, types with HFmode
>> > (_Float16 and __fp16) are there mangled as Dh (which is standard
>> > Itanium mangling:
>> >   ::= Dh # IEEE 754r half-precision floating point (16 
>> > bits)
>> >   ::= DF  _ # ISO/IEC TS 18661 binary floating 
>> > point type _FloatN (N bits)
>> > so in theory is also ok, but DF16_ is more specific.  Should we just
>> > change Dh to DF16_ in those backends, or should __fp16 there be distinct
>> > type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
>> 
>> You argued for keeping __float128 separate from _Float128, does the same
>> argument not apply to this case?
>
> Actually, they already were distinct types that just mangled the same.
> So the same issue that had to be solved on i?86, ia64 and rs6000 for
> _Float64x vs. long double is a problem on arm and aarch64 with _Float16
> vs. __fp16.
> The following patch fixes it.
>
>> > And there is csky, which mangles __fp16 (but only if type's name is __fp16,
>> > not _Float16) as __fp16, that looks clearly invalid to me as it isn't
>> > valid in the mangling grammar.  So perhaps just nuke csky's mangle_type
>> > and have it mangled as DF16_ by the generic code?
>
> And seems even on csky __fp16 is distinct type from _Float16 (which is a
> good thing for consistency, these 3 targets are the only ones that have
> __fp16 type), so instead the patch handles it the same as on arm/aarch64,
> Dh mangling for __fp16 and DF16_ for _Float16.
>
> Tested with cross-compilers, ok for trunk?
>
> 2022-09-30  Jakub Jelinek  
>
>   PR c++/107080
>   * config/arm/arm.cc (arm_mangle_type): Mangle just __fp16 as Dh
>   and _Float16 as DF16_.
>   * config/aarch64/aarch64.cc (aarch64_mangle_type): Likewise.
>   * config/csky/csky.cc (csky_init_builtins): Fix a comment typo.
>   (csky_mangle_type): Mangle __fp16 as Dh and _Float16 as DF16_
>   rather than mangling __fp16 as __fp16.
>
>   * g++.target/arm/pr107080.C: New test.
>   * g++.target/aarch64/pr107080.C: New test.

OK for the aarch64 part, thanks.  But could you add some scan-assemblers
to the test to check for the mangled names?  I assume they should be:

_Z3fooIDF16_DF16_EiT_T0_
_Z3fooIDF16_DhEiT_T0_

(which is what clang produces).

Richard

> --- gcc/config/arm/arm.cc.jj  2022-09-29 18:11:28.746750048 +0200
> +++ gcc/config/arm/arm.cc 2022-09-30 19:01:48.774286551 +0200
> @@ -30359,6 +30359,8 @@ arm_mangle_type (const_tree type)
>/* Half-precision floating point types.  */
>if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
>  {
> +  if (TYPE_MAIN_VARIANT (type) == float16_type_node)
> + return NULL;
>if (TYPE_MODE (type) == BFmode)
>   return "u6__bf16";
>else
> --- gcc/config/aarch64/aarch64.cc.jj  2022-09-29 18:11:34.806667210 +0200
> +++ gcc/config/aarch64/aarch64.cc 2022-09-30 19:02:02.079108171 +0200
> @@ -20664,6 +20664,8 @@ aarch64_mangle_type (const_tree type)
>/* Half-precision floating point types.  */
>if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
>  {
> +  if (TYPE_MAIN_VARIANT (type) == float16_type_node)
> + return NULL;
>if (TYPE_MODE (type) == BFmode)
>   return "u6__bf16";
>else
> --- gcc/config/csky/csky.cc.jj2022-09-08 13:01:19.239779562 +0200
> +++ gcc/config/csky/csky.cc   2022-09-30 19:06:09.126794587 +0200
> @@ -7300,7 +7300,7 @@ csky_init_cumulative_args (CUMULATIVE_AR
>  void
>  csky_init_builtins (void)
>  {
> -  /* Inint fp16.  */
> +  /* Init fp16.  */
>static tree csky_floatHF_type_node = make_node (REAL_TYPE);
>TYPE_PRECISION (csky_floatHF_type_node) = GET_MODE_PRECISION (HFmode);
>layout_type (csky_floatHF_type_node);
> @@ -7313,10 +7313,10 @@ csky_init_builtins (void)
>  static const char *
>  csky_mangle_type (const_tree type)
>  {
> -  if (TYPE_NAME (type) && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
> -  && DECL_NAME (TYPE_NAME (type))
> -  && !strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type))), 
> "__fp16"))
> -return "__fp16";
> +  if (TREE_CODE (type) == REAL_TYPE
> +  && TYPE_PRECISION (type) == 16
> +  && TYPE_MAIN_VARIANT (type) != float16_type_node)
> +return "Dh";
>  
>/* Use the default mangling.  */
>return NULL;
> --- gcc/testsuite/g++.target/arm/pr107080.C.jj2022-09-30 
> 18:56:08.885797047 +0200
> +++ gcc/testsuite/g++.target/arm/pr107080.C   2022-09-30 18:58:07.812221153 
> +0200
> @@ -0,0 +1,16 @@
> +// PR c++/107080
> +// { dg-do compile }
> +// { dg-options "-mfp16-format=ieee" }
> +
> +template  
> +int
> +foo (T x, T1 y)
> +{
> +  return 3;
> +}
> +
> +int
> +main ()
> +{
> +  return (foo (0.0f16, 0.0f16) + foo (0.0f16, (__fp16) 0.0)) != 6;
> +}
> --- gcc/testsuite/g++.target/aarch64/pr107080.C.jj2022-09-30 
> 

Re: [PATCH] c++: make some cp_trait_kind switch statements exhaustive

[Patrick Palka via Gcc-patches]

On Fri, 30 Sep 2022, Patrick Palka wrote:

> This replaces the unreachable default case in some cp_trait_kind
> switches with an exhaustive listing of the _unexpected_ trait codes,
> so that when adding a new trait we'll get a -Wswitch diagnostic if we
> forget to handle the trait code in one of these switches.
> 
> Bootstrappend and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk?
> 
> gcc/cp/ChangeLog:
> 
>   * semantics.cc (trait_expr_value): Make cp_trait_kind switch
>   exhaustive.
>   (finish_trait_expr): Likewise.
>   (finish_trait_type): Likewise.
> ---
>  gcc/cp/semantics.cc | 31 +--
>  1 file changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> index 66ee2186a84..91ad8aa340f 100644
> --- a/gcc/cp/semantics.cc
> +++ b/gcc/cp/semantics.cc
> @@ -12052,10 +12052,15 @@ trait_expr_value (cp_trait_kind kind, tree type1, 
> tree type2)
>  case CPTK_REF_CONVERTS_FROM_TEMPORARY:
>return ref_xes_from_temporary (type1, type2, /*direct_init=*/false);
>  
> -default:
> -  gcc_unreachable ();
> -  return false;
> +#define DEFTRAIT_TYPE(CODE, NAME, ARITY) \
> +case CPTK_##CODE:
> +#include "cp-trait.def"
> +#undef DEFTRAIT_EXPR

Whoops, this should be #undef DEFTRAIT_TYPE

> +  /* These are handled by finish_trait_type.  */
> +  break;
>  }
> +
> +  gcc_unreachable ();
>  }
>  
>  /* Returns true if TYPE meets the requirements for the specified KIND,
> @@ -12204,7 +12209,11 @@ finish_trait_expr (location_t loc, cp_trait_kind 
> kind, tree type1, tree type2)
>   return error_mark_node;
>break;
>  
> -default:
> +#define DEFTRAIT_TYPE(CODE, NAME, ARITY) \
> +case CPTK_##CODE:
> +#include "cp-trait.def"
> +#undef DEFTRAIT_TYPE
> +  /* These are handled by finish_trait_type.  */
>gcc_unreachable ();
>  }
>  
> @@ -12250,9 +12259,19 @@ finish_trait_type (cp_trait_kind kind, tree type1, 
> tree type2)
>if (TYPE_REF_P (type1))
>   type1 = TREE_TYPE (type1);
>return cv_unqualified (type1);
> -default:
> -  gcc_unreachable ();
> +
> +#define DEFTRAIT_EXPR(CODE, NAME, ARITY) \
> +case CPTK_##CODE:
> +#include "cp-trait.def"
> +#undef DEFTRAIT_EXPR
> +  /* These are handled by finish_trait_expr.  */
> +case CPTK_BASES:
> +case CPTK_DIRECT_BASES:
> +  /* These are handled by finish_bases.  */
> +  break;
>  }
> +
> +  gcc_unreachable ();
>  }
>  
>  /* Do-nothing variants of functions to handle pragma FLOAT_CONST_DECIMAL64,
> -- 
> 2.38.0.rc2
> 
> 

[PATCH] c++: make some cp_trait_kind switch statements exhaustive

[Patrick Palka via Gcc-patches]

This replaces the unreachable default case in some cp_trait_kind
switches with an exhaustive listing of the _unexpected_ trait codes,
so that when adding a new trait we'll get a -Wswitch diagnostic if we
forget to handle the trait code in one of these switches.

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

gcc/cp/ChangeLog:

* semantics.cc (trait_expr_value): Make cp_trait_kind switch
exhaustive.
(finish_trait_expr): Likewise.
(finish_trait_type): Likewise.
---
 gcc/cp/semantics.cc | 31 +--
 1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 66ee2186a84..91ad8aa340f 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12052,10 +12052,15 @@ trait_expr_value (cp_trait_kind kind, tree type1, 
tree type2)
 case CPTK_REF_CONVERTS_FROM_TEMPORARY:
   return ref_xes_from_temporary (type1, type2, /*direct_init=*/false);
 
-default:
-  gcc_unreachable ();
-  return false;
+#define DEFTRAIT_TYPE(CODE, NAME, ARITY) \
+case CPTK_##CODE:
+#include "cp-trait.def"
+#undef DEFTRAIT_EXPR
+  /* These are handled by finish_trait_type.  */
+  break;
 }
+
+  gcc_unreachable ();
 }
 
 /* Returns true if TYPE meets the requirements for the specified KIND,
@@ -12204,7 +12209,11 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, 
tree type1, tree type2)
return error_mark_node;
   break;
 
-default:
+#define DEFTRAIT_TYPE(CODE, NAME, ARITY) \
+case CPTK_##CODE:
+#include "cp-trait.def"
+#undef DEFTRAIT_TYPE
+  /* These are handled by finish_trait_type.  */
   gcc_unreachable ();
 }
 
@@ -12250,9 +12259,19 @@ finish_trait_type (cp_trait_kind kind, tree type1, 
tree type2)
   if (TYPE_REF_P (type1))
type1 = TREE_TYPE (type1);
   return cv_unqualified (type1);
-default:
-  gcc_unreachable ();
+
+#define DEFTRAIT_EXPR(CODE, NAME, ARITY) \
+case CPTK_##CODE:
+#include "cp-trait.def"
+#undef DEFTRAIT_EXPR
+  /* These are handled by finish_trait_expr.  */
+case CPTK_BASES:
+case CPTK_DIRECT_BASES:
+  /* These are handled by finish_bases.  */
+  break;
 }
+
+  gcc_unreachable ();
 }
 
 /* Do-nothing variants of functions to handle pragma FLOAT_CONST_DECIMAL64,
-- 
2.38.0.rc2

[PATCH] arm, aarch64, csky: Fix C++ ICEs with _Float16 and __fp16 [PR107080]

[Jakub Jelinek via Gcc-patches]

On Fri, Sep 30, 2022 at 09:54:49AM -0400, Jason Merrill wrote:
> > Note, there is one further problem on aarch64/arm, types with HFmode
> > (_Float16 and __fp16) are there mangled as Dh (which is standard
> > Itanium mangling:
> >   ::= Dh # IEEE 754r half-precision floating point (16 bits)
> >   ::= DF  _ # ISO/IEC TS 18661 binary floating 
> > point type _FloatN (N bits)
> > so in theory is also ok, but DF16_ is more specific.  Should we just
> > change Dh to DF16_ in those backends, or should __fp16 there be distinct
> > type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?
> 
> You argued for keeping __float128 separate from _Float128, does the same
> argument not apply to this case?

Actually, they already were distinct types that just mangled the same.
So the same issue that had to be solved on i?86, ia64 and rs6000 for
_Float64x vs. long double is a problem on arm and aarch64 with _Float16
vs. __fp16.
The following patch fixes it.

> > And there is csky, which mangles __fp16 (but only if type's name is __fp16,
> > not _Float16) as __fp16, that looks clearly invalid to me as it isn't
> > valid in the mangling grammar.  So perhaps just nuke csky's mangle_type
> > and have it mangled as DF16_ by the generic code?

And seems even on csky __fp16 is distinct type from _Float16 (which is a
good thing for consistency, these 3 targets are the only ones that have
__fp16 type), so instead the patch handles it the same as on arm/aarch64,
Dh mangling for __fp16 and DF16_ for _Float16.

Tested with cross-compilers, ok for trunk?

2022-09-30  Jakub Jelinek  

PR c++/107080
* config/arm/arm.cc (arm_mangle_type): Mangle just __fp16 as Dh
and _Float16 as DF16_.
* config/aarch64/aarch64.cc (aarch64_mangle_type): Likewise.
* config/csky/csky.cc (csky_init_builtins): Fix a comment typo.
(csky_mangle_type): Mangle __fp16 as Dh and _Float16 as DF16_
rather than mangling __fp16 as __fp16.

* g++.target/arm/pr107080.C: New test.
* g++.target/aarch64/pr107080.C: New test.

--- gcc/config/arm/arm.cc.jj2022-09-29 18:11:28.746750048 +0200
+++ gcc/config/arm/arm.cc   2022-09-30 19:01:48.774286551 +0200
@@ -30359,6 +30359,8 @@ arm_mangle_type (const_tree type)
   /* Half-precision floating point types.  */
   if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
 {
+  if (TYPE_MAIN_VARIANT (type) == float16_type_node)
+   return NULL;
   if (TYPE_MODE (type) == BFmode)
return "u6__bf16";
   else
--- gcc/config/aarch64/aarch64.cc.jj2022-09-29 18:11:34.806667210 +0200
+++ gcc/config/aarch64/aarch64.cc   2022-09-30 19:02:02.079108171 +0200
@@ -20664,6 +20664,8 @@ aarch64_mangle_type (const_tree type)
   /* Half-precision floating point types.  */
   if (TREE_CODE (type) == REAL_TYPE && TYPE_PRECISION (type) == 16)
 {
+  if (TYPE_MAIN_VARIANT (type) == float16_type_node)
+   return NULL;
   if (TYPE_MODE (type) == BFmode)
return "u6__bf16";
   else
--- gcc/config/csky/csky.cc.jj  2022-09-08 13:01:19.239779562 +0200
+++ gcc/config/csky/csky.cc 2022-09-30 19:06:09.126794587 +0200
@@ -7300,7 +7300,7 @@ csky_init_cumulative_args (CUMULATIVE_AR
 void
 csky_init_builtins (void)
 {
-  /* Inint fp16.  */
+  /* Init fp16.  */
   static tree csky_floatHF_type_node = make_node (REAL_TYPE);
   TYPE_PRECISION (csky_floatHF_type_node) = GET_MODE_PRECISION (HFmode);
   layout_type (csky_floatHF_type_node);
@@ -7313,10 +7313,10 @@ csky_init_builtins (void)
 static const char *
 csky_mangle_type (const_tree type)
 {
-  if (TYPE_NAME (type) && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
-  && DECL_NAME (TYPE_NAME (type))
-  && !strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type))), "__fp16"))
-return "__fp16";
+  if (TREE_CODE (type) == REAL_TYPE
+  && TYPE_PRECISION (type) == 16
+  && TYPE_MAIN_VARIANT (type) != float16_type_node)
+return "Dh";
 
   /* Use the default mangling.  */
   return NULL;
--- gcc/testsuite/g++.target/arm/pr107080.C.jj  2022-09-30 18:56:08.885797047 
+0200
+++ gcc/testsuite/g++.target/arm/pr107080.C 2022-09-30 18:58:07.812221153 
+0200
@@ -0,0 +1,16 @@
+// PR c++/107080
+// { dg-do compile }
+// { dg-options "-mfp16-format=ieee" }
+
+template  
+int
+foo (T x, T1 y)
+{
+  return 3;
+}
+
+int
+main ()
+{
+  return (foo (0.0f16, 0.0f16) + foo (0.0f16, (__fp16) 0.0)) != 6;
+}
--- gcc/testsuite/g++.target/aarch64/pr107080.C.jj  2022-09-30 
18:56:08.885797047 +0200
+++ gcc/testsuite/g++.target/aarch64/pr107080.C 2022-09-30 18:56:04.805851530 
+0200
@@ -0,0 +1,16 @@
+// PR c++/107080
+// { dg-do compile }
+// { dg-options "" }
+
+template  
+int
+foo (T x, T1 y)
+{
+  return 3;
+}
+
+int
+main ()
+{
+  return (foo (0.0f16, 0.0f16) + foo (0.0f16, (__fp16) 0.0)) != 6;
+}


Jakub

[PATCH 07/10] libstdc++: Make some tests work on freestanding [PR103626]

[Arsen Arsenović via Gcc-patches]

PR libstdc++/103626 - _GLIBCXX_HOSTED should respect -ffreestanding

Co-authored-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:
PR libstdc++/103626
* testsuite/17_intro/headers/c++1998/stdc++.cc [!__STDC_HOSTED__]:
Do not include C headers that aren't valid for freestanding.
* testsuite/17_intro/tag_type_explicit_ctor.cc [!__STDC_HOSTED__]:
Do not test tag types that aren't defined for freestanding.
* testsuite/18_support/headers/cstdlib/functions_std.cc: Do not
check for std::getenv and std::system for freestanding.
* testsuite/17_intro/using_namespace_std_exp_neg.cc [!__STDC_HOSTED__]:
Do not test hosted parts of the standard library.
* testsuite/17_intro/using_namespace_std_tr1_neg.cc [!__STDC_HOSTED__]:
Likewise.
* testsuite/20_util/allocator_traits/members/rebind_alloc.cc 
[!__STDC_HOSTED__]:
Likewise.
* 
testsuite/20_util/allocator_traits/requirements/explicit_instantiation.cc 
[!HOSTED]:
Likewise.
* testsuite/20_util/headers/bitset/synopsis.cc [!__STDC_HOSTED__]: 
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc 
[!__STDC_HOSTED__]:
Likewise.
* testsuite/20_util/pointer_traits/requirements/typedefs.cc 
[!__STDC_HOSTED__]:
Likewise.
* testsuite/20_util/tuple/cons/deduction.cc [!__STDC_HOSTED__]: 
Likewise.
* testsuite/25_algorithms/move/93872.cc [!__STDC_HOSTED__]: Likewise.
* testsuite/std/ranges/adaptors/100577.cc [!__STDC_HOSTED__]: Likewise.

Signed-off-by: Arsen Arsenović 
---
 .../17_intro/headers/c++1998/stdc++.cc|  2 +
 .../17_intro/tag_type_explicit_ctor.cc| 32 +++
 .../17_intro/using_namespace_std_exp_neg.cc   | 53 ++-
 .../17_intro/using_namespace_std_tr1_neg.cc   | 53 ++-
 .../headers/cstdlib/functions_std.cc  |  2 +
 .../allocator_traits/members/rebind_alloc.cc  |  2 +
 .../requirements/explicit_instantiation.cc|  2 +
 .../20_util/headers/bitset/synopsis.cc|  2 +
 .../requirements/typedefs_neg.cc  |  4 +-
 .../pointer_traits/requirements/typedefs.cc   |  2 +
 .../testsuite/20_util/tuple/cons/deduction.cc |  2 +
 .../testsuite/25_algorithms/move/93872.cc |  1 +
 .../testsuite/std/ranges/adaptors/100577.cc   | 11 +++-
 13 files changed, 104 insertions(+), 64 deletions(-)

diff --git a/libstdc++-v3/testsuite/17_intro/headers/c++1998/stdc++.cc 
b/libstdc++-v3/testsuite/17_intro/headers/c++1998/stdc++.cc
index 4776c18e1ed..e362dfee329 100644
--- a/libstdc++-v3/testsuite/17_intro/headers/c++1998/stdc++.cc
+++ b/libstdc++-v3/testsuite/17_intro/headers/c++1998/stdc++.cc
@@ -24,6 +24,7 @@
 
 #include 
 
+#if __STDC_HOSTED__
 // "C" compatibility headers
 #include 
 #include 
@@ -47,3 +48,4 @@
 #ifdef _GLIBCXX_HAVE_WCTYPE_H
 #include 
 #endif
+#endif
diff --git a/libstdc++-v3/testsuite/17_intro/tag_type_explicit_ctor.cc 
b/libstdc++-v3/testsuite/17_intro/tag_type_explicit_ctor.cc
index 262fc9a04d1..410142d3974 100644
--- a/libstdc++-v3/testsuite/17_intro/tag_type_explicit_ctor.cc
+++ b/libstdc++-v3/testsuite/17_intro/tag_type_explicit_ctor.cc
@@ -20,40 +20,50 @@
 #include 
 #include 
 #include 
-#include 
+
+#if __STDC_HOSTED__
+#  include 
+#endif
 
 void f1(std::nothrow_t);
 void f2(std::piecewise_construct_t);
 void f3(std::allocator_arg_t);
+#if __STDC_HOSTED__
 void f4(std::defer_lock_t);
 void f5(std::try_to_lock_t);
 void f6(std::adopt_lock_t);
-
+#endif
 
 int main()
 {
   std::nothrow_t v1;
   std::piecewise_construct_t v2;
   std::allocator_arg_t v3;
+#if __STDC_HOSTED__
   std::defer_lock_t v4;
   std::try_to_lock_t v5;
   std::try_to_lock_t v6;
+#endif
   std::nothrow_t v7 = {}; // { dg-error "explicit" }
   std::piecewise_construct_t v8 = {}; // { dg-error "explicit" }
   std::allocator_arg_t v9 = {}; // { dg-error "explicit" }
-  std::defer_lock_t v10 = {}; // { dg-error "explicit" }
-  std::try_to_lock_t v11 = {}; // { dg-error "explicit" }
-  std::try_to_lock_t v12 = {}; // { dg-error "explicit" }
+#if __STDC_HOSTED__
+  std::defer_lock_t v10 = {};  // { dg-error "explicit" "" { target hosted } }
+  std::try_to_lock_t v11 = {}; // { dg-error "explicit" "" { target hosted } }
+  std::try_to_lock_t v12 = {}; // { dg-error "explicit" "" { target hosted } }
+#endif
   f1(std::nothrow_t{});
   f2(std::piecewise_construct_t{});
   f3(std::allocator_arg_t{});
-  f4(std::defer_lock_t{});
-  f5(std::try_to_lock_t{});
-  f6(std::adopt_lock_t{});
   f1({}); // { dg-error "explicit" }
   f2({}); // { dg-error "explicit" }
   f3({}); // { dg-error "explicit" }
-  f4({}); // { dg-error "explicit" }
-  f5({}); // { dg-error "explicit" }
-  f6({}); // { dg-error "explicit" }
+#if __STDC_HOSTED__
+  f4(std::defer_lock_t{});
+  f5(std::try_to_lock_t{});
+  f6(std::adopt_lock_t{});
+  f4({}); // { dg-error "explicit" "" { target hosted } }
+  f5({}); // { dg-error "explicit" "" { target hosted } }
+  

[PATCH 09/10] libstdc++: Re-enable std::hash in freestanding [PR103626]

[Arsen Arsenović via Gcc-patches]

PR libstdc++/103626 - _GLIBCXX_HOSTED should respect -ffreestanding

libstdc++-v3/ChangeLog:
PR libstdc++/103626
* include/std/bitset [!_GLIBCXX_HOSTED]: Re-enable std::hash.
* testsuite/20_util/bitset/cons/constexpr_c++23.cc: Require ET
hosted.
* testsuite/20_util/bitset/ext/constexpr.cc: Likewise.

Signed-off-by: Arsen Arsenović 
---
 libstdc++-v3/include/std/bitset  | 9 +
 .../testsuite/20_util/bitset/cons/constexpr_c++23.cc | 2 ++
 libstdc++-v3/testsuite/20_util/bitset/ext/constexpr.cc   | 2 ++
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/libstdc++-v3/include/std/bitset b/libstdc++-v3/include/std/bitset
index 3fe8b18735c..b0b7f3f5482 100644
--- a/libstdc++-v3/include/std/bitset
+++ b/libstdc++-v3/include/std/bitset
@@ -52,9 +52,10 @@
 # include 
 # include 
 # include 
-# if __cplusplus >= 201103L
-#  include 
-# endif
+#endif
+
+#if __cplusplus >= 201103L
+# include 
 #endif
 
 #define _GLIBCXX_BITSET_BITS_PER_WORD  (__CHAR_BIT__ * __SIZEOF_LONG__)
@@ -1649,7 +1650,7 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
 #undef _GLIBCXX_BITSET_BITS_PER_WORD
 #undef _GLIBCXX_BITSET_BITS_PER_ULL
 
-#if __cplusplus >= 201103L && _GLIBCXX_HOSTED
+#if __cplusplus >= 201103L
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
diff --git a/libstdc++-v3/testsuite/20_util/bitset/cons/constexpr_c++23.cc 
b/libstdc++-v3/testsuite/20_util/bitset/cons/constexpr_c++23.cc
index 532fc9dc4d5..d308c2b2f10 100644
--- a/libstdc++-v3/testsuite/20_util/bitset/cons/constexpr_c++23.cc
+++ b/libstdc++-v3/testsuite/20_util/bitset/cons/constexpr_c++23.cc
@@ -1,5 +1,7 @@
 // { dg-options "-std=gnu++23" }
 // { dg-do compile { target c++23 } }
+// This test relies on std::string.
+// { dg-require-effective-target hosted }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/20_util/bitset/ext/constexpr.cc 
b/libstdc++-v3/testsuite/20_util/bitset/ext/constexpr.cc
index f82e7aa409a..4bacefad14a 100644
--- a/libstdc++-v3/testsuite/20_util/bitset/ext/constexpr.cc
+++ b/libstdc++-v3/testsuite/20_util/bitset/ext/constexpr.cc
@@ -1,5 +1,7 @@
 // { dg-options "-std=gnu++23" }
 // { dg-do compile { target c++23 } }
+// This test relies on std::string.
+// { dg-require-effective-target hosted }
 
 #include 
 #include 
-- 
2.37.3

[PATCH 04/10] libstdc++: Mark headers that must be hosted as such [PR103626]

[Arsen Arsenović via Gcc-patches]

PR libstdc++/103626 - _GLIBCXX_HOSTED should respect -ffreestanding

Co-authored-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:
PR libstdc++/103626
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/requires_hosted.h: New header.
* include/experimental/algorithm: Include
.
* include/experimental/any: Likewise.
* include/experimental/array: Likewise.
* include/experimental/buffer: Likewise.
* include/experimental/chrono: Likewise.
* include/experimental/deque: Likewise.
* include/experimental/executor: Likewise.
* include/experimental/filesystem: Likewise.
* include/experimental/forward_list: Likewise.
* include/experimental/functional: Likewise.
* include/experimental/internet: Likewise.
* include/experimental/io_context: Likewise.
* include/experimental/iterator: Likewise.
* include/experimental/list: Likewise.
* include/experimental/map: Likewise.
* include/experimental/memory: Likewise.
* include/experimental/memory_resource: Likewise.
* include/experimental/net: Likewise.
* include/experimental/netfwd: Likewise.
* include/experimental/numeric: Likewise.
* include/experimental/optional: Likewise.
* include/experimental/propagate_const: Likewise.
* include/experimental/random: Likewise.
* include/experimental/ratio: Likewise.
* include/experimental/regex: Likewise.
* include/experimental/scope: Likewise.
* include/experimental/set: Likewise.
* include/experimental/simd: Likewise.
* include/experimental/socket: Likewise.
* include/experimental/source_location: Likewise.
* include/experimental/string: Likewise.
* include/experimental/string_view: Likewise.
* include/experimental/system_error: Likewise.
* include/experimental/timer: Likewise.
* include/experimental/tuple: Likewise.
* include/experimental/unordered_map: Likewise.
* include/experimental/unordered_set: Likewise.
* include/experimental/utility: Likewise.
* include/experimental/vector: Likewise.
* include/std/barrier: Likewise.
* include/std/chrono: Likewise.
* include/std/condition_variable: Likewise.
* include/std/deque: Likewise.
* include/std/execution: Likewise.
* include/std/filesystem: Likewise.
* include/std/forward_list: Likewise.
* include/std/fstream: Likewise.
* include/std/future: Likewise.
* include/std/iomanip: Likewise.
* include/std/ios: Likewise.
* include/std/iosfwd: Likewise.
* include/std/iostream: Likewise.
* include/std/istream: Likewise.
* include/std/latch: Likewise.
* include/std/list: Likewise.
* include/std/locale: Likewise.
* include/std/map: Likewise.
* include/std/memory_resource: Likewise.
* include/std/mutex: Likewise.
* include/std/ostream: Likewise.
* include/std/queue: Likewise.
* include/std/random: Likewise.
* include/std/regex: Likewise.
* include/std/semaphore: Likewise.
* include/std/set: Likewise.
* include/std/shared_mutex: Likewise.
* include/std/spanstream: Likewise.
* include/std/sstream: Likewise.
* include/std/stack: Likewise.
* include/std/stacktrace: Likewise.
* include/std/stop_token: Likewise.
* include/std/streambuf: Likewise.
* include/std/string: Likewise.
* include/std/syncstream: Likewise.
* include/std/system_error: Likewise.
* include/std/thread: Likewise.
* include/std/unordered_map: Likewise.
* include/std/unordered_set: Likewise.
* include/std/valarray: Likewise.
* include/std/vector: Likewise.
* include/tr1/array: Likewise.
* include/tr1/ccomplex: Likewise.
* include/tr1/cctype: Likewise.
* include/tr1/cfenv: Likewise.
* include/tr1/cfloat: Likewise.
* include/tr1/cinttypes: Likewise.
* include/tr1/climits: Likewise.
* include/tr1/cmath: Likewise.
* include/tr1/complex: Likewise.
* include/tr1/complex.h: Likewise.
* include/tr1/cstdarg: Likewise.
* include/tr1/cstdbool: Likewise.
* include/tr1/cstdint: Likewise.
* include/tr1/cstdio: Likewise.
* include/tr1/cstdlib: Likewise.
* include/tr1/ctgmath: Likewise.
* include/tr1/ctime: Likewise.
* include/tr1/ctype.h: Likewise.
* include/tr1/cwchar: Likewise.
* include/tr1/cwctype: Likewise.
* include/tr1/fenv.h: Likewise.
* include/tr1/float.h: Likewise.
* include/tr1/functional: Likewise.
* include/tr1/inttypes.h: Likewise.
* 

[PATCH 08/10] libstdc++: Add effective-target 'hosted' for testsuite [PR103626]

[Arsen Arsenović via Gcc-patches]

From: Jonathan Wakely 

PR libstdc++/103626 - _GLIBCXX_HOSTED should respect -ffreestanding

libstdc++-v3/ChangeLog:
PR libstdc++/103626
* testsuite/lib/libstdc++.exp (check_effective_target_stacktrace):
Also require hosted.
(check_effective_target_hosted): New proc.

Signed-off-by: Arsen Arsenović 
---
 libstdc++-v3/testsuite/lib/libstdc++.exp | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index d3256b6c8c4..635f16db4e8 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1376,7 +1376,7 @@ proc check_effective_target_std_allocator_new { } {
 # Return 1 if libstdc++ was built as --enable-libstdcxx-backtrace
 proc check_effective_target_stacktrace { } {
 return [check_v3_target_prop_cached et_stacktrace {
-   set cond "_GLIBCXX_HAVE_STACKTRACE"
+   set cond "_GLIBCXX_HAVE_STACKTRACE && _GLIBCXX_HOSTED"
return [v3_check_preprocessor_condition stacktrace $cond]
 }]
 }
@@ -1389,6 +1389,14 @@ proc check_effective_target_rtti { } {
 }]
 }
 
+# Return 1 if a hosted implementation is available (i.e. not freestanding).
+proc check_effective_target_hosted { } {
+return [check_v3_target_prop_cached et_hosted {
+   set cond "_GLIBCXX_HOSTED"
+   return [v3_check_preprocessor_condition hosted $cond]
+}]
+}
+
 set additional_prunes ""
 
 if { [info exists env(GCC_RUNTEST_PARALLELIZE_DIR)] \
-- 
2.37.3

[PATCH 06/10] libstdc++: Rework how freestanding install works [PR106953]

[Arsen Arsenović via Gcc-patches]

In light of there being far more freestanding headers now, ad-hoc
maintenance of a subset of the install implementation has become
unsustainable. Instead, we gate off a part of the normal install routine
so that it works without HOSTED enabled, as well as subdivide lists of
headers into freestanding and hosted components, according to the HOSTED
flag.

libstdc++-v3/ChangeLog:

PR libstdc++/106953
* include/Makefile.am [!_GLIBCXX_HOSTED]: Remove
install-freestanding-headers, unifying it with the usual
install-headers
* include/Makefile.in: Regenerate.

Signed-off-by: Arsen Arsenović 
---
 libstdc++-v3/include/Makefile.am | 300 +++---
 libstdc++-v3/include/Makefile.in | 656 +++
 2 files changed, 477 insertions(+), 479 deletions(-)

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 56227427b6d..97542524a69 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -25,58 +25,70 @@ include $(top_srcdir)/fragment.am
 # Standard C++ includes.
 std_srcdir = ${glibcxx_srcdir}/include/std
 std_builddir = .
-std_headers = \
+std_freestanding = \
${std_srcdir}/algorithm \
-   ${std_srcdir}/any \
${std_srcdir}/array \
${std_srcdir}/atomic \
-   ${std_srcdir}/barrier \
${std_srcdir}/bit \
${std_srcdir}/bitset \
+   ${std_srcdir}/concepts \
+   ${std_srcdir}/coroutine \
+   ${std_srcdir}/expected \
+   ${std_srcdir}/functional \
+   ${std_srcdir}/iterator \
+   ${std_srcdir}/limits \
+   ${std_srcdir}/memory \
+   ${std_srcdir}/numbers \
+   ${std_srcdir}/numeric \
+   ${std_srcdir}/optional \
+   ${std_srcdir}/ranges \
+   ${std_srcdir}/ratio \
+   ${std_srcdir}/scoped_allocator \
+   ${std_srcdir}/source_location \
+   ${std_srcdir}/span \
+   ${std_srcdir}/tuple \
+   ${std_srcdir}/type_traits \
+   ${std_srcdir}/typeindex \
+   ${std_srcdir}/utility \
+   ${std_srcdir}/variant \
+   ${std_srcdir}/version
+
+if !GLIBCXX_HOSTED
+std_headers = ${std_freestanding}
+else GLIBCXX_HOSTED
+std_headers = \
+   ${std_freestanding} \
+   ${std_srcdir}/any \
+   ${std_srcdir}/barrier \
${std_srcdir}/charconv \
${std_srcdir}/chrono \
${std_srcdir}/codecvt \
${std_srcdir}/complex \
-   ${std_srcdir}/concepts \
${std_srcdir}/condition_variable \
-   ${std_srcdir}/coroutine \
${std_srcdir}/deque \
${std_srcdir}/execution \
-   ${std_srcdir}/expected \
${std_srcdir}/filesystem \
${std_srcdir}/forward_list \
${std_srcdir}/fstream \
-   ${std_srcdir}/functional \
${std_srcdir}/future \
${std_srcdir}/iomanip \
${std_srcdir}/ios \
${std_srcdir}/iosfwd \
${std_srcdir}/iostream \
${std_srcdir}/istream \
-   ${std_srcdir}/iterator \
${std_srcdir}/latch \
-   ${std_srcdir}/limits \
${std_srcdir}/list \
${std_srcdir}/locale \
${std_srcdir}/map \
-   ${std_srcdir}/memory \
${std_srcdir}/memory_resource \
${std_srcdir}/mutex \
-   ${std_srcdir}/numbers \
-   ${std_srcdir}/numeric \
-   ${std_srcdir}/optional \
${std_srcdir}/ostream \
${std_srcdir}/queue \
${std_srcdir}/random \
-   ${std_srcdir}/ranges \
-   ${std_srcdir}/ratio \
${std_srcdir}/regex \
-   ${std_srcdir}/scoped_allocator \
${std_srcdir}/semaphore \
${std_srcdir}/set \
${std_srcdir}/shared_mutex \
-   ${std_srcdir}/source_location \
-   ${std_srcdir}/span \
${std_srcdir}/spanstream \
${std_srcdir}/sstream \
${std_srcdir}/syncstream \
@@ -89,26 +101,68 @@ std_headers = \
${std_srcdir}/string_view \
${std_srcdir}/system_error \
${std_srcdir}/thread \
-   ${std_srcdir}/tuple \
-   ${std_srcdir}/typeindex \
-   ${std_srcdir}/type_traits \
${std_srcdir}/unordered_map \
${std_srcdir}/unordered_set \
-   ${std_srcdir}/utility \
${std_srcdir}/valarray \
-   ${std_srcdir}/variant \
-   ${std_srcdir}/vector \
-   ${std_srcdir}/version
+   ${std_srcdir}/vector
+endif GLIBCXX_HOSTED
 
 bits_srcdir = ${glibcxx_srcdir}/include/bits
 bits_builddir = ./bits
-bits_headers = \
+bits_freestanding = \
${bits_srcdir}/algorithmfwd.h \
${bits_srcdir}/align.h \
-   ${bits_srcdir}/alloc_traits.h \
-   ${bits_srcdir}/allocated_ptr.h \
${bits_srcdir}/allocator.h \
+   ${bits_srcdir}/alloc_traits.h \
${bits_srcdir}/atomic_base.h \
+   ${bits_srcdir}/c++0x_warning.h \
+   ${bits_srcdir}/boost_concept_check.h \
+   ${bits_srcdir}/concept_check.h \
+   ${bits_srcdir}/cpp_type_traits.h \
+   ${bits_srcdir}/enable_special_members.h \
+   ${bits_srcdir}/functexcept.h \
+   

[PATCH 03/10] libstdc++: Adjust precompiled headers for freestanding

[Arsen Arsenović via Gcc-patches]

From: Jonathan Wakely 

Co-authored-by: Arsen Arsenović 

libstdc++-v3/ChangeLog:

* include/precompiled/extc++.h [!_GLIBCXX_HOSTED]: Do not
include headers that aren't valid for freestanding.
* include/precompiled/stdc++.h [!_GLIBCXX_HOSTED]: Likewise.

Signed-off-by: Arsen Arsenović 
---
 libstdc++-v3/include/precompiled/extc++.h | 17 +++--
 libstdc++-v3/include/precompiled/stdc++.h | 81 +--
 2 files changed, 86 insertions(+), 12 deletions(-)

diff --git a/libstdc++-v3/include/precompiled/extc++.h 
b/libstdc++-v3/include/precompiled/extc++.h
index 7fe70738042..b094701aafb 100644
--- a/libstdc++-v3/include/precompiled/extc++.h
+++ b/libstdc++-v3/include/precompiled/extc++.h
@@ -32,14 +32,21 @@
 #include 
 #endif
 
-#include 
 #if __cplusplus >= 201103L
 # include 
 #endif
 #include 
 #include 
-#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if _GLIBCXX_HOSTED
+#include 
+#include 
 #if __cplusplus >= 201103L
 # include 
 #endif
@@ -47,15 +54,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #if __cplusplus >= 201103L
 # include 
@@ -66,8 +70,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -81,3 +83,4 @@
  #include 
  #include 
 #endif
+#endif // HOSTED
diff --git a/libstdc++-v3/include/precompiled/stdc++.h 
b/libstdc++-v3/include/precompiled/stdc++.h
index 5ee1244dc22..bfbb1654b88 100644
--- a/libstdc++-v3/include/precompiled/stdc++.h
+++ b/libstdc++-v3/include/precompiled/stdc++.h
@@ -28,6 +28,80 @@
 
 // 17.4.1.2 Headers
 
+// C
+#ifndef _GLIBCXX_NO_ASSERT
+#include 
+#endif
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if __cplusplus >= 201103L
+#include 
+#endif
+
+// C++
+// #include 
+// #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if __cplusplus >= 201103L
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif
+
+#if __cplusplus >= 201402L
+#endif
+
+#if __cplusplus >= 201703L
+#include 
+#include 
+// #include 
+#include 
+#include 
+#endif
+
+#if __cplusplus >= 202002L
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif
+
+#if __cplusplus > 202002L
+#include 
+#include 
+#if __cpp_impl_coroutine
+# include 
+#endif
+#endif
+
+
+#if _GLIBCXX_HOSTED
 // C
 #ifndef _GLIBCXX_NO_ASSERT
 #include 
@@ -62,8 +136,6 @@
 #endif
 
 // C++
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -138,9 +210,6 @@
 #include 
 #include 
 #include 
-#if __cpp_impl_coroutine
-# include 
-#endif
 #include 
 #include 
 #include 
@@ -160,3 +229,5 @@
 #endif
 #include 
 #endif
+
+#endif // HOSTED
-- 
2.37.3

[PATCH 02/10] libstdc++: Filter out unconditional default include

[Arsen Arsenović via Gcc-patches]

_AC_INCLUDES_DEFAULT_REQUIREMENTS including  when checking for
stdint.h has prevented proper detection of whether stdint.h is present,
since it'd poison the cache variables with test results failing due to
 failing to include. As a solution, for autoconf versions under
2.70, we filter out that bit of code from ac_includes_default.

This issue was fixed in autoconf-2.70.
This also applies to various other headers, but was noticed when looking
into why HAVE_STDINT_H was misdefined.

libstdc++-v3/ChangeLog:

* configure.ac: Remove any lines that unconditionally include
 from ac_includes_default, when running Autoconf <2.70.
* configure: Regenerate.

Signed-off-by: Arsen Arsenović 
---
 libstdc++-v3/configure.ac | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index b351622bf46..c05fcdda7e9 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -58,6 +58,15 @@ else
   GLIBCXX_IS_NATIVE=true
 fi
 
+# In the case that we're building without headers, we won't have 
+# available. In these cases, we have to instruct autotools to never include
+#  as a part of default headers.
+m4_version_prereq([2.70], [], [
+if test "x$with_headers" = "xno"; then
+  ac_includes_default=`echo "$ac_includes_default" | sed '/^#include 
$/d'`
+fi
+])
+
 # Sets up automake.  Must come after AC_CANONICAL_SYSTEM.  Each of the
 # following is magically included in AUTOMAKE_OPTIONS in each Makefile.am.
 #  1.x:  minimum required version
-- 
2.37.3

[PATCH 05/10] c-family: Implement new `int main' semantics in freestanding

[Arsen Arsenović via Gcc-patches]

>From now, by default, (specifically) `int main' in freestanding will
implicitly return 0, as it does for hosted modes. The old behaviour is
still accessible via -fno-builtin-main.

gcc/c-family/ChangeLog:

* c-common.cc (disable_builtin_function): Support special value
`main' that, in freestanding, allows disabling special casing
placed around `main'.
* c-common.h: Add flag_builtin_main.
(want_builtin_main_p): New function, true iff hosted OR
builtin_main are set.

gcc/c/ChangeLog:

* c-decl.cc (grokdeclarator): Consider flag_builtin_main when
deciding whether to emit warnings.
(finish_function): Consider flag_builtin_main when deciding
whether to emit an implicit zero return.
* c-objc-common.cc (c_missing_noreturn_ok_p): Consider missing
noreturn okay only when hosted or when builtin_main is enabled.

gcc/cp/ChangeLog:

* cp-tree.h (DECL_MAIN_P): Consider flag_builtin_main when
deciding whether this function is to be the special function
main.

gcc/ChangeLog:

* doc/invoke.texi: Document -fno-builtin-main.

gcc/testsuite/ChangeLog:

* gcc.dg/c11-noreturn-4.c: Add -fno-builtin-main to options.
* gcc.dg/inline-10.c: Likewise.
* gcc.dg/noreturn-4.c: Likewise.
* g++.dg/freestanding-main-implicitly-returns.C: New test.
* g++.dg/no-builtin-main.C: New test.
* gcc.dg/freestanding-main-implicitly-returns.c: New test.
* gcc.dg/no-builtin-main.c: New test.

Signed-off-by: Arsen Arsenović 
---
 gcc/c-family/c-common.cc  |  6 ++
 gcc/c-family/c-common.h   | 10 ++
 gcc/c/c-decl.cc   |  4 ++--
 gcc/c/c-objc-common.cc|  9 ++---
 gcc/cp/cp-tree.h  | 12 ++-
 gcc/doc/invoke.texi   | 20 ++-
 .../freestanding-main-implicitly-returns.C|  5 +
 gcc/testsuite/g++.dg/no-builtin-main.C|  5 +
 gcc/testsuite/gcc.dg/c11-noreturn-4.c |  2 +-
 .../freestanding-main-implicitly-returns.c|  5 +
 gcc/testsuite/gcc.dg/inline-10.c  |  2 +-
 gcc/testsuite/gcc.dg/no-builtin-main.c|  5 +
 gcc/testsuite/gcc.dg/noreturn-4.c |  2 +-
 13 files changed, 69 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/freestanding-main-implicitly-returns.C
 create mode 100644 gcc/testsuite/g++.dg/no-builtin-main.C
 create mode 100644 gcc/testsuite/gcc.dg/freestanding-main-implicitly-returns.c
 create mode 100644 gcc/testsuite/gcc.dg/no-builtin-main.c

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 3c60a89bfe2..117db8a1928 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -232,6 +232,10 @@ int flag_isoc2x;
 
 int flag_hosted = 1;
 
+/* Nonzero means that we want to give main its special meaning */
+
+int flag_builtin_main = 1;
+
 
 /* ObjC language option variables.  */
 
@@ -4878,6 +4882,8 @@ disable_builtin_function (const char *name)
 {
   if (startswith (name, "__builtin_"))
 error ("cannot disable built-in function %qs", name);
+  else if (strcmp("main", name) == 0)
+flag_builtin_main = 0;
   else
 {
   disabled_builtin *new_disabled_builtin = XNEW (disabled_builtin);
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 5f470d94f4a..cbed5f0f9e8 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -687,6 +687,16 @@ extern int flag_isoc2x;
 
 extern int flag_hosted;
 
+/* Nonzero means that we want to give main its special meaning */
+
+extern int flag_builtin_main;
+
+/* Returns false if both flag_hosted and flag_builtin_main are zero, true
+   otherwise. */
+inline bool builtin_main_p() {
+  return flag_hosted || flag_builtin_main;
+}
+
 /* ObjC language option variables.  */
 
 
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index bac8e6cc3f6..5060b3f2a41 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -7695,7 +7695,7 @@ grokdeclarator (const struct c_declarator *declarator,
 
/* Record presence of `inline' and `_Noreturn', if it is
   reasonable.  */
-   if (flag_hosted && MAIN_NAME_P (declarator->u.id.id))
+   if (builtin_main_p() && MAIN_NAME_P (declarator->u.id.id))
  {
if (declspecs->inline_p)
  pedwarn (loc, 0, "cannot inline function %");
@@ -10314,7 +10314,7 @@ finish_function (location_t end_loc)
   if (DECL_RESULT (fndecl) && DECL_RESULT (fndecl) != error_mark_node)
 DECL_CONTEXT (DECL_RESULT (fndecl)) = fndecl;
 
-  if (MAIN_NAME_P (DECL_NAME (fndecl)) && flag_hosted
+  if (MAIN_NAME_P (DECL_NAME (fndecl)) && builtin_main_p()
   && TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (fndecl)))
   == integer_type_node && flag_isoc99)
 {
diff --git a/gcc/c/c-objc-common.cc b/gcc/c/c-objc-common.cc
index 70e10a98e33..e229580b182 100644

[PATCH 00/10] c-family,libstdc++: P1642 and related changes

[Arsen Arsenović via Gcc-patches]

Hi,

This patchset:
- Implements the P1642 WG21 paper, with a fair few extensions,
- Fixes libstdc++' build system on systems --without-headers,
- Ports (a large chunk of) the libstdc++ testsuite to freestanding, and
- Changes the semantics of `int main' in freestanding (!!).

Thanks,

Arsen Arsenović (7):
  libstdc++: Filter out unconditional  default include
  libstdc++: Mark headers that must be hosted as such [PR103626]
  c-family: Implement new `int main' semantics in freestanding
  libstdc++: Rework how freestanding install works [PR106953]
  libstdc++: Make some tests work on freestanding [PR103626]
  libstdc++: Re-enable std::hash in freestanding [PR103626]
  libstdc++: Disable hosted-only tests [PR103626]

Jonathan Wakely (3):
  libstdc++: Make _GLIBCXX_HOSTED respect -ffreestanding [PR103626]
  libstdc++: Adjust precompiled headers for freestanding
  libstdc++: Add effective-target 'hosted' for testsuite [PR103626]

 gcc/c-family/c-common.cc  |   6 +
 gcc/c-family/c-common.h   |  10 +
 gcc/c/c-decl.cc   |   4 +-
 gcc/c/c-objc-common.cc|   9 +-
 gcc/cp/cp-tree.h  |  12 +-
 gcc/doc/invoke.texi   |  20 +-
 .../freestanding-main-implicitly-returns.C|   5 +
 gcc/testsuite/g++.dg/no-builtin-main.C|   5 +
 gcc/testsuite/gcc.dg/c11-noreturn-4.c |   2 +-
 .../freestanding-main-implicitly-returns.c|   5 +
 gcc/testsuite/gcc.dg/inline-10.c  |   2 +-
 gcc/testsuite/gcc.dg/no-builtin-main.c|   5 +
 gcc/testsuite/gcc.dg/noreturn-4.c |   2 +-
 libstdc++-v3/acinclude.m4 |   2 +-
 libstdc++-v3/configure|   2 +-
 libstdc++-v3/configure.ac |   9 +
 libstdc++-v3/include/Makefile.am  | 303 
 libstdc++-v3/include/Makefile.in  | 657 +-
 libstdc++-v3/include/bits/algorithmfwd.h  |   4 +
 libstdc++-v3/include/bits/concept_check.h |   2 +-
 libstdc++-v3/include/bits/ranges_algo.h   |   2 +
 libstdc++-v3/include/bits/requires_hosted.h   |  37 +
 libstdc++-v3/include/bits/stl_algo.h  |   2 +-
 libstdc++-v3/include/c_global/cmath   |   2 +
 libstdc++-v3/include/experimental/algorithm   |   2 +
 libstdc++-v3/include/experimental/any |   2 +
 libstdc++-v3/include/experimental/array   |   2 +
 libstdc++-v3/include/experimental/buffer  |   2 +
 libstdc++-v3/include/experimental/chrono  |   2 +
 libstdc++-v3/include/experimental/deque   |   2 +
 libstdc++-v3/include/experimental/executor|   2 +
 libstdc++-v3/include/experimental/filesystem  |   2 +
 .../include/experimental/forward_list |   2 +
 libstdc++-v3/include/experimental/functional  |   2 +
 libstdc++-v3/include/experimental/internet|   2 +
 libstdc++-v3/include/experimental/io_context  |   2 +
 libstdc++-v3/include/experimental/iterator|   2 +
 libstdc++-v3/include/experimental/list|   2 +
 libstdc++-v3/include/experimental/map |   2 +
 libstdc++-v3/include/experimental/memory  |   2 +
 .../include/experimental/memory_resource  |   2 +
 libstdc++-v3/include/experimental/net |   2 +
 libstdc++-v3/include/experimental/netfwd  |   2 +
 libstdc++-v3/include/experimental/numeric |   2 +
 libstdc++-v3/include/experimental/optional|   2 +
 .../include/experimental/propagate_const  |   2 +
 libstdc++-v3/include/experimental/random  |   2 +
 libstdc++-v3/include/experimental/ratio   |   2 +
 libstdc++-v3/include/experimental/regex   |   2 +
 libstdc++-v3/include/experimental/scope   |   2 +
 libstdc++-v3/include/experimental/set |   2 +
 libstdc++-v3/include/experimental/simd|   2 +
 libstdc++-v3/include/experimental/socket  |   2 +
 .../include/experimental/source_location  |   2 +
 libstdc++-v3/include/experimental/string  |   2 +
 libstdc++-v3/include/experimental/string_view |   2 +
 .../include/experimental/system_error |   2 +
 libstdc++-v3/include/experimental/timer   |   2 +
 libstdc++-v3/include/experimental/tuple   |   2 +
 .../include/experimental/unordered_map|   2 +
 .../include/experimental/unordered_set|   2 +
 libstdc++-v3/include/experimental/utility |   2 +
 libstdc++-v3/include/experimental/vector  |   2 +
 libstdc++-v3/include/ext/algorithm|   2 +
 libstdc++-v3/include/ext/bitmap_allocator.h   |   2 +
 libstdc++-v3/include/ext/cmath|   2 +
 .../include/ext/codecvt_specializations.h |   2 +
 libstdc++-v3/include/ext/debug_allocator.h|   2 +
 libstdc++-v3/include/ext/enc_filebuf.h|   2 +
 libstdc++-v3/include/ext/extptr_allocator.h   |   2 +
 libstdc++-v3/include/ext/functional   |   2 +
 libstdc++-v3/include/ext/malloc_allocator.h   |   2 +
 libstdc++-v3/include/ext/memory   |   2 +
 

[PATCH 01/10] libstdc++: Make _GLIBCXX_HOSTED respect -ffreestanding [PR103626]

[Arsen Arsenović via Gcc-patches]

From: Jonathan Wakely 

This allows the library to switch to freestanding mode when compiling
with the -ffreestanding flag. This means you don't need a separate
libstdc++ build configured with --disable-hosted-libstdcxx in order to
compile for a freestanding environment.

The testsuite support files cannot be compiled for freestanding, so add
-fno-freestanding to override any -ffreestanding in the test flags.

libstdc++-v3/ChangeLog:

PR libstdc++/103626
* acinclude.m4 (GLIBCXX_ENABLE_HOSTED): Define _GLIBCXX_HOSTED
to __STDC_HOSTED__ for non-freestanding installations.
* configure: Regenerate.
* include/Makefile.am (${host_builddir}/c++config.h): Adjust
grep pattern.
* include/Makefile.in: Regenerate.
* testsuite/lib/libstdc++.exp (v3-build_support): Use
-fno-freestanding.
* testsuite/libstdc++-abi/abi.exp: Likewise.

Signed-off-by: Arsen Arsenović 
---
 libstdc++-v3/acinclude.m4| 2 +-
 libstdc++-v3/configure   | 2 +-
 libstdc++-v3/include/Makefile.am | 2 +-
 libstdc++-v3/include/Makefile.in | 2 +-
 libstdc++-v3/testsuite/lib/libstdc++.exp | 4 ++--
 libstdc++-v3/testsuite/libstdc++-abi/abi.exp | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 9aa81e1ac13..1b404d7df22 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2992,7 +2992,7 @@ AC_DEFUN([GLIBCXX_ENABLE_HOSTED], [
 fi
   else
 is_hosted=yes
-hosted_define=1
+hosted_define=__STDC_HOSTED__
   fi
   GLIBCXX_CONDITIONAL(GLIBCXX_HOSTED, test $is_hosted = yes)
   AC_DEFINE_UNQUOTED(_GLIBCXX_HOSTED, $hosted_define,
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 07916d14d93..1ff28af2c2c 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -15651,7 +15651,7 @@ $as_echo "$as_me: Only freestanding libraries will be 
built" >&6;}
 fi
   else
 is_hosted=yes
-hosted_define=1
+hosted_define=__STDC_HOSTED__
   fi
 
 
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 3eeb407a57f..3472e84f75c 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1326,7 +1326,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
${CONFIG_HEADER} > /dev/null 2>&1 \
&& ldbl_alt128_compat='s,^#undef 
_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT$$,#define _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT 
1,' ;\
verbose_assert='s,g,g,' ; \
-   grep "^[ ]*#[]*define[   ][  ]*_GLIBCXX_HOSTED[ 
 ][  ]*1[]*$$" \
+   grep "^[ ]*#[]*define[   ][  ]*_GLIBCXX_HOSTED[ 
 ][  ]*__STDC_HOSTED__[  ]*$$" \
${CONFIG_HEADER} > /dev/null 2>&1 \
&& grep "^[  ]*#[]*define[   ][  ]*_GLIBCXX_VERBOSE[
 ][  ]*1[]*$$" \
${CONFIG_HEADER} > /dev/null 2>&1 \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index e24563caaed..39ef34fc3ce 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -1820,7 +1820,7 @@ ${host_builddir}/c++config.h: ${CONFIG_HEADER} \
${CONFIG_HEADER} > /dev/null 2>&1 \
&& ldbl_alt128_compat='s,^#undef 
_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT$$,#define _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT 
1,' ;\
verbose_assert='s,g,g,' ; \
-   grep "^[ ]*#[]*define[   ][  ]*_GLIBCXX_HOSTED[ 
 ][  ]*1[]*$$" \
+   grep "^[ ]*#[]*define[   ][  ]*_GLIBCXX_HOSTED[ 
 ][  ]*__STDC_HOSTED__[  ]*$$" \
${CONFIG_HEADER} > /dev/null 2>&1 \
&& grep "^[  ]*#[]*define[   ][  ]*_GLIBCXX_VERBOSE[
 ][  ]*1[]*$$" \
${CONFIG_HEADER} > /dev/null 2>&1 \
diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 0338b50897f..d3256b6c8c4 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -654,7 +654,7 @@ proc v3-build_support { } {
# do not prevent compilation.
# Disable LTO so that ar/ranlib don't need the LTO plugin.
if { [v3_target_compile $srcdir/util/$f $object_file "object" \
- [list "incdir=$srcdir" "additional_flags=-w -fno-lto"]]
+ [list "incdir=$srcdir" "additional_flags=-w -fno-lto 
-fno-freestanding"]]
 != "" } {
error "could not compile $f"
}
@@ -693,7 +693,7 @@ proc v3-build_support { } {
# Compile with "-w" so that warnings issued by the compiler
# do not prevent compilation.
if { [v3_target_compile $srcdir/util/$f $object_file "sharedlib" \
-[list "incdir=$srcdir" "additional_flags=-fno-inline -w -shared 
-fPIC -DPIC -std=gnu++98"]]
+[list "incdir=$srcdir" 

[PATCH] openmp: Add begin declare target support

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch adds support for the begin declare target construct,
which is another spelling for declare target construct without clauses
(where it needs paired end declare target), but unlike that one accepts
clauses.

This is an OpenMP 5.1 feature, implemented with 5.2 clarification because
in 5.1 we had a restriction in the declare target chapter shared by
declare target and begin declare target that if there are any clauses
specified at least one of them needs to be to or link.  But that
was of course meant just for declare target and not begin declare target,
because begin declare target doesn't even allow to/link/enter clauses.
In addition to that, the patch also makes device_type clause duplication
an error (as stated in 5.1) and similarly makes declare target with
just device_type clause an error rather than warning.

What this patch doesn't do is:
1) OpenMP 5.1 also added an indirect clause, we don't support that
   neither on declare target nor begin declare target
   and I couldn't find it in our features pages (neither libgomp.texi
   nor web)
2) I think device_type(nohost)/device_type(host) support can't work for
   variables (in 5.0 it only talked about procedures so this could be
   also thought as 5.1 feature that we should just add to the list
   and implement)
3) I don't see any use of the "omp declare target nohost" attribute, so
   I'm not sure if device_type(nohost) works at all

Will commit this tomorrow if bootstrap/regtest succeeds.

2022-09-30  Jakub Jelinek  

gcc/c-family/
* c-omp.cc (c_omp_directives): Uncomment begin declare target
entry.
gcc/c/
* c-lang.h (struct c_omp_declare_target_attr): New type.
(current_omp_declare_target_attribute): Change type from
int to vec *.
* c-parser.cc (c_parser_translation_unit): Adjust for that change.
If last pushed directive was begin declare target, use different
wording and simplify format strings for easier translations.
(c_parser_omp_clause_device_type): Uncomment
check_no_duplicate_clause call.
(c_parser_omp_declare_target): Adjust for the
current_omp_declare_target_attribute type change, push { -1 }.
Use error_at rather than warning_at for declare target with
only device_type clauses.
(OMP_BEGIN_DECLARE_TARGET_CLAUSE_MASK): Define.
(c_parser_omp_begin): Add begin declare target support.
(c_parser_omp_end): Adjust for the
current_omp_declare_target_attribute type change, adjust
diagnostics wording and simplify format strings for easier
translations.
* c-decl.cc (current_omp_declare_target_attribute): Change type from
int to vec *.
(c_decl_attributes): Adjust for the
current_omp_declare_target_attribute type change.  If device_type
was present on begin declare target, add "omp declare target host"
and/or "omp declare target nohost" attributes.
gcc/cp/
* cp-tree.h (struct omp_declare_target_attr): Rename to ...
(cp_omp_declare_target_attr): ... this.  Add device_type member.
(omp_begin_assumes_data): Rename to ...
(cp_omp_begin_assumes_data): ... this.
(struct saved_scope): Change types of omp_declare_target_attribute
and omp_begin_assumes.
* parser.cc (cp_parser_omp_clause_device_type): Uncomment
check_no_duplicate_clause call.
(cp_parser_omp_all_clauses): Fix up pasto, c_name for OMP_CLAUSE_LINK
should be "link" rather than "to".
(cp_parser_omp_declare_target): Adjust for omp_declare_target_attr
to cp_omp_declare_target_attr changes, push -1 as device_type.  Use
error_at rather than warning_at for declare target with only
device_type clauses.
(OMP_BEGIN_DECLARE_TARGET_CLAUSE_MASK): Define.
(cp_parser_omp_begin): Add begin declare target support.  Adjust
for omp_begin_assumes_data to cp_omp_begin_assumes_data change.
(cp_parser_omp_end): Adjust for the
omp_declare_target_attr to cp_omp_declare_target_attr and
omp_begin_assumes_data to cp_omp_begin_assumes_data type changes,
adjust diagnostics wording and simplify format strings for easier
translations.
* semantics.cc (finish_translation_unit): Likewise.
* decl2.cc (cplus_decl_attributes): If device_type was present on
begin declare target, add "omp declare target host" and/or
"omp declare target nohost" attributes.
gcc/testsuite/
* c-c++-common/gomp/declare-target-4.c: Move tests that are now
rejected into declare-target-7.c.
* c-c++-common/gomp/declare-target-6.c: Adjust expected diagnostics.
* c-c++-common/gomp/declare-target-7.c: New test.
* c-c++-common/gomp/begin-declare-target-1.c: New test.
* c-c++-common/gomp/begin-declare-target-2.c: New test.
* c-c++-common/gomp/begin-declare-target-3.c: New test.
  

[PATCH] undef offsetof before defining it in stddef.h

[Olivier Hainque via Gcc-patches]

Hello,

The attached patch is a proposal to #undef offsetof before
the #define we do in ginclude/stddef.h, which prevents redefinition
warnings from dg tests passing -Wsystem-headers on systems which
provide a definition in system headers, such as VxWorks.

We have been using this for a while with gcc-11 based toolchains
for a wide range of configurations (linux and windows hosts, native
and cross, bare board or VxWorks for a range of CPUs).

This also passes build + sanity test with gcc-12 for
powerpc64-vxworks7r2, then full bootstrap + regression testing
for mainline on x86_64-linux.

Ok to commit?

Thanks in advance!

With Kind Regards,

Olivier

2022-09-30  Olivier Hainque  

gcc/
   * ginclude/stddef.h: #undef offsetof before #define.



0003-undef-offsetof-before-defining-it-in-stddef.h.patch
Description: Binary data

Re: C++ ABI

[Patrick Palka via Gcc-patches]

On Fri, 30 Sep 2022, Nathan Sidwell wrote:

> Hi,
> I've discovered some mangling problems with lambdas.  (a) divergence from
> clang and (b) manglings that incorrectly demangle.  With #a I'm not yet sure
> who is correct.  for #b g++ is definitely wrong.
> 
> From the docs, it doesn't appear to have been bumped this cycle.  Is that
> correct, and I should bump it to 18?

AFAICT it hasn't been bumped since no mangling changes have been made
yet this cycle.

> 
> nathan
> -- 
> Nathan Sidwell
> 
> 

Re: [PATCH v3] testsuite: Only run test on target if VMA == LMA

[Richard Sandiford via Gcc-patches]

Torbjörn SVENSSON  writes:
> Checking that the triplet matches arm*-*-eabi (or msp430-*-*) is not
> enough to know if the execution will enter an endless loop, or if it
> will give a meaningful result. As the execution test only work when
> VMA and LMA are equal, make sure that this condition is met.
>
> gcc/ChangeLog:
>
>   * doc/sourcebuild.texi: Document new vma_equals_lma effective
>target check.
>
> gcc/testsuite/ChangeLog:
>
>   * lib/target-supports.exp (check_effective_target_vma_equals_lma): New.
> * c-c++-common/torture/attr-noinit-1.c: Requre VMA == LMA to run.
> * c-c++-common/torture/attr-noinit-2.c: Likewise.
> * c-c++-common/torture/attr-noinit-3.c: Likewise.
> * c-c++-common/torture/attr-persistent-1.c: Likewise.
> * c-c++-common/torture/attr-persistent-3.c: Likewise.

OK, thanks.

Richard

> Co-Authored-By: Yvan ROUX  
> Signed-off-by: Torbjörn SVENSSON  
> ---
>  gcc/doc/sourcebuild.texi  |  3 ++
>  .../c-c++-common/torture/attr-noinit-1.c  |  3 +-
>  .../c-c++-common/torture/attr-noinit-2.c  |  3 +-
>  .../c-c++-common/torture/attr-noinit-3.c  |  3 +-
>  .../c-c++-common/torture/attr-persistent-1.c  |  3 +-
>  .../c-c++-common/torture/attr-persistent-3.c  |  3 +-
>  gcc/testsuite/lib/target-supports.exp | 49 +++
>  7 files changed, 62 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 52357cc7aee..c81e2ffd43a 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -2868,6 +2868,9 @@ Vector alignment is reachable for types of 32 bits or 
> less.
>  @item vector_alignment_reachable_for_64bit
>  Vector alignment is reachable for types of 64 bits or less.
>  
> +@item vma_equals_lma
> +Target generates executable with VMA equal to LMA for .data section.
> +
>  @item wchar_t_char16_t_compatible
>  Target supports @code{wchar_t} that is compatible with @code{char16_t}.
>  
> diff --git a/gcc/testsuite/c-c++-common/torture/attr-noinit-1.c 
> b/gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
> index 877e7647ac9..f84eba0b649 100644
> --- a/gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
> +++ b/gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
> @@ -1,4 +1,5 @@
> -/* { dg-do run } */
> +/* { dg-do link } */
> +/* { dg-do run { target { vma_equals_lma } } } */
>  /* { dg-require-effective-target noinit } */
>  /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
>  /* { dg-options "-save-temps" } */
> diff --git a/gcc/testsuite/c-c++-common/torture/attr-noinit-2.c 
> b/gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
> index befa2a0bd52..4528b9e3cfa 100644
> --- a/gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
> +++ b/gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
> @@ -1,4 +1,5 @@
> -/* { dg-do run } */
> +/* { dg-do link } */
> +/* { dg-do run { target { vma_equals_lma } } } */
>  /* { dg-require-effective-target noinit } */
>  /* { dg-options "-fdata-sections -save-temps" } */
>  /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
> diff --git a/gcc/testsuite/c-c++-common/torture/attr-noinit-3.c 
> b/gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
> index 519e88a59a6..2f1745694c9 100644
> --- a/gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
> +++ b/gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
> @@ -1,4 +1,5 @@
> -/* { dg-do run } */
> +/* { dg-do link } */
> +/* { dg-do run { target { vma_equals_lma } } } */
>  /* { dg-require-effective-target noinit } */
>  /* { dg-options "-flto -save-temps" } */
>  /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
> diff --git a/gcc/testsuite/c-c++-common/torture/attr-persistent-1.c 
> b/gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
> index 72dc3c27192..b11a515cef8 100644
> --- a/gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
> +++ b/gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
> @@ -1,4 +1,5 @@
> -/* { dg-do run } */
> +/* { dg-do link } */
> +/* { dg-do run { target { vma_equals_lma } } } */
>  /* { dg-require-effective-target persistent } */
>  /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
>  /* { dg-options "-save-temps" } */
> diff --git a/gcc/testsuite/c-c++-common/torture/attr-persistent-3.c 
> b/gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
> index 3e4fd28618d..068a72af5c8 100644
> --- a/gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
> +++ b/gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
> @@ -1,4 +1,5 @@
> -/* { dg-do run } */
> +/* { dg-do link } */
> +/* { dg-do run { target { vma_equals_lma } } } */
>  /* { dg-require-effective-target persistent } */
>  /* { dg-options "-flto -save-temps" } */
>  /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 0a959c63c4a..7c9dd45f2a7 100644
> --- 

Re: [PATCH] testsuite: Windows paths use \ and not /

[Jonathan Wakely via Gcc-patches]

On Fri, 30 Sept 2022 at 17:04, Torbjörn SVENSSON
 wrote:
>
> libstdc++-v3/testsuite:
>
> * 20_util/bind/ref_neg.cc: Prune Windows paths too.

Please CC the libstdc++ for libstdc++ patches.

OK for trunk, thanks.


>
> Co-Authored-By: Yvan ROUX  
> Signed-off-by: Torbjörn SVENSSON  
> ---
>  libstdc++-v3/testsuite/20_util/bind/ref_neg.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
> b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
> index e779d2f20bd..1e9f3e7fece 100644
> --- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
> +++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
> @@ -50,7 +50,7 @@ void test02()
>
>  // Ignore the reasons for deduction/substitution failure in the headers.
>  // Arrange for the match to work on installed trees as well as build trees.
> -// { dg-prune-output "/(functional|bits/invoke.h):" }
> +// { dg-prune-output "[/\\](functional|bits/invoke.h):" }
>
>  int main()
>  {
> --
> 2.25.1
>

[PATCH v3] testsuite: Only run test on target if VMA == LMA

[Torbjörn SVENSSON via Gcc-patches]

Checking that the triplet matches arm*-*-eabi (or msp430-*-*) is not
enough to know if the execution will enter an endless loop, or if it
will give a meaningful result. As the execution test only work when
VMA and LMA are equal, make sure that this condition is met.

gcc/ChangeLog:

* doc/sourcebuild.texi: Document new vma_equals_lma effective
 target check.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp (check_effective_target_vma_equals_lma): New.
* c-c++-common/torture/attr-noinit-1.c: Requre VMA == LMA to run.
* c-c++-common/torture/attr-noinit-2.c: Likewise.
* c-c++-common/torture/attr-noinit-3.c: Likewise.
* c-c++-common/torture/attr-persistent-1.c: Likewise.
* c-c++-common/torture/attr-persistent-3.c: Likewise.

Co-Authored-By: Yvan ROUX  
Signed-off-by: Torbjörn SVENSSON  
---
 gcc/doc/sourcebuild.texi  |  3 ++
 .../c-c++-common/torture/attr-noinit-1.c  |  3 +-
 .../c-c++-common/torture/attr-noinit-2.c  |  3 +-
 .../c-c++-common/torture/attr-noinit-3.c  |  3 +-
 .../c-c++-common/torture/attr-persistent-1.c  |  3 +-
 .../c-c++-common/torture/attr-persistent-3.c  |  3 +-
 gcc/testsuite/lib/target-supports.exp | 49 +++
 7 files changed, 62 insertions(+), 5 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 52357cc7aee..c81e2ffd43a 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2868,6 +2868,9 @@ Vector alignment is reachable for types of 32 bits or 
less.
 @item vector_alignment_reachable_for_64bit
 Vector alignment is reachable for types of 64 bits or less.
 
+@item vma_equals_lma
+Target generates executable with VMA equal to LMA for .data section.
+
 @item wchar_t_char16_t_compatible
 Target supports @code{wchar_t} that is compatible with @code{char16_t}.
 
diff --git a/gcc/testsuite/c-c++-common/torture/attr-noinit-1.c 
b/gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
index 877e7647ac9..f84eba0b649 100644
--- a/gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
+++ b/gcc/testsuite/c-c++-common/torture/attr-noinit-1.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do link } */
+/* { dg-do run { target { vma_equals_lma } } } */
 /* { dg-require-effective-target noinit } */
 /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
 /* { dg-options "-save-temps" } */
diff --git a/gcc/testsuite/c-c++-common/torture/attr-noinit-2.c 
b/gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
index befa2a0bd52..4528b9e3cfa 100644
--- a/gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
+++ b/gcc/testsuite/c-c++-common/torture/attr-noinit-2.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do link } */
+/* { dg-do run { target { vma_equals_lma } } } */
 /* { dg-require-effective-target noinit } */
 /* { dg-options "-fdata-sections -save-temps" } */
 /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
diff --git a/gcc/testsuite/c-c++-common/torture/attr-noinit-3.c 
b/gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
index 519e88a59a6..2f1745694c9 100644
--- a/gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
+++ b/gcc/testsuite/c-c++-common/torture/attr-noinit-3.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do link } */
+/* { dg-do run { target { vma_equals_lma } } } */
 /* { dg-require-effective-target noinit } */
 /* { dg-options "-flto -save-temps" } */
 /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
diff --git a/gcc/testsuite/c-c++-common/torture/attr-persistent-1.c 
b/gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
index 72dc3c27192..b11a515cef8 100644
--- a/gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
+++ b/gcc/testsuite/c-c++-common/torture/attr-persistent-1.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do link } */
+/* { dg-do run { target { vma_equals_lma } } } */
 /* { dg-require-effective-target persistent } */
 /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
 /* { dg-options "-save-temps" } */
diff --git a/gcc/testsuite/c-c++-common/torture/attr-persistent-3.c 
b/gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
index 3e4fd28618d..068a72af5c8 100644
--- a/gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
+++ b/gcc/testsuite/c-c++-common/torture/attr-persistent-3.c
@@ -1,4 +1,5 @@
-/* { dg-do run } */
+/* { dg-do link } */
+/* { dg-do run { target { vma_equals_lma } } } */
 /* { dg-require-effective-target persistent } */
 /* { dg-options "-flto -save-temps" } */
 /* { dg-skip-if "data LMA != VMA" { msp430-*-* } { "-mlarge" } } */
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 0a959c63c4a..7c9dd45f2a7 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -370,6 +370,55 @@ proc check_weak_override_available { } {
 return [check_weak_available]
 }
 
+# Return 1 if VMA is equal to LMA for the .data section, 0
+# otherwise.  

Re: PING^1 [PATCH] testsuite: Do not prefix linker script with "-Wl, "

[Richard Sandiford via Gcc-patches]

Torbjorn SVENSSON  writes:
> Hi,
>
> Ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601831.html

OK, thanks.

Richard

> Kind regards,
> Torbjörn
>
> On 2022-09-19 18:57, Torbjörn SVENSSON wrote:
>> The linker script should not be prefixed with "-Wl," - it's not an
>> input file and does not interfere with the new dump output filename
>> strategy.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>>  * lib/gcc-defs.exp: Do not prefix linker script with "-Wl,".
>> 
>> Signed-off-by: Torbjörn SVENSSON  
>> ---
>>   gcc/testsuite/lib/gcc-defs.exp | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
>> index 42ef1d85432..2102ed6f7a3 100644
>> --- a/gcc/testsuite/lib/gcc-defs.exp
>> +++ b/gcc/testsuite/lib/gcc-defs.exp
>> @@ -332,7 +332,7 @@ proc gcc_adjust_linker_flags_list { args } {
>>  continue
>>  } elseif { $skip != "" } then {
>>  set skip ""
>> -} elseif { $opt == "-Xlinker" } then {
>> +} elseif { $opt == "-Xlinker" || $opt == "-T" } then {
>>  set skip $opt
>>  } elseif { ![string match "-*" $opt] \
>> && [file isfile $opt] } {

[PATCH] Introduce DWARF_VERSION_DEFAULT (and redefine for VxWorks)

[Olivier Hainque via Gcc-patches]

Hello,

This change is a proposal to introduce a target overridable macro
to replace the hardcoded value used in common.opt to initialize
dwarf_version.

The main advantage compared to special code in a target
override_options hook is that redefinitions by target config files
are visible by both the compiler proper and by the driver, which
might refer to dwarf_version in ASM_DEBUG_SPECs and friends.

This is useful at least on VxWorks, where we usually need to
default to dwarf 4 or even 2 to accommodate non-gdb debuggers
provided by the environment, including for assembly sources
used in libgcc for some ports (witnessed with lse.S on aarch64).

We have been using this in a lot of gcc-11 based toolchains
for various configurations for a while, cross and native.

This is a noop for anything but VxWorks and helped cure crashes
of target debuggers in VxWorks environments.

Bootstrapped and regression tested for mainline on x86_64-linux.

Is this ok to commit?

Thanks in advance!

Best Regards,

Olivier

2022-09-30  Olivier Hainque  

gcc/
* defaults.h (DWARF_DEFAULT_VERSION): Define if not
defined already.
* common.opt (gdwarf-): Use it.
* doc/tm.texi.in (DWARF_DEFAULT_VERSION): Document.
* doc/tm.texi: Update accordingly.

* config/vxworks.h (DWARF_DEFAULT_VERSION): Redefine.
* config/vxworks.cc: Remove code setting dwarf_version, now
handled by the DWARF_DEFAULT_VERSION redefinition.



0012-Introduce-DWARF_VERSION_DEFAULT-and-redefine-for-VxW.patch
Description: Binary data

Re: [PATCH v2] testsuite: Only run test on target if VMA == LMA

[Richard Sandiford via Gcc-patches]

Sorry for the slow reply.

Torbjorn SVENSSON  writes:
> Hi Richard,
>
> Thanks for your review.
> Comments below.
>
> On 2022-09-23 19:34, Richard Sandiford wrote:
>> Torbjörn SVENSSON via Gcc-patches  writes:
>>> Checking that the triplet matches arm*-*-eabi (or msp430-*-*) is not
>>> enough to know if the execution will enter an endless loop, or if it
>>> will give a meaningful result. As the execution test only work when
>>> VMA and LMA are equal, make sure that this condition is met.
>>>
>>> 2022-09-16  Torbjörn SVENSSON  
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * lib/target-supports.exp (check_effective_target_vma_equals_lma): New.
>>>  * c-c++-common/torture/attr-noinit-1.c: Requre VMA == LMA to run.
>>>  * c-c++-common/torture/attr-noinit-2.c: Likewise.
>>>  * c-c++-common/torture/attr-noinit-3.c: Likewise.
>>>  * c-c++-common/torture/attr-persistent-1.c: Likewise.
>>>  * c-c++-common/torture/attr-persistent-3.c: Likewise.
>> 
>> Looks like a nice thing to have.
>> 
>> Could you add an entry to doc/sourcebuild.texi too?
>
> I've added a note and will be shared in a v3.
>
>>> +
>>> +# Example output of objdump:
>>> +#vma_equals_lma9059.exe: file format elf32-littlearm
>>> +#
>>> +#Sections:
>>> +#Idx Name  Size  VMA   LMA   File off  Algn
>>> +#  6 .data 0558  2000  08002658  0002  2**3
>>> +#  CONTENTS, ALLOC, LOAD, DATA
>>> +
>>> +# Capture LMA and VMA columns for .data section
>>> +if ![ regexp "\d*\d+\s+\.data\s+\d+\s+(\d+)\s+(\d+)" $output 
>>> dummy vma lma ] {
>> 
>> Maybe my Tcl is getting rusty, but I'm surprised this quoting works.
>> I'd have expected single backslashes to be interpreted as C-style
>> sequences (for \n etc) and so be eaten before regexp sees them.
>> Quoting with {...} instead of "..." would avoid that.
>
> Good catch! I'm not fluent in Tcl and apparently, I was not testing this 
> well enough before sending it to the list. I got the expected result for 
> the test cases, but for the wrong reason. I've correct it for the v3.
>
>>> +verbose "Could not parse objdump output" 2
>>> +return 0
>>> +} else {
>>> +return [string equal $vma $lma]
>>> +}
>>> +   } else {
>>> +remote_file build delete $exe
>>> +verbose "Could not determine if VMA is equal to LMA. Assuming 
>>> not equal." 2
>>> +return 0
>>> +   }
>> 
>> Would it be more conservative to return 1 on failure rather than 0?
>> That way, a faulty test would trigger XFAILs rather than UNSUPPORTEDs,
>> with XFAILs being more likely to get attention.
>
> The main issue here is that for targets where VMA != LMA, executing the 
> tests will fall into an endless recursion loop. Well, "endless" in the 
> sense that the stack might be depleted or the test will simply timeout. 
> The test cases are designed to assume that it's safe to call _start() 
> from within main() to verify that the state of some variables tagged 
> with certain attributes are correct after a "reset".

Ah, OK.  In that case, I agree return 0 is the right choice.

>> On the other hand, I suppose we don't lose much if these tests are
>> run on common targets only.  So either way is OK, just asking. ;-)
>
> Do you think it's worth to have these tests reach the timeout to have 
> them in the XFAIL list rather than in the UNSUPPORTED list?
> Keep in mind that it's not just one test case, it's 5 test cases times 
> the number of permutations of the CFLAGS...
> It's also not expected that these test cases will be changed in a way 
> that will make them work when VMA != LMA.

Yeah, good points.  Let's stick with it as it is then.

Thanks,
Richard

Re: Extend fold_vec_perm to fold VEC_PERM_EXPR in VLA manner

[Richard Sandiford via Gcc-patches]

Richard Sandiford via Gcc-patches  writes:
> Prathamesh Kulkarni  writes:
>> Sorry to ask a silly question but in which case shall we select 2nd vector ?
>> For num_poly_int_coeffs == 2,
>> a1 /trunc n1 == (a1 + 0x) / (n1.coeffs[0] + n1.coeffs[1]*x)
>> If a1/trunc n1 succeeds,
>> 0 / n1.coeffs[1] == a1/n1.coeffs[0] == 0.
>> So, a1 has to be < n1.coeffs[0] ?
>
> Remember that a1 is itself a poly_int.  It's not necessarily a constant.
>
> E.g. the TRN1 .D instruction maps to a VEC_PERM_EXPR with the selector:
>
>   { 0, 2 + 2x, 1, 4 + 2x, 2, 6 + 2x, ... }

Sorry, should have been:

  { 0, 2 + 2x, 2, 4 + 2x, 4, 6 + 2x, ... }

> which is an interleaving of the two patterns:
>
>   { 0, 2, 4, ... }  a0 = 0, a1 = 2, S = 2
>   { 2 + 2x, 4 + 2x, 6 + 2x }a0 = 2 + 2x, a1 = 4 + 2x, S = 2

[patch] Prevent secondary warning from diagnostic tweak in gthr-vxworks.h

[Olivier Hainque via Gcc-patches]

Within gthr-vxworks.h, we prevent C++ errors from missing
declarations in some system headers by prepending their inclusion
with a

#pragma GCC diagnostic ignored "-Wstrict-prototypes"

But Wstrict-prototypes is internally registered as valid for
C/ObjC only, not C++, and this trick in turn triggers a Wpragma
warning with -Wsystem-headers.

This change just arranges to ignore the secondary warning locally.

We have been using this for a while with gcc-11 based toolchains,
where the only effect was the intended disappearance of a test failure
observed on g++.dg/warn/Wstringop-overflow-6.C.

Sanity checked with a build + basic testing with a gcc-12
compiler, then a mainline build for arm-vxworks7r2.

Cheers

Olivier

2021-02-03  Olivier Hainque  

* config/gthr-vxworks.h: Prevent Wpragma warning for the
pragma diagnostics on Wstrict-prototypes.



0010-Prevent-secondary-warning-from-diagnostic-tweak-in-g.patch
Description: Binary data

Re: Extend fold_vec_perm to fold VEC_PERM_EXPR in VLA manner

[Richard Sandiford via Gcc-patches]

Prathamesh Kulkarni  writes:
> On Tue, 27 Sept 2022 at 01:59, Richard Sandiford
>  wrote:
>>
>> Prathamesh Kulkarni  writes:
>> > On Fri, 23 Sept 2022 at 21:33, Richard Sandiford
>> >  wrote:
>> >>
>> >> Prathamesh Kulkarni  writes:
>> >> > On Tue, 20 Sept 2022 at 18:09, Richard Sandiford
>> >> >  wrote:
>> >> >>
>> >> >> Prathamesh Kulkarni  writes:
>> >> >> > On Mon, 12 Sept 2022 at 19:57, Richard Sandiford
>> >> >> >  wrote:
>> >> >> >>
>> >> >> >> Prathamesh Kulkarni  writes:
>> >> >> >> >> The VLA encoding encodes the first N patterns explicitly.  The
>> >> >> >> >> npatterns/nelts_per_pattern values then describe how to extend 
>> >> >> >> >> that
>> >> >> >> >> initial sequence to an arbitrary number of elements.  So when 
>> >> >> >> >> performing
>> >> >> >> >> an operation on (potentially) variable-length vectors, the 
>> >> >> >> >> questions is:
>> >> >> >> >>
>> >> >> >> >> * Can we work out an initial sequence and 
>> >> >> >> >> npatterns/nelts_per_pattern
>> >> >> >> >>   pair that will be correct for all elements of the result?
>> >> >> >> >>
>> >> >> >> >> This depends on the operation that we're performing.  E.g. it's
>> >> >> >> >> different for unary operations 
>> >> >> >> >> (vector_builder::new_unary_operation)
>> >> >> >> >> and binary operations (vector_builder::new_binary_operations).  
>> >> >> >> >> It also
>> >> >> >> >> varies between unary operations and between binary operations, 
>> >> >> >> >> hence
>> >> >> >> >> the allow_stepped_p parameters.
>> >> >> >> >>
>> >> >> >> >> For VEC_PERM_EXPR, I think the key requirement is that:
>> >> >> >> >>
>> >> >> >> >> (R) Each individual selector pattern must always select from the 
>> >> >> >> >> same vector.
>> >> >> >> >>
>> >> >> >> >> Whether this condition is met depends both on the pattern itself 
>> >> >> >> >> and on
>> >> >> >> >> the number of patterns that it's combined with.
>> >> >> >> >>
>> >> >> >> >> E.g. suppose we had the selector pattern:
>> >> >> >> >>
>> >> >> >> >>   { 0, 1, 4, ... }   i.e. 3x - 2 for x > 0
>> >> >> >> >>
>> >> >> >> >> If the arguments and selector are n elements then this pattern 
>> >> >> >> >> on its
>> >> >> >> >> own would select from more than one argument if 3(n-1) - 2 >= n.
>> >> >> >> >> This is clearly true for large enough n.  So if n is variable 
>> >> >> >> >> then
>> >> >> >> >> we cannot represent this.
>> >> >> >> >>
>> >> >> >> >> If the pattern above is one of two patterns, so interleaved as:
>> >> >> >> >>
>> >> >> >> >>  { 0, _, 1, _, 4, _, ... }  o=0
>> >> >> >> >>   or { _, 0, _, 1, _, 4, ... }  o=1
>> >> >> >> >>
>> >> >> >> >> then the pattern would select from more than one argument if
>> >> >> >> >> 3(n/2-1) - 2 + o >= n.  This too would be a problem for variable 
>> >> >> >> >> n.
>> >> >> >> >>
>> >> >> >> >> But if the pattern above is one of four patterns then it selects
>> >> >> >> >> from more than one argument if 3(n/4-1) - 2 + o >= n.  This is 
>> >> >> >> >> not
>> >> >> >> >> true for any valid n or o, so the pattern is OK.
>> >> >> >> >>
>> >> >> >> >> So let's define some ad hoc terminology:
>> >> >> >> >>
>> >> >> >> >> * Px is the number of patterns in x
>> >> >> >> >> * Ex is the number of elements per pattern in x
>> >> >> >> >>
>> >> >> >> >> where x can be:
>> >> >> >> >>
>> >> >> >> >> * 1: first argument
>> >> >> >> >> * 2: second argument
>> >> >> >> >> * s: selector
>> >> >> >> >> * r: result
>> >> >> >> >>
>> >> >> >> >> Then:
>> >> >> >> >>
>> >> >> >> >> (1) The number of elements encoded explicitly for x is Ex*Px
>> >> >> >> >>
>> >> >> >> >> (2) The explicit encoding can be used to produce a sequence of 
>> >> >> >> >> N*Ex*Px
>> >> >> >> >> elements for any integer N.  This extended sequence can be 
>> >> >> >> >> reencoded
>> >> >> >> >> as having N*Px patterns, with Ex staying the same.
>> >> >> >> >>
>> >> >> >> >> (3) If Ex < 3, Ex can be increased by 1 by repeating the final 
>> >> >> >> >> Px elements
>> >> >> >> >> of the explicit encoding.
>> >> >> >> >>
>> >> >> >> >> So let's assume (optimistically) that we can produce the result
>> >> >> >> >> by calculating the first Pr*Er elements and using the Pr,Er 
>> >> >> >> >> encoding
>> >> >> >> >> to imply the rest.  Then:
>> >> >> >> >>
>> >> >> >> >> * (2) means that, when combining multiple input operands with 
>> >> >> >> >> potentially
>> >> >> >> >>   different encodings, we can set the number of patterns in the 
>> >> >> >> >> result
>> >> >> >> >>   to the least common multiple of the number of patterns in the 
>> >> >> >> >> inputs.
>> >> >> >> >>   In this case:
>> >> >> >> >>
>> >> >> >> >>   Pr = least_common_multiple(P1, P2, Ps)
>> >> >> >> >>
>> >> >> >> >>   is a valid number of patterns.
>> >> >> >> >>
>> >> >> >> >> * (3) means that the number of elements per pattern of the 
>> >> >> >> >> result can
>> >> >> >> >>   be the maximum of the number of elements per pattern in the 
>> >> >> >> >> inputs.
>> >> >> >> >>   (Alternatively, we could always 

Re: [PATCH] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]

[Segher Boessenkool]

On Fri, Sep 30, 2022 at 05:31:26PM +0200, Jakub Jelinek wrote:
> On Fri, Sep 30, 2022 at 10:07:59AM -0500, Segher Boessenkool wrote:
> > On Thu, Sep 29, 2022 at 12:01:43PM +0200, Jakub Jelinek via Gcc-patches 
> > wrote:
> > > --- gcc/config/i386/i386.cc.jj2022-09-29 09:13:25.713718513 +0200
> > > +++ gcc/config/i386/i386.cc   2022-09-29 11:29:20.828358152 +0200
> > > @@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type)
> > >&& TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != 
> > > REAL_TYPE)
> > >  return NULL;
> > >  
> > > +  if (type == float128_type_node || type == float64x_type_node)
> > > +return NULL;
> > 
> > Is float128_type_node always IEEE QP, never double-double?  I couldn't
> > find this documented anywhere.  If this is not true, this part of the
> > patch is incorrect.
> 
> It is always IEEE quad, if there is no IEEE quad support, it is NULL.
> The C++ wording is:
> 
> "If the implementation supports an extended floating-point type whose
> properties are specified by the ISO/IEC/IEEE 60559 floating-point
> interchange format binary128, then the typedef-name std::float128_t is
> defined in the header  and names such a type, the macro
> __STDCPP_FLOAT128_T__ is defined, and the floating-point literal suffixes
> f128 and F128 are supported."
> and C:
> Types designated:
> _FloatN
> where N is 16, 32, 64, or ≥128 and a multiple of 32; and, types designated
> _DecimalN
> where N ≥ 32 and a multiple of 32, are collectively called the interchange 
> floating types. Each
> interchange floating type has the IEC 60559 interchange format corresponding 
> to its width (N) and
> radix (2 for _FloatN, 10 for _DecimalN). Each interchange floating type is 
> not compatible with any
> other type."
> 
> So, _Float128 and std::float128_t which we use float128_type_node for
> must be IEEE binary128, nothing else.

Great :-)

> Internally, it is implemented by using targetm.floatn_mode hook to query
> which mode if any is the IEEE one with corresponding width.

tree.h says just
/* Names for individual types (code should normally iterate over all
   such types; these are only for back-end use, or in contexts such as
   *.def where iteration is not possible).  */
and there is nothing whatsoever in doc/.  Looking at the current
implementation never shows intent :-(


Segher

[PATCH] testsuite: Windows paths use \ and not /

[Torbjörn SVENSSON via Gcc-patches]

libstdc++-v3/testsuite:

* 20_util/bind/ref_neg.cc: Prune Windows paths too.

Co-Authored-By: Yvan ROUX  
Signed-off-by: Torbjörn SVENSSON  
---
 libstdc++-v3/testsuite/20_util/bind/ref_neg.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
index e779d2f20bd..1e9f3e7fece 100644
--- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
@@ -50,7 +50,7 @@ void test02()
 
 // Ignore the reasons for deduction/substitution failure in the headers.
 // Arrange for the match to work on installed trees as well as build trees.
-// { dg-prune-output "/(functional|bits/invoke.h):" }
+// { dg-prune-output "[/\\](functional|bits/invoke.h):" }
 
 int main()
 {
-- 
2.25.1

Re: [PATCH] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]

[Jakub Jelinek via Gcc-patches]

On Fri, Sep 30, 2022 at 10:07:59AM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Sep 29, 2022 at 12:01:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > --- gcc/config/i386/i386.cc.jj  2022-09-29 09:13:25.713718513 +0200
> > +++ gcc/config/i386/i386.cc 2022-09-29 11:29:20.828358152 +0200
> > @@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type)
> >&& TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
> >  return NULL;
> >  
> > +  if (type == float128_type_node || type == float64x_type_node)
> > +return NULL;
> 
> Is float128_type_node always IEEE QP, never double-double?  I couldn't
> find this documented anywhere.  If this is not true, this part of the
> patch is incorrect.

It is always IEEE quad, if there is no IEEE quad support, it is NULL.
The C++ wording is:

"If the implementation supports an extended floating-point type whose
properties are specified by the ISO/IEC/IEEE 60559 floating-point
interchange format binary128, then the typedef-name std::float128_t is
defined in the header  and names such a type, the macro
__STDCPP_FLOAT128_T__ is defined, and the floating-point literal suffixes
f128 and F128 are supported."
and C:
Types designated:
_FloatN
where N is 16, 32, 64, or ≥128 and a multiple of 32; and, types designated
_DecimalN
where N ≥ 32 and a multiple of 32, are collectively called the interchange 
floating types. Each
interchange floating type has the IEC 60559 interchange format corresponding to 
its width (N) and
radix (2 for _FloatN, 10 for _DecimalN). Each interchange floating type is not 
compatible with any
other type."

So, _Float128 and std::float128_t which we use float128_type_node for
must be IEEE binary128, nothing else.

Internally, it is implemented by using targetm.floatn_mode hook to query
which mode if any is the IEEE one with corresponding width.

Jakub

Re: [PATCH] arm: unified syntax for libgcc clear_cache

[Seija Kijin via Gcc-patches]

Yes, please!

On Tue, Sep 6, 2022 at 10:48 AM Kyrylo Tkachov  wrote:
>
> Hi Seija,
>
> > -Original Message-
> > From: Gcc-patches  > bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Seija Kijin via
> > Gcc-patches
> > Sent: Thursday, August 11, 2022 2:36 PM
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] arm: unified syntax for libgcc clear_cache
> >
> > The patch to convert all thumb1 code in libgcc to unified syntax
> > omitted changing all swi instructions to the current name: svc.
> >
> > This patch fixes this case.
>
> This is ok, thanks.
> Do you need someone to commit this for you?
>
> Kyrill
>
> >
> > ---
> >  libgcc/config/arm/lib1funcs.S | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S
> > index 8c39c9f20a2b..19fa1462ccf3 100644
> > --- a/libgcc/config/arm/lib1funcs.S
> > +++ b/libgcc/config/arm/lib1funcs.S
> > @@ -1522,7 +1522,7 @@ LSYM(Lover12):
> >   add r7, r7, #2
> >  #endif
> >   mov r2, #0
> > - swi 0
> > + svc 0
> >   do_pop {r7}
> >   RET
> >   FUNC_END clear_cache

Re: [V2 PATCH] RISC-V:Add '-m[no]-csr-check' option in gcc.

[Kito Cheng via Gcc-patches]

Committed, but I decided to take v1 and disable that by default to
prevent breaking the existing code :)

On Tue, Sep 13, 2022 at 5:37 PM jiawei  wrote:
>
> From: Jiawei 
>
> Add -m[no]-csr-check option in gcc part, when enable -mcsr-check option,
> it will add csr-check in .option section and pass this to assembler.
>
> V2: Add assembler support check info for -mcsr-check. Thanks for Kito's
> suggestions.
>
> gcc/ChangeLog:
>
> * config.in: New def.
> * config/riscv/riscv.cc (riscv_file_start): New .option.
> * config/riscv/riscv.opt: New options.
> * configure.ac: New check.
> * doc/invoke.texi: New def.
>
> ---
>  gcc/config.in  | 6 ++
>  gcc/config/riscv/riscv.cc  | 5 +
>  gcc/config/riscv/riscv.opt | 6 ++
>  gcc/configure.ac   | 5 +
>  gcc/doc/invoke.texi| 6 ++
>  5 files changed, 28 insertions(+)
>
> diff --git a/gcc/config.in b/gcc/config.in
> index 9c53319b544..a4c39e1384d 100644
> --- a/gcc/config.in
> +++ b/gcc/config.in
> @@ -616,6 +616,12 @@
>  #endif
>
>
> +/* Define if your assembler supports -mcsr-check. */
> +#ifndef USED_FOR_TARGET
> +#undef HAVE_AS_MCSR_CHECK
> +#endif
> +
> +
>  /* Define if your Mac OS X assembler supports -mllvm 
> -x86-pad-for-align=false.
> */
>  #ifndef USED_FOR_TARGET
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 675d92c0961..e98e6b1f561 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -5135,6 +5135,11 @@ riscv_file_start (void)
>if (! riscv_mrelax)
>  fprintf (asm_out_file, "\t.option norelax\n");
>
> +  /* If the user specifies "-mcsr-check" on the command line then enable csr
> + check in the assembler.  */
> +  if (riscv_mcsr_check)
> +fprintf (asm_out_file, "\t.option csr-check\n");
> +
>if (riscv_emit_attribute_p)
>  riscv_emit_attribute ();
>  }
> diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
> index fbca91b956c..3a12dd47310 100644
> --- a/gcc/config/riscv/riscv.opt
> +++ b/gcc/config/riscv/riscv.opt
> @@ -132,6 +132,12 @@ Target Bool Var(riscv_mrelax) Init(1)
>  Take advantage of linker relaxations to reduce the number of instructions
>  required to materialize symbol addresses.
>
> +mcsr-check
> +Target Bool Var(riscv_mcsr_check) Init(1)
> +Enable the CSR checking for the ISA-dependent CRS and the read-only CSR.
> +The ISA-dependent CSR are only valid when the specific ISA is set.  The
> +read-only CSR can not be written by the CSR instructions.
> +
>  Mask(64BIT)
>
>  Mask(MUL)
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 50bb61c1b61..1a9288ee659 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -5269,6 +5269,11 @@ configured with --enable-newlib-nano-formatted-io.])
>[-march=rv32i_zifencei2p0],,,
>[AC_DEFINE(HAVE_AS_MARCH_ZIFENCEI, 1,
>  [Define if the assembler understands -march=rv*_zifencei.])])
> +gcc_GAS_CHECK_FEATURE([-mcsr-check],
> +  gcc_cv_as_riscv_csr_check,
> +  [-mcsr-check],,,
> +  [AC_DEFINE(HAVE_AS_MCSR_CHECK, 1,
> +[Define if the assembler understands -mcsr-check.])])
>  ;;
>  loongarch*-*-*)
>  gcc_GAS_CHECK_FEATURE([.dtprelword support],
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index dd3302fcd15..7caade26b94 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -1224,6 +1224,7 @@ See RS/6000 and PowerPC Options.
>  -mbig-endian  -mlittle-endian @gol
>  -mstack-protector-guard=@var{guard}  -mstack-protector-guard-reg=@var{reg} 
> @gol
>  -mstack-protector-guard-offset=@var{offset}}
> +-mcsr-check -mno-csr-check @gol
>
>  @emph{RL78 Options}
>  @gccoptlist{-msim  -mmul=none  -mmul=g13  -mmul=g14  -mallregs @gol
> @@ -28551,6 +28552,11 @@ linker relaxations.
>  Emit (do not emit) RISC-V attribute to record extra information into ELF
>  objects.  This feature requires at least binutils 2.32.
>
> +@item -mcsr-check
> +@itemx -mno-csr-check
> +@opindex mcsr-check
> +Enables or disables the CSR checking.
> +
>  @item -malign-data=@var{type}
>  @opindex malign-data
>  Control how GCC aligns variables and constants of array, structure, or union
> --
> 2.34.1
>

Re: [PATCH RFC] c++: streamline process for adding new builtin trait

[Patrick Palka via Gcc-patches]

On Thu, 29 Sep 2022, Jason Merrill wrote:

> On 9/29/22 11:05, Patrick Palka wrote:
> > Adding a new builtin trait currently involves some boilerplate (as can
> > be seen in r13-2956-g9ca147154074a0) of defining corresponding RID_ and
> > CPTK_ enumerators and adding them to various switch statements across
> > many files.  The exact switch statements we need to change is determined
> > by whether the proposed trait yields a type or an expression.
> > 
> > This RFC patch attempts to streamline this process via a centralized
> > cp-trait.def file for declaring the important parts about a builtin trait
> > (whether it yields a type or an expression, its code, its spelling and
> > its arity) and using this file to automate away the switch statement
> > addition boilerplate.  It also converts 9 traits to use this approach
> > by way of example (we can convert all the traits once the design is
> > settled).
> > 
> > After this change, the process of adding a new builtin trait is just
> > (modulo tests): declare it in cp-trait.def, define its behavior in
> > finish_trait_type/expr, and handle it in diagnose_trait_expr if it's
> > an expression-yielding trait (this last step is unfortunate but since
> > the switch has no default case, we'll at least get a diagnostic if we
> > forget to do it).
> > 
> > Does this look like a good approach?
> 
> OK.

Thanks a lot, I committed the following (which migrates all the
C++-specific traits to the new approach):

-- >8 --

Subject: [PATCH] c++: streamline built-in trait addition process

Adding a new built-in trait currently involves manual boilerplate
consisting of defining an rid enumerator for the identifier as well as a
corresponding cp_trait_kind enumerator and handling them in various switch
statements, the exact set of which depends on whether the proposed trait
yields (and thus is recognized as) a type or an expression.

To streamline the process, this patch adds a central cp-trait.def file
that tabulates the essential details about each built-in trait (whether
it yields a type or an expression, its code, its spelling and its arity)
and uses this file to automate away the manual boilerplate.  It also
migrates all the existing C++-specific built-in traits to use this
approach.

After this change, adding a new built-in trait just entails declaring
it in cp-trait.def and defining its behavior in finish_trait_expr/type
(and handling it in diagnose_trait_expr, if it's an expression-yielding
trait).

gcc/c-family/ChangeLog:

* c-common.cc (c_common_reswords): Use cp/cp-trait.def to handle
C++ traits.
* c-common.h (enum rid): Likewise.

gcc/cp/ChangeLog:

* constraint.cc (diagnose_trait_expr): Likewise.
* cp-objcp-common.cc (names_builtin_p): Likewise.
* cp-tree.h (enum cp_trait_kind): Likewise.
* cxx-pretty-print.cc (pp_cxx_trait): Likewise.
* parser.cc (cp_keyword_starts_decl_specifier_p): Likewise.
(cp_parser_primary_expression): Likewise.
(cp_parser_trait): Likewise.
(cp_parser_simple_type_specifier): Likewise.
* cp-trait.def: New file.
---
 gcc/c-family/c-common.cc   |  54 ++---
 gcc/c-family/c-common.h|  33 ++
 gcc/cp/constraint.cc   |  12 +-
 gcc/cp/cp-objcp-common.cc  |  44 +---
 gcc/cp/cp-trait.def| 106 ++
 gcc/cp/cp-tree.h   |  46 +---
 gcc/cp/cxx-pretty-print.cc | 126 +
 gcc/cp/parser.cc   | 217 -
 8 files changed, 161 insertions(+), 477 deletions(-)
 create mode 100644 gcc/cp/cp-trait.def

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 6e0af863a49..3c60a89bfe2 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -378,7 +378,6 @@ const struct c_common_resword c_common_reswords[] =
   { "__attribute", RID_ATTRIBUTE,  0 },
   { "__attribute__",   RID_ATTRIBUTE,  0 },
   { "__auto_type", RID_AUTO_TYPE,  D_CONLY },
-  { "__bases",  RID_BASES, D_CXXONLY },
   { "__builtin_addressof", RID_ADDRESSOF, D_CXXONLY },
   { "__builtin_bit_cast", RID_BUILTIN_BIT_CAST, D_CXXONLY },
   { "__builtin_call_with_static_chain",
@@ -401,44 +400,12 @@ const struct c_common_resword c_common_reswords[] =
   { "__const__",   RID_CONST,  0 },
   { "__constinit", RID_CONSTINIT,  D_CXXONLY },
   { "__decltype",   RID_DECLTYPE,   D_CXXONLY },
-  { "__direct_bases",   RID_DIRECT_BASES, D_CXXONLY },
   { "__extension__",   RID_EXTENSION,  0 },
   { "__func__",RID_C99_FUNCTION_NAME, 0 },
-  { "__has_nothrow_assign", RID_HAS_NOTHROW_ASSIGN, D_CXXONLY },
-  { "__has_nothrow_constructor", RID_HAS_NOTHROW_CONSTRUCTOR, D_CXXONLY },
-  { "__has_nothrow_copy", RID_HAS_NOTHROW_COPY, D_CXXONLY },
-  { "__has_trivial_assign", RID_HAS_TRIVIAL_ASSIGN, D_CXXONLY },
-  { "__has_trivial_constructor", RID_HAS_TRIVIAL_CONSTRUCTOR, D_CXXONLY },
-  { "__has_trivial_copy", RID_HAS_TRIVIAL_COPY, D_CXXONLY },
-  

Re: [PATCH] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]

[Segher Boessenkool]

Hi!

On Thu, Sep 29, 2022 at 12:01:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> --- gcc/config/i386/i386.cc.jj2022-09-29 09:13:25.713718513 +0200
> +++ gcc/config/i386/i386.cc   2022-09-29 11:29:20.828358152 +0200
> @@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type)
>&& TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
>  return NULL;
>  
> +  if (type == float128_type_node || type == float64x_type_node)
> +return NULL;

Is float128_type_node always IEEE QP, never double-double?  I couldn't
find this documented anywhere.  If this is not true, this part of the
patch is incorrect.


Segher

Re: [PATCH v3 06/11] OpenMP: Pointers and member mappings

[Tobias Burnus]

On 30.09.22 15:30, Julian Brown wrote:
On Fri, 23 Sep 2022 14:10:51 +0200 Tobias Burnus 
 wrote:
...

I added n->expr->expr_type == EXPR_VARIABLE to the condition -- I think
that should suffice for now?

Yes.


A similar mean way to write code would be:

integer, target :: A(5)
integer, pointer :: p(:), p2(:)
type(t) :: var

allocate(p2(1:20))
p => A
var%p2 => p2
!$omp target map(A(3:4), p2(4:8), p, var%p2)
 
!$omp end target

which has a similar issue – it is not clear from the syntax whether
p's or var%p2's pointer target has been mapped or not.


Again, I don't think you're allowed to write that: that's "different
list items" sharing the same "original storage", IIUC. (It'd be nice to
diagnose it at compile time, but that's probably not that easy...)

Hmm, isn't that implied to be valid per:

"[Fortran] If a list item in a map clause is an associated pointer and the 
pointer
is not the base pointer of another list item in a map clause on the same
construct, then it is treated as if its pointer target is implicitly
mapped in the same clause."
(OpenMP 5.2, 5.8.3 map Clause [152:1-4]; seems to be identical to
OpenMP 5.1, 2.21.7.1 map Clause [349:9-12])

Admittedly, in 5.0 I only see the wording (OpenMP 5.0, [316:22-25]),
which is also not handled - but different:

"[Fortran] Each pointer component that is a list item that results from
a mapped derived type variable is treated as if its association status
is undefined, unless the pointer component appears as another list
item or as the base pointer of another list item in a map clause on
the same construct."

I think the that's for the following case (which is also covered by the
more general 5.1/5.2 wording):
type t

 integer, pointer :: p(:)
 integer, pointer :: p2(:)
end type t
type(t) :: var
integer, target :: tgt(5), tgt2(1000)
var%p => tgt
var%p => tgt2

!$omp target map(tgt, tgt2(4:6), var)
 var%p(1) = 5
 var%p2(5) = 7
!$omp end target

and I think GCC does not handled this, but I might be wrong.

Tobias


-
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 v3 06/11] OpenMP: Pointers and member mappings

[Tobias Burnus]

Hi Julian,

On 30.09.22 15:30, Julian Brown wrote:

  i = 1; j = 2
  map (foo(i)%dt_ptr(1:3), foo(j)%dt_ptr)


Good catch! In that gfc_dep_resolver considers those terms to have a
dependency, and that triggers the mapping node transformation. But I
don't think OpenMP allows you to write this: IIUC if "foo" is an array,
you're not allowed to separately map two parts of the array because of
(OpenMP 5.2, "5.8.3 map Clause"):

 "Two list items of the map clauses on the same construct must not
  share original storage unless they are the same list item or unless
  one is the containing structure of the other."


I was thinking of something like:

type t
 integer, pointer :: p(:)
end t
type(t2) :: var(2)
allocate (var(1)%p, source=[1,2,3,5])
allocate (var(2)%p, source=[2,3,5])

!$omp target map (  )
 var(1)%p(1) = 5
 var(2)%p(2) = 7
!$omp end target


Similarly for C:

struct st {
 int *p;
};
struct st s[2];
s[0].p = (int*)__malloc(sizeof(int)*5);
s[1].p = (int*)__malloc(sizeof(int)*3);

#pragma omp target map(  )
{
 s[0].p[0] = 5;
 s[1].p[1] = 7;
}


And now I somehow need to map "p" in both the C and the Fortran case.
And I believe that should be possible...
and my
  i = 1; j = 2
  map (var(i)%p(1:3), var(j)%p)
or
 map (s[0].p[:3], s[1].p[:7])

does not look to far fetched to get this result ...

Tobias


-
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: Extend fold_vec_perm to fold VEC_PERM_EXPR in VLA manner

[Prathamesh Kulkarni via Gcc-patches]

On Tue, 27 Sept 2022 at 01:59, Richard Sandiford
 wrote:
>
> Prathamesh Kulkarni  writes:
> > On Fri, 23 Sept 2022 at 21:33, Richard Sandiford
> >  wrote:
> >>
> >> Prathamesh Kulkarni  writes:
> >> > On Tue, 20 Sept 2022 at 18:09, Richard Sandiford
> >> >  wrote:
> >> >>
> >> >> Prathamesh Kulkarni  writes:
> >> >> > On Mon, 12 Sept 2022 at 19:57, Richard Sandiford
> >> >> >  wrote:
> >> >> >>
> >> >> >> Prathamesh Kulkarni  writes:
> >> >> >> >> The VLA encoding encodes the first N patterns explicitly.  The
> >> >> >> >> npatterns/nelts_per_pattern values then describe how to extend 
> >> >> >> >> that
> >> >> >> >> initial sequence to an arbitrary number of elements.  So when 
> >> >> >> >> performing
> >> >> >> >> an operation on (potentially) variable-length vectors, the 
> >> >> >> >> questions is:
> >> >> >> >>
> >> >> >> >> * Can we work out an initial sequence and 
> >> >> >> >> npatterns/nelts_per_pattern
> >> >> >> >>   pair that will be correct for all elements of the result?
> >> >> >> >>
> >> >> >> >> This depends on the operation that we're performing.  E.g. it's
> >> >> >> >> different for unary operations 
> >> >> >> >> (vector_builder::new_unary_operation)
> >> >> >> >> and binary operations (vector_builder::new_binary_operations).  
> >> >> >> >> It also
> >> >> >> >> varies between unary operations and between binary operations, 
> >> >> >> >> hence
> >> >> >> >> the allow_stepped_p parameters.
> >> >> >> >>
> >> >> >> >> For VEC_PERM_EXPR, I think the key requirement is that:
> >> >> >> >>
> >> >> >> >> (R) Each individual selector pattern must always select from the 
> >> >> >> >> same vector.
> >> >> >> >>
> >> >> >> >> Whether this condition is met depends both on the pattern itself 
> >> >> >> >> and on
> >> >> >> >> the number of patterns that it's combined with.
> >> >> >> >>
> >> >> >> >> E.g. suppose we had the selector pattern:
> >> >> >> >>
> >> >> >> >>   { 0, 1, 4, ... }   i.e. 3x - 2 for x > 0
> >> >> >> >>
> >> >> >> >> If the arguments and selector are n elements then this pattern on 
> >> >> >> >> its
> >> >> >> >> own would select from more than one argument if 3(n-1) - 2 >= n.
> >> >> >> >> This is clearly true for large enough n.  So if n is variable then
> >> >> >> >> we cannot represent this.
> >> >> >> >>
> >> >> >> >> If the pattern above is one of two patterns, so interleaved as:
> >> >> >> >>
> >> >> >> >>  { 0, _, 1, _, 4, _, ... }  o=0
> >> >> >> >>   or { _, 0, _, 1, _, 4, ... }  o=1
> >> >> >> >>
> >> >> >> >> then the pattern would select from more than one argument if
> >> >> >> >> 3(n/2-1) - 2 + o >= n.  This too would be a problem for variable 
> >> >> >> >> n.
> >> >> >> >>
> >> >> >> >> But if the pattern above is one of four patterns then it selects
> >> >> >> >> from more than one argument if 3(n/4-1) - 2 + o >= n.  This is not
> >> >> >> >> true for any valid n or o, so the pattern is OK.
> >> >> >> >>
> >> >> >> >> So let's define some ad hoc terminology:
> >> >> >> >>
> >> >> >> >> * Px is the number of patterns in x
> >> >> >> >> * Ex is the number of elements per pattern in x
> >> >> >> >>
> >> >> >> >> where x can be:
> >> >> >> >>
> >> >> >> >> * 1: first argument
> >> >> >> >> * 2: second argument
> >> >> >> >> * s: selector
> >> >> >> >> * r: result
> >> >> >> >>
> >> >> >> >> Then:
> >> >> >> >>
> >> >> >> >> (1) The number of elements encoded explicitly for x is Ex*Px
> >> >> >> >>
> >> >> >> >> (2) The explicit encoding can be used to produce a sequence of 
> >> >> >> >> N*Ex*Px
> >> >> >> >> elements for any integer N.  This extended sequence can be 
> >> >> >> >> reencoded
> >> >> >> >> as having N*Px patterns, with Ex staying the same.
> >> >> >> >>
> >> >> >> >> (3) If Ex < 3, Ex can be increased by 1 by repeating the final Px 
> >> >> >> >> elements
> >> >> >> >> of the explicit encoding.
> >> >> >> >>
> >> >> >> >> So let's assume (optimistically) that we can produce the result
> >> >> >> >> by calculating the first Pr*Er elements and using the Pr,Er 
> >> >> >> >> encoding
> >> >> >> >> to imply the rest.  Then:
> >> >> >> >>
> >> >> >> >> * (2) means that, when combining multiple input operands with 
> >> >> >> >> potentially
> >> >> >> >>   different encodings, we can set the number of patterns in the 
> >> >> >> >> result
> >> >> >> >>   to the least common multiple of the number of patterns in the 
> >> >> >> >> inputs.
> >> >> >> >>   In this case:
> >> >> >> >>
> >> >> >> >>   Pr = least_common_multiple(P1, P2, Ps)
> >> >> >> >>
> >> >> >> >>   is a valid number of patterns.
> >> >> >> >>
> >> >> >> >> * (3) means that the number of elements per pattern of the result 
> >> >> >> >> can
> >> >> >> >>   be the maximum of the number of elements per pattern in the 
> >> >> >> >> inputs.
> >> >> >> >>   (Alternatively, we could always use 3.)  In this case:
> >> >> >> >>
> >> >> >> >>   Er = max(E1, E2, Es)
> >> >> >> >>
> >> >> >> >>   is a valid number of elements per pattern.
> >> >> >> >>
> >> >> >> >> So if 

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

[Richard Biener via Gcc-patches]

> Am 30.09.2022 um 16:29 schrieb Richard Sandiford via Gcc-patches 
> :
> 
> Tamar Christina  writes:
>>> -Original Message-
>>> From: Richard Biener 
>>> Sent: Friday, September 30, 2022 12:53 PM
>>> To: Tamar Christina 
>>> Cc: Richard Sandiford ; Tamar Christina via
>>> Gcc-patches ; nd ; Jeff Law
>>> 
>>> Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
>>> branches, give hint if argument is a truth type to backend
>>> 
 On Fri, 30 Sep 2022, Tamar Christina wrote:
>>> 
> -Original Message-
> From: Richard Biener 
> Sent: Friday, September 30, 2022 11:17 AM
> To: Tamar Christina 
> Cc: Richard Sandiford ; Tamar Christina
> via Gcc-patches ; nd ; Jeff
>>> Law
> 
> Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> branches, give hint if argument is a truth type to backend
> 
> On Fri, 30 Sep 2022, Tamar Christina wrote:
> 
>> 
>> 
>>> -Original Message-
>>> From: Richard Sandiford 
>>> Sent: Friday, September 30, 2022 9:49 AM
>>> To: Tamar Christina 
>>> Cc: Richard Biener ; Tamar Christina via
>>> Gcc-patches ; nd ; Jeff
>>> Law
>>> 
>>> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
>>> conditional branches, give hint if argument is a truth type to
>>> backend
>>> 
>>> Tamar Christina  writes:
> -Original Message-
> From: Richard Sandiford 
> Sent: Friday, September 30, 2022 9:29 AM
> To: Tamar Christina 
> Cc: Richard Biener ; Tamar Christina via
> Gcc-patches ; nd ; Jeff
> Law
> 
> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> conditional branches, give hint if argument is a truth type
> to backend
> 
> Tamar Christina  writes:
>>> -Original Message-
>>> From: Gcc-patches >> bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of
>>> Richard
>>> Biener via Gcc-patches
>>> Sent: Thursday, September 29, 2022 12:09 PM
>>> To: Tamar Christina via Gcc-patches
>>> 
>>> Cc: Richard Sandiford ; nd
>>> 
>>> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
>>> conditional branches, give hint if argument is a truth
>>> type to backend
>>> 
>>> 
>>> 
 Am 29.09.2022 um 12:23 schrieb Tamar Christina via
 Gcc-patches
 >> patc...@gcc.gnu.org>:
 
 
> 
> -Original Message-
> From: Richard Biener 
> Sent: Thursday, September 29, 2022 10:41 AM
> To: Richard Sandiford 
> Cc: Jeff Law ; Tamar Christina
> ; gcc-patches@gcc.gnu.org; nd
>>> 
> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion
> of conditional branches, give hint if argument is a
> truth type to backend
> 
>> On Thu, 29 Sep 2022, Richard Sandiford wrote:
>> 
>> Jeff Law  writes:
>>> On 9/28/22 09:04, Richard Sandiford wrote:
 Tamar Christina  writes:
>> Maybe the target could use (subreg:SI (reg:BI
>> ...)) as
>>> argument.
>>> Heh.
> But then I'd still need to change the expansion
> code. I suppose this could prevent the issue with
> changes to code on
> other targets.
> 
 We have undocumented addcc, negcc, etc.
 patterns,
>>> should
> we
 have aandcc
> pattern for this indicating support for andcc +
> jump as opposedto
> cmpcc + jump?
>>> This could work yeah. I didn't know these existed.
>> Ah, so they are conditional add, not add setting
>> CC, so andcc wouldn't be appropriate.
>> So I'm not sure how we'd handle such situation -
>> maybe looking at REG_DECL and recognizing a _Bool
>> PARM_DECL is
>>> OK?
> I have a slight suspicion that Richard Sandiford
> would likely reject this though..
 Good guess :-P  We shouldn't rely on something like
 that for
> correctness.
 
 Would it help if we promoted the test-and-branch
 instructions to optabs, alongside cbranch?  The jump
 expanders could then target it
> directly.
 
 IMO that'd be a reasonable thing to do if it does help.
 It's a relatively common operation, especially on
 CISCy
> targets.
>>> 
>>> But don't we represent 

Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

[Richard Sandiford via Gcc-patches]

Tamar Christina  writes:
>> -Original Message-
>> From: Richard Biener 
>> Sent: Friday, September 30, 2022 12:53 PM
>> To: Tamar Christina 
>> Cc: Richard Sandiford ; Tamar Christina via
>> Gcc-patches ; nd ; Jeff Law
>> 
>> Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
>> branches, give hint if argument is a truth type to backend
>>
>> On Fri, 30 Sep 2022, Tamar Christina wrote:
>>
>> > > -Original Message-
>> > > From: Richard Biener 
>> > > Sent: Friday, September 30, 2022 11:17 AM
>> > > To: Tamar Christina 
>> > > Cc: Richard Sandiford ; Tamar Christina
>> > > via Gcc-patches ; nd ; Jeff
>> Law
>> > > 
>> > > Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
>> > > branches, give hint if argument is a truth type to backend
>> > >
>> > > On Fri, 30 Sep 2022, Tamar Christina wrote:
>> > >
>> > > >
>> > > >
>> > > > > -Original Message-
>> > > > > From: Richard Sandiford 
>> > > > > Sent: Friday, September 30, 2022 9:49 AM
>> > > > > To: Tamar Christina 
>> > > > > Cc: Richard Biener ; Tamar Christina via
>> > > > > Gcc-patches ; nd ; Jeff
>> Law
>> > > > > 
>> > > > > Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
>> > > > > conditional branches, give hint if argument is a truth type to
>> > > > > backend
>> > > > >
>> > > > > Tamar Christina  writes:
>> > > > > >> -Original Message-
>> > > > > >> From: Richard Sandiford 
>> > > > > >> Sent: Friday, September 30, 2022 9:29 AM
>> > > > > >> To: Tamar Christina 
>> > > > > >> Cc: Richard Biener ; Tamar Christina via
>> > > > > >> Gcc-patches ; nd ; Jeff
>> > > Law
>> > > > > >> 
>> > > > > >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
>> > > > > >> conditional branches, give hint if argument is a truth type
>> > > > > >> to backend
>> > > > > >>
>> > > > > >> Tamar Christina  writes:
>> > > > > >> >> -Original Message-
>> > > > > >> >> From: Gcc-patches > > > > > >> >> bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of
>> > > > > Richard
>> > > > > >> >> Biener via Gcc-patches
>> > > > > >> >> Sent: Thursday, September 29, 2022 12:09 PM
>> > > > > >> >> To: Tamar Christina via Gcc-patches
>> > > > > >> >> 
>> > > > > >> >> Cc: Richard Sandiford ; nd
>> > > > > 
>> > > > > >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
>> > > > > >> >> conditional branches, give hint if argument is a truth
>> > > > > >> >> type to backend
>> > > > > >> >>
>> > > > > >> >>
>> > > > > >> >>
>> > > > > >> >> > Am 29.09.2022 um 12:23 schrieb Tamar Christina via
>> > > > > >> >> > Gcc-patches
>> > > > > >> >> > > > > > > >> >> patc...@gcc.gnu.org>:
>> > > > > >> >> >
>> > > > > >> >> >
>> > > > > >> >> >>
>> > > > > >> >> >> -Original Message-
>> > > > > >> >> >> From: Richard Biener 
>> > > > > >> >> >> Sent: Thursday, September 29, 2022 10:41 AM
>> > > > > >> >> >> To: Richard Sandiford 
>> > > > > >> >> >> Cc: Jeff Law ; Tamar Christina
>> > > > > >> >> >> ; gcc-patches@gcc.gnu.org; nd
>> > > > > >> >> 
>> > > > > >> >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion
>> > > > > >> >> >> of conditional branches, give hint if argument is a
>> > > > > >> >> >> truth type to backend
>> > > > > >> >> >>
>> > > > > >> >> >>> On Thu, 29 Sep 2022, Richard Sandiford wrote:
>> > > > > >> >> >>>
>> > > > > >> >> >>> Jeff Law  writes:
>> > > > > >> >>  On 9/28/22 09:04, Richard Sandiford wrote:
>> > > > > >> >> > Tamar Christina  writes:
>> > > > > >> >> >>> Maybe the target could use (subreg:SI (reg:BI
>> > > > > >> >> >>> ...)) as
>> > > > > argument.
>> > > > > >> >> Heh.
>> > > > > >> >> >> But then I'd still need to change the expansion
>> > > > > >> >> >> code. I suppose this could prevent the issue with
>> > > > > >> >> >> changes to code on
>> > > > > >> other targets.
>> > > > > >> >> >>
>> > > > > >> >> > We have undocumented addcc, negcc, etc.
>> > > > > >> >> > patterns,
>> > > > > should
>> > > > > >> we
>> > > > > >> >> > have aandcc
>> > > > > >> >> >> pattern for this indicating support for andcc +
>> > > > > >> >> >> jump as opposedto
>> > > > > >> >> >> cmpcc + jump?
>> > > > > >> >>  This could work yeah. I didn't know these existed.
>> > > > > >> >> >>> Ah, so they are conditional add, not add setting
>> > > > > >> >> >>> CC, so andcc wouldn't be appropriate.
>> > > > > >> >> >>> So I'm not sure how we'd handle such situation -
>> > > > > >> >> >>> maybe looking at REG_DECL and recognizing a _Bool
>> > > > > >> >> >>> PARM_DECL is
>> > > > > OK?
>> > > > > >> >> >> I have a slight suspicion that Richard Sandiford
>> > > > > >> >> >> would likely reject this though..
>> > > > > >> >> > Good guess :-P  We shouldn't rely on something like
>> > > > > >> >> > that for
>> > > > > >> >> >> correctness.
>> > > > > >> >> >
>> > > > > >> >> > Would it help if we promoted the test-and-branch
>> > > > > >> >> > 

Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support

[Jakub Jelinek via Gcc-patches]

On Fri, Sep 30, 2022 at 09:49:08AM -0400, Jason Merrill wrote:
> The comment from Apple on the ABI mangling proposal suggests to me that we
> might want to delay enabling C++ std::bfloat16_t (i.e. defining
> __STDCPP_BFLOAT16_T__) until we have that excess precision support?

I saw that comment.  We have similar problem with _Float16 too, where C++
effectively right now works as when one uses -fexcess-precision=16 in C
(which isn't default).
I can see how hard would it be to add EXCESS_PRECISION_EXPR support to C++
FE.

> > * config/arm/arm.cc (TARGET_INVALID_UNARY_OP,
> > TARGET_INVALID_BINARY_OP): Don't redefine.
> > (arm_mangle_type): Mangle BFmode as DFb16_.
> 
> If we're using DF32x for _Float32x, maybe we want DF16b for bfloat16?

Perhaps, I just followed what was in the pull request.  Can change it.

Anyway, overnight testing found some missing CFLAGS-*.c += -msse2
lines in libgcc/config/i386/t-softfp and some i386 tests that were testing
the inability to cast or use __bf16 in expressions, so have adjusted that
too.
What isn't in the patch but I think we'll need to also change are some
minimal set of __builtin_*bf16 builtins.  Seems for _Float16, GCC provides
all the __builtin_*f16 (and for C/ObjC even with *f16 names), but there is
no glibc support for any of that, so builtins that are expanded by the
compiler are fine, but what should be fall back to libm won't work.
Maybe at least for now it is acceptable to implement most  and
 std::float16_t and std::bfloat16_t overloads with using
__builtin_*f and explicitly narrow down, but I think at least nextafter
(and apparently nexttoward as an alias for it for extended floating
point types) needs to be specific for the particular floating point format.
And, while e.g. most of bfloat16_t stuff in numeric_limits can be done
using say (__bf16) __builtin_nanf ("") and similar, at least for sNaN
I'm afraid there is no replacement, as it needs to be constexpr and so
we can't use union type punning to get signaling NaN value.  So we'll
need at least __builtin_nansbf16, maybe __builtin_huge_valbf16 and some
others for start.

2022-09-30  Jakub Jelinek  

gcc/
* tree-core.h (enum tree_index): Add TI_BFLOAT16_TYPE.
* tree.h (bfloat16_type_node): Define.
* tree.cc (excess_precision_type): Promote bfloat16_type_mode
like float16_type_mode.
* expmed.h (maybe_expand_shift): Declare.
* expmed.cc (maybe_expand_shift): No longer static.
* expr.cc (convert_mode_scalar): Don't ICE on BF -> HF or HF -> BF
conversions.  If there is no optab, handle BF -> {DF,XF,TF,HF}
conversions as separate BF -> SF -> {DF,XF,TF,HF} conversions, add
-ffast-math generic implementation for BF -> SF and SF -> BF
conversions.
* config/arm/arm.h (arm_bf16_type_node): Remove.
(arm_bf16_ptr_type_node): Adjust comment.
* config/arm/arm.cc (TARGET_INVALID_UNARY_OP,
TARGET_INVALID_BINARY_OP): Don't redefine.
(arm_mangle_type): Mangle BFmode as DFb16_.
(arm_invalid_conversion): Only reject BF <-> HF conversions if
HFmode is non-IEEE format.
(arm_invalid_unary_op, arm_invalid_binary_op): Remove.
* config/arm/arm-builtins.cc (arm_bf16_type_node): Remove.
(arm_simd_builtin_std_type): Use bfloat16_type_node rather than
arm_bf16_type_node.
(arm_init_simd_builtin_types): Likewise.
(arm_init_simd_builtin_scalar_types): Likewise.
(arm_init_bf16_types): Likewise.
* config/i386/i386.cc (ix86_mangle_type): Mangle BFmode as DFb16_.
(ix86_invalid_conversion, ix86_invalid_unary_op,
ix86_invalid_binary_op): Remove.
(TARGET_INVALID_CONVERSION, TARGET_INVALID_UNARY_OP,
TARGET_INVALID_BINARY_OP): Don't redefine.
* config/i386/i386-builtins.cc (ix86_bf16_type_node): Remove.
(ix86_register_bf16_builtin_type): Use bfloat16_type_node rather than
ix86_bf16_type_node.
* config/i386/i386-builtin-types.def (BFLOAT16): Likewise.
* config/aarch64/aarch64.h (aarch64_bf16_type_node): Remove.
(aarch64_bf16_ptr_type_node): Adjust comment.
* config/aarch64/aarch64.cc (aarch64_gimplify_va_arg_expr): Use
bfloat16_type_node rather than aarch64_bf16_type_node.
(aarch64_mangle_type): Mangle BFmode as DFb16_.
(aarch64_invalid_conversion, aarch64_invalid_unary_op): Remove.
aarch64_invalid_binary_op): Remove BFmode related rejections.
(TARGET_INVALID_CONVERSION, TARGET_INVALID_UNARY_OP): Don't redefine.
* config/aarch64/aarch64-builtins.cc (aarch64_bf16_type_node): Remove.
(aarch64_int_or_fp_type): Use bfloat16_type_node rather than
aarch64_bf16_type_node.
(aarch64_init_simd_builtin_types, aarch64_init_bf16_types): Likewise.
* config/aarch64/aarch64-sve-builtins.def (svbfloat16_t): Likewise.
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): If 

Re: [PATCH] i386, rs6000, ia64, s390: Fix C++ ICEs with _Float64x or _Float128 [PR107080]

[Jason Merrill via Gcc-patches]

On 9/29/22 06:01, Jakub Jelinek wrote:

Hi!

The following testcase ICEs on x86 as well as ppc64le (the latter
with -mabi=ieeelongdouble), because _Float64x there isn't mangled as
DF64x but e or u9__ieee128 instead.
Those are the mangling that should be used for the non-standard
types with the same mode or for long double, but not for _Float64x.
All the 4 mangle_type targhook implementations start with
type = TYPE_MAIN_VARIANT (type);
so I think it is cleanest to handle it the same in all and return NULL
before the switches on mode or whatever other tests.
s390 doesn't actually have a bug, but while I was there, having
type = TYPE_MAIN_VARIANT (type);
if (TYPE_MAIN_VARIANT (type) == long_double_type_node)
looked useless to me.

Tested on x86_64, i686 and powerpc64le, ok for trunk?


OK.


Note, there is one further problem on aarch64/arm, types with HFmode
(_Float16 and __fp16) are there mangled as Dh (which is standard
Itanium mangling:
  ::= Dh # IEEE 754r half-precision floating point (16 bits)
  ::= DF  _ # ISO/IEC TS 18661 binary floating point 
type _FloatN (N bits)
so in theory is also ok, but DF16_ is more specific.  Should we just
change Dh to DF16_ in those backends, or should __fp16 there be distinct
type from _Float16 where __fp16 would mangle Dh and _Float16 DF16_ ?


You argued for keeping __float128 separate from _Float128, does the same 
argument not apply to this case?



And there is csky, which mangles __fp16 (but only if type's name is __fp16,
not _Float16) as __fp16, that looks clearly invalid to me as it isn't
valid in the mangling grammar.  So perhaps just nuke csky's mangle_type
and have it mangled as DF16_ by the generic code?


Sounds good.


2022-09-29  Jakub Jelinek  

PR c++/107080
* config/i386/i386.cc (ix86_mangle_type): Always return NULL
for float128_type_node or float64x_type_node, don't check
float128t_type_node later on.
* config/ia64/ia64.cc (ia64_mangle_type): Always return NULL
for float128_type_node or float64x_type_node.
* config/rs6000/rs6000.cc (rs6000_mangle_type): Likewise.
Don't check float128_type_node later on.
* config/s390/s390.cc (s390_mangle_type): Don't use
TYPE_MAIN_VARIANT on type which was set to TYPE_MAIN_VARIANT
a few lines earlier.

* g++.dg/cpp23/ext-floating11.C: New test.

--- gcc/config/i386/i386.cc.jj  2022-09-29 09:13:25.713718513 +0200
+++ gcc/config/i386/i386.cc 2022-09-29 11:29:20.828358152 +0200
@@ -22725,6 +22725,9 @@ ix86_mangle_type (const_tree type)
&& TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
  return NULL;
  
+  if (type == float128_type_node || type == float64x_type_node)

+return NULL;
+
switch (TYPE_MODE (type))
  {
  case E_BFmode:
@@ -22735,10 +22738,7 @@ ix86_mangle_type (const_tree type)
return "DF16_";
  case E_TFmode:
/* __float128 is "g".  */
-  if (type == float128t_type_node)
-   return "g";
-  /* _Float128 should mangle as "DF128_" done in generic code.  */
-  return NULL;
+  return "g";
  case E_XFmode:
/* "long double" or __float80 is "e".  */
return "e";
--- gcc/config/ia64/ia64.cc.jj  2022-09-27 08:03:26.977984661 +0200
+++ gcc/config/ia64/ia64.cc 2022-09-29 11:29:44.071037677 +0200
@@ -11225,6 +11225,9 @@ ia64_mangle_type (const_tree type)
&& TREE_CODE (type) != INTEGER_TYPE && TREE_CODE (type) != REAL_TYPE)
  return NULL;
  
+  if (type == float128_type_node || type == float64x_type_node)

+return NULL;
+
/* On HP-UX, "long double" is mangled as "e" so __float128 is
   mangled as "e".  */
if (!TARGET_HPUX && TYPE_MODE (type) == TFmode)
--- gcc/config/rs6000/rs6000.cc.jj  2022-09-27 08:03:26.84363 +0200
+++ gcc/config/rs6000/rs6000.cc 2022-09-29 11:26:10.290985331 +0200
@@ -20270,13 +20270,12 @@ rs6000_mangle_type (const_tree type)
if (type == bool_int_type_node) return "U6__booli";
if (type == bool_long_long_type_node) return "U6__boolx";
  
+  if (type == float128_type_node || type == float64x_type_node)

+return NULL;
+
if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IBM_P (TYPE_MODE (type)))
  return "g";
-  if (SCALAR_FLOAT_TYPE_P (type)
-  && FLOAT128_IEEE_P (TYPE_MODE (type))
-  /* _Float128 should mangle as DF128_ (done in generic code)
-rather than u9__ieee128 (used for __ieee128 and __float128).  */
-  && type != float128_type_node)
+  if (SCALAR_FLOAT_TYPE_P (type) && FLOAT128_IEEE_P (TYPE_MODE (type)))
  return "u9__ieee128";
  
if (type == vector_pair_type_node)

--- gcc/config/s390/s390.cc.jj  2022-09-26 18:47:26.950349802 +0200
+++ gcc/config/s390/s390.cc 2022-09-29 11:26:51.180421534 +0200
@@ -7642,8 +7642,7 @@ s390_mangle_type (const_tree type)
if (type == s390_builtin_types[BT_BV4SI]) return "U6__booli";
if (type == s390_builtin_types[BT_BV2DI]) return 

Re: C++ ABI

[Nathan Sidwell via Gcc-patches]

On 9/30/22 09:43, Nathan Sidwell wrote:

Hi,
I've discovered some mangling problems with lambdas.  (a) divergence 
from clang and (b) manglings that incorrectly demangle.  With #a I'm not 
yet sure who is correct.  for #b g++ is definitely wrong.


 From the docs, it doesn't appear to have been bumped this cycle.  Is 
that correct, and I should bump it to 18?


oops, 'it' == -fabi-version

nathan

--
Nathan Sidwell

Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support

[Jason Merrill via Gcc-patches]

On 9/29/22 11:55, Jakub Jelinek wrote:

Hi!

Here is more complete patch to add std::bfloat16_t support on
x86, AArch64 and (only partially) on ARM 32-bit.  No BFmode optabs
are added by the patch, so for binops/unops it extends to SFmode
first and then truncates back to BFmode.
For {HF,SF,DF,XF,TF}mode -> BFmode conversions libgcc has implementations
of all those conversions so that we avoid double rounding, for
BFmode -> {DF,XF,TF}mode conversions to avoid growing libgcc too much
it emits BFmode -> SFmode conversion first and then converts to the even
wider mode, neither step should be imprecise.
For BFmode -> HFmode, it first emits a precise BFmode -> SFmode conversion
and then SFmode -> HFmode, because neither format is subset or superset
of the other, while SFmode is superset of both.
expr.cc then contains a -ffast-math optimization of the BF -> SF and
SF -> BF conversions if we don't optimize for space (and for the latter
if -frounding-math isn't enabled either).
For x86, perhaps truncsfbf2 optab could be defined for TARGET_AVX512BF16
but IMNSHO should FAIL if !flag_finite_math || flag_rounding_math
|| !flag_unsafe_math_optimizations, because I think the insn doesn't
raise on sNaNs, hardcodes round to nearest and flushes denormals to zero.
In C by default (unless x86 -fexcess-precision=16) we use float excess
precision for BFmode, so truncate only on explicit casts and assignments.
In C++ unfortunately (but that is the case of also _Float16) we don't
support excess precision yet which means that for
__bf16 (__bf16 a, __bf16 b, __bf16 c, __bf16 d) { return a * b + c * d; }
we do a lot of conversions.


The comment from Apple on the ABI mangling proposal suggests to me that 
we might want to delay enabling C++ std::bfloat16_t (i.e. defining 
__STDCPP_BFLOAT16_T__) until we have that excess precision support?


"Steve [Cannon] is concerned that adding this type as an arithmetic type 
might serve to be an attractive nuisance. Because the precision of 
bfloat16 is so limited, controlling when truncation back to bfloat16 
occurs is of paramount practical importance to bfloat16 users. The 
normal semantics of an arithmetic type in C and C++ encourage the 
independent evaluation of operations, which would require an implicit 
truncation back to bfloat16 on every intermediate result. That would 
have catastrophic effects on both the precision and the performance of 
typical bfloat16 code. For example, on the performance side, typical 
hardware support is built around complex fused operations (e.g. float32 
+= bfloat16 * bfloat16 + bfloat16 * bfloat16, with all intermediate 
results computed in float32) that it would not be correct to 
pattern-match from independent operations.


Now, C and C++ do allow excess precision evaluation (C 6.5p8; C++ 
[expr.pre]p6), and Steve and I think that that might fix this problem. 
But we'd really need to force excess precision evaluation in order to 
get acceptable results; otherwise, allowing arithmetic is really just 
encouraging people to write code that is effectively incorrect. And even 
then there's definitely risk that someone might e.g. accumulate the 
intermediate results of a loop in std::bfloat16_t instead of in float."



The aarch64 part is untested but has a chance of working (IMHO),
though I'd appreciate if ARM maintainers could decide whether it is
acceptable for them that __bf16 changes mangling and will allow arithmetics
and conversions.
The arm part is partial, libgcc side is missing as the target doesn't really
seem to use soft-fp right now.  Perhaps the config/arm/ changes can be
left out from the patch (thus keep ARM 32-bit __bf16 as before) and support
for it can be done at some later time.

Thoughts on this?

2022-09-29  Jakub Jelinek  

gcc/
* tree-core.h (enum tree_index): Add TI_BFLOAT16_TYPE.
* tree.h (bfloat16_type_node): Define.
* tree.cc (excess_precision_type): Promote bfloat16_type_mode
like float16_type_mode.
* expmed.h (maybe_expand_shift): Declare.
* expmed.cc (maybe_expand_shift): No longer static.
* expr.cc (convert_mode_scalar): Don't ICE on BF -> HF or HF -> BF
conversions.  If there is no optab, handle BF -> {DF,XF,TF,HF}
conversions as separate BF -> SF -> {DF,XF,TF,HF} conversions, add
-ffast-math generic implementation for BF -> SF and SF -> BF
conversions.
* config/arm/arm.h (arm_bf16_type_node): Remove.
(arm_bf16_ptr_type_node): Adjust comment.
* config/arm/arm.cc (TARGET_INVALID_UNARY_OP,
TARGET_INVALID_BINARY_OP): Don't redefine.
(arm_mangle_type): Mangle BFmode as DFb16_.


If we're using DF32x for _Float32x, maybe we want DF16b for bfloat16?


(arm_invalid_conversion): Only reject BF <-> HF conversions if
HFmode is non-IEEE format.
(arm_invalid_unary_op, arm_invalid_binary_op): Remove.
* config/arm/arm-builtins.cc (arm_bf16_type_node): Remove.

[committed] libstdc++: Add missing include to

[Jonathan Wakely via Gcc-patches]

From: Arsen Arsenović 

Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/std/bitset: Include .
---
 libstdc++-v3/include/std/bitset | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libstdc++-v3/include/std/bitset b/libstdc++-v3/include/std/bitset
index 1a551cf9785..3fe8b18735c 100644
--- a/libstdc++-v3/include/std/bitset
+++ b/libstdc++-v3/include/std/bitset
@@ -46,6 +46,8 @@
 
 #include// For invalid_argument, out_of_range,
 // overflow_error
+#include   // For std::fill
+
 #if _GLIBCXX_HOSTED
 # include 
 # include 
-- 
2.37.3

C++ ABI

[Nathan Sidwell via Gcc-patches]

Hi,
I've discovered some mangling problems with lambdas.  (a) divergence 
from clang and (b) manglings that incorrectly demangle.  With #a I'm not 
yet sure who is correct.  for #b g++ is definitely wrong.


From the docs, it doesn't appear to have been bumped this cycle.  Is 
that correct, and I should bump it to 18?


nathan
--
Nathan Sidwell

Re: [PATCH v3 06/11] OpenMP: Pointers and member mappings

[Julian Brown]

On Fri, 23 Sep 2022 14:10:51 +0200
Tobias Burnus  wrote:

> Hi Julian and Jakub, hi all,
> 
> On 23.09.22 09:29, Julian Brown wrote:
> > How about this version? (Re-tested.)  
> 
> Some more generic (pre)remarks – not affecting the patch code,
> but possibly the commit log message:
> 
> > This follows OMP 5.0, 2.19.7.1 "map Clause":  
> 
> which is also in "OMP 5.2, 5.8.3 map Clause [152:1-4]". It might
> make sense to add this ref in addition (or instead):
> 
> >"If a list item in a map clause is an associated pointer and the
> > pointer is not the base pointer of another list item in a map
> > clause on the same construct, then it is treated as if its pointer
> > target is implicitly mapped in the same clause. For the purposes of
> > the map clause, the mapped pointer target is treated as if its base
> > pointer is the associated pointer."  

I've changed the wording in the commit log text...

> Thus, the following restriction was proposed for OpenMP 6.0 (TR11):
> 
> "The association status of a list item that is a pointer must not be
>   undefined unless it is a structure component and it results from a
>   predefined default mapper."
> 
> which makes my example invalid. (Add some caveat here about TR11 not
> yet being released and also TRs being not final named-version
> releases.)

(But not this bit, for now.)

> > and then instead we should follow:
> >
> >"If the structure sibling list item is a pointer then it is
> > treated as if its association status is undefined, unless it
> > appears as the base pointer of another list item in a map clause on
> > the same construct."  
> 
> 
> This wording disappeared in 5.1 due to some cleanup (cf. Issue 2152,
> which has multiple changes; this one is Pull Req. 2379).
> 
> I think the matching current / OpenMP 5.2 wording (5.8.3 map Clause
> [152:5-8, 11-13 (,14-16)]) is
> 
> "For map clauses on map-entering constructs, if any list item has a
> base pointer for which a corresponding pointer exists in the data
> environment upon entry to the region and either a new list item or
> the corresponding pointer is created in the device data environment
> on entry to the region, then: (Fortran)
> 1. The corresponding pointer variable is associated with a pointer
> target that has the same rank and bounds as the pointer target of the
> original pointer, such that the corresponding list item can be
> accessed through the pointer in a target region. ..."
> 
> I think here 'a new list item ... is created ... on entry' applies.
> However, this should not affect what you wrote later on.

I changed the text here too.

> > But, that's not implemented quite right at the moment [...]
> > The solution is to detect when we're mapping a smaller part of the
> > array (or a subcomponent) on the same directive, and only map the
> > descriptor in that case. So we get mappings like this instead:
> >
> >map(to: tvar%arrptr)   -->
> >GOMP_MAP_ALLOC  tvar%arrptr  (the descriptor)
> >
> >map(tofrom: tvar%arrptr(3:8)   -->
> >GOMP_MAP_TOFROM tvar%arrptr%data(3) (size 8-3+1, etc.)
> >GOMP_MAP_ALWAYS_POINTER tvar%arrptr%data (bias 3, etc.)  
> 
> (I concur.)

Thank you!

> > --- a/gcc/fortran/trans-openmp.cc
> > +++ b/gcc/fortran/trans-openmp.cc
> > ...
> > @@ -2470,22 +2471,18 @@ gfc_trans_omp_array_section (stmtblock_t
> > *block, gfc_omp_namelist *n, }
> > if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (decl)))
> >   {
> > ...
> > +  if (ptr_kind != GOMP_MAP_ALWAYS_POINTER)
> > {
> > ...
> > + /* For OpenMP, the descriptor must be mapped with its
> > own explicit
> > +map clause (e.g. both "map(foo%arr)" and
> > "map(foo%arr(:))" must
> > +be present in the clause list if "foo%arr" is a
> > pointer to an
> > +array).  So, we don't create a GOMP_MAP_TO_PSET node
> > here.  */
> > + node2 = build_omp_clause (input_location,
> > OMP_CLAUSE_MAP);
> > + OMP_CLAUSE_SET_MAP_KIND (node2, GOMP_MAP_TO_PSET);  
> 
> I found the last sentence of the comment and the set_map_kind
> confusing: The comment says no MAP_TO_PSET and the SET_MAP_KIND use
> it.
> 
> I wonder whether that should be something like 'if (openacc)' instead,
> which kind of matches the first way gfc_trans_omp_array_section is
> called:

I agree it was confusing -- I've tweaked the wording of the comment.
The condition changes in the "address tokenization" follow-up patch
anyway.

> inner, element, kind, node, node2, node3,
> node4);
> However, there is also a second call to it:
> 
>/* An array element or array section which is not
> part of a derived type, etc.  */
> ...
>gomp_map_kind k = GOMP_MAP_POINTER;
> ...
>gfc_trans_omp_array_section (block, n, decl,
> element, k, node, node2, node3, node4);

> And without following all 'if' conditions through, I don't see why
> that should be handled differently.

GOMP_MAP_POINTER is used for non-component 

Re: [PATCH] c-family: ICE with [[gnu::nocf_check]] [PR106937]

[Jason Merrill via Gcc-patches]

On 9/29/22 18:49, Marek Polacek wrote:

When getting the name of an attribute, we ought to use
get_attribute_name, which handles both [[ ]] and __attribute__(())
forms.  Failure to do so may result in an ICE, like here.

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


How do we print the attributes with this patch?  Don't we also want to 
print the namespace, and use [[]] in the output?



PR c++/106937

gcc/c-family/ChangeLog:

* c-pretty-print.cc (pp_c_attributes): Use get_attribute_name.
(pp_c_attributes_display): Likewise.

gcc/testsuite/ChangeLog:

* gcc.dg/fcf-protection-1.c: New test.
---
  gcc/c-family/c-pretty-print.cc  |  8 
  gcc/testsuite/gcc.dg/fcf-protection-1.c | 13 +
  2 files changed, 17 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/gcc.dg/fcf-protection-1.c

diff --git a/gcc/c-family/c-pretty-print.cc b/gcc/c-family/c-pretty-print.cc
index efa1768f4d6..91f88b830e3 100644
--- a/gcc/c-family/c-pretty-print.cc
+++ b/gcc/c-family/c-pretty-print.cc
@@ -863,7 +863,7 @@ pp_c_attributes (c_pretty_printer *pp, tree attributes)
pp_c_left_paren (pp);
for (; attributes != NULL_TREE; attributes = TREE_CHAIN (attributes))
  {
-  pp_tree_identifier (pp, TREE_PURPOSE (attributes));
+  pp_tree_identifier (pp, get_attribute_name (attributes));
if (TREE_VALUE (attributes))
pp_c_call_argument_list (pp, TREE_VALUE (attributes));
  
@@ -875,7 +875,7 @@ pp_c_attributes (c_pretty_printer *pp, tree attributes)

  }
  
  /* Pretty-print ATTRIBUTES using GNU C extension syntax for attributes

-   marked to be displayed on disgnostic.  */
+   marked to be displayed on diagnostic.  */
  
  void

  pp_c_attributes_display (c_pretty_printer *pp, tree a)
@@ -888,7 +888,7 @@ pp_c_attributes_display (c_pretty_printer *pp, tree a)
for (; a != NULL_TREE; a = TREE_CHAIN (a))
  {
const struct attribute_spec *as;
-  as = lookup_attribute_spec (TREE_PURPOSE (a));
+  as = lookup_attribute_spec (get_attribute_name (a));
if (!as || as->affects_type_identity == false)
  continue;
if (c_dialect_cxx ()
@@ -906,7 +906,7 @@ pp_c_attributes_display (c_pretty_printer *pp, tree a)
 {
   pp_separate_with (pp, ',');
 }
-  pp_tree_identifier (pp, TREE_PURPOSE (a));
+  pp_tree_identifier (pp, get_attribute_name (a));
if (TREE_VALUE (a))
 pp_c_call_argument_list (pp, TREE_VALUE (a));
  }
diff --git a/gcc/testsuite/gcc.dg/fcf-protection-1.c 
b/gcc/testsuite/gcc.dg/fcf-protection-1.c
new file mode 100644
index 000..9d06feadfd1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fcf-protection-1.c
@@ -0,0 +1,13 @@
+/* PR c++/106937 */
+/* { dg-options "-fcf-protection -w" } */
+
+[[gnu::nocf_check]] typedef void (*FuncPointerWithNoCfCheck)(void);
+typedef void (*FuncPointer)(void);
+[[gnu::nocf_check]] void testNoCfCheck();
+void testNoCfCheck(){};
+int [[gnu::nocf_check]] i;
+void testNoCfCheckImpl(double i [[gnu::nocf_check]]) {}
+void testNoCfCheckMismatch(FuncPointer f) {
+  FuncPointerWithNoCfCheck fNoCfCheck = f;
+  (*fNoCfCheck)();
+}

base-commit: c2ee70f20de8133a88553270073226b0f3f55f62

RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Richard Biener 
> Sent: Friday, September 30, 2022 12:53 PM
> To: Tamar Christina 
> Cc: Richard Sandiford ; Tamar Christina via
> Gcc-patches ; nd ; Jeff Law
> 
> Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> branches, give hint if argument is a truth type to backend
> 
> On Fri, 30 Sep 2022, Tamar Christina wrote:
> 
> > > -Original Message-
> > > From: Richard Biener 
> > > Sent: Friday, September 30, 2022 11:17 AM
> > > To: Tamar Christina 
> > > Cc: Richard Sandiford ; Tamar Christina
> > > via Gcc-patches ; nd ; Jeff
> Law
> > > 
> > > Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> > > branches, give hint if argument is a truth type to backend
> > >
> > > On Fri, 30 Sep 2022, Tamar Christina wrote:
> > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Richard Sandiford 
> > > > > Sent: Friday, September 30, 2022 9:49 AM
> > > > > To: Tamar Christina 
> > > > > Cc: Richard Biener ; Tamar Christina via
> > > > > Gcc-patches ; nd ; Jeff
> Law
> > > > > 
> > > > > Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> > > > > conditional branches, give hint if argument is a truth type to
> > > > > backend
> > > > >
> > > > > Tamar Christina  writes:
> > > > > >> -Original Message-
> > > > > >> From: Richard Sandiford 
> > > > > >> Sent: Friday, September 30, 2022 9:29 AM
> > > > > >> To: Tamar Christina 
> > > > > >> Cc: Richard Biener ; Tamar Christina via
> > > > > >> Gcc-patches ; nd ; Jeff
> > > Law
> > > > > >> 
> > > > > >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> > > > > >> conditional branches, give hint if argument is a truth type
> > > > > >> to backend
> > > > > >>
> > > > > >> Tamar Christina  writes:
> > > > > >> >> -Original Message-
> > > > > >> >> From: Gcc-patches  > > > > >> >> bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of
> > > > > Richard
> > > > > >> >> Biener via Gcc-patches
> > > > > >> >> Sent: Thursday, September 29, 2022 12:09 PM
> > > > > >> >> To: Tamar Christina via Gcc-patches
> > > > > >> >> 
> > > > > >> >> Cc: Richard Sandiford ; nd
> > > > > 
> > > > > >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> > > > > >> >> conditional branches, give hint if argument is a truth
> > > > > >> >> type to backend
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> > Am 29.09.2022 um 12:23 schrieb Tamar Christina via
> > > > > >> >> > Gcc-patches
> > > > > >> >> >  > > > > >> >> patc...@gcc.gnu.org>:
> > > > > >> >> >
> > > > > >> >> >
> > > > > >> >> >>
> > > > > >> >> >> -Original Message-
> > > > > >> >> >> From: Richard Biener 
> > > > > >> >> >> Sent: Thursday, September 29, 2022 10:41 AM
> > > > > >> >> >> To: Richard Sandiford 
> > > > > >> >> >> Cc: Jeff Law ; Tamar Christina
> > > > > >> >> >> ; gcc-patches@gcc.gnu.org; nd
> > > > > >> >> 
> > > > > >> >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion
> > > > > >> >> >> of conditional branches, give hint if argument is a
> > > > > >> >> >> truth type to backend
> > > > > >> >> >>
> > > > > >> >> >>> On Thu, 29 Sep 2022, Richard Sandiford wrote:
> > > > > >> >> >>>
> > > > > >> >> >>> Jeff Law  writes:
> > > > > >> >>  On 9/28/22 09:04, Richard Sandiford wrote:
> > > > > >> >> > Tamar Christina  writes:
> > > > > >> >> >>> Maybe the target could use (subreg:SI (reg:BI
> > > > > >> >> >>> ...)) as
> > > > > argument.
> > > > > >> >> Heh.
> > > > > >> >> >> But then I'd still need to change the expansion
> > > > > >> >> >> code. I suppose this could prevent the issue with
> > > > > >> >> >> changes to code on
> > > > > >> other targets.
> > > > > >> >> >>
> > > > > >> >> > We have undocumented addcc, negcc, etc.
> > > > > >> >> > patterns,
> > > > > should
> > > > > >> we
> > > > > >> >> > have aandcc
> > > > > >> >> >> pattern for this indicating support for andcc +
> > > > > >> >> >> jump as opposedto
> > > > > >> >> >> cmpcc + jump?
> > > > > >> >>  This could work yeah. I didn't know these existed.
> > > > > >> >> >>> Ah, so they are conditional add, not add setting
> > > > > >> >> >>> CC, so andcc wouldn't be appropriate.
> > > > > >> >> >>> So I'm not sure how we'd handle such situation -
> > > > > >> >> >>> maybe looking at REG_DECL and recognizing a _Bool
> > > > > >> >> >>> PARM_DECL is
> > > > > OK?
> > > > > >> >> >> I have a slight suspicion that Richard Sandiford
> > > > > >> >> >> would likely reject this though..
> > > > > >> >> > Good guess :-P  We shouldn't rely on something like
> > > > > >> >> > that for
> > > > > >> >> >> correctness.
> > > > > >> >> >
> > > > > >> >> > Would it help if we promoted the test-and-branch
> > > > > >> >> > instructions to optabs, alongside cbranch?  The jump
> > > > > >> >> > expanders could then target it
> > > > > >> >> >> directly.
> > > > > >> >> 

Re: [PATCH] Adjust the symbol for SECTION_LINK_ORDER linked_to section [PR99889]

[Kewen.Lin via Gcc-patches]

Hi Segher,

on 2022/9/30 04:31, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Aug 24, 2022 at 04:17:07PM +0800, Kewen.Lin wrote:
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -14771,18 +14771,9 @@ rs6000_print_patchable_function_entry (FILE *file,
>> unsigned HOST_WIDE_INT patch_area_size,
>> bool record_p)
>>  {
>> -  unsigned int flags = SECTION_WRITE | SECTION_RELRO;
>> -  /* When .opd section is emitted, the function symbol
>> - default_print_patchable_function_entry_1 is emitted into the .opd 
>> section
>> - while the patchable area is emitted into the function section.
>> - Don't use SECTION_LINK_ORDER in that case.  */
>> -  if (!(TARGET_64BIT && DEFAULT_ABI != ABI_ELFv2)
>> -  && HAVE_GAS_SECTION_LINK_ORDER)
>> -flags |= SECTION_LINK_ORDER;
>> -  default_print_patchable_function_entry_1 (file, patch_area_size, record_p,
>> -flags);
>> +  default_print_patchable_function_entry (file, patch_area_size, record_p);
>>  }
> 
> Please don't define TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY at all,
> instead, and remove this whole function?

This hook is still needed for "ELFv2 support rework" which
was just committed in r13-2984.  There is also a note
explaining this in the original mail: 

"btw, rs6000_print_patchable_function_entry can be dropped
but there is another rs6000 patch which needs this rs6000
specific hook rs6000_print_patchable_function_entry, not
sure which one gets landed first, so just leave it here."

> 
> The rs6000 changes are okay like that, thanks!

Thanks!

BR,
Kewen

Re: [PATCH v4] rs6000: Rework ELFv2 support for -fpatchable-function-entry* [PR99888]

[Kewen.Lin via Gcc-patches]

Hi Segher,

Thanks for the review comments!

on 2022/9/28 23:22, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Aug 25, 2022 at 01:50:28PM +0800, Kewen.Lin wrote:
>> --- a/gcc/config/rs6000/rs6000-internal.h
>> +++ b/gcc/config/rs6000/rs6000-internal.h
>> @@ -183,10 +183,15 @@ extern tree rs6000_fold_builtin (tree fndecl 
>> ATTRIBUTE_UNUSED,
>>   tree *args ATTRIBUTE_UNUSED,
>>   bool ignore ATTRIBUTE_UNUSED);
>>
>> +extern void rs6000_print_patchable_function_entry (FILE *,
>> +   unsigned HOST_WIDE_INT,
>> +   bool);
>> +
>>  extern bool rs6000_passes_float;
>>  extern bool rs6000_passes_long_double;
>>  extern bool rs6000_passes_vector;
>>  extern bool rs6000_returns_struct;
>>  extern bool cpu_builtin_p;
>>
>> +
>>  #endif
> 
> No new random empty lines please.
> 
>> + point would be 2, 6 and 14.  It's possible to support those
>> + other counts of nops by not making a local entry point, but
>> + we don't have clear user cases for them, so leave them
> 
> "use cases"
> 
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -16717,9 +16717,13 @@ the area size or to remove it completely on a 
>> single function.
>>  If @code{N=0}, no pad location is recorded.
>>
>>  The NOP instructions are inserted at---and maybe before, depending on
>> -@var{M}---the function entry address, even before the prologue.
>> +@var{M}---the function entry address, even before the prologue.  On
>> +PowerPC with the ELFv2 ABI, for one function with dual entry points,
>> +the local entry point is taken as the function entry for generation.
> 
> I think "the local entry point is this function entry address" is a bit
> clearer.
> 
>> -The maximum value of @var{N} and @var{M} is 65535.
>> +The maximum value of @var{N} and @var{M} is 65535.  On PowerPC with the
>> +ELFv2 ABI, for one function with dual entry points, the supported values
>> +for @var{M} are 0, 2, 6 and 14.
> 
> "for a function"
> 
> Okay for trunk with those trivial chnges.  Thanks!
> 

Updated as all above comments, re-tested and committed in r13-2984.  Thanks!


BR,
Kewen

Re: [PATCH] Emit discriminators for inlined call sites.

[Richard Biener via Gcc-patches]

On Fri, Sep 30, 2022 at 8:28 AM Eugene Rozenfeld via Gcc-patches
 wrote:
>
> This change is based on commit 9fa26998a63d4b22b637ed8702520819e408a694
> by Dehao Chen in vendors/google/heads/gcc-4_8.

OK

> gcc/ChangeLog:
>
> * dwarf2out.cc (add_call_src_coords_attributes): Emit discriminators 
> for inlined call sites.
> ---
>  gcc/dwarf2out.cc | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
> index 2df75904022..e81044b8c48 100644
> --- a/gcc/dwarf2out.cc
> +++ b/gcc/dwarf2out.cc
> @@ -24783,7 +24783,8 @@ add_call_src_coords_attributes (tree stmt, dw_die_ref 
> die)
>if (RESERVED_LOCATION_P (BLOCK_SOURCE_LOCATION (stmt)))
>  return;
>
> -  expanded_location s = expand_location (BLOCK_SOURCE_LOCATION (stmt));
> +  location_t locus = BLOCK_SOURCE_LOCATION (stmt);
> +  expanded_location s = expand_location (locus);
>
>if (dwarf_version >= 3 || !dwarf_strict)
>  {
> @@ -24791,6 +24792,9 @@ add_call_src_coords_attributes (tree stmt, dw_die_ref 
> die)
>add_AT_unsigned (die, DW_AT_call_line, s.line);
>if (debug_column_info && s.column)
> add_AT_unsigned (die, DW_AT_call_column, s.column);
> +  unsigned discr = get_discriminator_from_loc (locus);
> +   if (discr != 0)
> + add_AT_unsigned (die, DW_AT_GNU_discriminator, discr);
>  }
>  }
>
> --
> 2.25.1

Re: [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]

[Kewen.Lin via Gcc-patches]

Hi Segher!

on 2022/9/28 22:55, Segher Boessenkool wrote:
> Hi!
> 
> On Wed, Aug 24, 2022 at 04:17:55PM +0800, Kewen.Lin wrote:
>> As PR106516 shows, we can get unexpected gimple outputs for
>> function thud on some target which supports modulus operation
>> for vector int.  This patch introduces one effective target
>> vect_int_mod for it, then adjusts the test case with it.
> 
>> +# Return 1 if the target supports vector int modulus, 0 otherwise.
>> +
>> +proc check_effective_target_vect_int_mod { } {
>> +return [check_cached_effective_target_indexed vect_int_mod {
>> +  expr { [istarget powerpc*-*-*]
>> + && [check_effective_target_power10_ok] }}]
>> +}
> 
> power10_ok does not mean the vmod[su][wdq] instructions will be
> generated.  You need to test if we have -mcpu=power10 or such, so,
> check_effective_target_has_arch_pwr10 .

Indeed, the context is different from those cases in gcc.target/powerpc
which have -mdejagnu-cpu=power10 normally.  Thanks for catching and 
the correction!

> 
> _ok tests if it is okay to enable .  _hw tests if the hardware
> can do .  has_arch_ tests if the compiler is asked to generate
> code for  (which is reflected in the _ARCH_* preprocessor symbols,
> hence the name).
> 
> Okay for trunk with the correct check_effective_target_* .  Thanks!
> 

Thanks, re-tested as before, committed in r13-2983.

BR,
Kewen

Re: [PATCH] rs6000: Rework option -mpowerpc64 handling [PR106680]

[Kewen.Lin via Gcc-patches]

on 2022/9/30 01:11, Segher Boessenkool wrote:
> On Thu, Sep 29, 2022 at 01:45:16PM +0800, Kewen.Lin wrote:
>> I found this flag is mainly related to tune setting and spotted that we have 
>> some code
>> for tune setting when no explicit cpu is given. 
>>
>> ...
>>
>>   else
>> {
>>   size_t i;
>>   enum processor_type tune_proc
>>  = (TARGET_POWERPC64 ? PROCESSOR_DEFAULT64 : PROCESSOR_DEFAULT);
>>
>>   tune_index = -1;
>>   for (i = 0; i < ARRAY_SIZE (processor_target_table); i++)
>>  if (processor_target_table[i].processor == tune_proc)
>>{
>>  tune_index = i;
>>  break;
>>}
>> }
> 
> Ah cool, that needs fixing yes.
> 
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -3702,7 +3702,7 @@ rs6000_option_override_internal (bool global_init_p)
>>else
>>  {
>>/* PowerPC 64-bit LE requires at least ISA 2.07.  */
>> -  const char *default_cpu = (!TARGET_POWERPC64
>> +  const char *default_cpu = (!TARGET_POWERPC64 && TARGET_32BIT
>>   ? "powerpc"
>>   : (BYTES_BIG_ENDIAN
>>  ? "powerpc64"
> 
> ... but not like that.  If this snippet should happen later just move it
> later.  Or introduce a new variable to make the control flow less
> confused.  Or something else.  But don't make the code more complex,
> introducing more special cases like this.

Agree, the diff was mainly to check if it's the root cause.  I think we
need to place TARGET_POWERPC64 enablement for 64 bit before this hunk,
I've adjusted it in the new version, will post it once it's full tested.

> 
>> +#ifdef OS_MISSING_POWERPC64
>> +  else if (OS_MISSING_POWERPC64)
>> +/* It's unexpected to have OPTION_MASK_POWERPC64 on for OSes which
>> +   miss powerpc64 support, so disable it.  */
>> +rs6000_isa_flags &= ~OPTION_MASK_POWERPC64;
>> +#endif
> 
> All silent stuff is always bad.
> 

OK, with more testings for replacing warning instead of silently disablement
I noticed that some disablement is needed, one typical case is -m32 compilation
on ppc64, we have OPTION_MASK_POWERPC64 on from TARGET_DEFAULT which is used
for initialization (It makes sense to have it on in TARGET_DEFAULT because
of it's 64 bit cpu).  And -m32 compilation matches OS_MISSING_POWERPC64
(!TARGET_64BIT), so it's the case that we have an implicit OPTION_MASK_POWERPC64
on and OS_MISSING_POWERPC64 holds, but it's unexpected not to disable it but
warn it.

BR,
Kewen

> If things are done well, we will end up with *less* code than what we
> had before, not more!
> 
> 
> Segher

RE: [PATCH v2] testsuite: [arm] Relax expected register names in MVE tests

[Kyrylo Tkachov via Gcc-patches]

> -Original Message-
> From: Christophe Lyon 
> Sent: Friday, September 30, 2022 12:20 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Andre Simoes Dias Vieira
> ; Christophe Lyon
> 
> Subject: [PATCH v2] testsuite: [arm] Relax expected register names in MVE
> tests
> 
> These two tests have hardcoded q0 as destination/source of load/store
> instructions, but this register is actually used only under
> -mfloat-abi=hard. When using -mfloat-abi=softfp, other registers
> (eg. q3) can be used to transfer function arguments from core
> registers to MVE registers, making the expected regexp fail.
> 
> This small patch replaces q0 with q[0-7] to accept any 'q' register.
> In several places where we had q[0-9]+, replace it with q[0-7] as MVE
> only has q0-q7 registers.
> 
> OK for trunk?

Ok.
Thanks,
Kyrill

> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/arm/mve/mve_load_memory_modes.c: Update
> expected
>   registers.
>   * gcc.target/arm/mve/mve_store_memory_modes.c: Likewise.
> ---
>  .../arm/mve/mve_load_memory_modes.c   | 58 +--
>  .../arm/mve/mve_store_memory_modes.c  | 58 +--
>  2 files changed, 58 insertions(+), 58 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
> b/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
> index e35eb1108aa..816980d1203 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
> @@ -7,7 +7,7 @@
>  /*
>  **off_load8_0:
>  **   ...
> -**   vldrb.8 q0, \[r0, #16\]
> +**   vldrb.8 q[0-7], \[r0, #16\]
>  **   ...
>  */
>  int8x16_t off_load8_0 (int8_t * a)
> @@ -18,7 +18,7 @@ int8x16_t off_load8_0 (int8_t * a)
>  /*
>  **off_load8_1:
>  **   ...
> -**   vldrb.u16   q0, \[r0, #1\]
> +**   vldrb.u16   q[0-7], \[r0, #1\]
>  **   ...
>  */
>  uint16x8_t off_load8_1 (uint8_t * a)
> @@ -29,7 +29,7 @@ uint16x8_t off_load8_1 (uint8_t * a)
>  /*
>  **off_load8_2:
>  **   ...
> -**   vldrb.s32   q0, \[r0, #127\]
> +**   vldrb.s32   q[0-7], \[r0, #127\]
>  **   ...
>  */
>  int32x4_t off_load8_2 (int8_t * a)
> @@ -40,7 +40,7 @@ int32x4_t off_load8_2 (int8_t * a)
>  /*
>  **off_load8_3:
>  **   ...
> -**   vldrb.8 q0, \[r0, #-127\]
> +**   vldrb.8 q[0-7], \[r0, #-127\]
>  **   ...
>  */
>  uint8x16_t off_load8_3 (uint8_t * a)
> @@ -51,7 +51,7 @@ uint8x16_t off_load8_3 (uint8_t * a)
>  /*
>  **not_off_load8_0:
>  **   ...
> -**   vldrb.8 q0, \[r[0-9]+\]
> +**   vldrb.8 q[0-7], \[r[0-7]+\]
>  **   ...
>  */
>  int8x16_t not_off_load8_0 (int8_t * a)
> @@ -62,7 +62,7 @@ int8x16_t not_off_load8_0 (int8_t * a)
>  /*
>  **off_loadfp16_0:
>  **   ...
> -**   vldrh.16q0, \[r0, #-244\]
> +**   vldrh.16q[0-7], \[r0, #-244\]
>  **   ...
>  */
>  float16x8_t off_loadfp16_0 (float16_t *a)
> @@ -73,7 +73,7 @@ float16x8_t off_loadfp16_0 (float16_t *a)
>  /*
>  **off_load16_0:
>  **   ...
> -**   vldrh.16q0, \[r0, #-2\]
> +**   vldrh.16q[0-7], \[r0, #-2\]
>  **   ...
>  */
>  uint16x8_t off_load16_0 (uint16_t * a)
> @@ -84,7 +84,7 @@ uint16x8_t off_load16_0 (uint16_t * a)
>  /*
>  **off_load16_1:
>  **   ...
> -**   vldrh.u32   q0, \[r0, #254\]
> +**   vldrh.u32   q[0-7], \[r0, #254\]
>  **   ...
>  */
>  uint32x4_t off_load16_1 (uint16_t * a)
> @@ -95,7 +95,7 @@ uint32x4_t off_load16_1 (uint16_t * a)
>  /*
>  **not_off_load16_0:
>  **   ...
> -**   vldrh.16q0, \[r[0-9]+\]
> +**   vldrh.16q[0-7], \[r[0-7]+\]
>  **   ...
>  */
>  int16x8_t not_off_load16_0 (int8_t * a)
> @@ -106,7 +106,7 @@ int16x8_t not_off_load16_0 (int8_t * a)
>  /*
>  **not_off_load16_1:
>  **   ...
> -**   vldrh.u32   q0, \[r[0-9]+\]
> +**   vldrh.u32   q[0-7], \[r[0-7]+\]
>  **   ...
>  */
>  uint32x4_t not_off_load16_1 (uint16_t * a)
> @@ -117,7 +117,7 @@ uint32x4_t not_off_load16_1 (uint16_t * a)
>  /*
>  **off_loadfp32_0:
>  **   ...
> -**   vldrw.32q0, \[r0, #24\]
> +**   vldrw.32q[0-7], \[r0, #24\]
>  **   ...
>  */
>  float32x4_t off_loadfp32_0 (float32_t *a)
> @@ -128,7 +128,7 @@ float32x4_t off_loadfp32_0 (float32_t *a)
>  /*
>  **off_load32_0:
>  **   ...
> -**   vldrw.32q0, \[r0, #4\]
> +**   vldrw.32q[0-7], \[r0, #4\]
>  **   ...
>  */
>  uint32x4_t off_load32_0 (uint32_t * a)
> @@ -139,7 +139,7 @@ uint32x4_t off_load32_0 (uint32_t * a)
>  /*
>  **off_load32_1:
>  **   ...
> -**   vldrw.32q0, \[r0, #-508\]
> +**   vldrw.32q[0-7], \[r0, #-508\]
>  **   ...
>  */
>  int32x4_t off_load32_1 (int32_t * a)
> @@ -149,7 +149,7 @@ int32x4_t off_load32_1 (int32_t * a)
>  /*
>  **pre_load8_0:
>  **   ...
> -**   vldrb.8 q[0-9]+, \[r0, #16\]!
> +**   vldrb.8 q[0-7], \[r0, #16\]!
>  **   ...
>  */
>  int8_t* pre_load8_0 (int8_t * a, int8x16_t *v)
> @@ -162,7 +162,7 @@ int8_t* pre_load8_0 (int8_t * a, int8x16_t *v)
>  /*
>  **pre_load8_1:
>  **   ...
> -**   vldrb.u16   q[0-9]+, \[r0, #4\]!
> +**   vldrb.u16  

RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

[Richard Biener via Gcc-patches]

On Fri, 30 Sep 2022, Tamar Christina wrote:

> > -Original Message-
> > From: Richard Biener 
> > Sent: Friday, September 30, 2022 11:17 AM
> > To: Tamar Christina 
> > Cc: Richard Sandiford ; Tamar Christina via
> > Gcc-patches ; nd ; Jeff Law
> > 
> > Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> > branches, give hint if argument is a truth type to backend
> > 
> > On Fri, 30 Sep 2022, Tamar Christina wrote:
> > 
> > >
> > >
> > > > -Original Message-
> > > > From: Richard Sandiford 
> > > > Sent: Friday, September 30, 2022 9:49 AM
> > > > To: Tamar Christina 
> > > > Cc: Richard Biener ; Tamar Christina via
> > > > Gcc-patches ; nd ; Jeff Law
> > > > 
> > > > Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> > > > branches, give hint if argument is a truth type to backend
> > > >
> > > > Tamar Christina  writes:
> > > > >> -Original Message-
> > > > >> From: Richard Sandiford 
> > > > >> Sent: Friday, September 30, 2022 9:29 AM
> > > > >> To: Tamar Christina 
> > > > >> Cc: Richard Biener ; Tamar Christina via
> > > > >> Gcc-patches ; nd ; Jeff
> > Law
> > > > >> 
> > > > >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> > > > >> conditional branches, give hint if argument is a truth type to
> > > > >> backend
> > > > >>
> > > > >> Tamar Christina  writes:
> > > > >> >> -Original Message-
> > > > >> >> From: Gcc-patches  > > > >> >> bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of
> > > > Richard
> > > > >> >> Biener via Gcc-patches
> > > > >> >> Sent: Thursday, September 29, 2022 12:09 PM
> > > > >> >> To: Tamar Christina via Gcc-patches 
> > > > >> >> Cc: Richard Sandiford ; nd
> > > > 
> > > > >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> > > > >> >> conditional branches, give hint if argument is a truth type to
> > > > >> >> backend
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> > Am 29.09.2022 um 12:23 schrieb Tamar Christina via
> > > > >> >> > Gcc-patches
> > > > >> >> >  > > > >> >> patc...@gcc.gnu.org>:
> > > > >> >> >
> > > > >> >> >
> > > > >> >> >>
> > > > >> >> >> -Original Message-
> > > > >> >> >> From: Richard Biener 
> > > > >> >> >> Sent: Thursday, September 29, 2022 10:41 AM
> > > > >> >> >> To: Richard Sandiford 
> > > > >> >> >> Cc: Jeff Law ; Tamar Christina
> > > > >> >> >> ; gcc-patches@gcc.gnu.org; nd
> > > > >> >> 
> > > > >> >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> > > > >> >> >> conditional branches, give hint if argument is a truth type
> > > > >> >> >> to backend
> > > > >> >> >>
> > > > >> >> >>> On Thu, 29 Sep 2022, Richard Sandiford wrote:
> > > > >> >> >>>
> > > > >> >> >>> Jeff Law  writes:
> > > > >> >>  On 9/28/22 09:04, Richard Sandiford wrote:
> > > > >> >> > Tamar Christina  writes:
> > > > >> >> >>> Maybe the target could use (subreg:SI (reg:BI ...)) as
> > > > argument.
> > > > >> >> Heh.
> > > > >> >> >> But then I'd still need to change the expansion code. I
> > > > >> >> >> suppose this could prevent the issue with changes to
> > > > >> >> >> code on
> > > > >> other targets.
> > > > >> >> >>
> > > > >> >> > We have undocumented addcc, negcc, etc. patterns,
> > > > should
> > > > >> we
> > > > >> >> > have aandcc
> > > > >> >> >> pattern for this indicating support for andcc + jump as
> > > > >> >> >> opposedto
> > > > >> >> >> cmpcc + jump?
> > > > >> >>  This could work yeah. I didn't know these existed.
> > > > >> >> >>> Ah, so they are conditional add, not add setting CC,
> > > > >> >> >>> so andcc wouldn't be appropriate.
> > > > >> >> >>> So I'm not sure how we'd handle such situation - maybe
> > > > >> >> >>> looking at REG_DECL and recognizing a _Bool PARM_DECL
> > > > >> >> >>> is
> > > > OK?
> > > > >> >> >> I have a slight suspicion that Richard Sandiford would
> > > > >> >> >> likely reject this though..
> > > > >> >> > Good guess :-P  We shouldn't rely on something like that
> > > > >> >> > for
> > > > >> >> >> correctness.
> > > > >> >> >
> > > > >> >> > Would it help if we promoted the test-and-branch
> > > > >> >> > instructions to optabs, alongside cbranch?  The jump
> > > > >> >> > expanders could then target it
> > > > >> >> >> directly.
> > > > >> >> >
> > > > >> >> > IMO that'd be a reasonable thing to do if it does help.
> > > > >> >> > It's a relatively common operation, especially on CISCy
> > targets.
> > > > >> >> 
> > > > >> >>  But don't we represent these single bit tests using
> > > > >> >>  zero_extract as the condition of the branch?  I guess if
> > > > >> >>  we can generate them directly rather than waiting for
> > > > >> >>  combine to deduce that we're dealing with a single bit
> > > > >> >>  test and constructing the zero_extract form would be an
> > > > >> >>  improvement and might help aarch at the same
> > > > >> 

Re: [PATCH v2] testsuite: [arm] Relax expected register names in MVE tests

[Richard Earnshaw via Gcc-patches]

On 30/09/2022 12:19, Christophe Lyon via Gcc-patches wrote:

These two tests have hardcoded q0 as destination/source of load/store
instructions, but this register is actually used only under
-mfloat-abi=hard. When using -mfloat-abi=softfp, other registers
(eg. q3) can be used to transfer function arguments from core
registers to MVE registers, making the expected regexp fail.

This small patch replaces q0 with q[0-7] to accept any 'q' register.
In several places where we had q[0-9]+, replace it with q[0-7] as MVE
only has q0-q7 registers.

OK for trunk?

gcc/testsuite/ChangeLog:

* gcc.target/arm/mve/mve_load_memory_modes.c: Update expected
registers.
* gcc.target/arm/mve/mve_store_memory_modes.c: Likewise.


OK.

R.

---
  .../arm/mve/mve_load_memory_modes.c   | 58 +--
  .../arm/mve/mve_store_memory_modes.c  | 58 +--
  2 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c 
b/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
index e35eb1108aa..816980d1203 100644
--- a/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
+++ b/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
@@ -7,7 +7,7 @@
  /*
  **off_load8_0:
  **...
-** vldrb.8 q0, \[r0, #16\]
+** vldrb.8 q[0-7], \[r0, #16\]
  **...
  */
  int8x16_t off_load8_0 (int8_t * a)
@@ -18,7 +18,7 @@ int8x16_t off_load8_0 (int8_t * a)
  /*
  **off_load8_1:
  **...
-** vldrb.u16   q0, \[r0, #1\]
+** vldrb.u16   q[0-7], \[r0, #1\]
  **...
  */
  uint16x8_t off_load8_1 (uint8_t * a)
@@ -29,7 +29,7 @@ uint16x8_t off_load8_1 (uint8_t * a)
  /*
  **off_load8_2:
  **...
-** vldrb.s32   q0, \[r0, #127\]
+** vldrb.s32   q[0-7], \[r0, #127\]
  **...
  */
  int32x4_t off_load8_2 (int8_t * a)
@@ -40,7 +40,7 @@ int32x4_t off_load8_2 (int8_t * a)
  /*
  **off_load8_3:
  **...
-** vldrb.8 q0, \[r0, #-127\]
+** vldrb.8 q[0-7], \[r0, #-127\]
  **...
  */
  uint8x16_t off_load8_3 (uint8_t * a)
@@ -51,7 +51,7 @@ uint8x16_t off_load8_3 (uint8_t * a)
  /*
  **not_off_load8_0:
  **...
-** vldrb.8 q0, \[r[0-9]+\]
+** vldrb.8 q[0-7], \[r[0-7]+\]
  **...
  */
  int8x16_t not_off_load8_0 (int8_t * a)
@@ -62,7 +62,7 @@ int8x16_t not_off_load8_0 (int8_t * a)
  /*
  **off_loadfp16_0:
  **...
-** vldrh.16q0, \[r0, #-244\]
+** vldrh.16q[0-7], \[r0, #-244\]
  **...
  */
  float16x8_t off_loadfp16_0 (float16_t *a)
@@ -73,7 +73,7 @@ float16x8_t off_loadfp16_0 (float16_t *a)
  /*
  **off_load16_0:
  **...
-** vldrh.16q0, \[r0, #-2\]
+** vldrh.16q[0-7], \[r0, #-2\]
  **...
  */
  uint16x8_t off_load16_0 (uint16_t * a)
@@ -84,7 +84,7 @@ uint16x8_t off_load16_0 (uint16_t * a)
  /*
  **off_load16_1:
  **...
-** vldrh.u32   q0, \[r0, #254\]
+** vldrh.u32   q[0-7], \[r0, #254\]
  **...
  */
  uint32x4_t off_load16_1 (uint16_t * a)
@@ -95,7 +95,7 @@ uint32x4_t off_load16_1 (uint16_t * a)
  /*
  **not_off_load16_0:
  **...
-** vldrh.16q0, \[r[0-9]+\]
+** vldrh.16q[0-7], \[r[0-7]+\]
  **...
  */
  int16x8_t not_off_load16_0 (int8_t * a)
@@ -106,7 +106,7 @@ int16x8_t not_off_load16_0 (int8_t * a)
  /*
  **not_off_load16_1:
  **...
-** vldrh.u32   q0, \[r[0-9]+\]
+** vldrh.u32   q[0-7], \[r[0-7]+\]
  **...
  */
  uint32x4_t not_off_load16_1 (uint16_t * a)
@@ -117,7 +117,7 @@ uint32x4_t not_off_load16_1 (uint16_t * a)
  /*
  **off_loadfp32_0:
  **...
-** vldrw.32q0, \[r0, #24\]
+** vldrw.32q[0-7], \[r0, #24\]
  **...
  */
  float32x4_t off_loadfp32_0 (float32_t *a)
@@ -128,7 +128,7 @@ float32x4_t off_loadfp32_0 (float32_t *a)
  /*
  **off_load32_0:
  **...
-** vldrw.32q0, \[r0, #4\]
+** vldrw.32q[0-7], \[r0, #4\]
  **...
  */
  uint32x4_t off_load32_0 (uint32_t * a)
@@ -139,7 +139,7 @@ uint32x4_t off_load32_0 (uint32_t * a)
  /*
  **off_load32_1:
  **...
-** vldrw.32q0, \[r0, #-508\]
+** vldrw.32q[0-7], \[r0, #-508\]
  **...
  */
  int32x4_t off_load32_1 (int32_t * a)
@@ -149,7 +149,7 @@ int32x4_t off_load32_1 (int32_t * a)
  /*
  **pre_load8_0:
  **...
-** vldrb.8 q[0-9]+, \[r0, #16\]!
+** vldrb.8 q[0-7], \[r0, #16\]!
  **...
  */
  int8_t* pre_load8_0 (int8_t * a, int8x16_t *v)
@@ -162,7 +162,7 @@ int8_t* pre_load8_0 (int8_t * a, int8x16_t *v)
  /*
  **pre_load8_1:
  **...
-** vldrb.u16   q[0-9]+, \[r0, #4\]!
+** vldrb.u16   q[0-7], \[r0, #4\]!
  **...
  */
  uint8_t* pre_load8_1 (uint8_t * a, uint16x8_t *v)
@@ -175,7 +175,7 @@ uint8_t* pre_load8_1 (uint8_t * a, uint16x8_t *v)
  /*
  **pre_loadfp16_0:
  **...
-** vldrh.16q[0-9]+, \[r0, #128\]!
+** vldrh.16q[0-7], \[r0, #128\]!
  **...
  */
  float16_t* pre_loadfp16_0 (float16_t *a, float16x8_t 

Re: [Patch] Fortran: Update use_device_ptr for OpenMP 5.1 [PR105318]

[Tobias Burnus]

Hi Jakub,

On 30.09.22 13:04, Jakub Jelinek via Fortran wrote:

On Fri, Sep 30, 2022 at 12:41:19PM +0200, Tobias Burnus wrote:


And 'device(omp_initial_device)' printed a warning in Fortran.
(BTW: C/C++ silently accepts any negative value.)


I think that is what the standard wants.
E.g. in 5.2 device Clause chapter, there is just
"If the device_num device-modifier is specified and target-offload-var is not 
mandatory,
device-description must evaluate to a conforming device number."
restriction, which is something that can't be checked at compile time,
you don't know if target-offload-var is mandatory or not.


Admittedly, it is valid to use a non-conforming device number with
target-offload-var being 'mandatory'; however, the result is still
it it has a "non-conforming device number, is as if the
omp_invalid_device device number was used." (Which implies error
termination.)

Thus, while not invalid (iff using 'mandatory'), it is still odd
code and using 'device(omp_invalid_device)' is more sensible.

I think it is legitimate to warn in this case - but not to
print an error. It is likewise fine to accept it silently.



  if (omp_clauses->device)
-resolve_nonnegative_int_expr (omp_clauses->device, "DEVICE");
+{
+  resolve_scalar_int_expr (omp_clauses->device, "DEVICE");
+  /* omp_initial_device == 1, omp_invalid_device = -4 (in GCC).  */
+  if (omp_clauses->device->expr_type == EXPR_CONSTANT
+ && omp_clauses->device->ts.type == BT_INTEGER
+ && mpz_cmp_si (omp_clauses->device->value.integer, -1) < 0
+ && mpz_cmp_si (omp_clauses->device->value.integer, -4) != 0)
+   gfc_warning (0,
+"INTEGER expression of DEVICE clause at %L must be non-"
+"negative or omp_initial_device or omp_invalid_device",
+_clauses->device->where);
+}



So I think we should just resolve_scalar_int_expr and be done with that.

Otherwise LGTM.


I have now done as suggested - and committed it as 
https://gcc.gnu.org/r13-2980-g10a116104969b3ecc9ea4abdd5436c66fd78d537

Thanks for the review!

Tobias


-
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

[PATCH v2] testsuite: [arm] Relax expected register names in MVE tests

[Christophe Lyon via Gcc-patches]

These two tests have hardcoded q0 as destination/source of load/store
instructions, but this register is actually used only under
-mfloat-abi=hard. When using -mfloat-abi=softfp, other registers
(eg. q3) can be used to transfer function arguments from core
registers to MVE registers, making the expected regexp fail.

This small patch replaces q0 with q[0-7] to accept any 'q' register.
In several places where we had q[0-9]+, replace it with q[0-7] as MVE
only has q0-q7 registers.

OK for trunk?

gcc/testsuite/ChangeLog:

* gcc.target/arm/mve/mve_load_memory_modes.c: Update expected
registers.
* gcc.target/arm/mve/mve_store_memory_modes.c: Likewise.
---
 .../arm/mve/mve_load_memory_modes.c   | 58 +--
 .../arm/mve/mve_store_memory_modes.c  | 58 +--
 2 files changed, 58 insertions(+), 58 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c 
b/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
index e35eb1108aa..816980d1203 100644
--- a/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
+++ b/gcc/testsuite/gcc.target/arm/mve/mve_load_memory_modes.c
@@ -7,7 +7,7 @@
 /*
 **off_load8_0:
 ** ...
-** vldrb.8 q0, \[r0, #16\]
+** vldrb.8 q[0-7], \[r0, #16\]
 ** ...
 */
 int8x16_t off_load8_0 (int8_t * a)
@@ -18,7 +18,7 @@ int8x16_t off_load8_0 (int8_t * a)
 /*
 **off_load8_1:
 ** ...
-** vldrb.u16   q0, \[r0, #1\]
+** vldrb.u16   q[0-7], \[r0, #1\]
 ** ...
 */
 uint16x8_t off_load8_1 (uint8_t * a)
@@ -29,7 +29,7 @@ uint16x8_t off_load8_1 (uint8_t * a)
 /*
 **off_load8_2:
 ** ...
-** vldrb.s32   q0, \[r0, #127\]
+** vldrb.s32   q[0-7], \[r0, #127\]
 ** ...
 */
 int32x4_t off_load8_2 (int8_t * a)
@@ -40,7 +40,7 @@ int32x4_t off_load8_2 (int8_t * a)
 /*
 **off_load8_3:
 ** ...
-** vldrb.8 q0, \[r0, #-127\]
+** vldrb.8 q[0-7], \[r0, #-127\]
 ** ...
 */
 uint8x16_t off_load8_3 (uint8_t * a)
@@ -51,7 +51,7 @@ uint8x16_t off_load8_3 (uint8_t * a)
 /*
 **not_off_load8_0:
 ** ...
-** vldrb.8 q0, \[r[0-9]+\]
+** vldrb.8 q[0-7], \[r[0-7]+\]
 ** ...
 */
 int8x16_t not_off_load8_0 (int8_t * a)
@@ -62,7 +62,7 @@ int8x16_t not_off_load8_0 (int8_t * a)
 /*
 **off_loadfp16_0:
 ** ...
-** vldrh.16q0, \[r0, #-244\]
+** vldrh.16q[0-7], \[r0, #-244\]
 ** ...
 */
 float16x8_t off_loadfp16_0 (float16_t *a)
@@ -73,7 +73,7 @@ float16x8_t off_loadfp16_0 (float16_t *a)
 /*
 **off_load16_0:
 ** ...
-** vldrh.16q0, \[r0, #-2\]
+** vldrh.16q[0-7], \[r0, #-2\]
 ** ...
 */
 uint16x8_t off_load16_0 (uint16_t * a)
@@ -84,7 +84,7 @@ uint16x8_t off_load16_0 (uint16_t * a)
 /*
 **off_load16_1:
 ** ...
-** vldrh.u32   q0, \[r0, #254\]
+** vldrh.u32   q[0-7], \[r0, #254\]
 ** ...
 */
 uint32x4_t off_load16_1 (uint16_t * a)
@@ -95,7 +95,7 @@ uint32x4_t off_load16_1 (uint16_t * a)
 /*
 **not_off_load16_0:
 ** ...
-** vldrh.16q0, \[r[0-9]+\]
+** vldrh.16q[0-7], \[r[0-7]+\]
 ** ...
 */
 int16x8_t not_off_load16_0 (int8_t * a)
@@ -106,7 +106,7 @@ int16x8_t not_off_load16_0 (int8_t * a)
 /*
 **not_off_load16_1:
 ** ...
-** vldrh.u32   q0, \[r[0-9]+\]
+** vldrh.u32   q[0-7], \[r[0-7]+\]
 ** ...
 */
 uint32x4_t not_off_load16_1 (uint16_t * a)
@@ -117,7 +117,7 @@ uint32x4_t not_off_load16_1 (uint16_t * a)
 /*
 **off_loadfp32_0:
 ** ...
-** vldrw.32q0, \[r0, #24\]
+** vldrw.32q[0-7], \[r0, #24\]
 ** ...
 */
 float32x4_t off_loadfp32_0 (float32_t *a)
@@ -128,7 +128,7 @@ float32x4_t off_loadfp32_0 (float32_t *a)
 /*
 **off_load32_0:
 ** ...
-** vldrw.32q0, \[r0, #4\]
+** vldrw.32q[0-7], \[r0, #4\]
 ** ...
 */
 uint32x4_t off_load32_0 (uint32_t * a)
@@ -139,7 +139,7 @@ uint32x4_t off_load32_0 (uint32_t * a)
 /*
 **off_load32_1:
 ** ...
-** vldrw.32q0, \[r0, #-508\]
+** vldrw.32q[0-7], \[r0, #-508\]
 ** ...
 */
 int32x4_t off_load32_1 (int32_t * a)
@@ -149,7 +149,7 @@ int32x4_t off_load32_1 (int32_t * a)
 /*
 **pre_load8_0:
 ** ...
-** vldrb.8 q[0-9]+, \[r0, #16\]!
+** vldrb.8 q[0-7], \[r0, #16\]!
 ** ...
 */
 int8_t* pre_load8_0 (int8_t * a, int8x16_t *v)
@@ -162,7 +162,7 @@ int8_t* pre_load8_0 (int8_t * a, int8x16_t *v)
 /*
 **pre_load8_1:
 ** ...
-** vldrb.u16   q[0-9]+, \[r0, #4\]!
+** vldrb.u16   q[0-7], \[r0, #4\]!
 ** ...
 */
 uint8_t* pre_load8_1 (uint8_t * a, uint16x8_t *v)
@@ -175,7 +175,7 @@ uint8_t* pre_load8_1 (uint8_t * a, uint16x8_t *v)
 /*
 **pre_loadfp16_0:
 ** ...
-** vldrh.16q[0-9]+, \[r0, #128\]!
+** vldrh.16q[0-7], \[r0, #128\]!
 ** ...
 */
 float16_t* pre_loadfp16_0 (float16_t *a, float16x8_t *v)
@@ -188,7 +188,7 @@ float16_t* pre_loadfp16_0 (float16_t *a, float16x8_t *v)
 /*
 **pre_load16_0:
 ** ...
-** vldrh.16

Re: [PATCH] testsuite: Colon is reserved on Windows

[Nathan Sidwell via Gcc-patches]

On 9/30/22 04:18, Torbjörn SVENSSON wrote:

The ':' is reserved in filenames on Windows.
Can't find any specification for this, but when there is no filename
defined in the map file, GCC will replace the ':' with a '-' in the
generated filename for the module.


Correct (and the specification is in the source code, there's no 
requirement for any particular mapping, bu I was at least cognizant of 
windows' dislike of : :)




Without this patch, the test case failes with:
.../ben-1_a.C:4:8: error: failed to write compiled module: Invalid argument
.../ben-1_a.C:4:8: note: compiled module file is 'partitions/module:import.mod'

gcc/testsuite:

* g++.dg/modules/ben-1.map: Replace the colon with dash.
* g++.dg/modules/ben-1_a.C: Likewise


ok, thanks



Co-Authored-By: Yvan ROUX  
Signed-off-by: Torbjörn SVENSSON  
---
  gcc/testsuite/g++.dg/modules/ben-1.map | 2 +-
  gcc/testsuite/g++.dg/modules/ben-1_a.C | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/g++.dg/modules/ben-1.map 
b/gcc/testsuite/g++.dg/modules/ben-1.map
index 182183ad089..ad84c11397d 100644
--- a/gcc/testsuite/g++.dg/modules/ben-1.map
+++ b/gcc/testsuite/g++.dg/modules/ben-1.map
@@ -1,3 +1,3 @@
  $root .
-module:import partitions/module:import.mod
+module:import partitions/module-import.mod
  module module.mod
diff --git a/gcc/testsuite/g++.dg/modules/ben-1_a.C 
b/gcc/testsuite/g++.dg/modules/ben-1_a.C
index 7e9b5661026..f1562eb2c5a 100644
--- a/gcc/testsuite/g++.dg/modules/ben-1_a.C
+++ b/gcc/testsuite/g++.dg/modules/ben-1_a.C
@@ -2,7 +2,7 @@
  // { dg-additional-files ben-1.map }
  
  export module module:import;

-// { dg-module-cmi =partitions/module:import.mod }
+// { dg-module-cmi =partitions/module-import.mod }
  
  export int b() {

return 0;


--
Nathan Sidwell

RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend

[Tamar Christina via Gcc-patches]

> -Original Message-
> From: Richard Biener 
> Sent: Friday, September 30, 2022 11:17 AM
> To: Tamar Christina 
> Cc: Richard Sandiford ; Tamar Christina via
> Gcc-patches ; nd ; Jeff Law
> 
> Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> branches, give hint if argument is a truth type to backend
> 
> On Fri, 30 Sep 2022, Tamar Christina wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Richard Sandiford 
> > > Sent: Friday, September 30, 2022 9:49 AM
> > > To: Tamar Christina 
> > > Cc: Richard Biener ; Tamar Christina via
> > > Gcc-patches ; nd ; Jeff Law
> > > 
> > > Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> > > branches, give hint if argument is a truth type to backend
> > >
> > > Tamar Christina  writes:
> > > >> -Original Message-
> > > >> From: Richard Sandiford 
> > > >> Sent: Friday, September 30, 2022 9:29 AM
> > > >> To: Tamar Christina 
> > > >> Cc: Richard Biener ; Tamar Christina via
> > > >> Gcc-patches ; nd ; Jeff
> Law
> > > >> 
> > > >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> > > >> conditional branches, give hint if argument is a truth type to
> > > >> backend
> > > >>
> > > >> Tamar Christina  writes:
> > > >> >> -Original Message-
> > > >> >> From: Gcc-patches  > > >> >> bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of
> > > Richard
> > > >> >> Biener via Gcc-patches
> > > >> >> Sent: Thursday, September 29, 2022 12:09 PM
> > > >> >> To: Tamar Christina via Gcc-patches 
> > > >> >> Cc: Richard Sandiford ; nd
> > > 
> > > >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> > > >> >> conditional branches, give hint if argument is a truth type to
> > > >> >> backend
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> > Am 29.09.2022 um 12:23 schrieb Tamar Christina via
> > > >> >> > Gcc-patches
> > > >> >> >  > > >> >> patc...@gcc.gnu.org>:
> > > >> >> >
> > > >> >> >
> > > >> >> >>
> > > >> >> >> -Original Message-
> > > >> >> >> From: Richard Biener 
> > > >> >> >> Sent: Thursday, September 29, 2022 10:41 AM
> > > >> >> >> To: Richard Sandiford 
> > > >> >> >> Cc: Jeff Law ; Tamar Christina
> > > >> >> >> ; gcc-patches@gcc.gnu.org; nd
> > > >> >> 
> > > >> >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of
> > > >> >> >> conditional branches, give hint if argument is a truth type
> > > >> >> >> to backend
> > > >> >> >>
> > > >> >> >>> On Thu, 29 Sep 2022, Richard Sandiford wrote:
> > > >> >> >>>
> > > >> >> >>> Jeff Law  writes:
> > > >> >>  On 9/28/22 09:04, Richard Sandiford wrote:
> > > >> >> > Tamar Christina  writes:
> > > >> >> >>> Maybe the target could use (subreg:SI (reg:BI ...)) as
> > > argument.
> > > >> >> Heh.
> > > >> >> >> But then I'd still need to change the expansion code. I
> > > >> >> >> suppose this could prevent the issue with changes to
> > > >> >> >> code on
> > > >> other targets.
> > > >> >> >>
> > > >> >> > We have undocumented addcc, negcc, etc. patterns,
> > > should
> > > >> we
> > > >> >> > have aandcc
> > > >> >> >> pattern for this indicating support for andcc + jump as
> > > >> >> >> opposedto
> > > >> >> >> cmpcc + jump?
> > > >> >>  This could work yeah. I didn't know these existed.
> > > >> >> >>> Ah, so they are conditional add, not add setting CC,
> > > >> >> >>> so andcc wouldn't be appropriate.
> > > >> >> >>> So I'm not sure how we'd handle such situation - maybe
> > > >> >> >>> looking at REG_DECL and recognizing a _Bool PARM_DECL
> > > >> >> >>> is
> > > OK?
> > > >> >> >> I have a slight suspicion that Richard Sandiford would
> > > >> >> >> likely reject this though..
> > > >> >> > Good guess :-P  We shouldn't rely on something like that
> > > >> >> > for
> > > >> >> >> correctness.
> > > >> >> >
> > > >> >> > Would it help if we promoted the test-and-branch
> > > >> >> > instructions to optabs, alongside cbranch?  The jump
> > > >> >> > expanders could then target it
> > > >> >> >> directly.
> > > >> >> >
> > > >> >> > IMO that'd be a reasonable thing to do if it does help.
> > > >> >> > It's a relatively common operation, especially on CISCy
> targets.
> > > >> >> 
> > > >> >>  But don't we represent these single bit tests using
> > > >> >>  zero_extract as the condition of the branch?  I guess if
> > > >> >>  we can generate them directly rather than waiting for
> > > >> >>  combine to deduce that we're dealing with a single bit
> > > >> >>  test and constructing the zero_extract form would be an
> > > >> >>  improvement and might help aarch at the same
> > > >> time.
> > > >> >> >>>
> > > >> >> >>> Do you mean that the promote_mode stuff should use ext(z)v
> > > >> >> >>> rather than zero_extend to promote a bool, where available?
> > > >> >> >>> If so, I agree that might help.  But it sounds like it
> > > >> >> >>> would have downsides
> > 

Re: [Patch] Fortran: Update use_device_ptr for OpenMP 5.1 [PR105318]

[Jakub Jelinek via Gcc-patches]

On Fri, Sep 30, 2022 at 12:41:19PM +0200, Tobias Burnus wrote:
> While has_device_addr has been implemented (in GCC 12), updating
> use_device_ptr for Fortran was missed.
> 
> This patch fixes it: Removing the restrictions and mapping to
> has_device_addr where applicable.
> 
> For use_device_ptr something similar was done, albeit I think
> this has no semantic effect.
> 
> And 'device(omp_initial_device)' printed a warning in Fortran.
> (BTW: C/C++ silently accepts any negative value.)

I think that is what the standard wants.
E.g. in 5.2 device Clause chapter, there is just
"If the device_num device-modifier is specified and target-offload-var is not 
mandatory,
device-description must evaluate to a conforming device number."
restriction, which is something that can't be checked at compile time,
you don't know if target-offload-var is mandatory or not.
>if (omp_clauses->device)
> -resolve_nonnegative_int_expr (omp_clauses->device, "DEVICE");
> +{
> +  resolve_scalar_int_expr (omp_clauses->device, "DEVICE");
> +  /* omp_initial_device == 1, omp_invalid_device = -4 (in GCC).  */
> +  if (omp_clauses->device->expr_type == EXPR_CONSTANT
> +   && omp_clauses->device->ts.type == BT_INTEGER
> +   && mpz_cmp_si (omp_clauses->device->value.integer, -1) < 0
> +   && mpz_cmp_si (omp_clauses->device->value.integer, -4) != 0)
> + gfc_warning (0,
> +  "INTEGER expression of DEVICE clause at %L must be non-"
> +  "negative or omp_initial_device or omp_invalid_device",
> +  _clauses->device->where);
> +}

So I think we should just resolve_scalar_int_expr and be done with that.

Otherwise LGTM.

Jakub

Re: [Patch] Fortran: Update use_device_ptr for OpenMP 5.1 [PR105318]

[Tobias Burnus]

On 30.09.22 12:41, Tobias Burnus wrote:

Fortran: Update use_device_ptr for OpenMP 5.1 [PR105318]

The following two lines slipped in – which I have now removed in my version of 
the patch:

--- a/gcc/testsuite/gfortran.dg/gomp/is_device_ptr-1.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/is_device_ptr-1.f90
@@ -1,4 +1,5 @@
! { dg-do compile }
+! First


(Leftover - I wanted to refer to PR105318 - but then decided against it.)



+++ b/libgomp/testsuite/libgomp.fortran/is_device_ptr-2.f90
@@ -0,0 +1,167 @@
+! { dg-do compile }


Likewise leftover - I had an intermittent problem with device testing; hence, I 
disabled it. It turned out to be unrelated, but it remained.

Side remark: An issue I found with device testing was that I missed the "xx => 
null()"; in principle obvious (as GCC tried to map the pointer target of the 
uninitialized pointer), but still easy to miss.

Side note: The OpenMP spec (post-5.2) also clarified the mapping of undefined 
pointers / requiring the two null init here.

(The second null() is to avoid issues with firstprivatizing/copy-in of the 
internal pointer representation vs. simply using it (host fallback, unified 
shared memory). This forces the pointer after the target region to be the same 
as before the region (now required by the spec!), permitting either 
implementation without unexpected side effects for the user.)

Tobias

-
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