Extracting the abstract syntax tree from GCC

Posted Jan 15, 2015 19:57 UTC (Thu) by flussence (guest, #85566)
In reply to: Extracting the abstract syntax tree from GCC by etienne
Parent article: Extracting the abstract syntax tree from GCC

> Yes, buggy proprietary LLVM backend (on OpenCl video cards) are a real improvement to the software countryside...

Yes it is, when the status quo for a tolerably fast and standards-conformant OpenGL/CL stack is called "nvidia.ko" and it's apparent nobody else is even trying.

Extracting the abstract syntax tree from GCC

Posted Jan 16, 2015 20:39 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Nvidia isn't standards conforming (they allow all sorts of things the spec says shouldn't be possible). They also care very little about OpenCL.

Extracting the abstract syntax tree from GCC

Posted Jan 19, 2015 19:05 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

My point being the alternative in the GNU/Free monoculture etienne is pining for is non-existent.

Acting *offended* that LLVM exists and allows FOSS to work for its users is a repulsive attitude.

Extracting the abstract syntax tree from GCC

Posted Jan 20, 2015 11:13 UTC (Tue) by etienne (guest, #25256) [Link]

> My point being the alternative in the GNU/Free monoculture etienne is pining for is non-existent.

I was not talking about Nvidia but Ati.
My point was you look at their very powerful hardware, you say I want to play with that.
You look at how to program the hardware, you do not see a locked-down proprietary language but something reasonably described (OpenCl), you begin to look at the different hardware configurations you can buy.
You look at the compiler, you see LLVM, you say great! an open source compiler: I shall not have too many problems, and even if I have I will be able to fix them. You buy the hardware you have selected.

Then you realize, when you finally achieve to configure the hardware to work as a basic video card on your distribution (did take a long time, had to disable package management and other dirty things), that the version of LLVM used is completely out of date, that most of the toolchain is completely proprietary and no part can be re-generated, then you hit your first compiler bug (usually it locks down the PCIe bus so forces a hardware reboot with unclean filesystems because the disks are on PCIe Sata interface).

Then you understand that they declared their compiler BugFree (TM), and that they will not consider a bug if you cannot reproduce it on the latest video game (which do not seem to use OpenCl but the "intermediate" representation directly).

> Acting *offended* that LLVM exists and allows FOSS to work for its users is a repulsive attitude.

*offended* is a big word, that is not the first time I spent money on hardware I cannot really use, and I have seen a lot of broken compilers where the supplier denies officially that a bug may exists.

I am also *not saying* LLVM is buggy, I am saying the version they used has been so modified it now has a bug that bite me hard - I can't do anything about it.

I think LLVM gets bad advertisement with that story, final user should really understand the difference of:
- compiler based on "Open Source" software
- compiler itself "Open Source"
- compiler itself "Open Source" and can be fixed (regenerated) locally
- compiler GPL