Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Fri, Nov 14, 2014 at 2:19 AM, Richard Biener wrote: > On Fri, Nov 14, 2014 at 12:15 AM, H.J. Lu wrote: >> On Tue, Nov 11, 2014 at 8:02 AM, H.J. Lu wrote: >>> On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu wrote: On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener wrote: > On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek 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 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 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 >>> 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] : >>> Add $pic_flag for GCC. >>> (_LT_LANG_CXX_CONFIG) [linux] : >>> Likewise. >>> (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o. >>> * NEWS: Update. >>> >>> Signed-off-by: Ralf Wildenhues >>> >>> 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 wrote: > On Tue, Nov 11, 2014 at 8:02 AM, H.J. Lu wrote: >> On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu wrote: >>> On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener >>> wrote: On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek 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 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 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 >> 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] : >> Add $pic_flag for GCC. >> (_LT_LANG_CXX_CONFIG) [linux] : >> Likewise. >> (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o. >> * NEWS: Update. >> >> Signed-off-by: Ralf Wildenhues >> >> 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 wrote: > On Mon, Nov 10, 2014 at 11:42 AM, H.J. Lu wrote: >> On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener >> wrote: >>> On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek 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 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 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 > 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] : > Add $pic_flag for GCC. > (_LT_LANG_CXX_CONFIG) [linux] : > Likewise. > (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o. > * NEWS: Update. > > Signed-off-by: Ralf Wildenhues > > 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 wrote: > On Mon, Nov 10, 2014 at 5:44 AM, Richard Biener > wrote: >> On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek 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 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 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 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] : Add $pic_flag for GCC. (_LT_LANG_CXX_CONFIG) [linux] : Likewise. (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o. * NEWS: Update. Signed-off-by: Ralf Wildenhues OK to install? Thanks. -- H.J.
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Mon, Nov 10, 2014 at 12:16 PM, Markus Trippelsdorf wrote: > On 2014.11.10 at 12:05 -0800, H.J. Lu wrote: >> On Mon, Nov 10, 2014 at 11:57 AM, Markus Trippelsdorf >> wrote: >> > On 2014.11.10 at 11:43 -0800, H.J. Lu wrote: >> >> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek 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.
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 > wrote: > > On 2014.11.10 at 11:43 -0800, H.J. Lu wrote: > >> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek 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 11:57 AM, Markus Trippelsdorf wrote: > On 2014.11.10 at 11:43 -0800, H.J. Lu wrote: >> On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek 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 11:43 -0800, H.J. Lu wrote: > On Mon, Nov 10, 2014 at 6:24 AM, Jakub Jelinek 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 6:24 AM, Jakub Jelinek 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 Mon, Nov 10, 2014 at 5:44 AM, Richard Biener wrote: > On Mon, Nov 10, 2014 at 2:43 PM, Jakub Jelinek 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 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 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 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 2:43 PM, Jakub Jelinek 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 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 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 05:32:32AM -0800, H.J. Lu wrote: > On Mon, Nov 10, 2014 at 4:05 AM, Jakub Jelinek 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 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 4:05 AM, Jakub Jelinek 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 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 12:50:44PM +0100, Richard Biener wrote: > On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu 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
Re: PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
On Sun, Nov 9, 2014 at 5:46 PM, H.J. Lu 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
>
> PR bootstrap/63784
> * libtool.m4: Add $pic_flag with -shared.
>
> boehm-gc/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> gcc/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libatomic/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libbacktrace/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libcc1/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libcilkrts/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libffi/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libgfortran/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libgomp/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libitm/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libjava/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libjava/classpath/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libobjc/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libquadmath/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libsanitizer/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libssp/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libstdc++-v3/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> libvtv/
>
> 2014-11-09 H.J. Lu
>
> PR bootstrap/63784
> * configure: Regenerated.
>
> lto-plugin/
>
> 2014-11-09 H.J. Lu
>
> 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
> +
> + PR bootstrap/63784
> + * libtool.m4: Add $pic_flag with -shared.
> +
> 2014-10-31 Jakub Jelinek
>
> * 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
> +
> + PR bootstrap/63784
> + * configure: Regenerated.
> +
> 2014-10-23 Rainer Orth
>
> * 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 2>&1 | $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 $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
> -archive_expsym_cmds_CXX='$CC -shared -nostdlib $predep_objects
> $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname
> ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
> +archive_cm
PATCH: PR bootstrap/63784: [5 Regression] profiledbootstrap failure with bootstrap-lto
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.
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
PR bootstrap/63784
* libtool.m4: Add $pic_flag with -shared.
boehm-gc/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
gcc/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libatomic/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libbacktrace/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libcc1/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libcilkrts/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libffi/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libgfortran/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libgomp/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libitm/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libjava/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libjava/classpath/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libobjc/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libquadmath/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libsanitizer/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libssp/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libstdc++-v3/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
libvtv/
2014-11-09 H.J. Lu
PR bootstrap/63784
* configure: Regenerated.
lto-plugin/
2014-11-09 H.J. Lu
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
+
+ PR bootstrap/63784
+ * libtool.m4: Add $pic_flag with -shared.
+
2014-10-31 Jakub Jelinek
* 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
+
+ PR bootstrap/63784
+ * configure: Regenerated.
+
2014-10-23 Rainer Orth
* 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 2>&1 | $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 $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
-archive_expsym_cmds_CXX='$CC -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname
${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+archive_cmds_CXX='$CC $pic_flag -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o
$lib'
+archive_expsym_cmds_CXX='$CC $pic_flag -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
hardcode_libdir_flag_spec_CXX='${wl}-rpath ${wl}$libdir'
export_dynamic_flag_spec_CXX='${wl}--export-dynamic'
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 5ffc217..74da721 100644
--
