[Bug ipa/93369] [10 regression] g++.dg/lto/pr64076 fails

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93369

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 #15)
> 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=never
-fdiagnostics-urls=never -nostdinc++
-I/home/rguenther/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-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=0 -O0
-flto -flto-partition=none -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 -flto
-flto-partition=none -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?