Re: [PATCH] Detect loops in find_comparison_args

[Paolo Bonzini]

Il 21/05/2012 19:21, Andrew Jenner ha scritto:
> Hi Paolo,
> 
> On 5/21/2012 10:12 AM, Paolo Bonzini wrote:
>> That's pretty heavy-weight.  Perhaps you can try the usual algorithm of
>> looking at x->next and x->next->next?
> 
> That would only detect cycles of length 1 and 2 though. While that would
> cover all the testcases we currently know about, I wanted to eliminate
> the entire pattern of hangs. Otherwise it's only a question of time
> until someone hits a cycle of length >= 3.

Sorry, I meant x = x->next and y = y->next->next.  That's the tortoise
and hare algorithm you referred to, I think.

If you extract the body of the loop into a new function
find_comparison_args_1, the code would not be much more complicated.

Paolo

Re: [RFC] PR 51712 -Wtype-limits should not trigger for enum constants

[Dodji Seketeli]

Manuel López-Ibáñez  a écrit:

> This seems a chicken and egg dilemma. Current full-time contributors
> don't have interest or time for this kind of infrastructure work. And
> potential contributors who have interest in using (and perhaps
> improving) this infrastructure prefer to invest their effort in other
> compilers that already has the infrastructure in place.

Well, you never know.  I'd like to believe that there are potential
contributors who value the need to extent the reach of what I would call
"the copyleft commons".  So let's not discourage them in advance.

Rather, I think a constructive way to follow is the one some of us (and
you in particular) have taken until now, which is to document what we
think is still needed (for instance in the wiki) and to keep doing what
we can.

-- 
Dodji

Re: [PR tree-optimization/52558]: RFC: questions on store data race

[Aldy Hernandez]

On 05/16/12 07:53, Richard Guenther wrote:

On Mon, 7 May 2012, Aldy Hernandez wrote:


[Sorry for the delay; I was on vacation.]

I am forgoing the load avoidance code altogether to simplify things. 
Thanks.



+  /* Emit the load code into the latch, so that we are sure it will
+ be processed after all dependencies.  */
+  latch_edge = loop_latch_edge (loop);

inserting code into the latch block is bad - the vectorizer will
be confused by non-empty latches.


The code as is on trunk inserts the load on the latch.  That's why I 
also inserted the supporting flag checking code there.  Do you want me 
to put the supporting code somewhere else?



Your ChangeLog mentions changes that are no longer necessary
(the target hook).


Whoops.  Fixed.



I didn't quite get the store order issue - we _do_ preserve store
ordering right now, do we?  So how come introducing the flags
change that?


The current scheme on trunk works because it inserts one load with 
gsi_insert_on_edge() and subsequent ones get appended correctly, whereas 
my patch has to split the edge (which happens at the top of the block), 
so subsequent code inserts happen in reverse order (at the top).  If I 
remember correctly, that is... I can look again and report if it's still 
unclear.


New patch attached.  Tested on x86-64 Linux.  No regressions.

Thanks.
Aldy
* cfg.c (alloc_aux_for_edge): Fix comment.
(alloc_aux_for_edge): Remove static.
* basic-block.h (alloc_aux_for_edge): Protoize.
* tree-ssa-loop-im.c (execute_sm_if_changed): New.
(execute_sm_if_changed_flag): New.
(execute_sm_if_changed_flag_set): New.
(execute_sm): Do not generate data races unless requested.
(tree_ssa_lim_initialize): Call alloc_aux_for_edges.
(tree_ssa_lim_finalize): Call free_aux_for_edges.

Index: testsuite/gcc.dg/tm/reg-promotion.c
===
--- testsuite/gcc.dg/tm/reg-promotion.c (revision 0)
+++ testsuite/gcc.dg/tm/reg-promotion.c (revision 0)
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-fgnu-tm -O2 -fdump-tree-lim1" } */
+
+/* Test that `count' is not written to unless p->data>0.  */
+
+int count;
+
+struct obj {
+int data;
+struct obj *next;
+} *q;
+
+void func()
+{
+  struct obj *p;
+  __transaction_atomic {
+for (p = q; p; p = p->next)
+  if (p->data > 0)
+   count++;
+  }
+}
+
+/* { dg-final { scan-tree-dump-times "MEM count_lsm.. count_lsm_flag" 1 "lim1" 
} } */
+/* { dg-final { cleanup-tree-dump "lim1" } } */
Index: testsuite/gcc.dg/pr52558-1.c
===
--- testsuite/gcc.dg/pr52558-1.c(revision 0)
+++ testsuite/gcc.dg/pr52558-1.c(revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "--param allow-store-data-races=0 -O2 -fdump-tree-lim1" } */
+
+/* Test that `count' is not written to unless p->data > 0.  */
+
+int count;
+
+struct obj {
+int data;
+struct obj *next;
+} *q;
+
+void func()
+{
+  struct obj *p;
+  for (p = q; p; p = p->next)
+if (p->data > 0)
+  count++;
+}
+
+/* { dg-final { scan-tree-dump-times "MEM count_lsm.. count_lsm_flag" 1 "lim1" 
} } */
+/* { dg-final { cleanup-tree-dump "lim1" } } */
Index: testsuite/gcc.dg/pr52558-2.c
===
--- testsuite/gcc.dg/pr52558-2.c(revision 0)
+++ testsuite/gcc.dg/pr52558-2.c(revision 0)
@@ -0,0 +1,23 @@
+/* { dg-do compile } */
+/* { dg-options "--param allow-store-data-races=0 -O2 -fdump-tree-lim1" } */
+
+/* Test that g_2 is not written to unless !g_1.  */
+
+int g_1 = 1;
+int g_2 = 0;
+
+int func_1(void)
+{
+ int l;
+ for (l = 0; l < 1234; l++)
+ {
+   if (g_1)
+ return l;
+   else
+ g_2 = 0;
+ }
+ return 999;
+}
+
+/* { dg-final { scan-tree-dump-times "MEM.*g_2_lsm_flag" 1 "lim1" } } */
+/* { dg-final { cleanup-tree-dump "lim1" } } */
Index: basic-block.h
===
--- basic-block.h   (revision 187729)
+++ basic-block.h   (working copy)
@@ -802,6 +802,7 @@ extern basic_block alloc_block (void);
 extern void alloc_aux_for_blocks (int);
 extern void clear_aux_for_blocks (void);
 extern void free_aux_for_blocks (void);
+extern void alloc_aux_for_edge (edge, int);
 extern void alloc_aux_for_edges (int);
 extern void clear_aux_for_edges (void);
 extern void free_aux_for_edges (void);
Index: tree-ssa-loop-im.c
===
--- tree-ssa-loop-im.c  (revision 187729)
+++ tree-ssa-loop-im.c  (working copy)
@@ -52,7 +52,7 @@ along with GCC; see the file COPYING3.
 }
  }
 
-   Where COND and INV are is invariants, but evaluating INV may trap or be
+   Where COND and INV are invariants, but evaluating INV may trap or be
invalid from some other reason if !COND.  This may be transformed to
 
if (cond)
@@ -1626,6 +1626,7

[Patch, libgfortran] Add FPU Support for powerpc

[rbmj]

Hi everyone,

This patch adds FPU support for powerpc on platforms that do not have 
glibc.  It is basically the same code as glibc has.  The motivation for 
this was that right now there is no fpu-target.h that works for 
powerpc-*-vxworks.


Again, 90% of this code comes directly from glibc.  But on vxworks 
targets there is no glibc.


I also patched the configure.host script in order to add this in.

Any opinions?

Robert Mason
>From f9449738730fa0d460a30affa826a157bf97cf62 Mon Sep 17 00:00:00 2001
From: rbmj 
Date: Mon, 21 May 2012 15:56:06 -0400
Subject: [PATCH 3/6] Add FPU Support for PPC on VxWorks

libgfortran/config/fpu-ppc.h:
	Started work on a fpu-target.h that will work for VxWorks on PPC.
	90% of it is stolen from glibc.  I just took the necessary pieces
	and added the right VxWorks glue.  I made as few changes to the
	glibc code as possible in order to avoid introducing a bug.
	The VxWorks part seems to be correct, but I don't have a whole
	lot of experience in this area and documentation is incomplete.

libgfortran/configure.host:
	This just adds fpu-ppc.h to the list of targets.  For some
	reason, my powerpc-wrs-vxworks is getting mis-identified as
	AIX, even though it does not have the functions, so I'll also
	have to work on a patch for configure.ac.  I'll check on that.
	Also, I put it before glibc so that glibc targets will get
	to use glibc and not rely on my cruft.
---
 libgfortran/config/fpu-ppc.h |  407 ++
 libgfortran/configure.host   |   11 ++
 2 files changed, 418 insertions(+), 0 deletions(-)
 create mode 100644 libgfortran/config/fpu-ppc.h

diff --git a/libgfortran/config/fpu-ppc.h b/libgfortran/config/fpu-ppc.h
new file mode 100644
index 000..f27df7f
--- /dev/null
+++ b/libgfortran/config/fpu-ppc.h
@@ -0,0 +1,407 @@
+/* FPU-related code for systems without glibc on powerpc.
+   Copyright (C) 1997, 1998, 1999, 2008 Free Software Foundation, Inc.
+
+This file is part of the GNU Fortran runtime library (libgfortran).
+This file incorporates code from the GNU C Library (glibc) under the GNU LGPL.
+
+Libgfortran 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 of the License, or (at your option) any later version.
+
+Libgfortran 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
+.  */
+   
+/* FPU Types/Constants: */
+
+/* Type representing exception flags.  */
+typedef unsigned int fexcept_t;
+
+/* Type representing floating-point environment.  We leave it as 'double'
+   for efficiency reasons (rather than writing it to a 32-bit integer). */
+typedef double fenv_t;
+
+/* We want to specify the bit pattern of the __fe_*_env constants, so 
+   pretend they're really `long long' instead of `double'.  */
+
+/* If the default argument is used we use this value.  */
+const unsigned long long __fe_dfl_env __attribute__ ((aligned (8))) = 
+0xfff8ULL;
+#define FE_DFL_ENV	((double*)(&__fe_dfl_env))
+
+/* Floating-point environment where all exceptions are enabled.  Note that
+   this is not sufficient to give you SIGFPE.  */
+const unsigned long long __fe_enabled_env __attribute__ ((aligned (8))) = 
+0xfff800f8ULL;
+# define FE_ENABLED_ENV	((double*)(&__fe_enabled_env))
+
+/* Floating-point environment with (processor-dependent) non-IEEE floating
+   point.  */
+const unsigned long long __fe_nonieee_env __attribute__ ((aligned (8))) = 
+0xfff80004ULL;
+# define FE_NONIEEE_ENV	((double*)(&__fe_nonieee_env))
+
+/* Provide __fe_mask_env and __fe_nomask_env */
+#ifdef __VXWORKS__
+
+/* These are based loosly off of glibc
+  
+   see also glibc/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/fe{,no}mask.c
+ */
+
+#include 
+#include 
+
+#if !defined (_PPC_MSR_FE0) || !defined (_PPC_MSR_FE1)
+#error FPU Support does not appear to exist on target platform
+#else
+
+const fenv_t *
+__fe_nomask_env(void)
+{
+  UINT32 msr = vxMsrGet();
+  msr |= _PPC_MSR_FE0 | _PPC_MSR_FE1;
+  vxMsrSet(msr);
+  return FE_ENABLED_ENV;
+}
+
+const fenv_t *
+__fe_nomask_env(void)
+{
+  UINT32 msr = vxMsrGet();
+  msr &= ~(_PPC_MSR_FE0 | _PPC_MSR_FE1);
+  vxMsrSet(msr);
+  return FE_DFL_ENV;
+}
+
+#endif
+
+#else
+
+/* VxWorks is the only OS that this header supports so far.  It would be trivial
+   to also support Linux on PowerP

[google/gcc-4_6] More Fission updates (issue6219049)

[Cary Coutant]

This patch is for the google/gcc-4_6 branch.

Fission improvements and bug fixes.  Adds new DW_OP_GNU_const_index to
handle TLS offsets in debug info.  Adds -gpubnames/-gno-pubnames options
to explicitly request .debug_pubnames/pubtypes sections.  Adds style
parameter to C/C++ pretty-printer so that we can get canonical pubnames
without affecting diagnostic output.

Bootstrapped and tested on x86_64.


2012-05-18  Sterling Augustine  
Cary Coutant  

include/
* dwarf2.h: Add DW_OP_GNU_const_index.

gcc/
* opts.c (finish_options): -gfission implies -gpubnames.
(common_handle_option): Pass empty arg string to set_debug_level.
* common.opt (gno-fission): New option.
(gfission): Remove JoinedOrMissing, add RejectNegative.
(gno-pubnames, gpubnames): New options.
* target.def (want_debug_pub_sections): Change default to false.
* gcc.c (check_live_switch): Check -g options for -gno- options.

* c-family/c-pretty-print.c (pp_c_specifier_qualifier_list): Add
support for gnu_v3 style.
* c-family/c-pretty-print.h (pp_c_flag_gnu_v3): New enum constant.
* cp/error.c (dump_decl): Add support for gnu_v3 style.
(decl_as_string): Likewise.
(lang_decl_name): Likewise.
* cp/cp-lang.c (cxx_dwarf_name): Likewise.
* cp/cp-tree.h (enum overload_flags): Add TFF_MATCH_GNU_V3_DEMANGLER.

* dwarf2out.c (dwarf_stack_op_name): Add DW_OP_GNU_const_index.
(size_of_loc_descr): Likewise.
(output_loc_operands): Likewise.
(output_loc_operands_raw): Likewise.
(want_pubnames): New macro.
(dw_addr_op): New function.
(new_addr_loc_descr): Call dw_addr_op.
(add_AT_pubnames): Add DW_AT_GNU_pubnames/pubtypes only if
generating .debug_pubnames/pubtypes sections.
(add_pubname_string): Check for -gpubnames option.
(add_pubname): Likewise.
(add_pubtype): Likewise.
(output_pubnames): Likewise.
(mem_loc_descriptor): Call new_addr_loc_desc for TLS vars.
(loc_list_from_tree): Likewise.
(output_addr_table): Handle DW_OP_GNU_const_index.  Add missing
newline.
(hash_loc_operands): Add DW_OP_GNU_const_index.
(compare_loc_operands): Likewise.

* testsuite/g++.old-deja/g++.pt/memtemp77.C: Revert earlier change
to expected results.
* testsuite/g++.dg/ext/pretty3.C: Likewise.
* testsuite/g++.dg/warn/Wuninitializable-member.C: Likewise.
* testsuite/g++.dg/warn/pr35711.C: Likewise.
* testsuite/g++.dg/pr44486.C: Likewise.


Index: include/dwarf2.h
===
--- include/dwarf2.h(revision 187751)
+++ include/dwarf2.h(working copy)
@@ -546,8 +546,9 @@ enum dwarf_location_atom
 DW_OP_GNU_uninit = 0xf0,
 DW_OP_GNU_encoded_addr = 0xf1,
 DW_OP_GNU_implicit_pointer = 0xf2,
-/* Extension for Fission.  See http://gcc.gnu.org/wiki/DebugFission.  */
+/* Extensions for Fission.  See http://gcc.gnu.org/wiki/DebugFission.  */
 DW_OP_GNU_addr_index = 0xfb,
+DW_OP_GNU_const_index = 0xfc,
 /* HP extensions.  */
 DW_OP_HP_unknown = 0xe0, /* Ouch, the same as GNU_push_tls_address.  */
 DW_OP_HP_is_value= 0xe1,
Index: gcc/c-family/c-pretty-print.c
===
--- gcc/c-family/c-pretty-print.c   (revision 187751)
+++ gcc/c-family/c-pretty-print.c   (working copy)
@@ -445,6 +445,9 @@ pp_c_specifier_qualifier_list (c_pretty_
 {
   const enum tree_code code = TREE_CODE (t);
 
+  if (!(pp->flags & pp_c_flag_gnu_v3) && TREE_CODE (t) != POINTER_TYPE)
+pp_c_type_qualifier_list (pp, t);
+
   switch (code)
 {
 case REFERENCE_TYPE:
@@ -489,7 +492,7 @@ pp_c_specifier_qualifier_list (c_pretty_
   pp_simple_type_specifier (pp, t);
   break;
 }
-  if (TREE_CODE (t) != POINTER_TYPE)
+  if ((pp->flags & pp_c_flag_gnu_v3) && TREE_CODE (t) != POINTER_TYPE)
 pp_c_type_qualifier_list (pp, t);
 }
 
Index: gcc/c-family/c-pretty-print.h
===
--- gcc/c-family/c-pretty-print.h   (revision 187751)
+++ gcc/c-family/c-pretty-print.h   (working copy)
@@ -30,7 +30,8 @@ along with GCC; see the file COPYING3.  
 typedef enum
   {
  pp_c_flag_abstract = 1 << 1,
- pp_c_flag_last_bit = 2
+ pp_c_flag_last_bit = 2,
+ pp_c_flag_gnu_v3 = 4
   } pp_c_pretty_print_flags;
 
 
Index: gcc/target.def
===
--- gcc/target.def  (revision 187751)
+++ gcc/target.def  (working copy)
@@ -2795,7 +2795,7 @@ DEFHOOKPOD
  "True if the @code{.debug_pubtypes} and @code{.debug_pubnames} sections\
  should be emitted.  These sections are not used on most platforms, and\
  in particular GDB does not use them.",
- bool, true)
+ bool, false)
 
 DEFHOOKPOD

[v3] Avoid -Wall warnings

[Paolo Carlini]

Hi,

tested x86_64-linux, committed.

Paolo.

//
2012-05-21  Paolo Carlini  

* testsuite/22_locale/num_put/put/char/9780-2.cc: Avoid -Wall warnings.
* testsuite/29_atomics/atomic/cons/49445.cc: Likewise.
* testsuite/29_atomics/atomic/operators/pointer_partial_void.cc:
* Likewise.
* testsuite/23_containers/unordered_map/observers.cc: Likewise.
* testsuite/23_containers/unordered_map/erase/1.cc: Likewise.
* testsuite/23_containers/unordered_multimap/erase/1.cc: Likewise.
* testsuite/23_containers/unordered_multimap/erase/2.cc: Likewise.
* testsuite/23_containers/unordered_multimap/insert/53115.cc: Likewise.
* testsuite/23_containers/unordered_multimap/observers.cc: Likewise.
* testsuite/23_containers/vector/debug/alloc_prop.cc: Likewise.
* testsuite/23_containers/unordered_set/observers.cc: Likewise.
* testsuite/23_containers/unordered_set/erase/1.cc: Likewise.
* testsuite/23_containers/unordered_multiset/erase/1.cc: Likewise.
* testsuite/23_containers/unordered_multiset/erase/2.cc: Likewise.
* testsuite/23_containers/unordered_multiset/insert/53115.cc: Likewise.
* testsuite/23_containers/unordered_multiset/insert/multiset_range.cc:
* Likewise.
* testsuite/23_containers/unordered_multiset/observers.cc: Likewise.
Index: testsuite/22_locale/num_put/put/char/9780-2.cc
===
--- testsuite/22_locale/num_put/put/char/9780-2.cc  (revision 187733)
+++ testsuite/22_locale/num_put/put/char/9780-2.cc  (working copy)
@@ -1,7 +1,7 @@
 // { dg-require-namedlocale "de_DE" }
 // { dg-require-namedlocale "es_ES" }
 
-// Copyright (C) 2004, 2005, 2009, 2011 Free Software Foundation, Inc.
+// Copyright (C) 2004, 2005, 2009, 2011, 2012 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
@@ -34,7 +34,7 @@
 
   locale l2 = locale("C");
   const numpunct& npunct2 = use_facet >(l2);
-  char c = npunct2.thousands_sep();
+  char c __attribute__((unused)) = npunct2.thousands_sep();
   string s = npunct2.grouping();
 
   ostringstream oss;
@@ -53,7 +53,7 @@
 
   locale l2 = locale("es_ES");
   const numpunct& npunct3 = use_facet >(l2);
-  char c = npunct3.thousands_sep();
+  char c __attribute__((unused)) = npunct3.thousands_sep();
   string s = npunct3.grouping();
 
   ostringstream oss;
@@ -72,7 +72,7 @@
 int main()
 {
   // Sanity check.
-  char c = npunct.thousands_sep();
+  char c __attribute__((unused)) = npunct.thousands_sep();
   string s = npunct.grouping();
 
   test01();
Index: testsuite/29_atomics/atomic/cons/49445.cc
===
--- testsuite/29_atomics/atomic/cons/49445.cc   (revision 187733)
+++ testsuite/29_atomics/atomic/cons/49445.cc   (working copy)
@@ -33,10 +33,10 @@
 int main()
 {
   std::atomic af(0.0f);
-  float non_af = af;
+  float non_af __attribute__((unused)) = af;
   
   std::atomic ae(tacos::sabor);
-  tacos non_ae = ae;
+  tacos non_ae __attribute__((unused)) = ae;
 
   return 0;
 }
Index: testsuite/29_atomics/atomic/operators/pointer_partial_void.cc
===
--- testsuite/29_atomics/atomic/operators/pointer_partial_void.cc   
(revision 187733)
+++ testsuite/29_atomics/atomic/operators/pointer_partial_void.cc   
(working copy)
@@ -26,8 +26,6 @@
 // atomic vs. explicitly specialized w/o operators, like atomic_bool?
 int main(void)
 {
-  // bool test __attribute__((unused)) = true;
-
   using namespace std;
 
   typedef int  value_type;
@@ -35,7 +33,7 @@
   value_type value = 42;
   value_type* p = &value;
   void* vp = p;
-  ptrdiff_t dist(0);
+  ptrdiff_t __attribute__((unused)) dist(0);
 
   atomic a(vp);
 
Index: testsuite/23_containers/unordered_map/observers.cc
===
--- testsuite/23_containers/unordered_map/observers.cc  (revision 187733)
+++ testsuite/23_containers/unordered_map/observers.cc  (working copy)
@@ -25,6 +25,6 @@
 {
   std::unordered_map um;
 
-  auto ke = um.key_eq();
-  auto h = um.hash_function();
+  auto ke __attribute__((unused)) = um.key_eq();
+  auto h __attribute__((unused)) = um.hash_function();
 }
Index: testsuite/23_containers/unordered_map/erase/1.cc
===
--- testsuite/23_containers/unordered_map/erase/1.cc(revision 187733)
+++ testsuite/23_containers/unordered_map/erase/1.cc(working copy)
@@ -2,7 +2,7 @@
 
 // 2010-02-10  Paolo Carlini   
 //
-// Copyright (C) 2010 Free Software Foundation, Inc.
+// Copyright (C) 2010, 2012 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribut

Re: [C++ RFH / Patch] PR 53159

[Paolo Carlini]

On 05/22/2012 12:53 AM, Jason Merrill wrote:

On 05/21/2012 04:18 PM, Paolo Carlini wrote:

-check_narrowing (type, init);
+check_narrowing (type, perform_implicit_conversion
+ (type, tinit, tf_none));


Any changes should go inside check_narrowing rather than outside.  I 
think the best fix if ftype is a class would be to find the implicit 
conversion sequence from ftype to type, then drop the second standard 
conversion sequence and just perform the user-defined conversion, then 
continue with the rest of check_narrowing.  The conversion part should 
be a new function in call.c.

Ok, thanks!

Paolo.

Re: [C++ RFH / Patch] PR 53159

[Jason Merrill]

On 05/21/2012 04:18 PM, Paolo Carlini wrote:

-   check_narrowing (type, init);
+   check_narrowing (type, perform_implicit_conversion
+(type, tinit, tf_none));


Any changes should go inside check_narrowing rather than outside.  I 
think the best fix if ftype is a class would be to find the implicit 
conversion sequence from ftype to type, then drop the second standard 
conversion sequence and just perform the user-defined conversion, then 
continue with the rest of check_narrowing.  The conversion part should 
be a new function in call.c.


Jason

Re: fix demangler crash - gdb PR 14065

[Jason Merrill]

OK.

Jason

[C++ testcase, committed as obvious] PR 53361

[Paolo Carlini]

Hi,

I added to the library testsuite this testcase filed as part of 
c++/53361, which works in mainline.


Thanks,
Paolo.

//
2012-05-21  Paolo Carlini  

PR c++/53361
* testsuite/23_containers/array/cons/53361.cc: New.
Index: testsuite/23_containers/array/cons/53361.cc
===
--- testsuite/23_containers/array/cons/53361.cc (revision 0)
+++ testsuite/23_containers/array/cons/53361.cc (revision 0)
@@ -0,0 +1,28 @@
+// { dg-options "-std=gnu++11 -Wno-missing-braces" }
+// { dg-do compile }
+//
+// Copyright (C) 2012 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
+// .
+
+#include 
+
+void function(std::array);
+
+int main()
+{
+  function({0,0,0});
+}

[PATCH, c++]: Fix PR 53441, [4.8 Regression] obj-c++.dg/ivar-invalid-type-1.mm ICE

[Uros Bizjak]

Hello!

As shown in the PR, ivar-invalid-type-1 ICEs in constructor_name_p,
due to accessor on NULL "type" argument.

The one-liner patch fixes the ICE by adding a guard that checks that
current_class_type is non-NULL before calling constructor_name_p.

2012-05-21  Uros Bizjak  

PR obj-c++/53441
* decl.c (grokdeclarator): Check that current_class_type is non-NULL
before calling constructor_name_p.

Patch was bootstrapped and regression tested on x86_64-pc-linux-gnu {,-m32}.

OK for mainline SVN?

Uros.
Index: decl.c
===
--- decl.c  (revision 187736)
+++ decl.c  (working copy)
@@ -9803,7 +9803,8 @@ grokdeclarator (const cp_declarator *declarator,
   clones.  */
DECL_ABSTRACT (decl) = 1;
}
-  else if (constructor_name_p (unqualified_id, current_class_type))
+  else if (current_class_type
+  && constructor_name_p (unqualified_id, current_class_type))
permerror (input_location, "ISO C++ forbids nested type %qD with same 
name "
   "as enclosing class",
   unqualified_id);

Fix PR53373

[Bernd Schmidt]

This is an ICE due to using single_set on a somewhat unconventional call 
pattern. To fix it, I've borrowed code from dse.c which was mentioned in 
the PR.


Bootstrapped & tested on x86_64-linux and committed.


Bernd
Index: gcc/ChangeLog
===
--- gcc/ChangeLog	(revision 187744)
+++ gcc/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2012-05-21  Bernd Schmidt  
+
+	PR rtl-optimization/53373
+	* caller-save.c (save_call_clobbered_regs): Look into a possible
+	PARALLEL manually rather than using single_set on a call insn.
+
 2012-05-21  Jakub Jelinek  
 
 	PR tree-optimization/53436
Index: gcc/caller-save.c
===
--- gcc/caller-save.c	(revision 187744)
+++ gcc/caller-save.c	(working copy)
@@ -872,11 +872,13 @@ save_call_clobbered_regs (void)
 		  && HARD_REGISTER_P (cheap)
 		  && TEST_HARD_REG_BIT (call_used_reg_set, REGNO (cheap)))
 		{
-		  rtx call_set = single_set (insn);
-		  rtx dest = SET_DEST (call_set);
-		  rtx pat = gen_rtx_SET (VOIDmode, cheap,
-	 copy_rtx (dest));
-		  chain = insert_one_insn (chain, 0, -1, pat);
+		  rtx dest, newpat;
+		  rtx pat = PATTERN (insn);
+		  if (GET_CODE (pat) == PARALLEL)
+		pat = XVECEXP (pat, 0, 0);
+		  dest = SET_DEST (pat);
+		  newpat = gen_rtx_SET (VOIDmode, cheap, copy_rtx (dest));
+		  chain = insert_one_insn (chain, 0, -1, newpat);
 		}
 	}
   last = chain;

[committed] Propagate volatile/read-only flags to COMPONENT_REFs created by omp-low.c (PR tree-optimization/53436)

[Jakub Jelinek]

Hi!

In the testcase in the PR (not valid OpenMP, so not adding it to the
testsuite) predictive commoning optimizes a while (!x); loop with
volatile x into if (!x) for (;;);, because, while the stmt has volatile
ops, the COMPONENT_REF created by omp-low.c doesn't have TREE_THIS_VOLATILE
set on it (the FIELD_DECL does as well as the type of COMPONENT_REF).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk and 4.7 branch.

2012-05-21  Jakub Jelinek  

PR tree-optimization/53436
* omp-low.c (omp_build_component_ref): New function.
(build_receiver_ref, build_sender_ref, create_task_copyfn): Use it.

--- gcc/omp-low.c.jj2012-05-17 08:40:45.0 +0200
+++ gcc/omp-low.c   2012-05-21 15:38:25.091066781 +0200
@@ -852,6 +852,19 @@ omp_copy_decl_1 (tree var, omp_context *
   return omp_copy_decl_2 (var, DECL_NAME (var), TREE_TYPE (var), ctx);
 }
 
+/* Build COMPONENT_REF and set TREE_THIS_VOLATILE and TREE_READONLY on it
+   as appropriate.  */
+static tree
+omp_build_component_ref (tree obj, tree field)
+{
+  tree ret = build3 (COMPONENT_REF, TREE_TYPE (field), obj, field, NULL);
+  if (TREE_THIS_VOLATILE (field))
+TREE_THIS_VOLATILE (ret) |= 1;
+  if (TREE_READONLY (field))
+TREE_READONLY (ret) |= 1;
+  return ret;
+}
+
 /* Build tree nodes to access the field for VAR on the receiver side.  */
 
 static tree
@@ -866,7 +879,7 @@ build_receiver_ref (tree var, bool by_re
 field = x;
 
   x = build_simple_mem_ref (ctx->receiver_decl);
-  x = build3 (COMPONENT_REF, TREE_TYPE (field), x, field, NULL);
+  x = omp_build_component_ref (x, field);
   if (by_ref)
 x = build_simple_mem_ref (x);
 
@@ -916,8 +929,7 @@ static tree
 build_sender_ref (tree var, omp_context *ctx)
 {
   tree field = lookup_sfield (var, ctx);
-  return build3 (COMPONENT_REF, TREE_TYPE (field),
-ctx->sender_decl, field, NULL);
+  return omp_build_component_ref (ctx->sender_decl, field);
 }
 
 /* Add a new field for VAR inside the structure CTX->SENDER_DECL.  */
@@ -6529,7 +6541,7 @@ create_task_copyfn (gimple task_stmt, om
  sf = (tree) n->value;
  sf = *(tree *) pointer_map_contains (tcctx.cb.decl_map, sf);
  src = build_simple_mem_ref_loc (loc, sarg);
- src = build3 (COMPONENT_REF, TREE_TYPE (sf), src, sf, NULL);
+ src = omp_build_component_ref (src, sf);
  t = build2 (MODIFY_EXPR, TREE_TYPE (*p), *p, src);
  append_to_statement_list (t, &list);
}
@@ -6552,9 +6564,9 @@ create_task_copyfn (gimple task_stmt, om
if (tcctx.cb.decl_map)
  sf = *(tree *) pointer_map_contains (tcctx.cb.decl_map, sf);
src = build_simple_mem_ref_loc (loc, sarg);
-   src = build3 (COMPONENT_REF, TREE_TYPE (sf), src, sf, NULL);
+   src = omp_build_component_ref (src, sf);
dst = build_simple_mem_ref_loc (loc, arg);
-   dst = build3 (COMPONENT_REF, TREE_TYPE (f), dst, f, NULL);
+   dst = omp_build_component_ref (dst, f);
t = build2 (MODIFY_EXPR, TREE_TYPE (dst), dst, src);
append_to_statement_list (t, &list);
break;
@@ -6575,14 +6587,14 @@ create_task_copyfn (gimple task_stmt, om
if (tcctx.cb.decl_map)
  sf = *(tree *) pointer_map_contains (tcctx.cb.decl_map, sf);
src = build_simple_mem_ref_loc (loc, sarg);
-   src = build3 (COMPONENT_REF, TREE_TYPE (sf), src, sf, NULL);
+   src = omp_build_component_ref (src, sf);
if (use_pointer_for_field (decl, NULL) || is_reference (decl))
  src = build_simple_mem_ref_loc (loc, src);
  }
else
  src = decl;
dst = build_simple_mem_ref_loc (loc, arg);
-   dst = build3 (COMPONENT_REF, TREE_TYPE (f), dst, f, NULL);
+   dst = omp_build_component_ref (dst, f);
t = lang_hooks.decls.omp_clause_copy_ctor (c, dst, src);
append_to_statement_list (t, &list);
break;
@@ -6601,14 +6613,14 @@ create_task_copyfn (gimple task_stmt, om
if (tcctx.cb.decl_map)
  sf = *(tree *) pointer_map_contains (tcctx.cb.decl_map, sf);
src = build_simple_mem_ref_loc (loc, sarg);
-   src = build3 (COMPONENT_REF, TREE_TYPE (sf), src, sf, NULL);
+   src = omp_build_component_ref (src, sf);
if (use_pointer_for_field (decl, NULL))
  src = build_simple_mem_ref_loc (loc, src);
  }
else
  src = decl;
dst = build_simple_mem_ref_loc (loc, arg);
-   dst = build3 (COMPONENT_REF, TREE_TYPE (f), dst, f, NULL);
+   dst = omp_build_component_ref (dst, f);
t = build2 (MODIFY_EXPR, TREE_TYPE (dst), dst, src);
append_to_statement_list (t, &list);
break;
@@ -6640,10 +6652,10 @@ create_task_copyfn (gimple task_stmt, om
  sf = (tree) n->value;
  sf = *(tree *) pointer_map_contains (tcctx.cb.decl_map, sf);
  src = build_simple_mem_ref_loc (loc, sarg);
- s

Re: Turn check macros into functions. (issue6188088)

[Tom Tromey]

> "Alexander" == Alexander Monakov  writes:

Alexander> Hm, isn't GDB's 'set unwindonsignal on' enough to fix it?
Alexander> It's useful to have that in your .gdbinit anyway, because the
Alexander> same issue arises when calling debug_* functions in cc1 from
Alexander> the debugger.

Yeah, why didn't I remember that?  I think it should suffice.
Thanks for the reminder.

Tom

Re: Turn check macros into functions. (issue6188088)

[Mike Stump]

On May 18, 2012, at 7:48 PM, Lawrence Crowl wrote:
> On 5/17/12, Mike Stump  wrote:
>> On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
 Reusing the compiler for this seems like the only way to go.
 But, we did look at using g++ to parse C++ expressions from gdb,
 and it was too slow :-(.  We're going to look again, at least to
 generate some bug reports if we can.
>>> 
>>> It's a tough problem, particularly as C/C++ and their compilers
>>> were not designed for a read-eval-print-loop environment.
>> 
>> This of course is trivial to do,
> 
> I do not think that word means what you think it means.  :-)

Excellent reference...  Yeah, well, just a little more work to do:

$ ./eval
extern "C" int printf(const char *...); int &k2 = *(int*)4294971592; void 
eval()\
 { printf("k is %d\n", k2); }
about to run
k is 42
done running, took 32540 usecs


Notice, this sucked a int k2 = 42; that was a variable inside the context in 
which I wanted a k2.  The nature of the variable is irrelevant, could be a 
stack variable, could be a global, a static top-level, all I need to know, is 
where it is (the address) and the type and I generate a binding stub for it 
into the context, and presto, complete access to most all variables.  This does 
make use of C++ to manage the variables in a slightly nicer way.  One either 
has to inject all variables and functions into the context into which the 
program fragment is compiled, or notice which variables and function are or 
might be used and inject just those.

I've seen ptype foo print the types of variables, so, it isn't far off, and 
certainly gdb knows about the symbol table and can figure out the addresses of 
those variables, right?!

Now, certainly one can find additional issues, and yes, there is a bit of work 
to get 100% reliability that we'd like from the scheme.  For example, packed 
structures would need work, as ptype isn't going to get that right from that 
start.  I think the functionality one would get would be good enough to start 
with, and in time, better support for things ptype doesn't get right would fix 
a certain class of problems.

So, what another 1000 lines to generate the context for the fragment... I guess 
finding references could be annoying, and the time required to generate and 
compile the entire context could be annoying...

Doing C++ would be harder, though, not quite for the reason you gave.

> I like the example, but it sidesteps the main problem, which is
> putting the expression in the context from which it was called.
> For instance if I stop in the middle of a function and type
> 
>  print foo->bar( a + b )
> 
> I need to find the find the variable names, lookup their types,

ptype a does the lookup for a, and finds the type, so that isn't hard, same 
with b and foo.  Harder would be to synthesize the context for the fragment to 
live in.  To do this and work with templates, you'd need the entire template 
bodies to be in the debug information and to output them when generating the 
context that might use them.

class A {
  foo() { }
}

when stopped in foo, one needs to generate:

class A {
  foo();
  __eval() { fragment }
}

and then call __eval(lookup("this"))...  The compiler does the overload 
resolution, the template instantiation and so on.  To ensure the compiler does 
name loookup right, one just needs to generate the context for that fragment 
carefully.

> do overload resolution, possibly do template instantiation, etc,
> all as if the compiler was in the scope defined for the line that
> the debugger is stopped at.  That's the hard part.

fix demangler crash - gdb PR 14065

[Tom Tromey]

GDB PR 14065 has an executable which causes gdb to crash.

It crashes trying to demangle a certain symbol (see the included test
case).  The standalone demangler doesn't crash here, but you can still
see the failure with valgrind.

I'm not sure this is the proper fix, but it seemed correct, and it does
avoid the crash.

Ok?

Tom

2012-05-21  Tom Tromey  

http://sourceware.org/bugzilla/show_bug.cgi?id=14065
* testsuite/demangle-expected: Add regression test.
* cp-demangle.c (d_find_pack): Return NULL for
DEMANGLE_COMPONENT_UNNAMED_TYPE.

diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c
index d95b56c..27cc323 100644
--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -3715,6 +3715,7 @@ d_find_pack (struct d_print_info *dpi,
 case DEMANGLE_COMPONENT_SUB_STD:
 case DEMANGLE_COMPONENT_CHARACTER:
 case DEMANGLE_COMPONENT_FUNCTION_PARAM:
+case DEMANGLE_COMPONENT_UNNAMED_TYPE:
   return NULL;
 
 case DEMANGLE_COMPONENT_EXTENDED_OPERATOR:
diff --git a/libiberty/testsuite/demangle-expected 
b/libiberty/testsuite/demangle-expected
index d489692..58c1368 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -4266,3 +4266,7 @@ foo
 _Z1fIKFvvES0_Evv
 void f()
 f
+#
+--format=gnu-v3
+_ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRNS2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateILNS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6ParserIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ_5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_10Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_ELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4TypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_
+modc::parser::ParserRef::Parser::Style> 
>
 > >::InputType, 
modc::parser::MaybeRef&&)#21}>::Type, 
modc::parser::RepeatedParser::Parser::Style> 
>::Parser > 
>::Parser::Annotation::Relationship> >, 
modc::parser::ExactElementParser> >, 
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, 
modc::Maybe&&)#21}> >, 
false>::Parser > > > >::Type, 
modc::parser::RepeatedParser::Parser::Style> 
>::Parser > 
>::Parser::Annotation::Relationship> >, 
modc::parser::ExactElementParser> >, 
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, 
modc::Maybe&&)#21}> >, 
false>
 
>::Parser::Style> > > >::Type, 
modc::parser::RepeatedParser::Parser::Style> 
>::Parser > 
>::Parser::Annotation::Relationship> >, 
modc::parser::ExactElementParser> >, 
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, 
modc::Maybe&&)#21}> >, 
false>,
 
modc::astParser::LocatedParser
 > > > >::Type, 
modc::parser::RepeatedParser::Parser::Style> 
>::Parser > 
>::Parser::Annotation::Relationship> >, 
modc::parser::ExactElementParser> >, 
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, 
modc::Maybe&&)#21}> >, 
false>::Parser::Style> 
>::Parser > 
>::Parser::Annotation::Relationship> >, 
modc::parser::ExactElementParser> >, 
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, 
modc::Maybe&&)#21}> >, false> >::Type> 
modc::parser::sequence
 >, 
modc::parser::OptionalParser::Parser > > >, 
modc::astParser::LocatedParser
 
>::Parser::Style> > >, 
modc::parser::SequenceParser,
 
modc::astParser::LocatedParser
 > > >, 
modc::parser::RepeatedParser::Parser::Style> 
>::Parser > 
>::Parser::Annotation::Relationship> >, 
modc::parser::ExactElementParser> >, 
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, 
modc::Maybe&&)#21}> >, false> 
>(modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser, 
modc::Maybe&&)#21}&&, 
(modc::parser::ExtractParserType
 > >&&)...)

Re: [patch, libitm] fix __cxa_end_catch declaration

[Richard Henderson]

On 05/21/12 12:59, Patrick Marlier wrote:
> 2012-05-21  Patrick Marlier  
> 
> * eh_cpp.cc: Fix __cxa_end_catch declaration.

Ok.


r~

[C++ RFH / Patch] PR 53159

[Paolo Carlini]

Hi,

this PR is about the missing -Wnarrowing warning for:

struct X
{
  constexpr operator int() { return __INT_MAX__; }
};

signed char c { X{} };

The core issue seems pretty simple: check_narrowing, called by 
check_initializer, cannot handle something as complex as a class type 
with a type conversion operator (essentially it can only handle scalars) 
and gives up. Thus, it seems to me that one way or the other we have to 
help it. A simple, hackish, patch like the attached works on the 
testcase and passes the C++ testsuite. Is it far from what we want to do 
here?


Thanks!
Paolo.


Index: decl.c
===
--- decl.c  (revision 187733)
+++ decl.c  (working copy)
@@ -5557,9 +5557,11 @@ check_initializer (tree decl, tree init, int flags
}
  else
{
+ tree tinit = init;
  init = reshape_init (type, init, tf_warning_or_error);
  if (SCALAR_TYPE_P (type))
-   check_narrowing (type, init);
+   check_narrowing (type, perform_implicit_conversion
+(type, tinit, tf_none));
}
}
 

Re: [C++ Patch] Produce canonical names for debug info without changing normal pretty-printing (issue6215052)

[Sterling Augustine]

On Wed, May 16, 2012 at 1:03 PM, Sterling Augustine
 wrote:
> This patch adds new flags and defines such that the C++ decl pretty printer
> prints both canonical dwarf names for decls without perturbing normal error
> message output.
>
> It addresses the issues with the earlier patches submitted as:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00516.html
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00512.html
>
> Which are withdrawn.
>
> This patch requires no changes to the testsuite and does not produce
> visible changes to gcc's output except to dwarf consumers, which will now
> all agree on the names of functions.
>
> Tested with a full bootstrap.
>
> OK for mainline?
>
> Sterling
>
>
>
> 2012-05-16   Sterling Augustine  
>
>        * gcc/c-family/c-pretty-print.h (pp_c_flag_gnu_v3): New enumerator.
>        * gcc/c-family/c-pretty-print.c (pp_c_specifier_qualifier_list): Check
>        it at both the start and end of the function.
>        * gcc/cp/cp-tree.h (TFF_MATCH_GNU_V3_DEMANGLER): Define and comment.
>        * gcc/cp/error.c (dump_decl): Print appropriate string for anonymous
>        namespace based on pp_c_flag_gnu_v3.
>        (decl_as_string): Set cxx_pp->flags based on 
> TFF_MATCH_GNU_V3_DEMANGLER.
>        (lang_decl_name): Handle unnamed namespace decls.
>        * gcc/cp/cp-lang.c (cxx_dwarf_name): Call decl_as_string for namespace
>        decls.
>
> Index: gcc/c-family/c-pretty-print.c
> ===
> --- gcc/c-family/c-pretty-print.c       (revision 187603)
> +++ gcc/c-family/c-pretty-print.c       (working copy)
> @@ -446,8 +446,9 @@ pp_c_specifier_qualifier_list (c_pretty_printer *p
>  {
>   const enum tree_code code = TREE_CODE (t);
>
> -  if (TREE_CODE (t) != POINTER_TYPE)
> +  if (!(pp->flags & pp_c_flag_gnu_v3) && TREE_CODE (t) != POINTER_TYPE)
>     pp_c_type_qualifier_list (pp, t);
> +
>   switch (code)
>     {
>     case REFERENCE_TYPE:
> @@ -494,6 +495,8 @@ pp_c_specifier_qualifier_list (c_pretty_printer *p
>       pp_simple_type_specifier (pp, t);
>       break;
>     }
> +  if ((pp->flags & pp_c_flag_gnu_v3) && TREE_CODE (t) != POINTER_TYPE)
> +    pp_c_type_qualifier_list (pp, t);
>  }
>
>  /* parameter-type-list:
> Index: gcc/c-family/c-pretty-print.h
> ===
> --- gcc/c-family/c-pretty-print.h       (revision 187603)
> +++ gcc/c-family/c-pretty-print.h       (working copy)
> @@ -30,7 +30,8 @@ along with GCC; see the file COPYING3.  If not see
>  typedef enum
>   {
>      pp_c_flag_abstract = 1 << 1,
> -     pp_c_flag_last_bit = 2
> +     pp_c_flag_last_bit = 2,
> +     pp_c_flag_gnu_v3 = 4
>   } pp_c_pretty_print_flags;
>
>
> Index: gcc/cp/error.c
> ===
> --- gcc/cp/error.c      (revision 187603)
> +++ gcc/cp/error.c      (working copy)
> @@ -1028,7 +1028,12 @@ dump_decl (tree t, int flags)
>            dump_scope (CP_DECL_CONTEXT (t), flags);
>          flags &= ~TFF_UNQUALIFIED_NAME;
>          if (DECL_NAME (t) == NULL_TREE)
> -           pp_cxx_ws_string (cxx_pp, M_("{anonymous}"));
> +            {
> +              if (!(pp_c_base (cxx_pp)->flags & pp_c_flag_gnu_v3))
> +                pp_cxx_ws_string (cxx_pp, M_("{anonymous}"));
> +              else
> +                pp_cxx_ws_string (cxx_pp, M_("(anonymous namespace)"));
> +            }
>          else
>            pp_cxx_tree_identifier (cxx_pp, DECL_NAME (t));
>        }
> @@ -2561,6 +2566,8 @@ decl_as_string (tree decl, int flags)
>  {
>   reinit_cxx_pp ();
>   pp_translate_identifiers (cxx_pp) = false;
> +  if (flags & TFF_MATCH_GNU_V3_DEMANGLER)
> +    pp_c_base (cxx_pp)->flags |= pp_c_flag_gnu_v3;
>   dump_decl (decl, flags);
>   return pp_formatted_text (cxx_pp);
>  }
> @@ -2596,6 +2603,9 @@ lang_decl_name (tree decl, int v, bool translate)
>
>   if (TREE_CODE (decl) == FUNCTION_DECL)
>     dump_function_name (decl, TFF_PLAIN_IDENTIFIER);
> +  else if ((DECL_NAME (decl) == NULL_TREE)
> +           && TREE_CODE (decl) == NAMESPACE_DECL)
> +    dump_decl (decl, TFF_PLAIN_IDENTIFIER);
>   else
>     dump_decl (DECL_NAME (decl), TFF_PLAIN_IDENTIFIER);
>
> Index: gcc/cp/cp-lang.c
> ===
> --- gcc/cp/cp-lang.c    (revision 187603)
> +++ gcc/cp/cp-lang.c    (working copy)
> @@ -120,8 +120,14 @@ cxx_dwarf_name (tree t, int verbosity)
>   if (verbosity >= 2)
>     return decl_as_string (t,
>                           TFF_DECL_SPECIFIERS | TFF_UNQUALIFIED_NAME
> -                          | TFF_NO_OMIT_DEFAULT_TEMPLATE_ARGUMENTS);
> +                          | TFF_NO_OMIT_DEFAULT_TEMPLATE_ARGUMENTS
> +                           | TFF_MATCH_GNU_V3_DEMANGLER);
>
> +  /* decl_as_string handles namespaces--especially anonymous ones--more
> +     appropriately for debugging than cxx_printable_name.  But
> +     cxx_printable_name handles templates and global ctors an

[patch, libitm] fix __cxa_end_catch declaration

[Patrick Marlier]

Hi,

__cxa_end_catch declaration was wrong. No functional change just 
correctness.


Ok for trunk?
Thanks.

2012-05-21  Patrick Marlier  

* eh_cpp.cc: Fix __cxa_end_catch declaration.

--
Patrick Marlier
Index: eh_cpp.cc
===
--- eh_cpp.cc	(revision 187371)
+++ eh_cpp.cc	(working copy)
@@ -36,14 +36,14 @@ extern "C" {
 extern void *__cxa_allocate_exception (size_t) WEAK;
 extern void __cxa_throw (void *, void *, void *) WEAK;
 extern void *__cxa_begin_catch (void *) WEAK;
-extern void *__cxa_end_catch (void) WEAK;
+extern void __cxa_end_catch (void) WEAK;
 extern void __cxa_tm_cleanup (void *, void *, unsigned int) WEAK;
 
 #if !defined (HAVE_ELF_STYLE_WEAKREF) && !defined (__MACH__)
 void *__cxa_allocate_exception (size_t) { return NULL; }
 void __cxa_throw (void *, void *, void *) { return; }
 void *__cxa_begin_catch (void *) { return NULL; }
-void *__cxa_end_catch (void) { return NULL; }
+void __cxa_end_catch (void) { return; }
 void __cxa_tm_cleanup (void *, void *, unsigned int) { return; }
 void _Unwind_DeleteException (_Unwind_Exception *) { return; }
 #endif /* HAVE_ELF_STYLE_WEAKREF */

[PATCH, i386]: Cleanup ix86_output_operand

[Uros Bizjak]

Hello!

A cleanup to make ix86_output_operand more maintainable:

- merge condition code handling where appropriate
- change a couple of operands of put_condition_code to bool
- fix a couple of error reporting strings (COMPARISON_P does not check
for constant)
- move operand size checking cases together,
- move condition code handling together

No functional changes.

2012-05-21  Uros Bizjak  

* config/i386/i386.c (put_condition_code): Change "reverse" and "fp"
arguments to bool.
(ix86_print_operand) : Look at mode size of the operand.
Do not print '.' here.  Output operand lossage error for unhandled
sizes.  Move.
: Move.
: Ditto.
: Ditto.
: Hardcode "code" argument into error strings.
: Ditto.
: Merge AVX and non-AVX codes.
: Merge.  Fix error string.
Update call to put_condition_code.

Tested on x86_64-pc-linux-gnu {,-m32}, also with
HAVE_AS_IX86_CMOV_SUN_SYNTAX (until bootstrap breaks due to invalid
generated asm).

Committed to mainline SVN.

Uros.
Index: i386.c
===
--- i386.c  (revision 187726)
+++ i386.c  (working copy)
@@ -13610,8 +13610,8 @@ ix86_find_base_term (rtx x)
 }
 
 static void
-put_condition_code (enum rtx_code code, enum machine_mode mode, int reverse,
-   int fp, FILE *file)
+put_condition_code (enum rtx_code code, enum machine_mode mode, bool reverse,
+   bool fp, FILE *file)
 {
   const char *suffix;
 
@@ -13932,8 +13932,8 @@ get_some_local_dynamic_name (void)
C -- print opcode suffix for set/cmov insn.
c -- like C, but print reversed condition
F,f -- likewise, but for floating-point.
-   O -- if HAVE_AS_IX86_CMOV_SUN_SYNTAX, expand to "w.", "l." or "q.",
-otherwise nothing
+   O -- if HAVE_AS_IX86_CMOV_SUN_SYNTAX, print the opcode suffix for
+   the size of the current operand, otherwise nothing.
R -- print the prefix for register names.
z -- print the opcode suffix for the size of the current operand.
Z -- likewise, with special suffixes for x87 instructions.
@@ -13974,22 +13974,6 @@ ix86_print_operand (FILE *file, rtx x, int code)
 {
   switch (code)
{
-   case '*':
- if (ASSEMBLER_DIALECT == ASM_ATT)
-   putc ('*', file);
- return;
-
-   case '&':
- {
-   const char *name = get_some_local_dynamic_name ();
-   if (name == NULL)
- output_operand_lossage ("'%%&' used without any "
- "local dynamic TLS references");
-   else
- assemble_name (file, name);
-   return;
- }
-
case 'A':
  switch (ASSEMBLER_DIALECT)
{
@@ -14054,6 +14038,33 @@ ix86_print_operand (FILE *file, rtx x, int code)
putc ('t', file);
  return;
 
+   case 'O':
+#ifdef HAVE_AS_IX86_CMOV_SUN_SYNTAX
+ if (ASSEMBLER_DIALECT != ASM_ATT)
+   return;
+
+ switch (GET_MODE_SIZE (GET_MODE (x)))
+   {
+   case 2:
+ putc ('w', file);
+ break;
+  
+   case 4:
+ putc ('l', file);
+ break;
+
+   case 8:
+ putc ('q', file);
+ break;
+
+   default:
+ output_operand_lossage
+   ("invalid operand size for operand code 'O'");
+ return;
+   }
+#endif
+ return;
+
case 'z':
  if (GET_MODE_CLASS (GET_MODE (x)) == MODE_INT)
{
@@ -14081,14 +14092,14 @@ ix86_print_operand (FILE *file, rtx x, int code)
 
default:
  output_operand_lossage
-   ("invalid operand size for operand code '%c'", code);
+   ("invalid operand size for operand code 'z'");
  return;
}
}
 
  if (GET_MODE_CLASS (GET_MODE (x)) == MODE_FLOAT)
warning
- (0, "non-integer operand used with operand code '%c'", code);
+ (0, "non-integer operand used with operand code 'z'");
  /* FALLTHRU */
 
case 'Z':
@@ -14151,12 +14162,12 @@ ix86_print_operand (FILE *file, rtx x, int code)
  else
{
  output_operand_lossage
-   ("invalid operand type used with operand code '%c'", code);
+   ("invalid operand type used with operand code 'Z'");
  return;
}
 
  output_operand_lossage
-   ("invalid operand size for operand code '%c'", code);
+   ("invalid operand size for operand code 'Z'");
  return;
 
case 'd':
@@ -14181,179 +14192,160 @@ ix86_print_operand (FILE *file, rtx x, int code)
}
  return;
 
+   case 'Y':
+ switch (GET_CODE (x))
+   {
+   case NE:
+ fputs ("neq", file);
+ break;

cine castiga

[cramer]

http://www.youtube.com/watch?feature=youtu.be&hl=ro&v=_Sl3Ox7RMnE
 To unsubscribe please send email to unsubscr...@cc.psd-prahova.ro

Re: [RFA] PowerPC e5500 and e6500 cores support

[David Edelsohn]

> Regarding the implementation of popcntb, popcntd, and cmpb. Gcc has
> dedicated masks on target_flags for them, but due to shortage of bits,
> those masks controls more than the name implies.

The target flag bits control more than the name implies, but the bits
correspond to published ISA levels.

The Freescale localized parts of the patch (new scheduling
descriptions) are okay, modulo Mike's comments. We also need to
coordinate on which instructions really are part of "Altivec2" and
what name will be used for that feature.


However, what concerns me, as Mike commented as well, is this patch
adds support for a processor that does not conform to any particular
ISA -- it does not implement some instructions and adds other unique
instructions. Unlike the "SPE" instructions, these are not completely
orthogonal from the rest of the PowerPC architecture. SPE added a
separate set of SIMD instructions and merged the GPR and FPR register
sets, but left most other things alone.

The earlier addition of E500 support was a mess because the concept of
architecture and processor were not clearly defined and delineated.
This has been a maintenance nightmare for all other PowerPC
maintainers dealing with the irregularities introduced for Freescale's
non-conforming processor, especially when additional features were
added in the next processor.

At least the previous irregularities were local to Freescale's ISA
extensions. This latest processor modifies the meaning of the ISA
definitions. Changing macros that designate architectures to test for
specific processors is reverting to an approach of bad software
design. If the Freescale parts only has complete support for an
earlier ISA, that is the one it needs to use. If it implements more
"Altivec2" instructions than defined, users can access those with
inlined assembly.

Freescale can distribute compilers with whatever additional patches it
wants to include, but the cost-benefit ratio to the rest of the
PowerPC community and the rest of the GCC community is past
unreasonable.

In other words, this new processor and the latest patches mean that a
Linux distributor cannot build an application for a particular
revision of the ISA and have it work across both IBM and Freescale
processors. That is not the meaning of ISA and is going to confuse
users, developers and distros. The Freescale parts need to present
themselves as the lowest-common denominator of the processor ISA they
supports.

Thanks, David

On Fri, May 18, 2012 at 3:16 PM, Edmar  wrote:
> Michael,
>
> Thanks for reviewing the patch and all the suggestions.
> I have some questions / comments bellow.
>
> Regards,
> Edmar
>
>
>
> On 05/17/2012 06:16 PM, Michael Meissner wrote:
>>>
>>> In the patch I minimized the number of changes, while not adding
>>> any new mask to target_flags.
>>
>> While we may get some bits back when the original Power flags are removed,
>> it
>> may be time to bite the bullet and have two separate target flags like x86
>> did,
>> because we keep running out of bits.
>>
>
> I agree. But, wouldn't be better to have the e6500 patch separated from this
> ?
> Either way, I would like to collaborate towards having 2 target flags.
>
>> Some comments from looking at the patches:
>>
>> A meta-issue is the name of the Freescale extensions.  The problem of
>> calling
>> it Altivec2 is we get into a situation like AMD and Intel have had over
>> what
>> the next SSE revision is.  Perhaps using a different name than Altivec2.
>>  David
>> probably needs to weigh in on this.
>
>
> That name is my fault. Internally Freescale is not giving this feature any
> new name.
> Our design manual has a table that lists the differences between the
> original
> Altivec and the current Altivec, and that is it.
>
> I thought it would be better to have independent control of the
> instructions,
> instead of just throwing everything under __ALTIVEC__
> Perhaps we should keep the control that the "-m..." option does and get rid
> of the
>  __ALTIVEC2__  definition ?
>
> Regarding the spelling (-maltivec2 or other name), we do not have
> any position on it.
>
>> What is the rationale for changing modes for stv* from V4SI to V16QI, and
>> is it
>> safe?  I'm just worried about existing code, that suddenly stops working.
>
>
> Understandable. Right now there is a type mismatch. The RTL is
> V4SI and the builtins are emitted with V16QI, causing an ICE.
> I traced that ICE all the way back to 4.4.
>
> BTW, the only locations that uses V4SI are the ones I changed...
>
>> In rs6000.c, I think gpopt/mfocrf should only be cleared if the user did
>> not
>> explicitly set those options.  If you want to issue an error if the user
>> explicitly set the options for the new cpus, that is fine, but I don't
>> like the
>> backend to silently change options that were explicitly set on the command
>> line.
>
>
> Thanks for catching this. I will add "target_flags_explicit" to the logic.
>
>> In terms of the comments about the insns being in I

__builtin_clz for m68k

[Andreas Schwab]

This implements clzsi2 for m68k.  It also fixes a bug in the Coldfire
expansion: ff1 (like bfffo) sets ccr from the source operand.  Tested on
m68k-linux and installed on trunk.

Andreas.

* config/m68k/m68k.md (*clzsi2_cf): Renamed from clzsi2.  Call
CC_STATUS_INIT.
(clzsi2): New expander.
(*clzsi2_68k): New insn.
* config/m68k/m68k.h: Update comment about
CLZ_DEFINED_VALUE_AT_ZERO.

diff --git a/gcc/config/m68k/m68k.h b/gcc/config/m68k/m68k.h
index 0a390d0..b8d8d9c 100644
--- a/gcc/config/m68k/m68k.h
+++ b/gcc/config/m68k/m68k.h
@@ -1,6 +1,6 @@
 /* Definitions of target machine for GCC for Motorola 680x0/ColdFire.
Copyright (C) 1987, 1988, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
 
 This file is part of GCC.
@@ -698,7 +698,7 @@ __transfer_from_trampoline ()   
\
 
 #define TRULY_NOOP_TRUNCATION(OUTPREC, INPREC) 1
 
-/* The ColdFire FF1 instruction returns 32 for zero. */
+/* The 68020 BFFFO and ColdFire FF1 instructions return 32 for zero. */
 #define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) ((VALUE) = 32, 1)
 
 #define STORE_FLAG_VALUE (-1)
diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md
index 8fc81b5..0225b7e 100644
--- a/gcc/config/m68k/m68k.md
+++ b/gcc/config/m68k/m68k.md
@@ -4467,12 +4467,33 @@
 
 ;; bit indexing instructions
 
+(define_expand "clzsi2"
+  [(set (match_operand:SI 0 "register_operand" "")
+(clz:SI (match_operand:SI 1 "general_operand" "")))]
+  "ISA_HAS_FF1 || (TARGET_68020 && TARGET_BITFIELD)"
+{
+  if (ISA_HAS_FF1)
+operands[1] = force_reg (SImode, operands[1]);
+})
+
+(define_insn "*clzsi2_68k"
+  [(set (match_operand:SI 0 "register_operand" "=d")
+(clz:SI (match_operand:SI 1 "general_operand" "do")))]
+  "TARGET_68020 && TARGET_BITFIELD"
+{
+  CC_STATUS_INIT;
+  return "bfffo %1{#0:#0},%0";
+})
+
 ;; ColdFire ff1 instruction implements clz.
-(define_insn "clzsi2"
+(define_insn "*clzsi2_cf"
   [(set (match_operand:SI 0 "register_operand" "=d")
(clz:SI (match_operand:SI 1 "register_operand" "0")))]
   "ISA_HAS_FF1"
-  "ff1 %0"
+{
+  CC_STATUS_INIT;
+  return "ff1 %0";
+}
   [(set_attr "type" "ext")])
 
 ;; one complement instructions
-- 
1.7.10.2

-- 
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: [Dwarf Patch] Improve pubnames and pubtypes generation. (issue 6197069)

[Cary Coutant]

>> The entire motivation for this patch, including the proposed new
>> attributes is at:
>>
>> http://gcc.gnu.org/wiki/DebugFission
>>
>> In particular, the section titled, "Building a GDB Index".
>
> OK, I've read that section and I still don't understand why the consumer
> would need a pointer from the CU to the pubnames section to build an index.
>  If we're looking for something by name, we go from pubnames to the CU.  If
> we're looking at the CU because we're in a function body, presumably we need
> to parse most of it anyway; is there really a significant benefit to having
> a separate "what names does this CU define" attribute?  The index is all
> name->die lookup, isn't it?

The DW_AT_GNU_pubnames/pubtypes attributes serve two purposes: (1)
they let the linker know which CUs have pubnames & pubtypes sections,
and (2) they let us know that the pubnames and pubtypes are "reliable"
(relative to the incomplete sections that GCC has generated in the
past). When building the .gdb_index, the linker starts with the top
compile_unit DIE of the CU. If there are pubnames/pubtypes attributes,
it can go read those sections; otherwise, it needs to parse the whole
DIE tree (slow) to extract the information needed for .gdb_index. It
would be possible to use the pointer from the pubnames section to the
CU, but that's a reverse pointer, and it would take time to set up the
links to figure out which pubnames/pubtypes sections go with which
CUs.


> I'm also puzzled by what the proposal says about .debug_types.  Why would a
> pubtypes entry point to a CU that doesn't actually have a definition of the
> type?  Is it so that the consumer knows which .dwo to look in?  Perhaps we
> could do something else with the sig8 instead of pointing to the wrong unit.

Yes, it's to find the .dwo. I never did anything to accomodate
.debug_types sections with .debug_pubtypes -- probably a more
substantial change to the format is in order, but I wanted to save
that for what I expect to be a complete revamping of the accelerated
lookup tables in DWARF.


>>> The DWARF standard says that pubnames is for names with global scope;
>>> this
>>> change would add namespace-scope statics as well.
>>
>> I am matching what gold and gdb do when building the gdb index.
>
> Ah.  If that's what GDB wants I guess it makes sense, but I'd like to see
> reaction from the committee to this particular aspect.  I haven't noticed it
> come up in the committee discussion of Fission.

We had some discussion in the DWARF workgroup during the DWARF 4
development about what should go into pubnames and pubtypes, but
didn't really settle on any specific wording change for the standard.
I think it was generally agreed that it's ultimately a
quality-of-implementation issue where the producer and consumer need
to agree on what's useful there. For the purposes of a debugger, the
only thing that really make sense is to have a name-to-CU index that
indexes all the names that a user might type at the user interface.
Without the fixes we're putting in here, the pubnames section has been
essentially useless, and has been ignored entirely by gdb -- to the
point that a change went in a year or so ago to disable the section by
default except for Darwin.

I anticipate further discussion of accelerated lookup in the DWARF 5
discussions, and I expect these tables to get a major overhaul. Until
then, I think it's reasonable to make use of them as best we can
without making any major structural changes.


>>> Why do we need pubtype entries for base types?
>>
>> Same as above--to make these addable to the index, which in turn makes
>> gdb faster. I'll add this to the note to Cary.
>
> Really?  GDB wants to look up built-in types in the index rather than just
> knowing what "int" means?

It doesn't actually always mean the same thing, though. It might be
less surprising if you ask that about some other base type like
"double" (and consider that GCC has options like -fshort-double).
Also, GDB can narrow the set of CUs that it has to read sometimes by
knowing which CUs actually contain a declaration of a given base type
(again, it's easier to see the advantage for "double" than for "int").


>>> Why bypass the DECL_NAMELESS check?
>>
>> So objects within anonymous namespaces get pubnames:
>>
>> namespace { void some_function...
>
> Hmm, it would give the anonymous namespace itself a pubname, but I don't see
> how it would make any difference to objects within the namespace.

The items within an anonymous namespace need to be indexed so that a
GDB user can just type "some_function" instead of "(anonymous
namespace)::some_function".

-cary

Re: [RFA] leb128.h: New file.

[Ian Lance Taylor]

Doug Evans  writes:

> long long (+ unsigned long long) is ok by me.
> I could also rename the functions to read_uleb128_to_ull (unsigned
> long long) to allow for a day if/when someone wants
> read_uleb128_to_uint64.  Ok?

Sounds good to me.

Thanks.

Ian

[patch] committed: mark blocks as in transaction

[Aldy Hernandez]

As discussed on the "RFC: questions on store data race" thread.  This 
patch increases the granularity of transactionness from the gimple 
statement to the basic block containing it.


Pre-approved and committed.

Tested on x86-64 Linux.

Thanks.
* gimple.h (gimple_set_in_transaction): Remove.
(gimple_in_transaction): Look in BB instead.
(gimple_statement_base): Remove in_transaction field.
* basic-block.h (enum bb_flags): Add BB_IN_TRANSACTION.
* trans-mem.c (compute_transaction_bits): Place transaction bit
information into basic blocks.

Index: gimple.h
===
--- gimple.h(revision 187728)
+++ gimple.h(working copy)
@@ -179,11 +179,6 @@ struct GTY(()) gimple_statement_base {
   /* Nonzero if this statement contains volatile operands.  */
   unsigned has_volatile_ops: 1;
 
-  /* Nonzero if this statement appears inside a transaction.  This bit
- is calculated on de-mand and has relevant information only after
- it has been calculated with compute_transaction_bits.  */
-  unsigned in_transaction  : 1;
-
   /* The SUBCODE field can be used for tuple-specific flags for tuples
  that do not require subcodes.  Note that SUBCODE should be at
  least as wide as tree codes, as several tuples store tree codes
@@ -1598,15 +1593,7 @@ gimple_set_has_volatile_ops (gimple stmt
 static inline bool
 gimple_in_transaction (gimple stmt)
 {
-  return stmt->gsbase.in_transaction;
-}
-
-/* Set the IN_TRANSACTION flag to TRANSACTIONP.  */
-
-static inline void
-gimple_set_in_transaction (gimple stmt, bool transactionp)
-{
-  stmt->gsbase.in_transaction = (unsigned) transactionp;
+  return gimple_bb (stmt)->flags & BB_IN_TRANSACTION;
 }
 
 /* Return true if statement STMT may access memory.  */
Index: trans-mem.c
===
--- trans-mem.c (revision 187728)
+++ trans-mem.c (working copy)
@@ -2451,13 +2451,15 @@ compute_transaction_bits (void)
   struct tm_region *region;
   VEC (basic_block, heap) *queue;
   unsigned int i;
-  gimple_stmt_iterator gsi;
   basic_block bb;
 
   /* ?? Perhaps we need to abstract gate_tm_init further, because we
  certainly don't need it to calculate CDI_DOMINATOR info.  */
   gate_tm_init ();
 
+  FOR_EACH_BB (bb)
+bb->flags &= ~BB_IN_TRANSACTION;
+
   for (region = all_tm_regions; region; region = region->next)
 {
   queue = get_tm_region_blocks (region->entry_block,
@@ -2466,11 +2468,7 @@ compute_transaction_bits (void)
NULL,
/*stop_at_irr_p=*/true);
   for (i = 0; VEC_iterate (basic_block, queue, i, bb); ++i)
-   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
- {
-   gimple stmt = gsi_stmt (gsi);
-   gimple_set_in_transaction (stmt, true);
- }
+   bb->flags |= BB_IN_TRANSACTION;
   VEC_free (basic_block, heap, queue);
 }
 
Index: basic-block.h
===
--- basic-block.h   (revision 187728)
+++ basic-block.h   (working copy)
@@ -263,7 +263,12 @@ enum bb_flags
   BB_MODIFIED = 1 << 12,
 
   /* A general visited flag for passes to use.  */
-  BB_VISITED = 1 << 13
+  BB_VISITED = 1 << 13,
+
+  /* Set on blocks that are in a transaction.  This is calculated on
+ demand, and is available after calling
+ compute_transaction_bits().  */
+  BB_IN_TRANSACTION = 1 << 14
 };
 
 /* Dummy flag for convenience in the hot/cold partitioning code.  */

[Patch, Fortran] PR53389 realloc-on-assignment: Memory leak and wrong double evaluation (4.6-4.8 regression)

[Tobias Burnus]

First: I have another rather simple patch, which still needs to be 
reviewed: http://gcc.gnu.org/ml/fortran/2012-05/msg00086.html


 * * *

When a realloc on assignment is done, gfortran first obtains the 
descriptor by calling realloc_lhs_loop_for_fcn_call and then does the 
actual function call using gfc_conv_function_expr.


However, realloc_lhs_loop_for_fcn_call already causes that the RHS is 
evaluated (via gfc_add_loop_ss_code). The double evaluation of an inner 
function call, causes memory leaks - and double evaluation 
(correctness/performance issue).


The following code solves the issue. I am not 100% sure that it 
correctly does so, but it solved the problem and the testsuite passed. 
(It might obsolete the check in "se->direct_byref" of 
gfc_conv_procedure_call.)



The test case is a bit pointless as it will only fail if one uses 
valgrind on it; thus, one could consider committing the patch even 
without. However, it might not harm to have it in the test suite.



Build and regtested on x86-64-linux.
OK for the trunk and 4.6/4.7?

Tobias
2012-05-21  Tobias Burnus  

	PR fortran/53389
	* trans-array.c (gfc_add_loop_ss_code): Don't evaluate expression, if
	ss->is_alloc_lhs is set.

2012-05-21  Tobias Burnus  

	PR fortran/53389
	* gfortran.dg/realloc_on_assign_15.f90: New.

diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index b24d1c3..02bb38d 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -2401,6 +2401,11 @@ gfc_add_loop_ss_code (gfc_loopinfo * loop, gfc_ss * ss, bool subscript,
   bool skip_nested = false;
   int n;
 
+  /* Don't evaluate the arguments for realloc_lhs_loop_for_fcn_call; otherwise,
+ arguments could get evaluated multiple times.  */
+  if (ss->is_alloc_lhs)
+return;
+
   outer_loop = outermost_loop (loop);
 
   /* TODO: This can generate bad code if there are ordering dependencies,
--- /dev/null	2012-05-21 07:36:22.011729607 +0200
+++ gcc/gcc/testsuite/gfortran.dg/realloc_on_assign_15.f90	2012-05-21 18:18:59.0 +0200
@@ -0,0 +1,40 @@
+! { dg-do run }
+!
+! PR fortran/53389
+!
+! The program was leaking memory before due to
+! realloc on assignment and nested functions.
+!
+module foo
+  implicit none
+  contains
+
+  function filler(array, val)
+real, dimension(:), intent(in):: array
+real, dimension(size(array)):: filler
+real, intent(in):: val
+
+filler=val
+
+  end function filler
+end module
+
+program test
+  use foo
+  implicit none
+
+  real, dimension(:), allocatable:: x, y
+  integer, parameter:: N=1000 !*1000
+  integer:: i
+
+!  allocate( x(N) )
+  allocate( y(N) )
+  y=0.0
+
+  do i=1, N
+!print *,i
+x=filler(filler(y, real(2*i)), real(i))
+y=y+x
+  end do
+
+end program test

Re: [DF] Generate REFs in REGNO order

[Dimitrios Apostolou]

Hi Paolo,

On Mon, 21 May 2012, Paolo Bonzini wrote:

Il 20/05/2012 20:50, Dimitrios Apostolou ha scritto:



Paolo: I couldn't find a single test-case where the mw_reg_pool was
heavily used so I reduced its size. You think it's OK for all archs?



Makes sense, we can see if something breaks.  I'll commit the patch
tomorrow after a re-review.


Nothing will break hopefully, it will only become slower as the 
mw_reg_pool gets resized according to requests. But I can't find a 
mw_reg_pool-intensive testcase, so I guess this won't happen.


Thanks for reviewing, in the meantime I'll try to figure out why this 
patch doesn't offer any speed-up on ppc64 (doesn't break anything though), 
so expect a followup by tomorrow.



Thanks,
Dimitris

Re: [RFA] leb128.h: New file.

[Doug Evans]

On Mon, May 21, 2012 at 10:08 AM, Ian Lance Taylor  wrote:
> d...@google.com (Doug Evans) writes:
>
>> 2012-05-17  Doug Evans  
>>
>>       * leb128.h: New file.
>
> I'm not entirely sure about the use of int64_t to hold the result.  Do
> we want to let this interface support larger types some day?  E.g.,
> should the result be long long?
>
> I'll approve this patch, but think about it.
>
> The patch is not as portable as possible, but it will probably be OK in
> practice.  You should deal with any issues that arise.

I'll change the result to size_t per Jan's request.
I'm kinda worried about putting people to extra effort when they
compile with -Wconversion which is why I went with int (thinking
people would rather just use an int).  But ok.

long long (+ unsigned long long) is ok by me.
I could also rename the functions to read_uleb128_to_ull (unsigned
long long) to allow for a day if/when someone wants
read_uleb128_to_uint64.  Ok?

Fix warning if !HAVE_conditional_move

[Andreas Schwab]

get_def_for_expr_class and convert_tree_comp_to_rtx are only used if
HAVE_conditional_move.  Tested on m68k-linux and ppc-linux, checked in.

Andreas.

* expr.c (get_def_for_expr_class): Define only if
HAVE_conditional_move.
(convert_tree_comp_to_rtx): Likewise.

diff --git a/gcc/expr.c b/gcc/expr.c
index 0d52725..e6def73 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -2353,6 +2353,7 @@ get_def_for_expr (tree name, enum tree_code code)
   return def_stmt;
 }
 
+#ifdef HAVE_conditional_move
 /* Return the defining gimple statement for SSA_NAME NAME if it is an
assigment and the class of the expresion on the RHS is CLASS.  Return
NULL otherwise.  */
@@ -2372,6 +2373,7 @@ get_def_for_expr_class (tree name, enum tree_code_class 
tclass)
 
   return def_stmt;
 }
+#endif
 
 
 /* Determine whether the LEN bytes generated by CONSTFUN can be
@@ -7371,6 +7373,7 @@ highest_pow2_factor_for_target (const_tree target, 
const_tree exp)
   return MAX (factor, talign);
 }
 
+#ifdef HAVE_conditional_move
 /* Convert the tree comparision code TCODE to the rtl one where the
signedness is UNSIGNEDP.  */
 
@@ -7428,6 +7431,7 @@ convert_tree_comp_to_rtx (enum tree_code tcode, int 
unsignedp)
 }
   return code;
 }
+#endif
 
 /* Subroutine of expand_expr.  Expand the two operands of a binary
expression EXP0 and EXP1 placing the results in OP0 and OP1.
-- 
1.7.10.2

-- 
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] Detect loops in find_comparison_args

[Andrew Jenner]

Hi Paolo,

On 5/21/2012 10:12 AM, Paolo Bonzini wrote:

That's pretty heavy-weight.  Perhaps you can try the usual algorithm of
looking at x->next and x->next->next?


That would only detect cycles of length 1 and 2 though. While that would 
cover all the testcases we currently know about, I wanted to eliminate 
the entire pattern of hangs. Otherwise it's only a question of time 
until someone hits a cycle of length >= 3.


We could use less memory at the expense of CPU time by using the 
tortoise and hare algorithm, but that would make the code much more 
complicated.


Andrew

Re: [DF] Generate REFs in REGNO order

[Paolo Bonzini]

Il 20/05/2012 20:50, Dimitrios Apostolou ha scritto:
> 
> 
> Paolo: I couldn't find a single test-case where the mw_reg_pool was
> heavily used so I reduced its size. You think it's OK for all archs?
> 

Makes sense, we can see if something breaks.  I'll commit the patch
tomorrow after a re-review.

Paolo

Re: [PATCH] Detect loops in find_comparison_args

[Paolo Bonzini]

Il 21/05/2012 17:54, Andrew Jenner ha scritto:
> This patch is a followup to the patch Sandra Loosemore made to fix
> PR50380 (see (http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01402.html).
> That patch only detects fixed points, but Joseph Myers found a testcase
> which creates a cycle of length 2, causing find_comparison_args to stall
> even with the earlier patch.
> 
> This patch uses a pointer_set to detect cycles of any length and adds
> the new testcase to the test. I have successfully run bootstrap and
> regression tests. Okay to commit to mainline?

That's pretty heavy-weight.  Perhaps you can try the usual algorithm of
looking at x->next and x->next->next?

Paolo

Re: [PATCH] Fix PR53183, libgcc does not always figure out the size of double/long double

[Paolo Bonzini]

Il 21/05/2012 02:57, Andrew Pinski ha scritto:
> The problem here is that when libgcc goes to try to figure out the
> size of double/long double, it includes some headers.  But those
> headers does not exist when doing a "stage1" Linux cross compiler
> build.
> 
> This fixes the problem having configure not include those headers.
> 
> OK for the trunk and the 4.7 branch?  Bootstrap and tested on
> x86_64-linux-gnu and doing a full build of mips64-linux-gnu.
> 
> Thanks,
> Andrew Pinski
> 
> ChangeLog:
> * configure.ac: Define the default includes to being none.
> * configure: Regenerate.

Ok, thanks.

Paolo

Re: [RFA] leb128.h: New file.

[Ian Lance Taylor]

d...@google.com (Doug Evans) writes:

> 2012-05-17  Doug Evans  
>
>   * leb128.h: New file.

I'm not entirely sure about the use of int64_t to hold the result.  Do
we want to let this interface support larger types some day?  E.g.,
should the result be long long?

I'll approve this patch, but think about it.

The patch is not as portable as possible, but it will probably be OK in
practice.  You should deal with any issues that arise.

Thanks.

Ian

Re: [PATCH] Hoist adjacent pointer loads

[William J. Schmidt]

On Mon, 2012-05-21 at 14:17 +0200, Richard Guenther wrote:
> On Thu, May 3, 2012 at 4:33 PM, William J. Schmidt
>  wrote:
> > This patch was posted for comment back in February during stage 4.  It
> > addresses a performance issue noted in the EEMBC routelookup benchmark
> > on a common idiom:
> >
> >  if (...)
> >x = y->left;
> >  else
> >x = y->right;
> >
> > If the two loads can be hoisted out of the if/else, the if/else can be
> > replaced by a conditional move instruction on architectures that support
> > one.  Because this speculates one of the loads, the patch constrains the
> > optimization to avoid introducing page faults.
> >
> > Bootstrapped and regression tested on powerpc-unknown-linux-gnu with no
> > new failures.  The patch provides significant improvement to the
> > routelookup benchmark, and is neutral on SPEC cpu2000/cpu2006.
> >
> > One question is what optimization level should be required for this.
> > Because of the speculation, -O3 might be in order.  I don't believe
> > -Ofast is required as there is no potential correctness issue involved.
> > Right now the patch doesn't check the optimization level (like the rest
> > of the phi-opt transforms), which is likely a poor choice.
> >
> > Ok for trunk?
> >
> > Thanks,
> > Bill
> >
> >
> > 2012-05-03  Bill Schmidt  
> >
> >* tree-ssa-phiopt.c (tree_ssa_phiopt_worker): Add argument to forward
> >declaration.
> >(hoist_adjacent_loads, gate_hoist_loads): New forward declarations.
> >(tree_ssa_phiopt): Call gate_hoist_loads.
> >(tree_ssa_cs_elim): Add parm to tree_ssa_phiopt_worker call.
> >(tree_ssa_phiopt_worker): Add do_hoist_loads to formal arg list; call
> >hoist_adjacent_loads.
> >(local_reg_dependence): New function.
> >(local_mem_dependence): Likewise.
> >(hoist_adjacent_loads): Likewise.
> >(gate_hoist_loads): Likewise.
> >* common.opt (fhoist-adjacent-loads): New switch.
> >* Makefile.in (tree-ssa-phiopt.o): Added dependencies.
> >* params.def (PARAM_MIN_CMOVE_STRUCT_ALIGN): New param.
> >
> >
> > Index: gcc/tree-ssa-phiopt.c
> > ===
> > --- gcc/tree-ssa-phiopt.c   (revision 187057)
> > +++ gcc/tree-ssa-phiopt.c   (working copy)
> > @@ -37,9 +37,17 @@ along with GCC; see the file COPYING3.  If not see
> >  #include "cfgloop.h"
> >  #include "tree-data-ref.h"
> >  #include "tree-pretty-print.h"
> > +#include "gimple-pretty-print.h"
> > +#include "insn-config.h"
> > +#include "expr.h"
> > +#include "optabs.h"
> >
> > +#ifndef HAVE_conditional_move
> > +#define HAVE_conditional_move (0)
> > +#endif
> > +
> >  static unsigned int tree_ssa_phiopt (void);
> > -static unsigned int tree_ssa_phiopt_worker (bool);
> > +static unsigned int tree_ssa_phiopt_worker (bool, bool);
> >  static bool conditional_replacement (basic_block, basic_block,
> > edge, edge, gimple, tree, tree);
> >  static int value_replacement (basic_block, basic_block,
> > @@ -53,6 +61,9 @@ static bool cond_store_replacement (basic_block, b
> >  static bool cond_if_else_store_replacement (basic_block, basic_block, 
> > basic_block);
> >  static struct pointer_set_t * get_non_trapping (void);
> >  static void replace_phi_edge_with_variable (basic_block, edge, gimple, 
> > tree);
> > +static void hoist_adjacent_loads (basic_block, basic_block,
> > + basic_block, basic_block);
> > +static bool gate_hoist_loads (void);
> >
> >  /* This pass tries to replaces an if-then-else block with an
> >assignment.  We have four kinds of transformations.  Some of these
> > @@ -138,12 +149,56 @@ static void replace_phi_edge_with_variable (basic_
> >  bb2:
> >x = PHI ;
> >
> > -   A similar transformation is done for MAX_EXPR.  */
> > +   A similar transformation is done for MAX_EXPR.
> >
> > +
> > +   This pass also performs a fifth transformation of a slightly different
> > +   flavor.
> > +
> > +   Adjacent Load Hoisting
> > +   --
> > +
> > +   This transformation replaces
> > +
> > + bb0:
> > +   if (...) goto bb2; else goto bb1;
> > + bb1:
> > +   x1 = ().field1;
> > +   goto bb3;
> > + bb2:
> > +   x2 = ().field2;
> > + bb3:
> > +   # x = PHI ;
> > +
> > +   with
> > +
> > + bb0:
> > +   x1 = ().field1;
> > +   x2 = ().field2;
> > +   if (...) goto bb2; else goto bb1;
> > + bb1:
> > +   goto bb3;
> > + bb2:
> > + bb3:
> > +   # x = PHI ;
> > +
> > +   The purpose of this transformation is to enable generation of 
> > conditional
> > +   move instructions such as Intel CMOVE or PowerPC ISEL.  Because one of
> > +   the loads is speculative, the transformation is restricted to very
> > +   specific cases to avoid introducing a page fault.  We are looking for
> > +   the common idiom:
> > +
> > + if (...)
> > +   x = y

Re: RFC: IRA patch to reduce lifetimes

[H.J. Lu]

On Wed, Apr 11, 2012 at 7:35 AM, Bernd Schmidt  wrote:
> On 12/23/2011 05:31 PM, Vladimir Makarov wrote:
>> On 12/21/2011 09:09 AM, Bernd Schmidt wrote:
>>> This patch was an experiment to see if we can get the same improvement
>>> with modifications to IRA, making it more tolerant to over-aggressive
>>> scheduling. THe idea is that if an instruction sets a register A, and
>>> all its inputs are live and unmodified for the lifetime of A, then
>>> moving the instruction downwards towards its first use is going to be
>>> beneficial from a register pressure point of view.
>>>
>>> That alone, however, turns out to be too aggressive, performance drops
>>> presumably because we undo too many scheduling decisions. So, the patch
>>> detects such situations, and splits the pseudo; a new pseudo is
>>> introduced in the original setting instruction, and a copy is added
>>> before the first use. If the new pseudo does not get a hard register, it
>>> is removed again and instead the setting instruction is moved to the
>>> point of the copy.
>>>
>>> This gets up to 6.5% on 456.hmmer on the mips target I was working on;
>>> an embedded benchmark suite also seems to have a (small) geomean
>>> improvement. On x86_64, I've tested spec2k, where specint is unchanged
>>> and specfp has a tiny performance regression. All these tests were done
>>> with a gcc-4.6 based tree.
>>>
>>> Thoughts? Currently the patch feels somewhat bolted on to the side of
>>> IRA, maybe there's a nicer way to achieve this?
>>>
>> I think that is an excellent idea.  I used analogous approach for
>> splitting pseudo in IRA on loop bounds even if it gets hard register
>> inside and outside loops.  The copies are removed if the live ranges
>> were not spilled in reload.
>>
>> I have no problem with this patch.  It is just a small change in IRA.
>
> Sounds like you're happier with the patch than I am, so who am I to argue.
>
> Here's an updated version against current trunk, with some cc0 bugfixes
> that I've since discovered to be necessary. Bootstrapped and tested (but
> not benchmarked again) on i686-linux. Ok?
>
>
> Bernd

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53411

-- 
H.J.

Re: [I386, PATCH] Fix for PR53435

[H.J. Lu]

On Mon, May 21, 2012 at 8:51 AM, Uros Bizjak  wrote:
> On Mon, May 21, 2012 at 5:39 PM, Alexander Ivchenko  
> wrote:
>
>> Changelog entry:
>>
>> 2012-05-21  Alexander Ivchenko  
>>
>>        PR target/53435
>>        * config/i386/i386.c (ix86_expand_vec_perm): Use correct op.
>>        (ix86_expand_vec_perm): Use int mode instead of float.
>>        (expand_vec_perm_pshufb): Remove handling of useseless type
>>        conversion.
>>
>> Patch attached. Bootstrap passes.
>>
>> OK for trunk?
>
> OK for trunk and 4.7, under assumption that the relevant tests from
> the testsuite don't fail anymore on AVX2 target.
>

We noticed the issue when GCC is configured with --with-arch=native.
But current GCC trunk won't bootstrap on AVX target when GCC is
configured with --with-arch=native:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53373

We will test it on 4.7.

Thanks.


-- 
H.J.

Re: [PATCH][1/n] referenced-vars TLC

[Michael Matz]

Hi,

On Mon, 21 May 2012, Richard Guenther wrote:

> This removes the code that makes us walk DECL_INITIAL (recursively)
> on add_referenced_var - one source of compile-time hogs in the past
> and not strictly necessary.

For this to be a compile time hog, ...

>if (referenced_var_check_and_insert (var))
> -{
> -  /* Scan DECL_INITIAL for pointer variables as they may contain
> -  address arithmetic referencing the address of other
> -  variables.  As we are only interested in directly referenced
> -  globals or referenced locals restrict this to initializers
> -  than can refer to local variables.  */
> -  if (DECL_INITIAL (var)
> -  && DECL_CONTEXT (var) == current_function_decl)
> - walk_tree (&DECL_INITIAL (var), find_vars_r, NULL, 0);

... DECL_INITIAL must be non-zero often.  Two cases:
a) the transformation (presumably gimplification) that transformed 
   DECL_INITIALIZER into explicit statements left DECL_INITIALIZER 
   uselessly set
b) not all (local) DECL_INITIALIZERs are transformed into explicit 
   statements

If the former, then the above really is dead code as you rely on, though 
it probably would be good to zero out DECL_INITIALIZER at transformation 
time.  In case b) your patch is incorrect as it would leave out marking 
things as referenced which are referenced from only that initializer.

So, which is it? :)


Ciao,
Michael.

[PATCH] Detect loops in find_comparison_args

[Andrew Jenner]

This patch is a followup to the patch Sandra Loosemore made to fix 
PR50380 (see (http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01402.html). 
That patch only detects fixed points, but Joseph Myers found a testcase 
which creates a cycle of length 2, causing find_comparison_args to stall 
even with the earlier patch.


This patch uses a pointer_set to detect cycles of any length and adds 
the new testcase to the test. I have successfully run bootstrap and 
regression tests. Okay to commit to mainline?


Thanks,

Andrew

Index: ChangeLog
===
--- ChangeLog   (revision 187630)
+++ ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2012-05-17  Andrew Jenner  
+
+   * cse.c (find_comparison_args): Check for cycles of any length.
+
 2012-05-17  Manuel López-Ibáñez  
 
* opts.c (common_handle_option): -pedantic-errors enables -Wpedantic.
Index: testsuite/gcc.c-torture/compile/pr50380.c
===
--- testsuite/gcc.c-torture/compile/pr50380.c   (revision 187630)
+++ testsuite/gcc.c-torture/compile/pr50380.c   (working copy)
@@ -10,3 +10,11 @@ void foo (const unsigned char y)
((void) (__builtin_expect((!! y == y), 1) ? 0 : (fail (), 0)));
x = ! y;
 }
+
+int foo2 (int arg)
+{
+  if (arg != !arg)
+fail ();
+  if (arg)
+fail ();
+}
Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 187630)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2012-05-17  Andrew Jenner  
+
+   * gcc.c-torture/compile/pr50380.c: Add code to cause cycle of length 2.
+
 2012-05-17  Paolo Carlini  
 
PR c++/53371
Index: cse.c
===
--- cse.c   (revision 187630)
+++ cse.c   (working copy)
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.  
 #include "tree-pass.h"
 #include "df.h"
 #include "dbgcnt.h"
+#include "pointer-set.h"
 
 /* The basic idea of common subexpression elimination is to go
through the code, keeping a record of expressions that would
@@ -2905,6 +2906,7 @@ find_comparison_args (enum rtx_code code
  enum machine_mode *pmode1, enum machine_mode *pmode2)
 {
   rtx arg1, arg2;
+  struct pointer_set_t *visited = pointer_set_create ();
 
   arg1 = *parg1, arg2 = *parg2;
 
@@ -2993,10 +2995,8 @@ find_comparison_args (enum rtx_code code
  if (! exp_equiv_p (p->exp, p->exp, 1, false))
continue;
 
- /* If it's the same comparison we're already looking at, skip it.  */
- if (COMPARISON_P (p->exp)
- && XEXP (p->exp, 0) == arg1
- && XEXP (p->exp, 1) == arg2)
+ /* If it's a comparison we've used before, skip it.  */
+ if (pointer_set_contains (visited, p->exp))
continue;
 
  if (GET_CODE (p->exp) == COMPARE
@@ -3070,6 +3070,8 @@ find_comparison_args (enum rtx_code code
   else if (COMPARISON_P (x))
code = GET_CODE (x);
   arg1 = XEXP (x, 0), arg2 = XEXP (x, 1);
+
+  pointer_set_insert (visited, x);
 }
 
   /* Return our results.  Return the modes from before fold_rtx
@@ -3077,6 +3079,7 @@ find_comparison_args (enum rtx_code code
   *pmode1 = GET_MODE (arg1), *pmode2 = GET_MODE (arg2);
   *parg1 = fold_rtx (arg1, 0), *parg2 = fold_rtx (arg2, 0);
 
+  pointer_set_destroy (visited);
   return code;
 }
 

Re: [I386, PATCH] Fix for PR53435

[Uros Bizjak]

On Mon, May 21, 2012 at 5:39 PM, Alexander Ivchenko  wrote:

> Changelog entry:
>
> 2012-05-21  Alexander Ivchenko  
>
>        PR target/53435
>        * config/i386/i386.c (ix86_expand_vec_perm): Use correct op.
>        (ix86_expand_vec_perm): Use int mode instead of float.
>        (expand_vec_perm_pshufb): Remove handling of useseless type
>        conversion.
>
> Patch attached. Bootstrap passes.
>
> OK for trunk?

OK for trunk and 4.7, under assumption that the relevant tests from
the testsuite don't fail anymore on AVX2 target.

Thanks,
Uros.

Re: Turn check macros into functions. (issue6188088)

[Alexander Monakov]

On Thu, 17 May 2012, Tom Tromey wrote:

> It would be nice if there were a way to make cc1 not crash due to user
> error in the debugger.  I think this kind of crash will be especially
> crazy-making.

Hm, isn't GDB's 'set unwindonsignal on' enough to fix it?  It's useful to
have that in your .gdbinit anyway, because the same issue arises when calling
debug_* functions in cc1 from the debugger.

Alexander

[PATCH, i386]: Fix PR 53399, "*ffs" pattern generates wrong code with BMI enabled

[Uros Bizjak]

Hello!

It turned out that "rep; bsf" is not a 100% substitute for "tzcnt"
since the former sets ZF for zero input, while the later sets CF.
Attached patch fixes this oversight in ffs sequence.

2012-05-24  Uros Bizjak  

PR target/53399
* config/i386/i386.md (ffs2): Generate CCCmode compare
for TARGET_BMI.
(ffssi2_no_cmove): Ditto.
(*ffs_1): Remove insn pattern.
(*tzcnt_1): New insn pattern.
(*bsf1): Ditto.

Tested on x86_64-pc-linux-gnu {,-m32}. Tested on BMI target by Kirill.

Committed to mainline SVN.

Uros.
Index: i386.md
===
--- i386.md (revision 187694)
+++ i386.md (working copy)
@@ -12132,26 +12132,31 @@
 
 (define_expand "ffs2"
   [(set (match_dup 2) (const_int -1))
-   (parallel [(set (reg:CCZ FLAGS_REG)
-  (compare:CCZ
-(match_operand:SWI48 1 "nonimmediate_operand")
-(const_int 0)))
+   (parallel [(set (match_dup 3) (match_dup 4))
  (set (match_operand:SWI48 0 "register_operand")
-  (ctz:SWI48 (match_dup 1)))])
+  (ctz:SWI48
+(match_operand:SWI48 1 "nonimmediate_operand")))])
(set (match_dup 0) (if_then_else:SWI48
-   (eq (reg:CCZ FLAGS_REG) (const_int 0))
+   (eq (match_dup 3) (const_int 0))
(match_dup 2)
(match_dup 0)))
(parallel [(set (match_dup 0) (plus:SWI48 (match_dup 0) (const_int 1)))
  (clobber (reg:CC FLAGS_REG))])]
   ""
 {
+  enum machine_mode flags_mode;
+
   if (mode == SImode && !TARGET_CMOVE)
 {
   emit_insn (gen_ffssi2_no_cmove (operands[0], operands [1]));
   DONE;
 }
+
+  flags_mode = TARGET_BMI ? CCCmode : CCZmode;
+
   operands[2] = gen_reg_rtx (mode);
+  operands[3] = gen_rtx_REG (flags_mode, FLAGS_REG);
+  operands[4] = gen_rtx_COMPARE (flags_mode, operands[1], const0_rtx);
 })
 
 (define_insn_and_split "ffssi2_no_cmove"
@@ -12162,11 +12167,10 @@
   "!TARGET_CMOVE"
   "#"
   "&& reload_completed"
-  [(parallel [(set (reg:CCZ FLAGS_REG)
-  (compare:CCZ (match_dup 1) (const_int 0)))
+  [(parallel [(set (match_dup 4) (match_dup 5))
  (set (match_dup 0) (ctz:SI (match_dup 1)))])
(set (strict_low_part (match_dup 3))
-   (eq:QI (reg:CCZ FLAGS_REG) (const_int 0)))
+   (eq:QI (match_dup 4) (const_int 0)))
(parallel [(set (match_dup 2) (neg:SI (match_dup 2)))
  (clobber (reg:CC FLAGS_REG))])
(parallel [(set (match_dup 0) (ior:SI (match_dup 0) (match_dup 2)))
@@ -12174,37 +12178,38 @@
(parallel [(set (match_dup 0) (plus:SI (match_dup 0) (const_int 1)))
  (clobber (reg:CC FLAGS_REG))])]
 {
+  enum machine_mode flags_mode = TARGET_BMI ? CCCmode : CCZmode;
+
   operands[3] = gen_lowpart (QImode, operands[2]);
+  operands[4] = gen_rtx_REG (flags_mode, FLAGS_REG);
+  operands[5] = gen_rtx_COMPARE (flags_mode, operands[1], const0_rtx);
+
   ix86_expand_clear (operands[2]);
 })
 
-(define_insn "*ffs_1"
+(define_insn "*tzcnt_1"
+  [(set (reg:CCC FLAGS_REG)
+   (compare:CCC (match_operand:SWI48 1 "nonimmediate_operand" "rm")
+(const_int 0)))
+   (set (match_operand:SWI48 0 "register_operand" "=r")
+   (ctz:SWI48 (match_dup 1)))]
+  "TARGET_BMI"
+  "tzcnt{}\t{%1, %0|%0, %1}"
+  [(set_attr "type" "alu1")
+   (set_attr "prefix_0f" "1")
+   (set_attr "prefix_rep" "1")
+   (set_attr "mode" "")])
+
+(define_insn "*bsf_1"
   [(set (reg:CCZ FLAGS_REG)
(compare:CCZ (match_operand:SWI48 1 "nonimmediate_operand" "rm")
 (const_int 0)))
(set (match_operand:SWI48 0 "register_operand" "=r")
(ctz:SWI48 (match_dup 1)))]
   ""
-{
-  if (TARGET_BMI)
-return "tzcnt{}\t{%1, %0|%0, %1}";
-  else if (optimize_function_for_size_p (cfun))
-;
-  else if (TARGET_GENERIC)
-/* tzcnt expands to rep;bsf and we can use it even if !TARGET_BMI.  */
-return "rep; bsf{}\t{%1, %0|%0, %1}";
-
-  return "bsf{}\t{%1, %0|%0, %1}";
-}
+  "bsf{}\t{%1, %0|%0, %1}"
   [(set_attr "type" "alu1")
(set_attr "prefix_0f" "1")
-   (set (attr "prefix_rep")
- (if_then_else
-   (ior (match_test "TARGET_BMI")
-   (and (not (match_test "optimize_function_for_size_p (cfun)"))
-(match_test "TARGET_GENERIC")))
-   (const_string "1")
-   (const_string "0")))
(set_attr "mode" "")])
 
 (define_insn "ctz2"

[I386, PATCH] Fix for PR53435

[Alexander Ivchenko]

Hi, could pls have a look to fix for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53435

Changelog entry:

2012-05-21  Alexander Ivchenko  

PR target/53435
* config/i386/i386.c (ix86_expand_vec_perm): Use correct op.
(ix86_expand_vec_perm): Use int mode instead of float.
(expand_vec_perm_pshufb): Remove handling of useseless type
conversion.

Patch attached. Bootstrap passes.

OK for trunk?

thanks,
Alexander
diff --git gcc/config/i386/i386.c gcc/config/i386/i386.c
index f09b2bb..b4ad6ed 100644
--- gcc/config/i386/i386.c
+++ gcc/config/i386/i386.c
@@ -19956,7 +19956,7 @@ ix86_expand_vec_perm (rtx operands[])
  t1 = gen_reg_rtx (V8SImode);
  t2 = gen_reg_rtx (V8SImode);
  emit_insn (gen_avx2_permvarv8si (t1, op0, mask));
- emit_insn (gen_avx2_permvarv8si (t2, op0, mask));
+ emit_insn (gen_avx2_permvarv8si (t2, op1, mask));
  goto merge_two;
}
  return;
@@ -19989,10 +19989,10 @@ ix86_expand_vec_perm (rtx operands[])

 case V4SFmode:
  t1 = gen_reg_rtx (V8SFmode);
- t2 = gen_reg_rtx (V8SFmode);
- mask = gen_lowpart (V4SFmode, mask);
+ t2 = gen_reg_rtx (V8SImode);
+ mask = gen_lowpart (V4SImode, mask);
  emit_insn (gen_avx_vec_concatv8sf (t1, op0, op1));
- emit_insn (gen_avx_vec_concatv8sf (t2, mask, mask));
+ emit_insn (gen_avx_vec_concatv8si (t2, mask, mask));
  emit_insn (gen_avx2_permvarv8sf (t1, t1, t2));
  emit_insn (gen_avx_vextractf128v8sf (target, t1, const0_rtx));
  return;
@@ -36508,12 +36508,6 @@ expand_vec_perm_pshufb (struct expand_vec_perm_d *d)
gen_rtvec_v (GET_MODE_NUNITS (vmode), rperm));
   vperm = force_reg (vmode, vperm);

-  if (vmode == V8SImode && d->vmode == V8SFmode)
-{
-  vmode = V8SFmode;
-  vperm = gen_lowpart (vmode, vperm);
-}
-
   target = gen_lowpart (vmode, d->target);
   op0 = gen_lowpart (vmode, d->op0);
   if (d->one_operand_p)

Re: [RS6000] out-of-line save/restore conditions

[David Edelsohn]

On Mon, May 21, 2012 at 1:14 AM, Alan Modra  wrote:
> Currently, powerpc-linux gcc -Os -mno-multiple uses out-of-line gpr
> save and restore functions when saving/restoring just one gpr.  That's
> quite silly since the function call requires more instructions and is
> slower than an inline save/restore.  The only case where it might win
> is when no fprs are restored and the restore function can tear down
> the frame and exit (also loading up lr on ppc64).  I guess that's how
> GP_SAVE_INLINE came to be like it is, ie. it's optimised for the
> common case using ldm in the prologue and no fprs.  Still, it isn't
> difficult to choose the best combination in all cases, but it does
> mean different logic is needed for restores.  I could have implemented
> GP_RESTORE_INLINE and FP_RESORE_INLINE macros but it seemed simpler to
> just move everything into the one place the macros are invoked.  AIX
> and Darwin register cutoff doesn't change with this patch.
>
> This patch also enables out-of-line restores in cases that were
> previously disabled due to using inline saves.
>
> Bootstrapped and regression tested powerpc-linux.  OK to apply?
>
>        * aix.h (FP_SAVE_INLINE, GP_SAVE_INLINE): Delete.
>        * darwin.h (FP_SAVE_INLINE, GP_SAVE_INLINE): Delete.
>        * sysv4.h (FP_SAVE_INLINE, GP_SAVE_INLINE, V_SAVE_INLINE): Delete.
>        * config/rs6000/rs6000.c (V_SAVE_INLINE): Delete.
>        (rs6000_savres_strategy): Reimplement GP/FP/V_SAVE_INLINE logic.
>        For ELF targets, use out-of-line restores for -Os and any number
>        of regs if the restore exits, and out-of-line gp save for two or
>        more regs.  Use save_reg_p to test for holes in reg restore set.
>        Replace "#if" with "if".

Okay.

Thanks, David

Re: [RS6000] save/restore reg tidy

[David Edelsohn]

On Sun, May 20, 2012 at 10:48 PM, Alan Modra  wrote:
> On Tue, May 08, 2012 at 08:02:39PM +0930, Alan Modra wrote:
>> I also make use of gen_frame_store and siblings that I invented for
>> generating the eh info, elsewhere in rs6000.c where doing so is
>> blindingly obvious.  We could probably use them in other places too,
>> but I'll leave that for later.
>
> Like so.  The part that isn't completely obvious is removing calls to
> emit_move_insn, which can transform the rtl (rs6000_emit_move).
> However, we're past reload, the insns emitted are always one set
> involving a hard reg and mem, and we don't want any addressing mode
> subsititions going on that avoid rs6000_emit_prologue tracking of r0,
> r11 and r12 usage.
>
> This patch also fixes a couple of places that call df_regs_ever_live_p
> without checking call_used_regs to test for global asm regs.  Not
> serious bugs as they just result in larger stack frames.
>
> Bootstrapped and regression tested powerpc-linux.  OK to apply?
>
>        * config/rs6000/rs6000.c (save_reg_p): New function.
>        (first_reg_to_save, first_fp_reg_to_save): Use it here.
>        (first_altivec_reg_to_save, restore_saved_cr): Likewise.
>        (emit_frame_save): Use gen_frame_store.
>        (gen_frame_mem_offset): Correct SPE condition requiring reg+reg.
>        (rs6000_emit_prologue): Use save_reg_p.  Use gen_frame_store for
>        vrsave and toc.
>        (rs6000_emit_epilogue): Use save_reg_p.  Use gen_frame_load for
>        vrsave, toc, gp and fp restores.

Okay.

Thanks, David

Re: rs6000.c forward declaration cleanup

[David Edelsohn]

On Sun, May 20, 2012 at 9:57 PM, Alan Modra  wrote:
> This removes rather a lot of forward declarations in rs6000.c, most of
> which existed to satisfy an early TARGET_INITIALIZER.  Now that the
> TARGET_INITIALIZER has been moved to the end of rs6000.c, they become
> unnecessary and wrongly give the impression that rs6000.c style is to
> declare functions at the beginning of the file.  Bootstrapped etc.
> powerpc-linux.  OK to apply?
>
>        * config/rs6000/rs6000.c: Delete unnecessary forward declarations.
>        Move those with ATTRIBUTE_UNUSED to immediately before definitions.
>        Move function pointer variables after forward declarations.
>        (rs6000_builtin_support_vector_misalignment): Make static.
>        (rs6000_legitimate_address_p, rs6000_gimplify_va_arg): Likewise.
>        (rs6000_function_value, rs6000_can_eliminate): Likewise.

Okay. Thanks for the cleanup.

Thanks, David

Re: Show hash table stats when -fmem-report

[Jan Hubicka]

> Hello list,
>
> I ported a patch from last year's GSOC to current trunk, removing  
> deprecated hash tables and adding some new ones. I also backed out a  
> change that reduced collisions by decreasing load factor because it had  
> created controversy, so this patch should be easily applicable.
>
> CC'd whoever is relevant with subsystems or had commented on this last  
> year. Some notes:
>
>  * Is it OK that I included  in libiberty's hashtab.c?
>  * Many hash tables are created with htab_create_ggc(), for example  
> referenced_vars and default_defs in tree-ssa.c. I collect statistics in  
> delete_tree_ssa() but maybe some are not deallocated in there but  
> automatically garbage collected?
>  * Obviously hash table sizes are inflated where two entries might  
> reference the same element (for example in symtab_hash) but I don't 
> handle this.
>  * Maybe the best overall solution would be to add a string parameter to  
> htab_create*() and store statistics in an internal hash table according 
> to this string. Statistics would then be printed for all hash tables by  
> iterating this internal table. Since it would cause a significant  
> slowdown, -fmem-report would be better as a compile-time option than a  
> run-time one. This is probably an overkill so I think I'll skip it.

