https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98912
--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Well, lto_section is 8 byte long struct containing 2 ushort fields, 1 uchar,
> one byte padding (on most hosts) and one ushort field.
> So bet valgrind is complaining about streaming the padding...
I bet it's complaining about the padding.
Please test the following debugging patch:
diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 405f3bfc56c..d96a7ee3ec8 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -2672,6 +2672,10 @@ produce_lto_section ()
lto_section s
= { LTO_major_version, LTO_minor_version, slim_object, 0 };
s.set_compression (compression);
+ char *ptr = (char *)&s;
+ for (unsigned i = 0; i < sizeof s; i++)
+ fprintf (stderr, "v[%d]=%d\n", i, ptr[i]);
+ fprintf (stderr, "\n");
lto_write_data (&s, sizeof s);
lto_end_section ();
destroy_output_block (ob);
with GCC 10 the object is constructed in the following way:
MEM <char[4]> [(struct lto_section *)&s + 2B] = {};
s.major_version = 9;
s.slim_object = prephitmp_911;
s.flags = 1;
and that covers all bytes in the struct.
