| Message ID | alpine.LNX.2.00.1209251700050.4063@zhemvz.fhfr.qr |
|---|---|
| State | New |
| Headers | show |
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?
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.
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.
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.
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));