[oe] [PATCH] gcc: introduce version 4.5.2

[Andreas Oberritter]

On 12/16/2010 01:48 AM, Khem Raj wrote:
> On Wed, Dec 15, 2010 at 4:21 AM, Andreas Oberritter
> <obi at opendreambox.org> wrote:
>> On 12/10/2010 03:54 AM, Khem Raj wrote:
>>> On Thu, Dec 9, 2010 at 4:44 PM, Eric Bénard <eric at eukrea.com> wrote:
>>>> - based on gcc-4.5.2-RC-20101208 (svn 167585)
>>>> - without linaro patches (which seem to be the root of
>>>> problems when compiling at least on armv4 and armv5) :
>>>>        - samba 3.2.15 or 3.3.9 : http://tinderbox.openembedded.net/public/logs/task/8666826.txt
>>>>        - samba 3.5.6 : http://pastebin.com/yuiYX2CM
>>>>
>>>
>>> as discussed on IRC may be we should try to find the faulty patch in
>>> current gcc 4.5 linaro patches we have.
>>
>> I don't think that we need another svn-based pre-release recipe for gcc.
>> But I would still prefer to have a recipe for gcc 4.5.2 once it's
>> released, because I'd like to be able to pin a stable version with only
>> few required patches and Linaro only cares about ARM while I do not.
>>
> 
> We should avoid creating recipes for every minor release. As we see
> minor release only contain bug fixes.

What's wrong with bug fixes in minor releases? Btw., I have no problem
moving from one minor release to another, which means that I would be
happy with only one recipe for every major release.

> agreed. If you dont care about linaro thats fine. Would you prefer a
> gcc which is widely used or just used by you
> hence supported only by you.

I'd prefer a gcc which is widely used. We just seem to have different
opinions on what that means. IMO, a released version will surely be used
by many more people globally (i.e. outside OE) than a random svn version
of a linaro gcc. Also, since Eric already sent this patch, I'm sure that
I'm not the only one who'd prefer to have a recipe for a current,
released version in OE.

While gcc*_4.5.bb is widely in use (well, because it's the default
recipe and there is no alternative for 4.5 yet), its revision and linaro
patch level changes every other day. It went from r10 to r25 during the
last 10 weeks. This wastes a lot of time rebuilding the compiler, or -
if you don't want to mix different gcc's output - rebuilding the whole
system. In comparison, gcc-4.4.4 is still at r7.

> My point it more common we use better we
> have the support for it and community as a whole gets benefitted. If
> linaro patches dont
> harm your case negatively would you still be averse to them ? Do you
> have some cases where they created regressions compile time or run
> time or degraded the performance ?
> that will be interesting.

I haven't discovered any regressions by the compiler itself, but I also
haven't discovered any benefits.

My main concern is that a weekly changing compiler can hardly ever
become a good foundation of a stable build environment. Of course I
could pin a random SRCREV, but then again I'm likely to become the only
user of this specific SRCREV globally, some day. Oh, wait, I can not pin
a SRCREV, because the patches keep getting added as local files.

> why do you think gcc-4.5.2 will be more stable then say gcc-4.5.2 +
> patches from upstream 4.5 branch

It depends on the patches. Most of them need testing. Releases (and
their candidates) already would have been tested and/or reviewed by some
people before hitting OE.

As already stated in my previous mail, I'm not against applying patches
from upstream, provided they are _required_ to make it work in some
configuration.

> What advantage do you see of having a vanilla gcc without linaro patches ?

See above.

In the (hopefully unlikely) event that a random svn version of linaro
gcc introduces a regression, say on the MIPS platform, who am I going to
report that to? Would I have to bisect all linaro patches manually?
Surely, the upstream developers wouldn't care about reports about
heavily patched gccs, and linaro developers wouldn't care about MIPS.

Regards,
Andreas