[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201 Jeffrey A. Law changed: What|Removed |Added Status|SUSPENDED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #16 from Jeffrey A. Law --- Fixed on trunk.
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201 --- Comment #15 from Mikael Pettersson mikpe at it dot uu.se 2011-02-28 12:04:32 UTC --- (In reply to comment #14) I'll try Kazu's patch in my next 4.4 bootstrap/regtest. Kazu's patch appears to have been for a 4.2 code base. I forward-ported it to 4.4.5, where it fixed the test case in a cross compiler, but unfortunately broke native bootstrap: gengtype-lex.c: In function 'yy_get_next_buffer': gengtype-lex.c:1663: warning: old-style function definition gengtype-lex.c: In function 'yy_get_previous_state': gengtype-lex.c:1795: warning: old-style function definition gengtype-lex.c: In function 'yylex': gengtype-lex.c:1652: error: unrecognizable insn: (insn 2783 2782 1738 243 gengtype-lex.c:1784 (set (mem:QI (reg:SI 1 %d1 [orig:121 yy_n_chars.68 ] [121]) [0 S1 A8]) (const_int 0 [0x0])) -1 (nil)) gengtype-lex.c:1652: internal compiler error: in extract_insn, at recog.c:2048 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [build/gengtype-lex.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir44/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir44' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir44' make: *** [bootstrap] Error 2
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #14 from Mikael Pettersson mikpe at it dot uu.se 2011-02-26 11:35:50 UTC --- (In reply to comment #13) Also fine, not closed. Great to see that you pay enough attention to stop the reporter from closing his own PRs. I wish you would be just as fast with actually doing something about them. It is not even clear whether these problems still exist! The missed optimization still occurs with gcc-4.6, which generates: f: move.l 4(%sp),%a0 move.l (%a0),%a1 move.l 4(%a0),%d0 clr.b (%a1,%d0.l) rts .size f, .-f .ident GCC: (GNU) 4.6.0 20110219 (experimental) I'll try Kazu's patch in my next 4.4 bootstrap/regtest.
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2011-02-25 23:12:26 UTC --- No response from m68k maintainers for almost 2.5 years. This just clutters my bug searches. WONTFIX seems the most logical way out.
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|RESOLVED|NEW Resolution|WONTFIX | --- Comment #12 from Andreas Schwab sch...@linux-m68k.org 2011-02-25 23:58:09 UTC --- Not a reason to close them.
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #13 from Steven Bosscher steven at gcc dot gnu.org 2011-02-26 00:17:54 UTC --- Also fine, not closed. Great to see that you pay enough attention to stop the reporter from closing his own PRs. I wish you would be just as fast with actually doing something about them. It is not even clear whether these problems still exist! If this still not OK with you, I suggest you do something about these 15+ years old problems, or close these and re-file under your own account. They may not bother you but I don't want them anymore in my list.
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #10 from steven at gcc dot gnu dot org 2010-02-12 22:01 --- Waiting for a m68k maintainer to do something here... -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #9 from steven at gcc dot gnu dot org 2008-09-21 13:21 --- Andreas, could you adopt the patch of comment #4 and see if it still fixes this bug? -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kazu at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-03 02:05 --- This should not have been in waiting as it was waiting on a developer response and not the reporter. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2006-02-26 19:52:26 |2008-09-03 02:05:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #7 from steven at gcc dot gnu dot org 2007-12-17 08:12 --- Kazu, plans with this bug, and your patch for it? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #6 from kazu at gcc dot gnu dot org 2005-11-22 17:42 --- Andreas, Thanks for spotting the typo. I also updated the patch to ensure that we are giving an address register indirect to clr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #5 from schwab at suse dot de 2005-11-21 23:07 --- The comment in the patch has a typo: clr.b (%a0) should be clr.b (%a1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #3 from kazu at gcc dot gnu dot org 2005-11-19 21:52 --- FWIW, the mainline gcc with -O2 -fomit-frame-pointer produces f: move.l 4(%sp),%a0 move.l (%a0),%a1 move.l 4(%a0),%a0 clr.b (%a0,%a1.l) rts -- kazu at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Comment #4 from kazu at gcc dot gnu dot org 2005-11-20 00:22 --- Created an attachment (id=10299) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10299action=view) Patch With this patch, I get: f: move.l 4(%sp),%a0 move.l (%a0),%a1 add.l 4(%a0),%a1 clr.b (%a1) rts -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Additional Comments From schwab at suse dot de 2004-12-31 13:32 ---
Test case (see also
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01109.html):
struct X {
char *a;
/* other members */
int b;
};
void f (struct X *x)
{
x-a[x-b] = 0;
}
--
What|Removed |Added
CC||schwab at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
[Bug target/19201] [m68k] Inefficient code for array accesses (from old PROBLEMS)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31 14:58 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet||m68k-*-* Last reconfirmed|-00-00 00:00:00 |2004-12-31 14:58:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19201
