[Bug target/59363] [4.9 Regression] r203886 miscompiles git

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #21 from Michael Zolotukhin --- Thanks, HJ! That seems to be the root cause of the fail. Did I get it right, that you are testing a patch fixing the issue? Similar issue could be in expand_movmem_epilogue, I'll take a look.

[Bug target/59363] [4.9 Regression] r203886 miscompiles git

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59363 --- Comment #6 from Michael Zolotukhin --- I wasn't able to reproduce the problem, though I got the same asm-files as you showed. However, the both asms look correct to me, and equivalent to each other. Could the problem be in function xdi_diff

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624 --- Comment #4 from Michael Zolotukhin 2013-03-15 12:27:51 UTC --- Sorry, it looks like the reproducer with if could be made, and here it is: void foo (long *a) { int i; for (i = 0; i < 100; i+=2) { if (a[i] == 0)

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624 --- Comment #3 from Michael Zolotukhin 2013-03-15 12:26:46 UTC --- Created attachment 29674 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29674 Reproducer 2

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624 --- Comment #2 from Michael Zolotukhin 2013-03-15 12:19:50 UTC --- > Can you reproduce a testcase for that instead? It doesn't make sense > to handle code that should be optimized earlier (by DSE). Is it from > code like > > if (cond

[Bug tree-optimization/56625] New: After if-conversion vectorizer doesn't recognize similar stores

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56625 Bug #: 56625 Summary: After if-conversion vectorizer doesn't recognize similar stores Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCON

[Bug tree-optimization/56624] New: Vectorizer gives up on a group-access if it contains stores to the same location

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624 Bug #: 56624 Summary: Vectorizer gives up on a group-access if it contains stores to the same location Classification: Unclassified Product: gcc Version: 4.8.0

[Bug tree-optimization/54240] Routine hoist_adjacent_loads does not work properly after r189366

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240 --- Comment #3 from William J. Schmidt 2012-08-13 14:14:59 UTC --- Odd, I don't know. I'll have to go back and look at the tests when I get a moment and investigate that. Peculiar. --- Comment #4 from Michael Zolotukhin 2012-08-13 14:15:08 U

[Bug tree-optimization/54241] Routine hoist_adjacent_loads does not work properly after r189366

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54241 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693 --- Comment #6 from Michael Zolotukhin 2011-12-28 16:19:54 UTC --- (In reply to comment #5) > > In vect-peel-3.c we actually assume that vector length is 16 byte. Here is > > the > > loop body: > > suma += ia[i]; > > sumb += ib[i+5];

[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693 --- Comment #4 from Michael Zolotukhin 2011-12-28 13:01:51 UTC --- (In reply to comment #2) > > I though that if {vect_aligned_arrays} isn't true, than arrays could > > be aligned even after peeling - that's why I added such check. > > Sorry, I

[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693 --- Comment #3 from Michael Zolotukhin 2011-12-28 12:59:24 UTC --- Created attachment 26195 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26195 AVX2 vect dump

[Bug testsuite/51693] New XPASSes in vectorizer testsuite on powerpc64-suse-linux

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51693 --- Comment #1 from Michael Zolotukhin 2011-12-28 11:08:36 UTC --- I though that if {vect_aligned_arrays} isn't true, than arrays could be aligned even after peeling - that's why I added such check. Unfortunately, I can't reproduce these fails, a

[Bug middle-end/51508] New: Test vect.exp/fast-math-mgrid-resid.f fails when compiled with -mavx2.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51508 Bug #: 51508 Summary: Test vect.exp/fast-math-mgrid-resid.f fails when compiled with -mavx2. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIR

[Bug target/51387] Test vect.exp/vect-116.c fails on execution when compiled with -mavx2 on sde.

||gmail dot com --- Comment #1 from Michael Zolotukhin 2011-12-02 05:53:25 UTC --- I added prints to the test and saw that the result was incorrectly permuted (bytes 8-15 and 16-23 should be swapped): i C[i] correct C[i] 000 1

[Bug target/51387] New: Test vect.exp/vect-116.c fails on execution when compiled with -mavx2 on sde.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51387 Bug #: 51387 Summary: Test vect.exp/vect-116.c fails on execution when compiled with -mavx2 on sde. Classification: Unclassified Product: gcc Version: 4.7.0 Status: U

[Bug target/51134] [4.7 Regression] x86 memset/memcpy expansion is broken

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 --- Comment #12 from Michael Zolotukhin 2011-11-22 16:54:35 UTC --- > Do you have a patch for those C++ and Java regressions? What regressions do you mean exactly? I managed to fix the bootstraps (with sse_loop enabled again), but there are stil

[Bug target/51134] [4.7 Regression] x86 memset/memcpy expansion is broken

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51134 --- Comment #10 from Michael Zolotukhin 2011-11-22 13:17:38 UTC --- Created attachment 25882 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25882 Patch for new memset/memcpy implementation (In reply to comment #9) > Regressions caused by th

[Bug tree-optimization/50188] Optimizer doesn't take into account, that longjmp could lead to loops, which causes illegal code transformations.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50188 --- Comment #4 from Michael Zolotukhin 2011-08-25 20:21:10 UTC --- If I understand standard correctly, in this case behavior isn't undefined. Am I right? If so, then if behavior of optimized code (loop is infinite) is correct, behavior of not opt

[Bug tree-optimization/50188] New: Optimizer doesn't take into account, that longjmp could lead to loops, which causes illegal code transformations.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50188 Bug #: 50188 Summary: Optimizer doesn't take into account, that longjmp could lead to loops, which causes illegal code transformations. Classification: Unclassified Prod

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 --- Comment #8 from Michael Zolotukhin 2011-06-23 16:03:32 UTC --- (In reply to comment #6) > (In reply to comment #4) > > Created attachment 24584 [details] > > Test showing that cleanup-* tests are not quite correct. > > Wrong test. You don't

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 --- Comment #7 from Michael Zolotukhin 2011-06-23 16:00:36 UTC --- Created attachment 24587 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24587 Fixed cleanup-regression.c

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 --- Comment #5 from Michael Zolotukhin 2011-06-23 11:44:17 UTC --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > (In reply to comment #0) > > > > > > > > As _L_mutex_lock is a function, GCC generates a pr

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 --- Comment #4 from Michael Zolotukhin 2011-06-23 11:42:03 UTC --- Created attachment 24584 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24584 Test showing that cleanup-* tests are not quite correct.

[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 --- Comment #2 from Michael Zolotukhin 2011-06-22 17:50:34 UTC --- (In reply to comment #1) > (In reply to comment #0) > > > > As _L_mutex_lock is a function, GCC generates a prologue and epilogue for > > it - > > in prologue stack alignment is

[Bug testsuite/49503] New: Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 Summary: Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c Product: gcc Version: 4.7.0 S