Re: [google][4.7]Port function reordering via linker plugin from google/gcc-4_6 branch (issue6195099)

Patch too large to be attached, rejected by gcc-patches. Please see:

http://codereview.appspot.com/download/issue6195099_1.diff

Thanks,
-Sri.

On Wed, May 16, 2012 at 6:52 PM, Sriraman Tallam <tmsriram <at> google.com> wrote:
> Hi,
>
>  This patch ports function reordering support into google/gcc-4_7 branch
>  from google/gcc-4_6 branch.  There are 3 parts which are combined:
>
>  * Adding option -freoder-functions=callgraph.
>  * Dumping callgraph profiles in separate sections.
>  * The linker plugin itself.
>
>  Port revisions from google/gcc-4_6
>  r177289, r177308, r179104, r179289, r179303, r179404, r182447
>
>  into google/gcc-4_7
>
>  adding function reordering support via linker plugin invoked with option
>  -freorder-functions=callgraph.
>
> Patch also can be reviewed here: http://codereview.appspot.com/6195099
>
> function_reordering_plugin:
>
>       * config.h.in: Generate.

[libjava] --enable-symvers tweak for 52700

Allows use of --enable-symvers=gnu-versioned-namespace while
configuring in libjava. The rest of the target libs that use
--enable-symvers already handle this. As per libstdc++/52700.

Pretty simple, but will wait for OK for trunk/branch

tested x86/linux

trunk
4_7-branch

-benjamin

2012-05-16  Benjamin Kosnik  <bkoz <at> redhat.com>

	PR libstdc++/52700
	* configure.ac: Allow gnu, gnu-versioned-namespace for
	--enable-symvers arguments.
	* configure: Regenerate.

diff --git a/libjava/configure.ac b/libjava/configure.ac
index 351b2bd..62c5000 100644
--- a/libjava/configure.ac
+++ b/libjava/configure.ac
@@ -1805,7 +1805,7 @@ AC_CACHE_CHECK([whether ld supports anonymous version scripts],
      AS_HELP_STRING([--disable-symvers],
 		    [disable symbol versioning for libjava]),
        [case "$enableval" in
-         yes) libjava_cv_anon_version_script=yes ;;

m32r-rtems libgcc config missing crtinit/fini

Hi

When moving stuff into libgcc, a line for m32r-rtems
got lost.  This is PR53314.

Is this OK for the head and 4.7?

2012-05-16  Joel Sherrill <joel.sherrill <at> oarcorp.com>

     * config.host (m32r-*-rtems*): Include crtinit.o and crtfinit.o
     as extra_parts.

diff --git a/libgcc/config.host b/libgcc/config.host
index 14c705b..b79f321 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -679,6 +682,7 @@ m32r-*-elf*)
         ;;
  m32r-*-rtems*)
         tmake_file="$tmake_file m32r/t-m32r t-fdpbit"
+       extra_parts="$extra_parts crtinit.o crtfini.o"
         ;;
  m32rle-*-elf*)
         tmake_file=t-fdpbit

--

-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill <at> OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985

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

This patch adds new flags and defines such that the C++ decl pretty printer
prints both canonical dwarf names for decls without perturbing normal error
message output.

It addresses the issues with the earlier patches submitted as:

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00516.html
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00512.html

Which are withdrawn.

This patch requires no changes to the testsuite and does not produce
visible changes to gcc's output except to dwarf consumers, which will now
all agree on the names of functions.

Tested with a full bootstrap.

OK for mainline?

Sterling

2012-05-16   Sterling Augustine  <saugustine <at> google.com>

	* gcc/c-family/c-pretty-print.h (pp_c_flag_gnu_v3): New enumerator.
	* gcc/c-family/c-pretty-print.c (pp_c_specifier_qualifier_list): Check
	it at both the start and end of the function.
	* gcc/cp/cp-tree.h (TFF_MATCH_GNU_V3_DEMANGLER): Define and comment.
	* gcc/cp/error.c (dump_decl): Print appropriate string for anonymous
	namespace based on pp_c_flag_gnu_v3.
	(decl_as_string): Set cxx_pp->flags based on TFF_MATCH_GNU_V3_DEMANGLER.

[PATCH] Try to expand COND_EXPR using addcc

Hi,
  This is just like my previous patch to expand COND_EXPR using
