F22 System Wide Change: GCC5

[Jaroslav Reznik]

= Proposed System Wide Change: GCC5 =
https://fedoraproject.org/wiki/Changes/GCC5

Change owner(s):  Jakub Jelínek <jakub(a)redhat.com&gt;

Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.

== Detailed Description ==
GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease 
state with only regression bugfixes and documentation fixes allowed. The release 
will happen probably in the first half of April. We are working on scratch gcc 
rpms and will perform a test mass rebuild. Other distributions have performed 
test mass rebuilds already. 

== Scope ==
All packages should be rebuilt with the new gcc once it hits f22.

* Proposal owners: Build gcc in f22, rebuild packages that have direct 
dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).

* Other developers: First few days/weeks just voluntary rebuilds using the new 
system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html 
and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, 
analyze and report. 

* Release engineering: Organize a mass rebuild 
* Policies and guidelines: No policies need to be changed 

== Contingency Plan ==
If bugs are discovered, I'd appreciate help from the package owners in 
preparing self-contained testcases to speed up analysis and fixing the bugs. 
Don't have time to debug issues in 12000+ packages, especially when in many 
cases it could be caused by undefined code in the packages etc. I don't expect 
we'll have to fall back to the older gcc, we've never had to do it in the 
past, but worst case we can mass rebuild everything with older gcc again.

* Contingency mechanism: Revert to older gcc, mass rebuild everything again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No 
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Vít Ondruch]

Dne 14.1.2015 v 12:53 Jaroslav Reznik napsal(a):
>  = Proposed System Wide Change: GCC5 =
>  https://fedoraproject.org/wiki/Changes/GCC5
>
>  Change owner(s):  Jakub Jelínek <jakub(a)redhat.com&gt;
>
>  Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
>
>  == Detailed Description ==
>  GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease 
>  state with only regression bugfixes and documentation fixes allowed. The release 
>  will happen probably in the first half of April. We are working on scratch gcc 
>  rpms and will perform a test mass rebuild. Other distributions have performed 
>  test mass rebuilds already. 
>
>  == Scope ==
>  All packages should be rebuilt with the new gcc once it hits f22.
>
>  * Proposal owners: Build gcc in f22, rebuild packages that have direct 
>  dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
>
>  * Other developers: First few days/weeks just voluntary rebuilds using the new 
>  system gcc, if things fail, look at http://gcc.gnu.org/gcc-5/porting_to.html 
>  and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, 
>  analyze and report. 
Ah, few days/weeks. Now I really can't see how this will fit into schedule.


Vít


>   
>
>  * Release engineering: Organize a mass rebuild 
>  * Policies and guidelines: No policies need to be changed 
>
>  == Contingency Plan ==
>  If bugs are discovered, I'd appreciate help from the package owners in 
>  preparing self-contained testcases to speed up analysis and fixing the bugs. 
>  Don't have time to debug issues in 12000+ packages, especially when in many 
>  cases it could be caused by undefined code in the packages etc. I don't expect 
>  we'll have to fall back to the older gcc, we've never had to do it in the 
>  past, but worst case we can mass rebuild everything with older gcc again.
>
>  * Contingency mechanism: Revert to older gcc, mass rebuild everything again
>  * Contingency deadline: Before release
>  * Blocks release? Yes
>  * Blocks product? No 
>  _______________________________________________
>  devel-announce mailing list
>  devel-announce(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Dan Horák]

On Wed, 14 Jan 2015 12:53:18 +0100
Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:

>  = Proposed System Wide Change: GCC5 =
>  https://fedoraproject.org/wiki/Changes/GCC5
>  
>  Change owner(s):  Jakub Jelínek <jakub(a)redhat.com&gt;
>  
>  Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
>  
>  == Detailed Description ==
>  GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease 
>  state with only regression bugfixes and documentation fixes allowed. The release 
>  will happen probably in the first half of April. We are working on scratch gcc 
>  rpms and will perform a test mass rebuild. Other distributions have performed 
>  test mass rebuilds already.  
on what architectures and with which results? How can we help to avoid
issues with s390, ppc or aarch64 like we saw with gcc 4.9 and s390?


		Dan

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 01:34:26PM +0100, Dan Horák wrote:
>  On Wed, 14 Jan 2015 12:53:18 +0100
>  Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  
>  > = Proposed System Wide Change: GCC5 =
>  > https://fedoraproject.org/wiki/Changes/GCC5
>  > 
>  > Change owner(s):  Jakub Jelínek <jakub(a)redhat.com&gt;
>  > 
>  > Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
>  > 
>  > == Detailed Description ==
>  > GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease 
>  > state with only regression bugfixes and documentation fixes allowed. The release 
>  > will happen probably in the first half of April. We are working on scratch gcc 
>  > rpms and will perform a test mass rebuild. Other distributions have performed 
>  > test mass rebuilds already. 
>  
>  on what architectures and with which results? How can we help to avoid
>  issues with s390, ppc or aarch64 like we saw with gcc 4.9 and s390? 
Depends on what kind of issues.  If it is something detected during the mass
rebuild (ICEs, failures in package testsuite), you can gain a few days/weeks by
doing a test mass rebuild on the arches where you fear that (the plan was to do
just x86-64 test mass rebuild ourselves); the question is if there is beefy
enough hardware with spare cycles for that.
If it is something that can be detected only when running the distro, then
somebody would need to also install and try the test mass rebuilt distro, or
just let stuff be fixed after mass rebuild.  If there are GCC bugs that need
to be resolved, the better bugreports the less time we need to spend on
testcase reduction and analysis and the more we can spend on actual bug
fixing.

	Jakub

[Richard W.M. Jones]

Jakub:

I will test gcc 5 on my Rawhide aarch64 machine, if you can point me
to either a build of it or an SRPM.  So far I see no gcc 5 builds in
either Koji or the linked wiki page.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Peter Robinson]

On Fri, Jan 16, 2015 at 4:00 AM, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  Jakub:
>
>  I will test gcc 5 on my Rawhide aarch64 machine, if you can point me
>  to either a build of it or an SRPM.  So far I see no gcc 5 builds in
>  either Koji or the linked wiki page. 
aarch64 scratch build that Jakub did yesterday is here
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2847399

[Richard W.M. Jones]

On Fri, Jan 16, 2015 at 04:12:03AM +0000, Peter Robinson wrote:
>  On Fri, Jan 16, 2015 at 4:00 AM, Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>  > Jakub:
>  >
>  > I will test gcc 5 on my Rawhide aarch64 machine, if you can point me
>  > to either a build of it or an SRPM.  So far I see no gcc 5 builds in
>  > either Koji or the linked wiki page.
>  
>  aarch64 scratch build that Jakub did yesterday is here
>  http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2847399 
Thanks Peter -- will give this a spin on Monday.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Richard W.M. Jones]

On Fri, Jan 16, 2015 at 08:10:14AM +0000, Richard W.M. Jones wrote:
>  On Fri, Jan 16, 2015 at 04:12:03AM +0000, Peter Robinson wrote:
>  > On Fri, Jan 16, 2015 at 4:00 AM, Richard W.M. Jones <rjones(a)redhat.com&gt;
> wrote:
>  > > Jakub:
>  > >
>  > > I will test gcc 5 on my Rawhide aarch64 machine, if you can point me
>  > > to either a build of it or an SRPM.  So far I see no gcc 5 builds in
>  > > either Koji or the linked wiki page.
>  > 
>  > aarch64 scratch build that Jakub did yesterday is here
>  > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2847399
>  
>  Thanks Peter -- will give this a spin on Monday. 
Unfortunately it needs an updated libtool ...

Error: Package: libtool-2.4.2-31.fc22.aarch64 (@rawhide)
           Requires: gcc = 4.9.2
           Removing: gcc-4.9.2-5.fc22.aarch64 (@rawhide)
               gcc = 4.9.2-5.fc22
           Updated By: gcc-5.0.0-0.1.fc21.aarch64 (/gcc-5.0.0-0.1.fc21.aarch64)
               gcc = 5.0.0-0.1.fc21

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[Richard W.M. Jones]

On Mon, Jan 19, 2015 at 03:20:54PM +0000, Richard W.M. Jones wrote:
>  
>  On Fri, Jan 16, 2015 at 08:10:14AM +0000, Richard W.M. Jones wrote:
>  > On Fri, Jan 16, 2015 at 04:12:03AM +0000, Peter Robinson wrote:
>  > > On Fri, Jan 16, 2015 at 4:00 AM, Richard W.M. Jones <rjones(a)redhat.com&gt;
> wrote:
>  > > > Jakub:
>  > > >
>  > > > I will test gcc 5 on my Rawhide aarch64 machine, if you can point me
>  > > > to either a build of it or an SRPM.  So far I see no gcc 5 builds in
>  > > > either Koji or the linked wiki page.
>  > > 
>  > > aarch64 scratch build that Jakub did yesterday is here
>  > > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2847399
>  > 
>  > Thanks Peter -- will give this a spin on Monday.
>  
>  Unfortunately it needs an updated libtool ...
>  
>  Error: Package: libtool-2.4.2-31.fc22.aarch64 (@rawhide)
>             Requires: gcc = 4.9.2
>             Removing: gcc-4.9.2-5.fc22.aarch64 (@rawhide)
>                 gcc = 4.9.2-5.fc22
>             Updated By: gcc-5.0.0-0.1.fc21.aarch64 (/gcc-5.0.0-0.1.fc21.aarch64)
>                 gcc = 5.0.0-0.1.fc21 
For anyone else trying this, what you have to do is:

 - yum remove libtool
 - install gcc 5 from the link above
 - use 'fedpkg local' to build libtool locally from dist-git
 - yum install (locally built) libtool

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

[Jakub Jelinek]

On Mon, Jan 19, 2015 at 03:45:23PM +0000, Richard W.M. Jones wrote:
>  > Unfortunately it needs an updated libtool ... 
Sure, one needs to build libtool too.
>  > 
>  > Error: Package: libtool-2.4.2-31.fc22.aarch64 (@rawhide)
>  >            Requires: gcc = 4.9.2
>  >            Removing: gcc-4.9.2-5.fc22.aarch64 (@rawhide)
>  >                gcc = 4.9.2-5.fc22
>  >            Updated By: gcc-5.0.0-0.1.fc21.aarch64 (/gcc-5.0.0-0.1.fc21.aarch64)
>  >                gcc = 5.0.0-0.1.fc21 
Also note that there are 5.0.0-0.3.fc22 rpms right now:
    http://koji.fedoraproject.org/scratch/jakub/task_8642235/ (x86_64, i686)              
                                                        
    http://koji.fedoraproject.org/scratch/jakub/task_8652335/ (armv7hl)                   
                                                        
    http://ppc.koji.fedoraproject.org/scratch/jakub/task_2280661/ (ppc64, ppc64le)        
                                                        
    http://s390.koji.fedoraproject.org/scratch/jakub/task_1702214/ (s390)                 
                                                        
    http://arm.koji.fedoraproject.org/scratch/jakub/task_2849711/ (aarch64)
These have the libgccjit{,-devel} packaged and gcc-gdb-plugin in better
shape than initially (and some important IPA fixes).

	Jakub

[Jakub Jelinek]

Hi!

As FESCO denied mass rebuild of F22, I've adjusted
https://fedoraproject.org/wiki/Changes/GCC5
the current rpms are built with --with-default-libstdcxx-abi=c++98
thus will not have standard conforming std::string/std::list by default,
and I'd like to include gcc 5 in F22 anyway, just only what maintainers
rebuild themselves after gcc 5 is included will be rebuilt with it.

	Jakub

[Vít Ondruch]

Dne 19.1.2015 v 17:32 Jakub Jelinek napsal(a):
>  Hi!
>
>  As FESCO denied mass rebuild of F22, I've adjusted
>  https://fedoraproject.org/wiki/Changes/GCC5
>  the current rpms are built with --with-default-libstdcxx-abi=c++98
>  thus will not have standard conforming std::string/std::list by default,
>  and I'd like to include gcc 5 in F22 anyway, just only what maintainers
>  rebuild themselves after gcc 5 is included will be rebuilt with it.
>
>  	Jakub 
And what about early F23 mass rebuild? Is that feasible?


Vít

[Jakub Jelinek]

On Mon, Jan 19, 2015 at 05:52:51PM +0100, Vít Ondruch wrote:
>  Dne 19.1.2015 v 17:32 Jakub Jelinek napsal(a):
>  > As FESCO denied mass rebuild of F22, I've adjusted
>  > https://fedoraproject.org/wiki/Changes/GCC5
>  > the current rpms are built with --with-default-libstdcxx-abi=c++98
>  > thus will not have standard conforming std::string/std::list by default,
>  > and I'd like to include gcc 5 in F22 anyway, just only what maintainers
>  > rebuild themselves after gcc 5 is included will be rebuilt with it.
>  
>  And what about early F23 mass rebuild? Is that feasible? 
F23 of course would be mass rebuilt if FESCO allows that,
and gcc.spec will automatically
switch to the c++11 std::string/std::list by default:
%if 0%{fedora} >= 21 && 0%{fedora} <= 22
        --with-default-libstdcxx-abi=c++98 \
