GCC 4.0 (part 2)

Message

rhill · Post by **rhill** » Mon Aug 01, 2005 7:50 pm

CFLAGS="-O3 -march=pentium-m -mtune=pentium-m -pipe -mfpmath=sse -mmmx -msse -msse2 -momit-leaf-frame-pointer -funit-at-a-time -fweb -floop-optimize2 -fforce-addr -ftracer -fno-ident -minline-all-stringops -foptimize-sibling-calls -fcaller-saves -falign-functions=4 -falign-jumps=4 -falign-loops=4 -finline-functions"

bad.

Code: Select all

CFLAGS="-O3 -march=pentium-m -fomit-frame-pointer -pipe"

good.

http://gentoo-wiki.com/TIP_GCC_4.0_Test ... n_Problems

whitesouls · Post by **whitesouls** » Mon Aug 01, 2005 8:36 pm

Aight... I have reduced my cflags to

Code: Select all

CFLAGS="-Os -march=pentium-m -pipe -momit-leaf-frame-pointer"

Is this ok? How about some stability flags?? Can anyone suggest some or atleast one other than -frame-omit-pointer?

Post by **Halcy0n** » Mon Aug 01, 2005 8:37 pm

@Lord Vader: Like everyone else has said, make your CFLAGS something sane. I'd recommend recompiling atleast your toolchain after doing so. CFLAGS are not magical incantations that make software work magnitudes faster.

whitesouls · Post by **whitesouls** » Mon Aug 01, 2005 8:47 pm

Halcy0n wrote:@Lord Vader: Like everyone else has said, make your CFLAGS something sane. I'd recommend recompiling atleast your toolchain after doing so. CFLAGS are not magical incantations that make software work magnitudes faster.

Aight, thanks for the info. I even took out my LDFLAGS. Anything else?

. BTW, I'm recompiling my toolkit now.

Exner · Post by **Exner** » Mon Aug 01, 2005 11:45 pm

Halcy0n wrote:
d4rkn0va wrote:
Code: Select all
CFLAGS="-O0 -march=athlon -pipe -ffast-math"
CXXFLAGS="-O0 -march=athlon -pipe -ffast-math -fvisibility-inlines-hidden"
It looks like it needs atleast -O1 in CFLAGS. Try it with that and see if it works.

app-text/opensp-1.5.1 compiles here with gcc-4.0.1

I use CFLAGS="-march=athlon-xp -O1 -fomit-frame-pointer -ggdb1 -pipe"

So far 355 packages of 850 on my system have compiled. An estimated 10 have not. Once I go through all of them ill start hunting compile bugs.

d4rkn0va · Post by **d4rkn0va** » Tue Aug 02, 2005 12:04 am

OK, changed my CFLAGS to "-O1 -march=athlon -pipe -ffast-math" and compiled opensp successfully on my server, thx guys

But that's kinda funny.. I really thought "-O0" is more secure, less problems, so I used that one xD

whitesouls · Post by **whitesouls** » Tue Aug 02, 2005 8:00 am

