This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wednesday 02 January 2002 20:31, Gwenole Beauchesne wrote: > On 11 Dec 2001 gbeauchesne@mandrakesoft.com wrote: > > The attached test case is extracted/reduced from PR 2847 that was > > closed earlier. gcc3 series compilers are affected, unlike gcc-2.95.X. > > (gcc-"2.96" is affected too). > > Here is another testcase exhibing a strength reduction bug occurring with > FSF gcc 3.0.3 and binutils 2.11.92.0.12-2mdk (based on RH 2.11.92.0.12-8) > on i586-mandrake-linux-gnu. Also occurs with gcc 3.0.3 on IA-64 and with > mainline gcc (3.1 20020102) on IA-32. This is a regression from gcc > 2.95.X. > > Testcase is derived from PR optimization/5076 and PR optimization/2847. > > 2002-01-02 Gwenole Beauchesne <gbeauchesne@mandrakesoft.com> > > PR optimization/5076, PR optimization/2847 > * gcc.c-torture/execute/loop-10.c: New test. > > --- gcc/testsuite/gcc.c-torture/execute/loop-10.c.strength-reduce > Wed Jan 2 18:55:53 2002 > +++ gcc/testsuite/gcc.c-torture/execute/loop-10.c Wed Jan 2 > 18:54:03 2002 > @@ -0,0 +1,31 @@ > +/* Reduced from PR optimization/5076, PR optimization/2847 */ > + > +static int count = 0; > + > +static void > +inc (void) > +{ > + count++; > +} > + > +int > +main (void) > +{ > + int iNbr = 1; > + int test = 0; > + while (test == 0) > + { > + inc (); > + if (iNbr == 0) > + break; > + else > + { > + inc (); > + iNbr--; > + } > + test = 1; > + } > + if (count != 2) > + abort (); > + return 0; > +} Actually strength reduction is innocent here, the real culprit is the overly simplistic loop unrolling code if the iteration count equals 1. It goes wrong when the insns between loop->start and loop->cont influence the exit condition of the loop. Since we are in bugfix mode right now (and I think a rewrite based on CFG is pending), I'm suggesting the attached bandaid fix for 3.1 and gcc-3_0-branch. Correctly handling this would require to move the insns between loop->start and loop->cont after loop->sink, then use invert_jump to redirect the exit jump behind the moved insns. Franz. * unroll.c (unroll_loop): Don't try to unroll loops with a NOTE_INSN_LOOP_CONT. (ujump_to_loop_cont): Delete.
Attachment:
gcc3-noloopcontunroll.patch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |