gmane.comp.gcc.patches

Merge from gcc-4_7-branch to gccgo branch

Ian Lance Taylor — 2012-05-25T22:45:03

I've merged gcc-4_7-branch revision 187900 to the gccgo branch.

Ian

Re: [cxx-conversion] New Hash Table (issue6244048)

Gabriel Dos Reis — 2012-05-25T22:43:20


I could not agree more.

Re: [cxx-conversion] New Hash Table (issue6244048)

Gabriel Dos Reis — 2012-05-25T22:42:23

The problem with this is that it assumes that the grammar
is  a logical expression of the ideas and ideas of the language.
When that is the case, that is fine.  For C++ in particular, that is
not the case.  We have gone to extra length to fit ideas
and ideals into something that has grown barnacles and then
patch over those deficiencies by telling/teaching people to
write in certain ways.  The examples you gave below are great
and in some sense illustrate what the C++ would have liked to
happen (the ideas and ideals) as opposed to the gritty and
unsavory details of the horror that is the C++ grammar.  While
we should pay attention, I think it would be a mistake to set
coding conventions that mirror the horrors of the C++ grammar.


C++ standard thinks of "*" binding to "int" because it puts emphasis
on types -- and one of selling points of moving to C++ is that by
exploiting the static typing we would eliminate bugs and runtime
checks that are there only there because we could not get enough
static assuranc

Re: [C++ Patch] PR 32054

Paolo Carlini — 2012-05-25T22:37:37

Hi,

On 05/25/2012 06:25 PM, Jason Merrill wrote:
Good, then I propose the below, using the form "anonymous aggregate", 
because - I didn't know - we are already using it in error messages 
elsewhere, in decl.c too.

Thanks,
Paolo.

////////////////////
Index: testsuite/g++.dg/other/anon-union3.C
===================================================================
--- testsuite/g++.dg/other/anon-union3.C(revision 0)
+++ testsuite/g++.dg/other/anon-union3.C(revision 0)
< at >< at > -0,0 +1,25 < at >< at >
+// PR c++/32054
+
+class C
+{
+  auto union      // { dg-error "storage class" "" { target c++98 } }
+    {
+      int a;
+    };            // { dg-error "multiple|specified" "" { target c++11 } }
+  register union  // { dg-error "storage class" }
+    {
+      int b;
+    };
+  static union    // { dg-error "storage class" }
+    {
+      int c;
+    };
+  extern union    // { dg-error "storage class" }
+    {
+      int d;
+    };
+  mutable union   // { dg-error "storage class" }
+    {
+      int e;
+    };
+};
Index: cp

[google/gcc-4_6] Fix -gfission ICEs with pubnames and .debug_addr table (issue6254054)

Cary Coutant — 2012-05-25T22:29:27

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

It fixes a problem where we were still trying to output entries
in the .debug_addr table for location lists that were removed,
and fixes a problem where we were getting an ICE while trying
to output a pubname for a member function of a struct.

Tested with the GCC testsuite and validate-failures.py, and
also with an internal Google build with -gfission enabled.


2012-05-25   Sterling Augustine  <saugustine< at >google.com>
     Cary Coutant  <ccoutant< at >google.com>

* gcc/dwarf2out.c (remove_loc_list_addr_table_entries): New function.
(is_class_die): Return TRUE for DW_TAG_structure_type.
(resolve_addr): Remove address table entries when replacing a
location list.


Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c(revision 187887)
+++ gcc/dwarf2out.c(working copy)
< at >< at > -7864,6 +7864,19 < at >< at > remove_addr_table_entry (unsigned int i)
   attr->dw_attr = (enum dwarf_attribute) 0;
 }
 
