Opened 10 years ago

Closed 9 years ago

#4204 closed enhancement (fixed)

Incorporation of GCC 4.4

Reported by: jprostko Owned by: jprostko
Priority: normal Milestone: R1
Component: Build System Version: R1/pre-alpha1
Keywords: Cc: planche2k@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (3)

gcc-4.4-compatibility.diff (951 bytes ) - added by jprostko 10 years ago.
Fixes to Haiku code to allow it to build under GCC 4.4
gcc-4.4.1-diff (56.0 KB ) - added by jprostko 10 years ago.
Patch to core/g++ of GCC 4.4.0/4.4.1 (current through Haiku hrev32679)
intel-atom-optimization.diff (124.5 KB ) - added by jprostko 10 years ago.
Optional patch to allow Intel Atom optimizations in GCC 4.4.1

Download all attachments as: .zip

Change History (22)

by jprostko, 10 years ago

Attachment: gcc-4.4-compatibility.diff added

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

comment:1 by andreasf, 10 years ago

Cc: planche2k@… added

by jprostko, 10 years ago

Attachment: gcc-4.4.1-diff added

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

by jprostko, 10 years ago

Optional patch to allow Intel Atom optimizations in GCC 4.4.1

comment:2 by mmadia, 10 years ago

Owner: changed from bonefish to jprostko

comment:3 by kaliber, 9 years ago

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.

comment:4 by korli, 9 years ago

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.

comment:5 by korli, 9 years ago

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

comment:6 by jprostko, 9 years ago

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.

comment:7 by korli, 9 years ago

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.

in reply to:  7 comment:8 by bonefish, 9 years ago

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.

comment:9 by korli, 9 years ago

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

comment:10 by jprostko, 9 years ago

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.

in reply to:  10 ; comment:11 by bonefish, 9 years ago

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.

in reply to:  11 comment:12 by jprostko, 9 years ago

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.

comment:13 by tqh, 9 years ago

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

in reply to:  13 comment:14 by jprostko, 9 years ago

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.

comment:15 by mmadia, 9 years ago

can this be closed now?

in reply to:  15 ; comment:16 by korli, 9 years ago

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.

comment:17 by anevilyak, 9 years ago

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

in reply to:  15 comment:18 by jprostko, 9 years ago

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.

in reply to:  16 comment:19 by mmadia, 9 years ago

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.