4:19 a.m.
Is there expected to be a mass rebuild for F13 - for example, to include
GCC 4.5 (which will probably be released the first half of 2010, judging
by past release dates)?
4:50 a.m.
On Mon, Dec 21, 2009 at 05:19:20AM -0500, Andre Robatino wrote:
Is there expected to be a mass rebuild for F13 - for example, to
include
GCC 4.5 (which will probably be released the first half of 2010, judging
by past release dates)?
I do not intend to jump to GCC 4.5 for F13, that would mean I and others
would have to spend almost all our time on that already by now, while there
is still a lot of work on GCC 4.4 bugfixing.
GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we
can leave GCC 4.5 as a new feature to F14.
Jakub
5:17 a.m.
Jakub Jelinek wrote:
On Mon, Dec 21, 2009 at 05:19:20AM -0500, Andre Robatino wrote:
> Is there expected to be a mass rebuild for F13 - for example, to include
> GCC 4.5 (which will probably be released the first half of 2010, judging
> by past release dates)?
I do not intend to jump to GCC 4.5 for F13, that would mean I and others
would have to spend almost all our time on that already by now, while
there is still a lot of work on GCC 4.4 bugfixing.
GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we
can leave GCC 4.5 as a new feature to F14.
Jakub
How could I learn what 4.5 features are backported?
5:37 a.m.
On Mon, Dec 21, 2009 at 06:17:26AM -0500, Neal Becker wrote:
> On Mon, Dec 21, 2009 at 05:19:20AM -0500, Andre Robatino wrote:
>> Is there expected to be a mass rebuild for F13 - for example, to include
>> GCC 4.5 (which will probably be released the first half of 2010, judging
>> by past release dates)?
>
> I do not intend to jump to GCC 4.5 for F13, that would mean I and others
> would have to spend almost all our time on that already by now, while
> there is still a lot of work on GCC 4.4 bugfixing.
> GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we
> can leave GCC 4.5 as a new feature to F14.
How could I learn what 4.5 features are backported?
From gcc %changelog?
To list some of them:
- VTA
- -gdwarf-3, -gstrict-dwarf support, defaults to -gdwarf-3
- various other debuginfo related backports
- epilogue unwinding support
- __builtin_unreachable () support
- asm goto support
- power7 support
- SSE5 support removal, AMD Orochi support added (-mfma4, -mxop, -mlwp)
- -freorder-blocks-and-partitions unwind fixes
- STB_GNU_UNIQUE support
- C++ typeinfo comparison changes
- C++ constructor and destructor code size optimizations (aliasing
identical base/complete cdtors together when no virtual bases,
wrapper version of deleting dtor)
- -D_FORTIFY_SOURCE={1,2} changes
- some small Fortran speed optimization backports
- -mcrc32 support on ix86/x86_64
- more accurate ix86/x86_64 insn length info, ix86/x86_64 machine reorg improvements
- -march=atom/-mtune=atom support
- -masm=intel mode fixes
- raw string support, u/U/u8 string literal support
- assorted bugfixes
Jakub
6:03 a.m.
On Mon, Dec 21, 2009 at 6:37 AM, Jakub Jelinek wrote:
On Mon, Dec 21, 2009 at 06:17:26AM -0500, Neal Becker wrote:
> How could I learn what 4.5 features are backported?
>From gcc %changelog?
To list some of them:
- VTA
- -gdwarf-3, -gstrict-dwarf support, defaults to -gdwarf-3
- various other debuginfo related backports
- epilogue unwinding support
- __builtin_unreachable () support
- asm goto support
- power7 support
- SSE5 support removal, AMD Orochi support added (-mfma4, -mxop, -mlwp)
- -freorder-blocks-and-partitions unwind fixes
- STB_GNU_UNIQUE support
- C++ typeinfo comparison changes
- C++ constructor and destructor code size optimizations (aliasing
identical base/complete cdtors together when no virtual bases,
wrapper version of deleting dtor)
- -D_FORTIFY_SOURCE={1,2} changes
- some small Fortran speed optimization backports
- -mcrc32 support on ix86/x86_64
- more accurate ix86/x86_64 insn length info, ix86/x86_64 machine reorg improvements
- -march=atom/-mtune=atom support
- -masm=intel mode fixes
- raw string support, u/U/u8 string literal support
- assorted bugfixes
It would be nice if you folks add these little explanations as
comments next to the patches of the gcc SPEC file. (this is also a
packaging requirement [1]).
Orcan
[1]
http://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_hav...
6:21 a.m.
On Mon, Dec 21, 2009 at 07:03:13AM -0500, Orcan Ogetbil wrote:
It would be nice if you folks add these little explanations as
comments next to the patches of the gcc SPEC file. (this is also a
packaging requirement [1]).
1) gcc-4.4-RH has its own svn branch in upstream repository, so the
src.rpm contains only very few patches, most of the changes are
simply committed to the svn branch. svn commit logs contain
all relevant info.
2) the patches (~ 20) that are left have comments in their bodies,
rather than in the spec file, which is much more maintainable.
Jakub
6:38 a.m.
On Mon, Dec 21, 2009 at 7:21 AM, Jakub Jelinek wrote:
On Mon, Dec 21, 2009 at 07:03:13AM -0500, Orcan Ogetbil wrote:
> It would be nice if you folks add these little explanations as
> comments next to the patches of the gcc SPEC file. (this is also a
> packaging requirement [1]).
1) gcc-4.4-RH has its own svn branch in upstream repository, so the
src.rpm contains only very few patches, most of the changes are
simply committed to the svn branch. svn commit logs contain
all relevant info.
2) the patches (~ 20) that are left have comments in their bodies,
rather than in the spec file, which is much more maintainable.
Yeah, those comments in the patches are quite informative, like "libtool
sucks".
Seriously, this "comment about the patch in the specfile" is a
packaging requirement, not a personal request.
Orcan
7:57 a.m.
On Mon, 2009-12-21 at 07:38 -0500, Orcan Ogetbil wrote:
On Mon, Dec 21, 2009 at 7:21 AM, Jakub Jelinek wrote:
> On Mon, Dec 21, 2009 at 07:03:13AM -0500, Orcan Ogetbil wrote:
>> It would be nice if you folks add these little explanations as
>> comments next to the patches of the gcc SPEC file. (this is also a
>> packaging requirement [1]).
>
> 1) gcc-4.4-RH has its own svn branch in upstream repository, so the
> src.rpm contains only very few patches, most of the changes are
> simply committed to the svn branch. svn commit logs contain
> all relevant info.
> 2) the patches (~ 20) that are left have comments in their bodies,
> rather than in the spec file, which is much more maintainable.
>
Yeah, those comments in the patches are quite informative, like "libtool
sucks".
Seriously, this "comment about the patch in the specfile" is a
packaging requirement, not a personal request.
Keeping comments in patches is perfectly fine; if the packaging
guidelines don't reflect that, they ought to be clarified.
9:52 a.m.
On Dec 21, 2009, at 4:38, Orcan Ogetbil <oget.fedora(a)gmail.com> wrote:
On Mon, Dec 21, 2009 at 7:21 AM, Jakub Jelinek wrote:
> On Mon, Dec 21, 2009 at 07:03:13AM -0500, Orcan Ogetbil wrote:
>> It would be nice if you folks add these little explanations as
>> comments next to the patches of the gcc SPEC file. (this is also a
>> packaging requirement [1]).
>
> 1) gcc-4.4-RH has its own svn branch in upstream repository, so the
> src.rpm contains only very few patches, most of the changes are
> simply committed to the svn branch. svn commit logs contain
> all relevant info.
> 2) the patches (~ 20) that are left have comments in their bodies,
> rather than in the spec file, which is much more maintainable.
>
Yeah, those comments in the patches are quite informative, like
"libtool sucks".
Seriously, this "comment about the patch in the specfile" is a
packaging requirement, not a personal request.
With git style patches (and others) where there is lots of context and
info in the patch file itself, duplicating it into the spec file is
rather pointless. Let's have some thinking about the guidelines
instead of blind following. The guideline is there so that we don't
just have raw diffs without any context.
--
Jes
10:58 a.m.
Jesse Keating <jkeating(a)j2solutions.net> writes:
On Dec 21, 2009, at 4:38, Orcan Ogetbil <oget.fedora(a)gmail.com>
wrote:
> Seriously, this "comment about the patch in the specfile" is a
> packaging requirement, not a personal request.
With git style patches (and others) where there is lots of context
and
info in the patch file itself, duplicating it into the spec file is
rather pointless. Let's have some thinking about the guidelines
instead of blind following. The guideline is there so that we don't
just have raw diffs without any context.
Yeah, I much prefer to put comments in the patch file too. For one
thing, they're much more likely to get updated when the patch changes
that way. The packaging guideline seems to be written with one-liner
comments in mind, but my comments often run to more than that.
regards, tom lane
1:41 p.m.
On Mon, Dec 21, 2009 at 10:52 AM, Jesse Keating wrote:
On Dec 21, 2009, at 4:38, Orcan Ogetbil wrote:
>
> Yeah, those comments in the patches are quite informative, like "libtool
> sucks".
>
> Seriously, this "comment about the patch in the specfile" is a
> packaging requirement, not a personal request.
>
>
With git style patches (and others) where there is lots of context and info
in the patch file itself, duplicating it into the spec file is rather
pointless. Let's have some thinking about the guidelines instead of blind
following. The guideline is there so that we don't just have raw diffs
without any context.
Then I would say, let's have a look at the comments of gcc's patches
before blindly believing in that they all have explanatory comments in
them. Many don't. Some do, but those comments are sometimes 2 word
comments such as the one given above.
I fail to see the consistency here.
Orcan
1:59 p.m.
On Mon, 2009-12-21 at 14:41 -0500, Orcan Ogetbil wrote:
On Mon, Dec 21, 2009 at 10:52 AM, Jesse Keating wrote:
> On Dec 21, 2009, at 4:38, Orcan Ogetbil wrote:
>>
>> Yeah, those comments in the patches are quite informative, like "libtool
>> sucks".
>>
>> Seriously, this "comment about the patch in the specfile" is a
>> packaging requirement, not a personal request.
>>
>>
>
> With git style patches (and others) where there is lots of context and info
> in the patch file itself, duplicating it into the spec file is rather
> pointless. Let's have some thinking about the guidelines instead of blind
> following. The guideline is there so that we don't just have raw diffs
> without any context.
>
Then I would say, let's have a look at the comments of gcc's patches
before blindly believing in that they all have explanatory comments in
them. Many don't. Some do, but those comments are sometimes 2 word
comments such as the one given above.
I fail to see the consistency here.
Orcan
Whether they do or don't have the comments wasn't what I was replying
to. Whether the comments could exist in the patch files or whether they
are required to be in the .spec file is the issue I was addressing.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
9:21 a.m.
On Mon, Dec 21, 2009 at 5:50 AM, Jakub Jelinek <jakub(a)redhat.com> wrote:
I do not intend to jump to GCC 4.5 for F13, that would mean I and
others
would have to spend almost all our time on that already by now, while there
is still a lot of work on GCC 4.4 bugfixing.
GCC 4.4-RH contains several GCC 4.5 new features backported, so I think we
can leave GCC 4.5 as a new feature to F14.
Has any thought been given to the changes needed to make use of LTO when the
switch to 4.5 is eventually made?
5278
days inactive
5278
days old
13 comments
10 participants
participants (10)
-
Andre Robatino -
Gregory Maxwell -
Jakub Jelinek -
Jesse Keating -
Jesse Keating -
Kevin Kofler -
Matthias Clasen -
Neal Becker -
Orcan Ogetbil -
Tom Lane