Your proposed change to loop.c

Joern Rennecke amylaar@cygnus.co.uk
Wed Jun 23 16:57:00 GMT 1999


>     Joern> The loop that initialized stats[i].start_luid,
>     Joern> stats[i].end_luid and increments end_needs_computing uses
>     Joern> the numbering from before the first sort.  By having v->ix
>     Joern> point back with the same numbering scheme, find_life_end
>     Joern> could properly function, but the results were just garbled.
>     Joern> I suppose you can fix that by setting i to v->ix instead of
>     Joern> incrementing it.
> 
> Now we're getting somewhere.  This is the kind of information I'm
> looking for.  Could you just go into a bit more detail?  I think you
> forgot the part about me not being a loop.c master wizard. :-) Just
> spell it out a bit more.
> 
> As I understand you:
> 
>   o Fisrt we compute v->ix:
> 
>     /* Initialize stats and set up the ix field for each giv in stats to name
>        the corresponding index into stats.  */
> 
>   o Then we sort stats:
> 
>     qsort (stats, giv_count, sizeof(*stats), cmp_recombine_givs_stats);
> 
>   o Now, v->ix is wrong; we just changed all the indices around.  
> 
> I can see that this could cause general chaos.  Do I have it right so
> far?  Is that the bug?

One of the bugs.

> If so, isn't the fix just to iterate through assigning to v->ix after
> the sort, instead of before?  Presumably, when we sort again a bit

That's what my patch from last Thursday did.

> later, we should do this again?  I think you're suggesting something
> like this in your last line above, but I don't quite get what you
> mean.  Go slow, work with me. :-)

No.  Getting into any more detail would mean making a patch, but I don't
have any spare CPU cycles now to test it.


More information about the Gcc-patches mailing list