Re: PATCH to fix bogus -Wimplicit-fallthrough warning (PR c++/77803)

[Markus Trippelsdorf]

On 2016.09.30 at 23:31 +0200, Marek Polacek wrote:
> This PR reports a bogus -Wimplicit-fallthrough warning on the attached test.
> The problem is that last_stmt_in_scope should for GIMPLE_TRY, if the last
> statement of the eval part can't fallthrough, return this statement and don't
> warn.  And the same should be true for FALLTHROUGH ().   This patch fixes it.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?

Try to compile the testcase without the fallthrough attribute...

> diff --git gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C 
> gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C
> index e69de29..8f80b01 100644
> --- gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C
> +++ gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C
> @@ -0,0 +1,16 @@
> +// PR c++/77803
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-Wimplicit-fallthrough" }
> +
> +struct A {};
> +int a;
> +void fn1() {
> +  switch (0) {
> +  case 0: {
> +A b;
> +[[fallthrough]];
> +  }
> +  default:
> +a = 0;
> +  }
> +}
> 
>   Marek
> 

-- 
Markus

Fix PR tree-optimization/77808, ICE in duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with r240439

[Doug Gilmore]

It looks like my email being sent from my company is being dropped, re sending
via my gmail account.

Doug

From: Doug Gilmore
Sent: Friday, September 30, 2016 6:35 PM
To: gcc-patches@gcc.gnu.org; Christophe Lyon
Subject: Fix PR tree-optimization/77808, ICE in
duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with
r240439

My commit r240439 didn't handle the situation where setting
--param prefetch-latency=0 can cause the prefetch address to
be the same as the original address.  In this case, no
copying of points-to information should be done.

Bootstrapped and regression tested on x86_64-linux, ok for
trunk?

Doug


0001-Fix-PR-tree-optimization-77808.patch
Description: Binary data

Fix PR tree-optimization/77808, ICE in duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with r240439

[Doug Gilmore]

It looks like my original message was dropped, resending -- Doug

From: Doug Gilmore
Sent: Friday, September 30, 2016 6:35 PM
To: gcc-patches@gcc.gnu.org; Christophe Lyon
Subject: Fix PR tree-optimization/77808, ICE in duplicate_ssa_name_ptr_info, at 
tree-ssanames.c:630 starting with r240439

My commit r240439 didn't handle the situation where setting
--param prefetch-latency=0 can cause the prefetch address to
be the same as the original address.  In this case, no
copying of points-to information should be done.

Bootstrapped and regression tested on x86_64-linux, ok for
trunk?

Doug
From d7a115e12856f2bcd4cefab38378f5d947c7d96a Mon Sep 17 00:00:00 2001
From: Doug Gilmore 
Date: Fri, 30 Sep 2016 11:28:20 -0700
Subject: [PATCH] Fix PR tree-optimization/77808

gcc/
	PR tree-optimization/77808
	* tree-ssa-loop-prefetch.c (issue_prefetch_ref): Fix problem
	exposed by specifying --param prefetch-latency=0.

gcc/testsuite
	PR tree-optimization/77808
	* gcc.dg/tree-ssa/pr77808.c: New testcase.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr77808.c | 11 +++
 gcc/tree-ssa-loop-prefetch.c|  3 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr77808.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr77808.c b/gcc/testsuite/gcc.dg/tree-ssa/pr77808.c
new file mode 100644
index 000..85393f4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr77808.c
@@ -0,0 +1,11 @@
+/* PR tree-optimization/77808 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fprefetch-loop-arrays --param prefetch-latency=0" } */
+
+void daxpy(int n, double da, double * __restrict dx, double * __restrict dy)
+{
+  int i;
+
+  for (i = 0;i < n; i++)
+dy[i] = dy[i] + da*dx[i];
+}
diff --git a/gcc/tree-ssa-loop-prefetch.c b/gcc/tree-ssa-loop-prefetch.c
index 056815d..43ee85a 100644
--- a/gcc/tree-ssa-loop-prefetch.c
+++ b/gcc/tree-ssa-loop-prefetch.c
@@ -1162,7 +1162,8 @@ issue_prefetch_ref (struct mem_ref *ref, unsigned unroll_factor, unsigned ahead)
 	   NULL, true, GSI_SAME_STMT);
   }
 
-  if (TREE_CODE (addr_base) == SSA_NAME
+  if (addr_base != addr
+	  && TREE_CODE (addr_base) == SSA_NAME
 	  && TREE_CODE (addr) == SSA_NAME)
 	{
 	  duplicate_ssa_name_ptr_info (addr, SSA_NAME_PTR_INFO (addr_base));
-- 
1.9.1

Fix PR tree-optimization/77808, ICE in duplicate_ssa_name_ptr_info, at tree-ssanames.c:630 starting with r240439

[Doug Gilmore]

My commit r240439 didn't handle the situation where setting
--param prefetch-latency=0 can cause the prefetch address to
be the same as the original address.  In this case, no
copying of points-to information should be done.

Bootstrapped and regression tested on x86_64-linux, ok for
trunk?

Doug
From d7a115e12856f2bcd4cefab38378f5d947c7d96a Mon Sep 17 00:00:00 2001
From: Doug Gilmore 
Date: Fri, 30 Sep 2016 11:28:20 -0700
Subject: [PATCH] Fix PR tree-optimization/77808

gcc/
	PR tree-optimization/77808
	* tree-ssa-loop-prefetch.c (issue_prefetch_ref): Fix problem
	exposed by specifying --param prefetch-latency=0.

gcc/testsuite
	PR tree-optimization/77808
	* gcc.dg/tree-ssa/pr77808.c: New testcase.
---
 gcc/testsuite/gcc.dg/tree-ssa/pr77808.c | 11 +++
 gcc/tree-ssa-loop-prefetch.c|  3 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr77808.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr77808.c b/gcc/testsuite/gcc.dg/tree-ssa/pr77808.c
new file mode 100644
index 000..85393f4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr77808.c
@@ -0,0 +1,11 @@
+/* PR tree-optimization/77808 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fprefetch-loop-arrays --param prefetch-latency=0" } */
+
+void daxpy(int n, double da, double * __restrict dx, double * __restrict dy)
+{
+  int i;
+
+  for (i = 0;i < n; i++)
+dy[i] = dy[i] + da*dx[i];
+}
diff --git a/gcc/tree-ssa-loop-prefetch.c b/gcc/tree-ssa-loop-prefetch.c
index 056815d..43ee85a 100644
--- a/gcc/tree-ssa-loop-prefetch.c
+++ b/gcc/tree-ssa-loop-prefetch.c
@@ -1162,7 +1162,8 @@ issue_prefetch_ref (struct mem_ref *ref, unsigned unroll_factor, unsigned ahead)
 	   NULL, true, GSI_SAME_STMT);
   }
 
-  if (TREE_CODE (addr_base) == SSA_NAME
+  if (addr_base != addr
+	  && TREE_CODE (addr_base) == SSA_NAME
 	  && TREE_CODE (addr) == SSA_NAME)
 	{
 	  duplicate_ssa_name_ptr_info (addr, SSA_NAME_PTR_INFO (addr_base));
-- 
1.9.1

Re: C/C++ PATCH to implement -Wbool-operation (PR c/77490)

[Jakub Jelinek]

On Fri, Sep 23, 2016 at 12:44:22PM +0200, Marek Polacek wrote:
> 2016-09-23  Marek Polacek  
> 
>   PR c/77490
...
>   * c-c++-common/Wbool-operation-1.c: New test.

I've noticed this test fails on i686-linux and likely also on powerpc-linux.

Fixed thusly, committed to trunk as obvious:

2016-10-01  Jakub Jelinek  

PR c/77490
* c-c++-common/Wbool-operation-1.c: Add -Wno-psabi to dg-options.
Add dg-prune-output directive.

--- gcc/testsuite/c-c++-common/Wbool-operation-1.c.jj   2016-09-26 
20:22:23.0 +0200
+++ gcc/testsuite/c-c++-common/Wbool-operation-1.c  2016-10-01 
01:39:47.878097701 +0200
@@ -1,6 +1,6 @@
 /* PR c/77490 */
 /* { dg-do compile } */
-/* { dg-options "-Wall" } */
+/* { dg-options "-Wall -Wno-psabi" } */
 
 #ifndef __cplusplus
 # define bool _Bool
@@ -34,3 +34,5 @@ fn (bool b, bool b2, T b3, int n, v4si v
 
   return r;
 }
+
+/* { dg-prune-output ".*GCC vector passed by reference.*" } */

Jakub

Re: Implement P0001R1 - C++17 removal of register storage class specifier

[Jakub Jelinek]

On Fri, Sep 30, 2016 at 05:32:31PM -0400, Jason Merrill wrote:
> On Fri, Sep 30, 2016 at 4:10 AM, Jakub Jelinek  wrote:
> > On Thu, Sep 29, 2016 at 10:57:07PM +, Joseph Myers wrote:
> >> This is missing documentation of the new -Wregister option in invoke.texi.
> >
> > While I had it in my head when working on the patch, I forgot to do that in 
> > the end.
> > Fixed thusly, ok for trunk?
> 
> OK.  But also, the patch has introduced several check-c++1z failures:
> 
> > FAIL: g++.dg/charset/asm2.c  -std=c++1z (test for excess errors)
> > FAIL: g++.dg/ext/asm3.C  -std=c++1z (test for excess errors)
> > FAIL: g++.dg/tls/diag-2.C  -std=c++1z (test for excess errors)
> > FAIL: g++.dg/tls/diag-4.C  -std=c++1z (test for excess errors)
> > FAIL: g++.old-deja/g++.brendan/warnings4.C  -std=c++1z (test for excess 
> > errors)
> > FAIL: g++.old-deja/g++.eh/ia64-1.C  -std=gnu++1z (test for excess errors)
> > FAIL: g++.old-deja/g++.jason/enum3.C  -std=gnu++1z (test for excess errors)
> > FAIL: g++.old-deja/g++.mike/net31.C  -std=c++1z (test for excess errors)
> > FAIL: g++.old-deja/g++.mike/p700.C  -std=gnu++1z (test for excess errors)
> > FAIL: g++.old-deja/g++.other/regstack.C  -std=gnu++1z (test for excess 
> > errors)

Oops, I've been planning to do check-c++-all after the bootstrap/regtest,
but apparently forgot to do that in the end.

The following patch should fix that, ok for trunk?

2016-10-01  Jakub Jelinek  

* g++.dg/ext/asm3.C (two): Only use register keyword for C++14 and
earlier.
* g++.dg/charset/asm2.c (memmove): Likewise.
* g++.dg/tls/diag-2.C (foo): Expect -Wregister error for C++17.
* g++.dg/tls/diag-4.C (foo): Likewise.
* c-c++-common/vector-subscript-2.c (vf): Change dg-error to
dg-warning, fix up regex.
* g++.old-deja/g++.brendan/warnings4.C: Limit to c++14_down targets.
* g++.old-deja/g++.mike/p700.C: Add -Wno-register.
* g++.old-deja/g++.mike/net31.C: Likewise.
* g++.old-deja/g++.other/regstack.C (foo): Expect -Wregister warning
for C++17.
* g++.old-deja/g++.jason/enum3.C: Add -Wno-register.
* g++.old-deja/g++.eh/ia64-1.C: Likewise.

--- gcc/testsuite/g++.dg/ext/asm3.C.jj  2014-09-25 15:02:34.0 +0200
+++ gcc/testsuite/g++.dg/ext/asm3.C 2016-10-01 01:00:53.107415429 +0200
@@ -7,9 +7,12 @@
 
 int two(int in)
 {
-  register int out;
+#if __cplusplus <= 201402L
+  register
+#endif
+  int out;
   __asm__ ("" : "r" (out) : "r" (in));
   return out;
 }
 
-// { dg-message "error:" "" { target *-*-* } 11 }
+// { dg-message "error:" "" { target *-*-* } 14 }
--- gcc/testsuite/g++.dg/charset/asm2.c.jj  2014-09-25 15:02:36.0 
+0200
+++ gcc/testsuite/g++.dg/charset/asm2.c 2016-10-01 00:58:59.594839475 +0200
@@ -10,7 +10,10 @@
 void *
 memmove (void *__dest, __const void *__src, size_t __n)
 {
-  register unsigned long int __d0, __d1, __d2;
+#if __cplusplus <= 201402L
+  register
+#endif
+  unsigned long int __d0, __d1, __d2;
   if (__dest < __src)
 __asm__ __volatile__
   ("cld\n\t"
--- gcc/testsuite/g++.dg/tls/diag-2.C.jj2014-09-25 15:02:36.0 
+0200
+++ gcc/testsuite/g++.dg/tls/diag-2.C   2016-10-01 01:03:03.002785384 +0200
@@ -12,7 +12,7 @@ void foo()
   auto __thread int l2;/* { dg-error "multiple storage 
classes|data types" } */
   __thread extern int l3;  /* { dg-error "'__thread' before 'extern'" } */
   register __thread int l4;/* { dg-error "multiple storage classes" } */
-}
+}  /* { dg-error "ISO C\\+\\+1z does not allow 
'register' storage class specifier" "" { target c++1z } .-1 } */
 
 __thread void f1 ();   /* { dg-error "invalid for function" } */
 extern __thread void f2 ();/* { dg-error "invalid for function" } */
--- gcc/testsuite/g++.dg/tls/diag-4.C.jj2014-09-25 15:02:36.0 
+0200
+++ gcc/testsuite/g++.dg/tls/diag-4.C   2016-10-01 01:03:28.986458585 +0200
@@ -7,4 +7,4 @@ void foo()
 {
   __thread auto int l2;/* { dg-error "multiple storage 
classes|data types" } */
   __thread register int l4;/* { dg-error "multiple storage classes" } */
-}
+}  /* { dg-error "ISO C\\+\\+1z does not allow 
'register' storage class specifier" "" { target c++1z } .-1 } */
--- gcc/testsuite/c-c++-common/vector-subscript-2.c.jj  2016-09-30 
18:40:58.335979346 +0200
+++ gcc/testsuite/c-c++-common/vector-subscript-2.c 2016-10-01 
01:22:19.577245968 +0200
@@ -7,6 +7,6 @@
 
 float vf(int i)
 {
-  register vector float a; // { dg-error "ISO C++1z does not allow 
'register' storage class specifier" "" { target c++1z } }
+  register vector float a; // { dg-warning "ISO C\\+\\+1z does not allow 
'register' storage class specifier" "" { target c++1z } }
   return a[0];
 }
--- gcc/testsuite/g++.old-deja/g++.brendan/warnings4.C.jj   2014-09-25 
15:02:10.0 +0200
+++ 

[Patch, Fortran] PR66643 Check for missing format

[Jerry DeLisle]

Committed r240686
M   gcc/testsuite/ChangeLog
M   gcc/testsuite/gfortran.fortran-torture/compile/write.f90
M   gcc/testsuite/gfortran.fortran-torture/compile/arrayio.f90
M   gcc/fortran/ChangeLog
M   gcc/fortran/io.c

as obvious and trivial.

Regards,

Jerry

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Ian Lance Taylor]

Jakub Jelinek  writes:

> 2016-09-30  Jakub Jelinek  
>
>   * configure.ac: Add target-libffi to target_libraries.
>   Readd libgcj target disablings, modified to only target-libffi.
>   Readd target addition of go to unsupported languages.
>   * configure: Regenerated.

This is OK.  Thanks.

I saw that the discussion was clear that libffi was needed for libgo,
and the patch I saw did not remove the libffi configury.  I don't know
what happened.

Ian

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Rainer Orth]

Hi Eric,

>> I haven't tried to readd the boehm-gc objc support that has also been
>> disabled, don't know about anybody using that.
>
> I always configure with --enable-objc-gc. The only reason Apple
> deprecated garbage collection for Objective C is because they replaced
> it with Automated Reference Counting in clang, which GCC doesn't
> support yet. So, until GCC supports Automated Reference Counting,
> please keep boehm-gc support for objc.

me too, though mostly to have maximum test coverage (primarily on
Solaris).  As expected, a x86_64-apple-darwin16 bootstrap with
--enable-objc-gc just failed for me.  I'm testing the following patch
(on top of Jakub's).

Rainer


2016-10-01  Rainer Orth  

* configure.ac (target_libraries): Readd target-boehm-gc.
Restore --enable-objc-gc handling.
* configure: Regenerate.

--- configure.ac.pre-bgc	2016-09-30 23:20:44.0 +0200
+++ configure.ac	2016-09-30 23:28:35.952184178 +0200
@@ -161,6 +161,7 @@ target_libraries="target-libgcc \
 		target-libssp \
 		target-libquadmath \
 		target-libgfortran \
+		target-boehm-gc \
 		target-libffi \
 		target-libobjc \
 		target-libada \
@@ -2054,6 +2055,28 @@ for dir in $configdirs $build_configdirs
   fi
 done
 
+# Check for Boehm's garbage collector
+AC_ARG_ENABLE(objc-gc,
+[AS_HELP_STRING([--enable-objc-gc],
+		[enable use of Boehm's garbage collector with the
+		 GNU Objective-C runtime])],
+[case ,${enable_languages},:${enable_objc_gc}:${noconfigdirs} in
+  *,objc,*:*:yes:*target-boehm-gc*)
+AC_MSG_ERROR([Boehm's garbage collector was requested yet not supported in this configuration])
+;;
+esac])
+
+# Make sure we only build Boehm's garbage collector if required.
+case ,${enable_languages},:${enable_objc_gc} in
+  *,objc,*:yes)
+# Keep target-boehm-gc if requested for Objective-C.
+;;
+  *)
+# Otherwise remove target-boehm-gc.
+noconfigdirs="$noconfigdirs target-boehm-gc"
+;;
+esac
+
 # Disable libcilkrts, libitm, libsanitizer, libvtv, liboffloadmic if we're not building C++
 case ,${enable_languages}, in
   *,c++,*)

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

Re: [PATCH] Cleanup of input.c

[David Malcolm]

On Mon, 2016-09-26 at 14:30 +, Bernd Edlinger wrote:
> Hi,
> 
> this started, because I saw get_next_line returns -1 on error,
> instead
> of false: PR 77699.
> 
> But when I was there I also saw that read_line_num is using memmove
> on
> non-aliased src & dest, instead of memcpy.  But then I see that
> also adding a NUL byte is superfluos, and all the copying as well
> 
> 
> So the result is a cleanup of input.c that avoids lots of copying
> altogether, because it is no longer necessary to do so.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?

I'll attempt to review this with my "diagnostics maintainer" hat on - 
 but I'm not as familiar with input.c's implementation as with the restof the 
diagnostics subsystem.

Did you try running this under valgrind?
  (e.g. "make selftest-valgrind" at least)

FWIW I made the following notes to try to understand the existing
behavior:

  get_next_line:
sets its *line to values related to c->data, the buffered content
  of all of the file so far...
  c->data can be reallocated in maybe_grow, called by read_data,
  called by maybe_read_line, called by get_next_line
  invalidating the exposed ptr whenever the buffer growth needs a
  re-allocation.

  read_next_line:
copies the exposed part of c->data to *line
Note that it's a different *line:
It calls get_next_line with , so *line in get_next_line is 
writing to "l" in read_next_line, exposing part of c->data
read_next_line ensures that the passed-in-ptr's buffer is big
enough, then does a memcpy to it, effectively from c->data.

  goto_next_line:
also calls get_next_line, but doesn't bother copying the result
anywhere

  read_line_num:
calls goto_next_line repeatedly
then calls read_next_line, thus effectively read_next_line is 
copying data to the passed-in-ptr

  location_get_source_line:
calls read_next_line, managing:
  static char *buffer;
  static ssize_t len;
as the place where the copies are written to
Hence only one such buffer is live per-process, and it can't leak.
Hence location_get_source_line can't leak, but the buffer exposed
to the caller is only valid until the next call to
location_get_source_line.

> 2016-09-26  Bernd Edlinger  
> 
>   PR preprocessor/77699
>   * input.c (maybe_grow): Don't allocate one byte extra
headroom.
>   (get_next_line): Return false on error.
>   (read_next_line): Removed, use get_next_line instead.
>   (read_line_num): Don't copy the line.
>   (location_get_source_line): Don't use static data.
> 
> 
> Index: gcc/input.c
> ===
> --- gcc/input.c   (revision 240471)
> +++ gcc/input.c   (working copy)
> @@ -432,7 +432,7 @@ maybe_grow (fcache *c)
>  return;
>  
>size_t size = c->size == 0 ? fcache_buffer_size : c->size * 2;
> -  c->data = XRESIZEVEC (char, c->data, size + 1);
> +  c->data = XRESIZEVEC (char, c->data, size);
>c->size = size;
>  }

Seems reasonable; I can't see anywhere where an extra byte could get
used.


> @@ -534,7 +534,7 @@ get_next_line (fcache *c, char **line, ssize_t
*li
>  }
>  
>if (ferror (c->fp))
> -return -1;
> +return false;

OK

>/* At this point, we've found the end of the of line.  It either
>   points to the '\n' or to one byte after the last byte of the
> @@ -597,36 +597,6 @@ get_next_line (fcache *c, char **line, ssize_t
*li
>return true;
>  }
>  
> -/* Reads the next line from FILE into *LINE.  If *LINE is too small
> -   (or NULL) it is allocated (or extended) to have enough space to
> -   containe the line.  *LINE_LENGTH must contain the size of the
> -   initial*LINE buffer.  It's then updated by this function to the
> -   actual length of the returned line.  Note that the returned line
> -   can contain several zero bytes.  Also note that the returned
string
> -   is allocated in static storage that is going to be re-used by
> -   subsequent invocations of read_line.  */
> -
> -static bool
> -read_next_line (fcache *cache, char ** line, ssize_t *line_len)
> -{
> -  char *l = NULL;
> -  ssize_t len = 0;
> -
> -  if (!get_next_line (cache, , ))
> -return false;
> -
> -  if (*line == NULL)
> -*line = XNEWVEC (char, len);
> -  else
> -if (*line_len < len)
> - *line = XRESIZEVEC (char, *line, len);
> -
> -  memcpy (*line, l, len);
> -  *line_len = len;
> -
> -  return true;
> -}
> -
>  /* Consume the next bytes coming from the cache (or from its
> underlying file if there are remaining unread bytes in the file)
> until we reach the next end-of-line (or end-of-file).  There is
no
> @@ -651,7 +621,7 @@ goto_next_line (fcache *cache)
>  
>  static bool
>  read_line_num (fcache *c, size_t line_num,
> -char ** line, ssize_t *line_len)
> +char **line, ssize_t *line_len)
>  {
>gcc_assert (line_num > 

Re: C/C++ PATCH to implement -Wpointer-compare warning (PR c++/64767)

[Martin Sebor]

On 09/30/2016 01:40 PM, Marek Polacek wrote:

On Fri, Sep 30, 2016 at 01:08:19PM -0600, Martin Sebor wrote:

On 09/30/2016 11:05 AM, Martin Sebor wrote:

+permerror (input_location, "ISO C++11 only allows pointer "
+   "conversions for integer literals");


FWIW, I think it would be clearer to either mention the currently
selected language version or leave it out completely rather than
hardcoding C++11.  When the user specifies -std=c++14 (or later),
or when that's the current version used by the compiler, a warning
that tells them what C++ 11 allows isn't really relevant (or
meaningful), and becomes less so as time goes on.


Btw., I realize there are other instances where the C++ version
has been hardcoded and so I should have made it clear that I meant
my comment as a general suggestion, not as an objection to the patch.
Sorry if that wasn't apparent.

I've quickly surveyed some of the existing messages that mention
a C++ version and found instances where it applies only to the
referenced version of the standard and prior but not later versions. For
example:

  msgid "in C++98 %q+D may not be static because it is a member of a union"
  msgid "in C++03 a class-key must be used when declaring a friend"

But I also came across another form that may resolve the concern
I raised: mentioning the version along with whether it's the first
or last that supports (or doesn't support) the construct, such as
"C++11 and above."  Here's one example of it:

  msgid "in C++11 and above a default constructor can be explicit"

It might be worth to come up with a convention to adopt in new
messages and (gradually) change what's already there to use it.


Maybe, no strong opinions, I'll just go with whatever people prefer here.
Though I guess I like those explicit versions because you know when a
particular thing changed.  And when you're using -std=c++14 and the
compiler says C++11, I think that's ok, because C++14 implies C++11.


I agree that mentioning the (first or last) version can be helpful.
Does adopting the "C++11 and later" and "C++11 and earlier" phrasing
sound good then?  If no one objects I'll add it to the Guidelines for
C/C++ FE diagnostics on the Wiki.

(I changed "above" to "later" because it pairs better with "earlier"
than "below" would , and because it seems to be more natural when
referring to the year the version a standard was ratified.)

Martin

Re: C/C++ PATCH to implement -Wpointer-compare warning (PR c++/64767)

[Jason Merrill]

On Fri, Sep 30, 2016 at 12:43 PM, Marek Polacek  wrote:
> On Fri, Sep 23, 2016 at 10:31:33AM -0400, Jason Merrill wrote:
>> On Fri, Sep 23, 2016 at 9:15 AM, Marek Polacek  wrote:
>> > On Wed, Sep 21, 2016 at 03:52:09PM -0400, Jason Merrill wrote:
>> >> On Mon, Sep 19, 2016 at 2:49 PM, Jason Merrill  wrote:
>> >> > I suppose that an INTEGER_CST of character type is necessarily a
>> >> > character constant, so adding a check for !char_type_p ought to do the
>> >> > trick.
>> >>
>> >> Indeed it does.  I'm checking this in:
>> >
>> > Nice, thanks.  What about the original patch?  We still need to warn
>> > (or error for C++11) for pointer comparisons.
>>
>> If we still accept pointer comparisons in C++, that's another bug with
>> treating \0 as a null pointer constant.  This seems to be because
>> ocp_convert of \0 to int produces an INTEGER_CST indistinguishable
>> from literal 0.
>
> I was trying to fix this in ocp_convert, by using NOP_EXPRs, but that wasn't
> successful.  But since we're interested in ==/!=, I think this can be fixed
> easily in cp_build_binary_op.  Actually, all that seems to be needed is using
> orig_op as the argument to null_ptr_cst_p, but that wouldn't give the correct
> diagnostics, so I did this.  By checking orig_op we can see if the operands 
> are
> character literals or not, because orig_op is an operand before the default
> conversions.

What is wrong about the diagnostic from just using orig_op?  "ISO C++
forbids comparison between pointer and integer" seems fine to me, and
will help the user to realize that they need to index off the pointer.

I see that some of the calls to null_ptr_cst_p in cp_build_binary_op
have already been changed to check orig_op*, but not all.  Let's
update the remaining calls, that should do the trick without adding a
new error.

Jason

Re: [Patch 5/11] Add -fpermitted-flt-eval-methods=[c11|ts-18661-3]

[Mike Stump]

On Sep 30, 2016, at 10:34 AM, Jeff Law  wrote:
>> 2016-09-30  James Greenhalgh  
>> 
>>  * gcc.dg/fpermitted-flt-eval-methods_1.c: New.
>>  * gcc.dg/fpermitted-flt-eval-methods_2.c: New.
> OK.Are you going to need to do something for C++ (or gasp ObjC) in the 
> future

ObjC should come along for free as long as major rules of ettiquite aren't 
broken.

As test that says, make this work only for C, would be wrong.  Conditionalizing 
a flag as only for C would be wrong.  I glanced around and didn't see anything 
that would make it not work for ObjC.

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

[Jason Merrill]

On Fri, Sep 30, 2016 at 7:10 AM, Bernd Schmidt  wrote:
> On 09/30/2016 12:51 PM, Jakub Jelinek wrote:
>> On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote:
>>> On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
>>>
 See Tom Tromey's explanation why accepting too much is bad (at least
 unless we want multiple levels).
>>>
>>> And I still don't buy it. The case where someone writes "Don't fall
>>> through" is artificial to begin with, and also forgetting to put the break; 
>>> there
>>> really isn't something for us to be concerned about.

Agreed.

>> It doesn't have to be exactly that, fall is a substring of 200+ english,
>> thr is a substring of 1000+ english words, if you allow arbitrary stuff in
>> between or before it or after it, it can say anything, completely
>> unrelated to falling through across case labels.
>
> True, but IMO irrelevant. We have to consider what is likely in real code.
> We're trying to catch likely problems without adding a prohibitive cost to
> enabling -Wextra. It's not helpful to punish people for writing code that is
> valid and documents intentional fallthrough, but does it in a style or a
> language we didn't expect.
>
> A complete solution would require working AI; maybe someone from Google can
> contribute one. Failing that, we need heuristics, and I still like Michael's
> suggestion of not printing a warning if we see _any_ comment, on the grounds
> that this would still catch the vast majority of actual errors, without the
> huge false positive rate we currently have.

I think this would lead to too many false negatives, as explanatory
comments before a case label are extremely common.  I prefer the
*fall*thr{u,ough}* heuristic.

Jason

Re: Implement P0001R1 - C++17 removal of register storage class specifier

[Jason Merrill]

On Fri, Sep 30, 2016 at 4:10 AM, Jakub Jelinek  wrote:
> Hi!
>
> On Thu, Sep 29, 2016 at 10:57:07PM +, Joseph Myers wrote:
>> This is missing documentation of the new -Wregister option in invoke.texi.
>
> While I had it in my head when working on the patch, I forgot to do that in 
> the end.
> Fixed thusly, ok for trunk?

OK.  But also, the patch has introduced several check-c++1z failures:

> FAIL: g++.dg/charset/asm2.c  -std=c++1z (test for excess errors)
> FAIL: g++.dg/ext/asm3.C  -std=c++1z (test for excess errors)
> FAIL: g++.dg/tls/diag-2.C  -std=c++1z (test for excess errors)
> FAIL: g++.dg/tls/diag-4.C  -std=c++1z (test for excess errors)
> FAIL: g++.old-deja/g++.brendan/warnings4.C  -std=c++1z (test for excess 
> errors)
> FAIL: g++.old-deja/g++.eh/ia64-1.C  -std=gnu++1z (test for excess errors)
> FAIL: g++.old-deja/g++.jason/enum3.C  -std=gnu++1z (test for excess errors)
> FAIL: g++.old-deja/g++.mike/net31.C  -std=c++1z (test for excess errors)
> FAIL: g++.old-deja/g++.mike/p700.C  -std=gnu++1z (test for excess errors)
> FAIL: g++.old-deja/g++.other/regstack.C  -std=gnu++1z (test for excess errors)

PATCH to fix bogus -Wimplicit-fallthrough warning (PR c++/77803)

[Marek Polacek]

This PR reports a bogus -Wimplicit-fallthrough warning on the attached test.
The problem is that last_stmt_in_scope should for GIMPLE_TRY, if the last
statement of the eval part can't fallthrough, return this statement and don't
warn.  And the same should be true for FALLTHROUGH ().   This patch fixes it.

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

2016-09-30  Marek Polacek  

PR c++/77803
* gimplify.c (last_stmt_in_scope): Add check for FALLTHROUGH ().

* g++.dg/warn/Wimplicit-fallthrough-1.C: New test.

diff --git gcc/gimplify.c gcc/gimplify.c
index 66bb8be..97d63db 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -1687,6 +1687,7 @@ last_stmt_in_scope (gimple *stmt)
stmt = gimple_seq_last_stmt (gimple_try_eval (try_stmt));
gimple *last_eval = last_stmt_in_scope (stmt);
if (gimple_stmt_may_fallthru (last_eval)
+   && !gimple_call_internal_p (last_eval, IFN_FALLTHROUGH)
&& gimple_try_kind (try_stmt) == GIMPLE_TRY_FINALLY)
  {
stmt = gimple_seq_last_stmt (gimple_try_cleanup (try_stmt));
diff --git gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C 
gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C
index e69de29..8f80b01 100644
--- gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C
+++ gcc/testsuite/g++.dg/warn/Wimplicit-fallthrough-1.C
@@ -0,0 +1,16 @@
+// PR c++/77803
+// { dg-do compile { target c++11 } }
+// { dg-options "-Wimplicit-fallthrough" }
+
+struct A {};
+int a;
+void fn1() {
+  switch (0) {
+  case 0: {
+A b;
+[[fallthrough]];
+  }
+  default:
+a = 0;
+  }
+}

Marek

[v3 PATCH] PR libstdc++/77802

[Ville Voutilainen]

I do this with a rather heavy heart, but since gcc6 compiles boost 1.62,
I'll rather have gcc7 do so as well, and I'll throw the tuple fix for lwg2729
to the wolves not because I want to, but because I have to.

Tested on Linux-x64.

2016-10-01  Ville Voutilainen  

PR libstdc++/77802

* testsuite/20_util/tuple/77802.cc: New.

Revert:
2016-09-21  Ville Voutilainen  
Implement LWG 2729 for tuple.
* include/std/tuple (_Tuple_impl(_Tuple_impl&&)):
Suppress conditionally.
(_Tuple_impl(_Tuple_impl<_Idx, _UHead, _UTails...>&&)): Likewise.
(__is_tuple_impl_trait_impl, __is_tuple_impl_trait): New.
(_Tuple_impl(const _Head&)): Constrain.
(_Tuple_impl(_UHead&&)): Likewise.
(_Tuple_impl(_Tuple_impl&&)): Suppress conditionally.
(_Tuple_impl(const _Tuple_impl<_Idx, _UHead>&)): Constrain.
(_Tuple_impl(_Tuple_impl<_Idx, _UHead>&&)): Likewise.
(operator=(const tuple&)): Enable conditionally.
(operator=(tuple&&)): Suppress conditionally.
(operator=(const tuple<_UElements...>&)): Constrain.
(operator=(tuple<_UElements...>&&)): Likewise.
(operator=(const tuple&)): Enable conditionally (2-param tuple).
(operator=(tuple&&)): Suppress conditionally (2-param tuple).
(operator=(const tuple<_U1, _U2>&)): Constrain.
(operator=(tuple<_U1, _U2>&&)): Likewise.
(operator=(const pair<_U1, _U2>&)): Likewise.
(operator=(pair<_U1, _U2>&&)): Likewise.
* testsuite/20_util/tuple/element_access/get_neg.cc: Adjust.
* testsuite/20_util/tuple/tuple_traits.cc: New.
diff --git a/libstdc++-v3/include/std/tuple b/libstdc++-v3/include/std/tuple
index 32b932f..c06a040 100644
--- a/libstdc++-v3/include/std/tuple
+++ b/libstdc++-v3/include/std/tuple
@@ -220,11 +220,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   constexpr _Tuple_impl(const _Tuple_impl&) = default;
 
   constexpr
-  _Tuple_impl(typename conditional<
- __and_,
-is_move_constructible<_Inherited>>::value,
- _Tuple_impl&&, __nonesuch&&>::type __in)
-   noexcept(__and_,
+  _Tuple_impl(_Tuple_impl&& __in)
+  noexcept(__and_,
  is_nothrow_move_constructible<_Inherited>>::value)
   : _Inherited(std::move(_M_tail(__in))),
_Base(std::forward<_Head>(_M_head(__in))) { }
@@ -235,11 +232,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _Base(_Tuple_impl<_Idx, _UElements...>::_M_head(__in)) { }
 
   template
-constexpr _Tuple_impl(typename conditional<
- __and_,
- is_move_constructible<_Inherited>>::value,
- _Tuple_impl<_Idx, _UHead, _UTails...>&&,
- __nonesuch&&>::type __in)
+constexpr _Tuple_impl(_Tuple_impl<_Idx, _UHead, _UTails...>&& __in)
: _Inherited(std::move
 (_Tuple_impl<_Idx, _UHead, _UTails...>::_M_tail(__in))),
  _Base(std::forward<_UHead>
@@ -345,18 +338,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 };
 
-  template
-struct __is_tuple_impl_trait_impl : false_type
-{ };
-
-  template
-struct __is_tuple_impl_trait_impl<_Tuple_impl<_Idx, _Tp...>> : true_type
-{ };
-
-  template
-struct __is_tuple_impl_trait : public __is_tuple_impl_trait_impl<_Tp>
-{ };
-
   // Basis case of inheritance recursion.
   template
 struct _Tuple_impl<_Idx, _Head>
@@ -375,20 +356,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   constexpr _Tuple_impl()
   : _Base() { }
 
-  template::value,
- bool>::type=true>
   explicit
   constexpr _Tuple_impl(const _Head& __head)
   : _Base(__head) { }
 
-  template,
-__not_<__is_tuple_impl_trait<
-  typename
-remove_reference<_UHead>::type>>
->::value,
- bool>::type = true>
+  template
 explicit
 constexpr _Tuple_impl(_UHead&& __head)
: _Base(std::forward<_UHead>(__head)) { }
@@ -396,21 +368,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   constexpr _Tuple_impl(const _Tuple_impl&) = default;
 
   constexpr
-  _Tuple_impl(typename conditional<
- is_move_constructible<_Head>::value,
- _Tuple_impl&&, __nonesuch&&>::type __in)
+  _Tuple_impl(_Tuple_impl&& __in)
   noexcept(is_nothrow_move_constructible<_Head>::value)
   : _Base(std::forward<_Head>(_M_head(__in))) { }
 
-  template::value,
- bool>::type = true>
+  template
 constexpr _Tuple_impl(const _Tuple_impl<_Idx, _UHead>& __in)
: _Base(_Tuple_impl<_Idx, 

[PATCH] FALLTHRU markers for sse.md and some cleanups

[Jakub Jelinek]

On Thu, Sep 29, 2016 at 06:21:13PM +0200, Marek Polacek wrote:
> On Tue, Sep 27, 2016 at 09:58:20PM +0200, Jakub Jelinek wrote:
> > On Tue, Sep 27, 2016 at 09:29:10PM +0200, Florian Weimer wrote:
> > > Not sure if I read this code correctly, but if we fall through from
> > > V32HImode, and we have TARGET_SSE2 set, we execute this code:
> > > 
> > >   tmp = "p";
> > >   ssesuffix = TARGET_AVX512VL ? "q" : "";
> > > 
> > > And not gcc_unreachable (), as is probably intended.
> > 
> > It really doesn't matter.
> > The instruction uses
> > (define_mode_iterator VI12_AVX_AVX512F
> >   [ (V64QI "TARGET_AVX512F") (V32QI "TARGET_AVX") V16QI
> > (V32HI "TARGET_AVX512F") (V16HI "TARGET_AVX") V8HI])
> > iterator (and, after all, ix86_hard_regno_mode_ok should ensure the same),
> > which means V64QI/V32HI will only show up for TARGET_AVX512F, V32QI/V16HI
> > only for TARGET_AVX (which implies TARGET_SSE2), and the slightly
> > nonsensical
> > gcc_assert (TARGET_SSE2 || TARGET_AVX512VL);
> > before the switch (the  || TARGET_AVX512VL is pointless, because
> > TARGET_AVX512VL implies TARGET_SSE2 as well as TARGET_AVX2).
> > So, I'd go perhaps for (untested) following patch, first diff -up, followed
> > by diff -upb:
> 
> Looks good, are you going to test/commit it?  Or should I?

Here it is, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2016-09-30  Jakub Jelinek  

* config/i386/sse.md (): Add FALLTHRU
comments.  Simplify asserts, remove unnecessary conditions.
Formatting fixes.
(*3): Likewise.

--- gcc/config/i386/sse.md.jj   2016-08-30 08:42:09.169067639 +0200
+++ gcc/config/i386/sse.md  2016-09-30 14:40:45.382959729 +0200
@@ -11393,41 +11393,40 @@ (define_insn "
 {
 case MODE_XI:
   gcc_assert (TARGET_AVX512F);
+  /* FALLTHRU */
 case MODE_OI:
