Release Engineering Meeting Recap from Monday 16-APR-07

Jakub Jelinek jakub at redhat.com
Tue Apr 17 12:34:21 UTC 2007


On Tue, Apr 17, 2007 at 01:56:51PM +0200, Axel Thimm wrote:
> > Even the glibc changes in F7 are mostly glibc internal changes, bugfixes
> > and addition of a few new symbols (epoll_wait, sync_file_range,
> > strerror_l, __sched_cpucount) and only on PPC a new version for existing
> > symbols (pthread_attr_setstack{,size}).  So neither gcc nor glibc
> > changes necessitate a mass rebuild (and I'm not aware of any huge changes
> > in redhat-rpm-config either) at this time and that's why F7 rebuild status
> > is so low.  GCC 4.2 has been stagnating for 6 months now and we have
> > several important things backported anyway in GCC 4.1.x-RH (OpenMP,
> > visibility stuff, Java stack, numerous Fortran improvements, many bugfixes,
> > ...).
> 
> When did these backports happen between 4.1.1-30 and 4.1.2-8 or earlier?

Java stack rebase is in F7+ only, OpenMP/visibility stuff/most of Fortran
improvements were already in FC6.  Bug fixes are obviously continuously
coming, be it from upstream gcc-4_1-branch or backports of fixes from GCC
trunk or gcc-4_2-branch.

> > If gcc, binutils or glibc changes substantially in say F8, we'll
> > of course need to do a mass rebuild.
> 
> gcc should finally have made it to 4.2 by then.

Except it is unclear whether 4.2 is a win, while it has some advantages,
it has also pretty significant drop in performance of compiled code (due to
quick aliasing fixes), which is really fixed without performance degradation
only in 4.3+.  While this is not so severe for upstream 4.2 which compares
to vanilla 4.1, as redhat/gcc-4_1-branch contains e.g. the i?86/x86_64 CPU
tuning improvements (-mtune=generic, -m{arch,tune}={core2,amdfam10,geode}),
when comparing redhat/gcc-4_1-branch to gcc-4_2-branch this is more visible.
4.3 has a lot of other goodies we are looking for, but we can't predict ATM
how long will it take till 4.3 release, if it will stagnate the same way as
4.2 is or not.  4.2 actual development stages weren't terribly long, but
after branching it has been 6 months with little activity, bugfixing where
significant portion of the bugfixes went also to gcc-4_1-branch.

	Jakub




More information about the fedora-devel-list mailing list