If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
I would say Clang/LLVM would be really feature-complete if it can properly compile *unpatched* applications. Having to apply patches to application or kernel code to make it properly compile on Clang/LLVM sounds to me like it still isn't quite ready.
I would say Clang/LLVM would be really feature-complete if it can properly compile *unpatched* applications.
unpatched *standards-compliant, bug-free* applications? Sure. If there ever was such a thing.
Browsing through the small list of patches, it appears that many of these fix bugs in LibreOffice, where the code relies on gcc's quirks or gcc's acceptance of non-standard code.
At least one of them is clearly a workaround due to llvm bugs. Then again, do you know how many workarounds due to gcc bugs LO's codebase contains?
unpatched *standards-compliant, bug-free* applications? Sure. If there ever was such a thing.
Browsing through the small list of patches, it appears that many of these fix bugs in LibreOffice, where the code relies on gcc's quirks or gcc's acceptance of non-standard code.
At least one of them is clearly a workaround due to llvm bugs. Then again, do you know how many workarounds due to gcc bugs LO's codebase contains?
So you saying Clang/LLVM is using strict interpretations of how code's to be compiled vs gcc? So then these patches are quite instructive to the gcc team as these patches point out some quirks within gcc itself that need to be addressed.
I'm sure there are bugs in gcc and application and kernel developers work around them, and same thing would apply for LLVM's own quirks and bugs...so yes you are right
However altering code due to compiler bugs should be ideally kept to a minimum
Last edited by DeepDayze; 22 October 2011, 12:46 PM.
... and the generated executable evidently doesn't work
That hardly classifies as "building" for me. The language parser has seen some improvement again, okay, so that it doesn't err on the source code. But if I make a program that can only parse the source files but produces garbage binary output, that won't be called a compiler. So I'll acknowledge that it can "build" LibreOffice once the output really works.
So you saying Clang/LLVM is using strict interpretations of how code's to be compiled vs gcc?
No, I'm saying it's using a different set of strictness, different behaviour for things that the C standard determines to be "undefined", different compiler specific extensions and different subtle bugs and shortcomings.
However altering code due to compiler bugs should be ideally kept to a minimum
The thing is, this has already happened, by virtue of OOo/LO being developed using gcc. If OOo/LO had been developed on LLVM, we'd now need patches to compile LO on gcc.
The fact that LLVM needs some patches on a gcc-developed project does not allow us to determine which is the better compiler. It merely tells us that the compilers aren't identical.
[..]But if I make a program that can only parse the source files but produces garbage binary output, that won't be called a compiler. So I'll acknowledge that it can "build" LibreOffice once the output really works.
You may want to read the linked article. It's a valid binary, but it crashes during startup. Whether that's due to a bug in LLVM or a bug in LO (i.e. reliance on gcc specific behaviour) hasn't been researched yet.
I did read it before. Compiling something that does not work when it should is not considered a valid output, so it's all the same. Except if it is due to GCC-specific behaviour, then I take my words back. I mean, there is not much difference between not producing a usable output, and producing a valid binary that is not usable. But, you're right, LO might be relying on some non-standard GCC thing, if that is the only cause then I am sorry.
I'm pretty sure I'm also able to build a compiler that can generate code that doesn't work. o.O
(this is not aimed against Clang, it's aimed against the non news)
Comment