[RFC] split pseudos during loop unrolling in RTL unroller

[Jiufu Guo via Gcc-patches]

Hi,

As you may know, we have loop unroll pass in RTL which was introduced a few
years ago, and works for a long time.  Currently, this unroller is using the
pseudos in the original body, and then the pseudos are written multiple times.

It would be a good idea to create new pseudos for those duplicated instructions
during loop unrolling.  This would relax reg dependence, and then provide more
freedom/opportunity for other optimizations, like scheduling, RA... 

As below example:

Original loop:
```
   26: L26:
   17: NOTE_INSN_BASIC_BLOCK 4
   18: r130:SF=[r125:DI+r122:DI]
   19: r131:SF=[r126:DI+r122:DI]
   20: r129:SF=r130:SF*r131:SF
   21: r132:DF=float_extend(r129:SF)
   22: r121:DF=r121:DF+r132:DF
   23: r133:SI=r123:DI#0-0x1
   24: r123:DI=zero_extend(r133:SI)
   25: r122:DI=r122:DI+0x4
   27: r134:CC=cmp(r123:DI,0)
   28: pc={(r134:CC!=0)?L49:pc}
  ; pc falls through to BB 5
   49: L49:
   48: NOTE_INSN_BASIC_BLOCK 8
  ; pc falls through to BB 4
```
It was unrolled to:
```
   26: L26:
   17: NOTE_INSN_BASIC_BLOCK 4
   18: r130:SF=[r125:DI+r122:DI]
   19: r131:SF=[r126:DI+r122:DI]
   20: r129:SF=r130:SF*r131:SF
   21: r132:DF=float_extend(r129:SF)
   93: r145:DF=r121:DF+r132:DF
   23: r133:SI=r123:DI#0-0x1
   95: r148:DI=zero_extend(r133:SI)
   91: r140:DI=r122:DI+0x4
   25: r122:DI=r140:DI
   97: r134:CC=cmp(r148:DI,0)

   87: NOTE_INSN_BASIC_BLOCK 16
   77: r130:SF=[r125:DI+r122:DI]
   78: r131:SF=[r126:DI+r122:DI]
   79: r129:SF=r130:SF*r131:SF
   80: r132:DF=float_extend(r129:SF)
   81: r121:DF=r121:DF+r132:DF
   82: r133:SI=r123:DI#0-0x1
   83: r123:DI=zero_extend(r133:SI)
   84: r122:DI=r140:DI+0x4
   85: r134:CC=cmp(r123:DI,0)
   86: pc={(r134:CC!=0)?L90:pc}

```
We can see, the original loop is using r130,r131,r129,r132,r121...
For the unrolled sequence BB 16, they are still using them.

We could use new pseudos for duplicate body, like below:
```
   26: L26:
   17: NOTE_INSN_BASIC_BLOCK 4
   18: r130:SF=[r125:DI+r122:DI]
   19: r131:SF=[r126:DI+r122:DI]
   20: r129:SF=r130:SF*r131:SF
   21: r132:DF=float_extend(r129:SF)
   93: r145:DF=r121:DF+r132:DF
   23: r133:SI=r123:DI#0-0x1
   95: r148:DI=zero_extend(r133:SI)
   91: r140:DI=r122:DI+0x4
   25: r122:DI=r140:DI
   97: r134:CC=cmp(r148:DI,0)

   87: NOTE_INSN_BASIC_BLOCK 16
   77: r141:SF=[r125:DI+r122:DI]
   78: r142:SF=[r126:DI+r122:DI]
   79: r143:SF=r141:SF*r142:SF
   80: r144:DF=float_extend(r143:SF)
   81: r146:DF=r145:DF+r144:DF
   82: r147:SI=r148:DI#0-0x1
   83: r149:DI=zero_extend(r147:SI)
   84: r122:DI=r140:DI+0x4
   85: r150:CC=cmp(r149:DI,0)
   98: r130:SF=r141:SF
   99: r131:SF=r142:SF
  100: r129:SF=r143:SF
  101: r132:DF=r144:DF
  102: r121:DF=r146:DF
  103: r133:SI=r147:SI
  104: r123:DI=r149:DI
  105: r134:CC=r150:CC
   86: pc={(r150:CC!=0)?L90:pc}
``` 
In BB 16, new pseudos: r141,r142,r143... are used.

For this, I drafted a prototype like the patch below.
This patch only supports simple loops: one exit edge with one major basic block.

With this patch, we can see, the generated asm code uses fewer instructions on 
PowerPC.

Welcome for comments, thanks!

BR.
Jiufu Guo.

---
 gcc/common.opt|   4 +
 gcc/loop-unroll.c | 309 +-
 2 files changed, 310 insertions(+), 3 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index fa9da505fc2..e298ce09c82 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2526,6 +2526,10 @@ fvariable-expansion-in-unroller
 Common Report Var(flag_variable_expansion_in_unroller) Optimization
 Apply variable expansion when loops are unrolled.
 
+fassin-new-operand-in-unroller
+Common Report Var(flag_assign_new_operand_in_unroller) Init(1) Optimization
+Creating new pseudo for duplicated instruction when loops are unrolled.
+
 fstack-check=
 Common Report RejectNegative Joined Optimization
 -fstack-check=[no|generic|specific]Insert stack checking code into the 
program.
diff --git a/gcc/loop-unroll.c b/gcc/loop-unroll.c
index 693c7768868..54a48bd9fd7 100644
--- a/gcc/loop-unroll.c
+++ b/gcc/loop-unroll.c
@@ -94,6 +94,17 @@ struct var_to_expand
   var_expansions[REUSE_EXPANSION - 1].  */
 };
 
+struct def_to_split
+{
+  rtx_insn *insn;  /* The insn in that the assigment occurs.  */
+  rtx reg;  /* The def/set pseudo.  */
+  vec defs;/* The copies of the defs which is split to.  */
+  struct def_to_split *next; /* Next entry in walking order.  */
+  int count;/* Number of DEFS.  */
+  int use_before_def;  /* The pseudo is used before re-defined.  */
+  rtx_insn *last_insn;
+};
+
 /* Hashtable helper for iv_to_split.  */
 
 struct iv_split_hasher : free_ptr_hash 
@@ -143,6 +154,30 @@ var_expand_hasher::equal (const var_to_expand *i1, const 
var_to_expand *i2)
   return i1->insn == i2->insn;
 }
 
+/* Hashtable helper for iv_to_split.  */
+
+struct def_split_hasher : free_ptr_hash
+{
+  static inline hashval_t hash (const def_to_split *);
+  static 

Re: [PATCH] xtensa: fix PR target/94584

[Max Filippov via Gcc-patches]

On Tue, Apr 14, 2020 at 4:40 PM augustine.sterl...@gmail.com
 wrote:
>
> On Mon, Apr 13, 2020 at 4:39 PM Max Filippov  wrote:
> > 2020-04-13  Max Filippov  
> > gcc/
> > * config/xtensa/xtensa.md (zero_extendhisi2, zero_extendqisi2)
> > (extendhisi2_internal): Add %v1 before the load instructions.
> >
> > gcc/testsuite/
> > * gcc.target/xtensa/pr94584.c: New test.
>
> Approved. Surprised this hasn't been caught before.

Thanks. Applied to master. I'll apply it later to gcc-8 and gcc-9 branches.
I believe that we don't have use cases in linux that rely on memw associated
with volatile memory access, so it's nice to have non-linux user with different
requirements.

-- 
Thanks.
-- Max

Re: [PATCH] gcc/gcc.c: add outfiles spec

[Joseph Myers]

On Tue, 14 Apr 2020, Rasmus Villemoes wrote:

> On 06/04/2020 23.18, Joseph Myers wrote:
> > On Sat, 4 Apr 2020, Rasmus Villemoes wrote:
> > 
> >> +#ifndef OUTFILES_SPEC
> >> +#define OUTFILES_SPEC "%o"
> >> +#endif
> > 
> > A new target macro needs to be documented in tm.texi.in,
> 
> Will do.
> 
> > with tm.texi then being regenerated.
> 
> Please include information on how I would go about doing that, or point
> at a README/wiki that explains it. Is it just copying the generated
> tm.texi from the build/gcc/ dir back to the src/gcc/doc/ dir?

Yes, copy from the build directory to the source directory.

> Also, does my write-after-approval permission still apply after ~1.5
> years of non-activity, and the switch to git? If so, do I just make sure

It's not time-limited.  (However, when someone's employer changes they may 
need to get a new employer assignment / disclaimer before continuing to 
contribute changes that are significant for copyright purposes.)

> my changes (after approval, of course) apply cleanly on top of master
> and then push that?

Yes, once changes are approved you should push them.

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

Re: [PATCH] xtensa: fix PR target/94584

[augustine.sterling--- via Gcc-patches]

On Mon, Apr 13, 2020 at 4:39 PM Max Filippov  wrote:
> 2020-04-13  Max Filippov  
> gcc/
> * config/xtensa/xtensa.md (zero_extendhisi2, zero_extendqisi2)
> (extendhisi2_internal): Add %v1 before the load instructions.
>
> gcc/testsuite/
> * gcc.target/xtensa/pr94584.c: New test.

Approved. Surprised this hasn't been caught before.

[committed] libstdc++: Fix constraints on std::compare_three_way

[Jonathan Wakely via Gcc-patches]

My "simplification" of std::compare_three_way's constraints in commit
f214ffb336d582a66149068a2a96b7fcf395b5de was incorrect, because
std::three_way_comparable_with imposes additional restrictions beyond
the <=> expression being valid.

* libsupc++/compare (compare_three_way): Fix constraint so that
BUILTIN-PTR-THREE-WAY does not require three_way_comparable_with.
* testsuite/18_support/comparisons/object/builtin-ptr-three-way.cc:
New test.

Tested powerpc64l-linux, committed to master.


commit e1e9e8d7aa7bf1b0d3de34345b6c649e07da7a1e
Author: Jonathan Wakely 
Date:   Tue Apr 14 21:58:03 2020 +0100

libstdc++: Fix constraints on std::compare_three_way

My "simplification" of std::compare_three_way's constraints in commit
f214ffb336d582a66149068a2a96b7fcf395b5de was incorrect, because
std::three_way_comparable_with imposes additional restrictions beyond
the <=> expression being valid.

* libsupc++/compare (compare_three_way): Fix constraint so that
BUILTIN-PTR-THREE-WAY does not require three_way_comparable_with.
* testsuite/18_support/comparisons/object/builtin-ptr-three-way.cc:
New test.

diff --git a/libstdc++-v3/libsupc++/compare b/libstdc++-v3/libsupc++/compare
index 5f1df19e445..e5fb322ed9e 100644
--- a/libstdc++-v3/libsupc++/compare
+++ b/libstdc++-v3/libsupc++/compare
@@ -481,13 +481,14 @@ namespace std
 // BUILTIN-PTR-THREE-WAY(T, U)
 template
   concept __3way_builtin_ptr_cmp
-   = three_way_comparable_with<_Tp, _Up>
+   = requires(_Tp&& __t, _Up&& __u)
+ { static_cast<_Tp&&>(__t) <=> static_cast<_Up&&>(__u); }
  && convertible_to<_Tp, const volatile void*>
  && convertible_to<_Up, const volatile void*>
  && ! requires(_Tp&& __t, _Up&& __u)
-{ operator<=>(static_cast<_Tp&&>(__t), static_cast<_Up&&>(__u)); }
+ { operator<=>(static_cast<_Tp&&>(__t), static_cast<_Up&&>(__u)); }
  && ! requires(_Tp&& __t, _Up&& __u)
-{ static_cast<_Tp&&>(__t).operator<=>(static_cast<_Up&&>(__u)); };
+ { static_cast<_Tp&&>(__t).operator<=>(static_cast<_Up&&>(__u)); };
   } // namespace __detail
 
   // [cmp.object], typename compare_three_way
