[Bug tree-optimization/107368] New: [13 Regression] ICE: 'verify_gimple' failed (error: non-trivial conversion in 'var_decl')

[asolokha at gmx dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107368

Bug ID: 107368
   Summary: [13 Regression] ICE: 'verify_gimple' failed (error:
non-trivial conversion in 'var_decl')
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20221023 snapshot (g:0e37fd4dc74c1db99cdc7d71ef378e1221253c6f) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/attr-assume-1.c, w/ -O1:

double
f4 (double x)
{
  [[gnu::assume(x && x > 0.0)]];
  return x;
}

% gcc-13 -O1 -c ynay1wc5.c
ynay1wc5.c: In function 'f4':
ynay1wc5.c:2:1: error: non-trivial conversion in 'var_decl'
2 | f4 (double x)
  | ^~
_Bool
int
D.1992 = iftmp.0;
ynay1wc5.c:2:1: internal compiler error: 'verify_gimple' failed
0xf44b4e verify_gimple_in_seq(gimple*, bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/tree-cfg.cc:5309
0xc2973a gimplify_body(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/gimplify.cc:17697
0xc298fa gimplify_function_tree(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/gimplify.cc:17813
0xa46797 cgraph_node::analyze()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cgraphunit.cc:676
0xa49337 analyze_functions
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cgraphunit.cc:1240
0xa49fdd symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221023/work/gcc-13-20221023/gcc/cgraphunit.cc:2514

[Bug tree-optimization/106076] Sub-optimal code is generated for checking bitfields via proxy functions

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106076

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Andrew Pinski  ---
Mine. I am going to get this upstream finally for GCC 14.

[Bug tree-optimization/106076] Sub-optimal code is generated for checking bitfields via proxy functions

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106076

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/85043] -Wuseless-cast false positive for temporary objects; add separate -Wcast-to-the-same-type to cover that case instead

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85043

--- Comment #17 from Eric Gallager  ---
(In reply to Marek Polacek from comment #16)
> Should be fixed now.

It seems the fix just silenced the -Wuseless-cast false positive without also
adding the separate -Wcast-to-the-same-type flag to cover that case instead; I
still think that would be useful.

Re: Adding a new thread model to GCC

[LIU Hao via Gcc-patches]

在 2022/10/21 20:34, i.nix...@autistici.org 写道:


got it...
anyway it seems logical to me the way I proposed :)




Below is a message forwarded from mingw-w64-public, elaborating the necessity 
of a new thread model.

As there are objections from other mingw-w64 developers, I am putting those patches against 
mingw-w64-crt on hold for now. Despite that, all threading facilities - mutexes, condition 
variables, once flags, etc. - are still fully functional within the mcf thread model.


In addition, I will keep maintaining my personal builds (from GCC 12 release branch) with these 
patches at https://gcc-mcf.lhmouse.com/.



 Forwarded Message 
在 2022/10/23 18:06, Jacek Caban 写道:
>
> Please, let's not do that. It's possible to fix existing implementations, we 
don't need to make
> things more complicated than they are.
>

Okay okay, I think I have to compose a thorough list of problems that we are facing at the moment, 
and had better have a permalink to the mailing list archive that I can reference elsewhere. I have 
been tired of repeating the same grounds of arguments again and again:



1. In a DLL, destructors of static objects and callbacks that are registered
with `atexit()`, are executed by `LdrShutdownProcess()`, after all the other
thread have been terminated `ZwTerminateProcessO(NULL, status)`. This means
that, if another thread has been terminated while holding a mutex, the mutex
can never get unlocked. If a destructor attempts to lock the same mutex,
deadlocks will occur. Destructors of executables do not suffer from this
issue, because they are executed before `RtlExitUserProcess()`.

Standard behavior: Static destructors and exit callbacks should be executed
while other threads are running. If another thread attempts to access a
destroyed object, the behavior is undefined; the user is responsible to
prevent this from happening, by joining or suspending it.


2. Following 1, in a DLL, static destructors and exit callbacks are still
invoked when `_Exit()` or `quick_exit()` is called.

Standard behavior: `_Exit()` should not perform any cleanup; not even open
files are flushed. `quick_exit()` shall invoke all quick-exit callbacks in
reverse order, then call `_Exit()`.


3. There is a use-after-free bug [1] about thread-local destructors. I suspect
this is caused by emutls, because GCC uses `__cxa_thread_atexit()` to
register thread-local destructors, which could interleave with
`emutls_destroy()`.

Standard behavior: This is not allowed to happen. mcfgthread solves this
issue by running thread-local destructors and thread-specific key
destructors as two separate passes [3].

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80816
[2] 
https://github.com/gcc-mirror/gcc/blob/f84e4fb44aa26b71fbc64e0532fd24d96e5caa3f/libgcc/emutls.c#L96
[3] 
https://github.com/lhmouse/mcfgthread/blob/63e034d375caf585e2921cd3455f1048feb2172d/src/xglobals.c#L249



4. In the win32 thread model, thread-specific key destructors are called at
process exit [4], after static destructors.

Standard behavior: They shall be called only when a thread exits, and the
associated thread-specific values are not a null pointer. They shall not be
called when a program terminates; instead, users are responsible for
deallocating such resources before calling `exit()`. This requirement is
missing in POSIX, but formally specified by ISO/IEC 9899:2017, as the 4th
paragraph in '7.26.6.1 The tss_create function'.

[4] 
https://github.com/mingw-w64/mingw-w64/blob/d0a034a04d312434b842c4869a8a900568d8db98/mingw-w64-crt/crt/tlsthrd.c#L134



5. Wait operations, of timed mutexes and condition variables, should take
absolute time points as `struct timespec`.

Standard behavior: Both POSIX and ISO C specifies them as such, while all
Windows APIs take relative durations as a 32-bit integer of milliseconds,
which can also easily get overflown.


--
Best regards,
LIU Hao


OpenPGP_signature
Description: OpenPGP digital signature

[PATCH-2, rs6000] Reverse V8HI on Power8 by vector rotation [PR100866]

[HAO CHEN GUI via Gcc-patches]

Hi,
  This patch implements V8HI byte reverse on Power8 by vector rotation.
It should be effecient than orignial vector permute. The patch comes from
Xionghu's comments in PR. I just added a test case for it.

  Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.



ChangeLog
2022-10-24  Xionghu Luo 

gcc/
PR target/100866
* config/rs6000/altivec.md: (*altivec_vrl): Named to...
(altivec_vrl): ...this.
* config/rs6000/vsx.md (revb_): Call vspltish and vrlh when
target is Power8 and mode is V8HI.

gcc/testsuite/
PR target/100866
* gcc.target/powerpc/pr100866-2.c: New.

patch.diff
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 2c4940f2e21..84660073f32 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -1875,7 +1875,7 @@ (define_insn "altivec_vpkuum_direct"
 }
   [(set_attr "type" "vecperm")])

-(define_insn "*altivec_vrl"
+(define_insn "altivec_vrl"
   [(set (match_operand:VI2 0 "register_operand" "=v")
 (rotate:VI2 (match_operand:VI2 1 "register_operand" "v")
(match_operand:VI2 2 "register_operand" "v")))]
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index e226a93bbe5..34662a7252d 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -6092,12 +6092,21 @@ (define_expand "revb_"
 emit_insn (gen_p9_xxbr_ (operands[0], operands[1]));
   else
 {
-  /* Want to have the elements in reverse order relative
-to the endian mode in use, i.e. in LE mode, put elements
-in BE order.  */
-  rtx sel = swap_endian_selector_for_mode(mode);
-  emit_insn (gen_altivec_vperm_ (operands[0], operands[1],
-  operands[1], sel));
+  if (mode == V8HImode)
+   {
+ rtx splt = gen_reg_rtx (V8HImode);
+ emit_insn (gen_altivec_vspltish (splt, GEN_INT (8)));
+ emit_insn (gen_altivec_vrlh (operands[0], operands[1], splt));
+   }
+  else
+   {
+ /* Want to have the elements in reverse order relative
+to the endian mode in use, i.e. in LE mode, put elements
+in BE order.  */
+ rtx sel = swap_endian_selector_for_mode (mode);
+ emit_insn (gen_altivec_vperm_ (operands[0], operands[1],
+  operands[1], sel));
+   }
 }

   DONE;
diff --git a/gcc/testsuite/gcc.target/powerpc/pr100866-2.c 
b/gcc/testsuite/gcc.target/powerpc/pr100866-2.c
new file mode 100644
index 000..4357d1beb09
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr100866-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=power8" } */
+/* { dg-final { scan-assembler {\mvspltish\M} } } */
+/* { dg-final { scan-assembler {\mvrlh\M} } } */
+
+#include 
+
+vector unsigned short revb(vector unsigned short a)
+{
+   return vec_revb(a);
+}
+

Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int))

[Kito Cheng via Gcc-patches]

Merged two changes into one patch, and committed to master :)

On Mon, Oct 24, 2022 at 10:28 AM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_legitimize_move): Adjust using 
> force_reg.
>
> ---
>  gcc/config/riscv/riscv.cc | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 98374a922d1..1fd34f6ae8d 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -1967,9 +1967,7 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
> src)
>*/
>if (MEM_P (dest))
> {
> - rtx tmp = gen_reg_rtx (mode);
> - emit_move_insn (tmp, src);
> - emit_move_insn (dest, tmp);
> + emit_move_insn (dest, force_reg (mode, src));
>   return true;
> }
>poly_int64 value = rtx_to_poly_int64 (src);
> --
> 2.36.1
>

[PATCH] ix86: Suggest unroll factor for loop vectorization

[Cui,Lili via Gcc-patches]

Hi Hongtao,

This patch introduces function finish_cost and 
determine_suggested_unroll_factor for x86 backend, to make it be
able to suggest the unroll factor for a given loop being vectorized.
Referring to aarch64, RS6000 backends and basing on the analysis on
SPEC2017 performance evaluation results.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

OK for trunk?



With this patch, SPEC2017 performance evaluation results on
ICX/CLX/ADL/Znver3 are listed below:

For single copy:
  - ICX: 549.fotonik3d_r +6.2%, the others are neutral
  - CLX: 549.fotonik3d_r +1.9%, the others are neutral
  - ADL: 549.fotonik3d_r +4.5%, the others are neutral
  - Znver3: 549.fotonik3d_r +4.8%, the others are neutral

For multi-copy:
  - ADL: 549.fotonik3d_r +2.7%, the others are neutral

gcc/ChangeLog:

* config/i386/i386.cc (class ix86_vector_costs): Add new members
 m_nstmts, m_nloads m_nstores and determine_suggested_unroll_factor.
(ix86_vector_costs::add_stmt_cost): Update for m_nstores, m_nloads
and m_nstores.
(ix86_vector_costs::determine_suggested_unroll_factor): New function.
(ix86_vector_costs::finish_cost): Diito.
* config/i386/i386.opt:(x86-vect-unroll-limit): New parameter.
(x86-vect-unroll-min-ldst-threshold): Likewise.
(x86-vect-unroll-max-loop-size): Likewise.
* doc/invoke.texi: Document new parameter.

gcc/testsuite/ChangeLog:

* gcc.target/i386/cond_op_maxmin_b-1.c: Add -fno-unroll-loops.
* gcc.target/i386/cond_op_maxmin_ub-1.c: Ditto.
* gcc.target/i386/vect-alignment-peeling-1.c: Ditto.
* gcc.target/i386/vect-alignment-peeling-2.c: Ditto.
* gcc.target/i386/vect-reduc-1.c: Ditto.
---
 gcc/config/i386/i386.cc   | 106 ++
 gcc/config/i386/i386.opt  |  15 +++
 gcc/doc/invoke.texi   |  17 +++
 .../gcc.target/i386/cond_op_maxmin_b-1.c  |   2 +-
 .../gcc.target/i386/cond_op_maxmin_ub-1.c |   2 +-
 .../i386/vect-alignment-peeling-1.c   |   2 +-
 .../i386/vect-alignment-peeling-2.c   |   2 +-
 gcc/testsuite/gcc.target/i386/vect-reduc-1.c  |   2 +-
 8 files changed, 143 insertions(+), 5 deletions(-)

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index aeea26ef4be..a939354e55e 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -23336,6 +23336,17 @@ class ix86_vector_costs : public vector_costs
  stmt_vec_info stmt_info, slp_tree node,
  tree vectype, int misalign,
  vect_cost_model_location where) override;
+
+  unsigned int determine_suggested_unroll_factor (loop_vec_info);
+
+  void finish_cost (const vector_costs *) override;
+
+  /* Total number of vectorized stmts (loop only).  */
+  unsigned m_nstmts = 0;
+  /* Total number of loads (loop only).  */
+  unsigned m_nloads = 0;
+  /* Total number of stores (loop only).  */
+  unsigned m_nstores = 0;
 };
 
 /* Implement targetm.vectorize.create_costs.  */
@@ -23579,6 +23590,19 @@ ix86_vector_costs::add_stmt_cost (int count, 
vect_cost_for_stmt kind,
retval = (retval * 17) / 10;
 }
 
+  if (!m_costing_for_scalar
+  && is_a (m_vinfo)
+  && where == vect_body)
+{
+  m_nstmts += count;
+  if (kind == scalar_load || kind == vector_load
+ || kind == unaligned_load || kind == vector_gather_load)
+   m_nloads += count;
+  else if (kind == scalar_store || kind == vector_store
+  || kind == unaligned_store || kind == vector_scatter_store)
+   m_nstores += count;
+}
+
   m_costs[where] += retval;
 
   return retval;
@@ -23850,6 +23874,88 @@ ix86_loop_unroll_adjust (unsigned nunroll, class loop 
*loop)
   return nunroll;
 }
 
