Fix PR54702 and LTO bootstrap (for me)

Submitted by Richard Guenther on Sept. 25, 2012, 3 p.m.

Details

Message ID alpine.LNX.2.00.1209251700050.4063@zhemvz.fhfr.qr
State New
Headers show

Commit Message

Richard Guenther Sept. 25, 2012, 3 p.m.
On Tue, 25 Sep 2012, Richard Guenther wrote:

> 
> This fixes PR54702 and LTO bootstrap (well, at least I now survive
> stage2 cc1 build).  We shouldn't enter builtins into the symtab
> asm-name hash, too much code seems to be confused by that (at least
> we should at most insert builtins with a set assembler name).
> 
> Smells somewhat LTO-ish, but well.

And breaks regular build.  The following fixes PR54625 and this one
and passes bootstrap & regtest.

Committed.

Richard.
2012-09-25  Richard Guenther  <rguenther@suse.de>

	PR lto/54625
	* lto-symtab.c (lto_symtab_merge_cgraph_nodes_1): Do not merge
	cgraph nodes for builtins.

	* gcc.dg/lto/pr54702_0.c: New testcase.
	* gcc.dg/lto/pr54702_1.c: Likewise.
	* gcc.dg/lto/pr54625-1_0.c: Likewise.
	* gcc.dg/lto/pr54625-1_1.C: Likewise.
	* gcc.dg/lto/pr54625-2_0.c: Likewise.
	* gcc.dg/lto/pr54625-2_1.C: Likewise.

Index: gcc/testsuite/gcc.dg/lto/pr54702_0.c
===================================================================
*** gcc/testsuite/gcc.dg/lto/pr54702_0.c	(revision 0)
--- gcc/testsuite/gcc.dg/lto/pr54702_0.c	(working copy)
***************
*** 0 ****
--- 1,10 ----
+ /* { dg-lto-do link } */
+ /* { dg-lto-options { { -O2 -flto -w } } } */
+ /* { dg-extra-ld-options { -r -nostdlib } } */
+ 
+ #include <stdlib.h>
+ void* f ()
+ {
+   void* p = malloc (1);
+   return p;
+ }
Index: gcc/testsuite/gcc.dg/lto/pr54702_1.c
===================================================================
*** gcc/testsuite/gcc.dg/lto/pr54702_1.c	(revision 0)
--- gcc/testsuite/gcc.dg/lto/pr54702_1.c	(working copy)
***************
*** 0 ****
--- 1,16 ----
+ int *b;
+ void *d;
+ int c;
+ static int *f1 ();
+ void f2 ()
+ {
+   int *a = f1 (0);
+ }
+ 
+ int *f1 (j)
+ {
+   b = malloc (0);
+   d = *malloc;
+   c = j;
+ }
+

Comments

Mike Stump Oct. 15, 2013, 12:05 a.m.
On Sep 25, 2012, at 8:00 AM, Richard Guenther <rguenther@suse.de> wrote:
> 2012-09-25  Richard Guenther  <rguenther@suse.de>
> 
> 	PR lto/54625
> 	* lto-symtab.c (lto_symtab_merge_cgraph_nodes_1): Do not merge
> 	cgraph nodes for builtins.
> 
> 	* gcc.dg/lto/pr54702_0.c: New testcase.
> 	* gcc.dg/lto/pr54702_1.c: Likewise.
> 	* gcc.dg/lto/pr54625-1_0.c: Likewise.
> 	* gcc.dg/lto/pr54625-1_1.C: Likewise.
> 	* gcc.dg/lto/pr54625-2_0.c: Likewise.
> 	* gcc.dg/lto/pr54625-2_1.C: Likewise.


xgcc: error: /home/mrs/wg/gcc/gcc/testsuite/gcc.dg/lto/pr54625-2_1.C: C++ compiler not installed on this system

FAIL: gcc.dg/lto/pr54625-2 c_lto_pr54625-2_1.o assemble, -O2 -flto -fuse-linker-plugin

shouldn't C++ testcases go into the C++ testsuite?
Richard Guenther Oct. 15, 2013, 7:45 a.m.
On Mon, 14 Oct 2013, Mike Stump wrote:

> On Sep 25, 2012, at 8:00 AM, Richard Guenther <rguenther@suse.de> wrote:
> > 2012-09-25  Richard Guenther  <rguenther@suse.de>
> > 
> > 	PR lto/54625
> > 	* lto-symtab.c (lto_symtab_merge_cgraph_nodes_1): Do not merge
> > 	cgraph nodes for builtins.
> > 
> > 	* gcc.dg/lto/pr54702_0.c: New testcase.
> > 	* gcc.dg/lto/pr54702_1.c: Likewise.
> > 	* gcc.dg/lto/pr54625-1_0.c: Likewise.
> > 	* gcc.dg/lto/pr54625-1_1.C: Likewise.
> > 	* gcc.dg/lto/pr54625-2_0.c: Likewise.
> > 	* gcc.dg/lto/pr54625-2_1.C: Likewise.
> 
> 
> xgcc: error: /home/mrs/wg/gcc/gcc/testsuite/gcc.dg/lto/pr54625-2_1.C: C++ compiler not installed on this system
> 
> FAIL: gcc.dg/lto/pr54625-2 c_lto_pr54625-2_1.o assemble, -O2 -flto -fuse-linker-plugin
> 
> shouldn't C++ testcases go into the C++ testsuite?

