https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #26 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #25)
> Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> you just remove a nop.
Here is a test which crashes LRA with the path you proposed. Crash happe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
--- Comment #8 from Ilya Enkovich ---
(In reply to amker from comment #7)
> According to discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg00190.html,
> hook is probably not wanted in this case.
> Bernd gave another proposal by moving combine b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052
--- Comment #10 from Ilya Enkovich ---
(In reply to amker from comment #9)
> I know little about x86, is it because of generation of non-canonical rtl
> expression after this change?
>
> Another question for this case is: Is it because operand o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #32 from Ilya Enkovich ---
(In reply to Uroš Bizjak from comment #31)
> Maybe we can use HJ's patch from Comment #27 and communicate converted_insns
> flag from convert_scalars_to_vector to ix86_finalize_stack_realign_flags?
> The i_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69519
--- Comment #1 from Ilya Enkovich ---
Here is a code before RA:
5: r87:DI=[`a']
14: r92:DI=[`b']
8: r91:DI#0=r87:DI#0^r92:DI#0
REG_UNUSED flags:CC
9: [`a']=r91:DI
REG_DEAD r91:DI
10: call [`fn2'] argc:0
REG_CA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #37 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #36)
> (In reply to Richard Biener from comment #35)
> > I wonder why LRA cannot spill using unaligned moves?
>
> We keep track precise alignment requirement. RA will use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68030
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69519
--- Comment #3 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #2)
> Can we use (subreg:DI (reg:V2DI)) to force xmm?
I'm not sure this actually forces XMM. Also note that STV allows the same DI
reg to be used in both converted and not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68542
--- Comment #8 from Ilya Enkovich ---
Author: ienkovich
Date: Tue Feb 2 09:46:26 2016
New Revision: 233068
URL: https://gcc.gnu.org/viewcvs?rev=233068&root=gcc&view=rev
Log:
gcc/
2016-02-02 Yuri Rumyantsev
PR middle-end/68542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369
--- Comment #4 from Ilya Enkovich ---
(In reply to Jan Hubicka from comment #2)
> I will take a look. It works in my tree with changes to avoid use of
> IDENTIFIER_TRANSPARENT_ALIAS.
r232560 doesn't seem to fix any known problem in trunk. Can w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69648
--- Comment #7 from Ilya Enkovich ---
(In reply to Uroš Bizjak from comment #6)
> (In reply to Bernd Schmidt from comment #5)
> > Yeah, my current theory is that r87 is spilled at the start, then the spill
> > reg is inherited in all the existing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #14 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #6)
> STV turns:
>
> insn 21 19 23 4 (parallel [
> (set (reg:DI 102 [ val ])
> (and:DI (reg/v:DI 97 [ val ])
> (mem/u:DI (pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #15 from Ilya Enkovich ---
(In reply to Jakub Jelinek from comment #13)
> Fixed.
I think you just hide LRA issue disabling STV and LRA still may generate
incorrect register fill
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
The problem appears for code generated by STV pass. This code uses paradoxical
subregs which may cause spill/fill mismatch.
>cat test.i
extern const unsigned int a[];
ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #17 from Ilya Enkovich ---
(In reply to Uroš Bizjak from comment #16)
> That doesn't mean that incorrect register fill RA bug should't be fixed
> during stage-4. Do we have a small testcase that exposes it?
I submitted PR69693 for RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
--- Comment #1 from Ilya Enkovich ---
We should be able to revert r233167 if this issue is fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369
Ilya Enkovich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369
--- Comment #6 from Ilya Enkovich ---
Author: ienkovich
Date: Fri Feb 5 14:41:00 2016
New Revision: 233177
URL: https://gcc.gnu.org/viewcvs?rev=233177&root=gcc&view=rev
Log:
gcc/
2016-02-05 Ilya Enkovich
PR target/69369
Rev
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
Here is a test which fails when compiled with both LTO and CHKP enabled:
>cat test.i
class cl1
{
public:
virtual ~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69729
--- Comment #1 from Ilya Enkovich ---
Here is a patch which caused the regression:
diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 0cefc15..6bb76cc 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -2320,7 +2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
--- Comment #8 from Ilya Enkovich ---
Author: ienkovich
Date: Wed Feb 10 15:22:17 2016
New Revision: 233275
URL: https://gcc.gnu.org/viewcvs?rev=233275&root=gcc&view=rev
Log:
gcc/
2016-02-10 Yuri Rumyantsev
PR tree-optimization/6965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69729
--- Comment #3 from Ilya Enkovich ---
(In reply to Jan Hubicka from comment #2)
> Yes, the patch is meant to disbale streaming of instrumentation thunks, so
> we do not output two function bodies for one assembler name into LTO files.
> Can we po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69729
--- Comment #4 from Ilya Enkovich ---
Well, using thunk.add_pointer_bounds_args to determine intrumentation thunks in
this condition works fine for me. Let's change the condition then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69729
--- Comment #5 from Ilya Enkovich ---
Author: ienkovich
Date: Fri Feb 12 13:17:28 2016
New Revision: 233376
URL: https://gcc.gnu.org/viewcvs?rev=233376&root=gcc&view=rev
Log:
gcc/
PR target/69729
* lto-streamer-out.c (lto_output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69729
Ilya Enkovich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69804
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69956
Ilya Enkovich changed:
What|Removed |Added
CC||ysrumyan at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69956
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
--- Comment #10 from Ilya Enkovich ---
Author: ienkovich
Date: Mon Feb 29 14:32:24 2016
New Revision: 233811
URL: https://gcc.gnu.org/viewcvs?rev=233811&root=gcc&view=rev
Log:
gcc/testsuite/
2016-02-29 Yuri Rumyantsev
PR tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69956
--- Comment #4 from Ilya Enkovich ---
Author: ienkovich
Date: Tue Mar 1 11:17:44 2016
New Revision: 233850
URL: https://gcc.gnu.org/viewcvs?rev=233850&root=gcc&view=rev
Log:
gcc/
PR tree-optimization/69956
* tree-vect-stmts.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69956
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
--- Comment #3 from Ilya Enkovich ---
Here we have bool to int conversion:
g_9 = (long long unsigned int) _8;
which is replaced by a pattern:
patt_49 = _8 ? 1 : 0;
but somehow both original statement and pattern get vectorized and all uses of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
--- Comment #4 from Ilya Enkovich ---
(In reply to Ilya Enkovich from comment #3)
> but somehow both original statement and pattern get vectorized and all uses
> of g_9 use conversion result, not pattern result.
This happens because of bool patt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
--- Comment #5 from Ilya Enkovich ---
Testing this fix:
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index 95ce38d..1812742 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -2084,6 +2084,10 @@ vect_reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70021
--- Comment #7 from Ilya Enkovich ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 37834 [details]
> gcc6-pr70021-wip.patch
>
> But that would mean we don't vectorize the loop.
> I see 2 cases here, one where we look up the d
at gcc dot gnu.org |ienkovich at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70026
Ilya Enkovich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||ienkovich at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #4 from Ilya Enkovich ---
Closing then.
at gcc dot gnu.org |ienkovich at gcc dot
gnu.org
--- Comment #6 from Ilya Enkovich ---
Thanks a lot for your analysis! When chain is built we scan all register
definitions and their uses. Thus it includes all register definitions and
uses. Uninitialized uses are missed though. Simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70160
--- Comment #8 from Ilya Enkovich ---
Author: ienkovich
Date: Fri Mar 11 11:25:29 2016
New Revision: 234135
URL: https://gcc.gnu.org/viewcvs?rev=234135&root=gcc&view=rev
Log:
gcc/
PR target/70160
* config/i386/i386.c (scalar_cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70160
Ilya Enkovich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70252
--- Comment #2 from Ilya Enkovich ---
Seems it is due to incorrect mask conversion. The problem is that both scalar
mask of 4 elements and scalar mask of 8 elements have QImode. It makes us
think that we may get vec(4) using vec_unpack_[lo|hi]_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70290
--- Comment #3 from Ilya Enkovich ---
In build_conditional_expr_1 we check if used condition is a result of another
VEC_COND_EXPR and then may just re-use condition of that VEC_COND_EXPR.
In that case we deal with boolean vector as a condition t
at gcc dot gnu.org |ienkovich at gcc dot
gnu.org
--- Comment #3 from Ilya Enkovich ---
Well, for now we have only two scalar masks sharing the same mode. It means we
may handle them by changing appropriate optabs from direct to conversion type
and having separate entries for QI<->QI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
Ilya Enkovich changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
--- Comment #6 from Ilya Enkovich ---
(In reply to rguent...@suse.de from comment #5)
> I think that would be an odd transform. But yes, The pattern is probably
> dead now and can as well be removed...
This test proves pattern is not dead and s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70252
--- Comment #4 from Ilya Enkovich ---
Author: ienkovich
Date: Fri Mar 18 09:36:32 2016
New Revision: 234323
URL: https://gcc.gnu.org/viewcvs?rev=234323&root=gcc&view=rev
Log:
gcc/
PR tree-optimization/70252
* tree-vect-stmts.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70251
--- Comment #2 from Ilya Enkovich ---
Here is a responsible match.pd pattern:
/* A + (B vcmp C ? 1 : 0) -> A - (B vcmp C), since vector comparisons
return all-1 or all-0 results. */
/* ??? We could instead convert all instances of the vec_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70252
Ilya Enkovich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70314
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70322
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #4 from Ilya Enkovich ---
(In reply to Rainer Orth from comment #3)
> Ilya,
>
> do you have an idea what might be going on here?
>
> Thanks.
> Rainer
test.chkp printed in assembler means we either miss transparent alias chain for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70302
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70322
--- Comment #5 from Ilya Enkovich ---
STV is a scalar to vector converter. It doesn't combine two instructions into
a single ANDN, it searches for existing ANDN patterns and converts them into
vector mode. Combine is responsible for producing A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #6 from Ilya Enkovich ---
I got an access to x86_64-apple-darwin12.5.0. Will try to reproduce there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #8 from Ilya Enkovich ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> > --- Comment #6 from Ilya Enkovich ---
> > I got an access to x86_64-apple-darwin12.5.0. Will try to reproduce there.
>
> There's no point: as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #9 from Ilya Enkovich ---
Looking through Solaris configs I see two places where transparent aliases are
not followed. This patch should fix this. Any help with testing is very
appreciated.
diff --git a/gcc/config/i386/sol2.h b/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70290
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70290
--- Comment #4 from Ilya Enkovich ---
Author: ienkovich
Date: Tue Mar 22 12:31:12 2016
New Revision: 234399
URL: https://gcc.gnu.org/viewcvs?rev=234399&root=gcc&view=rev
Log:
gcc/cp/
PR target/70290
* call.c (build_conditional_e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70354
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321
--- Comment #7 from Ilya Enkovich ---
(In reply to Jakub Jelinek from comment #6)
> Why couldn't STV just "vectorize" AND and NOT patterns and let the combiner
> combine that in the vectorized code?
I think the only thing we miss for that is cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69917
--- Comment #12 from Ilya Enkovich ---
Author: ienkovich
Date: Wed Mar 23 10:55:37 2016
New Revision: 234423
URL: https://gcc.gnu.org/viewcvs?rev=234423&root=gcc&view=rev
Log:
gcc/
PR target/69917
* config/i386/sol2.h (ASM_OUTPU
||2016-03-28
CC||ienkovich at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Ilya Enkovich ---
Confirm.
Looks like combine issue. Before combine:
6: r94:DI=0x14ff6e2207db5d1f
7: {r93:DI=r94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69890
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69890
--- Comment #4 from Ilya Enkovich ---
(In reply to Dominique d'Humieres from comment #3)
> --- ../_clean/gcc/testsuite/gcc.target/i386/chkp-strlen-1.c 2016-01-20
> 19:08:43.0 +0100
> +++ gcc/testsuite/gcc.target/i386/chkp-strlen-1.c
at gcc dot gnu.org |ienkovich at gcc dot
gnu.org
--- Comment #2 from Ilya Enkovich ---
Another undefined register case in STV. Undefined registers were supported in
scalar_chain::convert_op but we don't call it for reg-reg moves. Testing this
patch:
diff --git a/gcc/config/i386/i38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69890
--- Comment #6 from Ilya Enkovich ---
(In reply to Dominique d'Humieres from comment #5)
> Sorry, but I don't understand what should be done to fix the chkp-stropt-*
> tests.
Basically all external dependencies just should be removed. There is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69890
--- Comment #7 from Ilya Enkovich ---
Created attachment 38145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38145&action=edit
patch
Attached patch seems to work OK on Linux and removes all string.h includes from
chkp-str* tests. I belie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70442
--- Comment #3 from Ilya Enkovich ---
Author: ienkovich
Date: Thu Mar 31 15:37:12 2016
New Revision: 234637
URL: https://gcc.gnu.org/viewcvs?rev=234637&root=gcc&view=rev
Log:
gcc/
PR target/70442
* config/i386/i386.c (scalar_cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70442
Ilya Enkovich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69890
--- Comment #9 from Ilya Enkovich ---
Author: ienkovich
Date: Fri Apr 1 10:40:51 2016
New Revision: 234666
URL: https://gcc.gnu.org/viewcvs?rev=234666&root=gcc&view=rev
Log:
gcc/testsuite/
PR target/69890
* gcc.dg/strlenopt.h (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69890
--- Comment #10 from Ilya Enkovich ---
Author: ienkovich
Date: Fri Apr 1 15:31:43 2016
New Revision: 234677
URL: https://gcc.gnu.org/viewcvs?rev=234677&root=gcc&view=rev
Log:
gcc/testsuite/
Backport from mainline r234666.
2016-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69890
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
--- Comment #14 from Ilya Enkovich ---
(In reply to Richard Biener from comment #13)
> (In reply to Yuri Rumyantsev from comment #12)
> > Created attachment 38367 [details]
> > modified patch
>
> The loop->aux flagging looks redundant to me. Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69804
Ilya Enkovich changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #3 f
||ienkovich at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Ilya Enkovich ---
Duplicate
*** This bug has been marked as a duplicate of bug 69804 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70807
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
||2016-05-04
Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot
gnu.org
Ever confirmed|0 |1
||2016-05-04
Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
--- Comment #5 from Ilya Enkovich ---
Author: ienkovich
Date: Fri May 6 12:07:25 2016
New Revision: 235962
URL: https://gcc.gnu.org/viewcvs?rev=235962&root=gcc&view=rev
Log:
gcc/
2016-05-06 Yuri Rumyantsev
PR debug/70935
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
--- Comment #6 from Ilya Enkovich ---
Author: ienkovich
Date: Tue May 10 14:26:37 2016
New Revision: 236081
URL: https://gcc.gnu.org/viewcvs?rev=236081&root=gcc&view=rev
Log:
gcc/
2016-05-10 Yuri Rumyantsev
Backport from mainline r2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70786
--- Comment #8 from Ilya Enkovich ---
Author: ienkovich
Date: Tue May 10 15:56:27 2016
New Revision: 236086
URL: https://gcc.gnu.org/viewcvs?rev=236086&root=gcc&view=rev
Log:
gcc/
PR tree-optimization/70786
* tree-chkp.c (chkp_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70877
--- Comment #1 from Ilya Enkovich ---
Author: ienkovich
Date: Tue May 10 16:06:36 2016
New Revision: 236088
URL: https://gcc.gnu.org/viewcvs?rev=236088&root=gcc&view=rev
Log:
gcc/
PR middle-end/70877
* tree-chkp.c (chkp_add_boun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70799
--- Comment #3 from Ilya Enkovich ---
Author: ienkovich
Date: Tue May 10 16:08:42 2016
New Revision: 236090
URL: https://gcc.gnu.org/viewcvs?rev=236090&root=gcc&view=rev
Log:
gcc/
PR target/70799
* config/i386/i386.c (dimode_sca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70876
--- Comment #1 from Ilya Enkovich ---
Fixed in trunk by r236086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70807
--- Comment #4 from Ilya Enkovich ---
Author: ienkovich
Date: Wed May 11 09:33:13 2016
New Revision: 236114
URL: https://gcc.gnu.org/viewcvs?rev=236114&root=gcc&view=rev
Log:
gcc/
PR middle-end/70807
* cfgrtl.h (delete_insn_and_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70807
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70876
--- Comment #2 from Ilya Enkovich ---
Author: ienkovich
Date: Wed May 11 09:51:49 2016
New Revision: 236115
URL: https://gcc.gnu.org/viewcvs?rev=236115&root=gcc&view=rev
Log:
gcc/
Backport from mainline r236086.
2016-05-10 Ilya
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70877
--- Comment #3 from Ilya Enkovich ---
Author: ienkovich
Date: Wed May 11 09:55:55 2016
New Revision: 236116
URL: https://gcc.gnu.org/viewcvs?rev=236116&root=gcc&view=rev
Log:
gcc/
Backport from mainline r236088.
2016-05-10 Ilya
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70877
Ilya Enkovich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70876
Ilya Enkovich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |ienkovich at gcc dot
gnu.org
--- Comment #2 from Ilya Enkovich ---
Looking at it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71006
--- Comment #4 from Ilya Enkovich ---
(In reply to Chengnian Sun from comment #3)
> Hi,
>
> Can you help check whether the following test case is a duplicate? Thanks.
This is definitely a separate issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70876
--- Comment #5 from Ilya Enkovich ---
(In reply to Vittorio Zecca from comment #4)
> Will you please check gcc 6.1 with your fix against bug 70877?
>
> I get an ICE, could it be a regression?
GCC 6.1 is released and will not be fixed. PR70877
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71006
--- Comment #5 from Ilya Enkovich ---
Author: ienkovich
Date: Thu May 12 11:27:49 2016
New Revision: 236171
URL: https://gcc.gnu.org/viewcvs?rev=236171&root=gcc&view=rev
Log:
gcc/
PR tree-optimization/71006
* tree-vect-loop.c (v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71084
--- Comment #4 from Ilya Enkovich ---
This is still CSE invalidating dominance info. Calls to cleanup_cfg don't
affect cse_cfg_altered. If I replace cfg_cleanup calls with
cse_cfg_altered |= cleanup_cfg (..)
then testcase passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70935
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 408 matches
Mail list logo