-  gcc_assert (TARGET_AVX2 || TARGET_AVX512VL);
+  gcc_assert (TARGET_AVX2);
+  /* FALLTHRU */
 case MODE_TI:
-  gcc_assert (TARGET_SSE2 || TARGET_AVX512VL);
+  gcc_assert (TARGET_SSE2);
   switch (mode)
-  {
-case V16SImode:
-case V8DImode:
-  if (TARGET_AVX512F)
-  {
-tmp = "p";
-break;
-  }
-case V8SImode:
-case V4DImode:
-case V4SImode:
-case V2DImode:
-  tmp = TARGET_AVX512VL ? "p" : "p";
-  break;
-default:
-  gcc_unreachable ();
-  }
+   {
+   case V16SImode:
+   case V8DImode:
+ tmp = "p";
+ break;
+   case V8SImode:
+   case V4DImode:
+   case V4SImode:
+   case V2DImode:
+ tmp = TARGET_AVX512VL ? "p" : "p";
+ break;
+   default:
+ gcc_unreachable ();
+   }
   break;
 
-   case MODE_V8SF:
+case MODE_V8SF:
   gcc_assert (TARGET_AVX);
-   case MODE_V4SF:
+case MODE_V4SF:
   gcc_assert (TARGET_SSE);
   gcc_assert (!);
   tmp = "ps";
   break;
 
-   default:
+default:
   gcc_unreachable ();
-   }
+}
 
   switch (which_alternative)
 {
@@ -11489,46 +11488,42 @@ (define_insn "*3"
 {
 case MODE_XI:
   gcc_assert (TARGET_AVX512F);
+  /* FALLTHRU */
 case MODE_OI:
-  gcc_assert (TARGET_AVX2 || TARGET_AVX512VL);
+  gcc_assert (TARGET_AVX2);
+  /* FALLTHRU */
 case MODE_TI:
-  gcc_assert (TARGET_SSE2 || TARGET_AVX512VL);
+  gcc_assert (TARGET_SSE2);
   switch (mode)
-{
-case V64QImode:
-case V32HImode:
-  if (TARGET_AVX512F)
-  {
-tmp = "p";
-ssesuffix = "q";
-break;
-  }
-case V32QImode:
-case V16HImode:
-case V16QImode:
-case V8HImode:
-  if (TARGET_AVX512VL || TARGET_AVX2 || TARGET_SSE2)
-  {
-tmp = "p";
-ssesuffix = TARGET_AVX512VL ? "q" : "";
-break;
-  }
-default:
-  gcc_unreachable ();
-  }
+   {
+   case V64QImode:
+   case V32HImode:
+ tmp = "p";
+ ssesuffix = "q";
+ break;
+   case V32QImode:
+   case V16HImode:
+   case V16QImode:
+   case V8HImode:
+ tmp = "p";
+ ssesuffix = TARGET_AVX512VL ? "q" : "";
+ break;
+   default:
+ gcc_unreachable ();
+   }
   break;
 
-   case MODE_V8SF:
+case MODE_V8SF:
   gcc_assert (TARGET_AVX);
-   case MODE_V4SF:
+case MODE_V4SF:
   gcc_assert (TARGET_SSE);
   tmp = "ps";
   ssesuffix = "";
   break;
 
-   default:
+default:
   gcc_unreachable ();
-   }
+}
 
   switch (which_alternative)
 {


Jakub

[PATCH] Improve target pass registration

[Jakub Jelinek]

Hi!

As discussed earlier on IRC, the current way of registering target specific
passes has various issues:
1) for -da, the target specific dump files appear last, regardless on where
   exactly they appear in the pass queue, so one has to look up the sources
   or remember where the pass is invoked if e.g. looking for when certain
   change in the IL first appears
2) -fdump-rtl-stv-details and similar options don't work, the option
   processing happens before the passes are registered

This patch allows backends to provide their *-passes.def file with
instructions how to ammend passes.def, which then can be inspected in
pass-instances.def the script generates.

I've only converted the i386 backend so far, other maintainers can easily
convert their backends later on.

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

2016-09-30  Jakub Jelinek  

* gen-pass-instances.awk: Rewritten.
* Makefile.in (pass-instances.def): Depend on $(PASSES_EXTRA), pass
$(PASSES_EXTRA) after passes.def to the script.
* config/i386/t-i386 (PASSES_EXTRA): Add i386-passes.def.
* config/i386/i386-passes.def: New file.
* config/i386/i386-protos.h (make_pass_insert_vzeroupper,
make_pass_stv): Declare.
* config/i386/i386.c (pass_stv::pass_stv): Initialize timode_p to
false.
(pass_stv::gate): Depending on timode_p member require TARGET_64BIT
or !TARGET_64BIT.
(pass_stv::clone, pass_stv::set_pass_param): New methods.
(pass_stv::timode_p): New non-static data member.
(ix86_option_override): Don't register passes here.

--- gcc/gen-pass-instances.awk.jj   2016-09-29 22:53:10.264776158 +0200
+++ gcc/gen-pass-instances.awk  2016-09-30 13:22:53.745373889 +0200
@@ -17,6 +17,8 @@
 # This Awk script takes passes.def and writes pass-instances.def,
 # counting the instances of each kind of pass, adding an instance number
 # to everywhere that NEXT_PASS is used.
+# Also handle INSERT_PASS_AFTER, INSERT_PASS_BEFORE and REPLACE_PASS
+# directives.
 #
 # For example, the single-instanced pass:
 # NEXT_PASS (pass_warn_unused_result);
@@ -30,81 +32,201 @@
 # through:
 #   NEXT_PASS (pass_copy_prop, 8);
 # (currently there are 8 instances of that pass)
+#
+# INSERT_PASS_AFTER (pass_copy_prop, 1, pass_stv);
+# will insert
+# NEXT_PASS (pass_stv, 1);
+# after immediately after the NEXT_PASS (pass_copy_prop, 1) line,
+# similarly INSERT_PASS_BEFORE inserts immediately before that line.
+# REPLACE_PASS (pass_copy_prop, 1, pass_stv, true);
+# will replace NEXT_PASS (pass_copy_prop, 1) line with
+# NEXT_PASS (pass_stv, 1, true);
+# line and renumber all higher pass_copy_prop instances if any.
 
 # Usage: awk -f gen-pass-instances.awk passes.def
 
 BEGIN {
-   print "/* This file is auto-generated by gen-pass-instances.awk";
-   print "   from passes.def.  */";
+  print "/* This file is auto-generated by gen-pass-instances.awk";
+  print "   from passes.def.  */";
+  lineno = 1;
 }
 
-function handle_line()
+function parse_line(line, fnname,  len_of_call, len_of_start,
+   len_of_open, len_of_close,
+   len_of_args, args_start_at,
+   args_str, len_of_prefix,
+   call_starts_at,
+   postfix_starts_at)
 {
-   line = $0;
+  # Find call expression.
+  call_starts_at = match(line, fnname " \\(.+\\)");
+  if (call_starts_at == 0)
+return 0;
+
+  # Length of the call expression.
+  len_of_call = RLENGTH;
+
+  len_of_start = length(fnname " (");
+  len_of_open = length("(");
+  len_of_close = length(")");
+
+  # Find arguments
+  len_of_args = len_of_call - (len_of_start + len_of_close);
+  args_start_at = call_starts_at + len_of_start;
+  args_str = substr(line, args_start_at, len_of_args);
+  split(args_str, args, ",");
+
+  # Find call expression prefix
+  len_of_prefix = call_starts_at - 1;
+  prefix = substr(line, 1, len_of_prefix);
+
+  # Find call expression postfix
+  postfix_starts_at = call_starts_at + len_of_call;
+  postfix = substr(line, postfix_starts_at);
+  return 1;
+}
 
-   # Find call expression.
-   call_starts_at = match(line, /NEXT_PASS \(.+\)/);
-   if (call_starts_at == 0)
-   {
-   print line;
-   return;
-   }
+function adjust_linenos(above, increment,  p, i)
+{
+  for (p in pass_lines)
+if (pass_lines[p] >= above)
+  pass_lines[p] += pass_lines[p];
+  if (increment > 0)
+for (i = lineno - 1; i >= above; i--)
+  lines[i + increment] = lines[i];
+  else
+for (i = above; i < lineno; i++)
+  lines[i + increment] = lines[i];
+  lineno += increment;
+}
 
-   # Length of the call expression.
-   len_of_call = RLENGTH;
+function insert_remove_pass(line, fnname)
+{
+  parse_line($0, fnname);
+  

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

[Jakub Jelinek]

On Fri, Sep 30, 2016 at 11:26:27AM +0200, Marek Polacek wrote:
> I haven't gone over the patch in detail yet, but I wonder if we should
> also accept /* Else, fall through.  */ (to be found e.g. in aarch64-simd.md).

Here is the patch split into a series of 3 patches (the later patches depend
on the earlier ones):
1) the first patch fixes some bugs and fixes also -Wimplicit-fallthrough -C
2) the second patch adds the else and intentional/ly etc.
3) the third one adds the optional comma between else and fall

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

Jakub
2016-09-30  Jakub Jelinek  

* c-lex.c (c_lex_with_flags) : For CPP_COMMENT
token with PREV_FALLTHROUGH, skip all following CPP_PADDING and
CPP_COMMENT tokens and set add_flags to PREV_FALLTHROUGH afterwards.

* doc/invoke.texi (-Wimplicit-fallthrough): Document the accepted
FALLTHRU comment styles.

* lex.c (fallthrough_comment_p): Fix off-by-one size comparison
errors, cleanup.
(_cpp_lex_direct): Allow arbitrary comments in between
fallthrough_comment_p comment and following token.

* c-c++-common/Wimplicit-fallthrough-22.c: New test.
* c-c++-common/Wimplicit-fallthrough-23.c: New test.

--- gcc/c-family/c-lex.c.jj 2016-09-30 18:16:26.303336781 +0200
+++ gcc/c-family/c-lex.c2016-09-30 18:26:14.650999215 +0200
@@ -598,7 +598,18 @@ c_lex_with_flags (tree *value, location_
 
 /* CPP_COMMENT will appear when compiling with -C and should be
ignored.  */
- case CPP_COMMENT:
+case CPP_COMMENT:
+  if (tok->flags & PREV_FALLTHROUGH)
+   {
+ do
+   {
+ tok = cpp_get_token_with_location (parse_in, loc);
+ type = tok->type;
+   }
+ while (type == CPP_PADDING || type == CPP_COMMENT);
+ add_flags = PREV_FALLTHROUGH;
+ goto retry_after_at;
+   }
goto retry;
 
 default:
--- gcc/doc/invoke.texi.jj  2016-09-30 18:16:26.308336719 +0200
+++ gcc/doc/invoke.texi 2016-09-30 18:26:33.288766793 +0200
@@ -4157,10 +4157,26 @@ C++17 provides a standard way to suppres
 warning using @code{[[fallthrough]];} instead of the GNU attribute.  In C++11
 or C++14 users can use @code{[[gnu::fallthrough]];}, which is a GNU extension.
 Instead of the these attributes, it is also possible to add a "falls through"
-comment to silence the warning.  GCC accepts a wide range of such comments,
-for example all of "Falls through.", "fallthru", "FALLS-THROUGH" work.  This
-comment needs to consist of two words merely, optionally followed by periods
-or whitespaces.
+comment to silence the warning.  The whole body of the C or C++ style comment
+should match one of the following regular expressions:
+
+@itemize @bullet
+
+@item @code{-fallthrough}
+
+@item @code{@@fallthrough@@}
+
+@item @code{[ \t]*FALL(S | |-)?THR(OUGH|U)\.?[ \t]*}
+
+@item @code{[ \t]*Fall((s | |-)[Tt]|t)hr(ough|u)\.?[ \t]*}
+
+@item @code{[ \t]*fall(s | |-)?thr(ough|u)\.?[ \t]*}
+
+@end itemize
+
+and the comment needs to be followed after optional whitespace and other 
comments
+by @code{case} or @code{default} keywords or by a user label that preceeds some
+@code{case} or @code{default} label.
 
 @smallexample
 @group
--- libcpp/lex.c.jj 2016-09-30 18:16:22.987378137 +0200
+++ libcpp/lex.c2016-09-30 18:26:33.289766781 +0200
@@ -2060,7 +2060,7 @@ fallthrough_comment_p (cpp_reader *pfile
 }
   /* Whole comment contents (regex):
  [ \t]*FALL(S | |-)?THR(OUGH|U)\.?[ \t]*
- [ \t]*Fall(s | |-)?[Tt]hr(ough|u)\.?[ \t]*
+ [ \t]*Fall((s | |-)[Tt]|t)hr(ough|u)\.?[ \t]*
  [ \t]*fall(s | |-)?thr(ough|u)\.?[ \t]*
*/
   else
@@ -2070,30 +2070,27 @@ fallthrough_comment_p (cpp_reader *pfile
   unsigned char f = *from;
   if (f != 'F' && f != 'f')
return false;
-  if ((size_t) (pfile->buffer->cur - from) < sizeof "fallthrough")
+  if ((size_t) (pfile->buffer->cur - from) < sizeof "fallthru" - 1)
return false;
   bool all_upper = false;
   if (f == 'F' && memcmp (from + 1, "ALL", sizeof "ALL" - 1) == 0)
all_upper = true;
   else if (memcmp (from + 1, "all", sizeof "all" - 1))
return false;
-  if (from[sizeof "fall" - 1] == (all_upper ? 'S' : 's')
- && from[sizeof "falls" - 1] == ' ')
-   from += sizeof "falls " - 1;
-  else if (from[sizeof "fall" - 1] == ' '
-  || from[sizeof "fall" - 1] == '-')
-   from += sizeof "fall " - 1;
-  else if (from[sizeof "fall" - 1] != (all_upper ? 'T' : 't'))
+  from += sizeof "fall" - 1;
+  if (*from == (all_upper ? 'S' : 's') && from[1] == ' ')
+   from += 2;
+  else if (*from == ' ' || *from == '-')
+   from++;
+  else if (*from != (all_upper ? 'T' : 't'))
return false;
-  else
-   from += sizeof "fall" - 1;
   if ((f == 'f' || *from != 'T') && (all_upper || *from != 't'))
  

Re: [PATCH v4] PR48344: Fix unrecognizable insn error with -fstack-limit-register=r2

[Andreas Schwab]

On Feb 11 2016, Kelvin Nilsen  wrote:

>   * opts-global.c (handle_common_deferred_options): Introduce and
> initialize two global variables to remember command-line options
> specifying a stack-limiting register.
>   * opts.h: Add extern declarations of the two new global variables. 
>   * emit-rtl.c (init_emit_once): Initialize the stack_limit_rtx
> variable based on the values of the two new global variables.

That breaks gcc.target/m68k/stack-limit-1.c:

/daten/aranym/gcc/test/gcc/testsuite/gcc.target/m68k/stack-limit-1.c: In 
function 'dummy':
/daten/aranym/gcc/test/gcc/testsuite/gcc.target/m68k/stack-limit-1.c:6:1: 
error: unrecognizable insn:
(insn 10 9 11 (trap_if (ltu (cc0)
(const_int 0 [0]))
(const_int 1 [0x1])) 
/daten/aranym/gcc/test/gcc/testsuite/gcc.target/m68k/stack-limit-1.c:6 -1
 (nil))
/daten/aranym/gcc/test/gcc/testsuite/gcc.target/m68k/stack-limit-1.c:6:1: 
internal compiler error: in extract_insn, at recog.c:2287

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Eric Gallager]

On 9/30/16, Jakub Jelinek  wrote:
> Hi!
>
> On Fri, Sep 30, 2016 at 01:48:12PM +0100, Andrew Haley wrote:
>> On 30/09/16 11:27, Marek Polacek wrote:
>> > Can we move forward with this patch, then?
>>
>> I've been travelling for several weeks.  However, I'm back at my desk
>> now, so I can move this forward.  I have all the approvals and
>> everybody has had time to respond.  However, I'll need to pull some
>> more recent changes into my tree and merge again.
>
> Unfortunately this broke bootstrap, because libgo needs libffi (at least on
> lots of targets) and target libffi is no longer built.
>
> This patch restores what we had before for target-libffi, it can be
> incrementally tweaked by individual target maintainers.
>
> I haven't tried to readd the boehm-gc objc support that has also been
> disabled, don't know about anybody using that.
>


I always configure with --enable-objc-gc. The only reason Apple
deprecated garbage collection for Objective C is because they replaced
it with Automated Reference Counting in clang, which GCC doesn't
support yet. So, until GCC supports Automated Reference Counting,
please keep boehm-gc support for objc.

Thanks,
Eric

Re: C/C++ PATCH to implement -Wpointer-compare warning (PR c++/64767)

[Marek Polacek]

On Fri, Sep 30, 2016 at 01:08:19PM -0600, Martin Sebor wrote:
> On 09/30/2016 11:05 AM, Martin Sebor wrote:
> > > +permerror (input_location, "ISO C++11 only allows pointer "
> > > +   "conversions for integer literals");
> > 
> > FWIW, I think it would be clearer to either mention the currently
> > selected language version or leave it out completely rather than
> > hardcoding C++11.  When the user specifies -std=c++14 (or later),
> > or when that's the current version used by the compiler, a warning
> > that tells them what C++ 11 allows isn't really relevant (or
> > meaningful), and becomes less so as time goes on.
> 
> Btw., I realize there are other instances where the C++ version
> has been hardcoded and so I should have made it clear that I meant
> my comment as a general suggestion, not as an objection to the patch.
> Sorry if that wasn't apparent.
> 
> I've quickly surveyed some of the existing messages that mention
> a C++ version and found instances where it applies only to the
> referenced version of the standard and prior but not later versions. For
> example:
> 
>   msgid "in C++98 %q+D may not be static because it is a member of a union"
>   msgid "in C++03 a class-key must be used when declaring a friend"
> 
> But I also came across another form that may resolve the concern
> I raised: mentioning the version along with whether it's the first
> or last that supports (or doesn't support) the construct, such as
> "C++11 and above."  Here's one example of it:
> 
>   msgid "in C++11 and above a default constructor can be explicit"
> 
> It might be worth to come up with a convention to adopt in new
> messages and (gradually) change what's already there to use it.

Maybe, no strong opinions, I'll just go with whatever people prefer here.
Though I guess I like those explicit versions because you know when a
particular thing changed.  And when you're using -std=c++14 and the
compiler says C++11, I think that's ok, because C++14 implies C++11.

Marek

Re: C/C++ PATCH to implement -Wpointer-compare warning (PR c++/64767)

[Martin Sebor]

On 09/30/2016 11:05 AM, Martin Sebor wrote:

+permerror (input_location, "ISO C++11 only allows pointer "
+   "conversions for integer literals");


FWIW, I think it would be clearer to either mention the currently
selected language version or leave it out completely rather than
hardcoding C++11.  When the user specifies -std=c++14 (or later),
or when that's the current version used by the compiler, a warning
that tells them what C++ 11 allows isn't really relevant (or
meaningful), and becomes less so as time goes on.


Btw., I realize there are other instances where the C++ version
has been hardcoded and so I should have made it clear that I meant
my comment as a general suggestion, not as an objection to the patch.
Sorry if that wasn't apparent.

I've quickly surveyed some of the existing messages that mention
a C++ version and found instances where it applies only to the
referenced version of the standard and prior but not later versions. 
For example:


  msgid "in C++98 %q+D may not be static because it is a member of a union"
  msgid "in C++03 a class-key must be used when declaring a friend"

But I also came across another form that may resolve the concern
I raised: mentioning the version along with whether it's the first
or last that supports (or doesn't support) the construct, such as
"C++11 and above."  Here's one example of it:

  msgid "in C++11 and above a default constructor can be explicit"

It might be worth to come up with a convention to adopt in new
messages and (gradually) change what's already there to use it.

Martin

Re: [BUILDROBOT] dwarf2out_do_cfi_startproc(bool)’: may write a terminating nul past the end of the destination

[Jakub Jelinek]

On Fri, Sep 30, 2016 at 07:07:22PM +0200, Jan-Benedict Glaw wrote:
> When building for --target=sparc-leon-elf (using config-list.mk) with
> a current GCC, I get this error message (cf.
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=632317):
> 
> g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall 
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. 
> -I/home/jbglaw/repos-configlist_mk/gcc/gcc 
> -I/home/jbglaw/repos-configlist_mk/gcc/gcc/. 
> -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../include 
> -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libcpp/include 
> -I/opt/cfarm/mpc/include  
> -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber 
> -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber/dpd 
> -I../libdecnumber -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libbacktrace  
>  -o dwarf2out.o -MT dwarf2out.o -MMD -MP -MF ./.deps/dwarf2out.TPo 
> /home/jbglaw/repos-configlist_mk/gcc/gcc/dwarf2out.c
> /home/jbglaw/repos-configlist_mk/gcc/gcc/dwarf2out.c: In function ‘void 
> dwarf2out_do_cfi_startproc(bool)’:
> /home/jbglaw/repos-configlist_mk/gcc/gcc/dwarf2out.c:942:1: error: may write 
> a terminating nul past the end of the destination [-Werror=format-length=]
>  dwarf2out_do_cfi_startproc (bool second)
>  ^~
> /home/jbglaw/repos-configlist_mk/gcc/gcc/dwarf2out.c:973:36: note: format 
> output between 10 and 21 bytes into a destination of size 20
> current_function_funcdef_no);
> ^
> cc1plus: all warnings being treated as errors
> Makefile:1102: recipe for target 'dwarf2out.o' failed
> 
> I haven't really tracked down since when that error/warning shows up
> and whether or not it's valid, but maybe you might want to have a look?

I think sparc-leon-elf uses "*.L%s%ld" format, so for string of length 6
and int cast to long int it needs theoretically up to 21 bytes (3 + 6 + 11 + 1)
byt that would only trigger if the counters overflow from INT_MAX to
INT_MIN (so wouldn't be valid assembly anyway).

That said, most of spots in dwarf2out.c use the MAX_ARTIFICIAL_LABEL_BYTES
macro for sizing such buffers, so instead of changing the [20] to [21] if
the prefix can be 6 bytes I think it is cleaner to switch to using that
macro everywhere.

Ok if it passes bootstrap/regtest?

2016-09-30  Jakub Jelinek  

* dwarf2out.c (output_fde, output_call_frame_info,
dwarf2out_do_cfi_startproc, set_indirect_string,
gen_internal_sym, output_die, output_line_info): Use
MAX_ARTIFICIAL_LABEL_BYTES as char array sizes for
ASM_GENERATE_INTERNAL_LABEL output.

--- gcc/dwarf2out.c.jj  2016-09-29 22:53:14.0 +0200
+++ gcc/dwarf2out.c 2016-09-30 20:41:00.839532467 +0200
@@ -567,7 +567,7 @@ output_fde (dw_fde_ref fde, bool for_eh,
 {
   const char *begin, *end;
   static unsigned int j;
-  char l1[20], l2[20];
+  char l1[MAX_ARTIFICIAL_LABEL_BYTES], l2[MAX_ARTIFICIAL_LABEL_BYTES];
 
   targetm.asm_out.emit_unwind_label (asm_out_file, fde->decl, for_eh,
 /* empty */ 0);
@@ -722,7 +722,8 @@ output_call_frame_info (int for_eh)
   unsigned int i;
   dw_fde_ref fde;
   dw_cfi_ref cfi;
-  char l1[20], l2[20], section_start_label[20];
+  char l1[MAX_ARTIFICIAL_LABEL_BYTES], l2[MAX_ARTIFICIAL_LABEL_BYTES];
+  char section_start_label[MAX_ARTIFICIAL_LABEL_BYTES];
   bool any_lsda_needed = false;
   char augmentation[6];
   int augmentation_size;
@@ -966,7 +967,7 @@ dwarf2out_do_cfi_startproc (bool second)
 
   if (crtl->uses_eh_lsda)
 {
-  char lab[20];
+  char lab[MAX_ARTIFICIAL_LABEL_BYTES];
 
   enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/0, /*global=*/0);
   ASM_GENERATE_INTERNAL_LABEL (lab, second ? "LLSDAC" : "LLSDA",
@@ -4128,7 +4129,7 @@ AT_string (dw_attr_node *a)
 static void
 set_indirect_string (struct indirect_string_node *node)
 {
-  char label[32];
+  char label[MAX_ARTIFICIAL_LABEL_BYTES];
   /* Already indirect is a no op.  */
   if (node->form == DW_FORM_strp || node->form == DW_FORM_GNU_str_index)
 {
@@ -7076,7 +7077,7 @@ is_template_instantiation (dw_die_ref di
 static char *
 gen_internal_sym (const char *prefix)
 {
-  char buf[256];
+  char buf[MAX_ARTIFICIAL_LABEL_BYTES];
 
   ASM_GENERATE_INTERNAL_LABEL (buf, prefix, label_num++);
   return xstrdup (buf);
@@ -9382,7 +9383,7 @@ output_die (dw_die_ref die)
 
case dw_val_class_fde_ref:
  {
-   char l1[20];
+   char l1[MAX_ARTIFICIAL_LABEL_BYTES];
 
ASM_GENERATE_INTERNAL_LABEL (l1, FDE_LABEL,
 a->dw_attr_val.v.val_fde_index * 2);
@@ -10710,7 +10711,8 @@ output_one_line_info_table (dw_line_info
 static void
 output_line_info 

[PATCH] Fix bootstrap with --enable-languages=all,go

[Jakub Jelinek]

Hi!

On Fri, Sep 30, 2016 at 01:48:12PM +0100, Andrew Haley wrote:
> On 30/09/16 11:27, Marek Polacek wrote:
> > Can we move forward with this patch, then?
> 
> I've been travelling for several weeks.  However, I'm back at my desk
> now, so I can move this forward.  I have all the approvals and
> everybody has had time to respond.  However, I'll need to pull some
> more recent changes into my tree and merge again.

Unfortunately this broke bootstrap, because libgo needs libffi (at least on
lots of targets) and target libffi is no longer built.

This patch restores what we had before for target-libffi, it can be
incrementally tweaked by individual target maintainers.

I haven't tried to readd the boehm-gc objc support that has also been
disabled, don't know about anybody using that.

Bootstrapped on i686-linux, bootstrap pending on x86_64-linux (both fail to
bootstrap without it), ok for trunk?

2016-09-30  Jakub Jelinek  

* configure.ac: Add target-libffi to target_libraries.
Readd libgcj target disablings, modified to only target-libffi.
Readd target addition of go to unsupported languages.
* configure: Regenerated.

--- configure.ac.jj 2016-09-30 18:40:58.0 +0200
+++ configure.ac2016-09-30 20:10:19.461760861 +0200
@@ -161,6 +161,7 @@ target_libraries="target-libgcc \
target-libssp \
target-libquadmath \
target-libgfortran \
+   target-libffi \
target-libobjc \
target-libada \
target-libgo"
@@ -696,6 +697,101 @@ case "${target}" in
 ;;
 esac
 
+# Disable libffi for some systems.
+case "${target}" in
+  powerpc-*-darwin*)
+;;
+  i[[3456789]]86-*-darwin*)
+;;
+  x86_64-*-darwin[[912]]*)
+;;
+  *-*-darwin*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  *-*-netware*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  *-*-phoenix*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  *-*-rtems*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  *-*-tpf*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  *-*-uclinux*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  *-*-vxworks*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  alpha*-*-*vms*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  arm*-*-freebsd*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  arm-wince-pe)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  arm*-*-symbianelf*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  cris-*-* | crisv32-*-*)
+case "${target}" in
+  *-*-linux*)
+   ;;
+  *) # See PR46792 regarding target-libffi.
+   noconfigdirs="$noconfigdirs target-libffi";;
+esac
+;;
+  hppa*64*-*-hpux*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  hppa*-hp-hpux11*)
+;;
+  hppa*-*-hpux*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  ia64*-*-*vms*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  i[[3456789]]86-w64-mingw*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  i[[3456789]]86-*-mingw*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  x86_64-*-mingw*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  mmix-*-*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  powerpc-*-aix*)
+# copied from rs6000-*-* entry
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  rs6000-*-aix*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  ft32-*-*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  *-*-lynxos*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+esac
+
+# Disable the go frontend on systems where it is known to not work. Please keep
+# this in sync with contrib/config-list.mk.
+case "${target}" in
+*-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*)
+unsupported_languages="$unsupported_languages go"
+;;
+esac
+
 # Disable libgo for some systems where it is known to not work.
 # For testing, you can easily override this with --enable-libgo.
 if test x$enable_libgo = x; then
--- configure.jj2016-09-30 18:40:58.0 +0200
+++ configure   2016-09-30 20:11:16.063041690 +0200
@@ -2748,6 +2748,7 @@ target_libraries="target-libgcc \
target-libssp \
target-libquadmath \
target-libgfortran \
+   target-libffi \
target-libobjc \
target-libada \
target-libgo"
@@ -3351,6 +3352,101 @@ case "${target}" in
 ;;
 esac
 
+# Disable libffi for some systems.
+case "${target}" in
+  powerpc-*-darwin*)
+;;
+  i[3456789]86-*-darwin*)
+;;
+  x86_64-*-darwin[912]*)
+;;
+  *-*-darwin*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  *-*-netware*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  *-*-phoenix*)
+noconfigdirs="$noconfigdirs target-libffi"
+;;
+  

[PATCH] Update email address

[Ellcey, Steve]

This patch updates my email address from sell...@imgtec.com to 
sell...@caviumnetworks.com

Steve Ellcey
sell...@caviumnetworks.com



2016-09-30  Steve Ellcey  

* MAINTAINERS: Update email address.


Index: MAINTAINERS
===
--- MAINTAINERS (revision 240658)
+++ MAINTAINERS (working copy)
@@ -66,7 +66,7 @@
 i386 port  Uros Bizjak 
 i386 vector ISA extns  Kirill Yukhin   
 ia64 port  Jim Wilson  
-ia64 port  Steve Ellcey
+ia64 port  Steve Ellcey
 iq2000 portNick Clifton
 lm32 port  Sebastien Bourdeauducq  
 m32c port  DJ Delorie  
@@ -130,7 +130,7 @@
 freebsdAndreas Tobler  
 GNU/Hurd   Thomas Schwinge 
 hpux   John David Anglin   
-hpux   Steve Ellcey
+hpux   Steve Ellcey
 solarisRainer Orth 

 netbsd Jason Thorpe
 netbsd Krister Walfridsson 

[gomp4] simplify parition allocation logic

[Nathan Sidwell]

The code I wrote to determine partitions on auto loops was too complicated, 
making it hard for me to figure out the changes needed for tiling.  I've 
committed this patch, which doesn't do such egregious bit twiddling.


nathan
2016-09-30  Nathan Sidwell  

	* omp-low.c (oacc_loop_auto_partition): Simplify logic.

Index: omp-low.c
===
--- omp-low.c	(revision 240664)
+++ omp-low.c	(working copy)
@@ -19867,15 +19867,19 @@ oacc_loop_auto_partitions (oacc_loop *lo
 {
   /* Allocate outermost and non-innermost loops at the outermost
 	 non-innermost available level.  */
-  unsigned this_mask = outer_mask + 1;
+  unsigned this_mask = GOMP_DIM_MASK (GOMP_DIM_GANG);
+  
+  /* Find the first outermost available partition. */
+  while (this_mask <= outer_mask)
+	this_mask <<= 1;
+
+  /* Prohibit the innermost partitioning at the moment.  */
+  this_mask &= GOMP_DIM_MASK (GOMP_DIM_MAX - 1) - 1;
 
-  /* Make sure it's the single outermost available partition.  */
-  while (this_mask != (this_mask & -this_mask))
-	this_mask += this_mask & -this_mask;
-
-  if (!(this_mask & (loop->inner | GOMP_DIM_MASK (GOMP_DIM_MAX)
-			 | GOMP_DIM_MASK (GOMP_DIM_MAX - 1
-	loop->mask = this_mask;
+  /* Don't use any dimension explicitly claimed by an inner loop. */
+  this_mask &= ~loop->inner;
+
+  loop->mask = this_mask;
 }
 
   if (loop->child)
@@ -19897,15 +19901,13 @@ oacc_loop_auto_partitions (oacc_loop *lo
 
   /* Pick the partitioning just inside that one.  */
   this_mask >>= 1;
-
   /* And avoid picking one use by an outer loop. */
   this_mask &= ~outer_mask;
 
-  if (!this_mask && !loop->mask && noisy)
+  loop->mask |= this_mask;
+  if (!loop->mask && noisy)
 	warning_at (loop->loc, 0,
 		"insufficient partitioning available to parallelize loop");
-
-  loop->mask |= this_mask;
 }
 
   if (assign && dump_file)

Re: [PATCH] libstdc++/77795 Only declare ::gets for C++98 and C++11

[Jonathan Wakely]

On 30/09/16 12:08 +0100, Jonathan Wakely wrote:

As noted in Bugzilla (and pointed out in LLVM's bugzilla by Richard
Smith) we check for a ::gets() declaration with the default
-std=gnu++14 mode, so for glibc we don't find it, and then we declare
it ourselves in  even though it's not meant to exist in C++14.

This adjusts the check to use C++11, and doesn't declare it for C++14
and later. I think this fixes the regression, without introducing any
new problems.

Please take a look and double-check I haven't missed something.

PR libstdc++/77795
* acinclude.m4 (GLIBCXX_CHECK_STDIO_PROTO): Use -std=gnu++11 to check
for gets.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/c_global/cstdio [!_GLIBCXX_HAVE_GETS] (gets): Only declare
for C++98 and C++11.
* include/c_std/cstdio [!_GLIBCXX_HAVE_GETS] (gets): Likewise.
* testsuite/27_io/headers/cstdio/functions_neg.cc: New test.



Committed to trunk and gcc-6-branch.


I think we could also get rid of the hack in
config/os/gnu-linux/os_defines.h because it doesn't do anything:

// Provide a declaration for the possibly deprecated gets function, as
// glibc 2.15 and later does not declare gets for ISO C11 when
// __GNU_SOURCE is defined.
#if __GLIBC_PREREQ(2,15) && defined(_GNU_SOURCE)
# undef _GLIBCXX_HAVE_GETS
#endif


Any reason to keep this part?

Re: [PATCH] Fix PR tree-optimization/77654

[Christophe Lyon]

On 30 September 2016 at 20:10, Doug Gilmore  wrote:
>> From: Christophe Lyon [christophe.l...@linaro.org]
>> Sent: Thursday, September 29, 2016 12:17 PM
>> To: Matthew Fortune
>> Cc: Doug Gilmore; Richard Biener; gcc-patches@gcc.gnu.org; 
>> rgue...@gcc.gnu.org
>> Subject: Re: [PATCH] Fix PR tree-optimization/77654
>>
>> On 23 September 2016 at 17:55, Matthew Fortune
>>  wrote:
>> > Doug Gilmore  writes:
>> >> > From: Richard Biener [rguent...@suse.de]
>> >> > Sent: Thursday, September 22, 2016 12:43 AM
>> >> > To: Doug Gilmore
>> >> > Cc: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org
>> >> > Subject: RE: [PATCH] Fix PR tree-optimization/77654
>> >> >
>> >> > On Wed, 21 Sep 2016, Doug Gilmore wrote:
>> >> >
>> >> > ...
>> >> > > Sorry I that missed point.  I glossed your comment "addr_base should
>> >> > > always be a pointer", causing me to go off into the weeds.
>> >> > >
>> >> > > New patch attached.
>> >> >
>> >> > Ok if successfully bootstrapped / tested.
>> >> >
>> >> > Thanks,
>> >> > Richard.
>> >> The change bootstrapped on X86_64 and the several "make check" errors
>> >> also appeared in latest archived mail message to gcc-testresults.
>> >
>> > Committed as r240439.
>> >
>>
>> Since this commit, I've noticed ICE on arm target:
>> FAIL: gcc.dg/params/blocksort-part.c -O3 --param prefetch-latency=0
>> (internal compiler error)
>> FAIL: gcc.dg/params/blocksort-part.c -O3 --param prefetch-latency=0
>> (test for excess errors)
>> Excess errors:
>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dREMOTE_SNAPSHOTS=g/params/blocksort-part.c:116:6:
>> internal compiler error: in duplicate
>> _ssa_name_ptr_info, at tree-ssanames.c:630
>> ...
> Hi Christophe,
>
> I filed PR77808, will send out a fix shortly.
>
Thanks

> BTW, I missed this in regression testing since -fprefetch-loop-arrays
> is needed to expose the problem.  Are you setting this as the default
> in your compiler build?
>
No, I did not do anything special.
I'm not sure to understand: this option is not in the command line
of the offending test.

Christophe

> Thanks,
>
> Doug

RE: [PATCH] Fix PR tree-optimization/77654

[Doug Gilmore]

> From: Christophe Lyon [christophe.l...@linaro.org]
> Sent: Thursday, September 29, 2016 12:17 PM
> To: Matthew Fortune
> Cc: Doug Gilmore; Richard Biener; gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org
> Subject: Re: [PATCH] Fix PR tree-optimization/77654
> 
> On 23 September 2016 at 17:55, Matthew Fortune
>  wrote:
> > Doug Gilmore  writes:
> >> > From: Richard Biener [rguent...@suse.de]
> >> > Sent: Thursday, September 22, 2016 12:43 AM
> >> > To: Doug Gilmore
> >> > Cc: gcc-patches@gcc.gnu.org; rgue...@gcc.gnu.org
> >> > Subject: RE: [PATCH] Fix PR tree-optimization/77654
> >> >
> >> > On Wed, 21 Sep 2016, Doug Gilmore wrote:
> >> >
> >> > ...
> >> > > Sorry I that missed point.  I glossed your comment "addr_base should
> >> > > always be a pointer", causing me to go off into the weeds.
> >> > >
> >> > > New patch attached.
> >> >
> >> > Ok if successfully bootstrapped / tested.
> >> >
> >> > Thanks,
> >> > Richard.
> >> The change bootstrapped on X86_64 and the several "make check" errors
> >> also appeared in latest archived mail message to gcc-testresults.
> >
> > Committed as r240439.
> >
> 
> Since this commit, I've noticed ICE on arm target:
> FAIL: gcc.dg/params/blocksort-part.c -O3 --param prefetch-latency=0
> (internal compiler error)
> FAIL: gcc.dg/params/blocksort-part.c -O3 --param prefetch-latency=0
> (test for excess errors)
> Excess errors:
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/params/blocksort-part.c:116:6:
> internal compiler error: in duplicate
> _ssa_name_ptr_info, at tree-ssanames.c:630
> ...
Hi Christophe,

I filed PR77808, will send out a fix shortly.

BTW, I missed this in regression testing since -fprefetch-loop-arrays
is needed to expose the problem.  Are you setting this as the default
in your compiler build?

Thanks,

Doug

Re: [Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[Joseph Myers]

On Fri, 30 Sep 2016, Jeff Law wrote:

> On 09/30/2016 11:34 AM, Joseph Myers wrote:
> > On Fri, 30 Sep 2016, James Greenhalgh wrote:
> > 
> > > +  case EXCESS_PRECISION_TYPE_STANDARD:
> > > +  case EXCESS_PRECISION_TYPE_IMPLICIT:
> > > + /* Otherwise, the excess precision we want when we are
> > > +in a standards compliant mode, and the implicit precision we
> > > +provide can be identical.  */
> > > + return FLT_EVAL_METHOD_PROMOTE_TO_DOUBLE;
> > 
> > That's wrong for EXCESS_PRECISION_TYPE_IMPLICIT.  There is no implicit
> > promotion in the back end (and really there shouldn't be any excess
> > precision here at all, and double_t in glibc should be fixed along with a
> > GCC change to remove this mistake).
> Sorry, change to a NAK.
> 
> Joseph, what's the right thing to do here?

(a) The present patch would keep the existing value of FLT_EVAL_METHOD.  
But the existing value is inaccurate for the default compilation mode, 
when there is no implicit promotion in the back end, and doing so means 
suboptimal code in libgcc and glibc because it does things to handle 
excess precision that isn't actually there (and quite possibly in code 
elsewhere that looks at FLT_EVAL_METHOD).

(b) Handling EXCESS_PRECISION_TYPE_IMPLICIT like 
EXCESS_PRECISION_TYPE_FAST would accurately describe what the back end 
does.  It would mean that the default FLT_EVAL_METHOD is 0, which is a 
more accurate description of how the compiler actually behaves, and would 
avoid the suboptimal code in libgcc and glibc.  It would however mean that 
unless -fexcess-precision=standard is used, FLT_EVAL_METHOD (accurate) is 
out of synx with float_t in math.h (inaccurate).

(c) Removing all special excess precision for S/390 from GCC, and changing 
float_t to float in glibc, is logically correct and produces optimal code.  
float_t does not appear in the ABI of any glibc function; in principle it 
could affect the ABIs of other libraries, but I don't think that's 
particularly likely.

The only argument for (a) is that's it's semantics-preserving - it's just 
that the preserved semantics are nonsensical and involve an inaccurate 
value of FLT_EVAL_METHOD in the default compilation mode.

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

[PATCH 2/3] Temporary remove "at least 8 byte alignment" code from x86

[Denys Vlasenko]

This change drops forced alignment to 8 if requested alignment is higher
than 8: before the patch, -falign-functions=9 was generating

.p2align 4,,8
.p2align 3

which means: "align to 16 if the skip is 8 bytes or less; else align to 8".
After this change, ".p2align 3" is not emitted.

This behavior will be implemented differently by the next patch.

The new SUBALIGN_LOG define will be used by the next patch.

While we are here, avoid generating ".p2align N,,2^N-1" -
it is functionally equivalent to ".p2align N". In this case, use the latter.

2016-09-27  Denys Vlasenko  

* config/i386/dragonfly.h: (ASM_OUTPUT_MAX_SKIP_ALIGN):
Use a simpler align directive also if MAXSKIP = ALIGN-1.
* config/i386/gas.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/lynx.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/netbsd-elf.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/i386.h (ASM_OUTPUT_MAX_SKIP_PAD): Likewise.
* config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N
is large, do at least 8 byte alignment" code. Add SUBALIGN_LOG
define. Use a simpler align directive also if MAXSKIP = ALIGN-1.
* config/i386/gnu-user.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/iamcu.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/openbsdelf.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/x86-64.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.

Index: gcc/config/i386/dragonfly.h
===
--- gcc/config/i386/dragonfly.h (revision 239860)
+++ gcc/config/i386/dragonfly.h (working copy)
@@ -69,10 +69,12 @@ see the files COPYING3 and COPYING.RUNTIME respect
 
 #ifdef HAVE_GAS_MAX_SKIP_P2ALIGN
 #undef  ASM_OUTPUT_MAX_SKIP_ALIGN
-#define ASM_OUTPUT_MAX_SKIP_ALIGN(FILE, LOG, MAX_SKIP) 
\
-  if ((LOG) != 0) {
\
-if ((MAX_SKIP) == 0) fprintf ((FILE), "\t.p2align %d\n", (LOG));   \
-else fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP));   \
+#define ASM_OUTPUT_MAX_SKIP_ALIGN(FILE, LOG, MAX_SKIP) \
+  if ((LOG) != 0) {\
+if ((MAX_SKIP) == 0 || (MAX_SKIP) >= (1<<(LOG))-1) \
+  fprintf ((FILE), "\t.p2align %d\n", (LOG));  \
+else   \
+  fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP));  \
   }
 #endif
 
Index: gcc/config/i386/freebsd.h
===
--- gcc/config/i386/freebsd.h   (revision 239860)
+++ gcc/config/i386/freebsd.h   (working copy)
@@ -92,9 +92,9 @@ along with GCC; see the file COPYING3.  If not see
 
 /* A C statement to output to the stdio stream FILE an assembler
command to advance the location counter to a multiple of 1<= (1<<(LOG))-1)   \
+   fprintf ((FILE), "\t.p2align %d\n", (LOG)); \
+  else \
fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP)); \
-   /* Make sure that we have at least 8 byte alignment if > 8 byte \
-  alignment is preferred.  */  \
-   if ((LOG) > 3   \
-   && (1 << (LOG)) > ((MAX_SKIP) + 1)  \
-   && (MAX_SKIP) >= 7) \
- fputs ("\t.p2align 3\n", (FILE)); \
-  }
\
 }  \
   } while (0)
 #endif
Index: gcc/config/i386/gas.h
===
--- gcc/config/i386/gas.h   (revision 239860)
+++ gcc/config/i386/gas.h   (working copy)
@@ -72,10 +72,12 @@ along with GCC; see the file COPYING3.  If not see
 
 #ifdef HAVE_GAS_MAX_SKIP_P2ALIGN
 #  define ASM_OUTPUT_MAX_SKIP_ALIGN(FILE,LOG,MAX_SKIP) \
