Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Created attachment 47543
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47543&action=edit
preprocessed benchmark wit
onent: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When generating the internal makefile in lto-wrapper we need to avoid or escape
characters in filenames which are special for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #3 from Jan Hubicka ---
Created attachment 47546
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47546&action=edit
preprocessed benchmark
I am attaching preprocessed source. I used -O3 -march=native
-fno-prefetch-loops-arrays (
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Created attachment 47553
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47553&action=edit
unreduced testcase
$ ./xgcc -B ./ -O2 ~/aa.ii
In file included from ../../
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93079
--- Comment #1 from Jan Hubicka ---
We rewrite VAR_DECL to invalid tree code by gimple_set_plf
(gdb) p ((tree)0x7fffeccfba20).base.code
$22 = VAR_DECL
(gdb) c
Continuing.
Hardware watchpoint 1: *$13
Old value = 17039395
New value = 17041443
gim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93079
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
--- Comment #7 from Jan Hubicka ---
This patch fixes the testcase, but I am not familiar enough with the code to
say if that is correct fix :)
Index: ../../gcc/cp/cp-gimplify.c
===
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
I get infinite loop in
(gdb) bt
#0 0x012b0e4e in values_equal_for_ipcp_p (y=0x7fffaf8496c0,
x=0x7fffafc26e80) at ../../gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
Jan Hubicka changed:
What|Removed |Added
CC||fxue at os dot
amperecomputing.com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #5 from Jan Hubicka ---
Created attachment 47563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47563&action=edit
fixed testcase
I have verified that building with
g++ -O3 -march=bdver1 -fno-prefetch-loop-arrays ~/stepanov_ve
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
jan@skylake:~> more t.c
#define def(name) struct name {int name;} name;
#define d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115
--- Comment #4 from Jan Hubicka ---
The problem here is that we produce ipa-cp clone to devirtualize v::av which
also lead to devirtualization of m::av, but we miss this optimization. After
inlining we remove m::av and while producing the ipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93115
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #5 from
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
This is testcase by Mark Williams who also bisected it
template class b {
struct c {
a h;
constexpr c() {}
~c() {}
} d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93169
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
In the testcase (reduced from folly by Mark Williams):
typedef int a;
template struct d { static constexpr b e = c; };
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
--- Comment #16 from Jan Hubicka ---
OK, i get an ICE because type is not compatible with its main variant. the two
types are:
constant 384>
unit-size constant 48>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
--- Comment #17 from Jan Hubicka ---
Created attachment 47651
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47651&action=edit
proposed patch
This is patch I plan to test which fixes the last testcase. It adds warning
about TREE_ADDRESSAB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
--- Comment #18 from Jan Hubicka ---
OK, other testcases does not reproduce for me. However if they do it seems like
fallout from the change dropping type checking from call statements.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92240
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92749
--- Comment #2 from Jan Hubicka ---
This is intentional, we got less aggressive at inlining inline functions for
-O2 (since we do not need to do all inlining we want for -O3 when we have
independent set of attributes).
Indeed -Winline -Werror is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93144
--- Comment #5 from Jan Hubicka ---
Well, the problem was debug info getting bigger due to more inlining? I guss in
that case we could close it. That patch is expected to allow more inlines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358
--- Comment #19 from Jan Hubicka ---
I think backporting would be a good idea :) If you beat me on it even better.
Now I need to set up my trees in git...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92600
--- Comment #6 from Jan Hubicka ---
Well, because the source files differs, the comdat group differs and the
loosing one has fewer symbols in it. So we end up keeping some symbols from
the other comdat group that happens to have same name. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91576
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
hubicka@lomikamen-jh:~$ cat t2.c
#include
union test {int a; float b;};
__attribute__ ((noinline)) union test set()
{
union test r;
r.a = 0x7f842335;
return r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
--- Comment #2 from Jan Hubicka ---
Fails at least for gcc 4.9+, but it must be regression compared to pre-tree-ssa
GCCs (which I don't have installed :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
Jan Hubicka changed:
What|Removed |Added
Keywords|wrong-code |
Target|i?86-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
--- Comment #5 from Jan Hubicka ---
Also I think it is violation of C++ memory model since we introduce load+store
pair where there was none before?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92077
--- Comment #4 from Jan Hubicka ---
We have --param comdat-sharing-probablity which says that average comdat
function has only 20% chance to be shared with another copy of same comdat in
other unit. This was introduced because of Firefox develope
: dmalcolm at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Bootstrapping with LTO complains about ODR issues in analyzer
../../gcc/analyzer/region-model.h:792: warning: type ‘struct region’ violates
the C++ One Definition Rule [-Wodr]
792 | class region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599
--- Comment #5 from Jan Hubicka ---
I also get similar ICE building Firefox
[task 2020-01-17T20:36:04.213Z] 20:36:04 INFO -
../../gcc-source/gcc/ipa-inline-transform.c:722
[task 2020-01-17T20:36:04.213Z] 20:36:04 INFO - 0x9d8315
exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599
--- Comment #6 from Jan Hubicka ---
I guess the problem is that the code expect lto-stmt-uid and call_stmt to be in
sync. This is not true. If call statements are around lto stmt uids are not
maintained.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92599
Jan Hubicka changed:
What|Removed |Added
Summary|ICE in |[8/9 regression] ICE in
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Firefox build now crashes with:
36:24.63 0x7756505f ???
36:24.63
/build/glibc-77giwP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93318
--- Comment #1 from Jan Hubicka ---
So it seems the problem is the following:
Program received signal SIGSEGV, Segmentation fault.
0x00a1ff0e in cgraph_edge::speculative_call_info (this=0x76e26bc8,
direct=@0x7fffd700: 0x90c070 <_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92816
--- Comment #2 from Jan Hubicka ---
It does not reproduce for me on bdver1 and also it does not seem to reproduce
at skylake (with generic tuning)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?highlight_run=8405&plot.70=227.70.0
So we need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93318
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93318
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #10 from Jan Hubicka ---
Concerning:
> Honza, the type_has_components_p check in
>
> if (compare_type_sizes (TREE_TYPE (ref2), type1) >= 0
> && (!end_struct_ref1
> || compare_type_sizes (TREE_TYPE (ref2),
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93345
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mliska at suse dot cz
--- Comment #
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
We have __gcov_topn_values_profiler and __gcov_topn_values_profiler_atomic
but only no
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
I am looking into this for a while, but lets create a tracking bug to record
some info on the problem.
-O2 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93404
--- Comment #1 from Jan Hubicka ---
Created attachment 47701
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47701&action=edit
inliner size stats parser
It took me a while to find some reasonable way to analyze code size regressions
caused
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
While analyzing GCC for PR93404 I noticed that gen_rtx_fmt_ee
34 rtx
35 gen_rtx_fmt_ee (code, mode, arg0, arg1)
36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #10 from Jan Hubicka ---
-fvpt still has no effect on Firefox
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=20725e2c319ad69128f075248bc41a0e97029437&newProject=try&newRevision=8a26cb77fed6ccc67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #12 from Jan Hubicka ---
This is stat for Firefox with current mainline.
== Stats for firefox2019-trunktest ==
stats for indirect_call:
total: 160451
invalid: 542
tracked values:
0 values: 134367 times (83.74%)
1 val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #14 from Jan Hubicka ---
> This seems reasonable well, 542/(21514+3151+866+11) = 2%.
I think one needs to consider only calls that was trained and have at least two
possible targets. With this metric it is more like 542/(3151+866+11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #15 from Jan Hubicka ---
This is frequency scaled by #of executions:
== Stats for /aux/hubicka/firefox2019-trunktest ==
stats for indirect_call:
total: 160451
invalid: 542 (0.34%) freq:276193364 (33.87%)
tracked values:
0 v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #17 from Jan Hubicka ---
I further hacked the script to record only values that are useful, where useful
means with greater count then all / TOPN_VALUES / 2. I use same test in GCC
itself (that was bug in original luxou's patch that
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Filename length limit for ext4 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93214
Jan Hubicka changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Jan Hubicka -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384
--- Comment #24 from Jan Hubicka ---
Reading through the PR I understand it as follows
1) we create localalias for a symbol
2) ipa-pure-const founds that the function is noreturn.
Here seems to be a bug, since it does
TREE_THIS_VOLATI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #19 from Jan Hubicka ---
Seems that the multi-target speculation fallout is now fixed and also indirect
call profiling works similarly as to gcc9 now if the reproducibility logic is
disabled.
I re-benchmarked Firefox. Reproducible m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #20 from Jan Hubicka ---
And thanks for the gcov-analysis improvemnets. It is quite handy tool now :)
and it is interesting to know where the many-target calls are. Clearly there is
not much to win on walk_tree, but I guess it all dep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #23 from Jan Hubicka ---
This is stat for clang build with current mainline. half of invalidated
counters is pretty high (as expected given large number of runs merged)
== Stats for instrumented-gcc-new/ ==
stats for indirect_call:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #24 from Jan Hubicka ---
You can get gcda files from the treeherder links
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/GacHgozaSRWbybgeUGzHVQ/runs/0/artifacts/public/build/profdata.tar.xz
https://firefox-ci-tc.services
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92924
--- Comment #25 from Jan Hubicka ---
I wonder if that is because of parallel updates. There is quite a lot of time
between prunning and streaming out. If Firefox forks while other threads are
running, it will mess up the streamed data quite badly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
--- Comment #3 from Jan Hubicka ---
Just to summarize discussions we had. I think we need to think through setup
where there are different build, train and pgo-buid machines and the
directories are not known in advance.
There -ffile-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
--- Comment #4 from Jan Hubicka ---
Actually passing phony / is not needed. We could do right thing with
gcc foo.c -o /ibb1/foo.o -fprofile-prefix-map==
-fprofile-generate
or
gcc foo.c -o /ibb1/foo.o -fprofile-strip-prefix=
-fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
--- Comment #7 from Jan Hubicka ---
do you have example how the relative paths can be used?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93401
--- Comment #9 from Jan Hubicka ---
This only work because the directory does not change from build time to train
time. The paths are not relative instead absolute path is put into every .o
file at compile time.
jan@skylake:~> gcc -fprofile-gene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #12 from Jan Hubicka ---
Created attachment 47898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47898&action=edit
possible fix
After some discussion with Richard it is my understanding now that FRE is
considering two stores eq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93586
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90869
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Jan Hubicka ---
N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #14 from Jan Hubicka ---
Created attachment 47901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47901&action=edit
another related testcase
> But that means we now miscompile the later two tests.
Good point, those are my testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
--- Comment #15 from Jan Hubicka ---
The following testcase:
union U { long long i; long f; };
struct a {union U u;};
struct aa {struct a a;};
struct b {union U u;};
struct bb {struct b b;};
long
foo (struct bb *bv, void *ptr)
{
struct aa *a =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92152
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789
--- Comment #7 from Jan Hubicka 2013-02-05
09:13:59 UTC ---
Author: hubicka
Date: Tue Feb 5 09:13:48 2013
New Revision: 195751
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195751
Log:
PR tree-optimization/55789
* g+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789
--- Comment #8 from Jan Hubicka 2013-02-05
15:24:03 UTC ---
Author: hubicka
Date: Tue Feb 5 15:23:56 2013
New Revision: 195758
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195758
Log:
PR tree-optimization/55789
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049
--- Comment #5 from Jan Hubicka 2013-02-11
22:55:44 UTC ---
Well, I think we should try to toamn fantasy of our optimizers here. What
unroller sees at -O3 -fno-tree-vectorize is quite ugly:
:
a = {};
:
# i_1 = PHI <1(2), i_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #9 from Jan Hubicka 2013-02-20
15:47:32 UTC ---
Author: hubicka
Date: Wed Feb 20 15:47:21 2013
New Revision: 196177
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196177
Log:
PR tree-optimization/56265
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53884
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Jan
||2013-03-01
CC||hubicka at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #32 from Jan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312
--- Comment #4 from Jan Hubicka 2013-03-02
17:50:06 UTC ---
I see, it looks like a bug when computing the boundary then; if folding is
possible through the constructor, the symtab node ought to be shipped into the
partition.
|unassigned at gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
--- Comment #4 from Jan Hubicka 2013-03-07
19:59:57 UTC ---
mine..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557
--- Comment #9 from Jan Hubicka 2013-03-11
18:10:57 UTC ---
I am testing the following that should prevent references from external vtables
to land in LTO symbol table.
Index: lto-streamer-out.c
=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557
--- Comment #11 from Jan Hubicka 2013-03-12
00:58:48 UTC ---
BTW, one thing i do not understand is why the construction vtables are not
static when they can not be used across .o boundary?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56571
--- Comment #5 from Jan Hubicka 2013-03-12
12:13:44 UTC ---
Author: hubicka
Date: Tue Mar 12 12:13:33 2013
New Revision: 196612
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196612
Log:
PR middle-end/56571
* valtrack.
||hubicka at gcc dot gnu.org
Resolution||FIXED
--- Comment #6 from Jan Hubicka 2013-03-12
12:15:16 UTC ---
Fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557
--- Comment #13 from Jan Hubicka 2013-03-12
12:38:54 UTC ---
Author: hubicka
Date: Tue Mar 12 12:38:47 2013
New Revision: 196613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196613
Log:
PR lto/56557
* lto-streamer-ou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557
Jan Hubicka changed:
What|Removed |Added
Component|libstdc++ |lto
--- Comment #14 from Jan Hubi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557
--- Comment #15 from Jan Hubicka 2013-03-12
13:00:11 UTC ---
Filled in binutils PR http://sourceware.org/bugzilla/show_bug.cgi?id=15270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312
--- Comment #5 from Jan Hubicka 2013-03-12
13:03:36 UTC ---
Sadly this problem does not reproduce to me (though I use -fno-fat-lto-objects
that makes the build quite a bit faster). Can you please upload for me the
files produced by --save
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278
--- Comment #2 from Jan Hubicka 2013-03-25
11:03:36 UTC ---
Yep, Botan tends to be very random, see our benchmarks. I looked into some of
the loops and they are very tight written in a bit particular way, so a lot of
performance changes a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55102
--- Comment #3 from Jan Hubicka 2013-03-27
12:47:04 UTC ---
Doing IPA analysis at -O0 for LTO streaming won't really solve the fact that
functions are not early optimized. I would vote for at least issuing a waning
when LTOing -O0 objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56714
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56714
--- Comment #3 from Jan Hubicka 2013-03-31
20:08:22 UTC ---
I guess it is really complaining about the lack of inline modifier.
__attribute__((__always_inline__)) bool
atomic_flag_test_and_set_explicit(atomic_flag* __a,
memory
||2013-04-03
CC||hubicka at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
||2013-04-03
CC||hubicka at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
|unassigned at gcc dot |hubicka at gcc dot gnu.org
|gnu.org |
--- Comment #10 from Jan Hubicka 2013-04-08
15:22:21 UTC ---
Mine.
101 - 200 of 3550 matches
Mail list logo
