On 3/15/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> I support the final-release-then-close approach. But can we get a
> volunteer to convert that branch to GPLv3... ?
How complicated is the task?
On Sat, Mar 15, 2008 at 1:31 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> "Gabriel Dos Reis" <[EMAIL PROTECTED]> writes:
>
> > On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> >> On Mon, 3 Mar 2008, Gabriel Dos Reis wrote:
> >> > Do we still want to keep this b
On Sat, Mar 15, 2008 at 5:09 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
>
> On Fri, 14 Mar 2008, Joe Buck wrote:
>
> > On Fri, Mar 14, 2008 at 05:58:12PM -0500, Gabriel Dos Reis wrote:
> > > On Sat, Mar 8, 2008 at 7:36 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> > > > On Mon, 3 Mar 2008,
On Sat, 15 Mar 2008, Richard Guenther wrote:
> I think we agreed to _not_ move the 4.1 branch to GPLv3. So, if
fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
--
Joseph S. Myers
[EMAIL PROTECTED]
> I think we agreed to _not_ move the 4.1 branch to GPLv3.
FWIW that was my understanding as well.
> So, if the FSF says we may not release as GPLv2 then we should not do
> a 4.1.3 release. The branch is simply open as 4.1 is widely adopted
> and distributors ship from the top of the branch and
> fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
By accident I presume?
--
Eric Botcazou
On Sat, Mar 15, 2008 at 1:12 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> > fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago.
>
> By accident I presume?
If there is too much confusion about this (unset) policy to keep 4.1 GPLv2
I propose to close the branch and branch a gcc-4_1-
> If there is too much confusion about this (unset) policy to keep 4.1 GPLv2
> I propose to close the branch and branch a gcc-4_1-gplv2-branch off the
> top.
My vague recollection from the last GCC summit is that there was no plan to
move the 4.1 branch to GPLv3 and that everyone was OK with this
This is an attempt to provide (pass) statistics collection. The
goal is to provide infrastructure to handle the current (pass specific)
statistics dumping that is done per function and per pass along the
regular tree/rtl dumps as well as to allow CU wide "fancy" analysis.
The most important aspe
From: "Richard Guenther" <[EMAIL PROTECTED]>
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
I strongly object to moving the 4.1 brach to GPLv3.
Richard.
Because... ?
--
Kaveh R. Ghazi
Kaveh Ghazi wrote:
From: "Richard Guenther" <[EMAIL PROTECTED]>
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
I strongly object to moving the 4.1 brach to GPLv3.
Richard.
Because... ?
--
Kaveh R. Ghazi
I thought every
Hi,
> This is an attempt to provide (pass) statistics collection. The
> goal is to provide infrastructure to handle the current (pass specific)
> statistics dumping that is done per function and per pass along the
> regular tree/rtl dumps as well as to allow CU wide "fancy" analysis.
>
> The mos
* Daniel Berlin:
> They could have made massive strides since then (this was a little
> over a year ago), but I wouldn't trust anything with that large of a
> scaling issue to have solved it in such a short time.
They still compute revision numbers on the fly in many commands, which
means that th
On Sun, 16 Mar 2008, Zdenek Dvorak wrote:
> Hi,
>
> > This is an attempt to provide (pass) statistics collection. The
> > goal is to provide infrastructure to handle the current (pass specific)
> > statistics dumping that is done per function and per pass along the
> > regular tree/rtl dumps as
[EMAIL PROTECTED] wrote:
> Yup. We can slot in a gcc git mirror beside the half-dozen others we
> already have. (Angela: the payload data is under the new
> /sourceware/projects/FOO-home/gitfiles directory; symlinks from /git.)
All of /sourceware/projects is backed up so it's covered. Thanks.
Hi,
> > > A statistics event consists of a function (optional), a statement
> > > (optional) and the counter ID. I converted the counters from
> > > tree-ssa-propagate.c as an example, instead of
> > >
> > > prop_stats.num_copy_prop++;
> > >
> > > you now write
> > >
> > >
On Sat, 15 Mar 2008, NightStrike wrote:
> On 3/15/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > I support the final-release-then-close approach. But can we get a
> > volunteer to convert that branch to GPLv3... ?
>
> How complicated is the task?
It's not complicated, but perhaps it is tediou
On Sat, 15 Mar 2008, Eric Botcazou wrote:
> > I think we agreed to _not_ move the 4.1 branch to GPLv3.
>
> FWIW that was my understanding as well.
>
> > So, if the FSF says we may not release as GPLv2 then we should not do
> > a 4.1.3 release. The branch is simply open as 4.1 is widely adopted
>
18 matches
Mail list logo
