Announcement

Collapse
No announcement yet.

GCC 4.9.1 Released, Adds OpenMP 4.0 To Fortran

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

  • GCC 4.9.1 Released, Adds OpenMP 4.0 To Fortran

    Phoronix: GCC 4.9.1 Released, Adds OpenMP 4.0 To Fortran

    The first point release to the GCC 4.9 compiler is now available...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    it chokes on -flto with codeblocks

    Version gcc-4.8.x compiles it fine. I didn't file official debug report since they drequest particularities I don't know, so if anyone has the will and time to give it a look, he might find interesting bug during LTO linking.

    4.9.1 dies soon after start with:


    Code:
    libtool: link: x86_64-pc-linux-gnu-g++ -DTIXML_USE_STL -Wno-unused-local-typedefs -O2 -ffast-math -DCB_AUTOCONF -march=native -O3 -flto -pipe -flto-partition=none -fpermissive -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -Wl,--no-undefined -o auto_revision auto_revision-autorevision.o  ../../base/tinyxml/.libs/libtinyxml.a -lpthread -ldl
    /var/tmp/portage/dev-util/codeblocks-9999/temp/cc7g671j.lto.o: In function `TiXmlDocument::~TiXmlDocument()':
    auto_revision-autorevision.o:(.text+0x4b): undefined reference to `vtable for TiXmlDocument'
    auto_revision-autorevision.o:(.text+0x6b): undefined reference to `TiXmlNode::~TiXmlNode()'
    /var/tmp/portage/dev-util/codeblocks-9999/temp/cc7g671j.lto.o: In function `QuerySvn(std::string const&, std::string&, std::string&) [clone .constprop.0]':
    auto_revision-autorevision.o:(.text+0xc6b): undefined reference to `TiXmlDocument::TiXmlDocument()'
    auto_revision-autorevision.o:(.text+0xc7a): undefined reference to `TiXmlDocument::Parse(char const*, TiXmlParsingData*, TiXmlEncoding)'
    auto_revision-autorevision.o:(.text+0xcab): undefined reference to `TiXmlHandle::FirstChildElement(char const*) const'
    auto_revision-autorevision.o:(.text+0xcc7): undefined reference to `TiXmlHandle::FirstChildElement(char const*) const'
    auto_revision-autorevision.o:(.text+0xce0): undefined reference to `TiXmlHandle::FirstChildElement(char const*) const'
    auto_revision-autorevision.o:(.text+0xd28): undefined reference to `TiXmlElement::Attribute(char const*) const'
    auto_revision-autorevision.o:(.text+0xd40): undefined reference to `TiXmlElement::Attribute(char const*) const'
    auto_revision-autorevision.o:(.text+0xd5a): undefined reference to `TiXmlNode::FirstChildElement(char const*) const'
    auto_revision-autorevision.o:(.text+0xd6e): undefined reference to `TiXmlElement::GetText() const'
    auto_revision-autorevision.o:(.text+0xd7f): undefined reference to `TiXmlElement::GetText() const'
    collect2: error: ld returned 1 exit status
    codeblocks code is from repository svn://svn.code.sf.net/p/codeblocks/code/trunk

    Flags used were

    CFLAGS="-march=native -O3 -flto -pipe -flto-partition=none" ( tried also without -flto-partition=none, same result).
    CXXFLAGS="${CFLAGS} -fpermissive"
    LDFLAGS="-Wl,-O3 -Wl,--sort-common -Wl,-flto -Wl,-flto-partition=none -Wl,--as-needed"

    gcc is 4.9.1 with all standards gentoo patches for 4.9.0 ( except those few already applied)

    Comment


    • #3
      Originally posted by Brane215 View Post
      Version gcc-4.8.x compiles it fine. I didn't file official debug report since they drequest particularities I don't know, so if anyone has the will and time to give it a look, he might find interesting bug during LTO linking.

      4.9.1 dies soon after start with:


      Code:
      libtool: link: x86_64-pc-linux-gnu-g++ -DTIXML_USE_STL -Wno-unused-local-typedefs -O2 -ffast-math -DCB_AUTOCONF -march=native -O3 -flto -pipe -flto-partition=none -fpermissive -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -Wl,--no-undefined -o auto_revision auto_revision-autorevision.o  ../../base/tinyxml/.libs/libtinyxml.a -lpthread -ldl
      /var/tmp/portage/dev-util/codeblocks-9999/temp/cc7g671j.lto.o: In function `TiXmlDocument::~TiXmlDocument()':
      auto_revision-autorevision.o:(.text+0x4b): undefined reference to `vtable for TiXmlDocument'
      auto_revision-autorevision.o:(.text+0x6b): undefined reference to `TiXmlNode::~TiXmlNode()'
      /var/tmp/portage/dev-util/codeblocks-9999/temp/cc7g671j.lto.o: In function `QuerySvn(std::string const&, std::string&, std::string&) [clone .constprop.0]':
      auto_revision-autorevision.o:(.text+0xc6b): undefined reference to `TiXmlDocument::TiXmlDocument()'
      auto_revision-autorevision.o:(.text+0xc7a): undefined reference to `TiXmlDocument::Parse(char const*, TiXmlParsingData*, TiXmlEncoding)'
      auto_revision-autorevision.o:(.text+0xcab): undefined reference to `TiXmlHandle::FirstChildElement(char const*) const'
      auto_revision-autorevision.o:(.text+0xcc7): undefined reference to `TiXmlHandle::FirstChildElement(char const*) const'
      auto_revision-autorevision.o:(.text+0xce0): undefined reference to `TiXmlHandle::FirstChildElement(char const*) const'
      auto_revision-autorevision.o:(.text+0xd28): undefined reference to `TiXmlElement::Attribute(char const*) const'
      auto_revision-autorevision.o:(.text+0xd40): undefined reference to `TiXmlElement::Attribute(char const*) const'
      auto_revision-autorevision.o:(.text+0xd5a): undefined reference to `TiXmlNode::FirstChildElement(char const*) const'
      auto_revision-autorevision.o:(.text+0xd6e): undefined reference to `TiXmlElement::GetText() const'
      auto_revision-autorevision.o:(.text+0xd7f): undefined reference to `TiXmlElement::GetText() const'
      collect2: error: ld returned 1 exit status
      codeblocks code is from repository svn://svn.code.sf.net/p/codeblocks/code/trunk

      Flags used were

      CFLAGS="-march=native -O3 -flto -pipe -flto-partition=none" ( tried also without -flto-partition=none, same result).
      CXXFLAGS="${CFLAGS} -fpermissive"
      LDFLAGS="-Wl,-O3 -Wl,--sort-common -Wl,-flto -Wl,-flto-partition=none -Wl,--as-needed"

      gcc is 4.9.1 with all standards gentoo patches for 4.9.0 ( except those few already applied)
      Try setting the following env vars (given that it uses autotools) -> NM=gcc-nm RANLIB=gcc-ranlib

      These are necessary if using -flto with gcc-4.9.

      You can also try using "-ffat-lto-objects" to restore gcc-4.8 like behavior for lto.

      Comment


      • #4
        Originally posted by Krejzi View Post
        Try setting the following env vars (given that it uses autotools) -> NM=gcc-nm RANLIB=gcc-ranlib

        These are necessary if using -flto with gcc-4.9.

        You can also try using "-ffat-lto-objects" to restore gcc-4.8 like behavior for lto.

        I tried trick with variables. It doesn't work. I tried upgrading binutils from version 23.x to 24.x

        With the same, negative result.

        But -ffat-lto-objects seems to be working. Thing is still compiling, but it is looking good.

        This kind of stuff should have been published along with newslet, so that potential volunteers wouldn't have to stumble around so much.

        BTW, colorized output with -fdiagnostics-color=auto is awesome new tweak on gcc-4.9.1.

        Comment


        • #5
          It works.

          BTW:For Gentoo users that would like to try it, I filed a version bump bug with adapted patch that you need.

          just emerge -F =gcc-4.9.0 , take a look in distfiles map which gcc-4.9.0-xxx files have been downloaded, delete main patch and use mine, rename the rest to 4.9.1, copy the gcc map into your overlay map, rename gcc-4.9.0. ebuild there into 4.9.1 version, unmask it and "emerge " new version.

          Official gentoo 4.9.1 will of course come, but it will probably take a while.

          Comment


          • #6
            They released it before fixing #61144? Awesome GCC.
            It was a wrong-code regression which should have been a P1 release blocker according to http://gcc.gnu.org/bugs/management.html

            Comment


            • #7
              Brane215, I think you forgot -fuse-linker-plugin.

              The need for -ffat-lto-objects means that it's (partly?) linked without LTO.

              Also set AR=gcc-ar.

              I've had more succes with GCC 4.9 than 4.8 with regard to LTO, so I doubt you've hit a regression.

              Comment


              • #8
                Originally posted by Ouroboros View Post
                They released it before fixing #61144? Awesome GCC.
                It was a wrong-code regression which should have been a P1 release blocker according to http://gcc.gnu.org/bugs/management.html
                They haven't . I have posted a patch for those that would like to toy with it. If one is dumb enough to go compiling one's system with it right away, that's his/her problem.

                Comment


                • #9
                  Originally posted by _pLu_ View Post
                  Brane215, I think you forgot -fuse-linker-plugin.

                  The need for -ffat-lto-objects means that it's (partly?) linked without LTO.

                  Also set AR=gcc-ar.

                  I've had more succes with GCC 4.9 than 4.8 with regard to LTO, so I doubt you've hit a regression.
                  I tired that. On latest codeblock it fails tiny bit later, maybe one or two links later, and with different error message, but stil fails

                  WRT to LTO, I want it selectively. Not across whole system.

                  It doesn' make much sense to compile glibc with it, if you expect it to be linked dynamically into many programs.

                  But for cutting through heaps of C++ object pr0n within Codeblocks it seems like a good choice.

                  Comment

                  Working...
                  X