| Message ID | 20110110070111.GC24102@gmx.de |
|---|---|
| State | New |
| Headers | show |
On 01/10/2011 08:01 AM, Ralf Wildenhues wrote: > Basically I'm asking for advice/opinions what to do with this. > Apply to a temporary branch and suggest people to test it? Apply > to trunk, put on my flame suit and hope hell doesn't break loose? > Wait until after branching and backport from trunk to branch after > some testing period? That's too far away. > To put things into perspective: this does fix a number of bugs > reported over the last weeks and months, but AFAIK no P1 or P2 > regressions. It should allow to build GCC with LTO (but for > parallel linking to work Automake changes would still be needed). I'll leave it to the RM. Certainly it sounds like good changes, but can you make a list of PRs that are fixed? Paolo
On Mon, Jan 10, 2011 at 9:12 AM, Paolo Bonzini <bonzini@gnu.org> wrote: > On 01/10/2011 08:01 AM, Ralf Wildenhues wrote: >> >> Basically I'm asking for advice/opinions what to do with this. >> Apply to a temporary branch and suggest people to test it? Apply >> to trunk, put on my flame suit and hope hell doesn't break loose? >> Wait until after branching and backport from trunk to branch after >> some testing period? > > That's too far away. > >> To put things into perspective: this does fix a number of bugs >> reported over the last weeks and months, but AFAIK no P1 or P2 >> regressions. It should allow to build GCC with LTO (but for >> parallel linking to work Automake changes would still be needed). > > I'll leave it to the RM. Certainly it sounds like good changes, but can you > make a list of PRs that are fixed? I'd rather have it on trunk immediately. If we want it at all or not I have no idea (because I have no idea what the pros are). If it doesn't fix a bug for a primary or secondary host/target we definitely don't want it at this stage (thus wait for 4.7 and do no backporting either). Thanks, Richard.
On Mon, Jan 10, 2011 at 15:55, Richard Guenther <richard.guenther@gmail.com> wrote: > On Mon, Jan 10, 2011 at 9:12 AM, Paolo Bonzini <bonzini@gnu.org> wrote: >> On 01/10/2011 08:01 AM, Ralf Wildenhues wrote: >>> >>> Basically I'm asking for advice/opinions what to do with this. >>> Apply to a temporary branch and suggest people to test it? Apply >>> to trunk, put on my flame suit and hope hell doesn't break loose? >>> Wait until after branching and backport from trunk to branch after >>> some testing period? >> >> That's too far away. >> >>> To put things into perspective: this does fix a number of bugs >>> reported over the last weeks and months, but AFAIK no P1 or P2 >>> regressions. It should allow to build GCC with LTO (but for >>> parallel linking to work Automake changes would still be needed). >> >> I'll leave it to the RM. Certainly it sounds like good changes, but can you >> make a list of PRs that are fixed? > > I'd rather have it on trunk immediately. If we want it at all or not > I have no idea (because I have no idea what the pros are). The main pro is that allowing to build GCC with LTO "sounds as" if it would give more exposure/coverage to new features. But without a list of PRs from Ralf I cannot really judge either. Paolo
On Mon, Jan 10, 2011 at 4:16 PM, Paolo Bonzini <bonzini@gnu.org> wrote: > On Mon, Jan 10, 2011 at 15:55, Richard Guenther > <richard.guenther@gmail.com> wrote: >> On Mon, Jan 10, 2011 at 9:12 AM, Paolo Bonzini <bonzini@gnu.org> wrote: >>> On 01/10/2011 08:01 AM, Ralf Wildenhues wrote: >>>> >>>> Basically I'm asking for advice/opinions what to do with this. >>>> Apply to a temporary branch and suggest people to test it? Apply >>>> to trunk, put on my flame suit and hope hell doesn't break loose? >>>> Wait until after branching and backport from trunk to branch after >>>> some testing period? >>> >>> That's too far away. >>> >>>> To put things into perspective: this does fix a number of bugs >>>> reported over the last weeks and months, but AFAIK no P1 or P2 >>>> regressions. It should allow to build GCC with LTO (but for >>>> parallel linking to work Automake changes would still be needed). >>> >>> I'll leave it to the RM. Certainly it sounds like good changes, but can you >>> make a list of PRs that are fixed? >> >> I'd rather have it on trunk immediately. If we want it at all or not >> I have no idea (because I have no idea what the pros are). > > The main pro is that allowing to build GCC with LTO "sounds as" if it > would give more exposure/coverage to new features. But without a list > of PRs from Ralf I cannot really judge either. Hm, but LTO bootstrap works for me right now. Or is this about things like installing a static libgfortran with LTO bytecode (the only other useful LTO related thing when building GCC)? Richard. > Paolo >
* Richard Guenther wrote on Mon, Jan 10, 2011 at 04:24:49PM CET: > On Mon, Jan 10, 2011 at 4:16 PM, Paolo Bonzini <bonzini@gnu.org> wrote: > > On Mon, Jan 10, 2011 at 15:55, Richard Guenther > > <richard.guenther@gmail.com> wrote: > >> On Mon, Jan 10, 2011 at 9:12 AM, Paolo Bonzini <bonzini@gnu.org> wrote: > >>> > >>> I'll leave it to the RM. Certainly it sounds like good changes, but can you > >>> make a list of PRs that are fixed? > >> > >> I'd rather have it on trunk immediately. If we want it at all or not > >> I have no idea (because I have no idea what the pros are). > > > > The main pro is that allowing to build GCC with LTO "sounds as" if it > > would give more exposure/coverage to new features. But without a list > > of PRs from Ralf I cannot really judge either. > > Hm, but LTO bootstrap works for me right now. Or is this about > things like installing a static libgfortran with LTO bytecode (the only > other useful LTO related thing when building GCC)? Well, current in-tree libtool will not pass -flto*, -fwhopr*, or -fuse-linker-plugin through to the linker, when creating a shared library. It "works" in the way that the build succeeds, but it doesn't expose the feature one would like to see. I must say that the last time I did a full LTO test with earlier versions of the patch were a while ago, though. Most other issues are not even listed as PRs: - linking/testing/installing on HP-UX should work again <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00893.html>, - no more $LINENO-related spurious diffs in configure scripts, - cache variables are used throughout the Libtool macros, which will hopefully make it easier for users to work around any remaining GCC_NO_EXECUTABLES-induced configure failures stemming from those macros, see e.g., parts of the discussion in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174 or these threads http://gcc.gnu.org/ml/gcc/2010-12/msg00074.html http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00317.html - support for Go (exploiting that would be part of a followup patch to update Libtool in libgo), - building on MSYS or Cygwin with tools from the respective other w32 system should mostly work (not sure if that is relevant for GCC, these issues were all reported to upstream Libtool only). Cheers, Ralf
diff --git a/libtool.m4 b/libtool.m4 index fd79dcf..f111c79 100644 --- a/libtool.m4 +++ b/libtool.m4 @@ -1213,33 +1213,8 @@ _LT_DECL([], [ECHO], [1], [An echo program that protects backslashes]) # _LT_WITH_SYSROOT # ---------------- AC_DEFUN([_LT_WITH_SYSROOT], -[AC_MSG_CHECKING([for sysroot]) -AC_ARG_WITH([sysroot], -[ --with-sysroot[=DIR] Search for dependent libraries within DIR - (or the compiler's sysroot if not specified).], -[], [with_sysroot=no]) - -dnl lt_sysroot will always be passed unquoted. We quote it here -dnl in case the user passed a directory name. +[ # Disabled for now. lt_sysroot= -case ${with_sysroot} in #( - yes) - if test "$GCC" = yes; then - lt_sysroot=`$CC --print-sysroot 2>/dev/null` - fi - ;; #( - /*) - lt_sysroot=`echo "$with_sysroot" | sed -e "$sed_quote_subst"` - ;; #( - no|'') - ;; #( - *) - AC_MSG_RESULT([${with_sysroot}]) - AC_MSG_ERROR([The sysroot must be an absolute path.]) - ;; -esac - - AC_MSG_RESULT([${lt_sysroot:-no}]) _LT_DECL([], [lt_sysroot], [0], [The root where to search for ]dnl [dependent libraries, and in which our libraries should be installed.])])