https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to r...@cebitec.uni-bielefeld.de from comment #36) > > --- a/gcc/tree-inline.cc > > +++ b/gcc/tree-inline.cc > > @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, > > profile_count count) > > /* Get clean struct function. */ > > push_struct_function (new_fndecl, true); > > targetm.target_option.relayout_function (new_fndecl); > > + if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl)))) > > + gen_raw_REG (DECL_MODE (DECL_RESULT (new_fndecl)), 8); > > > > /* We will rebuild these, so just sanity check that they are empty. */ > > gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); > > This one passed the build. That is kind of bad news for trying to debug where the problem is, because the above patch has only effect of doing 4 extra GC allocations, so the -fno-checking vs. -fchecking=1 bug was just latent before, perhaps some code generation decision is done from pointer comparisons or something similar. If the problem without this patch is reliably reproduceable even with the same d21 binary but not after enabling all the dumps, perhaps another attempt would be try to see if enabling just one dump somewhere would make it latent again as well or if it would still reproduce. So rather than trying to -fdump-tree-all -da, perhaps just try -fdump-tree-optimized, or -fdump-rtl-vregs or -fdump-rtl-postreload etc. If the assemblies differ even with just one of those dumps enabled, you can see if there is any difference in the dump or not. Other option would be only side-by-side debugging but without the dumps actually working it is much harder to find out where to look at.
