This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 4/4] Convert lto streamer out hashing to inchash
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Andi Kleen <ak at linux dot intel dot com>
- Date: Wed, 23 Jul 2014 16:21:59 +0200
- Subject: Re: [PATCH 4/4] Convert lto streamer out hashing to inchash
- Authentication-results: sourceware.org; auth=none
- References: <1405488709-12677-1-git-send-email-andi at firstfloor dot org> <1405488709-12677-2-git-send-email-andi at firstfloor dot org> <1405488709-12677-3-git-send-email-andi at firstfloor dot org> <1405488709-12677-4-git-send-email-andi at firstfloor dot org> <1405488709-12677-5-git-send-email-andi at firstfloor dot org> <53CF2E9F dot 9010103 at redhat dot com>
On Wed, Jul 23, 2014 at 5:40 AM, Jeff Law <email@example.com> wrote:
> On 07/15/14 23:31, Andi Kleen wrote:
>> From: Andi Kleen <firstname.lastname@example.org>
>> No substantial changes, although the hash values will be slightly
>> 2014-07-10 Andi Kleen <email@example.com>
>> * lto-streamer-out.c (hash_tree): Convert to inchash.
>> (add_flag): New macro.
> So my question here, does this make any existing LTO objects no longer
> usable? If so, what, if any policy do we have when we make that kind of
> If existing LTO objects continue to work, then this patch is fine too once
> the explicit begin/end vs ctor/dtor stuff is fixed.
I'd say add_flag should be in the hash abstraction? You convert
only some to hash_flag and not all of them - why? For example
I don't like your handling of TYPE/DECL_MODE. Please refrain
from doing semantical changes like that and call it a simple