On 12/14/20 10:34 PM, Ian Lance Taylor wrote:
On Mon, Dec 14, 2020 at 7:14 PM Nikhil Benesch <nikhil.bene...@gmail.com> wrote:
Also godump now emits a dummy `type _u?pad128_t struct {}` entry,
so we just suppress that and conditionally add it back.
I don't understand this bit. Why are we seeing an empty struct
definition, and why is this change the right fix?
Is the problem that because we don't know how to emit the definition
of the struct, godump.c winds up emitting an empty definition? That
doesn't sound like the right thing to do for this case.
That's a good question. u?pad128_t is clearly getting marked as a
potential dummy type. But then you'd think it'd *also* get marked as
an invalid type, and then find_dummy_types would suppress it.
Oh, you know, I bet the change to use DECL_ORIGINAL_TYPE means the
pointers in pot_dummy_types and invalid_types no longer line up. It
might be as simple as this:
diff --git a/gcc/godump.c b/gcc/godump.c
index ff3a4a9..2497037 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -1177,7 +1177,8 @@ go_output_typedef (class godump_container *container,
tree decl)
NULL, false))
{
fprintf (go_dump_file, "// ");
- slot = htab_find_slot (container->invalid_hash, type, INSERT);
+ slot = htab_find_slot (container->invalid_hash, original_type,
+ INSERT);
*slot = CONST_CAST (void *, (const void *) type);
}
fprintf (go_dump_file, "type _%s ",
I can't test this theory for a bit though. Probably should couple with a
negative (scan-file-not) test too.
Nikhil