Problems with GGC and bitmap/hash_set

Michael Ploujnikov michael.ploujnikov@oracle.com
Fri Jan 18 13:38:00 GMT 2019


On 2019-01-18 3:45 a.m., Richard Biener wrote:
> On Thu, Jan 17, 2019 at 8:16 PM Michael Ploujnikov
> <michael.ploujnikov@oracle.com> wrote:
>>
>> Hi,
>>
>> I've been doing some investigations that required using a bitmap to keep track of decl IDs and I ran into segmentation fault after my bitmap has been loaded from a PCH. Attached is a short patch that can reliably reproduce my problem. Looks like head->current is set to point to uninitialized memory for some reason. Could someone with a strong understanding of GGC take a look and let me know what I might be doing wrong and how to fix this?
> 
> If you're just doing investigation why do you care about PCH?

My idea is to write a patch that does something similar to this, but not exactly (obviously not storing all of the object IDs for example). It's very preliminary and I don't know about the feasibility of what I'm trying to do, but I do know that I need a bitmap/hash_set for the full duration of toplev::main which inevitably involves PCH. However because of this segfault I haven't been able to actually try my idea yet!

> 
> In any event I guess that bimaps are not supported by PCH because of
> GTY(skip)ing the bitmap_head current member (so that's not saved).
> I guess PCH writers/readers need to ignore skipping.

Why is the current member not saved? I know the documentation says that another pointer in the chain already points to the same thing, but what's the harm in not skipping it?


- Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20190118/46f96463/attachment.sig>


More information about the Gcc mailing list