From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8343 invoked by alias); 23 Jan 2020 13:07:17 -0000 Mailing-List: contact dwz-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: dwz-owner@sourceware.org Received: (qmail 8306 invoked by uid 48); 23 Jan 2020 13:07:12 -0000 From: "vries at gcc dot gnu.org" To: dwz@sourceware.org Subject: [Bug default/25449] Factor out compilation units Date: Wed, 01 Jan 2020 00:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: dwz X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: nobody at sourceware dot org 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-SW-Source: 2020-q1/txt/msg00041.txt https://sourceware.org/bugzilla/show_bug.cgi?id=3D25449 --- Comment #3 from Tom de Vries --- (In reply to Tom de Vries from comment #2) > So, the jist of this seems to be: > - factored out partial unit: needs import > - factored out compilation unit: > - prudent to import from C compilation unit (but we can have f.i. a > command line option to not do this, and see what breaks) Alternatively, we can try to prove we don't need the import. If the all the elements in the factored out compilation unit are uniquely named in link sc= ope, there's no confusion about which is meant, and we don't need the import. > - not required from C++ compilation unit Conversely, this may cause problems because there may be different DIEs with the same globally unique name which are not structurally equivalent. This happens for instance with member function templates, where a DIE in one CU representing a named struct can have extra members representing the various member function template instantiations in the CU, making the DIE potential= ly different from other DIEs representing the same named struct in other CUs. [ Which is why we want a --odr-mode=3Dunify option. ] --=20 You are receiving this mail because: You are on the CC list for the bug.