Re: [Patch, AVR]: AVR backend cleanup: use elfos.h

[Denis Chertykov]

2011/6/27 Georg-Johann Lay :
> or
>
> [ ] Remove the undefs so that we have .ident.
>    There's nothing terrific about it, it just adds
>    some text to .comment section.  I guess it's missing
>    because noone ever added it.

This one.

Denis.

Re: [RFC] Fix full memory barrier on SPARC-V8

[David Miller]

From: Geert Bosch 
Date: Mon, 27 Jun 2011 23:17:18 -0400

>> \You then go on to speak about LEON, does LEON implement PSO?
> No, I'm not talking about PSO anywhere or SPARCv9 anywhere. 
> Just plain old SPARCv8, using the TSO model. This requires a
> load-store instruction to guarantee a full memory barrier.
> 
> I'm not making this up, that is why I refer to the examples in
> the SPARC v8 architecture manual that specifically state that
> SWAP instructions need to be used instead of store instructions
> to make Dekker's algorithm work.

All v8 processors that I am aware of implement strong consistency, and
if so discussions about TSO are not relevant.  Is LEON an exception?

Let's clarify something, did you run your testcase that triggered this
bug on a v8 or a v9 machine?

Re: [RFC] Fix full memory barrier on SPARC-V8

[Geert Bosch]

On Jun 27, 2011, at 22:45, David Miller wrote:

> From: Geert Bosch 
> Date: Mon, 27 Jun 2011 22:21:47 -0400
> 
>> On Jun 27, 2011, at 19:53, David Miller wrote:
>> 
>>> Adding a ldstub here is going to be really expensive, on UltraSparc
>>> that can be 36+ cycles even on a cache hit.
>> 
>> Yes, synchronization in multi-CPU systems is expensive.
>> If it's really cheap, you're probably doing something wrong.
> 
> First, I fundamentally disagree with this assertion.  The reason
> proper memory barriers exist is so that you don't need nonsense like
> these proposed atomics to get proper memory operation ordering.
Sorry, I see now I phrased this poorly, no offense intended. We both 
agree that with TSO there is never a need for any STBAR instructions on 
SPARCv8. The point is that TSO is not sufficient for strong consistency.
The reason for this is the existence of write buffers (see fig 6.1, or K-1
of the SPARC v8 architecture manual). In particular, note the CPU-local
bypass from the store buffer. Two processors both storing a value X in 
location Y and then reading from Y might each see their own value. In
the end, one will reach memory first and the stores will be ordered
there. The load-store instructions are necessary to ensure the store
will be seen by the memory system before subsequent loads can use them.

The main issue is that SPARC's TSO does not guarantee Store-Load ordering.
So, only by issuing a SWAP(A) or LDSTUB(A) instruction can total ordering
of all loads and stores be guaranteed. 
> 
> A proper membar on your v9 test system is orders of magnitude cheaper
> than this stbar+ldstub business.
That's true, but membar is a SPARC v9 instruction. The issue Eric and I
are addressing is only about SPARCv8. 

> \You then go on to speak about LEON, does LEON implement PSO?
No, I'm not talking about PSO anywhere or SPARCv9 anywhere. 
Just plain old SPARCv8, using the TSO model. This requires a
load-store instruction to guarantee a full memory barrier.

I'm not making this up, that is why I refer to the examples in
the SPARC v8 architecture manual that specifically state that
SWAP instructions need to be used instead of store instructions
to make Dekker's algorithm work.

  -Geert

Re: [RFC] Fix full memory barrier on SPARC-V8

[David Miller]

From: David Miller 
Date: Mon, 27 Jun 2011 19:45:33 -0700 (PDT)

> You then go on to speak about LEON, does LEON implement PSO?

BTW, even if it does, I would be encouraging the person who submits
LEON kernel patches to not run the chip in this mode.

We don't even use PSO for v9 chips, it's just not worth the hassle.

So I think even from a v8 LEON perspective this is a non-issue.

Re: [RFC] Fix full memory barrier on SPARC-V8

[David Miller]

From: Geert Bosch 
Date: Mon, 27 Jun 2011 22:21:47 -0400

> On Jun 27, 2011, at 19:53, David Miller wrote:
> 
>> Adding a ldstub here is going to be really expensive, on UltraSparc
>> that can be 36+ cycles even on a cache hit.
> 
> Yes, synchronization in multi-CPU systems is expensive.
> If it's really cheap, you're probably doing something wrong.

First, I fundamentally disagree with this assertion.  The reason
proper memory barriers exist is so that you don't need nonsense like
these proposed atomics to get proper memory operation ordering.

A proper membar on your v9 test system is orders of magnitude cheaper
than this stbar+ldstub business.

You then go on to speak about LEON, does LEON implement PSO?

Re: [RFC] Fix full memory barrier on SPARC-V8

[Geert Bosch]

On Jun 27, 2011, at 19:53, David Miller wrote:

> I'm trying to find the part of the v8 manual that says there is
> a situation where we should use "stbar" and a "ldstub" to implement
> proper memory barriers.  In particular I'm looking in Appendix J,
> "Programming with the memory models."  Where is the description?
See J.7, and study why the store instructions are replaces by SWAP.
> 
> Adding a ldstub here is going to be really expensive, on UltraSparc
> that can be 36+ cycles even on a cache hit.

Yes, synchronization in multi-CPU systems is expensive.
If it's really cheap, you're probably doing something wrong.

> Also, the more I think about it, the issue really is that one is
> trying to run v8 code on a v9 cpu.

Double no:
   1. No, my primary concern is about v8 code running on multiprocessor
  systems implementing the SPARC v8 architecture (LEON3 in particular)
   2. No, a SPARCv8 compliant binary should run correctly on both
  SPARCv8 and SPARCv9. The entire raison-d'être for the SPARC
  architecture is so we can write code based on the architecture,
  and have it run correctly on all implementations.

  -Geert

Re: [patch, fortran] Fix PR 49479, reshape with optional arg

[Jerry DeLisle]

On 06/27/2011 03:18 PM, Thomas Koenig wrote:

Hello world,

the attached patch fixes PR 49479, a regression for 4.7 and 4.6. Test
case was supplied by Joost, the approach to the patch was suggested by
Tobias in comment#4 of the PR. The patch certainly looks safe enough.

Regression-tested. OK for trunk and, after a couple of days, for 4.6?

Thomas



OK,

Jerry

[pph] Update Tests (issue4636066)

[Lawrence Crowl]

Add missing mappings in pph.map.  These new mappings result in changes
to assembly difference expectations.

Remove namespace issues from x1template test.  Copy that test to a new
test x1namespace.

Add a new test x1dynarray, which is executable, when existing failures
get fixed.


Index: gcc/testsuite/ChangeLog.pph

2011-06-27  Lawrence Crowl  

* g++.dg/pph/pph.map: Add missing PPH mappings.
* g++.dg/pph/c1funcstatic.cc: Add expected asm diff.
* g++.dg/pph/c1eabi1.cc: Add xfail-if; remove expected asm diff.
* g++.dg/pph/c2builtin2.cc: Add expected asm diff.
* g++.dg/pph/x1funcstatic.cc: Add expected asm diff.
* g++.dg/pph/x1template.h: Remove use of namespace.
* g++.dg/pph/x1template.cc: Remove use of namespace; now passing.
* g++.dg/pph/x1namespace.h: New, copy of old x1template.h.
* g++.dg/pph/x1namespace.cc: New, copy of old x1template.cc.
* g++.dg/pph/x1dynarray1.h: New executable program, but it fails.
* g++.dg/pph/x1dynarray1.cc: New executable program, but it fails.


Index: gcc/testsuite/g++.dg/pph/c1funcstatic.cc
===
--- gcc/testsuite/g++.dg/pph/c1funcstatic.cc(revision 175566)
+++ gcc/testsuite/g++.dg/pph/c1funcstatic.cc(working copy)
@@ -1,2 +1,3 @@
+// pph asm xdiff
 #include "c1funcstatic.h"
 int g() { return f(); }
Index: gcc/testsuite/g++.dg/pph/x1namespace.h
===
--- gcc/testsuite/g++.dg/pph/x1namespace.h  (revision 0)
+++ gcc/testsuite/g++.dg/pph/x1namespace.h  (revision 0)
@@ -0,0 +1,22 @@
+#ifndef X1NAMESPACE_H
+#define X1NAMESPACE_H
+namespace A {
+extern int x;
+struct B;
+template< typename T >
+struct C {
+T* b;
+int method();
+int another()
+{ return *b; }
+};
+template< typename T >
+int C< T >::method()
+{ return x; }
+} // namespace A
+struct D : A::C< int > {
+int method();
+int another()
+{ return *b; }
+};
+#endif
Index: gcc/testsuite/g++.dg/pph/x1template.h
===
--- gcc/testsuite/g++.dg/pph/x1template.h   (revision 175566)
+++ gcc/testsuite/g++.dg/pph/x1template.h   (working copy)
@@ -1,6 +1,5 @@
 #ifndef X1TEMPLATE_H
 #define X1TEMPLATE_H
-namespace A {
 extern int x;
 struct B;
 template< typename T >
@@ -13,8 +12,7 @@ struct C {
 template< typename T >
 int C< T >::method()
 { return x; }
-} // namespace A
-struct D : A::C< int > {
+struct D : C< int > {
 int method();
 int another()
 { return *b; }
Index: gcc/testsuite/g++.dg/pph/c1eabi1.cc
===
--- gcc/testsuite/g++.dg/pph/c1eabi1.cc (revision 175566)
+++ gcc/testsuite/g++.dg/pph/c1eabi1.cc (working copy)
@@ -1,5 +1,5 @@
 // { dg-timeout 2 { target *-*-* } }
+// { dg-xfail-if "INFINITE" { "*-*-*" } { "-fpph-map=pph.map" } }
 // { dg-options "-w -fpermissive" }
-// pph asm xdiff
 
 #include "c1eabi1.h"
Index: gcc/testsuite/g++.dg/pph/c2builtin2.cc
===
--- gcc/testsuite/g++.dg/pph/c2builtin2.cc  (revision 175566)
+++ gcc/testsuite/g++.dg/pph/c2builtin2.cc  (working copy)
@@ -1,3 +1,4 @@
+// pph asm xdiff
 #include "a2builtin4.h"
 #include "c2builtin5.h"
 #include "c2builtin6.h"
Index: gcc/testsuite/g++.dg/pph/pph.map
===
--- gcc/testsuite/g++.dg/pph/pph.map(revision 175566)
+++ gcc/testsuite/g++.dg/pph/pph.map(working copy)
@@ -6,9 +6,11 @@ c1builtin-integral-1.h c1builtin-integra
 c1builtin-object-size-2.h  c1builtin-object-size-2.pph
 c1chained1.h   c1chained1.pph
 c1chained2.h   c1chained2.pph
+c1eabi1.h  c1eabi1.pph
 c1empty.h  c1empty.pph
 c1field.h  c1field.pph
 c1funcmac.hc1funcmac.pph
+c1funcstatic.h c1funcstatic.pph
 c1functions.h  c1functions.pph
 c1guarded1.h   c1guarded1.pph
 c1guarded2.h   c1guarded2.pph
@@ -28,6 +30,8 @@ c1variables.h c1variables.pph
 c2builtin1.h   c2builtin1.pph
 c2builtin2.h   c2builtin2.pph
 c2builtin3.h   c2builtin3.pph
+c2builtin5.h   c2builtin5.pph
+c2builtin6.h   c2builtin6.pph
 c2dupguard1.h  c2dupguard1.pph
 c2dupguard2.h  c2dupguard2.pph
 c2paste.h  c2paste.pph
@@ -38,10 +42,12 @@ stdlib.hstdlib.pph
 string.h   string.pph
 sys/types.htypes.pph
 x1autometh.h   x1autometh.pph
+x1dynarray1.h  x1dynarray1.pph
 x1funcstatic.h x1funcstatic.pph
 x1functions.h  x1functions.pph
 x1globalref.h  x1globalref.pph
 x1hardlookup.h x1hardlookup.pph
+x1namespace.h  x1namespace.pph
 x1special.hx1special.pph
 x1struct0.hx1struct0.pph
 x1struct1.hx1struct1.pph
@@ -53,6 +59,6 @@ x1tmplfunc.h  x1tmplfunc.pph
 x1typerefs.h   x1typerefs.pph
 x1variables.h  x1variables.pph
 x2nontrivinit.hx2nontrivinit.pph
-y2overload1.h  y2overload1.pph
-y2overload2.h  y2overload2.pph
-y2overload3.h  y2overload3.pph
+x2overloa

Re: Split insn-attr.h

[Bernd Schmidt]

On 06/28/11 02:24, Joseph S. Myers wrote:
> 
>   * genattr-common.c: New.  Based on genattr.c.
>   * Makefile.in (INSN_ATTR_H): Include insn-attr-common.h.
>   (MOSTLYCLEANFILES): Add insn-attr-common.h.
>   (opts.o): Update dependencies.
>   (.PRECIOUS): Add insn-attr-common.h.
>   (simple_rtl_generated_h): Add insn-attr-common.h.
>   (build/genattr-common.o): New.
>   (genprogrtl): Add attr-common.
>   * genattr.c (main): Include insn-attr-common.h.  Don't generate
>   definitions of DELAY_SLOTS or INSN_SCHEDULING.
>   * opts.c: Include insn-attr-common.h instead of rtl.h and
>   insn-attr.h.

Ok.


Bernd

[pph] Fix var order when streaming in. (issue4635074)

[Gabriel Charette]

The names and namespaces chains are built by adding each new element to the 
front of the list. When streaming it in we traverse the list of names and 
re-add them to the current chains; thus reversing the order in which they were 
defined in the header file.

Since this is a singly linked-list we cannot start from the tail; thus we 
reverse the chain in place and then traverse it, now adding the bindings in the 
same order they were found in the header file.

I introduced a new failing test to test this. The test showed the reverse 
behaviour prior to the patch.
The test still fails however, there is another inversion problem between the 
global variables and the .LFBO, .LCFI0, ...
This patch only fixes the inversion of the global variables declarations in the 
assembly, not the second issue this is exposing.
This second issue is potentially already exposed by another test?? Do we need 
this new test?

This fixes all of the assembly mismatches in c1limits-externalid.cc however!

Tested with bootstrap build and pph regression testing.

2011-06-27  Gabriel Charette  

* pph-streamer-in.c (pph_add_bindings_to_namespace): Reverse names and
namespaces chains.

* g++.dg/pph/c1limits-externalid.cc: Remove pph asm xdiff.
* g++.dg/pph/c1varorder.cc: New.
* g++.dg/pph/c1varorder.h: New.
* g++.dg/pph/pph.map: Add c1varorder.h

diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
index 93b5685..cfa2ce5 100644
--- a/gcc/cp/pph-streamer-in.c
+++ b/gcc/cp/pph-streamer-in.c
@@ -1141,6 +1141,11 @@ pph_add_bindings_to_namespace (struct cp_binding_level 
*bl, tree ns)
 {
   tree t, chain;
 
+  /* The chains are built backwards (ref: add_decl_to_level@name-lookup.c),
+ reverse them before putting them back in.  */
+  bl->names = nreverse (bl->names);
+  bl->namespaces = nreverse (bl->namespaces);
+
   for (t = bl->names; t; t = chain)
 {
   /* Pushing a decl into a scope clobbers its DECL_CHAIN.
diff --git a/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc 
b/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc
index 8d2da40..8b5039c 100644
--- a/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc
+++ b/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc
@@ -1,2 +1 @@
-// pph asm xdiff
 #include "c1limits-externalid.h"
diff --git a/gcc/testsuite/g++.dg/pph/c1varorder.cc 
b/gcc/testsuite/g++.dg/pph/c1varorder.cc
new file mode 100644
index 000..2db8209
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pph/c1varorder.cc
@@ -0,0 +1,7 @@
+#include "c1varorder.h"
+// pph asm xdiff
+
+int foo(void)
+{
+  return var1 - var2;
+}
diff --git a/gcc/testsuite/g++.dg/pph/c1varorder.h 
b/gcc/testsuite/g++.dg/pph/c1varorder.h
new file mode 100644
index 000..a87c80c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pph/c1varorder.h
@@ -0,0 +1,7 @@
+#ifndef __C1VARORDER_H
+#define __C1VARORDER_H
+
+int var1;
+int var2;
+
+#endif
diff --git a/gcc/testsuite/g++.dg/pph/pph.map b/gcc/testsuite/g++.dg/pph/pph.map
index 2735af8..2ed5bf2 100644
--- a/gcc/testsuite/g++.dg/pph/pph.map
+++ b/gcc/testsuite/g++.dg/pph/pph.map
@@ -25,6 +25,7 @@ c1simple2.h   c1simple2.pph
 c1struct.h c1struct.pph
 c1typerefs.h   c1typerefs.pph
 c1variables.h  c1variables.pph
+c1varorder.h   c1varorder.pph
 c2builtin1.h   c2builtin1.pph
 c2builtin2.h   c2builtin2.pph
 c2builtin3.h   c2builtin3.pph

--
This patch is available for review at http://codereview.appspot.com/4635074

Split insn-attr.h

[Joseph S. Myers]

opts.c includes insn-attr.h to get the definitions of INSN_SCHEDULING
and DELAY_SLOTS, used to determine whether to enable certain options
by default at certain -O levels.  insn-attr.h in turn requires rtl.h
to have been included first (and rtl.h requires tm.h, although there
are other tm.h dependencies in opts.c as well).

Apart from being a modularity issue - option handling shouldn't care
about RTL - this is also a problem for linking opts.o into the driver,
because these headers, and others they include, contain various inline
functions that in turn call other out-of-line functions not available
in the driver (and the stage1 compiler is built with
-fkeep-inline-functions so this issue gets detected reliably then).

This patch splits the two required macros into a new generated header
insn-attr-common.h.  It follows the minimal approach of including this
header in insn-attr.h so that files including insn-attr.h don't need
to change, but it might make sense to clean things up in future with
explicit includes of insn-attr-common.h in those files testing either
of the affected macros, removing the insn-attr.h includes if no other
definitions from that header are used.  (In checking for such files -
there aren't that many - I also noticed that the target macro
DELAY_SLOTS_FOR_EPILOGUE is used and documented but not defined by any
target, so the code relating to that macro is ripe for removal and
poisoning of the macro.)

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
commit?

2011-06-27  Joseph Myers  

* genattr-common.c: New.  Based on genattr.c.
* Makefile.in (INSN_ATTR_H): Include insn-attr-common.h.
(MOSTLYCLEANFILES): Add insn-attr-common.h.
(opts.o): Update dependencies.
(.PRECIOUS): Add insn-attr-common.h.
(simple_rtl_generated_h): Add insn-attr-common.h.
(build/genattr-common.o): New.
(genprogrtl): Add attr-common.
* genattr.c (main): Include insn-attr-common.h.  Don't generate
definitions of DELAY_SLOTS or INSN_SCHEDULING.
* opts.c: Include insn-attr-common.h instead of rtl.h and
insn-attr.h.

Index: gcc/genattr-common.c
===
--- gcc/genattr-common.c(revision 0)
+++ gcc/genattr-common.c(revision 0)
@@ -0,0 +1,83 @@
+/* Generate attribute information shared between driver and core
+   compilers (insn-attr-common.h) from machine description.  Split out
+   of genattr.c.
+   Copyright (C) 1991, 1994, 1996, 1998, 1999, 2000, 2003, 2004, 2007, 2008,
+   2010, 2011  Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC 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 GCC; see the file COPYING3.  If not see
+.  */
+
+
+#include "bconfig.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "rtl.h"
+#include "errors.h"
+#include "read-md.h"
+#include "gensupport.h"
+
+int
+main (int argc, char **argv)
+{
+  rtx desc;
+  bool have_delay = false;
+  bool have_sched = false;
+
+  progname = "genattr-common";
+
+  if (!init_rtx_reader_args (argc, argv))
+return (FATAL_EXIT_CODE);
+
+  puts ("/* Generated automatically by the program `genattr-common'");
+  puts ("   from the machine description file `md'.  */\n");
+  puts ("#ifndef GCC_INSN_ATTR_COMMON_H");
+  puts ("#define GCC_INSN_ATTR_COMMON_H\n");
+
+  /* Read the machine description.  */
+
+  while (1)
+{
+  int line_no, insn_code_number;
+
+  desc = read_md_rtx (&line_no, &insn_code_number);
+  if (desc == NULL)
+   break;
+
+  if (GET_CODE (desc) == DEFINE_DELAY)
+{
+ if (!have_delay)
+   {
+ printf ("#define DELAY_SLOTS\n");
+ have_delay = true;
+   }
+   }
+  else if (GET_CODE (desc) == DEFINE_INSN_RESERVATION)
+   {
+ if (!have_sched)
+   {
+ printf ("#define INSN_SCHEDULING\n");
+ have_sched = true;
+   }
+   }
+}
+  puts ("\n#endif /* GCC_INSN_ATTR_COMMON_H */");
+
+  if (ferror (stdout) || fflush (stdout) || fclose (stdout))
+return FATAL_EXIT_CODE;
+
+  return SUCCESS_EXIT_CODE;
+}
Index: gcc/opts.c
===
--- gcc/opts.c  (revision 175330)
+++ gcc/opts.c  (working copy)
@@ -23,17 +23,16 @@ along with GCC; see the file COPYING3.  
 #include "system.h"
 #include "intl.h"
 #include "coretypes.h"
-#include "tm.h

Re: [testsuite] ARM: don't specify unneeded -march

[Mike Stump]

On Jun 21, 2011, at 2:48 PM, Janis Johnson wrote:
> I modified these tests last week to check for thumb support and to
> ignore messages about conflicting options, but -march isn't needed
> and so there shouldn't be any conflicting options.
> 
> OK?

Ok.

Re: [RFC] Fix full memory barrier on SPARC-V8

[David Miller]

From: Geert Bosch 
Date: Mon, 27 Jun 2011 19:36:06 -0400

> On Jun 27, 2011, at 19:00, David Miller  wrote:
> 
>> V8 can only reorder stores, that's why it only has a 'stbar'
>> instruction.  I'm not so sure I agree with trying to paper over the
>> fact that someone has compiled code for v8 that's going to run on a v9
>> cpu.
>
> That's not the issue. While it is true that all stores will be
> submitted in order , this does not guarantee store-load
> consistency. In particular on a multiprocessor, each individual
> processor has it's own store buffers and cannot see what is in the
> other CPUs store buffet. In the end all stores will be committed to
> memory in a sequential order, but that is not sufficient. The use of
> a load-store instruction is needed to achieve a full barrier.  The
> SPARC architecture manuals describe this in detail.

I'm trying to find the part of the v8 manual that says there is
a situation where we should use "stbar" and a "ldstub" to implement
proper memory barriers.  In particular I'm looking in Appendix J,
"Programming with the memory models."  Where is the description?

Adding a ldstub here is going to be really expensive, on UltraSparc
that can be 36+ cycles even on a cache hit.

Also, the more I think about it, the issue really is that one is
trying to run v8 code on a v9 cpu.

And this is because no v8 cpu ever implemented anything other than
"Strong Consistency", so on a v8 cpu you would never run into this
problem.

I really think the answer in this situation is "compile code for the
actual processor you're targetting, especially if you want features
with processor specific behaviors, such as atomics and memory
barriers, to work properly."

Re: [RFC] Fix full memory barrier on SPARC-V8

[Geert Bosch]

On Jun 27, 2011, at 19:00, David Miller  wrote:

> V8 can only reorder stores, that's why it only has a 'stbar'
> instruction.  I'm not so sure I agree with trying to paper over the
> fact that someone has compiled code for v8 that's going to run on a v9
> cpu.

That's not the issue. While it is true that all stores will be submitted in 
order , this does not guarantee store-load consistency. In particular on a 
multiprocessor, each individual processor has it's own store buffers and cannot 
see what is in the other CPUs store buffet. In the end all stores will be 
committed to memory in a sequential order, but that is not sufficient. The use 
of a load-store instruction is needed to achieve a full barrier.  The SPARC 
architecture manuals describe this in detail. 

  -Geert

Re: [google] Enable both ld and gold in gcc (issue4664051)

[H.J. Lu]

On Mon, Jun 27, 2011 at 4:09 PM, Doug Kwan  wrote:
> This patch enables both ld and gold in gcc using the -fuse-ld switch.  The
> original patch use written by Nick Clifton and was subsequently updated by
> Matthias Klose.  The patch currently does not work with LTO but that is
> okay for now and it is no worse than its counterpart in an older gcc version.

Why doesn't work with LTO?  I can interchange ld.gold and ld.bfd for LTO
without any problems.


-- 
H.J.

[google] Enable both ld and gold in gcc (issue4664051)

[Doug Kwan]

This patch enables both ld and gold in gcc using the -fuse-ld switch.  The
original patch use written by Nick Clifton and was subsequently updated by
Matthias Klose.  The patch currently does not work with LTO but that is
okay for now and it is no worse than its counterpart in an older gcc version.
We need this functionality for now.  It is mostly used as a safety net in the
Android toolchain if gold does not work.  We can disable LTO in that case.
Hopefully we will fix this can resubmit it for trunk later.

This is tested by running ./buildit and building the Android toolchain.

I would like to apply this to goolge/main only.

2011-06-27   Doug Kwan  

Google ref 41164-p2
Backport upstream patch under review.

2011-01-19   Nick Clifton  
 Matthias Klose 

* configure.ac (gcc_cv_gold_srcdir): New cached variable -
contains the location of the gold sources.
(ORIGINAL_GOLD_FOR_TARGET): New substituted variable - contains
the name of the locally built gold executable.
* configure: Regenerate.
* collect2.c (main): Detect the -use-gold and -use-ld switches
and select the appropriate linker, if found.
If a linker cannot be found and collect2 is executing in
verbose mode then report the search paths examined.
* exec-tool.in: Detect the -use-gold and -use-ld switches and
select the appropriate linker, if found.
Add support for -v switch.
Report problems locating linker executable.
* gcc.c (LINK_COMMAND_SPEC): Translate -fuse-ld=gold into
-use-gold and -fuse-ld=bfd into -use-ld.
* common.opt: Add fuse-ld=gold and fuse-ld=bfd.
* opts.c (comman_handle_option): Ignore -fuse-ld=gold and
-fuse-ld=bfd.
* doc/invoke.texi: Document the new options.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 175346)
+++ gcc/doc/invoke.texi (working copy)
@@ -418,7 +418,7 @@
 -funit-at-a-time -funroll-all-loops -funroll-loops @gol
 -funsafe-loop-optimizations -funsafe-math-optimizations -funswitch-loops @gol
 -fvariable-expansion-in-unroller -fvect-cost-model -fvpt -fweb @gol
--fwhole-program -fwpa -fuse-linker-plugin @gol
+-fwhole-program -fwpa -fuse-ld -fuse-linker-plugin @gol
 --param @var{name}=@var{value}
 -O  -O0  -O1  -O2  -O3  -Os -Ofast}
 
@@ -8017,6 +8017,16 @@
 
 Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, @option{-Os}.
 
+@item -fuse-ld=gold
+Use the @command{gold} linker instead of the default linker.
+This option is only necessary if GCC has been configured with
+@option{--enable-gold} and @option{--enable-ld=default}.
+
+@item -fuse-ld=bfd
+Use the @command{ld.bfd} linker instead of the default linker.
+This option is only necessary if GCC has been configured with
+@option{--enable-gold} and @option{--enable-ld}.
+
 @item -fcprop-registers
 @opindex fcprop-registers
 After register allocation and post-register allocation instruction splitting,
Index: gcc/configure
===
--- gcc/configure   (revision 175346)
+++ gcc/configure   (working copy)
@@ -681,6 +681,7 @@
 gcc_cv_objdump
 ORIGINAL_NM_FOR_TARGET
 gcc_cv_nm
+ORIGINAL_GOLD_FOR_TARGET
 ORIGINAL_LD_FOR_TARGET
 ORIGINAL_PLUGIN_LD_FOR_TARGET
 gcc_cv_ld
@@ -21131,6 +21132,21 @@
 fi
 fi
 
+gcc_cv_ld_gold_srcdir=`echo $srcdir | sed -e 's,/gcc$,,'`/gold
+
+if test "${gcc_cv_gold+set}" = set; then :
+
+else
+
+if test -f $gcc_cv_ld_gold_srcdir/configure.ac \
+ && test -f ../gold/Makefile \
+ && test x$build = x$host; then
+   gcc_cv_gold=../gold/ld-new$build_exeext
+else
+gcc_cv_gold=''
+fi
+fi
+
 ORIGINAL_PLUGIN_LD_FOR_TARGET=$gcc_cv_ld
 PLUGIN_LD=`basename $gcc_cv_ld`
 
@@ -21170,6 +21186,9 @@
  ;;
 esac
 
+ORIGINAL_GOLD_FOR_TARGET=$gcc_cv_gold
+
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking what linker to use" >&5
 $as_echo_n "checking what linker to use... " >&6; }
 if test "$gcc_cv_ld" = ../ld/ld-new$build_exeext; then
Index: gcc/gcc.c
===
--- gcc/gcc.c   (revision 175346)
+++ gcc/gcc.c   (working copy)
@@ -657,6 +657,9 @@
 }"PLUGIN_COND_CLOSE" \
 %{flto|flto=*:%max_errors = value;
   break;
 
+case OPT_fuse_ld_:
 case OPT_fuse_linker_plugin:
-  /* No-op. Used by the driver and passed to us because it starts with f.*/
+  /* No-op. Used by the driver and passed to us because it starts with f.  
*/
   break;
 
 case OPT_Wuninitialized:
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 175346)
+++ gcc/configure.ac(working copy)
@@ -1974,6 +1974,17 @@
 AC_PATH_

Re: [RFC] Fix full memory barrier on SPARC-V8

[David Miller]

From: Eric Botcazou 
Date: Mon, 27 Jun 2011 18:11:10 +0200

>   * config/sparc/sync.md (*stbar): Delete.
>   (*membar_v8): New insn to implement UNSPEC_MEMBAR in SPARC-V8.

Code which cares about memory ordering etc. really has to know
the kind of cpu it is running on.

This is why atomic and synchronization primitives are typically
restricted to shared libraries and similar, where the dynamic
linker can vet out what is the correct implementation on a
given piece of hardware.

V8 can only reorder stores, that's why it only has a 'stbar'
instruction.  I'm not so sure I agree with trying to paper over the
fact that someone has compiled code for v8 that's going to run on a v9
cpu.

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const

[H.J. Lu]

On Mon, Jun 27, 2011 at 3:25 PM, H.J. Lu  wrote:
> On Mon, Jun 27, 2011 at 3:19 PM, H.J. Lu  wrote:
>> On Mon, Jun 27, 2011 at 3:08 PM, Ulrich Weigand  wrote:
>>> H.J. Lu wrote:
>>>
 reload generates:

 (insn 914 912 0 (set (reg:SI 0 ax)
         (plus:SI (subreg:SI (reg/v/f:DI 182 [ b ]) 0)
             (const_int 8 [0x8]))) 248 {*lea_1_x32}
      (nil))

 from

 insn = emit_insn_if_valid_for_reload (gen_rtx_SET (VOIDmode, out, in));
>>>
>>> Interesting.  The pseudo should have been replaced by the
>>> hard register (reg:DI 1) during the preceding call to
>>>      op0 = find_replacement (&XEXP (in, 0));
>>> (since reload 0 should have pushed a replacement record.)
>>>
>>> Interestingly enough, in the final output that replacement *is*
>>> performed in the REG_EQUIV note:
>>>
>>> (insn 1023 1022 1024 34 (set (reg:SI 1 dx)
>>>        (plus:SI (reg:SI 1 dx)
>>>            (const_int 8 [0x8]))) spooles.c:291 248 {*lea_1_x32}
>>>     (expr_list:REG_EQUIV (plus:SI (subreg:SI (reg:DI 1 dx) 0)
>>>            (const_int 8 [0x8]))
>>>        (nil)))
>>>
>>> which is why I hadn't expected this to be a problem here.
>>>
>>> Can you try to find out why the find_replacement doesn't work
>>> with your test case?
>>>
>>
>> I will investigate.  Could (reg:SI 1 dx) vs  (subreg:SI (reg:DI 1 dx) 0)
>> a problem?
>>
>
> find_replacement never checks subreg:
>
> Breakpoint 3, find_replacement (loc=0x7068ab00)
>    at /export/gnu/import/git/gcc-x32/gcc/reload.c:6411
> 6411          if (reloadreg && r->where == loc)
> (reg:DI 0 ax)
> (reg/v/f:DI 182 [ b ])
> (gdb) call debug_rtx (*loc)
> (subreg:SI (reg/v/f:DI 182 [ b ]) 0)
> (gdb)
>

This seems to work.  Does it make any senses?

Thanks.


-- 
H.J.
---
diff --git a/gcc/reload.c b/gcc/reload.c
index 3ad46b9..bdc47d3 100644
--- a/gcc/reload.c
+++ b/gcc/reload.c
@@ -6415,6 +6415,26 @@ find_replacement (rtx *loc)

  return reloadreg;
}
+  else if (reloadreg
+  && REG_P (reloadreg)
+  && !r->subreg_loc
+  && GET_CODE (*loc) == SUBREG
+  && r->where == &SUBREG_REG (*loc))
+   {
+ int offset;
+
+ if (r->mode != VOIDmode && GET_MODE (reloadreg) != r->mode)
+   reloadreg = gen_rtx_REG (r->mode, REGNO (reloadreg));
+
+ offset = (GET_MODE_SIZE (GET_MODE (reloadreg))
+   - GET_MODE_SIZE (GET_MODE (*loc)));
+
+ if (! BYTES_BIG_ENDIAN)
+   offset = (offset / UNITS_PER_WORD) * UNITS_PER_WORD;
+ else if (! WORDS_BIG_ENDIAN)
+   offset %= UNITS_PER_WORD;
+ return gen_rtx_SUBREG (GET_MODE (*loc), reloadreg, offset);
+   }
   else if (reloadreg && r->subreg_loc == loc)
{
  /* RELOADREG must be either a REG or a SUBREG.

RE: [PATCH, i386] Enable -mprefer-avx128 by default for Bulldozer

[Fang, Changpeng]

Is this patch OK to commit to trunk?

Also I would like to backport this patch to gcc 4.6 branch. Do I have to send a 
separate 
request or use this one?

Thanks,

Changpeng





From: Fang, Changpeng
Sent: Friday, June 24, 2011 7:12 PM
To: Jan Hubicka
Cc: Uros Bizjak; gcc-patches@gcc.gnu.org; rguent...@suse.de
Subject: RE: [PATCH, i386] Enable -mprefer-avx128 by default for Bulldozer

Hi,

 I have no preference in tune feature coding. But I agree with you it's better 
to
put similar things together. I modified the code following your suggestion.

Is it OK to commit this modified patch?

Thanks,

Changpeng




From: Jan Hubicka [hubi...@ucw.cz]
Sent: Thursday, June 23, 2011 6:20 PM
To: Fang, Changpeng
Cc: Uros Bizjak; gcc-patches@gcc.gnu.org; hubi...@ucw.cz; rguent...@suse.de
Subject: Re: [PATCH, i386] Enable -mprefer-avx128 by default for Bulldozer

Hi,
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -2128,6 +2128,9 @@ static const unsigned int 
> x86_avx256_split_unaligned_load
>  static const unsigned int x86_avx256_split_unaligned_store
>= m_COREI7 | m_BDVER1 | m_GENERIC;
>
> +static const unsigned int x86_prefer_avx128
> +  = m_BDVER1;

What is reason for stuff like this to not go into initial_ix86_tune_features?
I sort of liked them better when they was individual flags, but having the 
target
tunning flags spread across multiple places seems unnecesary.

Honza

RE: Backport AVX256 load/store split patches to gcc 4.6 for performance boost on latest AMD/Intel hardware.

[Fang, Changpeng]

Hi,

Attached are the patches we propose to backport to gcc 4.6 branch which are 
related to avx256 unaligned load/store splitting.
As we mentioned before,  The combined effect of these patches are positive on 
both AMD and Intel CPUs on cpu2006 and
polyhedron 2005.

0001-Split-32-byte-AVX-unaligned-load-store.patch
Initial patch that implements unaligned load/store splitting

0001-Don-t-assert-unaligned-256bit-load-store.patch
Remove the assert.

0001-Fix-a-typo-in-mavx256-split-unaligned-store.patch
Fix a typo.

0002-pr49089-enable-avx256-splitting-unaligned-load-store.patch
Disable unaligned load splitting for bdver1.

All these patches are in 4.7 trunk.

Bootstrap and tests are on-going in gcc 4.6 branch.

Is It OK to commit to 4.6 branch as long as the tests pass?

Thanks,

Changpeng 




From: Jagasia, Harsha
Sent: Monday, June 20, 2011 12:03 PM
To: 'H.J. Lu'
Cc: 'gcc-patches@gcc.gnu.org'; 'hubi...@ucw.cz'; 'ubiz...@gmail.com'; 
'hongjiu...@intel.com'; Fang, Changpeng
Subject: RE: Backport AVX256 load/store split patches to gcc 4.6 for 
performance boost on latest AMD/Intel hardware.

> On Mon, Jun 20, 2011 at 9:58 AM,   wrote:
> > Is it ok to backport patches, with Changelogs below, already in trunk
> to gcc
> > 4.6? These patches are for AVX-256bit load store splitting. These
> patches
> > make significant performance difference >=3% to several CPU2006 and
> > Polyhedron benchmarks on latest AMD and Intel hardware. If ok, I will
> post
> > backported patches for commit approval.
> >
> > AMD plans to submit additional patches on AVX-256 load/store
> splitting to
> > trunk. We will send additional backport requests for those later once
> they
> > are accepted/comitted to trunk.
> >
>
> Since we will make some changes on trunk, I would prefer to to do
> the backport after trunk change is finished.

Ok, thanks. Adding Changpeng who is working on the trunk changes.

Harsha

From b8cb8d5224d650672add0fb6a74d759ef12e428f Mon Sep 17 00:00:00 2001
From: hjl 
Date: Sun, 27 Mar 2011 18:56:00 +
Subject: [PATCH] Split 32-byte AVX unaligned load/store.

gcc/

2011-03-27  H.J. Lu  

	* config/i386/i386.c (flag_opts): Add -mavx256-split-unaligned-load
	and -mavx256-split-unaligned-store.
	(ix86_option_override_internal): Split 32-byte AVX unaligned
	load/store by default.
	(ix86_avx256_split_vector_move_misalign): New.
	(ix86_expand_vector_move_misalign): Use it.

	* config/i386/i386.opt: Add -mavx256-split-unaligned-load and
	-mavx256-split-unaligned-store.

	* config/i386/sse.md (*avx_mov_internal): Verify unaligned
	256bit load/store.  Generate unaligned store on misaligned memory
	operand.
	(*avx_movu): Verify unaligned
	256bit load/store.
	(*avx_movdqu): Likewise.

	* doc/invoke.texi: Document -mavx256-split-unaligned-load and
	-mavx256-split-unaligned-store.

gcc/testsuite/

2011-03-27  H.J. Lu  

	* gcc.target/i386/avx256-unaligned-load-1.c: New.
	* gcc.target/i386/avx256-unaligned-load-2.c: Likewise.
	* gcc.target/i386/avx256-unaligned-load-3.c: Likewise.
	* gcc.target/i386/avx256-unaligned-load-4.c: Likewise.
	* gcc.target/i386/avx256-unaligned-load-5.c: Likewise.
	* gcc.target/i386/avx256-unaligned-load-6.c: Likewise.
	* gcc.target/i386/avx256-unaligned-load-7.c: Likewise.
	* gcc.target/i386/avx256-unaligned-store-1.c: Likewise.
	* gcc.target/i386/avx256-unaligned-store-2.c: Likewise.
	* gcc.target/i386/avx256-unaligned-store-3.c: Likewise.
	* gcc.target/i386/avx256-unaligned-store-4.c: Likewise.
	* gcc.target/i386/avx256-unaligned-store-5.c: Likewise.
	* gcc.target/i386/avx256-unaligned-store-6.c: Likewise.
	* gcc.target/i386/avx256-unaligned-store-7.c: Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@171578 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog  |   22 ++
 gcc/config/i386/i386.c |   76 +--
 gcc/config/i386/i386.opt   |8 ++
 gcc/config/i386/sse.md |   42 ++--
 gcc/doc/invoke.texi|9 ++-
 gcc/testsuite/ChangeLog|   17 +
 .../gcc.target/i386/avx256-unaligned-load-1.c  |   19 +
 .../gcc.target/i386/avx256-unaligned-load-2.c  |   29 
 .../gcc.target/i386/avx256-unaligned-load-3.c  |   19 +
 .../gcc.target/i386/avx256-unaligned-load-4.c  |   19 +
 .../gcc.target/i386/avx256-unaligned-load-5.c  |   43 +++
 .../gcc.target/i386/avx256-unaligned-load-6.c  |   42 +++
 .../gcc.target/i386/avx256-unaligned-load-7.c  |   60 +++
 .../gcc.target/i386/avx256-unaligned-store-1.c |   22 ++
 .../gcc.target/i386/avx256-unaligned-store-2.c |   29 
 .../gcc.target/i386/avx256-unaligned-store-3.c |   22 ++
 .../gcc.target/i386/avx256-unaligned-store-4.c |   20 +
 .../gcc.target/i386/avx256-unaligned-store-5.c |   42 +++
 

Re: [pph] Rename token cache and identifiers streaming functions to reflect pph naming scheme (issue4636065)

[Gabriel Charette]

On Mon, Jun 27, 2011 at 1:40 PM,  wrote:
>
> On 2011/06/27 20:33:26, Gabriel Charette wrote:
>>
>> 2011-06-27  Gabriel Charette  
>
> Remove the 'mailto:' prefix.

Weird, that's not in the actual patch, probably gmail putting it in...

Commited as rev r175568.

Gab


>
>
>>        * pph-streamer-in.c (pph_get_type_from_index):
>>        Rename from pth_get_type_from_index. Update all users.
>>        (pph_in_number): Rename from pth_load_number.
>>        Update all users.
>>        (pph_in_token_value): Rename from pth_load_token_value. Change
>>        signature to 'pph_stream*, cp_token*' from 'cp_token*, pph_stream*'.
>>        Update all users.
>>        (pph_in_token): Rename from pth_load_token.
>>        Update all users.
>>        (pph_in_token_cache): Rename from pth_load_token_cache.
>>        Update all users.
>>        (pph_in_identifiers): Rename from pth_load_identifiers. Change
>>        signature to 'pph_stream*, cpp_idents_used*' from
>>        'cpp_idents_used*, pph_stream*'.
>>        from (cpp_idents_used*, pph_stream*).
>>        Update all users.
>>        * pph-streamer-out.c (pph_get_index_from_type):
>>        Rename from pth_get_index_from_type.
>>        Update all users.
>>        (pph_out_number): Rename from pth_write_number.
>>        Update all users.
>>        (pph_out_token_value): Rename from pth_save_token_value.
>>        Update all users.
>>        (pph_out_token): Rename from pth_save_token. Change signature to
>>        'pph_stream*, cp_token*' from 'cp_token*, pph_stream*'.
>>        Update all users.
>>        (pph_out_token_cache): Rename from pth_save_token_cache. Change
>>        signature to 'pph_stream*, cp_token_cache*'
>>        from 'cp_token_cache*, pph_stream*'.
>>        Update all users.
>>        (pph_out_identifiers): Rename from pth_save_identifiers. Change
>>        signature to 'pph_stream*, cpp_idents_used*' from
>>        'cpp_idents_used*, pph_stream*'.
>>        Update all users.
>
> OK with that change.
>
>
> Diego.
>
> http://codereview.appspot.com/4636065/

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const

[H.J. Lu]

On Mon, Jun 27, 2011 at 3:19 PM, H.J. Lu  wrote:
> On Mon, Jun 27, 2011 at 3:08 PM, Ulrich Weigand  wrote:
>> H.J. Lu wrote:
>>
>>> reload generates:
>>>
>>> (insn 914 912 0 (set (reg:SI 0 ax)
>>>         (plus:SI (subreg:SI (reg/v/f:DI 182 [ b ]) 0)
>>>             (const_int 8 [0x8]))) 248 {*lea_1_x32}
>>>      (nil))
>>>
>>> from
>>>
>>> insn = emit_insn_if_valid_for_reload (gen_rtx_SET (VOIDmode, out, in));
>>
>> Interesting.  The pseudo should have been replaced by the
>> hard register (reg:DI 1) during the preceding call to
>>      op0 = find_replacement (&XEXP (in, 0));
>> (since reload 0 should have pushed a replacement record.)
>>
>> Interestingly enough, in the final output that replacement *is*
>> performed in the REG_EQUIV note:
>>
>> (insn 1023 1022 1024 34 (set (reg:SI 1 dx)
>>        (plus:SI (reg:SI 1 dx)
>>            (const_int 8 [0x8]))) spooles.c:291 248 {*lea_1_x32}
>>     (expr_list:REG_EQUIV (plus:SI (subreg:SI (reg:DI 1 dx) 0)
>>            (const_int 8 [0x8]))
>>        (nil)))
>>
>> which is why I hadn't expected this to be a problem here.
>>
>> Can you try to find out why the find_replacement doesn't work
>> with your test case?
>>
>
> I will investigate.  Could (reg:SI 1 dx) vs  (subreg:SI (reg:DI 1 dx) 0)
> a problem?
>

find_replacement never checks subreg:

Breakpoint 3, find_replacement (loc=0x7068ab00)
at /export/gnu/import/git/gcc-x32/gcc/reload.c:6411
6411  if (reloadreg && r->where == loc)
(reg:DI 0 ax)
(reg/v/f:DI 182 [ b ])
(gdb) call debug_rtx (*loc)
(subreg:SI (reg/v/f:DI 182 [ b ]) 0)
(gdb)


-- 
H.J.

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const

[H.J. Lu]

On Mon, Jun 27, 2011 at 3:08 PM, Ulrich Weigand  wrote:
> H.J. Lu wrote:
>
>> reload generates:
>>
>> (insn 914 912 0 (set (reg:SI 0 ax)
>>         (plus:SI (subreg:SI (reg/v/f:DI 182 [ b ]) 0)
>>             (const_int 8 [0x8]))) 248 {*lea_1_x32}
>>      (nil))
>>
>> from
>>
>> insn = emit_insn_if_valid_for_reload (gen_rtx_SET (VOIDmode, out, in));
>
> Interesting.  The pseudo should have been replaced by the
> hard register (reg:DI 1) during the preceding call to
>      op0 = find_replacement (&XEXP (in, 0));
> (since reload 0 should have pushed a replacement record.)
>
> Interestingly enough, in the final output that replacement *is*
> performed in the REG_EQUIV note:
>
> (insn 1023 1022 1024 34 (set (reg:SI 1 dx)
>        (plus:SI (reg:SI 1 dx)
>            (const_int 8 [0x8]))) spooles.c:291 248 {*lea_1_x32}
>     (expr_list:REG_EQUIV (plus:SI (subreg:SI (reg:DI 1 dx) 0)
>            (const_int 8 [0x8]))
>        (nil)))
>
> which is why I hadn't expected this to be a problem here.
>
> Can you try to find out why the find_replacement doesn't work
> with your test case?
>

I will investigate.  Could (reg:SI 1 dx) vs  (subreg:SI (reg:DI 1 dx) 0)
a problem?


-- 
H.J.

[patch, fortran] Fix PR 49479, reshape with optional arg

[Thomas Koenig]

Hello world,

the attached patch fixes PR 49479, a regression for 4.7 and 4.6.  Test
case was supplied by Joost, the approach to the patch was suggested by
Tobias in comment#4 of the PR.  The patch certainly looks safe enough.

Regression-tested.  OK for trunk and, after a couple of days, for 4.6?

Thomas

 2011-06-27  Thomas Koenig  

PR fortran/49479
* m4/reshape.m4: If source allocation is smaller than one, set it
to one.
* generated/reshape_r16.c: Regenerated.
* generated/reshape_c4.c: Regenerated.
* generated/reshape_c16.c: Regenerated.
* generated/reshape_c8.c: Regenerated.
* generated/reshape_r4.c: Regenerated.
* generated/reshape_i4.c: Regenerated.
* generated/reshape_r10.c: Regenerated.
* generated/reshape_r8.c: Regenerated.
* generated/reshape_c10.c: Regenerated.
* generated/reshape_i8.c: Regenerated.
* generated/reshape_i16.c: Regenerated.

2011-06-27  Thomas Koenig  

PR fortran/49479
* gfortran.dg/reshape_zerosize_3.f90:  New test.
Index: m4/reshape.m4
===
--- m4/reshape.m4	(Revision 175543)
+++ m4/reshape.m4	(Arbeitskopie)
@@ -101,6 +101,8 @@
 
   if (ret->data == NULL)
 {
+  index_type alloc_size;
+
   rs = 1;
   for (n = 0; n < rdim; n++)
 	{
@@ -111,7 +113,13 @@
 	  rs *= rex;
 	}
   ret->offset = 0;
-  ret->data = internal_malloc_size ( rs * sizeof ('rtype_name`));
+
+  if (unlikely (rs < 1))
+alloc_size = 1;
+  else
+alloc_size = rs * sizeof ('rtype_name`);
+
+  ret->data = internal_malloc_size (alloc_size);
   ret->dtype = (source->dtype & ~GFC_DTYPE_RANK_MASK) | rdim;
 }
 
! { dg-do run }
! PR 49479 - this used not to print anything.
! Test case by Joost VandeVondele.
MODULE M1
  IMPLICIT NONE
CONTAINS
SUBROUTINE S1(data)
INTEGER, DIMENSION(:), INTENT(IN), &
  OPTIONAL   :: DATA
character(20) :: line
IF (.not. PRESENT(data)) call abort
write (unit=line,fmt='(I5)') size(data)
if (line /= '0   ') call abort
END SUBROUTINE

SUBROUTINE S2(N)
INTEGER :: N
INTEGER, ALLOCATABLE, DIMENSION(:, :):: blki
ALLOCATE(blki(3,N))
blki=0
CALL S1(RESHAPE(blki,(/3*N/)))
END SUBROUTINE S2
END MODULE M1

USE M1
CALL S2(0)
END
! { dg-final { cleanup-modules "m1" } }

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const

[Ulrich Weigand]

H.J. Lu wrote:

> reload generates:
> 
> (insn 914 912 0 (set (reg:SI 0 ax)
> (plus:SI (subreg:SI (reg/v/f:DI 182 [ b ]) 0)
> (const_int 8 [0x8]))) 248 {*lea_1_x32}
>  (nil))
> 
> from
> 
> insn = emit_insn_if_valid_for_reload (gen_rtx_SET (VOIDmode, out, in));

Interesting.  The pseudo should have been replaced by the
hard register (reg:DI 1) during the preceding call to
  op0 = find_replacement (&XEXP (in, 0));
(since reload 0 should have pushed a replacement record.)

Interestingly enough, in the final output that replacement *is*
performed in the REG_EQUIV note:

(insn 1023 1022 1024 34 (set (reg:SI 1 dx)
(plus:SI (reg:SI 1 dx)
(const_int 8 [0x8]))) spooles.c:291 248 {*lea_1_x32}
 (expr_list:REG_EQUIV (plus:SI (subreg:SI (reg:DI 1 dx) 0)
(const_int 8 [0x8]))
(nil)))

which is why I hadn't expected this to be a problem here.

Can you try to find out why the find_replacement doesn't work
with your test case?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Add Gabriel Charette to Write After Approval list (issue4626079)

[Gabriel Charette]

Added myself to write after approval maintainers list.

2011-06-27  Gabriel Charette  

* MAINTAINERS (Write After Approval): Add myself.

diff --git a/MAINTAINERS b/MAINTAINERS
index 9dead4f..f6a768e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -324,6 +324,7 @@ Christian Bruel 
christian.br...@st.com
 Kevin Buettner kev...@redhat.com
 Andrew Cagney  cag...@redhat.com
 Stephane Carrezstcar...@nerim.fr
+Gabriel Charette   gch...@google.com
 Chandra Chavva ccha...@redhat.com
 Fabien Chêne   fab...@gcc.gnu.org
 William Cohen  wco...@redhat.com

--
This patch is available for review at http://codereview.appspot.com/4626079

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const

[H.J. Lu]

On Mon, Jun 27, 2011 at 1:42 PM, H.J. Lu  wrote:
> On Mon, Jun 27, 2011 at 11:59 AM, Ulrich Weigand  wrote:
>> H.J. Lu wrote:
>>
>>> Reloads for insn # 588
>>> Reload 0: reload_in (DI) =3D (reg/v/f:DI 182 [ b ])
>>>         GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum =3D 0)
>>>         reload_in_reg: (reg/v/f:DI 182 [ b ])
>>>         reload_reg_rtx: (reg:DI 1 dx)
>>> Reload 1: reload_in (DI) =3D (zero_extend:DI (plus:SI (subreg:SI (reg/v/f:D=
>>> I 182
>>> [ b ]) 0)
>>>                                                         (const_int 8 [0x8])=
>>> ))
>>>         GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum =3D 0)
>>>         reload_in_reg: (zero_extend:DI (plus:SI (subreg:SI (reg/v/f:DI 182 =
>>> [ b
>>> ]) 0)
>>>                                                         (const_int 8 [0x8])=
>>> ))
>>>         reload_reg_rtx: (reg:DI 1 dx)
>>> Reload 2: reload_out (DF) =3D (mem:DF (zero_extend:DI (plus:SI (subreg:SI
>>> (reg/v/f:DI 182 [ b ]) 0)
>>>                                                             (const_int 8
>>> [0x8]))) [4 MEM[base: b_96(D), index: D.15020_278, step: 8, offset: 0B]+0 S8
>>> A64])
>>>         NO_REGS, RELOAD_FOR_OUTPUT (opnum =3D 0), optional
>>>         reload_out_reg: (mem:DF (zero_extend:DI (plus:SI (subreg:SI (reg/v/=
>>> f:DI
>>> 182 [ b ]) 0)
>>>                                                             (const_int 8
>>> [0x8]))) [4 MEM[base: b_96(D), index: D.15020_278, step: 8, offset: 0B]+0 S8
>>> A64])
>>>
>>> leads to
>>>
>>
>>> (insn 1017 587 1020 34 (set (reg:DI 1 dx)
>>>         (mem/c:DI (plus:DI (reg/f:DI 7 sp)
>>>                 (const_int 112 [0x70])) [5 %sfp+-208 S8 A64])) spooles.c:29=
>>> 1 62
>>> {*movdi_internal_rex64}
>>>      (nil))
>>
>> So this is the reload insn generated from reload 0.  So far so good.
>>
>>> (insn 1020 1017 1022 34 (set (reg:SI 1 dx)
>>>         (const_int 8 [0x8])) spooles.c:291 64 {*movsi_internal}
>>>      (nil))
>>>
>>> (insn 1022 1020 1023 34 (set (reg:SI 1 dx)
>>>         (reg:SI 1 dx)) spooles.c:291 64 {*movsi_internal}
>>>      (nil))
>>>
>>> (insn 1023 1022 1024 34 (set (reg:SI 1 dx)
>>>         (plus:SI (reg:SI 1 dx)
>>>             (const_int 8 [0x8]))) spooles.c:291 248 {*lea_1_x32}
>>>      (expr_list:REG_EQUIV (plus:SI (subreg:SI (reg:DI 1 dx) 0)
>>>             (const_int 8 [0x8]))
>>>         (nil)))
>>>
>>> (insn 1024 1023 588 34 (set (reg:DI 1 dx)
>>>         (zero_extend:DI (reg:SI 1 dx))) spooles.c:291 112
>>> {*zero_extendsidi2_rex64}
>>>      (expr_list:REG_EQUIV (zero_extend:DI (plus:SI (subreg:SI (reg:DI 1 dx)=
>>>  0)
>>>                 (const_int 8 [0x8])))
>>>         (nil)))
>>
>> All these reload insns are generated from reload 1.
>>
>>> (insn 588 1024 589 34 (set (mem:DF (reg:DI 1 dx) [4 MEM[base: b_96(D), inde=
>>> x:
>>> D.15020_278, step: 8, offset: 0B]+0 S8 A64])
>>>         (reg:DF 0 ax [orig:340 D.14980 ] [340])) spooles.c:291 106
>>> {*movdf_internal_rex64}
>>>      (nil))
>>
>> This is the original reloaded insn.
>>
>>> Reload 0 puts (reg/v/f:DI 182 [ b ]) in  (reg:DI 1 dx) for input.
>>> However, reload 2
>>> puts (reg/v/f:DI 182 [ b ]) in  (reg:DI 1 dx) for output.without checking w=
>>> hat
>>> reload 0 did.
>>
>> Reload 2 is an optional reload which reload chose not to utilize, so this
>> is not really relevant here in any case.  There is no output reload.
>>
>> The wrong code above originates from how reload 1 is handled:
>>
>> gen_reload is called to load the ZERO_EXTEND into (reg:DI 1).  This triggers
>> the "unary predicate" path, which recurses into gen_reload to load the 
>> operand
>> of the ZERO_EXTEND (reg:SI 1), and subsequently generates insn 1024.
>>
>> The recursive call loads (plus:SI (subreg:SI (reg:DI 1)) (const_int 8)) into
>> (reg:SI 1).  It attempts to do that in a single SET and fails (for some
>> reason).  It then attempts to load the constant (const_int 8) into the
>> destination register (insn 1020) [** which is broken **], and re-tries.
>> This still fails, so it falls through to the last attempt, which is to
>> instead copy the subreg to the destination (which results in insn 1022
>> as the subreg is optimized away at this point), followed by adding the
>> constant.
>>
>> Note that the point marked with "[** which is broken **]" is the place
>> I pointed out in the previous mail.
>>
>
> reload generates:
>
> (insn 914 912 0 (set (reg:SI 0 ax)
>        (plus:SI (subreg:SI (reg/v/f:DI 182 [ b ]) 0)
>            (const_int 8 [0x8]))) 248 {*lea_1_x32}
>     (nil))
>
> from
>
> insn = emit_insn_if_valid_for_reload (gen_rtx_SET (VOIDmode, out, in));
>
> Since (reg/v/f:DI 182 [ b ]) is a pseudo register, it is
> rejected by
>
>      if ((strict && ! REG_OK_FOR_BASE_STRICT_P (reg))
>          || (! strict && ! REG_OK_FOR_BASE_NONSTRICT_P (reg)))
>        /* Base is not valid.  */
>        return false;
>
> in ix86_legitimate_address_p.
>

Even if I added

+;; Use by reload
+(define_insn "*lea_0_x32"
+  [(set (match_operand:SI 0 "register_operand" "=r")
+  (plus:

Re: Fix cgraph_address_taken_from_non_vtable_p

[Richard Guenther]

On Mon, 27 Jun 2011, Jan Hubicka wrote:

> Hi,
> this patch fixes thinko in cgraph_address_taken_from_non_vtable_p that valks
> references in NODE instead of references of NODE.
> It fixes the testcase in http://sourceware.org/bugzilla/show_bug.cgi?id=12942
> in non-plugin LTO and Gold, but not with GNU LD that presently handle 
> resolution
> info incorrectly for comdats.
> 
> Dave, do you think you could fix the GNU LD issue?
> 
> Once fixed, I wonder if I should not add the testcase as
> lto/broken_comdat_in_gnu_ld.c or something similar like we have testcases for
> glibc/mpfr bugs?

I think you should add that now (given you have it).

Richard.

> Bootstrapped/regtested x86_64-linux, comitted.
> 
> Index: ChangeLog
> ===
> --- ChangeLog (revision 175554)
> +++ ChangeLog (working copy)
> @@ -1,3 +1,8 @@
> +2011-06-27  Jan Hubicka  
> +
> + * ipa.c (cgraph_address_taken_from_non_vtable_p): Walk references of 
> node
> + instead of references in node.
> +
>  2011-06-27  Richard Henderson  
>  
>   * config/alpha/alpha.c (vms_patch_builtins): Provide dummy definition.
> Index: ipa.c
> ===
> --- ipa.c (revision 175554)
> +++ ipa.c (working copy)
> @@ -542,13 +542,13 @@ cgraph_address_taken_from_non_vtable_p (
>  {
>int i;
>struct ipa_ref *ref;
> -  for (i = 0; ipa_ref_list_reference_iterate (&node->ref_list, i, ref); i++)
> +  for (i = 0; ipa_ref_list_refering_iterate (&node->ref_list, i, ref); i++)
>  if (ref->use == IPA_REF_ADDR)
>{
>   struct varpool_node *node;
> - if (ref->refered_type == IPA_REF_CGRAPH)
> + if (ref->refering_type == IPA_REF_CGRAPH)
> return true;
> - node = ipa_ref_varpool_node (ref);
> + node = ipa_ref_refering_varpool_node (ref);
>   if (!DECL_VIRTUAL_P (node->decl))
> return true;
>}
> 
> 

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

Re: [PATCH][RFC][2/2] Bitfield lowering

[Richard Guenther]

On Mon, 27 Jun 2011, Richard Henderson wrote:

> On 06/23/2011 02:49 AM, Richard Guenther wrote:
> > So, do you know of a target that can do insv with a memory
> > target?  I would expect extv on memory to be easily doable.
> 
> Depends on what you mean by that.  INSV is the traditional
> md pattern that performs unaligned stores.  So, many targets
> can handle a memory destination of some sort

Hm, the code that seems to deal with HAVE_insv seems to be indeed
generic (via store_bit_field).  But that would only mean that
lowering bitfields should be considered in the context of lowering
unaligned accesses (on targets that require that).

> Many many less would handle memory if we completed the 
> transition of unaligned memory load/store to movmisalign.
> But at present movmisalign is only defined for vector modes.

I think the ideal point would be when movmisaling would only
expand to native unaligned load single instructions.  Multiple
instruction sequences should be exposed at a (lowered) gimple
level.

Now the question is if there is a useful intermediate step
to that ideal result.  That is, if we transition memory
BIT_FIELD_REFs to a mode-size load and a register bit extract
we can for the purpose of expansion easily present that as
bit extract on a memory operand.  Similar for a store from
a BIT_FIELD_COMPOSE_EXPR.

So that definitely points in favor of using BIT_FIELD_*
for the lowering instead of decomposing those to shifts
and bitwise operations.

Richard.

Re: [RFA:] Removing target-libiberty on branches

[Hans-Peter Nilsson]

> Date: Fri, 24 Jun 2011 10:14:13 +0200
> From: Richard Guenther 

> On Thu, Jun 23, 2011 at 8:23 PM, Hans-Peter Nilsson
>  wrote:
> > Here's the patch I tested for 4.6, native
> > x86_64-unknown-linux-gnu, cross to cris-axis-elf, both with old
> > and new ("breaking") newlib.
> >
> > Ok for 4.6 and after testing, earlier branches?
> 
> Ok for 4.6.2 and 4.5.

The patch didn't apply cleanly to 4.5 so for the record here's
the adjusted variant I just committed, and also the
target-specific bits I instead committed to 4.4, noting that
skipdirs is the preferable variable to set for silent skipping.
Hours too late for the now-closed-and-final-released 4.3, alas.

4.4:
* configure.ac (cris-*-* | crisv32-*-*, mmix-*-*): Add
target-libiberty to skipdirs.
* configure: Regenerate.

Index: configure.ac
===
--- configure.ac(revision 175397)
+++ configure.ac(working copy)
@@ -612,6 +612,7 @@ case "${target}" in
 ;;
   cris-*-* | crisv32-*-*)
 unsupported_languages="$unsupported_languages java"
+skipdirs="$skipdirs target-libiberty"
 case "${target}" in
   *-*-aout)
unsupported_languages="$unsupported_languages fortran"
@@ -783,6 +784,7 @@ case "${target}" in
 noconfigdirs="$noconfigdirs target-libstdc++-v3"
 ;;
   mmix-*-*)
+skipdirs="$skipdirs target-libiberty"
 noconfigdirs="$noconfigdirs target-libffi target-boehm-gc gdb libgloss"
 unsupported_languages="$unsupported_languages fortran java"
 ;;

4.5:
PR regression/47836
PR bootstrap/23656
PR other/47733
PR bootstrap/49247
PR c/48825
* configure.ac (target_libraries): Remove target-libiberty.
Remove all target-specific settings adding target-libiberty to
skipdirs and noconfigdirs.  Remove checking target_configdirs
and removing target-libiberty but keeping target-libgcc if
otherwise empty.
* Makefile.def (target_modules): Don't add libiberty.
(dependencies): Remove all traces of target-libiberty.
* configure, Makefile.in: Regenerate.

Index: configure.ac
===
--- configure.ac(revision 175382)
+++ configure.ac(working copy)
@@ -185,9 +185,8 @@ libgcj="target-libffi \
 
 # these libraries are built for the target environment, and are built after
 # the host libraries and the host tools (which may be a cross compiler)
-#
+# Note that libiberty is not a target library.
 target_libraries="target-libgcc \
-   target-libiberty \
target-libgloss \
target-newlib \
target-libgomp \
@@ -506,14 +505,14 @@ case "${target}" in
 ;;
   *-*-kaos*)
 # Remove unsupported stuff on all kaOS configurations.
-skipdirs="target-libiberty ${libgcj} target-libstdc++-v3 target-librx"
+skipdirs="${libgcj} target-libstdc++-v3 target-librx"
 skipdirs="$skipdirs target-libobjc target-examples target-groff 
target-gperf"
 skipdirs="$skipdirs zlib fastjar target-libjava target-boehm-gc 
target-zlib"
 noconfigdirs="$noconfigdirs target-libgloss"
 ;;
   *-*-netbsd*)
 # Skip some stuff on all NetBSD configurations.
-noconfigdirs="$noconfigdirs target-newlib target-libiberty target-libgloss"
+noconfigdirs="$noconfigdirs target-newlib target-libgloss"
 
 # Skip some stuff that's unsupported on some NetBSD configurations.
 case "${target}" in
@@ -525,20 +524,20 @@ case "${target}" in
 esac
 ;;
   *-*-netware*)
-noconfigdirs="$noconfigdirs target-newlib target-libiberty target-libgloss 
${libgcj} target-libmudflap"
+noconfigdirs="$noconfigdirs target-newlib target-libgloss ${libgcj} 
target-libmudflap"
 ;;
   *-*-rtems*)
 noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
 ;;
 # The tpf target doesn't support gdb yet.
   *-*-tpf*)