Well ... this is a mixed C / C++ testcase (see the other file 
participating, gcc.dg/lto/pr54625-2_0.c).  The C testsuite is the only
one where the driver switches languages based on the file ending.

Hmm, it seems at least the fortran frontend knows how to mix fortran
and C.

So if you really did not build the C++ compiler then we need, at least
for lto.exp, a way to say dg-require-c++-frontend in the main file
(thats the _0 one).  Of course lto.exp misses a lot of other useful
stuff ;)

Btw, can we end up with the C frontend not built?

Richard.
Mike Stump Oct. 15, 2013, 8:47 p.m.
On Oct 15, 2013, at 12:45 AM, Richard Biener <rguenther@suse.de> wrote:
> On Mon, 14 Oct 2013, Mike Stump wrote:
>> On Sep 25, 2012, at 8:00 AM, Richard Guenther <rguenther@suse.de> wrote:
>>> 2012-09-25  Richard Guenther  <rguenther@suse.de>
>>> 
>>> 	PR lto/54625
>>> 	* lto-symtab.c (lto_symtab_merge_cgraph_nodes_1): Do not merge
>>> 	cgraph nodes for builtins.
>>> 
>>> 	* gcc.dg/lto/pr54702_0.c: New testcase.
>>> 	* gcc.dg/lto/pr54702_1.c: Likewise.
>>> 	* gcc.dg/lto/pr54625-1_0.c: Likewise.
>>> 	* gcc.dg/lto/pr54625-1_1.C: Likewise.
>>> 	* gcc.dg/lto/pr54625-2_0.c: Likewise.
>>> 	* gcc.dg/lto/pr54625-2_1.C: Likewise.
>> 
>> 
>> xgcc: error: /home/mrs/wg/gcc/gcc/testsuite/gcc.dg/lto/pr54625-2_1.C: C++ compiler not installed on this system
>> 
>> FAIL: gcc.dg/lto/pr54625-2 c_lto_pr54625-2_1.o assemble, -O2 -flto -fuse-linker-plugin
>> 
>> shouldn't C++ testcases go into the C++ testsuite?
> 
> Well ... this is a mixed C / C++ testcase (see the other file 
> participating, gcc.dg/lto/pr54625-2_0.c).  The C testsuite is the only
> one where the driver switches languages based on the file ending.

That is an interesting inquiry, but, doesn't lead to the error.  Not sure exactly why you bring it up:

From a random C++ test suite run:

spawn /home/mrs/work2/gcc-port/gcc/xgcc -B/home/mrs/work2/gcc-port/gcc/ -fno-diagnostics-show-caret -O0 -flto -flto-partition=none -fuse-linker-plugin -DNO_TRAMPOLINES -c -DNO_TRAMPOLINES -o cp_lto_20100603-1_1.o /home/mrs/work2/gcc/gcc/testsuite/g++.dg/lto/20100603-1_1.c

here, we see that xgcc is used to build a C part of a mix language testcase in the C++ test suite.

If you follow that style, is there some reason why it won't just work as you want?

> Hmm, it seems at least the fortran frontend knows how to mix fortran
> and C.

And the fortran/c test cases are in the fortran test suite.

> So if you really did not build the C++ compiler then we need,

Yup, no C++ compiler.

> at least for lto.exp, a way to say dg-require-c++-frontend in the main file
> (thats the _0 one).

Why do that?

> Btw, can we end up with the C frontend not built?

I'v never contemplated that idea…  but no, c is automatically added in order I suppose, to build the language independent runtime (libgcc) with.
Richard Guenther Oct. 16, 2013, 8:11 a.m.
On Tue, 15 Oct 2013, Mike Stump wrote:

> On Oct 15, 2013, at 12:45 AM, Richard Biener <rguenther@suse.de> wrote:
> > On Mon, 14 Oct 2013, Mike Stump wrote:
> >> On Sep 25, 2012, at 8:00 AM, Richard Guenther <rguenther@suse.de> wrote:
> >>> 2012-09-25  Richard Guenther  <rguenther@suse.de>
> >>> 
> >>> 	PR lto/54625
> >>> 	* lto-symtab.c (lto_symtab_merge_cgraph_nodes_1): Do not merge
> >>> 	cgraph nodes for builtins.
> >>> 
> >>> 	* gcc.dg/lto/pr54702_0.c: New testcase.
> >>> 	* gcc.dg/lto/pr54702_1.c: Likewise.
> >>> 	* gcc.dg/lto/pr54625-1_0.c: Likewise.
> >>> 	* gcc.dg/lto/pr54625-1_1.C: Likewise.
> >>> 	* gcc.dg/lto/pr54625-2_0.c: Likewise.
> >>> 	* gcc.dg/lto/pr54625-2_1.C: Likewise.
> >> 
> >> 
> >> xgcc: error: /home/mrs/wg/gcc/gcc/testsuite/gcc.dg/lto/pr54625-2_1.C: C++ compiler not installed on this system
> >> 
> >> FAIL: gcc.dg/lto/pr54625-2 c_lto_pr54625-2_1.o assemble, -O2 -flto -fuse-linker-plugin
> >> 
> >> shouldn't C++ testcases go into the C++ testsuite?
> > 
> > Well ... this is a mixed C / C++ testcase (see the other file 
> > participating, gcc.dg/lto/pr54625-2_0.c).  The C testsuite is the only
> > one where the driver switches languages based on the file ending.
> 
> That is an interesting inquiry, but, doesn't lead to the error.  Not sure exactly why you bring it up:
> 
> From a random C++ test suite run:
> 
> spawn /home/mrs/work2/gcc-port/gcc/xgcc -B/home/mrs/work2/gcc-port/gcc/ -fno-diagnostics-show-caret -O0 -flto -flto-partition=none -fuse-linker-plugin -DNO_TRAMPOLINES -c -DNO_TRAMPOLINES -o cp_lto_20100603-1_1.o /home/mrs/work2/gcc/gcc/testsuite/g++.dg/lto/20100603-1_1.c
> 
> here, we see that xgcc is used to build a C part of a mix language testcase in the C++ test suite.
> 
> If you follow that style, is there some reason why it won't just work as you want?
> 
> > Hmm, it seems at least the fortran frontend knows how to mix fortran
> > and C.
> 
> And the fortran/c test cases are in the fortran test suite.
> 
> > So if you really did not build the C++ compiler then we need,
> 
> Yup, no C++ compiler.
> 
> > at least for lto.exp, a way to say dg-require-c++-frontend in the main file
> > (thats the _0 one).
> 
> Why do that?
> 
> > Btw, can we end up with the C frontend not built?
> 
> I'v never contemplated that idea?  but no, c is automatically added in order I suppose, to build the language independent runtime (libgcc) with.

I suppose it's fine to move the testcase to the C++ lto testsuite
if you verify it will use the C compiler for the C parts.

Thanks,
Richard.

Patch hide | download patch | download mbox

Index: gcc/testsuite/gcc.dg/lto/pr54625-1_0.c
===================================================================
--- gcc/testsuite/gcc.dg/lto/pr54625-1_0.c	(revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr54625-1_0.c	(working copy)
@@ -0,0 +1,10 @@ 
+/* { dg-lto-do link } */
+/* { dg-extra-ld-options { -r -nostdlib } } */
+
+float a;
+double sin ();
+speex_resampler_init_frac ()
+{
+  a = sin (0);
+}
+
Index: gcc/testsuite/gcc.dg/lto/pr54625-1_1.C
===================================================================
--- gcc/testsuite/gcc.dg/lto/pr54625-1_1.C	(revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr54625-1_1.C	(working copy)
@@ -0,0 +1,19 @@ 
+extern "C" double sin (double);
+typedef double UnaryFunType (double);
+class A
+{
+public:
+  int hash ();
+  double lookup (UnaryFunType p1)
+    {
+      int a = hash ();
+      if (p1)
+	return 0;
+    }
+};
+A b;
+void
+math_sin_impl ()
+{
+  b.lookup (sin);
+}
Index: gcc/testsuite/gcc.dg/lto/pr54625-2_0.c
===================================================================
--- gcc/testsuite/gcc.dg/lto/pr54625-2_0.c	(revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr54625-2_0.c	(working copy)
@@ -0,0 +1,9 @@ 
+/* { dg-lto-do link } */
+/* { dg-extra-ld-options { -r -nostdlib } } */
+
+float a;
+double sin ();
+update_filter ()
+{
+  a = sin (0);
+}
Index: gcc/testsuite/gcc.dg/lto/pr54625-2_1.C
===================================================================
--- gcc/testsuite/gcc.dg/lto/pr54625-2_1.C	(revision 0)
+++ gcc/testsuite/gcc.dg/lto/pr54625-2_1.C	(working copy)
@@ -0,0 +1,24 @@ 
+extern "C" double sin (double);
+typedef double (*UnaryFunType) (double);
+class A
+{
+public:
+  int hash ();
+  void lookup (UnaryFunType p1)
+    {
+      int a = hash ();
+      p1 (0);
+    }
+};
+A b, c;
+void
+math_sin_impl ()
+{
+  b.lookup (sin);
+}
+
+void
+js_math_sqrt ()
+{
+  c.lookup (0);
+}
Index: gcc/lto-symtab.c
===================================================================
--- gcc/lto-symtab.c	(revision 191700)
+++ gcc/lto-symtab.c	(working copy)
@@ -629,7 +629,8 @@  lto_symtab_merge_cgraph_nodes_1 (symtab_
 
       if (!symtab_real_symbol_p (e))
 	continue;
-      if (symtab_function_p (e))
+      if (symtab_function_p (e)
+	  && !DECL_BUILT_IN (e->symbol.decl))
 	lto_cgraph_replace_node (cgraph (e), cgraph (prevailing));
       if (symtab_variable_p (e))
 	lto_varpool_replace_node (varpool (e), varpool (prevailing));