date:20220831

On 8/31/22 6:45 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 06:36:40PM -0500, Peter Bergner wrote:
>> Changes from v1:
>> * Fix spelling typo in git log entry
>> * Fix broken test checking src_ptr's type
>> * Use NOP_EXPR rather than VIEW_CONVERT_EXPR
>> * Change order of dg-options
>>
>> When we expand an MMA disassemble built-in with C++ using a pointer that
>> is cast to a valid MMA type, the type isn't passed down to the expand
>> machinery and we end up using the base type of the pointer which leads to
>> an ICE.  This patch enforces we always use the correct MMA type regardless
>> of the pointer type being used.
> 
> Okay for trunk and all backports (after it has survived a breath of
> fresh air).  Thanks!

Ok, pushed to trunk and I'll give it some burn-in time before backporting.
Thanks!

Peter

Re: [PATCH] RISC-V: Add RVV registers in TARGET_CONDITION_AL_REGISTER_USAGE

Committed with title fix, that should be TARGET_CONDITIONAL_REGISTER_USAGE

On Tue, Aug 30, 2022 at 2:28 PM  wrote:
>
> From: zhongjuzhe 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_conditional_register_usage): Add RVV 
> registers.
>
> ---
>  gcc/config/riscv/riscv.cc | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 50de6a83cba..aebe3c0ab6b 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -5439,6 +5439,15 @@ riscv_conditional_register_usage (void)
>for (int regno = FP_REG_FIRST; regno <= FP_REG_LAST; regno++)
> call_used_regs[regno] = 1;
>  }
> +
> +  if (!TARGET_VECTOR)
> +{
> +  for (int regno = V_REG_FIRST; regno <= V_REG_LAST; regno++)
> +   fixed_regs[regno] = call_used_regs[regno] = 1;
> +
> +  fixed_regs[VTYPE_REGNUM] = call_used_regs[VTYPE_REGNUM] = 1;
> +  fixed_regs[VL_REGNUM] = call_used_regs[VL_REGNUM] = 1;
> +}
>  }
>
>  /* Return a register priority for hard reg REGNO.  */
> --
> 2.36.1
>

Re: [PATCH] RISC-V: Add csrr vlenb instruction.

Committed.

