This is the mail archive of the gcc-bugs@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]

Re: Measuring gcc optimizations: are they well balanced?


> 
> 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.
> 
> 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.

Honza
> 
> -Andi
> 
> 
> -- 
> This is like TV. I don't like TV.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]