This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 4/4] Convert lto streamer out hashing to inchash
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jeff Law <law at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, gcc-patches at gcc dot gnu dot org, Andi Kleen <ak at linux dot intel dot com>
- Date: Wed, 23 Jul 2014 16:53: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 07/15/14 23:31, Andi Kleen wrote:
> >From: Andi Kleen <ak@linux.intel.com>
> >
> >No substantial changes, although the hash values will be slightly
> >different.
> >
> >gcc/:
> >
> >2014-07-10 Andi Kleen <ak@linux.intel.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 change?
We are freely breaking LTO objects all the time and have version checks
that are bumped after each release. If you mix object files from released
versions you get correct diagnostics, if you mix object files from different
versions of trunk, you get random errors or ICEs. I think we managed to
stay bytecode compatible for 4.8 release series. (Richi knows better)
Once we get well defined gimple and types, we can get also stable bytecode,
but until that this seems resonable policy.
Honza
>
> If existing LTO objects continue to work, then this patch is fine
> too once the explicit begin/end vs ctor/dtor stuff is fixed.
>
>
> jeff
>