- if ((LOG) != 0) {\
-   if ((MAX_SKIP) == 0) fprintf ((FILE), "\t.p2align %d\n", (LOG)); \
-   else fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP)); \
- }
+if ((LOG) != 0) { \
+  if ((MAX_SKIP) == 0 || (MAX_SKIP) >= (1<<(LOG))-1)   \
+   fprintf ((FILE), "\t.p2align %d\n", (LOG)); \
+  else \
+   fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP)); \
+}
 #endif
 
 /* A C statement or statements which output an assembler instruction
Index: gcc/config/i386/gnu-user.h
===
--- 

[PATCH 3/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

[Denys Vlasenko]

falign-functions=N is too simplistic.

Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte 
alignment
of functions runs fastest (he tried many other possibilites):
this way, after a call CPU can fetch a lot of insns in the first cacheline fill.

However, developers are less than thrilled by the idea of a slam-dunk 64-byte
aligning everything. Too much waste:
On 05/20/2015 02:47 AM, Linus Torvalds wrote:
> At the same time, I have to admit that I abhor a 64-byte function
> alignment, when we have a fair number of functions that are (much)
> smaller than that.
>
> Is there some way to get gcc to take the size of the function into
> account? Because aligning a 16-byte or 32-byte function on a 64-byte
> alignment is just criminally nasty and wasteful.

This change makes it possible to align functions to 64-byte boundaries *if*
this does not introduce huge amount of padding.

Example syntax is -falign-functions=64,9: "align to 64 by skipping up to
9 bytes (not inclusive)". IOW: "after a call insn, CPU will always be able
to fetch at least 9 bytes of insns".

x86 had a tweak: -falign-functions=N with N > 8 was adding secondary alignment.
For example, falign-functions=10 was emitting this before every function:
.p2align 4,,9
.p2align 3
This tweak was removed by the previous patch. Now it is reinstated
by the logic that if falign-functions=N[,M] is specified and N > 8,
then default value of N2 is 8, not 1. Now this can be suppressed by
falign-functions=N,M,1 - which wasn't possible before.
In general, optional N2,M2 pair can be used to generate any secondary
alignment user wants.

Subalignment for loops/jumps/labels are trickier to fully implement.
The implementation in this patch uses falign-labels subalignment values
for any of these three types of labels - but only if "main" alignment
triggers. With -O2 defaults, this provides a matching behavior on x86:
loops and jumps are aligned (to 16-32 bytes depending on selected CPU)
and subaligned to 8 bytes. Labels are not aligned.

Testing:

Tested that with -falign-functions=N (tried 8, 15, 16, 17...) the alignment
directives are the same before and after the patch.
Tested that -falign-functions=N,N (two equal parameters) works exactly
like -falign-functions=N.

No change from past behavior:
Tested that "-falign-functions" uses an arch-dependent alignment.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.

2016-09-27  Denys Vlasenko  

* doc/invoke.texi: Update option documentation.
* common.opt (-falign-functions=): Accept a string instead of integer.
(-falign-jumps=): Likewise.
(-falign-labels=): Likewise.
(-falign-loops=): Likewise.
* flags.h (struct target_flag_state): Revamp how alignment data is stored:
for each of four alignment types, store two pairs of log/maxskip values.
* toplev.c (read_uint): New function.
(read_log_maxskip): New function.
(parse_N_M): New function.
(init_alignments): Set align_FOO[0/1].log/maxskip from
specified falign-FOO=N[,M[,N[,M]]] options.
* varasm.c (assemble_start_function): Call two ASM_OUTPUT_MAX_SKIP_ALIGN
macros, first for N,M and second time for N2,M2 from
falign-functions=N,M,N2,M2. This generates 0, 1, or 2 align directives.
* final.c (final_scan_insn): If a label, jump or loop target
is being aligned, emit a secondary alignment directive.
* config/i386/i386.c (struct ptt): Change foo_align members from
integers to strings. Add align_label member. Set it to "0,0,8"
on the processors which have maxskips > 7 for loops and jumps -
this preserves existing behaviout of adding 8-byte subalign.
* config/i386/i386.c (processor_target_table): Likewise.
* config/aarch64/aarch64-protos.h (struct tune_params):
Change foo_align members from integers to strings.
* config/aarch64/aarch64.c (_tunings):
Change foo_align field values from integers to strings.
* config/arm/arm.c (arm_override_options_after_change_1):
Fix if() condition to detect that -falign-functions is specified.
* config/i386/i386.c (ix86_default_align): Likewise.
* testsuite/gcc.target/i386/falign-functions.c: New file.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 239860)
+++ gcc/doc/invoke.texi (working copy)
@@ -337,9 +337,11 @@ Objective-C and Objective-C++ Dialects}.
 
 @item Optimization Options
 @xref{Optimize Options,,Options that Control Optimization}.
-@gccoptlist{-faggressive-loop-optimizations -falign-functions[=@var{n}] @gol
--falign-jumps[=@var{n}] @gol
--falign-labels[=@var{n}] -falign-loops[=@var{n}] @gol
+@gccoptlist{-faggressive-loop-optimizations @gol
+-falign-functions[=@var{n}[,@var{m},[@var{n2}[,@var{m2} @gol

[PATCH 0/3] Extend -falign-FOO=N to N[,M[,N2[,M2]]] version 4

[Denys Vlasenko]

These patches are for this bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"

The test program:

int g();
int f(int i) {
i *= 3;
while (--i > 100) {
 L1:if (g()) goto L1;
if (g()) goto L2;
}
return i;
 L2:return 123;
}

"-O2" assembly before the patch:After the patch:
.text   .text
.p2align 4,,15  .p2align 4
.globl  f   .globl  f
.type   f, @function.type   f, @function
f:  f:
.LFB0:  .LFB0:
pushq   %rbxpushq   %rbx
leal(%rdi,%rdi,2), %ebx leal(%rdi,%rdi,2), %ebx
.p2align 4,,10  .p2align 4,,10
.p2align 3  .p2align 3
.L2:.L2:
subl$1, %ebxsubl$1, %ebx
cmpl$100, %ebx  cmpl$100, %ebx
jle .L1 jle .L1
.p2align 4,,10  .p2align 4,,10
.p2align 3  .p2align 3
.L3:.L3:
xorl%eax, %eax  xorl%eax, %eax
callg   callg
testl   %eax, %eax  testl   %eax, %eax
jne .L3 jne .L3
callg   callg
testl   %eax, %eax  testl   %eax, %eax
je  .L2 je  .L2
movl$123, %ebx  movl$123, %ebx
.L4:.L4:
.L1:.L1:
movl%ebx, %eax  movl%ebx, %eax
popq%rbxpopq%rbx
ret ret

This is version 5 of the patch set.

Bernd asked to replace use of a new SUBALIGN_LOG define with a hook.
Don't see an easy way to do that (short of adding a dedicated hook),
for now retained SUBALIGN_LOG method. Suggestions welcome.

Changes since version 4:

* Deleted rather than NOPed -malign-foo=N support.
* Improved behavior match with x86 8-byte subalignment for labels.

Changes since version 3:

* Improved documentation in invoke.texi
* Fixed x86-specific calculation of default N2 value:
  previous version was doing it incorrectly for cross-compile

[PATCH 1/3] Remove support for obsolete x86 -malign-foo options

[Denys Vlasenko]

2016-09-27  Denys Vlasenko  

* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config/i386/i386.opt: Likewise.

Index: gcc/common/config/i386/i386-common.c
===
--- gcc/common/config/i386/i386-common.c(revision 240663)
+++ gcc/common/config/i386/i386-common.c(working copy)
@@ -998,38 +998,6 @@ ix86_handle_option (struct gcc_options *opts,
}
   return true;
 
-
-  /* Comes from final.c -- no real reason to change it.  */
-#define MAX_CODE_ALIGN 16
-
-case OPT_malign_loops_:
-  warning_at (loc, 0, "-malign-loops is obsolete, use -falign-loops");
-  if (value > MAX_CODE_ALIGN)
-   error_at (loc, "-malign-loops=%d is not between 0 and %d",
- value, MAX_CODE_ALIGN);
-  else
-   opts->x_align_loops = 1 << value;
-  return true;
-
-case OPT_malign_jumps_:
-  warning_at (loc, 0, "-malign-jumps is obsolete, use -falign-jumps");
-  if (value > MAX_CODE_ALIGN)
-   error_at (loc, "-malign-jumps=%d is not between 0 and %d",
- value, MAX_CODE_ALIGN);
-  else
-   opts->x_align_jumps = 1 << value;
-  return true;
-
-case OPT_malign_functions_:
-  warning_at (loc, 0,
- "-malign-functions is obsolete, use -falign-functions");
-  if (value > MAX_CODE_ALIGN)
-   error_at (loc, "-malign-functions=%d is not between 0 and %d",
- value, MAX_CODE_ALIGN);
-  else
-   opts->x_align_functions = 1 << value;
-  return true;
-
 case OPT_mbranch_cost_:
   if (value > 5)
{
Index: gcc/config/i386/i386.opt
===
--- gcc/config/i386/i386.opt(revision 240663)
+++ gcc/config/i386/i386.opt(working copy)
@@ -205,18 +205,6 @@ malign-double
 Target Report Mask(ALIGN_DOUBLE) Save
 Align some doubles on dword boundary.
 
-malign-functions=
-Target RejectNegative Joined UInteger
-Function starts are aligned to this power of 2.
-
-malign-jumps=
-Target RejectNegative Joined UInteger
-Jump targets are aligned to this power of 2.
-
-malign-loops=
-Target RejectNegative Joined UInteger
-Loop code aligned to this power of 2.
-
 malign-stringops
 Target RejectNegative Report InverseMask(NO_ALIGN_STRINGOPS, ALIGN_STRINGOPS) 
Save
 Align destination of the string operations.

Re: [Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[Jeff Law]

On 09/30/2016 11:34 AM, Joseph Myers wrote:

On Fri, 30 Sep 2016, James Greenhalgh wrote:


+  case EXCESS_PRECISION_TYPE_STANDARD:
+  case EXCESS_PRECISION_TYPE_IMPLICIT:
+   /* Otherwise, the excess precision we want when we are
+  in a standards compliant mode, and the implicit precision we
+  provide can be identical.  */
+   return FLT_EVAL_METHOD_PROMOTE_TO_DOUBLE;


That's wrong for EXCESS_PRECISION_TYPE_IMPLICIT.  There is no implicit
promotion in the back end (and really there shouldn't be any excess
precision here at all, and double_t in glibc should be fixed along with a
GCC change to remove this mistake).

Sorry, change to a NAK.

Joseph, what's the right thing to do here?

jeff

[C++/66443] deleted ctor and vbase construction

[Nathan Sidwell]

PR 66443 concerns C++14 DR1611. It is now permitted to use the base-ctor of an 
abstract class whos complete ctor is deleted because of a virtual base issue. 
Specifically, given


class A {
  A (int);
  // no default ctor in C++14
};

class B : virtual A {
 virtual void Foo () = 0; // abstract
 // B::B deleted because there's no A::A()
};

class C: B
{
  virtual void Foo (); // not abstract

  C ()
   : A(1) // explicit vbase construction
  {}
};

Here, there's no way that B's complete object constructor can be called -- it's 
an abstract class, so no complete B objects can exist.  B's as-a-base 
constructor never constructs the A base, because its a virtual base.  So the 
missing 'A::A()' is never needed.  C's constructors must explicitly construct 
the A base using the available constructors.


the trickiness is that we create both base and complete constructors by building 
a more generic constructor, cloning it substituting the 'in-charge' parameter 
value and then allowing optimization to remove unreachable code in the two 
instances.  (see below for why not have the complete-ctor tail call the base-ctor.)


This patch adds a new FUNCTION_DECL flag and accessor 'DECL_BASE_FN_UNDELETED'. 
In the example above, this is true for B's generic constructor.  When we 
actually need a B constructor (the bodies are created lazily), we check 
DECL_BASE_FN_UNDELETED to see whether we need to do something 'interesting'.  If 
we do, and its the base-ctor we don't do the usual 'create generic body, clone 
it' scheme.  Instead we create the base body explicitly, passing an new 
'skip-vbases' flag, and thus never try and find 'A::A()' in this case. 
build_if_incharge needs tweaking, because the incharge parm only exists on the 
generic ctor.


bootstrapped on x86_64-linux, ok?


nathan

[*] why not tail-call the as-base ctor after constructing the vbases?  That 
would be fine for most cases, but we might need to provide a vtt pointer 
describing the complete object.  Not sure if such a table exists right now. 
Anyway the more serios issue is varadic ctors.  [without additional compiler 
magic] we can't tailcall from the complete ctor to the base ctor.
2016-09-30  Nathan Sidwell  

	cp/
	PR c++/66443
	* cp-tree.h (lang_decl_fn): Add base_undeleted_p.
	(DECL_BASE_UNDELETED_FN): New.
	(emit_mem_initializer, finish_mem_initializers): Add skip vbases arg.
	* class.c (build_if_incharge): Allow no incharge parm when
	building undeleted base dtor directly.
	* decl2.c (mark_used): Don't complain about using an undeleted
	base ctor.
	* init.c (emit_mem_initializers): Add skip_vbases arg. Skip vbase
	construction if true.
	* method.c (do_build_copy_constructor): Add skip_vbases arg, pass
	it through.
	(synthesize_method): Skip vbases when we have a
	(synthesized_method_walk): Add vbase_deleted_p argument.  Use it.
	(get_defaulted_eh_spec): Adjust synthesized_method_walk.
	(maybe_explain_implicit_delete, explain_implicit_non_constexpr,
	deduce_intheriting_ctor): Likewise.
	(implicitly_declare_fn): Determine DECL_BASE_UNDELETED_FN.
	* parser.c (cp_parser_ctor_initializer,
	cp_parser_mem_initializer_list): Adjust finish_mem_initializer call.
	* pt.c (tsubst_expr): Likewise.
	* semantics.c (finish_mem_initializers): Add skip_vbase parm, pass
	to emit_mem_initializers.

	testsuite.
	PR c++/66443
	* g++.dg/cpp0x/pr66443-cxx11.C: New.
	* g++.dg/cpp1y/pr66443-cxx14.C: New
	* g++.dg/cpp1y/pr66443-cxx14-2.C: New.

Index: cp/class.c
===
--- cp/class.c	(revision 240596)
+++ cp/class.c	(working copy)
@@ -233,15 +233,27 @@ int n_inner_fields_searched = 0;
 tree
 build_if_in_charge (tree true_stmt, tree false_stmt)
 {
-  gcc_assert (DECL_HAS_IN_CHARGE_PARM_P (current_function_decl));
-  tree cmp = build2 (NE_EXPR, boolean_type_node,
-		 current_in_charge_parm, integer_zero_node);
-  tree type = unlowered_expr_type (true_stmt);
-  if (VOID_TYPE_P (type))
-type = unlowered_expr_type (false_stmt);
-  tree cond = build3 (COND_EXPR, type,
-		  cmp, true_stmt, false_stmt);
-  return cond;
+  tree result;
+  
+  if (DECL_HAS_IN_CHARGE_PARM_P (current_function_decl))
+{
+  tree cmp = build2 (NE_EXPR, boolean_type_node,
+			 current_in_charge_parm, integer_zero_node);
+  tree type = unlowered_expr_type (true_stmt);
+  if (VOID_TYPE_P (type))
+	type = unlowered_expr_type (false_stmt);
+  result = build3 (COND_EXPR, type, cmp, true_stmt, false_stmt);
+}
+  else
+{
+  /* We must be building an undeleted base ctor.  */
+  gcc_assert (DECL_BASE_CONSTRUCTOR_P (current_function_decl)
+		  && DECL_DELETED_FN (current_function_decl)
+		  && DECL_BASE_UNDELETED_FN (current_function_decl));
+  result = false_stmt;
+}
+
+  return result;
 }
 
 /* Convert to or from a base subobject.  EXPR is an expression of type
Index: cp/cp-tree.h
===
--- cp/cp-tree.h	(revision 

Re: [Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[Joseph Myers]

On Fri, 30 Sep 2016, James Greenhalgh wrote:

> +  case EXCESS_PRECISION_TYPE_STANDARD:
> +  case EXCESS_PRECISION_TYPE_IMPLICIT:
> + /* Otherwise, the excess precision we want when we are
> +in a standards compliant mode, and the implicit precision we
> +provide can be identical.  */
> + return FLT_EVAL_METHOD_PROMOTE_TO_DOUBLE;

That's wrong for EXCESS_PRECISION_TYPE_IMPLICIT.  There is no implicit 
promotion in the back end (and really there shouldn't be any excess 
precision here at all, and double_t in glibc should be fixed along with a 
GCC change to remove this mistake).

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

Re: [Patch 5/11] Add -fpermitted-flt-eval-methods=[c11|ts-18661-3]

[Jeff Law]

On 09/30/2016 10:56 AM, James Greenhalgh wrote:


Hi,

This option is added to control which values of FLT_EVAL_METHOD the
compiler is allowed to set.

ISO/IEC TS 18661-3 defines new permissible values for
FLT_EVAL_METHOD that indicate that operations and constants with
a semantic type that is an interchange or extended format should be
evaluated to the precision and range of that type.  These new values are
a superset of those permitted under C99/C11, which does not specify the
meaning of other positive values of FLT_EVAL_METHOD.  As such, code
conforming to C11 may not have been written expecting the possibility of
the new values.

-fpermitted-flt-eval-methods specifies whether the compiler
should allow only the values of FLT_EVAL_METHOD specified in C99/C11,
or the extended set of values specified in ISO/IEC TS 18661-3.

The two possible values this option can take are "c11" or "ts-18661-3".

The default when in a standards compliant mode (-std=c11 or similar)
is -fpermitted-flt-eval-methods=c11.  The default when in a GNU
dialect (-std=gnu11 or similar) is -fpermitted-flt-eval-methods=ts-18661-3.

I've added two testcases which test that when this option, or a C standards
dialect, would restrict the range of values to {-1, 0, 1, 2}, those are
the only values we see. At this stage in the patch series this trivially
holds for all targets.

Bootstrapped on x86_64 with no issues and tested in series on AArch64.

OK?

Thanks,
James

---
gcc/c-family/

2016-09-30  James Greenhalgh  

* c-opts.c (c_common_post_options): Add logic to handle the default
case for -fpermitted-flt-eval-methods.

gcc/

2016-09-30  James Greenhalgh  

* common.opt (fpermitted-flt-eval-methods): New.
* doc/invoke.texi (-fpermitted-flt-eval-methods): Document it.
* flag_types.h (permitted_flt_eval_methods): New.

gcc/testsuite/

2016-09-30  James Greenhalgh  

* gcc.dg/fpermitted-flt-eval-methods_1.c: New.
* gcc.dg/fpermitted-flt-eval-methods_2.c: New.
OK.Are you going to need to do something for C++ (or gasp ObjC) in 
the future, or do you expect this to be C only indefinitely?


jeff

Re: [Patch 6/11] Migrate excess precision logic to use TARGET_EXCESS_PRECISION

[Joseph Myers]

On Fri, 30 Sep 2016, James Greenhalgh wrote:

>/* float.h needs to know this.  */
> +  /* We already have the option -fno-fp-int-builtin-inexact to ensure
> + certain built-in functions follow TS 18661-1 semantics.  It might be
> + reasonable to have a new option to enable FLT_EVAL_METHOD using new
> + values.  However, I'd be inclined to think that such an option should
> + be on by default for -std=gnu*, only off for strict conformance modes.
> + (There would be both __FLT_EVAL_METHOD__ and __FLT_EVAL_METHOD_C99__,
> + say, predefined macros, so that  could also always use the
> + new value if __STDC_WANT_IEC_60559_TYPES_EXT__ is defined.)  */

This comment makes no sense in the context.  The comment should not be 
talking about some other option for a different issue, or about 
half-thought-out ideas for how something might be implemented; comments 
need to relate to the actual code (which in this case is obvious and not 
in need of comments beyond saying what the macro semantics are).  In any 
case, this patch does not achieve the proposed semantics, since there is 
no change to ginclude/float.h.

The goal is: if the user's options imply new FLT_EVAL_METHOD values are 
OK, *or* they defined __STDC_WANT_IEC_60559_TYPES_EXT__ before including 
, it should use the appropriate TS 18661-3 value.  Otherwise 
(strict standards modes for existing standards, no 
__STDC_WANT_IEC_60559_TYPES_EXT__) it should use a C11 value.

So in a strict standards mode you need to predefine macros with both 
choices of values and let  choose between them.  One possibility 
is: __FLT_EVAL_METHOD_C99__ is the value to use when 
__STDC_WANT_IEC_60559_TYPES_EXT__ is not defined, __FLT_EVAL_METHOD__ is 
the value to use when it is defined.  Or some other arrangement, with or 
without a macro saying what setting you have for the new option.  But you 
can't avoid changing .

Tests then should be testing the value of FLT_EVAL_METHOD from , 
*not* the internal macros predefined by the compiler.

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

Re: [Patch 8/11] Make _Float16 available if HFmode is available

[Jeff Law]

On 09/30/2016 10:56 AM, James Greenhalgh wrote:


Hi,

Now that we've worked on -fexcess-precision, the comment in targhooks.c
no longer holds. We can now permit _Float16 on any target which provides
HFmode and supports HFmode in libgcc.

Bootstrapped and tested on x86-64, and in series on AArch64.

OK?

Thanks,
James

---
2016-09-30  James Greenhalgh  

* targhooks.c (default_floatn_mode): Enable _Float16 if a target
provides HFmode.

OK when prereqs are approved.

jeff

Re: [Patch 4/11] Implement TARGET_C_EXCESS_PRECISION for m68k

[Jeff Law]

On 09/30/2016 11:01 AM, James Greenhalgh wrote:


Hi,

This patch ports the logic from m68k's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.

Patch tested by building an m68k-none-elf toolchain and running
m68k.exp (without the ability to execute) with no regressions, and manually
inspecting the output assembly code when compiling
testsuite/gcc.target/i386/excess-precision* to show no difference in
code-generation.

OK?

Thanks,
James

---
gcc/

2016-09-30  James Greenhalgh  

* config/m68k/m68k.c (m68k_excess_precision): New.
(TARGET_C_EXCESS_PRECISION): Define.
OK when prereqs are approved.  Similarly for other targets where you 
needed to add this hook.


jeff

Re: [Patch 7/11] Delete TARGET_FLT_EVAL_METHOD and poison it.

[Jeff Law]

On 09/30/2016 10:56 AM, James Greenhalgh wrote:


Hi,

We've removed all uses of TARGET_FLT_EVAL_METHOD, so we can remove it
and poison it.

Bootstrapped and tested on x86-64 and AArch64. Tested on s390 and m68k
to the best of my ability (no execute tests).

OK?

Thanks,
James

---
gcc/

2016-09-30  James Greenhalgh  

* config/s390/s390.h (TARGET_FLT_EVAL_METHOD): Delete.
* config/m68k/m68k.h (TARGET_FLT_EVAL_METHOD): Delete.
* config/i386/i386.h (TARGET_FLT_EVAL_METHOD): Delete.
* defaults.h (TARGET_FLT_EVAL_METHOD): Delete.
* doc/tm.texi.in (TARGET_FLT_EVAL_METHOD): Delete.
* doc/tm.texi: Regenerate.
* system.h (TARGET_FLT_EVAL_METHOD): Poison.

OK when prereqs are approved.
jeff

Re: [patch][fix PR other/31566] @missing_file gives bad error message

[Jeff Law]

On 09/29/2016 12:34 AM, Prasad Ghangal wrote:

Hi all,

I don't know if this is the right time to submit such patches.
But this patch attempts to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31566

I have successfully bootstrapped and tested on x86_64-pc-linux-gnu


testcases:

file:
-Wall

test.c:
void foo()
{
  int a,b;
  a = b + 1;
}

@test2:
void foo()
{
  int a,b;
  a = b + 1;
}

case 1: file and test.c are present
 ./gcc @file test.c -c
test.c: In function ‘foo’:
test.c:3:7: warning: variable ‘a’ set but not used [-Wunused-but-set-variable]
   int a,b;
   ^
test.c:4:5: warning: ‘b’ is used uninitialized in this function
[-Wuninitialized]
   a = b + 1;
   ~~^~~


case 2: file1 is not present and test.c,file are present
./gcc @file @file1 test.c -c
gcc: error: file1: No such file or directory


case 3: file is present and test1.c is not present
./gcc @file test1.c -c
gcc: error: test1.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.

case 4: file1 and test1.c both are not present
./gcc @file1 test1.c -c
gcc: error: file1: No such file or directory
gcc: error: test1.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.


case 5: @test2.c is present
./gcc @test2.c -c
-> compiled successfully without any error/warning


case 6: both file and @test2.c are present
 ./gcc @file @test2.c -c
@test2.c: In function ‘foo’:
@test2.c:3:7: warning: variable ‘a’ set but not used [-Wunused-but-set-variable]
   int a,b;
   ^
@test2.c:4:5: warning: ‘b’ is used uninitialized in this function
[-Wuninitialized]
   a = b + 1;
   ~~^~~


case 7: @file1 is not present and @test2.c is present
./gcc @file1 @test2.c -c
gcc: error: file1: No such file or directory


case 8: both @file1 and @test3.c are not present
gcc: error: file1: No such file or directory
gcc: error: test3.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.

-- in this case @test3.c is treated as a file with arguments (test3.c)

Thanks.  I fixed some minor whitespace nits and installed your fix.

Jeff

Re: [PATCH] Make CHECKING_P a boolean flag again

[Jeff Law]

On 09/25/2016 03:13 AM, Bernd Edlinger wrote:

Hi!


Currently CHECKING_P is not a boolean flag but a ternary option.
However the _P in the name implies it is a boolean.

That should be cleaned up again IMHO.


So this patch splits CHECKING_P into CHECKING_P and a new flag
ENABLE_EXTRA_CHECKING.  All uses of CHECKING_P are actually of
the form "if (CHECKING_P)" so there is no problem there, only the
flag_checking is tested at one place for > 1,  thus we have to
make sure that the default initial value of flag_checking is
0, 1 or 2, dependent on CHECKING_P and ENABLE_EXTRA_CHECKING.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.


changelog-checking-p.txt


2016-09-25  Bernd Edlinger  

* configure.ac: Split CHECKING_P into CHECKING_P and
ENABLE_EXTRA_CHECKING.
* configure: Regenerated.
* config.in: Adjust commment of CHECKING_P.  Add ENABLE_EXTRA_CHECKING.
* common.opt (flag_checking): Use CHECKING_P and ENABLE_EXTRA_CHECKING.

OK.

jeff

Re: C/C++ PATCH to implement -Wpointer-compare warning (PR c++/64767)

[Martin Sebor]

+   permerror (input_location, "ISO C++11 only allows pointer "
+  "conversions for integer literals");


FWIW, I think it would be clearer to either mention the currently
selected language version or leave it out completely rather than
hardcoding C++11.  When the user specifies -std=c++14 (or later),
or when that's the current version used by the compiler, a warning
that tells them what C++ 11 allows isn't really relevant (or
meaningful), and becomes less so as time goes on.

Martin

[Patch libgcc AArch64 10/11] Enable hfmode soft-float conversions and truncations

[James Greenhalgh]

Hi,

This patch enables the conversion functions we need for AArch64's _Float16
support. To do that we need to implement TARGET_SCALAR_MODE_SUPPORTED_P,
so do that now.

OK?

Thanks,
James

---
gcc/

2016-09-30  James Greenhalgh  

* config/aarch64/aarch64-c.c (aarch64_scalar_mode_supported_p): New.
(TARGET_SCALAR_MODE_SUPPORTED_P): Define.

libgcc/

2016-09-30  James Greenhalgh  

* config/aarch64/sfp-machine.h (_FP_NANFRAC_H): Define.
(_FP_NANSIGN_H): Likewise.
* config/aarch64/t-softfp (softfp_extensions): Add hftf.
(softfp_truncations): Add tfhf.
(softfp_extras): Add required conversion functions.

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index df6514d..cda85de 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -14054,6 +14054,17 @@ aarch64_optab_supported_p (int op, machine_mode mode1, machine_mode,
 }
 }
 
+/* Implement TARGET_SCALAR_MODE_SUPPORTED_P - return TRUE
+   if MODE is HFmode, and punt to the generic implementation otherwise.  */
+
+static bool
+aarch64_scalar_mode_supported_p (machine_mode mode)
+{
+  return (mode == HFmode
+	  ? true
+	  : default_scalar_mode_supported_p (mode));
+}
+
 #undef TARGET_ADDRESS_COST
 #define TARGET_ADDRESS_COST aarch64_address_cost
 
@@ -14264,6 +14275,9 @@ aarch64_optab_supported_p (int op, machine_mode mode1, machine_mode,
 #undef TARGET_RTX_COSTS
 #define TARGET_RTX_COSTS aarch64_rtx_costs_wrapper
 
+#undef TARGET_SCALAR_MODE_SUPPORTED_P
+#define TARGET_SCALAR_MODE_SUPPORTED_P aarch64_scalar_mode_supported_p
+
 #undef TARGET_SCHED_ISSUE_RATE
 #define TARGET_SCHED_ISSUE_RATE aarch64_sched_issue_rate
 
diff --git a/libgcc/config/aarch64/sfp-machine.h b/libgcc/config/aarch64/sfp-machine.h
index 5efa245..da154dd 100644
--- a/libgcc/config/aarch64/sfp-machine.h
+++ b/libgcc/config/aarch64/sfp-machine.h
@@ -42,9 +42,11 @@ typedef int __gcc_CMPtype __attribute__ ((mode (__libgcc_cmp_return__)));
 
 #define _FP_DIV_MEAT_Q(R,X,Y)	_FP_DIV_MEAT_2_udiv(Q,R,X,Y)
 
+#define _FP_NANFRAC_H		((_FP_QNANBIT_H << 1) - 1)
 #define _FP_NANFRAC_S		((_FP_QNANBIT_S << 1) - 1)
 #define _FP_NANFRAC_D		((_FP_QNANBIT_D << 1) - 1)
 #define _FP_NANFRAC_Q		((_FP_QNANBIT_Q << 1) - 1), -1
+#define _FP_NANSIGN_H		0
 #define _FP_NANSIGN_S		0
 #define _FP_NANSIGN_D		0
 #define _FP_NANSIGN_Q		0
diff --git a/libgcc/config/aarch64/t-softfp b/libgcc/config/aarch64/t-softfp
index 586dca2..c4ce0dc 100644
--- a/libgcc/config/aarch64/t-softfp
+++ b/libgcc/config/aarch64/t-softfp
@@ -1,8 +1,9 @@
 softfp_float_modes := tf
 softfp_int_modes := si di ti
-softfp_extensions := sftf dftf
-softfp_truncations := tfsf tfdf
+softfp_extensions := sftf dftf hftf
+softfp_truncations := tfsf tfdf tfhf
 softfp_exclude_libgcc2 := n
+softfp_extras := fixhfti fixunshfti floattihf floatuntihf
 
 TARGET_LIBGCC2_CFLAGS += -Wno-missing-prototypes
 

[Patch libgcc 9/11] Update soft-fp from glibc

[James Greenhalgh]

Hi,

This patch merges in the support added to glibc for HFmode conversions in
this patch:

commit 87ab10d6524fe4faabd7eb3eac5868165ecfb323
Author: James Greenhalgh 
Date:   Wed Sep 21 21:02:54 2016 +

[soft-fp] Add support for various half-precision conversion routines.

This patch adds conversion routines required for _Float16 support in
AArch64.

These are one-step conversions to and from TImode and TFmode. We need
these on AArch64 regardless of presence of the ARMv8.2-A 16-bit
floating-point extensions.

In the patch, soft-fp/half.h is derived from soft-fp/single.h .  The
conversion routines are derivatives of their respective SFmode
variants.

* soft-fp/extendhftf2.c: New.
* soft-fp/fixhfti.c: Likewise.
* soft-fp/fixunshfti.c: Likewise.
* soft-fp/floattihf.c: Likewise.
* soft-fp/floatuntihf.c: Likewise.
* soft-fp/half.h: Likewise.
* soft-fp/trunctfhf2.c: Likewise.

Any patch merging from upstream is preapproved acording to our commit
policies, but I'll hold off on committing it until the others in this
series have been approved.

Thanks,
James

---
libgcc/

2016-09-30  James Greenhalgh  

* soft-fp/extendhftf2.c: New.
* soft-fp/fixhfti.c: Likewise.
* soft-fp/fixunshfti.c: Likewise.
* soft-fp/floattihf.c: Likewise.
* soft-fp/floatuntihf.c: Likewise.
* soft-fp/half.h: Likewise.
* soft-fp/trunctfhf2.c: Likewise.

diff --git a/libgcc/soft-fp/extendhftf2.c b/libgcc/soft-fp/extendhftf2.c
new file mode 100644
index 000..6ff6438
--- /dev/null
+++ b/libgcc/soft-fp/extendhftf2.c
@@ -0,0 +1,53 @@
+/* Software floating-point emulation.
+   Return an IEEE half converted to IEEE quad
+   Copyright (C) 1997-2016 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   In addition to the permissions in the GNU Lesser General Public
+   License, the Free Software Foundation gives you unlimited
+   permission to link the compiled version of this file into
+   combinations with other programs, and to distribute those
+   combinations without any restriction coming from the use of this
+   file.  (The Lesser General Public License restrictions do apply in
+   other respects; for example, they cover modification of the file,
+   and distribution when not linked into a combine executable.)
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   .  */
+
+#define FP_NO_EXACT_UNDERFLOW
+#include "soft-fp.h"
+#include "half.h"
+#include "quad.h"
+
+TFtype
+__extendhftf2 (HFtype a)
+{
+  FP_DECL_EX;
+  FP_DECL_H (A);
+  FP_DECL_Q (R);
+  TFtype r;
+
+  FP_INIT_EXCEPTIONS;
+  FP_UNPACK_RAW_H (A, a);
+#if (2 * _FP_W_TYPE_SIZE) < _FP_FRACBITS_Q
+  FP_EXTEND (Q, H, 4, 1, R, A);
+#else
+  FP_EXTEND (Q, H, 2, 1, R, A);
+#endif
+  FP_PACK_RAW_Q (r, R);
+  FP_HANDLE_EXCEPTIONS;
+
+  return r;
+}
diff --git a/libgcc/soft-fp/fixhfti.c b/libgcc/soft-fp/fixhfti.c
new file mode 100644
index 000..3610f4c
--- /dev/null
+++ b/libgcc/soft-fp/fixhfti.c
@@ -0,0 +1,45 @@
+/* Software floating-point emulation.
+   Convert IEEE half to 128bit signed integer
+   Copyright (C) 2007-2016 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   In addition to the permissions in the GNU Lesser General Public
+   License, the Free Software Foundation gives you unlimited
+   permission to link the compiled version of this file into
+   combinations with other programs, and to distribute those
+   combinations without any restriction coming from the use of this
+   file.  (The Lesser General Public License restrictions do apply in
+   other respects; for example, they cover modification of the file,
+   and distribution when not linked into a combine executable.)
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS 

[Patch AArch64 11/11] Enable _Float16

[James Greenhalgh]

Hi,

Finally, this patch adds the back-end wiring to get AArch64 support for
the _Float16 type working.

Bootstrapped on AArch64 with no issues.

OK?

Thanks,
James

---
2016-09-30  James Greenhalgh  

* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Update
__FLT_EVAL_METHOD__ and __FLT_EVAL_METHOD_C99__ when we switch
architecture levels.
* config/aarch64/aarch64.c (aarch64_promoted_type): Only promote
the aarch64_fp16_type_node, not all HFmode types.
(aarch64_libgcc_floating_mode_supported_p): Support HFmode.
(aarch64_scalar_mode_supported_p): Likewise.
(aarch64_excess_precision): New.
(TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P): Define.
(TARGET_SCALAR_MODE_SUPPORTED_P): Likewise.
(TARGET_C_EXCESS_PRECISION): Likewise.

2016-09-30  James Greenhalgh  

* gcc.target/aarch64/_Float16_1.c: New.
* gcc.target/aarch64/_Float16_2.c: Likewise.
* gcc.target/aarch64/_Float16_3.c: Likewise.

diff --git a/gcc/config/aarch64/aarch64-c.c b/gcc/config/aarch64/aarch64-c.c
index 3380ed6..9982512 100644
--- a/gcc/config/aarch64/aarch64-c.c
+++ b/gcc/config/aarch64/aarch64-c.c
@@ -132,6 +132,16 @@ aarch64_update_cpp_builtins (cpp_reader *pfile)
 
   aarch64_def_or_undef (TARGET_CRYPTO, "__ARM_FEATURE_CRYPTO", pfile);
   aarch64_def_or_undef (TARGET_SIMD_RDMA, "__ARM_FEATURE_QRDMX", pfile);
+
+  /* Not for ACLE, but required to keep "float.h" correct if we switch
+ target between implementations that do or do not support ARMv8.2-A
+ 16-bit floating-point extensions.  */
+  cpp_undef (pfile, "__FLT_EVAL_METHOD__");
+  builtin_define_with_int_value ("__FLT_EVAL_METHOD__",
+ c_flt_eval_method (true));
+  cpp_undef (pfile, "__FLT_EVAL_METHOD_C99__");
+  builtin_define_with_int_value ("__FLT_EVAL_METHOD_C99__",
+ c_flt_eval_method (false));
 }
 
 /* Implement TARGET_CPU_CPP_BUILTINS.  */
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index cda85de..01e1ca0 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -14029,12 +14029,19 @@ aarch64_vec_fpconst_pow_of_2 (rtx x)
   return firstval;
 }
 
-/* Implement TARGET_PROMOTED_TYPE to promote __fp16 to float.  */
+/* Implement TARGET_PROMOTED_TYPE to promote 16-bit floating point types
+   to float.
+
+   __fp16 always promotes through this hook.
+   _Float16 may promote if TARGET_FLT_EVAL_METHOD is 16, but we do that
+   through the generic excess precision logic rather than here.  */
+
 static tree
 aarch64_promoted_type (const_tree t)
 {
-  if (SCALAR_FLOAT_TYPE_P (t) && TYPE_PRECISION (t) == 16)
+  if (t == aarch64_fp16_type_node)
 return float_type_node;
+
   return NULL_TREE;
 }
 
@@ -14054,6 +14061,17 @@ aarch64_optab_supported_p (int op, machine_mode mode1, machine_mode,
 }
 }
 
+/* Implement TARGET_LIBGCC_FLOATING_POINT_MODE_SUPPORTED_P - return TRUE
+   if MODE is HFmode, and punt to the generic implementation otherwise.  */
+
+static bool
+aarch64_libgcc_floating_mode_supported_p (machine_mode mode)
+{
+  return (mode == HFmode
+	  ? true
+	  : default_libgcc_floating_mode_supported_p (mode));
+}
+
 /* Implement TARGET_SCALAR_MODE_SUPPORTED_P - return TRUE
if MODE is HFmode, and punt to the generic implementation otherwise.  */
 
