https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
--- Comment #6 from Jan Hubicka ---
Author: hubicka
Date: Fri Mar 20 18:19:18 2015
New Revision: 221542
URL: https://gcc.gnu.org/viewcvs?rev=221542&root=gcc&view=rev
Log:
PR ipa/65475
* ipa-devirt.c (add_type_duplicate): Prevail polymor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #36 from Jan Hubicka ---
This is probably too risky to fix for 5.1
(https://gcc.gnu.org/ml/gcc/2015-03/msg00241.html) though I am having WIP patch
now - we need to introduce transparent alias support and make lto-symtab to
turn incomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
--- Comment #7 from Jan Hubicka ---
I suppose proper fix is to make flag_incremental_linking and turn -r from
Driver only. Then we could revisit individual optimizations that do rely on
the fact that static linking will not be re-done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
Jan Hubicka changed:
What|Removed |Added
Assignee|hubicka at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
--- Comment #7 from Jan Hubicka ---
The ICE is now fixed. I will leave this open to fix the duplicated ODR warnings
(we probably only want to warn once per type).
Martin, can you commit the testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #9 from Jan Hubicka ---
Concerning Comment #7, I do not think the sreal refactoring screwed things up.
sreals are not high on profile and the code generated is not worse (performance
wise). It is not better, but it is not a surprise -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #10 from Jan Hubicka ---
I can re-confirm the 16% compile time regression. I went through some compare.
$ wc -l *.ssa
299231 tramp3d-v4.ii.015t.ssa
$ wc -l ../5/*.ssa
331115 ../5/tramp3d-v4.ii.018t.ssa
so as a lame compare, we alre
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
I just noticed that C++ destructors are not conisdered const/pure:
local analysis of Smarts::IterateScheduler::~IterateScheduler()
scanning: MEM[(struct &)this_2(D)] ={v} {CLOBBER};
Indirect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #11 from Jan Hubicka ---
Sorry, the number of clobbers drops at DSE1, not during ehcleanup2, I just
messed up my grep.
I tried the following patch:
Index: passes.def
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #12 from Jan Hubicka ---
Also the number of statements is about the same at .cfg dump, so it is .ssa
that introduces all the differences. Why?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65502
--- Comment #1 from Jan Hubicka ---
The following patch makes ipa-pure-const to detect these functions as
pure/const.
There are two issues
1) I think we should preserve clobber semantic when removing a call to
pure/const
destructor. I wonde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65502
--- Comment #2 from Jan Hubicka ---
Author: hubicka
Date: Sun Mar 22 21:10:24 2015
New Revision: 221574
URL: https://gcc.gnu.org/viewcvs?rev=221574&root=gcc&view=rev
Log:
PR ipa/65502
* ipa-comdats.c (enqueue_references): Walk through t
||2015-03-22
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Target Milestone|--- |6.0
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #3 from Jan
||2015-03-23
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Jan Hubicka ---
Hi,
I hope this is fixed by
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01151.html
(I plan to commit that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Mon Mar 23 00:17:07 2015
New Revision: 221582
URL: https://gcc.gnu.org/viewcvs?rev=221582&root=gcc&view=rev
Log:
PR ipa/65475
* ipa-devirt.c: Include demangle.h
(odr_type_d):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
--- Comment #8 from Jan Hubicka ---
Created attachment 35100
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35100&action=edit
partial patch
Hi,
this is a patch that adds necessary checks into resolution code. Basically if
static linking is
||2015-03-24
CC||hubicka at gcc dot gnu.org,
||mliska at suse dot cz
Target Milestone|--- |6.0
Ever confirmed|0 |1
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
As shown in https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01151.html
warnings seems to come out wrong with large programs. I did not manage to
reproduce it with small testcase. Columns tends to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65516
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531
--- Comment #2 from Jan Hubicka ---
Hmm, there is missing empty statement after the for loop.
There are two external symbols where we do not really build comdat groups
(maybe we could now as they preserve little bit of useful info). So i guess I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #20 from Jan Hubicka ---
It seems that manuel just commented out the actual insertion to linemap,
columns are still streamed and ignored.
Doing so will clearly make ODR waring more difficult to follow, so perhaps we
could try to go f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #24 from Jan Hubicka ---
Manuel, you may be right person to implement the streaming of linemaps then :)
I suppose we do care about inline stacks in longer term to get proper warnings.
We even may want to preserve macro expansion and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #16 from Jan Hubicka ---
The chkp stuff is IMO bit problematic. I was thinking about cutting the
optimization queue but was always hesitant to do so because of the cache
locality and other implications. I am not sure if that was consi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
Jan Hubicka changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #40 from Jan Hubicka ---
Manuel,
the following way you get the lto1 invocation:
jan@linux-qos1:~> gcc t.c -flto -O2 -c
jan@linux-qos1:~> gcc t.o -flto -O2 --verbose -save-temps 2>&1 | grep lto1
/usr/lib64/gcc/x86_64-suse-linux/4.8/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22501
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #21 from Jan Hubicka ---
Actually, looking at the code, I do not think we want full pure/const pass
(that build loops and attmepts to prove finiteness). We only want to run
nothrow discovery that is a lot cheaper and perhaps we want t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #23 from Jan Hubicka ---
Also with early-inlining-insns=11 the statement count is smaller for mainline
(copmared to 4.9) until the pass bswap, it grows up in PRE (by about 1%) and
then it continues growing with subsequent passes. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #24 from Jan Hubicka ---
Author: hubicka
Date: Fri Mar 27 04:02:28 2015
New Revision: 221719
URL: https://gcc.gnu.org/viewcvs?rev=221719&root=gcc&view=rev
Log:
PR ipa/65076
* passes.def: Add pass_nothrow.
* ipa-pure-cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #46 from Jan Hubicka ---
Manuel,
I will hopefully commit the cache patch today or tomorrow morning. It does not
solve full issue. What we have is
1) we still drop columns for firefox&chromium pretty early
2) there is a bug that we som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #25 from Jan Hubicka ---
The memory use report:
rtl.c:317 (copy_rtx)9610680: 1.6% 0:
0.0% 0: 0.0% 0: 0.0% 401870
tree.c:8281 (build_method_type_directly)28395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #47 from Jan Hubicka ---
Author: hubicka
Date: Fri Mar 27 06:58:59 2015
New Revision: 221720
URL: https://gcc.gnu.org/viewcvs?rev=221720&root=gcc&view=rev
Log:
PR lto/65536
* lto-streamer.h (class lto_location_cache): New.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #48 from Jan Hubicka ---
I run memory statistics with the cache and my patch. I will run stats with
cache w/o the libcpp patch tomorrow. I would like to get this problem solved,
but perhaps we want to only track down the reason for w
||2015-03-27
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jan Hubicka ---
Mine, will look into it tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65588
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=65595
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Fri Mar 27 10:33:17 2015
New Revision: 221726
URL: https://gcc.gnu.org/viewcvs?rev=221726&root=gcc&view=rev
Log:
PR middle-end/65595
* cgraph.c (cgraph_update_edges_for_call_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65595
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65588
--- Comment #5 from Jan Hubicka ---
The reduced testcase does not reproduce for me. The original source does. We
do insert undefined register variables into symbol table (not sure how much
sense it makes, but lets not change it now).
The probl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65600
--- Comment #3 from Jan Hubicka ---
Author: hubicka
Date: Fri Mar 27 15:13:54 2015
New Revision: 221735
URL: https://gcc.gnu.org/viewcvs?rev=221735&root=gcc&view=rev
Log:
PR ipa/65600
* cgraph.c (cgraph_update_edges_for_call_stmt_node):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65600
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531
--- Comment #4 from Jan Hubicka ---
Author: hubicka
Date: Fri Mar 27 15:19:35 2015
New Revision: 221736
URL: https://gcc.gnu.org/viewcvs?rev=221736&root=gcc&view=rev
Log:
PR target/65531
* symtab.c (symtab_node::verify_symtab_nodes): Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #53 from Jan Hubicka ---
> You can get an estimate of how much memory would be required to stream in/out
> directly the line_table by summing up the memory reported by
> dump_line_table_statistics for each TU before streaming out (p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65588
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Fri Mar 27 21:35:51 2015
New Revision: 221745
URL: https://gcc.gnu.org/viewcvs?rev=221745&root=gcc&view=rev
Log:
PR ipa/65588
* symtab.c (symtab_node::get_partitioning_class): Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65588
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #27 from Jan Hubicka ---
Unfortunately from me it wend down from about 18% to 15%, so still a
regression. One quantiative parameter I can measure is increase of number of
functions in the resulting binary from 1030 to 1140. I will try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #13 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #14 from Jan Hubicka ---
Author: hubicka
Date: Sun Mar 29 15:38:52 2015
New Revision: 221763
URL: https://gcc.gnu.org/viewcvs?rev=221763&root=gcc&view=rev
Log:
PR ipa/65478
* params.def (PARAM_IPA_CP_RECURSION_PENALTY) : New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65588
--- Comment #10 from Jan Hubicka ---
Author: hubicka
Date: Sun Mar 29 15:41:55 2015
New Revision: 221764
URL: https://gcc.gnu.org/viewcvs?rev=221764&root=gcc&view=rev
Log:
PR ipa/65588
* gcc.target/i386/pr65588.c: New testcase.
Added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #15 from Jan Hubicka ---
The inline bump needed is about 23. Richard, i guess convincing early
optimizers to turn that hack into shifts (that is done by GCC but only at RTL
time), is out of reach for this release, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #29 from Jan Hubicka ---
I also tested with -Os and compile times seems about same as for 4.9 modulo
noise.
The following one liner brings instruction and function count in final binary
to same as in 4.9:
Index: ipa-inline.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #30 from Jan Hubicka ---
Author: hubicka
Date: Mon Mar 30 02:00:56 2015
New Revision: 221769
URL: https://gcc.gnu.org/viewcvs?rev=221769&root=gcc&view=rev
Log:
PR ipa/65076
* ipa-inline.c (edge_badness): Base denominator on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61635
Jan Hubicka changed:
What|Removed |Added
Target Milestone|--- |5.0
--- Comment #8 from Jan Hubicka ---
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860
--- Comment #10 from Jan Hubicka ---
I filled in binutils PR for extension of plugin API
https://sourceware.org/bugzilla/show_bug.cgi?id=18178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65610
--- Comment #6 from Jan Hubicka ---
i guess it is remove_unused_scope_block_p who remove the blocks. I guess
we want to consider blocks as live when BLOCK_ABSTRACT_ORIGIN is function decl,
it is DECL_CXX_CONSTRUCTOR or DESTURCTOR and moreover it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61635
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676
Jan Hubicka changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
||2015-03-30
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Jan Hubicka ---
Patch posted https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01526.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #19 from Jan Hubicka ---
Actually at second thought, would BIT_FIELD_REF allow us to
avoid the actual memory store? I tought like COMPONENT_REF it takes address as
parameter. What I am hoping is to fully optimize out union doub x; at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #40 from Jan Hubicka ---
-O3 graph http://gcc.opensuse.org/c++bench/tramp3d/split-build.html seems to
show 3 bigger increases recently. Can we get the revisions for those?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #41 from Jan Hubicka ---
OK. I can actually look it up in raw files.
It is: 69s->80s between
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64190
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #42 from Jan Hubicka ---
Sorry, accidental message.
It is 69->80.5s between 141127.61083 and 150113.26056 (tester was down)
66->69s between 141123.15275 and 141124.01653
60->64 between 140807.80282 and 140808.66762
Now t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #43 from Jan Hubicka ---
Markus, can you reproduce some consistent growth in -ftime-report for one of
passes? Given that code size difference is solved (please try to double check
that, we may have slightly different revisions of tram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
--- Comment #16 from Jan Hubicka ---
Yep, it seems the problem is triggered on and off with random changed in the
inliner's decisions...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540
--- Comment #10 from Jan Hubicka ---
OK, this patch extends the calls.c hack:
Index: calls.c
===
--- calls.c (revision 221805)
+++ calls.c (working copy)
@@ -1321,6 +1321,15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #49 from Jan Hubicka ---
I did some experiments about the increase of early inlining insns:
- Early optimizers of both 4.9 and mainline process 9819 functions.
- At release_ssa time, the statement count is 8%
- at ipa-cp, we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #52 from Jan Hubicka ---
$ time /aux/hubicka/trunk-install/bin/g++ -Ofast -fpermissive --param
large-function-insns=1 tramp3d-v4.ii -w ; ./a.out -n 3
real0m34.232s
user0m33.729s
sys 0m0.532s
i = 1t = 0.00209225 dt =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #53 from Jan Hubicka ---
This patch makes denominator to use resulting function size (not uninlined time
like 4.9 did but getting the resulting fraction closer to 4.9 style):
Index: ../../gcc/ipa-inline.c
=
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #4 from Jan Hubicka ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581
--- Comment #11 from Jan Hubicka ---
Thanks!
The resolution file is wrong:
1
test.o 1
172 795d441a PREEMPTED_REG main
the resolution of main() should be PREVAILING_DEF_IRONLY. PREEMTED_REG is
defined as follows:
PREEMPTED_REG (this definition wa
||2015-04-02
CC||hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jan Hubicka ---
I will take a look, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540
--- Comment #11 from Jan Hubicka ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-04/msg3.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65581
--- Comment #13 from Jan Hubicka ---
Rainer,
the compiled code (test.s) is identical to what LTO path produces, so I am
convinced this is a bug at binutils side. Would you please mind filling up the
PR?
There are two issues at least - first is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #54 from Jan Hubicka ---
I have full set of firefox talos benchmarks with inline-unit-growth bumped back
to 30 (I did not test default value by accident, but I am running itnow). We
now get back the GCC 4.9 performance on dromaeo_dom/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65655
--- Comment #5 from Jan Hubicka ---
Hmm it is interesting case, we try to resolve speculation while we are
duplicating it. I am testing the following
Index: ipa-inline-analysis.c
==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660
--- Comment #6 from Jan Hubicka ---
Performance seems to be back at Apr 2
Apr 2, 2015 16:20 UTC
(Values: Base: 164.gzip: 1562, 175.vpr: 2384, 176.gcc: 2873, 181.mcf: 3743,
186.crafty: 2922, 197.parser: 2002, 252.eon: 4144, 255.vortex: 3345, 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660
--- Comment #7 from Jan Hubicka ---
32bit runs still shows regression between
Feb 10, 2015 17:03 UTC
(Values: Base: 164.gzip: 1478, 176.gcc: 3065, 181.mcf: 5127, 186.crafty:
2013, 197.parser: 2057, 252.eon: 2604, 255.vortex: 3062, 256.bzip2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #55 from Jan Hubicka ---
Author: hubicka
Date: Fri Apr 3 18:09:13 2015
New Revision: 221859
URL: https://gcc.gnu.org/viewcvs?rev=221859&root=gcc&view=rev
Log:
PR ipa/65076
* ipa-inline.c (edge_badness): Add combined size to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65655
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65655
--- Comment #6 from Jan Hubicka ---
Author: hubicka
Date: Fri Apr 3 18:19:53 2015
New Revision: 221860
URL: https://gcc.gnu.org/viewcvs?rev=221860&root=gcc&view=rev
Log:
PR ipa/65655
* ipa-inline-analysis.c (edge_set_predicate): Do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654
--- Comment #2 from Jan Hubicka ---
OK, it reproduces for me. The size difference is 2
Caller size is:
Inline summary for set_laplace_on_hex_vector/158341 inlinable
self time: 1602
global time: 1602
self size: 43
global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654
--- Comment #3 from Jan Hubicka ---
I am testing the following:
Index: ipa-inline-transform.c
===
--- ipa-inline-transform.c (revision 221859)
+++ ipa-inline-transform.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648
--- Comment #3 from Jan Hubicka ---
Author: hubicka
Date: Fri Apr 3 20:25:01 2015
New Revision: 221861
URL: https://gcc.gnu.org/viewcvs?rev=221861&root=gcc&view=rev
Log:
PR ipa/65648
* ipa-inline-transform.c (inline_call): Skip sanity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65654
Jan Hubicka changed:
What|Removed |Added
Target Milestone|5.0 |6.0
Summary|[5 Regression] 447.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #25 from Jan Hubicka ---
Crafty perfomrance is back (with a combination of better heuristics and
increase of inlining limits), eon is not, at least not in all configurations.
We have separate eon PR, so I am closing this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540
--- Comment #12 from Jan Hubicka ---
Author: hubicka
Date: Tue Apr 7 21:02:12 2015
New Revision: 221910
URL: https://gcc.gnu.org/viewcvs?rev=221910&root=gcc&view=rev
Log:
PR ipa/65540
* calls.c (initialize_argument_information): When p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65540
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65690
--- Comment #1 from Jan Hubicka ---
We are constructing:
(gdb) p debug_tree (t)
unit size
align 64 symtab 0 alias set -1 canonical type 0x76b02a80
precision 64
pointer_to_this >
BLK
size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65690
--- Comment #2 from Jan Hubicka ---
I see, C++ has special code for building qualified array types.
I would say that build_cplus_array_type should have a path where it is building
a variant and go via build_distinct_type_copy only adjusting the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65690
--- Comment #3 from Jan Hubicka ---
Created attachment 35248
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35248&action=edit
Patch I am testing.
Someting like this may work. I think we only want to change element type. I
also noticed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65690
--- Comment #4 from Jan Hubicka ---
This is better version of the patch that at least seems to survive early stages
of bootstrap ;)
Index: tree.c
===
--- tree.c (revision 221909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65690
--- Comment #5 from Jan Hubicka ---
Jason,
I think I need a help on this one. I am not able to get canonical types right
in all cases.
Also I added the following sanity check that seems to trigger in the testuiste
Index: ../../gcc/stor-layout.c
=
1601 - 1700 of 3603 matches
Mail list logo
