New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/gcc-12.1-b20220213.pot

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

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/12-20220213/gcc-12-20220213.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

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

New template for 'cpplib' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/cpplib-12.1-b20220213.pot

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

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/12-20220213/gcc-12-20220213.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

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

[PATCH][_Hashtable] Fix insertion of range of type convertible to value_type PR 56112

[François Dumont via Gcc-patches]

We have a regression regarding management of types convertible to 
value_type. It is an occurrence of PR 56112 but for the insert method.


    libstdc++: [_Hashtable] Insert range of types convertible to 
value_type PR 56112


    Fix insertion of range of types convertible to value_type.

    libstdc++-v3/ChangeLog:

    PR libstdc++/56112
    * include/bits/hashtable.h
    (_Hashtable<>::_M_insert_unique_aux): New.
    (_Hashtable<>::_S_to_value): New.
    (_Hashtable<>::_M_insert(_Arg&&, const _NodeGenerator&, 
true_type)): Use latters.
    * testsuite/23_containers/unordered_map/cons/56112.cc: Use 
dg-do compile.
    * testsuite/23_containers/unordered_set/cons/56112.cc: New 
test.


Tested under Linux x86_64.

Ok to commit ?

François
diff --git a/libstdc++-v3/include/bits/hashtable.h b/libstdc++-v3/include/bits/hashtable.h
index 5e1a417f7cd..5a502c02fe0 100644
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -898,14 +898,51 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 	std::pair
-	_M_insert(_Arg&& __arg, const _NodeGenerator& __node_gen,
-		  true_type /* __uks */)
+	_M_insert_unique_aux(_Arg&& __arg, const _NodeGenerator& __node_gen)
 	{
 	  return _M_insert_unique(
 	_S_forward_key(_ExtractKey{}(std::forward<_Arg>(__arg))),
 	std::forward<_Arg>(__arg), __node_gen);
 	}
 
+  template
+	static typename std::enable_if::value,
+   _Kt&&>::type
+	_S_to_value(_Kt&& __x) noexcept
+	{ return std::forward<_Kt>(__x); }
+
+  template
+	static typename std::enable_if::value,
+   const std::pair<_Kt, _Val>&>::type
+	_S_to_value(const std::pair<_Kt, _Val>& __x) noexcept
+	{ return __x; }
+
+  template
+	static typename std::enable_if::value,
+   std::pair<_Kt, _Val>&&>::type
+	_S_to_value(std::pair<_Kt, _Val>&& __x) noexcept
+	{ return std::move(__x); }
+
+  static value_type&&
+  _S_to_value(value_type&& __x) noexcept
+  { return std::move(__x); }
+
+  static const value_type&
+  _S_to_value(const value_type& __x) noexcept
+  { return __x; }
+
+  template
+	std::pair
+	_M_insert(_Arg&& __arg, const _NodeGenerator& __node_gen,
+		  true_type /* __uks */)
+	{
+	  return _M_insert_unique_aux(
+	_S_to_value(std::forward<_Arg>(__arg)), __node_gen);
+	}
+
   template
 	iterator
 	_M_insert(_Arg&& __arg, const _NodeGenerator& __node_gen,
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_map/cons/56112.cc b/libstdc++-v3/testsuite/23_containers/unordered_map/cons/56112.cc
index c4cdeee234c..8ec0d89af69 100644
--- a/libstdc++-v3/testsuite/23_containers/unordered_map/cons/56112.cc
+++ b/libstdc++-v3/testsuite/23_containers/unordered_map/cons/56112.cc
@@ -1,4 +1,4 @@
-// { dg-do run { target c++11 } }
+// { dg-do compile { target c++11 } }
 
 // Copyright (C) 2013-2022 Free Software Foundation, Inc.
 //
@@ -25,20 +25,23 @@ struct Key
   explicit Key(const int* p) : value(p) { }
   ~Key() { value = nullptr; }
 
-  bool operator==(const Key& k) const { return *value == *k.value; }
+  bool operator==(const Key& k) const
+  { return *value == *k.value; }
 
   const int* value;
 };
 
 struct hash
 {
-  std::size_t operator()(const Key& k) const noexcept { return *k.value; }
+  std::size_t operator()(const Key& k) const noexcept
+  { return *k.value; }
 };
 
 struct S
 {
   int value;
-  operator std::pair() const { return {Key(&value), value}; }
+  operator std::pair() const
+  { return {Key(&value), value}; }
 };
 
 int main()
@@ -46,4 +49,7 @@ int main()
 S s[1] = { {2} };
 std::unordered_map m(s, s+1);
 std::unordered_multimap mm(s, s+1);
+
+m.insert(s, s + 1);
+mm.insert(s, s + 1);
 }
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_set/cons/56112.cc b/libstdc++-v3/testsuite/23_containers/unordered_set/cons/56112.cc
new file mode 100644
index 000..aa34ed4c603
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/unordered_set/cons/56112.cc
@@ -0,0 +1,55 @@
+// { dg-do compile { target c++11 } }
+
+// Copyright (C) 2022 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+
+struct Key
+{
+  explicit Key(const int* p) : value(p) { }
+  ~Key() { value = nullptr; }
+
+  bool operato

Re: libgo patch committed: Update to Go1.18beta2 release

[Eric Botcazou via Gcc-patches]

> I've committed a change to update libgo to the Go1.18beta2 release.

This apparently broke the build on SPARC/Solaris 11.3:

/homes/botcazou/gcc-head/src/libgo/go/runtime/mem_gccgo.go:32:26: error: 
reference to undefined name 'open'
   32 | mmapFD = open(&devZero[0], 0 /* O_RDONLY */, 0)
  |  ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/mem_gccgo.go:35:25: error: 
reference to undefined name 'exit'
   35 | exit(2)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/mem_gccgo.go:56:25: error: 
reference to undefined name 'exit'
   56 | exit(2)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/mem_gccgo.go:60:25: error: 
reference to undefined name 'exit'
   60 | exit(2)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/os_gccgo.go:53:15: error: 
reference to undefined name 'open'
   53 | fd := open(&urandom_dev[0], 0 /* O_RDONLY */, 0)
  |   ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/os_gccgo.go:54:14: error: 
reference to undefined name 'read'
   54 | n := read(fd, unsafe.Pointer(&r[0]), int32(len(r)))
  |  ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/os_gccgo.go:55:9: error: 
reference to undefined name 'closefd'
   55 | closefd(fd)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/panic.go:1077:9: error: 
reference to undefined name 'exit'
 1077 | exit(2)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/panic.go:1115:17: error: 
reference to undefined name 'exit'
 1115 | exit(2)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/panic.go:1172:17: error: 
reference to undefined name 'exit'
 1172 | exit(4)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/panic.go:1176:17: error: 
reference to undefined name 'exit'
 1176 | exit(5)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:312:9: error: reference 
to undefined name 'exit'
  312 | exit(0)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:872:17: error: reference 
to undefined name 'usleep'
  872 | usleep(1000)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:875:9: error: reference 
to undefined name 'usleep'
  875 | usleep(1000)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:877:9: error: reference 
to undefined name 'usleep'
  877 | usleep(1000)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:1493:9: error: reference 
to undefined name 'exitThread'
 1493 | exitThread(&m.freeWait)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:1715:17: error: 
reference to undefined name 'exit'
 1715 | exit(1)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:1926:25: error: 
reference to undefined name 'usleep_no_g'
 1926 | usleep_no_g(1)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:2431:17: error: 
reference to undefined name 'setThreadCPUProfiler'
 2431 | setThreadCPUProfiler(hz)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:4364:9: error: reference 
to undefined name 'setThreadCPUProfiler'
 4364 | setThreadCPUProfiler(0)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:4370:17: error: 
reference to undefined name 'setProcessCPUProfiler'
 4370 | setProcessCPUProfiler(hz)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:4380:17: error: 
reference to undefined name 'setThreadCPUProfiler'
 4380 | setThreadCPUProfiler(hz)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:4846:17: error: 
reference to undefined name 'usleep'
 4846 | usleep(delay)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:5671:57: error: 
reference to undefined name 'usleep'
 5671 | usleep(3)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/runtime.go:35:17: error: 
reference to undefined name 'usleep'
   35 | usleep(100 * 1000)
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/runtime.go:66:9: error: 
reference to undefined name 'exit'
   66 | exit(int32(code))
  | ^
/homes/botcazou/gcc-head/src/libgo/go/runtime/signal_unix.go:662:25: error: 
reference to undefined name 'usleep'
  662 | usleep(5 * 1000 * 1000)
  | ^
/homes/botcazou/gcc-head/src/li

Re: [PATCH] vect+aarch64: Fix ldp_stp_* regressions

[Richard Biener via Gcc-patches]

On Mon, 14 Feb 2022, Richard Sandiford wrote:

> ldp_stp_1.c, ldp_stp_4.c and ldp_stp_5.c have been failing since
> vectorisation was enabled at -O2.  In all three cases SLP is
> generating vector code when scalar code would be better.
> 
> The problem is that the target costs do not model whether STP could
> be used for the scalar or vector code, so the normal latency-based
> costs for store-heavy code can be way off.  It would be good to fix
> that “properly” at some point, but it isn't easy; see the existing
> discussion in aarch64_sve_adjust_stmt_cost for more details.
> 
> This patch therefore adds an on-the-side check for whether the
> code is doing nothing more than set-up+stores.  It then applies
> STP-based costs to those cases only, in addition to the normal
> latency-based costs.  (That is, the vector code has to win on
> both counts rather than on one count individually.)
> 
> However, at the moment, SLP costs one vector set-up instruction
> for every vector in an SLP node, even if the contents are the
> same as a previous vector in the same node.  Fixing the STP costs
> without fixing that would regress other cases, tested in the patch.
> 
> The patch therefore makes the SLP costing code check for duplicates
> within a node.  Ideally we'd check for duplicates more globally,
> but that would require a more global approach to costs: the cost
> of an initialisation should be amoritised across all trees that
> use the initialisation, rather than fully counted against one
> arbitrarily-chosen subtree.
> 
> Back on aarch64: an earlier version of the patch tried to apply
> the new heuristic to constant stores.  However, that didn't work
> too well in practice; see the comments for details.  The patch
> therefore just tests the status quo for constant cases, leaving out
> a match if the current choice is dubious.
> 
> ldp_stp_5.c was affected by the same thing.  The test would be
> worth vectorising if we generated better vector code, but:
> 
> (1) We do a bad job of moving the { -1, 1 } constant, given that
> we have { -1, -1 } and { 1, 1 } to hand.
> 
> (2) The vector code has 6 pairable stores to misaligned offsets.
> We have peephole patterns to handle such misalignment for
> 4 pairable stores, but not 6.
> 
> So the SLP decision isn't wrong as such.  It's just being let
> down by later codegen.
> 
> The patch therefore adds -mstrict-align to preserve the original
> intention of the test while adding ldp_stp_19.c to check for the
> preferred vector code (XFAILed for now).
> 
> Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
> OK for the vectoriser bits?

OK.

Thanks,
Richard.

> Thanks,
> Richard
> 
> 
> gcc/
>   * tree-vectorizer.h (vect_scalar_ops_slice): New struct.
>   (vect_scalar_ops_slice_hash): Likewise.
>   (vect_scalar_ops_slice::op): New function.
>   * tree-vect-slp.cc (vect_scalar_ops_slice::all_same_p): New function.
>   (vect_scalar_ops_slice_hash::hash): Likewise.
>   (vect_scalar_ops_slice_hash::equal): Likewise.
>   (vect_prologue_cost_for_slp): Check for duplicate vectors.
>   * config/aarch64/aarch64.cc
>   (aarch64_vector_costs::m_stp_sequence_cost): New member variable.
>   (aarch64_aligned_constant_offset_p): New function.
>   (aarch64_stp_sequence_cost): Likewise.
>   (aarch64_vector_costs::add_stmt_cost): Handle new STP heuristic.
>   (aarch64_vector_costs::finish_cost): Likewise.
> 
> gcc/testsuite/
>   * gcc.target/aarch64/ldp_stp_5.c: Require -mstrict-align.
>   * gcc.target/aarch64/ldp_stp_14.h,
>   * gcc.target/aarch64/ldp_stp_14.c: New test.
>   * gcc.target/aarch64/ldp_stp_15.c: Likewise.
>   * gcc.target/aarch64/ldp_stp_16.c: Likewise.
>   * gcc.target/aarch64/ldp_stp_17.c: Likewise.
>   * gcc.target/aarch64/ldp_stp_18.c: Likewise.
>   * gcc.target/aarch64/ldp_stp_19.c: Likewise.
> ---
>  gcc/config/aarch64/aarch64.cc | 140 ++
>  gcc/testsuite/gcc.target/aarch64/ldp_stp_14.c |  89 +++
>  gcc/testsuite/gcc.target/aarch64/ldp_stp_14.h |  50 +++
>  gcc/testsuite/gcc.target/aarch64/ldp_stp_15.c | 137 +
>  gcc/testsuite/gcc.target/aarch64/ldp_stp_16.c | 133 +
>  gcc/testsuite/gcc.target/aarch64/ldp_stp_17.c | 120 +++
>  gcc/testsuite/gcc.target/aarch64/ldp_stp_18.c | 123 +++
>  gcc/testsuite/gcc.target/aarch64/ldp_stp_19.c |   6 +
>  gcc/testsuite/gcc.target/aarch64/ldp_stp_5.c  |   2 +-
>  gcc/tree-vect-slp.cc  |  75 ++
>  gcc/tree-vectorizer.h |  35 +
>  11 files changed, 884 insertions(+), 26 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/ldp_stp_14.c
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/ldp_stp_14.h
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/ldp_stp_15.c
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/ldp_stp_16.c
>  create mode 100644 gcc/

[committed] openmp: Make finalize_task_copyfn order reproduceable [PR104517]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase fails -fcompare-debug, because finalize_task_copyfn
was invoked from splay tree destruction, whose order can in some cases
depend on -g/-g0.  The fix is to queue the task stmts that need copyfn
in a vector and run finalize_task_copyfn on elements of that vector.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2022-02-15  Jakub Jelinek  

PR debug/104517
* omp-low.cc (task_cpyfns): New variable.
(delete_omp_context): Don't call finalize_task_copyfn from here.
(create_task_copyfn): Push task_stmt into task_cpyfns.
(execute_lower_omp): Call finalize_task_copyfn here on entries from
task_cpyfns vector and release the vector.

* gcc.dg/gomp/pr104517.c: New test.

--- gcc/omp-low.cc.jj   2022-02-11 00:19:22.343064464 +0100
+++ gcc/omp-low.cc  2022-02-14 13:45:57.311931078 +0100
@@ -191,6 +191,7 @@ static int target_nesting_level;
 static bitmap task_shared_vars;
 static bitmap global_nonaddressable_vars;
 static vec taskreg_contexts;
+static vec task_cpyfns;
 
 static void scan_omp (gimple_seq *, omp_context *);
 static tree scan_omp_1_op (tree *, int *, void *);
@@ -1082,9 +1083,6 @@ delete_omp_context (splay_tree_value val
DECL_ABSTRACT_ORIGIN (t) = NULL;
 }
 
-  if (is_task_ctx (ctx))
-finalize_task_copyfn (as_a  (ctx->stmt));
-
   if (ctx->task_reduction_map)
 {
   ctx->task_reductions.release ();
@@ -11951,6 +11949,7 @@ create_task_copyfn (gomp_task *task_stmt
   size_t looptempno = 0;
 
   child_fn = gimple_omp_task_copy_fn (task_stmt);
+  task_cpyfns.safe_push (task_stmt);
   child_cfun = DECL_STRUCT_FUNCTION (child_fn);
   gcc_assert (child_cfun->cfg == NULL);
   DECL_SAVED_TREE (child_fn) = alloc_stmt_list ();
@@ -14475,6 +14474,10 @@ execute_lower_omp (void)
   && (TREE_CODE (TREE_TYPE (DECL_ARGUMENTS (current_function_decl)))
  == POINTER_TYPE))
 remove_member_access_dummy_vars (DECL_INITIAL (current_function_decl));
+
+  for (auto task_stmt : task_cpyfns)
+finalize_task_copyfn (task_stmt);
+  task_cpyfns.release ();
   return 0;
 }
 
--- gcc/testsuite/gcc.dg/gomp/pr104517.c.jj 2022-02-14 13:43:20.097123092 
+0100
+++ gcc/testsuite/gcc.dg/gomp/pr104517.c2022-02-14 13:42:57.810433826 
+0100
@@ -0,0 +1,54 @@
+/* PR debug/104517 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -fcompare-debug -fopenmp -fno-tree-ter -save-temps" } */
+
+enum {
+  omp_default_mem_alloc,
+  omp_large_cap_mem_alloc,
+  omp_const_mem_alloc,
+  omp_high_bw_mem_alloc
+} omp_allocator_handle_t;
+
+int t, bar_nte, bar_tl, bar_i3, bar_dd;
+
+#pragma omp threadprivate(t)
+#pragma omp declare target
+int f, l, ll, r, r2;
+#pragma omp end declare target
+
+void
+bar (int *idp, int s, int nth, int g, int nta, int fi, int pp, int *q,
+ int ntm)
+{
+  int p = 0, i2 = 0, i1 = 0, m = 0, d = 0;
+
+#pragma omp target parallel for   \
+  device(p) firstprivate (f) allocate (f) in_reduction(+:r2)
+  for (int i = 0; i < 4; i++)
+ll++;
+
+#pragma omp target parallel for \
+  device(d) map (m) \
+  if (target: p) firstprivate (f) defaultmap(tofrom: scalar) is_device_ptr 
(idp) \
+  if (parallel: i2) reduction(+:r) num_threads (nth) linear (ll)\
+  schedule(static) collapse(1) nowait depend(inout: d) allocate (f) \
+  in_reduction(+:r2)
+  for (int i = 0; i < 4; i++)
+ll++;
+
+#pragma omp taskloop simd firstprivate(f) lastprivate(s) grainsize(g) \
+  collapse(1) untied if (i1) final(fi) mergeable nogroup  \
+  priority(pp) linear(ll) aligned(q) allocate(f)
+  for (int i = 0; i < 4; i++)
+ll++;
+
+#pragma omp taskloop simd firstprivate(f) lastprivate(s) num_tasks(nta) \
+  collapse(1) if (i1) final(fi) priority(pp) safelen(8) simdlen(4)  \
+  linear(ll) aligned(q) nontemporal(ntm) order(concurrent) allocate(f)
+  for (int i = 0; i < 4; i++)
+ll++;
+
+#pragma omp parallel master firstprivate(f) shared(nth) proc_bind(spread) \
+  copyin(t) allocate(f)
+  ;
+}

Jakub

[PATCH] fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

[Jakub Jelinek via Gcc-patches]

Hi!

For IBM double double I've added in PR95450 and PR99648 verification that
when we at the tree/GIMPLE or RTL level interpret target bytes as a REAL_CST
or CONST_DOUBLE constant, we try to encode it back to target bytes and
verify it is the same.
This is because our real.c support isn't able to represent all valid values
of IBM double double which has variable precision.
In PR104522, it has been noted that we have similar problem with the
Intel/Motorola extended XFmode formats, our internal representation isn't
able to record pseudo denormals, pseudo infinities, pseudo NaNs and unnormal
values.
So, the following patch is an attempt to extend that verification to all
floats.
Unfortunately, it wasn't that straightforward, because the
__builtin_clear_padding code exactly for the XFmode long doubles needs to
discover what bits are padding and does that by interpreting memory of
all 1s.  That is actually a valid supported value, a qNaN with negative
sign with all mantissa bits set, but the verification includes also the
padding bits (exactly what __builtin_clear_padding wants to figure out)
and so fails the comparison check and so we ICE.
The patch fixes that case by moving that verification from
native_interpret_real to its caller, so that clear_padding_type can
call native_interpret_real and avoid that extra check.

With this, the only thing that regresses in the testsuite is
+FAIL: gcc.target/i386/auto-init-4.c scan-assembler-times long\\t-16843010 5
because it decides to use a pattern that has non-zero bits in the padding
bits of the long double, so the simplify-rtx.cc change prevents folding
a SUBREG into a constant.  We emit (the testcase is -O0 but we emit worse
code at all opt levels) something like:
movabsq $-72340172838076674, %rax
movabsq $-72340172838076674, %rdx
movq%rax, -48(%rbp)
movq%rdx, -40(%rbp)
fldt-48(%rbp)
fstpt   -32(%rbp)
instead of
fldt.LC2(%rip)
fstpt   -32(%rbp)
...
.LC2:
.long   -16843010
.long   -16843010
.long   65278
.long   0
Note, neither of those sequences actually stores the padding bits, fstpt
simply doesn't touch them.
For vars with clear_padding_real_needs_padding_p types that are allocated
to memory at expansion time, I'd say much better would be to do the stores
using integral modes rather than XFmode, so do that:
movabsq $-72340172838076674, %rax
movq%rax, -32(%rbp)
movq%rax, -24(%rbp)
directly.  That is the only way to ensure the padding bits are initialized
(or expand __builtin_clear_padding, but then you initialize separately the
value bits and padding bits).

Bootstrapped/regtested on x86_64-linux and i686-linux, though as mentioned
above, the gcc.target/i386/auto-init-4.c case is unresolved.

2022-02-15  Jakub Jelinek  

PR middle-end/104522
* fold-const.h (native_interpret_real): Declare.
* fold-const.cc (native_interpret_real): No longer static.  Don't
perform MODE_COMPOSITE_P verification here.
(native_interpret_expr) : But perform it here instead
for all modes.
* gimple-fold.cc (clear_padding_type): Call native_interpret_real
instead of native_interpret_expr.
* simplify-rtx.cc (simplify_immed_subreg): Perform the native_encode_rtx
and comparison verification for all FLOAT_MODE_P modes, not just
MODE_COMPOSITE_P.

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

--- gcc/fold-const.h.jj 2022-02-07 21:26:50.717616208 +0100
+++ gcc/fold-const.h2022-02-15 01:16:14.509617954 +0100
@@ -36,6 +36,7 @@ extern int native_encode_expr (const_tre
 extern int native_encode_initializer (tree, unsigned char *, int,
  int off = -1, unsigned char * = nullptr);
 extern tree native_interpret_expr (tree, const unsigned char *, int);
+extern tree native_interpret_real (tree, const unsigned char *, int);
 extern bool can_native_interpret_type_p (tree);
 extern tree native_interpret_aggregate (tree, const unsigned char *, int, int);
 extern tree find_bitfield_repr_type (int, int);
--- gcc/fold-const.cc.jj2022-02-09 22:15:31.805466094 +0100
+++ gcc/fold-const.cc   2022-02-15 01:36:11.988496438 +0100
@@ -8643,7 +8643,7 @@ native_interpret_fixed (tree type, const
the buffer PTR of length LEN as a REAL_CST of type TYPE.
If the buffer cannot be interpreted, return NULL_TREE.  */
 
-static tree
+tree
 native_interpret_real (tree type, const unsigned char *ptr, int len)
 {
   scalar_float_mode mode = SCALAR_FLOAT_TYPE_MODE (type);
@@ -8694,19 +8694,7 @@ native_interpret_real (tree type, const
 }
 
   real_from_target (&r, tmp, mode);
-  tree ret = build_real (type, r);
-  if (MODE_COMPOSITE_P (mode))
-{
-  /* For floating point values in composite modes, punt if this folding
-doesn't preserve bit representation.  As the mode doesn't have fixed
-precision while GCC pretends it does, there c

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

[Zhao Wei Liew via Gcc-patches]

On Tue, 15 Feb 2022 at 13:13, Jason Merrill  wrote:
>
> On 2/14/22 21:30, Zhao Wei Liew wrote:
> > On 14/02/2022, Jason Merrill  wrote:
> >>>
> >>> +/* Returns true if EXPR is a reference to an implicit
> >>> +   call to operator=(). */
> >>> +static bool
> >>> +is_assignment_overload_ref_p (tree expr)
> >>> +{
> >>> +  if (expr == NULL_TREE || !REFERENCE_REF_P (expr))
> >>> +return false;
> >>
> >> This will only warn about op= that returns a reference, which is not
> >> required.
> >>
> >
> > Ah I understand now. I added some new test cases for non-reference return 
> > types
> > and copied some code from extract_call_expr that seems to do what we want.
>
> Good plan, but let's call extract_call_expr rather than copy from it.
>

I agree. However, I can't seem to call extract_call_expr directly
because it calls gcc_assert
to assert that the resulting expression is a CALL_EXPR or AGGR_INIT_EXPR.
Instead, I've extracted the non-assert-related code into a
extract_call_expr_noassert function
and called that instead in the new patch. Is that okay?

> > --- a/gcc/cp/semantics.cc
> > +++ b/gcc/cp/semantics.cc
> > @@ -815,6 +815,33 @@ finish_goto_stmt (tree destination)
> > return add_stmt (build_stmt (input_location, GOTO_EXPR, destination));
> >   }
> >
> > +/* Returns true if CALL is a (possibly wrapped) CALL_EXPR
> > +   to operator=() that is written as an operator expression. */
> > +static bool
> > +is_assignment_op_expr_p(tree call)
>
> Missing space before (
>

Thanks the catch. I've fixed that in the latest patch.

As always, thanks so much for your feedback!

--Everything below is v5 of the patch--

When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:

struct A {
A& operator=(int);
operator bool();
};

void f(A a) {
if (a = 0); // no warning
}

This is because a = 0 is a call to operator=, which GCC does not handle.

This patch fixes this issue by handling calls to operator= when deciding
to warn.

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

v4: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590379.html
Changes since v4:
1. Refactor the non-assert-related code out of extract_call_expr and
   call that function instead to check for call expressions.

v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html
Changes since v3:
1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.

v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.

v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
   operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.

PR c/25689

gcc/cp/ChangeLog:

* call.cc (extract_call_expr): Refactor non-assert code to
  extract_call_expr_noassert.
(extract_call_expr_noassert): Refactor non-assert code.
* cp-tree.h (extract_call_expr_noassert): Add prototype.
* semantics.cc (is_assignment_op_expr_p): Add function to check
  if an expression is a call to an op= operator expression.
(maybe_convert_cond): Handle the case of a op= operator expression
  for the -Wparentheses diagnostic.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wparentheses-31.C: New test.
---
 gcc/cp/call.cc  | 11 +++-
 gcc/cp/cp-tree.h|  1 +
 gcc/cp/semantics.cc | 22 +++-
 gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 62 +
 4 files changed, 94 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index d6eed5ed83510..bead9d6b624c5 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -7059,7 +7059,7 @@ build_op_subscript (const op_location_t &loc, tree obj,
convert_from_reference.  */

 tree
-extract_call_expr (tree call)
+extract_call_expr_noassert (tree call)
 {
   while (TREE_CODE (call) == COMPOUND_EXPR)
 call = TREE_OPERAND (call, 1);
@@ -7090,6 +7090,15 @@ extract_call_expr (tree call)
   default:;
   }

+  return call;
+}
+
+/* Like extract_call_expr_noassert, but also asserts that
+   the extracted expression is indeed a call expression. */
+tree
+extract_call_expr (tree call)
+{
+  call = extract_call_expr_noassert (call);
   gcc_assert (TREE_CODE (call) == CALL_EXPR
  || TREE_CODE (call) == AGGR_INIT_EXPR
  || call == error_mark_node);
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index f253b32c3f21d..19a7a9d2c9334 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6519,6 +

[PATCH] c-family: Fix up shorten_compare for decimal vs. non-decimal float comparison [PR104510]

[Jakub Jelinek via Gcc-patches]

Hi!

The comment in shorten_compare says:
  /* If either arg is decimal float and the other is float, fail.  */
but the callers of shorten_compare don't expect anything like failure
as a possibility from the function, callers require that the function
promotes the operands to the same type, whether the original selected
*restype_ptr one or some shortened.
So, if we choose not to shorten, we should still promote to the original
*restype_ptr.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-02-15  Jakub Jelinek  

PR c/104510
* c-common.cc (shorten_compare): Convert original arguments to
the original *restype_ptr when mixing binary and decimal float.

* gcc.dg/dfp/pr104510.c: New test.

--- gcc/c-family/c-common.cc.jj 2022-02-04 14:36:53.998619364 +0100
+++ gcc/c-family/c-common.cc2022-02-14 19:07:14.305068950 +0100
@@ -3174,7 +3174,11 @@ shorten_compare (location_t loc, tree *o
   else if (real1 && real2
   && (DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (primop0)))
   || DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (primop1)
-return NULL_TREE;
+{
+  type = *restype_ptr;
+  primop0 = op0;
+  primop1 = op1;
+}
 
   else if (real1 && real2
   && (TYPE_PRECISION (TREE_TYPE (primop0))
--- gcc/testsuite/gcc.dg/dfp/pr104510.c.jj  2022-02-14 19:11:05.610860035 
+0100
+++ gcc/testsuite/gcc.dg/dfp/pr104510.c 2022-02-14 19:10:42.819176224 +0100
@@ -0,0 +1,12 @@
+/* PR c/104510 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+float f;
+_Decimal64 d;
+
+int
+foo (void)
+{
+  return d > (_Decimal32) (_Decimal64) f;
+}

Jakub

[committed] sanitizer: Use glibc _thread_db_sizeof_pthread symbol if present

[Jakub Jelinek via Gcc-patches]

Hi!

I've cherry-picked following fix from llvm-project.  Recent glibcs
have _thread_db_sizeof_pthread symbol variable which contains the
size of struct pthread, so that sanitizers don't need to guess that
and risk that it will change again.

The patch is from Florian Weimer.

Bootstrapped/regtested on x86_64-linux and i686-linux, the former
both with old glibc that doesn't have the new symbol and a new one.

Committed to trunk.

2022-02-15  Jakub Jelinek  

* sanitizer_common/sanitizer_linux_libcdep.cpp: Cherry-pick
llvm-project revision ef14b78d9a144ba81ba02083fe21eb286a88732b.

--- libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
+++ libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cpp
@@ -220,10 +220,8 @@ void InitTlsSize() { }
 // sizeof(struct pthread) from glibc.
 static atomic_uintptr_t thread_descriptor_size;
 
-uptr ThreadDescriptorSize() {
-  uptr val = atomic_load_relaxed(&thread_descriptor_size);
-  if (val)
-return val;
+static uptr ThreadDescriptorSizeFallback() {
+  uptr val = 0;
 #if defined(__x86_64__) || defined(__i386__) || defined(__arm__)
   int major;
   int minor;
@@ -285,8 +283,21 @@ uptr ThreadDescriptorSize() {
 #elif defined(__powerpc64__)
   val = 1776; // from glibc.ppc64le 2.20-8.fc21
 #endif
+  return val;
+}
+
+uptr ThreadDescriptorSize() {
+  uptr val = atomic_load_relaxed(&thread_descriptor_size);
   if (val)
-atomic_store_relaxed(&thread_descriptor_size, val);
+return val;
+  // _thread_db_sizeof_pthread is a GLIBC_PRIVATE symbol that is exported in
+  // glibc 2.34 and later.
+  if (unsigned *psizeof = static_cast(
+  dlsym(RTLD_DEFAULT, "_thread_db_sizeof_pthread")))
+val = *psizeof;
+  if (!val)
+val = ThreadDescriptorSizeFallback();
+  atomic_store_relaxed(&thread_descriptor_size, val);
   return val;
 }
 


Jakub

[Patch] Fortran/OpenMP: Fix depend-clause handling

[Tobias Burnus]

As found by Marcel, the 'depend' clause was differently handled in
'omp depobj(...) depend(...)' and in 'omp task depend(...)'.

The problem was that for a scalar pointer, depobj depended
on the pointer address - while task depended on the pointer-target address.

If one now combines depobj and direct var dependency, the dependency
is on different addresses, such that the dependency is not honored.
Marcel's example is testsuite/libgomp.fortran/depend-4.f90.
(Thanks for the report!)


I think in the real world, the problem is not that big as most
code either uses depobj or a variable and does not mix them. Likewise,
using the address of a temporary variable (cf. below) will also usually
work in terms of dependency.


The attached patch does:
- depend clause (as used by task etc):
  For scalar allocatable/pointer, add another dereference

- For depobj (which handles the depend clause by itself)
  - Fix array(element) handling by coping the depend-clause.
Before the result was 'D.123 = var; depobj = &D.123;'
which is really not intended.
  - Several issues related to optional and allocatable/pointer.

OK for mainline? Does backporting to GCC 11 make sense?

Thanks,

Tobias

PS:
* I use the address of the pointer target (and not of the internal
  pointer) variable, which requires that the address to which the pointer
  points makes sense. (Technically, NULL and random value should be also okay, 
I think.)
* Likewise for 'allocatable' - which also requires that the memory
  is allocated.
* OpenMP uses the word 'storage location', which is defined according to the 
last F2F
  meeting as: "A data storage block in memory." (OpenMP Spec Pull Req. #3228)
* On the OpenMP side, there is the discussion to have a dependency on an integer
  value instead of an address. (Motivated by the question whether ptr = NULL;
  (void*)0x123; etc. should be valid or not.) → OpenMP Spec Issue #3226
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
Fortran/OpenMP: Fix depend-clause handling

gcc/fortran/ChangeLog:

	* trans-openmp.cc (gfc_trans_omp_clauses, gfc_trans_omp_depobj):
	Depend on the proper addr, for ptr/alloc depend on pointee.

libgomp/ChangeLog:

	* testsuite/libgomp.fortran/depend-4.f90: New test.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/depend-4.f90: New test.

 gcc/fortran/trans-openmp.cc|  45 -
 gcc/testsuite/gfortran.dg/gomp/depend-4.f90| 240 +
 libgomp/testsuite/libgomp.fortran/depend-4.f90 | 107 +++
 3 files changed, 386 insertions(+), 6 deletions(-)

diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index 0eba0b3c3e1..a85f11e52d4 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -2890,7 +2890,9 @@ gfc_trans_omp_clauses (stmtblock_t *block, gfc_omp_clauses *clauses,
 		  gcc_assert (POINTER_TYPE_P (TREE_TYPE (decl)));
 		  decl = build_fold_indirect_ref (decl);
 		}
-		  else if (DECL_P (decl))
+		  else if (n->sym->attr.allocatable || n->sym->attr.pointer)
+		decl = build_fold_indirect_ref (decl);
+		  if (DECL_P (decl))
 		TREE_ADDRESSABLE (decl) = 1;
 		  OMP_CLAUSE_DECL (node) = decl;
 		}
@@ -5508,12 +5510,43 @@ gfc_trans_omp_depobj (gfc_code *code)
   if (n)
 {
   tree var;
-  if (n->expr)
-var = gfc_convert_expr_to_tree (&block, n->expr);
+  if (n->expr && n->expr->ref->u.ar.type != AR_FULL)
+	{
+	  gfc_init_se (&se, NULL);
+	  if (n->expr->ref->u.ar.type == AR_ELEMENT)
+	{
+	  gfc_conv_expr_reference (&se, n->expr);
+	  var = se.expr;
+	}
+	  else
+	{
+	  gfc_conv_expr_descriptor (&se, n->expr);
+	  var = gfc_conv_array_data (se.expr);
+	}
+	  gfc_add_block_to_block (&block, &se.pre);
+	  gfc_add_block_to_block (&block, &se.post);
+	  gcc_assert (POINTER_TYPE_P (TREE_TYPE (var)));
+	}
   else
-	var = gfc_get_symbol_decl (n->sym);
-  if (!POINTER_TYPE_P (TREE_TYPE (var)))
-var = gfc_build_addr_expr (NULL, var);
+	{
+	  var = gfc_get_symbol_decl (n->sym);
+	  if (POINTER_TYPE_P (TREE_TYPE (var))
+	  && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (TREE_TYPE (var
+	var = build_fold_indirect_ref (var);
+	  if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (var)))
+	{
+	  var = gfc_conv_descriptor_data_get (var);
+	  gcc_assert (POINTER_TYPE_P (TREE_TYPE (var)));
+	}
+	  else if ((n->sym->attr.allocatable || n->sym->attr.pointer)
+		   && n->sym->attr.optional)
+	var = build_fold_indirect_ref (var);
+	  else if (!POINTER_TYPE_P (TREE_TYPE (var)))
+	{
+	  TREE_ADDRESSABLE (var) = 1;
+	  var = gfc_build_addr_expr (NULL, var);
+	}
+	}
   depobj = save_expr (depobj);
   tree r = build_fold_indirect_ref_loc (loc, depobj);
   gfc_add_expr_to_block (&block,
diff 

Contents of PO file 'cpplib-12.1-b20220213.fr.po'

[Translation Project Robot]

cpplib-12.1-b20220213.fr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New French PO file for 'cpplib' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/cpplib/fr.po

(This file, 'cpplib-12.1-b20220213.fr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[PATCH] tree-optimization/104519 - adjust PR100499 niter fix

[Richard Biener via Gcc-patches]

The following adjusts the PR100499 niter fix to use the appropriate
types when checking whether the difference between the final and base
values of the IV are a multiple of the step.  It also gets rid of
an always false condition in multiple_of_p which lead me to a
wrong solution first.

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

2022-02-15  Richard Biener  

PR tree-optimization/104519
* fold-const.cc (multiple_of_p): Remove never true condition.
* tree-ssa-loop-niter.cc (number_of_iterations_ne): Use
the appropriate types for determining whether the difference
of final and base is a multiple of the step.

* gcc.dg/torture/pr104519.c: New testcase.
---
 gcc/fold-const.cc  |  6 +-
 gcc/tree-ssa-loop-niter.cc | 16 +++-
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 386d5732ea0..9d9939642f6 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -14208,11 +14208,7 @@ multiple_of_p (tree type, const_tree top, const_tree 
bottom, bool nowrap)
  && multiple_of_p (type, TREE_OPERAND (top, 2), bottom, nowrap));
 
 case INTEGER_CST:
-  if (TREE_CODE (bottom) != INTEGER_CST
- || integer_zerop (bottom)
- || (TYPE_UNSIGNED (type)
- && (tree_int_cst_sgn (top) < 0
- || tree_int_cst_sgn (bottom) < 0)))
+  if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
return 0;
   return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
SIGNED);
diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 318d10c8fac..9bb5097379b 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -1048,13 +1048,19 @@ number_of_iterations_ne (class loop *loop, tree type, 
affine_iv *iv,
  which the loop exits immediately, and the iv does not overflow.
 
  Also note, we prove condition 2) by checking base and final seperately
- along with condition 1) or 1').  */
+ along with condition 1) or 1').  Since we ensure the difference
+ computation of c does not wrap with cond below and the adjusted s
+ will fit a signed type as well as an unsigned we can safely do
+ this using the type of the IV if it is not pointer typed.  */
+  tree mtype = type;
+  if (POINTER_TYPE_P (type))
+mtype = niter_type;
   if (!niter->control.no_overflow
   && (integer_onep (s)
- || (multiple_of_p (type, fold_convert (niter_type, iv->base), s,
-false)
- && multiple_of_p (type, fold_convert (niter_type, final), s,
-   false
+ || (multiple_of_p (mtype, fold_convert (mtype, iv->base),
+fold_convert (mtype, s), false)
+ && multiple_of_p (mtype, fold_convert (mtype, final),
+   fold_convert (mtype, s), false
 {
   tree t, cond, relaxed_cond = boolean_false_node;
 
-- 
2.34.1

Re: [committed][nvptx] Handle pre-sm_7x shared atomic store using atomic exchange

[Tom de Vries via Gcc-patches]

On 2/15/22 08:34, Thomas Schwinge wrote:

Hi Tom!

For my understanding:

On 2022-02-10T10:13:10+0100, Tom de Vries via Gcc-patches 
 wrote:

The ptx isa specifies (for pre-sm_7x) that atomic operations on shared memory
locations do not guarantee atomicity with respect to normal store instructions
to the same address.

This can be fixed by:
- inserting barriers between normal stores and atomic operations to a common
   address
- using atom.exch to store to locations accessed by other atomic operations.

It's not clearly spelled out which barriers are needed, and a barrier seem more
expensive than atomic exchange.

Implement the pre-sm_7x shared atomic store using atomic exchange.

That includes stores using generic addressing, since those may also point to
shared memory.


It is expected that this changes, for example (similar elsewhere)
'nvptx-none/libatomic/store_4_.o', to use (a) 'atom.exch' (with a new
dummy register allocated)


Yes.

We could do slightly better by emitting that as:
...
membar.sys;
{  .reg .u32 dummy;
   atom.exch.b32 dummy,[%r22],%r23;
}
membar.sys;
...
which could improve register pressure.

I just wrote a patch for that (attached, ftr), but using a scratch 
register, and it seems that this similar code:

...
void
foo (U_4 *mptr, U_4 newval)
{
  __atomic_exchange_n (mptr, newval, 5);
}
...
still maps to:
...
.reg .u32 %r24;
membar.sys;
atom.exch.b32 %r24,[%r22],%r23;
membar.sys;
...
so that may not be the right way to do it.

> and yet (b) 'membar.sys' remains before as well

as after (a):

  .visible .func __atomic_store_4 (.param .u64 %in_ar0, .param .u32 
%in_ar1, .param .u32 %in_ar2)
  {
  .reg .u64 %ar0;
  ld.param.u64 %ar0,[%in_ar0];
  .reg .u32 %ar1;
  ld.param.u32 %ar1,[%in_ar1];
  .reg .u32 %ar2;
  ld.param.u32 %ar2,[%in_ar2];
  .reg .u64 %r22;
  .reg .u32 %r23;
 +.reg .u32 %r25;
  mov.u64 %r22,%ar0;
  mov.u32 %r23,%ar1;
  .loc 2 39 5
  membar.sys;
 -st.u32 [%r22],%r23;
 +atom.exch.b32 %r25,[%r22],%r23;
  membar.sys;
  .loc 2 40 1
  ret;
  }



Yes.  Previously, the barriers where there to guarantee atomicity of the 
store, as well as to implement the memory model MEMMODEL_SEQ_CST.


Now the atomic exchange garantees atomicity of the store and the 
barriers implement the memory model.


In this particular instance (we're using the most severe barrier both 
before and after), we might be able to get away with using a store 
instead of atomic exchange.  But this is a fallback, and we don't care 
so much about performance (besides it's already pretty bad with two 
times membar.sys).


And I rather have atomicity guarantueed by using an atomic insn than by 
using barriers:  there's less room for error by the driver JIT.



And, for example (similar elsewhere) 'nvptx-none/libgomp/single.o', a
'ld' that previously was issued after 'membar.sys' now moves before that
one:

  .visible .func (.param .u64 %value_out) GOMP_single_copy_start
  {
 [...]
  .reg .u64 %r33;
  .reg .u64 %r34;
 [...]
  .reg .pred %r51;
  .reg .u64 %r50;
  .reg .u64 %r52;
 [...]
  ld.shared.u64 %r50,[nvptx_thrs];
  add.u64 %r33,%r50,%r49;
  .loc 2 1317 32
  ld.u64 %r34,[%r33+32];
  .loc 2 1317 6
  setp.eq.u64 %r51,%r34,0;
  @ %r51 bra $L6;
  .loc 4 66 3
 -membar.sys;
  ld.u64 %r52,[%r33+24];
 -st.u64 [%r34+80],%r52;
 +membar.sys;
 +atom.exch.b64 %r53,[%r34+80],%r52;
  $L6:
 [...]

(But I see there is another 'ld.u64 %r34,[%r33+32]' that previously also
already was issued before the 'membar.sys'.)



Before, an atomic store resulted in two seperate insns, a membar and a 
regular store, and so it could be that they became separated.  F.i., if 
alias analysis could prove that the load did not alias with the store, 
it could move the load inbetween.


Now the memmodel is an operand of the insn, and the membar is only 
implemented when printing the insn, so nothing can come inbetween anymore.


Note btw that we had here this pattern:
...
  membar.sys;
  st.u64 [%r34+80],%r52;
...
and there's no memory barrier after the store to guarantee atomicity 
with respect to atomic operations afterwards.


Thanks,
- Tom



Grüße
  Thomas



[nvptx] Handle pre-sm_7x shared atomic store using atomic exchange

gcc/ChangeLog:

2022-02-02  Tom de Vries  

   * config/nvptx/nvptx-protos.h (nvptx_mem_maybe_shared_p): Declare.
   * config/nvptx/nvptx.cc (nvptx_mem_data_area): New static function.
   (nvptx_mem_maybe_shared_p): New function.
   * config/nvptx/nvptx.md (define_expand "atomic_store"): New
   define_expand.

gcc/testsuite/ChangeLog:

2022-02-02  Tom de Vries  

   * gcc.target/nvptx/atomic-store-1.c: New test.
   * gcc.target/nvptx/atomic-store-3.c: New test.
   * gcc.target/nvptx/stack-atomics-run.c: Update.

---
  gcc/config/nvptx/nvptx-protos.h|  1 +
  gcc/config/nvptx/nvptx.cc

Re: [PATCH] fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

[Richard Biener via Gcc-patches]

On Tue, 15 Feb 2022, Jakub Jelinek wrote:

> Hi!
> 
> For IBM double double I've added in PR95450 and PR99648 verification that
> when we at the tree/GIMPLE or RTL level interpret target bytes as a REAL_CST
> or CONST_DOUBLE constant, we try to encode it back to target bytes and
> verify it is the same.
> This is because our real.c support isn't able to represent all valid values
> of IBM double double which has variable precision.
> In PR104522, it has been noted that we have similar problem with the
> Intel/Motorola extended XFmode formats, our internal representation isn't
> able to record pseudo denormals, pseudo infinities, pseudo NaNs and unnormal
> values.
> So, the following patch is an attempt to extend that verification to all
> floats.
> Unfortunately, it wasn't that straightforward, because the
> __builtin_clear_padding code exactly for the XFmode long doubles needs to
> discover what bits are padding and does that by interpreting memory of
> all 1s.  That is actually a valid supported value, a qNaN with negative
> sign with all mantissa bits set, but the verification includes also the
> padding bits (exactly what __builtin_clear_padding wants to figure out)
> and so fails the comparison check and so we ICE.
> The patch fixes that case by moving that verification from
> native_interpret_real to its caller, so that clear_padding_type can
> call native_interpret_real and avoid that extra check.
> 
> With this, the only thing that regresses in the testsuite is
> +FAIL: gcc.target/i386/auto-init-4.c scan-assembler-times long\\t-16843010 5
> because it decides to use a pattern that has non-zero bits in the padding
> bits of the long double, so the simplify-rtx.cc change prevents folding
> a SUBREG into a constant.  We emit (the testcase is -O0 but we emit worse
> code at all opt levels) something like:
> movabsq $-72340172838076674, %rax
> movabsq $-72340172838076674, %rdx
> movq%rax, -48(%rbp)
> movq%rdx, -40(%rbp)
> fldt-48(%rbp)
> fstpt   -32(%rbp)
> instead of
> fldt.LC2(%rip)
> fstpt   -32(%rbp)
> ...
> .LC2:
> .long   -16843010
> .long   -16843010
> .long   65278
> .long   0
> Note, neither of those sequences actually stores the padding bits, fstpt
> simply doesn't touch them.
> For vars with clear_padding_real_needs_padding_p types that are allocated
> to memory at expansion time, I'd say much better would be to do the stores
> using integral modes rather than XFmode, so do that:
> movabsq $-72340172838076674, %rax
>   movq%rax, -32(%rbp)
>   movq%rax, -24(%rbp)
> directly.  That is the only way to ensure the padding bits are initialized
> (or expand __builtin_clear_padding, but then you initialize separately the
> value bits and padding bits).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, though as mentioned
> above, the gcc.target/i386/auto-init-4.c case is unresolved.

OK.

Thanks,
Richard.

> 2022-02-15  Jakub Jelinek  
> 
>   PR middle-end/104522
>   * fold-const.h (native_interpret_real): Declare.
>   * fold-const.cc (native_interpret_real): No longer static.  Don't
>   perform MODE_COMPOSITE_P verification here.
>   (native_interpret_expr) : But perform it here instead
>   for all modes.
>   * gimple-fold.cc (clear_padding_type): Call native_interpret_real
>   instead of native_interpret_expr.
>   * simplify-rtx.cc (simplify_immed_subreg): Perform the native_encode_rtx
>   and comparison verification for all FLOAT_MODE_P modes, not just
>   MODE_COMPOSITE_P.
> 
>   * gcc.dg/pr104522.c: New test.
> 
> --- gcc/fold-const.h.jj   2022-02-07 21:26:50.717616208 +0100
> +++ gcc/fold-const.h  2022-02-15 01:16:14.509617954 +0100
> @@ -36,6 +36,7 @@ extern int native_encode_expr (const_tre
>  extern int native_encode_initializer (tree, unsigned char *, int,
> int off = -1, unsigned char * = nullptr);
>  extern tree native_interpret_expr (tree, const unsigned char *, int);
> +extern tree native_interpret_real (tree, const unsigned char *, int);
>  extern bool can_native_interpret_type_p (tree);
>  extern tree native_interpret_aggregate (tree, const unsigned char *, int, 
> int);
>  extern tree find_bitfield_repr_type (int, int);
> --- gcc/fold-const.cc.jj  2022-02-09 22:15:31.805466094 +0100
> +++ gcc/fold-const.cc 2022-02-15 01:36:11.988496438 +0100
> @@ -8643,7 +8643,7 @@ native_interpret_fixed (tree type, const
> the buffer PTR of length LEN as a REAL_CST of type TYPE.
> If the buffer cannot be interpreted, return NULL_TREE.  */
>  
> -static tree
> +tree
>  native_interpret_real (tree type, const unsigned char *ptr, int len)
>  {
>scalar_float_mode mode = SCALAR_FLOAT_TYPE_MODE (type);
> @@ -8694,19 +8694,7 @@ native_interpret_real (tree type, const
>  }
>  
>real_from_target (&r, tmp, mode);
> -  tree ret = build_real (type, r);
> -  

Re: [Patch] Fortran/OpenMP: Fix depend-clause handling

[Jakub Jelinek via Gcc-patches]

On Tue, Feb 15, 2022 at 11:26:12AM +0100, Tobias Burnus wrote:
> As found by Marcel, the 'depend' clause was differently handled in
> 'omp depobj(...) depend(...)' and in 'omp task depend(...)'.
> 
> The problem was that for a scalar pointer, depobj depended
> on the pointer address - while task depended on the pointer-target address.
> 
> If one now combines depobj and direct var dependency, the dependency
> is on different addresses, such that the dependency is not honored.
> Marcel's example is testsuite/libgomp.fortran/depend-4.f90.
> (Thanks for the report!)
> 
> 
> I think in the real world, the problem is not that big as most
> code either uses depobj or a variable and does not mix them. Likewise,
> using the address of a temporary variable (cf. below) will also usually
> work in terms of dependency.
> 
> 
> The attached patch does:
> - depend clause (as used by task etc):
>   For scalar allocatable/pointer, add another dereference
> 
> - For depobj (which handles the depend clause by itself)
>   - Fix array(element) handling by coping the depend-clause.
> Before the result was 'D.123 = var; depobj = &D.123;'
> which is really not intended.
>   - Several issues related to optional and allocatable/pointer.
> 
> OK for mainline? Does backporting to GCC 11 make sense?

Ok.  Dunno about backporting, perhaps later.

Jakub

Re: [committed][nvptx] Handle pre-sm_7x shared atomic store using atomic exchange

[Thomas Schwinge]

Hi Tom!

On 2022-02-15T11:52:29+0100, Tom de Vries  wrote:
> On 2/15/22 08:34, Thomas Schwinge wrote:
>> For my understanding:

Thanks for your explanations!

>> It is expected that this changes, for example (similar elsewhere)
>> 'nvptx-none/libatomic/store_4_.o', to use (a) 'atom.exch' (with a new
>> dummy register allocated)
>
> Yes.
>
> We could do slightly better by emitting that as:
> ...
> membar.sys;
> {  .reg .u32 dummy;
> atom.exch.b32 dummy,[%r22],%r23;
> }
> membar.sys;
> ...
> which could improve register pressure.

Or, use the "bit bucket" operand -- assuming that's applicable here?

atom.exch.b32 _,[%r22],%r23;

For example, see PTX 3.1, 8.2 "PTX Instructions".


Grüße
 Thomas


> I just wrote a patch for that (attached, ftr), but using a scratch
> register, and it seems that this similar code:
> ...
> void
> foo (U_4 *mptr, U_4 newval)
> {
>__atomic_exchange_n (mptr, newval, 5);
> }
> ...
> still maps to:
> ...
> .reg .u32 %r24;
> membar.sys;
> atom.exch.b32 %r24,[%r22],%r23;
> membar.sys;
> ...
> so that may not be the right way to do it.

> --- a/gcc/config/nvptx/nvptx.md
> +++ b/gcc/config/nvptx/nvptx.md
> @@ -89,9 +89,10 @@
>  ;; only literal constants, which differ from the generic ones, which
>  ;; permit subregs and symbolc constants (as appropriate)
>  (define_predicate "nvptx_register_operand"
> -  (match_code "reg")
> +  (match_code "reg,scratch")
>  {
> -  return register_operand (op, mode);
> +  return (register_operand (op, mode)
> +   || (GET_CODE (op) == SCRATCH && GET_MODE (op) == mode));
>  })
>
>  (define_predicate "nvptx_nonimmediate_operand"
> @@ -188,7 +189,7 @@
>
>  (define_constraint "R"
>"A pseudo register."
> -  (match_code "reg"))
> +  (ior (match_code "reg") (match_code "scratch")))
>
>  (define_constraint "Ia"
>"Any integer constant."
> @@ -2036,6 +2037,7 @@
>   (match_operand:SDIM 2 "nvptx_nonmemory_operand" "Ri"))] ;; input
>""
>{
> +bool scratch_dst_p = GET_CODE (operands[0]) == SCRATCH;
>  if (nvptx_mem_local_p (operands[1]))
>{
>   output_asm_insn ("{", NULL);
> @@ -2047,7 +2049,9 @@
>   return "";
>}
>  const char *t
> -  = "%.\tatom%A1.exch.b%T0\t%0, %1, %2;";
> +  = (scratch_dst_p
> +  ? "{ .reg.u%T0 dummy; %.\tatom%A1.exch.b%T0\t dummy,%1, %2; }"
> +  : "%.\tatom%A1.exch.b%T0\t%0, %1, %2;");
>  return nvptx_output_atomic_insn (t, operands, 1, 3);
>}
>[(set_attr "atomic" "true")])
> @@ -2079,7 +2083,7 @@
>  /* Fall back to expand_atomic_store.  */
>  FAIL;
>
> -  rtx tmpreg = gen_reg_rtx (mode);
> +  rtx tmpreg = gen_rtx_SCRATCH (mode);
>emit_insn (gen_atomic_exchange (tmpreg, operands[0], operands[1],
>   operands[2]));
>DONE;
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

[committed] cygwin: Fix up -Werror=format-diag errors [PR104536]

[Jakub Jelinek via Gcc-patches]

Hi!

As the testcase reports, cygwin has 3 can%'t contractions in diagnostics,
we use cannot everywhere else instead and -Wformat-diag enforces that.

Fixed thusly, untested, committed as obvious to unbreak cygwin bootstraps.

2022-02-15  Jakub Jelinek  

PR target/104536
* config/i386/host-cygwin.cc (cygwin_gt_pch_get_address): Use
cannot instead of can%'t in diagnostics.  Formatting fixes.

--- gcc/config/i386/host-cygwin.cc.jj   2022-01-18 11:58:59.111988785 +0100
+++ gcc/config/i386/host-cygwin.cc  2022-02-15 12:16:10.123180015 +0100
@@ -51,18 +51,18 @@ static void *
 cygwin_gt_pch_get_address (size_t sz, int fd)
 {
   void *base;
-  off_t p = lseek(fd, 0, SEEK_CUR);
+  off_t p = lseek (fd, 0, SEEK_CUR);
 
   if (p == (off_t) -1)
-fatal_error (input_location, "can%'t get position in PCH file: %m");
+fatal_error (input_location, "cannot get position in PCH file: %m");
 
/* Cygwin requires that the underlying file be at least
   as large as the requested mapping.  */
   if ((size_t) p < sz)
-  { 
-if ( ftruncate (fd, sz) == -1 )
-  fatal_error (input_location, "can%'t extend PCH file: %m");
-  }
+{ 
+  if (ftruncate (fd, sz) == -1)
+   fatal_error (input_location, "cannot extend PCH file: %m");
+}
 
   base = mmap (NULL, sz, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
 
@@ -71,8 +71,8 @@ cygwin_gt_pch_get_address (size_t sz, in
   else
 munmap (base, sz);
 
-  if (lseek (fd, p, SEEK_SET) == (off_t) -1 )
-fatal_error (input_location, "can%'t set position in PCH file: %m");
+  if (lseek (fd, p, SEEK_SET) == (off_t) -1)
+fatal_error (input_location, "cannot set position in PCH file: %m");
 
   return base;
 }

Jakub

Re: [committed][nvptx] Handle pre-sm_7x shared atomic store using atomic exchange

[Tom de Vries via Gcc-patches]

On 2/15/22 12:08, Thomas Schwinge wrote:

Hi Tom!

On 2022-02-15T11:52:29+0100, Tom de Vries  wrote:

On 2/15/22 08:34, Thomas Schwinge wrote:

For my understanding:


Thanks for your explanations!


It is expected that this changes, for example (similar elsewhere)
'nvptx-none/libatomic/store_4_.o', to use (a) 'atom.exch' (with a new
dummy register allocated)


Yes.

We could do slightly better by emitting that as:
...
membar.sys;
{  .reg .u32 dummy;
 atom.exch.b32 dummy,[%r22],%r23;
}
membar.sys;
...
which could improve register pressure.


Or, use the "bit bucket" operand -- assuming that's applicable here?

 atom.exch.b32 _,[%r22],%r23;



Ah, yes, that looks exactly what we need, thanks for pointing that out :)

I'll try to create a patch for this.

Thanks,
- Tom


For example, see PTX 3.1, 8.2 "PTX Instructions".


Grüße
  Thomas



I just wrote a patch for that (attached, ftr), but using a scratch
register, and it seems that this similar code:
...
void
foo (U_4 *mptr, U_4 newval)
{
__atomic_exchange_n (mptr, newval, 5);
}
...
still maps to:
...
.reg .u32 %r24;
membar.sys;
atom.exch.b32 %r24,[%r22],%r23;
membar.sys;
...
so that may not be the right way to do it.



--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -89,9 +89,10 @@
  ;; only literal constants, which differ from the generic ones, which
  ;; permit subregs and symbolc constants (as appropriate)
  (define_predicate "nvptx_register_operand"
-  (match_code "reg")
+  (match_code "reg,scratch")
  {
-  return register_operand (op, mode);
+  return (register_operand (op, mode)
+   || (GET_CODE (op) == SCRATCH && GET_MODE (op) == mode));
  })

  (define_predicate "nvptx_nonimmediate_operand"
@@ -188,7 +189,7 @@

  (define_constraint "R"
"A pseudo register."
-  (match_code "reg"))
+  (ior (match_code "reg") (match_code "scratch")))

  (define_constraint "Ia"
"Any integer constant."
@@ -2036,6 +2037,7 @@
   (match_operand:SDIM 2 "nvptx_nonmemory_operand" "Ri"))] ;; input
""
{
+bool scratch_dst_p = GET_CODE (operands[0]) == SCRATCH;
  if (nvptx_mem_local_p (operands[1]))
{
   output_asm_insn ("{", NULL);
@@ -2047,7 +2049,9 @@
   return "";
}
  const char *t
-  = "%.\tatom%A1.exch.b%T0\t%0, %1, %2;";
+  = (scratch_dst_p
+  ? "{ .reg.u%T0 dummy; %.\tatom%A1.exch.b%T0\t dummy,%1, %2; }"
+  : "%.\tatom%A1.exch.b%T0\t%0, %1, %2;");
  return nvptx_output_atomic_insn (t, operands, 1, 3);
}
[(set_attr "atomic" "true")])
@@ -2079,7 +2083,7 @@
  /* Fall back to expand_atomic_store.  */
  FAIL;

-  rtx tmpreg = gen_reg_rtx (mode);
+  rtx tmpreg = gen_rtx_SCRATCH (mode);
emit_insn (gen_atomic_exchange (tmpreg, operands[0], operands[1],
   operands[2]));
DONE;

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

[PATCH] tree-optimization/104543 - fix unroll-and-jam precondition

[Richard Biener via Gcc-patches]

We have to make sure that outer loop exits come after the inner
loop since we otherwise will put it into the fused loop body.

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

2022-02-15  Richard Biener  

PR tree-optimization/104543
* gimple-loop-jam.cc (unroll_jam_possible_p): Check outer loop exits
come after the inner loop.

* gcc.dg/torture/pr104543.c: New testcase.
---
 gcc/gimple-loop-jam.cc  | 10 --
 gcc/testsuite/gcc.dg/torture/pr104543.c | 21 +
 2 files changed, 29 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr104543.c

diff --git a/gcc/gimple-loop-jam.cc b/gcc/gimple-loop-jam.cc
index d9a77727665..e33dd9091df 100644
--- a/gcc/gimple-loop-jam.cc
+++ b/gcc/gimple-loop-jam.cc
@@ -198,7 +198,8 @@ unroll_jam_possible_p (class loop *outer, class loop *loop)
   if (!empty_block_p (loop->latch))
 return false;
 
-  if (!single_exit (loop))
+  edge exit;
+  if (!(exit = single_exit (loop)))
 return false;
 
   /* We need a perfect nest.  Quick check for adjacent inner loops.  */
@@ -259,7 +260,12 @@ unroll_jam_possible_p (class loop *outer, class loop *loop)
   n = get_loop_body_with_size (outer, bbs, n_basic_blocks_for_fn (cfun));
 
   for (i = 0; i < n; i++)
-if (bbs[i]->loop_father == outer && bb_prevents_fusion_p (bbs[i]))
+if (bbs[i]->loop_father == outer
+   && (bb_prevents_fusion_p (bbs[i])
+   /* Outer loop exits must come after the inner loop, otherwise
+  we'll put the outer loop exit into the fused inner loop.  */
+   || (loop_exits_from_bb_p (outer, bbs[i])
+   && !dominated_by_p (CDI_DOMINATORS, bbs[i], exit->src
   break;
   free (bbs);
   if (i != n)
diff --git a/gcc/testsuite/gcc.dg/torture/pr104543.c 
b/gcc/testsuite/gcc.dg/torture/pr104543.c
new file mode 100644
index 000..48963514f77
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr104543.c
@@ -0,0 +1,21 @@
+/* { dg-do run } */
+/* { dg-additional-options "-floop-unroll-and-jam" } */
+
+int a[3], b, c;
+static int e()
+{
+  if (!c) {
+for (b = 0; b < 3; b++)
+  for (c = 0; c < 3; c++)
+a[c] ^= 1;
+return -1;
+  }
+  return 0;
+}
+int main()
+{
+  e();
+  if (a[1] != 1)
+__builtin_abort();
+  return 0;
+}
-- 
2.34.1

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

[Jason Merrill via Gcc-patches]

On 2/15/22 05:06, Zhao Wei Liew wrote:

On Tue, 15 Feb 2022 at 13:13, Jason Merrill  wrote:


On 2/14/22 21:30, Zhao Wei Liew wrote:

On 14/02/2022, Jason Merrill  wrote:


+/* Returns true if EXPR is a reference to an implicit
+   call to operator=(). */
+static bool
+is_assignment_overload_ref_p (tree expr)
+{
+  if (expr == NULL_TREE || !REFERENCE_REF_P (expr))
+return false;


This will only warn about op= that returns a reference, which is not
required.



Ah I understand now. I added some new test cases for non-reference return types
and copied some code from extract_call_expr that seems to do what we want.


Good plan, but let's call extract_call_expr rather than copy from it.



I agree. However, I can't seem to call extract_call_expr directly
because it calls gcc_assert
to assert that the resulting expression is a CALL_EXPR or AGGR_INIT_EXPR.
Instead, I've extracted the non-assert-related code into a
extract_call_expr_noassert function
and called that instead in the new patch. Is that okay?


I think instead of factoring out a new function, let's change the assert 
to an if and return NULL_TREE if it fails.



--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -815,6 +815,33 @@ finish_goto_stmt (tree destination)
 return add_stmt (build_stmt (input_location, GOTO_EXPR, destination));
   }

+/* Returns true if CALL is a (possibly wrapped) CALL_EXPR
+   to operator=() that is written as an operator expression. */
+static bool
+is_assignment_op_expr_p(tree call)


Missing space before (



Thanks the catch. I've fixed that in the latest patch.

As always, thanks so much for your feedback!

--Everything below is v5 of the patch--

When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:

struct A {
A& operator=(int);
operator bool();
};

void f(A a) {
if (a = 0); // no warning
}

This is because a = 0 is a call to operator=, which GCC does not handle.

This patch fixes this issue by handling calls to operator= when deciding
to warn.

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

v4: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590379.html
Changes since v4:
1. Refactor the non-assert-related code out of extract_call_expr and
call that function instead to check for call expressions.

v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html
Changes since v3:
1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.

v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.

v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.

PR c/25689

gcc/cp/ChangeLog:

* call.cc (extract_call_expr): Refactor non-assert code to
  extract_call_expr_noassert.
(extract_call_expr_noassert): Refactor non-assert code.
* cp-tree.h (extract_call_expr_noassert): Add prototype.
* semantics.cc (is_assignment_op_expr_p): Add function to check
  if an expression is a call to an op= operator expression.
(maybe_convert_cond): Handle the case of a op= operator expression
  for the -Wparentheses diagnostic.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wparentheses-31.C: New test.
---
  gcc/cp/call.cc  | 11 +++-
  gcc/cp/cp-tree.h|  1 +
  gcc/cp/semantics.cc | 22 +++-
  gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 62 +
  4 files changed, 94 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index d6eed5ed83510..bead9d6b624c5 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -7059,7 +7059,7 @@ build_op_subscript (const op_location_t &loc, tree obj,
 convert_from_reference.  */

  tree
-extract_call_expr (tree call)
+extract_call_expr_noassert (tree call)
  {
while (TREE_CODE (call) == COMPOUND_EXPR)
  call = TREE_OPERAND (call, 1);
@@ -7090,6 +7090,15 @@ extract_call_expr (tree call)
default:;
}

+  return call;
+}
+
+/* Like extract_call_expr_noassert, but also asserts that
+   the extracted expression is indeed a call expression. */
+tree
+extract_call_expr (tree call)
+{
+  call = extract_call_expr_noassert (call);
gcc_assert (TREE_CODE (call) == CALL_EXPR
  || TREE_CODE (call) == AGGR_INIT_EXPR
  || call == error_mark_node);
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index f253b32c3f21d..19a7a9d2c9334 100644
--- 

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

[Jason Merrill via Gcc-patches]

On 2/15/22 07:48, Jason Merrill wrote:

On 2/15/22 05:06, Zhao Wei Liew wrote:

On Tue, 15 Feb 2022 at 13:13, Jason Merrill  wrote:


On 2/14/22 21:30, Zhao Wei Liew wrote:

On 14/02/2022, Jason Merrill  wrote:


+/* Returns true if EXPR is a reference to an implicit
+   call to operator=(). */
+static bool
+is_assignment_overload_ref_p (tree expr)
+{
+  if (expr == NULL_TREE || !REFERENCE_REF_P (expr))
+    return false;


This will only warn about op= that returns a reference, which is not
required.



Ah I understand now. I added some new test cases for non-reference 
return types
and copied some code from extract_call_expr that seems to do what we 
want.


Good plan, but let's call extract_call_expr rather than copy from it.



I agree. However, I can't seem to call extract_call_expr directly
because it calls gcc_assert
to assert that the resulting expression is a CALL_EXPR or AGGR_INIT_EXPR.
Instead, I've extracted the non-assert-related code into a
extract_call_expr_noassert function
and called that instead in the new patch. Is that okay?


I think instead of factoring out a new function, let's change the assert 
to an if and return NULL_TREE if it fails.


Incidentally, the subject should be "c++:" instead of "c:".

Also, it doesn't look like you have a copyright assignment with the FSF, 
so you will need to add a DCO sign-off to your patches; see 
https://gcc.gnu.org/dco.html for more information.


I'd suggest putting your revision history before the scissors line, as 
that doesn't need to be part of the commit message.


And the latest patch didn't apply easily because this line:

>> diff --git a/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
>> b/gcc/testsuite/g++.dg/warn/Wparentheses-31.C

got wrapped in transit.

Jason


--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -815,6 +815,33 @@ finish_goto_stmt (tree destination)
 return add_stmt (build_stmt (input_location, GOTO_EXPR, 
destination));

   }

+/* Returns true if CALL is a (possibly wrapped) CALL_EXPR
+   to operator=() that is written as an operator expression. */
+static bool
+is_assignment_op_expr_p(tree call)


Missing space before (



Thanks the catch. I've fixed that in the latest patch.

As always, thanks so much for your feedback!

--Everything below is v5 of the patch--

When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:

struct A {
A& operator=(int);
operator bool();
};

void f(A a) {
if (a = 0); // no warning
}

This is because a = 0 is a call to operator=, which GCC does not handle.

This patch fixes this issue by handling calls to operator= when deciding
to warn.

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

v4: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590379.html
Changes since v4:
1. Refactor the non-assert-related code out of extract_call_expr and
    call that function instead to check for call expressions.

v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html
Changes since v3:
1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.

v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.

v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
    operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.

PR c/25689

gcc/cp/ChangeLog:

* call.cc (extract_call_expr): Refactor non-assert code to
  extract_call_expr_noassert.
(extract_call_expr_noassert): Refactor non-assert code.
* cp-tree.h (extract_call_expr_noassert): Add prototype.
* semantics.cc (is_assignment_op_expr_p): Add function to check
  if an expression is a call to an op= operator expression.
(maybe_convert_cond): Handle the case of a op= operator expression
  for the -Wparentheses diagnostic.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wparentheses-31.C: New test.
---
  gcc/cp/call.cc  | 11 +++-
  gcc/cp/cp-tree.h    |  1 +
  gcc/cp/semantics.cc | 22 +++-
  gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 62 +
  4 files changed, 94 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index d6eed5ed83510..bead9d6b624c5 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -7059,7 +7059,7 @@ build_op_subscript (const op_location_t &loc, 
tree obj,

 convert_from_reference.  */

  tree
-extract_call_expr (tree call)
+extract_call_expr_noassert (tree call)
  {
    while (TREE_CODE (call) == COMPOUND_EXPR)
  cal

Re: [PATCH, OpenACC] Add support for gang local storage allocation in shared memory

[Julian Brown]

On Mon, 14 Feb 2022 16:56:35 +0100
Thomas Schwinge  wrote:

> Hi Julian!
> 
> Two more questions here, in context of 
> "[12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932
> since r12-980-g29a2f51806c":
> 
> On 2019-06-03T17:02:45+0100, Julian Brown 
> wrote:
> > +/* Record vars listed in private clauses in CLAUSES in CTX.  This
> > information
> > +   is used to mark up variables that should be made private
> > per-gang.  */ +
> > +static void
> > +oacc_record_private_var_clauses (omp_context *ctx, tree clauses)
> > +{
> > +  tree c;
> > +
> > +  if (!ctx)
> > +return;
> > +
> > +  for (c = clauses; c; c = OMP_CLAUSE_CHAIN (c))
> > +if (OMP_CLAUSE_CODE (c) == OMP_CLAUSE_PRIVATE)
> > +  {
> > +   tree decl = OMP_CLAUSE_DECL (c);
> > +   if (VAR_P (decl) && TREE_ADDRESSABLE (decl))
> > + ctx->oacc_addressable_var_decls->safe_push (decl);
> > +  }
> > +}  
> 
> So, here we analyze 'OMP_CLAUSE_DECL (c)' (as is, without translation
> through 'lookup_decl (decl, ctx)')...

I think you're right that this one should be using lookup_decl, but...

> > +/* Record addressable vars declared in BINDVARS in CTX.  This
> > information is
> > +   used to mark up variables that should be made private per-gang.
> >  */ +
> > +static void
> > +oacc_record_vars_in_bind (omp_context *ctx, tree bindvars)
> > +{
> > +  if (!ctx)
> > +return;
> > +
> > +  for (tree v = bindvars; v; v = DECL_CHAIN (v))
> > +if (VAR_P (v) && TREE_ADDRESSABLE (v))
> > +  ctx->oacc_addressable_var_decls->safe_push (v);
> > +}  
> 
> ..., and similarly here analyze 'v' (without 'lookup_decl (v,
> ctx)')...

I'm not so sure about this one: if the variables are declared at a
particular binding level, I think they have to be in the current OMP
context (and thus shadow any definitions that might be present in the
parent context)? Maybe that can be confirmed via an assertion.

> > +/* Mark addressable variables which are declared implicitly or
> > explicitly as
> > +   gang private with a special attribute.  These may need to have
> > their
> > +   declarations altered later on in compilation (e.g. in
> > +   execute_oacc_device_lower or the backend, depending on how the
> > OpenACC
> > +   execution model is implemented on a given target) to ensure
> > that sharing
> > +   semantics are correct.  */
> > +
> > +static void
> > +mark_oacc_gangprivate (vec *decls, omp_context *ctx)
> > +{
> > +  int i;
> > +  tree decl;
> > +
> > +  FOR_EACH_VEC_ELT (*decls, i, decl)
> > +{
> > +  for (omp_context *thisctx = ctx; thisctx; thisctx =
> > thisctx->outer)
> > +   {
> > + tree inner_decl = maybe_lookup_decl (decl, thisctx);
> > + if (inner_decl)
> > +   {
> > + decl = inner_decl;
> > + break;
> > +   }
> > +   }
> > +  if (!lookup_attribute ("oacc gangprivate", DECL_ATTRIBUTES
> > (decl)))
> > +   {
> > + if (dump_file && (dump_flags & TDF_DETAILS))
> > +   {
> > + fprintf (dump_file,
> > +  "Setting 'oacc gangprivate' attribute for
> > decl:");
> > + print_generic_decl (dump_file, decl, TDF_SLIM);
> > + fputc ('\n', dump_file);
> > +   }
> > + DECL_ATTRIBUTES (decl)
> > +   = tree_cons (get_identifier ("oacc gangprivate"),
> > +NULL, DECL_ATTRIBUTES (decl));
> > +   }
> > +}
> > +}  
> 
> ..., but here we action on the 'maybe_lookup_decl'-translated
> 'inner_decl', if applicable.  In certain cases that one may be
> different from the original 'decl'.  (In particular (only?), when the
> OMP lowering has made 'decl' "late 'TREE_ADDRESSABLE'".)  This
> assymetry I understand to give rise to 
> "[12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932
> since r12-980-g29a2f51806c".
> 
> It makes sense to me that we do the OpenACC privatization on the
> 'lookup_decl' -- but shouldn't we then do that in the analysis phase,
> too?  (This appears to work fine for OpenACC 'private' clauses (...,
> and avoids marking a few as addressable/gang-private), and for those
> in 'gimple_bind_vars' it doesn't seem to make a difference (for the
> current test cases and/or compiler transformations).)

Yes, I think you're right.

> And, second question: what case did you run into or foresee, that you
> here need the 'thisctx' loop and 'maybe_lookup_decl', instead of a
> plain 'lookup_decl (decl, ctx)'?  Per my testing that's sufficient.

I'd probably misunderstood about lookup_decl walking up through parent
contexts itself... oops.

> Unless you think this needs more consideration, I suggest to do these
> two changes.  (I have a WIP patch in testing.)

Sounds good to me.

Thank you,

Julian

[committed] libstdc++: Add missing constexpr to uses-allocator construction utilities [PR104542]

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

PR libstdc++/104542
* include/bits/uses_allocator_args.h (make_obj_using_allocator)
(uninitialized_construct_using_allocator): Add constexpr.
* testsuite/20_util/uses_allocator/make_obj.cc: Check constexpr.
* testsuite/20_util/uses_allocator/uninitialized_construct.cc: New test.
---
 .../include/bits/uses_allocator_args.h|  4 +--
 .../20_util/uses_allocator/make_obj.cc| 30 ++-
 .../uses_allocator/uninitialized_construct.cc | 17 +++
 3 files changed, 48 insertions(+), 3 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/20_util/uses_allocator/uninitialized_construct.cc

diff --git a/libstdc++-v3/include/bits/uses_allocator_args.h 
b/libstdc++-v3/include/bits/uses_allocator_args.h
index a3aa37d8e78..d92dd1f0901 100644
--- a/libstdc++-v3/include/bits/uses_allocator_args.h
+++ b/libstdc++-v3/include/bits/uses_allocator_args.h
@@ -196,7 +196,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 }
 
   template
-inline _Tp
+constexpr _Tp
 make_obj_using_allocator(const _Alloc& __a, _Args&&... __args)
 {
   return std::make_from_tuple<_Tp>(
@@ -205,7 +205,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 }
 
   template
-inline _Tp*
+constexpr _Tp*
 uninitialized_construct_using_allocator(_Tp* __p, const _Alloc& __a,
_Args&&... __args)
 {
diff --git a/libstdc++-v3/testsuite/20_util/uses_allocator/make_obj.cc 
b/libstdc++-v3/testsuite/20_util/uses_allocator/make_obj.cc
index cd4497e8410..2dd0f819657 100644
--- a/libstdc++-v3/testsuite/20_util/uses_allocator/make_obj.cc
+++ b/libstdc++-v3/testsuite/20_util/uses_allocator/make_obj.cc
@@ -142,7 +142,7 @@ test01()
   VERIFY( c2.alloc_id == 1 );
 }
 
-void 
+void
 test02()
 {
   decltype(auto) b
@@ -389,6 +389,34 @@ test08()
   std::make_obj_using_allocator(a);
 }
 
+constexpr bool
+test_pr104542()
+{
+  // PR libstdc++/104542 - missing constexpr
+  std::allocator a;
+  int i = std::make_obj_using_allocator(a, 1);
+
+  struct X {
+using allocator_type = std::allocator;
+constexpr X(std::allocator_arg_t, std::allocator, int i) : i(i+1) { }
+int i;
+  };
+
+  X x = std::make_obj_using_allocator(a, i);
+
+  struct Y {
+using allocator_type = std::allocator;
+constexpr Y(X x, std::allocator) : i(x.i+1) { }
+int i;
+  };
+
+  Y y = std::make_obj_using_allocator(a, x);
+
+  return y.i == 3;
+}
+
+static_assert( test_pr104542() );
+
 int
 main()
 {
diff --git 
a/libstdc++-v3/testsuite/20_util/uses_allocator/uninitialized_construct.cc 
b/libstdc++-v3/testsuite/20_util/uses_allocator/uninitialized_construct.cc
new file mode 100644
index 000..f403cbe99cc
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/uses_allocator/uninitialized_construct.cc
@@ -0,0 +1,17 @@
+// { dg-options "-std=gnu++20" }
+// { dg-do compile { target c++20 } }
+
+#include 
+
+constexpr bool
+test_pr104542()
+{
+  // PR libstdc++/104542 - missing constexpr
+  std::allocator a;
+  int* p = a.allocate(1);
+  int i = *std::uninitialized_construct_using_allocator(p, a, 999);
+  a.deallocate(p, 1);
+  return i == 999;
+}
+
+static_assert( test_pr104542() );
-- 
2.34.1

[PATCH] tree-optimization/96881 - CD-DCE and CLOBBERs

[Richard Biener via Gcc-patches]

CD-DCE does not consider CLOBBERs as necessary in the attempt
to not prevent DCE of SSA defs it uses.  A side-effect of that
is that it also removes all its control dependences if they are
not made necessary by other means.  When we later try to preserve
as many CLOBBERs as possible we have to make sure we also
preserved the controlling conditions, otherwise a CLOBBER can
now appear on a path where it was not executed before, leading
to wrong code as seen in the testcase.

This removes 20570 clobbers early, and 2642 and 957 in the two
late CD-DCE passes during stage2 in gcc/ - note almost all
of those are direct clobbers, if only tracking indirect clobbers
lazily we remove 39, 12 and 5.

It FAILs the stack coalescing test g++.dg/opt/pr80032.C which
can be only recovered if we never DCE paths to direct clobbers
(and thus those clobbers).  The pattern there is
if (pred) D.2512 = CLOBBER; else D.2512 = CLOBBER;, basically
we have all paths leading to the same clobber but we could
safely cut some branches which we do not realize.

Handling indirect vs. direct clobbers differently feels wrong,
so the option would be to simply stop removing control flow
to clobbers.  Elsewhere we noticed though that we elide
all indirect clobbers only after the last CD-DCE.  Removing
conditional clobbers too early might also inhibit DSE after
inlining, so maybe we should rather keep them and try to
optimize things elsewhere?

The aggressive clobber removal variant patch also causes

In destructor 'auto_timevar::~auto_timevar()',
inlined from 'void c_parser_declaration_or_fndef(c_parser*, bool, bool, 
bool, bool, bool, tree_node**, vec*, bool, tree, oacc_routine_data*, 
bool*' at /home/rguenther/src/gcc3/gcc/c/c-parser.cc:2569:7:
/home/rguenther/src/gcc3/gcc/timevar.h:247:20: error: dangling pointer to 'at' 
may be used [-Werror=dangling-pointer=]
  247 |   m_timer->pop (m_tv);
  |   ~^~

and a lot more dangling-pointer diagnostics during bootstrap.

When trying to avoid control DCE for all clobber kinds we end
up miscompiling g++.dg/pr64191.C.  So the only working solution
I found is handling indirect clobbers different from direct ones
with regard to control DCE.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Thoughts?

Thanks,
Richard.

2022-02-15  Richard Biener  

PR tree-optimization/96881
* tree-ssa-dce.cc (mark_stmt_if_obviously_necessary): Comment
CLOBBER handling.
(eliminate_unnecessary_stmts): Check that we preserved control
parents before retaining a CLOBBER.
(perform_tree_ssa_dce): Pass down aggressive flag
to eliminate_unnecessary_stmts.

* g++.dg/torture/pr96881-1.C: New testcase.
* g++.dg/torture/pr96881-2.C: Likewise.
---
 gcc/testsuite/g++.dg/torture/pr96881-1.C | 37 
 gcc/testsuite/g++.dg/torture/pr96881-2.C | 37 
 gcc/tree-ssa-dce.cc  | 13 ++---
 3 files changed, 83 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/torture/pr96881-1.C
 create mode 100644 gcc/testsuite/g++.dg/torture/pr96881-2.C

diff --git a/gcc/testsuite/g++.dg/torture/pr96881-1.C 
b/gcc/testsuite/g++.dg/torture/pr96881-1.C
new file mode 100644
index 000..1c182e6a8b3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr96881-1.C
@@ -0,0 +1,37 @@
+/* { dg-do run } */
+
+struct S { int s; ~S () {} } s;
+
+void __attribute__((noipa))
+foo (struct S *s, int flag)
+{
+  s->s = 1;
+  // We have to makes sure to not make the inlined CLOBBER
+  // unconditional but we have to remove it to be able
+  // to elide the branch
+  if (!flag)
+return;
+  s->~S();
+}
+
+void __attribute__((noipa))
+bar (struct S *s, int flag)
+{
+  s->s = 1;
+  // CD-DCE chooses an arbitrary path, try to present it
+  // with all variants
+  if (flag)
+s->~S();
+}
+
+int
+main ()
+{
+  foo (&s, 0);
+  if (s.s != 1)
+__builtin_abort ();
+  bar (&s, 0);
+  if (s.s != 1)
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/testsuite/g++.dg/torture/pr96881-2.C 
b/gcc/testsuite/g++.dg/torture/pr96881-2.C
new file mode 100644
index 000..35c788791e8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr96881-2.C
@@ -0,0 +1,37 @@
+/* { dg-do run } */
+
+struct S { int s; ~S () {} } s;
+
+void __attribute__((noipa))
+foo (int flag)
+{
+  s.s = 1;
+  // We have to makes sure to not make the inlined CLOBBER
+  // unconditional but we have to remove it to be able
+  // to elide the branch
+  if (!flag)
+return;
+  s.~S();
+}
+
+void __attribute__((noipa))
+bar (int flag)
+{
+  s.s = 1;
+  // CD-DCE chooses an arbitrary path, try to present it
+  // with all variants
+  if (flag)
+s.~S();
+}
+
+int
+main ()
+{
+  foo (0);
+  if (s.s != 1)
+__builtin_abort ();
+  bar (0);
+  if (s.s != 1)
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-ssa-dce.cc b/gcc/tree-ssa-dce.cc
index f1034878eaf..9aefdc1c8d3 100644
--- a/gcc/tree-ssa

Re: [PATCH, rs6000] Remove TImode from mode iterator BOOL_128 [PR100694]

[Segher Boessenkool]

On Tue, Feb 15, 2022 at 11:01:03AM +0800, HAO CHEN GUI wrote:
Hi!

> On 15/2/2022 上午 5:36, Segher Boessenkool wrote:
> > On Wed, Feb 09, 2022 at 10:43:17AM +0800, HAO CHEN GUI wrote:
> > All that are arguments for expanding to split form, not for removing
> > TImode from the iterator.  And you leave PTImode, which *always* is in
> > GPRs!
> >From my understanding, PTImode has limitation that it needs to be assigned
> with an even/odd register pair. So it can't be split before the reload pass.

TImode is put in an even/odd pair always as well.  What is special about
PTImode here?

> Currently it is split after reload.>

This prevents almost all optimisations.  Splits after reload should be a
last resort thing.  They almost always cause bigger problems than what
they are meant to solve.  There aren't many splitters that *have* to run
after RA!

> > (You'll also have to show it is *correct*, you need to prove (or show it
> > really likely :-) ) that after this change there are no TImode things
> > generated anywhere (anywhere!) that are no longer handled now).
> > 
> Yes, the TI may be generated after expand pass and causes ICEs. So how about
> creating two mode iterators? One is for expand which doesn't include TImode,
> another is for the split which include TImode and make TImode to be split
> as early as possible?

You can also have the expanders fail for TImode?  That gives you a good
place to put in a code comment as well ;-)


Segher

Re: [PATCH] tree-optimization/96881 - CD-DCE and CLOBBERs

[Jan Hubicka via Gcc-patches]

> @@ -1272,7 +1275,7 @@ maybe_optimize_arith_overflow (gimple_stmt_iterator 
> *gsi,
> contributes nothing to the program, and can be deleted.  */
>  
>  static bool
> -eliminate_unnecessary_stmts (void)
> +eliminate_unnecessary_stmts (bool aggressive)
>  {
>bool something_changed = false;
>basic_block bb;
> @@ -1366,7 +1369,9 @@ eliminate_unnecessary_stmts (void)
> break;
>   }
>   }
> -   if (!dead)
> +   if (!dead
> +   && (!aggressive
> +   || bitmap_bit_p (visited_control_parents, bb->index)))

It seems to me that it may be worth to consider case where
visited_control_parents is 0 while all basic blocks in the CD relation
are live for different reasons.  I suppose this can happen in more
complex CFGs when the other arms of conditionals are live...

Honza
>   {
> bitmap_clear (debug_seen);
> continue;
> @@ -1876,7 +1881,7 @@ perform_tree_ssa_dce (bool aggressive)
>propagate_necessity (aggressive);
>BITMAP_FREE (visited);
>  
> -  something_changed |= eliminate_unnecessary_stmts ();
> +  something_changed |= eliminate_unnecessary_stmts (aggressive);
>something_changed |= cfg_altered;
>  
>/* We do not update postdominators, so free them unconditionally.  */
> -- 
> 2.34.1

Re: libgo patch committed: Update to Go1.18beta2 release

[Ian Lance Taylor via Gcc-patches]

Thanks, I'm working on it.  I'm having some trouble with the Solaris
machines I have access to.

Ian

On Tue, Feb 15, 2022, 1:20 AM Eric Botcazou via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:

> > I've committed a change to update libgo to the Go1.18beta2 release.
>
> This apparently broke the build on SPARC/Solaris 11.3:
>
> /homes/botcazou/gcc-head/src/libgo/go/runtime/mem_gccgo.go:32:26: error:
> reference to undefined name 'open'
>32 | mmapFD = open(&devZero[0], 0 /* O_RDONLY */, 0)
>   |  ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/mem_gccgo.go:35:25: error:
> reference to undefined name 'exit'
>35 | exit(2)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/mem_gccgo.go:56:25: error:
> reference to undefined name 'exit'
>56 | exit(2)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/mem_gccgo.go:60:25: error:
> reference to undefined name 'exit'
>60 | exit(2)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/os_gccgo.go:53:15: error:
> reference to undefined name 'open'
>53 | fd := open(&urandom_dev[0], 0 /* O_RDONLY */, 0)
>   |   ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/os_gccgo.go:54:14: error:
> reference to undefined name 'read'
>54 | n := read(fd, unsafe.Pointer(&r[0]), int32(len(r)))
>   |  ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/os_gccgo.go:55:9: error:
> reference to undefined name 'closefd'
>55 | closefd(fd)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/panic.go:1077:9: error:
> reference to undefined name 'exit'
>  1077 | exit(2)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/panic.go:1115:17: error:
> reference to undefined name 'exit'
>  1115 | exit(2)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/panic.go:1172:17: error:
> reference to undefined name 'exit'
>  1172 | exit(4)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/panic.go:1176:17: error:
> reference to undefined name 'exit'
>  1176 | exit(5)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:312:9: error:
> reference
> to undefined name 'exit'
>   312 | exit(0)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:872:17: error:
> reference
> to undefined name 'usleep'
>   872 | usleep(1000)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:875:9: error:
> reference
> to undefined name 'usleep'
>   875 | usleep(1000)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:877:9: error:
> reference
> to undefined name 'usleep'
>   877 | usleep(1000)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:1493:9: error:
> reference
> to undefined name 'exitThread'
>  1493 | exitThread(&m.freeWait)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:1715:17: error:
> reference to undefined name 'exit'
>  1715 | exit(1)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:1926:25: error:
> reference to undefined name 'usleep_no_g'
>  1926 | usleep_no_g(1)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:2431:17: error:
> reference to undefined name 'setThreadCPUProfiler'
>  2431 | setThreadCPUProfiler(hz)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:4364:9: error:
> reference
> to undefined name 'setThreadCPUProfiler'
>  4364 | setThreadCPUProfiler(0)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:4370:17: error:
> reference to undefined name 'setProcessCPUProfiler'
>  4370 | setProcessCPUProfiler(hz)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:4380:17: error:
> reference to undefined name 'setThreadCPUProfiler'
>  4380 | setThreadCPUProfiler(hz)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:4846:17: error:
> reference to undefined name 'usleep'
>  4846 | usleep(delay)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/proc.go:5671:57: error:
> reference to undefined name 'usleep'
>  5671 | usleep(3)
>   | ^
> /homes/botcazou/gcc-head/src/libgo/go/runtime/runtime.go:35:17: error:
> reference to undefined name 'usleep'
>35 | usleep(100 * 1000)
>   | ^
> /

[PATCH] PR tree-optimization/104526 - Use GORI to evaluate arguments of a COND_EXPR.

[Andrew MacLeod via Gcc-patches]

As requested in the PR, this patch wires GORI into the evaluation of a 
COND_EXPR.  This late in the cycle, we'll keep it simple.


given   COND ? X : Y

if there is any dependency between COND and X or COND and Y, we use the 
GORI engine to determine the range of the SSA_NAME in COND when its TRUE 
and when its FALSE and then use those values  to solve for any dependent 
name in X and/or Y.


IE, in the testcase:

_11 = (unsigned int) _2;
_12 = _11 + 1;
_3 = _12 <= 2 ? _2 : 0;

GORI detects the dependency between _12 and _2, and can calculate that 
_2 is [-1, 1] in the true clause based on the restriction that  [1,1] = 
_12 <= 2


Limitations:  I kept it simple. It requires
- COND is a COMPARISON_CLASS_P  expression with a single SSA_NAME, (ie  
_12 > 45,   but not h_5 < j_2)
- one or both of the  2 operands must be a dependant of the name (_12) 
in the condition.
- This doesn't include the full bidirectional recomputations like 
outgoing edge does, ie


_11 = (unsigned int) _2;
_12 = _11 + 1;
_22 = _12 + 3
_3 = _12 <= 2 ? _22 : 0;

This patch will not recompute _12 to be [2,4] as the dependency goes the 
other way (_22 is dependant on _12, not vice versa)  I can do that for 
next release unless its an issue for this one


Half of the patch is outputting listing info.  There isn't really much 
new, just connecting a couple of existing wires.


In the next stage1, I will will COND_EXPR into the complete outgoing 
edge mechanism more seamlessly so it can take better advantages of 
everything available (like relations too).


Bootstraps on x86_64-pc-linux-gnu with no regressions.  But I'm running 
it through again to be sure.   OK for trunk, or want to wait for the 
next release?


Andrew
commit 496e3d19a8570d4d62a64bd540ce86bc1ddef219
Author: Andrew MacLeod 
Date:   Mon Feb 14 19:43:40 2022 -0500

Use GORI to evaluate arguments of a COND_EXPR.

Provide an API into gori to perform a basic evaluation of the arguments of a
COND_EXPR if they are in the dependency chain of the condition.

PR tree-optimization/104526
gcc/
* gimple-range-fold.cc (fold_using_range::range_of_cond_expr): Call
new routine.
* gimple-range-gori.cc (range_def_chain::get_def_chain): Force a build
of dependency chain if there isn't one.
(gori_compute::condexpr_adjust): New.
* gimple-range-gori.h (class gori_compute): New prototype.

gcc/testsuite/
* gcc.dg/pr104526.c: New.

diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index 2ac7562aceb..a62b954d013 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -1273,6 +1273,18 @@ fold_using_range::range_of_cond_expr  (irange &r, gassign *s, fur_source &src)
   src.get_operand (range1, op1);
   src.get_operand (range2, op2);
 
+  // Try to see if there is a dependence between the COND and either operand
+  if (src.gori ())
+if (src.gori ()->condexpr_adjust (range1, range2, s, cond, op1, op2, src))
+  if (dump_file && (dump_flags & TDF_DETAILS))
+	{
+	  fprintf (dump_file, "Possible COND_EXPR adjustment. Range op1 : ");
+	  range1.dump(dump_file);
+	  fprintf (dump_file, " and Range op2: ");
+	  range2.dump(dump_file);
+	  fprintf (dump_file, "\n");
+	}
+
   // If the condition is known, choose the appropriate expression.
   if (cond_range.singleton_p ())
 {
diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 3e5328389c0..99cc5c1f3c4 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -334,7 +334,7 @@ range_def_chain::get_def_chain (tree name)
   unsigned v = SSA_NAME_VERSION (name);
 
   // If it has already been processed, just return the cached value.
-  if (has_def_chain (name))
+  if (has_def_chain (name) && m_def_chain[v].bm)
 return m_def_chain[v].bm;
 
   // No definition chain for default defs.
@@ -1303,6 +1303,99 @@ gori_compute::outgoing_edge_range_p (irange &r, edge e, tree name,
   return false;
 }
 
+// Given COND ? OP1 : OP2 with ranges R1 for OP1 and R2 for OP2, Use gori
+// to further resolve R1 and R2 if there are any dependencies between
+// OP1 and COND or OP2 and COND.  All values can are to be calculated using SRC
+// as the origination source location for operands..
+// Effectively, use COND an the edge condition and solve for OP1 on the true
+// edge and OP2 on the false edge.
+
+bool
+gori_compute::condexpr_adjust (irange &r1, irange &r2, gimple *, tree cond,
+			   tree op1, tree op2, fur_source &src)
+{
+  int_range_max tmp, cond_true, cond_false;
+  tree ssa1 = gimple_range_ssa_p (op1);
+  tree ssa2 = gimple_range_ssa_p (op2);
+  if (!ssa1 && !ssa2)
+return false;
+  if (!COMPARISON_CLASS_P (cond))
+return false;
+  range_operator *hand = range_op_handler (TREE_CODE (cond), TREE_TYPE (op1));
+  if (!hand)
+return false;
+
+  tree c1 = gimple_range_ssa_p (TREE_OPERAND (cond, 0));
+  tree c2 = gimple_range_ssa_p (TREE_OPERAND 

Re: [PATCH] PR tree-optimization/104526 - Use GORI to evaluate arguments of a COND_EXPR.

[Jakub Jelinek via Gcc-patches]

On Tue, Feb 15, 2022 at 10:46:21AM -0500, Andrew MacLeod wrote:
> Bootstraps on x86_64-pc-linux-gnu with no regressions.  But I'm running it
> through again to be sure.   OK for trunk, or want to wait for the next
> release?

I'd like to see it in GCC 12 because it is a fix for a P1 regression.

> +bool
> +gori_compute::condexpr_adjust (irange &r1, irange &r2, gimple *, tree cond,
> +tree op1, tree op2, fur_source &src)
> +{
> +  int_range_max tmp, cond_true, cond_false;
> +  tree ssa1 = gimple_range_ssa_p (op1);
> +  tree ssa2 = gimple_range_ssa_p (op2);
> +  if (!ssa1 && !ssa2)
> +return false;
> +  if (!COMPARISON_CLASS_P (cond))
> +return false;
> +  range_operator *hand = range_op_handler (TREE_CODE (cond), TREE_TYPE 
> (op1));

Maybe I'm missing something, but I would expect calling range_op_handler
with the type of the comparison operands, i.e.
TREE_TYPE (TREE_OPERAND (cond, 0))
or so, rather than the type of lhs/op1/op2.
The comparison arguments could have a different type from lhs/op1/op2...

Otherwise LGTM, but my knowledge about ranger is very limited.

Jakub

Re: [PATCH] PR tree-optimization/104526 - Use GORI to evaluate arguments of a COND_EXPR.

[Andrew MacLeod via Gcc-patches]

On 2/15/22 10:56, Jakub Jelinek wrote:



+bool
+gori_compute::condexpr_adjust (irange &r1, irange &r2, gimple *, tree cond,
+  tree op1, tree op2, fur_source &src)
+{
+  int_range_max tmp, cond_true, cond_false;
+  tree ssa1 = gimple_range_ssa_p (op1);
+  tree ssa2 = gimple_range_ssa_p (op2);
+  if (!ssa1 && !ssa2)
+return false;
+  if (!COMPARISON_CLASS_P (cond))
+return false;
+  range_operator *hand = range_op_handler (TREE_CODE (cond), TREE_TYPE (op1));

Maybe I'm missing something, but I would expect calling range_op_handler
with the type of the comparison operands, i.e.
TREE_TYPE (TREE_OPERAND (cond, 0))
or so, rather than the type of lhs/op1/op2.
The comparison arguments could have a different type from lhs/op1/op2...


, true that.  I will make that adjustment.

Andrew

Re: [PATCH] fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

[Qing Zhao via Gcc-patches]

> On Feb 15, 2022, at 3:58 AM, Jakub Jelinek  wrote:
> 
> Hi!
> 
> For IBM double double I've added in PR95450 and PR99648 verification that
> when we at the tree/GIMPLE or RTL level interpret target bytes as a REAL_CST
> or CONST_DOUBLE constant, we try to encode it back to target bytes and
> verify it is the same.
> This is because our real.c support isn't able to represent all valid values
> of IBM double double which has variable precision.
> In PR104522, it has been noted that we have similar problem with the
> Intel/Motorola extended XFmode formats, our internal representation isn't
> able to record pseudo denormals, pseudo infinities, pseudo NaNs and unnormal
> values.
> So, the following patch is an attempt to extend that verification to all
> floats.
> Unfortunately, it wasn't that straightforward, because the
> __builtin_clear_padding code exactly for the XFmode long doubles needs to
> discover what bits are padding and does that by interpreting memory of
> all 1s.  That is actually a valid supported value, a qNaN with negative
> sign with all mantissa bits set, but the verification includes also the
> padding bits (exactly what __builtin_clear_padding wants to figure out)
> and so fails the comparison check and so we ICE.
> The patch fixes that case by moving that verification from
> native_interpret_real to its caller, so that clear_padding_type can
> call native_interpret_real and avoid that extra check.
> 
> With this, the only thing that regresses in the testsuite is
> +FAIL: gcc.target/i386/auto-init-4.c scan-assembler-times long\\t-16843010 5
> because it decides to use a pattern that has non-zero bits in the padding
> bits of the long double, so the simplify-rtx.cc change prevents folding
> a SUBREG into a constant.  We emit (the testcase is -O0 but we emit worse
> code at all opt levels) something like:
>movabsq $-72340172838076674, %rax
>movabsq $-72340172838076674, %rdx
>movq%rax, -48(%rbp)
>movq%rdx, -40(%rbp)
>fldt-48(%rbp)
>fstpt   -32(%rbp)
> instead of
>fldt.LC2(%rip)
>fstpt   -32(%rbp)
> ...
> .LC2:
>.long   -16843010
>.long   -16843010
>.long   65278
>.long   0
> Note, neither of those sequences actually stores the padding bits, fstpt
> simply doesn't touch them.
> For vars with clear_padding_real_needs_padding_p types that are allocated
> to memory at expansion time, I'd say much better would be to do the stores
> using integral modes rather than XFmode, so do that:
>movabsq $-72340172838076674, %rax
>   movq%rax, -32(%rbp)
>   movq%rax, -24(%rbp)
> directly.  That is the only way to ensure the padding bits are initialized
> (or expand __builtin_clear_padding, but then you initialize separately the
> value bits and padding bits).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, though as mentioned
> above, the gcc.target/i386/auto-init-4.c case is unresolved.

Thanks, I will try to fix this testing case in a later patch.

Qing
> 

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

[Zhao Wei Liew via Gcc-patches]

On Tue, 15 Feb 2022 at 21:05, Jason Merrill  wrote:
> >>
> >> I agree. However, I can't seem to call extract_call_expr directly
> >> because it calls gcc_assert
> >> to assert that the resulting expression is a CALL_EXPR or
AGGR_INIT_EXPR.
> >> Instead, I've extracted the non-assert-related code into a
> >> extract_call_expr_noassert function
> >> and called that instead in the new patch. Is that okay?
> >
> > I think instead of factoring out a new function, let's change the assert
> > to an if and return NULL_TREE if it fails.
>

I've adjusted the patch as advised. What do you think?

> Incidentally, the subject should be "c++:" instead of "c:".
>

Ah, I see. I found it a bit odd that gcc-commit-mklog auto-generated a
subject with "c:",
but I just went with it as I didn't know any better. Unfortunately, I can't
change it now on
the current thread.

> Also, it doesn't look like you have a copyright assignment with the FSF,
> so you will need to add a DCO sign-off to your patches; see
> https://gcc.gnu.org/dco.html for more information.
>
> I'd suggest putting your revision history before the scissors line, as
> that doesn't need to be part of the commit message.
>

Got it. Made the changes in the latest patch.

> And the latest patch didn't apply easily because this line:
>
>  >> diff --git a/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
>  >> b/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
>
> got wrapped in transit.
>

Ah, I didn't notice that. Sorry about that! I'm kinda new to the whole
mailing list
setup so there are some kinks I have to iron out.

v5: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590393.html
Changes since v5:
1. Revert changes in v4.
2. Replace gcc_assert with a return NULL_TREE in extract_call_expr.

v4: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590379.html
Changes since v4:
1. Refactor the non-assert-related code out of extract_call_expr and
   call that function instead to check for call expressions.

v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html
Changes since v3:
1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.

v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.

v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
   operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.


-- Everything below is patch v6 --

When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:

struct A {
A& operator=(int);
operator bool();
};

void f(A a) {
if (a = 0); // no warning
}

This is because a = 0 is a call to operator=, which GCC does not handle.

This patch fixes this issue by handling calls to operator= when deciding
to warn.

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

PR c++/25689

gcc/cp/ChangeLog:

* call.cc (extract_call_expr): Return a NULL_TREE on failure
  instead of asserting.
* semantics.cc (is_assignment_op_expr_p): Add function to check
  if an expression is a call to an op= operator expression.
(maybe_convert_cond): Handle the case of a op= operator expression
  for the -Wparentheses diagnostic.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wparentheses-31.C: New test.

Signed-off-by: Zhao Wei Liew 
---
 gcc/cp/call.cc  |  7 ++-
 gcc/cp/semantics.cc | 20 ++-
 gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 62 +
 3 files changed, 85 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index d6eed5ed835..3b2c6d8c499 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -7090,9 +7090,10 @@ extract_call_expr (tree call)
   default:;
   }

-  gcc_assert (TREE_CODE (call) == CALL_EXPR
- || TREE_CODE (call) == AGGR_INIT_EXPR
- || call == error_mark_node);
+  if (TREE_CODE (call) != CALL_EXPR
+  && TREE_CODE (call) != AGGR_INIT_EXPR
+  && call != error_mark_node)
+return NULL_TREE;
   return call;
 }

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0cb17a6a8ab..7a8f317af0d 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -815,6 +815,24 @@ finish_goto_stmt (tree destination)
   return add_stmt (build_stmt (input_location, GOTO_EXPR, destination));
 }

+/* Returns true if CALL is a (possibly wrapped) CALL_EXPR or AGGR_INIT_EXPR
+   to operator=() that is written as an operator expression. */
+static bool
+is_assignment_op_expr_p (tree call)
+{
+  if (call 

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

[Zhao Wei Liew via Gcc-patches]

On Wed, 16 Feb 2022 at 00:30, Zhao Wei Liew  wrote:

> On Tue, 15 Feb 2022 at 21:05, Jason Merrill  wrote:
> > >>
> > >> I agree. However, I can't seem to call extract_call_expr directly
> > >> because it calls gcc_assert
> > >> to assert that the resulting expression is a CALL_EXPR or
> AGGR_INIT_EXPR.
> > >> Instead, I've extracted the non-assert-related code into a
> > >> extract_call_expr_noassert function
> > >> and called that instead in the new patch. Is that okay?
> > >
> > > I think instead of factoring out a new function, let's change the
> assert
> > > to an if and return NULL_TREE if it fails.
> >
>
> I've adjusted the patch as advised. What do you think?
>
> > Incidentally, the subject should be "c++:" instead of "c:".
> >
>
> Ah, I see. I found it a bit odd that gcc-commit-mklog auto-generated a
> subject with "c:",
> but I just went with it as I didn't know any better. Unfortunately, I
> can't change it now on
> the current thread.
>
> > Also, it doesn't look like you have a copyright assignment with the FSF,
> > so you will need to add a DCO sign-off to your patches; see
> > https://gcc.gnu.org/dco.html for more information.
> >
> > I'd suggest putting your revision history before the scissors line, as
> > that doesn't need to be part of the commit message.
> >
>
> Got it. Made the changes in the latest patch.
>
> > And the latest patch didn't apply easily because this line:
> >
> >  >> diff --git a/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
> >  >> b/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
> >
> > got wrapped in transit.
> >
>
> Ah, I didn't notice that. Sorry about that! I'm kinda new to the whole
> mailing list
> setup so there are some kinks I have to iron out.
>
> v5: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590393.html
> Changes since v5:
> 1. Revert changes in v4.
> 2. Replace gcc_assert with a return NULL_TREE in extract_call_expr.
>
> v4: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590379.html
> Changes since v4:
> 1. Refactor the non-assert-related code out of extract_call_expr and
>call that function instead to check for call expressions.
>
> v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html
> Changes since v3:
> 1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.
>
> v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
> Changes since v2:
> 1. Add more test cases in Wparentheses-31.C.
> 2. Refactor added logic to a function (is_assignment_overload_ref_p).
> 3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
> Changes since v1:
> 1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
>operator=() calls.
> 2. Use INDIRECT_REF_P to filter implicit operator=() calls.
> 3. Use cp_get_callee_fndecl_nofold.
> 4. Add spaces before (.
>
>
> -- Everything below is patch v6 --
>
> When compiling the following code with g++ -Wparentheses, GCC does not
> warn on the if statement. For example, there is no warning for this code:
>
> struct A {
>   A& operator=(int);
>   operator bool();
> };
>
> void f(A a) {
>   if (a = 0); // no warning
> }
>
> This is because a = 0 is a call to operator=, which GCC does not handle.
>
> This patch fixes this issue by handling calls to operator= when deciding
> to warn.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
>   PR c++/25689
>
> gcc/cp/ChangeLog:
>
>   * call.cc (extract_call_expr): Return a NULL_TREE on failure
> instead of asserting.
>   * semantics.cc (is_assignment_op_expr_p): Add function to check
> if an expression is a call to an op= operator expression.
>   (maybe_convert_cond): Handle the case of a op= operator expression
> for the -Wparentheses diagnostic.
>
> gcc/testsuite/ChangeLog:
>
>   * g++.dg/warn/Wparentheses-31.C: New test.
>
> Signed-off-by: Zhao Wei Liew 
> ---
>  gcc/cp/call.cc  |  7 ++-
>  gcc/cp/semantics.cc | 20 ++-
>  gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 62 +
>  3 files changed, 85 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C
>
> diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
> index d6eed5ed835..3b2c6d8c499 100644
> --- a/gcc/cp/call.cc
> +++ b/gcc/cp/call.cc
> @@ -7090,9 +7090,10 @@ extract_call_expr (tree call)
>default:;
>}
>
> -  gcc_assert (TREE_CODE (call) == CALL_EXPR
> -   || TREE_CODE (call) == AGGR_INIT_EXPR
> -   || call == error_mark_node);
> +  if (TREE_CODE (call) != CALL_EXPR
> +  && TREE_CODE (call) != AGGR_INIT_EXPR
> +  && call != error_mark_node)
> +return NULL_TREE;
>return call;
>  }
>
> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> index 0cb17a6a8ab..7a8f317af0d 100644
> --- a/gcc/cp/semantics.cc
> +++ b/gcc/cp/semantics.cc
> @@ -815,6 +815,24 @@ finish_goto_stmt (tree destination)

Re: [Patch] Fortran/OpenMP: Fix depend-clause handling

[Thomas Schwinge]

Hi!

On 2022-02-15T11:26:12+0100, Tobias Burnus  wrote:
> As found by Marcel, the 'depend' clause was differently handled in
> 'omp depobj(...) depend(...)' and in 'omp task depend(...)'.

(Cross-referencing GCC PR104545 "[OpenMP & Fortran] Pointers issue in
combination of depobj construct and depend clause with depobj
dependence-type".)

> The attached patch [...]

>  gcc/fortran/trans-openmp.cc|  45 -
>  gcc/testsuite/gfortran.dg/gomp/depend-4.f90| 240 
> +
>  libgomp/testsuite/libgomp.fortran/depend-4.f90 | 107 +++

The actual commit r12-7242-g3939c1b11279dc950d2f160eb940dd791f7b40f1
"Fortran/OpenMP: Fix depend-clause handling" also has:

|  gcc/testsuite/gfortran.dg/gomp/depend-5.f90|  82 +

... (yay for more test cases!), and that one I see partially FAIL in
x86_64 '-m32'/'-mx32' testing:

FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\(\\*\\(integer\\(kind=16\\)\\[0:\\] \\* 
restrict\\) aaa.data\\)\\[aaa.offset \\+ 2\\]\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\(\\*\\(integer\\(kind=16\\)\\[0:\\] \\* 
restrict\\) daaa->data\\)\\[daaa->offset \\+ 2\\]\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\(\\*\\(integer\\(kind=16\\)\\[0:\\] \\* 
restrict\\) doaaa->data\\)\\[doaaa->offset \\+ 2\\]\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\(\\*daa\\)\\[1\\]\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\(\\*doaa\\)\\[1\\]\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\(integer\\(kind=16\\) \\*\\) \\(aap.data 
\\+ \\(sizetype\\) \\(\\(aap.offset \\+ aap.dim\\[0\\].stride \\* 2\\) \\* 
aap.span\\)\\)\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\(integer\\(kind=16\\) \\*\\) 
\\(daap->data \\+ \\(sizetype\\) \\(\\(daap->offset \\+ daap->dim\\[0\\].stride 
\\* 2\\) \\* daap->span\\)\\)\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\(integer\\(kind=16\\) \\*\\) 
\\(doaap->data \\+ \\(sizetype\\) \\(\\(doaap->offset \\+ 
doaap->dim\\[0\\].stride \\* 2\\) \\* doaap->span\\)\\)\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\*dosa\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\*dosp\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\*dsa\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\*dsp\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*doss\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*dss\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*sa\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*sp\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:aa\\[1\\]\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:ss\\)" 1
PASS: gfortran.dg/gomp/depend-5.f90   -O  (test for excess errors)


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

Contents of PO file 'cpplib-12.1-b20220213.zh_TW.po'

[Translation Project Robot]

cpplib-12.1-b20220213.zh_TW.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Chinese (traditional) PO file for 'cpplib' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Chinese (traditional) team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/zh_TW.po

(This file, 'cpplib-12.1-b20220213.zh_TW.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[Patch] Fortran/OpenMP: Fix depend-clause handling for c_ptr (was: [Patch] Fortran/OpenMP: Fix depend-clause handling)

[Tobias Burnus]

On 15.02.22 11:56, Jakub Jelinek wrote:

On Tue, Feb 15, 2022 at 11:26:12AM +0100, Tobias Burnus wrote:

As found by Marcel, the 'depend' clause was differently handled in
'omp depobj(...) depend(...)' and in 'omp task depend(...)'.


As Marcel reported, there was still a problem with c_ptr.

Looking at the dump, I also spotted that for a nonoptional dummy
argument, scalar allocatable/pointers should have a '*' for depobj,
which I fixed. I additionally added a VALUE attribute test.

I then copied the depend-4.f90 to depend-6.f90 and replaced 'integer' by
'type(c_ptr)' as depend-clause variable (and 'integer(kind=4)' by 'void
*' in the expected dump). Otherwise, those two files should be identical.

I hope it now works and I did not miss anything in the dump.

OK?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
Fortran/OpenMP: Fix depend-clause handling for c_ptr

gcc/fortran/ChangeLog:

	* trans-openmp.cc (gfc_trans_omp_depobj): Fix to alloc/ptr dummy
	and for c_ptr.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/depend-4.f90: Add VALUE test, update scan test.
	* gfortran.dg/gomp/depend-5.f90: Fix scan tree for -m32.
	* gfortran.dg/gomp/depend-6.f90: New test.

 gcc/fortran/trans-openmp.cc |   7 +-
 gcc/testsuite/gfortran.dg/gomp/depend-4.f90 |  29 +++-
 gcc/testsuite/gfortran.dg/gomp/depend-5.f90 |  12 +-
 gcc/testsuite/gfortran.dg/gomp/depend-6.f90 | 259 
 4 files changed, 295 insertions(+), 12 deletions(-)

diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index e1c9d46add6..4d56a771349 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -5536,9 +5536,12 @@ gfc_trans_omp_depobj (gfc_code *code)
 	  gcc_assert (POINTER_TYPE_P (TREE_TYPE (var)));
 	}
 	  else if ((n->sym->attr.allocatable || n->sym->attr.pointer)
-		   && n->sym->attr.optional)
+		   && n->sym->attr.dummy)
 	var = build_fold_indirect_ref (var);
-	  else if (!POINTER_TYPE_P (TREE_TYPE (var)))
+	  else if (!POINTER_TYPE_P (TREE_TYPE (var))
+		   || (n->sym->ts.f90_type == BT_VOID
+		   && !POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (var)))
+		   && !GFC_ARRAY_TYPE_P (TREE_TYPE (TREE_TYPE (var)
 	{
 	  TREE_ADDRESSABLE (var) = 1;
 	  var = gfc_build_addr_expr (NULL, var);
diff --git a/gcc/testsuite/gfortran.dg/gomp/depend-4.f90 b/gcc/testsuite/gfortran.dg/gomp/depend-4.f90
index d6686c1e48f..f6cf2fd2dd4 100644
--- a/gcc/testsuite/gfortran.dg/gomp/depend-4.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/depend-4.f90
@@ -7,7 +7,8 @@
 ! For pointers, it depends on the address of the pointer target
 ! For allocatable, on the allocated memory address
 
-subroutine foo(dss, dsp, dsa, daa, daaa, daap, doss, dosp, dosa, doaa, doaaa, doaap)
+subroutine foo(dss, dsp, dsa, daa, daaa, daap, doss, dosp, dosa, doaa, doaaa, doaap, &
+   dssv, dossv)
   !use omp_lib
   use iso_c_binding, only: c_intptr_t
   implicit none (type, external)
@@ -18,8 +19,10 @@ subroutine foo(dss, dsp, dsa, daa, daaa, daap, doss, dosp, dosa, doaa, doaaa, do
   optional :: doss, dosp, dosa, doaa, doaaa, doaap
   allocatable :: sa, aaa, dsa, daaa, dosa, doaaa
   pointer :: sp, aap, dsp, daap, dosp, doaap
+  integer, value :: dssv, dossv
+  optional :: dossv
 
-  integer(omp_depend_kind) :: object(18)
+  integer(omp_depend_kind) :: object(20)
   integer(omp_depend_kind) :: elem(9)
 
   !$omp depobj(object(1)) depend(in: ss)
@@ -40,6 +43,8 @@ subroutine foo(dss, dsp, dsa, daa, daaa, daap, doss, dosp, dosa, doaa, doaaa, do
   !$omp depobj(object(16)) depend(in: doaa)
   !$omp depobj(object(17)) depend(in: doaaa)
   !$omp depobj(object(18)) depend(in: doaap)
+  !$omp depobj(object(19)) depend(in: dssv)
+  !$omp depobj(object(20)) depend(in: dossv)
 
   !$omp depobj(elem(1)) depend(in: aa(2))
   !$omp depobj(elem(2)) depend(in: aaa(2))
@@ -107,6 +112,12 @@ subroutine foo(dss, dsp, dsa, daa, daaa, daap, doss, dosp, dosa, doaa, doaaa, do
 !$omp task depend(out: doaap)
   doaap = 4
 !$omp end task
+!$omp task depend(out: dossv)
+  dossv = 4
+!$omp end task
+!$omp task depend(out: dssv)
+  dssv = 4
+!$omp end task
 
 !$omp task depend(out: aa(2))
   aa(2) = 4
@@ -168,8 +179,8 @@ end
 ! { dg-final { scan-tree-dump-times "&object\\\[4\\\] = .integer.kind=4.\\\[0:\\\] \\* restrict\\) aaa.data;" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "&object\\\[5\\\] = .integer.kind=4.\\\[0:\\\] \\*\\) aap.data;" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "&object\\\[6\\\] = dss;" 1 "original" } }
-! { dg-final { scan-tree-dump-times "&object\\\[7\\\] = dsp;" 1 "original" } }
-! { dg-final { scan-tree-dump-times "&object\\\[8\\\] = dsa;" 1 "original" } }
+! { dg-final { scan-tree-dump-times "&obje

[PATCH] c-family: Remove names of unused parameters

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, OK for trunk?

-- >8 --

C++ allows unnamed parameters, which means we don't need to call them
'dummy' and mark them with the unused attribute.

gcc/c-family/ChangeLog:

* c-pragma.cc (handle_pragma_pack): Remove parameter name.
(handle_pragma_weak): Likewise.
(handle_pragma_scalar_storage_order): Likewise.
(handle_pragma_redefine_extname): Likewise.
(handle_pragma_visibility): Likewise.
(handle_pragma_diagnostic): Likewise.
(handle_pragma_target): Likewise.
(handle_pragma_optimize): Likewise.
(handle_pragma_push_options): Likewise.
(handle_pragma_pop_options): Likewise.
(handle_pragma_reset_options): Likewise.
(handle_pragma_message): Likewise.
(handle_pragma_float_const_decimal64): Likewise.
---
 gcc/c-family/c-pragma.cc | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/gcc/c-family/c-pragma.cc b/gcc/c-family/c-pragma.cc
index 9004b04c613..4c80bdd26d6 100644
--- a/gcc/c-family/c-pragma.cc
+++ b/gcc/c-family/c-pragma.cc
@@ -132,7 +132,7 @@ pop_alignment (tree id)
#pragma pack (pop)
#pragma pack (pop, ID) */
 static void
-handle_pragma_pack (cpp_reader * ARG_UNUSED (dummy))
+handle_pragma_pack (cpp_reader *)
 {
   location_t loc;
   tree x, id = 0;
@@ -355,7 +355,7 @@ maybe_apply_pending_pragma_weaks (void)
 
 /* #pragma weak name [= value] */
 static void
-handle_pragma_weak (cpp_reader * ARG_UNUSED (dummy))
+handle_pragma_weak (cpp_reader *)
 {
   tree name, value, x, decl;
   enum cpp_ttype t;
@@ -418,7 +418,7 @@ maybe_apply_pragma_scalar_storage_order (tree type)
 }
 
 static void
-handle_pragma_scalar_storage_order (cpp_reader *ARG_UNUSED(dummy))
+handle_pragma_scalar_storage_order (cpp_reader *)
 {
   const char *kind_string;
   enum cpp_ttype token;
@@ -499,7 +499,7 @@ static void handle_pragma_redefine_extname (cpp_reader *);
 
 /* #pragma redefine_extname oldname newname */
 static void
-handle_pragma_redefine_extname (cpp_reader * ARG_UNUSED (dummy))
+handle_pragma_redefine_extname (cpp_reader *)
 {
   tree oldname, newname, decls, x;
   enum cpp_ttype t;
@@ -721,7 +721,7 @@ pop_visibility (int kind)
specified on the command line.  */
 
 static void
-handle_pragma_visibility (cpp_reader *dummy ATTRIBUTE_UNUSED)
+handle_pragma_visibility (cpp_reader *)
 {
   /* Form is #pragma GCC visibility push(hidden)|pop */
   tree x;
@@ -765,7 +765,7 @@ handle_pragma_visibility (cpp_reader *dummy 
ATTRIBUTE_UNUSED)
 }
 
 static void
-handle_pragma_diagnostic(cpp_reader *ARG_UNUSED(dummy))
+handle_pragma_diagnostic(cpp_reader *)
 {
   tree x;
   location_t loc;
@@ -899,7 +899,7 @@ handle_pragma_diagnostic(cpp_reader *ARG_UNUSED(dummy))
 
 /*  Parse #pragma GCC target (xxx) to set target specific options.  */
 static void
-handle_pragma_target(cpp_reader *ARG_UNUSED(dummy))
+handle_pragma_target(cpp_reader *)
 {
   location_t loc;
   enum cpp_ttype token;
@@ -971,7 +971,7 @@ handle_pragma_target(cpp_reader *ARG_UNUSED(dummy))
 
 /* Handle #pragma GCC optimize to set optimization options.  */
 static void
-handle_pragma_optimize (cpp_reader *ARG_UNUSED(dummy))
+handle_pragma_optimize (cpp_reader *)
 {
   enum cpp_ttype token;
   tree x;
@@ -1057,7 +1057,7 @@ static GTY(()) struct opt_stack * options_stack;
options.  */
 
 static void
-handle_pragma_push_options (cpp_reader *ARG_UNUSED(dummy))
+handle_pragma_push_options (cpp_reader *)
 {
   enum cpp_ttype token;
   tree x = 0;
@@ -1093,7 +1093,7 @@ handle_pragma_push_options (cpp_reader *ARG_UNUSED(dummy))
optimization options from a previous push_options.  */
 
 static void
-handle_pragma_pop_options (cpp_reader *ARG_UNUSED(dummy))
+handle_pragma_pop_options (cpp_reader *)
 {
   enum cpp_ttype token;
   tree x = 0;
@@ -1150,7 +1150,7 @@ handle_pragma_pop_options (cpp_reader *ARG_UNUSED(dummy))
optimization options to the original options used on the command line.  */
 
 static void
-handle_pragma_reset_options (cpp_reader *ARG_UNUSED(dummy))
+handle_pragma_reset_options (cpp_reader *)
 {
   enum cpp_ttype token;
   tree x = 0;
@@ -1186,7 +1186,7 @@ handle_pragma_reset_options (cpp_reader 
*ARG_UNUSED(dummy))
 /* Print a plain user-specified message.  */
 
 static void
-handle_pragma_message (cpp_reader *ARG_UNUSED(dummy))
+handle_pragma_message (cpp_reader *)
 {
   location_t loc;
   enum cpp_ttype token;
@@ -1291,7 +1291,7 @@ handle_stdc_pragma (const char *pname)
#pragma STDC FLOAT_CONST_DECIMAL64 DEFAULT */
 
 static void
-handle_pragma_float_const_decimal64 (cpp_reader *ARG_UNUSED (dummy))
+handle_pragma_float_const_decimal64 (cpp_reader *)
 {
   if (c_dialect_cxx ())
 {
-- 
2.34.1

Re: [Patch] Fortran/OpenMP: Fix depend-clause handling for c_ptr (was: [Patch] Fortran/OpenMP: Fix depend-clause handling)

[Jakub Jelinek via Gcc-patches]

On Tue, Feb 15, 2022 at 06:01:09PM +0100, Tobias Burnus wrote:
> OK?

Ok.

> Fortran/OpenMP: Fix depend-clause handling for c_ptr
> 
> gcc/fortran/ChangeLog:
> 
>   * trans-openmp.cc (gfc_trans_omp_depobj): Fix to alloc/ptr dummy
>   and for c_ptr.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gfortran.dg/gomp/depend-4.f90: Add VALUE test, update scan test.
>   * gfortran.dg/gomp/depend-5.f90: Fix scan tree for -m32.
>   * gfortran.dg/gomp/depend-6.f90: New test.
> 
>  gcc/fortran/trans-openmp.cc |   7 +-
>  gcc/testsuite/gfortran.dg/gomp/depend-4.f90 |  29 +++-
>  gcc/testsuite/gfortran.dg/gomp/depend-5.f90 |  12 +-
>  gcc/testsuite/gfortran.dg/gomp/depend-6.f90 | 259 
> 
>  4 files changed, 295 insertions(+), 12 deletions(-)

Jakub

New German PO file for 'cpplib' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/cpplib/de.po

(This file, 'cpplib-12.1-b20220213.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Contents of PO file 'cpplib-12.1-b20220213.de.po'

[Translation Project Robot]

cpplib-12.1-b20220213.de.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

[PATCH], PR target/99708 - Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__

[Michael Meissner via Gcc-patches]

Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__.

Define the sizes of the PowerPC specific types __float128 and __ibm128 if those
types are enabled.

I tested this on a little endian power9 system and there were no regressions.
Can I check this into the trunk, and after a burn-in period, can I check this
into the GCC 10 and 11 branches?

2022-02-15  Michael Meissner  

gcc/
PR target/99708
* config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define
__SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ if we have float128
support.

gcc/testsuite/
PR target/99708
* gcc.target/powerpc/pr99708.c: New test.
---
 gcc/config/rs6000/rs6000-c.cc  | 12 ++--
 gcc/testsuite/gcc.target/powerpc/pr99708.c | 21 +
 2 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr99708.c

diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc
index 15251efc209..b5f771d1308 100644
--- a/gcc/config/rs6000/rs6000-c.cc
+++ b/gcc/config/rs6000/rs6000-c.cc
@@ -581,9 +581,17 @@ rs6000_target_modify_macros (bool define_p, HOST_WIDE_INT 
flags,
 {
   rs6000_define_or_undefine_macro (define_p, "__FLOAT128__");
   if (define_p)
-   rs6000_define_or_undefine_macro (true, "__float128=__ieee128");
+   {
+ rs6000_define_or_undefine_macro (true, "__float128=__ieee128");
+ rs6000_define_or_undefine_macro (true, "__SIZEOF_FLOAT128__=16");
+ rs6000_define_or_undefine_macro (true, "__SIZEOF_IBM128__=16");
+   }
   else
-   rs6000_define_or_undefine_macro (false, "__float128");
+   {
+ rs6000_define_or_undefine_macro (false, "__float128");
+ rs6000_define_or_undefine_macro (false, "__SIZEOF_FLOAT128__");
+ rs6000_define_or_undefine_macro (false, "__SIZEOF_IBM128__");
+   }
 }
   /* OPTION_MASK_FLOAT128_HARDWARE can be turned on if -mcpu=power9 is used or
  via the target attribute/pragma.  */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr99708.c 
b/gcc/testsuite/gcc.target/powerpc/pr99708.c
new file mode 100644
index 000..d478f7bc4c0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr99708.c
@@ -0,0 +1,21 @@
+/* { dg-do run } */
+/* { require-effective-target ppc_float128_sw } */
+/* { dg-options "-O2 -mvsx -mfloat128" } */
+
+/*
+ * PR target/99708
+ *
+ * Verify that __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ are properly defined.
+ */
+
+#include 
+
+int main (void)
+{
+  if (__SIZEOF_FLOAT128__ != sizeof (__float128)
+  || __SIZEOF_IBM128__ != sizeof (__ibm128))
+abort ();
+
+  return 0;
+}
+
-- 
2.35.1


-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

[PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

[Patrick Palka via Gcc-patches]

Here we're crashing from potential_constant_expression because it tries
to perform trial evaluation of the first operand '(bool)__r' of the
conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but
cxx_eval_constant_expression ICEs on unhandled trees (of which CAST_EXPR
is one).

Since cxx_eval_constant_expression always treats NON_DEPENDENT_EXPR
as non-constant, and since NON_DEPENDENT_EXPR is also opaque to
instantiate_non_dependent_expr, it seems futile to have p_c_e_1 ever
return true for NON_DEPENDENT_EXPR, so let's just instead return false
and avoid recursing.

Alternatively p_c_e_1 could continue to recurse into NON_DEPENDENT_EXPR,
but with trial evaluation disabled by setting processing_template_decl,
but as mentioned it seems pointless for p_c_e_1 to ever return true for
NON_DEPENDENT_EXPR.

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

PR c++/104507

gcc/cp/ChangeLog:

* constexpr.cc (potential_constant_expression_1)
: Return false rather than recursing.

gcc/testsuite/ChangeLog:

* g++.dg/template/non-dependent21.C: New test.
---
 gcc/cp/constexpr.cc | 4 +++-
 gcc/testsuite/g++.dg/template/non-dependent21.C | 9 +
 2 files changed, 12 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/template/non-dependent21.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 7274c3b760e..c0523551f7b 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -9065,6 +9065,9 @@ potential_constant_expression_1 (tree t, bool want_rval, 
bool strict, bool now,
 case BIND_EXPR:
   return RECUR (BIND_EXPR_BODY (t), want_rval);
 
+case NON_DEPENDENT_EXPR:
+  return false;
+
 case CLEANUP_POINT_EXPR:
 case MUST_NOT_THROW_EXPR:
 case TRY_CATCH_EXPR:
@@ -9072,7 +9075,6 @@ potential_constant_expression_1 (tree t, bool want_rval, 
bool strict, bool now,
 case EH_SPEC_BLOCK:
 case EXPR_STMT:
 case PAREN_EXPR:
-case NON_DEPENDENT_EXPR:
   /* For convenience.  */
 case LOOP_EXPR:
 case EXIT_EXPR:
diff --git a/gcc/testsuite/g++.dg/template/non-dependent21.C 
b/gcc/testsuite/g++.dg/template/non-dependent21.C
new file mode 100644
index 000..89900837b8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/non-dependent21.C
@@ -0,0 +1,9 @@
+// PR c++/104507
+
+extern const char *_k_errmsg[];
+
+template
+const char* DoFoo(int __r, int __s) {
+  const char* n = _k_errmsg[(bool)__r && __s ? 1 : 2];
+  return n;
+}
-- 
2.35.1.129.gb80121027d

Contents of PO file 'cpplib-12.1-b20220213.uk.po'

[Translation Project Robot]

cpplib-12.1-b20220213.uk.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Ukrainian PO file for 'cpplib' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/cpplib/uk.po

(This file, 'cpplib-12.1-b20220213.uk.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: [PATCH] [PATCH, v5, 1/1, AARCH64][PR102768] aarch64: Add compiler support for Shadow Call Stack

[Richard Sandiford via Gcc-patches]

Dan Li  writes:
> Shadow Call Stack can be used to protect the return address of a
> function at runtime, and clang already supports this feature[1].
>
> To enable SCS in user mode, in addition to compiler, other support
> is also required (as discussed in [2]). This patch only adds basic
> support for SCS from the compiler side, and provides convenience
> for users to enable SCS.
>
> For linux kernel, only the support of the compiler is required.
>
> [1] https://clang.llvm.org/docs/ShadowCallStack.html
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768
>
> Signed-off-by: Dan Li 
>
> gcc/ChangeLog:
>
>   * config/aarch64/aarch64.cc (SLOT_REQUIRED):
>   Change wb_candidate[12] to wb_push_candidate[12].
>   (aarch64_layout_frame): Likewise, and
>   change callee_adjust when scs is enabled.
>   (aarch64_save_callee_saves):
>   Change wb_candidate[12] to wb_push_candidate[12].
>   (aarch64_restore_callee_saves):
>   Change wb_candidate[12] to wb_pop_candidate[12].
>   (aarch64_get_separate_components):
>   Change wb_candidate[12] to wb_push_candidate[12].
>   (aarch64_expand_prologue): Push x30 onto SCS before it's
>   pushed onto stack.
>   (aarch64_expand_epilogue): Pop x30 frome SCS, while
>   preventing it from being popped from the regular stack again.
>   (aarch64_override_options_internal): Add SCS compile option check.
>   (TARGET_HAVE_SHADOW_CALL_STACK): New hook.
>   * config/aarch64/aarch64.h (struct GTY): Add is_scs_enabled,
>   wb_pop_candidate[12], and rename wb_candidate[12] to
>   wb_push_candidate[12].
>   * config/aarch64/aarch64.md (scs_push): New template.
>   (scs_pop): Likewise.
>   * doc/invoke.texi: Document -fsanitize=shadow-call-stack.
>   * doc/tm.texi: Regenerate.
>   * doc/tm.texi.in: Add hook have_shadow_call_stack.
>   * flag-types.h (enum sanitize_code):
>   Add SANITIZE_SHADOW_CALL_STACK.
>   * opts.cc: Add shadow-call-stack.
>   * target.def: New hook.
>   * toplev.cc (process_options): Add SCS compile option check.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/aarch64/shadow_call_stack_1.c: New test.
>   * gcc.target/aarch64/shadow_call_stack_2.c: New test.
>   * gcc.target/aarch64/shadow_call_stack_3.c: New test.
>   * gcc.target/aarch64/shadow_call_stack_4.c: New test.
>   * gcc.target/aarch64/shadow_call_stack_5.c: New test.
>   * gcc.target/aarch64/shadow_call_stack_6.c: New test.
>   * gcc.target/aarch64/shadow_call_stack_7.c: New test.
>   * gcc.target/aarch64/shadow_call_stack_8.c: New test.

Looks good, thanks.  However, when I bootstrap it on
aarch64-linux-gnu I get:

.../gcc/ubsan.cc: In function ‘bool 
ubsan_expand_null_ifn(gimple_stmt_iterator*)’:
.../gcc/ubsan.cc:835:50: error: enumerated and non-enumerated type in 
conditional expression [-Werror=extra]
  835 | = (flag_sanitize_recover & ((check_align ? SANITIZE_ALIGNMENT : 
0)
  |  
^~~~
.../gcc/ubsan.cc:836:51: error: enumerated and non-enumerated type in 
conditional expression [-Werror=extra]
  836 | | (check_null ? SANITIZE_NULL : 0)))
  |~~~^~~

I think this is because you're taking the last available bit
of the enum :-)

A hacky fix is to add "+ 0" to SANITIZE_ALIGNMENT and SANITIZE_NULL
in the code quoted above (i.e. the code in the error messages).
That seems slightly more robust than a cast to unsigned int (say),
since "+ 0" will work even if the values become 64-bit quantities
in future.

Richard


> ---
> V5:
> - Modify part of wb_push_candidates to wb_pop_candidates.
> - Rebase to the mainline (20220210).
> V4:
> - Added wb_[push|pop]_candidates[12] to ensure push/pop can
> emit different registers.
>
> V3:
> - Change scs_push/pop to standard move patterns.
> - Optimize scs_pop to avoid pop x30 twice when shadow stack is enabled.
>
>  gcc/config/aarch64/aarch64.cc | 113 +-
>  gcc/config/aarch64/aarch64.h  |  21 +++-
>  gcc/config/aarch64/aarch64.md |  10 ++
>  gcc/doc/invoke.texi   |  30 +
>  gcc/doc/tm.texi   |   5 +
>  gcc/doc/tm.texi.in|   2 +
>  gcc/flag-types.h  |   2 +
>  gcc/opts.cc   |   1 +
>  gcc/target.def|   8 ++
>  .../gcc.target/aarch64/shadow_call_stack_1.c  |   6 +
>  .../gcc.target/aarch64/shadow_call_stack_2.c  |   6 +
>  .../gcc.target/aarch64/shadow_call_stack_3.c  |  45 +++
>  .../gcc.target/aarch64/shadow_call_stack_4.c  |  20 
>  .../gcc.target/aarch64/shadow_call_stack_5.c  |  18 +++
>  .../gcc.target/aarch64/shadow_call_stack_6.c  |  18 +++
>  .../gcc.target/aarch64/shadow_call_stack_7.c  |  18 ++

[pushed] vect: Fix early free

[Richard Sandiford via Gcc-patches]

When updating the target costs interface, I failed to move the
free of the scalar costs beyond the new last use.

Tested on aarch64-linux-gnu and x86_64-linux-gnu, pushed as obvious.

Richard


gcc/
* tree-vect-slp.cc (vect_bb_vectorization_profitable_p): Fix
use after free.
---
 gcc/tree-vect-slp.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index e2cc7218c2b..273543d37ea 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -5380,7 +5380,6 @@ vect_bb_vectorization_profitable_p (bb_vec_info bb_vinfo,
   unsigned dummy;
   finish_cost (scalar_target_cost_data, nullptr,
   &dummy, &scalar_cost, &dummy);
-  delete scalar_target_cost_data;
 
   /* Complete the target-specific vector cost calculation.  */
   class vector_costs *vect_target_cost_data = init_cost (bb_vinfo, false);
@@ -5393,6 +5392,7 @@ vect_bb_vectorization_profitable_p (bb_vec_info bb_vinfo,
 && li_vector_costs[vi].first == vl);
   finish_cost (vect_target_cost_data, scalar_target_cost_data,
   &vec_prologue_cost, &vec_inside_cost, &vec_epilogue_cost);
+  delete scalar_target_cost_data;
   delete vect_target_cost_data;
 
   vec_outside_cost = vec_prologue_cost + vec_epilogue_cost;
-- 
2.25.1

[pushed] aarch64: Add +nosve to tests

[Richard Sandiford via Gcc-patches]

This patch adds +nosve to various Advanced SIMD-only tests.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/testsuite/
* gcc.target/aarch64/shl-combine-2.c: New test.
* gcc.target/aarch64/shl-combine-3.c: Likewise.
* gcc.target/aarch64/shl-combine-4.c: Likewise.
* gcc.target/aarch64/shl-combine-5.c: Likewise.
* gcc.target/aarch64/xtn-combine-1.c: Likewise.
* gcc.target/aarch64/xtn-combine-2.c: Likewise.
* gcc.target/aarch64/xtn-combine-3.c: Likewise.
* gcc.target/aarch64/xtn-combine-4.c: Likewise.
* gcc.target/aarch64/xtn-combine-5.c: Likewise.
* gcc.target/aarch64/xtn-combine-6.c: Likewise.
---
 gcc/testsuite/gcc.target/aarch64/shl-combine-2.c | 2 ++
 gcc/testsuite/gcc.target/aarch64/shl-combine-3.c | 2 ++
 gcc/testsuite/gcc.target/aarch64/shl-combine-4.c | 2 ++
 gcc/testsuite/gcc.target/aarch64/shl-combine-5.c | 2 ++
 gcc/testsuite/gcc.target/aarch64/xtn-combine-1.c | 2 ++
 gcc/testsuite/gcc.target/aarch64/xtn-combine-2.c | 2 ++
 gcc/testsuite/gcc.target/aarch64/xtn-combine-3.c | 2 ++
 gcc/testsuite/gcc.target/aarch64/xtn-combine-4.c | 2 ++
 gcc/testsuite/gcc.target/aarch64/xtn-combine-5.c | 2 ++
 gcc/testsuite/gcc.target/aarch64/xtn-combine-6.c | 2 ++
 10 files changed, 20 insertions(+)

diff --git a/gcc/testsuite/gcc.target/aarch64/shl-combine-2.c 
b/gcc/testsuite/gcc.target/aarch64/shl-combine-2.c
index 6a0331fbe60..491fd44e637 100644
--- a/gcc/testsuite/gcc.target/aarch64/shl-combine-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/shl-combine-2.c
@@ -1,6 +1,8 @@
 /* { dg-do assemble } */
 /* { dg-options "-O3 --save-temps --param=vect-epilogues-nomask=0" } */
 
+#pragma GCC target "+nosve"
+
 #define TYPE char
 
 void e (signed TYPE * restrict a, signed TYPE *b, int n)
diff --git a/gcc/testsuite/gcc.target/aarch64/shl-combine-3.c 
b/gcc/testsuite/gcc.target/aarch64/shl-combine-3.c
index 2086b24a3cb..39bef21f39c 100644
--- a/gcc/testsuite/gcc.target/aarch64/shl-combine-3.c
+++ b/gcc/testsuite/gcc.target/aarch64/shl-combine-3.c
@@ -1,6 +1,8 @@
 /* { dg-do assemble } */
 /* { dg-options "-O3 --save-temps --param=vect-epilogues-nomask=0" } */
 
+#pragma GCC target "+nosve"
+
 #define TYPE short
 
 void e (signed TYPE * restrict a, signed TYPE *b, int n)
diff --git a/gcc/testsuite/gcc.target/aarch64/shl-combine-4.c 
b/gcc/testsuite/gcc.target/aarch64/shl-combine-4.c
index 083181071f4..15dcbff8e8c 100644
--- a/gcc/testsuite/gcc.target/aarch64/shl-combine-4.c
+++ b/gcc/testsuite/gcc.target/aarch64/shl-combine-4.c
@@ -1,6 +1,8 @@
 /* { dg-do assemble } */
 /* { dg-options "-O3 --save-temps --param=vect-epilogues-nomask=0" } */
 
+#pragma GCC target "+nosve"
+
 #define TYPE int
 
 void e (signed TYPE * restrict a, signed TYPE *b, int n)
diff --git a/gcc/testsuite/gcc.target/aarch64/shl-combine-5.c 
b/gcc/testsuite/gcc.target/aarch64/shl-combine-5.c
index 6b2a6bd86b3..703f6302382 100644
--- a/gcc/testsuite/gcc.target/aarch64/shl-combine-5.c
+++ b/gcc/testsuite/gcc.target/aarch64/shl-combine-5.c
@@ -1,6 +1,8 @@
 /* { dg-do assemble } */
 /* { dg-options "-O3 --save-temps --param=vect-epilogues-nomask=0" } */
 
+#pragma GCC target "+nosve"
+
 #define TYPE long
 
 void e (signed TYPE * restrict a, signed TYPE *b, int n)
diff --git a/gcc/testsuite/gcc.target/aarch64/xtn-combine-1.c 
b/gcc/testsuite/gcc.target/aarch64/xtn-combine-1.c
index 14e0414cd14..27b785832f0 100644
--- a/gcc/testsuite/gcc.target/aarch64/xtn-combine-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/xtn-combine-1.c
@@ -1,6 +1,8 @@
 /* { dg-do assemble } */
 /* { dg-options "-O3 --save-temps --param=vect-epilogues-nomask=0" } */
 
+#pragma GCC target "+nosve"
+
 #define SIGN signed
 #define TYPE1 char
 #define TYPE2 short
diff --git a/gcc/testsuite/gcc.target/aarch64/xtn-combine-2.c 
b/gcc/testsuite/gcc.target/aarch64/xtn-combine-2.c
index c259010442b..02f03fa7efe 100644
--- a/gcc/testsuite/gcc.target/aarch64/xtn-combine-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/xtn-combine-2.c
@@ -1,6 +1,8 @@
 /* { dg-do assemble } */
 /* { dg-options "-O3 --save-temps --param=vect-epilogues-nomask=0" } */
 
+#pragma GCC target "+nosve"
+
 #define SIGN signed
 #define TYPE1 short
 #define TYPE2 int
diff --git a/gcc/testsuite/gcc.target/aarch64/xtn-combine-3.c 
b/gcc/testsuite/gcc.target/aarch64/xtn-combine-3.c
index 9a2065f6510..4bcbd8519c2 100644
--- a/gcc/testsuite/gcc.target/aarch64/xtn-combine-3.c
+++ b/gcc/testsuite/gcc.target/aarch64/xtn-combine-3.c
@@ -1,6 +1,8 @@
 /* { dg-do assemble } */
 /* { dg-options "-O3 --save-temps --param=vect-epilogues-nomask=0" } */
 
+#pragma GCC target "+nosve"
+
 #define SIGN signed
 #define TYPE1 int
 #define TYPE2 long long
diff --git a/gcc/testsuite/gcc.target/aarch64/xtn-combine-4.c 
b/gcc/testsuite/gcc.target/aarch64/xtn-combine-4.c
index 77c3dce1204..29703d1d042 100644
--- a/gcc/testsuite/gcc.target/aarch64/xtn-combine-4.c
+++ b/gcc/testsuite/gcc.target/aarch64/xtn-combine-4.c
@@ -1,6 +1,8 @@
 /* { dg-do assemble } */
 /* { dg-options "-O3 --s

[pushed] aarch64: Fix store_v2vec_lanes.c failure

[Richard Sandiford via Gcc-patches]

store_v2vec_lanes.c started failing after SLP was enabled at -O2.
The test is specifically checking what happens for unvectorised code,
with the vectors being constructed from individal addition results.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/testsuite/
* gcc.target/aarch64/store_v2vec_lanes.c: Add -fno-tree-vectorize.
---
 gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c 
b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
index 3296d04da14..7ea8a674f4c 100644
--- a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
+++ b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -fno-tree-vectorize" } */
 
 typedef long long v2di __attribute__ ((vector_size (16)));
 typedef double v2df __attribute__ ((vector_size (16)));
-- 
2.25.1

[pushed] aarch64: Fix subs_compare_2.c regression [PR100874]

[Richard Sandiford via Gcc-patches]

subs_compare_2.c tests that we can use a SUBS+CSEL sequence for:

unsigned int
foo (unsigned int a, unsigned int b)
{
  unsigned int x = a - 4;
  if (a < 4)
return x;
  else
return 0;
}

As Andrew notes in the PR, this is effectively MIN (x, 4) - 4,
and it is now recognised as such by phiopt.  Previously it was
if-converted in RTL instead.

I tried to look for ways to generalise this to other situations
and to other ?:-style operations, not just max and min.  However,
for general ?: we tend to push an outer “- CST” into the arms of
the ?: -- at least if one of them simplifies -- so I didn't find
any useful abstraction.

This patch therefore adds a pattern specifically for
max/min(a,cst)-cst.  I'm not thrilled at having to do this,
but it seems like the least worst fix in the circumstances.
Also, max(a,cst)-cst for unsigned a is a useful saturating
subtraction idiom and so is arguably worth its own code
for that reason.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/
PR target/100874
* config/aarch64/aarch64-protos.h (aarch64_maxmin_plus_const):
Declare.
* config/aarch64/aarch64.cc (aarch64_maxmin_plus_const): New function.
* config/aarch64/aarch64.md (*aarch64_minmax_plus): New pattern.

gcc/testsuite/
* gcc.target/aarch64/max_plus_1.c: New test.
* gcc.target/aarch64/max_plus_2.c: Likewise.
* gcc.target/aarch64/max_plus_3.c: Likewise.
* gcc.target/aarch64/max_plus_4.c: Likewise.
* gcc.target/aarch64/max_plus_5.c: Likewise.
* gcc.target/aarch64/max_plus_6.c: Likewise.
* gcc.target/aarch64/max_plus_7.c: Likewise.
* gcc.target/aarch64/min_plus_1.c: Likewise.
* gcc.target/aarch64/min_plus_2.c: Likewise.
* gcc.target/aarch64/min_plus_3.c: Likewise.
* gcc.target/aarch64/min_plus_4.c: Likewise.
* gcc.target/aarch64/min_plus_5.c: Likewise.
* gcc.target/aarch64/min_plus_6.c: Likewise.
* gcc.target/aarch64/min_plus_7.c: Likewise.
---
 gcc/config/aarch64/aarch64-protos.h   |   1 +
 gcc/config/aarch64/aarch64.cc | 104 
 gcc/config/aarch64/aarch64.md |  27 
 gcc/testsuite/gcc.target/aarch64/max_plus_1.c | 149 ++
 gcc/testsuite/gcc.target/aarch64/max_plus_2.c |  35 
 gcc/testsuite/gcc.target/aarch64/max_plus_3.c |  35 
 gcc/testsuite/gcc.target/aarch64/max_plus_4.c |  30 
 gcc/testsuite/gcc.target/aarch64/max_plus_5.c |  35 
 gcc/testsuite/gcc.target/aarch64/max_plus_6.c |   9 ++
 gcc/testsuite/gcc.target/aarch64/max_plus_7.c |  35 
 gcc/testsuite/gcc.target/aarch64/min_plus_1.c | 149 ++
 gcc/testsuite/gcc.target/aarch64/min_plus_2.c |  35 
 gcc/testsuite/gcc.target/aarch64/min_plus_3.c |  35 
 gcc/testsuite/gcc.target/aarch64/min_plus_4.c |  30 
 gcc/testsuite/gcc.target/aarch64/min_plus_5.c |  35 
 gcc/testsuite/gcc.target/aarch64/min_plus_6.c |   9 ++
 gcc/testsuite/gcc.target/aarch64/min_plus_7.c |  35 
 17 files changed, 788 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/max_plus_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/max_plus_2.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/max_plus_3.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/max_plus_4.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/max_plus_5.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/max_plus_6.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/max_plus_7.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/min_plus_1.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/min_plus_2.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/min_plus_3.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/min_plus_4.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/min_plus_5.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/min_plus_6.c
 create mode 100644 gcc/testsuite/gcc.target/aarch64/min_plus_7.c

diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 392efa0b74d..d0e78d6a559 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -939,6 +939,7 @@ bool aarch64_legitimate_address_p (machine_mode, rtx, bool,
   aarch64_addr_query_type = ADDR_QUERY_M);
 machine_mode aarch64_select_cc_mode (RTX_CODE, rtx, rtx);
 rtx aarch64_gen_compare_reg (RTX_CODE, rtx, rtx);
+bool aarch64_maxmin_plus_const (rtx_code, rtx *, bool);
 rtx aarch64_load_tp (rtx);
 
 void aarch64_expand_compare_and_swap (rtx op[]);
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 1a460d4bac0..37ed22bcc94 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -3781,6 +3781,110 @@ aarch64_gen_compare_reg_maybe_ze (RTX_CODE code, rtx x, 
rtx y,
   return aarch64_gen_compare_reg (code, x, y);
 }
 
+/* Consider the operation:
+
+ OPERANDS[0] = CODE (OPER

New Ukrainian PO file for 'gcc' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'gcc-12.1-b20220213.uk.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[PATCH] rs6000: Retry tbegin. instructions that can fail intermittently

[Peter Bergner via Gcc-patches]

The HTM tbegin. instruction can fail intermittently due to many reasons.
This can lead to the htm-1.c testsuite test case FAILing from time to time.
The solution is to allow retrying the instruction a few times before aborting.

Bill has seen this fail a 1-2 times per 1 runs.  With the change below, I
haven't seen the test case fail in over 1 million runs.

Ok for trunk and backports to the release branches?

Peter


gcc/testsuite/
* gcc.target/powerpc/htm-1.c: Retry intermittent failing tbegins.

diff --git a/gcc/testsuite/gcc.target/powerpc/htm-1.c 
b/gcc/testsuite/gcc.target/powerpc/htm-1.c
index f27e32ca281..399a7ec8812 100644
--- a/gcc/testsuite/gcc.target/powerpc/htm-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/htm-1.c
@@ -12,14 +12,21 @@ main (void)
 {
   long i;
   unsigned long mask = 0;
+  unsigned long retry_count = 0;
 
 repeat:
   if (__builtin_tbegin (0))
 {
   mask++;
+  retry_count = 0;
 }
   else
-abort();
+{
+  /* Retry a limited number of times before aborting.  */
+  if (retry_count++ < 10)
+   goto repeat;
+  abort ();
+}
 
   if (mask == 1)
 {

Re: [PATCH], PR target/99708 - Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__

[Segher Boessenkool]

On Tue, Feb 15, 2022 at 12:49:41PM -0500, Michael Meissner wrote:
> Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__.
> 
> Define the sizes of the PowerPC specific types __float128 and __ibm128 if 
> those
> types are enabled.

This is very silly of course, both of these are 16 bytes.  Abusing this
to see if the types exist is at least as silly (there are much better
mechanisms to do this).

So, this facilitates bad habits and bad code.  But, whatever, the macros
are just stating totally obvious and redundant facts, no problem, let's
just ignore that pepople only want it to abuse it.

> gcc/
>   PR target/99708
>   * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define
>   __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ if we have float128
>   support.

No.  __SIZEOF_IBM128__ should be defined if and only if __ibm128 is
defined.

This should be tested directly, it should not depend on that some other
code did what it does today.  That would also make the code much more
obvious.


Segher

Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]

[Jason Merrill via Gcc-patches]

On 2/15/22 11:30, Zhao Wei Liew wrote:
On Tue, 15 Feb 2022 at 21:05, Jason Merrill > wrote:

 > >>
 > >> I agree. However, I can't seem to call extract_call_expr directly
 > >> because it calls gcc_assert
 > >> to assert that the resulting expression is a CALL_EXPR or 
AGGR_INIT_EXPR.

 > >> Instead, I've extracted the non-assert-related code into a
 > >> extract_call_expr_noassert function
 > >> and called that instead in the new patch. Is that okay?
 > >
 > > I think instead of factoring out a new function, let's change the 
assert

 > > to an if and return NULL_TREE if it fails.
 >

I've adjusted the patch as advised. What do you think?

 > Incidentally, the subject should be "c++:" instead of "c:".
 >

Ah, I see. I found it a bit odd that gcc-commit-mklog auto-generated a 
subject with "c:",
but I just went with it as I didn't know any better. Unfortunately, I 
can't change it now on the current thread.


That came from this line in the testcase:

> +/* PR c/25689 */

The PR should be c++/25689.  Also, sometimes the bugzilla component 
isn't the same as the area of the compiler you're changing; the latter 
is what you want in the patch subject, so that the right people know to 
review it.



 > Also, it doesn't look like you have a copyright assignment with the FSF,
 > so you will need to add a DCO sign-off to your patches; see
 > https://gcc.gnu.org/dco.html  for more 
information.

 >
 > I'd suggest putting your revision history before the scissors line, as
 > that doesn't need to be part of the commit message.
 >

Got it. Made the changes in the latest patch.

 > And the latest patch didn't apply easily because this line:
 >
 >  >> diff --git a/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
 >  >> b/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
 >
 > got wrapped in transit.
 >

Ah, I didn't notice that. Sorry about that! I'm kinda new to the whole 
mailing list setup so there are some kinks I have to iron out.


FWIW it's often easier to send the patch as an attachment.

v5: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590393.html 


Changes since v5:
1. Revert changes in v4.
2. Replace gcc_assert with a return NULL_TREE in extract_call_expr.

v4: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590379.html 


Changes since v4:
1. Refactor the non-assert-related code out of extract_call_expr and
    call that function instead to check for call expressions.

v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html 


Changes since v3:
1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.

v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html 


Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.

v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html 


Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
    operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.


-- Everything below is patch v6 --

When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:

struct A {
A& operator=(int);
operator bool();
};

void f(A a) {
if (a = 0); // no warning
}

This is because a = 0 is a call to operator=, which GCC does not handle.

This patch fixes this issue by handling calls to operator= when deciding
to warn.

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

PR c++/25689

gcc/cp/ChangeLog:

* call.cc (extract_call_expr): Return a NULL_TREE on failure
  instead of asserting.
* semantics.cc (is_assignment_op_expr_p): Add function to check
  if an expression is a call to an op= operator expression.
(maybe_convert_cond): Handle the case of a op= operator expression
  for the -Wparentheses diagnostic.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wparentheses-31.C: New test.

Signed-off-by: Zhao Wei Liew mailto:zhaoweil...@gmail.com>>
---
  gcc/cp/call.cc  |  7 ++-
  gcc/cp/semantics.cc | 20 ++-
  gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 62 +
  3 files changed, 85 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index d6eed5ed835..3b2c6d8c499 100644
--- a/gcc/cp/call.cc
+++

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

[Patrick Palka via Gcc-patches]

On Tue, 15 Feb 2022, Patrick Palka wrote:

> Here we're crashing from potential_constant_expression because it tries
> to perform trial evaluation of the first operand '(bool)__r' of the
> conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but
> cxx_eval_constant_expression ICEs on unhandled trees (of which CAST_EXPR
> is one).
> 
> Since cxx_eval_constant_expression always treats NON_DEPENDENT_EXPR
> as non-constant, and since NON_DEPENDENT_EXPR is also opaque to
> instantiate_non_dependent_expr, it seems futile to have p_c_e_1 ever
> return true for NON_DEPENDENT_EXPR, so let's just instead return false
> and avoid recursing.
> 
> Alternatively p_c_e_1 could continue to recurse into NON_DEPENDENT_EXPR,
> but with trial evaluation disabled by setting processing_template_decl,
> but as mentioned it seems pointless for p_c_e_1 to ever return true for
> NON_DEPENDENT_EXPR.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk and perhaps 10/11?
> 
>   PR c++/104507
> 
> gcc/cp/ChangeLog:
> 
>   * constexpr.cc (potential_constant_expression_1)
>   : Return false rather than recursing.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/template/non-dependent21.C: New test.
> ---
>  gcc/cp/constexpr.cc | 4 +++-
>  gcc/testsuite/g++.dg/template/non-dependent21.C | 9 +
>  2 files changed, 12 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/template/non-dependent21.C
> 
> diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> index 7274c3b760e..c0523551f7b 100644
> --- a/gcc/cp/constexpr.cc
> +++ b/gcc/cp/constexpr.cc
> @@ -9065,6 +9065,9 @@ potential_constant_expression_1 (tree t, bool 
> want_rval, bool strict, bool now,
>  case BIND_EXPR:
>return RECUR (BIND_EXPR_BODY (t), want_rval);
>  
> +case NON_DEPENDENT_EXPR:
> +  return false;

Since we're not issuing a diagnostic in this case, I suppose we should
also assert that tf_error isn't set.  Bootstrapped and regtested on
x86_64-pc-linux-gnu.

-- >8 --

PR c++/104507

gcc/cp/ChangeLog:

* constexpr.cc (potential_constant_expression_1)
: Return false instead of recursing.
Assert tf_error isn't set.

gcc/testsuite/ChangeLog:

* g++.dg/template/non-dependent21.C: New test.
---
 gcc/cp/constexpr.cc | 5 -
 gcc/testsuite/g++.dg/template/non-dependent21.C | 9 +
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/template/non-dependent21.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 7274c3b760e..b363ef08411 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -9065,6 +9065,10 @@ potential_constant_expression_1 (tree t, bool want_rval, 
bool strict, bool now,
 case BIND_EXPR:
   return RECUR (BIND_EXPR_BODY (t), want_rval);
 
+case NON_DEPENDENT_EXPR:
+  gcc_checking_assert (!(flags & tf_error));
+  return false;
+
 case CLEANUP_POINT_EXPR:
 case MUST_NOT_THROW_EXPR:
 case TRY_CATCH_EXPR:
@@ -9072,7 +9076,6 @@ potential_constant_expression_1 (tree t, bool want_rval, 
bool strict, bool now,
 case EH_SPEC_BLOCK:
 case EXPR_STMT:
 case PAREN_EXPR:
-case NON_DEPENDENT_EXPR:
   /* For convenience.  */
 case LOOP_EXPR:
 case EXIT_EXPR:
diff --git a/gcc/testsuite/g++.dg/template/non-dependent21.C 
b/gcc/testsuite/g++.dg/template/non-dependent21.C
new file mode 100644
index 000..89900837b8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/non-dependent21.C
@@ -0,0 +1,9 @@
+// PR c++/104507
+
+extern const char *_k_errmsg[];
+
+template
+const char* DoFoo(int __r, int __s) {
+  const char* n = _k_errmsg[(bool)__r && __s ? 1 : 2];
+  return n;
+}
-- 
2.35.1.129.gb80121027d

[r12-7240 Regression] FAIL: gcc.target/i386/auto-init-4.c scan-assembler-times long\t-16843010 5 on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

2801f23fb82a5ef51c8b460a500786797943e1e9 is the first bad commit
commit 2801f23fb82a5ef51c8b460a500786797943e1e9
Author: Jakub Jelinek 
Date:   Tue Feb 15 12:11:31 2022 +0100

fold, simplify-rtx: Punt on non-representable floating point constants 
[PR104522]

caused

FAIL: gcc.target/i386/auto-init-4.c scan-assembler-times long\t-16843010 5

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-7240/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/auto-init-4.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="i386.exp=gcc.target/i386/auto-init-4.c --target_board='unix{-m64\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[r12-7242 Regression] FAIL: gfortran.dg/gomp/depend-5.f90 -O scan-tree-dump-times original "#pragma omp task depend\\(depobj:\\*\\(integer\\(kind=16\\) \\*\\) \\(doaap->data \\+ \\(sizetype\\) \\(\\

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

3939c1b11279dc950d2f160eb940dd791f7b40f1 is the first bad commit
commit 3939c1b11279dc950d2f160eb940dd791f7b40f1
Author: Tobias Burnus 
Date:   Tue Feb 15 12:26:48 2022 +0100

Fortran/OpenMP: Fix depend-clause handling

caused

FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\(\\*\\(integer\\(kind=16\\)\\[0:\\] \\* 
restrict\\) aaa.data\\)\\[aaa.offset \\+ 2\\]\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\(\\*\\(integer\\(kind=16\\)\\[0:\\] \\* 
restrict\\) daaa->data\\)\\[daaa->offset \\+ 2\\]\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\(\\*\\(integer\\(kind=16\\)\\[0:\\] \\* 
restrict\\) doaaa->data\\)\\[doaaa->offset \\+ 2\\]\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\(integer\\(kind=16\\) \\*\\) \\(aap.data 
\\+ \\(sizetype\\) \\(\\(aap.offset \\+ aap.dim\\[0\\].stride \\* 2\\) \\* 
aap.span\\)\\)\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\(integer\\(kind=16\\) \\*\\) 
\\(daap->data \\+ \\(sizetype\\) \\(\\(daap->offset \\+ daap->dim\\[0\\].stride 
\\* 2\\) \\* daap->span\\)\\)\\)" 1
FAIL: gfortran.dg/gomp/depend-5.f90   -O   scan-tree-dump-times original 
"#pragma omp task depend\\(depobj:\\*\\(integer\\(kind=16\\) \\*\\) 
\\(doaap->data \\+ \\(sizetype\\) \\(\\(doaap->offset \\+ 
doaap->dim\\[0\\].stride \\* 2\\) \\* doaap->span\\)\\)\\)" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-7242/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/depend-5.f90 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="gomp.exp=gfortran.dg/gomp/depend-5.f90 --target_board='unix{-m32\ 
-march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Re: [PATCH], PR target/99708 - Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__

[Michael Meissner via Gcc-patches]

On Tue, Feb 15, 2022 at 01:45:06PM -0600, Segher Boessenkool wrote:
> On Tue, Feb 15, 2022 at 12:49:41PM -0500, Michael Meissner wrote:
> > Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__.
> > 
> > Define the sizes of the PowerPC specific types __float128 and __ibm128 if 
> > those
> > types are enabled.
> 
> This is very silly of course, both of these are 16 bytes.  Abusing this
> to see if the types exist is at least as silly (there are much better
> mechanisms to do this).

This is just trying to close out the PR that people asked for.

> So, this facilitates bad habits and bad code.  But, whatever, the macros
> are just stating totally obvious and redundant facts, no problem, let's
> just ignore that pepople only want it to abuse it.
> 
> > gcc/
> > PR target/99708
> > * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define
> > __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ if we have float128
> > support.
> 
> No.  __SIZEOF_IBM128__ should be defined if and only if __ibm128 is
> defined.

In the current implementation, __ibm128 is only defined if __float128 was
defined.  I did have patches 6 months or so to define __ibm128 on any system
with IBM 128-bit long double.  But those were never applied to the trunk.

> This should be tested directly, it should not depend on that some other
> code did what it does today.  That would also make the code much more
> obvious.

Given __float128 and __ibm128 are defined at the same time, I don't see the
need for a separate target-supports.exp test, and so forth.  But if you want
that, I can easily do it.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

[Jason Merrill via Gcc-patches]

On 2/15/22 15:13, Patrick Palka wrote:

On Tue, 15 Feb 2022, Patrick Palka wrote:


Here we're crashing from potential_constant_expression because it tries
to perform trial evaluation of the first operand '(bool)__r' of the
conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but
cxx_eval_constant_expression ICEs on unhandled trees (of which CAST_EXPR
is one).

Since cxx_eval_constant_expression always treats NON_DEPENDENT_EXPR
as non-constant, and since NON_DEPENDENT_EXPR is also opaque to
instantiate_non_dependent_expr, it seems futile to have p_c_e_1 ever
return true for NON_DEPENDENT_EXPR, so let's just instead return false
and avoid recursing.


Well, in a template we use pce1 to decide whether to complain about 
something that needs to be constant but can't be.  We aren't trying to 
get a value yet.


Actually, why are we seeing a NON_DEPENDENT_EXPR here?  Did it leak into 
the AST somehow?  They should all be temporary within build_x_whatever 
functions.



Alternatively p_c_e_1 could continue to recurse into NON_DEPENDENT_EXPR,
but with trial evaluation disabled by setting processing_template_decl,
but as mentioned it seems pointless for p_c_e_1 to ever return true for
NON_DEPENDENT_EXPR.
... 
Since we're not issuing a diagnostic in this case, I suppose we should

also assert that tf_error isn't set.  Bootstrapped and regtested on
x86_64-pc-linux-gnu.

-- >8 --

PR c++/104507

gcc/cp/ChangeLog:

* constexpr.cc (potential_constant_expression_1)
: Return false instead of recursing.
Assert tf_error isn't set.

gcc/testsuite/ChangeLog:

* g++.dg/template/non-dependent21.C: New test.
---
  gcc/cp/constexpr.cc | 5 -
  gcc/testsuite/g++.dg/template/non-dependent21.C | 9 +
  2 files changed, 13 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/template/non-dependent21.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 7274c3b760e..b363ef08411 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -9065,6 +9065,10 @@ potential_constant_expression_1 (tree t, bool want_rval, 
bool strict, bool now,
  case BIND_EXPR:
return RECUR (BIND_EXPR_BODY (t), want_rval);
  
+case NON_DEPENDENT_EXPR:

+  gcc_checking_assert (!(flags & tf_error));
+  return false;
+
  case CLEANUP_POINT_EXPR:
  case MUST_NOT_THROW_EXPR:
  case TRY_CATCH_EXPR:
@@ -9072,7 +9076,6 @@ potential_constant_expression_1 (tree t, bool want_rval, 
bool strict, bool now,
  case EH_SPEC_BLOCK:
  case EXPR_STMT:
  case PAREN_EXPR:
-case NON_DEPENDENT_EXPR:
/* For convenience.  */
  case LOOP_EXPR:
  case EXIT_EXPR:
diff --git a/gcc/testsuite/g++.dg/template/non-dependent21.C 
b/gcc/testsuite/g++.dg/template/non-dependent21.C
new file mode 100644
index 000..89900837b8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/non-dependent21.C
@@ -0,0 +1,9 @@
+// PR c++/104507
+
+extern const char *_k_errmsg[];
+
+template
+const char* DoFoo(int __r, int __s) {
+  const char* n = _k_errmsg[(bool)__r && __s ? 1 : 2];
+  return n;
+}

[committed] analyzer: fix ICE on cast to NULL type [PR104524]

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-7252-g84832cab6e43db7fa10ec53d15f8f8457aa31080.

gcc/analyzer/ChangeLog:
PR analyzer/104524
* region-model-manager.cc
(region_model_manager::maybe_fold_sub_svalue): Only call
get_or_create_cast if type is non-NULL.

gcc/testsuite/ChangeLog:
PR analyzer/104524
* gcc.dg/analyzer/pr104524.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/region-model-manager.cc | 5 +++--
 gcc/testsuite/gcc.dg/analyzer/pr104524.c | 9 +
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr104524.c

diff --git a/gcc/analyzer/region-model-manager.cc 
b/gcc/analyzer/region-model-manager.cc
index d7156c5499f..917af22c4f5 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -771,7 +771,7 @@ region_model_manager::maybe_fold_sub_svalue (tree type,
   if (unary->get_op () == NOP_EXPR
  || unary->get_op () == VIEW_CONVERT_EXPR)
if (tree cst = unary->get_arg ()->maybe_get_constant ())
- if (zerop (cst))
+ if (zerop (cst) && type)
{
  const svalue *cst_sval
= get_or_create_constant_svalue (cst);
@@ -786,7 +786,8 @@ region_model_manager::maybe_fold_sub_svalue (tree type,
/* If we have a concrete 1-byte access within the parent region... */
byte_range subregion_bytes (0, 0);
if (subregion->get_relative_concrete_byte_range (&subregion_bytes)
-   && subregion_bytes.m_size_in_bytes == 1)
+   && subregion_bytes.m_size_in_bytes == 1
+   && type)
  {
/* ...then attempt to get that char from the STRING_CST.  */
HOST_WIDE_INT hwi_start_byte
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr104524.c 
b/gcc/testsuite/gcc.dg/analyzer/pr104524.c
new file mode 100644
index 000..875098c69a4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/pr104524.c
@@ -0,0 +1,9 @@
+int src[1];
+
+int
+main (int c, char **a)
+{
+  __builtin_memcpy (*a, src, c);
+
+  return 0;
+}
-- 
2.26.3

Re: [PATCH] rs6000: Retry tbegin. instructions that can fail intermittently

[Segher Boessenkool]

Hi!

On Tue, Feb 15, 2022 at 01:03:09PM -0600, Peter Bergner wrote:
> The HTM tbegin. instruction can fail intermittently due to many reasons.

Just a few really.  But, if the transaction fails it will appear as if
the tbegin. had an error as well, is that what you are seeing?

> This can lead to the htm-1.c testsuite test case FAILing from time to time.
> The solution is to allow retrying the instruction a few times before aborting.

That is the way any HTM code should be written in the first place
(except for rollback-only transactions, but let's not go there --
besides, it is normal for those to fail as well, and there needs to be a
fallback there as well :-) )

The patch is fine.  Okay for trunk and backports (after soak time ofc).
Thanks!


Segher


> gcc/testsuite/
>   * gcc.target/powerpc/htm-1.c: Retry intermittent failing tbegins.

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

[Patrick Palka via Gcc-patches]

On Tue, 15 Feb 2022, Jason Merrill wrote:

> On 2/15/22 15:13, Patrick Palka wrote:
> > On Tue, 15 Feb 2022, Patrick Palka wrote:
> > 
> > > Here we're crashing from potential_constant_expression because it tries
> > > to perform trial evaluation of the first operand '(bool)__r' of the
> > > conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but
> > > cxx_eval_constant_expression ICEs on unhandled trees (of which CAST_EXPR
> > > is one).
> > > 
> > > Since cxx_eval_constant_expression always treats NON_DEPENDENT_EXPR
> > > as non-constant, and since NON_DEPENDENT_EXPR is also opaque to
> > > instantiate_non_dependent_expr, it seems futile to have p_c_e_1 ever
> > > return true for NON_DEPENDENT_EXPR, so let's just instead return false
> > > and avoid recursing.
> 
> Well, in a template we use pce1 to decide whether to complain about something
> that needs to be constant but can't be.  We aren't trying to get a value yet.

Makes sense.. though for NON_DEPENDENT_EXPR in particular, ISTM this
tree is always used in a context where a constant expression isn't
required, e.g. in the build_x_* functions.

And if something is required to be a constant expression and we're
inside a template, then it seems at that point we're dealing with the
final templated form of that thing (which doesn't contain
NON_DEPENDENT_EXPR), which I suppose explains why the patch can get away
with asserting !(flags & tf_error) inside the NON_DEPENDENT_EXPR case of
p_c_e_1.

So I guess I don't fully understand the purpose of NON_DEPENDENT_EXPR
or how it should interact with fold_non_dependent_expr and constant
evaluation...

> 
> Actually, why are we seeing a NON_DEPENDENT_EXPR here?  Did it leak into the
> AST somehow?  They should all be temporary within build_x_whatever functions.

Hmm yes, kind of.  The unusual thing about this testcase is that
build_non_dependent_expr (called from grok_array_decl) for the
COND_EXPR

  (bool)__r && __s ? 1 : 2

wraps only the condition operand, yielding

  NON_DEPENDENT_EXPR<<<(bool)__r && __s>>> ? 1 : 2// #1

rather than wrapping the whole thing i.e.

  NON_DEPENDENT_EXPR<<<(bool)__r && __s ? 1 : 2>>>// #2

cp_build_array_ref then tries to speculatively fold the non-dependent #1
as a whole, during which the COND_EXPR case of tsubst_copy_and_build
tries to speculative fold #1's condition NON_DEPENDENT_EXPR<<<(bool)__r && 
__s>>>
on its own, which ends in a crash from p_c_e_1 because at this point
processing_template_decl is cleared so p_c_e_1 attempts trial evaluation
of the CAST_EXPR (bool)__r.

If instead build_non_dependent_expr yielded #2, speculative folding of
#2 as a whole just yield #2 since tsubst doesn't look through
NON_DEPENDENT_EXPR.

> 
> > > Alternatively p_c_e_1 could continue to recurse into NON_DEPENDENT_EXPR,
> > > but with trial evaluation disabled by setting processing_template_decl,
> > > but as mentioned it seems pointless for p_c_e_1 to ever return true for
> > > NON_DEPENDENT_EXPR.
> > ... Since we're not issuing a diagnostic in this case, I suppose we should
> > also assert that tf_error isn't set.  Bootstrapped and regtested on
> > x86_64-pc-linux-gnu.
> > 
> > -- >8 --
> > 
> > PR c++/104507
> > 
> > gcc/cp/ChangeLog:
> > 
> > * constexpr.cc (potential_constant_expression_1)
> > : Return false instead of recursing.
> > Assert tf_error isn't set.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/template/non-dependent21.C: New test.
> > ---
> >   gcc/cp/constexpr.cc | 5 -
> >   gcc/testsuite/g++.dg/template/non-dependent21.C | 9 +
> >   2 files changed, 13 insertions(+), 1 deletion(-)
> >   create mode 100644 gcc/testsuite/g++.dg/template/non-dependent21.C
> > 
> > diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
> > index 7274c3b760e..b363ef08411 100644
> > --- a/gcc/cp/constexpr.cc
> > +++ b/gcc/cp/constexpr.cc
> > @@ -9065,6 +9065,10 @@ potential_constant_expression_1 (tree t, bool
> > want_rval, bool strict, bool now,
> >   case BIND_EXPR:
> > return RECUR (BIND_EXPR_BODY (t), want_rval);
> >   +case NON_DEPENDENT_EXPR:
> > +  gcc_checking_assert (!(flags & tf_error));
> > +  return false;
> > +
> >   case CLEANUP_POINT_EXPR:
> >   case MUST_NOT_THROW_EXPR:
> >   case TRY_CATCH_EXPR:
> > @@ -9072,7 +9076,6 @@ potential_constant_expression_1 (tree t, bool
> > want_rval, bool strict, bool now,
> >   case EH_SPEC_BLOCK:
> >   case EXPR_STMT:
> >   case PAREN_EXPR:
> > -case NON_DEPENDENT_EXPR:
> > /* For convenience.  */
> >   case LOOP_EXPR:
> >   case EXIT_EXPR:
> > diff --git a/gcc/testsuite/g++.dg/template/non-dependent21.C
> > b/gcc/testsuite/g++.dg/template/non-dependent21.C
> > new file mode 100644
> > index 000..89900837b8b
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/template/non-dependent21.C
> > @@ -0,0 +1,9 @@
> > +// PR c++/104507
> > +
> > +extern const char *_k_errmsg[];
> > +
> > +template
> 

Re: [PATCH], PR target/99708 - Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__

[Segher Boessenkool]

On Tue, Feb 15, 2022 at 03:18:30PM -0500, Michael Meissner wrote:
> On Tue, Feb 15, 2022 at 01:45:06PM -0600, Segher Boessenkool wrote:
> > On Tue, Feb 15, 2022 at 12:49:41PM -0500, Michael Meissner wrote:
> > > Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__.
> > > 
> > > Define the sizes of the PowerPC specific types __float128 and __ibm128 if 
> > > those
> > > types are enabled.
> > 
> > This is very silly of course, both of these are 16 bytes.  Abusing this
> > to see if the types exist is at least as silly (there are much better
> > mechanisms to do this).
> 
> This is just trying to close out the PR that people asked for.

I put many arguments in that PR why this is a futile thing to have.

On all older compilers these macros will not be defined, but the types
often are.  If you are willing to not support older compilers properly
anyway, you could just *always* use the types, which will work with most
very old compilers as well (and the approach using these propesed
predefines will *not*!)

This is (not) solving a non-problem.

> > So, this facilitates bad habits and bad code.  But, whatever, the macros
> > are just stating totally obvious and redundant facts, no problem, let's
> > just ignore that pepople only want it to abuse it.
> > 
> > > gcc/
> > >   PR target/99708
> > >   * config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Define
> > >   __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__ if we have float128
> > >   support.
> > 
> > No.  __SIZEOF_IBM128__ should be defined if and only if __ibm128 is
> > defined.
> 
> In the current implementation, __ibm128 is only defined if __float128 was
> defined.  I did have patches 6 months or so to define __ibm128 on any system
> with IBM 128-bit long double.  But those were never applied to the trunk.
> 
> > This should be tested directly, it should not depend on that some other
> > code did what it does today.  That would also make the code much more
> > obvious.

Read that last paragraph again please?  This is the only thing that
needs changing.

> Given __float128 and __ibm128 are defined at the same time, I don't see the
> need for a separate target-supports.exp test, and so forth.  But if you want
> that, I can easily do it.

No, I'm asking for it in the code that does the predefine.  Not in the
testcase, testcases are dirty pretty much always, and it is acceptable
there because the scope is so limited.


Segher

Re: [PATCH] rs6000: Retry tbegin. instructions that can fail intermittently

[Peter Bergner via Gcc-patches]

On 2/15/22 3:54 PM, Segher Boessenkool wrote:
> On Tue, Feb 15, 2022 at 01:03:09PM -0600, Peter Bergner wrote:
>> The HTM tbegin. instruction can fail intermittently due to many reasons.
> 
> Just a few really.  But, if the transaction fails it will appear as if
> the tbegin. had an error as well, is that what you are seeing?

Yeah, exactly.  The transaction itself fails, which rolls us back to
the tbegin. with an error return value so we fall into the else/error
clause.



> That is the way any HTM code should be written in the first place
> (except for rollback-only transactions, but let's not go there --
> besides, it is normal for those to fail as well, and there needs to be a
> fallback there as well :-) )

Agreed and I'm not sure why I didn't write it that way to begin with.
Maybe I thought it was so simple that the likelihood of it failing was
so small we'd never see it?  Anyway, we do now, so...



> The patch is fine.  Okay for trunk and backports (after soak time ofc).
> Thanks!

Thanks, pushed.

Peter

Re: [PATCH], PR target/99708 - Define __SIZEOF_FLOAT128__ and __SIZEOF_IBM128__

[Michael Meissner via Gcc-patches]

On Tue, Feb 15, 2022 at 04:05:11PM -0600, Segher Boessenkool wrote:
> On all older compilers these macros will not be defined, but the types
> often are.  If you are willing to not support older compilers properly
> anyway, you could just *always* use the types, which will work with most
> very old compilers as well (and the approach using these propesed
> predefines will *not*!)

The types are not defined on older systems.

Both __ibm128 (ibm128_float_type_node) and __float128 (ieee128_float_type_node)
are only defined if TARGET_FLOAT128_TYPE is true.

TARGET_FLOAT128_TYPE is only true if both TARGET_FLOAT128_ENABLE_TYPE and
TARGET_VSX are true.

TARGET_FLOAT128_ENABLE_TYPE is only true on linux64 systems.

Now, the code to set __SIZEOF_IBM128__ and __SIZEOF_FLOAT128__  is in the code
that also defines __FLOAT128__.  This code checks whether the __float128 and
__ibm128 keywords are allowed.  These keywords are only set if
TARGET_FLOAT128_TYPE is true, and if the user did not use the -mno-float128
option.  In the GCC 7 time frame, we did not set this by default, but in the
modern compilers, it is always set by default on Linux 64-bit systems.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [PATCH] c++: NON_DEPENDENT_EXPR is not potentially constant [PR104507]

[Jason Merrill via Gcc-patches]

On 2/15/22 17:00, Patrick Palka wrote:

On Tue, 15 Feb 2022, Jason Merrill wrote:


On 2/15/22 15:13, Patrick Palka wrote:

On Tue, 15 Feb 2022, Patrick Palka wrote:


Here we're crashing from potential_constant_expression because it tries
to perform trial evaluation of the first operand '(bool)__r' of the
conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but
cxx_eval_constant_expression ICEs on unhandled trees (of which CAST_EXPR
is one).

Since cxx_eval_constant_expression always treats NON_DEPENDENT_EXPR
as non-constant, and since NON_DEPENDENT_EXPR is also opaque to
instantiate_non_dependent_expr, it seems futile to have p_c_e_1 ever
return true for NON_DEPENDENT_EXPR, so let's just instead return false
and avoid recursing.


Well, in a template we use pce1 to decide whether to complain about something
that needs to be constant but can't be.  We aren't trying to get a value yet.


Makes sense.. though for NON_DEPENDENT_EXPR in particular, ISTM this
tree is always used in a context where a constant expression isn't
required, e.g. in the build_x_* functions.


Fair enough.  The patch is OK with a comment to that effect.


And if something is required to be a constant expression and we're
inside a template, then it seems at that point we're dealing with the
final templated form of that thing (which doesn't contain
NON_DEPENDENT_EXPR), which I suppose explains why the patch can get away
with asserting !(flags & tf_error) inside the NON_DEPENDENT_EXPR case of
p_c_e_1.

So I guess I don't fully understand the purpose of NON_DEPENDENT_EXPR
or how it should interact with fold_non_dependent_expr and constant
evaluation...



Actually, why are we seeing a NON_DEPENDENT_EXPR here?  Did it leak into the
AST somehow?  They should all be temporary within build_x_whatever functions.


Hmm yes, kind of.  The unusual thing about this testcase is that
build_non_dependent_expr (called from grok_array_decl) for the
COND_EXPR

   (bool)__r && __s ? 1 : 2

wraps only the condition operand, yielding

   NON_DEPENDENT_EXPR<<<(bool)__r && __s>>> ? 1 : 2// #1

rather than wrapping the whole thing i.e.

   NON_DEPENDENT_EXPR<<<(bool)__r && __s ? 1 : 2>>>// #2

cp_build_array_ref then tries to speculatively fold the non-dependent #1
as a whole, during which the COND_EXPR case of tsubst_copy_and_build
tries to speculative fold #1's condition NON_DEPENDENT_EXPR<<<(bool)__r && 
__s>>>
on its own, which ends in a crash from p_c_e_1 because at this point
processing_template_decl is cleared so p_c_e_1 attempts trial evaluation
of the CAST_EXPR (bool)__r.

If instead build_non_dependent_expr yielded #2, speculative folding of
#2 as a whole just yield #2 since tsubst doesn't look through
NON_DEPENDENT_EXPR.


Alternatively p_c_e_1 could continue to recurse into NON_DEPENDENT_EXPR,
but with trial evaluation disabled by setting processing_template_decl,
but as mentioned it seems pointless for p_c_e_1 to ever return true for
NON_DEPENDENT_EXPR.

... Since we're not issuing a diagnostic in this case, I suppose we should
also assert that tf_error isn't set.  Bootstrapped and regtested on
x86_64-pc-linux-gnu.

-- >8 --

PR c++/104507

gcc/cp/ChangeLog:

* constexpr.cc (potential_constant_expression_1)
: Return false instead of recursing.
Assert tf_error isn't set.

gcc/testsuite/ChangeLog:

* g++.dg/template/non-dependent21.C: New test.
---
   gcc/cp/constexpr.cc | 5 -
   gcc/testsuite/g++.dg/template/non-dependent21.C | 9 +
   2 files changed, 13 insertions(+), 1 deletion(-)
   create mode 100644 gcc/testsuite/g++.dg/template/non-dependent21.C

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index 7274c3b760e..b363ef08411 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -9065,6 +9065,10 @@ potential_constant_expression_1 (tree t, bool
want_rval, bool strict, bool now,
   case BIND_EXPR:
 return RECUR (BIND_EXPR_BODY (t), want_rval);
   +case NON_DEPENDENT_EXPR:
+  gcc_checking_assert (!(flags & tf_error));
+  return false;
+
   case CLEANUP_POINT_EXPR:
   case MUST_NOT_THROW_EXPR:
   case TRY_CATCH_EXPR:
@@ -9072,7 +9076,6 @@ potential_constant_expression_1 (tree t, bool
want_rval, bool strict, bool now,
   case EH_SPEC_BLOCK:
   case EXPR_STMT:
   case PAREN_EXPR:
-case NON_DEPENDENT_EXPR:
 /* For convenience.  */
   case LOOP_EXPR:
   case EXIT_EXPR:
diff --git a/gcc/testsuite/g++.dg/template/non-dependent21.C
b/gcc/testsuite/g++.dg/template/non-dependent21.C
new file mode 100644
index 000..89900837b8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/non-dependent21.C
@@ -0,0 +1,9 @@
+// PR c++/104507
+
+extern const char *_k_errmsg[];
+
+template
+const char* DoFoo(int __r, int __s) {
+  const char* n = _k_errmsg[(bool)__r && __s ? 1 : 2];
+  return n;
+}

Re: [PATCH] c++: return-type-req in constraint using only outer tparms [PR104527]

[Jason Merrill via Gcc-patches]

On 2/14/22 11:32, Patrick Palka wrote:

Here the template context for the atomic constraint has two levels of
template arguments, but since it depends only on the innermost argument
T we use a single-level argument vector during substitution into the
constraint (built by get_mapped_args).  We eventually pass this vector
to do_auto_deduction as part of checking the return-type-requirement
inside the atom, but do_auto_deduction expects outer_targs to be a full
set of arguments for sake of satisfaction.


Could we note the current number of levels in the map and use that in 
get_mapped_args instead of the highest level parameter we happened to use?



do_auto_deduction has a workaround in place to compensate for callers
that pass only the innermost arguments as outer_targs, but here we're
passing the _outermost_ arguments.  Since the former situation should
now (after r12-7101) only occur with adc_unify callers and the latter
only with adc_requirement callers, this patch conditions the existing
workaround according to the auto_deduction_context: if the context is
adc_requirement, we add dummy innermost levels, otherwise we add dummy
outermost levels as before and also assert that the context is adc_unify.

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

PR c++/104527

gcc/cp/ChangeLog:

* pt.cc (do_auto_deduction): When template argument levels are
missing from outer_targs, fill in the innermost rather than the
outermost levels with dummy args if the context is
adc_requirement, otherwise also assert that the context is
adc_unify.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-return-req4.C: New test.
---
  gcc/cp/pt.cc  | 28 +--
  .../g++.dg/cpp2a/concepts-return-req4.C   | 24 
  2 files changed, 44 insertions(+), 8 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 1b18e2a7787..4ff2710b8ba 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -30215,20 +30215,32 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
  
tree full_targs = add_to_template_args (outer_targs, targs);
  
-  /* HACK: Compensate for callers not always communicating all levels of

-outer template arguments by filling in the outermost missing levels
-with dummy levels before checking satisfaction.  We'll still crash
-if the constraint depends on a template argument belonging to one of
-these missing levels, but this hack otherwise allows us to handle a
-large subset of possible constraints (including all non-dependent
-constraints).  */
if (int missing_levels = (TEMPLATE_TYPE_ORIG_LEVEL (auto_node)
- TMPL_ARGS_DEPTH (full_targs)))
{
  tree dummy_levels = make_tree_vec (missing_levels);
  for (int i = 0; i < missing_levels; ++i)
TREE_VEC_ELT (dummy_levels, i) = make_tree_vec (0);
- full_targs = add_to_template_args (dummy_levels, full_targs);
+ if (context == adc_requirement)
+   /* We're checking a requires-expr's return-type-requirement that's
+  part of an atomic constraint that doesn't depend on any innermost
+  template arguments, so OUTER_TARGS (built by get_mapped_args) is
+  missing at least one innermost level.  Fill in the innermost
+  levels of OUTER_TARGS with dummy levels.  */
+   full_targs = add_to_template_args
+ (add_to_template_args (outer_targs, dummy_levels), targs);
+ else
+   {
+ /* Otherwise, fill in the _outermost_ levels with dummy levels.
+This compensates for adc_unify callers that only pass the
+innermost level of template arguments as OUTER_TARGS.  We'll
+still crash if the constraint depends on a template argument
+belonging to one of these missing levels, but this hack
+otherwise allows us to handle a large subset of possible
+constraints (including all non-dependent constraints).  */
+ gcc_checking_assert (context == adc_unify);
+ full_targs = add_to_template_args (dummy_levels, full_targs);
+   }
}
  
if (!constraints_satisfied_p (auto_node, full_targs))

diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
new file mode 100644
index 000..471946bc8eb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
@@ -0,0 +1,24 @@
+// PR c++/104527
+// { dg-do compile { target c++20 } }
+
+template
+concept is_same = __is_same(T, U);
+
+template
+struct A {
+  template
+requires requires { { 0 } -> is_same; }
+  struct B {};
+
+  template
+requires require

Re: [PATCH] c-family: Fix up shorten_compare for decimal vs. non-decimal float comparison [PR104510]

[Jason Merrill via Gcc-patches]

On 2/15/22 05:07, Jakub Jelinek wrote:

Hi!

The comment in shorten_compare says:
   /* If either arg is decimal float and the other is float, fail.  */
but the callers of shorten_compare don't expect anything like failure
as a possibility from the function, callers require that the function
promotes the operands to the same type, whether the original selected
*restype_ptr one or some shortened.
So, if we choose not to shorten, we should still promote to the original
*restype_ptr.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


OK.


2022-02-15  Jakub Jelinek  

PR c/104510
* c-common.cc (shorten_compare): Convert original arguments to
the original *restype_ptr when mixing binary and decimal float.

* gcc.dg/dfp/pr104510.c: New test.

--- gcc/c-family/c-common.cc.jj 2022-02-04 14:36:53.998619364 +0100
+++ gcc/c-family/c-common.cc2022-02-14 19:07:14.305068950 +0100
@@ -3174,7 +3174,11 @@ shorten_compare (location_t loc, tree *o
else if (real1 && real2
   && (DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (primop0)))
   || DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (primop1)
-return NULL_TREE;
+{
+  type = *restype_ptr;
+  primop0 = op0;
+  primop1 = op1;
+}
  
else if (real1 && real2

   && (TYPE_PRECISION (TREE_TYPE (primop0))
--- gcc/testsuite/gcc.dg/dfp/pr104510.c.jj  2022-02-14 19:11:05.610860035 
+0100
+++ gcc/testsuite/gcc.dg/dfp/pr104510.c 2022-02-14 19:10:42.819176224 +0100
@@ -0,0 +1,12 @@
+/* PR c/104510 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+float f;
+_Decimal64 d;
+
+int
+foo (void)
+{
+  return d > (_Decimal32) (_Decimal64) f;
+}

Jakub

Re: [PATCH] c-family: Remove names of unused parameters

[Joseph Myers]

On Tue, 15 Feb 2022, Jonathan Wakely via Gcc-patches wrote:

> Tested powerpc64le-linux, OK for trunk?
> 
> -- >8 --
> 
> C++ allows unnamed parameters, which means we don't need to call them
> 'dummy' and mark them with the unused attribute.
> 
> gcc/c-family/ChangeLog:
> 
>   * c-pragma.cc (handle_pragma_pack): Remove parameter name.
>   (handle_pragma_weak): Likewise.
>   (handle_pragma_scalar_storage_order): Likewise.
>   (handle_pragma_redefine_extname): Likewise.
>   (handle_pragma_visibility): Likewise.
>   (handle_pragma_diagnostic): Likewise.
>   (handle_pragma_target): Likewise.
>   (handle_pragma_optimize): Likewise.
>   (handle_pragma_push_options): Likewise.
>   (handle_pragma_pop_options): Likewise.
>   (handle_pragma_reset_options): Likewise.
>   (handle_pragma_message): Likewise.
>   (handle_pragma_float_const_decimal64): Likewise.

OK.

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

Re: [PATCH] testsuite: Fix up tree-ssa/divide-7.c testcase [PR95424]

[Mike Stump via Gcc-patches]

On Jan 29, 2022, at 8:26 AM, Jakub Jelinek via Gcc-patches 
 wrote:
> 
> This test fails everywhere, because ? doesn't match literal ?.
> It should use \\? instead.  I've also changed those .s in there.
> Tested on x86_64-linux (-m32/-m64) and powerpc64le-linux, ok for trunk?

Ok.

Re: [PATCH v6 11/12] LoongArch Port: gcc/testsuite

[Mike Stump via Gcc-patches]

On Jan 28, 2022, at 5:49 AM, chenglulu  wrote:
> 
> gcc/testsuite/
> 
>* g++.dg/cpp0x/constexpr-rom.C: Add build options for LoongArch.
>* g++.old-deja/g++.abi/ptrmem.C: Add LoongArch support.
>* g++.old-deja/g++.pt/ptrmem6.C: xfail for LoongArch.
>* gcc.dg/20020312-2.c: Add LoongArch support.
>* gcc.dg/loop-8.c: Skip on LoongArch.
>* gcc.dg/torture/stackalign/builtin-apply-2.c: Likewise.
>* gcc.dg/tree-ssa/ssa-fre-3.c: Likewise.
>* go.test/go-test.exp: Define the LoongArch target.
>* lib/target-supports.exp: Like wise.
>* gcc.target/loongarch/loongarch.exp: New file.
>* gcc.target/loongarch/tst-asm-const.c: Like wise.

Ok.

New Serbian PO file for 'cpplib' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/cpplib/sr.po

(This file, 'cpplib-12.1-b20220213.sr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Contents of PO file 'cpplib-12.1-b20220213.sr.po'

[Translation Project Robot]

cpplib-12.1-b20220213.sr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [GCC 11 PATCH 1/5] x86: Remove "%!" before ret

[Hongtao Liu via Gcc-patches]

On Tue, Feb 1, 2022 at 2:56 AM H.J. Lu via Gcc-patches
 wrote:
>
> Before MPX was removed, "%!" was mapped to
>
> case '!':
>   if (ix86_bnd_prefixed_insn_p (current_output_insn))
> fputs ("bnd ", file);
>   return;
>
> After CET was added and MPX was removed, "%!" was mapped to
>
>case '!':
>   if (ix86_notrack_prefixed_insn_p (current_output_insn))
> fputs ("notrack ", file);
>   return;
>
> ix86_notrack_prefixed_insn_p always returns false on ret since the
> notrack prefix is only for indirect branches.  Remove the unused "%!"
> before ret.
The patch LGTM.
BTW This patch seems to be independent of straight-line-speculation mitigation.
>
> PR target/103307
> * config/i386/i386.c (ix86_code_end): Remove "%!" before ret.
> (ix86_output_function_return): Likewise.
> * config/i386/i386.md (simple_return_pop_internal): Likewise.
>
> (cherry picked from commit 8e410de43ce039bbe08f1e0195e3b6ec24f68cae)
> ---
>  gcc/config/i386/i386.c  | 4 ++--
>  gcc/config/i386/i386.md | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 8e8c8beb366..4ba1a218ee6 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -6000,7 +6000,7 @@ ix86_code_end (void)
>xops[0] = gen_rtx_REG (Pmode, regno);
>xops[1] = gen_rtx_MEM (Pmode, stack_pointer_rtx);
>output_asm_insn ("mov%z0\t{%1, %0|%0, %1}", xops);
> -  output_asm_insn ("%!ret", NULL);
> +  fputs ("\tret\n", asm_out_file);
>final_end_function ();
>init_insn_lengths ();
>free_after_compilation (cfun);
> @@ -16027,7 +16027,7 @@ ix86_output_function_return (bool long_p)
>  }
>
>if (!long_p)
> -return "%!ret";
> +return "ret";
>
>return "rep%; ret";
>  }
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index db9dbf384ad..1aff2ac2a82 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -13912,7 +13912,7 @@ (define_insn_and_split "simple_return_pop_internal"
>[(simple_return)
> (use (match_operand:SI 0 "const_int_operand"))]
>"reload_completed"
> -  "%!ret\t%0"
> +  "ret\t%0"
>"&& cfun->machine->function_return_type != indirect_branch_keep"
>[(const_int 0)]
>"ix86_split_simple_return_pop_internal (operands[0]); DONE;"
> --
> 2.34.1
>


-- 
BR,
Hongtao

Re: [GCC 11 PATCH 0/5] x86: Backport straight-line-speculation mitigation

[Hongtao Liu via Gcc-patches]

On Tue, Feb 1, 2022 at 2:55 AM H.J. Lu via Gcc-patches
 wrote:
>
> Backport -mindirect-branch-cs-prefix:
>
> commit 48a4ae26c225eb018ecb59f131e2c4fd4f3cf89a
> Author: H.J. Lu 
> Date:   Wed Oct 27 06:27:15 2021 -0700
>
> x86: Add -mindirect-branch-cs-prefix
>
> Add -mindirect-branch-cs-prefix to add CS prefix to call and jmp to
> indirect thunk with branch target in r8-r15 registers so that the call
> and jmp instruction length is 6 bytes to allow them to be replaced with
> "lfence; call *%r8-r15" or "lfence; jmp *%r8-r15" at run-time.
>
> commit 63738e176726d31953deb03f7e32cf8b760735ac
> Author: H.J. Lu 
> Date:   Wed Oct 27 07:48:54 2021 -0700
>
> x86: Add -mharden-sls=[none|all|return|indirect-branch]
>
> Add -mharden-sls= to mitigate against straight line speculation (SLS)
> for function return and indirect branch by adding an INT3 instruction
> after function return and indirect branch.
>
> and followup commits to support Linux kernel commits:
>
> commit e463a09af2f0677b9485a7e8e4e70b396b2ffb6f
> Author: Peter Zijlstra 
> Date:   Sat Dec 4 14:43:44 2021 +0100
>
> x86: Add straight-line-speculation mitigation
>
> commit 68cf4f2a72ef8786e6b7af6fd9a89f27ac0f520d
> Author: Peter Zijlstra 
> Date:   Fri Nov 19 17:50:25 2021 +0100
>
> x86: Use -mindirect-branch-cs-prefix for RETPOLINE builds
>
> H.J. Lu (5):
>   x86: Remove "%!" before ret
>   x86: Add -mharden-sls=[none|all|return|indirect-branch]
>   x86: Add -mindirect-branch-cs-prefix
>   x86: Rename -harden-sls=indirect-branch to -harden-sls=indirect-jmp
>   x86: Generate INT3 for __builtin_eh_return
The patch LGTM.
>
>  gcc/config/i386/i386-opts.h   |  7 
>  gcc/config/i386/i386.c| 38 +--
>  gcc/config/i386/i386.md   |  2 +-
>  gcc/config/i386/i386.opt  | 24 
>  gcc/doc/invoke.texi   | 18 -
>  gcc/testsuite/gcc.target/i386/harden-sls-1.c  | 14 +++
>  gcc/testsuite/gcc.target/i386/harden-sls-2.c  | 14 +++
>  gcc/testsuite/gcc.target/i386/harden-sls-3.c  | 14 +++
>  gcc/testsuite/gcc.target/i386/harden-sls-4.c  | 16 
>  gcc/testsuite/gcc.target/i386/harden-sls-5.c  | 17 +
>  gcc/testsuite/gcc.target/i386/harden-sls-6.c  | 18 +
>  .../i386/indirect-thunk-cs-prefix-1.c | 14 +++
>  .../i386/indirect-thunk-cs-prefix-2.c | 15 
>  13 files changed, 198 insertions(+), 13 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/harden-sls-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/harden-sls-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/harden-sls-3.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/harden-sls-4.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/harden-sls-5.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/harden-sls-6.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/indirect-thunk-cs-prefix-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/indirect-thunk-cs-prefix-2.c
>
> --
> 2.34.1
>


-- 
BR,
Hongtao

Re: [PATCH] c++: Add diagnostic when operator= is used as truth cond [PR25689]

[Zhao Wei Liew via Gcc-patches]

On Wed Feb 16, 2022 at 4:06 AM +08, Jason Merrill wrote:
> > Ah, I see. I found it a bit odd that gcc-commit-mklog auto-generated a 
> > subject with "c:",
> > but I just went with it as I didn't know any better. Unfortunately, I 
> > can't change it now on the current thread.
>
> That came from this line in the testcase:
>
>  > +/* PR c/25689 */
>
> The PR should be c++/25689.  Also, sometimes the bugzilla component 
> isn't the same as the area of the compiler you're changing; the latter 
> is what you want in the patch subject, so that the right people know to 
> review it.

Oh, I see. Thanks for the explanation. I've fixed the line.

> > Ah, I didn't notice that. Sorry about that! I'm kinda new to the whole 
> > mailing list setup so there are some kinks I have to iron out.
>
> FWIW it's often easier to send the patch as an attachment.

Alright, I'll send patches as attachments instead. I originally sent
them as text as it is easier to comment on them.

> > -  gcc_assert (TREE_CODE (call) == CALL_EXPR
> > -  || TREE_CODE (call) == AGGR_INIT_EXPR
> > -  || call == error_mark_node);
> > +  if (TREE_CODE (call) != CALL_EXPR
> > +  && TREE_CODE (call) != AGGR_INIT_EXPR
> > +  && call != error_mark_node)
> > +  return NULL_TREE;
> >  return call;
>
> Note that since this can return error_mark_node...
>
> >  }
> >  
> > diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> > index 0cb17a6a8ab..7a8f317af0d 100644
> > --- a/gcc/cp/semantics.cc
> > +++ b/gcc/cp/semantics.cc
> > @@ -815,6 +815,24 @@ finish_goto_stmt (tree destination)
> >  return add_stmt (build_stmt (input_location, GOTO_EXPR, destination));
> >  }
> >  
> > +/* Returns true if CALL is a (possibly wrapped) CALL_EXPR or AGGR_INIT_EXPR
> > +  to operator=() that is written as an operator expression. */
> > +static bool
> > +is_assignment_op_expr_p (tree call)
> > +{
> > +  if (call == NULL_TREE)
> > +  return false;
> > +
> > +  call = extract_call_expr (call);
> > +  if (call == NULL_TREE || !CALL_EXPR_OPERATOR_SYNTAX (call))
>
> ...you probably want to check for it here.

Good point. I've added the check.

> > +/* Test non-empty class */
> > +void f2(B b1, B b2)
> > +{
> > + if (b1 = 0); /* { dg-warning "suggest parentheses" } */
> > + if (b1 = 0.); /* { dg-warning "suggest parentheses" } */
> > + if (b1 = b2); /* { dg-warning "suggest parentheses" } */
> > + if (b1.operator= (0));
> > +
> > + /* Ideally, we wouldn't warn for non-empty classes using trivial
> > +  operator= (below), but we currently do as it is a MODIFY_EXPR. */
> > + // if (b1.operator= (b2));
>
> You can avoid it by calling suppress_warning on that MODIFY_EXPR in 
> build_over_call.

Unfortunately, that also affects the warning for if (b1 = b2) just 5
lines above. Both expressions seem to generate the same tree structure.



0001-c-Add-diagnostic-when-operator-is-used-as-truth-cond.patch
Description: application/mbox

Re: [PATCH v7] c++: Add diagnostic when operator= is used as truth cond [PR25689]

[Zhao Wei Liew via Gcc-patches]

Before I start, sincere apologies for the email mishaps! I was setting up
an email client and somehow the emails I sent did not initially seem to
go through, but they actually did. You might have received several
duplicate emails as a result.

On Wed Feb 16, 2022 at 4:06 AM +08, Jason Merrill wrote:
> > Ah, I see. I found it a bit odd that gcc-commit-mklog auto-generated a
> > subject with "c:",
> > but I just went with it as I didn't know any better. Unfortunately, I
> > can't change it now on the current thread.
>
> That came from this line in the testcase:
>
>  > +/* PR c/25689 */
>
> The PR should be c++/25689.  Also, sometimes the bugzilla component
> isn't the same as the area of the compiler you're changing; the latter
> is what you want in the patch subject, so that the right people know to
> review it.

Oh, I see. Thanks for the explanation. I've fixed the line.

> > Ah, I didn't notice that. Sorry about that! I'm kinda new to the whole
> > mailing list setup so there are some kinks I have to iron out.
>
> FWIW it's often easier to send the patch as an attachment.

Alright, I'll send patches as attachments instead. I originally sent
them as text as it is easier to comment on them.
> > +/* Test non-empty class */
> > +void f2(B b1, B b2)
> > +{
> > + if (b1 = 0); /* { dg-warning "suggest parentheses" } */
> > + if (b1 = 0.); /* { dg-warning "suggest parentheses" } */
> > + if (b1 = b2); /* { dg-warning "suggest parentheses" } */
> > + if (b1.operator= (0));
> > +
> > + /* Ideally, we wouldn't warn for non-empty classes using trivial
> > +  operator= (below), but we currently do as it is a MODIFY_EXPR. */
> > + // if (b1.operator= (b2));
>
> You can avoid it by calling suppress_warning on that MODIFY_EXPR in
> build_over_call.

Unfortunately, that also affects the warning for if (b1 = b2) just 5
lines above. Both expressions seem to generate the same tree structure.

v6: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590419.html
1. Check for error_mark_node in is_assignment_op_expr_pr.
2. Change "c:" to "c++:".

v5: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590393.html
Changes since v5:
1. Revert changes in v4.
2. Replace gcc_assert with a return NULL_TREE in extract_call_expr.

v4: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590379.html
Changes since v4:
1. Refactor the non-assert-related code out of extract_call_expr and
   call that function instead to check for call expressions.

v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html
Changes since v3:
1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.

v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.

v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
   operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.
From b89c3ebcfb4d7b3777bb70c1c0272cfd3bf29247 Mon Sep 17 00:00:00 2001
From: Zhao Wei Liew 
Date: Tue, 15 Feb 2022 17:44:29 +0800
Subject: [PATCH] c++: Add diagnostic when operator= is used as truth cond
 [PR25689]

When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:

struct A {
	A& operator=(int);
	operator bool();
};

void f(A a) {
	if (a = 0); // no warning
}

This is because a = 0 is a call to operator=, which GCC does not handle.

This patch fixes this issue by handling calls to operator= when deciding
to warn.

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

	PR c++/25689

gcc/cp/ChangeLog:

	* call.cc (extract_call_expr): Return a NULL_TREE on failure
	  instead of asserting.
	* semantics.cc (is_assignment_op_expr_p): Add function to check
	  if an expression is a call to an op= operator expression.
	(maybe_convert_cond): Handle the case of a op= operator expression
	  for the -Wparentheses diagnostic.

gcc/testsuite/ChangeLog:

	* g++.dg/warn/Wparentheses-31.C: New test.

Signed-off-by: Zhao Wei Liew 
---
 gcc/cp/call.cc  |  7 ++-
 gcc/cp/semantics.cc | 22 +++-
 gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 62 +
 3 files changed, 87 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index d6eed5ed835..3b2c6d8c499 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -7090,9 +7090,10 @@ extract_call_expr (tree call)
   default:;
   }
 
-  gcc_assert (TREE_CODE (call) == CALL_EXPR
-	  || TREE_CODE (call) == AGGR_INIT_EXPR
-	  || call == error_mark_node);
+  if (TREE_CODE (call) != CALL_EXPR
+  && TREE_CODE (call) != AGGR_INIT

Contents of PO file 'cpplib-12.1-b20220213.vi.po'

[Translation Project Robot]

cpplib-12.1-b20220213.vi.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Vietnamese PO file for 'cpplib' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/cpplib/vi.po

(This file, 'cpplib-12.1-b20220213.vi.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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