[PING] [PATCH, ARM][2 of 2] Enable shrink-wrap for ARM

Ping. Thanks! -Zhenqiang On 3 April 2013 14:50, Zhenqiang Chen wrote: > On 2 April 2013 17:55, Ramana Radhakrishnan wrote: >> On Thu, Mar 21, 2013 at 7:03 AM, Zhenqiang Chen >> wrote: >>> Hi, >>> >>> The patch is to enable shrink-wrap for TARGET_ARM and TARGET_THUMB2. >>> >>> Bootstrapped and

[Ping^2] [PATCH, ARM][1 of 2] Add epilogue dwarf info for shrink-wrap

Ping^2. Thanks! -Zhenqiang On 2 April 2013 17:54, Zhenqiang Chen wrote: > Ping. > > On 21 March 2013 14:58, Zhenqiang Chen wrote: >> Hi, >> >> When shrink-wrap is enabled, the "returns" from simple-return path and >> normal return path can be merged. The code is like: >> >> tst ... >>

[PATCH v2] gcc: arm: linux-eabi: fix handling of armv4 bx fixups when linking

The bpabi.h header already sets up defines to automatically use the --fix-v4bx flag with the assembler & linker as needed, and creates a default assembly & linker spec which uses those. Unfortunately, the linux-eabi.h header clobbers the LINK_SPEC define and doesn't include the v4bx define when se

Re: RFA: enable LRA for rs6000 [lra-constraints]

Note, this last patch does not bootstrap on powerpc: /home/meissner/fsf-src/meissner-lra/gcc/lra-constraints.c: In function ‘bool process_alt_operands(int)’: /home/meissner/fsf-src/meissner-lra/gcc/lra-constraints.c:2045:66: error: ‘small_class_operands_num’ may be used uninitialized in this func

Re: [C++ Patch/RFC] PR 56450

Hi again, On 04/27/2013 02:56 AM, Jason Merrill wrote: Why should id_expression_or_member_access_p be false? "declval().dummy" is a class member access (5.2.5) regardless of what kind of member dummy is. today I have been able to spend some more time on the issue, and I think the attached furt

[GOOGLE] Enhance LIPO support in AutoFDO

This patch improves the LIPO support in AutoFDO to make it more robust. Bootstrapped and passed regression test and benchmark tests. Ok for google 4_7 branch? Thanks, Dehao http://codereview.appspot.com/8624045 Index: gcc/opts.h =

Re: [gomp4] Some progress on #pragma omp simd

On Sat, Apr 27, 2013 at 12:30:28PM -0500, Aldy Hernandez wrote: > >>"The syntax and semantics of the various simd-openmp-data-clauses > >>are detailed in the OpenMP specification. > >>(http://www.openmp.org/mp-documents/spec30.pdf, Section 2.9.3)." > >> > >>Balaji, can you verify which is correct?

Re: Profile mode (was Re: Add std::unordered_* C++11 allocator support)

Hi, I have made some fixes and improvements in profile mode and recently posted to my github (user gedare, repo stlprof) for another to try out. I will try to send the shippable patches upstream soon. The profile mode is interesting and useful to me as part of work done for my ph.d. thesis, and I

Re: [gomp4] Some progress on #pragma omp simd

Hi Balaji. "The syntax and semantics of the various simd-openmp-data-clauses are detailed in the OpenMP specification. (http://www.openmp.org/mp-documents/spec30.pdf, Section 2.9.3)." Balaji, can you verify which is correct? For that matter, which are the official specs from which we should be

Re: [PATCH][10/10] -fuse-caller-save - Add test-case

Tom de Vries writes: > +/* { dg-do run } */ > +/* { dg-options "-fuse-caller-save -save-temps" } */ > +/* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */ > +/* Testing -fuse-caller-save optimization option. */ > + > +static int __attribute__((noinline)) > +bar (int x) > +{ > + return x + 3; >

Re: [PATCH RFC] Finer grained reg classes.

David Miller writes: > So this patch tries to rework the semantics of hard register classes, > such that if a hard register is present in the set it is implied that > the rest of the registers in a multi-register group are present as > well. So we can add a register class called EVEN_REGS and onl

Re: [PATCH] Improve vec_widen_?mult_odd_*

On Sat, Apr 27, 2013 at 12:20 AM, Jakub Jelinek wrote: > On > #define N 4096 > unsigned int b[N], d[N]; > > void > foo (void) > { > int i; > for (i = 0; i < N; i++) > d[i] = b[i] / 3; > } > testcase I was looking earlier today because of the XOP issues, > I've noticed we generate unnecess

Re: Make m32c build, fix PSImode truncation

Bernd Schmidt writes: > This patch here: > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00661.html > > changed simplification code from > case TRUNCATE: > - /* We can't handle truncation to a partial integer mode here > - because we don't know the real bitsize of the partial >

Re: [PATCH] Fix a -Wsign-compare warning in i386.c

On Sat, Apr 27, 2013 at 12:23 AM, Jakub Jelinek wrote: > GCC 4.7.2 warns about -Wsign-compare when unsigned iterator is compared > with cregs_size. GCC 4.8 doesn't warn about it (otherwise bootstrap would > fail), because it calls maybe_constant_value before emitting the warning, > but still I'd

Re: [PATCH] Two -mxop wrong-code fixes (PR target/56866)

On Fri, Apr 26, 2013 at 5:50 PM, Jakub Jelinek wrote: > This patch fixes two wrong-code bugs with -mxop. > One is that vpmacsdqh instruction can be only used for > vec_widen_smult_odd_v4si > but not vec_widen_umult_odd_v4si. Consider we have > unsigned V4SImode h* with arguments > { 3, 3, 3, 3

Re: [C++ Patch/RFC] PR 56450

Hi >Why should id_expression_or_member_access_p be false? >"declval().dummy" is a class member access (5.2.5) regardless of >what >kind of member dummy is. I see, thanks. Then I suppose that finish_decltype_type must be adjusted to handle the COMPOUND_EXPR, I'll look into it. Thanks again Paolo

Re: [patch, mips] Fix for PR target/56942

Steve Ellcey writes: > On Wed, 2013-04-24 at 07:45 +0100, Richard Sandiford wrote: >> "Steve Ellcey " writes: >> > 2013-04-19 Andrew Bennett >> >Steve Ellcey >> > >> >PR target/56942 >> >* config/mips/mips.md (casesi_internal_mips16_): Use >> >next_active_insn instead of n

Re: [wwwdocs] C++14 support for binary literals says Noinstead of Yes

On Sat, Apr 27, 2013 at 01:03:17AM -0400, Ed Smith-Rowland wrote: > In htdocs/projects/cxx1y.html it says no for support of binary > literals. I think that's a Yes actually. > > Here is a little patchlet. > > Am I missing something? Given ./xg++ -B ./ a.C -std=c++1y -pedantic-errors -S a.C:1:9: