https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #36 from Jan Hubicka ---
Author: hubicka
Date: Sat Dec 2 09:22:41 2017
New Revision: 255357
URL: https://gcc.gnu.org/viewcvs?rev=255357&root=gcc&view=rev
Log:
PR target/81616
* x86-tune.def: Remove obsolette FIXMEs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #37 from Jan Hubicka ---
Author: hubicka
Date: Mon Dec 4 23:59:11 2017
New Revision: 255395
URL: https://gcc.gnu.org/viewcvs?rev=255395&root=gcc&view=rev
Log:
PR target/81616
* athlon.md: Disable for generic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77472
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60016
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
||2016-09-11
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jan Hubicka ---
I think this has been fixed with last alias reorg, but double-checking and
having a testcase would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54839
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58203
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70582
--- Comment #6 from Jan Hubicka ---
Does this still reproduce? I have implemented the optimization that removes
weakrefs with definition provided in other unit so this may be solved/hidden by
it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63416
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64316
--- Comment #5 from Jan Hubicka ---
Author: hubicka
Date: Sun Sep 11 12:08:28 2016
New Revision: 240081
URL: https://gcc.gnu.org/viewcvs?rev=240081&root=gcc&view=rev
Log:
PR ipa/64316
* gcc.dg/ipa/pr63416.c: New testcase.
Added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159
--- Comment #3 from Jan Hubicka ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Sun Sep 11 12:15:02 2016
New Revision: 240082
URL: https://gcc.gnu.org/viewcvs?rev=240082&root=gcc&view=rev
Log:
PR ipa/61159
* compile/pr61159.c: New testcase
Added:
||2016-09-11
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jan Hubicka ---
Seems the testcase is not complete. Does it still reproduce?
||2016-09-11
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Jan Hubicka ---
Works for me with current mainline and it is not obvious to me what went wrong
in 4.6
Does it still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71089
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #9 from Jan Hubicka -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #10 from Jan Hubicka ---
Actually the problem here seems to be that we soon work out that most of edges
are never executed, yet we still inlining them. The metrics are not growing
then so we take time to hit the limits. I guess with a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #11 from Jan Hubicka ---
Created attachment 32439
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32439&action=edit
Patch I am testing
this patch implements the trick of redirecting call edges to UNREACHABLE. It
solves the compil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600
--- Comment #6 from Jan Hubicka ---
The patch looks fine to me with an testcase added checking for the warning.
I sort of hoped that the type based devirt code in ipa-cp won't get into
completely contradicting answers, but that was at a time when
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #10 from Jan Hubicka ---
I will take a look.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #12 from Jan Hubicka ---
Created attachment 32442
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32442&action=edit
Better patch
I am attaching more complete patch. There is quite bad wrong code bug in
pure-const that updates dec
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #2 from Jan Hubicka ---
Mine. And I was about to declare ipa-devirt to be officially 100% bug free :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #13 from Jan Hubicka ---
Author: hubicka
Date: Wed Mar 26 02:11:57 2014
New Revision: 208831
URL: http://gcc.gnu.org/viewcvs?rev=208831&root=gcc&view=rev
Log:
PR ipa/60315
* cif-code.def (UNREACHABLE) New code.
* ipa-inli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
--- Comment #14 from Jan Hubicka ---
The compile time hog issue is fixed now. We still fix the predicates for
switch statement (to get pass NOP_EXPR) since it seems very common pattern.
Richard: I suppose we can't fold away the NOP_EXPR easily e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
--- Comment #13 from Jan Hubicka ---
BTW, compiled with C++ FE we seem to have important bottleneck in
linemap_macro_map_lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243
--- Comment #14 from Jan Hubicka ---
Author: hubicka
Date: Fri Mar 28 19:50:28 2014
New Revision: 208916
URL: http://gcc.gnu.org/viewcvs?rev=208916&root=gcc&view=rev
Log:
PR ipa/60243
* ipa-inline.c (want_inline_small_function_p): Short c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659
--- Comment #4 from Jan Hubicka ---
OK, this is ICE on type inconsistent program (it looks up virtual function in
non-virtual type). I forgot gcc_unreacable on that code path from earlier
sanity checking.
I will arrange such inconsistent calls to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659
--- Comment #5 from Jan Hubicka ---
Created attachment 32494
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32494&action=edit
Patch I am testing
This is patch that makes us to redirect those type inconsistent calls to
builtin_unreachable. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449
--- Comment #11 from Jan Hubicka ---
> OTOH, why do we have to merge the decls/cgraph nodes at all? Can't we simply
> make them aliases if tree merging decides the decls are not equal?
If we do so, we would never merge external declaration from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659
--- Comment #6 from Jan Hubicka ---
Author: hubicka
Date: Thu Apr 3 03:55:59 2014
New Revision: 209048
URL: http://gcc.gnu.org/viewcvs?rev=209048&root=gcc&view=rev
Log:
PR ipa/60659
* ipa-devirt.c (get_polymorphic_call_info): Do not ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626
--- Comment #21 from Jan Hubicka ---
Author: hubicka
Date: Fri Apr 4 18:02:31 2014
New Revision: 209123
URL: http://gcc.gnu.org/viewcvs?rev=209123&root=gcc&view=rev
Log:
PR ipa/59626
* lto-cgraph.c (input_overwrite_node): Check that par
||2014-04-05
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jan Hubicka ---
Not really a bug, since can_refer is unused in that case, but I will add
initialization to that code path, it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567
--- Comment #14 from Jan Hubicka ---
OK, the problem is that one comdat group has two functions:
_ZNK19MutableIntegerValue18isValidNativeValueEi/0 (isValidNativeValue)
@0x76adfe18
Type: function definition analyzed
Visibility: forced_by_ab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60567
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #15 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820
--- Comment #4 from Jan Hubicka ---
I am testing the following
Index: /aux/hubicka/trunk-test/gcc/varpool.c
===
--- /aux/hubicka/trunk-test/gcc/varpool.c (revision 209170)
+++ /
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820
--- Comment #5 from Jan Hubicka ---
Author: hubicka
Date: Mon Apr 14 17:53:34 2014
New Revision: 209389
URL: http://gcc.gnu.org/viewcvs?rev=209389&root=gcc&view=rev
Log:
PR lto/60820
* varpool.c (varpool_remove_node): Do not alter decls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60854
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Jan Hubicka -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60854
--- Comment #3 from Jan Hubicka ---
OK, the problem is that we see the reference to alias and decide to keep the
alias for future inlining. But when processing the refernce from alias to
function itself, we throw it away. We need to keep the body,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60854
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Thu Apr 17 02:22:57 2014
New Revision: 209459
URL: http://gcc.gnu.org/viewcvs?rev=209459&root=gcc&view=rev
Log:
PR ipa/60854
* ipa.c (symtab_remove_unreachable_nodes): Mark target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Thu Apr 17 02:32:26 2014
New Revision: 209460
URL: http://gcc.gnu.org/viewcvs?rev=209460&root=gcc&view=rev
Log:
PR lto/60820
* gcc.dg/lto/pr60820_0.c: New testcase.
* gcc.dg/l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60871
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Jan Hubicka -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899
--- Comment #5 from Jan Hubicka ---
I am running benchmarks I do not want to disturb, but the following should fix
the problem.
$ svn diff ../../gcc/gimple-fold.c
Index: ../../gcc/gimple-fold.c
=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #4 from Jan Hubicka ---
Mine, probably 4.9 regression, too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60871
--- Comment #5 from Jan Hubicka ---
This is yet another case where get_binfo_at_offset incorrectly returns NULL
(wich is in there for long time, but before we started sanity check it just led
to missed optimizations).
In class D there is base C7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60871
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
--- Comment #6 from Jan Hubicka ---
I am testing the attached patch.
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 209913)
+++ ipa-devirt.c(working copy)
@@ -1137,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
--- Comment #15 from Jan Hubicka ---
Author: hubicka
Date: Mon May 5 19:40:34 2014
New Revision: 210079
URL: http://gcc.gnu.org/viewcvs?rev=210079&root=gcc&view=rev
Log:
PR ipa/60965
* g++.dg/ipa/devirt-31.C: New testcase.
* g++.dg/i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
--- Comment #16 from Jan Hubicka ---
Author: hubicka
Date: Mon May 5 23:27:40 2014
New Revision: 210086
URL: http://gcc.gnu.org/viewcvs?rev=210086&root=gcc&view=rev
Log:
PR ipa/60965
* ipa-devirt.c (get_class_context): Allow POD to chan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60973
--- Comment #2 from Jan Hubicka ---
I wonder if the tailcall flag can't be reliably set by tree-tailcall, but i
suppose we want tailcall in thunks even at -O0.
The patch seems fine to me.
Note that this is not ipa-devirt issue, just semi-latent bu
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #19 from Jan Hubicka ---
What seems to go wrong is that we try to analyze builtin_unreachable size/time
that should not happen. It would help to know the dump_cgraph_node of the node
of builtin_unreachable (or have full cgraph dump). I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60854
--- Comment #6 from Jan Hubicka ---
Author: hubicka
Date: Sat May 17 22:18:25 2014
New Revision: 210563
URL: http://gcc.gnu.org/viewcvs?rev=210563&root=gcc&view=rev
Log:
PR ipa/60854
* ipa.c (symtab_remove_unreachable_nodes): Mark targe
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #11 from Jan Hubicka ---
Mine, that testcase is fragile, perhaps we can just disable the template (it
was originally testing a scenario that no longer happens anyway)
||2014-05-19
CC||hubicka at gcc dot gnu.org
Assignee|ian at airs dot com|hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #4 from Jan Hubicka ---
I am going to reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232
--- Comment #6 from Jan Hubicka ---
Well, is there a reason why I can not place static symbol into the comdat
section, just as we do for labels within functions or thunks? Those also do not
have unique name.
It seems to me that there is a problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232
--- Comment #7 from Jan Hubicka ---
Created attachment 32821
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32821&action=edit
patch I am testing
This patch seems to do what I want - it makes the comdat local variables to be
in the comdat g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820
--- Comment #10 from Jan Hubicka ---
Author: hubicka
Date: Wed May 21 02:32:00 2014
New Revision: 210671
URL: http://gcc.gnu.org/viewcvs?rev=210671&root=gcc&view=rev
Log:
PR lto/60820
* varpool.c (varpool_remove_node): Do not alter decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
--- Comment #28 from Jan Hubicka ---
Author: hubicka
Date: Wed May 21 05:40:09 2014
New Revision: 210673
URL: http://gcc.gnu.org/viewcvs?rev=210673&root=gcc&view=rev
Log:
PR bootstrap/60984
* ipa-inline-transform.c (inline_call): Use ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
--- Comment #29 from Jan Hubicka ---
Author: hubicka
Date: Wed May 21 05:41:46 2014
New Revision: 210674
URL: http://gcc.gnu.org/viewcvs?rev=210674&root=gcc&view=rev
Log:
PR bootstrap/60984
* ipa-inline-transform.c (inline_call): Use ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61232
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094
--- Comment #12 from Jan Hubicka ---
Author: hubicka
Date: Wed May 21 05:52:07 2014
New Revision: 210675
URL: http://gcc.gnu.org/viewcvs?rev=210675&root=gcc&view=rev
Log:
PR middle-end/58094
* g++.dg/ipa/devirt-11.C: Be lax about number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899
--- Comment #10 from Jan Hubicka ---
Author: hubicka
Date: Wed May 21 06:16:03 2014
New Revision: 210676
URL: http://gcc.gnu.org/viewcvs?rev=210676&root=gcc&view=rev
Log:
PR tree-optimization/60899
* gimple-fold.c (can_refer_decl_in_cur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012
--- Comment #3 from Jan Hubicka ---
It is LTO-symtab bug. In this case we have chain with static var and external
decl and we find no prevailing symbol (correctly), but then instead of choosing
the external decl for further merging we go with st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Thu May 22 05:35:32 2014
New Revision: 210739
URL: http://gcc.gnu.org/viewcvs?rev=210739&root=gcc&view=rev
Log:
PR lto/61012
* lto-symtab.c (lto_symtab_merge_decls_1):
Modified:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012
--- Comment #5 from Jan Hubicka ---
Author: hubicka
Date: Thu May 22 05:38:04 2014
New Revision: 210740
URL: http://gcc.gnu.org/viewcvs?rev=210740&root=gcc&view=rev
Log:
PR lto/61012
* lto-symtab.c (lto_symtab_merge_decls_1): Do not ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #211 from Jan Hubicka ---
Elfhack is rather sensitive to LTO, but it works for me, so this seems like
binutils issue or some elfhack change that happened recently.
I wrote instructions for building firefox with LTO here
http://hubicka
||2014-06-09
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jan Hubicka ---
Mine,
seems like the symbol is not removed for reason not seen by the dataflow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510
--- Comment #1 from Jan Hubicka ---
What happens at the line 1054 of cgraphunit.c.
= cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl));
origin_node->used_as_abstract_origin = true;
Do you really get into case where
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #2 from Jan Hubicka ---
Mine.
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #4 from Jan Hubicka ---
Mine.
||2015-03-10
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jan Hubicka ---
Will take a look. Is it an open source program? I may include it into my
testing :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65394
--- Comment #3 from Jan Hubicka ---
Yep, a testsuite issue - we now get a mismatch earlier because the non-volatile
case turns out to be pure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65355
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337
--- Comment #3 from Jan Hubicka ---
Indeed, the cd-dce is one the worst documented of the tradition SSA
optimizations. I commented on this to Jakum on IRC. The mechanizm that should
prevent conditional from being removed is the control dependenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #4 from Jan Hubicka ---
Hmm, this one compiles just fine for me with today mainline. Does the problem
still reproduce for you? Can you possibly dump out node->debug() and c?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439
--- Comment #3 from Jan Hubicka ---
Can you attach the dump file? It is probalby due to lack of aliases, but I am
bit surprises the number of equal symbols grows up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #8 from Jan Hubicka ---
I am with terrible internet connection and it still does not reproduce for me
(I suppose difference between GNU LD and gold).
It is however clear what happens, we try to add symbol's alias that is external
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #9 from Jan Hubicka ---
please also attachg WPA dump of -fdump-ipa-cgraph. I would be interested what
visibility _ZTCN7Utility2IO12GUnzipStreamE0_So/7 has.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439
--- Comment #5 from Jan Hubicka ---
I see, the difference is _ZN12_GLOBAL__N_11AC1Ev that is same body alias on
targets supporting it, but not on Darwin where C++ FE produces a duplicate.
I suppose we want just relax the testcase template to acce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #10 from Jan Hubicka ---
Actually perhaps we manage to produce external alias of non-external symbol
that also should not happen.
Index: ipa-icf.c
===
--- ipa-icf.c (re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380
--- Comment #14 from Jan Hubicka ---
Ah, thanks! The patch fixed as in coment #10 is OK for mainline. We obviously
should not try to do any merging of external symbols; it is pointless. We only
want to calculate equivalences on these to merge no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
--- Comment #5 from Jan Hubicka ---
Well, the problem is that -r is the only case where we get LDPR_PREVAILING_DEF
or IRONLY and the resulting symbol may be removed from the unit later.
We would need a new LDPR_PREVAILING_DEF_FOR_NOW or something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
--- Comment #6 from Jan Hubicka ---
(just to explain bit more - the main difference between static and dynamic
linking here is that dynamic linking never remove any definition and thus you
can dissolve comdat groups)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051
--- Comment #5 from Jan Hubicka ---
yep, this seems to be the usual situation where visibilities does not mix that
well with assumptions that program is linked with symbols defined in the
headers.
I suppose we could make C++ FE to track if a typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||2015-03-19
CC||hubicka at gcc dot gnu.org
Assignee|hubicka at ucw dot cz |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jan Hubicka ---
Mine. The type1 should not be
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
As reported to me privately by Igor, crafty SPEC2k benchmark is slower since
r219863 which decreased inline-unit-growth.
I looked into the reason and it is the fact that we do not inline NextMove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka changed:
What|Removed |Added
Component|tree-optimization |ipa
Summary|crafty performance
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
bzip2 contains:
INLINE UInt32 bsR ( Int32 n )
{
UInt32 v;
bsNEEDR ( n );
v = (bsBuff >> (bsLive-n)) & ((1 << n)-1);
bsLive -= n;
return v;
}
and
INLNE void bsW ( Int32 n, UInt32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483
--- Comment #1 from Jan Hubicka ---
Benchmarking build with -O3 -flto -Ofast -funroll-loops
For mainline I get (running on input.graphic)
real0m35.673s
user0m35.556s
sys 0m0.133s
and setting early-inlining-insns=80 to get bsR/bsW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
--- Comment #3 from Jan Hubicka ---
The following should help:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 221528)
+++ ipa-devirt.c(working copy)
@@ -1412,9 +14
1501 - 1600 of 3603 matches
Mail list logo
