From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tkacvins@gmail.com>
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [IPv6:2a00:1450:4864:20::52d])
 by sourceware.org (Postfix) with ESMTPS id B2D053858D28
 for <gcc-help@gcc.gnu.org>; Wed, 29 Dec 2021 11:44:31 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B2D053858D28
Received: by mail-ed1-x52d.google.com with SMTP id bm14so85214983edb.5
 for <gcc-help@gcc.gnu.org>; Wed, 29 Dec 2021 03:44:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=Z833GEXw+JPS6kQU4wZVA35EgbcENLckOS3zy98w8k0=;
 b=Nc0QSKm5YcwI/EJs3T26oWTVDPgLDCzZkP5z0fUwSw6E1qI0HWWYdDh4AVxw6pETjt
 iolqgnCDvfnGhm+tQ9VLWxUX1WLpprU22cXqkYeiCjgwiTLk+TxcTGgjBtO0+kOiqJK8
 j15CudiDERTYuxtcDx5bW/cZijDkq73Nq+Owo64IhUP+YDp9uskM3xRBC/dus9ruWZl2
 hRixCpI6/6OF4+yarIyR8Usyi9XfTdvrC+Q3ofm8Wo0Vgco7l6u4g4/ur9QfG4OG5Wuo
 9m+BnYiFmcv2RGqQa2C8lgYIdNS7ITzqEP6gCxIo4R/D2vClOjkeXs61c+ecbwMCT5ck
 hQyw==
X-Gm-Message-State: AOAM532aGUygJgGxPJS76Sr4RrHPMRl0yMqVyS3SGcOEXmBrg0kAf+d/
 cscpux+8TERsTuZ13u2ppO0suzg+aMSFSR2Ex8kzRn5iTyE=
X-Google-Smtp-Source: ABdhPJzsghBniwBuODoDed9nemhjTwqjK8NT7baaubkrTn4BN2ojX5I2wOud8SUHm/uhmOicOkuiZtyAdWmCNrdmRd8=
X-Received: by 2002:a50:cc07:: with SMTP id m7mr24522455edi.4.1640778270413;
 Wed, 29 Dec 2021 03:44:30 -0800 (PST)
MIME-Version: 1.0
From: Tom Kacvinsky <tkacvins@gmail.com>
Date: Wed, 29 Dec 2021 06:44:19 -0500
Message-ID: <CAG_eJLf1GyCTi+KW29Nqt19oV44jRMam8WbBsCEfhwEvf8jjkw@mail.gmail.com>
Subject: GCC 8.3.0, -flto and violation of C++ One Definition Rule
To: gcc-help <gcc-help@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: gcc-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Dec 2021 11:44:33 -0000

Hi,

First, using GCC 8.3.0 and binutils 2.37.I am trying to increase
performance of linking our product, so I thought I'd give LTO a try.  So
I am compiling all object files with -flto, and passing -flto to g++
(which we use as our link driver).  However, what I have found is that
some of our code violates the C++ One Definition Rule (-Werror=odr). This
only happens when building with LTO - without LTO, the C++ rule is
not violated.  The problem exists with LTO using both the BFD and gold
linkers.

So, my question is, since the LTO object files are now such that one
needs to use gcc-nm to examine them (which I know is a wrapper around nm,
and passes an option to load the LTO plugin). how can I leverage that to
see if there are other translation units that define the class that ODR
violation is complaining about?  I did do a fairly thorough analysis of
the object files and did not see there the particular class and methods
would be multiply defined, but that was just based on symbol names from
gcc-nm output.  I suspect there is more to this since the object files
have LTO information now, and that is what I'd like to examine.

Any hints on how to move forward with diagnosing LTO link errors?

Thanks,

Tom