Re: Fixup INTEGER_CST

On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka wrote: >> On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka wrote: >> > Hi, >> > I added a santy check that after fixup all types that lost in the merging >> > are >> > really dead. And it turns out we have some zombies around. >> > >> > INTEGER_CST needs s

Re: handle isl and cloog in contrib/download_prerequisites

On Mon, Oct 8, 2012 at 3:16 AM, Jonathan Wakely wrote: > On 7 October 2012 21:31, Manuel López-Ibáñez wrote: >> On 7 October 2012 22:13, Jonathan Wakely wrote: >>> >>> On Oct 7, 2012 12:00 AM, "NightStrike" wrote: On Sat, Oct 6, 2012 at 7:30 AM, Manuel López-Ibáñez wrote: >

Re: [lra] patch to speed more compilation of PR54146

On Sun, Oct 7, 2012 at 11:27 PM, Steven Bosscher wrote: > On Sun, Oct 7, 2012 at 5:59 PM, Vladimir Makarov wrote: >> The following patch speeds LRA up more on PR54146. Below times for >> compilation of the test on gcc17.fsffrance.org (an AMD machine): >> >> Before: >> real=1214.71 user=1192.05 sy

Re: [ping patch] Predict for loop exits in short-circuit conditions

On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen wrote: > Attached is the updated patch. Yes, if we add a VRP pass before > profile pass, this patch would be unnecessary. Should we add a VRP > pass? No, we don't want VRP in early optimizations. Richard. > Thanks, > Dehao > > On Sat, Oct 6, 2012 at 9:

[Patch ARM] Fix that miss DMB instruction for ARMv6-M

