https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #6 from Jeffrey A. Law law at gcc dot gnu.org ---
Author: law
Date: Mon Jan 12 20:19:57 2015
New Revision: 219488
URL: https://gcc.gnu.org/viewcvs?rev=219488root=gccview=rev
Log:
PR target/64461
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #8 from Joel Sherrill joel at gcc dot gnu.org ---
Thanks. I didn't build all our Coldfire BSPs but I checked one and it is OK
now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #5 from Joel Sherrill joel at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #4)
The easiest fix is to disable the three trunc patterns for the coldfire.
This isn't my area of expertise. That's why I focused in on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #1 from Joel Sherrill joel at gcc dot gnu.org ---
Doing a git bisect showed this to be the commit that broke things. Clearly not
m68k specific but triggered it.
commit 91ae0791cbebaac673e42e53c8b7f000241a0ca1
Author: dj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #2 from Joel Sherrill joel at gcc dot gnu.org ---
Multiple BSPs trigger this on various files which is not a surprise seeing as
it is generating an illegal memory to memory move. But in case it helps, this
is the list of CPU CFLAGS of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #3 from Andreas Schwab sch...@linux-m68k.org ---
It is using truncsiqi2, but that pattern hasn't been adjusted for coldfire.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461
--- Comment #4 from Andreas Schwab sch...@linux-m68k.org ---
The easiest fix is to disable the three trunc patterns for the coldfire.