conditional moves but this time using addcc instead.
I had to fix a bug in emit_conditional_add where it was swapping op2
and op3 which can never happen.  Also the documentation for both
emit_conditional_add and add <at> var{mode}cc was in correct in saying the
first (non comparison) operand was the result when the condition was
true, it should have been when it was false.  So it does op2 if cond
is false and op2+op3 when the cond is true.  This actually makes
better sense than what the documentation was before too.

OK? Bootstrapped and tested on x86_64-linux-gnu?

Thanks,
Andrew Pinski

ChangeLog:
 * optabs.c (emit_conditional_add): Correct comment about the arguments.
Remove code which might swap op2 and op3 since they cannot be swapped.
* expr.c (get_condition_from_operand): New function.
(get_def_noter_for_expr_with_code): New function.
(expand_cond_expr_using_addcc): New function.
(expand_cond_expr_using_cmove): Use get_condition_from_operand instead
of doing it inline.
(expand_expr_real_2 <case COND_EXPR>): Call
expand_cond_expr_using_addcc before trying conditional moves.
* doc/md.texi (add <at> var{mode}cc): Fix document about how the arguments are used.

Index: optabs.c

[PATCH] Fix get_maxval_strlen for COND_EXPR after changing them to ternary

When COND_EXPR was changed from GIMPLE_SINGLE_RHS to
GIMPLE_TERNARY_RHS, get_maxval_strlen was not updated for that
changed.  With a patch which has a late PHIOPT produce COND_EXPR, I
saw a couple of regressions (pr23484-chk.c and  strncpy-chk.c).

This patch fixes get_maxval_strlen for that change.

OK for the trunk and 4.7 branch?  Bootstrapped and tested on
x86_64-linux-gnu with no regressions.  And in 4.7.0 with the patch for
PHIOPT producing COND_EXPR on both x86_64-linux-gnu and mipsisa64-elf.

Thanks,
Andrew Pinski

ChangeLog:
* gimple-fold.c (get_maxval_strlen): Move COND_EXPR handling under
GIMPLE_ASSIGN.

Index: gimple-fold.c
===================================================================
--- gimple-fold.c	(revision 187579)
+++ gimple-fold.c	(working copy)
@@ -670,13 +670,10 @@ get_maxval_strlen (tree arg, tree *lengt

   if (TREE_CODE (arg) != SSA_NAME)
     {
-      if (TREE_CODE (arg) == COND_EXPR)
-        return get_maxval_strlen (COND_EXPR_THEN (arg), length, visited, type)
-               && get_maxval_strlen (COND_EXPR_ELSE (arg), length, visited, type);

Re: [C++ Patch] PR 44516

Hi,

> On 16 May 2012 19:53, Paolo Carlini <pcarlini <at> gmail.com> wrote:
>>> -    expr = build_new_op (loc, code, LOOKUP_NORMAL, arg1, arg2, NULL_TREE,
>>> +    expr = build_new_op (LOC_OR_HERE (loc), code, LOOKUP_NORMAL,
>>> +             arg1, arg2, NULL_TREE,
>>>             overload, complain);
>>> 
>>> This doesn't seem correct to me because of the reasons Jason gave. If
>>> loc is unknown, you are changing the behaviour.
>> 
>> If loc is UNKNOWN I'm passing down an input_location which seems a definite improvement to me in the light
of your last message, given that the called function may immediately error out and try to use that location
in the error_at. But I'm not going to insist.
>> 
> 
> But then, this should have happened before, no? Or do we get
> UNKNOWN_LOCATION now but not before? That would indicate something has
> changed in an upper level that is not quite right. The point is that
> some things may naturally have UNKNOWN_LOCATION, however, such things
> should never be used in diagnostics. That indicates a bug. So, if the
> caller is passing down loc == UNKNOWN_LOCATION here and this new
> operation is never artificial, then the caller is wrongly passing down
> UNKNOWN_LOCATION.
> 
> In this particular case, you may have just uncovered a latent bug, and
> use the LOC_OR_HERE trick to defer fixing it for later. That seems OK
> to me, but then you should add a FIXME for such case, saying "This
> should be just LOC but something is passing down UNKNOWN_LOCATION and
> this breaks so and so"

Re: [patch] For alpha-vms, unset flag_jump_tables if flag_pic is nonzero

It turns out that there is a second target that doesn't define ASM_OUTPUT_ADDR_DIFF_ELT: pdp11.  I'll fix that.

The documentation is out of date as a consequence of this patch, because it still says that
ASM_OUTPUT_ADDR_DIFF_ELT is optional which is no longer the case (or not unless you take some other
actions as you did in the VAX port).

	paul

EnabledBy cleanups

Some cleanups in preparation for more EnabledBy goodness.

Bootstrapped and regression tested.

OK?

2012-05-16  Manuel López-Ibáñez  <manu <at> gcc.gnu.org>

c-family/
        * c.opt (--pedantic-errors,-pedantic-errors): Do not handle here.
        * c-opts.c (c_common_handle_option): Do not handle explicitly
        Wreturn-type, Wwrite-strings, warn_ecpp, and -pedantic-errors.
gcc/
        * opts.c (common_handle_option): -pedantic-errors enables -Wpedantic.
        (enable_warning_as_error): Do not special case Wuninitialized.
        * optc-gen.awk: Add sanity checks.

Fix folding through externally keyed vtables

Hi,
currently build of Mozilla with -flto-partition=none fails at:
/tmp/ccQ0smdA.ltrans3.ltrans.o:ccQ0smdA.ltrans3.o:function
scriptableInvokeDefault(NPObject*, _NPVariant const*, unsigned int, _NPVariant*) [clone
.part.84.4761]: error: undefi
ned reference to 'construction vtable for std::ostream-in-std::basic_ostringstream<char,
std::char_traits<char>, std::allocator<char> >'                                        
/tmp/ccQ0smdA.ltrans3.ltrans.o:ccQ0smdA.ltrans3.o:function
scriptableInvokeDefault(NPObject*, _NPVariant const*, unsigned int, _NPVariant*) [clone
.part.84.4761]: error: undefi
ned reference to 'construction vtable for std::ostream-in-std::basic_ostringstream<char,
std::char_traits<char>, std::allocator<char> >'                                        
/tmp/ccQ0smdA.ltrans4.ltrans.o:ccQ0smdA.ltrans4.o:function NPP_New: error: undefined reference
to 'construction vtable for std::ostream-in-std::basic_ostringstream<char, std::c
har_traits<char>, std::allocator<char> >'                                                                                                                                       
/tmp/ccQ0smdA.ltrans6.ltrans.o:ccQ0smdA.ltrans6.o:function
mozilla::NoteIntentionalCrash(char const*) [clone .local.0] [clone .constprop.67]: error:
undefined reference to 'con
struction vtable for std::ostream-in-std::basic_ostringstream<char, std::char_traits<char>,
std::allocator<char> >'                                    

and my patch actually makes this failure to happen always.  What happen is the following:

C++ represents vtables as initialized variables. When VTABLE is keyed, they are
DECL_EXTENRAL but their constructor is known.  We do look into them when
folding and derive useful data, primarily for devirtualization.  The
initializers of DECL_EXTERNAL vars however do not exists in current compilatoin
unit. They are build as if they were in the compilation unit they are comming
from.  We previously run into probelm with fact that they can reffer static
sumbol from other unit and added can_refer_decl_in_current_unit_p for this

[libgo] Undefined references to log_syslog.syslog_c on Solaris

As of today, all Go link tests were failing like this:

Undefined			first referenced
 symbol  			    in file
log_syslog.syslog_c                 /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/.
FAIL: go.go-torture/execute/array-1.go compilation,  -O0 

The symbol is referenced in log/syslog.o, but not defined anywhere.  It
turned out that this happens because an asm() in
go/log/syslog/syslog_c.c hasn't been updated.

The following patch fixes this and allowed the go and libgo tests to
pass as expected on i386-pc-solaris2.11.

	Rainer

diff --git a/libgo/go/log/syslog/syslog_c.c b/libgo/go/log/syslog/syslog_c.c
--- a/libgo/go/log/syslog/syslog_c.c
+++ b/libgo/go/log/syslog/syslog_c.c
@@ -10,7 +10,7 @@
    can't represent a C varargs function in Go.  */

 void syslog_c(int, const char*)
-  asm ("libgo_log.syslog.syslog_c");
+  asm ("log_syslog.syslog_c");

 void
 syslog_c (int priority, const char *msg)