This is related primarily to PR49864 but also to PR49879. The fundamental problem in the first test case is that the AVR target cannot perform (set (stack-pointer-rtx) (plus (stack-pointer-rtx) (const_int large))) where "large" is in fact really quite small. This gets dutifully reloaded to (set (reg temp) (stack-pointer-rtx)) (set (reg temp) (plus (reg temp) (const_int large))) (set (stack-pointer-rtx) (reg temp)) which, we have to admit, is perfectly reasonable. The code that we had in stack_adjust_offset would not properly handle anything except immediate addends to the stack pointer. Indeed, if it saw any other sort of stack pointer adjustment, it gave up and assumed that we'd reset the args_size level to 0. This exact problem hasn't shown up on other targets either (1) because they ACCUMULATE_OUTGOING_ARGS, or (2) while they may not be able to handle very large addends to the stack pointer, we usually don't let the pushed arguments grow to very large numbers; we regularly reduce stack_pointer_delta. AVR is special in that it can't *really* perform any direct addition to the stack pointer at all; "large" is non-zero only because of a peephole pattern to use pop insns into a scratch register for small adjustments. I briefly considered adding an insn pattern that would handle the entire mov/add/mov thing with a scratch, so that we wouldn't have to do anything special. It seemed relatively unlikely that any other port would be this severely limited. However, then came a look at the second PR, where we performed cross-jumping between two blocks with different args_size values. For the specific case of the PR, this "merely" resulted in wrong-debug, because we would in fact generate invalid unwind info for one of the two paths. That said, I see no reason why this same cross-jump could not occur with a real throw as opposed to an abort. And in that case we would have wrong-code. I consulted the IRC oracle, and Ian didn't have any objections in principal to a new reg-note. Comments? r~