[llvm-dev] unable to compile llvm with gcc 4.7.4

Mon Oct 17 13:20:18 PDT 2016

@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>