[PATCH] Value range: Add range op for __builtin_isfinite

[HAO CHEN GUI]

Hi,
  The former patch adds isfinite optab for __builtin_isfinite.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html

  Thus the builtin might not be folded at front end. The range op for
isfinite is needed for value range analysis. This patch adds them.

  Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
regressions. Is it OK for the trunk?

Thanks
Gui Haochen

ChangeLog
Value Range: Add range op for builtin isfinite

The former patch adds optab for builtin isfinite. Thus builtin isfinite might
not be folded at front end.  So the range op for isfinite is needed for value
range analysis.  This patch adds range op for builtin isfinite.

gcc/
* gimple-range-op.cc (class cfn_isfinite): New.
(op_cfn_finite): New variables.
(gimple_range_op_handler::maybe_builtin_call): Handle
CFN_BUILT_IN_ISFINITE.

gcc/testsuite/
* gcc/testsuite/gcc.dg/tree-ssa/range-isfinite.c: New test.


patch.diff
diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
index 9de130b4022..99c511728d3 100644
--- a/gcc/gimple-range-op.cc
+++ b/gcc/gimple-range-op.cc
@@ -1192,6 +1192,56 @@ public:
   }
 } op_cfn_isinf;

+//Implement range operator for CFN_BUILT_IN_ISFINITE
+class cnf_isfinite : public range_operator
+{
+public:
+  using range_operator::fold_range;
+  using range_operator::op1_range;
+  virtual bool fold_range (irange , tree type, const frange ,
+  const irange &, relation_trio) const override
+  {
+if (op1.undefined_p ())
+  return false;
+
+if (op1.known_isfinite ())
+  {
+   r.set_nonzero (type);
+   return true;
+  }
+
+if (op1.known_isnan ()
+   || op1.known_isinf ())
+  {
+   r.set_zero (type);
+   return true;
+  }
+
+return false;
+  }
+  virtual bool op1_range (frange , tree type, const irange ,
+ const frange &, relation_trio) const override
+  {
+if (lhs.zero_p ())
+  {
+   // The range is [-INF,-INF][+INF,+INF] NAN, but it can't be represented.
+   // Set range to varying
+   r.set_varying (type);
+   return true;
+  }
+
+if (!range_includes_zero_p ())
+  {
+   nan_state nan (false);
+   r.set (type, real_min_representable (type),
+  real_max_representable (type), nan);
+   return true;
+  }
+
+return false;
+  }
+} op_cfn_isfinite;
+
 // Implement range operator for CFN_BUILT_IN_
 class cfn_parity : public range_operator
 {
@@ -1288,6 +1338,11 @@ gimple_range_op_handler::maybe_builtin_call ()
   m_operator = _cfn_isinf;
   break;

+case CFN_BUILT_IN_ISFINITE:
+  m_op1 = gimple_call_arg (call, 0);
+  m_operator = _cfn_isfinite;
+  break;
+
 CASE_CFN_COPYSIGN_ALL:
   m_op1 = gimple_call_arg (call, 0);
   m_op2 = gimple_call_arg (call, 1);
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/range-isfinite.c 
b/gcc/testsuite/gcc.dg/tree-ssa/range-isfinite.c
new file mode 100644
index 000..f5dce0a0486
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/range-isfinite.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-evrp" } */
+
+#include 
+void link_error();
+
+void test1 (double x)
+{
+  if (x < __DBL_MAX__ && x > -__DBL_MAX__ && !__builtin_isfinite (x))
+link_error ();
+}
+
+void test2 (float x)
+{
+  if (x < __FLT_MAX__ && x > -__FLT_MAX__ && !__builtin_isfinite (x))
+link_error ();
+}
+
+void test3 (double x)
+{
+  if (__builtin_isfinite (x) && __builtin_isinf (x))
+link_error ();
+}
+
+void test4 (float x)
+{
+  if (__builtin_isfinite (x) && __builtin_isinf (x))
+link_error ();
+}
+
+/* { dg-final { scan-tree-dump-not "link_error" "evrp" } } */

[PATCH v2] match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 bit types [PR114666]

[Andrew Pinski]

The problem is `!a?b:c` pattern will create a COND_EXPR with an 1bit signed 
integer
which breaks patterns like `a?~t:t`. This rejects when we have a signed operand 
for
both patterns.

Note for GCC 15, I am going to look at the canonicalization of `a?~t:t` where t
was a constant since I think keeping it a COND_EXPR might be more canonical and
is what VPR produces from the same IR; if anything expand should handle which 
one
is better.

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

PR tree-optimization/114666

gcc/ChangeLog:

* match.pd (`!a?b:c`): Reject signed types for the condition.
(`a?~t:t`): Likewise.

gcc/testsuite/ChangeLog:

* gcc.c-torture/execute/bitfld-signed1-1.c: New test.

Signed-off-by: Andrew Pinski 
---
 gcc/match.pd|  6 +-
 .../gcc.c-torture/execute/bitfld-signed1-1.c| 13 +
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/bitfld-signed1-1.c

diff --git a/gcc/match.pd b/gcc/match.pd
index 15a1e7350d4..d401e7503e6 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -5895,7 +5895,10 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  /* !A ? B : C -> A ? C : B.  */
  (simplify
   (cnd (logical_inverted_value truth_valued_p@0) @1 @2)
-  (cnd @0 @2 @1)))
+  /* For CONDs, don't handle signed values here. */
+  (if (cnd == VEC_COND_EXPR
+   || TYPE_UNSIGNED (TREE_TYPE (@0)))
+   (cnd @0 @2 @1
 
 /* abs/negative simplifications moved from fold_cond_expr_with_comparison.
 
@@ -7095,6 +7098,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (cond @0 @1 @2)
  (with { bool wascmp; }
   (if (INTEGRAL_TYPE_P (type)
+   && TYPE_UNSIGNED (TREE_TYPE (@0))
&& bitwise_inverted_equal_p (@1, @2, wascmp)
&& (!wascmp || TYPE_PRECISION (type) == 1))
(if ((!TYPE_UNSIGNED (type) && TREE_CODE (type) == BOOLEAN_TYPE)
diff --git a/gcc/testsuite/gcc.c-torture/execute/bitfld-signed1-1.c 
b/gcc/testsuite/gcc.c-torture/execute/bitfld-signed1-1.c
new file mode 100644
index 000..b0ff120ea51
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/bitfld-signed1-1.c
@@ -0,0 +1,13 @@
+/* PR tree-optimization/114666 */
+/* We used to miscompile this to be always aborting
+   due to the use of the signed 1bit into the COND_EXPR. */
+
+struct {
+  signed a : 1;
+} b = {-1};
+char c;
+int main()
+{
+  if ((b.a ^ 1UL) < 3)
+__builtin_abort();
+}
-- 
2.43.0

Re: [PATCH] rs6000: Add OPTION_MASK_POWER8 [PR101865]

[Peter Bergner]

On 4/11/24 10:31 PM, Kewen.Lin wrote:
>> The passed bootstrap and regtest on powerpc64le-linux.  Ok for trunk?
> 
> Thanks for fixing this.  I guess it should go well on powerpc64-linux too,
> but since it's very late stage4 now, could you also test this on BE machine?

Will do, after making the changes suggested below.



>> +;; This option exists only to create its MASK.  It is not intended for 
>> users.
>> +mdo-not-use-this-option
>> +Target RejectNegative Mask(POWER8) Var(rs6000_isa_flags) WarnRemoved
>> +
> 
> I can understand the given name is to avoid users to use it, but it looks 
> odd, personally
> I'm inclined to mpower8 (or even mpower8-internal) even if it's more likely 
> to be used but
> it's a bit more meaningful (especially we already have mpower10), 
> theoretically speaking
> it's undocumented users shouldn't use it at all.

Sorry, I should have mentioned this, but I originally had it -mpower8, but given
it was an option we don't want users to use, Segher mentioned offline to give it
a name something like the above and not -mpower8.  I kind of like 
-mpower8-internal
now that you mention it, but I'd like Segher's input here whether he prefers
-mdo-not-use-this-option or -mpower8-internal or something else???



> And I think we want explicit "Undocumented" here, and WarnRemoved seems not 
> suitable here
> since it's for some option which worked before but then wasn't supported any 
> longer, but
> this one is new, may be "Warn(Don't use %qs)" instead?

Oops, yes, we want Undocumented here.  Thanks for catching that!
Good idea on the Warn versus WarnRemoved.


>> +/* { dg-options "-mdejagnu-cpu=power8 -mvsx -O2" } */
> 
> Nit: -O2 looks useless and can be dropped?

Ok, I'll drop it.


I'll make the changes above, modulo leaving the option name unchanged until
we hear from Segher on that and report back on the LE and BE testing.
Thanks!

Peter

Re: [PATCH] rs6000: Add OPTION_MASK_POWER8 [PR101865]

[Kewen.Lin]

Hi,

on 2024/4/12 06:15, Peter Bergner wrote:
> FYI: This patch is an update to Will Schmidt's patches to fix PR101865:
> 
>   https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601825.html
>   https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601823.html
> 
> ...taking into consideration patch reviews received than.  I also found
> a few more locations that needed patching, as well as simplifying the
> testsuite test cases by removing the need to scan for the predefined macros.
> 
> 
> 
> The bug in PR101865 is the _ARCH_PWR8 predefined macro is conditional upon
> TARGET_DIRECT_MOVE, which can be false for some -mcpu=power8 compiles if the
> -mno-altivec or -mno-vsx options are used.  The solution here is to create
> a new OPTION_MASK_POWER8 mask that is true for -mcpu=power8, regardless of
> Altivec or VSX enablement.
> 
> Unfortunately, the only way to create an OPTION_MASK_* mask is to create
> a new option, which we have done here, but marked it as WarnRemoved since
> we do not want users using it.  For stage1, we will look into how we can
> create ISA mask flags for use in the compiler without the need for explicit
> options.
> 
> The passed bootstrap and regtest on powerpc64le-linux.  Ok for trunk?

Thanks for fixing this.  I guess it should go well on powerpc64-linux too,
but since it's very late stage4 now, could you also test this on BE machine?

> 
> This is also broken on the release branches, so ok for backports after
> some burn-in time on trunk?
> 
> Peter
> 
> 
> 2024-04-11  Will Schmidt  
>   Peter Bergner  
> 
> gcc/
>   PR target/101865
>   * config/rs6000/rs6000-builtin.cc (rs6000_builtin_is_supported): Use
>   TARGET_POWER8.
>   * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Use
>   OPTION_MASK_POWER8.
>   * config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add OPTION_MASK_POWER8.
>   (ISA_2_7_MASKS_SERVER): Likewise.
>   * config/rs6000/rs6000.cc (rs6000_option_override_internal): Update
>   comment.  Use OPTION_MASK_POWER8 and TARGET_POWER8.
>   * config/rs6000/rs6000.h (TARGET_SYNC_HI_QI): Use TARGET_POWER8.
>   * config/rs6000/rs6000.md (define_attr "isa"): Add p8.
>   (define_attr "enabled"): Handle it.
>   (define_insn "prefetch"): Use TARGET_POWER8.
>   * config/rs6000/rs6000.opt (mdo-not-use-this-option): New.
> 
> gcc/testsuite/
>   PR target/101865
>   * gcc.target/powerpc/predefined-p7-novsx.c: New test.
>   * gcc.target/powerpc/predefined-p8-noaltivec-novsx.c: New test.
>   * gcc.target/powerpc/predefined-p8-noaltivec.c: New test.
>   * gcc.target/powerpc/predefined-p8-novsx.c: New test.
>   * gcc.target/powerpc/predefined-p8-pragma-vsx.c: New test.
>   * gcc.target/powerpc/predefined-p9-novsx.c: New test.
> 
> diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
> b/gcc/config/rs6000/rs6000-builtin.cc
> index e7d6204074c..320affd79e3 100644
> --- a/gcc/config/rs6000/rs6000-builtin.cc
> +++ b/gcc/config/rs6000/rs6000-builtin.cc
> @@ -165,7 +165,7 @@ rs6000_builtin_is_supported (enum rs6000_gen_builtins 
> fncode)
>  case ENB_P7_64:
>return TARGET_POPCNTD && TARGET_POWERPC64;
>  case ENB_P8:
> -  return TARGET_DIRECT_MOVE;
> +  return TARGET_POWER8;
>  case ENB_P8V:
>return TARGET_P8_VECTOR;
>  case ENB_P9:
> diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc
> index 647f20de7f2..bd493ab87c5 100644
> --- a/gcc/config/rs6000/rs6000-c.cc
> +++ b/gcc/config/rs6000/rs6000-c.cc
> @@ -429,7 +429,7 @@ rs6000_target_modify_macros (bool define_p, HOST_WIDE_INT 
> flags)
>  rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR6");
>if ((flags & OPTION_MASK_POPCNTD) != 0)
>  rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR7");
> -  if ((flags & OPTION_MASK_P8_VECTOR) != 0)
> +  if ((flags & OPTION_MASK_POWER8) != 0)
>  rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR8");
>if ((flags & OPTION_MASK_MODULO) != 0)
>  rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR9");
> diff --git a/gcc/config/rs6000/rs6000-cpus.def 
> b/gcc/config/rs6000/rs6000-cpus.def
> index 45dd5a85901..6ee678e69c3 100644
> --- a/gcc/config/rs6000/rs6000-cpus.def
> +++ b/gcc/config/rs6000/rs6000-cpus.def
> @@ -47,6 +47,7 @@
> fusion here, instead set it in rs6000.cc if we are tuning for a power8
> system.  */
>  #define ISA_2_7_MASKS_SERVER (ISA_2_6_MASKS_SERVER   \
> +  | OPTION_MASK_POWER8   \
>| OPTION_MASK_P8_VECTOR\
>| OPTION_MASK_CRYPTO   \
>| OPTION_MASK_EFFICIENT_UNALIGNED_VSX  \
> @@ -130,6 +131,7 @@
>| OPTION_MASK_MODULO   \
>| OPTION_MASK_MULHW\
>| OPTION_MASK_NO_UPDATE 

[PATCH 1/1] RISC-V: Add Zfbfmin extension to the -march= option

[Xiao Zeng]

This patch would like to add new sub extension (aka Zfbfmin) to the
-march= option. It introduces a new data type BF16.

1 The Zfbfmin extension depend on 'F', and the FLH, FSH, FMV.X.H, and
FMV.H.X instructions as defined in the Zfh extension.

2 The Zfhmin extension includes the following instructions from the
Zfh extension: FLH, FSH, FMV.X.H, FMV.H.X, FCVT.S.H, and FCVT.H.S.

3 Zfhmin extension depend on 'F'.

4 Simply put, just make Zfbfmin dependent on Zfhmin.

Perhaps in the future, we could propose making the FLH, FSH, FMV.X.H, and
FMV.H.X instructions an independent extension to achieve precise dependency
relationships for the Zfbfmin.

You can locate more information about Zfbfmin from below spec doc.



Below test are passed for this patch
* The riscv fully regression test.
---
 gcc/common/config/riscv/riscv-common.cc|  3 ++
 gcc/config/riscv/riscv.opt |  2 +
 gcc/testsuite/gcc.target/riscv/arch-35.c   |  5 +++
 gcc/testsuite/gcc.target/riscv/arch-36.c   |  5 +++
 gcc/testsuite/gcc.target/riscv/predef-34.c | 47 ++
 gcc/testsuite/gcc.target/riscv/predef-35.c | 47 ++
 6 files changed, 109 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-35.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/arch-36.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/predef-34.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/predef-35.c

diff --git a/gcc/common/config/riscv/riscv-common.cc 
b/gcc/common/config/riscv/riscv-common.cc
index 43b7549e3ec..49c4783eaf2 100644
--- a/gcc/common/config/riscv/riscv-common.cc
+++ b/gcc/common/config/riscv/riscv-common.cc
@@ -155,6 +155,7 @@ static const riscv_implied_info_t riscv_implied_info[] =
   {"zvksed", "zve32x"},
   {"zvksh",  "zve32x"},
 
+  {"zfbfmin", "zfhmin"},
   {"zfh", "zfhmin"},
   {"zfhmin", "f"},
 
@@ -331,6 +332,7 @@ static const struct riscv_ext_version 
riscv_ext_version_table[] =
   {"zvl32768b", ISA_SPEC_CLASS_NONE, 1, 0},
   {"zvl65536b", ISA_SPEC_CLASS_NONE, 1, 0},
 
+  {"zfbfmin",   ISA_SPEC_CLASS_NONE, 1, 0},
   {"zfh",   ISA_SPEC_CLASS_NONE, 1, 0},
   {"zfhmin",ISA_SPEC_CLASS_NONE, 1, 0},
   {"zvfbfmin",  ISA_SPEC_CLASS_NONE, 1, 0},
@@ -1698,6 +1700,7 @@ static const riscv_ext_flag_table_t 
riscv_ext_flag_table[] =
   {"zvl32768b", _options::x_riscv_zvl_flags, MASK_ZVL32768B},
   {"zvl65536b", _options::x_riscv_zvl_flags, MASK_ZVL65536B},
 
+  {"zfbfmin",   _options::x_riscv_zf_subext, MASK_ZFBFMIN},
   {"zfhmin",_options::x_riscv_zf_subext, MASK_ZFHMIN},
   {"zfh",   _options::x_riscv_zf_subext, MASK_ZFH},
   {"zvfbfmin",  _options::x_riscv_zf_subext, MASK_ZVFBFMIN},
diff --git a/gcc/config/riscv/riscv.opt b/gcc/config/riscv/riscv.opt
index 8da0764eb4b..5c96e951d45 100644
--- a/gcc/config/riscv/riscv.opt
+++ b/gcc/config/riscv/riscv.opt
@@ -393,6 +393,8 @@ Mask(ZICBOP) Var(riscv_zicmo_subext)
 TargetVariable
 int riscv_zf_subext
 
+Mask(ZFBFMIN)  Var(riscv_zf_subext)
+
 Mask(ZFHMIN)  Var(riscv_zf_subext)
 
 Mask(ZFH) Var(riscv_zf_subext)
diff --git a/gcc/testsuite/gcc.target/riscv/arch-35.c 
b/gcc/testsuite/gcc.target/riscv/arch-35.c
new file mode 100644
index 000..6c783769666
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-35.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv32i_zfbfmin -mabi=ilp32f" } */
+int foo()
+{
+}
diff --git a/gcc/testsuite/gcc.target/riscv/arch-36.c 
b/gcc/testsuite/gcc.target/riscv/arch-36.c
new file mode 100644
index 000..cbdccf12807
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/arch-36.c
@@ -0,0 +1,5 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64i_zfbfmin -mabi=lp64f" } */
+int foo()
+{
+}
diff --git a/gcc/testsuite/gcc.target/riscv/predef-34.c 
b/gcc/testsuite/gcc.target/riscv/predef-34.c
new file mode 100644
index 000..0a993271f7f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/predef-34.c
@@ -0,0 +1,47 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=rv32i_zfbfmin -mabi=ilp32f -mcmodel=medlow 
-misa-spec=20191213" } */
+
+int main () {
+
+#ifndef __riscv_arch_test
+#error "__riscv_arch_test"
+#endif
+
+#if __riscv_xlen != 32
+#error "__riscv_xlen"
+#endif
+
+#if !defined(__riscv_i)
+#error "__riscv_i"
+#endif
+
+#if !defined(__riscv_f)
+#error "__riscv_f"
+#endif
+
+#if !defined(__riscv_zfhmin)
+#error "__riscv_zfhmin"
+#endif
+
+#if !defined(__riscv_zfbfmin)
+#error "__riscv_zfbfmin"
+#endif
+
+#if defined(__riscv_v)
+#error "__riscv_v"
+#endif
+
+#if defined(__riscv_d)
+#error "__riscv_d"
+#endif
+
+#if defined(__riscv_c)
+#error "__riscv_c"
+#endif
+
+#if defined(__riscv_a)
+#error "__riscv_a"
+#endif
+
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/riscv/predef-35.c 
b/gcc/testsuite/gcc.target/riscv/predef-35.c
new file mode 100644
index 000..76b328a8932
--- /dev/null
+++ 

[PATCH] Optab: add isfinite_optab for __builtin_isfinite

[HAO CHEN GUI]

Hi,
  This patch adds an optab for __builtin_isfinite. The finite check can be
implemented on rs6000 by a single instruction. It needs an optab to be
expanded to the certain sequence of instructions.

  The subsequent patches will implement the expand on rs6000.

  Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no
regressions. Is this OK for next stage-1?

Thanks
Gui Haochen

ChangeLog
optab: Add isfinite_optab for isfinite builtin

gcc/
* builtins.cc (interclass_mathfn_icode): Set optab to isfinite_optab
for isfinite builtin.
* optabs.def (isfinite_optab): New.

patch.diff
diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index d2786f207b8..5262aa01660 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -2459,8 +2459,9 @@ interclass_mathfn_icode (tree arg, tree fndecl)
   errno_set = true; builtin_optab = ilogb_optab; break;
 CASE_FLT_FN (BUILT_IN_ISINF):
   builtin_optab = isinf_optab; break;
-case BUILT_IN_ISNORMAL:
 case BUILT_IN_ISFINITE:
+  builtin_optab = isfinite_optab; break;
+case BUILT_IN_ISNORMAL:
 CASE_FLT_FN (BUILT_IN_FINITE):
 case BUILT_IN_FINITED32:
 case BUILT_IN_FINITED64:
diff --git a/gcc/optabs.def b/gcc/optabs.def
index ad14f9328b9..dcd77315c2a 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -352,6 +352,7 @@ OPTAB_D (fmod_optab, "fmod$a3")
 OPTAB_D (hypot_optab, "hypot$a3")
 OPTAB_D (ilogb_optab, "ilogb$a2")
 OPTAB_D (isinf_optab, "isinf$a2")
+OPTAB_D (isfinite_optab, "isfinite$a2")
 OPTAB_D (issignaling_optab, "issignaling$a2")
 OPTAB_D (ldexp_optab, "ldexp$a3")
 OPTAB_D (log10_optab, "log10$a2")

RE: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

[Li, Pan2]

Thanks Edwin, should be one silly mistake, will fix it ASAP.

Pan

-Original Message-
From: Edwin Lu  
Sent: Friday, April 12, 2024 5:20 AM
To: Li, Pan2 ; Bernd Edlinger ; 
Kito Cheng ; juzhe.zh...@rivai.ai
Cc: gcc-patches 
Subject: Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode 
switch

On 4/11/2024 5:45 AM, Li, Pan2 wrote:
> Thanks for reporting this. Just take a look from my test log that 930623-1.c 
> is all pass.
> 
> Thus I bet this difference comes from the build option --with-arch=rv32imac 
> but my test script take rv64gcv.
> 
>> I've built the git revision f3fdcf4a37a with
>> ../gcc-trunk/configure --target=riscv-unknown-elf 
>> --prefix=/home/ed/gnu/riscv-unknown-elf --enable-languages=c,c++ 
>> --disable-multilib --with-arch=rv32imac --with-abi=ilp32
> 
>> I am a bit surprised since the target is not supposed to support floating 
>> point
>> or vector instructions AFAIK.
> 
> Because you specify rv32imac, with doesn't include f/d/v extension, aka 
> single/double floating point and vector extension. Thus, related 
> functionality are disabled.
> 
>> The issue does not happen with gcc-trunk from yesterday.
> 
> Ack, will look into it.
> 
> Pan
>  
Hi Pan,

Our postcommit-ci found that it breaks for non-vector targets on rv32/64 
newlib/linux https://github.com/patrick-rivos/gcc-postcommit-ci/issues/757.

The patchwork precommit-ci also appeared to have flagged it 
https://github.com/ewlu/gcc-precommit-ci/issues/1417#issuecomment-2048846532

Edwin

[wwwdocs] Update cxx-dr-status page

[Marek Polacek]

A big update.  I posted a script to generate new entries and check
the existing separately.

W3 validated.  Pushed.

commit 9e32f911b70a8c2303b9b60679ce337896ccffdd
Author: Marek Polacek 
Date:   Thu Apr 11 21:18:23 2024 -0400

cxx-dr-status: Update from C++ Core Language Issue TOC, Revision 113

diff --git a/htdocs/projects/cxx-dr-status.html 
b/htdocs/projects/cxx-dr-status.html
index b63c47df..fb3046cd 100644
--- a/htdocs/projects/cxx-dr-status.html
+++ b/htdocs/projects/cxx-dr-status.html
@@ -61,19 +61,18 @@
   ?
   
 
-
+
   https://wg21.link/cwg6;>6
-  open
-  Should the optimization that allows a class object to alias another 
- object also allow the case of a parameter in an inline function to 
alias its argument?
-  -
+  NAD
+  Should the optimization that allows a class object to alias another 
object also allow the case of a parameter in an inline function to alias its 
argument?
+  N/A
   
 
 
   https://wg21.link/cwg7;>7
   NAD
   Can a class with a private virtual base class be derived from?
-  ?
+  No
   
 
 
@@ -1212,7 +1211,7 @@
 
 
   https://wg21.link/cwg170;>170
-  tentatively ready
+  DRWP
   Pointer-to-member conversions
   ?
   
@@ -1644,19 +1643,19 @@
   ?
   
 
-
+
   https://wg21.link/cwg232;>232
-  drafting
+  NAD
   Is indirection through a null pointer undefined behavior?
-  -
+  N/A
   
 
-
+
   https://wg21.link/cwg233;>233
-  open
+  drafting
   References vs pointers in UDC overload resolution
-  -
-  
+  No
+  https://gcc.gnu.org/PR114697;>PR114697
 
 
   https://wg21.link/cwg234;>234
@@ -3104,11 +3103,11 @@
   ?
   
 
-
+
   https://wg21.link/cwg440;>440
-  open
+  NAD
   Allow implicit pointer-to-member conversion on nontype template 
argument
-  -
+  N/A
   
 
 
@@ -3195,11 +3194,11 @@
   ?
   
 
-
+
   https://wg21.link/cwg453;>453
-  drafting
+  tentatively ready
   References may only bind to "valid" objects
-  -
+  ?
   
 
 
@@ -3237,11 +3236,11 @@
   No
   https://gcc.gnu.org/PR96138;>PR96138
 
-
+
   https://wg21.link/cwg459;>459
-  open
+  NAD
   Hiding of template parameters by base class members
-  -
+  N/A
   
 
 
@@ -3335,11 +3334,11 @@
   -
   
 
-
+
   https://wg21.link/cwg473;>473
-  open
+  NAD
   Block-scope declarations of allocator functions
-  -
+  N/A
   
 
 
@@ -3552,11 +3551,11 @@
   -
   
 
-
+
   https://wg21.link/cwg504;>504
-  open
+  NAD
   Should use of a variable in its own initializer require a 
diagnostic?
-  -
+  ?
   https://gcc.gnu.org/PR18635;>PR18635
 
 
@@ -3720,11 +3719,11 @@
   ?
   
 
-
+
   https://wg21.link/cwg528;>528
-  open
+  NAD
   Why are incomplete class types not allowed with 
typeid?
-  -
+  N/A
   
 
 
@@ -3752,7 +3751,7 @@
   https://wg21.link/cwg532;>532
   C++11
   Member/nonmember operator template partial ordering
-  ?
+  14
   
 
 
@@ -4504,11 +4503,11 @@
   ?
   
 
-
+
   https://wg21.link/cwg640;>640
-  open
+  NAD
   Accessing destroyed local objects of static storage duration
-  -
+  N/A
   
 
 
@@ -5050,11 +5049,11 @@
   ?
   
 
-
+
   https://wg21.link/cwg718;>718
-  open
+  NAD
   Non-class, non-function friend declarations
-  -
+  N/A
   
 
 
@@ -6326,9 +6325,9 @@
 
 
   https://wg21.link/cwg900;>900
-  DRWP
+  C++23
   Lifetime of temporaries in range-based for
-  ?
+  No
   
 
 
@@ -7214,11 +7213,11 @@
   N/A
   
 
-
+
   https://wg21.link/cwg1027;>1027
-  drafting
+  review
   Type consistency and reallocation of scalar types
-  -
+  ?
   
 
 
@@ -7293,7 +7292,7 @@
 
 
   https://wg21.link/cwg1038;>1038
-  review
+  DR
   Overload resolution of x.static_func
   ?
   
@@ -7650,7 +7649,7 @@
 
 
   https://wg21.link/cwg1089;>1089
-  drafting
+  open
   Template parameters in member selections
   -
   
@@ -8812,7 +8811,7 @@
 
 
   https://wg21.link/cwg1255;>1255
-  open
+  drafting
   Definition problems with constexpr functions
   -
   
@@ -9498,7 +9497,7 @@
 
 
   https://wg21.link/cwg1353;>1353
-  tentatively ready
+  DRWP
   Array and variant members and deleted special member functions
   ?
   
@@ -9671,11 +9670,11 @@
   ?
   
 
-
+
   

[PATCH] contrib: add cxx-dr-table.sh

[Marek Polacek]

Ok for trunk?

-- >8 --
I use this script to keep 
up-to-date.  I thought it might be good to have it in contrib/, so I've
polished it a little bit.

contrib/ChangeLog:

* cxx-dr-table.sh: New file.
---
 contrib/cxx-dr-table.sh | 108 
 1 file changed, 108 insertions(+)
 create mode 100755 contrib/cxx-dr-table.sh

diff --git a/contrib/cxx-dr-table.sh b/contrib/cxx-dr-table.sh
new file mode 100755
index 000..9d67d176cad
--- /dev/null
+++ b/contrib/cxx-dr-table.sh
@@ -0,0 +1,108 @@
+#!/bin/bash
+# Script to check/update 
+# from .
+# Use --generate only to add new DRs; don't use it to update the existing
+# ones because it would rewrite the Notes column.
+# Use --check to check if the existing entries need to be updated.
+# May need $ iconv -f iso-8859-1 -t utf-8 cwg_toc.html > cwg_toc2.html
+
+# Written by Marek Polacek 
+
+AWK=/usr/bin/awk
+DIFF=/usr/bin/vimdiff
+SED=/usr/bin/sed
+
+usage()
+{
+  echo "Usage: $0 --check cwg_toc.html 
~/src/gcc-wwwdocs/htdocs/projects/cxx-dr-status.html"
+  echo "   or: $0 --generate cwg_toc.html"
+}
+
+fatal_usage()
+{
+  usage >&2
+  exit 1
+}
+
+# Generate new DR entries.
+do_generate() {
+  $AWK '/A NAME=/{
+# 2838
+num = gensub(/(<.+>)(<.+>)(<.+>)(.+)(<.+>)/, "\\4", "g", $0)
+getline
+# Eat 
+getline
+# Eat 6.7.6
+getline
+# open
+status = gensub(/(<.+>)(.+)(<.+>)/, "\\2", "g", $0)
+getline
+# Eat 
+getline
+title = $0
+
+# Generate the HTML fragment.
+if (status == "open" || status == "drafting") {
+  print ""
+} else {
+  print ""
+}
+print "  https://wg21.link/cwg; num "\">" num ""
+print "  " status ""
+print "  " title ""
+if (status == "open" || status == "drafting") {
+  print "  -"
+} else {
+  print "  ?"
+}
+print "  "
+print ""
+  }' $1
+}
+
+# Check existing DR entries against the ISO version.
+do_check() {
+  # Generate a table from the upstream table: DR# + status + summary
+  # First, fix the quotes.
+  $SED -i $1 -e 's/\(\|\)/"/g'
+  $AWK '/A NAME=/{ print; getline; getline; getline; print; getline; getline; 
print }' $1 | \
+  $AWK -v RS='<[^>]+>' -v ORS= '1' | iconv -f UTF-8 -t ASCII//TRANSLIT > $tmp1
+
+  # Generate a table from our table: DR# + status + summary
+  $AWK '/wg21.link.cwg/{ print; getline; print; getline; print }' $2 | \
+  $AWK -v RS='<[^>]+>' -v ORS= '1' > $tmp2
+  $SED -i $tmp2 -e 's/^[ \t]*//'
+
+  # Compare the tables.
+  $DIFF $tmp1 $tmp2
+}
+
+if [ $# -lt 2 ]; then
+  fatal_usage
+fi
+
+tmp1="$(mktemp)"
+tmp2="$(mktemp)"
+
+cleanup() {
+  rm -f -- "$tmp1" "$tmp2"
+}
+
+trap cleanup 0
+
+case "$1" in
+  -c | --check)
+if [ $# -lt 3 ]; then
+  fatal_usage
+fi
+do_check "$2" "$3"
+;;
+  -g | --generate)
+do_generate "$2"
+;;
+  *)
+fatal_usage
+;;
+esac
+
+exit

base-commit: d1a21a6f9474e519926d20a7c6d664be03aff3ee
-- 
2.44.0

[PATCH 3/3] c++/modules: Propagate hidden flag on decls from partitions

[Nathaniel Shead]

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

-- >8 --

While working on some other fixes I noticed that the partition handling
code used the wrong flag to propagate OVL_HIDDEN_P on exported bindings
from partitions. This patch fixes that, and renames the flag to be
clearer.

gcc/cp/ChangeLog:

* name-lookup.cc (walk_module_binding): Use the
partition-specific hidden flag instead of the top-level
decl_hidden.

gcc/testsuite/ChangeLog:

* g++.dg/modules/using-16_a.C: New test.
* g++.dg/modules/using-16_b.C: New test.
* g++.dg/modules/using-16_c.C: New test.

Signed-off-by: Nathaniel Shead 
---
 gcc/cp/name-lookup.cc | 10 +-
 gcc/testsuite/g++.dg/modules/using-16_a.C | 11 +++
 gcc/testsuite/g++.dg/modules/using-16_b.C | 12 
 gcc/testsuite/g++.dg/modules/using-16_c.C | 11 +++
 4 files changed, 39 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/using-16_a.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-16_b.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-16_c.C

diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc
index 7af7f00e34c..b7746938e1b 100644
--- a/gcc/cp/name-lookup.cc
+++ b/gcc/cp/name-lookup.cc
@@ -4274,19 +4274,19 @@ walk_module_binding (tree binding, bitmap partitions,
 
count += callback (btype, flags, data);
  }
-   bool hidden = STAT_DECL_HIDDEN_P (bind);
+   bool part_hidden = STAT_DECL_HIDDEN_P (bind);
for (ovl_iterator iter (MAYBE_STAT_DECL (STAT_DECL (bind)));
 iter; ++iter)
  {
if (iter.hidden_p ())
- hidden = true;
+ part_hidden = true;
gcc_checking_assert
- (!(hidden && DECL_IS_UNDECLARED_BUILTIN (*iter)));
+ (!(part_hidden && DECL_IS_UNDECLARED_BUILTIN 
(*iter)));
 
WMB_Flags flags = WMB_None;
if (maybe_dups)
  flags = WMB_Flags (flags | WMB_Dups);
-   if (decl_hidden)
+   if (part_hidden)
  flags = WMB_Flags (flags | WMB_Hidden);
if (iter.using_p ())
  {
@@ -4295,7 +4295,7 @@ walk_module_binding (tree binding, bitmap partitions,
  flags = WMB_Flags (flags | WMB_Export);
  }
count += callback (*iter, flags, data);
-   hidden = false;
+   part_hidden = false;
  }
  }
  }
diff --git a/gcc/testsuite/g++.dg/modules/using-16_a.C 
b/gcc/testsuite/g++.dg/modules/using-16_a.C
new file mode 100644
index 000..25d8bca5d1c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-16_a.C
@@ -0,0 +1,11 @@
+// { dg-additional-options "-fmodules-ts" }
+// { dg-module-cmi M:S }
+
+export module M:S;
+
+namespace foo {
+  // propagate hidden from partitions
+  export struct S {
+friend void f(S);
+  };
+};
diff --git a/gcc/testsuite/g++.dg/modules/using-16_b.C 
b/gcc/testsuite/g++.dg/modules/using-16_b.C
new file mode 100644
index 000..3f704a913f4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-16_b.C
@@ -0,0 +1,12 @@
+// { dg-additional-options "-fmodules-ts -Wno-global-module" }
+// { dg-module-cmi M }
+
+module;
+namespace bar {
+  void f(int);
+}
+export module M;
+export import :S;
+namespace foo {
+  export using bar::f;
+}
diff --git a/gcc/testsuite/g++.dg/modules/using-16_c.C 
b/gcc/testsuite/g++.dg/modules/using-16_c.C
new file mode 100644
index 000..5e46cd16013
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-16_c.C
@@ -0,0 +1,11 @@
+// { dg-additional-options "-fmodules-ts" }
+import M;
+
+int main() {
+  // this should be hidden and fail
+  foo::f(foo::S{});  // { dg-error "cannot convert" }
+
+  // but these should be legal
+  foo::f(10);
+  f(foo::S{});
+}
-- 
2.43.2

[PATCH 2/3] c++/modules: Propagate using decls from partitions

[Nathaniel Shead]

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

-- >8 --

The modules code currently neglects to set OVL_USING_P on the dependency
created for a using-decl, which causes it not to remember that the
OVL_EXPORT_P flag had been set on it when emitted from the primary
interface unit. This patch ensures that it occurs.

gcc/cp/ChangeLog:

* module.cc (depset::hash::add_binding_entity): Propagate
OVL_USING_P for using-declarations.

gcc/testsuite/ChangeLog:

* g++.dg/modules/using-15_a.C: New test.
* g++.dg/modules/using-15_b.C: New test.
* g++.dg/modules/using-15_c.C: New test.

Signed-off-by: Nathaniel Shead 
---
 gcc/cp/module.cc  |  4 
 gcc/testsuite/g++.dg/modules/using-15_a.C | 13 +
 gcc/testsuite/g++.dg/modules/using-15_b.C |  5 +
 gcc/testsuite/g++.dg/modules/using-15_c.C |  7 +++
 4 files changed, 29 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/modules/using-15_a.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-15_b.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-15_c.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 9d054c4c792..527c9046c67 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -12915,10 +12915,12 @@ depset::hash::add_binding_entity (tree decl, 
WMB_Flags flags, void *data_)
/* Ignore NTTP objects.  */
return false;
 
+  bool unscoped_enum_const_p = false;
   if (!(flags & WMB_Using) && CP_DECL_CONTEXT (decl) != data->ns)
{
  /* A using that lost its wrapper or an unscoped enum
 constant.  */
+ unscoped_enum_const_p = (TREE_CODE (decl) == CONST_DECL);
  flags = WMB_Flags (flags | WMB_Using);
  if (DECL_MODULE_EXPORT_P (TREE_CODE (decl) == CONST_DECL
? TYPE_NAME (TREE_TYPE (decl))
@@ -12979,6 +12981,8 @@ depset::hash::add_binding_entity (tree decl, WMB_Flags 
flags, void *data_)
   if (flags & WMB_Using)
{
  decl = ovl_make (decl, NULL_TREE);
+ if (!unscoped_enum_const_p)
+   OVL_USING_P (decl) = true;
  if (flags & WMB_Export)
OVL_EXPORT_P (decl) = true;
}
diff --git a/gcc/testsuite/g++.dg/modules/using-15_a.C 
b/gcc/testsuite/g++.dg/modules/using-15_a.C
new file mode 100644
index 000..23895bd8c4a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-15_a.C
@@ -0,0 +1,13 @@
+// { dg-additional-options "-fmodules-ts -Wno-global-module" }
+// { dg-module-cmi M:a }
+
+module;
+namespace foo {
+  void a();
+};
+export module M:a;
+
+namespace bar {
+  // propagate usings from partitions
+  export using foo::a;
+};
diff --git a/gcc/testsuite/g++.dg/modules/using-15_b.C 
b/gcc/testsuite/g++.dg/modules/using-15_b.C
new file mode 100644
index 000..a88f86af61f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-15_b.C
@@ -0,0 +1,5 @@
+// { dg-additional-options "-fmodules-ts" }
+// { dg-module-cmi M }
+
+export module M;
+export import :a;
diff --git a/gcc/testsuite/g++.dg/modules/using-15_c.C 
b/gcc/testsuite/g++.dg/modules/using-15_c.C
new file mode 100644
index 000..0651efffc91
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-15_c.C
@@ -0,0 +1,7 @@
+// { dg-additional-options "-fmodules-ts" }
+import M;
+
+int main() {
+  bar::a();
+  foo::a();  // { dg-error "not been declared" }
+}
-- 
2.43.2

[PATCH 1/3] c++/modules: Only emit exported GMF usings [PR114600]

[Nathaniel Shead]

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

-- >8 --

A typo in r14-6978 made us emit too many things. This ensures that we
don't emit using-declarations from the GMF that we don't need to.

PR c++/114600

gcc/cp/ChangeLog:

* module.cc (depset::hash::add_binding_entity): Require both
WMB_Using and WMB_Export for GMF entities.

gcc/testsuite/ChangeLog:

* g++.dg/modules/using-14.C: New test.

Signed-off-by: Nathaniel Shead 
Co-authored-by: Patrick Palka 
---
 gcc/cp/module.cc|  2 +-
 gcc/testsuite/g++.dg/modules/using-14.C | 14 ++
 2 files changed, 15 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/using-14.C

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 4e91fa6e052..9d054c4c792 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -12892,7 +12892,7 @@ depset::hash::add_binding_entity (tree decl, WMB_Flags 
flags, void *data_)
inner = DECL_TEMPLATE_RESULT (inner);
 
   if ((!DECL_LANG_SPECIFIC (inner) || !DECL_MODULE_PURVIEW_P (inner))
- && !(flags & (WMB_Using | WMB_Export)))
+ && !((flags & WMB_Using) && (flags & WMB_Export)))
/* Ignore global module fragment entities unless explicitly
   exported with a using declaration.  */
return false;
diff --git a/gcc/testsuite/g++.dg/modules/using-14.C 
b/gcc/testsuite/g++.dg/modules/using-14.C
new file mode 100644
index 000..0e15a952de5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/modules/using-14.C
@@ -0,0 +1,14 @@
+// PR c++/114600
+// { dg-additional-options "-fmodules-ts -Wno-global-module 
-fdump-lang-module" }
+// { dg-module-cmi M }
+
+module;
+namespace std {
+  template struct A { int n; };
+  template A f();
+  namespace __swappable_details { using std::f; }
+}
+export module M;
+
+// The whole GMF should be discarded here
+// { dg-final { scan-lang-dump "Wrote 0 clusters" module } }
-- 
2.43.2

[PATCH 0/3] c++/modules: Fix some small issues with exported using-decls

[Nathaniel Shead]

This patch series fixes a few issues with exported using-declarations that have
come up recently.

I was hoping to fix PR114683 and PR114685 as well, but the issues there look to
be much more involved and I'm not yet sure how to handle them.  They're
ultimately caused by using-declarations just inserting the value directly into
the given scope without any wrapping for non-functions, which means that
there's no indication of which using-decls in what scopes are exported.  I'd
hoped to try to repurpose the stat_hack machinery for this but after trying for
a while it doesn't seem to be appropriate.

Nathaniel Shead (3):
  c++: Only emit exported GMF usings [PR114600]
  c++: Propagate using decls from partitions
  c++: Propagate hidden flag on decls from partitions

 gcc/cp/module.cc  |  6 +-
 gcc/cp/name-lookup.cc | 10 +-
 gcc/testsuite/g++.dg/modules/using-14.C   | 14 ++
 gcc/testsuite/g++.dg/modules/using-15_a.C | 13 +
 gcc/testsuite/g++.dg/modules/using-15_b.C |  5 +
 gcc/testsuite/g++.dg/modules/using-15_c.C |  7 +++
 gcc/testsuite/g++.dg/modules/using-16_a.C | 11 +++
 gcc/testsuite/g++.dg/modules/using-16_b.C | 12 
 gcc/testsuite/g++.dg/modules/using-16_c.C | 11 +++
 9 files changed, 83 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/modules/using-14.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-15_a.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-15_b.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-15_c.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-16_a.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-16_b.C
 create mode 100644 gcc/testsuite/g++.dg/modules/using-16_c.C

-- 
2.43.2

RE: [PATCH] match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 bit types [PR114666]

[Andrew Pinski (QUIC)]

> -Original Message-
> From: Richard Biener 
> Sent: Thursday, April 11, 2024 2:31 AM
> To: Andrew Pinski (QUIC) 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] match: Fix `!a?b:c` and `a?~t:t` patterns for signed 1 
> bit
> types [PR114666]
> 
> On Thu, Apr 11, 2024 at 10:43 AM Andrew Pinski
>  wrote:
> >
> > The issue here is that the `a?~t:t` pattern assumed (maybe correctly)
> > that a here was always going to be a unsigned boolean type. This fixes
> > the problem in both patterns to cast the operand to boolean type first.
> >
> > I should note that VRP seems to be keep on wanting to produce `a ==
> > 0?1:-2` from `((int)a) ^ 1` is a bit odd and partly is the cause of
> > the issue and there seems to be some disconnect on what should be the
> > canonical form. That will be something to look at for GCC 15.
> >
> > Bootstrapped and tested on x86_64-linux-gnu with no regressions.
> >
> > PR tree-optimization/114666
> >
> > gcc/ChangeLog:
> >
> > * match.pd (`!a?b:c`): Cast `a` to boolean type for cond for
> > gimple.
> > (`a?~t:t`): Cast `a` to boolean type before casting it
> > to the type.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.c-torture/execute/bitfld-signed1-1.c: New test.
> >
> > Signed-off-by: Andrew Pinski 
> > ---
> >  gcc/match.pd| 10 +++---
> >  .../gcc.c-torture/execute/bitfld-signed1-1.c| 13 +
> >  2 files changed, 20 insertions(+), 3 deletions(-)  create mode 100644
> > gcc/testsuite/gcc.c-torture/execute/bitfld-signed1-1.c
> >
> > diff --git a/gcc/match.pd b/gcc/match.pd index
> > 15a1e7350d4..ffc928b656a 100644
> > --- a/gcc/match.pd
> > +++ b/gcc/match.pd
> > @@ -5895,7 +5895,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >   /* !A ? B : C -> A ? C : B.  */
> >   (simplify
> >(cnd (logical_inverted_value truth_valued_p@0) @1 @2)
> > -  (cnd @0 @2 @1)))
> > +  /* For gimple, make sure the operand to COND is a boolean type,
> > + truth_valued_p will match 1bit integers too. */  (if (GIMPLE &&
> > + cnd == COND_EXPR)
> > +   (cnd (convert:boolean_type_node @0) @2 @1)
> > +   (cnd @0 @2 @1
> 
> This looks "wrong" for GENERIC still?

I tired without the GIMPLE check and ran into the testcase 
gcc.dg/torture/builtins-isinf-sign-1.c failing. Because the extra convert was 
blocking seeing both sides of an equal was the same (I didn't look into it 
further than that). So I decided to limit it to GIMPLE only.

> But this is not really part of the fix but deciding we should not have
> signed:1 as
> cond operand?  I'll note that truth_valued_p allows signed:1.
> 
> Maybe as minimal surgery add a TYPE_UNSIGNED (TREE_TPE (@0)) check here
> instead?

That might work, let me try.

> 
> >  /* abs/negative simplifications moved from
> fold_cond_expr_with_comparison.
> >
> > @@ -7099,8 +7103,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > && (!wascmp || TYPE_PRECISION (type) == 1))
> > (if ((!TYPE_UNSIGNED (type) && TREE_CODE (type) == BOOLEAN_TYPE)
> > || TYPE_PRECISION (type) == 1)
> > -(bit_xor (convert:type @0) @2)
> > -(bit_xor (negate (convert:type @0)) @2)
> > +(bit_xor (convert:type (convert:boolean_type_node @0)) @2)
> > +(bit_xor (negate (convert:type (convert:boolean_type_node @0)))
> > + @2)
> >  #endif
> 
> This looks OK, but then testing TYPE_UNSIGNED (TREE_TYPE (@0)) might be
> better?
> 

Let me do that just like the other pattern.

> Does this all just go downhill from what VRP creates?  That is, would IL
> checking have had a chance detecting it if we say signed:1 are not valid as
> condition?

Yes. So what VRP produces in the testcase is:
`_2 == 0 ? 1 : -2u` (where _2 is the signed 1bit integer).
Now maybe the COND_EXPR should be the canonical form for constants (but that is 
for a different patch I think, I added it to the list of things I should look 
into for GCC 15).

> 
> That said, the latter pattern definitely needs guarding/adjustment, I'm not
> sure the former is wrong?  Semantically [VEC_]COND_EXPR is op0 != 0 ? ... : 
> ...

I forgot to mention that to fix the bug only one of the 2 hunks are needed.

> 
> Richard.
> 
> >  /* Simplify pointer equality compares using PTA.  */ diff --git
> > a/gcc/testsuite/gcc.c-torture/execute/bitfld-signed1-1.c
> > b/gcc/testsuite/gcc.c-torture/execute/bitfld-signed1-1.c
> > new file mode 100644
> > index 000..b0ff120ea51
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.c-torture/execute/bitfld-signed1-1.c
> > @@ -0,0 +1,13 @@
> > +/* PR tree-optimization/114666 */
> > +/* We used to miscompile this to be always aborting
> > +   due to the use of the signed 1bit into the COND_EXPR. */
> > +
> > +struct {
> > +  signed a : 1;
> > +} b = {-1};
> > +char c;
> > +int main()
> > +{
> > +  if ((b.a ^ 1UL) < 3)
> > +__builtin_abort();
> > +}
> > --
> > 2.43.0
> >

Re: [PATCH] btf: fix a possibly misleading asm debug comment

[Indu Bhagat]

On 4/11/24 14:02, David Faust wrote:

This patch fixes a small error that could occur in the debug comment
when emitting a type reference with btf_asm_type_ref.

While working on a previous patch, I noticed the following in the asm
output for the test btf-bitfields-4.c:

...
.long   0x39# MEMBER 'c' idx=3
.long   0x6 # btm_type: (BTF_KIND_UNKN '')
...
.long   0x34# TYPE 6 BTF_KIND_INT 'char'

The type for member 'c' is correct, but the comment for the member
incorrectly reads "BTF_KIND_UNKN ''".  This was caused by an
incorrect type lookup in btf_asm_type_ref that could happen if the
source file has types which can be represented in CTF but not in BTF.

This patch fixes the issue by changing btf_asm_type_ref to work fully
in the CTF ID space until writing out the final BTF ID.  That ensures
types are correctly identified when writing the asm debug comments,
like the following fixed comment for the above case.

...
.long   0x39# MEMBER 'c' idx=3
.long   0x6 # btm_type: (BTF_KIND_INT 'char')
...

Note that there was no problem with the actual BTF information, the
only error was in the comment.  This patch does not change the output
BTF information, and no tests were affected.

Tested on x86_64-linux-gnu and x86_64-linux-gnu host for
bpf-unknown-none target. Sanity checked by compiling kernel BPF
selftests.



Thanks.

The code is easier to follow now too.

LGTM.


gcc/
* btfout.cc (btf_asm_type_ref): Convert IDs to BTF internally and
fix potentially looking up wrong type for asm debug comment info.
Split into...
(btf_asm_datasec_type_ref): ... This. New.
(btf_asm_datasec_entry): Call it here, instead of btf_asm_type_ref.
(btf_asm_type, btf_asm_array, btf_asm_varent, btf_asm_sou_member)
(btf_asm_func_arg, btf_asm_func_type): Adapt btf_asm_type_ref call.
---
  gcc/btfout.cc | 84 ++-
  1 file changed, 50 insertions(+), 34 deletions(-)

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index e1ada41b1f4..24bef3acfd1 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -738,36 +738,22 @@ btf_dmd_representable_bitfield_p (ctf_container_ref ctfc, 
ctf_dmdef_t *dmd)
  /* Asm'out a reference to another BTF type.  */
  
  static void

-btf_asm_type_ref (const char *prefix, ctf_container_ref ctfc, ctf_id_t ref_id)
+btf_asm_type_ref (const char *prefix, ctf_container_ref ctfc, ctf_id_t ctf_id)
  {
-  if (ref_id == BTF_VOID_TYPEID || ref_id == BTF_INVALID_TYPEID)
+  ctf_id_t btf_id = get_btf_id (ctf_id);
+  if (btf_id == BTF_VOID_TYPEID || btf_id == BTF_INVALID_TYPEID)
  {
/* There is no explicit void type.
 Also handle any invalid refs that made it this far, just in case.  */
-  dw2_asm_output_data (4, ref_id, "%s: void", prefix);
-}
-  else if (ref_id >= num_types_added + 1
-  && ref_id < num_types_added + num_vars_added + 1)
-{
-  /* Ref to a variable.  Should only appear in DATASEC entries.  */
-  ctf_id_t var_id = btf_relative_var_id (ref_id);
-  ctf_dvdef_ref dvd = ctfc->ctfc_vars_list[var_id];
-  dw2_asm_output_data (4, ref_id, "%s: (BTF_KIND_VAR '%s')",
-  prefix, dvd->dvd_name);
-
-}
-  else if (ref_id >= num_types_added + num_vars_added + 1)
-{
-  /* Ref to a FUNC record.  */
-  size_t func_id = btf_relative_func_id (ref_id);
-  ctf_dtdef_ref ref_type = (*funcs)[func_id];
-  dw2_asm_output_data (4, ref_id, "%s: (BTF_KIND_FUNC '%s')",
-  prefix, get_btf_type_name (ref_type));
+  dw2_asm_output_data (4, btf_id, "%s: void", prefix);
  }
else
  {
-  /* Ref to a standard type in the types list.  */
-  ctf_dtdef_ref ref_type = ctfc->ctfc_types_list[ref_id];
+  gcc_assert (btf_id <= num_types_added);
+
+  /* Ref to a standard type in the types list.  Note: take care that we
+must index the type list by the original CTF id, not the BTF id.  */
+  ctf_dtdef_ref ref_type = ctfc->ctfc_types_list[ctf_id];
uint32_t ref_kind
= get_btf_kind (CTF_V2_INFO_KIND (ref_type->dtd_data.ctti_info));
  
@@ -775,12 +761,43 @@ btf_asm_type_ref (const char *prefix, ctf_container_ref ctfc, ctf_id_t ref_id)

? btf_kind_name (BTF_KIND_ENUM)
: btf_kind_name (ref_kind);
  
-  dw2_asm_output_data (4, ref_id, "%s: (BTF_KIND_%s '%s')",

+  dw2_asm_output_data (4, btf_id, "%s: (BTF_KIND_%s '%s')",
   prefix, kind_name,
   get_btf_type_name (ref_type));
  }
  }
  
+/* Asm'out a reference to a BTF_KIND_VAR or BTF_KIND_FUNC type.  These type

+   kinds are BTF-specific, and should only be referred to by entries in
+   BTF_KIND_DATASEC records.  */
+
+static void
+btf_asm_datasec_type_ref (const char *prefix, ctf_container_ref ctfc,
+ ctf_id_t btf_id)
+{
+  if (btf_id >= 

[PATCH] rs6000: Add OPTION_MASK_POWER8 [PR101865]

[Peter Bergner]

FYI: This patch is an update to Will Schmidt's patches to fix PR101865:

  https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601825.html
  https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601823.html

...taking into consideration patch reviews received than.  I also found
a few more locations that needed patching, as well as simplifying the
testsuite test cases by removing the need to scan for the predefined macros.



The bug in PR101865 is the _ARCH_PWR8 predefined macro is conditional upon
TARGET_DIRECT_MOVE, which can be false for some -mcpu=power8 compiles if the
-mno-altivec or -mno-vsx options are used.  The solution here is to create
a new OPTION_MASK_POWER8 mask that is true for -mcpu=power8, regardless of
Altivec or VSX enablement.

Unfortunately, the only way to create an OPTION_MASK_* mask is to create
a new option, which we have done here, but marked it as WarnRemoved since
we do not want users using it.  For stage1, we will look into how we can
create ISA mask flags for use in the compiler without the need for explicit
options.

The passed bootstrap and regtest on powerpc64le-linux.  Ok for trunk?

This is also broken on the release branches, so ok for backports after
some burn-in time on trunk?

Peter


2024-04-11  Will Schmidt  
Peter Bergner  

gcc/
PR target/101865
* config/rs6000/rs6000-builtin.cc (rs6000_builtin_is_supported): Use
TARGET_POWER8.
* config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Use
OPTION_MASK_POWER8.
* config/rs6000/rs6000-cpus.def (POWERPC_MASKS): Add OPTION_MASK_POWER8.
(ISA_2_7_MASKS_SERVER): Likewise.
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Update
comment.  Use OPTION_MASK_POWER8 and TARGET_POWER8.
* config/rs6000/rs6000.h (TARGET_SYNC_HI_QI): Use TARGET_POWER8.
* config/rs6000/rs6000.md (define_attr "isa"): Add p8.
(define_attr "enabled"): Handle it.
(define_insn "prefetch"): Use TARGET_POWER8.
* config/rs6000/rs6000.opt (mdo-not-use-this-option): New.

gcc/testsuite/
PR target/101865
* gcc.target/powerpc/predefined-p7-novsx.c: New test.
* gcc.target/powerpc/predefined-p8-noaltivec-novsx.c: New test.
* gcc.target/powerpc/predefined-p8-noaltivec.c: New test.
* gcc.target/powerpc/predefined-p8-novsx.c: New test.
* gcc.target/powerpc/predefined-p8-pragma-vsx.c: New test.
* gcc.target/powerpc/predefined-p9-novsx.c: New test.

diff --git a/gcc/config/rs6000/rs6000-builtin.cc 
b/gcc/config/rs6000/rs6000-builtin.cc
index e7d6204074c..320affd79e3 100644
--- a/gcc/config/rs6000/rs6000-builtin.cc
+++ b/gcc/config/rs6000/rs6000-builtin.cc
@@ -165,7 +165,7 @@ rs6000_builtin_is_supported (enum rs6000_gen_builtins 
fncode)
 case ENB_P7_64:
   return TARGET_POPCNTD && TARGET_POWERPC64;
 case ENB_P8:
-  return TARGET_DIRECT_MOVE;
+  return TARGET_POWER8;
 case ENB_P8V:
   return TARGET_P8_VECTOR;
 case ENB_P9:
diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc
index 647f20de7f2..bd493ab87c5 100644
--- a/gcc/config/rs6000/rs6000-c.cc
+++ b/gcc/config/rs6000/rs6000-c.cc
@@ -429,7 +429,7 @@ rs6000_target_modify_macros (bool define_p, HOST_WIDE_INT 
flags)
 rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR6");
   if ((flags & OPTION_MASK_POPCNTD) != 0)
 rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR7");
-  if ((flags & OPTION_MASK_P8_VECTOR) != 0)
+  if ((flags & OPTION_MASK_POWER8) != 0)
 rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR8");
   if ((flags & OPTION_MASK_MODULO) != 0)
 rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR9");
diff --git a/gcc/config/rs6000/rs6000-cpus.def 
b/gcc/config/rs6000/rs6000-cpus.def
index 45dd5a85901..6ee678e69c3 100644
--- a/gcc/config/rs6000/rs6000-cpus.def
+++ b/gcc/config/rs6000/rs6000-cpus.def
@@ -47,6 +47,7 @@
fusion here, instead set it in rs6000.cc if we are tuning for a power8
system.  */
 #define ISA_2_7_MASKS_SERVER   (ISA_2_6_MASKS_SERVER   \
+| OPTION_MASK_POWER8   \
 | OPTION_MASK_P8_VECTOR\
 | OPTION_MASK_CRYPTO   \
 | OPTION_MASK_EFFICIENT_UNALIGNED_VSX  \
@@ -130,6 +131,7 @@
 | OPTION_MASK_MODULO   \
 | OPTION_MASK_MULHW\
 | OPTION_MASK_NO_UPDATE\
+| OPTION_MASK_POWER8   \
 | OPTION_MASK_P8_FUSION\
 | OPTION_MASK_P8_VECTOR\
 | OPTION_MASK_P9_MINMAX\
diff --git a/gcc/config/rs6000/rs6000.cc 

Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

[Edwin Lu]

On 4/11/2024 5:45 AM, Li, Pan2 wrote:

Thanks for reporting this. Just take a look from my test log that 930623-1.c is 
all pass.

Thus I bet this difference comes from the build option --with-arch=rv32imac but 
my test script take rv64gcv.


I've built the git revision f3fdcf4a37a with
../gcc-trunk/configure --target=riscv-unknown-elf 
--prefix=/home/ed/gnu/riscv-unknown-elf --enable-languages=c,c++ 
--disable-multilib --with-arch=rv32imac --with-abi=ilp32



I am a bit surprised since the target is not supposed to support floating point
or vector instructions AFAIK.


Because you specify rv32imac, with doesn't include f/d/v extension, aka 
single/double floating point and vector extension. Thus, related functionality 
are disabled.


The issue does not happen with gcc-trunk from yesterday.


Ack, will look into it.

Pan
 

Hi Pan,

Our postcommit-ci found that it breaks for non-vector targets on rv32/64 
newlib/linux https://github.com/patrick-rivos/gcc-postcommit-ci/issues/757.


The patchwork precommit-ci also appeared to have flagged it 
https://github.com/ewlu/gcc-precommit-ci/issues/1417#issuecomment-2048846532


Edwin

Re: [PATCH v2] btf: emit non-representable bitfield as void

[Indu Bhagat]

On 4/11/24 14:01, David Faust wrote:

[Changes from v1: use btf_dmd_representable_bitfield_p in
  btf_asm_sou_member, instead of a slightly incorrect equivalent check.]

This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be represented
in BTF.  It is undefined what should happen in such cases, but we can
at least do something reasonable.

Commit

   936dd627cd9 "btf: do not skip members of data type with type id
   BTF_VOID_TYPEID"

made a similar change for un-representable non-bitfield members, but
had an unintended side-effect of mangling BTF for un-representable
bitfields: the struct (or union) would account for the offending
bitfield in its member count but the bitfield member itself was
not emitted, making the member count incorrect.

This change ensures that non-representable bitfield members of struct
and union types are always emitted with BTF_VOID_TYPEID.  This avoids
corrupting the BTF information for the entire struct or union type.

Tested on x86_64-linux-gnu and x86_64-linux-gnu host for
bpf-unknown-none target.

gcc/
* btfout.cc (btf_asm_sou_member): Always emit non-representable
bitfield members as having 'void' type.  Refactor slightly.

gcc/testsuite/
* gcc.dg/debug/btf/btf-bitfields-4.c: Add two new checks.


LGTM.

Thanks


---
  gcc/btfout.cc | 54 +--
  .../gcc.dg/debug/btf/btf-bitfields-4.c|  2 +
  2 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index ab491f0297f..a1510574a93 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -922,41 +922,39 @@ static void
  btf_asm_sou_member (ctf_container_ref ctfc, ctf_dmdef_t * dmd, unsigned int 
idx)
  {
ctf_dtdef_ref ref_type = ctfc->ctfc_types_list[dmd->dmd_type];
+  ctf_id_t base_type = get_btf_id (dmd->dmd_type);
+  uint64_t sou_offset = dmd->dmd_offset;
+
+  dw2_asm_output_data (4, dmd->dmd_name_offset,
+  "MEMBER '%s' idx=%u",
+  dmd->dmd_name, idx);
  
/* Re-encode bitfields to BTF representation.  */

if (CTF_V2_INFO_KIND (ref_type->dtd_data.ctti_info) == CTF_K_SLICE)
  {
-  ctf_id_t base_type = ref_type->dtd_u.dtu_slice.cts_type;
-  unsigned short word_offset = ref_type->dtd_u.dtu_slice.cts_offset;
-  unsigned short bits = ref_type->dtd_u.dtu_slice.cts_bits;
-  uint64_t sou_offset = dmd->dmd_offset;
-
-  /* Pack the bit offset and bitfield size together.  */
-  sou_offset += word_offset;
-
-  /* If this bitfield cannot be represented, do not output anything.
-The parent struct/union 'vlen' field has already been updated.  */
-  if ((bits > 0xff) || (sou_offset > 0xff))
-   return;
+  if (btf_dmd_representable_bitfield_p (ctfc, dmd))
+   {
+ unsigned short word_offset = ref_type->dtd_u.dtu_slice.cts_offset;
+ unsigned short bits = ref_type->dtd_u.dtu_slice.cts_bits;
  
-  sou_offset &= 0x00ff;

-  sou_offset |= ((bits & 0xff) << 24);
+ /* Pack the bit offset and bitfield size together.  */
+ sou_offset += word_offset;
+ sou_offset &= 0x00ff;
+ sou_offset |= ((bits & 0xff) << 24);
  
-  dw2_asm_output_data (4, dmd->dmd_name_offset,

-  "MEMBER '%s' idx=%u",
-  dmd->dmd_name, idx);
-  /* Refer to the base type of the slice.  */
-  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (base_type));
-  dw2_asm_output_data (4, sou_offset, "btm_offset");
-}
-  else
-{
-  dw2_asm_output_data (4, dmd->dmd_name_offset,
-  "MEMBER '%s' idx=%u",
-  dmd->dmd_name, idx);
-  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (dmd->dmd_type));
-  dw2_asm_output_data (4, dmd->dmd_offset, "btm_offset");
+ /* Refer to the base type of the slice.  */
+ base_type = get_btf_id (ref_type->dtd_u.dtu_slice.cts_type);
+   }
+  else
+   {
+ /* Bitfield cannot be represented in BTF.  Emit the member as having
+'void' type.  */
+ base_type = BTF_VOID_TYPEID;
+   }
  }
+
+  btf_asm_type_ref ("btm_type", ctfc, base_type);
+  dw2_asm_output_data (4, sou_offset, "btm_offset");
  }
  
  /* Asm'out an enum constant following a BTF_KIND_ENUM{,64}.  */

diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
index d4a6ef6a1eb..20cdfaa057a 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
@@ -14,6 +14,8 @@
  
  /* Struct with 4 members and no bitfield (kind_flag not set).  */

  /* { dg-final { scan-assembler-times "\[\t \]0x404\[\t 
\]+\[^\n\]*btt_info" 1 } } */
+/* { dg-final { scan-assembler-times " MEMBER" 4 } } */
+/* { dg-final { scan-assembler-times " MEMBER 'unsup' 

[PATCH] btf: fix a possibly misleading asm debug comment

[David Faust]

This patch fixes a small error that could occur in the debug comment
when emitting a type reference with btf_asm_type_ref.

While working on a previous patch, I noticed the following in the asm
output for the test btf-bitfields-4.c:

...
.long   0x39# MEMBER 'c' idx=3
.long   0x6 # btm_type: (BTF_KIND_UNKN '')
...
.long   0x34# TYPE 6 BTF_KIND_INT 'char'

The type for member 'c' is correct, but the comment for the member
incorrectly reads "BTF_KIND_UNKN ''".  This was caused by an
incorrect type lookup in btf_asm_type_ref that could happen if the
source file has types which can be represented in CTF but not in BTF.

This patch fixes the issue by changing btf_asm_type_ref to work fully
in the CTF ID space until writing out the final BTF ID.  That ensures
types are correctly identified when writing the asm debug comments,
like the following fixed comment for the above case.

...
.long   0x39# MEMBER 'c' idx=3
.long   0x6 # btm_type: (BTF_KIND_INT 'char')
...

Note that there was no problem with the actual BTF information, the
only error was in the comment.  This patch does not change the output
BTF information, and no tests were affected.

Tested on x86_64-linux-gnu and x86_64-linux-gnu host for
bpf-unknown-none target. Sanity checked by compiling kernel BPF
selftests.

gcc/
* btfout.cc (btf_asm_type_ref): Convert IDs to BTF internally and
fix potentially looking up wrong type for asm debug comment info.
Split into...
(btf_asm_datasec_type_ref): ... This. New.
(btf_asm_datasec_entry): Call it here, instead of btf_asm_type_ref.
(btf_asm_type, btf_asm_array, btf_asm_varent, btf_asm_sou_member)
(btf_asm_func_arg, btf_asm_func_type): Adapt btf_asm_type_ref call.
---
 gcc/btfout.cc | 84 ++-
 1 file changed, 50 insertions(+), 34 deletions(-)

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index e1ada41b1f4..24bef3acfd1 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -738,36 +738,22 @@ btf_dmd_representable_bitfield_p (ctf_container_ref ctfc, 
ctf_dmdef_t *dmd)
 /* Asm'out a reference to another BTF type.  */
 
 static void
-btf_asm_type_ref (const char *prefix, ctf_container_ref ctfc, ctf_id_t ref_id)
+btf_asm_type_ref (const char *prefix, ctf_container_ref ctfc, ctf_id_t ctf_id)
 {
-  if (ref_id == BTF_VOID_TYPEID || ref_id == BTF_INVALID_TYPEID)
+  ctf_id_t btf_id = get_btf_id (ctf_id);
+  if (btf_id == BTF_VOID_TYPEID || btf_id == BTF_INVALID_TYPEID)
 {
   /* There is no explicit void type.
 Also handle any invalid refs that made it this far, just in case.  */
-  dw2_asm_output_data (4, ref_id, "%s: void", prefix);
-}
-  else if (ref_id >= num_types_added + 1
-  && ref_id < num_types_added + num_vars_added + 1)
-{
-  /* Ref to a variable.  Should only appear in DATASEC entries.  */
-  ctf_id_t var_id = btf_relative_var_id (ref_id);
-  ctf_dvdef_ref dvd = ctfc->ctfc_vars_list[var_id];
-  dw2_asm_output_data (4, ref_id, "%s: (BTF_KIND_VAR '%s')",
-  prefix, dvd->dvd_name);
-
-}
-  else if (ref_id >= num_types_added + num_vars_added + 1)
-{
-  /* Ref to a FUNC record.  */
-  size_t func_id = btf_relative_func_id (ref_id);
-  ctf_dtdef_ref ref_type = (*funcs)[func_id];
-  dw2_asm_output_data (4, ref_id, "%s: (BTF_KIND_FUNC '%s')",
-  prefix, get_btf_type_name (ref_type));
+  dw2_asm_output_data (4, btf_id, "%s: void", prefix);
 }
   else
 {
-  /* Ref to a standard type in the types list.  */
-  ctf_dtdef_ref ref_type = ctfc->ctfc_types_list[ref_id];
+  gcc_assert (btf_id <= num_types_added);
+
+  /* Ref to a standard type in the types list.  Note: take care that we
+must index the type list by the original CTF id, not the BTF id.  */
+  ctf_dtdef_ref ref_type = ctfc->ctfc_types_list[ctf_id];
   uint32_t ref_kind
= get_btf_kind (CTF_V2_INFO_KIND (ref_type->dtd_data.ctti_info));
 
@@ -775,12 +761,43 @@ btf_asm_type_ref (const char *prefix, ctf_container_ref 
ctfc, ctf_id_t ref_id)
? btf_kind_name (BTF_KIND_ENUM)
: btf_kind_name (ref_kind);
 
-  dw2_asm_output_data (4, ref_id, "%s: (BTF_KIND_%s '%s')",
+  dw2_asm_output_data (4, btf_id, "%s: (BTF_KIND_%s '%s')",
   prefix, kind_name,
   get_btf_type_name (ref_type));
 }
 }
 
+/* Asm'out a reference to a BTF_KIND_VAR or BTF_KIND_FUNC type.  These type
+   kinds are BTF-specific, and should only be referred to by entries in
+   BTF_KIND_DATASEC records.  */
+
+static void
+btf_asm_datasec_type_ref (const char *prefix, ctf_container_ref ctfc,
+ ctf_id_t btf_id)
+{
+  if (btf_id >= num_types_added + 1
+  && btf_id < num_types_added + num_vars_added + 1)
+{
+  /* Ref to a variable.  Should only 

[PATCH v2] btf: emit non-representable bitfield as void

[David Faust]

[Changes from v1: use btf_dmd_representable_bitfield_p in
 btf_asm_sou_member, instead of a slightly incorrect equivalent check.]

This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be represented
in BTF.  It is undefined what should happen in such cases, but we can
at least do something reasonable.

Commit

  936dd627cd9 "btf: do not skip members of data type with type id
  BTF_VOID_TYPEID"

made a similar change for un-representable non-bitfield members, but
had an unintended side-effect of mangling BTF for un-representable
bitfields: the struct (or union) would account for the offending
bitfield in its member count but the bitfield member itself was
not emitted, making the member count incorrect.

This change ensures that non-representable bitfield members of struct
and union types are always emitted with BTF_VOID_TYPEID.  This avoids
corrupting the BTF information for the entire struct or union type.

Tested on x86_64-linux-gnu and x86_64-linux-gnu host for
bpf-unknown-none target.

gcc/
* btfout.cc (btf_asm_sou_member): Always emit non-representable
bitfield members as having 'void' type.  Refactor slightly.

gcc/testsuite/
* gcc.dg/debug/btf/btf-bitfields-4.c: Add two new checks.
---
 gcc/btfout.cc | 54 +--
 .../gcc.dg/debug/btf/btf-bitfields-4.c|  2 +
 2 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index ab491f0297f..a1510574a93 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -922,41 +922,39 @@ static void
 btf_asm_sou_member (ctf_container_ref ctfc, ctf_dmdef_t * dmd, unsigned int 
idx)
 {
   ctf_dtdef_ref ref_type = ctfc->ctfc_types_list[dmd->dmd_type];
+  ctf_id_t base_type = get_btf_id (dmd->dmd_type);
+  uint64_t sou_offset = dmd->dmd_offset;
+
+  dw2_asm_output_data (4, dmd->dmd_name_offset,
+  "MEMBER '%s' idx=%u",
+  dmd->dmd_name, idx);
 
   /* Re-encode bitfields to BTF representation.  */
   if (CTF_V2_INFO_KIND (ref_type->dtd_data.ctti_info) == CTF_K_SLICE)
 {
-  ctf_id_t base_type = ref_type->dtd_u.dtu_slice.cts_type;
-  unsigned short word_offset = ref_type->dtd_u.dtu_slice.cts_offset;
-  unsigned short bits = ref_type->dtd_u.dtu_slice.cts_bits;
-  uint64_t sou_offset = dmd->dmd_offset;
-
-  /* Pack the bit offset and bitfield size together.  */
-  sou_offset += word_offset;
-
-  /* If this bitfield cannot be represented, do not output anything.
-The parent struct/union 'vlen' field has already been updated.  */
-  if ((bits > 0xff) || (sou_offset > 0xff))
-   return;
+  if (btf_dmd_representable_bitfield_p (ctfc, dmd))
+   {
+ unsigned short word_offset = ref_type->dtd_u.dtu_slice.cts_offset;
+ unsigned short bits = ref_type->dtd_u.dtu_slice.cts_bits;
 
-  sou_offset &= 0x00ff;
-  sou_offset |= ((bits & 0xff) << 24);
+ /* Pack the bit offset and bitfield size together.  */
+ sou_offset += word_offset;
+ sou_offset &= 0x00ff;
+ sou_offset |= ((bits & 0xff) << 24);
 
-  dw2_asm_output_data (4, dmd->dmd_name_offset,
-  "MEMBER '%s' idx=%u",
-  dmd->dmd_name, idx);
-  /* Refer to the base type of the slice.  */
-  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (base_type));
-  dw2_asm_output_data (4, sou_offset, "btm_offset");
-}
-  else
-{
-  dw2_asm_output_data (4, dmd->dmd_name_offset,
-  "MEMBER '%s' idx=%u",
-  dmd->dmd_name, idx);
-  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (dmd->dmd_type));
-  dw2_asm_output_data (4, dmd->dmd_offset, "btm_offset");
+ /* Refer to the base type of the slice.  */
+ base_type = get_btf_id (ref_type->dtd_u.dtu_slice.cts_type);
+   }
+  else
+   {
+ /* Bitfield cannot be represented in BTF.  Emit the member as having
+'void' type.  */
+ base_type = BTF_VOID_TYPEID;
+   }
 }
+
+  btf_asm_type_ref ("btm_type", ctfc, base_type);
+  dw2_asm_output_data (4, sou_offset, "btm_offset");
 }
 
 /* Asm'out an enum constant following a BTF_KIND_ENUM{,64}.  */
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
index d4a6ef6a1eb..20cdfaa057a 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
@@ -14,6 +14,8 @@
 
 /* Struct with 4 members and no bitfield (kind_flag not set).  */
 /* { dg-final { scan-assembler-times "\[\t \]0x404\[\t 
\]+\[^\n\]*btt_info" 1 } } */
+/* { dg-final { scan-assembler-times " MEMBER" 4 } } */
+/* { dg-final { scan-assembler-times " MEMBER 'unsup' 
idx=2\[\\r\\n\]+\[^\\r\\n\]*0\[\t \]+\[^\n\]*btm_type: void" 1 } } */
 
 struct bigly
 {
-- 
2.43.0

Re: [PATCH] btf: emit non-representable bitfield as void

[David Faust]

On 4/11/24 13:40, Indu Bhagat wrote:
> On 4/11/24 11:53, David Faust wrote:
>> This patch fixes an issue with mangled BTF that could occur when
>> a struct type contains a bitfield member which cannot be represented
>> in BTF.  It is undefined what should happen in such cases, but we can
>> at least do something reasonable.
>>
>> Commit
>>
>>936dd627cd9 "btf: do not skip members of data type with type id
>>BTF_VOID_TYPEID"
>>
>> made a similar change for un-representable non-bitfield members, but
>> had an unintended side-effect of mangling BTF for un-representable
>> bitfields: the struct (or union) would account for the offending
>> bitfield in its member count but the bitfield member itself was
>> not emitted, making the member count incorrect.
>>
>> This change ensures that non-representable bitfield members of struct
>> and union types are always emitted with BTF_VOID_TYPEID.  This avoids
>> corrupting the BTF information for the entire struct or union type.
>>
>> Tested on x86_64-linux-gnu and x86_64-linux-gnu host for
>> bpf-unknown-none target.
>>
> 
> Hi David,
> 
> Thanks for fixing this.  One comment below.
> 
>> gcc/
>>  * btfout.cc (btf_asm_sou_member): Always emit non-representable
>>  bitfield members as having 'void' type.  Refactor slightly.
>>
>> gcc/testsuite/
>>  * gcc.dg/debug/btf/btf-bitfields-4.c: Add two new checks.
>> ---
>>   gcc/btfout.cc | 48 +--
>>   .../gcc.dg/debug/btf/btf-bitfields-4.c|  2 +
>>   2 files changed, 25 insertions(+), 25 deletions(-)
>>
>> diff --git a/gcc/btfout.cc b/gcc/btfout.cc
>> index ab491f0297f..e1ada41b1f4 100644
>> --- a/gcc/btfout.cc
>> +++ b/gcc/btfout.cc
>> @@ -922,41 +922,39 @@ static void
>>   btf_asm_sou_member (ctf_container_ref ctfc, ctf_dmdef_t * dmd, unsigned 
>> int idx)
>>   {
>> ctf_dtdef_ref ref_type = ctfc->ctfc_types_list[dmd->dmd_type];
>> +  ctf_id_t base_type = get_btf_id (dmd->dmd_type);
>> +  uint64_t sou_offset = dmd->dmd_offset;
>> +
>> +  dw2_asm_output_data (4, dmd->dmd_name_offset,
>> +   "MEMBER '%s' idx=%u",
>> +   dmd->dmd_name, idx);
>>   
>> /* Re-encode bitfields to BTF representation.  */
>> if (CTF_V2_INFO_KIND (ref_type->dtd_data.ctti_info) == CTF_K_SLICE)
>>   {
>> -  ctf_id_t base_type = ref_type->dtd_u.dtu_slice.cts_type;
>> unsigned short word_offset = ref_type->dtd_u.dtu_slice.cts_offset;
>> unsigned short bits = ref_type->dtd_u.dtu_slice.cts_bits;
>> -  uint64_t sou_offset = dmd->dmd_offset;
>> -
>> -  /* Pack the bit offset and bitfield size together.  */
>> -  sou_offset += word_offset;
>>   
>> -  /* If this bitfield cannot be represented, do not output anything.
>> - The parent struct/union 'vlen' field has already been updated.  */
>> if ((bits > 0xff) || (sou_offset > 0xff))
> 
> Why dont we reuse the btf_dmd_representable_bitfield_p () function here?
> 
> This one here checks for sou_off > 0xff, while that in 
> btf_dmd_representable_bitfield_p checks for sou_offset + word_offset > 
> 0xff.  The latter is more precise.

Oops. Good catch. We should be doing the same check here, but I moved
the sou_offset += word_offset into the else below, so the word_offset
isn't included.

I avoided using btf_dmd_representable_bitfield_p only because it does
some redundant work. Clearly that was a bad idea :D

Will use btf_dmd_representable_bitfield_p in v2 so we can keep these
checks contained.

> 
> 
>> -return;
>> -
>> -  sou_offset &= 0x00ff;
>> -  sou_offset |= ((bits & 0xff) << 24);
>> +{
>> +  /* Bitfield cannot be represented in BTF.  Emit the member as having
>> + 'void' type.  */
>> +  base_type = BTF_VOID_TYPEID;
>> +}
>> +  else
>> +{
>> +  /* Pack the bit offset and bitfield size together.  */
>> +  sou_offset += word_offset;
>> +  sou_offset &= 0x00ff;
>> +  sou_offset |= ((bits & 0xff) << 24);
>>   
>> -  dw2_asm_output_data (4, dmd->dmd_name_offset,
>> -   "MEMBER '%s' idx=%u",
>> -   dmd->dmd_name, idx);
>> -  /* Refer to the base type of the slice.  */
>> -  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (base_type));
>> -  dw2_asm_output_data (4, sou_offset, "btm_offset");
>> -}
>> -  else
>> -{
>> -  dw2_asm_output_data (4, dmd->dmd_name_offset,
>> -   "MEMBER '%s' idx=%u",
>> -   dmd->dmd_name, idx);
>> -  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (dmd->dmd_type));
>> -  dw2_asm_output_data (4, dmd->dmd_offset, "btm_offset");
>> +  /* Refer to the base type of the slice.  */
>> +  base_type = get_btf_id (ref_type->dtd_u.dtu_slice.cts_type);
>> +}
>>   }
>> +
>> +  btf_asm_type_ref ("btm_type", ctfc, base_type);
>> +  dw2_asm_output_data (4, sou_offset, "btm_offset");
>>   }
>>   
>>   /* Asm'out an enum constant 

[r14-9912 Regression] FAIL: gcc.dg/guality/pr54693-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i on Linux/x86_64

[haochen.jiang]

On Linux/x86_64,

c7e8a8d814229fd6fc4c16c2452f15dddc613479 is the first bad commit
commit c7e8a8d814229fd6fc4c16c2452f15dddc613479
Author: Richard Biener 
Date:   Thu Apr 11 11:08:07 2024 +0200

tree-optimization/109596 - wrong debug stmt move by copyheader

caused

FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 34 c == 
[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  -DPREVENT_OPTIMIZATION  line 39 c == 
[0]
FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 x == 10 - i
FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 y == 20 - 2 * i
FAIL: gcc.dg/guality/pr54693-2.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  -DPREVENT_OPTIMIZATION line 21 z == 30 - 3 * i

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-9912/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="guality.exp=gcc.dg/guality/pr43051-1.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="guality.exp=gcc.dg/guality/pr43051-1.c --target_board='unix{-m64\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="guality.exp=gcc.dg/guality/pr54693-2.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="guality.exp=gcc.dg/guality/pr54693-2.c --target_board='unix{-m32\ 
-march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="guality.exp=gcc.dg/guality/pr54693-2.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="guality.exp=gcc.dg/guality/pr54693-2.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.)
(If you met problems with cascadelake related, disabling AVX512F in command 
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)

Re: [PATCH] btf: emit non-representable bitfield as void

[Indu Bhagat]

On 4/11/24 11:53, David Faust wrote:

This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be represented
in BTF.  It is undefined what should happen in such cases, but we can
at least do something reasonable.

Commit

   936dd627cd9 "btf: do not skip members of data type with type id
   BTF_VOID_TYPEID"

made a similar change for un-representable non-bitfield members, but
had an unintended side-effect of mangling BTF for un-representable
bitfields: the struct (or union) would account for the offending
bitfield in its member count but the bitfield member itself was
not emitted, making the member count incorrect.

This change ensures that non-representable bitfield members of struct
and union types are always emitted with BTF_VOID_TYPEID.  This avoids
corrupting the BTF information for the entire struct or union type.

Tested on x86_64-linux-gnu and x86_64-linux-gnu host for
bpf-unknown-none target.



Hi David,

Thanks for fixing this.  One comment below.


gcc/
* btfout.cc (btf_asm_sou_member): Always emit non-representable
bitfield members as having 'void' type.  Refactor slightly.

gcc/testsuite/
* gcc.dg/debug/btf/btf-bitfields-4.c: Add two new checks.
---
  gcc/btfout.cc | 48 +--
  .../gcc.dg/debug/btf/btf-bitfields-4.c|  2 +
  2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index ab491f0297f..e1ada41b1f4 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -922,41 +922,39 @@ static void
  btf_asm_sou_member (ctf_container_ref ctfc, ctf_dmdef_t * dmd, unsigned int 
idx)
  {
ctf_dtdef_ref ref_type = ctfc->ctfc_types_list[dmd->dmd_type];
+  ctf_id_t base_type = get_btf_id (dmd->dmd_type);
+  uint64_t sou_offset = dmd->dmd_offset;
+
+  dw2_asm_output_data (4, dmd->dmd_name_offset,
+  "MEMBER '%s' idx=%u",
+  dmd->dmd_name, idx);
  
/* Re-encode bitfields to BTF representation.  */

if (CTF_V2_INFO_KIND (ref_type->dtd_data.ctti_info) == CTF_K_SLICE)
  {
-  ctf_id_t base_type = ref_type->dtd_u.dtu_slice.cts_type;
unsigned short word_offset = ref_type->dtd_u.dtu_slice.cts_offset;
unsigned short bits = ref_type->dtd_u.dtu_slice.cts_bits;
-  uint64_t sou_offset = dmd->dmd_offset;
-
-  /* Pack the bit offset and bitfield size together.  */
-  sou_offset += word_offset;
  
-  /* If this bitfield cannot be represented, do not output anything.

-The parent struct/union 'vlen' field has already been updated.  */
if ((bits > 0xff) || (sou_offset > 0xff))


Why dont we reuse the btf_dmd_representable_bitfield_p () function here?

This one here checks for sou_off > 0xff, while that in 
btf_dmd_representable_bitfield_p checks for sou_offset + word_offset > 
0xff.  The latter is more precise.




-   return;
-
-  sou_offset &= 0x00ff;
-  sou_offset |= ((bits & 0xff) << 24);
+   {
+ /* Bitfield cannot be represented in BTF.  Emit the member as having
+'void' type.  */
+ base_type = BTF_VOID_TYPEID;
+   }
+  else
+   {
+ /* Pack the bit offset and bitfield size together.  */
+ sou_offset += word_offset;
+ sou_offset &= 0x00ff;
+ sou_offset |= ((bits & 0xff) << 24);
  
-  dw2_asm_output_data (4, dmd->dmd_name_offset,

-  "MEMBER '%s' idx=%u",
-  dmd->dmd_name, idx);
-  /* Refer to the base type of the slice.  */
-  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (base_type));
-  dw2_asm_output_data (4, sou_offset, "btm_offset");
-}
-  else
-{
-  dw2_asm_output_data (4, dmd->dmd_name_offset,
-  "MEMBER '%s' idx=%u",
-  dmd->dmd_name, idx);
-  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (dmd->dmd_type));
-  dw2_asm_output_data (4, dmd->dmd_offset, "btm_offset");
+ /* Refer to the base type of the slice.  */
+ base_type = get_btf_id (ref_type->dtd_u.dtu_slice.cts_type);
+   }
  }
+
+  btf_asm_type_ref ("btm_type", ctfc, base_type);
+  dw2_asm_output_data (4, sou_offset, "btm_offset");
  }
  
  /* Asm'out an enum constant following a BTF_KIND_ENUM{,64}.  */

diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
index d4a6ef6a1eb..20cdfaa057a 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
@@ -14,6 +14,8 @@
  
  /* Struct with 4 members and no bitfield (kind_flag not set).  */

  /* { dg-final { scan-assembler-times "\[\t \]0x404\[\t 
\]+\[^\n\]*btt_info" 1 } } */
+/* { dg-final { scan-assembler-times " MEMBER" 4 } } */
+/* { dg-final { scan-assembler-times " MEMBER 'unsup' 
idx=2\[\\r\\n\]+\[^\\r\\n\]*0\[\t \]+\[^\n\]*btm_type: void" 1 } } 

Re: Combine patch ping

[Uros Bizjak]

On Thu, Apr 11, 2024 at 4:02 PM Segher Boessenkool
 wrote:
>
> On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote:
> > On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
> >  wrote:
> > > This is never okay.  You cannot commit a patch without approval, *ever*.
>
> This is the biggest issue, to start with.  It is fundamental.
>
> > > That patch is also obvious -- obviously *wrong*, that is.  There are
> > > big assumptions everywhere in the compiler how a CC reg can be used.
> > > This violates that, as explained elsewhere.
> >
> > Can you please elaborate what is wrong with this concrete patch.
>
> The explanation of the patch is contradictory to how RTL works at all,
> so it is just wrong.  It might even do something sane, but I didn't get
> that far at all!

The commit message explains the problem, the solution is explained in
the last couple of lines. Please see [1] for a more thorough
explanation of the problem.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560#c13

> Write good email explanations, and a good proposed commit message.
> Please.  It is the only one people can judge a patch.  Well, apart
> from doing everything myself from first principles, ignoring everything
> you said, just looking at the patch itself, but that is a hundred times
> more work.  I don't do that.
>
> > The
> > part that the patch touches has several wrong assumptions, and the
> > fixed "???" comment just emphasizes that. I don't see what is wrong
> > with:
> >
> > (define_insn "@pushfl2"
> >   [(set (match_operand:W 0 "push_operand" "=<")
> > (unspec:W [(match_operand 1 "flags_reg_operand")]
> >   UNSPEC_PUSHFL))]
> >   "GET_MODE_CLASS (GET_MODE (operands[1])) == MODE_CC"
> >   "pushf{}"
> >   [(set_attr "type" "push")
> >(set_attr "mode" "")])
>
> What does it even mean?  What is a flags:CC?  You always always always
> need to say what is *in* the flags, if you want to use it as input
> (which is what unspec does).  CC is weird like this.  Most targets do
> not have distinct physical flags for every condition, only a few
> conditions are "alive" at any point in the program!

>From our previous discussion, we concluded that "use" means
cc-compared-to-0, but we also need a "copy" operation, to be able to
move CC reg around as a physical register (e.g. sahf, lahf, pushfl,
popfl instructions). This is a register that contains the state of the
CPU, described in [1] , not some RTL concept. The register is even
listed in i386.md:

(FLAGS_REG   17)

with the "mode" that defines the value in the register more precisely.

[1] https://en.wikipedia.org/wiki/FLAGS_register

>
> > it is just a push of the flags reg to the stack. If the push can't be
> > described in this way, then it is the middle end at fault, we can't
> > just change modes at will.
>
> But that is not what this describes: it operates on the flags register
> in some unspecified way, and pushes the result of *that* to the stack.

No, the "use" is defined as cc-compared-to-0. The above is a "copy"
operation, the register that holds the state of the CPU is pushed on
the stack (and can be later popped from the stack to reload the saved
state). The pushfl instruction does not use the register in the sense
that it examines its contents.

> (Stack pointer modification is not described here btw, should it be?  Is
> that magically implemented by the backend some way, via type=push
> perhaps?)

Please see gen_pushfl() in i386.cc that emits the pattern:

#(insn:TI 5 2 6 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8])
#(unspec:DI [
#(reg:CC 17 flags)
#] UNSPEC_PUSHFL)) "flags.c":3:10 70 {pushfldi2}
# (expr_list:REG_DEAD (reg:CC 17 flags)
#(nil)))
   pushfq  # 5 [c=4 l=1]  pushfldi2

Uros.

New Swedish PO file for 'gcc' (version 14.1-b20240218)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-14.1-b20240218.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[PATCH] btf: emit non-representable bitfield as void

[David Faust]

This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be represented
in BTF.  It is undefined what should happen in such cases, but we can
at least do something reasonable.

Commit

  936dd627cd9 "btf: do not skip members of data type with type id
  BTF_VOID_TYPEID"

made a similar change for un-representable non-bitfield members, but
had an unintended side-effect of mangling BTF for un-representable
bitfields: the struct (or union) would account for the offending
bitfield in its member count but the bitfield member itself was
not emitted, making the member count incorrect.

This change ensures that non-representable bitfield members of struct
and union types are always emitted with BTF_VOID_TYPEID.  This avoids
corrupting the BTF information for the entire struct or union type.

Tested on x86_64-linux-gnu and x86_64-linux-gnu host for
bpf-unknown-none target.

gcc/
* btfout.cc (btf_asm_sou_member): Always emit non-representable
bitfield members as having 'void' type.  Refactor slightly.

gcc/testsuite/
* gcc.dg/debug/btf/btf-bitfields-4.c: Add two new checks.
---
 gcc/btfout.cc | 48 +--
 .../gcc.dg/debug/btf/btf-bitfields-4.c|  2 +
 2 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/gcc/btfout.cc b/gcc/btfout.cc
index ab491f0297f..e1ada41b1f4 100644
--- a/gcc/btfout.cc
+++ b/gcc/btfout.cc
@@ -922,41 +922,39 @@ static void
 btf_asm_sou_member (ctf_container_ref ctfc, ctf_dmdef_t * dmd, unsigned int 
idx)
 {
   ctf_dtdef_ref ref_type = ctfc->ctfc_types_list[dmd->dmd_type];
+  ctf_id_t base_type = get_btf_id (dmd->dmd_type);
+  uint64_t sou_offset = dmd->dmd_offset;
+
+  dw2_asm_output_data (4, dmd->dmd_name_offset,
+  "MEMBER '%s' idx=%u",
+  dmd->dmd_name, idx);
 
   /* Re-encode bitfields to BTF representation.  */
   if (CTF_V2_INFO_KIND (ref_type->dtd_data.ctti_info) == CTF_K_SLICE)
 {
-  ctf_id_t base_type = ref_type->dtd_u.dtu_slice.cts_type;
   unsigned short word_offset = ref_type->dtd_u.dtu_slice.cts_offset;
   unsigned short bits = ref_type->dtd_u.dtu_slice.cts_bits;
-  uint64_t sou_offset = dmd->dmd_offset;
-
-  /* Pack the bit offset and bitfield size together.  */
-  sou_offset += word_offset;
 
-  /* If this bitfield cannot be represented, do not output anything.
-The parent struct/union 'vlen' field has already been updated.  */
   if ((bits > 0xff) || (sou_offset > 0xff))
-   return;
-
-  sou_offset &= 0x00ff;
-  sou_offset |= ((bits & 0xff) << 24);
+   {
+ /* Bitfield cannot be represented in BTF.  Emit the member as having
+'void' type.  */
+ base_type = BTF_VOID_TYPEID;
+   }
+  else
+   {
+ /* Pack the bit offset and bitfield size together.  */
+ sou_offset += word_offset;
+ sou_offset &= 0x00ff;
+ sou_offset |= ((bits & 0xff) << 24);
 
-  dw2_asm_output_data (4, dmd->dmd_name_offset,
-  "MEMBER '%s' idx=%u",
-  dmd->dmd_name, idx);
-  /* Refer to the base type of the slice.  */
-  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (base_type));
-  dw2_asm_output_data (4, sou_offset, "btm_offset");
-}
-  else
-{
-  dw2_asm_output_data (4, dmd->dmd_name_offset,
-  "MEMBER '%s' idx=%u",
-  dmd->dmd_name, idx);
-  btf_asm_type_ref ("btm_type", ctfc, get_btf_id (dmd->dmd_type));
-  dw2_asm_output_data (4, dmd->dmd_offset, "btm_offset");
+ /* Refer to the base type of the slice.  */
+ base_type = get_btf_id (ref_type->dtd_u.dtu_slice.cts_type);
+   }
 }
+
+  btf_asm_type_ref ("btm_type", ctfc, base_type);
+  dw2_asm_output_data (4, sou_offset, "btm_offset");
 }
 
 /* Asm'out an enum constant following a BTF_KIND_ENUM{,64}.  */
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
index d4a6ef6a1eb..20cdfaa057a 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-bitfields-4.c
@@ -14,6 +14,8 @@
 
 /* Struct with 4 members and no bitfield (kind_flag not set).  */
 /* { dg-final { scan-assembler-times "\[\t \]0x404\[\t 
\]+\[^\n\]*btt_info" 1 } } */
+/* { dg-final { scan-assembler-times " MEMBER" 4 } } */
+/* { dg-final { scan-assembler-times " MEMBER 'unsup' 
idx=2\[\\r\\n\]+\[^\\r\\n\]*0\[\t \]+\[^\n\]*btm_type: void" 1 } } */
 
 struct bigly
 {
-- 
2.43.0

Re: [PATCH] contrib/check-params-in-docs.py: Ignore gcn-preferred-vectorization-factor

[Thomas Schwinge]

Hi!

On 2024-04-11T19:52:51+0200, Martin Jambor  wrote:
> contrib/check-params-in-docs.py is a script that checks that all
> options reported with ./gcc/xgcc -Bgcc --help=param are in
> gcc/doc/invoke.texi and vice versa.

Eh, first time I'm hearing about this one!

(a) Shouldn't this be running as part of the GCC build process?

> gcn-preferred-vectorization-factor is in the manual but normally not
> reported by --help, probably because I do not have gcn offload
> configured.

No, because you've not been building GCC for GCN target.  ;-P

> This patch makes the script silently about this particular
> fact.

(b) Shouldn't we instead ignore any '--param's with "gcn" prefix, similar
to how that's done for "skip aarch64 params"?

(c) ..., and shouldn't we likewise skip any "x86" ones?

(d) ..., or in fact any target specific ones, following after the generic
section?  (Easily achieved with a special marker in
'gcc/doc/invoke.texi', just before:

The following choices of @var{name} are available on AArch64 targets:

..., and adjusting the 'takewhile' in 'contrib/check-params-in-docs.py'
accordingly?


Grüße
 Thomas


> I'll push the patch as obvious momentarily.
>
> Martin
>
>
> contrib/ChangeLog:
>
> 2024-04-11  Martin Jambor  
>
>   * check-params-in-docs.py (ignored): Add
>   gcn-preferred-vectorization-factor.
> ---
>  contrib/check-params-in-docs.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/check-params-in-docs.py b/contrib/check-params-in-docs.py
> index 623c82284e2..f7879dd8e08 100755
> --- a/contrib/check-params-in-docs.py
> +++ b/contrib/check-params-in-docs.py
> @@ -45,7 +45,7 @@ parser.add_argument('params_output')
>  
>  args = parser.parse_args()
>  
> -ignored = {'logical-op-non-short-circuit'}
> +ignored = {'logical-op-non-short-circuit', 
> 'gcn-preferred-vectorization-factor'}
>  params = {}
>  
>  for line in open(args.params_output).readlines():
> -- 
> 2.44.0

Re: [PATCH] libstdc++: Compile std::allocator instantiations as C++20

[Iain Sandoe]

> On 11 Apr 2024, at 18:33, Ville Voutilainen  
> wrote:
> 
> On Thu, 11 Apr 2024 at 20:22, Jonathan Wakely  wrote:
>> 
>> I'm considering this late patch for gcc-14 to workaround an issue
>> discovered by a recent Clang change.
>> 
>> I'm not yet sure if Clang is right to require these symbols. It's not
>> really clear, because always_inline isn't part of the standard so it's
>> not clear how it should interact with explicit instantiations and
>> modules. Exporting these four extra symbols doesn't hurt, even if Clang
>> ends up reverting or revising its change that requires them.
>> 
>> Another way to fix it would be to suppress the explicit instantiation
>> declarations in  for C++20, so that the compiler
>> always instantiates them implicitly as needed. We do similar things for
>> the explicit instantiations of std::string etc. so that new member
>> functions that aren't in the .so are implicitly instantiated as needed.
>> 
>> That would look like this instead:
>> 
>> --- a/libstdc++-v3/include/bits/allocator.h
>> +++ b/libstdc++-v3/include/bits/allocator.h
>> @@ -281,7 +281,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> 
>>   // Inhibit implicit instantiations for required instantiations,
>>   // which are defined via explicit instantiations elsewhere.
>> -#if _GLIBCXX_EXTERN_TEMPLATE
>> +#if _GLIBCXX_EXTERN_TEMPLATE && __cplusplus <= 201703L
>>   extern template class allocator;
>>   extern template class allocator;
>> #endif
>> 
>> But we might want to export the new functions from the library
>> eventually anyway, so doing it now (before Clang 19 is released) might
>> be the best option.

I think clang-19 will branch after gcc-14 (so the urgency is more on the GCC
side - or making a decision to back out of the clang change.

>> 
>> Thoughts?
> 
> I think the symbol export is a fine solution. Both of these solutions
> work, so I don't have a strong preference,
> I have a minor preference for not suppressing explicit instantiations
> that are otherwise already there,
> but that is indeed not a strong preference.

In the case of interaction between modules and items not identified in
the std, the only solution is to get agreement between the ‘vendors’.

If we emit the symbols, then that gets baked into the libstdc++ ABI, right?

Is there an alternate solution that we can propose? (there is a modules
implementer’s group that meets bi-weekly, including next Tuesday - 
this includes representation from GCC, clang, MSVC and usually some
of the larger players like google… it could be a topic of discussion if
there is some tidier proposal we could make.

Iain

[PATCH] contrib/check-params-in-docs.py: Ignore gcn-preferred-vectorization-factor

[Martin Jambor]

Hi,

contrib/check-params-in-docs.py is a script that checks that all
options reported with ./gcc/xgcc -Bgcc --help=param are in
gcc/doc/invoke.texi and vice versa.
gcn-preferred-vectorization-factor is in the manual but normally not
reported by --help, probably because I do not have gcn offload
configured.  This patch makes the script silently about this particular
fact.

I'll push the patch as obvious momentarily.

Martin


contrib/ChangeLog:

2024-04-11  Martin Jambor  

* check-params-in-docs.py (ignored): Add
gcn-preferred-vectorization-factor.
---
 contrib/check-params-in-docs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contrib/check-params-in-docs.py b/contrib/check-params-in-docs.py
index 623c82284e2..f7879dd8e08 100755
--- a/contrib/check-params-in-docs.py
+++ b/contrib/check-params-in-docs.py
@@ -45,7 +45,7 @@ parser.add_argument('params_output')
 
 args = parser.parse_args()
 
-ignored = {'logical-op-non-short-circuit'}
+ignored = {'logical-op-non-short-circuit', 
'gcn-preferred-vectorization-factor'}
 params = {}
 
 for line in open(args.params_output).readlines():
-- 
2.44.0

Re: [PATCH] libstdc++: Compile std::allocator instantiations as C++20

[Ville Voutilainen]

On Thu, 11 Apr 2024 at 20:22, Jonathan Wakely  wrote:
>
> I'm considering this late patch for gcc-14 to workaround an issue
> discovered by a recent Clang change.
>
> I'm not yet sure if Clang is right to require these symbols. It's not
> really clear, because always_inline isn't part of the standard so it's
> not clear how it should interact with explicit instantiations and
> modules. Exporting these four extra symbols doesn't hurt, even if Clang
> ends up reverting or revising its change that requires them.
>
> Another way to fix it would be to suppress the explicit instantiation
> declarations in  for C++20, so that the compiler
> always instantiates them implicitly as needed. We do similar things for
> the explicit instantiations of std::string etc. so that new member
> functions that aren't in the .so are implicitly instantiated as needed.
>
> That would look like this instead:
>
> --- a/libstdc++-v3/include/bits/allocator.h
> +++ b/libstdc++-v3/include/bits/allocator.h
> @@ -281,7 +281,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>// Inhibit implicit instantiations for required instantiations,
>// which are defined via explicit instantiations elsewhere.
> -#if _GLIBCXX_EXTERN_TEMPLATE
> +#if _GLIBCXX_EXTERN_TEMPLATE && __cplusplus <= 201703L
>extern template class allocator;
>extern template class allocator;
>  #endif
>
> But we might want to export the new functions from the library
> eventually anyway, so doing it now (before Clang 19 is released) might
> be the best option.
>
> Thoughts?

I think the symbol export is a fine solution. Both of these solutions
work, so I don't have a strong preference,
I have a minor preference for not suppressing explicit instantiations
that are otherwise already there,
but that is indeed not a strong preference.

Re: [PATCH 2/3] bpf: remove huge memory waste with string allocation.

[Cupertino Miranda]

Hi David,

Thanks for the review.
Will apply the changes.
Nice catch and optimization with the vlen size.

Cupertino

David Faust writes:

> Hi Cupertino,
>
> On 4/11/24 04:11, Cupertino Miranda wrote:
>> Code was allocating way too much space for the string.
>
> A little bit more description would not hurt. Perhaps you could say
> something like:
> "The BPF backend was allocating an unnecessarily large string when
>  constructing CO-RE relocations for enum types."
>
>>
>> gcc/ChangeLog:
>>  * config/bpf/core-builtins.cc (process_enum_value): Corrected
>>  string allocation.
>
> nit: present tense, i.e. "Correct" rather than "Corrected"
>
>> ---
>>  gcc/config/bpf/core-builtins.cc | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/gcc/config/bpf/core-builtins.cc 
>> b/gcc/config/bpf/core-builtins.cc
>> index e03e986e2c1..ead1777d465 100644
>> --- a/gcc/config/bpf/core-builtins.cc
>> +++ b/gcc/config/bpf/core-builtins.cc
>> @@ -872,10 +872,11 @@ process_enum_value (struct cr_builtins *data)
>>  {
>>if (TREE_VALUE (l) == expr)
>>  {
>> -  char *tmp = (char *) ggc_alloc_atomic ((index / 10) + 1);
>> +  /* Array size is 21 = ceil(log_10(2^64)) + 1 to hold string
>> + representations of 64 bit integers.  */
>> +  char tmp[21];
>>sprintf (tmp, "%d", index);
>
> It looks like `index' is an `unsigned int', so this sprintf should use
> %u rather %d, no?
>
> Also, it occurs to me that the `vlen' of BTF types is only 16 bits, so
> BTF has no way currently to represent enums with more than 65535
> enumerators. It may be worth adding a sanity check to bail out (error)
> here if we're going to claim an index higher than that. And if that is
> validated before the printf, the buffer can be 6 bytes ("65535\0").
>
>> -  ret.str = (const char *) tmp;
>> -
>> +  ret.str = CONST_CAST (char *, ggc_strdup(tmp));
>>break;
>>  }
>>index++;

[PATCH] libstdc++: Compile std::allocator instantiations as C++20

[Jonathan Wakely]

I'm considering this late patch for gcc-14 to workaround an issue
discovered by a recent Clang change.

I'm not yet sure if Clang is right to require these symbols. It's not
really clear, because always_inline isn't part of the standard so it's
not clear how it should interact with explicit instantiations and
modules. Exporting these four extra symbols doesn't hurt, even if Clang
ends up reverting or revising its change that requires them.

Another way to fix it would be to suppress the explicit instantiation
declarations in  for C++20, so that the compiler
always instantiates them implicitly as needed. We do similar things for
the explicit instantiations of std::string etc. so that new member
functions that aren't in the .so are implicitly instantiated as needed.

That would look like this instead:

--- a/libstdc++-v3/include/bits/allocator.h
+++ b/libstdc++-v3/include/bits/allocator.h
@@ -281,7 +281,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // Inhibit implicit instantiations for required instantiations,
   // which are defined via explicit instantiations elsewhere.
-#if _GLIBCXX_EXTERN_TEMPLATE
+#if _GLIBCXX_EXTERN_TEMPLATE && __cplusplus <= 201703L
   extern template class allocator;
   extern template class allocator;
 #endif

But we might want to export the new functions from the library
eventually anyway, so doing it now (before Clang 19 is released) might
be the best option.

Thoughts?


-- >8 --

This ensures that the new std::allocator::allocate and
std::allocator::deallocate functions are included in the explicit
instantiation definitions. They're only defined for C++20 and later
(because they are needed to support constexpr dynamic allocation) so
were not being instantiated when those files were compiled as C++98.

This isn't needed for GCC because those functions are marked
'always_inline' and so no extern symbols are needed. But a recent Clang
change has meant that always_inline functions do not get exported from
modules, and so the extern symbols (which were not previously being
instantiated or exported) are needed by Clang. See the Clang issue
https://github.com/llvm/llvm-project/issues/86893 for details.

The allocator-inst.cc file is changed to include 
instead of all of , because otherwise it indirectly includes
 and the implicit instantiations of std::string and
std::wstring also instantiate std::allocator and
std::allocator, which for some reason suppresses the explicit
instantiation definitions of the default constructors in this file.
Just including  avoids that problem.

libstdc++-v3/ChangeLog:

* config/abi/pre/gnu.ver: Export new symbols.
* src/c++20/Makefile.am: Add allocator-inst.o.
* src/c++20/Makefile.in: Regenerate.
* src/c++98/allocator-inst.cc: Move to...
* src/c++20/allocator-inst.cc: ...here.
* src/c++98/Makefile.am: Remove allocator-inst.o.
* src/c++98/Makefile.in: Regenerate.
---
 libstdc++-v3/config/abi/pre/gnu.ver | 4 
 libstdc++-v3/src/c++20/Makefile.am  | 1 +
 libstdc++-v3/src/c++20/Makefile.in  | 4 +++-
 libstdc++-v3/src/{c++98 => c++20}/allocator-inst.cc | 2 +-
 libstdc++-v3/src/c++98/Makefile.am  | 1 -
 libstdc++-v3/src/c++98/Makefile.in  | 6 ++
 6 files changed, 11 insertions(+), 7 deletions(-)
 rename libstdc++-v3/src/{c++98 => c++20}/allocator-inst.cc (97%)

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index 31449b5b87b..ab001048a67 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2526,6 +2526,10 @@ GLIBCXX_3.4.32 {
 GLIBCXX_3.4.33 {
 # std::basic_file::native_handle()
 _ZNKSt12__basic_fileIcE13native_handleEv;
+
+# std::allocator<[cw]>::allocate and ::deallocate for C++20
+_ZNSaI[cw]E8allocateE[jmy];
+_ZNSaI[cw]E10deallocateEP[cw][jmy];
 } GLIBCXX_3.4.32;
 
 # Symbols in the support library (libsupc++) have their own tag.
diff --git a/libstdc++-v3/src/c++20/Makefile.am 
b/libstdc++-v3/src/c++20/Makefile.am
index a24505e5141..f4a06e6de78 100644
--- a/libstdc++-v3/src/c++20/Makefile.am
+++ b/libstdc++-v3/src/c++20/Makefile.am
@@ -30,6 +30,7 @@ headers =
 if ENABLE_EXTERN_TEMPLATE
 # XTEMPLATE_FLAGS = -fno-implicit-templates
 inst_sources = \
+   allocator-inst.cc \
sstream-inst.cc
 else
 # XTEMPLATE_FLAGS =
diff --git a/libstdc++-v3/src/c++20/Makefile.in 
b/libstdc++-v3/src/c++20/Makefile.in
index 3ec8c5ce804..ec4c5eec026 100644
--- a/libstdc++-v3/src/c++20/Makefile.in
+++ b/libstdc++-v3/src/c++20/Makefile.in
@@ -122,7 +122,8 @@ CONFIG_CLEAN_VPATH_FILES =
 LTLIBRARIES = $(noinst_LTLIBRARIES)
 libc__20convenience_la_LIBADD =
 am__objects_1 = tzdb.lo
-@ENABLE_EXTERN_TEMPLATE_TRUE@am__objects_2 = sstream-inst.lo
+@ENABLE_EXTERN_TEMPLATE_TRUE@am__objects_2 = allocator-inst.lo \
+@ENABLE_EXTERN_TEMPLATE_TRUE@  sstream-inst.lo
 @GLIBCXX_HOSTED_TRUE@am_libc__20convenience_la_OBJECTS =  \
 

Re: [PATCH] aarch64: Fix _BitInt testcases

[Richard Sandiford]

"Andre Vieira (lists)"  writes:
> This patch fixes some testisms introduced by:
>
> commit 5aa3fec38cc6f52285168b161bab1a869d864b44
> Author: Andre Vieira 
> Date:   Wed Apr 10 16:29:46 2024 +0100
>
>  aarch64: Add support for _BitInt
>
> The testcases were relying on an unnecessary sign-extend that is no longer
> generated.
>
> The tested version was just slightly behind top of trunk when the patch 
> was committed, and the codegen had changed, for the better, by then.
>
> OK for trunk? (I am away tomorrow, so if you want this in before the 
> weekend feel free to commit it on my behalf, if approved ofc...)
>
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/bitfield-bitint-abi-align16.c (g1, g8, g16, g1p, 
> g8p,
>   g16p): Remove unnecessary sbfx.
>   * gcc.target/aarch64/bitfield-bitint-abi-align8.c (g1, g8, g16, g1p, 
> g8p,
>   g16p): Likewise.

LGTM, thanks.  Pushed to trunk.

Richard

>
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c 
> b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
> index 
> 3f292a45f955d35b802a0bd789cd39d5fa7b5860..4a228b0a1ce696dc80e32305162d58f01d44051d
>  100644
> --- a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
> +++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
> @@ -55,9 +55,8 @@
>  ** g1:
>  **   mov (x[0-9]+), x0
>  **   mov w0, w1
> -**   sbfx(x[0-9]+), \1, 0, 63
> -**   and x4, \2, 9223372036854775807
> -**   and x2, \2, 1
> +**   and x4, \1, 9223372036854775807
> +**   and x2, \1, 1
>  **   mov x3, 0
>  **   b   f1
>  */
> @@ -66,9 +65,8 @@
>  ** g8:
>  **   mov (x[0-9]+), x0
>  **   mov w0, w1
> -**   sbfx(x[0-9]+), \1, 0, 63
> -**   and x4, \2, 9223372036854775807
> -**   and x2, \2, 1
> +**   and x4, \1, 9223372036854775807
> +**   and x2, \1, 1
>  **   mov x3, 0
>  **   b   f8
>  */
> @@ -76,9 +74,8 @@
>  ** g16:
>  **   mov (x[0-9]+), x0
>  **   mov w0, w1
> -**   sbfx(x[0-9]+), \1, 0, 63
> -**   and x4, \2, 9223372036854775807
> -**   and x2, \2, 1
> +**   and x4, \1, 9223372036854775807
> +**   and x2, \1, 1
>  **   mov x3, 0
>  **   b   f16
>  */
> @@ -107,9 +104,8 @@
>  /*
>  ** g1p:
>  **   mov (w[0-9]+), w1
> -**   sbfx(x[0-9]+), x0, 0, 63
> -**   and x3, \2, 9223372036854775807
> -**   and x1, \2, 1
> +**   and x3, x0, 9223372036854775807
> +**   and x1, x0, 1
>  **   mov x2, 0
>  **   mov w0, \1
>  **   b   f1p
> @@ -117,9 +113,8 @@
>  /*
>  ** g8p:
>  **   mov (w[0-9]+), w1
> -**   sbfx(x[0-9]+), x0, 0, 63
> -**   and x3, \2, 9223372036854775807
> -**   and x1, \2, 1
> +**   and x3, x0, 9223372036854775807
> +**   and x1, x0, 1
>  **   mov x2, 0
>  **   mov w0, \1
>  **   b   f8p
> @@ -128,9 +123,8 @@
>  ** g16p:
>  **   mov (x[0-9]+), x0
>  **   mov w0, w1
> -**   sbfx(x[0-9]+), \1, 0, 63
> -**   and x4, \2, 9223372036854775807
> -**   and x2, \2, 1
> +**   and x4, \1, 9223372036854775807
> +**   and x2, \1, 1
>  **   mov x3, 0
>  **   b   f16p
>  */
> diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c 
> b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
> index 
> da3c23550bae6734f69e2baf0e8db741fb65cfda..e7f773640f04f56646e5e1a5fb91280ea7e4db98
>  100644
> --- a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
> +++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
> @@ -54,9 +54,8 @@
>  /*
>  ** g1:
>  **   mov (w[0-9]+), w1
> -**   sbfx(x[0-9]+), x0, 0, 63
> -**   and x3, \2, 9223372036854775807
> -**   and x1, \2, 1
> +**   and x3, x0, 9223372036854775807
> +**   and x1, x0, 1
>  **   mov x2, 0
>  **   mov w0, \1
>  **   b   f1
> @@ -65,9 +64,8 @@
>  /*
>  ** g8:
>  **   mov (w[0-9]+), w1
> -**   sbfx(x[0-9]+), x0, 0, 63
> -**   and x3, \2, 9223372036854775807
> -**   and x1, \2, 1
> +**   and x3, x0, 9223372036854775807
> +**   and x1, x0, 1
>  **   mov x2, 0
>  **   mov w0, \1
>  **   b   f8
> @@ -76,9 +74,8 @@
>  ** g16:
>  **   mov (x[0-9]+), x0
>  **   mov w0, w1
> -**   sbfx(x[0-9]+), \1, 0, 63
> -**   and x4, \2, 9223372036854775807
> -**   and x2, \2, 1
> +**   and x4, \1, 9223372036854775807
> +**   and x2, \1, 1
>  **   mov x3, 0
>  **   b   f16
>  */
> @@ -107,9 +104,8 @@
>  /*
>  ** g1p:
>  **   mov (w[0-9]+), w1
> -**   sbfx(x[0-9]+), x0, 0, 63
> -**   and x3, \2, 9223372036854775807
> -**   and x1, \2, 1
> +**   and x3, x0, 9223372036854775807
> +**   and x1, x0, 1
>  **   mov x2, 0
>  **   mov w0, \1
>  **   b   f1p
> @@ -117,9 +113,8 @@
>  /*
>  ** g8p:
>  **   mov (w[0-9]+), w1
> -**   sbfx(x[0-9]+), x0, 0, 63
> -**   and x3, \2, 9223372036854775807
> -**   and x1, \2, 1
> +**   and

Re: [PATCH 2/3] bpf: remove huge memory waste with string allocation.

[David Faust]

Hi Cupertino,

On 4/11/24 04:11, Cupertino Miranda wrote:
> Code was allocating way too much space for the string.

A little bit more description would not hurt. Perhaps you could say
something like:
"The BPF backend was allocating an unnecessarily large string when
 constructing CO-RE relocations for enum types."

> 
> gcc/ChangeLog:
>   * config/bpf/core-builtins.cc (process_enum_value): Corrected
>   string allocation.

nit: present tense, i.e. "Correct" rather than "Corrected"

> ---
>  gcc/config/bpf/core-builtins.cc | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/gcc/config/bpf/core-builtins.cc b/gcc/config/bpf/core-builtins.cc
> index e03e986e2c1..ead1777d465 100644
> --- a/gcc/config/bpf/core-builtins.cc
> +++ b/gcc/config/bpf/core-builtins.cc
> @@ -872,10 +872,11 @@ process_enum_value (struct cr_builtins *data)
>   {
> if (TREE_VALUE (l) == expr)
>   {
> -   char *tmp = (char *) ggc_alloc_atomic ((index / 10) + 1);
> +   /* Array size is 21 = ceil(log_10(2^64)) + 1 to hold string
> +  representations of 64 bit integers.  */
> +   char tmp[21];
> sprintf (tmp, "%d", index);

It looks like `index' is an `unsigned int', so this sprintf should use
%u rather %d, no?

Also, it occurs to me that the `vlen' of BTF types is only 16 bits, so
BTF has no way currently to represent enums with more than 65535
enumerators. It may be worth adding a sanity check to bail out (error)
here if we're going to claim an index higher than that. And if that is
validated before the printf, the buffer can be 6 bytes ("65535\0").

> -   ret.str = (const char *) tmp;
> -
> +   ret.str = CONST_CAST (char *, ggc_strdup(tmp));
> break;
>   }
> index++;

[PATCH] aarch64: Fix _BitInt testcases

[Andre Vieira (lists)]

This patch fixes some testisms introduced by:

commit 5aa3fec38cc6f52285168b161bab1a869d864b44
Author: Andre Vieira 
Date:   Wed Apr 10 16:29:46 2024 +0100

aarch64: Add support for _BitInt

The testcases were relying on an unnecessary sign-extend that is no longer
generated.

The tested version was just slightly behind top of trunk when the patch 
was committed, and the codegen had changed, for the better, by then.


OK for trunk? (I am away tomorrow, so if you want this in before the 
weekend feel free to commit it on my behalf, if approved ofc...)



gcc/testsuite/ChangeLog:

* gcc.target/aarch64/bitfield-bitint-abi-align16.c (g1, g8, g16, g1p, 
g8p,
g16p): Remove unnecessary sbfx.
* gcc.target/aarch64/bitfield-bitint-abi-align8.c (g1, g8, g16, g1p, 
g8p,
g16p): Likewise.


diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c 
b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
index 
3f292a45f955d35b802a0bd789cd39d5fa7b5860..4a228b0a1ce696dc80e32305162d58f01d44051d
 100644
--- a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
+++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align16.c
@@ -55,9 +55,8 @@
 ** g1:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f1
 */
@@ -66,9 +65,8 @@
 ** g8:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f8
 */
@@ -76,9 +74,8 @@
 ** g16:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f16
 */
@@ -107,9 +104,8 @@
 /*
 ** g1p:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f1p
@@ -117,9 +113,8 @@
 /*
 ** g8p:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f8p
@@ -128,9 +123,8 @@
 ** g16p:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f16p
 */
diff --git a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c 
b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
index 
da3c23550bae6734f69e2baf0e8db741fb65cfda..e7f773640f04f56646e5e1a5fb91280ea7e4db98
 100644
--- a/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
+++ b/gcc/testsuite/gcc.target/aarch64/bitfield-bitint-abi-align8.c
@@ -54,9 +54,8 @@
 /*
 ** g1:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f1
@@ -65,9 +64,8 @@
 /*
 ** g8:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f8
@@ -76,9 +74,8 @@
 ** g16:
 ** mov (x[0-9]+), x0
 ** mov w0, w1
-** sbfx(x[0-9]+), \1, 0, 63
-** and x4, \2, 9223372036854775807
-** and x2, \2, 1
+** and x4, \1, 9223372036854775807
+** and x2, \1, 1
 ** mov x3, 0
 ** b   f16
 */
@@ -107,9 +104,8 @@
 /*
 ** g1p:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f1p
@@ -117,9 +113,8 @@
 /*
 ** g8p:
 ** mov (w[0-9]+), w1
-** sbfx(x[0-9]+), x0, 0, 63
-** and x3, \2, 9223372036854775807
-** and x1, \2, 1
+** and x3, x0, 9223372036854775807
+** and x1, x0, 1
 ** mov x2, 0
 ** mov w0, \1
 ** b   f8p
@@ -128,9 +123,8 @@
 ** g16p:
 ** mov (x[0-9]+), x0
 ** mov w0, w1

[PING] Re: [PATCH 1/2] ivopts: Revert computation of address cost complexity.

[Aleksandar Rakic]

PING: I remind you that the patch for the computation of complexity for 
unsupported addressing modes ( 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 ) has been sent:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647966.html

Re: Combine patch ping

[Richard Biener]

> Am 11.04.2024 um 16:03 schrieb Segher Boessenkool 
> :
> 
> On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote:
>>> On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
>>>  wrote:
>>> This is never okay.  You cannot commit a patch without approval, *ever*.
> 
> This is the biggest issue, to start with.  It is fundamental.

I have approved the patch as you might have noticed.

Richard 

>>> That patch is also obvious -- obviously *wrong*, that is.  There are
>>> big assumptions everywhere in the compiler how a CC reg can be used.
>>> This violates that, as explained elsewhere.
>> 
>> Can you please elaborate what is wrong with this concrete patch.
> 
> The explanation of the patch is contradictory to how RTL works at all,
> so it is just wrong.  It might even do something sane, but I didn't get
> that far at all!
> 
> Write good email explanations, and a good proposed commit message.
> Please.  It is the only one people can judge a patch.  Well, apart
> from doing everything myself from first principles, ignoring everything
> you said, just looking at the patch itself, but that is a hundred times
> more work.  I don't do that.
> 
>> The
>> part that the patch touches has several wrong assumptions, and the
>> fixed "???" comment just emphasizes that. I don't see what is wrong
>> with:
>> 
>> (define_insn "@pushfl2"
>>  [(set (match_operand:W 0 "push_operand" "=<")
>>(unspec:W [(match_operand 1 "flags_reg_operand")]
>>  UNSPEC_PUSHFL))]
>>  "GET_MODE_CLASS (GET_MODE (operands[1])) == MODE_CC"
>>  "pushf{}"
>>  [(set_attr "type" "push")
>>   (set_attr "mode" "")])
> 
> What does it even mean?  What is a flags:CC?  You always always always
> need to say what is *in* the flags, if you want to use it as input
> (which is what unspec does).  CC is weird like this.  Most targets do
> not have distinct physical flags for every condition, only a few
> conditions are "alive" at any point in the program!
> 
>> it is just a push of the flags reg to the stack. If the push can't be
>> described in this way, then it is the middle end at fault, we can't
>> just change modes at will.
> 
> But that is not what this describes: it operates on the flags register
> in some unspecified way, and pushes the result of *that* to the stack.
> 
> (Stack pointer modification is not described here btw, should it be?  Is
> that magically implemented by the backend some way, via type=push
> perhaps?)
> 
> 
> Segher

Re: [PATCH] Update GCC 14.1 library versions in docs

[Jonathan Wakely]

On Thu, 11 Apr 2024 at 15:50, Jakub Jelinek wrote:
>
> Hi!
>
> When we are already touching this topic, here is a patch like r13-5126
> which documents the upcoming release symbol versions in the documentation.
>
> Ok for trunk?

OK, thanks.

>
> 2024-04-11  Jakub Jelinek  
>
> * doc/xml/manual/abi.xml: Add latest library versions.
> * doc/html/manual/abi.html: Regenerate.
>
> --- gcc/doc/xml/manual/abi.xml.jj   2023-06-12 15:47:22.591501023 +0200
> +++ gcc/doc/xml/manual/abi.xml  2024-04-11 16:43:56.073565349 +0200
> @@ -360,6 +360,7 @@ compatible.
>  GCC 12.1.0: GLIBCXX_3.4.30, 
> CXXABI_1.3.13
>  GCC 13.1.0: GLIBCXX_3.4.31, 
> CXXABI_1.3.14
>  GCC 13.2.0: GLIBCXX_3.4.32, 
> CXXABI_1.3.14
> +GCC 14.1.0: GLIBCXX_3.4.33, 
> CXXABI_1.3.15
>
>  
>  
> --- gcc/doc/html/manual/abi.html.jj 2023-06-12 15:47:22.590501037 +0200
> +++ gcc/doc/html/manual/abi.html2024-04-11 16:45:31.592245629 +0200
> @@ -128,7 +128,7 @@ compatible.
> GLIBCPP_3.2 for symbols that were introduced in the GCC 3.2.0
> release.) If a particular release is not listed, it has the same
> version labels as the preceding release.
> -style="list-style-type: disc; ">GCC 3.0.0: (Error, 
> not versioned)GCC 3.0.1: (Error, not 
> versioned)GCC 3.0.2: (Error, not 
> versioned)GCC 3.0.3: (Error, not 
> versioned)GCC 3.0.4: (Error, not 
> versioned)GCC 3.1.0: GLIBCPP_3.1, 
> CXXABI_1GCC 3.1.1: GLIBCPP_3.1, 
> CXXABI_1GCC 3.2.0: GLIBCPP_3.2, 
> CXXABI_1.2GCC 3.2.1: GLIBCPP_3.2.1, 
> CXXABI_1.2GCC 3.2.2: GLIBCPP_3.2.2, 
> CXXABI_1.2GCC 3.2.3: GLIBCPP_3.2.2, 
> CXXABI_1.2GCC 3.3.0: GLIBCPP_3.2.2, 
> CXXABI_1.2.1GCC 3.3.1: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.3.2: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.3.3: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.4.0: GLIBCXX_3.4, 
> CXXABI_1.3GCC 3.4.1: GLIBCXX_3.4.1, 
> CXXABI_1.3GCC 3.4.2: 
> GLIBCXX_3.4.2GCC 3.4.3: 
> GLIBCXX_3.4.3GCC 4.0.0: GLIBCXX_3.4.4, 
> CXXABI_1.3.1GCC 4.0.1: 
> GLIBCXX_3.4.5GCC 4.0.2: 
> GLIBCXX_3.4.6GCC 4.0.3: 
> GLIBCXX_3.4.7GCC 4.1.1: 
> GLIBCXX_3.4.8GCC 4.2.0: 
> GLIBCXX_3.4.9GCC 4.3.0: GLIBCXX_3.4.10, 
> CXXABI_1.3.2GCC 4.4.0: GLIBCXX_3.4.11, 
> CXXABI_1.3.3GCC 4.4.1: GLIBCXX_3.4.12, 
> CXXABI_1.3.3GCC 4.4.2: GLIBCXX_3.4.13, 
> CXXABI_1.3.3GCC 4.5.0: GLIBCXX_3.4.14, 
> CXXABI_1.3.4GCC 4.6.0: GLIBCXX_3.4.15, 
> CXXABI_1.3.5GCC 4.6.1: GLIBCXX_3.4.16, 
> CXXABI_1.3.5GCC 4.7.0: GLIBCXX_3.4.17, 
> CXXABI_1.3.6GCC 4.8.0: GLIBCXX_3.4.18, 
> CXXABI_1.3.7GCC 4.8.3: GLIBCXX_3.4.19, 
> CXXABI_1.3.7GCC 4.9.0: GLIBCXX_3.4.20, 
> CXXABI_1.3.8GCC 5.1.0: GLIBCXX_3.4.21, 
> CXXABI_1.3.9GCC 6.1.0: GLIBCXX_3.4.22, 
> CXXABI_1.3.10GCC 7.1.0: GLIBCXX_3.4.23, 
> CXXABI_1.3.11GCC 7.2.0: GLIBCXX_3.4.24, 
> CXXABI_1.3.11GCC 8.1.0: GLIBCXX_3.4.25, 
> CXXABI_1.3.11GCC 9.1.0: GLIBCXX_3.4.26, 
> CXXABI_1.3.12GCC 9.2.0: GLIBCXX_3.4.27, 
> CXXABI_1.3.12GCC 9.3.0: GLIBCXX_3.4.28, 
> CXXABI_1.3.12GCC 10.1.0: GLIBCXX_3.4.28, 
> CXXABI_1.3.12GCC 11.1.0: GLIBCXX_3.4.29, 
> CXXABI_1.3.13GCC 12.1.0: GLIBCXX_3.4.30, 
> CXXABI_1.3.13GCC 13.1.0: GLIBCXX_3.4.31, 
> CXXABI_1.3.14GCC 13.2.0: GLIBCXX_3.4.32, 
> CXXABI_1.3.14Incremental 
> bumping of a compiler pre-defined macro,
> +style="list-style-type: disc; ">GCC 3.0.0: (Error, 
> not versioned)GCC 3.0.1: (Error, not 
> versioned)GCC 3.0.2: (Error, not 
> versioned)GCC 3.0.3: (Error, not 
> versioned)GCC 3.0.4: (Error, not 
> versioned)GCC 3.1.0: GLIBCPP_3.1, 
> CXXABI_1GCC 3.1.1: GLIBCPP_3.1, 
> CXXABI_1GCC 3.2.0: GLIBCPP_3.2, 
> CXXABI_1.2GCC 3.2.1: GLIBCPP_3.2.1, 
> CXXABI_1.2GCC 3.2.2: GLIBCPP_3.2.2, 
> CXXABI_1.2GCC 3.2.3: GLIBCPP_3.2.2, 
> CXXABI_1.2GCC 3.3.0: GLIBCPP_3.2.2, 
> CXXABI_1.2.1GCC 3.3.1: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.3.2: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.3.3: GLIBCPP_3.2.3, 
> CXXABI_1.2.1GCC 3.4.0: GLIBCXX_3.4, 
> CXXABI_1.3GCC 3.4.1: GLIBCXX_3.4.1, 
> CXXABI_1.3GCC 3.4.2: 
> GLIBCXX_3.4.2GCC 3.4.3: 
> GLIBCXX_3.4.3GCC 4.0.0: GLIBCXX_3.4.4, 
> CXXABI_1.3.1GCC 4.0.1: 
> GLIBCXX_3.4.5GCC 4.0.2: 
> GLIBCXX_3.4.6GCC 4.0.3: 
> GLIBCXX_3.4.7GCC 4.1.1: 
> GLIBCXX_3.4.8GCC 4.2.0: 
> GLIBCXX_3.4.9GCC 4.3.0: GLIBCXX_3.4.10, 
> CXXABI_1.3.2GCC 4.4.0: GLIBCXX_3.4.11, 
> CXXABI_1.3.3GCC 4.4.1: GLIBCXX_3.4.12, 
> CXXABI_1.3.3GCC 4.4.2: GLIBCXX_3.4.13, 
> CXXABI_1.3.3GCC 4.5.0: GLIBCXX_3.4.14, 
> CXXABI_1.3.4GCC 4.6.0: GLIBCXX_3.4.15, 
> CXXABI_1.3.5GCC 4.6.1: GLIBCXX_3.4.16, 
> CXXABI_1.3.5GCC 4.7.0: GLIBCXX_3.4.17, 
> CXXABI_1.3.6GCC 4.8.0: GLIBCXX_3.4.18, 
> CXXABI_1.3.7GCC 4.8.3: GLIBCXX_3.4.19, 
> CXXABI_1.3.7GCC 4.9.0: GLIBCXX_3.4.20, 
> CXXABI_1.3.8GCC 5.1.0: GLIBCXX_3.4.21, 
> CXXABI_1.3.9GCC 6.1.0: GLIBCXX_3.4.22, 
> CXXABI_1.3.10GCC 7.1.0: GLIBCXX_3.4.23, 
> CXXABI_1.3.11GCC 7.2.0: GLIBCXX_3.4.24, 
> CXXABI_1.3.11GCC 8.1.0: GLIBCXX_3.4.25, 
> CXXABI_1.3.11GCC 9.1.0: GLIBCXX_3.4.26, 
> CXXABI_1.3.12GCC 9.2.0: GLIBCXX_3.4.27, 
> CXXABI_1.3.12GCC 9.3.0: GLIBCXX_3.4.28, 
> CXXABI_1.3.12GCC 10.1.0: GLIBCXX_3.4.28, 
> CXXABI_1.3.12GCC 11.1.0: GLIBCXX_3.4.29, 
> CXXABI_1.3.13GCC 12.1.0: 

[PATCH] Update GCC 14.1 library versions in docs

[Jakub Jelinek]

Hi!

When we are already touching this topic, here is a patch like r13-5126
which documents the upcoming release symbol versions in the documentation.

Ok for trunk?

2024-04-11  Jakub Jelinek  

* doc/xml/manual/abi.xml: Add latest library versions.
* doc/html/manual/abi.html: Regenerate.

--- gcc/doc/xml/manual/abi.xml.jj   2023-06-12 15:47:22.591501023 +0200
+++ gcc/doc/xml/manual/abi.xml  2024-04-11 16:43:56.073565349 +0200
@@ -360,6 +360,7 @@ compatible.
 GCC 12.1.0: GLIBCXX_3.4.30, CXXABI_1.3.13
 GCC 13.1.0: GLIBCXX_3.4.31, CXXABI_1.3.14
 GCC 13.2.0: GLIBCXX_3.4.32, CXXABI_1.3.14
+GCC 14.1.0: GLIBCXX_3.4.33, CXXABI_1.3.15
 
 
 
--- gcc/doc/html/manual/abi.html.jj 2023-06-12 15:47:22.590501037 +0200
+++ gcc/doc/html/manual/abi.html2024-04-11 16:45:31.592245629 +0200
@@ -128,7 +128,7 @@ compatible.
GLIBCPP_3.2 for symbols that were introduced in the GCC 3.2.0
release.) If a particular release is not listed, it has the same
version labels as the preceding release.
-   GCC 3.0.0: (Error, not 
versioned)GCC 3.0.1: (Error, not 
versioned)GCC 3.0.2: (Error, not 
versioned)GCC 3.0.3: (Error, not 
versioned)GCC 3.0.4: (Error, not 
versioned)GCC 3.1.0: GLIBCPP_3.1, 
CXXABI_1GCC 3.1.1: GLIBCPP_3.1, 
CXXABI_1GCC 3.2.0: GLIBCPP_3.2, 
CXXABI_1.2GCC 3.2.1: GLIBCPP_3.2.1, 
CXXABI_1.2GCC 3.2.2: GLIBCPP_3.2.2, 
CXXABI_1.2GCC 3.2.3: GLIBCPP_3.2.2, 
CXXABI_1.2GCC 3.3.0: GLIBCPP_3.2.2, 
CXXABI_1.2.1GCC 3.3.1: GLIBCPP_3.2.3, 
CXXABI_1.2.1GCC 3.3.2: GLIBCPP_3.2.3, 
CXXABI_1.2.1GCC 3.3.3: GLIBCPP_3.2.3, 
CXXABI_1.2.1GCC 3.4.0: GLIBCXX_3.4, 
CXXABI_1.3GCC 3.4.1: GLIBCXX_3.4.1, 
CXXABI_1.3GCC 3.4.2: GLIBCXX_3.4.2GCC 3.4.3: GLIBCXX_3.4.3GCC 4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1GCC 4.0.1: GLIBCXX_3.4.5GCC 4.0.2: GLIBCXX_3.4.6GCC 4.0.3: GLIBCXX_3.4.7GCC 4.1.1: GLIBCXX_3.4.8GCC 4.2.0: GLIBCXX_3.4.9GCC 4.3.0: GLIBCXX_3.4.10, CXXABI_1.3.2GCC 4.4.0: GLIBCXX_3.4.11, CXXABI_1.3.3GCC 4.4.1: GLIBCXX_3.4.12, CXXABI_1.3.3GCC 4.4.2: GLIBCXX_3.4.13, CXXABI_1.3.3GCC 4.5.0: GLIBCXX_3.4.14, CXXABI_1.3.4GCC 4.6.0: GLIBCXX_3.4.15, CXXABI_1.3.5GCC 4.6.1: GLIBCXX_3.4.16, CXXABI_1.3.5GCC 4.7.0: GLIBCXX_3.4.17, CXXABI_1.3.6GCC 4.8.0: GLIBCXX_3.4.18, CXXABI_1.3.7GCC 4.8.3: GLIBCXX_3.4.19, CXXABI_1.3.7GCC 4.9.0: GLIBCXX_3.4.20, CXXABI_1.3.8GCC 5.1.0: GLIBCXX_3.4.21, CXXABI_1.3.9GCC 6.1.0: GLIBCXX_3.4.22, CXXABI_1.3.10GCC 7.1.0: GLIBCXX_3.4.23, CXXABI_1.3.11GCC 7.2.0: GLIBCXX_3.4.24, CXXABI_1.3.11GCC 8.1.0: GLIBCXX_3.4.25, CXXABI_1.3.11GCC 9.1.0: GLIBCXX_3.4.26, CXXABI_1.3.12GCC 9.2.0: GLIBCXX_3.4.27, CXXABI_1.3.12GCC 9.3.0: GLIBCXX_3.4.28, CXXABI_1.3.12GCC 10.1.0: GLIBCXX_3.4.28, CXXABI_1.3.12GCC 11.1.0: GLIBCXX_3.4.29, CXXABI_1.3.13GCC 12.1.0: GLIBCXX_3.4.30, CXXABI_1.3.13GCC 13.1.0: GLIBCXX_3.4.31, CXXABI_1.3.14GCC 13.2.0: GLIBCXX_3.4.32, 
CXXABI_1.3.14Incremental 
bumping of a compiler pre-defined macro,
+   GCC 3.0.0: (Error, not 
versioned)GCC 3.0.1: (Error, not 
versioned)GCC 3.0.2: (Error, not 
versioned)GCC 3.0.3: (Error, not 
versioned)GCC 3.0.4: (Error, not 
versioned)GCC 3.1.0: GLIBCPP_3.1, 
CXXABI_1GCC 3.1.1: GLIBCPP_3.1, 
CXXABI_1GCC 3.2.0: GLIBCPP_3.2, 
CXXABI_1.2GCC 3.2.1: GLIBCPP_3.2.1, 
CXXABI_1.2GCC 3.2.2: GLIBCPP_3.2.2, 
CXXABI_1.2GCC 3.2.3: GLIBCPP_3.2.2, 
CXXABI_1.2GCC 3.3.0: GLIBCPP_3.2.2, 
CXXABI_1.2.1GCC 3.3.1: GLIBCPP_3.2.3, 
CXXABI_1.2.1GCC 3.3.2: GLIBCPP_3.2.3, 
CXXABI_1.2.1GCC 3.3.3: GLIBCPP_3.2.3, 
CXXABI_1.2.1GCC 3.4.0: GLIBCXX_3.4, 
CXXABI_1.3GCC 3.4.1: GLIBCXX_3.4.1, 
CXXABI_1.3GCC 3.4.2: GLIBCXX_3.4.2GCC 3.4.3: GLIBCXX_3.4.3GCC 4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1GCC 4.0.1: GLIBCXX_3.4.5GCC 4.0.2: GLIBCXX_3.4.6GCC 4.0.3: GLIBCXX_3.4.7GCC 4.1.1: GLIBCXX_3.4.8GCC 4.2.0: GLIBCXX_3.4.9GCC 4.3.0: GLIBCXX_3.4.10, CXXABI_1.3.2GCC 4.4.0: GLIBCXX_3.4.11, CXXABI_1.3.3GCC 4.4.1: GLIBCXX_3.4.12, CXXABI_1.3.3GCC 4.4.2: GLIBCXX_3.4.13, CXXABI_1.3.3GCC 4.5.0: GLIBCXX_3.4.14, CXXABI_1.3.4GCC 4.6.0: GLIBCXX_3.4.15, CXXABI_1.3.5GCC 4.6.1: GLIBCXX_3.4.16, CXXABI_1.3.5GCC 4.7.0: GLIBCXX_3.4.17, CXXABI_1.3.6GCC 4.8.0: GLIBCXX_3.4.18, CXXABI_1.3.7GCC 4.8.3: GLIBCXX_3.4.19, CXXABI_1.3.7GCC 4.9.0: GLIBCXX_3.4.20, CXXABI_1.3.8GCC 5.1.0: GLIBCXX_3.4.21, CXXABI_1.3.9GCC 6.1.0: GLIBCXX_3.4.22, CXXABI_1.3.10GCC 7.1.0: GLIBCXX_3.4.23, CXXABI_1.3.11GCC 7.2.0: GLIBCXX_3.4.24, CXXABI_1.3.11GCC 8.1.0: GLIBCXX_3.4.25, CXXABI_1.3.11GCC 9.1.0: GLIBCXX_3.4.26, CXXABI_1.3.12GCC 9.2.0: GLIBCXX_3.4.27, CXXABI_1.3.12GCC 9.3.0: GLIBCXX_3.4.28, CXXABI_1.3.12GCC 10.1.0: GLIBCXX_3.4.28, CXXABI_1.3.12GCC 11.1.0: GLIBCXX_3.4.29, CXXABI_1.3.13GCC 12.1.0: GLIBCXX_3.4.30, CXXABI_1.3.13GCC 13.1.0: GLIBCXX_3.4.31, CXXABI_1.3.14GCC 13.2.0: GLIBCXX_3.4.32, CXXABI_1.3.14GCC 14.1.0: GLIBCXX_3.4.33, 
CXXABI_1.3.15Incremental 
bumping of a compiler pre-defined macro,
 __GXX_ABI_VERSION. This macro is defined as the version of the
 compiler v3 ABI, with g++ 3.0 being version 100. This macro will
 be automatically defined whenever g++ is used (the curious can

Jakub

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

[Jonathan Wakely]

On Thu, 11 Apr 2024 at 15:46, Andreas Schwab wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote:
> >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> >> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> >
> > If there are other changes needed for m68k, it means it wasn't regenerated
> > properly before the 13.1 release a year ago.
>
> Why do you think this has anything to do with m68k?


Looks like you were pointing out some missing lines for the
riscv64-linux-gnu baseline file, but Jakub's comment still applies.
That arch wasn't in Fedora, so wasn't in his r13-6532-gf875857e008c44
commit.

A riscv64-linux-gnu maintainer should have done that.

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

[Andreas Schwab]

On Apr 11 2024, Jakub Jelinek wrote:

> On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote:
>> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
>> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
>> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
>> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
>
> If there are other changes needed for m68k, it means it wasn't regenerated
> properly before the 13.1 release a year ago.

Why do you think this has anything to do with m68k?

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

[Jonathan Wakely]

On Thu, 11 Apr 2024 at 15:36, Andreas Schwab  wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj  
> >   2024-04-11 15:55:49.982325397 +0200
> > +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt 
> >   2024-04-11 16:10:05.206559463 +0200
> > @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
> >  FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
> >  FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
> >  FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
> > +FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
> >  FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
> >  FUNC:_ZNKSt12bad_weak_ptr4whatEv@@GLIBCXX_3.4.15
> >  FUNC:_ZNKSt12future_error4whatEv@@GLIBCXX_3.4.14
> > @@ -4525,6 +4526,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
> >  FUNC:__cxa_bad_cast@@CXXABI_1.3
> >  FUNC:__cxa_bad_typeid@@CXXABI_1.3
> >  FUNC:__cxa_begin_catch@@CXXABI_1.3
> > +FUNC:__cxa_call_terminate@@CXXABI_1.3.15
> >  FUNC:__cxa_call_unexpected@@CXXABI_1.3
> >  FUNC:__cxa_current_exception_type@@CXXABI_1.3
> >  FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
> > @@ -4568,6 +4570,7 @@ OBJECT:0:CXXABI_1.3.11
> >  OBJECT:0:CXXABI_1.3.12
> >  OBJECT:0:CXXABI_1.3.13
> >  OBJECT:0:CXXABI_1.3.14
> > +OBJECT:0:CXXABI_1.3.15
> >  OBJECT:0:CXXABI_1.3.2
> >  OBJECT:0:CXXABI_1.3.3
> >  OBJECT:0:CXXABI_1.3.4
> > @@ -4604,6 +4607,7 @@ OBJECT:0:GLIBCXX_3.4.3
> >  OBJECT:0:GLIBCXX_3.4.30
> >  OBJECT:0:GLIBCXX_3.4.31
> >  OBJECT:0:GLIBCXX_3.4.32
> > +OBJECT:0:GLIBCXX_3.4.33
> >  OBJECT:0:GLIBCXX_3.4.4
> >  OBJECT:0:GLIBCXX_3.4.5
> >  OBJECT:0:GLIBCXX_3.4.6
>
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31


Ah yes, looks like these were added for other arches in
r13-6532-gf875857e008c44 but that didn't include riscv64-linux

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

[Jakub Jelinek]

On Thu, Apr 11, 2024 at 04:35:52PM +0200, Andreas Schwab wrote:
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
> +FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31

If there are other changes needed for m68k, it means it wasn't regenerated
properly before the 13.1 release a year ago.
As I wrote, I don't have access to some of the arches and for that I just
apply by hand the expected changes, while for arches I have access to I
regenerate.

Jakub

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

[Andreas Schwab]

On Apr 11 2024, Jakub Jelinek wrote:

> --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj
> 2024-04-11 15:55:49.982325397 +0200
> +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt   
> 2024-04-11 16:10:05.206559463 +0200
> @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
>  FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
> +FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
>  FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
>  FUNC:_ZNKSt12bad_weak_ptr4whatEv@@GLIBCXX_3.4.15
>  FUNC:_ZNKSt12future_error4whatEv@@GLIBCXX_3.4.14
> @@ -4525,6 +4526,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
>  FUNC:__cxa_bad_cast@@CXXABI_1.3
>  FUNC:__cxa_bad_typeid@@CXXABI_1.3
>  FUNC:__cxa_begin_catch@@CXXABI_1.3
> +FUNC:__cxa_call_terminate@@CXXABI_1.3.15
>  FUNC:__cxa_call_unexpected@@CXXABI_1.3
>  FUNC:__cxa_current_exception_type@@CXXABI_1.3
>  FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
> @@ -4568,6 +4570,7 @@ OBJECT:0:CXXABI_1.3.11
>  OBJECT:0:CXXABI_1.3.12
>  OBJECT:0:CXXABI_1.3.13
>  OBJECT:0:CXXABI_1.3.14
> +OBJECT:0:CXXABI_1.3.15
>  OBJECT:0:CXXABI_1.3.2
>  OBJECT:0:CXXABI_1.3.3
>  OBJECT:0:CXXABI_1.3.4
> @@ -4604,6 +4607,7 @@ OBJECT:0:GLIBCXX_3.4.3
>  OBJECT:0:GLIBCXX_3.4.30
>  OBJECT:0:GLIBCXX_3.4.31
>  OBJECT:0:GLIBCXX_3.4.32
> +OBJECT:0:GLIBCXX_3.4.33
>  OBJECT:0:GLIBCXX_3.4.4
>  OBJECT:0:GLIBCXX_3.4.5
>  OBJECT:0:GLIBCXX_3.4.6

+FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31
+FUNC:_ZNKSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEcvbEv@@GLIBCXX_3.4.31

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH v2 00/13] Add aarch64-w64-mingw32 target

[Richard Sandiford]

Evgeny Karpov  writes:
> Wednesday, April 10, 2024 8:40 PM
> Richard Sandiford  wrote:
>
>> Thanks for the updates and sorry again for the slow review.
>> I've replied to some of the patches in the series but otherwise it looks 
>> good to
>> me.
>> 
>> If you agree with the suggested changes then the series is OK for stage 1,
>> assuming no objections from those with an interest in the
>> x86 cygwin/mingw port.
>> 
>> Richard
>
> Thank you, Richard, for the review!
> v3 addresses all comments on v2.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/thread.html#649261

Thanks, the new series looks good to me.

Richard

Re: [PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

[Jonathan Wakely]

On Thu, 11 Apr 2024 at 15:18, Jakub Jelinek wrote:
>
> Hi!
>
> While the previous patch was regeneration from 13.2 release (with hand
> edits for arches I don't have libraries for but which are still well
> maintained), thius one is regeneration from the trunk (this time for
> hand edits everywhere for the PR114692
> https://gcc.gnu.org/pipermail/libstdc++/2024-April/058570.html
> patch; plus again hand edits for arches I don't have libraries for).
>
> Ok for trunk after the PR114692 patch is committed?

Yes, OK for trunk now, thanks.


>
> 2024-04-11  Jakub Jelinek  
>
> * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
> * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
>
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj 
>   2024-04-11 15:55:49.974325507 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
> 2024-04-11 16:01:28.877662971 +0200
> @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
>  FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
> +FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
>  FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
>  
> FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
>  
> FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
> @@ -4533,6 +4534,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
>  FUNC:__cxa_bad_cast@@CXXABI_1.3
>  FUNC:__cxa_bad_typeid@@CXXABI_1.3
>  FUNC:__cxa_begin_catch@@CXXABI_1.3
> +FUNC:__cxa_call_terminate@@CXXABI_1.3.15
>  FUNC:__cxa_call_unexpected@@CXXABI_1.3
>  FUNC:__cxa_current_exception_type@@CXXABI_1.3
>  FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
> @@ -4576,6 +4578,7 @@ OBJECT:0:CXXABI_1.3.11
>  OBJECT:0:CXXABI_1.3.12
>  OBJECT:0:CXXABI_1.3.13
>  OBJECT:0:CXXABI_1.3.14
> +OBJECT:0:CXXABI_1.3.15
>  OBJECT:0:CXXABI_1.3.2
>  OBJECT:0:CXXABI_1.3.3
>  OBJECT:0:CXXABI_1.3.4
> @@ -4613,6 +4616,7 @@ OBJECT:0:GLIBCXX_3.4.3
>  OBJECT:0:GLIBCXX_3.4.30
>  OBJECT:0:GLIBCXX_3.4.31
>  OBJECT:0:GLIBCXX_3.4.32
> +OBJECT:0:GLIBCXX_3.4.33
>  OBJECT:0:GLIBCXX_3.4.4
>  OBJECT:0:GLIBCXX_3.4.5
>  OBJECT:0:GLIBCXX_3.4.6
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt.jj  
>   2024-04-11 15:55:49.976325479 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt 
>   2024-04-11 16:01:00.085059091 +0200
> @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
>  FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
> +FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
>  FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
>  
> FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
>  
> FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
> @@ -4533,6 +4534,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
>  FUNC:__cxa_bad_cast@@CXXABI_1.3
>  FUNC:__cxa_bad_typeid@@CXXABI_1.3
>  FUNC:__cxa_begin_catch@@CXXABI_1.3
> +FUNC:__cxa_call_terminate@@CXXABI_1.3.15
>  FUNC:__cxa_call_unexpected@@CXXABI_1.3
>  FUNC:__cxa_current_exception_type@@CXXABI_1.3
>  FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
> @@ -4576,6 +4578,7 @@ OBJECT:0:CXXABI_1.3.11
>  OBJECT:0:CXXABI_1.3.12
>  OBJECT:0:CXXABI_1.3.13
>  OBJECT:0:CXXABI_1.3.14
> +OBJECT:0:CXXABI_1.3.15
>  OBJECT:0:CXXABI_1.3.2
>  OBJECT:0:CXXABI_1.3.3
>  OBJECT:0:CXXABI_1.3.4
> @@ -4613,6 +4616,7 @@ OBJECT:0:GLIBCXX_3.4.3
>  OBJECT:0:GLIBCXX_3.4.30
>  OBJECT:0:GLIBCXX_3.4.31
>  OBJECT:0:GLIBCXX_3.4.32
> +OBJECT:0:GLIBCXX_3.4.33
>  OBJECT:0:GLIBCXX_3.4.4
>  OBJECT:0:GLIBCXX_3.4.5
>  OBJECT:0:GLIBCXX_3.4.6
> --- libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt.jj 
> 2024-04-11 15:55:49.977325466 +0200
> +++ libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt
> 2024-04-11 16:01:00.085059091 +0200
> @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
>  FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
>  

[committed 5/5 v2] aarch64: Remove FMV features whose names may change

[Andrew Carlotti]

Some architecture features have been combined under a single command
line flag, but have been assigned multiple FMV feature names with the
command line flag name enabling only a subset of these features in
the FMV specification.  I've proposed reallocating names in the FMV
specification to match the command line flags [1], but for GCC 14 we'll
just remove them from the FMV feature list.

[1] https://github.com/ARM-software/acle/pull/315

gcc/ChangeLog:

* config/aarch64/aarch64-option-extensions.def:
Remove "memtag", "memtag2", "ssbs", "ssbs2", "ls64", "ls64_v"
and "ls64_accdata" FMV features.


diff --git a/gcc/config/aarch64/aarch64-option-extensions.def 
b/gcc/config/aarch64/aarch64-option-extensions.def
index 
54bbf9c41e794786dffd69dd103fcbbca0a49f1f..3155eccd39c8e6825b7fc2bb0d0514c2e7e559bf
 100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -194,17 +194,13 @@ AARCH64_FMV_FEATURE("sve2-sm4", SVE_SM4, (SVE2_SM4))
 
 AARCH64_OPT_FMV_EXTENSION("sme", SME, (BF16, SVE2), (), (), "sme")
 
-AARCH64_OPT_FMV_EXTENSION("memtag", MEMTAG, (), (), (), "")
-
-AARCH64_FMV_FEATURE("memtag2", MEMTAG2, (MEMTAG))
+AARCH64_OPT_EXTENSION("memtag", MEMTAG, (), (), (), "")
 
 AARCH64_OPT_FMV_EXTENSION("sb", SB, (), (), (), "sb")
 
 AARCH64_OPT_FMV_EXTENSION("predres", PREDRES, (), (), (), "")
 
-AARCH64_OPT_FMV_EXTENSION("ssbs", SSBS, (), (), (), "ssbs")
-
-AARCH64_FMV_FEATURE("ssbs2", SSBS2, (SSBS))
+AARCH64_OPT_EXTENSION("ssbs", SSBS, (), (), (), "ssbs")
 
 AARCH64_OPT_EXTENSION("profile", PROFILE, (), (), (), "")
 
@@ -214,12 +210,6 @@ AARCH64_OPT_EXTENSION("pauth", PAUTH, (), (), (), "paca 
pacg")
 
 AARCH64_OPT_EXTENSION("ls64", LS64, (), (), (), "")
 
-AARCH64_FMV_FEATURE("ls64", LS64, ())
-
-AARCH64_FMV_FEATURE("ls64_v", LS64_V, ())
-
-AARCH64_FMV_FEATURE("ls64_accdata", LS64_ACCDATA, (LS64))
-
 AARCH64_OPT_EXTENSION("sme-f64f64", SME_F64F64, (SME), (), (), "")
 
 AARCH64_FMV_FEATURE("sme-f64f64", SME_F64, (SME_F64F64))

Re: [PATCH, OpenACC 2.7] Connect readonly modifier to points-to analysis

[Thomas Schwinge]

Hi Chung-Lin, Richard!

>From me just a few mechanical pieces, see below.  Richard, are you able
to again comment on Chung-Lin's general strategy, as I'm not at all
familiar with those parts of the code?

On 2024-04-03T19:50:55+0800, Chung-Lin Tang  wrote:
> On 2023/10/30 8:46 PM, Richard Biener wrote:
>>>
>>> What Chung-Lin's first patch does is mark the OMP clause for 'x' (not the
>>> 'x' decl itself!) as 'readonly', via a new 'OMP_CLAUSE_MAP_READONLY'
>>> flag.
>>>
>>> The actual optimization then is done in this second patch.  Chung-Lin
>>> found that he could use 'SSA_NAME_POINTS_TO_READONLY_MEMORY' for that.
>>> I don't have much experience with most of the following generic code, so
>>> would appreciate a helping hand, whether that conceptually makes sense as
>>> well as from the implementation point of view:
>
> First of all, I have removed all of the gimplify-stage scanning and setting of
> DECL_POINTS_TO_READONLY and SSA_NAME_POINTS_TO_READONLY_MEMORY (so no changes 
> to
> gimplify.cc now)
>
> I remember this code was an artifact of earlier attempts to allow 
> struct-member
> pointer mappings to also work (e.g. map(readonly:rec.ptr[:N])), but failed 
> anyways.
> I think the omp_data_* member accesses when building child function side
> receiver_refs is blocking points-to analysis from working (didn't try digging 
> deeper)
>
> Also during gimplify, VAR_DECLs appeared to be reused (at least in some 
> cases) for map
> clause decl reference building, so hoping that the variables "happen to be" 
> single-use and
> DECL_POINTS_TO_READONLY relaying into SSA_NAME_POINTS_TO_READONLY_MEMORY does 
> appear to be
> a little risky.
>
> However, for firstprivate pointers processed during omp-low, it appears to be 
> somewhat different.
> (see below description)
>
>> No, I don't think you can use that flag on non-default-defs, nor
>> preserve it on copying.  So
>> it also doesn't nicely extend to DECLs as done by the patch.  We
>> currently _only_ use it
>> for incoming parameters.  When used on arbitrary code you can get to for 
>> example
>> 
>> ptr1(points-to-readony-memory) = >x;
>> ... access via ptr1 ...
>> ptr2 = >x;
>> ... access via ptr2 ...
>> 
>> where both are your OMP regions differently constrained (the constrain is on 
>> the
>> code in the region, _not_ on the actual protections of the pointed to
>> data, much like
>> for the fortran case).  But now CSE comes along and happily replaces all ptr2
>> with ptr2 in the second region and ... oops!
>
> Richard, I assume what you meant was "happily replaces all ptr2 with ptr1 in 
> the second region"?
>
> That doesn't happen, because during omp-lower/expand, OMP target regions 
> (which is all that
> this applies currently) is separated into different individual child 
> functions.
>
> (Currently, the only "effective" use of DECL_POINTS_TO_READONLY is during 
> omp-lower, when
> for firstprivate pointers (i.e. 'a' here) we set this bit when constructing 
> the first load
> of this pointer)
>
>   #pragma acc parallel copyin(readonly: a[:32]) copyout(r)
>   {
> foo (a, a[8]);
> r = a[8];
>   }
>   #pragma acc parallel copyin(readonly: a[:32]) copyout(r)
>   {
> foo (a, a[12]);
> r = a[12];
>   }
>
> After omp-expand (before SSA):
>
> __attribute__((oacc parallel, omp target entrypoint, noclone))
> void main._omp_fn.1 (const struct .omp_data_t.3 & restrict .omp_data_i)
> {
>  ...
>:
>   D.2962 = .omp_data_i->D.2947;
>   a.8 = D.2962;
>   r.1 = (*a.8)[12];
>   foo (a.8, r.1);
>   r.1 = (*a.8)[12];
>   D.2965 = .omp_data_i->r;
>   *D.2965 = r.1;
>   return;
> }
>
> __attribute__((oacc parallel, omp target entrypoint, noclone))
> void main._omp_fn.0 (const struct .omp_data_t.2 & restrict .omp_data_i)
> {
>   ...
>:
>   D.2968 = .omp_data_i->D.2939;
>   a.4 = D.2968;
>   r.0 = (*a.4)[8];
>   foo (a.4, r.0);
>   r.0 = (*a.4)[8];
>   D.2971 = .omp_data_i->r;
>   *D.2971 = r.0;
>   return;
> }
>
> So actually, the creating of DECL_POINTS_TO_READONLY and its relaying to
> SSA_NAME_POINTS_TO_READONLY_MEMORY here, is actually quite similar to a 
> default-def
> for an PARM_DECL, at least conceptually.
>
> (If offloading was structured significantly differently, say if child 
> functions
> were separated much earlier before omp-lowering, than this readonly-modifier 
> might
> possibly be a direct application of 'r' in the "fn spec" attribute)
>
> Other changes since first version of patch include:
> 1) update of C/C++ FE changes to new style in c-family/c-omp.cc
> 2) merging of two if cases in fortran/trans-openmp.cc like Thomas suggested
> 3) Update of readonly-2.c testcase to scan before/after "fre1" pass, to 
> verify removal of a MEM load, also as Thomas suggested.

Thanks!

> I have re-tested this patch using mainline, with no regressions. Is this okay 
> for mainline?

> 2024-04-03  Chung-Lin Tang  
>
> gcc/c-family/ChangeLog:
>
>   * c-omp.cc (c_omp_address_inspector::expand_array_base):
>   Set 

[committed 3/5] aarch64: Fix typo and make rdma/rdm alias for FMV

[Andrew Carlotti]

gcc/ChangeLog:

* config/aarch64/aarch64-option-extensions.def:
Fix "rmd"->"rdm", and add FMV to "rdma".
* config/aarch64/aarch64.cc (FEAT_RDMA): Define as FEAT_RDM.


diff --git a/gcc/config/aarch64/aarch64-option-extensions.def 
b/gcc/config/aarch64/aarch64-option-extensions.def
index 
0078dd092884a94d2a339b5238b8d19747ff9fa1..b7b307b24eadd83a6d083955f5b30814b7212712
 100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -117,9 +117,10 @@ AARCH64_OPT_FMV_EXTENSION("sm4", SM4, (SIMD), (), (), "sm3 
sm4")
 
 /* An explicit +rdma implies +simd, but +rdma+nosimd still enables scalar
RDMA instructions.  */
-AARCH64_OPT_EXTENSION("rdma", RDMA, (), (SIMD), (), "asimdrdm")
+AARCH64_OPT_FMV_EXTENSION("rdma", RDMA, (), (SIMD), (), "asimdrdm")
 
-AARCH64_FMV_FEATURE("rmd", RDM, (RDMA))
+/* rdm is an alias for rdma.  */
+AARCH64_FMV_FEATURE("rdm", RDM, (RDMA))
 
 AARCH64_OPT_FMV_EXTENSION("crc", CRC, (), (), (), "crc32")
 
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
4f708213551523b4af966ac8521754df5eb6bf3c..e6703e06d55d33163da5abb7ea518671e76c26d3
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -19657,6 +19657,10 @@ typedef struct
 #define AARCH64_FMV_FEATURE(NAME, FEAT_NAME, C) \
   {NAME, 1ULL << FEAT_##FEAT_NAME, ::feature_deps::fmv_deps_##FEAT_NAME},
 
+/* The "rdma" alias uses a different FEAT_NAME to avoid a duplicate
+   feature_deps name.  */
+#define FEAT_RDMA FEAT_RDM
+
 /* FMV features are listed in priority order, to make it easier to sort target
strings.  */
 static aarch64_fmv_feature_datum aarch64_fmv_feature_data[] = {

[committed 4/5] aarch64: Remove unsupported FMV features

[Andrew Carlotti]

It currently isn't possible to support function multiversioning features
properly in GCC without also enabling the extension in the command line
options (with the exception of features such as "rpres" that do not
require assembler support).  We therefore remove unsupported features
from GCC's list of FMV features.

Some of these features ("fcma", "jscvt", "frintts", "flagm2", "wfxt",
"rcpc2", and perhaps "dpb" and "dpb2") will be added back in the future
once support for the command line option has been added.

The rest of the removed features I have proposed removing from the ACLE
specification as well, since it doesn't seem worthwhile to include support
for them; see the ACLE pull request for more detailed justification:
https://github.com/ARM-software/acle/pull/315

gcc/ChangeLog:

* config/aarch64/aarch64-option-extensions.def:
Remove "flagm2", "sha1", "pmull", "dit", "dpb", "dpb2", "jscvt",
"fcma", "rcpc2", "frintts", "dgh", "ebf16", "sve-bf16",
"sve-ebf16", "sve-i8mm", "sve2-pmull128", "memtag3", "bti" and
"wfxt" entries.


diff --git a/gcc/config/aarch64/aarch64-option-extensions.def 
b/gcc/config/aarch64/aarch64-option-extensions.def
index 
b7b307b24eadd83a6d083955f5b30814b7212712..54bbf9c41e794786dffd69dd103fcbbca0a49f1f
 100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -103,8 +103,6 @@ AARCH64_OPT_FMV_EXTENSION("rng", RNG, (), (), (), "rng")
 
 AARCH64_OPT_FMV_EXTENSION("flagm", FLAGM, (), (), (), "flagm")
 
-AARCH64_FMV_FEATURE("flagm2", FLAGM2, (FLAGM))
-
 AARCH64_OPT_FMV_EXTENSION("lse", LSE, (), (), (), "atomics")
 
 AARCH64_OPT_FMV_EXTENSION("fp", FP, (), (), (), "fp")
@@ -124,16 +122,12 @@ AARCH64_FMV_FEATURE("rdm", RDM, (RDMA))
 
 AARCH64_OPT_FMV_EXTENSION("crc", CRC, (), (), (), "crc32")
 
-AARCH64_FMV_FEATURE("sha1", SHA1, ())
-
 AARCH64_OPT_FMV_EXTENSION("sha2", SHA2, (SIMD), (), (), "sha1 sha2")
 
 AARCH64_FMV_FEATURE("sha3", SHA3, (SHA3))
 
 AARCH64_OPT_FMV_EXTENSION("aes", AES, (SIMD), (), (), "aes")
 
-AARCH64_FMV_FEATURE("pmull", PMULL, ())
-
 /* +nocrypto disables AES, SHA2 and SM4, and anything that depends on them
(such as SHA3 and the SVE2 crypto extensions).  */
 AARCH64_OPT_EXTENSION("crypto", CRYPTO, (AES, SHA2), (), (AES, SHA2, SM4),
@@ -157,44 +151,20 @@ AARCH64_OPT_EXTENSION("fp16fml", F16FML, (), (F16), (), 
"asimdfhm")
 
 AARCH64_FMV_FEATURE("fp16fml", FP16FML, (F16FML))
 
-AARCH64_FMV_FEATURE("dit", DIT, ())
-
-AARCH64_FMV_FEATURE("dpb", DPB, ())
-
-AARCH64_FMV_FEATURE("dpb2", DPB2, ())
-
-AARCH64_FMV_FEATURE("jscvt", JSCVT, ())
-
-AARCH64_FMV_FEATURE("fcma", FCMA, (SIMD))
-
 AARCH64_OPT_FMV_EXTENSION("rcpc", RCPC, (), (), (), "lrcpc")
 
-AARCH64_FMV_FEATURE("rcpc2", RCPC2, (RCPC))
-
 AARCH64_OPT_FMV_EXTENSION("rcpc3", RCPC3, (), (), (), "lrcpc3")
 
-AARCH64_FMV_FEATURE("frintts", FRINTTS, ())
-
-AARCH64_FMV_FEATURE("dgh", DGH, ())
-
 AARCH64_OPT_FMV_EXTENSION("i8mm", I8MM, (SIMD), (), (), "i8mm")
 
 /* An explicit +bf16 implies +simd, but +bf16+nosimd still enables scalar BF16
instructions.  */
 AARCH64_OPT_FMV_EXTENSION("bf16", BF16, (FP), (SIMD), (), "bf16")
 
-AARCH64_FMV_FEATURE("ebf16", EBF16, (BF16))
-
 AARCH64_FMV_FEATURE("rpres", RPRES, ())
 
 AARCH64_OPT_FMV_EXTENSION("sve", SVE, (SIMD, F16), (), (), "sve")
 
-AARCH64_FMV_FEATURE("sve-bf16", SVE_BF16, (SVE, BF16))
-
-AARCH64_FMV_FEATURE("sve-ebf16", SVE_EBF16, (SVE, BF16))
-
-AARCH64_FMV_FEATURE("sve-i8mm", SVE_I8MM, (SVE, I8MM))
-
 AARCH64_OPT_EXTENSION("f32mm", F32MM, (SVE), (), (), "f32mm")
 
 AARCH64_FMV_FEATURE("f32mm", SVE_F32MM, (F32MM))
@@ -209,8 +179,6 @@ AARCH64_OPT_EXTENSION("sve2-aes", SVE2_AES, (SVE2, AES), 
(), (), "sveaes")
 
 AARCH64_FMV_FEATURE("sve2-aes", SVE_AES, (SVE2_AES))
 
-AARCH64_FMV_FEATURE("sve2-pmull128", SVE_PMULL128, (SVE2))
-
 AARCH64_OPT_EXTENSION("sve2-bitperm", SVE2_BITPERM, (SVE2), (), (),
  "svebitperm")
 
@@ -230,8 +198,6 @@ AARCH64_OPT_FMV_EXTENSION("memtag", MEMTAG, (), (), (), "")
 
 AARCH64_FMV_FEATURE("memtag2", MEMTAG2, (MEMTAG))
 
-AARCH64_FMV_FEATURE("memtag3", MEMTAG3, (MEMTAG))
-
 AARCH64_OPT_FMV_EXTENSION("sb", SB, (), (), (), "sb")
 
 AARCH64_OPT_FMV_EXTENSION("predres", PREDRES, (), (), (), "")
@@ -240,8 +206,6 @@ AARCH64_OPT_FMV_EXTENSION("ssbs", SSBS, (), (), (), "ssbs")
 
 AARCH64_FMV_FEATURE("ssbs2", SSBS2, (SSBS))
 
-AARCH64_FMV_FEATURE("bti", BTI, ())
-
 AARCH64_OPT_EXTENSION("profile", PROFILE, (), (), (), "")
 
 AARCH64_OPT_EXTENSION("tme", TME, (), (), (), "")
@@ -256,8 +220,6 @@ AARCH64_FMV_FEATURE("ls64_v", LS64_V, ())
 
 AARCH64_FMV_FEATURE("ls64_accdata", LS64_ACCDATA, (LS64))
 
-AARCH64_FMV_FEATURE("wfxt", WFXT, ())
-
 AARCH64_OPT_EXTENSION("sme-f64f64", SME_F64F64, (SME), (), (), "")
 
 AARCH64_FMV_FEATURE("sme-f64f64", SME_F64, (SME_F64F64))

[committed 2/5 v2] aarch64: Fix FMV array iteration bounds

[Andrew Carlotti]

There was an assumption in some places that the aarch64_fmv_feature_data
array contained FEAT_MAX elements.  While this assumption held up till
now, it is safer and more flexible to use the array size directly.

Also fix the lower bound in compare_feature_masks to use ">=0" instead
of ">0", and add a test using the features at index 0 and 1. However,
the test already passed, because the earlier popcount check makes it
impossible to reach the loop if the masks differ in exactly one
location.

gcc/ChangeLog:

* config/aarch64/aarch64.cc (compare_feature_masks):
Use ARRAY_SIZE and >=0 for iteration bounds.
(aarch64_mangle_decl_assembler_name): Use ARRAY_SIZE.

gcc/testsuite/ChangeLog:

* g++.target/aarch64/mv-1.C: New test.


diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
1ea84c8bd7386e399f6ffa3a5e36408cf8831fc6..4f708213551523b4af966ac8521754df5eb6bf3c
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -19700,7 +19700,7 @@ aarch64_parse_fmv_features (const char *str, 
aarch64_feature_flags *isa_flags,
   if (len == 0)
return AARCH_PARSE_MISSING_ARG;
 
-  static const int num_features = ARRAY_SIZE (aarch64_fmv_feature_data);
+  int num_features = ARRAY_SIZE (aarch64_fmv_feature_data);
   int i;
   for (i = 0; i < num_features; i++)
{
@@ -19899,7 +19899,8 @@ compare_feature_masks (aarch64_fmv_feature_mask mask1,
   auto diff_mask = mask1 ^ mask2;
   if (diff_mask == 0ULL)
 return 0;
-  for (int i = FEAT_MAX - 1; i > 0; i--)
+  int num_features = ARRAY_SIZE (aarch64_fmv_feature_data);
+  for (int i = num_features - 1; i >= 0; i--)
 {
   auto bit_mask = aarch64_fmv_feature_data[i].feature_mask;
   if (diff_mask & bit_mask)
@@ -19982,7 +19983,8 @@ aarch64_mangle_decl_assembler_name (tree decl, tree id)
 
   name += "._";
 
-  for (int i = 0; i < FEAT_MAX; i++)
+  int num_features = ARRAY_SIZE (aarch64_fmv_feature_data);
+  for (int i = 0; i < num_features; i++)
{
  if (feature_mask & aarch64_fmv_feature_data[i].feature_mask)
{
diff --git a/gcc/testsuite/g++.target/aarch64/mv-1.C 
b/gcc/testsuite/g++.target/aarch64/mv-1.C
new file mode 100644
index 
..b4b0e5e3fea0ed481de1918d30cd8248bb4f7ab5
--- /dev/null
+++ b/gcc/testsuite/g++.target/aarch64/mv-1.C
@@ -0,0 +1,38 @@
+/* { dg-do compile } */
+/* { dg-require-ifunc "" } */
+/* { dg-options "-O0" } */
+
+__attribute__((target_version("default")))
+int foo ()
+{
+  return 1;
+}
+
+__attribute__((target_version("rng")))
+int foo ()
+{
+  return 1;
+}
+
+__attribute__((target_version("flagm")))
+int foo ()
+{
+  return 1;
+}
+
+__attribute__((target_version("rng+flagm")))
+int foo ()
+{
+  return 1;
+}
+
+int bar()
+{
+  return foo ();
+}
+
+/* Check usage of the first two FMV features, in case of off-by-one errors.  */
+/* { dg-final { scan-assembler-times "\n_Z3foov\.default:\n" 1 } } */
+/* { dg-final { scan-assembler-times "\n_Z3foov\._Mrng:\n" 1 } } */
+/* { dg-final { scan-assembler-times "\n_Z3foov\._MrngMflagm:\n" 1 } } */
+/* { dg-final { scan-assembler-times "\n_Z3foov\._Mflagm:\n" 1 } } */

[committed 1/5 v2] aarch64: Reorder FMV feature priorities

[Andrew Carlotti]

Some higher priority FMV features were dependent subsets of lower
priority features.  Fix this, using the new priorities specified in
https://github.com/ARM-software/acle/pull/279.

gcc/ChangeLog:

* config/aarch64/aarch64-option-extensions.def: Reorder FMV entries.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/cpunative/native_cpu_21.c: Reorder features.
* gcc.target/aarch64/cpunative/native_cpu_22.c: Ditto.


diff --git a/gcc/config/aarch64/aarch64-option-extensions.def 
b/gcc/config/aarch64/aarch64-option-extensions.def
index 
aa3cd99f791c83c5b15291503f3375a7cf2732cd..0078dd092884a94d2a339b5238b8d19747ff9fa1
 100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -99,17 +99,17 @@ AARCH64_OPT_EXTENSION(NAME, IDENT, REQUIRES, EXPLICIT_ON, 
EXPLICIT_OFF, \
 AARCH64_FMV_FEATURE(NAME, IDENT, (IDENT))
 
 
-AARCH64_OPT_EXTENSION("fp", FP, (), (), (), "fp")
-
-AARCH64_OPT_EXTENSION("simd", SIMD, (FP), (), (), "asimd")
-
 AARCH64_OPT_FMV_EXTENSION("rng", RNG, (), (), (), "rng")
 
 AARCH64_OPT_FMV_EXTENSION("flagm", FLAGM, (), (), (), "flagm")
 
 AARCH64_FMV_FEATURE("flagm2", FLAGM2, (FLAGM))
 
-AARCH64_FMV_FEATURE("fp16fml", FP16FML, (F16FML))
+AARCH64_OPT_FMV_EXTENSION("lse", LSE, (), (), (), "atomics")
+
+AARCH64_OPT_FMV_EXTENSION("fp", FP, (), (), (), "fp")
+
+AARCH64_OPT_FMV_EXTENSION("simd", SIMD, (FP), (), (), "asimd")
 
 AARCH64_OPT_FMV_EXTENSION("dotprod", DOTPROD, (SIMD), (), (), "asimddp")
 
@@ -121,12 +121,6 @@ AARCH64_OPT_EXTENSION("rdma", RDMA, (), (SIMD), (), 
"asimdrdm")
 
 AARCH64_FMV_FEATURE("rmd", RDM, (RDMA))
 
-AARCH64_OPT_FMV_EXTENSION("lse", LSE, (), (), (), "atomics")
-
-AARCH64_FMV_FEATURE("fp", FP, (FP))
-
-AARCH64_FMV_FEATURE("simd", SIMD, (SIMD))
-
 AARCH64_OPT_FMV_EXTENSION("crc", CRC, (), (), (), "crc32")
 
 AARCH64_FMV_FEATURE("sha1", SHA1, ())
@@ -160,6 +154,8 @@ AARCH64_FMV_FEATURE("fp16", FP16, (F16))
-march=armv8.4-a+nofp16+fp16 enables F16 but not F16FML.  */
 AARCH64_OPT_EXTENSION("fp16fml", F16FML, (), (F16), (), "asimdfhm")
 
+AARCH64_FMV_FEATURE("fp16fml", FP16FML, (F16FML))
+
 AARCH64_FMV_FEATURE("dit", DIT, ())
 
 AARCH64_FMV_FEATURE("dpb", DPB, ())
diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_21.c 
b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_21.c
index 
920e1d65711cbcb77b07441597180c0159ccabf9..1d90e9ec9d971ae0f085fd832099058488c817b8
 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_21.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_21.c
@@ -7,7 +7,7 @@ int main()
   return 0;
 }
 
-/* { dg-final { scan-assembler {\.arch 
armv8-a\+flagm\+dotprod\+rdma\+lse\+crc\+fp16fml\+rcpc\+i8mm\+bf16\+sve2-aes\+sve2-bitperm\+sve2-sha3\+sve2-sm4\+sb\+ssbs\n}
 } } */
+/* { dg-final { scan-assembler {\.arch 
armv8-a\+flagm\+lse\+dotprod\+rdma\+crc\+fp16fml\+rcpc\+i8mm\+bf16\+sve2-aes\+sve2-bitperm\+sve2-sha3\+sve2-sm4\+sb\+ssbs\n}
 } } */
 
 /* Check that an Armv8-A core doesn't fall apart on extensions without midr
values.  */
diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_22.c 
b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_22.c
index 
416a29b514ab7599a7092e26e3716ec8a50cc895..17050a0b72c98ecfd87ec5f7f522cce4db9efc16
 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_22.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_22.c
@@ -7,7 +7,7 @@ int main()
   return 0;
 }
 
-/* { dg-final { scan-assembler {\.arch 
armv8-a\+flagm\+dotprod\+rdma\+lse\+crc\+fp16fml\+rcpc\+i8mm\+bf16\+sve2-aes\+sve2-bitperm\+sve2-sha3\+sve2-sm4\+sb\+ssbs\+pauth\n}
 } } */
+/* { dg-final { scan-assembler {\.arch 
armv8-a\+flagm\+lse\+dotprod\+rdma\+crc\+fp16fml\+rcpc\+i8mm\+bf16\+sve2-aes\+sve2-bitperm\+sve2-sha3\+sve2-sm4\+sb\+ssbs\+pauth\n}
 } } */
 
 /* Check that an Armv8-A core doesn't fall apart on extensions without midr
values and that it enables optional features.  */

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

[Alex Coplan]

On 10/04/2024 23:48, Ajit Agarwal wrote:
> Hello Alex:
> 
> On 10/04/24 7:52 pm, Alex Coplan wrote:
> > Hi Ajit,
> > 
> > On 10/04/2024 15:31, Ajit Agarwal wrote:
> >> Hello Alex:
> >>
> >> On 10/04/24 1:42 pm, Alex Coplan wrote:
> >>> Hi Ajit,
> >>>
> >>> On 09/04/2024 20:59, Ajit Agarwal wrote:
>  Hello Alex:
> 
>  On 09/04/24 8:39 pm, Alex Coplan wrote:
> > On 09/04/2024 20:01, Ajit Agarwal wrote:
> >> Hello Alex:
> >>
> >> On 09/04/24 7:29 pm, Alex Coplan wrote:
> >>> On 09/04/2024 17:30, Ajit Agarwal wrote:
> 
> 
>  On 05/04/24 10:03 pm, Alex Coplan wrote:
> > On 05/04/2024 13:53, Ajit Agarwal wrote:
> >> Hello Alex/Richard:
> >>
> >> All review comments are incorporated.
> > 
> >> @@ -2890,8 +3018,8 @@ ldp_bb_info::merge_pairs (insn_list_t 
> >> _list,
> >>  // of accesses.  If we find two sets of adjacent accesses, call
> >>  // merge_pairs.
> >>  void
> >> -ldp_bb_info::transform_for_base (int encoded_lfs,
> >> -   access_group )
> >> +pair_fusion_bb_info::transform_for_base (int encoded_lfs,
> >> +   access_group )
> >>  {
> >>const auto lfs = decode_lfs (encoded_lfs);
> >>const unsigned access_size = lfs.size;
> >> @@ -2909,7 +3037,7 @@ ldp_bb_info::transform_for_base (int 
> >> encoded_lfs,
> >>   access.cand_insns,
> >>   lfs.load_p,
> >>   access_size);
> >> -skip_next = access.cand_insns.empty ();
> >> +skip_next = bb_state->cand_insns_empty_p (access.cand_insns);
> >
> > As above, why is this needed?
> 
>  For rs6000 we want to return always true. as load store pair
>  that are to be merged with 8/16 16/32 32/64 is occuring for rs6000.
>  And we want load store pair to 8/16 32/64. Thats why we want
>  to generate always true for rs6000 to skip pairs as above.
> >>>
> >>> Hmm, sorry, I'm not sure I follow.  Are you saying that for rs6000 
> >>> you have
> >>> load/store pair instructions where the two arms of the access are 
> >>> storing
> >>> operands of different sizes?  Or something else?
> >>>
> >>> As it stands the logic is to skip the next iteration only if we
> >>> exhausted all the candidate insns for the current access.  In the case
> >>> that we didn't exhaust all such candidates, then the idea is that when
> >>> access becomes prev_access, we can attempt to use those candidates as
> >>> the "left-hand side" of a pair in the next iteration since we failed 
> >>> to
> >>> use them as the "right-hand side" of a pair in the current iteration.
> >>> I don't see why you wouldn't want that behaviour.  Please can you
> >>> explain?
> >>>
> >>
> >> In merge_pair we get the 2 load candiates one load from 0 offset and
> >> other load is from 16th offset. Then in next iteration we get load
> >> from 16th offset and other load from 32 offset. In next iteration
> >> we get load from 32 offset and other load from 48 offset.
> >>
> >> For example:
> >>
> >> Currently we get the load candiates as follows.
> >>
> >> pairs:
> >>
> >> load from 0th offset.
> >> load from 16th offset.
> >>
> >> next pairs:
> >>
> >> load from 16th offset.
> >> load from 32th offset.
> >>
> >> next pairs:
> >>
> >> load from 32th offset
> >> load from 48th offset.
> >>
> >> Instead in rs6000 we should get:
> >>
> >> pairs:
> >>
> >> load from 0th offset
> >> load from 16th offset.
> >>
> >> next pairs:
> >>
> >> load from 32th offset
> >> load from 48th offset.
> >
> > Hmm, so then I guess my question is: why wouldn't you consider merging
> > the pair with offsets (16,32) for rs6000?  Is it because you have a
> > stricter alignment requirement on the base pair offsets (i.e. they have
> > to be a multiple of 32 when the operand size is 16)?  So the pair
> > offsets have to be a multiple of the entire pair size rather than a
> > single operand size> 
> 
>  We get load pair at a certain point with (0,16) and other program
>  point we get load pair (32, 48).
> 
>  In current implementation it takes offsets loads as (0, 16),
>  (16, 32), (32, 48).
> 
>  But In rs6000 we want  the load pair to be merged at different points
>  as (0,16) and (32, 48). for (0,16) we want to replace load lxvp with
>  0 offset and other load (32, 48) with lxvp with 32 offset.
> 
>  In current case it will merge with lxvp with 0 offset and lxvp with
>  16 offset, then lxvp with 32 offset and lxvp with 48 offset which
>  is incorrect in our case as 

[committed 0/5 v2] aarch64: FMV feature list fixes

[Andrew Carlotti]

This includes the following changes from v1:

1/5: Add missing testcase update. (I misread my test diffs, but Linaro
precommit picked this up as well.)
2/5: Address review comments and add a testcase.
5/5: Remove "memtag", "ssbs" and "ls64" instead of renaming them.

Bootstrapped and regression tested as a series, and committed to master.

I'll remove "memtag", "ssbs" and "ls64" from my documentation patch before
committing that.

[pushed] modula2: add modula-2 language section to languages supported by GCC

[Gaius Mulley]

Pushed to trunk as r14-9915-g0dc39dee836761f1bc993d760f4ed5f3d127897a

This patch introduces a small modula-2 language section to the
Language Standards Supported by GCC node.

gcc/ChangeLog:

* doc/standards.texi (Language Standards Supported by GCC):
Add Modula-2 language section.

(my last email omitted the patch, now included here)


diff --git a/gcc/doc/standards.texi b/gcc/doc/standards.texi
index 06444ee15f7..68bd750a063 100644
--- a/gcc/doc/standards.texi
+++ b/gcc/doc/standards.texi
@@ -332,6 +332,17 @@ GCC supports the D 2.0 programming language.  The D 
language itself is
 currently defined by its reference implementation and supporting language
 specification, described at @uref{https://dlang.org/spec/spec.html}.
 
+@section Modula-2 language
+
+GCC supports the Modula-2 language and is compliant with the PIM2,
+PIM3, PIM4 and ISO dialects.  Also implemented are a complete set of
+free ISO libraries.  It also contains a collection of PIM libraries
+and some Logitech compatible libraries.
+
+For more information on Modula-2 see
+@uref{https://gcc.gnu.org/readings.html}.  The online manual is
+available at @uref{https://gcc.gnu.org/onlinedocs/gm2/index.html}.
+
 @section References for Other Languages
 
 @xref{Top, GNAT Reference Manual, About This Guide, gnat_rm,

[PATCH] libstdc++: Regenerate trunk baseline_symbols.txt files for Linux

[Jakub Jelinek]

Hi!

While the previous patch was regeneration from 13.2 release (with hand
edits for arches I don't have libraries for but which are still well
maintained), thius one is regeneration from the trunk (this time for
hand edits everywhere for the PR114692
https://gcc.gnu.org/pipermail/libstdc++/2024-April/058570.html
patch; plus again hand edits for arches I don't have libraries for).

Ok for trunk after the PR114692 patch is committed?

2024-04-11  Jakub Jelinek  

* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.

--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj   
2024-04-11 15:55:49.974325507 +0200
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
2024-04-11 16:01:28.877662971 +0200
@@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
 FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
 
FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
 
FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
@@ -4533,6 +4534,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
 FUNC:__cxa_bad_cast@@CXXABI_1.3
 FUNC:__cxa_bad_typeid@@CXXABI_1.3
 FUNC:__cxa_begin_catch@@CXXABI_1.3
+FUNC:__cxa_call_terminate@@CXXABI_1.3.15
 FUNC:__cxa_call_unexpected@@CXXABI_1.3
 FUNC:__cxa_current_exception_type@@CXXABI_1.3
 FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
@@ -4576,6 +4578,7 @@ OBJECT:0:CXXABI_1.3.11
 OBJECT:0:CXXABI_1.3.12
 OBJECT:0:CXXABI_1.3.13
 OBJECT:0:CXXABI_1.3.14
+OBJECT:0:CXXABI_1.3.15
 OBJECT:0:CXXABI_1.3.2
 OBJECT:0:CXXABI_1.3.3
 OBJECT:0:CXXABI_1.3.4
@@ -4613,6 +4616,7 @@ OBJECT:0:GLIBCXX_3.4.3
 OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
 OBJECT:0:GLIBCXX_3.4.32
+OBJECT:0:GLIBCXX_3.4.33
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt.jj
2024-04-11 15:55:49.976325479 +0200
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt   
2024-04-11 16:01:00.085059091 +0200
@@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
 FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
 
FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
 
FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
@@ -4533,6 +4534,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.
 FUNC:__cxa_bad_cast@@CXXABI_1.3
 FUNC:__cxa_bad_typeid@@CXXABI_1.3
 FUNC:__cxa_begin_catch@@CXXABI_1.3
+FUNC:__cxa_call_terminate@@CXXABI_1.3.15
 FUNC:__cxa_call_unexpected@@CXXABI_1.3
 FUNC:__cxa_current_exception_type@@CXXABI_1.3
 FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
@@ -4576,6 +4578,7 @@ OBJECT:0:CXXABI_1.3.11
 OBJECT:0:CXXABI_1.3.12
 OBJECT:0:CXXABI_1.3.13
 OBJECT:0:CXXABI_1.3.14
+OBJECT:0:CXXABI_1.3.15
 OBJECT:0:CXXABI_1.3.2
 OBJECT:0:CXXABI_1.3.3
 OBJECT:0:CXXABI_1.3.4
@@ -4613,6 +4616,7 @@ OBJECT:0:GLIBCXX_3.4.3
 OBJECT:0:GLIBCXX_3.4.30
 OBJECT:0:GLIBCXX_3.4.31
 OBJECT:0:GLIBCXX_3.4.32
+OBJECT:0:GLIBCXX_3.4.33
 OBJECT:0:GLIBCXX_3.4.4
 OBJECT:0:GLIBCXX_3.4.5
 OBJECT:0:GLIBCXX_3.4.6
--- libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt.jj 
2024-04-11 15:55:49.977325466 +0200
+++ libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt
2024-04-11 16:01:00.085059091 +0200
@@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw
 FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
 
FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
 

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

[Jakub Jelinek]

On Thu, Apr 11, 2024 at 03:16:02PM +0100, Jonathan Wakely wrote:
> > That symbol should not be in this symver, see
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 and
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html
> 
> Jakub's patch is just adding the symbols from gcc-13.2.0 which should
> be in the baselines for both gcc-13 and trunk.

Yes.

> After that's done I can fix PR114692 and then we can regen the
> baselines for trunk, which will include the
> __cxa_call_terminate@@CXXABI_1.3.15 symbol, but also have
> _ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33 (N.B. 3.4.33
> not 3.4.32).

I've already posted that.

Jakub

[pushed] modula2: add modula-2 language section to languages supported by GCC

[Gaius Mulley]

Pushed to trunk as r14-9915-g0dc39dee836761f1bc993d760f4ed5f3d127897a

This patch introduces a small modula-2 language section to the
Language Standards Supported by GCC node.

gcc/ChangeLog:

* doc/standards.texi (Language Standards Supported by GCC):
Add Modula-2 language section.

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

[Jonathan Wakely]

On Thu, 11 Apr 2024 at 15:13, Jonathan Wakely  wrote:
>
> On Thu, 11 Apr 2024 at 15:12, Andreas Schwab  wrote:
> >
> > On Apr 11 2024, Jakub Jelinek wrote:
> >
> > > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj   
> > > 2023-05-04 09:42:43.277271065 +0200
> > > +++ libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt  
> > > 2024-04-11 15:44:07.113985138 +0200
> > > @@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
> > > +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> > > @@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
> > > +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
> > >  
> > > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
> >
> > That does not fit.
> >
> > diff --git 
> > a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt 
> > b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> > index 975e7e97cbf..0ac915dc01b 100644
> > --- a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> > +++ b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> > @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw@@GLIBCXX_3.4
> >  FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
> >  FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
> >  FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
> > +FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.32
>
> That symbol should not be in this symver, see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 and
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html

Jakub's patch is just adding the symbols from gcc-13.2.0 which should
be in the baselines for both gcc-13 and trunk.

After that's done I can fix PR114692 and then we can regen the
baselines for trunk, which will include the
__cxa_call_terminate@@CXXABI_1.3.15 symbol, but also have
_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.33 (N.B. 3.4.33
not 3.4.32).

[PATCH v2 00/13] Add aarch64-w64-mingw32 target

[Evgeny Karpov]

Wednesday, April 10, 2024 8:40 PM
Richard Sandiford  wrote:

> Thanks for the updates and sorry again for the slow review.
> I've replied to some of the patches in the series but otherwise it looks good 
> to
> me.
> 
> If you agree with the suggested changes then the series is OK for stage 1,
> assuming no objections from those with an interest in the
> x86 cygwin/mingw port.
> 
> Richard

Thank you, Richard, for the review!
v3 addresses all comments on v2.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/thread.html#649261

Regards,
Evgeny

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

[Jonathan Wakely]

On Thu, 11 Apr 2024 at 15:12, Andreas Schwab  wrote:
>
> On Apr 11 2024, Jakub Jelinek wrote:
>
> > --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj 
> >   2023-05-04 09:42:43.277271065 +0200
> > +++ libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt  
> > 2024-04-11 15:44:07.113985138 +0200
> > @@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
> > +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> > @@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
> > +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
> >  
> > FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
>
> That does not fit.
>
> diff --git a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt 
> b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> index 975e7e97cbf..0ac915dc01b 100644
> --- a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> +++ b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
> @@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
>  FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
> +FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.32

That symbol should not be in this symver, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692 and
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

[Andreas Schwab]

On Apr 11 2024, Jakub Jelinek wrote:

> --- libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt.jj   
> 2023-05-04 09:42:43.277271065 +0200
> +++ libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt  
> 2024-04-11 15:44:07.113985138 +0200
> @@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> @@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23

That does not fit.

diff --git a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
index 975e7e97cbf..0ac915dc01b 100644
--- a/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/m68k-linux-gnu/baseline_symbols.txt
@@ -497,6 +497,7 @@ FUNC:_ZNKSt11__timepunctIwE7_M_daysEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE8_M_am_pmEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11__timepunctIwE9_M_monthsEPPKw@@GLIBCXX_3.4
 FUNC:_ZNKSt11logic_error4whatEv@@GLIBCXX_3.4
+FUNC:_ZNKSt12__basic_fileIcE13native_handleEv@@GLIBCXX_3.4.32
 FUNC:_ZNKSt12__basic_fileIcE7is_openEv@@GLIBCXX_3.4
 
FUNC:_ZNKSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
 
FUNC:_ZNKSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEcvbEv@@GLIBCXX_3.4.31
@@ -3214,6 +3215,7 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv@@GLIBCX
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
@@ -3366,6 +3368,7 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_disposeEv@@GLIBCX
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
@@ -4527,6 +4530,7 @@ FUNC:__cxa_allocate_exception@@CXXABI_1.3
 FUNC:__cxa_bad_cast@@CXXABI_1.3
 FUNC:__cxa_bad_typeid@@CXXABI_1.3
 FUNC:__cxa_begin_catch@@CXXABI_1.3
+FUNC:__cxa_call_terminate@@CXXABI_1.3.15
 FUNC:__cxa_call_unexpected@@CXXABI_1.3
 FUNC:__cxa_current_exception_type@@CXXABI_1.3
 FUNC:__cxa_deleted_virtual@@CXXABI_1.3.6
@@ -4570,6 +4574,7 @@ OBJECT:0:CXXABI_1.3.11
 OBJECT:0:CXXABI_1.3.12
 OBJECT:0:CXXABI_1.3.13
 OBJECT:0:CXXABI_1.3.14
+OBJECT:0:CXXABI_1.3.15
 OBJECT:0:CXXABI_1.3.2
 OBJECT:0:CXXABI_1.3.3
 OBJECT:0:CXXABI_1.3.4
-- 
2.44.0

> --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj
> 2023-05-04 09:42:43.279271036 +0200
> +++ 

[PATCH, OpenACC 2.7, v3] Adjust acc_map_data/acc_unmap_data interaction with reference counters

[Chung-Lin Tang]

Hi Thomas,

On 2024/3/15 7:24 PM, Thomas Schwinge wrote:
> Hi Chung-Lin!
> 
> I realized: please add "PR libgomp/92840" to the Git commit log, as your
> changes are directly a continuation of my earlier changes.

Okay, I'll remember to do that.

...
> -  if (n->refcount != REFCOUNT_INFINITY)
> +  if (n->refcount != REFCOUNT_INFINITY
> +   && n->refcount != REFCOUNT_ACC_MAP_DATA)
>   n->refcount--;
>n->dynamic_refcount--;
>  }
>  
> +  /* Mappings created by 'acc_map_data' may only be deleted by
> + 'acc_unmap_data'.  */
> +  if (n->refcount == REFCOUNT_ACC_MAP_DATA
> +  && n->dynamic_refcount == 0)
> +n->dynamic_refcount = 1;
> +
>if (n->refcount == 0)
>  {
>bool copyout = (kind == GOMP_MAP_FROM
> 
> ..., which really should have the same semantics?  No strong opinion on
> which of the two variants you now chose.

My guess is that breaking off the REFCOUNT_ACC_MAP_DATA case separately will
be lighter on any branch predictors (faster performing overall), so I will
stick with my version here.


>>>
>>> It's not clear to me why you need this handling -- instead of just
>>> handling 'REFCOUNT_ACC_MAP_DATA' like 'REFCOUNT_INFINITY' here, that is,
>>> early 'return'?
>>>
>>> Per my understanding, this code is for OpenACC only exercised for
>>> structured data regions, and it seems strange (unnecessary?) to adjust
>>> the 'dynamic_refcount' for these for 'acc_map_data'-mapped data?  Or am I
>>> missing anything?
>>
>> No, that is not true. It goes through almost everything through 
>> gomp_map_vars_existing/_internal.
>> This is what happens when you acc_create/acc_copyin on a mapping created by 
>> acc_map_data.
> 
> But I don't understand what you foresee breaking with the following (on
> top of your v2):
> 
> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> @@ -476,14 +476,14 @@ gomp_free_device_memory (struct gomp_device_descr 
> *devicep, void *devptr)
>  static inline void
>  gomp_increment_refcount (splay_tree_key k, htab_t *refcount_set)
>  {
> -  if (k == NULL || k->refcount == REFCOUNT_INFINITY)
> +  if (k == NULL
> +  || k->refcount == REFCOUNT_INFINITY
> +  || k->refcount == REFCOUNT_ACC_MAP_DATA)
>  return;
>  
>uintptr_t *refcount_ptr = >refcount;
>  
> -  if (k->refcount == REFCOUNT_ACC_MAP_DATA)
> -refcount_ptr = >dynamic_refcount;
> -  else if (REFCOUNT_STRUCTELEM_FIRST_P (k->refcount))
> +  if (REFCOUNT_STRUCTELEM_FIRST_P (k->refcount))
>  refcount_ptr = >structelem_refcount;
...
> Can you please show a test case?

I have re-tested the patch *without* the gomp_increment/decrement_refcount 
changes,
and have these regressions (just to demonstrate what is affected):
+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nested-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  
execution test
+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/nested-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  
execution test
+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr92854-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  
execution test
+FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr92854-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  
execution test
+FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/nested-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  
execution test
+FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/nested-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  
execution test
+FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/pr92854-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  
execution test
+FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/pr92854-1.c 
-DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  
execution test

Now, I have also re-tested your version (aka, just break early and return when 
k->refcount == REFCOUNT_ACC_MAP_DATA)
And for the record, that also works (no regressions).

However, I strongly suggest we use my version here where we adjust the 
dynamic_refcount, simply because: *It is the whole point of this project item 
in OpenACC 2.7*

The 2.7 spec articulated how increment/decrement interacts with 
acc_map_data/acc_unmap_data and this patch was supposed to make libgomp more 
conforming to it implementation-wise.
(otherwise, no point in working on this at all, as there wasn't really anything 
behaviorally wrong about our implementation before)

> I see we already have:
> 
> if ((kinds[i] & 0xff) == GOMP_MAP_TO_PSET
> && tgt->list_count == 0)
>   {
> /* 'declare target'.  */
> assert (n->refcount == REFCOUNT_INFINITY);
> 
> I think I wanted to you to add:
> 
> --- 

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for i386-linux-gnu

[Jonathan Wakely]

On Thu, 11 Apr 2024 at 15:07, Jakub Jelinek wrote:
>
> On Thu, Apr 11, 2024 at 02:59:05PM +0100, Jonathan Wakely wrote:
> > I think we also want the same change for i386.
> >
> > -- >8 --
> >
> > libstdc++-v3/ChangeLog:
> >
> >   * config/abi/post/i386-linux-gnu/baseline_symbols.txt:
> >   Regenerate.
>
> Not sure about that, the file is missing all the 3.4.30, 3.4.31 and other
> 3.4.32 symbols as well.
> It needs to be regenerated.

Oh right, yeah there's more missing.

> I'm not really sure what i386 really is and if we support it at all, given
> that it doesn't support the fundamental locking instructions.

True.

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for i386-linux-gnu

[Jakub Jelinek]

On Thu, Apr 11, 2024 at 02:59:05PM +0100, Jonathan Wakely wrote:
> I think we also want the same change for i386.
> 
> -- >8 --
> 
> libstdc++-v3/ChangeLog:
> 
>   * config/abi/post/i386-linux-gnu/baseline_symbols.txt:
>   Regenerate.

Not sure about that, the file is missing all the 3.4.30, 3.4.31 and other
3.4.32 symbols as well.
It needs to be regenerated.
I'm not really sure what i386 really is and if we support it at all, given
that it doesn't support the fundamental locking instructions.

> --- a/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
> +++ b/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
> @@ -3186,6 +3186,7 @@ 
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv@@GLIBCX
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> @@ -3337,6 +3338,7 @@ 
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_disposeEv@@GLIBCX
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
> -- 
> 2.44.0

Jakub

[PATCH v3 12/12] Add aarch64-w64-mingw32 target to libgcc

[Evgeny Karpov]

From: Zac Walker 
Date: Mon, 12 Feb 2024 15:22:47 +0100
Subject: [PATCH v3 12/12] Add aarch64-w64-mingw32 target to libgcc

Reuse MinGW definitions from i386 for libgcc. Move reused files to
libgcc/config/mingw folder.

libgcc/ChangeLog:

* config.host: Add aarch64-w64-mingw32 target. Adjust targets
after moving MinGW files.
* config/i386/t-gthr-win32: Move to...
* config/mingw/t-gthr-win32: ...here.
* config/i386/t-mingw-pthread: Move to...
* config/mingw/t-mingw-pthread: ...here.
* config/aarch64/t-no-eh: New file. EH is not yet implemented for
the target, and the default definition should be disabled.
---
 libgcc/config.host| 23 +++
 libgcc/config/aarch64/t-no-eh |  2 ++
 libgcc/config/{i386 => mingw}/t-gthr-win32|  0
 libgcc/config/{i386 => mingw}/t-mingw-pthread |  0
 4 files changed, 21 insertions(+), 4 deletions(-)
 create mode 100644 libgcc/config/aarch64/t-no-eh
 rename libgcc/config/{i386 => mingw}/t-gthr-win32 (100%)
 rename libgcc/config/{i386 => mingw}/t-mingw-pthread (100%)

diff --git a/libgcc/config.host b/libgcc/config.host
index e75a7af647f..0f853b7d02b 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -465,6 +465,21 @@ aarch64*-*-vxworks7*)
tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
tmake_file="${tmake_file} t-dfprules"
;;
+aarch64-*-mingw*)
+   case ${target_thread_file} in
+ win32)
+   tmake_thr_file="mingw/t-gthr-win32"
+   ;;
+ posix)
+   tmake_thr_file="mingw/t-mingw-pthread"
+   ;;
+   esac
+   tmake_file="${tmake_file} ${cpu_type}/t-no-eh ${tmake_thr_file}"
+   tmake_file="${tmake_file} t-dfprules"
+   tmake_file="${tmake_file} ${cpu_type}/t-aarch64"
+   tmake_file="${tmake_file} ${cpu_type}/t-lse"
+   tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
+   ;;
 alpha*-*-linux*)
tmake_file="${tmake_file} alpha/t-alpha alpha/t-ieee t-crtfm 
alpha/t-linux"
extra_parts="$extra_parts crtfastmath.o"
@@ -883,10 +898,10 @@ i[34567]86-*-mingw*)
fi
case ${target_thread_file} in
  win32)
-   tmake_thr_file="i386/t-gthr-win32"
+   tmake_thr_file="mingw/t-gthr-win32"
;;
  posix)
-   tmake_thr_file="i386/t-mingw-pthread"
+   tmake_thr_file="mingw/t-mingw-pthread"
;;
  mcf)
tmake_thr_file="i386/t-mingw-mcfgthread"
@@ -910,10 +925,10 @@ i[34567]86-*-mingw*)
 x86_64-*-mingw*)
case ${target_thread_file} in
  win32)
-   tmake_thr_file="i386/t-gthr-win32"
+   tmake_thr_file="mingw/t-gthr-win32"
;;
  posix)
-   tmake_thr_file="i386/t-mingw-pthread"
+   tmake_thr_file="mingw/t-mingw-pthread"
;;
  mcf)
tmake_thr_file="i386/t-mingw-mcfgthread"
diff --git a/libgcc/config/aarch64/t-no-eh b/libgcc/config/aarch64/t-no-eh
new file mode 100644
index 000..1802339a583
--- /dev/null
+++ b/libgcc/config/aarch64/t-no-eh
@@ -0,0 +1,2 @@
+# Not using EH
+LIB2ADDEH =
diff --git a/libgcc/config/i386/t-gthr-win32 b/libgcc/config/mingw/t-gthr-win32
similarity index 100%
rename from libgcc/config/i386/t-gthr-win32
rename to libgcc/config/mingw/t-gthr-win32
diff --git a/libgcc/config/i386/t-mingw-pthread 
b/libgcc/config/mingw/t-mingw-pthread
similarity index 100%
rename from libgcc/config/i386/t-mingw-pthread
rename to libgcc/config/mingw/t-mingw-pthread
-- 
2.25.1

[PATCH v3 11/12] aarch64: Add aarch64-w64-mingw32 target to libatomic

[Evgeny Karpov]

From: Zac Walker 
Date: Fri, 1 Mar 2024 02:23:45 +0100
Subject: [PATCH v3 11/12] aarch64: Add aarch64-w64-mingw32 target to libatomic

libatomic/ChangeLog:

* configure.tgt: Add aarch64-w64-mingw32 target.
---
 libatomic/configure.tgt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index 4237f283fe4..e49fd57ab41 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -44,7 +44,7 @@ case "${target_cpu}" in
   aarch64*)
ARCH=aarch64
case "${target}" in
-   aarch64*-*-linux*)
+   aarch64*-*-linux* | aarch64-*-mingw*)
if test -n "$enable_aarch64_lse"; then
try_ifunc=yes
fi
-- 
2.25.1

Re: Combine patch ping

[Segher Boessenkool]

On Wed, Apr 10, 2024 at 08:32:39PM +0200, Uros Bizjak wrote:
> On Wed, Apr 10, 2024 at 7:56 PM Segher Boessenkool
>  wrote:
> > This is never okay.  You cannot commit a patch without approval, *ever*.

This is the biggest issue, to start with.  It is fundamental.

> > That patch is also obvious -- obviously *wrong*, that is.  There are
> > big assumptions everywhere in the compiler how a CC reg can be used.
> > This violates that, as explained elsewhere.
> 
> Can you please elaborate what is wrong with this concrete patch.

The explanation of the patch is contradictory to how RTL works at all,
so it is just wrong.  It might even do something sane, but I didn't get
that far at all!

Write good email explanations, and a good proposed commit message.
Please.  It is the only one people can judge a patch.  Well, apart
from doing everything myself from first principles, ignoring everything
you said, just looking at the patch itself, but that is a hundred times
more work.  I don't do that.

> The
> part that the patch touches has several wrong assumptions, and the
> fixed "???" comment just emphasizes that. I don't see what is wrong
> with:
> 
> (define_insn "@pushfl2"
>   [(set (match_operand:W 0 "push_operand" "=<")
> (unspec:W [(match_operand 1 "flags_reg_operand")]
>   UNSPEC_PUSHFL))]
>   "GET_MODE_CLASS (GET_MODE (operands[1])) == MODE_CC"
>   "pushf{}"
>   [(set_attr "type" "push")
>(set_attr "mode" "")])

What does it even mean?  What is a flags:CC?  You always always always
need to say what is *in* the flags, if you want to use it as input
(which is what unspec does).  CC is weird like this.  Most targets do
not have distinct physical flags for every condition, only a few
conditions are "alive" at any point in the program!

> it is just a push of the flags reg to the stack. If the push can't be
> described in this way, then it is the middle end at fault, we can't
> just change modes at will.

But that is not what this describes: it operates on the flags register
in some unspecified way, and pushes the result of *that* to the stack.

(Stack pointer modification is not described here btw, should it be?  Is
that magically implemented by the backend some way, via type=push
perhaps?)


Segher

[PATCH v3 10/12] aarch64: Build and add objects for Cygwin and MinGW for AArch64

[Evgeny Karpov]

From: Zac Walker 
Date: Tue, 20 Feb 2024 13:55:51 +0100
Subject: [PATCH v3 10/12] aarch64: Build and add objects for Cygwin and MinGW
 for AArch64

gcc/ChangeLog:

* config.gcc: Build and add objects for Cygwin and MinGW. Add Cygwin
and MinGW options to the target.
---
 gcc/config.gcc | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index d2f92e0fc50..ef7f854735a 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1279,6 +1279,11 @@ aarch64-*-mingw*)
tm_file="${tm_file} mingw/mingw-stdint.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+   extra_options="${extra_options} mingw/cygming.opt mingw/mingw.opt"
+   extra_objs="${extra_objs} winnt.o"
+   c_target_objs="${c_target_objs} msformat-c.o"
+   d_target_objs="${d_target_objs} winnt-d.o"
+   tmake_file="${tmake_file} mingw/t-cygming"
case ${enable_threads} in
  "" | yes | win32)
thread_file='win32'
-- 
2.25.1

[PATCH] libstdc++: Regenerate baseline_symbols.txt files for i386-linux-gnu

[Jonathan Wakely]

I think we also want the same change for i386.

-- >8 --

libstdc++-v3/ChangeLog:

* config/abi/post/i386-linux-gnu/baseline_symbols.txt:
Regenerate.
---
 .../config/abi/post/i386-linux-gnu/baseline_symbols.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt 
b/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
index 259cfdbaaa4..7789f200899 100644
--- a/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
+++ b/libstdc++-v3/config/abi/post/i386-linux-gnu/baseline_symbols.txt
@@ -3186,6 +3186,7 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_disposeEv@@GLIBCX
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
@@ -3337,6 +3338,7 @@ 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_disposeEv@@GLIBCX
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
-- 
2.44.0

[PATCH v3 09/12] Rename "x86 Windows Options" to "Cygwin and MinGW Options"

[Evgeny Karpov]

From: Zac Walker 
Date: Thu, 11 Apr 2024 13:43:23 +0200
Subject: [PATCH v3 09/12] Rename "x86 Windows Options" to "Cygwin and MinGW
 Options"

Rename "x86 Windows Options" to "Cygwin and MinGW Options".
It will be used also for AArch64.

gcc/ChangeLog:

* config/i386/mingw-w64.opt.urls: Rename options' name and
regenerate option URLs.
* config/lynx.opt.urls: Likewise.
* config/mingw/cygming.opt.urls: Likewise.
* config/mingw/mingw.opt.urls: Likewise.
* doc/invoke.texi: Likewise.
---
 gcc/config/i386/mingw-w64.opt.urls |  2 +-
 gcc/config/lynx.opt.urls   |  2 +-
 gcc/config/mingw/cygming.opt.urls  | 18 +-
 gcc/config/mingw/mingw.opt.urls|  2 +-
 gcc/doc/invoke.texi| 10 ++
 5 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/gcc/config/i386/mingw-w64.opt.urls 
b/gcc/config/i386/mingw-w64.opt.urls
index 6bb53ef29b2..5cceba1d1a1 100644
--- a/gcc/config/i386/mingw-w64.opt.urls
+++ b/gcc/config/i386/mingw-w64.opt.urls
@@ -1,5 +1,5 @@
 ; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/mingw-w64.opt 
and generated HTML
 
 municode
-UrlSuffix(gcc/x86-Windows-Options.html#index-municode)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-municode)
 
diff --git a/gcc/config/lynx.opt.urls b/gcc/config/lynx.opt.urls
index 63e7b9c4b33..b547138f7ff 100644
--- a/gcc/config/lynx.opt.urls
+++ b/gcc/config/lynx.opt.urls
@@ -1,5 +1,5 @@
 ; Autogenerated by regenerate-opt-urls.py from gcc/config/lynx.opt and 
generated HTML
 
 mthreads
-UrlSuffix(gcc/x86-Windows-Options.html#index-mthreads-1)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
 
diff --git a/gcc/config/mingw/cygming.opt.urls 
b/gcc/config/mingw/cygming.opt.urls
index 87799befe3c..c624e22e442 100644
--- a/gcc/config/mingw/cygming.opt.urls
+++ b/gcc/config/mingw/cygming.opt.urls
@@ -1,30 +1,30 @@
 ; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/cygming.opt and 
generated HTML
 
 mconsole
-UrlSuffix(gcc/x86-Windows-Options.html#index-mconsole)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mconsole)
 
 mdll
-UrlSuffix(gcc/x86-Windows-Options.html#index-mdll)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mdll)
 
 mnop-fun-dllimport
-UrlSuffix(gcc/x86-Windows-Options.html#index-mnop-fun-dllimport)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mnop-fun-dllimport)
 
 ; skipping UrlSuffix for 'mthreads' due to multiple URLs:
+;   duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1'
 ;   duplicate: 'gcc/x86-Options.html#index-mthreads'
-;   duplicate: 'gcc/x86-Windows-Options.html#index-mthreads-1'
 
 mwin32
-UrlSuffix(gcc/x86-Windows-Options.html#index-mwin32)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwin32)
 
 mwindows
-UrlSuffix(gcc/x86-Windows-Options.html#index-mwindows)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwindows)
 
 mpe-aligned-commons
-UrlSuffix(gcc/x86-Windows-Options.html#index-mpe-aligned-commons)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mpe-aligned-commons)
 
 fset-stack-executable
-UrlSuffix(gcc/x86-Windows-Options.html#index-fno-set-stack-executable)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-fno-set-stack-executable)
 
 fwritable-relocated-rdata
-UrlSuffix(gcc/x86-Windows-Options.html#index-fno-writable-relocated-rdata)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-fno-writable-relocated-rdata)
 
diff --git a/gcc/config/mingw/mingw.opt.urls b/gcc/config/mingw/mingw.opt.urls
index 2cbbaadf310..f8ee5be6a53 100644
--- a/gcc/config/mingw/mingw.opt.urls
+++ b/gcc/config/mingw/mingw.opt.urls
@@ -1,7 +1,7 @@
 ; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/mingw.opt and 
generated HTML
 
 mcrtdll=
-UrlSuffix(gcc/x86-Windows-Options.html#index-mcrtdll)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mcrtdll)
 
 ; skipping UrlSuffix for 'pthread' due to multiple URLs:
 ;   duplicate: 'gcc/Link-Options.html#index-pthread-1'
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 5d5e70c3033..951ab9ae2f8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1499,6 +1499,8 @@ See RS/6000 and PowerPC Options.
 -munroll-only-small-loops -mlam=@var{choice}}
 
 @emph{x86 Windows Options}
+
+@emph{Cygwin and MinGW Options}
 @gccoptlist{-mconsole  -mcrtdll=@var{library}  -mdll
 -mnop-fun-dllimport  -mthread
 -municode  -mwin32  -mwindows  -fno-set-stack-executable}
@@ -21027,6 +21029,7 @@ platform.
 * C6X Options::
 * CRIS Options::
 * C-SKY Options::
+* Cygwin and MinGW Options::
 * Darwin Options::
 * DEC Alpha Options::
 * eBPF Options::
@@ -36272,6 +36275,13 @@ positions 62:57 can be used for metadata.
 @cindex x86 Windows Options
 @cindex Windows Options for x86
 
+@xref{Cygwin and MinGW Options}.
+
+@node Cygwin and MinGW Options
+@subsection Cygwin and MinGW Options
+@cindex Cygwin and MinGW Options
+@cindex Options for Cygwin and MinGW
+
 These additional options are available for Microsoft Windows targets:
 
 

[PATCH v3 08/12] aarch64: Add SEH to machine_function

[Evgeny Karpov]

From: Zac Walker 
Date: Tue, 20 Feb 2024 18:10:08 +0100
Subject: [PATCH v3 08/12] aarch64: Add SEH to machine_function

SEH is not enabled in aarch64-w64-mingw32 target yet. However, it is
needed to be declared in machine_function for reusing winnt.cc.

gcc/ChangeLog:

* config/aarch64/aarch64.h (struct seh_frame_state): Declare SEH
structure in machine_function.
(GTY): Add SEH field.
---
 gcc/config/aarch64/aarch64.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 6d360ca3e33..67736baedc1 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -1045,6 +1045,9 @@ struct GTY (()) aarch64_frame
   bool is_scs_enabled;
 };
 
+/* Private to winnt.cc.  */
+struct seh_frame_state;
+
 #ifdef hash_set_h
 typedef struct GTY (()) machine_function
 {
@@ -1085,6 +1088,9 @@ typedef struct GTY (()) machine_function
  still exists and still fulfils its original purpose. the same register
  can be reused by other code.  */
   rtx_insn *advsimd_zero_insn;
+
+  /* During SEH output, this is non-null.  */
+  struct seh_frame_state * GTY ((skip (""))) seh;
 } machine_function;
 #endif
 #endif
-- 
2.25.1

[PATCH v3 07/12] aarch64: Add Cygwin and MinGW environments for AArch64

[Evgeny Karpov]

From: Zac Walker 
Date: Thu, 11 Apr 2024 13:41:51 +0200
Subject: [PATCH v3 07/12] aarch64: Add Cygwin and MinGW environments for
 AArch64

Define Cygwin and MinGW environment such as types, SEH definitions,
shared libraries, etc.

gcc/ChangeLog:

* config.gcc: Add Cygwin and MinGW difinitions.
* config/aarch64/aarch64-protos.h
(mingw_pe_maybe_record_exported_symbol): Declare functions
which are used in Cygwin and MinGW environment.
(mingw_pe_section_type_flags): Likewise.
(mingw_pe_unique_section): Likewise.
(mingw_pe_encode_section_info): Likewise.
* config/aarch64/cygming.h: New file.
---
 gcc/config.gcc  |   4 +
 gcc/config/aarch64/aarch64-protos.h |   5 +
 gcc/config/aarch64/cygming.h| 172 
 3 files changed, 181 insertions(+)
 create mode 100644 gcc/config/aarch64/cygming.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3bc4982850b..d2f92e0fc50 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1274,7 +1274,11 @@ aarch64*-*-gnu*)
 aarch64-*-mingw*)
tm_file="${tm_file} aarch64/aarch64-abi-ms.h"
tm_file="${tm_file} aarch64/aarch64-coff.h"
+   tm_file="${tm_file} aarch64/cygming.h"
+   tm_file="${tm_file} mingw/mingw32.h"
+   tm_file="${tm_file} mingw/mingw-stdint.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
+   target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
case ${enable_threads} in
  "" | yes | win32)
thread_file='win32'
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 42639e9efcf..1d3f94c813e 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -1110,6 +1110,11 @@ extern void aarch64_output_patchable_area (unsigned int, 
bool);
 
 extern void aarch64_adjust_reg_alloc_order ();
 
+extern void mingw_pe_maybe_record_exported_symbol (tree, const char *, int);
+extern unsigned int mingw_pe_section_type_flags (tree, const char *, int);
+extern void mingw_pe_unique_section (tree, int);
+extern void mingw_pe_encode_section_info (tree, rtx, int);
+
 bool aarch64_optimize_mode_switching (aarch64_mode_entity);
 void aarch64_restore_za (rtx);
 
diff --git a/gcc/config/aarch64/cygming.h b/gcc/config/aarch64/cygming.h
new file mode 100644
index 000..2e7b01feb76
--- /dev/null
+++ b/gcc/config/aarch64/cygming.h
@@ -0,0 +1,172 @@
+/* Operating system specific defines to be used when targeting GCC for
+   hosting on Windows32, using a Unix style C library and tools.
+   Copyright (C) 1995-2024 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#ifndef GCC_AARCH64_CYGMING_H
+#define GCC_AARCH64_CYGMING_H
+
+#undef PREFERRED_DEBUGGING_TYPE
+#define PREFERRED_DEBUGGING_TYPE DINFO_TYPE_NONE
+
+#define FASTCALL_PREFIX '@'
+
+#define print_reg(rtx, code, file) (gcc_unreachable ())
+
+#define SYMBOL_FLAG_DLLIMPORT 0
+#define SYMBOL_FLAG_DLLEXPORT 0
+
+#define SYMBOL_REF_DLLEXPORT_P(X) \
+   ((SYMBOL_REF_FLAGS (X) & SYMBOL_FLAG_DLLEXPORT) != 0)
+
+/* Disable SEH and declare the required SEH-related macros that are
+still needed for compilation.  */
+#undef TARGET_SEH
+#define TARGET_SEH 0
+
+#define SSE_REGNO_P(N) (gcc_unreachable (), 0)
+#define GENERAL_REGNO_P(N) (gcc_unreachable (), 0)
+#define SEH_MAX_FRAME_SIZE (gcc_unreachable (), 0)
+
+#undef TARGET_PECOFF
+#define TARGET_PECOFF 1
+
+#include 
+#ifdef __MINGW32__
+#include 
+#endif
+
+extern void mingw_pe_asm_named_section (const char *, unsigned int, tree);
+extern void mingw_pe_declare_function_type (FILE *file, const char *name,
+   int pub);
+
+#define TARGET_ASM_NAMED_SECTION  mingw_pe_asm_named_section
+
+/* Select attributes for named sections.  */
+#define TARGET_SECTION_TYPE_FLAGS  mingw_pe_section_type_flags
+
+#define TARGET_ASM_UNIQUE_SECTION mingw_pe_unique_section
+#define TARGET_ENCODE_SECTION_INFO  mingw_pe_encode_section_info
+
+/* Declare the type properly for any external libcall.  */
+#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \
+  mingw_pe_declare_function_type (FILE, XSTR (FUN, 0), 1)
+
+#define TARGET_OS_CPP_BUILTINS()   \
+  do   \
+{  \
+  

[PATCH v3 06/12] Exclude i386 functionality from aarch64 build

[Evgeny Karpov]

From: Zac Walker 
Date: Thu, 11 Apr 2024 13:38:59 +0200
Subject: [PATCH v3 06/12] Exclude i386 functionality from aarch64 build

This patch defines TARGET_AARCH64_MS_ABI in config.gcc and uses it to
exclude i386 functionality from aarch64 build and adjust MinGW headers
for AArch64 MS ABI.

gcc/ChangeLog:

* config.gcc: Define TARGET_AARCH64_MS_ABI.
* config/mingw/mingw-stdint.h (INTPTR_TYPE): Use
TARGET_AARCH64_MS_ABI to adjust MinGW headers for
AArch64 MS ABI.
(UINTPTR_TYPE): Likewise.
(defined): Likewise.
* config/mingw/mingw32.h (DEFAULT_ABI): Likewise.
(defined): Likewise.
* config/mingw/winnt.cc (defined): Use TARGET_ARM64_MS_ABI to
exclude ix86_get_callcvt.
(i386_pe_maybe_mangle_decl_assembler_name): Likewise.
(i386_pe_mangle_decl_assembler_name): Likewise.
---
 gcc/config.gcc  | 1 +
 gcc/config/mingw/mingw-stdint.h | 9 +++--
 gcc/config/mingw/mingw32.h  | 4 +++-
 gcc/config/mingw/winnt.cc   | 8 
 4 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 1712441429c..3bc4982850b 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1285,6 +1285,7 @@ aarch64-*-mingw*)
esac
default_use_cxa_atexit=yes
user_headers_inc_next_post="${user_headers_inc_next_post} float.h"
+   tm_defines="${tm_defines} TARGET_AARCH64_MS_ABI=1"
;;
 aarch64*-wrs-vxworks*)
 tm_file="${tm_file} elfos.h aarch64/aarch64-elf.h"
diff --git a/gcc/config/mingw/mingw-stdint.h b/gcc/config/mingw/mingw-stdint.h
index c0feade76e9..debbe829bdf 100644
--- a/gcc/config/mingw/mingw-stdint.h
+++ b/gcc/config/mingw/mingw-stdint.h
@@ -46,5 +46,10 @@ along with GCC; see the file COPYING3.  If not see
 #define UINT_FAST32_TYPE "unsigned int"
 #define UINT_FAST64_TYPE "long long unsigned int"
 
-#define INTPTR_TYPE (TARGET_64BIT ? "long long int" : "int")
-#define UINTPTR_TYPE (TARGET_64BIT ? "long long unsigned int" : "unsigned int")
+#if defined (TARGET_AARCH64_MS_ABI)
+# define INTPTR_TYPE "long long int"
+# define UINTPTR_TYPE "long long unsigned int"
+#else
+# define INTPTR_TYPE (TARGET_64BIT ? "long long int" : "int")
+# define UINTPTR_TYPE (TARGET_64BIT ? "long long unsigned int" : "unsigned 
int")
+#endif
\ No newline at end of file
diff --git a/gcc/config/mingw/mingw32.h b/gcc/config/mingw/mingw32.h
index 58304fc55f6..08f1b5f0696 100644
--- a/gcc/config/mingw/mingw32.h
+++ b/gcc/config/mingw/mingw32.h
@@ -19,7 +19,9 @@ along with GCC; see the file COPYING3.  If not see
 .  */
 
 #undef DEFAULT_ABI
-#define DEFAULT_ABI MS_ABI
+#if !defined (TARGET_AARCH64_MS_ABI)
+# define DEFAULT_ABI MS_ABI
+#endif
 
 /* By default, target has a 80387, uses IEEE compatible arithmetic,
returns float values in the 387 and needs stack probes.
diff --git a/gcc/config/mingw/winnt.cc b/gcc/config/mingw/winnt.cc
index 1ed383155d0..2a4fc03fc56 100644
--- a/gcc/config/mingw/winnt.cc
+++ b/gcc/config/mingw/winnt.cc
@@ -224,6 +224,8 @@ gen_stdcall_or_fastcall_suffix (tree decl, tree id, bool 
fastcall)
   return get_identifier (new_str);
 }
 
+#if !defined (TARGET_AARCH64_MS_ABI)
+
 /* Maybe decorate and get a new identifier for the DECL of a stdcall or
fastcall function. The original identifier is supplied in ID. */
 
@@ -250,6 +252,8 @@ i386_pe_maybe_mangle_decl_assembler_name (tree decl, tree 
id)
   return new_id;
 }
 
+#endif
+
 /* Emit an assembler directive to set symbol for DECL visibility to
the visibility type VIS, which must not be VISIBILITY_DEFAULT.
As for PE there is no hidden support in gas, we just warn for
@@ -266,6 +270,8 @@ i386_pe_assemble_visibility (tree decl, int)
  "in this configuration; ignored");
 }
 
+#if !defined (TARGET_AARCH64_MS_ABI)
+
 /* This is used as a target hook to modify the DECL_ASSEMBLER_NAME
in the language-independent default hook
langhooks,c:lhd_set_decl_assembler_name ()
@@ -278,6 +284,8 @@ i386_pe_mangle_decl_assembler_name (tree decl, tree id)
   return (new_id ? new_id : id);
 }
 
+#endif
+
 /* This hook behaves the same as varasm.cc/assemble_name(), but
generates the name into memory rather than outputting it to
a file stream.  */
-- 
2.25.1

Re: [PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

[Jonathan Wakely]

On Thu, 11 Apr 2024 at 14:52, Jakub Jelinek  wrote:
>
> Hi!
>
> The following patch regenerates the ABI files for 13 branch (I've only changed
> the Linux files which were updated in r13-7289, all but m68k, riscv64 and
> powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited).
> We've added one symbol very early in the 13.2 cycle, but then added 2
> further ones very soon afterwards, quite a long time before 13.2 release
> and haven't regenerated.  The patch applies cleanly to trunk as well.
>
> Ok for trunk/13 branch?

Yes for both, thanks.


>
> 2024-04-11  Jakub Jelinek  
>
> * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
> * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.
> * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
>
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj 
>   2023-05-04 09:42:43.282270993 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
> 2024-04-11 15:36:04.251623423 +0200
> @@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEmm@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEm@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> @@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEmmPKwm@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEmm@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEm@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
> --- libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt.jj  
>   2023-05-04 09:42:43.281271008 +0200
> +++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt 
>   2024-04-11 15:36:00.525674901 +0200
> @@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
> @@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
> +FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
>  
> FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
> --- libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt.jj 
> 2023-05-04 09:42:43.276271079 +0200
> +++ 

[PATCH v3 05/12] Rename section and encoding functions from i386 which will be used in aarch64

[Evgeny Karpov]

From: Zac Walker 
Date: Tue, 20 Feb 2024 17:22:31 +0100
Subject: [PATCH v3 05/12] Rename section and encoding functions from i386
 which will be used in aarch64

gcc/ChangeLog:

* config/i386/cygming.h (SUBTARGET_ENCODE_SECTION_INFO):
Rename functions in mingw folder which will be reused for
aarch64.
(TARGET_ASM_UNIQUE_SECTION): Likewise.
(TARGET_ASM_NAMED_SECTION): Likewise.
(TARGET_SECTION_TYPE_FLAGS): Likewise.
(ASM_DECLARE_COLD_FUNCTION_NAME): Likewise.
(ASM_OUTPUT_EXTERNAL_LIBCALL): Likewise.
* config/i386/i386-protos.h (i386_pe_unique_section):
Rename into ...
(mingw_pe_unique_section): ... this.
(i386_pe_declare_function_type): Rename into ...
(mingw_pe_declare_function_type): ... this.
(i386_pe_encode_section_info): Rename into ...
(mingw_pe_encode_section_info): ... this.
(i386_pe_maybe_record_exported_symbol): Rename into ...
(mingw_pe_maybe_record_exported_symbol): ... this.
(i386_pe_section_type_flags): Rename into ...
(mingw_pe_section_type_flags): ... this.
(i386_pe_asm_named_section): Rename into ...
(mingw_pe_asm_named_section): ... this.
* config/mingw/winnt.cc (i386_pe_encode_section_info):
Rename into ...
(mingw_pe_encode_section_info): ... this.
(i386_pe_unique_section): Rename into ...
(mingw_pe_unique_section): ... this.
(i386_pe_section_type_flags): Rename into ...
(mingw_pe_section_type_flags): ... this.
(i386_pe_asm_named_section): Rename into ...
(mingw_pe_asm_named_section): ... this.
(i386_pe_asm_output_aligned_decl_common): Likewise.
(i386_pe_declare_function_type): Rename into ...
(mingw_pe_declare_function_type): ... this.
(i386_pe_maybe_record_exported_symbol): Rename into ...
(mingw_pe_maybe_record_exported_symbol): ... this.
(i386_pe_start_function): Likewise.
* varasm.cc (switch_to_comdat_section): Likewise.
---
 gcc/config/i386/cygming.h | 18 +-
 gcc/config/i386/i386-protos.h | 12 ++--
 gcc/config/mingw/winnt.cc | 22 +++---
 gcc/varasm.cc |  2 +-
 4 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index 1af5bc380a5..beedf7c398a 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -219,7 +219,7 @@ do {
\
section and we need to set DECL_SECTION_NAME so we do that here.
Note that we can be called twice on the same decl.  */
 
-#define SUBTARGET_ENCODE_SECTION_INFO  i386_pe_encode_section_info
+#define SUBTARGET_ENCODE_SECTION_INFO  mingw_pe_encode_section_info
 
 /* Local and global relocs can be placed always into readonly memory
for PE-COFF targets.  */
@@ -235,7 +235,7 @@ do {
\
 #undef ASM_DECLARE_OBJECT_NAME
 #define ASM_DECLARE_OBJECT_NAME(STREAM, NAME, DECL)\
 do {   \
-  i386_pe_maybe_record_exported_symbol (DECL, NAME, 1);\
+  mingw_pe_maybe_record_exported_symbol (DECL, NAME, 1);   \
   ASM_OUTPUT_LABEL ((STREAM), (NAME)); \
 } while (0)
 
@@ -283,16 +283,16 @@ do {  \
 /* Windows uses explicit import from shared libraries.  */
 #define MULTIPLE_SYMBOL_SPACES 1
 
-#define TARGET_ASM_UNIQUE_SECTION i386_pe_unique_section
+#define TARGET_ASM_UNIQUE_SECTION mingw_pe_unique_section
 #define TARGET_ASM_FUNCTION_RODATA_SECTION default_no_function_rodata_section
 
 #define SUPPORTS_ONE_ONLY 1
 
 /* Switch into a generic section.  */
-#define TARGET_ASM_NAMED_SECTION  i386_pe_asm_named_section
+#define TARGET_ASM_NAMED_SECTION  mingw_pe_asm_named_section
 
 /* Select attributes for named sections.  */
-#define TARGET_SECTION_TYPE_FLAGS  i386_pe_section_type_flags
+#define TARGET_SECTION_TYPE_FLAGS  mingw_pe_section_type_flags
 
 /* Write the extra assembler code needed to declare a function
properly.  */
@@ -307,7 +307,7 @@ do {\
 #define ASM_DECLARE_COLD_FUNCTION_NAME(FILE, NAME, DECL)   \
   do   \
 {  \
-  i386_pe_declare_function_type (FILE, NAME, 0);   \
+  mingw_pe_declare_function_type (FILE, NAME, 0);  \
   i386_pe_seh_cold_init (FILE, NAME);  \
   ASM_OUTPUT_LABEL (FILE, NAME);   \
 }  \
@@ -333,7 +333,7 @@ do {\
 
 /* Declare the type properly for any external libcall.  */
 #define 

[PATCH] libstdc++: Regenerate baseline_symbols.txt files for Linux

[Jakub Jelinek]

Hi!

The following patch regenerates the ABI files for 13 branch (I've only changed
the Linux files which were updated in r13-7289, all but m68k, riscv64 and
powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited).
We've added one symbol very early in the 13.2 cycle, but then added 2
further ones very soon afterwards, quite a long time before 13.2 release
and haven't regenerated.  The patch applies cleanly to trunk as well.

Ok for trunk/13 branch?

2024-04-11  Jakub Jelinek  

* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.

--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt.jj   
2023-05-04 09:42:43.282270993 +0200
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt  
2024-04-11 15:36:04.251623423 +0200
@@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEmm@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEm@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
@@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEmmPKwm@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEmm@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEm@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_m@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
--- libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt.jj
2023-05-04 09:42:43.281271008 +0200
+++ libstdc++-v3/config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt   
2024-04-11 15:36:00.525674901 +0200
@@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_S_compareEjj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC1EPcRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_Alloc_hiderC2EPcOS3_@@GLIBCXX_3.4.23
@@ -3366,6 +3367,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIwSt11ch
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_M_replaceEjjPKwj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE10_S_compareEjj@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_M_capacityEj@@GLIBCXX_3.4.21
+FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE11_S_allocateERS3_j@@GLIBCXX_3.4.32
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwOS3_@@GLIBCXX_3.4.23
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC1EPwRKS3_@@GLIBCXX_3.4.21
 
FUNC:_ZNSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE12_Alloc_hiderC2EPwOS3_@@GLIBCXX_3.4.23
--- libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt.jj 
2023-05-04 09:42:43.276271079 +0200
+++ libstdc++-v3/config/abi/post/i486-linux-gnu/baseline_symbols.txt
2024-04-11 15:36:00.525674901 +0200
@@ -3214,6 +3214,7 @@ FUNC:_ZNSt7__cxx1112basic_stringIcSt11ch
 
FUNC:_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEjjPKcj@@GLIBCXX_3.4.21
 

[PATCH v3 04/12] Reuse MinGW from i386 for AArch64

[Evgeny Karpov]

From: Zac Walker 
Date: Fri, 1 Mar 2024 02:41:50 +0100
Subject: [PATCH v3 04/12] Reuse MinGW from i386 for AArch64

This patch creates a new config/mingw directory to share MinGW
related definitions, and moves there the corresponding existing files
from config/i386.

gcc/ChangeLog:

* config.gcc: Adjust targets after moving MinGW related files
from i386 to mingw folder.
* config/i386/cygming.opt: Move to...
* config/mingw/cygming.opt: ...here.
* config/i386/cygming.opt.urls: Move to...
* config/mingw/cygming.opt.urls: ...here.
* config/i386/cygwin-d.cc: Move to...
* config/mingw/cygwin-d.cc: ...here.
* config/i386/mingw-stdint.h: Move to...
* config/mingw/mingw-stdint.h: ...here.
* config/i386/mingw.opt: Move to...
* config/mingw/mingw.opt: ...here.
* config/i386/mingw.opt.urls: Move to...
* config/mingw/mingw.opt.urls: ...here.
* config/i386/mingw32.h: Move to...
* config/mingw/mingw32.h: ...here.
* config/i386/msformat-c.cc: Move to...
* config/mingw/msformat-c.cc: ...here.
* config/i386/t-cygming: Move to...
* config/mingw/t-cygming: ...here and updated.
* config/i386/winnt-cxx.cc: Move to...
* config/mingw/winnt-cxx.cc: ...here.
* config/i386/winnt-d.cc: Move to...
* config/mingw/winnt-d.cc: ...here.
* config/i386/winnt-stubs.cc: Move to...
* config/mingw/winnt-stubs.cc: ...here.
* config/i386/winnt.cc: Move to...
* config/mingw/winnt.cc: ...here.
---
 gcc/config.gcc  | 22 ++--
 gcc/config/{i386 => mingw}/cygming.opt  |  0
 gcc/config/{i386 => mingw}/cygming.opt.urls |  0
 gcc/config/{i386 => mingw}/cygwin-d.cc  |  0
 gcc/config/{i386 => mingw}/mingw-stdint.h   |  0
 gcc/config/{i386 => mingw}/mingw.opt|  0
 gcc/config/{i386 => mingw}/mingw.opt.urls   |  0
 gcc/config/{i386 => mingw}/mingw32.h|  0
 gcc/config/{i386 => mingw}/msformat-c.cc|  0
 gcc/config/{i386 => mingw}/t-cygming| 23 -
 gcc/config/{i386 => mingw}/winnt-cxx.cc |  0
 gcc/config/{i386 => mingw}/winnt-d.cc   |  0
 gcc/config/{i386 => mingw}/winnt-stubs.cc   |  0
 gcc/config/{i386 => mingw}/winnt.cc |  0
 14 files changed, 24 insertions(+), 21 deletions(-)
 rename gcc/config/{i386 => mingw}/cygming.opt (100%)
 rename gcc/config/{i386 => mingw}/cygming.opt.urls (100%)
 rename gcc/config/{i386 => mingw}/cygwin-d.cc (100%)
 rename gcc/config/{i386 => mingw}/mingw-stdint.h (100%)
 rename gcc/config/{i386 => mingw}/mingw.opt (100%)
 rename gcc/config/{i386 => mingw}/mingw.opt.urls (100%)
 rename gcc/config/{i386 => mingw}/mingw32.h (100%)
 rename gcc/config/{i386 => mingw}/msformat-c.cc (100%)
 rename gcc/config/{i386 => mingw}/t-cygming (73%)
 rename gcc/config/{i386 => mingw}/winnt-cxx.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt-d.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt-stubs.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt.cc (100%)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index dffc041cc18..1712441429c 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2168,9 +2168,9 @@ i[4567]86-wrs-vxworks*|x86_64-wrs-vxworks7*)
 i[34567]86-*-cygwin*)
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h 
i386/cygwin.h i386/cygwin-stdint.h"
xm_file=i386/xm-cygwin.h
-   tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
-   target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
-   extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
+   tmake_file="${tmake_file} mingw/t-cygming t-slibgcc"
+   target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+   extra_options="${extra_options} mingw/cygming.opt i386/cygwin.opt"
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
c_target_objs="${c_target_objs} msformat-c.o"
cxx_target_objs="${cxx_target_objs} winnt-cxx.o msformat-c.o"
@@ -2186,9 +2186,9 @@ x86_64-*-cygwin*)
need_64bit_isa=yes
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h 
i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
xm_file=i386/xm-cygwin.h
-   tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
-   target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
-   extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
+   tmake_file="${tmake_file} mingw/t-cygming t-slibgcc"
+   target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+   extra_options="${extra_options} mingw/cygming.opt i386/cygwin.opt"
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
c_target_objs="${c_target_objs} msformat-c.o"
cxx_target_objs="${cxx_target_objs} winnt-cxx.o msformat-c.o"
@@ -2224,7 +2224,7 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
if test x$enable_threads = xmcf 

[PATCH v3 03/12] aarch64: Add aarch64-w64-mingw32 COFF

[Evgeny Karpov]

From: Zac Walker 
Date: Thu, 11 Apr 2024 14:46:07 +0200
Subject: [PATCH v3 03/12] aarch64: Add aarch64-w64-mingw32 COFF

Define ASM specific for COFF format on AArch64.

gcc/ChangeLog:

* config.gcc: Add COFF format support definitions.
* config/aarch64/aarch64-coff.h: New file.
---
 gcc/config.gcc|  1 +
 gcc/config/aarch64/aarch64-coff.h | 91 +++
 2 files changed, 92 insertions(+)
 create mode 100644 gcc/config/aarch64/aarch64-coff.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 0aeb5641461..dffc041cc18 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1273,6 +1273,7 @@ aarch64*-*-gnu*)
;;
 aarch64-*-mingw*)
tm_file="${tm_file} aarch64/aarch64-abi-ms.h"
+   tm_file="${tm_file} aarch64/aarch64-coff.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
case ${enable_threads} in
  "" | yes | win32)
diff --git a/gcc/config/aarch64/aarch64-coff.h 
b/gcc/config/aarch64/aarch64-coff.h
new file mode 100644
index 000..81fd9954f75
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-coff.h
@@ -0,0 +1,91 @@
+/* Machine description for AArch64 architecture.
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#ifndef GCC_AARCH64_COFF_H
+#define GCC_AARCH64_COFF_H
+
+#ifndef LOCAL_LABEL_PREFIX
+# define LOCAL_LABEL_PREFIX""
+#endif
+
+/* Using long long breaks -ansi and -std=c90, so these will need to be
+   made conditional for an LLP64 ABI.  */
+#undef SIZE_TYPE
+#define SIZE_TYPE  "long long unsigned int"
+
+#undef PTRDIFF_TYPE
+#define PTRDIFF_TYPE   "long long int"
+
+#undef LONG_TYPE_SIZE
+#define LONG_TYPE_SIZE 32
+
+#ifndef ASM_GENERATE_INTERNAL_LABEL
+# define ASM_GENERATE_INTERNAL_LABEL(STRING, PREFIX, NUM)  \
+  sprintf (STRING, "*%s%s%u", LOCAL_LABEL_PREFIX, PREFIX, (unsigned int)(NUM))
+#endif
+
+#define ASM_OUTPUT_ALIGN(STREAM, POWER)\
+  fprintf (STREAM, "\t.align\t%d\n", (int)POWER)
+
+/* Output a common block.  */
+#ifndef ASM_OUTPUT_COMMON
+# define ASM_OUTPUT_COMMON(STREAM, NAME, SIZE, ROUNDED)\
+{  \
+  fprintf (STREAM, "\t.comm\t");   \
+  assemble_name (STREAM, NAME);\
+  asm_fprintf (STREAM, ", %d, %d\n",   \
+  (int)(ROUNDED), (int)(SIZE));\
+}
+#endif
+
+/* Output a local common block.  /bin/as can't do this, so hack a
+   `.space' into the bss segment.  Note that this is *bad* practice,
+   which is guaranteed NOT to work since it doesn't define STATIC
+   COMMON space but merely STATIC BSS space.  */
+#ifndef ASM_OUTPUT_ALIGNED_LOCAL
+# define ASM_OUTPUT_ALIGNED_LOCAL(STREAM, NAME, SIZE, ALIGN)   \
+{  \
+  switch_to_section (bss_section); \
+  ASM_OUTPUT_ALIGN (STREAM, floor_log2 (ALIGN / BITS_PER_UNIT));   \
+  ASM_OUTPUT_LABEL (STREAM, NAME); \
+  fprintf (STREAM, "\t.space\t%d\n", (int)(SIZE)); \
+}
+#endif
+
+#define ASM_OUTPUT_SKIP(STREAM, NBYTES)\
+  fprintf (STREAM, "\t.space\t%d  // skip\n", (int) (NBYTES))
+
+/* Definitions that are not yet supported by binutils for the
+   aarch64-w64-mingw32 target.  */
+#define ASM_OUTPUT_TYPE_DIRECTIVE(STREAM, NAME, TYPE)
+#define ASM_DECLARE_FUNCTION_SIZE(FILE, FNAME, DECL)
+
+#define TEXT_SECTION_ASM_OP"\t.text"
+#define DATA_SECTION_ASM_OP"\t.data"
+#define BSS_SECTION_ASM_OP "\t.bss"
+
+#define CTORS_SECTION_ASM_OP   "\t.section\t.ctors, \"aw\""
+#define DTORS_SECTION_ASM_OP   "\t.section\t.dtors, \"aw\""
+
+#define GLOBAL_ASM_OP "\t.global\t"
+
+#undef SUPPORTS_INIT_PRIORITY
+#define SUPPORTS_INIT_PRIORITY 0
+
+#endif
-- 
2.25.1

[PATCH v3 02/12] aarch64: Mark x18 register as a fixed register for MS ABI

[Evgeny Karpov]

From: Zac Walker 
Date: Thu, 11 Apr 2024 13:30:27 +0200
Subject: [PATCH v3 02/12] aarch64: Mark x18 register as a fixed register for
 MS ABI

Define the MS ABI for aarch64-w64-mingw32.
Adjust FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and
STATIC_CHAIN_REGNUM for AArch64 MS ABI.
The X18 register is reserved on Windows for the TEB.

gcc/ChangeLog:

* config.gcc: Define TARGET_AARCH64_MS_ABI when
AArch64 MS ABI is used.
* config/aarch64/aarch64.h (FIXED_X18): Adjust
FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and
STATIC_CHAIN_REGNUM for AArch64 MS ABI.
(CALL_USED_X18): Likewise.
(FIXED_REGISTERS): Likewise.
* config/aarch64/aarch64-abi-ms.h: New file.
---
 gcc/config.gcc  |  1 +
 gcc/config/aarch64/aarch64-abi-ms.h | 34 +
 gcc/config/aarch64/aarch64.h|  7 --
 3 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 gcc/config/aarch64/aarch64-abi-ms.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 6f97f24af10..0aeb5641461 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1272,6 +1272,7 @@ aarch64*-*-gnu*)
 tm_defines="${tm_defines}  TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
;;
 aarch64-*-mingw*)
+   tm_file="${tm_file} aarch64/aarch64-abi-ms.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
case ${enable_threads} in
  "" | yes | win32)
diff --git a/gcc/config/aarch64/aarch64-abi-ms.h 
b/gcc/config/aarch64/aarch64-abi-ms.h
new file mode 100644
index 000..15dc33d0474
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-abi-ms.h
@@ -0,0 +1,34 @@
+/* Machine description for AArch64 MS ABI.
+   Copyright (C) 2024 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#ifndef GCC_AARCH64_ABI_MS_H
+#define GCC_AARCH64_ABI_MS_H
+
+/* X18 reserved for the TEB on Windows.  */
+
+#undef FIXED_X18
+#define FIXED_X18 1
+
+#undef CALL_USED_X18
+#define CALL_USED_X18 0
+
+#undef  STATIC_CHAIN_REGNUM
+#define STATIC_CHAIN_REGNUM R17_REGNUM
+
+#endif /* GCC_AARCH64_ABI_MS_H.  */
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 45e901cda64..6d360ca3e33 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -536,11 +536,14 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE = 
AARCH64_FL_SM_OFF;
register.  GCC internally uses the poly_int variable aarch64_sve_vg
instead.  */
 
+#define FIXED_X18 0
+#define CALL_USED_X18 1
+
 #define FIXED_REGISTERS\
   {\
 0, 0, 0, 0,   0, 0, 0, 0,  /* R0 - R7 */   \
 0, 0, 0, 0,   0, 0, 0, 0,  /* R8 - R15 */  \
-0, 0, 0, 0,   0, 0, 0, 0,  /* R16 - R23 */ \
+0, 0, FIXED_X18, 0,   0, 0, 0, 0,  /* R16 - R23.  */   \
 0, 0, 0, 0,   0, 1, 0, 1,  /* R24 - R30, SP */ \
 0, 0, 0, 0,   0, 0, 0, 0,   /* V0 - V7 */   \
 0, 0, 0, 0,   0, 0, 0, 0,   /* V8 - V15 */ \
@@ -564,7 +567,7 @@ constexpr auto AARCH64_FL_DEFAULT_ISA_MODE = 
AARCH64_FL_SM_OFF;
   {\
 1, 1, 1, 1,   1, 1, 1, 1,  /* R0 - R7 */   \
 1, 1, 1, 1,   1, 1, 1, 1,  /* R8 - R15 */  \
-1, 1, 1, 0,   0, 0, 0, 0,  /* R16 - R23 */ \
+1, 1, CALL_USED_X18, 0, 0,   0, 0, 0, /* R16 - R23.  */   \
 0, 0, 0, 0,   0, 1, 1, 1,  /* R24 - R30, SP */ \
 1, 1, 1, 1,   1, 1, 1, 1,  /* V0 - V7 */   \
 0, 0, 0, 0,   0, 0, 0, 0,  /* V8 - V15 */  \
-- 
2.25.1

[PATCH v3 01/12] Introduce aarch64-w64-mingw32 target

[Evgeny Karpov]

From: Zac Walker 
Date: Fri, 1 Mar 2024 01:40:53 +0100
Subject: [PATCH v3 01/12] Introduce aarch64-w64-mingw32 target

Add the initial aarch64-w64-mingw32 target for gcc.

This is the first commit in a sequence of patch series to add
new aarch64-w64-mingw32 target.

Coauthors: Zac Walker ,
Mark Harmstone   and
Ron Riddle 

Refactored, prepared, and validated by
Radek Barton  and
Evgeny Karpov 

fixincludes/ChangeLog:

* mkfixinc.sh: Extend for *-mingw32* targets.

gcc/ChangeLog:

* config.gcc: Add aarch64-w64-mingw32 target.
---
 fixincludes/mkfixinc.sh |  3 +--
 gcc/config.gcc  | 13 +
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/fixincludes/mkfixinc.sh b/fixincludes/mkfixinc.sh
index df90720b716..7112f4dcd64 100755
--- a/fixincludes/mkfixinc.sh
+++ b/fixincludes/mkfixinc.sh
@@ -12,8 +12,7 @@ target=fixinc.sh
 # Check for special fix rules for particular targets
 case $machine in
 i?86-*-cygwin* | \
-i?86-*-mingw32* | \
-x86_64-*-mingw32* | \
+*-mingw32* | \
 powerpc-*-eabisim* | \
 powerpc-*-eabi*| \
 powerpc-*-rtems*   | \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5df3c52f8e9..6f97f24af10 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1271,6 +1271,19 @@ aarch64*-*-gnu*)
 tmake_file="${tmake_file} aarch64/t-aarch64"
 tm_defines="${tm_defines}  TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
;;
+aarch64-*-mingw*)
+   tmake_file="${tmake_file} aarch64/t-aarch64"
+   case ${enable_threads} in
+ "" | yes | win32)
+   thread_file='win32'
+   ;;
+ posix)
+   thread_file='posix'
+   ;;
+   esac
+   default_use_cxa_atexit=yes
+   user_headers_inc_next_post="${user_headers_inc_next_post} float.h"
+   ;;
 aarch64*-wrs-vxworks*)
 tm_file="${tm_file} elfos.h aarch64/aarch64-elf.h"
 tm_file="${tm_file} vx-common.h vxworks.h aarch64/aarch64-vxworks.h"
-- 
2.25.1

Re: [PATCH] aarch64: Preserve mem info on change of base for ldp/stp [PR114674]

[Richard Sandiford]

Alex Coplan  writes:
> Hi,
>
> The ldp/stp fusion pass can change the base of an access so that the two
> accesses end up using a common base register.  So far we have been using
> adjust_address_nv to do this, but this means that we don't preserve
> other properties of the mem we're replacing.  It seems better to use
> replace_equiv_address_nv, as this will preserve e.g. the MEM_ALIGN of the
> mem whose address we're changing.
>
> The PR shows that by adjusting the other mem we lose alignment
> information about the original access and therefore end up rejecting an
> otherwise viable pair when --param=aarch64-stp-policy=aligned is passed.
> This patch fixes that by using replace_equiv_address_nv instead.
>
> Notably this is the same approach as taken by
> aarch64_check_consecutive_mems when a change of base is required, so
> this at least makes things more consistent between the ldp fusion pass
> and the peepholes.
>
> Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk when stage 1
> opens for GCC 15?

Yes, thanks.

Richard

>
> Thanks,
> Alex
>
>
> gcc/ChangeLog:
>
>   PR target/114674
>   * config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair):
>   Use replace_equiv_address_nv on a change of base instead of
>   adjust_address_nv on the other access.
>
> gcc/testsuite/ChangeLog:
>
>   PR target/114674
>   * gcc.target/aarch64/pr114674.c: New test.
>
> diff --git a/gcc/config/aarch64/aarch64-ldp-fusion.cc 
> b/gcc/config/aarch64/aarch64-ldp-fusion.cc
> index 365dcf48b22..4258a560c48 100644
> --- a/gcc/config/aarch64/aarch64-ldp-fusion.cc
> +++ b/gcc/config/aarch64/aarch64-ldp-fusion.cc
> @@ -1730,11 +1730,11 @@ ldp_bb_info::fuse_pair (bool load_p,
>   adjust_amt *= -1;
>  
>rtx change_reg = XEXP (change_pat, !load_p);
> -  machine_mode mode_for_mem = GET_MODE (change_mem);
>rtx effective_base = drop_writeback (base_mem);
> -  rtx new_mem = adjust_address_nv (effective_base,
> -mode_for_mem,
> -adjust_amt);
> +  rtx adjusted_addr = plus_constant (Pmode,
> +  XEXP (effective_base, 0),
> +  adjust_amt);
> +  rtx new_mem = replace_equiv_address (change_mem, adjusted_addr);
>rtx new_set = load_p
>   ? gen_rtx_SET (change_reg, new_mem)
>   : gen_rtx_SET (new_mem, change_reg);
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr114674.c 
> b/gcc/testsuite/gcc.target/aarch64/pr114674.c
> new file mode 100644
> index 000..944784fd008
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pr114674.c
> @@ -0,0 +1,17 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 --param=aarch64-stp-policy=aligned" } */
> +typedef struct {
> + unsigned int f1;
> + unsigned int f2;
> +} test_struct;
> +
> +static test_struct ts = {
> + 123, 456
> +};
> +
> +void foo(void)
> +{
> + ts.f2 = 36969 * (ts.f2 & 65535) + (ts.f1 >> 16);
> + ts.f1 = 18000 * (ts.f2 & 65535) + (ts.f2 >> 16);
> +}
> +/* { dg-final { scan-assembler-times "stp" 1 } } */

[PATCH v3 00/12] Add aarch64-w64-mingw32 target

[Evgeny Karpov]

Hello,

Thank you for reviewing v2!
v3 addresses all comments on v2.

v3 Changes:
- Exclude the aarch64_calling_abi declaration from the patch series.
- Refactor x18 adjustment for MS ABI.
- Remove unnecessary headers.
- Add an extra comment to explain empty definitions.
- Use gcc_unreachable for definitions that are needed for compilation, 
but not used by the aarch64-w64-mingw32 target.
- Retain old index entries.
- Rebase from 11th April 2024

Regards,
Evgeny


Zac Walker (12):
  Introduce aarch64-w64-mingw32 target
  aarch64: Mark x18 register as a fixed register for MS ABI
  aarch64: Add aarch64-w64-mingw32 COFF
  Reuse MinGW from i386 for AArch64
  Rename section and encoding functions from i386 which will be used in
aarch64
  Exclude i386 functionality from aarch64 build
  aarch64: Add Cygwin and MinGW environments for AArch64
  aarch64: Add SEH to machine_function
  Rename "x86 Windows Options" to "Cygwin and MinGW Options"
  aarch64: Build and add objects for Cygwin and MinGW for AArch64
  aarch64: Add aarch64-w64-mingw32 target to libatomic
  Add aarch64-w64-mingw32 target to libgcc

 fixincludes/mkfixinc.sh   |   3 +-
 gcc/config.gcc|  47 +++--
 gcc/config/aarch64/aarch64-abi-ms.h   |  34 
 gcc/config/aarch64/aarch64-coff.h |  91 +
 gcc/config/aarch64/aarch64-protos.h   |   5 +
 gcc/config/aarch64/aarch64.h  |  13 +-
 gcc/config/aarch64/cygming.h  | 172 ++
 gcc/config/i386/cygming.h |  18 +-
 gcc/config/i386/cygming.opt.urls  |  30 ---
 gcc/config/i386/i386-protos.h |  12 +-
 gcc/config/i386/mingw-w64.opt.urls|   2 +-
 gcc/config/lynx.opt.urls  |   2 +-
 gcc/config/{i386 => mingw}/cygming.opt|   0
 gcc/config/mingw/cygming.opt.urls |  30 +++
 gcc/config/{i386 => mingw}/cygwin-d.cc|   0
 gcc/config/{i386 => mingw}/mingw-stdint.h |   9 +-
 gcc/config/{i386 => mingw}/mingw.opt  |   0
 gcc/config/{i386 => mingw}/mingw.opt.urls |   2 +-
 gcc/config/{i386 => mingw}/mingw32.h  |   4 +-
 gcc/config/{i386 => mingw}/msformat-c.cc  |   0
 gcc/config/{i386 => mingw}/t-cygming  |  23 ++-
 gcc/config/{i386 => mingw}/winnt-cxx.cc   |   0
 gcc/config/{i386 => mingw}/winnt-d.cc |   0
 gcc/config/{i386 => mingw}/winnt-stubs.cc |   0
 gcc/config/{i386 => mingw}/winnt.cc   |  30 +--
 gcc/doc/invoke.texi   |  10 +
 gcc/varasm.cc |   2 +-
 libatomic/configure.tgt   |   2 +-
 libgcc/config.host|  23 ++-
 libgcc/config/aarch64/t-no-eh |   2 +
 libgcc/config/{i386 => mingw}/t-gthr-win32|   0
 libgcc/config/{i386 => mingw}/t-mingw-pthread |   0
 32 files changed, 473 insertions(+), 93 deletions(-)
 create mode 100644 gcc/config/aarch64/aarch64-abi-ms.h
 create mode 100644 gcc/config/aarch64/aarch64-coff.h
 create mode 100644 gcc/config/aarch64/cygming.h
 delete mode 100644 gcc/config/i386/cygming.opt.urls
 rename gcc/config/{i386 => mingw}/cygming.opt (100%)
 create mode 100644 gcc/config/mingw/cygming.opt.urls
 rename gcc/config/{i386 => mingw}/cygwin-d.cc (100%)
 rename gcc/config/{i386 => mingw}/mingw-stdint.h (86%)
 rename gcc/config/{i386 => mingw}/mingw.opt (100%)
 rename gcc/config/{i386 => mingw}/mingw.opt.urls (86%)
 rename gcc/config/{i386 => mingw}/mingw32.h (99%)
 rename gcc/config/{i386 => mingw}/msformat-c.cc (100%)
 rename gcc/config/{i386 => mingw}/t-cygming (73%)
 rename gcc/config/{i386 => mingw}/winnt-cxx.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt-d.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt-stubs.cc (100%)
 rename gcc/config/{i386 => mingw}/winnt.cc (97%)
 create mode 100644 libgcc/config/aarch64/t-no-eh
 rename libgcc/config/{i386 => mingw}/t-gthr-win32 (100%)
 rename libgcc/config/{i386 => mingw}/t-mingw-pthread (100%)

-- 
2.25.1

[PATCH] libstdc++: Export std::__basic_file::native_handle as GLIBCXX_3.4.33 [PR114692]

[Jonathan Wakely]

I plan to push this shortly, to fix the P1 ABI regression that Jakub
reported earlier today.

This will trigger 'make check-abi' failures for CI testers, because the
baseline_sybols.txt wasn't regenerated for gcc 13.2.0 and so there are
two symbols present in GLIBCXX_3.4.32 which are not in the baseline, and
so get flagged as "incompatible" after this change (because new symbols
are not allowed to be added to GLIBCXX_3.4.32 once it's no longer the
latest). That's a false positive, due to the baselines being out of
date. We'll fix that too.

-- >8 --

I added this new symbol in the wrong version. GLIBCXX_3.4.32 was
already used for the GCC 13.2.0 release, so the new symbol should have
been in a new GLIBCXX_3.4.33 version.

Additionally, the pattern doesn't need to use [cw] because we only ever
use __basic_file, even for std::basic_filebuf.

libstdc++-v3/ChangeLog:

PR libstdc++/114692
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Move new exports for
__basic_file::native_handle to ...
(GLIBCXX_3.4.33): ... here. Adjust to not match wchar_t
specialization, which isn't used.
* testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.33 and update
latest version check.
---
 libstdc++-v3/config/abi/pre/gnu.ver  | 9 +++--
 libstdc++-v3/testsuite/util/testsuite_abi.cc | 3 ++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver 
b/libstdc++-v3/config/abi/pre/gnu.ver
index db20d75b68e..31449b5b87b 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2516,13 +2516,18 @@ GLIBCXX_3.4.31 {
 
 } GLIBCXX_3.4.30;
 
+# GCC 13.2.0
 GLIBCXX_3.4.32 {
 _ZSt21ios_base_library_initv;
 
_ZNSt7__cxx1112basic_stringI[cw]St11char_traitsI[cw]ESaI[cw]EE11_S_allocateERS3_[jmy];
-# std::basic_file<>::native_handle()
-_ZNKSt12__basic_fileI[cw]E13native_handleEv;
 } GLIBCXX_3.4.31;
 
+# GCC 14.1.0
+GLIBCXX_3.4.33 {
+# std::basic_file::native_handle()
+_ZNKSt12__basic_fileIcE13native_handleEv;
+} GLIBCXX_3.4.32;
+
 # Symbols in the support library (libsupc++) have their own tag.
 CXXABI_1.3 {
 
diff --git a/libstdc++-v3/testsuite/util/testsuite_abi.cc 
b/libstdc++-v3/testsuite/util/testsuite_abi.cc
index 4f3846b9cc2..e4bf3cdc8e0 100644
--- a/libstdc++-v3/testsuite/util/testsuite_abi.cc
+++ b/libstdc++-v3/testsuite/util/testsuite_abi.cc
@@ -214,6 +214,7 @@ check_version(symbol& test, bool added)
   known_versions.push_back("GLIBCXX_3.4.30");
   known_versions.push_back("GLIBCXX_3.4.31");
   known_versions.push_back("GLIBCXX_3.4.32");
+  known_versions.push_back("GLIBCXX_3.4.33");
   known_versions.push_back("GLIBCXX_LDBL_3.4.31");
   known_versions.push_back("GLIBCXX_IEEE128_3.4.29");
   known_versions.push_back("GLIBCXX_IEEE128_3.4.30");
@@ -253,7 +254,7 @@ check_version(symbol& test, bool added)
test.version_status = symbol::incompatible;
 
   // Check that added symbols are added in the latest pre-release version.
-  bool latestp = (test.version_name == "GLIBCXX_3.4.32"
+  bool latestp = (test.version_name == "GLIBCXX_3.4.33"
 || test.version_name == "CXXABI_1.3.15"
 || test.version_name == "CXXABI_FLOAT128"
 || test.version_name == "CXXABI_TM_1");
-- 
2.44.0

Re: [PATCH v8 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

[Qing Zhao]

Sid and Richard,

The C FE changes in this patch has been approved by Joseph.

Could you please review the Middle-end change?

thanks.

Qing

> On Apr 10, 2024, at 14:36, Joseph Myers  wrote:
> 
> On Fri, 29 Mar 2024, Qing Zhao wrote:
> 
>> +/* For a SUBDATUM field of a structure or union DATUM, generate a REF to
>> +   the object that represents its counted_by per the attribute counted_by
>> +   attached to this field if it's a flexible array member field, otherwise
>> +   return NULL_TREE.
>> +   set COUNTED_BY_TYPE to the TYPE of the counted_by field.
> 
> Use an uppercase letter at the start of a sentence, "Set".
> 
>> +static tree
>> +build_counted_by_ref (tree datum, tree subdatum, tree *counted_by_type)
>> +{
>> +  tree type = TREE_TYPE (datum);
>> +  if (!(c_flexible_array_member_type_p (TREE_TYPE (subdatum
>> +return NULL_TREE;
> 
> There are redundant parentheses here around the call to 
> c_flexible_array_member_type_p.
> 
> The C front-end changes in this patch are OK for GCC 15 (after GCC 14 has 
> branched, and once a version of patch 1 has also been approved) with those 
> fixes.
> 
> -- 
> Joseph S. Myers
> josmy...@redhat.com
> 

Re: [PATCH v8 5/5] Add the 6th argument to .ACCESS_WITH_SIZE

[Qing Zhao]

Sid,

Thanks a lot for your review.

Richard,

Could you please comment on this patch? Is the middle-end part Okay for stage 1?

Thanks.

Qing

On Apr 10, 2024, at 17:48, Siddhesh Poyarekar  wrote:

On 2024-03-29 12:07, Qing Zhao wrote:
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
source code.
gcc/c/ChangeLog:
* c-typeck.cc (build_access_with_size_for_counted_by): Add the 6th
argument to .ACCESS_WITH_SIZE.
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): Use the type
of the 6th argument for the type of the element.
gcc/testsuite/ChangeLog:
* gcc.dg/flex-array-counted-by-6.c: New test.

This version looks fine to me for stage 1, but I'm not a maintainer so you'll 
need an ack from one to commit.

Thanks,
Sid

---
 gcc/c/c-typeck.cc | 11 +++--
 gcc/internal-fn.cc|  2 +
 .../gcc.dg/flex-array-counted-by-6.c  | 46 +++
 gcc/tree-object-size.cc   | 16 ---
 4 files changed, 66 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-6.c
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index f7b0e08459b0..05948f76039e 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -2608,7 +2608,8 @@ build_counted_by_ref (tree datum, tree subdatum, tree 
*counted_by_type)
  to:
 -   (*.ACCESS_WITH_SIZE (REF, COUNTED_BY_REF, 1, (TYPE_OF_SIZE)0, -1))
+   (*.ACCESS_WITH_SIZE (REF, COUNTED_BY_REF, 1, (TYPE_OF_SIZE)0, -1,
+ (TYPE_OF_ARRAY *)0))
  NOTE: The return type of this function is the POINTER type pointing
to the original flexible array type.
@@ -2620,6 +2621,9 @@ build_counted_by_ref (tree datum, tree subdatum, tree 
*counted_by_type)
The 4th argument of the call is a constant 0 with the TYPE of the
object pointed by COUNTED_BY_REF.
 +   The 6th argument of the call is a constant 0 with the pointer TYPE
+   to the original flexible array type.
+
   */
 static tree
 build_access_with_size_for_counted_by (location_t loc, tree ref,
@@ -2632,12 +2636,13 @@ build_access_with_size_for_counted_by (location_t loc, 
tree ref,
 tree call
 = build_call_expr_internal_loc (loc, IFN_ACCESS_WITH_SIZE,
- result_type, 5,
+ result_type, 6,
  array_to_pointer_conversion (loc, ref),
  counted_by_ref,
  build_int_cst (integer_type_node, 1),
  build_int_cst (counted_by_type, 0),
- build_int_cst (integer_type_node, -1));
+ build_int_cst (integer_type_node, -1),
+ build_int_cst (result_type, 0));
   /* Wrap the call with an INDIRECT_REF with the flexible array type.  */
   call = build1 (INDIRECT_REF, TREE_TYPE (ref), call);
   SET_EXPR_LOCATION (call, loc);
diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
index e744080ee670..34e4a4aea534 100644
--- a/gcc/internal-fn.cc
+++ b/gcc/internal-fn.cc
@@ -3411,6 +3411,8 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
  1: read_only
  2: write_only
  3: read_write
+   6th argument: A constant 0 with the pointer TYPE to the original flexible
+ array type.
  Both the return type and the type of the first argument of this
function have been converted from the incomplete array type to
diff --git a/gcc/testsuite/gcc.dg/flex-array-counted-by-6.c 
b/gcc/testsuite/gcc.dg/flex-array-counted-by-6.c
new file mode 100644
index ..65fa01443d95
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/flex-array-counted-by-6.c
@@ -0,0 +1,46 @@
+/* Test the attribute counted_by and its usage in
+ * __builtin_dynamic_object_size: when the type of the flexible array member
+ * is casting to another type.  */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include "builtin-object-size-common.h"
+
+typedef unsigned short u16;
+
+struct info {
+   u16 data_len;
+   char data[] __attribute__((counted_by(data_len)));
+};
+
+struct foo {
+   int a;
+   int b;
+};
+
+static __attribute__((__noinline__))
+struct info *setup ()
+{
+ struct info *p;
+ size_t bytes = 3 * sizeof(struct foo);
+
+ p = (struct info *)malloc (sizeof (struct info) + bytes);
+ p->data_len = bytes;
+
+ return p;
+}
+
+static void
+__attribute__((__noinline__)) report (struct info *p)
+{
+ struct foo *bar = (struct foo *)p->data;
+ EXPECT(__builtin_dynamic_object_size((char *)(bar + 1), 1), 16);
+ EXPECT(__builtin_dynamic_object_size((char *)(bar + 2), 1), 8);
+}
+
+int main(int argc, char *argv[])
+{
+ struct info *p = setup();
+ report(p);
+ return 0;
+}
diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index 8de264d1dee2..4c1fa9b555fa 100644
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -762,9 +762,11 @@ addr_object_size (struct object_size_info *osi, const_tree 
ptr,
  1: the number of the elements of the object type;
   

Re: [PATCH v8 4/5] Use the .ACCESS_WITH_SIZE in bound sanitizer.

[Qing Zhao]

Sid,

Thanks a lot for the review.


> On Apr 10, 2024, at 17:46, Siddhesh Poyarekar  wrote:
> 
> On 2024-03-29 12:07, Qing Zhao wrote:
>> gcc/c-family/ChangeLog:
>>  * c-ubsan.cc (get_bound_from_access_with_size): New function.
>>  (ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
>> gcc/testsuite/ChangeLog:
>>  * gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
>>  * gcc.dg/ubsan/flex-array-counted-by-bounds-3.c: New test.
>>  * gcc.dg/ubsan/flex-array-counted-by-bounds-4.c: New test.
>>  * gcc.dg/ubsan/flex-array-counted-by-bounds.c: New test.
>> ---
> 
> This version looks fine to me for stage 1, but I'm not a maintainer so you'll 
> need an ack from one to commit.

This patch is purely C FE changes. Joseph already approved it.

thanks.

Qing
> 
> Thanks,
> Sid
> 
>>  gcc/c-family/c-ubsan.cc   | 42 +
>>  .../ubsan/flex-array-counted-by-bounds-2.c| 45 ++
>>  .../ubsan/flex-array-counted-by-bounds-3.c| 34 ++
>>  .../ubsan/flex-array-counted-by-bounds-4.c| 34 ++
>>  .../ubsan/flex-array-counted-by-bounds.c  | 46 +++
>>  5 files changed, 201 insertions(+)
>>  create mode 100644 
>> gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-2.c
>>  create mode 100644 
>> gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-3.c
>>  create mode 100644 
>> gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-4.c
>>  create mode 100644 gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds.c
>> diff --git a/gcc/c-family/c-ubsan.cc b/gcc/c-family/c-ubsan.cc
>> index 940982819ddf..7cd3c6aa5b88 100644
>> --- a/gcc/c-family/c-ubsan.cc
>> +++ b/gcc/c-family/c-ubsan.cc
>> @@ -376,6 +376,40 @@ ubsan_instrument_return (location_t loc)
>>return build_call_expr_loc (loc, t, 1, build_fold_addr_expr_loc (loc, 
>> data));
>>  }
>>  +/* Get the tree that represented the number of counted_by, i.e, the maximum
>> +   number of the elements of the object that the call to .ACCESS_WITH_SIZE
>> +   points to, this number will be the bound of the corresponding array.  */
>> +static tree
>> +get_bound_from_access_with_size (tree call)
>> +{
>> +  if (!is_access_with_size_p (call))
>> +return NULL_TREE;
>> +
>> +  tree ref_to_size = CALL_EXPR_ARG (call, 1);
>> +  unsigned int class_of_size = TREE_INT_CST_LOW (CALL_EXPR_ARG (call, 2));
>> +  tree type = TREE_TYPE (CALL_EXPR_ARG (call, 3));
>> +  tree size = fold_build2 (MEM_REF, type, unshare_expr (ref_to_size),
>> +   build_int_cst (ptr_type_node, 0));
>> +  /* If size is negative value, treat it as zero.  */
>> +  if (!TYPE_UNSIGNED (type))
>> +  {
>> +tree cond = fold_build2 (LT_EXPR, boolean_type_node,
>> + unshare_expr (size), build_zero_cst (type));
>> +size = fold_build3 (COND_EXPR, type, cond,
>> +build_zero_cst (type), size);
>> +  }
>> +
>> +  /* Only when class_of_size is 1, i.e, the number of the elements of
>> + the object type, return the size.  */
>> +  if (class_of_size != 1)
>> +return NULL_TREE;
>> +  else
>> +size = fold_convert (sizetype, size);
>> +
>> +  return size;
>> +}
>> +
>> +
>>  /* Instrument array bounds for ARRAY_REFs.  We create special builtin,
>> that gets expanded in the sanopt pass, and make an array dimension
>> of it.  ARRAY is the array, *INDEX is an index to the array.
>> @@ -401,6 +435,14 @@ ubsan_instrument_bounds (location_t loc, tree array, 
>> tree *index,
>>&& COMPLETE_TYPE_P (type)
>>&& integer_zerop (TYPE_SIZE (type)))
>>  bound = build_int_cst (TREE_TYPE (TYPE_MIN_VALUE (domain)), -1);
>> +  else if (INDIRECT_REF_P (array)
>> +   && is_access_with_size_p ((TREE_OPERAND (array, 0
>> +{
>> +  bound = get_bound_from_access_with_size ((TREE_OPERAND (array, 0)));
>> +  bound = fold_build2 (MINUS_EXPR, TREE_TYPE (bound),
>> +   bound,
>> +   build_int_cst (TREE_TYPE (bound), 1));
>> +}
>>else
>>  return NULL_TREE;
>>  }
>> diff --git a/gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-2.c 
>> b/gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-2.c
>> new file mode 100644
>> index ..b503320628d2
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/ubsan/flex-array-counted-by-bounds-2.c
>> @@ -0,0 +1,45 @@
>> +/* Test the attribute counted_by and its usage in
>> +   bounds sanitizer combined with VLA.  */
>> +/* { dg-do run } */
>> +/* { dg-options "-fsanitize=bounds" } */
>> +/* { dg-output "index 11 out of bounds for type 'int 
>> \\\[\\\*\\\]\\\[\\\*\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
>> +/* { dg-output "\[^\n\r]*index 20 out of bounds for type 'int 
>> \\\[\\\*\\\]\\\[\\\*\\\]\\\[\\\*\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
>> +/* { dg-output "\[^\n\r]*index 11 out of bounds for type 'int 
>> \\\[\\\*\\\]\\\[\\\*\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
>> +/* { dg-output 

Re: [PATCH v8 3/5] Use the .ACCESS_WITH_SIZE in builtin object size.

[Qing Zhao]

Sid,

Thanks a lot for your review!


> On Apr 10, 2024, at 17:45, Siddhesh Poyarekar  wrote:
> 
> On 2024-03-29 12:07, Qing Zhao wrote:
>> gcc/ChangeLog:
>>  * tree-object-size.cc (access_with_size_object_size): New function.
>>  (call_object_size): Call the new function.
>> gcc/testsuite/ChangeLog:
>>  * gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
>>  * gcc.dg/flex-array-counted-by-3.c: New test.
>>  * gcc.dg/flex-array-counted-by-4.c: New test.
>>  * gcc.dg/flex-array-counted-by-5.c: New test.
> 
> This version looks fine to me for stage 1, but I'm not a maintainer so you'll 
> need an ack from one to commit.

Richard, 

Could you please comment on this patch? Is this one okay for stage 1?

Thanks

Qing


> 
> Thanks,
> Sid
> 
>> ---
>>  .../gcc.dg/builtin-object-size-common.h   |  11 ++
>>  .../gcc.dg/flex-array-counted-by-3.c  |  63 +++
>>  .../gcc.dg/flex-array-counted-by-4.c  | 178 ++
>>  .../gcc.dg/flex-array-counted-by-5.c  |  48 +
>>  gcc/tree-object-size.cc   |  60 ++
>>  5 files changed, 360 insertions(+)
>>  create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-3.c
>>  create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-4.c
>>  create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-5.c
>> diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-common.h 
>> b/gcc/testsuite/gcc.dg/builtin-object-size-common.h
>> index 66ff7cdd953a..b677067c6e6b 100644
>> --- a/gcc/testsuite/gcc.dg/builtin-object-size-common.h
>> +++ b/gcc/testsuite/gcc.dg/builtin-object-size-common.h
>> @@ -30,3 +30,14 @@ unsigned nfails = 0;
>>__builtin_abort (); \
>>  return 0;   
>>   \
>>} while (0)
>> +
>> +#define EXPECT(p, _v) do {\
>> +  size_t v = _v;  \
>> +  if (p == v)   
>>   \
>> +__builtin_printf ("ok:  %s == %zd\n", #p, p); \
>> +  else  
>>   \
>> +{   
>>   \
>> +  __builtin_printf ("WAT: %s == %zd (expected %zd)\n", #p, p, v);   
>>   \
>> +  FAIL ();  
>>   \
>> +}   
>>   \
>> +} while (0);
>> diff --git a/gcc/testsuite/gcc.dg/flex-array-counted-by-3.c 
>> b/gcc/testsuite/gcc.dg/flex-array-counted-by-3.c
>> new file mode 100644
>> index ..78f50230e891
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/flex-array-counted-by-3.c
>> @@ -0,0 +1,63 @@
>> +/* Test the attribute counted_by and its usage in
>> + * __builtin_dynamic_object_size.  */
>> +/* { dg-do run } */
>> +/* { dg-options "-O2" } */
>> +
>> +#include "builtin-object-size-common.h"
>> +
>> +struct flex {
>> +  int b;
>> +  int c[];
>> +} *array_flex;
>> +
>> +struct annotated {
>> +  int b;
>> +  int c[] __attribute__ ((counted_by (b)));
>> +} *array_annotated;
>> +
>> +struct nested_annotated {
>> +  struct {
>> +union {
>> +  int b;
>> +  float f;  
>> +};
>> +int n;
>> +  };
>> +  int c[] __attribute__ ((counted_by (b)));
>> +} *array_nested_annotated;
>> +
>> +void __attribute__((__noinline__)) setup (int normal_count, int attr_count)
>> +{
>> +  array_flex
>> += (struct flex *)malloc (sizeof (struct flex)
>> + + normal_count *  sizeof (int));
>> +  array_flex->b = normal_count;
>> +
>> +  array_annotated
>> += (struct annotated *)malloc (sizeof (struct annotated)
>> +  + attr_count *  sizeof (int));
>> +  array_annotated->b = attr_count;
>> +
>> +  array_nested_annotated
>> += (struct nested_annotated *)malloc (sizeof (struct nested_annotated)
>> + + attr_count *  sizeof (int));
>> +  array_nested_annotated->b = attr_count;
>> +
>> +  return;
>> +}
>> +
>> +void __attribute__((__noinline__)) test ()
>> +{
>> +EXPECT(__builtin_dynamic_object_size(array_flex->c, 1), -1);
>> +EXPECT(__builtin_dynamic_object_size(array_annotated->c, 1),
>> +   array_annotated->b * sizeof (int));
>> +EXPECT(__builtin_dynamic_object_size(array_nested_annotated->c, 1),
>> +   array_nested_annotated->b * sizeof (int));
>> +}
>> +
>> +int main(int argc, char *argv[])
>> +{
>> +  setup (10,10);
>> +  test ();
>> +  DONE ();
>> +}
>> diff --git a/gcc/testsuite/gcc.dg/flex-array-counted-by-4.c 
>> b/gcc/testsuite/gcc.dg/flex-array-counted-by-4.c
>> new file mode 100644
>> index ..20103d58ef51
>> --- /dev/null
>> +++ 

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Qing Zhao]

> On Apr 10, 2024, at 17:56, Joseph Myers  wrote:
> 
> On Wed, 10 Apr 2024, Qing Zhao wrote:
> 
>> Okay, the above is very clear, thanks a lot for the explanation.
>> So, basically, for “counted-by” attribute:
>> **The following is good:
>> struct f { 
>>  int b;
>>  int c;
>>  int a[]  __attribute__ ((counted_by (b))) };
>> struct f {
>>  int b;
>>  int c;
>>  int a[] __attribute__ ((counted_by (b))) };
>> 
>> **The following should error:
>> 
>> struct f { 
>>  int b;
>>  int c;
>>  int a[]  __attribute__ ((counted_by (b))) };
>> struct f {
>>  int b;
>>  int c;
>>  int a[] __attribute__ ((counted_by (c))) };  /* error here */
>> 
>> For the same tag in different scopes case:
>> 
>> struct f { 
>>  int b;
>>  int c;
>>  int a[]  __attribute__ ((counted_by (b))) }  y0;
>> 
>> void test1(void) 
>> {   
>> struct f {
>>  int b;
>>  int c;
>>  int a[] __attribute__ ((counted_by (c))) } x;
>> 
>>  y0 = x;  /* will report incompatible type error here */
>> }
>> 
>> Are the above complete?
> 
> Yes, that looks like what should be tested (with the addition of the case 
> of same tag, different scopes, same counted_by so compatible).

Okay, thanks for the help.

Qing
> 
> -- 
> Joseph S. Myers
> josmy...@redhat.com

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

[Qing Zhao]

> On Apr 11, 2024, at 02:02, Martin Uecker  wrote:
> 
> Am Mittwoch, dem 10.04.2024 um 19:35 + schrieb Qing Zhao:
>> 
>>> On Apr 10, 2024, at 15:05, Martin Uecker  wrote:
>>> 
>>> Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker:
 Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
> On Fri, 29 Mar 2024, Qing Zhao wrote:
> 
>> +  /* Issue error when there is a counted_by attribute with a different
>> + field as the argument for the same flexible array member field.  */
> 
> There's another case of this to consider, though I'm not sure where best 
> to check for it (Martin might have suggestions) - of course this case 
> will 
> need testcases as well.
> 
> Suppose, as allowed in C23, a structure is defined twice in the same 
> scope, but the two definitions of the structure use inconsistent 
> counted_by attributes.  I'd say that, when the declarations are in the 
> same scope (thus required to be consistent), it should be an error for 
> the 
> two definitions of what is meant to be the same structure to use 
> incompatible counted_by attributes (even though the member declarations 
> are otherwise the same).
 
 I think the right place could be comp_types_attributes in
 attributes.cc.  It may be sufficient to set the
 affects_type_identify flag.
 
 This should then give a redefinition error as it should do for
 "packed".
>>> 
>>> Thinking about this a bit more, this will not work here, because
>>> the counted_by attribute is not applied to the struct type but
>>> one of the members.
>>> 
>>> So probably there should be a check added directly
>>> to tagged_types_tu_compatible_p
>> 
>> 
>> There are two cases we will check:
>> 
>>  A. Both definitions are in the same scope;
>>  Then if the 2nd definition has a counted-by attribute different from 
>> the 1st definition, the 2nd definition will be given a redefinition error; 
>> 
>>  B. These two definitions are in different scope;
>>  When these two definitions are used in a way need to be compatible, an 
>> incompatible error need to be issued at that
>> Point;
>> 
>> 
>> My question is, Will the routine “tagged_types_tu_compatible_p” can handle 
>> both A and B?
> 
> Yes, changing this function should address both cases if I am
> not missing something.
> 
Thanks for the help.
Will study this routine in more details and update the patch.

Qing
> Martin
> 
>> 
>> Thanks.
>> 
>> Qing
>>> 
>>> Martin
>>> 
 
> 
> In C23 structures defined with the same tag in different scopes are 
> compatible given requirements including compatible types for 
> corresponding 
> elements.  It would seem most appropriate to me for such structures with 
> incompatible counted_by attributes to be considered *not* compatible 
> types 
> (but it would be valid to define structures with the same tag, different 
> scopes, and elements the same except for counted_by - just not to use 
> them 
> in any way requiring them to be compatible).
 
 Another option might be to warn about the case when those types
 are then used together in a way where they are required to
 be compatible.  Then comp_types_attributes would have to return 2.
 
 
 Martin
 
> 
>> +The @code{counted_by} attribute may be attached to the C99 flexible 
>> array
>> +member of a structure.  It indicates that the number of the elements of 
>> the
>> +array is given by the field "@var{count}" in the same structure as the
> 
> As noted previously, the "" quotes should be removed there (or replaced 
> by 
> ``'' quotes).
> 
 
>>> 
>> 
> 

[PATCH] aarch64: Preserve mem info on change of base for ldp/stp [PR114674]

[Alex Coplan]

Hi,

The ldp/stp fusion pass can change the base of an access so that the two
accesses end up using a common base register.  So far we have been using
adjust_address_nv to do this, but this means that we don't preserve
other properties of the mem we're replacing.  It seems better to use
replace_equiv_address_nv, as this will preserve e.g. the MEM_ALIGN of the
mem whose address we're changing.

The PR shows that by adjusting the other mem we lose alignment
information about the original access and therefore end up rejecting an
otherwise viable pair when --param=aarch64-stp-policy=aligned is passed.
This patch fixes that by using replace_equiv_address_nv instead.

Notably this is the same approach as taken by
aarch64_check_consecutive_mems when a change of base is required, so
this at least makes things more consistent between the ldp fusion pass
and the peepholes.

Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk when stage 1
opens for GCC 15?

Thanks,
Alex


gcc/ChangeLog:

PR target/114674
* config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair):
Use replace_equiv_address_nv on a change of base instead of
adjust_address_nv on the other access.

gcc/testsuite/ChangeLog:

PR target/114674
* gcc.target/aarch64/pr114674.c: New test.
diff --git a/gcc/config/aarch64/aarch64-ldp-fusion.cc 
b/gcc/config/aarch64/aarch64-ldp-fusion.cc
index 365dcf48b22..4258a560c48 100644
--- a/gcc/config/aarch64/aarch64-ldp-fusion.cc
+++ b/gcc/config/aarch64/aarch64-ldp-fusion.cc
@@ -1730,11 +1730,11 @@ ldp_bb_info::fuse_pair (bool load_p,
adjust_amt *= -1;
 
   rtx change_reg = XEXP (change_pat, !load_p);
-  machine_mode mode_for_mem = GET_MODE (change_mem);
   rtx effective_base = drop_writeback (base_mem);
-  rtx new_mem = adjust_address_nv (effective_base,
-  mode_for_mem,
-  adjust_amt);
+  rtx adjusted_addr = plus_constant (Pmode,
+XEXP (effective_base, 0),
+adjust_amt);
+  rtx new_mem = replace_equiv_address (change_mem, adjusted_addr);
   rtx new_set = load_p
? gen_rtx_SET (change_reg, new_mem)
: gen_rtx_SET (new_mem, change_reg);
diff --git a/gcc/testsuite/gcc.target/aarch64/pr114674.c 
b/gcc/testsuite/gcc.target/aarch64/pr114674.c
new file mode 100644
index 000..944784fd008
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr114674.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 --param=aarch64-stp-policy=aligned" } */
+typedef struct {
+   unsigned int f1;
+   unsigned int f2;
+} test_struct;
+
+static test_struct ts = {
+   123, 456
+};
+
+void foo(void)
+{
+   ts.f2 = 36969 * (ts.f2 & 65535) + (ts.f1 >> 16);
+   ts.f1 = 18000 * (ts.f2 & 65535) + (ts.f2 >> 16);
+}
+/* { dg-final { scan-assembler-times "stp" 1 } } */

[PATCH][wwwdocs] modula2 update for changes.html, index.html, readings.html and frontends.html

[Gaius Mulley]

Hello,

Here are a proposed set of patches to highlight the changes in the
modula-2 frontend for GCC 14.1.

The patches also contain updates for:

  * readings.html: Add Modula-2 language standards.
  * index.html: Modula-2 listed in the languages supported by GCC.
  * frontends.html: Update now Modula-2 is in the tree.
  * changes.html: Highlight user facing changes.

feel free to adjust or rewrite in anyway,

regards,
Gaius



diff --git a/htdocs/frontends.html b/htdocs/frontends.html
index d47b56b6..2dec80c9 100644
--- a/htdocs/frontends.html
+++ b/htdocs/frontends.html
@@ -43,8 +43,8 @@ has a back end that generates assembler directly, using the 
GCC back end.
 http://www.nongnu.org/gm2/;>GNU Modula-2 implements
 the ISO/IEC 10514-1, PIM2, PIM3 and PIM4 dialects of the language.
 The compiler is operational with GCC 10, GCC 11, and GCC 12 (on
-GNU/Linux x86 systems).  The front end is now in the GCC development
-trunk (GCC 13).  It is mostly written in Modula-2 and includes a
+GNU/Linux x86 systems).  The front end was merged into the GCC tree
+during GCC 13.  It is mostly written in Modula-2 and includes a
 bootstrap tool which translates Modula-2 into C/C++.
 
 Modula-3 (for links see 
 
 
 
+Modula-2
+
+  The automatic dependency generation options: -M,
+-MD, -MF,
+-MMD, -MP, -MQ and
+-MT have been implemented in the compiler.
+  
+  The -Wcase-enum
+and -Wuninit-variable-checking= options have
+been implemented to provide compile time warnings against
+missing case clauses and uninitialized variables respectively.
+  
+
+
 
 libgccjit
 
diff --git a/htdocs/index.html b/htdocs/index.html
index 909cae75..125fc4ce 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -19,7 +19,7 @@
 C,
 C++,
 Objective-C, Fortran,
-Ada, Go, and D, as well as libraries for these languages (libstdc++,...).
+Ada, Go, D and Modula-2 as well as libraries for these languages 
(libstdc++,...).
 GCC was originally written as the compiler for the http://www.gnu.org/gnu/thegnuproject.html;>GNU operating system.
 The GNU system was developed to be 100% free software, free in the sense
diff --git a/htdocs/readings.html b/htdocs/readings.html
index ee77d969..e78c4769 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -559,6 +559,18 @@ names.
 
 
 
+Modula 2 information
+
+
+  https://www.research-collection.ethz.ch/handle/20.500.11850/68683;>Programming
+  in Modula-2 (Edition 2)
+  https://freepages.modula2.org/report4/modula-2.html;>Programming
+  in Modula-2 (Edition 4)
+  http://sc22wg13.twi.tudelft.nl;>ISO Modula-2 standards
+  (base language, OO and generic language extensions)
+
+
+
 Modula 3 information
 
 

RE: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

[Li, Pan2]

Thanks for reporting this. Just take a look from my test log that 930623-1.c is 
all pass.

Thus I bet this difference comes from the build option --with-arch=rv32imac but 
my test script take rv64gcv.

> I've built the git revision f3fdcf4a37a with 
> ../gcc-trunk/configure --target=riscv-unknown-elf 
> --prefix=/home/ed/gnu/riscv-unknown-elf --enable-languages=c,c++ 
> --disable-multilib --with-arch=rv32imac --with-abi=ilp32

> I am a bit surprised since the target is not supposed to support floating 
> point
> or vector instructions AFAIK.

Because you specify rv32imac, with doesn't include f/d/v extension, aka 
single/double floating point and vector extension. Thus, related functionality 
are disabled.

> The issue does not happen with gcc-trunk from yesterday.

Ack, will look into it.

Pan

-Original Message-
From: Bernd Edlinger  
Sent: Thursday, April 11, 2024 7:52 PM
To: Li, Pan2 ; Kito Cheng ; 
juzhe.zh...@rivai.ai
Cc: gcc-patches 
Subject: Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode 
switch

On 4/11/24 05:03, Li, Pan2 wrote:
> Committed, thanks Juzhe and Kito.
> 
> Pan


Hi Pan,

this commit caused a regression:

FAIL: gcc.c-torture/compile/930623-1.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O1  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O2  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O3 -g  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -Os  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (internal compiler error: in emit_vec_extract, at 
config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)

gcc/testsuite/gcc.c-torture/compile/930623-1.c:10:3: internal compiler error: 
in emit_vec_extract, at config/riscv/riscv-v.cc:5059^M
0xbba2de riscv_vector::emit_vec_extract(rtx_def*, rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv-v.cc:5059^M
0x186945f riscv_legitimize_move(machine_mode, rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv.cc:2895^M
0x1ef50b2 gen_movsi(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv.md:2225^M
0xffc91c rtx_insn* insn_gen_fn::operator()(rtx_def*, 
rtx_def*) const^M
../../gcc-trunk/gcc/recog.h:441^M
0xffc91c emit_move_insn_1(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/expr.cc:4551^M
0xffcdf4 emit_move_insn(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/expr.cc:4721^M
0x1002f17 emit_move_multi_word^M
../../gcc-trunk/gcc/expr.cc:4517^M
0xffcdf4 emit_move_insn(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/expr.cc:4721^M
0x1efc6b7 gen_untyped_call(rtx_def*, rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv.md:3478^M
0x185fc7c target_gen_untyped_call^M
../../gcc-trunk/gcc/config/riscv/riscv.md:3453^M
0xe8e81f expand_builtin_apply^M
../../gcc-trunk/gcc/builtins.cc:1761^M
0xea053c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)^M
../../gcc-trunk/gcc/builtins.cc:8001^M
0xff9e27 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)^M
../../gcc-trunk/gcc/expr.cc:12353^M
0xec4c3d expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)^M
../../gcc-trunk/gcc/expr.h:316^M
0xec4c3d expand_call_stmt^M
../../gcc-trunk/gcc/cfgexpand.cc:2865^M
0xec4c3d expand_gimple_stmt_1^M
../../gcc-trunk/gcc/cfgexpand.cc:3932^M
0xec4c3d expand_gimple_stmt^M
../../gcc-trunk/gcc/cfgexpand.cc:4077^M
0xeca206 expand_gimple_basic_block^M
../../gcc-trunk/gcc/cfgexpand.cc:6133^M
0xecc287 execute^M
../../gcc-trunk/gcc/cfgexpand.cc:6872^M
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1

I've built the git revision f3fdcf4a37a with 
../gcc-trunk/configure --target=riscv-unknown-elf 
--prefix=/home/ed/gnu/riscv-unknown-elf --enable-languages=c,c++ 
--disable-multilib --with-arch=rv32imac --with-abi=ilp32

I am a bit surprised since the target is not supposed to support floating point
or vector instructions AFAIK.

The issue does not happen with gcc-trunk from yesterday.

Regards
Bernd.

Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

[Bernd Edlinger]

On 4/11/24 05:03, Li, Pan2 wrote:
> Committed, thanks Juzhe and Kito.
> 
> Pan


Hi Pan,

this commit caused a regression:

FAIL: gcc.c-torture/compile/930623-1.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O1  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O2  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O3 -g  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -Os  (internal compiler error: in 
emit_vec_extract, at config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (internal compiler error: in emit_vec_extract, at 
config/riscv/riscv-v.cc:5059)
FAIL: gcc.c-torture/compile/930623-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)

gcc/testsuite/gcc.c-torture/compile/930623-1.c:10:3: internal compiler error: 
in emit_vec_extract, at config/riscv/riscv-v.cc:5059^M
0xbba2de riscv_vector::emit_vec_extract(rtx_def*, rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv-v.cc:5059^M
0x186945f riscv_legitimize_move(machine_mode, rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv.cc:2895^M
0x1ef50b2 gen_movsi(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv.md:2225^M
0xffc91c rtx_insn* insn_gen_fn::operator()(rtx_def*, 
rtx_def*) const^M
../../gcc-trunk/gcc/recog.h:441^M
0xffc91c emit_move_insn_1(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/expr.cc:4551^M
0xffcdf4 emit_move_insn(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/expr.cc:4721^M
0x1002f17 emit_move_multi_word^M
../../gcc-trunk/gcc/expr.cc:4517^M
0xffcdf4 emit_move_insn(rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/expr.cc:4721^M
0x1efc6b7 gen_untyped_call(rtx_def*, rtx_def*, rtx_def*)^M
../../gcc-trunk/gcc/config/riscv/riscv.md:3478^M
0x185fc7c target_gen_untyped_call^M
../../gcc-trunk/gcc/config/riscv/riscv.md:3453^M
0xe8e81f expand_builtin_apply^M
../../gcc-trunk/gcc/builtins.cc:1761^M
0xea053c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)^M
../../gcc-trunk/gcc/builtins.cc:8001^M
0xff9e27 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)^M
../../gcc-trunk/gcc/expr.cc:12353^M
0xec4c3d expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)^M
../../gcc-trunk/gcc/expr.h:316^M
0xec4c3d expand_call_stmt^M
../../gcc-trunk/gcc/cfgexpand.cc:2865^M
0xec4c3d expand_gimple_stmt_1^M
../../gcc-trunk/gcc/cfgexpand.cc:3932^M
0xec4c3d expand_gimple_stmt^M
../../gcc-trunk/gcc/cfgexpand.cc:4077^M
0xeca206 expand_gimple_basic_block^M
../../gcc-trunk/gcc/cfgexpand.cc:6133^M
0xecc287 execute^M
../../gcc-trunk/gcc/cfgexpand.cc:6872^M
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1

I've built the git revision f3fdcf4a37a with 
../gcc-trunk/configure --target=riscv-unknown-elf 
--prefix=/home/ed/gnu/riscv-unknown-elf --enable-languages=c,c++ 
--disable-multilib --with-arch=rv32imac --with-abi=ilp32

I am a bit surprised since the target is not supposed to support floating point
or vector instructions AFAIK.

The issue does not happen with gcc-trunk from yesterday.

Regards
Bernd.

RE: [PATCH] asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027]

[Liu, Hongtao]

> -Original Message-
> From: Jakub Jelinek 
> Sent: Thursday, April 11, 2024 4:39 PM
> To: Richard Biener ; Jeff Law ;
> Liu, Hongtao 
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] asan, v3: Fix up handling of > 32 byte aligned variables 
> with -
> fsanitize=address -fstack-protector* [PR110027]
> 
> On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote:
> > > > So, try to add some other variable with larger size and smaller
> > > > alignment to the frame (and make sure it isn't optimized away).
> > > >
> > > > alignb above is the alignment of the first partition's var, if
> > > > align_frame_offset really needs to depend on the var alignment, it
> > > > probably should be the maximum alignment of all the vars with
> > > > alignment alignb * BITS_PER_UNIT <=3D
> > > > MAX_SUPPORTED_STACK_ALIGNMENT
> > > >
> >
> > In asan_emit_stack_protection, when it allocated fake stack, it assume
> > bottom of stack is also aligned to alignb. And the place violated this
> > is the first var partition. which is 32 bytes offsets,  it should be
> > BIGGEST_ALIGNMENT / BITS_PER_UNIT.
> > So I think we need to use MAX (BIGGEST_ALIGNMENT / BITS_PER_UNIT,
> > ASAN_RED_ZONE_SIZE) for the first var partition.
> 
> Your first patch aligned offsets[0] to maximum of alignb and
> ASAN_RED_ZONE_SIZE.  But as I wrote in the reply to that mail, alignb there is
> the alignment of just a single variable which is the first one to appear in 
> the
> sorted list and is placed in the highest spot in the stack frame.
> That is not necessarily the largest alignment, the sorting ensures that it is 
> a
> variable with the largest size in the frame (and only if several of them have
> equal size, largest alignment from the same sized ones).  Your second patch
> used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and
> ASAN_RED_ZONE_SIZE.  That doesn't change anything at all when using -mno-
> avx512f - offsets[0] is still just 32-byte aligned in that case relative to 
> top of
> frame, just changes the -mavx512f case to be 64-byte aligned offsets[0] (aka
> offsets[0] is then either 0 or -64 instead of either
> 0 or -32).  That will not help if any variable in the frame needs 128-byte, 
> 256-
> byte, 512-byte ...  4096-byte alignment.  If you want to fix the bug in the 
> spot
> you've touched, you'd need to walk all the stack_vars[stack_vars_sorted[si2]]
> for si2 [si + 1, n - 1] and for those where the loop would do anything (i.e.
> stack_vars[i2].representative == i2
> && TREE_CODE (decl2) == SSA_NAME
>? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] == NULL_RTX
>: DECL_RTL (decl2) == pc_rtx
> and the pred applies (but that means also walking the earlier ones!
> because with -fstack-protector* the vars can be processed in several calls) 
> and
> alignb2 * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT and
> compute maximum of those alignments.
> That maximum is already computed,
> data->asan_alignb = MAX (data->asan_alignb, alignb);
> computes that, but you get the final result only after you do all the
> expand_stack_vars calls.  You'd need to compute it before.
> 
> Though, that change would be still in the wrong place.
> The thing is, it would be a waste of the precious stack space when it isn't
> needed at all (e.g.  when asan will not at compile time do the use after 
> return
> checking, or if it won't do it at runtime, or even if it will do at runtime 
> it will
> waste the space on the stack).
> 
> The following patch fixes it solely for the __asan_stack_malloc_N allocations,
> doesn't enlarge unnecessarily further the actual stack frame.
> Because asan is only supported on FRAME_GROWS_DOWNWARD
> architectures (mips, rs6000 and xtensa are conditional
> FRAME_GROWS_DOWNWARD arches, which for -fsanitize=address or -fstack-
> protector* use FRAME_GROWS_DOWNWARD 1, otherwise 0, others
> supporting asan always just use 1), the assumption for the dynamic stack
> realignment is that the top of the stack frame (aka offset
> 0) is aligned to alignb passed to the function (which is the maximum of alignb
> of all the vars in the frame).  As checked by the assertion in the patch,
> offsets[0] is 0 most of the time and so that assumption is correct, the only
> case when it is not 0 is if -fstack-protector* is on together with -
> fsanitize=address and cfgexpand.cc (create_stack_guard) created a stack
> guard.  That is the only variable which is allocated in the stack frame right
> away, for all others with -fsanitize=address defer_stack_allocation (or 
> -fstack-
> protector*) returns true and so they aren't allocated immediately but handled
> during the frame layout phases.  So, the original frame_offset of 0 is changed
> because of the stack guard to -pointer_size_in_bytes and later at the
>   if (data->asan_vec.is_empty ())
> {
>   align_frame_offset (ASAN_RED_ZONE_SIZE);
>   prev_offset = frame_offset.to_constant ();
> }
> to 

[PATCH 3/3] bpf: add line_info support to BTF.ext section.

[Cupertino Miranda]

This patch adds line_info debug information support to .BTF.ext
sections.
Line info information is used by the BPF verifier to improve error
reporting and give more precise source core referenced errors.

gcc/Changelog:
* config/bpf/bpf-protos.h (bpf_output_call): Change prototype.
* config/bpf/bpf.cc (bpf_output_call): Change to adapt operands
and return
the instruction template instead of emmidiatelly emit asm and
not allow proper final expected execution flow.
(bpf_output_line_info): Add function to introduce line info
entries in respective structures
(bpf_asm_out_unwind_emit): Add function as hook to
TARGET_ASM_UNWIND_EMIT. This hook is called before any
instruction is emitted.
* config/bpf/bpf.md: Change calls to bpf_output_call.
* config/bpf/btfext-out.cc (struct btf_ext_lineinfo): Add fields
to struct.
(bpf_create_lineinfo, btf_add_line_info_for): Add support
function to insert line_info data in respective structures.
(output_btfext_line_info): Function to emit line_info data in
.BTF.ext section.
(btf_ext_output): Call output_btfext_line_info.
* config/bpf/btfext-out.h: Add prototype for
btf_add_line_info_for.
---
 gcc/config/bpf/bpf-protos.h   |   2 +-
 gcc/config/bpf/bpf.cc | 103 ++---
 gcc/config/bpf/bpf.md |   4 +-
 gcc/config/bpf/btfext-out.cc  | 108 +-
 gcc/config/bpf/btfext-out.h   |   4 +
 .../gcc.target/bpf/btfext-funcinfo.c  |   3 +-
 6 files changed, 203 insertions(+), 21 deletions(-)

diff --git a/gcc/config/bpf/bpf-protos.h b/gcc/config/bpf/bpf-protos.h
index b4866d34209..ddaca50af69 100644
--- a/gcc/config/bpf/bpf-protos.h
+++ b/gcc/config/bpf/bpf-protos.h
@@ -23,7 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 /* Routines implemented in bpf.cc.  */
 
 extern HOST_WIDE_INT bpf_initial_elimination_offset (int, int);
-extern const char *bpf_output_call (rtx);
+extern const char *bpf_output_call (const char *templ, rtx *, int 
target_index);
 extern void bpf_target_macros (cpp_reader *);
 extern void bpf_print_operand (FILE *, rtx, int);
 extern void bpf_print_operand_address (FILE *, rtx);
diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
index d9141dd625a..f1a8eb8d62c 100644
--- a/gcc/config/bpf/bpf.cc
+++ b/gcc/config/bpf/bpf.cc
@@ -754,14 +754,12 @@ bpf_output_destructor (rtx symbol, int priority 
ATTRIBUTE_UNUSED)
bpf.md.  */
 
 const char *
-bpf_output_call (rtx target)
+bpf_output_call (const char *templ, rtx *operands, int target_index)
 {
-  rtx xops[1];
-
+  rtx target = operands[target_index];
   switch (GET_CODE (target))
 {
 case CONST_INT:
-  output_asm_insn ("call\t%0", );
   break;
 case SYMBOL_REF:
   {
@@ -774,26 +772,20 @@ bpf_output_call (rtx target)
  {
tree attr_args = TREE_VALUE (attr);
 
-   xops[0] = GEN_INT (TREE_INT_CST_LOW (TREE_VALUE (attr_args)));
-   output_asm_insn ("call\t%0", xops);
- }
-   else
- output_asm_insn ("call\t%0", );
+   operands[target_index] = GEN_INT (TREE_INT_CST_LOW (TREE_VALUE 
(attr_args)));
 
+ }
break;
   }
 default:
-  if (TARGET_XBPF)
-   output_asm_insn ("call\t%0", );
-  else
+  if (!TARGET_XBPF)
{
  error ("indirect call in function, which are not supported by eBPF");
- output_asm_insn ("call 0", NULL);
+ operands[target_index] = GEN_INT (0);
}
   break;
 }
-
-  return "";
+  return templ;
 }
 
 const char *
@@ -1144,6 +1136,87 @@ bpf_debug_unwind_info ()
 #undef TARGET_DEBUG_UNWIND_INFO
 #define TARGET_DEBUG_UNWIND_INFO bpf_debug_unwind_info
 
+/* Create a BTF.ext line_info entry.  */
+
+static void
+bpf_output_line_info (FILE *asm_out_file, rtx_insn *insn)
+{
+  static unsigned int line_info_label = 1;
+  static tree cfun_decl = NULL_TREE;
+  static bool func_start_added = false;
+  const char *label = NULL;
+  unsigned int loc = 0;
+  const char *filename = NULL;
+  unsigned int line = 0;
+  unsigned int column = 0;
+
+  if(!btf_debuginfo_p ())
+return;
+
+  gcc_assert (insn != NULL_RTX);
+
+  if (current_function_decl != cfun_decl
+  && GET_CODE (insn) == NOTE)
+{
+  label = current_function_func_begin_label;
+  loc = DECL_SOURCE_LOCATION (current_function_decl);
+  filename = LOCATION_FILE (loc);
+  line = LOCATION_LINE (loc);
+  column = LOCATION_COLUMN (loc);
+  func_start_added = true;
+}
+  else
+{
+  if (GET_CODE (insn) == NOTE)
+   return;
+
+  /* Already added a label for this location. This might not be fully
+acurate but it is better then adding 2 entries on the same location,
+which is imcompatible with the verifier expectations.  */
+  if 

[PATCH 1/3] bpf: support more instructions to match CO-RE relocations

[Cupertino Miranda]

BPF supports multiple instructions to be CO-RE relocatable regardless of
the position of the immediate field in the encoding.
In particular, not only the MOV instruction allows a CO-RE
relocation of its immediate operand, but the LD and ST instructions can
have a CO-RE relocation happening to their offset immediate operand,
even though those operands are encoded in different encoding bits.
This patch moves matching from a more traditional matching of the
UNSPEC_CORE_RELOC pattern within a define_insn to a match within the
constraints of both immediates and address operands from more generic
mov define_insn rule.

gcc/Changelog:
* config/bpf/bpf-protos.h (bpf_add_core_reloc): Renamed function
to bpf_output_move.
* config/bpf/bpf.cc (bpf_legitimate_address_p): Allow
UNSPEC_CORE_RELOC to match an address.
(bpf_insn_cost): Make UNSPEC_CORE_RELOC immediate moves
expensive to prioritize loads and stores.
(TARGET_INSN_COST): Add hook.
(bpf_output_move): Wrapper to call bpf_output_core_reloc.
(bpf_print_operand): Add support to print immediate operands
specified with the UNSPEC_CORE_RELOC.
(bpf_print_operand_address): Likewise, but to support
UNSPEC_CORE_RELOC in addresses.
(bpf_init_builtins): Flag BPF_BUILTIN_CORE_RELOC as NOTHROW.
* config/bpf/bpf.md: Wrap patterns for MOV, LD and ST
instruction with bpf_output_move call.
(mov_reloc_core): Remove now spurious define_insn.
* config/bpf/constraints.md: Added "c" and "C" constraints to
match immediates represented with UNSPEC_CORE_RELOC.
* config/bpf/core-builtins.cc (bpf_add_core_reloc): Remove
(bpf_output_core_reloc): Add function to create the CO-RE
relocations based on new matching rules.
* config/bpf/core-builtins.h (bpf_output_core_reloc): Add
prototype.
* config/bpf/predicates.md (core_imm_operand) Add predicate.
(mov_src_operand): Add match for core_imm_operand.

gcc/testsuite/ChangeLog:
* gcc.target/bpf/btfext-funcinfo.c: Updated to changes.
* gcc.target/bpf/core-builtin-fieldinfo-const-elimination.c:
Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-existence-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-lshift-1-be.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-lshift-1-le.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-lshift-2.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-offset-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-rshift-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-rshift-2.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-sign-1.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-sign-2.c: Likewise.
* gcc.target/bpf/core-builtin-fieldinfo-size-1.c: Likewise.
---
 gcc/config/bpf/bpf-protos.h   |  2 +-
 gcc/config/bpf/bpf.cc | 54 +-
 gcc/config/bpf/bpf.md | 56 ++-
 gcc/config/bpf/constraints.md | 20 ++
 gcc/config/bpf/core-builtins.cc   | 71 ++-
 gcc/config/bpf/core-builtins.h|  2 +
 gcc/config/bpf/predicates.md  |  7 +-
 .../gcc.target/bpf/btfext-funcinfo.c  |  2 -
 ...core-builtin-fieldinfo-const-elimination.c |  2 +-
 .../bpf/core-builtin-fieldinfo-existence-1.c  |  2 +-
 .../bpf/core-builtin-fieldinfo-lshift-1-be.c  |  8 +--
 .../bpf/core-builtin-fieldinfo-lshift-1-le.c  |  8 +--
 .../bpf/core-builtin-fieldinfo-lshift-2.c |  6 +-
 .../bpf/core-builtin-fieldinfo-offset-1.c | 12 ++--
 .../bpf/core-builtin-fieldinfo-rshift-1.c |  8 +--
 .../bpf/core-builtin-fieldinfo-rshift-2.c |  4 +-
 .../bpf/core-builtin-fieldinfo-sign-1.c   |  4 +-
 .../bpf/core-builtin-fieldinfo-sign-2.c   |  4 +-
 .../bpf/core-builtin-fieldinfo-size-1.c   |  8 +--
 19 files changed, 189 insertions(+), 91 deletions(-)

diff --git a/gcc/config/bpf/bpf-protos.h b/gcc/config/bpf/bpf-protos.h
index ac0c2f4038f..b4866d34209 100644
--- a/gcc/config/bpf/bpf-protos.h
+++ b/gcc/config/bpf/bpf-protos.h
@@ -30,7 +30,7 @@ extern void bpf_print_operand_address (FILE *, rtx);
 extern void bpf_expand_prologue (void);
 extern void bpf_expand_epilogue (void);
 extern void bpf_expand_cbranch (machine_mode, rtx *);
-const char *bpf_add_core_reloc (rtx *operands, const char *templ);
+const char *bpf_output_move (rtx *operands, const char *templ);
 
 class gimple_opt_pass;
 gimple_opt_pass *make_pass_lower_bpf_core (gcc::context *ctxt);
diff --git a/gcc/config/bpf/bpf.cc b/gcc/config/bpf/bpf.cc
index fb60770c170..d9141dd625a 100644
--- a/gcc/config/bpf/bpf.cc
+++ b/gcc/config/bpf/bpf.cc
@@ -584,6 +584,16 @@ bpf_legitimate_address_p (machine_mode mode,
if (bpf_address_base_p (x0, strict) && GET_CODE (x1) == CONST_INT)
  return 

[PATCH 2/3] bpf: remove huge memory waste with string allocation.

[Cupertino Miranda]

Code was allocating way too much space for the string.

gcc/ChangeLog:
* config/bpf/core-builtins.cc (process_enum_value): Corrected
string allocation.
---
 gcc/config/bpf/core-builtins.cc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gcc/config/bpf/core-builtins.cc b/gcc/config/bpf/core-builtins.cc
index e03e986e2c1..ead1777d465 100644
--- a/gcc/config/bpf/core-builtins.cc
+++ b/gcc/config/bpf/core-builtins.cc
@@ -872,10 +872,11 @@ process_enum_value (struct cr_builtins *data)
{
  if (TREE_VALUE (l) == expr)
{
- char *tmp = (char *) ggc_alloc_atomic ((index / 10) + 1);
+ /* Array size is 21 = ceil(log_10(2^64)) + 1 to hold string
+representations of 64 bit integers.  */
+ char tmp[21];
  sprintf (tmp, "%d", index);
- ret.str = (const char *) tmp;
-
+ ret.str = CONST_CAST (char *, ggc_strdup(tmp));
  break;
}
  index++;
-- 
2.30.2

Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output

[Jonathan Wakely]

On Thu, 25 Jan 2024 at 15:54, Christophe Lyon
 wrote:
>
> On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely  wrote:
> >
> > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> > >
> > > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
> >
> > We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> >
>
> Hmm, right, sorry I had this patch in my tree for quite some time, but
> wrote the description just now, so I read a bit too quickly.
>
> >
> > > possibly leading to mismatches under racy conditions.
> >
> > What do we incorrectly match? Is the problem that a \r\n sequence
> > might be incompletely printed, due to buffering, and so the regex only
> > sees (and matches) the \r which then leaves an unwanted \n in the
> > stream, which then interferes with the next match? I don't understand
> > why that problem wouldn't just result in a failed match with your new
> > regex though.
> >
> Exactly: READ1 forces read() to return 1 byte at a time, so we leave
> an unwanted \r in front of a string that should otherwise match the
> "got" case.
>
> >
> > >
> > > I noticed this while running the GCC testsuite using the equivalent of
> > > GDB's READ1 feature [1] which helps detecting bufferization issues.
> > >
> > > Adjusting the first regexp to match the right order implied fixing the
> > > second one, to skip the empty lines.
> >
> > At the very least, this part of the description is misleading. The
> > existing regex matches "the right order" already. The change is to
> > match *exactly* \r\n instead of any mix of CR and LF characters.
> > That's not about matching "the right order", it's being more precise
> > in what we match.
> >
> > But I'm still confused about what the failure scenario is and how the
> > change fixes it.
> >
>
> I followed what the GDB testsuite does (it matches \r\n at the end of
> many regexps), but in fact it seems it's not needed:
> it works if I update the "got" regexp like this (ie. accept any number
> of leading \r or \n):
> -   -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> +   -re {^[\n\r]*(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> and leave the "skipping" regexp as it is currently.
>
> Is the new attached version OK?

Yeah this makes more sense to me now, thanks.

OK for trunk.


>
> Thanks,
>
> Christophe
>
> > >
> > > Tested on aarch64-linux-gnu.
> > >
> > > [1] 
> > > https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
> > >
> > > 2024-01-24  Christophe Lyon  
> > >
> > > libstdc++-v3/
> > > * testsuite/lib/gdb-test.exp (gdb-test): Fix regexps.
> > > ---
> > >  libstdc++-v3/testsuite/lib/gdb-test.exp | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp 
> > > b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > index 31206f2fc32..0de8d9ee153 100644
> > > --- a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > +++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > @@ -194,7 +194,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 
> > > 0} } {
> > >
> > >  set test_counter 0
> > >  remote_expect target [timeout_value] {
> > > -   -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > > +   -re {^(type|\$([0-9]+)) = ([^\n\r]*)\r\n} {
> > > send_log "got: $expect_out(buffer)"
> > >
> > > incr test_counter
> > > @@ -250,7 +250,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 
> > > 0} } {
> > > return
> > > }
> > >
> > > -   -re {^[^$][^\n\r]*[\n\r]+} {
> > > +   -re {^[\r\n]*[^$][^\n\r]*\r\n} {
> > > send_log "skipping: $expect_out(buffer)"
> > > exp_continue
> > > }
> > > --
> > > 2.34.1
> > >
> >

Re: [PATCH] openmp: Add support for the 'indirect' clause in C/C++

[Thomas Schwinge]

Hi!

I've filed 
"OpenMP 'indirect' clause: dynamic image loading/unloading" for the
following issue:

On 2023-11-13T12:47:04+0100, Tobias Burnus  wrote:
> On 13.11.23 11:59, Thomas Schwinge wrote:
 Also, for my understanding: why is 'build_indirect_map' done at kernel
 invocation time (here) instead of at image load time?
>>> The splay_tree is generated on the device itself - and we currently do
>>> not start a kernel during GOMP_OFFLOAD_load_image. We could, the
>>> question is whether it makes sense. (Generating the splay_tree on the
>>> host for the device is a hassle and error prone as it needs to use
>>> device pointers at the end.)
>> Hmm.  It seems conceptually cleaner to me to set this up upfront, and
>> avoids potentially slowing down every device kernel invocation (at least
>> another function call, and 'gomp_mutex_lock' check).  Though, I agree
>> this may be "in the noise" with regards to all the other stuff going on
>> in 'gomp_gcn_enter_kernel' and elsewhere...
>
> I think the most common case is GOMP_INDIRECT_ADDR_MAP == NULL.
>
> The question is whether the lock should/could be moved inside  if 
> (!indirect_array)
> or not. Probably yes:
> * doing an atomic load for the outer '!indirect array', work on a local array 
> for
> the build up and only assign it at the end - and just after the lock check 
> again
> whether '!indirect array'.
>
> That way, it is lock free once build but when build there is no race.
>
>> What I just realize, what's also unclear to me is how the current
>> implementation works with regards to several images getting loaded --
>> don't we then overwrite 'GOMP_INDIRECT_ADDR_MAP' instead of
>> (conceptually) appending to it?
>
> Yes, I think that will happen - but it looks as if the same issue exists
> also the other code? I think that's not the first variable that has that
> issue?
>
> I think we should try to cleanup that handling, also to support calling
> a device function in a shared library from a target region in the main
> program, which currently also fails.
>
> All device routines that are in normal static libraries and in the
> object files of the main program should simply work thanks to offload
> LTO such that there is only a single GOMP_offload_register_ver call (per
> device type) and GOMP_OFFLOAD_load_image call (per device).
>
> Likewise if the offloading is only done via a single shared library. —
> Any mixing will currently fail, unfortunately. This patch just adds
> another item which does not handle it properly.
>
> (Not good but IMHO also not a showstopper for this patch.)
>
>> In the general case, additional images may also get loaded during
>> execution.  We thus need proper locking of the shared data structure, uh?
>> Or, can we have separate on-device data structures per image?  (I've not
>> yet thought about that in detail.)
>
> I think we could - but in the main-program 'omp target' case that calls
> a shared-library 'declare target' function means that we need to handle
> multiple GOMP_offload_register_ver / load_image calls such that they can
> work together.
>
> Obviously, it gets harder if the user keeps doing dlopen() / dlclose()
> of libraries containing offload code where a target/compute region is
> run before, between, and after those calls (but hopefully not running
> when calling dlopen/dlclose).
>
>> Relatedly then, when images are unloaded, we also need to remove stale
>> items from the table, and release resources (for example, the
>> 'GOMP_OFFLOAD_alloc' for 'map_target_addr').
>
> True. I think the general assumption is that images only get unloaded at
> the very end, which matches most but not all code. Yet another work item.
>
> I think we should open a new PR about this topic and collect work items
> there.


Grüße
 Thomas