Hi, When running libstdc++ regression test on Cortex-M0, the case 49445.cc fails with error message: /tmp/ccMqZdgc.o: In function `std::atomic::load(std::memory_order) const':^M /home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none-eabi/armv6-m/ libstdc++-v3/include/atomic:202: undefined

Re: handle isl and cloog in contrib/download_prerequisites

On 8 October 2012 09:18, Richard Guenther wrote: > On Mon, Oct 8, 2012 at 3:16 AM, Jonathan Wakely wrote: >> On 7 October 2012 21:31, Manuel López-Ibáñez wrote: >>> On 7 October 2012 22:13, Jonathan Wakely wrote: On Oct 7, 2012 12:00 AM, "NightStrike" wrote: > > On Sat, Oct 6,

[testsuite] Minor housekeeping work

Recent tests added to gcc.dg/tree-ssa don't clean up after themselves. Tested on x86_64-suse-linux, applied on the mainline as obvious. 2012-10-08 Eric Botcazou * gcc.dg/tree-ssa/slsr-30.c: Use correct cleanup directive. * gcc.dg/tree-ssa/attr-hotcold-2.c: Likewise. *

Re: [lra] patch to speed more compilation of PR54146

On Mon, Oct 08, 2012 at 09:20:47AM +0200, Richard Guenther wrote: > On Sun, Oct 7, 2012 at 11:27 PM, Steven Bosscher > wrote: > > The next bottle-neck in my timings is in > > lra-eliminate.c:lra_eliminate(), in this loop: > > > >FOR_EACH_BB (bb) > > FOR_BB_INSNS_SAFE (bb, insn, temp) > >

Re: [PATCH] Fix PR54489 - FRE needing AVAIL_OUT

On Fri, 5 Oct 2012, Steven Bosscher wrote: > On Fri, Sep 14, 2012 at 2:26 PM, Richard Guenther wrote: > > If you can figure out a better name for the function we should > > probably move it to cfganal.c > > It looks like my previous e-mail about this appears to have gone got > somehow, so retry:

Re: vec_cond_expr adjustments

On Fri, Oct 5, 2012 at 5:01 PM, Marc Glisse wrote: > [I am still a little confused, sorry for the long email...] > > > On Tue, 2 Oct 2012, Richard Guenther wrote: > > + if (TREE_CODE (op0) == VECTOR_CST && TREE_CODE (op1) == VECTOR_CST) > +{ > + int count = VECTOR_CST_NELTS (

Re: [ping patch] Predict for loop exits in short-circuit conditions

> On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen wrote: > > Attached is the updated patch. Yes, if we add a VRP pass before > > profile pass, this patch would be unnecessary. Should we add a VRP > > pass? > > No, we don't want VRP in early optimizations. I am not quite sure about that. VRP 1) make

Re: patch to fix constant math - second small patch

On Sat, Oct 6, 2012 at 12:48 AM, Kenneth Zadeck wrote: > This patch adds machinery to genmodes.c so that largest possible sizes of > various data structures can be determined at gcc build time. These > functions create 3 symbols that are available in insn-modes.h: > MAX_BITSIZE_MODE_INT - the bit

Re: patch to fix constant math - third small patch

On Sat, Oct 6, 2012 at 5:55 PM, Kenneth Zadeck wrote: > This is the third patch in the series of patches to fix constant math. > this one changes some predicates at the rtl level to use the new predicate > CONST_SCALAR_INT_P. > I did not include a few that were tightly intertwined with other chang

Re: Fixup INTEGER_CST

> On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka wrote: > >> On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka wrote: > >> > Hi, > >> > I added a santy check that after fixup all types that lost in the > >> > merging are > >> > really dead. And it turns out we have some zombies around. > >> > > >> > INT

Re: Check that unlinked uses do not contain ssa-names when renaming.

On Sun, Oct 7, 2012 at 12:44 PM, Tom de Vries wrote: > Richard, > > attached patch checks that unlinked uses do not contain ssa-names when > renaming. > > This assert triggers when compiling (without the fix) the PR54735 example. > > AFAIU, it was due to chance that we caught the PR54735 bug by h

Re: patch to fix constant math

On Sun, Oct 7, 2012 at 4:58 PM, Kenneth Zadeck wrote: > > On 10/07/2012 09:19 AM, Richard Guenther wrote: >>> >>> >In fact, you could argue that the tree level did it wrong (not that i am >>> >suggesting to change this). But it makes me think what was going on >>> > when >>> >the decision to mak

Re: [ping patch] Predict for loop exits in short-circuit conditions

On Mon, Oct 8, 2012 at 11:04 AM, Jan Hubicka wrote: >> On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen wrote: >> > Attached is the updated patch. Yes, if we add a VRP pass before >> > profile pass, this patch would be unnecessary. Should we add a VRP >> > pass? >> >> No, we don't want VRP in early opt

Re: vec_cond_expr adjustments

On Mon, 8 Oct 2012, Richard Guenther wrote: VEC_COND_EXPR is more complicated. We could for instance require that it takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon thing are equivalent). Which would leave to decide what the expansion of vec_cond_expr passes to the target

Re: Fixup INTEGER_CST

On Mon, Oct 8, 2012 at 11:18 AM, Jan Hubicka wrote: >> On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka wrote: >> >> On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka wrote: >> >> > Hi, >> >> > I added a santy check that after fixup all types that lost in the >> >> > merging are >> >> > really dead. And

Re: vec_cond_expr adjustments

On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse wrote: > On Mon, 8 Oct 2012, Richard Guenther wrote: > >>> VEC_COND_EXPR is more complicated. We could for instance require that it >>> takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon >>> thing are equivalent). Which would leave

Re: Fixup INTEGER_CST

> > 2) As we query the type_hash while we are rewritting the types, > > we run into instability of the hashtable. This manifests itself > > as an ICE when one adds sanity check that while merging function > > types their arg types are equivalent, too. > > This ICEs compiling i

Re: [ping patch] Predict for loop exits in short-circuit conditions

> On Mon, Oct 8, 2012 at 11:04 AM, Jan Hubicka wrote: > >> On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen wrote: > >> > Attached is the updated patch. Yes, if we add a VRP pass before > >> > profile pass, this patch would be unnecessary. Should we add a VRP > >> > pass? > >> > >> No, we don't want VR

RE: [Patch] Fix PR53397

Hi Richard, I have incorporated your comments. > Yes, call dump_mem_ref then, instead of repeating parts of its body. Reference object is not yet created at the place we check for invariance. It is still a tree expression. I created a common function and used at all places to dump the "step

Re: [RFC] Make vectorizer to skip loops with small iteration estimate

On Sat, Oct 6, 2012 at 11:34 AM, Jan Hubicka wrote: > Hi, > I benchmarked the patch moving loop header copying and it is quite noticeable > win. > > Some testsuite updating is needed. In many cases it is just because the > optimizations are now happening earlier. > There are however few testusite

[C++ Patch/RFC] PR 54194

Hi, in this PR submitter points out that in the -Wparentheses warning, for, eg, char in[4]={0}, out[6]; out[1] = in[1] & 0x0F | ((in[3] & 0x3C) << 2); warning: suggest parentheses around arithmetic in operand of ‘|’ [-Wparentheses] the caret points to end of the expression, ie the final clos

[wwwdocs,avr]: Deprecate/remove -mshort-calls, --with-avrlibc is default

Applied the following changes to 4.7/4.8 release notes caveats. Index: htdocs/gcc-4.7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v retrieving revision 1.127 retrieving revision 1.128 diff -u -p -r1.127 -

Re: [ping patch] Predict for loop exits in short-circuit conditions

On Mon, Oct 8, 2012 at 12:01 PM, Jan Hubicka wrote: >> On Mon, Oct 8, 2012 at 11:04 AM, Jan Hubicka wrote: >> >> On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen wrote: >> >> > Attached is the updated patch. Yes, if we add a VRP pass before >> >> > profile pass, this patch would be unnecessary. Should

Re: [Patch] Fix PR53397

On Mon, Oct 8, 2012 at 12:01 PM, Kumar, Venkataramanan wrote: > Hi Richard, > > I have incorporated your comments. > >> Yes, call dump_mem_ref then, instead of repeating parts of its body. > > Reference object is not yet created at the place we check for invariance. It > is still a tree expressi

Re: [lra] patch to speed more compilation of PR54146

On Mon, Oct 8, 2012 at 10:18 AM, Jakub Jelinek wrote: >> > I'm playing with a patch to expand the insns_with_changed_offsets >> > bitmap to an sbitmap, and will send a patch if this works better. >> >> Or make insns_with_changed_offsets a VEC of insns (or a pointer-set). > > Or use temporarily som

Re: [lra] patch to speed more compilation of PR54146

On Sun, Oct 7, 2012 at 5:59 PM, Vladimir Makarov wrote: > * lra-lives.c (lra_start_point_ranges, lra_finish_point_ranges): > Remove. > (process_bb_lives): Change start regno in > EXECUTE_IF_SET_IN_BITMAP. Iterate on DF_LR_IN (bb) instead of > pseudos_live_th

[RFC] Implement load sinking in loops

Hi, we recently noticed that, even at -O3, the compiler doesn't figure out that the following loop is dumb: #define SIZE 64 int foo (int v[]) { int r; for (i = 0; i < SIZE; i++) r = v[i]; return r; } which was a bit of a surprise. On second thoughts, this isn't entirely unexpecte

Re: [RFC] Make vectorizer to skip loops with small iteration estimate

> On Sat, Oct 6, 2012 at 11:34 AM, Jan Hubicka wrote: > > Hi, > > I benchmarked the patch moving loop header copying and it is quite > > noticeable win. > > > > Some testsuite updating is needed. In many cases it is just because the > > optimizations are now happening earlier. > > There are howev

Re: Scheduler: Save state at the end of a block

On 08/13/2012 05:42 PM, Vladimir Makarov wrote: > On 08/13/2012 06:32 AM, Bernd Schmidt wrote: >> This is a small patch for sched-rgn that attempts to save DFA state at >> the end of a basic block and re-use it in successor blocks. This was a >> customer-requested optimization; I've not seen it mak

[RFC] Fix PR rtl-optimization/54315 (partially)

Hi, this PR is about the other path in the RTL expander where a temporary is created on the stack for a value returned in registers: BLKmode structures returned in registers without PARALLELs, i.e. for which the back-end is permitted (but not required) to create (REG:BLK). The canonical exampl

Re: patch to fix constant math - third small patch

yes, my bad. here it is with the patches. On 10/06/2012 11:55 AM, Kenneth Zadeck wrote: This is the third patch in the series of patches to fix constant math. this one changes some predicates at the rtl level to use the new predicate CONST_SCALAR_INT_P. I did not include a few that were tight

[PATCH] Remove my_rev_post_order_compute

This replaces my_rev_post_order_compute in PRE by the already existing inverted_post_order_compute, with the necessary adjustments. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-10-08 Richard Guenther * tree-ssa-pre.c (postorder_num): New global.

[PATCH] Fix PR54825

This fixes PR54825, properly FRE/PRE vector BIT_FIELD_REFs. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-10-08 Richard Guenther PR tree-optimization/54825 * tree-ssa-sccvn.c (vn_nary_length_from_stmt): Handle BIT_FIELD_REF. (init_vn_nar

Re: patch to fix constant math - third small patch

On Mon, Oct 8, 2012 at 1:36 PM, Kenneth Zadeck wrote: > yes, my bad. here it is with the patches. Just for the record, ok! Thanks, Richard. > On 10/06/2012 11:55 AM, Kenneth Zadeck wrote: >> >> This is the third patch in the series of patches to fix constant math. >> this one changes some pre

Re: [PATCH] PR 53528 c++/ C++11 Generalized Attribute support

Jason Merrill writes: > OK. Thanks. Committed to trunk at revision r192199. -- Dodji

Re: RFA: darwin PATCH to fix build, internal visibility

> > It appears that the patch should also special case the "scan-assembler > > .internal.*Foo.methodEv" > > tests in g++.dg/ext/visibility/pragma-override1.C and > > g++.dg/ext/visibility/pragma-override2.C > > on darwin as well... > > Done, thanks. Jason, These tests are still failing on d

Re: [RFC] Implement load sinking in loops

On Mon, Oct 8, 2012 at 12:38 PM, Eric Botcazou wrote: > Hi, > > we recently noticed that, even at -O3, the compiler doesn't figure out that > the following loop is dumb: > > #define SIZE 64 > > int foo (int v[]) > { > int r; > > for (i = 0; i < SIZE; i++) > r = v[i]; > > return r; > } >

Re: [RFC] Implement load sinking in loops

On Mon, Oct 8, 2012 at 2:32 PM, Richard Guenther wrote: > On Mon, Oct 8, 2012 at 12:38 PM, Eric Botcazou wrote: >> Hi, >> >> we recently noticed that, even at -O3, the compiler doesn't figure out that >> the following loop is dumb: >> >> #define SIZE 64 >> >> int foo (int v[]) >> { >> int r; >>

gcc/lto/lto.c: Free lto_file struct after closing the file

lto_obj_file_open allocates: lo = XCNEW (struct lto_simple_object); However, the data is never freed - neither explicitly nor in lto_obj_file_close. In the attached patch, I free the memory now after the call to lto_obj_file_close. Build and regtested on x86-64-gnu-linux. OK for the trunk?

Re: gcc/lto/lto.c: Free lto_file struct after closing the file

On Mon, Oct 8, 2012 at 2:39 PM, Tobias Burnus wrote: > lto_obj_file_open allocates: > lo = XCNEW (struct lto_simple_object); > However, the data is never freed - neither explicitly nor in > lto_obj_file_close. > > In the attached patch, I free the memory now after the call to > lto_obj_file_clos

Re: [lra] another patch to speed more compilation of PR54146

On Mon, Oct 8, 2012 at 1:00 AM, Steven Bosscher wrote: > Hello, > > This patch changes the worklist-like bitmap in lra_eliminate() to an > sbitmap. Effect on compile time: I have another patch to also make lra_constraint_insn_stack_bitmap. Without patch: log.0: LRA non-specific: 46.94

Re: [patch] Add option to compute "reaching and live definitions"

Il 07/10/2012 19:18, Steven Bosscher ha scritto: > Hello, > > The attached patch adds a DF changeable flag to compute a subset of > reaching definitions that are also live at the program points they > reach. This is an idea I discussed with Paolo many years ago already, > but until today it hadn't

[Patch] Fix PR52945

The following patch fixes PR52945 on Darwin. It as beem approved by Jan Hubicka in PR52945#c5. Since I don't have write permission, could someone commit it for me? TIA Dominique 2012-10-08 Dominique d'Humieres PR gcc/52945 * testsuite/gcc.dg/lto/pr52634_0.c: skip the test on

Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure

On Android NDK libstdc++ is configured, built and packaged separately. The problem is not dependency on libgcc sources but rather dependency on the symlink which is generated during libgcc build and cannot be found if libstdc++ is configured and built separately. It was working fine for 4.4 and 4.6

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

This is definitely an improvement, though for warnings about issues with the left or right argument, we could use the EXPR_LOCATION of the problematic argument rather than the location of the new operand. Jason

Re: [PATCH] Improve debug info for partial inlining (PR debug/54519, take 2)

On Fri, Oct 5, 2012 at 7:19 AM, Jakub Jelinek wrote: > On Fri, Oct 05, 2012 at 03:59:55PM +0200, Richard Guenther wrote: >> I don't think we want to rely on that ... so just keep the push/pop_cfun. > > Ok, so this is what I'm retesting (basically just comments added and the two > lines (subcode an

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

On 10/08/2012 03:57 PM, Jason Merrill wrote: This is definitely an improvement, though for warnings about issues with the left or right argument, we could use the EXPR_LOCATION of the problematic argument rather than the location of the new operand. I agree. Let me see if I can figure out somet

Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure

On 10/08/2012 03:43 PM, Pavel Chupin wrote: This issue has been introduced in 4.7. Irrespective of what we are eventually going to do from a practical point of view, I think it would be important to understand when/what introduced the issue: did you analyze that in any detail? Thanks, Paolo.

Re: [patch] Add option to compute "reaching and live definitions"

On Mon, Oct 8, 2012 at 3:27 PM, Paolo Bonzini wrote: > I wonder if we actually need the non-pruned version anywhere... I don't think so, but I'm not sure. Only ddg.c and loop-iv.c access the DF_RD results directly (i.e. not via DU/UD chains). For loop-iv the pruned version is fine. For ddg I didn'

Re: Fixup INTEGER_CST

> > 2) As we query the type_hash while we are rewritting the types, > > we run into instability of the hashtable. This manifests itself > > as an ICE when one adds sanity check that while merging function > > types their arg types are equivalent, too. > > This ICEs compiling i

PING Re: [PATCH] PR c++/53540 - using fails to be equivalent to typedef

Friendly pinging this patch. Dodji Seketeli writes: > Hello, > > In the example of this problem report, during the substituting of int > into 'function', tsubst_aggr_type fails for the alias ctxt1. This is > because TYPE_TEMPLATE_INFO looks for the TEMPLATE_INFO of the ctxt1 > alias at the wron

Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure

It has been changed here: http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=630d52ca0a88d173f89634a5d7dd8aee07d04d80 subj:"Move gthr to toplevel libgcc" Here is the change (builddir is used as the directory for gthr_default.h): -${host_builddir}/gthr-default.h: ${toplevel_srcdir}/gcc/${glibcxx_thread_

Re: [i386] recognize haddpd

On Fri, 28 Sep 2012, Uros Bizjak wrote: 2) {v[0]-v[1], v[0]-v[1]} is not recognized as a hsubpd because vec_duplicate doesn't match vec_concat. Do we really need to duplicate (no pun intended) the pattern? You can add this transformation to simplify-rtx.c. Probably vec_concat with two equal op

RFA: PATCH to acinclude.m4 to fix gas version detection

On 10/04/2012 11:40 AM, Jason Merrill wrote: Recent versions of binutils seem to have started putting ' around the version number in bfd/configure.in, which was confusing gcc configure. When this change was made to binutils, the other directories changed to using bfd/configure --version to get

Ping Re: Defining C99 predefined macros for whole translation unit

Ping. This patch (non-C parts) is pending review. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH, libstdc++] Fix missing gthr-default.h issue on libstdc++ configure

Hi, Pavel Chupin ha scritto: >It has been changed here: >http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=630d52ca0a88d173f89634a5d7dd8aee07d04d80 > >subj:"Move gthr to toplevel libgcc" I see, thanks. Let's add Rainer in CC, see if he expected this to happen or not. Paolo

Re: patch to fix constant math

- Original Message - > Btw, as for Richards idea of conditionally placing the length field > in > rtx_def looks like overkill to me. These days we'd merely want to > optimize for 64bit hosts, thus unconditionally adding a 32 bit > field to rtx_def looks ok to me (you can wrap that inside a

[testsuite] Require tls_runtime in gcc.target/i386/pr54445-1.c

gcc.target/i386/pr54445-1.c FAILs to execute on Solaris 9 with native TLS: ld.so.1: pr54445-1.exe: fatal: pr54445-1.exe: object requires TLS, but TLS faile d to initialize The following patch fixes this by both requiring TLS runtime support and adding the necessary options. Tested with the appro

Re: patch to fix constant math

On 10/8/2012 11:01 AM, Nathan Froyd wrote: - Original Message - Btw, as for Richards idea of conditionally placing the length field in rtx_def looks like overkill to me. These days we'd merely want to optimize for 64bit hosts, thus unconditionally adding a 32 bit field to rtx_def looks

Re: [PATCH] Fix inclusion of cxxabi_forced.h in dynamic_bitset

On 10/06/12 01:50, Paolo Carlini wrote: > On 10/06/2012 02:33 AM, Joe Seymour wrote: >> I'm seeing tr2/headers/all.cc fail in the libstdc++ testsuite: >> >> In file included from >> src/gcc-mainline/libstdc++-v3/testsuite/tr2/headers/all.cc:22:0: >> /scratch/jseymour/mainline/i686-pc-linux-gnu/inst

Third ping: Re: Add a configure option to disable system header canonicalizations (issue6495088)

Ping, again. On 1 October 2012 16:56, Simon Baldwin wrote: > > Ping, again. > > > On 21 September 2012 12:45, Simon Baldwin wrote: > > > > Ping. > > > > http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html > > > > Full text of previous message and context at URL above. No comments > > or cod

[C++] Omit overflow check for new char[n]

If the size of the inner array elements is 1 and we do not need a cookie, we do not need to insert an overflow check. This applies to the relatively frequent new char[n] case. Built and regression-tested on x86_64-redhat-linux-gnu. Okay for trunk? -- Florian Weimer / Red Hat Product Security

Re: [C++] Mixed scalar-vector operations

On Fri, 5 Oct 2012, Jason Merrill wrote: + error_at (loc, "conversion of scalar to vector " + "involves truncation"); These errors should print the types involved. They also need to be suppressed when !(complain & tf_error). Hello, here is a new

[PATCH] Fix up vt_add_function_parameter (PR debug/54831)

As the testcase shows, we ICEd when generating the debug info for C++ and not splitting types into multiple registers. The issue is in vt_add_function_parameter that we assumed that the DECL_RTL expression was a pseudo register. But in that case it is better to just give up than to ICE. Regtested

Re: [i386] recognize haddpd

On Mon, Oct 8, 2012 at 4:40 PM, Marc Glisse wrote: > On Fri, 28 Sep 2012, Uros Bizjak wrote: > > 2) {v[0]-v[1], v[0]-v[1]} is not recognized as a hsubpd because > vec_duplicate doesn't match vec_concat. Do we really need to duplicate > (no > pun intended) the pattern? >> >> >> You

Re: [PATCH] Fix up vt_add_function_parameter (PR debug/54831)

On Mon, Oct 08, 2012 at 05:58:15PM +0200, Marek Polacek wrote: > 2012-10-08 Marek Polacek > > PR debug/54831 > * var-tracking.c (vt_add_function_parameter): Use condition in place > of gcc_assert. Perhaps s/in place/instead/ ? > --- gcc/var-tracking.c.mp 2012-10-08 10:56

Re: [i386] recognize haddpd

On Mon, Oct 8, 2012 at 6:08 PM, Uros Bizjak wrote: >> +(define_insn "*sse3_haddv2df3" >>[(set (match_operand:V2DF 0 "register_operand" "=x,x") >> (vec_concat:V2DF >> - (plusminus:DF >> + (plus:DF >> + (vec_select:DF >> + (match_operand:V2DF 1 "reg

[patch, mips, testsuite] Fix test to handle optimizations

The gcc.target/mips/ext_ins.c was failing in little endian mode on MIPS because the compiler is smart enough now to see that 'c' is uninitialized and it can insert the field 'a' into 'c' with a shift and a full store instead of an insert because the store just overwrites unintialized data. I chang

Re: patch to fix constant math

On Mon, Oct 8, 2012 at 5:01 PM, Nathan Froyd wrote: > - Original Message - >> Btw, as for Richards idea of conditionally placing the length field >> in >> rtx_def looks like overkill to me. These days we'd merely want to >> optimize for 64bit hosts, thus unconditionally adding a 32 bit >>

[patch, mips, testsuite] Fix gcc.target/mips/octeon-bbit-2.c for -Os

The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization level does not do whichever optimization it is that results in a bbit instead of a bbit[01]l. I would like to skip this test for -Os the way it already gets skipped for -O0. Tested on mips-mti-elf. Ok for checkin? Stev

[lra] 3rd patch to speed more compilation of PR54146

Hello, This patch makes lra_constraint_insn_stack_bitmap an sbitmap. This reduces compile time by another minute or so on gcc17 for the test case of PR54146, and I think it's a general improvement also for less extreme code. For cc1-i files the compile time change tends to be a little less but tha

Re: [PATCH] Fix up vt_add_function_parameter (PR debug/54831)

On Mon, Oct 08, 2012 at 06:09:41PM +0200, Jakub Jelinek wrote: > Ok with those changes. Thanks, this is what I've checked in: 2012-10-08 Marek Polacek PR debug/54831 * var-tracking.c (vt_add_function_parameter): Use condition instead of gcc_assert. * testsuite

Re: [C++] Mixed scalar-vector operations

OK. Jason

Re: RFA: darwin PATCH to fix build, internal visibility

On 10/08/2012 08:28 AM, Dominique Dhumieres wrote: These tests are still failing on darwin. I think that target { ! *-*-solaris2* } { ! *-*-darwin* } sould be replaced with target { ! { *-*-solaris2* *-*-darwin* } } Could someone with a darwin box handy make the appropriate change? Thanks. Ja

Re: [patch, mips, testsuite] Fix gcc.target/mips/octeon-bbit-2.c for -Os

On Oct 8, 2012, at 9:21 AM, Steve Ellcey wrote: > The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization > level does not do whichever optimization it is that results in a bbit instead > of a bbit[01]l. I would like to skip this test for -Os the way it already > gets > skip

Re: [C++] Mixed scalar-vector operations

On Oct 8, 2012, at 8:53 AM, Marc Glisse wrote: > On Fri, 5 Oct 2012, Jason Merrill wrote: > >>> + error_at (loc, "conversion of scalar to vector " >>> + "involves truncation"); >> >> These errors should print the types involved. They also need to be >> suppre

Re: [patch, mips, testsuite] Fix test to handle optimizations

On Oct 8, 2012, at 9:16 AM, Steve Ellcey wrote: > The gcc.target/mips/ext_ins.c was failing in little endian mode on MIPS > because > the compiler is smart enough now to see that 'c' is uninitialized and it can > insert the field 'a' into 'c' with a shift and a full store instead of an > insert b

Re: [patch, mips, testsuite] Fix gcc.target/mips/octeon-bbit-2.c for -Os

On Mon, 2012-10-08 at 11:09 -0700, Mike Stump wrote: > On Oct 8, 2012, at 9:21 AM, Steve Ellcey wrote: > > The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization > > level does not do whichever optimization it is that results in a bbit > > instead > > of a bbit[01]l. I woul

Re: [patch, mips, testsuite] Fix test to handle optimizations

On 10/08/2012 11:15 AM, Mike Stump wrote: On Oct 8, 2012, at 9:16 AM, Steve Ellcey wrote: The gcc.target/mips/ext_ins.c was failing in little endian mode on MIPS because the compiler is smart enough now to see that 'c' is uninitialized and it can insert the field 'a' into 'c' with a shift and a

[google/4_7] Patch committed: backport the static prediction for short-circuit patch from trunk

I have backported r192215 from trunk to google-4_7: 2012-10-08 Dehao Chen * predict.c (predict_extra_loop_exits): Use predict_paths_leading_to_edge to replace predict_edge_def. Bootstrapped and passed crosstool test. Dehao

Re: [PATCH] PR c++/53540 - using fails to be equivalent to typedef

Let's move the alias template case from primary_template_instantiation_p into alias_template_specialization_p and call the latter from the former. And also call it from tsubst. Jason

Re: [patch, mips, testsuite] Fix test to handle optimizations

Really I meant this in reply to the 'Fix gcc.target/mips/octeon-bbit-2.c for -Os' thread. Sorry for confusing the issue here. I don't really have an objection to this one. David Daney On 10/08/2012 11:28 AM, David Daney wrote: On 10/08/2012 11:15 AM, Mike Stump wrote: On Oct 8, 2012, at 9

New Spanish PO file for 'gcc' (version 4.7.2)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Spanish team of translators. The file is available at: http://translationproject.org/latest/gcc/es.po (This file, 'gcc-4.7.2.es.po', has just

[C++ PATCH] Fix ICE in cp_tree_equal (PR c++/54858)

Hi! The following testcase ICEs because cp_tree_equal doesn't handle FIELD_DECLs (in 4.4 it was enough to have c0/d0 and c1/d1 in the testcase, now 12 lines are needed due to introduction of a hash table). Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.7? 201

Re: patch to fix constant math - first small patch

is this ok to commit with this change? kenny On 10/05/2012 08:14 PM, Joseph S. Myers wrote: On Fri, 5 Oct 2012, Kenneth Zadeck wrote: +# define HOST_HALF_WIDE_INT_PRINT "h" This may cause problems on hosts not supporting %hd (MinGW?), and there's no real need for using "h" here given the prom

Re: [C++ PATCH] Fix ICE in cp_tree_equal (PR c++/54858)

OK. Jason

Re: Convert more non-GTY htab_t to hash_table.

On Oct 5, 2012, at 3:19 PM, Diego Novillo wrote: > On Fri, Oct 5, 2012 at 6:08 PM, Lawrence Crowl wrote: > >>> For many people the time to compile (almost) empty file is very >>> important, we are already bad about that right now, initializing >>> too much stuff dynamically is going to make it w

Re: [i386] recognize haddpd

On Mon, 8 Oct 2012, Uros Bizjak wrote: You missed the most important sseadd1 addition, the one that prevents checking of operand2 when calculating "memory" attribute: (and (eq_attr "type" "!alu1,negnot,ishift1, imov,imovx,icmp,test,bitmanip,

Re: patch to fix constant math - third small patch

Kenneth Zadeck writes: > diff --git a/gcc/combine.c b/gcc/combine.c > index 4e0a579..b531305 100644 > --- a/gcc/combine.c > +++ b/gcc/combine.c > @@ -2617,16 +2617,19 @@ try_combine (rtx i3, rtx i2, rtx i1, rtx i0, int > *new_direct_jump_p, > constant. */ >if (i1 == 0 >&& (temp

Re: [PATCH, libstdc++] Add proper OpenBSD support

Jonathan, Any further thoughts about this? I've attached a diff that combines my origional diff with the change to use the "newlib" locale model on OpenBSD since they probably should be committed together. > > > On 10 September 2012 07:34, Mark Kettenis wrote: > > >> Date: Sun, 9 Sep 2012 21:07:

[google/4_7] Patch committed: backport the location_block bugfix patches from trunk

I have backported the following patches from trunk to google-4_7: 191931, 192049, 192120, 192165 gcc: 2012-10-08 Dehao Chen Backport 191931, 192049, 192120, 192165 from trunk. * tree-vect-loop-manip.c (slpeel_make_loop_iterate_ntimes): Use LOCATION_LOCUS to compare wi

Re: [PATCH, libstdc++] Add proper OpenBSD support

On 8 October 2012 20:45, Mark Kettenis wrote: > Jonathan, > > Any further thoughts about this? I've attached a diff that combines > my origional diff with the change to use the "newlib" locale model on > OpenBSD since they probably should be committed together. Hi, Sorry for the delay, I realise

Re: patch to fix constant math

Robert Dewar writes: > On 10/8/2012 11:01 AM, Nathan Froyd wrote: >> - Original Message - >>> Btw, as for Richards idea of conditionally placing the length field >>> in >>> rtx_def looks like overkill to me. These days we'd merely want to >>> optimize for 64bit hosts, thus unconditionally

Re: [i386] recognize haddpd

On Mon, Oct 8, 2012 at 9:36 PM, Marc Glisse wrote: > On Mon, 8 Oct 2012, Uros Bizjak wrote: > >> You missed the most important sseadd1 addition, the one that prevents >> checking of operand2 when calculating "memory" attribute: >> >> (and (eq_attr "type" >> "!alu1,negnot,

Small cleanup/memory leak plugs for lto

Some more issues found by Coverity scanner. lto-cgraph.c: The code seems to be unused, besides, it's a zero-trip loop as parm_num is set to 0 and then checked non nonzeroness. lto-opts: The check whether first_p is non NULL is always false: All calls have a variable ref as argument - and firs

Re: [patch][lra] Improve initial program point density in lra-lives.c (RFA)

On 10/07/2012 02:52 PM, Steven Bosscher wrote: On Sat, Oct 6, 2012 at 4:52 AM, Vladimir Makarov wrote: Without this patch: Compressing live ranges: from 700458 to 391665 - 55%, pre_count 40730653, post_count 34363983 max per-reg pre_count 12978 (228090, 2 defs, 2 uses) (reg/f:DI 228090 [ SR.2500

  1   2   >