Re: Fix PR50638 (segfault with emutls)

2011-10-08 Thread Richard Guenther
On Fri, Oct 7, 2011 at 6:34 PM, Michael Matz  wrote:
> Hi,
>
> tree-emutls.c missed to called add_referenced_var for a variable that is
> referenced.  That always was a bug, but meanwhile is fatal (causing a
> segfault).  This fixes the problem.  Okay for trunk if regstrapping
> succeeds?

Ok (qualifies even as obvious).

Thanks,
Richard.

> The related bugreport PR50640 (fortran segfaults for similar reasons) is a
> bit more involved and requires some pondering on my part.  The PR50644
> (LTO segfault) requires some analysis still, to know which variable causes
> this.
>
>
> Ciao,
> Michael.
> -
>        PR middle-end/50638
>        * tree-emutls.c (gen_emutls_addr): Call add_referenced_var.
>
> Index: tree-emutls.c
> ===
> --- tree-emutls.c       (revision 179606)
> +++ tree-emutls.c       (working copy)
> @@ -434,6 +434,7 @@ gen_emutls_addr (tree decl, struct lower
>       addr = create_tmp_var (build_pointer_type (TREE_TYPE (decl)), NULL);
>       x = gimple_build_call (d->builtin_decl, 1, build_fold_addr_expr 
> (cdecl));
>       gimple_set_location (x, d->loc);
> +      add_referenced_var (cdecl);
>
>       addr = make_ssa_name (addr, x);
>       gimple_call_set_lhs (x, addr);
>


Re: [Patch, Fortran, committed] PR 50585: [4.6/4.7 Regression] ICE with assumed length character array argument

2011-10-08 Thread Janus Weil
> Thanks! What's about the .texi change for -fwhole-file?

Will do. Should I include a note about deprecation? And if yes, do you
have a suggestion for the wording?

Cheers,
Janus


Re: [C++ Patch] PR 34927

2011-10-08 Thread Jason Merrill

On 10/08/2011 12:56 AM, Paolo Carlini wrote:

The fix seems easy: output a cloned destructor only once (+ output any
other member functions normally).



+ static bool done_cloned_dest = false;


This seems like it will only complain once per translation unit about 
virtual destructors.  How about instead of this flag, we look at which 
variant it is and only complain about one of them, perhaps the base?


Jason



Re: [testsuite] suppress warnings for powerpc for graphite vector test

2011-10-08 Thread Dominique Dhumieres
> I'm hoping the graphite people have an even a better idea...  If not, Ok.

I have filed pr50023 two month ago CCing Sebastian Pop asking the question:
"Why not on powerpc?" and I have the patch (comment#2) since over a month.

I think that if "the graphite people have an even a better idea", they had
plenty of time to react. Please apply the patch.

Thanks

Dominique


Re: [C++ Patch] PR 34927

2011-10-08 Thread Paolo Carlini
Hi,

> This seems like it will only complain once per translation unit about virtual 
> destructors.

Oops, sorry, but this specific issue could be solved rather easily by not using 
a static, right?

>  How about instead of this flag, we look at which variant it is and only 
> complain about one of them, perhaps the base?

Yes, isn't simply not using a static a rather straightforward alternative?

Paolo


[google] record compiler options to .note sections

2011-10-08 Thread Dehao Chen
This patch records the compiler command-line flags to a .note section,
which could be used by FDO/LIPO.

Bootstrapped on x86_64, no regressions.

Is it ok for google/gcc-4_6 and google/main branches?

Thanks,
Dehao

gcc/ChangeLog.google-4_6:
2011-10-08  Dehao Chen  

Add a flag (-frecord-options-in-elf) to record compiler command
line options to .note sections of the object file.
* coverage.c (write_opts_to_asm): Write the options to
.note sections.
* common.opt: Ditto.
* opts.h: Ditto.

gcc/c-family/ChangeLog.google-4_6:
2011-10-08  Dehao Chen  
* c-opts.c (c_common_parse_file): Write the options to
.note sections.

gcc/testsuite/ChangeLog.google-4_6:
2011-10-08  Dehao Chen  

* gcc.dg/record-options-in-elf-1.c: New test.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 179708)
+++ gcc/doc/invoke.texi (working copy)
@@ -391,6 +391,7 @@
 -fpmu-profile-generate=@var{pmuoption} @gol
 -fpmu-profile-use=@var{pmuoption} @gol
 -freciprocal-math -fregmove -frename-registers -freorder-blocks @gol
+-frecord-options-in-elf@gol
 -freorder-blocks-and-partition -freorder-functions @gol
 -frerun-cse-after-loop -freschedule-modulo-scheduled-loops @gol
 -fripa -fripa-disallow-asm-modules -fripa-disallow-opt-mismatch @gol
@@ -8170,6 +8171,11 @@
 number of times it is called. The params variable
 "note-cgraph-section-edge-threshold" can be used to only list edges above a
 certain threshold.
+
+@item -frecord-options-in-elf
+@opindex frecord-options-in-elf
+Record the command line options in the .note elf section for sample FDO to
+do module grouping.
 @end table

 The following options control compiler behavior regarding floating
Index: gcc/c-family/c-opts.c
===
--- gcc/c-family/c-opts.c   (revision 179708)
+++ gcc/c-family/c-opts.c   (working copy)
@@ -1109,6 +1109,8 @@
   for (;;)
 {
   c_finish_options ();
+  if (flag_record_options_in_elf && i == 0)
+   write_opts_to_asm ();
   pch_init ();
   set_lipo_c_parsing_context (parse_in, i, verbose);
   push_file_scope ();
Index: gcc/testsuite/gcc.dg/record-options-in-elf-1.c
===
--- gcc/testsuite/gcc.dg/record-options-in-elf-1.c  (revision 0)
+++ gcc/testsuite/gcc.dg/record-options-in-elf-1.c  (revision 0)
@@ -0,0 +1,16 @@
+/* { dg-do compile} */
+/* { dg-options "-frecord-options-in-elf -Dtest -dA" } */
+
+void foobar(int);
+
+void
+foo (void)
+{
+  int i;
+  for (i = 0; i < 100; i++)
+{
+  foobar(i);
+}
+}
+
+/* { dg-final { scan-assembler-times "test" 1 } } */
Index: gcc/opts.h
===
--- gcc/opts.h  (revision 179708)
+++ gcc/opts.h  (working copy)
@@ -381,4 +381,5 @@
 extern void set_struct_debug_option (struct gcc_options *opts,
 location_t loc,
 const char *value);
+extern void write_opts_to_asm (void);
 #endif
Index: gcc/coverage.c
===
--- gcc/coverage.c  (revision 179708)
+++ gcc/coverage.c  (working copy)
@@ -55,6 +55,7 @@
 #include "diagnostic-core.h"
 #include "intl.h"
 #include "l-ipo.h"
+#include "dwarf2asm.h"

 #include "gcov-io.h"
 #include "gcov-io.c"
@@ -2146,4 +2147,64 @@
   return 0;
 }

+/* Write command line options to the .note section.  */
+
+void
+write_opts_to_asm (void)
+{
+  size_t i;
+  cpp_dir *quote_paths, *bracket_paths, *pdir;
+  struct str_list *pdef, *pinc;
+  int num_quote_paths = 0;
+  int num_bracket_paths = 0;
+
+  get_include_chains ("e_paths, &bracket_paths);
+
+  /* Write quote_paths to ASM section.  */
+  switch_to_section (get_section (".note.quote_paths", SECTION_DEBUG, NULL));
+  for (pdir = quote_paths; pdir; pdir = pdir->next)
+{
+  if (pdir == bracket_paths)
+   break;
+  num_quote_paths++;
+}
+  dw2_asm_output_nstring (in_fnames[0], (size_t)-1, NULL);
+  dw2_asm_output_data_uleb128 (num_quote_paths, NULL);
+  for (pdir = quote_paths; pdir; pdir = pdir->next)
+{
+  if (pdir == bracket_paths)
+   break;
+  dw2_asm_output_nstring (pdir->name, (size_t)-1, NULL);
+}
+
+  /* Write bracket_paths to ASM section.  */
+  switch_to_section (get_section (".note.bracket_paths", SECTION_DEBUG, NULL));
+  for (pdir = bracket_paths; pdir; pdir = pdir->next)
+num_bracket_paths++;
+  dw2_asm_output_nstring (in_fnames[0], (size_t)-1, NULL);
+  dw2_asm_output_data_uleb128 (num_bracket_paths, NULL);
+  for (pdir = bracket_paths; pdir; pdir = pdir->next)
+dw2_asm_output_nstring (pdir->name, (size_t)-1, NULL);
+
+  /* Write cpp_defines to ASM section.  */
+  switch_to_section (get_section (".note.cpp_defines", SECTION_DEBUG, NULL));
+  dw2_asm_output_nstring (in_fnames[0]

Re: [C++ Patch] PR 34927

2011-10-08 Thread Paolo Carlini
> Yes, isn't simply not using a static a rather straightforward alternative?

Ok, now I see: since it's easy, better avoid using *any* sort of flag, I'll do 
it.

Paolo


Re: [google] record compiler options to .note sections

2011-10-08 Thread Jakub Jelinek
On Sat, Oct 08, 2011 at 06:43:47PM +0800, Dehao Chen wrote:
> This patch records the compiler command-line flags to a .note section,
> which could be used by FDO/LIPO.
> 
> Bootstrapped on x86_64, no regressions.
> 
> Is it ok for google/gcc-4_6 and google/main branches?

Why yet another record switches option?  Isn't -grecord-gcc-switches
good enough for you (or -frecord-gcc-switches)?

Jakub


Re: [patch] --enable-dynamic-string default for mingw-w64 v2

2011-10-08 Thread JonY
Ok, fixed it, I made a very dumb mistake in configure.host, new patch
attached.

Changelog:
2011-10-08  Jonathan Yong  

* configure.host: Use config/os/mingw32-w64 instead of
config/os/mingw32 if vendor key is "w64".
* config/os/mingw32-w64: Duplicate from config/os/mingw32.
* config/os/mingw32-w64/os_defines.h: Enable
_GLIBCXX_FULLY_DYNAMIC_STRING if undefined.
* acinclude.m4: Set fully-dynamic-string to 1 when enabled,
0 when disabled or undefined if unset by user.
* include/bits/basic_string.h: Check if
_GLIBCXX_FULLY_DYNAMIC_STRING is set to 0 instead of undefined.
include/bits/basic_string.tcc: Likewise.
* configure: Regenerated.
* config.h.in: Likewise.

Index: configure
===
--- configure   (revision 179710)
+++ configure   (working copy)
@@ -17240,10 +17240,15 @@
 
 
   if test $enable_fully_dynamic_string = yes; then
+enable_fully_dynamic_string_def=1
+  else
+enable_fully_dynamic_string_def=0
+  fi
 
-$as_echo "#define _GLIBCXX_FULLY_DYNAMIC_STRING 1" >>confdefs.h
+cat >>confdefs.h <<_ACEOF
+#define _GLIBCXX_FULLY_DYNAMIC_STRING ${enable_fully_dynamic_string_def}
+_ACEOF
 
-  fi
 
 
 
Index: configure.host
===
--- configure.host  (revision 179710)
+++ configure.host  (working copy)
@@ -260,8 +260,16 @@
 atomic_word_dir=os/irix
 ;;
   mingw32*)
-os_include_dir="os/mingw32"
-error_constants_dir="os/mingw32"
+case "$host" in
+  *-w64-*)
+os_include_dir="os/mingw32-w64"
+error_constants_dir="os/mingw32-w64"
+;;
+  *)
+os_include_dir="os/mingw32"
+error_constants_dir="os/mingw32"
+;;
+esac
 OPT_LDFLAGS="${OPT_LDFLAGS} \$(lt_host_flags)"
 ;;
   netbsd*)
