Patchwork Fix PR54702 and LTO bootstrap (for me)

login
register
mail settings
Submitter Richard Guenther
Date Sept. 25, 2012, 3 p.m.
Message ID <alpine.LNX.2.00.1209251700050.4063@zhemvz.fhfr.qr>
Download mbox | patch
Permalink /patch/186835/
State New
Headers show

Comments

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;
+ }
+
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

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));