Announcement

Collapse
No announcement yet.

GCC 10 Compiler Released With Radeon OpenMP/OpenACC Offload, Intel Tigerlake/Cooperlake

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

  • GCC 10 Compiler Released With Radeon OpenMP/OpenACC Offload, Intel Tigerlake/Cooperlake

    Phoronix: GCC 10 Compiler Released With Radeon OpenMP/OpenACC Offload, Intel Tigerlake/Cooperlake

    The GNU Compiler Collection 10 has seen its first stable release this morning in the form of GCC 10.1...

    http://www.phoronix.com/scan.php?pag...piler-Released

  • #2
    cant wait to see benchmarks

    Comment


    • #3
      Does it build the Linux Kernel without workarounds now?

      Comment


      • #4
        Originally posted by ms178 View Post
        Does it build the Linux Kernel without workarounds now?
        Yes and with optimization on compiler side that kernel is very fast and responsive

        https://www.dropbox.com/s/20rirx8nlg...70505.png?dl=0

        Comment


        • #5
          GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking.
          Beware: this change breaks compilation for literally hundreds of C applications.

          Also, just like it's now been forever, GCC 10 produces larger binary code than any GCC version before it.

          Comment


          • #6
            Thunder X3 Support can´t wait to see them deployed.. I think they won´t win the developers choice race (due to cross platform development being required), but they will definetly win the powerconsumption / processing power metric and the density / price metric so cool for workloads that need hundred of cores / have hundred of nodes!

            Probably won´t see them in traditional enterprises anytime soon IMHO.. And amazon is rolling their own N1 based design.. think smaller cloud providers will deploy them though.

            Comment


            • #7
              Wasn't this version supposed to have also some Zen2 improvements or they finished all the improvements for Zen2 in 9.3 ?

              Comment


              • #8
                Originally posted by Danny3 View Post
                Wasn't this version supposed to have also some Zen2 improvements or they finished all the improvements for Zen2 in 9.3 ?
                Yes, there is tuning done on real hardware (scheduler model, better vectorization etc.)

                Comment


                • #9
                  Originally posted by birdie View Post

                  Beware: this change breaks compilation for literally hundreds of C applications.

                  Also, just like it's now been forever, GCC 10 produces larger binary code than any GCC version before it.
                  One of bigger changes is that GCC now auto-inlines at -O2. This makes some binaries bigger other smaller. Testcases where it misbehave would be greatly welcome - it is very tedious task to analyze code size effects of such changes (and it occupied me for months last year)

                  Comment


                  • #10
                    Originally posted by hubicka View Post

                    One of bigger changes is that GCC now auto-inlines at -O2. This makes some binaries bigger other smaller. Testcases where it misbehave would be greatly welcome - it is very tedious task to analyze code size effects of such changes (and it occupied me for months last year)
                    I've carried out a simple test though: I compiled the kernel and its modules using GCC 9.3 and 10.1 - the latter came out bigger. And we're not even talking about any uArch specific optimizations as by default the kernel is compiled using just "-O2" with no other options whatsoever.

                    To be absolutely precise the compilation flags for 5.6.11 are (sans -DCONFIG):

                    -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init

                    i.e. no -march, no -mtune, nothing. The difference is around 1% which is probably nothing to actually worry about.

                    Comment

                    Working...
                    X