On Tue, Aug 30, 2022 at 2:21 PM  wrote:
>
> From: zhongjuzhe 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_const_insns): Add cost of poly_int.
> (riscv_output_move): Add csrr vlenb assembly.
> * config/riscv/riscv.md (move_type): Add csrr vlenb type.
> (ext): New attribute.
> (ext_enabled): Ditto.
> (enabled): Ditto.
>
> ---
>  gcc/config/riscv/riscv.cc | 13 +++
>  gcc/config/riscv/riscv.md | 79 ---
>  2 files changed, 70 insertions(+), 22 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index ef606f33983..50de6a83cba 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -1136,6 +1136,12 @@ riscv_const_insns (rtx x)
>  case LABEL_REF:
>return riscv_symbol_insns (riscv_classify_symbol (x));
>
> +/* TODO: In RVV, we get CONST_POLY_INT by using csrr vlenb
> +   instruction and several scalar shift or mult instructions,
> +   it is so far unknown. We set it to 4 temporarily.  */
> +case CONST_POLY_INT:
> +  return 4;
> +
>  default:
>return 0;
>  }
> @@ -2507,6 +2513,13 @@ riscv_output_move (rtx dest, rtx src)
> return "fld\t%0,%1";
>   }
>  }
> +  if (dest_code == REG && GP_REG_P (REGNO (dest)) && src_code == 
> CONST_POLY_INT)
> +{
> +  /* we only want a single full vector register vlen
> +read after reload. */
> +  gcc_assert (known_eq (rtx_to_poly_int64 (src), 
> BYTES_PER_RISCV_VECTOR));
> +  return "csrr\t%0,vlenb";
> +}
>gcc_unreachable ();
>  }
>
> diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
> index 63bb3c8debc..2bfab198370 100644
> --- a/gcc/config/riscv/riscv.md
> +++ b/gcc/config/riscv/riscv.md
> @@ -148,7 +148,7 @@
>  ;; scheduling type to be "multi" instead.
>  (define_attr "move_type"
>"unknown,load,fpload,store,fpstore,mtc,mfc,move,fmove,
> -   const,logical,arith,andi,shift_shift"
> +   const,logical,arith,andi,shift_shift,rdvlenb"
>(const_string "unknown"))
>
>  ;; Main data type used by the insn
> @@ -166,6 +166,35 @@
>  (const_string "yes")]
> (const_string "no")))
>
> +;; ISA attributes.
> +(define_attr "ext" "base,f,d,vector"
> +  (const_string "base"))
> +
> +;; True if the extension is enabled.
> +(define_attr "ext_enabled" "no,yes"
> +  (cond [(eq_attr "ext" "base")
> +(const_string "yes")
> +
> +(and (eq_attr "ext" "f")
> + (match_test "TARGET_HARD_FLOAT"))
> +(const_string "yes")
> +
> +(and (eq_attr "ext" "d")
> + (match_test "TARGET_DOUBLE_FLOAT"))
> +(const_string "yes")
> +
> +(and (eq_attr "ext" "vector")
> + (match_test "TARGET_VECTOR"))
> +(const_string "yes")
> +   ]
> +   (const_string "no")))
> +
> +;; Attribute to control enable or disable instructions.
> +(define_attr "enabled" "no,yes"
> +  (cond [(eq_attr "ext_enabled" "no")
> +(const_string "no")]
> +   (const_string "yes")))
> +
>  ;; Classification of each insn.
>  ;; branch  conditional branch
>  ;; jumpunconditional jump
> @@ -326,7 +355,8 @@
>   (eq_attr "dword_mode" "yes"))
>(const_string "multi")
>  (eq_attr "move_type" "move") (const_string "move")
> -(eq_attr "move_type" "const") (const_string "const")]
> +(eq_attr "move_type" "const") (const_string "const")
> +(eq_attr "move_type" "rdvlenb") (const_string "rdvlenb")]
> (const_string "unknown")))
>
>  ;; Length of instruction in bytes.
> @@ -1633,24 +1663,26 @@
>  })
>
>  (define_insn "*movdi_32bit"
> -  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,m,  
> *f,*f,*r,*f,*m")
> -   (match_operand:DI 1 "move_operand" " 
> r,i,m,r,*J*r,*m,*f,*f,*f"))]
> +  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,m,  
> *f,*f,*r,*f,*m,r")
> +   (match_operand:DI 1 "move_operand" " 
> r,i,m,r,*J*r,*m,*f,*f,*f,vp"))]
>"!TARGET_64BIT
> && (register_operand (operands[0], DImode)
> || reg_or_0_operand (operands[1], DImode))"
>{ return riscv_output_move (operands[0], operands[1]); }
> -  [(set_attr "move_type" 
> "move,const,load,store,mtc,fpload,mfc,fmove,fpstore")
> -   (set_attr "mode" "DI")])
> +  [(set_attr "move_type" 
> "move,const,load,store,mtc,fpload,mfc,fmove,fpstore,rdvlenb")
> +   (set_attr "mode" "DI")
> +   (set_attr "ext" "base,base,base,base,d,d,d,d,d,vector")])
>
>  (define_insn "*movdi_64bit"
> -  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r, m,  
> *f,*f,*r,*f,*m")
> -   (match_operand:DI 1 "move_operand" " 
> r,T,m,rJ,*r*J,*m,*f,*f,*f"))]
> +  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r, m,  
> *f,*f,*r,*f,*m,r")
> +   (match_operand:DI 1 "move_operand" " 
> r,T,m,rJ,*r*J,*m,*f,*f,*f,vp"))]
>"TARGET_64BIT
> && (register_operand

Re: [PATCH] RISC-V: Add RVV constraints.

Thanks, committed!

On Tue, Aug 30, 2022 at 2:15 PM  wrote:
>
> From: zhongjuzhe 
>
> gcc/ChangeLog:
>
> * config/riscv/constraints.md (TARGET_VECTOR ? V_REGS : NO_REGS): Add 
> "vr" constraint.
> (TARGET_VECTOR ? VD_REGS : NO_REGS): Add "vd" constraint.
> (TARGET_VECTOR ? VM_REGS : NO_REGS): Add "vm" constraint.
> (vp): Add poly constraint.
>
> ---
>  gcc/config/riscv/constraints.md | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
> index 2873d533cb5..669e5ed734b 100644
> --- a/gcc/config/riscv/constraints.md
> +++ b/gcc/config/riscv/constraints.md
> @@ -108,3 +108,23 @@
> A constant @code{move_operand}."
>(and (match_operand 0 "move_operand")
> (match_test "CONSTANT_P (op)")))
> +
> +;; Vector constraints.
> +
> +(define_register_constraint "vr" "TARGET_VECTOR ? V_REGS : NO_REGS"
> +  "A vector register (if available).")
> +
> +(define_register_constraint "vd" "TARGET_VECTOR ? VD_REGS : NO_REGS"
> +  "A vector register except mask register (if available).")
> +
> +(define_register_constraint "vm" "TARGET_VECTOR ? VM_REGS : NO_REGS"
> +  "A vector mask register (if available).")
> +
> +;; This constraint is used to match instruction "csrr %0, vlenb" which is 
> generated in "mov".
> +;; VLENB is a run-time constant which represent the vector register length 
> in bytes.
> +;; BYTES_PER_RISCV_VECTOR represent runtime invariant of vector register 
> length in bytes.
> +;; We should only allow the poly equal to BYTES_PER_RISCV_VECTOR.
> +(define_constraint "vp"
> +  "POLY_INT"
> +  (and (match_code "const_poly_int")
> +   (match_test "known_eq (rtx_to_poly_int64 (op), 
> BYTES_PER_RISCV_VECTOR)")))
> \ No newline at end of file
> --
> 2.36.1
>

Re: [PATCH] RISC-V: Fix annotation

Thanks, pushed to trunk.

On Tue, Aug 30, 2022 at 10:58 AM  wrote:
>
> From: zhongjuzhe 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.h (enum reg_class): Change vype to vtype.
>
> ---
>  gcc/config/riscv/riscv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> index 29582f7c545..3ee5a93ce6a 100644
> --- a/gcc/config/riscv/riscv.h
> +++ b/gcc/config/riscv/riscv.h
> @@ -462,7 +462,7 @@ enum reg_class
>FP_REGS, /* floating-point registers */
>FRAME_REGS,  /* arg pointer and frame pointer */
>VL_REGS, /* vl register */
> -  VTYPE_REGS,  /* vype register */
> +  VTYPE_REGS,  /* vtype register */
>VM_REGS, /* v0.t registers */
>VD_REGS, /* vector registers except v0.t */
>V_REGS,  /* vector registers */
> --
> 2.36.1
>

Re: [PATCH] RISC-V: Fix riscv_vector_chunks configuration according to TARGET_MIN_VLEN

Thanks, pushed with a few minor style fixes.

On Tue, Aug 30, 2022 at 9:51 AM  wrote:
>
> From: zhongjuzhe 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_convert_vector_bits): Change 
> configuration according to TARGET_MIN_VLEN.
> * config/riscv/riscv.h (UNITS_PER_FP_REG): Fix annotation.
>
> ---
>  gcc/config/riscv/riscv.cc | 11 ++-
>  gcc/config/riscv/riscv.h  |  2 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 4d439e15392..ef606f33983 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -5219,14 +5219,15 @@ riscv_init_machine_status (void)
>  static poly_uint16
>  riscv_convert_vector_bits (void)
>  {
> -  /* The runtime invariant is only meaningful when vector is enabled. */
> +  /* The runtime invariant is only meaningful when TARGET_VECTOR is enabled. 
> */
>if (!TARGET_VECTOR)
>  return 0;
>
> -  if (TARGET_VECTOR_ELEN_64 || TARGET_VECTOR_ELEN_FP_64)
> +  if (TARGET_MIN_VLEN > 32)
>  {
> -  /* When targetting Zve64* (ELEN = 64) extensions, we should use 64-bit
> -chunk size. Runtime invariant: The single indeterminate represent the
> +  /* When targetting minimum VLEN > 32, we should use 64-bit chunk size.
> + Otherwise we can not include sew = 64bits.
> +Runtime invariant: The single indeterminate represent the
>  number of 64-bit chunks in a vector beyond minimum length of 64 bits.
>  Thus the number of bytes in a vector is 8 + 8 * x1 which is
>  riscv_vector_chunks * 8 = poly_int (8, 8). */
> @@ -5234,7 +5235,7 @@ riscv_convert_vector_bits (void)
>  }
>else
>  {
> -  /* When targetting Zve32* (ELEN = 32) extensions, we should use 32-bit
> +  /* When targetting minimum VLEN = 32, we should use 32-bit
>  chunk size. Runtime invariant: The single indeterminate represent the
>  number of 32-bit chunks in a vector beyond minimum length of 32 bits.
>  Thus the number of bytes in a vector is 4 + 4 * x1 which is
> diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> index 1d8139c2c9b..29582f7c545 100644
> --- a/gcc/config/riscv/riscv.h
> +++ b/gcc/config/riscv/riscv.h
> @@ -160,7 +160,7 @@ ASM_MISA_SPEC
>
>  /* The `Q' extension is not yet supported.  */
>  #define UNITS_PER_FP_REG (TARGET_DOUBLE_FLOAT ? 8 : 4)
> -/* Size per vector register. For zve32*, size = poly (4, 4). Otherwise, size 
> = poly (8, 8). */
> +/* Size per vector register. For VLEN = 32, size = poly (4, 4). Otherwise, 
> size = poly (8, 8). */
>  #define UNITS_PER_V_REG (riscv_vector_chunks * riscv_bytes_per_vector_chunk)
>
>  /* The largest type that can be passed in floating-point registers.  */
> --
> 2.36.1
>

[r13-2303 Regression] FAIL: g++.dg/tree-ssa/empty-loop.C -std=gnu++20 (test for excess errors) on Linux/x86_64

2022-08-31 Thread haochen.jiang via Gcc-patches

On Linux/x86_64,

b911ca4231a366ddfd026f190b126bd517f4e640 is the first bad commit
commit b911ca4231a366ddfd026f190b126bd517f4e640
Author: Jonathan Wakely 
Date:   Fri Aug 26 16:22:21 2022 +0100

libstdc++: Add [[nodiscard]] attribute to  and 

caused

FAIL: g++.dg/tree-ssa/empty-loop.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/tree-ssa/empty-loop.C  -std=gnu++20 (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-2303/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=g++.dg/tree-ssa/empty-loop.C --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=g++.dg/tree-ssa/empty-loop.C --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=g++.dg/tree-ssa/empty-loop.C --target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="dg.exp=g++.dg/tree-ssa/empty-loop.C --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com)

[r13-2288 Regression] FAIL: gcc.dg/vect/bb-slp-pr54400.c scan-tree-dump-not slp2 " = VEC_PERM_EXPR" on Linux/x86_64

2022-08-31 Thread haochen.jiang via Gcc-patches

On Linux/x86_64,

61c4c989034548f481d1f10198447be27fb9a55f is the first bad commit
commit 61c4c989034548f481d1f10198447be27fb9a55f
Author: Richard Sandiford 
Date:   Tue Aug 30 15:43:47 2022 +0100

Extend SLP permutation optimisations

caused

FAIL: gcc.dg/vect/bb-slp-pr54400.c -flto -ffat-lto-objects  scan-tree-dump-not 
slp2 " = VEC_PERM_EXPR"
FAIL: gcc.dg/vect/bb-slp-pr54400.c scan-tree-dump-not slp2 " = VEC_PERM_EXPR"

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-2288/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-pr54400.c --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-pr54400.c --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-pr54400.c --target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/bb-slp-pr54400.c --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com)

Re: [PATCH v2] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

On Wed, Aug 31, 2022 at 06:36:40PM -0500, Peter Bergner wrote:
> Changes from v1:
> * Fix spelling typo in git log entry
> * Fix broken test checking src_ptr's type
> * Use NOP_EXPR rather than VIEW_CONVERT_EXPR
> * Change order of dg-options
> 
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is cast to a valid MMA type, the type isn't passed down to the expand
> machinery and we end up using the base type of the pointer which leads to
> an ICE.  This patch enforces we always use the correct MMA type regardless
> of the pointer type being used.

Okay for trunk and all backports (after it has survived a breath of
fresh air).  Thanks!


Segher

[PATCH v2] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

Changes from v1:
* Fix spelling typo in git log entry
* Fix broken test checking src_ptr's type
* Use NOP_EXPR rather than VIEW_CONVERT_EXPR
* Change order of dg-options

When we expand an MMA disassemble built-in with C++ using a pointer that
is cast to a valid MMA type, the type isn't passed down to the expand
machinery and we end up using the base type of the pointer which leads to
an ICE.  This patch enforces we always use the correct MMA type regardless
of the pointer type being used.

This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk and backports after some burn-in time?

Peter

gcc/
PR target/101322
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_mma_builtin):
Enforce the use of a valid MMA pointer type.

gcc/testsuite/
PR target/101322
* g++.target/powerpc/pr101322.C: New test.

diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
b/gcc/config/rs6000/rs6000-builtin.cc
index 12afa86854c..e6948b9abb7 100644
--- a/gcc/config/rs6000/rs6000-builtin.cc
+++ b/gcc/config/rs6000/rs6000-builtin.cc
@@ -1085,7 +1085,12 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator 
*gsi,
   unsigned nvec = (fncode == RS6000_BIF_DISASSEMBLE_ACC) ? 4 : 2;
   tree dst_ptr = gimple_call_arg (stmt, 0);
   tree src_ptr = gimple_call_arg (stmt, 1);
-  tree src_type = TREE_TYPE (src_ptr);
+  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
+ ? build_pointer_type (vector_quad_type_node)
+ : build_pointer_type (vector_pair_type_node);
+  if (TREE_TYPE (src_ptr) != src_type)
+   src_ptr = build1 (NOP_EXPR, src_type, src_ptr);
+
   tree src = create_tmp_reg_or_ssa_name (TREE_TYPE (src_type));
   gimplify_assign (src, build_simple_mem_ref (src_ptr), _seq);
 
diff --git a/gcc/testsuite/g++.target/powerpc/pr101322.C 
b/gcc/testsuite/g++.target/powerpc/pr101322.C
new file mode 100644
index 000..43eaf3afcd4
--- /dev/null
+++ b/gcc/testsuite/g++.target/powerpc/pr101322.C
@@ -0,0 +1,17 @@
+/* PR target/101322 */
+/* { dg-require-effective-target power10_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
+
+/* Verify we don't ICE on the following test cases.  */
+
+void
+foo (char *resp, char *vpp)
+{
+  __builtin_vsx_disassemble_pair (resp, (__vector_pair *) vpp);
+}
+
+void
+bar (char *resp, char *vpp)
+{
+  __builtin_mma_disassemble_acc (resp, (__vector_quad *)vpp);
+}

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

On 8/31/22 6:08 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
>> The problem goes away if I use use -O1 or above, I drop -flto or I use
>> the code I originally posted without the ptr_vector_*_type
>>
>> The assert in gimple_canonical_types_compatible_p() we're hitting is:
>> 13673default:
>> 13674  /* Consider all types with language specific trees in 
>> them mutually
>> 13675 compatible.  This is executed only from verify_type 
>> and false
>> 13676 positives can be tolerated.  */
>> 13677  gcc_assert (!in_lto_p);
>> 13678  return true;
>>
>> I have no idea why ptr_vector_*_type would behave differently here than
>> build_pointer_type (vector_*_type_node).  Using the build_pointer_type()
>> fixed it for me, so that's why I went with it. :-)  Maybe this is a bug
>> in lto???
> 
> It looks like left-over debugging code.  Or this truly should never
> happen in LTO?

I have no idea.  Either way, I'm going to go with the code that works,
because either it's the "correct" code or it works around buggy code
in lto.  Either is a valid reason to me to use it.

Peter

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
> The problem goes away if I use use -O1 or above, I drop -flto or I use
> the code I originally posted without the ptr_vector_*_type
> 
> The assert in gimple_canonical_types_compatible_p() we're hitting is:
> 13673 default:
> 13674   /* Consider all types with language specific trees in them 
> mutually
> 13675  compatible.  This is executed only from verify_type and false
> 13676  positives can be tolerated.  */
> 13677   gcc_assert (!in_lto_p);
> 13678   return true;
> 
> I have no idea why ptr_vector_*_type would behave differently here than
> build_pointer_type (vector_*_type_node).  Using the build_pointer_type()
> fixed it for me, so that's why I went with it. :-)  Maybe this is a bug
> in lto???

It looks like left-over debugging code.  Or this truly should never
happen in LTO?


Segher

[committed] c: C2x attributes fixes and updates

Implement some changes to the currently supported C2x standard
attributes that have been made to the specification since they were
first implemented in GCC, and some consequent changes:

* maybe_unused is now supported on labels.  In fact that was already
  accidentally supported in GCC as a result of sharing the
  implementation with __attribute__ ((unused)), but needed to be
  covered in the tests.

* As part of the support for maybe_unused on labels, its
  __has_c_attribute value changed.

* The issue of maybe_unused accidentally being already supported on
  labels showed up the lack of tests for other standard attributes
  being incorrectly applied to labels; add such tests.

* Use of fallthrough or nodiscard attributes on labels already
  properly resulted in a pedwarn.  For the deprecated attribute,
  however, there was only a warning, and the wording "'deprecated'
  attribute ignored for 'void'" included an unhelpful "for 'void'".
  Arrange for the case of the deprecated attribute on a label to be
  checked for separately and result in a pedwarn.  As with
  inappropriate uses of fallthrough (see commit
  6c80b1b56dec2691436f3e2676e3d1b105b01b89), it seems reasonable for
  this pedwarn to apply regardless of whether [[]] or __attribute__
  was used and regardless of whether C or C++ is being compiled.

* Attributes on case or default labels (the standard syntax supports
  attributes on all kinds of labels) were quietly ignored, whether or
  not appropriate for use in such a context, because they weren't
  passed to decl_attributes at all.  (Note where I'm changing the
  do_case prototype that such a function is actually only defined in
  the C front end, not for C++, despite the declaration being in
  c-common.h.)

* A recent change as part of the editorial review in preparation for
  the C2x CD ballot has changed the __has_c_attribute value for
  fallthrough to 201910 to reflect when that attribute was actually
  voted into the working draft.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/c-family/
* c-attribs.cc (handle_deprecated_attribute): Check and pedwarn
for LABEL_DECL.
* c-common.cc (c_add_case_label): Add argument ATTRS.  Call
decl_attributes.
* c-common.h (do_case, c_add_case_label): Update declarations.
* c-lex.cc (c_common_has_attribute): For C, produce a result of
201910 for fallthrough and 202106 for maybe_unused.

gcc/c/
* c-parser.cc (c_parser_label): Pass attributes to do_case.
* c-typeck.cc (do_case): Add argument ATTRS.  Pass it to
c_add_case_label.

gcc/testsuite/
* gcc.dg/c2x-attr-deprecated-2.c, gcc.dg/c2x-attr-fallthrough-2.c,
gcc.dg/c2x-attr-maybe_unused-1.c, gcc.dg/c2x-attr-nodiscard-2.c:
Add tests of attributes on labels.
* gcc.dg/c2x-has-c-attribute-2.c: Update expected results for
maybe_unused and fallthrough.

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index e4f1d3542f3..8bb80e251dc 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -4163,6 +4163,13 @@ handle_deprecated_attribute (tree *node, tree name,
  || TREE_CODE (decl) == CONST_DECL
  || objc_method_decl (TREE_CODE (decl)))
TREE_DEPRECATED (decl) = 1;
+  else if (TREE_CODE (decl) == LABEL_DECL)
+   {
+ pedwarn (input_location, OPT_Wattributes, "%qE attribute ignored",
+  name);
+ *no_add_attrs = true;
+ return NULL_TREE;
+   }
   else
warn = 1;
 }
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 71fe7305369..1eb842e1c7b 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -5068,11 +5068,12 @@ case_compare (splay_tree_key k1, splay_tree_key k2)
CASES is a tree containing all the case ranges processed so far;
COND is the condition for the switch-statement itself.
Returns the CASE_LABEL_EXPR created, or ERROR_MARK_NODE if no
-   CASE_LABEL_EXPR is created.  */
+   CASE_LABEL_EXPR is created.  ATTRS are the attributes to be applied
+   to the label.  */
 
 tree
 c_add_case_label (location_t loc, splay_tree cases, tree cond,
- tree low_value, tree high_value)
+ tree low_value, tree high_value, tree attrs)
 {
   tree type;
   tree label;
@@ -5081,6 +5082,7 @@ c_add_case_label (location_t loc, splay_tree cases, tree 
cond,
 
   /* Create the LABEL_DECL itself.  */
   label = create_artificial_label (loc);
+  decl_attributes (, attrs, 0);
 
   /* If there was an error processing the switch condition, bail now
  before we get more confused.  */
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index e7b0fd1309d..64fe14b66fe 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -1018,7 +1018,7 @@ extern void c_parse_final_cleanups (void);
 /* True iff TYPE is cv decltype(nullptr).  */
 #define NULLPTR_TYPE_P(TYPE) (TREE_CODE (TYPE) ==

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

2022-08-31 Thread Kees Cook via Gcc-patches

On Wed, Aug 31, 2022 at 08:35:12PM +, Qing Zhao wrote:
> One of the major purposes of the new option -fstrict-flex-array is to 
> encourage standard conforming programming style. 
> 
> So, it might be reasonable to treat -fstrict-flex-array similar as -pedantic 
> (but only for flexible array members)? 
> If so, then issuing warnings when the standard doesn’t support is reasonable 
> and desirable. 

I guess the point is that "-std=c89 -fstrict-flex-arrays=3" leaves "[]"
available for use still? I think this doesn't matter. If someone wants
it to be really strict, they'd just add -Wpedantic.

-- 
Kees Cook

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 4:49 PM, Segher Boessenkool wrote:
> But it is incorrect as well.  Instead, we should look if -mpowerpc64 is
> enabled explicitly, and not change it if so.

Sure, I agree with checking for explicit use.  That said, I'll let
someone else work on this.

Peter

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

2022-08-31 Thread Kees Cook via Gcc-patches

On Wed, Aug 31, 2022 at 08:16:49PM +, Qing Zhao wrote:
> 
> > On Aug 31, 2022, at 4:09 PM, Joseph Myers  wrote:
> > 
> > On Wed, 31 Aug 2022, Qing Zhao wrote:
> > 
>  When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member 
>  [] is treated as a valid flexible array) present together,
> >>> 
> >>> That seems reasonable enough without a warning.  If people want a warning 
> >>> for flexible array members in older language modes, they can use 
> >>> -pedantic; I don't think we need to warn for any particular 
> >>> -fstrict-flex-array modes there.
> >> 
> >> So, you mean,
> >> 
> >> 1. GCC with -std=gnu89 support all [0], [1], and [] as Flexible array 
> >> member;
> >> 2. Therefore. -std=gnu89 + -fstrict-flex-array=3 does not need a warning;
> >> 
> >> ?
> > 
> > Yes.
> > 
> >> Then, how about:
> >> 
> >> -std=c89:
> >> 
> >> 1. GCC with -std=c89 also support all [0], [1], and [] as Flexible array 
> >> member;
> >> 2, therefore, -std=c89 + -fstrict-flex-array does not need a warning too.
> >> 
> >> ?
> > 
> > Yes.
> > 
> 
> Okay, I am fine with this.
> 
> Richard and Kees,  what’s your opinion on this?

Agreed: I think it's fine not to warn about these "conflicting" flags in
those cases. It looks like the C standard warnings about flexible arrays
are already hidden behind -Wpedantic, so nothing else is needed, IMO.
Using -fstrict-flex-arrays just enforces that warning. ;)

-- 
Kees Cook

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

On 8/31/22 3:51 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
>> Question for my own education, when would you use VIEW_CONVERT_EXPR over 
>> NOP_EXPR?
> 
> VIEW_CONVERT_EXPR is essentially a bit_cast.  Only use it when you need
> that, it is sub-optimal if you don't.

Ok.  I believe I added a couple of other similar uses of VIEW_CONVERT_EXPR for
pointer casts on the __builtin_vsx_lxvp/stxvp built-ins.  I'll try converting
those to use NOP_EXPR too in a separate cleanup patch.  Thanks!

>> -  tree src_type = TREE_TYPE (src_ptr);
>> +  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>> + ? ptr_vector_quad_type_node : 
>> ptr_vector_pair_type_node;
> 
> If you split a?b:c over multiple lines, please make it three lines.

Can do, however...

>> ...and of course, now I can't recreate that issue at all and the
>> ptr_vector_*_type use work fine now.  Strange! ...so ok, changed.
>> Maybe the behavior changed since my PR106017 fix went in???
> 
> That is my best guess as well.  But, how did that help this test?

It didn't. :-)   During my bootstrap, I hit the gimple verification issue
I mentioned seeing earlier.  My problem was I thought I hit it with the
test case, but it was exposed on a different test case in the testsuite.
Here's what I'm seeing, which only happens when using -O0 -flto:

rain6p1% gcc -O0 -mcpu=power10 -flto pr102347.c 
lto1: internal compiler error: in gimple_canonical_types_compatible_p, at 
tree.cc:13677
0x11930a97 gimple_canonical_types_compatible_p(tree_node const*, tree_node 
const*, bool)
/home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/tree.cc:13677
0x1192f1ab verify_type_variant
/home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/tree.cc:13377
0x11930beb verify_type(tree_node const*)
/home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/tree.cc:13700
0x106bbd37 lto_fixup_state
/home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/lto/lto-common.cc:2629
0x106bbff3 lto_fixup_decls
/home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/lto/lto-common.cc:2660
0x106bce13 read_cgraph_and_symbols(unsigned int, char const**)
/home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/lto/lto-common.cc:2901
0x1067bcbf lto_main()
/home/bergner/gcc/gcc-fsf-mainline-pr101322/gcc/lto/lto.cc:656
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: 
/home/bergner/gcc/build/gcc-fsf-mainline-pr101322-debug/gcc/xgcc returned 1 
exit status
compilation terminated.
/home/bergner/binutils/install/binutils-power10/bin/ld: error: lto-wrapper 
failed
collect2: error: ld returned 1 exit status

The problem goes away if I use use -O1 or above, I drop -flto or I use
the code I originally posted without the ptr_vector_*_type

The assert in gimple_canonical_types_compatible_p() we're hitting is:
13673   default:
13674 /* Consider all types with language specific trees in them 
mutually
13675compatible.  This is executed only from verify_type and false
13676positives can be tolerated.  */
13677 gcc_assert (!in_lto_p);
13678 return true;

I have no idea why ptr_vector_*_type would behave differently here than
build_pointer_type (vector_*_type_node).  Using the build_pointer_type()
fixed it for me, so that's why I went with it. :-)  Maybe this is a bug
in lto???

Peter

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On Wed, Aug 31, 2022 at 04:38:02PM -0500, Peter Bergner wrote:
> On 8/31/22 4:07 PM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
> >> Changing OS_MISSING_POWERPC64 as I mentioned would not add 
> >> OPTION_MASK_POWERPC64
> >> to our cpu masks when -m32 is used.
> > 
> > So you say this is where the bug is?
> 
> For linux64.h which is what I think the powerpc64-linux build will use,
> we have:
> 
> linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT
> 
> Doing the macro expansion by hand into:
> 
>   set_masks = POWERPC_MASKS;
> #ifdef OS_MISSING_POWERPC64
>   if (OS_MISSING_POWERPC64)
> set_masks &= ~OPTION_MASK_POWERPC64;
> #endif
> 
> 
> ...gives us:
> 
>   set_masks = POWERPC_MASKS;
>   if (!TARGET_64BIT)
> set_masks &= ~OPTION_MASK_POWERPC64;
> 
> So if we handled a -mpowerpc64 earlier on the command line and added
> OPTION_MASK_POWERPC64 to our cpu mask, then a following -m32 use will
> remove it here.
> 
> So I mentioned doing:
> 
> linux64.h:
> - #define OS_MISSING_POWERPC64 !TARGET_64BIT
> + #define OS_MISSING_POWERPC64 0
> 
> ...which disables the above code only for powerpc64-linux builds and doesn't
> affect AIX, Darwin, BSD, etc. or a powerpc-linux build.

But it is incorrect as well.  Instead, we should look if -mpowerpc64 is
enabled explicitly, and not change it if so.

> > The kernel has.  But there are user space things (glibc) that haven't
> > been fixed, and those are default as well.
> 
> Sure, but someone who is using -m32 -mpowerpc64 should know that and
> relying on a 32-bit glibc to save/restore the full 64-bit registers
> is a user error in my book.  If you're using -m32 -mpower64, you
> better know what you are doing and the limitations you have to live under.

Of course.  But -mpowerpc64 can never be any kind of default for 32-bit
Linux.  Not indirectly either.


Segher

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 4:07 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
>> Changing OS_MISSING_POWERPC64 as I mentioned would not add 
>> OPTION_MASK_POWERPC64
>> to our cpu masks when -m32 is used.
> 
> So you say this is where the bug is?

For linux64.h which is what I think the powerpc64-linux build will use,
we have:

linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT

Doing the macro expansion by hand into:

  set_masks = POWERPC_MASKS;
#ifdef OS_MISSING_POWERPC64
  if (OS_MISSING_POWERPC64)
set_masks &= ~OPTION_MASK_POWERPC64;
#endif

...gives us:

  set_masks = POWERPC_MASKS;
  if (!TARGET_64BIT)
set_masks &= ~OPTION_MASK_POWERPC64;

So if we handled a -mpowerpc64 earlier on the command line and added
OPTION_MASK_POWERPC64 to our cpu mask, then a following -m32 use will
remove it here.

So I mentioned doing:

linux64.h:
- #define OS_MISSING_POWERPC64 !TARGET_64BIT
+ #define OS_MISSING_POWERPC64 0

...which disables the above code only for powerpc64-linux builds and doesn't
affect AIX, Darwin, BSD, etc. or a powerpc-linux build.

> The kernel has.  But there are user space things (glibc) that haven't
> been fixed, and those are default as well.

Sure, but someone who is using -m32 -mpowerpc64 should know that and
relying on a 32-bit glibc to save/restore the full 64-bit registers
is a user error in my book.  If you're using -m32 -mpower64, you
better know what you are doing and the limitations you have to live under.

Peter

Re: [PATCH] Fortran 2018 rounding modes changes

> +  case GFC_FPE_GFC_FPE_AWAY:
> 
> typo?

Absolutely. Didn’t break the build because glibc currently doesn’t define 
FE_TONEARESTFROMZERO, but it should in the future (when C2x is included).

FX

[PATCH] c++: Micro-optimize most_specialized_partial_spec

2022-08-31 Thread Patrick Palka via Gcc-patches

This introduces an early exit test to most_specialized_partial_spec for
the common case where we have no partial specializations, which allows
us to avoid some unnecessary work.  In passing, clean the function up a
bit.

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

gcc/cp/ChangeLog:

* pt.cc (most_specialized_partial_spec): Exit early when
DECL_TEMPLATE_SPECIALIZATIONS is empty.  Move local variable
declarations closer to their first use.  Remove redundant
flag_concepts test.  Remove redundant forward declaration.
---
 gcc/cp/pt.cc | 45 +++--
 1 file changed, 19 insertions(+), 26 deletions(-)

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index fe7e809fc2d..497a18ef728 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -187,7 +187,6 @@ static int unify_pack_expansion (tree, tree, tree,
 static tree copy_template_args (tree);
 static tree tsubst_template_parms (tree, tree, tsubst_flags_t);
 static void tsubst_each_template_parm_constraints (tree, tree, tsubst_flags_t);
-tree most_specialized_partial_spec (tree, tsubst_flags_t);
 static tree tsubst_aggr_type (tree, tree, tsubst_flags_t, tree, int);
 static tree tsubst_arg_types (tree, tree, tree, tsubst_flags_t, tree);
 static tree tsubst_function_type (tree, tree, tsubst_flags_t, tree);
@@ -25756,15 +25755,7 @@ most_general_template (tree decl)
 tree
 most_specialized_partial_spec (tree target, tsubst_flags_t complain)
 {
-  tree list = NULL_TREE;
-  tree t;
-  tree champ;
-  int fate;
-  bool ambiguous_p;
-  tree outer_args = NULL_TREE;
-  tree tmpl, args;
-
-  tree decl;
+  tree tmpl, args, decl;
   if (TYPE_P (target))
 {
   tree tinfo = CLASSTYPE_TEMPLATE_INFO (target);
@@ -25788,13 +25779,18 @@ most_specialized_partial_spec (tree target, 
tsubst_flags_t complain)
   else
 gcc_unreachable ();
 
+  tree main_tmpl = most_general_template (tmpl);
+  tree specs = DECL_TEMPLATE_SPECIALIZATIONS (main_tmpl);
+  if (!specs)
+/* There are no partial specializations of this template.  */
+return NULL_TREE;
+
   push_access_scope_guard pas (decl);
   deferring_access_check_sentinel acs (dk_no_deferred);
 
-  tree main_tmpl = most_general_template (tmpl);
-
   /* For determining which partial specialization to use, only the
  innermost args are interesting.  */
+  tree outer_args = NULL_TREE;
   if (TMPL_ARGS_HAVE_MULTIPLE_LEVELS (args))
 {
   outer_args = strip_innermost_template_args (args, 1);
@@ -25806,7 +25802,8 @@ most_specialized_partial_spec (tree target, 
tsubst_flags_t complain)
  fully resolve everything.  */
   processing_template_decl_sentinel ptds;
 
-  for (t = DECL_TEMPLATE_SPECIALIZATIONS (main_tmpl); t; t = TREE_CHAIN (t))
+  tree list = NULL_TREE;
+  for (tree t = specs; t; t = TREE_CHAIN (t))
 {
   const tree ospec_tmpl = TREE_VALUE (t);
 
@@ -25829,10 +25826,8 @@ most_specialized_partial_spec (tree target, 
tsubst_flags_t complain)
  if (outer_args)
spec_args = add_to_template_args (outer_args, spec_args);
 
-  /* Keep the candidate only if the constraints are satisfied,
- or if we're not compiling with concepts.  */
-  if (!flag_concepts
- || constraints_satisfied_p (ospec_tmpl, spec_args))
+ /* Keep the candidate only if the constraints are satisfied.  */
+ if (constraints_satisfied_p (ospec_tmpl, spec_args))
 {
  list = tree_cons (spec_args, ospec_tmpl, list);
   TREE_TYPE (list) = TREE_TYPE (t);
@@ -25843,13 +25838,11 @@ most_specialized_partial_spec (tree target, 
tsubst_flags_t complain)
   if (! list)
 return NULL_TREE;
 
-  ambiguous_p = false;
-  t = list;
-  champ = t;
-  t = TREE_CHAIN (t);
-  for (; t; t = TREE_CHAIN (t))
+  tree champ = list;
+  bool ambiguous_p = false;
+  for (tree t = TREE_CHAIN (list); t; t = TREE_CHAIN (t))
 {
-  fate = more_specialized_partial_spec (tmpl, champ, t);
+  int fate = more_specialized_partial_spec (tmpl, champ, t);
   if (fate == 1)
;
   else
@@ -25868,9 +25861,9 @@ most_specialized_partial_spec (tree target, 
tsubst_flags_t complain)
 }
 
   if (!ambiguous_p)
-for (t = list; t && t != champ; t = TREE_CHAIN (t))
+for (tree t = list; t && t != champ; t = TREE_CHAIN (t))
   {
-   fate = more_specialized_partial_spec (tmpl, champ, t);
+   int fate = more_specialized_partial_spec (tmpl, champ, t);
if (fate != 1)
  {
ambiguous_p = true;
@@ -25889,7 +25882,7 @@ most_specialized_partial_spec (tree target, 
tsubst_flags_t complain)
   else
error ("ambiguous template instantiation for %q#D", target);
   str = ngettext ("candidate is:", "candidates are:", list_length (list));
-  for (t = list; t; t = TREE_CHAIN (t))
+  for (tree t = list; t; t = TREE_CHAIN (t))
 {
  tree subst = build_tree_list (TREE_VALUE (t), TREE_PURPOSE (t));

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
> On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> Right, but haven't the 64-bit Linux kernels been fixed forever to always
> save/restore the full 64-bit hardware registers on a context switch/signal?

The kernel has.  But there are user space things (glibc) that haven't
been fixed, and those are default as well.

> If not, them this whole thing is moot and the current behavior of disabling
> -mpower64 if we use -m32 later on the command line is the correct thing to do.

The kernel has no way of disabling -mpowerpc64.  The instructions are
valid on any CPU that supports them, whether SF=1 or SF=0.

> > But we should not enable -mpowerpc64 on 32-bit Linux by default.
> 
> I didn't imply we should do that.  I was only agreeing with you that
> we should try not disabling an explicit -mpowerpc64 when -m32 is used
> later on the command line.

Okay, glad we agree :-)

> I only meant to say is that the code in rs6000_option_override_internal() is 
> what
> seems to remove the OPTION_MASK_POWERPC64 from our cpu mask when -m32 is used
> later on the command line... and that is controlled by OS_MISSING_POWERPC64.

This is the default mask only here.

> Changing OS_MISSING_POWERPC64 as I mentioned would not add 
> OPTION_MASK_POWERPC64
> to our cpu masks when -m32 is used.

So you say this is where the bug is?


Segher

[PATCH] ipa: Fix throw in multi-versioned functions [PR106627]

2022-08-31 Thread Simon Rainer

Hi,

This patch fixes PR106627. I ran the i386.exp tests on my x86_64-linux-gnu 
machine with a fully bootstrapped checkout. I also tested manually that no 
exception handling code is generated if none of the function versions throws an 
exception.
I don't have access to a machine to test the change to  rs6000.cc, but the code 
seems like an exact copy and I don't see a reason why it shouldn't work there 
the same way.

Regards
Simon Rainer

>From 6fcb1c742fa1d61048f7d63243225a8d1931af4a Mon Sep 17 00:00:00 2001
From: Simon Rainer 
Date: Wed, 31 Aug 2022 20:56:04 +0200
Subject: [PATCH] ipa: Fix throw in multi-versioned functions [PR106627]

Any multi-versioned function was implicitly declared as noexcept, which
leads to an abort if an exception is thrown inside the function.
The reason for this is that the function declaration is replaced by a
newly created dispatcher declaration, which has TREE_NOTHROW always set
to 1. Instead we need to set TREE_NOTHROW to the value of the original
declaration.

PR ipa/106627

gcc/ChangeLog:

* config/i386/i386-features.cc (ix86_get_function_versions_dispatcher): 
Set TREE_NOTHROW
correctly for dispatcher declaration
* config/rs6000/rs6000.cc (rs6000_get_function_versions_dispatcher): 
Likewise

gcc/testsuite/ChangeLog:

* g++.target/i386/pr106627.C: New test.
---
 gcc/config/i386/i386-features.cc |  1 +
 gcc/config/rs6000/rs6000.cc  |  1 +
 gcc/testsuite/g++.target/i386/pr106627.C | 30 
 3 files changed, 32 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/i386/pr106627.C

diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc
index d6bb66cbe01..5b3b1aeff28 100644
--- a/gcc/config/i386/i386-features.cc
+++ b/gcc/config/i386/i386-features.cc
@@ -3268,6 +3268,7 @@ ix86_get_function_versions_dispatcher (void *decl)
 
   /* Right now, the dispatching is done via ifunc.  */
   dispatch_decl = make_dispatcher_decl (default_node->decl);
+  TREE_NOTHROW(dispatch_decl) = TREE_NOTHROW(fn);
 
   dispatcher_node = cgraph_node::get_create (dispatch_decl);
   gcc_assert (dispatcher_node != NULL);
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 2f3146e56f8..9280da8a5c8 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -24861,6 +24861,7 @@ rs6000_get_function_versions_dispatcher (void *decl)
 
   /* Right now, the dispatching is done via ifunc.  */
   dispatch_decl = make_dispatcher_decl (default_node->decl);
+  TREE_NOTHROW(dispatch_decl) = TREE_NOTHROW(fn);
 
   dispatcher_node = cgraph_node::get_create (dispatch_decl);
   gcc_assert (dispatcher_node != NULL);
diff --git a/gcc/testsuite/g++.target/i386/pr106627.C 
b/gcc/testsuite/g++.target/i386/pr106627.C
new file mode 100644
index 000..a67f5ae4813
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/pr106627.C
@@ -0,0 +1,30 @@
+/* PR c++/103012 Exception handling with multiversioned functions */
+/* { dg-do run } */
+/* { dg-require-ifunc "" }  */
+
+#include 
+
+__attribute__((target("default")))
+void f() {
+throw 1;
+}
+
+__attribute__((target("sse4.2,bmi")))
+void f() {
+throw 2;
+}
+
+int main()
+{
+try {
+f();
+}
+catch(...)
+{
+return 0;
+}
+
+assert (false);
+return 1;
+}
+
-- 
2.34.1

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

2022-08-31 Thread Bernhard Reutner-Fischer via Gcc-patches

On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
> ...and of course, now I can't recreate that issue at all and the
> ptr_vector_*_type use work fine now.  Strange! ...so ok, changed.
> Maybe the behavior changed since my PR106017 fix went in???

That is my best guess as well.  But, how did that help this test?

> Question for my own education, when would you use VIEW_CONVERT_EXPR over 
> NOP_EXPR?

VIEW_CONVERT_EXPR is essentially a bit_cast.  Only use it when you need
that, it is sub-optimal if you don't.

> FYI, here is the current code patch with all of the suggested changes 
> incorporated:

> --- a/gcc/config/rs6000/rs6000-builtin.cc
> +++ b/gcc/config/rs6000/rs6000-builtin.cc
> @@ -1085,7 +1085,11 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator 
> *gsi,
>unsigned nvec = (fncode == RS6000_BIF_DISASSEMBLE_ACC) ? 4 : 2;
>tree dst_ptr = gimple_call_arg (stmt, 0);
>tree src_ptr = gimple_call_arg (stmt, 1);
> -  tree src_type = TREE_TYPE (src_ptr);
> +  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
> + ? ptr_vector_quad_type_node : ptr_vector_pair_type_node;

If you split a?b:c over multiple lines, please make it three lines.


Segher

Re: [PATCH] Fortran 2018 rounding modes changes

On 31 August 2022 20:29:12 CEST, FX via Fortran  wrote:


+  case GFC_FPE_GFC_FPE_AWAY:

typo?

thanks,

Re: [PATCH 2/2] RISC-V: remove CM_PIC as it doesn't do much

2022-08-31 Thread Vineet Gupta





On 8/31/22 07:57, Palmer Dabbelt wrote:

   if (flag_pic)
-    riscv_cmodel = CM_PIC;
+    riscv_cmodel = CM_MEDANY;

   /* We get better code with explicit relocs for CM_MEDLOW, but
  worse code for the others (for now).  Pick the best default.  */


I'm fine either way on this one: having CM_PIC gone makes it a bit 
more likely to confuse CM_MEDANY with PIC, but flag_pic is overriding 
riscv_cmodel anyway so this isn't really used and deleting code is 
always a plus.


Indeed this was the most contentious part of removing CM_PIC, but it 
seems this is the way fwd. I'll add Kito's comment from [1] in code to 
make it more explicit.


[1]https://github.com/riscv-non-isa/riscv-c-api-doc/pull/11#issuecomment-686385585 



Thx,
-Vineett

Re: [PATCH 1/2] RISC-V: remove deprecate pic code model macro

2022-08-31 Thread Vineet Gupta


On 8/31/22 07:57, Palmer Dabbelt wrote:

On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:

Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code

Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/riscv-c.cc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index eb7ef09297e9..bba72cf77a82 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -93,9 +93,6 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
   break;

 case CM_PIC:
-  /* __riscv_cmodel_pic is deprecated, and will removed in next 
GCC release.

- see https://github.com/riscv/riscv-c-api-doc/pull/11  */
-  builtin_define ("__riscv_cmodel_pic");
   /* FALLTHROUGH. */

 case CM_MEDANY:


It looks like some of the tests
(gcc/testsuite/gcc.target/riscv/predef-3.c, for example) are checking
for __riscv_cmodel_pic.  From looking at them I'd expect them to fail,
but even if they're not we should clean them up.


Aah, I did miss removing them and looks like there was a snafu in my 
test setup as well.
I'm rerunning the tests with the fix and will post a v2 after tests come 
out clean.


Thx,
-Vineet

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array



> On Aug 31, 2022, at 4:16 PM, Qing Zhao via Gcc-patches 
>  wrote:
> 
> Okay, I am fine with this.

Another thought on this is:

One of the major purposes of the new option -fstrict-flex-array is to encourage 
standard conforming programming style. 

So, it might be reasonable to treat -fstrict-flex-array similar as -pedantic 
(but only for flexible array members)? 
If so, then issuing warnings when the standard doesn’t support is reasonable 
and desirable. 

(I guess that this is the original motivation to add such warnings).

Qing
> 
> Richard and Kees,  what’s your opinion on this?
> 
> thanks.
> 
> Qing
> 
>> On Aug 31, 2022, at 4:09 PM, Joseph Myers  wrote:
>> 
>> On Wed, 31 Aug 2022, Qing Zhao wrote:
>> 
> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member 
> [] is treated as a valid flexible array) present together,
 
 That seems reasonable enough without a warning.  If people want a warning 
 for flexible array members in older language modes, they can use 
 -pedantic; I don't think we need to warn for any particular 
 -fstrict-flex-array modes there.
>>> 
>>> So, you mean,
>>> 
>>> 1. GCC with -std=gnu89 support all [0], [1], and [] as Flexible array 
>>> member;
>>> 2. Therefore. -std=gnu89 + -fstrict-flex-array=3 does not need a warning;
>>> 
>>> ?
>> 
>> Yes.
>> 
>>> Then, how about:
>>> 
>>> -std=c89:
>>> 
>>> 1. GCC with -std=c89 also support all [0], [1], and [] as Flexible array 
>>> member;
>>> 2, therefore, -std=c89 + -fstrict-flex-array does not need a warning too.
>>> 
>>> ?
>> 
>> Yes.
>> 
>> -- 
>> Joseph S. Myers
>> jos...@codesourcery.com
>

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

Okay, I am fine with this.

Richard and Kees,  what’s your opinion on this?

thanks.

Qing

> On Aug 31, 2022, at 4:09 PM, Joseph Myers  wrote:
> 
> On Wed, 31 Aug 2022, Qing Zhao wrote:
> 
 When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member 
 [] is treated as a valid flexible array) present together,
>>> 
>>> That seems reasonable enough without a warning.  If people want a warning 
>>> for flexible array members in older language modes, they can use 
>>> -pedantic; I don't think we need to warn for any particular 
>>> -fstrict-flex-array modes there.
>> 
>> So, you mean,
>> 
>> 1. GCC with -std=gnu89 support all [0], [1], and [] as Flexible array member;
>> 2. Therefore. -std=gnu89 + -fstrict-flex-array=3 does not need a warning;
>> 
>> ?
> 
> Yes.
> 
>> Then, how about:
>> 
>> -std=c89:
>> 
>> 1. GCC with -std=c89 also support all [0], [1], and [] as Flexible array 
>> member;
>> 2, therefore, -std=c89 + -fstrict-flex-array does not need a warning too.
>> 
>> ?
> 
> Yes.
> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

[committed] testsuite: Fix warning regression due to std::string changes [PR106795]

I missed this testsuite fix in the libstdc++ commit.

Tested x86_64-linux, pushed to trunk.

-- >8 --

std::string now has [[nodiscard]] attributes on most members, causing
-Wunused-result warnings for this test.

gcc/testsuite/ChangeLog:

PR testsuite/106795
* g++.dg/tree-ssa/empty-loop.C: Use -Wno-unused-result.
---
 gcc/testsuite/g++.dg/tree-ssa/empty-loop.C | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C 
b/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C
index 6b1e879e6a9..dca7868f3c9 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/empty-loop.C
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-cddce2 -ffinite-loops" } */
+/* { dg-options "-O2 -fdump-tree-cddce2 -ffinite-loops -Wno-unused-result" } */
 
 #include 
 #include 
-- 
2.37.2

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, 31 Aug 2022, Qing Zhao wrote:

> >> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member 
> >> [] is treated as a valid flexible array) present together,
> > 
> > That seems reasonable enough without a warning.  If people want a warning 
> > for flexible array members in older language modes, they can use 
> > -pedantic; I don't think we need to warn for any particular 
> > -fstrict-flex-array modes there.
> 
> So, you mean,
> 
> 1. GCC with -std=gnu89 support all [0], [1], and [] as Flexible array member;
> 2. Therefore. -std=gnu89 + -fstrict-flex-array=3 does not need a warning;
> 
> ?

Yes.

> Then, how about:
> 
> -std=c89:
> 
> 1. GCC with -std=c89 also support all [0], [1], and [] as Flexible array 
> member;
> 2, therefore, -std=c89 + -fstrict-flex-array does not need a warning too.
> 
> ?

Yes.

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

Re: [PATCH] libstdc++: A few more minor cleanups

On Wed, 31 Aug 2022 at 20:27, Patrick Palka via Libstdc++
 wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

OK, thanks.

Re: [PATCH] Add _GLIBCXX_DEBUG backtrace generation

On Wed, 31 Aug 2022 at 20:33, François Dumont  wrote:
>
> On 31/08/22 12:11, Jonathan Wakely wrote:
> > On Wed, 31 Aug 2022 at 06:05, François Dumont  wrote:
> >> After a second thought here is an even cleaner version. No more function
> >> rename, current pretty_print is fine.
> >>
> >>   libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
> >>
> >> Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace
> >> generation on
> >>   _GLIBCXX_DEBUG assertions. Prerequisite is to have configure the
> >> lib with:
> >>
> >>   --enable-libstdcxx-backtrace=yes
> >>
> >>   libstdc++-v3/ChangeLog:
> >>
> >>   * include/debug/formatter.h
> >>   [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_state): 
> >> Declare.
> >> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_create_state): Declare.
> >> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_callback): Define.
> >> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_error_callback): Define.
> >> [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_func): Define.
> >>   [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full): 
> >> Declare.
> >> [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_state): New.
> >> [_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_full): New.
> >>   * src/c++11/debug.cc
> >> [_GLIBCXX_HAVE_STACKTRACE](print_backtrace): New.
> >>   (_Error_formatter::_M_error()): Adapt.
> >>   * src/libbacktrace/Makefile.am: Add backtrace.c.
> >>   * src/libbacktrace/Makefile.in: Regenerate.
> >>   * src/libbacktrace/backtrace-rename.h (backtrace_full): New.
> >>   *
> >> testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc: New test.
> >>   * doc/xml/manual/debug_mode.xml: Document
> >> _GLIBCXX_DEBUG_BACKTRACE.
> >>   * doc/xml/manual/using.xml: Likewise.
> >> Ok to commit ?
> > OK for trunk, thanks.
> >
> > The small change to print_raw in this patch makes me wonder whether
> > that function is actually useful.
> >
> > It supports two modes, print with max precision, and print without.
> > The only time we use it to print with max precision we pass a string
> > of exactly the right length, so the precision is not needed (but the
> > caller has to get the string length correct: if we increase _S_indent
> > and do not increase the "" literal passed to print_raw, the
> > effects would be wrong).
> >
> > Wouldn't it be better to just use fprintf directly when we want to
> > print without precision, and use a minimum field width instead of
> > precision for indenting? i.e. ...
> >
> > --- a/libstdc++-v3/src/c++11/debug.cc
> > +++ b/libstdc++-v3/src/c++11/debug.cc
> > @@ -608,15 +608,6 @@ namespace
> >  print_literal(PrintContext& ctx, const char()[Length])
> >  { print_word(ctx, word, Length - 1); }
> >
> > -  void
> > -  print_raw(PrintContext& ctx, const char* str, ptrdiff_t nbc = -1)
> > -  {
> > -if (nbc >= 0)
> > -  ctx._M_column += fprintf(stderr, "%.*s", (int)nbc, str);
> > -else
> > -  ctx._M_column += fprintf(stderr, "%s", str);
> > -  }
> > -
> >void
> >print_word(PrintContext& ctx, const char* word, ptrdiff_t nbc = -1)
> >{
> > @@ -643,12 +634,9 @@ namespace
> > || (ctx._M_column + visual_length < ctx._M_max_length)
> > || (visual_length >= ctx._M_max_length && ctx._M_column == 1))
> >{
> > -   // If this isn't the first line, indent
> > +   // If this isn't the first line, indent.
> > if (ctx._M_column == 1 && !ctx._M_first_line)
> > - {
> > -   const char spacing[PrintContext::_S_indent + 1] = "";
> > -   print_raw(ctx, spacing, PrintContext::_S_indent);
> > - }
> > + ctx._M_column += fprintf(stderr, "%*c", PrintContext::_S_indent, 
> > ' ');
> I did not know this syntax, it looks definitely better.
> >
> > int written = fprintf(stderr, "%.*s", (int)length, word);
> >
> > @@ -1112,7 +1100,7 @@ namespace __gnu_debug
> >  PrintContext ctx;
> >  if (_M_file)
> >{
> > -   print_raw(ctx, _M_file);
> > +   ctx._M_column += fprintf(stderr, "%s", _M_file);
> > print_literal(ctx, ":");
> > go_to_next_line = true;
> >}
> >
> Do you take care or you prefer I do ?


I can do it.

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array




> On Aug 31, 2022, at 3:52 PM, Joseph Myers  wrote:
> 
> On Wed, 31 Aug 2022, Qing Zhao wrote:
> 
>> Does the above mean that -std=gnu89 does not support C99 flexible array 
>> member, then
> 
> No.
> 
> Flexible array members are supported by GCC in all C standards modes.  The 
> C90 standard doesn't support them, but that's irrelevant to what GCC 
> supports; it just means a diagnostic is required for strict conformance in 
> pre-C99 modes.

Okay.

> 
>> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member 
>> [] is treated as a valid flexible array) present together,
> 
> That seems reasonable enough without a warning.  If people want a warning 
> for flexible array members in older language modes, they can use 
> -pedantic; I don't think we need to warn for any particular 
> -fstrict-flex-array modes there.

So, you mean,

1. GCC with -std=gnu89 support all [0], [1], and [] as Flexible array member;
2. Therefore. -std=gnu89 + -fstrict-flex-array=3 does not need a warning;

?

Then, how about:

-std=c89:

1. GCC with -std=c89 also support all [0], [1], and [] as Flexible array member;
2, therefore, -std=c89 + -fstrict-flex-array does not need a warning too.

?


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

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> No.  Instead, it just works!
> 
> Try this:
> ===
> typedef float vf __attribute__((vector_size(16)));
> vf f(float x)
> {
>   x *= 42;
>   return (vf){x, x, x, x};
> }
> ===
> with -maltivec -msoft-float.  It does not use the FPRs, and it does use
> the VMX registers and VMX instructions.

Well color me surprised!

>> linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT
> 
> That macro returns 1 on OSes that do not properly support -mpowerpc64.

Right, but haven't the 64-bit Linux kernels been fixed forever to always
save/restore the full 64-bit hardware registers on a context switch/signal?
If not, them this whole thing is moot and the current behavior of disabling
-mpower64 if we use -m32 later on the command line is the correct thing to do.

> But we should not enable -mpowerpc64 on 32-bit Linux by default.

I didn't imply we should do that.  I was only agreeing with you that
we should try not disabling an explicit -mpowerpc64 when -m32 is used
later on the command line.

I only meant to say is that the code in rs6000_option_override_internal() is 
what
seems to remove the OPTION_MASK_POWERPC64 from our cpu mask when -m32 is used
later on the command line... and that is controlled by OS_MISSING_POWERPC64.
Changing OS_MISSING_POWERPC64 as I mentioned would not add OPTION_MASK_POWERPC64
to our cpu masks when -m32 is used.

Peter

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, 31 Aug 2022, Qing Zhao wrote:

> Does the above mean that -std=gnu89 does not support C99 flexible array 
> member, then

No.

Flexible array members are supported by GCC in all C standards modes.  The 
C90 standard doesn't support them, but that's irrelevant to what GCC 
supports; it just means a diagnostic is required for strict conformance in 
pre-C99 modes.

> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member 
> [] is treated as a valid flexible array) present together,

That seems reasonable enough without a warning.  If people want a warning 
for flexible array members in older language modes, they can use 
-pedantic; I don't think we need to warn for any particular 
-fstrict-flex-array modes there.

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

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array



> On Aug 31, 2022, at 3:29 PM, Joseph Myers  wrote:
> 
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> 
>>> How is level 3 (thus -fstrict-flex-array) interpreted when you specify 
>>> -std=c89?  How for -std=gnu89?
>> 
>> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible 
>> array? (Checked online, cannot find a concrete answer on this).
>>  ** my understanding is:   -std=c89 will not support any flexible array 
>> (neither [], [0], [1]), but -std=gnu89 will support [0] and [1], but not [].
>>Is this correct?
> 
> Flexible array members are supported in all C standard modes, since they 
> don't affect the semantics of any valid pre-C99 program (only make valid 
> programs that were previously erroneous).
> 
> With -std=c89 or -std=gnu89, -pedantic will give a warning "ISO C90 does 
> not support flexible array members" and -pedantic-errors will change that 
> to an error.

A little confused here…

With both -std=c89 and -std=gnu89, -pedantic will warning on “[]” (C99 flexible 
array member):

[opc@qinzhao-ol8u3-x86 ~]$ gcc -std=c89 t.c  -pedantic
t.c:5:7: warning: ISO C90 does not support flexible array members [-Wpedantic]
5 |   int b[];
  |   ^
[opc@qinzhao-ol8u3-x86 ~]$ gcc -std=gnu89 t.c  -pedantic
t.c:5:7: warning: ISO C90 does not support flexible array members [-Wpedantic]
5 |   int b[];
  |   ^

Does the above mean that -std=gnu89 does not support C99 flexible array member, 
 then

When -std=gnu89 + -fstrict-flex-array=3  (ONLY C99 flexible array member [] is 
treated as a valid flexible array) present together, 

It should be reasonable to issue warning on this?  (-fstrict-flex-arrays=3 
is not supported by GNU extension GNU89, ignored)

Right?

Qing




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

Re: [PATCH] Add _GLIBCXX_DEBUG backtrace generation

2022-08-31 Thread François Dumont via Gcc-patches


On 31/08/22 12:11, Jonathan Wakely wrote:

On Wed, 31 Aug 2022 at 06:05, François Dumont  wrote:

After a second thought here is an even cleaner version. No more function
rename, current pretty_print is fine.

  libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand

Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace
generation on
  _GLIBCXX_DEBUG assertions. Prerequisite is to have configure the
lib with:

  --enable-libstdcxx-backtrace=yes

  libstdc++-v3/ChangeLog:

  * include/debug/formatter.h
  [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_state): Declare.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_create_state): Declare.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_callback): Define.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_error_callback): Define.
[_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full_func): Define.
  [_GLIBCXX_HAVE_STACKTRACE](__glibcxx_backtrace_full): Declare.
[_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_state): New.
[_GLIBCXX_HAVE_STACKTRACE](_Error_formatter::_M_backtrace_full): New.
  * src/c++11/debug.cc
[_GLIBCXX_HAVE_STACKTRACE](print_backtrace): New.
  (_Error_formatter::_M_error()): Adapt.
  * src/libbacktrace/Makefile.am: Add backtrace.c.
  * src/libbacktrace/Makefile.in: Regenerate.
  * src/libbacktrace/backtrace-rename.h (backtrace_full): New.
  *
testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc: New test.
  * doc/xml/manual/debug_mode.xml: Document
_GLIBCXX_DEBUG_BACKTRACE.
  * doc/xml/manual/using.xml: Likewise.
Ok to commit ?

OK for trunk, thanks.

The small change to print_raw in this patch makes me wonder whether
that function is actually useful.

It supports two modes, print with max precision, and print without.
The only time we use it to print with max precision we pass a string
of exactly the right length, so the precision is not needed (but the
caller has to get the string length correct: if we increase _S_indent
and do not increase the "" literal passed to print_raw, the
effects would be wrong).

Wouldn't it be better to just use fprintf directly when we want to
print without precision, and use a minimum field width instead of
precision for indenting? i.e. ...

--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -608,15 +608,6 @@ namespace
 print_literal(PrintContext& ctx, const char()[Length])
 { print_word(ctx, word, Length - 1); }

-  void
-  print_raw(PrintContext& ctx, const char* str, ptrdiff_t nbc = -1)
-  {
-if (nbc >= 0)
-  ctx._M_column += fprintf(stderr, "%.*s", (int)nbc, str);
-else
-  ctx._M_column += fprintf(stderr, "%s", str);
-  }
-
   void
   print_word(PrintContext& ctx, const char* word, ptrdiff_t nbc = -1)
   {
@@ -643,12 +634,9 @@ namespace
|| (ctx._M_column + visual_length < ctx._M_max_length)
|| (visual_length >= ctx._M_max_length && ctx._M_column == 1))
   {
-   // If this isn't the first line, indent
+   // If this isn't the first line, indent.
if (ctx._M_column == 1 && !ctx._M_first_line)
- {
-   const char spacing[PrintContext::_S_indent + 1] = "";
-   print_raw(ctx, spacing, PrintContext::_S_indent);
- }
+ ctx._M_column += fprintf(stderr, "%*c", PrintContext::_S_indent, ' ');

I did not know this syntax, it looks definitely better.


int written = fprintf(stderr, "%.*s", (int)length, word);

@@ -1112,7 +1100,7 @@ namespace __gnu_debug
 PrintContext ctx;
 if (_M_file)
   {
-   print_raw(ctx, _M_file);
+   ctx._M_column += fprintf(stderr, "%s", _M_file);
print_literal(ctx, ":");
go_to_next_line = true;
   }


Do you take care or you prefer I do ?

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> >> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
> > 
> > Oh?  Why should it disable -maltivec?  -mvsx makes a little sense on
> > one hand, but totally none on the other either.
> 
> VSX has to be disabled, since VSX replies on the FP registers existing.

It doesn't?  On a CPU supporting VSX the FP registers are overlaid on
the VSX registers, not the other way around.

GCC says
  cc1: warning: '-mvsx' requires hardware floating point
and that's okay with me of course, but it doesn't say why it is
required.  Implementation convenience coupled with lack of a use case
is my best guess :-)

OTOH VMX and hard float are completely orthogonal (the VMX FP things do
not even use the fpscr for example).

> As for Altivec, I'm pretty sure there are some inherent dependencies
> there, probably both in hardware and our GCC backend implementation.
> I could be wrong, but my guess is things will fall over the ground
> if as allow -maltivec along with -msoft-float.  Does the linux kernel
> only build with -msoft-float assuming it disables altivec and vsx?
> Or does it explicitly always also add -mno-altivec?

No.  Instead, it just works!

Try this:
===
typedef float vf __attribute__((vector_size(16)));
vf f(float x)
{
x *= 42;
return (vf){x, x, x, x};
}
===
with -maltivec -msoft-float.  It does not use the FPRs, and it does use
the VMX registers and VMX instructions.

> So in linux*.h, we have the following which came from a 2004 commit from Alan:
> 
> linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT

That macro returns 1 on OSes that do not properly support -mpowerpc64.

> ...so I think there was no real reason, other than old 64-bit linux kernels 
> didn't
> save the upper register state in 32-bit mode binaries.

And it is still not saved in 32-bit user mode (setjmp/longjmp and
getcontext/setcontext).  Most bigger programs will fail, and most
smaller programs (including everything in the GCC testsuite) work fine.
But we should not enable -mpowerpc64 on 32-bit Linux by default.

Segher

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:

> > How is level 3 (thus -fstrict-flex-array) interpreted when you specify 
> > -std=c89?  How for -std=gnu89?
> 
> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible 
> array? (Checked online, cannot find a concrete answer on this).
>   ** my understanding is:   -std=c89 will not support any flexible array 
> (neither [], [0], [1]), but -std=gnu89 will support [0] and [1], but not [].
> Is this correct?

Flexible array members are supported in all C standard modes, since they 
don't affect the semantics of any valid pre-C99 program (only make valid 
programs that were previously erroneous).