@@ -14065,6 +14083,47 @@ aarch64_scalar_mode_supported_p (machine_mode mode)
 	  : default_scalar_mode_supported_p (mode));
 }
 
+/* Set the value of FLT_EVAL_METHOD.
+   ISO/IEC TS 18661-3 defines two values that we'd like to make use of:
+
+0: evaluate all operations and constants, whose semantic type has at
+   most the range and precision of type float, to the range and
+   precision of float; evaluate all other operations and constants to
+   the range and precision of the semantic type;
+
+N, where _FloatN is a supported interchange floating type
+   evaluate all operations and constants, whose semantic type has at
+   most the range and precision of _FloatN type, to the range and
+   precision of the _FloatN type; evaluate all other operations and
+   constants to the range and precision of the semantic type;
+
+   If we have the ARMv8.2-A extensions then we support _Float16 in native
+   precision, so we should set this to 16.  Otherwise, we support the type,
+   but want to evaluate expressions in float precision, so set this to
+   0.  */
+
+static enum flt_eval_method
+aarch64_excess_precision (enum excess_precision_type type)
+{
+  switch (type)
+{
+  case EXCESS_PRECISION_TYPE_FAST:
+  case EXCESS_PRECISION_TYPE_STANDARD:
+	/* We can calculate either in 16-bit range and precision or
+	   32-bit range and precision.  Make that decision based on whether
+	   we have native support for the ARMv8.2-A 16-bit floating-point
+	   instructions or not.  */
+	return (TARGET_FP_F16INST
+		? FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16
+		: 

[Patch libgcc 9/11] Update soft-fp from glibc

[James Greenhalgh]

Hi,

This patch merges in the support added to glibc for HFmode conversions in
this patch:

commit 87ab10d6524fe4faabd7eb3eac5868165ecfb323
Author: James Greenhalgh 
Date:   Wed Sep 21 21:02:54 2016 +

[soft-fp] Add support for various half-precision conversion routines.

This patch adds conversion routines required for _Float16 support in
AArch64.

These are one-step conversions to and from TImode and TFmode. We need
these on AArch64 regardless of presence of the ARMv8.2-A 16-bit
floating-point extensions.

In the patch, soft-fp/half.h is derived from soft-fp/single.h .  The
conversion routines are derivatives of their respective SFmode
variants.

* soft-fp/extendhftf2.c: New.
* soft-fp/fixhfti.c: Likewise.
* soft-fp/fixunshfti.c: Likewise.
* soft-fp/floattihf.c: Likewise.
* soft-fp/floatuntihf.c: Likewise.
* soft-fp/half.h: Likewise.
* soft-fp/trunctfhf2.c: Likewise.

Any patch merging from upstream is preapproved acording to our commit
policies, but I'll hold off on committing it until the others in this
series have been approved.

Thanks,
James

---
libgcc/

2016-09-30  James Greenhalgh  

* soft-fp/extendhftf2.c: New.
* soft-fp/fixhfti.c: Likewise.
* soft-fp/fixunshfti.c: Likewise.
* soft-fp/floattihf.c: Likewise.
* soft-fp/floatuntihf.c: Likewise.
* soft-fp/half.h: Likewise.
* soft-fp/trunctfhf2.c: Likewise.

diff --git a/libgcc/soft-fp/extendhftf2.c b/libgcc/soft-fp/extendhftf2.c
new file mode 100644
index 000..6ff6438
--- /dev/null
+++ b/libgcc/soft-fp/extendhftf2.c
@@ -0,0 +1,53 @@
+/* Software floating-point emulation.
+   Return an IEEE half converted to IEEE quad
+   Copyright (C) 1997-2016 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   In addition to the permissions in the GNU Lesser General Public
+   License, the Free Software Foundation gives you unlimited
+   permission to link the compiled version of this file into
+   combinations with other programs, and to distribute those
+   combinations without any restriction coming from the use of this
+   file.  (The Lesser General Public License restrictions do apply in
+   other respects; for example, they cover modification of the file,
+   and distribution when not linked into a combine executable.)
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   .  */
+
+#define FP_NO_EXACT_UNDERFLOW
+#include "soft-fp.h"
+#include "half.h"
+#include "quad.h"
+
+TFtype
+__extendhftf2 (HFtype a)
+{
+  FP_DECL_EX;
+  FP_DECL_H (A);
+  FP_DECL_Q (R);
+  TFtype r;
+
+  FP_INIT_EXCEPTIONS;
+  FP_UNPACK_RAW_H (A, a);
+#if (2 * _FP_W_TYPE_SIZE) < _FP_FRACBITS_Q
+  FP_EXTEND (Q, H, 4, 1, R, A);
+#else
+  FP_EXTEND (Q, H, 2, 1, R, A);
+#endif
+  FP_PACK_RAW_Q (r, R);
+  FP_HANDLE_EXCEPTIONS;
+
+  return r;
+}
diff --git a/libgcc/soft-fp/fixhfti.c b/libgcc/soft-fp/fixhfti.c
new file mode 100644
index 000..3610f4c
--- /dev/null
+++ b/libgcc/soft-fp/fixhfti.c
@@ -0,0 +1,45 @@
+/* Software floating-point emulation.
+   Convert IEEE half to 128bit signed integer
+   Copyright (C) 2007-2016 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   In addition to the permissions in the GNU Lesser General Public
+   License, the Free Software Foundation gives you unlimited
+   permission to link the compiled version of this file into
+   combinations with other programs, and to distribute those
+   combinations without any restriction coming from the use of this
+   file.  (The Lesser General Public License restrictions do apply in
+   other respects; for example, they cover modification of the file,
+   and distribution when not linked into a combine executable.)
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS 

[Patch 4/11] Implement TARGET_C_EXCESS_PRECISION for m68k

[James Greenhalgh]

Hi,

This patch ports the logic from m68k's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.

Patch tested by building an m68k-none-elf toolchain and running
m68k.exp (without the ability to execute) with no regressions, and manually
inspecting the output assembly code when compiling
testsuite/gcc.target/i386/excess-precision* to show no difference in
code-generation.

OK?

Thanks,
James

---
gcc/

2016-09-30  James Greenhalgh  

* config/m68k/m68k.c (m68k_excess_precision): New.
(TARGET_C_EXCESS_PRECISION): Define.

diff --git a/gcc/config/m68k/m68k.c b/gcc/config/m68k/m68k.c
index a104193..c858d7e 100644
--- a/gcc/config/m68k/m68k.c
+++ b/gcc/config/m68k/m68k.c
@@ -182,6 +182,8 @@ static rtx m68k_function_arg (cumulative_args_t, machine_mode,
 static bool m68k_cannot_force_const_mem (machine_mode mode, rtx x);
 static bool m68k_output_addr_const_extra (FILE *, rtx);
 static void m68k_init_sync_libfuncs (void) ATTRIBUTE_UNUSED;
+static enum flt_eval_method
+m68k_excess_precision (enum excess_precision_type);
 
 /* Initialize the GCC target structure.  */
 
@@ -322,6 +324,9 @@ static void m68k_init_sync_libfuncs (void) ATTRIBUTE_UNUSED;
 #undef TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA
 #define TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA m68k_output_addr_const_extra
 
+#undef TARGET_EXCESS_PRECISION
+#define TARGET_EXCESS_PRECISION m68k_excess_precision
+
 /* The value stored by TAS.  */
 #undef TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
 #define TARGET_ATOMIC_TEST_AND_SET_TRUEVAL 128
@@ -6528,4 +6533,36 @@ m68k_epilogue_uses (int regno ATTRIBUTE_UNUSED)
 	  == m68k_fk_interrupt_handler));
 }
 
+
+/* Implement TARGET_EXCESS_PRECISION.
+
+   Set the value of FLT_EVAL_METHOD in float.h.  When using 68040 fp
+   instructions, we get proper intermediate rounding, otherwise we
+   get extended precision results.  */
+
+static enum flt_eval_method
+m68k_excess_precision (enum excess_precision_type type)
+{
+  switch (type)
+{
+  case EXCESS_PRECISION_TYPE_FAST:
+	/* The fastest type to promote to will always be the native type,
+	   whether that occurs with implicit excess precision or
+	   otherwise.  */
+	return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
+  case EXCESS_PRECISION_TYPE_STANDARD:
+  case EXCESS_PRECISION_TYPE_IMPLICIT:
+	/* Otherwise, the excess precision we want when we are
+	   in a standards compliant mode, and the implicit precision we
+	   provide can be identical.  */
+	if (TARGET_68040 || ! TARGET_68881)
+	  return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
+
+	return FLT_EVAL_METHOD_PROMOTE_TO_LONG_DOUBLE;
+  default:
+	gcc_unreachable ();
+}
+  return FLT_EVAL_METHOD_UNPREDICTABLE;
+}
+
 #include "gt-m68k.h"

Re: [PATCH][v4] GIMPLE store merging pass

[Richard Biener]

On September 30, 2016 4:43:10 PM GMT+02:00, Kyrill Tkachov 
 wrote:
>
>On 30/09/16 15:36, Kyrill Tkachov wrote:
>> Hi Richard,
>>
>> On 29/09/16 11:45, Richard Biener wrote:
>>>
 +
 +  /* In some cases get_inner_reference may return a
 + MEM_REF [ptr + byteoffset].  For the purposes of this
>pass
 + canonicalize the base_addr to MEM_REF [ptr] and take
 + byteoffset into account in the bitpos.  This occurs in
 + PR 23684 and this way we can catch more chains.  */
 +  if (TREE_CODE (base_addr) == MEM_REF
 +  && POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (base_addr,
>0)))
 +  && TREE_CODE (TREE_OPERAND (base_addr, 1)) ==
>INTEGER_CST
>>> This is always an INTEGER_CST.
>>>
 +  && tree_fits_shwi_p (TREE_OPERAND (base_addr, 1))
>>> This will never allow negative offsets (but maybe this is a good
>thing?)
>>>
>>> )
 +{
 +  bitpos += tree_to_shwi (TREE_OPERAND (base_addr, 1))
 +* BITS_PER_UNIT;
>>> this multiplication may overflow.  There is mem_ref_offset () which
>>> you should really use here, see get_inner_reference itself (and
>>> how to translate back from offset_int to HOST_WIDE_INT if it fits).
>>>
 +
 +  base_addr = fold_build2 (MEM_REF, TREE_TYPE (base_addr),
 +   TREE_OPERAND (base_addr, 0),
 +   build_zero_cst (TREE_TYPE (
 + TREE_OPERAND (base_addr, 1;
>>> Ugh, building a tree node ... you could use TREE_OPERAND (base_addr,
>0)
>>> as base_addr instead?
>>
>> This didn't work for me because aliasing info was lost.
>> So in the example:
>> void
>> foo2 (struct bar *p, struct bar *p2)
>> {
>>   p->b = 0xff;
>>   p2->b = 0xa;
>>   p->a = 0xf;
>>   p2->c = 0xc;
>>   p->c = 0xff;
>>   p2->d = 0xbf;
>>   p->d = 0xfff;
>> }
>>
>> we end up merging p->b with p->a even though the p2->b store may
>alias.
>> We'll record the base objects as being 'p' and 'p2' whereas with my
>approach
>> we record them as '*p' and '*p2'. I don't suppose I could just do:
>> TREE_OPERAND (base_addr, 1) = build_zero_cst (TREE_TYPE (TREE_OPERAND
>(base_addr, 1)));
>> ?
>>
>
>Although I think I could try to make it work by using
>ptr_derefs_may_alias_p in the alias checks
>a bit more. I'll see what I can do.

I don't think this will be enough.  Don't bother with this comment too much, 
it's a minor issue.

Richard.

>Kyrill
>
>> Thanks,
>> Kyrill
>>
>>>
 +}
 +
 +  struct imm_store_chain_info **chain_info
 += m_stores.get (base_addr);
 +
 +  if (!invalid)
 +{
 +  store_immediate_info *info;
 +  if (chain_info)
 +{
 +  info = new store_immediate_info (
 +bitsize, bitpos, rhs, lhs, stmt,
 +(*chain_info)->m_store_info.length ());
 +  if (dump_file)
 +{
 +  fprintf (dump_file,
 +   "Recording immediate store from stmt:\n");
 +  print_gimple_stmt (dump_file, stmt, 0, 0);
 +}
 +  (*chain_info)->m_store_info.safe_push (info);
 +  continue;
 +}
 +
 +  /* Store aliases any existing chain?  */
 +  terminate_all_aliasing_chains (lhs, base_addr, stmt);
 +
 +  /* Start a new chain.  */
 +  struct imm_store_chain_info *new_chain
 += new imm_store_chain_info;
 +  info = new store_immediate_info (bitsize, bitpos, rhs,
>lhs,
 +   stmt, 0);
 +  new_chain->m_store_info.safe_push (info);
 +  m_stores.put (base_addr, new_chain);
 +  if (dump_file)
 +{
 +  fprintf (dump_file,
 +   "Starting new chain with statement:\n");
 +  print_gimple_stmt (dump_file, stmt, 0, 0);
 +  fprintf (dump_file, "The base object is:\n");
 +  print_generic_expr (dump_file, base_addr, 0);
 +  fprintf (dump_file, "\n");
 +}
 +}
 +  else
 +terminate_all_aliasing_chains (lhs, base_addr, stmt);
 +
 +  continue;
 +}
 +
 +  terminate_all_aliasing_chains (NULL_TREE, NULL_TREE, stmt);
 +}
 +  terminate_and_process_all_chains (bb);
 +}
 +  return 0;
 +}
 +
 +} // anon namespace
 +
 +/* Construct and return a store merging pass object.  */
 +
 +gimple_opt_pass *
 +make_pass_store_merging (gcc::context *ctxt)
 +{
 +  return new pass_store_merging (ctxt);
 +}
 diff --git a/gcc/opts.c b/gcc/opts.c
 index 45f1f89c..e63d7e4 100644
 --- a/gcc/opts.c
 +++ b/gcc/opts.c
 @@ -463,6 

[Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[James Greenhalgh]

Hi,

This patch ports the logic from s390's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.

Patch tested by building an s390-none-linux toolchain and running
s390.exp (without the ability to execute) with no regressions, and manually
inspecting the output assembly code when compiling
testsuite/gcc.target/i386/excess-precision* to show no difference in
code-generation.

OK?

Thanks,
James

---
gcc/

2016-09-30  James Greenhalgh  

* config/s390/s390.c (s390_excess_precision): New.
(TARGET_C_EXCESS_PRECISION): Define.

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 3bdb648..b704d46 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -15106,6 +15106,34 @@ s390_invalid_binary_op (int op ATTRIBUTE_UNUSED, const_tree type1, const_tree ty
   return NULL;
 }
 
+/* Implement TARGET_EXCESS_PRECISION.
+
+   This is used by float.h to define the float_t and double_t data
+   types.  For historical reasons both are double on s390 what cannot
+   be changed anymore.  */
+
+static enum flt_eval_method
+s390_excess_precision (enum excess_precision_type type)
+{
+  switch (type)
+{
+  case EXCESS_PRECISION_TYPE_FAST:
+	/* The fastest type to promote to will always be the native type,
+	   whether that occurs with implicit excess precision or
+	   otherwise.  */
+	return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
+  case EXCESS_PRECISION_TYPE_STANDARD:
+  case EXCESS_PRECISION_TYPE_IMPLICIT:
+	/* Otherwise, the excess precision we want when we are
+	   in a standards compliant mode, and the implicit precision we
+	   provide can be identical.  */
+	return FLT_EVAL_METHOD_PROMOTE_TO_DOUBLE;
+  default:
+	gcc_unreachable ();
+}
+  return FLT_EVAL_METHOD_UNPREDICTABLE;
+}
+
 /* Initialize GCC target structure.  */
 
 #undef  TARGET_ASM_ALIGNED_HI_OP
@@ -15161,6 +15189,9 @@ s390_invalid_binary_op (int op ATTRIBUTE_UNUSED, const_tree type1, const_tree ty
 #undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
 #define TARGET_ASM_CAN_OUTPUT_MI_THUNK hook_bool_const_tree_hwi_hwi_const_tree_true
 
+#undef TARGET_C_EXCESS_PRECISION
+#define TARGET_C_EXCESS_PRECISION s390_excess_precision
+
 #undef  TARGET_SCHED_ADJUST_PRIORITY
 #define TARGET_SCHED_ADJUST_PRIORITY s390_adjust_priority
 #undef TARGET_SCHED_ISSUE_RATE

[Patch 2/11] Implement TARGET_C_EXCESS_PRECISION for i386

[James Greenhalgh]

Hi,

This patch ports the logic from i386's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.

Bootstrapped and tested with no issues.

OK?

Thanks,
James

---
gcc/

2016-09-30  James Greenhalgh  

* config/i386/i386.c (ix86_excess_precision): New.
(TARGET_C_EXCESS_PRECISION): Define.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index e0b2d57..3c801c2 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -50359,6 +50359,45 @@ ix86_addr_space_zero_address_valid (addr_space_t as)
 {
   return as != ADDR_SPACE_GENERIC;
 }
+
+/* Set the value of FLT_EVAL_METHOD in float.h.  When using only the
+   FPU, assume that the fpcw is set to extended precision; when using
+   only SSE, rounding is correct; when using both SSE and the FPU,
+   the rounding precision is indeterminate, since either may be chosen
+   apparently at random.  */
+
+static enum flt_eval_method
+ix86_excess_precision (enum excess_precision_type type)
+{
+  switch (type)
+{
+  case EXCESS_PRECISION_TYPE_FAST:
+	/* The fastest type to promote to will always be the native type,
+	   whether that occurs with implicit excess precision or
+	   otherwise.  */
+	return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
+  case EXCESS_PRECISION_TYPE_STANDARD:
+  case EXCESS_PRECISION_TYPE_IMPLICIT:
+	/* Otherwise, the excess precision we want when we are
+	   in a standards compliant mode, and the implicit precision we
+	   provide can be identical.  */
+	if (!TARGET_80387)
+	  return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
+	else if (TARGET_MIX_SSE_I387)
+	  return FLT_EVAL_METHOD_UNPREDICTABLE;
+	else if (!TARGET_SSE_MATH)
+	  return FLT_EVAL_METHOD_PROMOTE_TO_LONG_DOUBLE;
+	else if (TARGET_SSE2)
+	  return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
+	else
+	  return FLT_EVAL_METHOD_UNPREDICTABLE;
+  default:
+	gcc_unreachable ();
+}
+
+  return FLT_EVAL_METHOD_UNPREDICTABLE;
+}
+
 #undef TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID
 #define TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID ix86_addr_space_zero_address_valid
 
@@ -50563,6 +50602,8 @@ ix86_addr_space_zero_address_valid (addr_space_t as)
 #undef TARGET_MD_ASM_ADJUST
 #define TARGET_MD_ASM_ADJUST ix86_md_asm_adjust
 
+#undef TARGET_C_EXCESS_PRECISION
+#define TARGET_C_EXCESS_PRECISION ix86_excess_precision
 #undef TARGET_PROMOTE_PROTOTYPES
 #define TARGET_PROMOTE_PROTOTYPES hook_bool_const_tree_true
 #undef TARGET_SETUP_INCOMING_VARARGS

Re: [PATCH][v4] GIMPLE store merging pass

[Kyrill Tkachov]

Hi Richard,

On 29/09/16 11:45, Richard Biener wrote:


+  gimple_seq seq = NULL;
+  unsigned int num_stmts = 0;
+  tree offset_type = get_type_for_merged_store (group);
+  tree last_vdef, new_vuse;
+  last_vdef = gimple_vdef (group->last_stmt);
+  new_vuse = gimple_vuse (group->last_stmt);
+  location_t loc = get_merged_store_location (group);
If you end up splitting the store then please use a location appropriate
for the split part.  Likewise for the alias type.



How would I get the appropriate alias type?
Is there some way to construct it from the alias type of the base
object offset by some number of bytes?


Thanks,
Kyrill

[Patch 7/11] Delete TARGET_FLT_EVAL_METHOD and poison it.

[James Greenhalgh]

Hi,

We've removed all uses of TARGET_FLT_EVAL_METHOD, so we can remove it
and poison it.

Bootstrapped and tested on x86-64 and AArch64. Tested on s390 and m68k
to the best of my ability (no execute tests).

OK?

Thanks,
James

---
gcc/

2016-09-30  James Greenhalgh  

* config/s390/s390.h (TARGET_FLT_EVAL_METHOD): Delete.
* config/m68k/m68k.h (TARGET_FLT_EVAL_METHOD): Delete.
* config/i386/i386.h (TARGET_FLT_EVAL_METHOD): Delete.
* defaults.h (TARGET_FLT_EVAL_METHOD): Delete.
* doc/tm.texi.in (TARGET_FLT_EVAL_METHOD): Delete.
* doc/tm.texi: Regenerate.
* system.h (TARGET_FLT_EVAL_METHOD): Poison.

diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 8751143..b5e4d61 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -690,17 +690,6 @@ extern const char *host_detect_local_cpu (int argc, const char **argv);
   SUBTARGET_EXTRA_SPECS
 
 
-/* Set the value of FLT_EVAL_METHOD in float.h.  When using only the
-   FPU, assume that the fpcw is set to extended precision; when using
-   only SSE, rounding is correct; when using both SSE and the FPU,
-   the rounding precision is indeterminate, since either may be chosen
-   apparently at random.  */
-#define TARGET_FLT_EVAL_METHOD		\
-  (TARGET_80387\
-   ? (TARGET_MIX_SSE_I387 ? -1		\
-  : (TARGET_SSE_MATH ? (TARGET_SSE2 ? 0 : -1) : 2))			\
-   : 0)
-
 /* Whether to allow x87 floating-point arithmetic on MODE (one of
SFmode, DFmode and XFmode) in the current excess precision
configuration.  */
diff --git a/gcc/config/m68k/m68k.h b/gcc/config/m68k/m68k.h
index 2aa858f..2021e9d 100644
--- a/gcc/config/m68k/m68k.h
+++ b/gcc/config/m68k/m68k.h
@@ -281,11 +281,6 @@ along with GCC; see the file COPYING3.  If not see
 #define LONG_DOUBLE_TYPE_SIZE			\
   ((TARGET_COLDFIRE || TARGET_FIDOA) ? 64 : 80)
 
-/* Set the value of FLT_EVAL_METHOD in float.h.  When using 68040 fp
-   instructions, we get proper intermediate rounding, otherwise we
-   get extended precision results.  */
-#define TARGET_FLT_EVAL_METHOD ((TARGET_68040 || ! TARGET_68881) ? 0 : 2)
-
 #define BITS_BIG_ENDIAN 1
 #define BYTES_BIG_ENDIAN 1
 #define WORDS_BIG_ENDIAN 1
diff --git a/gcc/config/s390/s390.h b/gcc/config/s390/s390.h
index 3a7be1a..1a2c150 100644
--- a/gcc/config/s390/s390.h
+++ b/gcc/config/s390/s390.h
@@ -247,11 +247,6 @@ extern const char *s390_host_detect_local_cpu (int argc, const char **argv);
 #define S390_TDC_INFINITY (S390_TDC_POSITIVE_INFINITY \
 			  | S390_TDC_NEGATIVE_INFINITY )
 
-/* This is used by float.h to define the float_t and double_t data
-   types.  For historical reasons both are double on s390 what cannot
-   be changed anymore.  */
-#define TARGET_FLT_EVAL_METHOD 1
-
 /* Target machine storage layout.  */
 
 /* Everything is big-endian.  */
diff --git a/gcc/defaults.h b/gcc/defaults.h
index c62c844..210a3c5 100644
--- a/gcc/defaults.h
+++ b/gcc/defaults.h
@@ -963,9 +963,6 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #define REG_WORDS_BIG_ENDIAN WORDS_BIG_ENDIAN
 #endif
 
-#ifndef TARGET_FLT_EVAL_METHOD
-#define TARGET_FLT_EVAL_METHOD 0
-#endif
 
 #ifndef TARGET_DEC_EVAL_METHOD
 #define TARGET_DEC_EVAL_METHOD 2
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 0bdae58..9c10ea8 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -1566,13 +1566,6 @@ uses this macro should also arrange to use @file{t-gnu-prefix} in
 the libgcc @file{config.host}.
 @end defmac
 
-@defmac TARGET_FLT_EVAL_METHOD
-A C expression for the value for @code{FLT_EVAL_METHOD} in @file{float.h},
-assuming, if applicable, that the floating-point control word is in its
-default state.  If you do not define this macro the value of
-@code{FLT_EVAL_METHOD} will be zero.
-@end defmac
-
 @defmac WIDEST_HARDWARE_FP_SIZE
 A C expression for the size in bits of the widest floating-point format
 supported by the hardware.  If you define this macro, you must specify a
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 7c7af33..0a4d19b 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -1402,13 +1402,6 @@ uses this macro should also arrange to use @file{t-gnu-prefix} in
 the libgcc @file{config.host}.
 @end defmac
 
-@defmac TARGET_FLT_EVAL_METHOD
-A C expression for the value for @code{FLT_EVAL_METHOD} in @file{float.h},
-assuming, if applicable, that the floating-point control word is in its
-default state.  If you do not define this macro the value of
-@code{FLT_EVAL_METHOD} will be zero.
-@end defmac
-
 @defmac WIDEST_HARDWARE_FP_SIZE
 A C expression for the size in bits of the widest floating-point format
 supported by the hardware.  If you define this macro, you must specify a
diff --git a/gcc/system.h b/gcc/system.h
index cc353f5..df7a398 100644
--- a/gcc/system.h
+++ b/gcc/system.h
@@ -896,7 +896,7 @@ extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
 	ASM_BYTE_OP MEMBER_TYPE_FORCES_BLK 

[Patch 6/11] Migrate excess precision logic to use TARGET_EXCESS_PRECISION

[James Greenhalgh]

Hi,

This patch moves the logic for excess precision from using the
TARGET_FLT_EVAL_METHOD macro to the TARGET_EXCESS_PRECISION hook
introduced earlier in the patch series.

These logic changes follow Joseph's comments at
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00410.html

Briefly; we have four things to change.

  1) The logic in tree.c::excess_precision_type .
  Here we want to ask the target which excess preicion it would like for
  whichever of -fexcess-precision=standard or -fexcess-precision=fast is
  in use, then apply that.

  2) The logic in c-family/c-cppbuiltin.c::c_cpp_flt_eval_method_iec_559 .
  We want to update this to ensure that the target claims the same excess
  precision to be implicitly added to operations that it reports in
  -fexcess-precision=standard mode. We take the join of these two reported
  values, and only if the join is equal to the excess precision requested
  for -fexcess-precision=standard can we set the IEC_559 macro.

  3) The logic in c-family/c-cppbuiltin.c::c_cpp_builtin for setting
  __FLT_EVAL_METHOD__ .
  Which is now little more complicated, and makes use of
  -fpermitted-flt-eval-methods from patch 5.

  4) The logic in c-family/c-cppbuiltin.c::c_cpp_builtin for setting
  __LIBGCC_*_EXCESS_PRECISION__ .
  This can just be the implicit precision reported by the target.

Having moved the logic in to those areas, we can simplify
toplev.c::init_excess_precision , which now only retains the assert that
-fexcess-precision=default has been rewritten by the language front-end, and
the set from the command-line variable to the internal variable.

The documentation in invoke.texi is not quite right for the impact of
-fexcess-precision, so I've rewritten the text to read a little more
generic.

Bootstrapped on x86_64 and aarch64 with no issues.

Thanks,
James

---
gcc/

2016-09-30  James Greenhalgh  

* toplev.c (init_excess_precision): Delete most logic.
* tree.c (excess_precision_type): Rewrite to use
TARGET_EXCESS_PRECISION.
* doc/invoke.texi (-fexcess-precision): Document behaviour in a
more generic fashion.

gcc/c-family/

2016-09-30  James Greenhalgh  

* c-common.c (excess_precision_mode_join): New.
(c_ts18661_flt_eval_method): New.
(c_c11_flt_eval_method): Likewise.
(c_flt_eval_method): Likewise.
* c-common.h (excess_precision_mode_join): New.
(c_flt_eval_method): Likewise.
* c-cppbuiltin.c (c_cpp_flt_eval_method_iec_559): New.
(cpp_iec_559_value): Call it.
(c_cpp_builtins): Modify logic for __LIBGCC_*_EXCESS_PRECISION__,
call c_flt_eval_method to set __FLT_EVAL_METHOD__ and
__FLT_EVAL_METHOD_C99__.

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 2652259..983f71a 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -13145,4 +13145,83 @@ diagnose_mismatched_attributes (tree olddecl, tree newdecl)
   return warned;
 }
 
+/* Return the latice point which is the wider of the two FLT_EVAL_METHOD
+   modes X, Y.  This isn't just  >, as the FLT_EVAL_METHOD values added
+   by C TS 18661-3 for interchange  types that are computed in their
+   native precision are larger than the C11 values for evaluating in the
+   precision of float/double/long double.  If either mode is
+   FLT_EVAL_METHOD_UNPREDICTABLE, return that.  */
+
+enum flt_eval_method
+excess_precision_mode_join (enum flt_eval_method x,
+			enum flt_eval_method y)
+{
+  if (x == FLT_EVAL_METHOD_UNPREDICTABLE
+  || y == FLT_EVAL_METHOD_UNPREDICTABLE)
+return FLT_EVAL_METHOD_UNPREDICTABLE;
+
+  /* GCC only supports one interchange type right now, _Float16.  If
+ we're evaluating _Float16 in 16-bit precision, then flt_eval_method
+ will be FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16.  */
+  if (x == FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16)
+return y;
+  if (y == FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16)
+return x;
+
+  /* Other values for flt_eval_method are directly comparable, and we want
+ the maximum.  */
+  return MAX (x, y);
+}
+
+/* Return the value that should be set for FLT_EVAL_METHOD in the
+   context of ISO/IEC TS 18861-3.
+
+   This should relate to the effective excess precision seen by the user,
+   which is the join point of the precision the target requests for
+   -fexcess-precision={standard,fast} and the implicit excess precision
+   the target uses.  */
+
+static enum flt_eval_method
+c_ts18661_flt_eval_method (void)
+{
+  enum flt_eval_method implicit
+= targetm.c.excess_precision (EXCESS_PRECISION_TYPE_IMPLICIT);
+
+  enum excess_precision_type flag_type
+= (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD
+   ? EXCESS_PRECISION_TYPE_STANDARD
+   : EXCESS_PRECISION_TYPE_FAST);
+
+  enum flt_eval_method requested
+= targetm.c.excess_precision (flag_type);
+
+  return excess_precision_mode_join (implicit, requested);
+}
+
+/* 

[Patch 8/11] Make _Float16 available if HFmode is available

[James Greenhalgh]

Hi,

Now that we've worked on -fexcess-precision, the comment in targhooks.c
no longer holds. We can now permit _Float16 on any target which provides
HFmode and supports HFmode in libgcc.

Bootstrapped and tested on x86-64, and in series on AArch64.

OK?

Thanks,
James

---
2016-09-30  James Greenhalgh  

* targhooks.c (default_floatn_mode): Enable _Float16 if a target
provides HFmode.

diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index 08d0b35..bf94b2a 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -513,10 +513,12 @@ default_floatn_mode (int n, bool extended)
   switch (n)
 	{
 	case 16:
-	  /* We do not use HFmode for _Float16 by default because the
-	 required excess precision support is not present and the
-	 interactions with promotion of the older __fp16 need to
-	 be worked out.  */
+	  /* Always enable _Float16 if we have basic support for the mode.
+	 Targets can control the range and precision of operations on
+	 the _Float16 type using TARGET_C_EXCESS_PRECISION.  */
+#ifdef HAVE_HFmode
+	  cand = HFmode;
+#endif
 	  break;
 
 	case 32:

