http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584
--- Comment #15 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- (In reply to Richard Biener from comment #14) > Ok, but it's not clear to me what the bug is and why it's not a target bug > fixed by your changes. Ok, I'll try to explain my point without putting time I don't have into this: the CRIS subtarget I'm most interested in now, requires that the stack-pointer is valid at all times. For this target, the fix I committed is enough to cover the issue with no conceivable way to have such an insn validly split. For another target, either maybe a completely different port, but there actually *is* another CRIS subtarget, such a define_split makes sense: the stack-pointer used at interrupts is different to the "user" stack-pointer (another register). For that subtarget the fix is (very very minor) suboptimal cover-up in the absense of the other commits. The actual commits here *may* have made the case where the tweaked define_split would previously match impossible, or they *may* have just made the issue latent. The case here is where the stack-pointer is *set* (not just incremented or decremented) from a variable, and IIRC that instruction sequence is very unlikely except when __builtin_stack_restore is used, and nobody would use that, so almost never (as I recall my analysis then and yes I considered exceptions). See also <http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01847.html>, the patch message. Thus, I'm fine with closing this for the regressions but not exactly for the issue in comment #5 for which the bug was opened; "the combination of expr.c:find_args_size_adjust and expr.c:fixup_args_size_notes can't handle a define_split matching for the stack-adjustment assignment instruction emitted by __builtin_stack_restore". (In other words, a person investigating such an issue in the future, would not be helped by searching the bugzilla and finding this PR with the previous title as closed.)
