http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #4 from Jan Hubicka ---
Right now I am preparing a short conference, but I will try to look into it
tonight.
The way it was supposed to work is that the misaligned move prologues should be
disabled
for pentiumpro target. I wonder why
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58981
--- Comment #3 from Jan Hubicka ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58981
>
> --- Comment #2 from H.J. Lu ---
> The bug is in
>
> *count = expand_simple_binop (GET_MODE (*count), PLUS, *count,
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
--- Comment #4 from Jan Hubicka ---
Actually ipa-devirt has a code that is supposed to not make devirt happen in
this case - I will check out why it doesn't here.
But I think it is KDE's bug here. You have library with -fvisibility=hidden
and th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #8 from Jan Hubicka ---
> Ah, right. We don't have an A binfo in C's base list.
>
> I believe you can distinguish this case by looking at the
> BINFO_INHERITANCE_CHAIN of the A binfo; in this case, it should point back to
> C
> rath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #6 from Jan Hubicka ---
> > Is there way how to keep track of the vtables w/o doing the walk based on
> > fields instead of BINFO_BASEs?
>
> There should be. Your code change makes sense to me; a primary base will
> always be at offs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58388
--- Comment #4 from Jan Hubicka ---
> It took me some time to reproduce this in a way that would give me
> enough debug info to look at stuff. Nevertheless, indeed that is the
I usually debug these crashes by simply running stage1 compiler when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #14 from Jan Hubicka ---
I use the following workaround for time being.
Honza
Index: tree-ssa-threadedge.c
===
--- tree-ssa-threadedge.c(revision 202364)
+++ tree-ss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201
--- Comment #13 from Jan Hubicka ---
> I'm a bit worried, because normally we don't check in the testsuite that those
> messages about the instantiation point have the right line number, thus, we
> may
> well have a pretty serious diagnostic regr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #6 from Jan Hubicka ---
> The PA-RISC HP-UX linker interposes import and export stubs in dynamic
> libraries.
> Whether there is a working notion of alias is somewhat unclear and
> involves digging
> into the linker code. The HP a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294
--- Comment #11 from Jan Hubicka ---
> Better terminate if the region indeed did throw (usually it's just
> not optimized good enough).
I tihnk that is difference in between throw() and nothrow attribute.
The first produce must not throw region a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294
--- Comment #9 from Jan Hubicka ---
> Well, must_not_throw would work, too.
It will wind up in producing EH receiver with terminate, probably not what we
want.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294
--- Comment #7 from Jan Hubicka ---
> The fix is to preserve this "nonthrowing". That's how I made it work
Yes, this was my first tought, too.
> for the abnormal edge case. Thus, wrap it in a NOTHROW region?
I think we would have to invent it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #3 from Jan Hubicka ---
> I wouldn't be surprised.
>
> I don't have assembler output or preprocessed source yet. There is
> some alias
> support in gas for HP-UX but I believe it may not work when we have a
> call using
> a funct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #195 from Jan Hubicka ---
Today there was two fixes for bugs that produce undefined symbols like one you
see.
Does the problem still exist on current mainline? Are you using profile
feedback?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #1 from Jan Hubicka ---
> Symbol has type data which is wrong for procedure label:
>
> Symbols from system_error.o:
>
> ValueInfo Type Scope ck HQIRCDSKLN xl reloc Name
>
> Data Unsat 0 .. 3 000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58250
--- Comment #3 from Jan Hubicka ---
> Prefetching generally increases code size, so I think we shouldn't do it, at
> least not by default. So I'd say for !optimize_size -fprofile-use should just
> not add -fprefetch-loop-arrays.
Yep, I think -fp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #190 from Jan Hubicka ---
> /ssd/firefox/js/src/gc/Marking.cpp: In function
> ???js::gc::IsAboutToBeFinalized(JSAtom**)bool [clone .isra.65]???:
> /ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted profile info:
> profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127
--- Comment #7 from Jan Hubicka ---
>
> that's kind of a pity, since IIRC one of the main reasons for recasting the
> emutls implementation as a separate pass was to allow for uses like this;
> but, having said that, probably not a high priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602
--- Comment #13 from Jan Hubicka ---
> Please, let me know if more info is needed.
Actually I got the same ICE in meantime. Here is improved patch (it is still
testing for me)
Index: cgraph.c
=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #34 from Jan Hubicka ---
> I can confirm that one call of resid now gets inlined on the branch
> even on x86_64 (I'm confused why, the dump seems to suggest all call
> sites would violate param max-inline-insns-auto limit but then one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
--- Comment #3 from Jan Hubicka ---
Hmm,
the problem here is that we output errors after early inlining always now,
while previously we did
only when some other inlining happened in the function (adding extra early
inlinable function
to the testca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #25 from Jan Hubicka ---
Updated patch.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #24 from Jan Hubicka ---
does this patch help?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #29 from Jan Hubicka ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
>
> --- Comment #28 from Martin Liška ---
> Gdb instruction dump of ScDocument::CalcAll, place where SIGSEGV was received
> is marked with '>', address: 0x2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551
--- Comment #6 from Jan Hubicka ---
Good to be assigned. I posted the patch
Jason, can you please look at
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00433.html
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
--- Comment #41 from Jan Hubicka ---
> > I however do not see any chained weakrefs in the preprocessed file
> > attached, so
> > I am not quite convinced this can change anything.
> >
> > Can you, please, run it in debugger and take a look what i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
--- Comment #38 from Jan Hubicka ---
> No longer a 4.9 regression, fixed by the patch for PR middle-end/57366.
Good news.
>
> Unfortunately, that doesn't easily backport to the 4.8 branch since that lacks
> alias and alias_target in struct symta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #14 from Jan Hubicka ---
Hi,
the problems with weakref are bit deeper than I though. They way RTL rewriting
is done
breaks completely with any symbol renaming that is quite common with LTO. I am
testing
the following
Index: cgraphun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #9 from Jan Hubicka ---
Hi,
the following patch sets IDENTIFIER_TRANSPARENT_ALIAS correctly from lto-symtab
(correct fix should do the same for variable aliases, too). Now the testcase
compiles for
me on Linux with weakref disabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318
--- Comment #7 from Jan Hubicka ---
> URL: http://gcc.gnu.org/viewcvs?rev=199140&root=gcc&view=rev
> Log:
> 2013-05-21 Richard Biener
>
> PR tree-optimization/57318
> * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Do not
> es
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #5 from Jan Hubicka ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
>
> --- Comment #4 from Uroš Bizjak ---
> The inlining is failed in ipa-inline.c, around line 294:
>
> /* TM pure functions should not be inlined into non
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57267
--- Comment #4 from Jan Hubicka ---
> is this PR duplicate of lto/57038 ?
You are right, I meant lto/57038.
This PR is not exactly dup of lto/57038, but while fixing lto/57038 I
constructed artificial testcase similar to yours
and thus the problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57294
--- Comment #6 from Jan Hubicka ---
> I've confirmed this is the case by putting a call to
> cgraph_rebuild_references into convert_callers_for_node and it "fixes"
> the issue. But of course that could be quite expensive.
Hmm, it is bit ugly to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57267
--- Comment #2 from Jan Hubicka ---
This is fixed by
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00695.html
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #18 from Jan Hubicka ---
> Callstack:
> [build CXX] store/source/stortree.cxx
> lto1: internal compiler error: in lto_balanced_map, at lto/lto-partition.c:566
> 0x52004f lto_balanced_map()
> ../../gcc/lto/lto-partition.c:566
M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #12 from Jan Hubicka 2013-05-03 16:48:41
UTC ---
> Hi,
>you are right, the symbol is also missing in FieldCacheImpl.o.
>
> Unlike FieldCacheImpl.o, propagg.o really contains symbol:
> _ZNSt11_Tuple_implILm0EJRKiEEC1Ev
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #9 from Jan Hubicka 2013-05-03 14:19:22 UTC
---
Hi,
I can not find any symbol
ZNSt11_Tuple_implILm0EJRKPN6lucene5index11IndexReaderEEEC1Ev in the
preprocessed file you added. Can you check if the symbol appears in LTO symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #7 from Jan Hubicka 2013-05-03 13:03:32 UTC
---
Hmm, not weakref but really weak alias of external function. This seems even
more weird.
What are the flags used to compile the .o file?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57084
--- Comment #3 from Jan Hubicka 2013-05-03 12:17:20 UTC
---
> @@ -1993,6 +1994,18 @@ ipa_intraprocedural_devirtualization (gi
>token = OBJ_TYPE_REF_TOKEN (otr);
>fndecl = gimple_get_virt_method_for_binfo (tree_low_cst (token, 1),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #4 from Jan Hubicka 2013-05-03 12:15:48 UTC
---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
>
> --- Comment #3 from Martin Liška 2013-05-03
> 11:20:00 UTC ---
> lto-partition.c:265 (add_symbol_to_partition)
>
> c++filt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #12 from Jan Hubicka 2013-04-25 20:52:39
UTC ---
> So yes, I'm in favor of turning the calls into builtin_trap or
> builtin_unreachable. Not sure which one. How do I get their call
> graph nodes?
cgraph_get_create_node (bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
--- Comment #3 from Jan Hubicka 2013-03-26 16:12:27 UTC
---
> Confirmed. We don't optimize callgraph cycles with one externally visible
> entry that way. And I believe we currently have no way of annotating a
> single call to resolve loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
--- Comment #3 from Jan Hubicka 2013-03-23 21:40:19 UTC
---
> This patch causes the destructor to be created and marked as COMDAT, but for
> some reason cgraph still isn't emitting it.
Thank you!. I will work out why it is not emitted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932
--- Comment #16 from Jan Hubicka 2013-03-18 11:04:58
UTC ---
> Since very recently (between 20130313 and 20130315) gfortran.dg/do_1.f90
> execution started to XPASS not only at -O0/-O1, but at every optimisation
> level.
> I think it woul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #37 from Jan Hubicka 2013-03-12 13:32:15
UTC ---
> > So perhaps the construction vtables should be always comdat hidden?
>
> Hmm? My earlier patch made them hidden, and they were already comdat. Do you
> mean something else
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557
--- Comment #8 from Jan Hubicka 2013-03-11 13:58:07 UTC
---
Yes, I agree it is GNU LD bug.
There is also GCC problem: this particular symbol should not appear in the LTO
symtab. It appears because we see the refernece, but the reference it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515
--- Comment #5 from Jan Hubicka 2013-03-04 16:06:25 UTC
---
> We build the function decls via build_fn_decl which ends up using
> input_location of the first random function we are processing.
>
> But that doesn't seem to be the issue af
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #18 from Jan Hubicka 2013-03-01 16:19:47
UTC ---
> I will take care of the early inlining problem. I wonder, you don't have
> oprofile of that, by any chance?
Aha, callee walking in update_inline_summary. Perhaps I will real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #17 from Jan Hubicka 2013-03-01 16:14:08
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
>
> --- Comment #12 from Steven Bosscher 2013-03-01
> 07:50:43 UTC ---
> Last night's compilation at -O1 with my hacks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #8 from Jan Hubicka 2013-02-19 21:09:54 UTC
---
>
Hi,
the patch seems to work well for Mozilla. There are two issues I noticed while
testing it
1) we now enable-checking ICE on cgraph_mark_address_taken when compiling
Moz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #7 from Jan Hubicka 2013-02-19 06:46:20 UTC
---
> Honza, any progress on this?
Oops, forgot to check the Firefox results. I am currently on a way, will do it
once arriving.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #4 from Jan Hubicka 2013-02-12 17:25:31 UTC
---
Hi,
this patch should make ipa_make_edge_direct_to_target to behave properly when
new symbol
needs to be inserted into the symbol table. We already have
canonicalize_construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56297
--- Comment #5 from Jan Hubicka 2013-02-12 16:23:37 UTC
---
> Confirmed. We put
>
> register int i asm ("esp");
>
> into the LTO symbol table. Oops. The GCC symtab and the partition contains
>
> (gdb) call debug_symtab_node (node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932
--- Comment #13 from Jan Hubicka 2013-02-04 00:16:44
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932
>
> --- Comment #12 from Dominique d'Humieres
> 2013-02-01 13:59:11 UTC ---
> (In reply to comment #11)
> > > > Thus,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56061
--- Comment #8 from Jan Hubicka 2013-01-30 17:16:25 UTC
---
> They are useful. It should be technically possible to support -O1 vs. -O0,
> and if not, we have means to forcefully enable -O1 at link-time (which we
> should do then).
I per
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #28 from Jan Hubicka 2013-01-28 19:05:40
UTC ---
> > 1) Just add the check. We will then miss all devirtualization oppurtunities
> >through the construction vtable.
>
> The front end does devirtualization itself for call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #26 from Jan Hubicka 2013-01-28 14:56:12
UTC ---
> perhaps making them hidden whenever possible is really desirable.
Yes, this seems fine to me. Just to be sure I understand the problem fully.
I believe there is still problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #23 from Jan Hubicka 2013-01-26 18:32:15
UTC ---
> I must say I'm surprised by the gimple-fold.c test, I'd really expect
> additional && DECL_VISIBILITY (decl) != VISIBILITY_DEFAULT .
> Another alternative to make those always
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
--- Comment #15 from Jan Hubicka 2013-01-19 21:48:12
UTC ---
> Clearing of address-taken does not work:
>
> two/1 (two) @0x7fafc0e29818
> Type: function
> Visibility: prevailing_def_ironly
> Address is taken.
> References:
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #173 from Jan Hubicka 2013-01-17 12:30:30
UTC ---
> Patch looks incomplete? What does dropping columns only do to memory use?
I will check. I remember that prior columns there was also some savings for
the cache.
Just savi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
--- Comment #12 from Jan Hubicka 2013-01-17 10:27:10
UTC ---
> Still a problem in latest 4.7, google/4.7, and trunk (4.8).
So 4.6 was working but 4.7 isn't?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #33 from Jan Hubicka 2013-01-11 17:36:48
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
>
> --- Comment #32 from H.J. Lu 2013-01-10 19:36:08
> UTC ---
> (In reply to comment #30)
> > LTO profiled-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927
--- Comment #1 from Jan Hubicka 2013-01-10 14:33:48 UTC
---
This will be usual difference of virtual call representation in ia64. The .cp
test is going fine?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875
--- Comment #12 from Jan Hubicka 2013-01-09 16:29:21
UTC ---
Shall we track the C testcase regression in 4.7 and earlier?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264
--- Comment #8 from Jan Hubicka 2013-01-09 15:23:54 UTC
---
> Let me look into those...
Try the patch I attached to PR45375
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48065
--- Comment #9 from Jan Hubicka 2013-01-04 21:26:04 UTC
---
> I think we don't fail late now, at least not in expand_call_inline (unless
> inline_failed is re-computed at LTRANS stage).
Yes, i think we simply produce invalid gimple and typ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823
--- Comment #5 from Jan Hubicka 2013-01-02 00:10:52 UTC
---
ipa-cp is behaving funny here. It clones InitCommon so THIS pointer's binfo is
known to enable devirtualization of SetLayoutDirection.
It doesn't devirtualize GetLayoutDirection
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823
--- Comment #4 from Jan Hubicka 2013-01-01 23:32:27 UTC
---
This is the usual problem of devirt benefit predicting more devirtualization
than inline-transform actually doing. This time it seems to be related to fact
that we first clone th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #21 from Jan Hubicka 2012-12-22 23:20:37
UTC ---
> I'll give this patch a try and let you know how it affects the
> performance I see. But unrolling shouldn't affect inlining, since all
> unrolling is after inlining, right?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #19 from Jan Hubicka 2012-12-21 16:15:34
UTC ---
> As another data point, in our internal benchmarks I had tried a few
> values and 99.9% gave the best performance. Just going down to 99.0%
> reduced the inlining too much, even
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #22 from Jan Hubicka 2012-12-21 14:22:28
UTC ---
> There would be if we had ADD_RESTRICT or something similar. But we don't
> right
> now, so supposedly it would be better to avoid such IPA-CP changes if it
> removes restrict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #17 from Jan Hubicka 2012-12-21 13:49:15
UTC ---
> Nothing to fix for me - it's the IPA-CP decision that pessimizes things.
Well, replacing parameter by known constant should not pessimize in general...
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55686
--- Comment #10 from Jan Hubicka 2012-12-21 13:48:19
UTC ---
> Honza, any thoughts on this (both the combine vs. strset and local register
> vars vs. string insns)?
Well, Steven's suggestion to track local explicit reg vars in seems reso
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #17 from Jan Hubicka 2012-12-18 17:25:37
UTC ---
> I did some measurements with tramp3d and in this case
> the default (999) gives the best performance:
>
> par. sizetime
>
> 999 955859 3.71752
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #15 from Jan Hubicka 2012-12-18 15:40:34
UTC ---
> It's hard to say in case of Firefox, because the only thing
> that one can reliably measure is the JavaScript performance.
> And this varies only very slightly with different c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683
--- Comment #9 from Jan Hubicka 2012-12-18 13:39:45 UTC
---
> Bumping the limit to assert on to off-by-two doesn't fix all cases (I can
> hand you a testcase if you like...)
Yep, i guess it just depends on how many calls we diverge. I w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55684
--- Comment #8 from Jan Hubicka 2012-12-14 18:36:48 UTC
---
> First when in estimate_numbers_of_iterations_loop, number_of_iterations_exit
> succeeds, then in find_loop_niter called from
> canonicalize_loop_induction_variables it fails, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #163 from Jan Hubicka 2012-12-14 18:24:31
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
>
> --- Comment #162 from Markus Trippelsdorf
> 2012-12-13 22:25:27 UTC ---
> The libxul binary size issue is solved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476
--- Comment #10 from Jan Hubicka 2012-12-13 20:56:13
UTC ---
> (gdb) call debug_tree (node->symbol.decl)
> type size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x767f75e8 precision
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #159 from Jan Hubicka 2012-12-12 20:35:37
UTC ---
> hal/Hal.gcda: 96.72%: num counts=30069, min counter=16389
> hal/Hal.gcda: 97.50%: num counts=35296, min counter=10241
> hal/Hal.gcda: 98.28%: num
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
--- Comment #14 from Jan Hubicka 2012-12-10 16:26:40
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
>
> --- Comment #13 from Richard Biener 2012-12-10
> 14:14:07 UTC ---
> (In reply to comment #9)
> > This is reduced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395
--- Comment #10 from Jan Hubicka 2012-12-04 16:25:36
UTC ---
> It is always used if available and there is no other way to generate the
> location info for it (which for vars that were removed from the varpool is
> probably always, I bet t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395
--- Comment #8 from Jan Hubicka 2012-12-04 14:46:06 UTC
---
> (the DECL_INITIAL setting to error_mark_node). I can understand the aim at
> saving compile time memory, but this is a wrong thing to do. dwarf2out.c uses
> DECL_INITIAL heavi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
--- Comment #14 from Jan Hubicka 2012-12-03 23:24:13
UTC ---
> > Someone needs to do something here because the C/C++/Fortran testsuite
> > results
> > are abysmal at -O3.
>
> And the tentative fix doesn't really help, it turns the ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #152 from Jan Hubicka 2012-12-02 21:09:24
UTC ---
Also I suppose you don't have comparsion to 4.7 handy? (I am curious because of
inliner heuristic re-tunning)
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #151 from Jan Hubicka 2012-12-02 20:52:13
UTC ---
Teresa comitted another bugfix just today. So with bit of luck it will work
now?
I will try to look deeper into it ASAP, but I am just getting ready for trip to
USA.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #149 from Jan Hubicka 2012-12-02 15:05:52
UTC ---
> > Please try to reduce HOT_BB_COUNT_WS_PERMILLE to 990. I also see some
> > regressions
> > on some SPEC benchmarks (such as GCC) and this helps. If it doesn't it
> > would b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from Jan Hubicka 2012-12-02 11:03:53 UTC
---
> I'm pretty sure there are no out-of-bounds. In particular coef_x is easy to
> check, it is only used as coef_x(:,lxp) where lxp is the loop bound 0..lp
> consistent with its def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #147 from Jan Hubicka 2012-12-02 09:23:09
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
>
> --- Comment #146 from Markus Trippelsdorf
> 2012-12-02 07:36:02 UTC ---
> (In reply to comment #145)
> > >
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #145 from Jan Hubicka 2012-12-01 22:09:07
UTC ---
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
>
> --- Comment #144 from Markus Trippelsdorf
> 2012-12-01 12:39:30 UTC ---
> It looks like there is a LTO code-size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #1 from Jan Hubicka 2012-11-26 12:45:23 UTC
---
> /export/project/git/gcc-regression-bootstrap/master/191466/bld/gcc/cc1...done.
> (gdb) whatis global_options
> type =
> (gdb) whatis cl_options
> type =
> (gdb) whatis cl_e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #29 from Jan Hubicka 2012-11-16 18:57:41
UTC ---
>
> I'm confused - that is essentially what it is doing today (although
> comparing against the first merged file instead of the last merged
> file). It isn't expecting all the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #24 from Jan Hubicka 2012-11-15 10:56:53
UTC ---
> Note though that this is not an assert. It just emits a message to
> stderr. Do you think a better error message is appropriate? I'm not
> sure the "some data files may have be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #21 from Jan Hubicka 2012-11-15 02:01:01
UTC ---
> Ok, I can do that. I had tried that but didn't see any gain yet (need
> to take a look at my results again). I have been playing with teasing
> apart the various uses of this c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #19 from Jan Hubicka 2012-11-15 01:42:55
UTC ---
> Oh got it - it is this one, right?:
>
> profiling:/home/tejohnson/extra/gcc_trunk_3_obj/libcpp/files.gcda:Invocation
> mismatch - some data files may have been removed
Yes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #40 from Jan Hubicka 2012-11-14 23:54:44
UTC ---
mgrid do not seem to be sensitive to --param min-inline-speedup, so it seems
independent regression of this change.
No idea what goes wrong.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717
--- Comment #13 from Jan Hubicka 2012-11-14 19:43:00
UTC ---
> So for the loop that starting at bb 28 you can see the xxtrt_46 access was not
> put into pretemp. Possible reason is exactly as it was mentioned by Richard -
> there were extr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #7 from Jan Hubicka 2012-11-14 15:35:26 UTC
---
> --- Comment #6 from Markus Trippelsdorf
> 2012-11-14 15:13:08 UTC ---
> (In reply to comment #5)
> > There are
> >
> > badness = (relative_time_benefit (callee_info,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55187
--- Comment #2 from Jan Hubicka 2012-11-03 16:44:14 UTC
---
> --- Comment #1 from Andreas Schwab 2012-11-03
> 15:23:25 UTC ---
> Also fails on powerpc, likely universal.
Yes, it fails for me too, I am looking into it.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168
--- Comment #2 from Jan Hubicka 2012-11-01 20:49:18 UTC
---
This actually looks like a previously latent issue in predict.c For all but
estimate_num_iterations_int. It uses the funny definition of number of
iterations (i.e. 0 means that l
601 - 700 of 1212 matches
Mail list logo