[Patch 1/11] Add a new target hook for describing excess precision intentions

[James Greenhalgh]

Hi,

This patch introduces TARGET_C_EXCESS_PRECISION. This hook takes a tri-state
argument, one of EXCESS_PRECISION_TYPE_IMPLICIT,
EXCESS_PRECISION_TYPE_STANDARD, EXCESS_PRECISION_TYPE_FAST. Which relate to
the implicit extra precision added by the target, the excess precision that
should be guaranteed for -fexcess-precision=standard, and the excess
precision that should be added for performance under -fexcess-precision=fast .

Bootstrapped and tested in sequence with the other patches in this series
on Arch64, and as a standalone patch on x86_64.

OK?

Thanks
James

---
gcc/

2016-09-30  James Greenhalgh  

* target.def (excess_precision): New hook.
* target.h (flt_eval_method): New.
(excess_precision_type): Likewise.
* targhooks.c (default_excess_precision): New.
* targhooks.h (default_excess_precision): New.
* doc/tm.texi.in (TARGET_EXCESS_PRECISION): New.
* doc/tm.texi: Regenerate.
diff --git a/gcc/coretypes.h b/gcc/coretypes.h
index fe1e984..26b0fa3 100644
--- a/gcc/coretypes.h
+++ b/gcc/coretypes.h
@@ -359,6 +359,24 @@ enum memmodel
   MEMMODEL_SYNC_SEQ_CST = MEMMODEL_SEQ_CST | MEMMODEL_SYNC
 };
 
+/* enums used by the targetm.excess_precision hook.  */
+
+enum flt_eval_method
+{
+  FLT_EVAL_METHOD_UNPREDICTABLE = -1,
+  FLT_EVAL_METHOD_PROMOTE_TO_FLOAT = 0,
+  FLT_EVAL_METHOD_PROMOTE_TO_DOUBLE = 1,
+  FLT_EVAL_METHOD_PROMOTE_TO_LONG_DOUBLE = 2,
+  FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 = 16
+};
+
+enum excess_precision_type
+{
+  EXCESS_PRECISION_TYPE_IMPLICIT,
+  EXCESS_PRECISION_TYPE_STANDARD,
+  EXCESS_PRECISION_TYPE_FAST
+};
+
 /* Support for user-provided GGC and PCH markers.  The first parameter
is a pointer to a pointer, the second a cookie.  */
 typedef void (*gt_pointer_operator) (void *, void *);
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 8a98ba4..0bdae58 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -947,6 +947,10 @@ sign-extend the result to 64 bits.  On such machines, set
 Do not define this macro if it would never modify @var{m}.
 @end defmac
 
+@deftypefn {Target Hook} {enum flt_eval_method} TARGET_C_EXCESS_PRECISION (enum excess_precision_type @var{type})
+Return a value, with the same meaning as @code{FLT_EVAL_METHOD} C that describes which excess precision should be applied.  @var{type} is either @code{EXCESS_PRECISION_TYPE_IMPLICIT}, @code{EXCESS_PRECISION_TYPE_FAST}, or @code{EXCESS_PRECISION_TYPE_STANDARD}.  For @code{EXCESS_PRECISION_TYPE_IMPLICIT}, the target should return which precision and range operations will be implictly evaluated in regardless of the excess precision explicitly added.  For @code{EXCESS_PRECISION_TYPE_STANDARD} and @code{EXCESS_PRECISION_TYPE_FAST}, the target should return the explicit excess precision that should be added depending on the value set for @code{-fexcess-precision=[standard|fast]}.
+@end deftypefn
+
 @deftypefn {Target Hook} machine_mode TARGET_PROMOTE_FUNCTION_MODE (const_tree @var{type}, machine_mode @var{mode}, int *@var{punsignedp}, const_tree @var{funtype}, int @var{for_return})
 Like @code{PROMOTE_MODE}, but it is applied to outgoing function arguments or
 function return values.  The target hook should return the new mode
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index f1cfc86..7c7af33 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -921,6 +921,8 @@ sign-extend the result to 64 bits.  On such machines, set
 Do not define this macro if it would never modify @var{m}.
 @end defmac
 
+@hook TARGET_C_EXCESS_PRECISION
+
 @hook TARGET_PROMOTE_FUNCTION_MODE
 
 @defmac PARM_BOUNDARY
diff --git a/gcc/target.def b/gcc/target.def
index 83373a5..1542692 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -5402,6 +5402,23 @@ DEFHOOK_UNDOC
  machine_mode, (char c),
  default_mode_for_suffix)
 
+DEFHOOK
+(excess_precision,
+ "Return a value, with the same meaning as @code{FLT_EVAL_METHOD} C that\
+ describes which excess precision should be applied.  @var{type} is\
+ either @code{EXCESS_PRECISION_TYPE_IMPLICIT},\
+ @code{EXCESS_PRECISION_TYPE_FAST}, or\
+ @code{EXCESS_PRECISION_TYPE_STANDARD}.  For\
+ @code{EXCESS_PRECISION_TYPE_IMPLICIT}, the target should return which\
+ precision and range operations will be implictly evaluated in regardless\
+ of the excess precision explicitly added.  For\
+ @code{EXCESS_PRECISION_TYPE_STANDARD} and\
+ @code{EXCESS_PRECISION_TYPE_FAST}, the target should return the\
+ explicit excess precision that should be added depending on the\
+ value set for @code{-fexcess-precision=[standard|fast]}.",
+ enum flt_eval_method, (enum excess_precision_type type),
+ default_excess_precision)
+
 HOOK_VECTOR_END (c)
 
 /* Functions specific to the C++ frontend.  */
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index d75650f..08d0b35 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -2110,4 +2110,12 @@ default_max_noce_ifcvt_seq_cost (edge e)
 return BRANCH_COST (true, predictable_p) * 

[Patch 5/11] Add -fpermitted-flt-eval-methods=[c11|ts-18661-3]

[James Greenhalgh]

Hi,

This option is added to control which values of FLT_EVAL_METHOD the
compiler is allowed to set.

ISO/IEC TS 18661-3 defines new permissible values for
FLT_EVAL_METHOD that indicate that operations and constants with
a semantic type that is an interchange or extended format should be
evaluated to the precision and range of that type.  These new values are
a superset of those permitted under C99/C11, which does not specify the
meaning of other positive values of FLT_EVAL_METHOD.  As such, code
conforming to C11 may not have been written expecting the possibility of
the new values.

-fpermitted-flt-eval-methods specifies whether the compiler
should allow only the values of FLT_EVAL_METHOD specified in C99/C11,
or the extended set of values specified in ISO/IEC TS 18661-3.

The two possible values this option can take are "c11" or "ts-18661-3".

The default when in a standards compliant mode (-std=c11 or similar)
is -fpermitted-flt-eval-methods=c11.  The default when in a GNU
dialect (-std=gnu11 or similar) is -fpermitted-flt-eval-methods=ts-18661-3.

I've added two testcases which test that when this option, or a C standards
dialect, would restrict the range of values to {-1, 0, 1, 2}, those are
the only values we see. At this stage in the patch series this trivially
holds for all targets.

Bootstrapped on x86_64 with no issues and tested in series on AArch64.

OK?

Thanks,
James

---
gcc/c-family/

2016-09-30  James Greenhalgh  

* c-opts.c (c_common_post_options): Add logic to handle the default
case for -fpermitted-flt-eval-methods.

gcc/

2016-09-30  James Greenhalgh  

* common.opt (fpermitted-flt-eval-methods): New.
* doc/invoke.texi (-fpermitted-flt-eval-methods): Document it.
* flag_types.h (permitted_flt_eval_methods): New.

gcc/testsuite/

2016-09-30  James Greenhalgh  

* gcc.dg/fpermitted-flt-eval-methods_1.c: New.
* gcc.dg/fpermitted-flt-eval-methods_2.c: New.

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index c5a699d..af8d7fe 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -789,6 +789,18 @@ c_common_post_options (const char **pfilename)
   && flag_unsafe_math_optimizations == 0)
 flag_fp_contract_mode = FP_CONTRACT_OFF;
 
+  /* If we are compiling C, and we are outside of a standards mode,
+ we can permit the new values from ISO/IEC TS 18661-3 for
+ FLT_EVAL_METHOD.  Otherwise, we must restrict the possible values to
+ the set specified in ISO C99/C11.  */
+  if (!flag_iso
+  && !c_dialect_cxx ()
+  && (global_options_set.x_flag_permitted_flt_eval_methods
+	  == PERMITTED_FLT_EVAL_METHODS_DEFAULT))
+flag_permitted_flt_eval_methods = PERMITTED_FLT_EVAL_METHODS_TS_18661;
+  else
+flag_permitted_flt_eval_methods = PERMITTED_FLT_EVAL_METHODS_C11;
+
   /* By default we use C99 inline semantics in GNU99 or C99 mode.  C99
  inline semantics are not supported in GNU89 or C89 mode.  */
   if (flag_gnu89_inline == -1)
diff --git a/gcc/common.opt b/gcc/common.opt
index 0e01577..3a22aa0 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1305,6 +1305,21 @@ Enum(excess_precision) String(fast) Value(EXCESS_PRECISION_FAST)
 EnumValue
 Enum(excess_precision) String(standard) Value(EXCESS_PRECISION_STANDARD)
 
+; Whether we permit the extended set of values for FLT_EVAL_METHOD
+; introduced in ISO/IEC TS 18661-3, or limit ourselves to those in C99/C11.
+fpermitted-flt-eval-methods=
+Common Joined RejectNegative Enum(permitted_flt_eval_methods) Var(flag_permitted_flt_eval_methods) Init(PERMITTED_FLT_EVAL_METHODS_DEFAULT)
+-fpermitted-flt-eval-methods=[c11|ts-18661]	Specify which values of FLT_EVAL_METHOD are permitted.
+
+Enum
+Name(permitted_flt_eval_methods) Type(enum permitted_flt_eval_methods) UnknownError(unknown specification for the set of FLT_EVAL_METHOD values to permit %qs)
+
+EnumValue
+Enum(permitted_flt_eval_methods) String(c11) Value(PERMITTED_FLT_EVAL_METHODS_C11)
+
+EnumValue
+Enum(permitted_flt_eval_methods) String(ts-18661-3) Value(PERMITTED_FLT_EVAL_METHODS_TS_18661)
+
 ffast-math
 Common Optimization
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8a84e4f..9cb0b54 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -375,7 +375,8 @@ Objective-C and Objective-C++ Dialects}.
 -flto-partition=@var{alg} -fmerge-all-constants @gol
 -fmerge-constants -fmodulo-sched -fmodulo-sched-allow-regmoves @gol
 -fmove-loop-invariants -fno-branch-count-reg @gol
--fno-defer-pop -fno-fp-int-builtin-inexact -fno-function-cse @gol
+-fno-defer-pop -fno-fp-int-builtin-inexact @gol
+-fpermitted-flt-eval-methods=@var{standard} -fno-function-cse @gol
 -fno-guess-branch-probability -fno-inline -fno-math-errno -fno-peephole @gol
 -fno-peephole2 -fno-sched-interblock -fno-sched-spec -fno-signed-zeros @gol
 -fno-toplevel-reorder -fno-trapping-math -fno-zero-initialized-in-bss @gol
@@ 

[Patch 0/11] Add support for _Float16 to AArch64

[James Greenhalgh]

Hi,

This patch set enables the _Float16 type specified in ISO/IEC TS 18661-3
for AArch64.

To do this, we first need to update the excess precision logic to support
possibly computing _Float16 values in 16-bit range and precision, and to
set the FLT_EVAL_METHOD macro to "16" as appropriate. That requires some
more expressiveness than we currently get with TARGET_FLT_EVAL_METHOD, so
we first need a new target hook - TARGET_C_EXCESS_PRECISION (patch 1/11),
which we implement in the i386, s390 and m68k back-ends in patches 2-4/11.

However, the meaning of the new value "16" for FLT_EVAL_METHOD is not
specified under C99/C11, and conforming code may have been written assuming
that the only possible values for FLT_EVAL_METHOD were negative values and
{ 0, 1, 2 }. In [patch 5/11] we work around that with a new option -
-fpermitted-flt-eval-methods=[c11|ts-18661-3]. This option will restrict
the compiler to only using the C99/C11 values for FLT_EVAL_METHOD, and is
set to -fpermitted-flt-eval-methods=c11 by default when in a standards
compliant mode like -std=c11.

Patch 6/11 does the work of rewriting the excess precision logic along
the guidelines given in https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00410.html

Patch 7/11 finishes the hookization of TARGET_FLT_EVAL_METHOD by poisoning
the old macro.

Patch 8/11 removes the restriction in targhooks.c:default_floatn_mode that
currently disables HFmode support. This patch is not strictly necessary,
and an alternative route to the same goal would override TARGET_FLOATN_MODE
in AArch64. However, now we've cleaned up the excess precision logic,
I don't believe there is any reason this patch would not be correct.

Patch 9/11 imports the soft-fp changes from
https://sourceware.org/ml/libc-alpha/2016-09/msg00310.html to libgcc.

Patch 10/11 enables these conversion routines for AArch64.

And finally patch 11/11 adds support for the various hooks that the AArch64
back-end requires to turn _Float16 support on.

The patch series as a whole passes a bootstrap and test cycle on x86_64
and AArch64. I've bootstrapped and tested each patch individually on x86_64.
All new tests added and enabled pass as appropriate.

The AArch64 enablement requires
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00268.html

OK?

Thanks,
James

ChangeLogs:

[Patch 1/11] Add a new target hook for describing excess precision intentions

  gcc/

  2016-09-30  James Greenhalgh  

* target.def (excess_precision): New hook.
* target.h (flt_eval_method): New.
(excess_precision_type): Likewise.
* targhooks.c (default_excess_precision): New.
* targhooks.h (default_excess_precision): New.
* doc/tm.texi.in (TARGET_EXCESS_PRECISION): New.
* doc/tm.texi: Regenerate.

[Patch 2/11] Implement TARGET_C_EXCESS_PRECISION for i386

  gcc/

  2016-09-30  James Greenhalgh  

* config/i386/i386.c (ix86_excess_precision): New.
(TARGET_C_EXCESS_PRECISION): Define.

[Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

  gcc/

  2016-09-30  James Greenhalgh  

* config/s390/s390.c (s390_excess_precision): New.
(TARGET_C_EXCESS_PRECISION): Define.

[Patch 4/11] Implement TARGET_C_EXCESS_PRECISION for m68k

  gcc/

  2016-09-30  James Greenhalgh  

* config/m68k/m68k.c (m68k_excess_precision): New.
(TARGET_C_EXCESS_PRECISION): Define.

[Patch 5/11] Add -fpermitted-flt-eval-methods=[c11|ts-18661-3]

  gcc/c-family/

  2016-09-30  James Greenhalgh  

* c-opts.c (c_common_post_options): Add logic to handle the default
case for -fpermitted-flt-eval-methods.

  gcc/

  2016-09-30  James Greenhalgh  

* common.opt (fpermitted-flt-eval-methods): New.
* doc/invoke.texi (-fpermitted-flt-eval-methods): Document it.
* flag_types.h (permitted_flt_eval_methods): New.

  gcc/testsuite/

  2016-09-30  James Greenhalgh  

* gcc.dg/fpermitted-flt-eval-methods_1.c: New.
* gcc.dg/fpermitted-flt-eval-methods_2.c: New.

[Patch 6/11] Migrate excess precision logic to use TARGET_EXCESS_PRECISION

  gcc/

  2016-09-30  James Greenhalgh  

* toplev.c (init_excess_precision): Delete most logic.
* tree.c (excess_precision_type): Rewrite to use
TARGET_EXCESS_PRECISION.
* doc/invoke.texi (-fexcess-precision): Document behaviour in a
more generic fashion.

  gcc/c-family/

  2016-09-30  James Greenhalgh  

* c-common.c (excess_precision_mode_join): New.
(c_ts18661_flt_eval_method): New.
(c_c11_flt_eval_method): Likewise.
(c_flt_eval_method): Likewise.
* c-common.h (excess_precision_mode_join): New.
(c_flt_eval_method): Likewise.
* c-cppbuiltin.c 

Re: Fix missing FALLTHRU comments

[Marek Polacek]

On Fri, Sep 30, 2016 at 06:49:17PM +0200, Jan-Benedict Glaw wrote:
> On Thu, 2016-09-29 18:01:46 +0200, Marek Polacek  wrote:
> > My upcoming fix revealed more places that were missing a fall through 
> > marker.
> > 
> > Bootstrapped/regtested on x86_64-linux, ppc64-linux, and aarch64-linux-gnu 
> > with
> > my fix, applying to trunk.
> > 
> > 2016-09-29  Marek Polacek  
> > 
> > * rtti.c (involves_incomplete_p): Add fall through comment.
> > 
> > * dwarf2out.c (loc_descriptor): Add fall through comment.
> > (add_const_value_attribute): Likewise.
> 
> Maybe gcc/config/alpha/predicates.md:184, too?
> 
> /* ... fall through ...  */
> 
> This showed up on my build robot recently.

Thanks, fixed:

2016-09-30  Marek Polacek  

* config/alpha/predicates.md: Adjust fall through comment.

diff --git gcc/config/alpha/predicates.md gcc/config/alpha/predicates.md
index 24fa3c2..ca14fad 100644
--- gcc/config/alpha/predicates.md
+++ gcc/config/alpha/predicates.md
@@ -181,7 +181,7 @@
 case SUBREG:
   if (register_operand (op, mode))
return 1;
-  /* ... fall through ...  */
+  /* fall through */
 case MEM:
   return ((TARGET_BWX || (mode != HImode && mode != QImode))
  && general_operand (op, mode));


Marek

Re: Fwd: [PATCH] gcc: Fix sysroot relative paths for MinGW

[Jeff Law]

On 09/29/2016 09:21 PM, Tadek Kijkowski wrote:

Can I have plain-text mode, please, gmail?

:-)  Only because you're asking nicely...




 # Directory in which the compiler finds libraries etc.
 libsubdir =
$(libdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix)
 # Directory in which the compiler finds executables
@@ -2751,14 +2763,14 @@
 PREPROCESSOR_DEFINES = \
   -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
   -DFIXED_INCLUDE_DIR=\"$(libsubdir)/include-fixed\" \
-  -DGPLUSPLUS_INCLUDE_DIR=\"$(gcc_gxx_include_dir)\" \
+  -DGPLUSPLUS_INCLUDE_DIR=\"$(call
sysroot_relative_path,$(gcc_gxx_include_dir),$(filter-out
0,$(gcc_gxx_include_dir_add_sysroot)))\" \


So why the $(filter-out 0, )?

I'd really like to avoid being too clever here and write this code in the
most straightforward way possible.



Hmm... that's partially leftover from the abandoned idea to pass
@TARGET_SYSTEM_ROOT@ as second parameter of sysroot_relative_path.
Sysroot is prepended to GPLUSPLUS_INCLUDE_DIR in runtime only if
$(gcc_gxx_include_dir) is 1.
Since sysroot_relative_path checks for non-empty string the easiest
way was to use filter-out. But I agree this way it's confusing.

How about if I change the sysroot_relative_path function to explicitly
check for 1? But still - since $(if) checks for empty string, it will
have to use filter or filter-out.

I think with the improved comments you showed in V2, that'd be fine.




N.B. I'd prefer to use backticks over "$()", but it could clash if
some include paths already contain backtick expressions.
So the concern is we might use backticks to get an evaluation of 
something at build time.  Conceptually one could even create a pathname 
with literal backticks, but I suspect somewhere, somehow that's going to 
fail independent of your change.


Jeff

Re: Fix missing FALLTHRU comments

[Jan-Benedict Glaw]

On Thu, 2016-09-29 18:01:46 +0200, Marek Polacek  wrote:
> My upcoming fix revealed more places that were missing a fall through marker.
> 
> Bootstrapped/regtested on x86_64-linux, ppc64-linux, and aarch64-linux-gnu 
> with
> my fix, applying to trunk.
> 
> 2016-09-29  Marek Polacek  
> 
>   * rtti.c (involves_incomplete_p): Add fall through comment.
> 
>   * dwarf2out.c (loc_descriptor): Add fall through comment.
>   (add_const_value_attribute): Likewise.

Maybe gcc/config/alpha/predicates.md:184, too?

/* ... fall through ...  */

This showed up on my build robot recently.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: Friends are relatives you make for yourself.
the second  :


signature.asc
Description: Digital signature

Re: C/C++ PATCH to implement -Wpointer-compare warning (PR c++/64767)

[Marek Polacek]

On Fri, Sep 23, 2016 at 10:31:33AM -0400, Jason Merrill wrote:
> On Fri, Sep 23, 2016 at 9:15 AM, Marek Polacek  wrote:
> > On Wed, Sep 21, 2016 at 03:52:09PM -0400, Jason Merrill wrote:
> >> On Mon, Sep 19, 2016 at 2:49 PM, Jason Merrill  wrote:
> >> > I suppose that an INTEGER_CST of character type is necessarily a
> >> > character constant, so adding a check for !char_type_p ought to do the
> >> > trick.
> >>
> >> Indeed it does.  I'm checking this in:
> >
> > Nice, thanks.  What about the original patch?  We still need to warn
> > (or error for C++11) for pointer comparisons.
> 
> If we still accept pointer comparisons in C++, that's another bug with
> treating \0 as a null pointer constant.  This seems to be because
> ocp_convert of \0 to int produces an INTEGER_CST indistinguishable
> from literal 0.

I was trying to fix this in ocp_convert, by using NOP_EXPRs, but that wasn't
successful.  But since we're interested in ==/!=, I think this can be fixed
easily in cp_build_binary_op.  Actually, all that seems to be needed is using
orig_op as the argument to null_ptr_cst_p, but that wouldn't give the correct
diagnostics, so I did this.  By checking orig_op we can see if the operands are
character literals or not, because orig_op is an operand before the default
conversions.

Curiously, nothing in the testsuite broke.

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

2016-09-30  Marek Polacek  

Core 903
* typeck.c (cp_build_binary_op) [EQ_EXPR]: Diagnose invalid pointer
conversions.

* g++.dg/cpp0x/nullptr37.C: New test.

diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 617ca55..2e6f44e 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -4584,6 +4584,14 @@ cp_build_binary_op (location_t location,
  else
result_type = type0;
 
+ if (null_ptr_cst_p (op1) && !null_ptr_cst_p (orig_op1))
+   {
+ if (complain & tf_error)
+   permerror (input_location, "ISO C++11 only allows pointer "
+  "conversions for integer literals");
+ else
+   return error_mark_node;
+   }
  warn_for_null_address (location, op0, complain);
}
   else if (((code1 == POINTER_TYPE || TYPE_PTRDATAMEM_P (type1))
@@ -4598,6 +4606,14 @@ cp_build_binary_op (location_t location,
  else
result_type = type1;
 
+ if (null_ptr_cst_p (op0) && !null_ptr_cst_p (orig_op0))
+   {
+ if (complain & tf_error)
+   permerror (input_location, "ISO C++11 only allows pointer "
+  "conversions for integer literals");
+ else
+   return error_mark_node;
+   }
  warn_for_null_address (location, op1, complain);
}
   else if ((code0 == POINTER_TYPE && code1 == POINTER_TYPE)
diff --git gcc/testsuite/g++.dg/cpp0x/nullptr37.C 
gcc/testsuite/g++.dg/cpp0x/nullptr37.C
index e69de29..17c33d1 100644
--- gcc/testsuite/g++.dg/cpp0x/nullptr37.C
+++ gcc/testsuite/g++.dg/cpp0x/nullptr37.C
@@ -0,0 +1,78 @@
+/* PR c++/64767 */
+// { dg-do compile { target c++11 } }
+
+int
+f1 (int *p, int **q)
+{
+  int r = 0;
+
+  r += p == '\0'; /* { dg-error "ISO C\\+\\+11 only allows pointer conversions 
for integer literals" } */
+  r += p == L'\0'; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += p == u'\0'; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += p == U'\0'; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += p != '\0'; /* { dg-error "ISO C\\+\\+11 only allows pointer conversions 
for integer literals" } */
+  r += p != L'\0'; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += p != u'\0'; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += p != U'\0'; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+
+  r += '\0' == p; /* { dg-error "ISO C\\+\\+11 only allows pointer conversions 
for integer literals" } */
+  r += L'\0' == p; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += u'\0' == p; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += U'\0' == p; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += '\0' != p; /* { dg-error "ISO C\\+\\+11 only allows pointer conversions 
for integer literals" } */
+  r += L'\0' != p; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += u'\0' != p; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer literals" } */
+  r += U'\0' != p; /* { dg-error "ISO C\\+\\+11 only allows pointer 
conversions for integer 

Re: Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion

[Andrew Haley]

On 30/09/16 17:38, Rainer Orth wrote:
> but both Per and Tom are still libcpp maintainers, so no need to add
> them to the write-after-approval list.

Ooh, I had no idea.  Will fix, thanks.

Andrew.

Re: Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion

[Rainer Orth]

Hi Andrew,

> Pushed.
>
> 2016-09-30  Andrew Haley  
>
> * MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to
> write-after approval after GCJ deletion.

but both Per and Tom are still libcpp maintainers, so no need to add
them to the write-after-approval list.

Rainer

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

Re: [PATCH] fixincludes: fix fixincludes for MinGW

[Jeff Law]

On 09/30/2016 10:18 AM, Bruce Korb wrote:

Hi Tadek,

Looks good to me.  Thank you.
Clear to send (push).

Committed on behalf of Tadek.

Thanks,
jeff

Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion

[Andrew Haley]

Pushed.

2016-09-30  Andrew Haley  

* MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to
write-after approval after GCJ deletion.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 240658)
+++ MAINTAINERS (working copy)
@@ -155,9 +155,6 @@
 c++Jason Merrill   
 c++Nathan Sidwell  
 go Ian Lance Taylor
-java   Per Bothner 
-java   Andrew Haley
-java   Tom Tromey  
 objective-c/c++Mike Stump  
 objective-c/c++Iain Sandoe 

@@ -352,6 +349,7 @@
 Andrea Bona
 Paolo Bonzini  
 Neil Booth 
+Per Bothner 
 Robert Bowdidge
 Joel Brobecker 
 Dave Brolley   
@@ -425,6 +423,7 @@
 Wei Guozhi 
 Mostafa Hagog  
 Olivier Hainque
+Andrew Haley   
 Stuart Hastings
 Michael Haubenwallner  

 Pat Haugen 
@@ -608,6 +607,7 @@
 Philipp Tomsich

 Konrad Trifunovic  
 Markus Trippelsdorf
+Tom Tromey  
 Martin Uecker  
 David Ung  
 Neil Vachharajani  

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

[Jakub Jelinek]

On Fri, Sep 30, 2016 at 10:10:55AM -0600, Martin Sebor wrote:
> I haven't been following the discussion very closely so I may have
> missed that what I'm about to suggest has been discussed and rejected
> for some valid reason, but if not let me try.
> 
> It seems to me that the ultimate, long term goal should be to have
> actively maintained code bases gradually migrate away from the
> various fallthrough comments and to the new attribute.  Under that
> premise, I think introducing a warning that's on the permissive end
> of the spectrum (say outside of -Wall, or even outside of -Wextra,
> and/or disabling the checker at the first sight of a comment) would
> obviate the concern of needlessly breaking working code and let
> users start adopting the warning on their own schedules.  The next
> major release of GCC after 7 could increase the sensitivity of the
> warning (e.g., by adding it -Wextra, and/or checking for the words
> fall though in the comments, etc.), and the next one could make it
> even more strict.  With GCC's one year release cycle this approach
> would give even users who adopt the latest compiler two to three
> years to make the transition.

That is IMHO a bad idea, because almost nobody will really use it and the
warning option will bitrot.  The reason why we've added parsing of the most
common comments was exactly to be able to enable it already in -Wextra.
clang has it outside of -Wextra and (almost) nobody really started adopting
the attributes.

The option to have different levels of -Wimplicit-fallthrough= has been
proposed, that would allow projects to choose if they only allow attributes
to disable the warning, or also some very strict set of comments, or more
relaxed set of comments, or perhaps any comment before the label.

Jakub

Re: [PATCH] fixincludes: fix fixincludes for MinGW

[Bruce Korb]

Hi Tadek,

Looks good to me.  Thank you.
Clear to send (push).

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

[Martin Sebor]

I haven't been following the discussion very closely so I may have
missed that what I'm about to suggest has been discussed and rejected
for some valid reason, but if not let me try.

It seems to me that the ultimate, long term goal should be to have
actively maintained code bases gradually migrate away from the
various fallthrough comments and to the new attribute.  Under that
premise, I think introducing a warning that's on the permissive end
of the spectrum (say outside of -Wall, or even outside of -Wextra,
and/or disabling the checker at the first sight of a comment) would
obviate the concern of needlessly breaking working code and let
users start adopting the warning on their own schedules.  The next
major release of GCC after 7 could increase the sensitivity of the
warning (e.g., by adding it -Wextra, and/or checking for the words
fall though in the comments, etc.), and the next one could make it
even more strict.  With GCC's one year release cycle this approach
would give even users who adopt the latest compiler two to three
years to make the transition.

Martin

Re: Use version namespace in normal mode

[Jonathan Wakely]

On 29/09/16 21:59 +0200, François Dumont wrote:

Hi

   I think _GLIBCXX_BEGIN_NAMESPACE_ALGO should default to 
_GLIBCXX_BEGIN_NAMESPACE_VERSION when parallel mode is not active. 
Same for _GLIBCXX_BEGIN_NAMESPACE_CONTAINER, no ?


Hmm, yes, I think this is correct, otherwise we're missing the VERSION
namespace in normal mode. But it seems we've always been missing it
since those macros were introduced in GCC 4.6 so I'd like to
investigate the consequences for gnu-versioned-namespace more
carefuly.


   * include/bits/c++config (_GLIBCXX_BEGIN_NAMESPACE_ALGO)
   (_GLIBCXX_END_NAMESPACE_ALGO): Default to respectively
   _GLIBCXX_BEGIN_NAMESPACE_VERSION and _GLIBCXX_END_NAMESPACE_VERSION
   when parallel mode is not active.
   (_GLIBCXX_BEGIN_NAMESPACE_CONTAINER, _GLIBCXX_END_NAMESPACE_CONTAINER):
   Likewise.

   Ok to commit after normal check ? Should I rebuild library with 
versioned namespace activated ?


Any change affecting the NAMESPACE_VERSION macros should be tested
with the gnu-versioned-namespace, since those macros are only used for
that mode.

But it can't be tested currently, see PR 77794. So let's wait until
I've fixed 77794, when we can test it.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 05/09/16 17:25, Gerald Pfeifer wrote:
> And here is the patch for the web pages.
> 
> Note I did not include all the removed java/* contents.  Is there
> anything particular you'd like to retain there?

No, please delete it all.

Thanks,

Andrew.

Re: [PATCH 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

[Denys Vlasenko]

On 09/30/2016 01:20 PM, Bernd Schmidt wrote:

On 09/29/2016 07:32 PM, Denys Vlasenko wrote:

On 09/29/2016 04:45 PM, Bernd Schmidt wrote:

On 09/28/2016 02:57 PM, Denys Vlasenko wrote:

-  /* Comes from final.c -- no real reason to change it.  */
-#define MAX_CODE_ALIGN 16
-
 case OPT_malign_loops_:
   warning_at (loc, 0, "-malign-loops is obsolete, use
-falign-loops");
-  if (value > MAX_CODE_ALIGN)
-error_at (loc, "-malign-loops=%d is not between 0 and %d",
-  value, MAX_CODE_ALIGN);
-  else
-opts->x_align_loops = 1 << value;
   return true;


That does seem to be a functional change. I'll defer to Uros.


It would be awkward to translate -malign-loops=%d et al
to comma-separated string format.
Since this warning is there for some 15 years already,
anyone who actually cares should have converted to new options
long ago.


Hmm, if it's been 15 years, maybe it's time to remove these. Could you submit a 
patch separately?


Sure.


-  if (opts->x_align_functions <= 0)
+  if (opts->x_flag_align_functions && !opts->x_str_align_functions)


Are these conditions really equivalent? It looks like zero was
the default even when no -falign-functions was specified.
 Or is that overriden by init_alignments?


 {
-  if (opts->x_align_loops == 0)
+  /* -falign-foo without argument: supply one */
+  if (opts->x_flag_align_loops && !opts->x_str_align_loops)


Same here.


The execution flow for option parsing is somewhat convoluted, no doubt.

I found it experimentally that these are locations where
default alignment parameters are set when -falign-functions
is given with no arguments (or when it is implied by -O2).


I applied your latest two patches to experiment with them, and I see different
 behaviour before and after on x86_64-linux. There seems to be a difference
 in function alignment and label alignment at -O2.


Let me try harder, I was only checking -ffunction-alignment...

My test program:

int g();
int f(int i)
{
i *= 3;
while (--i > 100) {
 L1:
if (g())
goto L1;
if (g())
goto L2;
}
return i;
 L2:
return 123;
}

Before-and-after "gcc -O2 -S" assembly (after the patch is on the right):

.text   .text
.p2align 4,,15  .p2align 4,,15
.globl  f   .p2align 3
.type   f, @function.globl  f
f:  .type   f, @function
.LFB0:  f:
.cfi_startproc  .LFB0:
pushq   %rbx.cfi_startproc
.cfi_def_cfa_offset 16  pushq   %rbx
.cfi_offset 3, -16  .cfi_def_cfa_offset 16
leal(%rdi,%rdi,2), %ebx .cfi_offset 3, -16
.p2align 4,,10  leal(%rdi,%rdi,2), %ebx
.p2align 3  .p2align 4,,10
.L2:.L2:
subl$1, %ebxsubl$1, %ebx
cmpl$100, %ebx  cmpl$100, %ebx
jle .L1 jle .L1
.p2align 4,,10  .p2align 4,,10
.p2align 3  .L3:
.L3:xorl%eax, %eax
xorl%eax, %eax  callg
callg   testl   %eax, %eax
testl   %eax, %eax  jne .L3
jne .L3 callg
callg   testl   %eax, %eax
testl   %eax, %eax  je  .L2
je  .L2 movl$123, %ebx
movl$123, %ebx  .L4:
.L4:.L1:
.L1:movl%ebx, %eax
movl%ebx, %eax  popq%rbx
popq%rbx.cfi_def_cfa_offset 8
.cfi_def_cfa_offset 8   ret
ret .cfi_endproc
.cfi_endproc.LFE0:
.LFE0:


Yes, I see differences. ".p2align 3" appeared in function alignment.
The reason is that old code had an optimization - it noticed that
".p2align 4,,15" _always_ aligns (because 2^4=15+1), thus ".p2align 3"
is superfluous. My patch doesn't do that. I fixed this already
in the next version of the patch I'm going to send.

The other difference is that ".p2align 4,,10" is no longer followed
by ".p2align 3". Well... this one is harder to make happen.
It comes from here in gcc/final.c:

case CODE_LABEL:
  /* The target port might emit labels in the output function for
 some insn, e.g. sh.c 

Re: [PATCH][v4] GIMPLE store merging pass

[Kyrill Tkachov]

On 30/09/16 15:36, Kyrill Tkachov wrote:

Hi Richard,

On 29/09/16 11:45, Richard Biener wrote:



+
+  /* In some cases get_inner_reference may return a
+ MEM_REF [ptr + byteoffset].  For the purposes of this pass
+ canonicalize the base_addr to MEM_REF [ptr] and take
+ byteoffset into account in the bitpos.  This occurs in
+ PR 23684 and this way we can catch more chains.  */
+  if (TREE_CODE (base_addr) == MEM_REF
+  && POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (base_addr, 0)))
+  && TREE_CODE (TREE_OPERAND (base_addr, 1)) == INTEGER_CST

This is always an INTEGER_CST.


+  && tree_fits_shwi_p (TREE_OPERAND (base_addr, 1))

This will never allow negative offsets (but maybe this is a good thing?)

)

+{
+  bitpos += tree_to_shwi (TREE_OPERAND (base_addr, 1))
+* BITS_PER_UNIT;

this multiplication may overflow.  There is mem_ref_offset () which
you should really use here, see get_inner_reference itself (and
how to translate back from offset_int to HOST_WIDE_INT if it fits).


+
+  base_addr = fold_build2 (MEM_REF, TREE_TYPE (base_addr),
+   TREE_OPERAND (base_addr, 0),
+   build_zero_cst (TREE_TYPE (
+ TREE_OPERAND (base_addr, 1;

Ugh, building a tree node ... you could use TREE_OPERAND (base_addr, 0)
as base_addr instead?


This didn't work for me because aliasing info was lost.
So in the example:
void
foo2 (struct bar *p, struct bar *p2)
{
  p->b = 0xff;
  p2->b = 0xa;
  p->a = 0xf;
  p2->c = 0xc;
  p->c = 0xff;
  p2->d = 0xbf;
  p->d = 0xfff;
}

we end up merging p->b with p->a even though the p2->b store may alias.
We'll record the base objects as being 'p' and 'p2' whereas with my approach
we record them as '*p' and '*p2'. I don't suppose I could just do:
TREE_OPERAND (base_addr, 1) = build_zero_cst (TREE_TYPE (TREE_OPERAND 
(base_addr, 1)));
?



Although I think I could try to make it work by using ptr_derefs_may_alias_p in 
the alias checks
a bit more. I'll see what I can do.

Kyrill


Thanks,
Kyrill




+}
+
+  struct imm_store_chain_info **chain_info
+= m_stores.get (base_addr);
+
+  if (!invalid)
+{
+  store_immediate_info *info;
+  if (chain_info)
+{
+  info = new store_immediate_info (
+bitsize, bitpos, rhs, lhs, stmt,
+(*chain_info)->m_store_info.length ());
+  if (dump_file)
+{
+  fprintf (dump_file,
+   "Recording immediate store from stmt:\n");
+  print_gimple_stmt (dump_file, stmt, 0, 0);
+}
+  (*chain_info)->m_store_info.safe_push (info);
+  continue;
+}
+
+  /* Store aliases any existing chain?  */
+  terminate_all_aliasing_chains (lhs, base_addr, stmt);
+
+  /* Start a new chain.  */
+  struct imm_store_chain_info *new_chain
+= new imm_store_chain_info;
+  info = new store_immediate_info (bitsize, bitpos, rhs, lhs,
+   stmt, 0);
+  new_chain->m_store_info.safe_push (info);
+  m_stores.put (base_addr, new_chain);
+  if (dump_file)
+{
+  fprintf (dump_file,
+   "Starting new chain with statement:\n");
+  print_gimple_stmt (dump_file, stmt, 0, 0);
+  fprintf (dump_file, "The base object is:\n");
+  print_generic_expr (dump_file, base_addr, 0);
+  fprintf (dump_file, "\n");
+}
+}
+  else
+terminate_all_aliasing_chains (lhs, base_addr, stmt);
+
+  continue;
+}
+
+  terminate_all_aliasing_chains (NULL_TREE, NULL_TREE, stmt);
+}
+  terminate_and_process_all_chains (bb);
+}
+  return 0;
+}
+
+} // anon namespace
+
+/* Construct and return a store merging pass object.  */
+
+gimple_opt_pass *
+make_pass_store_merging (gcc::context *ctxt)
+{
+  return new pass_store_merging (ctxt);
+}
diff --git a/gcc/opts.c b/gcc/opts.c
index 45f1f89c..e63d7e4 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -463,6 +463,7 @@ static const struct default_options default_options_table[] 
=
  { OPT_LEVELS_1_PLUS, OPT_ftree_dse, NULL, 1 },
  { OPT_LEVELS_1_PLUS, OPT_ftree_ter, NULL, 1 },
  { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_ftree_sra, NULL, 1 },
+{ OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_fstore_merging, NULL, 1 },

Please leave it to -O[2s]+ -- the chain invalidation is quadratic and
-O1 should work well even for gigantic basic blocks.

Overall the pass looks quite well with the comments addressed.

Thanks,
Richard.


  { OPT_LEVELS_1_PLUS, OPT_ftree_fre, NULL, 1 },
  { OPT_LEVELS_1_PLUS, OPT_ftree_copy_prop, NULL, 1 },
  { OPT_LEVELS_1_PLUS, OPT_ftree_sink, NULL, 1 },
diff --git a/gcc/params.def b/gcc/params.def
index 8907aa4..e63e594 100644
--- 

Re: [PATCH][v4] GIMPLE store merging pass

[Kyrill Tkachov]

Hi Richard,

On 29/09/16 11:45, Richard Biener wrote:



+
+ /* In some cases get_inner_reference may return a
+MEM_REF [ptr + byteoffset].  For the purposes of this pass
+canonicalize the base_addr to MEM_REF [ptr] and take
+byteoffset into account in the bitpos.  This occurs in
+PR 23684 and this way we can catch more chains.  */
+ if (TREE_CODE (base_addr) == MEM_REF
+ && POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (base_addr, 0)))
+ && TREE_CODE (TREE_OPERAND (base_addr, 1)) == INTEGER_CST

This is always an INTEGER_CST.


+ && tree_fits_shwi_p (TREE_OPERAND (base_addr, 1))

This will never allow negative offsets (but maybe this is a good thing?)

)

+   {
+ bitpos += tree_to_shwi (TREE_OPERAND (base_addr, 1))
+   * BITS_PER_UNIT;

this multiplication may overflow.  There is mem_ref_offset () which
you should really use here, see get_inner_reference itself (and
how to translate back from offset_int to HOST_WIDE_INT if it fits).


+
+ base_addr = fold_build2 (MEM_REF, TREE_TYPE (base_addr),
+  TREE_OPERAND (base_addr, 0),
+  build_zero_cst (TREE_TYPE (
+TREE_OPERAND (base_addr, 1;

Ugh, building a tree node ... you could use TREE_OPERAND (base_addr, 0)
as base_addr instead?


This didn't work for me because aliasing info was lost.
So in the example:
void
foo2 (struct bar *p, struct bar *p2)
{
  p->b = 0xff;
  p2->b = 0xa;
  p->a = 0xf;
  p2->c = 0xc;
  p->c = 0xff;
  p2->d = 0xbf;
  p->d = 0xfff;
}

we end up merging p->b with p->a even though the p2->b store may alias.
We'll record the base objects as being 'p' and 'p2' whereas with my approach
we record them as '*p' and '*p2'. I don't suppose I could just do:
TREE_OPERAND (base_addr, 1) = build_zero_cst (TREE_TYPE (TREE_OPERAND 
(base_addr, 1)));
?

Thanks,
Kyrill




+   }
+
+ struct imm_store_chain_info **chain_info
+   = m_stores.get (base_addr);
+
+ if (!invalid)
+   {
+ store_immediate_info *info;
+ if (chain_info)
+   {
+ info = new store_immediate_info (
+   bitsize, bitpos, rhs, lhs, stmt,
+   (*chain_info)->m_store_info.length ());
+ if (dump_file)
+   {
+ fprintf (dump_file,
+  "Recording immediate store from stmt:\n");
+ print_gimple_stmt (dump_file, stmt, 0, 0);
+   }
+ (*chain_info)->m_store_info.safe_push (info);
+ continue;
+   }
+
+ /* Store aliases any existing chain?  */
+ terminate_all_aliasing_chains (lhs, base_addr, stmt);
+
+ /* Start a new chain.  */
+ struct imm_store_chain_info *new_chain
+   = new imm_store_chain_info;
+ info = new store_immediate_info (bitsize, bitpos, rhs, lhs,
+  stmt, 0);
+ new_chain->m_store_info.safe_push (info);
+ m_stores.put (base_addr, new_chain);
+ if (dump_file)
+   {
+ fprintf (dump_file,
+  "Starting new chain with statement:\n");
+ print_gimple_stmt (dump_file, stmt, 0, 0);
+ fprintf (dump_file, "The base object is:\n");
+ print_generic_expr (dump_file, base_addr, 0);
+ fprintf (dump_file, "\n");
+   }
+   }
+ else
+   terminate_all_aliasing_chains (lhs, base_addr, stmt);
+
+ continue;
+   }
+
+ terminate_all_aliasing_chains (NULL_TREE, NULL_TREE, stmt);
+   }
+  terminate_and_process_all_chains (bb);
+}
+  return 0;
+}
+
+} // anon namespace
+
+/* Construct and return a store merging pass object.  */
+
+gimple_opt_pass *
+make_pass_store_merging (gcc::context *ctxt)
+{
+  return new pass_store_merging (ctxt);
+}
diff --git a/gcc/opts.c b/gcc/opts.c
index 45f1f89c..e63d7e4 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -463,6 +463,7 @@ static const struct default_options default_options_table[] 
=
  { OPT_LEVELS_1_PLUS, OPT_ftree_dse, NULL, 1 },
  { OPT_LEVELS_1_PLUS, OPT_ftree_ter, NULL, 1 },
  { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_ftree_sra, NULL, 1 },
+{ OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_fstore_merging, NULL, 1 },

Please leave it to -O[2s]+ -- the chain invalidation is quadratic and
-O1 should work well even for gigantic basic blocks.

Overall the pass looks quite well with the 

[gomp4] remove some tile tests

[Nathan Sidwell]

In implementing tile I discovered two existing runtime tile tests.  These were 
only passing because tile was completely ignored.  One of them exposes a latent 
bug in collapse, in my WIP, but I don't want to get distracted by that right now.


Better to have tile tests test tile tiles.

nathan
2016-09-30  Nathan Sidwell  

	* testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c: Remove
	tile test.
	* testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.h: Likewise.
	* testsuite/libgomp.oacc-fortran/kernels-loop-1.f90: Likewise.

Index: testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c
===
--- testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c	(revision 240654)
+++ testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.c	(working copy)
@@ -29,12 +29,10 @@ main ()
   || test_none_auto ()
   || test_none_independent ()
   || test_none_seq ()
-  || test_none_tile ()
   || test_gangs_none ()
   || test_gangs_auto ()
   || test_gangs_independent ()
-  || test_gangs_seq ()
-  || test_gangs_tile ())
+  || test_gangs_seq ())
 abort ();
   return 0;
 }
Index: testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.h
===
--- testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.h	(revision 240654)
+++ testsuite/libgomp.oacc-c-c++-common/parallel-loop-1.h	(working copy)
@@ -18,8 +18,3 @@
 #include "parallel-loop-2.h"
 #undef S
 #undef N
-#define S tile(*)
-#define N(x) M(x, G, tile)
-#include "parallel-loop-2.h"
-#undef S
-#undef N
Index: testsuite/libgomp.oacc-fortran/kernels-loop-1.f90
===
--- testsuite/libgomp.oacc-fortran/kernels-loop-1.f90	(revision 240654)
+++ testsuite/libgomp.oacc-fortran/kernels-loop-1.f90	(working copy)
@@ -54,17 +54,6 @@ program loops
 
   call check (a, b, n)
 
-  ! PRESENT_OR_COPY
-
-  !$acc kernels pcopy (a)
-  !$acc loop tile (*)
-  do i = 1, n
- a(i) = i
-  end do
-  !$acc end kernels
-
-  call check (a, b, n)
-
 end program loops
 
 subroutine check (a, b, n)

Re:[PATCH] [ARC] Disable compact casesi patterns for arcv2

[Claudiu Zissulescu]

Please find the updated patch,
Claudiu

gcc/
2016-05-09  Claudiu Zissulescu  

* common/config/arc/arc-common.c (arc_option_optimization_table):
Remove compact casesi option.
* config/arc/arc.c (arc_override_options): Use compact casesi
option only for pre-ARCv2 cores.
* doc/invoke.texi (mcompact-casesi): Update text.
---
 gcc/common/config/arc/arc-common.c |  1 -
 gcc/config/arc/arc.c   | 11 +++
 gcc/doc/invoke.texi|  4 ++--
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/gcc/common/config/arc/arc-common.c 
b/gcc/common/config/arc/arc-common.c
index f5b9c6d..5b687fb 100644
--- a/gcc/common/config/arc/arc-common.c
+++ b/gcc/common/config/arc/arc-common.c
@@ -56,7 +56,6 @@ static const struct default_options 
arc_option_optimization_table[] =
 { OPT_LEVELS_ALL, OPT_mbbit_peephole, NULL, 1 },
 { OPT_LEVELS_SIZE, OPT_mq_class, NULL, 1 },
 { OPT_LEVELS_SIZE, OPT_mcase_vector_pcrel, NULL, 1 },
-{ OPT_LEVELS_SIZE, OPT_mcompact_casesi, NULL, 1 },
 { OPT_LEVELS_NONE, 0, NULL, 0 }
   };
 
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 2b25b0b..5e8d6b4 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -858,6 +858,17 @@ arc_override_options (void)
   if (arc_size_opt_level == 3)
 optimize_size = 1;
 
+  /* Compact casesi is not a valid option for ARCv2 family.  */
+  if (TARGET_V2
+  && TARGET_COMPACT_CASESI)
+{
+  warning (0, "compact-casesi is not applicable to ARCv2");
+  TARGET_COMPACT_CASESI = 0;
+}
+  else if (optimize_size == 1
+  && !global_options_set.x_TARGET_COMPACT_CASESI)
+TARGET_COMPACT_CASESI = 1;
+
   if (flag_pic)
 target_flags |= MASK_NO_SDATA_SET;
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6767462..05f565d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14255,8 +14255,8 @@ This is the default for @option{-Os}.
 
 @item -mcompact-casesi
 @opindex mcompact-casesi
-Enable compact casesi pattern.
-This is the default for @option{-Os}.
+Enable compact casesi pattern.  This is the default for @option{-Os},
+and only available for ARCv1 cores.
 
 @item -mno-cond-exec
 @opindex mno-cond-exec
-- 
1.9.1

libgo patch committed: Copy locking code from Go 1.7 master library

[Ian Lance Taylor]

This patch to libgo copies the locking code from the Go 1.7 master
library, replacing C code for locking with Go code.  The result is
more efficient on most systems, though it is essentially the same on
GNU/Linux.

Add a shell script mkrsysinfo.sh to generate the runtime_sysinfo.go
file, so that we can get Go copies of the system time structures and
other types.

As part of this change, tweak the compiler so that when compiling the
runtime package the address operator does not cause local variables to
escape.  When the gc compiler compiles the runtime, an escaping local
variable is treated as an error.  We should implement that, instead of
this change, when escape analysis is turned on.  This is for
correctness: there are places in the runtime where we must not
allocate memory unintentionally.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu and
i386-sun-solaris.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 240609)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-e51657a576367c7a498c94baf985b79066fc082a
+f3fb9bf2d5a009a707962a416fcd1a8435756218
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 240453)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -3787,6 +3787,13 @@ Unary_expression::do_flatten(Gogo* gogo,
   if ((n->encoding() & ESCAPE_MASK) == int(Node::ESCAPE_NONE))
this->escapes_ = false;
 
+  // When compiling the runtime, the address operator does not
+  // cause local variables to escapes.  When escape analysis
+  // becomes the default, this should be changed to make it an
+  // error if we have an address operator that escapes.
+  if (gogo->compiling_runtime() && gogo->package_name() == "runtime")
+   this->escapes_ = false;
+
   Named_object* var = NULL;
   if (this->expr_->var_expression() != NULL)
var = this->expr_->var_expression()->named_object();
Index: gcc/go/gofrontend/gogo.cc
===
--- gcc/go/gofrontend/gogo.cc   (revision 240559)
+++ gcc/go/gofrontend/gogo.cc   (working copy)
@@ -4480,6 +4480,19 @@ Gogo::write_c_header()
++p)
 {
   Named_object* no = *p;
+
+  // Skip names that start with underscore followed by something
+  // other than an uppercase letter, as when compiling the runtime
+  // package they are mostly types defined by mkrsysinfo.sh based
+  // on the C system header files.  We don't need to translate
+  // types to C and back to Go.  But do accept the special cases
+  // _defer and _panic.
+  std::string name = Gogo::unpack_hidden_name(no->name());
+  if (name[0] == '_'
+ && (name[1] < 'A' || name[1] > 'Z')
+ && (name != "_defer" && name != "_panic"))
+   continue;
+
   if (no->is_type() && no->type_value()->struct_type() != NULL)
types.push_back(no);
   if (no->is_const() && no->const_value()->type()->integer_type() != NULL)
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 240588)
+++ libgo/Makefile.am   (working copy)
@@ -396,9 +396,9 @@ rtems_task_variable_add_file =
 endif
 
 if LIBGO_IS_LINUX
-runtime_lock_files = runtime/lock_futex.c runtime/thread-linux.c
+runtime_thread_files = runtime/thread-linux.c
 else
-runtime_lock_files = runtime/lock_sema.c runtime/thread-sema.c
+runtime_thread_files = runtime/thread-sema.c
 endif
 
 if LIBGO_IS_LINUX
@@ -502,7 +502,6 @@ runtime_files = \
runtime/go-varargs.c \
runtime/env_posix.c \
runtime/heapdump.c \
-   $(runtime_lock_files) \
runtime/mcache.c \
runtime/mcentral.c \
$(runtime_mem_file) \
@@ -518,6 +517,7 @@ runtime_files = \
runtime/runtime.c \
runtime/signal_unix.c \
runtime/thread.c \
+   $(runtime_thread_files) \
runtime/yield.c \
$(rtems_task_variable_add_file) \
chan.c \
@@ -633,12 +633,8 @@ s-version: Makefile
$(STAMP) $@
 
 runtime_sysinfo.go: s-runtime_sysinfo; @true
-s-runtime_sysinfo: sysinfo.go
-   rm -f tmp-runtime_sysinfo.go
-   echo 'package runtime' > tmp-runtime_sysinfo.go
-   echo >> tmp-runtime_sysinfo.go
-   grep 'const _sizeof_ucontext_t ' sysinfo.go >> tmp-runtime_sysinfo.go
-   grep 'type _sigset_t ' sysinfo.go >> tmp-runtime_sysinfo.go
+s-runtime_sysinfo: $(srcdir)/mkrsysinfo.sh gen-sysinfo.go
+   $(SHELL) $(srcdir)/mkrsysinfo.sh
$(SHELL) $(srcdir)/mvifdiff.sh tmp-runtime_sysinfo.go runtime_sysinfo.go
$(STAMP) $@
 
Index: libgo/configure.ac

[PATCH] Remove use of std::abs in experimental::{gcd,lcm}

[Jonathan Wakely]

std::abs isn't suitable for these functions because we need something
that works in constexpr functions and with unsigned types.

Also,  is supposed to include .

PR libstdc++/77801
* include/experimental/numeric: Include .
(__abs): Define.
(gcd, lcm): Use __abs instead of std::abs.
* testsuite/experimental/numeric/77801.cc: New test.
* testsuite/experimental/numeric/gcd.cc: Test unsigned inputs.
* testsuite/experimental/numeric/lcm.cc: Likewise.

Tested powerpc64le-linux, committed to trunk. Backport to gcc-6
coming too.

commit 49396c6b134c5994e6a7e5dff766dc8cf1290dc1
Author: Jonathan Wakely 
Date:   Fri Sep 30 14:20:10 2016 +0100

Remove use of std::abs in experimental::{gcd,lcm}

PR libstdc++/77801
* include/experimental/numeric: Include .
(__abs): Define.
(gcd, lcm): Use __abs instead of std::abs.
* testsuite/experimental/numeric/77801.cc: New test.
* testsuite/experimental/numeric/gcd.cc: Test unsigned inputs.
* testsuite/experimental/numeric/lcm.cc: Likewise.

diff --git a/libstdc++-v3/include/experimental/numeric 
b/libstdc++-v3/include/experimental/numeric
index 21878f3..5089772 100644
--- a/libstdc++-v3/include/experimental/numeric
+++ b/libstdc++-v3/include/experimental/numeric
@@ -39,8 +39,8 @@
 # include 
 #else
 
+#include 
 #include 
-#include 
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -52,6 +52,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #define __cpp_lib_experimental_gcd_lcm 201411
 
+  // std::abs is not constexpr and doesn't support unsigned integers.
+  template
+constexpr
+enable_if_t<__and_, is_signed<_Tp>>::value, _Tp>
+__abs(_Tp __val)
+{ return __val < 0 ? -__val : __val; }
+
+  template
+constexpr
+enable_if_t<__and_, is_unsigned<_Tp>>::value, _Tp>
+__abs(_Tp __val)
+{ return __val; }
+
   // Greatest common divisor
   template
 constexpr common_type_t<_Mn, _Nn>
@@ -60,8 +73,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static_assert(is_integral<_Mn>::value, "arguments to gcd are integers");
   static_assert(is_integral<_Nn>::value, "arguments to gcd are integers");
 
-  return __m == 0 ? std::abs(__n)
-   : __n == 0 ? std::abs(__m)
+  return __m == 0 ? fundamentals_v2::__abs(__n)
+   : __n == 0 ? fundamentals_v2::__abs(__m)
: fundamentals_v2::gcd(__n, __m % __n);
 }
 
@@ -74,7 +87,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static_assert(is_integral<_Nn>::value, "arguments to lcm are integers");
 
   return (__m != 0 && __n != 0)
-   ? (std::abs(__m) / fundamentals_v2::gcd(__m, __n)) * std::abs(__n)
+   ? (fundamentals_v2::__abs(__m) / fundamentals_v2::gcd(__m, __n))
+ * fundamentals_v2::__abs(__n)
: 0;
 }
 
diff --git a/libstdc++-v3/testsuite/experimental/numeric/77801.cc 
b/libstdc++-v3/testsuite/experimental/numeric/77801.cc
new file mode 100644
index 000..c4c8bfb
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/numeric/77801.cc
@@ -0,0 +1,22 @@
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do compile { target c++14 } }
+
+#include 
+#include 
+constexpr int i = std::experimental::gcd(4L, 5L); // PR libstdc++/77801
diff --git a/libstdc++-v3/testsuite/experimental/numeric/gcd.cc 
b/libstdc++-v3/testsuite/experimental/numeric/gcd.cc
index 038f12d..b3345dc 100644
--- a/libstdc++-v3/testsuite/experimental/numeric/gcd.cc
+++ b/libstdc++-v3/testsuite/experimental/numeric/gcd.cc
@@ -25,3 +25,7 @@ static_assert(lcm(21, 6) == 42, "");
 static_assert(lcm(41, 0) == 0, "LCD with zero is zero");
 static_assert(lcm(0, 7) == 0, "LCD with zero is zero");
 static_assert(lcm(0, 0) == 0, "no division by zero");
