Incorporation of GCC 4.4

[jprostko]

The purpose of this ticket is to allow Haiku to utilize the current release series of GCC, which is GCC 4.4. The current release version in this series is 4.4.1.

I am only going to address this topic within a limited scope, leaving out details such as inclusion of the Graphite loop optimization framework, native versus cross-building, etc. This would need more patches and further discussion/details, which I think would be too much all at once.

Thanks to korli and stippi, most of the patches needed to get Haiku building with GCC 4.4 have already been committed. Currently two files need patched, however. A patch fixing those issues is attached as gcc-4.4-compatibility.diff.

With regards to the patch to GCC itself, it is very similar to what is in our repository now for GCC 4.3.3, but with some fixes/cleanup. I also put in some code to prevent a native build from failing upon bootstrap comparison. The patch is to be applied to the GCC 4.4.1 core and g++ packages that can be obtained from the GCC FTP (GCC 4.4.0 will work as well). This will make it easy to work on if a vendor branch for GCC 4.4.1 was introduced, for instance.

In addition to the steps above, MPFR in the buildtool repository will need updated to version 2.3.2 or higher as required by GCC 4.4.

As mentioned on the development mailing list previously, there is still an issue where GCC 4.4.1 miscompiles the Tracker on certain specific revisions. The latest revision of Haiku (hrev32211 as of this ticket) doesn't have this problem, but some previous ones certainly did. I am not sure if it will ever creep up again, but I have all of the details documented so I can investigate further, and have also filed a bug with the GCC folks so it is at least documented on their end.

I would like to state that I'd be willing to work on the latest GCC (and its dependencies, as well as updated binutils) in a branch if desired, since I have a pretty good working knowledge of building GCC by now, both in a native and cross-compiled environment. I can also provide an optional package if/when desired, with or without Graphite included.

I know the Haiku alpha is around the corner and this may be put on the backburner, but I felt it was important to at least get this enhancement in place to show current progress.

Also, just for reference, GCC 4.3.4 came out recently, so if we want to hold off on GCC 4.4 for some time, perhaps we can at least upgrade to that in the near future.

[jprostko]

Fixes to Haiku code to allow it to build under GCC 4.4

[jprostko]

Patch to core/g++ of GCC 4.4.0/4.4.1 (current through Haiku hrev32679)

[jprostko]

Optional patch to allow Intel Atom optimizations in GCC 4.4.1

[kaliber]

GCC 4.5 is available. Using gcc-4.5 and gcc-4.4-compatibility.diff patch Haiku compiles cleanly. I think we should upgrade gcc to 4.5 and send changes upstream.

[korli]

I don't know if it's a good idea to upgrade when we release soon. Maybe this can wait just after, this will give us time in case of regressions.

[korli]

Now r1a2 is released, could we see which version to update to ? 4.4.4 or 4.5.0 ?

[jprostko]

Yeah, it'd probably be good to go with 4.5.0. There are some upcoming changes in GCC though that will probably make PPL 0.11 a requirement, and I'm trying to find out more about this in case I'm mistaken. PPL 0.11 should be out this month, but it won't work with GCC 4.5.0 without some patching. It should work with 4.5.1 though when that comes out. PPL 0.11 does have some changes I got pushed though that makes building it on Haiku less of a headache as compared to 0.10.2.

One thing, I do want to check before I move forward is to see if there are regressions still present that showed up with GCC 4.4.1 that resulted in improper builds of tracker and media_addon_server (and maybe other items) with certain -O1 optimizations. It bummed me out before having to disable some optimizations just to build Haiku properly. Testing out the LTO introduced in 4.5 would probably be a good idea as well. (Maybe kaliber has explored all of this already though.)

In summary, 4.5.0 would be cool, but waiting for 4.5.1 could be good too. Then again, waiting significant amounts of time (for me or the GCC guys) isn't exactly a good utilization of time, necessarily.

In any case, I agree we should get an update done before the next release, and that getting it done with breathing room would be a good idea.

I'll accept the ticket once I do some more prodding, although if you want to jump on things, you could feel free to reassign it to yourself as well.

[korli]

After all, I'd keep the upgrade simple for the time being and go with 4.4.4. We don't need the bleeding edge of gcc.

[bonefish]

Replying to korli:

After all, I'd keep the upgrade simple for the time being and go with 4.4.4. We don't need the bleeding edge of gcc.