%endif

	Jakub

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 14, 2015 at 12:53:18PM +0100, Jaroslav Reznik wrote:
>  = Proposed System Wide Change: GCC5 =
>  https://fedoraproject.org/wiki/Changes/GCC5
>  
>  Change owner(s):  Jakub Jelínek <jakub(a)redhat.com&gt;
>  
>  Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
>  
>  == Detailed Description ==
>  GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease 
>  state with only regression bugfixes and documentation fixes allowed. The release 
>  will happen probably in the first half of April. We are working on scratch gcc 
>  rpms and will perform a test mass rebuild. Other distributions have performed 
>  test mass rebuilds already. 
>  
>  == Scope ==
>  All packages should be rebuilt with the new gcc once it hits f22.
>  
>  * Proposal owners: Build gcc in f22, rebuild packages that have direct 
>  dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
>  
>  * Other developers: First few days/weeks just voluntary rebuilds using the new 
>  system gcc, if things fail, look at 
http://gcc.gnu.org/gcc-5/porting_to.html → 404

(also on the wiki)

Zbyszek

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
>  On Wed, Jan 14, 2015 at 12:53:18PM +0100, Jaroslav Reznik wrote:
>  > = Proposed System Wide Change: GCC5 =
>  > https://fedoraproject.org/wiki/Changes/GCC5
>  > 
>  > Change owner(s):  Jakub Jelínek <jakub(a)redhat.com&gt;
>  > 
>  > Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
>  > 
>  > == Detailed Description ==
>  > GCC 5 is currently in stage3, but in 3 days will move to stage4, in prerelease 
>  > state with only regression bugfixes and documentation fixes allowed. The release 
>  > will happen probably in the first half of April. We are working on scratch gcc 
>  > rpms and will perform a test mass rebuild. Other distributions have performed 
>  > test mass rebuilds already. 
>  > 
>  > == Scope ==
>  > All packages should be rebuilt with the new gcc once it hits f22.
>  > 
>  > * Proposal owners: Build gcc in f22, rebuild packages that have direct 
>  > dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).
>  > 
>  > * Other developers: First few days/weeks just voluntary rebuilds using the new 
>  > system gcc, if things fail, look at
>  
>  http://gcc.gnu.org/gcc-5/porting_to.html → 404
>  
>  (also on the wiki) 
BTW: is there a copr or another place to get gcc5 without
compiling from source?

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
>  http://gcc.gnu.org/gcc-5/porting_to.html → 404 
That will be added likely after the test mass rebuild with what we find
during that.

	Jakub

[Jaroslav Reznik]

----- Original Message -----
>  On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek
> wrote:
>  > http://gcc.gnu.org/gcc-5/porting_to.html → 404
>  
>  That will be added likely after the test mass rebuild with what we find
>  during that. 
Do you have any estimate when it will be done? F22 schedule is/will be pretty
tight. We already have problem scheduling mass rebuild and I expect GCC 5
would require as long as possible period to fix issues/build problems. This
time, schedule is more strict time based - what would it mean for you if
GCC 5 will miss F22? I'm not saying it's going to happen but it could be
option.

Jaroslav

>  	Jakub
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Peter Robinson]

On Wed, Jan 14, 2015 at 2:12 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  ----- Original Message -----
> > On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > http://gcc.gnu.org/gcc-5/porting_to.html → 404
> >
> > That will be added likely after the test mass rebuild with what we find
> > during that.
>
>  Do you have any estimate when it will be done? F22 schedule is/will be pretty
>  tight. We already have problem scheduling mass rebuild and I expect GCC 5
>  would require as long as possible period to fix issues/build problems. This
>  time, schedule is more strict time based - what would it mean for you if
>  GCC 5 will miss F22? I'm not saying it's going to happen but it could be
>  option. 
I was thinking exactly that, mass rebuild is scheduled for Jan 30th
according to the schedule [1] with branching 10 days or so later. That
is only two weeks away. With statements like "The release will happen
probably in the first half of April" when we're already suppose to be
be in freeze from end of March I think this would be better landing in
F-23 right after we branch F-22 off on Feb 10th. Ultimately the above
gives us no room to move and a roll back is another mass rebuild which
will only cause more delay!

Peter

