Great job! - I just tried this PR on my M4 and it works fine in executing the same code that failed for #521

Unix builds are failing import tests! I'll look at it.

Now travis is happy. I had to remove a different alloca() that I had changed to an array. It went out of scope and was destroyed, but the data was needed later. alloca() storage lives until the function returns, so that was wrong in this case.

Original alloca() changed to an array still stands, to fix the bug.

I repeated the tests from #521 and this PR still works fine. Thanks.
Do yo have any idea why this cropped up when it did. Was there some change that triggered it or was it just a latent issue and we got lucky?

I did some further testing on this and found that the problem arose when the double-tap stuff was added to the loader map. There's no bug with this:

/* top end of the stack */
_estack = ORIGIN(RAM) + LENGTH(RAM);

The bug appears when _estack is moved down one word to make room for the double-tap check word:

/* top end of the stack */
_estack = ORIGIN(RAM) + LENGTH(RAM) - 4;
_bootloader_dbl_tap = _estack;

I actually just adjusted _estack by -4 and it caused the problem, even without introducing the rest of the double-tap code.

Then I changed it to -8 to make it double-word aligned and the bug disappears again.

_estack = ORIGIN(RAM) + LENGTH(RAM) - 8;

@tannewt: I'll check in with you about this.

So - does this imply that there is really no issue with "alloca"? It is just a memory alignment issue?

@jerryneedell I don't know yet. I have something else to do for a while and then will come back to this. It could be that alloca() assumes certain alignment, which isn't true, and the array decl doesn't make that assumption. The generated code does not differ between the working and non-working versions.