Index: include/bits/basic_string.h
===
--- include/bits/basic_string.h (revision 179710)
+++ include/bits/basic_string.h (working copy)
@@ -201,7 +201,7 @@
void
_M_set_length_and_sharable(size_type __n)
{
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
  if (__builtin_expect(this != &_S_empty_rep(), false))
 #endif
{
@@ -231,7 +231,7 @@
void
_M_dispose(const _Alloc& __a)
{
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
  if (__builtin_expect(this != &_S_empty_rep(), false))
 #endif
{
@@ -252,7 +252,7 @@
_CharT*
_M_refcopy() throw()
{
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
  if (__builtin_expect(this != &_S_empty_rep(), false))
 #endif
 __gnu_cxx::__atomic_add_dispatch(&this->_M_refcount, 1);
@@ -430,7 +430,7 @@
*  @brief  Default constructor creates an empty string.
*/
   basic_string()
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
   : _M_dataplus(_S_empty_rep()._M_refdata(), _Alloc()) { }
 #else
   : _M_dataplus(_S_construct(size_type(), _CharT(), _Alloc()), _Alloc()){ }
@@ -502,7 +502,7 @@
   basic_string(basic_string&& __str) noexcept
   : _M_dataplus(__str._M_dataplus)
   {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING  
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
__str._M_data(_S_empty_rep()._M_refdata());
 #else
__str._M_data(_S_construct(size_type(), _CharT(), get_allocator()));
Index: include/bits/basic_string.tcc
===
--- include/bits/basic_string.tcc   (revision 179710)
+++ include/bits/basic_string.tcc   (working copy)
@@ -80,7 +80,7 @@
   _S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a,
   input_iterator_tag)
   {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
if (__beg == __end && __a == _Alloc())
  return _S_empty_rep()._M_refdata();
 #endif
@@ -126,7 +126,7 @@
   _S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a,
   forward_iterator_tag)
   {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
if (__beg == __end && __a == _Alloc())
  return _S_empty_rep()._M_refdata();
 #endif
@@ -154,7 +154,7 @@
 basic_string<_CharT, _Traits, _Alloc>::
 _S_construct(size_type __n, _CharT __c, const _Alloc& __a)
 {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
   if (__n == 0 && __a == _Alloc())
return _S_empty_rep()._M_refdata();
 #endif
@@ -456,7 +456,7 @@
 basic_string<_CharT, _Traits, _Alloc>::
 _M_leak_hard()
 {
-#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
+#if _GLIBCXX_FULLY_DYNAMIC_STRING == 0
   if (_M_rep() == &_S_empty_rep())
return;

Re: [PATCH] Fix PR46556 (poor address generation)

2011-10-08 Thread William J. Schmidt
Greetings,

Here are the revised changes for the tree portions of the patch.  I've
attempted to resolve all comments to date on those portions.  Per
Steven's comment, I moved copy_ref_info into tree-ssa-address.c; let me
know if there's a better place, or whether you'd prefer to leave it
where it was.

I looked into changing the second reassoc pass to use a different
pass_late_reassoc entry, but this impacted the test suite.  There are
about 20 tests that rely on -fdump-tree-reassoc being associated with
two dump files named reassoc1 and reassoc2.  Rather than change all
these test cases for a temporary solution, I chose to use the deprecated
first_pass_instance boolean to distinguish between the two passes.  I
marked this as a Bad Thing and it will be removed once I have time to
work on the straight-line strength reducer.

I looked into adding a test case with a negative offset, but was unable
to come up with a construct that would have a negative offset on the
base MEM_REF and still be recognized by this particular pattern matcher.
In any case, the use of double_ints throughout should remove that
concern.

Thanks,
Bill


2011-10-08  Bill Schmidt  

gcc:

PR rtl-optimization/46556
* tree.h (copy_ref_info): Expose existing function.
* tree-ssa-loop-ivopts.c (copy_ref_info): Move this function to...
* tree-ssa-address.c (copy_ref_info): ...here, and remove static token.
* tree-ssa-reassoc.c (restructure_base_and_offset): New function.
(restructure_mem_ref): Likewise.
(reassociate_bb): Look for opportunities to call restructure_mem_ref.

gcc/testsuite:

PR rtl-optimization/46556
* gcc.dg/tree-ssa/pr46556-1.c: New testcase.
* gcc.dg/tree-ssa/pr46556-2.c: Likewise.
* gcc.dg/tree-ssa/pr46556-3.c: Likewise.


Index: gcc/tree.h
===
--- gcc/tree.h  (revision 179708)
+++ gcc/tree.h  (working copy)
@@ -5777,6 +5777,7 @@ tree target_for_debug_bind (tree);
 /* In tree-ssa-address.c.  */
 extern tree tree_mem_ref_addr (tree, tree);
 extern void copy_mem_ref_info (tree, tree);
+extern void copy_ref_info (tree, tree);
 
 /* In tree-vrp.c */
 extern bool ssa_name_nonnegative_p (const_tree);
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-1.c   (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dom2" } */
+
+struct x
+{
+  int a[16];
+  int b[16];
+  int c[16];
+};
+
+extern void foo (int, int, int);
+
+void
+f (struct x *p, unsigned int n)
+{
+  foo (p->a[n], p->c[n], p->b[n]);
+}
+
+/* { dg-final { scan-tree-dump-times "\\* 4;" 1 "dom2" } } */
+/* { dg-final { scan-tree-dump-times "p_1\\(D\\) \\+ D" 1 "dom2" } } */
+/* { dg-final { scan-tree-dump-times "MEM\\\[\\(struct x \\*\\)D" 2 "dom2" } } 
*/
+/* { dg-final { cleanup-tree-dump "dom2" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-2.c   (revision 0)
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dom2" } */
+
+struct x
+{
+  int a[16];
+  int b[16];
+  int c[16];
+};
+
+extern void foo (int, int, int);
+
+void
+f (struct x *p, unsigned int n)
+{
+  foo (p->a[n], p->c[n], p->b[n]);
+  if (n > 12)
+foo (p->a[n], p->c[n], p->b[n]);
+  else if (n > 3)
+foo (p->b[n], p->a[n], p->c[n]);
+}
+
+/* { dg-final { scan-tree-dump-times "\\* 4;" 1 "dom2" } } */
+/* { dg-final { scan-tree-dump-times "p_1\\(D\\) \\+ D" 1 "dom2" } } */
+/* { dg-final { scan-tree-dump-times "MEM\\\[\\(struct x \\*\\)D" 6 "dom2" } } 
*/
+/* { dg-final { cleanup-tree-dump "dom2" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr46556-3.c   (revision 0)
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-dom2" } */
+
+struct x
+{
+  int a[16];
+  int b[16];
+  int c[16];
+};
+
+extern void foo (int, int, int);
+
+void
+f (struct x *p, unsigned int n)
+{
+  foo (p->a[n], p->c[n], p->b[n]);
+  if (n > 3)
+{
+  foo (p->a[n], p->c[n], p->b[n]);
+  if (n > 12)
+   foo (p->b[n], p->a[n], p->c[n]);
+}
+}
+
+/* { dg-final { scan-tree-dump-times "\\* 4;" 1 "dom2" } } */
+/* { dg-final { scan-tree-dump-times "p_1\\(D\\) \\+ D" 1 "dom2" } } */
+/* { dg-final { scan-tree-dump-times "MEM\\\[\\(struct x \\*\\)D" 6 "dom2" } } 
*/
+/* { dg-final { cleanup-tree-dump "dom2" } } */
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c  (revision 179708)
+++ gcc/tree-s

[RFC] Slightly fix up vgather* patterns

2011-10-08 Thread Jakub Jelinek
Hi!

The AVX2 docs say that the insns will #UD if any of the mask, src and index
registers are the same, but e.g. on
#include 

__m256 m;
float f[1024];

__m256
foo (void)
{
  __m256i mi = (__m256i) m;
  return _mm256_mask_i32gather_ps (m, f, mi, m, 4);
}

which is IMHO valid and should for m being zero vector just return a
zero vector and clear mask (in this case it was already cleared) we compile
it as
vmovdqa m(%rip), %ymm1
vmovaps %ymm1, %ymm0
vgatherdps  %ymm1, (%rax, %ymm1, 4), %ymm0
and thus IMHO it will #UD.  Also, the insns should make it clear that
the mask register is modified too (the patch clobbers it, perhaps
we could instead say that it zeros the register (which is true if
it doesn't segfault), but then what if a segfault handler chooses to
continue with the next insn and doesn't clear the mask register?).
Still, the insn description is imprecise, saying that it loads from mem
at the address register is wrong and perhaps some DCE might delete
what shouldn't be deleted.  So, either it should (use (mem (scratch)))
or something similar, or in the unspec list all the memory locations
that are being read
(mem: (plus:SI (reg:SI) (vec_select:SI (match_operand:V4SI)
(parallel [(const_int N)]
for N 0 through something (but it is complicated by Pmode size vs.
the need to do nothing/truncate/sign_extend the vec_select to the right
mode).

What do you think?

2011-10-08  Jakub Jelinek  

* config/i386/sse.md (avx2_gathersi, avx2_gatherdi,
avx2_gatherdi256): Add clobber of operand 4.
(*avx2_gathersi, *avx2_gatherdi,
*avx2_gatherdi256): Add clobber of the mask register,
add earlyclobber to both output operands.

--- gcc/config/i386/sse.md.jj   2011-10-07 10:03:27.0 +0200
+++ gcc/config/i386/sse.md  2011-10-08 17:14:50.0 +0200
@@ -12521,55 +12521,59 @@ (define_mode_attr VEC_GATHER_MODE
   (V8SI "V8SI") (V8SF "V8SI")])
 
 (define_expand "avx2_gathersi"
-  [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "")
-   (unspec:VEC_GATHER_MODE
- [(match_operand:VEC_GATHER_MODE 1 "register_operand" "")
-  (match_operand: 2 "memory_operand" "")
-  (match_operand: 3 "register_operand" "")
-  (match_operand:VEC_GATHER_MODE 4 "register_operand" "")
-  (match_operand:SI 5 "const1248_operand " "")]
- UNSPEC_GATHER))]
+  [(parallel [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "")
+  (unspec:VEC_GATHER_MODE
+[(match_operand:VEC_GATHER_MODE 1 "register_operand" "")
+ (match_operand: 2 "memory_operand" "")
+ (match_operand: 3 "register_operand" "")
+ (match_operand:VEC_GATHER_MODE 4 "register_operand" "")
+ (match_operand:SI 5 "const1248_operand " "")]
+UNSPEC_GATHER))
+ (clobber (match_dup 4))])]
   "TARGET_AVX2")
 
 (define_insn "*avx2_gathersi"
-  [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "=x")
+  [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "=&x")
(unspec:VEC_GATHER_MODE
- [(match_operand:VEC_GATHER_MODE 1 "register_operand" "0")
+ [(match_operand:VEC_GATHER_MODE 2 "register_operand" "0")
   (mem:
-(match_operand:P 2 "register_operand" "r"))
-  (match_operand: 3 "register_operand" "x")
-  (match_operand:VEC_GATHER_MODE 4 "register_operand" "x")
-  (match_operand:SI 5 "const1248_operand" "n")]
- UNSPEC_GATHER))]
+(match_operand:P 3 "register_operand" "r"))
+  (match_operand: 4 "register_operand" "x")
+  (match_operand:VEC_GATHER_MODE 5 "register_operand" "1")
+  (match_operand:SI 6 "const1248_operand" "n")]
+ UNSPEC_GATHER))
+   (clobber (match_operand:VEC_GATHER_MODE 1 "register_operand" "=&x"))]
   "TARGET_AVX2"
-  "vgatherd\t{%4, (%2, %3, %c5), %0|%0, (%2, %3, %c5), 
%4}"
+  "vgatherd\t{%1, (%3, %4, %c6), %0|%0, (%3, %4, %c6), 
%1}"
   [(set_attr "type" "ssemov")
(set_attr "prefix" "vex")
(set_attr "mode" "")])
 
 (define_expand "avx2_gatherdi"
-  [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "")
-   (unspec:VEC_GATHER_MODE
- [(match_operand:VEC_GATHER_MODE 1 "register_operand" "")
-  (match_operand: 2 "memory_operand" "")
-  (match_operand: 3 "register_operand" "")
-  (match_operand:VEC_GATHER_MODE 4 "register_operand" "")
-  (match_operand:SI 5 "const1248_operand " "")]
- UNSPEC_GATHER))]
+  [(parallel [(set (match_operand:VEC_GATHER_MODE 0 "register_operand" "")
+  (unspec:VEC_GATHER_MODE
+[(match_operand:VEC_GATHER_MODE 1 "register_operand" "")
+ (match_operand: 2 "memory_operand" "")
+ (match_operand: 3 "register_operand" "")
+ (match_operand:VEC_GATHER_MODE 4 "register_operand

Re: [patch] --enable-dynamic-string default for mingw-w64 v2

2011-10-08 Thread Paolo Carlini
Hi,

> Ok, fixed it, I made a very dumb mistake in configure.host, new patch
> attached.

Patch is still ok with me, if Kai is ok with it (remember for next time: 
regenerated files are not posted, are just a distraction)

Paolo
> 


Re: [patch] --enable-dynamic-string default for mingw-w64 v2

2011-10-08 Thread Kai Tietz
2011/10/8 Paolo Carlini :
> Hi,
>
>> Ok, fixed it, I made a very dumb mistake in configure.host, new patch
>> attached.
>
> Patch is still ok with me, if Kai is ok with it (remember for next time: 
> regenerated files are not posted, are just a distraction)
>
> Paolo

Ok, by me, too.

Thanks,
Kai


Re: PATCH RFA: New configure option --with-native-system-header-dir

2011-10-08 Thread Joseph S. Myers
On Fri, 7 Oct 2011, Ian Lance Taylor wrote:

> The uses in DJGPP and Mingw support all match.  config/gnu.h is only
> used on i[34567]86-*-gnu* while config/t-gnu is used on *-*-gnu*; this
> mismatch appears to be an error.  The use of STANDARD_INCLUDE_DIR in

There are no other *-*-gnu* targets (the others were all removed as 
bitrotten).

> So, it seems to me that we should:

These proposals generally seem reasonable (with "remove" taken to be 
"remove and poison in system.h" as usual for removed target macros).

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


Patch for PR libobjc/50428 ("Consider changing semantics of +initialize so that it is inherited")

2011-10-08 Thread Nicola Pero
This patch implements the change discussed in libobjc/50428.  Traditionally, 
the Apple runtime "inherits" +initialize,
meaning that if a class doesn't implement it, but the superclass does, the 
superclass's implementation gets executed
the first time a method of the class is invoked.  Instead, the GNU runtime 
traditionally doesn't "inherit" +initialize,
meaning in that situation, no +initialize is executed.  The idea is that with 
the GNU runtime you wouldn't have to worry
about protecting your +initialize against multiple executions.  But, in 
practice, people seem to protect +initialize methods all
the same even with the GNU runtime, and they supply the following two 
explanations of why:

 * It is generally considered good practice to protect +initialize methods 
against multiple exclusions because it allows
the code to run without changes with the Apple/NeXT runtime.

 * The runtime doesn't prevent programmers from invoking +initialize directly.  
You are not supposed to do it, but some beginners
do, which is why a number of frameworks (including GNUstep) protect all 
+initialize methods against multiple executions all the
same even when using the GNU runtime and even ignoring the existence of the 
Apple/NeXT runtime (!!).

Because of these two reasons, it seems that everyone's really protecting their 
+initialize methods against multiple executions
all the same!  So the difference in behaviour between the GNU runtime and the 
Apple/NeXT one is not really helping anyone;
but it makes it harder to port code written for the Apple/NeXT runtime to the 
GNU runtime.  Programmers writing code for the
Apple/NeXT runtime assume that +initialize methods are "inherited", so they may 
write code which expects such methods to
be called multiple times, once per subclass.  That code would compile on the 
GNU runtime but not work.  Fixing the code so
that it works with both runtimes is not necessarily trivial in some situations, 
for example if the classes are dynamically
created at runtime.  So the difference in behaviour is not really helping 
anyone, but it's making life hard for some people who
are porting software to run on the GNU runtime.

This patch (originally submitted by Richard Frith-Macdonald in a private email, 
and revised by me) changes the behaviour of the
GNU runtime to match the one of the Apple/NeXT one.  This makes it easier to 
port software to use the GNU runtime.

A testcase is included; I tested the patch on an Apple Mac OS X 10.6.8, making 
sure that the testcase behaves in the same way
with the Apple/NeXT and GNU runtimes.  Committed to trunk.

Thanks

PS: This change absolutely deserves a mention in the GCC 4.7 release notes.  
But I'll work on the release notes separately,
once we are in stage 2 or so. :-)

Index: gcc/doc/objc.texi
===
--- gcc/doc/objc.texi   (revision 179710)
+++ gcc/doc/objc.texi   (working copy)
@@ -635,7 +635,8 @@ following class does this:
 
 + (void)initialize
 @{
-  class_ivar_set_gcinvisible (self, "weakPointer", YES);
+  if (self == objc_lookUpClass ("WeakPointer"))
+class_ivar_set_gcinvisible (self, "weakPointer", YES);
 @}
 
 - initWithPointer:(const void*)p
Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 179710)
+++ gcc/ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2011-10-08  Nicola Pero  
+
+   PR libobjc/50428
+   * doc/objc.texi (Garbage Collection): Updated example to protect
+   +initialize against execution in subclasses.
+
 2011-10-07  Richard Henderson  
 
* doc/extend.texi (__builtin_shuffle): Improve the description to
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 179710)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2011-10-08  Nicola Pero  
+
+   PR libobjc/50428
+   * objc/execute/initialize-1.m: New test.
+
 2011-10-08  Paul Thomas  
 
PR fortran/47844
Index: gcc/testsuite/objc/execute/initialize-1.m
===
--- gcc/testsuite/objc/execute/initialize-1.m   (revision 0)
+++ gcc/testsuite/objc/execute/initialize-1.m   (revision 0)
@@ -0,0 +1,47 @@
+/* Contributed by Nicola Pero - Sat  8 Oct 2011 16:47:48 BST */
+#include 
+
+/* Test that if a class has no +initialize method, the superclass
+   implementation is called.  */
+
+static int class_variable = 0;
+
+@interface TestClass
+{
+  Class isa;
+}
++ (void) initialize;
++ (int) classVariable;
+@end
+
+@implementation TestClass
++ (void) initialize
+{
+  class_variable++;
+}
++ (int) classVariable
+{
+  return class_variable;
+}
+@end
+
+@interface TestSubClass : TestClass
+@end
+
+@implementation TestSubClass
+@end
+
+int main (void)
+{
+  if ([TestClass classVariable] != 1)
+{
+  abort ();
+}
+
+  if ([TestSubClass classVaria

[C++ Patch] PR 34927 (Take 2)

2011-10-08 Thread Paolo Carlini

Hi again,

today I had a look to clone_function_decl & co, and came up with the 
below. I understand DECL_DELETING_DESTRUCTOR_P would work as well...


Tested x86_64-linux.

Thanks,
Paolo.

///
2011-10-08  Paolo Carlini  

PR c++/34927
* typeck2.c (abstract_virtuals_error_sfinae): Don't produce duplicate
inform messages in case of cloned destructor.
Index: typeck2.c
===
--- typeck2.c   (revision 179660)
+++ typeck2.c   (working copy)
@@ -340,7 +340,10 @@ abstract_virtuals_error_sfinae (tree decl, tree ty
  type);
 
   FOR_EACH_VEC_ELT (tree, pure, ix, fn)
-   inform (input_location, "\t%+#D", fn);
+   if (! DECL_CLONED_FUNCTION_P (fn)
+   || DECL_COMPLETE_DESTRUCTOR_P (fn))
+ inform (input_location, "\t%+#D", fn);
+
   /* Now truncate the vector.  This leaves it non-null, so we know
 there are pure virtuals, but empty so we don't list them out
 again.  */


Re: [wwwdocs] Add info about IPA optimization and LTO improvments

2011-10-08 Thread Gerald Pfeifer
On Wed, 28 Sep 2011, Andi Kleen wrote:
> ld -r is now supported with LTO. When using assembler files or non 
> LTOed objects inside ld -r objects together with LTO then the Linux 
> binutils 2.21.51.0.3 or later are needed.

I think this should be GNU/Linux, if anything, but then I also think
we should not refer to this $notsurewhatthepropertermis variant of our 
official binutils project as part of GCC release notes.

Gerald


Re: [wwwdocs] Add info about IPA optimization and LTO improvments

2011-10-08 Thread Andi Kleen
On Sat, Oct 08, 2011 at 05:38:07PM -0400, Gerald Pfeifer wrote:
> On Wed, 28 Sep 2011, Andi Kleen wrote:
> > ld -r is now supported with LTO. When using assembler files or non 
> > LTOed objects inside ld -r objects together with LTO then the Linux 
> > binutils 2.21.51.0.3 or later are needed.
> 
> I think this should be GNU/Linux, if anything, but then I also think
> we should not refer to this $notsurewhatthepropertermis variant of our 
> official binutils project as part of GCC release notes.

Okay. The users will stay mystified then.  Hopefully they are good
at googling.

-Andi

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


Re: [DF] [performance] generate DF_REF_BASE REFs in REGNO order

2011-10-08 Thread Dimitrios Apostolou

Hello all,

I received my GSOC t-shirt yesterday which reminded me I have a promise to 
keep... After realising that it can take forever to find enough free time 
to work on GCC, I decided to work a couple of hours whenever I can and 
post updates to my patches as time permits. Hopefully some of them will 
make it into 4.7?


On Mon, 22 Aug 2011, Dimitrios Apostolou wrote:


For the record I'm posting here the final version of this patch, in case it 
gets applied. It adds minor stylistic fixes, plus a small change in 
alloc_pool sizes. Any further testing I do will be posted under this thread.


The previously posted Changelog applies, with the following addition:

(df_scan_alloc): Rounded up allocation pools size, reduced the
mw_reg_pool size, it was unnecessarily large.

Paolo, did I assume correctly that the mw_reg_pool is significantly smaller 
than the rest? That was the case on i386, I assumed it would be similar in 
other arch as well.




The attached patch (df2b.diff, exactly the same as the one in parent 
email) applies successfully to latest gcc snapshot. In addition to 
previous testing (i386,x86_64) I've just finished testing on 
sparc-linux-gnu at the GCC compile farm having no regressions. Finally I 
think Steven's tests on IA64 went ok. Wasn't testing the only thing 
holding this patch?


On sparc runtime of compiling df-scan.c seems to have been reduced from 
34s to 33s user time, for a debug build 
(--enable-checking=assert,misc,runtime,rtl,df). But measurements are too 
flaky since node is busy.




The complete changelog is the following:

2011-07-29  Dimitrios Apostolou  
Paolo Bonzini  

(df_def_record_1): Assert a parallel must contain an EXPR_LIST at
this point.  Receive the LOC and move its extraction...
(df_defs_record): ... here. Rewrote logic with a switch statement
instead of multiple if-else.
(df_find_hard_reg_defs, df_find_hard_reg_defs_1): New functions
that duplicate the logic of df_defs_record() and df_def_record_1()
but without actually recording any DEFs, only marking them in
the defs HARD_REG_SET.
(df_get_call_refs): Call df_find_hard_reg_defs() to mark DEFs that
are the result of the call. Record DF_REF_BASE DEFs in REGNO
order. Use regs_invalidated_by_call HARD_REG_SET instead of
regs_invalidated_by_call_regset bitmap.
(df_insn_refs_collect): Record DF_REF_REGULAR DEFs after
df_get_call_refs().
(df_scan_alloc): Rounded up allocation pools size, reduced the
mw_reg_pool size, it was unnecessarily large.


Thanks,
Dimitris=== modified file 'gcc/df-scan.c'
--- gcc/df-scan.c   2011-02-02 20:08:06 +
+++ gcc/df-scan.c   2011-08-22 15:17:18 +
@@ -111,7 +111,7 @@ static void df_ref_record (enum df_ref_c
   rtx, rtx *,
   basic_block, struct df_insn_info *,
   enum df_ref_type, int ref_flags);
-static void df_def_record_1 (struct df_collection_rec *, rtx,
+static void df_def_record_1 (struct df_collection_rec *, rtx *,
 basic_block, struct df_insn_info *,
 int ref_flags);
 static void df_defs_record (struct df_collection_rec *, rtx,
@@ -318,7 +318,7 @@ df_scan_alloc (bitmap all_blocks ATTRIBU
 {
   struct df_scan_problem_data *problem_data;
   unsigned int insn_num = get_max_uid () + 1;
-  unsigned int block_size = 400;
+  unsigned int block_size = 512;
   basic_block bb;
 
   /* Given the number of pools, this is really faster than tearing
@@ -347,7 +347,7 @@ df_scan_alloc (bitmap all_blocks ATTRIBU
 sizeof (struct df_reg_info), block_size);
   problem_data->mw_reg_pool
 = create_alloc_pool ("df_scan mw_reg",
-sizeof (struct df_mw_hardreg), block_size);
+sizeof (struct df_mw_hardreg), block_size / 16);
 
   bitmap_obstack_initialize (&problem_data->reg_bitmaps);
   bitmap_obstack_initialize (&problem_data->insn_bitmaps);
@@ -2916,40 +2916,27 @@ df_read_modify_subreg_p (rtx x)
 }
 
 
-/* Process all the registers defined in the rtx, X.
+/* Process all the registers defined in the rtx pointed by LOC.
Autoincrement/decrement definitions will be picked up by
df_uses_record.  */
 
 static void
 df_def_record_1 (struct df_collection_rec *collection_rec,
- rtx x, basic_block bb, struct df_insn_info *insn_info,
+ rtx *loc, basic_block bb, struct df_insn_info *insn_info,
 int flags)
 {
-  rtx *loc;
-  rtx dst;
-
- /* We may recursively call ourselves on EXPR_LIST when dealing with PARALLEL
- construct.  */
-  if (GET_CODE (x) == EXPR_LIST || GET_CODE (x) == CLOBBER)
-loc = &XEXP (x, 0);
-  else
-loc = &SET_DEST (x);
-  dst = *loc;
+  rtx dst = *loc;
 
   /* It is legal to have a set destination be a parallel. */
   if (GET_CODE (dst) == PARALLEL)
  

Re: Rename vshuffle/vec_shuffle to vec_perm

2011-10-08 Thread H.J. Lu
On Fri, Oct 7, 2011 at 3:49 PM, Richard Henderson  wrote:
> Our existing vector permutation support uses the name vec_perm.
> The new support added for __builtin_shuffle used a variety of
> names.  This brings all the internals into line with vec_perm.
>
> I've added documentation for the (existing) variable permute
> rtl named pattern (vec_perm).  I've also added documentation for
> the (intended) constant permute rtl named pattern (vec_perm_const).
> I've not actually added the support for vec_perm_const yet, but
> plan to do so shortly.  It was just easiest to do the docs for
> both at the same time.
>
> The builtin is still named shuffle in honor of the OpenCL primitive
> on which this feature is based.  I've improved the documentation
> for the builtin a bit to make it clear that the selector modulus
> is part of the interface.
>
> Tested on x86_64-linux.
>

Is this a typo:

@@ -557,6 +560,7 @@ enum optab_index
 #define vec_pack_usat_optab (&optab_table[OTI_vec_pack_usat])
 #define vec_pack_sfix_trunc_optab (&optab_table[OTI_vec_pack_sfix_trunc])
 #define vec_pack_ufix_trunc_optab (&optab_table[OTI_vec_pack_ufix_trunc])
+#define vec_perm_optab (&direct_optab_table[(int) OTI_vec_perm])
^

 #define powi_optab (&optab_table[OTI_powi])




-- 
H.J.


Re: Rename vshuffle/vec_shuffle to vec_perm

2011-10-08 Thread H.J. Lu
On Sat, Oct 8, 2011 at 3:56 PM, H.J. Lu  wrote:
> On Fri, Oct 7, 2011 at 3:49 PM, Richard Henderson  wrote:
>> Our existing vector permutation support uses the name vec_perm.
>> The new support added for __builtin_shuffle used a variety of
>> names.  This brings all the internals into line with vec_perm.
>>
>> I've added documentation for the (existing) variable permute
>> rtl named pattern (vec_perm).  I've also added documentation for
>> the (intended) constant permute rtl named pattern (vec_perm_const).
>> I've not actually added the support for vec_perm_const yet, but
>> plan to do so shortly.  It was just easiest to do the docs for
>> both at the same time.
>>
>> The builtin is still named shuffle in honor of the OpenCL primitive
>> on which this feature is based.  I've improved the documentation
>> for the builtin a bit to make it clear that the selector modulus
>> is part of the interface.
>>
>> Tested on x86_64-linux.
>>
>
> Is this a typo:
>
> @@ -557,6 +560,7 @@ enum optab_index
>  #define vec_pack_usat_optab (&optab_table[OTI_vec_pack_usat])
>  #define vec_pack_sfix_trunc_optab (&optab_table[OTI_vec_pack_sfix_trunc])
>  #define vec_pack_ufix_trunc_optab (&optab_table[OTI_vec_pack_ufix_trunc])
> +#define vec_perm_optab (&direct_optab_table[(int) OTI_vec_perm])
> ^
>
>  #define powi_optab (&optab_table[OTI_powi])
>

DOI_vshuffle is renamed/moved to OTI_vec_perm.  But the rename/move
is incomplete, which caused:

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


-- 
H.J.


Re: [C++ Patch] PR 34927 (Take 2)

2011-10-08 Thread Jason Merrill

OK.

Jason


Re: [C++-11] User defined literals

2011-10-08 Thread Jason Merrill

On 10/08/2011 07:25 PM, Ed Smith-Rowland wrote:

Also, In spite of the documentation cp_parser_template_parameter_list
returns a TREE_VEC not a TREE_LIST. This happens inside
end_template_parm_list called inside the former. So parameter_list is a
TREE_VEC, parm_list is a TREE_LIST, parm is a PARM_DECL, etc.


Ah, I was thinking of template arguments rather than parameters.  You're 
right, except that INNERMOST_TEMPLATE_PARMS should be just TREE_VALUE; 
you are already starting from the innermost parm list if you use what 
end_template_parm_list returns.


Though it occurs to me that push_template_decl_real might be a better 
place for this check.



I'm still looking for a fix for duplicate errors/warnings coming from
cp_parser_operator. I tried cp_parser_error and lost the errors. I'll
look for different code paths for the two invocations and see if I can
either move something up or see if something is set differently between
the two that would be useful for a flag.


One approach would be changing the token stream after the first error to 
something that won't produce another error, e.g. changing token->u.value 
to be an empty string after you complain about it being non-empty.


Jason


Re: [PATCH] Fix htab lookup bug in reregister_specialization (issue5190046, take 2)

2011-10-08 Thread Jason Merrill

On 10/07/2011 12:14 PM, Jakub Jelinek wrote:

Here is a modified patch then, bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?  Would just the reregister_specialization
change be ok for 4.6 too?


Yes and yes.

Jason



Re: [google] record compiler options to .note sections

2011-10-08 Thread Dehao Chen
Unfortunately -frecord-gcc-switches cannot serve our purpose because
the recorded switches are mergable, i.e. the linker will merge all
options to a set of strings. However, object files may have distinct
compile options. We want to preserve every object file's compile
options when doing LIPO build.

Thanks,
Dehao

On Sat, Oct 8, 2011 at 7:41 PM, Jakub Jelinek  wrote:
> On Sat, Oct 08, 2011 at 06:43:47PM +0800, Dehao Chen wrote:
>> This patch records the compiler command-line flags to a .note section,
>> which could be used by FDO/LIPO.
>>
>> Bootstrapped on x86_64, no regressions.
>>
>> Is it ok for google/gcc-4_6 and google/main branches?
>
> Why yet another record switches option?  Isn't -grecord-gcc-switches
> good enough for you (or -frecord-gcc-switches)?
>
>        Jakub
>