This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Measuring gcc optimizations: are they well balanced?
At 14:02 10.01.00 , Jan Hubicka wrote:
> >
> > Hallo Jan,
> >
> > hubicka@atrey.karlin.mff.cuni.cz (Jan Hubicka) writes:
> >
> > >
> > > i=0
> > > while (i < TOP-1)
> > > table[i] = table[i+1];
> > >
> > > so please next time try to avoid such simple mistakes.
> > > I've tried to reproduce your problem with current version of gcc using
> > > following loop:
> >
> > His original version did have the i++ (at least in the version I saved).
> > I think the interesting point is that it is not clear if the bug is fixed.
> > It seems to be covered by another optimization, but would it generate
> > correct code if the loop cannot be converted to down counting for some
> > reason?
>
>I believe it generates correct code in all cases.
>Having few extra instructions inside loop isn't bug as long as the behaviour
>of program is unchanged.
>If you are curious what whould happen then, just try it.
>My reply is that I don't know...
>Gcc managed to inverse all simple modifications to the given loop I've tried.
Jan,
please look at the original bug report at
<http://gcc.gnu.org/ml/gcc-bugs/2000-01/msg00001.html>.
This seems to be a miscompilation on x86 only (?), I tried it with current
gcc-2_95-branch on PPC and the produced code looks and works fine. Andi
tried the current 2.95-branch on x86 and could still reproduce the bug.
Hmmm, I just remember I have one additional patch backported from the
mainline in my 2.95-branch sources for PPC, but I don't think it's relevant
here:
Thu Nov 4 15:52:35 1999 Andrew Haley <aph@cygnus.com>
* reload1.c (reload_reg_free_for_value_p): Don't use a register
that is in reload_reg_used.
> >
> > Also IMHO the bug is quite serious to have in a release compiler
> > like gcc 2.95.2, and it would be nice if there was a small standalone
> > that could be applied if needed and hopefully be put into 2.95.3 if it
> > should ever be released.
>
>The minor releases contains fixes only to the major problems (that causes
>crashes, incorrect code etc).
>Not to the misoptimizations, so you would have to wait for next major release
>anyway.
This is a bug and no missed optimization, so it should be fixed for 2.95.3
if possible (maybe you can take a look?).
Franz.