Re: [PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

2015-12-12 Thread Steve Kargl 
On Sat, Dec 12, 2015 at 08:14:39PM -0800, Jerry DeLisle wrote:
>  case 16:
> +  /* Adjust decimal precision depending on binary precision, 103 or 113. 
>  */


s/103/106

I suspect that this is simply a bandaid on a much bigger
problem.  Namely, few of the intrinsic functions for 
REAL(16) expect 106 bits instead of 113 bits.

-- 
Steve

[PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

2015-12-12 Thread Jerry DeLisle 
Hi all,

This PR is about different binary precision of quad floats on different 
platforms.

X86 uses libquadmath with 113 bits, PowerPC uses IBM 106 bits.

For list directed output we set the default decimal precision to use.  Because
the PowerPC has fewer significant bits, we need to adjust the formatting for
kind=16 accordingly or we are just getting junk in the last few digits emitted
(consistent junk).  This patch reduces the width and precision via conditional
compilation depending on the bit precision.

Regression tested on X86_64 and PowerPC (Power7) Linux.  The patch includes the
necessary updates of the testsuite quad_2.f90.

OK for trunk?

Regards,

Jerry

2015-12-12  Jerry DeLisle  

PR libfortran/pr68867
* io/write.c (set_fnode_default): For kind=16, set the decimal precision
depending on the platform binary precision, 106 or 113.


Index: gcc/testsuite/gfortran.dg/quad_2.f90
===
--- gcc/testsuite/gfortran.dg/quad_2.f90	(revision 231314)
+++ gcc/testsuite/gfortran.dg/quad_2.f90	(working copy)
@@ -49,18 +49,19 @@ program test_qp
if (str4 /= "1.41421356237309504876") call abort()
 
  case (16)
-   if (str1 /= "   1.000") call abort()
-   if (str2 /= "1.000") call abort()
-
if (digits(1.0_qp) == 113) then
  ! IEEE 754 binary 128 format
  ! e.g. libquadmath/__float128 on i686/x86_64/ia64
+ if (str1 /= "   1.000") call abort()
+ if (str2 /= "1.000") call abort()
  if (str3 /= "   1.41421356237309504880168872420969798") call abort()
  if (str4 /= "1.41421356237309504880168872420969798") call abort()
else if (digits(1.0_qp) == 106) then
  ! IBM binary 128 format
- if (str3(1:37) /= "   1.41421356237309504880168872420969") call abort()
- if (str4(1:34) /= "1.41421356237309504880168872420969") call abort()
+ if (str1 /= "   1.000") call abort()
+ if (str2 /= "1.000") call abort()
+ if (str3(1:37) /= "   1.4142135623730950488016887242097") call abort()
+ if (str4(1:34) /= "1.4142135623730950488016887242097") call abort()
end if
 
! Do a libm run-time test
Index: libgfortran/io/write.c
===
--- libgfortran/io/write.c	(revision 231314)
+++ libgfortran/io/write.c	(working copy)
@@ -1405,9 +1405,16 @@ set_fnode_default (st_parameter_dt *dtp, fnode *f,
   f->u.real.e = 4;
   break;
 case 16:
+  /* Adjust decimal precision depending on binary precision, 103 or 113.  */
+#if GFC_REAL_16_DIGITS == 113
   f->u.real.w = 45;
   f->u.real.d = 36;
   f->u.real.e = 4;
+#else
+  f->u.real.w = 41;
+  f->u.real.d = 32;
+  f->u.real.e = 4;
+#endif
   break;
 default:
   internal_error (>common, "bad real kind");

[PATCH] g++.dg/cpp1y/pr58708.C testcase fix for AIX

2015-12-12 Thread David Edelsohn 
I previously updated the assignment to correct the compile-time error,
but the runtime check of values also needs to be updated for 16 bit
wchar_t.

Tested on powerpc-ibm-aix7.1.0.0.

Committed.

Thanks, David

* g++.dg/cpp17/pr58708.C: Test appropriate value for size of wchar_t.

Index: pr58708.C
===
--- pr58708.C   (revision 231582)
+++ pr58708.C   (working copy)
@@ -50,8 +50,13 @@
 #endif
   if (is_same::value != true)
__builtin_abort();
   if (sizeof(wfoo.chars)/sizeof(wchar_t) != 2) __builtin_abort();
+#if __SIZEOF_WCHAR_T__ == 2
+  if (wfoo.chars[0] != 258) __builtin_abort();
+  if (wfoo.chars[1] != 772) __builtin_abort();
+#else
   if (wfoo.chars[0] != 16909060) __builtin_abort();
   if (wfoo.chars[1] != 84281096) __builtin_abort();
+#endif

   auto foou = u"\x0102\x0304\x0506\x0708"_foo;
   if (is_same::value != true)
__builtin_abort();

RE: [Patch, MIPS] Remove definition of TARGET_PROMOTE_PROTOTYPES

2015-12-12 Thread Matthew Fortune 
Steve Ellcey  writes:
> On Tue, 2015-11-10 at 15:57 -0800, Steve Ellcey wrote:
> > 2015-11-10  Steve Ellcey  
> >
> > * config/mips/mips.c (mips_promote_function_mode): New function.
> > (TARGET_PROMOTE_FUNCTION_MODE): Define as above function.
> > (TARGET_PROMOTE_PROTOTYPES): Remove.

I'm OK with this change on the basis that MIPS has been providing stronger
guarantees than required by the various standards. I.e. after this change
MIPS will have undefined behaviour for a mismatch in types between a
call to an un-prototyped function and its definition:

extern void foo();

void caller(int a)
{
  foo(a);
}

--

void foo(short a)
{
  // the value of 'a' can be out of range of a short because the caller
  // did not get the right type for the argument.
}

Thanks,
Matthew

Re: [PATCH][ARC] Refurbish emitting DWARF2 for epilogue.

2015-12-12 Thread Joern Wolfgang Rennecke 



On 11/12/15 10:29, Claudiu Zissulescu wrote:

I did some testing here. For size, I used CSiBE testbench, and for speed, I 
used coremark and dhrystone. Using a blockage or not, doesn't affect the size 
or speed figures. However, using TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P hook 
betters the size figures (not much, just .1%), and improves the coremark by 2% 
and Dhrystone by 1%.

Hence, in the light of the new figures, I favor the above two patch solution. 
Both patches are checked using dg.exp and compile.exp. Ok to submit?

Both patches are OK.

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

2015-12-12 Thread H.J. Lu 
On Sat, Dec 12, 2015 at 7:27 AM, Jakub Jelinek  wrote:
> On Sat, Dec 12, 2015 at 09:51:23AM -0500, Jason Merrill wrote:
>> On 12/11/2015 06:52 PM, H.J. Lu wrote:
>> >On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
>> > wrote:
>> >>On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
>> >> wrote:
>> >>>On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:
>> 
>> Empty C++ class is a corner case which isn't covered in psABI nor C++ 
>> ABI.
>> There is no mention of "empty record" in GCC documentation.  But there 
>> are
>> plenty of "empty class" in gcc/cp.  This change affects all targets.  
>> C++ ABI
>> should specify how it should be passed.
>> >>>
>> >>>There is a C++ ABI mailinglist, where you could discuss this issue:
>> >>>http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>> >>
>> >>Yep.  As long as the ABI doesn't state how to pass those I'd rather _not_ 
>> >>change
>> >>GCCs way.
>> >
>> >It is agreed that GCC is wrong on this:
>> >
>> >http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html
>>
>> Yes, I think this is just a (nasty) bug on some GCC targets.
>
> Well, the argument in that thread is weird, because C and C++ empty structs
> are different, so it isn't surprising they are passed differently.
> C++ makes those sizeof == 1, while C has them sizeof == 0.
> So I rather think clang should change rather than GCC.
>

But according to x86-64 psABI,  sizeof == 1 should be passed in register,
not on stack.  This leads to weird GCC bugs like:

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


-- 
H.J.

Re: update_vtable_references segfault

2015-12-12 Thread Nathan Sidwell 

On 12/11/15 13:15, Jan Hubicka wrote:

Jan,



b) augment can_replace_by_local_alias_in_vtable to check whether
aliases can be created?


I think this is best: can_replace_by_local_alias_in_vtable exists to prevent the
body walk in cases we are not going to create the alias.  This is because in LTO
we may need to stream in the constructor from the object file that is not 
copletely
free and thus it is better to not touch it unless necessary.


I went with augmenting can_replace_by_local_alias, which 
can_replace_by_local_alias_in_vtable calls.  I also noticed that both should be 
static, which  I suspect will encourage the inliner to go inline them and then 
determine a bunch of code is unreachable.


tested on x86-linux and ptx-none.

ok?

nathan
2015-12-12  Nathan Sidwell  

	* ipa-visibility.c (can_replace_by_local_alias): Make static,
	check ASM_OUTPUT_DEF.
	(can_replace_by_local_alias_in_vtable): Make static.
	(function_and_variable_visibility): Reformat overlong comment.

Index: ipa-visibility.c
===
--- ipa-visibility.c	(revision 231571)
+++ ipa-visibility.c	(working copy)
@@ -329,9 +329,13 @@ varpool_node::externally_visible_p (void
Local aliases save dynamic linking overhead and enable more optimizations.
  */
 
-bool
+static bool
 can_replace_by_local_alias (symtab_node *node)
 {
+#ifndef ASM_OUTPUT_DEF
+  /* If aliases aren't supported, we can't do replacement.  */
+  return false;
+#endif
   /* Weakrefs have a reason to be non-local.  Be sure we do not replace
  them.  */
   while (node->transparent_alias && node->definition && !node->weakref)
@@ -344,11 +348,11 @@ can_replace_by_local_alias (symtab_node
 	  && !node->can_be_discarded_p ());
 }
 
-/* Return true if we can replace refernece to NODE by local alias
+/* Return true if we can replace reference to NODE by local alias
within a virtual table.  Generally we can replace function pointers
and virtual table pointers.  */
 
-bool
+static bool
 can_replace_by_local_alias_in_vtable (symtab_node *node)
 {
   if (is_a  (node)
@@ -592,10 +596,11 @@ function_and_variable_visibility (bool w
   if (!node->local.local)
 node->local.local |= node->local_p ();
 
-  /* If we know that function can not be overwritten by a different semantics
-	 and moreover its section can not be discarded, replace all direct calls
-	 by calls to an noninterposable alias.  This make dynamic linking
-	 cheaper and enable more optimization.
+  /* If we know that function can not be overwritten by a
+	 different semantics and moreover its section can not be
+	 discarded, replace all direct calls by calls to an
+	 noninterposable alias.  This make dynamic linking cheaper and
+	 enable more optimization.
 
 	 TODO: We can also update virtual tables.  */
   if (node->callers

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

2015-12-12 Thread Jakub Jelinek 
On Sat, Dec 12, 2015 at 09:51:23AM -0500, Jason Merrill wrote:
> On 12/11/2015 06:52 PM, H.J. Lu wrote:
> >On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
> > wrote:
> >>On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
> >> wrote:
> >>>On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:
> 
> Empty C++ class is a corner case which isn't covered in psABI nor C++ ABI.
> There is no mention of "empty record" in GCC documentation.  But there are
> plenty of "empty class" in gcc/cp.  This change affects all targets.  C++ 
> ABI
> should specify how it should be passed.
> >>>
> >>>There is a C++ ABI mailinglist, where you could discuss this issue:
> >>>http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
> >>
> >>Yep.  As long as the ABI doesn't state how to pass those I'd rather _not_ 
> >>change
> >>GCCs way.
> >
> >It is agreed that GCC is wrong on this:
> >
> >http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html
> 
> Yes, I think this is just a (nasty) bug on some GCC targets.

Well, the argument in that thread is weird, because C and C++ empty structs
are different, so it isn't surprising they are passed differently.
C++ makes those sizeof == 1, while C has them sizeof == 0.
So I rather think clang should change rather than GCC.

Jakub

Re: [PATCH 6/6] [DJGPP] configure.ac: enable LTO

2015-12-12 Thread Andris Pavenis 

On 12/11/2015 12:32 AM, Jeff Law wrote:

On 12/05/2015 10:25 AM, Andris Pavenis wrote:

Patch enables LTO support for DJGPP in top level configure.ac

Andris

2015-12-05 Andris Pavenis 

* configure.ac: enable LTO for *-*-msdosdjgpp
OK once prereqs have gone in.  Note you should to the autoconf dance to update the generated 
files.  Mention them in your ChangeLog as

* configure: Regenerated

jeff



Updated patch is in attachment.

Andris

PS. Somebody other should apply this and my other DJGPP related patches as I do not have SVN write 
access.


2015-12-05 Andris Pavenis 

* configure.ac: Enable LTO for *-*-msdosdjgpp.
* configure: Regenerate.

>From d001fa0866e6bf1f4b879329841f7674f0e90eab Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Sat, 12 Dec 2015 10:15:42 +0200
Subject: [PATCH 6/6] [DJGPP] configure.ac: enable LTO

---
 configure| 4 ++--
 configure.ac | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 090615f..0cde5a2 100755
--- a/configure
+++ b/configure
@@ -6122,7 +6122,7 @@ if test $target_elf = yes; then :
 else
   if test x"$default_enable_lto" = x"yes" ; then
 case $target in
-  *-apple-darwin9* | *-cygwin* | *-mingw*) ;;
+  *-apple-darwin9* | *-cygwin* | *-mingw* | *djgpp*) ;;
   # On other non-ELF platforms, LTO has yet to be validated.
   *) enable_lto=no ;;
 esac
@@ -6133,7 +6133,7 @@ else
   # warn during gcc/ subconfigure; unless you're bootstrapping with
   # -flto it won't be needed until after installation anyway.
 case $target in
-  *-cygwin* | *-mingw* | *-apple-darwin*) ;;
+  *-cygwin* | *-mingw* | *-apple-darwin* | *djgpp*) ;;
   *) if test x"$enable_lto" = x"yes"; then
 	as_fn_error "LTO support is not enabled for this target." "$LINENO" 5
 fi
diff --git a/configure.ac b/configure.ac
index a6998ff..ee4fd23 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1817,7 +1817,7 @@ ACX_ELF_TARGET_IFELSE([# ELF platforms build the lto-plugin always.
   build_lto_plugin=yes
 ],[if test x"$default_enable_lto" = x"yes" ; then
 case $target in
-  *-apple-darwin9* | *-cygwin* | *-mingw*) ;;
+  *-apple-darwin9* | *-cygwin* | *-mingw* | *djgpp*) ;;
   # On other non-ELF platforms, LTO has yet to be validated.
   *) enable_lto=no ;;
 esac
