--- Comment #17 from hubicka at gcc dot gnu dot org 2008-02-06 13:28
---
One problem is the following:
do {
;
match = window + cur_match;
if (match[best_len] != scan_end ||
match[best_len-1] != scan_end1 ||
*match != *scan
--- Comment #28 from hubicka at gcc dot gnu dot org 2008-02-06 15:10
---
*** Bug 23305 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-02-06 15:10
---
Looks like last remaining problem is the missed loop invariant motion due to
STACK_REGS hack as in the case of pr23322
[EMAIL PROTECTED]:/aux/hubicka/trunk-write/buidl2/gcc$ time
./a.out-nostackregs-hack
real
--- Comment #18 from hubicka at gcc dot gnu dot org 2008-02-06 16:44
---
Created an attachment (id=15107)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15107action=view)
Path to predict_paths_leading_to
Hi,
I've revived the continue heuristic patch. By itself it does not help
--- Comment #19 from hubicka at gcc dot gnu dot org 2008-02-06 16:56
---
Created an attachment (id=15108)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15108action=view)
Complete continue heuristic patch
Hi,
this is the complete patch. With this patch we produce profile sane
--- Comment #22 from hubicka at gcc dot gnu dot org 2008-02-06 19:22
---
Yes, there are number of unlucky variables. However the real source is here
seems to be always wrong profile guiding regalloc to optimize for cold portions
of the function rather than real increase of register
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-02-05 13:36
---
Thanks, looks comparable to K8 scores, except that -O3 is not actually that
worse there. So it looks there is more than just random effect of code layout
involved, I will try to look into the assembly produced
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-02-05 13:31
---
This testcase is still slower, 4.4s with -O2 and 3.6s with -O2
-fno-inline-small-functions (on i386). I wondered if the patch counting
frequency of calls crossed helped here. My slowdown is smaller than what
--- Comment #16 from hubicka at gcc dot gnu dot org 2008-02-05 13:55
---
Thanks, looks comparable to K8 scores, except that -O3 is not actually that
worse there. So it looks there is more than just random effect of code layout
involved, I will try to look into the assembly produced
--- Comment #17 from hubicka at gcc dot gnu dot org 2008-02-05 16:18
---
The simplified testcase is dealt with the call crossed frequency patch. I now
get:
.L2:
faddl (%edx,%eax,8)
addl$1, %eax
cmpl$2000, %eax
jne .L2
fstpl -24
--- Comment #18 from hubicka at gcc dot gnu dot org 2008-02-05 16:24
---
RA still don't split live ranges, but works sanely here:
.L21:
faddl (%ebx,%eax,8)
addl$1, %eax
cmpl%edx, %eax
jl .L21
Honza
--
hubicka at gcc dot gnu dot org
--- Comment #20 from hubicka at gcc dot gnu dot org 2008-02-05 22:50
---
Last rumors I heard about LR splitting was that it didn't really helped and
worked and used LOOP notes, so it would need complete rewrite anyway. This
problem wasn't really LR splitting issue, just wrong caller
--- Comment #21 from hubicka at gcc dot gnu dot org 2008-02-05 23:54
---
Looking at the -O2 and -O2 -fno-inline-small-functions, I believe last
remaining problem is our inability to hoist load of 0 out of loop:
The fill loop without inlining is taking the value as argument:
.L7
--- Comment #13 from hubicka at gcc dot gnu dot org 2008-02-03 13:39
---
Tonight runs on haydn with patch in shows regression on gzip: 950-901 in
32bit. FDO 64bit runs are not affected.
This is same score as we had in December, we improved a bit since then but not
enough to match
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-02-02 16:22
---
Created an attachment (id=15079)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15079action=view)
address accumulation patch
While working on PR17863 I wrote the attached patch to make fwprop to combine
code
--- Comment #40 from hubicka at gcc dot gnu dot org 2008-02-01 16:47
---
Well, I still meant that simplifying the cascaded addition into accumulator
into direct addition from base makes the code to simplify. I implemented
experimentally the trick in fwprop and will attach later
--- Comment #42 from hubicka at gcc dot gnu dot org 2008-02-01 22:33
---
So for summary.
With TER disabled, I get 6.2s, so we are still worse than 3.4 that is 5.6s.
With call-cost inline parameter increased and TER disabled, I get 5.3s.
With forwprop fix, ter disabled and inline
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-01-30 15:54
---
Fixed at mainline. I am really surprises this is 4.3 only regression since the
code didn't see much changes in last few releases.
--
hubicka at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from hubicka at gcc dot gnu dot org 2008-01-30 15:55
---
Subject: Bug 34982
Author: hubicka
Date: Wed Jan 30 15:54:14 2008
New Revision: 131966
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131966
Log:
PR target/34982
* i386.c
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-30 16:04
---
If you have nothing against, I would probably go for -mfpmath=sse implied by
-ftree-vectorize route then.
Since there is now i386 ABI mailing list I hope if we can move in direction of
having -mfpmath=sse
--- Comment #34 from hubicka at gcc dot gnu dot org 2008-01-30 17:13
---
[EMAIL PROTECTED]:/aux/hubicka/trunk-write/buidl2$ time ./test-3.4
real0m5.692s
user0m5.588s
sys 0m0.012s
[EMAIL PROTECTED]:/aux/hubicka/trunk-write/buidl2$ time ./test-3.4
real0m5.536s
user
--- Comment #35 from hubicka at gcc dot gnu dot org 2008-01-30 17:58
---
So for more proper analysis. The testcase is quite challenging for inlining
heuristics and by introducing early inlining and reducing call cost we now
inline less that we used to at a time I claimed that we inline
--- Comment #36 from hubicka at gcc dot gnu dot org 2008-01-30 18:14
---
Looking at the .optimized dump, one obvious problem is that we keep a lot of
pointer arithmetic that should be forward propagated:
L147:;
D.184420 = *pz;
p1 = pz + 8;
D.184422 = *p1;
p1 = p1 + 8;
D
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-01-20 11:56 ---
Double checking patch, I don't see obvious mistakes. Since the patch should
only affect register allocation decisions, either we see a latent bug, or
another example of x86 extra precision causing FP program
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-01-19 12:03 ---
Does the regression on C2 duo show even without vectorizing? It looks like
generic SSE fpmath performance issue. There should be no reason why SSE math
in combination with SSE vectorization should result
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-01-16 16:32
---
Subject: Bug 31396
Author: hubicka
Date: Wed Jan 16 16:32:05 2008
New Revision: 131576
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131576
Log:
PR rtl-optimization/31396
* regstat.c
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-16 16:33
---
Fixed on mainline.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-16 16:46
---
Last time I looked into it, it was code
alignment affected by inlining in the string matching loop (longest_match).
This code is very atypical, since the internal loop
--- Comment #32 from hubicka at gcc dot gnu dot org 2008-01-15 15:47
---
I am bit confused by logic of code here. Middle end now ingore DECL_INLINE
consistently, it is still arround since it affect some instantiation decisions
in C++ FE. Does fno-default-inline work? I think only way
--- Comment #5 from hubicka at gcc dot gnu dot org 2008-01-13 11:18 ---
Subject: Bug 32135
Author: hubicka
Date: Sun Jan 13 11:18:08 2008
New Revision: 131502
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131502
Log:
PR middle-end/32135
* tree-ssa-ccp.c
--- Comment #6 from hubicka at gcc dot gnu dot org 2008-01-13 11:26 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-01-12 13:34
---
Fixed on mainline (at least checking number of references from cross compiler).
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-01-12 13:55 ---
I can definitely commit the patch to silence the (IMO valid) diagnostics.
However, why programs are using always_inline and extern inline combination at
all? Just extern inline should be enough.
/* For GNU C
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-01-12 14:03 ---
Subject: Bug 28023
Author: hubicka
Date: Sat Jan 12 14:02:06 2008
New Revision: 131492
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131492
Log:
PR other/28023
* invoke.texi (max-inline
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-01-12 14:04 ---
Fixed in mainline.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-01-12 19:00 ---
Created an attachment (id=14930)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14930action=view)
tentative fix
I am testing the attached patch. It is obvious that we should use profile
here. The PR is most
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-01-11 15:25 ---
I am testing the attached patch. It disables the transformation and produce:
in_cols.0 = (char *) in_cols;
D.1180 = in_cols.0 + 500;
perhaps more canonical way would be
in_cols.0 = in_cols + 500;
d.1180
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-11 15:39
---
The problem here is really how we handle extern inline functions redefining
non-extern inline functions.
What forntend does is to handle all extern inline or extern functions of same
name in all units as single
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-09 19:20
---
Subject: Bug 34708
Author: hubicka
Date: Wed Jan 9 19:19:40 2008
New Revision: 131433
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131433
Log:
PR tree-optimization/34708
* tree-inline.c
--- Comment #1 from hubicka at gcc dot gnu dot org 2008-01-07 22:09 ---
mine.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #16 from hubicka at gcc dot gnu dot org 2008-01-03 21:25
---
Subject: Bug 31081
Author: hubicka
Date: Thu Jan 3 21:23:26 2008
New Revision: 131306
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131306
Log:
PR tree-optimization/31081
* tree-inline.c
--- Comment #15 from hubicka at gcc dot gnu dot org 2007-12-29 22:31
---
Well, I would personally not worry that much about pesimization. The current
behaviour of increasing register pressure is worse. We definitly can insert
the initialization to common dominator of all uses
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-12-18 11:41
---
But I wonder what would be the best way to add the PHI nodes. We really
shouldn't do mark_sym_for_renaming on underlying decl, perhaps create a dummy
decl, let intossa create PHIs etc. for it, then change
--- Comment #13 from hubicka at gcc dot gnu dot org 2007-12-18 18:54
---
Sorry, my last comment was about different inliner issue that seems to be gone
now. I guess easiest way around would be to initialize to 0 at the beggining
of inlined function body? This happens only
--- Comment #15 from hubicka at gcc dot gnu dot org 2007-11-08 12:42
---
The problem here is that code assumes that variable without DEFAULT_DEF is not
in SSA. Arguments that are unused also do have DEFAULT_DEF=NULL, this patch
should fix it. I am testing it now.
Honza
Index: tree
--- Comment #5 from hubicka at gcc dot gnu dot org 2007-10-28 19:09 ---
Mine, it is another example of EH updating problem. I will try to add may EH
edges pre-inlniing to avoid need to call mark_sym_for_renaming in inliner
completely.
--
hubicka at gcc dot gnu dot org changed
--- Comment #9 from hubicka at gcc dot gnu dot org 2007-10-28 19:17 ---
Mine
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from hubicka at gcc dot gnu dot org 2007-10-14 12:10 ---
This is result of ugly hack handling redefined extern inline functions. The
most sane semantics (not what 3.2.x did) would be that function if inlined
should get the extern inline body, but the body from redefined
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-10-14 12:50 ---
This patch should disable the sorry message in this case, but I would argue
that outputting sorry here is right - we fail to inline alway_inline function
because of implementation limitation. So I would claim 3.2.0
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-10-09 14:54 ---
It is little bit sick, but what about implying -mfpmath=sse when
-ftree-vectorize is used and SSE is available?
The reason why we don't default to fpmath=sse is because the extra precision is
told to be part
--- Comment #36 from hubicka at gcc dot gnu dot org 2007-10-09 18:57
---
Startup times was optimized a bit in 4.3.
hashes.c, 100 compilations:
GCC-3.3 GCC-3.4 mainline mainlineprofiledbootstrap
-O0 3.2s3.8s 3.6s3.3s
-O1 5s
--- Comment #7 from hubicka at gcc dot gnu dot org 2007-09-17 15:12 ---
Subject: Bug 33348
Author: hubicka
Date: Mon Sep 17 15:12:10 2007
New Revision: 128547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128547
Log:
PR middle-end/33348
PR target/33406
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-09-17 15:12
---
Subject: Bug 33406
Author: hubicka
Date: Mon Sep 17 15:12:10 2007
New Revision: 128547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128547
Log:
PR middle-end/33348
PR target/33406
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-09-16 21:52 ---
What happens in this testcase is (mis)behaviour of invariant code motion.
On instruction:
(set (mem/c/i:SI (plus:DI (reg/f:DI 113 sfp)
(const_int 80 [0x50])) [3 S4 A32])
(fix:SI (reg:DF 135
--- Comment #25 from hubicka at gcc dot gnu dot org 2007-09-13 11:27
---
Thanks a lot for tracking down this issue. The patch looks correct to me, can
you please send it into gcc-patches?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-09-12 07:03 ---
Subject: Bug 33393
Author: hubicka
Date: Wed Sep 12 07:02:31 2007
New Revision: 128414
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128414
Log:
PR target/33393
* i386.md
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-09-11 14:10 ---
This seems to be latent problem unconvered by -finline-small-functions patch.
Perlbmk was failing at -O3 on older SVN snapshots too.
-finline-small-functions should work as an workaround until the issue
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-09-11 14:22 ---
Sure, it will be neccessary to do some binary to figure out what inlining
breaks the benchmark. Not having the CPU2006 sources, I will be able to do so
until Monday. But if I remember right, it reproduced down
--- Comment #2 from hubicka at gcc dot gnu dot org 2007-09-07 16:05 ---
Apparently it is, it should get out as _U_Qfeq.
I was fixing similar problem yesterday. Perhaps it works now on updated tree?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-09-06 15:10 ---
Subject: Bug 33318
Author: hubicka
Date: Thu Sep 6 15:10:28 2007
New Revision: 128187
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128187
Log:
PR target/33318
* cse.c (fold_rtx): Avoid
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-09-05 22:30 ---
Created an attachment (id=14162)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14162action=view)
fix
does the attached patch fix the bootstrap problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33318
--- Comment #5 from hubicka at gcc dot gnu dot org 2007-06-29 20:13 ---
Subject: Bug 32372
Author: hubicka
Date: Fri Jun 29 20:13:41 2007
New Revision: 126122
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126122
Log:
PR middle-end/32372
* cse.c (cse_insn): Avoid
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-06-29 20:15 ---
Paolo's rumor is correct, Indeed. I somehow lost track in patches that was or
wasn't approved or tested. I've comited the fix now.
--
hubicka at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-06-29 20:19 ---
The testcase works for me on current mainline with sharing checking patch on
x86_64-linux, but since the target triplet is not specified, can you double
check, please, that the bug is gone?
Honza
--
http
--- Comment #13 from hubicka at gcc dot gnu dot org 2007-06-24 23:24
---
Subject: Bug 30563
Author: hubicka
Date: Sun Jun 24 23:24:10 2007
New Revision: 125991
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125991
Log:
PR middle-end/30563
* cgraphunit.c
--- Comment #18 from hubicka at gcc dot gnu dot org 2007-06-23 11:58
---
Subject: Bug 31541
Author: hubicka
Date: Sat Jun 23 11:58:18 2007
New Revision: 125971
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125971
Log:
PR middle-end/31541
* gimplify.c
--- Comment #15 from hubicka at gcc dot gnu dot org 2007-05-06 15:31
---
The problem with NRV transformation is that it removes the return statement
from default path and keeps it in the catch path making GCOV to properly output
it as unexecuted. I tried to look into the NRV
--- Comment #7 from hubicka at gcc dot gnu dot org 2007-04-17 19:02 ---
Subject: Bug 30700
Author: hubicka
Date: Tue Apr 17 19:02:09 2007
New Revision: 123922
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123922
Log:
PR middle-end/30700
* dwarf2out.c
--- Comment #8 from hubicka at gcc dot gnu dot org 2007-04-17 19:04 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #65 from hubicka at gcc dot gnu dot org 2007-04-17 19:16
---
I can confirm that at -O2, memory consumption dropped from 0.5GB to 0.28GB,
that is indeed good improvement. To summarize
http://www.suse.de/~gcctest/memory/results/200704171438/pr28071-O2.rep
Compile time wise
--- Comment #16 from hubicka at gcc dot gnu dot org 2007-04-16 17:07
---
Subject: Bug 27869
Author: hubicka
Date: Mon Apr 16 17:07:19 2007
New Revision: 123876
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123876
Log:
PR target/27869
* config/i386/sse.md
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-04-10 00:06
---
Subject: Bug 27869
Author: hubicka
Date: Tue Apr 10 00:06:16 2007
New Revision: 123682
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123682
Log:
PR target/27869
* config/i386/sse.md
--- Comment #13 from hubicka at gcc dot gnu dot org 2007-03-14 23:03
---
Note that Michael Matz commited a patch to solve the problem independently.
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html
I hope it will get into mainline in few days.
Honza
--
http://gcc.gnu.org
--- Comment #8 from hubicka at gcc dot gnu dot org 2007-02-25 17:37 ---
Subject: Bug 30778
Author: hubicka
Date: Sun Feb 25 17:37:37 2007
New Revision: 122313
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122313
Log:
PR target/30778
* i386.c (counter_mode): New
--- Comment #10 from hubicka at gcc dot gnu dot org 2007-02-25 18:11
---
Subject: Bug 30509
Author: hubicka
Date: Sun Feb 25 18:11:20 2007
New Revision: 122314
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122314
Log:
PR middle-end/30509
* tree-inline.c (copy_bb
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-02-24 22:58 ---
I am testing a fix:
Index: tree-inline.c
===
*** tree-inline.c (revision 122292)
--- tree-inline.c (working copy)
*** copy_bb
--- Comment #4 from hubicka at gcc dot gnu dot org 2007-02-24 23:09 ---
Hi,
testing for expected_size is wrong here - with profile feedback, expected_size
is average size of the block and thus can be smaller than actual size of the
block being copied.
In general we should in this case
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-02-24 23:47 ---
Hi,
this is version I ended up with. In general I don't think that code should
handle with such a small constant sizes, we probably should bump move_by_pieces
constants since it can do better job using proper moves
--- Comment #9 from hubicka at gcc dot gnu dot org 2007-02-21 17:26 ---
The main problem here is that inliner really don't have enough of detailed
information. In general inlining improves optimization and often leads to
smaller code when inlining such a trivial function ARM
--- Comment #9 from hubicka at gcc dot gnu dot org 2007-02-14 01:24 ---
Hi,
the reason is -msse3 that is supposed to be at both invocations. -msse3
enables the SSE builtins that do change declarations UIDs that in turn changes
function names:
;; Function ddx (ddx.1401
--- Comment #60 from hubicka at gcc dot gnu dot org 2007-02-06 22:05
---
Hi,
small update on status. At -O3 -fno-tree-fre -fno-tree-pre we are now doing
1.1GB footprint, 800MB of this out of gimple. We still explode in FRE/PRE but
majority of other problems was fixed:
Execution times
--- Comment #61 from hubicka at gcc dot gnu dot org 2007-02-06 22:14
---
Also forgot to mention, integration is slow because of the split_block
quadraticness.
For -O2:
We need 531MB of ram, GGC memory is peaking at 100MB, large portion of the
non-GGC memory are definitly the scheduler
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-02-04 23:41 ---
Subject: Bug 30696
Author: hubicka
Date: Sun Feb 4 23:40:58 2007
New Revision: 121582
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121582
Log:
PR middle-end/30696
* ipa-inline.c
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-02-03 21:48 ---
Testing fix.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #4 from hubicka at gcc dot gnu dot org 2007-02-03 21:49 ---
Created an attachment (id=13002)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13002action=view)
Fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30650
--- Comment #7 from hubicka at gcc dot gnu dot org 2007-02-03 23:35 ---
Subject: Bug 30650
Author: hubicka
Date: Sat Feb 3 23:35:42 2007
New Revision: 121554
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121554
Log:
PR gcov-profile/30650
* value-prof.c
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-01-27 15:57 ---
update_inlined_to_pointers is obviously no longer needed and can be safely
removed now. Thanks for noticing it ;)
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-01-22 00:40 ---
Mine
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-01-15 01:56 ---
since the bug does not reproduce on Linux setup, would be possible to have
preprocessed testcase and possibly also backtrace of the crash?
Thank you,
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
--- Comment #4 from hubicka at gcc dot gnu dot org 2007-01-12 18:08 ---
Subject: Bug 30443
Author: hubicka
Date: Fri Jan 12 18:07:57 2007
New Revision: 120730
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120730
Log:
PR tree-optimization/30443
* tree-inline.c
--- Comment #15 from hubicka at gcc dot gnu dot org 2007-01-11 16:45
---
Subject: Bug 1046
Author: hubicka
Date: Thu Jan 11 16:44:56 2007
New Revision: 120680
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120680
Log:
PR tree-optimization/1046
* tree-tailcall.c
--- Comment #16 from hubicka at gcc dot gnu dot org 2007-01-11 16:50
---
Subject: Bug 1046
Author: hubicka
Date: Thu Jan 11 16:50:32 2007
New Revision: 120681
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120681
Log:
PR tree-optimization/1046
* tree-tailcall.c
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-01-12 01:43 ---
Patch in testing. It is related to function cloning update needed by Razya's
IPCP code.
Honza
Index: tree-inline.c
===
*** tree-inline.c
--- Comment #2 from hubicka at gcc dot gnu dot org 2007-01-06 18:10 ---
Created an attachment (id=12866)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12866action=view)
patch in testing
Mine,
testing the attached fix.
Honza
--
hubicka at gcc dot gnu dot org changed
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-01-07 03:23 ---
Created an attachment (id=12868)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12868action=view)
fix in testing
testing a fix.
--
hubicka at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from hubicka at gcc dot gnu dot org 2006-12-23 14:26
---
Note that we've got another noticeable jump in memory consumption today (well
at least it would be very important jump if we used just 28MB of memory for
aliasing :). Is that also aliasing or shall be analyzed
--- Comment #14 from hubicka at gcc dot gnu dot org 2006-12-23 14:27
---
Well, actually the testcase now runs out of memory and ICE...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
--- Comment #3 from hubicka at gcc dot gnu dot org 2006-12-20 20:46 ---
Subject: Bug 30213
Author: hubicka
Date: Wed Dec 20 20:46:15 2006
New Revision: 120083
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120083
Log:
PR target/30213
* i386.c
--- Comment #2 from hubicka at gcc dot gnu dot org 2006-12-18 02:54 ---
Mine, working on fix.
Honza
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
401 - 500 of 631 matches
Mail list logo
