[haiku-development] Re: Updating Haiku's GCC4 to 4.4.1
- From: Joseph Prostko <joe.prostko+haiku@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 23 Jul 2009 11:59:23 -0400
On Thu, Jul 23, 2009 at 8:58 AM, Ingo Weinhold<ingo_weinhold@xxxxxx> wrote:
>
> On 2009-07-23 at 12:57:06 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> wrote:
>> Joseph Prostko <joe.prostko+haiku@xxxxxxxxx> wrote:
>> > As some of you may know, I have been doing work on a Haiku-ready GCC
>> > 4.4. Today GCC 4.4.1 was released, and I am going to do some testing
>> > with that in a bit to make sure it still seems nice and stable.
>>
>> At least former GCC releases showed that it's usually a good idea to be
>> a bit conservative with updating.
Yeah, I don't mean we have to update it right this instant, but wanted
to let you know at least that option is pretty much possible right
now.
>
> Agreed in principle. Nevertheless it would be nice to have the newer
> version more readily available (ideally as optional package).
I could easily make an optional package, but obviously I'd have to
provide the changes that were made. I tried to keep intact as much of
the 4.3.3 changes as possible, but changed a few things here and there
to make it easier to get the fixes into GCC's tree at some point.
Maybe we can just have 4.3.3 be the default GCC4 optional package, but
have GCC 4.4.1 as an "experimental" package or the like...at least
until it is proven stable and supplants the 4.3 package.
>> > You can all let me know your take on this about the best way to
>> > proceed.
>>
>> Best is to provide a patch, I would guess.
>
> That wouldn't work particularly well, since we'd also have to update the
> vendor branch. A branch is probably a good idea.
Yeah, GCC 4.4 would require a new vendor branch due to a large amount
of changes between GCC 4.3 and GCC 4.4 . The other issue is two more
dependencies will be needed with GCC 4.4 if we decide we want Graphite
support. These are PPL and ClooG-PPL. I think it would be good to
have these present, and build in Graphite support at the end-user's
discretion. That said, building in Graphite isn't required by any
means (at least right now), so this could easily be skipped as well,
and would make updating the buildtools much easier. People might not
like the increased time to build the extra dependencies though, but
like I said, I'd like it to only be built by those who explicitly
request it. I still want to do more testing to see the benefit or not
of Graphite though in general. I suspect Graphite will be most
valuable on targets with plenty of available registers.
I suppose I could provide a patch that can be applied to a clean GCC
4.4.1 core/g++ download in an enhancement ticket if you guys want.
Naturally one of the devs would have to do all the other work though
unless you guys want me to take care of things. It would be pretty
straightforward if Graphite is left out. If not, matters get
complicated quite a bit. Manageable, yes, but also more work.
I am currently redoing a tiny part of the patch to make it not break
other platforms (not really necessary since it'd live in our repo), so
I could probably file a ticket later tonight or tomorrow morning once
I get that done and blow through a build to make sure I didn't make a
syntax error or the like.
So, should I file an enhancement and go from there?
- joe
Other related posts:
