[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.