From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 37FDC385B80B; Fri, 3 Apr 2020 16:43:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 37FDC385B80B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585932181; bh=L6lnpn/ZWvwDeNeGvCoIS92n/vcIQsroMrAqfY/TWEU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RzECXmTboricbi9d2TxrV7iFD9cvWqmjBHb0xwg1XFnitFcXvrrVE3LpRySeKldqp VJQZThzNG+f+BLP5rf6jChiEnSdcyU6jw9je8aY5LyDICLpIIy7KtKAbx23tcgtpBM tBxn2MwGjwseJiSrnF8BfNW5bAC8e6Q8R3NReXhE= From: "vries at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/94450] lto abstract variable emitted as concrete decl Date: Fri, 03 Apr 2020 16:43:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: lto X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 16:43:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94450 Tom de Vries changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tromey at gcc dot gnu.org --- Comment #13 from Tom de Vries --- (In reply to rguenther@suse.de from comment #11) > Note that as I read the DWARF spec changing the > early CUs to DW_TAG_partial_unit and then again importing those > (the spec suggests you need to import DW_TAG_partial_units) would > not reflect documented semantics either. It's not my understanding from the spec that DW_TAG_partial_units are requi= red to be imported. AFAIU, it's just that in all the use-cases there using DW_TAG_partial_unit, an import happens to be required. OK, so lets look at the use cases described in the spec at E.1. I. classic dwz: factor out into partial unit, add imports: ... DW_TAG_compile_unit DW_AT_name cu1 L1: DIEx DIEy DW_AT_type L1 DW_TAG_compile_unit DW_AT_name cu2 L2: DIEx DIEz DW_AT_type L2 -> L3: DW_TAG_partial_unit L4: DIEx DW_TAG_compile_unit DW_TAG_imported_unit DW_AT_import L3 DW_AT_name cu1 DIEy DW_AT_type L4 DW_TAG_compile_unit DW_TAG_imported_unit DW_AT_import L3 DW_AT_name cu2 DIEz DW_AT_type L4 ... II. dwz --devel-uni-lang --devel-gen-cu: factor out into DW_TAG_compile_uni= t, no imports, exploit global namespace: ... DW_TAG_compile_unit DW_AT_name cu1 L1: DIEx DIEy DW_AT_type L1 DW_TAG_compile_unit DW_AT_name cu2 L2: DIEx DIEz DW_AT_type L2 -> DW_TAG_compile_unit L4: DIEx DW_TAG_compile_unit DW_AT_name cu1 DIEy DW_AT_type L4 DW_TAG_compile_unit DW_AT_name cu2 DIEz DW_AT_type L4 ... III. #include in namespace: ... DW_TAG_compile_unit DW_AT_name cu1 DW_TAG_namespace bla1 L1: DIEx DIEy DW_AT_type L1 DW_TAG_compile_unit DW_AT_name cu2 DW_TAG_namespace bla2 L2: DIEx DIEz DW_AT_type L2 -> L3: DW_TAG_partial_unit L4: DIEx DW_TAG_compile_unit DW_AT_name cu1 DW_TAG_namespace bla1 DW_TAG_imported_unit DW_AT_import L3 DIEy DW_AT_type L4 DW_TAG_compile_unit DW_AT_name cu2 DW_TAG_namespace bla2 DW_TAG_imported_unit DW_AT_import L3 DIEz DW_AT_type L4 ... So indeed, in all cases where DW_TAG_partial_unit is used, we use an import, but that's because it's applicable to the transformation, and we're just do= ing an entirely different transformation here: ... DW_TAG_compile_unit DW_AT_name cu1 DW_TAG_variable DW_AT_name var1 DW_AT_location -> DW_TAG_partial_unit L1: DW_TAG_variable DW_AT_name var1 DW_TAG_compile_unit DW_AT_name cu1 DW_TAG_variable DW_AT_abstract_origin L1 DW_AT_location ... We fabricate a new abstract DW_TAG_variable DIE out of thin air, then try to hide that fact by placing it in a DW_TAG_partial_unit, much like is done at III. Only in contrast to III, we don't want to reintroduce it in another context, we want it to keep hidden, so there's no import.=