From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by sourceware.org (Postfix) with ESMTPS id 322033858D28 for ; Wed, 29 Dec 2021 15:39:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 322033858D28 Received: by mail-wm1-x32e.google.com with SMTP id o30so11323384wms.4 for ; Wed, 29 Dec 2021 07:39:08 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y4kHl3N3J+TKP0IxFLop7Zxv4lu4AI/7SRW16yMvZRc=; b=7+DJp9rzFeE0hd6xRImry/GimWKMzC0ZZBv6Ags8TZ4IfLJ0Q5rVhPldLh7/FPgNaQ Yz4lAb1iKJLXAoyCtx2xMB6XdZdMKE9+7VNkSycDPeYvu/aJrymdmn6tFmriegCCjjGK /6ya3ELL87xyfdTIKve6BEMTMFf7Jvacgz7U2hvllypjcHz016Jd65SwpG/bNVOSkXYW 7nbZgiyj3qYix8L/f8MLzPO6NIA1xqYQbaWaL2Bomz3ZioFHqQtocOCPtNIW6j3QHiUg WvLbPcq3G/ZY7FbOE0IKoZEl9NFN7k439iFRUat98fUkO2cAkbAIUtnYLT9sqv5sXI3k ImCQ== X-Gm-Message-State: AOAM5327IZocSLPWAtPw1JntWvFI9aPGlQqMCEguIDysZfOB3X3nWbjp ILks07mzWNV5wLloWSCntJPg9u77efaty7xkh9c= X-Google-Smtp-Source: ABdhPJzyT8d1XRfvi7mQmgDuBS8BF99mimXIFioMSDdNlnuaUyhGgpHBkaOWSQnIWYikuqqY51eWdLjTDB16lZilWrM= X-Received: by 2002:a7b:c0c1:: with SMTP id s1mr21677449wmh.176.1640792347191; Wed, 29 Dec 2021 07:39:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Wed, 29 Dec 2021 15:38:54 +0000 Message-ID: Subject: Re: GCC 8.3.0, -flto and violation of C++ One Definition Rule To: Tom Kacvinsky Cc: gcc-help X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2021 15:39:09 -0000 On Wed, 29 Dec 2021, 11:45 Tom Kacvinsky via Gcc-help, wrote: > 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. As already explained, this is almost certainly wrong. It is more likely that the LTO violation is always present, but only detected when using LTO. 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, It would help if you tell us the actual error/warning you get. -Wodr can warn about various different things. It does not warn about multiple definitions, it warns about *inconsistent* definitions. 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 >