http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
Jeffrey A. Law <law at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at redhat dot com, | |richard.guenther at gmail dot com --- Comment #24 from Jeffrey A. Law <law at redhat dot com> --- This is a mess. As noted in the other comments, we're considering a cc0-setter as a potentially trapping insn. As a result the cc0-setter and cc0-consumer end up in different blocks. That's bad on so many levels and "fixing" it by hacking up fold_rtx like this just papers over the fundamental problem (though I must admit from a pragmatic standpoint, it's pretty effective). One could argue that the CFG building code could be tweaked so that a cc0-setter is never considered the end of a block. The downside of that is we're lying to the compiler about the true nature of the CFG. But that little white lie may be acceptable. I haven't looked into how ugly that would be to implement. One could also argue that this is an inherent flaw in cc0 targets and that any unconverted backend should be converted to deprecated. There are certainly better mechanisms for dealing with condition codes than the old cc0 nonsense. But I have neither the time nor the interest in converting the m68k backend. If we went this route it's a good bet the m68k backend would be deprecated. In the end I'm at a loss about the best direction to take. Adding Richi on cc for his thoughts.