Announcement

Collapse
No announcement yet.

Talk Of GCC 5.0 To Be Modular, More Like LLVM

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

  • #11
    Originally posted by DaemonFC View Post
    LLVM generates poorly optimized code.....with less useful debugging information....if it even builds something at all. (8.5% of Debian GNU/Linux packages fail to build with LLVM 3.0, that's a few thousand packages. In LLVM 2.9, the failure rate was nearly 15%.)
    Any figure for the % of those packages using gcc specific extensions?

    Comment


    • #12
      Originally posted by jayrulez View Post
      Any figure for the % of those packages using gcc specific extensions?
      And the fun part is, that those "extensions" are enabled by default instead of a proper ANSI behavior.
      Well, in any case I'm happy with LLVM and Clang, I use both and never had problems with assembly code, debugging and such (in fact, when I had a FreeBSD system around, I compiled the entire base system plus some software with Clang without issues)

      ATM I prefer it over GCC, but if the chit-chat at the GCC mailing lists is somewhat true (plus, some advantages of LLVM/Clang), I'll use that version of GCC.

      Comment


      • #13
        Originally posted by XorEaxEax View Post
        As for Micheal's comparisons against LLVM, first off the projects he names are using LLVM as a JIT compiler, GCC is a static compiler (barring GCJ I suppose) so comparing them in this area is pointless and currently LLVM's real success is as a JIT framework.
        GCJ is staticly compiled. It also gives performance in many cases (at least with flags of removing bounds checking) in GCC range.
        When dynamic runtime code is needed, GCJ goes in interpreted mode (which maybe here is where GCJ have bad rep).

        Comment


        • #14
          Originally posted by jayrulez View Post
          Any figure for the % of those packages using gcc specific extensions?
          That's about as relevant as asking how many have MSVC extensions, or ICC extensions, or Solaris extensions, or LLVM extensions. It doesn't matter.

          Comment


          • #15
            Originally posted by smitty3268 View Post
            That's about as relevant as asking how many have MSVC extensions, or ICC extensions, or Solaris extensions, or LLVM extensions. It doesn't matter.
            In some ways it matters. Because if you want to write a C library that works on Windows you have to write __stdcall. These extensions are a part of working with real software. The good part is that CLang offers extensions by itself, in part for compatibility:
            This document describes the language extensions provided by Clang. In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. Please see the GCC manual for more information on these extensions.

            Comment


            • #16
              Originally posted by smitty3268 View Post
              That's about as relevant as asking how many have MSVC extensions, or ICC extensions, or Solaris extensions, or LLVM extensions. It doesn't matter.
              It does, if we want portable programming, it does.
              Those extensions should be disabled when a project is setup, just like a programmer abstracts platform, this also makes up for portability...

              Regards.

              Comment


              • #17
                Originally posted by smitty3268 View Post
                That's about as relevant as asking how many have MSVC extensions, or ICC extensions, or Solaris extensions, or LLVM extensions. It doesn't matter.
                Unless you expect every compiler to compensate for the short-coming and quirks of other compilers, then it does matter. You cannot write code specific to compiler X, then complain that compiler Y won't compile your code and treat that as a short-coming of compiler Y.

                read - STANDARDS, PORTABILITY

                I think if LLVM/Clang was never created, then the GCC devs wouldn't be contemplating such improvements so soon (maybe in the next 7-10 years).

                Comment


                • #18
                  Originally posted by vertexSymphony View Post
                  It does, if we want portable programming, it does.
                  Those extensions should be disabled when a project is setup, just like a programmer abstracts platform, this also makes up for portability...

                  Regards.
                  Whoosh! What's that? It's my point flying by over your heads?

                  You are attempting to assign blame, when that doesn't matter. All that matters to the end user is whether or not it works.

                  If Joe Blow can't install Magic Eight Ball software package in the latest Fedora release, it doesn't matter why. All Joe knows is that he used to be able to and now can't. Therefore the latest Fedora sucks.

                  Comment


                  • #19
                    Originally posted by jayrulez View Post
                    Unless you expect every compiler to compensate for the short-coming and quirks of other compilers, then it does matter. You cannot write code specific to compiler X, then complain that compiler Y won't compile your code and treat that as a short-coming of compiler Y.

                    read - STANDARDS, PORTABILITY
                    You realise that these are 'extensions', as such they are not part of any standard and developers know this when they use them. Like Smitty said, all compiler have extensions, not only that but they also have exclusive extensions. The reason there are extensions is that there's a need/request for their functionality from programmers, this obviously also results in them being used in certain projects. Extensions which prove extremely useable will almost certainly be supported across compilers, and some of them even end up as parts of the standards. In short, writing standard compliant portable code is up to the programmer, not the compiler he/she uses.

                    Comment


                    • #20
                      Why so much focus on LLVM?

                      Even on a story which could (and should) have been focused on some free software project, Michael chooses to focus on his favored LLVM. I understand a person having favorite projects, but there needs to be much less reporter's bias here. Something that is almost never mentioned when it comes to stories regarding these and other free software projects are the licensing differences (if any), and the corresponding considerations.

                      Comment

                      Working...
                      X