[C++PATCH] [PR87322] move cp_evaluated up to tsubst all lambda parms

[Alexandre Oliva]

From: Alexandre Oliva 

A lambda capture variable initialized with a lambda expr taking more
than one parameter got us confused.

The first problem was that the parameter list was cut short during
tsubsting because we tsubsted it with cp_unevaluated_operand.  We
reset it right after, to tsubst the function body, so I've moved the
reset up so that it's in effect while processing the parameters as
well.

The second problem was that the lambda expr appeared twice, once in a
decltype that gave the capture variable its type, and once in its
initializer.  This caused us to instantiate two separate lambda exprs
and closure types, and then to flag that the lambda expr in the
initializer could not be converted to the unrelated closure type
determined for the capture variable.  Recording the tsubsted expr in
the local specialization map, and retrieving it for reuse fixed it.

Regstrapped on x86_64- and i686-linux-gnu.  Ok to install?


for  gcc/cp/ChangeLog

PR c++/87322
* pt.c (tsubst_lambda_expr): Avoid duplicate tsubsting.
Move cp_evaluated resetting before signature tsubsting.

for  gcc/testsuite/ChangeLog

PR c++/87322
* g++.dg/cpp1y/pr87322.C: New.
---
 gcc/cp/pt.c  |   18 ++
 gcc/testsuite/g++.dg/cpp1y/pr87322.C |   23 +++
 2 files changed, 37 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr87322.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b8fbf4046f07..3dffa8d2de88 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -17912,8 +17912,17 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
   tree oldfn = lambda_function (t);
   in_decl = oldfn;
 
+  /* If we have already specialized this lambda expr, reuse it.  See
+ PR c++/86322.  */
+  if (local_specializations)
+if (tree r = retrieve_local_specialization (t))
+  return r;
+
   tree r = build_lambda_expr ();
 
+  if (local_specializations)
+register_local_specialization (r, t);
+
   LAMBDA_EXPR_LOCATION (r)
 = LAMBDA_EXPR_LOCATION (t);
   LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (r)