+unsigned int
+ix86_vector_costs::determine_suggested_unroll_factor (loop_vec_info loop_vinfo)
+{
+  class loop *loop = LOOP_VINFO_LOOP (loop_vinfo);
+
+  /* Don't unroll if it's specified explicitly not to be unrolled.  */
+  if (loop->unroll == 1
+  || (OPTION_SET_P (flag_unroll_loops) && !flag_unroll_loops)
+  || (OPTION_SET_P (flag_unroll_all_loops) && !flag_unroll_all_loops))
+return 1;
+
+  /* Don't unroll if there is no vectorized stmt.  */
+  if (m_nstmts == 0)
+return 1;
+
+  /* Don't unroll if vector size is zmm, since zmm throughput is lower than 
other
+ sizes.  */
+  if (GET_MODE_SIZE (loop_vinfo->vector_mode) == 64)
+return 1;
+
+  /* Calc the total number of loads and stores in the loop body.  */
+  unsigned int nstmts_ldst = m_nloads + m_nstores;
+
+  /* Don't unroll if loop body size big than threshold, the threshold
+ is a heuristic value inspired by param_max_unrolled_insns.  */
+  unsigned int uf = m_nstmts < (unsigned int)x86_vect_unroll_max_loop_size
+   ? ((unsigned int)x86_vect_unroll_max_loop_size / m_nstmts)
+   : 1;
+  uf = MIN ((unsigned 

[Bug libstdc++/107367] All standard library algorithms should optimize to pointers internally when they are contiguous iterators after C++20

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107367

--- Comment #1 from cqwrteur  ---
This optimization will prevent duplications of templates over iterators and
pointers. (vector::iterator and int* duplications for example)

For example:

https://godbolt.org/z/9zEajxxa8
vs
https://godbolt.org/z/n61vEddj1

579 vs 879

[Bug libstdc++/107367] New: All standard library algorithms should detect whether they are contiguous iterators after C++20

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107367

Bug ID: 107367
   Summary: All standard library algorithms should detect whether
they are contiguous iterators after C++20
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

https://github.com/gcc-mirror/gcc/blob/00716b776200c2de6813ce706d2757eec4cb2735/libstdc%2B%2B-v3/include/bits/stl_algo.h#L3229

Take is_sorted for example:

  template
_GLIBCXX20_CONSTEXPR
inline bool
is_sorted(_ForwardIterator __first, _ForwardIterator __last)
{ return std::is_sorted_until(__first, __last) == __last; }

It should be optimized to

  template
_GLIBCXX20_CONSTEXPR
inline bool
is_sorted(_ForwardIterator __first, _ForwardIterator __last)
{ 
   if
constexpr(contiguous_iterator<_ForwardIterator>&&!is_pointer_v<_ForwardIterator>)
{
   return is_sorted(to_address(__first),to_address(__last));
}
else
{
 return std::is_sorted_until(__first, __last) == __last; 
}
 }

[PATCH] RISC-V: Support (set (mem) (const_poly_int))

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Adjust using force_reg.

---
 gcc/config/riscv/riscv.cc | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 98374a922d1..1fd34f6ae8d 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1967,9 +1967,7 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
   */
   if (MEM_P (dest))
{
- rtx tmp = gen_reg_rtx (mode);
- emit_move_insn (tmp, src);
- emit_move_insn (dest, tmp);
+ emit_move_insn (dest, force_reg (mode, src));
  return true;
}
   poly_int64 value = rtx_to_poly_int64 (src);
-- 
2.36.1

Re: [PATCH] RISC-V: Replace CONSTEXPR with constexpr

[Kito Cheng via Gcc-patches]

Committed, thanks!

On Mon, Oct 24, 2022 at 10:21 AM  wrote:
>
> From: Ju-Zhe Zhong 
>
> Move away from the pre-C++11 compatibility macro CONSTEXPR.
> This patch is inspired by aarch64:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603974.html.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins-bases.cc: Replace CONSTEXPR
> with constexpr throughout.
> * config/riscv/riscv-vector-builtins-shapes.cc (SHAPE): Likewise.
> * config/riscv/riscv-vector-builtins.cc (struct 
> registered_function_hasher): Likewise.
> * config/riscv/riscv-vector-builtins.h (struct rvv_arg_type_info): 
> Likewise.
>
> ---
>  gcc/config/riscv/riscv-vector-builtins-bases.cc  |  4 ++--
>  gcc/config/riscv/riscv-vector-builtins-shapes.cc |  2 +-
>  gcc/config/riscv/riscv-vector-builtins.cc| 14 +++---
>  gcc/config/riscv/riscv-vector-builtins.h |  2 +-
>  4 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
> b/gcc/config/riscv/riscv-vector-builtins-bases.cc
> index 231b63a610d..713a7566e29 100644
> --- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
> +++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
> @@ -84,8 +84,8 @@ public:
>}
>  };
>
> -static CONSTEXPR const vsetvl vsetvl_obj;
> -static CONSTEXPR const vsetvl vsetvlmax_obj;
> +static constexpr const vsetvl vsetvl_obj;
> +static constexpr const vsetvl vsetvlmax_obj;
>  namespace bases {
>  const function_base *const vsetvl = _obj;
>  const function_base *const vsetvlmax = _obj;
> diff --git a/gcc/config/riscv/riscv-vector-builtins-shapes.cc 
> b/gcc/config/riscv/riscv-vector-builtins-shapes.cc
> index 24fc1c02341..14c59690c06 100644
> --- a/gcc/config/riscv/riscv-vector-builtins-shapes.cc
> +++ b/gcc/config/riscv/riscv-vector-builtins-shapes.cc
> @@ -71,7 +71,7 @@ build_all (function_builder , const function_group_info 
> )
>  /* Declare the function shape NAME, pointing it to an instance
> of class _def.  */
>  #define SHAPE(DEF, VAR) \
> -  static CONSTEXPR const DEF##_def VAR##_obj; \
> +  static constexpr const DEF##_def VAR##_obj; \
>namespace shapes { const function_shape *const VAR = ##_obj; }
>
>  /* Base class for for build.  */
> diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
> b/gcc/config/riscv/riscv-vector-builtins.cc
> index dc410788c99..caeb97211f9 100644
> --- a/gcc/config/riscv/riscv-vector-builtins.cc
> +++ b/gcc/config/riscv/riscv-vector-builtins.cc
> @@ -88,7 +88,7 @@ struct registered_function_hasher : 
> nofree_ptr_hash
>  };
>
>  /* Static information about each RVV type.  */
> -static CONSTEXPR const vector_type_info vector_types[] = {
> +static constexpr const vector_type_info vector_types[] = {
>  #define DEF_RVV_TYPE(NAME, NCHARS, ABI_NAME, ARGS...)
>   \
>{#NAME, #ABI_NAME, "u" #NCHARS #ABI_NAME},
>  #include "riscv-vector-builtins.def"
> @@ -123,23 +123,23 @@ static const rvv_type_info i_ops[] = {
>  #include "riscv-vector-builtins-types.def"
>{NUM_VECTOR_TYPES, 0}};
>
> -static CONSTEXPR const rvv_arg_type_info rvv_arg_type_info_end
> +static constexpr const rvv_arg_type_info rvv_arg_type_info_end
>= rvv_arg_type_info (NUM_BASE_TYPES);
>
>  /* A list of args for size_t func (void) function.  */
> -static CONSTEXPR const rvv_arg_type_info void_args[]
> +static constexpr const rvv_arg_type_info void_args[]
>= {rvv_arg_type_info (RVV_BASE_void), rvv_arg_type_info_end};
>
>  /* A list of args for size_t func (size_t) function.  */
> -static CONSTEXPR const rvv_arg_type_info size_args[]
> +static constexpr const rvv_arg_type_info size_args[]
>= {rvv_arg_type_info (RVV_BASE_size), rvv_arg_type_info_end};
>
>  /* A list of none preds that will be registered for intrinsic functions.  */
> -static CONSTEXPR const predication_type_index none_preds[]
> +static constexpr const predication_type_index none_preds[]
>= {PRED_TYPE_none, NUM_PRED_TYPES};
>
>  /* A static operand information for size_t func (void) function 
> registration. */
> -static CONSTEXPR const rvv_op_info i_none_size_void_ops
> +static constexpr const rvv_op_info i_none_size_void_ops
>= {i_ops,/* Types */
>   OP_TYPE_none, /* Suffix */
>   rvv_arg_type_info (RVV_BASE_size), /* Return type */
> @@ -147,7 +147,7 @@ static CONSTEXPR const rvv_op_info i_none_size_void_ops
>
>  /* A static operand information for size_t func (size_t) function 
> registration.
>   */
> -static CONSTEXPR const rvv_op_info i_none_size_size_ops
> +static constexpr const rvv_op_info i_none_size_size_ops
>= {i_ops,/* Types */
>   OP_TYPE_none, /* Suffix */
>   rvv_arg_type_info (RVV_BASE_size), /* Return type */
> diff --git a/gcc/config/riscv/riscv-vector-builtins.h 
> b/gcc/config/riscv/riscv-vector-builtins.h
> index 425da12326c..e5636e23a7c 100644
> --- 

Re: Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int))

[juzhe.zh...@rivai.ai]

Address comments. Fix it soon.



juzhe.zh...@rivai.ai
 
From: Andrew Pinski
Date: 2022-10-24 10:14
To: juzhe.zhong
CC: gcc-patches; kito.cheng
Subject: Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int))
On Sun, Oct 23, 2022 at 7:04 PM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
> (const_poly_int)).
>
> ---
>  gcc/config/riscv/riscv.cc | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 90a39047dd7..f7694ba043c 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, 
> rtx src)
>  {
>if (CONST_POLY_INT_P (src))
>  {
> +  /*
> +   Handle:
> + (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
> + (const_int 96 [0x60])) [0  S1 A8])
> + (const_poly_int:QI [8, 8]))
> +   "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
> +  */
> +  if (MEM_P (dest))
> +   {
> + rtx tmp = gen_reg_rtx (mode);
> + emit_move_insn (tmp, src);
> + emit_move_insn (dest, tmp);
 
Couldn't you just use force_reg here instead of the above?
Something like:
emit_move_insn (dest, force_reg (mode, src));
 
Thanks,
Andrew Pinski
 
> + return true;
> +   }
>poly_int64 value = rtx_to_poly_int64 (src);
>if (!value.is_constant () && !TARGET_VECTOR)
> {
> --
> 2.36.1
>
 

Re: [PATCH] RISC-V: Remove unused TI/TF vector modes.

[Kito Cheng via Gcc-patches]

Committed, thanks :)

On Mon, Oct 24, 2022 at 10:06 AM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-switch.def (ENTRY): Remove unused TI/TF 
> vector modes.
>
> ---
>  gcc/config/riscv/riscv-vector-switch.def | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/gcc/config/riscv/riscv-vector-switch.def 
> b/gcc/config/riscv/riscv-vector-switch.def
> index cacfccb6d29..ee8ebd5f1cc 100644
> --- a/gcc/config/riscv/riscv-vector-switch.def
> +++ b/gcc/config/riscv/riscv-vector-switch.def
> @@ -155,10 +155,6 @@ ENTRY (VNx4DF, TARGET_VECTOR_FP64)
>  ENTRY (VNx2DF, TARGET_VECTOR_FP64)
>  ENTRY (VNx1DF, TARGET_VECTOR_FP64)
>
> -/* SEW = 128. Disable all of them.  */
> -ENTRY (VNx2TI, false)
> -ENTRY (VNx2TF, false)
> -
>  #undef TARGET_VECTOR_FP32
>  #undef TARGET_VECTOR_FP64
>  #undef ENTRY
> --
> 2.36.1
>

[PATCH] RISC-V: Replace CONSTEXPR with constexpr

[juzhe . zhong]

From: Ju-Zhe Zhong 

Move away from the pre-C++11 compatibility macro CONSTEXPR.
This patch is inspired by aarch64:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603974.html.

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins-bases.cc: Replace CONSTEXPR
with constexpr throughout.
* config/riscv/riscv-vector-builtins-shapes.cc (SHAPE): Likewise.
* config/riscv/riscv-vector-builtins.cc (struct 
registered_function_hasher): Likewise.
* config/riscv/riscv-vector-builtins.h (struct rvv_arg_type_info): 
Likewise.

---
 gcc/config/riscv/riscv-vector-builtins-bases.cc  |  4 ++--
 gcc/config/riscv/riscv-vector-builtins-shapes.cc |  2 +-
 gcc/config/riscv/riscv-vector-builtins.cc| 14 +++---
 gcc/config/riscv/riscv-vector-builtins.h |  2 +-
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc 
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 231b63a610d..713a7566e29 100644
--- a/gcc/config/riscv/riscv-vector-builtins-bases.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-bases.cc
@@ -84,8 +84,8 @@ public:
   }
 };
 
-static CONSTEXPR const vsetvl vsetvl_obj;
-static CONSTEXPR const vsetvl vsetvlmax_obj;
+static constexpr const vsetvl vsetvl_obj;
+static constexpr const vsetvl vsetvlmax_obj;
 namespace bases {
 const function_base *const vsetvl = _obj;
 const function_base *const vsetvlmax = _obj;
diff --git a/gcc/config/riscv/riscv-vector-builtins-shapes.cc 
b/gcc/config/riscv/riscv-vector-builtins-shapes.cc
index 24fc1c02341..14c59690c06 100644
--- a/gcc/config/riscv/riscv-vector-builtins-shapes.cc
+++ b/gcc/config/riscv/riscv-vector-builtins-shapes.cc
@@ -71,7 +71,7 @@ build_all (function_builder , const function_group_info 
)
 /* Declare the function shape NAME, pointing it to an instance
of class _def.  */
 #define SHAPE(DEF, VAR) \
-  static CONSTEXPR const DEF##_def VAR##_obj; \
+  static constexpr const DEF##_def VAR##_obj; \
   namespace shapes { const function_shape *const VAR = ##_obj; }
 
 /* Base class for for build.  */
diff --git a/gcc/config/riscv/riscv-vector-builtins.cc 
b/gcc/config/riscv/riscv-vector-builtins.cc
index dc410788c99..caeb97211f9 100644
--- a/gcc/config/riscv/riscv-vector-builtins.cc
+++ b/gcc/config/riscv/riscv-vector-builtins.cc
@@ -88,7 +88,7 @@ struct registered_function_hasher : 
nofree_ptr_hash
 };
 
 /* Static information about each RVV type.  */
-static CONSTEXPR const vector_type_info vector_types[] = {
+static constexpr const vector_type_info vector_types[] = {
 #define DEF_RVV_TYPE(NAME, NCHARS, ABI_NAME, ARGS...)  
\
   {#NAME, #ABI_NAME, "u" #NCHARS #ABI_NAME},
 #include "riscv-vector-builtins.def"
@@ -123,23 +123,23 @@ static const rvv_type_info i_ops[] = {
 #include "riscv-vector-builtins-types.def"
   {NUM_VECTOR_TYPES, 0}};
 
-static CONSTEXPR const rvv_arg_type_info rvv_arg_type_info_end
+static constexpr const rvv_arg_type_info rvv_arg_type_info_end
   = rvv_arg_type_info (NUM_BASE_TYPES);
 
 /* A list of args for size_t func (void) function.  */
-static CONSTEXPR const rvv_arg_type_info void_args[]
+static constexpr const rvv_arg_type_info void_args[]
   = {rvv_arg_type_info (RVV_BASE_void), rvv_arg_type_info_end};
 
 /* A list of args for size_t func (size_t) function.  */
-static CONSTEXPR const rvv_arg_type_info size_args[]
+static constexpr const rvv_arg_type_info size_args[]
   = {rvv_arg_type_info (RVV_BASE_size), rvv_arg_type_info_end};
 
 /* A list of none preds that will be registered for intrinsic functions.  */
-static CONSTEXPR const predication_type_index none_preds[]
+static constexpr const predication_type_index none_preds[]
   = {PRED_TYPE_none, NUM_PRED_TYPES};
 
 /* A static operand information for size_t func (void) function registration. 
*/
-static CONSTEXPR const rvv_op_info i_none_size_void_ops
+static constexpr const rvv_op_info i_none_size_void_ops
   = {i_ops,/* Types */
  OP_TYPE_none, /* Suffix */
  rvv_arg_type_info (RVV_BASE_size), /* Return type */
@@ -147,7 +147,7 @@ static CONSTEXPR const rvv_op_info i_none_size_void_ops
 
 /* A static operand information for size_t func (size_t) function registration.
  */
-static CONSTEXPR const rvv_op_info i_none_size_size_ops
+static constexpr const rvv_op_info i_none_size_size_ops
   = {i_ops,/* Types */
  OP_TYPE_none, /* Suffix */
  rvv_arg_type_info (RVV_BASE_size), /* Return type */
diff --git a/gcc/config/riscv/riscv-vector-builtins.h 
b/gcc/config/riscv/riscv-vector-builtins.h
index 425da12326c..e5636e23a7c 100644
--- a/gcc/config/riscv/riscv-vector-builtins.h
+++ b/gcc/config/riscv/riscv-vector-builtins.h
@@ -171,7 +171,7 @@ struct rvv_builtin_suffixes
 /* RVV Builtin argument information.  */
 struct rvv_arg_type_info
 {
-  CONSTEXPR rvv_arg_type_info (rvv_base_type base_type_in)
+  constexpr 

Re: [PATCH] RISC-V: Fix REG_CLASS_CONTENTS.

[Kito Cheng via Gcc-patches]

Committed, thanks for the fix!

On Mon, Oct 24, 2022 at 9:39 AM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.h (enum reg_class): Fix ALL_REGS.
>
> ---
>  gcc/config/riscv/riscv.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> index acae68ebb2d..37363e975e1 100644
> --- a/gcc/config/riscv/riscv.h
> +++ b/gcc/config/riscv/riscv.h
> @@ -516,7 +516,7 @@ enum reg_class
>{ 0x, 0x, 0x, 0x0001 },  /* V0_REGS */ 
>   \
>{ 0x, 0x, 0x, 0xfffe },  /* VNoV0_REGS */  
>   \
>{ 0x, 0x, 0x, 0x },  /* V_REGS */  
>   \
> -  { 0x, 0x, 0x0003, 0x }   /* ALL_REGS */
>   \
> +  { 0x, 0x, 0x000f, 0x }   /* ALL_REGS */
>   \
>  }
>
>  /* A C expression whose value is a register class containing hard
> --
> 2.36.1
>

Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int))

[Andrew Pinski via Gcc-patches]

On Sun, Oct 23, 2022 at 7:04 PM  wrote:
>
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
> (const_poly_int)).
>
> ---
>  gcc/config/riscv/riscv.cc | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 90a39047dd7..f7694ba043c 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, 
> rtx src)
>  {
>if (CONST_POLY_INT_P (src))
>  {
> +  /*
> +   Handle:
> + (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
> + (const_int 96 [0x60])) [0  S1 A8])
> + (const_poly_int:QI [8, 8]))
> +   "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
> +  */
> +  if (MEM_P (dest))
> +   {
> + rtx tmp = gen_reg_rtx (mode);
> + emit_move_insn (tmp, src);
> + emit_move_insn (dest, tmp);

Couldn't you just use force_reg here instead of the above?
Something like:
emit_move_insn (dest, force_reg (mode, src));

Thanks,
Andrew Pinski

> + return true;
> +   }
>poly_int64 value = rtx_to_poly_int64 (src);
>if (!value.is_constant () && !TARGET_VECTOR)
> {
> --
> 2.36.1
>

[PATCH] RISC-V: Support load/store in mov pattern for RVV modes.

[juzhe . zhong]

From: Ju-Zhe Zhong 

---
 gcc/config.gcc|   2 +-
 gcc/config/riscv/constraints.md   |  22 +
 gcc/config/riscv/predicates.md|  23 ++
 gcc/config/riscv/riscv-protos.h   |  14 +
 gcc/config/riscv/riscv-v.cc   | 180 
 .../riscv/riscv-vector-builtins-bases.cc  |  14 +-
 gcc/config/riscv/riscv.cc |  67 ++-
 gcc/config/riscv/riscv.h  |   2 +
 gcc/config/riscv/riscv.md |   9 +-
 gcc/config/riscv/t-riscv  |   4 +
 gcc/config/riscv/vector-iterators.md  |  58 +++
 gcc/config/riscv/vector.md| 279 -
 .../gcc.target/riscv/rvv/base/mov-1.c | 179 
 .../gcc.target/riscv/rvv/base/mov-10.c| 385 ++
 .../gcc.target/riscv/rvv/base/mov-11.c| 385 ++
 .../gcc.target/riscv/rvv/base/mov-12.c| 159 
 .../gcc.target/riscv/rvv/base/mov-13.c|  14 +
 .../gcc.target/riscv/rvv/base/mov-2.c | 153 +++
 .../gcc.target/riscv/rvv/base/mov-3.c | 127 ++
 .../gcc.target/riscv/rvv/base/mov-4.c | 101 +
 .../gcc.target/riscv/rvv/base/mov-5.c |  66 +++
 .../gcc.target/riscv/rvv/base/mov-6.c |  53 +++
 .../gcc.target/riscv/rvv/base/mov-7.c |  13 +
 .../gcc.target/riscv/rvv/base/mov-8.c |  96 +
 .../gcc.target/riscv/rvv/base/mov-9.c |  44 ++
 25 files changed, 2421 insertions(+), 28 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-v.cc
 create mode 100644 gcc/config/riscv/vector-iterators.md
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-10.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-11.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-12.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-13.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-7.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-8.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/mov-9.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3826ae42803..0232e572a99 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -515,7 +515,7 @@ pru-*-*)
;;
 riscv*)
cpu_type=riscv
-   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
riscv-shorten-memrefs.o riscv-selftests.o"
+   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
riscv-shorten-memrefs.o riscv-selftests.o riscv-v.o"
extra_objs="${extra_objs} riscv-vector-builtins.o 
riscv-vector-builtins-shapes.o riscv-vector-builtins-bases.o"
d_target_objs="riscv-d.o"
extra_headers="riscv_vector.h"
diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
index 8997284f32e..951dcc52d6b 100644
--- a/gcc/config/riscv/constraints.md
+++ b/gcc/config/riscv/constraints.md
@@ -128,3 +128,25 @@
   "POLY_INT"
   (and (match_code "const_poly_int")
(match_test "known_eq (rtx_to_poly_int64 (op), 
BYTES_PER_RISCV_VECTOR)")))
+
+(define_constraint "vu"
+  "A undefined vector value."
+  (and (match_code "unspec")
+   (match_test "XINT (op, 1) == UNSPEC_VUNDEF")))
+
+(define_constraint "vi"
+  "A vector 5-bit signed immediate."
+  (and (match_code "const_vector")
+   (match_test "riscv_vector::const_vec_all_same_in_range_p (op, -16, 
15)")))
+
+(define_constraint "Wc0"
+  "@internal
+ A constraint that matches a vector of immediate all zeros."
+ (and (match_code "const_vector")
+  (match_test "op == CONST0_RTX (GET_MODE (op))")))
+
+(define_constraint "Wc1"
+  "@internal
+ A constraint that matches a vector of immediate all ones."
+ (and (match_code "const_vector")
+  (match_test "op == CONSTM1_RTX (GET_MODE (op))")))
diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index 5e149b3a95f..e2bfafe8150 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -262,3 +262,26 @@
 
return true;
 })
+
+;; Predicates for the V extension.
+(define_special_predicate "vector_length_operand"
+  (ior (match_operand 0 "pmode_register_operand")
+   (match_operand 0 "const_csr_operand")))
+
+(define_predicate "reg_or_mem_operand"
+  (ior (match_operand 0 "register_operand")
+   (match_operand 0 "memory_operand")))
+
+(define_predicate "vector_move_operand"
+  (ior (match_operand 0 "nonimmediate_operand")
+   (match_code "const_vector")))
+
+(define_predicate "vector_mask_operand"
+  (ior (match_operand 0 "register_operand")

[PATCH] RISC-V: Remove unused TI/TF vector modes.

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv-vector-switch.def (ENTRY): Remove unused TI/TF 
vector modes.

---
 gcc/config/riscv/riscv-vector-switch.def | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-switch.def 
b/gcc/config/riscv/riscv-vector-switch.def
index cacfccb6d29..ee8ebd5f1cc 100644
--- a/gcc/config/riscv/riscv-vector-switch.def
+++ b/gcc/config/riscv/riscv-vector-switch.def
@@ -155,10 +155,6 @@ ENTRY (VNx4DF, TARGET_VECTOR_FP64)
 ENTRY (VNx2DF, TARGET_VECTOR_FP64)
 ENTRY (VNx1DF, TARGET_VECTOR_FP64)
 
-/* SEW = 128. Disable all of them.  */
-ENTRY (VNx2TI, false)
-ENTRY (VNx2TF, false)
-
 #undef TARGET_VECTOR_FP32
 #undef TARGET_VECTOR_FP64
 #undef ENTRY
-- 
2.36.1

[PATCH] RISC-V: Support (set (mem) (const_poly_int))

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
(const_poly_int)).

---
 gcc/config/riscv/riscv.cc | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 90a39047dd7..f7694ba043c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
 {
   if (CONST_POLY_INT_P (src))
 {
+  /*
+   Handle:
+ (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
+ (const_int 96 [0x60])) [0  S1 A8])
+ (const_poly_int:QI [8, 8]))
+   "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
+  */
+  if (MEM_P (dest))
+   {
+ rtx tmp = gen_reg_rtx (mode);
+ emit_move_insn (tmp, src);
+ emit_move_insn (dest, tmp);
+ return true;
+   }
   poly_int64 value = rtx_to_poly_int64 (src);
   if (!value.is_constant () && !TARGET_VECTOR)
{
-- 
2.36.1

Re: [PATCH] RISC-V: Support (set (mem) (const_poly_int)) handling and remove TI/TF.

[juzhe.zh...@rivai.ai]

I made a mistake in this patch. I mixed 2 commits into a single patch.
Sorry about that. Please ignore this patch. Thanks.



juzhe.zh...@rivai.ai
 
From: juzhe.zhong
Date: 2022-10-24 09:53
To: gcc-patches
CC: kito.cheng; palmer; Ju-Zhe Zhong
Subject: [PATCH] RISC-V: Support (set (mem) (const_poly_int)) handling and 
remove TI/TF.
From: Ju-Zhe Zhong 
 
gcc/ChangeLog:
 
* config/riscv/riscv-vector-switch.def (ENTRY): Remove TI/TF.
* config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
(const_poly_int)).
 
---
gcc/config/riscv/riscv-vector-switch.def |  4 
gcc/config/riscv/riscv.cc| 14 ++
2 files changed, 14 insertions(+), 4 deletions(-)
 
diff --git a/gcc/config/riscv/riscv-vector-switch.def 
b/gcc/config/riscv/riscv-vector-switch.def
index cacfccb6d29..ee8ebd5f1cc 100644
--- a/gcc/config/riscv/riscv-vector-switch.def
+++ b/gcc/config/riscv/riscv-vector-switch.def
@@ -155,10 +155,6 @@ ENTRY (VNx4DF, TARGET_VECTOR_FP64)
ENTRY (VNx2DF, TARGET_VECTOR_FP64)
ENTRY (VNx1DF, TARGET_VECTOR_FP64)
-/* SEW = 128. Disable all of them.  */
-ENTRY (VNx2TI, false)
-ENTRY (VNx2TF, false)
-
#undef TARGET_VECTOR_FP32
#undef TARGET_VECTOR_FP64
#undef ENTRY
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 90a39047dd7..f7694ba043c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
{
   if (CONST_POLY_INT_P (src))
 {
+  /*
+ Handle:
+   (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
+   (const_int 96 [0x60])) [0  S1 A8])
+   (const_poly_int:QI [8, 8]))
+ "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
+  */
+  if (MEM_P (dest))
+ {
+   rtx tmp = gen_reg_rtx (mode);
+   emit_move_insn (tmp, src);
+   emit_move_insn (dest, tmp);
+   return true;
+ }
   poly_int64 value = rtx_to_poly_int64 (src);
   if (!value.is_constant () && !TARGET_VECTOR)
{
-- 
2.36.1
 

[PATCH] RISC-V: Support (set (mem) (const_poly_int)) handling and remove TI/TF.

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv-vector-switch.def (ENTRY): Remove TI/TF.
* config/riscv/riscv.cc (riscv_legitimize_move): Support (set (mem) 
(const_poly_int)).

---
 gcc/config/riscv/riscv-vector-switch.def |  4 
 gcc/config/riscv/riscv.cc| 14 ++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/gcc/config/riscv/riscv-vector-switch.def 
b/gcc/config/riscv/riscv-vector-switch.def
index cacfccb6d29..ee8ebd5f1cc 100644
--- a/gcc/config/riscv/riscv-vector-switch.def
+++ b/gcc/config/riscv/riscv-vector-switch.def
@@ -155,10 +155,6 @@ ENTRY (VNx4DF, TARGET_VECTOR_FP64)
 ENTRY (VNx2DF, TARGET_VECTOR_FP64)
 ENTRY (VNx1DF, TARGET_VECTOR_FP64)
 
-/* SEW = 128. Disable all of them.  */
-ENTRY (VNx2TI, false)
-ENTRY (VNx2TF, false)
-
 #undef TARGET_VECTOR_FP32
 #undef TARGET_VECTOR_FP64
 #undef ENTRY
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 90a39047dd7..f7694ba043c 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1958,6 +1958,20 @@ riscv_legitimize_move (machine_mode mode, rtx dest, rtx 
src)
 {
   if (CONST_POLY_INT_P (src))
 {
+  /*
+   Handle:
+ (insn 183 182 184 6 (set (mem:QI (plus:DI (reg/f:DI 156)
+ (const_int 96 [0x60])) [0  S1 A8])
+ (const_poly_int:QI [8, 8]))
+   "../../../../riscv-gcc/libgcc/unwind-dw2.c":1579:3 -1 (nil))
+  */
+  if (MEM_P (dest))
+   {
+ rtx tmp = gen_reg_rtx (mode);
+ emit_move_insn (tmp, src);
+ emit_move_insn (dest, tmp);
+ return true;
+   }
   poly_int64 value = rtx_to_poly_int64 (src);
   if (!value.is_constant () && !TARGET_VECTOR)
{
-- 
2.36.1

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 13:09, Frank Ch. Eigler wrote:

[...]  To be specific, gcc steering committee and glibc FSF stewards
have announced the decision for their projects [...]


I may be missing something.  All I've seen so far were some of the
leaders of some of the projects being joint signatories to a letter on
overseers@.  As far as I'm aware, that is not how any of these
projects make or announce **project decisions** with/to their
respective constituencies.


Fair enough.


I am not aware of any opposition from maintainers of libabigail or
cygwin or any other active sourceware based project over moving
either, but I haven't had any links to those projects, so I may be
uninformed.


Indeed.  The onus is obviously on the shoulders of the proponents of
this proposal to convince each sourceware guest project to consent to
move.  If you wish to frame any dissent as "blocking full migration",
then I'd say the job of convincing everyone just has not been up to
par.  Perhaps it was the wrong goal all along.


Are you saying then that your dissent so far is as maintainer for 
systemtap and not as an overseer?


Sid

[PATCH] RISC-V: Fix REG_CLASS_CONTENTS.

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/riscv.h (enum reg_class): Fix ALL_REGS.

---
 gcc/config/riscv/riscv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index acae68ebb2d..37363e975e1 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -516,7 +516,7 @@ enum reg_class
   { 0x, 0x, 0x, 0x0001 },  /* V0_REGS */   
\
   { 0x, 0x, 0x, 0xfffe },  /* VNoV0_REGS */
\
   { 0x, 0x, 0x, 0x },  /* V_REGS */
\
-  { 0x, 0x, 0x0003, 0x }   /* ALL_REGS */  
\
+  { 0x, 0x, 0x000f, 0x }   /* ALL_REGS */  
\
 }
 
 /* A C expression whose value is a register class containing hard
-- 
2.36.1

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 17:59, Christopher Faylor wrote:

On Sun, Oct 23, 2022 at 05:17:40PM -0400, Siddhesh Poyarekar wrote:

On 2022-10-23 16:57, Christopher Faylor wrote:

On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:

Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html

On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:

The GNU Toolchain project leadership supports the proposal[1] to move the
services for the GNU Toolchain to the Linux Foundation IT under the auspices of
the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the
OpenSSF and other major donors.


Noted, however, a list of signatories does not automatically confer
authority over any particular project.  Any participation from
overseers in moving projects to different infrastructure will require
clear approval from the individual projects themselves.

Also, the FSF, being the existing fiscal sponsor to these projects,
surely needs to review the formal agreements before we sunset our
infrastructural offerings to glibc, gcc, binutils, and gdb and hand
control of the projects' infrastructure over to a different entity.

We'd like to assure the communities that, when and if any individual
project formally expresses the decision of their developers to transfer
their services, we'll endeavor to make the move as smooth as possible.
Those projects that wish to stay will continue to receive the best
services that the overseers can offer, with the ongoing assistance of
Red Hat, the SFC, and, when relevant, the FSF tech team.


On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote:

Given that the current sourceware admins have decided to block migration of
all sourceware assets to the LF IT, I don't have a stake on how they'd like
to handle this for sourceware.  I could however, as a member of TAC (and as
member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc),
discuss with others the possibility of specific community volunteers being
given some amount of access to manage infrastructure.


Stop spreading FUD.  The "we" in my statement above, from October 13,
included fche, mjw, and myself.  You have no reason to be confused on
this subject.



Nope, I'm not spreading FUD, in fact that statement of yours is perfectly
consistent with what I've said: the blocker at the moment is that the
sourceware overseers have refused to hand over the server *in its entirety*
to LF IT, not that any projects themselves have refused to move their
services to LF IT.  I don't doubt that the overseers will help in smooth
migration for projects that eventually state that they wish to move over.


Your initial implication was that the unreasonable overseers would hold
all projects hostage on our current infrastructure.   


Absolutely not, you and I have had multiple exchanges on this list so 
far and I'd have trusted you to take my statement above in the correct 
context.  I did not even negate your statement when you stated that the 
overseers would support seamless migration of services over to LF IT and 
in fact supplemented[1] by saying that the transition would likely take 
years.



Now you've "clarified"
that point by implying that we've been approached to transfer the server
"in its entirety" to the LF and have unreasonably refused.


You literally have an email on the list with the subject like "Moving 
sourceware to the Linux Foundation? no thanks".



Both of those are FUD.  You're either intentionally trying to muddy the
waters or you're just confused.  I'd submit that in either case you should
just think about shutting up.  You have no special authority to speak for
the GTI TAC and your increasingly hostile messages are not helping anyone.


It's funny that you're asking me to shut up and also implying that my 
messages are hostile.


Sid

[1] https://sourceware.org/pipermail/overseers/2022q4/018987.html

[PATCH] Add -gcodeview option

[Mark Harmstone]

Both current lld and the next version of ld have an option -pdb, which
creates a PDB file which Microsoft's debuggers can use. This patch adds
a -gcodeview option, which passes this to the linker.

I do intend to expand this so it also creates the .debug$S and .debug$T
sections which would make this useful - I submitted patches for this a
while back, but they need to be rewritten to parse the DWARF DIEs rather
than using debug_hooks.

Clang also has -gcodeview, but AFAICS only uses it for .debug$S and
.debug$T, and doesn't use it for linker options (though IMO it probably
should).

---
 gcc/common.opt  | 4 
 gcc/doc/invoke.texi | 7 +++
 gcc/gcc.cc  | 4 
 gcc/opts.cc | 3 +++
 4 files changed, 18 insertions(+)

diff --git a/gcc/common.opt b/gcc/common.opt
index 8a0dafc522d..77103f961d8 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -3253,6 +3253,10 @@ gas-locview-support
 Common Driver Var(dwarf2out_as_locview_support)
 Assume assembler support for view in (DWARF2+) .loc directives.
 
+gcodeview
+Common Driver JoinedOrMissing
+Generate debug information in CodeView format.
+
 gcoff
 Common Driver WarnRemoved
 Does nothing.  Preserved for backward compatibility.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ff6c338bedb..2d29fd2611d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -483,6 +483,7 @@ Objective-C and Objective-C++ Dialects}.
 -gstabs  -gstabs+  -gstrict-dwarf  -gno-strict-dwarf @gol
 -gas-loc-support  -gno-as-loc-support @gol
 -gas-locview-support  -gno-as-locview-support @gol
+-gcodeview @gol
 -gcolumn-info  -gno-column-info  -gdwarf32  -gdwarf64 @gol
 -gstatement-frontiers  -gno-statement-frontiers @gol
 -gvariable-location-views  -gno-variable-location-views @gol
@@ -10358,6 +10359,12 @@ assembler (GAS) to fail with an error.
 Produce debugging information in Alpha/VMS debug format (if that is
 supported).  This is the format used by DEBUG on Alpha/VMS systems.
 
+@item -gcodeview
+@opindex gcodeview
+Produce debugging information in CodeView debug format (if that is
+supported).  This is the format used by Microsoft Visual C++ on
+Windows.
+
 @item -g@var{level}
 @itemx -ggdb@var{level}
 @itemx -gstabs@var{level}
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index bb07cc244e3..2820f325282 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -4608,6 +4608,10 @@ driver_handle_option (struct gcc_options *opts,
   do_save = false;
   break;
 
+case OPT_gcodeview:
+  add_infile ("-pdb=", "*");
+  break;
+
 default:
   /* Various driver options need no special processing at this
 point, having been handled in a prescan above or being
diff --git a/gcc/opts.cc b/gcc/opts.cc
index 3a89da2dd03..e2633ee5439 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -3089,6 +3089,9 @@ common_handle_option (struct gcc_options *opts,
   set_debug_level (NO_DEBUG, 2, arg, opts, opts_set, loc);
   break;
 
+case OPT_gcodeview:
+  break;
+
 case OPT_gstabs:
 case OPT_gstabs_:
   set_debug_level (DBX_DEBUG, code == OPT_gstabs_, arg, opts, opts_set,
-- 
2.37.3

[Bug middle-end/106081] missed vectorization

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/107364] [10/11/12/13 Regression] ICE on Via Nehemiah with --march=native

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364

Andrew Pinski  changed:

   What|Removed |Added

   Host|X86_64  |i?86-linux-gnu
   Keywords||ice-on-valid-code
   Target Milestone|--- |10.5
Summary|ICE on Via Nehemiah with|[10/11/12/13 Regression]
   |--march=native  |ICE on Via Nehemiah with
   ||--march=native
  Build|X86_64  |i?86-linux-gnu
 Target|X86_64  |i?86-linux-gnu

[Bug c++/107361] Why does -Wclass-memaccess require trivial types, instead of trivially-copyable types?

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107361

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/legacy-ml/gcc-patches/2017-04/msg01571.html

gcc-13-20221023 is now available

[GCC Administrator via Gcc]

Snapshot gcc-13-20221023 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/13-20221023/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 0e37fd4dc74c1db99cdc7d71ef378e1221253c6f

You'll find:

 gcc-13-20221023.tar.xz   Complete GCC

  SHA256=db7beb9c2c36fa96028d62337c0a1e599dae20ead34e1acebdf14fe7ee922d4e
  SHA1=744a825a2297ef609438c4d8eea4cde914d4e7da

Diffs from 13-20221016 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-13
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

On Sun, Oct 23, 2022 at 11:01:34AM -0600, Jeff Law wrote:
>On 10/23/22 10:07, Siddhesh Poyarekar wrote:
>>>If you're trying to suggest that overseers, contrary to our repeated
>>>public statements, wish to block all migration, that is untrue and you
>>>will need to retract this.
>>
>>Here's a more precise statement: Two of the overseers are leaders of
>>projects hosted on sourceware and three overseers (including those two)
>>have stated clearly on multiple occasions that transitioning to LF IT
>>is off the table, effectively announcing their decision on behalf of
>>projects they lead.  It is hence clear that the overseers have
>>effectively blocked full migration of sourceware to LF IT.
>
>They can make those decisions for the projects they lead.  But making
>the decision or setting criteria for other projects is highly
>unreasonable.

This is not, IMO, helping.

On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:
>We'd like to assure the communities that, when and if any individual
>project formally expresses the decision of their developers to transfer
>their services, we'll endeavor to make the move as smooth as possible.
>Those projects that wish to stay will continue to receive the best
>services that the overseers can offer, with the ongoing assistance of
>Red Hat, the SFC, and, when relevant, the FSF tech team.

We can't help move anyone without first establishing some kind of
criteria.  The only reasonable criteria is a formal request from the
project being moved.

As an exercise in human psychology, these insinuations of anticipated
unhelpfulness *can* eventually be a self-fullfilling prophecy, though.

i.e., if you really do not *want* any help with any transitions of
projects then, just keep implying, despite evidence to the contrary,
that we might be unreasonable jerks.

Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

vv

On Sun, Oct 23, 2022 at 06:19:33PM -0300, Alexandre Oliva wrote:
>It doesn't smell good, however, that Sourceware has been prevented from 
>presenting its own
>expansion plans and proposals at the Cauldron.  I wish it too gets a chance to 
>extend their offer.
>There's no basis for a rational decision in refusing to listen to 
>alternatives; it comes across to
>me as acknowledgment that a weaker proposal wishes to prevail by denying 
>others any consideration.

^^^

Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

On Sun, Oct 23, 2022 at 05:17:40PM -0400, Siddhesh Poyarekar wrote:
>On 2022-10-23 16:57, Christopher Faylor wrote:
>> On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:
>> > Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html
>> > 
>> > On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:
>> > > The GNU Toolchain project leadership supports the proposal[1] to move the
>> > > services for the GNU Toolchain to the Linux Foundation IT under the 
>> > > auspices of
>> > > the Toolchain Infrastructure project (GTI) with fiscal sponsorship from 
>> > > the
>> > > OpenSSF and other major donors.
>> > 
>> > Noted, however, a list of signatories does not automatically confer
>> > authority over any particular project.  Any participation from
>> > overseers in moving projects to different infrastructure will require
>> > clear approval from the individual projects themselves.
>> > 
>> > Also, the FSF, being the existing fiscal sponsor to these projects,
>> > surely needs to review the formal agreements before we sunset our
>> > infrastructural offerings to glibc, gcc, binutils, and gdb and hand
>> > control of the projects' infrastructure over to a different entity.
>> > 
>> > We'd like to assure the communities that, when and if any individual
>> > project formally expresses the decision of their developers to transfer
>> > their services, we'll endeavor to make the move as smooth as possible.
>> > Those projects that wish to stay will continue to receive the best
>> > services that the overseers can offer, with the ongoing assistance of
>> > Red Hat, the SFC, and, when relevant, the FSF tech team.
>> 
>> On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote:
>> > Given that the current sourceware admins have decided to block migration of
>> > all sourceware assets to the LF IT, I don't have a stake on how they'd like
>> > to handle this for sourceware.  I could however, as a member of TAC (and as
>> > member of projects that have agreed to migrate to LF IT, i.e. gcc and 
>> > glibc),
>> > discuss with others the possibility of specific community volunteers being
>> > given some amount of access to manage infrastructure.
>> 
>> Stop spreading FUD.  The "we" in my statement above, from October 13,
>> included fche, mjw, and myself.  You have no reason to be confused on
>> this subject.
>> 
>
>Nope, I'm not spreading FUD, in fact that statement of yours is perfectly
>consistent with what I've said: the blocker at the moment is that the
>sourceware overseers have refused to hand over the server *in its entirety*
>to LF IT, not that any projects themselves have refused to move their
>services to LF IT.  I don't doubt that the overseers will help in smooth
>migration for projects that eventually state that they wish to move over.

Your initial implication was that the unreasonable overseers would hold
all projects hostage on our current infrastructure.   Now you've "clarified"
that point by implying that we've been approached to transfer the server
"in its entirety" to the LF and have unreasonably refused.

Both of those are FUD.  You're either intentionally trying to muddy the
waters or you're just confused.  I'd submit that in either case you should
just think about shutting up.  You have no special authority to speak for
the GTI TAC and your increasingly hostile messages are not helping anyone.

Re: Toolchain Infrastructure project statement of support

[Alexandre Oliva via Gcc]

On Oct 12, 2022, "Carlos O'Donell via Overseers"  
wrote:

> The GNU Toolchain project leadership

Is GNU Toolchain the name of a project?  This term has usually meant a
set of packages that are part of the GNU Project.  Each package has its
own set of maintainers appointed by GNU leadership, each one with a
commitment to advance the goals of the GNU Project through their
maintainership.  GNU Project leadership hasn't been consulted, and the
proposed move appears to be detrimental to the GNU Project, so it
follows that these people are not acting in their capacity of GNU
maintainers.  As such, any kind of leadership and decision-making
arising from these roles must be presumed void and null.

Speaking specifically of the GCC Steering Committee, I quote from the
very first sentence in https://gcc.gnu.org/steering.html

  The steering committee was founded in 1998 with the intent of
  *preventing* *any* particular individual, group or *organization* from
  *getting* *control* *over* *the* *project*.

(highlights are mine)

Turning over control over critical project infrastructure, in a way that
seemingly places the packages under the umbrella of that single
organization, is not in line with the existential reason of the GCC
Steering Committee.  As such, it must follow that the undersigners are
not acting in their capacity of GCC Steering Committee members, which
removes any decision-making weight that might have otherwise been
presumed from them, due to expectations associated with these roles.


That said, I acknowledge that several of them are prominent contributors
to GCC, and the GNU Project is happy to welcome contributions from
anyone willing to help advance its goals (please do not mistake this as
speaking on behalf of the GNU project; I merely state GNU policies and
positions to the extend that I'm familiar with and understand them).
Several others were relevant developers, as I and RMS have been for
quite some time in GNU libc and GCC, respectively.  It's interesting to
see that past contributors can have a voice, but it appears to me that
there has been some bias in the selection of which past voices to
actively seek out, and which to dismiss, that places the legitimacy of
the pronouncement under further doubt.


Anyhow, FWIW, I hereby raise my objection to the proposed outright move
of our infrastructure out of Sourceware and into LF.  I have a different
proposal that is more in line with GNU policies, that GNU maintainers
ought to uphold, and with the stated goals of the GCC SC quoted above.

I wish to be clear on GNU policy of welcoming contributions that help
advance its goals.  I, as contributor to the affected packages, and as
long-time GNU contributor, do not wish GNU to turn down the resources
offered as part of this proposal, any more than I wish GNU to turn down
the resources that have long been made available to us by Sourceware.
There are significant upsides to using both, to increase our autonomy,
rather than jumping from one single point of corporate dependence (AKA
autonomy failure :-) to another.

It seems fine to me, and also welcome, that groups of contributors pool
their individual efforts towards finding resources for the GNU packages
they wish to support.

I have no objection in principle to our relying on these resources, be
they financial or infrastructure, to advance our projects, even if the
governance model of each supporting group is independent from and
unrelated to the governance structure of GNU.  After all, we have no say
in Red Hat's internal governance structure and funding of Sourceware,
and that hasn't stopped and IMHO shouldn't stop us from accepting that
contribution either.  So it shouldn't stop us from accepting
contributions from the LF, even if we have no say in its governance
structure or in the composition of the governing board of the
organization or of the brands and subgroups that would affect directly
their offer to our packages.

As long as the offered resources advance our goals, they are welcome.  I
don't see that an outright move does, but I do see that increased
autonomy and robustness through replication would.

Should any such supporting group at any point in the future take actions
that conflict with our goal, the GNU Project may then turn them down,
and then, as long as critical project infrastructure doesn't make us
hostage, we will be no worse off than if the contributions had never
been offered in the first place, and presumably even a little ahead
because of already-accepted past contributions.

It seems very important, however, that we take steps to guard our own
autonomy, so as to avoid the risks of finding ourselves in such a
hostage situation or of being strongarmed into behaviors we'd not engage
in out of our own volition, and even of having our governance structures
confused, subverted or replaced by misperceptions about the nature of
these supporting structures.

To this end, it appears to me that the reliance on multiple 

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 16:57, Christopher Faylor wrote:

On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:

Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html

On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:

The GNU Toolchain project leadership supports the proposal[1] to move the
services for the GNU Toolchain to the Linux Foundation IT under the auspices of
the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the
OpenSSF and other major donors.


Noted, however, a list of signatories does not automatically confer
authority over any particular project.  Any participation from
overseers in moving projects to different infrastructure will require
clear approval from the individual projects themselves.

Also, the FSF, being the existing fiscal sponsor to these projects,
surely needs to review the formal agreements before we sunset our
infrastructural offerings to glibc, gcc, binutils, and gdb and hand
control of the projects' infrastructure over to a different entity.

We'd like to assure the communities that, when and if any individual
project formally expresses the decision of their developers to transfer
their services, we'll endeavor to make the move as smooth as possible.
Those projects that wish to stay will continue to receive the best
services that the overseers can offer, with the ongoing assistance of
Red Hat, the SFC, and, when relevant, the FSF tech team.


On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote:

Given that the current sourceware admins have decided to block migration of
all sourceware assets to the LF IT, I don't have a stake on how they'd like
to handle this for sourceware.  I could however, as a member of TAC (and as
member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc),
discuss with others the possibility of specific community volunteers being
given some amount of access to manage infrastructure.


Stop spreading FUD.  The "we" in my statement above, from October 13,
included fche, mjw, and myself.  You have no reason to be confused on
this subject.



Nope, I'm not spreading FUD, in fact that statement of yours is 
perfectly consistent with what I've said: the blocker at the moment is 
that the sourceware overseers have refused to hand over the server *in 
its entirety* to LF IT, not that any projects themselves have refused to 
move their services to LF IT.  I don't doubt that the overseers will 
help in smooth migration for projects that eventually state that they 
wish to move over.


Sid

Re: Toolchain Infrastructure project statement of support

[Christopher Faylor via Gcc]

On Thu, Oct 13, 2022 at 02:25:29PM -0400, Christopher Faylor wrote:
>Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html
>
>On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:
>>The GNU Toolchain project leadership supports the proposal[1] to move the
>>services for the GNU Toolchain to the Linux Foundation IT under the auspices 
>>of
>>the Toolchain Infrastructure project (GTI) with fiscal sponsorship from the
>>OpenSSF and other major donors.
>
>Noted, however, a list of signatories does not automatically confer
>authority over any particular project.  Any participation from
>overseers in moving projects to different infrastructure will require
>clear approval from the individual projects themselves.
>
>Also, the FSF, being the existing fiscal sponsor to these projects,
>surely needs to review the formal agreements before we sunset our
>infrastructural offerings to glibc, gcc, binutils, and gdb and hand
>control of the projects' infrastructure over to a different entity.
>
>We'd like to assure the communities that, when and if any individual
>project formally expresses the decision of their developers to transfer
>their services, we'll endeavor to make the move as smooth as possible.
>Those projects that wish to stay will continue to receive the best
>services that the overseers can offer, with the ongoing assistance of
>Red Hat, the SFC, and, when relevant, the FSF tech team.

On Sun, Oct 23, 2022 at 09:27:26AM -0400, Siddhesh Poyarekar wrote:
>Given that the current sourceware admins have decided to block migration of
>all sourceware assets to the LF IT, I don't have a stake on how they'd like
>to handle this for sourceware.  I could however, as a member of TAC (and as
>member of projects that have agreed to migrate to LF IT, i.e. gcc and glibc),
>discuss with others the possibility of specific community volunteers being
>given some amount of access to manage infrastructure.

Stop spreading FUD.  The "we" in my statement above, from October 13,
included fche, mjw, and myself.  You have no reason to be confused on
this subject.

[Bug fortran/105633] ICE in find_array_section, at fortran/expr.cc:1582

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105633

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:910156619c93ff988587762b446542c4dfbb00a2

commit r10-11055-g910156619c93ff988587762b446542c4dfbb00a2
Author: Harald Anlauf 
Date:   Wed Oct 19 22:37:56 2022 +0200

Fortran: error recovery with references of bad array constructors
[PR105633]

gcc/fortran/ChangeLog:

PR fortran/105633
* expr.c (find_array_section): Move check for NULL pointers so
that both subscript triplets and vector subscripts are covered.

gcc/testsuite/ChangeLog:

PR fortran/105633
* gfortran.dg/pr105633.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit ecb20df4fa6d99daa635c7fb662dc0554610777e)

[Bug fortran/105633] ICE in find_array_section, at fortran/expr.cc:1582

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105633

--- Comment #7 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:c6ff6ca2fcefdd5edc37011a2ba8412a466d9b0b

commit r11-10330-gc6ff6ca2fcefdd5edc37011a2ba8412a466d9b0b
Author: Harald Anlauf 
Date:   Wed Oct 19 22:37:56 2022 +0200

Fortran: error recovery with references of bad array constructors
[PR105633]

gcc/fortran/ChangeLog:

PR fortran/105633
* expr.c (find_array_section): Move check for NULL pointers so
that both subscript triplets and vector subscripts are covered.

gcc/testsuite/ChangeLog:

PR fortran/105633
* gfortran.dg/pr105633.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit ecb20df4fa6d99daa635c7fb662dc0554610777e)

[Bug fortran/105633] ICE in find_array_section, at fortran/expr.cc:1582

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105633

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:e3c997824f17dd6a4f7eb8d668b9ed2ef84408fc

commit r12-8860-ge3c997824f17dd6a4f7eb8d668b9ed2ef84408fc
Author: Harald Anlauf 
Date:   Wed Oct 19 22:37:56 2022 +0200

Fortran: error recovery with references of bad array constructors
[PR105633]

gcc/fortran/ChangeLog:

PR fortran/105633
* expr.cc (find_array_section): Move check for NULL pointers so
that both subscript triplets and vector subscripts are covered.

gcc/testsuite/ChangeLog:

PR fortran/105633
* gfortran.dg/pr105633.f90: New test.

Co-authored-by: Steven G. Kargl 
(cherry picked from commit ecb20df4fa6d99daa635c7fb662dc0554610777e)

[Bug fortran/107362] Segfault for recursive class

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107362

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-10-23
   Keywords||compile-time-hog,
   ||ice-on-valid-code
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
This eats a lot of memory until virtual memory is exhausted.

Also likely a duplicate of pr106606.

Re: Toolchain Infrastructure project statement of support

[Konstantin Ryabitsev via Gcc]

On Sun, Oct 23, 2022 at 12:17:36PM -0400, Siddhesh Poyarekar wrote:
> > Let's consider some "established security and administration practices"
> > 
> > curl -v http://vger.kernel.org | head

These are all very fair observations, with one important caveat --
vger.kernel.org is the last remaining piece of kernel.org infrastructure that
is not managed by our team. It's been historically maintained by volunteers
that are not associated with the Linux Foundation (vger used to be hosted at
Red Hat, iirc).

> +Konstantin from LF IT since he's better equipped to speak to this, although
> ISTM that they started migrating off vger last year[1].

Correct, everything is ready for the migration on our end, but we cannot
unilaterally initiate the process. The mail server maintained by the Linux
Foundation is at subspace.kernel.org. I invite you to poke at it to see if it
fares any better compared to vger.

Best wishes,
Konstantin

Re: Toolchain Infrastructure project statement of support

[Jeff Law via Gcc]

On 10/23/22 11:09, Frank Ch. Eigler via Libc-alpha wrote:

Hi -


[...]  To be specific, gcc steering committee and glibc FSF stewards
have announced the decision for their projects [...]

I may be missing something.  All I've seen so far were some of the
leaders of some of the projects being joint signatories to a letter on
overseers@.  As far as I'm aware, that is not how any of these
projects make or announce **project decisions** with/to their
respective constituencies.


Right.  It's a general statement of support from a variety of leaders 
but I wouldn't consider it authoritative from any project.



For GCC the decision would be made by the overseers and relayed to the 
overseers as an official statement for the GCC project. That would 
happen after a vote by the steering committee members based on already 
established voting procedures.







I am not aware of any opposition from maintainers of libabigail or
cygwin or any other active sourceware based project over moving
either, but I haven't had any links to those projects, so I may be
uninformed.

Indeed.  The onus is obviously on the shoulders of the proponents of
this proposal to convince each sourceware guest project to consent to
move.  If you wish to frame any dissent as "blocking full migration",
then I'd say the job of convincing everyone just has not been up to
par.  Perhaps it was the wrong goal all along.


Also agreed.  And I fully support needing a statement from project 
leadership for each project wishing to move.    That is reasonable and I 
wish we'd been clearer about that.


In simplest terms, overseers need  to be a neutral party here.

In cases where overseers have leadership roles on particular projects, 
then they will have to wear multiple hats, but it's not really 
complicated.  Each project makes a decision, by whatever means project 
leadership has in place to make decisions. overseers then honors those 
requests to stay or go.  It's a pretty simple separation of 
responsibilities.  It need not be contentious in any way shape or form.



Jeff

Re: Toolchain Infrastructure project statement of support

[Frank Ch. Eigler via Gcc]

Hi -

> [...]  To be specific, gcc steering committee and glibc FSF stewards
> have announced the decision for their projects [...]

I may be missing something.  All I've seen so far were some of the
leaders of some of the projects being joint signatories to a letter on
overseers@.  As far as I'm aware, that is not how any of these
projects make or announce **project decisions** with/to their
respective constituencies.


> I am not aware of any opposition from maintainers of libabigail or
> cygwin or any other active sourceware based project over moving
> either, but I haven't had any links to those projects, so I may be
> uninformed.

Indeed.  The onus is obviously on the shoulders of the proponents of
this proposal to convince each sourceware guest project to consent to
move.  If you wish to frame any dissent as "blocking full migration",
then I'd say the job of convincing everyone just has not been up to
par.  Perhaps it was the wrong goal all along.


- FChE

Re: Toolchain Infrastructure project statement of support

[Jeff Law via Gcc]

On 10/23/22 10:07, Siddhesh Poyarekar wrote:


If you're trying to suggest that overseers, contrary to our repeated
public statements, wish to block all migration, that is untrue and you
will need to retract this.


Here's a more precise statement: Two of the overseers are leaders of 
projects hosted on sourceware and three overseers (including those 
two) have stated clearly on multiple occasions that transitioning to 
LF IT is off the table, effectively announcing their decision on 
behalf of projects they lead.  It is hence clear that the overseers 
have effectively blocked full migration of sourceware to LF IT.


They can make those decisions for the projects they lead.  But making 
the decision or setting criteria for other projects is highly unreasonable.


Jeff

[PATCH] c: If -fplan9-extensions, allow duplicate field declarations

[Keegan Saunders via Gcc-patches]

The Plan 9 compilers defer duplicate declaration checks until field
resolution time.  Further, there is a priority order of resolution such
that field lookups first match the name, then typedef'd names before
recursing into substructures.

This enables large portions of the Plan 9 userspace and kernel to be
compiled with GCC without modification.

gcc/c/ChangeLog:

* c-decl.cc (is_duplicate_field): Remove unused Plan 9 logic.
(detect_field_duplicates_hash): Likewise.
(detect_field_duplicates): If -fplan9-extensions, disable
duplicate field detection.
* c-typeck.cc (lookup_field_plan9): Implement the Plan 9 look up
  scheme.
(lookup_field): Likewise.

gcc/testsuite/ChangeLog:

* gcc.dg/anon-struct-13.c: Add duplicate fields.

Signed-off-by: Keegan Saunders 
---
 gcc/c/c-decl.cc   |  63 ++--
 gcc/c/c-typeck.cc | 101 --
 gcc/testsuite/gcc.dg/anon-struct-13.c |   9 +++
 3 files changed, 96 insertions(+), 77 deletions(-)

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 193e268f04e..539ad407f49 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -8538,41 +8538,7 @@ grokfield (location_t loc,
 static bool
 is_duplicate_field (tree x, tree y)
 {
-  if (DECL_NAME (x) != NULL_TREE && DECL_NAME (x) == DECL_NAME (y))
-return true;
-
-  /* When using -fplan9-extensions, an anonymous field whose name is a
- typedef can duplicate a field name.  */
-  if (flag_plan9_extensions
-  && (DECL_NAME (x) == NULL_TREE || DECL_NAME (y) == NULL_TREE))
-{
-  tree xt, xn, yt, yn;
-
-  xt = TREE_TYPE (x);
-  if (DECL_NAME (x) != NULL_TREE)
-   xn = DECL_NAME (x);
-  else if (RECORD_OR_UNION_TYPE_P (xt)
-  && TYPE_NAME (xt) != NULL_TREE
-  && TREE_CODE (TYPE_NAME (xt)) == TYPE_DECL)
-   xn = DECL_NAME (TYPE_NAME (xt));
-  else
-   xn = NULL_TREE;
-
-  yt = TREE_TYPE (y);
-  if (DECL_NAME (y) != NULL_TREE)
-   yn = DECL_NAME (y);
-  else if (RECORD_OR_UNION_TYPE_P (yt)
-  && TYPE_NAME (yt) != NULL_TREE
-  && TREE_CODE (TYPE_NAME (yt)) == TYPE_DECL)
-   yn = DECL_NAME (TYPE_NAME (yt));
-  else
-   yn = NULL_TREE;
-
-  if (xn != NULL_TREE && xn == yn)
-   return true;
-}
-
-  return false;
+  return DECL_NAME (x) != NULL_TREE && DECL_NAME (x) == DECL_NAME (y);
 }
 
 /* Subroutine of detect_field_duplicates: add the fields of FIELDLIST
@@ -8599,19 +8565,6 @@ detect_field_duplicates_hash (tree fieldlist,
 else if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)))
   {
detect_field_duplicates_hash (TYPE_FIELDS (TREE_TYPE (x)), htab);
-
-   /* When using -fplan9-extensions, an anonymous field whose
-  name is a typedef can duplicate a field name.  */
-   if (flag_plan9_extensions
-   && TYPE_NAME (TREE_TYPE (x)) != NULL_TREE
-   && TREE_CODE (TYPE_NAME (TREE_TYPE (x))) == TYPE_DECL)
- {
-   tree xn = DECL_NAME (TYPE_NAME (TREE_TYPE (x)));
-   slot = htab->find_slot (xn, INSERT);
-   if (*slot)
- error ("duplicate member %q+D", TYPE_NAME (TREE_TYPE (x)));
-   *slot = xn;
- }
   }
 }
 
@@ -8639,6 +8592,11 @@ detect_field_duplicates (tree fieldlist)
 if (objc_detect_field_duplicates (false))
   return;
 
+  /* When using -fplan9-extensions, do not perform duplicate field
+ checks until a field look up is performed.  */
+  if (flag_plan9_extensions)
+   return;
+
   /* First, see if there are more than "a few" fields.
  This is trivially true if there are zero or one fields.  */
   if (!fieldlist || !DECL_CHAIN (fieldlist))
@@ -8658,14 +8616,7 @@ detect_field_duplicates (tree fieldlist)
   if (timeout > 0)
 {
   for (x = DECL_CHAIN (fieldlist); x; x = DECL_CHAIN (x))
-   /* When using -fplan9-extensions, we can have duplicates
-  between typedef names and fields.  */
-   if (DECL_NAME (x)
-   || (flag_plan9_extensions
-   && DECL_NAME (x) == NULL_TREE
-   && RECORD_OR_UNION_TYPE_P (TREE_TYPE (x))
-   && TYPE_NAME (TREE_TYPE (x)) != NULL_TREE
-   && TREE_CODE (TYPE_NAME (TREE_TYPE (x))) == TYPE_DECL))
+   if (DECL_NAME (x))
  {
for (y = fieldlist; y != x; y = TREE_CHAIN (y))
  if (is_duplicate_field (y, x))
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index f9190680a3c..97ffa329ba7 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -95,6 +95,7 @@ static int comp_target_types (location_t, tree, tree);
 static int function_types_compatible_p (const_tree, const_tree, bool *,
bool *);
 static int type_lists_compatible_p (const_tree, const_tree, bool *, bool *);
+static tree lookup_field_plan9 (tree, tree);
 static tree lookup_field (tree, tree);
 static int convert_arguments (location_t, 

Re: Toolchain Infrastructure project statement of support

[Jeff Law via Gcc]

On 10/23/22 09:16, Frank Ch. Eigler via Gcc wrote:

Hi -


[...]  Given that the current sourceware admins have decided to
block migration of all sourceware assets to the LF IT [...]

If you're trying to say that projects have not unanimously shown
interest in moving infrastructure to LF IT, just say that.  Don't
blame overseers.


Project leadership needs to make this decision.  The sourceware 
overseers should neither make the decision nor decide how high the bar 
needs to be for any given project.



Jeff

[Bug c++/105774] Bogus overflow in constant expression with signed char++

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105774

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Jakub Jelinek  ---
Created attachment 53763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53763=edit
gcc13-pr105774.patch

Untested fix.

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 12:07, Siddhesh Poyarekar via Overseers wrote:
sourceware, I assume that means he'd like to use sourceware as a mirror 
or something similar) but gdb folks have been silent so far.  Given how 
gdb and binutils are coupled, the gdb conversation really needs to 
happen at some point.  From private conversations with folks from the 
gdb community, it seems to me that they're primarily avoiding getting 
into this public spat.


... and I've been corrected offline that a gdb GNU maintainer (Joel 
Brobecker) has indeed signed on to support the LF IT proposal and there 
have been no objections so far that I'm aware of, either publicly or 
privately.


Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 07:33, Ian Kelling wrote:

Siddhesh Poyarekar via Overseers  writes:


I personally do not think the current sourceware infrastructure, even
with the roadmap it promises is a viable alternative to what LF IT can
provide.  There is a significant resource gap (e.g.



established security and administration practices,

...

that we seem to disagree about.



Let's consider some "established security and administration practices"

curl -v http://vger.kernel.org | head
...
< Server: Apache/2.0.52 (Red Hat)
< X-Powered-By: PHP/4.3.9

This is RHEL 3, released in 2003, according to
https://people.redhat.com/crunge/RHEL3-package-lists.pdf,

The final end of support for this distro was on 2014-01-30.

There are CVE's for that version of Apache. I assume their apache is not
running in a configuration that makes them actually exploitable, but it
is still better security practice upgrade.

The kernel is likely from RHEL 3 too. I'm reminded of Greg KH beating the
drum that old kernels need upgrades for security, especially because the
kernel devs don't always check if a bug is a security issue and
especially not for really old kernels (
https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/
)

Notice that link is http because https is not supported by the apache
from 2003. Linux kernel development works through patches on mailing
lists, and how do you find the patches if you aren't already subscribed
to a list? You'd naturally go to the lists main webpage,
http://vger.kernel.org, and click "LIST INFO",
http://vger.kernel.org/vger-lists.html, and then click one of the list
archive links, or maybe the subscribe link. So, those vger.kerne.org
pages are an essential part of retrieving upstream kernel patches and
security information for some people. And being http only, my isp or
anyone in my network path could alter them to be malicious urls that
that appear to give the correct result, but actually give malicious
kernel patches, or hides away a security relevant patch. Obviously,
https for security sensitive pages like these is a basic 101 security
practice in 2022.


+Konstantin from LF IT since he's better equipped to speak to this, 
although ISTM that they started migrating off vger last year[1].


Sid

[1] https://www.kernel.org/lists-linux-dev.html

Sid

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 11:16, Frank Ch. Eigler wrote:

Hi -


[...]  Given that the current sourceware admins have decided to
block migration of all sourceware assets to the LF IT [...]


If you're trying to say that projects have not unanimously shown
interest in moving infrastructure to LF IT, just say that.  Don't
blame overseers.


I did not say that, although no project (barring maybe elfutils and 
systemtap, assuming that your and Mark's objection as overseers implies 
that you do not want to move to LF IT) has specifically *opposed* moving 
infrastructure to LF IT either.


To be specific, gcc steering committee and glibc FSF stewards have 
announced the decision for their projects, Nick announced for binutils 
that he supports moving to LF IT (with the caveat that he won't abandon 
sourceware, I assume that means he'd like to use sourceware as a mirror 
or something similar) but gdb folks have been silent so far.  Given how 
gdb and binutils are coupled, the gdb conversation really needs to 
happen at some point.  From private conversations with folks from the 
gdb community, it seems to me that they're primarily avoiding getting 
into this public spat.


I am not aware of any opposition from maintainers of libabigail or 
cygwin or any other active sourceware based project over moving either, 
but I haven't had any links to those projects, so I may be uninformed.



If you're trying to suggest that overseers, contrary to our repeated
public statements, wish to block all migration, that is untrue and you
will need to retract this.


Here's a more precise statement: Two of the overseers are leaders of 
projects hosted on sourceware and three overseers (including those two) 
have stated clearly on multiple occasions that transitioning to LF IT is 
off the table, effectively announcing their decision on behalf of 
projects they lead.  It is hence clear that the overseers have 
effectively blocked full migration of sourceware to LF IT.


Sid

Re: Toolchain Infrastructure project statement of support

[Ian Kelling via Gcc]

Siddhesh Poyarekar via Overseers  writes:

> I personally do not think the current sourceware infrastructure, even
> with the roadmap it promises is a viable alternative to what LF IT can
> provide.  There is a significant resource gap (e.g.

> established security and administration practices,
...
> that we seem to disagree about.


Let's consider some "established security and administration practices"

curl -v http://vger.kernel.org | head
...
< Server: Apache/2.0.52 (Red Hat)
< X-Powered-By: PHP/4.3.9

This is RHEL 3, released in 2003, according to
https://people.redhat.com/crunge/RHEL3-package-lists.pdf,

The final end of support for this distro was on 2014-01-30.

There are CVE's for that version of Apache. I assume their apache is not
running in a configuration that makes them actually exploitable, but it
is still better security practice upgrade.

The kernel is likely from RHEL 3 too. I'm reminded of Greg KH beating the
drum that old kernels need upgrades for security, especially because the
kernel devs don't always check if a bug is a security issue and
especially not for really old kernels (
https://thenewstack.io/design-system-can-update-greg-kroah-hartman-linux-security/
)

Notice that link is http because https is not supported by the apache
from 2003. Linux kernel development works through patches on mailing
lists, and how do you find the patches if you aren't already subscribed
to a list? You'd naturally go to the lists main webpage,
http://vger.kernel.org, and click "LIST INFO",
http://vger.kernel.org/vger-lists.html, and then click one of the list
archive links, or maybe the subscribe link. So, those vger.kerne.org
pages are an essential part of retrieving upstream kernel patches and
security information for some people. And being http only, my isp or
anyone in my network path could alter them to be malicious urls that
that appear to give the correct result, but actually give malicious
kernel patches, or hides away a security relevant patch. Obviously,
https for security sensitive pages like these is a basic 101 security
practice in 2022.

You might think when kernel.org had a major compromise in 2011, 11 years
later, they would have managed this basic upgrade. The fact is that the
Linux Foundation struggles with getting stuff to current versions and
following good security practices like everyone else does. This
narrative that there is a huge resource gap in security practices
between LF and sourceware is not true, and I don't think the kernel.org
IT team would claim that either. They certainly made no such claims in
their slide deck about the GTI proposal.

If LF IT were to get involved in services for GNU toolchain packages, it
should be more of a collaboration with sourceware instead of taking over
what sourceware is doing.

Competent sysadmin volunteers are rare and valuable to GNU. They help
build community, they help GNU stay independent, and they help GNU
practice what it preaches.

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

[Bug c++/107363] Wrong caret location for "redundant move in return statement" and nvo

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107363

--- Comment #1 from Andrew Pinski  ---
The wrong caret comes from named return value optimization iirc.

[Bug c++/107327] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12930

[kaploceh at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107327

--- Comment #9 from Carlos E  ---
(In reply to Martin Liška from comment #7)
> (In reply to Carlos E from comment #6)
> > (In reply to Martin Liška from comment #4)
> > > > When you say to attach a preprocessed source, what would be the most
> > > > accepted command that I should be running which can reliably show 
> > > > whatever
> > > > was preprocessed?   
> > > 
> > > Just append -E to the existing command line arguments, that would be fine.
> > 
> > done.
> 
> We need what was likely printed to stdout, or saved to a .o file.
> 
> See what's the pre-processed source file:
> echo '#include ' | gcc -x c - -E

thank you Martin. 

It did compile as Richard suggested with 10.4 

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.4.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --with-mpc-lib= --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.4.0 (GCC) 

the preprocessed file was after installing 10.4.
I can revert to 10.2

Re: Toolchain Infrastructure project statement of support

[Frank Ch. Eigler via Gcc]

Hi -

> [...]  Given that the current sourceware admins have decided to
> block migration of all sourceware assets to the LF IT [...]

If you're trying to say that projects have not unanimously shown
interest in moving infrastructure to LF IT, just say that.  Don't
blame overseers.

If you're trying to suggest that overseers, contrary to our repeated
public statements, wish to block all migration, that is untrue and you
will need to retract this.

- FChE

[Bug c++/107327] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12930

[kaploceh at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107327

--- Comment #8 from Carlos E  ---
Created attachment 53762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53762=edit
preprocessed file

Re: clarification question

[Paul Koning via Gcc]

> On Oct 22, 2022, at 2:38 PM, Marc Glisse via Gcc  wrote:
> 
> On Sat, 22 Oct 2022, Péntek Imre via Gcc wrote:
> 
>> https://gcc.gnu.org/backends.html
>> 
>> by "Architecture does not have a single condition code register" do you mean 
>> it has none or do you mean it has multiple?
> 
> Either.
> 
> If you look at the examples below, there is a C for riscv, which has 0, and 
> one for sparc, which has several.

Also pdp11, which has two: one for floating point, one for integers, and 
conditional branches act only on the integer CC register.  So the MD has to 
describe a "move float CC to integer CC" operation.

GCC supports all these strange things quite nicely -- this is one of several 
things that the newer CCmode machinery does well and the old "cc0" stuff 
doesn't.

paul

[PATCH] [PR tree-optimization/107365] Check HONOR_NANS instead of flag_finite_math_only in frange:verify_range.

[Aldy Hernandez via Gcc-patches]

[Jakub and other FP experts, would this be OK, or am I missing
something?]

Vax does not seem to have !flag_finite_math_only, but float_type_node
does not HONOR_NANS.  The check in frange::verify_range dependend on
flag_finite_math_only, which is technically not correct since
frange::set_varying() checks HONOR_NANS instead of
flag_finite_math_only.

I'm actually getting tired of flag_finite_math_only and
!flag_finite_math_only discrepancies in the selftests (Vax and rx-elf
come to mind).  I think we should just test both alternatives in the
selftests as in this patch.

We could also check flag_finite_math_only=0 with a float_type_node
that does not HONOR_NANs, but I have no idea how to twiddle
FLOAT_MODE_FORMAT temporarily, and that may be over thinking it.

How does this look?

PR tree-optimization/107365

gcc/ChangeLog:

* value-range.cc (frange::verify_range): Predicate NAN check in
VARYING range on HONOR_NANS instead of flag_finite_math_only.
(range_tests_floats): Same.
(range_tests_floats_various): New.
(range_tests): Call range_tests_floats_various.
---
 gcc/value-range.cc | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index d779e9819e2..d8ee6ec0d0f 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -720,13 +720,13 @@ frange::verify_range ()
   gcc_checking_assert (!m_type);
   return;
 case VR_VARYING:
-  if (flag_finite_math_only)
-   gcc_checking_assert (!m_pos_nan && !m_neg_nan);
-  else
-   gcc_checking_assert (m_pos_nan && m_neg_nan);
   gcc_checking_assert (m_type);
   gcc_checking_assert (frange_val_is_min (m_min, m_type));
   gcc_checking_assert (frange_val_is_max (m_max, m_type));
+  if (HONOR_NANS (m_type))
+   gcc_checking_assert (m_pos_nan && m_neg_nan);
+  else
+   gcc_checking_assert (!m_pos_nan && !m_neg_nan);
   return;
 case VR_RANGE:
   gcc_checking_assert (m_type);
@@ -3957,10 +3957,9 @@ range_tests_floats ()
   // A range of [-INF,+INF] is actually VARYING if no other properties
   // are set.
   r0 = frange_float ("-Inf", "+Inf");
-  if (r0.maybe_isnan ())
-ASSERT_TRUE (r0.varying_p ());
+  ASSERT_TRUE (r0.varying_p ());
   // ...unless it has some special property...
-  if (!flag_finite_math_only)
+  if (HONOR_NANS (r0.type ()))
 {
   r0.clear_nan ();
   ASSERT_FALSE (r0.varying_p ());
@@ -4041,6 +4040,24 @@ range_tests_floats ()
 }
 }
 
+// Run floating range tests for various combinations of NAN and INF
+// support.
+
+static void
+range_tests_floats_various ()
+{
+  int save_finite_math_only = flag_finite_math_only;
+
+  // Test -ffinite-math-only.
+  flag_finite_math_only = 1;
+  range_tests_floats ();
+  // Test -fno-finite-math-only.
+  flag_finite_math_only = 0;
+  range_tests_floats ();
+
+  flag_finite_math_only = save_finite_math_only;
+}
+
 void
 range_tests ()
 {
@@ -4049,7 +4066,7 @@ range_tests ()
   range_tests_int_range_max ();
   range_tests_strict_enum ();
   range_tests_nonzero_bits ();
-  range_tests_floats ();
+  range_tests_floats_various ();
   range_tests_misc ();
 }
 
-- 
2.37.3

[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365

--- Comment #2 from Aldy Hernandez  ---
Created attachment 53761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53761=edit
untested

[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726

[aldyh at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365

--- Comment #1 from Aldy Hernandez  ---
Ok, this is getting ridiculous.  I'm tired of these weird finite-math-only
combinations in Vax and rx-elf.  I think we should just test -ffinite-math-only
and -fno-finite-math-only in the self tests for all architectures.  Heck, we
should probably check -fno-finite-math-only + !HONOR_NANS (float_type_mode).

[Bug tree-optimization/107346] [13 Regression] gnat.dg/loop_optimization23_pkg.ad failure afer r13-3413-ge10ca9544632db

[avieira at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346

--- Comment #9 from avieira at gcc dot gnu.org ---
Hi Eric,

I realised the same, got a patch pending here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604139.html

RE: [PATCH] [X86_64]: Enable support for next generation AMD Zen4 CPU

[Kumar, Venkataramanan via Gcc-patches]

[AMD Official Use Only - General]

Hi Richi and Jakub

> -Original Message-
> From: Jakub Jelinek 
> Sent: Saturday, October 22, 2022 10:41 PM
> To: Richard Biener 
> Cc: Kumar, Venkataramanan ; Joshi,
> Tejas Sanjay ; gcc-patches@gcc.gnu.org;
> honza.hubi...@gmail.com
> Subject: Re: [PATCH] [X86_64]: Enable support for next generation AMD
> Zen4 CPU
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Fri, Oct 21, 2022 at 01:51:55PM +0200, Richard Biener via Gcc-patches
> wrote:
> > > > > BTW: Perhaps znver1.md is not the right filename anymore, since
> > > > > it hosts
> > > > all four Zen schedulers.
> > > >
> > > > I have renamed the file to znver.md in this revision, PFA.
> > > > Thank you for the review, we will push it for trunk if we don't
> > > > get any further comments.
> > >
> > > I have pushed the patch on behalf of Tejas.
> >
> > This grew insn-automata.cc from 201502 lines to 639968 lines and the
> > build of the automata (genautomata) to several minutes in my dev tree.
>
> Yeah, in my unoptimized non-bootstrapped development tree genautomata
> now takes over 12 minutes on a fast box, that is simply not acceptable.

Thank you for notifying us.

tejassanjay.jo...@amd.com has posted a patch for review to fix this (as per 
Honza's comments).
Ref: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604144.html

Sorry for the inconvenience caused.

Regards,
Venkat.

>
> Jakub

Re: Toolchain Infrastructure project statement of support

[Siddhesh Poyarekar]

On 2022-10-23 04:59, Ian Kelling wrote:

No, I don't think that was ever clear. I've just read this message, but
I've been keeping up with everything public since Cauldron.  All your
options assume that any specific service is 100% managed by LF IT, or
100% managed by sourceware. That is a bad assumption. They could do it
together, or another group could help.  So, you said you wanted
"dedicated ops management", and I assume sourceware is not currently
equipped for that. But there is no reason that an ops team from LF IT or
FSF could not provide dedicated ops management for existing sourceware
services in collaboration with sourceware. Another notable ops team is
OSU, https://osuosl.org/.


Hybrid administration isn't part of the GTI proposal, why would that be 
considered an option?  Is this something you'd like to propose to the 
TAC, i.e. give named members from the community access to infrastructure 
administration?  We can bring that up in our discussion with the LF IT.



Anyways, basically, having a dedicated ops team does not imply removing
the sourceware's role, it could simply mean: adding a dedicated ops team
to sourceware.


Given that the current sourceware admins have decided to block migration 
of all sourceware assets to the LF IT, I don't have a stake on how 
they'd like to handle this for sourceware.  I could however, as a member 
of TAC (and as member of projects that have agreed to migrate to LF IT, 
i.e. gcc and glibc), discuss with others the possibility of specific 
community volunteers being given some amount of access to manage 
infrastructure.



To provide dedicated ops for the physical servers would require moving
the servers or into servers in a data center near the ops team, or
outsourcing the hardware management to one of many companies (usually by
renting a physical server), but that is all totally feasible and not a
big cost.


Siddhesh Poyarekar via Overseers  writes:


I want us to migrate
services to infrastructure with better funding (that's not just limited
to services),


What do you want to fund specifically? "Infrastructure" and "not limited
to services" is not specific enough to understand.


and an actually scalable future.


What does "an actually scalable future" mean? That is very vague.


Both of those point to scaling hardware in addition to services, having 
things like physical isolation of services.  Scaling volunteers (which 
hasn't happened in the last 20-soemthing years; it has scaled *down*, if 
anything) and money to pay for dedicated ops isn't going to mostly 
pointless if we can't pay for hardware, which is owned by Red Hat. 
That, and FSF not being able to add resources for the GNU toolchain was 
in fact why we had to look elsewhere for funding.


I suggest you wait a day for the FSF hosted call so that the background 
is clearer.


Sid

[Bug c/107366] New: -fanalyzer with -fdiagnostics-format=sarif-file or sarif-stderr

[rainer.keller--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107366

Bug ID: 107366
   Summary: -fanalyzer with -fdiagnostics-format=sarif-file or
sarif-stderr
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rainer.kel...@hs-esslingen.de
  Target Milestone: ---

Created attachment 53760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53760=edit
Compilation of -freport-bug

Compiling hwloc-2.8.0 with -fanalyzer and either
-fdiagnostics-format=sarif-file or -fdiagnostics-format=sarif-stderr produces:

during IPA pass: analyzer
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

Unfortunately I wasn't able to produce a MWE.
Steps to reproduce:
   wget https://download.open-mpi.org/release/hwloc/v2.8/hwloc-2.8.0.tar.bz2
   tar xf hwloc-2.8.0.tar.bz2 && cd hwloc-2.8.0
   mkdir BUILD && cd $_
   ../configure --prefix=$PWD/usr
   make CFLAGS="-fanalyzer -fdiagnostics-format=sarif-stderr"
fails in hwloc/diff.c

Using -fdiagnostics-format=json-stderr and -file works.

The above does not seem to be related to https://gcc.gnu.org/PR106703

Attached is the -freport-bug of same file.
Thanks

Re: Ping (c,c++): Handling of main() function for freestanding

[Arsen Arsenović via Gcc]

On Friday, 21 October 2022 23:02:02 CEST Joseph Myers wrote:
> I have no objections to the C changes.

Great!  Thanks for the review.  I don't have push rights currently, so I 
must ask that someone else pushes this patch for me.

Have a great day!
-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.

Re: Ping (c,c++): Handling of main() function for freestanding

[Arsen Arsenović via Gcc-patches]

On Friday, 21 October 2022 23:02:02 CEST Joseph Myers wrote:
> I have no objections to the C changes.

Great!  Thanks for the review.  I don't have push rights currently, so I 
must ask that someone else pushes this patch for me.

Have a great day!
-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] d: Remove D-specific version definitions from target headers

[ibuclaw--- via Gcc-patches]

> On 17/10/2022 20:08 CEST Iain Buclaw  wrote:
> 
>  
> Hi,
> 
> This splits up the targetdm sources so that each file only handles one
> target platform.
> 
> Having all logic kept in the headers means that they could become out of
> sync when a new target is added (loongarch*-*-linux*) or accidentally
> broken if some headers in tm_file are omitted or changed about.
> 
> There might be an open bikeshed question as to appropriate names for
> some of the platform sources (kfreebsd-d.cc or kfreebsd-gnu-d.cc).
> 
> Bootstrapped and regression tested on x86_64-linux-gnu, and also built
> i686-cygwin, i686-gnu, i686-kfreebsd-gnu, i686-kopensolaris-gnu,
> x86_64-cygwin, x86_64-w64-mingw32 cross compilers, the dumps of all
> predefined version identifiers remain correct in all configurations.
> 
> OK?
> 

Ping?

I'll apply this tomorrow, but there is a general open question about whether 
taking logic out of target headers and putting it in config.gcc is the right 
approach moving forward for non C/C++ front-ends.  This is also relevant for 
Rust, which initially put all their target support definitions in headers, and 
have since removed the entire tangled mess that created.

Regards,
Iain.

[Bug tree-optimization/107346] [13 Regression] gnat.dg/loop_optimization23_pkg.ad failure afer r13-3413-ge10ca9544632db

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  ---
> I am wondering whether I should try to support this, or bail out of
> vect_check_gather_scatter if pbitpos is not a multiple of BITS_PER_UNIT. The
> latter obviously feels safer.

It turns out that this vect_check_gather_scatter problem was latent since I can
reproduce it with the GCC 12 compiler in Ada, and the following fix:

diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index e32b1779c5d..a22eb2d763d 100644
--- a/gcc/tree-vect-data-refs.cc
+++ b/gcc/tree-vect-data-refs.cc
@@ -4013,7 +4013,7 @@ vect_check_gather_scatter (stmt_vec_info stmt_info,
loop_vec_info loop_vinfo,
  that can be gimplified before the loop.  */
   base = get_inner_reference (base, , , , ,
  , , );
-  if (reversep)
+  if (!multiple_p (pbitpos, BITS_PER_UNIT) || reversep)
 return false;

   poly_int64 pbytepos = exact_div (pbitpos, BITS_PER_UNIT);

is sufficient to get rid of it.

[Bug tree-optimization/107365] ICE in verify_range, at value-range.cc:726

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||amacleod at redhat dot com

[Bug tree-optimization/107365] New: ICE in verify_range, at value-range.cc:726

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107365

Bug ID: 107365
   Summary: ICE in verify_range, at value-range.cc:726
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: vax-linux-gnu

Happens for a cross compiler:

$ ./xgcc -B./ -B/home/marxin/bin/gcc/vax-linux-gnu/bin/ -isystem
/home/marxin/bin/gcc/vax-linux-gnu/include -isystem
/home/marxin/bin/gcc/vax-linux-gnu/sys-include -L/dev/shm/objdir2/gcc/../ld 
-xc++ -nostdinc /dev/null -S -o /dev/null
-fself-test=/home/marxin/Programming/gcc/gcc/testsuite/selftests
In function ‘test_fn’:
cc1plus: internal compiler error: in verify_range, at value-range.cc:726
0x18dbdc5 frange::verify_range()
/home/marxin/Programming/gcc/gcc/value-range.cc:726
0x18da448 frange::set(tree_node*, real_value const&, real_value const&,
value_range_kind)
/home/marxin/Programming/gcc/gcc/value-range.cc:366
0x18f17fe frange::frange(tree_node*, real_value const&, real_value const&,
value_range_kind)
/home/marxin/Programming/gcc/gcc/value-range.h:1080
0x18ed069 frange_float
/home/marxin/Programming/gcc/gcc/value-range.cc:3692
0x18f021c range_tests_floats
/home/marxin/Programming/gcc/gcc/value-range.cc:3959
0x18f11c9 selftest::range_tests()
/home/marxin/Programming/gcc/gcc/value-range.cc:4052
0x20549b7 test_ranges
/home/marxin/Programming/gcc/gcc/function-tests.cc:584
0x20549b7 selftest::function_tests_cc_tests()
/home/marxin/Programming/gcc/gcc/function-tests.cc:680
0x21b488c selftest::run_tests()
/home/marxin/Programming/gcc/gcc/selftest-run-tests.cc:107
0x146880e toplev::run_self_tests()
/home/marxin/Programming/gcc/gcc/toplev.cc:2184
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/107364] New: ICE on Via Nehemiah with --march=native

[orzel at freehackers dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107364

Bug ID: 107364
   Summary: ICE on Via Nehemiah with --march=native
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: orzel at freehackers dot org
  Target Milestone: ---

The cpu is very old:
chopin /etc # cat /proc/cpuinfo 
processor   : 0
vendor_id   : CentaurHauls
cpu family  : 6
model   : 9
model name  : VIA Nehemiah
stepping: 3
cpu MHz : 997.000
cache size  : 64 KB
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de pse tsc msr cx8 mtrr pge cmov mmx fxsr sse cpuid rng
rng_en
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
swapgs itlb_multihit mmio_unknown
bogomips: 1999.03
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:

The compiler crashes when using -march=native. You dont need to compile for it
to crash, --help=target is enough. As a result, gcc can't build itself anymore.
The last known 'working' version is gcc 9. Tested are gcc 10, 11, and 12, all
crashing the same way. This is how it looks:


chopin /etc # gcc-12 -Q --help=target -march=native -freport-bug
gcc-12: internal compiler error: in cpu_indicator_init, at
common/config/i386/cpuinfo.h:986
0xb7cd535e __libc_start_main
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
chopin /etc # gcc-12 -Q --help=target
The following options are target specific:
  -m128bit-long-double  [disabled]
  -m16  [disabled]
  -m32  [enabled]
  -m3dnow   [disabled]
  -m3dnowa  [disabled]
  -m64  [disabled]
  -m80387   [enabled]
  -m8bit-idiv   [disabled]
  -m96bit-long-double   [enabled]
  -mabi=sysv
  -mabm [disabled]
  -maccumulate-outgoing-args[disabled]
  -maddress-mode=   short
  -madx [disabled]
  -maes [disabled]
  -malign-data= compat
  -malign-double[disabled]
  -malign-functions=0
  -malign-jumps=0
  -malign-loops=0
  -malign-stringops [enabled]
  -mamx-bf16[disabled]
  -mamx-int8[disabled]
  -mamx-tile[disabled]
  -mandroid [disabled]
  -march=   i686
  -masm=att
  -mavx [disabled]
  -mavx2[disabled]
  -mavx256-split-unaligned-load [disabled]
  -mavx256-split-unaligned-store[disabled]
  -mavx5124fmaps[disabled]
  -mavx5124vnniw[disabled]
  -mavx512bf16  [disabled]
  -mavx512bitalg[disabled]
  -mavx512bw[disabled]
  -mavx512cd[disabled]
  -mavx512dq[disabled]
  -mavx512er[disabled]
  -mavx512f [disabled]
  -mavx512fp16  [disabled]
  -mavx512ifma  [disabled]
  -mavx512pf[disabled]
  -mavx512vbmi  [disabled]
  -mavx512vbmi2 [disabled]
  -mavx512vl[disabled]
  -mavx512vnni  [disabled]
  -mavx512vp2intersect  [disabled]
  -mavx512vpopcntdq [disabled]
  -mavxvnni [disabled]
  -mbionic  [disabled]
  -mbmi [disabled]
  -mbmi2[disabled]
  -mbranch-cost=<0,5>   3
  -mcall-ms2sysv-xlogues[disabled]
  -mcet-switch  [disabled]
  -mcld [disabled]
  -mcldemote[disabled]
  -mclflushopt  [disabled]
  -mclwb[disabled]
  -mclzero  [disabled]
  -mcmodel= 32
  -mcpu=  

Re: Toolchain Infrastructure project statement of support

[Ian Kelling via Gcc]

Siddhesh Poyarekar via Overseers  writes:

>> what
>> alternatives we have, etc.
> For projects the alternatives they have are:
>
> 1. Migrate to LF IT infrastructure
> 2. Have a presence on sourceware as well as LF IT, contingent to Red
> Hat's decision on the hardware infrastructure
> 3. Stay fully on sourceware
>
> For sourceware as infrastructure the alternatives are:
>
> 1. Migrate to LF IT infrastructure
> 2. Stay as it currently is
>
> For sourceware overseers, the choices are contingent on what projects
> decide and what Red Hat decides w.r.t. sourceware.
>
> All of the above has been clear all along.  Maybe the problem here is
> that you're not happy with the alternatives?

No, I don't think that was ever clear. I've just read this message, but
I've been keeping up with everything public since Cauldron.  All your
options assume that any specific service is 100% managed by LF IT, or
100% managed by sourceware. That is a bad assumption. They could do it
together, or another group could help.  So, you said you wanted
"dedicated ops management", and I assume sourceware is not currently
equipped for that. But there is no reason that an ops team from LF IT or
FSF could not provide dedicated ops management for existing sourceware
services in collaboration with sourceware. Another notable ops team is
OSU, https://osuosl.org/.

For example, at FSF tech team (where I work), we jointly maintain
services with many volunteers that volunteer for specific projects. They
are mainly: KDE, Linux Libre, Emacs, Savannah, Guix, GNU debbugs,
replicant, h-node.org, planet.gnu.org, and Trisquel. The FSF tech team
keeps a 24 hour on call rotation, so the services have a dedicated ops
team to fix issues and respond to alerts, but the day to day management
of the services those groups want, eg: upgrading them, configuring,
modifying, etc is mostly done by volunteers.

To give some very specific examples: a group of volunteer sysadmins for
emacs decided they wanted a new build service for Emacs, so they jumped
in a meeting with FSF tech team (I'm part of it) to discuss all the
technical details and requirements. We decided the volunteers would do
the primary installation and management of a gitlab that was only
configured to use the build server, and FSF tech team would setup
alerts, create the VM and the DNS. We agree on what kind of uptime is
expected and what kind of alerts the tech team will respond to in off
hours. The volunteer's ssh keys sit alongside the FSF tech team's keys
on that VM. Alternatively, for Trisquel, Trisquel orders hardware and we
go install it to the data center, and the Trisquel sysadmins spin up
their own virtual machines or whatever they want to run, we just go into
the data center with spare parts and fix things if the hardware breaks
down. For any service we are going to support, we learn enough about the
service to fix things things.

Anyways, basically, having a dedicated ops team does not imply removing
the sourceware's role, it could simply mean: adding a dedicated ops team
to sourceware.

To provide dedicated ops for the physical servers would require moving
the servers or into servers in a data center near the ops team, or
outsourcing the hardware management to one of many companies (usually by
renting a physical server), but that is all totally feasible and not a
big cost.


Siddhesh Poyarekar via Overseers  writes:

> I want us to migrate
> services to infrastructure with better funding (that's not just limited
> to services),

What do you want to fund specifically? "Infrastructure" and "not limited
to services" is not specific enough to understand.

> and an actually scalable future.

What does "an actually scalable future" mean? That is very vague.


-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org

[Bug c++/107363] New: Wrong caret location for "redundant move in return statement"

[dani at danielbertalan dot dev via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107363

Bug ID: 107363
   Summary: Wrong caret location for "redundant move in return
statement"
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dani at danielbertalan dot dev
  Target Milestone: ---

The caret in the following "redundant move in return statement" warning does
not point to a return statement (https://godbolt.org/z/4v7Y9G9e3):

```
#include 

template 
struct Optional {
  T ();
  T release_value() {
T released_value = std::move(value());
return released_value;
  }
};

struct Foo {};
void test(Optional o) { o.release_value(); }
```

:7:7: warning: redundant move in return statement [-Wredundant-move]
7 | T released_value = std::move(value());
  |   ^~
:7:7: note: remove 'std::move' call

As an aside, it's a bit annoying to have this warning when the moved type
depends on a template parameter in library code. We are forced to either
silence this warning with a #pragma, or use concepts to have a variant of the
release_value method that does not call std::move for const-qualified T.

[PATCH]: Fix static-pie on Hurd target

[Samuel Thibault via Gcc-patches]

When linking with -static-pie, we need to use rcrt0.o (and grcrt0.o for
-pg). Also, set static:crt0.o before pie:Scrt1.o, otherwise -static -pie
fails to link with Scrt1.o due to missing _DYNAMIC symbol.

Also, -static-pie needs crtbeginS.o (otherwise it contains a relocation
in read-only .text).

And eventually, when HAVE_LD_PIE is not defined, there is no reason to
include the pie case

gcc/ChangeLog

* gcc/config/i386/gnu.h (STARTFILE_SPEC): Add static-pie cases
and fix -static -pie case.

---
 gcc/config/i386/gnu.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/config/i386/gnu.h b/gcc/config/i386/gnu.h
index fb8d69a97d8..7d7bfa7da7b 100644
--- a/gcc/config/i386/gnu.h
+++ b/gcc/config/i386/gnu.h
@@ -27,12 +27,12 @@ along with GCC.  If not, see .
 #undef STARTFILE_SPEC
 #if defined HAVE_LD_PIE
 #define STARTFILE_SPEC \
-  "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}}
 \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+  "%{!shared: 
%{pg|p|profile:%{static-pie:grcrt0.o%s;static:gcrt0.o%s;:gcrt1.o%s};static-pie:rcrt0.o%s;static:crt0.o%s;pie:Scrt1.o%s;:crt1.o%s}}
 \
+   crti.o%s 
%{static:crtbeginT.o%s;shared|pie|static-pie:crtbeginS.o%s;:crtbegin.o%s}"
 #else
 #define STARTFILE_SPEC \
   "%{!shared: 
%{pg|p|profile:%{static:gcrt0.o%s;:gcrt1.o%s};static:crt0.o%s;:crt1.o%s}} \
-   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
+   crti.o%s %{static:crtbeginT.o%s;shared:crtbeginS.o%s;:crtbegin.o%s}"
 #endif
 
 #ifdef TARGET_LIBC_PROVIDES_SSP

[Bug c++/107360] ICE on sizeof(*f(x)) when f's (deduced) return type is a pointer to VLA

[izbyshev at ispras dot ru via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107360

--- Comment #2 from Alexey Izbyshev  ---
(In reply to Andrew Pinski from comment #1)
> Maybe this should be invalid code ...

Yes, I think it should be invalid. VLAs are not allowed in function return
types in C. VLAs in C++ are a GCC extension, but it's unclear to me why (and
how) GCC should allow them in return types, even when they don't depend on
function parameters.

Currently, GCC crashes even in the latter case, e.g.:

extern int n;

auto f() {
int (*a)[n] = 0;
return a;
}

int g() {
return sizeof *f();
}

[Bug fortran/107362] New: Segfault for recursive class

[baradi09 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107362

Bug ID: 107362
   Summary: Segfault for recursive class
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baradi09 at gmail dot com
  Target Milestone: ---

When trying to build Fortuno (https://github.com/aradi/fortuno), our new
Fortran unit testing system, I encounter a segfault with GFortran. The problem
can be reduced to the following MWE:

[details: failureinfo.f90]
module fortuno_failureinfo
  implicit none

  type :: failure_info
class(failure_info), allocatable :: previous
  end type failure_info

end module fortuno_failureinfo
[/details]

> gfortran -freport-bug -c failureinfo.f90 
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report, with preprocessed source.
See 
for instructions.

Apparently, the problem is the "class(failure_info)" field within the derived
type. Turning it into "type(failure_info)" allows compilation.

I use GNU Fortran (conda-forge gcc 12.2.0-18) 12.2.0 on x86_64/Linux.

Thanks a lot for having a look at it in advance!

[Bug c++/107361] New: Why does -Wclass-memaccess require trivial types, instead of trivially-copyable types?

[carlosgalvezp at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107361

Bug ID: 107361
   Summary: Why does -Wclass-memaccess require trivial types,
instead of trivially-copyable types?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

I find -Wclass-memaccess warns on this kind of code:

#include 

struct Foo
{
int x{};
char y{};
int z{};
};

int main()
{
Foo a;
std::memset(, 0, sizeof(a));
}

All because Foo has default member initializers, making it a non-trivial type.
It's still trivially-copyable, which is the requirement for std::memset.
Therefore I ask: why is the warning stricter than it needs to be?

Making sure structs are initialized is defensive programming, and consistent
with coding guidelines that require classes to initialize their data members. 

Also, there are cases where we cannot use the C++ initialization (Foo a = {};).
For example, this class has implicit padding, and the C++ initialization will
not initialize that. This is a problem for serializer/deserializer type of code
(copying/reading uninitialized padding bytes, valgrind will complain).

[Bug c++/107360] ICE on sizeof(*f(x)) when f's (deduced) return type is a pointer to VLA

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107360

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |

--- Comment #1 from Andrew Pinski  ---
Maybe this should be invalid code ...

[Bug target/107359] [aarch64] should avoid the punpklo/punpkhi compare to llvm

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107359

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-10-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.

Note if you use float instead of double. GCC produces better code. That is the
following testcase:
int check (char *mask, float *result, int n) {
int count = 0;
for (int i=0; i

[Bug c++/107360] New: ICE on sizeof(*f(x)) when f's (deduced) return type is a pointer to VLA

[izbyshev at ispras dot ru via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107360

Bug ID: 107360
   Summary: ICE on sizeof(*f(x)) when f's (deduced) return type is
a pointer to VLA
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izbyshev at ispras dot ru
  Target Milestone: ---

auto f(int n) {
int (*a)[n] = 0;
return a;
}

int g() {
return sizeof *f(1);
}

Output of GCC 12.2:

during RTL pass: expand
: In function 'int g()':
:7:23: internal compiler error: in expand_expr_real_1, at expr.cc:10586
7 | return sizeof *f(1);
  |   ^
0x1bb069e internal_error(char const*, ...)
???:0
0x6ff396 fancy_abort(char const*, int, char const*)
???:0
0xab97bd expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0xaab144 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xab97bd expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0xaab144 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xab38c4 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
???:0
0xaba7ac expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0xaab144 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0xabb2c9 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0xaab144 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0

All versions supporting C++14 return type deduction (i.e. since 4.8) produce
ICE, except 4.9, which generates wrong code for g() instead (it returns 1
regardless of f's argument).

[Bug target/107359] [aarch64] should avoid the punpklo/punpkhi compare to llvm

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107359

--- Comment #1 from Andrew Pinski  ---
Options: -O3  -march=armv8.2-a+sve