Izzit possible for me to apply -Os instead of -O2. By this i wish to optimize the size of the code but it is stated here {http://gentoo-wiki.com/TIP_GCC_4.0_Test ... n_Problems }that it will increase the size of code. Can anyone explain how this can happen?

Another question is, If this GCC4 is meant for testing ( i mean the GCC 4.0.1 ) wheter it is stable or not,
1.Can't we imply some performance CFLAGS

2.And if we do imply, like -ftracer or -ffast-math, why would it break where the previous versions of GCC like GCC3.4.3 and GCC 3.4.4 can handle it.

Debentoo_Gao · Post by **Debentoo_Gao** » Tue Aug 02, 2005 12:56 pm

zomps wrote:

zomps wrote:For Ati binary drivers there seems to be patch
http://rage3d.com/board/showthread.php?t=33822116

Finally installed the gcc 4.0.1 and tried the above patch
Seems that gentoo-sources has already most of this patch

i removed the gentoo part
and left this part

Code: Select all

diff -urN fglrx-vanilla/firegl_public.c fglrx/firegl_public.c
--- fglrx-vanilla/firegl_public.c       2005-06-12 20:56:30.000000000 +0200
+++ build_mod/firegl_public.c   2005-06-30 00:19:24.000000000 +0200
@@ -167,7 +167,7 @@

 #if !defined(__ia64__)
 // the macros do use errno variable
-static int errno;
+int errno;
 #endif // __ia64__

 // int mlock(const void *addr, size_t len);
diff -urN fglrx/agp_backend.h fglrx-vanilla/agp_backend.h
--- fglrx/agp_backend.h 2005-06-12 20:56:04.000000000 +0200
+++ build_mod/agp_backend.h     2005-06-30 00:37:34.000000000 +0200
@@ -89,7 +89,7 @@
 #define _X(_x) __fgl_##_x
 extern int _X(agp_init)(void);
 extern void _X(agp_cleanup)(void);
-extern int _X(agp_try_unsupported);
+static int _X(agp_try_unsupported);
 #else /* Original AGPGART module */
 #define STANDALONE_AGPGART
 #define _X(_x) _x
diff -urN fglrx/agpgart_be.c fglrx-vanilla/agpgart_be.c
--- fglrx/agpgart_be.c  2005-06-30 00:38:38.000000000 +0200
+++ build_mod/agpgart_be.c      2005-06-30 00:38:02.000000000 +0200
@@ -176,7 +176,7 @@
 #ifdef STANDALONE_AGPGART
 static int agp_try_unsupported __initdata = 0;
 #else /* !STANDALONE_AGPGART */
-int agp_try_unsupported = 0;
+static int agp_try_unsupported = 0;
 #endif /* !STANDALONE_AGPGART */

 int agp_memory_reserved;

then added epatch ${FILESDIR}/fglrx-linux-2.6.12-gcc4.diff to ebuild
and line "cp libfglrx_ip.a.GCC3 libfglrx_ip.a.GCC4" in src_compile function
and it works

Could u make an ebuild 4 all these patches? I think it's useful 4 all the newbie

nxsty · Post by **nxsty** » Tue Aug 02, 2005 1:34 pm

Lord Vader wrote:Izzit possible for me to apply -Os instead of -O2. By this i wish to optimize the size of the code but it is stated here {http://gentoo-wiki.com/TIP_GCC_4.0_Test ... n_Problems }that it will increase the size of code. Can anyone explain how this can happen?

Another question is, If this GCC4 is meant for testing ( i mean the GCC 4.0.1 ) wheter it is stable or not,
1.Can't we imply some performance CFLAGS

2.And if we do imply, like -ftracer or -ffast-math, why would it break where the previous versions of GCC like GCC3.4.3 and GCC 3.4.4 can handle it.

The -Os size bug does not apply to everything so it's probably safe to play with. But perhaps you shouldn't use it system wide yet before that bug is fixed.

1. Yes of course you can, but then be ready to report bugs to the gcc devs on http://gcc.gnu.org/bugzilla/

2. Gcc 3 has been out for 4 years while gcc 4 with all it's new technology only has been out for a couple of months, so it's not that strange that gcc 3 is more stable than 4.

But you shouldn't use "aggresive" CFLAGS anyway even if the compiler is stable. More CFLAGS than what i previously suggested usually causes bloat in binaries which is bad for performance and is unlikely to gain you anything.

Debentoo_Gao · Post by **Debentoo_Gao** » Tue Aug 02, 2005 4:08 pm

modify the ebuild myself

Here's the ati-drivers-8.14.13-r2.ebuild 4 gcc4

http://www.mydays.org.ru/files/ati-drivers-gcc4.tar.bz2

Xake · Post by **Xake** » Thu Aug 04, 2005 2:01 pm

What is the current status of -mfpmath=sse?
Someone warned about it some time ago, have not heard anything sbout it since....

nxsty · Post by **nxsty** » Sat Aug 06, 2005 12:02 pm

chtephan wrote:I've opened a bug on bugzilla to discuss the hardened gcc 4.0.1 stuff:

http://bugs.gentoo.org/show_bug.cgi?id=100689

Any news on this?

rhill · Post by **rhill** » Sun Aug 07, 2005 2:59 am

Debentoo_Gao wrote:modify the ebuild myself Here's the ati-drivers-8.14.13-r2.ebuild 4 gcc4

http://www.mydays.org.ru/files/ati-drivers-gcc4.tar.bz2

thanks.

here's the diff against ati-drivers-8.14.13-r3.ebuild

Code: Select all

--- ati-drivers-8.14.13-r3.ebuild-orig  2005-08-06 21:08:18.000000000 -0600
+++ ati-drivers-8.14.13-r3.ebuild       2005-08-06 21:08:23.000000000 -0600
@@ -66,6 +66,7 @@
        rpm_src_unpack

        cd ${WORKDIR}/lib/modules/fglrx/build_mod
+       cp libfglrx_ip.a.GCC3 libfglrx_ip.a.GCC4

        #epatch ${FILESDIR}/fglrx-3.9.0-allocation.patch

@@ -79,6 +80,7 @@
        epatch ${FILESDIR}/8.8.25-smp.patch
        epatch ${FILESDIR}/ioctl32.patch
        epatch ${FILESDIR}/p1.patch
+       epatch ${FILESDIR}/fglrx-linux-2.6.12-gcc4.diff

        rm -rf ${WORKDIR}/usr/X11R6/bin/fgl_glxgears
 }

rhill · Post by **rhill** » Sun Aug 07, 2005 7:08 am

nxsty wrote:The -Os size bug does not apply to everything so it's probably safe to play with. But perhaps you shouldn't use it system wide yet before that bug is fixed.

i think at least one case of -Os size bloat was just fixed (friday). next week's 4.0.2alpha snapshot should have the fix.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529

rhill · Post by **rhill** » Sun Aug 07, 2005 7:33 am

gcc-4.0.2_beta20050804 is available.

bug fixes since 20050728: 19
bug fixes since 4.0.1: 83

ebuild and patches available @ http://metawire.org/~dirtyepic/gcc-4.0. ... 04.tar.bz2

untar in $PORTDIR_OVERLAY. patchset is pretty small right now and just contains fixes for pr21254, pr21562, pr22360, and pr23165. if you can't connect, then metawire is probably down for it's bi-weekly DDOS attack

. try again later.

asimon · Post by **asimon** » Sun Aug 07, 2005 4:35 pm

dirtyepic wrote:gcc-4.0.2_beta20050804 is available.

bug fixes since 20050728: 19
bug fixes since 4.0.1: 83

ebuild and patches available @ http://metawire.org/~dirtyepic/gcc-4.0. ... 04.tar.bz2

untar in $PORTDIR_OVERLAY. patchset is pretty small right now and just contains fixes for pr21254, pr21562, pr22360, and pr23165. if you can't connect, then metawire is probably down for it's bi-weekly DDOS attack . try again later.

Very cool. I just updated from 4.0.1, but this seems somewhat strange to me:

Code: Select all

# ldd /usr/lib/gcc/i686-pc-linux-gnu/4.0.2/libstdc++.so.6.0.5
        linux-gate.so.1 =>  (0xffffe000)
        libm.so.6 => /lib/libm.so.6 (0xb7e40000)
        libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libgcc_s.so.1 (0xb7e37000)
        libc.so.6 => /lib/libc.so.6 (0xb7d1a000)
        /lib/ld-linux.so.2 (0x80000000)

I don't think it's good that gcc 4's stdc++ lib links against gcc 3.

EDIT: I got that linking issue fixed by uninstalling gcc 3.4.x and cleaning a lot of garbage that portage/gcc-config never removed (I even had stuff left from gcc 3.3).

Another thing: /etc/env/05gcc adds /usr/lib/gcc/i686-pc-linux-gnu/4.0.2-beta20050804 to LDPATH, but there are no libraries under this dir at all, only include files. The libs get installed under /usr/lib/gcc/i686-pc-linux-gnu/4.0.2.

rhill · Post by **rhill** » Sun Aug 07, 2005 5:51 pm

asimon wrote:Another thing: /etc/env/05gcc adds /usr/lib/gcc/i686-pc-linux-gnu/4.0.2-beta20050804 to LDPATH, but there are no libraries under this dir at all, only include files. The libs get installed under /usr/lib/gcc/i686-pc-linux-gnu/4.0.2.

now that you mention it, i ran into the same problem when i did a stage 1 install with a gcc 4 snapshot a couple weeks ago. i ended up making a temporary symlink between the two (ugh) until i had a running system and could check out what was going on and then immediately forgot all about it.

FWIW, the 4.1 ebuild also does the same thing. anyways, whatever the reason it seems to be working fine.

rhill · Post by **rhill** » Sun Aug 07, 2005 8:25 pm

scratch that - it _was_ linking against an older libc++

after removing an old copy of 3.3.5 i had installed i got:

Code: Select all

error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

this seems to me like a bug in the eclass but i haven't been able to find it just yet. in the meantime, i've worked around it in /etc/env.d/gcc/i686-pc-linux-gnu-4.0.2-beta20050804.

Code: Select all

LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.0.2-beta20050804/:/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/"

then i ran gcc-config and env-update.

is this something that should get filed in bugzilla? do any of the 3.x ebuilds have this behaviour?

asimon · Post by **asimon** » Sun Aug 07, 2005 8:52 pm

dirtyepic wrote:scratch that - it _was_ linking against an older libc++ after removing an old copy of 3.3.5 i had installed i got:
Code: Select all
error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
this seems to me like a bug in the eclass but i haven't been able to find it just yet. in the meantime, i've worked around it in /etc/env.d/gcc/i686-pc-linux-gnu-4.0.2-beta20050804.
Code: Select all
LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.0.2-beta20050804/:/usr/lib/gcc/i686-pc-linux-gnu/4.0.2/"

I think it's pointless to have /usr/lib/gcc/i686-pc-linux-gnu/4.0.2-beta20050804 in the LDPATH at all. I only put /usr/lib/gcc/i686-pc-linux-gnu/4.0.2 in there and it works fine.

dirtyepic wrote: is this something that should get filed in bugzilla?

I just saw this with your ebuild, I don't know if or how many other gcc builds are effected. But if it's an eclass issue than it should be filed in bugzilla of course.

dirtyepic wrote: do any of the 3.x ebuilds have this behaviour?

At least gcc-3.4.4 and gcc-4.0.1 don't had this behaviour here. Maybe only beta GCCs show this behavior, i.e. if they put more than one dir into /usr/lib/gcc/i686-pc-linux-gnu. Then the wrong one ends in LDPATH.

BTW: I just recompiled some KDE stuff. The new gcc snapshot fixes some annoying segfaults I had with 4.0.1. Very nice.

Exner · Post by **Exner** » Sun Aug 07, 2005 11:56 pm

If you have just upgraded from gcc-4.0.1 to gcc-4.0.2 would it be a good idea to run

Code: Select all

/sbin/fix_libtool_files.sh 4.0.1

Exner · Post by **Exner** » Mon Aug 08, 2005 12:02 am

I happened to do this:

Code: Select all

localhost gcc # ldd /usr/lib/gcc/i686-pc-linux-gnu/4.0.1/libgcc_s.so
ldd: warning: you do not have execution permission for `/usr/lib/gcc/i686-pc-linux-gnu/4.0.1/libgcc_s.so'
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/libc.so.6 (0x448a9000)
        /lib/ld-linux.so.2 (0x80000000)

Should not that library be executable?

rhill · Post by **rhill** » Mon Aug 08, 2005 3:33 am

Exner wrote:Should not that library be executable?

nope. it's not for me anyways.

my ebuild is nothing but a src_unpack function to apply the patches. everything else is done by toolchain.eclass. if the 4.0.1 ebuild doesn't cause this to happen, it's got to be a versioning oops. i bet there's a misplaced ${GCC_CONFIG_VER} somewhere.

rhill · Post by **rhill** » Mon Aug 08, 2005 5:00 am

i swear half my postcount is in this thread.

perl-5.8.7 is now broken with gcc-4.0 snapshots due to a patch that adds -fno-stack-protector to CFLAGS.

https://bugs.gentoo.org/show_bug.cgi?id=97452

solar has indicated this is WONTFIX. the workaround to the problem is

Code: Select all

--- /usr/portage/dev-lang/perl/perl-5.8.7.ebuild        2005-08-03 21:05:29.000000000 -0600
+++ perl-5.8.7.ebuild   2005-08-07 15:46:21.000000000 -0600
@@ -120,7 +120,7 @@
        # with ssp enabled. This become fatal during compile time so we
        # temporally disable ssp on two regexp files till upstream has a
        # chance to work it out. Bug #97452
-       epatch "${FILESDIR}"/${P}-regexp-nossp.patch
+       gcc-specs-ssp && epatch "${FILESDIR}"/${P}-regexp-nossp.patch
 }

 src_configure() {

Xake · Post by **Xake** » Mon Aug 08, 2005 1:36 pm

@dirtyepic:

Code: Select all

i686-pc-linux-gnu-gcc ../sysdeps/unix/sysv/linux/ssp.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -march=pentium4 -pipe -mpreferred-stack-boundary=4  -fno-stack-protector   -I../include -I. -I/var/tmp/portage/glibc-2.3.5.20050722/work/build-default-i686-pc-linux-gnu-nptl/csu -I.. -I../libio -I../nptl -I/var/tmp/portage/glibc-2.3.5.20050722/work/build-default-i686-pc-linux-gnu-nptl -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/i386/i686 -I../nptl/sysdeps/i386 -I../nptl/sysdeps/generic -I../libidn/sysdeps/unix -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.0.2/include -isystem /usr/include -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h       -DHAVE_INITFINI -o /var/tmp/portage/glibc-2.3.5.20050722/work/build-default-i686-pc-linux-gnu-nptl/csu/ssp.o -MD -MP -MF /var/tmp/portage/glibc-2.3.5.20050722/work/build-default-i686-pc-linux-gnu-nptl/csu/ssp.o.dt -MT /var/tmp/portage/glibc-2.3.5.20050722/work/build-default-i686-pc-linux-gnu-nptl/csu/ssp.o
cc1: error: unrecognized command line option "-fno-stack-protector"
make[2]: *** [/var/tmp/portage/glibc-2.3.5.20050722/work/build-default-i686-pc-linux-gnu-nptl/csu/ssp.o] Fel 1

This is with your gcc-4.0.2_beta20050804.ebuild

Any workaround for this or is there a version of glibc not affected?

asimon · Post by **asimon** » Mon Aug 08, 2005 2:06 pm

Xake wrote:Any workaround for this or is there a version of glibc not affected?

The patch from dirtyepic on page 25 of this thread works fine. Here is the patch again:

Code: Select all

--- /usr/portage/sys-libs/glibc/glibc-2.3.5.20050722.ebuild   2005-07-29 16:35:58.000000000 -0600 
 +++ glibc-2.3.5.20050722.ebuild   2005-07-31 19:47:31.000000000 -0600 
 @@ -1193,6 +1193,9 @@ 
     # disable binutils -as-needed 
     sed -e 's/^have-as-needed.*/have-as-needed = no/' -i ${S}/config.make.in 
   
 +   # disable -fno-stack-protector as GCC4 doesn't support it 
 +   sed -e 's/^CFLAGS-ssp.c.*//' -i ${S}/sysdeps/unix/sysv/linux/Makefile 
 + 
     # Glibc is stupid sometimes, and doesn't realize that with a 
     # static C-Only gcc, -lgcc_eh doesn't exist. 
     # http://sources.redhat.com/ml/libc-alpha/2003-09/msg00100.html

This kind of error will probably not get fixed in portage (at least not by applying conditional patches to affected ebuilds) -- see dirtyepics last post.