Re: [rs6000] Fix compare debug failure on AIX

2015-05-01 Thread Alan Modra
On Fri, May 01, 2015 at 09:48:51AM -0400, David Edelsohn wrote:
> On Thu, Apr 30, 2015 at 7:28 AM, Eric Botcazou  wrote:
> >> We might want to check if doing -Og and not just -O0.
> >
> > You're right, thanks, amended patch attached, same ChangeLog.
> 
> Why should GCC unnecessarily create stack frames to avoid
> compare-debug testcase failures?

More to the point, do you need a frame on AIX when debugging?  If yes
then the correct change is to replace

  else if (TARGET_XCOFF && write_symbols != NO_DEBUG)
info_ptr->push_p = 1;

with

  else if (TARGET_XCOFF)
info_ptr->push_p = 1;

If no, then the correct change is to delete those lines from
rs6000_stack_info, and fix the comment.

https://gcc.gnu.org/ml/gcc-patches/2003-03/msg01693.html 

-- 
Alan Modra
Australia Development Lab, IBM


[doc, committed] more attribute documentation cleanup

2015-05-01 Thread Sandra Loosemore
I've checked in another installment of my ongoing cleanup of the 
attribute documentation in extend.texi.  In this patch, I've tidied up 
the variable and type attribute sections.  There's not much actual 
change to the document text here, mostly just moving things around and 
tweaking structure.  These two sections were in much better shape 
(besides being much shorter) than the function attribute section was 
that I tackled in my last patch.


Next I am planning to reorder the attribute sections within the chapter 
to group them together, and re-work the introductory material so that 
the presentation flows better.


-Sandra

2015-05-01  Sandra Loosemore  

	gcc/
	* doc/extend.texi (Variable Attributes): Add menu and proper
	@nodes to subsections.  Move Microsoft Windows attributes to
	their own subsection.
	(Type Attributes): Reorganize introduction to remove duplicate
	list of attributes.  Add menu and proper @nodes to subsections.
	Alphabetize the main table of common attributes.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 222543)
+++ gcc/doc/extend.texi	(working copy)
@@ -5400,6 +5400,26 @@ Other front ends might define more attri
 @xref{Attribute Syntax}, for details of the exact syntax for using
 attributes.
 
+@menu
+* Common Variable Attributes::
+* AVR Variable Attributes::
+* Blackfin Variable Attributes::
+* H8/300 Variable Attributes::
+* IA-64 Variable Attributes::
+* M32R/D Variable Attributes::
+* MeP Variable Attributes::
+* Microsoft Windows Variable Attributes::
+* PowerPC Variable Attributes::
+* SPU Variable Attributes::
+* x86 Variable Attributes::
+* Xstormy16 Variable Attributes::
+@end menu
+
+@node Common Variable Attributes
+@subsection Common Variable Attributes
+
+The following attributes are supported on most targets.
+
 @table @code
 @cindex @code{aligned} variable attribute
 @item aligned (@var{alignment})
@@ -5522,7 +5542,8 @@ argument, which must be a string, is pri
 present.
 
 The @code{deprecated} attribute can also be used for functions and
-types (@pxref{Common Function Attributes}, @pxref{Type Attributes}).
+types (@pxref{Common Function Attributes},
+@pxref{Common Type Attributes}).
 
 @item mode (@var{mode})
 @cindex @code{mode} variable attribute
@@ -5608,33 +5629,6 @@ attribute is not available on all platfo
 If you need to map the entire contents of a module to a particular
 section, consider using the facilities of the linker instead.
 
-@item shared
-@cindex @code{shared} variable attribute
-On Microsoft Windows, in addition to putting variable definitions in a named
-section, the section can also be shared among all running copies of an
-executable or DLL@.  For example, this small program defines shared data
-by putting it in a named section @code{shared} and marking the section
-shareable:
-
-@smallexample
-int foo __attribute__((section ("shared"), shared)) = 0;
-
-int
-main()
-@{
-  /* @r{Read and write foo.  All running
- copies see the same value.}  */
-  return 0;
-@}
-@end smallexample
-
-@noindent
-You may only use the @code{shared} attribute along with @code{section}
-attribute with a fully-initialized global definition because of the way
-linkers work.  See @code{section} attribute for more information.
-
-The @code{shared} attribute is only available on Microsoft Windows@.
-
 @item tls_model ("@var{tls_model}")
 @cindex @code{tls_model} variable attribute
 The @code{tls_model} attribute sets thread-local storage model
@@ -5692,45 +5686,14 @@ struct S  __attribute__ ((vector_size (1
 is invalid even if the size of the structure is the same as the size of
 the @code{int}.
 
-@item selectany
-@cindex @code{selectany} variable attribute
-The @code{selectany} attribute causes an initialized global variable to
-have link-once semantics.  When multiple definitions of the variable are
-encountered by the linker, the first is selected and the remainder are
-discarded.  Following usage by the Microsoft compiler, the linker is told
-@emph{not} to warn about size or content differences of the multiple
-definitions.
-
-Although the primary usage of this attribute is for POD types, the
-attribute can also be applied to global C++ objects that are initialized
-by a constructor.  In this case, the static initialization and destruction
-code for the object is emitted in each translation defining the object,
-but the calls to the constructor and destructor are protected by a
-link-once guard variable.
-
-The @code{selectany} attribute is only available on Microsoft Windows
-targets.  You can use @code{__declspec (selectany)} as a synonym for
-@code{__attribute__ ((selectany))} for compatibility with other
-compilers.
-
 @item weak
 @cindex @code{weak} variable attribute
 The @code{weak} attribute is described in
 @ref{Common Function Attributes}.
 
-@item dllimport
-@cindex @code{dllimport} variable attribute
-The @code{dllimport} attribute is described in
-@ref{Microsoft Wind

Re: [PATCH] fixup libobjc usage of PCC_BITFIELD_TYPE_MATTERS

2015-05-01 Thread pinskia




> On May 1, 2015, at 8:30 PM, tbsaunde+...@tbsaunde.org wrote:
> 
> From: Trevor Saunders 
> 
> Hi,
> 
> This adds a configure check to libobjc to find out if types of bitfields 
> effect
> their layout, and uses it to replace the rather broken usage of
> PCC_BITFIELD_TYPE_MATTERS.
> 
> bootstrapped + regtested x86_64-linux-gnu, bootstrapped on ppc64le-linux-gnu
> and ran check-objc there without failures, and checked the correct part of the
> ifdef is used on a cross to m68k-linux-elf.  ok?  I'm sure I've gotten
> something wrong since this is a bunch of auto tools ;-)


This is ok.  I have been meaning to try to get rid of all uses of the target 
headers but never got around to finishing it. 

Thanks,
Andrew

> 
> Trev
> 
> libobjc/ChangeLog:
> 
> 2015-05-01  Trevor Saunders  
> 
>* acinclude.m4: Include bitfields.m4.
>* config.h.in: Regenerate.
>* configure: Likewise.
>* configure.ac: Invoke gt_BITFIELD_TYPE_MATTERS.
>* encoding.c: Check HAVE_BITFIELD_TYPE_MATTERS.
> 
> config/ChangeLog:
> 
> 2015-05-01  Trevor Saunders  
> 
>* bitfields.m4: New file.
> ---
> config/bitfields.m4  | 26 ++
> libobjc/acinclude.m4 |  1 +
> libobjc/config.h.in  |  3 +++
> libobjc/configure| 38 ++
> libobjc/configure.ac |  2 ++
> libobjc/encoding.c   |  3 ++-
> 6 files changed, 72 insertions(+), 1 deletion(-)
> create mode 100644 config/bitfields.m4
> 
> diff --git a/config/bitfields.m4 b/config/bitfields.m4
> new file mode 100644
> index 000..ee8f3b5
> --- /dev/null
> +++ b/config/bitfields.m4
> @@ -0,0 +1,26 @@
> +dnl Copyright (C) 2015 Free Software Foundation, Inc.
> +dnl This file is free software, distributed under the terms of the GNU
> +dnl General Public License.  As a special exception to the GNU General
> +dnl Public License, this file may be distributed as part of a program
> +dnl that contains a configuration script generated by Autoconf, under
> +dnl the same distribution terms as the rest of that program.
> +
> +# Define HAVE_BITFIELD_TYPE_MATTERS if the type of bitfields effects their
> +# alignment.
> +
> +AC_DEFUN([gt_BITFIELD_TYPE_MATTERS],
> +[
> +  AC_CACHE_CHECK([if the type of bitfields matters], 
> gt_cv_bitfield_type_matters,
> +  [
> +AC_TRY_COMPILE(
> +  [struct foo1 { char x; char :0; char y; };
> +struct foo2 { char x; int :0; char y; };
> +int foo1test[ sizeof (struct foo1) == 2 ? 1 : -1 ];
> +int foo2test[ sizeof (struct foo2) == 5 ? 1 : -1]; ],
> +  [], gt_cv_bitfield_type_matters=yes, gt_cv_bitfield_type_matters=no)
> +  ])
> +  if test $gt_cv_bitfield_type_matters = yes; then
> +AC_DEFINE(HAVE_BITFIELD_TYPE_MATTERS, 1,
> +  [Define if the type of bitfields effects alignment.])
> +  fi
> +])
> diff --git a/libobjc/acinclude.m4 b/libobjc/acinclude.m4
> index bf78dbe..4193018 100644
> --- a/libobjc/acinclude.m4
> +++ b/libobjc/acinclude.m4
> @@ -12,6 +12,7 @@ m4_include(../config/acx.m4)
> m4_include(../config/no-executables.m4)
> m4_include(../config/enable.m4)
> m4_include(../config/tls.m4)
> +m4_include(../config/bitfields.m4)
> 
> m4_include(../libtool.m4)
> dnl The lines below arrange for aclocal not to bring an installed
> diff --git a/libobjc/config.h.in b/libobjc/config.h.in
> index c055e7c..20d1fca 100644
> --- a/libobjc/config.h.in
> +++ b/libobjc/config.h.in
> @@ -1,5 +1,8 @@
> /* config.h.in.  Generated from configure.ac by autoheader.  */
> 
> +/* Define if the type of bitfields effects alignment. */
> +#undef HAVE_BITFIELD_TYPE_MATTERS
> +
> /* Define to 1 if the target assembler supports thread-local storage. */
> #undef HAVE_CC_TLS
> 
> diff --git a/libobjc/configure b/libobjc/configure
> index 642eb9c..0547f91 100755
> --- a/libobjc/configure
> +++ b/libobjc/configure
> @@ -11530,6 +11530,44 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_exception_model_name" >&5
> $as_echo "$ac_exception_model_name" >&6; }
> 
> +
> +  { $as_echo "$as_me:${as_lineno-$LINENO}: checking if the type of bitfields 
> matters" >&5
> +$as_echo_n "checking if the type of bitfields matters... " >&6; }
> +if test "${gt_cv_bitfield_type_matters+set}" = set; then :
> +  $as_echo_n "(cached) " >&6
> +else
> +
> +cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> +/* end confdefs.h.  */
> +struct foo1 { char x; char :0; char y; };
> +struct foo2 { char x; int :0; char y; };
> +int foo1test[ sizeof (struct foo1) == 2 ? 1 : -1 ];
> +int foo2test[ sizeof (struct foo2) == 5 ? 1 : -1];
> +int
> +main ()
> +{
> +
> +  ;
> +  return 0;
> +}
> +_ACEOF
> +if ac_fn_c_try_compile "$LINENO"; then :
> +  gt_cv_bitfield_type_matters=yes
> +else
> +  gt_cv_bitfield_type_matters=no
> +fi
> +rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> +
> +fi
> +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
> $gt_cv_bitfield_type_matters" >&5
> +$as_echo "$gt_cv_bitfield_type_matters" >&6; }
> +  if test $gt_cv_bitfield_type_matters = yes; then
> +
> +$as_ech

[PATCH] fixup libobjc usage of PCC_BITFIELD_TYPE_MATTERS

2015-05-01 Thread tbsaunde+gcc
From: Trevor Saunders 

Hi,

This adds a configure check to libobjc to find out if types of bitfields effect
their layout, and uses it to replace the rather broken usage of
PCC_BITFIELD_TYPE_MATTERS.

bootstrapped + regtested x86_64-linux-gnu, bootstrapped on ppc64le-linux-gnu
and ran check-objc there without failures, and checked the correct part of the
ifdef is used on a cross to m68k-linux-elf.  ok?  I'm sure I've gotten
something wrong since this is a bunch of auto tools ;-)

Trev

libobjc/ChangeLog:

2015-05-01  Trevor Saunders  

* acinclude.m4: Include bitfields.m4.
* config.h.in: Regenerate.
* configure: Likewise.
* configure.ac: Invoke gt_BITFIELD_TYPE_MATTERS.
* encoding.c: Check HAVE_BITFIELD_TYPE_MATTERS.

config/ChangeLog:

2015-05-01  Trevor Saunders  

* bitfields.m4: New file.
---
 config/bitfields.m4  | 26 ++
 libobjc/acinclude.m4 |  1 +
 libobjc/config.h.in  |  3 +++
 libobjc/configure| 38 ++
 libobjc/configure.ac |  2 ++
 libobjc/encoding.c   |  3 ++-
 6 files changed, 72 insertions(+), 1 deletion(-)
 create mode 100644 config/bitfields.m4

diff --git a/config/bitfields.m4 b/config/bitfields.m4
new file mode 100644
index 000..ee8f3b5
--- /dev/null
+++ b/config/bitfields.m4
@@ -0,0 +1,26 @@
+dnl Copyright (C) 2015 Free Software Foundation, Inc.
+dnl This file is free software, distributed under the terms of the GNU
+dnl General Public License.  As a special exception to the GNU General
+dnl Public License, this file may be distributed as part of a program
+dnl that contains a configuration script generated by Autoconf, under
+dnl the same distribution terms as the rest of that program.
+
+# Define HAVE_BITFIELD_TYPE_MATTERS if the type of bitfields effects their
+# alignment.
+
+AC_DEFUN([gt_BITFIELD_TYPE_MATTERS],
+[
+  AC_CACHE_CHECK([if the type of bitfields matters], 
gt_cv_bitfield_type_matters,
+  [
+AC_TRY_COMPILE(
+  [struct foo1 { char x; char :0; char y; };
+struct foo2 { char x; int :0; char y; };
+int foo1test[ sizeof (struct foo1) == 2 ? 1 : -1 ];
+int foo2test[ sizeof (struct foo2) == 5 ? 1 : -1]; ],
+  [], gt_cv_bitfield_type_matters=yes, gt_cv_bitfield_type_matters=no)
+  ])
+  if test $gt_cv_bitfield_type_matters = yes; then
+AC_DEFINE(HAVE_BITFIELD_TYPE_MATTERS, 1,
+  [Define if the type of bitfields effects alignment.])
+  fi
+])
diff --git a/libobjc/acinclude.m4 b/libobjc/acinclude.m4
index bf78dbe..4193018 100644
--- a/libobjc/acinclude.m4
+++ b/libobjc/acinclude.m4
@@ -12,6 +12,7 @@ m4_include(../config/acx.m4)
 m4_include(../config/no-executables.m4)
 m4_include(../config/enable.m4)
 m4_include(../config/tls.m4)
+m4_include(../config/bitfields.m4)
 
 m4_include(../libtool.m4)
 dnl The lines below arrange for aclocal not to bring an installed
diff --git a/libobjc/config.h.in b/libobjc/config.h.in
index c055e7c..20d1fca 100644
--- a/libobjc/config.h.in
+++ b/libobjc/config.h.in
@@ -1,5 +1,8 @@
 /* config.h.in.  Generated from configure.ac by autoheader.  */
 
+/* Define if the type of bitfields effects alignment. */
+#undef HAVE_BITFIELD_TYPE_MATTERS
+
 /* Define to 1 if the target assembler supports thread-local storage. */
 #undef HAVE_CC_TLS
 
diff --git a/libobjc/configure b/libobjc/configure
index 642eb9c..0547f91 100755
--- a/libobjc/configure
+++ b/libobjc/configure
@@ -11530,6 +11530,44 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_exception_model_name" >&5
 $as_echo "$ac_exception_model_name" >&6; }
 
+
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking if the type of bitfields 
matters" >&5
+$as_echo_n "checking if the type of bitfields matters... " >&6; }
+if test "${gt_cv_bitfield_type_matters+set}" = set; then :
+  $as_echo_n "(cached) " >&6
+else
+
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+struct foo1 { char x; char :0; char y; };
+struct foo2 { char x; int :0; char y; };
+int foo1test[ sizeof (struct foo1) == 2 ? 1 : -1 ];
+int foo2test[ sizeof (struct foo2) == 5 ? 1 : -1];
+int
+main ()
+{
+
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  gt_cv_bitfield_type_matters=yes
+else
+  gt_cv_bitfield_type_matters=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gt_cv_bitfield_type_matters" 
>&5
+$as_echo "$gt_cv_bitfield_type_matters" >&6; }
+  if test $gt_cv_bitfield_type_matters = yes; then
+
+$as_echo "#define HAVE_BITFIELD_TYPE_MATTERS 1" >>confdefs.h
+
+  fi
+
+
 # --
 # Output
 # --
diff --git a/libobjc/configure.ac b/libobjc/configure.ac
index c794a80..2d88519 100644
--- a/libobjc/configure.ac
+++ b/libobjc/configure.ac
@@ -266,6 +266,8 @@ fi
 AC_LANG_POP(C)
 AC_MSG_RESULT($ac_exception_model_name)
 
+gt_BITFIELD_TYPE_MATTERS
+
 # --
 # Output
 # --
diff --git a/libobjc/encoding.c b/libobjc/encoding.c
index 20ace46..abb6

Re: [Patch] pr65779 - [5/6 Regression] undefined local symbol on powerpc

2015-05-01 Thread Alan Modra
On Tue, Apr 21, 2015 at 02:30:15PM +0200, Jakub Jelinek wrote:
> This isn't safe.  There could be a debug_insn for the same decl anywhere in
> between the dinsn and bb_note (bb) on the chosen live path, if there is,
> this change will break stuff.

Yeah, I see now that what I was trying to do can't be done so easily.
In fact, the more I look at debug_insns the less sure I am of any
solution other than simply zapping them with UNKNOWN_VAR_LOC.
However, I'm not going to write such a patch.  Simply because I don't
want to be responsible for even more cases where "print var" in gdb
gets "" and upon examing the disassembly you can easily
determine that "var" is live in some register.

One of the potential problems I've discovered is that debug_insns do
not satisfy an assumption made by propagate_for_debug, that they are
always located immediately after their associated insn.  For example,
gcc-5 branch on x86_64 varasm.c:hashtab_entry_note_pointers has this
in vregs pass:

(code_label 18 17 19 5 57 "" [1 uses])
(note 19 18 7 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 7 19 40 5 (set (reg/v:DI 91 [ i ])
(const_int 0 [0])) /src/gcc-5-cur/gcc/hash-table.h:1723 89 
{*movdi_internal}
 (nil))
;;  succ:   6 [100.0%]  (FALLTHRU)

;; basic block 6, loop depth 1, count 0, freq 9100, maybe hot
;;  prev block 5, next block 7, flags: (NEW, REACHABLE, RTL)
;;  pred:   5 [100.0%]  (FALLTHRU)
;;  8 [100.0%] 
(code_label 40 7 20 6 60 "" [1 uses])
(note 20 40 21 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(debug_insn 21 20 22 6 (var_location:DI i (reg/v:DI 91 [ i ])) -1
 (nil))

OK, so that particular example can't cause a problem with combine's
use of propagate_for_debug but something like the above would break
what I'm trying to do in shrink_wrap.


Here's another problem, x86_64 varasm.c again, last occurrence of
valid0 in debug, cprop1:

(debug_insn 858 629 630 104 (var_location:DI D#293 (reg:DI 0 ax)) -1
 (nil))
(insn 630 858 631 104 (set (reg/v/f:DI 195 [ ret ])
(reg:DI 0 ax)) /src/gcc-5-cur/gcc/varasm.c:4541 89 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 0 ax)
(nil)))
(debug_insn 631 630 633 104 (var_location:DI valid0 (debug_expr:DI D#293)) 
/src/gcc-5-cur/gcc/varasm.c:4541 -1
 (nil))

Now that seems just plain wrong to me.  This is just after a call.
After insn 630 valid0 lives in reg 195, not reg 0 as the debug_insn
says.  What I'm concerned about as far as fixing shrink_wrap is
whether this sort of thing can occur in correct debug expressions,
ie. if debug_isns 858 said D#293 is equal to reg 195.  We'd have part
of the debug info about valid0 *before* the insn setting reg 195.
As far as I can tell, sched doesn't create this sort of problem.
Note that prior to cprop1, we just had
(insn 630 629 631 93 (set (reg/v/f:DI 195 [ ret ])
(reg:DI 0 ax)) /src/gcc-5-cur/gcc/varasm.c:4541 89 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 0 ax)
(nil)))
(debug_insn 631 630 633 93 (var_location:DI valid0 (reg/v/f:DI 195 [ ret ])) 
/src/gcc-5-cur/gcc/varasm.c:4541 -1
 (nil))


Anyway, here's my best attempt at fixing PR65779.  If it isn't
acceptable I'm going to have to leave this problem to someone else,
not because I'm uninterested in fixing it properly, but because I'm
being asked to work on other things by my employer..

Bootstrapped and regression tested powerpc64-linux and x86_64-linux.

gcc/
PR debug/65779
* shrink-wrap.c (insn_uses_reg): New function.
(move_insn_for_shrink_wrap): Try to fix up debug insns related
to the moved insn.
gcc/testsuite/
* gcc.dg/pr65779.c: New.

Index: gcc/shrink-wrap.c
===
--- gcc/shrink-wrap.c   (revision 222708)
+++ gcc/shrink-wrap.c   (working copy)
@@ -79,6 +79,7 @@
 #include "shrink-wrap.h"
 #include "regcprop.h"
 #include "rtl-iter.h"
+#include "valtrack.h"
 
 #ifdef HAVE_simple_return
 
@@ -182,6 +183,24 @@
   return live_edge;
 }
 
+/* Return true if INSN df shows a use of a reg in the range
+   [REGNO,END_REGNO).  */
+
+static bool
+insn_uses_reg (rtx_insn *insn, unsigned int regno, unsigned int end_regno)
+{
+  df_ref use;
+
+  FOR_EACH_INSN_USE (use, insn)
+{
+  rtx reg = DF_REF_REG (use);
+
+  if (REG_P (reg) && REGNO (reg) >= regno && REGNO (reg) < end_regno)
+   return true;
+}
+  return false;
+}
+
 /* Try to move INSN from BB to a successor.  Return true on success.
USES and DEFS are the set of registers that are used and defined
after INSN in BB.  SPLIT_P indicates whether a live edge from BB
@@ -193,7 +212,7 @@
   const HARD_REG_SET defs,
   bool *split_p)
 {
-  rtx set, src, dest;
+  rtx set, src, orig_src, dest;
   bitmap live_out, live_in, bb_uses, bb_defs;
   unsigned int i, dregno, end_dregno;
   unsigned int sregno = FIRST_PSEUDO_REGISTER;
@@ -209,7 +228,7 @@
   set = PATTERN (insn);
   if (GET_CODE (set) != SET)
 return fal

Re: [libstdc++ PATCH] Implement observer_ptr

2015-05-01 Thread Ed Smith-Rowland

On 05/01/2015 05:01 PM, Jonathan Wakely wrote:

On 01/05/15 16:37 +0300, Ville Voutilainen wrote:

Tested on Linux-x64.

   Implement observer_ptr.


Thanks! Committed with some minor formatting changes.

I've also committed this to add feature-test macros and update the
docs. Tested powerpc64le-linux, committed to trunk.


I pretty sure we're supposed to add the macro for *all* the headers that 
got enable_if.


I actually went ahead and did this on 222713.

2015-05-02  Edward Smith-Rowland  <3dw...@verizon.net>

* include/experimental/deque: Add feature-test macro.
* include/experimental/forward_list: Ditto.
* include/experimental/list: Ditto.
* include/experimental/map: Ditto.
* include/experimental/set: Ditto.
* include/experimental/string: Ditto.
* include/experimental/unordered_map: Ditto.
* include/experimental/unordered_set: Ditto.




[PATCH 4/4] Replace line_map union with C++ class hierarchy

2015-05-01 Thread David Malcolm
This patch eliminates the union in struct line_map in favor of
a simple class hierarchy, making struct line_map a base class,
with line_map_ordinary and line_map_macro subclasses.

The patch eliminates all usage of linemap_check_ordinary and
linemap_check_macro from line-map.h, updating return types and
signatures throughout libcpp and gcc's usage of it to use the
appropriate subclasses.

This moves the checking of linemap kind from run-time to
compile-time, and also implicitly documents everywhere where
the code is expecting an ordinary map vs a macro map vs
either kind of map.  I believe it makes the code significantly
simpler: most of the accessor functions in line-map.h become
trivial field-lookups.

I attemped to use templates for maps_info, but was stymied by
gengtype, so in the end I simply split it manually into
maps_info_ordinary and maps_info_macro.  In theory it's just
a vec<>, but vec.h is in gcc, and thus not available
for use from libcpp.

In a similar vein, gcc/is-a.h is presumably not usable
from within libcpp.  If it were, there would be the following
rough equivalences:

-  
line-map.h is-a.h
-  
linemap_check_ordinary (m) as_a  (m)
linemap_check_macro (m)as_a  (m)
linemap_macro_expansion_map_p (m)  (M ? is_a  (m)
  : false)
-  

There are numerous places in libcpp that offset a
line_map * using array notation to get the next/prev line_map of the
same kind, e.g.:
MAP_START_LOCATION (&cached[1])
which breaks due to the different sizes of line_map vs its subclasses.

On x86_64 host, before:
(gdb) p sizeof(line_map)
$1 = 40

after:
(gdb) p sizeof(line_map)
$1 = 8
(gdb) p sizeof(line_map_ordinary)
$2 = 32
(gdb) p sizeof(line_map_macro)
$3 = 40

Tracking down all of these array-based offsets to use a pointer to the
appropriate subclass (and thus use the correct offset) was rather
involved, but I believe the patch fixes them all now.

(the patch thus also gives a very modest saving of 8 bytes per ordinary
line map).

I've tried to use the naming convention "ord_map" and "macro_map"
whenever the typesystem ensures we're dealing with such a map,
wherever this is doable without needing to touch lines of code that
would otherwise not need touching by the patch.

gcc/ChangeLog:
* diagnostic.c (diagnostic_report_current_module): Strengthen
local "new_map" from const line_map * to
const line_map_ordinary *.
* genmatch.c (error_cb): Likewise for local "map".
(output_line_directive): Likewise for local "map".
* input.c (expand_location_1): Likewise for local "map".
Pass NULL rather than &map to
linemap_unwind_to_first_non_reserved_loc, since the value is never
read from there, and the value written back not read from here.
(is_location_from_builtin_token): Strengthen local "map" from
const line_map * to const line_map_ordinary *.
(dump_location_info): Strengthen locals "map" from
line_map *, one to const line_map_ordinary *, the other
to const line_map_macro *.
* tree-diagnostic.c (loc_map_pair): Strengthen field "map" from
const line_map * to const line_map_macro *.
(maybe_unwind_expanded_macro_loc): Add a call to
linemap_check_macro when writing to the "map" field of the
loc_map_pair.
Introduce local const line_map_ordinary * "ord_map", using it in
place of "map" in the part of the function where we know we have
an ordinary map.  Strengthen local "m" from const line_map * to
const line_map_ordinary *.

gcc/ada/ChangeLog:
* gcc-interface/trans.c (Sloc_to_locus1): Strenghthen local "map"
from line_map * to line_map_ordinary *.

gcc/c-family/ChangeLog:
* c-common.h (fe_file_change): Strengthen param from
const line_map * to const line_map_ordinary *.
(pp_file_change): Likewise.
* c-lex.c (fe_file_change): Likewise.
(cb_define): Use linemap_check_ordinary when invoking
SOURCE_LINE.
(cb_undef): Likewise.
* c-opts.c (c_finish_options): Use linemap_check_ordinary when
invoking cb_file_change.
(c_finish_options): Likewise.
(push_command_line_include): Likewise.
(cb_file_change): Strengthen param "new_map" from
const line_map * to const line_map_ordinary *.
* c-ppoutput.c (cb_define): Likewise for local "map".
(pp_file_change): Likewise for param "map" and local "from".

gcc/fortran/ChangeLog:
* cpp.c (maybe_print_line): Strengthen local "map" from
const line_map * to const line_map_ordinary *.
(cb_file_change): Likewise for param "map" and local "from".
(cb_line_change): Likewise for local "map".

[PATCH 3/4] libcpp/input.c: Add a way to visualize the linemaps

2015-05-01 Thread David Malcolm
As a relative newcomer to GCC, one of the issues I had was
becoming comfortable with the linemap API and its internal
representation.

To familiarize myself with it, I wrote a dumping routine
to try to visualize how the source_location space is carved
up between line maps, and what each number can mean.

It struck me that this would benefit others, so this patch
adds this visualization, via an undocumented option
-fdump-locations, and adds a text file to libcpp's sources
documenting a simple example of compiling a small C file,
with a header and macro expansions (built using the
-fdump-locations option and a little hand-editing).

gcc/ChangeLog:
* common.opt (fdump-locations): New option.
* input.c: Include diagnostic-core.h.
(get_end_location): New function.
(write_digit): New function.
(write_digit_row): New function.
(dump_location_range): New function.
(dump_labelled_location_range): New function.
(dump_location_info): New function.
* input.h (dump_location_info): New prototype.
* toplev.c (compile_file): Handle flag_dump_locations.

libcpp/ChangeLog:
* include/line-map.h (source_location): Add a reference to
location-example.txt to the descriptive comment.
* location-example.txt: New file.
---
 gcc/common.opt  |   4 +
 gcc/input.c | 237 
 gcc/input.h |   2 +
 gcc/toplev.c|   3 +
 libcpp/include/line-map.h   |   4 +-
 libcpp/location-example.txt | 216 
 6 files changed, 465 insertions(+), 1 deletion(-)
 create mode 100644 libcpp/location-example.txt

diff --git a/gcc/common.opt b/gcc/common.opt
index 380848c..444a73a 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1166,6 +1166,10 @@ Common Driver Var(flag_report_bug)
 Collect and dump debug information into temporary file if ICE in C/C++
 compiler occured.
 
+fdump-locations
+Common Var(flag_dump_locations) Init(0)
+Dump detailed information on GCC's internal representation of source code 
locations
+
 fdump-passes
 Common Var(flag_dump_passes) Init(0)
 Dump optimization passes
diff --git a/gcc/input.c b/gcc/input.c
index 18c1e50..922c2f1 100644
--- a/gcc/input.c
+++ b/gcc/input.c
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "intl.h"
 #include "input.h"
 #include "vec.h"
+#include "diagnostic-core.h"
 
 /* This is a cache used by get_next_line to store the content of a
file to be searched for file lines.  */
@@ -869,3 +870,239 @@ dump_line_table_statistics (void)
STAT_LABEL (total_used_map_size));
   fprintf (stderr, "\n");
 }
