Your proposed change to loop.c
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