Announcement

Collapse
No announcement yet.

Apple Originally Tried To Give GPL'ed LLVM To GCC

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

  • #31
    Originally posted by Annabel View Post
    this does not answer what I asked
    You asked for a source, and were quite vague. I gave a source, to what I thought you might have wanted the source to. Excuse me for failing at mind-reading.

    As far as it being easier to use, you could hardly find an objective source for that, as it's a very subjective thing in the first place. If you want the answer to that, you're better off trying each for yourself...although I wouldn't blame you if you didn't, I know I don't have time for that.

    Comment


    • #32
      Phoronix was the first to report widespread on Richard Stallman calling LLVM a "terrible setback"...
      Yeah...
      I got much more cheers when I read about that Phoronix was first to report on Valve's Steam for linux. Now "Phoronix reporting about Richard Stallman saying this or that" really, is that newsworthy? Somehow to me that degrades phoronix from being geeky to being nerdy...

      Comment


      • #33
        Originally posted by zanny View Post
        ... (the only missing feature I like in classic C is struct initialization, but in C++ you can get away with default constructors doing the same thing) ...
        You should look at C++11's initializer_list. If you're not aware of C++11 (or C++14/C++1y) or its new features, it's time to play catch-up.

        And superset of C aside, the language helps you achieve object orientation and polymorphism in a more straightforward fashion as well as providing the compiler more type information where it matters (e.g. a classic example being std::sort vs qsort()). All C has over C++ at this point is restrict pointers (which are absolutely awesome!).

        Comment


        • #34
          Originally posted by zanny View Post
          Uh, just copy / pasting from wikipedia here, but: ActionScript, Ada, D, Fortran, GLSL, Haskell, Java bytecode, Julia, Objective-C, Python, Ruby, Rust, Scala[2] and C#.

          That is a lot of languages. More than GCC. And it is much easier to integrate a new language into llvm. You usually don't have to write asm backends for every architecture in gcc though, but you have to write to their internal codepaths for language structures if you want to implement a new language for it, which is more cumbersome than just translating to a common asm surrogate.
          Languages? How did architectures in my question turned to languages? GCC was born as static compiler, it never was desighned as jit, you supposed to use other tool for jit, LLVM or something that not matter. But recently with all that fuzz there was attempts to make jit-like things libgccjit (WHY it must be in GCC? why not other extra project? Jit is jit, static compiler is static, both deal with CPU internals but they are very different in other parts, why mix them?).

          Another one. In my parallel universe, Black asm surrogate hand to hand to GPL spagetty monster 8 years torture LLVM and prevent to do Fortran, OpenMP, and posess ppl who actually try to deal with that "so cool LLVM architecture" so they write opposite things http://phoronix.com/forums/showthrea...054#post318054.

          Comment


          • #35
            Originally posted by nslay View Post
            You should look at C++11's initializer_list. If you're not aware of C++11 (or C++14/C++1y) or its new features, it's time to play catch-up.

            And superset of C aside, the language helps you achieve object orientation and polymorphism in a more straightforward fashion as well as providing the compiler more type information where it matters (e.g. a classic example being std::sort vs qsort()). All C has over C++ at this point is restrict pointers (which are absolutely awesome!).
            No, I mean I use C++ all the time, but you can't use designated initializers in C++, they are flat out not implemented and aren't meant to be:

            struct-test.cpp:11:51: sorry, unimplemented: non-trivial designated initializers not supported
            foo bar {.x = 5,};
            That can compile just fine in C, but will always fail in any version of standard C++ because it doesn't incude that named initialization syntax from C99. Among other aspects of C that aren't in C++, so you don't get a clean superset anymore. I was specifying an exception to the rule of "you can write C in C++ code" because you can use the C imperative style but the syntax isn't identical.
            Last edited by zanny; 25 January 2014, 05:19 PM.

            Comment


            • #36
              Originally posted by zanny View Post
              No, I mean I use C++ all the time, but you can't use designated initializers in C++, they are flat out not implemented and aren't meant to be:



              That can compile just fine in C, but will always fail in any version of standard C++ because it doesn't incude that named initialization syntax from C99. Among other aspects of C that aren't in C++, so you don't get a clean superset anymore.
              Oh, you got me there! I forgot all about the named initialization. Thanks.

              Comment


              • #37
                Originally posted by mrugiero View Post
                Are you sure the + suffices? Remember what they try to do with the relicensing is avoid the use under GPLv2, which allows patent trolling and tivoisation. I don't know if the + allows to start distributing as 3+ later, as far as I understand, they have no right (without the copyright assignment) to restrict the use of following versions of GCC to GPLv3 and above.
                Yes, the + is enough. What happened with linux after Linus and RMS had their indifference was that future contributions to linux was GPL2 only, effectively a fork from the GPL2+ code. Such forks can of course be made of GCC too, anybody can fork it and extend it with GPL3 only code.
                Originally posted by zanny View Post
                Uh, just copy / pasting from wikipedia here, but: ActionScript, Ada, D, Fortran, GLSL, Haskell, Java bytecode, Julia, Objective-C, Python, Ruby, Rust, Scala[2] and C#.

                That is a lot of languages. More than GCC. And it is much easier to integrate a new language into llvm. You usually don't have to write asm backends for every architecture in gcc though, but you have to write to their internal codepaths for language structures if you want to implement a new language for it, which is more cumbersome than just translating to a common asm surrogate.
                These are mostly interpreted languages, not a design target for GCC. What is the Fortran support in LLVM? I didn't know they had any. All things considered I tend to regard GCC as a very impressive project that stands its ground against any compiler. Sure various compilers have the upper hand in certain aspects, so Intel customers like Intel's compilers for HPC and clang has found some followers due to its fast compile time and low memory footprint. GCC is still the main work horse though, and that says a lot.

                Comment


                • #38
                  Originally posted by storm_st View Post
                  Languages? How did architectures in my question turned to languages? GCC was born as static compiler, it never was desighned as jit, you supposed to use other tool for jit, LLVM or something that not matter. But recently with all that fuzz there was attempts to make jit-like things libgccjit (WHY it must be in GCC? why not other extra project? Jit is jit, static compiler is static, both deal with CPU internals but they are very different in other parts, why mix them?).

                  Another one. In my parallel universe, Black asm surrogate hand to hand to GPL spagetty monster 8 years torture LLVM and prevent to do Fortran, OpenMP, and posess ppl who actually try to deal with that "so cool LLVM architecture" so they write opposite things http://phoronix.com/forums/showthrea...054#post318054.
                  Epic post lol.

                  On topic, this article is utter crap in quality and made me switch AdBlock on this site back on.

                  Comment


                  • #39
                    lfort (last commit 5 months ago, don't know how complete it is), or the well known dragonegg (Uses GCC with LLVM as the backend).

                    Comment


                    • #40
                      Originally posted by Del_ View Post
                      What is the Fortran support in LLVM? I didn't know they had any. All things considered I tend to regard GCC as a very impressive project that stands its ground against any compiler. Sure various compilers have the upper hand in certain aspects, so Intel customers like Intel's compilers for HPC and clang has found some followers due to its fast compile time and low memory footprint. GCC is still the main work horse though, and that says a lot.
                      I'm not saying GCC isn't great, I prefer it any time I can use it - for the langauges it supports it is the best. I imagine LLVM Fortran performance, barring a corporate contributor, is pretty shoddy - but the only real reason GCC has good support for an honestly legacy language like it is because its so old. Who would start a new project today in Fortran?

                      Where LLVM is great is implementing new languages like Rust. There is a reason the reference compiler targets llvm, after all.

                      Comment

                      Working...
                      X