+
+/* Get location one beyond the final location in ordinary map IDX.  */
+
+static source_location
+get_end_location (struct line_maps *set, unsigned int idx)
+{
+  if (idx == LINEMAPS_ORDINARY_USED (set) - 1)
+return set->highest_location;
+
+  struct line_map *next_map = LINEMAPS_ORDINARY_MAP_AT (set, idx + 1);
+  return MAP_START_LOCATION (next_map);
+}
+
+/* Helper function for write_digit_row.  */
+
+static void
+write_digit (FILE *stream, int digit)
+{
+  fputc ('0' + (digit % 10), stream);
+}
+
+/* Helper function for dump_location_info.
+   Write a row of numbers to STREAM, numbering a source line,
+   giving the units, tens, hundreds etc of the column number.  */
+
+static void
+write_digit_row (FILE *stream, int indent,
+source_location loc, int max_col, int divisor)
+{
+  fprintf (stream, "%*c", indent, ' ');
+  fprintf (stream, "|");
+  for (int column = 1; column < max_col; column++)
+{
+  source_location column_loc = loc + column;
+  write_digit (stream, column_loc / divisor);
+}
+  fprintf (stream, "\n");
+}
+
+/* Write a half-closed (START) / half-open (END) interval of
+   source_location to STREAM.  */
+
+static void
+dump_location_range (FILE *stream,
+source_location start, source_location end)
+{
+  fprintf (stream,
+  "  source_location interval: %u <= loc < %u\n",
+  start, end);
+}
+
+/* Write a labelled description of a half-closed (START) / half-open (END)
+   interval of source_location to STREAM.  */
+
+static void
+dump_labelled_location_range (FILE *stream,
+ const char *name,
+ source_location start, source_location end)
+{
+  fprintf (stream, "%s\n", name);
+  dump_location_range (stream, start, end);
+  fprintf (stream, "\n");
+}
+
+/* Write a visualization of the locations in the line_table to STREAM.  */
+
+void
+dump_location_info (FILE *stream)
+{
+  if (0)
+line_table_dump (stream,
+line_table,
+LINEMAPS_ORDINARY_USED (line_table),
+LINEMAPS_MACRO_USED (line_table));
+
+  /* Visualize the reserved locations.  */
+  dump_labelled_location_range (stream, "RESERVED LOCATIONS",
+   

[PATCH 2/4] libcpp: Replace macro usage with C++ constructs

2015-05-01 Thread David Malcolm
libcpp makes extensive use of the C preprocessor.  Whilst this has a
pleasingly self-referential quality, I find the code hard-to-read;
implementing source location support in my JIT branch was much harder than
I felt it should have been.

In an attempt at making the code easier to follow, and to build towards
a followup patch, this patch converts most of these macros to C++
equivalents: using "const" for compile-time constants, and inline
functions where macros aren't used as lvalues.

This effectively documents the expected types of the params, and makes
them available from the debugger e.g.:

  (gdb) p LINEMAP_FILE ($3)
  $1 = 0x13b8b37 ""

and indeed the constants also:

  (gdb) p IS_ADHOC_LOC(MAX_SOURCE_LOCATION)
  $2 = false
  (gdb) p IS_ADHOC_LOC(MAX_SOURCE_LOCATION + 1)
  $3 = true

[I didn't mark the inline functions as "static"; should they be?]

[FWIW, I posted a reduced version of this patch about a year ago as:
  https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01092.html
which covered a smaller subset of the macros].

libcpp/ChangeLog:
* include/line-map.h (MAX_SOURCE_LOCATION): Convert from a macro
to a const source_location.
(RESERVED_LOCATION_COUNT): Likewise.
(linemap_check_ordinary): Convert from a macro to a pair of inline
functions, for const/non-const arguments.
(MAP_START_LOCATION): Likewise.
(ORDINARY_MAP_STARTING_LINE_NUMBER): Likewise.
(ORDINARY_MAP_INCLUDER_FILE_INDEX): Likewise.
(ORDINARY_MAP_IN_SYSTEM_HEADER_P): Likewise.
(ORDINARY_MAP_NUMBER_OF_COLUMN_BITS): Convert from a macro to a
pair of inline functions, for const/non-const arguments, where the
latter is named...
(SET_ORDINARY_MAP_NUMBER_OF_COLUMN_BITS): New function.
(ORDINARY_MAP_FILE_NAME): Convert from a macro to a pair of inline
functions, for const/non-const arguments.
(MACRO_MAP_MACRO): Likewise.
(MACRO_MAP_NUM_MACRO_TOKENS): Likewise.
(MACRO_MAP_LOCATIONS): Likewise.
(MACRO_MAP_EXPANSION_POINT_LOCATION): Likewise.
(LINEMAPS_MAP_INFO): Likewise.
(LINEMAPS_MAPS): Likewise.
(LINEMAPS_ALLOCATED): Likewise.
(LINEMAPS_USED): Likewise.
(LINEMAPS_CACHE): Likewise.
(LINEMAPS_ORDINARY_CACHE): Likewise.
(LINEMAPS_MACRO_CACHE): Likewise.
(LINEMAPS_MAP_AT): Convert from a macro to an inline function.
(LINEMAPS_LAST_MAP): Likewise.
(LINEMAPS_LAST_ALLOCATED_MAP): Likewise.
(LINEMAPS_ORDINARY_MAPS): Likewise.
(LINEMAPS_ORDINARY_MAP_AT): Likewise.
(LINEMAPS_ORDINARY_ALLOCATED): Likewise.
(LINEMAPS_ORDINARY_USED): Likewise.
(LINEMAPS_LAST_ORDINARY_MAP): Likewise.
(LINEMAPS_LAST_ALLOCATED_ORDINARY_MAP): Likewise.
(LINEMAPS_MACRO_MAPS): Likewise.
(LINEMAPS_MACRO_MAP_AT): Likewise.
(LINEMAPS_MACRO_ALLOCATED): Likewise.
(LINEMAPS_MACRO_USED): Likewise.
(LINEMAPS_MACRO_LOWEST_LOCATION): Likewise.
(LINEMAPS_LAST_MACRO_MAP): Likewise.
(LINEMAPS_LAST_ALLOCATED_MACRO_MAP): Likewise.
(IS_ADHOC_LOC): Likewise.
(COMBINE_LOCATION_DATA): Likewise.
(SOURCE_LINE): Likewise.
(SOURCE_COLUMN): Likewise.
(LAST_SOURCE_LINE_LOCATION): Likewise.
(LAST_SOURCE_LINE): Likewise.
(LAST_SOURCE_COLUMN): Likewise.
(LAST_SOURCE_LINE_LOCATION)
(INCLUDED_FROM): Likewise.
(MAIN_FILE_P): Likewise.
(LINEMAP_FILE): Likewise.
(LINEMAP_LINE): Likewise.
(LINEMAP_SYSP): Likewise.
(linemap_location_before_p): Likewise.
* line-map.c (linemap_check_files_exited): Make local "map" const.
(linemap_add): Use SET_ORDINARY_MAP_NUMBER_OF_COLUMN_BITS.
(linemap_line_start): Likewise.
---
 libcpp/include/line-map.h | 533 ++
 libcpp/line-map.c |   6 +-
 2 files changed, 397 insertions(+), 142 deletions(-)

diff --git a/libcpp/include/line-map.h b/libcpp/include/line-map.h
index e1681ea..021ca6e 100644
--- a/libcpp/include/line-map.h
+++ b/libcpp/include/line-map.h
@@ -155,7 +155,7 @@ struct GTY(()) line_map_ordinary {
 
 /* This is the highest possible source location encoded within an
ordinary or macro map.  */
-#define MAX_SOURCE_LOCATION 0x7FFF
+const source_location MAX_SOURCE_LOCATION = 0x7FFF;
 
 struct cpp_hashnode;
 
@@ -279,30 +279,168 @@ struct GTY(()) line_map {
   } GTY((desc ("%1.reason == LC_ENTER_MACRO"))) d;
 };
 
-#define MAP_START_LOCATION(MAP) (MAP)->start_location
+#if defined ENABLE_CHECKING && (GCC_VERSION >= 2007)
+
+/* Assertion macro to be used in line-map code.  */
+#define linemap_assert(EXPR)  \
+  do {\
+if (! (EXPR)) \
+  abort ();   \
+  } while (0)
+
+/* Assert that becomes a conditional expression

[PATCH 0/4] libcpp patches

2015-05-01 Thread David Malcolm
The following patches for libcpp (and gcc) are an attempt at making
the libcpp API and internal representation easier to understand
and to hack on, simplifying it (IMHO) with a modest amount of C++,
without changing its behavior.

See the individual patches for their descriptions.

How do these look? (for trunk)

I've successfully bootstrapped®rtested the cumulative effect of the
patches on x86_64-unknown-linux-gnu (Fedora 20).  I would verify the
bootstrap®rtest of each patch before applying them.

I didn't do any performance testing; what would be appropriate?

David Malcolm (4):
  libcpp: Improvements to comments in line-map.h/c
  libcpp: Replace macro usage with C++ constructs
  libcpp/input.c: Add a way to visualize the linemaps
  Replace line_map union with C++ class hierarchy

 gcc/ada/gcc-interface/trans.c |   2 +-
 gcc/c-family/c-common.h   |   4 +-
 gcc/c-family/c-lex.c  |   6 +-
 gcc/c-family/c-opts.c |  14 +-
 gcc/c-family/c-ppoutput.c |   6 +-
 gcc/common.opt|   4 +
 gcc/diagnostic.c  |   2 +-
 gcc/fortran/cpp.c |  12 +-
 gcc/genmatch.c|   4 +-
 gcc/input.c   | 244 +-
 gcc/input.h   |   2 +
 gcc/toplev.c  |   3 +
 gcc/tree-diagnostic.c |   9 +-
 libcpp/directives.c   |  17 +-
 libcpp/files.c|   2 +-
 libcpp/include/cpplib.h   |   2 +-
 libcpp/include/line-map.h | 735 +++---
 libcpp/internal.h |  12 +-
 libcpp/line-map.c | 243 --
 libcpp/location-example.txt   | 216 +
 libcpp/macro.c|  18 +-
 21 files changed, 1204 insertions(+), 353 deletions(-)
 create mode 100644 libcpp/location-example.txt

-- 
1.8.5.3



[PATCH 1/4] libcpp: Improvements to comments in line-map.h/c

2015-05-01 Thread David Malcolm
This patch updates and expands some comments in libcpp, adding
a big table to try to clarify what an individual source_location
value can mean.

libcpp/ChangeLog:
* include/line-map.h: Fix comment at the top of the file.
(source_location): Rewrite and expand the comment for this
typedef, adding an ascii-art table to clarify how source_location
values are allocated.
* line-map.c: Fix comment at the top of the file.
---
 libcpp/include/line-map.h | 71 +--
 libcpp/line-map.c |  2 +-
 2 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/libcpp/include/line-map.h b/libcpp/include/line-map.h
index 403d798..e1681ea 100644
--- a/libcpp/include/line-map.h
+++ b/libcpp/include/line-map.h
@@ -1,4 +1,4 @@
-/* Map logical line numbers to (source file, line number) pairs.
+/* Map (unsigned int) keys to (source file, line, column) triples.
Copyright (C) 2001-2015 Free Software Foundation, Inc.
 
 This program is free software; you can redistribute it and/or modify it
@@ -46,7 +46,74 @@ enum lc_reason
 /* The type of line numbers.  */
 typedef unsigned int linenum_type;
 
-/* A logical line/column number, i.e. an "index" into a line_map.  */
+/* The typedef "source_location" is a key within the location database,
+   identifying a source location or macro expansion.
+
+   This key only has meaning in relation to a line_maps instance.  Within
+   gcc there is a single line_maps instance: "line_table", declared in
+   gcc/input.h and defined in gcc/input.c.
+
+   The values of the keys are intended to be internal to libcpp,
+   but for ease-of-understanding the implementation, they are currently
+   assigned as follows:
+
+  Actual | Value | Meaning
+  ---+---+---
+  0x |   | Reserved for use by libcpp
+  0x0001 | RESERVED_LOCATION_COUNT - 1   | Reserved for use by libcpp
+  ---+---+---
+  0x0002 | RESERVED_LOCATION_COUNT   | The first location to be
+ | (also | handed out, and the
+ |  ordmap[0]->start_location)   | first line in ordmap 0
+  ---+---+---
+ | ordmap[1]->start_location | First line in ordmap 1
+ | ordmap[1]->start_location+1   | First column in that line
+ | ordmap[1]->start_location+2   | 2nd column in that line
+ |   | Subsequent lines are offset by
+ |   | (1 << column_bits),
+ |   | e.g. 128 for 7 bits, with a
+ |   | column value of 0 representing
+ |   | "the whole line".
+ | ordmap[2]->start_location-1   | Final location in ordmap 1
+  ---+---+---
+ | ordmap[2]->start_location | First line in ordmap 2
+ | ordmap[3]->start_location-1   | Final location in ordmap 2
+  ---+---+---
+ |   | (etc)
+  ---+---+---
+ | ordmap[n-1]->start_location   | First line in final ord map
+ |   | (etc)
+ | set->highest_location - 1 | Final location in that ordmap
+  ---+---+---
+ | set->highest_location | Location of the where the next
+ |   | ordinary linemap would start
+  ---+---+---
+ |   |
+ |  VVV
+ |  Ordinary maps grow this way
+ |
+ |(unallocated integers)
+ |
+ |   Macro maps grow this way
+ |   
+ |   |
+  ---+---+---
+ | LINEMAPS_MACRO_LOWEST_LOCATION| Locations within macro maps
+ | macromap[m-1]->start_location | Start of last macro map
+ |   |
+  ---+---+---
+ | macromap[m-2]->start_location | Start of penultimate macro map
+  ---+---+---
+ | macromap[1]->start_location   | 

[RFA] More type narrowing in match.pd V2

2015-05-01 Thread Jeff Law

Here's an updated patch to add more type narrowing to match.pd.

Changes since the last version:

Slight refactoring of the condition by using types_match as suggested by 
Richi.  I also applied the new types_match to 2 other patterns in 
match.pd where it seemed clearly appropriate.


Additionally the transformation is restricted by using the new 
single_use predicate.  I didn't change other patterns in match.pd to use 
the new single_use predicate.  But some probably could be changed.


This (of course) continues to pass the bootstrap and regression check 
for x86-linux-gnu.


There's still a ton of work to do in this space.  This is meant to be an 
incremental stand-alone improvement.


OK now?



Jeff
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index e006b26..5ee89de 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-05-01  Jeff Law  
+
+   * match.pd (bit_and (plus/minus (convert @0) (convert @1) mask): New
+   simplifier to narrow arithmetic.
+
 2015-05-01  Rasmus Villemoes  
 
* match.pd: New simplification patterns.
diff --git a/gcc/generic-match-head.c b/gcc/generic-match-head.c
index daa56aa..303b237 100644
--- a/gcc/generic-match-head.c
+++ b/gcc/generic-match-head.c
@@ -70,4 +70,20 @@ along with GCC; see the file COPYING3.  If not see
 #include "dumpfile.h"
 #include "generic-match.h"
 
+/* Routine to determine if the types T1 and T2 are effectively
+   the same for GENERIC.  */
 
+inline bool
+types_match (tree t1, tree t2)
+{
+  return TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2);
+}
+
+/* Return if T has a single use.  For GENERIC, we assume this is
+   always true.  */
+
+inline bool
+single_use (tree t)
+{
+  return true;
+}
diff --git a/gcc/gimple-match-head.c b/gcc/gimple-match-head.c
index c7b2f95..dc13218 100644
--- a/gcc/gimple-match-head.c
+++ b/gcc/gimple-match-head.c
@@ -861,3 +861,21 @@ do_valueize (tree (*valueize)(tree), tree op)
   return op;
 }
 
+/* Routine to determine if the types T1 and T2 are effectively
+   the same for GIMPLE.  */
+
+inline bool
+types_match (tree t1, tree t2)
+{
+  return types_compatible_p (t1, t2);
+}
+
+/* Return if T has a single use.  For GIMPLE, we also allow any
+   non-SSA_NAME (ie constants) and zero uses to cope with uses
+   that aren't linked up yet.  */
+
+inline bool
+single_use (tree t)
+{
+  return TREE_CODE (t) != SSA_NAME || has_zero_uses (t) || has_single_use (t);
+}
diff --git a/gcc/match.pd b/gcc/match.pd
index 87ecaf1..51a950a 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -289,8 +289,7 @@ along with GCC; see the file COPYING3.  If not see
   (if (((TREE_CODE (@1) == INTEGER_CST
 && INTEGRAL_TYPE_P (TREE_TYPE (@0))
 && int_fits_type_p (@1, TREE_TYPE (@0)))
-   || (GIMPLE && types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)))
-   || (GENERIC && TREE_TYPE (@0) == TREE_TYPE (@1)))
+   || types_match (TREE_TYPE (@0), TREE_TYPE (@1)))
/* ???  This transform conflicts with fold-const.c doing
  Convert (T)(x & c) into (T)x & (T)c, if c is an integer
  constants (if x has signed type, the sign bit cannot be set
@@ -949,8 +948,7 @@ along with GCC; see the file COPYING3.  If not see
 /* Unordered tests if either argument is a NaN.  */
 (simplify
  (bit_ior (unordered @0 @0) (unordered @1 @1))
- (if ((GIMPLE && types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1)))
-  || (GENERIC && TREE_TYPE (@0) == TREE_TYPE (@1)))
+ (if (types_match (TREE_TYPE (@0), TREE_TYPE (@1)))
   (unordered @0 @1)))
 (simplify
  (bit_ior:c (unordered @0 @0) (unordered:c@2 @0 @1))
@@ -1054,7 +1052,7 @@ along with GCC; see the file COPYING3.  If not see
operation and convert the result to the desired type.  */
 (for op (plus minus)
   (simplify
-(convert (op (convert@2 @0) (convert@3 @1)))
+(convert (op@4 (convert@2 @0) (convert@3 @1)))
 (if (INTEGRAL_TYPE_P (type)
 /* We check for type compatibility between @0 and @1 below,
so there's no need to check that @1/@3 are integral types.  */
@@ -1070,15 +1068,45 @@ along with GCC; see the file COPYING3.  If not see
 && TYPE_PRECISION (type) == GET_MODE_PRECISION (TYPE_MODE (type))
 /* The inner conversion must be a widening conversion.  */
 && TYPE_PRECISION (TREE_TYPE (@2)) > TYPE_PRECISION (TREE_TYPE (@0))
-&& ((GENERIC 
- && (TYPE_MAIN_VARIANT (TREE_TYPE (@0))
- == TYPE_MAIN_VARIANT (TREE_TYPE (@1)))
- && (TYPE_MAIN_VARIANT (TREE_TYPE (@0))
- == TYPE_MAIN_VARIANT (type)))
-|| (GIMPLE
-&& types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1))
-&& types_compatible_p (TREE_TYPE (@0), type
+&& types_match (TREE_TYPE (@0), TREE_TYPE (@1))
+&& types_match (TREE_TYPE (@0), type)
+&& single_use (@4))
   (if (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
(convert (op @0 @1)))
   (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
  

Re: [PATCH/libiberty] fix build of gdb/binutils with clang.

2015-05-01 Thread Yunlian Jiang
The test case does not have #define _GNU_SOURCE, so it says
error: ‘asprintf’ undeclared (first use in this function)

On Fri, May 1, 2015 at 3:45 PM, Ian Lance Taylor  wrote:
> On Tue, Apr 28, 2015 at 2:59 PM, Yunlian Jiang  wrote:
>> I believe this is the same problem as
>> https://gcc.gnu.org/ml/gcc-patches/2008-07/msg00292.html
>>
>> The asprinf declaration is  messed up when using clang to build gdb.
>>
>> diff --git a/include/libiberty.h b/include/libiberty.h
>> index b33dd65..a294903 100644
>> --- a/include/libiberty.h
>> +++ b/include/libiberty.h
>> @@ -625,8 +625,10 @@ extern int pwait (int, int *, int);
>>  /* Like sprintf but provides a pointer to malloc'd storage, which must
>> be freed by the caller.  */
>>
>> +#ifndef asprintf
>>  extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;
>>  #endif
>> +#endif
>>
>>  /* Like asprintf but allocates memory without fail. This works like
>> xmalloc.  */
>
> Why is HAVE_DECL_ASPRINTF not defined?
>
> Ian


PR 64454: Improve VRP for %

2015-05-01 Thread Marc Glisse

Hello,

this patch tries to tighten a bit the range estimate for x%y. slp-perm-7.c 
started failing by vectorizing more than expected, I assumed it was a good 
thing and updated the test. I am less conservative than Jakub with 
division by 0, but I still don't really understand how empty ranges are 
supposed to be represented in VRP.


Bootstrap+testsuite on x86_64-linux-gnu.

2015-05-02  Marc Glisse  

PR tree-optimization/64454
gcc/
* tree-vrp.c (extract_range_from_binary_expr_1) :
Rewrite.
gcc/testsuite/
* gcc.dg/tree-ssa/vrp97.c: New file.
* gcc.dg/vect/slp-perm-7.c: Update.

--
Marc GlisseIndex: gcc/testsuite/gcc.dg/tree-ssa/vrp97.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/vrp97.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp97.c   (working copy)
@@ -0,0 +1,13 @@
+/* PR tree-optimization/64454 */
+/* { dg-options "-O2 -fdump-tree-vrp1" } */
+
+int f(int a, int b)
+{
+if (a < -3 || a > 13) __builtin_unreachable();
+if (b < -6 || b > 9) __builtin_unreachable();
+int c = a % b;
+return c >= -3 && c <= 8;
+}
+
+/* { dg-final { scan-tree-dump "return 1;" "vrp1" } } */
+/* { dg-final { cleanup-tree-dump "vrp1" } } */
Index: gcc/testsuite/gcc.dg/vect/slp-perm-7.c
===
--- gcc/testsuite/gcc.dg/vect/slp-perm-7.c  (revision 222708)
+++ gcc/testsuite/gcc.dg/vect/slp-perm-7.c  (working copy)
@@ -63,15 +63,15 @@ int main (int argc, const char* argv[])
 
   foo (input, output, input2, output2);
 
   for (i = 0; i < N; i++)
  if (output[i] != check_results[i] || output2[i] != check_results2[i])
abort ();
 
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect"  { target 
vect_perm } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect"  { target 
vect_perm } } } */
 /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" { 
target vect_perm } } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */
 
 
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 222708)
+++ gcc/tree-vrp.c  (working copy)
@@ -3189,40 +3189,83 @@ extract_range_from_binary_expr_1 (value_
}
}
   else
{
  extract_range_from_multiplicative_op_1 (vr, code, &vr0, &vr1);
  return;
}
 }
   else if (code == TRUNC_MOD_EXPR)
 {
-  if (vr1.type != VR_RANGE
- || range_includes_zero_p (vr1.min, vr1.max) != 0
- || vrp_val_is_min (vr1.min))
+  if (range_is_null (&vr1))
+   {
+ set_value_range_to_undefined (vr);
+ return;
+   }
+  // Some propagation of symbolic ranges should be possible
+  // at least in the unsigned case.
+  bool has_vr0 = vr0.type == VR_RANGE && !symbolic_range_p (&vr0);
+  bool has_vr1 = vr1.type == VR_RANGE && !symbolic_range_p (&vr1);
+  if (!has_vr0 && !has_vr1)
{
  set_value_range_to_varying (vr);
  return;
}
   type = VR_RANGE;
-  /* Compute MAX <|vr1.min|, |vr1.max|> - 1.  */
-  max = fold_unary_to_constant (ABS_EXPR, expr_type, vr1.min);
-  if (tree_int_cst_lt (max, vr1.max))
-   max = vr1.max;
-  max = int_const_binop (MINUS_EXPR, max, build_int_cst (TREE_TYPE (max), 
1));
-  /* If the dividend is non-negative the modulus will be
-non-negative as well.  */
-  if (TYPE_UNSIGNED (expr_type)
- || value_range_nonnegative_p (&vr0))
-   min = build_int_cst (TREE_TYPE (max), 0);
+  if (TYPE_UNSIGNED (expr_type))
+   {
+ // A % B is at most A and smaller than B.
+ min = build_int_cst (expr_type, 0);
+ if (has_vr0 && (!has_vr1 || tree_int_cst_lt (vr0.max, vr1.max)))
+   max = vr0.max;
+ else
+   max = int_const_binop (MINUS_EXPR, vr1.max,
+  build_int_cst (expr_type, 1));
+   }
   else
-   min = fold_unary_to_constant (NEGATE_EXPR, expr_type, max);
+   {
+ tree min1 = NULL_TREE;
+ tree max1 = NULL_TREE;
+ if (has_vr1)
+   {
+ // ABS (A % B) < ABS (B)
+ max1 = fold_unary_to_constant (ABS_EXPR, expr_type, vr1.min);
+ if (tree_int_cst_lt (max1, vr1.max))
+   max1 = vr1.max;
+ max1 = int_const_binop (MINUS_EXPR, max1,
+ build_int_cst (expr_type, 1));
+ min1 = fold_unary_to_constant (NEGATE_EXPR, expr_type, max1);
+   }
+ if (has_vr0)
+   {
+ // Either 0 <= A % B <= A or A <= A % B <= 0.
+ max = vr0.max;
+ min = vr0.min;
+ tree zero = build_int_cst (expr_type, 0);
+ if (tree_int_cst_lt (zero, min))
+   min = zero;
+ if (tree_int_cst

Re: [PATCH/libiberty] fix build of gdb/binutils with clang.

2015-05-01 Thread Ian Lance Taylor
On Tue, Apr 28, 2015 at 2:59 PM, Yunlian Jiang  wrote:
> I believe this is the same problem as
> https://gcc.gnu.org/ml/gcc-patches/2008-07/msg00292.html
>
> The asprinf declaration is  messed up when using clang to build gdb.
>
> diff --git a/include/libiberty.h b/include/libiberty.h
> index b33dd65..a294903 100644
> --- a/include/libiberty.h
> +++ b/include/libiberty.h
> @@ -625,8 +625,10 @@ extern int pwait (int, int *, int);
>  /* Like sprintf but provides a pointer to malloc'd storage, which must
> be freed by the caller.  */
>
> +#ifndef asprintf
>  extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;
>  #endif
> +#endif
>
>  /* Like asprintf but allocates memory without fail. This works like
> xmalloc.  */

Why is HAVE_DECL_ASPRINTF not defined?

Ian


Re: [wwwdocs, committed] gcc-5/changes.html: Update Fortran section

2015-05-01 Thread Gerald Pfeifer
On Sun, 31 Aug 2014, Tobias Burnus wrote:
> I have committed the attached patch. Comment and suggestions are welcome!

I applied the small follow-up below.

What I am struggling to understand, though, is the following piece:

   Full experimental support of Fortran 2008's coarrays with
   -fcoarray=lib except for locking and allocatable/pointer
   components of derived-type coarrays.

Does this mean it is only supported when -fcoarray=lib is provided?
If so, I'd say that more explicitly.

And perhaps split off the second half into something like "(Only
locking and... are not provided yet)".

What is "full experimental support", by the way?  Just "experimental"?

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.116
diff -u -r1.116 changes.html
--- changes.html22 Apr 2015 12:43:34 -  1.116
+++ changes.html1 May 2015 22:40:33 -
@@ -537,7 +537,7 @@
 
 
 The -Wuse-without-only option has been added to warn when 
a
-  USE statement has no ONLY qualifier and, thus,
+  USE statement has no ONLY qualifier and thus
   implicitly imports all public entities of the used module.
 Formatted READ and WRITE statements now work correctly in locale-aware
   programs.  For more information and potential caveats, see


Re: [libstdc++ PATCH] Implement observer_ptr

2015-05-01 Thread Jonathan Wakely

On 01/05/15 22:01 +0100, Jonathan Wakely wrote:

On 01/05/15 16:37 +0300, Ville Voutilainen wrote:

Tested on Linux-x64.

  Implement observer_ptr.


Thanks! Committed with some minor formatting changes.

I've also committed this to add feature-test macros and update the
docs. Tested powerpc64le-linux, committed to trunk.


Thanks to Ville for pointing out that I put the wrong macro. Doh.

Committed to trunk.
commit f6fdadce0e8362d8ccaf0bdf024e1d9ac73afeaa
Author: Jonathan Wakely 
Date:   Fri May 1 22:22:19 2015 +0100

	* include/experimental/memory: Correct feature-test macro.

diff --git a/libstdc++-v3/include/experimental/memory b/libstdc++-v3/include/experimental/memory
index f43621f..08a6b33 100644
--- a/libstdc++-v3/include/experimental/memory
+++ b/libstdc++-v3/include/experimental/memory
@@ -52,7 +52,7 @@ inline namespace fundamentals_v2
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-#define __cpp_lib_experimental_not_fn 201411
+#define __cpp_lib_experimental_observer_ptr 201411
 
   template 
 class observer_ptr


Re: [Patch, Fortran] Simplify lbound

2015-05-01 Thread Mikael Morin
Hello,

Le 30/04/2015 20:19, Mikael Morin a écrit :
>>> As you may want to simplify in the limited scope of the matmul inlining,
>>> I'm giving comments about the patch (otherwise you can ignore them):
>>>  - No need to check for allocatable or pointer, it should be excluded by
>>> as->type == AS_ASSUMED_SHAPE (but does no harm either).
>>
>> Actually, no.  You can have assumed-shape allocatable or pointer
>> dummy arguments which keep their original lbound; see the subroutine
>> 'bar' in the test case.
>>
>>>  - Please modify the early return condition:
>>>  if (as && (as->type == AS_DEFERRED || as->type == AS_ASSUMED_SHAPE
>>> || as->type == AS_ASSUMED_RANK))
>>>return NULL;
>>>and let the existing code do the simplification work.
>>
>> That is not part of my patch.
>>
> I'm not sure I expressed what I was asking for clearly enough.
> Anyway, I may as well submit the requested changes myself.
> 
I present here the announced above follow-up change to Thomas' recent
bound simplification patch.

It basically removes the code added and tighten the condition
mentioned above, so that we don't give up too early to simplify the
lbound of an assumed shape array, and let the existing code do the
simplification.

To not regression wrt to Thomas work, I had to also adjust early
give-ups in simplify_bound_dim.
But the code has been reorganized, so that it doesn't appear clearly.
The declared bound and empty bound value have been abstracted
from the differentiated lbound/ubound specifics.  Then the
simplification is applied indifferently on those abstractions.
Finally, the empty array tricks have been disabled for the CO{L,U}BOUND
intrinsics.

With these changes, Thomas' tests continue to work and one gets DIM-less
bound simplification "for free".

The testsuite adds tests for zero sized arrays and DIM-less {L,U}BOUND
calls.
I had to remove the check for absence of string "bound" in the dump:
there is code generated for assumed shape arrays that plays tricks with
bounds and contains that string, even if the code generated for the body
itself of the procedure is empty.

Regression tested on x86_64-unknown-linux-gnu.  OK for trunk?

Mikael




2015-05-01  Mikael Morin  

* simplify.c (simplify_bound_dim): Don't check for emptyness
in the case of cobound simplification.  Factor lower/upper
bound differenciation before the actual simplification.
(simplify_bound): Remove assumed shape specific simplification.  
Don't give up early for the lbound of an assumed shape.

2015-05-01  Mikael Morin  

* gfortran.dg/bound_simplification_4.f90: Disable implicit typing.
Add checks for bound simplification without DIM argument.
Add checks for empty array and assumed shape bound simplification.
Remove check for absence of string "bound" in the dump.

Index: fortran/simplify.c
===
--- fortran/simplify.c	(révision 222681)
+++ fortran/simplify.c	(copie de travail)
@@ -3340,29 +3340,43 @@ simplify_bound_dim (gfc_expr *array, gfc_expr *kin
   /* Then, we need to know the extent of the given dimension.  */
   if (coarray || (ref->u.ar.type == AR_FULL && !ref->next))
 {
+  gfc_expr *declared_bound;
+  int empty_bound;
+  bool constant_lbound, constant_ubound;
+
   l = as->lower[d-1];
   u = as->upper[d-1];
 
-  if (l->expr_type != EXPR_CONSTANT || u == NULL
-	  || u->expr_type != EXPR_CONSTANT)
+  gcc_assert (l != NULL);
+
+  constant_lbound = l->expr_type == EXPR_CONSTANT;
+  constant_ubound = u && u->expr_type == EXPR_CONSTANT;
+
+  empty_bound = upper ? 0 : 1;
+  declared_bound = upper ? u : l;
+
+  if ((!upper && !constant_lbound)
+	  || (upper && !constant_ubound))
 	goto returnNull;
 
-  if (mpz_cmp (l->value.integer, u->value.integer) > 0)
+  if (!coarray)
 	{
-	  /* Zero extent.  */
-	  if (upper)
-	mpz_set_si (result->value.integer, 0);
+	  /* For {L,U}BOUND, the value depends on whether the array
+	 is empty.  We can nevertheless simplify if the declared bound
+	 has the same value as that of an empty array, in which case
+	 the result isn't dependent on the array emptyness.  */
+	  if (mpz_cmp_si (declared_bound->value.integer, empty_bound) == 0)
+	mpz_set_si (result->value.integer, empty_bound);
+	  else if (!constant_lbound || !constant_ubound)
+	/* Array emptyness can't be determined, we can't simplify.  */
+	goto returnNull;
+	  else if (mpz_cmp (l->value.integer, u->value.integer) > 0)
+	mpz_set_si (result->value.integer, empty_bound);
 	  else
-	mpz_set_si (result->value.integer, 1);
+	mpz_set (result->value.integer, declared_bound->value.integer);
 	}
   else
-	{
-	  /* Nonzero extent.  */
-	  if (upper)
-	mpz_set (result->value.integer, u->value.integer);
-	  else
-	mpz_set (result->value.integer, l->value.integer);
-	}
+	mpz_set (result->value.intege

Re: [libstdc++ PATCH] Implement observer_ptr

2015-05-01 Thread Jonathan Wakely

On 01/05/15 16:37 +0300, Ville Voutilainen wrote:

Tested on Linux-x64.

   Implement observer_ptr.


Thanks! Committed with some minor formatting changes.

I've also committed this to add feature-test macros and update the
docs. Tested powerpc64le-linux, committed to trunk.


commit 2606fe20721608c2d6f6c95f1748e53640796745
Author: Jonathan Wakely 
Date:   Fri May 1 21:51:48 2015 +0100

	* include/experimental/memory: Add feature-test macro.
	* include/experimental/vector: Likewise.
	* doc/xml/manual/status_cxx2017.xml: Update status.
	* doc/html/manual/status.html: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
index b08e1b1..80dd050 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -233,14 +233,13 @@ not in any particular release.
 
 
 
-  
   
 	http://www.w3.org/1999/xlink"; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf";>
 	  N4282
 	
   
   The World's Dumbest Smart Pointer
-  N
+  Y
   Library Fundamentals 2 TS
 
 
diff --git a/libstdc++-v3/include/experimental/memory b/libstdc++-v3/include/experimental/memory
index d3c9509..f43621f 100644
--- a/libstdc++-v3/include/experimental/memory
+++ b/libstdc++-v3/include/experimental/memory
@@ -52,6 +52,8 @@ inline namespace fundamentals_v2
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
+#define __cpp_lib_experimental_not_fn 201411
+
   template 
 class observer_ptr
 {
diff --git a/libstdc++-v3/include/experimental/vector b/libstdc++-v3/include/experimental/vector
index 245e034..37645a1 100644
--- a/libstdc++-v3/include/experimental/vector
+++ b/libstdc++-v3/include/experimental/vector
@@ -46,6 +46,8 @@ inline namespace fundamentals_v2
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
+#define __cpp_lib_experimental_erase_if 201411
+
   template
 inline void
 erase_if(vector<_Tp, _Alloc>& __cont, _Predicate __pred)


Re: [rfc, stage 1] default to -fno-delete-null-pointer-checks on nios2-elf

2015-05-01 Thread Sandra Loosemore

Re https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01510.html :

On 04/15/2015 10:42 PM, Jeff Law wrote:

It looks very sane to me.  This is probably how the AVR and CR16 should
have been handled to begin with IMHO.

FWIW, I generally discourage ports overriding default options, but this
is a case where I believe it makes some sense.

Please move forward with an official submission.


I've now bootstrapped and regression-tested the previously posted patch 
on x86_64-linux-gnu, as well as retesting it on nios2-elf after updating 
my source tree to current mainline head.


Are the target-independent parts OK to commit?

-Sandra



Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Jonathan Wakely

On 01/05/15 20:38 +0100, Jonathan Wakely wrote:

On 01/05/15 21:28 +0200, Daniel Krügler wrote:

But if I read your implementation of path::compare(const path& p)
correctly it *also* may allocate memory by copying _M_pathname into a
_Cmpt object.


Yes, I agree that there's a bug here that could cause it to
std::terminate.


I was wondering whether for this comparison there exists
real need to *copy* _M_pathname (potentially exceeding the memory
limits). Wouldn't it be possible to define a _CmptRef type that for
the purpose of implementing compare(const path& p) just refers to
references of the _M_pathname and therefore doesn't need to allocate
any dynamic storage? (I should have spoken of a new type _CmptRef and
not of your existing _Cmpt).



Ah, I see what you mean (I thought you were suggesting some
improvements to _Cmpt itself ... which might be possible so I'm glad
you made me think about it :-)

I think I wrote compare() like that because it was easier, and when I
first implemented this we had COW strings so it wouldn't throw when
copying. That isn't true now, so I need to change it.


And here's the fix for this noexcept issue, it was very simple in the
end, thanks for the idea.

Tested powerpc64le-linux, committed to trunk.

commit 9c2f4abea2096bcc5e3568facf12fb3550358c6b
Author: Jonathan Wakely 
Date:   Fri May 1 20:57:21 2015 +0100

	* src/filesystem/path.cc (path::compare): Do not copy strings.

diff --git a/libstdc++-v3/src/filesystem/path.cc b/libstdc++-v3/src/filesystem/path.cc
index cc5780f..7924732 100644
--- a/libstdc++-v3/src/filesystem/path.cc
+++ b/libstdc++-v3/src/filesystem/path.cc
@@ -107,17 +107,23 @@ namespace
 int
 path::compare(const path& p) const noexcept
 {
+  struct CmptRef
+  {
+const path* ptr;
+const string_type& native() const noexcept { return ptr->native(); }
+  };
+
   if (_M_type == _Type::_Multi && p._M_type == _Type::_Multi)
 return do_compare(_M_cmpts.begin(), _M_cmpts.end(),
 		  p._M_cmpts.begin(), p._M_cmpts.end());
   else if (_M_type == _Type::_Multi)
 {
-  _Cmpt c[1] = { { p._M_pathname, p._M_type, 0 } };
+  CmptRef c[1] = { { &p } };
   return do_compare(_M_cmpts.begin(), _M_cmpts.end(), c, c+1);
 }
   else if (p._M_type == _Type::_Multi)
 {
-  _Cmpt c[1] = { { _M_pathname, _M_type, 0 } };
+  CmptRef c[1] = { { this } };
   return do_compare(c, c+1, p._M_cmpts.begin(), p._M_cmpts.end());
 }
   else


Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Jonathan Wakely

On 01/05/15 11:53 +0100, Jonathan Wakely wrote:

On 01/05/15 10:05 +0900, Luke Allardyce wrote:

This fails on mingw-w64 4.02 due to


Yay, thanks for trying it!


an extra typename:

/mnt/build/native/gcc/x86_64-w64-mingw32/libstdc++-v3/include/experimental/fs_path.h:784:35:
error: expected nested-name-specifier
 using _CharAlloc = typename __alloc_rebind<_Allocator, char>;


Oops, forgetting how to use my own alias.



readdir_r not available:

/mnt/src/gcc/libstdc++-v3/src/filesystem/dir.cc:169:46: error:
'readdir_r' was not declared in this scope
 if (int err = readdir_r(dirp, &ent, &result))


and calling opendir with a wchar_t*

/mnt/src/gcc/libstdc++-v3/src/filesystem/dir.cc:108:40: error: cannot
convert 'const value_type* {aka const wchar_t*}' to 'const char*' for
argument '1' to 'DIR* opendir(const char*)'
   if (DIR* dirp = ::opendir(p.c_str()))

/mnt/src/gcc/libstdc++-v3/src/filesystem/dir.cc:256:38: error: cannot
convert 'const value_type* {aka const wchar_t*}' to 'const char*' for
argument '1' to 'DIR* opendir(const char*)'
 if (DIR* dirp = ::opendir(p.c_str()))


Ah interesting, this means mingw supports , I was expecting
it to use the dummy definitions at the top of src/filesystem/dir.cc
(where I'd made opendir take wchar_t).

I've done some reading and am going to commit some fixes and
improvements for mingw in an hour or two. It would be great if you
could try it again after that.


I've committed the two changes attached (only tested on linux again).

patch2.txt should fix the mingw-w64 errors above, as well as the
issues Daniel reported, and should fix the error on Solaris 10

Rainer, would you be able to test with
--enable-libstdcxx-filesystem-ts before we re-enable it to build by
default on solaris* ?


patch1.txt changes path::_M_cmpts from std::list to std::vector (as
Marc suggested months ago) and fixes the pretty printer, so paths are
shown like this in GDB:

(gdb) print p
$1 = filesystem::path ""
(gdb) print c
$2 = filesystem::path "/home/jwakely" = {[root-directory] = "/", [1] = "home", [2] = 
"jwakely"}
(gdb) print r
$3 = filesystem::path "/" [root-directory]
(gdb) print h
$4 = filesystem::path "home"
(gdb) print l
$5 = filesystem::path "//host/foo/bar///baz/.//xyzzy/meta/syntactic/variable" = {[root-name] = "//host", [root-directory] = "/", [2] = "foo", [3] = 
"bar", [4] = "baz", [5] = ".", [6] = "xyzzy", [7] = "meta", [8] = "syntactic", [9] = "variable"}

That output came from debugging this code:

 path p;
 path c = current_path();
 path r = *c.begin();
 path h = *std::next(c.begin());
 path l = "//host/foo/bar///baz/.//xyzzy/meta/syntactic/variable";


Thanks everyone for testing and feedback, it's been very helpful.
commit 44990ad8ae2cafab954b9e64556fc2ca0db97d7e
Author: Jonathan Wakely 
Date:   Fri May 1 13:41:42 2015 +0100

* include/experimental/fs_path.h (path::_List): Use vector instead of
list.
* python/libstdcxx/v6/printers.py (StdExpPathPrinter): Adapt.
* src/filesystem/path.cc: Use std::prev instead of decrementing
rvalues. Fix whitespace.
* testsuite/experimental/filesystem/path/decompose/parent_path.cc:
Do not decrement iterators before begin.

diff --git a/libstdc++-v3/include/experimental/fs_path.h 
b/libstdc++-v3/include/experimental/fs_path.h
index 11b0561..e57a08b 100644
--- a/libstdc++-v3/include/experimental/fs_path.h
+++ b/libstdc++-v3/include/experimental/fs_path.h
@@ -36,7 +36,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -430,7 +430,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 string_type _M_pathname;
 
 struct _Cmpt;
-using _List = std::list<_Cmpt>;
+using _List = _GLIBCXX_STD_C::vector<_Cmpt>;
 _List _M_cmpts; // empty unless _M_type == _Type::_Multi
 _Type _M_type = _Type::_Multi;
   };
diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 37c3b9b..c6f96d7 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -984,16 +984,51 @@ class StdExpPathPrinter:
 
 def __init__ (self, typename, val):
 self.val = val
-self.list_visualizer = gdb.default_visualizer(val['_M_cmpts'])
+start = self.val['_M_cmpts']['_M_impl']['_M_start']
+finish = self.val['_M_cmpts']['_M_impl']['_M_finish']
+self.num_cmpts = int (finish - start)
+
+def _path_type(self):
+t = str(self.val['_M_type'])
+if t[-9:] == '_Root_dir':
+return "root-directory"
+if t[-10:] == '_Root_name':
+return "root-name"
+return None
 
 def to_string (self):
-path = self.val ['_M_pathname']
-if self.list_visualizer:
-list_head = self.val['_M_cmpts']['_M_impl']['_M_node']
-if list_head.address != list_head['_M_next']:
-cmpts = self.list_visualizer.to_string()
-path = "%s [Components %s]" % (path, cm

Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Jonathan Wakely

On 01/05/15 21:28 +0200, Daniel Krügler wrote:

2015-05-01 20:22 GMT+02:00 Jonathan Wakely :

On 01/05/15 19:03 +0200, Daniel Krügler wrote:


b/libstdc++-v3/src/filesystem/path.cc:

- path::compare(const path& p) const noexcept:

Shouldn't the implementation of this noexcept function not try to
create copies of path objects? Couldn't _Cmpt just hold references to
_M_pathname?


All your other comments are definitely correct and I'll make the
relevant fixes soon, but I'm not sure what you mean here, could you
clarify?


My remembrance of the difference in noexcept qualifications of

int  compare(const path& p) const noexcept;
int  compare(const string_type& s) const;
int  compare(const value_type* s) const;

is that the latter are allowed to allocate memory to be implemented as
the standard writes the corresponding functions for std::basic_string:

int compare(const basic_string& str) const noexcept;
int compare(const charT* s) const;

Returns: compare(basic_string(s)).

But if I read your implementation of path::compare(const path& p)
correctly it *also* may allocate memory by copying _M_pathname into a
_Cmpt object.


Yes, I agree that there's a bug here that could cause it to
std::terminate.


I was wondering whether for this comparison there exists
real need to *copy* _M_pathname (potentially exceeding the memory
limits). Wouldn't it be possible to define a _CmptRef type that for
the purpose of implementing compare(const path& p) just refers to
references of the _M_pathname and therefore doesn't need to allocate
any dynamic storage? (I should have spoken of a new type _CmptRef and
not of your existing _Cmpt).



Ah, I see what you mean (I thought you were suggesting some
improvements to _Cmpt itself ... which might be possible so I'm glad
you made me think about it :-)

I think I wrote compare() like that because it was easier, and when I
first implemented this we had COW strings so it wouldn't throw when
copying. That isn't true now, so I need to change it.


Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Daniel Krügler
2015-05-01 20:22 GMT+02:00 Jonathan Wakely :
> On 01/05/15 19:03 +0200, Daniel Krügler wrote:
>>
>> b/libstdc++-v3/src/filesystem/path.cc:
>>
>> - path::compare(const path& p) const noexcept:
>>
>> Shouldn't the implementation of this noexcept function not try to
>> create copies of path objects? Couldn't _Cmpt just hold references to
>> _M_pathname?
>
> All your other comments are definitely correct and I'll make the
> relevant fixes soon, but I'm not sure what you mean here, could you
> clarify?

My remembrance of the difference in noexcept qualifications of

int  compare(const path& p) const noexcept;
int  compare(const string_type& s) const;
int  compare(const value_type* s) const;

is that the latter are allowed to allocate memory to be implemented as
the standard writes the corresponding functions for std::basic_string:

int compare(const basic_string& str) const noexcept;
int compare(const charT* s) const;

Returns: compare(basic_string(s)).

But if I read your implementation of path::compare(const path& p)
correctly it *also* may allocate memory by copying _M_pathname into a
_Cmpt object. I was wondering whether for this comparison there exists
real need to *copy* _M_pathname (potentially exceeding the memory
limits). Wouldn't it be possible to define a _CmptRef type that for
the purpose of implementing compare(const path& p) just refers to
references of the _M_pathname and therefore doesn't need to allocate
any dynamic storage? (I should have spoken of a new type _CmptRef and
not of your existing _Cmpt).

> I think it would be possible to implement a path like:

Actually I was not (yet) suggesting to change your API of path, I was
only wondering whether given the existing ABI compare(const path& p)
could be implementable without need of additional dynamic memory. This
was more a kind of louder thinking, I have not fully thought whether
this not possible without changing your currently suggested ABI.

- Daniel


Re: [c++-concepts] code review

2015-05-01 Thread Andrew Sutton
> It looks like things are coming together pretty well.  What's your feeling
> about readiness to merge into the trunk?  Is the branch down to no
> regressions?

They are coming together pretty well. We have one major unit test
failure involving template introductions (Braden is working on it),
one involving constraint equivalence that I plan to tackle next week.

Other than those issues, which I hope to clear up next week, I think it's ready.

> See you on Monday!

Unfortunately, I won't be attending.

Andrew

>
>> @@ -4146,21 +4146,21 @@ build_new_function_call (tree fn, vec
>> **args, bool koenig_p,
>>if (TREE_CODE (fn) == TEMPLATE_ID_EXPR)
>>  {
>>/* If overload resolution selects a specialization of a
>> + function concept for non-dependent template arguments,
>> + the expression is true if the constraints are satisfied
>> + and false otherwise.
>>
>>   NOTE: This is an extension of Concepts Lite TS that
>>   allows constraints to be used in expressions. */
>> +  if (flag_concepts && !processing_template_decl)
>>  {
>>tree tmpl = DECL_TI_TEMPLATE (cand->fn);
>> +  tree targs = DECL_TI_ARGS (cand->fn);
>>tree decl = DECL_TEMPLATE_RESULT (tmpl);
>> +  if (DECL_DECLARED_CONCEPT_P (decl)
>> +  && !uses_template_parms (targs)) {
>> +return evaluate_function_concept (decl, targs);
>
>
> If processing_template_decl is false, uses_template_parms should always be
> false as well.
>
>> +function_concept_check_p (tree t)
>
>
>> +  tree fn = CALL_EXPR_FN (t);
>> +  if (TREE_CODE (fn) == TEMPLATE_ID_EXPR
>> +  && TREE_CODE (TREE_OPERAND (fn, 0)) == OVERLOAD)
>> +{
>> +  tree f1 = OVL_FUNCTION (TREE_OPERAND (fn, 0));
>
>
> I think you want get_first_fn here.
>
>>if (TEMPLATE_PARM_CONSTRAINTS (current_template_parms))
>> -TYPE_CANONICAL (type) = type;
>> +SET_TYPE_STRUCTURAL_EQUALITY (type);
>
>
> This seems like papering over an underlying issue.  What was the testcase
> that motivated this change?
>
>> @@ -11854,7 +11854,7 @@ tsubst_decl (tree t, tree args, tsubst_flags_t
>> complain)
>> -   if (!spec)
>> +   if (!spec && DECL_LANG_SPECIFIC (t))
>> -   if (!local_p)
>> +   if (!local_p && DECL_LANG_SPECIFIC (r))
>
>
> What motivated these changes?  From the testcase, it seems that you're
> getting here with the decl for "using TD = int", which shouldn't happen.
>
>> @@ -1159,7 +1159,6 @@ check_noexcept_r (tree *tp, int * /*walk_subtrees*/,
>> void * /*data*/)
>> -  tree type = TREE_TYPE (TREE_TYPE (fn));
>> -  if (!TYPE_NOTHROW_P (type))
>> +  if (!TYPE_NOTHROW_P (TREE_TYPE (fn)))
>
>
> The old code was incorrectly assuming that CALL_EXPR_FN is always a function
> pointer, but your new code seems to be incorrectly assuming that it's always
> a function or an expression taking the address of a function; I think this
> will break on a call to a function pointer variable.
>
>> @@ -3481,13 +3481,27 @@ cxx_eval_constant_expression (const constexpr_ctx
>> *ctx, tree t,
>>  case REQUIRES_EXPR:
>> +  if (!processing_template_decl)
>> +return evaluate_constraint_expression (t, NULL_TREE);
>> +  else
>> +*non_constant_p = true;
>> +return t;
>
>
> We shouldn't get here with a dependent REQUIRES_EXPR (or any dependent
> expression), so we shouldn't ever hit the else clause.
>
>> @@ -18063,18 +18063,41 @@ cp_parser_declarator (cp_parser* parser,
>> +  /* Function declarations may be followed by a trailing
>> + requires-clause. Declarators for function declartions
>> + are function declarators wrapping an id-declarator.
>> + If the inner declarator is anything else, it does not
>> + declare a function. These may also be reference or
>> + pointer declarators enclosing such a function declarator.
>> + In the declaration :
>> +
>> +int *f(args)
>> +
>> + the declarator is *f(args).
>> +
>> + Abstract declarators cannot have a requires-clauses
>> + because they do not declare functions. Here:
>>
>>  void f() -> int& requires false
>>
>> + The trailing return type contains an abstract declarator,
>> + and the requires-clause applies to the function
>> + declaration and not the abstract declarator.  */
>> +  if (flag_concepts && dcl_kind != CP_PARSER_DECLARATOR_ABSTRACT)
>>  {
>> +  /* We could have things like *f(args) or &f(args).
>> + Look inside references and pointers.  */
>> +  cp_declarator* p = declarator;
>> +  if (p->kind == cdk_reference || p->kind == cdk_pointer)
>> +p = p->declarator;
>> +
>> +  /* Pointers or references with no name, or functions
>> + with no name cannot have constraints.  */
>> +  if (!p || !p->declarator)
>> +return declarator;
>> +
>> +  /* Look for f(args) but not (*f)(args).  */
>> +  

Re: More type narrowing in match.pd

2015-05-01 Thread Jeff Law

On 04/30/2015 05:07 AM, Richard Biener wrote:

On Thu, Apr 30, 2015 at 12:53 PM, Marc Glisse  wrote:

On Thu, 30 Apr 2015, Richard Biener wrote:


I have in my local dev tree (so completely untested...)

@@ -1040,31 +1052,22 @@ (define_operator_list CBRT BUILT_IN_CBRT
operation and convert the result to the desired type.  */
(for op (plus minus)
   (simplify
-(convert (op (convert@2 @0) (convert@3 @1)))
+(convert (op:c@4 (convert@2 @0) (convert?@3 @1)))



I believe the :c here requires extra code further down, so we don't turn a-b
into b-a.


Indeed.  I've added :c only for minus as 5 - x can't be canonicalized to
move the constant to 2nd position which is always possible for plus.

Might be cleaner to add a separate pattern for that case.
FWIW, this is the patch that's attached to 65084 (not 47477 as I 
initially reported).  It's supposed to address one or more of the 
example loops in that testcase.


I'd like to tackle it as a follow-up.
jeff



Re: [PATCH][expr.c] PR 65358 Avoid clobbering partial argument during sibcall

2015-05-01 Thread Jeff Law

On 04/28/2015 03:54 AM, Kyrill Tkachov wrote:


On 27/04/15 21:13, Jeff Law wrote:

On 04/21/2015 11:33 AM, Kyrill Tkachov wrote:

On 21/04/15 15:09, Jeff Law wrote:

On 04/21/2015 02:30 AM, Kyrill Tkachov wrote:

   From reading config/stormy16/stormy-abi it seems to me that we
don't
pass arguments partially in stormy16, so this code would never be
called
there. That leaves pa as the potential problematic target.
I don't suppose there's an easy way to test on pa? My checkout of
binutils
doesn't seem to include a sim target for it.

No simulator, no machines in the testfarm, the box I had access to via
parisc-linux.org seems dead and my ancient PA overheats well before a
bootstrap could complete.  I often regret knowing about the backwards
way many things were done on the PA because it makes me think about
cases that only matter on dead architectures.

So what should be the action plan here? I can't add an assert on
positive result as a negative result is valid.

We want to catch the case where this would cause trouble on
pa, or change the patch until we're confident that it's fine
for pa.

That being said, reading the documentation of STACK_GROWS_UPWARD
and ARGS_GROW_DOWNWARD I'm having a hard time visualising a case
where this would cause trouble on pa.

Is the problem that in the function:

+/* Add SIZE to X and check whether it's greater than Y.
+   If it is, return the constant amount by which it's greater or
smaller.
+   If the two are not statically comparable (for example, X and Y
contain
+   different registers) return -1.  This is used in expand_push_insn to
+   figure out if reading SIZE bytes from location X will end up reading
from
+   location Y.  */
+static int
+memory_load_overlap (rtx x, rtx y, HOST_WIDE_INT size)
+{
+  rtx tmp = plus_constant (Pmode, x, size);
+  rtx sub = simplify_gen_binary (MINUS, Pmode, tmp, y);
+
+  if (!CONST_INT_P (sub))
+return -1;
+
+  return INTVAL (sub);
+}

for ARGS_GROW_DOWNWARD we would be reading 'backwards' from x,
so the function should something like the following?

So I had to go back and compile some simple examples.

References to outgoing arguments will be SP relative.  References to the
incoming arguments will be ARGP relative.  And that brings me to the
another issue.  Isn't X in this context the incoming argument slot and
the destination an outgoing argument slot?

If so, the approach of memory_load_overlap simply won't work on a target
with calling conventions like the PA.  And you might really want to
consider punting for these kind of calling conventions


Ok, thanks for the guidance.
How about this? This patch disables sibcall optimisation when
encountering a partial argument when ARGS_GROW_DOWNWARD &&
!STACK_GROWS_DOWNWARD.
Hopefully this shouldn't harm codegen on parisc if, as you say, it's
rare to have
partial arguments anyway on PA due to the large number of argument regs.

I tested this on arm and bootstrapped on x86_64.
I am now going through the process of getting access to a Debian PA
machine to
give it a test there (thanks Dave!)

Ok if testing comes clean?

Thanks,
Kyrill

2015-04-28  Kyrylo Tkachov  

 PR target/65358
 * calls.c (expand_call): Cancel sibcall optimisation when encountering
 partial argument on targets with ARGS_GROW_DOWNWARD and
 !STACK_GROWS_DOWNWARD.
 * expr.c (memory_load_overlap): New function.
 (emit_push_insn): When pushing partial args to the stack would
 clobber the register part load the overlapping part into a pseudo
 and put it into the hard reg after pushing.

2015-04-28  Honggyu Kim  

 PR target/65358
 * gcc.dg/pr65358.c: New test.
The more I think about this, the more I think it's an ugly can of worms 
and maybe we should just disable sibcalls for partial arguments.  I 
doubt it's a big performance issue in general.


In addition to the argument/stack direction stuff, I've been pondering 
the stack/frame/arg pointer issues.  Your approach assumes that the 
incoming and outgoing areas are always referenced off the same base 
register.  If they aren't, then the routine returns no overlap.


But we'd need to consider the case where we have a reference to the arg 
or frame pointer which later gets rewritten into a stack pointer 
relative address.


Is it too late at the point were you do the checks to reject the sibling 
call?  If not, then maybe the overlap routine should return a tri-state. 
 No overlap, overlap, don't know.  The last would be used when the two 
addresses use a different register.


Jeff




Re: More type narrowing in match.pd

2015-05-01 Thread Jeff Law

On 04/30/2015 03:38 PM, Marc Glisse wrote:

On Thu, 30 Apr 2015, Jeff Law wrote:


On 04/30/2015 01:17 AM, Marc Glisse wrote:


+/* This is another case of narrowing, specifically when there's an
outer
+   BIT_AND_EXPR which masks off bits outside the type of the innermost
+   operands.   Like the previous case we have to convert the operands
+   to unsigned types to avoid introducing undefined behaviour for the
+   arithmetic operation.  */
+(for op (minus plus)

No mult? or widen_mult with a different pattern? (maybe that's already
done elsewhere)

No mult.  When I worked on the pattern for 47477, supporting mult
clearly regressed the generated code -- presumably because we can
often widen the operands for free.


It would help with the testcase below, but I am willing to accept that
the cases where it hurts are more common (and guessing if it will help
or hurt may be hard), while with +- the cases that help are more common.

void f(short*a) {
   a = __builtin_assume_aligned(a,128);
   for (int i = 0; i < (1<<22); ++i) {
#ifdef EASY
 a[i] *= a[i];
#else
 int x = a[i];
 x *= x;
 a[i] = x;
#endif
   }
}
Thanks.  I've filed a bug and attached it the operand 
shortening/narrowing BZ (65964).  I strongly suspect there's other bugs 
in BZ that need to be attached to 65964.


jeff



[c++-concepts] code review

2015-05-01 Thread Jason Merrill
It looks like things are coming together pretty well.  What's your 
feeling about readiness to merge into the trunk?  Is the branch down to 
no regressions?


See you on Monday!


@@ -4146,21 +4146,21 @@ build_new_function_call (tree fn, vec 
**args, bool koenig_p,
   if (TREE_CODE (fn) == TEMPLATE_ID_EXPR)
 {
   /* If overload resolution selects a specialization of a
+ function concept for non-dependent template arguments,
+ the expression is true if the constraints are satisfied
+ and false otherwise.

  NOTE: This is an extension of Concepts Lite TS that
  allows constraints to be used in expressions. */
+  if (flag_concepts && !processing_template_decl)
 {
   tree tmpl = DECL_TI_TEMPLATE (cand->fn);
+  tree targs = DECL_TI_ARGS (cand->fn);
   tree decl = DECL_TEMPLATE_RESULT (tmpl);
+  if (DECL_DECLARED_CONCEPT_P (decl)
+  && !uses_template_parms (targs)) {
+return evaluate_function_concept (decl, targs);


If processing_template_decl is false, uses_template_parms should always 
be false as well.



+function_concept_check_p (tree t)



+  tree fn = CALL_EXPR_FN (t);
+  if (TREE_CODE (fn) == TEMPLATE_ID_EXPR
+  && TREE_CODE (TREE_OPERAND (fn, 0)) == OVERLOAD)
+{
+  tree f1 = OVL_FUNCTION (TREE_OPERAND (fn, 0));


I think you want get_first_fn here.


   if (TEMPLATE_PARM_CONSTRAINTS (current_template_parms))
-TYPE_CANONICAL (type) = type;
+SET_TYPE_STRUCTURAL_EQUALITY (type);


This seems like papering over an underlying issue.  What was the 
testcase that motivated this change?



@@ -11854,7 +11854,7 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
-   if (!spec)
+   if (!spec && DECL_LANG_SPECIFIC (t))
-   if (!local_p)
+   if (!local_p && DECL_LANG_SPECIFIC (r))


What motivated these changes?  From the testcase, it seems that you're 
getting here with the decl for "using TD = int", which shouldn't happen.



@@ -1159,7 +1159,6 @@ check_noexcept_r (tree *tp, int * /*walk_subtrees*/, void 
* /*data*/)
-  tree type = TREE_TYPE (TREE_TYPE (fn));
-  if (!TYPE_NOTHROW_P (type))
+  if (!TYPE_NOTHROW_P (TREE_TYPE (fn)))


The old code was incorrectly assuming that CALL_EXPR_FN is always a 
function pointer, but your new code seems to be incorrectly assuming 
that it's always a function or an expression taking the address of a 
function; I think this will break on a call to a function pointer variable.



@@ -3481,13 +3481,27 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
 case REQUIRES_EXPR:
+  if (!processing_template_decl)
+return evaluate_constraint_expression (t, NULL_TREE);
+  else
+*non_constant_p = true;
+return t;


We shouldn't get here with a dependent REQUIRES_EXPR (or any dependent 
expression), so we shouldn't ever hit the else clause.



@@ -18063,18 +18063,41 @@ cp_parser_declarator (cp_parser* parser,
+  /* Function declarations may be followed by a trailing
+ requires-clause. Declarators for function declartions
+ are function declarators wrapping an id-declarator.
+ If the inner declarator is anything else, it does not
+ declare a function. These may also be reference or
+ pointer declarators enclosing such a function declarator.
+ In the declaration :
+
+int *f(args)
+
+ the declarator is *f(args).
+
+ Abstract declarators cannot have a requires-clauses
+ because they do not declare functions. Here:

 void f() -> int& requires false

+ The trailing return type contains an abstract declarator,
+ and the requires-clause applies to the function
+ declaration and not the abstract declarator.  */
+  if (flag_concepts && dcl_kind != CP_PARSER_DECLARATOR_ABSTRACT)
 {
+  /* We could have things like *f(args) or &f(args).
+ Look inside references and pointers.  */
+  cp_declarator* p = declarator;
+  if (p->kind == cdk_reference || p->kind == cdk_pointer)
+p = p->declarator;
+
+  /* Pointers or references with no name, or functions
+ with no name cannot have constraints.  */
+  if (!p || !p->declarator)
+return declarator;
+
+  /* Look for f(args) but not (*f)(args).  */
+  if (p && p->kind == cdk_function && p->declarator->kind == cdk_id)


I think you can use function_declarator_p here.


+static inline bool
+pending_expansion_p (tree t)
+{
+  return (TREE_CODE (t) == PARM_DECL && CONSTRAINT_VAR_P (t)
+  && PACK_EXPANSION_P (TREE_TYPE (t)));
+}


What's the difference between this and function_parameter_pack_p?


+  /* A sentinel class that ensures that deferred access checks
+ are popped before a function returns.  */
+  struct deferring_access_check_sentinel
+  {
+deferring_access_check_sentinel ()
+{
+  push_deferring_access_checks (dk_deferre

Re: [PATCH 2/4] match.pd: Add x & ~(x & y) -> x & ~y pattern

2015-05-01 Thread Jeff Law

On 01/21/2015 03:49 AM, Rasmus Villemoes wrote:

gcc.dg/20150120-2.c: New test

Clearing a certain subset of bits, for example to round down x to a
multiple of a power of 2, is sometimes written x & ~(x & y), where y
may or may not be a constant. It is shorter to use x & ~y,
particularly when y is a constant. gcc already does this when it is
spelled x - (x & y) or x ^ (x & y).

Signed-off-by: Rasmus Villemoes 
---
  gcc/match.pd  |  6 ++
  gcc/testsuite/gcc.dg/20150120-2.c | 32 
  2 files changed, 38 insertions(+)
  create mode 100644 gcc/testsuite/gcc.dg/20150120-2.c
I combined this pattern with its bit-ior 'dual' into a single pattern. 
Then bootstrapped, regression tested, wrote the ChangeLog and installed 
the result onto the trunk.


I'm attaching the final patch which includes the changes in #1, #2 and 
#3 of this series for archival purposes.


jeff

commit 0a66cfe379a8217c69705535303626d12aca0c5f
Author: law 
Date:   Fri May 1 18:25:12 2015 +

* match.pd: New simplification patterns.
(x + (x & 1))  -> ((x + 1) & ~1)
(x & ~(x & y)) -> ((x & ~y))
(x | ~(x | y)) -> ((x | ~y))

* gcc.dg/20150120-1.c: New test.
* gcc.dg/20150120-2.c: New test.
* gcc.dg/20150120-3.c: New test.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222697 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 65816c7..e006b26 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2015-05-01  Rasmus Villemoes  
+
+   * match.pd: New simplification patterns.
+   (x + (x & 1))  -> ((x + 1) & ~1)
+   (x & ~(x & y)) -> ((x & ~y))
+   (x | ~(x | y)) -> ((x | ~y))
+
 2015-05-01  Kyrylo Tkachov  
 
* target.def (attribute_table): Mention that struct attribute_spec
diff --git a/gcc/match.pd b/gcc/match.pd
index fc374de..87ecaf1 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -255,6 +255,20 @@ along with GCC; see the file COPYING3.  If not see
   (bitop @0 @0)
   (non_lvalue @0)))
 
+/* x + (x & 1) -> (x + 1) & ~1 */
+(simplify
+ (plus:c @0 (bit_and@2 @0 integer_onep@1))
+ (if (TREE_CODE (@2) != SSA_NAME || has_single_use (@2))
+  (bit_and (plus @0 @1) (bit_not @1
+
+/* x & ~(x & y) -> x & ~y */
+/* x | ~(x | y) -> x | ~y  */
+(for bitop (bit_and bit_ior)
+  (simplify
+(bitop:c @0 (bit_not (bitop:c@2 @0 @1)))
+  (if (TREE_CODE (@2) != SSA_NAME || has_single_use (@2))
+   (bitop @0 (bit_not @1)
+
 (simplify
  (abs (negate @0))
  (abs @0))
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index bfdde3b..2aedc46 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2015-05-01  Rasmus Villemoes  
+
+   * gcc.dg/20150120-1.c: New test.
+   * gcc.dg/20150120-2.c: New test.
+   * gcc.dg/20150120-3.c: New test.
+
 2015-05-01  David Edelsohn  
 
* gcc.dg/debug/pr65771.c: Add "dg-add-options tls".
diff --git a/gcc/testsuite/gcc.dg/20150120-1.c 
b/gcc/testsuite/gcc.dg/20150120-1.c
new file mode 100644
index 000..18906c4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/20150120-1.c
@@ -0,0 +1,51 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-original" } */
+
+/* x + (x & 1) -> (x + 1) & ~1 */
+int
+fn1 (int x)
+{
+   return x + (x & 1);
+}
+int
+fn2 (int x)
+{
+   return (x & 1) + x;
+}
+int
+fn3 (int x)
+{
+   return x + (1 & x);
+}
+int
+fn4 (int x)
+{
+   return (1 & x) + x;
+}
+unsigned int
+fn5 (unsigned int x)
+{
+   return x + (x & 1);
+}
+unsigned int
+fn6 (unsigned int x)
+{
+   return (x & 1) + x;
+}
+unsigned int
+fn7 (unsigned int x)
+{
+   return x + (x % 2);
+}
+unsigned int
+fn8 (unsigned int x)
+{
+   return (x % 2) + x;
+}
+unsigned int
+fn9 (unsigned int x)
+{
+   return (1LL & x) + x;
+}
+
+/* { dg-final { scan-tree-dump-times "x \\+ 1" 9 "original" } } */
diff --git a/gcc/testsuite/gcc.dg/20150120-2.c 
b/gcc/testsuite/gcc.dg/20150120-2.c
new file mode 100644
index 000..976b654
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/20150120-2.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-original" } */
+
+/* x & ~(x & y) -> x & ~y */
+int fn1 (int x, int y)
+{
+   return x & ~(x & y);
+}
+int fn2 (int x, int y)
+{
+   return ~(x & y) & x;
+}
+int fn3 (int x, int y)
+{
+   return x & ~(y & x);
+}
+int fn4 (int x, int y)
+{
+   return ~(y & x) & x;
+}
+int fn5 (int z)
+{
+   return z & ~(z & 3);
+}
+int fn6 (int z)
+{
+   return ~(z & 3) & z;
+}
+
+
+/* { dg-final { scan-tree-dump-times "~y & x" 4 "original" } } */
+/* { dg-final { scan-tree-dump-times "z & -4" 2 "original" } } */
diff --git a/gcc/testsuite/gcc.dg/20150120-3.c 
b/gcc/testsuite/gcc.dg/20150120-3.c
new file mode 100644
index 000..322556f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/20150120-3.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-original" } */
+
+/* x | ~(x | y) 

Re: [PATCH 1/4] match.pd: Add x + (x & 1) -> (x + 1) & ~1 pattern

2015-05-01 Thread Jeff Law

On 01/21/2015 03:49 AM, Rasmus Villemoes wrote:

gcc.dg/20150120-1.c: New test

Rounding an integer to the next even integer is sometimes written x +=
x & 1. The equivalent x = (x+1)&~1 usually uses one less register, and
in practical cases only the new value of x will be used (making it
unlikely that the subexpression x&1 has any uses).


I bootstrapped and regression tested this on x86_64-linux-gnu, created 
the appropriate ChangeLogs and installed the patch on the trunk.


Jeff



Re: [Patch, fortran] PR65792 - allocation of scalar elemental function with structure constructor fails

2015-05-01 Thread Paul Richard Thomas
Dear All,

By the time I went to commit, something had changed and the patch
caused a regression. I presume that the version that I had of Andre's
patch was not the same as the one committed. I'll cast an eye over it
this weekend and see if I can understand what gives.

Cheers

paul

On 27 April 2015 at 22:42, Paul Richard Thomas
 wrote:
> Dear Steve,
>
> Thanks for the review. I THINK that I know what I meant in the comment
> :-) I will commit tomorrow night.
>
> Cheers
>
> Paul
>
> On 26 April 2015 at 20:53, Steve Kargl  
> wrote:
>> On Sun, Apr 26, 2015 at 08:35:06PM +0200, Paul Richard Thomas wrote:
>>>
>>> --- 7062,7091 
>>>   {
>>> if (expr->expr_type != EXPR_STRUCTURE)
>>>   {
>>> +   tree dealloc = NULL_TREE;
>>> gfc_init_se (&se, NULL);
>>> gfc_conv_expr (&se, expr);
>>> gfc_add_block_to_block (&block, &se.pre);
>>> +   /* Prevent repeat evaluations in gfc_copy_alloc_comp by fixing the
>>> +  expression in  a temporary variable and deallocate is allocatable
>>> +  components the copy to the result.  */
>>
>> Can you take a second shot at this comment?  The "and ..." portions
>> seems to be a little muddled.
>>
>> OK with after comment fix.
>>
>> --
>> Steve
>
>
>
> --
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
>
> Groucho Marx



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx


[PATCH] pr65771 testcase

2015-05-01 Thread David Edelsohn
The TLS testcase needs to add target-specific TLS options.

Committed as obvious.

* gcc.dg/debug/pr65771.c: Add "dg-add-options tls".

Index: debug/pr65771.c
===
--- debug/pr65771.c (revision 222680)
+++ debug/pr65771.c (working copy)
@@ -1,6 +1,7 @@
 /* PR debug/65771 */
 /* { dg-do link } */
 /* { dg-require-effective-target tls } */
+/* { dg-add-options tls } */


Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Jonathan Wakely

On 01/05/15 19:03 +0200, Daniel Krügler wrote:

b/libstdc++-v3/src/filesystem/path.cc:

- path::compare(const path& p) const noexcept:

Shouldn't the implementation of this noexcept function not try to
create copies of path objects? Couldn't _Cmpt just hold references to
_M_pathname?


All your other comments are definitely correct and I'll make the
relevant fixes soon, but I'm not sure what you mean here, could you
clarify?

I think it would be possible to implement a path like:

 class path
 {
   using value_type = ...;
   using string_type = basic_string;
   struct _Cmpt;
   using composite_path = pair>;
   using sub_path = basic_string_view;

   variant _M_data;
   enum _Type { ... } _M_type;
 };

 struct _Cmpt : path
 {
   // ...
 };

With the invariant that for all objects of type _Cmpt the variant
member holds a string_view that refers to the string_type object in
some other path.

This would reduce the memory footprint of a path object (but for the
new std::string ABI, only if there are path components longer than the
SSO small string buffer). Even with that design, paths would still
be sizeof(string_type) + sizeof(std::list<_Cmpt>) + sizeof(_Type).

Alternatively, it could be done without a variant, just adding a
string_view member to the path type, which would make it even larger,
but would simplify the implementation.



Re: [patch] Perform anonymous constant propagation during inlining

2015-05-01 Thread Eric Botcazou
> OK, how aggressive then?  We could as well do the substitution for all
> copies:
> 
>   /* For EXPAND_INITIALIZER try harder to get something simpler.
>Otherwise, substitute copies on the RHS, this can propagate
>constants at -O0 and thus simplify arithmetic operations.  */
>   if (g == NULL
> && !SSA_NAME_IS_DEFAULT_DEF (exp)
> && (optimize || DECL_IGNORED_P (SSA_NAME_VAR (exp)))
> && (modifier == EXPAND_INITIALIZER
> 
> || (modifier != EXPAND_WRITE
> 
> && gimple_assign_copy_p (SSA_NAME_DEF_STMT (exp
> && stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
>   g = SSA_NAME_DEF_STMT (exp);

This doesn't work (this generates wrong code because this creates overlapping 
live ranges for SSA_NAMEs with the same base variable).  Here's the latest 
working version, all the predicates and accessors used are inlined.

Tested on x86_64-suse-linux, OK for the mainline?


2015-05-01  Eric Botcazou  

* expr.c (expand_expr_real_1) : Try to substitute constants
on the RHS of expressions.
* gimple-expr.h (is_gimple_constant): Reorder.


-- 
Eric BotcazouIndex: expr.c
===
--- expr.c	(revision 222673)
+++ expr.c	(working copy)
@@ -9511,11 +9511,17 @@ expand_expr_real_1 (tree exp, rtx target
 	}
 
   g = get_gimple_for_ssa_name (exp);
-  /* For EXPAND_INITIALIZER try harder to get something simpler.  */
+  /* For EXPAND_INITIALIZER try harder to get something simpler.
+	 Otherwise, substitute constants on the RHS, this can make
+	 it possible to simplify arithmetic operations at -O0.  */
   if (g == NULL
-	  && modifier == EXPAND_INITIALIZER
 	  && !SSA_NAME_IS_DEFAULT_DEF (exp)
 	  && (optimize || DECL_IGNORED_P (SSA_NAME_VAR (exp)))
+	  && (modifier == EXPAND_INITIALIZER
+	  || (modifier != EXPAND_WRITE
+		  && gimple_assign_single_p (SSA_NAME_DEF_STMT (exp))
+		  && is_gimple_constant
+		 (gimple_assign_rhs1 (SSA_NAME_DEF_STMT (exp)
 	  && stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
 	g = SSA_NAME_DEF_STMT (exp);
   if (g)
Index: gimple-expr.h
===
--- gimple-expr.h	(revision 222673)
+++ gimple-expr.h	(working copy)
@@ -136,9 +136,9 @@ is_gimple_constant (const_tree t)
 case INTEGER_CST:
 case REAL_CST:
 case FIXED_CST:
-case STRING_CST:
 case COMPLEX_CST:
 case VECTOR_CST:
+case STRING_CST:
   return true;
 
 default:

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

2015-05-01 Thread Sriraman Tallam
On Fri, May 1, 2015 at 9:26 AM, Xinliang David Li  wrote:
> yes -- it is good to turn this on by default in LTO mode without
> requiring user to specify the option.

Yes, with LTO, we would exactly know what the "truly extern" functions
are and PLT stubs can be eliminated for all extern functions when
early binding is specified. With lazy binding, we can eliminate the
PLT stubs selectively for the hot extern functions.

Thanks
Sri

>
> David
>
> On Fri, May 1, 2015 at 9:23 AM, H.J. Lu  wrote:
>> On Fri, May 1, 2015 at 9:19 AM, Xinliang David Li  wrote:
>>> On Fri, May 1, 2015 at 8:01 AM, Andi Kleen  wrote:
 Sriraman Tallam  writes:
>
> This comes with  caveats.  This cannot be generally done for all
> functions marked extern as it is impossible for the compiler to say if
> a function is "truly extern" (defined in a shared library). If a
> function is not truly extern(ends up defined in the final executable),
> then calling it indirectly is a performance penalty as it could have
> been a direct call.  Further, the newly created GOT entries are fixed
> up at start-up and do not get lazily bound.

 This means you need to make it depend on -fno-semantic-interposition ?

> Given this, I propose adding a new option called
> -fno-plt= to the compiler.  This tells the compiler
> that we know that the function is truly extern and we want the
> indirect call only for these call-sites.  I have attached a patch that
> adds -fno-plt= to GCC.  Any number of "-fno-plt=" can be specified and
> all call-sites corresponding to these named functions will be done
> indirectly using the mechanism described above without the use of a
> PLT stub.

 The argument seems awkward. The command line may get very long.
 Better an attribute?
>>>
>>> They are complementary. Perhaps another option like linker's
>>> --dynamic-list=<> that can take a file specifying the list of symbols.
>>>

 Longer term it would be probably better to support it properly
 in the linker.

>>>
>>> Linker solution has its own downside -- it require reserving more
>>> space conservatively for many callsites which end up being direct
>>> calls.
>>>
>>
>> Can we do it automatically for LTO?
>>
>>
>> --
>> H.J.


Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Jonathan Wakely

On 01/05/15 19:03 +0200, Daniel Krügler wrote:

- There are three places where you refer to std::__addressof and one
where you refer to std::addressof. Is this difference intentional?


No, I'll make them all use __addressof.


- I found all together six non-uglified usages of parameter name "rhs"
in the synopsis of directory_iterator and
recursive_directory_iterator.


All names should be uglified as of this patch, which also fixes the
dg-require-filesystem-ts check so the tests actually run again(!)

Tested x86_64-linux and powerpc64le-linux, committed to trunk.


I'll address the other issues ASAP (I'm making a number of changes to
the #else branches in ops.cc and dir.cc).

Thanks very much for the thorough review.

commit 503fb9b4fe01b0c34d47590ed2384db179e04a57
Author: Jonathan Wakely 
Date:   Fri May 1 18:41:38 2015 +0100

	* include/experimental/fs_dir.h: Fix use of non-reserved names.
	* include/experimental/fs_ops.h: Likewise.
	* include/experimental/fs_path.h: Likewise.
	* testsuite/lib/libstdc++.exp (check_v3_target_filesystem_ts): Use
	C++11 when checking for support.

diff --git a/libstdc++-v3/include/experimental/fs_dir.h b/libstdc++-v3/include/experimental/fs_dir.h
index 0538fd2..d46d41b 100644
--- a/libstdc++-v3/include/experimental/fs_dir.h
+++ b/libstdc++-v3/include/experimental/fs_dir.h
@@ -180,14 +180,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   directory_options __options, error_code& __ec) noexcept
 : directory_iterator(__p, __options, &__ec) { }
 
-directory_iterator(const directory_iterator& rhs) = default;
+directory_iterator(const directory_iterator& __rhs) = default;
 
-directory_iterator(directory_iterator&& rhs) noexcept = default;
+directory_iterator(directory_iterator&& __rhs) noexcept = default;
 
 ~directory_iterator() = default;
 
-directory_iterator& operator=(const directory_iterator& rhs) = default;
-directory_iterator& operator=(directory_iterator&& rhs) noexcept = default;
+directory_iterator& operator=(const directory_iterator& __rhs) = default;
+directory_iterator& operator=(directory_iterator&& __rhs) noexcept = default;
 
 const directory_entry& operator*() const;
 const directory_entry* operator->() const { return &**this; }
@@ -269,9 +269,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 
 // modifiers
 recursive_directory_iterator&
-  operator=(const recursive_directory_iterator& rhs) noexcept;
+  operator=(const recursive_directory_iterator& __rhs) noexcept;
 recursive_directory_iterator&
-  operator=(recursive_directory_iterator&& rhs) noexcept;
+  operator=(recursive_directory_iterator&& __rhs) noexcept;
 
 recursive_directory_iterator& operator++();
 recursive_directory_iterator& increment(error_code& __ec) noexcept;
diff --git a/libstdc++-v3/include/experimental/fs_ops.h b/libstdc++-v3/include/experimental/fs_ops.h
index 0878fbb..6b7d470 100644
--- a/libstdc++-v3/include/experimental/fs_ops.h
+++ b/libstdc++-v3/include/experimental/fs_ops.h
@@ -53,8 +53,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   path absolute(const path& __p, const path& __base = current_path());
 
   path canonical(const path& __p, const path& __base = current_path());
-  path canonical(const path& p, error_code& ec);
-  path canonical(const path& p, const path& base, error_code& ec);
+  path canonical(const path& __p, error_code& __ec);
+  path canonical(const path& __p, const path& __base, error_code& __ec);
 
   inline void
   copy(const path& __from, const path& __to)
@@ -64,8 +64,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   copy(const path& __from, const path& __to, error_code& __ec) noexcept
   { copy(__from, __to, copy_options::none, __ec); }
 
-  void copy(const path& __from, const path& __to, copy_options options);
-  void copy(const path& __from, const path& __to, copy_options options,
+  void copy(const path& __from, const path& __to, copy_options __options);
+  void copy(const path& __from, const path& __to, copy_options __options,
 	error_code& __ec) noexcept;
 
   inline bool
@@ -239,12 +239,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   file_time_type  last_write_time(const path& __p);
   file_time_type  last_write_time(const path& __p, error_code& __ec) noexcept;
-  void last_write_time(const path& __p, file_time_type new_time);
-  void last_write_time(const path& __p, file_time_type new_time,
+  void last_write_time(const path& __p, file_time_type __new_time);
+  void last_write_time(const path& __p, file_time_type __new_time,
 		   error_code& __ec) noexcept;
 
-  void permissions(const path& __p, perms prms);
-  void permissions(const path& __p, perms prms, error_code& __ec) noexcept;
+  void permissions(const path& __p, perms __prms);
+  void permissions(const path& __p, perms __prms, error_code& __ec) noexcept;
 
   path read_symlink(const path& __p);
   path read_symlink(const path& __p, error_code& __ec);
diff --git a/libstdc++-v3/include/experimental/fs_path.h b/libstdc++-v3/i

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

2015-05-01 Thread Sriraman Tallam
On Fri, May 1, 2015 at 8:01 AM, Andi Kleen  wrote:
> Sriraman Tallam  writes:
>>
>> This comes with  caveats.  This cannot be generally done for all
>> functions marked extern as it is impossible for the compiler to say if
>> a function is "truly extern" (defined in a shared library). If a
>> function is not truly extern(ends up defined in the final executable),
>> then calling it indirectly is a performance penalty as it could have
>> been a direct call.  Further, the newly created GOT entries are fixed
>> up at start-up and do not get lazily bound.
>
> This means you need to make it depend on -fno-semantic-interposition ?

Please correct me if I am wrong but I do not see any dependency on
semantic-interposition.  The GOT entry created for the function
pointer (whose PLT has been eliminated) has a dynamic relocation
against it to fixup the address at run-time and the dynamic linker
fills it with the right address.  This is not a new mechanism.  The
same mechanism is used when we access function pointers with PIE for
instance.

Thanks
Sri

>
>> Given this, I propose adding a new option called
>> -fno-plt= to the compiler.  This tells the compiler
>> that we know that the function is truly extern and we want the
>> indirect call only for these call-sites.  I have attached a patch that
>> adds -fno-plt= to GCC.  Any number of "-fno-plt=" can be specified and
>> all call-sites corresponding to these named functions will be done
>> indirectly using the mechanism described above without the use of a
>> PLT stub.
>
> The argument seems awkward. The command line may get very long.
> Better an attribute?
>
> Longer term it would be probably better to support it properly
> in the linker.
>
> -Andi
>
> --
> a...@linux.intel.com -- Speaking for myself only


Re: [C++ patch] PR 65858

2015-05-01 Thread Jason Merrill

OK (= true).

Jason


Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Daniel Krügler
2015-04-30 19:32 GMT+02:00 Jonathan Wakely :
> This is the complete  implementation I intend
> to commit shortly. (It's also been pushed to the redi/filesystem-ts
> branch in the git mirror).

- There are three places where you refer to std::__addressof and one
where you refer to std::addressof. Is this difference intentional?

- I found all together six non-uglified usages of parameter name "rhs"
in the synopsis of directory_iterator and
recursive_directory_iterator.

b/libstdc++-v3/include/experimental/fs_ops.h:

- non-uglified parameters names "ec", "base", "p", "options",
"new_time", "prms":

path canonical(const path& p, error_code& ec);
path canonical(const path& p, const path& base, error_code& ec);

void copy(const path& __from, const path& __to, copy_options options);
void copy(const path& __from, const path& __to, copy_options options,
error_code& __ec) noexcept;

void last_write_time(const path& __p, file_time_type new_time);
void last_write_time(const path& __p, file_time_type new_time,
error_code& __ec) noexcept;

void permissions(const path& __p, perms prms);
void permissions(const path& __p, perms prms, error_code& __ec) noexcept;

b/libstdc++-v3/include/experimental/fs_path.h:

- non-uglified parameters names "n", "pos", "equals":

void _M_add_root_name(size_t n);
void _M_add_root_dir(size_t pos);
void _M_add_filename(size_t pos, size_t n);

class path::iterator:
bool equals(iterator) const;

b/libstdc++-v3/src/filesystem/dir.cc:

- Shouldn't the template bool is_set(Bitmask obj, Bitmask bits) be inline?

b/libstdc++-v3/src/filesystem/ops.cc:

- Shouldn't the template  bool is_set(Bitmask obj, Bitmask bits) be inline?

- fs::space(const path& p, error_code& ec) noexcept:

If _GLIBCXX_HAVE_SYS_STATVFS_H is not defined, there should be a #else
that performs

ec = std::make_error_code(std::errc::not_supported);

- fs::path fs::temp_directory_path(error_code& ec):

The code-branch

#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS

should start with:

ec = std::make_error_code(std::errc::not_supported);

b/libstdc++-v3/src/filesystem/path.cc:

- path::compare(const path& p) const noexcept:

Shouldn't the implementation of this noexcept function not try to
create copies of path objects? Couldn't _Cmpt just hold references to
_M_pathname?

- Daniel


Re: [PATCH] libstdc++: Fix list.cc xmethods test.

2015-05-01 Thread Jonathan Wakely

On 29/04/15 17:18 +0100, Jonathan Wakely wrote:

On 29 April 2015 at 17:04, Doug Evans wrote:

Tested the same patch on the gcc 5.0 branch.
Just double checking ... ok to apply there too?


Yes, OK for the branch too.


btw, the test is currently marked as unsupported by the test run.
I don't know what would be involved in marking it as failing instead,
but I noticed this happening a lot while I was working with this code.
I can imagine more failures going unnoticed because of this.


That's due to:

(*): Shared library is missing debugging information.^M
skipping: (*): Shared library is missing debugging information.^M
list.gdb:10: Error in sourced command file:^M
Cannot evaluate function -- may be inlined^M
skipping: list.gdb:10: Error in sourced command file:^M
skipping: Cannot evaluate function -- may be inlined^M
UNSUPPORTED: libstdc++-xmethods/list.cc

But I can't say anything more useful than that.


This might be all that's needed to make it work with the new list, but
I can't test it due to the UNSUPPORTED error above.


diff --git a/libstdc++-v3/python/libstdcxx/v6/xmethods.py b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
index 6db0e16..112d854 100644
--- a/libstdc++-v3/python/libstdcxx/v6/xmethods.py
+++ b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
@@ -382,7 +382,8 @@ class ListMethodsMatcher(gdb.xmethod.XMethodMatcher):
 
 def match(self, class_type, method_name):
 if not re.match('^std::list<.*>$', class_type.tag):
-return None
+if not re.match('^std::__cxx11::list<.*>$', class_type.tag):
+return None
 method = self._method_dict.get(method_name)
 if method is None or not method.enabled:
 return None
diff --git a/libstdc++-v3/testsuite/libstdc++-xmethods/list.cc b/libstdc++-v3/testsuite/libstdc++-xmethods/list.cc
index 050f75b..6c02de9 100644
--- a/libstdc++-v3/testsuite/libstdc++-xmethods/list.cc
+++ b/libstdc++-v3/testsuite/libstdc++-xmethods/list.cc
@@ -18,9 +18,6 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// List xmethods only recognize the non cxx11 std::list for now.
-#define _GLIBCXX_USE_CXX11_ABI 0
-
 #include 
 
 int


[patch] Use deleted functions to make std::locale::facet non-copyable

2015-05-01 Thread Jonathan Wakely

Replace the private & unimplemented idiom with deleted functions when
available. This gives slightly better error messages (as well as
stricter conformance to the precise wording of the standard).

Tested powerpc64le-linux, committed to trunk.
commit dd256f9035b4e32f1bb53eaf82919b0b69c6c999
Author: Jonathan Wakely 
Date:   Fri May 1 17:35:26 2015 +0100

	* include/bits/locale_classes.h (locale::facet): Delete copy
	operations in C++11 mode.

diff --git a/libstdc++-v3/include/bits/locale_classes.h b/libstdc++-v3/include/bits/locale_classes.h
index f3898eb..7e098e3 100644
--- a/libstdc++-v3/include/bits/locale_classes.h
+++ b/libstdc++-v3/include/bits/locale_classes.h
@@ -428,6 +428,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _GLIBCXX_CONST static const char*
 _S_get_c_name() throw();
 
+#if __cplusplus < 201103L
+  private:
+facet(const facet&);  // Not defined.
+
+facet&
+operator=(const facet&);  // Not defined.
+#else
+facet(const facet&) = delete;
+
+facet&
+operator=(const facet&) = delete;
+#endif
+
   private:
 void
 _M_add_reference() const throw()
@@ -448,11 +461,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	}
 }
 
-facet(const facet&);  // Not defined.
-
-facet&
-operator=(const facet&);  // Not defined.
-
 class __shim;
 
 const facet* _M_sso_shim(const id*) const;


Re: [patch] Perform anonymous constant propagation during inlining

2015-05-01 Thread Eric Botcazou
> Yeah, I think that's a way better place for the hack.

OK, how aggressive then?  We could as well do the substitution for all copies:

  /* For EXPAND_INITIALIZER try harder to get something simpler.
 Otherwise, substitute copies on the RHS, this can propagate
 constants at -O0 and thus simplify arithmetic operations.  */
  if (g == NULL
  && !SSA_NAME_IS_DEFAULT_DEF (exp)
  && (optimize || DECL_IGNORED_P (SSA_NAME_VAR (exp)))
  && (modifier == EXPAND_INITIALIZER
  || (modifier != EXPAND_WRITE
  && gimple_assign_copy_p (SSA_NAME_DEF_STMT (exp
  && stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
g = SSA_NAME_DEF_STMT (exp);

-- 
Eric Botcazou


Re: [PATCH 1/3] optabs.c: Make vector_compare_rtx cope with VOIDmode constants (e.g. const0_rtx)

2015-05-01 Thread Jeff Law

On 05/01/2015 09:12 AM, Alan Lawrence wrote:

Alan Lawrence wrote:

As per introduction, this allows vector_compare_rtx to work on DImode
vectors.

Bootstrapped + check-gcc on x86-unknown-linux-gnu.

gcc/ChangeLog:

* optabs.c (vector_compare_rtx): Handle RTL operands having VOIDmode.



Ping. (DImode vectors are explicitly allowed by stor-layout.c.)
Patch is fine.  If you have a testcase where this patch improves code, 
can you please add it to the testsuite.


Thanks,
Jeff



Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

2015-05-01 Thread Xinliang David Li
yes -- it is good to turn this on by default in LTO mode without
requiring user to specify the option.

David

On Fri, May 1, 2015 at 9:23 AM, H.J. Lu  wrote:
> On Fri, May 1, 2015 at 9:19 AM, Xinliang David Li  wrote:
>> On Fri, May 1, 2015 at 8:01 AM, Andi Kleen  wrote:
>>> Sriraman Tallam  writes:

 This comes with  caveats.  This cannot be generally done for all
 functions marked extern as it is impossible for the compiler to say if
 a function is "truly extern" (defined in a shared library). If a
 function is not truly extern(ends up defined in the final executable),
 then calling it indirectly is a performance penalty as it could have
 been a direct call.  Further, the newly created GOT entries are fixed
 up at start-up and do not get lazily bound.
>>>
>>> This means you need to make it depend on -fno-semantic-interposition ?
>>>
 Given this, I propose adding a new option called
 -fno-plt= to the compiler.  This tells the compiler
 that we know that the function is truly extern and we want the
 indirect call only for these call-sites.  I have attached a patch that
 adds -fno-plt= to GCC.  Any number of "-fno-plt=" can be specified and
 all call-sites corresponding to these named functions will be done
 indirectly using the mechanism described above without the use of a
 PLT stub.
>>>
>>> The argument seems awkward. The command line may get very long.
>>> Better an attribute?
>>
>> They are complementary. Perhaps another option like linker's
>> --dynamic-list=<> that can take a file specifying the list of symbols.
>>
>>>
>>> Longer term it would be probably better to support it properly
>>> in the linker.
>>>
>>
>> Linker solution has its own downside -- it require reserving more
>> space conservatively for many callsites which end up being direct
>> calls.
>>
>
> Can we do it automatically for LTO?
>
>
> --
> H.J.


Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

2015-05-01 Thread H.J. Lu
On Fri, May 1, 2015 at 9:19 AM, Xinliang David Li  wrote:
> On Fri, May 1, 2015 at 8:01 AM, Andi Kleen  wrote:
>> Sriraman Tallam  writes:
>>>
>>> This comes with  caveats.  This cannot be generally done for all
>>> functions marked extern as it is impossible for the compiler to say if
>>> a function is "truly extern" (defined in a shared library). If a
>>> function is not truly extern(ends up defined in the final executable),
>>> then calling it indirectly is a performance penalty as it could have
>>> been a direct call.  Further, the newly created GOT entries are fixed
>>> up at start-up and do not get lazily bound.
>>
>> This means you need to make it depend on -fno-semantic-interposition ?
>>
>>> Given this, I propose adding a new option called
>>> -fno-plt= to the compiler.  This tells the compiler
>>> that we know that the function is truly extern and we want the
>>> indirect call only for these call-sites.  I have attached a patch that
>>> adds -fno-plt= to GCC.  Any number of "-fno-plt=" can be specified and
>>> all call-sites corresponding to these named functions will be done
>>> indirectly using the mechanism described above without the use of a
>>> PLT stub.
>>
>> The argument seems awkward. The command line may get very long.
>> Better an attribute?
>
> They are complementary. Perhaps another option like linker's
> --dynamic-list=<> that can take a file specifying the list of symbols.
>
>>
>> Longer term it would be probably better to support it properly
>> in the linker.
>>
>
> Linker solution has its own downside -- it require reserving more
> space conservatively for many callsites which end up being direct
> calls.
>

Can we do it automatically for LTO?


-- 
H.J.


Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

2015-05-01 Thread Xinliang David Li
On Fri, May 1, 2015 at 8:01 AM, Andi Kleen  wrote:
> Sriraman Tallam  writes:
>>
>> This comes with  caveats.  This cannot be generally done for all
>> functions marked extern as it is impossible for the compiler to say if
>> a function is "truly extern" (defined in a shared library). If a
>> function is not truly extern(ends up defined in the final executable),
>> then calling it indirectly is a performance penalty as it could have
>> been a direct call.  Further, the newly created GOT entries are fixed
>> up at start-up and do not get lazily bound.
>
> This means you need to make it depend on -fno-semantic-interposition ?
>
>> Given this, I propose adding a new option called
>> -fno-plt= to the compiler.  This tells the compiler
>> that we know that the function is truly extern and we want the
>> indirect call only for these call-sites.  I have attached a patch that
>> adds -fno-plt= to GCC.  Any number of "-fno-plt=" can be specified and
>> all call-sites corresponding to these named functions will be done
>> indirectly using the mechanism described above without the use of a
>> PLT stub.
>
> The argument seems awkward. The command line may get very long.
> Better an attribute?

They are complementary. Perhaps another option like linker's
--dynamic-list=<> that can take a file specifying the list of symbols.

>
> Longer term it would be probably better to support it properly
> in the linker.
>

Linker solution has its own downside -- it require reserving more
space conservatively for many callsites which end up being direct
calls.

David



> -Andi
>
> --
> a...@linux.intel.com -- Speaking for myself only


Re: [PATCH][doc] Update definition location of attribute_spec in documentation

2015-05-01 Thread Jeff Law

On 05/01/2015 08:51 AM, Kyrill Tkachov wrote:

Hi all,

Like the subject says, struct attribute_spec is now defined in
tree-core.h rather than tree.h.
The patch updates the reference that I spotted.

Ok for trunk?

Thanks,
Kyrill

2015-05-01  Kyrylo Tkachov  

 * target.def (attribute_table): Mention that struct attribute_spec
 is defined in tree-core.h rather than tree.h
 * doc/tm.texi: Regenerate.

OK.
jeff



[PATCH][tree-ssa-math-opts] Expand pow (x, CONST) using square roots when possible

2015-05-01 Thread Kyrill Tkachov

Hi all,

GCC has some logic to expand calls to pow (x, 0.75), pow (0.25) and pow (x, 
(int)k + 0.5)
using square roots. So, for the above examples it would generate sqrt (x) * 
sqrt (sqrt (x)),
sqrt (sqrt (x)) and powi (x, k) * sqrt (x) (assuming k > 0. For k < 0 it will 
calculate the
reciprocal of that).

However, the implementation of these optimisations is done on a bit of an 
ad-hoc basis with
the 0.25, 0.5, 0.75 cases hardcoded.
Judging by 
https://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=meissner2.pdf
these are the most commonly used exponents (at least in SPEC ;))

This patch generalises this optimisation into a (hopefully) more robust 
algorithm.
In particular, it expands calls to pow (x, CST) by expanding the integer part 
of CST
using a powi, like it does already, and then expanding the fractional part as a 
product
of repeated applications of a square root if the fractional part can be 
expressed
as a multiple of a power of 0.5.

I try to explain the algorithm in more detail in the comments in the patch but, 
for example:

pow (x, 5.625) is not currently handled, but with this patch will be expanded
to powi (x, 5) * sqrt (x) * sqrt (sqrt (sqrt (x))) because 5.625 == 5.0 + 0.5 + 
0.5**3

Negative exponents are handled in either of two ways, depending on the exponent 
value:
* Using a simple reciprocal.
  For example:
  pow (x, -5.625) == 1.0 / pow (x, 5.625)
--> 1.0 / (powi (x, 5) * sqrt (x) * sqrt (sqrt (sqrt (x

* For pow (x, EXP) with negative exponent EXP with integer part INT and 
fractional part FRAC:
pow (1.0 - FRAC) / powi (ceil (abs (EXP))).
  For example:
  pow (x, -5.875) == pow (x, 0.125) / powi (X, 6)
--> sqrt (sqrt (sqrt (x))) / (powi (x, 6))


Since hardware square root instructions tend to be expensive, we may want to 
reduce the number
of square roots we are willing to calculate. Since we reuse intermediate square 
root results,
this boils down to restricting the depth of the square root chains. In all the 
examples above
that depth is 3. I've made this maximum depth parametrisable in params.def. By 
adjusting that
parameter we can adjust the resolution of this optimisation. So, if it's set to 
'4' then we
will synthesize every exponent that is a multiple of 0.5**4 == 0.0625, 
including negative
multiples. Currently, GCC will not try to expand negative multiples of anything 
else than 0.5

I have tried to keep the existing functionality intact and activate this only 
for
-funsafe-math-optimizations and only when the target has a sqrt instruction.
 An exception to that is pow (x, 0.5) which we prefer to transform to sqrt even
when a hardware sqrt is not available, presumably because the library function 
for
sqrt is usually faster than pow (?).


Having seen the glibc implementation of a fully IEEE-754-compliant pow 
function, I think we
would prefer synthesising the pow call whenever we can for -ffast-math.

I have seen this optimisation trigger a few times in SPEC2k6, in particular in 
447.dealII
and 481.wrf where it replaced calls to powf (x, -0.25), pow (x, 0.125) and pow 
(x, 0.875)
with square roots, multiplies and, in the case of -0.25, divides.
On 481.wrf I saw it remove a total of 22 out of 322 calls to pow

On 481.wrf on aarch64 I saw about a 1% improvement.
The cycle count on x86_64 was also smaller, but not by a significant amount 
(the same calls to
pow were eliminated).

In general, I think this can shine if multiple expandable calls to pow appear 
together.
So, for example for code:
double
baz (double a)
{
  return __builtin_pow (a, -1.25) + __builtin_pow (a, 5.75) - __builtin_pow (a, 
3.375);
}

we can generate:
baz:
fsqrt   d3, d0
fmuld4, d0, d0
fmovd5, 1.0e+0
fmuld6, d0, d4
fsqrt   d2, d3
fmuld1, d0, d2
fsqrt   d0, d2
fmuld3, d3, d2
fdivd1, d5, d1
fmuld3, d3, d6
fmuld2, d2, d0
fmadd   d0, d4, d3, d1
fmsub   d0, d6, d2, d0
ret

reusing the sqrt results and doing more optimisations rather than the current:
baz:
stp x29, x30, [sp, -48]!
fmovd1, -1.25e+0
add x29, sp, 0
stp d8, d9, [sp, 16]
fmovd9, d0
str d10, [sp, 32]
bl  pow
fmovd8, d0
fmovd0, d9
fmovd1, 5.75e+0
bl  pow
fmovd10, d0
fmovd0, d9
fmovd1, 3.375e+0
bl  pow
faddd8, d8, d10
ldr d10, [sp, 32]
fsubd0, d8, d0
ldp d8, d9, [sp, 16]
ldp x29, x30, [sp], 48
ret


Of course gcc could already do that if the exponents were to fall in the set 
{0.25, 0.75, k+0.5}
but with this patch that set can be greatly expanded.

I suppose if we're really lucky we might even open up new vectorisation 
opportunities.
For example:
void
vecfoo (float *a, float *b)
{
  for (int i = 0; i < N; i++)
a[i] = __builtin_p

Re: [PATCH][AARCH64]Use mov for add with large immediate.

2015-05-01 Thread Marcus Shawcroft
On 1 May 2015 at 16:30, Renlin Li  wrote:

> Thank you, Marcus. I have updated the patch accordingly, please check..
>
> Regards,
> Renlin Li

OK, thanks /Marcus


Re: [PATCH][doc] Update definition location of attribute_spec in documentation

2015-05-01 Thread Kyrill Tkachov


On 01/05/15 16:22, Sandra Loosemore wrote:

On 05/01/2015 08:51 AM, Kyrill Tkachov wrote:

Hi all,

Like the subject says, struct attribute_spec is now defined in
tree-core.h rather than tree.h.
The patch updates the reference that I spotted.

Ok for trunk?

Thanks,
Kyrill

2015-05-01  Kyrylo Tkachov  

  * target.def (attribute_table): Mention that struct attribute_spec
  is defined in tree-core.h rather than tree.h
  * doc/tm.texi: Regenerate.

This looks fine to me.  In fact, I think this sort of change qualifies
as obvious and can just be committed without asking for review.


Thanks, I agree that the content is obvious.
It's just that I always get confused whenever I modify target.def
because on building the documentation it errors out and demands that
I manually copy the tm.texi from the build back to the sources so I
just wanted to make sure that the patch can just be applied as is.

Kyrill



-Sandra





Re: [PATCH] PR ld/18355: --enable-shared doesn't work

2015-05-01 Thread H.J. Lu
On Wed, Apr 29, 2015 at 9:12 AM, H.J. Lu  wrote:
> When bfd is configured as a shared library, we need to configure zlib
> with --enable-host-shared since zlib is used by bfd.  Any comments,
> feedbacks, objections?
>
>
> H.J.
> --
> PR ld/18355
> * Makefile.def: Add extra_configure_flags to host zlib.
> * configure.ac (extra_host_zlib_configure_flags): New.  Set
> to --enable-host-shared When bfd is to be built as shared
> library.  AC_SUBST.
> * Makefile.in: Regenerated.
> * configure: Likewise.

I am checking it in.


-- 
H.J.


Re: [PATCH][AARCH64]Use mov for add with large immediate.

2015-05-01 Thread Renlin Li

Hi Marcus,

On 01/05/15 11:19, Marcus Shawcroft wrote:

On 21 April 2015 at 17:10, Renlin Li  wrote:

Hi all,

This is a simple patch to generate a move instruction to temporarily hold
the large immediate for a add instruction.

GCC regression test has been run using aarch64-none-elf toolchain. NO new
issues.

Okay for trunk?

Regards,
Renlin Li

gcc/ChangeLog:

2015-04-21  Renlin Li  

 * config/aarch64/aarch64.md (add3): Use mov when allowed.

A couple style nits:

HOST_WIDE_INT imm = INTVAL (operands[2]);
-
-  if (imm < 0)

Don't remove the blank line between declarations and the first statement.

+  if (aarch64_move_imm (imm, mode)
+  && can_create_pseudo_p ())
+  {

The indentation of { should conform to the gnu style guide.

It also  looks to me that  an unbroken line will fit within the 80
column limit, hence the break before && is unnecessary.


Thank you, Marcus. I have updated the patch accordingly, please check..

Regards,
Renlin Li



Cheers
/Marcus

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 429c5ba..d0ceafa 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1414,18 +1414,28 @@
   "
   if (! aarch64_plus_operand (operands[2], VOIDmode))
 {
-  rtx subtarget = ((optimize && can_create_pseudo_p ())
-		   ? gen_reg_rtx (mode) : operands[0]);
   HOST_WIDE_INT imm = INTVAL (operands[2]);
 
-  if (imm < 0)
-	imm = -(-imm & ~0xfff);
+  if (aarch64_move_imm (imm, mode) && can_create_pseudo_p ())
+{
+	  rtx tmp = gen_reg_rtx (mode);
+	  emit_move_insn (tmp, operands[2]);
+	  operands[2] = tmp;
+}
   else
-imm &= ~0xfff;
-
-  emit_insn (gen_add3 (subtarget, operands[1], GEN_INT (imm)));
-  operands[1] = subtarget;
-  operands[2] = GEN_INT (INTVAL (operands[2]) - imm);
+{
+	  rtx subtarget = ((optimize && can_create_pseudo_p ())
+			   ? gen_reg_rtx (mode) : operands[0]);
+
+	  if (imm < 0)
+	imm = -(-imm & ~0xfff);
+	  else
+	imm &= ~0xfff;
+
+	  emit_insn (gen_add3 (subtarget, operands[1], GEN_INT (imm)));
+	  operands[1] = subtarget;
+	  operands[2] = GEN_INT (INTVAL (operands[2]) - imm);
+}
 }
   "
 )


Re: [PATCH][doc] Update definition location of attribute_spec in documentation

2015-05-01 Thread Sandra Loosemore

On 05/01/2015 08:51 AM, Kyrill Tkachov wrote:

Hi all,

Like the subject says, struct attribute_spec is now defined in
tree-core.h rather than tree.h.
The patch updates the reference that I spotted.

Ok for trunk?

Thanks,
Kyrill

2015-05-01  Kyrylo Tkachov  

 * target.def (attribute_table): Mention that struct attribute_spec
 is defined in tree-core.h rather than tree.h
 * doc/tm.texi: Regenerate.


This looks fine to me.  In fact, I think this sort of change qualifies 
as obvious and can just be committed without asking for review.


-Sandra



[patch] Rename template parameter of std::__alloc_rebind

2015-05-01 Thread Jonathan Wakely

The name of this alias template is a copy&paste error, it should be
_Alloc. Tested powerpc64le-linux, committed to trunk.
commit a772309ec9fc300e57edd750fa32b8320d68004a
Author: Jonathan Wakely 
Date:   Fri May 1 16:12:16 2015 +0100

	* include/bits/alloc_traits.h (__alloc_rebind): Change parameter name.

diff --git a/libstdc++-v3/include/bits/alloc_traits.h b/libstdc++-v3/include/bits/alloc_traits.h
index d6c42ec..12c6c12 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -72,8 +72,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef _Alloc<_Tp, _Args...> __type;
 };
 
-  template
-using __alloc_rebind = typename __alloctr_rebind<_Ptr, _Tp>::__type;
+  template
+using __alloc_rebind = typename __alloctr_rebind<_Alloc, _Tp>::__type;
 
   /**
* @brief  Uniform interface to all allocator types.


Re: [RFC]: Remove Mem/address type assumption in combiner

2015-05-01 Thread Segher Boessenkool
On Wed, Apr 29, 2015 at 12:03:35PM -0500, Segher Boessenkool wrote:
> On Wed, Apr 29, 2015 at 09:25:21AM +, Kumar, Venkataramanan wrote:
> > diff --git a/gcc/combine.c b/gcc/combine.c
> > index 5c763b4..945abdb 100644
> > --- a/gcc/combine.c
> > +++ b/gcc/combine.c
> > @@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code)
> >   but once inside, go back to our default of SET.  */
> > 
> >next_code = (code == MEM ? MEM
> > -  : ((code == PLUS || code == MINUS)
> > - && SCALAR_INT_MODE_P (mode)) ? MEM
> >: ((code == COMPARE || COMPARISON_P (x))
> >   && XEXP (x, 1) == const0_rtx) ? COMPARE
> >: in_code == COMPARE ? SET : in_code);
> > 
> > 
> > On X86_64, it passes bootstrap and regression tests.
> > But on Aarch64 the test in PR passed, but I got a few test case failures.
> 
> > There are few patterns based on multiplication operations in Aarch64 
> > backend which are used to match with the pattern combiner generated.
> > Now those patterns have to be fixed to use SHIFTS.  Also need to see any 
> > impact on other targets.
> 
> Right.  It would be good if you could find out for what targets it matters.
> The thing is, if a target expects only the patterns as combine used to make
> them, it will regress (as you've seen on aarch64); but it will regress
> _silently_.  Which isn't so nice.
> 
> > But  before that  I wanted to check if the assumption in combiner,  can 
> > simply be removed ?
> 
> Seeing for what targets / patterns it makes a difference would tell us the
> answer to that, too :-)
> 
> I'll run some tests with and without your patch.

So I ran the tests.  These are text sizes for vmlinux built for most
architectures (before resp. after the patch).  Results are good, but
they show many targets need some work...


BIGGER
 5410496   5432744   alpha
 3848987   3849143   arm
 2190276   2190292   blackfin
 2188431   2191503   c6x (but data shrank by more than text grew)
 2212322   2212706   cris
10896454  10896965   i386
 7471891   7488771   parisc
 6168799   6195391   parisc64
 1545840   1545872   shnommu
 1946649   1954149   xtensa

I looked at some of those.  Alpha regresses with s4add things, arm with
add ,lsl things, parisc with shladd things.  I tried to fix the parisc
one (it seemed simplest), and the 32-bit kernel got most (but not all)
of the size difference back; and the 64-bit wouldn't build (an assert
in the kernel failed, and it uses a floating point reg where an integer
one is needed -- I gave up).


SMALLER
 8688171   8688003   powerpc
20252605  20251797   powerpc64
11425334  11422558   s390
12300135  12299767   x86_64

The PowerPC differences are mostly what first was rlwinm;addi;rlwinm;lwz
and now is rlwinm;lwz; i.e. the add is moved after the two rotates, the
rotates are merged, and the add is made part of the offset in the load.


NO DIFF
 3321492   3321492   frv
 3252747   3252747   m32r
 4708232   4708232   microblaze
 3949145   3949145   mips
 5693019   5693019   mips64
 2373441   2373441   mn10300
 6489846   6489846   sh64
 3733749   3733749   sparc
 6075122   6075122   sparc64

Also quite a few without any diff.  Good :-)  Some of those might have
unnecessary add/mult patterns now, but they also have the add/shift.


I didn't see any big differences, and all are of the expected kind.
Some targets need some love (but what else is new).

The patch is approved for trunk.

Thanks,


Segher


Re: [PATCH, AArch64] Add Cortex-A53 erratum 843419 configure-time option

2015-05-01 Thread Marcus Shawcroft
On 1 May 2015 at 14:56, Yvan Roux  wrote:

> 2015-05-01  Yvan Roux  
>
>  * configure.ac: Add --enable-fix-cortex-a53-843419 option.
>  * configure: Regenerate.
>  * config/aarch64/aarch64-elf-raw.h (CA53_ERR_843419_SPEC): Define.
>  (LINK_SPEC): Include CA53_ERR_843419_SPEC.
>  * config/aarch64/aarch64-linux.h (CA53_ERR_843419_SPEC): Define.
>  (LINK_SPEC): Include CA53_ERR_843419_SPEC.
>  * doc/install.texi (aarch64*-*-*): Document
>  new --enable-fix-cortex-a53-843419 option
>  * config/aarch64/aarch64.opt (mfix-cortex-a53-843419): New option.
>  * doc/invoke.texi (AArch64 Options): Document -mfix-cortex-a53-843419
>  and -mno-fix-cortex-a53-8434199 options.
>

+@option{--enable-fix-cortex-a53-843419} option.  This erratum
workaround is
+made at link time and enabling it by default in GCC will only pass
the

How about something like "The workaround is applied at link time.
Enabling the workaround will cause GCC to pass the relevant option to
the linker." ?

+corresponding flag to the linker.  It can be explicitly disabled
during
+compilation by passing the @option{-mno-fix-cortex-a53-835769} option.

Copy paste error here with the previous errata number.

Cheers
/Marcus


Re: [PATCH][docs] Re: Update __atomic builtins documentation.

2015-05-01 Thread Jeff Law

On 04/30/2015 04:44 AM, Matthew Wahab wrote:

[added tags to subject]

Ping.

On 20/04/15 14:29, Matthew Wahab wrote:

Hello,

The documentation for the __atomic builtins isn't clear about their
expectations
and behaviour. In particular, assumptions about the C11/C++11
restrictions on
programs should be stated and the different behaviour of memory models
in fences
and in operations should be noted. The behaviour of compare-exchange
when the
compare fails is also confusing and the description of the
implementation of the
__atomics is mixed in with the description of their functionality.

This patch tries to deal with some of these problems.

Tested by looking at the html.

Ok for trunk?
Matthew

2015-04-20  Matthew Wahab  

* doc/extend.texi (__atomic Builtins): Move implementation details
to the end of the description, rewrite opening paragraphs, state
difference with __sync builtins, state C11/C++11 assumptions,
weaken itemized descriptions, add explanation of memory model
behaviour, expand description of compare-exchange, simplify text.

OK.



jeff


Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Rainer Orth
Jonathan Wakely  writes:

> Sorry about that, I'll add a check for fchmodat, in the meantime this
> will fix bootstrap. Committed as obvious.
>
>
> commit f4768ebcfd68e2fa6e4763d0b681e8fe710c64c4
> Author: Jonathan Wakely 
> Date:   Fri May 1 16:09:28 2015 +0100
>
>   * acinclude.m4 (GLIBCXX_ENABLE_FILESYSTEM_TS): Disable for solaris.
>   * configure: Regenerate.

Which is overkill given that Solaris > 10 does support fchmodat, but it's
just a workaround anyway.

Thanks.
Rainer

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


Re: [PATCH 1/3] optabs.c: Make vector_compare_rtx cope with VOIDmode constants (e.g. const0_rtx)

2015-05-01 Thread Alan Lawrence

Alan Lawrence wrote:

As per introduction, this allows vector_compare_rtx to work on DImode vectors.

Bootstrapped + check-gcc on x86-unknown-linux-gnu.

gcc/ChangeLog:

* optabs.c (vector_compare_rtx): Handle RTL operands having VOIDmode.



Ping. (DImode vectors are explicitly allowed by stor-layout.c.)
diff --git a/gcc/optabs.c b/gcc/optabs.c
index f8d584eeeb11a2c19d8c8d887a0ff18aed5f56b4..135c88938f8bc03eed4dc7f1b5adcb0bb0606b1e 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -6530,18 +6530,28 @@ vector_compare_rtx (enum tree_code tcode, tree t_op0, tree t_op1,
 {
   struct expand_operand ops[2];
   rtx rtx_op0, rtx_op1;
+  machine_mode m0, m1;
   enum rtx_code rcode = get_rtx_code (tcode, unsignedp);
 
   gcc_assert (TREE_CODE_CLASS (tcode) == tcc_comparison);
 
-  /* Expand operands.  */
+  /* Expand operands.  For vector types with scalar modes, e.g. where int64x1_t
+ has mode DImode, this can produce a constant RTX of mode VOIDmode; in such
+ cases, use the original mode.  */
   rtx_op0 = expand_expr (t_op0, NULL_RTX, TYPE_MODE (TREE_TYPE (t_op0)),
 			 EXPAND_STACK_PARM);
+  m0 = GET_MODE (rtx_op0);
+  if (m0 == VOIDmode)
+m0 = TYPE_MODE (TREE_TYPE (t_op0));
+
   rtx_op1 = expand_expr (t_op1, NULL_RTX, TYPE_MODE (TREE_TYPE (t_op1)),
 			 EXPAND_STACK_PARM);
+  m1 = GET_MODE (rtx_op1);
+  if (m1 == VOIDmode)
+m1 = TYPE_MODE (TREE_TYPE (t_op1));
 
-  create_input_operand (&ops[0], rtx_op0, GET_MODE (rtx_op0));
-  create_input_operand (&ops[1], rtx_op1, GET_MODE (rtx_op1));
+  create_input_operand (&ops[0], rtx_op0, m0);
+  create_input_operand (&ops[1], rtx_op1, m1);
   if (!maybe_legitimize_operands (icode, 4, 2, ops))
 gcc_unreachable ();
   return gen_rtx_fmt_ee (rcode, VOIDmode, ops[0].value, ops[1].value);


Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Jonathan Wakely

On 01/05/15 14:45 +0200, Rainer Orth wrote:

Jonathan Wakely  writes:


I've tested this on GNU/Linux and DragonFly BSD, but as it's probably
not going to build everywhere I've added the configure option
--enable-libstdcxx-filesystem-ts which defaults to enabled on GNU, BSD
and Solaris targets, and disabled elsewhere for now. If it fails to
build on any of those targets we can change the default while we fix
the problem.


Unfortunately, the patch breaks Solaris 10 bootstrap, which lacks
fchmodat:

/vol/gcc/src/hg/trunk/local/libstdc++-v3/src/filesystem/ops.cc: In function 'void 
std::experimental::filesystem::v1::permissions(const 
std::experimental::filesystem::v1::__cxx11::path&, 
std::experimental::filesystem::v1::perms, std::error_code&)':
/vol/gcc/src/hg/trunk/local/libstdc++-v3/src/filesystem/ops.cc:890:17: error: 
'::fchmodat' has not been declared
  if (int err = ::fchmodat(AT_FDCWD, p.c_str(), static_cast(prms), 0))
^
make[6]: *** [ops.lo] Error 1


Sorry about that, I'll add a check for fchmodat, in the meantime this
will fix bootstrap. Committed as obvious.

commit f4768ebcfd68e2fa6e4763d0b681e8fe710c64c4
Author: Jonathan Wakely 
Date:   Fri May 1 16:09:28 2015 +0100

	* acinclude.m4 (GLIBCXX_ENABLE_FILESYSTEM_TS): Disable for solaris.
	* configure: Regenerate.

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 537ca6f..9d8d96d 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -3923,7 +3923,7 @@ AC_DEFUN([GLIBCXX_ENABLE_FILESYSTEM_TS], [
 enable_libstdcxx_filesystem_ts=yes
 ;;
   solaris*)
-enable_libstdcxx_filesystem_ts=yes
+enable_libstdcxx_filesystem_ts=no
 ;;
   *)
 enable_libstdcxx_filesystem_ts=no
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 0a059c6..5ecfdeb 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -79163,7 +79163,7 @@ $as_echo_n "checking whether to build Filesystem TS support... " >&6; }
 enable_libstdcxx_filesystem_ts=yes
 ;;
   solaris*)
-enable_libstdcxx_filesystem_ts=yes
+enable_libstdcxx_filesystem_ts=no
 ;;
   *)
 enable_libstdcxx_filesystem_ts=no


Re: [PATCH]Add sync_int_long target selector to gcc.dg/pr65345-2.c

2015-05-01 Thread Jeff Law

On 05/01/2015 08:44 AM, Renlin Li wrote:

Hi all,

The new test case requires the target to support atomic operations on
"int" type. By adding the correct target selector, it fixes the
regression on arm-none-elf target.

Okay to commit?


gcc/testsuite/ChangeLog:

2015-05-01  Renlin Li  

 * gcc.dg/pr65345-2.c: Add sync_int_long target selector.

OK.

Jeff



Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

2015-05-01 Thread Andi Kleen
Sriraman Tallam  writes:
>
> This comes with  caveats.  This cannot be generally done for all
> functions marked extern as it is impossible for the compiler to say if
> a function is "truly extern" (defined in a shared library). If a
> function is not truly extern(ends up defined in the final executable),
> then calling it indirectly is a performance penalty as it could have
> been a direct call.  Further, the newly created GOT entries are fixed
> up at start-up and do not get lazily bound.

This means you need to make it depend on -fno-semantic-interposition ?

> Given this, I propose adding a new option called
> -fno-plt= to the compiler.  This tells the compiler
> that we know that the function is truly extern and we want the
> indirect call only for these call-sites.  I have attached a patch that
> adds -fno-plt= to GCC.  Any number of "-fno-plt=" can be specified and
> all call-sites corresponding to these named functions will be done
> indirectly using the mechanism described above without the use of a
> PLT stub.

The argument seems awkward. The command line may get very long.
Better an attribute?

Longer term it would be probably better to support it properly
in the linker.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only


[PATCH][doc] Update definition location of attribute_spec in documentation

2015-05-01 Thread Kyrill Tkachov

Hi all,

Like the subject says, struct attribute_spec is now defined in tree-core.h 
rather than tree.h.
The patch updates the reference that I spotted.

Ok for trunk?

Thanks,
Kyrill

2015-05-01  Kyrylo Tkachov  

* target.def (attribute_table): Mention that struct attribute_spec
is defined in tree-core.h rather than tree.h
* doc/tm.texi: Regenerate.
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index f85ccec..e07f59c 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -9828,7 +9828,7 @@ be documented in @file{extend.texi}.
 
 @deftypevr {Target Hook} {const struct attribute_spec *} TARGET_ATTRIBUTE_TABLE
 If defined, this target hook points to an array of @samp{struct
-attribute_spec} (defined in @file{tree.h}) specifying the machine
+attribute_spec} (defined in @file{tree-core.h}) specifying the machine
 specific attributes for this target and some of the restrictions on the
 entities to which these attributes are applied and the arguments they
 take.
diff --git a/gcc/target.def b/gcc/target.def
index 842ebf7..3ea4c8a 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -1980,7 +1980,7 @@ merging.",
 DEFHOOKPOD
 (attribute_table,
  "If defined, this target hook points to an array of @samp{struct\n\
-attribute_spec} (defined in @file{tree.h}) specifying the machine\n\
+attribute_spec} (defined in @file{tree-core.h}) specifying the machine\n\
 specific attributes for this target and some of the restrictions on the\n\
 entities to which these attributes are applied and the arguments they\n\
 take.",


[PATCH]Add sync_int_long target selector to gcc.dg/pr65345-2.c

2015-05-01 Thread Renlin Li

Hi all,

The new test case requires the target to support atomic operations on 
"int" type. By adding the correct target selector, it fixes the 
regression on arm-none-elf target.


Okay to commit?


gcc/testsuite/ChangeLog:

2015-05-01  Renlin Li  

* gcc.dg/pr65345-2.c: Add sync_int_long target selector.
diff --git a/gcc/testsuite/gcc.dg/pr65345-2.c b/gcc/testsuite/gcc.dg/pr65345-2.c
index 438100d..c9adffb 100644
--- a/gcc/testsuite/gcc.dg/pr65345-2.c
+++ b/gcc/testsuite/gcc.dg/pr65345-2.c
@@ -1,5 +1,6 @@
 /* PR c/65345 */
 /* { dg-do run } */
+/* { dg-require-effective-target sync_int_long } */
 /* { dg-options "" } */
 
 #define CHECK(X) if (!(X)) __builtin_abort ()


[PATCH][ARM] Add debug dumping of cost table fields

2015-05-01 Thread Kyrill Tkachov

Hi all,

This patch adds a macro to wrap cost field accesses into a helpful debug dump,
saying which field is being accessed at what line and with what values.
This helped me track down cases where the costs were doing the wrong thing
by allowing me to see which path in arm_new_rtx_costs was taken.
For example, the combine log might now contain:

Trying 2 -> 6:
Successfully matched this instruction:
(set (reg:SI 115 [ D.5348 ])
(neg:SI (reg:SI 0 r0 [ a ])))
using extra_cost->alu.arith with cost 0 from line 10506

which can be useful in debugging the rtx costs.

Bootstrapped and tested on arm.

Ok for trunk?

Thanks,
Kyrill


2015-05-01  Kyrylo Tkachov  

* config/arm/arm.c (DBG_COST): New macro.
(arm_new_rtx_costs): Use above.
commit 554c118dd2c232a62e2e504f9af3bfcb417ce7c3
Author: Kyrylo Tkachov 
Date:   Thu Apr 2 13:37:20 2015 +0100

[ARM] Add debug dumping of cost table fields.

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 4abd38a..a460d76 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -9684,6 +9684,11 @@ arm_unspec_cost (rtx x, enum rtx_code /* outer_code */, bool speed_p, int *cost)
 	  }\
 	while (0);
 
+
+#define DBG_COST(F) ((dump_file && (dump_flags & TDF_DETAILS)  \
+  ? fprintf (dump_file, "using "#F" with cost %d from line %d\n",  \
+(F), __LINE__) : 0), (F))
+
 /* RTX costs.  Make an estimate of the cost of executing the operation
X, which is contained with an operation with code OUTER_CODE.
SPEED_P indicates whether the cost desired is the performance cost,
@@ -9784,7 +9789,7 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
 		  + arm_address_cost (XEXP (x, 0), mode,
   ADDR_SPACE_GENERIC, speed_p));
 #else
-*cost += extra_cost->ldst.load;
+*cost += DBG_COST (extra_cost->ldst.load);
 #endif
   return true;
 
@@ -9812,11 +9817,11 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
 	{
 	  HOST_WIDE_INT nregs = XVECLEN (x, 0);
 	  HOST_WIDE_INT regs_per_insn_1st = is_ldm
-	  ? extra_cost->ldst.ldm_regs_per_insn_1st
-	  : extra_cost->ldst.stm_regs_per_insn_1st;
+		? DBG_COST (extra_cost->ldst.ldm_regs_per_insn_1st)
+		: DBG_COST (extra_cost->ldst.stm_regs_per_insn_1st);
 	  HOST_WIDE_INT regs_per_insn_sub = is_ldm
-	   ? extra_cost->ldst.ldm_regs_per_insn_subsequent
-	   : extra_cost->ldst.stm_regs_per_insn_subsequent;
+		? DBG_COST (extra_cost->ldst.ldm_regs_per_insn_subsequent)
+		: DBG_COST (extra_cost->ldst.stm_regs_per_insn_subsequent);
 
 	  *cost += regs_per_insn_1st
 	   + COSTS_N_INSNS (((MAX (nregs - regs_per_insn_1st, 0))
@@ -9833,9 +9838,10 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
   if (TARGET_HARD_FLOAT && GET_MODE_CLASS (mode) == MODE_FLOAT
 	  && (mode == SFmode || !TARGET_VFP_SINGLE))
 	*cost += COSTS_N_INSNS (speed_p
-			   ? extra_cost->fp[mode != SFmode].div : 0);
+			? DBG_COST (extra_cost->fp[mode != SFmode].div) : 0);
   else if (mode == SImode && TARGET_IDIV)
-	*cost += COSTS_N_INSNS (speed_p ? extra_cost->mult[0].idiv : 0);
+	*cost += COSTS_N_INSNS (speed_p ? DBG_COST (extra_cost->mult[0].idiv)
+	 : 0);
   else
 	*cost = LIBCALL_COST (2);
   return false;	/* All arguments must be in registers.  */
@@ -9851,7 +9857,7 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
 	  *cost += (COSTS_N_INSNS (1)
 		   + rtx_cost (XEXP (x, 0), code, 0, speed_p));
 	  if (speed_p)
-	*cost += extra_cost->alu.shift_reg;
+	*cost += DBG_COST (extra_cost->alu.shift_reg);
 	  return true;
 	}
   /* Fall through */
@@ -9864,7 +9870,7 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
 	  *cost += (COSTS_N_INSNS (2)
 		   + rtx_cost (XEXP (x, 0), code, 0, speed_p));
 	  if (speed_p)
-	*cost += 2 * extra_cost->alu.shift;
+	*cost += DBG_COST (2 * extra_cost->alu.shift);
 	  return true;
 	}
   else if (mode == SImode)
@@ -9872,7 +9878,7 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
 	  *cost += rtx_cost (XEXP (x, 0), code, 0, speed_p);
 	  /* Slightly disparage register shifts at -Os, but not by much.  */
 	  if (!CONST_INT_P (XEXP (x, 1)))
-	*cost += (speed_p ? extra_cost->alu.shift_reg : 1
+	*cost += (speed_p ? DBG_COST (extra_cost->alu.shift_reg) : 1
 		  + rtx_cost (XEXP (x, 1), code, 1, speed_p));
 	  return true;
 	}
@@ -9885,7 +9891,7 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
 	  /* Slightly disparage register shifts at -Os, but not by
 	 much.  */
 	  if (!CONST_INT_P (XEXP (x, 1)))
-		*cost += (speed_p ? extra_cost->alu.shift_reg : 1
+		*cost += (speed_p ? DBG_COST (extra_cost->alu.shift_reg) : 1
 			  + rtx_cost (XEXP (x, 1), code, 1, speed_p));
 	}
 	  else if (code == LSHIFTRT || code == AS

Re: [patch] Perform anonymous constant propagation during inlining

2015-05-01 Thread Richard Biener
On May 1, 2015 12:27:17 PM GMT+02:00, Eric Botcazou  
wrote:
>> Hmm, special-casing this in the inliner looks odd to me.  ISTR the
>inliner
>> already propagates constant parameters to immediate uses, so I guess
>> you run into the casting case you handle specially.
>
>Right on both counts, the original GIMPLE looks like:
>
>  right.3 = (system__storage_elements__integer_address) right;
>  D.4203 = D.4201 % right.3;
>  D.4200 = (system__storage_elements__storage_offset) D.4203;
>  return D.4200;
>
>and setup_one_parameter has:
>
>/* If there is no setup required and we are in SSA, take the easy route
> replacing all SSA names representing the function parameter by the
> SSA name passed to function.
>
>   We need to construct map for the variable anyway as it might be used
> in different SSA names when parameter is set in function.
>
> Do replacement at -O0 for const arguments replaced by constant.
> This is important for builtin_constant_p and other construct requiring
> constant argument to be visible in inlined function body.  */
>  if (gimple_in_ssa_p (cfun) && rhs && def && is_gimple_reg (p)
>  && (optimize
>  || (TREE_READONLY (p)
> && is_gimple_min_invariant (rhs)))
>  && (TREE_CODE (rhs) == SSA_NAME
> || is_gimple_min_invariant (rhs))
>  && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (def))
>{
>  insert_decl_map (id, def, rhs);
>  return insert_init_debug_bind (id, bb, var, rhs, NULL);
>}
>
>and here is the GIMPLE after inlining:
>
>  _17 = _16;
>  _18 = _17;
>  right.3_19 = 8;
>  _20 = _18 % right.3_19;
>  _21 = (system__storage_elements__storage_offset) _20;
>
>so the constant replacement is done for right.3_19 by the above block.
>
>> But then if any constant propagation is ok at -O0 why not perform
>> full-fledged constant propagation (with !DECL_IGNORED_P vars as a
>> propagation barrier) as a regular SSA pass?  That is, if you'd had a
>> Inline_Always function like
>> 
>> int foo (int i)
>> {
>>   return (i + 1) / i;
>> }
>> 
>> you'd not get the desired result as the i + 1 stmt wouldn't be folded
>> and thus the (i + 1) / i stmt wouldn't either.
>
>That's OK, only the trivial cases need to be dealt with since it's -O0
>so 
>running a fully-fledged constant propagation seems overkill.
>
>> That said - why does RTL optimization not save you here anyway?
>> After all, it is responsible for turning divisions into shifts.
>
>You mean the RTL expander?  Because the SSA name isn't replaced with
>the RHS 
>of its defining statement in:
>
> /* For EXPAND_INITIALIZER try harder to get something simpler.  */
>  if (g == NULL
> && modifier == EXPAND_INITIALIZER
> && !SSA_NAME_IS_DEFAULT_DEF (exp)
> && (optimize || DECL_IGNORED_P (SSA_NAME_VAR (exp)))
> && stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
>   g = SSA_NAME_DEF_STMT (exp);
>
>since modifier is EXPAND_NORMAL.  Do you think it would be OK to be a
>little 
>more aggressive here?  Something like:
>
>  /* If we aren't on the LHS, look into the defining statement.  */
>  if (g == NULL
> && modifier != EXPAND_WRITE
> && !SSA_NAME_IS_DEFAULT_DEF (exp)
> && (optimize || DECL_IGNORED_P (SSA_NAME_VAR (exp)))
> && stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
>{
>   g = SSA_NAME_DEF_STMT (exp);
>   /* For EXPAND_INITIALIZER substitute in all cases, otherwise do
>  it only for constants.  */
>   if (modifier != EXPAND_INITIALIZER
>   && (!gimple_assign_copy_p (g)
>   || !is_gimple_min_invariant (gimple_assign_rhs1 (g
> g = NULL;
>}
>
>That's certainly sufficient here.

Yeah, I think that's a way better place for the hack.

Richard.




Re: [PATCH] Mark help string in DEFPARAM as no-c-format

2015-05-01 Thread Jeff Law

On 05/01/2015 05:27 AM, Andreas Schwab wrote:

Tested with make gcc.pot.

Andreas.

PR translation/65959
* params.h (DEFPARAM): Rename msgid to nocmsgid.

OK.
jeff



Re: Mostly rewrite genrecog

2015-05-01 Thread Jeff Law

On 05/01/2015 06:41 AM, Richard Sandiford wrote:

Richard Sandiford  writes:

Richard Biener  writes:

On Thu, Apr 30, 2015 at 2:08 PM, Andreas Schwab  wrote:

Richard Sandiford  writes:


Andreas Schwab  writes:

Richard Sandiford  writes:


/* Represents a test and the action that should be taken on the result.
If a transition exists for the test outcome, the machine switches
to the transition's target state.  If no suitable transition exists,
the machine either falls through to the next decision or, if there are no
more decisions to try, fails the match.  */
struct decision : list_head 
{
   decision (const test &);

   void set_parent (list_head  *s);
   bool if_statement_p (uint64_t * = 0) const;

   /* The state to which this decision belongs.  */
   state *s;

   /* Links to other decisions in the same state.  */
   decision *prev, *next;

   /* The test to perform.  */
   struct test test;
};


../../gcc/genrecog.c:1467: error: declaration of 'test decision::test'
../../gcc/genrecog.c:1051: error: changes meaning of 'test' from
struct test'

Bootstrap compiler is gcc 4.3.4.


Bah.  Does it like "::test test" instead of "struct test test"?


Same error.


You have to use a different name I believe (or -fpermissive).


Hmm, but then why does it work with more recent compilers?


Whatever the reason, I suppose the path of least resistance is to
rename the thing.

Tested on x86_64-linux-gnu.  OK to install?

Thanks,
Richard


gcc/
* genrecog.c (test): Rename to rtx_test.  Update rest of file
accordingly.

OK.
jeff



Re: [PATCH, AArch64] Add Cortex-A53 erratum 843419 configure-time option

2015-05-01 Thread Yvan Roux
On 1 May 2015 at 13:39, Yvan Roux  wrote:
> Hi Marcus,
>
> (Sorry wanted to cc you in my first mail but seems that gmail prefers
> Maxim to Marcus ! ;)
>
> On 1 May 2015 at 13:11, Marcus Shawcroft  wrote:
>> On 1 May 2015 at 10:11, Yvan Roux  wrote:
>>> Hi all,
>>>
>>> As described in the thread bellow, there is a link-time workaround for
>>> an erratum (843419) of some early revision of Cortex-A53.  Similarly
>>> to what was done for a previous erratum, this patch adds a new
>>> configure-time option --enable-fix-cortex-a53-843419 that pass down
>>> the linker option --fix-cortex-a53-843419.
>>>
>>> I haven't implemented flags to explicitly disable/enable it during
>>> compilation as it is only a linker workaround, but I can do it if you
>>> think it's necessary.
>>
>> Hi Yvan,
>>
>> In the case of the 835769 erratum, providing such GCC configury made
>> (some) sense because the workaround included both a GCC and an LD
>> component. GCC in effect needed the option to control GCC behaviour
>> aswell as LD behaviour. The same is not true of 843419. The net effect
>> of the proposed  patch here is to provide a configure option in GCC to
>> change the default behaviour of LD, with no other purpose within GCC
>> itself.  This seems rather bizarre to me. I would have thought that if
>> the sole objective is to change the default behaviour of LD, then
>> there should be configure time options on LD, rather than GCC.
>
> Yes indeed.
>
>> That said, I can also see that providing consistent behaviour across
>> these various work around configure options and consistent run time
>> options for the user will reduce confusion in the future, both for
>> folks building toolchains and for the folks using them.  From this
>> perspective I think it would be better to go with this patch *and*
>> include the flags explicitly such the both of the current workaround
>> have equivalent configury behaviour and have equivalent user flags at
>> run time.
>
> Ok I'll add the -mfix-cortex-a53-843419 flags to be consistent.

Here is the new patch, I kept the "Report" property for the flag even
if nothing is changed in the assembly generated, but I think it's good
to have the info.

Cheers,
Yvan

2015-05-01  Yvan Roux  

 * configure.ac: Add --enable-fix-cortex-a53-843419 option.
 * configure: Regenerate.
 * config/aarch64/aarch64-elf-raw.h (CA53_ERR_843419_SPEC): Define.
 (LINK_SPEC): Include CA53_ERR_843419_SPEC.
 * config/aarch64/aarch64-linux.h (CA53_ERR_843419_SPEC): Define.
 (LINK_SPEC): Include CA53_ERR_843419_SPEC.
 * doc/install.texi (aarch64*-*-*): Document
 new --enable-fix-cortex-a53-843419 option
 * config/aarch64/aarch64.opt (mfix-cortex-a53-843419): New option.
 * doc/invoke.texi (AArch64 Options): Document -mfix-cortex-a53-843419
 and -mno-fix-cortex-a53-8434199 options.

>
> Cheers
> Yvan
>
>> Cheers
>> /Marcus
>>
>>>
>>> https://sourceware.org/ml/binutils-cvs/2015-04/msg00012.html
>>>
>>> Is it ok for trunk and/or branches ?
>>>
>>> Thanks,
>>> Yvan
>>>
>>> 2015-05-01  Yvan Roux  
>>>
>>> * configure.ac: Add --enable-fix-cortex-a53-843419 option.
>>> * configure: Regenerate.
>>> * config/aarch64/aarch64-elf-raw.h (CA53_ERR_843419_SPEC): Define.
>>> (LINK_SPEC): Include CA53_ERR_843419_SPEC.
>>> * config/aarch64/aarch64-linux.h (CA53_ERR_843419_SPEC): Define.
>>> (LINK_SPEC): Include CA53_ERR_843419_SPEC.
>>> * doc/install.texi (aarch64*-*-*): Document
>>> new --enable-fix-cortex-a53-843419 option.
diff --git a/gcc/config/aarch64/aarch64-elf-raw.h 
b/gcc/config/aarch64/aarch64-elf-raw.h
index ebeeb50..bd5e51c 100644
--- a/gcc/config/aarch64/aarch64-elf-raw.h
+++ b/gcc/config/aarch64/aarch64-elf-raw.h
@@ -35,10 +35,19 @@
   " %{mfix-cortex-a53-835769:--fix-cortex-a53-835769}"
 #endif
 
+#ifdef TARGET_FIX_ERR_A53_843419_DEFAULT
+#define CA53_ERR_843419_SPEC \
+  " %{!mno-fix-cortex-a53-843419:--fix-cortex-a53-843419}"
+#else
+#define CA53_ERR_843419_SPEC \
+  " %{mfix-cortex-a53-843419:--fix-cortex-a53-843419}"
+#endif
+
 #ifndef LINK_SPEC
 #define LINK_SPEC "%{mbig-endian:-EB} %{mlittle-endian:-EL} -X \
   -maarch64elf%{mabi=ilp32*:32}%{mbig-endian:b}" \
-  CA53_ERR_835769_SPEC
+  CA53_ERR_835769_SPEC \
+  CA53_ERR_843419_SPEC
 #endif
 
 #endif /* GCC_AARCH64_ELF_RAW_H */
diff --git a/gcc/config/aarch64/aarch64-linux.h 
b/gcc/config/aarch64/aarch64-linux.h
index 9abb252..7973268 100644
--- a/gcc/config/aarch64/aarch64-linux.h
+++ b/gcc/config/aarch64/aarch64-linux.h
@@ -49,8 +49,17 @@
   " %{mfix-cortex-a53-835769:--fix-cortex-a53-835769}"
 #endif
 
+#ifdef TARGET_FIX_ERR_A53_843419_DEFAULT
+#define CA53_ERR_843419_SPEC \
+  " %{!mno-fix-cortex-a53-843419:--fix-cortex-a53-843419}"
+#else
+#define CA53_ERR_843419_SPEC \
+  " %{mfix-cortex-a53-843419:--fix-cortex-a53-843419}"
+#endif
+
 #define LINK_SPEC LINUX_TARGET_LINK_SPEC \
-  CA53_ERR_835769_SPEC
+  CA53_ERR_835769_SPEC \
+  CA53_ERR_843419_SPE

Re: [rs6000] Fix compare debug failure on AIX

2015-05-01 Thread David Edelsohn
On Thu, Apr 30, 2015 at 7:28 AM, Eric Botcazou  wrote:
>> We might want to check if doing -Og and not just -O0.
>
> You're right, thanks, amended patch attached, same ChangeLog.

Why should GCC unnecessarily create stack frames to avoid
compare-debug testcase failures?

- David


[libstdc++ PATCH] Implement observer_ptr

2015-05-01 Thread Ville Voutilainen
Tested on Linux-x64.

2015-05-01  Ville Voutilainen  
Implement observer_ptr.
* include/Makefile.am: Add new exported header.
* include/Makefile.in: Regenerate.
* include/experimental/memory: New.
* testsuite/experimental/memory/observer_ptr/assignment/assign.cc: Likewise.
* testsuite/experimental/memory/observer_ptr/cons/cons.cc: Likewise.
* testsuite/experimental/memory/observer_ptr/hash/hash.cc: Likewise.
* testsuite/experimental/memory/observer_ptr/make_observer.cc: Likewise.
* testsuite/experimental/memory/observer_ptr/relops/relops.cc: Likewise.
* testsuite/experimental/memory/observer_ptr/requirements.cc: Likewise.
* testsuite/experimental/memory/observer_ptr/swap/swap.cc: Likewise.
* testsuite/experimental/memory/observer_ptr/typedefs.cc: Likewise.
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 2677132..5962e23 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -647,6 +647,7 @@ experimental_headers = \
${experimental_srcdir}/any \
${experimental_srcdir}/chrono \
${experimental_srcdir}/functional \
+   ${experimental_srcdir}/memory \
${experimental_srcdir}/optional \
${experimental_srcdir}/ratio \
${experimental_srcdir}/string_view \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 9c423cb..1a13b89 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -914,6 +914,7 @@ experimental_headers = \
${experimental_srcdir}/any \
${experimental_srcdir}/chrono \
${experimental_srcdir}/functional \
+   ${experimental_srcdir}/memory \
${experimental_srcdir}/optional \
${experimental_srcdir}/ratio \
${experimental_srcdir}/string_view \
diff --git a/libstdc++-v3/include/experimental/memory 
b/libstdc++-v3/include/experimental/memory
new file mode 100644
index 000..6b2e78e
--- /dev/null
+++ b/libstdc++-v3/include/experimental/memory
@@ -0,0 +1,233 @@
+//  -*- C++ -*-
+
+// Copyright (C) 2015 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.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file experimental/memory
+ *  This is a TS C++ Library header.
+ */
+
+//
+// N4336 Working Draft, C++ Extensions for Library Fundamentals, Version 2
+//
+
+#ifndef _GLIBCXX_EXPERIMENTAL_MEMORY
+#define _GLIBCXX_EXPERIMENTAL_MEMORY 1
+
+#pragma GCC system_header
+
+#if __cplusplus <= 201103L
+# include 
+#else
+
+#include 
+#include 
+#include 
+#include 
+
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+namespace experimental
+{
+inline namespace fundamentals_v2
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+template  class observer_ptr {
+public:
+  // publish our template parameter and variations thereof
+  using element_type = _Tp;
+  using __pointer = add_pointer_t<_Tp>;// exposition-only
+  using __reference = add_lvalue_reference_t<_Tp>; // exposition-only
+  
+  // 3.2.2, observer_ptr constructors
+  // default c’tor
+  constexpr observer_ptr() noexcept
+  : __t()
+  { }
+
+  // pointer-accepting c’tors
+  constexpr observer_ptr(nullptr_t) noexcept
+  : __t()
+  { }
+  
+  constexpr explicit observer_ptr(__pointer __p) noexcept
+  : __t(__p)
+  { }
+
+  // copying c’tors (in addition to compiler-generated copy c’tor)
+  template ::type, __pointer
+  >::value
+>::type> 
+  constexpr observer_ptr(observer_ptr<_Up> __p) noexcept
+  : __t(__p.get())
+  {
+  }
+
+  // 3.2.3, observer_ptr observers
+  constexpr __pointer get() const noexcept
+  {
+return __t;
+  }
+
+  constexpr __reference operator*() const
+  {
+return *get();
+  }
+
+  constexpr __pointer operator->() const noexcept
+  {
+return get();
+  }
+
+  constexpr explicit operator bool() const noexcept
+  {
+return get() != nullptr;
+  }
+
+  // 3.2.4, observer_ptr conversions
+  constexpr explicit operator __pointer() const noexcept
+  {
+return get();
+  }
+
+  // 3.2.5, observer_ptr modifiers

Re: [PATCH][AArch64] Make aarch64_min_divisions_for_recip_mul configurable

2015-05-01 Thread Kyrill Tkachov


On 01/05/15 14:11, Wilco Dijkstra wrote:

Marcus Shawcroft wrote:
On 1 May 2015 at 12:26, Wilco Dijkstra  wrote:



Marcus Shawcroft wrote:
On 27 April 2015 at 14:43, Wilco Dijkstra  wrote:


  static unsigned int
-aarch64_min_divisions_for_recip_mul (enum machine_mode mode ATTRIBUTE_UNUSED)
+aarch64_min_divisions_for_recip_mul (enum machine_mode mode)
  {
-  return 2;
+  if (GET_MODE_UNIT_SIZE (mode) == 4)
+return aarch64_tune_params->min_div_recip_mul_sf;
+  return aarch64_tune_params->min_div_recip_mul_df;

This should be expressed directly as mode == SFmode (or DFmode) rather
than the indirect approach of first computing the size first.

Can we never see vector types at this point?

Fair point, curiously we don't appear to see them, but I see no reason
why we should not.  Commit your patch as proposed.

Cheers /Marcus

And this one please.


Done with r222679.

Kyrill



Wilco

2015-05-01  Wilco Dijkstra  

* gcc/config/aarch64/aarch64-protos.h (tune_params):
Add min_div_recip_mul_sf and min_div_recip_mul_df fields.
* gcc/config/aarch64/aarch64.c (aarch64_min_divisions_for_recip_mul):
Return value depending on target.
(generic_tunings): Initialize new target settings.
(cortexa53_tunings): Likewise.
(cortexa57_tunings): Likewise.
(thunderx_tunings): Likewise.
(xgene1_tunings): Likewise.





RE: [PATCH][AArch64] Make aarch64_min_divisions_for_recip_mul configurable

2015-05-01 Thread Wilco Dijkstra
> Marcus Shawcroft wrote:
> On 1 May 2015 at 12:26, Wilco Dijkstra  wrote:
> >
> >
> >> Marcus Shawcroft wrote:
> >> On 27 April 2015 at 14:43, Wilco Dijkstra  wrote:
> >>
> >> >>  static unsigned int
> >> >> -aarch64_min_divisions_for_recip_mul (enum machine_mode mode 
> >> >> ATTRIBUTE_UNUSED)
> >> >> +aarch64_min_divisions_for_recip_mul (enum machine_mode mode)
> >> >>  {
> >> >> -  return 2;
> >> >> +  if (GET_MODE_UNIT_SIZE (mode) == 4)
> >> >> +return aarch64_tune_params->min_div_recip_mul_sf;
> >> >> +  return aarch64_tune_params->min_div_recip_mul_df;
> >>
> >> This should be expressed directly as mode == SFmode (or DFmode) rather
> >> than the indirect approach of first computing the size first.
> >
> > Can we never see vector types at this point?
> 
> Fair point, curiously we don't appear to see them, but I see no reason
> why we should not.  Commit your patch as proposed.
> 
> Cheers /Marcus

And this one please.

Wilco

2015-05-01  Wilco Dijkstra  

* gcc/config/aarch64/aarch64-protos.h (tune_params):
Add min_div_recip_mul_sf and min_div_recip_mul_df fields.
* gcc/config/aarch64/aarch64.c (aarch64_min_divisions_for_recip_mul):
Return value depending on target.
(generic_tunings): Initialize new target settings.
(cortexa53_tunings): Likewise.
(cortexa57_tunings): Likewise.
(thunderx_tunings): Likewise.
(xgene1_tunings): Likewise.

---
 gcc/config/aarch64/aarch64-protos.h |  2 ++
 gcc/config/aarch64/aarch64.c| 26 +++---
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 59c5824..4331e5c 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -177,6 +177,8 @@ struct tune_params
   const int int_reassoc_width;
   const int fp_reassoc_width;
   const int vec_reassoc_width;
+  const int min_div_recip_mul_sf;
+  const int min_div_recip_mul_df;
 };
 
 HOST_WIDE_INT aarch64_initial_elimination_offset (unsigned, unsigned);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index e22d72e..42a96f6 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -353,7 +353,9 @@ static const struct tune_params generic_tunings =
   4,   /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
-  1/* vec_reassoc_width.  */
+  1,   /* vec_reassoc_width.  */
+  2,   /* min_div_recip_mul_sf.  */
+  2/* min_div_recip_mul_df.  */
 };
 
 static const struct tune_params cortexa53_tunings =
@@ -371,7 +373,9 @@ static const struct tune_params cortexa53_tunings =
   4,   /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
-  1/* vec_reassoc_width.  */
+  1,   /* vec_reassoc_width.  */
+  2,   /* min_div_recip_mul_sf.  */
+  2/* min_div_recip_mul_df.  */
 };
 
 static const struct tune_params cortexa57_tunings =
@@ -389,7 +393,9 @@ static const struct tune_params cortexa57_tunings =
   4,   /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
-  1/* vec_reassoc_width.  */
+  1,   /* vec_reassoc_width.  */
+  2,   /* min_div_recip_mul_sf.  */
+  2/* min_div_recip_mul_df.  */
 };
 
 static const struct tune_params thunderx_tunings =
@@ -406,7 +412,9 @@ static const struct tune_params thunderx_tunings =
   8,   /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
-  1/* vec_reassoc_width.  */
+  1,   /* vec_reassoc_width.  */
+  2,   /* min_div_recip_mul_sf.  */
+  2/* min_div_recip_mul_df.  */
 };
 
 static const struct tune_params xgene1_tunings =
@@ -423,7 +431,9 @@ static const struct tune_params xgene1_tunings =
   16,  /* loop_align.  */
   2,   /* int_reassoc_width.  */
   4,   /* fp_reassoc_width.  */
-  1/* vec_reassoc_width.  */
+  1,   /* vec_reassoc_width.  */
+  2,   /* min_div_recip_mul_sf.  */
+  2/* min_div_recip_mul_df.  */
 };
 
 /* A processor implementing AArch64.  */
@@ -512,9 +522,11 @@ static const char * const aarch64_condition_codes[] =
 };
 
 static unsigned int
-aarch64_min_divisions_for_recip_mul (enum machine_mode mode ATTRIBUTE_UNUSED)
+aarch64_min_divisions_for_recip_mul (enum machine_mode mode)
 {
-  return 2;
+  if (GET_MODE_UNIT_SIZE (mode) == 4)
+return aarch64_tune_params->min_div_recip_mul_sf;
+  return aarch64_tune_params->min_div_recip_mul_df;
 }
 
 static int
-- 
1.9.1



Re: [PATCH][AArch64] Fix Cortex-A53 shift costs

2015-05-01 Thread Kyrill Tkachov


On 01/05/15 14:07, Wilco Dijkstra wrote:

Marcus Shawcroft wrote:
On 5 March 2015 at 14:49, Wilco Dijkstra  wrote:

This patch fixes the shift costs for Cortex-A53 so they are more accurate - 
immediate shifts

use

SBFM/UBFM which takes 2 cycles, register controlled shifts take 1 cycle. 
Bootstrap and

regression

OK.

ChangeLog:
2015-03-05  Wilco Dijkstra  

 * gcc/config/arm/aarch-cost-tables.h (cortexa53_extra_costs):
 Make Cortex-A53 shift costs more accurate.

OK /Marcus

Kyrill, could you check this in please? Patch attached


Hi Wilco,

I've committed this with r222678.

Cheers,
Kyrill



Wilco

2015-05-01  Wilco Dijkstra  

* gcc/config/arm/aarch-cost-tables.h (cortexa53_extra_costs):
Make Cortex-A53 shift costs more accurate.






RE: [PATCH][AArch64] Fix Cortex-A53 shift costs

2015-05-01 Thread Wilco Dijkstra
> Marcus Shawcroft wrote:
> On 5 March 2015 at 14:49, Wilco Dijkstra  wrote:
> > This patch fixes the shift costs for Cortex-A53 so they are more accurate - 
> > immediate shifts
> use
> > SBFM/UBFM which takes 2 cycles, register controlled shifts take 1 cycle. 
> > Bootstrap and
> regression
> > OK.
> >
> > ChangeLog:
> > 2015-03-05  Wilco Dijkstra  
> >
> > * gcc/config/arm/aarch-cost-tables.h (cortexa53_extra_costs):
> > Make Cortex-A53 shift costs more accurate.
> 
> OK /Marcus

Kyrill, could you check this in please? Patch attached

Wilco

2015-05-01  Wilco Dijkstra  

* gcc/config/arm/aarch-cost-tables.h (cortexa53_extra_costs):
Make Cortex-A53 shift costs more accurate.


---
 gcc/config/arm/aarch-cost-tables.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/config/arm/aarch-cost-tables.h 
b/gcc/config/arm/aarch-cost-tables.h
index 05e96a9..6bb8ede 100644
--- a/gcc/config/arm/aarch-cost-tables.h
+++ b/gcc/config/arm/aarch-cost-tables.h
@@ -130,12 +130,12 @@ const struct cpu_cost_table cortexa53_extra_costs =
 0, /* arith.  */
 0, /* logical.  */
 COSTS_N_INSNS (1), /* shift.  */
-COSTS_N_INSNS (2), /* shift_reg.  */
+0, /* shift_reg.  */
 COSTS_N_INSNS (1), /* arith_shift.  */
-COSTS_N_INSNS (2), /* arith_shift_reg.  */
+COSTS_N_INSNS (1), /* arith_shift_reg.  */
 COSTS_N_INSNS (1), /* log_shift.  */
-COSTS_N_INSNS (2), /* log_shift_reg.  */
-0, /* extend.  */
+COSTS_N_INSNS (1), /* log_shift_reg.  */
+COSTS_N_INSNS (1), /* extend.  */
 COSTS_N_INSNS (1), /* extend_arith.  */
 COSTS_N_INSNS (1), /* bfi.  */
 COSTS_N_INSNS (1), /* bfx.  */
-- 
1.9.1



Re: [PATCH][AArch64] Fix aarch64_rtx_costs of PLUS/MINUS

2015-05-01 Thread Kyrill Tkachov


On 01/05/15 11:22, Marcus Shawcroft wrote:

On 4 March 2015 at 15:37, Wilco Dijkstra  wrote:

Include the cost of op0 and op1 in all cases in PLUS and MINUS in 
aarch64_rtx_costs.
Bootstrap & regression OK.

ChangeLog:
2015-03-04  Wilco Dijkstra  

 * gcc/config/aarch64/aarch64.c (aarch64_rtx_costs):
 Calculate cost of op0 and op1 in PLUS and MINUS cases.

OK, we take this one instead of Kyrill's. /Marcus



I've committed this patch on Wilcos' behalf with r222676.

Thanks,
Kyrill



Re: [PATCH][AArch64] Fix geniterators.sh to use standard BRE syntax in sed

2015-05-01 Thread Marcus Shawcroft
On 23 March 2015 at 17:06, Szabolcs Nagy  wrote:
> GCC can be compiled for aarch64 target with busybox sed except for
> the geniterators.sh script which uses nonstandard basic regex.
>
> I explicitly set LC_ALL=C too because the regex depends on collation
> order.
>
> I tested that the script gives the same result on iterators.md.
>
> Ok?
>
> gcc/Changelog:
>
> 2015-03-23  Szabolcs Nagy  
>
> * config/aarch64/geniterators.sh: Use standard BRE in sed.

OK /Marcus


Re: [patch] Implement ISO/IEC TS 18822 C++ File system TS

2015-05-01 Thread Rainer Orth
Jonathan Wakely  writes:

> I've tested this on GNU/Linux and DragonFly BSD, but as it's probably
> not going to build everywhere I've added the configure option
> --enable-libstdcxx-filesystem-ts which defaults to enabled on GNU, BSD
> and Solaris targets, and disabled elsewhere for now. If it fails to
> build on any of those targets we can change the default while we fix
> the problem.

Unfortunately, the patch breaks Solaris 10 bootstrap, which lacks
fchmodat:

/vol/gcc/src/hg/trunk/local/libstdc++-v3/src/filesystem/ops.cc: In function 
'void std::experimental::filesystem::v1::permissions(const 
std::experimental::filesystem::v1::__cxx11::path&, 
std::experimental::filesystem::v1::perms, std::error_code&)':
/vol/gcc/src/hg/trunk/local/libstdc++-v3/src/filesystem/ops.cc:890:17: error: 
'::fchmodat' has not been declared
   if (int err = ::fchmodat(AT_FDCWD, p.c_str(), static_cast(prms), 0))
 ^
make[6]: *** [ops.lo] Error 1

Rainer

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


Re: Mostly rewrite genrecog

2015-05-01 Thread Richard Sandiford
Richard Sandiford  writes:
> Richard Biener  writes:
>> On Thu, Apr 30, 2015 at 2:08 PM, Andreas Schwab  
>> wrote:
>>> Richard Sandiford  writes:
>>>
 Andreas Schwab  writes:
> Richard Sandiford  writes:
>
>> /* Represents a test and the action that should be taken on the result.
>>If a transition exists for the test outcome, the machine switches
>>to the transition's target state.  If no suitable transition exists,
>>the machine either falls through to the next decision or, if there 
>> are no
>>more decisions to try, fails the match.  */
>> struct decision : list_head 
>> {
>>   decision (const test &);
>>
>>   void set_parent (list_head  *s);
>>   bool if_statement_p (uint64_t * = 0) const;
>>
>>   /* The state to which this decision belongs.  */
>>   state *s;
>>
>>   /* Links to other decisions in the same state.  */
>>   decision *prev, *next;
>>
>>   /* The test to perform.  */
>>   struct test test;
>> };
>
> ../../gcc/genrecog.c:1467: error: declaration of 'test decision::test'
> ../../gcc/genrecog.c:1051: error: changes meaning of 'test' from
> struct test'
>
> Bootstrap compiler is gcc 4.3.4.

 Bah.  Does it like "::test test" instead of "struct test test"?
>>>
>>> Same error.
>>
>> You have to use a different name I believe (or -fpermissive).
>
> Hmm, but then why does it work with more recent compilers?

Whatever the reason, I suppose the path of least resistance is to
rename the thing.

Tested on x86_64-linux-gnu.  OK to install?

Thanks,
Richard


gcc/
* genrecog.c (test): Rename to rtx_test.  Update rest of file
accordingly.

Index: gcc/genrecog.c
===
--- gcc/genrecog.c  2015-04-30 17:45:29.662231979 +0100
+++ gcc/genrecog.c  2015-04-30 17:45:29.806230258 +0100
@@ -1047,9 +1047,9 @@ struct pattern_use
 };
 
 /* Represents a test performed by a decision.  */
-struct test
+struct rtx_test
 {
-  test ();
+  rtx_test ();
 
   /* The types of test that can be performed.  Most of them take as input
  an rtx X.  Some also take as input a transition label LABEL; the others
@@ -1140,136 +1140,136 @@ struct test
 acceptance_type acceptance;
   } u;
 
-  static test code (position *);
-  static test mode (position *);
-  static test int_field (position *, int);
-  static test wide_int_field (position *, int);
-  static test veclen (position *);
-  static test peep2_count (int);
-  static test veclen_ge (position *, int);
-  static test predicate (position *, const pred_data *, machine_mode);
-  static test duplicate (position *, int);
-  static test pattern (position *, pattern_use *);
-  static test have_num_clobbers ();
-  static test c_test (const char *);
-  static test set_op (position *, int);
-  static test accept (const acceptance_type &);
+  static rtx_test code (position *);
+  static rtx_test mode (position *);
+  static rtx_test int_field (position *, int);
+  static rtx_test wide_int_field (position *, int);
+  static rtx_test veclen (position *);
+  static rtx_test peep2_count (int);
+  static rtx_test veclen_ge (position *, int);
+  static rtx_test predicate (position *, const pred_data *, machine_mode);
+  static rtx_test duplicate (position *, int);
+  static rtx_test pattern (position *, pattern_use *);
+  static rtx_test have_num_clobbers ();
+  static rtx_test c_test (const char *);
+  static rtx_test set_op (position *, int);
+  static rtx_test accept (const acceptance_type &);
 
   bool terminal_p () const;
   bool single_outcome_p () const;
 
 private:
-  test (position *, kind_enum);
+  rtx_test (position *, kind_enum);
 };
 
-test::test () {}
+rtx_test::rtx_test () {}
 
-test::test (position *pos_in, kind_enum kind_in)
+rtx_test::rtx_test (position *pos_in, kind_enum kind_in)
   : pos (pos_in), pos_operand (-1), kind (kind_in) {}
 
-test
-test::code (position *pos)
+rtx_test
+rtx_test::code (position *pos)
 {
-  return test (pos, test::CODE);
+  return rtx_test (pos, rtx_test::CODE);
 }
 
-test
-test::mode (position *pos)
+rtx_test
+rtx_test::mode (position *pos)
 {
-  return test (pos, test::MODE);
+  return rtx_test (pos, rtx_test::MODE);
 }
 
-test
-test::int_field (position *pos, int opno)
+rtx_test
+rtx_test::int_field (position *pos, int opno)
 {
-  test res (pos, test::INT_FIELD);
+  rtx_test res (pos, rtx_test::INT_FIELD);
   res.u.opno = opno;
   return res;
 }
 
-test
-test::wide_int_field (position *pos, int opno)
+rtx_test
+rtx_test::wide_int_field (position *pos, int opno)
 {
-  test res (pos, test::WIDE_INT_FIELD);
+  rtx_test res (pos, rtx_test::WIDE_INT_FIELD);
   res.u.opno = opno;
   return res;
 }
 
-test
-test::veclen (position *pos)
+rtx_test
+rtx_test::veclen (position *pos)
 {
-  return test (pos, test::VECLEN);
+  return rtx_test (pos, rtx_test::VECLEN);
 }
 
-test
-test::peep2_count (int min_len)
+rtx_test
+rtx_

Re: [PATCH][AArch64] Handle FLOAT and UNSIGNED_FLOAT in rtx costs

2015-05-01 Thread Marcus Shawcroft
On 1 May 2015 at 09:21, Kyrill Tkachov  wrote:

> 2015-05-01  Kyrylo Tkachov  
>
> * config/aarch64/aarch64.c (aarch64_rtx_costs): Handle FLOAT and
> UNSIGNED_FLOAT.

OK /Marcus


Re: [ARM,AArch64][testsuite] AdvSIMD intrinsics tests cleanup: remove useless expected values.

2015-05-01 Thread Marcus Shawcroft
On 30 April 2015 at 20:38, Christophe Lyon  wrote:
> This is a cleanup of the series of tests I added some time ago.
>
> During the latest reviews, I got comments about the fact that some
> intrinsics do not support all the vector types but the corresponding
> tests would still contain dummy expected results for those variants.
>
> This patch cleans this up, by:
> * removing all these dummy expected values
> * where needed, checking results of each variant rather than relying
> on the general macro which tests all the variants, to save coding
> lines.
>
> Maybe it's a bit big, but it's mostly mechanical.
>
> Tested on ARM and AArch64 (LE/BE) using qemu.
>
> OK for trunk?

OK /Marcus


Re: [PATCH][AArch64] Make aarch64_min_divisions_for_recip_mul configurable

2015-05-01 Thread Marcus Shawcroft
On 1 May 2015 at 12:26, Wilco Dijkstra  wrote:
>
>
>> Marcus Shawcroft wrote:
>> On 27 April 2015 at 14:43, Wilco Dijkstra  wrote:
>>
>> >>  static unsigned int
>> >> -aarch64_min_divisions_for_recip_mul (enum machine_mode mode 
>> >> ATTRIBUTE_UNUSED)
>> >> +aarch64_min_divisions_for_recip_mul (enum machine_mode mode)
>> >>  {
>> >> -  return 2;
>> >> +  if (GET_MODE_UNIT_SIZE (mode) == 4)
>> >> +return aarch64_tune_params->min_div_recip_mul_sf;
>> >> +  return aarch64_tune_params->min_div_recip_mul_df;
>>
>> This should be expressed directly as mode == SFmode (or DFmode) rather
>> than the indirect approach of first computing the size first.
>
> Can we never see vector types at this point?

Fair point, curiously we don't appear to see them, but I see no reason
why we should not.  Commit your patch as proposed.

Cheers /Marcus


New Swedish PO file for 'cpplib' (version 5.1.0)

2015-05-01 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/cpplib/sv.po

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

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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




Contents of PO file 'cpplib-5.1.0.sv.po'

2015-05-01 Thread Translation Project Robot


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



Re: [PATCH, AArch64] Add Cortex-A53 erratum 843419 configure-time option

2015-05-01 Thread Yvan Roux
Hi Marcus,

(Sorry wanted to cc you in my first mail but seems that gmail prefers
Maxim to Marcus ! ;)

On 1 May 2015 at 13:11, Marcus Shawcroft  wrote:
> On 1 May 2015 at 10:11, Yvan Roux  wrote:
>> Hi all,
>>
>> As described in the thread bellow, there is a link-time workaround for
>> an erratum (843419) of some early revision of Cortex-A53.  Similarly
>> to what was done for a previous erratum, this patch adds a new
>> configure-time option --enable-fix-cortex-a53-843419 that pass down
>> the linker option --fix-cortex-a53-843419.
>>
>> I haven't implemented flags to explicitly disable/enable it during
>> compilation as it is only a linker workaround, but I can do it if you
>> think it's necessary.
>
> Hi Yvan,
>
> In the case of the 835769 erratum, providing such GCC configury made
> (some) sense because the workaround included both a GCC and an LD
> component. GCC in effect needed the option to control GCC behaviour
> aswell as LD behaviour. The same is not true of 843419. The net effect
> of the proposed  patch here is to provide a configure option in GCC to
> change the default behaviour of LD, with no other purpose within GCC
> itself.  This seems rather bizarre to me. I would have thought that if
> the sole objective is to change the default behaviour of LD, then
> there should be configure time options on LD, rather than GCC.

Yes indeed.

> That said, I can also see that providing consistent behaviour across
> these various work around configure options and consistent run time
> options for the user will reduce confusion in the future, both for
> folks building toolchains and for the folks using them.  From this
> perspective I think it would be better to go with this patch *and*
> include the flags explicitly such the both of the current workaround
> have equivalent configury behaviour and have equivalent user flags at
> run time.

Ok I'll add the -mfix-cortex-a53-843419 flags to be consistent.

Cheers
Yvan

> Cheers
> /Marcus
>
>>
>> https://sourceware.org/ml/binutils-cvs/2015-04/msg00012.html
>>
>> Is it ok for trunk and/or branches ?
>>
>> Thanks,
>> Yvan
>>
>> 2015-05-01  Yvan Roux  
>>
>> * configure.ac: Add --enable-fix-cortex-a53-843419 option.
>> * configure: Regenerate.
>> * config/aarch64/aarch64-elf-raw.h (CA53_ERR_843419_SPEC): Define.
>> (LINK_SPEC): Include CA53_ERR_843419_SPEC.
>> * config/aarch64/aarch64-linux.h (CA53_ERR_843419_SPEC): Define.
>> (LINK_SPEC): Include CA53_ERR_843419_SPEC.
>> * doc/install.texi (aarch64*-*-*): Document
>> new --enable-fix-cortex-a53-843419 option.


[PATCH] Mark help string in DEFPARAM as no-c-format

2015-05-01 Thread Andreas Schwab
Tested with make gcc.pot.

Andreas.

PR translation/65959
* params.h (DEFPARAM): Rename msgid to nocmsgid.
---
 gcc/params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/params.h b/gcc/params.h
index 28d077f..f53426d 100644
--- a/gcc/params.h
+++ b/gcc/params.h
@@ -81,7 +81,7 @@ extern void set_param_value (const char *name, int value,
 
 enum compiler_param
 {
-#define DEFPARAM(enumerator, option, msgid, default, min, max) \
+#define DEFPARAM(enumerator, option, nocmsgid, default, min, max) \
   enumerator,
 #include "params.def"
 #undef DEFPARAM
-- 
2.4.0

-- 
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][AArch64] Make aarch64_min_divisions_for_recip_mul configurable

2015-05-01 Thread Wilco Dijkstra


> Marcus Shawcroft wrote:
> On 27 April 2015 at 14:43, Wilco Dijkstra  wrote:
> 
> >>  static unsigned int
> >> -aarch64_min_divisions_for_recip_mul (enum machine_mode mode 
> >> ATTRIBUTE_UNUSED)
> >> +aarch64_min_divisions_for_recip_mul (enum machine_mode mode)
> >>  {
> >> -  return 2;
> >> +  if (GET_MODE_UNIT_SIZE (mode) == 4)
> >> +return aarch64_tune_params->min_div_recip_mul_sf;
> >> +  return aarch64_tune_params->min_div_recip_mul_df;
> 
> This should be expressed directly as mode == SFmode (or DFmode) rather
> than the indirect approach of first computing the size first.

Can we never see vector types at this point?

Wilco




Re: [PATCH, AArch64] Add Cortex-A53 erratum 843419 configure-time option

2015-05-01 Thread Marcus Shawcroft
On 1 May 2015 at 10:11, Yvan Roux  wrote:
> Hi all,
>
> As described in the thread bellow, there is a link-time workaround for
> an erratum (843419) of some early revision of Cortex-A53.  Similarly
> to what was done for a previous erratum, this patch adds a new
> configure-time option --enable-fix-cortex-a53-843419 that pass down
> the linker option --fix-cortex-a53-843419.
>
> I haven't implemented flags to explicitly disable/enable it during
> compilation as it is only a linker workaround, but I can do it if you
> think it's necessary.

Hi Yvan,

In the case of the 835769 erratum, providing such GCC configury made
(some) sense because the workaround included both a GCC and an LD
component. GCC in effect needed the option to control GCC behaviour
aswell as LD behaviour. The same is not true of 843419. The net effect
of the proposed  patch here is to provide a configure option in GCC to
change the default behaviour of LD, with no other purpose within GCC
itself.  This seems rather bizarre to me. I would have thought that if
the sole objective is to change the default behaviour of LD, then
there should be configure time options on LD, rather than GCC.

That said, I can also see that providing consistent behaviour across
these various work around configure options and consistent run time
options for the user will reduce confusion in the future, both for
folks building toolchains and for the folks using them.  From this
perspective I think it would be better to go with this patch *and*
include the flags explicitly such the both of the current workaround
have equivalent configury behaviour and have equivalent user flags at
run time.

Cheers
/Marcus

>
> https://sourceware.org/ml/binutils-cvs/2015-04/msg00012.html
>
> Is it ok for trunk and/or branches ?
>
> Thanks,
> Yvan
>
> 2015-05-01  Yvan Roux  
>
> * configure.ac: Add --enable-fix-cortex-a53-843419 option.
> * configure: Regenerate.
> * config/aarch64/aarch64-elf-raw.h (CA53_ERR_843419_SPEC): Define.
> (LINK_SPEC): Include CA53_ERR_843419_SPEC.
> * config/aarch64/aarch64-linux.h (CA53_ERR_843419_SPEC): Define.
> (LINK_SPEC): Include CA53_ERR_843419_SPEC.
> * doc/install.texi (aarch64*-*-*): Document
> new --enable-fix-cortex-a53-843419 option.


Re: [PATCH] [libstdc++] Add uniform container erasure.

2015-05-01 Thread Jonathan Wakely

On 01/05/15 07:01 -0400, Ed Smith-Rowland wrote:

On 04/30/2015 02:01 PM, Daniel Krügler wrote:
Shouldn't the "one-liner" forwarding function templates be declared 
as inline? - Daniel

You are right.

This builds and tests clean on x86_64-linux.

OK?


Yes OK, thanks.


[patch] Update libstdc++ status docs, add C++17 status

2015-05-01 Thread Jonathan Wakely

This updates the C++11 and C++14/TS status tables, and adds a new
table for C++17 features.

Committed to trunk.

commit c95071e70eaa69a47ae49c99c8ddb8d20c2e9085
Author: Jonathan Wakely 
Date:   Thu Apr 30 21:35:55 2015 +0100

	* doc/xml/manual/intro.xml: Link to new status_cxx2017.xml file.
	* doc/xml/manual/status_cxx2011.xml: Update status tables.
	* doc/xml/manual/status_cxx2014.xml: Likewise.
	* doc/xml/manual/status_cxx2017.xml: New.
	* doc/xml/manual/using.xml: Fix typo.
	* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/intro.xml b/libstdc++-v3/doc/xml/manual/intro.xml
index 2dd833d..b521089 100644
--- a/libstdc++-v3/doc/xml/manual/intro.xml
+++ b/libstdc++-v3/doc/xml/manual/intro.xml
@@ -33,11 +33,15 @@
 http://www.w3.org/2001/XInclude"; parse="xml" href="status_cxx2014.xml">
 
 
-
+
+http://www.w3.org/2001/XInclude"; parse="xml" href="status_cxx2017.xml">
+
+
+
 http://www.w3.org/2001/XInclude"; parse="xml" href="status_cxxtr1.xml">
 
 
-
+
 http://www.w3.org/2001/XInclude"; parse="xml" href="status_cxxtr24733.xml">
 
   
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index 965df13..2b99b9d 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
@@ -17,8 +17,8 @@ Final Draft International Standard, Standard for Programming Language C++
 
 
 
-In this implementation -std=gnu++11 or
--std=c++11 flags must be used to enable language
+In this implementation the -std=gnu++11 or
+-std=c++11 flag must be used to enable language
 and library
 features. See dialect
 options. The pre-defined symbol
@@ -529,10 +529,9 @@ particular release.
   
 
 
-  
   20.6.4
   Pointer safety
-  Partial
+  Y
   
 
 
@@ -642,10 +641,8 @@ particular release.
   Class template shared_ptr
   Y
   
-	
 	  Uses code from
 	  http://www.w3.org/1999/xlink"; xlink:href="http://www.boost.org/libs/smart_ptr/shared_ptr.htm";>boost::shared_ptr.
-	
   
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
index fc32995..d022ea4 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2014.xml
@@ -10,8 +10,8 @@
 
 
 
-In this implementation -std=gnu++1y or
--std=c++1y flags must be used to enable language
+In this implementation the -std=gnu++14 or
+-std=c++14 flag must be used to enable language
 and library
 features. See dialect
 options. The pre-defined symbol
@@ -196,7 +196,7 @@ not in any particular release.
   
   Shared Locking in C++
   Y
-  Need tests
+  
 
 
 
@@ -395,14 +395,13 @@ not in any particular release.
 
 
 
-  
   
-	http://www.w3.org/1999/xlink"; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3932.htm";>
-	  N3940
+	http://www.w3.org/1999/xlink"; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4100.pdf";>
+	  N4100
 	
   
   File System
-  WIP
+  Y
   
 
 
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
new file mode 100644
index 000..b08e1b1
--- /dev/null
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -0,0 +1,251 @@
+http://docbook.org/ns/docbook"; version="5.0" 
+	 xml:id="status.iso.201z" xreflabel="Status C++ 201z">
+
+
+C++ 201z
+  
+ISO C++
+201z
+  
+
+
+
+In this implementation the -std=gnu++1z or
+-std=c++1z flag must be used to enable language
+and library
+features. See dialect
+options. The pre-defined symbol
+__cplusplus is used to check for the
+presence of the required flag.
+
+
+
+This page describes the C++1z and library TS support in mainline GCC SVN,
+not in any particular release.
+
+
+
+C++ 201z Implementation Status
+
+
+
+
+
+
+  
+
+  Paper
+  Title
+  Status
+  Comments
+
+  
+
+  
+
+
+  
+	http://www.w3.org/1999/xlink"; xlink:href="http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2014/n4259.pdf";>
+	  N4259
+	
+  
+  Wording for std::uncaught_exceptions
+  Y
+  
+
+
+
+  
+  
+	http://www.w3.org/1999/xlink"; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4190.htm";>
+	  N4190
+	
+  
+  
+Removing auto_ptr, random_shuffle(),
+And Old  Stuff
+  
+  N
+  
+
+
+
+  
+	http://www.w3.org/1999/xlink"; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4284.htm";>
+	  N4284
+	
+  
+  Contiguous Iterators 
+  Y
+  No code changes required
+
+
+
+  
+  
+	http://www.w3.org/1999/xlink"; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4089.pdf";>
+	  N4089
+	
+  
+  Safe conversions in unique_ptr 
+  

[patch] Implement std::pointer_safety etc.

2015-05-01 Thread Jonathan Wakely

I forgot to add these (useless) functions that are required for full
C++11 conformance.

Tested powerpc64le-linux, committed to trunk.

I will probably backport these to 5.2 as well.
commit 95d0e38e22b85e6ffeea15678c6dce114c029be7
Author: Jonathan Wakely 
Date:   Tue Jan 20 12:14:11 2015 +

	* include/std/memory (pointer_safety, declare_reachable,
	undeclare_reachable, declare_no_pointers, undeclare_no_pointers,
	get_pointer_safety): Define.
	* testsuite/20_util/pointer_safety/1.cc: New.

diff --git a/libstdc++-v3/include/std/memory b/libstdc++-v3/include/std/memory
index 4257394..3ed53b8 100644
--- a/libstdc++-v3/include/std/memory
+++ b/libstdc++-v3/include/std/memory
@@ -126,6 +126,26 @@ align(size_t __align, size_t __size, void*& __ptr, size_t& __space) noexcept
 }
 }
 
+// 20.7.4 [util.dynamic.safety], pointer safety
+
+enum class pointer_safety { relaxed, preferred, strict };
+
+inline void
+declare_reachable(void*) { }
+
+template 
+  inline T*
+  undeclare_reachable(T* __p) { return __p; }
+
+inline void
+declare_no_pointers(char*, size_t) { }
+
+inline void
+undeclare_no_pointers(char*, size_t) { }
+
+inline pointer_safety
+get_pointer_safety() noexcept { return pointer_safety::relaxed; }
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
 #endif // _GLIBCXX_USE_C99_STDINT_TR1
diff --git a/libstdc++-v3/testsuite/20_util/pointer_safety/1.cc b/libstdc++-v3/testsuite/20_util/pointer_safety/1.cc
new file mode 100644
index 000..85793ff
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/pointer_safety/1.cc
@@ -0,0 +1,43 @@
+// Copyright (C) 2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++11" }
+
+#include 
+#include 
+
+void
+test01()
+{
+  char buf[8];
+
+  std::declare_reachable(buf);
+  char* p = std::undeclare_reachable(buf);
+  VERIFY( p == buf );
+
+  std::declare_no_pointers(p, sizeof(buf));
+  std::undeclare_no_pointers(p, sizeof(buf));
+
+  std::pointer_safety ps = std::get_pointer_safety();
+  VERIFY( ps == std::pointer_safety::relaxed );
+}
+
+int
+main()
+{
+  test01();
+}


Re: [PATCH] [libstdc++] Add uniform container erasure.

2015-05-01 Thread Ed Smith-Rowland

On 04/30/2015 02:01 PM, Daniel Krügler wrote:
Shouldn't the "one-liner" forwarding function templates be declared as 
inline? - Daniel 

You are right.

This builds and tests clean on x86_64-linux.

OK?

2015-05-01  Edward Smith-Rowland  <3dw...@verizon.net>

Inline one-line erasure dispatch functions.
* include/experimental/forward_list (erase_if(), erase()): Inline.
* include/experimental/list (erase_if(), erase()): Inline.
* include/experimental/map (erase_if(*)): Inline.
* include/experimental/set (erase_if(*)): Inline.
* include/experimental/string (erase_if(), erase()): Inline.
* include/experimental/unordered_map (erase_if(*)): Inline.
* include/experimental/unordered_set (erase_if(*)): Inline.
Index: include/experimental/forward_list
===
--- include/experimental/forward_list   (revision 222661)
+++ include/experimental/forward_list   (working copy)
@@ -46,12 +46,13 @@
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
-void 
+inline void 
 erase_if(forward_list<_Tp, _Alloc>& __cont, _Predicate __pred)
 { __cont.remove_if(__pred); }
 
   template
-void erase(forward_list<_Tp, _Alloc>& __cont, const _Up& __value)
+inline void
+erase(forward_list<_Tp, _Alloc>& __cont, const _Up& __value)
 {
   using __elem_type = typename forward_list<_Tp, _Alloc>::value_type;
   erase_if(__cont, [&](__elem_type& __elem) { return __elem == __value; });
Index: include/experimental/list
===
--- include/experimental/list   (revision 222661)
+++ include/experimental/list   (working copy)
@@ -46,12 +46,12 @@
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   template
-void
+inline void
 erase_if(list<_Tp, _Alloc>& __cont, _Predicate __pred)
 { __cont.remove_if(__pred); }
 
   template
-void
+inline void
 erase(list<_Tp, _Alloc>& __cont, const _Up& __value)
 {
   using __elem_type = typename list<_Tp, _Alloc>::value_type;
Index: include/experimental/map
===
--- include/experimental/map(revision 222661)
+++ include/experimental/map(working copy)
@@ -48,13 +48,13 @@
 
   template
-void
+inline void
 erase_if(map<_Key, _Tp, _Compare, _Alloc>& __cont, _Predicate __pred)
 { __detail::__erase_nodes_if(__cont, __pred); }
 
   template
-void
+inline void
 erase_if(multimap<_Key, _Tp, _Compare, _Alloc>& __cont, _Predicate __pred)
 { __detail::__erase_nodes_if(__cont, __pred); }
 
Index: include/experimental/set
===
--- include/experimental/set(revision 222661)
+++ include/experimental/set(working copy)
@@ -48,13 +48,13 @@
 
   template
-void
+inline void
 erase_if(set<_Key, _Compare, _Alloc>& __cont, _Predicate __pred)
 { __detail::__erase_nodes_if(__cont, __pred); }
 
   template
-void
+inline void
 erase_if(multiset<_Key, _Compare, _Alloc>& __cont, _Predicate __pred)
 { __detail::__erase_nodes_if(__cont, __pred); }
 
Index: include/experimental/string
===
--- include/experimental/string (revision 222661)
+++ include/experimental/string (working copy)
@@ -48,7 +48,7 @@
 
   template
-void
+inline void
 erase_if(basic_string<_CharT, _Traits, _Alloc>& __cont, _Predicate __pred)
 {
   __cont.erase(std::remove_if(__cont.begin(), __cont.end(), __pred),
@@ -56,7 +56,7 @@
 }
 
   template
-void
+inline void
 erase(basic_string<_CharT, _Traits, _Alloc>& __cont, const _Up& __value)
 {
   __cont.erase(std::remove(__cont.begin(), __cont.end(), __value),
Index: include/experimental/unordered_map
===
--- include/experimental/unordered_map  (revision 222661)
+++ include/experimental/unordered_map  (working copy)
@@ -48,7 +48,7 @@
 
   template
-void
+inline void
 erase_if(unordered_map<_Key, _Tp, _Hash, _CPred, _Alloc>& __cont,
 _Predicate __pred)
 { __detail::__erase_nodes_if(__cont, __pred); }
@@ -55,7 +55,7 @@
 
   template
-void
+inline void
 erase_if(unordered_multimap<_Key, _Tp, _Hash, _CPred, _Alloc>& __cont,
 _Predicate __pred)
 { __detail::__erase_nodes_if(__cont, __pred); }
Index: include/experimental/unordered_set
===
--- include/experimental/unordered_set  (revision 222661)
+++ include/experimental/unordered_set  (working copy)
@@ -48,7 +48,7 @@
 
   template
-void
+inline void
 erase_if(unordered_set<_Key, _Hash, _CPred, _Alloc>& __cont,
 _Predicate __pred)
 { __detail::__erase_nodes_if(__cont, __pred); }
@@ -55,7 +55,7 @@
 
   template
-void
+inline void
  

Re: [patch] Perform anonymous constant propagation during inlining

2015-05-01 Thread Eric Botcazou
> Hmm, special-casing this in the inliner looks odd to me.  ISTR the inliner
> already propagates constant parameters to immediate uses, so I guess
> you run into the casting case you handle specially.

Right on both counts, the original GIMPLE looks like:

  right.3 = (system__storage_elements__integer_address) right;
  D.4203 = D.4201 % right.3;
  D.4200 = (system__storage_elements__storage_offset) D.4203;
  return D.4200;

and setup_one_parameter has:

  /* If there is no setup required and we are in SSA, take the easy route
 replacing all SSA names representing the function parameter by the
 SSA name passed to function.

 We need to construct map for the variable anyway as it might be used
 in different SSA names when parameter is set in function.

 Do replacement at -O0 for const arguments replaced by constant.
 This is important for builtin_constant_p and other construct requiring
 constant argument to be visible in inlined function body.  */
  if (gimple_in_ssa_p (cfun) && rhs && def && is_gimple_reg (p)
  && (optimize
  || (TREE_READONLY (p)
  && is_gimple_min_invariant (rhs)))
  && (TREE_CODE (rhs) == SSA_NAME
  || is_gimple_min_invariant (rhs))
  && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (def))
{
  insert_decl_map (id, def, rhs);
  return insert_init_debug_bind (id, bb, var, rhs, NULL);
}

and here is the GIMPLE after inlining:

  _17 = _16;
  _18 = _17;
  right.3_19 = 8;
  _20 = _18 % right.3_19;
  _21 = (system__storage_elements__storage_offset) _20;

so the constant replacement is done for right.3_19 by the above block.

> But then if any constant propagation is ok at -O0 why not perform
> full-fledged constant propagation (with !DECL_IGNORED_P vars as a
> propagation barrier) as a regular SSA pass?  That is, if you'd had a
> Inline_Always function like
> 
> int foo (int i)
> {
>   return (i + 1) / i;
> }
> 
> you'd not get the desired result as the i + 1 stmt wouldn't be folded
> and thus the (i + 1) / i stmt wouldn't either.

That's OK, only the trivial cases need to be dealt with since it's -O0 so 
running a fully-fledged constant propagation seems overkill.

> That said - why does RTL optimization not save you here anyway?
> After all, it is responsible for turning divisions into shifts.

You mean the RTL expander?  Because the SSA name isn't replaced with the RHS 
of its defining statement in:

  /* For EXPAND_INITIALIZER try harder to get something simpler.  */
  if (g == NULL
  && modifier == EXPAND_INITIALIZER
  && !SSA_NAME_IS_DEFAULT_DEF (exp)
  && (optimize || DECL_IGNORED_P (SSA_NAME_VAR (exp)))
  && stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
g = SSA_NAME_DEF_STMT (exp);

since modifier is EXPAND_NORMAL.  Do you think it would be OK to be a little 
more aggressive here?  Something like:

  /* If we aren't on the LHS, look into the defining statement.  */
  if (g == NULL
  && modifier != EXPAND_WRITE
  && !SSA_NAME_IS_DEFAULT_DEF (exp)
  && (optimize || DECL_IGNORED_P (SSA_NAME_VAR (exp)))
  && stmt_is_replaceable_p (SSA_NAME_DEF_STMT (exp)))
 {
g = SSA_NAME_DEF_STMT (exp);
/* For EXPAND_INITIALIZER substitute in all cases, otherwise do
   it only for constants.  */
if (modifier != EXPAND_INITIALIZER
&& (!gimple_assign_copy_p (g)
|| !is_gimple_min_invariant (gimple_assign_rhs1 (g
  g = NULL;
 }

That's certainly sufficient here.

-- 
Eric Botcazou


Re: [PATCH][AArch64] Fix aarch64_rtx_costs of PLUS/MINUS

2015-05-01 Thread Marcus Shawcroft
On 4 March 2015 at 15:37, Wilco Dijkstra  wrote:
> Include the cost of op0 and op1 in all cases in PLUS and MINUS in 
> aarch64_rtx_costs.
> Bootstrap & regression OK.
>
> ChangeLog:
> 2015-03-04  Wilco Dijkstra  
>
> * gcc/config/aarch64/aarch64.c (aarch64_rtx_costs):
> Calculate cost of op0 and op1 in PLUS and MINUS cases.

OK, we take this one instead of Kyrill's. /Marcus


Re: [PATCH][AARCH64]Use mov for add with large immediate.

2015-05-01 Thread Marcus Shawcroft
On 21 April 2015 at 17:10, Renlin Li  wrote:
> Hi all,
>
> This is a simple patch to generate a move instruction to temporarily hold
> the large immediate for a add instruction.
>
> GCC regression test has been run using aarch64-none-elf toolchain. NO new
> issues.
>
> Okay for trunk?
>
> Regards,
> Renlin Li
>
> gcc/ChangeLog:
>
> 2015-04-21  Renlin Li  
>
> * config/aarch64/aarch64.md (add3): Use mov when allowed.

A couple style nits:

   HOST_WIDE_INT imm = INTVAL (operands[2]);
-
-  if (imm < 0)

Don't remove the blank line between declarations and the first statement.

+  if (aarch64_move_imm (imm, mode)
+  && can_create_pseudo_p ())
+  {

The indentation of { should conform to the gnu style guide.

It also  looks to me that  an unbroken line will fit within the 80
column limit, hence the break before && is unnecessary.

Cheers
/Marcus


Re: [libstdc++ PATCH] Implement __is_nothrow_swappable and use it

2015-05-01 Thread Ville Voutilainen
On 1 May 2015 at 12:47, Ville Voutilainen  wrote:
> This patch partially solves the problem described in N4426, which is
> basically LWG
> issue 2456, which in turn is caused by CWG DR 1330. Some remarks:

..and I forgot to mention that it fixes PR 63860.


[libstdc++ PATCH] Implement __is_nothrow_swappable and use it

2015-05-01 Thread Ville Voutilainen
This patch partially solves the problem described in N4426, which is
basically LWG
issue 2456, which in turn is caused by CWG DR 1330. Some remarks:
- the __is_swappable and __is_nothrow_swappable are at this time not
meant to be general traits, they make the shortcut of automatically transforming
their template parameter into a reference, which the truly general trait
as described in N4426 wouldn't do.
- swap is now constrained..
- ..which means that everything from bits/move.h moves to type_traits since
swap now needs type_traits. type_traits becomes ok to include in pre-c++14
modes, but only enables the parts that work in pre-c++14 modes.
- this patch does _not_ yet implement N4426.

Tested on Linux-x64.

2015-05-01  Ville Voutilainen  
Add __is_nothrow_swappable and take it into use.
* libstdc++-v3/include/bits/algorithmfwd.h: Add constraints to the
forward-declaration of swap.
* include/bits/move.h: Move everything in it to..
* include/type_traits: ..here.
* include/type_traits (__swappable_impl::__swappable,
__is_nothrow_swappable_impl, __is_nothrow_swappable): New.
* include/bits/stl_pair.h (swap): Use __is_nothrow_swappable
for the free swap function for pair.
* include/bits/stl_queue.h (swap): Use __is_nothrow_swappable
for the free swap functions for queue and priority_queue.
* include/bits/stl_stack.h (swap): Use __is_nothrow_swappable
for the free swap function for stack.
* include/debug/array (swap): Use __is_nothrow_swappable
for the free swap function for array.
* include/profile/array (swap): Likewise.
* include/std/array (swap): Likewise.
* include/std/tuple (_M_swap): Use __is_nothrow_swappable.
* testsuite/20_util/forward/c_neg.cc: Adjust.
* testsuite/20_util/forward/f_neg.cc: Likewise.
* testsuite/20_util/headers/type_traits/std_c++0x_neg.cc: Remove.
* 
testsuite/20_util/is_nothrow_swappable/requirements/explicit_instantiation.cc:
New.
* testsuite/20_util/is_nothrow_swappable/requirements/typedefs.cc: Likewise.
* testsuite/20_util/is_nothrow_swappable/value.cc: Likewise.
diff --git a/libstdc++-v3/include/bits/algorithmfwd.h 
b/libstdc++-v3/include/bits/algorithmfwd.h
index 1dfc4ad..0e37307 100644
--- a/libstdc++-v3/include/bits/algorithmfwd.h
+++ b/libstdc++-v3/include/bits/algorithmfwd.h
@@ -567,7 +567,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 stable_partition(_BIter, _BIter, _Predicate);
 
   template 
-void 
+#if __cplusplus >= 201103L
+typename enable_if<__and_,
+   is_move_assignable<_Tp>>::value>::type
+#else
+void
+#endif
 swap(_Tp&, _Tp&)
 #if __cplusplus >= 201103L
 noexcept(__and_,
@@ -576,7 +581,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 ;
 
   template
+#if __cplusplus >= 201103L
+typename enable_if<__and_,
+   is_move_assignable<_Tp>>::value>::type
+#else
 void
+#endif
 swap(_Tp (&__a)[_Nm], _Tp (&__b)[_Nm])
 #if __cplusplus >= 201103L
 noexcept(noexcept(swap(*__a, *__b)))
diff --git a/libstdc++-v3/include/bits/move.h b/libstdc++-v3/include/bits/move.h
index 1dfd667..96e2e51 100644
--- a/libstdc++-v3/include/bits/move.h
+++ b/libstdc++-v3/include/bits/move.h
@@ -30,179 +30,7 @@
 #ifndef _MOVE_H
 #define _MOVE_H 1
 
-#include 
-#include 
-
-namespace std _GLIBCXX_VISIBILITY(default)
-{
-_GLIBCXX_BEGIN_NAMESPACE_VERSION
-
-  // Used, in C++03 mode too, by allocators, etc.
-  /**
-   *  @brief Same as C++11 std::addressof
-   *  @ingroup utilities
-   */
-  template
-inline _Tp*
-__addressof(_Tp& __r) _GLIBCXX_NOEXCEPT
-{
-  return reinterpret_cast<_Tp*>
-   (&const_cast(reinterpret_cast(__r)));
-}
-
-_GLIBCXX_END_NAMESPACE_VERSION
-} // namespace
-
-#if __cplusplus >= 201103L
 #include  // Brings in std::declval too.
 
-namespace std _GLIBCXX_VISIBILITY(default)
-{
-_GLIBCXX_BEGIN_NAMESPACE_VERSION
-
-  /**
-   *  @addtogroup utilities
-   *  @{
-   */
-
-  /**
-   *  @brief  Forward an lvalue.
-   *  @return The parameter cast to the specified type.
-   *
-   *  This function is used to implement "perfect forwarding".
-   */
-  template
-constexpr _Tp&&
-forward(typename std::remove_reference<_Tp>::type& __t) noexcept
-{ return static_cast<_Tp&&>(__t); }
-
-  /**
-   *  @brief  Forward an rvalue.
-   *  @return The parameter cast to the specified type.
-   *
-   *  This function is used to implement "perfect forwarding".
-   */
-  template
-constexpr _Tp&&
-forward(typename std::remove_reference<_Tp>::type&& __t) noexcept
-{
-  static_assert(!std::is_lvalue_reference<_Tp>::value, "template argument"
-   " substituting _Tp is an lvalue reference type");
-  return static_cast<_Tp&&>(__t);
-}
-
-  /**
-   *  @brief  Convert a value to an rvalue.
-   *  @param  __t  A thing of arbitrary type.
-   *  @return The parameter cast to an rvalue-reference to allow moving it.
-  */
-  template
-constexpr typename std::remove_reference<_Tp>::typ

[PATCH] Fix OpenACC shutdown and PTX image unloading (PR65904)

2015-05-01 Thread Julian Brown
Hi,

This patch fixes PR65904, a double-free error that started occurring
after recent libgomp changes to the way offload images are registered
with the runtime.

Offload images now map all functions/data using just two malloc'ed
blocks, but the function gomp_free_memmap did not take that into
account, and treated all mappings as if they had their own blocks (as
they do if created by gomp_map_vars): so attempting to free the whole
map at once failed when it hit mappings for an offload image.

The fix is to split offload-image freeing out of GOMP_offload_unregister
into a separate function, and call that from gomp_free_memmap for the
given device before freeing the rest of the memory map.

The patch also fixes a thinko that was revealed in image unloading in
the NVPTX backend. Tested for libgomp with PTX offloading.

OK for trunk?

Thanks,

Julian

ChangeLog

libgomp/
* libgomp.h (gomp_free_memmap): Update prototype.
* oacc-init.c (acc_shutdown_1): Pass device descriptor to
gomp_free_memmap. Don't lock device around call.
* target.c (gomp_map_vars): Initialise tgt->array to NULL before
early exit.
(GOMP_offload_unregister): Split out and call...
(gomp_deoffload_image_from_device): This new function.
(gomp_free_memmap): Call gomp_deoffload_image_from_device.

* plugin/nvptx.c (struct ptx_image_data): Add ord, fn_descs fields.
(GOMP_OFFLOAD_load_image): Populate above fields.
(GOMP_OFFLOAD_unload_image): Switch to ORD'th device before freeing
images, and use fn_descs field from ptx_image_data instead of
incorrectly using a pointer derived from target_data.
 commit 14e8e35a494a5a8231ab1a3cad38a2157bca7e4a
Author: Julian Brown 
Date:   Thu Apr 30 10:19:58 2015 -0700

Fix freeing of memory maps during acc shutdown.

diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
index 5272f01..5e0e09c 100644
--- a/libgomp/libgomp.h
+++ b/libgomp/libgomp.h
@@ -777,7 +777,7 @@ extern struct target_mem_desc *gomp_map_vars (struct gomp_device_descr *,
 extern void gomp_copy_from_async (struct target_mem_desc *);
 extern void gomp_unmap_vars (struct target_mem_desc *, bool);
 extern void gomp_init_device (struct gomp_device_descr *);
-extern void gomp_free_memmap (struct splay_tree_s *);
+extern void gomp_free_memmap (struct gomp_device_descr *);
 extern void gomp_fini_device (struct gomp_device_descr *);
 
 /* work.c */
diff --git a/libgomp/oacc-init.c b/libgomp/oacc-init.c
index 503f8b8..f2c60ec 100644
--- a/libgomp/oacc-init.c
+++ b/libgomp/oacc-init.c
@@ -245,9 +245,7 @@ acc_shutdown_1 (acc_device_t d)
 
   if (walk->dev)
 	{
-	  gomp_mutex_lock (&walk->dev->lock);
-	  gomp_free_memmap (&walk->dev->mem_map);
-	  gomp_mutex_unlock (&walk->dev->lock);
+	  gomp_free_memmap (walk->dev);
 
 	  walk->dev = NULL;
 	  walk->base_dev = NULL;
diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index 583ec87..2cc0ae0 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -334,8 +334,10 @@ struct ptx_event
 
 struct ptx_image_data
 {
+  int ord;
   void *target_data;
   CUmodule module;
+  struct targ_fn_descriptor *fn_descs;
   struct ptx_image_data *next;
 };
 
@@ -1625,13 +1627,6 @@ GOMP_OFFLOAD_load_image (int ord, void *target_data,
 
   link_ptx (&module, img_header[0]);
 
-  pthread_mutex_lock (&ptx_image_lock);
-  new_image = GOMP_PLUGIN_malloc (sizeof (struct ptx_image_data));
-  new_image->target_data = target_data;
-  new_image->module = module;
-  new_image->next = ptx_images;
-  ptx_images = new_image;
-  pthread_mutex_unlock (&ptx_image_lock);
 
   /* The mkoffload utility emits a table of pointers/integers at the start of
  each offload image:
@@ -1652,8 +1647,21 @@ GOMP_OFFLOAD_load_image (int ord, void *target_data,
 
   *target_table = GOMP_PLUGIN_malloc (sizeof (struct addr_pair)
   * (fn_entries + var_entries));
-  targ_fns = GOMP_PLUGIN_malloc (sizeof (struct targ_fn_descriptor)
- * fn_entries);
+  if (fn_entries > 0)
+targ_fns = GOMP_PLUGIN_malloc (sizeof (struct targ_fn_descriptor)
+   * fn_entries);
+  else
+targ_fns = NULL;
+
+  pthread_mutex_lock (&ptx_image_lock);
+  new_image = GOMP_PLUGIN_malloc (sizeof (struct ptx_image_data));
+  new_image->ord = ord;
+  new_image->target_data = target_data;
+  new_image->module = module;
+  new_image->fn_descs = targ_fns;
+  new_image->next = ptx_images;
+  ptx_images = new_image;
+  pthread_mutex_unlock (&ptx_image_lock);
 
   for (i = 0; i < fn_entries; i++)
 {
@@ -1687,23 +1695,22 @@ GOMP_OFFLOAD_load_image (int ord, void *target_data,
 }
 
 void
-GOMP_OFFLOAD_unload_image (int tid __attribute__((unused)), void *target_data)
+GOMP_OFFLOAD_unload_image (int ord, void *target_data)
 {
-  void **img_header = (void **) target_data;
-  struct targ_fn_descriptor *targ_fns
-= (struct targ_fn_descriptor *) img_header[0];
   struct ptx_image_data *image, *prev = NULL, *newhd = NULL;
 
-  free (targ_fns);
+  nvptx_attach_host_th

Re: [PATCH] [AArch32] Additional bics patterns.

2015-05-01 Thread Kyrill Tkachov


On 24/04/15 16:41, Alex Velenko wrote:

Hi,

This patch adds rtl patterns to generate bics instructions with shift.

Added attribute predicable_short_it since last respin.

Done full regression run on arm-none-eabi and arm-none-gnueabihf.
Bootstrapped on arm-none-gnueabihf.

Is this patch ok?

gcc/config

2015-04-24  Alex Velenko  

* arm/arm.md (andsi_not_shiftsi_si_scc): New pattern.
* (andsi_not_shiftsi_si_scc_no_reuse): New pattern.


As mentioned before, the ChangeLog entry for arm.md should
have the correct path:
* config/arm/arm.md (andsi_not_shiftsi_si_scc): New pattern.
(andsi_not_shiftsi_si_scc_no_reuse): Likewise.

Can you please confirm that bootstraps with both arm and thumb pass?
That is, configured with --with-mode=arm and --with-mode=thumb

If no problems there, then ok with the fixed ChangeLog entry.

Thanks,
Kyrill



gcc/testsuite

2015-04-24  Alex Velenko 

* gcc.target/arm/bics_1.c : New testcase.
* gcc.target/arm/bics_2.c : New testcase.
* gcc.target/arm/bics_3.c : New testcase.
* gcc.target/arm/bics_4.c : New testcase.
---
   gcc/config/arm/arm.md | 44 +++
   gcc/testsuite/gcc.target/arm/bics_1.c | 54
+
   gcc/testsuite/gcc.target/arm/bics_2.c | 57
+++
   gcc/testsuite/gcc.target/arm/bics_3.c | 41 +
   gcc/testsuite/gcc.target/arm/bics_4.c | 49 ++
   5 files changed, 245 insertions(+)
   create mode 100644 gcc/testsuite/gcc.target/arm/bics_1.c
   create mode 100644 gcc/testsuite/gcc.target/arm/bics_2.c
   create mode 100644 gcc/testsuite/gcc.target/arm/bics_3.c
   create mode 100644 gcc/testsuite/gcc.target/arm/bics_4.c

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 164ac13..9e774c1 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -2768,6 +2768,50 @@
  (const_string "logic_shift_reg")))]
   )

+(define_insn "andsi_not_shiftsi_si_scc_no_reuse"
+  [(set (reg:CC_NOOV CC_REGNUM)
+   (compare:CC_NOOV
+   (and:SI (not:SI (match_operator:SI 0 "shift_operator"
+   [(match_operand:SI 1 "s_register_operand" "r")
+(match_operand:SI 2 "arm_rhs_operand" "rM")]))
+   (match_operand:SI 3 "s_register_operand" "r"))
+   (const_int 0)))
+   (clobber (match_scratch:SI 4 "=r"))]
+  "TARGET_32BIT"
+  "bic%.%?\\t%4, %3, %1%S0"
+  [(set_attr "predicable" "yes")
+   (set_attr "predicable_short_it" "no")
+   (set_attr "conds" "set")
+   (set_attr "shift" "1")
+   (set (attr "type") (if_then_else (match_operand 2
"const_int_operand" "")
+ (const_string "logic_shift_imm")
+ (const_string "logic_shift_reg")))]
+)
+
+(define_insn "andsi_not_shiftsi_si_scc"
+  [(parallel [(set (reg:CC_NOOV CC_REGNUM)
+   (compare:CC_NOOV
+   (and:SI (not:SI (match_operator:SI 0 "shift_operator"
+   [(match_operand:SI 1 "s_register_operand" "r")
+(match_operand:SI 2 "arm_rhs_operand" "rM")]))
+   (match_operand:SI 3 "s_register_operand" "r"))
+   (const_int 0)))
+   (set (match_operand:SI 4 "s_register_operand" "=r")
+(and:SI (not:SI (match_op_dup 0
+[(match_dup 1)
+ (match_dup 2)]))
+(match_dup 3)))])]
+  "TARGET_32BIT"
+  "bic%.%?\\t%4, %3, %1%S0"
+  [(set_attr "predicable" "yes")
+   (set_attr "predicable_short_it" "no")
+   (set_attr "conds" "set")
+   (set_attr "shift" "1")
+   (set (attr "type") (if_then_else (match_operand 2
"const_int_operand" "")
+ (const_string "logic_shift_imm")
+ (const_string "logic_shift_reg")))]
+)
+
   (define_insn "*andsi_notsi_si_compare0"
 [(set (reg:CC_NOOV CC_REGNUM)
(compare:CC_NOOV
diff --git a/gcc/testsuite/gcc.target/arm/bics_1.c
b/gcc/testsuite/gcc.target/arm/bics_1.c
new file mode 100644
index 000..173eb89
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/bics_1.c
@@ -0,0 +1,54 @@
+/* { dg-do run } */
+/* { dg-options "-O2 --save-temps -fno-inline" } */
+/* { dg-require-effective-target arm32 } */
+
+extern void abort (void);
+
+int
+bics_si_test1 (int a, int b, int c)
+{
+  int d = a & ~b;
+
+  /* { dg-final { scan-assembler-times "bics\tr\[0-9\]+, r\[0-9\]+,
r\[0-9\]+" 2 } } */
+  if (d == 0)
+return a + c;
+  else
+return b + d + c;
+}
+
+int
+bics_si_test2 (int a, int b, int c)
+{
+  int d = a & ~(b << 3);
+
+  /* { dg-final { scan-assembler-times "bics\tr\[0-9\]+, r\[0-9\]+,
r\[0-9\]+, .sl \#3" 1 } } */
+  if (d == 0)
+return a + c;
+  else
+return b + d + c;
+}
+
+int
+main ()
+{
+  int x;
+
+  x = bics_si_test1 (29, ~4, 5);
+  if (x != ((29 & 4) + ~4 + 5))
+abort ();
+
+  x = bics_si_test1 (5, ~2, 20);
+  if (x != 25)
+abort ();
+
+x = bics_si_test2 (35, ~4, 5);
+

  1   2   >