With -std=c89 or -std=gnu89, -pedantic will give a warning "ISO C90 does 
not support flexible array members" and -pedantic-errors will change that 
to an error.

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

[PATCH] libstdc++: A few more minor cleanups

2022-08-31 Thread Patrick Palka via Gcc-patches

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

libstdc++-v3/ChangeLog:

* include/bits/ranges_base.h (__advance_fn::operator()): Add
parentheses in assert condition to avoid -Wparentheses warning.
* include/std/ranges: (take_view::take_view): Uglify 'base'.
(take_while_view::take_while_view): Likewise.
(elements_view::elements_view): Likewise.
(views::_Zip::operator()): Adjust position of [[nodiscard]] for
compatibility with -fconcepts-ts.
(zip_transform_view::_Sentinel): Uglify 'OtherConst'.
(views::_ZipTransform::operator()): Adjust position of
[[nodiscard]] for compatibilty with -fconcepts-ts.
---
 libstdc++-v3/include/bits/ranges_base.h |  2 +-
 libstdc++-v3/include/std/ranges | 40 -
 2 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/libstdc++-v3/include/bits/ranges_base.h 
b/libstdc++-v3/include/bits/ranges_base.h
index 38db33fd2ce..866d7c56cbc 100644
--- a/libstdc++-v3/include/bits/ranges_base.h
+++ b/libstdc++-v3/include/bits/ranges_base.h
@@ -778,7 +778,7 @@ namespace ranges
else if (__n != 0) [[likely]]
  {
// n and bound must not lead in opposite directions:
-   __glibcxx_assert(__n < 0 == __diff < 0);
+   __glibcxx_assert((__n < 0) == (__diff < 0));
 
(*this)(__it, __n);
return 0;
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 2352aad76fc..39822b71b94 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -2121,8 +2121,8 @@ namespace views::__adaptor
   take_view() requires default_initializable<_Vp> = default;
 
   constexpr
-  take_view(_Vp base, range_difference_t<_Vp> __count)
-   : _M_base(std::move(base)), _M_count(std::move(__count))
+  take_view(_Vp __base, range_difference_t<_Vp> __count)
+   : _M_base(std::move(__base)), _M_count(std::move(__count))
   { }
 
   constexpr _Vp
@@ -2355,8 +2355,8 @@ namespace views::__adaptor
= default;
 
   constexpr
-  take_while_view(_Vp base, _Pred __pred)
-   : _M_base(std::move(base)), _M_pred(std::move(__pred))
+  take_while_view(_Vp __base, _Pred __pred)
+   : _M_base(std::move(__base)), _M_pred(std::move(__pred))
   { }
 
   constexpr _Vp
@@ -3982,8 +3982,8 @@ namespace views::__adaptor
   elements_view() requires default_initializable<_Vp> = default;
 
   constexpr explicit
-  elements_view(_Vp base)
-   : _M_base(std::move(base))
+  elements_view(_Vp __base)
+   : _M_base(std::move(__base))
   { }
 
   constexpr _Vp
@@ -4753,9 +4753,8 @@ namespace views::__adaptor
 {
   template
requires (sizeof...(_Ts) == 0 || __detail::__can_zip_view<_Ts...>)
-   [[nodiscard]]
constexpr auto
-   operator()(_Ts&&... __ts) const
+   operator() [[nodiscard]] (_Ts&&... __ts) const
{
  if constexpr (sizeof...(_Ts) == 0)
return views::empty>;
@@ -5036,22 +5035,22 @@ namespace views::__adaptor
   : _M_inner(std::move(__i._M_inner))
 { }
 
-template
-  requires sentinel_for<__zentinel<_Const>, __ziperator>
+template
+  requires sentinel_for<__zentinel<_Const>, __ziperator<_OtherConst>>
 friend constexpr bool
-operator==(const _Iterator& __x, const _Sentinel& __y)
+operator==(const _Iterator<_OtherConst>& __x, const _Sentinel& __y)
 { return __x._M_inner == __y._M_inner; }
 
-template
-  requires sized_sentinel_for<__zentinel<_Const>, __ziperator>
-friend constexpr range_difference_t<__detail::__maybe_const_t>
-operator-(const _Iterator& __x, const _Sentinel& __y)
+template
+  requires sized_sentinel_for<__zentinel<_Const>, __ziperator<_OtherConst>>
+friend constexpr range_difference_t<__detail::__maybe_const_t<_OtherConst, 
_InnerView>>
+operator-(const _Iterator<_OtherConst>& __x, const _Sentinel& __y)
 { return __x._M_inner - __y._M_inner; }
 
-template
-  requires sized_sentinel_for<__zentinel<_Const>, __ziperator>
-friend constexpr range_difference_t<__detail::__maybe_const_t>
-operator-(const _Sentinel& __x, const _Iterator& __y)
+template
+  requires sized_sentinel_for<__zentinel<_Const>, __ziperator<_OtherConst>>
+friend constexpr range_difference_t<__detail::__maybe_const_t<_OtherConst, 
_InnerView>>
+operator-(const _Sentinel& __x, const _Iterator<_OtherConst>& __y)
 { return __x._M_inner - __y._M_inner; }
   };
 
@@ -5068,9 +5067,8 @@ namespace views::__adaptor
 {
   template
requires (sizeof...(_Ts) == 0) || 
__detail::__can_zip_transform_view<_Fp, _Ts...>
-   [[nodiscard]]
constexpr auto
-   operator()(_Fp&& __f, _Ts&&... __ts) const
+   operator() [[nodiscard]] (_Fp&& __f, _Ts&&... __ts) const
{
  if constexpr (sizeof...(_Ts) == 0)

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array



> On Aug 31, 2022, at 2:55 PM, Qing Zhao via Gcc-patches 
>  wrote:
> 
> 
> 
>> On Aug 31, 2022, at 1:21 PM, Joseph Myers  wrote:
>> 
>> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>> 
 "a GNU extension" suggests a particular language feature, but I think 
 you're actually referring here to a whole language version rather than an 
 individual feature.
>>> 
>>> Is “not supported by GNU extension GNU89” better?
>> 
>> There are no existing diagnostics referring to GNU89 at all.  I don't 
>> think "GNU extension" needs to be mentioned in that diagnostic, but I also 
>> think that having that diagnostic at all is ill-conceived.
>> 
 In any case, -std=gnu89 supports flexible array members.
>>> 
>>> Yes, but only [0],[1] are supported as flexible array members.  The C99 
>>> flexible array member [] is not supported by GNU89, right?
>> 
>> C99 flexible array members are fully supported in GNU89 mode.  In general, 
>> any feature from a new language version that doesn't affect code that was 
>> valid in previous versions is likely to be accepted as an extension with 
>> options for older language versions.
> 
> 
> We have a previous discussion on this: 
> (https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599067.html)
> 
> And looks like that the previous conclusion was wrong… please see the 
> following:
> 
> ==
> 
>> How is level 3 (thus -fstrict-flex-array) interpreted when you specify 
>> -std=c89?  How for -std=gnu89?
> 
> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible 
> array? (Checked online, cannot find a concrete answer on this).
>   ** my understanding is:   -std=c89 will not support any flexible array 
> (neither [], [0], [1]), but -std=gnu89 will support [0] and [1], but not [].
>Is this correct?
> 
> If my answer to the first question is correct, then:
> 
> 2. When -fstrict-flex-array=n and -std=c89 present at the same time, which 
> one has the higher priority? 
>   ** I think that -std=c89 should be honored over -fstrict-flex-array, 
> therefore we should disable -fstrict-flex-array=n when n > 0  and issue 
> warnings to the user.
> 
> 
> 3. how about -fstrict-flex-array=n and -std=gnu89 present at the same time? 
>   ** When -std=gnu89 present, [] is not supported. So, we need to issue 
> an warning to disable -fstrict-flex-array=3; but level 1 and level 2 is Okay.
> 
> We also need to document the above.
> 
> 
> So, from my understanding from what you said so far, 
> 
> -std=c89 will not support any flexible array (neither [], [0], [1]),  but 
> -std=gnu89 will support ALL flexible array including [0], [1], and [].
> 
> Is this understanding correct?

And also for C++:

-std=c++98 will not support any flexible array, but -std=gnu++98 will support 
ALL flexible array ([0],[1].[])?

Qing
> 
> thanks.
> 
> Qing
> 
> 
>> 
>> -- 
>> Joseph S. Myers
>> jos...@codesourcery.com

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

2022-08-31 Thread Iain Buclaw via Gcc-patches

Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
> On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> 
>> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
>> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>> > 
>> >> I was hoping Joseph would chime in here - I recollect debugging this kind
>> >> of thing and a thread about this a while back but unfortunately I do not
>> >> remember the details here (IIRC some things get included where they
>> >> better should not be).
>> > 
>> > See .  
>> > Is there some reason it's problematic to avoid having defaults.h or 
>> > ${cpu_type}/${cpu_type}.h included in tm_d.h, and instead have tm_d.h only 
>> > include D-specific headers?
>> > 
>> 
>> In targets such as arm-elf, we still need to pull in definitions from
>> ${cpu_type}/${cpu_type}-d.cc into default-d.cc.
>> 
>> All I can think that might suffice is having D-specific prototype
>> headers in all targets as ${cpu_type}/${cpu_type}-d.h.
> 
> As long as those prototypes don't involve any types that depend on an 
> inclusion of tm.h, that should be fine.
> 

Updated patch that does what I described.

Bootstrapped on x86_64-linux-gnu and built an aarch64-rtems
cross-compiler without any errors, will kick off config-list.mk as well for
sanity checking a big list of targets in a while.

Iain.
---
PR d/105659

gcc/ChangeLog:

* config.gcc: Set tm_d_file to ${cpu_type}/${cpu_type}-d.h.
* config/aarch64/aarch64-d.cc: Include tm_d.h.
* config/aarch64/aarch64-protos.h (aarch64_d_target_versions): Move to
config/aarch64/aarch64-d.h.
(aarch64_d_register_target_info): Likewise.
* config/aarch64/aarch64.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/arm/arm-d.cc: Include tm_d.h instead of tm_p.h.
* config/arm/arm-protos.h (arm_d_target_versions): Move to
config/arm/arm-d.h.
(arm_d_register_target_info): Likewise.
* config/arm/arm.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/default-d.cc: Remove memmodel.h include.
* config/freebsd-d.cc: Include tm_d.h instead of tm_p.h.
* config/glibc-d.cc: Likewise.
* config/i386/i386-d.cc: Include tm_d.h.
* config/i386/i386-protos.h (ix86_d_target_versions): Move to
config/i386/i386-d.h.
(ix86_d_register_target_info): Likewise.
(ix86_d_has_stdcall_convention): Likewise.
* config/i386/i386.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
(TARGET_D_HAS_STDCALL_CONVENTION): Likewise.
* config/i386/winnt-d.cc: Include tm_d.h instead of tm_p.h.
* config/mips/mips-d.cc: Include tm_d.h.
* config/mips/mips-protos.h (mips_d_target_versions): Move to
config/mips/mips-d.h.
(mips_d_register_target_info): Likewise.
* config/mips/mips.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/netbsd-d.cc: Include tm_d.h instead of tm.h and memmodel.h.
* config/openbsd-d.cc: Likewise.
* config/pa/pa-d.cc: Include tm_d.h.
* config/pa/pa-protos.h (pa_d_target_versions): Move to
config/pa/pa-d.h.
(pa_d_register_target_info): Likewise.
* config/pa/pa.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/riscv/riscv-d.cc: Include tm_d.h.
* config/riscv/riscv-protos.h (riscv_d_target_versions): Move to
config/riscv/riscv-d.h.
(riscv_d_register_target_info): Likewise.
* config/riscv/riscv.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/rs6000/rs6000-d.cc: Include tm_d.h.
* config/rs6000/rs6000-protos.h (rs6000_d_target_versions): Move to
config/rs6000/rs6000-d.h.
(rs6000_d_register_target_info): Likewise.
* config/rs6000/rs6000.h (TARGET_D_CPU_VERSIONS) Likewise.:
(TARGET_D_REGISTER_CPU_TARGET_INFO) Likewise.:
* config/s390/s390-d.cc: Include tm_d.h.
* config/s390/s390-protos.h (s390_d_target_versions): Move to
config/s390/s390-d.h.
(s390_d_register_target_info): Likewise.
* config/s390/s390.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* config/sol2-d.cc: Include tm_d.h instead of tm.h and memmodel.h.
* config/sparc/sparc-d.cc: Include tm_d.h.
* config/sparc/sparc-protos.h (sparc_d_target_versions): Move to
config/sparc/sparc-d.h.
(sparc_d_register_target_info): Likewise.
* config/sparc/sparc.h (TARGET_D_CPU_VERSIONS): Likewise.
(TARGET_D_REGISTER_CPU_TARGET_INFO): Likewise.
* configure:

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

> On Aug 31, 2022, at 1:21 PM, Joseph Myers  wrote:
> 
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> 
>>> "a GNU extension" suggests a particular language feature, but I think 
>>> you're actually referring here to a whole language version rather than an 
>>> individual feature.
>> 
>> Is “not supported by GNU extension GNU89” better?
> 
> There are no existing diagnostics referring to GNU89 at all.  I don't 
> think "GNU extension" needs to be mentioned in that diagnostic, but I also 
> think that having that diagnostic at all is ill-conceived.
> 
>>> In any case, -std=gnu89 supports flexible array members.
>> 
>> Yes, but only [0],[1] are supported as flexible array members.  The C99 
>> flexible array member [] is not supported by GNU89, right?
> 
> C99 flexible array members are fully supported in GNU89 mode.  In general, 
> any feature from a new language version that doesn't affect code that was 
> valid in previous versions is likely to be accepted as an extension with 
> options for older language versions.

We have a previous discussion on this: 
(https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599067.html)

And looks like that the previous conclusion was wrong… please see the following:

==

> How is level 3 (thus -fstrict-flex-array) interpreted when you specify 
> -std=c89?  How for -std=gnu89?

1. what’s the major difference between -std=c89 and -std=gnu89 on flexible 
array? (Checked online, cannot find a concrete answer on this).
** my understanding is:   -std=c89 will not support any flexible array 
(neither [], [0], [1]), but -std=gnu89 will support [0] and [1], but not [].
Is this correct?

If my answer to the first question is correct, then:

2. When -fstrict-flex-array=n and -std=c89 present at the same time, which one 
has the higher priority? 
** I think that -std=c89 should be honored over -fstrict-flex-array, 
therefore we should disable -fstrict-flex-array=n when n > 0  and issue 
warnings to the user.

3. how about -fstrict-flex-array=n and -std=gnu89 present at the same time? 
** When -std=gnu89 present, [] is not supported. So, we need to issue 
an warning to disable -fstrict-flex-array=3; but level 1 and level 2 is Okay.

We also need to document the above.

So, from my understanding from what you said so far, 

-std=c89 will not support any flexible array (neither [], [0], [1]),  but 
-std=gnu89 will support ALL flexible array including [0], [1], and [].

Is this understanding correct?

thanks.

Qing

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

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

On 8/31/22 8:59 AM, Peter Bergner wrote:
> On 8/31/22 4:22 AM, Kewen.Lin wrote:
>> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>>> -  tree src_type = TREE_TYPE (src_ptr);
>>> +  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>>> + ? build_pointer_type (vector_quad_type_node)
>>> + : build_pointer_type (vector_pair_type_node);
>>
>> Nit: it seems we can use existing ptr_vector_quad_type_node and 
>> ptr_vector_pair_type_node?
>> I assume the const qualifier is fine since it's for disassembling.
> 
> That's actually what I started with, but I got some type of gimple
> verification error which I can't remember what it said.  Let me put
> that back temporarily and I'll grab the error message.

...and of course, now I can't recreate that issue at all and the
ptr_vector_*_type use work fine now.  Strange! ...so ok, changed.
Maybe the behavior changed since my PR106017 fix went in???



>>> +  if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)
>>
>> This line looks unexpected, the former is type char while the latter is type 
>> __vector_pair *.
>>
>> I guess you meant to compare the type of pointer type like: 
>>
>>TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE (src_type)
> 
> Maybe?  However, if that is the case, how can it be working for me?
> Let me throw this in the debugger and verify the types and I'll report
> back with what I find.

Ok, you are correct.  Thanks for catching that!  I don't think we need
those matching outer TREE_TYPE() uses.  I think just a simple:

if (TREE_TYPE (src_ptr) != src_type)

...should suffice.


>> or even with mode like:
>>
>>TYPE_MODE (TREE_TYPE (TREE_TYPE (src_ptr))) != TYPE_MODE (TREE_TYPE 
>> (src_type))

I'd rather not look at the mode here, since OOmode/XOmode doesn't necessarily
mean __vector_{pair,quad}, so I'll go with the modified test above.




>>> +   src_ptr = build1 (VIEW_CONVERT_EXPR, src_type, src_ptr);
>>
>> Nit: NOP_EXPR seems to be better suited here for pointer conversion.

Ok, this works too, so code changed to use it.  Thanks!

Question for my own education, when would you use VIEW_CONVERT_EXPR over 
NOP_EXPR?



FYI, here is the current code patch with all of the suggested changes 
incorporated:

diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
b/gcc/config/rs6000/rs6000-builtin.cc
index 12afa86854c..61352fcd801 100644
--- a/gcc/config/rs6000/rs6000-builtin.cc
+++ b/gcc/config/rs6000/rs6000-builtin.cc
@@ -1085,7 +1085,11 @@ rs6000_gimple_fold_mma_builtin (gimple_stmt_iterator 
*gsi,
   unsigned nvec = (fncode == RS6000_BIF_DISASSEMBLE_ACC) ? 4 : 2;
   tree dst_ptr = gimple_call_arg (stmt, 0);
   tree src_ptr = gimple_call_arg (stmt, 1);
-  tree src_type = TREE_TYPE (src_ptr);
+  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
+ ? ptr_vector_quad_type_node : ptr_vector_pair_type_node;
+  if (TREE_TYPE (src_ptr) != src_type)
+   src_ptr = build1 (NOP_EXPR, src_type, src_ptr);
+
   tree src = create_tmp_reg_or_ssa_name (TREE_TYPE (src_type));
   gimplify_assign (src, build_simple_mem_ref (src_ptr), _seq);
 

I'll fire off a new round of bootstrap and regtesting and resubmit if it's 
clean.
Thanks for the review!


Peter

[PATCH] Fortran 2018 rounding modes changes

This adds new F2018 features, that are not really enabled (because their 
runtime support is optional).

1. Add the new IEEE_AWAY rounding mode. It is unsupported on all known targets, 
but could be supported by glibc and AIX as part of the C2x proposal. Testing 
for now is minimal, but once a target supports that rounding mode, the tests 
will fail and we can fix them by expanding them.

2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and 
IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support 
floating-point radices other than 2.


Regression-tested on x86_64-pc-linux-gnu, both 32- and 64-bit.
OK to commit?




0001-fortran-Fortran-2018-rounding-modes-changes.patch
Description: Binary data

Re: [PATCH][V3] 32-bit PA-RISC with HP-UX: remove deprecated ports





On 8/31/2022 10:40 AM, John David Anglin wrote:

On 2022-08-31 11:35 a.m., Jeff Law wrote:
It looks like you removed the pa-bsd and pa-osf targets too.  Those 
were so niche that I doubt anyone else would notice.
That should be okay.  I have never heard of anyone building these. 
There is no config for these in config.gcc.
Right.  Those were used almost exclusively by my former colleagues at 
the U of Utah and their industry partners.  All the relevant projects 
and machines have long since been retired.




hppa*-*-openbsd* and hppa*-*-netbsd* are still somewhat used.

Right.   I mentally lump these in with the -linux port.

Jeff

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:

> > "a GNU extension" suggests a particular language feature, but I think 
> > you're actually referring here to a whole language version rather than an 
> > individual feature.
> 
> Is “not supported by GNU extension GNU89” better?

There are no existing diagnostics referring to GNU89 at all.  I don't 
think "GNU extension" needs to be mentioned in that diagnostic, but I also 
think that having that diagnostic at all is ill-conceived.

> > In any case, -std=gnu89 supports flexible array members.
> 
> Yes, but only [0],[1] are supported as flexible array members.  The C99 
> flexible array member [] is not supported by GNU89, right?

C99 flexible array members are fully supported in GNU89 mode.  In general, 
any feature from a new language version that doesn't affect code that was 
valid in previous versions is likely to be accepted as an extension with 
options for older language versions.

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

Re: [PATCH] d: Fix #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported (PR105659)

On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:

> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> > 
> >> I was hoping Joseph would chime in here - I recollect debugging this kind
> >> of thing and a thread about this a while back but unfortunately I do not
> >> remember the details here (IIRC some things get included where they
> >> better should not be).
> > 
> > See .  
> > Is there some reason it's problematic to avoid having defaults.h or 
> > ${cpu_type}/${cpu_type}.h included in tm_d.h, and instead have tm_d.h only 
> > include D-specific headers?
> > 
> 
> In targets such as arm-elf, we still need to pull in definitions from
> ${cpu_type}/${cpu_type}-d.cc into default-d.cc.
> 
> All I can think that might suffice is having D-specific prototype
> headers in all targets as ${cpu_type}/${cpu_type}-d.h.

As long as those prototypes don't involve any types that depend on an 
inclusion of tm.h, that should be fine.

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

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
>> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
> 
> Oh?  Why should it disable -maltivec?  -mvsx makes a little sense on
> one hand, but totally none on the other either.

VSX has to be disabled, since VSX replies on the FP registers existing.

As for Altivec, I'm pretty sure there are some inherent dependencies
there, probably both in hardware and our GCC backend implementation.
I could be wrong, but my guess is things will fall over the ground
if as allow -maltivec along with -msoft-float.  Does the linux kernel
only build with -msoft-float assuming it disables altivec and vsx?
Or does it explicitly always also add -mno-altivec?

> As far as I always knew it does *not* override it, so this seems like
> an accident to me, not detected before  because everyone always types
> -m32 -mpowerpc64 (I know I do, anyway).
> 
> I think we should just fix this and see what breaks, if anything?

So in linux*.h, we have the following which came from a 2004 commit from Alan:

linux64.h:#define OS_MISSING_POWERPC64 !TARGET_64BIT

...and in rs6000.cc:rs6000_option_override_internal(), the following hunk is
basically from:

+2003-12-18  Geoffrey Keating  
+
+   * config/rs6000/aix.h (OS_MISSING_POWERPC64): Define.
+   (OS_MISSING_ALTIVEC): Define.
+   * config/rs6000/darwin.h (ASM_SPEC): Be generous about supplying
+   -force_cpusubtype_ALL.
+   * config/rs6000/rs6000.c (rs6000_override_options): Rearrange
+   CPU information table; now always set all CPU-specific values.
+   Also, use Altivec and powerpc64 when chip and OS supports them.

  /* Some OSs don't support saving the high part of 64-bit registers on context
 switch.  Other OSs don't support saving Altivec registers.  On those OSs,
 we don't touch the OPTION_MASK_POWERPC64 or OPTION_MASK_ALTIVEC settings;
 if the user wants either, the user must explicitly specify them and we
 won't interfere with the user's specification.  */

  set_masks = POWERPC_MASKS;
#ifdef OS_MISSING_POWERPC64
  if (OS_MISSING_POWERPC64)
set_masks &= ~OPTION_MASK_POWERPC64;
#endif
#ifdef OS_MISSING_ALTIVEC
  if (OS_MISSING_ALTIVEC)
set_masks &= ~(OPTION_MASK_ALTIVEC | OPTION_MASK_VSX
   | OTHER_VSX_VECTOR_MASKS);
#endif

...so I think there was no real reason, other than old 64-bit linux kernels 
didn't
save the upper register state in 32-bit mode binaries.  I believe that was 
"fixed"
a long time ago, so I agree we should just "fix" it and see what happens.
In this case, I think the fix is probably just to change the linux64.h define
to be "0" rather than "!TARGET_64".

Peter

Re: [PATCH][V3] 32-bit PA-RISC with HP-UX: remove deprecated ports

2022-08-31 Thread John David Anglin


On 2022-08-31 11:35 a.m., Jeff Law wrote:

It looks like you removed the pa-bsd and pa-osf targets too.  Those were so 
niche that I doubt anyone else would notice.

That should be okay.  I have never heard of anyone building these. There is no 
config for these in config.gcc.

hppa*-*-openbsd* and hppa*-*-netbsd* are still somewhat used.

Dave

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

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]


On 8/31/22 11:07, Jakub Jelinek wrote:

On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:

It could be more explicit, but I think we can assume that from the existing
wording; it says it designates the named character.  If there is no such
character, that cannot be satisfied, so it must be ill-formed.


Ok.


So, we could reject the int h case above and accept silently the others?


Why not warn on the others?


We were always silent for the cases like \u123X or \U12345X.
Do you think we should emit some warnings (but never pedwarns/errors in that
case) that it is universal character name like but not completely?


I think that would be helpful, at least for \u{ and \N{.


The following patch let's us silently accept:
#define z(x) 0
#define a z(
int b = a\u{});
int c = a\u{);
int d = a\N{});
int e = a\N{);
int f = a\u123);
int g = a\U1234567);
int h = a\N);
int i = a\NARG);
int j = a\N{abc});
int k = a\N{ABC.123});

