<div dir="ltr">Without knowing the details of gcc, the usual idea is:<div><br></div><div>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.</div><div><br></div><div>2) use the temporary compiler to compile whatever parts of the latest runtime library the compiler itself uses.</div><div><br></div><div>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!</div><div><br></div><div>4) use the new compiler to compile the full runtime library.</div><div><br></div><div>5) use the new compiler to compile itself and link with the full runtime library.</div><div><br></div><div>6) compile any other tools you distribute.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 17, 2016 at 9:09 PM, Flamedoge <span dir="ltr"><<a href="mailto:code.kchoi@gmail.com" target="_blank">code.kchoi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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?<br><br></div>Regards,<br></div>Kevin<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 17, 2016 at 7:24 AM, Bruce Hoult via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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!!<div><br></div><div>The good news: it should be a very very long time before you need a 4 stage bootstrap :-)</div><div><br></div></div><div class="m_-4326205488417867319HOEnZb"><div class="m_-4326205488417867319h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 17, 2016 at 2:02 PM, Sylvain Bertrand via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The problem is modern c++. I can have a reasonable system boostrape-ed<br>
with (tinycc/alternative C compiler), but only in the gcc world since<br>
a modern c++ compiler is only bootsrape-able from near any C compiler<br>
there. clang and llvm are unable to do it. That why I would need to<br>
get 2 gccs: "any C compiler" -> gcc 4.7.4 -> gcc recent_version -><br>
<span class="m_-4326205488417867319m_4718239777220961885HOEnZb"><font color="#888888">llvm.<br>
</font></span><div class="m_-4326205488417867319m_4718239777220961885HOEnZb"><div class="m_-4326205488417867319m_4718239777220961885h5"><br>
On Fri, Oct 14, 2016 at 4:02 PM, Renato Golin <<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>> wrote:<br>
> On 13 October 2016 at 12:56, <<a href="mailto:sylvain.bertrand@gmail.com" target="_blank">sylvain.bertrand@gmail.com</a>> wrote:<br>
>> It's my custom distro. My goal is to make it boostrap-able with tinycc (or any<br>
>> little C compiler alternative) as a one-man reasonable job. With the removal of<br>
>> gcc 4.7 support now official, I would need to have a 3 step bootstrap, adding a<br>
>> modern gcc (which is guaranted to compile with iso c++98-ish gcc 4.7.4, feature<br>
>> that clang cannot guaranted anymore).<br>
><br>
> Hi Sylvain,<br>
><br>
> I have to say, after a while thinking about your use case, I cannot<br>
> come up with a better solution than a 3-stage build. :(<br>
><br>
> Maybe you need to step back a bit and ask yourself: what would be the<br>
> system changes to adopt GCC 4.8 natively instead of tinycc.<br>
><br>
> What distributions do is to compile the base GCC they'll use first,<br>
> making sure all the correct libraries in all the correct versions are<br>
> bundles in the right places, then use that toolchain for *everything*.<br>
><br>
> You seem comfortable enough building GCC 4.7, I assume as a side<br>
> package, like BSD ports. I'm also assuming you already need GCC (for<br>
> packages other than LLVM), then why not make GCC your system compiler?<br>
><br>
> The dependencies will already be there anyway, and I don't think GCC<br>
> 4.8's libraries are much bigger than 4.7, so it does seem like an<br>
> overall gain.<br>
><br>
> Of course, it'll mean you'll have to test your packages with GCC 4.8,<br>
> but assuming they already use tinycc or GCC 4.7, I hope you'll have<br>
> very little additional problems.<br>
><br>
> Would any of that help?<br>
><br>
> cheers,<br>
> --renato<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
<br></div></div><span class="HOEnZb"><font color="#888888">--
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is
<br>believed to be clean.
</font></span></blockquote></div><br></div>