-noconfigdirs="$noconfigdirs target-newlib target-libgloss target-libiberty 
${libgcj} target-libmudflap gdb tcl tk libgui itcl"
+noconfigdirs="$noconfigdirs target-newlib target-libgloss ${libgcj} 
target-libmudflap gdb tcl tk libgui itcl"
 ;;
   *-*-uclinux*)
 noconfigdirs="$noconfigdirs target-newlib target-libgloss target-rda 
${libgcj}"
 ;;
   *-*-vxworks*)
-noconfigdirs="$noconfigdirs target-newlib target-libgloss target-libiberty 
target-libstdc++-v3 ${libgcj}"
+noconfigdirs="$noconfigdirs target-newlib target-libgloss 
target-libstdc++-v3 ${libgcj}"
 ;;
   alpha*-dec-osf*)
 # ld works, but does not support shared libraries.
@@ -566,7 +565,7 @@ case "${target}" in
   sh*-*-pe|mips*-*-pe|*arm-wince-pe)
 noconfigdirs="$noconfigdirs ${libgcj}"
 noconfigdirs="$noconfigdirs target-examples"
-noconfigdirs="$noconfigdirs target-libiberty texinfo send-pr"
+noconfigdirs="$noconfigdirs texinfo send-pr"
 noconfigdirs="$noconfigdirs tcl tk itcl libgui s

Re: [PATCH 0/4] Docs: extend.texi

[Michael Witten]

On Thu, Apr 28, 2011 at 01:20, Michael Witten  wrote:

> See the following emails for a few inlined patches
> to /trunk/gcc/doc/extend.texi (revision 172911):
>
>  [1] Docs: extend.texi: Add missing semicolon for consistency
>  [2] Docs: extend.texi: Remove trailing blanks from lines
>  [3] Docs: extend.texi: Rearrange nodes; no text was removed or added
>  [4] Docs: extend.texi: Reword and rearrange attribute node introductions
>
>  trunk/gcc/doc/extend.texi | 5449 
> +++--
>  1 files changed, 2730 insertions(+), 2719 deletions(-)
>
> CHANGELOG
>
> Essentially, I think it would be easiest to squash all of these patches
> together into one revision; here is a ChangeLog entry for such a revision:
>
> 2011-04-27  Michael Witten 
>
>* gcc/doc/extend.texi: Add a `;', remove trailing whitespace,
>and reorganize nodes to group the discussion of attributes more
>logically.
>
> --
> 1.7.4.18.g68fe8

Please commit these patches, starting here:

 http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02175.html
 Message-ID: <378e16b9-5d40-427c-8b4e-00700b2ad30c-mfwit...@gmail.com

Sincerely,
Michael Witten

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const

[H.J. Lu]

On Mon, Jun 27, 2011 at 11:59 AM, Ulrich Weigand  wrote:
> H.J. Lu wrote:
>
>> Reloads for insn # 588
>> Reload 0: reload_in (DI) =3D (reg/v/f:DI 182 [ b ])
>>         GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum =3D 0)
>>         reload_in_reg: (reg/v/f:DI 182 [ b ])
>>         reload_reg_rtx: (reg:DI 1 dx)
>> Reload 1: reload_in (DI) =3D (zero_extend:DI (plus:SI (subreg:SI (reg/v/f:D=
>> I 182
>> [ b ]) 0)
>>                                                         (const_int 8 [0x8])=
>> ))
>>         GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum =3D 0)
>>         reload_in_reg: (zero_extend:DI (plus:SI (subreg:SI (reg/v/f:DI 182 =
>> [ b
>> ]) 0)
>>                                                         (const_int 8 [0x8])=
>> ))
>>         reload_reg_rtx: (reg:DI 1 dx)
>> Reload 2: reload_out (DF) =3D (mem:DF (zero_extend:DI (plus:SI (subreg:SI
>> (reg/v/f:DI 182 [ b ]) 0)
>>                                                             (const_int 8
>> [0x8]))) [4 MEM[base: b_96(D), index: D.15020_278, step: 8, offset: 0B]+0 S8
>> A64])
>>         NO_REGS, RELOAD_FOR_OUTPUT (opnum =3D 0), optional
>>         reload_out_reg: (mem:DF (zero_extend:DI (plus:SI (subreg:SI (reg/v/=
>> f:DI
>> 182 [ b ]) 0)
>>                                                             (const_int 8
>> [0x8]))) [4 MEM[base: b_96(D), index: D.15020_278, step: 8, offset: 0B]+0 S8
>> A64])
>>
>> leads to
>>
>
>> (insn 1017 587 1020 34 (set (reg:DI 1 dx)
>>         (mem/c:DI (plus:DI (reg/f:DI 7 sp)
>>                 (const_int 112 [0x70])) [5 %sfp+-208 S8 A64])) spooles.c:29=
>> 1 62
>> {*movdi_internal_rex64}
>>      (nil))
>
> So this is the reload insn generated from reload 0.  So far so good.
>
>> (insn 1020 1017 1022 34 (set (reg:SI 1 dx)
>>         (const_int 8 [0x8])) spooles.c:291 64 {*movsi_internal}
>>      (nil))
>>
>> (insn 1022 1020 1023 34 (set (reg:SI 1 dx)
>>         (reg:SI 1 dx)) spooles.c:291 64 {*movsi_internal}
>>      (nil))
>>
>> (insn 1023 1022 1024 34 (set (reg:SI 1 dx)
>>         (plus:SI (reg:SI 1 dx)
>>             (const_int 8 [0x8]))) spooles.c:291 248 {*lea_1_x32}
>>      (expr_list:REG_EQUIV (plus:SI (subreg:SI (reg:DI 1 dx) 0)
>>             (const_int 8 [0x8]))
>>         (nil)))
>>
>> (insn 1024 1023 588 34 (set (reg:DI 1 dx)
>>         (zero_extend:DI (reg:SI 1 dx))) spooles.c:291 112
>> {*zero_extendsidi2_rex64}
>>      (expr_list:REG_EQUIV (zero_extend:DI (plus:SI (subreg:SI (reg:DI 1 dx)=
>>  0)
>>                 (const_int 8 [0x8])))
>>         (nil)))
>
> All these reload insns are generated from reload 1.
>
>> (insn 588 1024 589 34 (set (mem:DF (reg:DI 1 dx) [4 MEM[base: b_96(D), inde=
>> x:
>> D.15020_278, step: 8, offset: 0B]+0 S8 A64])
>>         (reg:DF 0 ax [orig:340 D.14980 ] [340])) spooles.c:291 106
>> {*movdf_internal_rex64}
>>      (nil))
>
> This is the original reloaded insn.
>
>> Reload 0 puts (reg/v/f:DI 182 [ b ]) in  (reg:DI 1 dx) for input.
>> However, reload 2
>> puts (reg/v/f:DI 182 [ b ]) in  (reg:DI 1 dx) for output.without checking w=
>> hat
>> reload 0 did.
>
> Reload 2 is an optional reload which reload chose not to utilize, so this
> is not really relevant here in any case.  There is no output reload.
>
> The wrong code above originates from how reload 1 is handled:
>
> gen_reload is called to load the ZERO_EXTEND into (reg:DI 1).  This triggers
> the "unary predicate" path, which recurses into gen_reload to load the operand
> of the ZERO_EXTEND (reg:SI 1), and subsequently generates insn 1024.
>
> The recursive call loads (plus:SI (subreg:SI (reg:DI 1)) (const_int 8)) into
> (reg:SI 1).  It attempts to do that in a single SET and fails (for some
> reason).  It then attempts to load the constant (const_int 8) into the
> destination register (insn 1020) [** which is broken **], and re-tries.
> This still fails, so it falls through to the last attempt, which is to
> instead copy the subreg to the destination (which results in insn 1022
> as the subreg is optimized away at this point), followed by adding the
> constant.
>
> Note that the point marked with "[** which is broken **]" is the place
> I pointed out in the previous mail.
>

reload generates:

(insn 914 912 0 (set (reg:SI 0 ax)
(plus:SI (subreg:SI (reg/v/f:DI 182 [ b ]) 0)
(const_int 8 [0x8]))) 248 {*lea_1_x32}
 (nil))

from

insn = emit_insn_if_valid_for_reload (gen_rtx_SET (VOIDmode, out, in));

Since (reg/v/f:DI 182 [ b ]) is a pseudo register, it is
rejected by

  if ((strict && ! REG_OK_FOR_BASE_STRICT_P (reg))
  || (! strict && ! REG_OK_FOR_BASE_NONSTRICT_P (reg)))
/* Base is not valid.  */
return false;

in ix86_legitimate_address_p.

-- 
H.J.

Re: [pph] Rename token cache and identifiers streaming functions to reflect pph naming scheme (issue4636065)

[dnovillo]

On 2011/06/27 20:33:26, Gabriel Charette wrote:

2011-06-27  Gabriel Charette  


Remove the 'mailto:' prefix.



* pph-streamer-in.c (pph_get_type_from_index):
Rename from pth_get_type_from_index. Update all users.
(pph_in_number): Rename from pth_load_number.
Update all users.
(pph_in_token_value): Rename from pth_load_token_value. Change
signature to 'pph_stream*, cp_token*' from 'cp_token*, pph_stream*'.
Update all users.
(pph_in_token): Rename from pth_load_token.
Update all users.
(pph_in_token_cache): Rename from pth_load_token_cache.
Update all users.
(pph_in_identifiers): Rename from pth_load_identifiers. Change
signature to 'pph_stream*, cpp_idents_used*' from
'cpp_idents_used*, pph_stream*'.
from (cpp_idents_used*, pph_stream*).
Update all users.
* pph-streamer-out.c (pph_get_index_from_type):
Rename from pth_get_index_from_type.
Update all users.
(pph_out_number): Rename from pth_write_number.
Update all users.
(pph_out_token_value): Rename from pth_save_token_value.
Update all users.
(pph_out_token): Rename from pth_save_token. Change signature to
'pph_stream*, cp_token*' from 'cp_token*, pph_stream*'.
Update all users.
(pph_out_token_cache): Rename from pth_save_token_cache. Change
signature to 'pph_stream*, cp_token_cache*'
from 'cp_token_cache*, pph_stream*'.
Update all users.
(pph_out_identifiers): Rename from pth_save_identifiers. Change
signature to 'pph_stream*, cpp_idents_used*' from
'cpp_idents_used*, pph_stream*'.
Update all users.


OK with that change.


Diego.

http://codereview.appspot.com/4636065/

[pph] Rename token cache and identifiers streaming functions to reflect pph naming scheme (issue4636065)

[Gabriel Charette]

Renamed all functions to reflect pph naming schemes (pph_in/out_*).

Also reordered parameters so that the first parameter is always pph_stream*

Tested with bootstrap and pph regression testing.

2011-06-27  Gabriel Charette  

* pph-streamer-in.c (pph_get_type_from_index):
Rename from pth_get_type_from_index. Update all users.
(pph_in_number): Rename from pth_load_number.
Update all users.
(pph_in_token_value): Rename from pth_load_token_value. Change
signature to 'pph_stream*, cp_token*' from 'cp_token*, pph_stream*'.
Update all users.
(pph_in_token): Rename from pth_load_token.
Update all users.
(pph_in_token_cache): Rename from pth_load_token_cache.
Update all users.
(pph_in_identifiers): Rename from pth_load_identifiers. Change
signature to 'pph_stream*, cpp_idents_used*' from
'cpp_idents_used*, pph_stream*'.
from (cpp_idents_used*, pph_stream*).
Update all users.
* pph-streamer-out.c (pph_get_index_from_type):
Rename from pth_get_index_from_type.
Update all users.
(pph_out_number): Rename from pth_write_number.
Update all users.
(pph_out_token_value): Rename from pth_save_token_value.
Update all users.
(pph_out_token): Rename from pth_save_token. Change signature to
'pph_stream*, cp_token*' from 'cp_token*, pph_stream*'.
Update all users.
(pph_out_token_cache): Rename from pth_save_token_cache. Change
signature to 'pph_stream*, cp_token_cache*'
from 'cp_token_cache*, pph_stream*'.
Update all users.
(pph_out_identifiers): Rename from pth_save_identifiers. Change
signature to 'pph_stream*, cpp_idents_used*' from
'cpp_idents_used*, pph_stream*'.
Update all users.

diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
index 6743c3c..93b5685 100644
--- a/gcc/cp/pph-streamer-in.c
+++ b/gcc/cp/pph-streamer-in.c
@@ -246,7 +246,7 @@ pph_register_shared_data (pph_stream *stream, void *data, 
unsigned ix)
return a type from integer_types or global_trees.  */
 
 static tree
-pth_get_type_from_index (unsigned type_idx, unsigned type_kind)
+pph_get_type_from_index (unsigned type_idx, unsigned type_kind)
 {
   if (type_kind == CPP_N_INTEGER)
 return integer_types[type_idx];
@@ -266,7 +266,7 @@ pth_get_type_from_index (unsigned type_idx, unsigned 
type_kind)
 /* Load a numeric value from file F.  Return the corresponding tree.  */
 
 static tree
-pth_load_number (pph_stream *f)
+pph_in_number (pph_stream *f)
 {
   unsigned type_idx, type_kind;
   tree type, val;
@@ -274,7 +274,7 @@ pth_load_number (pph_stream *f)
   type_idx = pph_in_uint (f);
   type_kind = pph_in_uint (f);
 
-  type = pth_get_type_from_index (type_idx, type_kind);
+  type = pph_get_type_from_index (type_idx, type_kind);
 
   if (type_kind == CPP_N_INTEGER)
 {
@@ -296,8 +296,8 @@ pth_load_number (pph_stream *f)
 }
   else if (type_kind == CPP_N_IMAGINARY)
 {
-  tree r = pth_load_number (f);
-  tree i = pth_load_number (f);
+  tree r = pph_in_number (f);
+  tree i = pph_in_number (f);
   val = build_complex (NULL_TREE, r, i);
 }
   else
@@ -310,7 +310,7 @@ pth_load_number (pph_stream *f)
 /* Load the tree value associated with TOKEN to file F.  */
 
 static void
-pth_load_token_value (cp_token *token, pph_stream *f)
+pph_in_token_value (pph_stream *f, cp_token *token)
 {
   const char *str;
 
@@ -334,7 +334,7 @@ pth_load_token_value (cp_token *token, pph_stream *f)
   case CPP_CHAR16:
   case CPP_CHAR32:
   case CPP_NUMBER:
-   token->u.value = pth_load_number (f);
+   token->u.value = pph_in_number (f);
break;
 
   case CPP_STRING:
@@ -359,7 +359,7 @@ pth_load_token_value (cp_token *token, pph_stream *f)
 /* Read and return a token from STREAM.  */
 
 static cp_token *
-pth_load_token (pph_stream *stream)
+pph_in_token (pph_stream *stream)
 {
   cp_token *token = ggc_alloc_cleared_cp_token ();
 
@@ -373,8 +373,8 @@ pth_load_token (pph_stream *stream)
  confusing the rest of the compiler for now.  */
   token->location = input_location;
 
-  /* FIXME pph: verify that pth_load_token_value works with no tokens.  */
-  pth_load_token_value (token, stream);
+  /* FIXME pph: verify that pph_in_token_value works with no tokens.  */
+  pph_in_token_value (stream, token);
 
   return token;
 }
@@ -383,7 +383,7 @@ pth_load_token (pph_stream *stream)
 /* Read and return a cp_token_cache instance from STREAM.  */
 
 static cp_token_cache *
-pth_load_token_cache (pph_stream *stream)
+pph_in_token_cache (pph_stream *stream)
 {
   unsigned i, num;
   cp_token *first, *last;
@@ -391,7 +391,7 @@ pth_load_token_cache (pph_stream *stream)
   num = pph_in_uint (stream);
   for (last = first = NULL, i = 0; i < num; i++)
 {
-  last = pth_load_token (stream);
+  last = pph_in_token (stream);
   if 

Re: [pph] Moved token cache streaming to in/out respectively (issue4635073)

[Diego Novillo]

On Mon, Jun 27, 2011 at 15:32,   wrote:
> On 2011/06/27 18:51:22, Gabriel Charette wrote:
>
>> 2011-06-27  Gabriel Charette  
>
>>        * pph-streamer-in.c (pth_get_type_from_index): Moved from pph.c.
>>        (pth_load_number): Moved from pph.c.
>>        (pth_load_token_value): Moved from pph.c.
>>        (pth_load_token): Moved from pph.c.
>>        (pth_load_token_cache): Moved from pph.c. Made static.
>>        * pph-streamer-out.c (pth_get_index_from_type): Moved from pph.c.
>>        (pth_write_number): Moved from pph.c.
>>        (pth_save_token_value): Moved from pph.c.
>>        (pth_save_token): Moved from pph.c.
>>        (pth_save_token_cache): Moved from pph.c. Made static.
>>        * pph-streamer.h (struct cp_token_cache):
>>        Not declared in pph.c, but in parser.h, removed.
>>        (pth_save_token_cache): Now static, removed.
>>        (pth_load_token_cache): Now static, removed.
>
> OK.  Will apply shortly.

Done.


Diego.

New German PO file for 'gcc' (version 4.6.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-4.6.0.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Fix cgraph_address_taken_from_non_vtable_p

[Jan Hubicka]

Hi,
this patch fixes thinko in cgraph_address_taken_from_non_vtable_p that valks
references in NODE instead of references of NODE.
It fixes the testcase in http://sourceware.org/bugzilla/show_bug.cgi?id=12942
in non-plugin LTO and Gold, but not with GNU LD that presently handle resolution
info incorrectly for comdats.

Dave, do you think you could fix the GNU LD issue?

Once fixed, I wonder if I should not add the testcase as
lto/broken_comdat_in_gnu_ld.c or something similar like we have testcases for
glibc/mpfr bugs?

Bootstrapped/regtested x86_64-linux, comitted.

Index: ChangeLog
===
--- ChangeLog   (revision 175554)
+++ ChangeLog   (working copy)
@@ -1,3 +1,8 @@
+2011-06-27  Jan Hubicka  
+
+   * ipa.c (cgraph_address_taken_from_non_vtable_p): Walk references of 
node
+   instead of references in node.
+
 2011-06-27  Richard Henderson  
 
* config/alpha/alpha.c (vms_patch_builtins): Provide dummy definition.
Index: ipa.c
===
--- ipa.c   (revision 175554)
+++ ipa.c   (working copy)
@@ -542,13 +542,13 @@ cgraph_address_taken_from_non_vtable_p (
 {
   int i;
   struct ipa_ref *ref;
-  for (i = 0; ipa_ref_list_reference_iterate (&node->ref_list, i, ref); i++)
+  for (i = 0; ipa_ref_list_refering_iterate (&node->ref_list, i, ref); i++)
 if (ref->use == IPA_REF_ADDR)
   {
struct varpool_node *node;
-   if (ref->refered_type == IPA_REF_CGRAPH)
+   if (ref->refering_type == IPA_REF_CGRAPH)
  return true;
-   node = ipa_ref_varpool_node (ref);
+   node = ipa_ref_refering_varpool_node (ref);
if (!DECL_VIRTUAL_P (node->decl))
  return true;
   }

Re: ia64-linux build broken

[Richard Henderson]

On 06/27/2011 12:23 PM, Richard Henderson wrote:
> On 06/27/2011 12:11 PM, Richard Henderson wrote:
>> gcc -c  -DUSE_LIBUNWIND_EXCEPTIONS  -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  
>> -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes 
>> -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long 
>> -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition 
>> -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../comb/gcc 
>> -I../../comb/gcc/. -I../../comb/gcc/../include 
>> -I../../comb/gcc/../libcpp/include  -I../../comb/gcc/../libdecnumber 
>> -I../../comb/gcc/../libdecnumber/dpd -I../libdecnumber\
>>  ../../comb/gcc/config/ia64/ia64.c -o ia64.o
>> ../../comb/gcc/config/ia64/ia64.c: In function ‘ia64_init_builtins’:
>> ../../comb/gcc/config/ia64/ia64.c:10136:7: warning: implicit declaration of 
>> function ‘vms_patch_builtins’ [-Wimplicit-function-declaration]
> 
> And of course alpha-linux is broken for the same reason.
> You cannot call a function in config/vms.c without ifdef protection.

Fixed thus.


r~
* config/alpha/alpha.c (vms_patch_builtins): Provide dummy definition.
* config/ia64/ia64.c (ia64_init_builtins): Call vms_patch_builtins
inside ifdef.

diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 5d656f1..962f020 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -198,6 +198,8 @@ static rtx alpha_emit_xfloating_compare (enum rtx_code *, 
rtx, rtx);
 #if TARGET_ABI_OPEN_VMS
 static void alpha_write_linkage (FILE *, const char *, tree);
 static bool vms_valid_pointer_mode (enum machine_mode);
+#else
+#define vms_patch_builtins()  gcc_unreachable()
 #endif
 
 #ifdef TARGET_ALTERNATE_LONG_DOUBLE_MANGLING
diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
index b0d9dc8..c06903d 100644
--- a/gcc/config/ia64/ia64.c
+++ b/gcc/config/ia64/ia64.c
@@ -10131,10 +10131,9 @@ ia64_init_builtins (void)
   "__float128");
 
   /* Fwrite on VMS is non-standard.  */
-  if (TARGET_ABI_OPEN_VMS)
-{
-  vms_patch_builtins ();
-}
+#if TARGET_ABI_OPEN_VMS
+  vms_patch_builtins ();
+#endif
 
 #define def_builtin(name, type, code)  \
   add_builtin_function ((name), (type), (code), BUILT_IN_MD,   \

Re: Unreviewed build/libgcc, mudflap patches

[Mike Stump]

On Jun 27, 2011, at 9:54 AM, Iain Sandoe wrote:
> On 27 Jun 2011, at 12:32, Rainer Orth wrote:
> 
>> The following three patches have remained unreviewed for a week:
>> 
>>  [build] Move unwinder to toplevel libgcc
>>   http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html

> As far as Darwin is concerned, there do not appear to be any problems.

Darwin bits are Ok.

Re: [pph] Moved token cache streaming to in/out respectively (issue4635073)

[dnovillo]

On 2011/06/27 18:51:22, Gabriel Charette wrote:


2011-06-27  Gabriel Charette  



* pph-streamer-in.c (pth_get_type_from_index): Moved from pph.c.
(pth_load_number): Moved from pph.c.
(pth_load_token_value): Moved from pph.c.
(pth_load_token): Moved from pph.c.
(pth_load_token_cache): Moved from pph.c. Made static.
* pph-streamer-out.c (pth_get_index_from_type): Moved from pph.c.
(pth_write_number): Moved from pph.c.
(pth_save_token_value): Moved from pph.c.
(pth_save_token): Moved from pph.c.
(pth_save_token_cache): Moved from pph.c. Made static.
* pph-streamer.h (struct cp_token_cache):
Not declared in pph.c, but in parser.h, removed.
(pth_save_token_cache): Now static, removed.
(pth_load_token_cache): Now static, removed.


OK.  Will apply shortly.


Diego.

http://codereview.appspot.com/4635073/

Re: ia64-linux build broken

[Richard Henderson]

On 06/27/2011 12:11 PM, Richard Henderson wrote:
> gcc -c  -DUSE_LIBUNWIND_EXCEPTIONS  -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  
> -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes 
> -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common  
> -DHAVE_CONFIG_H -I. -I. -I../../comb/gcc -I../../comb/gcc/. 
> -I../../comb/gcc/../include -I../../comb/gcc/../libcpp/include  
> -I../../comb/gcc/../libdecnumber -I../../comb/gcc/../libdecnumber/dpd 
> -I../libdecnumber\
>   ../../comb/gcc/config/ia64/ia64.c -o ia64.o
> ../../comb/gcc/config/ia64/ia64.c: In function ‘ia64_init_builtins’:
> ../../comb/gcc/config/ia64/ia64.c:10136:7: warning: implicit declaration of 
> function ‘vms_patch_builtins’ [-Wimplicit-function-declaration]

And of course alpha-linux is broken for the same reason.
You cannot call a function in config/vms.c without ifdef protection.

Re: [Patch, AVR]: AVR backend cleanup: use elfos.h

[Georg-Johann Lay]

Denis Chertykov schrieb:

2011/6/27 Georg-Johann Lay:



http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02011.html

[...]

Is there a specific reason not to emit .ident?
If not, I would remove the #undefs of IDENT_ASM_OP and
ASM_OUTPUT_IDENT from avr/elf.h.


Sorry, I forgot.

Denis.


It's just a marginality... please pick one of:

[ ] Leave the patch as is (and add a comment).

or

[ ] Remove the undefs so that we have .ident.
There's nothing terrific about it, it just adds
some text to .comment section.  I guess it's missing
because noone ever added it.

Johann

ia64-linux build broken

[Richard Henderson]

2011-06-27  Tristan Gingold  

PR target/44241
* config/vms/vms-protos.h: New file.
* config/vms/vms-crtlmap.map: New file.
* config/vms/vms.c: New file.
* config/vms/make-crtlmap.awk: New file.
* config/vms/vms-crtl.h: File removed.
* config/vms/vms-crtl-64.h: File removed.
* config/vms/t-vms (vms-crtlmap.h, vms.o): New targets.
* config/alpha/vms64.h: Do not include vms-crtl-64.h
* config/alpha/alpha.c (alpha_init_builtins): Remove code to
clear some builtins on VMS.  Calls vms_patch_builtins.
(avms_asm_output_external): Remove.
* config/alpha/vms.h (ASM_OUTPUT_EXTERNAL): Remove.
(struct crtl_name_spec): Remove
(DO_CTRL_NAMES): Remove.
* config/ia64/vms.h (struct crtl_name_spec): Remove
(DO_CTRL_NAMES): Remove.
* config/ia64/ia64.c (alpha_init_builtins): Remove code to
clear some builtins on VMS.  Calls vms_patch_builtins.
(ia64_asm_output_external): Remove DO_CRTL_NAME.
* config/ia64/vms64.h: Do not include vms-crtl-64.h
* config.gcc (*-*-*vms*): Define extra_objs, target_gtfiles,
tm_p_file.

causes

gcc -c  -DUSE_LIBUNWIND_EXCEPTIONS  -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W 
-Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common  
-DHAVE_CONFIG_H -I. -I. -I../../comb/gcc -I../../comb/gcc/. 
-I../../comb/gcc/../include -I../../comb/gcc/../libcpp/include  
-I../../comb/gcc/../libdecnumber -I../../comb/gcc/../libdecnumber/dpd 
-I../libdecnumber\
../../comb/gcc/config/ia64/ia64.c -o ia64.o
../../comb/gcc/config/ia64/ia64.c: In function ‘ia64_init_builtins’:
../../comb/gcc/config/ia64/ia64.c:10136:7: warning: implicit declaration of 
function ‘vms_patch_builtins’ [-Wimplicit-function-declaration]


r~

Re: [pph] Add header files to pph.map (issue4639073)

[Lawrence Crowl]

On 6/27/11, Gabriel Charette  wrote:
> On Jun 27, 2011 Diego Novillo  wrote:
> > On Jun 27, 2011 Gabriel Charette  wrote:
> > > Couldn't we have headers look for their corresponding .pph
> > > file by default when -fpph-map is on? (especially since
> > > pph.map is only temporary for the implementation phase)
> >
> > The problem is with headers that include other headers.
> > We want to limit the generation of images to specific headers.
> > Given that we are in this initial implementation phase, the
> > simplest approach is to remember to update pph.map.
>
> Well in what I'm proposing we only use the pph file if it was
> actually generated before (we don't generate it if it's not
> there). Are there any situations where we have a corresponding
> pph file, but don't actually want to use it when the fpph-map
> flag is on? Seems unlikely as we put all the pph files in the
> pph map for now anyways...

For a shortcut, you can add the option

-fpph-hdr=   A mapping from .h to .pph

In general, the pph files won't live in the same directory as the
header file.  This will cause problems when two headers have the same
name.  I would rather not get into complicated search rules just yet.

-- 
Lawrence Crowl

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const

[Ulrich Weigand]

H.J. Lu wrote:

> Reloads for insn # 588
> Reload 0: reload_in (DI) =3D (reg/v/f:DI 182 [ b ])
> GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum =3D 0)
> reload_in_reg: (reg/v/f:DI 182 [ b ])
> reload_reg_rtx: (reg:DI 1 dx)
> Reload 1: reload_in (DI) =3D (zero_extend:DI (plus:SI (subreg:SI (reg/v/f:D=
> I 182
> [ b ]) 0)
> (const_int 8 [0x8])=
> ))
> GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum =3D 0)
> reload_in_reg: (zero_extend:DI (plus:SI (subreg:SI (reg/v/f:DI 182 =
> [ b
> ]) 0)
> (const_int 8 [0x8])=
> ))
> reload_reg_rtx: (reg:DI 1 dx)
> Reload 2: reload_out (DF) =3D (mem:DF (zero_extend:DI (plus:SI (subreg:SI
> (reg/v/f:DI 182 [ b ]) 0)
> (const_int 8
> [0x8]))) [4 MEM[base: b_96(D), index: D.15020_278, step: 8, offset: 0B]+0 S8
> A64])
> NO_REGS, RELOAD_FOR_OUTPUT (opnum =3D 0), optional
> reload_out_reg: (mem:DF (zero_extend:DI (plus:SI (subreg:SI (reg/v/=
> f:DI
> 182 [ b ]) 0)
> (const_int 8
> [0x8]))) [4 MEM[base: b_96(D), index: D.15020_278, step: 8, offset: 0B]+0 S8
> A64])
> 
> leads to
> 

> (insn 1017 587 1020 34 (set (reg:DI 1 dx)
> (mem/c:DI (plus:DI (reg/f:DI 7 sp)
> (const_int 112 [0x70])) [5 %sfp+-208 S8 A64])) spooles.c:29=
> 1 62
> {*movdi_internal_rex64}
>  (nil))

So this is the reload insn generated from reload 0.  So far so good.

> (insn 1020 1017 1022 34 (set (reg:SI 1 dx)
> (const_int 8 [0x8])) spooles.c:291 64 {*movsi_internal}
>  (nil))
> 
> (insn 1022 1020 1023 34 (set (reg:SI 1 dx)
> (reg:SI 1 dx)) spooles.c:291 64 {*movsi_internal}
>  (nil))
> 
> (insn 1023 1022 1024 34 (set (reg:SI 1 dx)
> (plus:SI (reg:SI 1 dx)
> (const_int 8 [0x8]))) spooles.c:291 248 {*lea_1_x32}
>  (expr_list:REG_EQUIV (plus:SI (subreg:SI (reg:DI 1 dx) 0)
> (const_int 8 [0x8]))
> (nil)))
> 
> (insn 1024 1023 588 34 (set (reg:DI 1 dx)
> (zero_extend:DI (reg:SI 1 dx))) spooles.c:291 112
> {*zero_extendsidi2_rex64}
>  (expr_list:REG_EQUIV (zero_extend:DI (plus:SI (subreg:SI (reg:DI 1 dx)=
>  0)
> (const_int 8 [0x8])))
> (nil)))

All these reload insns are generated from reload 1.

> (insn 588 1024 589 34 (set (mem:DF (reg:DI 1 dx) [4 MEM[base: b_96(D), inde=
> x:
> D.15020_278, step: 8, offset: 0B]+0 S8 A64])
> (reg:DF 0 ax [orig:340 D.14980 ] [340])) spooles.c:291 106
> {*movdf_internal_rex64}
>  (nil))

This is the original reloaded insn.

> Reload 0 puts (reg/v/f:DI 182 [ b ]) in  (reg:DI 1 dx) for input.
> However, reload 2
> puts (reg/v/f:DI 182 [ b ]) in  (reg:DI 1 dx) for output.without checking w=
> hat
> reload 0 did.

Reload 2 is an optional reload which reload chose not to utilize, so this
is not really relevant here in any case.  There is no output reload.

The wrong code above originates from how reload 1 is handled:

gen_reload is called to load the ZERO_EXTEND into (reg:DI 1).  This triggers
the "unary predicate" path, which recurses into gen_reload to load the operand
of the ZERO_EXTEND (reg:SI 1), and subsequently generates insn 1024.

The recursive call loads (plus:SI (subreg:SI (reg:DI 1)) (const_int 8)) into
(reg:SI 1).  It attempts to do that in a single SET and fails (for some
reason).  It then attempts to load the constant (const_int 8) into the
destination register (insn 1020) [** which is broken **], and re-tries.
This still fails, so it falls through to the last attempt, which is to
instead copy the subreg to the destination (which results in insn 1022
as the subreg is optimized away at this point), followed by adding the
constant.

Note that the point marked with "[** which is broken **]" is the place
I pointed out in the previous mail.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: [pph] New test (issue4629075)

[Diego Novillo]

On Mon, Jun 27, 2011 at 14:56, Lawrence Crowl  wrote:
> On 6/27/11, Diego Novillo  wrote:
>> On Jun 27, 2011 Gabriel Charette  wrote:
>> > Just wondering why you're naming x finishing by an underscore
>> > "x_", this is a valid name, but just thinking it's tricky syntax,
>> > does this test anything more? or is it just a preference for
>> > private members?
>>
>> No real reason.  Just a quick hack I was trying to compile with
>> pph enabled.
>
> There is a convention in Google (and elsewhere) to mark data member
> fields with a trailing underscore in their name.  This convention
> makes it easy to identify field accesses, which helps avoid
> performance problems (unnecessary reloads) and correctness problems
> (missing reloads in the presence of aliasing).

That's probably where I picked it from.  I wasn't really thinking
about the code itself.  Just wanted to get some simple C++ executable
test.


Diego.

Re: [pph] New test (issue4629075)

[Lawrence Crowl]

On 6/27/11, Diego Novillo  wrote:
> On Jun 27, 2011 Gabriel Charette  wrote:
> > Just wondering why you're naming x finishing by an underscore
> > "x_", this is a valid name, but just thinking it's tricky syntax,
> > does this test anything more? or is it just a preference for
> > private members?
>
> No real reason.  Just a quick hack I was trying to compile with
> pph enabled.

There is a convention in Google (and elsewhere) to mark data member
fields with a trailing underscore in their name.  This convention
makes it easy to identify field accesses, which helps avoid
performance problems (unnecessary reloads) and correctness problems
(missing reloads in the presence of aliasing).

-- 
Lawrence Crowl

[patch tree-optimization]: Try to do type sinking on comparisons

[Kai Tietz]

Hello,

this patch tries to sink conversions for comparisons patterns:
a) (type) X cmp (type) Y => x cmp y.
b) (type) X cmp CST => x cmp ((type-x) CST).
c) CST cmp (type) X => ((type-x) CST) cmp x.

This patch just allows type sinking for the case that type-precision of type is 
wider or equal to type-precision of type-x. Or if type and type-x have same 
signess and CST fits into type-x. For cmp operation is == or !=, we allow also 
that type and type-x have different signess, as long as CST fits into type-x 
without truncation. 

ChangeLog

2011-06-27  Kai Tietz  

* tree-ssa-forwprop.c (forward_propagate_into_comparision):
Sink types within comparison operands, if suitable.

Bootstrapped and regression tested for x86_64-pc-linux-gnu. Ok for apply?

Regards,
Kai
Index: gcc-head/gcc/tree-ssa-forwprop.c
===
--- gcc-head.orig/gcc/tree-ssa-forwprop.c
+++ gcc-head/gcc/tree-ssa-forwprop.c
@@ -432,11 +432,73 @@ forward_propagate_into_comparison_1 (loc
   /* If that wasn't successful either, try both operands.  */
   if (rhs0 != NULL_TREE
   && rhs1 != NULL_TREE)
-tmp = combine_cond_expr_cond (loc, code, type,
- rhs0, rhs1,
- !(single_use0_p && single_use1_p));
-
-  return tmp;
+{
+  tmp = combine_cond_expr_cond (loc, code, type,
+   rhs0, rhs1,
+   !(single_use0_p && single_use1_p));
+  if (tmp)
+return tmp;
+}
+  /* Sink types of comparison, if (type) CMP (type) Y, if types
+ of X and Y are compatible.  */
+  if (rhs0 != NULL_TREE && rhs1 != NULL_TREE
+  && CONVERT_EXPR_CODE_P (TREE_CODE (rhs0))
+  && CONVERT_EXPR_CODE_P (TREE_CODE (rhs1))
+  && types_compatible_p (TREE_TYPE (TREE_OPERAND (rhs0, 0)),
+TREE_TYPE (TREE_OPERAND (rhs1, 0)))
+  /* Make sure that the conversion widens the operands, or has same
+precision.  */
+  && (TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (rhs0, 0)))
+  <= TYPE_PRECISION (TREE_TYPE (rhs0)))
+  && (code == EQ_EXPR || code == NE_EXPR
+ || TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (rhs0, 0)))
+== TYPE_UNSIGNED (TREE_TYPE (rhs0
+ return fold_build2_loc (loc, code, type, TREE_OPERAND (rhs0, 0),
+TREE_OPERAND (rhs1, 0));
+  /* Check if (type) X cmp CST can be convered into
+ (type) (X cmp (type-x) CST).  */
+  if (rhs0 != NULL_TREE
+  && CONVERT_EXPR_CODE_P (TREE_CODE (rhs0))
+  && TREE_CODE (op1) == INTEGER_CST
+  && INTEGRAL_TYPE_P (TREE_OPERAND (rhs0, 0))
+  && INTEGRAL_TYPE_P (rhs0)
+  && (code == EQ_EXPR || code == NE_EXPR
+ || TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (rhs0, 0)))
+== TYPE_UNSIGNED (TREE_TYPE (rhs0
+{
+  tree folded_int = fold_convert_loc (loc,
+ TREE_TYPE (TREE_OPERAND (rhs0, 0)),
+ op1);
+  /* Is the back casted folded integer identical to original
+integer?  */
+  if (operand_equal_p (op1, fold_convert_loc (loc, TREE_TYPE (op0),
+ folded_int), 0))
+return fold_build2_loc (loc, code, type, TREE_OPERAND (rhs0, 0),
+   folded_int);
+}
+
+  /* Check if CST op (type) X can be converted into
+ (type) ((type-x) CST op X).  */
+  if (rhs1 != NULL_TREE
+  && CONVERT_EXPR_CODE_P (TREE_CODE (rhs1))
+  && TREE_CODE (op0) == INTEGER_CST
+  && INTEGRAL_TYPE_P (TREE_OPERAND (rhs1, 0))
+  && INTEGRAL_TYPE_P (rhs1)
+  && (code == EQ_EXPR || code == NE_EXPR
+ || TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (rhs1, 0)))
+== TYPE_UNSIGNED (TREE_TYPE (rhs1
+{
+  tree folded_int = fold_convert_loc (loc,
+ TREE_TYPE (TREE_OPERAND (rhs1, 0)),
+ op0);
+  /* Is the back casted folded integer identical to original
+integer?  */
+  if (operand_equal_p (op0, fold_convert_loc (loc, TREE_TYPE (op1),
+ folded_int), 0))
+return fold_build2_loc (loc, code, type, folded_int,
+   TREE_OPERAND (rhs1, 0));
+}
+  return NULL_TREE;
 }
 
 /* Propagate from the ssa name definition statements of the assignment

[pph] Moved token cache streaming to in/out respectively (issue4635073)

[Gabriel Charette]

Moved all token cache streaming to it's respective in/out streamer.
They were non-static exposed methods, but were only used in 
pph-streamer-in/out.c

This is a pure copy/paste patch.

I will change the functions names to reflect the pph naming scheme in a 
subsequent patch.

Tested with bootstrap and pph regression testing.

2011-06-27  Gabriel Charette  

* pph-streamer-in.c (pth_get_type_from_index): Moved from pph.c.
(pth_load_number): Moved from pph.c.
(pth_load_token_value): Moved from pph.c.
(pth_load_token): Moved from pph.c.
(pth_load_token_cache): Moved from pph.c. Made static.
* pph-streamer-out.c (pth_get_index_from_type): Moved from pph.c.
(pth_write_number): Moved from pph.c.
(pth_save_token_value): Moved from pph.c.
(pth_save_token): Moved from pph.c.
(pth_save_token_cache): Moved from pph.c. Made static.
* pph-streamer.h (struct cp_token_cache): 
Not declared in pph.c, but in parser.h, removed.
(pth_save_token_cache): Now static, removed.
(pth_load_token_cache): Now static, removed.

diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
index 605b214..6743c3c 100644
--- a/gcc/cp/pph-streamer-in.c
+++ b/gcc/cp/pph-streamer-in.c
@@ -242,6 +242,164 @@ pph_register_shared_data (pph_stream *stream, void *data, 
unsigned ix)
 }
 
 
+/* Given a type index TYPE_IDX and TYPE_KIND specifying the kind of type,
+   return a type from integer_types or global_trees.  */
+
+static tree
+pth_get_type_from_index (unsigned type_idx, unsigned type_kind)
+{
+  if (type_kind == CPP_N_INTEGER)
+return integer_types[type_idx];
+  else if (type_kind == CPP_N_FLOATING || type_kind == CPP_N_FRACT)
+return global_trees[type_idx];
+  else if (type_kind == CPP_N_IMAGINARY)
+{
+  /* We don't need a type for the complex number.  The type is
+associated with the real and imaginary parts.  */
+  return NULL_TREE;
+}
+  else
+gcc_unreachable ();
+}
+
+
+/* Load a numeric value from file F.  Return the corresponding tree.  */
+
+static tree
+pth_load_number (pph_stream *f)
+{
+  unsigned type_idx, type_kind;
+  tree type, val;
+
+  type_idx = pph_in_uint (f);
+  type_kind = pph_in_uint (f);
+
+  type = pth_get_type_from_index (type_idx, type_kind);
+
+  if (type_kind == CPP_N_INTEGER)
+{
+  HOST_WIDE_INT v[2];
+  pph_in_bytes (f, v, 2 * sizeof (HOST_WIDE_INT));
+  val = build_int_cst_wide (type, v[0], v[1]);
+}
+  else if (type_kind == CPP_N_FLOATING)
+{
+  REAL_VALUE_TYPE r;
+  pph_in_bytes (f, &r, sizeof (REAL_VALUE_TYPE));
+  val = build_real (type, r);
+}
+  else if (type_kind == CPP_N_FRACT)
+{
+  FIXED_VALUE_TYPE fv;
+  pph_in_bytes (f, &fv, sizeof (FIXED_VALUE_TYPE));
+  val = build_fixed (type, fv);
+}
+  else if (type_kind == CPP_N_IMAGINARY)
+{
+  tree r = pth_load_number (f);
+  tree i = pth_load_number (f);
+  val = build_complex (NULL_TREE, r, i);
+}
+  else
+gcc_unreachable ();
+
+  return val;
+}
+
+
+/* Load the tree value associated with TOKEN to file F.  */
+
+static void
+pth_load_token_value (cp_token *token, pph_stream *f)
+{
+  const char *str;
+
+  switch (token->type)
+{
+  case CPP_TEMPLATE_ID:
+  case CPP_NESTED_NAME_SPECIFIER:
+   break;
+
+  case CPP_NAME:
+   str = pph_in_string (f);
+   token->u.value = get_identifier (str);
+   break;
+
+  case CPP_KEYWORD:
+   token->u.value = ridpointers[token->keyword];
+   break;
+
+  case CPP_CHAR:
+  case CPP_WCHAR:
+  case CPP_CHAR16:
+  case CPP_CHAR32:
+  case CPP_NUMBER:
+   token->u.value = pth_load_number (f);
+   break;
+
+  case CPP_STRING:
+  case CPP_WSTRING:
+  case CPP_STRING16:
+  case CPP_STRING32:
+   str = pph_in_string (f);
+   token->u.value = build_string (strlen (str), str);
+   break;
+
+  case CPP_PRAGMA:
+   /* Nothing to do.  Field pragma_kind has already been loaded.  */
+   break;
+
+  default:
+   pph_in_bytes (f, &token->u.value, sizeof (token->u.value));
+   gcc_assert (token->u.value == NULL);
+}
+}
+
+
+/* Read and return a token from STREAM.  */
+
+static cp_token *
+pth_load_token (pph_stream *stream)
+{
+  cp_token *token = ggc_alloc_cleared_cp_token ();
+
+  /* Do not read the whole structure, the token value has
+ dynamic size as it contains swizzled pointers.
+ FIXME pph, restructure to allow bulk reads of the whole
+ section.  */
+  pph_in_bytes (stream, token, sizeof (cp_token) - sizeof (void *));
+
+  /* FIXME pph.  Use an arbitrary (but valid) location to avoid
+ confusing the rest of the compiler for now.  */
+  token->location = input_location;
+
+  /* FIXME pph: verify that pth_load_token_value works with no tokens.  */
+  pth_load_token_value (token, stream);
+
+  return token;
+}
+
+
+/* Read and return a cp_token_cache instance 

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const

[H.J. Lu]

On Mon, Jun 27, 2011 at 11:28 AM, Ulrich Weigand  wrote:
> H.J. Lu wrote:
>> On Mon, Jun 27, 2011 at 7:47 AM, Ulrich Weigand  wrote:
>> > The actual problem
>> > here is that this part of gen_reload takes the approach to transform
>> >
>> >  out <- op0 + op1
>> >
>> > into
>> >
>> >  out <- op0
>> >  out <- out + op1
>> >
>> > which is invalid if writing to out clobbers op1.
>
>> The problem is reload 0 puts OP1 in OUT. Adding
>>
>> gcc_assert (!reg_overlap_mentioned_p (out, op1));
>>
>> doesn't help in reload 2.  How can I check if OP1 overlaps with
>> OUT in previous reload?
>
> Sorry, I don't understand how previous reloads come into play here.
> gen_reload is supposed to load "in" (which happens to be of the
> form op0 + op1) into "out", which means it is of course supposed
> to clobber "out" (as long as that doesn't implictly clobber op0
> or op1 before they're used).  Any conflicts with other reloads ought
> to have been resolved earlier.
>
> Can you elaborate?
>

Here is the output from reload:

Reloads for insn # 588
Reload 0: reload_in (DI) = (reg/v/f:DI 182 [ b ])
GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (reg/v/f:DI 182 [ b ])
reload_reg_rtx: (reg:DI 1 dx)
Reload 1: reload_in (DI) = (zero_extend:DI (plus:SI (subreg:SI (reg/v/f:DI 182
[ b ]) 0)
(const_int 8 [0x8])))
GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (zero_extend:DI (plus:SI (subreg:SI (reg/v/f:DI 182 [ b
]) 0)
(const_int 8 [0x8])))
reload_reg_rtx: (reg:DI 1 dx)
Reload 2: reload_out (DF) = (mem:DF (zero_extend:DI (plus:SI (subreg:SI
(reg/v/f:DI 182 [ b ]) 0)
(const_int 8
[0x8]))) [4 MEM[base: b_96(D), index: D.15020_278, step: 8, offset: 0B]+0 S8
A64])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem:DF (zero_extend:DI (plus:SI (subreg:SI (reg/v/f:DI
182 [ b ]) 0)
(const_int 8
[0x8]))) [4 MEM[base: b_96(D), index: D.15020_278, step: 8, offset: 0B]+0 S8
A64])

leads to

(insn 1017 587 1020 34 (set (reg:DI 1 dx)
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 112 [0x70])) [5 %sfp+-208 S8 A64])) spooles.c:291 62
{*movdi_internal_rex64}
 (nil))

(insn 1020 1017 1022 34 (set (reg:SI 1 dx)
(const_int 8 [0x8])) spooles.c:291 64 {*movsi_internal}
 (nil))

(insn 1022 1020 1023 34 (set (reg:SI 1 dx)
(reg:SI 1 dx)) spooles.c:291 64 {*movsi_internal}
 (nil))

(insn 1023 1022 1024 34 (set (reg:SI 1 dx)
(plus:SI (reg:SI 1 dx)
(const_int 8 [0x8]))) spooles.c:291 248 {*lea_1_x32}
 (expr_list:REG_EQUIV (plus:SI (subreg:SI (reg:DI 1 dx) 0)
(const_int 8 [0x8]))
(nil)))

(insn 1024 1023 588 34 (set (reg:DI 1 dx)
(zero_extend:DI (reg:SI 1 dx))) spooles.c:291 112
{*zero_extendsidi2_rex64}
 (expr_list:REG_EQUIV (zero_extend:DI (plus:SI (subreg:SI (reg:DI 1 dx) 0)
(const_int 8 [0x8])))
(nil)))

(insn 588 1024 589 34 (set (mem:DF (reg:DI 1 dx) [4 MEM[base: b_96(D), index:
D.15020_278, step: 8, offset: 0B]+0 S8 A64])
(reg:DF 0 ax [orig:340 D.14980 ] [340])) spooles.c:291 106
{*movdf_internal_rex64}
 (nil))

Reload 0 puts (reg/v/f:DI 182 [ b ]) in  (reg:DI 1 dx) for input.
However, reload 2
puts (reg/v/f:DI 182 [ b ]) in  (reg:DI 1 dx) for output.without checking what
reload 0 did.

-- 
H.J.

Re: [RFC, ARM] Convert thumb1 prologue completely to rtl

[Richard Henderson]

On 06/24/2011 02:59 AM, Richard Earnshaw wrote:
> On 18/06/11 20:02, Richard Henderson wrote:
>> I couldn't find anything terribly tricky about the conversion.
>>
>> The existing push_mult pattern would service thumb1 with just
>> a tweak or two to the memory predicate and the length.
>>
>> The existing emit_multi_reg_push wasn't set up to handle a
>> complete switch of registers for unwind info.  I thought about
>> trying to merge them, but thought chickened out.
>>
>> I havn't cleaned out the code that is now dead in thumb_pushpop.
>> I'd been thinking about maybe converting epilogues completely
>> to rtl as well, which would allow the function to be deleted
>> completely, rather than incrementally.
>>
>> I'm unsure what testing should be applied.  I'm currently doing
>> arm-elf, which does at least have a thumb1 multilib, and uses
>> newlib so I don't have to fiddle with setting up a full native
>> cross environment.  What else should be done?  arm-eabi?
>>
> 
> Testing this on arm-eabi is essential since this may affect C++ unwind
> table generation (I can't see any obvious problems, but you never know).
> 

I've now tested the patch with both arm-elf and arm-eabi with
RUNTESTFLAGS='--target_board=arm-sim{-mthumb}' with no regressions.

Ok to install?


r~

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const

[Ulrich Weigand]

H.J. Lu wrote:
> On Mon, Jun 27, 2011 at 7:47 AM, Ulrich Weigand  wrote:
> > The actual problem
> > here is that this part of gen_reload takes the approach to transform
> >
> >  out <- op0 + op1
> >
> > into
> >
> >  out <- op0
> >  out <- out + op1
> >
> > which is invalid if writing to out clobbers op1.

> The problem is reload 0 puts OP1 in OUT. Adding
> 
> gcc_assert (!reg_overlap_mentioned_p (out, op1));
> 
> doesn't help in reload 2.  How can I check if OP1 overlaps with
> OUT in previous reload?

Sorry, I don't understand how previous reloads come into play here.
gen_reload is supposed to load "in" (which happens to be of the
form op0 + op1) into "out", which means it is of course supposed
to clobber "out" (as long as that doesn't implictly clobber op0
or op1 before they're used).  Any conflicts with other reloads ought
to have been resolved earlier.

Can you elaborate?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: [PATCH][RFC][2/2] Bitfield lowering

[Richard Henderson]

On 06/23/2011 02:49 AM, Richard Guenther wrote:
> So, do you know of a target that can do insv with a memory
> target?  I would expect extv on memory to be easily doable.

Depends on what you mean by that.  INSV is the traditional
md pattern that performs unaligned stores.  So, many targets
can handle a memory destination of some sort.

Many many less would handle memory if we completed the 
transition of unaligned memory load/store to movmisalign.
But at present movmisalign is only defined for vector modes.


r~

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int

[H.J. Lu]

On Mon, Jun 27, 2011 at 7:47 AM, Ulrich Weigand  wrote:
> H.J. Lu wrote:
>
>> When reload gets:
>>
>> (insn 588 587 589 28 (set (mem:DF (zero_extend:DI (plus:SI (subreg:SI
>> (reg/v/f:DI 182 [ b ]) 0)
>>                     (const_int 8 [0x8]))) [4 MEM[base: b_96(D), index:
>> D.15020_278, step: 8, offset: 0B]+0 S8 A64])
>>         (reg:DF 340 [ D.14980 ])) spooles.c:291 106
>> {*movdf_internal_rex64}
>>      (expr_list:REG_DEAD (reg:DF 340 [ D.14980 ])
>>         (nil)))
>
> Reloading of PLUS expressions is a long-standing problem.  gen_reload
> supports those only for PLUSes that look more or less like address
> computations, and then only the "usual" cases.
>
> Is the address above (once the pseudo reg:DI 182 is replaced by
> a hard reg) really a legitimate address on your platform?  If not,
> this would need to be fixed at some earlier place.
>
> If this *is* a valid address (and just not valid for this particular
> insn pattern), the back-end needs to provide some means to reload to
> allow reloading of such expressions.  This can be done either by
> providing an insn (plus post-reload splitter if necessary), or else
> defining a secondary reload to handle the case where additional
> registers are required.  Assuming the generic gen_reload code is
> powerful enough to handle complex expressions like this is probably
> not wise ...
>
> In any case, however, gen_reload should not generate *wrong*
> code, so there's indeed a bug here.
>
> However, this:
>
>> -      if (CONSTANT_P (op1) || MEM_P (op1) || GET_CODE (op1) == SUBREG
>> +      if ((GET_CODE (op0) != SUBREG
>> +        && (CONSTANT_P (op1) || MEM_P (op1)))
>> +       || GET_CODE (op1) == SUBREG
>>         || (REG_P (op1)
>>             && REGNO (op1) >= FIRST_PSEUDO_REGISTER)
>>         || (code != CODE_FOR_nothing
>
> doesn't look like the proper fix for all cases.  The actual problem
> here is that this part of gen_reload takes the approach to transform
>
>     out <- op0 + op1
>
> into
>
>     out <- op0
>     out <- out + op1
>
> which is invalid if writing to out clobbers op1.
>
> This means that:
>
> - The "if" testing whether to swap op0 and op1 should verify
>    !reg_overlap_mentioned_p (out, op0)
>
> - Regardless of whether we swapped or not, there needs to be a
>    gcc_assert (!reg_overlap_mentioned_p (out, op1));
>  before the gen_reload (out, op0, opnum, type) line.
>
> There may still be cases where the algorithm of gen_reload doesn't
> work, but at least we'll get an ICE instead of wrong code now.
> Those cases will have to be fixed by the back-end as described
> above ...
>

The problem is reload 0 puts OP1 in OUT. Adding

gcc_assert (!reg_overlap_mentioned_p (out, op1));

doesn't help in reload 2.  How can I check if OP1 overlaps with
OUT in previous reload?


-- 
H.J.

Re: Simplify Solaris configuration

[Eric Botcazou]

> sorry about that: I don't test the 64-bit default configurations so far,
> and didn't even have the necessary support libs around to do so.  The
> problem was that sparc/sol2-64.h was included too late and
> DEFAULT_ARCH32_P was wrong for those configurations.
>
> The following patch should fix this:
>
> 2011-06-27  Rainer Orth  
>
>   * config.gcc (sparc*-*-solaris2*): Move sol2-bi.h after
>   sparc/sol2-64.h.

Thanks.

> At least I can build the 64-bit libgcc now, but the 32-bit one fails for
> unrelated reasons:
>
> configure:3247: checking for suffix of object files
> configure:3269: /var/gcc/gcc-4.7.0-20110622/11-gcc/./gcc/xgcc
> -B/var/gcc/gcc-4.7.0-20110622/11-gcc/./gcc/
> -B/usr/local/sparcv9-sun-solaris2.11/bin/
> -B/usr/local/sparcv9-sun-solaris2.11/lib/ -isystem
> /usr/local/sparcv9-sun-solaris2.11/include -isystem
> /usr/local/sparcv9-sun-solaris2.11/sys-include  -m32 -c -g -O2  conftest.c
> >&5 conftest.c:16:1: internal compiler error: in simplify_subreg, at
> simplify-rtx.c:5362

It's very likely the same problem, the options -mptr32 -mno-stack-bias aren't 
passed to cc1 anymore.

-- 
Eric Botcazou

Re: Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

Hi Iain,

>> The following three patches have remained unreviewed for a week:
>>
>>  [build] Move unwinder to toplevel libgcc
>>http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html
>>
>> This needs at least a build and/or libgcc maintainer, though a global
>> reviewer might be helpful.  I'm not Cc'ing the various affected target
>> or runtime library maintainers here, though unfortunately none of them
>> has commented in any way ;-(
>
> As far as Darwin is concerned, there do not appear to be any problems.
>
> The patch bootstraps on *-darwin9 and x86_64-darwin10 and reg-tested on
> i686-darwin9 with no issues.

great, thanks for testing.

> having said this .. I can neither approve nor reject the patch ;-)

Even so, every bit of assurance that this won't break many platforms helps.

> If you get as far as pushing the .ver files around, then I have some
> tidy-ups I'd like to incorporate (particularly with respect to gcc/
> libgcc-libsystem.ver which is in a funny place, and contains extra  symbols
> that are only used AFAIK by x86 darwin10).

No such plans at the moment: my primary motivation is to deal with
issues that affect platforms I maintain.  While I can test Darwin 9 if
need be, I'd rather restrict my time to my `own' platforms.