@@ -495,6 +496,7 @@ namespace std
   {
 template
   requires three_way_comparable_with<_Tp, _Up>
+  || __detail::__3way_builtin_ptr_cmp<_Tp, _Up>
   constexpr auto
   operator()(_Tp&& __t, _Up&& __u) const
   noexcept(noexcept(std::declval<_Tp>() <=> std::declval<_Up>()))
diff --git 
a/libstdc++-v3/testsuite/18_support/comparisons/object/builtin-ptr-three-way.cc 
b/libstdc++-v3/testsuite/18_support/comparisons/object/builtin-ptr-three-way.cc
new file mode 100644
index 000..38b3c6e3211
--- /dev/null
+++ 
b/libstdc++-v3/testsuite/18_support/comparisons/object/builtin-ptr-three-way.cc
@@ -0,0 +1,45 @@
+// Copyright (C) 2020 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
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+
+#include 
+
+void
+test01()
+{
+  struct X
+  {
+operator int() const { return 0; }
+operator long*() const { return nullptr; }
+  } x;
+
+  // Not three-way-comparable because of ambiguous conversion to int or long*:
+  static_assert( ! std::three_way_comparable );
+
+  // And therefore X is not three-way-comparable-with anything else
+  // (because std::three_way_comparable_with requires that both
+  // three_way_comparable and three_way_comparable are true).
+  static_assert( ! std::three_way_comparable_with );
+
+  long l;
+  // But <=> is valid and resolves to a builtin operator comparing pointers:
+  auto c =  <=> x;
+  // So std::compare_three_way should be usable:
+  auto c2 = std::compare_three_way()(, x);
+}

Re: [PATCH], Fix target/94557 PowerPC regression on GCC 9 (variable vec_extract)

[Michael Meissner via Gcc-patches]

On Tue, Apr 14, 2020 at 07:39:44AM -0500, Segher Boessenkool wrote:
> Hi,
> 
> On Mon, Apr 13, 2020 at 10:24:39PM -0400, Michael Meissner wrote:
> > This patch fixes PR target/94557, on PowerPC.  It was a regression on the 
> > GCC 9
> > branch caused by my recent patch for PR target/93932.
> > 
> > The patch for 93932 was a back port from the master branch of a fix for the
> > vec_extract built-in function.  This patch fixes the case where we are
> > optimizing a vector extract from an vector in memory to be a scalar load
> > instead of loading the vector to a register and then doing an extract.
> 
> What does "this patch" mean?  The backport?
> 
> > This patch adds in the masking of the vector index that is in the master
> > branch.  I re-implemented the change for GCC 9, since the changes on the 
> > master
> > branch are more extensive, and include PC-relative support that is not in 
> > GCC
> > 9.
> 
> Hrm.
> 
> > 2020-04-13  Michael Meissner  
> > 
> > PR target/94557
> > * config/rs6000/rs6000.c (rs6000_adjust_vec_address): Mask
> > variable vector extract index so it does not go beyond the vector
> > when extracting a vector element from memory.  This change is a
> > simplification of the 2020-02-03 patch that went into the trunk.
> 
> You have no patches go into trunk at that date.

Lets see if I can clarify things.

One of the examples comes from vsx-builtin-10a.c.  It has the following code:

#define CONST0  (0)
#define CONST1  (1)
#define CONST2  (2)
#define CONST3  (3)
#define CONST4  (4)
#define CONST5  (5)
#define CONST6  (6)
#define CONST7  (7)

__attribute__((noinline))
short mci (vector short *vp, int i)
{
  return __builtin_vec_ext_v8hi (*vp, i);
}

int main (int argc, short *argv[]) {
  vector short sv = {
CONST0, CONST1, CONST2, CONST3, CONST4, CONST5, CONST6, CONST7 };
  short s;

  /* ... */

  s = mci (, 25);
  if (s != CONST1)
abort ();
}

The current trunk generates the correct code for both -mcpu=power8 and power9

power8: power9:
mci:mci:
rldicl 9,4,0,61 rldicl 9,4,0,61
rldicr 3,3,0,59 sldi 9,9,1
sldi 9,9,1  lhzx 4,3,9
lhzx 4,3,9  extsh 3,4
extsh 3,4   blr
blr

The 'rldicr 3,3,0,59' is presumably due to alignment issues in vectors between
p8 and p9.  The important line is the 'rldicl 9,4,0,61' which truncates the
variable vector index to be between 0..7.  The test that fails has an index of
25 (i.e. out of bounds).

The GCC 9 -mcpu=power9 code does the optimization converting vec_extract from a
vector in memory to be a normal load, but the GCC 9 -mcpu=power8 code does not
do this optimization.

power8: power9:
mci:mci:
rldicl 9,4,0,61 sldi 9,4,1
lvx 0,0,3   lhzx 4,3,9
subfic 9,9,7extsh 3,4
sldi 9,9,4  blr
mtvsrd 33,9
xxpermdi 33,33,33,0
vslo 1,0,1
mfvsrd 3,33
srdi 3,3,48
extsh 3,3
blr

Notice that even though the optimization of using a scalar load is not done for
-mcpu=power8, it does do the masking.  Thus it will access the correct element.

The code for -mcpu=power9 is missing the masking.  So when it is given an index
of 25, it randomly indexes outside of the vector, picking up whatever 2 byte
value is is after the vector in question.  The test in particular checks to see
that the element #1 is return, and fails at execution time.

The patch for PR target/94557, provides this masking when the optimization is
done.

Now, what happened with the backport of the 93932 patch, is without the 93932
patch, it always called rs6000_split_vec_extract_var which does the masking.

The master branch now splits this into 2 cases, extracting from a vector in a
register calls rs6000_split_vec_extract_var, but extracting a scalar from a
vector in memory calls the lower level function rs6000_adjust_vec_address.  In
the master branch, as part of the PC-relative support, the
rs6000_adjust_vec_address function now does the masking.  In GCC 9, we were
relying on the masking being done in rs6000_split_vec_extract_var before it
calls rs6000_adjust_vec_address.

And if you remember, part of the issue with master patches in that area is you
pointed out that we were modifying an operand to do the masking.

> > --- /tmp/4XFFqK_rs6000.c2020-04-13 15:28:33.514011024 -0500
> > +++ gcc/config/rs6000/rs6000.c  2020-04-13 14:24:01.296932921 -0500
> > @@ -7047,18 +7047,25 @@ rs6000_adjust_vec_address (rtx scalar_re
> >  element_offset = GEN_INT (INTVAL (element) * scalar_size);
> >else
> >  {
> > +  /* Mask the element to make sure the element number is 

[committed] libstdc++: Add comparison operators to std::shared_ptr (PR 94562)

[Jonathan Wakely via Gcc-patches]

This also implements the proposed resolution to LWG issue 3247, so that
the ill-formed <=> expression with nullptr is not used.

PR libstdc++/94562
* include/bits/shared_ptr.h (operator<=>): Define for C++20.
* include/bits/shared_ptr_base.h (operator<=>): Likewise.
* include/bits/unique_ptr.h (operator<=>): Add inline specifier.
* testsuite/20_util/shared_ptr/comparison/cmp_c++20.cc: New test.
* testsuite/20_util/shared_ptr/comparison/less.cc: Do not expect
std::less to be used when comparing std::shared_ptr objects in
C++20.

Tested powerpc64le-linux, committed to master.


commit f5fa62ed19a1c85cda920bbe05eb075d8f2a0b42
Author: Jonathan Wakely 
Date:   Tue Apr 14 21:54:55 2020 +0100

libstdc++: Add comparison operators to std::shared_ptr (PR 94562)

This also implements the proposed resolution to LWG issue 3247, so that
the ill-formed <=> expression with nullptr is not used.

PR libstdc++/94562
* include/bits/shared_ptr.h (operator<=>): Define for C++20.
* include/bits/shared_ptr_base.h (operator<=>): Likewise.
* include/bits/unique_ptr.h (operator<=>): Add inline specifier.
* testsuite/20_util/shared_ptr/comparison/cmp_c++20.cc: New test.
* testsuite/20_util/shared_ptr/comparison/less.cc: Do not expect
std::less to be used when comparing std::shared_ptr objects 
in
C++20.

diff --git a/libstdc++-v3/include/bits/shared_ptr.h 
b/libstdc++-v3/include/bits/shared_ptr.h
index c4df3582e20..0c393e23132 100644
--- a/libstdc++-v3/include/bits/shared_ptr.h
+++ b/libstdc++-v3/include/bits/shared_ptr.h
@@ -442,6 +442,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator==(const shared_ptr<_Tp>& __a, nullptr_t) noexcept
 { return !__a; }
 
+#ifdef __cpp_lib_three_way_comparison
+  template
+inline strong_ordering
+operator<=>(const shared_ptr<_Tp>& __a,
+   const shared_ptr<_Up>& __b) noexcept
+{ return compare_three_way()(__a.get(), __b.get()); }
+
+  template
+inline strong_ordering
+operator<=>(const shared_ptr<_Tp>& __a, nullptr_t) noexcept
+{
+  using pointer = typename shared_ptr<_Tp>::element_type*;
+  return compare_three_way()(__a.get(), static_cast(nullptr));
+}
+#else
   /// shared_ptr comparison with nullptr
   template
 _GLIBCXX_NODISCARD inline bool
@@ -548,6 +563,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _GLIBCXX_NODISCARD inline bool
 operator>=(nullptr_t, const shared_ptr<_Tp>& __a) noexcept
 { return !(nullptr < __a); }
+#endif
 
   // 20.7.2.2.8 shared_ptr specialized algorithms.
 
diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h 
b/libstdc++-v3/include/bits/shared_ptr_base.h
index c9017ede4cb..ff578e66117 100644
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -54,6 +54,9 @@
 #include 
 #include 
 #include 
+#if __cplusplus > 201703L
+# include 
+#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -1442,6 +1445,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator==(const __shared_ptr<_Tp, _Lp>& __a, nullptr_t) noexcept
 { return !__a; }
 
+#ifdef __cpp_lib_three_way_comparison
+  template
+inline strong_ordering
+operator<=>(const __shared_ptr<_Tp, _Lp>& __a,
+   const __shared_ptr<_Up, _Lp>& __b) noexcept
+{ return compare_three_way()(__a.get(), __b.get()); }
+
+  template
+inline strong_ordering
+operator<=>(const __shared_ptr<_Tp, _Lp>& __a, nullptr_t) noexcept
+{
+  using pointer = typename __shared_ptr<_Tp, _Lp>::element_type*;
+  return compare_three_way()(__a.get(), static_cast(nullptr));
+}
+#else
   template
 inline bool
 operator==(nullptr_t, const __shared_ptr<_Tp, _Lp>& __a) noexcept
@@ -1537,6 +1555,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 inline bool
 operator>=(nullptr_t, const __shared_ptr<_Tp, _Lp>& __a) noexcept
 { return !(nullptr < __a); }
+#endif // three-way comparison
 
   // 20.7.2.2.8 shared_ptr specialized algorithms.
   template
diff --git a/libstdc++-v3/include/bits/unique_ptr.h 
b/libstdc++-v3/include/bits/unique_ptr.h
index 53c8def627d..3695214808b 100644
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -888,6 +888,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 requires three_way_comparable_with::pointer,
   typename unique_ptr<_Up, _Ep>::pointer>
+inline
 compare_three_way_result_t::pointer,
   typename unique_ptr<_Up, _Ep>::pointer>
 operator<=>(const unique_ptr<_Tp, _Dp>& __x,
@@ -896,11 +897,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
 requires three_way_comparable::pointer>
+inline
 compare_three_way_result_t::pointer>
 operator<=>(const unique_ptr<_Tp, _Dp>& __x, nullptr_t)
 {
   using pointer = typename unique_ptr<_Tp, 

Re: [PATCH v2] Fix use of singleton in optinfo framework

[Piotr Kubaj via Gcc-patches]

I have already bisected GCC 10 issue here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494

The problem is commit 634afa05a8cbff010480088811fe1f39eca70c1d.

On 20-04-14 21:11:01, Iain Sandoe wrote:

Gerald Pfeifer  wrote:


On Tue, 7 Apr 2020, Gustavo Romero via Gcc-patches wrote:

gcc/Changelog:
2020-04-06  Gustavo Romero  

* dumpfile.c:
(selftest::temp_dump_context::temp_dump_context): Fix ctor.


If you approve (David, Jakub, or someone else) I can take care of
committing this if you like.


It would be helpful to get this resolved in the next days.


+1 for earlier Darwin platforms.

on GCC-9.x this fixes bootstrap with Apple gcc-4.2.1 (XCode 3.1.4, 3.2.6 and
some earlier versions of 4.x)

For master/10, we’re still broken by some other issue - but it does at
least get
us past the self-test.

Iain



signature.asc
Description: PGP signature

Re: [PATCH v2] Fix use of singleton in optinfo framework

[Iain Sandoe via Gcc-patches]

Gerald Pfeifer  wrote:


On Tue, 7 Apr 2020, Gustavo Romero via Gcc-patches wrote:

gcc/Changelog:
2020-04-06  Gustavo Romero  

* dumpfile.c:
(selftest::temp_dump_context::temp_dump_context): Fix ctor.


If you approve (David, Jakub, or someone else) I can take care of
committing this if you like.


It would be helpful to get this resolved in the next days.


+1 for earlier Darwin platforms.

on GCC-9.x this fixes bootstrap with Apple gcc-4.2.1 (XCode 3.1.4, 3.2.6 and
some earlier versions of 4.x)

For master/10, we’re still broken by some other issue - but it does at  
least get

us past the self-test.

Iain

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Iain Sandoe]

Rainer Orth  wrote:

>> Rainer Orth  wrote:
 On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote:
> Unfortunately, several targets have ABI constraints that prevent
> an indirect tail-call, which results in the PRs compile error.
>> 
>> So .. after scanning the current published testsuite results I have:
>> 
>> // See PR94359 - some targets are unable to make general indirect tailcalls
>> // for example, between different DSOs.
>> // { dg-xfail-run-if "" { hppa*-*-hpux11* } }
>> // { dg-xfail-run-if "" { ia64-*-linux-gnu } }
>> // { dg-xfail-run-if "" { { lp64 && { powerpc*-linux-gnu } } || { *-*-aix*
>> } } }
>> // { dg-xfail-run-if "" { sparc-*-solaris2* } }
> 
> this is wrong: for one, it needs to allow for 64-bit-default SPARC
> configurations (i.e. sparcv9-*-* and sparc64-*-*), and AFAICS there's
> nothing Solaris-specific here.  So this should be sparc*-*-* instead.
> 
>> I’d say it would be a reasonable idea to get this in sooner rather than
>> later, we
>> can always increase the list (or a target maintainer can trivially add
>> their target)
> 
> Fine with me.  If the list gets much longer or the conditions more
> complex, it might still be worthwhile to use an effective-target keyword
> instead.

This is what I’ve pushed after re-checking on
x86_64-linux/darwin
sparc-solaris11
powerpc64-linux-gnu

I won’t be entirely surprised if the list needs amendment or additions
but that’s realistically what I can test.

thanks for the reviews,

Iain

coroutines: Fix compile error with symmetric transfers [PR94359]

For symmetric transfers to work with C++20 coroutines, it is
currently necessary to tail call the callee coroutine from resume
method of the caller coroutine. The current codegen marks these
resume calls as "MUST_TAIL_CALL" to indicate that the tail call is
required for correctness.

Unfortunately, several targets have ABI constraints that prevent
an indirect tail-call, which results in the PRs compile error.

The change here tests the target sibcall hook for the resume
expression and only marks it as requiring a tail call if that's
supported.

This doesn't fix the underlying problem; that really a solution is
needed to allow the tail-calls (or equivalent) to take place - but
that will be deferred until next stage 1.

gcc/cp/ChangeLog:

2020-04-14  Iain Sandoe  

PR c++/94359
* coroutines.cc (build_actor_fn): Check that the target can
support the resume tailcall before mandating it.

gcc/testsuite/ChangeLog:

2020-04-14  Iain Sandoe  

PR c++/94359
* g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:
Expect a run fail for targets without arbitrary indirect
tail-calls.


diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 57172853639..e4ba642d527 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2376,14 +2376,22 @@ build_actor_fn (location_t loc, tree coro_frame_type, 
tree actor, tree fnbody,
   tree resume = build_call_expr_loc
 (loc, builtin_decl_explicit (BUILT_IN_CORO_RESUME), 1, addr);
 
+  /* In order to support an arbitrary number of coroutine continuations,
+ we must tail call them.  However, some targets might not support this
+ for indirect calls, or calls between DSOs.
+ FIXME: see if there's an alternate strategy for such targets.  */
   /* Now we have the actual call, and we can mark it as a tail.  */
   CALL_EXPR_TAILCALL (resume) = true;
-  /* ... and for optimisation levels 0..1, mark it as requiring a tail-call
- for correctness.  It seems that doing this for optimisation levels that
- normally perform tail-calling, confuses the ME (or it would be logical
- to put this on unilaterally).  */
-  if (optimize < 2)
-CALL_EXPR_MUST_TAIL_CALL (resume) = true;
+  /* Temporarily, switch cfun so that we can use the target hook.  */
+  push_struct_function (actor);
+  if (targetm.function_ok_for_sibcall (NULL_TREE, resume))
+{
+  /* ... and for optimisation levels 0..1, which do not normally tail-
+   -call, mark it as requiring a tail-call for correctness.  */
+  if (optimize < 2)
+   CALL_EXPR_MUST_TAIL_CALL (resume) = true;
+}
+  pop_cfun ();
   resume = coro_build_cvt_void_expr_stmt (resume, loc);
   add_stmt (resume);
 
@@ -3951,7 +3959,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
 
   push_deferring_access_checks (dk_no_check);
 
-  /* Actor ...  */
+  /* Build the actor...  */
   build_actor_fn (fn_start, coro_frame_type, actor, fnbody, orig, param_uses,
  _var_uses, param_dtor_list, initial_await, final_await,
  body_aw_points.await_number, frame_size);

diff --git 
a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C 
b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
index 864846e365c..6f379c8e77a 100644
--- a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
+++ 

[committed] c++: Add testcase for PR c++/93207

[Patrick Palka via Gcc-patches]

gcc/testsuite/ChangeLog:

PR c++/93207
* g++.dg/concepts/variadic5.C: New test.
---
 gcc/testsuite/g++.dg/concepts/variadic5.C | 26 +++
 1 file changed, 26 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/concepts/variadic5.C

diff --git a/gcc/testsuite/g++.dg/concepts/variadic5.C 
b/gcc/testsuite/g++.dg/concepts/variadic5.C
new file mode 100644
index 000..a871079e5de
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/variadic5.C
@@ -0,0 +1,26 @@
+// PR c++/93207
+// { dg-do compile { target concepts } }
+
+template 
+concept C = true;
+
+struct S
+{
+template 
+void f()
+requires C;
+};
+
+template 
+void S::f()
+requires C
+{
+}
+
+void foo()
+{
+  S s;
+  s.f<>();
+  s.f();
+  s.f();
+}
-- 
2.26.0.106.g9fadedd637

Re: [PATCH] c++: "'decltype_type' not supported" in diagnostic [PR85278]

[Jason Merrill via Gcc-patches]

On 4/14/20 11:46 AM, Patrick Palka wrote:

This fixes a garbled concepts diagnostic by moving the handling of DECLTYPE_TYPE
from pp_cxx_type_specifier_seq to cxx_pretty_printer::simple_type_specifier, a
move which also seems to be more consistent with the language grammar.

This patch also fixes pretty printing of rvalue reference types via
cxx_pretty_printer::type_id, which eventually calls pp_c_pointer which currently
doesn't distinguish between lvalue and rvalue references.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to commit?


OK.


gcc/c-family/ChangeLog:

PR c++/85278
* c-pretty-print.c (pp_c_pointer) : Print a double
ampersand if it's an rvalue reference type.

gcc/cp/ChangeLog:

PR c++/85278
* cxx-pretty-print.c (cxx_pretty_printer:simple_type_specifier)
: Handle DECLTYPE_TYPE here instead of ...
(pp_cxx_type_specifier_seq) : ... here.
(cxx_pretty_printer::direct_abstract_declarator) :
New no-op case.

gcc/testsuite/ChangeLog:

PR c++/85278
* g++.dg/concepts/diagnostic9.C: New test.
---
  gcc/c-family/c-pretty-print.c   |  6 +-
  gcc/cp/cxx-pretty-print.c   | 17 ++---
  gcc/testsuite/g++.dg/concepts/diagnostic9.C | 11 +++
  3 files changed, 26 insertions(+), 8 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic9.C

diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index eccb63096fd..32f30f2d452 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -278,7 +278,11 @@ pp_c_pointer (c_pretty_printer *pp, tree t)
if (TREE_CODE (t) == POINTER_TYPE)
pp_c_star (pp);
else
-   pp_c_ampersand (pp);
+   {
+ pp_c_ampersand (pp);
+ if (TYPE_REF_IS_RVALUE (t))
+   pp_c_ampersand (pp);
+   }
pp_c_type_qualifier_list (pp, t);
break;
  
diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c

index 840b5a8db8b..a26291eee0f 100644
--- a/gcc/cp/cxx-pretty-print.c
+++ b/gcc/cp/cxx-pretty-print.c
@@ -1325,6 +1325,7 @@ cxx_pretty_printer::declaration_specifiers (tree t)
  /* simple-type-specifier:
::(opt) nested-name-specifier(opt) type-name
::(opt) nested-name-specifier(opt) template(opt) template-id
+  decltype-specifier
char
wchar_t
bool
@@ -1363,6 +1364,13 @@ cxx_pretty_printer::simple_type_specifier (tree t)
pp_cxx_unqualified_id (this, TYPENAME_TYPE_FULLNAME (t));
break;
  
+case DECLTYPE_TYPE:

+  pp_cxx_ws_string (this, "decltype");
+  pp_cxx_left_paren (this);
+  this->expression (DECLTYPE_TYPE_EXPR (t));
+  pp_cxx_right_paren (this);
+  break;
+
  default:
c_pretty_printer::simple_type_specifier (t);
break;
@@ -1389,6 +1397,7 @@ pp_cxx_type_specifier_seq (cxx_pretty_printer *pp, tree t)
  case TEMPLATE_TEMPLATE_PARM:
  case TYPE_DECL:
  case BOUND_TEMPLATE_TEMPLATE_PARM:
+case DECLTYPE_TYPE:
pp_cxx_cv_qualifier_seq (pp, t);
pp->simple_type_specifier (t);
break;
@@ -1399,13 +1408,6 @@ pp_cxx_type_specifier_seq (cxx_pretty_printer *pp, tree 
t)
pp_cxx_nested_name_specifier (pp, TYPE_METHOD_BASETYPE (t));
break;
  
-case DECLTYPE_TYPE:

-  pp_cxx_ws_string (pp, "decltype");
-  pp_cxx_left_paren (pp);
-  pp->expression (DECLTYPE_TYPE_EXPR (t));
-  pp_cxx_right_paren (pp);
-  break;
-
  case RECORD_TYPE:
if (TYPE_PTRMEMFUNC_P (t))
{
@@ -1799,6 +1801,7 @@ cxx_pretty_printer::direct_abstract_declarator (tree t)
  case TEMPLATE_TEMPLATE_PARM:
  case BOUND_TEMPLATE_TEMPLATE_PARM:
  case UNBOUND_CLASS_TEMPLATE:
+case DECLTYPE_TYPE:
break;
  
  default:

diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic9.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic9.C
new file mode 100644
index 000..b8f1fadd5e0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic9.C
@@ -0,0 +1,11 @@
+// PR c++/85278
+// { dg-do compile { target concepts } }
+
+template
+void f2(T a)
+  requires requires (const decltype(a) &) { -x; }
+{ }
+
+int main() {
+  f2(nullptr); // { dg-error "use of function .*const decltype\\(f2::a\\) 
*&&" }
+}

Re: [PATCH]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

[Andrea Corallo]

Kyrylo Tkachov  writes:

> -  if (!REG_P (addr.base))
> +  if (addr.type == ADDRESS_SYMBOLIC || !REG_P (addr.base))
>  return false;
>
> Hmm, given that the code below only handles the  ADDRESS_REG_* forms, how 
> about we get defensive here and check that addr.type is not one of 
> ADDRESS_REG_* instead?
> That way, if aarch64_classify_address is extended in the future with new 
> addr.type values that leave addr.base in the wrong forms, this code will not 
> need to be updated.

Yeah make sense.

Thanks

  Andrea

RE: [PATCH]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

[Kyrylo Tkachov]

Hi Andrea,

> -Original Message-
> From: Andrea Corallo 
> Sent: 14 April 2020 11:01
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; nd ;
> Christophe Lyon 
> Subject: [PATCH]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for
> use of uninitialized value
> 
> Hi all,
> 
> Testing the backport of pr94530 fix (af19e4d0e23e) to GCC 9 I realized
> this is not entirely correct.
> 
> aarch64_classify_address sets the base field of struct
> aarch64_address_info for all aarch64_address_type with the exception
> of ADDRESS_SYMBOLIC.  In this case we would access an uninitialized
> value.  The attached patch fixes the issue.
> 
> Bootstraped on aarch64 and regressioned.  Okay for trunk?
> 
> I've also tested af19e4d0e23e + the current patch rebased on on top of
> the gcc-9 branch.  Okay to backport?
> 
> Andrea
> 
> PS I'm wondering if would be good also to always set the addr field in
> aarch64_classify_address for safeness.
> 
> gcc/ChangeLog
> 
> 2020-??-??  Andrea Corallo  
> 
>   * config/aarch64/falkor-tag-collision-avoidance.c
>   (valid_src_p): Check for aarch64_address_info type before
>   accessing base field.

>From 4af5bb32cd88bb4e65591207839fb0e276b2eb23 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Thu, 9 Apr 2020 15:34:50 +0100
Subject: [PATCH] pr94530 2

---
 gcc/config/aarch64/falkor-tag-collision-avoidance.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/aarch64/falkor-tag-collision-avoidance.c 
b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
index f850153fae02..fb56ff66bfab 100644
--- a/gcc/config/aarch64/falkor-tag-collision-avoidance.c
+++ b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
@@ -538,7 +538,7 @@ valid_src_p (rtx src, rtx_insn *insn, struct loop *loop, 
bool *pre_post,
   if (!aarch64_classify_address (, XEXP (x, 0), mode, true))
 return false;
 
-  if (!REG_P (addr.base))
+  if (addr.type == ADDRESS_SYMBOLIC || !REG_P (addr.base))
 return false;
 
Hmm, given that the code below only handles the  ADDRESS_REG_* forms, how about 
we get defensive here and check that addr.type is not one of ADDRESS_REG_* 
instead?
That way, if aarch64_classify_address is extended in the future with new 
addr.type values that leave addr.base in the wrong forms, this code will not 
need to be updated.
Thanks,
Kyrill


   unsigned regno = REGNO (addr.base);
-- 
2.17.1

[PATCH] testsuite: Add check_effective_target_d_runtime_has_std_library procedure

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds an effect target d_runtime_has_std_library to
target-supports.exp, and some preliminary uses of it.

The current check_effective_target_d_runtime procedure returns false if
the target is without any core runtime library for D.  This additional
procedure is for targets where the core runtime library exists, but is
without the higher level standard D library.

OK for master?

Regards
Iain.

---
gcc/testsuite/ChangeLog:

* gdc.dg/link.d: Use d_runtime_has_std_library effective target.
* gdc.dg/runnable.d: Move phobos tests to...
* gdc.dg/runnable2.d: ...here.  New test.
* lib/target-supports.exp
(check_effective_target_d_runtime_has_std_library): New.

libphobos/ChangeLog:

* testsuite/libphobos.phobos/phobos.exp: Skip if effective target is
not d_runtime_has_std_library.
* testsuite/libphobos.phobos_shared/phobos_shared.exp: Likewise.
---
 gcc/testsuite/gdc.dg/link.d   |   2 +-
 gcc/testsuite/gdc.dg/runnable.d   | 229 
 gcc/testsuite/gdc.dg/runnable2.d  | 244 ++
 gcc/testsuite/lib/target-supports.exp |  15 ++
 .../testsuite/libphobos.phobos/phobos.exp |   5 +
 .../libphobos.phobos_shared/phobos_shared.exp |   5 +
 6 files changed, 270 insertions(+), 230 deletions(-)
 create mode 100644 gcc/testsuite/gdc.dg/runnable2.d

diff --git a/gcc/testsuite/gdc.dg/link.d b/gcc/testsuite/gdc.dg/link.d
index a8ca4ed5cb6..5efd0ad347f 100644
--- a/gcc/testsuite/gdc.dg/link.d
+++ b/gcc/testsuite/gdc.dg/link.d
@@ -1,4 +1,4 @@
-// { dg-do link { target d_runtime } }
+// { dg-do link { target d_runtime_has_std_library } }
 
 /**/
 
diff --git a/gcc/testsuite/gdc.dg/runnable.d b/gcc/testsuite/gdc.dg/runnable.d
index 484a9709bf3..7307e09a645 100644
--- a/gcc/testsuite/gdc.dg/runnable.d
+++ b/gcc/testsuite/gdc.dg/runnable.d
@@ -9,20 +9,6 @@ import core.stdc.stdio;
 import gcc.attribute;
 
 
-/**/
-// https://bugzilla.gdcproject.org/show_bug.cgi?id=2
-
-struct S
-{
-string toString() { return "foo"; }
-}
-
-void test2()
-{
-import std.string : format;
-assert(format("%s", S()) == "foo");
-}
-
 /**/
 // https://bugzilla.gdcproject.org/show_bug.cgi?id=4
 
@@ -33,35 +19,6 @@ void test4()
 static assert(!__traits(compiles, str.sort));
 }
 
-/**/
-// https://bugzilla.gdcproject.org/show_bug.cgi?id=15
-
-class B
-{
-class A { }
-A a;
-}
-
-class C
-{
-void visit(B b)
-{
-import std.algorithm : map;
-auto as = [b.a];
-as.map!(d => d);
-}
-}
-
-/**/
-// https://bugzilla.gdcproject.org/show_bug.cgi?id=16
-
-void test16()
-{
-import std.parallelism : taskPool;
-
-taskPool.reduce!"a+b"([0, 1, 2, 3]);
-}
-
 /**/
 // https://bugzilla.gdcproject.org/show_bug.cgi?id=17
 
@@ -99,59 +56,6 @@ void test17()
   (new ModuleWriter()).save ("test.0.mci");
 }
 
-/**/
-// https://bugzilla.gdcproject.org/show_bug.cgi?id=18
-
-class C18
-{
-struct Link
-{
-int x;
-int y;
-}
-
-void sort_links()
-{
-import std.algorithm : sort;
-import std.array : empty;
-import std.exception : enforce;
-
-enforce(!_link.empty);
-
-bool lt(Link a, Link b)
-{
-if(a.x > b.x)
-return false;
-if(a.x < b.x)
-return true;
-if(a.y >= b.y)
-return false;
-else
-return true;
-}
-sort!(lt)(_link);
-}
-
-this()
-{
-_link ~= Link(8, 3);
-_link ~= Link(4, 7);
-_link ~= Link(4, 6);
-_link ~= Link(3, 7);
-_link ~= Link(2, 7);
-_link ~= Link(2, 2);
-_link ~= Link(4, 1);
-}
-
-Link[] _link;
-}
-
-void test18()
-{
-C18 foo = new C18;
-foo.sort_links();
-}
-
 /**/
 // https://bugzilla.gdcproject.org/show_bug.cgi?id=19
 
@@ -177,22 +81,6 @@ void test24()
 return;
 }
 
-/**/
-// https://bugzilla.gdcproject.org/show_bug.cgi?id=29
-
-void test29()
-{
-import std.string : format;
-import std.conv : text;
-
-string s;
-for (auto i = 0; i < 10; i++)
-{
-s = format("%d", i);
-s = text(i);
-}
-}
-
 /**/
 // https://bugzilla.gdcproject.org/show_bug.cgi?id=31
 
@@ -499,54 +387,6 @@ void test51()
 assert (s.x == 0);
 }
 