+
+static_assert(lcm(1u, 2) == 2, "unsigned and signed");
+static_assert(lcm(3, 4u) == 12, "signed and unsigned");
+static_assert(lcm(5u, 6u) == 30, "unsigned and unsigned");
diff --git a/libstdc++-v3/testsuite/experimental/numeric/lcm.cc 
b/libstdc++-v3/testsuite/experimental/numeric/lcm.cc
index 2c969b0..d90c152 100644
--- a/libstdc++-v3/testsuite/experimental/numeric/lcm.cc
+++ b/libstdc++-v3/testsuite/experimental/numeric/lcm.cc
@@ -29,3 +29,6 @@ static_assert( gcd(0, 

Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)

[Bernd Edlinger]

On 09/30/16 12:14, Bernd Edlinger wrote:
> Eric Botcazou wrote:
>>> A comment before the SETs and a testcase would be nice.  IIRC
>>> we do have stack size testcases via using -fstack-usage.
>>
>> Or -Wstack-usage, which might be more appropriate here.
>
> Yes.  good idea.  I was not aware that we already have that kind of tests.
>
> When trying to write this test. I noticed, that I did not try -Os so far.
> But for -Os the stack is still the unchanged 3500 bytes.
>
> However for embedded targets I am often inclined to use -Os, and
> would certainly not expect the stack to explode...
>
> I see in arm.md there are places like
>
>/* If we're optimizing for size, we prefer the libgcc calls.  */
>if (optimize_function_for_size_p (cfun))
>  FAIL;
>

Oh, yeah.  The comment is completely misleading.

If this pattern fails, expmed.c simply expands some
less efficient rtl, which also results in two shifts
and one or-op.  No libgcc calls at all.

So in simple cases without spilling the resulting
assembler is the same, regardless if this pattern
fails or not.  But the half-defined out registers
make a big difference when it has to be spilled.

>/* Expand operation using core-registers.
>   'FAIL' would achieve the same thing, but this is a bit smarter.  */
>scratch1 = gen_reg_rtx (SImode);
>scratch2 = gen_reg_rtx (SImode);
>arm_emit_coreregs_64bit_shift (LSHIFTRT, operands[0], operands[1],
>   operands[2], scratch1, scratch2);
>
>
> .. that explains why this happens.  I think it would be better to
> use the emit_coreregs for shift count >= 32, because these are
> effectively 32-bit shifts.
>
> Will try if that can be improved, and come back with the
> results.
>

The test case with -Os has 3520 bytes stack usage.
When only shift count >= 32 are handled we
have still 3000 bytes stack usage.
And when arm_emit_coreregs_64bit_shift is always
allowed to run, we have 2360 bytes stack usage.

Also for the code size it is better not to fail this
pattern.  So I propose to remove this exception in all
three expansions.

Here is an improved patch with the test case from the PR.
And a comment on the redundant SET why it is better to clear
the out register first.


Bootstrap and reg-testing on arm-linux-gnueabihf.
Is it OK for trunk?


Thanks
Bernd.
2016-09-29  Bernd Edlinger  

	PR target/77308
	* config/arm/arm.c (arm_emit_coreregs_64bit_shift): Clear the result
	register explicitly.
	* config/arm/arm.md (ashldi3, ashrdi3, lshrdi3): Don't FAIL if
	optimizing for size.

testsuite:
2016-09-29  Bernd Edlinger  

	PR target/77308
	* gcc.target/arm/pr77308.c: New test.


Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c	(revision 240645)
+++ gcc/config/arm/arm.c	(working copy)
@@ -29226,6 +29226,10 @@ arm_emit_coreregs_64bit_shift (enum rtx_code code,
 	  /* Shifts by a constant less than 32.  */
 	  rtx reverse_amount = GEN_INT (32 - INTVAL (amount));
 
+	  /* Clearing the out register in DImode first avoids lots
+	 of spilling and results in less stack usage.
+	 Later this redundant insn is completely removed.  */
+	  emit_insn (SET (out, const0_rtx));
 	  emit_insn (SET (out_down, LSHIFT (code, in_down, amount)));
 	  emit_insn (SET (out_down,
 			  ORR (REV_LSHIFT (code, in_up, reverse_amount),
@@ -29237,12 +29241,11 @@ arm_emit_coreregs_64bit_shift (enum rtx_code code,
 	  /* Shifts by a constant greater than 31.  */
 	  rtx adj_amount = GEN_INT (INTVAL (amount) - 32);
 
+	  emit_insn (SET (out, const0_rtx));
 	  emit_insn (SET (out_down, SHIFT (code, in_up, adj_amount)));
 	  if (code == ASHIFTRT)
 	emit_insn (gen_ashrsi3 (out_up, in_up,
 GEN_INT (31)));
-	  else
-	emit_insn (SET (out_up, const0_rtx));
 	}
 }
   else
Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md	(revision 240645)
+++ gcc/config/arm/arm.md	(working copy)
@@ -4016,10 +4016,6 @@
  cheaper to have the alternate code being generated than moving
  values to iwmmxt regs and back.  */
 
-  /* If we're optimizing for size, we prefer the libgcc calls.  */
-  if (optimize_function_for_size_p (cfun))
-	FAIL;
-
   /* Expand operation using core-registers.
 	 'FAIL' would achieve the same thing, but this is a bit smarter.  */
   scratch1 = gen_reg_rtx (SImode);
@@ -4089,10 +4085,6 @@
  cheaper to have the alternate code being generated than moving
  values to iwmmxt regs and back.  */
 
-  /* If we're optimizing for size, we prefer the libgcc calls.  */
-  if (optimize_function_for_size_p (cfun))
-	FAIL;
-
   /* Expand operation using core-registers.
 	 'FAIL' would achieve the same thing, but this is a bit smarter.  */
   scratch1 = gen_reg_rtx (SImode);
@@ -4159,10 +4151,6 @@
 

[PATCHv2][GCC] Optimise the fpclassify builtin to perform integer operations when possible

[Tamar Christina]

Hi All,

This is v2 of the patch which adds an optimized route to the fpclassify builtin
for floating point numbers which are similar to IEEE-754 in format.

I have addressed most comments from everyone except for two things:

1) Providing a back-end hook to override the functionality. While certainly
   possible the current fpclassify doesn't provide this either. So I'd like to
   treat it as an enhancement rather than an issue.

2) Doing it in a lowering phase. If the general consensus is that this is the
   path the patch must take then I'd be happy to reconsider. However at this
   this patch does not seem to produce worse code than what there was before.

The goal is to make it faster by:
1. Trying to determine the most common case first
   (e.g. the float is a Normal number) and then the
   rest. The amount of code generated at -O2 are
   about the same +/- 1 instruction, but the code
   is much better.
2. Using integer operation in the optimized path.

At a high level, the optimized path uses integer operations
to perform the following:

  if (exponent bits aren't all set or unset)
 return Normal;
  else if (no bits are set on the number after masking out
   sign bits then)
 return Zero;
  else if (exponent has no bits set)
 return Subnormal;
  else if (mantissa has no bits set)
 return Infinite;
  else
 return NaN;

In case the optimization can't be applied the old
implementation is used as a fall-back.

A limitation with this new approach is that the exponent
of the floating point has to fit in 31 bits and the floating
point has to have an IEEE like format and values for NaN and INF
(e.g. for NaN and INF all bits of the exp must be set).

To determine this IEEE likeness a new boolean was added to real_format.

As an example, Aarch64 now generates for classification of doubles:

f:
fmovx1, d0
mov w0, 7
sbfxx2, x1, 52, 11
add w3, w2, 1
tst w3, 0x07FE
bne .L1
mov w0, 13
tst x1, 0x7fff
beq .L1
mov w0, 11
tbz x2, 0, .L1
tst x1, 0xf
mov w0, 3
mov w1, 5
cselw0, w0, w1, ne

.L1:
ret

No new tests as there are existing tests to test functionality.
glibc benchmarks ran against the builtin and this shows a 42.5%
performance gain on Aarch64.

Regression tests ran on aarch64-none-linux and arm-none-linux-gnueabi
and no regression. x86 also has no regressions and modest gains (3%).

Ok for trunk?

Thanks,
Tamar

gcc/
2016-08-25  Tamar Christina  
Wilco Dijkstra  

* gcc/builtins.c (fold_builtin_fpclassify): Added optimized version. 
* gcc/real.h (real_format): Added is_ieee_compatible field.
* gcc/real.c (ieee_single_format): Set is_ieee_compatible flag.
(mips_single_format): Likewise.
(motorola_single_format): Likewise.
(spu_single_format): Likewise.
(ieee_double_format): Likewise.
(mips_double_format): Likewise.
(motorola_double_format): Likewise.
(ieee_extended_motorola_format): Likewise.
(ieee_extended_intel_128_format): Likewise.
(ieee_extended_intel_96_round_53_format): Likewise.
(ibm_extended_format): Likewise.
(mips_extended_format): Likewise.
(ieee_quad_format): Likewise.
(mips_quad_format): Likewise.
(vax_f_format): Likewise.
(vax_d_format): Likewise.
(vax_g_format): Likewise.
(decimal_single_format): Likewise.
(decimal_quad_format): Likewise.
(iee_half_format): Likewise.
(mips_single_format): Likewise.
(arm_half_format): Likewise.
(real_internal_format): Likewise.


gcc/testsuite/
2016-09-27  Tamar Christina  

* gcc.target/aarch64/builtin-fpclassify.c: New codegen test.diff --git a/gcc/builtins.c b/gcc/builtins.c
index 9a19a75cc8ed6edb5f543cd7bd26bcc0693e6ebb..1b4878c5ba098dcc0a4a506dbc7959d150cc9028 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -7943,10 +7943,8 @@ static tree
 fold_builtin_fpclassify (location_t loc, tree *args, int nargs)
 {
   tree fp_nan, fp_infinite, fp_normal, fp_subnormal, fp_zero,
-arg, type, res, tmp;
+arg, type, res;
   machine_mode mode;
-  REAL_VALUE_TYPE r;
-  char buf[128];
 
   /* Verify the required arguments in the original call.  */
   if (nargs != 6
@@ -7966,14 +7964,164 @@ fold_builtin_fpclassify (location_t loc, tree *args, int nargs)
   arg = args[5];
   type = TREE_TYPE (arg);
   mode = TYPE_MODE (type);
-  arg = builtin_save_expr (fold_build1_loc (loc, ABS_EXPR, type, arg));
+  const real_format *format = REAL_MODE_FORMAT (mode);
+  const HOST_WIDE_INT type_width = TYPE_PRECISION (type);
+
+  /*
+  For IEEE 754 types:
+
+  fpclassify (x) ->
+   !((exp + 1) & (exp_mask & ~1)) // exponent bits not all set or 

Re: [PATCH] Define 3-argument overloads of std::hypot for C++17 (P0030R1)

[Jonathan Wakely]

On 30/09/16 14:13 +0100, Szabolcs Nagy wrote:

On 30/09/16 10:35, Szabolcs Nagy wrote:

On 29/09/16 14:37, Andre Vieira (lists) wrote:


On arm-none-eabi I'm seeing a failure for the long double type and inputs:
{ 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }

The abs(frac) is higher than the toler: 1.73455e-16 vs 1e-16. Is that a
reasonable difference? Should we raise toler3 to 1e-15?

The last line is also too high:
  { 2147483647.l, 2147483647.l, 2147483647.l, 3719550785.027307813987l }
Yields a frac of: 1.28198e-16

Those are the only ones that pass the 1e-16 threshold.



i think the tolerance should be defined in
terms of LDBL_EPSILON (or numeric_limits).

n*LDBL_EPSILON tolerance would accept hypot
with about n ulp error.



now i see that there are huge ulp errors..

toler = 10*eps;

should work for all formats, but currently there
is >1000 ulp error on one of the double test cases..
so tolerance is carefully set to avoid triggering
the failure there

i'd set toler to 1*eps if this test case is not
for testing hypot quality.


Ed is already re-working the code, and probably the tests.

I'd prefer to wait for his new implementation, but if the FAIL is a
problem now then go ahead and adjust the tolerance.

Re: [PATCH] Define 3-argument overloads of std::hypot for C++17 (P0030R1)

[Szabolcs Nagy]

On 30/09/16 10:35, Szabolcs Nagy wrote:
> On 29/09/16 14:37, Andre Vieira (lists) wrote:
>>
>> On arm-none-eabi I'm seeing a failure for the long double type and inputs:
>> { 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }
>>
>> The abs(frac) is higher than the toler: 1.73455e-16 vs 1e-16. Is that a
>> reasonable difference? Should we raise toler3 to 1e-15?
>>
>> The last line is also too high:
>>   { 2147483647.l, 2147483647.l, 2147483647.l, 3719550785.027307813987l }
>> Yields a frac of: 1.28198e-16
>>
>> Those are the only ones that pass the 1e-16 threshold.
>>
> 
> i think the tolerance should be defined in
> terms of LDBL_EPSILON (or numeric_limits).
> 
> n*LDBL_EPSILON tolerance would accept hypot
> with about n ulp error.
> 

now i see that there are huge ulp errors..

toler = 10*eps;

should work for all formats, but currently there
is >1000 ulp error on one of the double test cases..
so tolerance is carefully set to avoid triggering
the failure there

i'd set toler to 1*eps if this test case is not
for testing hypot quality.

Re: [Testsuite] Use correct effective-target settings for ARM fp16-aapcs tests.

[Kyrill Tkachov]

On 30/09/16 10:31, Matthew Wahab wrote:

The recently added tests gcc.target/arm/aapcs-{3,4}.c are intended
to check the behaviour of th ARM Alternative FP16 format. They both
check for compiler support of FP16 using dg-require-effective-target
arm_fp16_ok This is too weak since the directive is true when
fp16-format=ieee is set, as it is when the +fp16 extension is
enabled.

This patch changes the directives for both tests to
  dg-require-effective-target arm_fp16_alternative_ok
which is only enabled with fp16-format=alternative is set.

For fp16-aapcs-4.c, it was also necessary to add the
-mfp16-format=alternative to the dg-options, rather than use the
arm_fp16-alternative add-options. There seems to some interaction
between the different directives and the dg-skip-if, but I can't track
it down.

Tested for cross-compiled arm-none-eabi by running the
gcc.target/arm/arm.exp testsuite on an ARMv8.2-A emulator and on an
ARMv8-A emulator.

Ok for trunk?


Ok.
Thanks,
Kyrill


Matthew

testsuite/
2016-09-28  Matthew Wawhab  

* gcc.target/arm/fp16-aapcs-3.c: Replace the arm_fp16_ok with
arm_fp16_alternative_ok as the required effective target.
* gcc.target/arm/fp16-aapcs-4.c: Likewise.  Also add
-mfp16-format=alternative to the dg-options directive and remove
the dg-add-otions directive.

Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler

[Rainer Orth]

Hi Martin,

> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>> this would be i386-pc-solaris2.12.  I'm not sure if the constructor
>> priority detection works in a cross scenario.
>> 
>> I'm attaching the resulting assembly (although for Solaris as, the gas
>> build is still running).
>
> Hi. Sorry, I have a stupid mistake in dtor priority
> (I used 65534 instead of desired 99). Please try to test it on Solaris 12
> with the attached patch. I'll send the patch to ML soon.
>
> Can you please test whether it makes any change on a solaris target w/o
> prioritized ctors/dtors?

sure: I've added your patch to my source tree for the running bootstraps
and will have builds on Solaris 12 (with constructor priority) and S10/11
(without) available in a few hours.

Rainer

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

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 30/09/16 11:27, Marek Polacek wrote:
> Can we move forward with this patch, then?

I've been travelling for several weeks.  However, I'm back at my desk
now, so I can move this forward.  I have all the approvals and
everybody has had time to respond.  However, I'll need to pull some
more recent changes into my tree and merge again.

Andrew.

Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler

[Martin Liška]

On 09/30/2016 02:31 PM, Rainer Orth wrote:
> this would be i386-pc-solaris2.12.  I'm not sure if the constructor
> priority detection works in a cross scenario.
> 
> I'm attaching the resulting assembly (although for Solaris as, the gas
> build is still running).

Hi. Sorry, I have a stupid mistake in dtor priority
(I used 65534 instead of desired 99). Please try to test it on Solaris 12
with the attached patch. I'll send the patch to ML soon.

Can you please test whether it makes any change on a solaris target w/o
prioritized ctors/dtors?

Thanks,
Martin
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 0b8c0b3..a759831 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1078,7 +1078,7 @@ build_gcov_exit_decl (void)
   append_to_statement_list (stmt, );
 
   /* Generate a destructor to run it (with priority 99).  */
-  cgraph_build_static_cdtor ('D', dtor, DEFAULT_INIT_PRIORITY - 1);
+  cgraph_build_static_cdtor ('D', dtor, MAX_RESERVED_INIT_PRIORITY - 1);
 }
 
 /* Create the gcov_info types and object.  Generate the constructor

Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler

[Rainer Orth]

7:
.LSFDE19:
.long   .LEFDE19-.LASFDE19
.LASFDE19:
.long   .LASFDE19-.Lframe1
.long   .LFB1054
.long   .LFE1054-.LFB1054
.byte   0
.byte   0x4
.long   .LCFI27-.LFB1054
.byte   0xe
.byte   0x10
.byte   0x86
.byte   0x2
.byte   0x4
.long   .LCFI28-.LCFI27
.byte   0xd
.byte   0x6
.byte   0x4
.long   .LCFI29-.LCFI28
.byte   0xc
.byte   0x7
.byte   0x8
.align 8
.LEFDE19:
.LSFDE21:
.long   .LEFDE21-.LASFDE21
.LASFDE21:
.long   .LASFDE21-.Lframe1
.long   .LFB1055
.long   .LFE1055-.LFB1055
.byte   0
.byte   0x4
.long   .LCFI30-.LFB1055
.byte   0xe
.byte   0x10
.byte   0x86
.byte   0x2
.byte   0x4
.long   .LCFI31-.LCFI30
.byte   0xd
.byte   0x6
.byte   0x4
.long   .LCFI32-.LCFI31
.byte   0xc
.byte   0x7
.byte   0x8
.align 8
.LEFDE21:
.LSFDE23:
.long   .LEFDE23-.LASFDE23
.LASFDE23:
.long   .LASFDE23-.Lframe1
.long   .LFB1056
.long   .LFE1056-.LFB1056
.byte   0
.byte   0x4
.long   .LCFI33-.LFB1056
.byte   0xe
.byte   0x10
.byte   0x86
.byte   0x2
.byte   0x4
.long   .LCFI34-.LCFI33
.byte   0xd
.byte   0x6
.byte   0x4
    .long   .LCFI35-.LCFI34
.byte   0xc
.byte   0x7
.byte   0x8
.align 8
.LEFDE23:
.hidden __dso_handle
.ident  "GCC: (GNU) 7.0.0 20160930 (experimental) [trunk revision 
240649]"
.section.text._ZN4TestC2Ev%_ZN4TestC5Ev,"ax",@progbits
_ZN4TestC5Ev:
.section.text._ZN4TestD2Ev%_ZN4TestD5Ev,"ax",@progbits
_ZN4TestD5Ev:

Re: [wwwdocs] Make it more obvious which releases are still supported

[Richard Biener]

On Fri, Sep 30, 2016 at 2:26 PM, Jonathan Wakely  wrote:
> This adjusts the front page and the news page for each release to
> clarify that past releases are no longer maintained.
>
> OK for wwwdocs?

Ok.

Thanks,
Richard.

>

[wwwdocs] Make it more obvious which releases are still supported

[Jonathan Wakely]

This adjusts the front page and the news page for each release to
clarify that past releases are no longer maintained.

OK for wwwdocs?


Index: htdocs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1026
diff -u -r1.1026 index.html
--- htdocs/index.html	25 Aug 2016 10:55:41 -	1.1026
+++ htdocs/index.html	30 Sep 2016 12:25:30 -
@@ -121,7 +121,7 @@
 
 
 
-Releases
+Supported Releases
 
 
 GCC 6.2
Index: htdocs/gcc-2.95/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/index.html,v
retrieving revision 1.5
diff -u -r1.5 index.html
--- htdocs/gcc-2.95/index.html	28 Jun 2014 11:59:43 -	1.5
+++ htdocs/gcc-2.95/index.html	30 Sep 2016 12:25:30 -
@@ -10,6 +10,8 @@
 March 16, 2001: The GNU project and the GCC developers are
 pleased to announce the release of GCC version 2.95.3.
 
+This release is no longer maintained.
+
 Release History
 
 
Index: htdocs/gcc-3.0/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.0/index.html,v
retrieving revision 1.17
diff -u -r1.17 index.html
--- htdocs/gcc-3.0/index.html	28 Jun 2014 07:45:10 -	1.17
+++ htdocs/gcc-3.0/index.html	30 Sep 2016 12:25:30 -
@@ -15,6 +15,8 @@
 a bug-fix release for the GCC 3.0 series.
 
 
+This release series is no longer maintained.
+
 GCC used to stand for the GNU C Compiler, but since the compiler
 supports several other languages aside from C, it now stands for the
 GNU Compiler Collection.
Index: htdocs/gcc-3.1/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/index.html,v
retrieving revision 1.6
diff -u -r1.6 index.html
--- htdocs/gcc-3.1/index.html	28 Jun 2014 07:45:11 -	1.6
+++ htdocs/gcc-3.1/index.html	30 Sep 2016 12:25:30 -
@@ -15,6 +15,8 @@
 
 The links below still apply to GCC 3.1.1.
 
+This release series is no longer maintained.
+
 May 15, 2002
 
 The http://www.gnu.org/;>GNU project and the GCC
Index: htdocs/gcc-3.2/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.2/index.html,v
retrieving revision 1.13
diff -u -r1.13 index.html
--- htdocs/gcc-3.2/index.html	28 Jun 2014 07:45:11 -	1.13
+++ htdocs/gcc-3.2/index.html	30 Sep 2016 12:25:30 -
@@ -25,6 +25,8 @@
 Please refer to our detailed list of news,
 caveats, and bug-fixes for further information.
 
+This release series is no longer maintained.
+
 Release History
 
 
Index: htdocs/gcc-3.3/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/index.html,v
retrieving revision 1.21
diff -u -r1.21 index.html
--- htdocs/gcc-3.3/index.html	28 Jun 2014 07:45:11 -	1.21
+++ htdocs/gcc-3.3/index.html	30 Sep 2016 12:25:30 -
@@ -23,6 +23,8 @@
 href="https://gcc.gnu.org/onlinedocs/gcc/Contributors.html;>amazing
 group of volunteers.
 
+This release series is no longer maintained.
+
 

[gomp4] improve collapse user var calculation

[Nathan Sidwell]

In working on tile I noticed an unnecessary modulo operation for the calculation 
of the outermost loop's user iteration variable.  By construction the modulo 
operator is useless here.  Took the opportunity of moving the modulo and 
division operations next to eachother so it'd be easier to make use of any 
divmod apparatus the target may have.


committed to gomp4.

nathan
2016-09-30  Nathan Sidwell  

	* omp-low.c (expand_oacc_collapse_vars): Avoid DIV for outermost
	collaps var.

Index: omp-low.c
===
--- omp-low.c	(revision 240653)
+++ omp-low.c	(working copy)
@@ -7591,8 +7591,16 @@ expand_oacc_collapse_vars (const struct
 	  plus_type = sizetype;
 	}
 
-  expr = fold_build2 (TRUNC_MOD_EXPR, ivar_type, ivar,
-			  fold_convert (ivar_type, collapse->iters));
+  expr = ivar;
+  if (ix)
+	{
+	  tree mod = fold_convert (ivar_type, collapse->iters);
+	  ivar = fold_build2 (TRUNC_DIV_EXPR, ivar_type, expr, mod);
+	  expr = fold_build2 (TRUNC_MOD_EXPR, ivar_type, expr, mod);
+	  ivar = force_gimple_operand_gsi (gsi, ivar, true, NULL_TREE,
+	   true, GSI_SAME_STMT);
+	}
+  
   expr = fold_build2 (MULT_EXPR, diff_type, fold_convert (diff_type, expr),
 			  collapse->step);
   expr = fold_build2 (plus_code, iter_type, collapse->base,
@@ -7601,14 +7609,6 @@ expand_oacc_collapse_vars (const struct
    true, GSI_SAME_STMT);
   gassign *ass = gimple_build_assign (loop->v, expr);
   gsi_insert_before (gsi, ass, GSI_SAME_STMT);
-
-  if (ix)
-	{
-	  expr = fold_build2 (TRUNC_DIV_EXPR, ivar_type, ivar,
-			  fold_convert (ivar_type, collapse->iters));
-	  ivar = force_gimple_operand_gsi (gsi, expr, true, NULL_TREE,
-	   true, GSI_SAME_STMT);
-	}
 }
 }
 

Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler

[Nathan Sidwell]

On 09/30/16 05:22, Rainer Orth wrote:


While this would take care of the testsuite failures, this creates a
terrible user experience outside of the testsuite: if we know that
-fprofile-arcs -ftest-coverage cannot work on targets without
constructor priority support, the compiler should error out with an
appropriate message instead of just creating confusing non-working
executables.


It should either
1) emit a non-prioritized static ctor
2) or use the older atexit mechanism.

Adjust fall through comments in aarch64-simd.md

[Marek Polacek]

It's unclear whether we'll handle /* Else, fall through.  */ in the nearest
future, so I'll just change it to a recognizable format instead.

When this is in, I can remove the recently added -Wno-error lines in 
Makefile.in.

Bootstrapped on aarch64-linux.  I'm checking this in.

2016-09-30  Marek Polacek  

* config/aarch64/aarch64-simd.md: Adjust fall through comments.

diff --git gcc/config/aarch64/aarch64-simd.md gcc/config/aarch64/aarch64-simd.md
index f942a54..9ce7f00 100644
--- gcc/config/aarch64/aarch64-simd.md
+++ gcc/config/aarch64/aarch64-simd.md
@@ -2443,7 +2443,7 @@
  comparison = gen_aarch64_cmlt;
  break;
}
-  /* Else, fall through.  */
+  /* Fall through.  */
 case UNGE:
   std::swap (operands[2], operands[3]);
   /* Fall through.  */
@@ -2457,7 +2457,7 @@
  comparison = gen_aarch64_cmle;
  break;
}
-  /* Else, fall through.  */
+  /* Fall through.  */
 case UNGT:
   std::swap (operands[2], operands[3]);
   /* Fall through.  */

Marek

Re: [PATCH 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

[Bernd Schmidt]

On 09/29/2016 07:32 PM, Denys Vlasenko wrote:

On 09/29/2016 04:45 PM, Bernd Schmidt wrote:

On 09/28/2016 02:57 PM, Denys Vlasenko wrote:

-  /* Comes from final.c -- no real reason to change it.  */
-#define MAX_CODE_ALIGN 16
-
 case OPT_malign_loops_:
   warning_at (loc, 0, "-malign-loops is obsolete, use
-falign-loops");
-  if (value > MAX_CODE_ALIGN)
-error_at (loc, "-malign-loops=%d is not between 0 and %d",
-  value, MAX_CODE_ALIGN);
-  else
-opts->x_align_loops = 1 << value;
   return true;


That does seem to be a functional change. I'll defer to Uros.


It would be awkward to translate -malign-loops=%d et al
to comma-separated string format.
Since this warning is there for some 15 years already,
anyone who actually cares should have converted to new options
long ago.


Hmm, if it's been 15 years, maybe it's time to remove these. Could you 
submit a patch separately?



-  if (opts->x_align_functions <= 0)
+  if (opts->x_flag_align_functions && !opts->x_str_align_functions)


Are these conditions really equivalent? It looks like zero was
the default even when no -falign-functions was specified.
 Or is that overriden by init_alignments?


 {
-  if (opts->x_align_loops == 0)
+  /* -falign-foo without argument: supply one */
+  if (opts->x_flag_align_loops && !opts->x_str_align_loops)


Same here.


The execution flow for option parsing is somewhat convoluted, no doubt.

I found it experimentally that these are locations where
default alignment parameters are set when -falign-functions
is given with no arguments (or when it is implied by -O2).


I applied your latest two patches to experiment with them, and I see 
different behaviour before and after on x86_64-linux. There seems to be 
a difference in function alignment and label alignment at -O2.


I think it would be good to add testcases first to document and verify 
existing behaviour, they would then serve to show whether it is 
unchanged afterwards.


Need to look into the x86 hook thing in a bit more detail.


Bernd

Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler

[Martin Liška]

On 09/30/2016 11:22 AM, Rainer Orth wrote:
> Hi Martin,
> 
>>> the testcase FAILs on Solaris 12 (both SPARC and x86):
>>>
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 gcov: 1 failures in line
>>> counts, 0 i
>>> n branch percentages, 0 in return percentages, 0 in intermediate format
>>> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++11  line 21: is #:should be 1
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++14 gcov: 1 failures in line
>>> counts, 0 i
>>> n branch percentages, 0 in return percentages, 0 in intermediate format
>>> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++14  line 21: is #:should be 1
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++98 gcov: 1 failures in line
>>> counts, 0 i
>>> n branch percentages, 0 in return percentages, 0 in intermediate format
>>> +FAIL: g++.dg/gcov/pr16855.C  -std=gnu++98  line 21: is #:should be 1
>>>
>>> I haven't looked closer yet, but notice that you require constructor
>>> priority support which isn't available everywhere (it is on Solaris 12,
>>> but not before).
>>>
>>> Rainer
>>>
>>
>> Hello.
>>
>> Sorry for the test-breakage. The issue is really connected to fact that
>> current trunk relies
>> on support of dtor priority. The former implementation called the function
>> __gcov_exit via atexit.
>> If I understand correctly, fully support of static ctors/dtors, C++
>> ctors/dtors, with combination
>> of atexit cannot be done on a target w/o ctor/dtor priorities.
> 
> understood.  However, Solaris 12 *does* have support for constructor
> priorities and the testcase still fails, so there's more going on here.

I see, however I don't have access to such a machine. I would appreciate
if you help me to debug what's going on. Can you please send me --target=x,
so that I can at least check created assembly?

> 
>> Ideally we should have a macro for each target telling whether it supports
>> priorities or not.
>> However, we probably don't have? I would suggest to make the test
>> conditional just for main
>> targets which support priorities?
>>
>> Thoughts?
> 
> While this would take care of the testsuite failures, this creates a
> terrible user experience outside of the testsuite: if we know that
> -fprofile-arcs -ftest-coverage cannot work on targets without
> constructor priority support, the compiler should error out with an
> appropriate message instead of just creating confusing non-working
> executables.

More precisely, it does not work reliably on constructor and destructors as
we depend on an order how are ctor/dtors executed. We had the same behavior even
before my patch, but documenting that definitely worth for doing. I'll do a 
patch.

Martin

> 
>   Rainer
> 

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

[Marek Polacek]

On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote:
> On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
> 
> > See Tom Tromey's explanation why accepting too much is bad (at least unless
> > we want multiple levels).
> 
> And I still don't buy it. The case where someone writes "Don't fall through"
> is artificial to begin with, and also forgetting to put the break; there
> really isn't something for us to be concerned about.
> 
> On the other hand, we end up having to change massive amounts of perfectly
> fine code and even disabling -Werror in some places. That's the textbook
> case of an awful warning.

On the flip side, those patches (for GCC) were quite trivial and I've done
most of the work, and it's something you only have to do once.

Disabling -Werror was only necessary because I didn't investigate the problem
deep enough, but this has been fixed now (the genattr.c part in
) and I'm about to
post a patch that removes those added -Wno-error (just waiting for aarch64
bootstrap to finish).

The warning repeatedly finds bugs (I've already fixed a bunch of them), and
prevents from more creeping in.

The comments parsing part is contentious and tricky (and GCC might be the first
compiler that attempts to do this, so we're breaking new ground), yet the
warning *is* useful, and only more so with upcoming C++17 which standardizes
[[fallthrough]];.

Marek

Re: [PATCH] Fix -Wimplicit-fallthrough -C, handle some more comment styles and comments in between FALLTHRU comment and label

[Bernd Schmidt]

On 09/30/2016 12:51 PM, Jakub Jelinek wrote:

On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote:

On 09/30/2016 11:45 AM, Jakub Jelinek wrote:


See Tom Tromey's explanation why accepting too much is bad (at least unless
we want multiple levels).


And I still don't buy it. The case where someone writes "Don't fall through"
is artificial to begin with, and also forgetting to put the break; there
really isn't something for us to be concerned about.


It doesn't have to be exactly that, fall is a substring of 200+ english, thr
is a substring of 1000+ english words, if you allow arbitrary stuff in
between or before it or after it, it can say anything, completely unrelated
to falling through across case labels.


True, but IMO irrelevant. We have to consider what is likely in real 
code. We're trying to catch likely problems without adding a prohibitive 
cost to enabling -Wextra. It's not helpful to punish people for writing 
code that is valid and documents intentional fallthrough, but does it in 
a style or a language we didn't expect.


A complete solution would require working AI; maybe someone from Google 
can contribute one. Failing that, we need heuristics, and I still like 
Michael's suggestion of not printing a warning if we see _any_ comment, 
on the grounds that this would still catch the vast majority of actual 
errors, without the huge false positive rate we currently have.



Bernd