Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Fri, Nov 14, 2014 at 2:19 AM, Richard Biener richard.guent...@gmail.com wrote: On Fri, Nov 14, 2014 at 12:15 AM, H.J. Lu hjl.to...@gmail.com wrote: On Tue, Nov 11, 2014 at 8:02 AM, H.J. Lu hjl.to...@gmail.com wrote: On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu hjl.to...@gmail.com wrote: On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener richard.guent...@gmail.com wrote: On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu hongjiu...@intel.com wrote: Hi, r216964 disables bootstrap for libcc1 which exposed 2 things: 1. libcc1 isn't compiled with LTO even when GCC is configured with --with-build-config=bootstrap-lto. It may be intentional since libcc1 is disabled for bootstrap. 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is compiled with LTO which remembers PIC option. Why is this any special to LTO? If it is then it looks like a LTO (driver) issue to me? Why are we linking the pic libibterty into a non-pic libcc1? I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. There is nothing wrong with linker. It is a slm-lto bug in libtool. I uploaded a testcase at https://gcc.gnu.org/bugzilla/attachment.cgi?id=33931 My patch is a backport of libtool LTO support: commit b81fd4ef009c24a86a7e64727ea09efb410ea149 Author: Ralf Wildenhues ralf.wildenh...@gmx.de Date: Sun Aug 29 17:31:29 2010 +0200 Support GCC LTO on GNU/Linux. * libltdl/config/ltmain.m4sh (func_mode_link): Allow through flags matching -O*, -flto*, -fwhopr, -fuse-linker-plugin. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Drop symbols starting with __gnu_lto. (_LT_LINKER_SHLIBS) [linux] archive_cmds, archive_expsyms_cmds: Add $pic_flag for GCC. (_LT_LANG_CXX_CONFIG) [linux] archive_cmds, archive_expsyms_cmds: Likewise. (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o. * NEWS: Update. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de OK to install? Ping. Stage 1 will be closed tomorrow. I'd like to restore LTO bootstrap. Bugfixing is still possible after that date. I suppose you don't call LTO bootstrap a new feature ;) New LTO bugs have been introduced since LTO bootstrap was broken a few weeks ago. I'd like to check in this one so that we have a chance to prevent further damage. Any objects to backport this from libtool upstream? -- H.J.
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Fri, Nov 14, 2014 at 12:15 AM, H.J. Lu hjl.to...@gmail.com wrote: On Tue, Nov 11, 2014 at 8:02 AM, H.J. Lu hjl.to...@gmail.com wrote: On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu hjl.to...@gmail.com wrote: On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener richard.guent...@gmail.com wrote: On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu hongjiu...@intel.com wrote: Hi, r216964 disables bootstrap for libcc1 which exposed 2 things: 1. libcc1 isn't compiled with LTO even when GCC is configured with --with-build-config=bootstrap-lto. It may be intentional since libcc1 is disabled for bootstrap. 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is compiled with LTO which remembers PIC option. Why is this any special to LTO? If it is then it looks like a LTO (driver) issue to me? Why are we linking the pic libibterty into a non-pic libcc1? I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. There is nothing wrong with linker. It is a slm-lto bug in libtool. I uploaded a testcase at https://gcc.gnu.org/bugzilla/attachment.cgi?id=33931 My patch is a backport of libtool LTO support: commit b81fd4ef009c24a86a7e64727ea09efb410ea149 Author: Ralf Wildenhues ralf.wildenh...@gmx.de Date: Sun Aug 29 17:31:29 2010 +0200 Support GCC LTO on GNU/Linux. * libltdl/config/ltmain.m4sh (func_mode_link): Allow through flags matching -O*, -flto*, -fwhopr, -fuse-linker-plugin. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Drop symbols starting with __gnu_lto. (_LT_LINKER_SHLIBS) [linux] archive_cmds, archive_expsyms_cmds: Add $pic_flag for GCC. (_LT_LANG_CXX_CONFIG) [linux] archive_cmds, archive_expsyms_cmds: Likewise. (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o. * NEWS: Update. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de OK to install? Ping. Stage 1 will be closed tomorrow. I'd like to restore LTO bootstrap. Bugfixing is still possible after that date. I suppose you don't call LTO bootstrap a new feature ;) Richard. -- H.J.
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Tue, Nov 11, 2014 at 8:02 AM, H.J. Lu hjl.to...@gmail.com wrote: On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu hjl.to...@gmail.com wrote: On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener richard.guent...@gmail.com wrote: On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu hongjiu...@intel.com wrote: Hi, r216964 disables bootstrap for libcc1 which exposed 2 things: 1. libcc1 isn't compiled with LTO even when GCC is configured with --with-build-config=bootstrap-lto. It may be intentional since libcc1 is disabled for bootstrap. 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is compiled with LTO which remembers PIC option. Why is this any special to LTO? If it is then it looks like a LTO (driver) issue to me? Why are we linking the pic libibterty into a non-pic libcc1? I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. There is nothing wrong with linker. It is a slm-lto bug in libtool. I uploaded a testcase at https://gcc.gnu.org/bugzilla/attachment.cgi?id=33931 My patch is a backport of libtool LTO support: commit b81fd4ef009c24a86a7e64727ea09efb410ea149 Author: Ralf Wildenhues ralf.wildenh...@gmx.de Date: Sun Aug 29 17:31:29 2010 +0200 Support GCC LTO on GNU/Linux. * libltdl/config/ltmain.m4sh (func_mode_link): Allow through flags matching -O*, -flto*, -fwhopr, -fuse-linker-plugin. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Drop symbols starting with __gnu_lto. (_LT_LINKER_SHLIBS) [linux] archive_cmds, archive_expsyms_cmds: Add $pic_flag for GCC. (_LT_LANG_CXX_CONFIG) [linux] archive_cmds, archive_expsyms_cmds: Likewise. (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o. * NEWS: Update. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de OK to install? Ping. Stage 1 will be closed tomorrow. I'd like to restore LTO bootstrap. -- H.J.
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu hjl.to...@gmail.com wrote: On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener richard.guent...@gmail.com wrote: On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu hongjiu...@intel.com wrote: Hi, r216964 disables bootstrap for libcc1 which exposed 2 things: 1. libcc1 isn't compiled with LTO even when GCC is configured with --with-build-config=bootstrap-lto. It may be intentional since libcc1 is disabled for bootstrap. 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is compiled with LTO which remembers PIC option. Why is this any special to LTO? If it is then it looks like a LTO (driver) issue to me? Why are we linking the pic libibterty into a non-pic libcc1? I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. There is nothing wrong with linker. It is a slm-lto bug in libtool. I uploaded a testcase at https://gcc.gnu.org/bugzilla/attachment.cgi?id=33931 My patch is a backport of libtool LTO support: commit b81fd4ef009c24a86a7e64727ea09efb410ea149 Author: Ralf Wildenhues ralf.wildenh...@gmx.de Date: Sun Aug 29 17:31:29 2010 +0200 Support GCC LTO on GNU/Linux. * libltdl/config/ltmain.m4sh (func_mode_link): Allow through flags matching -O*, -flto*, -fwhopr, -fuse-linker-plugin. * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Drop symbols starting with __gnu_lto. (_LT_LINKER_SHLIBS) [linux] archive_cmds, archive_expsyms_cmds: Add $pic_flag for GCC. (_LT_LANG_CXX_CONFIG) [linux] archive_cmds, archive_expsyms_cmds: Likewise. (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o. * NEWS: Update. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de OK to install? Thanks. -- H.J.
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu hongjiu...@intel.com wrote: Hi, r216964 disables bootstrap for libcc1 which exposed 2 things: 1. libcc1 isn't compiled with LTO even when GCC is configured with --with-build-config=bootstrap-lto. It may be intentional since libcc1 is disabled for bootstrap. 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is compiled with LTO which remembers PIC option. Why is this any special to LTO? If it is then it looks like a LTO (driver) issue to me? Why are we linking the pic libibterty into a non-pic libcc1? Richard. libiberty is bootstrapped with LTO. When libcc1 isn't compiled with LTO, we are creating libcc1.so without -fPIC, which leads to linker failure when linking with slim-lto libiberty. This patch from https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00991.html adds -fPIC to -shared so that -fPIC is always used to create shared object. Tested on Linux/x86-64. OK for trunk? Thanks. H.J. --- 2014-11-09 Markus Trippelsdorf mar...@trippelsdorf.de PR bootstrap/63784 * libtool.m4: Add $pic_flag with -shared. boehm-gc/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. gcc/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libatomic/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libbacktrace/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libcc1/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libcilkrts/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libffi/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libgfortran/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libgomp/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libitm/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libjava/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libjava/classpath/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libobjc/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libquadmath/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libsanitizer/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libssp/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libstdc++-v3/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. libvtv/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. lto-plugin/ 2014-11-09 H.J. Lu hongjiu...@intel.com PR bootstrap/63784 * configure: Regenerated. diff --git a/ChangeLog b/ChangeLog index 5c7f649..25bc026 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2014-11-09 Markus Trippelsdorf mar...@trippelsdorf.de + + PR bootstrap/63784 + * libtool.m4: Add $pic_flag with -shared. + 2014-10-31 Jakub Jelinek ja...@redhat.com * Makefile.def (libcc1): Remove bootstrap=true;. diff --git a/boehm-gc/ChangeLog b/boehm-gc/ChangeLog index 1c8cbda..7a2750f 100644 --- a/boehm-gc/ChangeLog +++ b/boehm-gc/ChangeLog @@ -1,3 +1,8 @@ +2014-11-09 H.J. Lu hongjiu...@intel.com + + PR bootstrap/63784 + * configure: Regenerated. + 2014-10-23 Rainer Orth r...@cebitec.uni-bielefeld.de * include/gc.h [(sparc || __sparc) sun] (GC_INIT): Remove diff --git a/boehm-gc/configure b/boehm-gc/configure index 025003c..efaf7b8 100755 --- a/boehm-gc/configure +++ b/boehm-gc/configure @@ -9081,7 +9081,7 @@ _LT_EOF if $LD --help 21 | $EGREP ': supported targets:.* elf' /dev/null \ test $tmp_diet = no then - tmp_addflag= + tmp_addflag=' $pic_flag' tmp_sharedflag='-shared' case $cc_basename,$host_cpu in pgcc*) # Portland Group C compiler @@ -12019,8 +12019,8 @@ with_gnu_ld=$lt_cv_prog_gnu_ld # Check if GNU C++ uses GNU ld as the underlying linker, since the # archiving commands below assume that GNU ld is being used. if test $with_gnu_ld = yes; then -archive_cmds_CXX='$CC -shared -nostdlib $predep_objects $libobjs $deplibs
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu hongjiu...@intel.com wrote: Hi, r216964 disables bootstrap for libcc1 which exposed 2 things: 1. libcc1 isn't compiled with LTO even when GCC is configured with --with-build-config=bootstrap-lto. It may be intentional since libcc1 is disabled for bootstrap. 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is compiled with LTO which remembers PIC option. Why is this any special to LTO? If it is then it looks like a LTO (driver) issue to me? Why are we linking the pic libibterty into a non-pic libcc1? I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: /bin/sh ./libtool --tag=CXX --mode=link /export/project/git/gcc-regression-bootstrap/master/216981/bld/./gcc/xg++ -B/export/project/git/gcc-regression-bootstrap/master/216981/bld/./gcc/ -nostdinc++ `if test -f /export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags; then /bin/sh /export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags --build-includes; else echo -funconfigured-libstdc++-v3 ; fi` -L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/bin/ -B/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/lib/ -isystem /export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/include -isystem /export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/sys-include -W -Wall -fvisibility=hidden -g -O2 -D_GNU_SOURCE -module -export-symbols /export/project/git/gcc-regression/gcc/libcc1/libcc1.sym -Xcompiler '-static-libstdc++' -Xcompiler '-static-libgcc' -o libcc1.la -rpath /export/project/git/gcc-regression-bootstrap/master/216981/usr/lib/../lib64 findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo marshall.lo -Wc,../libiberty/pic/libiberty.a There are no -fPIC nor any other options, like -O2. Since *.lo aren't compiled with LTO and libiberty/pic/libiberty.a is compiled with LTO, linker uses libtool command line to compile libiberty/pic/libiberty.a LTO IR into regular object. Since libtool command line doesn't have -fPIC, it fails to create shared object. Since it doesn't have -O2, it isn't optimized and misses other options. Both ld and gold pull the compiler options from the first .o file with LTO IR. We can argue if linker should pull compiler option from the first LTO IR in .o and .a. But it doesn't happen today and may not be desirable at all. -- H.J.
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu hongjiu...@intel.com wrote: Hi, r216964 disables bootstrap for libcc1 which exposed 2 things: 1. libcc1 isn't compiled with LTO even when GCC is configured with --with-build-config=bootstrap-lto. It may be intentional since libcc1 is disabled for bootstrap. 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is compiled with LTO which remembers PIC option. Why is this any special to LTO? If it is then it looks like a LTO (driver) issue to me? Why are we linking the pic libibterty into a non-pic libcc1? I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. Jakub
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu hongjiu...@intel.com wrote: Hi, r216964 disables bootstrap for libcc1 which exposed 2 things: 1. libcc1 isn't compiled with LTO even when GCC is configured with --with-build-config=bootstrap-lto. It may be intentional since libcc1 is disabled for bootstrap. 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is compiled with LTO which remembers PIC option. Why is this any special to LTO? If it is then it looks like a LTO (driver) issue to me? Why are we linking the pic libibterty into a non-pic libcc1? I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. Richard. Jakub
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote: I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after $(HOST_EXPORTS) to the libcc1 rules iff the libcc1 module is built by the newly built bootstrapped compiler (but not when the compiler is not bootstrapped and thus it is built by the host compiler), because if we first bootstrap the compiler and build libcc1 by stage3, it is really post-stage1 building. Paolo, any thoughts how to arrange that? Jakub
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener richard.guent...@gmail.com wrote: On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 05:32:32AM -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 12:50:44PM +0100, Richard Biener wrote: On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu hongjiu...@intel.com wrote: Hi, r216964 disables bootstrap for libcc1 which exposed 2 things: 1. libcc1 isn't compiled with LTO even when GCC is configured with --with-build-config=bootstrap-lto. It may be intentional since libcc1 is disabled for bootstrap. 2. -fPIC isn't used to created libcc1.so, which is OK if libcc1 is compiled with LTO which remembers PIC option. Why is this any special to LTO? If it is then it looks like a LTO (driver) issue to me? Why are we linking the pic libibterty into a non-pic libcc1? I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. There is nothing wrong with linker. It is a slm-lto bug in libtool. I uploaded a testcase at https://gcc.gnu.org/bugzilla/attachment.cgi?id=33931 -- H.J.
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote: I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after $(HOST_EXPORTS) to the libcc1 rules iff the libcc1 module is built by the newly built bootstrapped compiler (but not when the compiler is not bootstrapped and thus it is built by the host compiler), because if we first bootstrap the compiler and build libcc1 by stage3, it is really post-stage1 building. It doesn't help. The problem is the missing -fPIC when libtool calls g+++ to create the shared object. My patch fixes it. -- H.J.
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On 2014.11.10 at 11:43 -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote: I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after $(HOST_EXPORTS) to the libcc1 rules iff the libcc1 module is built by the newly built bootstrapped compiler (but not when the compiler is not bootstrapped and thus it is built by the host compiler), because if we first bootstrap the compiler and build libcc1 by stage3, it is really post-stage1 building. It doesn't help. The problem is the missing -fPIC when libtool calls g+++ to create the shared object. My patch fixes it. But wouldn't it be better to update to a more recent libtool version instead of adding hack upon hack? This would also allow bootstrap-lto without the need of the gcc-ar (, etc.) wrappers. And you are one of the very few persons who could handle such an update. -- Markus
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2014.11.10 at 11:43 -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote: I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after $(HOST_EXPORTS) to the libcc1 rules iff the libcc1 module is built by the newly built bootstrapped compiler (but not when the compiler is not bootstrapped and thus it is built by the host compiler), because if we first bootstrap the compiler and build libcc1 by stage3, it is really post-stage1 building. It doesn't help. The problem is the missing -fPIC when libtool calls g+++ to create the shared object. My patch fixes it. But wouldn't it be better to update to a more recent libtool version instead of adding hack upon hack? Hack is safer than the newer libtool :-(. A new libtool needs to be verified on all hosts for all targets. This would also allow bootstrap-lto without the need of the gcc-ar (, etc.) wrappers. And you are one of the very few persons who could handle such an update. What did you mean by you? -- H.J.
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On 2014.11.10 at 12:05 -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2014.11.10 at 11:43 -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote: I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after $(HOST_EXPORTS) to the libcc1 rules iff the libcc1 module is built by the newly built bootstrapped compiler (but not when the compiler is not bootstrapped and thus it is built by the host compiler), because if we first bootstrap the compiler and build libcc1 by stage3, it is really post-stage1 building. It doesn't help. The problem is the missing -fPIC when libtool calls g+++ to create the shared object. My patch fixes it. But wouldn't it be better to update to a more recent libtool version instead of adding hack upon hack? Hack is safer than the newer libtool :-(. A new libtool needs to be verified on all hosts for all targets. Well, perhaps now is the right time to do it, because there would be enough time to fix any fallout. This would also allow bootstrap-lto without the need of the gcc-ar (, etc.) wrappers. And you are one of the very few persons who could handle such an update. What did you mean by you? I mean that since Ralf Wildenhues dropped from the scene, you (H.J.) are one of the few people who could handle a libtool update across the different trees (gcc, binutils, etc.). -- Markus
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 12:16 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2014.11.10 at 12:05 -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2014.11.10 at 11:43 -0800, H.J. Lu wrote: On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Nov 10, 2014 at 02:44:55PM +0100, Richard Biener wrote: I admit I haven't tried LTO bootstrap, but from normal bootstrap logs, libcc1 is built normally using libtool using -fPIC only, and linked into libcc1.so.0.0.0 and libcc1plugin.so.0.0.0, and of course against the pic/libiberty.a, because we need PIC code in the shared libraries. So, I don't understand the change at all. Jakub This is the command line to build libcc1.la: Sure, but there was -fPIC used to compile all the *.o files that are being linked into libcc1.so, so LTO should know that. And it does. If not please file a bug with a smaller testcase than libcc1 and libiberty. Ah, supposedly we should add $(POSTSTAGE1_HOST_EXPORTS) after $(HOST_EXPORTS) to the libcc1 rules iff the libcc1 module is built by the newly built bootstrapped compiler (but not when the compiler is not bootstrapped and thus it is built by the host compiler), because if we first bootstrap the compiler and build libcc1 by stage3, it is really post-stage1 building. It doesn't help. The problem is the missing -fPIC when libtool calls g+++ to create the shared object. My patch fixes it. But wouldn't it be better to update to a more recent libtool version instead of adding hack upon hack? Hack is safer than the newer libtool :-(. A new libtool needs to be verified on all hosts for all targets. Well, perhaps now is the right time to do it, because there would be enough time to fix any fallout. This would also allow bootstrap-lto without the need of the gcc-ar (, etc.) wrappers. And you are one of the very few persons who could handle such an update. What did you mean by you? I mean that since Ralf Wildenhues dropped from the scene, you (H.J.) are one of the few people who could handle a libtool update across the different trees (gcc, binutils, etc.). I can handle binutils. But it takes a LONG time for GCC build changes to be reviewed. I try to avoid it as much as I can :-). -- H.J.
