llvm dev - Oct 2016 - unable to compile llvm with gcc 4.7.4

On Mon, Oct 17, 2016 at 1:41 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 17 October 2016 at 19:44, Daniel Berlin <dberlin at dberlin.org>
wrote:
> > First stage of gcc is the entire compiler, not a subset or a different
> > compoiler.
>
> I didn't mean a different compiler, just not a full
"toolchain".
>
Ah.
You said "GCC has a reduced sub-set of the compiler that works with many
old
compiler".

This is the part i meant is not correct anymore. It does not have a reduced
subset.
This was kind of true at one point.  It used to be that the C compiler even
worked with K&R through conversion.
Nowadays, even this has fallen by the wayside.
>
> As far as my knowledge of Linaro's process goes, stage 1 uses the
> system libraries and tools (could be cross), and they use the stage 1
> to build the intended versions of the libraries and tools (stage
> 1.5?),

Yes.

> and use that "incomplete" build + new libraries and tools to
> build stage 2.

I wouldn't call it "incomplete". In most cases, it includes all
compilers
and languages and libraries :)
> Stage 3 should be identical, for verification
> processes.
>
Yes.

>
> The difference with LLVM is that we don't build the libraries with
> stage 1's Clang, but the system compiler/tools/libraries as well,
> making it a simple 2-stage build, as opposed to a 2.5 stage build.
> When it comes to the C libraries, we don't even build them at all, and
> use the system libraries even on stage 2.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161017/d7c897ee/attachment.html>

On 17 October 2016 at 22:01, Daniel Berlin <dberlin at dberlin.org>
wrote:
> This was kind of true at one point.  It used to be that the C compiler even
> worked with K&R through conversion.
> Nowadays, even this has fallen by the wayside.
Right, that would explain my confusion.

> I wouldn't call it "incomplete". In most cases, it includes
all compilers
> and languages and libraries :)
It turns out, for cross-compilation bootstrap, in stage "0" you
don't
really need any other language than C. Then, when the run-time and C
libraries are correct, you build full stage 1 and the rest follows.

Or so I gathered... :)

cheers,
--renato

Hi,

This is not the purpose of my distro.

The purpose of my distro is to account for complexity lock-in and to remove
this as much as possible. This complexity is usually performed in 2 ways:
 - ultra costly languages/runtime to implement (c++/java...), and I don't
think
   "ultra" is a word big enough.
 - multiplication of script languages
(python2/python3/ruby/javascript/perl/guile...)

It is to keep the technical cost the lowest possible in order to let the door
reasonnably open to alternatives of the same language. c++ is slapping this
door at the face of any attempt to produce working alternatives.
An other point of view is the level of entry which is usually much higher on
c++ projects due to syntax complexity, and often non-pertinent in
the goal to achieve.

Then c++ compilers and c++ in itself fail big time to achieve my goal, because
their
implementation cost is orders of magnitude higher than a C99 compiler.

Not to mention the sick attitude of many c++ developers which is to maximize the
complexity of their object oriented design because they think it makes them
smart. Smart is to address a pb as elegantly as possible with low technical
cost components. The pb is that c++ syntax amplify the damage caused by this
attitude, again in dramatic proportion.

It is better to lose syntax sugar and to type a bit more than to get super
duper syntax sugar at the price of a dependency on an ultra complex
compiler/runtime.

Currently mesa glsl compiler is based on llvm for AMD gpu. That's why
I'm
looking at integrating llvm.

llvm is c++, then I know I'm talking to walls there, but this is a matter of
sincerity.

-- 
Sylvain