GCC 4.0

Message

PrakashP · Post by **PrakashP** » Sun Jun 13, 2004 8:26 pm

Well, I gave today's snapshot a go with bison.
CFLAGS="-march=athlon-xp -mtune=athlon-xp -O# -pipe"

#=0: OK, all tests passed.

#=1:
[GNU Bison 1.875] testsuite: 4 27 34 36 37 39 40 41 42 44 47 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 89 93 94 95 96 97 98 99 100 101 102 103 104 failed

#=2:
[GNU Bison 1.875] testsuite: 27 34 47 87 89 94 failed

Could anybody explain, why a *higher* optimization level actually b0rks less?

spb · Post by **spb** » Sun Jun 13, 2004 8:40 pm

There's a new snapshot? That's something to look at tomorrow, after exams. I'm meant to be revising, and keep getting distracted.

ShadowHawkBV · Post by **ShadowHawkBV** » Mon Jun 14, 2004 1:22 am

Just a word of thanks to you all who know what you're doing and make time to help improve things for the rest of us dopey plugs. I'm hoping that by this time next year I'll be able to join in on the insanity and make m'self useful.

Cheers to you all.

robmoss · Post by **robmoss** » Mon Jun 14, 2004 7:02 am

I'm going to start work on this again next week. Nearly finished my exams now...

PrakashP · Post by **PrakashP** » Mon Jun 14, 2004 8:12 am

Something else which came into my mind:

As we are experimenting with a broken compiler, how wise is the bootstrapping process? I mean I don't think that the compiler will get better if it compiles itself as it is broken. So the result will probably miscompile even more. Shouldn't we change the ebuild so that in a single shot the compiler gets emerged using a safe compiler?

robmoss · Post by **robmoss** » Mon Jun 14, 2004 8:16 am

It bootstraps fine, although I wouldn't compile anything else critical with it yet.

PrakashP · Post by **PrakashP** » Mon Jun 14, 2004 8:24 am

Well, have you tried a bootstrapped version against a -say- gcc-3.5 compiled by gcc-3.4 version? I hope you understood what I was trying to say...

robmoss · Post by **robmoss** » Mon Jun 14, 2004 1:20 pm

No, I know exactly what you mean. Don't worry, it's safe. The tarball doesn't get released unless it bootstraps correctly. What it does once that has finished is a different matter entirely...

You could always read up on how to use the testsuite, if you're sufficiently paranoid.

PrakashP · Post by **PrakashP** » Tue Jun 15, 2004 9:55 am

Has anyone tried to compile kdelibs-3.3.0_alpha1?

It gives several errors, but I don't understand why the code should be wrong.

Code: Select all

In file included from kab2kabc.cpp:36:
stdaddressbook.h:129: Fehler: `Addressee' does not name a type
stdaddressbook.h:136: Fehler: expected `,' or `...' vor »&«
stdaddressbook.h:136: Fehler: ISO C++ forbids declaration of `Addressee' with no type
kab2kabc.cpp:48: Fehler: »KABC::AddressBook« wurde nicht deklariert
kab2kabc.cpp:49: Fehler: ISO C++ forbids declaration of `ab' with no type
kab2kabc.cpp: In function `void readKMailEntry(constQString&, int*)':
kab2kabc.cpp:107: Fehler: »KABC::Addressee« wurde nicht deklariert
kab2kabc.cpp:107: Fehler: `List' was not declared in this scope

The first error can be fixed, by adding #include addressee.h (or alike) in the stdaddressbook.h. Already this seems to be ridiculous to me, as another file is included which as such includes addressee.h. So why the necessity to include it explicitly?
The second one cannot be properly fixed (in my eyes). There is some sort of namespace trouble which seems to be a compiler bug to my believes, but I could be wrong. kab2kabc.cpp includes the file which declares AddressBook in the namespace KABC, so I don't understand above error. When I del the KABC:: it will go further, but then complain later about functions not being members in Addressbook. kab2kabc.cpp is "using namespace KABC", so why the heck doesn't it work out?

Nekkrist · Post by **Nekkrist** » Wed Jun 16, 2004 2:56 am

Oh god I can't believe I'm actually going to try installing this. Oh well, here goes...

robmoss · Post by **robmoss** » Wed Jun 16, 2004 11:11 am

Even I think you're mad. Don't actually expect anything to work. Most things miscompile, and quite badly. Unless you're actually trying to contribute some development work to GCC, I wouldn't bother (or, in my case, 3.5-specific patches for Gentoo which will still be necessary once 3.5 is released as stable).