[1] https://fedoraproject.org/wiki/Releases/22/Schedule

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 02:24:29PM +0000, Peter Robinson wrote:
>  On Wed, Jan 14, 2015 at 2:12 PM, Jaroslav Reznik
> <jreznik(a)redhat.com&gt; wrote:
>  > ----- Original Message -----
>  >> On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
>  >> > http://gcc.gnu.org/gcc-5/porting_to.html → 404
>  >>
>  >> That will be added likely after the test mass rebuild with what we find
>  >> during that.
>  >
>  > Do you have any estimate when it will be done? F22 schedule is/will be pretty
>  > tight. We already have problem scheduling mass rebuild and I expect GCC 5
>  > would require as long as possible period to fix issues/build problems. This
>  > time, schedule is more strict time based - what would it mean for you if
>  > GCC 5 will miss F22? I'm not saying it's going to happen but it could be
>  > option.
>  
>  I was thinking exactly that, mass rebuild is scheduled for Jan 30th
>  according to the schedule [1] with branching 10 days or so later. That
>  is only two weeks away. With statements like "The release will happen
>  probably in the first half of April" when we're already suppose to be
>  be in freeze from end of March I think this would be better landing in
>  F-23 right after we branch F-22 off on Feb 10th. Ultimately the above
>  gives us no room to move and a roll back is another mass rebuild which
>  will only cause more delay! 
Again, how is that different from F9, F11, F13, F15, F17, F19?

	Jakub

[Jonathan Underwood]

On 14 January 2015 at 14:31, Jakub Jelinek <jakub(a)redhat.com&gt; wrote:
>  Again, how is that different from F9, F11, F13, F15, F17, F19?
Only a partial answer to your question, but one fairly significant
change (as you know) compared to the GCC upgrades for those releases
is moving from C89 to C11 as the default C standard for the compiler,
which could have quite some consequences. Or do you plan to have
-std=gnu89 added to the default compiler flags?

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 02:37:02PM +0000, Jonathan Underwood wrote:
>  On 14 January 2015 at 14:31, Jakub Jelinek <jakub(a)redhat.com&gt;
> wrote:
>  > Again, how is that different from F9, F11, F13, F15, F17, F19?
>  
>  Only a partial answer to your question, but one fairly significant
>  change (as you know) compared to the GCC upgrades for those releases
>  is moving from C89 to C11 as the default C standard for the compiler,
>  which could have quite some consequences. Or do you plan to have
>  -std=gnu89 added to the default compiler flags? 
That is to be decided based on Mass rebuild results.
I think in many packages it means no changes needed at all, in others
only very small changes, then of course there could be packages with helplessly
obsolete codebases where -std=gnu89 will be probably the only possibility,
at least short term.
The C99->C11 step is a fairly minor, C89->C99 is bigger, but mainly for
old packages that haven't ever seen -Wmissing-prototypes or similar options.

	Jakub

[Richard Hughes]

On 14 January 2015 at 14:37, Jonathan Underwood
<jonathan.underwood(a)gmail.com&gt; wrote:
>  Only a partial answer to your question, but one fairly significant
>  change (as you know) compared to the GCC upgrades for those releases
>  is moving from C89 to C11 as the default C standard for the compiler 
Is there any easy way for humble little upstream maintainers to test
their code with the new compiler?

Richard

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 02:44:03PM +0000, Richard Hughes wrote:
>  On 14 January 2015 at 14:37, Jonathan Underwood
>  <jonathan.underwood(a)gmail.com&gt; wrote:
>  > Only a partial answer to your question, but one fairly significant
>  > change (as you know) compared to the GCC upgrades for those releases
>  > is moving from C89 to C11 as the default C standard for the compiler
>  
>  Is there any easy way for humble little upstream maintainers to test
>  their code with the new compiler? 
You mean for the C89 -> C11 default change, or for other changes in GCC 5?
For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8).
The latter is mainly C++ or new features, so something you don't hit on
average C code.

	Jakub

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 14, 2015 at 03:47:18PM +0100, Jakub Jelinek wrote:
>  On Wed, Jan 14, 2015 at 02:44:03PM +0000, Richard Hughes wrote:
>  > On 14 January 2015 at 14:37, Jonathan Underwood
>  > <jonathan.underwood(a)gmail.com&gt; wrote:
>  > > Only a partial answer to your question, but one fairly significant
>  > > change (as you know) compared to the GCC upgrades for those releases
>  > > is moving from C89 to C11 as the default C standard for the compiler
>  > 
>  > Is there any easy way for humble little upstream maintainers to test
>  > their code with the new compiler?
>  
>  You mean for the C89 -> C11 default change, or for other changes in GCC 5?
>  For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8).
>  The latter is mainly C++ or new features, so something you don't hit on
>  average C code. 
I think it's a valid request. Of course packagers can
approximate, but
to test for issues it would be best to have a simple way to build with gcc5
from the latest snapshot. How do you expect people to make an informed
decision otherwise?

Zbyszek

[Jonathan Underwood]

On 14 January 2015 at 14:47, Jakub Jelinek <jakub(a)redhat.com&gt; wrote:
>  On Wed, Jan 14, 2015 at 02:44:03PM +0000, Richard Hughes wrote:
> > On 14 January 2015 at 14:37, Jonathan Underwood
> > <jonathan.underwood(a)gmail.com&gt; wrote:
> > > Only a partial answer to your question, but one fairly significant
> > > change (as you know) compared to the GCC upgrades for those releases
> > > is moving from C89 to C11 as the default C standard for the compiler
> >
> > Is there any easy way for humble little upstream maintainers to test
> > their code with the new compiler?
>
>  You mean for the C89 -> C11 default change, or for other changes in GCC 5?
>  For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8). 
Perhaps it would be worth adding -std=gnu11 to the F22 default flags
now and having a rebuild, before gcc5 lands, to start shaking out
problems now?

[Helio Chissini de Castro]

On Wed, Jan 14, 2015 at 1:46 PM, Jonathan Underwood <
jonathan.underwood(a)gmail.com&gt; wrote:

>  On 14 January 2015 at 14:47, Jakub Jelinek <jakub(a)redhat.com&gt;
> wrote:
>  > On Wed, Jan 14, 2015 at 02:44:03PM +0000, Richard Hughes wrote:
>  >> On 14 January 2015 at 14:37, Jonathan Underwood
>  >> <jonathan.underwood(a)gmail.com&gt; wrote:
>  >> > Only a partial answer to your question, but one fairly significant
>  >> > change (as you know) compared to the GCC upgrades for those releases
>  >> > is moving from C89 to C11 as the default C standard for the compiler
>  >>
>  >> Is there any easy way for humble little upstream maintainers to test
>  >> their code with the new compiler?
>  >
>  > You mean for the C89 -> C11 default change, or for other changes in GCC
>  5?
>  > For the former, just build with -std=gnu11 with GCC 4.9 (or 4.8).
>
>  Perhaps it would be worth adding -std=gnu11 to the F22 default flags
>  now and having a rebuild, before gcc5 lands, to start shaking out
>  problems now?
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>  
+1 for this.

Will help a lot to see how all the code base is behaving well on new
standards

[Richard Hughes]

On 14 January 2015 at 15:46, Jonathan Underwood <jonathan.underwood(a)gmail.com&gt;
>  Perhaps it would be worth adding -std=gnu11 to the F22 default flags
>  now and having a rebuild, before gcc5 lands, to start shaking out
>  problems now? 
I think this is a really good idea.

Richard.

[Miloslav Trmač]

>  On Wed, Jan 14, 2015 at 02:24:29PM +0000, Peter Robinson wrote:
>  > I was thinking exactly that, mass rebuild is scheduled for Jan 30th
>  > according to the schedule [1] with branching 10 days or so later. That
>  > is only two weeks away. With statements like "The release will happen
>  > probably in the first half of April" when we're already suppose to be
>  > be in freeze from end of March I think this would be better landing in
>  > F-23 right after we branch F-22 off on Feb 10th. Ultimately the above
>  > gives us no room to move and a roll back is another mass rebuild which
>  > will only cause more delay!
>  
>  Again, how is that different from F9, F11, F13, F15, F17, F19? 
We are learning not to do the same mistakes all over again ☺

Now it could, I guess, be argued, that gcc has a long history of not having egregious
failure modes we are learning from, and should be allowed to land later.  OTOH there is
also, IIRC, a history of having to do a second (full or partial) or even a third rebuild
due to necessary gcc bug fixes, and landing the .0 version at the time we ship Beta is
basically an explicit bet that there will be no such bug in .0, or we are slipping.
    Mirek

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 09:12:42AM -0500, Jaroslav Reznik wrote:
>  ----- Original Message -----
>  > On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
>  > > http://gcc.gnu.org/gcc-5/porting_to.html → 404
>  > 
>  > That will be added likely after the test mass rebuild with what we find
>  > during that.
>  
>  Do you have any estimate when it will be done? F22 schedule is/will be pretty
>  tight. We already have problem scheduling mass rebuild and I expect GCC 5
>  would require as long as possible period to fix issues/build problems. This 
How is that different from any other past Fedora releases (with the
exception of F21)?  If I remember well, at least starting with GCC 4.3 (March 2008)
new GCC was deployed always in the spring release of Fedora, we've skipped
4.2 before that and as there was no spring release last year, GCC 4.9 was
kind of an exception too.

>  time, schedule is more strict time based - what would it mean for you
> if
>  GCC 5 will miss F22? I'm not saying it's going to happen but it could be
>  option. 
Well, if we want to turn Fedora into a collection of obsolete software
rather than trying to lead progress, we don't have to update anything.
In the past, from my experience with both GCC distro maintainer and upstream
maintainer hats, shipping GCC early in Fedora helped both projects,
the early deployment in Fedora helped Fedora developers to use latest
langauge features (e.g. GCC 5 will finally have C++11 compliant std::string
or std::list, and feature completeness on the C++14 language side, see
changes.html for other stuff), help upstreams make the packages more
portable and enjoy better generated code (e.g. if you really want to make
PIE the default on x86_64, doing it with 4.9 is just a terribly bad idea
because only in 5 you can actually rely on PIE copy relocs and not get hit
as much by the PIE penalty as before), and for the GCC project lead to
wider testing and more bugfixes.

	Jakub

[Josh Boyer]

On Wed, Jan 14, 2015 at 9:28 AM, Jakub Jelinek <jakub(a)redhat.com&gt; wrote:
>  On Wed, Jan 14, 2015 at 09:12:42AM -0500, Jaroslav Reznik wrote:
> > ----- Original Message -----
> > > On Wed, Jan 14, 2015 at 02:55:15PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > > http://gcc.gnu.org/gcc-5/porting_to.html → 404
> > >
> > > That will be added likely after the test mass rebuild with what we find
> > > during that.
> >
> > Do you have any estimate when it will be done? F22 schedule is/will be pretty
> > tight. We already have problem scheduling mass rebuild and I expect GCC 5
> > would require as long as possible period to fix issues/build problems. This
>
>  How is that different from any other past Fedora releases (with the
>  exception of F21)?  If I remember well, at least starting with GCC 4.3 (March 2008)
>  new GCC was deployed always in the spring release of Fedora, we've skipped
>  4.2 before that and as there was no spring release last year, GCC 4.9 was
>  kind of an exception too. 
The difference this time is that FESCo decided to set a time-based
schedule and adhere to it.  The past two releases were set based on
submitted Changes (with F21 being weird all around).  Before that, the
schedule was time-based but not strictly stuck to which led to lots of
slips.  Essentially, this is an attempt to _actually_ do a time-based
schedule.

That being said, FESCo is discussing the schedule again today because
there's no room for a mass rebuild at all.  It will be interesting to
see if they actually stick to the plan and defer any Change that
requires a mass rebuild.

josh

[Peter Robinson]

> > > > http://gcc.gnu.org/gcc-5/porting_to.html → 404
> > >
> > > That will be added likely after the test mass rebuild with what we find
> > > during that.
> >
> > Do you have any estimate when it will be done? F22 schedule is/will be pretty
> > tight. We already have problem scheduling mass rebuild and I expect GCC 5
> > would require as long as possible period to fix issues/build problems. This
>
>  How is that different from any other past Fedora releases (with the
>  exception of F21)?  If I remember well, at least starting with GCC 4.3 (March 2008)
>  new GCC was deployed always in the spring release of Fedora, we've skipped
>  4.2 before that and as there was no spring release last year, GCC 4.9 was
>  kind of an exception too.
>
> > time, schedule is more strict time based - what would it mean for you if
> > GCC 5 will miss F22? I'm not saying it's going to happen but it could be
> > option.
>
>  Well, if we want to turn Fedora into a collection of obsolete software
>  rather than trying to lead progress, we don't have to update anything. 
I think that's a bit of an over reaction, ultimately F-22 is due to
branch on February 10th which is less than a month from now, the
moment it branches gcc5 could land and people are then free to rebuild
anything they like and gcc5 will be in the October release which is in
all likely hood earlier than most other distros would adopt it anyway.

