From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2B4343945057; Thu, 9 Apr 2020 08:47:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2B4343945057 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1586422058; bh=alYaDGog1M8hE3VTUJVoau+Ng4KcsShr216twymTK+8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ys73YMFElc0QHr7+gUMY2C6lL8tzqrzYnL0mZ6nCA9gjB0jczlc+rDuKdXJVjwAuI DptAhDg82fvjTrQTKvOyMB4/LM9wit+0EkEVhcIhQF0rXEcWqrbSaYWUv9S9hB8R7a wx3yeIq6zW58BxQMPjIohmI9JVI0RHgjHRHVtBYc= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails Date: Thu, 09 Apr 2020 08:47:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.0 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: Thu, 09 Apr 2020 08:47:38 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D93369 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenth at gcc dot gnu.org --- Comment #18 from Richard Biener --- So the resolution for PR64076 the testcase was added for was "similar" as in short-cut an assert with !in_lto_p.(In reply to Jan Hubicka from comment #1= 5) > The testcase has an ODR violation that makes comdat groups go out of sync. > So I guess it is just about finding way to not make verifier to ICE. > With release settings the testcase will however quietly compile this I do > not think this is release blocker (P1). Huh, the testcase failure mode is a link-fail - remember the testcase has one object compiled with -fno-lto. It might be there's another bug in us ICEing when you LTO the whole thing and I'd agree that's more an ice-after-error and we should eventually make ODR violations error and simply give up after WPA. So - can you please see why the testcase fails to _link_? For reference this is what my testsuite log says: spawn -ignore SIGHUP /home/rguenther/obj/gcc/testsuite/g++/../../xg++ -B/home/rguenther/obj/gcc/testsuite/g++/../../ cp_lto_pr64076_0.o cp_lto_pr64076_1.o -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=3Dnever -fdiagnostics-urls=3Dnever -nostdinc++ -I/home/rguenther/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-li= nux-gnu -I/home/rguenther/obj/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/rguenther/src/trunk/libstdc++-v3/libsupc++ -I/home/rguenther/src/trunk/libstdc++-v3/include/backward -I/home/rguenther/src/trunk/libstdc++-v3/testsuite/util -fmessage-length=3D= 0 -O0 -flto -flto-partition=3Dnone -fuse-linker-plugin -L/home/rguenther/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/rguenther/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -L/home/rguenther/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/rguenther/obj/x86_64-pc-linux-gnu/./libitm/ -L/home/rguenther/obj/x86_64-pc-linux-gnu/./libitm/.libs -o g++-dg-lto-pr64076-01.exe^M /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: g++-dg-lto-pr64076-01.exe.lto.o:(.rodata+0x58): undefined reference to `non-virtual thunk to S::f()'^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 FAIL: g++.dg/lto/pr64076 cp_lto_pr64076_0.o-cp_lto_pr64076_1.o link, -O0 -f= lto -flto-partition=3Dnone -fuse-linker-plugin I guess the explanation is similar in the end - the wrong comdat wins? For a usual bugreport such report would be INVALID I guess. Now the issue is we have that testcase in our testsuite and the solution to PR64076. I suppose PR64076 would have ICEd when producing a shared object as well so that might be something we could do to alleivate the link failure? The testcase unfortunately doesn't reproduce the old issue anymore when reverting the fix. The question is of course also why appearantly the causing rev caused that symbol to be necessary. diff --git a/gcc/testsuite/g++.dg/lto/pr64076_0.C b/gcc/testsuite/g++.dg/lto/pr64076_0.C index fb9b060e323..57d0fd6a1c3 100644 --- a/gcc/testsuite/g++.dg/lto/pr64076_0.C +++ b/gcc/testsuite/g++.dg/lto/pr64076_0.C @@ -1,4 +1,8 @@ // { dg-lto-do link } +// { dg-lto-options { { -O0 -flto -shared -fPIC } } } +// { dg-require-effective-target fpic } +// { dg-require-effective-target shared } +// { dg-extra-ld-options "-shared" } #define XXX #include "pr64076.H" diff --git a/gcc/testsuite/g++.dg/lto/pr64076_1.C b/gcc/testsuite/g++.dg/lto/pr64076_1.C index 4bd00817b1d..c9c58b798ec 100644 --- a/gcc/testsuite/g++.dg/lto/pr64076_1.C +++ b/gcc/testsuite/g++.dg/lto/pr64076_1.C @@ -1,4 +1,4 @@ -// { dg-options -fno-lto } +// { dg-options "-fno-lto -fPIC" } #include "pr64076.H" fixes the testcase for me (and would be OK to me to resolve this P1). Other opinions?=