Re: [df-scan.c] Optimise DF_REFs ordering in collection_rec, use HARD_REG_SETs instead of bitmaps

On Fri, Jul 08, 2011 at 06:20:04AM +0300, Dimitrios Apostolou wrote: > The attached patch does two things for df_get_call_refs(): > * First it uses HARD_REG_SETs for defs_generated and > regs_invalidated_by_call, instead of bitmaps. Replacing in total > more than 400K calls (for my testcase) to bit

Re: [df-scan.c] Optimise DF_REFs ordering in collection_rec, use HARD_REG_SETs instead of bitmaps

On Fri, Jul 8, 2011 at 5:20 AM, Dimitrios Apostolou wrote: > The attached patch does two things for df_get_call_refs(): How did you test this patch? Normally, a patch submission comes with text like, "Bootstrapped & tested on ..., no regressions.". Also, you chould write a ChangeLog entry, best

Re: [df-scan.c] Optimise DF_REFs ordering in collection_rec, use HARD_REG_SETs instead of bitmaps

And here is the patch that breaks things. By moving df_defs_record() *after* df_get_call_refs() most times collection_rec remains sorted, and about 50M instructions are avoided in qsort() calls of df_canonize_collection_rec(). Unfortunately this does not work. Sometimes cc1 crashes, for exampl

Re: [df-scan.c] Optimise DF_REFs ordering in collection_rec, use HARD_REG_SETs instead of bitmaps