Rainer

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

Re: [Patch, AVR]: AVR backend cleanup: use elfos.h

[Denis Chertykov]

2011/6/27 Georg-Johann Lay :
> Denis Chertykov wrote:
>> 2011/6/27 Georg-Johann Lay :
>>> This patch removes ELF dependencies from avr.h and redundancies from
>>> avr.h and avr.c
>>>
>>> The AVR BE defines many things that are readily available in elfos.h.
>>> ELF is the only target supported by avr-gcc.
>>>
>>> The patch includes elfos.h in config.gcc for all avr* targets together
>>> with a new file avr/elf.h.
>>>
>>> ELF for avr deviates in some points from elfos.h. The needed overrides
>>> are defined in avr/elf.h.  avr/elf.h is included after elfos.h because
>>> that is the only way to achieve the needed overrides/undefs.
>>>
>>> The patch removes some hundreds lines from the AVR BE which are
>>> redundant, and the new avr/elf.h makes it much clearer what the actual
>>> deviations to default ELF implementation are.
>>>
>>> Some overrides like that there is no .ident emitted by avr presumably
>>> have just historical reasons; anyway the patch tries to be neutral
>>> compared to the present implementation.
>>>
>>> Same applies for other defines like READONLY_DATA_SECTION_ASM_OP:
>>> .rodata is mapped to .data by avr ldscripts anyway, so there is
>>> actually no need to set readonly_data_section = data_section and
>>> merging of STRING_CST could save some space.
>>>
>>> For zeroes memory the patch will emit
>>>   .zero N
>>> instead of
>>>   .skip N,0
>>>
>>> Tested without regressions and asm-output diffed for real-world avr-code.
>>>
>>> Johann
>>>        * config.gcc (tm_file): Add elfos.h and avr/elf.h for
>>>        avr-*-* and avr-*-rtems* targets.
>>>
>>>        * config/avr/elf.h: New file.
>>>        (ASM_OUTPUT_BEFORE_CASE_LABEL): Define.
>>>        (TARGET_ASM_SELECT_SECTION): Define.
>>>        (INIT_SECTION_ASM_OP): Undefine.
>>>        (FINI_SECTION_ASM_OP): Undefine.
>>>        (IDENT_ASM_OP): Undefine.
>>>        (ASM_OUTPUT_IDENT): Undefine.
>>>        (READONLY_DATA_SECTION_ASM_OP): Undefine.
>>>        (PCC_BITFIELD_TYPE_MATTERS): Undefine.
>>>        (TARGET_HAVE_SWITCHABLE_BSS_SECTIONS): Undefine.
>>>        * config/avr/avr.h:
>>>        (PREFERRED_DEBUGGING_TYPE): Move to elf.h.
>>>        (TARGET_ASM_NAMED_SECTION): Move to elf.h.
>>>        (MAX_OFILE_ALIGNMENT): Move to elf.h.
>>>        (STRING_LIMIT): Move to elf.h.
>>>        (ASM_DECLARE_FUNCTION_NAME): Move to elf.h.
>>>        (ASM_DECLARE_OBJECT_NAME): Remove.
>>>        (ESCAPES): Remove.
>>>        (ASM_OUTPUT_SKIP): Remove.
>>>        (DWARF2_DEBUGGING_INFO): Remove.
>>>        (OBJECT_FORMAT_ELF): Remove.
>>>        (USER_LABEL_PREFIX): Remove.
>>>        (ASM_OUTPUT_EXTERNAL): Remove.
>>>        (ASM_OUTPUT_ASCII): Remove.
>>>        (TYPE_ASM_OP): Remove.
>>>        (SIZE_ASM_OP): Remove.
>>>        (WEAK_ASM_OP): Remove.
>>>        (STRING_ASM_OP): Remove.
>>>        (SET_ASM_OP): Remove.
>>>        (ASM_WEAKEN_LABEL): Remove.
>>>        (TYPE_OPERAND_FMT): Remove.
>>>        (ASM_DECLARE_FUNCTION_SIZE): Remove.
>>>        (ASM_FINISH_DECLARE_OBJECT): Remove.
>>>        (NO_DOLLAR_IN_LABEL): Remove.
>>>        (ASM_GENERATE_INTERNAL_LABEL): Remove.
>>>        (ASM_OUTPUT_CASE_LABEL): Remove.
>>>        * config/avr/avr.c (avr_asm_output_aligned_decl_common): Use
>>>        ASM_OUTPUT_ALIGNED_LOCAL, ASM_OUTPUT_ALIGNED_COMMON.
>>>        (gas_output_ascii): Remove.
>>>        (gas_output_limited_string): Remove.
>>>        (TARGET_ASM_FILE_START_FILE_DIRECTIVE): Remove.
>>>        * config/avr/avr-protos.h
>>>        (gas_output_ascii): Remove prototye.
>>>        (gas_output_limited_string): Remove prototype.
>>>
>>
>> Approved.
>>
>> Denis.
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02011.html
>
> Is that also for the config.gcc part?
> Or does it need review from global reviewer?
>
> Is there a specific reason not to emit .ident?
> If not, I would remove the #undefs of IDENT_ASM_OP and
> ASM_OUTPUT_IDENT from avr/elf.h.

Sorry, I forgot.

Denis.

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jason Merrill]

On 06/27/2011 11:04 AM, Jan Kratochvil wrote:

Had to restrict the patch very much for the template function reference case as
otherwise the parameter types are required even in templates there.


They should be supressed whenever the function appears in an expression 
context, either as a pointer to member function (i.e. the operand of 
'&') or as the function being called in a call expression.


Jason

Re: Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

Hi Frank,

> Sure.  Transcribing:
>
>> One generic issue came up with the port: enabling or disabling
>> libmudflap depends on a factor (linker support for --wrap/-z wrap)
>> that is best checked dynamically, thus doesn't really seem to belong
>> at the toplevel.  Is there any precedent for performing such a test
>> in the target library and enabling or disabling depending on the
>> outcome?  [...]
>
> I don't know.

perhaps one of the build maintainers has a suggestion.  For the time
being, I'll juts continue with --enable-libmudflap.

>> It seems the failures fall into only a few categories.  It's
>> probably best to analyse and fix those before checking in the patch.
>> Where should we continue discussing the failures?  Here or rather in
>> the PR?
>
> Separate PRs would be best.

I've now filed

libmudflap/49549Use of --noinhibit-exec is unportable
libmudflap/49550Many libmudflap tests fail on Solaris 11/x86

The second one almost certainly covers a couple of different issues, but
I cannot identify them yet, so any help is appreciated.

Rainer

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

Re: [Patch, AVR]: AVR backend cleanup: use elfos.h

[Bernd Schmidt]

On 06/27/11 19:34, Georg-Johann Lay wrote:
> Denis Chertykov wrote:
>> Approved.
>>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02011.html
> 
> Is that also for the config.gcc part?
> Or does it need review from global reviewer?

Denis can approve AVR changes in config.gcc.


Bernd

Re: Unreviewed build/libgcc, mudflap patches

[Rainer Orth]

Hi Frank,

>>  Support libmudflap on Solaris (PR libmudflap/38738)
>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html
>
> Looks good to me, thanks for taking a look at the area.

I've installed the patch as it, since it at least fixes the libmudflap
build on Solaris.

Thanks.
Rainer

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

Re: [Patch, AVR]: AVR backend cleanup: use elfos.h

[Georg-Johann Lay]

Denis Chertykov wrote:
> 2011/6/27 Georg-Johann Lay :
>> This patch removes ELF dependencies from avr.h and redundancies from
>> avr.h and avr.c
>>
>> The AVR BE defines many things that are readily available in elfos.h.
>> ELF is the only target supported by avr-gcc.
>>
>> The patch includes elfos.h in config.gcc for all avr* targets together
>> with a new file avr/elf.h.
>>
>> ELF for avr deviates in some points from elfos.h. The needed overrides
>> are defined in avr/elf.h.  avr/elf.h is included after elfos.h because
>> that is the only way to achieve the needed overrides/undefs.
>>
>> The patch removes some hundreds lines from the AVR BE which are
>> redundant, and the new avr/elf.h makes it much clearer what the actual
>> deviations to default ELF implementation are.
>>
>> Some overrides like that there is no .ident emitted by avr presumably
>> have just historical reasons; anyway the patch tries to be neutral
>> compared to the present implementation.
>>
>> Same applies for other defines like READONLY_DATA_SECTION_ASM_OP:
>> .rodata is mapped to .data by avr ldscripts anyway, so there is
>> actually no need to set readonly_data_section = data_section and
>> merging of STRING_CST could save some space.
>>
>> For zeroes memory the patch will emit
>>   .zero N
>> instead of
>>   .skip N,0
>>
>> Tested without regressions and asm-output diffed for real-world avr-code.
>>
>> Johann
>>* config.gcc (tm_file): Add elfos.h and avr/elf.h for
>>avr-*-* and avr-*-rtems* targets.
>>
>>* config/avr/elf.h: New file.
>>(ASM_OUTPUT_BEFORE_CASE_LABEL): Define.
>>(TARGET_ASM_SELECT_SECTION): Define.
>>(INIT_SECTION_ASM_OP): Undefine.
>>(FINI_SECTION_ASM_OP): Undefine.
>>(IDENT_ASM_OP): Undefine.
>>(ASM_OUTPUT_IDENT): Undefine.
>>(READONLY_DATA_SECTION_ASM_OP): Undefine.
>>(PCC_BITFIELD_TYPE_MATTERS): Undefine.
>>(TARGET_HAVE_SWITCHABLE_BSS_SECTIONS): Undefine.
>>* config/avr/avr.h:
>>(PREFERRED_DEBUGGING_TYPE): Move to elf.h.
>>(TARGET_ASM_NAMED_SECTION): Move to elf.h.
>>(MAX_OFILE_ALIGNMENT): Move to elf.h.
>>(STRING_LIMIT): Move to elf.h.
>>(ASM_DECLARE_FUNCTION_NAME): Move to elf.h.
>>(ASM_DECLARE_OBJECT_NAME): Remove.
>>(ESCAPES): Remove.
>>(ASM_OUTPUT_SKIP): Remove.
>>(DWARF2_DEBUGGING_INFO): Remove.
>>(OBJECT_FORMAT_ELF): Remove.
>>(USER_LABEL_PREFIX): Remove.
>>(ASM_OUTPUT_EXTERNAL): Remove.
>>(ASM_OUTPUT_ASCII): Remove.
>>(TYPE_ASM_OP): Remove.
>>(SIZE_ASM_OP): Remove.
>>(WEAK_ASM_OP): Remove.
>>(STRING_ASM_OP): Remove.
>>(SET_ASM_OP): Remove.
>>(ASM_WEAKEN_LABEL): Remove.
>>(TYPE_OPERAND_FMT): Remove.
>>(ASM_DECLARE_FUNCTION_SIZE): Remove.
>>(ASM_FINISH_DECLARE_OBJECT): Remove.
>>(NO_DOLLAR_IN_LABEL): Remove.
>>(ASM_GENERATE_INTERNAL_LABEL): Remove.
>>(ASM_OUTPUT_CASE_LABEL): Remove.
>>* config/avr/avr.c (avr_asm_output_aligned_decl_common): Use
>>ASM_OUTPUT_ALIGNED_LOCAL, ASM_OUTPUT_ALIGNED_COMMON.
>>(gas_output_ascii): Remove.
>>(gas_output_limited_string): Remove.
>>(TARGET_ASM_FILE_START_FILE_DIRECTIVE): Remove.
>>* config/avr/avr-protos.h
>>(gas_output_ascii): Remove prototye.
>>(gas_output_limited_string): Remove prototype.
>>
> 
> Approved.
> 
> Denis.

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02011.html

Is that also for the config.gcc part?
Or does it need review from global reviewer?

Is there a specific reason not to emit .ident?
If not, I would remove the #undefs of IDENT_ASM_OP and
ASM_OUTPUT_IDENT from avr/elf.h.

Johann

{patch tree-ssa-math-opts]: Change searching direction for bswap

[Kai Tietz]

Hello,

this is the separated patch for issues noticed by doing type-sinking on 
bitwise-operations.  The tests exposed that bswap pattern-matching searches 
from top to down for each BB. As it replaces the found match for a bswap in 
tree, but doesn't know about handling its inserted builtin-swap on 
pattern-matching for wider-mode bswap, search failed.
By reversing search order within BB from last to first, this issue can be fixed.

ChangeLog

2011-06-27  Kai Tietz  

* tree-ssa-math-opts.c (execute_optimize_bswap): Search
within BB from last to first.

Bootstrapped and regression-tested for x86_64-pc-linux-gnu. Ok for apply?

Regards,
Kai

Index: gcc-head/gcc/tree-ssa-math-opts.c
===
--- gcc-head.orig/gcc/tree-ssa-math-opts.c
+++ gcc-head/gcc/tree-ssa-math-opts.c
@@ -1820,8 +1820,10 @@ execute_optimize_bswap (void)
   FOR_EACH_BB (bb)
 {
   gimple_stmt_iterator gsi;
-
+/*
   for (gsi = gsi_after_labels (bb); !gsi_end_p (gsi); gsi_next (&gsi))
+ */
+  for (gsi = gsi_last_bb (bb); !gsi_end_p (gsi); gsi_prev (&gsi))
 {
  gimple stmt = gsi_stmt (gsi);
  tree bswap_src, bswap_type;

Re: [pph] Add header files to pph.map (issue4639073)

[Gabriel Charette]

On Mon, Jun 27, 2011 at 10:18 AM, Diego Novillo  wrote:
> On Mon, Jun 27, 2011 at 13:13, Gabriel Charette  wrote:
>> On Mon, Jun 27, 2011 at 10:06 AM, Diego Novillo  wrote:
>>> On Mon, Jun 27, 2011 at 13:01, Gabriel Charette  wrote:
 Couldn't we have headers look for their corresponding .pph file by
 default when -fpph-map is on? (especially since pph.map is only
 temporary for the implementation phase)
>>>
>>> The problem is with headers that include other headers.  We want to
>>> limit the generation of images to specific headers.  Given that we are
>>> in this initial implementation phase, the simplest approach is to
>>> remember to update pph.map.
>>
>> Well in what I'm proposing we only use the pph file if it was actually
>> generated before (we don't generate it if it's not there). Are there
>> any situations where we have a corresponding pph file, but don't
>> actually want to use it when the fpph-map flag is on? Seems unlikely
>> as we put all the pph files in the pph map for now anyways...
>
> Headers include other headers.  We are not generating PPH for all headers.
>
> The mapping file also allows us to control what happens when
> generating a PPH file that emits #include directives itself.  Some of
> those we want to have referenced as PPH, but not all.
>
> It's really easier for us to remember to update the mapping file
> rather than adding some automatic detection that would have to be
> removed later.

Ok I agree, temporary flags and map files are better then temporary
code for the implementation phase.

LGTM,
Gab

>
> Diego.
>

[google] Do not execute pass_warn_function_return after a syntax error (issue4629076)

[Diego Novillo]

This patch is the compromise solution for the problem described in
http://gcc.gnu.org/ml/gcc/2011-06/msg00213.html.  We should not try
to analyze the IL in the presence of syntax errors.

The full solution is simpler, but it changes diagnostic behaviour too
much for the release branch, so this patch simply stops the faulty
function return analysis from running.

Tested on x86_64.  Committed to google/gcc-4_6.


Diego.

ChangeLog.google-4_6
2011-06-27  Diego Novillo  

Google ref 4487457.

* tree-cfg.c (gate_warn_function_return): New.
(pass_warn_function_return): Use it.

testsuite/ChangeLog.google-4_6
2011-06-27   Diego Novillo  

Google ref 4487457.

* g++.dg/parse/cascading-errors.C: New.
* g++.old-deja/g++.jason/report.C: Remove expected reachability
warnings.

Index: gcc/testsuite/g++.old-deja/g++.jason/report.C
===
--- gcc/testsuite/g++.old-deja/g++.jason/report.C   (revision 175523)
+++ gcc/testsuite/g++.old-deja/g++.jason/report.C   (working copy)
@@ -72,6 +72,3 @@ int darg (char X::*p)
 {
undef3 (1); // { dg-error "" } implicit declaration
 }  // { dg-warning "no return statement" }
-
-// { dg-message "warning: control reaches end of non-void function" "" { 
target *-*-* } 36 }
-// { dg-message "warning: control reaches end of non-void function" "" { 
target *-*-* } 65 }
Index: gcc/testsuite/g++.dg/parse/cascading-errors.C
===
--- gcc/testsuite/g++.dg/parse/cascading-errors.C   (revision 0)
+++ gcc/testsuite/g++.dg/parse/cascading-errors.C   (revision 0)
@@ -0,0 +1,34 @@
+// { dg-do compile }
+// { dg-options "-Wall -Werror" }
+// a.cc:11:3: error: 'B::B' names the constructor, not the type
+// a.cc:11:8: error: expected ';' before 'f'
+// a.cc:11:13: error: statement cannot resolve address of overloaded function
+// a.cc:18:1: error: control reaches end of non-void function 
[-Werror=return-type]
+ 
+
+// After a parsing error, the IL ends up in an inconsistent state.
+// In this case, the parser never adds destructor calls, which causes
+// B::~B to never be called, triggering the error 'control reaches end
+// of non-void function' from the middle end. This second error is
+// bogus and only confuses the user.
+
+int bar(int);
+
+struct B {
+B(int);
+~B() __attribute__((noreturn));
+};
+
+
+int foo(void)
+{
+  B::B f(10);  // { dg-error "names the constructor" }
+   // { dg-error "expected ';'" "" { target *-*-* } 25 }
+   // { dg-error "cannot resolve" "" { target *-*-* } 25 }
+  return 0;
+}
+
+int bar(int j)
+{
+  B(10);
+}
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 175523)
+++ gcc/tree-cfg.c  (working copy)
@@ -7445,12 +7445,28 @@ extract_true_false_edges_from_block (bas
 }
 }
 