-/**/
-// https://bugzilla.gdcproject.org/show_bug.cgi?id=52
-
-class C52
-{
-C52 a;
-
-this()
-{
-printf("Construct: this=%p\n", cast(void*)this);
-a 

[PATCH] c++: "'decltype_type' not supported" in diagnostic [PR85278]

[Patrick Palka via Gcc-patches]

This fixes a garbled concepts diagnostic by moving the handling of DECLTYPE_TYPE
from pp_cxx_type_specifier_seq to cxx_pretty_printer::simple_type_specifier, a
move which also seems to be more consistent with the language grammar.

This patch also fixes pretty printing of rvalue reference types via
cxx_pretty_printer::type_id, which eventually calls pp_c_pointer which currently
doesn't distinguish between lvalue and rvalue references.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to commit?

gcc/c-family/ChangeLog:

PR c++/85278
* c-pretty-print.c (pp_c_pointer) : Print a double
ampersand if it's an rvalue reference type.

gcc/cp/ChangeLog:

PR c++/85278
* cxx-pretty-print.c (cxx_pretty_printer:simple_type_specifier)
: Handle DECLTYPE_TYPE here instead of ...
(pp_cxx_type_specifier_seq) : ... here.
(cxx_pretty_printer::direct_abstract_declarator) :
New no-op case.

gcc/testsuite/ChangeLog:

PR c++/85278
* g++.dg/concepts/diagnostic9.C: New test.
---
 gcc/c-family/c-pretty-print.c   |  6 +-
 gcc/cp/cxx-pretty-print.c   | 17 ++---
 gcc/testsuite/g++.dg/concepts/diagnostic9.C | 11 +++
 3 files changed, 26 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic9.C

diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index eccb63096fd..32f30f2d452 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -278,7 +278,11 @@ pp_c_pointer (c_pretty_printer *pp, tree t)
   if (TREE_CODE (t) == POINTER_TYPE)
pp_c_star (pp);
   else
-   pp_c_ampersand (pp);
+   {
+ pp_c_ampersand (pp);
+ if (TYPE_REF_IS_RVALUE (t))
+   pp_c_ampersand (pp);
+   }
   pp_c_type_qualifier_list (pp, t);
   break;
 
diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index 840b5a8db8b..a26291eee0f 100644
--- a/gcc/cp/cxx-pretty-print.c
+++ b/gcc/cp/cxx-pretty-print.c
@@ -1325,6 +1325,7 @@ cxx_pretty_printer::declaration_specifiers (tree t)
 /* simple-type-specifier:
   ::(opt) nested-name-specifier(opt) type-name
   ::(opt) nested-name-specifier(opt) template(opt) template-id
+  decltype-specifier
   char
   wchar_t
   bool
@@ -1363,6 +1364,13 @@ cxx_pretty_printer::simple_type_specifier (tree t)
   pp_cxx_unqualified_id (this, TYPENAME_TYPE_FULLNAME (t));
   break;
 
+case DECLTYPE_TYPE:
+  pp_cxx_ws_string (this, "decltype");
+  pp_cxx_left_paren (this);
+  this->expression (DECLTYPE_TYPE_EXPR (t));
+  pp_cxx_right_paren (this);
+  break;
+
 default:
   c_pretty_printer::simple_type_specifier (t);
   break;
@@ -1389,6 +1397,7 @@ pp_cxx_type_specifier_seq (cxx_pretty_printer *pp, tree t)
 case TEMPLATE_TEMPLATE_PARM:
 case TYPE_DECL:
 case BOUND_TEMPLATE_TEMPLATE_PARM:
+case DECLTYPE_TYPE:
   pp_cxx_cv_qualifier_seq (pp, t);
   pp->simple_type_specifier (t);
   break;
@@ -1399,13 +1408,6 @@ pp_cxx_type_specifier_seq (cxx_pretty_printer *pp, tree 
t)
   pp_cxx_nested_name_specifier (pp, TYPE_METHOD_BASETYPE (t));
   break;
 
-case DECLTYPE_TYPE:
-  pp_cxx_ws_string (pp, "decltype");
-  pp_cxx_left_paren (pp);
-  pp->expression (DECLTYPE_TYPE_EXPR (t));
-  pp_cxx_right_paren (pp);
-  break;
-
 case RECORD_TYPE:
   if (TYPE_PTRMEMFUNC_P (t))
{
@@ -1799,6 +1801,7 @@ cxx_pretty_printer::direct_abstract_declarator (tree t)
 case TEMPLATE_TEMPLATE_PARM:
 case BOUND_TEMPLATE_TEMPLATE_PARM:
 case UNBOUND_CLASS_TEMPLATE:
+case DECLTYPE_TYPE:
   break;
 
 default:
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic9.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic9.C
new file mode 100644
index 000..b8f1fadd5e0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic9.C
@@ -0,0 +1,11 @@
+// PR c++/85278
+// { dg-do compile { target concepts } }
+
+template
+void f2(T a)
+  requires requires (const decltype(a) &) { -x; }
+{ }
+
+int main() {
+  f2(nullptr); // { dg-error "use of function .*const 
decltype\\(f2::a\\) *&&" }
+}
-- 
2.26.0.106.g9fadedd637

Re: [PR C++ 94426] Lambda linkage

[Iain Sandoe via Gcc-patches]

Hi Nathan,

Nathan Sidwell  wrote:

> My fix for 94147 was confusing no-linkage with internal linkage, at the 
> language level.  That's wrong. (the std is confusing here, because it 
> describes linkage of names (which is wrong), and lambdas have no names)
> 
> Lambdas with extra-scope, have linkage.  However, at the implementation-level 
> that linkage is at least as restricted as the linkage of the extra-scope decl.
> 
> Further, when instantiating a variable initialized by a lambda, we must 
> determine the visibility of the variable itself, before instantiating its 
> initializer.  If the template arguments are internal (or no-linkage), the 
> variable will have internal linkage, regardless of the linkage of the 
> template it is instantiated from.  We need to know that before instantiating 
> the lambda, so we can restrict its linkage correctly.
> 
> I'll commit this in a few days.

As discussed on irc,

The testcase for this fails on Darwin, where we don’t use .local or .comm for 
the var.

I’ve tested this on x86-64-linux and darwin, 
but I plan on testing on a few more Darwin boxen,
OK to apply, if additional testing passes?

thanks
Iain

gcc/testsuite/ChangeLog:

2020-04-14  Iain Sandoe  

* g++.dg/cpp0x/lambda/pr94426-2.C: Add tests for Darwin’s codegen.

iff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/pr94426-2.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/pr94426-2.C
index 3db864c604b..fc85400388a 100644
--- a/gcc/testsuite/g++.dg/cpp0x/lambda/pr94426-2.C
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/pr94426-2.C
@@ -16,5 +16,10 @@ void q ()
 }
 
 // The instantiation of VAR becomes local
-// { dg-final { scan-assembler {.local _Z3VARIZ1qvEUlvE_E} { target { i?86-*-* 
x86_64-*-* } } } }
-// { dg-final { scan-assembler {.comm  _Z3VARIZ1qvEUlvE_E,1,1} { target { 
i?86-*-* x86_64-*-* } } } }
+// { dg-final { scan-assembler {.local _Z3VARIZ1qvEUlvE_E} { target { { 
i?86-*-* x86_64-*-* } && { ! *-*-darwin* } } } } }
+// { dg-final { scan-assembler {.comm  _Z3VARIZ1qvEUlvE_E,1,1} { target { { 
i?86-*-* x86_64-*-* } && { ! *-*-darwin* } } } } }
+
+// Darwin's assembler does not use .local (linker-visible symbols which are
+// not global are counted as local).
+// { dg-final { scan-assembler-not {.globl[ \t]+__Z3VARIZ1qvEUlvE_E} { target 
*-*-darwin* } } }
+// { dg-final { scan-assembler {.static_data[ \n\t]+__Z3VARIZ1qvEUlvE_E} { 
target *-*-darwin* } } }

Re: [PATCH] RTEMS: Improve GCC specification

[Sebastian Huber]

Hello Jeff,

On 08/04/2020 22:24, Jeff Law wrote:


On Wed, 2020-04-08 at 19:47 +0200, Sebastian Huber wrote:

Add a start/end file specification if the -qrtems option is present.
Allow targets to customize it.

Support the standard -nodefaultlibs option.

gcc/

* config/rtems.h (RTEMS_STARTFILE_SPEC): Define if undefined.
(RTEMS_ENDFILE_SPEC): Likewise.
(STARTFILE_SPEC): Update comment.  Add RTEMS_STARTFILE_SPEC.
(ENDFILE_SPEC): Add RTEMS_ENDFILE_SPEC.
(LIB_SPECS): Support -nodefaultlibs option.
* config/or1k/rtems.h (RTEMS_STARTFILE_SPEC): Define.
(RTEMS_ENDFILE_SPEC): Likewise.
* config/rs6000/rtems.h (RTEMS_STARTFILE_SPEC): Likewise.
(RTEMS_ENDFILE_SPEC): Likewise.
* config/v850/rtems.h (RTEMS_STARTFILE_SPEC): Likewise.
(RTEMS_ENDFILE_SPEC): Likewise.

How important is it to get this into gcc-10?  We're well into stage4 at this
point and while we do have leeway with a patch like this we do want to be
selective about what we accept.

If it's important, then OK, otherwise please defer it to gcc-11, where it's pre-
approved.
would it be all right to commit it to the trunk once the GCC 11 
development starts and then back port it for GCC 10.2 after a while?

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

[Jan Hubicka]

> 
> But we're using it in indirect_ref_may_alias_decl_p as
> 
>   /* If second reference is view-converted, give up now.  */
>   if (same_type_for_tbaa (TREE_TYPE (dbase2), TREE_TYPE (ptrtype2)) != 
> 1)
> return true;
> 
> and clearly if TREE_TYPE (ptrtype2) is void * while TREE_TYPE (dbase2)
> is T * we've "view-converted" things.
> 
> Not sure what the consequence is when we fall through here since those
> checks may be redundant now(?)  But given we're late for GCC 10 I'd
> rather be safe than sorry ;)

I think this check is about part of access path missing (i.e. we have
access path like a.b.c.d.e.f while mem-ref took part of it away
so we have a.b.c...f).
So here c and f should not be both pointers.
> 
> > For ICF checking we need to be more careful anyway (in particular we do
> > not want all those -1s on arrays), so I would worry about that next
> > stage1.
> > 
> > With 1 we will probably save some work since the code will not continue
> > looking for must aliases.
> 
> I think we have still quite some cleanup to do for the path-based
> disambiguations.

Yep, one issue at a time

Honza
> 
> Richard.
> 
> > Honza
> > 
> > > 
> > > So, like the following.
> > > 
> > > Richard.
> > > 
> > > 
> > > middle-end/94539 - void * aliases every other pointer
> > > 
> > > This makes same_type_for_tbaa_p conservative in the same way
> > > get_alias_set is about void * which we allow to alias all other
> > > pointers.
> > > 
> > > 2020-04-14  Richard Biener  
> > > 
> > >   PR middle-end/94539
> > >   * tree-ssa-alias.c (same_type_for_tbaa): Defer to
> > >   alias_sets_conflict_p for pointers.
> > > 
> > >   * gcc.dg/alias-14.c: Make dg-do run.
> > > ---
> > >  gcc/testsuite/gcc.dg/alias-14.c |  2 +-
> > >  gcc/tree-ssa-alias.c| 11 ++-
> > >  2 files changed, 11 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/gcc/testsuite/gcc.dg/alias-14.c 
> > > b/gcc/testsuite/gcc.dg/alias-14.c
> > > index 1ca1c09d5e3..24f0d1c1168 100644
> > > --- a/gcc/testsuite/gcc.dg/alias-14.c
> > > +++ b/gcc/testsuite/gcc.dg/alias-14.c
> > > @@ -1,4 +1,4 @@
> > > -/* { dg-do compile } */
> > > +/* { dg-do run } */
> > >  /* { dg-options "-O2" } */
> > >  #include 
> > >  void *a;
> > > diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> > > index df9ba0de0d6..ede4f198342 100644
> > > --- a/gcc/tree-ssa-alias.c
> > > +++ b/gcc/tree-ssa-alias.c
> > > @@ -839,7 +839,16 @@ same_type_for_tbaa (tree type1, tree type2)
> > >   would mean that conversions between them are useless, whereas they 
> > > are
> > >   not (e.g. type and subtypes can have different modes).  So, in the 
> > > end,
> > >   they are only guaranteed to have the same alias set.  */
> > > -  if (get_alias_set (type1) == get_alias_set (type2))
> > > +  alias_set_type set1 = get_alias_set (type1);
> > > +  alias_set_type set2 = get_alias_set (type2);
> > > +  if (set1 == set2)
> > > +return -1;
> > > +
> > > +  /* Pointers to void are considered compatible with all other pointers,
> > > + so for two pointers see what the alias set resolution thinks.  */
> > > +  if (POINTER_TYPE_P (type1)
> > > +  && POINTER_TYPE_P (type2)
> > > +  && alias_sets_conflict_p (set1, set2))
> > >  return -1;
> > >  
> > >/* The types are known to be not equal.  */
> > > -- 
> > > 2.13.7
> > > 
> > 
> 
> -- 
> Richard Biener 
> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] wwwdocs: Slightly improve IPA-SRA description in gcc-10/changes.html

[Gerald Pfeifer]

On Tue, 14 Apr 2020, Martin Jambor wrote:
> I think that the fact that IPA-SRA can now remove unused return
> values deserves a special mention - and I also fixed the proposition
> in the name of the pass.
> 
> OK for wwwdocs?

Yes, thank you.  A small recommendation:

> +  The inter-procedural scalar replacement of aggregates (IPA-SRA) 
> pass
> +   was re-implemented to work at link-time and can now also remove
> +   calculating and passing unused return values.

Here I'd use "computing" instead of "calculating".

The meanings of those two words overlap, and in the sense of formal
logics everything could be seen as a calculation.  In the more common
term 

  x = 47*(y+1)

would be more of a calculation whereas

  if (y > 47) x = y; else x = f(y);

more of a computation.

Gerald

Re: [PATCH] wwwdocs: Deprecate offloading to HSAIL

[Gerald Pfeifer]

On Tue, 14 Apr 2020, Martin Jambor wrote:
> for reasons described in my earlier email, I'd like to commit the
> following to gcc-10/changes.html to mark offloading to HSAIL as
> deprecated.
> 
> OK?

Yes, thank you.

Though given what I saw/understand, you could write "...will likely
be removed in GCC 11" (instead of "a future release").

Gerald

Re: [PATCH] wwwdocs: Slightly improve IPA-SRA description in gcc-10/changes.html

[Richard Biener via Gcc-patches]

On Tue, Apr 14, 2020 at 4:19 PM Martin Jambor  wrote:
>
> Hi,
>
> I think that the fact that IPA-SRA can now remove unused return
> values deserves a special mention - and I also fixed the proposition
> in the name of the pass.
>
> OK for wwwdocs?
>
> Thanks,
>
> Martin
>
>
> ---
>  htdocs/gcc-10/changes.html | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index 17679812..1e3aca18 100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -103,8 +103,9 @@ a work-in-progress.
>
>  Inter-procedural optimization improvements:
>  
> -  The inter-procedural scalar replacement for aggregates (IPA-SRA) 
> pass
> - was re-implemented to work at link-time.
> +  The inter-procedural scalar replacement of aggregates (IPA-SRA) 
> pass
> + was re-implemented to work at link-time and can now also remove
> + calculating and passing unused return values.

and returning

OK with that change.

>
> href="https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Optimize-Options.html#index-finline-functions;>-finline-functions
>   is now enabled at -O2 and was retuned for better code
> --
> 2.26.0
>

Re: [PATCH] wwwdocs: Deprecate offloading to HSAIL

[Richard Biener via Gcc-patches]

On Tue, Apr 14, 2020 at 4:17 PM Martin Jambor  wrote:
>
> Hi,
>
> for reasons described in my earlier email, I'd like to commit the
> following to gcc-10/changes.html to mark offloading to HSAIL as
> deprecated.
>
> OK?

OK.

Richard.

> Thanks,
>
> Martin
>
>
> ---
>  htdocs/gcc-10/changes.html | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index ca49e626..17679812 100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -57,6 +57,11 @@ a work-in-progress.
>  of the default via --param allow-store-data-races will
>  now be diagnosed and build systems have to be adjusted accordingly.
>
> +  
> +Offloading to Heterogeneous System Architecture Intermediate
> +Language (HSAIL) has been deprecated and will likely be removed in
> +a future release.
> +  
>  
>
>
> --
> 2.26.0
>

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

[Richard Biener]

On Tue, 14 Apr 2020, Jan Hubicka wrote:

> > 
> > Note that now, looking again, the TYPE_STRUCTURAL_EQUALITY_P in my patch
> > doesn't match that of get_alias_set.  Since we're looking at the alias
> > sets of type1 and type2 anyway we could resort to alias_sets_conflict_p
> > for the two POINTER_TYPE_P case and return -1 then.  Not sure about
> > returning 1 - they are not the same as in, one cannot replace a
> > *(void *) access with a *(T *) access since the latter behaves differently
> > wrt a *(U *) access not visible to the call.
> > 
> > But the semantics of same_type_for_tbaa are not entirely clear
> > (ISTR you suggested to use it for ICF-like compares).
> 
> I think it is clear.
> 
> 0 means that accesspath ending by one type can not continue by access path 
> starting by the other type.
> 1 means that they can continue.
> -1 means that we do not know (or are too lazy to decide).
> 
> In this partiuclar case we have the continuation path trivial and we
> only want to check if one continues the other, so 1 should work.

But we're using it in indirect_ref_may_alias_decl_p as

  /* If second reference is view-converted, give up now.  */
  if (same_type_for_tbaa (TREE_TYPE (dbase2), TREE_TYPE (ptrtype2)) != 
1)
return true;

and clearly if TREE_TYPE (ptrtype2) is void * while TREE_TYPE (dbase2)
is T * we've "view-converted" things.

Not sure what the consequence is when we fall through here since those
checks may be redundant now(?)  But given we're late for GCC 10 I'd
rather be safe than sorry ;)

> For ICF checking we need to be more careful anyway (in particular we do
> not want all those -1s on arrays), so I would worry about that next
> stage1.
> 
> With 1 we will probably save some work since the code will not continue
> looking for must aliases.

I think we have still quite some cleanup to do for the path-based
disambiguations.

Richard.

> Honza
> 
> > 
> > So, like the following.
> > 
> > Richard.
> > 
> > 
> > middle-end/94539 - void * aliases every other pointer
> > 
> > This makes same_type_for_tbaa_p conservative in the same way
> > get_alias_set is about void * which we allow to alias all other
> > pointers.
> > 
> > 2020-04-14  Richard Biener  
> > 
> > PR middle-end/94539
> > * tree-ssa-alias.c (same_type_for_tbaa): Defer to
> > alias_sets_conflict_p for pointers.
> > 
> > * gcc.dg/alias-14.c: Make dg-do run.
> > ---
> >  gcc/testsuite/gcc.dg/alias-14.c |  2 +-
> >  gcc/tree-ssa-alias.c| 11 ++-
> >  2 files changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/gcc/testsuite/gcc.dg/alias-14.c 
> > b/gcc/testsuite/gcc.dg/alias-14.c
> > index 1ca1c09d5e3..24f0d1c1168 100644
> > --- a/gcc/testsuite/gcc.dg/alias-14.c
> > +++ b/gcc/testsuite/gcc.dg/alias-14.c
> > @@ -1,4 +1,4 @@
> > -/* { dg-do compile } */
> > +/* { dg-do run } */
> >  /* { dg-options "-O2" } */
> >  #include 
> >  void *a;
> > diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> > index df9ba0de0d6..ede4f198342 100644
> > --- a/gcc/tree-ssa-alias.c
> > +++ b/gcc/tree-ssa-alias.c
> > @@ -839,7 +839,16 @@ same_type_for_tbaa (tree type1, tree type2)
> >   would mean that conversions between them are useless, whereas they are
> >   not (e.g. type and subtypes can have different modes).  So, in the 
> > end,
> >   they are only guaranteed to have the same alias set.  */
> > -  if (get_alias_set (type1) == get_alias_set (type2))
> > +  alias_set_type set1 = get_alias_set (type1);
> > +  alias_set_type set2 = get_alias_set (type2);
> > +  if (set1 == set2)
> > +return -1;
> > +
> > +  /* Pointers to void are considered compatible with all other pointers,
> > + so for two pointers see what the alias set resolution thinks.  */
> > +  if (POINTER_TYPE_P (type1)
> > +  && POINTER_TYPE_P (type2)
> > +  && alias_sets_conflict_p (set1, set2))
> >  return -1;
> >  
> >/* The types are known to be not equal.  */
> > -- 
> > 2.13.7
> > 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

[PATCH] wwwdocs: Deprecate offloading to HSAIL

[Martin Jambor]

Hi,

for reasons described in my earlier email, I'd like to commit the
following to gcc-10/changes.html to mark offloading to HSAIL as
deprecated.

OK?

Thanks,

Martin


---
 htdocs/gcc-10/changes.html | 5 +
 1 file changed, 5 insertions(+)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index ca49e626..17679812 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -57,6 +57,11 @@ a work-in-progress.
 of the default via --param allow-store-data-races will
 now be diagnosed and build systems have to be adjusted accordingly.
   
+  
+Offloading to Heterogeneous System Architecture Intermediate
+Language (HSAIL) has been deprecated and will likely be removed in
+a future release.
+  
 
 
 
-- 
2.26.0

[PATCH] wwwdocs: Slightly improve IPA-SRA description in gcc-10/changes.html

[Martin Jambor]

Hi,

I think that the fact that IPA-SRA can now remove unused return
values deserves a special mention - and I also fixed the proposition
in the name of the pass.

OK for wwwdocs?

Thanks,

Martin


---
 htdocs/gcc-10/changes.html | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 17679812..1e3aca18 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -103,8 +103,9 @@ a work-in-progress.
   
 Inter-procedural optimization improvements:
 
-  The inter-procedural scalar replacement for aggregates (IPA-SRA) pass
- was re-implemented to work at link-time.
+  The inter-procedural scalar replacement of aggregates (IPA-SRA) pass
+ was re-implemented to work at link-time and can now also remove
+ calculating and passing unused return values.
   
   https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Optimize-Options.html#index-finline-functions;>-finline-functions
  is now enabled at -O2 and was retuned for better code
-- 
2.26.0

[committed] testsuite: Add testcase for already fixed PR [PR94573]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase is optimized since Eric's r10-3575 change.

Tested on x86_64-linux -m32/-m64 (and in 9 where it FAILs), committed to
trunk as obvious.

2020-04-14  Jakub Jelinek  

PR tree-optimization/94573
* gcc.dg/store_merging_30.c: New test.

--- gcc/testsuite/gcc.dg/store_merging_30.c.jj  2020-04-14 15:51:59.749645994 
+0200
+++ gcc/testsuite/gcc.dg/store_merging_30.c 2020-04-14 15:53:57.222908241 
+0200
@@ -0,0 +1,20 @@
+/* PR tree-optimization/94573 */
+/* { dg-do compile } */
+/* { dg-require-effective-target store_merge } */
+/* { dg-options "-O2 -fdump-tree-store-merging-details" } */
+/* { dg-final { scan-tree-dump "New sequence of 4 stores to replace old one of 
8 stores" "store-merging" { target lp64 } } } */
+
+int var[43][12];
+
+void
+foo (int x)
+{
+  var[x][0] = 0;
+  var[x][1] = 0;
+  var[x][2] = 0;
+  var[x][3] = 0;
+  var[x][4] = 0;
+  var[x][5] = 0;
+  var[x][6] = 0;
+  var[x][7] = 0;
+}

Jakub

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Rainer Orth]

Hi Iain,

> Rainer Orth  wrote:
>>>
>>> On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote:
 Unfortunately, several targets have ABI constraints that prevent
 an indirect tail-call, which results in the PRs compile error.
>
> So .. after scanning the current published testsuite results I have:
>
> // See PR94359 - some targets are unable to make general indirect tailcalls
> // for example, between different DSOs.
> // { dg-xfail-run-if "" { hppa*-*-hpux11* } }
> // { dg-xfail-run-if "" { ia64-*-linux-gnu } }
> // { dg-xfail-run-if "" { { lp64 && { powerpc*-linux-gnu } } || { *-*-aix*
> } } }
> // { dg-xfail-run-if "" { sparc-*-solaris2* } }

this is wrong: for one, it needs to allow for 64-bit-default SPARC
configurations (i.e. sparcv9-*-* and sparc64-*-*), and AFAICS there's
nothing Solaris-specific here.  So this should be sparc*-*-* instead.

> I’d say it would be a reasonable idea to get this in sooner rather than
> later, we
> can always increase the list (or a target maintainer can trivially add
> their target)

Fine with me.  If the list gets much longer or the conditions more
complex, it might still be worthwhile to use an effective-target keyword
instead.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

[Jan Hubicka]

> 
> Note that now, looking again, the TYPE_STRUCTURAL_EQUALITY_P in my patch
> doesn't match that of get_alias_set.  Since we're looking at the alias
> sets of type1 and type2 anyway we could resort to alias_sets_conflict_p
> for the two POINTER_TYPE_P case and return -1 then.  Not sure about
> returning 1 - they are not the same as in, one cannot replace a
> *(void *) access with a *(T *) access since the latter behaves differently
> wrt a *(U *) access not visible to the call.
> 
> But the semantics of same_type_for_tbaa are not entirely clear
> (ISTR you suggested to use it for ICF-like compares).

I think it is clear.

0 means that accesspath ending by one type can not continue by access path 
starting by the other type.
1 means that they can continue.
-1 means that we do not know (or are too lazy to decide).

In this partiuclar case we have the continuation path trivial and we
only want to check if one continues the other, so 1 should work.

For ICF checking we need to be more careful anyway (in particular we do
not want all those -1s on arrays), so I would worry about that next
stage1.

With 1 we will probably save some work since the code will not continue
looking for must aliases.

Honza

