(known?) Issue with bitmap iterators

Alexander Monakov amonakov@ispras.ru
Fri Jun 26 10:47:00 GMT 2009



On Thu, 25 Jun 2009, Jeff Law wrote:
> I wasn't suggesting we make them "safe" in the sense that one could modify 
> the bitmap and everything would just work.  Instead I was suggesting we make 
> the bitmap readonly for the duration of the iterator and catch attempts to 
> modify the bitmap -- under the control of ENABLE_CHECKING of course.  If that 
> turns out to still be too expensive, it could be conditional on 
> ENABLE_BITMAP_ITERATOR_CHECKING or whatever, which would normally be off.
>
> My biggest concern would be catching all the exit paths from the gazillion 
> iterators we use and making sure they all reset the readonly flag.  Ick...

Unless I'm missing something, one can avoid that by checking whether the 
bitmap has been modified in the iterator increment function.  To be 
precise, what I have in mind is:

1. Add bool field `modified_p' in bitmap structure.
2. Make iterator setup functions (e.g. bmp_iter_set_init) reset it to 
false.
3. Make functions that modify the bitmap set it to true.
4. Make iterator increment function (e.g. bmp_iter_next) assert 
!modified_p.

This approach would also allow to modify the bitmap on the iteration 
ending with break, which IMHO is fine.

-- 
Alexander Monakov



More information about the Gcc mailing list