Re: gcc-4.1-20080303 is now available
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?
Re: gcc-4.1-20080303 is now available
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 branch alive? > >> > >> Looking at the changes that were made in the last three months still, > >> it seems the branch is still surprisingly alive, so it may not yet be > >> the time to close it. Personally I don't have a preference either way, > >> but I'll update our main page to reflect the current status (no new > >> releases, among others) a bit better and if the decision is to close > >> it down volunteer to take the necessary steps. > > > > The alternative would to be to make a final release and close it. > > We have two options. What do people think? > > My understanding is that the FSF has directed us to not make any > further GPLv2 releases. So if we do a 4.1.3 release, the branch needs > to be converted to GPLv3. This could be done using Nick Clifton's > script, but somebody would have to do the work. > > I'm relatively agnostic on whether to do a 4.1.3 release or not. I think we agreed to _not_ move the 4.1 branch to GPLv3. 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 not from point-releases anyway. Richard.
Re: gcc-4.1-20080303 is now available
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, Gabriel Dos Reis wrote: > > > > > Do we still want to keep this branch alive? > > > > > > > > Looking at the changes that were made in the last three months still, > > > > it seems the branch is still surprisingly alive, so it may not yet be > > > > the time to close it. Personally I don't have a preference either > way, > > > > but I'll update our main page to reflect the current status (no new > > > > releases, among others) a bit better and if the decision is to close > > > > it down volunteer to take the necessary steps. > > > > > > The alternative would to be to make a final release and close it. > > > We have two options. What do people think? > > > > If there are nontrivial bug fixes in the SVN branch but not in the last > > 4.1.x release, I think it would be better to use the > > final-release-then-close approach, so that there is an available tarball on > > fsf.gnu.org that has all of the work and people don't have to use SVN > > or a snapshot for anything. > > 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.
Re: gcc-4.1-20080303 is now available
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]
Re: gcc-4.1-20080303 is now available
> 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 not from > point-releases anyway. Seconded. -- Eric Botcazou
Re: gcc-4.1-20080303 is now available
> fixincludes/fixincl.x changed to GPLv3 on 4.1 branch a month ago. By accident I presume? -- Eric Botcazou
Re: gcc-4.1-20080303 is now available
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-gplv2-branch off the top. Richard.
Re: gcc-4.1-20080303 is now available
> 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 makes things simpler for distributors. And I think that creating a special branch would create more confusion than anything else. So I'd simply revert the patch that (presumably) accidentally changed the licence of this particular file and ask people to be careful about this. -- Eric Botcazou
[PATCH][RFC] Statistics "infrastructure"
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 aspect I think is simplicity to use it and especially
add new "counters". Thus, we simply associate a counter with a string ID.
The patch is a rough implementation of the current features of
pass specific statistics plus a global "log" with statistics events.
In the end you can do any postprocessing / globbing / summing of
such global log.
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
statistics_add ("copy propagations");
(function and statement omitted, you might prefer #defines for strings
that you use multiple times). In the .ccp1 dump file you then get
Pass statistics:
constant propagations: 15
copy propagations: 5
in stead of previously
Constants propagated: 15
Copies propagated: 5
Predicates folded: 0
and the 208t.statistics file will for example contain
33 ccp "constant propagations" "sin_pif" "(nostmt)"
33 ccp "constant propagations" "sin_pif" "(nostmt)"
38 copyprop"copy propagations" "sin_pif" "(nostmt)"
38 copyprop"copy propagations" "sin_pif" "(nostmt)"
38 copyprop"copy propagations" "sin_pif" "(nostmt)"
38 copyprop"copy propagations" "sin_pif" "(nostmt)"
38 copyprop"copy propagations" "sin_pif" "(nostmt)"
33 ccp "constant propagations" "__ieee754_lgammaf_r" "(nostmt)"
33 ccp "constant propagations" "__ieee754_lgammaf_r" "(nostmt)"
33 ccp "constant propagations" "__ieee754_lgammaf_r" "(nostmt)"
...
(pass number, pass name, ID, function name, statement location
(unimplemented)).
The backend implementation is of course not limited to be that simple,
but it is the interface that I am curious if it provides enough
information.
(please trim CC, use gcc@ for general discussion, gcc-patches@ for
implementation details of this hac^H^H^Hpatch)
Thanks,
Richard.
2008-03-15 Richard Guenther <[EMAIL PROTECTED]>
* tree-pass.h (statistics_add_fn_stmt): Declare.
(statistics_add_stmt): New macro.
(statistics_add): Likewise.
* passes.c (statistics_dump_nr, statistics_dump_file): New globals.
(init_optimization_passes): Register statistics dump.
(execute_function_todo): Flush per function statistics.
(execute_pass_list): Start statistics dump.
(execute_ipa_pass_list): Likewise.
(struct statistics_counter_s): New structure.
(statistics_fini_pass): New function.
(statistics_add_fn_stmt): Likewise.
* tree-ssa-propagate.c: Use statistics infrastructure.
Index: trunk/gcc/passes.c
===
*** trunk.orig/gcc/passes.c 2008-03-15 17:26:59.0 +0100
--- trunk/gcc/passes.c 2008-03-15 19:09:30.0 +0100
*** along with GCC; see the file COPYING3.
*** 102,107
--- 102,111
declarations for e.g. AIX 4.x. */
#endif
+ static void statistics_fini_pass (void);
+ static int statistics_dump_nr;
+ static FILE *statistics_dump_file;
+
/* This is used for debugging. It allows the current pass to printed
from anywhere in compilation. */
struct tree_opt_pass *current_pass;
*** init_optimization_passes (void)
*** 797,802
--- 801,808
register_dump_files (all_passes, false,
PROP_gimple_any | PROP_gimple_lcf | PROP_gimple_leh
| PROP_cfg);
+ statistics_dump_nr = dump_register (".statistics", "statistics",
+ "statistics", TDF_TREE, 0);
}
/* If we are in IPA mode (i.e., current_function_decl is NULL), call
*** execute_function_todo (void *data)
*** 883,889
flags &= ~cfun->last_verified;
if (!flags)
return;
!
/* Always cleanup the CFG before trying to update SSA. */
if (flags & TODO_cleanup_cfg)
{
--- 889,897
flags &= ~cfun->last_verified;
if (!flags)
return;
!
! statistics_fini_pass ();
!
/* Always cleanup the CFG before trying to update SSA. */
if (flags & TODO_cleanup_cfg)
{
*** execute_one_pass (struct tree_opt_pass *
*** 1171,1176
--- 1179,1186
void
execute_pass_list (struct tree_opt_pass *pass)
{
+ if (statistics_dump_file == NULL)
+ statistics_dump_file = dump_begin (statistics_dump_nr, NULL);
do
{
if (execute_one_pass (pa
Re: gcc-4.1-20080303 is now available
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
Re: gcc-4.1-20080303 is now available
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 everything was GPL v3 at this stage, just that not all the file headers have been changed (the file headers are not legally decisive in determining the licensing in any case).
Re: [PATCH][RFC] Statistics "infrastructure"
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 most important aspect I think is simplicity to use it and especially
> add new "counters". Thus, we simply associate a counter with a string ID.
>
> The patch is a rough implementation of the current features of
> pass specific statistics plus a global "log" with statistics events.
> In the end you can do any postprocessing / globbing / summing of
> such global log.
>
> 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
>
> statistics_add ("copy propagations");
>
> (function and statement omitted, you might prefer #defines for strings
> that you use multiple times).
it would perhaps be better to use #defines with integer values? Also,
it would be more consistent to have statistics.def similar to
timevar.def for this. It would make creation of new counters a bit
more difficult, but on the other hand, it would make it possible to
classify the counters (by type of the counted operation/its
expensiveness/...),
Zdenek
Re: Official GCC git repository
* 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 the performance isn't even close to GIT (or Subversion with a reasonably fast connection to the server, for that matter). If you like GIT, it shoud be relatively painless to use it with the GCC Subversion repository. The only annoyance is that "git svn dcommit" transmits changed file as a whole to the server, which can take a while for large Changelog files. On the other hand, getting GIT repositories into other formats can be quite painful because GIT doesn't care about file identity, but other systems do.
Re: [PATCH][RFC] Statistics "infrastructure"
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 well as to allow CU wide "fancy" analysis.
> >
> > The most important aspect I think is simplicity to use it and especially
> > add new "counters". Thus, we simply associate a counter with a string ID.
> >
> > The patch is a rough implementation of the current features of
> > pass specific statistics plus a global "log" with statistics events.
> > In the end you can do any postprocessing / globbing / summing of
> > such global log.
> >
> > 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
> >
> > statistics_add ("copy propagations");
> >
> > (function and statement omitted, you might prefer #defines for strings
> > that you use multiple times).
>
> it would perhaps be better to use #defines with integer values? Also,
> it would be more consistent to have statistics.def similar to
> timevar.def for this. It would make creation of new counters a bit
> more difficult, but on the other hand, it would make it possible to
> classify the counters (by type of the counted operation/its
> expensiveness/...),
The difficultness to add new counters is exactly why I didn't go
down that route. I expect this mainly used for experimentation
where it is IMHO inconvenient to go the .def route (also like
with timevar.def we probably just get false re-use of IDs).
We might auto-generate (part of) the ID from the instrumentation
point (FILE/LINE) as well... (thus get "copy prop at xyz.c:25")
The point is to have easy instrumentation this way and automatic
analysis, not some stable interface (IMHO). For this reason
classifying the counters is engineering at the wrong point - you'd
do that at the analysis point and not hard-code this somewhere
(after all, just name it "lim expensive" ;)).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
Re: Official GCC git repository
[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. --Angela
Re: [PATCH][RFC] Statistics "infrastructure"
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
> > >
> > > statistics_add ("copy propagations");
> > >
> > > (function and statement omitted, you might prefer #defines for strings
> > > that you use multiple times).
> >
> > it would perhaps be better to use #defines with integer values? Also,
> > it would be more consistent to have statistics.def similar to
> > timevar.def for this. It would make creation of new counters a bit
> > more difficult, but on the other hand, it would make it possible to
> > classify the counters (by type of the counted operation/its
> > expensiveness/...),
>
> The difficultness to add new counters is exactly why I didn't go
> down that route. I expect this mainly used for experimentation
> where it is IMHO inconvenient to go the .def route
I thought of it more as an aid in debugging performance problems, as in,
checking the dumps without introducing new statistics counters; in which
case, having some description of what the counters mean and the metadata
from the .def file would be useful.
On the other hand, I agree that for the purpose that you suggest
avoiding .def is better. Perhaps we could require that all the
statistics strings are #defined and documented (and of course you can
ignore this rule for the counters that you use for experimentation)?
Zdenek
Re: gcc-4.1-20080303 is now available
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 tedious. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: gcc-4.1-20080303 is now available
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 > > and distributors ship from the top of the branch and not from > > point-releases anyway. > > Seconded. I understand and can support (up to a point) the desire of distributors to continue working within GPLv2 and I know that's why the 4.1 branch is in this situation. However IMHO this position is in tension with the interests of users who don't get gcc from distributors (think non-linux-gnu platforms) and therefore leaving the 4.1 branch in this situation forever eventually is against the interests of the FSF. Free platforms are most important to us, but users of free software (gcc) on other platforms should eventually be considered too. So *at some point* we have to consider what to do about 4.1.x. Right now it's been about a year since it's last release and so none of the bugfixes made on the branch are benefitting users who don't get their 4.1 compiler from a distributor. Also there is the maintenance burden of having four active branches. I don't think leaving the current situation indefinitely is an option. So we're left several choices: 1. Close 4.1 immediately, without a release. 2. Convert 4.1 to GPLv3 for one last release and then close it. 3. Postpone the decision, but let's decide how long we're going to keep the 4.1 branch around. Then we still have to pick from 1 or 2. I suggest we do 2, or if necessary we do 3+2. For those that support #3, I'd like to hear how long they feel keeping 4.1 open is necessary. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
