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

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

On 18 October 2016 at 10:17, Sylvain BERTRAND
<sylvain.bertrand at gmail.com> wrote:
> 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...)
A worthy goal, and a niche that has been left untouched by most
distros our there.

> 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.
Unfortunately, we don't have a C-only front-end, nor you can select
some C-only libraries in LLVM to compile C-only code. Such a goal
should have been set from the beginning, and honestly, it would have
made LLVM's code horrendous to work with.

> 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.
C++, Perl, Python, Haskell, Ocaml... and I have to say, C programmers
as well. The amount of hackery I've seen in C programs by so called
"smart guys" is astounding.

> Currently mesa glsl compiler is based on llvm for AMD gpu. That's why
I'm
> looking at integrating llvm.
Ah! This explains it! Honestly, I'd go back to the mesa guys and check
to see if there is any other back-end that you can use.

Last time I checked (a very long time ago), LLVM-pipe was an
experimental thing. I'm not sure what's the new rage in terms of
rendering libraries nowadays, but I'd be surprised if you couldn't
find some old C-only (or simplified C++) that is still supported in
some way.

> llvm is c++, then I know I'm talking to walls there, but this is a
matter of
> sincerity.
You're most certainly not talking to walls, here.

I think most of us understand these problems quite well, and we try
very hard to not fall into the fallacy of language power. We're
constantly refactoring our data structures and algorithms to make them
easier to understand as well as faster and more reliable, so you got
the right crowd here.

However, C++14 has brought a lot of simplicity to the convoluted
C++98, and has made it a much simpler, saner language, and that's why
we're so keen on moving on. Not because it's a cool toy, but because
it makes the code simpler to read and maintain.

But that's not going to save your day. :/

cheers,
--renato

On Tue, Oct 18, 2016 at 10:54:31AM +0100, Renato Golin
wrote:
> > 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.
> 
> C++, Perl, Python, Haskell, Ocaml... and I have to say, C programmers
> as well. The amount of hackery I've seen in C programs by so called
> "smart guys" is astounding.
This is what I'm saying: the c++ ultra complex syntax and infrastructure
technical cost, both makes way more damage than
simpler syntax languages. More over c++ is "building" more people with
this
attitude because of c++ complex syntax _in itself_. The main issue it c++ being
c++.
> > Currently mesa glsl compiler is based on llvm for AMD gpu. That's
why I'm
> > looking at integrating llvm.
> 
> Ah! This explains it! Honestly, I'd go back to the mesa guys and check
> to see if there is any other back-end that you can use.
No, you cannot, their glsl infrastructure for AMD GPUs is based on c++ and
llvm, and from my perspective, is not something to be proud of, as you can
guess.
(on the side, I'm not found of the DRM in the linux kernel either, even
though
I'm siding with Linus T. for his views on the problem which is c++).
> I think most of us understand these problems quite well, and we try
> very hard to not fall into the fallacy of language power. We're
> constantly refactoring our data structures and algorithms to make them
> easier to understand as well as faster and more reliable, so you got
> the right crowd here.
> 
> However, C++14 has brought a lot of simplicity to the convoluted
> C++98, and has made it a much simpler, saner language, and that's why
> we're so keen on moving on. Not because it's a cool toy, but
because
> it makes the code simpler to read and maintain.
This is where the fallacy is: c++ compiler/runtime (any version) ultra costly
dependency and its other issues do not balance any gain brought by its syntax.
Most of the time it ends up to be saner to write a bit more code in simpler
languages than paying the cost of such a dependency. More over the reasonabl
syntax "helps" a lot to put some straps on the developer ability to
produce
obscure design.
If really a specific language design could have help massively at writting
compiler infrastrutures (taylored for it), at least, that specific language
should be bootstrapable, in a reasonable maner, with basic C compilers. vala is
a good example, with taylorisation for gobject. But where vala compiler/runtime
has the decency to compile with a basic C compiler and has a simple ABI, modern
c++ compilers/infrastrures (c++XX>98) do fail dramaticaly.
> But that's not going to save your day. :/
Indeed, but at least, I hope I did open some eyes on this very serious issue. 

regards,

-- 
Sylvain

On 10/18/2016 4:54 AM, Renato Golin via llvm-dev wrote:
> Unfortunately, we don't have a C-only front-end, nor you can select
> some C-only libraries in LLVM to compile C-only code. Such a goal
> should have been set from the beginning, and honestly, it would have
> made LLVM's code horrendous to work with.
An option would be to have a C backend again, and then cross-compile the 
toolchain for the new target, but compile it into C, which then can be 
recompiled into binaries on the target platform.

I actually bootstrapped an SML compiler for FreeBSD/ppc this way a while 
back. A part of the compiler was written in SML and there was an option 
to compile SML to C (that was actually one of the ways to generate final 
code: the C output would then be passed to a system C compiler). I think 
the SML compiler was mlton, but I'm not 100% certain.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation