http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've looked at dozens of the failures, except for one they were all about an
expected TREE_VEC being written as 0s (i.e. ERROR_MARK) in the PCH file, the
one exception was TREE_LIST instead of TREE_VEC. But it isn't always the same
place that refers to the previously TREE_VEC, sometimes it is
t->type_with_lang_specific->lang_specific->u.c.template_info->typed.type->decl_non_common->arguments
which points to ERROR_MARK code instead of TREE_VEC, sometimes it is
static tree
get_template_argument_pack_elems_folded (const_tree t)
{
return fold_cplus_constants (get_template_argument_pack_elems (t));
}
where get_template_argument_pack_elems returns TREE_TYPE of something and the
TREE_TYPE is a TREE_VEC with 0s in the PCH file, etc.
I've tried to disable ggc_free altogether (return early in the function), but
that didn't fix this up. Using setarch x86_64 -R seems to reliably make the
problem away, so whether we hit this or not depends on address space
randomization of the process that saves the PCH file.
So no idea how to debug this actually, perhaps only through instrumenting the
kernel somehow (systemtap, something else)? I'd imagine if we recorded all the
random values used during address space randomization of selected processes
(cc1plus would be interesting for us), then run in a loop the PCH saving + PCH
reading commands mentioned above until it fails and when it fails, looked into
logs (systemtap, something else) what exact values the PCH saving cc1plus
process used and then somehow arranged to replay those values reliably for all
cc1plus invocations under some session, then supposedly it could be reliably
reproduced.
