Flamedoge via llvm-dev
2016-Oct-17 18:09 UTC
[llvm-dev] unable to compile llvm with gcc 4.7.4
Just for the interest of discussion, I find it completely weird and interesting that GCC needs to build itself 3 times to fully bootstrap. Has there been any interest in looking at a single compile build? I don't exactly know the limitations, but my naive thinking is that C++14 compiler source parsed by C++14 capable compiler and codegen'd to C99 (or older) source should make it compilable by older compilers. Is this just a delusion or an actually useful idea? Regards, Kevin On Mon, Oct 17, 2016 at 7:24 AM, Bruce Hoult via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I think this 3 stage bootstrap is just a fact of modern life, and progress > of languages. In fact I think you're getting away lightly, and I'm amazed > you could use only a 2-stage bootstrap from a very simple C compiler until > now!! > > The good news: it should be a very very long time before you need a 4 > stage bootstrap :-) > > > On Mon, Oct 17, 2016 at 2:02 PM, Sylvain Bertrand via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> The problem is modern c++. I can have a reasonable system boostrape-ed >> with (tinycc/alternative C compiler), but only in the gcc world since >> a modern c++ compiler is only bootsrape-able from near any C compiler >> there. clang and llvm are unable to do it. That why I would need to >> get 2 gccs: "any C compiler" -> gcc 4.7.4 -> gcc recent_version -> >> llvm. >> >> On Fri, Oct 14, 2016 at 4:02 PM, Renato Golin <renato.golin at linaro.org> >> wrote: >> > On 13 October 2016 at 12:56, <sylvain.bertrand at gmail.com> wrote: >> >> It's my custom distro. My goal is to make it boostrap-able with tinycc >> (or any >> >> little C compiler alternative) as a one-man reasonable job. With the >> removal of >> >> gcc 4.7 support now official, I would need to have a 3 step bootstrap, >> adding a >> >> modern gcc (which is guaranted to compile with iso c++98-ish gcc >> 4.7.4, feature >> >> that clang cannot guaranted anymore). >> > >> > Hi Sylvain, >> > >> > I have to say, after a while thinking about your use case, I cannot >> > come up with a better solution than a 3-stage build. :( >> > >> > Maybe you need to step back a bit and ask yourself: what would be the >> > system changes to adopt GCC 4.8 natively instead of tinycc. >> > >> > What distributions do is to compile the base GCC they'll use first, >> > making sure all the correct libraries in all the correct versions are >> > bundles in the right places, then use that toolchain for *everything*. >> > >> > You seem comfortable enough building GCC 4.7, I assume as a side >> > package, like BSD ports. I'm also assuming you already need GCC (for >> > packages other than LLVM), then why not make GCC your system compiler? >> > >> > The dependencies will already be there anyway, and I don't think GCC >> > 4.8's libraries are much bigger than 4.7, so it does seem like an >> > overall gain. >> > >> > Of course, it'll mean you'll have to test your packages with GCC 4.8, >> > but assuming they already use tinycc or GCC 4.7, I hope you'll have >> > very little additional problems. >> > >> > Would any of that help? >> > >> > cheers, >> > --renato >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/b1ea3c52/attachment.html>
Renato Golin via llvm-dev
2016-Oct-17 18:28 UTC
[llvm-dev] unable to compile llvm with gcc 4.7.4
On 17 October 2016 at 19:09, Flamedoge via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Just for the interest of discussion, I find it completely weird and > interesting that GCC needs to build itself 3 times to fully bootstrap. Has > there been any interest in looking at a single compile build? I don't > exactly know the limitations, but my naive thinking is that C++14 compiler > source parsed by C++14 capable compiler and codegen'd to C99 (or older) > source should make it compilable by older compilers. Is this just a delusion > or an actually useful idea?Far from being an expert, my understanding is that this is largely due to the libraries and tools. GCC has a reduced sub-set of the compiler that works with many old compilers, and they build that one first, then use that one to build the required libraries, tools, and the complete compiler, than use the complete compiler to bootstrap. You can also have cross-bootstrap, or Canadian cross, which increase the complexity of the builds by a reasonable margin. LLVM doesn't do that because we rely on the system's libraries, which honestly is a bad habit. This bad habit made the edges between RT, libc++ and LLVM a bit rough, especially when cross compiling and re-using those tools to bootstrap. It also makes it very hard to have stable tests, especially in between "package upgrades". It should be possible to bootstrap Clang in only two stages, but that requires a lot of CMake magic if we want to get *all* components built, including RT, libc++ and lld. However, none of that mentions the C library, which is a whole new problem if Clang can't compile it. I believe we still can't compile the GNU C library, but we can compile Musl (at least for some targets), so we could include Musl on such a two-stage magical bootstrap... But that's a lot of work... :) cheers, --renato
Daniel Berlin via llvm-dev
2016-Oct-17 18:44 UTC
[llvm-dev] unable to compile llvm with gcc 4.7.4
On Mon, Oct 17, 2016 at 11:28 AM, Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On 17 October 2016 at 19:09, Flamedoge via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Just for the interest of discussion, I find it completely weird and > > interesting that GCC needs to build itself 3 times to fully bootstrap. > Has > > there been any interest in looking at a single compile build?(I know renato did not write this, but i'll just answer this here) This is deliberate and necessary if you want to be sure. You can do a single compile build by just "not bootstrapping". The reason boostrapping is 3 stages is to find optimizer bugs. stage 1: Compile new compiler stage 2: Compile self with new compiler // IE detect any obvious bugs in new compiler, like ICE, etc stage 3: Compiler self with stage 2 compiler // IE detect miscompiles caused by new compiler being broken Stage 2 and 3 should be identical, if they aren't, you have a minimum of non-determinism, and more likely, a codegen bug somewhere. Otherwise, stage2 could be very broken and you may not notice, because the compiler has relatively few compile + execute tests (since they are very hard to write) Instead, they rely on the one large execution test they know they can use: the compiler itself. Note that 3 stage bootstraps are a technique that predates gcc :)> I don't > > exactly know the limitations, but my naive thinking is that C++14 > compiler > > source parsed by C++14 capable compiler and codegen'd to C99 (or older) > > source should make it compilable by older compilers. Is this just a > delusion > > or an actually useful idea? > > Far from being an expert, my understanding is that this is largely due > to the libraries and tools. > > GCC has a reduced sub-set of the compiler that works with many old > compilers, and they build that one first, then use that one to build > the required libraries, tools, and the complete compiler, than use the > complete compiler to bootstrap.This is not correct :) First stage of gcc is the entire compiler, not a subset or a different compoiler. You can also have cross-bootstrap, or> Canadian cross, which increase the complexity of the builds by a > reasonable margin. > > LLVM doesn't do that because we rely on the system's libraries, which > honestly is a bad habit. This bad habit made the edges between RT, > libc++ and LLVM a bit rough, especially when cross compiling and > re-using those tools to bootstrap. It also makes it very hard to have > stable tests, especially in between "package upgrades". > > It should be possible to bootstrap Clang in only two stages, but that > requires a lot of CMake magic if we want to get *all* components > built, including RT, libc++ and lld. > > However, none of that mentions the C library, which is a whole new > problem if Clang can't compile it. I believe we still can't compile > the GNU C library, but we can compile Musl (at least for some > targets), so we could include Musl on such a two-stage magical > bootstrap... > > But that's a lot of work... :) > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/7c96ab41/attachment.html>
Bruce Hoult via llvm-dev
2016-Oct-17 18:53 UTC
[llvm-dev] unable to compile llvm with gcc 4.7.4
Without knowing the details of gcc, the usual idea is: 1) use the old compiler to compile a temporary compiler form the latest compiler sources. This makes a compiler that understands the latest language and ABI and interface to the runtime library, but links to the old runtime library using the old ABI. 2) use the temporary compiler to compile whatever parts of the latest runtime library the compiler itself uses. 3) use the temporary compiler to compile the latest compiler sources and link them to the new runtime library. This produces nearly the final new compiler. But! You don't know if it works properly! 4) use the new compiler to compile the full runtime library. 5) use the new compiler to compile itself and link with the full runtime library. 6) compile any other tools you distribute. This requires that the compiler always be written using only the old version of the language, and using only features from the old version of the runtime library. But the runtime library can make unrestricted use of the latest language. Possibly also the temporary compiler might be restricted in some way. For example, not include the optimizer, or use a very simple back end. In that case, those parts of the compiler can be written using the full current version of the language, but you need an extra bootstrap step. On Mon, Oct 17, 2016 at 9:09 PM, Flamedoge <code.kchoi at gmail.com> wrote:> Just for the interest of discussion, I find it completely weird and > interesting that GCC needs to build itself 3 times to fully bootstrap. Has > there been any interest in looking at a single compile build? I don't > exactly know the limitations, but my naive thinking is that C++14 compiler > source parsed by C++14 capable compiler and codegen'd to C99 (or older) > source should make it compilable by older compilers. Is this just a > delusion or an actually useful idea? > > Regards, > Kevin > > On Mon, Oct 17, 2016 at 7:24 AM, Bruce Hoult via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I think this 3 stage bootstrap is just a fact of modern life, and >> progress of languages. In fact I think you're getting away lightly, and I'm >> amazed you could use only a 2-stage bootstrap from a very simple C compiler >> until now!! >> >> The good news: it should be a very very long time before you need a 4 >> stage bootstrap :-) >> >> >> On Mon, Oct 17, 2016 at 2:02 PM, Sylvain Bertrand via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> The problem is modern c++. I can have a reasonable system boostrape-ed >>> with (tinycc/alternative C compiler), but only in the gcc world since >>> a modern c++ compiler is only bootsrape-able from near any C compiler >>> there. clang and llvm are unable to do it. That why I would need to >>> get 2 gccs: "any C compiler" -> gcc 4.7.4 -> gcc recent_version -> >>> llvm. >>> >>> On Fri, Oct 14, 2016 at 4:02 PM, Renato Golin <renato.golin at linaro.org> >>> wrote: >>> > On 13 October 2016 at 12:56, <sylvain.bertrand at gmail.com> wrote: >>> >> It's my custom distro. My goal is to make it boostrap-able with >>> tinycc (or any >>> >> little C compiler alternative) as a one-man reasonable job. With the >>> removal of >>> >> gcc 4.7 support now official, I would need to have a 3 step >>> bootstrap, adding a >>> >> modern gcc (which is guaranted to compile with iso c++98-ish gcc >>> 4.7.4, feature >>> >> that clang cannot guaranted anymore). >>> > >>> > Hi Sylvain, >>> > >>> > I have to say, after a while thinking about your use case, I cannot >>> > come up with a better solution than a 3-stage build. :( >>> > >>> > Maybe you need to step back a bit and ask yourself: what would be the >>> > system changes to adopt GCC 4.8 natively instead of tinycc. >>> > >>> > What distributions do is to compile the base GCC they'll use first, >>> > making sure all the correct libraries in all the correct versions are >>> > bundles in the right places, then use that toolchain for *everything*. >>> > >>> > You seem comfortable enough building GCC 4.7, I assume as a side >>> > package, like BSD ports. I'm also assuming you already need GCC (for >>> > packages other than LLVM), then why not make GCC your system compiler? >>> > >>> > The dependencies will already be there anyway, and I don't think GCC >>> > 4.8's libraries are much bigger than 4.7, so it does seem like an >>> > overall gain. >>> > >>> > Of course, it'll mean you'll have to test your packages with GCC 4.8, >>> > but assuming they already use tinycc or GCC 4.7, I hope you'll have >>> > very little additional problems. >>> > >>> > Would any of that help? >>> > >>> > cheers, >>> > --renato >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/10e23c3c/attachment.html>
Flamedoge via llvm-dev
2016-Oct-17 20:20 UTC
[llvm-dev] unable to compile llvm with gcc 4.7.4
@Daniel, I seem to have confused the GCC's 3-stage building for functional testing with this thread's 3-stage building of "any C"->gcc-4.7.4->gcc4.8->LLVM. I was wondering if GCC was a compiler that had to bootstrap itself in lock-steps implementing new features with older language in order to support using new features in itself. If it can build itself from get go, then I suppose it doesn't use many new features in itself. I was just interested in circumventing the need-for-lock-step-building problem by targeting C backend to produce a 'compilable' code using any C compiler. It would be interesting to apply the "former" 3-stage technique with this. On Mon, Oct 17, 2016 at 11:53 AM, Bruce Hoult <bruce at hoult.org> wrote:> Without knowing the details of gcc, the usual idea is: > > 1) use the old compiler to compile a temporary compiler form the latest > compiler sources. This makes a compiler that understands the latest > language and ABI and interface to the runtime library, but links to the old > runtime library using the old ABI. > > 2) use the temporary compiler to compile whatever parts of the latest > runtime library the compiler itself uses. > > 3) use the temporary compiler to compile the latest compiler sources and > link them to the new runtime library. This produces nearly the final new > compiler. But! You don't know if it works properly! > > 4) use the new compiler to compile the full runtime library. > > 5) use the new compiler to compile itself and link with the full runtime > library. > > 6) compile any other tools you distribute. > > This requires that the compiler always be written using only the old > version of the language, and using only features from the old version of > the runtime library. But the runtime library can make unrestricted use of > the latest language. > > Possibly also the temporary compiler might be restricted in some way. For > example, not include the optimizer, or use a very simple back end. In that > case, those parts of the compiler can be written using the full current > version of the language, but you need an extra bootstrap step. > > > > On Mon, Oct 17, 2016 at 9:09 PM, Flamedoge <code.kchoi at gmail.com> wrote: > >> Just for the interest of discussion, I find it completely weird and >> interesting that GCC needs to build itself 3 times to fully bootstrap. Has >> there been any interest in looking at a single compile build? I don't >> exactly know the limitations, but my naive thinking is that C++14 compiler >> source parsed by C++14 capable compiler and codegen'd to C99 (or older) >> source should make it compilable by older compilers. Is this just a >> delusion or an actually useful idea? >> >> Regards, >> Kevin >> >> On Mon, Oct 17, 2016 at 7:24 AM, Bruce Hoult via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> I think this 3 stage bootstrap is just a fact of modern life, and >>> progress of languages. In fact I think you're getting away lightly, and I'm >>> amazed you could use only a 2-stage bootstrap from a very simple C compiler >>> until now!! >>> >>> The good news: it should be a very very long time before you need a 4 >>> stage bootstrap :-) >>> >>> >>> On Mon, Oct 17, 2016 at 2:02 PM, Sylvain Bertrand via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Hi, >>>> >>>> The problem is modern c++. I can have a reasonable system boostrape-ed >>>> with (tinycc/alternative C compiler), but only in the gcc world since >>>> a modern c++ compiler is only bootsrape-able from near any C compiler >>>> there. clang and llvm are unable to do it. That why I would need to >>>> get 2 gccs: "any C compiler" -> gcc 4.7.4 -> gcc recent_version -> >>>> llvm. >>>> >>>> On Fri, Oct 14, 2016 at 4:02 PM, Renato Golin <renato.golin at linaro.org> >>>> wrote: >>>> > On 13 October 2016 at 12:56, <sylvain.bertrand at gmail.com> wrote: >>>> >> It's my custom distro. My goal is to make it boostrap-able with >>>> tinycc (or any >>>> >> little C compiler alternative) as a one-man reasonable job. With the >>>> removal of >>>> >> gcc 4.7 support now official, I would need to have a 3 step >>>> bootstrap, adding a >>>> >> modern gcc (which is guaranted to compile with iso c++98-ish gcc >>>> 4.7.4, feature >>>> >> that clang cannot guaranted anymore). >>>> > >>>> > Hi Sylvain, >>>> > >>>> > I have to say, after a while thinking about your use case, I cannot >>>> > come up with a better solution than a 3-stage build. :( >>>> > >>>> > Maybe you need to step back a bit and ask yourself: what would be the >>>> > system changes to adopt GCC 4.8 natively instead of tinycc. >>>> > >>>> > What distributions do is to compile the base GCC they'll use first, >>>> > making sure all the correct libraries in all the correct versions are >>>> > bundles in the right places, then use that toolchain for *everything*. >>>> > >>>> > You seem comfortable enough building GCC 4.7, I assume as a side >>>> > package, like BSD ports. I'm also assuming you already need GCC (for >>>> > packages other than LLVM), then why not make GCC your system compiler? >>>> > >>>> > The dependencies will already be there anyway, and I don't think GCC >>>> > 4.8's libraries are much bigger than 4.7, so it does seem like an >>>> > overall gain. >>>> > >>>> > Of course, it'll mean you'll have to test your packages with GCC 4.8, >>>> > but assuming they already use tinycc or GCC 4.7, I hope you'll have >>>> > very little additional problems. >>>> > >>>> > Would any of that help? >>>> > >>>> > cheers, >>>> > --renato >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >> >> -- >> This message has been scanned for viruses and >> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and >> is >> believed to be clean. > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/7b700081/attachment.html>