+static bool
+gate_warn_function_return (void)
+{
+  /* FIXME - Disable this warning if there were errors upstream
+ (Google ref 4487457).  We should not even get this far down in
+ the optimization process after a syntax error in the parser.
+ However, bailing out right after parsing causes many regressions
+ in the testsuite, because tests expect more errors from the
+ compiler.
+
+ To avoid invasive changes in 4.6, the trunk variant of this fix
+ is described in http://gcc.gnu.org/ml/gcc/2011-06/msg00213.html.  */
+  return !seen_error ();
+}
+
+
 struct gimple_opt_pass pass_warn_function_return =
 {
  {
   GIMPLE_PASS,
   "*warn_function_return", /* name */
-  NULL,/* gate */
+  gate_warn_function_return,   /* gate */
   execute_warn_function_return,/* execute */
   NULL,/* sub */
   NULL,/* next */

--
This patch is available for review at http://codereview.appspot.com/4629076

Re: [pph] Add header files to pph.map (issue4639073)

[Diego Novillo]

On Mon, Jun 27, 2011 at 13:13, Gabriel Charette  wrote:
> On Mon, Jun 27, 2011 at 10:06 AM, Diego Novillo  wrote:
>> On Mon, Jun 27, 2011 at 13:01, Gabriel Charette  wrote:
>>> Couldn't we have headers look for their corresponding .pph file by
>>> default when -fpph-map is on? (especially since pph.map is only
>>> temporary for the implementation phase)
>>
>> The problem is with headers that include other headers.  We want to
>> limit the generation of images to specific headers.  Given that we are
>> in this initial implementation phase, the simplest approach is to
>> remember to update pph.map.
>
> Well in what I'm proposing we only use the pph file if it was actually
> generated before (we don't generate it if it's not there). Are there
> any situations where we have a corresponding pph file, but don't
> actually want to use it when the fpph-map flag is on? Seems unlikely
> as we put all the pph files in the pph map for now anyways...

Headers include other headers.  We are not generating PPH for all headers.

The mapping file also allows us to control what happens when
generating a PPH file that emits #include directives itself.  Some of
those we want to have referenced as PPH, but not all.

It's really easier for us to remember to update the mapping file
rather than adding some automatic detection that would have to be
removed later.

Diego.

Re: [patch tree-optimization]: Try to sink type-casts for binary and/or/xor operations

[Kai Tietz]

Ups, missed to update patch.

Kai

- Original Message -
From: "Kai Tietz" 
To: "Richard Guenther" 
Cc: gcc-patches@gcc.gnu.org
Sent: Monday, June 27, 2011 7:04:04 PM
Subject: Re: [patch tree-optimization]: Try to sink type-casts for binary 
and/or/xor operations

Hi,

so I modified patch to use int_fits_type_p() for integer CST checking.  Well, 
this approach is - as discussed on IRC suboptimal - as my intial approach was 
for and-operations with precision type > precision type-x and unsigned type-x 
for constant values bigger then (type-x)~0.
But well, those we miss now by int_fits_type_p() approach, too. And also we 
miss now the cases for that type is signed and type-x is unsigned with same 
precision.

Anyway ... here is the updated patch

Regards,
Kai

- Original Message -
From: "Richard Guenther" 
To: "Kai Tietz" 
Cc: gcc-patches@gcc.gnu.org
Sent: Monday, June 27, 2011 4:08:41 PM
Subject: Re: [patch tree-optimization]: Try to sink type-casts for binary 
and/or/xor operations

On Mon, Jun 27, 2011 at 3:46 PM, Kai Tietz  wrote:
> Hello,
>
> this patch sink type conversions in forward-propagate for the following 
> patterns:
> - ((type) X) op ((type) Y): If X and Y have compatible types.
> - ((type) X) op CST: If the conversion of (type) ((type-x) CST) == CST and X 
> has integral type.
> - CST op ((type) X): If the conversion of (type) ((type-x) CST) == CST and X 
> has integral type.

See IRC comments.

> Additionally it fixes another issue shown by this type-sinking in bswap 
> detection. The bswap pattern matching algorithm goes for the first hit, and 
> not tries to seek for best hit.  So we search here two times. First for di 
> case (if present) and then for si mode case.

Please split this piece out.  I suppose either walking over stmts backwards
or simply handling __builtin_bswap in find_bswap_1 would be a better
fix than yours.

Richard.

> ChangeLog
>
> 2011-06-27  Kai Tietz  
>
>        * tree-ssa-forwprop.c (simplify_bitwise_binary): Improve
>        type sinking.
>        * tree-ssa-math-opts.c (execute_optimize_bswap): Separate
>        search for di/si mode patterns for finding widest match.
>
> Bootstrapped and regression tested for x86_64-pc-linux-gnu.  Ok for apply?
>
> Regards,
> Kai
>
Index: gcc-head/gcc/tree-ssa-forwprop.c
===
--- gcc-head.orig/gcc/tree-ssa-forwprop.c
+++ gcc-head/gcc/tree-ssa-forwprop.c
@@ -1624,30 +1624,54 @@ simplify_bitwise_binary (gimple_stmt_ite
   /* If the first argument is an SSA name that is itself a result of a
  typecast of an ADDR_EXPR to an integer, feed the ADDR_EXPR to the
  folder rather than the ssa name.  */
-  if (code == BIT_AND_EXPR
-  && TREE_CODE (arg2) == INTEGER_CST
+  if (TREE_CODE (arg2) == INTEGER_CST
   && TREE_CODE (arg1) == SSA_NAME)
 {
   gimple def = SSA_NAME_DEF_STMT (arg1);
   tree op = arg1;
+  tree opp = NULL_TREE;
+  tree folded_int = NULL_TREE;
 
-  /* ???  This looks bogus - the conversion could be truncating.  */
   if (is_gimple_assign (def)
  && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def))
  && INTEGRAL_TYPE_P (TREE_TYPE (arg1)))
{
- tree opp = gimple_assign_rhs1 (def);
+ opp = gimple_assign_rhs1 (def);
+ if (INTEGRAL_TYPE_P (opp)
+ && int_fits_type_p (arg2, TREE_TYPE (opp)))
+   folded_int = fold_convert_loc (gimple_location (stmt),
+  TREE_TYPE (opp), arg2);
+ /* ???  This looks bogus - the conversion could be truncating.  */
  if (TREE_CODE (opp) == ADDR_EXPR)
op = opp;
}
+  if (code == BIT_AND_EXPR)
+{
+ res = fold_binary_loc (gimple_location (stmt),
+BIT_AND_EXPR,
+TREE_TYPE (gimple_assign_lhs (stmt)),
+op, arg2);
+ if (res && is_gimple_min_invariant (res))
+   {
+ gimple_assign_set_rhs_from_tree (gsi, res);
+ update_stmt (stmt);
+ return true;
+   }
+   }
 
-  res = fold_binary_loc (gimple_location (stmt),
-BIT_AND_EXPR, TREE_TYPE (gimple_assign_lhs (stmt)),
-op, arg2);
-  if (res && is_gimple_min_invariant (res))
-   {
- gimple_assign_set_rhs_from_tree (gsi, res);
- update_stmt (stmt);
+  /* Convert (type) X & CST -> (type) (X & (typeof-X) CST),
+ if conversion of CST is reversible.  */
+  if (opp != NULL_TREE && folded_int != NULL_TREE)
+{
+ gimple newop;
+ tree tem = create_tmp_reg (TREE_TYPE (opp), NULL);
+ newop = gimple_build_assign_with_ops (code, tem, opp, folded_int);
+ tem = make_ssa_name (tem, newop);
+ gimple_assign_set_lhs (newop, tem);
+ gsi_insert_before (gsi, newop, GSI_SAME_STMT);
+ gimple_ass

Re: [pph] Add header files to pph.map (issue4639073)

[Gabriel Charette]

On Mon, Jun 27, 2011 at 10:06 AM, Diego Novillo  wrote:
> On Mon, Jun 27, 2011 at 13:01, Gabriel Charette  wrote:
>> Couldn't we have headers look for their corresponding .pph file by
>> default when -fpph-map is on? (especially since pph.map is only
>> temporary for the implementation phase)
>
> The problem is with headers that include other headers.  We want to
> limit the generation of images to specific headers.  Given that we are
> in this initial implementation phase, the simplest approach is to
> remember to update pph.map.

Well in what I'm proposing we only use the pph file if it was actually
generated before (we don't generate it if it's not there). Are there
any situations where we have a corresponding pph file, but don't
actually want to use it when the fpph-map flag is on? Seems unlikely
as we put all the pph files in the pph map for now anyways...

>
>> Could that also be why the small test I tried to introduce last week
>> to test the ordering of the bindings coming from the pph would pass
>> (i.e. it wouldn't use it's pph as I didn't add it to pph.map?).
>
> Yes, that's likely.
>
>
> Diego.
>

Re: [PING] [PATCH, libstdc++-v3] Add newlib specific ctype_members.cc

[Paolo Carlini]

Hi,

Ping for:
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00440.html
personally, I have only minor comments, like only 2011 as Copyright year 
for new files, and please also regtest on a gnu-linux system.


Before going ahead, however, you should send the patch also to the 
libstdc++ mailing list (this is the rule for v3 patches) and make sure 
the other maintainers don't have further comments. Wait, say, at least a 
couple of days.


Thanks,
Paolo.

PS: no regenerated files in the diffs.

Re: [pph] New test (issue4629075)

[Diego Novillo]

On Mon, Jun 27, 2011 at 13:06, Gabriel Charette  wrote:
> Just wondering why you're naming x finishing by an underscore "x_",
> this is a valid name, but just thinking it's tricky syntax, does this
> test anything more? or is it just a preference for private members?

No real reason.  Just a quick hack I was trying to compile with pph enabled.

Re: [pph] New test (issue4629075)

[Gabriel Charette]

Just wondering why you're naming x finishing by an underscore "x_",
this is a valid name, but just thinking it's tricky syntax, does this
test anything more? or is it just a preference for private members?

LGTM

On Mon, Jun 27, 2011 at 9:39 AM, Diego Novillo  wrote:
> We are very close to having the first simple C++ program working from
> a PPH image.  Adding a runnable test case.
>
> This produces assembly miscomparisons and does not link.  I'll be
> working on it this week.
>
>
> Diego.
>
>        * g++.dg/pph/x1ten-hellos.cc: New.
>        * g++.dg/pph/x1ten-hellos.h: New.
>        * g++.dg/pph/pph.map: Add x1ten-hellos.h
>
> diff --git a/gcc/testsuite/g++.dg/pph/x1ten-hellos.cc 
> b/gcc/testsuite/g++.dg/pph/x1ten-hellos.cc
> new file mode 100644
> index 000..b99d08a
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pph/x1ten-hellos.cc
> @@ -0,0 +1,12 @@
> +// { dg-do run }
> +// { dg-xfail-if "LINK ERROR" { "*-*-*" } { "-fpph-map=pph.map" } }
> +// pph asm xdiff
> +#include "x1ten-hellos.h"
> +
> +int main(void)
> +{
> +  A a;
> +  for (int i = 0; i < 10; i++)
> +    a.hello();
> +  return 0;
> +}
> diff --git a/gcc/testsuite/g++.dg/pph/x1ten-hellos.h 
> b/gcc/testsuite/g++.dg/pph/x1ten-hellos.h
> new file mode 100644
> index 000..2a53b66
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pph/x1ten-hellos.h
> @@ -0,0 +1,21 @@
> +#ifndef A_H_
> +#define A_H_
> +#include 
> +
> +class A
> +{
> +public:
> +  A() {
> +    x_ = 0;
> +    printf ("constructing\n");
> +  }
> +
> +  void hello(void) {
> +    x_++;
> +    printf ("Hello World (%d)\n", x_);
> +  }
> +
> +private:
> +  int x_;
> +};
> +#endif
> diff --git a/gcc/testsuite/g++.dg/pph/pph.map 
> b/gcc/testsuite/g++.dg/pph/pph.map
> index f0c7abd..2735af8 100644
> --- a/gcc/testsuite/g++.dg/pph/pph.map
> +++ b/gcc/testsuite/g++.dg/pph/pph.map
> @@ -38,6 +47,7 @@ x1struct0.h   x1struct0.pph
>  x1struct1.h    x1struct1.pph
>  x1struct2.h    x1struct2.pph
>  x1template.h   x1template.pph
> +x1ten-hellos.h x1ten-hellos.pph
>  x1tmplclass.h  x1tmplclass.pph
>  x1tmplfunc.h   x1tmplfunc.pph
>  x1typerefs.h   x1typerefs.pph
>
> --
> This patch is available for review at http://codereview.appspot.com/4629075
>

Re: [pph] Add header files to pph.map (issue4639073)

[Diego Novillo]

On Mon, Jun 27, 2011 at 13:01, Gabriel Charette  wrote:
> Couldn't we have headers look for their corresponding .pph file by
> default when -fpph-map is on? (especially since pph.map is only
> temporary for the implementation phase)

The problem is with headers that include other headers.  We want to
limit the generation of images to specific headers.  Given that we are
in this initial implementation phase, the simplest approach is to
remember to update pph.map.

> Could that also be why the small test I tried to introduce last week
> to test the ordering of the bindings coming from the pph would pass
> (i.e. it wouldn't use it's pph as I didn't add it to pph.map?).

Yes, that's likely.


Diego.

Re: [patch tree-optimization]: Try to sink type-casts for binary and/or/xor operations

[Kai Tietz]

Hi,

so I modified patch to use int_fits_type_p() for integer CST checking.  Well, 
this approach is - as discussed on IRC suboptimal - as my intial approach was 
for and-operations with precision type > precision type-x and unsigned type-x 
for constant values bigger then (type-x)~0.
But well, those we miss now by int_fits_type_p() approach, too. And also we 
miss now the cases for that type is signed and type-x is unsigned with same 
precision.

Anyway ... here is the updated patch

Regards,
Kai

- Original Message -
From: "Richard Guenther" 
To: "Kai Tietz" 
Cc: gcc-patches@gcc.gnu.org
Sent: Monday, June 27, 2011 4:08:41 PM
Subject: Re: [patch tree-optimization]: Try to sink type-casts for binary 
and/or/xor operations

On Mon, Jun 27, 2011 at 3:46 PM, Kai Tietz  wrote:
> Hello,
>
> this patch sink type conversions in forward-propagate for the following 
> patterns:
> - ((type) X) op ((type) Y): If X and Y have compatible types.
> - ((type) X) op CST: If the conversion of (type) ((type-x) CST) == CST and X 
> has integral type.
> - CST op ((type) X): If the conversion of (type) ((type-x) CST) == CST and X 
> has integral type.

See IRC comments.

> Additionally it fixes another issue shown by this type-sinking in bswap 
> detection. The bswap pattern matching algorithm goes for the first hit, and 
> not tries to seek for best hit.  So we search here two times. First for di 
> case (if present) and then for si mode case.

Please split this piece out.  I suppose either walking over stmts backwards
or simply handling __builtin_bswap in find_bswap_1 would be a better
fix than yours.

Richard.

> ChangeLog
>
> 2011-06-27  Kai Tietz  
>
>        * tree-ssa-forwprop.c (simplify_bitwise_binary): Improve
>        type sinking.
>        * tree-ssa-math-opts.c (execute_optimize_bswap): Separate
>        search for di/si mode patterns for finding widest match.
>
> Bootstrapped and regression tested for x86_64-pc-linux-gnu.  Ok for apply?
>
> Regards,
> Kai
>
Index: gcc-head/gcc/tree-ssa-forwprop.c
===
--- gcc-head.orig/gcc/tree-ssa-forwprop.c
+++ gcc-head/gcc/tree-ssa-forwprop.c
@@ -1624,30 +1624,53 @@ simplify_bitwise_binary (gimple_stmt_ite
   /* If the first argument is an SSA name that is itself a result of a
  typecast of an ADDR_EXPR to an integer, feed the ADDR_EXPR to the
  folder rather than the ssa name.  */
-  if (code == BIT_AND_EXPR
-  && TREE_CODE (arg2) == INTEGER_CST
+  if (TREE_CODE (arg2) == INTEGER_CST
   && TREE_CODE (arg1) == SSA_NAME)
 {
   gimple def = SSA_NAME_DEF_STMT (arg1);
   tree op = arg1;
+  tree opp = NULL_TREE;
+  tree folded_int = NULL_TREE;
 
-  /* ???  This looks bogus - the conversion could be truncating.  */
   if (is_gimple_assign (def)
  && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def))
  && INTEGRAL_TYPE_P (TREE_TYPE (arg1)))
{
- tree opp = gimple_assign_rhs1 (def);
- if (TREE_CODE (opp) == ADDR_EXPR)
+ opp = gimple_assign_rhs1 (def);
+ if (int_fits_type_p (arg2, TREE_TYPE (opp)))
+   folded_int = fold_convert_loc (gimple_location (stmt),
+  TREE_TYPE (opp), arg2);
+ /* ???  This looks bogus - the conversion could be truncating.  */
+ if (TREE_CODE (opp) == ADDR_EXPR && folded_int)
op = opp;
}
+  if (code == BIT_AND_EXPR)
+{
+ res = fold_binary_loc (gimple_location (stmt),
+BIT_AND_EXPR,
+TREE_TYPE (gimple_assign_lhs (stmt)),
+op, arg2);
+ if (res && is_gimple_min_invariant (res))
+   {
+ gimple_assign_set_rhs_from_tree (gsi, res);
+ update_stmt (stmt);
+ return true;
+   }
+   }
 
-  res = fold_binary_loc (gimple_location (stmt),
-BIT_AND_EXPR, TREE_TYPE (gimple_assign_lhs (stmt)),
-op, arg2);
-  if (res && is_gimple_min_invariant (res))
-   {
- gimple_assign_set_rhs_from_tree (gsi, res);
- update_stmt (stmt);
+  /* Convert (type) X & CST -> (type) (X & (typeof-X) CST),
+ if conversion of CST is reversible.  */
+  if (opp != NULL_TREE && folded_int != NULL_TREE)
+{
+ gimple newop;
+ tree tem = create_tmp_reg (TREE_TYPE (opp), NULL);
+ newop = gimple_build_assign_with_ops (code, tem, opp, folded_int);
+ tem = make_ssa_name (tem, newop);
+ gimple_assign_set_lhs (newop, tem);
+ gsi_insert_before (gsi, newop, GSI_SAME_STMT);
+ gimple_assign_set_rhs_with_ops_1 (gsi, NOP_EXPR,
+   tem, NULL_TREE, NULL_TREE);
+ update_stmt (gsi_stmt (*gsi));
  return true;
}
 }
@@ -1682,10 +1705,11 @@ simplify_bitwise_binary (gimple_stmt_

Re: PATCH [11/n]: Prepare x32: PR rtl-optimization/48155: Reload doesn't handle subreg properly

[Ulrich Weigand]

H.J. Lu wrote:
> On Mon, Jun 27, 2011 at 7:52 AM, Ulrich Weigand  wrote:
> > H.J. Lu wrote:
> >
> >> Given input:
> >>
> >> (plus:SI (subreg:SI (plus:DI (reg/f:DI 7 sp)
> >> =A0 =A0 =A0 =A0 =A0 =A0 (const_int 16 [0x10])) 0)
> >> =A0 =A0 (const_int -1 [0x]))
> >
> > Once again, this seems weird as legitimate address ... =A0If this really
> > can occur validly, there'll probably need to be an insn+splitter and/or
> > a secondard reload provided by the back-end to handle it.
> 
> This is the valid memory address for any instructions which
> take a memory operand under x32.  How will insn+splitter and/or
> a secondard reload help x32 here? Do I implement such a thing for
> all instructions which take a memory operand?

Well, if this *is* already accepted as valid, then I don't understand
why it is getting reloaded in the first place.

> > With your change below, it seems you're just falling through to
> > the generic gen_rtx_SET case, right? =A0 How does this help?
> >
> 
> I added ix86_simplify_base_disp to i386.c to handle such cases.

I see.  It appears that this routine is used within ix86_decompose_address,
which means that:
- addresses containing constructs as above will be accepted as valid
- the simplification will *not* be done in place in the RTL stream,
  but on the fly every time the address is looked at

This explains why just emitting a plain SET is accepted.  But if this
is the case, then the PLUS case in gen_reload should also have worked,
since the first thing it tries is just a plain SET as well:

[snip]
 The simplest approach is to try to generate such an insn and see if it
 is recognized and matches its constraints.  If so, it can be used.
[snip]
  insn = emit_insn_if_valid_for_reload (gen_rtx_SET (VOIDmode, out, in));
  if (insn)
return insn;

Can you check in your test case why this isn't accepted here?


In general, I'm wondering if it really a good idea to accept
complex non-simplified expressions like the above as valid addresses,
instead of simplifying them directly where they are generated, and
then just accepting the simplified versions.  That simplification
could occur e.g. in a secondary reload for PLUS (in those cases
where we actually require a reload), or in a legitimize_reload_address
handler (in those cases where the address can remain in place).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: [pph] Add header files to pph.map (issue4639073)

[Gabriel Charette]

Couldn't we have headers look for their corresponding .pph file by
default when -fpph-map is on? (especially since pph.map is only
temporary for the implementation phase)

I would see it like this:
if -fpph-map is not NULL:
  look for mapping in file
  if not found:
look for default mapping (i.e. replace .h by .pph and look for file)
if not found:
  use actual #include behaviour

Could that also be why the small test I tried to introduce last week
to test the ordering of the bindings coming from the pph would pass
(i.e. it wouldn't use it's pph as I didn't add it to pph.map?).

On Mon, Jun 27, 2011 at 9:21 AM, Diego Novillo  wrote:
>
> When I added these tests, I forgot to add them to pph.map, so the header
> files were being generated into an image, but not used in the second
> compilation.
>
> Most of the failures are in the form of different asm output.  There
> is one new ICE, though.
>
> Committed to branch.
>
>
> Diego.
>
>        * g++.dg/pph/pph.map: Add entries for c120060625-1.cc,
>        c1attr-warn-unused-result.cc, c1builtin-integral-1.cc,
>        c1builtin-object-size-2.cc, c1eabi1.cc, c1eabi1.h,
>        c1limits-externalid.cc, c1meteor-contest.cc, c1pr36533.cc,
>        c1pr44948-1a.cc, c1return-5.cc, and x1template.cc.
>        * g++.dg/pph/c120060625-1.cc: Adjust XFAIL patterns.
>        * g++.dg/pph/c1attr-warn-unused-result.cc: Adjust XFAIL
>        patterns.
>        * g++.dg/pph/c1builtin-integral-1.cc: Adjust XFAIL patterns.
>        * g++.dg/pph/c1builtin-object-size-2.cc: Adjust XFAIL
>        patterns.
>        * g++.dg/pph/c1eabi1.cc: Adjust XFAIL patterns.
>        * g++.dg/pph/c1eabi1.h: Adjust XFAIL patterns.
>        * g++.dg/pph/c1limits-externalid.cc: Adjust XFAIL patterns.
>        * g++.dg/pph/c1meteor-contest.cc: Adjust XFAIL patterns.
>        * g++.dg/pph/c1pr36533.cc: Adjust XFAIL patterns.
>        * g++.dg/pph/c1pr44948-1a.cc: Adjust XFAIL patterns.
>        * g++.dg/pph/c1return-5.cc: Adjust XFAIL patterns.
>        * g++.dg/pph/x1template.cc: Adjust XFAIL patterns.
>
> diff --git a/gcc/testsuite/g++.dg/pph/c120060625-1.cc 
> b/gcc/testsuite/g++.dg/pph/c120060625-1.cc
> index 05c7929..d09be39 100644
> --- a/gcc/testsuite/g++.dg/pph/c120060625-1.cc
> +++ b/gcc/testsuite/g++.dg/pph/c120060625-1.cc
> @@ -1 +1,2 @@
> +// pph asm xdiff
>  #include "c120060625-1.h"
> diff --git a/gcc/testsuite/g++.dg/pph/c1attr-warn-unused-result.cc 
> b/gcc/testsuite/g++.dg/pph/c1attr-warn-unused-result.cc
> index 921d294..da75561 100644
> --- a/gcc/testsuite/g++.dg/pph/c1attr-warn-unused-result.cc
> +++ b/gcc/testsuite/g++.dg/pph/c1attr-warn-unused-result.cc
> @@ -1,2 +1,3 @@
>  /* { dg-options "-w" } */
> +// pph asm xdiff
>  #include "c1attr-warn-unused-result.h"
> diff --git a/gcc/testsuite/g++.dg/pph/c1builtin-integral-1.cc 
> b/gcc/testsuite/g++.dg/pph/c1builtin-integral-1.cc
> index bf53219..962086c 100644
> --- a/gcc/testsuite/g++.dg/pph/c1builtin-integral-1.cc
> +++ b/gcc/testsuite/g++.dg/pph/c1builtin-integral-1.cc
> @@ -1 +1,2 @@
> +// pph asm xdiff
>  #include "c1builtin-integral-1.h"
> diff --git a/gcc/testsuite/g++.dg/pph/c1builtin-object-size-2.cc 
> b/gcc/testsuite/g++.dg/pph/c1builtin-object-size-2.cc
> index 615e7da..17fe707 100644
> --- a/gcc/testsuite/g++.dg/pph/c1builtin-object-size-2.cc
> +++ b/gcc/testsuite/g++.dg/pph/c1builtin-object-size-2.cc
> @@ -1,2 +1,3 @@
>  /* { dg-options "-O2 -w -fpermissive" } */
> +// pph asm xdiff
>  #include "c1builtin-object-size-2.h"
> diff --git a/gcc/testsuite/g++.dg/pph/c1eabi1.cc 
> b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
> index b2e9b11..07a3a8b 100644
> --- a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
> +++ b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
> @@ -1,3 +1,4 @@
> +// { dg-timeout 2 { target *-*-* } }
>  // { dg-options "-w -fpermissive" }
>  // pph asm xdiff
>
> diff --git a/gcc/testsuite/g++.dg/pph/c1eabi1.h 
> b/gcc/testsuite/g++.dg/pph/c1eabi1.h
> index 5f5b593..383b752 100644
> --- a/gcc/testsuite/g++.dg/pph/c1eabi1.h
> +++ b/gcc/testsuite/g++.dg/pph/c1eabi1.h
> @@ -1,4 +1,6 @@
>  // { dg-options "-w -fpermissive" }
> +// FIXME pph - Enabling PPH for this file causes memory problems in cc1plus.
> +// c1eabi1.h   c1eabi1.pph
>
>  #ifndef __PPH_GUARD_H
>  #define __PPH_GUARD_H
> diff --git a/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc 
> b/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc
> index 8b5039c..8d2da40 100644
> --- a/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc
> +++ b/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc
> @@ -1 +1,2 @@
> +// pph asm xdiff
>  #include "c1limits-externalid.h"
> diff --git a/gcc/testsuite/g++.dg/pph/c1meteor-contest.cc 
> b/gcc/testsuite/g++.dg/pph/c1meteor-contest.cc
> index bb097ac..58d2c89 100644
> --- a/gcc/testsuite/g++.dg/pph/c1meteor-contest.cc
> +++ b/gcc/testsuite/g++.dg/pph/c1meteor-contest.cc
> @@ -1,2 +1,4 @@
> +/* { dg-timeout 5 { target *-*-* } }  */
> +// { dg-xfail-if "INFINITE" { "*-*-*" } { "-fpph-map=pph.map" } }
>  /* { dg-options "-w" }  */
>  #include "c

Re: [Patch, AVR]: AVR backend cleanup: use elfos.h

[Denis Chertykov]

2011/6/27 Georg-Johann Lay :
> This patch removes ELF dependencies from avr.h and redundancies from
> avr.h and avr.c
>
> The AVR BE defines many things that are readily available in elfos.h.
> ELF is the only target supported by avr-gcc.
>
> The patch includes elfos.h in config.gcc for all avr* targets together
> with a new file avr/elf.h.
>
> ELF for avr deviates in some points from elfos.h. The needed overrides
> are defined in avr/elf.h.  avr/elf.h is included after elfos.h because
> that is the only way to achieve the needed overrides/undefs.
>
> The patch removes some hundreds lines from the AVR BE which are
> redundant, and the new avr/elf.h makes it much clearer what the actual
> deviations to default ELF implementation are.
>
> Some overrides like that there is no .ident emitted by avr presumably
> have just historical reasons; anyway the patch tries to be neutral
> compared to the present implementation.
>
> Same applies for other defines like READONLY_DATA_SECTION_ASM_OP:
> .rodata is mapped to .data by avr ldscripts anyway, so there is
> actually no need to set readonly_data_section = data_section and
> merging of STRING_CST could save some space.
>
> For zeroes memory the patch will emit
>   .zero N
> instead of
>   .skip N,0
>
> Tested without regressions and asm-output diffed for real-world avr-code.
>
> Johann
>        * config.gcc (tm_file): Add elfos.h and avr/elf.h for
>        avr-*-* and avr-*-rtems* targets.
>
>        * config/avr/elf.h: New file.
>        (ASM_OUTPUT_BEFORE_CASE_LABEL): Define.
>        (TARGET_ASM_SELECT_SECTION): Define.
>        (INIT_SECTION_ASM_OP): Undefine.
>        (FINI_SECTION_ASM_OP): Undefine.
>        (IDENT_ASM_OP): Undefine.
>        (ASM_OUTPUT_IDENT): Undefine.
>        (READONLY_DATA_SECTION_ASM_OP): Undefine.
>        (PCC_BITFIELD_TYPE_MATTERS): Undefine.
>        (TARGET_HAVE_SWITCHABLE_BSS_SECTIONS): Undefine.
>        * config/avr/avr.h:
>        (PREFERRED_DEBUGGING_TYPE): Move to elf.h.
>        (TARGET_ASM_NAMED_SECTION): Move to elf.h.
>        (MAX_OFILE_ALIGNMENT): Move to elf.h.
>        (STRING_LIMIT): Move to elf.h.
>        (ASM_DECLARE_FUNCTION_NAME): Move to elf.h.
>        (ASM_DECLARE_OBJECT_NAME): Remove.
>        (ESCAPES): Remove.
>        (ASM_OUTPUT_SKIP): Remove.
>        (DWARF2_DEBUGGING_INFO): Remove.
>        (OBJECT_FORMAT_ELF): Remove.
>        (USER_LABEL_PREFIX): Remove.
>        (ASM_OUTPUT_EXTERNAL): Remove.
>        (ASM_OUTPUT_ASCII): Remove.
>        (TYPE_ASM_OP): Remove.
>        (SIZE_ASM_OP): Remove.
>        (WEAK_ASM_OP): Remove.
>        (STRING_ASM_OP): Remove.
>        (SET_ASM_OP): Remove.
>        (ASM_WEAKEN_LABEL): Remove.
>        (TYPE_OPERAND_FMT): Remove.
>        (ASM_DECLARE_FUNCTION_SIZE): Remove.
>        (ASM_FINISH_DECLARE_OBJECT): Remove.
>        (NO_DOLLAR_IN_LABEL): Remove.
>        (ASM_GENERATE_INTERNAL_LABEL): Remove.
>        (ASM_OUTPUT_CASE_LABEL): Remove.
>        * config/avr/avr.c (avr_asm_output_aligned_decl_common): Use
>        ASM_OUTPUT_ALIGNED_LOCAL, ASM_OUTPUT_ALIGNED_COMMON.
>        (gas_output_ascii): Remove.
>        (gas_output_limited_string): Remove.
>        (TARGET_ASM_FILE_START_FILE_DIRECTIVE): Remove.
>        * config/avr/avr-protos.h
>        (gas_output_ascii): Remove prototye.
>        (gas_output_limited_string): Remove prototype.
>

Approved.

Denis.

Re: Unreviewed build/libgcc, mudflap patches

[Iain Sandoe]

Hi Rainer,

On 27 Jun 2011, at 12:32, Rainer Orth wrote:


The following three patches have remained unreviewed for a week:

[build] Move unwinder to toplevel libgcc
   http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html

This needs at least a build and/or libgcc maintainer, though a global
reviewer might be helpful.  I'm not Cc'ing the various affected target
or runtime library maintainers here, though unfortunately none of them
has commented in any way ;-(


As far as Darwin is concerned, there do not appear to be any problems.

The patch bootstraps on *-darwin9 and x86_64-darwin10 and reg-tested  
on i686-darwin9 with no issues.


having said this .. I can neither approve nor reject the patch ;-)

===

If you get as far as pushing the .ver files around, then I have some  
tidy-ups I'd like to incorporate (particularly with respect to gcc/ 
libgcc-libsystem.ver which is in a funny place, and contains extra  
symbols that are only used AFAIK by x86 darwin10).


Iain

Re: [PATCH] __builtin_assume_aligned

[Jakub Jelinek]

On Mon, Jun 27, 2011 at 12:17:40PM +0200, Richard Guenther wrote:
> Ok if you remove the builtins.c folding and instead verify arguments
> from check_builtin_function_arguments.

Thanks, here is what I've committed after bootstrapping/regtesting
again on x86_64-linux and i686-linux.

2011-06-27  Jakub Jelinek  

* builtin-types.def (BT_FN_PTR_CONST_PTR_SIZE_VAR): New.
* builtins.def (BUILT_IN_ASSUME_ALIGNED): New builtin.
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call,
find_func_clobbers): Handle BUILT_IN_ASSUME_ALIGNED.
* tree-ssa-ccp.c (bit_value_assume_aligned): New function.
(evaluate_stmt, execute_fold_all_builtins): Handle
BUILT_IN_ASSUME_ALIGNED.
* tree-ssa-dce.c (propagate_necessity): Likewise.
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1,
call_may_clobber_ref_p_1): Likewise.
* builtins.c (is_simple_builtin, expand_builtin): Likewise.
(expand_builtin_assume_aligned): New function.
* doc/extend.texi (__builtin_assume_aligned): Document.

* c-common.c (check_builtin_function_arguments): Handle
BUILT_IN_ASSUME_ALIGNED.

* gcc.dg/builtin-assume-aligned-1.c: New test.
* gcc.dg/builtin-assume-aligned-2.c: New test.
* gcc.target/i386/builtin-assume-aligned-1.c: New test.

--- gcc/builtin-types.def.jj2011-06-26 09:55:16.0 +0200
+++ gcc/builtin-types.def   2011-06-27 15:08:12.0 +0200
@@ -454,6 +454,8 @@ DEF_FUNCTION_TYPE_VAR_2 (BT_FN_INT_CONST
 BT_INT, BT_CONST_STRING, BT_CONST_STRING)
 DEF_FUNCTION_TYPE_VAR_2 (BT_FN_INT_INT_CONST_STRING_VAR,
 BT_INT, BT_INT, BT_CONST_STRING)
+DEF_FUNCTION_TYPE_VAR_2 (BT_FN_PTR_CONST_PTR_SIZE_VAR, BT_PTR,
+BT_CONST_PTR, BT_SIZE)
 
 DEF_FUNCTION_TYPE_VAR_3 (BT_FN_INT_STRING_SIZE_CONST_STRING_VAR,
 BT_INT, BT_STRING, BT_SIZE, BT_CONST_STRING)
--- gcc/builtins.def.jj 2011-06-26 09:55:16.0 +0200
+++ gcc/builtins.def2011-06-27 15:08:12.0 +0200
@@ -1,7 +1,7 @@
 /* This file contains the definitions and documentation for the
builtins used in the GNU compiler.
Copyright (C) 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
-   2010 Free Software Foundation, Inc.
+   2010, 2011 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -638,6 +638,7 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_EXE
 DEF_EXT_LIB_BUILTIN(BUILT_IN_EXECVE, "execve", 
BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING, ATTR_NOTHROW_LIST)
 DEF_LIB_BUILTIN(BUILT_IN_EXIT, "exit", BT_FN_VOID_INT, 
ATTR_NORETURN_NOTHROW_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_EXPECT, "expect", BT_FN_LONG_LONG_LONG, 
ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_GCC_BUILTIN(BUILT_IN_ASSUME_ALIGNED, "assume_aligned", 
BT_FN_PTR_CONST_PTR_SIZE_VAR, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_EXTEND_POINTER, "extend_pointer", 
BT_FN_UNWINDWORD_PTR, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_EXTRACT_RETURN_ADDR, "extract_return_addr", 
BT_FN_PTR_PTR, ATTR_LEAF_LIST)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_FFS, "ffs", BT_FN_INT_INT, 
ATTR_CONST_NOTHROW_LEAF_LIST)
--- gcc/tree-ssa-structalias.c.jj   2011-06-26 09:55:16.0 +0200
+++ gcc/tree-ssa-structalias.c  2011-06-27 15:08:12.0 +0200
@@ -4002,6 +4002,7 @@ find_func_aliases_for_builtin_call (gimp
   case BUILT_IN_STPCPY_CHK:
   case BUILT_IN_STRCAT_CHK:
   case BUILT_IN_STRNCAT_CHK:
+  case BUILT_IN_ASSUME_ALIGNED:
{
  tree res = gimple_call_lhs (t);
  tree dest = gimple_call_arg (t, (DECL_FUNCTION_CODE (fndecl)
@@ -4726,6 +4727,7 @@ find_func_clobbers (gimple origt)
  return;
}
  /* The following functions neither read nor clobber memory.  */
+ case BUILT_IN_ASSUME_ALIGNED:
  case BUILT_IN_FREE:
return;
  /* Trampolines are of no interest to us.  */
--- gcc/tree-ssa-ccp.c.jj   2011-06-26 09:55:16.0 +0200
+++ gcc/tree-ssa-ccp.c  2011-06-27 15:08:12.0 +0200
@@ -1476,6 +1476,64 @@ bit_value_binop (enum tree_code code, tr
   return val;
 }
 
+/* Return the propagation value when applying __builtin_assume_aligned to
+   its arguments.  */
+
+static prop_value_t
+bit_value_assume_aligned (gimple stmt)
+{
+  tree ptr = gimple_call_arg (stmt, 0), align, misalign = NULL_TREE;
+  tree type = TREE_TYPE (ptr);
+  unsigned HOST_WIDE_INT aligni, misaligni = 0;
+  prop_value_t ptrval = get_value_for_expr (ptr, true);
+  prop_value_t alignval;
+  double_int value, mask;
+  prop_value_t val;
+  if (ptrval.lattice_val == UNDEFINED)
+return ptrval;
+  gcc_assert ((ptrval.lattice_val == CONSTANT
+  && TREE_CODE (ptrval.value) == INTEGER_CST)
+ || double_int_minus_one_p (ptrval.mask));
+  align = gimple_call_arg (stmt, 1);
+  if (!host_integerp (align, 1))
+re

Re: [PATCH] Use TYPE_NEXT_VARIANT instead of TREE_CHAIN as chain_next for types during GC (PR c++/46400)

[Richard Henderson]

On 06/27/2011 09:42 AM, Jakub Jelinek wrote:
> 2011-06-27  Jakub Jelinek  
> 
>   * c-common.h (c_tree_chain_next): New static inline function.
> 
>   * c-decl.c (union lang_tree_node): Use it in chain_next expression.
> 
>   * cp-tree.h (union lang_tree_node): Use it in chain_next expression.

Ok.  Thanks.

r~

[committed] Fix promote_debug_loc (PR debug/49544)

[Jakub Jelinek]

Hi!

When I've added adding subregs of wider value to cselib_lookup_1
in http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174508, I've mistakenly
only adjusted the assertion, while we need in that case to adjust
the second location's setting_insn as well.

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

2011-06-27  Jakub Jelinek  

PR debug/49544
* cselib.c (promote_debug_loc): If cselib_preserve_constants
and l has two DEBUG_INSN owned locs instead of just one, adjust
the second location's setting_insn too.

* gcc.dg/pr49544.c: New test.

--- gcc/cselib.c.jj 2011-06-27 11:21:17.0 +0200
+++ gcc/cselib.c2011-06-27 13:34:11.0 +0200
@@ -257,7 +257,15 @@ promote_debug_loc (struct elt_loc_list *
 {
   n_debug_values--;
   l->setting_insn = cselib_current_insn;
-  gcc_assert (!l->next || cselib_preserve_constants);
+  if (cselib_preserve_constants && l->next)
+   {
+ gcc_assert (l->next->setting_insn
+ && DEBUG_INSN_P (l->next->setting_insn)
+ && !l->next->next);
+ l->next->setting_insn = cselib_current_insn;
+   }
+  else
+   gcc_assert (!l->next);
 }
 }
 
--- gcc/testsuite/gcc.dg/pr49544.c.jj   2011-06-27 15:00:33.0 +0200
+++ gcc/testsuite/gcc.dg/pr49544.c  2011-06-27 15:00:13.0 +0200
@@ -0,0 +1,19 @@
+/* PR debug/49544 */
+/* { dg-do compile } */
+/* { dg-options "-g -O2" } */
+
+int baz (int, int, void *);
+
+static inline __attribute__ ((always_inline)) long
+foo (int x, int y, void *z)
+{
+  if (y < 0)
+return baz (x, y, z);
+  return 0;
+}
+
+long
+bar (long x, long y, long z)
+{
+  return foo (x, y, (void *) z);
+}

Jakub

[Patch, AVR]: AVR backend cleanup: use elfos.h

[Georg-Johann Lay]

This patch removes ELF dependencies from avr.h and redundancies from
avr.h and avr.c

The AVR BE defines many things that are readily available in elfos.h.
ELF is the only target supported by avr-gcc.

The patch includes elfos.h in config.gcc for all avr* targets together
with a new file avr/elf.h.

ELF for avr deviates in some points from elfos.h. The needed overrides
are defined in avr/elf.h.  avr/elf.h is included after elfos.h because
that is the only way to achieve the needed overrides/undefs.

The patch removes some hundreds lines from the AVR BE which are
redundant, and the new avr/elf.h makes it much clearer what the actual
deviations to default ELF implementation are.

Some overrides like that there is no .ident emitted by avr presumably
have just historical reasons; anyway the patch tries to be neutral
compared to the present implementation.

Same applies for other defines like READONLY_DATA_SECTION_ASM_OP:
.rodata is mapped to .data by avr ldscripts anyway, so there is
actually no need to set readonly_data_section = data_section and
merging of STRING_CST could save some space.

For zeroes memory the patch will emit
   .zero N
instead of
   .skip N,0

Tested without regressions and asm-output diffed for real-world avr-code.

Johann
* config.gcc (tm_file): Add elfos.h and avr/elf.h for
avr-*-* and avr-*-rtems* targets.

* config/avr/elf.h: New file.
(ASM_OUTPUT_BEFORE_CASE_LABEL): Define.
(TARGET_ASM_SELECT_SECTION): Define.
(INIT_SECTION_ASM_OP): Undefine.
(FINI_SECTION_ASM_OP): Undefine.
(IDENT_ASM_OP): Undefine.
(ASM_OUTPUT_IDENT): Undefine.
(READONLY_DATA_SECTION_ASM_OP): Undefine.
(PCC_BITFIELD_TYPE_MATTERS): Undefine.
(TARGET_HAVE_SWITCHABLE_BSS_SECTIONS): Undefine.
* config/avr/avr.h:
(PREFERRED_DEBUGGING_TYPE): Move to elf.h.
(TARGET_ASM_NAMED_SECTION): Move to elf.h.
(MAX_OFILE_ALIGNMENT): Move to elf.h.
(STRING_LIMIT): Move to elf.h.
(ASM_DECLARE_FUNCTION_NAME): Move to elf.h.
(ASM_DECLARE_OBJECT_NAME): Remove.
(ESCAPES): Remove.
(ASM_OUTPUT_SKIP): Remove.
(DWARF2_DEBUGGING_INFO): Remove.
(OBJECT_FORMAT_ELF): Remove.
(USER_LABEL_PREFIX): Remove.
(ASM_OUTPUT_EXTERNAL): Remove.
(ASM_OUTPUT_ASCII): Remove.
(TYPE_ASM_OP): Remove.
(SIZE_ASM_OP): Remove.
(WEAK_ASM_OP): Remove.
(STRING_ASM_OP): Remove.
(SET_ASM_OP): Remove.
(ASM_WEAKEN_LABEL): Remove.
(TYPE_OPERAND_FMT): Remove.
(ASM_DECLARE_FUNCTION_SIZE): Remove.
(ASM_FINISH_DECLARE_OBJECT): Remove.
(NO_DOLLAR_IN_LABEL): Remove.
(ASM_GENERATE_INTERNAL_LABEL): Remove.
(ASM_OUTPUT_CASE_LABEL): Remove.
* config/avr/avr.c (avr_asm_output_aligned_decl_common): Use
ASM_OUTPUT_ALIGNED_LOCAL, ASM_OUTPUT_ALIGNED_COMMON.
(gas_output_ascii): Remove.
(gas_output_limited_string): Remove.
(TARGET_ASM_FILE_START_FILE_DIRECTIVE): Remove.
* config/avr/avr-protos.h
(gas_output_ascii): Remove prototye.
(gas_output_limited_string): Remove prototype.


Index: config.gcc
===
--- config.gcc	(revision 175372)
+++ config.gcc	(working copy)
@@ -933,13 +933,13 @@ arm*-wince-pe*)
 	extra_objs="pe.o"
 	;;
 avr-*-rtems*)
-	tm_file="avr/avr.h dbxelf.h avr/rtems.h rtems.h newlib-stdint.h"
+	tm_file="elfos.h avr/elf.h avr/avr.h dbxelf.h avr/rtems.h rtems.h newlib-stdint.h"
 	tmake_file="avr/t-avr t-rtems avr/t-rtems"
 	extra_gcc_objs="driver-avr.o avr-devices.o"
 	extra_objs="avr-devices.o"
 	;;
 avr-*-*)
-	tm_file="avr/avr.h dbxelf.h newlib-stdint.h"
+	tm_file="elfos.h avr/elf.h avr/avr.h dbxelf.h newlib-stdint.h"
 	use_gcc_stdint=wrap
 	extra_gcc_objs="driver-avr.o avr-devices.o"
 	extra_objs="avr-devices.o"
Index: config/avr/elf.h
===
--- config/avr/elf.h	(revision 0)
+++ config/avr/elf.h	(revision 0)
@@ -0,0 +1,61 @@
+/* Copyright (C) 2011
+   Free Software Foundation, Inc.
+   Contributed by Georg-Johann Lay (a...@gjlay.de)
+
+   This file is part of GCC.
+
+   GCC 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.
+   
+   GCC 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 GCC; see the file COPYING3.  If not see
+   .  */
+
+
+/* Overriding some definitions from elfos.h for AVR.  */
+
+#undef PCC_BITFIELD

Re: [PATCH] Use TYPE_NEXT_VARIANT instead of TREE_CHAIN as chain_next for types during GC (PR c++/46400)

[Jakub Jelinek]

On Fri, Jun 24, 2011 at 03:21:07PM -0700, Richard Henderson wrote:
> On 06/24/2011 07:43 AM, Jakub Jelinek wrote:
> > +   chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), 
> > TS_TYPE_COMMON) ? ((union lang_tree_node *) TYPE_NEXT_VARIANT 
> > (&%h.generic)) : CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), TS_COMMON) 
> > ? ((union lang_tree_node *) TREE_CHAIN (&%h.generic)) : NULL"))) 
> > lang_tree_node {
> 
> Is it possible to break this out into an inline (or, i suppose, out of line)
> function?  This is getting fairly unreadable...

Like this?  Bootstrapped/regtested on x86_64-linux and i686-linux.

2011-06-27  Jakub Jelinek  

* c-common.h (c_tree_chain_next): New static inline function.

* c-decl.c (union lang_tree_node): Use it in chain_next expression.

* cp-tree.h (union lang_tree_node): Use it in chain_next expression.

--- gcc/c-family/c-common.h.jj  2011-05-31 08:02:51.0 +0200
+++ gcc/c-family/c-common.h 2011-06-27 15:58:21.0 +0200
@@ -1016,4 +1016,19 @@ extern bool c_omp_sharing_predetermined 
 extern tree c_omp_remap_decl (tree, bool);
 extern void record_types_used_by_current_var_decl (tree);
 
+/* Return next tree in the chain for chain_next walking of tree nodes.  */
+static inline tree
+c_tree_chain_next (tree t)
+{
+  /* TREE_CHAIN of a type is TYPE_STUB_DECL, which is different
+ kind of object, never a long chain of nodes.  Prefer
+ TYPE_NEXT_VARIANT for types.  */
+  if (CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_TYPE_COMMON))
+return TYPE_NEXT_VARIANT (t);
+  /* Otherwise, if there is TREE_CHAIN, return it.  */
+  if (CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_COMMON))
+return TREE_CHAIN (t);
+  return NULL;
+}
+
 #endif /* ! GCC_C_COMMON_H */
