Re: Weird optimization bug...?

[Adrian Bentley <adruab@voria.com>]

Ok ok... I think I found why it's crashing (although it doesn't actually
crash when I run it because I'm calling a print function).  Anyways, I
re-expanded the if statement to check the bounds on the array
indirections....

//see other code for the rest...
if (y>length) 
{
	typename T1::value_type &v = iter[-length-1];
	if( (char*)&v < beginptr || (char*)&v >= endptr)
		printf("crap! %d (%p off %p)\n",y,&v,&*iter);
	tot-=iter[-length-1];
}
else
{
	tot-=val;
}

And I'm indirecting off of iter which is being incremented every
iteration.  But for some reason it looks like gcc decided to use the
original value of iter for the 10th iteration (1 greater than the value
for length my example is using) inside the sample case I have... (i.e.
rather than using the incremented value).  So it looks like it was
trying to optimize out an expression that wasn't constant (either in
attempting to optimize the first if statement out of the loop).  It
doesn't do this when I turn optimization off... so it definitely looks
like an optimizer bug.

Anyways, I'm not sure why it would do this as iter is being changed
every iteration.  Oh well, I'm gonna manually do some unrolling and
hopefully it won't break any more.  Hope that helps anyone interested in
the issue.

Thanks again all,
Adruab


On Thu, 2004-06-03 at 11:36, Eljay Love-Jensen wrote:
> Hi Adruab.
> 
>  >However, if that was the case, inserting a random function into the code 
> certain shouldn't fix the problem :P.
> 
> Inserting a random function into the code can affect the optimizer, which 
> can mask the problem.
> 
> I recommend taking a look at the assembly file to see what's different 
> between having and not having the extra function present, in the optimized 
> code.
> 
> You can use the "-save-temps" to keep the assembly file around, and 
> "-fverbose-asm" for extra blather.
> 
> HTH,
> --Eljay
> 
> 
>