This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA] Type inheritance graph analysis & speculative devirtualization, part 4/7, ODR at LTO time
- From: Jason Merrill <jason at redhat dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, marxin dot liska at gmail dot com, rguenther at suse dot de, mjambor at suse dot cz, davidxl at google dot com
- Date: Sun, 01 Sep 2013 17:24:24 -0400
- Subject: Re: [RFA] Type inheritance graph analysis & speculative devirtualization, part 4/7, ODR at LTO time
- Authentication-results: sourceware.org; auth=none
- References: <20130819140116 dot GA16575 at kam dot mff dot cuni dot cz> <522396E0 dot 9080208 at redhat dot com> <20130901195034 dot GB15259 at kam dot mff dot cuni dot cz>
On 09/01/2013 03:50 PM, Jan Hubicka wrote:
I was mostly worried about ordering issues. pointer_set is not stable
across memory layout changes and we may end up outputting warnings/merging
binfos in random orders. This seemed uncool. Maybe the final form is quite
safe, since we do everything with the designated leader, but I would rather
keep this here rather than later go into nasty issues of divergences in
between compilation on different hosts.
OK, sure.
I will leave this for incremental update and discuss it with Richard.
OK.
I see, I wondered if I can get mangling of type names. So, once we will
need uniqueness of ODR types for C++ (probably for alias info), we can
basically convince C++ FE to produce the mangling and then discover
and match ODR types based on presence of the assembler names?
Yes.
Can't this be used for merging of dwarf debug info on types?
Possibly, but we already have several ways to merge dwarf debug info for
types: .debug_types and dwz come to mind first.
Jason