http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49357
Summary: [4.7 Regression] register allocation worse Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf Compare the prologue for the test-case in attachment 24471 to PR49154 and compiled according to those instructions, <http://gcc.gnu.org/bugzilla/attachment.cgi?id=24471> between 4.3.3 (everything before the first "add"): subq 4,$sp move $srp,[$sp] subq 12,$sp movem $r2,[$sp] move.d $r10,$r2 move.d $r10,$r9 move.d $r11,$r10 to that of trunk at r174114 as well as r174870: subq 4,$sp move $srp,[$sp] subq 16,$sp movem $r3,[$sp] subq 4,$sp move.d $r8,[$sp] move.d $r10,$r8 move.d $r11,$r9 So, we have a regression from 3 to 5 registers, and with a hole compared to reg_alloc_order. Note that the source uses DFmode and DImode and derived unions; at a glance "normal" code is less affected. Building on a 32-bit host seems to aggravate the situation. Just put here as a note for the time being.