This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind
- From: "ccoutant at google dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 27 Jan 2015 20:17:46 +0000
- Subject: [Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind
- Auto-submitted: auto-generated
- References: <bug-63504-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504
--- Comment #14 from ccoutant at google dot com ---
> But then there is (question mainly on Cary) the .debug_types checksumming:
>
> case dw_val_class_const_double:
> CHECKSUM_ULEB128 (DW_FORM_block);
> CHECKSUM_ULEB128 (sizeof (at->dw_attr_val.v.val_double));
> CHECKSUM (at->dw_attr_val.v.val_double);
> break;
>
> case dw_val_class_wide_int:
> CHECKSUM_ULEB128 (DW_FORM_block);
> CHECKSUM_ULEB128 (sizeof (*at->dw_attr_val.v.val_wide));
> CHECKSUM (*at->dw_attr_val.v.val_wide);
> break;
>
> and that one ought to be governed by the DWARF standard, so I wonder how it can
> get away without converting for endianity etc.
There shouldn't be any location lists in .debug_types, so I don't
think the DWARF standard really matters for this case, and it would be
reasonable to use the same hashing you use for other purposes. Some
may slip through, unfortunately, so I covered this case just for
completeness.
-cary