You may also consider using the machinery we use for statistics of
bitmaps/alloc pools/ vectors/ggc with -fenable-gather-detailes-mem-stats.  Will
be bit tricky because hashtables are used to gather the stats elsehwere, but i
think it is resonable approach to do. (basically you need to add API to
avoid gathering statistics of statistics).

We should have similar statics for pointer maps and pointer sets. All those
are suspects of expoding especially at WPA time.

Honza

Re: [PATCH 2/2] Better system header location detection for built-in macro tokens

[Jason Merrill]

What if the built-in macro appears in a macro defined in a system header 
but used in user code?  This would resolve the location all the way to 
the user code, and warn.  I think we only want to step out until we 
reach a non-built-in macro, not all the way to the outermost expansion 
point.


Jason

Re: [PATCH 1/2] PR c++/53322 - -Wunused-local-typedefs is not enabled by Wall or Wunused

[Jason Merrill]

On 05/21/2012 09:53 AM, Dodji Seketeli wrote:

I have changed the gcc+.dg/warn/Wunused-local-typedefs.C test case to
make it use -Wunused instead of -Wunused-local-typedefs.  I had to
adjust it to avoid the warnings due to the other -W* options triggered
by -Wunused there.


Hmm, I might have added another test to make sure that -Wunused enables 
-Wunused-local-typedefs rather than scatter attribute ((unused)) all 
around this one, but I guess this way is fine too.


The patch is OK.

Jason

[PATCH][2/n] referenced-vars TLC

[Richard Guenther]

This makes add_referenced_var take a struct function argument to
eventually avoid a push/pop_cfun around some of its callers (in
some further patch).  It also avoids a redundant hashtable
lookup on var insertion.

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

Richard.

2012-05-21  Richard Guenther  

* tree-flow.h (add_referenced_var_1): Declare.
(add_referenced_var): Define.
* tree-dfa.c (referenced_var_check_and_insert): Avoid one hash
lookup.
(add_referenced_var): Rename to ...
(add_referenced_var_1): ... this.  Take struct function argument.

Index: gcc/tree-flow.h
===
--- gcc/tree-flow.h (revision 187719)
+++ gcc/tree-flow.h (working copy)
@@ -491,7 +491,8 @@ extern void debug_referenced_vars (void)
 extern void dump_referenced_vars (FILE *);
 extern void dump_variable (FILE *, tree);
 extern void debug_variable (tree);
-extern bool add_referenced_var (tree);
+extern bool add_referenced_var_1 (tree, struct function *);
+#define add_referenced_var(v) add_referenced_var_1 ((v), cfun)
 extern void remove_referenced_var (tree);
 extern tree make_rename_temp (tree, const char *);
 extern void set_default_def (tree, tree);
Index: gcc/tree-dfa.c
===
--- gcc/tree-dfa.c  (revision 187719)
+++ gcc/tree-dfa.c  (working copy)
@@ -503,24 +503,23 @@ referenced_var_lookup (struct function *
Return true if it required insertion.  */
 
 static bool
-referenced_var_check_and_insert (tree to)
+referenced_var_check_and_insert (tree to, struct function *fn)
 {
-  tree h, *loc;
+  tree *loc;
   struct tree_decl_minimal in;
   unsigned int uid = DECL_UID (to);
 
   in.uid = uid;
-  h = (tree) htab_find_with_hash (gimple_referenced_vars (cfun), &in, uid);
-  if (h)
+  loc = (tree *) htab_find_slot_with_hash (gimple_referenced_vars (fn),
+  &in, uid, INSERT);
+  if (*loc)
 {
   /* DECL_UID has already been entered in the table.  Verify that it is
 the same entry as TO.  See PR 27793.  */
-  gcc_assert (h == to);
+  gcc_assert (*loc == to);
   return false;
 }
 
-  loc = (tree *) htab_find_slot_with_hash (gimple_referenced_vars (cfun),
-  &in, uid, INSERT);
   *loc = to;
   return true;
 }
@@ -575,7 +574,7 @@ set_default_def (tree var, tree def)
 /* Add VAR to the list of referenced variables if it isn't already there.  */
 
 bool
-add_referenced_var (tree var)
+add_referenced_var_1 (tree var, struct function *fn)
 {
   gcc_checking_assert (TREE_CODE (var) == VAR_DECL
   || TREE_CODE (var) == PARM_DECL
@@ -585,7 +584,7 @@ add_referenced_var (tree var)
 create_var_ann (var);
 
   /* Insert VAR into the referenced_vars hash table if it isn't present.  */
-  if (referenced_var_check_and_insert (var))
+  if (referenced_var_check_and_insert (var, fn))
 return true;
 
   return false;

Re: [PATCH preprocessor, diagnostics] PR preprocessor/53229 - Fix diagnostics location when pasting tokens

[Jason Merrill]

On 05/21/2012 10:07 AM, Dodji Seketeli wrote:

Jason Merrill  writes:

When do we not want to set invocation_location if we're beginning to
expand a macro?


If M itself involves expanding another macro M', we are supposed to call
the (internal function) cpp_get_token_1 that does not set
set_invocation_location.  So that the only expansion point recorded is
the one for M, not the one for M'.


But if we're already in a macro expansion (if context->c.macro is set) 
cpp_get_token_1 doesn't set invocation_location even if 
set_invocation_location is true.  So we should only get the expansion 
point for M even if set_invocation_location is always true.



Now, looking at how surprising this is turning out to be, I am thinking
that cpp_get_token should, like cpp_get_token_with_location just set
pfile->set_invocation_location, just like cpp_get_token_with_location.

Would you agree?


Yes, except that I would go farther and do away with the flag entirely.

Jason

Re: [C++ Patch] PR 40821

[Jason Merrill]

OK.

Jason

Re: [patch] More thorough checking in reg_fits_class_p

[Richard Earnshaw]

On 17/05/12 14:23, Jim MacArthur wrote:
> On 02/05/12 14:55, Richard Sandiford wrote:
>> Richard Earnshaw  writes:
>>> On 02/05/12 14:00, Richard Sandiford wrote:
 Jim MacArthur  writes:
> New Changelog text:
>
> 2012-05-02 Jim MacArthur
> * recog.c (reg_fits_class_p): Check both regno and regno + offset are
> hard registers.
 Thanks.  I still think the final:

> + &&  HARD_REGISTER_NUM_P (end_hard_regno (regno + offset, mode))
 check belongs in in_hard_reg_set_p, since most callers don't (and IMO
 shouldn't need to) check this.  The idea behind adding these functions
 was to commonise various bits of code that were doing the same checks
 in slightly different ways.  Requiring each caller to check the end
 register would go against that to some extent.

>>> If you're going to do that (which is fine, BTW), I think
>>> in_hard_reg_set_p should gcc_assert() that regno is a valid hard reg.
>> Sounds good.
>>
>> Richard
>>
> 
> Sorry for the delay in responding to this, I had a few problems with 
> end_hard_regno. Here's a new version of the patch, which adds to 
> in_hard_reg_set_p the assert and a check for the hardness of end_regno.  
> end_hard_regno is the exclusive upper bound of the range, so not 
> actually a meaningful reg no. HARD_REGNO_NREGS is required to return a 
> positive value, so (end_regno - 1) is always safe, as I understand it.
> 
> I've tested this with an x86 bootstrap which shows no errors, and with 
> our own AArch64 back end.
> 
> Jim
> 
> New ChangeLog text:
> 
> 2012-05-17  Jim MacArthur
>* recog.c (reg_fits_class_p): Check both regno and regno + offset are  
> hard registers.
>* regs.h (in_hard_reg_set_p): Assert that regno is a hard register and
> check end_regno - 1 is a hard register.
> 

OK.

R.

Fix PR c/53148 (ICE with division by zero in conditional expression)

[Joseph S. Myers]

This patch fixes PR 53148, a regression where a conditional expression
between signed and unsigned, the evaluated half involving division by
zero but both halves having only integer constants as operands,
resulted in an ICE because C_MAYBE_CONST_EXPRs were wrongly nested
(they should never be nested).  The problem was the code dealing with
signed/unsigned warnings folded both halves, and then wrapped them in
C_MAYBE_CONST_EXPRs as needed to avoid repeated recursive folding, but
the code dealing with nonconstant expressions with integer constant
operands (such as those involving an evaluated division by zero - such
expressions may appear in unevaluated parts of an integer constant
expression, but not in evaluated parts) failed to deal with this
before adding another C_MAYBE_CONST_EXPR to mark the expression with
integer constant operands as such.

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  Applied
to mainline.  Will also test for 4.7 and 4.6 branches.

2012-05-21  Joseph Myers  

PR c/53148
* c-typeck.c (build_conditional_expr): Remove C_MAYBE_CONST_EXPR
from folded operands before wrapping another around the
conditional expression.

testsuite:
2012-05-21  Joseph Myers  

PR c/53148
* gcc.c-torture/compile/pr53418-1.c,
gcc.c-torture/compile/pr53418-2.c: New tests.

Index: testsuite/gcc.c-torture/compile/pr53418-1.c
===
--- testsuite/gcc.c-torture/compile/pr53418-1.c (revision 0)
+++ testsuite/gcc.c-torture/compile/pr53418-1.c (revision 0)
@@ -0,0 +1,5 @@
+void
+f (void)
+{
+  int i = (0 ? 1 : 0U / 0);
+}
Index: testsuite/gcc.c-torture/compile/pr53418-2.c
===
--- testsuite/gcc.c-torture/compile/pr53418-2.c (revision 0)
+++ testsuite/gcc.c-torture/compile/pr53418-2.c (revision 0)
@@ -0,0 +1,5 @@
+void
+f (void)
+{
+  int i = (1 ? 0U / 0 : 1);
+}
Index: c-typeck.c
===
--- c-typeck.c  (revision 187704)
+++ c-typeck.c  (working copy)
@@ -4408,6 +4408,11 @@ build_conditional_expr (location_t colon
 ret = fold_build3_loc (colon_loc, COND_EXPR, result_type, ifexp, op1, op2);
   else
 {
+  if (int_operands)
+   {
+ op1 = remove_c_maybe_const_expr (op1);
+ op2 = remove_c_maybe_const_expr (op2);
+   }
   ret = build3 (COND_EXPR, result_type, ifexp, op1, op2);
   if (int_operands)
ret = note_integer_operands (ret);

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

Re: [C++ Patch] PR 51184

[Jason Merrill]

OK.

Jason

[PATCH][1/n] referenced-vars TLC

[Richard Guenther]

This removes the code that makes us walk DECL_INITIAL (recursively)
on add_referenced_var - one source of compile-time hogs in the past
and not strictly necessary.  Fallout is fixed by guarding used flag
setting in unused-var-removal as all reads of that flag are already.

This is a first patch in a series to make referenced vars tracking
cheaper and more robust.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2012-05-21  Richard Guenther  

* tree-dfa.c (add_referenced_var): Do not walk DECL_INITIAL for
more referenced vars.
* tree-ssa-live.c (mark_all_vars_used_1): Only set the used
flag on variables that have a var-annotation.

Index: gcc/tree-dfa.c
===
--- gcc/tree-dfa.c  (revision 187708)
+++ gcc/tree-dfa.c  (working copy)
@@ -577,24 +577,16 @@ set_default_def (tree var, tree def)
 bool
 add_referenced_var (tree var)
 {
-  gcc_assert (DECL_P (var));
+  gcc_checking_assert (TREE_CODE (var) == VAR_DECL
+  || TREE_CODE (var) == PARM_DECL
+  || TREE_CODE (var) == RESULT_DECL);
+
   if (!*DECL_VAR_ANN_PTR (var))
 create_var_ann (var);
 
   /* Insert VAR into the referenced_vars hash table if it isn't present.  */
   if (referenced_var_check_and_insert (var))
-{
-  /* Scan DECL_INITIAL for pointer variables as they may contain
-address arithmetic referencing the address of other
-variables.  As we are only interested in directly referenced
-globals or referenced locals restrict this to initializers
-than can refer to local variables.  */
-  if (DECL_INITIAL (var)
-  && DECL_CONTEXT (var) == current_function_decl)
-   walk_tree (&DECL_INITIAL (var), find_vars_r, NULL, 0);
-
-  return true;
-}
+return true;
 
   return false;
 }
Index: gcc/tree-ssa-live.c
===
--- gcc/tree-ssa-live.c (revision 187708)
+++ gcc/tree-ssa-live.c (working copy)
@@ -377,7 +377,8 @@ mark_all_vars_used_1 (tree *tp, int *wal
   if (data != NULL && bitmap_clear_bit ((bitmap) data, DECL_UID (t))
  && DECL_CONTEXT (t) == current_function_decl)
mark_all_vars_used (&DECL_INITIAL (t), data);
-  set_is_used (t);
+  if (var_ann (t) != NULL)
+   set_is_used (t);
 }
   /* remove_unused_scope_block_p requires information about labels
  which are not DECL_IGNORED_P to tell if they might be used in the IL.  */

Re: [RFA] leb128.h: New file.

[Jan Kratochvil]

On Mon, 21 May 2012 02:30:58 +0200, Doug Evans wrote:
> Ping.
> On Thu, May 17, 2012 at 11:29 AM, Doug Evans  wrote:
[...]
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ leb128.h    17 May 2012 18:23:29 -
[...]
> > +/* Get a definition for NULL.  */
> > +#include 

I think  for NULL.


[...]
> > +static inline int

Return type should be size_t or ptrdiff_t.  Likewise for other functions.

> > +read_uleb128 (const unsigned char *buf, const unsigned char *buf_end,
> > +             uint64_t *r)
> > +{
> > +  const unsigned char *p = buf;
> > +  unsigned int shift = 0;
> > +  uint64_t result = 0;
> > +  unsigned char byte;
> > +
> > +  while (1)
> > +    {
> > +      if (p >= buf_end)
> > +       return 0;
> > +
> > +      byte = *p++;
> > +      result |= ((uint64_t) (byte & 0x7f)) << shift;
> > +      if ((byte & 0x80) == 0)
> > +       break;
> > +      shift += 7;
> > +    }
> > +
> > +  *r = result;
> > +  return p - buf;
> > +}
[...]


Regards,
Jan

Re: [PATCH preprocessor, diagnostics] PR preprocessor/53229 - Fix diagnostics location when pasting tokens

[Dodji Seketeli]

Tom Tromey  writes:

>> "Dodji" == Dodji Seketeli  writes:
>
> Dodji> To properly fix this, I think libcpp should keep the token of the
> Dodji> pasting operator '##', instead of representing it with flag on the LHS
> Dodji> operand's token.  That way, it could use its location.
>
> Originally I had thought that a pasted token should have a special
> virtual location, pointing to the locations of its source tokens.
> This would let later code "undo" the paste, if need be.
>
> I don't know any more if this idea makes sense or not.

I think this makes sense, at least in the grand scheme of things.

The same underlying mechanism that would associate one or several
locations (for instance, the locations of the two operands of the
pasting operator) to a given location (for instance the location for the
token resulting from the pasting operation) could be used to e.g, make a
token carry two locations: one for the beginning of the token, and
another one for the end of the token.

cpp_get_token_with_location would just return the location for the
beginning of the token, like it does today, and we'd be able to retrieve
the second token by mean of the earlier association.

This whole shebang would be then used for the mighty range based
diagnostic[1].

Does that make sense?

[1]: http://gcc.gnu.org/wiki/Better_Diagnostics

-- 
Dodji

Re: Show hash table stats when -fmem-report

[Dimitrios Apostolou]

One line patch to update Makefile.


2012-05-21 Dimitrios Apostolou 

* gcc/Makefile.in: (toplev.o) toplev.o depends on cselib.h.



=== modified file 'gcc/Makefile.in'
--- gcc/Makefile.in 2012-05-04 20:04:47 +
+++ gcc/Makefile.in 2012-05-21 14:08:45 +
@@ -2751,7 +2751,7 @@ toplev.o : toplev.c $(CONFIG_H) $(SYSTEM
langhooks.h insn-flags.h $(CFGLAYOUT_H) $(CFGLOOP_H) hosthooks.h \
$(CGRAPH_H) $(COVERAGE_H) alloc-pool.h $(GGC_H) $(INTEGRATE_H) \
$(OPTS_H) params.def tree-mudflap.h $(TREE_PASS_H) $(GIMPLE_H) \
-   tree-ssa-alias.h $(PLUGIN_H) realmpfr.h tree-diagnostic.h \
+   tree-ssa-alias.h $(PLUGIN_H) cselib.h realmpfr.h tree-diagnostic.h \
tree-pretty-print.h opts-diagnostic.h $(COMMON_TARGET_H)

 hwint.o : hwint.c $(CONFIG_H) $(SYSTEM_H) $(DIAGNOSTIC_CORE_H)

Re: [PATCH] Fix vect_supported_load_permutation_p (PR tree-optimization/53366)

[Richard Guenther]

On Mon, May 21, 2012 at 4:04 PM, Jakub Jelinek  wrote:
> Hi!
>
> If there are exactly 2 complex loads and some other loads in SLP instance,
> we sometimes miscompile things because vect_supported_load_permutation_p
> skips important checks.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk/4.7?

Ok.

Thanks,
Richard.

> 2012-05-21  Jakub Jelinek  
>
>        PR tree-optimization/53366
>        * tree-vect-slp.c (vect_supported_load_permutation_p): Don't shortcut
>        tests if complex_numbers == 2, but there are non-complex number loads
>        too.
>
>        * gcc.dg/torture/pr53366-1.c: New test.
>        * gcc.dg/torture/pr53366-2.c: New test.
>        * gcc.target/i386/pr53366-1.c: New test.
>        * gcc.target/i386/pr53366-2.c: New test.
>
> --- gcc/tree-vect-slp.c.jj      2012-04-19 11:09:13.0 +0200
> +++ gcc/tree-vect-slp.c 2012-05-21 12:46:40.078674688 +0200
> @@ -1199,7 +1199,8 @@ vect_supported_load_permutation_p (slp_i
>
>   /* We checked that this case ok, so there is no need to proceed with
>      permutation tests.  */
> -  if (complex_numbers == 2)
> +  if (complex_numbers == 2
> +      && VEC_length (slp_tree, SLP_INSTANCE_LOADS (slp_instn)) == 2)
>     {
>       VEC_free (slp_tree, heap, SLP_INSTANCE_LOADS (slp_instn));
>       VEC_free (int, heap, SLP_INSTANCE_LOAD_PERMUTATION (slp_instn));
> --- gcc/testsuite/gcc.dg/torture/pr53366-1.c.jj 2012-05-21 12:55:47.220474343 
> +0200
> +++ gcc/testsuite/gcc.dg/torture/pr53366-1.c    2012-05-21 12:53:40.0 
> +0200
> @@ -0,0 +1,70 @@
> +/* PR tree-optimization/53366 */
> +/* { dg-do run } */
> +
> +extern void abort (void);
> +
> +struct S { double v[3]; };
> +struct T { struct S r, i; };
> +struct U { struct T j[5]; };
> +
> +void
> +foo (struct U *__restrict p1, struct U *__restrict p2,
> +     struct S l1, struct S l2, struct S l3, struct S l4,
> +     const double _Complex * __restrict x, int y, int z)
> +{
> +  int i, j;
> +  while (y < z - 2)
> +    {
> +      for (j = 0; j < 5; ++j)
> +       {
> +         double a = __real__ x[5 * y + j];
> +         double b = __imag__ x[5 * y + j];
> +         double c = __real__ x[5 * (y + 2) + j];
> +         double d = __imag__ x[5 * (y + 2) + j];
> +         double e = __real__ x[5 * (y + 1) + j];
> +         double f = __imag__ x[5 * (y + 1) + j];
> +         double g = __real__ x[5 * (y + 3) + j];
> +         double h = __imag__ x[5 * (y + 3) + j];
> +         for (i = 0; i < 3; ++i)
> +           {
> +             p1->j[j].r.v[i] += l2.v[i] * a;
> +             p1->j[j].r.v[i] += l4.v[i] * c;
> +             p1->j[j].i.v[i] += l2.v[i] * b;
> +             p1->j[j].i.v[i] += l4.v[i] * d;
> +             p2->j[j].r.v[i] += l3.v[i] * e;
> +             p2->j[j].r.v[i] += l1.v[i] * g;
> +             p2->j[j].i.v[i] += l3.v[i] * f;
> +             p2->j[j].i.v[i] += l1.v[i] * h;
> +           }
> +       }
> +      y += 4;
> +    }
> +}
> +
> +_Complex double x[5005];
> +struct U p1, p2;
> +
> +int
> +main ()
> +{
> +  int i, j;
> +  struct S l1, l2, l3, l4;
> +  for (i = 0; i < 5005; ++i)
> +    x[i] = i + 1.0iF * (2 * i);
> +  for (i = 0; i < 3; ++i)
> +    {
> +      l1.v[i] = 1;
> +      l2.v[i] = 2;
> +      l3.v[i] = 3;
> +      l4.v[i] = 4;
> +    }
> +  foo (&p1, &p2, l1, l2, l3, l4, x, 5, 1000);
> +  for (j = 0; j < 5; ++j)
> +    for (i = 0; i < 3; ++i)
> +      if (p1.j[j].r.v[i] != 3752430 + j * 1494.0
> +         || p1.j[j].i.v[i] != p1.j[j].r.v[i] * 2
> +         || p2.j[j].r.v[i] != 2502450 + j * 996.0
> +         || p2.j[j].i.v[i] != p2.j[j].r.v[i] * 2)
> +       abort ();
> +  return 0;
> +}
> --- gcc/testsuite/gcc.dg/torture/pr53366-2.c.jj 2012-05-21 12:55:50.011459264 
> +0200
> +++ gcc/testsuite/gcc.dg/torture/pr53366-2.c    2012-05-21 12:54:48.0 
> +0200
> @@ -0,0 +1,43 @@
> +/* PR tree-optimization/53366 */
> +/* { dg-do run } */
> +
> +extern void abort (void);
> +
> +struct T { float r[3], i[3]; };
> +struct U { struct T j[2]; };
> +
> +void __attribute__ ((noinline))
> +foo (struct U *__restrict y, const float _Complex *__restrict x)
> +{
> +  int i, j;
> +  for (j = 0; j < 2; ++j)
> +    {
> +      float a = __real__ x[j];
> +      float b = __imag__ x[j];
> +      float c = __real__ x[j + 2];
> +      float d = __imag__ x[j + 2];
> +      for (i = 0; i < 3; ++i)
> +        {
> +          y->j[j].r[i] = y->j[j].r[i] + a + c;
> +          y->j[j].i[i] = y->j[j].i[i] + b + d;
> +        }
> +    }
> +}
> +
> +_Complex float x[4];
> +struct U y;
> +
> +int
> +main ()
> +{
> +  int i, j;
> +  for (i = 0; i < 4; ++i)
> +    x[i] = i + 1.0iF * (2 * i);
> +  foo (&y, x);
> +  for (j = 0; j < 2; ++j)
> +    for (i = 0; i < 3; ++i)
> +      if (y.j[j].r[i] != __real__ (x[j] + x[j + 2])
> +          || y.j[j].i[i] != __imag__ (x[j] + x[j + 2]))
> +        __builtin_abort ();
> +  return 0;
> +}
> --- gcc/testsuite/gcc.target/i386/pr53366-1.c.jj        2012-05-21 
> 12:56:54.091092771 +0200
> +++ gcc/testsuite/gcc.tar

Re: [PATCH] Fix vectorizer ICE (PR tree-optimization/53409)

[Richard Guenther]

On Mon, May 21, 2012 at 3:59 PM, Jakub Jelinek  wrote:
> Hi!
>
> On the following testcase we ICE, because op_def_stmt isn't inside
> of the loop (phi is a degenerate phi referencing a phi result from before the
> loop) and stmts outside of the loop don't have uid set (or it can contain
> garbage).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.7?

Ok.

Thanks,
Richard.

> 2012-05-21  Jakub Jelinek  
>
>        PR tree-optimization/53409
>        * tree-vect-loop.c (vect_analyze_loop_operations): Don't check
>        vinfo_for_stmt (op_def_stmt) if op_def_stmt isn't inside loop.
>
>        * gcc.c-torture/compile/pr53409.c: New test.
>
> --- gcc/tree-vect-loop.c.jj     2012-05-17 08:40:45.0 +0200
> +++ gcc/tree-vect-loop.c        2012-05-21 11:30:28.721333458 +0200
> @@ -1327,7 +1327,9 @@ vect_analyze_loop_operations (loop_vec_i
>                     return false;
>
>                   op_def_stmt = SSA_NAME_DEF_STMT (phi_op);
> -                  if (!op_def_stmt || !vinfo_for_stmt (op_def_stmt))
> +                 if (!op_def_stmt
> +                     || !flow_bb_inside_loop_p (loop, gimple_bb 
> (op_def_stmt))
> +                     || !vinfo_for_stmt (op_def_stmt))
>                     return false;
>
>                   if (STMT_VINFO_RELEVANT (vinfo_for_stmt (op_def_stmt))
> --- gcc/testsuite/gcc.c-torture/compile/pr53409.c.jj    2012-05-21 
> 11:33:23.621318856 +0200
> +++ gcc/testsuite/gcc.c-torture/compile/pr53409.c       2012-05-21 
> 11:33:13.0 +0200
> @@ -0,0 +1,19 @@
> +/* PR tree-optimization/53409 */
> +
> +int a, c, d, e, f;
> +int b[0];
> +
> +int
> +main ()
> +{
> +  if (f)
> +    e = 0;
> +  int g = d;
> +  for (c = 0; c <= 1; c++)
> +    {
> +      for (a = 0; a <= 1; a = (char) a + 1)
> +       b[c] = g;
> +      a = 0;
> +    }
> +  return 0;
> +}
>
>        Jakub

Re: [PATCH preprocessor, diagnostics] PR preprocessor/53229 - Fix diagnostics location when pasting tokens

[Dodji Seketeli]

Jason Merrill  writes:

> On 05/15/2012 10:17 AM, Dodji Seketeli wrote:
>> It fixes the test case gcc.dg/cpp/paste12.c because that test case runs
>> with -ftrack-macro-expansion turned off.  Otherwise, you are right that
>> the issue exists only when we aren't tracking virtual locations.
>
> I still don't understand why this change should be needed; it seems
> like a kludge disguised as a trivial change from one function to
> another.  If we're going to kludge, I'd rather explicitly set the flag
> with a comment.
>
> But why do we need the set_invocation_location flag at all?

I understand this set_invocation_location business as the poor man's
approach of tracking the expansion point location prior to the
ftrack-macro-expansion machinery.

When we are about to expand a macro M that is the top-most macro of the
expansion stack, we set it to record the expansion point of M.  This is
what cpp_get_token_with_location does.

> When do we not want to set invocation_location if we're beginning to
> expand a macro?

If M itself involves expanding another macro M', we are supposed to call
the (internal function) cpp_get_token_1 that does not set
set_invocation_location.  So that the only expansion point recorded is
the one for M, not the one for M'.

Said otherwise, cpp_get_token_with_location is the preferred external top-most
entry point to use to get a token (otherwise, we don't handle expansion
point locations), and cpp_get_token_1 should only used internally.

Now, looking at how surprising this is turning out to be, I am thinking
that cpp_get_token should, like cpp_get_token_with_location just set
pfile->set_invocation_location, just like cpp_get_token_with_location.

Would you agree?

-- 
Dodji

Re: [PATCH] Fix fold_binary_loc vector handling (PR tree-optimization/53410)

[Richard Guenther]

On Mon, May 21, 2012 at 3:55 PM, Jakub Jelinek  wrote:
> Hi!
>
> As the following testcases show, some places in fold_binary_loc
> (haven't checked other routines) can attempt to optimize even vector
> expressions, but in that case build_int_cst can't be used.
> Instead, for zeros build_zero_cst can be used, for the two places
> which need to build 1 I'm just folding the original one argument.

There is build_one_cst, too.

> On the 4.7 branch (patch attached after the 4.8 version) there are fewer
> spots that need changing, because integer_zerop/integer_onep don't return
> true for vectors.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.7?

Ok.

Thanks,
Richard.

> 2012-05-21  Jakub Jelinek  
>
>        PR tree-optimization/53410
>        * fold-const.c (fold_binary_loc): Use build_zero_cst (type)
>        instead of build_int_cst (type, 0) where vector types might be
>        involved. Instead of build_int_cst (type, 1) convert the original
>        integer_onep argument to the desired type.
>
>        * gcc.c-torture/compile/pr53410-1.c: New test.
>        * gcc.c-torture/compile/pr53410-2.c: New test.
>
> --- gcc/fold-const.c.jj 2012-05-12 10:21:06.0 +0200
> +++ gcc/fold-const.c    2012-05-21 10:38:36.928229511 +0200
> @@ -11245,7 +11245,7 @@ fold_binary_loc (location_t loc,
>          && integer_onep (TREE_OPERAND (arg0, 1))
>          && integer_onep (arg1))
>        return fold_build2_loc (loc, EQ_EXPR, type, arg0,
> -                           build_int_cst (TREE_TYPE (arg0), 0));
> +                               build_zero_cst (TREE_TYPE (arg0)));
>
>       /* Fold (X & Y) ^ Y as ~X & Y.  */
>       if (TREE_CODE (arg0) == BIT_AND_EXPR
> @@ -11355,21 +11355,25 @@ fold_binary_loc (location_t loc,
>          && integer_onep (TREE_OPERAND (arg0, 1))
>          && integer_onep (arg1))
>        {
> +         tree tem2;
>          tem = TREE_OPERAND (arg0, 0);
> -         return fold_build2_loc (loc, EQ_EXPR, type,
> -                             fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE 
> (tem), tem,
> -                                          build_int_cst (TREE_TYPE (tem), 
> 1)),
> -                             build_int_cst (TREE_TYPE (tem), 0));
> +         tem2 = fold_convert_loc (loc, TREE_TYPE (tem), arg1);
> +         tem2 = fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE (tem),
> +                                 tem, tem2);
> +         return fold_build2_loc (loc, EQ_EXPR, type, tem2,
> +                                 build_zero_cst (TREE_TYPE (tem)));
>        }
>       /* Fold ~X & 1 as (X & 1) == 0.  */
>       if (TREE_CODE (arg0) == BIT_NOT_EXPR
>          && integer_onep (arg1))
>        {
> +         tree tem2;
>          tem = TREE_OPERAND (arg0, 0);
> -         return fold_build2_loc (loc, EQ_EXPR, type,
> -                             fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE 
> (tem), tem,
> -                                          build_int_cst (TREE_TYPE (tem), 
> 1)),
> -                             build_int_cst (TREE_TYPE (tem), 0));
> +         tem2 = fold_convert_loc (loc, TREE_TYPE (tem), arg1);
> +         tem2 = fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE (tem),
> +                                 tem, tem2);
> +         return fold_build2_loc (loc, EQ_EXPR, type, tem2,
> +                                 build_zero_cst (TREE_TYPE (tem)));
>        }
>       /* Fold !X & 1 as X == 0.  */
>       if (TREE_CODE (arg0) == TRUTH_NOT_EXPR
> @@ -11377,7 +11381,7 @@ fold_binary_loc (location_t loc,
>        {
>          tem = TREE_OPERAND (arg0, 0);
>          return fold_build2_loc (loc, EQ_EXPR, type, tem,
> -                                 build_int_cst (TREE_TYPE (tem), 0));
> +                                 build_zero_cst (TREE_TYPE (tem)));
>        }
>
>       /* Fold (X ^ Y) & Y as ~X & Y.  */
> @@ -12893,13 +12897,13 @@ fold_binary_loc (location_t loc,
>       if (TREE_CODE (arg0) == BIT_XOR_EXPR
>          && operand_equal_p (TREE_OPERAND (arg0, 1), arg1, 0))
>        return fold_build2_loc (loc, code, type, TREE_OPERAND (arg0, 0),
> -                               build_int_cst (TREE_TYPE (arg0), 0));
> +                               build_zero_cst (TREE_TYPE (arg0)));
>       /* Likewise (X ^ Y) == X becomes Y == 0.  X has no side-effects.  */
>       if (TREE_CODE (arg0) == BIT_XOR_EXPR
>          && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0)
>          && reorder_operands_p (TREE_OPERAND (arg0, 1), arg1))
>        return fold_build2_loc (loc, code, type, TREE_OPERAND (arg0, 1),
> -                               build_int_cst (TREE_TYPE (arg0), 0));
> +                               build_zero_cst (TREE_TYPE (arg0)));
>
>       /* (X ^ C1) op C2 can be rewritten as X op (C1 ^ C2).  */
>       if (TREE_CODE (arg0) == BIT_XOR_EXPR
> @@ -12987,7 +12991,7 @@ fold_binary_loc (location_t loc,
>                                                          BIT_XOR_EXPR, itype,
>                                       

[Ping 2] [PATCH H8300] Add function_vector attribute

[Ajinkya Dhobale]

PING 2:

This is a ping for the patch that add 'function_vector' attribute for 
H8300 targets: 
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00250.html

The patch has been updated to address Jeff's comments which can be referred
at: http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01884.html

Please review the patch.

Thanks & Regards,
Ajinkya Dhobale
KPIT Cummins, Pune.

[PATCH] Fix vect_supported_load_permutation_p (PR tree-optimization/53366)

[Jakub Jelinek]

Hi!

If there are exactly 2 complex loads and some other loads in SLP instance,
we sometimes miscompile things because vect_supported_load_permutation_p
skips important checks.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/4.7?

2012-05-21  Jakub Jelinek  

PR tree-optimization/53366
* tree-vect-slp.c (vect_supported_load_permutation_p): Don't shortcut
tests if complex_numbers == 2, but there are non-complex number loads
too.

* gcc.dg/torture/pr53366-1.c: New test.
* gcc.dg/torture/pr53366-2.c: New test.
* gcc.target/i386/pr53366-1.c: New test.
* gcc.target/i386/pr53366-2.c: New test.

--- gcc/tree-vect-slp.c.jj  2012-04-19 11:09:13.0 +0200
+++ gcc/tree-vect-slp.c 2012-05-21 12:46:40.078674688 +0200
@@ -1199,7 +1199,8 @@ vect_supported_load_permutation_p (slp_i
 
   /* We checked that this case ok, so there is no need to proceed with 
  permutation tests.  */
-  if (complex_numbers == 2)
+  if (complex_numbers == 2
+  && VEC_length (slp_tree, SLP_INSTANCE_LOADS (slp_instn)) == 2)
 {
   VEC_free (slp_tree, heap, SLP_INSTANCE_LOADS (slp_instn));
   VEC_free (int, heap, SLP_INSTANCE_LOAD_PERMUTATION (slp_instn));
--- gcc/testsuite/gcc.dg/torture/pr53366-1.c.jj 2012-05-21 12:55:47.220474343 
+0200
+++ gcc/testsuite/gcc.dg/torture/pr53366-1.c2012-05-21 12:53:40.0 
+0200
@@ -0,0 +1,70 @@
+/* PR tree-optimization/53366 */
+/* { dg-do run } */
+
+extern void abort (void);
+
+struct S { double v[3]; };
+struct T { struct S r, i; };
+struct U { struct T j[5]; };
+
+void
+foo (struct U *__restrict p1, struct U *__restrict p2,
+ struct S l1, struct S l2, struct S l3, struct S l4,
+ const double _Complex * __restrict x, int y, int z)
+{
+  int i, j;
+  while (y < z - 2)
+{
+  for (j = 0; j < 5; ++j)
+   {
+ double a = __real__ x[5 * y + j];
+ double b = __imag__ x[5 * y + j];
+ double c = __real__ x[5 * (y + 2) + j];
+ double d = __imag__ x[5 * (y + 2) + j];
+ double e = __real__ x[5 * (y + 1) + j];
+ double f = __imag__ x[5 * (y + 1) + j];
+ double g = __real__ x[5 * (y + 3) + j];
+ double h = __imag__ x[5 * (y + 3) + j];
+ for (i = 0; i < 3; ++i)
+   {
+ p1->j[j].r.v[i] += l2.v[i] * a;
+ p1->j[j].r.v[i] += l4.v[i] * c;
+ p1->j[j].i.v[i] += l2.v[i] * b;
+ p1->j[j].i.v[i] += l4.v[i] * d;
+ p2->j[j].r.v[i] += l3.v[i] * e;
+ p2->j[j].r.v[i] += l1.v[i] * g;
+ p2->j[j].i.v[i] += l3.v[i] * f;
+ p2->j[j].i.v[i] += l1.v[i] * h;
+   }
+   }
+  y += 4;
+}
+}
+
+_Complex double x[5005];
+struct U p1, p2;
+
+int
+main ()
+{
+  int i, j;
+  struct S l1, l2, l3, l4;
+  for (i = 0; i < 5005; ++i)
+x[i] = i + 1.0iF * (2 * i);
+  for (i = 0; i < 3; ++i)
+{
+  l1.v[i] = 1;
+  l2.v[i] = 2;
+  l3.v[i] = 3;
+  l4.v[i] = 4;
+}
+  foo (&p1, &p2, l1, l2, l3, l4, x, 5, 1000);
+  for (j = 0; j < 5; ++j)
+for (i = 0; i < 3; ++i)
+  if (p1.j[j].r.v[i] != 3752430 + j * 1494.0
+ || p1.j[j].i.v[i] != p1.j[j].r.v[i] * 2
+ || p2.j[j].r.v[i] != 2502450 + j * 996.0
+ || p2.j[j].i.v[i] != p2.j[j].r.v[i] * 2)
+   abort ();
+  return 0;
+}
--- gcc/testsuite/gcc.dg/torture/pr53366-2.c.jj 2012-05-21 12:55:50.011459264 
+0200
+++ gcc/testsuite/gcc.dg/torture/pr53366-2.c2012-05-21 12:54:48.0 
+0200
@@ -0,0 +1,43 @@
+/* PR tree-optimization/53366 */
+/* { dg-do run } */
+
+extern void abort (void);
+
+struct T { float r[3], i[3]; };
+struct U { struct T j[2]; };
+
+void __attribute__ ((noinline))
+foo (struct U *__restrict y, const float _Complex *__restrict x)
+{
+  int i, j;
+  for (j = 0; j < 2; ++j)
+{
+  float a = __real__ x[j];
+  float b = __imag__ x[j];
+  float c = __real__ x[j + 2];
+  float d = __imag__ x[j + 2];
+  for (i = 0; i < 3; ++i)
+{
+  y->j[j].r[i] = y->j[j].r[i] + a + c;
+  y->j[j].i[i] = y->j[j].i[i] + b + d;
+}
+}
+}
+
+_Complex float x[4];
+struct U y;
+
+int
+main ()
+{
+  int i, j;
+  for (i = 0; i < 4; ++i)
+x[i] = i + 1.0iF * (2 * i);
+  foo (&y, x);
+  for (j = 0; j < 2; ++j)
+for (i = 0; i < 3; ++i)
+  if (y.j[j].r[i] != __real__ (x[j] + x[j + 2])
+  || y.j[j].i[i] != __imag__ (x[j] + x[j + 2]))
+__builtin_abort ();
+  return 0;
+}
--- gcc/testsuite/gcc.target/i386/pr53366-1.c.jj2012-05-21 
12:56:54.091092771 +0200
+++ gcc/testsuite/gcc.target/i386/pr53366-1.c   2012-05-21 13:14:01.355210995 
+0200
@@ -0,0 +1,5 @@
+/* PR tree-optimization/53366 */
+/* { dg-do run { target avx_runtime } } */
+/* { dg-options "-O3 -mavx" } */
+
+#include "../../gcc.dg/torture/pr53366-1.c"
--- gcc/testsuite/gcc.target/i386/pr53366-2.c.jj2012-05-21 
12:56:56.868076994 +0200
+++ gcc/testsuite/gcc.target/i386/pr53366-2.c

Show hash table stats when -fmem-report

[Dimitrios Apostolou]

Hello list,

I ported a patch from last year's GSOC to current trunk, removing 
deprecated hash tables and adding some new ones. I also backed out a 
change that reduced collisions by decreasing load factor because it had 
created controversy, so this patch should be easily applicable.


CC'd whoever is relevant with subsystems or had commented on this last 
year. Some notes:


 * Is it OK that I included  in libiberty's hashtab.c?
 * Many hash tables are created with htab_create_ggc(), for example 
referenced_vars and default_defs in tree-ssa.c. I collect statistics in 
delete_tree_ssa() but maybe some are not deallocated in there but 
automatically garbage collected?
 * Obviously hash table sizes are inflated where two entries might 
reference the same element (for example in symtab_hash) but I don't handle 
this.
 * Maybe the best overall solution would be to add a string parameter to 
htab_create*() and store statistics in an internal hash table according to 
this string. Statistics would then be printed for all hash tables by 
iterating this internal table. Since it would cause a significant 
slowdown, -fmem-report would be better as a compile-time option than a 
run-time one. This is probably an overkill so I think I'll skip it.



Thanks,
Dimitris



2012-05-21 Dimitrios Apostolou 

Print various statistics about hash tables when called with
-fmem-report. If the tables are created once use
htab_dump_statistics(), if they are created/destroyed multiple
times then introduce global variables to track statistics.

* cgraph.c, cgraph.h:
(cgraph_dump_stats): New function to dump stats about hash tables.
* gcc/symtab.c, cgraph.h:
(symtab_dump_stats): New function to dump stats about hash tables.
* cgraph.c: (call_site_hash_{num,expands,searches,collisions}):
New globals to keep statistics about call_site_hash hash tables.
(cgraph_remove_node_callees,cgraph_remove_node): if (mem_report)
then keep statistics about hash tables.
* cselib.c, cselib.h (cselib_dump_stats): New function to dump
stats about cselib_hash_table.
* cselib.c (cselib_htab_{num,expands,searches,collisions}): New
globals to keep hash table statistics.
(cselib_finish): if (mem_report) keep hash table statistics.
* dwarf2out.c (dwarf2out_finish): Call htab_dump_statistics() if
-fmem_report.
* emit-rtl.c, emit-rtl.h (mem_attrs_dump_stats): New function to
dump statistics about mem_attrs_htab hash table.
* tree.h, tree-ssa.c (tree_ssa_dump_stats): New function to print
statistics about all referenced_vars and default_defs hash tables.
* tree-ssa.c (default_defs_{num,expands,searches,collisions})
(referenced_vars_{num,expands,searches,collisions}): new globals
to keep statistics about hash tables.
(delete_tree_ssa): Keep statistics for hash tables by
increasing the new global variables.
* tree.c (dump_tree_statistics): Call tree_ssa_dump_stats().
(print_type_hash_statistics): Used the new htab_dump_statistics()
function.
* var-tracking.c (vars_htab_{num,expands,searches,collisions})
(dropval_htab_{num,expands,searches,collisions})
(cv_htab_{num,expands,searches,collisions}): new globals to keep
hash table statistics.
(shared_hash_destroy, vt_finalize): Keep statistics by
increasing values of new global variables if -fmem-report.
* var-tracking.c, rtl.h (vt_dump_stats): New function to dump
stats about vars->htab, dropped_variables and value_chains hash
tables.
* toplev.c: Included cselib.h for cselib_dump_stats().
(dump_memory_report): Call all the above functions to provide
better statistics.

* hashtab.c, hashtab.h: Added "expands" variable to htab_t for
tracking total times the hash table was expanded.
* hashtab.c, hashtab.h (htab_dump_statistics, htab_collisions_num)
	(htab_searches_num, htab_expands_num): New functions for 
statistics.

* hashtab.c: Included assert.h for checks in htab_dump_statistics.
* cgraph.h, varpool.c (varpool_dump_stats): New function to dump
stats about varpool_hash hash table.

* libcpp/symtab.c, symtab.h: Added "expands" variable to
hash_table type for tracking total times the hash table was
expanded.
* symtab.c (ht_dump_statistics): Beautified stats output.



Number of expanded macros: 23397
Average number of tokens per macro expansion: 10

Line Table allocations during the compilation process
Number of ordinary maps used:  576 
Ordinary map used size: 13k
Number of ordinary maps allocated:1365 
Ordinary maps allocated size:   31k
Number of macro maps used:  20k
Macro maps used size:  494k
Macro maps locatio

[PATCH] Fix vectorizer ICE (PR tree-optimization/53409)

[Jakub Jelinek]

Hi!

On the following testcase we ICE, because op_def_stmt isn't inside
of the loop (phi is a degenerate phi referencing a phi result from before the
loop) and stmts outside of the loop don't have uid set (or it can contain
garbage).

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

2012-05-21  Jakub Jelinek  

PR tree-optimization/53409
* tree-vect-loop.c (vect_analyze_loop_operations): Don't check
vinfo_for_stmt (op_def_stmt) if op_def_stmt isn't inside loop.

* gcc.c-torture/compile/pr53409.c: New test.

--- gcc/tree-vect-loop.c.jj 2012-05-17 08:40:45.0 +0200
+++ gcc/tree-vect-loop.c2012-05-21 11:30:28.721333458 +0200
@@ -1327,7 +1327,9 @@ vect_analyze_loop_operations (loop_vec_i
 return false;
 
   op_def_stmt = SSA_NAME_DEF_STMT (phi_op);
-  if (!op_def_stmt || !vinfo_for_stmt (op_def_stmt))
+ if (!op_def_stmt
+ || !flow_bb_inside_loop_p (loop, gimple_bb (op_def_stmt))
+ || !vinfo_for_stmt (op_def_stmt))
 return false;
 
   if (STMT_VINFO_RELEVANT (vinfo_for_stmt (op_def_stmt))
--- gcc/testsuite/gcc.c-torture/compile/pr53409.c.jj2012-05-21 
11:33:23.621318856 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr53409.c   2012-05-21 
11:33:13.0 +0200
@@ -0,0 +1,19 @@
+/* PR tree-optimization/53409 */
+
+int a, c, d, e, f;
+int b[0];
+
+int
+main ()
+{
+  if (f)
+e = 0;
+  int g = d;
+  for (c = 0; c <= 1; c++)
+{
+  for (a = 0; a <= 1; a = (char) a + 1)
+   b[c] = g;
+  a = 0;
+}
+  return 0;
+}

Jakub

[PATCH] Fix fold_binary_loc vector handling (PR tree-optimization/53410)

[Jakub Jelinek]

Hi!

As the following testcases show, some places in fold_binary_loc
(haven't checked other routines) can attempt to optimize even vector
expressions, but in that case build_int_cst can't be used.
Instead, for zeros build_zero_cst can be used, for the two places
which need to build 1 I'm just folding the original one argument.

On the 4.7 branch (patch attached after the 4.8 version) there are fewer
spots that need changing, because integer_zerop/integer_onep don't return
true for vectors.

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

2012-05-21  Jakub Jelinek  

PR tree-optimization/53410
* fold-const.c (fold_binary_loc): Use build_zero_cst (type)
instead of build_int_cst (type, 0) where vector types might be
involved. Instead of build_int_cst (type, 1) convert the original
integer_onep argument to the desired type.

* gcc.c-torture/compile/pr53410-1.c: New test.
* gcc.c-torture/compile/pr53410-2.c: New test.

--- gcc/fold-const.c.jj 2012-05-12 10:21:06.0 +0200
+++ gcc/fold-const.c2012-05-21 10:38:36.928229511 +0200
@@ -11245,7 +11245,7 @@ fold_binary_loc (location_t loc,
  && integer_onep (TREE_OPERAND (arg0, 1))
  && integer_onep (arg1))
return fold_build2_loc (loc, EQ_EXPR, type, arg0,
-   build_int_cst (TREE_TYPE (arg0), 0));
+   build_zero_cst (TREE_TYPE (arg0)));
 
   /* Fold (X & Y) ^ Y as ~X & Y.  */
   if (TREE_CODE (arg0) == BIT_AND_EXPR
@@ -11355,21 +11355,25 @@ fold_binary_loc (location_t loc,
  && integer_onep (TREE_OPERAND (arg0, 1))
  && integer_onep (arg1))
{
+ tree tem2;
  tem = TREE_OPERAND (arg0, 0);
- return fold_build2_loc (loc, EQ_EXPR, type,
- fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE 
(tem), tem,
-  build_int_cst (TREE_TYPE (tem), 1)),
- build_int_cst (TREE_TYPE (tem), 0));
+ tem2 = fold_convert_loc (loc, TREE_TYPE (tem), arg1);
+ tem2 = fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE (tem),
+ tem, tem2);
+ return fold_build2_loc (loc, EQ_EXPR, type, tem2,
+ build_zero_cst (TREE_TYPE (tem)));
}
   /* Fold ~X & 1 as (X & 1) == 0.  */
   if (TREE_CODE (arg0) == BIT_NOT_EXPR
  && integer_onep (arg1))
{
+ tree tem2;
  tem = TREE_OPERAND (arg0, 0);
- return fold_build2_loc (loc, EQ_EXPR, type,
- fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE 
(tem), tem,
-  build_int_cst (TREE_TYPE (tem), 1)),
- build_int_cst (TREE_TYPE (tem), 0));
+ tem2 = fold_convert_loc (loc, TREE_TYPE (tem), arg1);
+ tem2 = fold_build2_loc (loc, BIT_AND_EXPR, TREE_TYPE (tem),
+ tem, tem2);
+ return fold_build2_loc (loc, EQ_EXPR, type, tem2,
+ build_zero_cst (TREE_TYPE (tem)));
}
   /* Fold !X & 1 as X == 0.  */
   if (TREE_CODE (arg0) == TRUTH_NOT_EXPR
@@ -11377,7 +11381,7 @@ fold_binary_loc (location_t loc,
{
  tem = TREE_OPERAND (arg0, 0);
  return fold_build2_loc (loc, EQ_EXPR, type, tem,
- build_int_cst (TREE_TYPE (tem), 0));
+ build_zero_cst (TREE_TYPE (tem)));
}
 
   /* Fold (X ^ Y) & Y as ~X & Y.  */
@@ -12893,13 +12897,13 @@ fold_binary_loc (location_t loc,
   if (TREE_CODE (arg0) == BIT_XOR_EXPR
  && operand_equal_p (TREE_OPERAND (arg0, 1), arg1, 0))
return fold_build2_loc (loc, code, type, TREE_OPERAND (arg0, 0),
-   build_int_cst (TREE_TYPE (arg0), 0));
+   build_zero_cst (TREE_TYPE (arg0)));
   /* Likewise (X ^ Y) == X becomes Y == 0.  X has no side-effects.  */
   if (TREE_CODE (arg0) == BIT_XOR_EXPR
  && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0)
  && reorder_operands_p (TREE_OPERAND (arg0, 1), arg1))
return fold_build2_loc (loc, code, type, TREE_OPERAND (arg0, 1),
-   build_int_cst (TREE_TYPE (arg0), 0));
+   build_zero_cst (TREE_TYPE (arg0)));
 
   /* (X ^ C1) op C2 can be rewritten as X op (C1 ^ C2).  */
   if (TREE_CODE (arg0) == BIT_XOR_EXPR
@@ -12987,7 +12991,7 @@ fold_binary_loc (location_t loc,
  BIT_XOR_EXPR, itype,
  arg00, arg10),
 arg01),
-   build_int_cst (itype, 0));
+   build_zero_cst (itype));
 
  if (operand_equal_p (arg01, arg10, 0))
   

[PATCH 2/2] Better system header location detection for built-in macro tokens

[Dodji Seketeli]

Hello,

The location for a built-in macro token is BUILTIN_LOCATION.  When we
see that location value, we cannot know if that token was used in a
system header or not.  And that can trigger some unwanted warnings on
e.g, the use of __LONG_LONG_MAX__ built-in macro in system headers
when we compile with -pedantic, like in the test case accompanying
this patch.

In that case, I think we ought to look at the location for the
expansion point of the built-in macro instead.

Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.

libcpp/

* line-map.c (linemap_location_in_system_header_p): Check
expansion point location for built-in macro tokens.

gcc/testsuite/

* g++.dg/cpp/limits.C: New test.
---
 gcc/testsuite/g++.dg/cpp/limits.C |   21 +
 libcpp/line-map.c |   18 ++
 2 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp/limits.C

diff --git a/gcc/testsuite/g++.dg/cpp/limits.C 
b/gcc/testsuite/g++.dg/cpp/limits.C
new file mode 100644
index 000..b64e1e2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp/limits.C
@@ -0,0 +1,21 @@
+// { dg-options "-pedantic" }
+// { dg-do compile }
+
+#include 
+
+// Compiling this with -pedantic was wrongly triggering this error:
+// libstdc++-v3/include/limits:1269:45: warning : use of C++0x long long 
integer constant [-Wlong-long]
+//   min() _GLIBCXX_USE_NOEXCEPT { return -__LONG_LONG_MAX__ - 1; }
+// ^
+// libstdc++-v3/include/limits:1272:44: warning : use of C++0x long long 
integer constant [-Wlong-long]
+//   max() _GLIBCXX_USE_NOEXCEPT { return __LONG_LONG_MAX__; }
+//^
+// libstdc++-v3/include/limits:1342:44: warning : use of C++0x long long 
integer constant [-Wlong-long]
+//   max() _GLIBCXX_USE_NOEXCEPT { return __LONG_LONG_MAX__ * 2ULL + 1
+//^
+
+int
+main ()
+{
+return 0;
+}
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 6e514e5..5a2ca0f 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -754,12 +754,22 @@ linemap_location_in_system_header_p (struct line_maps 
*set,
 source_location location)
 {
   const struct line_map *map = NULL;
-
-  location =
+  source_location loc =
 linemap_resolve_location (set, location, LRK_SPELLING_LOCATION, &map);
 
-  if (location < RESERVED_LOCATION_COUNT)
-return false;
+  if (loc < RESERVED_LOCATION_COUNT)
+{
+  /* Maybe LOCATION is for a token that comes from the expansion
+of a built-in macro.  In that case, we cannot know from its
+spelling location (which is thus a reserved location) where
+exactly the token is located.  So let's see where that
+built-in macro has been expanded, instead.  */
+  loc = linemap_resolve_location (set, location,
+ LRK_MACRO_EXPANSION_POINT,
+ &map);
+  if (loc < RESERVED_LOCATION_COUNT)
+   return false;
+}
 
   return LINEMAP_SYSP (map);
 }
-- 
Dodji

[PATCH 1/2] PR c++/53322 - -Wunused-local-typedefs is not enabled by Wall or Wunused

[Dodji Seketeli]

Hello,

As the audit trail of this shows, -Wunused-local-typedefs is not
turned on by -Wunused after all.  Sigh.

Now that we have the EnabledBy construct for the *.opt files, it's
more precise and concise to use that to make -Wunused-local-typedefs
be triggered by -Wunused.

I have changed the gcc+.dg/warn/Wunused-local-typedefs.C test case to
make it use -Wunused instead of -Wunused-local-typedefs.  I had to
adjust it to avoid the warnings due to the other -W* options triggered
by -Wunused there.

While testing the compiler, it turned out that some local typedefs
were not being used when the experimental "Concepts" support is turned
off, in the libstdc++ test suite.  I also had to remove some obvious
useless local typedef usage in the fortran front-end.  Fixed thus.

Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.

gcc/c-family/

PR c++/53322
* c.opt (Wunused-local-typedefs): Use EnabledBy(Wunused).

libstdc++-v3/

PR c++/53322
* include/bits/stl_algobase.h (lower_bound)
(lexicographical_compare): Do not declare unused local typedefs
here when Concepts are turned off.

gcc/fortran/

PR c++/53322
* f95-lang.c (gfc_init_builtin_functions): Remove the unused
typedef builtin_type.

gcc/testsuite/

PR c++/53322
* g++.dg/warn/Wunused-local-typedefs.C: Adjust to use -Wunused
instead of -Wunused-local-typedefs.
---
 gcc/c-family/c.opt |2 +-
 gcc/fortran/f95-lang.c |1 -
 gcc/testsuite/g++.dg/warn/Wunused-local-typedefs.C |   16 
 libstdc++-v3/include/bits/stl_algobase.h   |4 
 4 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 53d9752..0b72d79 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -671,7 +671,7 @@ C ObjC Var(warn_unsuffixed_float_constants) Warning
 Warn about unsuffixed float constants
 
 Wunused-local-typedefs
-C ObjC C++ ObjC++ Var(warn_unused_local_typedefs) Warning
+C ObjC C++ ObjC++ Var(warn_unused_local_typedefs) Warning EnabledBy(Wunused)
 Warn when typedefs locally defined in a function are not used
 
 Wunused-macros
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 3f0c303..7250ca2 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -641,7 +641,6 @@ gfc_init_builtin_functions (void)
 #undef DEF_POINTER_TYPE
 BT_LAST
   };
-  typedef enum builtin_type builtin_type;
 
   tree mfunc_float[6];
   tree mfunc_double[6];
diff --git a/gcc/testsuite/g++.dg/warn/Wunused-local-typedefs.C 
b/gcc/testsuite/g++.dg/warn/Wunused-local-typedefs.C
index 87feb52..4fc8640 100644
--- a/gcc/testsuite/g++.dg/warn/Wunused-local-typedefs.C
+++ b/gcc/testsuite/g++.dg/warn/Wunused-local-typedefs.C
@@ -1,5 +1,5 @@
 // Origin PR c++/33255
-// { dg-options "-Wunused-local-typedefs" }
+// { dg-options "-Wunused" } <-- should trigger -Wunused-local-typedefs
 // { dg-do compile }
 
 void
@@ -59,7 +59,7 @@ test3_tmpl(void)
 {
 typedef struct ST foo;
 ST v;
-const foo &var = v;
+const foo __attribute__((unused))&var = v;
 }
 
 void
@@ -72,7 +72,7 @@ void
 test4(void)
 {
   typedef int foo;
-  int vec[1] = {sizeof (foo)};
+  int __attribute__((unused))vec[1] = {sizeof (foo)};
 }
 
 void
@@ -87,11 +87,11 @@ test5(void)
   typedef C0 T4;
 
   int v0 = (T0) 2;
-  char v1 = static_cast (0);
-  reinterpret_cast (&v0);
+  char __attribute__((unused)) v1 = static_cast (0);
+  if (reinterpret_cast (&v0));
   unsigned* const c = 0;
-  unsigned* v2 = const_cast (c);
-  C0 *p0 = 0;
+  unsigned* __attribute__((unused))v2 = const_cast (c);
+  C0 *__attribute__((unused))p0 = 0;
   C1 *p1 = 0;
   p0 = dynamic_cast (p1);  
 }
@@ -101,7 +101,7 @@ test6(void)
 {
   struct C0 {};
   typedef C0 foo;
-  C0 *v = new foo;
+  C0 *__attribute__((unused))v = new foo;
 }
 
 template
diff --git a/libstdc++-v3/include/bits/stl_algobase.h 
b/libstdc++-v3/include/bits/stl_algobase.h
index a48cf9a..fe30f6c 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -944,8 +944,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 lower_bound(_ForwardIterator __first, _ForwardIterator __last,
const _Tp& __val)
 {
+#ifdef _GLIBCXX_CONCEPT_CHECKS
   typedef typename iterator_traits<_ForwardIterator>::value_type
_ValueType;
+#endif
   typedef typename iterator_traits<_ForwardIterator>::difference_type
_DistanceType;
 
@@ -1083,9 +1085,11 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
 lexicographical_compare(_II1 __first1, _II1 __last1,
_II2 __first2, _II2 __last2)
 {
+#ifdef _GLIBCXX_CONCEPT_CHECKS
   // concept requirements
   typedef typename iterator_traits<_II1>::value_type _ValueType1;
   typedef typename iterator_traits<_II2>::value_type _ValueType2;
+#endif
   __glibcxx_function_requires(_InputIteratorConcept

[C++ Patch] PR 40821

[Paolo Carlini]

Hi,

this is a rather old diagnostic issue, already reported at least 3 
times, recently too.


I tried various small variants of the same idea, and the below appears 
to work well enough: it tells the user about all the missing open and 
closed parentheses and overall the diagnostic is quite similar in terms 
of quality and quantity to what EDG produces, for example.


Booted and tested x86_64-linux.

Thanks,
Paolo.


/cp
2012-05-21  Paolo Carlini  

PR c++/40821
* parser.c (cp_parser_attributes_opt): Enforce error checking of
unbalanced parentheses in the presence of tentative parsing.

/testsuite
2012-05-21  Paolo Carlini  

PR c++/40821
* g++.dg/ext/attrib46.C: New.

Index: testsuite/g++.dg/ext/attrib46.C
===
--- testsuite/g++.dg/ext/attrib46.C (revision 0)
+++ testsuite/g++.dg/ext/attrib46.C (revision 0)
@@ -0,0 +1,4 @@
+// PR c++/40821
+
+struct __attribute__((aligned(8)) S1 { int i; }; // { dg-error "expected" }
+struct __attribute__( aligned(8)  S2 { int i; }; // { dg-error "expected" }
Index: cp/parser.c
===
--- cp/parser.c (revision 187704)
+++ cp/parser.c (working copy)
@@ -20052,6 +20052,7 @@ cp_parser_attributes_opt (cp_parser* parser)
 {
   cp_token *token;
   tree attribute_list;
+  bool ok = true;
 
   /* Peek at the next token.  */
   token = cp_lexer_peek_token (parser->lexer);
@@ -20076,8 +20077,12 @@ cp_parser_attributes_opt (cp_parser* parser)
attribute_list = NULL;
 
   /* Look for the two `)' tokens.  */
-  cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
-  cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
+  if (!cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN))
+   ok = false;
+  if (!cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN))
+   ok = false;
+  if (!ok)
+   cp_parser_skip_to_end_of_statement (parser);
 
   /* Add these new attributes to the list.  */
   attributes = chainon (attributes, attribute_list);

[Ada] Remove call to expand_decl

[Michael Matz]

Hi Eric,

there's a call to expand_decl in gcc-interface/utils.c, which is used only 
for setting up some field of CONST_DECLs.  I'm working on removing this 
function, and removing that call from utils.c is seemingly working just 
fine.  It came in with :

2005-11-14  Thomas Quinot  
Olivier Hainque  
Eric Botcazou  
...
(create_var_decl): call expand_decl for CONST_DECLs, to set MODE, ALIGN
SIZE and SIZE_UNIT which we need for later back-annotations.

I don't understand the reference to "back-annotations" so I don't really 
know if this need was meanwhile solved differently, or if it's still 
necessary.  As said, there are no testcases in GCC (or in the Ada compiler 
itself) that would exhibit any problem with that setup removed.

Can you think of any or would a patch removing that call be approved?  
I.e. the patch below (regstrapped on x86_64-linux).


Ciao,
Michael.

* gcc-interface/utils.c (create_var_decl_1): Remove call to 
expand_decl.

Index: ada/gcc-interface/utils.c
===
--- ada/gcc-interface/utils.c   (revision 187708)
+++ ada/gcc-interface/utils.c   (working copy)
@@ -2227,8 +2227,6 @@ create_var_decl_1 (tree var_name, tree a
   if (global_bindings_p ())
rest_of_decl_compilation (var_decl, true, 0);
 }
-  else
-expand_decl (var_decl);

   return var_decl;
 }

Re: [PATCH] Hoist adjacent pointer loads

[Richard Guenther]

On Thu, May 3, 2012 at 4:33 PM, William J. Schmidt
 wrote:
> This patch was posted for comment back in February during stage 4.  It
> addresses a performance issue noted in the EEMBC routelookup benchmark
> on a common idiom:
>
>  if (...)
>    x = y->left;
>  else
>    x = y->right;
>
> If the two loads can be hoisted out of the if/else, the if/else can be
> replaced by a conditional move instruction on architectures that support
> one.  Because this speculates one of the loads, the patch constrains the
> optimization to avoid introducing page faults.
>
> Bootstrapped and regression tested on powerpc-unknown-linux-gnu with no
> new failures.  The patch provides significant improvement to the
> routelookup benchmark, and is neutral on SPEC cpu2000/cpu2006.
>
> One question is what optimization level should be required for this.
> Because of the speculation, -O3 might be in order.  I don't believe
> -Ofast is required as there is no potential correctness issue involved.
> Right now the patch doesn't check the optimization level (like the rest
> of the phi-opt transforms), which is likely a poor choice.
>
> Ok for trunk?
>
> Thanks,
> Bill
>
>
> 2012-05-03  Bill Schmidt  
>
>        * tree-ssa-phiopt.c (tree_ssa_phiopt_worker): Add argument to forward
>        declaration.
>        (hoist_adjacent_loads, gate_hoist_loads): New forward declarations.
>        (tree_ssa_phiopt): Call gate_hoist_loads.
>        (tree_ssa_cs_elim): Add parm to tree_ssa_phiopt_worker call.
>        (tree_ssa_phiopt_worker): Add do_hoist_loads to formal arg list; call
>        hoist_adjacent_loads.
>        (local_reg_dependence): New function.
>        (local_mem_dependence): Likewise.
>        (hoist_adjacent_loads): Likewise.
>        (gate_hoist_loads): Likewise.
>        * common.opt (fhoist-adjacent-loads): New switch.
>        * Makefile.in (tree-ssa-phiopt.o): Added dependencies.
>        * params.def (PARAM_MIN_CMOVE_STRUCT_ALIGN): New param.
>
>
> Index: gcc/tree-ssa-phiopt.c
> ===
> --- gcc/tree-ssa-phiopt.c       (revision 187057)
> +++ gcc/tree-ssa-phiopt.c       (working copy)
> @@ -37,9 +37,17 @@ along with GCC; see the file COPYING3.  If not see
>  #include "cfgloop.h"
>  #include "tree-data-ref.h"
>  #include "tree-pretty-print.h"
> +#include "gimple-pretty-print.h"
> +#include "insn-config.h"
> +#include "expr.h"
> +#include "optabs.h"
>
> +#ifndef HAVE_conditional_move
> +#define HAVE_conditional_move (0)
> +#endif
> +
>  static unsigned int tree_ssa_phiopt (void);
> -static unsigned int tree_ssa_phiopt_worker (bool);
> +static unsigned int tree_ssa_phiopt_worker (bool, bool);
>  static bool conditional_replacement (basic_block, basic_block,
>                                     edge, edge, gimple, tree, tree);
>  static int value_replacement (basic_block, basic_block,
> @@ -53,6 +61,9 @@ static bool cond_store_replacement (basic_block, b
>  static bool cond_if_else_store_replacement (basic_block, basic_block, 
> basic_block);
>  static struct pointer_set_t * get_non_trapping (void);
>  static void replace_phi_edge_with_variable (basic_block, edge, gimple, tree);
> +static void hoist_adjacent_loads (basic_block, basic_block,
> +                                 basic_block, basic_block);
> +static bool gate_hoist_loads (void);
>
>  /* This pass tries to replaces an if-then-else block with an
>    assignment.  We have four kinds of transformations.  Some of these
> @@ -138,12 +149,56 @@ static void replace_phi_edge_with_variable (basic_
>      bb2:
>        x = PHI ;
>
> -   A similar transformation is done for MAX_EXPR.  */
> +   A similar transformation is done for MAX_EXPR.
>
> +
> +   This pass also performs a fifth transformation of a slightly different
> +   flavor.
> +
> +   Adjacent Load Hoisting
> +   --
> +
> +   This transformation replaces
> +
> +     bb0:
> +       if (...) goto bb2; else goto bb1;
> +     bb1:
> +       x1 = ().field1;
> +       goto bb3;
> +     bb2:
> +       x2 = ().field2;
> +     bb3:
> +       # x = PHI ;
> +
> +   with
> +
> +     bb0:
> +       x1 = ().field1;
> +       x2 = ().field2;
> +       if (...) goto bb2; else goto bb1;
> +     bb1:
> +       goto bb3;
> +     bb2:
> +     bb3:
> +       # x = PHI ;
> +
> +   The purpose of this transformation is to enable generation of conditional
> +   move instructions such as Intel CMOVE or PowerPC ISEL.  Because one of
> +   the loads is speculative, the transformation is restricted to very
> +   specific cases to avoid introducing a page fault.  We are looking for
> +   the common idiom:
> +
> +     if (...)
> +       x = y->left;
> +     else
> +       x = y->right;
> +
> +   where left and right are typically adjacent pointers in a tree structure. 
>  */
> +
>  static unsigned int
>  tree_ssa_phiopt (void)
>  {
> -  return tree_ssa_phiopt_worker (false);
> +  return tree_ssa_phiopt_worker (false, gate_hoist_loads ());
>  }
>
>  /* This pass tri

Re: [Patch]: Fix very large frame bug on i386

[Tristan Gingold]

Ping for:

On May 15, 2012, at 11:10 AM, Tristan Gingold wrote:

> Hi,
> 
> use of 'unsigned int' for i386.c:ix86_compute_frame_layout 
> stack_alignment_needed results in truncation of frame offset in code such as:
> 
> offset = (offset + stack_alignment_needed - 1) & -stack_alignment_needed
> 
> (as it is -stack_alignment_needed that is converted to HOST_WIDE_INT).
> 
> As a consequence, frames larger than 4GB are squeezed.
> 
> Also, the frame field of struct ix86_frame is never used.
> 
> Bootstrapped and reg-tested on x86_64 GNU/Linux, without regressions.
> 
> Ok for trunk ?
> 
> Tristan.
> 
> 2012-05-15  Tristan Gingold  
> 
>   * config/i386/i386.c (struct ix86_frame): Remove unused frame field.
>   (ix86_compute_frame_layout): Fix type of stack_alignment_needed
>   and preferred_alignment.
> 
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index ad4739b..353ee53 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -2408,7 +2408,6 @@ struct ix86_frame
>   int va_arg_size;
>   int red_zone_size;
>   int outgoing_arguments_size;
> -  HOST_WIDE_INT frame;
> 
>   /* The offsets relative to ARG_POINTER.  */
>   HOST_WIDE_INT frame_pointer_offset;
> @@ -8937,9 +8936,9 @@ ix86_builtin_setjmp_frame_value (void)
> static void
> ix86_compute_frame_layout (struct ix86_frame *frame)
> {
> -  unsigned int stack_alignment_needed;
> +  unsigned HOST_WIDE_INT stack_alignment_needed;
>   HOST_WIDE_INT offset;
> -  unsigned int preferred_alignment;
> +  unsigned HOST_WIDE_INT preferred_alignment;
>   HOST_WIDE_INT size = get_frame_size ();
>   HOST_WIDE_INT to_allocate;
> 
> 

[PATCH] Fix PR53408

[Richard Guenther]

This fixes PR53408, we ICE when we encounter an unhandled situation
in induction handling for outer loop vectorization - the fix is to
properly reject this at analysis time rather than asserting and
ICEing, of course.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

2012-05-21  Richard Guenther  

PR tree-optimization/53408
* tree-vect-loop.c (vectorizable_induction): Properly check
the restriction that we cannot handle induction results from
the inner loop outside of the outer loop.

* gcc.dg/torture/pr53408.c: New testcase.

Index: gcc/tree-vect-loop.c
===
*** gcc/tree-vect-loop.c(revision 187706)
--- gcc/tree-vect-loop.c(working copy)
*** vectorizable_induction (gimple phi, gimp
*** 5061,5072 
tree vec_def;
  
gcc_assert (ncopies >= 1);
!   /* FORNOW. This restriction should be relaxed.  */
!   if (nested_in_vect_loop_p (loop, phi) && ncopies > 1)
  {
!   if (vect_print_dump_info (REPORT_DETAILS))
! fprintf (vect_dump, "multiple types in nested loop.");
!   return false;
  }
  
if (!STMT_VINFO_RELEVANT_P (stmt_info))
--- 5061,5106 
tree vec_def;
  
gcc_assert (ncopies >= 1);
!   /* FORNOW. These restrictions should be relaxed.  */
!   if (nested_in_vect_loop_p (loop, phi))
  {
!   imm_use_iterator imm_iter;
!   use_operand_p use_p;
!   gimple exit_phi;
!   edge latch_e;
!   tree loop_arg;
! 
!   if (ncopies > 1)
!   {
! if (vect_print_dump_info (REPORT_DETAILS))
!   fprintf (vect_dump, "multiple types in nested loop.");
! return false;
!   }
! 
!   exit_phi = NULL;
!   latch_e = loop_latch_edge (loop->inner);
!   loop_arg = PHI_ARG_DEF_FROM_EDGE (phi, latch_e);
!   FOR_EACH_IMM_USE_FAST (use_p, imm_iter, loop_arg)
!   {
! if (!flow_bb_inside_loop_p (loop->inner,
! gimple_bb (USE_STMT (use_p
!   {
! exit_phi = USE_STMT (use_p);
! break;
!   }
!   }
!   if (exit_phi)
!   {
! stmt_vec_info exit_phi_vinfo  = vinfo_for_stmt (exit_phi);
! if (!(STMT_VINFO_RELEVANT_P (exit_phi_vinfo)
!   && !STMT_VINFO_LIVE_P (exit_phi_vinfo)))
!   {
! if (vect_print_dump_info (REPORT_DETAILS))
!   fprintf (vect_dump, "inner-loop induction only used outside "
!"of the outer vectorized loop.");
! return false;
!   }
!   }
  }
  
if (!STMT_VINFO_RELEVANT_P (stmt_info))
Index: gcc/testsuite/gcc.dg/torture/pr53408.c
===
*** gcc/testsuite/gcc.dg/torture/pr53408.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr53408.c  (revision 0)
***
*** 0 
--- 1,20 
+ /* { dg-do compile } */
+ 
+ int a, b, c, d, e;
+ void
+ fn1 ()
+ {
+   int f, g;
+   char h = 0;
+   b = 0;
+   for (; b < 32; b++)
+ {
+   g = h > e ? h : h << 1;
+   f = g && a ? 0 : 1;
+   h = 1;
+   for (; h > 0; h = h + 1)
+   c = 0 < h | f;
+ }
+   if (h)
+ d = 0;
+ }

Ping: [Patch]: Fix typo in common/config/ia64/ia64-common.c

[Tristan Gingold]

Ping for:

On May 15, 2012, at 10:52 AM, Tristan Gingold wrote:

> hi,
> 
> looks like a typo...
> 
> Ok for trunk ?
> 
> Tristan.
> 
> 2012-05-14  Tristan Gingold  
> 
>   * common/config/ia64/ia64-common.c (ia64_except_unwind_info): Fix typo.
> 
> diff --git a/gcc/common/config/ia64/ia64-common.c 
> b/gcc/common/config/ia64/ia64-
> index 1168253..79aed6a 100644
> --- a/gcc/common/config/ia64/ia64-common.c
> +++ b/gcc/common/config/ia64/ia64-common.c
> @@ -71,8 +71,8 @@ enum unwind_info_type
> ia64_except_unwind_info (struct gcc_options *opts)
> {
>   /* Honor the --enable-sjlj-exceptions configure switch.  */
> -#ifdef CONFIG_UNWIND_EXCEPTIONS
> -  if (CONFIG_UNWIND_EXCEPTIONS)
> +#ifdef CONFIG_SJLJ_EXCEPTIONS
> +  if (CONFIG_SJLJ_EXCEPTIONS)
> return UI_SJLJ;
> #endif
> 
> 

Re: Turn check macros into functions. (issue6188088)

[Richard Guenther]

On Mon, May 21, 2012 at 12:18 PM, Richard Guenther
 wrote:
> On Sun, May 20, 2012 at 9:10 PM, Diego Novillo  wrote:
>> On 12-05-20 13:59 , Richard Henderson wrote:
>>>
>>> On 05/18/2012 04:48 PM, Diego Novillo wrote:

 We can do this in trunk today using a variant of Lawrence's original
 patch (http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01649.html). This
 uses no C++ features, though it weakens type checking by removing away
 constness.

 In the cxx-conversion branch, we can use overloads, which will DTRT
 with const.

 My question is, what do folks prefer?

 a) The trunk patch today, using no C++ features.
 b) Wait for the cxx-conversion variant?
>>>
>>>
>>> Surely (check(t), t) also works, and also strt wrt const.
>>
>>
>> My concern with (check(t), t) is that it evaluates 't' twice.  It may not be
>> a big deal, however.  In which case, I'm OK with that alternative.
>
> Hum.  A source of possibly nasty errors.
>
> I'd like to avoid using templates here though.  Going with two overloads
> for each function sounds like the best solution to me, thus delay the
> change to cxx-switch time.
>
> What's the effect on bootstrap times?  Remember we build stage1 with -O0
> and checking enabled always ...

Btw, as of doing this all for the sake of debuggability of GCC - for debugging
you do _not_ want to have gdb invoke the checking functions, because then
you ICE in the inferior if you mis-type.  Instead ideally gdb would use the
non-checking variant or even better, diagnose misuse itself (which means
using a python implementation rather than the gcc macro or an inferior call).

So - why not provide proper (python) implementations of the various
accessors in .gdbinit?

Richard.

> Richard.
>
>>
>> Diego.
>>

Re: Symbol table 21/many: analyze initializers of external vars

[Jan Hubicka]

> > + 2012-05-17  Jan Hubicka  
> > +
> > +       * lto-symtab.c (lto_symtab_resolve_symbols): Preffer decl with 
> > constructor
> > +       over decl without.
> > +       * cgraph.c (cgraph_remove_node): Clear also body of unanalyzed 
> > nodes.
> > +       * cgraph.h (varpool_can_remove_if_no_refs): Handle external 
> > correctly.
> > +       * cgraphunit.c (process_function_and_variable_attributes): Finalize
> > +       extrnal decls.
> > +       (mark_functions_to_output): Also accept bodies for functions with 
> > clones.
> > +       (output_in_order): Skip external vars.
> > +       * lto-cgraph.c (lto_output_node): External functions are never in 
> > other
> > +       partition.
> > +       (lto_output_varpool_node): Likewise.
> > +       * lto-streamer-out.c (lto_write_tree): Always use error_mark_nodes 
> > for
> > +       forgotten initializers.
> > +       * ipa.c (process_references): Handle external vars.
> > +       (symtab_remove_unreachable_nodes): Update to handle external vars.
> > +       (varpool_externally_visible_p): External vars are externally 
> > visible.
> > +       * gimple-fold.c (can_refer_decl_in_current_unit_p): Update.
> > +       * varpool.c (varpool_remove_node): Remove constructor.
> > +       (decide_is_variable_needed): Handle externals.
> > +       (varpool_remove_unreferenced_decls): Likewise.
> > +
> 
> This caused:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53428

This is unexpected. The patch should be generally no-op on non-C++ non-Ada 
code.  I will double
check. Thanks for tracking this down.

Honza

[PATCH] Fix gfortran.dg/pr46519-2.f90 FAIL

[Richard Guenther]

Seem to have missed this one.

Committed as obvious.

Richard.

2012-05-21  Richard Guenther  

* gfortran.dg/pr46519-2.f90: Adjust to avoid memset transform.

Index: gcc/testsuite/gfortran.dg/pr46519-2.f90
===
--- gcc/testsuite/gfortran.dg/pr46519-2.f90 (revision 187706)
+++ gcc/testsuite/gfortran.dg/pr46519-2.f90 (working copy)
@@ -10,7 +10,7 @@
   REAL  :: fluxout
   INTEGER   :: min_q, max_q, var
   do k=kts,kte
-praci(k)=0.0
+praci(k)=1.0
   enddo
   min_q=kte
   max_q=kts-1

[PATCH] Disallow memset recognition for volatile stores

[Richard Guenther]

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2012-05-21  Richard Guenther  

* tree-loop-distribution.c (can_generate_builtin): Reject
volatile stmts.

* gcc.dg/torture/ldist-1.c: New testcase.

Index: gcc/tree-loop-distribution.c
===
*** gcc/tree-loop-distribution.c(revision 187704)
--- gcc/tree-loop-distribution.c(working copy)
*** can_generate_builtin (struct graph *rdg,
*** 822,829 
nb_reads++;
  else if (RDG_MEM_WRITE_STMT (rdg, i))
{
nb_writes++;
!   if (stmt_with_adjacent_zero_store_dr_p (RDG_STMT (rdg, i)))
  stores_zero++;
}
  
--- 822,831 
nb_reads++;
  else if (RDG_MEM_WRITE_STMT (rdg, i))
{
+   gimple stmt = RDG_STMT (rdg, i);
nb_writes++;
!   if (!gimple_has_volatile_ops (stmt)
!   && stmt_with_adjacent_zero_store_dr_p (stmt))
  stores_zero++;
}
  
Index: gcc/testsuite/gcc.dg/torture/ldist-1.c
===
*** gcc/testsuite/gcc.dg/torture/ldist-1.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/ldist-1.c  (revision 0)
***
*** 0 
--- 1,12 
+ /* { dg-do compile } */
+ /* { dg-options "-ftree-loop-distribute-patterns" } */
+ 
+ void foo (volatile int *p, int n)
+ {
+   int i;
+   for (i = 0; i < n; ++i)
+ p[i] = 0;
+ }
+ 
+ /* { dg-final { scan-assembler-not "memset" } } */
+ /* { dg-final { cleanup-tree-dump "ldist" } } */

Re: Turn check macros into functions. (issue6188088)

[Richard Guenther]

On Sun, May 20, 2012 at 9:10 PM, Diego Novillo  wrote:
> On 12-05-20 13:59 , Richard Henderson wrote:
>>
>> On 05/18/2012 04:48 PM, Diego Novillo wrote:
>>>
>>> We can do this in trunk today using a variant of Lawrence's original
>>> patch (http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01649.html). This
>>> uses no C++ features, though it weakens type checking by removing away
>>> constness.
>>>
>>> In the cxx-conversion branch, we can use overloads, which will DTRT
>>> with const.
>>>
>>> My question is, what do folks prefer?
>>>
>>> a) The trunk patch today, using no C++ features.
>>> b) Wait for the cxx-conversion variant?
>>
>>
>> Surely (check(t), t) also works, and also strt wrt const.
>
>
> My concern with (check(t), t) is that it evaluates 't' twice.  It may not be
> a big deal, however.  In which case, I'm OK with that alternative.

Hum.  A source of possibly nasty errors.

I'd like to avoid using templates here though.  Going with two overloads
for each function sounds like the best solution to me, thus delay the
change to cxx-switch time.

What's the effect on bootstrap times?  Remember we build stage1 with -O0
and checking enabled always ...

Richard.

>
> Diego.
>

[driver, LTO Patch]: Resurrect user specs support

[Christian Bruel]

Hello,

This patch restores the --specs flags functionality.

There are 2 parts
1) Lazily check the flag validation until all command line spec files
are read. For this purpose, 'read_specs' records specs, to be analyzed
with 'file_spec_p'. Such flags have 'live_cond' = SWITCH_USER
2) --specs options need to be propagated to COLLECT_GCC_OPTIONS. Without
this lto1 might be given user flags without the corresponding --spec
file. Note that --specs LTO is broken since 4.6 included.

Regression tests included. Bootstrapped and reg tested on [x86,sh4]
Linux and regression tested on sh-superh-elf with proprietary BSP
supports. Also tested with LTO.

Some references on the issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858
http://gcc.gnu.org/ml/gcc/2012-05/msg00079.html

Having experienced with the implementation a bit, I prefer to implement
this lazy check, rather than explicitly expose the user flags thru a new
-fextension option, because I think the full previous behavior can be
restored without lost of missing diagnostic (as opposed with older
version (< 4.6) and without ambiguity : There is an error for
unrecognized flags either from internal .opt or explicitly provided in a
spec file.

Thanks a lot for your feedback. I'd like to candidate this change for
the 4.7 and trunk branches.

Christian

2012-05-18  Christian Bruel  

	* gcc.c (save_switch) Add user_p parameter. Set live_cond.
	(read_specs): Likewise. Call record_file_spec.
	(main): Call read_specs with user_p.
	(record_file_spec): New function.
	(file_spec_p): Likewise.
	(SWITCH_USER): New flag.
	(driver_unknown_option_callback): Test OPT_SPECIAL_unknown.
	Add user_p parameter.
	(set_collect_gcc_options): Don't ignore SWITCH_USER.
	(check_live_switch): Likewise.
	(validate_switches): Validate SWITCH_USER options.
	(driver_handle_option): Propagate OPT_specs to collect2.

2012-05-18  Christian Bruel  

	* gcc.dg/spec-options.c: Test recognized --specs option.
	* gcc.dg/spec-options-2.c: Test unknown --specs option.
	* gcc.dg/foo.specs: New file.

Index: gcc/gcc.c
===
--- gcc/gcc.c	(revision 187500)
+++ gcc/gcc.c	(working copy)
@@ -190,7 +190,7 @@
 static void store_arg (const char *, int, int);
 static void insert_wrapper (const char *);
 static char *load_specs (const char *);
-static void read_specs (const char *, int);
+static void read_specs (const char *, bool, bool);
 static void set_spec (const char *, const char *);
 static struct compiler *lookup_compiler (const char *, size_t, const char *);
 static char *build_search_list (const struct path_prefix *, const char *,
@@ -1472,6 +1472,47 @@
 
   specs = sl;
 }
+struct file_specs
+{
+  struct file_specs *next;
+  const char *spec;
+};
+
+static struct file_specs *file_specs_head;
+
+static void
+record_file_spec (const char *spec)
+{
+  struct file_specs *user = XNEW (struct file_specs);
+
+  user->next = file_specs_head;
+
+  if (spec[0] == '+' && ISSPACE ((unsigned char)spec[1]))
+user->spec = spec + 1;
+  else
+user->spec = spec;
+
+  file_specs_head = user;
+}
+
+static bool
+file_spec_p (const char *name)
+{
+  struct file_specs *user;
+
+  for (user = file_specs_head; user; user = user->next)
+{
+  const char *p = user->spec;
+  char c;
+  while ((c = *p++))
+	if (c == '%' && (*p == '{' || *p == '<' || (*p == 'W' && *++p == '{')))
+	  if (!strcmp (name, p + 1))
+	return true;
+}
+
+  return false;
+}
+
 
 /* Change the value of spec NAME to SPEC.  If SPEC is empty, then the spec is
removed; If the spec starts with a + then SPEC is added to the end of the
@@ -1686,7 +1727,7 @@
Anything invalid in the file is a fatal error.  */
 
 static void
-read_specs (const char *filename, int main_p)
+read_specs (const char *filename, bool main_p, bool user_p)
 {
   char *buffer;
   char *p;
@@ -1735,7 +1776,7 @@
 
 	  p[-2] = '\0';
 	  new_filename = find_a_file (&startfile_prefixes, p1, R_OK, true);
-	  read_specs (new_filename ? new_filename : p1, FALSE);
+	  read_specs (new_filename ? new_filename : p1, false, user_p);
 	  continue;
 	}
 	  else if (!strncmp (p1, "%include_noerr", sizeof "%include_noerr" - 1)
@@ -1756,7 +1797,7 @@
 	  p[-2] = '\0';
 	  new_filename = find_a_file (&startfile_prefixes, p1, R_OK, true);
 	  if (new_filename)
-		read_specs (new_filename, FALSE);
+		read_specs (new_filename, false, user_p);
 	  else if (verbose_flag)
 		fnotice (stderr, "could not find specs file %s\n", p1);
 	  continue;
@@ -1899,7 +1940,12 @@
 	  if (! strcmp (suffix, "*link_command"))
 	link_command_spec = spec;
 	  else
-	set_spec (suffix + 1, spec);
+	{
+	  set_spec (suffix + 1, spec);
+
+	  if (user_p)
+		record_file_spec (spec);
+	}
 	}
   else
 	{
@@ -2806,20 +2852,22 @@
SWITCH_IGNORE_PERMANENTLY to indicate this switch should be ignored
in all do_spec calls afterwards.  Used for %canonical_option[0],
 		   de

Re: [patch] Fix array type merging in LTO mode

[Richard Guenther]

On Sun, May 20, 2012 at 7:56 PM, Eric Botcazou  wrote:
> Hi,
>
> since http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00833.html, canonical type
> merging for arrays takes hours instead of minutes for big Ada applications.
> The problem is that iterative_hash_canonical_type doesn't hash TYPE_MIN_VALUE
> and TYPE_MAX_VALUE for integer types anymore, so TYPE_DOMAIN is effectively
> not hashed anymore and the number of collisions goes to the roof in Ada.
>
> Fixed by the attached patch, which also removes a bogus comparison of the
> TYPE_SIZE of TYPE_DOMAIN in gimple_[canonical]types_compatible_p.  LTO
> bootstrapped on x86_64-suse-linux, OK for mainline and 4.7 branch?

-  /* For integer types hash the types min/max values and the string flag.  */
+  /* For integer types hash the sizetype flag and the string flag.  */
   if (TREE_CODE (type) == INTEGER_TYPE)
 v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);

The sizetype flag is no longer present (the patch will differ for the branch).

+  /* For array types hash the domain and its bounds, and the string flag.  */
+  if (TREE_CODE (type) == ARRAY_TYPE && TYPE_DOMAIN (type))
 {
   v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
   v = iterative_hash_canonical_type (TYPE_DOMAIN (type), v);
+  /* OMP lowering can introduce error_mark_node in place of
+random local decls in types.  */
+  if (TYPE_MIN_VALUE (TYPE_DOMAIN (type)) != error_mark_node)
+   v = iterative_hash_expr (TYPE_MIN_VALUE (TYPE_DOMAIN (type)), v);
+  if (TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != error_mark_node)
+   v = iterative_hash_expr (TYPE_MAX_VALUE (TYPE_DOMAIN (type)), v);
 }

I suppose hashing TYPE_DOMAIN itself is then useless?  Practically
it will be always sizetype anyway ... and if we start to see different
domain types arrays with the same actual domain [0, 1] should be
still merged for canonical merging.

Ok with the comment adjustment and not hashing TYPE_DOMAIN itself.

Thanks,
Richard.


>
> 2012-05-20  Eric Botcazou  
>
>        * gimple.c (gimple_types_compatible_p_1) : Remove bogus
>        size handling.
>        (gimple_canonical_types_compatible_p) : Likewise.
>        (iterative_hash_gimple_type): Adjust comment.
>        (iterative_hash_canonical_type): Likewise.  Hash the bounds of the
>        domain for an array type.
>
> --
> Eric Botcazou

Re: fix cross build

[Richard Guenther]

On Sun, May 20, 2012 at 7:24 PM, Nathan Sidwell  wrote:
> In building a ppc cross compiler using a freshly built native compiler, I
> encountered an ICE in iterative_hash_expr compiling c-lex.c.  I extracted
> the attached testcase, showing the problem is with statement expressions.
> Investigation showed I_H_E seeing BLOCK and BIND_EXPR nodes, which is was
> unprepared for.  These two nodes are never considered equal by
> operand_equal_p, so we don't need to look into them further to refine the
> hash.
>
> I'm not sure why a native i686-pc-linux-gnu bootstrap doesn't encounter this
> problem.
>
> The attached patch resolves the ICE.  built and tested on i686-pc-linux-gnu,
> ok?

Hmm - I think this papers over the issue that the CONSTRUCTOR is not
properly gimplified - it still contains a TARGET_EXPR which is not valid GIMPLE.
Why is that TARGET_EXPR not gimplified?

Richard.

> nathan

Re: [PATCH] Fix PR 53395: tree-if-conv.c not producing MAX_EXPR

[Richard Guenther]

On Sun, May 20, 2012 at 1:40 AM, Andrew Pinski  wrote:
> The problem here is that tree-if-conv.c produces COND_EXPR instead of
> the MAX/MIN EXPRs.  When I added the expansion from COND_EXPR to
> conditional moves, I assumes that the expressions which should have
> been converted into MAX_EXPR/MIN_EXPR have already happened.
>
> This fixes the problem by having tree-if-conv fold the expression so
> the MIN_EXPR/MAX_EXPR appears in the IR rather than COND_EXPR and the
> expansion happens correctly to the min/max rtl rather than just
> through the conditional move ones.
>
> OK?  Bootstrapped and tested on x86_64-linux-gnu with no regressions.

As we are unconditionally building a gimple_assign from the folding result
you need to re-gimplify it.  The code was using build3 instead of fold_build3
to avoid that and to make sure we create a plain COND_EXPR we can
later CSE / simplify properly.  Generating a MAX_EXPR directly is certainly
fine (can we always vectorize that?), but I suppose simply changing the
code to use fold_build3 will have unwanted fallout (consider folds habit
to insert conversions that are not requried on gimple).

So I'd rather prefer to abstract the build3 (COND_EXPR,... into a
helper function that uses fold_ternary and only if the result is an
invariant/register or a MIN/MAX_EXPR use the result, canonicalizing
it properly.

Richard.

> Thanks,
> Andrew Pinski
>
> ChangeLog:
> * tree-if-conv.c (predicate_scalar_phi): Call fold_build3 instead of build3.
> (predicate_mem_writes): Likewise.

Re: [PATCH, java] Fix placement of #ifdef JCR_SECTION_NAME in class.c

[Richard Guenther]

On Sat, May 19, 2012 at 11:07 PM, John David Anglin
 wrote:
> The attached change fixes a compilation error that occurs because
> JCR_SECTION_NAME is not defined on hppa*-hpux.
>
> Tested on hppa2.0w-hp-hpux11.11.
>
> Ok for trunk?

Ok.

Thanks,
Richard.

> Dave
> --
> J. David Anglin                                  dave.ang...@nrc-cnrc.gc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 
> 952-6602)
>
> 2012-05-19  John David Anglin  
>
>        PR java/52815
>        * class.c (emit_register_classes_in_jcr_section): Revise placement
>        of #ifdef JCR_SECTION_NAME.
>
> Index: class.c
> ===
> --- class.c     (revision 186553)
> +++ class.c     (working copy)
> @@ -2791,17 +2791,12 @@
>  static void
>  emit_register_classes_in_jcr_section (void)
>  {
> +#ifdef JCR_SECTION_NAME
>   tree klass, cdecl, class_array_type;
>   int i;
>   int size = VEC_length (tree, registered_class);
>   VEC(constructor_elt,gc) *init = VEC_alloc (constructor_elt, gc, size);
>
> -#ifndef JCR_SECTION_NAME
> -  /* A target has defined TARGET_USE_JCR_SECTION,
> -     but doesn't have a JCR_SECTION_NAME.  */
> -  gcc_unreachable ();
> -#endif
> -
>   FOR_EACH_VEC_ELT (tree, registered_class, i, klass)
>     CONSTRUCTOR_APPEND_ELT (init, NULL_TREE, build_fold_addr_expr (klass));
>
> @@ -2827,6 +2822,11 @@
>   relayout_decl (cdecl);
>   rest_of_decl_compilation (cdecl, 1, 0);
>   mark_decl_referenced (cdecl);
> +#else
> +  /* A target has defined TARGET_USE_JCR_SECTION,
> +     but doesn't have a JCR_SECTION_NAME.  */
> +  gcc_unreachable ();
> +#endif
>  }
>
>

Re: [PATCH, 4.6] Fix PR53170: missing target c++11 selector

[Paolo Carlini]

On 05/21/2012 11:49 AM, Fabien Chêne wrote:
Doesn't the target selector c++11 set -pedantic as well ? 
You may be right, I didn't check, sorry. Then just add that too, 
wouldn't be the first time.


Paolo.

Re: [PATCH] Improved re-association of signed arithmetic

[Richard Guenther]

On Fri, May 18, 2012 at 11:13 PM, Robert Dewar  wrote:
> On 5/18/2012 4:27 PM, Ulrich Weigand wrote:
>
>> I finally got some time to look into this in detail.  The various special-
>> case transforms in associate_plusminus all transform a plus/minus
>> expression
>> tree into either a single operand, a negated operand, or a single plus or
>> minus of two operands.  This is valid as long as we can prove that the
>> newly introduced expression can never overflow (if we're doing signed
>> arithmetic).
>
>
> It's interesting to note that for Ada, reassociatin is allowed if there
> are no overriiding parens, even if it would introduce an overflow
> (exception) that would not occur otherwise. However, I think I prefer
> the C semantics!

So you mean in Ada signed types have undefined overflow for all
possible associations of an expression wrapped in paranteses?
That's certainly interesting ... especially how this is actually
formally specified.  Also interesting to think about how we could
transfer this knowledge to the middle-end (in the context of
the no-undefined-overflow branch where I merely dealt with the
C way of -f[no-]wrapv of signed types).  For Fortran we have
PAREN_EXPR as association barrier, but that's of course not
giving extra freedom to things inside.

Richard.

Re: [PATCH, 4.6] Fix PR53170: missing target c++11 selector

[Fabien Chêne]

2012/5/21 Paolo Carlini :
> On 05/21/2012 01:45 AM, Michael Hope wrote:
>>
>> The testsuite for PR52796 uses the 'target c++11' selector which doesn't
>> exist in 4.6.
>> This patch backports the selector, clearing the 'ERROR:
>> g++.dg/cpp0x/variadic-value1.C:
>> syntax error in target selector "target c++11" for " dg-do 2 run { target
>> c++11 } "'
>> errors which have appeared in recent 4.6 builds.
>>
>> Tested on x86_64-linux-gnu with no regressions.  Changes the ERROR to
>> UNSUPPORTED.
>>
>> OK for 4.6?
>
> To be honest, when I saw the issue I thought we wanted simply to not use the
> target selector at all in the branch and simply add a // { dg-options
> "-std=c++11" } I thought somebody would commit the change as obvious ;)

Doesn't the target selector c++11 set -pedantic as well ?

-- 
Fabien

[C++ Patch] PR 51184

[Paolo Carlini]

Hi,

a simple diagnostic issue: we aren't diagnosing functions returning 
abstract class types as typenames.


In grokdeclarator we already have a place where we do such checks on the 
return types, and I'm adding this one too, with the following details:


1- I'm not immediately returning with error_mark_node: I think that by 
now we have solid enough evidence that the rest of the compiler can cope 
with such types without crashing and in this way the error message 
doesn't end up including more redundant lines about semicolons etc. 
Additionally, in this way we can also produce further useful error 
messages, for example no function types in sizeofs.


2- I'm only handling TYPENAME, because normal FUNCTION_DECL, etc, are 
handled later, by abstract_virtuals_error and the error messages are 
more verbose but also more complete in such cases (eg, always include 
the complete signature of the function)


Tested x86_64-linux.

Thanks,
Paolo.

//
/cp
2012-05-21  Paolo Carlini  

PR c++/51184
* decl.c (grokdeclarator): Diagnose functions returning abstract
class types as TYPENAME.
* cp-tree.h (ABSTRACT_CLASS_TYPE_P): Add.
* except.c (is_admissible_throw_operand_or_catch_parameter): Use it.
* pt.c (tsubst): Likewise.
* semantics.c (trait_expr_value): Likewise.

/testsuite
2012-05-21  Paolo Carlini  

PR c++/51184
* g++.dg/other/abstract4.C: New-
Index: testsuite/g++.dg/other/abstract4.C
===
--- testsuite/g++.dg/other/abstract4.C  (revision 0)
+++ testsuite/g++.dg/other/abstract4.C  (revision 0)
@@ -0,0 +1,18 @@
+// PR c++/51184
+
+template
+struct S { };
+
+template
+void foo();
+
+struct Abs
+{
+  virtual void bar() = 0;
+};
+
+int main()
+{
+  S s; // { dg-error "abstract" }
+  foo();   // { dg-error "abstract" }
+}
Index: cp/decl.c
===
--- cp/decl.c   (revision 187694)
+++ cp/decl.c   (working copy)
@@ -9194,6 +9194,11 @@ grokdeclarator (const cp_declarator *declarator,
error ("%qs declared as function returning an array", name);
return error_mark_node;
  }
+   /* When decl_context == NORMAL we emit a better error message
+  later in abstract_virtuals_error.  */
+   if (decl_context == TYPENAME && ABSTRACT_CLASS_TYPE_P (type))
+ error ("%qs declared as function returning an abstract "
+"class type", name);
 
/* Pick up type qualifiers which should be applied to `this'.  */
memfn_quals = declarator->u.function.qualifiers;
Index: cp/except.c
===
--- cp/except.c (revision 187694)
+++ cp/except.c (working copy)
@@ -974,7 +974,7 @@ is_admissible_throw_operand_or_catch_parameter (tr
   /* 10.4/3 An abstract class shall not be used as a parameter type,
as a function return type or as type of an explicit
conversion.  */
-  else if (CLASS_TYPE_P (type) && CLASSTYPE_PURE_VIRTUALS (type))
+  else if (ABSTRACT_CLASS_TYPE_P (type))
 {
   if (is_throw)
error ("expression %qE of abstract class type %qT cannot "
Index: cp/pt.c
===
--- cp/pt.c (revision 187694)
+++ cp/pt.c (working copy)
@@ -11646,7 +11646,7 @@ tsubst (tree t, tree args, tsubst_flags_t complain
  error ("creating array of %qT", type);
return error_mark_node;
  }
-   if (CLASS_TYPE_P (type) && CLASSTYPE_PURE_VIRTUALS (type))
+   if (ABSTRACT_CLASS_TYPE_P (type))
  {
if (complain & tf_error)
  error ("creating array of %qT, which is an abstract class type",
Index: cp/semantics.c
===
--- cp/semantics.c  (revision 187694)
+++ cp/semantics.c  (working copy)
@@ -5441,7 +5441,7 @@ trait_expr_value (cp_trait_kind kind, tree type1,
   return type_has_virtual_destructor (type1);
 
 case CPTK_IS_ABSTRACT:
-  return (CLASS_TYPE_P (type1) && CLASSTYPE_PURE_VIRTUALS (type1));
+  return (ABSTRACT_CLASS_TYPE_P (type1));
 
 case CPTK_IS_BASE_OF:
   return (NON_UNION_CLASS_TYPE_P (type1) && NON_UNION_CLASS_TYPE_P (type2)
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 187694)
+++ cp/cp-tree.h(working copy)
@@ -1658,6 +1658,10 @@ struct GTY((variable_size)) lang_type {
 #define CLASSTYPE_PURE_VIRTUALS(NODE) \
   (LANG_TYPE_CLASS_CHECK (NODE)->pure_virtuals)
 
+/* Nonzero means that this type is an abstract class type.  */
+#define ABSTRACT_CLASS_TYPE_P(NODE) \
+  (CLASS_TYPE_P (NODE) && CLASSTYPE_PURE_VIRTUALS(NODE))
+
 /* Nonzero means that this type has an X() constructor.  */
 #define TYPE_HAS_DEFAULT_CONSTRUC

Re: [PATCH] ARM/NEON: vld1q_dup_s64 builtin

[Christophe Lyon]

I tried applying your patch but ran into trouble with patch not liking
this . My suspicion is mailer munging white spaces in some form -
Could you send the patch as an attachment please rather than inline in
your mail ?

regards,
Ramana


Here it is, as an attachment. Note however that this patch is against GCC-4.6.3.

Thanks for testing.

Christophe.

2012-05-16  Christophe Lyon  

* gcc/config/arm/neon.md (neon_vld1_dup): Restrict to VQ
operands.
(neon_vld1_dupv2di): New, fixes vld1q_dup_s64.
* gcc/testsuite/gcc.target/arm/neon-vld1_dupQ.c: New test.

 2012-04-25  Christophe Lyon  
 
Fix codex #161546:
Index: gcc/testsuite/gcc.target/arm/neon-vld1_dupQ.c
===
--- gcc.orig/gcc/testsuite/gcc.target/arm/neon-vld1_dupQ.c  (revision 0)
+++ gcc.new/gcc/testsuite/gcc.target/arm/neon-vld1_dupQ.c   (revision 0)
@@ -0,0 +1,24 @@
+/* Test the `vld1q_s64' ARM Neon intrinsic.  */
+
+/* { dg-do run } */
+/* { dg-require-effective-target arm_neon_hw } */
+/* { dg-options "-O0" } */
+/* { dg-add-options arm_neon } */
+
+#include "arm_neon.h"
+#include 
+
+int main (void)
+{
+  int64x1_t input[2] = {(int64x1_t)0x0123456776543210LL,
+   (int64x1_t)0x89abcdeffedcba90LL};
+  int64x1_t output[2] = {0, 0};
+  int64x2_t var = vld1q_dup_s64(input);
+
+  vst1q_s64(output, var);
+  if (output[0] != (int64x1_t)0x0123456776543210LL)
+abort();
+  if (output[1] != (int64x1_t)0x0123456776543210LL)
+abort();
+  return 0;
+}
Index: gcc/config/arm/neon.md
===
--- gcc.orig/gcc/config/arm/neon.md (revision 2659)
+++ gcc.new/gcc/config/arm/neon.md  (working copy)
@@ -4195,20 +4195,32 @@
 )
 
 (define_insn "neon_vld1_dup"
-  [(set (match_operand:VQX 0 "s_register_operand" "=w")
-(unspec:VQX [(match_operand: 1 "neon_struct_operand" "Um")]
+  [(set (match_operand:VQ 0 "s_register_operand" "=w")
+(unspec:VQ [(match_operand: 1 "neon_struct_operand" "Um")]
 UNSPEC_VLD1_DUP))]
   "TARGET_NEON"
 {
-  if (GET_MODE_NUNITS (mode) > 2)
 return "vld1.\t{%e0[], %f0[]}, %A1";
-  else
-return "vld1.\t%h0, %A1";
 }
   [(set (attr "neon_type")
-  (if_then_else (gt (const_string "") (const_string "1"))
-(const_string "neon_vld2_2_regs_vld1_vld2_all_lanes")
-(const_string "neon_vld1_1_2_regs")))]
+  (const_string "neon_vld2_2_regs_vld1_vld2_all_lanes"))]
+)
+
+(define_insn_and_split "neon_vld1_dupv2di"
+   [(set (match_operand:V2DI 0 "s_register_operand" "=w")
+(vec_duplicate:V2DI (match_operand:DI 1 "neon_struct_operand" "Um")))]
+   "TARGET_NEON"
+   "#"
+   "&& reload_completed"
+   [(const_int 0)]
+   {
+rtx tmprtx = gen_lowpart (DImode, operands[0]);
+emit_insn (gen_neon_vld1_dupdi (tmprtx, operands[1]));
+emit_move_insn (gen_highpart (DImode, operands[0]), tmprtx );
+DONE;
+}
+  [(set_attr "length" "8")
+   (set (attr "neon_type") (const_string 
"neon_vld2_2_regs_vld1_vld2_all_lanes"))]
 )
 
 (define_expand "vec_store_lanes"

Re: [PATCH, 4.6] Fix PR53170: missing target c++11 selector

[Paolo Carlini]

On 05/21/2012 01:45 AM, Michael Hope wrote:
The testsuite for PR52796 uses the 'target c++11' selector which 
doesn't exist in 4.6.
This patch backports the selector, clearing the 'ERROR: 
g++.dg/cpp0x/variadic-value1.C:
syntax error in target selector "target c++11" for " dg-do 2 run { 
target c++11 } "'

errors which have appeared in recent 4.6 builds.

Tested on x86_64-linux-gnu with no regressions.  Changes the ERROR to 
UNSUPPORTED.


OK for 4.6?
To be honest, when I saw the issue I thought we wanted simply to not use 
the target selector at all in the branch and simply add a // { 
dg-options "-std=c++11" } I thought somebody would commit the change as 
obvious ;)


Paolo.

Re: [PATCH] Fix memset recognition, paper over PR53346

[Richard Guenther]

On Fri, 18 May 2012, Andi Kleen wrote:

> Richard Guenther  writes:
> 
> > In PR53346 we vectorize a simple memset loop very inefficiently.
> > But of course we should have detected this and transformed the
> > loop into a memset!  Seems like we only do that if the original
> > loop does sth else than memset as well.
> 
> Is there a way to turn this off?

-fno-tree-loop-distribute-patterns, it's enabled by default only at -O3.

> I know code written in the past who explicitely wrote memset as a loop
> because it couldn't deal with the optimizations optimized memsets do
> (like reordering or changing access granuality.
> 
> One example is clearing something in memory mapped hardware registers.
> 
> It would be good at least if this was not done for volatile.

I see it does it for volatile - that's clearly a bug that I'll address
shortly.

Richard.