To document the gains from the bitmaps, here is (part of) the annotated source from callgrind profiler, showing instruction count. Before: 1,154,400 if (bitmap_bit_p(regs_invalidated_by_call_regset, i) 8,080,800 => bitmap.c:bitmap_bit_p (192400x) 1,021,200 && !bitmap_bit_p (&d

[df-scan.c] Optimise DF_REFs ordering in collection_rec, use HARD_REG_SETs instead of bitmaps

Hello list, The attached patch does two things for df_get_call_refs(): * First it uses HARD_REG_SETs for defs_generated and regs_invalidated_by_call, instead of bitmaps. Replacing in total more than 400K calls (for my testcase) to bitmap_bit_p() with the much faster TEST_HARD_REG_BIT, reduces

Re: [PATCH, ARM] PR47855 Compute attr length for thumb2 insns, 3/3 (issue4475042)

Thanks for the review. Richard, what's the situation of unaligned memory access and how does it conflict with this patch? thanks Carrot On Tue, Jun 7, 2011 at 6:42 PM, Nick Clifton wrote: > Hi Carrot, > >> 2011-05-06  Guozhi Wei   >> >>        PR target/47855 >>        * config/arm/thumb2.md (t

Re: [CFT][PATCH 0/6] Move dwarf2 cfi creation to a new pass

On 07/06/2011 04:15 PM, Bernd Schmidt wrote: > Ok for the bits that aren't from me anyway, once you're satisfied it's > sufficiently tested. I committed this series. I tested x86_64, ia64, and ppc64-linux; Iain tested i686-darwin9; and you tested arm-linux. Excluding vax, that covered all the ta

[alpha] Don't force MIPS debugging on dwarf2.

commit bc207f644185c3889e38406e9552fc5d43e66af5 Author: Richard Henderson Date: Wed Jul 6 13:04:49 2011 -0700 alpha-elf: Disable stabs debugging, and the mips sdb extensions. In particular, the mips sdb extensions accidentally implied the irix dwarf2 extensions and restrictions

Re: PATCH: Support -mx32 in GCC tests

On Thu, Jul 7, 2011 at 2:12 PM, H.J. Lu wrote: > On Thu, Jul 7, 2011 at 1:57 PM, H.J. Lu wrote: >> On Thu, Jul 7, 2011 at 1:56 PM, H.J. Lu wrote: >> >>> > -/* { dg-do compile { target { { { ! mips64 } && { ! ia64-*-* } } && { ! > spu-*-* } } } } */ > +/* { dg-do compile { target { {

Re: PATCH: Support -mx32 in GCC tests

On Jul 7, 2011, at 3:20 PM, H.J. Lu wrote: > -/* { dg-do compile { target { { { ! mips64 } && { ! ia64-*-* } } && { > ! spu-*-* } } } } */ > +/* { dg-do compile { target { { { { ! mips64 } && { ! ia64-*-* } } && > { ! spu-*-* } } && { ! { { i?86-*-* x86_64-*-* } && x32 } } } } } */ > -/* { dg-do c

Re: CFT: Move unwinder to toplevel libgcc

On Thu, 2011-07-07 at 10:05 -0700, Steve Ellcey wrote: > On Thu, 2011-07-07 at 15:08 +0200, Rainer Orth wrote: > > > In that case, perhaps Steve could have a look? I'd finally like to make > > some progress on this patch. > > > > Thanks. > > Rainer > > When doing an IA64 Linux build (wh

Re: MAINTAINERS: update my email address

On Fri, 27 May 2011, Nathan Froyd wrote: (Setting maintainer point-of-contact to @gcc.gnu.org) Please, anyone setting their contact adress to point at gcc.gnu.org, test that it works to send email from somewhere else than gcc.gnu.org, from an adress with a domain setting SPF records. No MX betwee

Re: Ping: The TI C6X port

On 07/07/2011 03:26 PM, Bernd Schmidt wrote: > 7/11: Cope with using a section name other than ".rodata". > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00909.html Ok. > 8/11: Round function arg sizes to more than PARM_BOUNDARY > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02170.

Re: Ping: The TI C6X port

On 07/07/2011 03:26 PM, Bernd Schmidt wrote: > 6/11: REG_WORDS_BIG_ENDIAN > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00757.html Ok. Nick, consider using this on the rx port. This should solve the problem with the mulsidi3 pattern not available for BE. r~

Re: Ping: The TI C6X port

Ping^6 for the C6X port. 6/11, 7/11, 8/11, 9/11 should be relatively quick to review. Cc'ing some maintainers. 10/11 is of course out of date by now, but there's little sense posting new versions all the time... >>> regrename across basic block boundaries: >>> http://gcc.gnu.org/ml/gcc-patches/

Re: PATCH: Support -mx32 in GCC tests

On Thu, Jul 7, 2011 at 2:58 PM, Mike Stump wrote: > On Jul 7, 2011, at 2:12 PM, H.J. Lu wrote: >> Here is the updated patch.  I will wait for Uros's comments. > > Please remove ChangeLog for lower-subreg-1.c and pr44194-1.c, as I don't > think those files are modified anymore. They are modified.

Re: PATCH: Support -mx32 in GCC tests

On Jul 7, 2011, at 2:12 PM, H.J. Lu wrote: > Here is the updated patch. I will wait for Uros's comments. Please remove ChangeLog for lower-subreg-1.c and pr44194-1.c, as I don't think those files are modified anymore.

C++ PATCH for c++/49663 (ICE in lookup_base)

When we're doing template argument substitution during deduction, we push into the appropriate class for lookup, but after my patch for 48884 stopped doing push_to_top_level in the case of a non-member function. In this PR, this change confused a place in the compiler that assumes, reasonably,

Re: [CFT][PATCH 0/6] Move dwarf2 cfi creation to a new pass

On 07/03/11 22:01, Richard Henderson wrote: > So far I've tested this only on x86_64-linux. It needs a bit more > testing across other targets before going in. Any help that can > be given there would be welcome. > No problems on qemu arm-linux, "{arch=armv7-a,armv7-a/thumb,thumb,}". Bernd

Re: PATCH: Support -mx32 in GCC tests

On Thu, Jul 7, 2011 at 1:57 PM, H.J. Lu wrote: > On Thu, Jul 7, 2011 at 1:56 PM, H.J. Lu wrote: > >> -/* { dg-do compile { target { { { ! mips64 } && { ! ia64-*-* } } && { ! spu-*-* } } } } */ +/* { dg-do compile { target { { { { ! mips64 } && { ! ia64-*-* } } && { ! spu-*-*

Re: PATCH: Support -mx32 in GCC tests

On Thu, Jul 7, 2011 at 1:56 PM, H.J. Lu wrote: > >>> -/* { dg-do compile { target { { { ! mips64 } && { ! ia64-*-* } } && { ! >>> spu-*-* } } } } */ >>> +/* { dg-do compile { target { { { { ! mips64 } && { ! ia64-*-* } } && { ! >>> spu-*-* } } && { ! x32 } } } } */ >> >> >> Hum, I worry about x

Re: PATCH: Support -mx32 in GCC tests

On Thu, Jul 7, 2011 at 1:27 PM, Mike Stump wrote: > On Jul 7, 2011, at 11:26 AM, H.J. Lu wrote: >> -/* { dg-do compile { target { { i?86-*-* rs6000-*-* alpha*-*-* x86_64-*-* } >> || { powerpc*-*-* && ilp32 } } } } */ >> +/* { dg-do compile { target { { i?86-*-* rs6000-*-* alpha*-*-* x86_64-*-* }

[SPARC] Fix PR target/49660

This is the glitch reported by Rainer for the 64-bit compiler on SPARC/Solaris, where we pass -mcpu=v9 in 32-bit mode but this nevertheless doesn't cause the V8+ architecture to be selected, unlike for the 32-bit compiler. Tested on SPARC/Solaris and SPARC64/Solaris, applied on the mainline, and

Re: [patch] Disable static build for libjava

Hi Matthias, On Thu, Jul 07, 2011 at 10:26:59PM +0200, Jakub Jelinek wrote: > On Thu, Jul 07, 2011 at 10:22:37PM +0200, Matthias Klose wrote: > > +AC_PROG_LIBTOOL This tests the wrong compiler and toolchain. The compiler you want to test doesn't exist yet at the time this configure script is run

Re: [PATCH] Skip testsuite/gcc.dg/tree-ssa/sra-12.c on avr*-*-*

On Jul 7, 2011, at 11:33 AM, Martin Jambor wrote: > on avr targets, the aggregate that we test to be totally scalarized > away is deemed to be to big for it - this is determined by the value > of MOVE_RATIO which is very low unless redefined by the target. This > is analogous situation to what we

Re: PATCH: Support -mx32 in GCC tests

On Jul 7, 2011, at 11:26 AM, H.J. Lu wrote: > -/* { dg-do compile { target { { i?86-*-* rs6000-*-* alpha*-*-* x86_64-*-* } > || { powerpc*-*-* && ilp32 } } } } */ > +/* { dg-do compile { target { { i?86-*-* rs6000-*-* alpha*-*-* x86_64-*-* } > || { powerpc*-*-* && ia32 } } } } */ powerpc doesn't

Re: [patch] Disable static build for libjava

On Thu, Jul 07, 2011 at 10:22:37PM +0200, Matthias Klose wrote: > +AC_PROG_LIBTOOL > +if test x$enable_shared = xyes && test x$enable_static_libjava != xyes ; then > + case $host_cpu in Shouldn't this be $host_os instead of $host_cpu ? cygwin* etc. don't look like host_cpu names... > + cygwin*

Re: [patch] Disable static build for libjava

On 07/07/2011 07:56 PM, Andrew Haley wrote: > On 07/07/11 18:02, David Daney wrote: >> On 07/07/2011 09:57 AM, Matthias Klose wrote: >>> On 07/07/2011 06:51 PM, David Daney wrote: On 07/07/2011 09:27 AM, Matthias Klose wrote: > As discussed at the Google GCC gathering, disable the build of

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 7, 2011 at 9:14 PM, David Edelsohn wrote: > On Thu, Jul 7, 2011 at 11:53 AM, Richard Guenther > wrote: > >> Well, that's up to the target maintainers to decide, maybe >> -mno-nested-functions instead? > > Is -mno-nested-functions or -mno-nested-function-pointers too > C-centric or GCC

Re: [PATCH 4/6] Shrink-wrapping

Richard Earnshaw writes: > On 07/07/11 15:34, Richard Sandiford wrote: >> It seems a shame to have both (return) and (simple_return). You said >> that we need the distinction in order to cope with targets like ARM, >> whose (return) instruction actually performs some of the epilogue too. >> It fe

[ARM] Fix PR49641

This corrects an error in store_multiple_operation. We're only generating the writeback version of the instruction on Thumb-1, so that's where we must make sure the base register isn't also stored. The ARMv7 manual is unfortunately not totally clear that this does in fact produce unpredictable res

Re: [PATCH, testsuite] Fix for PR49519, miscompiled 447.dealII in SPEC CPU 2006

On Thu, Jul 07, 2011 at 09:52:31PM +0200, Eric Botcazou wrote: > OK, modulo a few nits: > > + /* If address come in register - we have no idea of its origin, so > + give up and conservatively return true */ > + else if (GET_CODE (addr) == REG) > > /* If the address comes in a register, we h

Re: [PATCH, testsuite] Fix for PR49519, miscompiled 447.dealII in SPEC CPU 2006

> ChangeLog entry: > 2011-07-06 Kirill Yukhin > >PR middle-end/49519 >* calls.c (mem_overlaps_already_clobbered_arg_p): Additional >check if address is stored in register. If so - give up. >(check_sibcall_argument_overlap_1): Do not perform check of >overl

[lra] patch to fix GCC testsuite degradations on x86

The following patch fixes all current GCC testsuite degradations of IRA+LRA in comparison with IRA + reload on x86 bringing IRA+LRA having less testsuite failures on x86 than IRA+reload. The patch was successfully bootstrapped on x86-64, IA64, and ppc64. 2011-07-07 Vladimir Makarov

[Patch, Fortra] Add STAT_STOPPED_IMAGE to SYC ALL/SYNC IMAGES

Hello, I'd like to submit the attached patch. This patch was just discussed in the gfortran list. It fixes a couple of TODO items in the MPI library. It is a simple patch. libgfortran/ChangeLog 2011-07-07 Daniel Carrera * mpi.c (_gfortran_caf_sync_all): Add STAT_STOPPED_IMAGE as a

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 7, 2011 at 11:53 AM, Richard Guenther wrote: > Well, that's up to the target maintainers to decide, maybe > -mno-nested-functions instead? Is -mno-nested-functions or -mno-nested-function-pointers too C-centric or GCC-centric? I don't know what wording would be more informative, but

Re: Provide 64-bit default Solaris/x86 configuration (PR target/39150)

Rainer Orth writes: > All bootstraps have completed without regressions, so I've installed the > patch as is, after verifying that the libgo parts aren't present in the > upstream Go repo. I committed the libgo patch to the upstream repository. Thanks. Ian diff -r 70b5a35b2d19 libgo/config/li

Re: [PATCH, PR 49495] Cgraph verifier must look through aliases

> Hi, > > On Mon, Jul 04, 2011 at 11:13:12AM +0200, Jan Hubicka wrote: > > > Hi, > > > > > > PR 49495 is actually a bug in the verifier that does not look through > > > aliases at one point. Fixed wit the patch below (created a special > > > function, otherwise I just wasn't able to fit the 80 c

[PATCH, SRA] Dump that a structure is too big for total scalarization

Hi, in order to better analyze what SRA is or is not doing, it is sometimes advantageous to have in the dump information that a structure was not subject to total scalarization because it was too big - if we have detailed dumping on, that is. This is accomplished by the patch below. It is curren

Re: Remove dead code in genautomata.c

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/11 12:25, Bernd Schmidt wrote: > In January 2006, Zack had a series of "chainsaw" patches for > genautomata. One of them left some dead code (a loop which used to count > states but is now useless), which the following patch removes. > > Test

[PATCH] Skip testsuite/gcc.dg/tree-ssa/sra-12.c on avr*-*-*

Hi, on avr targets, the aggregate that we test to be totally scalarized away is deemed to be to big for it - this is determined by the value of MOVE_RATIO which is very low unless redefined by the target. This is analogous situation to what we had with testsuite/gcc.dg/tree-ssa/pr42585.C a year a

Re: PATCH: Support -mx32 in GCC tests

On Thu, Jul 7, 2011 at 10:57 AM, Mike Stump wrote: > On Jul 7, 2011, at 10:29 AM, H.J. Lu wrote: >> On Linux/x86-64, when we pass >> >> RUNTESTFLAGS="--target_board='unix{-mx32}'" >> >> to GCC tests, we can't check lp64/ilp32 for availability of 64bit x86 >> instructions.  This patch adds ia32 and

Remove dead code in genautomata.c

In January 2006, Zack had a series of "chainsaw" patches for genautomata. One of them left some dead code (a loop which used to count states but is now useless), which the following patch removes. Tested by verifying no warnings when compiling genautomata.c, and identical insn-automata.c output fo

Re: [PATCH, PR 49495] Cgraph verifier must look through aliases

Hi, On Mon, Jul 04, 2011 at 11:13:12AM +0200, Jan Hubicka wrote: > > Hi, > > > > PR 49495 is actually a bug in the verifier that does not look through > > aliases at one point. Fixed wit the patch below (created a special > > function, otherwise I just wasn't able to fit the 80 column limit). >

Re: [Patch, AVR]: Fix PR46779

2011/7/7 Georg-Johann Lay : > Denis Chertykov wrote: >> 2011/6/27 Georg-Johann Lay: >>> Denis Chertykov wrote: > The main problem for me is that the new addressing mode produce a worse code in many tests. >>> You have an example source? >> >> In attachment. >> >> Denis. > > Hi Denis. > >

[PATCH 3/3] Fix PR47654: Compute LB and UB of a CLAST expression.

2011-07-05 Sebastian Pop PR tree-optimization/47654 PR middle-end/49649 * graphite-clast-to-gimple.c (struct clast_name_index): Add a level field. (new_clast_name_index): Add the level parameter. (clast_name_to_level): New. (save_clast_nam

[PATCH 2/3] Do not compute twice type, lb, and ub.

2011-07-05 Sebastian Pop * graphite-clast-to-gimple.c (graphite_create_new_loop): Do not recompute type, lb, and ub. Get them from... (graphite_create_new_loop_guard): ...here. Pass in parameter pointers to type, lb, and ub. (translate_clast_for_loop):

[PATCH 1/3] Start counting nesting level from 0 and use the standard "Polyhedral SCattering Transformed" psct_* interface.

2011-07-05 Sebastian Pop * graphite-clast-to-gimple.c (compute_bounds_for_level): Call psct_dynamic_dim. (translate_clast_for_loop): Pass loop level to dependency_in_loop_p. (gcc_type_for_iv_of_clast_loop): Update use of level. (gloog): Start counting nes

[PATCH 0/3] Fix PR47654 and PR49649

Hi, First there are two cleanup patches independent of the fix: Start counting nesting level from 0. Do not compute twice type, lb, and ub. Then the patch that fixes PR47654: Fix PR47654: Compute LB and UB of a CLAST expression. One of the reasons we cannot determine the IV type only fro

Re: PATCH: Support -mx32 in GCC tests

On Jul 7, 2011, at 10:29 AM, H.J. Lu wrote: > On Linux/x86-64, when we pass > > RUNTESTFLAGS="--target_board='unix{-mx32}'" > > to GCC tests, we can't check lp64/ilp32 for availability of 64bit x86 > instructions. This patch adds ia32 and x32 effetive targets. OK for > trunk? Ok.

Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests

On 07/07/2011 09:48 AM, Richard Earnshaw wrote: > On 07/07/11 17:30, Janis Johnson wrote: >> On 07/07/2011 09:14 AM, Richard Earnshaw wrote: >>> On 07/07/11 00:26, Janis Johnson wrote: Index: gcc.target/arm/xor-and.c ===

PATCH: Support -mx32 in GCC tests

Hi, On Linux/x86-64, when we pass RUNTESTFLAGS="--target_board='unix{-mx32}'" to GCC tests, we can't check lp64/ilp32 for availability of 64bit x86 instructions. This patch adds ia32 and x32 effetive targets. OK for trunk? Thanks. H.J. --- 2011-07-07 H.J. Lu * lib/target-support

Re: [PATCH 4/6] Shrink-wrapping

On 07/07/11 19:05, Paul Koning wrote: > From a note by Richard Henderson (June 30, 2011) it sounds like > rs6000 is the other platform that still generates asm prologues. But > yes, I said I would do this. It sounds like doing it soon would help > Bernd a lot. Let me try to accelerate it. Maybe

Re: Fix PR 49014

On 07/01/11 16:50, Andrey Belevantsev wrote: > On 26.05.2011 17:32, Andrey Belevantsev wrote: >> On 25.05.2011 19:31, Bernd Schmidt wrote: >>> On 05/25/2011 03:29 PM, Andrey Belevantsev wrote: I think the hook is a better idea than the attribute because nobody will care to mark all o

Re: [PATCH 4/6] Shrink-wrapping

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/11 11:05, Paul Koning wrote: > > On Jul 7, 2011, at 1:00 PM, Jeff Law wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 07/07/11 10:58, Paul Koning wrote: >>> >>> On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote: >>>

Re: CFT: Move unwinder to toplevel libgcc

On Thu, 2011-07-07 at 15:08 +0200, Rainer Orth wrote: > In that case, perhaps Steve could have a look? I'd finally like to make > some progress on this patch. > > Thanks. > Rainer When doing an IA64 Linux build (where I do need to compile unwind-ia64.c) I am dying with this failure: In

Re: [PATCH 4/6] Shrink-wrapping

On Jul 7, 2011, at 1:00 PM, Jeff Law wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/07/11 10:58, Paul Koning wrote: >> >> On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote: >> >>> ... >>> It'd also be nice to get rid of all these big blocks of code that are condit

Re: [patch] Disable static build for libjava

On 07/07/2011 09:57 AM, Matthias Klose wrote: On 07/07/2011 06:51 PM, David Daney wrote: On 07/07/2011 09:27 AM, Matthias Klose wrote: As discussed at the Google GCC gathering, disable the build of static libraries in libjava, which should cut the build time of libjava by 50%. The static libja

Re: [PATCH 4/6] Shrink-wrapping

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/11 10:58, Paul Koning wrote: > > On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote: > >> ... >> >>> It'd also be nice to get rid of all these big blocks of code that are >>> conditional on preprocessor macros, but I realise you're just follow

Re: [PATCH 4/6] Shrink-wrapping

On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote: > ... > >> It'd also be nice to get rid of all these big blocks of code that are >> conditional on preprocessor macros, but I realise you're just following >> existing practice in the surrounding code, so again it can be left to >> a future clean

Re: [patch] Disable static build for libjava

On 07/07/2011 06:51 PM, David Daney wrote: > On 07/07/2011 09:27 AM, Matthias Klose wrote: >> As discussed at the Google GCC gathering, disable the build of static >> libraries >> in libjava, which should cut the build time of libjava by 50%. The static >> libjava build isn't useful out of the bo

Re: [patch] Disable static build for libjava

On 07/07/2011 09:27 AM, Matthias Klose wrote: As discussed at the Google GCC gathering, disable the build of static libraries in libjava, which should cut the build time of libjava by 50%. The static libjava build isn't useful out of the box, and I don't see it packaged by Linux distributions ei

Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests

On 07/07/11 17:30, Janis Johnson wrote: > On 07/07/2011 09:14 AM, Richard Earnshaw wrote: >> On 07/07/11 00:26, Janis Johnson wrote: >>> Index: gcc.target/arm/xor-and.c >>> === >>> --- gcc.target/arm/xor-and.c(revision 175921)

Re: CFT: Move unwinder to toplevel libgcc

On Thu, 2011-07-07 at 15:08 +0200, Rainer Orth wrote: > In that case, perhaps Steve could have a look? I'd finally like to make > some progress on this patch. > > Thanks. > Rainer It looks like the GCC build is trying to compile unwind-ia64.c on IA64 HP-UX even though it should not use

Re: [testsuite] arm thumb tests: remove -march= and dg-prune-output from 9 tests

On 07/07/11 00:28, Janis Johnson wrote: > This patch removes -march= from nine tests that also check for relevant > effective targets. If -march is removed there is no need to ignore > compiler warnings about conflicting options with dg-prune-output, so the > patch removes that from the tests. >

Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests

On 07/07/2011 09:14 AM, Richard Earnshaw wrote: > On 07/07/11 00:26, Janis Johnson wrote: >> Index: gcc.target/arm/pr41679.c > > I think this should just be moved to gcc.c-torture/compile. There > doesn't seem to be anything processor-specific here. > >> Index: gcc.target/arm/pr46883.c > > Lik

[patch] Disable static build for libjava

As discussed at the Google GCC gathering, disable the build of static libraries in libjava, which should cut the build time of libjava by 50%. The static libjava build isn't useful out of the box, and I don't see it packaged by Linux distributions either. The AC_PROG_LIBTOOL check is needed to ge

Re: [patch tree-optimization]: [3 of 3]: Boolify compares & more

2011/7/7 Paolo Bonzini : > On 07/07/2011 06:07 PM, Kai Tietz wrote: >> >> +  /* We redo folding here one time for allowing to inspect more >> +     complex reductions.  */ >> +  substitute_and_fold (op_with_constant_singleton_value_range, >> +                      vrp_fold_stmt, false); >> +  /* We

Re: Fix PR 49014

On 07/01/2011 10:50 AM, Andrey Belevantsev wrote: On 26.05.2011 17:32, Andrey Belevantsev wrote: On 25.05.2011 19:31, Bernd Schmidt wrote: On 05/25/2011 03:29 PM, Andrey Belevantsev wrote: I think the hook is a better idea than the attribute because nobody will care to mark all offending insn

Re: [patch tree-optimization]: [3 of 3]: Boolify compares & more

On 07/07/2011 06:07 PM, Kai Tietz wrote: + /* We redo folding here one time for allowing to inspect more + complex reductions. */ + substitute_and_fold (op_with_constant_singleton_value_range, + vrp_fold_stmt, false); + /* We need to mark this second pass to avoid re-

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

[...] On Jul 7, 2011, at 5:53 PM, Richard Guenther wrote: > On Thu, Jul 7, 2011 at 5:47 PM, Michael Meissner > wrote: >> I certainly can call the switch -mno-static-chain, which is perhaps more >> meaningful (at least to us compiler folk, I'm not sure static chain means >> much >> to the normal

Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests

On 07/07/11 00:26, Janis Johnson wrote: > For three tests in gcc.target/arm that don't depend on processor-specific > behavior, don't specify the -march option. This makes dg-prune-output > for warnings about conflicts unnecessary, so remove it. > > Two of these tests are for internal compiler er

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 07, 2011 at 05:53:09PM +0200, Richard Guenther wrote: > Well, I guess you don't propose to build glibc with -mno-r11? The compiler > certainly can't figure out in _all_ cases - but it should be able to handle > most of the cases (with LTO even more cases) ok, no? No, we are no proposi

[patch tree-optimization]: [3 of 3]: Boolify compares & more

Hello, This patch - third of series - fixes vrp to handle bitwise one-bit precision typed operations. And it introduces a second - limitted to non-switch-statement range - vrp pass. Bootstrapped and regression tested for all standard-languages (plus Ada and Obj-C++) on host x86_64-pc-linux-gnu.

[patch tree-optimization]: [2 of 3]: Boolify compares & more

Hello, This patch - second of series - adds boolification of comparisions in gimplifier. For this casts from/to boolean are marked as not-useless. And in fold_unary_loc casts to non-boolean integral types are preserved. The hunk in tree-ssa-forwprop.c in combine_cond-expr_cond is not strictly nec

[patch tree-optimization]: [1 of 3]: Boolify compares & more

Hello, This patch - first of series - adds to fold and some helper routines support for one-bit precision bitwise folding and detection. This patch is necessary for - next patch of series - boolification of comparisons. Bootstrapped and regression tested for all standard-languages (plus Ada and O

Re: [PATCH] New IPA-CP with real function cloning

Hi, patch is long, so let me review it in more passes. > > > 2011-06-22 Martin Jambor > > * ipa-prop.h: Include alloc-pool.h. > (ipa_lattice_type): Removed. > (ipcp_value_source): New type. > (ipcp_value): Likewise. > (ipcp_values_pool): Declare. > (ipcp_so

Re: [testsuite] ARM wmul tests: require arm_dsp_multiply

On 06/07/11 18:33, Janis Johnson wrote: > On 06/29/2011 06:25 AM, Richard Earnshaw wrote: >> On 23/06/11 22:38, Janis Johnson wrote: >>> Tests wmul-[1234].c and mla-2.c in gcc.target/arm require support that >>> the arm backend identifies as TARGET_DSP_MULTIPLY. The tests all >>> specify a -march

Re: Ping Re: Remove config.gcc support for *local* configurations

On 07/07/2011 05:49 PM, Joseph S. Myers wrote: Ping. This patch is pending review. Ok. Paolo

Re: [PATCH] Make VRP optimize useless conversions

Hi, On Thu, 7 Jul 2011, Richard Guenther wrote: > + tree rhs1 = gimple_assign_rhs1 (stmt); > + gimple def_stmt = SSA_NAME_DEF_STMT (rhs1); > + value_range_t *final, *inner; > + > + /* Obtain final and inner value-ranges for a conversion > + sequence (final-type)(intermediate-type)in

Re: [PATCH 4/6] Shrink-wrapping

On 07/07/11 15:34, Richard Sandiford wrote: > It seems a shame to have both (return) and (simple_return). You said > that we need the distinction in order to cope with targets like ARM, > whose (return) instruction actually performs some of the epilogue too. > It feels like the load of the saved r

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 7, 2011 at 5:47 PM, Michael Meissner wrote: > On Thu, Jul 07, 2011 at 10:59:36AM +0200, Richard Guenther wrote: >> On Thu, Jul 7, 2011 at 12:29 AM, Michael Meissner >> wrote: >> > This patch adds an option to not load the static chain (r11) for 64-bit >> > PowerPC >> > calls through

Re: CFT: Move unwinder to toplevel libgcc

On Thu, 2011-07-07 at 15:08 +0200, Rainer Orth wrote: > Tristan Gingold writes: > > >> Otherwise, the patch is unchanged from the original submission: > >> > >>[build] Move unwinder to toplevel libgcc > >>http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html > >> > >> Unfortunately, i

Re: [PATCH] Fix dead_debug_insert_before ICE (PR debug/49522, take 3)

> So, here is a new patch which doesn't need two loops, just might go a > little bit backwards to unchain dead_debug_use for the reset insn. > > It still needs the change of the gcc_assert (reg) into if (reg == NULL) > return;, because the dead->used bitmap is with this sometimes a false > positive

Ping Re: Remove config.gcc support for *local* configurations

Ping. This patch is pending review. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 07, 2011 at 10:59:36AM +0200, Richard Guenther wrote: > On Thu, Jul 7, 2011 at 12:29 AM, Michael Meissner > wrote: > > This patch adds an option to not load the static chain (r11) for 64-bit > > PowerPC > > calls through function pointers (or virtual function).  Most of the > > langu

Re: [PATCH] Fix folding of -(unsigned)(a * -b)

Hi, On Thu, 7 Jul 2011, Richard Guenther wrote: > Index: gcc/fold-const.c > === > --- gcc/fold-const.c (revision 175962) > +++ gcc/fold-const.c (working copy) > @@ -7561,7 +7561,7 @@ fold_unary_loc (location_t loc, enum tre >if

Re: Generic hwloop support library

On 07/05/11 21:25, Richard Sandiford wrote: > (Could you bootstrap this on x86_64 to check for things like that? That has no loop_end pattern so it wouldn't be much of a test, but a x86_64 x bfin compiler has no warnings in this file with the intptr_t thing fixed. > A C bootstrap only should be

Re: [ARM] Deprecate -mwords-little-endian

On 07/07/11 16:18, Richard Sandiford wrote: > Richard Earnshaw writes: >> On 29/06/11 12:28, Richard Sandiford wrote: >>> ARM has an option called -mwords-little-endian that provides big-endian >>> compatibility with pre-2.8 compilers. When I asked Richard about it, >>> he seemed to think it had

Re: [PATCH 4/6] Shrink-wrapping

Whee! Thanks for reviewing (reviving?) this old thing. I should be posting an up-to-date version of this, but for the moment it has to wait until dwarf2out is sorted out, and I'm rather busy with other stuff. I hope to squeeze this in in the not too distant future. I'll try to answer some of the

Re: PATCH [1/n] X32: Add initial -x32 support

On Thu, Jul 7, 2011 at 17:12, Uros Bizjak wrote: > On Thu, Jul 7, 2011 at 5:02 PM, H.J. Lu wrote: > >>> Did you even _think_ of looking at the sh configury, and do something >>> vaguely similar for x86? >>> >>> You should not duplicate t-linux64 at all.  Instead, in config.gcc set >>> m64/m32 as

Re: [ARM] Deprecate -mwords-little-endian

Richard Earnshaw writes: > On 29/06/11 12:28, Richard Sandiford wrote: >> ARM has an option called -mwords-little-endian that provides big-endian >> compatibility with pre-2.8 compilers. When I asked Richard about it, >> he seemed to think it had outlived its usefulness, so this patch >> deprecat

Re: [PATCH] Fix complex {*,/} real or real * complex handling in C FE (PR c/49644)

On Thu, 7 Jul 2011, Jakub Jelinek wrote: > On Thu, Jul 07, 2011 at 02:55:45PM +, Joseph S. Myers wrote: > > On Thu, 7 Jul 2011, Jakub Jelinek wrote: > > > For MULT_EXPR and TRUNC_DIV_EXPR, both sides of COMPLEX_EXPR contain > > > a copy of the non-complex operand, which means its side-effects

Re: PATCH [1/n] X32: Add initial -x32 support

On Thu, Jul 7, 2011 at 5:02 PM, H.J. Lu wrote: >> Did you even _think_ of looking at the sh configury, and do something >> vaguely similar for x86? >> >> You should not duplicate t-linux64 at all.  Instead, in config.gcc set >> m64/m32 as the default value for with_multilib_list on i386 biarch an

Re: [PATCH] Fix complex {*,/} real or real * complex handling in C FE (PR c/49644)

On Thu, Jul 07, 2011 at 02:55:45PM +, Joseph S. Myers wrote: > On Thu, 7 Jul 2011, Jakub Jelinek wrote: > > For MULT_EXPR and TRUNC_DIV_EXPR, both sides of COMPLEX_EXPR contain > > a copy of the non-complex operand, which means its side-effects can be > > evaluated twice. For PLUS_EXPR/MINUS_E

Re: PATCH [1/n] X32: Add initial -x32 support

On Thu, Jul 7, 2011 at 6:21 AM, Paolo Bonzini wrote: > Did you even _think_ of looking at the sh configury, and do something > vaguely similar for x86? > > You should not duplicate t-linux64 at all.  Instead, in config.gcc set > m64/m32 as the default value for with_multilib_list on i386 biarch an

Re: [Patch,testsuite]: Filter more test cases to fit target capabilities

On Jul 6, 2011, at 10:26 AM, Georg-Johann Lay wrote: > Hi, I am struggling against hundreds of fails in the testsuite because > many cases are not carefully written, e.g. stull like shifting an int > by 19 bits if int is only 16 bits wide. > Ok to commit? Ok.

Re: [PATCH][C] Fixup pointer-int-sum

On Thu, 7 Jul 2011, Joseph S. Myers wrote: > On Thu, 7 Jul 2011, Richard Guenther wrote: > > > not overflow (what is actually the C semantics - is the > > multiplication allowed to overflow for unsigned intop? If not > > Overflow is not allowed. Formally the multiplication is as-if to infinite

Re: [PATCH] Fix complex {*,/} real or real * complex handling in C FE (PR c/49644)

On Thu, 7 Jul 2011, Jakub Jelinek wrote: > Hi! > > For MULT_EXPR and TRUNC_DIV_EXPR, both sides of COMPLEX_EXPR contain > a copy of the non-complex operand, which means its side-effects can be > evaluated twice. For PLUS_EXPR/MINUS_EXPR they appear just in one of > the operands and thus it works

Re: [PATCH][C] Fixup pointer-int-sum

On Thu, 7 Jul 2011, Richard Guenther wrote: > not overflow (what is actually the C semantics - is the > multiplication allowed to overflow for unsigned intop? If not Overflow is not allowed. Formally the multiplication is as-if to infinite precision, and then there is undefined behavior if the

  1   2   >