http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #123 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-05-11 05:55:43 UTC ---
Just for comparison, clang with -O4 runs only single threaded and does
everything in memory (no streaming out). It uses 3.5GB of memory (peak) and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #119 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-19
09:22:01 UTC ---
Some up to date perfomrance data. WPA peaks 3.1GB in TOP now. (3261 virt).
Overall compile time is 4m32s real, 21m14 user.
GGC memory is GC 2248537k -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #120 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-19
13:05:25 UTC ---
weakref reorg saves about 15 seconds, so we have total WPA time 145s and decl
out at 19s (13%).
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #117 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-10-11 07:39:43 UTC ---
-flto=4 -fno-fat-lto-objects -fprofile-use -fprofile-correction breaks
at js/src/xpconnect/src/dombindings.cpp:
...
In file included from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #118 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-10-11 12:18:21 UTC ---
Probably a Mozilla bug. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=693563
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #114 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-01
13:18:30 UTC ---
So quick summary
1) -g build is still blocked by dwarf2out ICE
2) build with gold works, but only without -fprofile-generate. FDO build is
also possible,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #115 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-01
15:28:46 UTC ---
OK the same errors also happens with GNU LD build
http://sourceware.org/bugzilla/show_bug.cgi?id=13244
https://bugzilla.mozilla.org/show_bug.cgi?id=691053
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #116 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-01
15:52:51 UTC ---
Solving http://sourceware.org/bugzilla/show_bug.cgi?id=13245
should make that linker error with -flto -fprofile-generate to go away.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #113 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-29
16:24:56 UTC ---
Even with PR47247 solved, -fprofile-generate -flto build fails at
libbrowsercomps.so.ltrans23.ltrans.o:libbrowsercomps.so.ltrans23.o:function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #112 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-28
13:33:03 UTC ---
OK, the problem turns out to be configure issue. Configure script greps asm
output and with slim LTO it does not find there what it expects disabling
hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #111 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-27
20:48:19 UTC ---
Mozilla now builds for me with slim LTO objects. I.e. with -flto=24
-fuse-linker-plugin -fno-fat-lto-objects
One needs ar/nm/ranlib that works with slim LTO.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #110 from Martin Jambor jamborm at gcc dot gnu.org 2011-08-05
13:47:30 UTC ---
(In reply to comment #107)
Martin, you mentioned similar problem earlier, perhaps you already have
solution?
I went for adding the includes. I wasn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #107 from Jan Hubicka hubicka at gcc dot gnu.org 2011-08-04
19:16:29 UTC ---
Now my build dies on what appears to be configure confussion:
/abuild/jh/mozilla-central2/mozilla-central/ipc/chromium/src/base/file_util_linux.cc:43:17:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #108 from Andrew Pinski pinskia at gcc dot gnu.org 2011-08-04
19:22:50 UTC ---
(In reply to comment #107)
Now my build dies on what appears to be configure confussion:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #109 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-08-04 19:25:09 UTC ---
Yep. See: http://gcc.gnu.org/viewcvs?view=revisionrevision=176335
http://thread.gmane.org/gmane.comp.gcc.devel/121989
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #106 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-06-26 19:50:20 UTC ---
I've opened a new bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533
with a patch that fixes the issue seen in Comment 99.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #104 from Jan Hubicka hubicka at ucw dot cz 2011-06-18 08:53:37
UTC ---
Even with 8c1fce46fc0 reverted libxul fails to link during
a profiledbuild. Normal build is fine.
I didn't really tested profiledbuild for a while, so I will
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #105 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-06-18 10:18:09 UTC ---
(In reply to comment #104)
Even with 8c1fce46fc0 reverted libxul fails to link during
a profiledbuild. Normal build is fine.
I didn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #99 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-06-15 10:32:08 UTC ---
New build failure with gold and gcc 4.7.0 20110615:
ake[6]: Entering directory
`/var/tmp/mozilla-central/moz-build-dir/js/src/shell'
js.cpp
c++ -o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #100 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-06-15 10:44:52 UTC ---
Please note that this error only happens during a profiled build.
Normal build seems to be OK.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #101 from Mike Hommey mh+gcc at glandium dot org 2011-06-15
11:38:01 UTC ---
(In reply to comment #100)
Please note that this error only happens during a profiled build.
Normal build seems to be OK.
FWIW:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #102 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-06-15 11:44:22 UTC ---
Jan,
this is caused by:
commit 8c1fce46fc02e43e82b05f49894690133a1bcdcf
Author: hubicka hubicka@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Fri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #103 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-06-15 12:34:20 UTC ---
Even with 8c1fce46fc0 reverted libxul fails to link during
a profiledbuild. Normal build is fine.
with bfd:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #97 from Jan Hubicka hubicka at gcc dot gnu.org 2011-06-02
13:28:28 UTC ---
Today I noticed by an accident that the following hack:
Index: lto-streamer-out.c
===
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #98 from Jan Hubicka hubicka at gcc dot gnu.org 2011-06-02
14:28:47 UTC ---
Martin suggested ingoring BINFOs without FLAG_2 set.
It don't seem make much difference:
[WPA] Compression: 430287537 input bytes, 1997250286 uncompressed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #96 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-27
21:57:27 UTC ---
Stream in oprofile is now quite changed:
33258 9.6313 lto1 htab_find_slot_with_hash
29679 8.5949 lto1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #94 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-20
15:30:38 UTC ---
Callgrinding htab_find_slot_with_hash leads to:
2,535,276,742 /libiberty/hashtab.c:htab_find_slot'2 (27545437x) [//lto1]
84,947,655,239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #95 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-20
15:31:28 UTC ---
... and
7,456,601,134 /gcc/gimple.c:gimple_type_eq (18852945x) [//lto1]
1,384,102,312 /gcc/gimple.c:gimple_type_hash (3452343x) [//lto1]
936,822,402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #92 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-19
22:28:18 UTC ---
decl in is now at 96 seconds.
oprofile for streaming in is:
27469 9.3054 lto1 htab_find_slot_with_hash
23175 7.8508
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #93 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-19
22:41:41 UTC ---
Time report:
ipa lto gimple out: 10.28 ( 4%) usr 1.05 (11%) sys 11.35 ( 4%) wall
0 kB ( 0%) ggc
ipa lto decl in : 98.45 (37%) usr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #91 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-03
17:34:56 UTC ---
Hi,
with the patch I just posted for removal of hash tables for cgraph/varpool node
set, the situation with hashing is better. We got from 900s WPA stage to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #89 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-02
10:13:00 UTC ---
This is callgrind profile for our hashtables that are consuming most of time at
WPA stage. It is from javascript library, but probably close enough for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #90 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-02
12:41:15 UTC ---
Per node memory usage statistics for WPA
Code Nodes
identifier_node 428715
tree_list10992455
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #87 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-22
12:52:17 UTC ---
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01854.html has updated bulild
time/memory stats. With Michaels WPA patch, we now need about 5GB of address
space
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #88 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-22
15:03:16 UTC ---
As a quick status update, mozilla now builds and works with TOT GCC tree again,
after fixes to debug info streaming and clone materialization. -g still fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #84 from Mike Hommey mh+gcc at glandium dot org 2011-04-12
10:53:44 UTC ---
(In reply to comment #83)
I am not sure if this is GCC bug or elfhack, but I would guess for
elfhack actually.
I guess you're right, because when I move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #85 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-12
16:22:13 UTC ---
Thanks for analysis. removing inline should work too.
while as qoi issue gcc can find the missing bodu, i think it is better to avoid
more hacks. for 4.7 i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #86 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-12 16:42:34 UTC ---
(In reply to comment #85)
does elfhack work for you now?
Yes, no problems anymore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #80 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-11
11:00:05 UTC ---
Hi,
in the resolution files, the swap functions are already undefined
5382 3d06433b UNDEF __assert_fail
5400 3d06433b UNDEF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #81 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-11
11:13:32 UTC ---
Sorry, firefox concluded I want to save changes when I didn't ;)
The problem is function Elf_Ehdr::serialize(std::basic_ofstreamchar,
std::char_traitschar ,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #82 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-11 15:08:28 UTC ---
(In reply to comment #81)
The problem is function Elf_Ehdr::serialize(std::basic_ofstreamchar,
std::char_traitschar , char, char)
...
Would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #83 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-11 18:44:07 UTC ---
I am not sure if this is GCC bug or elfhack, but I would guess for
elfhack actually.
I guess you're right, because when I move the swap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #75 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-08 06:52:34 UTC ---
(In reply to comment #74)
Interesting. -O3 makes no difference for me. I will look into your dumps if I
can spot something useful.
...
If GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #76 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-08 15:42:23 UTC ---
Created attachment 23930
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23930
Output of -Wl,-Map good
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #77 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-08 15:51:09 UTC ---
Created attachment 23931
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23931
Output of -Wl,-Map bad
I've attached the output of -Wl,-Map,map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #78 from Mike Hommey mh+gcc at glandium dot org 2011-04-08
15:57:14 UTC ---
(In reply to comment #75)
(In reply to comment #74)
Interesting. -O3 makes no difference for me. I will look into your dumps
if I
can spot something
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #79 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-08 16:10:01 UTC ---
(In reply to comment #78)
What matters is what is used to build/link test.so, not elfhack itself, and
from the look at the command line in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #70 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-07
19:15:19 UTC ---
I can not reproduce the aforementioned elfhack failure. For me build fails
later at
/abuild/jh/trunk-install/bin/g++ -flto=24 -fuse-linker-plugin -fno-rtti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #71 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-07 19:38:17 UTC ---
Created attachment 23917
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23917
-lm.res
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #72 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-07 19:39:29 UTC ---
Created attachment 23918
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23918
elfhack.wpa.000i.cgraph
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #73 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-07 19:59:30 UTC ---
Jan,
elfhack only fails to build if I use:
ac_add_options --enable-optimize=-O3
in my .mozconfig.
When I delete the =-O3 part everything builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #74 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-07
22:07:38 UTC ---
Interesting. -O3 makes no difference for me. I will look into your dumps if I
can spot something useful.
The behavior I observe is that GCC optimize away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #67 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-04
12:30:07 UTC ---
(In reply to comment #66)
On Sun, Apr 03, 2011 at 10:09:06AM +, hubicka at gcc dot gnu.org wrote:
Kind Nodes Bytes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #68 from froydnj at codesourcery dot com froydnj at codesourcery
dot com 2011-04-04 13:13:01 UTC ---
On Mon, Apr 04, 2011 at 01:01:27PM +, rguenth at gcc dot gnu.org wrote:
Do folks think it would be useful to include a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #69 from Mark Mitchell mark at codesourcery dot com 2011-04-05
00:16:02 UTC ---
On 4/4/2011 3:19 AM, froydnj at codesourcery dot com wrote:
Do folks think it would be useful to include a breakdown by individual
TREE_CODE, similar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #61 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-03
08:34:01 UTC ---
My tree still builds (this is debug info ICE and I use non-debug info by
default). Will update tree and try to reproduce it. Would be handy to have a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #62 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-03
08:36:47 UTC ---
and since it doesn't fail at link time, this is debug info bug, not LTO, so if
you get a testcase, please open a new PR.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #63 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-03
09:09:03 UTC ---
Some stats on size of the compilation unit...
There is 4.5GB of GGC memory, it gets down to 3.9MB after type merging and
3.1MB after cgraph merging.
GIMPLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #64 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-03
10:08:34 UTC ---
Some detailed stats on WPA memory usage.
Before IPA:
ipa-prop.c:2820 (ipa_read_node_info) 0: 0.0%8895232:
1.1% 24998944: 0.7%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #65 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-04-03 11:32:08 UTC ---
(In reply to comment #62)
and since it doesn't fail at link time, this is debug info bug, not LTO, so if
you get a testcase, please open a new
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #66 from froydnj at codesourcery dot com froydnj at codesourcery
dot com 2011-04-04 01:18:59 UTC ---
On Sun, Apr 03, 2011 at 10:09:06AM +, hubicka at gcc dot gnu.org wrote:
Kind Nodes Bytes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #60 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-03-23 13:10:50 UTC ---
Latest mozilla-central fails here:
make[5]: Entering directory
`/var/tmp/mozilla-central/moz-build-dir/js/src/shell'
js.cpp
c++ -o js.o -c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #59 from Jan Hubicka hubicka at ucw dot cz 2011-03-10 12:53:58
UTC ---
How do you do this with make -f client.mk profiledbuild?
To answer my own question:
Just edit ./configure and ./js/src/configure and add
-flto=4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #53 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-03-09 13:46:39 UTC ---
Building fails with GNU ld (Linux/GNU Binutils) 2.21.51.0.7.20110306:
c++ -o xpcshell -fno-rtti -fno-exceptions -Wall -Wpointer-arith
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #54 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-03-09 14:40:25 UTC ---
Turned out that GNU ld doesn't like --as-needed;
LDFLAGS=-Wl,-O1,--hash-style=gnu,--no-keep-memory works fine.
(although GNU ld uses way more
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #55 from Jan Hubicka hubicka at ucw dot cz 2011-03-09 19:17:26
UTC ---
Just a warning: Building a -fprofile-generate libxul uses
~13GB of memory. (I have 8GB on my build-system and lto1
got killed several times by the OOM killer,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #56 from Jan Hubicka hubicka at ucw dot cz 2011-03-09 19:19:53
UTC ---
Turned out that GNU ld doesn't like --as-needed;
LDFLAGS=-Wl,-O1,--hash-style=gnu,--no-keep-memory works fine.
(although GNU ld uses way more memory than gold.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #57 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-03-09 19:49:56 UTC ---
(In reply to comment #56)
Turned out that GNU ld doesn't like --as-needed;
LDFLAGS=-Wl,-O1,--hash-style=gnu,--no-keep-memory works fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #58 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-03-09 21:45:10 UTC ---
How do you do this with make -f client.mk profiledbuild?
To answer my own question:
Just edit ./configure and ./js/src/configure and add
-flto=4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #51 from Martin Jambor jamborm at gcc dot gnu.org 2011-02-18
12:30:08 UTC ---
I tried again on a machine with more RAM and LTO build succeeded for me as
well. Thanks a lot.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #49 from Martin Jambor jamborm at gcc dot gnu.org 2011-02-17
13:15:48 UTC ---
(In reply to comment #48)
Updated mozilla patch fixing the undefined symbols Martin reported.
Sorry, had it in tree for a while, but didn't noticed PR is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #50 from Jan Hubicka hubicka at ucw dot cz 2011-02-17 15:16:19
UTC ---
Thanks, that resolved these issues. However, now my 8GB machine runs
out of memory when linking libxul.so.
That is expected. With richard's -g fixes memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #47 from Martin Jambor jamborm at gcc dot gnu.org 2011-02-16
16:30:31 UTC ---
With the elfhack issues gone, the build now fails with:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Attachment #21543|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #46 from Martin Jambor jamborm at gcc dot gnu.org 2011-02-13
12:41:29 UTC ---
(In reply to comment #45)
Can you try mozilla-central revision 19f13dea4d4a?
With that revision the elfhack problems are gone. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #45 from Mike Hommey mh+gcc at glandium dot org 2011-02-12
09:32:34 UTC ---
Can you try mozilla-central revision 19f13dea4d4a?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #42 from Martin Jambor jamborm at gcc dot gnu.org 2011-02-10
17:35:36 UTC ---
(In reply to comment #41)
Segfaults or aborts ?
Segfaults:
===
=== If you get failures below, please file a bug describing the error
=== and your
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #43 from Mike Hommey mh+gcc at glandium dot org 2011-02-10
17:41:53 UTC ---
(In reply to comment #42)
(In reply to comment #41)
Segfaults or aborts ?
Segfaults:
===
=== If you get failures below, please file a bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #44 from Mike Hommey mh+gcc at glandium dot org 2011-02-10
17:43:04 UTC ---
(In reply to comment #43)
Ah, so this is a crash of the test, not of elfhack. Could you attach both
test.so and test.so.bak files ?
Actually, it would be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #40 from Martin Jambor jamborm at gcc dot gnu.org 2011-02-09
14:12:57 UTC ---
(In reply to comment #39)
That could well be https://bugzilla.mozilla.org/show_bug.cgi?id=629638
Can you check with a changeset newer than
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #41 from Mike Hommey mh+gcc at glandium dot org 2011-02-09
14:34:08 UTC ---
(In reply to comment #40)
I have just checked-out mozilla-central entirely by doing
hg clone http://hg.mozilla.org/mozilla-central/
and the elfhack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #39 from Mike Hommey mh+gcc at glandium dot org 2011-02-07
18:40:22 UTC ---
(In reply to comment #38)
Created attachment 23253 [details]
failing testcase
With current mainline and top of tree mozilla, things seems to go well,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #38 from Jan Hubicka hubicka at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #37 from Jan Hubicka hubicka at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #35 from Jan Hubicka hubicka at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #36 from Jan Hubicka hubicka at gcc dot gnu.org 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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #34 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-11
17:29:57 UTC ---
Author: hubicka
Date: Tue Jan 11 17:29:52 2011
New Revision: 168666
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168666
Log:
PR lto/45721
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #30 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-10
16:39:08 UTC ---
The libmoznome build issue is now Mozilla PR
https://bugzilla.mozilla.org/show_bug.cgi?id=624385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #31 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-10
22:51:06 UTC ---
Mozilla now builds with profile feedback and LTO.
One needs to train without LTO (i.e. -fprofile-generate -O3 only) and then
build with LTO (-fprofile-use -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #32 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-10
23:37:14 UTC ---
Author: hubicka
Date: Mon Jan 10 23:37:11 2011
New Revision: 168643
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168643
Log:
PR lto/45375
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #33 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-10
23:37:48 UTC ---
Author: hubicka
Date: Mon Jan 10 23:37:45 2011
New Revision: 168644
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168644
Log:
PR lto/45375
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #28 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-10
01:29:19 UTC ---
With fixes for PR47234 and PR47233 I can build -fprofile-generate libxul.
Didn't tried yet if the porfile apply, since build later dies at:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #29 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-10
01:59:31 UTC ---
... and hacking around, the profile doesn't read back even with
-fprofile-correction
/abuild/jh/trunk-install/bin/gcc -O3 -flto -flto-partition=none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #25 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-08
21:06:27 UTC ---
With current mainline and release checking compiler, I can for first time build
mozilla with debug info. 7.5GB of RAM is needed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #26 from Alexey Feldgendler alexey at feldgendler dot ru
2011-01-08 21:10:50 UTC ---
This is a great success, although I have to say it's still way too much RAM to
ask for. In particular, this excludes the possiblity of compiling on a
There is a lot of room for improvement in the WPA memory use, but I am not sure
how much we can still fit in 4.6.0...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #27 from Jan Hubicka hubicka at ucw dot cz 2011-01-08 21:35:00
UTC ---
There is a lot of room for improvement in the WPA memory use, but I am not sure
how much we can still fit in 4.6.0...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #23 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-07
18:11:39 UTC ---
I've updated mozilla tree and rebuilt with top of tree GCC. The resulting
binary seems to work well. Two GCC patches are required:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #24 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-07
18:21:03 UTC ---
Author: hubicka
Date: Fri Jan 7 18:21:00 2011
New Revision: 168580
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168580
Log:
PR lto/45375
*
101 - 200 of 216 matches
Mail list logo