[patch] more bitmap obstacks

Hello, This reduces peak memory usage for the small test case of PR54146 by 2GB. 24hrs ago peak memory was 9.4 GB in top, but with Richi's patches from yesterday and with this one, peak memory is now "only" 5.2GB. About 40% of that is in IRA and reload so there is still room for improvement, but c

Re: Commit: BFIN: Fix use of VEC_last macro in bfin.c

Hi Diego, Thanks Nick. I made the wrong fix here, sorry about that. I will be making more changes to VEC_ shortly. What's a good way for me to test them? All I was doing was building a variety of targets, just to make sure that a local, generic patch of my own did not break anything. If yo

Re: [bootstrap] Tentative fix for PR 54281

On Thu, 16 Aug 2012, Ian Lance Taylor wrote: > On Thu, Aug 16, 2012 at 12:12 PM, Diego Novillo wrote: > > > > This is the patch I'm currently testing. I need someone with a very old > > toolchain (4.1 or earlier) to also give this a try (the original problem > > does not occur in g++ more recent

[PATCH] More leak plugs for PR54146

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-08-16 Richard Guenther * tree-sra.c (modify_function): Free redirect_callers vector. * ipa-split.c (split_function): Free args_to_pass vector. * tree-vect-data-refs.c (vect_peeling_hash_get_lo

Re: [PATCH] Decrease integer-share-limit

On Thu, 16 Aug 2012, Jakub Jelinek wrote: > On Thu, Aug 16, 2012 at 04:44:03PM +0200, Richard Guenther wrote: > > On Thu, 16 Aug 2012, Paolo Carlini wrote: > > > On 08/16/2012 03:39 PM, Richard Guenther wrote: > > > > This decreases the integer-share-limit to make sure the TREE_VEC we > > > > allo

Re: [PATCH] More leak plugs for PR54146

On Fri, Aug 17, 2012 at 09:46:35AM +0200, Richard Guenther wrote: > --- gcc/tree-vect-slp.c (revision 190447) > +++ gcc/tree-vect-slp.c (working copy) > @@ -1858,8 +1862,11 @@ new_bb_vec_info (basic_block bb) > static void > destroy_bb_vec_info (bb_vec_info bb_vinfo) > { > + VEC (sl

Re: PATCH: Replace target MEMBER_TYPE_FORCES_BLK macro with a target hook

On Thu, Aug 16, 2012 at 4:40 PM, H.J. Lu wrote: > On Thu, Aug 16, 2012 at 3:09 AM, Richard Guenther > wrote: >> On Thu, Aug 16, 2012 at 1:50 AM, H.J. Lu wrote: >>> Hi, >>> >>> This patch replaces MEMBER_TYPE_FORCES_BLK with a target hook. I >>> also pass the type to the target hook in addition

Re: [PATCH] More leak plugs for PR54146

On Fri, 17 Aug 2012, Jakub Jelinek wrote: > On Fri, Aug 17, 2012 at 09:46:35AM +0200, Richard Guenther wrote: > > --- gcc/tree-vect-slp.c (revision 190447) > > +++ gcc/tree-vect-slp.c (working copy) > > @@ -1858,8 +1862,11 @@ new_bb_vec_info (basic_block bb) > > static void > > destroy_b

Re: [patch] more bitmap obstacks

On Fri, Aug 17, 2012 at 9:03 AM, Steven Bosscher wrote: > Hello, > > This reduces peak memory usage for the small test case of PR54146 by > 2GB. 24hrs ago peak memory was 9.4 GB in top, but with Richi's patches > from yesterday and with this one, peak memory is now "only" 5.2GB. > About 40% of tha

[PATCH, ARM] Don't unnecessarily clobber the flags for ADD Rd, Rd, Rm

Thumb2 add instructions of the form add Rd, Rm Are already 16-bit instructions, so turning them into addsRd, Rm is pointless. This patch adds support for this in the compiler and ensures that the conversion to ADDS is skipped in this case. The additional variant in arm

[Patch,AVR]: Use CC to compile gen-avr-mmcu-texi.c

http://gcc.gnu.org/viewcvs?view=revision&revision=190473 Committed this to compile gen-avr-mmcu-texi.c with the C compiler. Johann -- * config/avr/t-avr (gen-avr-mmcu-texi): Use $(CC) to compile gen-avr-mmcu-texi.c.

Commit: MEP: Use C++ to compile mep-pragma.

Hi DJ, I am applying the following patch as an obvious patch fix for building the MEP targeted port of gcc. It fixes the build rule for mep-pragma.o so that is uses the C++ compiler instead of the C compiler. Cheers Nick gcc/ChangeLog 2012-08-17 Nick Clifton * config/mep/t

Re: Reproducible gcc builds, gfortran, and -grecord-gcc-switches

On 16 August 2012 21:28, Jakub Jelinek wrote: > > On Thu, Aug 16, 2012 at 06:59:09PM +0200, Simon Baldwin wrote: > > On 16 August 2012 16:40, Michael Matz wrote: > > > > > > ,,, > > > > > > Do you have considered to use a new option flag (usable in the .opt files) > > > instead of a langhook? I.

Surprise! A new friend is looking for you.)

I am Kayleigh. I am 26 years and I really like spending nice time with my buddies. Yeah, it always brings me delight to go party, going to disco clubs, pubs and other places like these. It is always fun and interesting with me. And... I am so sexual! I even won the sexiest woman in our universi

Commit: IQ2000: Remove modes from

Hi Guys, I am applying the patch below to fix some problems building an iq2000-elf toolchain. The main problem is that the conditional branch patterns were specifying a mode for the comparison operator, which then fails to match the rtl generated by the compiler. The other problem is t

Commit: MCore: Fix building libgcc

Hi Guys, I am applying the patch below to fix a problem building libgcc for the mcore-elf target. The cbranchsi4 pattern was applying a mode to the comparison operator which was preventing it from matching rtl generated by the middle end. Cheers Nick gcc/ChangeLog 2012-08-17 Nick Cli

Commit: FR30: Fix building libgcc

Hi Guys, I am applying the patch below to fix building libgcc for the fr30-elf target. The problem was that the comparison patterns were applying a mode to the operator which prevents them from matching rtl generated by the middle-end. Cheers Nick gcc/ChangeLog 2012-08-17 Nick Clifto

RFA: LM32: Fix building libgcc

Hi Sebastien, Currently the lm32-elf target fails to configure libgcc because of a seg-fault whilst running the configuration checks: configure:3794: lm32-elf/gcc/xgcc [...] conftest.c xgcc: internal compiler error: Segmentation fault (program cc1) GCC goes into an infinite loop t

Re: [rtl, i386] combine concat+permutation

Ping http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00205.html (Cc: the nice reviewer of the previous patch) On Fri, 3 Aug 2012, Marc Glisse wrote: Hello, this is a follow up to the patch applied after this discussion: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00504.html It handles the -ma

[PATCH] Annotate GC bitmaps

This marks GTY bitmaps properly for most efficient marking. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2012-08-17 Richard Guenther * bitmap.h (struct bitmap_element_def): GTY annotate next/prev. (struct bitmap_head_def): GTY skip current

Re: [rtl, i386] combine concat+permutation

On Fri, Aug 03, 2012 at 10:47:25PM +0200, Marc Glisse wrote: > Hello, > > this is a follow up to the patch applied after this discussion: > http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00504.html > > It handles the -mavx __builtin_shuffle case mentioned there. > > It passes bootstrap (languages=

[PATCH][C++] Save memory and reallocations in name-lookup

This reduces the number of re-allocations and the amount of memory wasted by store_binding. Previously, on a cut-down testcase from PR54146 we can see (--enable-gather-detailed-mem-stats -fmem-report output): cp/name-lookup.c:5874 (store_binding) 12033504: 1.6% 8564032: 2.4%

Re: [Test] contrib/test_installed modified to set specific gcov

Ping one more time. 2012/8/10 Anna Tikhonova : > Ping. > > 2012/8/8 Anna Tikhonova : >> Hi, >> >> while running check for Android NDK compiler (I've used >> contrib/test_installed for it) I've noticed that gcov name is >> hardcoded in g++.dg/gcov/gcov.exp. >> All NDK x86 tools have prefix like i68

[PATCH][C++] Get rid of TREE_CHAIN use for TREE_VEC (NON_DEFAULT_TEMPLATE_ARGS_COUNT)

This gets rid of this field, pushing it into a short int in tree_base (hopefully 2^16 non-defaulted template args are enough ...). The existing code is a bit confusing because of the differences with respect to ENABLE_CHECKING, it has very little testcase coverage as well (a single testcase, g++.

Re: [PATCH][C++] Save memory and reallocations in name-lookup

On Fri, Aug 17, 2012 at 6:17 AM, Richard Guenther wrote: > > This reduces the number of re-allocations and the amount of memory > wasted by store_binding. Previously, on a cut-down testcase from > PR54146 we can see (--enable-gather-detailed-mem-stats -fmem-report > output): > > cp/name-lookup.c:

Re: [PATCH][C++] Save memory and reallocations in name-lookup

On Fri, Aug 17, 2012 at 6:17 AM, Richard Guenther wrote: > which means only 19516 reallocations and 350kb wasted memory. The > compile-time effects are neutral (name-lookup is 1.0+-0.05s on > the reduced testcase) - a slightly different version which omitted > the temporary vector but walked thi

[patch][RFC] 160-bits bitmap_element

Hello, On a 64-bits host we leave 32 bits of each bitmap_element unused. And actually, on a 32-bits host we do that too for GGC-allocated bitmaps (due to alignment). With this patch, we use those 32 bits by making BITMAP_WORD an unsigned int (instead of unsigned long) and having 5 elts per bitmap

Re: [patch][RFC] 160-bits bitmap_element

On Fri, Aug 17, 2012 at 1:46 PM, Steven Bosscher wrote: > Hello, > > On a 64-bits host we leave 32 bits of each bitmap_element unused. And > actually, on a 32-bits host we do that too for GGC-allocated bitmaps > (due to alignment). > > With this patch, we use those 32 bits by making BITMAP_WORD an

Re: [PATCH][C++] Save memory and reallocations in name-lookup

On Fri, 17 Aug 2012, Gabriel Dos Reis wrote: > On Fri, Aug 17, 2012 at 6:17 AM, Richard Guenther wrote: > > > > This reduces the number of re-allocations and the amount of memory > > wasted by store_binding. Previously, on a cut-down testcase from > > PR54146 we can see (--enable-gather-detailed

Re: [PATCH][C++] Save memory and reallocations in name-lookup

On Fri, Aug 17, 2012 at 06:41:37AM -0500, Gabriel Dos Reis wrote: > I am however concerned with: > > > static void > > store_bindings (tree names, VEC(cxx_saved_binding,gc) **old_bindings) > > { > > ! static VEC(tree,heap) *bindings_need_stored = NULL; > > I would be more comfortable to s

Re: [patch][RFC] 160-bits bitmap_element

On Fri, Aug 17, 2012 at 1:54 PM, Richard Guenther wrote: > Well, another effect of reducing the size of BITMAP_WORD is that > operations are not performed in a mode optimally using CPU regs > (did you check code generation differences on a 64bit host?). I did, on x86_64 and on powerpc64. The effe

Re: [patch][RFC] 160-bits bitmap_element

On Fri, Aug 17, 2012 at 2:04 PM, Steven Bosscher wrote: > On Fri, Aug 17, 2012 at 1:54 PM, Richard Guenther > wrote: >> Well, another effect of reducing the size of BITMAP_WORD is that >> operations are not performed in a mode optimally using CPU regs >> (did you check code generation differences

Re: [patch][RFC] 160-bits bitmap_element

On Fri, Aug 17, 2012 at 02:04:50PM +0200, Steven Bosscher wrote: > On Fri, Aug 17, 2012 at 1:54 PM, Richard Guenther > wrote: > > Well, another effect of reducing the size of BITMAP_WORD is that > > operations are not performed in a mode optimally using CPU regs > > (did you check code generation

Re: [patch][RFC] 160-bits bitmap_element

On Fri, Aug 17, 2012 at 2:12 PM, Richard Guenther wrote: > On Fri, Aug 17, 2012 at 2:04 PM, Steven Bosscher > wrote: >> On Fri, Aug 17, 2012 at 1:54 PM, Richard Guenther >> wrote: >>> Well, another effect of reducing the size of BITMAP_WORD is that >>> operations are not performed in a mode opt

Re: [bootstrap] Tentative fix for PR 54281

On 12-08-16 20:29 , Ian Lance Taylor wrote: I recommend that you add libintl.h to the AC_CHECK_HEADERS list in gcc/configure.ac Thanks. The attached patch implements the approach. Tested with --disable-nls and --enable-nls. Folks with 4.1 compilers, could you test it there? OK for trunk

Re: [patch][RFC] 160-bits bitmap_element

On Fri, Aug 17, 2012 at 02:16:12PM +0200, Richard Guenther wrote: > Or figure out if or why not the vectorizer does catch this (of course we do > not enable that with -O2 which we eventually should in a very conservative > mode). It might be helpful if we for the BITMAP_ELEMENT_WORDS == 5 case reo

Re: [bootstrap] Tentative fix for PR 54281

Hi! On Fri, Aug 17, 2012 at 08:23:02AM -0400, Diego Novillo wrote: > --- a/gcc/intl.h > +++ b/gcc/intl.h > @@ -27,8 +27,16 @@ > # define setlocale(category, locale) (locale) > #endif > > +/* If libintl.h is available, include it before testing for NLS. If we > + are building with --disable-

[PATCH] Fix m68k __sync_lock_test_and_set_1 definition

This fixes a warning about the definition not matching the builtin. Since the type is not actually used for accessing the data, this doesn't affect the generated code. Tested on m68k-linux and committed. Andreas. * config/m68k/linux-atomic.c (__sync_lock_test_and_set_1): Fix type

Re: Commit: BFIN: Fix use of VEC_last macro in bfin.c

On 12-08-17 03:10 , nick clifton wrote: Hi Diego, Thanks Nick. I made the wrong fix here, sorry about that. I will be making more changes to VEC_ shortly. What's a good way for me to test them? All I was doing was building a variety of targets, just to make sure that a local, generic patch

Re: [PATCH][C++] Save memory and reallocations in name-lookup

On Fri, Aug 17, 2012 at 6:55 AM, Jakub Jelinek wrote: > On Fri, Aug 17, 2012 at 06:41:37AM -0500, Gabriel Dos Reis wrote: >> I am however concerned with: >> >> > static void >> > store_bindings (tree names, VEC(cxx_saved_binding,gc) **old_bindings) >> > { >> > ! static VEC(tree,heap) *bind

Re: [C PATCH] -Wsizeof-pointer-memaccess warning

On 08/16/2012 09:10 PM, Jakub Jelinek wrote: + switch (DECL_FUNCTION_CODE (callee)) +{ +case BUILT_IN_STRNCMP: +case BUILT_IN_STRNCASECMP: +case BUILT_IN_STRNCPY: +case BUILT_IN_STRNCAT: + strop = true; + /* FALLTHRU */ +case BUILT_IN_MEMCPY: +case BUILT_IN

Re: Commit: BFIN: Fix use of VEC_last macro in bfin.c

Hi Diego, Would it be too much imposition for you to put this on the wiki? I would be happy to. Where do you think would be appropriate ? I would guess that somewhere off the Getting Started page (http://gcc.gnu.org/wiki/GettingStarted) would be best. Maybe a new item in the Tutorials se

Re: [patch][RFC] 160-bits bitmap_element

On Fri, Aug 17, 2012 at 2:21 PM, Jakub Jelinek wrote: > On Fri, Aug 17, 2012 at 02:16:12PM +0200, Richard Guenther wrote: >> Or figure out if or why not the vectorizer does catch this (of course we do >> not enable that with -O2 which we eventually should in a very conservative >> mode). > > It mi

Re: [C PATCH] -Wsizeof-pointer-memaccess warning

On Fri, Aug 17, 2012 at 02:52:34PM +0200, Florian Weimer wrote: > >+{ > >+case BUILT_IN_STRNCMP: > >+case BUILT_IN_STRNCASECMP: > >+case BUILT_IN_STRNCPY: > >+case BUILT_IN_STRNCAT: > >+ strop = true; > >+ /* FALLTHRU */ > >+case BUILT_IN_MEMCPY: > >+case BUILT

Re: [C PATCH] -Wsizeof-pointer-memaccess warning

On 08/17/2012 03:09 PM, Jakub Jelinek wrote: s/stpncopy/stpncpy/, yeah, I guess, we could do that for those too, but 1) I'd prefer to wait for the C++ FE change to go in first 2) {,v}snprintf would be much harder than the rest, as the size argument then isn't the last argument to the function, a

Re: [C PATCH] -Wsizeof-pointer-memaccess warning

On Fri, Aug 17, 2012 at 03:26:34PM +0200, Florian Weimer wrote: > On 08/17/2012 03:09 PM, Jakub Jelinek wrote: > > >s/stpncopy/stpncpy/, yeah, I guess, we could do that for those too, > >but 1) I'd prefer to wait for the C++ FE change to go in first > >2) {,v}snprintf would be much harder than the

Re: PATCH: Replace target MEMBER_TYPE_FORCES_BLK macro with a target hook

On Fri, Aug 17, 2012 at 1:02 AM, Richard Guenther wrote: > On Thu, Aug 16, 2012 at 4:40 PM, H.J. Lu wrote: >> On Thu, Aug 16, 2012 at 3:09 AM, Richard Guenther >> wrote: >>> On Thu, Aug 16, 2012 at 1:50 AM, H.J. Lu wrote: Hi, This patch replaces MEMBER_TYPE_FORCES_BLK with a targ

Re: [PATCH][C++] Get rid of TREE_CHAIN use for TREE_VEC (NON_DEFAULT_TEMPLATE_ARGS_COUNT)

On 08/17/2012 01:26 PM, Richard Guenther wrote: This gets rid of this field, pushing it into a short int in tree_base (hopefully 2^16 non-defaulted template args are enough ...). Honestly, I don't think it's a trivial issue. Often and often, while hacking the C++ front-end I noticed the integer

Re: PATCH: Replace target MEMBER_TYPE_FORCES_BLK macro with a target hook

On Fri, Aug 17, 2012 at 9:39 AM, H.J. Lu wrote: > Here is the updated patch. Steve, David, Sterling, can you take a look > at ia64, rs6000 and xtensa changes? > * config/rs6000/rs6000.c (TARGET_MEMBER_TYPE_FORCES_BLK): New > macro. > (rs6000_member_type_forces_blk): Ne

[patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

ing multiply operation. PR tree-ssa/54295 * tree-ssa-math-opts.c (is_widening_mult_p): Short-circuit when the stmt is already a widening multiply. Testsuite PR tree-ssa/54295 * gcc.c-torture/execute/20120817-1.c: New test. OK to commit once testing has comple

Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

On 17/08/12 15:04, Richard Earnshaw wrote: The fix is to make is_widening_mult_p note that it has been called with a WIDEN_MULT_EXPR and rather than decompose the operands again, to simply extract the existing operands, which have already been formulated correctly for a widening multiply operatio

Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

On 17/08/12 15:22, Andrew Stubbs wrote: > On 17/08/12 15:04, Richard Earnshaw wrote: >> The fix is to make is_widening_mult_p note that it has been called with >> a WIDEN_MULT_EXPR and rather than decompose the operands again, to >> simply extract the existing operands, which have already been form

Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

On 17/08/12 15:31, Richard Earnshaw wrote: On 17/08/12 15:22, Andrew Stubbs wrote: On 17/08/12 15:04, Richard Earnshaw wrote: The fix is to make is_widening_mult_p note that it has been called with a WIDEN_MULT_EXPR and rather than decompose the operands again, to simply extract the existing op

Re: [bootstrap] Tentative fix for PR 54281

On Fri, Aug 17, 2012 at 5:32 AM, Jakub Jelinek wrote: > > Will that handle even the case where without --disable-nls intl/ > creates its own libintl.h? Dunno which targets need that, but > I'd guess configury wouldn't find it in that case. So perhaps > it should be #if defined(HAVE_LIBINTL_H) ||

Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

On 17/08/12 15:39, Andrew Stubbs wrote: > On 17/08/12 15:31, Richard Earnshaw wrote: >> On 17/08/12 15:22, Andrew Stubbs wrote: >>> On 17/08/12 15:04, Richard Earnshaw wrote: The fix is to make is_widening_mult_p note that it has been called with a WIDEN_MULT_EXPR and rather than decompos

Re: Commit: BFIN: Fix use of VEC_last macro in bfin.c

On Fri, 17 Aug 2012, Diego Novillo wrote: > On 12-08-17 03:10 , nick clifton wrote: > > Hi Diego, > > > Thanks Nick. I made the wrong fix here, sorry about that. I will be > > > making more changes to VEC_ shortly. What's a good way for me to test > > > them? > > > > All I was doing was buildi

Re: Reproducible gcc builds, gfortran, and -grecord-gcc-switches

On Fri, 17 Aug 2012, Simon Baldwin wrote: > > You could have just added > > case OPT_cpp_: > > to the switch in gen_producer_string, instead of all this. > > Thanks. I was under the impression, apparently mistaken, that > OPT_cpp_ exists only if fortran is enabled. OPT_* for Fortran options o

[AArch64] Add new testcases and improve diagnostics

Hi, I've just committed the attached patch on the AArch64 branch to add new testcases and improve diagnostics. Thanks Sofiane - r190481 | sofiane | 2012-08-17 15:53:50 +0100 (Fri, 17 Aug 2012) | 11 lines [AArch64] Add new testcases to improve diagnostics. gcc/ * co

Re: [bootstrap] Tentative fix for PR 54281

On 12-08-17 08:32 , Jakub Jelinek wrote: Hi! On Fri, Aug 17, 2012 at 08:23:02AM -0400, Diego Novillo wrote: --- a/gcc/intl.h +++ b/gcc/intl.h @@ -27,8 +27,16 @@ # define setlocale(category, locale) (locale) #endif +/* If libintl.h is available, include it before testing for NLS. If we +

Re: Commit: BFIN: Fix use of VEC_last macro in bfin.c

On 12-08-17 10:52 , Joseph S. Myers wrote: On Fri, 17 Aug 2012, Diego Novillo wrote: On 12-08-17 03:10 , nick clifton wrote: Hi Diego, Thanks Nick. I made the wrong fix here, sorry about that. I will be making more changes to VEC_ shortly. What's a good way for me to test them? All I was

[AArch64] Use effective-target keyword to test for endianness

Hi, I've just committed the attached patch on the AArch64 branch to use effective-target keyword to test for endianness. Thanks Sofiane - r190482 | sofiane | 2012-08-17 16:02:20 +0100 (Fri, 17 Aug 2012) | 9 lines [AArch64] Use effective-target to check for big endian gcc/t

Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

On 17/08/12 15:47, Richard Earnshaw wrote: If we don't have a 16x16->64 mult operation then after step 1 we'll still have a MULT_EXPR, not a WIDEN_MULT_EXPR, so when we reach step2 there's nothing to short circuit. Unless, of course, you're expecting us to get step1 -> 16x16->32 widen mult step

Re: [bootstrap] Tentative fix for PR 54281

On Fri, Aug 17, 2012 at 10:58:25AM -0400, Diego Novillo wrote: > Sounds reasonable. Amended patch attached. > OK for trunk? Yes, except for: > diff --git a/gcc/ChangeLog b/gcc/ChangeLog > index c9a81d1..43b0af7 100644 > --- a/gcc/ChangeLog > +++ b/gcc/ChangeLog > @@ -213,7 +222,7 @@ > * c

[AArch64] implement vmlsq_laneq_*

Hi, I've just committed the attached patch on the AArch64 branch to implement vmlsq_laneq_*. Thanks Sofiane - r190484 | sofiane | 2012-08-17 16:15:49 +0100 (Fri, 17 Aug 2012) | 11 lines Tejas Belagod [AArch64] Implement vmlsq_laneq_*. gcc/ * config/aarch64/arm_n

Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

On 17/08/12 16:06, Andrew Stubbs wrote: > On 17/08/12 15:47, Richard Earnshaw wrote: >> If we don't have a 16x16->64 mult operation then after step 1 we'll >> still have a MULT_EXPR, not a WIDEN_MULT_EXPR, so when we reach step2 >> there's nothing to short circuit. >> >> Unless, of course, you're e

[AArch64] implement FSQRT in RTL.

Hi, I've just committed the attached patch on the AArch64 branch to implement FSQRT in RTL. Thanks Sofiane - r190485 | sofiane | 2012-08-17 16:22:28 +0100 (Fri, 17 Aug 2012) | 12 lines 2012-08-17 Tejas Belagod [AArch64] Implement FSQRT in RTL. * config/aarch64/aarch64-

[AArch64] Do not mix statements with declarations

Hi, I've just committed the attached patch on the AArch64 branch to fix a style issue related to mixing statements with declarations. Thanks Sofiane - r190486 | sofiane | 2012-08-17 16:26:47 +0100 (Fri, 17 Aug 2012) | 7 lines 2012-08-17 Marcus Shawcroft [AArch64] Do not mix sta

Re: [bootstrap] Tentative fix for PR 54281

On Fri, Aug 17, 2012 at 11:05 AM, Jakub Jelinek wrote: > On Fri, Aug 17, 2012 at 10:58:25AM -0400, Diego Novillo wrote: >> Sounds reasonable. Amended patch attached. > >> OK for trunk? > > Yes, except for: > >> diff --git a/gcc/ChangeLog b/gcc/ChangeLog >> index c9a81d1..43b0af7 100644 >> --- a/g

Re: PATCH: Replace target MEMBER_TYPE_FORCES_BLK macro with a target hook

> Here is the updated patch. Steve, David, Sterling, can you take a look > at ia64, rs6000 and xtensa changes? > > Thanks. The ia64 part looks OK. Steve Ellcey sell...@mips.com

Re: [PATCH] Set correct source location for deallocator calls

On 2012-08-10 20:38, Dehao Chen wrote: > + // { dg-final { scan-assembler "1 28 0" } } This test case isn't going to work except with dwarf2, and with gas. You can use -dA so that you can scan for file.c:line. There are other examples in the testsuite. This doesn't belong in guality. It belong

Re: PATCH: Replace target MEMBER_TYPE_FORCES_BLK macro with a target hook

On Fri, Aug 17, 2012 at 6:59 AM, David Edelsohn wrote: > > On Fri, Aug 17, 2012 at 9:39 AM, H.J. Lu wrote: > > > Here is the updated patch. Steve, David, Sterling, can you take a > > look > > at ia64, rs6000 and xtensa changes? > > > * config/rs6000/rs6000.c (TARGET_MEMBER_TYPE_FORCES_

[RFC] Warning for potentially unbound writes to function parameters

In some real-world code, I noticed a curious pattern: using the unsafe string functions on function parameter arguments. This leads to gets()-style unsafe APIs. I've looked at how to implement a warning for this, and came up with the attached patch. Do you think this makes sense? 1 #

[PATCH, rtl-optimization]: Fix PR46829, ICE in spill_failure with -fschedule-insns [was: Fixing instability of -fschedule-insns for x86]

Hello! Attached patch fixes one of the critical problems in combine.c: combine pass blindly propagates hard registers into insn patterns and this way creates partially invalid instructions. Most of the times, reload is able to fix these inconsistencies, but operands with invalid hard registers blo

Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

On 17/08/12 16:20, Richard Earnshaw wrote: > Ok, in which case we have to give is_widening_mult_rhs_p enough smarts > to not strip > > (s32)u32 > > and return u32. > > I'll have another think about it. Take two. This version should address your concerns about handling (u32)u16 *

Re: [google] Modification of gcov pmu format to reduce gcda size bloat (issue 6427063)

Hi Rong, Could you take a look at the patch I mailed to gcc-patches when you get a chance? It reduces the gcda size bloat issue by replacing gcov_pmu data with a filetag field that holds the position of the correct filename inside of the newly added string table. Thanks, Chris http://coderevie

Re: [AArch64] implement FSQRT in RTL.

On Fri, Aug 17, 2012 at 8:26 AM, Sofiane Naci wrote: > Hi, > > I've just committed the attached patch on the AArch64 branch to implement > FSQRT in RTL. Maybe add a testcase which tests that sqrt gets vectorized? Thanks, Andrew > > Thanks > Sofiane > > - > > r190485 | sofiane | 2012-08-17

Re: Merge C++ conversion into trunk (0/6 - Overview)

On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote: On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey wrote: "Gaby" == Gabriel Dos Reis writes: Tom> I asked Keith to resurrect his patch for this. [snip] I hope this will be acceptable all around. OK, that sounds reasonable. I have committed a pat

Re: Merge C++ conversion into trunk (0/6 - Overview)

On Fri, Aug 17, 2012 at 10:45 AM, Keith Seitz wrote: > On 08/15/2012 11:25 AM, Gabriel Dos Reis wrote: >> >> On Wed, Aug 15, 2012 at 1:21 PM, Tom Tromey wrote: "Gaby" == Gabriel Dos Reis writes: >>> >>> >>> Tom> I asked Keith to resurrect his patch for this. > > [snip] > >>> I

Re: [PATCH][C++] Get rid of TREE_CHAIN use for TREE_VEC (NON_DEFAULT_TEMPLATE_ARGS_COUNT)

On Aug 17, 2012, at 6:58 AM, Paolo Carlini wrote: > On 08/17/2012 01:26 PM, Richard Guenther wrote: >> This gets rid of this field, pushing it into a short int in tree_base >> (hopefully 2^16 non-defaulted template args are enough ...). > Honestly, I don't think it's a trivial issue. Love to hear

Re: [PATCH, rtl-optimization]: Fix PR46829, ICE in spill_failure with -fschedule-insns [was: Fixing instability of -fschedule-insns for x86]

On Fri, Aug 17, 2012 at 6:36 PM, Uros Bizjak wrote: > 2012-08-17 Uros Bizjak > > PR rtl-optimization/46829 > * combine.c (recog_for_combine): Check operand constraints > in case hard registers were propagater into insn pattern. > > testsuite/ChangeLog: > > 2012-08-17 U

Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

On 17/08/12 16:20, Richard Earnshaw wrote: No, given a u16xu16->u64 operation in the code, and that the arch doesn't have such an opcode, I'd expect to get step1 -> (u32)u16 x (u32)u16 -> u64 Hmm, I would have thought that would be more costly than (u64)(u16 x u16 -> u32) You might

Re: [PATCH][C++] Get rid of TREE_CHAIN use for TREE_VEC (NON_DEFAULT_TEMPLATE_ARGS_COUNT)

On Fri, Aug 17, 2012 at 1:03 PM, Mike Stump wrote: > On Aug 17, 2012, at 6:58 AM, Paolo Carlini wrote: >> On 08/17/2012 01:26 PM, Richard Guenther wrote: >>> This gets rid of this field, pushing it into a short int in tree_base >>> (hopefully 2^16 non-defaulted template args are enough ...). >> Ho

Re: [RFC] Warning for potentially unbound writes to function parameters

On Fri, Aug 17, 2012 at 11:22 AM, Florian Weimer wrote: > In some real-world code, I noticed a curious pattern: using the unsafe > string functions on function parameter arguments. This leads to > gets()-style unsafe APIs. > > I've looked at how to implement a warning for this, and came up with t

Re: [patch, tree-ssa] PR54295 Incorrect value extension in widening multiply-accumulate

On 17/08/12 18:05, Richard Earnshaw wrote: Take two. This version should address your concerns about handling (u32)u16 * (u32)u16 -> u64 We now look at each operand directly, but when doing so we check whether the operand is the same size as the result or not. When it is, we can strip

Re: PATCH: PR target/20020: 128 bit structs not targeted to TImode

On Thu, Aug 16, 2012 at 7:41 PM, H.J. Lu wrote: > My email sent to gcc-patches@gcc.gnu.org was bounced as spam. I am > resending it. This patch defines both MAX_FIXED_MODE_SIZE and > MEMBER_TYPE_FORCES_BLK for i386. MEMBER_TYPE_FORCES_BLK is needed so > that we always put union with XFmode fie

Re: PATCH: PR target/20020: 128 bit structs not targeted to TImode

On Fri, Aug 17, 2012 at 12:35 PM, Uros Bizjak wrote: > On Thu, Aug 16, 2012 at 7:41 PM, H.J. Lu wrote: > >> My email sent to gcc-patches@gcc.gnu.org was bounced as spam. I am >> resending it. This patch defines both MAX_FIXED_MODE_SIZE and >> MEMBER_TYPE_FORCES_BLK for i386. MEMBER_TYPE_FORCES

Re: [RFC] Warning for potentially unbound writes to function parameters

On 08/17/2012 09:15 PM, Gabriel Dos Reis wrote: Hmm, I think it help a little bit if you could expand on where exactly the danger the patch is trying to prevent is, and where what does "unbound parameter" refer to or mean? (I don't know what an unbound parameter is) Sorry for being unclear.

Re: [PATCH, rtl-optimization]: Fix PR46829, ICE in spill_failure with -fschedule-insns [was: Fixing instability of -fschedule-insns for x86]

Hi, On Fri, 2012-08-17 at 20:34 +0200, Uros Bizjak wrote: > On Fri, Aug 17, 2012 at 6:36 PM, Uros Bizjak wrote: > > > 2012-08-17 Uros Bizjak > > > > PR rtl-optimization/46829 > > * combine.c (recog_for_combine): Check operand constraints > > in case hard registers were

[PATCH] Fix -fcompare-debug failure in fwprop (PR rtl-optimization/54294)

Hi! As discussed in the PR, this patch, originally posted for PR42728, makes sure the shortcut in all_uses_available_at is used on the same insns in between -g and -g0, it is the second time a -fcompare-debug failure resulted from NEXT_INSN being something different with -g, so IMHO it is desirabl

Re: [PATCH, rtl-optimization]: Fix PR46829, ICE in spill_failure with -fschedule-insns [was: Fixing instability of -fschedule-insns for x86]

On Fri, Aug 17, 2012 at 9:58 PM, Oleg Endo wrote: >> > 2012-08-17 Uros Bizjak >> > >> > PR rtl-optimization/46829 >> > * combine.c (recog_for_combine): Check operand constraints >> > in case hard registers were propagater into insn pattern. >> > >> > testsuite/ChangeLog

[PATCH] Fix AVR fallout

Hi! I see these warnings/errors right now: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-s

Re: RFA: Support infinity, NaN, and denormalized numbers in floatformat.c

On Thu, Aug 16, 2012 at 9:20 AM, Andreas Schwab wrote: > > * floatformat.c (floatformat_to_double): Correctly handle numbers > between 1 and 2. Simplify handling of denormal number. > (main): Test with 1.1. This is OK. Thanks. Ian

Re: [PATCH, rtl-optimization]: Fix PR46829, ICE in spill_failure with -fschedule-insns [was: Fixing instability of -fschedule-insns for x86]

On Fri, 2012-08-17 at 22:32 +0200, Uros Bizjak wrote: > Yes, x86_64 also has register passing convention. So, i.e.: > > --cut here-- > int foo (int a, int b, int c) > { > return a + b + c; > } > --cut here-- > > expands to: > > (note 6 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK) > (insn 2 6 3 2

Re: Inheritance of gfc_symbol / gfc_component

Following up on myself: On 2012-08-16 14:59, Tobias Schlüter wrote: A place where C++ inheritance is a trivial improvement is the red-black tree used for storing various objects (gfc_symtree, gfc_gsymbol, gfc_st_label, I think). This is currently implemented with macro-based inheritance. It i

Re: [PATCH] Set correct source location for deallocator calls

Hi, Richard, Thanks for the review. I've addressed most of the issues except the java unittest (see comments below). The new patch is attached in the end of this email. Thanks, Dehao On Fri, Aug 17, 2012 at 8:47 AM, Richard Henderson wrote: > On 2012-08-10 20:38, Dehao Chen wrote: >> + // { dg-

[google/gcc-4_7] Fix ICE in output_pubnames where union contains a ctor

This patch is for the google/gcc-4_7 branch. I'll submit it for trunk after the Fission patches have gone in. When adding names to the pubnames table (-gsplit-dwarf or -gpubnames), a method within a union may not get handled properly, sometimes resulting in an internal compiler error in output_pu

Always define USE_PT_GNU_EH_FRAME in crtstuff.c for glibc

Bootstrapping cross toolchains using glibc is an unduly complicated process involving multiple GCC builds and sometimes multiple glibc builds or glibc header installs. Something like the ideal bootstrap process is described at . I put som

Re: [google/gcc-4_7] Fix ICE in output_pubnames where union contains a ctor

On Fri, Aug 17, 2012 at 3:09 PM, Cary Coutant wrote: > This patch is for the google/gcc-4_7 branch. I'll submit it for trunk > after the Fission patches have gone in. > > When adding names to the pubnames table (-gsplit-dwarf or -gpubnames), > a method within a union may not get handled properly,

Re: [google/gcc-4_7] Fix ICE in output_pubnames where union contains a ctor

> OK for Google 4.7 Thanks, committed at r190494. -cary

Re: Always define USE_PT_GNU_EH_FRAME in crtstuff.c for glibc

On Fri, Aug 17, 2012 at 3:14 PM, Joseph S. Myers wrote: > Bootstrapping cross toolchains using glibc is an unduly complicated > process involving multiple GCC builds and sometimes multiple glibc > builds or glibc header installs. > > Something like the ideal bootstrap process is described at >

  1   2   >