Uros Bizjak writes:
> On Thu, Sep 27, 2012 at 8:20 PM, Jakub Jelinek wrote:
>> On Thu, Sep 27, 2012 at 08:04:58PM +0200, Uros Bizjak wrote:
>>> After some off-line discussion with Richard, attached is v2 of the patch.
>>>
>>> 2012-09-27 Uros Bizjak
>>>
>>> PR rtl-optimization/54457
>>>
Hi Vlad,
Vladimir Makarov writes:
> @@ -2973,11 +2973,11 @@ cleanup_subreg_operands (rtx insn)
> df_insn_rescan (insn);
> }
>
> -/* If X is a SUBREG, replace it with a REG or a MEM,
> - based on the thing it is a subreg of. */
> +/* If X is a SUBREG, try to replace it with a REG or a M
Hi,
the point of the following patch is to make vectorizer to not vectorize the
following testcase with profile feedback:
int a[1];
int i=5;
int k=2;
int val;
__attribute__ ((noinline,noclone))
test()
{
int j;
for(j=0;j VIC * ((niters-PL_ITERS-EP_ITERS)/VF) + VOC(A)
where
PR libstdc++/54577
* doc/xml/manual/status_cxx2011.xml: N2350 changes are missing from
sequence containers.
* doc/html/*: Regenerate.
Committed to trunk.
commit 56e855e46beb016fcf4f9f293abbb774a9285a46
Author: Jonathan Wakely
Date: Sun Sep 30 12:35:19 2012 +0100
On Tue, Sep 18, 2012 at 1:31 PM, Uros Bizjak wrote:
>> This patch aims to fix all stability issues related to using the first
>> scheduler in gcc
>> for x86 target (there several reported issues related to this problem).
>>
>> Main idea of this activity is mostly to provide user a possibility to
On Thu, Sep 20, 2012 at 8:35 AM, Uros Bizjak wrote:
> On Thu, Sep 20, 2012 at 8:06 AM, Vladimir Yakovlev
> wrote:
>> The compiler with the patch and without post_reload.patch is built and works
>> successfully. It has the only failure with avx-vzeroupper-3 test because of
>> post reload problem.
Denis Chertykov schrieb:
Georg-Johann Lay:
PR52543 required to represent a load from non-generic address spaces as UNSPEC
instead of as MEM to avoid a gross code bloat.
http://gcc.gnu.org/PR52543
lower-subreg's cost model is still broken: It assumes that any loads from MEM
are from the generic
Hi Janus,
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
This looks all right to me (although I'm not really an expert :-)
OK, and thanks for the patch!
Thomas
Hi all,
I have just committed as obvious a patch which re-enables a few class
array checks in the testsuite (removing some FIXMEs):
http://gcc.gnu.org/viewcvs?view=revision&revision=191867
Those tests had been disabled for the 4.6 release, when class arrays
were not supported yet, cf.
http://gcc
Hi,
when writting scale_loop_profile I forgot about scale_loop_frequency that
already sits in the tree for few years. The functions are slightly different.
While scale_loop_frequency only cales frequency of each BB in the loop,
scale_loop_profile takes care of reducing iteration count to known boun
This fixes a lookup failure when using ropes with an allocator
declared outside namespace std, introduced by
http://gcc.gnu.org/ml/libstdc++/2004-07/msg00157.html
* include/ext/ropeimpl.h (__uninitialized_fill_n_a): Fix using
declaration.
* testsuite/ext/rope/5.cc: New.
Te
On Sat, Sep 29, 2012 at 10:26 PM, Steven Bosscher wrote:
> Hi Vlad,
>
> Thanks for the testing and the logs. You must have good hardware, your
> timings are all ~3 times faster than mine :-)
>
> On Sat, Sep 29, 2012 at 3:01 AM, Vladimir Makarov wrote:
>> --32-bit--
2012/9/30 Georg-Johann Lay :
> Denis Chertykov schrieb:
>>
>> Georg-Johann Lay:
>>
>>> PR52543 required to represent a load from non-generic address spaces as
>>> UNSPEC
>>> instead of as MEM to avoid a gross code bloat.
>>>
>>> http://gcc.gnu.org/PR52543
>>>
>>> lower-subreg's cost model is still
On Sat, 29 Sep 2012, Eric Botcazou wrote:
this patch lets the compiler try to rewrite:
(vec_concat (vec_select x [a]) (vec_select x [b]))
as:
vec_select x [a b]
or even just "x" if appropriate.
[...]
OK, but:
1) Always add a comment describing the simplification when you add one,
2) The
Hi Thomas,
>> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>
>
> This looks all right to me (although I'm not really an expert :-)
>
> OK, and thanks for the patch!
thanks for the review. Committed as r191870.
Cheers,
Janus
Hello,
This implements the changes as proposed PR, albeit with some small
differences:
* I decided to go for a more verbose option name '-matomic-model'
instead of just '-matomic'.
* In addition to the soft-tcb model I've also added a soft-imask model.
Interrupt-flipping atomics might not be t
On Sun, Sep 30, 2012 at 6:01 PM, Richard Guenther
wrote:
>>> --64-bit:---
>>> Reload:
>>> 503.26user 36.54system 30:16.62elapsed 29%CPU (0avgtext+0avgdata
>>> LRA:
>>> 598.70user 30.90system 27:26.92elapsed 38%CPU (0avgtext+0avgdata
>
Richard Guenther writes:
>
> I think both measurements run into swap (low CPU utilization), from the LRA
> numbers I'd say that LRA uses less memory but the timings are somewhat
> useless with the swapping.
On Linux I would normally recommend to use
/usr/bin/time -f 'real=%e user=%U system=%S sh
Hi,
To look at it in yet another way:
> integrated RA : 189.34 (16%) usr
> LRA non-specific: 59.82 ( 5%) usr
> LRA virtuals eliminatenon: 56.79 ( 5%) usr
> LRA create live ranges : 175.30 (15%) usr
> LRA hard reg assignment : 130.85 (11%) usr
The IRA pass is slower tha
On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher wrote:
> Hi,
>
>
> To look at it in yet another way:
>
>> integrated RA : 189.34 (16%) usr
>> LRA non-specific: 59.82 ( 5%) usr
>> LRA virtuals eliminatenon: 56.79 ( 5%) usr
>> LRA create live ranges : 175.30 (15%) usr
>> L
Committed.
Andreas.
* gcc.dg/ucnid-8.c: Update line number.
* gcc.dg/torture/pr51106-2.c: Likewise.
diff --git a/gcc/testsuite/gcc.dg/torture/pr51106-2.c
b/gcc/testsuite/gcc.dg/torture/pr51106-2.c
index 49dcdd0..80328a9 100644
--- a/gcc/testsuite/gcc.dg/torture/pr51106-2.c
+++ b
This cleanup removes the handling for MEM expressions that can never
happen. This fixes an ICE that happens because register_operand also
matches (SUBREG (REG)), which isn't caught when only checking for REG.
Tested on m68k-linux and committed.
Andreas.
* config/m68k/m68k.md: Add names t
The test gcc.dg/torture/pr53922.c fails on 32-bit HP-UX because there
isn't support for undefined weak symbols. We skip rather than xfail
to avoid the warning that would otherwise arise.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed
to trunk and 4.7 branch.
Dave
--
J. Davi
This fixes a recent thinko introduced by the double-int rewrite and
responsible for the following failures:
FAIL: gcc.target/sparc/pdist-2.c scan-tree-dump optimized "return 475"
FAIL: gcc.target/sparc/pdist-3.c execution test
as well as an older one spotted by Bernd, whereby the compiler emits
IRA has code to check whether there is only a single acceptable register
for a given operand. This code uses conditions like:
ira_class_hard_regs_num[cl] != 0
&& (ira_class_hard_regs_num[cl] <= ira_reg_class_max_nregs[cl][mode])
i.e. the number of registers needed to store the mode is >=
the
There is no __gthread_recursive_mutex_destroy function in the gthreads API.
Trying to use __gthread_mutex_destroy fails to compile on platforms
where the mutex
types are different. To avoid resource leaks libstdc++ needs to hack
around the missing function with overloaded functions and SFINAE
tric
This is another patch needed for the MIPS MD_REGS change described here:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01992.html
The profitable_hard_regs set used during IRA colouring used to be restricted
to registers that are valid for the allocno's mode. That caused problems
for multi-reg
Denis Chertykov wrote:
Georg-Johann wrote:
Denis Chertykov wrote:
Georg-Johann Lay wrote:
PR52543 required to represent a load from non-generic address spaces as
UNSPEC
instead of as MEM to avoid a gross code bloat.
http://gcc.gnu.org/PR52543
lower-subreg's cost model is still broken: It as
"Steve Ellcey " writes:
> diff --git a/gcc/testsuite/gcc.target/mips/pr37362.c
> b/gcc/testsuite/gcc.target/mips/pr37362.c
> index a378366..da34b9d 100644
> --- a/gcc/testsuite/gcc.target/mips/pr37362.c
> +++ b/gcc/testsuite/gcc.target/mips/pr37362.c
> @@ -1,5 +1,5 @@
> /* mips*-sde-elf doesn't
Hi,
This patch fixes the bug when comparing location to UNKNOWN_LOC.
Bootstrapped and passed gcc regression test.
Okay for trunk?
Thanks,
Dehao
2012-09-30 Dehao Chen
PR middle-end/54759
* gcc/tree-vect-loop-manip.c (slpeel_make_loop_iterate_ntimes): Use
LOCATION_LOCUS to compare with UNKNO
Hello!
Recently, gcc become smart enough to merge:
leal(%rdi), %eax
addl%esi, %eax
into
leal(%rsi,%rdi), %eax
The generated sequence (without ret) becomes shorter than 4 instructions:
cmpl$1, %esi
leal(%rsi,%rdi), %eax
je
On Sun, Sep 30, 2012 at 7:03 PM, Richard Guenther
wrote:
> On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher
> wrote:
>> Hi,
>>
>>
>> To look at it in yet another way:
>>
>>> integrated RA : 189.34 (16%) usr
>>> LRA non-specific: 59.82 ( 5%) usr
>>> LRA virtuals eliminatenon
On 12-09-30 1:03 PM, Richard Guenther wrote:
On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher wrote:
Hi,
To look at it in yet another way:
integrated RA : 189.34 (16%) usr
LRA non-specific: 59.82 ( 5%) usr
LRA virtuals eliminatenon: 56.79 ( 5%) usr
LRA create liv
On 12-09-30 4:42 PM, Steven Bosscher wrote:
On Sun, Sep 30, 2012 at 7:03 PM, Richard Guenther
wrote:
On Sun, Sep 30, 2012 at 6:52 PM, Steven Bosscher wrote:
Hi,
To look at it in yet another way:
integrated RA : 189.34 (16%) usr
LRA non-specific: 59.82 ( 5%) usr
LR
On Mon, Oct 1, 2012 at 12:44 AM, Vladimir Makarov wrote:
> Actually, I don't see there is a problem with LRA right now. I think we
> should first to solve a whole compiler memory footprint problem for this
> test because cpu utilization is very small for this test. On my machine
> with 8GB, th
On Mon, Oct 1, 2012 at 12:50 AM, Vladimir Makarov wrote:
> As I wrote, I don't see that LRA has a problem right now because even on
> 8GB machine, GCC with LRA is 10% faster than GCC with reload with real time
> point of view (not saying that LRA generates 15% smaller code). And real
> time is
Oleg Endo wrote:
> This implements the changes as proposed PR, albeit with some small
> differences:
> --- gcc/config/sh/sh.c(revision 191865)
> +++ gcc/config/sh/sh.c(working copy)
[snip]
> + std::vector tokens;
> + for (std::stringstream ss (str); ss.good (); )
> + {
> +t
On Mon, 2012-10-01 at 08:38 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> > This implements the changes as proposed PR, albeit with some small
> > differences:
>
> > --- gcc/config/sh/sh.c (revision 191865)
> > +++ gcc/config/sh/sh.c (working copy)
> [snip]
> > + std::vector tokens;
>
On 12-09-30 7:15 PM, Steven Bosscher wrote:
On Mon, Oct 1, 2012 at 12:50 AM, Vladimir Makarov wrote:
As I wrote, I don't see that LRA has a problem right now because even on
8GB machine, GCC with LRA is 10% faster than GCC with reload with real time
point of view (not saying that LRA generat
Oleg Endo wrote:
> The existing .c files are compiled as C++ already. There was a
> discussion not long go whether the .c files should be renamed to .cc or
> not. If I remember correctly, the conclusion was that existing .c files
> remain .c, while files newly added should be .cc. gcc/double-in
On Sun, Sep 30, 2012 at 7:23 PM, Kaz Kojima wrote:
> Oleg Endo wrote:
>> The existing .c files are compiled as C++ already. There was a
>> discussion not long go whether the .c files should be renamed to .cc or
>> not. If I remember correctly, the conclusion was that existing .c files
>> remain
On 12-09-28 1:48 PM, Andi Kleen wrote:
Steven Bosscher writes:
On Fri, Sep 28, 2012 at 12:56 AM, Vladimir Makarov wrote:
Any comments and proposals are appreciated. Even if GCC community
decides that it is too late to submit it to gcc4.8, the earlier reviews
are always useful.
I would l
Gabriel Dos Reis wrote:
>> Ah, I've missed that argument. Then can we use STL classes in .c now?
>
> Yes.
>
> The existing file extensions ".c" do not mean "C" only.
Thanks for clarification.
Oleg, the patch is OK.
Regards,
kaz
On Sun, Sep 30, 2012 at 06:50:50PM -0400, Vladimir Makarov wrote:
> But I think that LRA cpu time problem for this test can be fixed.
> But I don't think I can fix it for 2 weeks. So if people believe
> that current LRA behaviour on this PR is a stopper to include it
> into gcc4.8 than we should
Resend to gcc-patches
I have addressed the comments by fixing all the minor issues,
bootstrapped and tested on x86_64. I did the recommended reshuffling
by moving non-tree code from tree-dump.c into a new file dumpfile.c.
I committed two successive revisions
r191883 Main patch with the dump infra
45 matches
Mail list logo
