Ping: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00642.html
Jason, I'm on PTO until 1/6 starting this Thursday, with no
connectivity. If there are any further changes to make to
the patch I will need to make them before then, or otherwise
after I get back in January.
On 12/9/19 5:29 PM, Martin Sebor wrote:
On 12/6/19 12:08 PM, Jason Merrill wrote:
On 12/5/19 6:47 PM, Jakub Jelinek wrote:
On Thu, Dec 05, 2019 at 04:33:10PM -0700, Martin Sebor wrote:
It's hard to distinguish between this type and the previous one by
name;
this one should probably have "map" in its name.
+static GTY (()) record_to_locs_t *rec2loc;
...
+ rec2loc = new record_to_locs_t ();
If this isn't GC-allocated, marking it with GTY(()) seems wrong.
How do
you imagine this warning interacting with PCH?
I have to confess I know too little about PCH to have an idea how
it might interact. Is there something you suggest I try testing?
For your patch, obviously some struct/class forward declarations or
definitions in a header that you compile into PCH and then the main
testcase
that contains the mismatched pairs.
If there is something that you need to record during parsing of the
precompiled header and use later on, everything needs to be GGC
allocated.
So, the hash_map needs to be created with something like
hash_map<something, something_else>::create_ggc (nnn)
and it really can't use pointer hashing, but has to use some
different one
(say on DECL_UID, TYPE_UID etc.), because the addresses are remapped
during
PCH save/restore cycle, but hash tables aren't rehashed.
See e.g. PR92458.
Alternately you can decide that this information will not be saved to
PCH, and rely on CLASSTYPE_DECLARED_CLASS for classes loaded from a PCH.
This seems like the right approach to me. Mismatches in
a precompiled header should be diagnosed when the header is
being compiled, so the only ones involving its uses should
be between classes defined in it and declared or referenced
outside it. I've implemented this in the attached revision.
Martin