If you're after a bleeding-edge compiler, use 3.4 CVS instead - things will actually work!

spb · Post by **spb** » Wed Jun 16, 2004 11:30 am

Quite. Installing this compiler won't break your system, but trying to use it will.

My project once I'm done with exams will be to try to get glibc to compile properly and pass the testsuites.

Nekkrist · Post by **Nekkrist** » Wed Jun 16, 2004 3:42 pm

I'm quite willing to both risk a broken system as well as contribute gcc3.5 patches. I'm getting some things to go ahead and compile (though I can't really figure out why one version of binutils is failing on src_unpack() but thats a different story) I'm just not quite sure if I'm interpreting the broken code correctly. Oh well, I'll go back and verify that the patches do what they are supposed to and not just get it to compile before I submit anything.

Now, if only I could figure out how to use the testsuite I could contribute better, could anyone point me in the right direction (from the beginning please, The only mention of such a testsuite in this thread is dejagnu, but I can't find a manpage or anything on it). If there's a manpage or howto on how (and what!) to use just point me in that direction and I can figure it out from there. Of course if you want to lay out exactly what you're doing so I can do the same, that would be good too, but a decent manpage/faq or something works great.

robmoss · Post by **robmoss** » Wed Jun 16, 2004 3:48 pm

portage-2.0.51_pre9 has integrated support for the use of testsuites and uses them automatically. 2.0.51_pre10 does too, but I can't for the life of me figure out how to use them! However, certain packages will need a testsuite writing - the relevant ebuild function is called dyn_test.

spb · Post by **spb** » Wed Jun 16, 2004 8:16 pm

Hmm...now I remember why I went back to portage-2.0.50 last time:

Code: Select all

$ sudo emerge -uDa world
Password:

These are the packages that I would merge, in order:

Calculating world dependencies |~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.2.5-r9
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.2.5-r9
~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.1-r5
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.1-r5
~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.2-r10
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.2-r10
~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.2-r2
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.2-r2
~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.2-r9
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.2-r9
~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3.20040420
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3.20040420
~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3_pre20031210
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3_pre20031210
~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3_pre20040117
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3_pre20040117
~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3_pre20040207
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3_pre20040207
~x86
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3_pre20040420
QA Notice: USE Flag 'debug' not in IUSE for sys-libs/glibc-2.3.3_pre20040420
~x86

Et cetera, et cetera, et cetera. What with those and 'has_version() in global scope', it filled up gnome-terminal's buffer several times over. It's probably worth it for integrated testsuite support though.

robmoss · Post by **robmoss** » Wed Jun 16, 2004 10:10 pm

Oooh, I've been stickied!

And they even saved it so I could celebrate my first ever sticky thread with my 2000th post...

Anyway, yes. Expect some heavy development on this in the coming weeks. I've got nothing better to do...

fca · Post by **fca** » Thu Jun 17, 2004 2:46 pm

I've been playing with gcc 3.5 for some time now (and with tree-ssa before it got merged) and I must say that I'm impressed by the code speed. Some simple computational programs I've written (say, a random polymer generator using a slithering snake algorithm) ran twice as fast compiled with gcc 3.5 as compiled with gcc 3.4. Lame encoding was just a tad slower though, and it wouldn't compile dosbox. This actually brings it close to the performance of ICC.
I wouldn't dare to try compile KDE or something like that with it. Maybe when it enters stage 2...
And I'm really interested in what the lno branch merge will do for perfomance.

PrakashP · Post by **PrakashP** » Thu Jun 17, 2004 3:06 pm

I treid kde to simply fix the code and not to get it working. I gave up on getting gcc3.5 packets working. It is too seriously broken.

Anyone with bright c++ knowledge here who could take a look at above issue? The more I think about it the more I am sure gcc3.5 has some wrong namespace parsing. It doesn't seem to see the KABC namespace stuff defined in addressbook.h, that's why the error messages pop up.

Post by **dsd** » Thu Jun 17, 2004 6:18 pm

robmoss2k wrote:Current list of broken packages: [...] easytag,[...]

what are the compile errors with this one? assuming its a problem with the code rather than a bug in GCC, i'll look into it..

spb · Post by **spb** » Thu Jun 17, 2004 6:33 pm

dsd wrote:
robmoss2k wrote:Current list of broken packages: [...] easytag,[...]
what are the compile errors with this one? assuming its a problem with the code rather than a bug in GCC, i'll look into it..

There are no compile errors with the current snapshot. It seems to run, too. Haven't done exhaustive testing, but there doesn't seem to be a lot to do to it right now.

Edit: Having said that, I'm getting this consistently:

Code: Select all

The program 'easytag' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 81942 error_code 3 request_code 38 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I wouldn't normally bug you with it, but you did ask...

Nekkrist · Post by **Nekkrist** » Fri Jun 18, 2004 4:02 am

I know I'm crazy for even trying with mplayer, but I thought I'd at least try to get it to compile and see what happened. I think that this is just a cast of an int to an int, so it can just be removed (if I'm not making a silly oversight, see what you think).

Code: Select all

static int WINAPI expGetWindowThreadProcessId(HWND win, int *pid_data)
{
    int tid = pthread_self();
    dbgprintf("GetWindowThreadProcessId(0x%x, 0x%x) => %d\n",
	win, pid_data, tid);
    if (pid_data)
	    (int)*pid_data = tid;
    return tid;
}

I just patched it by removing the (int). Am I wrong? Looks like a cast of a dereferenced int pointer to an int for the purpose of storing an int.

Anyway, here's the patchfile (really simple I know...).

Code: Select all

--- MPlayer-1.0pre4/loader/win32.c.orig 2004-04-23 07:50:23.000000000 -0400
+++ MPlayer-1.0pre4/loader/win32.c      2004-06-17 23:08:14.730667198 -0400
@@ -2666,7 +2666,7 @@
     dbgprintf("GetWindowThreadProcessId(0x%x, 0x%x) => %d\n",
        win, pid_data, tid);
     if (pid_data)
-       (int)*pid_data = tid;
+       *pid_data = tid;
     return tid;
 }

The ebuild then goes on to fail at something apparently concerning registers...something I don't have enough knowledge about to go poking around "fixing" things.

Code: Select all

i386/dsputil_mmx.c: In function `h263_h_loop_filter_mmx':
i386/dsputil_mmx.c:633: error: can't find a register in class `GENERAL_REGS' while reloading `asm'
make[1]: *** [i386/dsputil_mmx.o] Error 1

Is this possibly because I didn't compile glibc with gcc 3.5 (well, I don't think I did anyway)?

Oh, one more thing. If I were to chroot onto some other disk and start with a stage1 or 2 install, wouldn't that be a way to have my safe system intact (not to mention running while I play with gcc 3.5) with the sketchy gcc 3.5 system isolated from my real system? Let me know, maybe I'll do that if that would work as expected...

eissimuf · Post by **eissimuf** » Fri Jun 18, 2004 1:31 pm

With regard to removing that cast, this page: http://gcc.gnu.org/onlinedocs/gcc-3.3.3 ... ml#Lvalues seems to say that you can remove it, since it would be the same as:

Code: Select all

(int)(*pid_data = (int)(int)tid)

Anyone more familiar with lvalue casting in gcc care to comment?

windzor · Post by **windzor** » Fri Jun 18, 2004 5:05 pm

Oh, one more thing. If I were to chroot onto some other disk and start with a stage1 or 2 install, wouldn't that be a way to have my safe system intact (not to mention running while I play with gcc 3.5) with the sketchy gcc 3.5 system isolated from my real system? Let me know, maybe I'll do that if that would work as expected...

Maybe look at UserMode Linux?

spb · Post by **spb** » Fri Jun 18, 2004 5:15 pm

windzor wrote:
Oh, one more thing. If I were to chroot onto some other disk and start with a stage1 or 2 install, wouldn't that be a way to have my safe system intact (not to mention running while I play with gcc 3.5) with the sketchy gcc 3.5 system isolated from my real system? Let me know, maybe I'll do that if that would work as expected...
Maybe look at UserMode Linux?

No need. Running it inside a chroot is more than adequate for testing new systems, unless you're testing the kernel or init scripts. Kernels generally compile without problems, and the init scripts are mostly Bash, so there's no need.

But as for starting a stage2 install with it, good luck. Several packages in system miscompile in subtle ways. An example: last time I tried it, glibc was miscompiled, and this didn't show up until it tried to install wget.

Nekkrist · Post by **Nekkrist** » Fri Jun 18, 2004 6:26 pm

Out of curiosity, how did you realize it was glibc that was miscompiling? Some sort of linker error perhaps?

GCC 4.0

Re: GCC 3.5

Re: GCC 3.5