From past experience I'd say we don't even want any gcc x.y.0 version. They usually come with new problems and we have a sizable code base to trigger them. I would wait at least until x.y.1 or even better x.y.2 (unless there's an urgently needed feature). So yes, ATM updating to the 4.4 series sounds about perfect.

[korli]

gcc-4.4-compatibility.diff is applied in hrev36954.

[jprostko]

Thanks for applying that, Korli. I suppose I could have applied that, but figured it could wait until the other pieces were dropped into place.

Real life is kind of messing with me again, but I hope to at least get some vendor drops done within the next week or so once I can get back to using the computer that has the right environment to let that happen. The 4.4 update may be kept simpler than I initially planned, leaving out Graphite support, as I think it may be better to bring that stuff in with 4.5. We'll see though.

A quick question...

Since the update will live within our buildtool repository, are we only going to worry about core/g++ for GCC? I mean, I could see us releasing an optional package with Objective-C/C++, Fortran, etc., but should those components of GCC live in our repository or elsewhere? I figure anything above and beyond C/C++ should probably live somewhere else, seeing as that isn't needed to actually build Haiku.

[bonefish]

Replying to jprostko:

Since the update will live within our buildtool repository, are we only going to worry about core/g++ for GCC? I mean, I could see us releasing an optional package with Objective-C/C++, Fortran, etc., but should those components of GCC live in our repository or elsewhere? I figure anything above and beyond C/C++ should probably live somewhere else, seeing as that isn't needed to actually build Haiku.

I would keep non C/C++ related changes out of the repository. Moreover all patches for the current gcc/binutils should be upstreamed eventually (no one was motivated enough to do that yet), so that our repository will basically be a copy of the vendor sources.

[jprostko]

Replying to bonefish:

I would keep non C/C++ related changes out of the repository. Moreover all patches for the current gcc/binutils should be upstreamed eventually (no one was motivated enough to do that yet), so that our repository will basically be a copy of the vendor sources.

Okay, sounds good. And yes, it would make everything a lot easier if these were committed upstream. I believe the GCC guys won't accept patches for ports unless a full testsuite is run and they are given the results. I know that requires Tcl/Expect/DejaGNU to be working on a given platform. I think we need some porting work to get those all going, but admit I didn't check out HaikuPorts just yet to verify.

I'll probably ask around again though just in case the testsuite run is just preferred, not required.

[tqh]

Saw that the first patch was commited in hrev36954, so I added the obsolete flag on that patch.

[jprostko]

Replying to tqh:

Saw that the first patch was commited in hrev36954, so I added the obsolete flag on that patch.

Thanks. I hope to get on this soon (I know, I have said that far too many times by now). If I'm lucky I'll do something tonight, but I think I'll just say that I'll get to it in the near future when I can.

[mmadia]

can this be closed now?

[korli]

Replying to mmadia:

can this be closed now?

A native gcc 4.4 package is yet to be tested and integrated as an optional package.

[anevilyak]

I didn't find time to test that one yet sorry, will try to sometime this week.

[jprostko]

Replying to mmadia:

can this be closed now?

Probably, although I don't know the state of the zip that Korli produced, as I haven't had a chance to look at it yet. The normal culprits are linking in iconv and the like accidentally. Also, binutils were not updated, and that kind of comes along for the ride on the optional GCC package.

I think the choice of MPFR and GMP versions to integrate could potentially cause problems though. I see Korli addressed the obvious, but staying at MPFR 2.4.2 and GMP 4.3.2 would have made more sense, seeing as the GCC guys don't support the versions imported at all, plus those bleeding-edge versions break GRAPHITE support entirely.

That said, months down the road the currently-imported GMP/MPFR versions will probably be a non-issue, especially having to bring in MPC as another build requirement. So yeah, it could all be for the best while keeping the future in mind.

I also know that there used to be regressions with 4.4, but if they are gone now, then good stuff. Otherwise, if Tracker and media_addon_server start acting up (Tracker not drawing icons, and there being no sound in GCC4 pure/hybrid builds), 4.4 is probably to blame due to the nature of some -O1 optimizations.

I do thank Korli for doing what should have been my work. This is the first chance I've had to really check in lately, and appreciate he stepped in while my heels were (and are pretty much still) dragging.

[mmadia]

Replying to korli:

Replying to mmadia:

can this be closed now?

A native gcc 4.4 package is yet to be tested and integrated as an optional package.

Applied in hrev38723. If by some chance, there are any issues with the package, they would be filed as new tickets.