+/* Given a location list

Re: [cxx-conversion] New Hash Table (issue6244048)

Lawrence Crowl — 2012-05-25T21:52:15

Personally, I would rather see if we can take advantage of C++
features to reduce garbage and then use the Boehm collector.
There is too much manual management with GTY, and I'd rather the
compiler leverage mainstream practice rather than depart from it.


There has been some talk of such a language feature.  As yet,
the only concrete proposal does not have wide support.  I suspect
it will take several more proposals before we hit upon one that
will get wide support.  If you have any good ideas, now would be
a really excellent time to speak up!

libgo patch committed: More efficient trampoline allocation

Ian Lance Taylor — 2012-05-25T21:51:47

This patch to libgo makes the implementation of function trampolines,
used for nested functions that refer to variables in an enclosing
function scope, much more efficient.  Previously we were allocating a
separate page for each trampoline.  This patch packs them on a single
page as much as possible.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Commited to mainline and 4.7 branch.

Ian

Re: [cxx-conversion] New Hash Table (issue6244048)

Lawrence Crowl — 2012-05-25T21:42:39

Are you claiming that the size of the binary is more important than
run-time performance, type safety, and source code size?


First, the new hash table code is smaller because it avoid supporting
special cases that we are not using in practice.  What was formerly
conditional is now unconditional, leading to tighter binaries for
a given function.

As you say, there will be more functions in the source, leading to
an increased executable size.  Setting aside run-time performance,
why is that size important?


It is precisely the performance critical code that needs the template
approach.  The approach avoids two indirect calls, which go across
translation units.  The optimizer has no ability to inline the often
trivial actions within those indirect calls.  This problem is most
severe in the traverse functions, because the optimize cannot see
enough to do anything useful with the loop.  The inliner also has no
ability to elide comparisons for null function pointers.  In short,
with the libiberty code, the ope

Re: [cxx-conversion] New Hash Table (issue6244048)

Lawrence Crowl — 2012-05-25T21:16:52

We will clean the page.

There are technical guidelines that we can, and I think should,
apply to the coding convention.  In particular, I believe any coding
convention should be consistent with the grammar of the language.

Both the GNU style and the C++ Standard style break that guideline
in different respects.  For example, consider the following GNU code.

    int *p = *foo (3);

Here, the convention implies that foo binds more tightly to the *
than it does to the (.  This implication is false.

Now consider the C++ Standard equivalent.

    int* p = *foo(3);

It fixes the binding of foo, but implies that * is syntactically
closer to int than it is to p.  That implication is false.

Now consider a form that is consistent with the actual grammar of
the language:

    int *p = *foo(3);

Here there is no implication that foo binds more closely to either
the * or the (, so the form is consistent with the grammar.

We can go further and have the spacing reinforce the grammar, but
lines will get longer.

Go patch committed: Don't create a closure if not needed

Ian Lance Taylor — 2012-05-25T21:14:51

This patch to the Go frontend changes it to not produce a closure for an
embedded function if one is not needed.  Earlier, when Go permitted
comparisons of function types, it was necessary to always create a
closure for an embedded function, so that each embedded function would
be reliably distinct.  Go 1 removed function comparisons, for this and
other reasons.  Now, if an embedded function does not require a closure,
because it does not refer to any variables defined in enclosing
functions, we don't need to create a closure.  Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline and 4.7
branch.

Ian

Re: [cxx-conversion] New Hash Table (issue6244048)

Lawrence Crowl — 2012-05-25T21:05:11

Yes, an omission that's a consequence of dealing with several
coding conventions.


We can address this issue by requiring all function definitions
to appear outside the class definition.  The code is more verbose,
but livable.


Yes.


For template classes, the specification of an out-of-line member
function is going to be long, so a single-line specification is
likely to overflow often.  Whatever we chose, it should be reasonably
extended to multiple lines.

libgcc patch committed: Fix for -fsplit-stack when using gold

Ian Lance Taylor — 2012-05-25T20:50:00

When using the gold linker, the linker will adjust the split-stack
prologue to call __morestack_non_split if it sees that the function
calls a different function compiled without -fsplit-stack.  The
__morestack_non_split function has an optimization I committed
2011-12-20 to avoid splitting the stack if it has a lot of space.
Unfortunately, I forgot that if the function calling
__morestack_non_split is a varargs function, then it expects %ebp to
have a particular value when __morestack_non_split returns.  There is no
reasonable way for __morestack_non_split to set %ebp to the right value
without actually splitting the stack.  This patch changes
__morestack_non_split to do a stack split when called by a varargs
function.  It detects a call from a varargs function by looking at the
instruction it is going to return to, to see if it uses %ebp.

Bootstrapped and ran Go testsuite and split-stack tests on
x86_64-unknown-linux-gnu, both 32-bit and 64-bit.  Added a new test to
check this case in the future.  With an

Re: [patch] Fix PR lto/52178 (continued)

Eric Botcazou — 2012-05-25T20:21:01

Thanks.  I already verified it with --enable-checking=yes,rtl.

Re: [cxx-conversion] Convert vec.[ch] to C++ [1/3] (issue6233044)

Diego Novillo — 2012-05-25T20:06:52

Minimalism.  I was almost obsessed by it with the first patch.  It 
would've required more changes if I didn't make it a POD type.

I will make it into a more standard C++ type in subsequent patches.


Diego.

Re: [AARCH64] [PATCH 1/3] AArch64 Port

Joseph S. Myers — 2012-05-25T19:40:33


I think the order of preference is roughly:

* Generic GNU C code.  For example, I saw you had addition intrinsics that 
just used "+" on the vector types.  This is the best approach for anything 
that can be represented like that in GNU C.  This includes any cases where 
the generic GNU C way of doing something is with a generic __builtin (for 
example, if the operation can naturally be defined in terms of 
__builtin_shuffle then you should do that).

* Architecture-specific built-in functions that fold to produce GENERIC / 
GIMPLE codes with architecture-independent semantics.  (But if several 
architectures have the same vector operation, it may be better to define 
an architecture-independent built-in function for it - though that then 
needs generic fallback support for architectures without the operation.)

* Architecture-specific built-in functions that produce RTL with 
architecture-independent semantics.

* Architecture-specific built-in functions that produce UNSPEC RTL.

* Inline asm.

And, inli

Re: [PATCH][revised] PR debug/53453 ensure debug notes linked on darwin

Jason Merrill — 2012-05-25T19:36:59

OK.

Jason

Re: [PATCH] Add powerpc64-linux configuration options

David Edelsohn — 2012-05-25T19:29:00

On Fri, May 25, 2012 at 10:22 AM, Michael Meissner
<meissner< at >linux.vnet.ibm.com> wrote:


Mike,

Please apply the second version of your patch corresponding to

       * config/rs6000/t-linux64: Delete the 32-bit multilib that uses
       software floating point emulation.  No longer build the multilibs
       with -mstrict-align.

Thanks, David

Re: [AARCH64] [PATCH 1/3] AArch64 Port

Marcus Shawcroft — 2012-05-25T19:01:07

There is work going on to get other components ready for community 
review.  I expect to see patches submitted over the next few months.


Ok, thanks for the explanation, we will drop __float128.


I will respond to this comment separately.



We initially put together a simple asm based implementation of each 
intrinsic.  Subsequently we have replaced many of the intrinsics with 
GNU C implementations.  The vneg_* patterns are an oversight which will 
be fixed.

We have a long list of intrinsics which we want to move into RTL, only 
some of these have been moved so far.  However, that said, point noted 
that we can usefully exploit TARGET_FOLD_BUILTIN in preference to RTL.


Agreed, these are not needed.


We have no plans for non-ELF, the conditionals will be removed.

The remainder of your comments will be addressed with patches shortly.

Thank you for the feedback!

/Marcus

Re: [PATCH] PR bootstrap/53459 - unused local typedef when building on altivec

Pedro Alves — 2012-05-25T18:56:40



You can simply rename the 'l' array to the error you want to output, so you get an error like:

error: size of array 'the_vector_size_has_to_be_the_size_of_2_or_4_long' is negative

or whatever you want to say as error.

Re: [PATCH] PR debug/53453 ensure debug notes linked on darwin

Mike Stump — 2012-05-25T18:50:51

Darwin bits are Ok.

Re: [PATCH] omit -lcrt1.10.6.o and pass -no_new_main with -pg on darwin >= 10.8

Mike Stump — 2012-05-25T18:49:11

Ok.