Results 1 to 9 of 9

Thread: GCC 4.9.1 Released, Adds OpenMP 4.0 To Fortran

  1. #1
    Join Date
    Jan 2007
    Posts
    15,645

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

    http://www.phoronix.com/vr.php?view=MTc0Mjc

  2. #2
    Join Date
    Jul 2012
    Posts
    149

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

  3. #3
    Join Date
    Feb 2013
    Posts
    89

    Default

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

  4. #4
    Join Date
    Jul 2012
    Posts
    149

    Default

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

  5. #5
    Join Date
    Jul 2012
    Posts
    149

    Default

    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.

  6. #6
    Join Date
    Dec 2012
    Posts
    79

    Default

    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

  7. #7
    Join Date
    Jan 2013
    Location
    Sweden
    Posts
    8

    Default

    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.

  8. #8
    Join Date
    Jul 2012
    Posts
    149

    Default

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

  9. #9
    Join Date
    Jul 2012
    Posts
    149

    Default

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

Posting Permissions

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