Re: [i386] recognize haddpd

On Wed, Sep 26, 2012 at 5:16 PM, Marc Glisse wrote: > Adding an x86 maintainer in Cc: >>> this patch passes bootstrap+testsuite. It is probably wrong in many ways, >>> but I don't know enough to do more without some advice. >>> >>> The goal is to recognize that v[0]+v[1] can be computed with hadd

Re: RFC: LRA for x86/x86-64 [0/9]

On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov wrote: > Originally I was to submit LRA at the very beginning of stage1 for > gcc4.9 as it was discussed on this summer GNU Tools Cauldron. After > some thinking, I've decided to submit LRA now but only switched on for > *x86/x86-64* target. T

Re: RFC: LRA for x86/x86-64 [0/9]

On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov wrote: > Any comments and proposals are appreciated. Even if GCC community > decides that it is too late to submit it to gcc4.8, the earlier reviews > are always useful. I would like to see some benchmark numbers, both for code quality and com

Re: [PATCH RFA] Implement register pressure directed hoist pass

On Fri, Sep 28, 2012 at 9:18 AM, Bin Cheng wrote: > (get_regno_pressure_class, get_pressure_class_and_nregs) Broken long lines in a ChangeLog entry end with a ",". > (change_pressure, mark_regno_live, mark_regno_death, mark_reg_death) > (mark_reg_store, mark_reg_clobber,

Re: RFC: LRA for x86/x86-64 [2/9]

On Fri, Sep 28, 2012 at 12:57 AM, Vladimir Makarov wrote: > LRA outputs a lot debug information about insns. I found that using slim > insn/rtl presentation helps a lot for LRA debuging. The following patch > makes slim presentation printing functions visible to LRA. It also > implements one mor

Re: vec_cond_expr adjustments

On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse wrote: > Hello, > > I have been experimenting with generating VEC_COND_EXPR from the front-end, > and these are just a couple things I noticed. > > 1) optabs.c requires that the first argument of vec_cond_expr be a > comparison, but verify_gimple_assig

[google] Emit relative addresses to function patch sections instead of absolute addresses. (issue6572065)

commit fc3a55ccec9bc770c79f8a221f5abd397befc8f6 Author: Harshit Chopra Date: Thu Sep 20 17:49:59 2012 -0700 Instead of emitting absolute addresses to the function patch sections, emit relative addresses. Absolute addresses might require relocation, which is time consuming and fraught with

RE: [PATCH RFA] Implement register pressure directed hoist pass

Thanks for comments. > -Original Message- > From: Steven Bosscher [mailto:stevenb@gmail.com] > Sent: Friday, September 28, 2012 4:29 PM > To: Bin Cheng > Cc: gcc-patches@gcc.gnu.org; Eric Botcazou; Richard Sandiford; > vmaka...@redhat.com > Subject: Re: [PATCH RFA] Implement register p

Re: [PATCH RFA] Implement register pressure directed hoist pass

On 09/28/2012 09:29 AM, Steven Bosscher wrote: > On Fri, Sep 28, 2012 at 9:18 AM, Bin Cheng wrote: >> (get_regno_pressure_class, get_pressure_class_and_nregs) > > Broken long lines in a ChangeLog entry end with a ",". >From >

[PATCH] [MELT] Fixing echo stderr permission issue

Hello, While updating my gcc melt package for debian/ubuntu, I ran into an issue of /dev/stderr permissions. Some melt build script are directly echoing to /dev/stderr; and that seems not correct. The attached patch changes this to echoing to &2, which is more sane and works. >From ebc8fa49c1aee06

[PATCH][LTO] "properly" stream PARM_DECLs

This avoids streaming PARM_DECLs both in the global type/decl and the local function sections. They are needed on the global level, so properly stream them there. Fixes part of the issues we have with debug information for early inlining, too. LTO Bootstrapped and tested on x86_64-unknown-linux

[C++ Patch] PR 54249

Hi, this patchlet fixes the issue reported by Daniel by simply adding nullptr_t to the global namespace in stddef.h (over which luckily we have control). Tested x86_64-linux. Thanks, Paolo. / 2012-09-28 Paolo Carlini PR c++/54249 * ginclude/stddef.h: I

[PATCH] Fix up vector CONSTRUCTOR handling (PR tree-optimization/54713)

Hi! As discussed in the PR, tree-vect-generic.c sometimes creates CONSTRUCTORs with vector elements to build up larger vectors from vectors supported by HW. This patch teaches fold-const to bail up on those. Vector CONSTRUCTOR verification changes and assorted fixes have been separated from the

