http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #121 from Jan Hubicka 2012-05-10
21:45:10 UTC ---
With inliner performance fix I am going to push out today, the situation looks
as follows:
Execution times (seconds)
phase parsing : 606.20 (98%) usr 21.98 (99%) sys 641.28
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #120 from Jan Hubicka 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 #119 from Jan Hubicka 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 -> 1727826k
WPA time report:
cal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #118 from Markus Trippelsdorf
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 #117 from Markus Trippelsdorf
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
/var/tmp/mozilla-central/js/src/xp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #116 from Jan Hubicka 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 #115 from Jan Hubicka 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 will analyze what happens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #114 from Jan Hubicka 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, but -fprofile-generate needs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #113 from Jan Hubicka 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
_ZTV17gfxUnknownSurface.local.706.2371: e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #112 from Jan Hubicka 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 visibilities. No surprise
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #111 from Jan Hubicka 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. I simply set PATH to direc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #110 from Martin Jambor 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 looking into dependenci
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #109 from Markus Trippelsdorf
2011-08-04 19:25:09 UTC ---
Yep. See: http://gcc.gnu.org/viewcvs?view=revision&revision=176335
http://thread.gmane.org/gmane.comp.gcc.devel/121989
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #108 from Andrew Pinski 2011-08-04
19:22:50 UTC ---
(In reply to comment #107)
> 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:1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #107 from Jan Hubicka 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:
error: 'close' was not declare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #106 from Markus Trippelsdorf
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 #105 from Markus Trippelsdorf
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 really tested profiledbuild f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #104 from Jan Hubicka 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 check.
Last time I tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #103 from Markus Trippelsdorf
2011-06-15 12:34:20 UTC ---
Even with 8c1fce46fc0 reverted libxul fails to link during
a profiledbuild. Normal build is fine.
with bfd:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #102 from Markus Trippelsdorf
2011-06-15 11:44:22 UTC ---
Jan,
this is caused by:
commit 8c1fce46fc02e43e82b05f49894690133a1bcdcf
Author: hubicka
Date: Fri Jun 10 20:06:48 2011 +
Reverting the commit "fixes" the problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #101 from Mike Hommey 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: https://bugzilla.mozilla.org/show_bug.cgi?id=664387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #100 from Markus Trippelsdorf
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 #99 from Markus Trippelsdorf
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 js.o -c -I../../../dist/sy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #98 from Jan Hubicka 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 bytes (ratio:
4.641664)
[WP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #97 from Jan Hubicka 2011-06-02
13:28:28 UTC ---
Today I noticed by an accident that the following hack:
Index: lto-streamer-out.c
===
--- lto-streamer-out.c (revision 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #96 from Jan Hubicka 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 lto_input_tree
18338 5.3106
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #95 from Jan Hubicka 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 * ???:_obstack_begin [/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #94 from Jan Hubicka 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 < /libiberty/hashtab.c:htab_find_slot (5291
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #93 from Jan Hubicka 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 2.23 (24%) sys 100.91 (36%) wa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #92 from Jan Hubicka 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 libc-2.11.1.so _int_malloc
18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #91 from Jan Hubicka 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 500s
WPA stage.
Streaming s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #90 from Jan Hubicka 2011-05-02
12:41:15 UTC ---
Per node memory usage statistics for WPA
Code Nodes
identifier_node 428715
tree_list10992455
tree_vec 5459
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #89 from Jan Hubicka 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
libxul:
9,413,074 < ipa.c:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #88 from Jan Hubicka 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
at PR48724
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #87 from Jan Hubicka 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 on 64bit build, so we might
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #86 from Markus Trippelsdorf
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 #85 from Jan Hubicka 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 will implement the new comdat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #84 from Mike Hommey 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 the swap definitions:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #83 from Markus Trippelsdorf
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 definitions:
template
inline void El
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #82 from Markus Trippelsdorf
2011-04-11 15:08:28 UTC ---
(In reply to comment #81)
>
> The problem is function Elf_Ehdr::serialize(std::basic_ofstream std::char_traits >&, char, char)
...
> Would be possible for you to look into pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #81 from Jan Hubicka 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_ofstream >&, char, char)
What I see is that this function is de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #80 from Jan Hubicka 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
_ZN15Elf_Ehdr_Traits4swapI13little_endian10Elf32_Ehdr12seria
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #79 from Markus Trippelsdorf
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 comment 70, you're building test.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #78 from Mike Hommey 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 useful.
> > ...
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #77 from Markus Trippelsdorf
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" of both
cases (-Os vs. -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #76 from Markus Trippelsdorf
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 #75 from Markus Trippelsdorf
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 fail to link even such a s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #74 from Jan Hubicka 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 all the strings that are
plac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #73 from Markus Trippelsdorf
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 fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #72 from Markus Trippelsdorf
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 #71 from Markus Trippelsdorf
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 #70 from Jan Hubicka 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 -Wall
-Wpointer-arith -Woverl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #69 from Mark Mitchell 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 to what's done for RTXes?
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #68 from 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 breakdown by individual
> > TREE_CODE,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #67 from Richard Guenther 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 #66 from 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
> ---
> decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #65 from Markus Trippelsdorf
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 PR.
You're right, it builds f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #64 from Jan Hubicka 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% 395040: 0.1% 558297
t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #63 from Jan Hubicka 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 type table: size 524287, 37
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #62 from Jan Hubicka 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 #61 from Jan Hubicka 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
testcase.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #60 from Markus Trippelsdorf
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 -I../../../dist/system_wrappers_js -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #59 from Jan Hubicka 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 -fwhole-program" (or wha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #58 from Markus Trippelsdorf
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 -fwhole-program" (or whate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #57 from Markus Trippelsdorf
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.
> > (although GNU ld uses wa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #56 from Jan Hubicka 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.)
Hmm, seems li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #55 from Jan Hubicka 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, until I added
> enou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #54 from Markus Trippelsdorf
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 memory than gold.)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #53 from Markus Trippelsdorf
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
-Woverloaded-virtual -Wsynth -Wno-ctor-dto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #51 from Martin Jambor 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 #50 from Jan Hubicka 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 usage is slightly over
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #49 from Martin Jambor 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 out of date.
Thanks, th
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=45375
--- Comment #47 from Martin Jambor 2011-02-16
16:30:31 UTC ---
With the elfhack issues gone, the build now fails with:
--
/home/mjambor/gcc/icln/inst/bin/g++ -o js -fno-rtti -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #46 from Martin Jambor 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 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 #44 from Mike Hommey 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 better to just do that on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #43 from Mike Hommey 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 describing the error
> =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #42 from Martin Jambor 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 environment (compiler and link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #41 from Mike Hommey 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 test still segfaults for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #40 from Martin Jambor 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://hg.mozilla.org/mozilla-central/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #39 from Mike Hommey 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, sqlite
> issues are gone.
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
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=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=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 #34 from Jan Hubicka 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=gcc&view=rev&rev=168666
Log:
PR lto/45721
PR lto/45375
* tree.h (s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #33 from Jan Hubicka 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=gcc&view=rev&rev=168644
Log:
PR lto/45375
* lto-cgraph.c (input_profile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #32 from Jan Hubicka 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=gcc&view=rev&rev=168643
Log:
PR lto/45375
* profile.c (read_profile_edg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #31 from Jan Hubicka 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 -flto) becase of the afore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #30 from Jan Hubicka 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 #29 from Jan Hubicka 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
-fuse-linker-plugin -fprofile-corre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #28 from Jan Hubicka 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:
/abuild/jh/trunk-install/bin/g++ -fpermissive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #27 from Jan Hubicka 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...
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 #26 from Alexey Feldgendler
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 32-bit
architecture.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #25 from Jan Hubicka 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 #24 from Jan Hubicka 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=gcc&view=rev&rev=168580
Log:
PR lto/45375
* lto-opt.c (lto_reissue_opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #23 from Jan Hubicka 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/ml/gcc-patches/2011-01/msg00210.h
101 - 200 of 216 matches
Mail list logo
