http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #14 from Jan Hubicka hubicka at ucw dot cz ---
I use the following workaround for time being.
Honza
Index: tree-ssa-threadedge.c
===
--- tree-ssa-threadedge.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201
--- Comment #13 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #3 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz ---
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 #11 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #6 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58250
--- Comment #3 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329
--- Comment #1 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #195 from Jan Hubicka hubicka at ucw dot cz ---
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=45375
--- Comment #190 from Jan Hubicka hubicka at ucw dot cz ---
/ssd/firefox/js/src/gc/Marking.cpp: In function
???js::gc::IsAboutToBeFinalizedJSAtom(JSAtom**)bool [clone .isra.65]???:
/ssd/firefox/js/src/gc/Marking.cpp:1713:1: error: corrupted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602
--- Comment #13 from Jan Hubicka hubicka at ucw dot cz ---
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 hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
--- Comment #3 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #25 from Jan Hubicka hubicka at ucw dot cz ---
Updated patch.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #29 from Jan Hubicka hubicka at ucw dot cz ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #28 from Martin Liška marxin.liska at gmail dot com ---
Gdb instruction dump of ScDocument::CalcAll, place where SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #24 from Jan Hubicka hubicka at ucw dot cz ---
does this patch help?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57551
--- Comment #6 from Jan Hubicka hubicka at ucw dot cz ---
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 #38 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
--- Comment #41 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #14 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz ---
URL: http://gcc.gnu.org/viewcvs?rev=199140root=gccview=rev
Log:
2013-05-21 Richard Biener rguent...@suse.de
PR tree-optimization/57318
* tree-ssa-loop-ivcanon.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57267
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
The inlining is failed in ipa-inline.c, around line 294:
/* TM pure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57294
--- Comment #6 from Jan Hubicka hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57267
--- Comment #2 from Jan Hubicka hubicka at ucw dot cz ---
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 hubicka at ucw dot cz ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2013-05-03 12:15:48 UTC
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #3 from Martin Liška marxin.liska at gmail dot com 2013-05-03
11:20:00 UTC ---
lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57084
--- Comment #3 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz 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=57038
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #12 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #12 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
--- Comment #3 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
--- Comment #3 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932
--- Comment #16 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #37 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557
--- Comment #8 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #17 from Jan Hubicka hubicka at ucw dot cz 2013-03-01 16:14:08
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #12 from Steven Bosscher steven at gcc dot gnu.org 2013-03-01
07:50:43 UTC ---
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135
--- Comment #18 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #8 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz 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=56297
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932
--- Comment #13 from Jan Hubicka hubicka at ucw dot cz 2013-02-04 00:16:44
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932
--- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr
2013-02-01 13:59:11 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56061
--- Comment #8 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #26 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #28 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #23 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
--- Comment #15 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
--- Comment #12 from Jan Hubicka hubicka at ucw dot cz 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=45375
--- Comment #173 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #33 from Jan Hubicka hubicka at ucw dot cz 2013-01-11 17:36:48
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #32 from H.J. Lu hjl.tools at gmail dot com 2013-01-10 19:36:08
UTC ---
(In reply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927
--- Comment #1 from Jan Hubicka hubicka at ucw dot cz 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=55264
--- Comment #8 from Jan Hubicka hubicka at ucw dot cz 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=55875
--- Comment #12 from Jan Hubicka hubicka at ucw dot cz 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=48065
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #21 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55686
--- Comment #10 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #17 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #22 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #19 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #15 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55674
--- Comment #17 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #163 from Jan Hubicka hubicka at ucw dot cz 2012-12-14 18:24:31
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #162 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-12-13 22:25:27 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55684
--- Comment #8 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53476
--- Comment #10 from Jan Hubicka hubicka at ucw dot cz 2012-12-13 20:56:13
UTC ---
(gdb) call debug_tree (node-symbol.decl)
var_decl 0x768045f0 Wv10a
type integer_type 0x767f75e8 int public SI
size integer_cst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #159 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
--- Comment #14 from Jan Hubicka hubicka at ucw dot cz 2012-12-10 16:26:40
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2012-12-10
14:14:07 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395
--- Comment #8 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395
--- Comment #10 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158
--- Comment #14 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #147 from Jan Hubicka hubicka at ucw dot cz 2012-12-02 09:23:09
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #146 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-12-02 07:36:02 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #149 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #151 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #152 from Jan Hubicka hubicka at ucw dot cz 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 #145 from Jan Hubicka hubicka at ucw dot cz 2012-12-01 22:09:07
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #144 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-12-01 12:39:30 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #1 from Jan Hubicka hubicka at ucw dot cz 2012-11-26 12:45:23 UTC
---
/export/project/git/gcc-regression-bootstrap/master/191466/bld/gcc/cc1...done.
(gdb) whatis global_options
type = data variable, no debug info
(gdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #29 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #24 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz 2012-11-14 15:35:26 UTC
---
--- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-11-14 15:13:08 UTC ---
(In reply to comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717
--- Comment #13 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #40 from Jan Hubicka hubicka at ucw dot cz 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=55051
--- Comment #19 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #21 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55187
--- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2012-11-03 16:44:14 UTC
---
--- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2012-11-03
15:23:25 UTC ---
Also fails on powerpc, likely universal.
Yes, it fails for me too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168
--- Comment #2 from Jan Hubicka hubicka at ucw dot cz 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55078
--- Comment #3 from Jan Hubicka hubicka at ucw dot cz 2012-10-27 07:05:26 UTC
---
Fails for me, too, so likely universal. Seems ordering issue with the inliner
patches. Works in my tree - I will work out what fix solved it and fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55078
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2012-10-27 09:18:09 UTC
---
Actually, this seems like another latent problem in devirtualization. We
assert because estimate_edge_devirt_benefit works out we can devirtualize the
call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz 2012-10-23 13:55:24 UTC
---
Thus, I close the bug as INVALID.
... in wich case could you, please, update the testcase to be valid and remove
the XFAIL I introduced?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54966
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz 2012-10-23 13:59:38 UTC
---
I'm not sure how we count the initial unit size, given that when not using
LTO not merged comdats are probably counted here, so overall they add up
while
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz 2012-10-23 14:03:06 UTC
---
you are using indirect function calls here, GCC in 4.6 is not smart enough
to transform them to direct calls before inlining. Inlining of
always-inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54966
--- Comment #6 from Jan Hubicka hubicka at ucw dot cz 2012-10-23 14:12:43 UTC
---
The patch suggesed by Dminique is not going to help here.
I was just guessing why our overall unit-growth heuristics would
lead to different overall
601 - 700 of 1199 matches
Mail list logo
