------- Comment #15 from mikpe at it dot uu dot se 2010-05-26 12:44 ------- Created an attachment (id=20749) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20749&action=view) proposed 4.6 fix for PR38644
PR38644 and its dupes are very similar to PowerPC PR44199 and PR30282. PR44199 was recently fixed by conditionally emitting stack ties in epilogues. I first intended to simply clone that approach for Thumb1, but it turns out there's already a conditional barrier in thumb1_expand_epilogue (). So for now I simply extended that condition to also trigger whenever there's stack pointer adjustment in the epilogue. I've confirmed that this fixes the test cases in PR38644, PR42155, and PR44091. I know that Richard Earnshaw has stated that he considers this a middle-end rather than a back-end bug, and I agree with that. However, given that this wrong-code bug has been known for so long with no middle-end fix in sight, I think solving it in the back-end is appropriate for now, at least for 4.4/4.5. The current patch is a little too heavy in that it also blocks non memory accesses from being scheduled past the stack pointer adjustment -- I saw an example of that in the large PR44091 test case. Using a stack tie instead of a full barrier should hopefully fix that. So far only tested with 4.4/4.5/4.6 crosses to armv5tel-unknown-linux-gnueabi. I'll try this in a 4.5 native bootstrap soonish (4.6 bootstraps are currently broken on ARM, see PR44255). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
