http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45934
--- Comment #11 from Jan Hubicka 2011-01-15
16:37:37 UTC ---
Fixed now?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #35 from Jan Hubicka 2011-01-15
16:42:06 UTC ---
I looked briefly into effectivity of the devirtualization bits and they don't
seem to work terribly well.
In GCC 4.3 -O3 copmiled libxul there are 82155 indirect calls.
In mainline -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #36 from Jan Hubicka 2011-01-15
17:21:16 UTC ---
Hmm, the patch makes no difference, but I also see failure in its testcase
FAIL: g++.dg/ipa/imm-devirt-1.C scan-tree-dump optimized "= B::.*foo"
FAIL: g++.dg/ipa/imm-devirt-2.C scan-tre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287
--- Comment #6 from Jan Hubicka 2011-01-17
16:10:54 UTC ---
Is hpux an ELF target? GNU LD plugin implementation contains some hackery to
chose proper PREEMPTED/RESOLVED/etc values.
Perhaps it is broken on non-elfs.
In any case I will prepare pa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #43 from Jan Hubicka 2011-01-18
14:53:46 UTC ---
Now at -O2 the main inliner seems to degenerate ;(
168767 78.4974 cc1 cgraph_edge_badness
9426 4.3842 cc1 update_edge_key
3529 1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #44 from Jan Hubicka 2011-01-18
14:58:04 UTC ---
and later IRA
samples %app name symbol name
2582656.8667 cc1 allocno_spill_priority_compare
6812 14.9994 cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #37 from Jan Hubicka 2011-01-20
10:21:06 UTC ---
I tested Martin's devirtualization patch at cgraph build. The net result is
decrease of number of indirect calls in libxul by 2. The code size decrease by
about 3KB, so there is probabl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47190
Jan Hubicka changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47193
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
Known to fail||
--- Comment #10 from Jan Hubicka 2011-01-22
16:04:49 UTC ---
I think with unit-at-a-time mode for all compilation settings, we should just
drop the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334
--- Comment #24 from Jan Hubicka 2011-01-22
16:23:49 UTC ---
PR 43884 has similar problem with deep loop nests.
gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
--- Comment #19 from Jan Hubicka 2011-01-22
16:24:36 UTC ---
The profile is consistent, but due to recursive inlining we create deep loop
nest in the function making profile estimation to believe that code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
--- Comment #20 from Jan Hubicka 2011-01-22
21:45:23 UTC ---
Patch posted http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01597.html
I tested that is seems to bring us back to the 4.3 speed
jh@gcc10:~/trunk/build/gcc$ time ./a.out 45
fib(45)=1134903
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334
--- Comment #25 from Jan Hubicka 2011-01-22
21:47:43 UTC ---
Author: hubicka
Date: Sat Jan 22 21:47:40 2011
New Revision: 169136
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169136
Log:
PR tree-optimization/43884
PR lto/44334
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44334
--- Comment #26 from Jan Hubicka 2011-01-22
21:49:19 UTC ---
OK,
i comitted the branch prediction change. I am bit confused by the rest of
trail, can you please confirm if the problem is fixed in all the configurations
mentioned?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
--- Comment #21 from Jan Hubicka 2011-01-22
21:47:43 UTC ---
Author: hubicka
Date: Sat Jan 22 21:47:40 2011
New Revision: 169136
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169136
Log:
PR tree-optimization/43884
PR lto/44334
gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
--- Comment #5 from Jan Hubicka 2011-01-22
21:57:35 UTC ---
Hmm, weakref is fun ;(
Seems we fail to stream the alias pair for those two vars.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
--- Comment #6 from Jan Hubicka 2011-01-22
22:10:08 UTC ---
testing the following patch for pasto in reachable_from_this_partition_p
Index: lto-cgraph.c
===
--- lto-cgraph.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
--- Comment #7 from Jan Hubicka 2011-01-22
23:45:47 UTC ---
Author: hubicka
Date: Sat Jan 22 23:45:45 2011
New Revision: 169137
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169137
Log:
PR lto/47333
* g++.dg/lto/pr47333.C: New fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #8 from Jan Hubicka 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225
Jan Hubicka changed:
What|Removed |Added
AssignedTo|hubicka at gcc dot gnu.org |unassigned at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810
--- Comment #13 from Jan Hubicka 2011-01-23
16:45:23 UTC ---
OK, the slowdown comes away when both hookers_law and perida is inlined.
First needs -finline-limit=380 the second needs large-function-growth=1000
(or large increase of inline limi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810
--- Comment #15 from Jan Hubicka 2011-01-23
17:56:31 UTC ---
Enabling early FRE
Index: passes.c
===
--- passes.c(revision 169136)
+++ passes.c(working copy)
@@ -760,6 +760,7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810
--- Comment #16 from Jan Hubicka 2011-01-23
17:57:58 UTC ---
Also w/o inlining hookes_law but with inlining perida (by using
large-function-growth parameter only and the patch abov), I get 30% speedup,
not 50% as with inlining both, but it seems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed|2011-01-23 15:59:30 |
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed||2011-01-23 15:59:30
--- Comment #19 from Ja
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21659
--- Comment #11 from Jan Hubicka 2011-01-24
23:07:29 UTC ---
Author: hubicka
Date: Mon Jan 24 23:07:25 2011
New Revision: 169184
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169184
Log:
PR c/21659
* doc/extend.texi (weak pragma
gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
--- Comment #1 from Jan Hubicka 2011-01-26
10:06:05 UTC ---
testing patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47237
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Jan Hubicka 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47190
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||2011.01.26 14:29:32
CC||hubicka at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
Summary|ICE when weakref is used on |[4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43467
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
||dot com, hubicka at gcc dot
||gnu.org
--- Comment #5 from Jan Hubicka 2011-01-26
14:45:25 UTC ---
Gold was updated to handle this well for binutils 2.11.1, so H.J.'s branch.
We still have issues with mainline G
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46652
--- Comment #6 from Jan Hubicka 2011-01-26
14:46:40 UTC ---
Gold was updated to handle this well for binutils 2.11.1, so H.J.'s branch.
We still have issues with mainline GNU LD. Dave, what about getting this fixed
the gold way?
||hubicka at gcc dot gnu.org
Resolution||INVALID
--- Comment #2 from Jan Hubicka 2011-01-26
14:49:02 UTC ---
This is documented feature.
See "Hidden symbols used from non-link time objects now have to be explicitly
annotated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47190
Jan Hubicka changed:
What|Removed |Added
Summary|[4.5/4.6 Regression] ICE: |[4.5 Regression] ICE: in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274
--- Comment #17 from Jan Hubicka 2011-01-27
15:51:54 UTC ---
You uploaded the cgraph files from local compilation.main_test is not called in
abs-1.c
I need to see the dump from merging, too.
They gets name of one of the .o files when -save-temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46949
--- Comment #2 from Jan Hubicka 2011-01-27
16:16:44 UTC ---
Author: hubicka
Date: Thu Jan 27 16:16:34 2011
New Revision: 169332
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169332
Log:
PR middle-end/46949
* cgraphunit.c (process
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46949
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
,
||hubicka at gcc dot gnu.org
--- Comment #1 from Jan Hubicka 2011-01-27
16:50:43 UTC ---
I can not parse the error, but it seems to be introduced by Alan's patch
http://odin3.kernel.org/git-lewiemann/?p=devel/binutils/hjl/x86.git;a=commitdiff_pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274
Jan Hubicka changed:
What|Removed |Added
CC||dave.korn.cygwin at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #38 from Jan Hubicka 2011-02-05
22:38:41 UTC ---
Created attachment 23253
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23253
failing testcase
With current mainline and top of tree mozilla, things seems to go well, sqlite
issue
||dot com, hubicka at gcc dot
||gnu.org
--- Comment #3 from Jan Hubicka 2011-02-12
12:58:56 UTC ---
It seems like similar problem to the TLS issue - the section built for LTO
symbol table is not quite matching what we
gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
--- Comment #9 from Jan Hubicka 2011-02-12
13:03:25 UTC ---
Hmm, I guess the problem is that we ignore resolution info of aliases when
deciding on privatizing the symbol and then we privatize everything
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Jan Hubicka changed:
What|Removed |Added
Attachment #21543|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47402
--- Comment #13 from Jan Hubicka 2011-02-17
16:18:34 UTC ---
Author: hubicka
Date: Thu Feb 17 16:18:24 2011
New Revision: 170249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170249
Log:
PR debug/47106
PR debug/47402
* cfgex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47106
--- Comment #15 from Jan Hubicka 2011-02-17
16:18:34 UTC ---
Author: hubicka
Date: Thu Feb 17 16:18:24 2011
New Revision: 170249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170249
Log:
PR debug/47106
PR debug/47402
* cfgex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47788
--- Comment #3 from Jan Hubicka 2011-02-19
02:13:20 UTC ---
Author: hubicka
Date: Sat Feb 19 02:13:17 2011
New Revision: 170300
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170300
Log:
PR middle-end/47788
* ipa-inline.c (comput
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497
--- Comment #12 from Jan Hubicka 2011-02-26
10:50:30 UTC ---
Hmm, this is actually same body alias internal thunk. Will need to look more.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497
--- Comment #13 from Jan Hubicka 2011-02-26
13:52:31 UTC ---
The think in question (.LTHUNK0.10948) appears in:
__base_dtor /613(-1) @0x7f43c6b49000 (asm: _ZN6soplex6SoPlexD2Ev.local.405)
availability:available analyzed 194 time, 22 benefit (419
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497
--- Comment #14 from Jan Hubicka 2011-02-26
14:32:42 UTC ---
The problem is in the alias merging code in lto-symtab. It does:
alias->thunk.alias = prevailing_node->decl;
that is wrong for thunks, as for thunks pointing to thunk (like this one) th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46639
--- Comment #5 from Jan Hubicka 2011-02-28
09:25:28 UTC ---
There is no predictor predicting x > 1023 as unlikely, there is not much you
can easilly guess here ;(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497
--- Comment #18 from Jan Hubicka 2011-03-01
19:07:36 UTC ---
Created attachment 23507
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23507
patch I am testing
Hi,
the problem is with thunks referring thunks or aliases.
lto-symtab is wrong h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #19 from Jan Hubicka
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497
--- Comment #20 from Jan Hubicka 2011-03-04
18:49:27 UTC ---
Author: hubicka
Date: Fri Mar 4 18:49:23 2011
New Revision: 170682
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170682
Log:
PR lto/47497
* lto-symtab.c (lto_cgraph_re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
||2011.03.06 09:26:02
CC||hubicka at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #3 from Jan Hubicka 2011-03-06
09:26:02 UTC ---
Confirmed. Most porbably fallout from Zdenek's patch. The loop body si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
||2013-05-22
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jan Hubicka ---
I solved the infinite loop problem on plugin enabled setups with
http://gcc.gnu.org/ml/gcc-patches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #24 from Jan Hubicka ---
S=/home/marxin/libreoffice && O=$S/solver/unxlngx6.pro &&
W=$S/workdir/unxlngx6.pro && mkdir -p $W/LinkTarget/Executable/ && g++ -flto
-fno-fat-lto-objects -fuse-linker-plugin -O2 -Wl,-z,origin
'-Wl,-rpath,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #4 from Jan Hubicka ---
Thank you. It seems that the weakref is simply not output into the file, so we
end up with undefined call.
What happens when you compile the following manually concatenated testcase w/o
LTO? If it links, can you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #8 from Jan Hubicka ---
Thanks. Obviously RTL world translates through the weakrefs w/o LTO but not
with LTO. I will look into it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #13 from Jan Hubicka ---
Indeed, this is generic problem with weakref implementation that for some very
entertaining reason use the CHAIN pointer of identifier nodes in undocumented
way. I will try to debug today who clears the pointe
||2013-05-31
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #5 from Jan Hubicka ---
Mine. Seems alias target got lost somehow.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57500
--- Comment #6 from Jan Hubicka ---
OK, the problem here is that the symbol is not created yet, but decl exists.
Why it happens with -g only is bit strange. The following should fix it however
Index: cgraphunit.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
--- Comment #35 from Jan Hubicka ---
I am having problem to reproduce it on a cross compiler. I assume you have
non-plugin-enable LD setup, right?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
--- Comment #36 from Jan Hubicka ---
I am having problem to reproduce it on a cross compiler. I assume you have
non-plugin-enable LD setup, right?
There is problem with chained weakrefs that ought to be fixed by the following
change:
Index: cgra
||2013-06-07
CC||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jan Hubicka ---
mine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551
--- Comment #4 from Jan Hubicka ---
OK, C++ FE properly brings the decl local as part of constrain_visibility,
however later in pt.c it is made public again in
mark_decl_instantiated as explicit instantiation.
My wild try is the following:
Index
||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #2 from Jan Hubicka ---
mine :(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #5 from Jan Hubicka ---
(gdb) p debug_tree (fn->decl)
unit size
align 32 symtab 0 alias set -1 canonical type 0x76f155e8
precision 32 min max
pointer_to_this >
QI
size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #182 from Jan Hubicka ---
OK, after a while I should update the stats here. Richard's new tree merging
patch makes libxul linking a lot faster and less memory consuming.
Peak memory usage (in TOP) is now just bellow 10GB, with bit of
||2013-06-17
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #6 from Jan Hubicka ---
I am testing
Index: lto-symtab.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #183 from Jan Hubicka ---
type merging stats
[WPA] read 43156894 SCCs of average size 2.270660
[WPA] 97994652 tree bodies read in total
[WPA] tree SCC table: size 8388593, 3830511 elements, collision ratio: 0.684487
[WPA] tree SCC max
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #184 from Jan Hubicka ---
New profiles after Richard's changes to remove pointer maps from straming in.
Stream in:
samples %app name symbol name
3659912.3464 lto1 inflate_fast
27382
||2013-06-19
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #8 from Jan Hubicka ---
This seems to be ELF or libelf limitation. The .o produced is corrupt
apparently because we produce too many
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #11 from Jan Hubicka ---
OK, self contained way to reproduce the bug:
evans:/tmp/:[1]# cat t.c
#include
main()
{
int i;
printf ("int main(){}\n");
for (i=0;i<7;i++)
printf ("__attribute__ ((used, externally_visible)) int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #13 from Jan Hubicka ---
progret needs a fraction of brain capacity than the preprocessor generator and
I doubt it would be faster :)))
anyway I seem to be still getting error with the patch
evans:/tmp/:[0]# /abuild/jh/trunk-install/b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #27 from Jan Hubicka ---
It is difficult to say why the unit test fails. Would be possible to run it in
GDB and figure out why it segfaults?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #18 from Jan Hubicka ---
What about trying ulimit -m to increase the number of FDs? (it requires root)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #19 from Jan Hubicka ---
chrome.wpa.000i.cgraph:
_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (OnIOComplete)
@0x7f80e10be980
Type: function definition analyzed
Visibility: force_output prevailing_def_ironly
Addres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #30 from Jan Hubicka ---
BTW the first parameter is this pointer ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #23 from Jan Hubicka ---
It seems late optimizers translate
cloning Bind to
_ZN4base4BindIMN3net12_GLOBAL__N_113DnsTCPAttemptEFviENS_8internal17UnretainedWrapperIS3_NS_8CallbackINS6_9BindStateINS6_13FunctorTraitsIT_E12RunnableType
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
One of ltrans partitions wihle building firefox gets stuck with the following
profile:
CPU: AMD64 family10, speed 2100 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #185 from Jan Hubicka ---
I merged in some patches intended to reduce memory of Firefox LTO and also
updated firefox tree. Some more involved patches are on the way, so it is
summary where we stand now.
WPA usage in TOP is 10GB now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #186 from Jan Hubicka ---
oprofile of merging
6764713.0501 lto1 inflate_fast
38682 7.4624 lto1 compare_tree_sccs_1(tree_node*,
tree_node*, tree_node***)
32365 6.2437 lto1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #187 from Jan Hubicka ---
WPA time report
Execution times (seconds)
phase setup : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
1398 kB ( 0%) ggc
phase opt and generate : 80.79 (13%) usr 1.01 ( 3%) sys 81.96
||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #10 from Jan Hubicka ---
Mine...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602
--- Comment #11 from Jan Hubicka ---
Created attachment 30616
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30616&action=edit
Proposed fix
Patch I am testing. The problem was that ltrans passes got overzelaous on
clearing local flags. I th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
--- Comment #4 from Jan Hubicka ---
Not much ideas except for implementing more smart (=expensive) common value
histogram collection. I wonder how often such patterns hits us in practice?
The problem here is that the functions are interleaving in
401 - 500 of 3550 matches
Mail list logo