@@ -1828,7 +1828,7 @@ ACX_ELF_TARGET_IFELSE([# ELF platforms build the lto-plugin always.
   # warn during gcc/ subconfigure; unless you're bootstrapping with
   # -flto it won't be needed until after installation anyway.
 case $target in
-  *-cygwin* | *-mingw* | *-apple-darwin*) ;;
+  *-cygwin* | *-mingw* | *-apple-darwin* | *djgpp*) ;;
   *) if test x"$enable_lto" = x"yes"; then
 	AC_MSG_ERROR([LTO support is not enabled for this target.])
 fi
-- 
2.5.0

Re: [PATCH 5/6] [DJGPP] gcc/config/i386: update DJGPP configuration related files

2015-12-12 Thread Andris Pavenis 

On 12/11/2015 12:43 AM, Jeff Law wrote:

On 12/05/2015 10:22 AM, Andris Pavenis wrote:

Patch include updates to DJGPP related files in gcc/config/i386.

There are too many changes to gcc/config/i386/djgpp.h and
gcc/config/i386/xm-djgpp.h to list them completely in changelog
entry.

Andris

2015-11-25 Andris Pavenis 

Subject: [PATCH 6/6] [DJGPP] gcc/config/i386: update DJGPP configuration
  related files

* gcc/config/i386/djgpp.h: update
* gcc/config/i386/xm-djgpp.h: update
* gcc/config/i386/djgpp.c: new file
* gcc/config/i386/djgpp.opt: remove obsolete option -mbnu210
* gcc/config/i386/t-djgpp: new file
* gcc/config.gcc: use i386/t-djgpp for DJGPP target

