public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: Joe Buck <Joe.Buck@synopsys.COM>
Cc: Jeff Law <law@redhat.com>,
	Richard Guenther <richard.guenther@gmail.com>,
	     GCC <gcc@gcc.gnu.org>
Subject: Re: (known?) Issue with bitmap iterators
Date: Fri, 26 Jun 2009 19:28:00 -0000	[thread overview]
Message-ID: <alpine.LNX.2.00.0906262309570.27723@endeed2.ispras.ru> (raw)
In-Reply-To: <20090626163559.GM14794@synopsys.com>



On Fri, 26 Jun 2009, Joe Buck wrote:

> On Fri, Jun 26, 2009 at 03:38:31AM -0700, Alexander Monakov wrote:
>> 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.
>
> Sorry, it doesn't work.  Function foo has a loop that iterates
> over a bitmap.  During the iteration, it calls a function bar.  bar
> modifies the bitmap, then iterates over the bitmap.  It then returns
> to foo, which is in the middle of an iteration, which it continues.
> The bitmap has been modified (by bar), but modified_p was reset to
> false by the iteration that happened at the end of bar.

Good catch, thanks!  Let me patch that up a bit:

1. Add int field `generation' in bitmap structure, initialized arbitrarily 
at bitmap creation time.
2. Make iterator setup functions save initial generation count in the 
iterator (or generation counts for two bitmaps, if needed).
3. Modify generation count when bitmap is modified (e.g. increment it).
4. Verify that saved and current generations match when incrementing the 
iterator.

  reply	other threads:[~2009-06-26 19:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-20 14:53 Jeff Law
2009-06-20 15:01 ` Richard Guenther
2009-06-21  3:27   ` Peter Bergner
2009-06-22 17:06   ` Jeff Law
2009-06-22 17:46     ` Joe Buck
2009-06-22 19:07       ` Dave Korn
2009-06-25 18:11         ` Daniel Berlin
2009-06-25 18:37       ` Jeff Law
2009-06-25 22:39         ` Dave Korn
2009-07-01  2:14           ` Jeff Law
2009-06-26 10:47         ` Alexander Monakov
2009-06-26 16:51           ` Joe Buck
2009-06-26 19:28             ` Alexander Monakov [this message]
2009-07-01  2:21               ` Jeff Law
2009-07-01  6:48                 ` Dave Korn
2009-06-22  2:44 ` Daniel Berlin
2009-06-22 11:33   ` Dave Korn
2009-06-22 11:37     ` Richard Guenther
2009-06-22 13:06       ` Dave Korn
2009-06-22 13:38         ` Paolo Bonzini
2009-06-22 19:03           ` Dave Korn
2009-06-22 14:27   ` Andrew MacLeod

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.00.0906262309570.27723@endeed2.ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=Joe.Buck@synopsys.COM \
    --cc=gcc@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).