The following 2 will be still rejected with errors:
int l = a\N{ABC});
int m = a\N{LATIN SMALL LETTER A WITH ACUTE});
the first one because ABC is not valid Unicode name and the latter because
it will be int m = aá); and will trigger other errors later.

Given what you said above, I think that is what we want for the last 2
for C++23, the question is if it is ok also for C++20/C17 etc. and whether
it should depend on -pedantic or -pedantic-errors or GNU vs. ISO mode
or not in that case.  We could handle those 2 also differently, just
warn instead of error for the \N{ABC} case if not in C++23 mode when
identifier_pos.


That sounds right.


Here is an incremental version of the patch which will make valid
\u{123} and \N{LATIN SMALL LETTER A WITH ACUTE} an extension in GNU
modes before C++23 and split it as separate tokens in ISO modes.


Looks good.

Jason

Re: [PATCH] middle-end: Add MULT_EXPR recognition for cond scalar reduction





On 8/25/2022 3:39 AM, Kong, Lingling via Gcc-patches wrote:

Hi,

The conditional mult reduction cannot be recognized with current GCC. The 
following loop cannot be vectorized.
Now add MULT_EXPR recognition for conditional scalar reduction.

float summa(int n, float *arg1, float *arg2)
{
 int i;
 float res1 = 1.0;
 for(i = 0; i < n; i++) {
   if(arg2[i])
 res1 *= arg1[i];
 }
 return res1;
}

gcc/ChangeLog:

* tree-if-conv.cc (is_cond_scalar_reduction): Add MULT_EXPR
recognition.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/gen-vect-34.c: New test.
* gcc.dg/vect/vect-ifcvt-18.c: New test.

OK
jeff

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> > Should *any* explicit command line flag ever be disabled like that?
> > (Not talking about things like -m32 -m64, ...
> 
> In a general sense, I'd agree that the answer is no, but we do have
> dependent options like -maltivec and -mvsx, etc., so a -mno-altivec
> better disable any explicit -mvsx earlier on the command line.

Yes, but those two flags are tightly related.  -m32/-m64 and -mpowerpc64
are not, code model and instruction set selection are orthogonal.

> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.

Oh?  Why should it disable -maltivec?  -mvsx makes a little sense on
one hand, but totally none on the other either.

> It's complicated...and that's a bad thing. :-(

Yes.  And most of it is caused by us, instead of being a fact of life.

> > -mpowerpc64 -m32 should always mean the same as -m32 -mpowerpc64, that's
> > the principle of least surprise.
> 
> I think I agree with this, since -mpowerpc64 doesn't mean or imply -m64.
> I say "think", because I don't remember the history of why it behaves this
> way and maybe there was a reason we did like this?  If there isn't a reason,
> then I'm all for -m32 not overriding -mpowerpc64.

As far as I always knew it does *not* override it, so this seems like
an accident to me, not detected before  because everyone always types
-m32 -mpowerpc64 (I know I do, anyway).

I think we should just fix this and see what breaks, if anything?


Segher

Re: [PATCH] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS





On 8/29/2022 2:11 PM, Jan-Benedict Glaw wrote:

Hi Jeff!

On Sun, 2022-08-28 15:32:53 -0600, Jeff Law via Gcc-patches 
 wrote:

On 8/28/2022 1:50 AM, Jan-Benedict Glaw wrote:

On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches 
 wrote:

This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and errors out if DWARF DWARF is not supported.

While I think the pdp11 bits arreved, the rest did not (yet). Just
checked my auto-builder logs. When building current HEAD as

../gcc/configure --prefix=... --enable-werror-always \
--enable-languages=all --disable-gcov \
--disable-shared --disable-threads --without-headers \
--target=...
make V=1 all-gcc

ALL of these targets won't build right now:

[...]

Umm, most of those -elf targets do build.  See:

http://law-sandy.freeddns.org:8080

Another builder. :)  Randomly picking xtensa-elf, you're configuring
as

+ ../../gcc/configure --disable-analyzer --with-system-libunwind
--with-newlib --without-headers --disable-threads --disable-shared
--enable-languages=c,c++
--prefix=/home/jlaw/jenkins/workspace/xtensa-elf/xtensa-elf-obj/gcc/../../xtensa-elf-installed
--target=xtensa-elf

I guess the main difference that lets my builds fail might be
--enable-languages=all (vs. c,c++ in your case.)

Maybe you'd give that a try? (...and I'll trigger a build with just
c,c++ on my builder.)
I can, particularly now that the tester builds everything in a docker 
container -- it really didn't like having Ada tests (for example) 
appearing and disappearing based on whether or not the host had an Ada 
compiler installed.  I've also brought the computing resources in-house 
(literally, in my house), so I'm not worried about running out of Amazon 
credits anymore.


Jeff

Re: [PATCH] Support bitmap_copy across representations





On 8/17/2022 5:11 AM, Richard Biener via Gcc-patches wrote:

The following started as making the backward threader m_imports
use the tree representation.  Since that interfaces to a list
representation bitmap in ranger by copying rewriting the tree
to list to perform the copy is inefficient in that it loses
balancing.  The following adds bitmap_copy_tree_to_list and
integrates it with the generic bitmap_copy routine.  For symmetry
I also added list to tree copy, relying on auto-balancing, and
tree to tree copy which I didn't optimize to preserve the
source balancing but instead use bitmap_copy_tree_to_list and
have the result auto-balanced again.

I've only exercised the tree to list path and I won't actually
end up using it but it's at least worth posting.

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

Worth pushing?

* bitmap.h: Document set_copy aka bitmap_copy as usable
for tree representation.
* bitmap.cc (bitmap_copy_tree_to_list): New helper.
(bitmap_copy): Support copying all bitmap representation
combinations.
I'd lean against unless you expect to be using it.   But it's not a 
strongly held opinion.


jeff

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

Hi!

On Fri, Aug 26, 2022 at 10:50:00PM -0500, Peter Bergner wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand

(The perfect tense of cast is "cast").

> machinery and we end up using the base type of the pointer which leads to
> an ICE.  This patch enforces we always use the correct MMA type regardless
> of the pointer type being used.

> --- /dev/null
> +++ b/gcc/testsuite/g++.target/powerpc/pr101322.C
> @@ -0,0 +1,17 @@
> +/* PR target/101322 */
> +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> +/* { dg-require-effective-target power10_ok } */

These should be the other way around.  It makes no sense to set option X
before testing if you can set option X.  Even if it would technically
work, the primary consumer of any source code is the humans who read it,
and humans read code top down.

Segher

Re: [PATCH] regenerate configure files and config.h.in files





On 8/25/2022 3:42 AM, Martin Liška wrote:

Hi.

I wrote a scipt that runs autoconf in all folders that have configure.ac
file and same for autoheader (where AC_CONFIG_HEADERS is present) and
this is the output.

The script can be seen here:
https://github.com/marxin/script-misc/blob/master/gcc-autoconf-all.py

I'm going to add the script to my daily Builbot tester.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

fixincludes/ChangeLog:

* config.h.in: Regenerate.
* configure: Regenerate.

libada/ChangeLog:

* configure: Regenerate.

libiberty/ChangeLog:

* configure: Regenerate.

libobjc/ChangeLog:

* configure: Regenerate.

liboffloadmic/ChangeLog:

* configure: Regenerate.
* plugin/configure: Regenerate.

libquadmath/ChangeLog:

* configure: Regenerate.

libssp/ChangeLog:

* configure: Regenerate.

libvtv/ChangeLog:

* configure: Regenerate.

zlib/ChangeLog:

* configure: Regenerate.
OK.  And ISTM that regeneration using the standard tools ought to be 
pre-approved for the future.

jeff

Re: [committed] Fix more problems with new linker warnings

On 8/22/2022 3:39 AM, Martin Liška wrote:

On 4/28/22 18:10, Jeff Law via Gcc-patches wrote:

As I mentioned in the original thread, my change to pr94157_0 was an attempt to
avoid these warnings by passing a magic flag to the linker. Of course we may
not be using GNU ld. Or we may be on a non-elf target where the flag I used
doesn't exist. Or we may even be on a ELF target where those bits weren't
added to the linker (frv). Furthermore, we need fixes to all the nested
function tests as well.

So even though I initially resisted pruning the warning, that seems like the
best course of action. So this patch removes my recent change to pr94157_0 and
instead uses our pruning facilities.

I'll be pushing this to the trunk and gcc-12 branch.

Jeff

Hello.

I noticed this patch during my GCC test-suite run with mold linker. As you
likely now, the linker defaults
to non-executable stack and so one sees test-suite crashes (not only warnings)
[1].

So the question is if we want to explicitly fix all tests that rely on
exectack? Or is it something
we can assume as it's what GNU linkers do?

List of affected tests:
https://gist.githubusercontent.com/marxin/aadb75408a5a7867bf9fb26e879ce4c4/raw/aff2a0e4559e2dba8ea358520ca836eda6e7dc70/gistfile1.txt
The problem I ran into was that there wasn't a good way to determine
what to do, even if we know the test was going to need execstack. We
can't just blindly pass the magic flag to the linker -- at the least
that would need to be conditional on the linker being used as well as
the target as some of the ELF targets don't have the linker
infrastructure. And given that the linker can vary across gnu-ld, gold,
mold, it's a rats nest.

