Announcement

Collapse
No announcement yet.

GCC 12 Moves On To Stage 4 Development With Many New Compiler Features

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

  • GCC 12 Moves On To Stage 4 Development With Many New Compiler Features

    Phoronix: GCC 12 Moves On To Stage 4 Development With Many New Compiler Features

    GCC 12 as this year's annual GNU Compiler Collection feature release has moved on to "stage four" development with likely releasing GCC 12.1 in April...

    https://www.phoronix.com/scan.php?pa...Enters-Stage-4

  • #2
    And at least one of the P1 regressions prevents the Linux kernel from being able to compile with gcc 12 (which is sort of an important application).

    And at least a few of the compiler improvements/enhancements are finding code in applications that have always been wrong, but are just now being identified by gcc, which means other code needs to be updated.

    Comment


    • #3
      Originally posted by phoronix
      One fundamental change made by GCC developers upon entering stage four development was the decision to rename all .c C source files comprising the GCC compiler to now using a .cc extension.
      I took a look at some of the GCC 11 source recently, and it was a long time before I saw some usage of templates and realised that it was C++ and not C.

      That's quite unlike many C++ projects, which seem to rewrite everything every three years to update to what the newest definition of "modern C++" is.

      Comment


      • #4
        Originally posted by archsway View Post

        I took a look at some of the GCC 11 source recently, and it was a long time before I saw some usage of templates and realised that it was C++ and not C.

        That's quite unlike many C++ projects, which seem to rewrite everything every three years to update to what the newest definition of "modern C++" is.
        Indeed; I joined the GCC project in 2013, about the time we started moving the implementation language from C to C++. The fact that the source files all still had .c extensions has been an ongoing minor annoyance (and a hurdle for new contributors), I'm excited that we've finally gone ahead and fixed it (and nervous about all the working copies I have to rebase...)

        Given that GCC is needed to bootstrap a toolchain we're relatively conservative about our build requirements, and could only use C++98, until GCC 11, when we started allowing C++11 - and we're still conservative in our language usage, given that we could be getting compiled by older compilers that had bugs. (this is about the implementation language, as opposed to what we implement - we implement the most modern standards, as well as the older ones)

        Comment


        • #5
          Originally posted by archsway View Post

          I took a look at some of the GCC 11 source recently, and it was a long time before I saw some usage of templates and realised that it was C++ and not C.

          That's quite unlike many C++ projects, which seem to rewrite everything every three years to update to what the newest definition of "modern C++" is.
          GCC's use of C++ is very conservative and it was a concern for them from the beginning

          https://lwn.net/Articles/390016/

          "Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake."

          Comment


          • #6
            Originally posted by RahulSundaram View Post
            "Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake."
            it's not like c++ features are intended to make worse programs for users

            Comment


            • #7
              Originally posted by CommunityMember View Post
              And at least one of the P1 regressions prevents the Linux kernel from being able to compile with gcc 12 (which is sort of an important application).
              p1 is sort of high priority, it will be fixed before release
              Originally posted by CommunityMember View Post
              And at least a few of the compiler improvements/enhancements are finding code in applications that have always been wrong, but are just now being identified by gcc, which means other code needs to be updated.
              if it was never built with stricter compiler

              Comment


              • #8
                Originally posted by pal666 View Post
                it's not like c++ features are intended to make worse programs for users
                This seems like a willful misunderstanding of the point, which is so unlike you.

                What they're talking about is not wanting to use C++ features just for the sake of using them. The other day, I happened upon some code where someone was using trailing return type specifications for absolutely no good reason. We've all seen it: people either using features for the sake of playing around with them, or because they have some idea that the quality of their code is directly proportional to the number of language features it uses.

                Comment


                • #9
                  It seems that everybody understands the intent, but the last sentence in the article has it backwards. We renamed C++ files (not C, as the article says) that still had suffix .c to .cc.

                  Comment


                  • #10
                    Originally posted by pal666 View Post
                    it's not like c++ features are intended to make worse programs for users
                    It's a bit more involved than that.

                    Some C++ features are only still around for backward compatibility with legacy C or C++ and using them in your programs can make them worse, some of them are advanced features and while they may be useful in specific situations, you have to be cautious about using them, if you are migrating a large and complex codebase with many C developers as was the case with GCC. There are other features which are prone to misuse etc. Most large codebases have a specific policy (and tooling to support this) on which language subset they are willing to accept for these and other similar reasons.

                    Comment

                    Working...
                    X