From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9BFF63858C74; Tue, 1 Mar 2022 14:40:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9BFF63858C74 From: "gprocida at google dot com" To: libabigail@sourceware.org Subject: [Bug default/26646] unexpected declaration-only types Date: Tue, 01 Mar 2022 14:40:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: gprocida at google dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2022 14:40:28 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26646 --- Comment #30 from gprocida at google dot com --- Hi Dodji. On Mon, 28 Feb 2022 at 10:01, dodji at redhat dot com wrote: > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D26646 > > --- Comment #28 from dodji at redhat dot com --- > (In reply to gprocida from comment #26) > > > > If the regression disappears, I guess we can say that the current sta= te is > > > an improvement. If so, I'll clean-up and post the patches on the lis= t, if > > > you agree. Further investigation will continue after that. > > > > Agreed. Thanks! > > I have posted the cleaned-up patch for review at > https://sourceware.org/pipermail/libabigail/2022q1/004179.html. > I've thought a little bit more about this one. The current check is "local", recursion prevention at *this* DIE prevents it from being canonicalised, but it could still depend on child DIEs that are actually also parent DIEs and whose processing has not yet been completed. Would it be safer (more precise) to inhibit on-the-fly canonicalisation whenever the set (stack) of aggregates being compared is non-empty? Giuliano. > Thanks. > > -- > You are receiving this mail because: > You are on the CC list for the bug. --=20 You are receiving this mail because: You are on the CC list for the bug.=