Re: [PATCH] Fix up vector CONSTRUCTOR handling (PR tree-optimization/54713)

On Fri, Sep 28, 2012 at 1:31 PM, Jakub Jelinek wrote: > Hi! > > As discussed in the PR, tree-vect-generic.c sometimes creates CONSTRUCTORs > with vector elements to build up larger vectors from vectors supported by > HW. This patch teaches fold-const to bail up on those. Vector CONSTRUCTOR > ver

Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)

Hi, On Thu, 27 Sep 2012, Lawrence Crowl wrote: > > template > > struct D : B > > { > > typedef typename B::E E; // element_type > > E getme (int index); > > } > > Inside that struct, lets say we have a field of type E. Do we name > it F or f? IMHO only for types, not for any other decls.

Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)

On Fri, Sep 28, 2012 at 8:18 AM, Michael Matz wrote: >> It is common practice to have >> >> struct Q >> { >> typedef int E; >> E getme (int index); >> }; > > Easy: I wouldn't make a typedef for Q::E that merely is int. The reason > is that it makes knowing what getme really returns harder.

libgo patch committed: Use libbacktrace

This patch to libgo changes it to use libbacktrace. Previously backtraces required the Go package debug/elf to register itself with the runtime during the package initialization, which only worked if the program actually imported debug/elf one way or another. Bootstrapped and ran Go testsuite on

[patch] fix cross build on powerpc*-*-freebsd

Hi, I didn't test building a cross compiler when I committed the port for powerpc64-*-freebsd. And now I struggled myself when I wanted to build an amd64-freebsd -> powerpc64-freebsd cross compiler. With the below patch I'm able to do so. Ok for trunk and 4.7 once I completed the test suite

Re: RFC: LRA for x86/x86-64 [0/9]

On 12-09-28 4:21 AM, Steven Bosscher wrote: On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov wrote: Any comments and proposals are appreciated. Even if GCC community decides that it is too late to submit it to gcc4.8, the earlier reviews are always useful. I would like to see some benchm

Re: RFC: LRA for x86/x86-64 [2/9]

On 12-09-28 4:43 AM, Steven Bosscher wrote: On Fri, Sep 28, 2012 at 12:57 AM, Vladimir Makarov wrote: LRA outputs a lot debug information about insns. I found that using slim insn/rtl presentation helps a lot for LRA debuging. The following patch makes slim presentation printing functions visi

Re: [patch] fix cross build on powerpc*-*-freebsd

On Fri, Sep 28, 2012 at 4:30 AM, Andreas Tobler wrote: > > 2012-09-28 Andreas Tobler > > * config.gcc: Replace 'host' with 'target' when configuring for > powerpc64*-*-freebsd. Counts as obvious. OK in any case. Thanks. Ian

Re: [PATCH v2, rtl-optimization]: Fix PR54457, [x32] Fail to combine 64bit index + constant

On Thu, Sep 27, 2012 at 8:20 PM, Jakub Jelinek wrote: > On Thu, Sep 27, 2012 at 08:04:58PM +0200, Uros Bizjak wrote: >> After some off-line discussion with Richard, attached is v2 of the patch. >> >> 2012-09-27 Uros Bizjak >> >> PR rtl-optimization/54457 >> * simplify-rtx.c (sim

Re: [patch] fix cross build on powerpc*-*-freebsd

On 28.09.12 17:21, Ian Lance Taylor wrote: On Fri, Sep 28, 2012 at 4:30 AM, Andreas Tobler wrote: 2012-09-28 Andreas Tobler * config.gcc: Replace 'host' with 'target' when configuring for powerpc64*-*-freebsd. Counts as obvious. OK in any case. Thanks. Thank you Ian

Re: RFC: LRA for x86/x86-64 [2/9]

On 09/28/2012 09:21 AM, Vladimir Makarov wrote: On 12-09-28 4:43 AM, Steven Bosscher wrote: On Fri, Sep 28, 2012 at 12:57 AM, Vladimir Makarov wrote: LRA outputs a lot debug information about insns. I found that using slim insn/rtl presentation helps a lot for LRA debuging. The following patc

[PATCH] PR c++/54401 - Confusing diagnostics about type-alias at class scope

Hello, Consider this invalid example given in the PR, where T is not defined: 1 template 2 struct X { 3 using type = T; 4 }; g++ yields the confusing diagnostics: test.cc:3:10: error: expected nested-name-specifier before 'type' using type = T; ^ test.c

Re: Defining C99 predefined macros for whole translation unit

On Fri, 24 Apr 2009, Ian Lance Taylor wrote: > This patch to gcc is OK if the patch to glibc is OK. Now that the corresponding glibc patch is in glibc 2.16, I've updated the GCC patch (original submission ) for current sources and retested

Re: RFC: LRA for x86/x86-64 [1/9]

On 09/27/2012 04:56 PM, Vladimir Makarov wrote: The following patch adds a new argument for function alter_subreg. LRA will sometime call alter_subreg with different argument value. 2012-09-27 Vladimir Makarov * output.h (alter_subreg): Add new argument. * dbxout.c (dbxout_symbo

*ping* [patch, fortran] Handle -Wextra, -fcompare-reals is implied with -Wextra

I wrote: the attatched patch (this time for real!) implements -Wextra for the Fortran front end, and adds -fcompare-reals to -Wextra. Ping?

[PATCH] Disable updating VRSAVE everywhere except Darwin

The following proposed patch disables setting, saving and restoring the VRSAVE register on all targets except Darwin. VRSAVE was removed from the AIX ABI and was suppose to have been removed from the PPC SVR4 ABI. All recent versions of the Linux kernel set and maintain VRSAVE itself, as a proces

Re: vec_cond_expr adjustments

On Fri, 28 Sep 2012, Richard Guenther wrote: On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse wrote: Hello, I have been experimenting with generating VEC_COND_EXPR from the front-end, and these are just a couple things I noticed. 1) optabs.c requires that the first argument of vec_cond_expr be

Re: RFC: LRA for x86/x86-64 [3/9]

Il 28/09/2012 00:57, Vladimir Makarov ha scritto: > LRA creates a lot of new pseudos. So the following patch implements > ahead allocation reg info information which is important for LRA > compilation speed. > > 2012-09-27 Vladimir Makarov > > * reginfo.c (max_regno_since_last_resize): Ne

Re: Remove def operands cache

On 09/11/2012 10:53 AM, Michael Matz wrote: Hi, the operands cache is ugly. This patch removes it at least for the def operands, saving three pointers for roughly each normal statement (the pointer in gsbase, and two pointers from def_optype_d). This is relatively easy to do, because all state

Re: [google 4.7] fix line number checksum mismatch in lipo-use (issue6566044)

Comments are inlined. Attached is the new patch. Thanks, -Rong On Tue, Sep 25, 2012 at 2:25 PM, Xinliang David Li wrote: > On Mon, Sep 24, 2012 at 2:42 PM, Rong Xu wrote: >> Hi, >> >> This is for google branches only. >> It fix the lino number checksum mismatch during LIPO-use build. >> >> Tes

Re: [google 4.7] fix line number checksum mismatch in lipo-use (issue6566044)

ok (for google-47 and google/main) thanks, David On Fri, Sep 28, 2012 at 10:22 AM, Rong Xu wrote: > Comments are inlined. > Attached is the new patch. > > Thanks, > > -Rong > > On Tue, Sep 25, 2012 at 2:25 PM, Xinliang David Li wrote: >> On Mon, Sep 24, 2012 at 2:42 PM, Rong Xu wrote: >>> Hi,

libgo patch committed: runtime.Caller should succeed without debug info

Further testing uncovered a small bug in the change to use the libbacktrace library. The runtime.Caller function should succeed if we get the PC, even if we don't have any debug info. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r dff305030965

Re: RFC: LRA for x86/x86-64 [0/9]

Steven Bosscher writes: > On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov > wrote: >> Any comments and proposals are appreciated. Even if GCC community >> decides that it is too late to submit it to gcc4.8, the earlier reviews >> are always useful. > > I would like to see some benchmark n

Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2c

Segher Boessenkool asked me on IRC to break out the fix in the last change. This patch is just the change to set the default options if the user did not use -mcpu= and the compiler was not configured with --with-cpu=. Here are the patches. I can submit this patch first if David desires, and then r

Re: RFC: LRA for x86/x86-64 [3/9]

On 09/27/2012 04:57 PM, Vladimir Makarov wrote: LRA creates a lot of new pseudos. So the following patch implements ahead allocation reg info information which is important for LRA compilation speed. 2012-09-27 Vladimir Makarov * reginfo.c (max_regno_since_last_resize): New. (reg_

Re: RFC: LRA for x86/x86-64 [5/9]

On 09/27/2012 04:58 PM, Vladimir Makarov wrote: The following patch mostly prepares some data from IRA which will be used by LRA. It is done by moving some definitions fro ira-int.h to ira.h. New data reg_class_subset is generated in IRA for LRA. New functions dealing with equivs are created

Re: RFC: LRA for x86/x86-64 [0/9]

On Fri, Sep 28, 2012 at 5:21 PM, Vladimir Makarov wrote: > On 12-09-28 4:21 AM, Steven Bosscher wrote: >> >> On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov >> wrote: >>> >>>Any comments and proposals are appreciated. Even if GCC community >>> decides that it is too late to submit it to g

Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)

On 9/28/12, Michael Matz wrote: > On Thu, 27 Sep 2012, Lawrence Crowl wrote: > > > template > > > struct D : B > > > { > > > typedef typename B::E E; // element_type > > > E getme (int index); > > > } > > > > Inside that struct, lets say we have a field of type E. Do we name > > it F or f? >

Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)

On Fri, Sep 28, 2012 at 12:40 PM, Lawrence Crowl wrote: > On 9/28/12, Michael Matz wrote: >> >> I would even prefer 'e' over value_type. It's scoped, the context always >> will be clear, no need to be verbose in that name. I find the long names >> inelegant, as most of the standard libs convent

Re: Merge C++ conversion into trunk (4/6 - hash table rewrite)

On 9/28/12, Gabriel Dos Reis wrote: > On Fri, Sep 28, 2012 at 8:18 AM, Michael Matz wrote: >>> It is common practice to have >>> >>> struct Q >>> { >>> typedef int E; >>> E getme (int index); >>> }; >> >> Easy: I wouldn't make a typedef for Q::E that merely is int. The reason >> is that it m

Re: RFC: LRA for x86/x86-64 [0/9]

On 2012.09.28 at 11:21 -0400, Vladimir Makarov wrote: > On 12-09-28 4:21 AM, Steven Bosscher wrote: > > On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov > > wrote: > >>Any comments and proposals are appreciated. Even if GCC community > >> decides that it is too late to submit it to gcc4.8,

[v3] patch, configuring GCC --disable-libgomp causes libstdc++ abi check to fail.

Hey Iain. I looked at this, and easily reproduced your results. The following symbols are actually required by all namespace associated-modes, not just parallel, and do not require parallel capability: > Symbols reported as missing by the abi.exp code: > > _ZNSt9__cxx199815_List_node_base8tran

Re: RFC: LRA for x86/x86-64 [6/9]

On 09/27/2012 04:58 PM, Vladimir Makarov wrote: The following patch modifies some code in the rest of compiler for correct work of LRA. The code works the same way when LRA is not used. It is achieved by checking a new variable lra_in_progress. 2012-09-27 Vladimir Makarov * rtlanal.

Profile housekeeping 1/n (tree-vect-loop-manip updates)

Hi, this patch makes the vectorizer to produce valid profile, at least for simple testcases, like int a[1]; int i=5; main() { while (i) { int j; for(j=0;j<1;j++) a[j]=1; i--; } } or struct a { struct a * x; }; void foo (struct a * b, int j) {

Profile housekeeping 2/n (shrink wrapping fix)

Hi, this patch fixes updating in shrink wrapping. Bootstrapped/regtested x86_64-linux. Will commit it shortly. Honza * function.c (dup_block_and_redirect): Update profile. Index: function.c === --- function.c (revision 191

Fix PR54688

This is a bug in the new scheduler dependency breaking code. Sparc has a slightly broken machine description using noncanonical RTL: we get MINUS with a constant second argument. That exposes a problem in the new code, it pretends to handle MINUS but doesn't really. Since the most important case is

Profile housekeeping 3/4 (call-cddce fix)

Hi, shrink_wrap_one_built_in_call forgets to update counts. * tree-call-cdce.c (shrink_wrap_one_built_in_call): Update counts. Index: tree-call-cdce.c === --- tree-call-cdce.c(revision 191823) +++ tree-call-cdce.c

Re: Profile housekeeping 3/4 (call-cddce fix)

On Fri, Sep 28, 2012 at 10:43 PM, Jan Hubicka wrote: > Hi, > shrink_wrap_one_built_in_call forgets to update counts. Hi, Can you look at the one-liner from http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00794.html too, please? The patch there is this: Index: tree-ssa-tail-merge.c ===

Re: Profile housekeeping 3/4 (call-cddce fix)

> On Fri, Sep 28, 2012 at 10:43 PM, Jan Hubicka wrote: > > Hi, > > shrink_wrap_one_built_in_call forgets to update counts. > > Hi, > > Can you look at the one-liner from > http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00794.html too, please? > > The patch there is this: > > Index: tree-ssa-tail

libgo patch committed: Better detection of memory overflow

This patch, which brings in some bits of code from the master Go library, does a better job of detecting when a memory allocation request will overflow. This lets us panic in a way that the program can see, rather than crashing. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Comm

Re: [google] Add new dump flag -pmu to display PMU data in dumps (issue6551072)

Sorry to reply late, missed this mail again... not sure why. LGTM, okay for google branches. Dehao On Mon, Sep 24, 2012 at 1:20 PM, Teresa Johnson wrote: > Revised patch to add a new dump flag that dumps PMU profile information using > the -pmu dump option. (Was issue 6489092, creating new issu

Go patch committed: Fix handling of omitted expression in switch

In Go, if a switch statement omits the expression on which to switch, it is taken to be the constant "true". I was simply testing that the cases were boolean, which is not quite right, as it is valid to compare an empty interface against "true". This patch to the Go frontend fixes the problem. B

Re: RFC: LRA for x86/x86-64 [6/9]

On 12-09-28 4:07 PM, Jeff Law wrote: On 09/27/2012 04:58 PM, Vladimir Makarov wrote: The following patch modifies some code in the rest of compiler for correct work of LRA. The code works the same way when LRA is not used. It is achieved by checking a new variable lra_in_progress. 2012-09-

Re: RFC: LRA for x86/x86-64 [2/9]

On 12-09-28 11:36 AM, Jeff Law wrote: On 09/28/2012 09:21 AM, Vladimir Makarov wrote: On 12-09-28 4:43 AM, Steven Bosscher wrote: I have patches in the works to use the slim RTL dumping format more, too, and to use the pretty-printer code so that printing strings with escaped characters can be

Re: RFC: LRA for x86/x86-64 [3/9]

On 12-09-28 3:08 PM, Jeff Law wrote: On 09/27/2012 04:57 PM, Vladimir Makarov wrote: LRA creates a lot of new pseudos. So the following patch implements ahead allocation reg info information which is important for LRA compilation speed. 2012-09-27 Vladimir Makarov * reginfo.c (max_regn

[C++ Patch] PR 54738

Hi, Daniel, while working on the SFINAE-friendly std::result_of, noticed one more SFINAE bug: we weren't propagating complain from tsubst_copy_and_build via build_offset_ref_call_from_tree. Fixed the usual way. Tested x86_64-linux. Thanks, Paolo. /// /cp 2012-09-28

Breakage with "[v3] patch, configuring GCC --disable-libgomp causes libstdc++ abi check to fail."

> MIME-Version: 1.0 > From: Benjamin De Kosnik > Date: Fri, 28 Sep 2012 22:02:46 +0200 > There's no reason for this unintentional ABI breakage with this > configure flag. > 2012-09-28 Benjamin Kosnik > > * acinclude.m4 (GLIBCXX_ENABLE_PARALLEL): Remove ENABLE_PARALLEL. > * i

Re: [google] AutoFDO implementation

Dehao Chen writes: > > If people in up-stream find this feature interesting, I'll spend some > time to port this to trunk and try to opensource the tool to generate > profile data file. I find it interesting and would like to see the tool and a trunk version. Thanks, -Andi -- a...@linux.intel.

[v3] fixup --enable-cxx-flags

... found while working on arm-eabisim cross, using --enable-cxx-flags was not working as AM_CXXFLAGS was being over-ridden by CXXFLAGS. (Despite the comments warning about this.) Fixed. Also patchlet for the last commit, forgot to edit PARALELL_FLAGS, so --disable-thread compiles were failing.

RE: [PATCH RFA] Implement register pressure directed hoist pass

> -Original Message- > From: Steven Bosscher [mailto:stevenb@gmail.com] > Sent: Friday, September 28, 2012 4:29 PM > To: Bin Cheng > Cc: gcc-patches@gcc.gnu.org; Eric Botcazou; Richard Sandiford; > vmaka...@redhat.com > Subject: Re: [PATCH RFA] Implement register pressure directed hois

[PATCH RFA] Implement register pressure directed hoist pass

Hi, This patch implements register pressure directed hoist pass. Basically it calculates register pressure for each basic block and use that information to determine the hoist distance of each candidate expression. The register pressure is calculated by re-using IRA utilities. I measured the bene