0005-DJGPP-gcc-config-i386-update-DJGPP-configuration-rel.patch


 From 367432d08b4a00f180c3d0710a0f34cda1b6 Mon Sep 17 00:00:00 2001
From: Andris Pavenis
Date: Sat, 5 Dec 2015 08:49:12 +0200
Subject: [PATCH 5/6] [DJGPP] gcc/config/i386: update DJGPP configuration 
related files

* gcc/config/i386/djgpp.h: update
* gcc/config/i386/xm-djgpp.h: update

You should describe what you updated.  SImply saying "update" is insufficient 
here.

Updated ChangeLog entry included


diff --git a/gcc/config/i386/djgpp.c b/gcc/config/i386/djgpp.c
new file mode 100644
index 000..29dad33
--- /dev/null
+++ b/gcc/config/i386/djgpp.c
@@ -0,0 +1,50 @@
+/* Subroutines for DJGPP.
+   Contributed by Andris Pavenis
+   Copyright (C) 2013 Free Software Foundation, Inc.

Copyright date needs updating.

I also removed direct reference to me. One can check search ChangeLog if 
interested



+
+void
+i386_djgpp_asm_named_section(const char *name, unsigned int flags,
+ tree decl)
+{
+  char flagchars[8], *f = flagchars;
+
+(void)decl; /* silence warning. */
The way to do this now is to not give a name to the parameter. So remove "decl" from the function 
signature (leaving its type though). Then you can remove this line.


OK



--- a/gcc/config/i386/djgpp.h
+++ b/gcc/config/i386/djgpp.h
@@ -17,12 +17,27 @@ You should have received a copy of the GNU General Public 
License
  along with GCC; see the file COPYING3.  If not see
  .  */

+#define DBX_DEBUGGING_INFO 1
+#define SDB_DEBUGGING_INFO 1
?  Really,  do you *really* need this.  I'd really like to see DBX and SDB debugging info die, 
not propagate into more targets.

They were missing for some versions of DJGPP builds and re-added after some 
discussion.
DJGPP port of Emacs depends on COFF debugging information. Building it with recent versions of GCC 
do not however work, so

no harm from removing it




-#define IX86_MAYBE_NO_LIBGCC_TFMODE
+#undef DBX_REGISTER_NUMBER
+#define DBX_REGISTER_NUMBER(n) svr4_dbx_register_map[n]

And if the DBX_DEBUGGING_INFO goes away, can't this go away too?
Not according GCC internal docs 
(https://gcc.gnu.org/onlinedocs/gccint/All-Debuggers.html#All-Debuggers).

It is also rather widely used for other targets


Jeff




Andris


New ChangeLog entry:

015-12-12 Andris Pavenis 

   [DJGPP] gcc/config/i386: update DJGPP configuration related files

   * config/i386/djgpp.h (PREFERRED_DEBUGGING_TYPE): Define to DWARF2
   (TARGET_ASM_OUTPUT_IDENT): Define to default_asm_output_ident_directive
   (MD_EXEC_PREFIX): Remove.
   (MD_STARTFILE_PREFIX) Removee.
   (FILE_NAME_ABSOLUTE_P): Remove.
   (CPP_SPEC): Do not read macros from sys/version.h.
   (LINK_COMMAND_SPEC): Remove.
   (LOCAL_INCLUDE_DIR): Remove.
   (TARGET_ASM_NAMED_SECTION): Define to i386_djgpp_asm_named_section
   (TARGET_OS_CPP_BUILTINS): Add DJGPP (non ISO only), __DJGPP, __DJGPP__, 
unix.
   (POST_LINK_SPEC): Define to invoke stubify after linker
   (LIBSTDCXX): Remove define
   (DBX_REGISTER_NUMBER): Define to svr4_dbx_register_map.
   (DEFAULT_PCC_STRUCT_RETURN): Define to 1.
   (SUBTARGET_OVERRIDE_OPTIONS): Remove warning about -mbnu2210.
   (SUBTARGET_OVERRIDE_OPTIONS): Ignore -fPIC and generate message.
   (SUBTARGET_OVERRIDE_OPTIONS): Default to DWARF2 debugging info.
   (IX86_MAYBE_NO_LIBGCC_TFMODE): Remove.
   (i386_djgpp_asm_named_section): Add propotype of new procedure

   * config/i386/xm-djgpp.h (NATIVE_SYSTEM_HEADER_DIR): Define.
   (MD_EXEC_PREFIX): Define (moved from config/i386/djgpp.h).
   (STANDARD_STARTFILE_PREFIX_1): Define (moved from MD_STARTFILE_PREFIX in 
config/i386/djgpp.h).
   (STANDARD_STARTFILE_PREFIX_2): Define identical to 
STANDARD_STARTFILE_PREFIX_1.
   (LOCAL_INCLUDE_DIR): Define (moved from config/i386/djgpp.h).
   (GCC_DRIVER_HOST_INITIALIZATION): Fix reporting fatal installation 
errors.
   (MAX_OFILE_ALIGNMENT): Define to 128.
   (HAVE_FTW_H): Undefine as DJGPP do not have nftw, but have ftw.h.

   * config/i386/djgpp.c: New file. Add implementation of 
i386_djgpp_asm_named_section.

   * config/i386/djgpp.opt: Remove obsolete option

Re: [PATCH] v2 Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

2015-12-12 Thread Bernhard Reutner-Fischer 
On December 9, 2015 2:07:05 AM GMT+01:00, David Malcolm  
wrote:

>I can't comment on Mikael's observations, but here's an updated version
>of Bernhard's patch which moves the duplicated code into a new
>"find_closest_string" function in gcc/spellcheck.c.  
>With that, the lookup_*_fuzzy functions are all of the form:
>
>{
>  auto_vec  candidates;
>
>  /* call something to populate candidates e.g.: */
>  lookup_function_fuzzy_find_candidates (fun, );
>
>  return find_closest_string (fn, );
>}
>
>where, as before, the auto_vec is implicitly cleaned up via a
>C++ destructor as the function exits.  Hopefully with this change it
>reduces the amount of proposed C++ in the fortran subdirectory to an
>palatable amount.
>
>That's all I did; I didn't address the other issues seen in this thread
>(e.g. Mikael's notes above).
>
>Not yet well-tested; it compiles and passes the new test cases; I'm
>posting it here in case someone more familiar with the Fortran FE wants
>to take this forward (Bernhard?)

I have rewritten the autovec to plain c, will send an updated patch including 
current comments and maybe the parameter handling as suggested by Joost when 
done.

Thanks,
>
>Hope this is constructive
>Dave

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

2015-12-12 Thread Jason Merrill 

On 12/11/2015 06:52 PM, H.J. Lu wrote:

On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
 wrote:

On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
 wrote:

On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:


Empty C++ class is a corner case which isn't covered in psABI nor C++ ABI.
There is no mention of "empty record" in GCC documentation.  But there are
plenty of "empty class" in gcc/cp.  This change affects all targets.  C++ ABI
should specify how it should be passed.


There is a C++ ABI mailinglist, where you could discuss this issue:
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev


Yep.  As long as the ABI doesn't state how to pass those I'd rather _not_ change
GCCs way.


It is agreed that GCC is wrong on this:

http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html


Yes, I think this is just a (nasty) bug on some GCC targets.


Here is the updated patch.   I updated -WpsABI to warn empty
record which are passed in a variable argument list or aren't the last
arguments.   They are triggered in:

/export/build/gnu/gcc-x32/build-x86_64-linux/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1507:7:
note: the ABI of passing empty record has changed in GCC 6

>

Oof.  Well, at least it's all C++11 stuff, and GCC 5 still defaulted to 
C++98...


Jason

Re: [Patch, Fortran] PR45859 - Permit array elements to coarray dummy arguments

2015-12-12 Thread Steve Kargl 
On Wed, Dec 09, 2015 at 08:24:39AM +0100, Tobias Burnus wrote:
> PING
> 

OK.

-- 
Steve

Re: Transparent alias suport part 7 (lto-symtab support)

2015-12-12 Thread H.J. Lu 
On Tue, Dec 8, 2015 at 2:30 PM, Jan Hubicka  wrote:
> Hi,
> this patch adds support to lto-symtab.c to prevent merging of certain
> declarations.  The new predicate lto_symtab_merge_p can be used to decide
> about this.   The change is pretty straigforward.  lto_symtab_merge_decls_2
> makes the decisions about what decls to merge and lto_symtab_merge_symbols_1
> does the corresponding symbol merging/creation of transparent aliases.
>
> I re-implemented lto_symtab_prevailing_decl and moved it to inline so the
> merging pass is also considerably faster (it used to do quite expensive
> assembler name hash lookup on every occurenceof the decl).  Merging decisions
> are represented by setting DECL_ABSTRACT_ORIGIN to error_mark_node and
> DECL_CHAIN to the replacement decl.  This is quite arbitrary decision - I 
> needed
> a pointer and flag that is not going to mess with the warnings we output
> during the lto-symtab's operation.
>
> The patch does not disable any of the wrong merging we are hitting.  I will
> dot hat separately and with a testcases.  I only revisited a bit the way
> builtins are handled.
>
> Bootstrapped/regtested x86_64-linux. I am re-running the lto-bootstrap after
> some last minute changes and plan commit once it converges.
>
> Honza
>
> PR ipa/61886
> * lto-streamer.h (lto_symtab_merge_decls, lto_symtab_merge_symbols,
> lto_symtab_prevailing_decl): MOve to lto-symtab.h.
>
> * lto-symtab.c: Include lto-symtab.h.
> (lto_cgraph_replace_node): Do not merge profiles here.
> (lto_symtab_merge_p): New function.
> (lto_symtab_merge_decls_2): Honor lto_symtab_merge_p.
> (lto_symtab_merge_symbols_1): Turn unmerged decls into transparent
> aliases.
> (lto_symtab_merge_symbols): Do not clear node->aux; we no longer use 
> it.
> (lto_symtab_prevailing_decl): Move to lto-symtab.h; rewrite.
> * lto.c: Include lto-symtab.h
> * lto-symtab.h: New.
>

This caused:

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


-- 
H.J.

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

2015-12-12 Thread Marc Glisse 

On Sat, 12 Dec 2015, Jakub Jelinek wrote:


On Sat, Dec 12, 2015 at 09:51:23AM -0500, Jason Merrill wrote:

On 12/11/2015 06:52 PM, H.J. Lu wrote:

On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
 wrote:

On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
 wrote:

On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:


Empty C++ class is a corner case which isn't covered in psABI nor C++ ABI.
There is no mention of "empty record" in GCC documentation.  But there are
plenty of "empty class" in gcc/cp.  This change affects all targets.  C++ ABI
should specify how it should be passed.



About this patch, aren't we supposed to enable new C++ ABIs with 
-fabi-version=42 (or whatever the next number is)?




There is a C++ ABI mailinglist, where you could discuss this issue:
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev


Yep.  As long as the ABI doesn't state how to pass those I'd rather _not_ change
GCCs way.


It is agreed that GCC is wrong on this:

http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html


Yes, I think this is just a (nasty) bug on some GCC targets.


Well, the argument in that thread is weird, because C and C++ empty structs
are different, so it isn't surprising they are passed differently.
C++ makes those sizeof == 1, while C has them sizeof == 0.


Maybe it isn't surprising, but it isn't particularly helpful either. It 
increases the number of places where the 2 are incompatible.

(I personally don't care about empty C structs)


So I rather think clang should change rather than GCC.


Passing empty arguments (with trivial copy constructor, etc) is a complete 
waste. Not passing them is strictly superior. The only reason to prefer 
passing them is that that's what gcc does and changing would break the 
ABI. I could understand clang being unhappy if they have to both break ABI 
compatibility with their older versions and move towards an inferior 
ABI... (arguably they could have copied the de facto gcc ABI to begin 
with) They might be willing to do it on linux-x86, but not on ios/mac 
where they dominate and compatibility with their own earlier versions 
matters more than compatibility with gcc?


--
Marc Glisse

[v3 PATCH] Document the implementation of Logical Operator Type Traits.

2015-12-12 Thread Ville Voutilainen 
2015-11-12  Ville Voutilainen  

Document the implementation of Logical Operator Type Traits.

* doc/html/index.html: Regenerate.
* doc/html/manual/status.html: Likewise.
* doc/xml/manual/status_cxx2017.xml: Add P0013R1 to C++ 201z
and to Library Fundamentals 2 TS.
diff --git a/libstdc++-v3/doc/html/index.html b/libstdc++-v3/doc/html/index.html
index 1d2815c..d3570c4 100644
--- a/libstdc++-v3/doc/html/index.html
+++ b/libstdc++-v3/doc/html/index.html
@@ -23,7 +23,7 @@
 Table of 
ContentsThe GNU C++ Library 
ManualI. 
   Introduction
   
-1. StatusImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 
2011Implementation Specific 
BehaviorC++ 2014C++ 
201zC++ 
TR1Implementation Specific 
BehaviorC++ TR 
24733LicenseThe Code: 
GPLThe Documentation: 
GPL, FDLBugsImplementation 
BugsStandard 
Bugs2. SetupPrerequisitesConfigureMake3. 
UsingCommand 
OptionsHeadersHeader 
FilesMixing 
HeadersThe C 
Headers and namespace stdPrecompiled 
HeadersMacrosDual 
ABITroubleshootingNamespacesAvailable 
Namespacesnamespace 
stdUsing 
Namespace CompositionLinkingAlmost
 NothingFinding
 Dynamic or Shared LibrariesConcurrencyPrerequisitesThread
 SafetyAtomicsIOStructureDefaultsFutureAlternativesContainersExceptionsException 
SafetyException 
NeutralityDoing 
withoutCompatibilityWith CWith POSIX thread 
cancellationDebugging SupportUsing g++Debug Versions of Library 
Binary FilesMemory Leak 
HuntingData Race HuntingUsing gdbTracking uncaught 
exceptionsDebug ModeCompile 
Time CheckingProfile-based Performance 
AnalysisII. 
+1. StatusImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 
2011Implementation Specific 
BehaviorC++ 2014C++ 
201zC++ 
TR1Implementation Specific 
BehaviorC++ TR 
24733LicenseThe Code: 
GPLThe Documentation: 
GPL, FDLBugsImplementation 
BugsStandard 
Bugs2. SetupPrerequisitesConfigureMake3. 
UsingCommand 
OptionsHeadersHeader 
FilesMixing 
HeadersThe C 
Headers and namespace stdPrecompiled 
HeadersMacrosDual 
ABITroubleshootingNamespacesAvailable 
Namespacesnamespace 
stdUsing 
Namespace CompositionLinkingAlmost
 NothingFinding
 Dynamic or Shared LibrariesExperimental
 Library ExtensionsConcurrencyPrerequisitesThread
 SafetyAtomicsIOStructureDefaultsFutureAlternativesContainersExceptionsException 
SafetyException 
NeutralityDoing 
withoutCompatibilityWith CWith POSIX thread 
cancellationDebugging SupportUsing g++Debug Versions of Library 
Binary FilesMemory Leak 
HuntingData Race HuntingUsing gdbTracking uncaught 
exceptionsDebug ModeCompile 
Time CheckingProfile-based Performance 
AnalysisII. 
 Standard Contents
   4. 
   Support
@@ -31,7 +31,7 @@
 TypesFundamental 
TypesNumeric 
PropertiesNULLDynamic 
MemoryTerminationTermination 
HandlersVerbose Terminate 
Handler5. 
   Diagnostics
   
-ExceptionsAPI 
ReferenceAdding Data to 
exceptionConcept 
Checking6. 
+ExceptionsAPI 
ReferenceAdding Data to 
exceptionUse of errno by the 
libraryConcept 
Checking6. 
   Utilities
   
 FunctorsPairsMemoryAllocatorsRequirementsDesign 
IssuesImplementationInterface 
DesignSelecting Default Allocation 
PolicyDisabling Memory 
CachingUsing a Specific 
AllocatorCustom 
AllocatorsExtension 
Allocatorsauto_ptrLimitationsUse in 
Containersshared_ptrRequirementsDesign 
IssuesImplementationClass 
HierarchyThread 
SafetySelecting Lock 
PolicyRelated functions and 
classesUseExamplesUnresolved 
IssuesAcknowledgmentsTraits7. 
diff --git a/libstdc++-v3/doc/html/manual/status.html 
b/libstdc++-v3/doc/html/manual/status.html
index 91404aa..8c5a7c9 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -539,6 +539,12 @@ not in any particular release.

   
 Minimal incomplete type support for standard containers, revision 4
+  Y 
+   http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0013r1.html; 
target="_top">
+ P0013R1
+   
+  
+Logical Operator Type Traits (revision 1)
   Y 
Table 
1.6. C++ Technical Specifications Implementation StatusPaperTitleStatusComments
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4076.html; 
target="_top">
  N4076
@@ -579,7 +585,11 @@ not in any particular release.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4521.html; 
target="_top">
  N4521

-   Merge Fundamentals V1 into V2 NLibrary Fundamentals 2 
TSC++ TR1
+   Merge Fundamentals V1 into V2 NLibrary Fundamentals 2 TS
+   http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0013r1.html; 
target="_top">
+ P0013R1
+   
+  Logical Operator Type Traits (revision 1)YLibrary Fundamentals 2 
TSC++ TR1
 This table is based on the table of contents of ISO/IEC DTR 19768
 Doc No: N1836=05-0096 Date: 2005-06-24
 Draft Technical Report on C++ Library Extensions
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml

Re: Do not decompress functions sections when copying them to ltrans

2015-12-12 Thread Jan Hubicka 
> > So would the patch be a lot more difficult if you go down either of
> > the routes above?  (I think I prefer changing lto_header rather
> > than making main_size a bitfield)
> 
> Agreed ;)
Hmm, actually it seems things are difficult. All the headers are already 
compressed
by zlib:
Contents of section .gnu.lto_.inline.faa6142d1fc0c505:
  789c6362 6062c006 10a2 ba0007x.cb`b. 
Contents of section .gnu.lto_.symbol_nodes.faa6142d1fc0c505:
  789c6362 6062e060 80025606 06f67a06  x.cb`b.`..V...z.
 0010 0600029c 0098..  
Contents of section .gnu.lto_.refs.faa6142d1fc0c505:
  789c6362 60626064 8002 460006x.cb`b`dF.. 
Contents of section .gnu.lto_.decls.faa6142d1fc0c505:
  789c6362 6062d060 6060f80f 0461405a  x.cb`b.```...a@Z
 0010 10881981 d88e0115 80c496a2 8929312c  .)1,
 0020 6c5870e0 c1d2291c 131a1b1b feffaf4f  lXp...)O
 0030 6464e104 9ac7cec8 a0c5b0b2 a1a16142  ddaB
 0040 43c32336 142d118c 898c7c9c 0c0a6006  C.#6.-|...`.
 0050 0f27030b 58349171 1923135c 0d4b895e  .'..X4.q.#.\.K.^
 0060 32037359 620e9bbb 5fa88233 0300a167  2.sYb..._..3...g
 0070 1a7f ..  
Contents of section .gnu.lto_.symtab.faa6142d1fc0c505:
  76616c00 00040004  00a5  val.
 0010 00   ...  


Contents of section .gnu.lto_.opts: 


  272d6d74 756e653d 67656e65 72696327  '-mtune=generic' 


 0010 20272d6d 61726368 3d783836 2d363427   '-march=x86-64' 


 0020 20272d66 6c746f27 00  '-flto'.


Contents of section .comment:   


  00474343 3a202853 55534520 4c696e75  .GCC: (SUSE Linu 


 0010 78292034 2e382e33 20323031 34303632  x) 4.8.3 2014062 


 0020 37205b67 63632d34 5f382d62 72616e63  7 [gcc-4_8-branc
 0030 68207265 76697369 6f6e2032 31323036  h revision 21206
 0040 345d00   4]. 

as you can see only opts/comment and symtab sections come out decompressed.
The sequence x.cb`b is zlib's header.  The description is here:
https://tools.ietf.org/html/rfc1950#page-4

There don't seem to be unique identifier of the zlib header that would
allow us to tell lto_header apart from zlib, so I don't think I can play
a trick and auto-detect the compression.  As such, I do not think
we can get a header about compression into section w/o breaking
backward compatibility short of inventing our own mallformed zlib
header which we would be sure to be able to tell apart from zlib's.
That would defeat the plan to not increase the section sizes.

I would preffer to go with my current solution until we make a new
"major major" revision of the format where we will have a chance
to drop all this and cleanup other design mistakes of the original
LTO format.

Honza

Re: Do not decompress functions sections when copying them to ltrans

2015-12-12 Thread Richard Biener 
On December 12, 2015 7:47:39 PM GMT+01:00, Jan Hubicka  wrote:
>> > So would the patch be a lot more difficult if you go down either of
>> > the routes above?  (I think I prefer changing lto_header rather
>> > than making main_size a bitfield)
>> 
>> Agreed ;)
>Hmm, actually it seems things are difficult. All the headers are
>already compressed
>by zlib:
>Contents of section .gnu.lto_.inline.faa6142d1fc0c505:
>  789c6362 6062c006 10a2 ba0007x.cb`b. 
>Contents of section .gnu.lto_.symbol_nodes.faa6142d1fc0c505:
>  789c6362 6062e060 80025606 06f67a06  x.cb`b.`..V...z.
> 0010 0600029c 0098..  
>Contents of section .gnu.lto_.refs.faa6142d1fc0c505:
>  789c6362 60626064 8002 460006x.cb`b`dF.. 
>Contents of section .gnu.lto_.decls.faa6142d1fc0c505:
>  789c6362 6062d060 6060f80f 0461405a  x.cb`b.```...a@Z
> 0010 10881981 d88e0115 80c496a2 8929312c  .)1,
> 0020 6c5870e0 c1d2291c 131a1b1b feffaf4f  lXp...)O
> 0030 6464e104 9ac7cec8 a0c5b0b2 a1a16142  ddaB
> 0040 43c32336 142d118c 898c7c9c 0c0a6006  C.#6.-|...`.
> 0050 0f27030b 58349171 1923135c 0d4b895e  .'..X4.q.#.\.K.^
> 0060 32037359 620e9bbb 5fa88233 0300a167  2.sYb..._..3...g
> 0070 1a7f ..  
>Contents of section .gnu.lto_.symtab.faa6142d1fc0c505:
>  76616c00 00040004  00a5  val.
>0010 00   ...  
>   
>Contents of section .gnu.lto_.opts:
>   
> 272d6d74 756e653d 67656e65 72696327  '-mtune=generic' 
>   
>0010 20272d6d 61726368 3d783836 2d363427   '-march=x86-64' 
>   
>0020 20272d66 6c746f27 00  '-flto'.
>   
>Contents of section .comment:  
>   
> 00474343 3a202853 55534520 4c696e75  .GCC: (SUSE Linu 
>   
>0010 78292034 2e382e33 20323031 34303632  x) 4.8.3 2014062 
>   
> 0020 37205b67 63632d34 5f382d62 72616e63  7 [gcc-4_8-branc
> 0030 68207265 76697369 6f6e2032 31323036  h revision 21206
> 0040 345d00   4]. 
>
>as you can see only opts/comment and symtab sections come out
>decompressed.
>The sequence x.cb`b is zlib's header.  The description is here:
>https://tools.ietf.org/html/rfc1950#page-4
>
>There don't seem to be unique identifier of the zlib header that would
>allow us to tell lto_header apart from zlib, so I don't think I can
>play
>a trick and auto-detect the compression.  As such, I do not think
>we can get a header about compression into section w/o breaking
>backward compatibility short of inventing our own mallformed zlib
>header which we would be sure to be able to tell apart from zlib's.
>That would defeat the plan to not increase the section sizes.

Aww, yeah.  Now I remember.

>I would preffer to go with my current solution until we make a new
>"major major" revision of the format where we will have a chance
>to drop all this and cleanup other design mistakes of the original
>LTO format.

OK...

Richard.

>
>Honza

[SPARC] Enable wide-int support

2015-12-12 Thread Eric Botcazou 
On the heels of s390, this enables wide-int support in the SPARC back-end and 
removes all the obsolete code conditionalized on HOST_BITS_PER_WIDE_INT == 32.

Boostrapped/regtested on SPARC/Solaris, applied on the mainline.


2015-12-12  Eric Botcazou  

* config/sparc/sparc.h (TARGET_SUPPORTS_WIDE_INT): Define to 1.
* config/sparc/sparc.c (sparc_emit_set_const64): Remove code
conditionalized on HOST_BITS_PER_WIDE_INT == 32.
(sparc_cannot_force_const_mem) : New case.
: Remove VOIDmode test.
(epilogue_renumber) : New case.
(sparc_print_operand): Remove support for CONST_DOUBLE with VOIDmode.
(sparc_assemble_integer): Likewise.
(set_extends): Likewise.
(sparc_rtx_costs) : Use SMALL_INT.
: New case.
: Remove support for VOIDmode.
: Remove support for CONST_DOUBLE with VOIDmode.
* config/sparc/predicates.md (const_zero_operand): Add const_wide_int.
(const_all_ones_operand): Likewise.
(uns_small_int_operand): Remove const_double and code conditionalized
on HOST_BITS_PER_WIDE_INT == 32.
(arith_double_operand): Likewise.
(arith_double_add_operand): Likewise.
(input_operand): Remove support for CONST_DOUBLE with DImode.
* config/sparc/sparc.md (DImode CONST_INT splitter): Remove code
conditionalized on HOST_BITS_PER_WIDE_INT == 32.
(DFmode CONST_DOUBLE splitter): Likewise.
(*adddi3_insn_sp32): Likewise.
(*subdi3_insn_sp32): Likewise.
(DImode logical splitter): Likewise.
(DImode CONST_DOUBLE splitter): Delete.

-- 
Eric BotcazouIndex: config/sparc/predicates.md
===
--- config/sparc/predicates.md	(revision 231562)
+++ config/sparc/predicates.md	(working copy)
@@ -21,13 +21,12 @@
 
 ;; Return true if OP is the zero constant for MODE.
 (define_predicate "const_zero_operand"
-  (and (match_code "const_int,const_double,const_vector")
+  (and (match_code "const_int,const_wide_int,const_double,const_vector")
(match_test "op == CONST0_RTX (mode)")))
 
-;; Return true if the integer representation of OP is
-;; all-ones.
+;; Return true if the integer representation of OP is all ones.
 (define_predicate "const_all_ones_operand"
-  (and (match_code "const_int,const_double,const_vector")
+  (and (match_code "const_int,const_wide_int,const_double,const_vector")
(match_test "INTEGRAL_MODE_P (GET_MODE (op))")
(match_test "op == CONSTM1_RTX (GET_MODE (op))")))
 
@@ -47,20 +46,10 @@ (define_predicate "small_int_operand"
 ;; instruction sign-extends immediate values just like all other SPARC
 ;; instructions, but interprets the extended result as an unsigned number.
 (define_predicate "uns_small_int_operand"
-  (match_code "const_int,const_double")
-{
-#if HOST_BITS_PER_WIDE_INT == 32
-  return ((GET_CODE (op) == CONST_INT && (unsigned) INTVAL (op) < 0x1000)
-	  || (GET_CODE (op) == CONST_DOUBLE
-	  && CONST_DOUBLE_HIGH (op) == 0
-	  && (unsigned) CONST_DOUBLE_LOW (op) - 0xF000 < 0x1000));
-#else
-  return (GET_CODE (op) == CONST_INT
-	  && ((INTVAL (op) >= 0 && INTVAL (op) < 0x1000)
-	  || (INTVAL (op) >= 0xF000
-  && INTVAL (op) <= 0x)));
-#endif
-})
+  (and (match_code "const_int")
+   (match_test "((INTVAL (op) >= 0 && INTVAL (op) < 0x1000)
+		|| (INTVAL (op) >= 0xF000
+			&& INTVAL (op) <= 0x))")))
 
 ;; Return true if OP is a constant that can be loaded by the sethi instruction.
 ;; The first test avoids emitting sethi to load zero for example.
@@ -308,7 +297,7 @@ (define_predicate "arith_operand"
 ;; representable by a couple of 13-bit signed fields.  This is an
 ;; acceptable operand for most 3-address splitters.
 (define_predicate "arith_double_operand"
-  (match_code "const_int,const_double,reg,subreg")
+  (match_code "const_int,reg,subreg")
 {
   bool arith_simple_operand = arith_operand (op, mode);
   HOST_WIDE_INT m1, m2;
@@ -316,17 +305,11 @@ (define_predicate "arith_double_operand"
   if (TARGET_ARCH64 || arith_simple_operand)
 return arith_simple_operand;
 
-#if HOST_BITS_PER_WIDE_INT == 32
-  if (GET_CODE (op) != CONST_DOUBLE)
-return false;
-  m1 = CONST_DOUBLE_LOW (op);
-  m2 = CONST_DOUBLE_HIGH (op);
-#else
   if (GET_CODE (op) != CONST_INT)
 return false;
+
   m1 = trunc_int_for_mode (INTVAL (op), SImode);
   m2 = trunc_int_for_mode (INTVAL (op) >> 32, SImode);
-#endif
 
   return SPARC_SIMM13_P (m1) && SPARC_SIMM13_P (m2);
 })
@@ -338,11 +321,9 @@ (define_predicate "arith_add_operand"
 
 ;; Return true if OP is suitable as second double operand for add/sub.
 (define_predicate "arith_double_add_operand"
-  (match_code "const_int,const_double,reg,subreg")
+  (match_code "const_int,reg,subreg")
 {
-  bool _arith_double_operand = arith_double_operand (op, mode);
-
-  if (_arith_double_operand)
+  if

[PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators)

2015-12-12 Thread Patrick Palka 
On Fri, 11 Dec 2015, Jason Merrill wrote:

> On 12/11/2015 02:43 PM, Patrick Palka wrote:
>> +  if (processing_template_decl
>> +  && result != NULL_TREE
>> +  && result != error_mark_node
>> +  && DECL_HIDDEN_FRIEND_P (cand->fn))
>> +{
>> +  tree call = result;
>> +  if (REFERENCE_REF_P (call))
>> +call = TREE_OPERAND (call, 0);
>> +  KOENIG_LOOKUP_P (call) = 1;
>> +}
>
> This should have a comment explaining that this prevents
> build_new_function_call from discarding the function.

Consider it done.

>
>> +  if (op == PREINCREMENT_EXPR
>> +  || op == PREDECREMENT_EXPR)
>> +gcc_assert (nargs == 1);
>> +  else if (op == MODOP_EXPR)
>> +gcc_assert (nargs == 2);
>> +  else
>> +gcc_assert (nargs == TREE_CODE_LENGTH (op));
>
> This should use cp_tree_operand_length.

Hmm, I don't immediately see how I can use this function here.  It
expects a tree but I dont have an appropriate tree to give to it, only a
tree_code.  And I can't overload it easily because it calls
TREE_OPERAND_LENGTH which expects a tree as well.

Your pointing out of this function fortunately made me uncover a bug in
my patch: that the function build_min_non_dep_op_overload expects the
wrong number of arguments to an operator[] overload.  It is expecting 4
(i.e. TREE_CODE_LENGTH (ARRAY_REF)) instead of 2.

This should have caused an ICE but it turns out that the test case was
not using the code I added in build_x_array_ref at all, because during
template processing, ARRAY_REFS seem to get processed via
grok_array_decl -- a caller of build_new_op that I had forgotten to
change.

This patch v3 fixes this issue by adjusting the functions
build_min_non_dep_op_overload and grok_array_decl accordingly.  It also
improves the pr53223.C test case to use static_assert and std::is_same<>
to explicitly confirm that the auto types in the test case are correctly
deduced.

gcc/cp/ChangeLog:

PR c++/21802
PR c++/53223
* cp-tree.h (build_min_non_dep_op_overload): Declare.
* tree.c (build_min_non_dep_op_overload): Define.
(build_win_non_dep_call_vec): Copy KOENIG_LOOKUP_P flag.
* typeck.c (build_x_indirect_ref): Use
build_min_non_dep_op_overload when the given expression
has been resolved to an operator overload.
(build_x_binary_op): Likewise.
(build_x_array_ref): Likewise.
(build_x_unary_op): Likewise.
(build_x_compound_expr): Likewise.
(build_x_modify_expr): Likewise.
* decl2.c (grok_array_decl): Likewise.
* call.c (build_new_op_1): If during template processing we
chose an operator overload that is a hidden friend function, set
the call's KOENIG_LOOKUP_P flag to 1.

gcc/testsuite/ChangeLog:

PR c++/21802
PR c++/53223
* g++.dg/cpp0x/pr53223.C: New test.
* g++.dg/lookup/pr21802.C: New test.
* g++.dg/lookup/two-stage4.C: Remove XFAIL.
---
 gcc/cp/call.c|  13 ++
 gcc/cp/cp-tree.h |   1 +
 gcc/cp/decl2.c   |  13 +-
 gcc/cp/tree.c|  67 
 gcc/cp/typeck.c  | 100 ---
 gcc/testsuite/g++.dg/cpp0x/pr53223.C |  45 +
 gcc/testsuite/g++.dg/lookup/pr21802.C| 276 +++
 gcc/testsuite/g++.dg/lookup/two-stage4.C |   2 +-
 8 files changed, 494 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr53223.C
 create mode 100644 gcc/testsuite/g++.dg/lookup/pr21802.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 117dd79..cdfa01a 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -5630,6 +5630,19 @@ build_new_op_1 (location_t loc, enum tree_code code, int 
flags, tree arg1,
result = error_mark_node;
  else
result = build_over_call (cand, LOOKUP_NORMAL, complain);
+
+ if (processing_template_decl
+ && result != NULL_TREE
+ && result != error_mark_node
+ && DECL_HIDDEN_FRIEND_P (cand->fn))
+   {
+ tree call = result;
+ if (REFERENCE_REF_P (call))
+   call = TREE_OPERAND (call, 0);
+ /* This prevents build_new_function_call from discarding this
+function during instantiation of the enclosing template.  */
+ KOENIG_LOOKUP_P (call) = 1;
+   }
}
   else
{
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 6190f4e..3487d77 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6513,6 +6513,7 @@ extern tree build_min (enum 
tree_code, tree, ...);
 extern tree build_min_nt_loc   (location_t, enum tree_code,
 ...);
 extern tree build_min_non_dep  (enum tree_code, tree, ...);
+extern tree build_min_non_dep_op_overload

Re: [PATCH v2] Do not sanitize left shifts for -fwrapv (PR68418)

2015-12-12 Thread Eric Botcazou 
> gcc:
>   PR sanitizer/68418
>   * c-family/c-ubsan.c (ubsan_instrument_shift): Disable
>   sanitization of left shifts for wrapping signed types as well.

That's incorrect, it should be put into c-family/ChangeLog without prefix.

-- 
Eric Botcazou

Re: Prune TYPE_FIELDS lists more in free_lang_data

2015-12-12 Thread Jan Hubicka 
> On Fri, 11 Dec 2015, Jan Hubicka wrote:
> 
> > > 
> > > We explicitely do not use debug-info-level tests in free-lang-data
> > > to allow mixing -g and -g0 objects.  Are you sure doing the above
> > > doesn't mess up tree merging enough to effectively enlarge WPA
> > > memory use and the merged decl sections?
> > > 
> > > [I'm quite sure firefox build system manages to mess up -g vs. -g0
> > > in some places ;)]
> > 
> > Hmm, I will try the debug build with firefox on this.  -fdump-ipa-devirt
> > now dumps all main variants that are duplicates of one ODR type.
> > We definitely have types with hundreds of duplicates, so there are
> > quite common cases where tree merging does not fire.
> > > 
> > > > +  return (!DECL_IGNORED_P (decl) && !is_redundant_typedef (decl));
> > > > +}
> > > > +
> > > 
> > > The patch would be ok if you simply export is_redundant_typedef
> > > and inline the DECL_IGNORED_P check into free-lang-data.
> > 
> > OK, I had that originally, will return that back.
> > is_redundant_typedef is declared inline.  Putting it to tree.h drags
> > bit too many dwarf2out internals, but I suppose it is OK to just
> > turn it non-inline.  It is a type of function where inliner should be
> > able to decide.
> 
> Yeah.
Hi,
this is a variant of patch I re-tested (x86_64-linux) and comitted.  I also
double checked that it results in smaller meomry footprint on the -g/-no-g
mixed build of firefox (I built Javascript without debug and rest with).
THe tree merging is affected but not in very significant way.  Hopefully
this will all go early next stage1 with early debug :)

I also noticed that TYPE_DECLs are common in BLOCK_VARs. I will check how
many of them can be shaved off and if that furhter increases partitionability.

The size of largest ltransp partition with this patch and debug shrinks
from 862k trees to 710k trees and for a first time I am aware of we get
both debug and non-debug builds under 3GB of WPA on my firefox tree (that
is from the time GCC 5 was released - I will update it once I get past issues
on this one)

Thanks,
Honza

* tree.c (free_lang_data_in_type, find_decls_types_r): Also free
unnecesary type decls.
* tree.h (is_redundant_typedef): Declare.
* dwarf2out.c (is_redundant_typedef): Export; booleanize
Index: tree.c
===
--- tree.c  (revision 231581)
+++ tree.c  (working copy)
@@ -5191,7 +5191,10 @@ free_lang_data_in_type (tree type)
   while (member)
{
  if (TREE_CODE (member) == FIELD_DECL
- || TREE_CODE (member) == TYPE_DECL)
+ || (TREE_CODE (member) == TYPE_DECL
+ && !DECL_IGNORED_P (member)
+ && debug_info_level > DINFO_LEVEL_TERSE
+ && !is_redundant_typedef (member)))
{
  if (prev)
TREE_CHAIN (prev) = member;
@@ -5216,7 +5219,7 @@ free_lang_data_in_type (tree type)
   /* Remove TYPE_METHODS list.  While it would be nice to keep it
 to enable ODR warnings about different method lists, doing so
 seems to impractically increase size of LTO data streamed.
-Keep the infrmation if TYPE_METHODS was non-NULL. This is used
+Keep the information if TYPE_METHODS was non-NULL. This is used
 by function.c and pretty printers.  */
   if (TYPE_METHODS (type))
 TYPE_METHODS (type) = error_mark_node;
@@ -5666,7 +5669,10 @@ find_decls_types_r (tree *tp, int *ws, v
  while (tem)
{
  if (TREE_CODE (tem) == FIELD_DECL
- || TREE_CODE (tem) == TYPE_DECL)
+ || (TREE_CODE (tem) == TYPE_DECL
+ && !DECL_IGNORED_P (tem)
+ && debug_info_level > DINFO_LEVEL_TERSE
+ && !is_redundant_typedef (tem)))
fld_worklist_push (tem, fld);
  tem = TREE_CHAIN (tem);
}
Index: tree.h
===
--- tree.h  (revision 231581)
+++ tree.h  (working copy)
@@ -5386,6 +5386,7 @@ extern void gt_pch_nx (tree &);
 extern void gt_pch_nx (tree &, gt_pointer_operator, void *);
 
 extern bool nonnull_arg_p (const_tree);
+extern bool is_redundant_typedef (const_tree);
 
 extern location_t
 set_source_range (tree expr, location_t start, location_t finish);
Index: dwarf2out.c
===
--- dwarf2out.c (revision 231581)
+++ dwarf2out.c (working copy)
@@ -3319,7 +3319,6 @@ static void gen_typedef_die (tree, dw_di
 static void gen_type_die (tree, dw_die_ref);
 static void gen_block_die (tree, dw_die_ref);
 static void decls_for_scope (tree, dw_die_ref);
-static inline int is_redundant_typedef (const_tree);
 static bool is_naming_typedef_decl (const_tree);
 static inline dw_die_ref get_context_die (tree);
 static void gen_namespace_die (tree, dw_die_ref);
@@ -21117,11