||2018-08-23
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jan Hubicka ---
We use files for tlink use which IMO is never executed when we do plugin
enabled LTO link. I think we can just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Thu Aug 30 15:50:39 2018
New Revision: 263988
URL: https://gcc.gnu.org/viewcvs?rev=263988&root=gcc&view=rev
Log:
PR lto/86517
* lto-opts.c (lto_write_options): Always st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #2 from Jan Hubicka ---
Indeed, having -fdump-tree-vect-details-blocks dump would probably make it easy
to figure out what happens.
What is configuration tripplet and exact invocation line for the test?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
--- Comment #3 from Jan Hubicka ---
backtracing with GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
works for me, but it takes 20GB and 5 minutes to print a backtrace:
(gdb) bt
#0 0x77bc915f in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87455
--- Comment #4 from Jan Hubicka ---
We already have TARGET_SSE_TYPELESS_STORES for stores, so perhaps we want
something like typeless reg-reg moves and loads flag?
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665
--- Comment #14 from Jan Hubicka ---
Author: hubicka
Date: Mon Feb 12 09:48:06 2018
New Revision: 257582
URL: https://gcc.gnu.org/viewcvs?rev=257582&root=gcc&view=rev
Log:
PR middle-end/83665
* params.def (inline-min-speedup): I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016
--- Comment #12 from Jan Hubicka ---
I can confirm that gamess is fixed. In addition tonto's regression from earlier
cost tuning was fixed as well. There is nice improvement to galgel
(15400->15800) which is not fixing earlier regression and apsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
--- Comment #4 from Jan Hubicka ---
For reference, this is open implementation from Jessie version of glibc that
trigeers the issue
__fortify_function int
open (const char *__path, int __o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
--- Comment #5 from Jan Hubicka ---
Author: hubicka
Date: Wed Feb 21 19:05:30 2018
New Revision: 257877
URL: https://gcc.gnu.org/viewcvs?rev=257877&root=gcc&view=rev
Log:
PR c/84229
* ipa-cp.c (determine_versionability): Do not v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
--- Comment #7 from Jan Hubicka ---
I am not sure it is really fixed. We no longer ICE, howeverw we need
backporting to release branches and also I think we miss fortification whenever
we fail to inline (that is with -Os). I have some patches to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84058
--- Comment #6 from Jan Hubicka ---
I would not call it P1 - it is relatively minor code quality issue, but i will
look into it next week.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71991
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #5 from Jan Hubicka ---
Will take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84058
--- Comment #7 from Jan Hubicka ---
Created attachment 43876
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43876&action=edit
Patch I am testing
Turns out that those are mostly artifacts of the fact that basically all of
cfg-cleanup has be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078
--- Comment #6 from Jan Hubicka ---
The problem is that we build type inheritance graph earlier and at that time
there are still virtual functions in the callgraph that are optimized out
before free-lang-data. Their types however remain in ODR h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #1 from Jan Hubicka ---
Pat, can you try to figure out what value of min-speedup is neeed to recover
from this regression?
It woul be nice to know what is the particular inline decision causing trouble
and what are the esitmated benef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #1 from Jan Hubicka ---
Would be possible to analyze this a bit? The patch does have effect on
optimizers because we produce a lot fewer MEM_REFs on type mismatches. Of
course this should not trigger wrong code but it also may be som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #5 from Jan Hubicka ---
I think this is caused by misoptimizing
void **x;
void *info ATTRIBUTE_UNUSED;
{
cselib_val *v = (cselib_val *)*x;
struct elt_loc_list **p = &v->locs;
int had_locs = v->locs != 0;
while (*p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #9 from Jan Hubicka ---
Created attachment 44946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44946&action=edit
reproducer
I am attaching the preprocessed file and will be away till 2pm.
What seems to be wrong is that we opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87706
--- Comment #2 from Jan Hubicka ---
cow is already dead at profile time (if it would not, we would end up using the
counter). It seems to me that one remove unreachable code pass is missing.
We used to remove unreachable code after early optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87885
--- Comment #2 from Jan Hubicka ---
The patch makes sense to me. I am not sure why it was run after pass but before
cleanups originally... Seems like a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87830
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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: ---
In GCC 9 we started to stream abstract origin everywhere. Disabling abstract
oririgin improves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86004
--- Comment #9 from Jan Hubicka ---
I wonder if we can close this based on fact that it only reproduces on
sufficiently old binutils and we simply can't support incremental linking on
these?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988
--- Comment #3 from Jan Hubicka ---
Thanks, I will give it a try. Note that the numbers I posted are from trunk
and trunk with abstract origin streaming disabled. Thanks to the type
streaming reorg we do not have overall regression relative to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88010
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #14 from Jan Hubicka ---
I will take a look. These decisions are bit fragile because inliner typically
does not know what of the two inline decisions is more profitable and one
excludes the other.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #3 from Jan Hubicka ---
Author: hubicka
Date: Sat Nov 17 11:35:01 2018
New Revision: 266235
URL: https://gcc.gnu.org/viewcvs?rev=266235&root=gcc&view=rev
Log:
PR ipa/87957
* ipa-devirt.c (warn_odr): Look for main vari
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #7 from Jan Hubicka ---
Author: hubicka
Date: Mon Nov 19 23:27:10 2018
New Revision: 266289
URL: https://gcc.gnu.org/viewcvs?rev=266289&root=gcc&view=rev
Log:
PR lto/87957
* ipa-devirt.c (free_enum_values): Do not IC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87706
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Tue Nov 20 13:25:04 2018
New Revision: 266315
URL: https://gcc.gnu.org/viewcvs?rev=266315&root=gcc&view=rev
Log:
PR ipa/87706
* ipa-fnsummary.c (pass_ipa_fnsummary): Do n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87997
--- Comment #1 from Jan Hubicka ---
Author: hubicka
Date: Tue Nov 20 14:09:27 2018
New Revision: 266316
URL: https://gcc.gnu.org/viewcvs?rev=266316&root=gcc&view=rev
Log:
PR lto/87997
* tree.c (free_lang_data_in_cgraph): Add arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87706
--- Comment #10 from Jan Hubicka ---
Author: hubicka
Date: Tue Nov 20 15:58:37 2018
New Revision: 266320
URL: https://gcc.gnu.org/viewcvs?rev=266320&root=gcc&view=rev
Log:
PR ipa/87706
* ipa-fnsummary.c (pass_ipa_fnsummary): Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Tue Nov 20 16:22:19 2018
New Revision: 266322
URL: https://gcc.gnu.org/viewcvs?rev=266322&root=gcc&view=rev
Log:
PR lto/87957
* ipa-devirt.c (odr_subtypes_equivalent_p):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044
--- Comment #11 from Jan Hubicka ---
Warning from #9 is caused by fact that I compare pointers rather than test for
equality so when the enums are not merged, they triggers the warning even if
the values are in fact equivalent.
The following sile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044
--- Comment #12 from Jan Hubicka ---
Actually the issue here is that enum is context that is the type B and it has
keyed vtable which makes it unmerged. So we are correct to not merge here
provided that we want to keep TYPE_CONTEXT here (which I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044
--- Comment #13 from Jan Hubicka ---
... and I can also confirm that the original testcase no longer triggers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044
--- Comment #14 from Jan Hubicka ---
Author: hubicka
Date: Wed Nov 21 02:38:43 2018
New Revision: 266334
URL: https://gcc.gnu.org/viewcvs?rev=266334&root=gcc&view=rev
Log:
PR lto/84044
* ipa-devirt.c (odr_types_equivalent_p): Us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #9 from Jan Hubicka ---
Author: hubicka
Date: Wed Nov 21 17:31:19 2018
New Revision: 266350
URL: https://gcc.gnu.org/viewcvs?rev=266350&root=gcc&view=rev
Log:
PR lto/87957
* tree.c (fld_decl_context): Break out from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
--- Comment #10 from Jan Hubicka ---
Author: hubicka
Date: Wed Nov 21 17:32:19 2018
New Revision: 266351
URL: https://gcc.gnu.org/viewcvs?rev=266351&root=gcc&view=rev
Log:
PR lto/87957
* g++.dg/lto/odr-1_0.C: Extend by mismatche
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147
--- Comment #1 from Jan Hubicka ---
Hmm, this looks like another overfow in line map - my understanding is that the
assert checks that correct line number is added. I am not quite line_map
expert :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147
--- Comment #3 from Jan Hubicka ---
If it is simply location overflow it likely won't reduce into something simple
:(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140
--- Comment #1 from Jan Hubicka ---
Ok, we die testing:
3199 if (!useless_type_conversion_p (TREE_TYPE (expr),
3200 TREE_TYPE (TREE_OPERAND
(expr, 1
where expr is:
pub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140
--- Comment #2 from Jan Hubicka ---
I am testing:
Index: tree-cfg.c
===
--- tree-cfg.c (revision 266382)
+++ tree-cfg.c (working copy)
@@ -3196,8 +3196,8 @@ verify_types_in_gimple_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88142
--- Comment #1 from Jan Hubicka ---
Author: hubicka
Date: Thu Nov 22 23:10:57 2018
New Revision: 266396
URL: https://gcc.gnu.org/viewcvs?rev=266396&root=gcc&view=rev
Log:
PR lto/88142
* ipa-devirt.c (type_variants_equivalent_p):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88142
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87754
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|hubicka at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88185
--- Comment #2 from Jan Hubicka ---
Yes, this should be fixed on mainline (would be great to double-check that
systemd builds with it). I guess we could backport this to gcc 8?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88181
--- Comment #4 from Jan Hubicka ---
It is possible that the verifier is just overzelaous here, but it seems it
really does not make sense to have packed variant of nonpacked structure and
vice versa because the memory layout is different. So i wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988
--- Comment #7 from Jan Hubicka ---
Hi,
ltrans files are 1374K without and 1339K with patch.
WPA report without patch:
[WPA] read 13690507 SCCs of average size 1.397311
[WPA] 19129895 tree bodies read in total
[WPA] tree SCC table: size 4194301,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87988
--- Comment #9 from Jan Hubicka ---
We still have:
/* When not generating debug info we can eliminate info on unused
variables. */
else if (!flag_auto_profile &&
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
We output quite few warnings "warning: iteration 9223372036854775807 invokes
undefined behavior" while building Fi
erity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
$ cat test.c
int (*ptr)(void);
static
int test2(void)
{
}
test()
{
test3();
ptr();
}
$ cat test2.c
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88279
--- Comment #1 from Jan Hubicka ---
GNU ld (GNU Binutils for Debian) 2.28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2
: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Currently __gcov_indirect_call_profiler_v2 consumes about 3% of execution of
lto1 with -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297
--- Comment #4 from Jan Hubicka ---
Originally we maintained things safe by having the global counter and not using
same suffixes (i.e. constprop/wpa etc.) during early, wpa and late
optimization, so things did not conflict.
I wonder how the con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #36 from Jan Hubicka 2012-11-11
18:14:40 UTC ---
Author: hubicka
Date: Sun Nov 11 18:14:35 2012
New Revision: 193406
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193406
Log:
PR middle-end/48636
* ipa-in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55229
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55238
--- Comment #5 from Jan Hubicka 2012-11-11
19:35:31 UTC ---
Author: hubicka
Date: Sun Nov 11 19:35:27 2012
New Revision: 193410
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193410
Log:
PR tree-optimization/55238
* ip
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278
Bug #: 55278
Summary: Botan performance regressions apparently due to LRA
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: norma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55283
Bug #: 55283
Summary: EON performance regression at -O2 due to loop
unrolling changes
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55283
--- Comment #1 from Jan Hubicka 2012-11-12
10:44:14 UTC ---
http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-head-64/252_eon_big.png
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55285
Bug #: 55285
Summary: Botan regression on ia-64 at Mar-2012
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #37 from Jan Hubicka 2012-11-12
12:16:18 UTC ---
Fatigue now gets all inlining with -O3 -fwhole-program, with -O3 it gets only
half of inlining because jump functions are not able to track array descriptors
in both calls to gen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
Jan Hubicka changed:
What|Removed |Added
Summary|[4.8 regression] false |[4.8 regression] false
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346
--- Comment #22 from Jan Hubicka 2012-11-14
22:38:19 UTC ---
OK, similar loop in C looks like:
float a[1];
float b[1];
t()
{
int mi = 0,i;
for (i=0;i<1000;i++)
if (a[i]")))
(set (pc) (if_then_else
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #9 from Jan Hubicka 2012-11-14
23:03:27 UTC ---
Author: hubicka
Date: Wed Nov 14 23:03:22 2012
New Revision: 193512
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193512
Log:
PR bootstrap/55051
* ipa-inli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #39 from Jan Hubicka 2012-11-14
23:22:40 UTC ---
Hmm, indeed. Good catch. I will look into it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
Jan Hubicka changed:
What|Removed |Added
CC||tejohnson at google dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55079
--- Comment #9 from Jan Hubicka 2012-11-15
01:01:30 UTC ---
This is reduced testcase from gcov.c
int a[8];
int
t (void)
{
int ix = 0;
int k;
int b = 0;
int curr = 0;
for (k = 0; k < 2; k++)
{
b = ix * 32;
curr = a[ix++]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #13 from Jan Hubicka 2012-11-15
01:03:09 UTC ---
OK, the false positive is on quite sloppy code in gcov-io.c. I attached
testcase to PR55079 and will fix the gcc_assert specifying the loop bounds to
not allow out-of-bound read.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #14 from Jan Hubicka 2012-11-15
01:07:04 UTC ---
Author: hubicka
Date: Thu Nov 15 01:07:01 2012
New Revision: 193522
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193522
Log:
PR bootstrap/55051
* gcov-io.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #15 from Jan Hubicka 2012-11-15
01:10:29 UTC ---
Note that profiledbootstrap still dies for me on
config.status: creating tests/rand/Makefile
../../libiberty/cp-demangle.c: In function 'd_print_cast.isra.8':
../../libiberty/cp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #16 from Jan Hubicka 2012-11-15
01:17:43 UTC ---
Theresa: I am using gcc10 from compilation farm, but I think it is fairly
universal problem.
Also I think that gcc_assert should not be assert, but an user readable error
about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
Bug #: 55334
Summary: mgrid regression (ipa-cp disables vectorization)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #41 from Jan Hubicka 2012-11-15
02:28:26 UTC ---
mgrid regression is now PR55334
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717
--- Comment #15 from Jan Hubicka 2012-11-15
10:27:49 UTC ---
Path posted at http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01222.html
Can we figure out why the vectorization still does not happen?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717
--- Comment #16 from Jan Hubicka 2012-11-15
10:52:13 UTC ---
OK, 4.7 vectorize two loops in the function in cptrf2
loop at ../a.f90:3538
if (nxtr < 4) then
kerr = 1
do ixtr = 1, nxtr - 1
ixtrt (ixt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #2 from Jan Hubicka 2012-11-15
11:07:10 UTC ---
I think the problem is that we somehow make MEM_REF to be base...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55329
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717
--- Comment #18 from Jan Hubicka 2012-11-16
10:37:30 UTC ---
Author: hubicka
Date: Fri Nov 16 10:37:25 2012
New Revision: 193553
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193553
Log:
PR tree-optimization/54717
* t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
Jan Hubicka changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #7 from Jan Hubicka 2012-11-16
13:19:51 UTC ---
The C testcase is simiar - in the mgrid case we are probably able to derrive
useful loop bounds now and the dependency analysis could use them (but
doesn't). I will try to look in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
Jan Hubicka changed:
What|Removed |Added
CC||pthaugen at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55078
--- Comment #7 from Jan Hubicka 2012-11-16
17:32:50 UTC ---
Martin, any news here?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #27 from Jan Hubicka 2012-11-16
17:42:26 UTC ---
/* Now merge each file. */
for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr->next)
{
// Open existing gcda file for gi_ptr
// Find program summary corr
||hubicka at gcc dot gnu.org
Resolution|FIXED |
--- Comment #32 from Jan Hubicka 2012-11-16
17:50:28 UTC ---
Would be possible to double check if this problem is still fixed after the fix
to the tree-ssa-pre patch? I do not see any cold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
--- Comment #33 from Jan Hubicka 2012-11-16
18:00:54 UTC ---
And at -O3 the testcase does not look really good indeed
:
# cstore_51 = PHI <0(5), 2147483647(6)>
# prephitmp_82 = PHI <1073741823(5), 3221225470(6)>
# prephitmp_83 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #35 from Jan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
Jan Hubicka changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Co
1101 - 1200 of 3603 matches
Mail list logo