>  In the past, from my experience with both GCC distro maintainer and
> upstream
>  maintainer hats, shipping GCC early in Fedora helped both projects,
>  the early deployment in Fedora helped Fedora developers to use latest
>  langauge features (e.g. GCC 5 will finally have C++11 compliant std::string 
And how is that any different if it lands in f-23/rawhide in mid Feb?

>  or std::list, and feature completeness on the C++14 language side,
> see
>  changes.html for other stuff), help upstreams make the packages more
>  portable and enjoy better generated code (e.g. if you really want to make
>  PIE the default on x86_64, doing it with 4.9 is just a terribly bad idea
>  because only in 5 you can actually rely on PIE copy relocs and not get hit
>  as much by the PIE penalty as before), and for the GCC project lead to
>  wider testing and more bugfixes. 
So the feature gets delayed by a release and it gets enabled in F-23

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 03:05:09PM +0000, Peter Robinson wrote:
>  > Well, if we want to turn Fedora into a collection of obsolete
> software
>  > rather than trying to lead progress, we don't have to update anything.
>  
>  I think that's a bit of an over reaction, ultimately F-22 is due to
>  branch on February 10th which is less than a month from now, the
>  moment it branches gcc5 could land and people are then free to rebuild
>  anything they like and gcc5 will be in the October release which is in
>  all likely hood earlier than most other distros would adopt it anyway. 
For a product with a rough schedule every 6 month and another quite time
based every 12 months that is significant.  It turns Fedora from being one
of the first distros to ship the new compilers to one of the last if not the
last one.

	Jakub

[David Howells]

Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:

>  Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
Does cross-gcc need to switch simultaneously?  Some packages are built with
that, I believe.

David

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 05:05:50PM +0000, David Howells wrote:
>  Jaroslav Reznik <jreznik(a)redhat.com&gt; wrote:
>  
>  > Switch GCC in Fedora 22 to 5.x.y, rebuild all packages with it.
>  
>  Does cross-gcc need to switch simultaneously?  Some packages are built with
>  that, I believe. 
It is a different package, so it can switch independently.

	Jakub

[Miloslav Trmač]

>  * Contingency mechanism: Revert to older gcc, mass rebuild everything
> again
>  * Contingency deadline: Before release 
This is an invasive contingency mechanism, requiring retesting a lot of functionality; the
contingency deadline for this (i.e. when we need to be comfortable that the revert will
not be needed, should certainly be at the usual beta freeze at the latest, if not earlier.
 Invoking this contingency mechanism “before release”, say during the GA RC phase, would
really not be feasible without a massive slip.
    Mirek

[Jakub Jelinek]

On Wed, Jan 14, 2015 at 12:51:24PM -0500, Miloslav Trmač wrote:
>  > * Contingency mechanism: Revert to older gcc, mass rebuild
> everything again
>  > * Contingency deadline: Before release
>  
>  This is an invasive contingency mechanism, requiring retesting a lot of
>      functionality; the contingency deadline for this (i.e.  when we need 
It is a contingency mechanism which we never invoked in the past.

If there are bugs on the GCC side, they are just fixed.

And the GCC GA release time isn't that much special time, it is time when
the compiler is declared officially GA, but bugs are fixed before and after
that time under completely the same policy, only regression bugfixes and
documentation bugfixes are allowed starting with this Saturday onwards
(last two months allowed general bugfixes too, so not only for things that
regressed from earlier GCC releases).  So from the Fedora POV, starting this
Saturday only regression bugfixes will be allowed from now on until all
Fedoras that will ship GCC 5 go EOL.

	Jakub

[Peter Robinson]

On Wed, Jan 14, 2015 at 5:51 PM, Miloslav Trmač <mitr(a)redhat.com&gt; wrote:
> > * Contingency mechanism: Revert to older gcc, mass rebuild
> everything again
> > * Contingency deadline: Before release
>
>  This is an invasive contingency mechanism, requiring retesting a lot of functionality;
> the contingency deadline for this (i.e. when we need to be comfortable that the revert
> will not be needed, should certainly be at the usual beta freeze at the latest, if not
> earlier.  Invoking this contingency mechanism “before release”, say during the GA RC
> phase, would really not be feasible without a massive slip. 
Any revert of this would mean another mass rebuild similar to what was
needed in F-21 which will guarantee a slip of probably two weeks, late
in the beta phase this becomes more of an issue. 18K packages do take
some time to rebuild, tag etc.

Peter