Announcement

Collapse
No announcement yet.

LLVM/Clang Can Build LibreOffice

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • LLVM/Clang Can Build LibreOffice

    Phoronix: LLVM/Clang Can Build LibreOffice

    Clang, the C/C++ compiler for LLVM, can now build a patched version of LibreOffice...

    http://www.phoronix.com/vr.php?view=MTAwNDM

  • #2
    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.

    Comment


    • #3
      i would classify this as bugs ans not missing features

      Comment


      • #4
        Originally posted by DeepDayze View Post
        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?

        Comment


        • #5
          Originally posted by rohcQaH View Post
          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; 10-22-2011, 12:46 PM.

          Comment


          • #6
            ... 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.

            Comment


            • #7
              Originally posted by DeepDayze View Post
              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.

              Originally posted by DeepDayze View Post
              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.


              Originally posted by ultimA View Post
              [..]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.

              Comment


              • #8
                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.
                Last edited by ultimA; 10-22-2011, 04:11 PM.

                Comment


                • #9
                  This is as much a non News as the Plymouth one.

                  It builds now but what it builds is crap! Yay!

                  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)
                  Last edited by Ragas; 10-22-2011, 04:57 PM.

                  Comment


                  • #10
                    Originally posted by Ragas View Post
                    I'm pretty sure I'm also able to build a compiler that can generate code that doesn't work. o.O
                    But can you end the mono-culture that exists around gcc that results in blog posts about patches that allow something else to build?

                    Comment


                    • #11
                      From personal experience, code I wrote that didn't compile with Clang was my own fault. Clang was right not to accept it and GCC was wrong. These are mostly corner cases that are very easy to get wrong when writing code. For example, I didn't know that const objects should not have a compiler-generated default constructor. GCC would generate one just fine. Clang wouldn't because the standard says that user is responsible for providing it. (GCC got fixed now, but only after Clang showed that this was an issue.)

                      This is why I now mainly use Clang while developing (I run it through GCC and Intel C++ now and then for brevity though.) It helps in producing more correct code by refusing to compile wrong code. The error messages are also much clearer than GCC's, where you already need to know in advance what the error means by having encountered it before.
                      Last edited by RealNC; 10-23-2011, 12:39 AM.

                      Comment


                      • #12
                        I am sure someday Clang/LLVM will end up becoming the default compiler for the Linux kernel rather than GCC, once it matures. Even desktops like KDE/GNOME could be built with it as well as apps. If Clang does become the "wonder compiler" I am sure it'll become widely used

                        Comment


                        • #13
                          Originally posted by rohcQaH View Post
                          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.
                          If the compiler doesn't throw errors and the binary fails to run the problem is most likely a bug in the compiler. Still, a while back LLVM/Clang couldn't even compile LibreOffice so there's definately been progress. I think this article should have been posted when it compiled and ran, I'll chalk it up to either Michael's overall entusiasm concerning LLVM/Clang or a lack of newsworthy material.

                          Comment


                          • #14
                            Originally posted by yogi_berra View Post
                            But can you end the mono-culture that exists around gcc that results in blog posts about patches that allow something else to build?
                            What exactly are you referring to?

                            Comment


                            • #15
                              Originally posted by RealNC View Post
                              The error messages are also much clearer than GCC's, where you already need to know in advance what the error means by having encountered it before.
                              Yes the error diagnostics are superior in Clang/LLVM, when it reaches a higher maturity/GCC compability I will most likely switch to it as my development compiler and use GCC primarily for performance/final builds as it generates faster code.

                              Comment

                              Working...
                              X