Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Talk Of GCC 5.0 To Be Modular, More Like LLVM

  1. #11
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    300

    Default

    Quote 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?

  2. #12
    Join Date
    Feb 2012
    Posts
    111

    Default

    Quote 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.

  3. #13
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote 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).

  4. #14
    Join Date
    Oct 2008
    Posts
    3,102

    Default

    Quote 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.

  5. #15
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    398

    Default

    Quote 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.

  6. #16
    Join Date
    Feb 2012
    Posts
    111

    Default

    Quote 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.

  7. #17
    Join Date
    Feb 2012
    Location
    Kingston, Jamaica
    Posts
    300

    Default

    Quote 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).

  8. #18
    Join Date
    Oct 2008
    Posts
    3,102

    Default

    Quote 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.

  9. #19
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote 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.

  10. #20
    Join Date
    Nov 2006
    Location
    Seattle
    Posts
    305

    Default 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •