[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #13 from Linus Torvalds 2011-05-29 18:56:44 UTC --- Thanks guys.

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #11 from Jakub Jelinek 2011-05-29 18:51:51 UTC --- Author: jakub Date: Sun May 29 18:51:48 2011 New Revision: 174413 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174413 Log: PR rtl-optimization/49095 * config/i386/pr

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #10 from Linus Torvalds 2011-05-27 16:48:52 UTC --- (In reply to comment #9) > > 32-bit before32-bit after64-bit before64-bit after > libstdc++.so.60x717080x716e80x67ee60x67ec6 > libgcj

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #9 from Jakub Jelinek 2011-05-27 16:33:33 UTC --- .text sizes before/after the patch (in each case on identical sources, for cc1plus I've reverted the patch afterwards and did make -j64 cc1plus in gcc/ subdir), the size changes aren't

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #8 from Linus Torvalds 2011-05-27 15:32:21 UTC --- (In reply to comment #7) > > BTW, the patch bootstrapped/regtested on both x86_64-linux and i686-linux, I'm > just running second set of bootstrap without the patch to be able to comp

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #7 from Jakub Jelinek 2011-05-27 14:47:08 UTC --- (In reply to comment #6) > Jakub - the patch looks sane, although I don't currently have a gcc build > environment to actually test it with, and there is no way I'm going to claim > th

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #6 from Linus Torvalds 2011-05-27 14:15:25 UTC --- Jakub - the patch looks sane, although I don't currently have a gcc build environment to actually test it with, and there is no way I'm going to claim that I follow all the matches an

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 Jakub Jelinek changed: What|Removed |Added Attachment #24366|0 |1 is obsolete|

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #3 from Linus Torvalds 2011-05-21 20:42:26 UTC --- Hmm. Looking at that code generation, it strikes me that even with the odd load store situation, why do we have that "test" instruction? c:8b 10mov(%ea

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 --- Comment #2 from Linus Torvalds 2011-05-21 18:41:15 UTC --- (In reply to comment #1) > > On the RTL side combine tries to do > > Trying 7, 8 -> 9: > Failed to match this instruction: > (parallel [ > (set (mem/f:DI (reg/v/f:DI 63 [ arg

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49095 Richard Guenther changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Statu