This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: mudflap cache question
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Herman ten Brugge <hermantenbrugge at home dot nl>
- Cc: gcc at gcc dot gnu dot org
- Date: 15 Jun 2005 11:15:36 -0400
- Subject: Re: mudflap cache question
- References: <42AF3F1F.6050902@home.nl>
Hi -
Herman ten Brugge <hermantenbrugge@home.nl> writes:
> [...]
> I looked at the code in mf-runtime.c and found the cache
> functions. The code [...]
> __mf_uncache_object (__mf_object_t *old_obj)
> [...]
> unsigned idx_low = __MF_CACHE_INDEX (low);
> unsigned idx_high = __MF_CACHE_INDEX (high);
> for (i = idx_low; i <= idx_high; i++)
> [... check cache slot at index i ...]
> [...]
> __MF_CACHE_INDEX(ptr) is (ptr >> 2) & 0x3ff at startup.
>
> Suppose we have an old_obj->low of 0x10000 and an old_obj->high of
> 0x20000. Then the cache entries we look at is just entry 0. Which I
> believe is just wrong. Any pointer between 0x10000 and 0x20000 must
> fill other cache entries. [...]
You're right, one can't treat this way a data structure that is trying
to be a hash table. Probably this wasn't found before because it
would result in false no-error indications, which are quiet.
> Should I write a bug report?
Not necessary, this is fine. Thank you.
- FChE