@@ -18005,6 +18014,11 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
 r = error_mark_node;
   else
 {
+  /* The body of a lambda-expression is not a subexpression of the
+enclosing expression.  Parms are to have DECL_CHAIN tsubsted,
+which would be skipped if cp_unevaluated_operand.  */
+  cp_evaluated ev;
+
   /* Fix the type of 'this'.  */
   fntype = build_memfn_type (fntype, type,
 type_memfn_quals (fntype),
@@ -18026,10 +18040,6 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
   /* Let finish_function set this.  */
   DECL_DECLARED_CONSTEXPR_P (fn) = false;
 
-  /* The body of a lambda-expression is not a subexpression of the
-enclosing expression.  */
-  cp_evaluated ev;
-
   bool nested = cfun;
   if (nested)
push_function_context ();
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr87322.C 
b/gcc/testsuite/g++.dg/cpp1y/pr87322.C
new file mode 100644
index ..8f52e0e3b99b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr87322.C
@@ -0,0 +1,23 @@
+// { dg-do compile { target c++14 } }
+
+#include 
+#include 
+
+int main()
+{
+  constexpr std::array,3> my_mat { 
+ { { 1., 1. },
+   { 1., 1. },
+   { 1., 1. }, }
+  };
+  
+  std::for_each(my_mat.begin(), my_mat.end(), [
+  inner_func =  [] (auto a, auto b) { return a + b; } ](auto& row) {
+std::for_each(row.begin(), row.end(), [&,
+  inner_func2 =  [] (auto a, auto b) { return a + b; } ]
+  (const double&) {
+return;
+});
+  }); 
+  
+}


-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

Re: [patch, fortran] Move some array packing to front end

[Chris Elrod]

Hi,
I just compiled gcc-trunk after applying your patches (p8.diff) and H.J.
Lu's patches from *Bug 88713*
 (vectorized code slow
vs Flang) fixing rsqrt.

Thomas Koenig already confirmed it fixed the problem I recorded there, but
figured I'd add that I can also confirm it improved the benchmarks
dramatically. gfortran and g++ now seem to be the fastest (one of the
Fortran benchmarks saw over 100x improvement). Between those two patches,
Bug 88713 will be solved.

LLVM also seems to have an issue where, if you don't store inside the
function being called within the loop, the loop body ends up with a lot of
leaq instructions. gcc now seems to produce the same code regardless
(without those unnecessary instructions). Obviously, just one simple narrow
example, but exciting to see that improvement!


On Thu, Jan 24, 2019 at 4:56 AM Richard Biener 
wrote:

> On Wed, Jan 23, 2019 at 6:18 PM Thomas Koenig 
> wrote:
> >
> > Hi Dominique,
> >
> > > FAIL: gfortran.dg/internal_pack_4.f90   -O3 -fomit-frame-pointer
> -funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
> > >
> > > with -m32.
> > >
> > > gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/internal_pack_4.f90 -O3
> -funroll-loops -ftracer -m32
> > >
> > > is enough to trigger the miscomputation.
> >
> > Thanks, I will look into it.
> >
> > > The changes in the test suite are quite messy and I hope I did not
> miss any test (you should do "diff -N …" for the new tests).
> >
> > I don't think this is a good idea.  Applying the patch twice will then
> > double the test case.
> >
> >
> > > Do you have test showing a speed-up?
> >
> > It' in the PR.
> >
> >
> > > I agree with Richard that this patch should be held until the next
> stage 1.
> >
> > I just realized that we are, in principle, in regression-only mode.
> >
> > I do wish the announcements were also made to the fortran mailing lists.
>
> They are made to the low-traffic gcc@ list which everybody working on GCC
> is supposed to subscribe to.
>
> > Anyway, I'll see if I can fix that bug, then attach the combined
> > patch to the PR for later inclusion.
> >
> > Regards
> >
> > Thomas
>


-- 
https://github.com/chriselrod?tab=repositories
https://www.linkedin.com/in/chris-elrod-9720391a/

Re: [PATCH] Updated patches for the port of gccgo to GNU/Hurd

[Ian Lance Taylor]

On Thu, Jan 31, 2019 at 7:40 AM Svante Signell  wrote:
>
> As advised by the Debian gcc maintainer Matthias Klose and golang
> developer Ian Lance Taylor I'm re-submitting the patches for
> the port of gccgo to GNU/Hurd again. Now GOOS value is changed from gnu
> to hurd as requested.
>
> The 12 patches are:
> src_libgo_build.diff
> src_libgo_runtime.diff
> src_libgo_go_crypto.diff
> src_libgo_go_internal.diff
> src_libgo_go_net.diff
> src_libgo_go_os.diff
> src_libgo_go_runtime.diff
> src_libgo_go_syscall.diff
> src_libgo_go_test.diff
>
> src_libgo_testsuite_gotest.diff
> add-hurd-to-libgo-headers.diff
> add-hurd-to-libgo-test-headers.diff

Thanks.  I've committed versions of all of these patches other than
src_libgo_testsuite_gotest.diff.  I omitted that one because as far as
I can tell it won't work.  While the original code may not run on the
Hurd, the modified version won't work.

I made various changes, and I'm sure I broke some things.  Take a look
at GCC trunk and see how it seems.

Ian

libgo patch committed: A couple of Hurd fixes for tests

[Ian Lance Taylor]

This libgo patch based on a patch by Svante Signell fixes a couple of
tests for the Hurd.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268604)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-28b65174d9c9163f4ab2cfaf70dca646f1a7611f
+9b66264ed6adcf3fd215dbfd125c12b022b7280e
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/os/os_test.go
===
--- libgo/go/os/os_test.go  (revision 268369)
+++ libgo/go/os/os_test.go  (working copy)
@@ -1336,6 +1336,10 @@ func TestSeek(t *testing.T) {
t.Logf("skipping test case #%d on nacl; 
https://golang.org/issue/21728;, i)
continue
}
+   if runtime.GOOS == "hurd" && tt.out > 1<<32 {
+   t.Logf("skipping test case #%d on Hurd: file too 
large", i)
+   continue
+   }
off, err := f.Seek(tt.in, tt.whence)
if off != tt.out || err != nil {
if e, ok := err.(*PathError); ok && e.Err == 
syscall.EINVAL && tt.out > 1<<32 && runtime.GOOS == "linux" {
Index: libgo/go/syscall/syscall_unix_test.go
===
--- libgo/go/syscall/syscall_unix_test.go   (revision 268369)
+++ libgo/go/syscall/syscall_unix_test.go   (working copy)
@@ -46,11 +46,13 @@ func _() {
// fcntl file locking structure and constants
var (
_ = syscall.Flock_t{
-   Type:   int16(0),
-   Whence: int16(0),
-   Start:  int64(0),
-   Len:int64(0),
-   Pid:int32(0),
+   // Comment out the Type and Whence tests because
+   // on the Hurd they are int32, not int16.
+   // Type:   int16(0),
+   // Whence: int16(0),
+   Start: int64(0),
+   Len:   int64(0),
+   Pid:   int32(0),
}
)
const (

libgo patch committed: Add hurd support to os, net, crypto/x509

[Ian Lance Taylor]

This libgo patch by Svante Signell adds Hurd support to the os, net,
and crypto/x509 packages.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268603)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-db618eeabdcf1ba56861d21d5639ca4514cd6934
+28b65174d9c9163f4ab2cfaf70dca646f1a7611f
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/crypto/x509/root_hurd.go
===
--- libgo/go/crypto/x509/root_hurd.go   (nonexistent)
+++ libgo/go/crypto/x509/root_hurd.go   (working copy)
@@ -0,0 +1,11 @@
+// Copyright 2019 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+// This file is derived from root_linux.go
+
+package x509
+
+// Possible certificate files; stop after finding one.
+var certFiles = []string{
+   "/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc.
+}
Index: libgo/go/internal/poll/sendfile_glibc.go
===
--- libgo/go/internal/poll/sendfile_glibc.go(revision 268369)
+++ libgo/go/internal/poll/sendfile_glibc.go(working copy)
@@ -2,6 +2,8 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
+// +build hurd linux
+
 package poll
 
 import "syscall"
Index: libgo/go/internal/poll/sendfile_linux.go
===
--- libgo/go/internal/poll/sendfile_linux.go(revision 268369)
+++ libgo/go/internal/poll/sendfile_linux.go(nonexistent)
@@ -1,49 +0,0 @@
-// Copyright 2011 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-package poll
-
-import "syscall"
-
-// maxSendfileSize is the largest chunk size we ask the kernel to copy
-// at a time.
-const maxSendfileSize int = 4 << 20
-
-// SendFile wraps the sendfile system call.
-func SendFile(dstFD *FD, src int, remain int64) (int64, error) {
-   if err := dstFD.writeLock(); err != nil {
-   return 0, err
-   }
-   defer dstFD.writeUnlock()
-
-   dst := int(dstFD.Sysfd)
-   var written int64
-   var err error
-   for remain > 0 {
-   n := maxSendfileSize
-   if int64(n) > remain {
-   n = int(remain)
-   }
-   n, err1 := syscall.Sendfile(dst, src, nil, n)
-   if n > 0 {
-   written += int64(n)
-   remain -= int64(n)
-   } else if n == 0 && err1 == nil {
-   break
-   }
-   if err1 == syscall.EAGAIN {
-   if err1 = dstFD.pd.waitWrite(dstFD.isFile); err1 == nil 
{
-   continue
-   }
-   }
-   if err1 != nil {
-   // This includes syscall.ENOSYS (no kernel
-   // support) and syscall.EINVAL (fd types which
-   // don't implement sendfile)
-   err = err1
-   break
-   }
-   }
-   return written, err
-}
Index: libgo/go/net/cgo_hurd.go
===
--- libgo/go/net/cgo_hurd.go(nonexistent)
+++ libgo/go/net/cgo_hurd.go(working copy)
@@ -0,0 +1,17 @@
+// Copyright 2019 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+// This file is derived from cgo_bsd.go
+
+// +build cgo,!netgo
+// +build hurd
+
+package net
+
+/*
+#include 
+*/
+
+import "syscall"
+
+const cgoAddrInfoFlags = syscall.AI_CANONNAME | syscall.AI_V4MAPPED | 
syscall.AI_ALL
Index: libgo/go/net/sendfile_glibc.go
===
--- libgo/go/net/sendfile_glibc.go  (revision 268369)
+++ libgo/go/net/sendfile_glibc.go  (working copy)
@@ -2,6 +2,8 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
+// +build hurd linux
+
 package net
 
 import (
Index: libgo/go/net/sendfile_linux.go
===
--- libgo/go/net/sendfile_linux.go  (revision 268369)
+++ libgo/go/net/sendfile_linux.go  (nonexistent)
@@ -1,53 +0,0 @@
-// Copyright 2011 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-package net
-
-import (
-   "internal/poll"
-   "io"
-   

[PATCH] i386: Fix typo in *movoi_internal_avx/movti_internal

[H.J. Lu]

PR target/89229
* config/i386/i386.md (*movoi_internal_avx): Set mode to OI
for TARGET_AVX512VL.
(*movti_internal): Set mode to TI for TARGET_AVX512VL.
---
 gcc/config/i386/i386.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 9948f77fca5..c1492363bca 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -1938,7 +1938,7 @@
 (const_string "XI")
   (and (eq_attr "alternative" "1")
(match_test "TARGET_AVX512VL"))
-(const_string "XI")
+(const_string "OI")
   (ior (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL")
(and (eq_attr "alternative" "3")
 (match_test "TARGET_SSE_TYPELESS_STORES")))
@@ -2017,7 +2017,7 @@
 (const_string "XI")
   (and (eq_attr "alternative" "3")
(match_test "TARGET_AVX512VL"))
-(const_string "XI")
+(const_string "TI")
   (ior (not (match_test "TARGET_SSE2"))
(ior (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL")
 (and (eq_attr "alternative" "5")
-- 
2.20.1

libgo patch committed: Add hurd support to syscall package

[Ian Lance Taylor]

This libco patch adds hurd support to the syscall package.  This is
loosely based on a patch by Svante Signell, but I rewrote it to reduce
duplication.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268602)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-77f0f28af556f50c561ff5c2cca17ad6f985068e
+db618eeabdcf1ba56861d21d5639ca4514cd6934
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/syscall/errstr_glibc.go
===
--- libgo/go/syscall/errstr_glibc.go(revision 268369)
+++ libgo/go/syscall/errstr_glibc.go(working copy)
@@ -1,4 +1,4 @@
-// errstr_linux.go -- GNU/Linux specific error strings.
+// errstr_glibc.go -- GNU/Linux and GNU/Hurd specific error strings.
 
 // Copyright 2010 The Go Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style
@@ -7,6 +7,8 @@
 // We use this rather than errstr.go because on GNU/Linux sterror_r
 // returns a pointer to the error message, and may not use buf at all.
 
+// +build hurd linux
+
 package syscall
 
 import "unsafe"
Index: libgo/go/syscall/errstr_linux.go
===
--- libgo/go/syscall/errstr_linux.go(revision 268369)
+++ libgo/go/syscall/errstr_linux.go(nonexistent)
@@ -1,31 +0,0 @@
-// errstr_linux.go -- GNU/Linux specific error strings.
-
-// Copyright 2010 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-// We use this rather than errstr.go because on GNU/Linux sterror_r
-// returns a pointer to the error message, and may not use buf at all.
-
-package syscall
-
-import "unsafe"
-
-//sysnbstrerror_r(errnum int, b []byte) (errstr *byte)
-//strerror_r(errnum _C_int, b *byte, len Size_t) *byte
-
-func Errstr(errnum int) string {
-   a := make([]byte, 128)
-   p := strerror_r(errnum, a)
-   b := (*[1000]byte)(unsafe.Pointer(p))
-   i := 0
-   for b[i] != 0 {
-   i++
-   }
-   // Lowercase first letter: Bad -> bad, but STREAM -> STREAM.
-   if i > 1 && 'A' <= b[0] && b[0] <= 'Z' && 'a' <= b[1] && b[1] <= 'z' {
-   c := b[0] + 'a' - 'A'
-   return string(c) + string(b[1:i])
-   }
-   return string(b[:i])
-}
Index: libgo/go/syscall/exec_unix.go
===
--- libgo/go/syscall/exec_unix.go   (revision 268369)
+++ libgo/go/syscall/exec_unix.go   (working copy)
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build aix darwin dragonfly freebsd linux netbsd openbsd solaris
+// +build aix darwin dragonfly freebsd hurd linux netbsd openbsd solaris
 
 // Fork, exec, wait, etc.
 
@@ -319,7 +319,7 @@ func Exec(argv0 string, argv []string, e
runtime_BeforeExec()
 
var err1 error
-   if runtime.GOOS == "solaris" || runtime.GOOS == "aix" {
+   if runtime.GOOS == "solaris" || runtime.GOOS == "aix" || runtime.GOOS 
== "hurd" {
// RawSyscall should never be used on Solaris or AIX.
err1 = execveLibc(
uintptr(unsafe.Pointer(argv0p)),
Index: libgo/go/syscall/libcall_glibc.go
===
--- libgo/go/syscall/libcall_glibc.go   (nonexistent)
+++ libgo/go/syscall/libcall_glibc.go   (working copy)
@@ -0,0 +1,135 @@
+// Copyright 2009 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// +build hurd linux
+
+// glibc library calls.
+
+package syscall
+
+import (
+   "internal/race"
+   "unsafe"
+)
+
+//sys  Openat(dirfd int, path string, flags int, mode uint32) (fd int, err 
error)
+//__go_openat(dirfd _C_int, path *byte, flags _C_int, mode Mode_t) _C_int
+
+//sys  futimesat(dirfd int, path *byte, times *[2]Timeval) (err error)
+//futimesat(dirfd _C_int, path *byte, times *[2]Timeval) _C_int
+func Futimesat(dirfd int, path string, tv []Timeval) (err error) {
+   if len(tv) != 2 {
+   return EINVAL
+   }
+   return futimesat(dirfd, StringBytePtr(path), 
(*[2]Timeval)(unsafe.Pointer([0])))
+}
+
+func Futimes(fd int, tv []Timeval) (err error) {
+   // Believe it or not, this is the best we can do on GNU/Linux
+   // (and is what glibc does).
+   return Utimes("/proc/self/fd/"+itoa(fd), tv)
+}
+
+//sys  ptrace(request int, pid int, addr uintptr, data uintptr) (err error)
+//ptrace(request _C_int, pid Pid_t, addr *byte, data *byte) _C_long
+
+//sys  accept4(fd int, sa 

libgo patch committed: Add hurd constants to internal/syscall/unix

[Ian Lance Taylor]

This patch by Svante Signell adds a couple of hurd constants to
internal/syscall/unix.  Bootstrapped and ran a few tests on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268591)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-d89db31db68d09aa13a6137122cc096c1d92597b
+77f0f28af556f50c561ff5c2cca17ad6f985068e
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/internal/syscall/unix/at_sysnum_hurd.go
===
--- libgo/go/internal/syscall/unix/at_sysnum_hurd.go(nonexistent)
+++ libgo/go/internal/syscall/unix/at_sysnum_hurd.go(working copy)
@@ -0,0 +1,8 @@
+// Copyright 2019 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package unix
+
+const AT_REMOVEDIR = 0x200
+const AT_SYMLINK_NOFOLLOW = 0x100

[PATCH] Fix excess warnings from -Wtype-limits with location wrappers (PR c++/88680)

[David Malcolm]

PR c++/88680 reports excess warnings from -Wtype-limits after the C++
FE's use of location wrappers was extended in r267272 for cases such as:

  const unsigned n = 8;
  static_assert (n >= 0 && n % 2 == 0, "");

t.C:3:18: warning: comparison of unsigned expression >= 0 is always true
  [-Wtype-limits]
3 | static_assert (n >= 0 && n % 2 == 0, "");
  |~~^~~~

The root cause is that the location wrapper around "n" breaks the
suppression of the warning for the "if OP0 is a constant that is >= 0"
case.

This patch fixes it by calling fold_for_warn on OP0, extracting the
constant.

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

OK for trunk?

gcc/c-family/ChangeLog:
PR c++/88680
* c-common.c (shorten_compare): Call fold_for_warn on op0 when
implementing -Wtype-limits.

gcc/testsuite/ChangeLog:
PR c++/88680
* g++.dg/wrappers/pr88680.C: New test.
---
 gcc/c-family/c-common.c |  2 +-
 gcc/testsuite/g++.dg/wrappers/pr88680.C | 47 +
 2 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/wrappers/pr88680.C

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index d3b5879..5813e0a 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -3114,7 +3114,7 @@ shorten_compare (location_t loc, tree *op0_ptr, tree 
*op1_ptr,
   /* Here we must do the comparison on the nominal type
 using the args exactly as we received them.  */
   type = *restype_ptr;
-  primop0 = op0;
+  primop0 = fold_for_warn (op0);
   primop1 = op1;
 
   if (!real1 && !real2 && integer_zerop (primop1)
diff --git a/gcc/testsuite/g++.dg/wrappers/pr88680.C 
b/gcc/testsuite/g++.dg/wrappers/pr88680.C
new file mode 100644
index 000..86945db
--- /dev/null
+++ b/gcc/testsuite/g++.dg/wrappers/pr88680.C
@@ -0,0 +1,47 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wtype-limits" }
+
+const unsigned N = 8;
+const unsigned P = 0;
+
+enum { FOO, BAR };
+
+static_assert (N >= 0 && N % 2 == 0, "");
+static_assert (FOO >= 0, "");
+static_assert (FOO >= FOO, "");
+static_assert (FOO >= P, "");
+static_assert (BAR >= P, "");
+static_assert (N >= FOO, "");
+
+void test(unsigned n)
+{
+  if (N >= 0 && N % 2 == 0, "")
+return;
+  if (FOO >= 0, "")
+return;
+  if (FOO >= FOO, "")
+return;
+  if (FOO >= P, "")
+return;
+  if (BAR >= P)
+return;
+  if (N >= FOO, "")
+return;
+  if (n >= 0) // { dg-warning ">= 0 is always true" }
+return;
+  if (n < 0) // { dg-warning "< 0 is always false" }
+return;
+  if (n >= FOO)
+return;
+  if (n < FOO)
+return;
+  if (N >= 0)
+return;
+  if (N < 0)
+return;
+  if (N >= FOO)
+return;
+  if (N < FOO)
+return;
+
+}
-- 
1.8.5.3

[PATCH] improve out-of-bounds pointer warning (PR 88771)

[Martin Sebor]

The attached patch doesn't avoid the false positive but only improves
the warning to make it more readable (as suggested in the PR by Richard
for GCC 9).  With the patch, for a call like:

  memcpy (d, s, -1);

where d and s are pointers with unknown provenances the patch has GCC
in LP32 issue

  warning: ‘memcpy’ specified bound 4294967295 exceeds maximum object 
size 2147483647 [-Wstringop-overflow=]


instead of the somewhat mystifying

  ‘memcpy’ pointer overflow between offset 0 and size [4294967295, 
2147483647] [-Warray-bounds]


There are a few places the warning is issued from and it would make
sense to consolidate them into the same utility function.  Since that
will require some not entirely trivial changes to the warning code
I defer it until GCC 10 as well, along with a fix for the false
positive.

Tested on x86_64-linux.

Martin
PR tree-optimization/88771 - Misleading -Werror=array-bounds error

gcc/ChangeLog:

	PR tree-optimization/88771
	* gimple-ssa-warn-restrict.c (pass_wrestrict::gate): Also enable
	when -Wstringop-overflow is set.
	(builtin_memref::builtin_memref): Adjust excessive upper bound
	only when lower bound is not excessive.
	(maybe_diag_overlap): Detect and diagnose excessive bounds via
	-Wstringop-ovefflow.
	(maybe_diag_offset_bounds): Rename...
	(maybe_diag_access_bounds): ...to this.
	(check_bounds_or_overlap): Adjust for name change above.

gcc/testsuite/ChangeLog:

	PR tree-optimization/88771
	* gcc.dg/Wstringop-overflow-8.c: New test.
	* gcc.dg/Wstringop-overflow-9.c: New test.
	* gcc.dg/Warray-bounds-40.c: New test.
	* gcc.dg/builtin-stpncpy.c: Adjust.
	* gcc.dg/builtin-stringop-chk-4.c: Adjust.
	* g++.dg/opt/memcpy1.C: Adjust.

Index: gcc/gimple-ssa-warn-restrict.c
===
--- gcc/gimple-ssa-warn-restrict.c	(revision 268583)
+++ gcc/gimple-ssa-warn-restrict.c	(working copy)
@@ -75,7 +75,7 @@ class pass_wrestrict : public gimple_opt_pass
 bool
 pass_wrestrict::gate (function *fun ATTRIBUTE_UNUSED)
 {
-  return warn_array_bounds != 0 || warn_restrict != 0;
+  return warn_array_bounds || warn_restrict || warn_stringop_overflow;
 }
 
 /* Class to walk the basic blocks of a function in dominator order.  */
@@ -256,7 +256,7 @@ builtin_memref::builtin_memref (tree expr, tree si
   sizrange[1] = wi::to_offset (range[1]);
   /* get_size_range returns SIZE_MAX for the maximum size.
 	 Constrain it to the real maximum of PTRDIFF_MAX.  */
-  if (sizrange[1] > maxobjsize)
+  if (sizrange[0] <= maxobjsize && sizrange[1] > maxobjsize)
 	sizrange[1] = maxobjsize;
 }
   else
@@ -1567,18 +1567,56 @@ maybe_diag_overlap (location_t loc, gimple *call,
   return true;
 }
 
-/* Validate REF offsets in an expression passed as an argument to a CALL
-   to a built-in function FUNC to make sure they are within the bounds
-   of the referenced object if its size is known, or PTRDIFF_MAX otherwise.
-   Both initial values of the offsets and their final value computed by
-   the function by incrementing the initial value by the size are
+/* Validate REF size and offsets in an expression passed as an argument
+   to a CALL to a built-in function FUNC to make sure they are within
+   the bounds of the referenced object if its size is known, or
+   PTRDIFF_MAX otherwise.  DO_WARN is true when a diagnostic should
+   be issued, false otherwise.
+   Both initial values of the offsets and their final value computed
+   by the function by incrementing the initial value by the size are
validated.  Return true if the offsets are not valid and a diagnostic
-   has been issued.  */
+   has been issued, or would have been issued if DO_WARN had been true.  */
 
 static bool
-maybe_diag_offset_bounds (location_t loc, gimple *call, tree func, int strict,
+maybe_diag_access_bounds (location_t loc, gimple *call, tree func, int strict,
 			  const builtin_memref , bool do_warn)
 {
+  const offset_int maxobjsize = tree_to_shwi (max_object_size ());
+
+  /* Check for excessive size first and regardless of warning options
+ since the result is used to make codegen decisions.  */
+  if (ref.sizrange[0] > maxobjsize)
+{
+  /* Return true without issuing a warning.  */
+  if (!do_warn)
+	return true;
+
+  if (ref.ref && TREE_NO_WARNING (ref.ref))
+	return false;
+
+  if (warn_stringop_overflow)
+	{
+	  if (EXPR_HAS_LOCATION (ref.ptr))
+	loc = EXPR_LOCATION (ref.ptr);
+
+	  loc = expansion_point_location_if_in_system_header (loc);
+
+	  if (ref.sizrange[0] == ref.sizrange[1])
+	return warning_at (loc, OPT_Wstringop_overflow_,
+			   "%G%qD specified bound %wu "
+			   "exceeds maximum object size %wu",
+			   call, func, ref.sizrange[0].to_uhwi (),
+			   maxobjsize.to_uhwi ());
+
+	  return warning_at (loc, OPT_Wstringop_overflow_,
+			 "%G%qD specified bound between %wu and %wu "
+			 "exceeds maximum object size %wu",
+			 call, func, ref.sizrange[0].to_uhwi (),
+			 

[PATCH] correct __clear_cache signature

[Martin Sebor]

Recent libgcc builds have been triggering -Wbuiltin-declaration-mismatch
due to the declaration of the __clear_cache built-in being incompatible
with how GCC declares it internally.  The attached patch adjusts
the libgcc declaration and the one in the manual to match what GCC
expects.

Tested on x86_64-linux.

Martin
libgcc/ChangeLog:

	* libgcc2.h (__clear_cache): Correct signature.
	* libgcc2.c (__clear_cache): Same.

gcc/ChangeLog:

	* doc/extend.texi (__clear_cache): Correct signature.

gcc/testsuite/ChangeLog:

	* gcc.dg/Wbuiltin-declaration-mismatch-12.c: New test.

Index: libgcc/libgcc2.h
===
--- libgcc/libgcc2.h	(revision 268583)
+++ libgcc/libgcc2.h	(working copy)
@@ -30,7 +30,7 @@ see the files COPYING3 and COPYING.RUNTIME respect
 #endif
 
 extern int __gcc_bcmp (const unsigned char *, const unsigned char *, size_t);
-extern void __clear_cache (char *, char *);
+extern void __clear_cache (void *, void *);
 extern void __eprintf (const char *, const char *, unsigned int, const char *)
   __attribute__ ((__noreturn__));
 
Index: libgcc/libgcc2.c
===
--- libgcc/libgcc2.c	(revision 268583)
+++ libgcc/libgcc2.c	(working copy)
@@ -2162,11 +2162,14 @@ __eprintf (const char *string, const char *express
 /* Clear part of an instruction cache.  */
 
 void
-__clear_cache (char *beg __attribute__((__unused__)),
-	   char *end __attribute__((__unused__)))
+__clear_cache (void *beg __attribute__((__unused__)),
+	   void *end __attribute__((__unused__)))
 {
 #ifdef CLEAR_INSN_CACHE
-  CLEAR_INSN_CACHE (beg, end);
+  /* Cast the void* pointers to char* as some implementations
+ of the macro assume the pointers can be subtracted from
+ one another.  */
+  CLEAR_INSN_CACHE ((char *) beg, (char *) end);
 #endif /* CLEAR_INSN_CACHE */
 }
 
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 268583)
+++ gcc/doc/extend.texi	(working copy)
@@ -13073,7 +13073,7 @@ void foo (void)
 
 @end deftypefn
 
-@deftypefn {Built-in Function} void __builtin___clear_cache (char *@var{begin}, char *@var{end})
+@deftypefn {Built-in Function} void __builtin___clear_cache (void *@var{begin}, void *@var{end})
 This function is used to flush the processor's instruction cache for
 the region of memory between @var{begin} inclusive and @var{end}
 exclusive.  Some targets require that the instruction cache be
Index: gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-12.c
===
--- gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-12.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/Wbuiltin-declaration-mismatch-12.c	(working copy)
@@ -0,0 +1,8 @@
+/* Verify that declaring the __clear_cache and __builtin_prefetch
+   intrinsic functions with the wrong signature is diagnosed.
+   { dg-do compile }
+   { dg-options "-Wbuiltin-declaration-mismatch -Wextra" } */
+
+extern void __clear_cache (char*, char*);   /* { dg-warning "mismatch in argument 1 type of built-in function .__clear_cache.; expected .void \\\*." } */
+
+void __builtin_prefetch (const char *, ...);   /* { dg-warning "mismatch in argument 1 type of built-in function .__builtin_prefetch.; expected .const void \\\*." } */

Re: [Patch] PR rtl-optimization/87763 - generate more bfi instructions on aarch64

[Steve Ellcey]

On Tue, 2019-02-05 at 21:12 +, Wilco Dijkstra wrote:

> +bool
> +aarch64_masks_and_shift_for_bfi_p (scalar_int_mode mode,
> +  unsigned HOST_WIDE_INT mask1,
> +  unsigned HOST_WIDE_INT shft_amnt,
> +  unsigned HOST_WIDE_INT mask2)
> +{
> +  unsigned HOST_WIDE_INT t;
> +
> +  /* Verify that there is no overlap in what bits are set in the two
> masks.  */
> +  if ((mask1 + mask2) != HOST_WIDE_INT_M1U)
> +return false;
> +  if ((mask1 & mask2) != 0)
> +return false;
> 
> Why not check mask1 == ~mask2? That's much simpler...

Yes that would be simpler.  I made that change.
> 
> +  /* Verify that the shift amount is less than the mode size.  */
> +  if (shft_amnt >= GET_MODE_BITSIZE (mode))
> +return false;
> 
> The md pattern already guarantees this (this could be an assert). We need
> to check that  shift+width <= mode size. Given immediates are limited to
> the mode size, the easiest way is to check mask2 is not 0 or M1.

OK, I changed the if statement to a gcc_assert and added a check to
make sure mask2 is not 0 or M1.

> +  /* Verify that the mask being shifted is contiguous and would be in the
> + least significant bits after shifting by creating a mask 't' based on
> + the number of bits set in mask2 and the shift amount for mask2 and
> + comparing that to the actual mask2.  */
> +  t = popcount_hwi (mask2);
> +  t = (HOST_WIDE_INT_1U << t) - 1;
> +  t = t << shft_amnt;
> +  if (t != mask2)
> +return false;
> +
> +  return true;
> 
> This would return true if mask2 == 0 or M1 (I think this can't happen with
> current md patterns, but this would emit an illegal bfi).
> 
> After special cases you could do something like t = mask2 + (HWI_1U << shift);
> return t == (t & -t) to check for a valid bfi.

I am not sure I follow this logic and my attempts to use this did not
work so I kept my original code.

> +  "bfi\t%0, %1, 0, %P2"
> 
> This could emit a width that may be 32 too large in SImode if bit 31 is set
> (there is another use of %P in aarch64.md which may have the same
> issue).

I am not sure why having bit 31 set would be a problem.  Sign
extension?

> Finally from some quick testing it seems one case is not yet
> supported:
> 
> int f1(int x, int y)
> {
>   return (y & 0xfff) | (((x <<28) & 0xf000));
> }
> 
> This just has a shift, rather than an AND plus a shift.

I added another instruction to handle this and added a new test to
check for it.

Steve Ellcey
sell...@marvell.com


Here is the latest version of the patch.


2018-02-06  Steve Ellcey  

PR rtl-optimization/87763
* config/aarch64/aarch64-protos.h (aarch64_masks_and_shift_for_bfi_p):
New prototype.
* config/aarch64/aarch64.c (aarch64_masks_and_shift_for_bfi_p):
New function.
* config/aarch64/aarch64.md (*aarch64_bfi5_shift):
New instruction.
(*aarch64_bfi4_noand): Ditto.
(*aarch64_bfi4_noshift): Ditto.
(*aarch64_bfi4_noshift_alt): Ditto.

2018-02-06  Steve Ellcey  

PR rtl-optimization/87763
* gcc.target/aarch64/combine_bfxil.c: Change some bfxil checks
to bfi.
* gcc.target/aarch64/combine_bfi_2.c: New test.

diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index b035e35f33b..b6c0d0a8eb6 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -429,6 +429,9 @@ bool aarch64_label_mentioned_p (rtx);
 void aarch64_declare_function_name (FILE *, const char*, tree);
 bool aarch64_legitimate_pic_operand_p (rtx);
 bool aarch64_mask_and_shift_for_ubfiz_p (scalar_int_mode, rtx, rtx);
+bool aarch64_masks_and_shift_for_bfi_p (scalar_int_mode, unsigned HOST_WIDE_INT,
+	unsigned HOST_WIDE_INT,
+	unsigned HOST_WIDE_INT);
 bool aarch64_zero_extend_const_eq (machine_mode, rtx, machine_mode, rtx);
 bool aarch64_move_imm (HOST_WIDE_INT, machine_mode);
 opt_machine_mode aarch64_sve_pred_mode (unsigned int);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index d7c453cdad0..26b5ab47d6f 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -9330,6 +9330,42 @@ aarch64_mask_and_shift_for_ubfiz_p (scalar_int_mode mode, rtx mask,
 	 & ((HOST_WIDE_INT_1U << INTVAL (shft_amnt)) - 1)) == 0;
 }
 
+/* Return true if the masks and a shift amount from an RTX of the form
+   ((x & MASK1) | ((y << SHIFT_AMNT) & MASK2)) are valid to combine into
+   a BFI instruction of mode MODE.  See *arch64_bfi patterns.  */
+
+bool
+aarch64_masks_and_shift_for_bfi_p (scalar_int_mode mode,
+   unsigned HOST_WIDE_INT mask1,
+   unsigned HOST_WIDE_INT shft_amnt,
+   unsigned HOST_WIDE_INT mask2)
+{
+  unsigned HOST_WIDE_INT t;
+
+  /* Verify that there is no overlap in what bits are set in the two masks.  */
+  if (mask1 != ~mask2)
+return false;
+
+  /* Verify that mask2 is not all zeros or 

[rs6000] 64-bit integer loads/stores and FP instructions

[Eric Botcazou]

Hi,

as reported e.g. at https://gcc.gnu.org/ml/gcc-help/2018-11/msg00038.html, the 
7 series of compilers started to use FP instructions for simple 64-bit integer 
loads/stores in unexpected ways.  Consider:

uint64_t var;

void foo1 (uint64_t *p)
{
  var = *p;
}

void foo2 (uint64_t *p)
{
  *p = var;
}

void foo3 (void * p)
{
  var = *(uint64_t *)p;
}

void foo4 (void *p)
{
  *(uint64_t *)p = var;
}

At -O0, the 32-bit compiler uses a double lwz/stw pairs for the 4 functions.  
At -O1, it uses a lfd/stfd pair for foo2 and foo4, but neither for foo1 nor 
foo3.  At -O2, it again uses a double lwz/stw pairs for the 4 functions.

This was introduced by this change:
  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01993.html

Now, if you try with the GCC 8 compiler, then you get back the double lwz/stw 
pairs for the 4 functions at every optimization level.

The difference between GCC 7 and GCC 8 comes from this change:
  https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00584.html
which seems to imply that the first change was problematic but which was not 
backported to the 7 branch.

So at a minimum I think that the second change should be backported to the 7 
branch; it applies (almost) cleanly and gives no regressions on PowerPC/Linux.

Backport from mainline
2018-06-11  Segher Boessenkool  

PR target/85755
* config/rs6000/rs6000.md (*movdi_internal32): Put constraint modifiers
on the correct operand.
(*movdi_internal64): Ditto.


But I also think that another part of the first change is problematic, namely 
the removal of the '*' modifier on the alternatives, which means that the 
register preference of the instruction isn't skewed towards integer registers 
any more.  That may be OK for native targets, but that is frowned upon for 
embedded targets, where people are really unhappy when the compiler emits 
floating-point instructions for pure integer code for no apparent reason.

So I suggest decoupling the (recent) native targets from the rest for this 
specific issue, see a proof of concept in the second patch.

Thoughts?

-- 
Eric Botcazou
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 8d0b58cc6d6..89812a03d74 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -8565,16 +8565,16 @@
 
 (define_insn "*movdi_internal32"
   [(set (match_operand:DI 0 "rs6000_nonimmediate_operand"
- "=Y,r, r, ^m,^d, ^d,
-  r, ^wY,   $Z,^wb,   $wv,^wi,
+ "=Y,r, r, m, ^d, ^d,
+  r, wY,Z, ^wb,   $wv,^wi,
   *wo,   *wo,   *wv,   *wi,   *wi,*wv,
   *wv")
 
 	(match_operand:DI 1 "input_operand"
-  "r,Y, r, d, m,  d,
-   IJKnGHF,  wb,wv,wY,Z,  wi,
-   Oj,   wM,OjwM,  Oj,wM, wS,
-   wB"))]
+ "r, Y, r, ^d,m,  ^d,
+  IJKnGHF,   ^wb,   $wv,   wY,Z,  ^wi,
+  Oj,wM,OjwM,  Oj,wM, wS,
+  wB"))]
 
   "! TARGET_POWERPC64
&& (gpc_reg_operand (operands[0], DImode)
@@ -8642,17 +8642,17 @@
 (define_insn "*movdi_internal64"
   [(set (match_operand:DI 0 "nonimmediate_operand"
"=YZ,   r, r, r, r,  r,
-^m,^d,^d,^wY,   $Z, $wb,
+m, ^d,^d,wY,Z,  $wb,
 $wv,   ^wi,   *wo,   *wo,   *wv,*wi,
 *wi,   *wv,   *wv,   r, *h, *h,
 ?*r,   ?*wg,  ?*r,   ?*wj")
 
 	(match_operand:DI 1 "input_operand"
-"r,YZ,r, I, L,  nF,
- d,m, d, wb,wv, wY,
- Z,wi,Oj,wM,OjwM,   Oj,
- wM,   wS,wB,*h,r,  0,
- wg,   r, wj,r"))]
+   "r, YZ,r, I, L,  nF,
+^d,m, ^d,^wb,   $wv,wY,
+Z, ^wi,   Oj,wM,OjwM,   Oj,
+wM,wS,wB,*h,r,  0,
+wg,r, wj,r"))]
 
   "TARGET_POWERPC64
&& (gpc_reg_operand (operands[0], DImode)
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 7d399a2227b..d48395666fc 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -4894,6 +4894,13 @@ rs6000_option_override_internal (bool 

patch to fix PR89225

[Vladimir Makarov]

  The following patch fixes

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

  The patch was bootstrapped and tested on x86-64.

  Committed as rev. 268597.

Index: ChangeLog
===
--- ChangeLog	(revision 268596)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2019-02-06  Vladimir Makarov  
+
+	PR rtl-optimization/89225
+	* lra-constaints.c (simplify_operand_subreg): Add subreg mode
+	sizes check.
+
 2019-02-06  Eric Botcazou  
 
 	* config/i386/i386.c (ix86_expand_prologue): Emit a memory blockage
Index: lra-constraints.c
===
--- lra-constraints.c	(revision 268424)
+++ lra-constraints.c	(working copy)
@@ -1533,9 +1533,12 @@ simplify_operand_subreg (int nop, machin
 	 a word.
 
 	 If valid memory becomes invalid after subreg elimination
-	 we still have to reload memory.
+	 and address might be different we still have to reload
+	 memory.
 	  */
-	  if ((! addr_was_valid || addr_is_valid)
+	  if ((! addr_was_valid
+	   || addr_is_valid
+	   || known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE (innermode)))
 	  && !(maybe_ne (GET_MODE_PRECISION (mode),
 			 GET_MODE_PRECISION (innermode))
 		   && known_le (GET_MODE_SIZE (mode), UNITS_PER_WORD)
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog	(revision 268596)
+++ testsuite/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2019-02-06  Vladimir Makarov  
+
+	PR rtl-optimization/89225
+	* gcc.target/powerpc/pr89225.c: New.
+
 2019-02-06  Eric Botcazou  
 
 	* gnat.dg/opt76.adb: New test.
Index: testsuite/gcc.target/powerpc/pr89225.c
===
--- testsuite/gcc.target/powerpc/pr89225.c	(nonexistent)
+++ testsuite/gcc.target/powerpc/pr89225.c	(working copy)
@@ -0,0 +1,73 @@
+/* { dg-do compile  { target { powerpc*-*-* && lp64 } } } */
+/* { dg-options "-O2 -fstack-protector-strong -mlong-double-128" } */
+
+extern long double foo (long double);
+extern double bar (double);
+typedef long long int64_t;
+typedef unsigned long long uint64_t;
+typedef union { int64_t i[2]; long double x; double d[2]; } mynumber;
+static const double t512 = 0x1p512, tm256 = 0x1p-256, two54 = 0x1p54, twom54 = 0x1p-54;
+
+long double
+foo (long double x)
+{
+  static const long double big = 134217728.0, big1 = 134217729.0;
+  long double t, s, i;
+  mynumber a, c;
+  uint64_t k, l;
+  int64_t m, n;
+  double d;
+
+  a.x = x;
+  k = a.i[0] & 0x7fffL;
+
+  if (k > 0x000fL && k < 0x7ff0L)
+{
+  if (x < 0)
+	return (big1 - big1) / (big - big);
+  l = (k & 0x001fL) | 0x3fe0L;
+  if ((a.i[1] & 0x7fffL) != 0)
+	{
+	  n = (int64_t) ((l - k) * 2) >> 53;
+	  m = (a.i[1] >> 52) & 0x7ff;
+	  if (m == 0)
+	{
+	  a.d[1] *= two54;
+	  m = ((a.i[1] >> 52) & 0x7ff) - 54;
+	}
+	  m += n;
+	  if (m > 0)
+	a.i[1] = (a.i[1] & 0x800fL) | (m << 52);
+	  else if (m <= -54)
+	{
+	  a.i[1] &= 0x8000L;
+	}
+	  else
+	{
+	  m += 54;
+	  a.i[1] = (a.i[1] & 0x800fL) | (m << 52);
+	  a.d[1] *= twom54;
+	}
+	}
+  a.i[0] = l;
+  s = a.x;
+  d = bar (a.d[0]);
+  c.i[0] = 0x2000L + ((k & 0x7fe0L) >> 1);
+  c.i[1] = 0;
+  i = d;
+  t = 0.5L * (i + s / i);
+  i = 0.5L * (t + s / t);
+  return c.x * i;
+}
+  else
+{
+  if (k >= 0x7ff0L)
+
+	return x * x + x;
+  if (x == 0)
+	return x;
+  if (x < 0)
+	return (big1 - big1) / (big - big);
+  return tm256 * foo (x * t512);
+}
+}

[patch, committed] Test case for PR 71860

[Thomas Koenig]

Hi,

I have committed the attached test case as obvious, to trunk,
as r268590 (after checking that it passes).  The PR is marked as a 7/8/9
regression.

I plan to wait for a few days to see if anything comes up, then also
commit to the other open branches (I have already checked that it
passes there as well).

Regards

Thomas

2019-02-06  Thomas Koenig  

PR fortran/71860
* gfortran.dg/null_10.f90: New test.

! { dg-do compile }
! PR 71860 - this used to ICE
! Original test case by Gerhard Steinmetz
program p
   class(*), pointer :: z
   z => null(z)
end

[PATCH] PR libstdc++/89164 enforce constraints for uninitialized algos

[Jonathan Wakely]

The memmove optimizations for std::uninitialized_copy/fill/_n will
compile even if the type is not copy constructible, because std::copy
doesn't require copy construction to work. But the uninitialized
algorithms do require it.

This adds explicit static assertions to ensure we don't allow ill-formed
initializations.

PR libstdc++/89164
* include/bits/stl_uninitialized.h (uninitialized_copy): Add static
assertion.
* testsuite/20_util/specialized_algorithms/uninitialized_copy/89164.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_copy_n/
89164.cc: New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill/89164.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill_n/
89164.cc: New test.
* testsuite/23_containers/vector/cons/89164.cc: New test.

This fixes an accepts-invalid bug in vector (and probably other
containers, I didn't check) but I don't see any great urgency to fix
this now. I'll wait for stage 1.


commit 6f61f77f40546fdf47aaf6320d141f380a0c7d49
Author: Jonathan Wakely 
Date:   Tue Feb 5 14:12:27 2019 +

PR libstdc++/89164 enforce constraints for uninitialized algos

The memmove optimizations for std::uninitialized_copy/fill/_n will
compile even if the type is not copy constructible, because std::copy
doesn't require copy construction to work. But the uninitialized
algorithms do require it.

This adds explicit static assertions to ensure we don't allow ill-formed
initializations.

PR libstdc++/89164
* include/bits/stl_uninitialized.h (uninitialized_copy): Add static
assertion.
* 
testsuite/20_util/specialized_algorithms/uninitialized_copy/89164.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_copy_n/
89164.cc: New test.
* 
testsuite/20_util/specialized_algorithms/uninitialized_fill/89164.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill_n/
89164.cc: New test.
* testsuite/23_containers/vector/cons/89164.cc: New test.

diff --git a/libstdc++-v3/include/bits/stl_algobase.h 
b/libstdc++-v3/include/bits/stl_algobase.h
index 2b69e658fe8..646d15b2164 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -301,7 +301,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // (2) If we're using random access iterators, then write the loop as
   // a for loop with an explicit count.
 
-  template
+  template
 struct __copy_move
 {
   template
diff --git a/libstdc++-v3/include/bits/stl_uninitialized.h 
b/libstdc++-v3/include/bits/stl_uninitialized.h
index 0d42b253df1..f5ca74329e2 100644
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -122,9 +122,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #if __cplusplus < 201103L
   const bool __assignable = true;
 #else
-  // trivial types can have deleted assignment
+  // Trivial types can have deleted copy constructor, but the std::copy
+  // optimization that uses memmove would happily "copy" them anyway.
+  static_assert(is_constructible<_ValueType2, decltype(*__first)>::value,
+ "result type must be constructible from value type of input range");
+
   typedef typename iterator_traits<_InputIterator>::reference _RefType1;
   typedef typename iterator_traits<_ForwardIterator>::reference _RefType2;
+  // Trivial types can have deleted assignment, so using std::copy
+  // would be ill-formed. Require assignability before using std::copy:
   const bool __assignable = is_assignable<_RefType2, _RefType1>::value;
 #endif
 
@@ -186,7 +192,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #if __cplusplus < 201103L
   const bool __assignable = true;
 #else
-  // trivial types can have deleted assignment
+  // Trivial types can have deleted copy constructor, but the std::fill
+  // optimization that uses memmove would happily "copy" them anyway.
+  static_assert(is_constructible<_ValueType, const _Tp&>::value,
+ "result type must be constructible from input type");
+
+  // Trivial types can have deleted assignment, so using std::fill
+  // would be ill-formed. Require assignability before using std::fill:
   const bool __assignable = is_copy_assignable<_ValueType>::value;
 #endif
 
@@ -248,7 +260,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 #if __cplusplus < 201103L
   const bool __assignable = true;
 #else
-  // trivial types can have deleted assignment
+  // Trivial types can have deleted copy constructor, but the std::fill
+  // optimization that uses memmove would happily "copy" them anyway.
+  static_assert(is_constructible<_ValueType, const _Tp&>::value,
+ "result type must be constructible 

libgo patch committed: Use strong form of atomic_compare_exchange_n

[Ian Lance Taylor]

In GCC PR 89199 Lynn Boger points out that I used the weak form of
atomic_compare_exchange_n.  The upstream library uses, in effect, the
strong form, and the rest of the library expects the strong form.
This patch fixes libgo accordingly.  Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268584)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-74ffeddbe6fef446129af65581b3a9094715bc22
+d89db31db68d09aa13a6137122cc096c1d92597b
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/sync/atomic/atomic.c
===
--- libgo/go/sync/atomic/atomic.c   (revision 268458)
+++ libgo/go/sync/atomic/atomic.c   (working copy)
@@ -69,7 +69,7 @@ _Bool CompareAndSwapInt32 (int32_t *, in
 _Bool
 CompareAndSwapInt32 (int32_t *val, int32_t old, int32_t new)
 {
-  return __atomic_compare_exchange_n (val, , new, true, __ATOMIC_SEQ_CST,
+  return __atomic_compare_exchange_n (val, , new, false, __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED);
 }
 
@@ -82,7 +82,7 @@ CompareAndSwapInt64 (int64_t *val, int64
 {
   if (((uintptr_t) val & 7) != 0)
 val = NULL;
-  return __atomic_compare_exchange_n (val, , new, true, __ATOMIC_SEQ_CST,
+  return __atomic_compare_exchange_n (val, , new, false, __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED);
 }
 
@@ -93,7 +93,7 @@ _Bool CompareAndSwapUint32 (uint32_t *,
 _Bool
 CompareAndSwapUint32 (uint32_t *val, uint32_t old, uint32_t new)
 {
-  return __atomic_compare_exchange_n (val, , new, true, __ATOMIC_SEQ_CST,
+  return __atomic_compare_exchange_n (val, , new, false, __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED);
 }
 
@@ -106,7 +106,7 @@ CompareAndSwapUint64 (uint64_t *val, uin
 {
   if (((uintptr_t) val & 7) != 0)
 val = NULL;
-  return __atomic_compare_exchange_n (val, , new, true, __ATOMIC_SEQ_CST,
+  return __atomic_compare_exchange_n (val, , new, false, __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED);
 }
 
@@ -117,7 +117,7 @@ _Bool CompareAndSwapUintptr (uintptr_t *
 _Bool
 CompareAndSwapUintptr (uintptr_t *val, uintptr_t old, uintptr_t new)
 {
-  return __atomic_compare_exchange_n (val, , new, true, __ATOMIC_SEQ_CST,
+  return __atomic_compare_exchange_n (val, , new, false, __ATOMIC_SEQ_CST,
  __ATOMIC_RELAXED);
 }
 

[patch, fortran] Fix PR 71237

[Thomas Koenig]

Hello world,

this patch fixes a 7/8/9 regression where we tried to accept invalid
code, which led to an ICE later on.

The patch is rather straightforward.  The reason why I could not
use gfc_expr_attr is that it does not actually return the
flags the way they can be found in the original attributes;
for example, an expression containing a pointer attribute is
shown as having the target attribute, for reasons I cannot
fathom.

Regression-tested.  OK for trunk and other open branches?

Regards

Thomas

2019-02-06  Thomas Koenig  

PR fortran/71237
* expr.c (gfc_check_assign): Add argument is_init_expr.  If we are
looking at an init expression, issue error if the target is not a
TARGET and we are not looking at a procedure pointer.
* gfortran.h (gfc_check_assign): Add optional argument
is_init_expr.

2019-02-06  Thomas Koenig  

PR fortran/71237
* gfortran.dg/pointer_init_2.f90: Adjust error messages.
* gfortran.dg/pointer_init_6.f90: Likewise.
* gfortran.dg/pointer_init_9.f90: New test.
! { dg-do compile }
! PR 71237 - this used to ICE.
module data_mod
  implicit none

  type data_t
integer :: i
  end type

  type(data_t), pointer :: data
  integer, pointer :: idata => data%i ! { dg-error "Pointer assignment target in initialization expression does not have the TARGET attribute" }

end module
Index: fortran/ChangeLog
===
--- fortran/ChangeLog	(Revision 268501)
+++ fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,11 @@
+2019-02-05  Thomas Koenig  
+
+	PR fortran/67679
+	Backport from trunk
+	* trans-array.c (gfc_array_allocate):  For setting the bounds on
+	the new array, add a condition for a not previously allocated
+	variable.
+
 2019-02-02  Dominique d'Humieres  
 
 	PR fortran/81344
Index: fortran/expr.c
===
--- fortran/expr.c	(Revision 268432)
+++ fortran/expr.c	(Arbeitskopie)
@@ -3682,7 +3682,7 @@ gfc_check_assign (gfc_expr *lvalue, gfc_expr *rval
 
 bool
 gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue,
-			  bool suppress_type_test)
+			  bool suppress_type_test, bool is_init_expr)
 {
   symbol_attribute attr, lhs_attr;
   gfc_ref *ref;
@@ -4124,12 +4124,36 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
   return false;
 }
 
-  if (!attr.target && !attr.pointer)
+  if (is_init_expr)
 {
-  gfc_error ("Pointer assignment target is neither TARGET "
-		 "nor POINTER at %L", >where);
-  return false;
+  gfc_symbol *sym;
+  bool target;
+
+  gcc_assert (rvalue->symtree);
+  sym = rvalue->symtree->n.sym;
+
+  if (sym->ts.type == BT_CLASS && sym->attr.class_ok)
+	target = CLASS_DATA (sym)->attr.target;
+  else
+	target = sym->attr.target;
+
+  if (!target && !proc_pointer)
+	{
+	  gfc_error ("Pointer assignment target in initialization expression "
+		 "does not have the TARGET attribute at %L",
+		 >where);
+	  return false;
+	}
 }
+  else
+{
+  if (!attr.target && !attr.pointer)
+	{
+	  gfc_error ("Pointer assignment target is neither TARGET "
+		 "nor POINTER at %L", >where);
+	  return false;
+	}
+}
 
   if (is_pure && gfc_impure_variable (rvalue->symtree->n.sym))
 {
@@ -4262,7 +4286,7 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_comp
 }
 
   if (pointer || proc_pointer)
-r = gfc_check_pointer_assign (, rvalue);
+r = gfc_check_pointer_assign (, rvalue, false, true);
   else
 {
   /* If a conversion function, e.g., __convert_i8_i4, was inserted
Index: fortran/gfortran.h
===
--- fortran/gfortran.h	(Revision 268475)
+++ fortran/gfortran.h	(Arbeitskopie)
@@ -3247,7 +3247,8 @@ int gfc_kind_max (gfc_expr *, gfc_expr *);
 bool gfc_check_conformance (gfc_expr *, gfc_expr *, const char *, ...) ATTRIBUTE_PRINTF_3;
 bool gfc_check_assign (gfc_expr *, gfc_expr *, int, bool c = true);
 bool gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue,
-  bool suppres_type_test = false);
+			   bool suppres_type_test = false,
+			   bool is_init_expr = false);
 bool gfc_check_assign_symbol (gfc_symbol *, gfc_component *, gfc_expr *);
 
 gfc_expr *gfc_build_default_init_expr (gfc_typespec *, locus *);
Index: testsuite/gfortran.dg/pointer_init_2.f90
===
--- testsuite/gfortran.dg/pointer_init_2.f90	(Revision 268432)
+++ testsuite/gfortran.dg/pointer_init_2.f90	(Arbeitskopie)
@@ -18,7 +18,7 @@ subroutine sub
   integer, pointer :: dp0 => 13  ! { dg-error "Error in pointer initialization" }
   integer, pointer :: dp1 => r   ! { dg-error "Different types in pointer assignment" }
   integer, pointer :: dp2 => v   ! { dg-error "Different ranks in pointer assignment" }
-  integer, pointer :: dp3 => i   ! { dg-error "is neither TARGET nor POINTER" }
+  

[committed] Fix locations in conversion_null_warnings (PR c++/71302)

[David Malcolm]

PR c++/71302 reports that g++ shows poor locations for
-Wzero-as-null-pointer-constant for pointers in function calls,
using the close parenthesis of the call, rather than showing the
pertinent argument.

This particular case was fixed in GCC 8, but regressed on trunk
in r260973.

This patch fixes the regression, and adds column numbers to the
test cases (where they're correct) to avoid regressing them in the
future.  There are still various places where the locations aren't
correct, but fixing them isn't stage 4 material.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
adds 21 PASS results to g++.sum.

Committed to trunk as r268589.

gcc/cp/ChangeLog:
PR c++/71302
* call.c (get_location_for_expr_unwinding_for_system_header): New
function.
(conversion_null_warnings): Use it when getting locations for
EXPR, effectively adding a call to
get_location_for_expr_unwinding_for_system_header for
-Wconversion-null and making use of EXPR_LOCATION for
-Wzero-as-null-pointer-constant.

gcc/testsuite/ChangeLog:
PR c++/71302
* g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C: Add expected
column numbers to dg-warning directives where they are correct.
* g++.dg/warn/Wzero-as-null-pointer-constant-5.C: Likewise.
* g++.dg/warn/Wzero-as-null-pointer-constant-7.C: Likewise.
* g++.dg/warn/Wzero-as-null-pointer-constant-8.C: New test.
---
 gcc/cp/call.c  | 24 ---
 .../cpp0x/Wzero-as-null-pointer-constant-1.C   |  8 ++--
 .../g++.dg/warn/Wzero-as-null-pointer-constant-1.C | 36 -
 .../g++.dg/warn/Wzero-as-null-pointer-constant-5.C |  2 +-
 .../g++.dg/warn/Wzero-as-null-pointer-constant-7.C |  4 +-
 .../g++.dg/warn/Wzero-as-null-pointer-constant-8.C | 47 ++
 6 files changed, 91 insertions(+), 30 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-8.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c74d1b4..0f0a1f5 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6718,6 +6718,22 @@ build_temp (tree expr, tree type, int flags,
   return expr;
 }
 
+/* Get any location for EXPR, falling back to input_location.
+
+   If the result is in a system header and is the virtual location for
+   a token coming from the expansion of a macro, unwind it to the
+   location of the expansion point of the macro (e.g. to avoid the
+   diagnostic being suppressed for expansions of NULL where "NULL" is
+   in a system header).  */
+
+static location_t
+get_location_for_expr_unwinding_for_system_header (tree expr)
+{
+  location_t loc = EXPR_LOC_OR_LOC (expr, input_location);
+  loc = expansion_point_location_if_in_system_header (loc);
+  return loc;
+}
+
 /* Perform warnings about peculiar, but valid, conversions from/to NULL.
Also handle a subset of zero as null warnings.
EXPR is implicitly converted to type TOTYPE.
@@ -6730,8 +6746,7 @@ conversion_null_warnings (tree totype, tree expr, tree 
fn, int argnum)
   if (null_node_p (expr) && TREE_CODE (totype) != BOOLEAN_TYPE
   && ARITHMETIC_TYPE_P (totype))
 {
-  location_t loc = EXPR_LOC_OR_LOC (expr, input_location);
-  loc = expansion_point_location_if_in_system_header (loc);
+  location_t loc = get_location_for_expr_unwinding_for_system_header 
(expr);
   if (fn)
{
  auto_diagnostic_group d;
@@ -6750,7 +6765,7 @@ conversion_null_warnings (tree totype, tree expr, tree 
fn, int argnum)
   else if (TREE_CODE (TREE_TYPE (expr)) == BOOLEAN_TYPE
   && TYPE_PTR_P (totype))
 {
-  location_t loc = EXPR_LOC_OR_LOC (expr, input_location);
+  location_t loc = get_location_for_expr_unwinding_for_system_header 
(expr);
   if (fn)
{
  auto_diagnostic_group d;
@@ -6769,8 +6784,7 @@ conversion_null_warnings (tree totype, tree expr, tree 
fn, int argnum)
   else if (null_ptr_cst_p (expr) &&
   (TYPE_PTR_OR_PTRMEM_P (totype) || NULLPTR_TYPE_P (totype)))
 {
-  location_t loc =
-   expansion_point_location_if_in_system_header (input_location);
+  location_t loc = get_location_for_expr_unwinding_for_system_header 
(expr);
   maybe_warn_zero_as_null_pointer_constant (expr, loc);
 }
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C 
b/gcc/testsuite/g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
index a9dd155..e280a05 100644
--- a/gcc/testsuite/g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C
@@ -64,16 +64,16 @@ void f()
   if (!p)
 ;
 
-  if (pmf == 0) // { dg-warning "zero as null pointer" }
+  if (pmf == 0) // { dg-warning "14: zero as null pointer" }
 ;
   
-  if (pdm == 0) // { dg-warning "zero as null pointer" }
+  if (pdm == 0) // { dg-warning "14: zero as null pointer" }
 ;
 
-  if (pf == 0)  // { 

New Esperanto PO file for 'cpplib' (version 9.1-b20190203)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'cpplib-9.1-b20190203.eo.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Contents of PO file 'cpplib-9.1-b20190203.eo.po'

[Translation Project Robot]

cpplib-9.1-b20190203.eo.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [Patch] [arm] Fix 88714, Arm LDRD/STRD peepholes

[Kyrill Tkachov]

Hi Matthew,

On 05/02/19 14:44, Matthew Malcomson wrote:

These peepholes match a pair of SImode loads or stores that can be
implemented with a single LDRD or STRD instruction.
When compiling for TARGET_ARM, these peepholes originally created a set
pattern in DI mode to be caught by movdi patterns.

This approach failed to take into account the possibility that the two
matched insns operated on memory with different aliasing information.
The peepholes lost the aliasing information on one of the insns, which
could then cause the scheduler to make an invalid transformation.

This patch changes the peepholes so they generate a PARALLEL expression
of the two relevant loads or stores, which means the aliasing
information of both is kept.  Such a PARALLEL pattern is what the
peepholes currently produce for TARGET_THUMB2.

In order to match these new insn patterns, we add two new define_insn's.  These
define_insn's use the same checks as the peepholes to find valid insns.

Note that the patterns now created by the peepholes for LDRD and STRD
are very similar to those created by the peepholes for LDM and STM.
Many patterns could be matched by the LDM and STM define_insns, which
means we rely on the order the define_insn patterns are defined in the
machine description, with those for LDRD/STRD defined before those for
LDM/STM.

The difference between the peepholes for LDRD/STRD and those for LDM/STM
are mainly that those for LDRD/STRD have some logic to ensure that the
two registers are consecutive and the first one is even.

Bootstrapped and regtested on arm-none-linux-gnu.
Demonstrated fix of bug 88714 by bootstrapping on armv7l.


gcc/ChangeLog:

2019-02-05  Matthew Malcomson 

PR bootstrap/88714
* config/arm/arm-protos.h (valid_operands_ldrd_strd,
arm_count_ldrdstrd_insns): New declarations.
* config/arm/arm.c (mem_ok_for_ldrd_strd): Remove broken handling of
MINUS.
(valid_operands_ldrd_strd): New function.
(arm_count_ldrdstrd_insns): New function.
* config/arm/ldrdstrd.md: Change peepholes to generate PARALLEL SImode
sets instead of single DImode set and define new insns to match this.

gcc/testsuite/ChangeLog:

2019-02-05  Matthew Malcomson 

* gcc.c-torture/execute/pr88714.c: New test.
* gcc.dg/rtl/arm/ldrd-peepholes.c: New test.



Please add the PR marker to the testsuite ChangeLog as well.
I've been following this PR a bit from the sidelines, I believe a substantial 
amount of code
(and one of the testcases) was written by Jakub, so please add him to the 
ChangeLog entries as well.

This looks ok to me.
Thanks for fixing this and thanks Jakub for the analysis and fixes too!

Kyrill




### Attachment also inlined for ease of reply###


diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 
79ede0db174fcce87abe8b4d18893550d4c7e2f6..485bc68a618d6ae4a1640368ccb025fe2c9e1420
 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -125,6 +125,7 @@ extern rtx arm_gen_store_multiple (int *, int, rtx, int, 
rtx, HOST_WIDE_INT *);
 extern bool offset_ok_for_ldrd_strd (HOST_WIDE_INT);
 extern bool operands_ok_ldrd_strd (rtx, rtx, rtx, HOST_WIDE_INT, bool, bool);
 extern bool gen_operands_ldrd_strd (rtx *, bool, bool, bool);
+extern bool valid_operands_ldrd_strd (rtx *, bool);
 extern int arm_gen_movmemqi (rtx *);
 extern bool gen_movmem_ldrd_strd (rtx *);
 extern machine_mode arm_select_cc_mode (RTX_CODE, rtx, rtx);
@@ -146,6 +147,7 @@ extern const char *output_mov_long_double_arm_from_arm (rtx 
*);
 extern const char *output_move_double (rtx *, bool, int *count);
 extern const char *output_move_quad (rtx *);
 extern int arm_count_output_move_double_insns (rtx *);
+extern int arm_count_ldrdstrd_insns (rtx *, bool);
 extern const char *output_move_vfp (rtx *operands);
 extern const char *output_move_neon (rtx *operands);
 extern int arm_attr_length_move_neon (rtx_insn *);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
73cb8df9af1ec9d680091bb8691bcd925a1be1d3..1c336da9e5b0948ef1058c46966364510dc1ca38
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -15556,7 +15556,7 @@ mem_ok_for_ldrd_strd (rtx mem, rtx *base, rtx *offset, 
HOST_WIDE_INT *align)
   *base = addr;
   return true;
 }
-  else if (GET_CODE (addr) == PLUS || GET_CODE (addr) == MINUS)
+  else if (GET_CODE (addr) == PLUS)
 {
   *base = XEXP (addr, 0);
   *offset = XEXP (addr, 1);
@@ -15721,7 +15721,7 @@ gen_operands_ldrd_strd (rtx *operands, bool load,
 }

   /* Make sure accesses are to consecutive memory locations.  */
-  if (gap != 4)
+  if (gap != GET_MODE_SIZE (SImode))
 return false;

   if (!align_ok_ldrd_strd (align[0], offset))
@@ -15802,6 +15802,55 @@ gen_operands_ldrd_strd (rtx *operands, bool load,
 }


+/* Return true if parallel execution of the two word-size accesses provided
+   could be satisfied with a single 

Re: [PATCH doc] correct/expand -Wreturn-type

[Martin Sebor]

On 2/6/19 10:20 AM, Jakub Jelinek wrote:

On Wed, Feb 06, 2019 at 10:15:27AM -0700, Martin Sebor wrote:

-For C++, a function without return type always produces a diagnostic
-message, even when @option{-Wno-return-type} is specified.  The only
-exceptions are @code{main} and functions defined in system headers.
+For C++, calling a non-@code{void} function other than @code{main} that flows
+off the end is undefined even if the value of the function is not used.


That is not true, the undefined behavior is not when calling such a function,
but only when it flows off the end.  So, it is perfectly fine if you have:
int
foo (int x)
{
if (x > 10)
  return 20;
}
and you only ever call foo with x > 10, or if you have:
int
bar ()
{
baz ();
}
and baz always throws, or never returns etc.  So, if we try to clarify, we
should clarify it correctly.


Sigh.  Was that jab really necessary?

The C++ standard says:

   ...flowing off the end of a function other than main (6.6.1)
   results in undefined behavior.

It doesn't mention anything about calling the function so it seems
to me the text I added is no less correct or clear than that.  I see
no point in going into unlikely corner cases that the standard itself
make provisions for.


Your new text talks about calling the function though, which might be read as 
that
the UB is already when you call such a function.


The purpose of referring to calling the function is to clearly
distinguish the C++ undefined behavior from that in C.  I see
absolutely no value in trying to carefully explain that it is
possible to call functions that forget to return a value without
running into undefined behavior.


Why don't you use the
standard wording instead, i.e.
"For C++, flowing off the end of a function other than @code{main} is
undefined even if the return value from the function is not used in the
caller."
or similar?


You just reversed the two subsentences:

  calling a non-@code{void} function other than @code{main}
  that flows off the end is undefined even if the value of the function
  is not used.

vs

  flowing off the end of a function other than @code{main} is
  undefined even if the return value from the function is not used
  in the caller.

But whatever.  Attached is a change with the subsentences reversed.

Martin
gcc/ChangeLog:

	* doc/invoke.texi (-Wreturn-type): Correct and expand.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 268583)
+++ gcc/doc/invoke.texi	(working copy)
@@ -5261,13 +5261,16 @@ without a value).
 For C only, warn about a @code{return} statement with an expression in a
 function whose return type is @code{void}, unless the expression type is
 also @code{void}.  As a GNU extension, the latter case is accepted
-without a warning unless @option{-Wpedantic} is used.
+without a warning unless @option{-Wpedantic} is used.  Attempting
+to use the return value of a non-@code{void} function other than @code{main}
+that flows off the end by reaching the closing curly brace that terminates
+the function is undefined.
 
-For C++, a function without return type always produces a diagnostic
-message, even when @option{-Wno-return-type} is specified.  The only
-exceptions are @code{main} and functions defined in system headers.
+Unlike in C, in C++, flowing off the end of a non-@code{void} function other
+than @code{main} results in undefined behavior even when the value of
+the function is not used.
 
-This warning is enabled by default for C++ and is enabled by @option{-Wall}.
+This warning is enabled by default in C++ and by @option{-Wall} otherwise.
 
 @item -Wshift-count-negative
 @opindex Wshift-count-negative

Re: [Aarch64][SVE] Vectorise sum-of-absolute-differences

[James Greenhalgh]

On Mon, Feb 04, 2019 at 07:34:05AM -0600, Alejandro Martinez Vicente wrote:
> Hi,
> 
> This patch adds support to vectorize sum of absolute differences (SAD_EXPR)
> using SVE. It also uses the new functionality to ensure that the resulting 
> loop
> is masked. Therefore, it depends on
> 
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00016.html
> 
> Given this input code:
> 
> int
> sum_abs (uint8_t *restrict x, uint8_t *restrict y, int n)
> {
>   int sum = 0;
> 
>   for (int i = 0; i < n; i++)
> {
>   sum += __builtin_abs (x[i] - y[i]);
> }
> 
>   return sum;
> }
> 
> The resulting SVE code is:
> 
>  :
>0: 715fcmp w2, #0x0
>4: 5400026db.le50 
>8: d283mov x3, #0x0// #0
>c: 93407c42sxtwx2, w2
>   10: 2538c002mov z2.b, #0
>   14: 25221fe0whilelo p0.b, xzr, x2
>   18: 2538c023mov z3.b, #1
>   1c: 2518e3e1ptrue   p1.b
>   20: a4034000ld1b{z0.b}, p0/z, [x0, x3]
>   24: a4034021ld1b{z1.b}, p0/z, [x1, x3]
>   28: 0430e3e3incbx3
>   2c: 0520c021sel z1.b, p0, z1.b, z0.b
>   30: 25221c60whilelo p0.b, x3, x2
>   34: 040d0420uabdz0.b, p1/m, z0.b, z1.b
>   38: 44830402udotz2.s, z0.b, z3.b
>   3c: 5421b.ne20   // b.any
>   40: 2598e3e0ptrue   p0.s
>   44: 04812042uaddv   d2, p0, z2.s
>   48: 1e260040fmovw0, s2
>   4c: d65f03c0ret
>   50: 1e2703e2fmovs2, wzr
>   54: 1e260040fmovw0, s2
>   58: d65f03c0ret
> 
> Notice how udot is used inside a fully masked loop.
> 
> I tested this patch in an aarch64 machine bootstrapping the compiler and
> running the checks.

This doesn't give us much confidence in SVE coverage; unless you have
been running in an environment using SVE by default? Do you have some set
of workloads you could test the compiler against to ensure correct operation
of the SVE vectorization?

> 
> I admit it is too late to merge this into gcc 9, but I'm posting it anyway so
> it can be considered for gcc 10.

Richard Sandiford has the call on whether this patch is OK for trunk now or
GCC 10. With the minimal testing it has had, I'd be uncomfortable with it as
a GCC 9 patch. That said, it is a fairly self-contained pattern for the
compiler and it would be good to see this optimization in GCC 9.

> 
> Alejandro
> 
> 
> gcc/Changelog:
> 
> 2019-02-04  Alejandro Martinez  
> 
>   * config/aarch64/aarch64-sve.md (abd_3): New define_expand.
>   (aarch64_abd_3): Likewise.
>   (*aarch64_abd_3): New define_insn.
>   (sad): New define_expand.
>   * config/aarch64/iterators.md: Added MAX_OPP and max_opp attributes.
>   Added USMAX iterator.
>   * config/aarch64/predicates.md: Added aarch64_smin and aarch64_umin
>   predicates.
>   * tree-vect-loop.c (use_mask_by_cond_expr_p): Add SAD_EXPR.
>   (build_vect_cond_expr): Likewise.
> 
> gcc/testsuite/Changelog:
>  
> 2019-02-04  Alejandro Martinez  
> 
>   * gcc.target/aarch64/sve/sad_1.c: New test for sum of absolute
>   differences.

Re: [PATCH][AArch64] Use implementation namespace consistently in arm_neon.h

[Kyrill Tkachov]

Hi James,

On 06/02/19 17:27, James Greenhalgh wrote:

On Wed, Feb 06, 2019 at 07:52:42AM -0600, Kyrill Tkachov wrote:

[resending with patch compressed]

Hi all,

We're somewhat inconsistent in arm_neon.h when it comes to using the 
implementation namespace for local
identifiers. This means things like:
#define hash_abcd 0
#define hash_e 1
#define wk 2

#include "arm_neon.h"

uint32x4_t
foo (uint32x4_t a, uint32_t b, uint32x4_t c)
{
return vsha1cq_u32 (a, b, c);
}

don't compile.
This patch fixes these issues throughout the whole of arm_neon.h
Bootstrapped and tested on aarch64-none-linux-gnu.
The advsimd-intrinsics.exp tests pass just fine.

Don't feel sorry for me having to write the ChangeLog. ./contrib/mklog.pl 
automated the whole thing.

Ok for trunk?

I assume you've just run some simple sed over this file.

I'd rather review them than the patch; what were they?


I... errr.. I did it semi-manually in my graphical editor by doing 
search-and-replace for things like
" a)" -> " __a)" , " a," -> " __a," , ")a " -> ")__a " etc.

Same for 'b', 'c', 'd', 'r', 'temp', 'val', 'result' and any other offending 
identifier I could spot.
I left things like the "val" in:
typedef struct int8x8x2_t
{
  int8x8_t val[2];
} int8x8x2_t;

alone, but there were some uses of the identifier "val" as an intrinsic parameter so I 
converted those to "__val"

If any of the changes are invalid (changing parameter name in intrinsic, but 
not its use for example) then any testcase using arm_neon.h breaks,
even if the intrinsic in question is not used, so I expect the testing enforces 
the correctness.

Thanks,
Kyrill



James


2019-02-06  Kyrylo Tkachov  

  * config/aarch64/arm_neon.h (vaba_s8): Use __ in identifiers
  consistenly.

Re: [PATCH] PR libstdc++/89102 fix common_type<> and common_type specializations

[Jonathan Wakely]

On 06/02/19 17:25 +, Jonathan Wakely wrote:

This is a partial implementation of the revised std::common_type rules
from P0435R1.

PR libstdc++/89102 (partial)
* include/std/type_traits (common_type<>): Define.
(common_type): Derive from common_type.
* testsuite/20_util/common_type/requirements/explicit_instantiation.cc:
Test zero-length template argument list.
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Test additional single argument cases.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Adjust expected error.

Tested powerpc64le-linux, committed to trunk.

I think this could be backported to gcc-8-branch too.

I have a complete patch for stage 1 which I'll post in a minute.


This is the complee patch, but it changes the semantics in a few cases
involving user specializations, so I'll wait for stage 1 (and then
maybe backport it to gcc-9-branch later).


commit 6d5355fc251047d71c5262a38e6c4fe590a20905
Author: Jonathan Wakely 
Date:   Wed Feb 6 11:51:37 2019 +

PR libstdc++/89102 implement new common_type rules (P0435R1, P0548R1)

This change ensures that std::common_type<> is a complete type (LWG
2408), and that std::common_type, std::common_type, and
std::common_type will use program-defined specializations
for std::common_type (LWG 2465).

The implementation of common_type is changed to use
void_t, and the specializations for duration and time_point are modified
to also use void_t instead of depending on implementation details of
common_type.

PR libstdc++/89102
* include/std/chrono (__duration_common_type_wrapper): Replace with ...
(__duration_common_type): New helper.
(common_type, chrono::duration>): Use
__duration_common_type.
(__timepoint_common_type_wrapper): Replace with ...
(__timepoint_common_type): New helper.
(common_type, chrono::time_point>):
Use __time_point_common_type.
* include/std/type_traits (common_type<>): Define, as per LWG 2408.
(__common_type_impl): If either argument is transformed by decay,
use the common_type of the decayed types.
(__common_type_impl<_Tp, _Up, _Tp, _Up>): If the types are already
decayed, use __do_common_type_impl to get the common_type.
(common_type<_Tp>): Use common_type<_Tp, _Tp>.
(__do_member_type_wrapper, __member_type_wrapper)
(__expanded_common_type_wrapper): Remove.
(__common_type_pack, __common_type_fold): New helpers.
(common_type<_Tp, _Up, _Vp...>): Use new helpers instead of
__member_type_wrapper and __expanded_common_type_wrapper.
* testsuite/20_util/common_type/requirements/explicit_instantiation.cc:
Test zero-length template argument list.
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Test single argument cases and argument types that should decay.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Adjust expected error.
* testsuite/20_util/duration/literals/range_neg.cc: Use zero for
dg-error lineno.
* testsuite/20_util/duration/requirements/typedefs_neg1.cc: Likewise.
* testsuite/20_util/duration/requirements/typedefs_neg2.cc: Likewise.
* testsuite/20_util/duration/requirements/typedefs_neg3.cc: Likewise.

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index 9e63fa9c698..8cef79ea3e6 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -67,48 +67,51 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // 20.11.4.3 specialization of common_type (for duration, sfinae-friendly)
 
+  template
+struct __duration_common_type
+{ };
+
   template
-struct __duration_common_type_wrapper
+struct __duration_common_type<_CT, _Period1, _Period2,
+  __void_t>
 {
 private:
-  typedef __static_gcd<_Period1::num, _Period2::num> __gcd_num;
-  typedef __static_gcd<_Period1::den, _Period2::den> __gcd_den;
-  typedef typename _CT::type __cr;
-  typedef ratio<__gcd_num::value,
-(_Period1::den / __gcd_den::value) * _Period2::den> __r;
+  using __gcd_num = __static_gcd<_Period1::num, _Period2::num>;
+  using __gcd_den = __static_gcd<_Period1::den, _Period2::den>;
+  using __cr = typename _CT::type;
+  using __r = ratio<__gcd_num::value,
+			(_Period1::den / __gcd_den::value) * _Period2::den>;
+
 public:
-  typedef __success_type> type;
+  using type = chrono::duration<__cr, __r>;
 };
 
   template
-struct __duration_common_type_wrapper<__failure_type, _Period1, _Period2>
+struct __duration_common_type<__failure_type, _Period1, _Period2>
 { typedef 

Re: [PATCH doc] correct/expand -Wreturn-type

[Jakub Jelinek]

On Wed, Feb 06, 2019 at 06:20:35PM +0100, Jakub Jelinek wrote:
> "For C++, flowing off the end of a function other than @code{main} is

Oops, either replace function above with value-returning function, or
non-@code{void} function.

> undefined even if the return value from the function is not used in the
> caller."
> or similar?

Jakub

Re: [PATCH][AArch64] Change representation of SABD in RTL

[James Greenhalgh]

On Mon, Feb 04, 2019 at 04:23:32AM -0600, Kyrill Tkachov wrote:
> Hi all,
> 
> Richard raised a concern about the RTL we use to represent the AdvSIMD SABD
> (vector signed absolute difference) instruction.
> We currently represent it as ABS (MINUS op1 op2).
> 
> This isn't exactly what SABD does. ABS treats its input as a signed value
> and returns the absolute of that.
> 
> For example:
> (sabd:QI 64 -128) == 192 (unsigned) aka -64 (signed)
> whereas
> (minus:QI 64 -128) == 192 (unsigned) aka -64 (signed), (abs ...) of that is 
> 64.
> 
> A better way to describe the instruction is with MINUS (SMAX (op1 op2) SMIN 
> (op1 op2)).
> This patch implements that, and also implements similar semantics for the 
> UABD instruction
> that uses UMAX and UMIN.
> 
> That way for the example above we'll have:
> (minus:QI (smax:QI (64 -128)) (smin:QI (64 -128))) == (minus:QI 64 -128) == 
> 192 (or -64 signed) which matches
> what SABD does.
> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> 
> Ok for trunk?

Not without a comment explaining the above subtlety and preferably a
testcase which would fail today on trunk.

Otherwise, OK.

James

> 
> Thanks,
> Kyrill
> 
> 2019-04-02  Kyrylo Tkachov  
> 
>  * config/aarch64/iterators.md (max_opp): New code_attr.
>  (USMAX): New code iterator.
>  * config/aarch64/predicates.md (aarch64_smin): New predicate.
>  (aarch64_smax): Likewise.
>  * config/aarch64/aarch64-simd.md (abd_3): Rename to...
>  (*aarch64_abd_3): ... Change RTL representation to
>  MINUS (MAX MIN).
> 
> 2019-04-02  Kyrylo Tkachov  
> 
>  * gcc.target/aarch64/abd_1.c: New test.

Re: [PATCH][AArch64] Use neon_dot_q type for 128-bit [US]DOT instructions where appropriate

[James Greenhalgh]

On Tue, Feb 05, 2019 at 11:52:10AM -0600, Kyrill Tkachov wrote:
> Hi all,
> 
> For the Dot Product instructions we have the scheduling types neon_dot and 
> neon_dot_q for the 128-bit versions.
> It seems that we're only using the former though, not assigning the 
> neon_dot_q type anywhere.
> 
> This patch fixes that by adding the  mode attribute suffix to the type, 
> similar to how we do it for other
> types in aarch64-simd.md.
> 
> Bootstrapped and tested on aarch64-none-linux-gnu.
> 
> Ok for trunk?

OK.

James

> 2019-05-02  Kyrylo Tkachov  
> 
>  * config/aarch64/aarch64-simd.md (aarch64_dot): Use 
> neon_dot for type.
>  (aarch64_dot_lane): Likewise.
>  (aarch64_dot_laneq): Likewise.

Re: [PATCH][AArch64] Use implementation namespace consistently in arm_neon.h

[James Greenhalgh]

On Wed, Feb 06, 2019 at 07:52:42AM -0600, Kyrill Tkachov wrote:
> [resending with patch compressed]
> 
> Hi all,
> 
> We're somewhat inconsistent in arm_neon.h when it comes to using the 
> implementation namespace for local
> identifiers. This means things like:
> #define hash_abcd 0
> #define hash_e 1
> #define wk 2
> 
> #include "arm_neon.h"
> 
> uint32x4_t
> foo (uint32x4_t a, uint32_t b, uint32x4_t c)
> {
>return vsha1cq_u32 (a, b, c);
> }
> 
> don't compile.
> This patch fixes these issues throughout the whole of arm_neon.h
> Bootstrapped and tested on aarch64-none-linux-gnu.
> The advsimd-intrinsics.exp tests pass just fine.
> 
> Don't feel sorry for me having to write the ChangeLog. ./contrib/mklog.pl 
> automated the whole thing.
> 
> Ok for trunk?

I assume you've just run some simple sed over this file.

I'd rather review them than the patch; what were they?

James

> 2019-02-06  Kyrylo Tkachov  
> 
>  * config/aarch64/arm_neon.h (vaba_s8): Use __ in identifiers
>  consistenly.

Re: [testsuite] Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451)

[Richard Biener]

On February 6, 2019 3:47:19 PM GMT+01:00, Rainer Orth 
 wrote:
>Hi Richard,
>
>> On Fri, 4 Jan 2019, Rainer Orth wrote:
>>
>>> Hi Richard,
>>> 
>>> >> On Thu, 3 Jan 2019, Rainer Orth wrote:
>>> >>
>>> >>> gcc.dg/debug/dwarf2/inline5.c currently FAILs with Solaris as
>(both
>>> >>> sparc and x86):
>>> >>> 
>>> >>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not (DIE
>>> >>> (0x([0-9a-f]*)) DW_TAG_lexical_block)[^#/!]*[#/!]
>>> >>> [^(].*DW_TAG_lexical_block)[^#/!x]*x1[^#/!]*[#/!]
>>> >>> DW_AT_abstract_origin
>>> >>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>>> >>> DW_TAG_lexical_block)[^#/!]*[#/!] (DIE
>(0x[0-9a-f]*)
>>> >>> DW_TAG_variable 1
>>> >>> 
>>> >>> The first failure seems to be caused because .* performs
>multiline
>>> >>> matches by default in Tcl; tightening it to [^\n]* avoids the
>problem.
>>> >>
>>> >> Hmm, but the matches are supposed to match multiple lines...  how
>>> >> does it fail for you?
>>> >
>>> > it matches all of
>>> >
>>> > (DIE (0x19f) DW_TAG_lexical_block)
>>> > .byte   0xd / uleb128 0xd; (DIE (0x1a0)
>DW_TAG_variable)
>>> > .ascii "j"  / DW_AT_name
>>> > .byte   0x1 / DW_AT_decl_file
>(/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c)
>>> > .byte   0x12/ DW_AT_decl_line
>>> > .byte   0x14/ DW_AT_decl_column
>>> > .long   0x17f   / DW_AT_type
>>> > .byte   0   / end of children of DIE 0x19f
>>> > .byte   0   / end of children of DIE 0x184
>>> > .byte   0xe / uleb128 0xe; (DIE (0x1ac)
>DW_TAG_subprogram)
>>> > .long   0x184   / DW_AT_abstract_origin
>>> > .long   .LFB0   / DW_AT_low_pc
>>> > .long   .LFE0-.LFB0 / DW_AT_high_pc
>>> > .byte   0x1 / uleb128 0x1; DW_AT_frame_base
>>> > .byte   0x9c/ DW_OP_call_frame_cfa
>>> > / DW_AT_GNU_all_call_sites
>>> > .byte   0xf / uleb128 0xf; (DIE (0x1bb)
>DW_TAG_formal_parameter)
>>> > .long   0x195   / DW_AT_abstract_origin
>>> > .byte   0x2 / uleb128 0x2; DW_AT_location
>>> > .byte   0x91/ DW_OP_fbreg
>>> > .byte   0   / sleb128 0
>>> > .byte   0x6 / uleb128 0x6; (DIE (0x1c3)
>DW_TAG_lexical_block)
>>> > .long   0x19f   / DW_AT_abstract_origin
>>> >
>>> > while with gas there's instead
>>> >
>>> >   .uleb128 0xc/ (DIE (0xad) DW_TAG_lexical_block)
>>> >   .uleb128 0xd/ (DIE (0xae) DW_TAG_variable)
>>> >   .ascii "j\0"/ DW_AT_name
>>> >   .byte   0x1 / DW_AT_decl_file
>(/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c)
>>> >
>>> > i.e. the pattern doesn't match with gas due to the [^(] while with
>as we
>>> > have uleb128 first which does match, producing the failure (which
>shows
>>> > that that part of my patch is wrong).
>>> 
>>> I still have a hard time determining what to do here.  I've now
>reverted
>>> the tree to r264642, i.e. the one before the PR debug/87443 patch. 
>Then
>>> I build on x86_64-pc-linux-gnu and ran the inline5.c testcase
>against
>>> the old compiler.  I'd have expected all the scan-assembler* tests
>to
>>> FAIL here, but instead I get
>>> 
>>> PASS: gcc.dg/debug/dwarf2/inline5.c (test for excess errors)
>>> PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>>> DW_TAG_inlined_subrouti
>>> ne 2
>>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>>> DW_TAG_lexical_block\\)
>>> [^#/!]*[#/!] DW_AT_abstract_origin 2
>>> PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>>> DW_TAG_lexical_block\\)
>>> [^#/!]*[#/!] \\(DIE \\(0x[0-9a-f]*\\) DW_TAG_variable 1
>>> PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not \\(DIE
>>> \\(0x([0-9a-f]*)\\
>>> ) DW_TAG_lexical_block\\)[^#/!]*[#/!]
>>> [^(].*DW_TAG_lexical_block\\)[^#/!x]*x\\1[
>>> ^#/!]*[#/!] DW_AT_abstract_origin
>>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not
>>> DW_TAG_lexical_block\\)[^
>>> #/!x]*x([0-9a-f]*)[^#/!]*[#/!] DW_AT_abstract_origin.*\\(DIE
>\\(0x\\1\\)
>>> DW_TAG_
>>> lexical_block\\)[^#/!]*[#/!] DW_AT
>>> 
>>> i.e. the problematic scan-assembler-not test PASSes before and after
>>> your patch, making it hard to determine what that test is guarding
>>> against (i.e. what is matched on Linux/x86_64 or Solaris with gas)
>and
>>> adapting it to the Solaris as syntax.
>>
>> Yeah, the issue is I applied patches in another order than I
>developed
>> the testcases...  I think you need to back out the PR87428/87362
>> fix to see this FAIL happening.
>>
>> What we want to not see is a lexical block used as abstract origin
>> that has further attributes.  GCC 8 shows bogus DWARF:
>>
>>  <2><5c>: Abbrev Number: 4 (DW_TAG_inlined_subroutine)
>> <5d>   DW_AT_abstract_origin: <0xa9>
>> <61>   DW_AT_low_pc  : 0xf
>> <69>   DW_AT_high_pc : 0xf
>> <71>   DW_AT_call_file   : 1
>> <72>   DW_AT_call_line   : 10
>> <73>   

[PATCH] PR libstdc++/89102 fix common_type<> and common_type specializations

[Jonathan Wakely]

This is a partial implementation of the revised std::common_type rules
from P0435R1.

PR libstdc++/89102 (partial)
* include/std/type_traits (common_type<>): Define.
(common_type): Derive from common_type.
* testsuite/20_util/common_type/requirements/explicit_instantiation.cc:
Test zero-length template argument list.
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Test additional single argument cases.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Adjust expected error.

Tested powerpc64le-linux, committed to trunk.

I think this could be backported to gcc-8-branch too.

I have a complete patch for stage 1 which I'll post in a minute.

commit e5f7ac8d78351f41edd752c94c92fe1a389bdca7
Author: Jonathan Wakely 
Date:   Wed Feb 6 16:27:03 2019 +

PR libstdc++/89102 fix common_type<> and common_type specializations

This is a partial implementation of the revised std::common_type rules
from P0435R1.

PR libstdc++/89102 (partial)
* include/std/type_traits (common_type<>): Define.
(common_type): Derive from common_type.
* 
testsuite/20_util/common_type/requirements/explicit_instantiation.cc:
Test zero-length template argument list.
* testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc:
Test additional single argument cases.
* testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc:
Adjust expected error.

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index f05a583cb04..bc2250d9dce 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -2132,9 +2132,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct __expanded_common_type_wrapper<__failure_type, _Args...>
 { typedef __failure_type type; };
 
+  template<>
+struct common_type<>
+{ };
+
   template
 struct common_type<_Tp>
-{ typedef typename decay<_Tp>::type type; };
+: common_type<_Tp, _Tp>
+{ };
 
   template
 struct common_type<_Tp, _Up>
diff --git 
a/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc
 
b/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc
index 28535a80d64..dc57ab5ad8e 100644
--- 
a/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc
+++ 
b/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc
@@ -30,6 +30,7 @@ namespace std
   typedef void test_type5;
   typedef const void test_type6;  
 
+  template struct common_type<>;
   template struct common_type;
   template struct common_type;
   template struct common_type;
diff --git 
a/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc 
b/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
index 372c1a58378..9b94eb13434 100644
--- 
a/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
+++ 
b/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
@@ -159,7 +159,10 @@ namespace std {
   };
 }
 
+static_assert(is_type, int>(), "");
+static_assert(is_type, int>(), "");
 static_assert(is_type, int>(), "");
+static_assert(is_type, int>(), "");
 static_assert(is_type, ScEn>(), "");
 static_assert(is_type, UnscEn>(), "");
 static_assert(is_type, int>(), "");
@@ -180,6 +183,8 @@ static_assert(is_type,
  const volatile int*>(), "");
 static_assert(is_type,
  const volatile void*>(), "");
+static_assert(is_type, void>(), "");
+static_assert(is_type, void>(), "");
 static_assert(is_type, void>(), "");
 static_assert(is_type, void>(), "");
 static_assert(is_type, int>(), "");
@@ -316,6 +321,14 @@ static_assert(!has_type>(), "");
 static_assert(!has_type,
 std::initializer_list>>(), "");
 
+// PR libstdc++/89102
+static_assert(!has_type>(), "");
+static_assert(!has_type>(), "");
+static_assert(!has_type>(), "");
+static_assert(!has_type>(), "");
+static_assert(!has_type>(), "");
+static_assert(!has_type>(), "");
+
 void test(int i)
 {
   auto local_lmd1 = [=](int, double) { return i + i; };
diff --git 
a/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc 
b/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc
index 64c8ea9339e..8f6f4ecd4d8 100644
--- 
a/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc
+++ 
b/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc
@@ -25,7 +25,7 @@ template
 constexpr
 std::array::type, 
   sizeof...(Args)>
-make_array(Args&&... args)  // { dg-error "invalid use" }
+make_array(Args&&... args)  // { dg-error "no type.*common_type<>" }
 {
   typedef typename std::common_type::type CT;
   return std::array{static_cast

Re: [PATCH doc] correct/expand -Wreturn-type

[Jakub Jelinek]

On Wed, Feb 06, 2019 at 10:15:27AM -0700, Martin Sebor wrote:
> > > -For C++, a function without return type always produces a diagnostic
> > > -message, even when @option{-Wno-return-type} is specified.  The only
> > > -exceptions are @code{main} and functions defined in system headers.
> > > +For C++, calling a non-@code{void} function other than @code{main} that 
> > > flows
> > > +off the end is undefined even if the value of the function is not used.
> > 
> > That is not true, the undefined behavior is not when calling such a 
> > function,
> > but only when it flows off the end.  So, it is perfectly fine if you have:
> > int
> > foo (int x)
> > {
> >if (x > 10)
> >  return 20;
> > }
> > and you only ever call foo with x > 10, or if you have:
> > int
> > bar ()
> > {
> >baz ();
> > }
> > and baz always throws, or never returns etc.  So, if we try to clarify, we
> > should clarify it correctly.
> 
> Sigh.  Was that jab really necessary?
> 
> The C++ standard says:
> 
>   ...flowing off the end of a function other than main (6.6.1)
>   results in undefined behavior.
> 
> It doesn't mention anything about calling the function so it seems
> to me the text I added is no less correct or clear than that.  I see
> no point in going into unlikely corner cases that the standard itself
> make provisions for.

Your new text talks about calling the function though, which might be read as 
that
the UB is already when you call such a function.  Why don't you use the
standard wording instead, i.e.
"For C++, flowing off the end of a function other than @code{main} is
undefined even if the return value from the function is not used in the
caller."
or similar?

Jakub

Re: [PATCH doc] correct/expand -Wreturn-type

[Martin Sebor]

On 2/6/19 9:56 AM, Jakub Jelinek wrote:

On Wed, Feb 06, 2019 at 09:51:59AM -0700, Martin Sebor wrote:

-For C++, a function without return type always produces a diagnostic
-message, even when @option{-Wno-return-type} is specified.  The only
-exceptions are @code{main} and functions defined in system headers.
+For C++, calling a non-@code{void} function other than @code{main} that flows
+off the end is undefined even if the value of the function is not used.


That is not true, the undefined behavior is not when calling such a function,
but only when it flows off the end.  So, it is perfectly fine if you have:
int
foo (int x)
{
   if (x > 10)
 return 20;
}
and you only ever call foo with x > 10, or if you have:
int
bar ()
{
   baz ();
}
and baz always throws, or never returns etc.  So, if we try to clarify, we
should clarify it correctly.


Sigh.  Was that jab really necessary?

The C++ standard says:

  ...flowing off the end of a function other than main (6.6.1)
  results in undefined behavior.

It doesn't mention anything about calling the function so it seems
to me the text I added is no less correct or clear than that.  I see
no point in going into unlikely corner cases that the standard itself
make provisions for.

Martin

Re: [gmane.comp.gdb.patches] [RFA] Fix splay tree KEY leak detected in GDB test gdb.base/macscp.exp

[Richard Biener]

On February 6, 2019 2:59:21 PM GMT+01:00, Tom Tromey  wrote:
>Philippe Waroquiers found another splay-tree memory leak and sent this
>patch to the gdb patch list.  I'm forwarding it here, as splay-tree is
>canonically maintained in gcc; if approved I will check it in for him.
>
>Note that the analysis from the previous splay-tree patch applies here
>as well: there is a single user of the key-deletion functionality in
>gcc, and I believe it remains safe with this patch.  (In fact, if
>duplicate keys were ever used, this would fix a leak in gcc.  I am not
>sure whether or not that can happen though.)

Didn't I approve the patch already? 

OK if not so. 

Richard. 

>thanks,
>Tom

Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features and flags.

[Tamar Christina]

Hi Gerald,

I've updated the patch with your suggested changes and have grouped
the Arm and AArch64 targets a bit.

Ok for commit?

Thanks,
Tamar

The 01/31/2019 10:21, Ramana Radhakrishnan wrote:
> 
> 
> On Thu, 31 Jan 2019, 10:09 Tamar Christina 
> mailto:tamar.christ...@arm.com> wrote:
> Hi Gerard,
> 
> Thanks I'll make the suggested changes.
> 
> About the duplication, we can avoid it if we have a "general" section for all 
> Arm ports first and then subsections for Arm and AArch64 specific things.
> 
> I'm not sure how the maintainers feel about such a re-organization though.
> 
> Works for me
> 
> R
> 
> Any opinions guys?
> 
> Thanks,
> Tamar
> 
> 
> From: Gerald Pfeifer mailto:ger...@pfeifer.com>>
> Sent: Thursday, January 31, 2019 12:29 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd; James 
> Greenhalgh; Richard Earnshaw; Marcus Shawcroft; Ramana Radhakrishnan; 
> ni...@redhat.com; Kyrylo Tkachov
> Subject: Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new features 
> and flags.
> 
> On Wed, 23 Jan 2019, Tamar Christina wrote:
> > This patch adds the documentation for Stack clash protection and
> > Armv8.3-a support to changes.html for GCC 9.
> 
> Some additional notes, all minor, for consideration before you commit.
> 
> +The probing interval/guard size can be set by using
> +--param stack-clash-protection-guard-size=12|16.
> +The value of this parameter must be in bytes represented as a power of 
> two.
> +The only two supported values for this parameter are 12 and 16 being
> +4Kb (2^12) and 64Kb (2^16) respectively.
> 
> This one keeps making me think every time I read it.  What do you
> think of changing the second and third sentences to
> 
>   "The two supported values for this paramter are 12 (for a 4KiB size,
>   2^12) and 16 (for a 64KiB size, 2^16)."
> 
> or something like that?  Shorter and about the same contents?  (Note,
> uppercase B or we'd refer to bits.)
> 
> +The Armv8.3-A complex number instructions are now supported via 
> intrinsics
> +when the option -march=armv8.3-a or equivalent is specified.
> +For the half-precision floating-point variants of these instructions use 
> the
> +architecture extension flag +fp16, e.g.
> +-march=armv8.3-a+fp16.
> +
> +The intrinsics are defined by the ACLE specification.
> 
> Note that these two visual paragraphs in HTML source will be merged into
> just one unless you add ... around the two.  Just pointing it out.
> 
> +  
> +The Armv8.3-A complex number instructions are now supported via 
> intrinsics
> +when the option -march=armv8.3-a or equivalent is specified.
> +For the half-precision floating-point variants of these instructions use 
> the
> +architecture extension flag +fp16, e.g.
> +-march=armv8.3-a+fp16.
> +
> +The intrinsics are defined by the ACLE specification.
> +  
> 
> I guess this duplication is hard to avoid between Arm and AArch64?
> 
> Gerald

-- 
Index: htdocs/gcc-9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.35
diff -u -r1.35 changes.html
--- htdocs/gcc-9/changes.html	15 Jan 2019 13:17:49 -	1.35
+++ htdocs/gcc-9/changes.html	5 Feb 2019 16:03:46 -
@@ -199,7 +199,8 @@
 
 New Targets and Target Specific Improvements
 
-AArch64
+AArch64  Arm
+
 
   
 Support has been added for the following processors
@@ -214,32 +215,35 @@
 -mtune=cortex-a76.cortex-a55 or as arguments to the equivalent target
 attributes and pragmas.
   
+  
+The Armv8.3-A complex number instructions are now supported via intrinsics
+when the option -march=armv8.3-a or equivalent is specified.
+For the half-precision floating-point variants of these instructions use the
+architecture extension flag +fp16, e.g.
+-march=armv8.3-a+fp16.
+
+The intrinsics are defined by the ACLE specification.
+  
 
 
-ARC
+AArch64 specific
 
-  LRA is now on by default for the ARC target.  This can be
-  controlled by -mlra.
-  Add support for frame code-density and branch-and-index
-  instructions.
+  
+The AArch64 port now has support for stack clash protection using the
+-fstack-clash-protection option.  The probing interval/guard
+size can be set by using --param stack-clash-protection-guard-size=12|16.
+The value of this parameter must be in bytes represented as a power of two.
+The two supported values for this parameter are 12 (for a 4KiB size, 2^12)
+and 16 (for a 64KiB size, 2^16).
+
+The default value is 16 (64Kb) and can be changed at configure
+time using the flag --with-stack-clash-protection-guard-size=12|16.
+  
 
 
-Arm
+Arm specific
 
   
-Support has been added for the following processors
-(GCC identifiers in parentheses):
-
-	Arm Cortex-A76 (cortex-a76).
-	Arm 

Re: [PATCH doc] correct/expand -Wreturn-type

[Jakub Jelinek]

On Wed, Feb 06, 2019 at 09:51:59AM -0700, Martin Sebor wrote:
> -For C++, a function without return type always produces a diagnostic
> -message, even when @option{-Wno-return-type} is specified.  The only
> -exceptions are @code{main} and functions defined in system headers.
> +For C++, calling a non-@code{void} function other than @code{main} that flows
> +off the end is undefined even if the value of the function is not used.

That is not true, the undefined behavior is not when calling such a function,
but only when it flows off the end.  So, it is perfectly fine if you have:
int
foo (int x)
{
  if (x > 10)
return 20;
}
and you only ever call foo with x > 10, or if you have:
int
bar ()
{
  baz ();
}
and baz always throws, or never returns etc.  So, if we try to clarify, we
should clarify it correctly.

Jakub

[PATCH doc] correct/expand -Wreturn-type

[Martin Sebor]

A recent flurry of bug reports about wrong code in C++ due to flowing
(AKA falling) off the end of a function prompted me to look at what
the manual has to say about the undefined behavior that the warning
is meant to point out.  It turns out that the manual not only doesn't
mention it, but it also incorrectly states that in C++, -Wreturn-type
cannot be suppressed by -Wno-return-type.

The attached patch documents the undefined behavior and removes
the statement about -Wno-return-type having no effect in C++.

Martin

PS The C++ standard uses the term "flow of the end" so I used that
in the new text even though the C paragraph refers to it as "falling
off the end."
gcc/ChangeLog:

	* doc/invoke.texi (-Wreturn-type): Correct and expand.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 268583)
+++ gcc/doc/invoke.texi	(working copy)
@@ -5261,13 +5261,15 @@ without a value).
 For C only, warn about a @code{return} statement with an expression in a
 function whose return type is @code{void}, unless the expression type is
 also @code{void}.  As a GNU extension, the latter case is accepted
-without a warning unless @option{-Wpedantic} is used.
+without a warning unless @option{-Wpedantic} is used.  Attempting
+to use the return value of a non-@code{void} function other than @code{main}
+that flows off the end by reaching the closing curly brace that terminates
+the function is undefined.
 
-For C++, a function without return type always produces a diagnostic
-message, even when @option{-Wno-return-type} is specified.  The only
-exceptions are @code{main} and functions defined in system headers.
+For C++, calling a non-@code{void} function other than @code{main} that flows
+off the end is undefined even if the value of the function is not used.
 
-This warning is enabled by default for C++ and is enabled by @option{-Wall}.
+This warning is enabled by default in C++ and by @option{-Wall} otherwise.
 
 @item -Wshift-count-negative
 @opindex Wshift-count-negative

Go patch committed: Update README

[Ian Lance Taylor]

This patch updates the go/gofrontend/README file, which had gotten
very out of date, and had diverged from the version in the GCC repo.
Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268554)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-347628daf153baf3034b61b2abb4ec39e2ab37c8
+74ffeddbe6fef446129af65581b3a9094715bc22
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/README
===
--- gcc/go/gofrontend/README(revision 268369)
+++ gcc/go/gofrontend/README(working copy)
@@ -1,52 +1,55 @@
 See ../README.
 
-The frontend is written in C++.
+The frontend is written in C++.  It can only be used in conjunction
+with a full compiler backend.  Currently the backend interface has
+been implemented with GCC (known as gccgo) and with LLVM (known as
+GoLLVM).
 
 The frontend lexes and parses the input into an IR specific to this
 frontend known as gogo.  It then runs a series of passes over the
 code.
 
-Finally it converts gogo to gcc's GENERIC.  A goal is to move the gcc
-support code into a gcc-interface subdirectory.  The gcc code will be
-put under the GPL.  The rest of the frontend will not include any gcc
-header files.
-
-Issues to be faced in this transition:
-
-* Representation of source locations.
-  + Currently the frontend uses gcc's location_t codes, using the
-interface in libcpp/line-map.h.
-
-* Handling of error messages.
-  + Currently the frontend uses gcc's error_at and warning_at
-functions.
-  + Currently the frontend uses gcc's diagnostic formatter, using
-features such as %<%> for appropriate quoting.
-  + Localization may be an issue.
-
-This compiler works, but the code is a work in progress.  Notably, the
-support for garbage collection is ineffective and needs a complete
-rethinking.  The frontend pays little attention to its memory usage
-and rarely frees any memory.  The code could use a general cleanup
-which we have not had time to do.
+Finally it converts gogo to the backend IR.  This is done via the
+interface described in backend.h.  The backend must implement that
+interface.  When used with GCC, the interface is implemented in
+gcc/go/go-gcc.cc.
+
+Source locations are represented using the interface described in
+go-linemap.h.  The backend is expected to provide a header file
+go-location.h that defines a Location type.
+
+The frontend does not start by itself.  It expects something to call
+go_create_gogo passing in a Backend and a Linemap, as well as other
+options.  Then it expects something to call go_parse_input_files
+passing in the input files.  Finally, a call to go_write_globals will
+cause all global definitions to be written out via the Backend
+interface.
+
+The backend is expected to provide the functions defined at the
+bottom of go-diagnostics.h: go_be_error_at, etc.  These will be used
+for error messages.
+
+This compiler works, but the code is a work in progress.  The frontend
+pays little attention to its memory usage and rarely frees any memory.
+The code could use a general cleanup which we have not had time to do.
 
 Contributing
 =
 
 To contribute patches to the files in this directory, please see
-http://golang.org/doc/gccgo_contribute.html .
+https://golang.org/doc/gccgo_contribute.html .
 
 The master copy of these files is hosted at
-http://code.google.com/p/gofrontend .  Changes to these files require
+https://go.googlesource.com/gofrontend .  There is a mirror at
+https://github.com/golang/gofrontend .  Changes to these files require
 signing a Google contributor license agreement.  If you are the
 copyright holder, you will need to agree to the individual contributor
-license agreement at
-http://code.google.com/legal/individual-cla-v1.0.html.  This agreement
-can be completed online.
+https://cla.developers.google.com/about/google-individual .  This
+agreement can be completed online.
 
 If your organization is the copyright holder, the organization will
 need to agree to the corporate contributor license agreement at
-http://code.google.com/legal/corporate-cla-v1.0.html.
+https://cla.developers.google.com/about/google-corporate .
 
 If the copyright holder for your code has already completed the
 agreement in connection with another Google open source project, it

[PATCH doc] correct/improve -Wmissing-attributes and -Wattribute-alias

[Martin Sebor]

The manual documents the -Wno-missing-attributes form of the option
as if it was enabled by default, even though it's enabled by -Wall
(I can't get this -Wno- convention straight in my head).  I also
got private comments on the documentation of the option suggesting
to add cross-references, and to list the attributes
-Wattribute-alias considers (the same ones as -Wmissing-attributes).

The attached patch makes these changes.

Martin
gcc/ChangeLog:

	* doc/invoke.texi (-Wmissing-attributes): Invert entry.
	Add cross-references.
	(-Wattribute-alias): Mention considered attributes (same
	as for -Wmissing-attributes).

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 268583)
+++ gcc/doc/invoke.texi	(working copy)
@@ -5055,10 +5055,10 @@ about the layout of the file that the directive re
 
 This warning is enabled by @option{-Wall} in C and C++.
 
-@item -Wno-missing-attributes
+@item -Wmissing-attributes
 @opindex Wmissing-attributes
 @opindex Wno-missing-attributes
-Warn when a declaration of a function is missing one or more attributes
+Do not warn when a declaration of a function is missing one or more attributes
 that a related function is declared with and whose absence may adversely
 affect the correctness or efficiency of generated code.  For example,
 the warning is issued for declarations of aliases that use attributes
@@ -5079,6 +5079,11 @@ or @code{nonnull} is declared without it.  Attribu
 @code{error}, and @code{warning} suppress the warning.
 (@pxref{Function Attributes}).
 
+The the @code{copy} attribute provides a mechanism for applying the same
+set of attributes to a declaration as that on another declaration without
+explicitly enumerating the attributes. (@pxref{Function Attributes}.
+@pxref{Variable Attributes}.  @pxref{Variable Attributes}.)
+
 @option{-Wmissing-attributes} is enabled by @option{-Wall}.
 
 For example, since the declaration of the primary function template
@@ -6101,9 +6106,14 @@ false positives and is deactivated by default.
 @opindex -Wattribute-alias
 @opindex -Wno-attribute-alias
 Warn about declarations using the @code{alias} and similar attributes whose
-target is incompatible with the type of the alias.
+target is incompatible with the type of the alias.  Attributes considered
+include @code{alloc_align}, @code{alloc_size}, @code{cold}, @code{const},
+@code{hot}, @code{leaf}, @code{malloc}, @code{nonnull}, @code{noreturn},
+@code{nothrow}, @code{pure}, @code{returns_nonnull}, and @code{returns_twice}.
+
 @xref{Function Attributes,,Declaring Attributes of Functions}.
-The @option{-Wattribute-alias=1} is  enabled by @option{-Wall}.
+The @option{-Wattribute-alias=1} option is enabled by @option{-Wall}.
+See also the related @option{-Wmissing-attributes} option.
 
 @table @gcctabopt
 @item -Wattribute-alias=1

New Russian PO file for 'cpplib' (version 9.1-b20190203)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'cpplib-9.1-b20190203.ru.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Contents of PO file 'cpplib-9.1-b20190203.ru.po'

[Translation Project Robot]

cpplib-9.1-b20190203.ru.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

RE: [PATCH][GCC][AArch64] Fix command line options canonicalization. (PR target/88530)

[Tamar Christina]

Friendly Ping, is there anything I can do to move this one along?

Thanks,
Tamar

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org 
> On Behalf Of Tamar Christina
> Sent: Wednesday, January 30, 2019 14:02
> To: Kyrill Tkachov 
> Cc: gcc-patches@gcc.gnu.org; nd ; James Greenhalgh
> ; Richard Earnshaw
> ; Marcus Shawcroft
> 
> Subject: Re: [PATCH][GCC][AArch64] Fix command line options
> canonicalization. (PR target/88530)
> 
> Ping.
> 
> 
> From: gcc-patches-ow...@gcc.gnu.org 
> on behalf of Tamar Christina 
> Sent: Tuesday, January 15, 2019 5:12:46 PM
> To: Kyrill Tkachov
> Cc: gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard Earnshaw;
> Marcus Shawcroft
> Subject: Re: [PATCH][GCC][AArch64] Fix command line options
> canonicalization. (PR target/88530)
> 
> Hi Kyrill,
> 
> Thanks for the review,
> 
> I have respun the patch on top of trunk and here is the new changelog to
> account for the updates of the new extensions.
> 
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for trunk?
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
> 2019-01-15  Tamar Christina  
> 
> PR target/88530
> * common/config/aarch64/aarch64-common.c
> (struct aarch64_option_extension): Add is_synthetic.
> (all_extensions): Use it.
> (TARGET_OPTION_INIT_STRUCT): Define hook.
> (struct gcc_targetm_common): Moved to end.
> (all_extensions_by_on): New.
> (opt_ext_cmp, typedef opt_ext): New.
> (aarch64_option_init_struct): New.
> (aarch64_contains_opt): New.
> (aarch64_get_extension_string_for_isa_flags): Output smallest set.
> * config/aarch64/aarch64-option-extensions.def
> (AARCH64_OPT_EXTENSION): Explicitly include AES and SHA2 in crypto.
> (fp, simd, crc, lse, fp16, rcpc, rdma, dotprod, aes, sha2, sha3,
> sm4, fp16fml, sve, profile, rng, memtag, sb, ssbs, predres):
> Set is_synthetic to false.
> (crypto): Set is_synthetic to true.
> 
> gcc/testsuite/ChangeLog:
> 
> 2019-01-15  Tamar Christina  
> 
> PR target/88530
> * gcc.target/aarch64/options_set_1.c: New test.
> * gcc.target/aarch64/options_set_2.c: New test.
> * gcc.target/aarch64/options_set_3.c: New test.
> * gcc.target/aarch64/options_set_4.c: New test.
> * gcc.target/aarch64/options_set_5.c: New test.
> * gcc.target/aarch64/options_set_6.c: New test.
> * gcc.target/aarch64/options_set_7.c: New test.
> * gcc.target/aarch64/options_set_8.c: New test.
> * gcc.target/aarch64/options_set_9.c: New test.
> 
> 
> 
> The 01/10/2019 17:15, Kyrill Tkachov wrote:
> > Hi Tamar,
> >
> > On 17/12/18 19:18, Tamar Christina wrote:
> > > Hi All,
> > >
> > > The options don't seem to get canonicalized into the smallest
> > > possible set before output to the assembler. This means that
> > > overlapping feature sets are emitted with superfluous parts.
> > >
> > > Normally this isn't an issue, but in the case of crypto we have
> > > retro-actively split it into aes and sha2. We need to emit only
> > > +crypto to the assembler so old assemblers continue to work.
> > >
> > > Because of how -mcpu=native and -march=native work they end up
> > > enabling all feature bits, so we need to get the smallest possible
> > > set, which would also fix the problem with older the assemblers and the
> retro-active split.
> > >
> > > Admittedly this should be done earlier in options processing, but
> > > the problem with the way AArch64 currently processes options is that
> > > where the isa_bits are determined we don't know which options are part
> of the default set yet.
> > >
> > > Which is why we instead do it late in processing when we have all
> > > the information.  This however requires us to make a duplicate of
> > > the extensions list.
> > >
> > > The Option handling structures have been extended to have a boolean
> > > to indicate whether the option is synthetic, with that I mean if the 
> > > option
> flag itself has a bit.
> > >
> > > e.g. +crypto isn't an actual bit, it just enables other bits, but
> > > other features flags like +rdma also enable multiple options but are
> themselves also a feature.
> > >
> > > There are two ways to solve this.
> > >
> > > 1) Either have the options that are feature bits also turn themselves on,
> e.g. change
> > >rdma to turn on FP, SIMD and RDMA as dependency bits.
> > > 2) Make a distinction between these two different type of features and
> have the framework
> > >handle it correctly.
> > >
> > > Even though it's more code I went for the second approach, as it's
> > > the one that'll be less fragile and give the least surprises.
> > >
> > > This is a stop-gap measure that's has the lowest impact and is back-
> portable.
> > >
> > > Effectively this patch changes the following:
> > >
> > > The values before the => are the old compiler and after the => the 

Re: [testsuite] Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451)

[Rainer Orth]

Hi Richard,

> On Fri, 4 Jan 2019, Rainer Orth wrote:
>
>> Hi Richard,
>> 
>> >> On Thu, 3 Jan 2019, Rainer Orth wrote:
>> >>
>> >>> gcc.dg/debug/dwarf2/inline5.c currently FAILs with Solaris as (both
>> >>> sparc and x86):
>> >>> 
>> >>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not (DIE
>> >>> (0x([0-9a-f]*)) DW_TAG_lexical_block)[^#/!]*[#/!]
>> >>> [^(].*DW_TAG_lexical_block)[^#/!x]*x1[^#/!]*[#/!]
>> >>> DW_AT_abstract_origin
>> >>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>> >>> DW_TAG_lexical_block)[^#/!]*[#/!] (DIE (0x[0-9a-f]*)
>> >>> DW_TAG_variable 1
>> >>> 
>> >>> The first failure seems to be caused because .* performs multiline
>> >>> matches by default in Tcl; tightening it to [^\n]* avoids the problem.
>> >>
>> >> Hmm, but the matches are supposed to match multiple lines...  how
>> >> does it fail for you?
>> >
>> > it matches all of
>> >
>> > (DIE (0x19f) DW_TAG_lexical_block)
>> > .byte   0xd / uleb128 0xd; (DIE (0x1a0) DW_TAG_variable)
>> > .ascii "j"  / DW_AT_name
>> > .byte   0x1 / DW_AT_decl_file 
>> > (/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c)
>> > .byte   0x12/ DW_AT_decl_line
>> > .byte   0x14/ DW_AT_decl_column
>> > .long   0x17f   / DW_AT_type
>> > .byte   0   / end of children of DIE 0x19f
>> > .byte   0   / end of children of DIE 0x184
>> > .byte   0xe / uleb128 0xe; (DIE (0x1ac) DW_TAG_subprogram)
>> > .long   0x184   / DW_AT_abstract_origin
>> > .long   .LFB0   / DW_AT_low_pc
>> > .long   .LFE0-.LFB0 / DW_AT_high_pc
>> > .byte   0x1 / uleb128 0x1; DW_AT_frame_base
>> > .byte   0x9c/ DW_OP_call_frame_cfa
>> > / DW_AT_GNU_all_call_sites
>> > .byte   0xf / uleb128 0xf; (DIE (0x1bb) 
>> > DW_TAG_formal_parameter)
>> > .long   0x195   / DW_AT_abstract_origin
>> > .byte   0x2 / uleb128 0x2; DW_AT_location
>> > .byte   0x91/ DW_OP_fbreg
>> > .byte   0   / sleb128 0
>> > .byte   0x6 / uleb128 0x6; (DIE (0x1c3) DW_TAG_lexical_block)
>> > .long   0x19f   / DW_AT_abstract_origin
>> >
>> > while with gas there's instead
>> >
>> >.uleb128 0xc/ (DIE (0xad) DW_TAG_lexical_block)
>> >.uleb128 0xd/ (DIE (0xae) DW_TAG_variable)
>> >.ascii "j\0"/ DW_AT_name
>> >.byte   0x1 / DW_AT_decl_file 
>> > (/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c)
>> >
>> > i.e. the pattern doesn't match with gas due to the [^(] while with as we
>> > have uleb128 first which does match, producing the failure (which shows
>> > that that part of my patch is wrong).
>> 
>> I still have a hard time determining what to do here.  I've now reverted
>> the tree to r264642, i.e. the one before the PR debug/87443 patch.  Then
>> I build on x86_64-pc-linux-gnu and ran the inline5.c testcase against
>> the old compiler.  I'd have expected all the scan-assembler* tests to
>> FAIL here, but instead I get
>> 
>> PASS: gcc.dg/debug/dwarf2/inline5.c (test for excess errors)
>> PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>> DW_TAG_inlined_subrouti
>> ne 2
>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>> DW_TAG_lexical_block\\)
>> [^#/!]*[#/!] DW_AT_abstract_origin 2
>> PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
>> DW_TAG_lexical_block\\)
>> [^#/!]*[#/!] \\(DIE \\(0x[0-9a-f]*\\) DW_TAG_variable 1
>> PASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not \\(DIE
>> \\(0x([0-9a-f]*)\\
>> ) DW_TAG_lexical_block\\)[^#/!]*[#/!]
>> [^(].*DW_TAG_lexical_block\\)[^#/!x]*x\\1[
>> ^#/!]*[#/!] DW_AT_abstract_origin
>> FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not
>> DW_TAG_lexical_block\\)[^
>> #/!x]*x([0-9a-f]*)[^#/!]*[#/!] DW_AT_abstract_origin.*\\(DIE \\(0x\\1\\)
>> DW_TAG_
>> lexical_block\\)[^#/!]*[#/!] DW_AT
>> 
>> i.e. the problematic scan-assembler-not test PASSes before and after
>> your patch, making it hard to determine what that test is guarding
>> against (i.e. what is matched on Linux/x86_64 or Solaris with gas) and
>> adapting it to the Solaris as syntax.
>
> Yeah, the issue is I applied patches in another order than I developed
> the testcases...  I think you need to back out the PR87428/87362
> fix to see this FAIL happening.
>
> What we want to not see is a lexical block used as abstract origin
> that has further attributes.  GCC 8 shows bogus DWARF:
>
>  <2><5c>: Abbrev Number: 4 (DW_TAG_inlined_subroutine)
> <5d>   DW_AT_abstract_origin: <0xa9>
> <61>   DW_AT_low_pc  : 0xf
> <69>   DW_AT_high_pc : 0xf
> <71>   DW_AT_call_file   : 1
> <72>   DW_AT_call_line   : 10
> <73>   DW_AT_call_column : 20
>  <3><74>: Abbrev Number: 5 (DW_TAG_formal_parameter)
> <75>   DW_AT_abstract_origin: <0xba>
> <79>   DW_AT_location: 0x0 (location list)
> 

Re: [C++ Patch] PR 88986 ("[7/8/9 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in member_vec_binary_search, at cp/name-lookup.c:1136")

[Paolo Carlini]

... the below passes testing on x86_64-linux.

Note, we have to handle separately the empty pack case, otherwise we 
don't emit any diagnostics and we crash pretty soon.


Thanks, Paolo.

/


Index: cp/decl.c
===
--- cp/decl.c   (revision 268513)
+++ cp/decl.c   (working copy)
@@ -3816,7 +3816,9 @@ make_typename_type (tree context, tree name, enum
   gcc_assert (identifier_p (name));
   gcc_assert (TYPE_P (context));
 
-  if (!MAYBE_CLASS_TYPE_P (context))
+  if (TREE_CODE (context) == TYPE_PACK_EXPANSION)
+/* This can happen for C++17 variadic using (c++/88986).  */;
+  else if (!MAYBE_CLASS_TYPE_P (context))
 {
   if (complain & tf_error)
error ("%q#T is not a class", context);
Index: cp/pt.c
===
--- cp/pt.c (revision 268513)
+++ cp/pt.c (working copy)
@@ -14895,8 +14895,24 @@ tsubst (tree t, tree args, tsubst_flags_t complain
 
 case TYPENAME_TYPE:
   {
-   tree ctx = tsubst_aggr_type (TYPE_CONTEXT (t), args, complain,
-in_decl, /*entering_scope=*/1);
+   tree ctx = TYPE_CONTEXT (t);
+   if (TREE_CODE (ctx) == TYPE_PACK_EXPANSION)
+ {
+   ctx = tsubst_pack_expansion (ctx, args, complain, in_decl);
+   if (ctx == error_mark_node
+   || TREE_VEC_LENGTH (ctx) > 1)
+ return error_mark_node;
+   if (TREE_VEC_LENGTH (ctx) == 0)
+ {
+   error ("%qD is instantiated for an empty pack",
+  TYPENAME_TYPE_FULLNAME (t));
+   return error_mark_node;
+ }
+   ctx = TREE_VEC_ELT (ctx, 0);
+ }
+   else
+ ctx = tsubst_aggr_type (ctx, args, complain, in_decl,
+ /*entering_scope=*/1);
if (ctx == error_mark_node)
  return error_mark_node;
 
Index: testsuite/g++.dg/cpp1z/using4.C
===
--- testsuite/g++.dg/cpp1z/using4.C (nonexistent)
+++ testsuite/g++.dg/cpp1z/using4.C (working copy)
@@ -0,0 +1,12 @@
+// PR c++/88986
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+struct B { typedef int type; };
+
+template struct C : T... {
+  using typename T::type ...;  // { dg-warning "pack expansion" "" { target 
c++14_down } }
+  void f() { type value; }
+};
+
+template struct C;
Index: testsuite/g++.dg/cpp1z/using5.C
===
--- testsuite/g++.dg/cpp1z/using5.C (nonexistent)
+++ testsuite/g++.dg/cpp1z/using5.C (working copy)
@@ -0,0 +1,12 @@
+// PR c++/88986
+// { dg-do compile { target c++11 } }
+// { dg-options "" }
+
+struct B { typedef int type; };
+
+template struct C : T... {
+  using typename T::type ...;  // { dg-warning "pack expansion" "" { target 
c++14_down } }
+  void f() { type value; }  // { dg-error "empty pack" }
+};
+
+template struct C<>;

Re: [PATCH][GCC][Arm] Fix NEON REG to REG reload failures. (PR/target 88850)

[Kyrylo Tkachov]

On 06/02/19 14:28, Tamar Christina wrote:
> Hi Kyrill,
>
> >
> > So you add a new alternative but don't modify any of the output logic, which
> > means it will use output_move_double. Can that handle an "r,r" alternative?
> > Or do you expect a split to always happen here? If so, the output should be
> > '#'
>
> Yes.. so output_move_double can't indeed handle it, but it doesn't actually 
> get used. The pattern here is only because reload has decided there must be 
> one because of our cost = 2.  In the end they will always be split due to the 
> splitter in arm.md line 5897 which will split any 64 bit values after reload. 
> And since this is an anonymous pattern you can't call It, so there really 
> shouldn't be any case in which the r -> r case doesn't get split as VDX only 
> contains 64 bit types.
>

Ok.

> However I agree it may be confusing and probably a bit more correct if I put 
> the #.

Yeah, returning a '#' explicitly is the correct thing to do in that case.
Ok with that change.

Thanks,
Kyrill

>
> Kind Regards,
> Tamar
> >
> > Thanks,
> > Kyrill
>

RE: [PATCH][GCC][Arm] Fix NEON REG to REG reload failures. (PR/target 88850)

[Tamar Christina]

Hi Kyrill,

> 
> So you add a new alternative but don't modify any of the output logic, which
> means it will use output_move_double. Can that handle an "r,r" alternative?
> Or do you expect a split to always happen here? If so, the output should be
> '#'

Yes.. so output_move_double can't indeed handle it, but it doesn't actually get 
used. The pattern here is only because reload has decided there must be one 
because of our cost = 2.  In the end they will always be split due to the 
splitter in arm.md line 5897 which will split any 64 bit values after reload. 
And since this is an anonymous pattern you can't call It, so there really 
shouldn't be any case in which the r -> r case doesn't get split as VDX only 
contains 64 bit types.

However I agree it may be confusing and probably a bit more correct if I put 
the #.

Kind Regards,
Tamar
> 
> Thanks,
> Kyrill

Re: [RS6000] Set uses_pic_offset_table on sysv secure-plt calls and tls.

[Alan Modra]

On Wed, Feb 06, 2019 at 05:45:17AM -0600, Segher Boessenkool wrote:
> On Wed, Feb 06, 2019 at 04:43:18PM +1030, Alan Modra wrote:
> > Segher, you'll recognize these as your patches from pr88343.  All I've
> > done here is give you a testcase for the legitimize_tls_address change
> > (which you said you had no idea what the patch was for!)
> 
> I don't see a testcase, and the rs6000_legitimize_tls_address part is new
> to me.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343#c21

>  Oh you mean the stuff in the commit message below here :-)

Yes.

> 
> I'll make real testcases from that, let's see if things are fixed.  Do you
> know if it helps the glibs libm stuff?

The patch fixes the libm testcase that Joseph attached to the bug.

I believe we might have more places where we need to set
uses_pic_offset_table for Linux ABIs, builtin_setjmp_receiver and the
use of RS6000_PIC_OFFSET_TABLE_REGNUM in rs6000_longcall_ref.  (I'd
looked at the latter case and decided it wasn't strictly necessary
because we'd get use_pic_offset_table set when emitting the call, but
that isn't true for old -mbss-plt code.)

> 
> Another question below:
> 
> > 
> > Fixes lack of r30 save/restore on powerpc-linux.
> > 
> > // -m32 -fpic -ftls-model=initial-exec
> > __thread char* p;
> > char** f1 (void) { return  }
> > 
> > and
> > 
> > // -m32 -fpic -msecure-plt
> > extern int foo (int);
> > int f1 (int x) { return foo (x); }
> > 
> > PR target/88343
> > * config/rs6000/rs6000.c (rs6000_legitimize_tls_address),
> > (rs6000_call_sysv): Set uses_pic_offset_table.
> > 
> > diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> > index 883361cabbe..ab01dee9b68 100644
> > --- a/gcc/config/rs6000/rs6000.c
> > +++ b/gcc/config/rs6000/rs6000.c
> > @@ -8705,7 +8705,10 @@ rs6000_legitimize_tls_address (rtx addr, enum 
> > tls_model model)
> >else
> > {
> >   if (flag_pic == 1)
> > -   got = gen_rtx_REG (Pmode, RS6000_PIC_OFFSET_TABLE_REGNUM);
> > +   {
> > + crtl->uses_pic_offset_table = 1;
> > + got = gen_rtx_REG (Pmode, RS6000_PIC_OFFSET_TABLE_REGNUM);
> 
> This is the same as just
> 
>   got = pic_offset_table_rtx;

Yes, I wondered about that too, then decided that it wasn't a stage 4
fix.  It's true if rs6000_legitimize_tls_address isn't used by powerpc
darwin.

I believe you could use pic_offset_table_rtx for the TARGET_64BIT
"got = gen_rtx_REG (Pmode, 2);" too.  And if we're tidying the
function it would be nice to use DEFAULT_ABI tests rather than some of
the TARGET_64BIT tests.  Register selection for local-exec model is an
ABI thing, as is the GOT register choice.

-- 
Alan Modra
Australia Development Lab, IBM

[gmane.comp.gdb.patches] [RFA] Fix splay tree KEY leak detected in GDB test gdb.base/macscp.exp

[Tom Tromey]

Philippe Waroquiers found another splay-tree memory leak and sent this
patch to the gdb patch list.  I'm forwarding it here, as splay-tree is
canonically maintained in gcc; if approved I will check it in for him.

Note that the analysis from the previous splay-tree patch applies here
as well: there is a single user of the key-deletion functionality in
gcc, and I believe it remains safe with this patch.  (In fact, if
duplicate keys were ever used, this would fix a leak in gcc.  I am not
sure whether or not that can happen though.)

thanks,
Tom

--- Begin Message ---
When a node is removed from a splay tree, the splay tree was
not using the function splay_tree_delete_key_fn to release the key.
This was causing a leak, fixed by Tom Tromey.

This patch fixes another key leak, that happens when a key equal to
a key already present is inserted.  In such a case, we have to release
the old KEY.
Note that this is based on the assumption that the caller always
allocates a new KEY when doing an insert.

Also, clarify the documentation about when the release functions are
called.

include/ChangeLog
2019-01-26  Philippe Waroquiers  

* splay-tree.h (splay_tree_delete_key_fn): Update comment.
(splay_tree_delete_value_fn): Likewise.

libiberty/ChangeLog
2019-01-26  Philippe Waroquiers  

* splay-tree.c (splay_tree_insert): Also release old KEY in case
of insertion of a key equal to an already present key.
(splay_tree_new_typed_alloc): Update comment.
---
 include/splay-tree.h   | 11 +--
 libiberty/splay-tree.c | 13 ++---
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/include/splay-tree.h b/include/splay-tree.h
index 0d26272943..da533dec18 100644
--- a/include/splay-tree.h
+++ b/include/splay-tree.h
@@ -58,11 +58,18 @@ typedef struct splay_tree_node_s *splay_tree_node;
 typedef int (*splay_tree_compare_fn) (splay_tree_key, splay_tree_key);
 
 /* The type of a function used to deallocate any resources associated
-   with the key.  */
+   with the key.  If you provide this function, the splay tree
+   will take the ownership of the memory of the splay_tree_key arg
+   of splay_tree_insert.  This function is called to release the keys
+   present in the tree when calling splay_tree_delete or splay_tree_remove.
+   If splay_tree_insert is called with a key equal to a key already
+   present in the tree, the old key and old value will be released.  */
 typedef void (*splay_tree_delete_key_fn) (splay_tree_key);
 
 /* The type of a function used to deallocate any resources associated
-   with the value.  */
+   with the value.  If you provide this function, the memory of the
+   splay_tree_value arg of splay_tree_insert is managed similarly to
+   the splay_tree_key memory: see splay_tree_delete_key_fn.  */
 typedef void (*splay_tree_delete_value_fn) (splay_tree_value);
 
 /* The type of a function used to iterate over the tree.  */
diff --git a/libiberty/splay-tree.c b/libiberty/splay-tree.c
index 21d23c38df..4bbb39a62c 100644
--- a/libiberty/splay-tree.c
+++ b/libiberty/splay-tree.c
@@ -318,7 +318,11 @@ different types need to be allocated with different 
allocators.
 
 The splay tree will use @var{compare_fn} to compare nodes,
 @var{delete_key_fn} to deallocate keys, and @var{delete_value_fn} to
-deallocate values.
+deallocate values.  Keys and values will be deallocated when the
+tree is deleted using splay_tree_delete or when a node is removed
+using splay_tree_remove.  splay_tree_insert will release the previously
+inserted key and value using @var{delete_key_fn} and @var{delete_value_fn}
+if the inserted key is already found in the tree.
 
 @end deftypefn
 
@@ -372,10 +376,13 @@ splay_tree_insert (splay_tree sp, splay_tree_key key, 
splay_tree_value value)
 
   if (sp->root && comparison == 0)
 {
-  /* If the root of the tree already has the indicated KEY, just
-replace the value with VALUE.  */
+  /* If the root of the tree already has the indicated KEY, delete
+ the old key and old value, and replace them with KEY and  VALUE.  */
+  if (sp->delete_key)
+   (*sp->delete_key) (sp->root->key);
   if (sp->delete_value)
(*sp->delete_value)(sp->root->value);
+  sp->root->key = key;
   sp->root->value = value;
 } 
   else 
-- 
2.20.1


--- End Message ---

Re: [PATCH][GCC][Arm] Fix NEON REG to REG reload failures. (PR/target 88850)

[Kyrill Tkachov]

Hi Tamar,

On 05/02/19 10:13, Tamar Christina wrote:

Hi All,

We currently return cost 2 for NEON REG to REG moves, which would be incorrect
for 64 bit moves.  We currently don't have a pattern for this in the neon_move
alternatives because this is a bit of a special case.  We would almost never
want it to use this r -> r pattern unless it really has no choice.

As such we add a new neon r -> r move pattern but also hide it from being used
to determine register preferences and also disparage it during LRA.

Bootstrapped Regtested on arm-none-gnueabihf and no issues.

Ok for trunk?

Thanks,
Tamar

gcc/ChangeLog:

2019-02-05  Tamar Christina  

PR/target 88850
* config/arm/neon.md (*neon_mov): Add r -> r case.

gcc/testsuite/ChangeLog:

2019-02-05  Tamar Christina  

PR/target 88850
* gcc.target/arm/pr88850.c: New test.

--


diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 
f9d7ba35b137fed383f84eecbe81dd942943d216..21ff5adbd40c362aa977171bd1726b88b383a265
 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -25,9 +25,9 @@
 
 (define_insn "*neon_mov"

   [(set (match_operand:VDX 0 "nonimmediate_operand"
- "=w,Un,w, w,  ?r,?w,?r, ?Us")
+ "=w,Un,w, w,  ?r,?w,?r, ?Us,*r")
(match_operand:VDX 1 "general_operand"
- " w,w, Dn,Uni, w, r, Usi,r"))]
+ " w,w, Dn,Uni, w, r, Usi,r,*r"))]
   "TARGET_NEON
&& (register_operand (operands[0], mode)
|| register_operand (operands[1], mode))"
@@ -62,11 +62,11 @@
 }
  [(set_attr "type" "neon_move,neon_store1_1reg,neon_move,\
 neon_load1_1reg, neon_to_gp,neon_from_gp,\
-neon_load1_2reg, neon_store1_2reg")
-  (set_attr "length" "4,4,4,4,4,4,8,8")
-  (set_attr "arm_pool_range" "*,*,*,1020,*,*,1020,*")
-  (set_attr "thumb2_pool_range" "*,*,*,1018,*,*,1018,*")
-  (set_attr "neg_pool_range" "*,*,*,1004,*,*,1004,*")])
+neon_load1_2reg, neon_store1_2reg, multiple")
+  (set_attr "length" "4,4,4,4,4,4,8,8,8")
+  (set_attr "arm_pool_range" "*,*,*,1020,*,*,1020,*,*")
+  (set_attr "thumb2_pool_range" "*,*,*,1018,*,*,1018,*,*")
+  (set_attr "neg_pool_range" "*,*,*,1004,*,*,1004,*,*")])
 


So you add a new alternative but don't modify any of the output logic, which 
means it will use
output_move_double. Can that handle an "r,r" alternative?
Or do you expect a split to always happen here? If so, the output should be '#'

Thanks,
Kyrill

[PATCH][AArch64] Use implementation namespace consistently in arm_neon.h

[Kyrill Tkachov]

[resending with patch compressed]

Hi all,

We're somewhat inconsistent in arm_neon.h when it comes to using the 
implementation namespace for local
identifiers. This means things like:
#define hash_abcd 0
#define hash_e 1
#define wk 2

#include "arm_neon.h"

uint32x4_t
foo (uint32x4_t a, uint32_t b, uint32x4_t c)
{
  return vsha1cq_u32 (a, b, c);
}

don't compile.
This patch fixes these issues throughout the whole of arm_neon.h
Bootstrapped and tested on aarch64-none-linux-gnu.
The advsimd-intrinsics.exp tests pass just fine.

Don't feel sorry for me having to write the ChangeLog. ./contrib/mklog.pl 
automated the whole thing.

Ok for trunk?
Thanks,
Kyrill

2019-02-06  Kyrylo Tkachov  

* config/aarch64/arm_neon.h (vaba_s8): Use __ in identifiers
consistenly.
(vaba_s16): Likewise.
(vaba_s32): Likewise.
(vaba_u8): Likewise.
(vaba_u16): Likewise.
(vaba_u32): Likewise.
(vabal_high_s8): Likewise.
(vabal_high_s16): Likewise.
(vabal_high_s32): Likewise.
(vabal_high_u8): Likewise.
(vabal_high_u16): Likewise.
(vabal_high_u32): Likewise.
(vabal_s8): Likewise.
(vabal_s16): Likewise.
(vabal_s32): Likewise.
(vabal_u8): Likewise.
(vabal_u16): Likewise.
(vabal_u32): Likewise.
(vabaq_s8): Likewise.
(vabaq_s16): Likewise.
(vabaq_s32): Likewise.
(vabaq_u8): Likewise.
(vabaq_u16): Likewise.
(vabaq_u32): Likewise.
(vabd_s8): Likewise.
(vabd_s16): Likewise.
(vabd_s32): Likewise.
(vabd_u8): Likewise.
(vabd_u16): Likewise.
(vabd_u32): Likewise.
(vabdl_high_s8): Likewise.
(vabdl_high_s16): Likewise.
(vabdl_high_s32): Likewise.
(vabdl_high_u8): Likewise.
(vabdl_high_u16): Likewise.
(vabdl_high_u32): Likewise.
(vabdl_s8): Likewise.
(vabdl_s16): Likewise.
(vabdl_s32): Likewise.
(vabdl_u8): Likewise.
(vabdl_u16): Likewise.
(vabdl_u32): Likewise.
(vabdq_s8): Likewise.
(vabdq_s16): Likewise.
(vabdq_s32): Likewise.
(vabdq_u8): Likewise.
(vabdq_u16): Likewise.
(vabdq_u32): Likewise.
(vaddlv_s8): Likewise.
(vaddlv_s16): Likewise.
(vaddlv_u8): Likewise.
(vaddlv_u16): Likewise.
(vaddlvq_s8): Likewise.
(vaddlvq_s16): Likewise.
(vaddlvq_s32): Likewise.
(vaddlvq_u8): Likewise.
(vaddlvq_u16): Likewise.
(vaddlvq_u32): Likewise.
(vcvtx_f32_f64): Likewise.
(vcvtx_high_f32_f64): Likewise.
(vcvtxd_f32_f64): Likewise.
(vmla_n_f32): Likewise.
(vmla_n_s16): Likewise.
(vmla_n_s32): Likewise.
(vmla_n_u16): Likewise.
(vmla_n_u32): Likewise.
(vmla_s8): Likewise.
(vmla_s16): Likewise.
(vmla_s32): Likewise.
(vmla_u8): Likewise.
(vmla_u16): Likewise.
(vmla_u32): Likewise.
(vmlal_high_n_s16): Likewise.
(vmlal_high_n_s32): Likewise.
(vmlal_high_n_u16): Likewise.
(vmlal_high_n_u32): Likewise.
(vmlal_high_s8): Likewise.
(vmlal_high_s16): Likewise.
(vmlal_high_s32): Likewise.
(vmlal_high_u8): Likewise.
(vmlal_high_u16): Likewise.
(vmlal_high_u32): Likewise.
(vmlal_n_s16): Likewise.
(vmlal_n_s32): Likewise.
(vmlal_n_u16): Likewise.
(vmlal_n_u32): Likewise.
(vmlal_s8): Likewise.
(vmlal_s16): Likewise.
(vmlal_s32): Likewise.
(vmlal_u8): Likewise.
(vmlal_u16): Likewise.
(vmlal_u32): Likewise.
(vmlaq_n_f32): Likewise.
(vmlaq_n_s16): Likewise.
(vmlaq_n_s32): Likewise.
(vmlaq_n_u16): Likewise.
(vmlaq_n_u32): Likewise.
(vmlaq_s8): Likewise.
(vmlaq_s16): Likewise.
(vmlaq_s32): Likewise.
(vmlaq_u8): Likewise.
(vmlaq_u16): Likewise.
(vmlaq_u32): Likewise.
(vmls_n_f32): Likewise.
(vmls_n_s16): Likewise.
(vmls_n_s32): Likewise.
(vmls_n_u16): Likewise.
(vmls_n_u32): Likewise.
(vmls_s8): Likewise.
(vmls_s16): Likewise.
(vmls_s32): Likewise.
(vmls_u8): Likewise.
(vmls_u16): Likewise.
(vmls_u32): Likewise.
(vmlsl_high_n_s16): Likewise.
(vmlsl_high_n_s32): Likewise.
(vmlsl_high_n_u16): Likewise.
(vmlsl_high_n_u32): Likewise.
(vmlsl_high_s8): Likewise.
(vmlsl_high_s16): Likewise.
(vmlsl_high_s32): Likewise.
(vmlsl_high_u8): Likewise.
(vmlsl_high_u16): Likewise.
(vmlsl_high_u32): Likewise.
(vmlsl_n_s16): Likewise.
(vmlsl_n_s32): Likewise.
(vmlsl_n_u16): Likewise.
(vmlsl_n_u32): Likewise.
(vmlsl_s8): Likewise.
(vmlsl_s16): Likewise.
(vmlsl_s32): Likewise.
(vmlsl_u8): Likewise.
(vmlsl_u16): Likewise.
(vmlsl_u32): Likewise.
(vmlsq_n_f32): Likewise.
(vmlsq_n_s16): Likewise.
(vmlsq_n_s32): Likewise.
(vmlsq_n_u16): Likewise.
(vmlsq_n_u32): Likewise.
(vmlsq_s8): Likewise.
(vmlsq_s16): Likewise.
(vmlsq_s32): Likewise.
(vmlsq_u8): Likewise.
(vmlsq_u16): Likewise.
(vmlsq_u32): Likewise.
(vmovl_high_s8): Likewise.
(vmovl_high_s16): Likewise.
(vmovl_high_s32): Likewise.
(vmovl_high_u8): Likewise.

Re: [v3 PATCH, RFC] Rewrite variant. Also PR libstdc++/85517

[Ville Voutilainen]

On Wed, 6 Feb 2019 at 12:21, Ville Voutilainen
 wrote:
> > I think the assumption was this would produce smaller code. Does that
> > hold true?
>
> I think the assumption was that this produces equivalent or better
> code than fixing the current
> semantics bugs with some sort of separate constexpr arrays of function
> pointers would.
> And certainly better code than any approach that has a run-time
> branch. I don't think this ends up
> being different from the current codegen; both have an array indexing
> operation followed by an indirect
> function call.

And, to emphasize, the most important reason for this was to be able
to write straightforward
code for the special member functions, with the hope that it wouldn't
have a negative codegen
effect. Our Microsoft friends described the general technique as "has
crazy-good codegen",
but I have no idea what their starting point was; our starting point
probably wasn't bad
to begin with.

Re: [RS6000] Set uses_pic_offset_table on sysv secure-plt calls and tls.

[Segher Boessenkool]

On Wed, Feb 06, 2019 at 05:45:17AM -0600, Segher Boessenkool wrote:
> On Wed, Feb 06, 2019 at 04:43:18PM +1030, Alan Modra wrote:
> > Segher, you'll recognize these as your patches from pr88343.  All I've
> > done here is give you a testcase for the legitimize_tls_address change
> > (which you said you had no idea what the patch was for!)
> 
> I don't see a testcase, and the rs6000_legitimize_tls_address part is new
> to me.  Oh you mean the stuff in the commit message below here :-)

"New to me"...  I did not remember it, anyway :-)


Segher

Re: Make clear, when contributions will be ignored

[Segher Boessenkool]

On Fri, Dec 07, 2018 at 10:55:11AM +, Дилян Палаузов wrote:
> will it help, if Bugzilla is reprogrammed to send automatically weekly
> reminders on all patches, that are not integrated yet?

No, that will not help.

If an interested party sends a friendly ping, that is of course welcome.
But automated pings are spam: unwanted bulk mail.

> The patch I proposed on 27th Oct was first submitted towards GDB and
> then I was told to send it to GCC.  Here I was told to sent it to GDB. 
> What shall happen to quit the loop?

You can cc: both sides of the discussion.  Either also gdb-patches, or also
whoever told you to send it to GCC instead, or both.  And include a link to
the mailing list archive of your thread on gdb-patches in your mail to
gcc-patches, so that all parties can see the relevant context.  Make it
easy for people to help you!


Segher

Re: [RS6000] Set uses_pic_offset_table on sysv secure-plt calls and tls.

[Iain Sandoe]

> On 6 Feb 2019, at 11:45, Segher Boessenkool  
> wrote:
> 
> On Wed, Feb 06, 2019 at 04:43:18PM +1030, Alan Modra wrote:
>> Segher, you'll recognize these as your patches from pr88343.  All I've
>> done here is give you a testcase for the legitimize_tls_address change
>> (which you said you had no idea what the patch was for!)
> 
> I don't see a testcase, and the rs6000_legitimize_tls_address part is new
> to me.  Oh you mean the stuff in the commit message below here :-)
> 
> I'll make real testcases from that, let's see if things are fixed.  Do you
> know if it helps the glibs libm stuff?

I don’t know the answer to this ^ …
… but was attempting a manual audit of other possible places and saw that
rs6000_emit_toc_load_table() for pic code also uses the picbase without
setting  crtl->uses_pic_offset_table.  However, that’s quite late on - and I
wasn’t sure if something should be setting the use in that circumstance
earlier on.

Iain

> 
> Another question below:
> 
>> 
>> Fixes lack of r30 save/restore on powerpc-linux.
>> 
>> // -m32 -fpic -ftls-model=initial-exec
>> __thread char* p;
>> char** f1 (void) { return  }
>> 
>> and
>> 
>> // -m32 -fpic -msecure-plt
>> extern int foo (int);
>> int f1 (int x) { return foo (x); }
>> 
>>  PR target/88343
>>  * config/rs6000/rs6000.c (rs6000_legitimize_tls_address),
>>  (rs6000_call_sysv): Set uses_pic_offset_table.
>> 
>> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
>> index 883361cabbe..ab01dee9b68 100644
>> --- a/gcc/config/rs6000/rs6000.c
>> +++ b/gcc/config/rs6000/rs6000.c
>> @@ -8705,7 +8705,10 @@ rs6000_legitimize_tls_address (rtx addr, enum 
>> tls_model model)
>>   else
>>  {
>>if (flag_pic == 1)
>> -got = gen_rtx_REG (Pmode, RS6000_PIC_OFFSET_TABLE_REGNUM);
>> +{
>> +  crtl->uses_pic_offset_table = 1;
>> +  got = gen_rtx_REG (Pmode, RS6000_PIC_OFFSET_TABLE_REGNUM);
> 
> This is the same as just
> 
>  got = pic_offset_table_rtx;
> 
> or am I missing something?
> 
>> +}
>>else
>>  {
>>rtx gsym = rs6000_got_sym ();
>> @@ -38068,7 +38071,10 @@ rs6000_call_sysv (rtx value, rtx func_desc, rtx 
>> tlsarg, rtx cookie)
>>   && (!SYMBOL_REF_LOCAL_P (func_addr)
>>|| SYMBOL_REF_EXTERNAL_P (func_addr)
>>|| SYMBOL_REF_WEAK (func_addr)))
>> -call[n++] = gen_rtx_USE (VOIDmode, pic_offset_table_rtx);
>> +{
>> +  crtl->uses_pic_offset_table = 1;
>> +  call[n++] = gen_rtx_USE (VOIDmode, pic_offset_table_rtx);
>> +}
>> 
>>   call[n++] = gen_hard_reg_clobber (Pmode, LR_REGNO);
>> 
> 
> 
> Segher

[Ada] fix gnatlib build on x32 runtime

[Arnaud Charlet]

This has been reported on 
https://github.com/mattgodbolt/compiler-explorer-image/issues/161

The failure has been introduced 2018-11-14 when updating the list of
signals in s-linux*.ads files, s-linux__x32.ads was forgotten.

Tested on x86_64-pc-linux-gnu, committed on trunk.

2019-02-06  Arnaud Charlet  

* libgnarl/s-linux__x32.ads: Resync list of signals with s-linux.ads

Index: libgnarl/s-linux__x32.ads
===
--- libgnarl/s-linux__x32.ads   (revision 268575)
+++ libgnarl/s-linux__x32.ads   (working copy)
@@ -82,35 +82,36 @@
SIGILL : constant := 4; --  illegal instruction (not reset)
SIGTRAP: constant := 5; --  trace trap (not reset)
SIGIOT : constant := 6; --  IOT instruction
-   SIGABRT: constant := 6; --  used by abort, replace SIGIOT in the  future
+   SIGABRT: constant := 6; --  used by abort, replace SIGIOT in the future
SIGFPE : constant := 8; --  floating point exception
SIGKILL: constant := 9; --  kill (cannot be caught or ignored)
SIGBUS : constant := 7; --  bus error
+   SIGUSR1: constant := 10; --  user defined signal 1
SIGSEGV: constant := 11; --  segmentation violation
+   SIGUSR2: constant := 12; --  user defined signal 2
SIGPIPE: constant := 13; --  write on a pipe with no one to read it
SIGALRM: constant := 14; --  alarm clock
SIGTERM: constant := 15; --  software termination signal from kill
-   SIGUSR1: constant := 10; --  user defined signal 1
-   SIGUSR2: constant := 12; --  user defined signal 2
+   SIGSTKFLT  : constant := 16; --  coprocessor stack fault (Linux)
SIGCLD : constant := 17; --  alias for SIGCHLD
SIGCHLD: constant := 17; --  child status change
-   SIGPWR : constant := 30; --  power-fail restart
-   SIGWINCH   : constant := 28; --  window size change
-   SIGURG : constant := 23; --  urgent condition on IO channel
-   SIGPOLL: constant := 29; --  pollable event occurred
-   SIGIO  : constant := 29; --  I/O now possible (4.2 BSD)
-   SIGLOST: constant := 29; --  File lock lost
SIGSTOP: constant := 19; --  stop (cannot be caught or ignored)
SIGTSTP: constant := 20; --  user stop requested from tty
SIGCONT: constant := 18; --  stopped process has been continued
SIGTTIN: constant := 21; --  background tty read attempted
SIGTTOU: constant := 22; --  background tty write attempted
+   SIGURG : constant := 23; --  urgent condition on IO channel
+   SIGXCPU: constant := 24; --  CPU time limit exceeded
+   SIGXFSZ: constant := 25; --  filesize limit exceeded
SIGVTALRM  : constant := 26; --  virtual timer expired
SIGPROF: constant := 27; --  profiling timer expired
-   SIGXCPU: constant := 24; --  CPU time limit exceeded
-   SIGXFSZ: constant := 25; --  filesize limit exceeded
-   SIGUNUSED  : constant := 31; --  unused signal (GNU/Linux)
-   SIGSTKFLT  : constant := 16; --  coprocessor stack fault (Linux)
+   SIGWINCH   : constant := 28; --  window size change
+   SIGPOLL: constant := 29; --  pollable event occurred
+   SIGIO  : constant := 29; --  I/O now possible (4.2 BSD)
+   SIGLOST: constant := 29; --  File lock lost
+   SIGPWR : constant := 30; --  power-fail restart
+   SIGSYS : constant := 31; --  bad system call
+   SIGUNUSED  : constant := 31; --  unused signal (mapped to SIGSYS)
SIG32  : constant := 32; --  glibc internal signal
SIG33  : constant := 33; --  glibc internal signal
SIG34  : constant := 34; --  glibc internal signal

Re: [RS6000] Set uses_pic_offset_table on sysv secure-plt calls and tls.

[Segher Boessenkool]

On Wed, Feb 06, 2019 at 04:43:18PM +1030, Alan Modra wrote:
> Segher, you'll recognize these as your patches from pr88343.  All I've
> done here is give you a testcase for the legitimize_tls_address change
> (which you said you had no idea what the patch was for!)

I don't see a testcase, and the rs6000_legitimize_tls_address part is new
to me.  Oh you mean the stuff in the commit message below here :-)

I'll make real testcases from that, let's see if things are fixed.  Do you
know if it helps the glibs libm stuff?

Another question below:

> 
> Fixes lack of r30 save/restore on powerpc-linux.
> 
> // -m32 -fpic -ftls-model=initial-exec
> __thread char* p;
> char** f1 (void) { return  }
> 
> and
> 
> // -m32 -fpic -msecure-plt
> extern int foo (int);
> int f1 (int x) { return foo (x); }
> 
>   PR target/88343
>   * config/rs6000/rs6000.c (rs6000_legitimize_tls_address),
>   (rs6000_call_sysv): Set uses_pic_offset_table.
> 
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 883361cabbe..ab01dee9b68 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -8705,7 +8705,10 @@ rs6000_legitimize_tls_address (rtx addr, enum 
> tls_model model)
>else
>   {
> if (flag_pic == 1)
> - got = gen_rtx_REG (Pmode, RS6000_PIC_OFFSET_TABLE_REGNUM);
> + {
> +   crtl->uses_pic_offset_table = 1;
> +   got = gen_rtx_REG (Pmode, RS6000_PIC_OFFSET_TABLE_REGNUM);

This is the same as just

  got = pic_offset_table_rtx;

or am I missing something?

> + }
> else
>   {
> rtx gsym = rs6000_got_sym ();
> @@ -38068,7 +38071,10 @@ rs6000_call_sysv (rtx value, rtx func_desc, rtx 
> tlsarg, rtx cookie)
>&& (!SYMBOL_REF_LOCAL_P (func_addr)
> || SYMBOL_REF_EXTERNAL_P (func_addr)
> || SYMBOL_REF_WEAK (func_addr)))
> -call[n++] = gen_rtx_USE (VOIDmode, pic_offset_table_rtx);
> +{
> +  crtl->uses_pic_offset_table = 1;
> +  call[n++] = gen_rtx_USE (VOIDmode, pic_offset_table_rtx);
> +}
>  
>call[n++] = gen_hard_reg_clobber (Pmode, LR_REGNO);
>  


Segher

Re: [PATCH, rs6000] Fix instruction counts on powerpc64 test cases. (take 2)

[Segher Boessenkool]

Hi Bill,

On Tue, Feb 05, 2019 at 02:14:16PM -0600, Bill Seurer wrote:
> [PATCH, rs6000] Fix instruction counts on powerpc64 test cases.
> 
> This patch fixes the assembler instruction counts for some test cases
> that started failing due to changes in code generation.  The targets
> were adjusted a bit as well to avoid generating BE/LE endian code on
> unsupported platforms.

>   * gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c: Update 
>   instruction counts and target.

(Trailing space after "Update").

>  /* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
>  /* { dg-final { scan-assembler-times "xvadddp" 1 } } */
> -/* { dg-final { scan-assembler-times "xxlnor" 8 { target le } } } */
> -/* { dg-final { scan-assembler-times "xxlnor" 7 { target be } } } */
> -/* { dg-final { scan-assembler-times "xvcmpeqdp" 5 { target le } } } */
> -/* { dg-final { scan-assembler-times "xvcmpeqdp" 6 { target be }} } */
> -/* { dg-final { scan-assembler-times "xvcmpeqdp." 5 { target le } } } */
> -/* { dg-final { scan-assembler-times "xvcmpeqdp." 6 { target be } } } */
> -/* { dg-final { scan-assembler-times "xvcmpgtdp" 9 { target le } } } */
> -/* { dg-final { scan-assembler-times "xvcmpgtdp" 8 { target be } } } */
> -/* { dg-final { scan-assembler-times "xvcmpgtdp." 9 { target le } } } */
> -/* { dg-final { scan-assembler-times "xvcmpgtdp." 8 { target be } } } */
> -/* { dg-final { scan-assembler-times "xvcmpgedp" 6 { target le } } } */
> -/* { dg-final { scan-assembler-times "xvcmpgedp" 7 { target be } } } */
> -/* { dg-final { scan-assembler-times "xvcmpgedp." 6 { target le } } } */
> -/* { dg-final { scan-assembler-times "xvcmpgedp." 7 { target be } } } */
> +/* { dg-final { scan-assembler-times "xxlnor" 5 } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpeqdp\s} 1 } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpeqdp\.\s} 5 } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgtdp\s} 2 } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgtdp\.\s} 5 } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgedp\s} 1 } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgedp\.\s} 6 } } */
>  /* { dg-final { scan-assembler-times "xvrdpim" 1 } } */
>  /* { dg-final { scan-assembler-times "xvmaddadp" 1 } } */
>  /* { dg-final { scan-assembler-times "xvmsubadp" 1 } } */

As a future cleanup / robustification, all the other insns could use \m
and \M as well.  For example xxlor would match xxlorc.  I don't know if
there are currently any possible conflicts, but :-)

> Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c(revision 
> 268524)
> +++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c(working copy)
> @@ -1,16 +1,15 @@
> -/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
> +/* { dg-do compile { target { lp64 } } } */

No braces around "lp64" please.  They are needed when there is more than
one selector in there, in an expression with && or whatnot (this is parsed
by custom code, not by the tcl parser).

> +/* { dg-final { scan-assembler-times {\mxvcmpeqdp\s} 1 { target le } } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpeqdp\.\s} 5 { target le } } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpeqdp\s} 1 { target be } } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpeqdp\.\s} 5 { target be } } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgtdp\s} 2 { target le } } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgtdp\.\s} 6 { target le } } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgtdp\s} 2 { target be } } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgtdp\.\s} 6 { target be } } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgedp\s} 2 } } */
> +/* { dg-final { scan-assembler-times {\mxvcmpgedp\.\s} 4 } } */

"le" and "be" are now identical, so unify them?

> --- gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p9.c(revision 
> 268524)
> +++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p9.c(working copy)
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
> +/* { dg-do compile { target { lp64 && le } } } */
>  /* { dg-skip-if "" { powerpc*-*-darwin* } } */
>  /* { dg-require-effective-target powerpc_p9vector_ok } */
>  /* { dg-options "-mvsx -O2 -mcpu=power9" } */

I don't know if we should limit the p9 testcases to LE only.  If no one
ever tests GCC on p9 BE, leaving out the "le" works fine; and if people
_do_ test on it, we will want to know if it doesn't work.

Okay for trunk with those things fixed.  (The \m\M thing isn't required of
course).  Thanks!


Segher

Re: [i386] Fix wrong argument value on Windows

[Uros Bizjak]

> this is a regression present on all active branches: if you compile the
> attached Ada testcase with -O2 -gnatp -fno-omit-frame-pointer for 32-bit
> Windows, you'll see that the compiler swaps a load based on the stack pointer
> with a store based on the frame pointer, thus clobbering a saved argument:
>
>pushl   %ebp
>movl%esp, %ebp
>pushl   %esi
>pushl   %ebx
>pushl   %eax  <- %eax save
>movl$4108, %eax
>call___chkstk_ms
>leal8(%ebp), %esi
>subl%eax, %esp
>movl8(%ebp), %ebx
>movl%edx, -20(%ebp)
>movl%esi, -12(%ebp)<- fp-based store
>movl(%esp,%eax), %eax  <- sp-based load
>... wrong value in eax...
>
> The load and the store are swapped because there are not based on the same
> register and the offset between them is seen as variable.  The proposed fix is
> to add a memory blockage, like in other frame-related constructs.
>
> Tested on x86/Windows and x86-64/Windows, OK for all active branches?
>
>
> 2019-02-06  Eric Botcazou  
>
> * config/i386/i386.c (ix86_expand_prologue): Generate a memory blockage
> after restoring registers saved to allocate the frame on Windows.
>
>
> 2019-02-06  Eric Botcazou  
>
> * gnat.dg/opt76.adb: New test.

OK everywhere.

Thanks,
Uros.

Re: [v3 PATCH, RFC] Rewrite variant. Also PR libstdc++/85517

[Ville Voutilainen]

On Wed, 6 Feb 2019 at 12:13, Jonathan Wakely  wrote:
> Did you compare the codegen?

No. Getting the metaprograms to work took all the time I had thus far. :)

> I think the assumption was this would produce smaller code. Does that
> hold true?

I think the assumption was that this produces equivalent or better
code than fixing the current
semantics bugs with some sort of separate constexpr arrays of function
pointers would.
And certainly better code than any approach that has a run-time
branch. I don't think this ends up
being different from the current codegen; both have an array indexing
operation followed by an indirect
function call.

> Are you still working on the rest of the special member functions? It

Yes.

> seems to me that they could be fixed separately anyway, it doesn't
> need to be done all at once. Each special member function is
> independent of the others.

Right. The question is whether we want to commit a mixture of
visitation and separate function pointer
arrays. :)

[i386] Fix wrong argument value on Windows

[Eric Botcazou]

Hi,

this is a regression present on all active branches: if you compile the 
attached Ada testcase with -O2 -gnatp -fno-omit-frame-pointer for 32-bit 
Windows, you'll see that the compiler swaps a load based on the stack pointer 
with a store based on the frame pointer, thus clobbering a saved argument:

pushl   %ebp
movl%esp, %ebp
pushl   %esi
pushl   %ebx
pushl   %eax  <- %eax save
movl$4108, %eax
call___chkstk_ms
leal8(%ebp), %esi
subl%eax, %esp
movl8(%ebp), %ebx
movl%edx, -20(%ebp)
movl%esi, -12(%ebp)<- fp-based store
movl(%esp,%eax), %eax  <- sp-based load
... wrong value in eax...

The load and the store are swapped because there are not based on the same 
register and the offset between them is seen as variable.  The proposed fix is 
to add a memory blockage, like in other frame-related constructs.

Tested on x86/Windows and x86-64/Windows, OK for all active branches?


2019-02-06  Eric Botcazou  

* config/i386/i386.c (ix86_expand_prologue): Generate a memory blockage
after restoring registers saved to allocate the frame on Windows.


2019-02-06  Eric Botcazou  

* gnat.dg/opt76.adb: New test.

-- 
Eric BotcazouIndex: config/i386/i386.c
===
--- config/i386/i386.c	(revision 268508)
+++ config/i386/i386.c	(working copy)
@@ -13579,8 +13579,9 @@ ix86_expand_prologue (void)
 	}
   m->fs.sp_offset += allocate;
 
-  /* Use stack_pointer_rtx for relative addressing so that code
-	 works for realigned stack, too.  */
+  /* Use stack_pointer_rtx for relative addressing so that code works for
+	 realigned stack.  But this means that we need a blockage to prevent
+	 stores based on the frame pointer from being scheduled before.  */
   if (r10_live && eax_live)
 {
 	  t = gen_rtx_PLUS (Pmode, stack_pointer_rtx, eax);
@@ -13589,6 +13590,7 @@ ix86_expand_prologue (void)
 	  t = plus_constant (Pmode, t, UNITS_PER_WORD);
 	  emit_move_insn (gen_rtx_REG (word_mode, AX_REG),
 			  gen_frame_mem (word_mode, t));
+	  emit_insn (gen_memory_blockage ());
 	}
   else if (eax_live || r10_live)
 	{
@@ -13596,6 +13598,7 @@ ix86_expand_prologue (void)
 	  emit_move_insn (gen_rtx_REG (word_mode,
    (eax_live ? AX_REG : R10_REG)),
 			  gen_frame_mem (word_mode, t));
+	  emit_insn (gen_memory_blockage ());
 	}
 }
   gcc_assert (m->fs.sp_offset == frame.stack_pointer_offset);
-- { dg-do run }
-- { dg-options "-O2 -gnatp -fno-omit-frame-pointer" }

procedure Opt76 is

   type Integer_Access is access Integer;
   type Registry_Array is array (Natural range <>) of Integer_Access;

   procedure Nested (Input, Parser : Integer; A, B : Boolean) is

  Index : Registry_Array (1 .. 1024);
  Not_B : constant Boolean := not B;

  procedure Inner (Input : Integer) is
  begin
 if Input /= 1 then
raise Program_Error;
 end if;

 if Parser = 128 and then A and then Not_B then
Inner (Input);
Index (Index'First) := null;
 end if;
  end;

   begin
  Inner (Input);
   end;

   Input : Integer := 1 with Volatile;
   Parser : Integer := 2 with Volatile;
  
begin
   Nested (Input, Parser, False, True);
   Nested (Input, Parser, True, False);
end;

Re: [v3 PATCH, RFC] Rewrite variant. Also PR libstdc++/85517

[Jonathan Wakely]

On 06/02/19 00:05 +0200, Ville Voutilainen wrote:

Okay then. This patch takes the hopefully biggest steps towards
a std::variant rewrite. The problem we have with the current
approach is that we'd really like to write fairly straightforward
code for variant's special member functions, but can't, because
the specification suggests fairly straightforward compile-time-property
queries and selection of behavior based on those, but variant's selected
index is a run-time property. This leads to difficulties implementing
what the standard requires, like the differences of handling throwing and
non-throwing move/copy operations of the types held in variant.

Well. We apply the hammer of Pattern Matching. variant's visit()
can get us into code that can do the compile-time queries despite
variant's selected index being a run-time property. We modify
the visitation mechanism to not throw an exception if invoked
with a special kind of visitor that can handle valueless variants,
and then use polylambdas as such visitors, and do if-constexprs
in those polylambdas.

We can now get rid of the function-pointer tables that are used for
similar kind of dispatching in the original approach. Visitation
generates similar tables, so we keep the O(1) indexing into the right
function based on the current selected index, and there's the same
amount of indirect calls through a pointer-to-function, one.
Our code for e.g. variant's copy assignment is now straightforward;
it visits both the this-variant and the rhs-variant at the same time,
and does the right thing based on the compile-time properties of the
selected type,
and whether either variant is valueless. Modulo the polylambda wrapping
and the fact that all ifs in it are if-constexprs, it looks like it's just
doing conditional code based on what the nothrow-properties, for example,
of the type of the object held by the variant are.


Did you compare the codegen?

I think the assumption was this would produce smaller code. Does that
hold true?


This patch also partially gets rid of some of the cases where an object
is self-destroyed before it's reconstructed. We shouldn't do that.


Agreed, that's been concerning me since I noticed it.


We should be doing _M_reset followed by _M_construct, so that we only
ever destroy a variant member of a union object held in the variant's
storage, and then try to reconstruct that (or some other variant member),
and we should never self-destroy any object in the inheritance chain of
variant. The rest of that is work-in-progress, as is changing the rest
of the special member functions to use visitation.

Thoughts?


I like it. As you know, I've never liked that _S_vtable[] array of
function pointers, and the this->~variant() calls are undefined.

This is also necessary to implement the P0602R4 changes, and seems to
do so without ABI changes to our std::variant (its layout is not
changed by the patch).

As it only touches a C++17 component I'm inclined to approve it for
trunk before gcc-9.

Are you still working on the rest of the special member functions? It
seems to me that they could be fixed separately anyway, it doesn't
need to be done all at once. Each special member function is
independent of the others.

[PATCH] Fix PR89182

[Richard Biener]

This adds a cache around scalar_evolution_in_region avoiding re-analysis
during code-generation where out-of-date SSA form can cause minor
differences in SCEV analysis (follow_copies_to_constant ...).

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

It leaves a (tiny) hole via scev_analyzable_p but I refrained from
more refactoring at this point w/o a good reason (testcase).

Richard.

2019-02-06  Richard Biener  

PR tree-optimization/89182
* graphite.h (cached_scalar_evolution_in_region): Declare.
* graphite.c (struct seir_cache_key): New.
(struct sese_scev_hash): Likewise.
(seir_cache): New global.
(cached_scalar_evolution_in_region): New function.
(graphite_transform_loops): Allocate and release seir_cache.
* graphite-isl-ast-to-gimple.c (get_rename_from_scev): Use
cached_scalar_evolution_in_region.
* graphite-scop-detection.c (scop_detection::can_represent_loop):
Simplify.
(scop_detection::graphite_can_represent_expr: Use
cached_scalar_evolution_in_region.
(scop_detection::stmt_simple_for_scop_p): Likewise.
(find_params_in_bb): Likewise.
(gather_bbs::before_dom_children): Likewise.
* graphite-sese-to-poly.c (create_pw_aff_from_tree): Likewise.
(add_loop_constraints): Likewise.

* gfortran.dg/graphite/pr89182.f90: New testcase.

Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 268572)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -1092,7 +1092,8 @@ tree translate_isl_ast_to_gimple::
 get_rename_from_scev (tree old_name, gimple_seq *stmts, loop_p loop,
  vec iv_map)
 {
-  tree scev = scalar_evolution_in_region (region->region, loop, old_name);
+  tree scev = cached_scalar_evolution_in_region (region->region,
+loop, old_name);
 
   /* At this point we should know the exact scev for each
  scalar SSA_NAME used in the scop: all the other scalar
Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c   (revision 268572)
+++ gcc/graphite-scop-detection.c   (working copy)
@@ -568,8 +568,6 @@ scop_detection::can_represent_loop (loop
 && niter_desc.control.no_overflow
 && (niter = number_of_latch_executions (loop))
 && !chrec_contains_undetermined (niter)
-&& !chrec_contains_undetermined (scalar_evolution_in_region (scop,
-loop, niter))
 && graphite_can_represent_expr (scop, loop, niter);
 }
 
@@ -924,7 +922,7 @@ bool
 scop_detection::graphite_can_represent_expr (sese_l scop, loop_p loop,
 tree expr)
 {
-  tree scev = scalar_evolution_in_region (scop, loop, expr);
+  tree scev = cached_scalar_evolution_in_region (scop, loop, expr);
   return graphite_can_represent_scev (scop, scev);
 }
 
@@ -1061,7 +1059,8 @@ scop_detection::stmt_simple_for_scop_p (
FOR_EACH_SSA_TREE_OPERAND (op, stmt, i, SSA_OP_USE)
  if (scev_analyzable_p (op, scop)
  && chrec_contains_undetermined
-  (scalar_evolution_in_region (scop, bb->loop_father, op)))
+  (cached_scalar_evolution_in_region (scop,
+  bb->loop_father, op)))
{
  DEBUG_PRINT (dp << "[scop-detection-fail] "
   << "Graphite cannot code-gen stmt:\n";
@@ -1190,10 +1189,10 @@ find_params_in_bb (sese_info_p region, g
   FOR_EACH_VEC_ELT (GBB_CONDITIONS (gbb), i, stmt)
 {
   loop_p loop = gimple_bb (stmt)->loop_father;
-  tree lhs = scalar_evolution_in_region (region->region, loop,
-gimple_cond_lhs (stmt));
-  tree rhs = scalar_evolution_in_region (region->region, loop,
-gimple_cond_rhs (stmt));
+  tree lhs = cached_scalar_evolution_in_region (region->region, loop,
+   gimple_cond_lhs (stmt));
+  tree rhs = cached_scalar_evolution_in_region (region->region, loop,
+   gimple_cond_rhs (stmt));
   gcc_assert (!chrec_contains_undetermined (lhs)
  && !chrec_contains_undetermined (rhs));
 
@@ -1492,8 +1491,8 @@ gather_bbs::before_dom_children (basic_b
   tree nb_iters = number_of_latch_executions (loop);
   if (chrec_contains_symbols (nb_iters))
{
- nb_iters = scalar_evolution_in_region (region->region,
-loop, nb_iters);
+ nb_iters = cached_scalar_evolution_in_region (region->region,
+   loop, nb_iters);
 

Re: [PATCH] Fix fold_const_vec_convert (PR middle-end/89210)

[Richard Sandiford]

Jakub Jelinek  writes:
> Hi!
>
> Apparently VECTOR_CSTs shouldn't be stepped if they contain floating
> elements and also widening conversions can be problematic if there is
> wrapping in the narrower type.  On the following testcase, we create a
> stepped VECTOR_CST with REAL_CST elts and ICE whenever we try to print it or
> when we try to expand it.  The following patch follows what fold_convert_const
> does.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2019-02-05  Jakub Jelinek  
>
>   PR middle-end/89210
>   * fold-const-call.c (fold_const_vec_convert): Pass true as last
>   operand to new_unary_operation only if both element types are integral
>   and it isn't a widening conversion.  Return NULL_TREE if
>   new_unary_operation failed.

OK, thanks.

Richard