About GCC 4.8.x branch...

[SiZiOUS]

Hi there,

Long time no see heh?
Last week I've restarted my quest about making a brand new DC toolchain based on GCC 4.8.2 under MinGW.
And guess what? Success

I think I'll make a updated tutorial for those who wants to use MinGW instead of Cygwin.
I made some (littles) fixes in the KOS to make this possible. I think I'll submit these modifications to the KOS repository.
For me I prefer MinGW, it's more lightweight and more "self-contained", that means the MinGW installation is fully portable...

So, everything is working now under MinGW, the only one program that I can't compile is genromfs, I started to use GnuLib to make it compatible with the MinGW environment, the application is compiling now but it generates empty romdisks... Nevermind, I'll try to find a solution for that later. I'm using a Cygwin binary instead for this specific program, but everything else compiles fine under MinGW (including dcload-ip/dctool-ip, etc.).

But the problem I often read on that forum is some stability issues with GCC 4.8.x branch (e.g. SWAT stills use GCC 4.7.3).
So what's the recommanded GCC build revision for the DC platform?

Every DC samples are compiling in my environment, but I don't have tested to run them...
I think I should do that and post some results.

Thank you for your time,

Mike

[BlueCrab]

The recommended GCC build (i.e, the latest one that I have tested and found working properly) is GCC 4.7.3. Basically, whatever version of GCC is built by default in dc-chain at the time is the recommended version for KOS.

If I recall correctly, GCC 4.8.2 was generating instructions improperly around delayed branches on SuperH. It's been a while since I looked, so I might be wrong on that...

Compilers are one part of a system where newer is definitely not always better.

[SiZiOUS]

Thanks BlueCrab.

I saw there's a patch for GCC 4.8.2, that's why is used that version.
Does that means the use of that patch isn't recommended at all for that version?
If yes I guess I'm good to recompile my toolchain in 4.7.3

PS: Btw, what's the procedure to submit to the KOS repo? Since I made some littles and not intrusives fixes to compile under MinGW, I think it'd be nice if these modifications are integrated in the standard (of course with your validation).

[BlueCrab]

The patches are there, yes, but there was an issue discussed a while back on the forums that resulted in the version being rolled back to 4.7.x in dc-chain. I do tend to update the READMEs and such when new versions should be recommended (and I keep dc-chain itself up-to-date with what I'm using), so always look to what's in the README files and such to see what I'd recommend.

As for 4.8.x, if you're interested in why I'd highly recommend against it... I finally dug up the one post where I mentioned the issues I saw with it:

Yeah that's it! So sorry of course, binaries from 4.8 more compact

That's believable that they got smaller, but there were a few problems in the 4.8.x branch of GCC regarding branching and the T-bit that are still unresolved in that branch (although, I believe they said that they are fixed in the trunk -- so, they'll be fixed for 4.9.x). I noticed a very noticeable framerate drop in CrabEmu when compiled with 4.8.x that is related to those issues.

As for why I haven't looked into 4.9.x at all... Well, I haven't really found any need to do so. That, and some of the early 4.9.x releases were even pretty broken for x86 and x86-64, so I didn't really trust them on the much lesser-used targets like SuperH.

EDIT: Just noticed one somewhat nasty looking optimization bug in 4.9.x for SuperH (that seems to be resolved in 5.0.0): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151 ... By the way, if you're ever looking at what bugs happen to exist in GCC for SuperH, here's a handy link: https://gcc.gnu.org/bugzilla/buglist.cg ... h=%5BSH%5D

I'll probably end up looking at whether a GCC update changes things sometime after GCC 5.0.0 comes out...

[SWAT]

But the problem I often read on that forum is some stability issues with GCC 4.8.x branch (e.g. SWAT stills use GCC 4.7.3).
So what's the recommanded GCC build revision for the DC platform?

I use GCC 4.9.1, it's works much better than 4.7.x/4.8.x and I not have problems.
And now I have builded 4.9.2 but not tested it yet properly.

You can get some problems with 4.9.x if you will use optimization level 3, but not at all cases, just in some. The KallistiOS uses level 2 by default, so I think it's not a big problem. Only new libgl used level 3, but changing this level to 2 can solve compiling problem.

[BlueCrab]

I use GCC 4.9.1, it's works much better than 4.7.x/4.8.x and I not have problems.
And now I have builded 4.9.2 but not tested it yet properly.

You can get some problems with 4.9.x if you will use optimization level 3, but not at all cases, just in some. The KallistiOS uses level 2 by default, so I think it's not a big problem. Only new libgl used level 3, but changing this level to 2 can solve compiling problem.

The one that I linked to in my last post shows up in any optimization level (-O1, -Os, -O2, -O3). Perhaps it doesn't happen often, but it is still a bug in all optimization levels on SuperH.

There seem to be those kinds of bugs quite often with SuperH, which is why we've often had optimization disabling flags as part of the default KOS_CFLAGS (two that come to mind that we've had to use in the past are -fno-optimize-sibling-calls and -fno-crossjumping).

It does look like the SuperH code has been getting a lot more of a look lately (most of the bugs in that list I linked to in my last post are enhancements and not actually bugs), so I'd like to think that some of the ugly problems of the past might be working themselves out.

[Jae686]

I just use the default one. If it works, well.......