--- gcc/c-decl.c.jj 2011-06-26 09:55:31.0 +0200
+++ gcc/c-decl.c2011-06-27 16:00:18.0 +0200
@@ -238,7 +238,7 @@ extern char C_SIZEOF_STRUCT_LANG_IDENTIF
 /* The resulting tree type.  */
 
 union GTY((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"),
-   chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), 
TS_TYPE_COMMON) ? (union lang_tree_node *) TYPE_NEXT_VARIANT (&%h.generic) : 
CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), TS_COMMON) ? ((union 
lang_tree_node *) TREE_CHAIN (&%h.generic)) : NULL")))  lang_tree_node
+   chain_next ("(union lang_tree_node *) c_tree_chain_next 
(&%h.generic)"))) lang_tree_node
  {
   union tree_node GTY ((tag ("0"),
desc ("tree_node_structure (&%h)")))
--- gcc/cp/cp-tree.h.jj 2011-06-26 09:55:24.0 +0200
+++ gcc/cp/cp-tree.h2011-06-27 16:01:09.0 +0200
@@ -729,7 +729,7 @@ enum cp_tree_node_structure_enum {
 
 /* The resulting tree type.  */
 union GTY((desc ("cp_tree_node_structure (&%h)"),
-   chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), 
TS_TYPE_COMMON) ? ((union lang_tree_node *) TYPE_NEXT_VARIANT (&%h.generic)) : 
CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), TS_COMMON) ? ((union 
lang_tree_node *) TREE_CHAIN (&%h.generic)) : NULL"))) lang_tree_node {
+   chain_next ("(union lang_tree_node *) c_tree_chain_next 
(&%h.generic)"))) lang_tree_node {
   union tree_node GTY ((tag ("TS_CP_GENERIC"),
desc ("tree_node_structure (&%h)"))) generic;
   struct template_parm_index_s GTY ((tag ("TS_CP_TPI"))) tpi;


Jakub

[pph] New test (issue4629075)

[Diego Novillo]

We are very close to having the first simple C++ program working from
a PPH image.  Adding a runnable test case.

This produces assembly miscomparisons and does not link.  I'll be
working on it this week.


Diego.

* g++.dg/pph/x1ten-hellos.cc: New.
* g++.dg/pph/x1ten-hellos.h: New.
* g++.dg/pph/pph.map: Add x1ten-hellos.h

diff --git a/gcc/testsuite/g++.dg/pph/x1ten-hellos.cc 
b/gcc/testsuite/g++.dg/pph/x1ten-hellos.cc
new file mode 100644
index 000..b99d08a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pph/x1ten-hellos.cc
@@ -0,0 +1,12 @@
+// { dg-do run }
+// { dg-xfail-if "LINK ERROR" { "*-*-*" } { "-fpph-map=pph.map" } }
+// pph asm xdiff
+#include "x1ten-hellos.h"
+
+int main(void)
+{
+  A a;
+  for (int i = 0; i < 10; i++)
+a.hello();
+  return 0;
+}
diff --git a/gcc/testsuite/g++.dg/pph/x1ten-hellos.h 
b/gcc/testsuite/g++.dg/pph/x1ten-hellos.h
new file mode 100644
index 000..2a53b66
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pph/x1ten-hellos.h
@@ -0,0 +1,21 @@
+#ifndef A_H_
+#define A_H_
+#include 
+
+class A
+{
+public:
+  A() {
+x_ = 0;
+printf ("constructing\n");
+  }
+
+  void hello(void) {
+x_++;
+printf ("Hello World (%d)\n", x_);
+  }
+
+private:
+  int x_;
+};
+#endif
diff --git a/gcc/testsuite/g++.dg/pph/pph.map b/gcc/testsuite/g++.dg/pph/pph.map
index f0c7abd..2735af8 100644
--- a/gcc/testsuite/g++.dg/pph/pph.map
+++ b/gcc/testsuite/g++.dg/pph/pph.map
@@ -38,6 +47,7 @@ x1struct0.h   x1struct0.pph
 x1struct1.hx1struct1.pph
 x1struct2.hx1struct2.pph
 x1template.h   x1template.pph
+x1ten-hellos.h x1ten-hellos.pph
 x1tmplclass.h  x1tmplclass.pph
 x1tmplfunc.h   x1tmplfunc.pph
 x1typerefs.h   x1typerefs.pph

--
This patch is available for review at http://codereview.appspot.com/4629075

[pph] Add header files to pph.map (issue4639073)

[Diego Novillo]

When I added these tests, I forgot to add them to pph.map, so the header
files were being generated into an image, but not used in the second
compilation.

Most of the failures are in the form of different asm output.  There
is one new ICE, though.

Committed to branch.


Diego.

* g++.dg/pph/pph.map: Add entries for c120060625-1.cc,
c1attr-warn-unused-result.cc, c1builtin-integral-1.cc,
c1builtin-object-size-2.cc, c1eabi1.cc, c1eabi1.h,
c1limits-externalid.cc, c1meteor-contest.cc, c1pr36533.cc,
c1pr44948-1a.cc, c1return-5.cc, and x1template.cc.
* g++.dg/pph/c120060625-1.cc: Adjust XFAIL patterns.
* g++.dg/pph/c1attr-warn-unused-result.cc: Adjust XFAIL
patterns.
* g++.dg/pph/c1builtin-integral-1.cc: Adjust XFAIL patterns.
* g++.dg/pph/c1builtin-object-size-2.cc: Adjust XFAIL
patterns.
* g++.dg/pph/c1eabi1.cc: Adjust XFAIL patterns.
* g++.dg/pph/c1eabi1.h: Adjust XFAIL patterns.
* g++.dg/pph/c1limits-externalid.cc: Adjust XFAIL patterns.
* g++.dg/pph/c1meteor-contest.cc: Adjust XFAIL patterns.
* g++.dg/pph/c1pr36533.cc: Adjust XFAIL patterns.
* g++.dg/pph/c1pr44948-1a.cc: Adjust XFAIL patterns.
* g++.dg/pph/c1return-5.cc: Adjust XFAIL patterns.
* g++.dg/pph/x1template.cc: Adjust XFAIL patterns.

diff --git a/gcc/testsuite/g++.dg/pph/c120060625-1.cc 
b/gcc/testsuite/g++.dg/pph/c120060625-1.cc
index 05c7929..d09be39 100644
--- a/gcc/testsuite/g++.dg/pph/c120060625-1.cc
+++ b/gcc/testsuite/g++.dg/pph/c120060625-1.cc
@@ -1 +1,2 @@
+// pph asm xdiff
 #include "c120060625-1.h"
diff --git a/gcc/testsuite/g++.dg/pph/c1attr-warn-unused-result.cc 
b/gcc/testsuite/g++.dg/pph/c1attr-warn-unused-result.cc
index 921d294..da75561 100644
--- a/gcc/testsuite/g++.dg/pph/c1attr-warn-unused-result.cc
+++ b/gcc/testsuite/g++.dg/pph/c1attr-warn-unused-result.cc
@@ -1,2 +1,3 @@
 /* { dg-options "-w" } */
+// pph asm xdiff
 #include "c1attr-warn-unused-result.h"
diff --git a/gcc/testsuite/g++.dg/pph/c1builtin-integral-1.cc 
b/gcc/testsuite/g++.dg/pph/c1builtin-integral-1.cc
index bf53219..962086c 100644
--- a/gcc/testsuite/g++.dg/pph/c1builtin-integral-1.cc
+++ b/gcc/testsuite/g++.dg/pph/c1builtin-integral-1.cc
@@ -1 +1,2 @@
+// pph asm xdiff
 #include "c1builtin-integral-1.h"
diff --git a/gcc/testsuite/g++.dg/pph/c1builtin-object-size-2.cc 
b/gcc/testsuite/g++.dg/pph/c1builtin-object-size-2.cc
index 615e7da..17fe707 100644
--- a/gcc/testsuite/g++.dg/pph/c1builtin-object-size-2.cc
+++ b/gcc/testsuite/g++.dg/pph/c1builtin-object-size-2.cc
@@ -1,2 +1,3 @@
 /* { dg-options "-O2 -w -fpermissive" } */
+// pph asm xdiff
 #include "c1builtin-object-size-2.h"
diff --git a/gcc/testsuite/g++.dg/pph/c1eabi1.cc 
b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
index b2e9b11..07a3a8b 100644
--- a/gcc/testsuite/g++.dg/pph/c1eabi1.cc
+++ b/gcc/testsuite/g++.dg/pph/c1eabi1.cc
@@ -1,3 +1,4 @@
+// { dg-timeout 2 { target *-*-* } }
 // { dg-options "-w -fpermissive" }
 // pph asm xdiff
 
diff --git a/gcc/testsuite/g++.dg/pph/c1eabi1.h 
b/gcc/testsuite/g++.dg/pph/c1eabi1.h
index 5f5b593..383b752 100644
--- a/gcc/testsuite/g++.dg/pph/c1eabi1.h
+++ b/gcc/testsuite/g++.dg/pph/c1eabi1.h
@@ -1,4 +1,6 @@
 // { dg-options "-w -fpermissive" }
+// FIXME pph - Enabling PPH for this file causes memory problems in cc1plus.
+// c1eabi1.h   c1eabi1.pph
 
 #ifndef __PPH_GUARD_H
 #define __PPH_GUARD_H
diff --git a/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc 
b/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc
index 8b5039c..8d2da40 100644
--- a/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc
+++ b/gcc/testsuite/g++.dg/pph/c1limits-externalid.cc
@@ -1 +1,2 @@
+// pph asm xdiff
 #include "c1limits-externalid.h"
diff --git a/gcc/testsuite/g++.dg/pph/c1meteor-contest.cc 
b/gcc/testsuite/g++.dg/pph/c1meteor-contest.cc
index bb097ac..58d2c89 100644
--- a/gcc/testsuite/g++.dg/pph/c1meteor-contest.cc
+++ b/gcc/testsuite/g++.dg/pph/c1meteor-contest.cc
@@ -1,2 +1,4 @@
+/* { dg-timeout 5 { target *-*-* } }  */
+// { dg-xfail-if "INFINITE" { "*-*-*" } { "-fpph-map=pph.map" } }
 /* { dg-options "-w" }  */
 #include "c1meteor-contest.h"
diff --git a/gcc/testsuite/g++.dg/pph/c1pr36533.cc 
b/gcc/testsuite/g++.dg/pph/c1pr36533.cc
index b44e8c9..d8d6d8c 100644
--- a/gcc/testsuite/g++.dg/pph/c1pr36533.cc
+++ b/gcc/testsuite/g++.dg/pph/c1pr36533.cc
@@ -1,2 +1,3 @@
 /* { dg-options "-w -fpermissive" } */
+// pph asm xdiff
 #include "c1pr36533.h"
diff --git a/gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc 
b/gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc
index f3f0427..d2ebd27 100644
--- a/gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc
+++ b/gcc/testsuite/g++.dg/pph/c1pr44948-1a.cc
@@ -1 +1,3 @@
+// { dg-xfail-if "INFINITE" { "*-*-*" } { "-fpph-map=pph.map" } }
+// { dg-bogus "internal compiler error: in lto_streamer_cache_get, at 
lto-streamer.c" "" { xfail *-*-* } 0 }
 #include "c1pr44948-1a.h"
diff --git a/gcc/testsuite/g++.dg/pph/c1return-5.cc 
b/gcc/testsuite

Re: Simplify Solaris configuration

[Rainer Orth]

Eric,

>> All bootstraps completed without regressions, so I've installed the
>> patch.  I'll address eventual issues and further simplifications as a
>> followup.
>
> I cannot bootstrap SPARC64/Solaris anymore though:
[...]
> from /nile.build/botcazou/gcc-head/src/libgcc/../gcc/libgcc2.c:29:
> /usr/include/sys/isa_defs.h:280:2: error: #error "SPARC Versions 8 and 9 are 
> mutually exclusive choices"
> /usr/include/sys/isa_defs.h:376:2: error: #error "Both _ILP32 and _LP64 are 
> defined"

sorry about that: I don't test the 64-bit default configurations so far,
and didn't even have the necessary support libs around to do so.  The
problem was that sparc/sol2-64.h was included too late and
DEFAULT_ARCH32_P was wrong for those configurations.

The following patch should fix this:

2011-06-27  Rainer Orth  

* config.gcc (sparc*-*-solaris2*): Move sol2-bi.h after
sparc/sol2-64.h.

diff --git a/gcc/config.gcc b/gcc/config.gcc
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2476,7 +2476,7 @@ sparc-*-netbsdelf*)
extra_options="${extra_options} sparc/long-double-switch.opt"
;;
 sparc*-*-solaris2*)
-   tm_file="sparc/biarch64.h ${tm_file} ${sol2_tm_file} sol2-bi.h"
+   tm_file="sparc/biarch64.h ${tm_file} ${sol2_tm_file}"
case ${target} in
sparc64-*-* | sparcv9-*-*)
tm_file="${tm_file} sparc/sol2-64.h"
@@ -2485,6 +2485,7 @@ sparc*-*-solaris2*)
test x$with_cpu != x || with_cpu=v9
;;
esac
+   tm_file="${tm_file} sol2-bi.h"
tmake_file="${tmake_file} sparc/t-sol2-64"
;;
 sparc-wrs-vxworks)

At least I can build the 64-bit libgcc now, but the 32-bit one fails for
unrelated reasons:

configure:3247: checking for suffix of object files
configure:3269: /var/gcc/gcc-4.7.0-20110622/11-gcc/./gcc/xgcc 
-B/var/gcc/gcc-4.7.0-20110622/11-gcc/./gcc/ 
-B/usr/local/sparcv9-sun-solaris2.11/bin/ 
-B/usr/local/sparcv9-sun-solaris2.11/lib/ -isystem 
/usr/local/sparcv9-sun-solaris2.11/include -isystem 
/usr/local/sparcv9-sun-solaris2.11/sys-include  -m32 -c -g -O2  conftest.c >&5
conftest.c:16:1: internal compiler error: in simplify_subreg, at 
simplify-rtx.c:5362

Rainer

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

[RFC] Fix full memory barrier on SPARC-V8

[Eric Botcazou]

The memory_barrier pattern expands to UNSPEC_MEMBAR on the SPARC and the latter 
is implemented differently for V8 and V9:

(define_insn "*stbar"
  [(set (match_operand:BLK 0 "" "")
(unspec:BLK [(match_dup 0)] UNSPEC_MEMBAR))]
  "TARGET_V8"
  "stbar"
  [(set_attr "type" "multi")])

;; membar #StoreStore | #LoadStore | #StoreLoad | #LoadLoad
(define_insn "*membar"
  [(set (match_operand:BLK 0 "" "")
(unspec:BLK [(match_dup 0)] UNSPEC_MEMBAR))]
  "TARGET_V9"
  "membar\t15"
  [(set_attr "type" "multi")])


This is surprising because, while membar 0x0F is a full memory barrier for V9, 
stbar isn't one for V8.  stbar is only for PSO and a nop in TSO; now TSO isn't 
Strong Consistency so there is something missing.  Geert has devised a nice 
testcase (in Ada) based on Peterson's algorithm with 4 tasks (threads) and it 
fails on a 4-CPU Solaris machine with -mcpu=v8 (Solaris is TSO).  Something 
like the attached patch is needed to make it pass.

Now the GCC implementation seems to derive from that of the kernel, which has:

/* XXX Change this if we ever use a PSO mode kernel. */
#define mb()__asm__ __volatile__ ("" : : : "memory")

in include/asm-sparc/system.h and

#define mb()\
membar_safe("#LoadLoad | #LoadStore | #StoreStore | #StoreLoad")

in include/asm-sparc64/system.h.

So mb() isn't a full memory barrier for V8 either.


* config/sparc/sync.md (*stbar): Delete.
(*membar_v8): New insn to implement UNSPEC_MEMBAR in SPARC-V8.


-- 
Eric Botcazou
Index: config/sparc/sync.md
===
--- config/sparc/sync.md	(revision 175408)
+++ config/sparc/sync.md	(working copy)
@@ -30,15 +30,20 @@ (define_expand "memory_barrier"
 {
   operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
   MEM_VOLATILE_P (operands[0]) = 1;
-
 })
 
