No announcement yet.

GCC 4.3.0 Released w/ SSE4 Support

  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC 4.3.0 Released w/ SSE4 Support

    Phoronix: GCC 4.3.0 Released w/ SSE4 Support

    GCC 4.2.0 was released less than a year ago, but arriving yesterday was the release of GCC 4.3.0. Version 4.3.0 of the GNU Compiler Collection has its middle-end integrated with the MPFR math library, experimental support for the forthcoming C++0x ISO standard, GCJ now uses the Eclipse Java Compiler for Java parsing, all Java 1.5 language features now supported by both the compiler and at run-time, and new GCJ Java tools...

  • #2
    GCC no longer places the cld instruction before string operations. Both i386 and x86-64 ABI documents mandate the direction flag to be clear at the entry of a function. It is now invalid to set the flag in asm statement without reseting it afterward.
    I've read that this causes a potential bug in current versions of the Linux kernel. Is there an news on which kernel release (if any) has been fixed for this?

    See this mailing list post and resulting discussion:


    • #3
      I'm a complete newbie in Linux stuff but I feel the need to ask. Does this mean no love for SSE4A (read: Phenom) ? That's too bad since I was thinking of buying one of them once they get the TLB fixed processors out.


      • #4
        There seems to be a performance increase when following the ABI docs on setting the direction flag, and userland code needs to be fixed too. My guess is distros won't fully switch to 4.3 until these problems are fixed.

        Keefa: SSE4A is supported through -march=barcelona


        • #5
          Ah, that clears it up. Thank you very much indeed, audi100quattro.


          • #6
            So after installing a distro with GCC 4.3 (eg openSUSE 11.0) is it possible to set the -march=barcelona or -march=core2? Or is it done automatically by the distro during initial installation?

            BTW, are all 64-bit distros i686 already?


            • #7
              -march=native will automatically detect and optimize for whatever processor you have.

              If you're building from source through ./configure and make, you might have to edit the makefile or edit and re-run aclocal/autoconf and add the flags you want to CPPFLAGS/CFLAGS. There's probably an easier way of doing it, I'm sure somebody knows.


              • #8
                It didn't even compile on my i686-pc-linux-gnu system (SuSE 10).

                Crapped out when compiling fortran.

                if /bin/sh ./libtool --tag=CC --mode=compile /gcc/gcc-4.3.0/host-i686-pc-linux-gnu/gcc/xgcc -B/gcc/gcc-4.3.0/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../.././libgfortran -I.  -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../../host-i686-pc-linux-gnu/gcc -D_GNU_SOURCE  -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -g -O2   -MT unix.lo -MD -MP -MF ".deps/unix.Tpo" -c -o unix.lo `test -f 'io/unix.c' || echo '../.././libgfortran/'`io/unix.c; \
                then mv -f ".deps/unix.Tpo" ".deps/unix.Plo"; else rm -f ".deps/unix.Tpo"; exit 1; fi
                libtool: compile:  /gcc/gcc-4.3.0/host-i686-pc-linux-gnu/gcc/xgcc -B/gcc/gcc-4.3.0/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../.././libgfortran -I. -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../../host-i686-pc-linux-gnu/gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -g -O2 -MT unix.lo -MD -MP -MF .deps/unix.Tpo -c ../.././libgfortran/io/unix.c  -fPIC -DPIC -o .libs/unix.o
                /tmp/ccMebWWk.s: Assembler messages:
                /tmp/ccMebWWk.s:6353: Error: symbol `fstat64' is already defined
                /tmp/ccMebWWk.s:7169: Error: symbol `lstat64' is already defined
                /tmp/ccMebWWk.s:7202: Error: symbol `stat64' is already defined
                make[3]: *** [unix.lo] Error 1
                make[3]: Leaving directory `/x/gcc-4.3.0/gcc-4.3.0/i686-pc-linux-gnu/libgfortran'
                make[2]: *** [all] Error 2
                make[2]: Leaving directory `/x/gcc-4.3.0/gcc-4.3.0/i686-pc-linux-gnu/libgfortran'
                make[1]: *** [all-target-libgfortran] Error 2
                make[1]: Leaving directory `/x/gcc-4.3.0/gcc-4.3.0'
                make: *** [all] Error 2
                ./configure --with-mpfr=/usr/local/ --enable-languages=c,c++,java,objc

                compiles though. That the configure script cannot find headers and/or libraries in /usr/local/ is a worry.
                Last edited by Jade; 03-13-2008, 05:03 AM.


                • #9
                  Seems to be a toxic release.

                  Crapped out when compiling basic Win32 (mingw32) cross compiler.

                  ./configure --target=i686-pc-mingw32 --enable-languages=c

                  with winsup = winsup-src-20080302.tar.bz2 from


                  ( cp -r cygwin-snapshot-20080302-1/winsup gcc-4.3.0/ )

                  updating cache ./config.cache
                  configure: creating ./config.status
                  config.status: creating Makefile
                  config.status: executing default commands
                  Adding multilib support to Makefile in ../.././libgcc
                  make[2]: Entering directory `/x/gcc-4.3.0/gcc-4.3.0/i686-pc-mingw32/libgcc'
                  Makefile:144: ../.././gcc/libgcc.mvars: No such file or directory
                  make[2]: *** No rule to make target `../.././gcc/libgcc.mvars'.  Stop.
                  make[2]: Leaving directory `/x/gcc-4.3.0/gcc-4.3.0/i686-pc-mingw32/libgcc'
                  make[1]: *** [all-target-libgcc] Error 2
                  make[1]: Leaving directory `/x/gcc-4.3.0/gcc-4.3.0'
                  make: *** [all] Error 2


                  • #10

                    Apparently, both of these problems (mentioned above) go away if you do the build in directories separate from the sources. Since this is non-traditional, it might have been nice for people to point out that the build will not work, in certain cases, unless you build in separate directories. For projects like gcc, compiling in separate directories is actually a great idea.