jeff

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> Should *any* explicit command line flag ever be disabled like that?
> (Not talking about things like -m32 -m64, ...

In a general sense, I'd agree that the answer is no, but we do have
dependent options like -maltivec and -mvsx, etc., so a -mno-altivec
better disable any explicit -mvsx earlier on the command line.
Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
It's complicated...and that's a bad thing. :-(

> -mpowerpc64 -m32 should always mean the same as -m32 -mpowerpc64, that's
> the principle of least surprise.

I think I agree with this, since -mpowerpc64 doesn't mean or imply -m64.
I say "think", because I don't remember the history of why it behaves this
way and maybe there was a reason we did like this?  If there isn't a reason,
then I'm all for -m32 not overriding -mpowerpc64.

Peter

Re: [PATCH] nvptx: Silence unused variable warning





On 8/28/2022 5:09 AM, Jan-Benedict Glaw wrote:

Hi!

The nvptx backend defines ASM_OUTPUT_DEF along with
ASM_OUTPUT_DEF_FROM_DECLS.  Much like the rs6000 coff target, nvptx
triggers an unused variable warning:

/usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc/gcc/../libbacktrace   -o varasm.o -MT varasm.o -MMD -MP -MF 
./.deps/varasm.TPo ../../gcc/gcc/varasm.cc
../../gcc/gcc/varasm.cc: In function 'void 
output_constant_pool_contents(rtx_constant_pool*)':
../../gcc/gcc/varasm.cc:4318:21: error: unused variable 'name' 
[-Werror=unused-variable]
  4318 | const char *name = XSTR (desc->sym, 0);
   | ^~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1145: varasm.o] Error 1


Fixed the same way:

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..71297440566 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -321,6 +321,9 @@ struct GTY(()) machine_function
  #define ASM_OUTPUT_DEF(FILE,LABEL1,LABEL2)\
do  \
  { \
+  (void) (FILE);   \
+  (void) (LABEL1); \
+  (void) (LABEL2); \
gcc_unreachable (); \
  } \
while (0)


Ok for HEAD?

OK with a ChangeLog entry.

jeff

Re: [PATCH] sched1: Fix -fcompare-debug issue in schedule_region [PR105586]





On 8/23/2022 5:49 AM, Surya Kumari Jangala via Gcc-patches wrote:

sched1: Fix -fcompare-debug issue in schedule_region [PR105586]

In schedule_region(), a basic block that does not contain any real insns
is not scheduled and the dfa state at the entry of the bb is not copied
to the fallthru basic block. However a DEBUG insn is treated as a real
insn, and if a bb contains non-real insns and a DEBUG insn, it's dfa
state is copied to the fallthru bb. This was resulting in
-fcompare-debug failure as the incoming dfa state of the fallthru block
is different with -g. We should always copy the dfa state of a bb to
it's fallthru bb even if the bb does not contain real insns.

2022-08-22  Surya Kumari Jangala  

gcc/
PR rtl-optimization/105586
* sched-rgn.cc (schedule_region): Always copy dfa state to
fallthru block.

gcc/testsuite/
PR rtl-optimization/105586
* gcc.target/powerpc/pr105586.c: New test.
Interesting.    We may have stumbled over this bug internally a little 
while ago -- not from a compare-debug standpoint, but from a "why isn't 
the processor state copied to the fallthru block" point of view.   I had 
it on my to investigate list, but hadn't gotten around to it yet.


I think there were requests for ChangeLog updates and a function comment 
for save_state_for_fallthru_edge.  OK with those updates.


jeff

Re: [PATCH][V3] 32-bit PA-RISC with HP-UX: remove deprecated ports





On 8/31/2022 1:21 AM, Martin Liška wrote:

Sending v3 of the patch that includes John's comments.

Ready to be installed?
Thanks,
Martin

ChangeLog:

* configure: Regenerate.
* configure.ac: Delete hpux9 and hpux10.

config/ChangeLog:

* mh-pa-hpux10: Removed.

contrib/ChangeLog:

* config-list.mk: Remove deprecated ports.

contrib/header-tools/ChangeLog:

* README: Remove deprecated ports.
* reduce-headers: Likewise.

gcc/ChangeLog:

* config.build: Remove deprecated ports.
* config.gcc: Likewise.
* config.host: Likewise.
* configure.ac: Likewise.
* configure: Regenerate.
* config/pa/pa-hpux10.h: Removed.
* config/pa/pa-hpux10.opt: Removed.
* config/pa/t-dce-thr: Removed.

gnattools/ChangeLog:

* configure.ac: Remove deprecated ports.
* configure: Regenerate.

libstdc++-v3/ChangeLog:

* configure: Regenerate.
* crossconfig.m4: Remove deprecated ports.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-conv.C: Remove useless test.
* gcc.c-torture/execute/ieee/hugeval.x: Likewise.
* gcc.dg/torture/pr47917.c: Likewise.
* lib/target-supports.exp: Likewise.

libgcc/ChangeLog:

* config.host: Remove hppa.

libitm/ChangeLog:

* configure: Regenerate.

fixincludes/ChangeLog:

* configure: Regenerate.

OK

It looks like you removed the pa-bsd and pa-osf targets too.  Those were 
so niche that I doubt anyone else would notice.




jeff

Re: [PATCH 1/2] RISC-V: remove deprecate pic code model macro

Could you also clean up all __riscv_cmodel_pic checking in
gcc/testsuite/gcc.target/riscv/predef-*.c?

On Wed, Aug 31, 2022 at 10:58 PM Palmer Dabbelt  wrote:
>
> On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:
> > Came across this deprecated symbol when looking around for
> > -mexplicit-relocs handling in code
> >
> > Signed-off-by: Vineet Gupta 
> > ---
> >  gcc/config/riscv/riscv-c.cc | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
> > index eb7ef09297e9..bba72cf77a82 100644
> > --- a/gcc/config/riscv/riscv-c.cc
> > +++ b/gcc/config/riscv/riscv-c.cc
> > @@ -93,9 +93,6 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
> >break;
> >
> >  case CM_PIC:
> > -  /* __riscv_cmodel_pic is deprecated, and will removed in next GCC 
> > release.
> > -  see https://github.com/riscv/riscv-c-api-doc/pull/11  */
> > -  builtin_define ("__riscv_cmodel_pic");
> >/* FALLTHROUGH. */
> >
> >  case CM_MEDANY:
>
> It looks like some of the tests
> (gcc/testsuite/gcc.target/riscv/predef-3.c, for example) are checking
> for __riscv_cmodel_pic.  From looking at them I'd expect them to fail,
> but even if they're not we should clean them up.

Re: [PATCH v2] Support --disable-fixincludes.

2022-08-31 Thread Alexandre Oliva via Gcc-patches

On Aug 31, 2022, Xi Ruoyao  wrote:

> On Sat, 2022-07-09 at 10:11 -0600, Jeff Law via Gcc-patches wrote:
>> Once Alex is OK with this patch, then it'll be good to go.
>> 
>> jeff

> Gentle ping as a distro maintainer :).

Oops, thanks, sorry, I seem to have missed it the first time around.

The patch looks good to me, thanks Martin,

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

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On Wed, Aug 31, 2022 at 05:07:29PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Given what you said above, I think that is what we want for the last 2
> for C++23, the question is if it is ok also for C++20/C17 etc. and whether
> it should depend on -pedantic or -pedantic-errors or GNU vs. ISO mode
> or not in that case.  We could handle those 2 also differently, just
> warn instead of error for the \N{ABC} case if not in C++23 mode when
> identifier_pos.

Here is an incremental version of the patch which will make valid
\u{123} and \N{LATIN SMALL LETTER A WITH ACUTE} an extension in GNU
modes before C++23 and split it as separate tokens in ISO modes.

Testcase:
#define z(x) 0
#define a z(
int b = a\u{123});
int c = a\N{LATIN SMALL LETTER A WITH ACUTE});

--- libcpp/charset.cc.jj2022-08-31 16:50:48.862775486 +0200
+++ libcpp/charset.cc   2022-08-31 17:18:59.649257350 +0200
@@ -1448,7 +1448,11 @@ _cpp_valid_ucn (cpp_reader *pfile, const
   if (str[-1] == 'u')
 {
   length = 4;
-  if (str < limit && *str == '{')
+  if (str < limit
+  && *str == '{'
+  && (!identifier_pos
+ || CPP_OPTION (pfile, delimited_escape_seqs)
+ || !CPP_OPTION (pfile, std)))
{
  str++;
  /* Magic value to indicate no digits seen.  */
@@ -1462,6 +1466,13 @@ _cpp_valid_ucn (cpp_reader *pfile, const
   else if (str[-1] == 'N')
 {
   length = 4;
+  if (identifier_pos
+ && !CPP_OPTION (pfile, delimited_escape_seqs)
+ && CPP_OPTION (pfile, std))
+   {
+ *cp = 0;
+ return false;
+   }
   if (str == limit || *str != '{')
{
  if (identifier_pos)

Jakub

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
> Test case bswap64-4.c suffers the issue as its comments:
> 
> /* On some versions of dejagnu this test will fail when
>biarch testing with RUNTESTFLAGS="--target_board=unix
>'{-m64,-m32}'" due to -m32 being added on the command
>line after the dg-options -mpowerpc64.
>common/config/rs6000/rs6000-common.c:
>rs6000_handle_option disables -mpowerpc64 for -m32.  */
> 
> As tested, on test machine with dejaGnu 1.6.2, the compilation
> option order looks like: -m32 ... -mpowerpc64, option
> -mpowerpc64 still takes effect;  While on test machine with
> dejaGnu 1.5.1, the option order looks like: -mpowerpc64 ... -m32,
> option -mpowerpc64 is disabled by -m32, then the case fails.

*Should* -mpowerpc64  be disabled by -m32?  Should *any* explicit
command line flag ever be disabled like that?  (Not talking about things
like -m32 -m64, this should be supported for convenience).

-mpowerpc64 -m32 should always mean the same as -m32 -mpowerpc64, that's
the principle of least surprise.

Where then dg-options is placed does not matter in this testcase, both
-m32 -mno-powerpc64 and -m32 -mpowerpc64 are ilp32.


Segher

Re: [PATCH] Add support for floating point endpoints to frange.





On 8/29/2022 8:30 AM, Aldy Hernandez via Gcc-patches wrote:

On Mon, Aug 29, 2022 at 4:27 PM Jakub Jelinek  wrote:

On Mon, Aug 29, 2022 at 04:20:16PM +0200, Aldy Hernandez wrote:

Sure, I can add the HONOR_NANS, but can we even "see" a NAN in the IL
for -ffinite-math-only?

Sure, you can, e.g. __builtin_nan{,s}{,f,l} etc. would do it.
It would be UB to use it at runtime in -ffinite-math-only code though.
Another question is, when making a range VARYING, do you set the NAN
property or not when !HONOR_NANS && MODE_HAS_NANS?

A range of VARYING sets the NAN property to unknown
(fp_prop::VARYING).  If you prefer we can set the property to
fp_prop::NO for !HONOR_NANS && MODE_HAS_NANS.


If the format doesn't have NaNs or the user explicitly disables them, 
then the state should be NO, otherwise YES.


Jeff

Re: [PATCH] Add support for floating point endpoints to frange.





On 8/29/2022 8:42 AM, Toon Moene wrote:

On 8/29/22 16:36, Aldy Hernandez wrote:


On Mon, Aug 29, 2022 at 4:30 PM Toon Moene  wrote:


On 8/29/22 16:15, Aldy Hernandez wrote:


But even with -ffinite-math-only, is there any benefit to propagating
a known NAN?  For example:


The original intent (in 2002) for the option -ffinite-math-only was for
the optimizers to ignore all the various exceptions to common
optimizations because they might not work correctly when presented with
a NaN or an Inf.

I do not know what the effect for floating point range information 
would

be - offhand.

But in the *spirit* of this option would be to ignore that the range
[5.0, 5.0] would "also" contain NaN, for instance.


Hmm, this is somewhat similar to what Jakub suggested.  Perhaps we
could categorically set !NAN for !HONOR_NANS at frange construction
time?

For reference:
bool
HONOR_NANS (machine_mode m)
{
   return MODE_HAS_NANS (m) && !flag_finite_math_only;
}

Thanks.
Aldy



Yep, I think that would do it.

Agreed.
Jeff

Re: [PATCH] Add support for floating point endpoints to frange.





On 8/29/2022 8:15 AM, Aldy Hernandez via Gcc-patches wrote:

On Mon, Aug 29, 2022 at 4:08 PM Toon Moene  wrote:

On 8/29/22 15:54, Jakub Jelinek via Gcc-patches wrote:


On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:

For convenience, singleton_p() returns false for a NAN.  IMO, it makes
the implementation cleaner, but I'm not wed to the idea if someone
objects.

If singleton_p() is used to decide whether one can just replace a variable
with singleton range with a constant, then certainly.
If MODE_HAS_SIGNED_ZEROS, zero has 2 representations (-0.0 and 0.0) and
NaNs have lots of different representations (the sign bit is ignored
except for stuff like copysign/signbit, there are qNaNs and sNaNs and
except for the single case how Inf is represented, all other values of the
mantissa mean different representations of NaN).  So, unless we track which
exact form of NaN can appear, NaN or any [x, x] range with NaN property
set can't be a singleton.  There could be programs that propagate something
important in NaN mantissa and would be upset if frange kills that.
Of course, one needs to take into account that when a FPU creates NaN, it
will create the canonical qNaN.

   Jakub


But the NaNs are irrelevant with -ffinite-math-only, as are the various
Infs (I do not know offhand which MODE_ that is) ...

But even with -ffinite-math-only, is there any benefit to propagating
a known NAN?  For example:
In theory, yes, but I don't know if it's worth the headache in practice 
for NaNs, particularly given they can have many representations.


Jeff

Re: [PATCH] Add support for floating point endpoints to frange.





On 8/29/2022 7:54 AM, Jakub Jelinek via Gcc-patches wrote:

On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:

For convenience, singleton_p() returns false for a NAN.  IMO, it makes
the implementation cleaner, but I'm not wed to the idea if someone
objects.

If singleton_p() is used to decide whether one can just replace a variable
with singleton range with a constant, then certainly.
If MODE_HAS_SIGNED_ZEROS, zero has 2 representations (-0.0 and 0.0) and
NaNs have lots of different representations (the sign bit is ignored
except for stuff like copysign/signbit, there are qNaNs and sNaNs and
except for the single case how Inf is represented, all other values of the
mantissa mean different representations of NaN).  So, unless we track which
exact form of NaN can appear, NaN or any [x, x] range with NaN property
set can't be a singleton.  There could be programs that propagate something
important in NaN mantissa and would be upset if frange kills that.
Of course, one needs to take into account that when a FPU creates NaN, it
will create the canonical qNaN.
I've always thought of singleton_p as having that purpose -- but in the 
integer world we never really had to think about multiple 
representations of the same value.  So it's entirely possible we're 
using singleton_p for multiple purposes.


Clearly if the representation has multiple representations for the same 
value, then we have to be more careful with propagation.  So we may need 
to separate the concept of "this has a value we can propagate" from 
"this has a constant value, but the value may have multiple 
represenatations".


I don't think it's worth trying to track the various NaN 
representations, but I do think it's worth tracking +-Inf and +-0.0.


jeff

Re: [PATCH] rs6000/test: Fix typo in pr86731-fwrapv-longlong.c [PR106682]

On Wed, Aug 31, 2022 at 05:33:21PM +0800, Kewen.Lin wrote:
> It's meant to update "lxv" to "p?lxv" and should leave the
> "lvx" unchanged.  So this is to fix the typo accordingly.
> 
> I'll push this soon if no objections.

Please go ahead.  Out of interest, did you see failures from this, was
it just by visual inspection,  something else?

Thanks,

Segher

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:
> It could be more explicit, but I think we can assume that from the existing
> wording; it says it designates the named character.  If there is no such
> character, that cannot be satisfied, so it must be ill-formed.

Ok.

> > So, we could reject the int h case above and accept silently the others?
> 
> Why not warn on the others?

We were always silent for the cases like \u123X or \U12345X.
Do you think we should emit some warnings (but never pedwarns/errors in that
case) that it is universal character name like but not completely?

The following patch let's us silently accept:
#define z(x) 0
#define a z(
int b = a\u{});
int c = a\u{);
int d = a\N{});
int e = a\N{);
int f = a\u123);
int g = a\U1234567);
int h = a\N);
int i = a\NARG);
int j = a\N{abc});
int k = a\N{ABC.123});

The following 2 will be still rejected with errors:
int l = a\N{ABC});
int m = a\N{LATIN SMALL LETTER A WITH ACUTE});
the first one because ABC is not valid Unicode name and the latter because
it will be int m = aá); and will trigger other errors later.

Given what you said above, I think that is what we want for the last 2
for C++23, the question is if it is ok also for C++20/C17 etc. and whether
it should depend on -pedantic or -pedantic-errors or GNU vs. ISO mode
or not in that case.  We could handle those 2 also differently, just
warn instead of error for the \N{ABC} case if not in C++23 mode when
identifier_pos.

--- libcpp/charset.cc.jj2022-08-31 12:34:18.921176118 +0200
+++ libcpp/charset.cc   2022-08-31 16:50:48.862775486 +0200
@@ -1463,7 +1463,14 @@ _cpp_valid_ucn (cpp_reader *pfile, const
 {
   length = 4;
   if (str == limit || *str != '{')
-   cpp_error (pfile, CPP_DL_ERROR, "'\\N' not followed by '{'");
+   {
+ if (identifier_pos)
+   {
+ *cp = 0;
+ return false;
+   }
+ cpp_error (pfile, CPP_DL_ERROR, "'\\N' not followed by '{'");
+   }
   else
{
  str++;
@@ -1489,7 +1496,7 @@ _cpp_valid_ucn (cpp_reader *pfile, const

  if (str < limit && *str == '}')
{
- if (name == str && identifier_pos)
+ if (identifier_pos && (name == str || !strict))
{
  *cp = 0;
  return false;

Jakub

Re: [PATCH 2/2] RISC-V: remove CM_PIC as it doesn't do much

2022-08-31 Thread Palmer Dabbelt


On Tue, 30 Aug 2022 10:48:30 PDT (-0700), Vineet Gupta wrote:

CM_PIC is no longer doing anything directly. Removing it might
potentially affect USE_LOAD_ADDRESS_MACRO() but seems unlikely.


At least in the short term, there's kind of a mess here that needs to 
get sorted out but just removing CM_PIC doesn't really get us there.



Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/riscv-c.cc   | 4 
 gcc/config/riscv/riscv-opts.h | 3 +--
 gcc/config/riscv/riscv.cc | 2 +-
 3 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index bba72cf77a82..7064fcf142fe 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -92,13 +92,9 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
   builtin_define ("__riscv_cmodel_medlow");
   break;

-case CM_PIC:
-  /* FALLTHROUGH. */
-
 case CM_MEDANY:
   builtin_define ("__riscv_cmodel_medany");
   break;
-
 }

   if (TARGET_MIN_VLEN != 0)
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index 85e869e62e3a..ce3237beca7a 100644
--- a/gcc/config/riscv/riscv-opts.h
+++ b/gcc/config/riscv/riscv-opts.h
@@ -34,8 +34,7 @@ extern enum riscv_abi_type riscv_abi;

 enum riscv_code_model {
   CM_MEDLOW,
-  CM_MEDANY,
-  CM_PIC
+  CM_MEDANY
 };
 extern enum riscv_code_model riscv_cmodel;

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 7c120eaa8e33..a239fe43047c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5162,7 +5162,7 @@ riscv_option_override (void)
   init_machine_status = _init_machine_status;

   if (flag_pic)
-riscv_cmodel = CM_PIC;
+riscv_cmodel = CM_MEDANY;

   /* We get better code with explicit relocs for CM_MEDLOW, but
  worse code for the others (for now).  Pick the best default.  */


I'm fine either way on this one: having CM_PIC gone makes it a bit more 
likely to confuse CM_MEDANY with PIC, but flag_pic is overriding 
riscv_cmodel anyway so this isn't really used and deleting code is 
always a plus.

Re: [PATCH 1/2] RISC-V: remove deprecate pic code model macro

2022-08-31 Thread Palmer Dabbelt


On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:

Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code

Signed-off-by: Vineet Gupta 
---
 gcc/config/riscv/riscv-c.cc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index eb7ef09297e9..bba72cf77a82 100644
--- a/gcc/config/riscv/riscv-c.cc
+++ b/gcc/config/riscv/riscv-c.cc
@@ -93,9 +93,6 @@ riscv_cpu_cpp_builtins (cpp_reader *pfile)
   break;

 case CM_PIC:
-  /* __riscv_cmodel_pic is deprecated, and will removed in next GCC 
release.
-see https://github.com/riscv/riscv-c-api-doc/pull/11  */
-  builtin_define ("__riscv_cmodel_pic");
   /* FALLTHROUGH. */

 case CM_MEDANY:


It looks like some of the tests
(gcc/testsuite/gcc.target/riscv/predef-3.c, for example) are checking
for __riscv_cmodel_pic.  From looking at them I'd expect them to fail,
but even if they're not we should clean them up.

Re: [PATCH] rs6000/test: Fix typo in pr86731-fwrapv-longlong.c [PR106682]

On 8/31/22 4:33 AM, Kewen.Lin via Gcc-patches wrote:
> Commit r12-2266 updated the scanned assembly content from
> 
>   "{\mlvx\M|\mlxv\M|\mlxvd2x\M}"
> 
> to
> 
>   "{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"
> 
> for the test case pr86731-fwrapv-longlong.c unexpectedly.
> 
> It's meant to update "lxv" to "p?lxv" and should leave the
> "lvx" unchanged.  So this is to fix the typo accordingly.

I agree.  Thanks for catching this!

Peter

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]


On 8/31/22 10:35, Jakub Jelinek wrote:

On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote:

If
#define z(x) 0
#define a z(
int x = a\NARG);
is valid in C and C++ <= 20 then
#define z(x) 0
#define a z(
int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
is too and shall preprocess to int x = 0; too.
Which would likely mean that we want to only handle it in identifiers if
in C++23 and not actually treat it as an extension except in literals.

Jason, your toughts about that?


Trying to read again the current C++23 wording, I'm afraid that outside of
the literals both the delimited escape sequences and named universal
characters are a complete nightmare for diagnostics.
Because the wording is that only valid universal character names are
replaced by their corresponding characters.
Ill-formed is only if the hexadecimal digit sequences are valid but
represent a number that is not a UCS scalar value, or represent a control
character.
So, I think we can't reject even
#define z(x) 0
#define a z(
int b = a\u{});
int c = a\u{);
int d = a\N{});
int e = a\N{);
int f = a\u123);
int g = a\U1234567);
int h = a\N{LATIN SMALL LETTER A WITH ACUT});
Couldn't C++23 say at least that if a valid named-universal-character
doesn't designate any character then the program is ill-formed?


It could be more explicit, but I think we can assume that from the 
existing wording; it says it designates the named character.  If there 
is no such character, that cannot be satisfied, so it must be ill-formed.



So, we could reject the int h case above and accept silently the others?


Why not warn on the others?


GCC 12 accepts all these without warning, current trunk rejects the h
case with error and accepts the rest without a warning, clang trunk
emits warnings on all cases but the last and rejects the h case with
an error.

Jakub

[pushed] aarch64: Update sizeless tests for recent GNU C changes

2022-08-31 Thread Richard Sandiford via Gcc-patches

The tests for sizeless SVE types include checks that the types
are handled for initialisation purposes in the same way as scalars.
GNU C and C2x now allow scalars to be initialised using empty braces,
so this patch updates the SVE tests to match.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/testsuite/
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c: Update
tests for empty initializers.
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-1.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/sizeless-2.c: Likewise.
---
 .../gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c | 4 ++--
 .../gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c | 4 ++--
 .../gcc.target/aarch64/sve/acle/general-c/sizeless-1.c| 4 ++--
 .../gcc.target/aarch64/sve/acle/general-c/sizeless-2.c| 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git 
a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c
index 285751eebc4..9db9535831a 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_1.c
@@ -12,7 +12,7 @@ f (svuint8_t sve_u1, svint8_t sve_s1,
   /* Initialization.  */
 
   svuint8_t init_sve_u1 = 0; /* { dg-error {incompatible types when 
initializing type 'svuint8_t' using type 'int'} } */
-  svuint8_t init_sve_u2 = {}; /* { dg-error {empty scalar initializer} } */
+  svuint8_t init_sve_u2 = {};
   svuint8_t init_sve_u3 = { sve_u1 };
   svuint8_t init_sve_u4 = { gnu_u1 };
   svuint8_t init_sve_u5 = { sve_s1 }; /* { dg-error {incompatible types when 
initializing type 'svuint8_t' using type 'svint8_t'} } */
@@ -31,7 +31,7 @@ f (svuint8_t sve_u1, svint8_t sve_s1,
 
   /* Compound literals.  */
 
-  (svuint8_t) {}; /* { dg-error {empty scalar initializer} } */
+  (svuint8_t) {};
   (svuint8_t) { 0 }; /* { dg-error {incompatible types when initializing type 
'svuint8_t' using type 'int'} } */
   (svuint8_t) { sve_u1 };
   (svuint8_t) { gnu_u1 };
diff --git 
a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c
index 306fd478047..c05b16406a4 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/gnu_vectors_2.c
@@ -12,7 +12,7 @@ f (svuint8_t sve_u1, svint8_t sve_s1,
   /* Initialization.  */
 
   svuint8_t init_sve_u1 = 0; /* { dg-error {incompatible types when 
initializing type 'svuint8_t' using type 'int'} } */
-  svuint8_t init_sve_u2 = {}; /* { dg-error {empty scalar initializer} } */
+  svuint8_t init_sve_u2 = {};
   svuint8_t init_sve_u3 = { sve_u1 };
   svuint8_t init_sve_u4 = { gnu_u1 };
   svuint8_t init_sve_u5 = { sve_s1 };
@@ -31,7 +31,7 @@ f (svuint8_t sve_u1, svint8_t sve_s1,
 
   /* Compound literals.  */
 
-  (svuint8_t) {}; /* { dg-error {empty scalar initializer} } */
+  (svuint8_t) {};
   (svuint8_t) { 0 }; /* { dg-error {incompatible types when initializing type 
'svuint8_t' using type 'int'} } */
   (svuint8_t) { sve_u1 };
   (svuint8_t) { gnu_u1 };
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
index 7fc51e7ad18..4b34a71c1fe 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
@@ -66,14 +66,14 @@ statements (int n)
 
   svint8_t init_sve_sc1 = sve_sc1;
   svint8_t init_sve_sc2 = sve_sh1; /* { dg-error {incompatible types when 
initializing type 'svint8_t' using type 'svint16_t'} } */
-  svint8_t init_sve_sc3 = {}; /* { dg-error {empty scalar initializer} } */
+  svint8_t init_sve_sc3 = {};
 
   int initi_a = sve_sc1; /* { dg-error {incompatible types when initializing 
type 'int' using type 'svint8_t'} } */
   int initi_b = { sve_sc1 }; /* { dg-error {incompatible types when 
initializing type 'int' using type 'svint8_t'} } */
 
   /* Compound literals.  */
 
-  (svint8_t) {}; /* { dg-error {empty scalar initializer} } */
+  (svint8_t) {};
   (svint8_t) { sve_sc1 };
 
   (int) { sve_sc1 }; /* { dg-error {incompatible types when initializing type 
'int' using type 'svint8_t'} } */
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c 
b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
index c575492c1f8..34dfd598e32 100644
--- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
@@ -66,14 +66,14 @@ statements (int n)
 
   svint8_t init_sve_sc1 = sve_sc1;
   svint8_t init_sve_sc2 = sve_sh1; /* { dg-error {incompatible types when 
initializing type 'svint8_t' using type 'svint16_t'} } */
-

Re: [PATCH 6/6] Extend SLP permutation optimisations





On 8/30/2022 8:50 AM, Richard Sandiford wrote:

Jeff Law via Gcc-patches  writes:

On 8/25/2022 7:07 AM, Richard Sandiford via Gcc-patches wrote:

Currently SLP tries to force permute operations "down" the graph
from loads in the hope of reducing the total number of permutations
needed or (in the best case) removing the need for the permutations
entirely.  This patch tries to extend it as follows:

- Allow loads to take a different permutation from the one they
started with, rather than choosing between "original permutation"
and "no permutation".

- Allow changes in both directions, if the target supports the
reverse permutation.

- Treat the placement of permutations as a two-way dataflow problem:
after propagating information from leaves to roots (as now), propagate
information back up the graph.

- Take execution frequency into account when optimising for speed,
so that (for example) permutations inside loops have a higher
cost than permutations outside loops.

- Try to reduce the total number of permutations when optimising for
size, even if that increases the number of permutations on a given
execution path.

See the big block comment above vect_optimize_slp_pass for
a detailed description.

The original motivation for doing this was to add a framework that would
allow other layout differences in future.  The two main ones are:

- Make it easier to represent predicated operations, including
predicated operations with gaps.  E.g.:

   a[0] += 1;
   a[1] += 1;
   a[3] += 1;

could be a single load/add/store for SVE.  We could handle this
by representing a layout such as { 0, 1, _, 2 } or { 0, 1, _, 3 }
(depending on what's being counted).  We might need to move
elements between lanes at various points, like with permutes.

(This would first mean adding support for stores with gaps.)

- Make it easier to switch between an even/odd and unpermuted layout
when switching between wide and narrow elements.  E.g. if a widening
operation produces an even vector and an odd vector, we should try
to keep operations on the wide elements in that order rather than
force them to be permuted back "in order".

Very cool.  Richi and I discussed this a bit a year or so ago --
basically noting that bi-directional movement is really the way to go
and that the worst thing to do is push a permute down into the *middle*
of a computation chain since that will tend to break FMA generation.
Moving to the loads or stores or to another permute point ought to be
the goal.

Hmm, I hadn't thought specifically about the case of permutes
ending up in the middle of a fusable operation.  The series doesn't
address that directly.  If we have:

   permute(a) * permute(b) + c

then the tendency will still be to convert that into:

   permute(a * b) + c

Damn.  Another case to think about ;-)

I've pushed the series for now though (thanks to Richi for the reviews).
There's a simple testcase attached to PR101895 which shows an example 
where (in the gcc-11 era) we pushed a permute down in a problematic 
way.   It might be worth taking a looksie, though I think we're avoiding 
the problem behavior via a workaround on the trunk right now.


Jeff

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]

On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote:
> If
> #define z(x) 0
> #define a z(
> int x = a\NARG);
> is valid in C and C++ <= 20 then
> #define z(x) 0
> #define a z(
> int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
> is too and shall preprocess to int x = 0; too.
> Which would likely mean that we want to only handle it in identifiers if
> in C++23 and not actually treat it as an extension except in literals.
> 
> Jason, your toughts about that?

Trying to read again the current C++23 wording, I'm afraid that outside of
the literals both the delimited escape sequences and named universal
characters are a complete nightmare for diagnostics.
Because the wording is that only valid universal character names are
replaced by their corresponding characters.
Ill-formed is only if the hexadecimal digit sequences are valid but
represent a number that is not a UCS scalar value, or represent a control
character.
So, I think we can't reject even
#define z(x) 0
#define a z(
int b = a\u{});
int c = a\u{);
int d = a\N{});
int e = a\N{);
int f = a\u123);
int g = a\U1234567);
int h = a\N{LATIN SMALL LETTER A WITH ACUT});
Couldn't C++23 say at least that if a valid named-universal-character
doesn't designate any character then the program is ill-formed?
So, we could reject the int h case above and accept silently the others?

GCC 12 accepts all these without warning, current trunk rejects the h
case with error and accepts the rest without a warning, clang trunk
emits warnings on all cases but the last and rejects the h case with
an error.

Jakub

[PATCH] Avoid fatal fails in predicate::init_from_control_deps

2022-08-31 Thread Richard Biener via Gcc-patches

When processing USE predicates we can drop from the AND chain,
when procsssing DEF predicates we can drop from the OR chain.  Do
that instead of giving up completely.  This also removes cases
that should never trigger.

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