-(define_insn "*stbar"
+;; In V8, loads are blocking and ordered wrt earlier loads, i.e. every load
+;; is virtually followed by a load barrier (membar #LoadStore | #LoadLoad).
+;; In PSO, stbar orders the stores (membar #StoreStore).
+;; In TSO, ldstub orders the stores wrt subsequent loads (membar #StoreLoad).
+;; The combination of the three yields a full memory barrier in all cases.
+(define_insn "*membar_v8"
   [(set (match_operand:BLK 0 "" "")
 	(unspec:BLK [(match_dup 0)] UNSPEC_MEMBAR))]
   "TARGET_V8"
-  "stbar"
-  [(set_attr "type" "multi")])
+  "stbar\n\tldstub\t[%%sp-1], %%g0"
+  [(set_attr "type" "multi")
+   (set_attr "length" "2")])
 
 ;; membar #StoreStore | #LoadStore | #StoreLoad | #LoadLoad
 (define_insn "*membar"

Re: varpool alias reorg

[Michael Matz]

Hi,

On Mon, 27 Jun 2011, Jan Hubicka wrote:

> > I still like to stream unmodified builtins as builtins, as that is 
> > similar to pre-loading the streamer caches with things like 
> > void_type_node or sizetype.
> 
> Doing so will need us to solve the other one decl rules probly. I didn't 
> really got what the preloading is useful for after all?

One important thing that really affects correctness which preloading does 
is to guarantee pointer equality for things like void_type_node or 
error_mark_node, which are used sometimes.  If we weren't doing preloading 
we would have to forcibly merge all these trees over different units, and 
what's worse, also fill out the global tree arrays with that merged 
variant.  And for that we'd need to note somehow which array slot a 
certain tree is coming from (and deal with the fact that different 
language frontends fill this array differently, sometimes with 
pointer-eqal tree nodes, sometimes only with semantically equal tree 
nodes, sometimes not at all).

Or we could fix all places where we use pointer equality with some of the 
global trees, which I wouldn't like, even for abstract considerations.  
There's really no point in having different but equal void_type nodes, or 
error_mark nodes.

preloading really is the easiest way to solve all this.  It's just 
important that all .o files have the same idea about "tree at slot 
so-and-so" (e.g. meaning "error_mark_node"), which I fixed some weeks ago.

And with early-debug-info we don't even then have the issue of e.g. the 
base integer types not being named like the frontend emitted them.


Ciao,
Michael.

Re: PATCH [11/n]: Prepare x32: PR rtl-optimization/48155: Reload doesn't handle subreg properly

[H.J. Lu]

On Mon, Jun 27, 2011 at 7:52 AM, Ulrich Weigand  wrote:
> H.J. Lu wrote:
>
>> Given input:
>>
>> (plus:SI (subreg:SI (plus:DI (reg/f:DI 7 sp)
>>             (const_int 16 [0x10])) 0)
>>     (const_int -1 [0x]))
>
> Once again, this seems weird as legitimate address ...  If this really
> can occur validly, there'll probably need to be an insn+splitter and/or
> a secondard reload provided by the back-end to handle it.

This is the valid memory address for any instructions which
take a memory operand under x32.  How will insn+splitter and/or
a secondard reload help x32 here? Do I implement such a thing for
all instructions which take a memory operand?

>> reloads tries to add
>>
>> (subreg:SI (plus:DI (reg/f:DI 7 sp)
>>         (const_int 16 [0x10])) 0)
>>
>> to
>>
>> (reg:SI 1 dx)
>
> And what happens then?  If the only problem is that this is then
> rejected by the back-end, I don't think we need to change anything
> in gen_reload ...
>
> With your change below, it seems you're just falling through to
> the generic gen_rtx_SET case, right?   How does this help?
>

I added ix86_simplify_base_disp to i386.c to handle such cases.
It translates

(set (reg:SI 40 r11)
(plus:SI (plus:SI (mult:SI (reg:SI 1 dx)
   (const_int 8))
  (subreg:SI (plus:DI (reg/f:DI 7 sp)
  (const_int CONST1)) 0))
 (const_int CONST2)))

  into

   (set (reg:SI 40 r11)
(plus:SI (plus:SI (mult:SI (reg:SI 1 dx)
   (const_int 8))
  (reg/f:SI 7 sp))
 (const_int [CONST1 + CONST2])))

   It also translates

   (plus:DI (zero_extend:DI (plus:SI (plus:SI (reg:SI 4 si [70])
  (reg:SI 2 cx [86]))
 (const_int CONST1)))
(const_int CONST2))

   into

   (plus:DI (zero_extend:DI (plus:SI (reg:SI 4 si [70])
 (reg:SI 2 cx [86]))
(const_int [CONST1 + CONST2])))

  It also translates

   (plus:SI (plus:SI (plus:SI (reg:SI 4 si [70])
  (reg:SI 2 cx [86]))
 (symbol_ref:SI ("A.193.2210")))
(const_int CONST))

   into

   (plus:SI (plus:SI (reg:SI 4 si [70])
 (reg:SI 2 cx [86]))
(const (plus:SI (symbol_ref:SI ("A.193.2210"))
(const_int CONST

   It aslo translates

   (set (reg:SI 40 r11)
(plus:SI (plus:SI (reg:SI 1 dx)
  (subreg:SI (plus:DI (reg/f:DI 7 sp)
  (const_int CONST1)) 0))
 (const_int CONST2)))

   into

   (set (reg:SI 40 r11)
(plus:SI (plus:SI (reg:SI 1 dx)
  (reg/f:SI 7 sp))
 (const_int [CONST1 + CONST2])))


-- 
H.J.

Re: varpool alias reorg

[Jan Hubicka]

> On Fri, 24 Jun 2011, Jan Hubicka wrote:
> 
> > Hi,
> > this is yet another variant of the fix.  This time we stream builtins decls 
> > as
> > usually, but at fixup time we copy the assembler names (if set) into the
> > builtin decls used by folders.  Not sure if it is any better than breaking
> > memops-asm, but I can imagine that things like glibc actually rename string
> > functions into their internal variants (and thus with this version of patch 
> > we
> > would be able to LTO such library, but still we won't be able to LTO such
> > library into something else because something else would end up referncing 
> > the
> > internal versions of builtins).  I doubt we could do any better, however.
> 
> Not stream builtins with adjusted assembler names (I guess we'd need
> a flag for this, DECL_USER_ASSEMBLER_NAME_SET_P?  Or just check for

Most of code just checks for '*' on begginign of assembler name. I suppose it 
is safe.

> attributes?) as builtins but as new decls.  Let lto symbol merging
> then register those as aliases.  But which way around?  probably
> similar to how we should handle re-defined extern inlines, the
> extern inline being the GCC builtin and the re-definition being
> the aliased one.

I don't quite get your answer here.  What we do now is:

 1) stream in builtin as special kind of reference with decl assembler name 
associated to it
 2) at streaming in time always resolve builtlin to the "official" builtin 
decls (no matter
 what types and other stuff builtin had at stream out time) and overwritting 
the official builtin
 assembler name into one specified.

What i suggest is

 1) Stream out builtins as usual decls just with the extra function code
 2) Stream in builtins as usually
 3) optionally set the assembler name of the "official" decl

I see there are problems with i.e. one decl rule, but we do have same problems
with normal frontends that also do use different decl for explicit builtin
calls than for implicit, sadly.

I am not quite sure what the proper fix for this problem is - it is very handy
to have builtin decl in middle end where I know it is sane (i.e. it has the
right types etc.). Since C allows to declare the builtins arbitrarily, it gets
bit tricky to preserve one decl rule here.
> 
> > __attribute__ ((used)) is still needed in memops-asm-lib.c because LTO 
> > symtab
> > of course doesn't see the future references to builtins that we will emit
> > later via folding.  I think it is resonable requirement, as discussed at the
> > time enabling the plugin.
> 
> Yes, I think the testcase fix sounds reasonable.
> 
> I suppose you can come up with a simpler testcase for this "feature"
> for gcc.dg/lto highlighting the different issues?  I'm not sure
> if we are talking about my_memcpy () alias("memcpy") or
> memcpy () alias("my_memcpy").
> 
> I still like to stream unmodified builtins as builtins, as that is
> similar to pre-loading the streamer caches with things like
> void_type_node or sizetype.

Doing so will need us to solve the other one decl rules probly.
I didn't really got what the preloading is useful for after all?

Honza

> 
> Richard.

Re: [patch tree-optimization]: Try to sink type-casts for binary and/or/xor operations

[Kai Tietz]

- Original Message -
From: "Richard Guenther" 
To: "Kai Tietz" 
Cc: gcc-patches@gcc.gnu.org
Sent: Monday, June 27, 2011 4:08:41 PM
Subject: Re: [patch tree-optimization]: Try to sink type-casts for binary 
and/or/xor operations

On Mon, Jun 27, 2011 at 3:46 PM, Kai Tietz  wrote:
> Hello,
>
> this patch sink type conversions in forward-propagate for the following 
> patterns:
> - ((type) X) op ((type) Y): If X and Y have compatible types.
> - ((type) X) op CST: If the conversion of (type) ((type-x) CST) == CST and X 
> has integral type.
> - CST op ((type) X): If the conversion of (type) ((type-x) CST) == CST and X 
> has integral type.

See IRC comments.

> Additionally it fixes another issue shown by this type-sinking in bswap 
> detection. The bswap pattern matching algorithm goes for the first hit, and 
> not tries to seek for best hit.  So we search here two times. First for di 
> case (if present) and then for si mode case.

Please split this piece out.  I suppose either walking over stmts backwards
or simply handling __builtin_bswap in find_bswap_1 would be a better
fix than yours.

Richard.

> ChangeLog
>
> 2011-06-27  Kai Tietz  
>
>        * tree-ssa-forwprop.c (simplify_bitwise_binary): Improve
>        type sinking.
>        * tree-ssa-math-opts.c (execute_optimize_bswap): Separate
>        search for di/si mode patterns for finding widest match.
>
> Bootstrapped and regression tested for x86_64-pc-linux-gnu.  Ok for apply?


Revised patch without the bswap part.

Regards,
KaiIndex: gcc-head/gcc/tree-ssa-forwprop.c
===
--- gcc-head.orig/gcc/tree-ssa-forwprop.c
+++ gcc-head/gcc/tree-ssa-forwprop.c
@@ -1624,30 +1624,56 @@ simplify_bitwise_binary (gimple_stmt_ite
   /* If the first argument is an SSA name that is itself a result of a
  typecast of an ADDR_EXPR to an integer, feed the ADDR_EXPR to the
  folder rather than the ssa name.  */
-  if (code == BIT_AND_EXPR
-  && TREE_CODE (arg2) == INTEGER_CST
+  if (TREE_CODE (arg2) == INTEGER_CST
   && TREE_CODE (arg1) == SSA_NAME)
 {
   gimple def = SSA_NAME_DEF_STMT (arg1);
   tree op = arg1;
+  tree opp = NULL_TREE;
+  tree folded_int = NULL_TREE;
 
-  /* ???  This looks bogus - the conversion could be truncating.  */
   if (is_gimple_assign (def)
  && CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def))
  && INTEGRAL_TYPE_P (TREE_TYPE (arg1)))
{
- tree opp = gimple_assign_rhs1 (def);
- if (TREE_CODE (opp) == ADDR_EXPR)
+ opp = gimple_assign_rhs1 (def);
+ folded_int = fold_convert_loc (gimple_location (stmt),
+TREE_TYPE (opp), arg2);
+ /* Check if integer value remains the same on cast back
+to original type.  */
+ if (!operand_equal_p (arg2, fold_convert (TREE_TYPE (arg1),
+   folded_int), 0))
+   folded_int = NULL_TREE;
+ if (TREE_CODE (opp) == ADDR_EXPR && folded_int)
op = opp;
}
+  if (code == BIT_AND_EXPR)
+{
+ res = fold_binary_loc (gimple_location (stmt),
+BIT_AND_EXPR,
+TREE_TYPE (gimple_assign_lhs (stmt)),
+op, arg2);
+ if (res && is_gimple_min_invariant (res))
+   {
+ gimple_assign_set_rhs_from_tree (gsi, res);
+ update_stmt (stmt);
+ return true;
+   }
+   }
 
-  res = fold_binary_loc (gimple_location (stmt),
-BIT_AND_EXPR, TREE_TYPE (gimple_assign_lhs (stmt)),
-op, arg2);
-  if (res && is_gimple_min_invariant (res))
-   {
- gimple_assign_set_rhs_from_tree (gsi, res);
- update_stmt (stmt);
+  /* Convert (type) X & CST -> (type) (X & (typeof-X) CST),
+ if conversion of CST is reversible.  */
+  if (opp != NULL_TREE && folded_int != NULL_TREE)
+{
+ gimple newop;
+ tree tem = create_tmp_reg (TREE_TYPE (opp), NULL);
+ newop = gimple_build_assign_with_ops (code, tem, opp, folded_int);
+ tem = make_ssa_name (tem, newop);
+ gimple_assign_set_lhs (newop, tem);
+ gsi_insert_before (gsi, newop, GSI_SAME_STMT);
+ gimple_assign_set_rhs_with_ops_1 (gsi, NOP_EXPR,
+   tem, NULL_TREE, NULL_TREE);
+ update_stmt (gsi_stmt (*gsi));
  return true;
}
 }
@@ -1682,10 +1708,11 @@ simplify_bitwise_binary (gimple_stmt_ite
   if (CONVERT_EXPR_CODE_P (def1_code)
   && CONVERT_EXPR_CODE_P (def2_code)
   && types_compatible_p (TREE_TYPE (def1_arg1), TREE_TYPE (def2_arg1))
-  /* Make sure that the conversion widens the operands or that it
-changes the operation to a bitfield precision.  */
+  /* Make sure that the conversion 

Re: [patch tree-optimization]: Try to sink type-casts for binary and/or/xor operations

[Kai Tietz]

2011/6/27 Richard Guenther :
> On Mon, Jun 27, 2011 at 3:46 PM, Kai Tietz  wrote:
>> Hello,
>>
>> this patch sink type conversions in forward-propagate for the following 
>> patterns:
>> - ((type) X) op ((type) Y): If X and Y have compatible types.
>> - ((type) X) op CST: If the conversion of (type) ((type-x) CST) == CST and X 
>> has integral type.
>> - CST op ((type) X): If the conversion of (type) ((type-x) CST) == CST and X 
>> has integral type.
>
> See IRC comments.

See IRC comments, too.  int_fits_type_p isn't suitable here, as for
bitwise operations and/or/xor casts to/from sign for same precision
don't matter. Nevertheless it is of course important to handle
sign-extension proper for operands with different precisions.
Eg: int foo (char c) { return ((int) c & 0xf0f); }.

>> Additionally it fixes another issue shown by this type-sinking in bswap 
>> detection. The bswap pattern matching algorithm goes for the first hit, and 
>> not tries to seek for best hit.  So we search here two times. First for di 
>> case (if present) and then for si mode case.
>
> Please split this piece out.  I suppose either walking over stmts backwards
> or simply handling __builtin_bswap in find_bswap_1 would be a better
> fix than yours.

Ok, I'll do.

> Richard.
>
>> ChangeLog
>>
>> 2011-06-27  Kai Tietz  
>>
>>        * tree-ssa-forwprop.c (simplify_bitwise_binary): Improve
>>        type sinking.
>>        * tree-ssa-math-opts.c (execute_optimize_bswap): Separate
>>        search for di/si mode patterns for finding widest match.
>>
>> Bootstrapped and regression tested for x86_64-pc-linux-gnu.  Ok for apply?

Regards,
Kai

PING Re: PATCH: fix collect2 handling of --demangle and --no-demangle

[Sandra Loosemore]

Ping?

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01368.html


We had a bug report from a customer that the linker was ignoring the
--demangle and --no-demangle options when generating map files.
Moreover, it was failing in a host-dependent way; on Windows hosts,
it was always emitting demangled names in the map file, while on
Linux hosts, it never did.  Moreover, on Windows hosts it also
ignored the setting of the COLLECT_NO_DEMANGLE environment variable.

This turns out to be a problem in collect2, or actually, three
problems:

(1) By default, collect2 is configured to filter out --demangle and
--no-demangle from the linker options, and it tries to do demangling
on symbol names in stdout and stderr itself instead.  But, it is too
stupid to know about the map file.

(2) Collect2 is trying to set COLLECT_NO_DEMANGLE to disable
demangling in ld, but in a nonportable way that causes it to be
always unset instead on Windows.

(3) If you configure with --with-demangler-in-ld to try to disable
the collect2 demangling, there's another bug that causes it to ignore
any explicit --demangle or --no-demangle options and only pay
attention to whether or not COLLECT_NO_DEMANGLE is set.

The attached patch addresses all three problems:

(1) I've flipped the default to --with-demangler-in-ld=yes.  Note
that configure.ac already takes care not to let this percolate
through to collect2 without verifying that the linker is GNU ld and
that it is a version that supports --demangle.  Perhaps back in 2004
when this option was first added, the ld demangling support was
deemed too experimental to make it the default, but that's surely not
the case any more.  Also, since this has been broken since 2004, I'm
not sure there's much reason to be concerned with backwards
compatibility, here

(2) I fixed the COLLECT_NO_DEMANGLE environment variable setting
recipe.

(3) I simplified the argument processing for --demangle and
--no-demangle to pass them straight through to the linker when
HAVE_LD_DEMANGLE is defined.

OK to commit?

-Sandra

2011-06-17  Sandra Loosemore  

gcc/
* configure.ac (demangler_in_ld): Default to yes.
* configure: Regenerated.
* collect2.c (main): When HAVE_LD_DEMANGLE is defined, don't
mess with COLLECT_NO_DEMANGLE, and just pass --demangle and
--no-demangle options straight through to ld.  When
HAVE_LD_DEMANGLE is not defined, set COLLECT_NO_DEMANGLE in a
way that has the intended effect on Windows.

Re: [PATCH] Fixup current_pass after running IPA transforms

[Jan Hubicka]

> 
> Running IPA transforms will mess up current_pass (and reset it
> to NULL), ICEing later for IPA PTA.  I also don't see any
> code that would avoid doing IPA transforms twice in case
> we put another small IPA pass in the late IPA pass queue.  Honza,
> I guess we need to add some PROP_ipa_transforms_applied and
> simply make the late IPA passes depend on that?

Well, the transforms are added into cgraph node at a time IPA pass is run and
then when non-IPA pass is run the transform is applied and removed from the
list.

The passmanager was originally intended to allow arbitrary ping-pong in between
ipa/small-ipa and local passes doing the right thing (i.e. applying the ipa
passes run since last non-IPA pass first time non-IPA pass is executed after a
sequence of IPA passes.

So the transforms are not run twice with IPA-PTA even if apply_ipa_transforms 
is.

Honza

[gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jan Kratochvil]

On Wed, 22 Jun 2011 17:42:34 +0200, Jason Merrill wrote:
> Well, the basic issue is that the "linkage name" is produced by
> libiberty/cp-demangle.c and the DW_AT_name is produced by
> gcc/cp/error.c, and they don't always agree on the same
> pretty-printed representation of a C++ expression.

Filed cross-check RFE GCC PR debug/49537 for it.


> >The function linkage name has prefix: K<&(S::m(int))>
> 
> This isn't actually valid C++ syntax, so the demangler should be adjusted.

Attached.  No regressions on gcc-4.6.0-10.fc15.x86_64.  OK for check it in?

It fixes (and GDB commands start to work):
K<&(S::m(int))>::f (this=0x7fffdcaf) at tmplmember.C:6
->
K<&S::m>::f (this=0x7fffdcaf) at tmplmember.C:6
BTW the above change is when using DW_AT_linkage_name; FSF GDB HEAD still uses
physname computation but that is also not right:
K<&(S::m)>::f (this=0x7fffdcaf) at tmplmember.C:6
--
struct S {
  void m (int x) {}
};
template
struct K {
  void f () { S s; (s.*F) (5); }
};
int main () {
  K<&S::m> k;
  k.f ();
}
--

Filed as GCC PR debug/49546 that GDB still does not work (*) for:
(*) without implementing - filed as GDB PR c++/12936:
On Wed, 22 Jun 2011 17:42:34 +0200, Jason Merrill wrote:
# > Or maybe it is not a bug and one just has to accept the function prefix may
# > not match its struct/class name?
# This would also be a good idea, for robustness when this kind of
# issue crops up.
--
struct S {
  static void m (int x) {}
};
template
// or: template
struct K {
  void f () { T (0); }
};
int main () {
  K<&S::m> k;
// or: K k;
  k.f ();
}
--

DWARF is exactly the for all the four combination of alternative lines.
In the member function pointer above no alternative source form gets compiled.

As both K<&S::m>::f() functions have exactly the same mangled name
_ZN1KIXadL_ZN1S1mEiEEE1fEv , the demangled names should match the source form
and in the first example it is the only allowed form of the source the
function should demangled to K<&S::m>::f() - as it is by the patch below.
But in the second example the template instace `struct K' DW_AT_name is
K so it cannot match the function K<&S::m>::f() prefix.

But in the second case it also cannot always match the source form when
multiple source notations compile into exactly the same output.

FYI:
_ZN1KIXadL_ZN1S1mEiEEE1fEv
typed name
  qualified name
template
  name 'K'
  template argument list
unary operator
  operator &
  typed name
qualified name
  name 'S'
  name 'm'
function type
  argument list
builtin type int
name 'f'
  function type
argument list


For GDB this patch resolves a regression of combination:
Re: [patch] Follow DW_AT_linkage_name for methods #2
http://sourceware.org/ml/gdb-patches/2011-06/msg00040.html
and
FYI: updates to temargs.exp
http://sourceware.org/ml/gdb-patches/2011-06/msg00138.html


On Wed, 22 Jun 2011 21:55:47 +0200, Gabriel Dos Reis wrote:
> I agree this isn't valid C++ syntax.  However, it is a syntax used in certain
> popular frameworks, e.g. QT signal/slots, and it unambiguously tells in a
> readable manner what function is intended from overload resolution 
> perspective.

There is now for some time for the template:
 <2><92>: Abbrev Number: 11 (DW_TAG_template_value_param)
<93>   DW_AT_name: F
<95>   DW_AT_type: <0x16f>  

pointing (<0x16f>) to the member function so it is more up to the debugger (or
front-end) to show it.  Had to file GDB PR c++/12933 for it, though.


Had to restrict the patch very much for the template function reference case as
otherwise the parameter types are required even in templates there.


Thanks,
Jan


libiberty/
2011-06-27  Jan Kratochvil  

* cp-demangle.c (d_print_comp): Suppress argument list for function
references as template arguments.
* testsuite/demangle-expected: 3 new testcases for it.

--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -4095,7 +4095,56 @@ d_print_comp (struct d_print_info *dpi, int options,
 case DEMANGLE_COMPONENT_ARGLIST:
 case DEMANGLE_COMPONENT_TEMPLATE_ARGLIST:
   if (d_left (dc) != NULL)
-   d_print_comp (dpi, options, d_left (dc));
+   {
+ const struct demangle_component *left = d_left (dc);
+
+ if (dc->type == DEMANGLE_COMPONENT_TEMPLATE_ARGLIST
+ && left->type == DEMANGLE_COMPONENT_UNARY
+ && d_left (left)->type == DEMANGLE_COMPONENT_OPERATOR
+ && d_left (left)->u.s_operator.op->len == 1
+ && d_left (left)->u.s_operator.op->name[0] == '&'
+

Re: RFA; MN10300: Fix AM33 clzsi2 pattern

[Richard Henderson]

On 06/25/2011 09:29 PM, Nick Clifton wrote:
> * mn10300.md (clzsi2): Use XOR after BSCH to convert bit position
> of highest bit set into a count of the high zero bits.

Ok.


r~

Re: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

[Jason Merrill]

On 06/26/2011 05:58 PM, H.J. Lu wrote:

The current unwind library scheme provides only one unwind
context and is backward compatible with multiple different unwind
contexts from multiple unwind libraries:

http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01769.html

My patch fixes UNITS_PER_WORD > sizeof (void *) and
enforces single unwind context when backward compatibility
isn't needed.


OK, there seem to be two things going on in this patch:

1) Handle registers larger than pointers.
2) Require that all code share a single copy of the unwinder.

For #2, how are you avoiding the issues Jakub describes in that message? 
 Isn't his scenario 2 still possible?  Are you deciding that it's 
better to abort at run-time in that case?


It seems to me that for targets newer than Jakub's patch we can 
hard-wire _Unwind_IsExtendedContext to true, but making further 
assumptions would be a mistake.


Then, if we're still trying to handle versioning, I think your earlier 
patch for #1 (r170716) that just changes the type of the reg array is a 
better way to go.  But that change should be dependent on a target macro 
to avoid ABI changes for existing targets.


Jason

Re: PATCH [11/n]: Prepare x32: PR rtl-optimization/48155: Reload doesn't handle subreg properly

[Ulrich Weigand]

H.J. Lu wrote:

> Given input:
> 
> (plus:SI (subreg:SI (plus:DI (reg/f:DI 7 sp)
> (const_int 16 [0x10])) 0)
> (const_int -1 [0x]))

Once again, this seems weird as legitimate address ...  If this really
can occur validly, there'll probably need to be an insn+splitter and/or
a secondard reload provided by the back-end to handle it.

> reloads tries to add
> 
> (subreg:SI (plus:DI (reg/f:DI 7 sp)
> (const_int 16 [0x10])) 0)
> 
> to
> 
> (reg:SI 1 dx)

And what happens then?  If the only problem is that this is then
rejected by the back-end, I don't think we need to change anything
in gen_reload ...

With your change below, it seems you're just falling through to
the generic gen_rtx_SET case, right?   How does this help?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: PATCH [10/n]: Prepare x32: PR rtl-optimization/49114: Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int

[Ulrich Weigand]

H.J. Lu wrote:

> When reload gets:
> 
> (insn 588 587 589 28 (set (mem:DF (zero_extend:DI (plus:SI (subreg:SI
> (reg/v/f:DI 182 [ b ]) 0) 
> (const_int 8 [0x8]))) [4 MEM[base: b_96(D), index:
> D.15020_278, step: 8, offset: 0B]+0 S8 A64])
> (reg:DF 340 [ D.14980 ])) spooles.c:291 106
> {*movdf_internal_rex64}
>  (expr_list:REG_DEAD (reg:DF 340 [ D.14980 ])
> (nil)))

Reloading of PLUS expressions is a long-standing problem.  gen_reload
supports those only for PLUSes that look more or less like address
computations, and then only the "usual" cases.

Is the address above (once the pseudo reg:DI 182 is replaced by
a hard reg) really a legitimate address on your platform?  If not,
this would need to be fixed at some earlier place.

If this *is* a valid address (and just not valid for this particular
insn pattern), the back-end needs to provide some means to reload to
allow reloading of such expressions.  This can be done either by
providing an insn (plus post-reload splitter if necessary), or else
defining a secondary reload to handle the case where additional
registers are required.  Assuming the generic gen_reload code is
powerful enough to handle complex expressions like this is probably
not wise ...

In any case, however, gen_reload should not generate *wrong*
code, so there's indeed a bug here.

However, this:

> -  if (CONSTANT_P (op1) || MEM_P (op1) || GET_CODE (op1) == SUBREG
> +  if ((GET_CODE (op0) != SUBREG
> +&& (CONSTANT_P (op1) || MEM_P (op1)))
> +   || GET_CODE (op1) == SUBREG
> || (REG_P (op1)
> && REGNO (op1) >= FIRST_PSEUDO_REGISTER)
> || (code != CODE_FOR_nothing

doesn't look like the proper fix for all cases.  The actual problem
here is that this part of gen_reload takes the approach to transform

 out <- op0 + op1

into

 out <- op0
 out <- out + op1

which is invalid if writing to out clobbers op1.

This means that:

- The "if" testing whether to swap op0 and op1 should verify
!reg_overlap_mentioned_p (out, op0)

- Regardless of whether we swapped or not, there needs to be a
gcc_assert (!reg_overlap_mentioned_p (out, op1));
  before the gen_reload (out, op0, opnum, type) line.

There may still be cases where the algorithm of gen_reload doesn't
work, but at least we'll get an ICE instead of wrong code now.
Those cases will have to be fixed by the back-end as described
above ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: Unreviewed build/libgcc, mudflap patches

[Frank Ch. Eigler]

Hi -

> >> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html
> > Looks good to me, thanks for taking a look at the area.
> 
> Could you also comment on the open questions in the submission so
> mudflap support on Solaris can be improved further?

Sure.  Transcribing:

> One generic issue came up with the port: enabling or disabling
> libmudflap depends on a factor (linker support for --wrap/-z wrap)
> that is best checked dynamically, thus doesn't really seem to belong
> at the toplevel.  Is there any precedent for performing such a test
> in the target library and enabling or disabling depending on the
> outcome?  [...]

I don't know.

> It seems the failures fall into only a few categories.  It's
> probably best to analyse and fix those before checking in the patch.
> Where should we continue discussing the failures?  Here or rather in
> the PR?

Separate PRs would be best.

- FChE

Re: [pph] Stream chain of struct fields (issue4631072)

[Diego Novillo]

On Fri, Jun 24, 2011 at 19:13, Gabriel Charette  wrote:
> We were only streaming the first field of every struct. Struct fields have a 
> chain link to the next field, thus we need to stream the DECL_CHAIN of every 
> field as well recursively.
>
> I limited this to VAR_DECL and FUNCTION_DECL for now (which fixes all of our 
> current bugs in regards to the struct fields issues), are there any other 
> DECLs that can potentially be fields of a struct?

FIELD_DECLs are the natural members of structs.  But those are handled
by generic streaming.  Also needed for PARM_DECLs (already handled as
well).  VAR_DECLs and FUNCTION_DECLs were the only ones missing.

> Syntax-wise: Is it ok to play this 'case' fall through trick with VAR_DECL or 
> should I make a
> separate case entry with it's own break?

Cleaner to just distinguish them inside the main group.  I've tweaked
it and committed to the branch.

We are still missing some link attributes.  The code compiles but does
not link.  I will look into that today.


Diego.