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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #122 from Jan Hubicka 2012-05-10
21:53:54 UTC ---
oprofile shows:
139188 15.6963 lto1 lto1
uniquify_nodes
66390 7.4868 lto1 lto1
estimate_edge_gro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #123 from Markus Trippelsdorf
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
takes 19 minutes to finish...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #124 from Jan Hubicka 2012-05-11 08:34:17
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
> takes 19 minutes to finish...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #125 from Richard Guenther 2012-05-11
08:44:51 UTC ---
(In reply to comment #122)
> oprofile shows:
> 139188 15.6963 lto1 lto1
> uniquify_nodes
> 66390 7.4868 lto1 lt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #126 from Markus Trippelsdorf
2012-05-11 08:46:39 UTC ---
(In reply to comment #124)
> > 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #127 from Mike Hommey 2012-05-11
08:52:24 UTC ---
(In reply to comment #126)
> (In reply to comment #124)
> > > Just for comparison, clang with -O4 runs only single threaded and does
> > > everything in memory (no streaming out). It u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #128 from Jan Hubicka 2012-05-11 08:52:50
UTC ---
> Well - the obvious possibly "slow" part of uniquify nodes is that it walks
> all fields of record/union types. So - do you have a more detailed profile
> of uniquify_nodes?
No, I w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #129 from Jan Hubicka 2012-05-11
19:05:19 UTC ---
OK, the slow part of uniuqify_nodes is:
/* Remove us from our main variant list if we are not the
variant leader. */
if (TYPE_MAIN_VARIANT (t) != t)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #130 from Jan Hubicka 2012-05-12
14:44:47 UTC ---
After fixing one linker error, I can now build Mozilla with
-flto-partition=none. It takes 11GB and 40 minutes, so there is space for
improvement ;)
There are some obvious questions,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #132 from Jan Hubicka 2012-05-12 18:32:14
UTC ---
> > tree VRP: 65.88 ( 2%) usr 0.73 ( 2%) sys 66.71
> >( 2%) wall 862879 kB (24%) ggc
>
> Is it possible to do this again with gathering statistics enabled? The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #133 from Jan Hubicka 2012-05-12 19:07:32
UTC ---
Another thing to observe is that GGC memory is "just" 4GB. I am not sure where
the other 8GB goes when our IL is believed
to be major memory consumer and it resists almost completely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #134 from Jan Hubicka 2012-05-12
20:22:27 UTC ---
I tracked down the LTO/WHOPR code size difference. It is EH handling. EH frame
is empty for LTO build and quite large for WHOPR. Probably -fno-exceptions
getting lots on way to ltrans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #135 from Jan Hubicka 2012-05-12
21:33:36 UTC ---
... and mem reports on WPA stage:
toplev.c:964 (realloc_for_line_map) 0: 0.0% 89473168:
9.4% 268435472:10.3%160: 0.0% 8
cgraph.c:359 (cgraph_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #136 from Jan Hubicka 2012-05-13
16:29:04 UTC ---
... and oprofile of compilation stage of -flto-partition=none
samples %image name app name symbol name
1949762.8536 lto1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #137 from Jan Hubicka 2012-08-10
15:06:51 UTC ---
So since the last report we managed to double WPA memory usage and compile
time...
12m wall, 42m user is needed for WPA build.
Execution times (seconds)
phase opt and generate : 97.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #138 from Jan Hubicka 2012-08-10
15:35:44 UTC ---
Actually not, I looked up wrong report. The last report in comment #121 shows:
TOTAL : 616.4322.26 651.79
2165706 kB
So we actually go
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 #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 #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 #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 #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 #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 #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 #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 #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 #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
Jan Hubicka changed:
What|Removed |Added
Attachment #21543|0 |1
is obsolete|
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
--- 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 #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
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #10 from Jan Hubicka 2010-12-01
23:58:30 UTC ---
I am just trying to get Mozilla building with GNU ld instead of gold. First
problem is that Mozilla links some of libraries as:
/abuild/jh/trunk-install/bin/gcc -O3 -flto -flto-parti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Jan Hubicka changed:
What|Removed |Added
CC||dave.korn.cygwin at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Dave Korn changed:
What|Removed |Added
CC||davek at gcc dot gnu.org
--- Comment #12 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #13 from Jan Hubicka 2010-12-02 08:47:28
UTC ---
> Yeh, precisely. The ironly file is a placeholder into which we put the
> symbols found in the lto symtab so that they can take part in the link and
> their resolutions be determine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #14 from Dave Korn 2010-12-02 08:52:20
UTC ---
(In reply to comment #13)
> > Yeh, precisely. The ironly file is a placeholder into which we put the
> > symbols found in the lto symtab so that they can take part in the link and
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #15 from Richard Guenther 2010-12-02
09:41:58 UTC ---
(In reply to comment #10)
> I am just trying to get Mozilla building with GNU ld instead of gold. First
> problem is that Mozilla links some of libraries as:
>
> /abuild/jh/trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #16 from Jan Hubicka 2010-12-02 15:34:48
UTC ---
> It's valid I think and we try to work out fPIC ourselves in the funny
> LTO option handling code (but the options are not re-applied at ltrans
> stage I think, so it doesn't work at a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #17 from Jan Hubicka 2010-12-12
23:52:52 UTC ---
Current mainline crashes:
Program received signal SIGSEGV, Segmentation fault.
lto_cgraph_replace_node (slot=, data=) at ../../gcc/lto-symtab.c:227
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Jan Hubicka changed:
What|Removed |Added
Depends on||46940
--- Comment #18 from Jan Hubicka 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #19 from Jan Hubicka 2010-12-15
00:44:25 UTC ---
Filled in the GNU LD bug as
http://sourceware.org/bugzilla/show_bug.cgi?id=12323
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #20 from H.J. Lu 2010-12-17 22:25:56
UTC ---
(In reply to comment #19)
> Filled in the GNU LD bug as
> http://sourceware.org/bugzilla/show_bug.cgi?id=12323
It should have been fixed on hjl/lto-mixed branch at
http://git.kernel.org/?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #22 from Mark Mitchell 2011-01-06
03:55:40 UTC ---
On 1/5/2011 5:36 AM, hubicka at gcc dot gnu.org wrote:
> 40259 5.6000 cc1plus cc1plus
> lookup_field_1
I've looked at this, in the distant pas
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
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 #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 #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 #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...
1 - 100 of 216 matches
Mail list logo
