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]

Re: [testcase] optimization/5076: gcc3 regression: yet another strength reduction bug


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]