struct S { unsigned int s; }; struct T { struct S t[2]; unsigned int u : 1; }; void foo (int x, int y, int z) { int i; struct T t; t.u = t.u; for (i = 0; i < x; i++) if (z != 1) t.t[i].s = y || t.u; }
Seems to be caused by a failure to simplify (if_then_else (ne (zero_extract:SI (const_int 0 [0x0]) (const_int 1 [0x1]) (const_int 0 [0x0])) (const_int 0 [0x0])) (label_ref 71) (pc)))
(This is gcc.c-torture/compile/20071128-1.c).
GCC 4.5.0 is being released. Deferring to 4.5.1.
GCC 4.5.1 is being released, adjusting target milestone.
GCC 4.5.2 is being released, adjusting target milestone.
GCC 4.5.3 is being released, adjusting target milestone.
GCC 4.6.4 has been released and the branch has been closed.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
First note the testcase is rather bogus. Modern compilers collapse foo() down into a simple return as DCE doesn't find any statements within foo() which affect state outside of foo. Testing was thus done with "t" being an extern. The code we generate on the trunk for the v850 is marginally better than what we generated prior to the cond-optab merge (smaller by a single move insn) The code we generate on the mn103 is slightly better as well. It uses fewer registers (and as a result has less memory traffic to save/restore registers), and generates smaller code. The avr code looks considerably better, though my familiarity with that architecture is minimal. It appears to use fewer registers and is considerably smaller. I haven't done bisection to see what fixed the reported regressions, nor do I plan to. While this might have been a regression in 4.8 and 4.9, I don't think anyone bothered to check and I can't see anyone bothering to do so in the future or backport the fix if it were identified. Thus I'm closing as resolved. If anyone objects, feel free to reopen.