* gimple-predicate-analysis.cc (predicate::init_from_control_deps):
Assert the guard_bb isn't empty and has more than one successor.
Drop appropriate parts of the predicate when an edge fails to
register a predicate.
(predicate::dump): Dump empty predicate as TRUE.
---
 gcc/gimple-predicate-analysis.cc | 119 ++-
 1 file changed, 55 insertions(+), 64 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 58eade433dc..eb1e11cead8 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -1671,7 +1671,6 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
 {
   gcc_assert (is_empty ());
 
-  bool has_valid_pred = false;
   if (num_chains == 0)
 return;
 
@@ -1689,27 +1688,16 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
 of the predicates.  */
   const vec  = dep_chains[i];
 
-  has_valid_pred = false;
+  bool has_valid_pred = false;
   /* The chain of predicates guarding the definition along this path.  */
   pred_chain t_chain{ };
   for (unsigned j = 0; j < path.length (); j++)
{
  edge e = path[j];
  basic_block guard_bb = e->src;
- /* Ignore empty forwarder blocks.  */
- if (empty_block_p (guard_bb) && single_succ_p (guard_bb))
-   continue;
 
- /* An empty basic block here is likely a PHI, and is not one
-of the cases we handle below.  */
- gimple_stmt_iterator gsi = gsi_last_bb (guard_bb);
- if (gsi_end_p (gsi))
-   {
- has_valid_pred = false;
- break;
-   }
- /* Get the conditional controlling the bb exit edge.  */
- gimple *cond_stmt = gsi_stmt (gsi);
+ gcc_assert (!empty_block_p (guard_bb) && !single_succ_p (guard_bb));
+
  /* Skip this edge if it is bypassing an abort - when the
 condition is not satisfied we are neither reaching the
 definition nor the use so it isn't meaningful.  Note if
@@ -1730,8 +1718,13 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
}
}
  if (skip)
-   continue;
+   {
+ has_valid_pred = true;
+ continue;
+   }
}
+ /* Get the conditional controlling the bb exit edge.  */
+ gimple *cond_stmt = last_stmt (guard_bb);
  if (gimple_code (cond_stmt) == GIMPLE_COND)
{
  /* The true edge corresponds to the uninteresting condition.
@@ -1757,37 +1750,29 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
}
  else if (gswitch *gs = dyn_cast (cond_stmt))
{
- /* Avoid quadratic behavior.  */
- if (gimple_switch_num_labels (gs) > MAX_SWITCH_CASES)
-   {
- has_valid_pred = false;
- break;
-   }
- /* Find the case label.  */
  tree l = NULL_TREE;
- unsigned idx;
- for (idx = 0; idx < gimple_switch_num_labels (gs); ++idx)
-   {
- tree tl = gimple_switch_label (gs, idx);
- if (e->dest == label_to_block (cfun, CASE_LABEL (tl)))
-   {
- if (!l)
-   l = tl;
- else
-   {
- l = NULL_TREE;
- break;
-   }
-   }
-   }
+ /* Find the case label, but avoid quadratic behavior.  */
+ if (gimple_switch_num_labels (gs) <= MAX_SWITCH_CASES)
+   for (unsigned idx = 0;
+idx < gimple_switch_num_labels (gs); ++idx)
+ {
+   tree tl = gimple_switch_label (gs, idx);
+   if (e->dest == label_to_block (cfun, CASE_LABEL (tl)))
+ {
+   if (!l)
+ l = tl;
+   else
+ {
+   l = NULL_TREE;
+   break;
+ }
+ }
+ }
  /* If more than one label reaches this block or the case
 label doesn't have a contiguous range of values (like the
 default one) fail.  */
  if (!l || !CASE_LOW (l))
-   {
- has_valid_pred = false;
- break;
-   }
+   has_valid_pred =

Re: [PATCH] libcpp, v4: Add -Winvalid-utf8 warning [PR106655]


On 8/31/22 10:15, Jakub Jelinek wrote:

On Wed, Aug 31, 2022 at 09:55:29AM -0400, Jason Merrill wrote:

On 8/31/22 07:14, Jakub Jelinek wrote:

On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:

This hunk now seems worth factoring out of the four places it occurs.

It also seems the comment for _cpp_valid_utf8 needs to be updated: it
currently says it's not called when parsing a string.


Ok, so like this?


OK, thanks.


Actually, it isn't enough to diagnose this in comments and character/string
literals, sorry for finding that out only today.

We don't accept invalid UTF-8 in identifiers, it fails the checking in there
(most of the times without errors), what we do is create CPP_OTHER tokens
out of those and then typically diagnose it when it is used somewhere.
Except it doesn't have to be used anywhere, it can be omitted.

So if we have say
#define I(x)
I(���)
like in the Winvalid-utf8-3.c test, we silently accept it.

This updated version extends the diagnostics even to those cases.
I can't use _cpp_handle_multibyte_utf8 in that case because it needs
different treatment (no bidi stuff which is emitted already from
forms_identifier_p etc.).

Tested so far on the new tests, ok for trunk if it passes full
bootstrap/regtest?


OK.


2022-08-31  Jakub Jelinek  

PR c++/106655
libcpp/
* include/cpplib.h (struct cpp_options): Implement C++23
P2295R6 - Support for UTF-8 as a portable source file encoding.
Add cpp_warn_invalid_utf8 and cpp_input_charset_explicit fields.
(enum cpp_warning_reason): Add CPP_W_INVALID_UTF8 enumerator.
* init.cc (cpp_create_reader): Initialize cpp_warn_invalid_utf8
and cpp_input_charset_explicit.
* charset.cc (_cpp_valid_utf8): Adjust function comment.
* lex.cc (UCS_LIMIT): Define.
(utf8_continuation): New const variable.
(utf8_signifier): Move earlier in the file.
(_cpp_warn_invalid_utf8, _cpp_handle_multibyte_utf8): New functions.
(_cpp_skip_block_comment): Handle -Winvalid-utf8 warning.
(skip_line_comment): Likewise.
(lex_raw_string, lex_string): Likewise.
(_cpp_lex_direct): Likewise.
gcc/
* doc/invoke.texi (-Winvalid-utf8): Document it.
gcc/c-family/
* c.opt (-Winvalid-utf8): New warning.
* c-opts.c (c_common_handle_option) :
Set cpp_opts->cpp_input_charset_explicit.
(c_common_post_options): If -finput-charset=UTF-8 is explicit
in C++23, enable -Winvalid-utf8 by default and if -pedantic
or -pedantic-errors, make it a pedwarn.
gcc/testsuite/
* c-c++-common/cpp/Winvalid-utf8-1.c: New test.
* c-c++-common/cpp/Winvalid-utf8-2.c: New test.
* c-c++-common/cpp/Winvalid-utf8-3.c: New test.
* g++.dg/cpp23/Winvalid-utf8-1.C: New test.
* g++.dg/cpp23/Winvalid-utf8-2.C: New test.
* g++.dg/cpp23/Winvalid-utf8-3.C: New test.
* g++.dg/cpp23/Winvalid-utf8-4.C: New test.
* g++.dg/cpp23/Winvalid-utf8-5.C: New test.
* g++.dg/cpp23/Winvalid-utf8-6.C: New test.
* g++.dg/cpp23/Winvalid-utf8-7.C: New test.
* g++.dg/cpp23/Winvalid-utf8-8.C: New test.
* g++.dg/cpp23/Winvalid-utf8-9.C: New test.
* g++.dg/cpp23/Winvalid-utf8-10.C: New test.
* g++.dg/cpp23/Winvalid-utf8-11.C: New test.
* g++.dg/cpp23/Winvalid-utf8-12.C: New test.

--- libcpp/include/cpplib.h.jj  2022-08-31 10:19:45.226452609 +0200
+++ libcpp/include/cpplib.h 2022-08-31 12:25:42.451125755 +0200
@@ -560,6 +560,13 @@ struct cpp_options
   cpp_bidirectional_level.  */
unsigned char cpp_warn_bidirectional;
  
+  /* True if libcpp should warn about invalid UTF-8 characters in comments.

+ 2 if it should be a pedwarn.  */
+  unsigned char cpp_warn_invalid_utf8;
+
+  /* True if -finput-charset= option has been used explicitly.  */
+  bool cpp_input_charset_explicit;
+
/* Dependency generation.  */
struct
{
@@ -666,7 +673,8 @@ enum cpp_warning_reason {
CPP_W_CXX11_COMPAT,
CPP_W_CXX20_COMPAT,
CPP_W_EXPANSION_TO_DEFINED,
-  CPP_W_BIDIRECTIONAL
+  CPP_W_BIDIRECTIONAL,
+  CPP_W_INVALID_UTF8
  };
  
  /* Callback for header lookup for HEADER, which is the name of a

--- libcpp/init.cc.jj   2022-08-31 10:19:45.260452148 +0200
+++ libcpp/init.cc  2022-08-31 12:25:42.451125755 +0200
@@ -227,6 +227,8 @@ cpp_create_reader (enum c_lang lang, cpp
CPP_OPTION (pfile, ext_numeric_literals) = 1;
CPP_OPTION (pfile, warn_date_time) = 0;
CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
+  CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;
  
/* Default CPP arithmetic to something sensible for the host for the

   benefit of dumb users like fix-header.  */
--- libcpp/charset.cc.jj2022-08-26 16:06:10.578493272 +0200
+++ libcpp/charset.cc   2022-08-31 12:34:18.921176118 +0200
@@ -1742,9 +1742,9 @@ convert_ucn

Re: [PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

Hum, slightly amended patch, after checking 32-bit results on another linux 
machine.
The test for FMA has been made a bit less strict, because otherwise we have 
surprised on 387 arithmetic due to excess precision.

Final patch is attached. Regression-tested on x86_64-pc-linux-gnu, both 32- and 
64-bit.
OK to commit?

FX



0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch
Description: Binary data

Re: [PATCH] c++, v2: Implement C++23 P2071R2 - Named universal character escapes [PR106648]


On 8/30/22 17:37, Jakub Jelinek wrote:

On Tue, Aug 30, 2022 at 11:18:20PM +0200, Jakub Jelinek via Gcc-patches wrote:

On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:

I'm seeing build failures of glibc for powerpc64, as illustrated by the
following C code:

#if 0
\NARG
#endif

(the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef
__ASSEMBLER__).

This shows some problems with this feature - and with delimited escape
sequences - as it affects C.  It's fine to accept it as an extension
inside string and character literals, because \N or \u{...} would be
invalid in the absence of the feature (i.e. the syntax for such literals
fails to match, meaning that the rule about undefined behavior for a
single ' or " as a pp-token applies).  But outside string and character
literals, the usual lexing rules apply, the \ is a pp-token on its own and
the code is valid at the preprocessing level, and with expansion of macros
appearing before or after the \ (e.g. u defined as a macro in the \u{...}
case) it may be valid code at the language level as well.  I don't know
what older C++ versions say about this, but for C this means e.g.

#define z(x) 0
#define a z(
int x = a\NARG);

needs to be accepted as expanding to "int x = 0;", not interpreted as
using the \N feature in an identifier and produce an error.


Thanks, will look at it tomorrow.


If
#define z(x) 0
#define a z(
int x = a\NARG);
is valid in C and C++ <= 20 then
#define z(x) 0
#define a z(
int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
is too and shall preprocess to int x = 0; too.
Which would likely mean that we want to only handle it in identifiers if
in C++23 and not actually treat it as an extension except in literals.

Jason, your thoughts about that?


The problem in glibc is with \N that is not followed by {; it certainly 
seems that we need to not treat that as an ill-formed named universal 
char escape outside of a literal.  I think for an actual \N{...} 
sequence, we should treat it as an extension unless in strict 
conformance mode, kind of like we do with the ext_numeric_numerals flag.


Jason

[PATCH] libcpp, v4: Add -Winvalid-utf8 warning [PR106655]

On Wed, Aug 31, 2022 at 09:55:29AM -0400, Jason Merrill wrote:
> On 8/31/22 07:14, Jakub Jelinek wrote:
> > On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
> > > This hunk now seems worth factoring out of the four places it occurs.
> > > 
> > > It also seems the comment for _cpp_valid_utf8 needs to be updated: it
> > > currently says it's not called when parsing a string.
> > 
> > Ok, so like this?
> 
> OK, thanks.

Actually, it isn't enough to diagnose this in comments and character/string
literals, sorry for finding that out only today.

We don't accept invalid UTF-8 in identifiers, it fails the checking in there
(most of the times without errors), what we do is create CPP_OTHER tokens
out of those and then typically diagnose it when it is used somewhere.
Except it doesn't have to be used anywhere, it can be omitted.

So if we have say
#define I(x)
I(���)
like in the Winvalid-utf8-3.c test, we silently accept it.

This updated version extends the diagnostics even to those cases.
I can't use _cpp_handle_multibyte_utf8 in that case because it needs
different treatment (no bidi stuff which is emitted already from
forms_identifier_p etc.).

Tested so far on the new tests, ok for trunk if it passes full
bootstrap/regtest?

2022-08-31  Jakub Jelinek  

PR c++/106655
libcpp/
* include/cpplib.h (struct cpp_options): Implement C++23
P2295R6 - Support for UTF-8 as a portable source file encoding.
Add cpp_warn_invalid_utf8 and cpp_input_charset_explicit fields.
(enum cpp_warning_reason): Add CPP_W_INVALID_UTF8 enumerator.
* init.cc (cpp_create_reader): Initialize cpp_warn_invalid_utf8
and cpp_input_charset_explicit.
* charset.cc (_cpp_valid_utf8): Adjust function comment.
* lex.cc (UCS_LIMIT): Define.
(utf8_continuation): New const variable.
(utf8_signifier): Move earlier in the file.
(_cpp_warn_invalid_utf8, _cpp_handle_multibyte_utf8): New functions.
(_cpp_skip_block_comment): Handle -Winvalid-utf8 warning.
(skip_line_comment): Likewise.
(lex_raw_string, lex_string): Likewise.
(_cpp_lex_direct): Likewise.
gcc/
* doc/invoke.texi (-Winvalid-utf8): Document it.
gcc/c-family/
* c.opt (-Winvalid-utf8): New warning.
* c-opts.c (c_common_handle_option) :
Set cpp_opts->cpp_input_charset_explicit.
(c_common_post_options): If -finput-charset=UTF-8 is explicit
in C++23, enable -Winvalid-utf8 by default and if -pedantic
or -pedantic-errors, make it a pedwarn.
gcc/testsuite/
* c-c++-common/cpp/Winvalid-utf8-1.c: New test.
* c-c++-common/cpp/Winvalid-utf8-2.c: New test.
* c-c++-common/cpp/Winvalid-utf8-3.c: New test.
* g++.dg/cpp23/Winvalid-utf8-1.C: New test.
* g++.dg/cpp23/Winvalid-utf8-2.C: New test.
* g++.dg/cpp23/Winvalid-utf8-3.C: New test.
* g++.dg/cpp23/Winvalid-utf8-4.C: New test.
* g++.dg/cpp23/Winvalid-utf8-5.C: New test.
* g++.dg/cpp23/Winvalid-utf8-6.C: New test.
* g++.dg/cpp23/Winvalid-utf8-7.C: New test.
* g++.dg/cpp23/Winvalid-utf8-8.C: New test.
* g++.dg/cpp23/Winvalid-utf8-9.C: New test.
* g++.dg/cpp23/Winvalid-utf8-10.C: New test.
* g++.dg/cpp23/Winvalid-utf8-11.C: New test.
* g++.dg/cpp23/Winvalid-utf8-12.C: New test.

--- libcpp/include/cpplib.h.jj  2022-08-31 10:19:45.226452609 +0200
+++ libcpp/include/cpplib.h 2022-08-31 12:25:42.451125755 +0200
@@ -560,6 +560,13 @@ struct cpp_options
  cpp_bidirectional_level.  */
   unsigned char cpp_warn_bidirectional;

+  /* True if libcpp should warn about invalid UTF-8 characters in comments.
+ 2 if it should be a pedwarn.  */
+  unsigned char cpp_warn_invalid_utf8;
+
+  /* True if -finput-charset= option has been used explicitly.  */
+  bool cpp_input_charset_explicit;
+
   /* Dependency generation.  */
   struct
   {
@@ -666,7 +673,8 @@ enum cpp_warning_reason {
   CPP_W_CXX11_COMPAT,
   CPP_W_CXX20_COMPAT,
   CPP_W_EXPANSION_TO_DEFINED,
-  CPP_W_BIDIRECTIONAL
+  CPP_W_BIDIRECTIONAL,
+  CPP_W_INVALID_UTF8
 };

 /* Callback for header lookup for HEADER, which is the name of a
--- libcpp/init.cc.jj   2022-08-31 10:19:45.260452148 +0200
+++ libcpp/init.cc  2022-08-31 12:25:42.451125755 +0200
@@ -227,6 +227,8 @@ cpp_create_reader (enum c_lang lang, cpp
   CPP_OPTION (pfile, ext_numeric_literals) = 1;
   CPP_OPTION (pfile, warn_date_time) = 0;
   CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
+  CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;

   /* Default CPP arithmetic to something sensible for the host for the
  benefit of dumb users like fix-header.  */
--- libcpp/charset.cc.jj2022-08-26 16:06:10.578493272 +0200
+++ libcpp/charset.cc   2022-08-31 12:34:18.921176118 +0200
@@ -1742,9 +1742,9 @@ convert_ucn (cpp_reader *pfile, const uc
 case,

Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

On 8/31/22 4:33 AM, Kewen.Lin wrote:
> @@ -1,7 +1,8 @@
>  /* { dg-do compile { target { powerpc*-*-* } } } */
>  /* { dg-skip-if "" { powerpc*-*-aix* } } */
> -/* { dg-options "-O2 -mpowerpc64" } */
>  /* { dg-require-effective-target ilp32 } */
> +/* { dg-options "-O2 -mpowerpc64" } */
> +/* { dg-require-effective-target has_arch_ppc64 } */

With many of our recent patches moving the dg-options before any
dg-requires-effectice-target so it affects the results of the
dg-requires-effectice-target test, this looks like it's backwards
from that process.  I understand why, so I think an explicit comment
here in the test case explaining why it's after in this case.
Just so in a few years when we come back to this test case, we
won't accidentally undo this change.

The other option would be to introduce -mdejagnu-32 and -mdejagnu-64
options that operate like our -mdejagnu-cpu= options and override any
-m32/-m64 option given on the command line (eg, RUNTESTFLAGS=...).
To be honest, I'm not sure how I feel about this suggestion! :-)
Maybe we'd only use it on the test cases like this one that we know
are sensitive to be overridden???

Peter

Re: [PATCH] libcpp, v3: Add -Winvalid-utf8 warning [PR106655]


On 8/31/22 07:14, Jakub Jelinek wrote:

On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:

This hunk now seems worth factoring out of the four places it occurs.

It also seems the comment for _cpp_valid_utf8 needs to be updated: it
currently says it's not called when parsing a string.


Ok, so like this?


OK, thanks.


2022-08-31  Jakub Jelinek  

PR c++/106655
libcpp/
* include/cpplib.h (struct cpp_options): Implement C++23
P2295R6 - Support for UTF-8 as a portable source file encoding.
Add cpp_warn_invalid_utf8 and cpp_input_charset_explicit fields.
(enum cpp_warning_reason): Add CPP_W_INVALID_UTF8 enumerator.
* init.cc (cpp_create_reader): Initialize cpp_warn_invalid_utf8
and cpp_input_charset_explicit.
* charset.cc (_cpp_valid_utf8): Adjust function comment.
* lex.cc (UCS_LIMIT): Define.
(utf8_continuation): New const variable.
(utf8_signifier): Move earlier in the file.
(_cpp_warn_invalid_utf8, _cpp_handle_multibyte_utf8): New functions.
(_cpp_skip_block_comment): Handle -Winvalid-utf8 warning.
(skip_line_comment): Likewise.
(lex_raw_string, lex_string): Likewise.
gcc/
* doc/invoke.texi (-Winvalid-utf8): Document it.
gcc/c-family/
* c.opt (-Winvalid-utf8): New warning.
* c-opts.c (c_common_handle_option) :
Set cpp_opts->cpp_input_charset_explicit.
(c_common_post_options): If -finput-charset=UTF-8 is explicit
in C++23, enable -Winvalid-utf8 by default and if -pedantic
or -pedantic-errors, make it a pedwarn.
gcc/testsuite/
* c-c++-common/cpp/Winvalid-utf8-1.c: New test.
* c-c++-common/cpp/Winvalid-utf8-2.c: New test.
* g++.dg/cpp23/Winvalid-utf8-1.C: New test.
* g++.dg/cpp23/Winvalid-utf8-2.C: New test.
* g++.dg/cpp23/Winvalid-utf8-3.C: New test.
* g++.dg/cpp23/Winvalid-utf8-4.C: New test.
* g++.dg/cpp23/Winvalid-utf8-5.C: New test.
* g++.dg/cpp23/Winvalid-utf8-6.C: New test.
* g++.dg/cpp23/Winvalid-utf8-7.C: New test.
* g++.dg/cpp23/Winvalid-utf8-8.C: New test.

--- libcpp/include/cpplib.h.jj  2022-08-31 10:19:45.226452609 +0200
+++ libcpp/include/cpplib.h 2022-08-31 12:25:42.451125755 +0200
@@ -560,6 +560,13 @@ struct cpp_options
   cpp_bidirectional_level.  */
unsigned char cpp_warn_bidirectional;
  
+  /* True if libcpp should warn about invalid UTF-8 characters in comments.

+ 2 if it should be a pedwarn.  */
+  unsigned char cpp_warn_invalid_utf8;
+
+  /* True if -finput-charset= option has been used explicitly.  */
+  bool cpp_input_charset_explicit;
+
/* Dependency generation.  */
struct
{
@@ -666,7 +673,8 @@ enum cpp_warning_reason {
CPP_W_CXX11_COMPAT,
CPP_W_CXX20_COMPAT,
CPP_W_EXPANSION_TO_DEFINED,
-  CPP_W_BIDIRECTIONAL
+  CPP_W_BIDIRECTIONAL,
+  CPP_W_INVALID_UTF8
  };
  
  /* Callback for header lookup for HEADER, which is the name of a

--- libcpp/init.cc.jj   2022-08-31 10:19:45.260452148 +0200
+++ libcpp/init.cc  2022-08-31 12:25:42.451125755 +0200
@@ -227,6 +227,8 @@ cpp_create_reader (enum c_lang lang, cpp
CPP_OPTION (pfile, ext_numeric_literals) = 1;
CPP_OPTION (pfile, warn_date_time) = 0;
CPP_OPTION (pfile, cpp_warn_bidirectional) = bidirectional_unpaired;
+  CPP_OPTION (pfile, cpp_warn_invalid_utf8) = 0;
+  CPP_OPTION (pfile, cpp_input_charset_explicit) = 0;
  
/* Default CPP arithmetic to something sensible for the host for the

   benefit of dumb users like fix-header.  */
--- libcpp/charset.cc.jj2022-08-26 16:06:10.578493272 +0200
+++ libcpp/charset.cc   2022-08-31 12:34:18.921176118 +0200
@@ -1742,9 +1742,9 @@ convert_ucn (cpp_reader *pfile, const uc
  case, no diagnostic is emitted, and the return value of FALSE should cause
  a new token to be formed.
  
-Unlike _cpp_valid_ucn, this will never be called when lexing a string; only

-a potential identifier, or a CPP_OTHER token.  NST is unused in the latter
-case.
+_cpp_valid_utf8 can be called when lexing a potential identifier, or a
+CPP_OTHER token or for the purposes of -Winvalid-utf8 warning in string or
+character literals.  NST is unused when not in a potential identifier.
  
  As in _cpp_valid_ucn, IDENTIFIER_POS is 0 when not in an identifier, 1 for

  the start of an identifier, or 2 otherwise.  */
--- libcpp/lex.cc.jj2022-08-31 10:19:45.327451236 +0200
+++ libcpp/lex.cc   2022-08-31 12:45:47.929906159 +0200
@@ -50,6 +50,9 @@ static const struct token_spelling token
  #define TOKEN_SPELL(token) (token_spellings[(token)->type].category)
  #define TOKEN_NAME(token) (token_spellings[(token)->type].name)
  
+/* ISO 10646 defines the UCS codespace as the range 0-0x10 inclusive.  */

+#define UCS_LIMIT 0x10
+
  static void add_line_note (cpp_buffer *, const uchar *, unsigned int);
  static int skip_line_comment (cpp_reader *);

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

Hi, Joseph,

Thanks a lot for your comment.

> On Aug 30, 2022, at 6:53 PM, Joseph Myers  wrote:
> 
> On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote:
> 
>> Hi, Joseph and Nathan,
>> 
>> Could you please review the C and C++ FE parts of the patch?
>> 
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html
> 
> I think some work is still needed on the diagnostic wording.
> 
>> +  "%qE attribute may not be specified for a non array field",
> 
> "non-array" not "non array".

Okay.

> 
>> +   "not supported with a ISO C before C99", name);
> 
> "a ISO C" is not proper usage.  I think something like "by ISO C before 
> C99" would be better.  Likewise "a ISO C++".
> 
> "!flag_isoc99" is more usual than "flag_isoc99 == 0".

Okay.

> 
>> +   "not supported with a GNU extension GNU89", name);
> 
> "a GNU extension" suggests a particular language feature, but I think 
> you're actually referring here to a whole language version rather than an 
> individual feature.

Is “not supported by GNU extension GNU89” better?

> 
> In any case, -std=gnu89 supports flexible array members.

Yes, but only [0],[1] are supported as flexible array members.  The C99 
flexible array member [] is not supported by GNU89, right?

Then, -fstrict-flex-arrays=3 is not supported by -std=gnu89.


>  So I'd expect 
> them to have exactly the same semantics as in C99, so disallowing a 
> particular feature for gnu89 here seems suspect.
> 
> In the manual, any literal code should be enclosed in @code{} or @samp{}.  
> That replaces the use of ASCII quotes "" that you currently have in the 
> documentation (that should never be used outside of @code, @samp and 
> similar).

Okay. Will update those places.
> 
>> +When -std=gnu89 is specified or C++ with GNU extension, only zero-length 
>> array
> 
> And @option{} should be used around "-std=gnu89" here (except as noted 
> above, I think it's suspect to disallow parts of this feature for gnu89).

Okay. Will update.
> 
>> +language. FOR ISO C before C99 and ISO C++, no language support for the 
>> flexible
> 
> "FOR" should be "For".

Okay.

thanks.

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

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

On 8/31/22 4:22 AM, Kewen.Lin wrote:
> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>> -  tree src_type = TREE_TYPE (src_ptr);
>> +  tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>> +  ? build_pointer_type (vector_quad_type_node)
>> +  : build_pointer_type (vector_pair_type_node);
> 
> Nit: it seems we can use existing ptr_vector_quad_type_node and 
> ptr_vector_pair_type_node?
> I assume the const qualifier is fine since it's for disassembling.

That's actually what I started with, but I got some type of gimple
verification error which I can't remember what it said.  Let me put
that back temporarily and I'll grab the error message.

>> +  if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)
> 
> This line looks unexpected, the former is type char while the latter is type 
> __vector_pair *.
> 
> I guess you meant to compare the type of pointer type like: 
>
>TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE (src_type)
> 
> or even with mode like:
> 
>TYPE_MODE (TREE_TYPE (TREE_TYPE (src_ptr))) != TYPE_MODE (TREE_TYPE 
> (src_type))

Maybe?  However, if that is the case, how can it be working for me?
Let me throw this in the debugger and verify the types and I'll report
back with what I find.

>> +src_ptr = build1 (VIEW_CONVERT_EXPR, src_type, src_ptr);
> 
> Nit: NOP_EXPR seems to be better suited here for pointer conversion.

NOP_EXPR is new to me (I don't play in the middle-end that often).
Let me look around at some other uses of it and I'll give it a try.
Thanks!

Peter

[PATCH] Fortran: Add IEEE_SIGNBIT and IEEE_FMA functions

Hi,

These functions were added in Fortran 2018: 
https://gcc.gnu.org/wiki/Fortran2018Status
When it comes to floating-point and IEEE compliance, gfortran fully implements 
the 2003 and 2008 standards. In a series of patch, as time permits, I would 
like to add all Fortran 2018 features before the GCC 13 release process begins.

Regarding this patch, the functions are added to the IEEE_ARITHMETIC module, 
but are entirely expanded in the front-end, using GCC built-ins. They will 
benefit fully from middle-end optimisation where relevant, and on many targets 
FMA will reduce to a single instruction (as expected).

Regression-tested on x86_64-pc-linux-gnu. OK to commit?

FX




0001-fortran-Add-IEEE_SIGNBIT-and-IEEE_FMA-functions.patch
Description: Binary data

[committed] libstdc++: Add noexcept-specifier to std::reference_wrapper::operator()

Tested x86_64-linux, pushed to trunk.

-- >8 --

This isn't required by the standard, but there's an LWG issue suggesting
to add it.

Also use __invoke_result instead of result_of, to match the spec in
recent standards.

libstdc++-v3/ChangeLog:

* include/bits/refwrap.h (reference_wrapper::operator()): Add
noexcept-specifier and use __invoke_result instead of result_of.
* testsuite/20_util/reference_wrapper/invoke-noexcept.cc: New test.
---
 libstdc++-v3/include/bits/refwrap.h   |  3 ++-
 .../20_util/reference_wrapper/invoke-noexcept.cc  | 15 +++
 2 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 
libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-noexcept.cc

diff --git a/libstdc++-v3/include/bits/refwrap.h 
b/libstdc++-v3/include/bits/refwrap.h
index 8016f87478e..976902bc7bc 100644
--- a/libstdc++-v3/include/bits/refwrap.h
+++ b/libstdc++-v3/include/bits/refwrap.h
@@ -348,8 +348,9 @@ _GLIBCXX_MEM_FN_TRAITS(&& noexcept, false_type, true_type)
 
   template
_GLIBCXX20_CONSTEXPR
-   typename result_of<_Tp&(_Args&&...)>::type
+   typename __invoke_result<_Tp&, _Args...>::type
operator()(_Args&&... __args) const
+   noexcept(__is_nothrow_invocable<_Tp&, _Args...>::value)
{
 #if __cplusplus > 201703L
  if constexpr (is_object_v)
diff --git 
a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-noexcept.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-noexcept.cc
new file mode 100644
index 000..91b5d097f08
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-noexcept.cc
@@ -0,0 +1,15 @@
+// { dg-do compile { target c++11 } }
+
+// C++11 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
+
+#include 
+
+struct F
+{
+  int operator()() noexcept(true) { return 1; }
+  int operator()() const noexcept(false) { return 2; }
+};
+
+F f;
+static_assert( noexcept(std::ref(f)()) );
+static_assert( ! noexcept(std::cref(f)()) );
-- 
2.37.2

[committed] libstdc++: Improve comments in std::reference_wrapper tests

Tested x86_64-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* testsuite/20_util/reference_wrapper/invoke-2.cc: Improve
comments.
* testsuite/20_util/reference_wrapper/invoke-3.cc: Likewise.
* testsuite/20_util/reference_wrapper/invoke.cc: Likewise.
---
 libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc | 3 ++-
 libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc | 3 ++-
 libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc   | 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc
index 2741510e756..fd3430cf0a9 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-2.cc
@@ -16,7 +16,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// 20.6.4 function object return types [func.ret]
+// C++11 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
 #include 
 
 struct X
@@ -27,6 +27,7 @@ struct X
 
 void test01()
 {
+  // PR libstdc++/48521 std::result_of doesn't work with pointer to member
   typedef int (X::*mfp)(int);
   typedef int X::*mp;
   mfp m = ::f;
diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc
index e4124c9b57c..c25315b6751 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc
@@ -17,7 +17,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
+// C++11 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
 #include 
 
 struct ABC
@@ -33,4 +33,5 @@ struct Concrete : ABC
 Concrete c;
 ABC& abc = c;
 
+// PR libstdc++/57336 Cannot INVOKE a reference_wrapper around an abstract type
 auto b = std::cref(abc)();
diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc
index cd884fe66eb..b2abc812b79 100644
--- a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke.cc
@@ -17,6 +17,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
+// C++11 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
+
 #include 
 #include 
 #include 
-- 
2.37.2

Re: [PATCH 1/2] libstdc++: Implement ranges::adjacent_view from P2321R2