This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/3384: PowerPC -funroll-loops -fbranch-count-reg misoptimization
- To: Zoltan Hidvegi <hzoli at hzoli dot 2y dot net>
- Subject: Re: optimization/3384: PowerPC -funroll-loops -fbranch-count-reg misoptimization
- From: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>
- Date: Sat, 28 Jul 2001 12:05:12 +1200 (NZST)
- Cc: dje at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, hzoli at austin dot ibm dot com, m dot hayes at elec dot canterbury dot ac dot nz, mmitchel at gcc dot gnu dot org, bernds at redhat dot com
- References: <20010720173936.26771.qmail@sourceware.cygnus.com> <E15Nfss-0006lc-00@hzoli.home>
Zoltan Hidvegi writes:
> Thanks for looking at that, but could you please consider the patch in
> http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01080.html in favor of this
> one? This improves a tiny bit on normal non-unrolled loops, and it has
> some comments. Also I forgot to remove some misleanding comments in that
> patch, so I attach below a comment-only patch that should be applied
> after http://gcc.gnu.org/ml/gcc-patches/2001-07/msg01080.html.
The doloop part of this patch is OK.
> Also note that there is still a bug here, that is not new:
>
> main(){unsigned int i; for (i = ~0-39; i < ~0u-1; i += 4);}
> This is an infinite loop, but it quits when compiled with -O2. It would
> be easy to fix for the constant limit case, actually I have some hack for
> that, but for the variable final value case that would require extra
> run-time checks for every loop even if they would never overflow, and the
> standard behavior is undefined anyways, so it probably does not worth
> fixing it (that was that way even in 2.95).
Do you know what the standard says about these type of loops? I could
never envisage a case where this behaviour would be deliberate. When
people want an infinite loop, a non-conditional expression is used for
the loop termination test.
Michael.