> 
> So, like the following.
> 
> Richard.
> 
> 
> middle-end/94539 - void * aliases every other pointer
> 
> This makes same_type_for_tbaa_p conservative in the same way
> get_alias_set is about void * which we allow to alias all other
> pointers.
> 
> 2020-04-14  Richard Biener  
> 
>   PR middle-end/94539
>   * tree-ssa-alias.c (same_type_for_tbaa): Defer to
>   alias_sets_conflict_p for pointers.
> 
>   * gcc.dg/alias-14.c: Make dg-do run.
> ---
>  gcc/testsuite/gcc.dg/alias-14.c |  2 +-
>  gcc/tree-ssa-alias.c| 11 ++-
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.dg/alias-14.c b/gcc/testsuite/gcc.dg/alias-14.c
> index 1ca1c09d5e3..24f0d1c1168 100644
> --- a/gcc/testsuite/gcc.dg/alias-14.c
> +++ b/gcc/testsuite/gcc.dg/alias-14.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile } */
> +/* { dg-do run } */
>  /* { dg-options "-O2" } */
>  #include 
>  void *a;
> diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> index df9ba0de0d6..ede4f198342 100644
> --- a/gcc/tree-ssa-alias.c
> +++ b/gcc/tree-ssa-alias.c
> @@ -839,7 +839,16 @@ same_type_for_tbaa (tree type1, tree type2)
>   would mean that conversions between them are useless, whereas they are
>   not (e.g. type and subtypes can have different modes).  So, in the end,
>   they are only guaranteed to have the same alias set.  */
> -  if (get_alias_set (type1) == get_alias_set (type2))
> +  alias_set_type set1 = get_alias_set (type1);
> +  alias_set_type set2 = get_alias_set (type2);
> +  if (set1 == set2)
> +return -1;
> +
> +  /* Pointers to void are considered compatible with all other pointers,
> + so for two pointers see what the alias set resolution thinks.  */
> +  if (POINTER_TYPE_P (type1)
> +  && POINTER_TYPE_P (type2)
> +  && alias_sets_conflict_p (set1, set2))
>  return -1;
>  
>/* The types are known to be not equal.  */
> -- 
> 2.13.7
> 

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Iain Sandoe]

Hi Rainer,

Rainer Orth  wrote:


On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote:

Unfortunately, several targets have ABI constraints that prevent
an indirect tail-call, which results in the PRs compile error.


So .. after scanning the current published testsuite results I have:

// See PR94359 - some targets are unable to make general indirect tailcalls
// for example, between different DSOs.
// { dg-xfail-run-if "" { hppa*-*-hpux11* } }
// { dg-xfail-run-if "" { ia64-*-linux-gnu } }
// { dg-xfail-run-if "" { { lp64 && { powerpc*-linux-gnu } } || { *-*-aix*  
} } }

// { dg-xfail-run-if "" { sparc-*-solaris2* } }

* I don’t see the armv8l- fail in the results.
* hppa-linux seems OK.
* I’m avoiding writing powerpc and rs6000 aix, since I expect the result to  
be

the same for both.

I’d say it would be a reasonable idea to get this in sooner rather than  
later, we
can always increase the list (or a target maintainer can trivially add  
their target)


happy to test on the platforms I have access to if this seems a reasonable  
start

thanks
Iain

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Patrick Palka via Gcc-patches]

On Tue, 14 Apr 2020, Jason Merrill wrote:

> On 4/14/20 9:01 AM, Patrick Palka wrote:
> > On Tue, 14 Apr 2020, Patrick Palka wrote:
> > 
> > > On Mon, 13 Apr 2020, Jason Merrill wrote:
> > > 
> > > > On 4/13/20 2:49 PM, Patrick Palka wrote:
> > > > > On Mon, 13 Apr 2020, Jason Merrill wrote:
> > > > > 
> > > > > > On 4/12/20 9:43 AM, Patrick Palka wrote:
> > > > > > > On Sat, 11 Apr 2020, Jason Merrill wrote:
> > > > > > > 
> > > > > > > > On 4/10/20 5:47 PM, Patrick Palka wrote:
> > > > > > > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > > > > > > On 4/10/20 2:15 PM, Patrick Palka wrote:
> > > > > > > > > > > On Fri, 10 Apr 2020, Patrick Palka wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > On 4/10/20 1:04 PM, Patrick Palka wrote:
> > > > > > > > > > > > > > On Thu, 9 Apr 2020, Patrick Palka wrote:
> > > > > > > > > > > > > > > On Thu, 9 Apr 2020, Jason Merrill wrote:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > On 4/8/20 7:49 PM, Patrick Palka wrote:
> > > > > > > > > > > > > > > > > When evaluating the initializer of 'a' in the
> > > > > > > > > > > > > > > > > following
> > > > > > > > > > > > > > > > > example
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > >  struct A { A *p = this; };
> > > > > > > > > > > > > > > > >  constexpr A foo() { return {}; }
> > > > > > > > > > > > > > > > >  constexpr A a = foo();
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > the PLACEHOLDER_EXPR for 'this' in the
> > > > > > > > > > > > > > > > > aggregate
> > > > > > > > > > > > > > > > > initializer
> > > > > > > > > > > > > > > > > returned
> > > > > > > > > > > > > > > > > by foo
> > > > > > > > > > > > > > > > > gets resolved to the RESULT_DECL of foo.  But
> > > > > > > > > > > > > > > > > due to
> > > > > > > > > > > > > > > > > guaranteed
> > > > > > > > > > > > > > > > > RVO,
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > 'this'
> > > > > > > > > > > > > > > > > should really be resolved to ''.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > It seems to me that the right approach would
> > > > > > > > > > > > > > > > > be to
> > > > > > > > > > > > > > > > > immediately
> > > > > > > > > > > > > > > > > resolve
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > PLACEHOLDER_EXPR to the correct target object
> > > > > > > > > > > > > > > > > during
> > > > > > > > > > > > > > > > > evaluation
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > 'foo()',
> > > > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > > > that we could use 'this' to access objects
> > > > > > > > > > > > > > > > > adjacent
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > > > object in
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > ultimate storage location.  (I think #c2 of PR
> > > > > > > > > > > > > > > > > c++/94537
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > > > example
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > such
> > > > > > > > > > > > > > > > > usage of 'this', which currently doesn't work.
> > > > > > > > > > > > > > > > > But
> > > > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > #c1
> > > > > > > > > > > > > > > > > shows
> > > > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > > seem
> > > > > > > > > > > > > > > > > to handle this case correctly in non-constexpr
> > > > > > > > > > > > > > > > > initialization
> > > > > > > > > > > > > > > > > either.)
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > As I commented in the PR, the standard doesn't
> > > > > > > > > > > > > > > > require
> > > > > > > > > > > > > > > > this to
> > > > > > > > > > > > > > > > work
> > > > > > > > > > > > > > > > because A
> > > > > > > > > > > > > > > > is trivially copyable, and our ABI makes it
> > > > > > > > > > > > > > > > impossible.
> > > > > > > > > > > > > > > > But
> > > > > > > > > > > > > > > > there's
> > > > > > > > > > > > > > > > still a
> > > > > > > > > > > > > > > > constexpr bug when we add
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > A() = default; A(const A&);
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > clang doesn't require the constructors to make
> > > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > > work
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > constant
> > > > > > > > > > > > > > > > initialization, but similarly can't make it work
> > > > > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > non-constant
> > > > > > > > > > > > > > > > initialization.
> > > > 

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Jason Merrill via Gcc-patches]

On 4/14/20 9:01 AM, Patrick Palka wrote:

On Tue, 14 Apr 2020, Patrick Palka wrote:


On Mon, 13 Apr 2020, Jason Merrill wrote:


On 4/13/20 2:49 PM, Patrick Palka wrote:

On Mon, 13 Apr 2020, Jason Merrill wrote:


On 4/12/20 9:43 AM, Patrick Palka wrote:

On Sat, 11 Apr 2020, Jason Merrill wrote:


On 4/10/20 5:47 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Jason Merrill wrote:

On 4/10/20 2:15 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Patrick Palka wrote:


On Fri, 10 Apr 2020, Jason Merrill wrote:


On 4/10/20 1:04 PM, Patrick Palka wrote:

On Thu, 9 Apr 2020, Patrick Palka wrote:

On Thu, 9 Apr 2020, Jason Merrill wrote:


On 4/8/20 7:49 PM, Patrick Palka wrote:

When evaluating the initializer of 'a' in the
following
example

 struct A { A *p = this; };
 constexpr A foo() { return {}; }
 constexpr A a = foo();

the PLACEHOLDER_EXPR for 'this' in the aggregate
initializer
returned
by foo
gets resolved to the RESULT_DECL of foo.  But due to
guaranteed
RVO,
the
'this'
should really be resolved to ''.



It seems to me that the right approach would be to
immediately
resolve
the
PLACEHOLDER_EXPR to the correct target object during
evaluation
of
'foo()',
so
that we could use 'this' to access objects adjacent
to
the
current
object in
the
ultimate storage location.  (I think #c2 of PR
c++/94537
is
an
example
of
such
usage of 'this', which currently doesn't work.  But
as
#c1
shows
we
don't
seem
to handle this case correctly in non-constexpr
initialization
either.)


As I commented in the PR, the standard doesn't require
this to
work
because A
is trivially copyable, and our ABI makes it
impossible.
But
there's
still a
constexpr bug when we add

A() = default; A(const A&);

clang doesn't require the constructors to make this
work
for
constant
initialization, but similarly can't make it work for
non-constant
initialization.


That makes a lot of sense, thanks for the detailed
explanation.




I haven't yet been able to make a solution using the
above
approach
work --
making sure we use the ultimate object instead of
the
RESULT_DECL
whenever
we
access ctx->global->values is proving to be tricky
and
subtle.


Do we need to go through ctx->global->values?  Would
it
work
for
the
RESULT_DECL case in cxx_eval_constant_expression to go
to
straight
to
ctx->object or ctx->ctor instead?


I attempted that at some point, but IIRC we still end up
not
resolving
some RESULT_DECLs because not all of them get processed
through
cxx_eval_constant_expression before we manipulate
ctx->global->values
with them.  I'll try this approach more carefully and
report
back
with
more specifics.


It turns out that immediately resolving
RESULT_DECLs/'this' to
the
ultimate ctx->object would not interact well with
constexpr_call
caching:

struct A { A() = default; A(const A&); A *ap =
this; };
constexpr A foo() { return {}; }
constexpr A a = foo();
constexpr A b = foo();
static_assert(b.ap == ); // fails

Evaluation of the first call to foo() returns {}, since
we
resolve
'this' to  due to guaranteed RVO, and we cache this
result.
Evaluation of the second call to foo() just returns the
cached
result
from the constexpr_call cache, and so we get {} again.

So it seems we would have to mark the result of a
constexpr
call
as
not
cacheable whenever this RVO applies during its evaluation,
even
when
doing the RVO has no observable difference in the final
result
(i.e.
the
constructor does not try to save the 'this' pointer).

Would the performance impact of disabling caching whenever
RVO
applies
during constexpr call evaluation be worth it, or should we
go
with
something like my first patch which "almost works," and
which
marks a
constexpr call as not cacheable only when we replace a
RESULT_DECL
in
the result of the call?


Could we search through the result of the call for
ctx->object
and
cache
if we
don't find it?


Hmm, I think the result of the call could still depend on
ctx->object
without ctx->object explicitly appearing in the result.
Consider
the
following testcase:

   struct A {
 A() = default; A(const A&);
 constexpr A(const A *q) : d{this - p} { }


Oops sorry, that 'q' should be a 'p'.


 long d = 0;
   };

   constexpr A baz(const A *q) { return A(p); };


And same here.


   constexpr A a = baz();
   constexpr A b = baz(); // no error

The initialization of 'b' should be ill-formed, but the result
of
the
first call to baz() would be {0}, so we would cache it and
then
reuse
the result when initializing 'b'.


Ah, true.  Can we still cache if we're initializing something that
isn't
TREE_STATIC?


Hmm, we correctly compile the analogous non-TREE_STATIC testcase

struct A {
  A() = default; A(const A&);
  constexpr A(const A *p) : d{this == p} { }
  bool d;
};

constexpr A baz(const A *p) { return A(p); }

void foo() {
  constexpr A x = baz();
  constexpr 

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

[Richard Biener]

On Tue, 14 Apr 2020, Jan Hubicka wrote:

> > On Tue, 14 Apr 2020, Richard Sandiford wrote:
> > 
> > > Richard Biener  writes:
> > > > This makes same_type_for_tbaa_p conservative in the same way
> > > > get_alias_set is about void * which we allow to alias all other
> > > > pointers.
> > > >
> > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> > > >
> > > > Honza, is this what you had in mind?
> > > >
> > > > Thanks,
> > > > Richard.
> > > >
> > > > 2020-04-14  Richard Biener  
> > > >
> > > > PR middle-end/94539
> > > > * tree-ssa-alias.c (same_type_for_tbaa): Handle void *
> > > > pointers the same as get_alias_set, returning -1.
> > > >
> > > > * gcc.dg/alias-14.c: Make dg-do run.
> > > > ---
> > > >  gcc/testsuite/gcc.dg/alias-14.c | 2 +-
> > > >  gcc/tree-ssa-alias.c| 9 +
> > > >  2 files changed, 10 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/gcc/testsuite/gcc.dg/alias-14.c 
> > > > b/gcc/testsuite/gcc.dg/alias-14.c
> > > > index 1ca1c09d5e3..24f0d1c1168 100644
> > > > --- a/gcc/testsuite/gcc.dg/alias-14.c
> > > > +++ b/gcc/testsuite/gcc.dg/alias-14.c
> > > > @@ -1,4 +1,4 @@
> > > > -/* { dg-do compile } */
> > > > +/* { dg-do run } */
> > > >  /* { dg-options "-O2" } */
> > > >  #include 
> > > >  void *a;
> > > > diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> > > > index df9ba0de0d6..2850141303e 100644
> > > > --- a/gcc/tree-ssa-alias.c
> > > > +++ b/gcc/tree-ssa-alias.c
> > > > @@ -831,6 +831,15 @@ same_type_for_tbaa (tree type1, tree type2)
> > > >&& TREE_CODE (type2) == ARRAY_TYPE)
> > > >  return -1;
> > > >  
> > > > +  /* void * is compatible with all other pointers.  */
> > > > +  if (POINTER_TYPE_P (type1)
> > > > +  && POINTER_TYPE_P (type2)
> > > > +  && (TREE_CODE (TREE_TYPE (type1)) == VOID_TYPE
> > > > + || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type1))
> > > > + || TREE_CODE (TREE_TYPE (type2)) == VOID_TYPE
> > > > + || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type2
> > > > +return -1;
> > > > +
> > > 
> > > Could you add a comment about the TYPE_STRUCTURAL_EQUALITY_P checks?
> > > Was surprised by them at first, since in aarch64 we use the flag to keep
> > > a distinct ABI identity between ACLE vector types and other vector types.
> > > I'm not sure we expected that to affect the aliasing rules between the
> > > vector types and (say) arbitrary structures.
> > 
> > I copied that from the get_alias_set handling:
> > 
> >   /* Make void * compatible with char * and also void **.
> >  Programs are commonly violating TBAA by this.
> > 
> >  We also make void * to conflict with every pointer
> >  (see record_component_aliases) and thus it is safe it to use it 
> > for
> >  pointers to types with TYPE_STRUCTURAL_EQUALITY_P.  */
> >   if (TREE_CODE (p) == VOID_TYPE || TYPE_STRUCTURAL_EQUALITY_P (p))
> > set = get_alias_set (ptr_type_node);
> > 
> > and the reason is that while we keep struct S * and struct R * have
> > different alias sets the case where 'S' requires structural equality
> > means we have to use an alias-set that conflicts with any other
> > pointer.  I'll add a pointer to get_alias_set in the comment.
> > 
> > Note that structures with TYPE_STRUCTURAL_EQUALITY_P use alias-set zero,
> > thus have TBAA disabled.  Note for vector types this only matters as
> > of the pointer case (we're maybe missing to look one level deeper
> > here), vector types themselves use the alias-set of the component type.
> 
> Thanks. I had same patch but failed to send it earlier. I believe it is
> safe to return 1 since the types really are considered same by TBAA.

Note that now, looking again, the TYPE_STRUCTURAL_EQUALITY_P in my patch
doesn't match that of get_alias_set.  Since we're looking at the alias
sets of type1 and type2 anyway we could resort to alias_sets_conflict_p
for the two POINTER_TYPE_P case and return -1 then.  Not sure about
returning 1 - they are not the same as in, one cannot replace a
*(void *) access with a *(T *) access since the latter behaves differently
wrt a *(U *) access not visible to the call.

But the semantics of same_type_for_tbaa are not entirely clear
(ISTR you suggested to use it for ICF-like compares).

So, like the following.

Richard.


middle-end/94539 - void * aliases every other pointer

This makes same_type_for_tbaa_p conservative in the same way
get_alias_set is about void * which we allow to alias all other
pointers.

2020-04-14  Richard Biener  

PR middle-end/94539
* tree-ssa-alias.c (same_type_for_tbaa): Defer to
alias_sets_conflict_p for pointers.

* gcc.dg/alias-14.c: Make dg-do run.
---
 gcc/testsuite/gcc.dg/alias-14.c |  2 +-
 gcc/tree-ssa-alias.c| 11 ++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/alias-14.c b/gcc/testsuite/gcc.dg/alias-14.c
index 

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Jason Merrill via Gcc-patches]

On 4/14/20 12:29 AM, Patrick Palka wrote:

On Mon, 13 Apr 2020, Jason Merrill wrote:


On 4/13/20 2:49 PM, Patrick Palka wrote:

On Mon, 13 Apr 2020, Jason Merrill wrote:


On 4/12/20 9:43 AM, Patrick Palka wrote:

On Sat, 11 Apr 2020, Jason Merrill wrote:


On 4/10/20 5:47 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Jason Merrill wrote:

On 4/10/20 2:15 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Patrick Palka wrote:


On Fri, 10 Apr 2020, Jason Merrill wrote:


On 4/10/20 1:04 PM, Patrick Palka wrote:

On Thu, 9 Apr 2020, Patrick Palka wrote:

On Thu, 9 Apr 2020, Jason Merrill wrote:


On 4/8/20 7:49 PM, Patrick Palka wrote:

When evaluating the initializer of 'a' in the
following
example

 struct A { A *p = this; };
 constexpr A foo() { return {}; }
 constexpr A a = foo();

the PLACEHOLDER_EXPR for 'this' in the aggregate
initializer
returned
by foo
gets resolved to the RESULT_DECL of foo.  But due to
guaranteed
RVO,
the
'this'
should really be resolved to ''.



It seems to me that the right approach would be to
immediately
resolve
the
PLACEHOLDER_EXPR to the correct target object during
evaluation
of
'foo()',
so
that we could use 'this' to access objects adjacent
to
the
current
object in
the
ultimate storage location.  (I think #c2 of PR
c++/94537
is
an
example
of
such
usage of 'this', which currently doesn't work.  But
as
#c1
shows
we
don't
seem
to handle this case correctly in non-constexpr
initialization
either.)


As I commented in the PR, the standard doesn't require
this to
work
because A
is trivially copyable, and our ABI makes it
impossible.
But
there's
still a
constexpr bug when we add

A() = default; A(const A&);

clang doesn't require the constructors to make this
work
for
constant
initialization, but similarly can't make it work for
non-constant
initialization.


That makes a lot of sense, thanks for the detailed
explanation.




I haven't yet been able to make a solution using the
above
approach
work --
making sure we use the ultimate object instead of
the
RESULT_DECL
whenever
we
access ctx->global->values is proving to be tricky
and
subtle.


Do we need to go through ctx->global->values?  Would
it
work
for
the
RESULT_DECL case in cxx_eval_constant_expression to go
to
straight
to
ctx->object or ctx->ctor instead?


I attempted that at some point, but IIRC we still end up
not
resolving
some RESULT_DECLs because not all of them get processed
through
cxx_eval_constant_expression before we manipulate
ctx->global->values
with them.  I'll try this approach more carefully and
report
back
with
more specifics.


It turns out that immediately resolving
RESULT_DECLs/'this' to
the
ultimate ctx->object would not interact well with
constexpr_call
caching:

struct A { A() = default; A(const A&); A *ap =
this; };
constexpr A foo() { return {}; }
constexpr A a = foo();
constexpr A b = foo();
static_assert(b.ap == ); // fails

Evaluation of the first call to foo() returns {}, since
we
resolve
'this' to  due to guaranteed RVO, and we cache this
result.
Evaluation of the second call to foo() just returns the
cached
result
from the constexpr_call cache, and so we get {} again.

So it seems we would have to mark the result of a
constexpr
call
as
not
cacheable whenever this RVO applies during its evaluation,
even
when
doing the RVO has no observable difference in the final
result
(i.e.
the
constructor does not try to save the 'this' pointer).

Would the performance impact of disabling caching whenever
RVO
applies
during constexpr call evaluation be worth it, or should we
go
with
something like my first patch which "almost works," and
which
marks a
constexpr call as not cacheable only when we replace a
RESULT_DECL
in
the result of the call?


Could we search through the result of the call for
ctx->object
and
cache
if we
don't find it?


Hmm, I think the result of the call could still depend on
ctx->object
without ctx->object explicitly appearing in the result.
Consider
the
following testcase:

   struct A {
 A() = default; A(const A&);
 constexpr A(const A *q) : d{this - p} { }


Oops sorry, that 'q' should be a 'p'.


 long d = 0;
   };

   constexpr A baz(const A *q) { return A(p); };


And same here.


   constexpr A a = baz();
   constexpr A b = baz(); // no error

The initialization of 'b' should be ill-formed, but the result
of
the
first call to baz() would be {0}, so we would cache it and
then
reuse
the result when initializing 'b'.


Ah, true.  Can we still cache if we're initializing something that
isn't
TREE_STATIC?


Hmm, we correctly compile the analogous non-TREE_STATIC testcase

struct A {
  A() = default; A(const A&);
  constexpr A(const A *p) : d{this == p} { }
  bool d;
};

constexpr A baz(const A *p) { return A(p); }

void foo() {
  constexpr A x = baz();
  constexpr A y = baz();
  static_assert(!y.d);

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

[Jan Hubicka]

> On Tue, 14 Apr 2020, Richard Sandiford wrote:
> 
> > Richard Biener  writes:
> > > This makes same_type_for_tbaa_p conservative in the same way
> > > get_alias_set is about void * which we allow to alias all other
> > > pointers.
> > >
> > > Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> > >
> > > Honza, is this what you had in mind?
> > >
> > > Thanks,
> > > Richard.
> > >
> > > 2020-04-14  Richard Biener  
> > >
> > >   PR middle-end/94539
> > >   * tree-ssa-alias.c (same_type_for_tbaa): Handle void *
> > >   pointers the same as get_alias_set, returning -1.
> > >
> > >   * gcc.dg/alias-14.c: Make dg-do run.
> > > ---
> > >  gcc/testsuite/gcc.dg/alias-14.c | 2 +-
> > >  gcc/tree-ssa-alias.c| 9 +
> > >  2 files changed, 10 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/gcc/testsuite/gcc.dg/alias-14.c 
> > > b/gcc/testsuite/gcc.dg/alias-14.c
> > > index 1ca1c09d5e3..24f0d1c1168 100644
> > > --- a/gcc/testsuite/gcc.dg/alias-14.c
> > > +++ b/gcc/testsuite/gcc.dg/alias-14.c
> > > @@ -1,4 +1,4 @@
> > > -/* { dg-do compile } */
> > > +/* { dg-do run } */
> > >  /* { dg-options "-O2" } */
> > >  #include 
> > >  void *a;
> > > diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> > > index df9ba0de0d6..2850141303e 100644
> > > --- a/gcc/tree-ssa-alias.c
> > > +++ b/gcc/tree-ssa-alias.c
> > > @@ -831,6 +831,15 @@ same_type_for_tbaa (tree type1, tree type2)
> > >&& TREE_CODE (type2) == ARRAY_TYPE)
> > >  return -1;
> > >  
> > > +  /* void * is compatible with all other pointers.  */
> > > +  if (POINTER_TYPE_P (type1)
> > > +  && POINTER_TYPE_P (type2)
> > > +  && (TREE_CODE (TREE_TYPE (type1)) == VOID_TYPE
> > > +   || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type1))
> > > +   || TREE_CODE (TREE_TYPE (type2)) == VOID_TYPE
> > > +   || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type2
> > > +return -1;
> > > +
> > 
> > Could you add a comment about the TYPE_STRUCTURAL_EQUALITY_P checks?
> > Was surprised by them at first, since in aarch64 we use the flag to keep
> > a distinct ABI identity between ACLE vector types and other vector types.
> > I'm not sure we expected that to affect the aliasing rules between the
> > vector types and (say) arbitrary structures.
> 
> I copied that from the get_alias_set handling:
> 
>   /* Make void * compatible with char * and also void **.
>  Programs are commonly violating TBAA by this.
> 
>  We also make void * to conflict with every pointer
>  (see record_component_aliases) and thus it is safe it to use it 
> for
>  pointers to types with TYPE_STRUCTURAL_EQUALITY_P.  */
>   if (TREE_CODE (p) == VOID_TYPE || TYPE_STRUCTURAL_EQUALITY_P (p))
> set = get_alias_set (ptr_type_node);
> 
> and the reason is that while we keep struct S * and struct R * have
> different alias sets the case where 'S' requires structural equality
> means we have to use an alias-set that conflicts with any other
> pointer.  I'll add a pointer to get_alias_set in the comment.
> 
> Note that structures with TYPE_STRUCTURAL_EQUALITY_P use alias-set zero,
> thus have TBAA disabled.  Note for vector types this only matters as
> of the pointer case (we're maybe missing to look one level deeper
> here), vector types themselves use the alias-set of the component type.

Thanks. I had same patch but failed to send it earlier. I believe it is
safe to return 1 since the types really are considered same by TBAA.

Honza
> 
> Richard.

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Patrick Palka via Gcc-patches]

On Tue, 14 Apr 2020, Patrick Palka wrote:

> On Mon, 13 Apr 2020, Jason Merrill wrote:
> 
> > On 4/13/20 2:49 PM, Patrick Palka wrote:
> > > On Mon, 13 Apr 2020, Jason Merrill wrote:
> > > 
> > > > On 4/12/20 9:43 AM, Patrick Palka wrote:
> > > > > On Sat, 11 Apr 2020, Jason Merrill wrote:
> > > > > 
> > > > > > On 4/10/20 5:47 PM, Patrick Palka wrote:
> > > > > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > > > > On 4/10/20 2:15 PM, Patrick Palka wrote:
> > > > > > > > > On Fri, 10 Apr 2020, Patrick Palka wrote:
> > > > > > > > > 
> > > > > > > > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > > > > > > 
> > > > > > > > > > > On 4/10/20 1:04 PM, Patrick Palka wrote:
> > > > > > > > > > > > On Thu, 9 Apr 2020, Patrick Palka wrote:
> > > > > > > > > > > > > On Thu, 9 Apr 2020, Jason Merrill wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > On 4/8/20 7:49 PM, Patrick Palka wrote:
> > > > > > > > > > > > > > > When evaluating the initializer of 'a' in the
> > > > > > > > > > > > > > > following
> > > > > > > > > > > > > > > example
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > struct A { A *p = this; };
> > > > > > > > > > > > > > > constexpr A foo() { return {}; }
> > > > > > > > > > > > > > > constexpr A a = foo();
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > the PLACEHOLDER_EXPR for 'this' in the aggregate
> > > > > > > > > > > > > > > initializer
> > > > > > > > > > > > > > > returned
> > > > > > > > > > > > > > > by foo
> > > > > > > > > > > > > > > gets resolved to the RESULT_DECL of foo.  But due 
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > guaranteed
> > > > > > > > > > > > > > > RVO,
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > 'this'
> > > > > > > > > > > > > > > should really be resolved to ''.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > It seems to me that the right approach would be to
> > > > > > > > > > > > > > > immediately
> > > > > > > > > > > > > > > resolve
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > PLACEHOLDER_EXPR to the correct target object 
> > > > > > > > > > > > > > > during
> > > > > > > > > > > > > > > evaluation
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > 'foo()',
> > > > > > > > > > > > > > > so
> > > > > > > > > > > > > > > that we could use 'this' to access objects 
> > > > > > > > > > > > > > > adjacent
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > current
> > > > > > > > > > > > > > > object in
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > ultimate storage location.  (I think #c2 of PR
> > > > > > > > > > > > > > > c++/94537
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > an
> > > > > > > > > > > > > > > example
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > such
> > > > > > > > > > > > > > > usage of 'this', which currently doesn't work.  
> > > > > > > > > > > > > > > But
> > > > > > > > > > > > > > > as
> > > > > > > > > > > > > > > #c1
> > > > > > > > > > > > > > > shows
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > seem
> > > > > > > > > > > > > > > to handle this case correctly in non-constexpr
> > > > > > > > > > > > > > > initialization
> > > > > > > > > > > > > > > either.)
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > As I commented in the PR, the standard doesn't 
> > > > > > > > > > > > > > require
> > > > > > > > > > > > > > this to
> > > > > > > > > > > > > > work
> > > > > > > > > > > > > > because A
> > > > > > > > > > > > > > is trivially copyable, and our ABI makes it
> > > > > > > > > > > > > > impossible.
> > > > > > > > > > > > > > But
> > > > > > > > > > > > > > there's
> > > > > > > > > > > > > > still a
> > > > > > > > > > > > > > constexpr bug when we add
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > A() = default; A(const A&);
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > clang doesn't require the constructors to make this
> > > > > > > > > > > > > > work
> > > > > > > > > > > > > > for
> > > > > > > > > > > > > > constant
> > > > > > > > > > > > > > initialization, but similarly can't make it work for
> > > > > > > > > > > > > > non-constant
> > > > > > > > > > > > > > initialization.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > That makes a lot of sense, thanks for the detailed
> > > > > > > > > > > > > explanation.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I haven't yet been able to make a solution using 
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > above
> > > > > > > > > > > > > > > approach
> > > > > > > > > > > > > > > work --
> > > > > > > > > > > > > > > making sure we use the ultimate object instead of
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > RESULT_DECL
> > > > > > > > > > > > > > > 

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

[Richard Biener]

On Tue, 14 Apr 2020, Richard Sandiford wrote:

> Richard Biener  writes:
> > This makes same_type_for_tbaa_p conservative in the same way
> > get_alias_set is about void * which we allow to alias all other
> > pointers.
> >
> > Bootstrap & regtest running on x86_64-unknown-linux-gnu.
> >
> > Honza, is this what you had in mind?
> >
> > Thanks,
> > Richard.
> >
> > 2020-04-14  Richard Biener  
> >
> > PR middle-end/94539
> > * tree-ssa-alias.c (same_type_for_tbaa): Handle void *
> > pointers the same as get_alias_set, returning -1.
> >
> > * gcc.dg/alias-14.c: Make dg-do run.
> > ---
> >  gcc/testsuite/gcc.dg/alias-14.c | 2 +-
> >  gcc/tree-ssa-alias.c| 9 +
> >  2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/testsuite/gcc.dg/alias-14.c 
> > b/gcc/testsuite/gcc.dg/alias-14.c
> > index 1ca1c09d5e3..24f0d1c1168 100644
> > --- a/gcc/testsuite/gcc.dg/alias-14.c
> > +++ b/gcc/testsuite/gcc.dg/alias-14.c
> > @@ -1,4 +1,4 @@
> > -/* { dg-do compile } */
> > +/* { dg-do run } */
> >  /* { dg-options "-O2" } */
> >  #include 
> >  void *a;
> > diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> > index df9ba0de0d6..2850141303e 100644
> > --- a/gcc/tree-ssa-alias.c
> > +++ b/gcc/tree-ssa-alias.c
> > @@ -831,6 +831,15 @@ same_type_for_tbaa (tree type1, tree type2)
> >&& TREE_CODE (type2) == ARRAY_TYPE)
> >  return -1;
> >  
> > +  /* void * is compatible with all other pointers.  */
> > +  if (POINTER_TYPE_P (type1)
> > +  && POINTER_TYPE_P (type2)
> > +  && (TREE_CODE (TREE_TYPE (type1)) == VOID_TYPE
> > + || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type1))
> > + || TREE_CODE (TREE_TYPE (type2)) == VOID_TYPE
> > + || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type2
> > +return -1;
> > +
> 
> Could you add a comment about the TYPE_STRUCTURAL_EQUALITY_P checks?
> Was surprised by them at first, since in aarch64 we use the flag to keep
> a distinct ABI identity between ACLE vector types and other vector types.
> I'm not sure we expected that to affect the aliasing rules between the
> vector types and (say) arbitrary structures.

I copied that from the get_alias_set handling:

  /* Make void * compatible with char * and also void **.
 Programs are commonly violating TBAA by this.

 We also make void * to conflict with every pointer
 (see record_component_aliases) and thus it is safe it to use it 
for
 pointers to types with TYPE_STRUCTURAL_EQUALITY_P.  */
  if (TREE_CODE (p) == VOID_TYPE || TYPE_STRUCTURAL_EQUALITY_P (p))
set = get_alias_set (ptr_type_node);

and the reason is that while we keep struct S * and struct R * have
different alias sets the case where 'S' requires structural equality
means we have to use an alias-set that conflicts with any other
pointer.  I'll add a pointer to get_alias_set in the comment.

Note that structures with TYPE_STRUCTURAL_EQUALITY_P use alias-set zero,
thus have TBAA disabled.  Note for vector types this only matters as
of the pointer case (we're maybe missing to look one level deeper
here), vector types themselves use the alias-set of the component type.

Richard.

Re: [PATCH] i386: Remove mode size check in ix86_get_ssemov

[Jakub Jelinek via Gcc-patches]

On Sat, Apr 11, 2020 at 02:48:22PM -0700, H.J. Lu via Gcc-patches wrote:
> Even though ix86_hard_regno_mode_ok doesn't allow xmm16-xmm31 nor
> ymm16-ymm31 in 128/256 bit modes when AVX512VL is disabled, reload
> can still generate reg to reg moves with xmm16-xmm31 and ymm16-ymm31
> in 128/256 bit modes.  Remove mode size check in ix86_get_ssemov.

Looking at the testcase, LRA doesn't have good choices,
(define_insn ("*avx512f_gatherdiv16si")
 [
(set (match_operand:V16SI 0 ("register_operand") ("="))
(unspec:V16SI [
(match_operand:V8SI 1 ("register_operand") ("0"))
...
so if the output is chosen to be zmm16+, then LRA is required to stick
a V8SI pseudo into that register, even when ix86_hard_regno_mode_ok
isn't ok with that.
Unless we changed all the patterns with such issues (i.e. where a
128-bit/256-bit operand uses matching constraint to 512-bit one with
v) so that it uses just x on the matching operand unless avx512vl.
Before your changes, we would just emit the *mov_internal even in
those cases, so your change matches what we used to do.

> 
> gcc/
> 
>   PR target/94561
>   * config/i386/i386.c (ix86_get_ssemov): Remove mode size check.
> 
> gcc/testsuite/
> 
>   PR target/94561
>   * gcc.target/i386/pr94561.c: New test.

Ok.

Jakub

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

[Richard Sandiford]

Richard Biener  writes:
> This makes same_type_for_tbaa_p conservative in the same way
> get_alias_set is about void * which we allow to alias all other
> pointers.
>
> Bootstrap & regtest running on x86_64-unknown-linux-gnu.
>
> Honza, is this what you had in mind?
>
> Thanks,
> Richard.
>
> 2020-04-14  Richard Biener  
>
>   PR middle-end/94539
>   * tree-ssa-alias.c (same_type_for_tbaa): Handle void *
>   pointers the same as get_alias_set, returning -1.
>
>   * gcc.dg/alias-14.c: Make dg-do run.
> ---
>  gcc/testsuite/gcc.dg/alias-14.c | 2 +-
>  gcc/tree-ssa-alias.c| 9 +
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/alias-14.c b/gcc/testsuite/gcc.dg/alias-14.c
> index 1ca1c09d5e3..24f0d1c1168 100644
> --- a/gcc/testsuite/gcc.dg/alias-14.c
> +++ b/gcc/testsuite/gcc.dg/alias-14.c
> @@ -1,4 +1,4 @@
> -/* { dg-do compile } */
> +/* { dg-do run } */
>  /* { dg-options "-O2" } */
>  #include 
>  void *a;
> diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> index df9ba0de0d6..2850141303e 100644
> --- a/gcc/tree-ssa-alias.c
> +++ b/gcc/tree-ssa-alias.c
> @@ -831,6 +831,15 @@ same_type_for_tbaa (tree type1, tree type2)
>&& TREE_CODE (type2) == ARRAY_TYPE)
>  return -1;
>  
> +  /* void * is compatible with all other pointers.  */
> +  if (POINTER_TYPE_P (type1)
> +  && POINTER_TYPE_P (type2)
> +  && (TREE_CODE (TREE_TYPE (type1)) == VOID_TYPE
> +   || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type1))
> +   || TREE_CODE (TREE_TYPE (type2)) == VOID_TYPE
> +   || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type2
> +return -1;
> +

Could you add a comment about the TYPE_STRUCTURAL_EQUALITY_P checks?
Was surprised by them at first, since in aarch64 we use the flag to keep
a distinct ABI identity between ACLE vector types and other vector types.
I'm not sure we expected that to affect the aliasing rules between the
vector types and (say) arbitrary structures.

Thanks,
Richard

Re: [PATCH 2/5] testsuite: [arm/mve] Use arm_softfp and arm_hard as needed in MVE tests

[Christophe Lyon via Gcc-patches]

On Tue, 14 Apr 2020 at 10:21, Andre Vieira (lists) <
andre.simoesdiasvie...@arm.com> wrote:

> On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:
> > Some MVE tests explicitly test a -mfloat-abi=hard option, but we need
> > to check that the toolchain actually supports it (which may not be the
> > case for arm-linux-gnueabi* targets).
> >
> > We also make use of dg-add-options arm_v8_1m_mve_fp and arm_v8_1m_mve
> > instead of duplicating the corresponding options in
> > dg-additional-options where we keep only -mfloat-abi to override the
> > option selected by arm_v8_1m_mve_fp.
> Hi Christophe,
>
> This sounds good!! Thank you for doing this.
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
> > index 1462dd4..0fa3afd 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
> > @@ -1,6 +1,8 @@
> >   /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
> > +/* { dg-require-effective-target arm_hard_ok } */
> > +/* { dg-add-options arm_v8_1m_mve_fp } */
> >   /* { dg-skip-if "Incompatible float ABI" { *-*-* } {
> "-mfloat-abi=soft" } {""} } */
> I was wondering, do we still need the skip-if with the arm_hard_ok?
>

Indeed, I just checked that it's useless by running with
--target-board=-mfloat-abi=soft.

> -/* { dg-additional-options "-march=armv8.1-m.main+mve.fp
> -mfloat-abi=hard -mthumb -mfpu=auto --save-temps" } */
> > +/* { dg-additional-options "-mfloat-abi=hard" } */
> >
> >   #include "arm_mve.h"
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c
> > index d528133..1fca110 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c
> > @@ -1,5 +1,7 @@
> >   /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
> > -/* { dg-additional-options "-march=armv8.1-m.main+mve.fp
> -mfloat-abi=softfp -mthumb -mfpu=auto --save-temps" } */
> > +/* { dg-require-effective-target arm_softfp_ok } */
> > +/* { dg-add-options arm_v8_1m_mve_fp } */
> > +/* { dg-additional-options "-mfloat-abi=softfp" } */
> >
> >   #include "arm_mve.h"
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c
> > index 59ca724..726f9ec 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c
> > @@ -1,6 +1,8 @@
> >   /* { dg-require-effective-target arm_v8_1m_mve_ok } */
> > +/* { dg-require-effective-target arm_hard_ok } */
> > +/* { dg-add-options arm_v8_1m_mve } */
> >   /* { dg-skip-if "Incompatible float ABI" { *-*-* } {
> "-mfloat-abi=soft" } {""} } */
> Same here.
>
Same


> > -/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard
> -mthumb -mfpu=auto --save-temps" } */
> > +/* { dg-additional-options "-mfloat-abi=hard" } */
> >
> >   #include "arm_mve.h"
> >
> > diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c
> > index ce297ea..7f39905 100644
> > --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c
> > +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c
> > @@ -1,6 +1,8 @@
> >   /* { dg-require-effective-target arm_v8_1m_mve_ok } */
> > +/* { dg-require-effective-target arm_softfp_ok } */
> > +/* { dg-add-options arm_v8_1m_mve } */
> >   /* { dg-skip-if "Incompatible float ABI" { *-*-* } {
> "-mfloat-abi=soft" } {""} } */
> And here.
>
Without dg-skip-if, the test passes since soft and softfp are compatible.


> > -/* { dg-additional-options "-march=armv8.1-m.main+mve
> -mfloat-abi=softfp -mthumb -mfpu=auto --save-temps" } */
> > +/* { dg-additional-options "-mfloat-abi=softfp" } */
> >
> >   #include "arm_mve.h"
> >
> LGTM.
>
Thanks, I'll remove the dg-skip-if clauses above before committing if the
patch is approved.

Christophe

Re: [PATCH], Fix target/94557 PowerPC regression on GCC 9 (variable vec_extract)

[Segher Boessenkool]

Hi,

On Mon, Apr 13, 2020 at 10:24:39PM -0400, Michael Meissner wrote:
> This patch fixes PR target/94557, on PowerPC.  It was a regression on the GCC 
> 9
> branch caused by my recent patch for PR target/93932.
> 
> The patch for 93932 was a back port from the master branch of a fix for the
> vec_extract built-in function.  This patch fixes the case where we are
> optimizing a vector extract from an vector in memory to be a scalar load
> instead of loading the vector to a register and then doing an extract.

What does "this patch" mean?  The backport?

> This patch adds in the masking of the vector index that is in the master
> branch.  I re-implemented the change for GCC 9, since the changes on the 
> master
> branch are more extensive, and include PC-relative support that is not in GCC
> 9.

Hrm.

> 2020-04-13  Michael Meissner  
> 
>   PR target/94557
>   * config/rs6000/rs6000.c (rs6000_adjust_vec_address): Mask
>   variable vector extract index so it does not go beyond the vector
>   when extracting a vector element from memory.  This change is a
>   simplification of the 2020-02-03 patch that went into the trunk.

You have no patches go into trunk at that date.

> --- /tmp/4XFFqK_rs6000.c  2020-04-13 15:28:33.514011024 -0500
> +++ gcc/config/rs6000/rs6000.c2020-04-13 14:24:01.296932921 -0500
> @@ -7047,18 +7047,25 @@ rs6000_adjust_vec_address (rtx scalar_re
>  element_offset = GEN_INT (INTVAL (element) * scalar_size);
>else
>  {
> +  /* Mask the element to make sure the element number is between 0 and 
> the
> +  maximum number of elements - 1 so that we don't generate an address
> +  outside the vector.  */

The patch introducing this to trunk was reverted.


I don't get the warm and fuzzies from this patch.  How can I expect that
it won't cause more problems than it solves, like this?  Reverts and new
implementations, and also mislabeled?

Please explain this better?


Segher

Re: [PATCH] gcc/gcc.c: add outfiles spec

[Rasmus Villemoes]

On 06/04/2020 23.18, Joseph Myers wrote:
> On Sat, 4 Apr 2020, Rasmus Villemoes wrote:
> 
>> +#ifndef OUTFILES_SPEC
>> +#define OUTFILES_SPEC "%o"
>> +#endif
> 
> A new target macro needs to be documented in tm.texi.in,

Will do.

> with tm.texi then being regenerated.

Please include information on how I would go about doing that, or point
at a README/wiki that explains it. Is it just copying the generated
tm.texi from the build/gcc/ dir back to the src/gcc/doc/ dir?

Also, does my write-after-approval permission still apply after ~1.5
years of non-activity, and the switch to git? If so, do I just make sure
my changes (after approval, of course) apply cleanly on top of master
and then push that?

Thanks,
Rasmus

Re: [PATCH PR94574] ICE during GIMPLE pass: ccp

[Richard Biener via Gcc-patches]

On Tue, Apr 14, 2020 at 1:57 PM yangyang (ET)  wrote:
>
> Hi,
>
> > -Original Message-
> > From: Richard Biener [mailto:richard.guent...@gmail.com]
> > Sent: Tuesday, April 14, 2020 4:44 PM
> > To: yangyang (ET) 
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH PR94574] ICE during GIMPLE pass: ccp
> >
> > On Mon, Apr 13, 2020 at 11:38 AM yangyang (ET) 
> > wrote:
> > >
> > > Hi,
> > >
> > >   This is a simple fix for pr94574.
> > >
> > >   testcase testsuite/gcc.target/aarch64/sve/acle/general/deref_1.c ICEs
> > when testing GCC trunk with -O2 -msve-vector-bits=256
> > -march=armv8.2-a+sve.
> > >
> > >   There is a gimple statement before the ccp pass as follow:
> > >
> > >   MEM[(svuint32_t *)] = _2;
> > >
> > >   The ccp pass tries to convert this gimple into:
> > >
> > >   _7 = VIEW_CONVERT_EXPR(_2);
> > >   res_9 = BIT_INSERT_EXPR ;
> > >
> > >   However,  the size of _7 is larger than res_8(D) , leading to a
> > verify_gimple failure. Since the replaced bits of BIT_INSERT_EXPR are 
> > supposed
> > to fully inside the container, before doing the above optimitzaion, a check 
> > shall
> > be added.
> > >
> > >   With this fix, a MEM_REF which visits the address of a vector will be
> > rewritten into a BIT_INSERT_EXPR only when the size of the vector is larger
> > than the size of MEM_REF. In this way, this kind of ICE can be avoided.
> > >
> > >   a test case with which this problem will be exposed more easily is
> > extracted and added for this. Bootstrapped/regtested on both x86_64 and
> > aarch64 Linux platform.
> > >   Any suggestion?
> >
> > OK.
> >
> > Thanks,
> > Richard.
>
>
>   Thanks for reviewing this.
>
>   The attached patch has been adjusted to be suitable for git am. Can you 
> sponsor it if it's OK to go?

Will do.

> Thanks,
> Yang Yang

[PATCH] Add myself as callgraph (IPA) reviewer

[Martin Jambor]

Hi,

On Mon, Apr 13 2020, David Edelsohn wrote:
>   I am pleased to announce that the GCC Steering Committee has
> appointed Martin Jambor as GCC IPA Reviewer.
>
>   Please join me in congratulating Martin on his new role.
> Martin, please update your listing in the MAINTAINERS file.
>

Thank you very much!  I am about to commit the following patch.

Martin


2020-04-14  Martin Jambor  

* MAINTAINERS (Reviewers): Add myself as callgraph (IPA) reviewer.
---
 ChangeLog   | 4 
 MAINTAINERS | 1 +
 2 files changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f2924c6cbe3..f37e9e68622 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -256,6 +256,7 @@ check in changes outside of the parts of the compiler they 
maintain.
 arc port   Andrew Burgess  
 arc port   Claudiu Zissulescu  
 callgraph  Martin Liska
+callgraph  Martin Jambor   
 C front endMarek Polacek   
 dataflow   Paolo Bonzini   
 dataflow   Seongbae Park   
-- 
2.26.0

RE: [PATCH PR94574] ICE during GIMPLE pass: ccp

[yangyang (ET)]

Hi,

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, April 14, 2020 4:44 PM
> To: yangyang (ET) 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94574] ICE during GIMPLE pass: ccp
> 
> On Mon, Apr 13, 2020 at 11:38 AM yangyang (ET) 
> wrote:
> >
> > Hi,
> >
> >   This is a simple fix for pr94574.
> >
> >   testcase testsuite/gcc.target/aarch64/sve/acle/general/deref_1.c ICEs
> when testing GCC trunk with -O2 -msve-vector-bits=256
> -march=armv8.2-a+sve.
> >
> >   There is a gimple statement before the ccp pass as follow:
> >
> >   MEM[(svuint32_t *)] = _2;
> >
> >   The ccp pass tries to convert this gimple into:
> >
> >   _7 = VIEW_CONVERT_EXPR(_2);
> >   res_9 = BIT_INSERT_EXPR ;
> >
> >   However,  the size of _7 is larger than res_8(D) , leading to a
> verify_gimple failure. Since the replaced bits of BIT_INSERT_EXPR are supposed
> to fully inside the container, before doing the above optimitzaion, a check 
> shall
> be added.
> >
> >   With this fix, a MEM_REF which visits the address of a vector will be
> rewritten into a BIT_INSERT_EXPR only when the size of the vector is larger
> than the size of MEM_REF. In this way, this kind of ICE can be avoided.
> >
> >   a test case with which this problem will be exposed more easily is
> extracted and added for this. Bootstrapped/regtested on both x86_64 and
> aarch64 Linux platform.
> >   Any suggestion?
> 
> OK.
> 
> Thanks,
> Richard.


  Thanks for reviewing this. 

  The attached patch has been adjusted to be suitable for git am. Can you 
sponsor it if it's OK to go? 

Thanks,
Yang Yang


pr94574-v1.patch
Description: pr94574-v1.patch

[patch, fortran, committed] Fix PR 94270

[Thomas Koenig via Gcc-patches]

Hi,

I just committed the attached patch as obvious and simple.
Since this is a regression, I will backport to gcc 9 and
gcc 8 shortly.

(I'm attaching the patch as txt file in the hope it will not
be munged in the web archive).

Regards

Thomas

Fix PR 94270 by not warning about artifical dummy arguments.

2020-04-14  Thomas Koenig  

PR fortran/94270
* interface.c (gfc_get_formal_from_actual_arglist): Always
set artificial attribute for symbols.
* trans-decl.c (generate_local_decl): Do not warn if the
symbol is artifical.

2020-04-14  Thomas Koenig  

PR fortran/94270
* gfortran.dg/warn_unused_dummy_argument_6.f90: New test.
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 96835dea4bf..6d01bd035de 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,11 @@
+2020-04-14  Thomas Koenig  
+
+   PR fortran/94270
+   * interface.c (gfc_get_formal_from_actual_arglist): Always
+   set artificial attribute for symbols.
+   * trans-decl.c (generate_local_decl): Do not warn if the
+   symbol is artifical.
+
 2020-04-13  Linus Koenig 
 
PR fortran/94192
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 75a50c999b7..8f041f0a0a8 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -5317,7 +5317,6 @@ gfc_get_formal_from_actual_arglist (gfc_symbol *sym,
  s->ts.is_iso_c = 0;
  s->ts.is_c_interop = 0;
  s->attr.flavor = FL_VARIABLE;
- s->attr.artificial = 1;
  if (a->expr->rank > 0)
{
  s->attr.dimension = 1;
@@ -5332,6 +5331,7 @@ gfc_get_formal_from_actual_arglist (gfc_symbol *sym,
s->maybe_array = maybe_dummy_array_arg (a->expr);
}
  s->attr.dummy = 1;
+ s->attr.artificial = 1;
  s->declared_at = a->expr->where;
  s->attr.intent = INTENT_UNKNOWN;
  (*f)->sym = s;
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index e91a2795762..487e776f5dd 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -6072,7 +6072,7 @@ generate_local_decl (gfc_symbol * sym)
   /* Unused procedure passed as dummy argument.  */
   if (sym->attr.flavor == FL_PROCEDURE)
{
- if (!sym->attr.referenced)
+ if (!sym->attr.referenced && !sym->attr.artificial)
{
  if (warn_unused_dummy_argument)
gfc_warning (OPT_Wunused_dummy_argument,
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 2035cf6fd1f..86a3a1fe462 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-14  Thomas Koenig  
+
+   PR fortran/94270
+   * gfortran.dg/warn_unused_dummy_argument_6.f90: New test.
+
 2020-04-13  Marek Polacek  
 
PR c++/94588
diff --git a/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_6.f90 
b/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_6.f90
new file mode 100644
index 000..72f6d5c0857
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_6.f90
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! { dg-options "-Wall" }
+! PR 94270 - this used to give a bogus warning.
+! Test case by Ignacio Fernández Galván.
+subroutine foo()
+external bar
+call meh(bar)
+call foo_internal()
+contains
+  subroutine foo_internal()
+call meh(bar)
+  end subroutine foo_internal
+end subroutine foo

Re: *ping* Re: [Patch][Fortran] Fix name conflict check for use-assoc (PR 92736)

[Thomas Koenig via Gcc-patches]

Hi Tobias,


*ping*


OK. Thanks for the patch!

Regards

Thomas

ICE on wrong code [PR94192] commit

[Linus König]

Hi all,

the PR has just recently been committed. Paul gave his offline approval. 
I only realized recently, that the NULL pointer check can actually be 
ommitted if the check is moved in the code. In the commit however, it is 
still right below the declaration. I believe both ways work fine. It is 
still possible to change it.


Best regards,

Linus König

Re: Merge dg-options and dg-additional-options (with a target directive)?

[Jakub Jelinek via Gcc-patches]

On Tue, Apr 14, 2020 at 01:39:43PM +0200, Martin Liška wrote:
> On 4/14/20 1:26 PM, Jakub Jelinek wrote:
> > On Tue, Apr 14, 2020 at 01:11:36PM +0200, Martin Liška wrote:
> > > Hi.
> > > 
> > > I've noticed that various files compile both these directives.
> > > Do we want to merge them into dg-options?
> > 
> > I'd defer for GCC11
> 
> I'm fine with that.
> 
> > , and only do it if the line doesn't get way too long.
> 
> How long? 80 characters?

Roughly, yes.  A few extra in testcases don't hurt necessarily, but say 160
chars or more is clearly too much.

Jakub

Re: Merge dg-options and dg-additional-options (with a target directive)?

[Martin Liška]

On 4/14/20 1:26 PM, Jakub Jelinek wrote:

On Tue, Apr 14, 2020 at 01:11:36PM +0200, Martin Liška wrote:

Hi.

I've noticed that various files compile both these directives.
Do we want to merge them into dg-options?


I'd defer for GCC11


I'm fine with that.


, and only do it if the line doesn't get way too long.


How long? 80 characters?

Martin



Jakub

Re: Merge dg-options and dg-additional-options (with a target directive)?

[Jakub Jelinek via Gcc-patches]

On Tue, Apr 14, 2020 at 01:11:36PM +0200, Martin Liška wrote:
> Hi.
> 
> I've noticed that various files compile both these directives.
> Do we want to merge them into dg-options?

I'd defer for GCC11, and only do it if the line doesn't get way too long.

Jakub

Re: [wwwdocs] Fix inverted option for disabling new feature (PR 94581)

[Thomas König]

Am 14.04.20 um 12:11 schrieb Jonathan Wakely:

Committed as obvious.

Thomas, please fix it if this isn't what you meant to say.


Yep, that's what I meant to say.

Thanks a lot!

Regards

Thomas

[PATCH] middle-end/94539 - void * aliases every other pointer

[Richard Biener]

This makes same_type_for_tbaa_p conservative in the same way
get_alias_set is about void * which we allow to alias all other
pointers.

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Honza, is this what you had in mind?

Thanks,
Richard.

2020-04-14  Richard Biener  

PR middle-end/94539
* tree-ssa-alias.c (same_type_for_tbaa): Handle void *
pointers the same as get_alias_set, returning -1.

* gcc.dg/alias-14.c: Make dg-do run.
---
 gcc/testsuite/gcc.dg/alias-14.c | 2 +-
 gcc/tree-ssa-alias.c| 9 +
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/alias-14.c b/gcc/testsuite/gcc.dg/alias-14.c
index 1ca1c09d5e3..24f0d1c1168 100644
--- a/gcc/testsuite/gcc.dg/alias-14.c
+++ b/gcc/testsuite/gcc.dg/alias-14.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do run } */
 /* { dg-options "-O2" } */
 #include 
 void *a;
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index df9ba0de0d6..2850141303e 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -831,6 +831,15 @@ same_type_for_tbaa (tree type1, tree type2)
   && TREE_CODE (type2) == ARRAY_TYPE)
 return -1;
 
+  /* void * is compatible with all other pointers.  */
+  if (POINTER_TYPE_P (type1)
+  && POINTER_TYPE_P (type2)
+  && (TREE_CODE (TREE_TYPE (type1)) == VOID_TYPE
+ || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type1))
+ || TREE_CODE (TREE_TYPE (type2)) == VOID_TYPE
+ || TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (type2
+return -1;
+
   /* ??? In Ada, an lvalue of an unconstrained type can be used to access an
  object of one of its constrained subtypes, e.g. when a function with an
  unconstrained parameter passed by reference is called on an object and
-- 
2.25.1

Merge dg-options and dg-additional-options (with a target directive)?

[Martin Liška]

Hi.

I've noticed that various files compile both these directives.
Do we want to merge them into dg-options?

Thanks,
Martin

gcc/gcc/testsuite/g++.old-deja/g++.robertl/eb27.C:
  // { dg-options "-Wno-deprecated" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/pr94314.C:
  /* { dg-options "-O2 -fdump-tree-cddce-details" } */
  /* { dg-additional-options "-fdelete-null-pointer-checks" } */
gcc/gcc/testsuite/g++.dg/pr80481.C:
  // { dg-options "-Ofast -funroll-loops -fopenmp -march=knl" }
  // { dg-additional-options "--param vect-epilogues-nomask=0" }
gcc/gcc/testsuite/g++.dg/pr67989.C:
  /* { dg-options "-std=c++11 -O2" } */
  /* { dg-additional-options "-Wno-return-type" } */
gcc/gcc/testsuite/g++.dg/pr81194.C:
  // { dg-options "-O2 -fno-exceptions" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/pr94314-2.C:
  /* { dg-options "-O2 -fdump-tree-cddce-details" } */
  /* { dg-additional-options "-fdelete-null-pointer-checks" } */
gcc/gcc/testsuite/g++.dg/pr94314-3.C:
  /* { dg-options "-O2 --param early-inlining-insns=100 
-fdump-tree-cddce-details" } */
  /* { dg-additional-options "-fdelete-null-pointer-checks" } */
gcc/gcc/testsuite/g++.dg/pr59510.C:
  // { dg-options "-O2 -g --param=large-stack-frame-growth=1" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/pr57662.C:
  /* { dg-options "-O2 -fselective-scheduling2 -fsel-sched-pipelining" } */
  /* { dg-additional-options "-Wno-return-type" } */
gcc/gcc/testsuite/g++.dg/tree-ssa/pr22444.C:
  // { dg-options "-O2" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/tree-ssa/pr27291.C:
  /* { dg-options "-O2" } */
  /* { dg-additional-options "-Wno-return-type" } */
gcc/gcc/testsuite/g++.dg/tree-ssa/pr27283.C:
  /* { dg-options "-O2" } */
  /* { dg-additional-options "-Wno-return-type" } */
gcc/gcc/testsuite/g++.dg/tree-ssa/pr27548.C:
  // { dg-options "-O1" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/tree-ssa/copyprop.C:
  // { dg-options  "-Wno-error -fno-exceptions -fno-tree-vrp -O2 -fprofile-generate  
-finline-limit=500 -std=c++98"  }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/tree-ssa/pr24351-3.C:
  /* { dg-options "-O2" } */
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/tree-ssa/pr42337.C:
  // { dg-options "-O2" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/parse/error5.C:
  // { dg-options "-fshow-column" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/ubsan/pr65583.C:
  // { dg-options "-std=c++11 -fsanitize=undefined" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/opt/dump1.C:
  // { dg-options "-O2 -fno-inline -fdump-final-insns" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/opt/pr82159-2.C:
  // { dg-options "" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/opt/pr44919.C:
  // { dg-options "-O3 -fselective-scheduling2" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/opt/pr47615.C:
  // { dg-options "-O -fstrict-aliasing -ftree-pre -fno-tree-fre -fno-tree-sra" 
}
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/cpp1y/new1.C:
  /* { dg-options "-O2 -fdump-tree-cddce-details" } */
  // { dg-additional-options "-fdelete-null-pointer-checks" }
gcc/gcc/testsuite/g++.dg/cpp1y/new2.C:
  /* { dg-options "-O2 -std=c++17 -fdump-tree-cddce-details" } */
  /* { dg-additional-options "-fdelete-null-pointer-checks" } */
gcc/gcc/testsuite/g++.dg/tm/pr46646.C:
  // { dg-options "-fgnu-tm -O0"}
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/tm/cgraph_edge.C:
  // { dg-options "-fgnu-tm -O3" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/concepts/diagnostic1.C:
  // { dg-options "-fconcepts" }
  // { dg-additional-options "-fconcepts-diagnostics-depth=2" }
gcc/gcc/testsuite/g++.dg/other/pr52048.C:
  // { dg-options "-fcompare-debug -fnon-call-exceptions -fno-tree-dominator-opts 
-O2" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/template/canon-type-8.C:
  // { dg-options "" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/template/crash107.C:
  // { dg-options "" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/template/show-template-tree-3.C:
  // { dg-options "-fdiagnostics-show-template-tree" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/debug/dwarf2/pr61433.C:
  // { dg-options "-O -fcompare-debug -fno-inline -fno-ipa-pure-const 
-fipa-sra" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/init/new18.C:
  // { dg-options "-O2 -fstrict-aliasing" }
  // { dg-additional-options "-Wno-return-type" }
gcc/gcc/testsuite/g++.dg/ipa/pr78211.C:
  // { dg-options 

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Martin Liška]

On 4/14/20 10:37 AM, Jakub Jelinek wrote:

On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote:

+/* PR c++/94314.  */
+/* { dg-do run } */
+/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */
+/* { dg-additional-options "-fdelete-null-pointer-checks" } */


Any reason why you want to do it for -std=c++14 only?


I need at least -std=c++11 for the noexcept keyword. I updated that.


Wouldn't
// PR c++/94314
// { dg-do run { target c++14 } }
// { dg-options "-O2 -fdelete-null-pointer-checks -fdump-tree-cddce-details" }
be better (and no need for dg-additional-options if you have dg-options
already and don't have some effective target on it).


Sure, removed that.




+
+#include 


What do you need stdio.h for?


Likewise here (also for other test-cases).



Otherwise, LGTM, but please give the C++ maintainers time to comment.


Sure.
Martin



Jakub



>From 29626be765eea010f7d1505d08d594844e4518bf Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 9 Apr 2020 15:50:58 +0200
Subject: [PATCH] List valid pairs for new and delete operators.

gcc/ChangeLog:

2020-04-09  Martin Liska  
	Jakub Jelinek  

	PR c++/94314
	* cgraphclones.c (set_new_clone_decl_and_node_flags): Drop
	DECL_IS_REPLACEABLE_OPERATOR during cloning.
	* tree-ssa-dce.c (valid_new_delete_pair_p): New function.
	(propagate_necessity): Check operator names.

gcc/testsuite/ChangeLog:

2020-04-09  Martin Liska  
	Jakub Jelinek  

	PR c++/94314
	* g++.dg/pr94314.C: Do not use dg-additional-options
	and remove not needed stdio.h include.
	* g++.dg/pr94314-2.C: Likewise.
	* g++.dg/pr94314-3.C: Likewise.
	* g++.dg/pr94314-4.C: New test.
---
 gcc/cgraphclones.c   |  2 +
 gcc/testsuite/g++.dg/pr94314-2.C |  5 +-
 gcc/testsuite/g++.dg/pr94314-3.C |  5 +-
 gcc/testsuite/g++.dg/pr94314-4.C | 30 ++
 gcc/testsuite/g++.dg/pr94314.C   |  5 +-
 gcc/tree-ssa-dce.c   | 98 
 6 files changed, 123 insertions(+), 22 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr94314-4.C

diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index c73b8f810f0..8f541a28b6e 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -165,6 +165,7 @@ set_new_clone_decl_and_node_flags (cgraph_node *new_node)
   DECL_STATIC_DESTRUCTOR (new_node->decl) = 0;
   DECL_SET_IS_OPERATOR_NEW (new_node->decl, 0);
   DECL_SET_IS_OPERATOR_DELETE (new_node->decl, 0);
+  DECL_IS_REPLACEABLE_OPERATOR (new_node->decl) = 0;
 
   new_node->externally_visible = 0;
   new_node->local = 1;
@@ -1030,6 +1031,7 @@ cgraph_node::create_version_clone_with_body
   DECL_STATIC_DESTRUCTOR (new_decl) = 0;
   DECL_SET_IS_OPERATOR_NEW (new_decl, 0);
   DECL_SET_IS_OPERATOR_DELETE (new_decl, 0);
+  DECL_IS_REPLACEABLE_OPERATOR (new_decl) = 0;
 
   /* Create the new version's call-graph node.
  and update the edges of the new node. */
diff --git a/gcc/testsuite/g++.dg/pr94314-2.C b/gcc/testsuite/g++.dg/pr94314-2.C
index 36b93ed6d4d..998ce601767 100644
--- a/gcc/testsuite/g++.dg/pr94314-2.C
+++ b/gcc/testsuite/g++.dg/pr94314-2.C
@@ -1,9 +1,6 @@
 /* PR c++/94314.  */
 /* { dg-do run } */
-/* { dg-options "-O2 -fdump-tree-cddce-details" } */
-/* { dg-additional-options "-fdelete-null-pointer-checks" } */
-
-#include 
+/* { dg-options "-O2 -fdump-tree-cddce-details -fdelete-null-pointer-checks" } */
 
 struct A
 {
diff --git a/gcc/testsuite/g++.dg/pr94314-3.C b/gcc/testsuite/g++.dg/pr94314-3.C
index 575ba9d8ad8..846a5d6a3d8 100644
--- a/gcc/testsuite/g++.dg/pr94314-3.C
+++ b/gcc/testsuite/g++.dg/pr94314-3.C
@@ -1,9 +1,6 @@
 /* PR c++/94314.  */
 /* { dg-do run } */
-/* { dg-options "-O2 --param early-inlining-insns=100 -fdump-tree-cddce-details" } */
-/* { dg-additional-options "-fdelete-null-pointer-checks" } */
-
-#include 
+/* { dg-options "-O2 --param early-inlining-insns=100 -fdump-tree-cddce-details -fdelete-null-pointer-checks" } */
 
 volatile int idx;
 
diff --git a/gcc/testsuite/g++.dg/pr94314-4.C b/gcc/testsuite/g++.dg/pr94314-4.C
new file mode 100644
index 000..d097f29d4ad
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr94314-4.C
@@ -0,0 +1,30 @@
+/* PR c++/94314.  */
+/* { dg-do run { target c++11 } } */
+/* { dg-options "-O2 -fdump-tree-cddce-details -fdelete-null-pointer-checks" } */
+
+int count = 0;
+
+__attribute__((malloc, noinline)) void* operator new[](__SIZE_TYPE__ sz) {
+  ++count;
+  return ::operator new(sz);
+}
+
+void operator delete[](void* ptr) noexcept {
+  --count;
+  ::operator delete(ptr);
+}
+
+void operator delete[](void* ptr, __SIZE_TYPE__ sz) noexcept {
+  --count;
+  ::operator delete(ptr, sz);
+}
+
+int main() {
+  delete[] new int[1];
+  if (count != 0)
+__builtin_abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-not "Deleting : operator delete" "cddce1"} } */
diff --git a/gcc/testsuite/g++.dg/pr94314.C b/gcc/testsuite/g++.dg/pr94314.C
index 86e651d10ba..4e5ae122e9f 100644
--- a/gcc/testsuite/g++.dg/pr94314.C
+++ b/gcc/testsuite/g++.dg/pr94314.C
@@ 

[committed] libstdc++: Make comparison category comparisons noexcept (PR 94565)

[Jonathan Wakely via Gcc-patches]

PR libstdc++/94565
* libsupc++/compare (__unspec): Add noexcept-specifier to constructor.
* testsuite/18_support/comparisons/categories/94565.cc: New test.

Tested powerp64le-linux, committed to master.


commit 597601aa7a0f822816041d521fae7da6e883fa7d
Author: Jonathan Wakely 
Date:   Tue Apr 14 11:23:34 2020 +0100

libstdc++: Make comparison category comparisons noexcept (PR 94565)

PR libstdc++/94565
* libsupc++/compare (__unspec): Add noexcept-specifier to 
constructor.
* testsuite/18_support/comparisons/categories/94565.cc: New test.

diff --git a/libstdc++-v3/libsupc++/compare b/libstdc++-v3/libsupc++/compare
index 37601d32648..5f1df19e445 100644
--- a/libstdc++-v3/libsupc++/compare
+++ b/libstdc++-v3/libsupc++/compare
@@ -56,7 +56,7 @@ namespace std
 
 struct __unspec
 {
-  constexpr __unspec(__unspec*) { }
+  constexpr __unspec(__unspec*) noexcept { }
 };
   }
 
diff --git a/libstdc++-v3/testsuite/18_support/comparisons/categories/94565.cc 
b/libstdc++-v3/testsuite/18_support/comparisons/categories/94565.cc
new file mode 100644
index 000..a4c62466a18
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/comparisons/categories/94565.cc
@@ -0,0 +1,66 @@
+// Copyright (C) 2020 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
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+
+#include 
+
+static_assert(noexcept(std::partial_ordering::less == 0));
+static_assert(noexcept(std::partial_ordering::less != 0));
+static_assert(noexcept(std::partial_ordering::less < 0));
+static_assert(noexcept(std::partial_ordering::less > 0));
+static_assert(noexcept(std::partial_ordering::less <= 0));
+static_assert(noexcept(std::partial_ordering::less >= 0));
+static_assert(noexcept(std::partial_ordering::less <=> 0));
+static_assert(noexcept(0 == std::partial_ordering::less));
+static_assert(noexcept(0 != std::partial_ordering::less));
+static_assert(noexcept(0 < std::partial_ordering::less));
+static_assert(noexcept(0 > std::partial_ordering::less));
+static_assert(noexcept(0 <= std::partial_ordering::less));
+static_assert(noexcept(0 >= std::partial_ordering::less));
+static_assert(noexcept(0 <=> std::partial_ordering::less));
+
+static_assert(noexcept(std::weak_ordering::less == 0));
+static_assert(noexcept(std::weak_ordering::less != 0));
+static_assert(noexcept(std::weak_ordering::less < 0));
+static_assert(noexcept(std::weak_ordering::less > 0));
+static_assert(noexcept(std::weak_ordering::less <= 0));
+static_assert(noexcept(std::weak_ordering::less >= 0));
+static_assert(noexcept(std::weak_ordering::less <=> 0));
+static_assert(noexcept(0 == std::weak_ordering::less));
+static_assert(noexcept(0 != std::weak_ordering::less));
+static_assert(noexcept(0 < std::weak_ordering::less));
+static_assert(noexcept(0 > std::weak_ordering::less));
+static_assert(noexcept(0 <= std::weak_ordering::less));
+static_assert(noexcept(0 >= std::weak_ordering::less));
+static_assert(noexcept(0 <=> std::weak_ordering::less));
+
+static_assert(noexcept(std::strong_ordering::less == 0));
+static_assert(noexcept(std::strong_ordering::less != 0));
+static_assert(noexcept(std::strong_ordering::less < 0));
+static_assert(noexcept(std::strong_ordering::less > 0));
+static_assert(noexcept(std::strong_ordering::less <= 0));
+static_assert(noexcept(std::strong_ordering::less >= 0));
+static_assert(noexcept(std::strong_ordering::less <=> 0));
+static_assert(noexcept(0 == std::strong_ordering::less));
+static_assert(noexcept(0 != std::strong_ordering::less));
+static_assert(noexcept(0 < std::strong_ordering::less));
+static_assert(noexcept(0 > std::strong_ordering::less));
+static_assert(noexcept(0 <= std::strong_ordering::less));
+static_assert(noexcept(0 >= std::strong_ordering::less));
+static_assert(noexcept(0 <=> std::strong_ordering::less));

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Iain Sandoe]

Rainer Orth  wrote:


Hi Segher,


On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote:

Unfortunately, several targets have ABI constraints that prevent
an indirect tail-call, which results in the PRs compile error.



diff --git
a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
index 864846e365c..8211e8250ff 100644
---  
a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
+++  
b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C

@@ -1,4 +1,5 @@
-//  { dg-do run }
+// { dg-do run }
+// { dg-xfail-run-if "no indirect tailcall" { { lp64 && {
powerpc64*-linux-gnu } } || { *-*-solaris2* *-*-aix* } } }


lp64 && powerpc*-*-linux (we have biarch compilers :-) )

The problem is not that there is no indirect tailcall; the problem is
that no tailcall can be done to a routine that (potentially) has a
different TOC.

From rs6000_function_ok_for_sibcall:
 Under the AIX or ELFv2 ABIs we can't allow calls to non-local
 functions, because the callee may have a different TOC pointer to
 the caller and there's no way to ensure we restore the TOC when
 we return.


so shouldn't the above be

 lp64 && powerpc*-*-*

instead to cover AIX, too?  Or are there other PowerPC ABIs that don't
have this issue?


Just for once, Darwin (both PPC and X86) has no problem (doesn’t use the TOC
and has a per-function “got”), so that’s one.

Iain

[wwwdocs] Fix inverted option for disabling new feature (PR 94581)

[Jonathan Wakely via Gcc-patches]

Committed as obvious.

Thomas, please fix it if this isn't what you meant to say.

commit 5264b357a424a38ccdcd3af01d67902109218aa8
Author: Jonathan Wakely 
Date:   Tue Apr 14 11:09:43 2020 +0100

Fix inverted option for disabling new feature (PR 94581)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 61c767f4..ca49e626 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -444,7 +444,7 @@ a work-in-progress.
 uses inline packing for arguments instead of calling a library
 routine.  If the source contains a large number of arguments that
 need to be repacked, code size or time for compilation can become
-excessive. If that is the case, -finline-arg-packing
+excessive. If that is the case, -fno-inline-arg-packing
 can be used to disable inline argument packing.
   
   

Re: [PATCH][PR target/94542]Don't allow PC-relative addressing for TLS data

[Segher Boessenkool]

Hi!

On Fri, Apr 10, 2020 at 06:00:45PM -0500, acsawdey wrote:
> One of the things that address_to_insn_form() is used for is determining 
> whether a PC-relative addressing instruction could be used. In 
> particular predicate pcrel_external_address and function 
> prefixed_paddi_p() both use it for this purpose. So what emerged in 
> PR/94542 is that it should be looking to see if the associated 
> symbol_ref is a TLS symbol of some kind. TLS symbols cannot be addressed 
> with PC-relative. This patch fixes both places in address_to_insn_form() 
> where it is looking at a symbol_ref.

> 2020-04-10  Aaron Sawdey  
> 
>   PR target/94542
>   * config/rs6000/rs6000.c (address_to_insn_form): Do not attempt to
>   use PC-relative addressing for TLS references.

> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 2b6613bcb7e..c77e60a718f 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -24824,15 +24824,21 @@ address_to_insn_form (rtx addr,
>if (GET_RTX_CLASS (GET_CODE (addr)) == RTX_AUTOINC)
>  return INSN_FORM_UPDATE;
>  
> -  /* Handle PC-relative symbols and labels.  Check for both local and 
> external
> - symbols.  Assume labels are always local.  */
> +  /* Handle PC-relative symbols and labels.  Check for both local and
> + external symbols.  Assume labels are always local. TLS symbols
> + are not PC-relative.  */

(Two spaces after dot).

As Will says, "... for rs6000." won't hurt.

Okay for trunk.  Thanks!


Segher

[PATCH]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

[Andrea Corallo]

Hi all,

Testing the backport of pr94530 fix (af19e4d0e23e) to GCC 9 I realized
this is not entirely correct.

aarch64_classify_address sets the base field of struct
aarch64_address_info for all aarch64_address_type with the exception
of ADDRESS_SYMBOLIC.  In this case we would access an uninitialized
value.  The attached patch fixes the issue.

Bootstraped on aarch64 and regressioned.  Okay for trunk?

I've also tested af19e4d0e23e + the current patch rebased on on top of
the gcc-9 branch.  Okay to backport?

Andrea

PS I'm wondering if would be good also to always set the addr field in
aarch64_classify_address for safeness.

gcc/ChangeLog

2020-??-??  Andrea Corallo  

* config/aarch64/falkor-tag-collision-avoidance.c
(valid_src_p): Check for aarch64_address_info type before
accessing base field.
>From 4af5bb32cd88bb4e65591207839fb0e276b2eb23 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Thu, 9 Apr 2020 15:34:50 +0100
Subject: [PATCH] pr94530 2

---
 gcc/config/aarch64/falkor-tag-collision-avoidance.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/aarch64/falkor-tag-collision-avoidance.c b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
index f850153fae02..fb56ff66bfab 100644
--- a/gcc/config/aarch64/falkor-tag-collision-avoidance.c
+++ b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
@@ -538,7 +538,7 @@ valid_src_p (rtx src, rtx_insn *insn, struct loop *loop, bool *pre_post,
   if (!aarch64_classify_address (, XEXP (x, 0), mode, true))
 return false;
 
-  if (!REG_P (addr.base))
+  if (addr.type == ADDRESS_SYMBOLIC || !REG_P (addr.base))
 return false;
 
   unsigned regno = REGNO (addr.base);
-- 
2.17.1

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Rainer Orth]

Hi Segher,

> On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote:
>> Unfortunately, several targets have ABI constraints that prevent
>> an indirect tail-call, which results in the PRs compile error.
>
>> diff --git
>> a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>> b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>> index 864846e365c..8211e8250ff 100644
>> --- a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>> +++ b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>> @@ -1,4 +1,5 @@
>> -//  { dg-do run }
>> +// { dg-do run }
>> +// { dg-xfail-run-if "no indirect tailcall" { { lp64 && {
>> powerpc64*-linux-gnu } } || { *-*-solaris2* *-*-aix* } } }
>
> lp64 && powerpc*-*-linux (we have biarch compilers :-) )
>
> The problem is not that there is no indirect tailcall; the problem is
> that no tailcall can be done to a routine that (potentially) has a
> different TOC.
>
> From rs6000_function_ok_for_sibcall:
>   Under the AIX or ELFv2 ABIs we can't allow calls to non-local
>   functions, because the callee may have a different TOC pointer to
>   the caller and there's no way to ensure we restore the TOC when
>   we return.

so shouldn't the above be

  lp64 && powerpc*-*-*

instead to cover AIX, too?  Or are there other PowerPC ABIs that don't
have this issue?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Segher Boessenkool]

Hi!

On Sat, Apr 11, 2020 at 03:46:18PM +0100, Iain Sandoe wrote:
> Unfortunately, several targets have ABI constraints that prevent
> an indirect tail-call, which results in the PRs compile error.

> diff --git 
> a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C 
> b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
> index 864846e365c..8211e8250ff 100644
> --- a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
> +++ b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
> @@ -1,4 +1,5 @@
> -//  { dg-do run }
> +// { dg-do run }
> +// { dg-xfail-run-if "no indirect tailcall" { { lp64 && { 
> powerpc64*-linux-gnu } } || { *-*-solaris2* *-*-aix* } } }

lp64 && powerpc*-*-linux (we have biarch compilers :-) )

The problem is not that there is no indirect tailcall; the problem is
that no tailcall can be done to a routine that (potentially) has a
different TOC.

>From rs6000_function_ok_for_sibcall:
  Under the AIX or ELFv2 ABIs we can't allow calls to non-local
  functions, because the callee may have a different TOC pointer to
  the caller and there's no way to ensure we restore the TOC when
  we return.


Segher

Re: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

[Richard Biener via Gcc-patches]

On Tue, Apr 14, 2020 at 11:05 AM xiezhiheng  wrote:
>
> > -Original Message-
> > From: Richard Biener [mailto:richard.guent...@gmail.com]
> > Sent: Tuesday, April 14, 2020 4:39 PM
> > To: xiezhiheng 
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp
> > instructions emitted at -O3
> >
> > On Mon, Apr 13, 2020 at 8:48 AM xiezhiheng 
> > wrote:
> > >
> > > Ping for:
> > > 
> >
> > This is definitely stage1 material.
>
> OK, thanks for the reply. I was thinking that this is 10 perf regression 
> issue.

Yeah, but we're close to GCC 10 and the actual fix has a broader impact
that just fixing this particular regression - it fundamentally changes where
fwprop propgates to.

> Now let's wait for GCC 11 to solve it.
>
> Xie Zhiheng
>
> >
> > Richard.
> >
> > > Xie Zhiheng
> > >
> > >
>

*ping* Re: [Patch][Fortran] Fix name conflict check for use-assoc (PR 92736)

[Tobias Burnus]

*ping*

On 4/8/20 12:44 PM, Tobias Burnus wrote:

Hi all,

this issue only occurs when use associating a symbol in a module
and then again use-associating the same symbol in its submodule.

If one simply uses
   use m, only: i
   use m, only: i
the issue does not occur as all symbols are only created after
parsing all use statements.

And for
   use m, only: i
contains
   subroutine sub()
 use m, only: i
one has different gfc_namespaces such that they cannot conflict.

This is a GCC 9 + mainline/10 regression, hence:
OK for those two branches?

Tobias


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

RE: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

[xiezhiheng]

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, April 14, 2020 4:39 PM
> To: xiezhiheng 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp
> instructions emitted at -O3
> 
> On Mon, Apr 13, 2020 at 8:48 AM xiezhiheng 
> wrote:
> >
> > Ping for:
> > 
> 
> This is definitely stage1 material.

OK, thanks for the reply. I was thinking that this is 10 perf regression issue.
Now let's wait for GCC 11 to solve it.

Xie Zhiheng

> 
> Richard.
> 
> > Xie Zhiheng
> >
> >

Re: [PATCH PR94574] ICE during GIMPLE pass: ccp

[Richard Biener via Gcc-patches]

On Mon, Apr 13, 2020 at 11:38 AM yangyang (ET)  wrote:
>
> Hi,
>
>   This is a simple fix for pr94574.
>
>   testcase testsuite/gcc.target/aarch64/sve/acle/general/deref_1.c ICEs when 
> testing GCC trunk with -O2 -msve-vector-bits=256 -march=armv8.2-a+sve.
>
>   There is a gimple statement before the ccp pass as follow:
>
>   MEM[(svuint32_t *)] = _2;
>
>   The ccp pass tries to convert this gimple into:
>
>   _7 = VIEW_CONVERT_EXPR(_2);
>   res_9 = BIT_INSERT_EXPR ;
>
>   However,  the size of _7 is larger than res_8(D) , leading to a 
> verify_gimple failure. Since the replaced bits of BIT_INSERT_EXPR are 
> supposed to fully inside the container, before doing the above optimitzaion, 
> a check shall be added.
>
>   With this fix, a MEM_REF which visits the address of a vector will be 
> rewritten into a BIT_INSERT_EXPR only when the size of the vector is larger 
> than the size of MEM_REF. In this way, this kind of ICE can be avoided.
>
>   a test case with which this problem will be exposed more easily is 
> extracted and added for this. Bootstrapped/regtested on both x86_64 and 
> aarch64 Linux platform.
>   Any suggestion?

OK.

Thanks,
Richard.

> Thanks,
> Yang Yang
>
> gcc:
> +2020-04-13  Yang Yang  
> +
> +   PR tree-optimization/94574
> +   * tree-ssa.c (non_rewritable_lvalue_p): Add size check when analyzing
> +   whether a vector-insert is rewritable using a BIT_INSERT_EXPR.
>
> gcc/testsuite:
> +2020-04-13  Yang Yang 
> +
> +   PR tree-optimization/94574
> +   * gcc.dg/pr94574.c: New test.

Re: [PATCH 3/5] testsuite: [arm/mve] Fix mve_move_gpr_to_gpr.c

[Andre Vieira (lists)]

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:

This test can pass with a hard-float toolchain, provided we don't
force -mfloat-abi=softfp.

This patch removes this useless option, as well as -save-temps which
is implied by arm_v8_1m_mve_fp.

Hi Christophe,

LGTM, but you need to wait for maintainer approval.

Cheers,
Andre


2020-04-10  Christophe Lyon  

gcc/tesuite/
* gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c: Remove
useless options.
---
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
index 374bc4d..53300e5 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_move_gpr_to_gpr.c
@@ -1,6 +1,6 @@
  /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
  /* { dg-add-options arm_v8_1m_mve_fp } */
-/* { dg-additional-options "-O2 -mfloat-abi=softfp --save-temps" } */
+/* { dg-additional-options "-O2" } */
  
  #include "arm_mve.h"
  

Re: [PATCH 5/5] testsuite: [arm/mve] Include arm_mve.h in arm_v8_1m_mve_ok

[Andre Vieira (lists)]

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:

Since arm_mve.h includes stdint.h, its use requires the presence of
the right gnu/stub-*.h, so make sure to include it when checking the
arm_v8_1m_mve_ok_nocache effective target, otherwise we can decide MVE
is supported while it's not really. This makes several tests
unsupported rather than fail.

Hi Christophe,

LGTM, but you need to wait for maintainer approval.

Cheers,
Andre


2020-04-10  Christophe Lyon  

gcc/testsuite/
* lib/target-supports.exp
(check_effective_target_arm_v8_1m_mve_ok_nocache): Include
arm_mve.h.
---
  gcc/testsuite/lib/target-supports.exp | 1 +
  1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 6c8dd01..d16498d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -4965,6 +4965,7 @@ proc check_effective_target_arm_v8_1m_mve_ok_nocache { } {
#if __ARM_BIG_ENDIAN
#error "MVE intrinsics are not supported in Big-Endian mode."
#endif
+   #include 
  } "$flags -mthumb"] } {
  set et_arm_v8_1m_mve_flags "$flags -mthumb --save-temps"
  return 1

Re: [PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

[Richard Biener via Gcc-patches]

On Mon, Apr 13, 2020 at 8:48 AM xiezhiheng  wrote:
>
> Ping for:
> 

This is definitely stage1 material.

Richard.

> Xie Zhiheng
>
>
> > -Original Message-
> > From: xiezhiheng
> > Sent: Thursday, April 2, 2020 2:35 PM
> > To: 'gcc-patches@gcc.gnu.org' 
> > Subject: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted
> > at -O3
> >
> > Hi,
> >   I've created a bug for this issue:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442
> >
> >   And I'm going to solve this problem by propagating def's insn to its use
> >   when they are at the same loop in fwprop pass.
> >   I mean something like:
> > diff --git a/gcc/fwprop.c b/gcc/fwprop.c
> > index 705d2885aae..0edbbc65047 100644
> > --- a/gcc/fwprop.c
> > +++ b/gcc/fwprop.c
> > @@ -416,7 +416,7 @@ should_replace_address (rtx old_rtx, rtx new_rtx,
> > machine_mode mode,
> >  gain = (set_src_cost (new_rtx, VOIDmode, speed)
> > - set_src_cost (old_rtx, VOIDmode, speed));
> >
> > -  return (gain > 0);
> > +  return (gain >= 0);
> >  }
> >
> >
> > @@ -1573,10 +1573,14 @@ fwprop (bool fwprop_addr_p)
> >df_ref use = DF_USES_GET (i);
> >if (use)
> > {
> > + df_ref def = get_def_for_use (use);
> >   if (DF_REF_TYPE (use) == DF_REF_REG_USE
> >   || DF_REF_BB (use)->loop_father == NULL
> >   /* The outer most loop is not really a loop.  */
> > - || loop_outer (DF_REF_BB (use)->loop_father) == NULL)
> > + || loop_outer (DF_REF_BB (use)->loop_father) == NULL
> > + || (def && (DF_REF_BB (def)->loop_father == DF_REF_BB
> > (use)->loop_father
> > + || flow_loop_nested_p
> > (DF_REF_BB(use)->loop_father,
> > +
> > DF_REF_BB(def)->loop_father
> > forward_propagate_into (use, fwprop_addr_p);
> >
> >   else if (fwprop_addr_p)
> >
> > Any suggestions?
> >
> > Best regards
> > Xie Zhiheng

Re: [PATCH 4/5] testsuite: [arm/mve] Use dg-add-options arm_v8_1m_mve in MVE tests

[Andre Vieira (lists)]

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:

Several ARM/MVE tests can be compiled even if the toolchain does not
support -mfloat-abi=hard (softfp is OK).

Use dg-add-options arm_v8_1m_mve or arm_v8_1m_mve_fp instead of using
dg-additional-options.

Hi Christophe,

I think a bunch of these tests were initially meant to test hard float 
abi with vectors, especially in the MVE integer cases, this is what the 
scan-assemblers are meant to test. However, it seems to pass for 
float-abi=softfp too ... which means these tests don't really mean 
anything. I think it would be good to remove the scan-assembler tests 
for now and improve these tests later with run tests, or some smarter 
function body testing.


I suggest we apply your changes and I can follow up with a patch to 
remove the scan-assemblers for now, if a maintainer agrees with me that is.


Cheers,
Andre

2020-04-10  Christophe Lyon  

gcc/testsuite/
* gcc.target/arm/mve/intrinsics/mve_vector_float.c: Use
arm_v8_1m_mve_fp.
* gcc.target/arm/mve/intrinsics/mve_vector_float1.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_float2.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_int.c: Use
arm_v8_1m_mve.
* gcc.target/arm/mve/intrinsics/mve_vector_int1.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_int2.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_uint.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_uint1.c: Likewise.
* gcc.target/arm/mve/intrinsics/mve_vector_uint2.c: Likewise.
---
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c  | 2 +-
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c | 2 +-
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c | 2 +-
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c| 2 +-
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int1.c   | 2 +-
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int2.c   | 2 +-
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint.c   | 2 +-
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint1.c  | 2 +-
  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_uint2.c  | 2 +-
  9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
index 881157f..6519b81 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float.c
@@ -1,6 +1,6 @@
  /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
{""} } */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
  
  #include "arm_mve.h"
  
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c

index 9515ed6..855e3b8 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float1.c
@@ -1,6 +1,6 @@
  /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
{""} } */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
  
  #include "arm_mve.h"
  
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c

index 3ce8ea3..e3cf8f8 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_float2.c
@@ -1,6 +1,6 @@
  /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
{""} } */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfpu=auto 
-mfloat-abi=hard -mthumb --save-temps" } */
  
  #include "arm_mve.h"
  
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c

index dab0705..e70cbc1 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vector_int.c
@@ -1,6 +1,6 @@
  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
{""} } */
-/* { dg-additional-options "-march=armv8.1-m.main+mve -mfpu=auto -mfloat-abi=hard 
-mthumb --save-temps" } */
  
  #include "arm_mve.h"
  
diff --git 

Re: [PATCH 1/5] testsuite: [arm] Add arm_softfp_ok and arm_hard_ok effective targets.

[Andre Vieira (lists)]

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:

For arm-linux-gnueabi* targets, a toolchain cannot support the
float-abi opposite to the one it has been configured for: since glibc
does not support such multilibs, we end up lacking gnu/stubs-*.h when
including stdint.h for instance.

This patch introduces two new effective targets to detect whether we
can compile tests with -mfloat-abi=softfp or -mfloat-abi=hard.

This enables to make such tests unsupported rather than fail.

Hi Christophe,

LGTM, but you need to wait for maintainer approval.

Cheers,
Andre

2020-04-10  Christophe Lyon  

gcc/testsuite/
* lib/target-supports.exp (arm_softfp_ok): New effective target.
(arm_hard_ok): Likewise.
---
  gcc/testsuite/lib/target-supports.exp | 20 
  1 file changed, 20 insertions(+)

diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 3758bb3..6c8dd01 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -4739,6 +4739,26 @@ proc check_effective_target_default_branch_protection { 
} {
  return [check_configured_with "enable-standard-branch-protection"]
  }
  
+# Return 1 if this is an ARM target supporting -mfloat-abi=softfp.

+
+proc check_effective_target_arm_softfp_ok { } {
+return [check_no_compiler_messages arm_softfp_ok object {
+   #include 
+   int dummy;
+   int main (void) { return 0; }
+   } "-mfloat-abi=softfp"]
+}
+
+# Return 1 if this is an ARM target supporting -mfloat-abi=hard.
+
+proc check_effective_target_arm_hard_ok { } {
+return [check_no_compiler_messages arm_hard_ok object {
+   #include 
+   int dummy;
+   int main (void) { return 0; }
+   } "-mfloat-abi=hard"]
+}
+
  # Return 1 if the target supports ARMv8.1-M MVE with floating point
  # instructions, 0 otherwise.  The test is valid for ARM.
  # Record the command line options needed.

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Jakub Jelinek via Gcc-patches]

On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote:
> +/* PR c++/94314.  */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */
> +/* { dg-additional-options "-fdelete-null-pointer-checks" } */

Any reason why you want to do it for -std=c++14 only?
Wouldn't
// PR c++/94314
// { dg-do run { target c++14 } }
// { dg-options "-O2 -fdelete-null-pointer-checks -fdump-tree-cddce-details" }
be better (and no need for dg-additional-options if you have dg-options
already and don't have some effective target on it).

> +
> +#include 

What do you need stdio.h for?

Otherwise, LGTM, but please give the C++ maintainers time to comment.

Jakub

Re: [PATCH] ipa-sra: Fix treatment of internal functions (PR 94434)

[Richard Biener via Gcc-patches]

On Thu, Apr 9, 2020 at 7:57 PM Martin Jambor  wrote:
>
> Hi,
>
> On Tue, Apr 07 2020, bule wrote:
> > Hi,
> >
> > The patch is tested and works fine. It is more appropriate to handle
> > the context by considering it as a section of assemble code.
> >
> > A minor question is that I think svst functions are for store
> >operations. Why pass ISRA_CTX_LOAD to scan_expr_access rather than
> >ISRA_CTX_STORE?
> >
>
> That's a good point, I did not immediately realize that these were
> writes.  IPA-SRA really distinguishes between reads and writes only when
> it comes to parameters passed by reference but I agree that we should
> not lie to the bit of the compiler (if we can avoid it :-).
>
> Therefore I'd like to fix this issue with the patch below.  I'd
> encourage anyone with experience with adding SVE testcases to add one
> specifically for this.

OK.

Richard.

> Thanks,
>
> Martin
>
>
> ipa-sra: Fix treatment of internal functions (PR 94434)
>
> IPA-SRA can segfault when processing a coll to an internal function
> because such calls do not have corresponding call graphs and should be
> treated like memory accesses anyway, which what the patch below does.
>
> The patch makes an attempt to differentiate between reads and writes,
> although for things passed by value it does not make any difference.  It
> treats all arguments of functions denoted with internal_store_fn_p as
> written to, even though in practice only some are, but for IPA-SRA
> purposes, actions needed to be taken when processing a read are also
> always performed when analyzing a write, so the code is just slightly
> pessimistic.  But not as pessimistic as bailing out on any internal call
> immediately.
>
> I have LTO bootstrapped and tested the patch on x86_64-linux and
> normally bootstrapped and tested it on aarch64-linux, although one
> which is not SVE capable.  I would appreciate testing on such machine
> too - as well as a small testcase that would follow all relevant
> conventions in gcc.target/aarch64/sve.
>
> OK for trunk?
>
>
> 2020-04-09  Martin Jambor  
>
> PR ipa/94434
> * ipa-sra.c: Include internal-fn.h.
> (enum isra_scan_context): Update comment.
> (scan_function): Treat calls to internal_functions like loads or 
> stores.
> ---
>  gcc/ChangeLog |  7 +++
>  gcc/ipa-sra.c | 26 --
>  2 files changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index e10fb251c16..a838634b707 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,10 @@
> +2020-04-09  Martin Jambor  
> +
> +   PR ipa/94434
> +   * ipa-sra.c: Include internal-fn.h.
> +   (enum isra_scan_context): Update comment.
> +   (scan_function): Treat calls to internal_functions like loads or 
> stores.
> +
>  2020-04-05 Zachary Spytz  
>
> * extend.texi: Add free to list of ISO C90 functions that
> diff --git a/gcc/ipa-sra.c b/gcc/ipa-sra.c
> index f0ebaec708d..7c922e40a4e 100644
> --- a/gcc/ipa-sra.c
> +++ b/gcc/ipa-sra.c
> @@ -83,7 +83,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "builtins.h"
>  #include "cfganal.h"
>  #include "tree-streamer.h"
> -
> +#include "internal-fn.h"
>
>  /* Bits used to track size of an aggregate in bytes interprocedurally.  */
>  #define ISRA_ARG_SIZE_LIMIT_BITS 16
> @@ -1281,7 +1281,9 @@ allocate_access (gensum_param_desc *desc,
>  }
>
>  /* In what context scan_expr_access has been called, whether it deals with a
> -   load, a function argument, or a store.  */
> +   load, a function argument, or a store.  Please note that in rare
> +   circumstances when it is not clear if the access is a load or store,
> +   ISRA_CTX_STORE is used too.  */
>
>  enum isra_scan_context {ISRA_CTX_LOAD, ISRA_CTX_ARG, ISRA_CTX_STORE};
>
> @@ -1870,15 +1872,27 @@ scan_function (cgraph_node *node, struct function 
> *fun)
> case GIMPLE_CALL:
>   {
> unsigned argument_count = gimple_call_num_args (stmt);
> -   scan_call_info call_info;
> -   call_info.cs = node->get_edge (stmt);
> -   call_info.argument_count = argument_count;
> +   isra_scan_context ctx = ISRA_CTX_ARG;
> +   scan_call_info call_info, *call_info_p = _info;
> +   if (gimple_call_internal_p (stmt))
> + {
> +   call_info_p = NULL;
> +   ctx = ISRA_CTX_LOAD;
> +   internal_fn ifn = gimple_call_internal_fn (stmt);
> +   if (internal_store_fn_p (ifn))
> + ctx = ISRA_CTX_STORE;
> + }
> +   else
> + {
> +   call_info.cs = node->get_edge (stmt);
> +   call_info.argument_count = argument_count;
> + }
>
> for (unsigned i = 0; i < argument_count; i++)
>   {
> call_info.arg_idx = i;
> 

Re: [PATCH 2/5] testsuite: [arm/mve] Use arm_softfp and arm_hard as needed in MVE tests

[Andre Vieira (lists)]

On 10/04/2020 14:55, Christophe Lyon via Gcc-patches wrote:

Some MVE tests explicitly test a -mfloat-abi=hard option, but we need
to check that the toolchain actually supports it (which may not be the
case for arm-linux-gnueabi* targets).

We also make use of dg-add-options arm_v8_1m_mve_fp and arm_v8_1m_mve
instead of duplicating the corresponding options in
dg-additional-options where we keep only -mfloat-abi to override the
option selected by arm_v8_1m_mve_fp.

Hi Christophe,

This sounds good!! Thank you for doing this.

diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
index 1462dd4..0fa3afd 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu1.c
@@ -1,6 +1,8 @@
  /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-require-effective-target arm_hard_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
{""} } */

I was wondering, do we still need the skip-if with the arm_hard_ok?

-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfloat-abi=hard -mthumb 
-mfpu=auto --save-temps" } */
+/* { dg-additional-options "-mfloat-abi=hard" } */
  
  #include "arm_mve.h"
  
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c

index d528133..1fca110 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fp_fpu2.c
@@ -1,5 +1,7 @@
  /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
-/* { dg-additional-options "-march=armv8.1-m.main+mve.fp -mfloat-abi=softfp -mthumb 
-mfpu=auto --save-temps" } */
+/* { dg-require-effective-target arm_softfp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+/* { dg-additional-options "-mfloat-abi=softfp" } */
  
  #include "arm_mve.h"
  
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c

index 59ca724..726f9ec 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu1.c
@@ -1,6 +1,8 @@
  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-require-effective-target arm_hard_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
{""} } */

Same here.

-/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard -mthumb 
-mfpu=auto --save-temps" } */
+/* { dg-additional-options "-mfloat-abi=hard" } */
  
  #include "arm_mve.h"
  
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c

index ce297ea..7f39905 100644
--- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_fpu2.c
@@ -1,6 +1,8 @@
  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-require-effective-target arm_softfp_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
{""} } */

And here.

-/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=softfp -mthumb 
-mfpu=auto --save-temps" } */
+/* { dg-additional-options "-mfloat-abi=softfp" } */
  
  #include "arm_mve.h"
  

LGTM.

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Martin Liška]

On 4/14/20 9:09 AM, Martin Liška wrote:

I've updated a bit the Jakub's patch.


I forgot to remove valid_pairs data structure, fixed here.

Martin
>From fb093e29d013ce0ce8e9181bd10635d14a48bcd2 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 9 Apr 2020 15:50:58 +0200
Subject: [PATCH] List valid pairs for new and delete operators.

gcc/ChangeLog:

2020-04-09  Martin Liska  
	Jakub Jelinek  

	PR c++/94314
	* cgraphclones.c (set_new_clone_decl_and_node_flags): Drop
	DECL_IS_REPLACEABLE_OPERATOR during cloning.
	* tree-ssa-dce.c (valid_new_delete_pair_p): New function.
	(propagate_necessity): Check operator names.

gcc/testsuite/ChangeLog:

2020-04-09  Martin Liska  
	Jakub Jelinek  

	PR c++/94314
	* g++.dg/pr94314-4.C: New test.
---
 gcc/cgraphclones.c   |  2 +
 gcc/testsuite/g++.dg/pr94314-4.C | 33 +++
 gcc/tree-ssa-dce.c   | 98 
 3 files changed, 123 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr94314-4.C

diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index c73b8f810f0..8f541a28b6e 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -165,6 +165,7 @@ set_new_clone_decl_and_node_flags (cgraph_node *new_node)
   DECL_STATIC_DESTRUCTOR (new_node->decl) = 0;
   DECL_SET_IS_OPERATOR_NEW (new_node->decl, 0);
   DECL_SET_IS_OPERATOR_DELETE (new_node->decl, 0);
+  DECL_IS_REPLACEABLE_OPERATOR (new_node->decl) = 0;
 
   new_node->externally_visible = 0;
   new_node->local = 1;
@@ -1030,6 +1031,7 @@ cgraph_node::create_version_clone_with_body
   DECL_STATIC_DESTRUCTOR (new_decl) = 0;
   DECL_SET_IS_OPERATOR_NEW (new_decl, 0);
   DECL_SET_IS_OPERATOR_DELETE (new_decl, 0);
+  DECL_IS_REPLACEABLE_OPERATOR (new_decl) = 0;
 
   /* Create the new version's call-graph node.
  and update the edges of the new node. */
diff --git a/gcc/testsuite/g++.dg/pr94314-4.C b/gcc/testsuite/g++.dg/pr94314-4.C
new file mode 100644
index 000..afa2a443dc4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr94314-4.C
@@ -0,0 +1,33 @@
+/* PR c++/94314.  */
+/* { dg-do run } */
+/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */
+/* { dg-additional-options "-fdelete-null-pointer-checks" } */
+
+#include 
+
+int count = 0;
+
+__attribute__((malloc, noinline)) void* operator new[](__SIZE_TYPE__ sz) {
+  ++count;
+  return ::operator new(sz);
+}
+
+void operator delete[](void* ptr) noexcept {
+  --count;
+  ::operator delete(ptr);
+}
+
+void operator delete[](void* ptr, __SIZE_TYPE__ sz) noexcept {
+  --count;
+  ::operator delete(ptr, sz);
+}
+
+int main() {
+  delete[] new int[1];
+  if (count != 0)
+__builtin_abort ();
+
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-not "Deleting : operator delete" "cddce1"} } */
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index fd5f24c746c..757cfad5b5e 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -646,6 +646,77 @@ degenerate_phi_p (gimple *phi)
   return true;
 }
 
+/* Return that NEW_CALL and DELETE_CALL are a valid pair of new
+   and delete  operators.  */
+
+static bool
+valid_new_delete_pair_p (gimple *new_call, gimple *delete_call)
+{
+  tree new_asm = DECL_ASSEMBLER_NAME (gimple_call_fndecl (new_call));
+  tree delete_asm = DECL_ASSEMBLER_NAME (gimple_call_fndecl (delete_call));
+  const char *new_name = IDENTIFIER_POINTER (new_asm);
+  const char *delete_name = IDENTIFIER_POINTER (delete_asm);
+  unsigned int new_len = IDENTIFIER_LENGTH (new_asm);
+  unsigned int delete_len = IDENTIFIER_LENGTH (delete_asm);
+
+  if (new_len < 5 || delete_len < 6)
+return false;
+  if (new_name[0] == '_')
+++new_name, --new_len;
+  if (new_name[0] == '_')
+++new_name, --new_len;
+  if (delete_name[0] == '_')
+++delete_name, --delete_len;
+  if (delete_name[0] == '_')
+++delete_name, --delete_len;
+  if (new_len < 4 || delete_len < 5)
+return false;
+  /* *_len is now just the length after initial underscores.  */
+  if (new_name[0] != 'Z' || new_name[1] != 'n')
+return false;
+  if (delete_name[0] != 'Z' || delete_name[1] != 'd')
+return false;
+  /* _Znw must match _Zdl, _Zna must match _Zda.  */
+  if ((new_name[2] != 'w' || delete_name[2] != 'l')
+  && (new_name[2] != 'a' || delete_name[2] != 'a'))
+return false;
+  /* 'j', 'm' and 'y' correspond to size_t.  */
+  if (new_name[3] != 'j' && new_name[3] != 'm' && new_name[3] != 'y')
+return false;
+  if (delete_name[3] != 'P' || delete_name[4] != 'v')
+return false;
+  if (new_len == 4
+  || (new_len == 18 && !memcmp (new_name + 4, "RKSt9nothrow_t", 14)))
+{
+  /* _ZnXY or _ZnXYRKSt9nothrow_t matches
+	 _ZdXPv, _ZdXPvY and _ZdXPvRKSt9nothrow_t.  */
+  if (delete_len == 5)
+	return true;
+  if (delete_len == 6 && delete_name[5] == new_name[3])
+	return true;
+  if (delete_len == 19 && !memcmp (delete_name + 5, "RKSt9nothrow_t", 14))
+	return true;
+}
+  else if ((new_len == 19 && !memcmp (new_name + 4, "St11align_val_t", 

Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Martin Liška]

On 4/10/20 11:17 AM, Jakub Jelinek wrote:

On Fri, Apr 10, 2020 at 10:29:29AM +0200, Martin Liška wrote:

+/* Valid pairs of new and delete operators for DCE.  */
+static hash_set *valid_pairs = NULL;
+
+/* Return that NEW_CALL and DELETE_CALL are a valid pair of new
+   and delete  operators.  */
+
+static bool
+valid_new_delete_pair_p (gimple *new_call, gimple *delete_call)
+{
+  const char *new_name
+= IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (gimple_call_fndecl (new_call)));
+  const char *delete_name
+= IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (gimple_call_fndecl 
(delete_call)));
+
+  if (new_name[0] == '_' and new_name[1] == '_')
+++new_name;
+  if (delete_name[0] == '_' and delete_name[1] == '_')
+++delete_name;
+
+  char *needle = concat (new_name, ":", delete_name, NULL);
+
+  if (valid_pairs == NULL)
+{
+  valid_pairs = new hash_set ();
+  /* Invalid pairs:
+non-[] and []
+aligned and non-aligned
+  */
+
+  const char *pairs[] = {
+ /* non-[] operators.  */
+ "_Znwm:_ZdlPv" ,
+ "_Znwm:_ZdlPvm" ,


Formatting, I think the /* and "_Z should be two columns from const char,
and no space before ,
Not sure I like using the : and using a hash table looks like an overkill to
me, don't we have only 8 options, and most of them with different identifier
lengths?  The concat itself will take a while...
And, what's worse, the m in there is really different on different targets.
It can be j, m or y depending on what fundamental type size_t is.

So why not (completely untested):


Hi.

I've updated a bit the Jakub's patch.

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

Ready to be installed?
Thanks,
Martin



static bool
valid_new_delete_pair_p (gimple *new_call, gimple *delete_call)
{
   tree new_asm = DECL_ASSEMBLER_NAME (gimple_call_fndecl (new_call));
   tree delete_asm = DECL_ASSEMBLER_NAME (gimple_call_fndecl (delete_call));
   const char *new_name = IDENTIFIER_POINTER (new_asm);
   const char *delete_name = IDENTIFIER_POINTER (delete_asm);
   unsigned int new_len = IDENTIFIER_LENGTH (mew_asm);
   unsigned int delete_len = IDENTIFIER_LENGTH (delete_asm);
   if (new_name < 5 || delete_len < 6)
 return false;
   if (new_name[0] == '_')
 ++new_name, --new_len;
   if (new_name[0] == '_')
 ++new_name, --new_len;
   if (delete_name[0] == '_')
 ++delete_name, --delete_len;
   if (delete_name[0] == '_')
 ++delete_name, --delete_len;
   if (new_len < 4 || delete_len < 5)
 return false;
   /* *_len is now just the length after initial underscores.  */
   if (new_name[0] != 'Z' || new_name[1] != 'n')
 return false;
   if (delete_name[0] != 'Z' || delete_name[1] != 'd')
 return false;
   /* _Znw must match _Zdl, _Zna must match _Zda.  */
   if ((new_name[2] != 'w' || delete_name[2] != 'l')
   && (new_name[2] != 'a' || delete_name[2] != 'a'))
 return false;
   if (new_name[3] != 'j' && new_name[3] != 'm' && new_name[3] != 'y')
 return false;
   if (delete_name[3] != 'P' || delete_name[4] != 'v')
 return false;
   if (new_len == 4
   || (new_len == 18 && !memcmp (new_name + 4, "RKSt9nothrow_t", 14)))
 {
   /* _ZnXY or _ZnXYRKSt9nothrow_t matches
 _ZdXPv, _ZdXPvY and _ZdXPvRKSt9nothrow_t.  */
   if (delete_len == 5)
return true;
   if (delete_len == 6 && delete_name[5] == new_name[3])
return true;
   if (delete_len == 19 && !memcmp (delete_name + 5, "RKSt9nothrow_t", 14))
return true;
 }
   else if ((new_len == 19 && !memcmp (new_name + 4, "St11align_val_t", 15))
   || (new_len == 33
   && !memcmp (new_name + 4, "St11align_val_tRKSt9nothrow_t", 29)))
 {
   /* _ZnXYSt11align_val_t or _ZnXYSt11align_val_tRKSt9nothrow_t matches
 _ZdXPvSt11align_val_t or _ZdXPvYSt11align_val_t or  or
 _ZdXPvSt11align_val_tRKSt9nothrow_t.  */
   if (delete_len == 20 && !memcmp (delete_name + 5, "St11align_val_t", 15))
return true;
   if (delete_len == 21
  && delete_name[5] == new_name[3]
  && !memcmp (delete_name + 6, "St11align_val_t", 15))
return true;
   if (delete_len == 34
  && !memcmp (delete_name + 5, "St11align_val_tRKSt9nothrow_t", 29))
return true;
 }
   return false;
}

Jakub



>From 60626d4b040bc502c563b7c014b62751a517705a Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 9 Apr 2020 15:50:58 +0200
Subject: [PATCH] List valid pairs for new and delete operators.

gcc/ChangeLog:

2020-04-09  Martin Liska  
	Jakub Jelinek  

	PR c++/94314
	* cgraphclones.c (set_new_clone_decl_and_node_flags): Drop
	DECL_IS_REPLACEABLE_OPERATOR during cloning.
	* tree-ssa-dce.c (valid_new_delete_pair_p): New function.
	(propagate_necessity): Check operator names.
	(perform_tree_ssa_dce): Delete valid_pairs.

gcc/testsuite/ChangeLog:

2020-04-09  Martin Liska  
	Jakub Jelinek  

	PR c++/94314
	* g++.dg/pr94314-4.C: 

Re: [PATCH] correct format of flexible array members in diagnostics (PR c/92326)

[Martin Liška]

On 4/13/20 9:41 PM, Martin Sebor wrote:

On 4/13/20 1:25 PM, Jeff Law wrote:

On Mon, 2020-04-13 at 12:39 -0600, Martin Sebor via Gcc-patches wrote:

GCC 10 has changed the formatting of zero-length arrays in diagnostics
to include their bound, but it also inadvertently added the zero bound
to flexible array members which are confusingly represented differently
between the C and C++ front ends.

The attached patch corrects the problem so both zero-length arrays and
flexible array members are formatted consistently by both front ends
(i.e., as T[0] and T[]).

Tested on x86_64-linux.

This is fine.

Though I don't see that it actually addressed the qemu or grub2 issues raised by
Martin L.  ISTM those really should be a separate bug independent of the wrong-
bound in the diagnostic.  It looks like Martin L's claim is that for qemu & 
grub2
we've got new false positives from the warning.  Thoughts?


I don't see how this could cause false positives, unless something
is set up to filter out the specific text of the warning and this
change makes the filtering fail.

I had asked Martin (CC'd) about it but didn't understand his answer
in c#5 on the bug.  Martin?


Hi.

Official SUSE guideline recommends not to use -Werror for package builds. 
However, there
are package like grub or qemu that use -Werror. That's why these packages hit 
the error
in a way that I noticed. Both these packages decided to fix the warnings.

Martin



M.

[PATCH v4] Fix alignment for local variable [PR90811]

[Kito Cheng]

 - The alignment for local variable was adjust during estimate_stack_frame_size,
   however it seems wrong spot to adjust that, expand phase will adjust that
   but it little too late to some gimple optimization, which rely on certain
   target hooks need to check alignment, forwprop is an example for
   that, result of simplify_builtin_call rely on the alignment on some
   target like ARM or RISC-V.

 - Exclude static local var and hard register var in the process of
   alignment adjustment.

 - This patch fix gfortran.dg/pr45636.f90 for arm and riscv.

 - Regression test on riscv32/riscv64 and x86_64-linux-gnu, no new fail
   introduced.

gcc/ChangeLog

PR target/90811
* Makefile.in (OBJS): Add tree-adjust-alignment.o.
* tree-adjust-alignment.cc (pass_data_adjust_alignment): New.
(pass_adjust_alignment): New.
(-pass_adjust_alignment::execute): New.
(make_pass_adjust_alignment): New.
* tree-pass.h (make_pass_adjust_alignment): New.
* passes.def: Add pass_adjust_alignment.
---
 gcc/Makefile.in  |  1 +
 gcc/passes.def   |  1 +
 gcc/tree-adjust-alignment.cc | 92 
 gcc/tree-pass.h  |  1 +
 4 files changed, 95 insertions(+)
 create mode 100644 gcc/tree-adjust-alignment.cc

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index fa9923bb270..9b73288f776 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1545,6 +1545,7 @@ OBJS = \
ubsan.o \
sanopt.o \
sancov.o \
+   tree-adjust-alignment.o \
tree-call-cdce.o \
tree-cfg.o \
tree-cfgcleanup.o \
diff --git a/gcc/passes.def b/gcc/passes.def
index 2bf2cb78fc5..92cbe587a8a 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -183,6 +183,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_oacc_device_lower);
   NEXT_PASS (pass_omp_device_lower);
   NEXT_PASS (pass_omp_target_link);
+  NEXT_PASS (pass_adjust_alignment);
   NEXT_PASS (pass_all_optimizations);
   PUSH_INSERT_PASSES_WITHIN (pass_all_optimizations)
   NEXT_PASS (pass_remove_cgraph_callee_edges);
diff --git a/gcc/tree-adjust-alignment.cc b/gcc/tree-adjust-alignment.cc
new file mode 100644
index 000..77f38f6949b
--- /dev/null
+++ b/gcc/tree-adjust-alignment.cc
@@ -0,0 +1,92 @@
+/* Adjust alignment for local variable.
+   Copyright (C) 2003-2020 Free Software Foundation, Inc.
+   Contributed by Dorit Naishlos 
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "target.h"
+#include "tree.h"
+#include "gimple.h"
+#include "tree-pass.h"
+#include "cgraph.h"
+#include "fold-const.h"
+#include "gimple-iterator.h"
+#include "tree-cfg.h"
+#include "cfgloop.h"
+#include "tree-vectorizer.h"
+#include "tm_p.h"
+
+namespace {
+
+const pass_data pass_data_adjust_alignment =
+{
+  GIMPLE_PASS, /* type */
+  "adjust_alignment", /* name */
+  OPTGROUP_NONE, /* optinfo_flags */
+  TV_NONE, /* tv_id */
+  0, /* properties_required */
+  0, /* properties_provided */
+  0, /* properties_destroyed */
+  0, /* todo_flags_start */
+  0, /* todo_flags_finish */
+};
+
+class pass_adjust_alignment : public gimple_opt_pass
+{
+public:
+  pass_adjust_alignment (gcc::context *ctxt)
+: gimple_opt_pass (pass_data_adjust_alignment, ctxt)
+  {}
+
+  virtual unsigned int execute (function *);
+
+}; // class pass_adjust_alignment
+
+} // anon namespace
+
+/* Entry point to adjust_alignment pass.  */
+unsigned int
+pass_adjust_alignment::execute (function *fun) {
+  size_t i;
+  tree var;
+  unsigned int align;
+
+  FOR_EACH_LOCAL_DECL (fun, i, var)
+{
+  /* Don't adjust aligment for static local var and hard register var.  */
+  if (is_global_var (var) || DECL_HARD_REGISTER (var))
+   continue;
+
+  align = LOCAL_DECL_ALIGNMENT (var);
+
+  /* Make sure alignment only increase.  */
+  gcc_assert (align >= DECL_ALIGN (var));
+
+  SET_DECL_ALIGN (var, align);
+}
+  return 0;
+}
+
+gimple_opt_pass *
+make_pass_adjust_alignment (gcc::context *ctxt)
+{
+  return new pass_adjust_alignment (ctxt);
+}
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index a1207a20a3c..576b3f67434 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -480,6 +480,7 @@ extern gimple_opt_pass *make_pass_sprintf_length 
(gcc::context *ctxt);