From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 107D03858CDB; Fri, 31 Mar 2023 12:28:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 107D03858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680265693; bh=yjHblT3lVfGd0+DrEDJ2b+O7k2sAlMm4kd/+8RdyT2U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=h7Zr4C9qLYErT840QrQNugs70Q/G+gKL/UVNBUUIQFBw8BEOQBT9jmAvddPLb6IEq v2+ixNSIAp6/3DydfPE0sxaZHKpjTL0ukE8f4mt73TWSU2m9PTlPEpE868znIXBE7l YoTcFBnCz1oYX300HAxWxW+086k3t6QZKCKBJFss= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o Date: Fri, 31 Mar 2023 12:28:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: d X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: build X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ibuclaw at gdcproject dot org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109231 --- Comment #37 from Jakub Jelinek --- (In reply to ro@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_fnd= ecl, > > 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) =3D=3D NULL); >=20 > 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=3D1 bug was just latent before, perhaps some code generation dec= ision is done from pointer comparisons or something similar. If the problem without this patch is reliably reproduceable even with the s= ame d21 binary but not after enabling all the dumps, perhaps another attempt wo= uld be try to see if enabling just one dump somewhere would make it latent again as well or i= f it would still reproduce. So rather than trying to -fdump-tree-all -da, perha= ps 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, y= ou 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.=