Re: Official GCC git repository
Harvey Harrison wrote: A few things I'd like to clean up if we move a copy over: 1) generate a author's file so the commits have better than just a login name as the commiter/author. Very good idea. And the pairing should already be in the aliases file on gcc.gnu.org. 2) change the layout so it can be cloned just like any other git repo What would the problem be? I have just cloned it normally. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/
Re: Official GCC git repository
Harvey Harrison wrote: Actually, the newer git-svn's finally switched metadata format, so once I get done moving it over, it will be ~350MB of git data and 50MB or so of git-svn metadata. (rev_db vs rev_map format) Finally. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/
Re: update_path in gcc/prefix.h?
Hello All
I = Basile STARYNKEVITCH wrote:
Daniel Jacobowitz wrote:
On Wed, Mar 12, 2008 at 04:06:52PM +0100, Basile STARYNKEVITCH wrote:
What is the exact intent of the update_path in gcc/prefix.[hc]?
Very complicated and underdocumented; I avoid it for that reason.
Can't you use an existing directory variable, like gcc_libexec_prefix?
Thanks for the suggestion. I'll probably try.
I'm trying just now, and I believe I cannot use it as is (remember that
I want to read a file within cc1!) because:
* gcc_libexec_prefix appears only in gcc/gcc.c; in the current trunk
(r133208) it is a static char* variable declared in gcc/gcc.c line 1476
and used in the static function process_command between lines 3411 and 3463
* I want to have the value of $(libexecsubdir)/melt-private-include/ (in
gcc/Makefile.in parlance) from within a pass (or some initialization in)
the cc1 (& related) backends.
http://gcc.gnu.org/ml/gcc/2008-03/msg00551.html
So how do I get $(libexecsubdir)/melt-private-include/ from within C
code of cc1?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Official GCC git repository
Ben Elliston wrote: >> David Woodhouse wrote: > >>> To be honest, I find it weird that Subversion even exists. Precisely >>> because it _is_ so close to what people were using before, as you point >>> out. I've never really understood why anyone would bother to change from >>> CVS to SVN -- it just seems to be part of the 'one VCS per project' >>> insanity. > > I remember seeing a talk by Jim Blandy on Subversion around 2001. At > the time, the CVS-using community in the audience were (vocally) > impressed by what a huge step forward it was in addressing the > limitations of CVS. > > There are indeed other choices out there these days, but at the time it > began, Subversion made a lot of sense. Yes. And unless you want to make the jump to distributed VCS, it still does. Andrew.
Re: Official GCC git repository
I could never understand why anyone would use anything but CVS (if that works for them), or git. The VCS-du-jour craze just confuses me. I could understand a lot why people would use subversion and not CVS. Not that I like subversion a lot (the trunk/branches/tags system seems a bit ad-hoc for example, though I must admit it works great), but the gcc CVS repository took 1 hour to tag, while it's constant time for subversion. I could understand a little why people would use hg instead of git. I think that git's design is better, and most of the common objections are red herring (e.g. I never had any problem with "git diff -rHEAD vs. git diff" because, if my commit is complicated enough to add files, I always use "git citool" to review it instead), but it didn't work well on Windows until very recently, and there are no good tutorials IMNSHO. I even felt the need to write mine (see http://smalltalk.gnu.org/tags/git if you're intereste). Paolo
Re: Official GCC git repository
Bernardo Innocenti wrote: Harvey Harrison wrote: A few things I'd like to clean up if we move a copy over: 1) generate a author's file so the commits have better than just a login name as the commiter/author. Or in the ChangeLog. Paolo
DFA state and arc explosion
Hello, In porting GCC (still 4.2) to our VLIW processor, I tried to model pipeline as precisely as possible. If I only model the issue slot resource, it is fine. GCC generates a small state machine and compiles code quickly. However, if I also want to model the resource for writing back register file, the number of states and arcs just explodes. It is especially true for long pipeline instruction. In the following example, (define_insn_reservation "mul_op" 8 (and (eq_attr "type" "mul") (eq_attr "dual" "no")) "long_p0|long_p1, nothing * 7") 50 NDFA states,178 NDFA arcs 50 DFA states, 178 DFA arcs 50 minimal DFA states, 178 minimal DFA arcs (define_insn_reservation "mul_op" 8 (and (eq_attr "type" "mul") (eq_attr "dual" "no")) "long_p0|long_p1, nothing * 6, port_0") 7680 NDFA states, 27008 NDFA arcs 7680 DFA states, 27008 DFA arcs 7680 minimal DFA states, 27008 minimal DFA arcs The number of states and arcs increases dramatically for just single difference. Modeling other instructions in a similar way becomes impossible therefore. It takes forever to build GCC. What I did wrong here? I just want to model resource usage in issue slot and writeback stage in order possible stall cycle. What is the cheap to do this? Thanks in advance. Cheers, Bingfeng Mei Broadcom UK
RE: DFA state and arc explosion
I don't really know what NDFA, DFA and minimal DFA mean. But by a quick search I found other machine porting could have the same number as well. http://osdir.com/ml/linux.lfs.clfs.support/2006-10/msg00042.html Bingfeng -Original Message- From: Galloth [mailto:[EMAIL PROTECTED] Sent: 14 March 2008 10:58 To: Bingfeng Mei Subject: Re: DFA state and arc explosion Hello, I maybe totally wrong, but how it is possible that your NDFA DFA and Minimal DFA are the same? I would think that this indicate some sort of error. Jan 2008/3/14, Bingfeng Mei <[EMAIL PROTECTED]>: > Hello, > In porting GCC (still 4.2) to our VLIW processor, I tried to model > pipeline as precisely as possible. If I only model the issue slot > resource, it is fine. GCC generates a small state machine and compiles > code quickly. > > However, if I also want to model the resource for writing back register > file, the number of states and arcs just explodes. It is especially true > for long pipeline instruction. In the following example, > > (define_insn_reservation "mul_op" 8 >(and (eq_attr "type" "mul") > (eq_attr "dual" "no")) >"long_p0|long_p1, nothing * 7") > >50 NDFA states,178 NDFA arcs >50 DFA states, 178 DFA arcs >50 minimal DFA states, 178 minimal DFA arcs > > (define_insn_reservation "mul_op" 8 >(and (eq_attr "type" "mul") > (eq_attr "dual" "no")) >"long_p0|long_p1, nothing * 6, port_0") > > 7680 NDFA states, 27008 NDFA arcs > 7680 DFA states, 27008 DFA arcs > 7680 minimal DFA states, 27008 minimal DFA arcs > > The number of states and arcs increases dramatically for just single > difference. Modeling other instructions in a similar way becomes > impossible therefore. It takes forever to build GCC. > > What I did wrong here? I just want to model resource usage in issue > slot and writeback stage in order possible stall cycle. What is the > cheap to do this? Thanks in advance. > > Cheers, > > Bingfeng Mei > Broadcom UK > > -- Jan Kastil [EMAIL PROTECTED]
Re: update_path in gcc/prefix.h?
On Fri, Mar 14, 2008 at 10:13:01AM +0100, Basile STARYNKEVITCH wrote: > So how do I get $(libexecsubdir)/melt-private-include/ from within C code > of cc1? Either by replicating code from the gcc driver, or by adding it to cc1's command line. -- Daniel Jacobowitz CodeSourcery
Re: vectorizer default in 4.3.0 changes document missing
On Mon, 10 Mar 2008, Andrew Pinski wrote: > Just like with any other parts of GCC, you can check out the web docs > and change them yourself. Yes I agree they should be mentioned. That's fair to some extent, but only to some -- if I find an issue with the kernel, I'd hope this _not_ to be Andi's immediate response. :-/ On Mon, 10 Mar 2008, Andi Kleen wrote: > Sorry I'm not going through this now, especially not for such a > trivialty. My past experiences are that it takes several months of > pings to get anything included and I don't have time for that now. Not for the web pages, I swear. :-) Gerald
Re: Official GCC git repository
On Fri, Mar 14, 2008 at 6:35 AM, Paolo Bonzini <[EMAIL PROTECTED]> wrote: > > > I could never understand why anyone would use anything but CVS (if that > > works for them), or git. The VCS-du-jour craze just confuses me. > > I could understand a lot why people would use subversion and not CVS. > Not that I like subversion a lot (the trunk/branches/tags system seems a > bit ad-hoc for example, though I must admit it works great), but the gcc > CVS repository took 1 hour to tag, while it's constant time for subversion. > > I could understand a little why people would use hg instead of git. I > think that git's design is better, and most of the common objections are > red herring (e.g. I never had any problem with "git diff -rHEAD vs. git > diff" because, if my commit is complicated enough to add files, I always > use "git citool" to review it instead), but it didn't work well on > Windows until very recently, and there are no good tutorials IMNSHO. git and hg mainly differ in backend storage more than anything else. It would be not difficult to write a bridge from one to the other. My current plan is to bug a few of our devs to try git, and a few to try hg (for a few weeks each), giving them whatever tutorials are around, and see if they find it better enough than subversion. (Personally, I use hg now because being able to log/etc the entire gcc history and do offline commits makes my life a lot easier now that i travel more).
Re: Official GCC git repository
Git-daemon is already running, i think (frank, is this right?) On Thu, Mar 13, 2008 at 6:47 PM, Bernardo Innocenti <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote: > > > > Bernardo Innocenti wrote: > >> Fair enough. I hereby volunteer to setup and maintain the git > >> mirror on gcc.gnu.org if someone provides me a shell account > >> there. > > > > Email [EMAIL PROTECTED] and ask what kind of sponsorship they want > > to require for a shell account (for write access to repositories, we > > usually only require 1 sponsor, but these do not give you shell > > access). > > As stated above, I'd like to request shell access to gcc.gnu.org to > setup a git mirror of the GCC svn repository. I'd also suggest Harvey > Harrison as a co-maintainer of the mirror, as he helped setting it up on > git.infradead.org. > > At this time, the repository and git-svn metadata take up 2.5GB of disk > space. CPU usage is minimal. I will just have to install a shell > script running from my user crontab. > > We don't require root access for ordinary maintenance, but someone would > have to install and configure at least git-daemon and gitweb to make the > mirror publicly accessible. > > If it seems too much hassle for the benefit, we'll keep going with the > existing git mirror on infradead.org, but I feel it would better serve > our users and developers to at least mention it as an official mirror on > our web site. > > > > > I am happy to sponsor you if it helps. > > Thanks, Daniel! > > > > -- > \___/ > |___| Bernardo Innocenti - http://www.codewiz.org/ >\___\ One Laptop Per Child - http://www.laptop.org/ >
Re: Official GCC git repository
My current plan is to bug a few of our devs to try git, and a few to try hg (for a few weeks each), giving them whatever tutorials are around, and see if they find it better enough than subversion. I can try to use git, but I'm already quite experienced in it so I'm not representative. (Personally, I use hg now because being able to log/etc the entire gcc history and do offline commits makes my life a lot easier now that i travel more). Same here. I was using tla for other projects, but it was so slow that the only benefit for me was offline commits. How useful it is to have the entire history at hand, that's something you just have to try to understand. :-) Paolo
Re: Official GCC git repository
Hi - > Git-daemon is already running, i think (frank, is this right?) 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.) I'll try to set up the blank directories and then hand it over to Bernardo for population and maintenance. - FChE
[Ada] GNAT BUG Assert_Failure uintp.adb:1593
On cygwin, I currently get the following GNAT bug: /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev -gcc/ -B/usr/local/i686-pc-cygwin/bin/ -c -g -O2 -gnatpg -gnata -nostdinc - I- -I. -Iada -I../../gcc/gcc/ada ../../gcc/gcc/ada/ada.ads -o ada/ada.o +===GNAT BUG DETECTED==+ | 4.4.0 20080314 (experimental) [trunk revision 133215] (i686-pc-cygwin) | | Assert_Failure uintp.adb:1593| | No source file position information available| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. compilation abandoned make[3]: *** [ada/ada.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 Should I skip Ada for gcc trunk on cygwin a while now? -- Cheers, /ChJ
Re: [Ada] GNAT BUG Assert_Failure uintp.adb:1593
"Christian Joensson" <[EMAIL PROTECTED]> writes: > On cygwin, I currently get the following GNAT bug: > > /usr/local/src/trunk/objdir/./prev-gcc/xgcc > -B/usr/local/src/trunk/objdir/./prev > -gcc/ -B/usr/local/i686-pc-cygwin/bin/ -c -g -O2 -gnatpg -gnata > -nostdinc - > I- -I. -Iada -I../../gcc/gcc/ada ../../gcc/gcc/ada/ada.ads -o ada/ada.o > +===GNAT BUG DETECTED==+ > | 4.4.0 20080314 (experimental) [trunk revision 133215] (i686-pc-cygwin) | > | Assert_Failure uintp.adb:1593| That looks similar to PR35493, but that should already be fixed by r133082. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Official GCC git repository
Hi -
On Thu, Mar 13, 2008 at 11:47:52PM +0100, Bernardo Innocenti wrote:
> As stated above, I'd like to request shell access to gcc.gnu.org to
> setup a git mirror of the GCC svn repository. I'd also suggest Harvey
> Harrison as a co-maintainer of the mirror, as he helped setting it up on
> git.infradead.org.
OK, /git/gcc.git appears ready for you to populate & maintain. Access
as {http,git,ssh}://gcc.gnu.org/gcc.git should all work.
Harvey appears to have no sourceware account, so he'll need to request
one if necessary.
- FChE
Re: Test Harness and SPARC VIS Instructions
Uros Bizjak wrote:
Hello!
This one looks like another test slipping another unsupported
instruction by.
0x020012b8 : bne,pn %icc, 0x200138c
Is this UltraSPARC and not V7? Do we need two bad instructions
in the test case?
Executing on host: /home/joel/work-gnat/svn/b-gcc1-sparc/gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc1-sparc/gcc/
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.dg/vect/vect-align-2.c
gcc_tg.o -ftree-vectorize -fno-vect-cost-model -mcpu=ultrasparc -mvis
-O2 -fdump-tree-vect-details -DSTACK_SIZE=2048 -fno-show-column
-B/home/joel/work-gnat/svn/bsp-install/sparc-rtems4.9/sis/lib/ -specs
bsp_specs -qrtems -mcpu=cypress
/home/joel/work-gnat/svn/b-gcc1-sparc/rtems_gcc_main.o -Wl,-wrap,exit
-Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o
./vect-align-2.exe (timeout = 300)
PASS: gcc.dg/vect/vect-align-2.c (test for excess errors)
Unexpected trap (0x 2) at address 0x020012B8^M
illegal instruction^M
FAIL: gcc.dg/vect/vect-align-2.c execution test
This is not-guarded runtime test. The problem is fixed by the attached
patch.
Confirmed in my overnight run. See
It now looks like the scan-tree-dump-times tests are the next
easy group that isn't supported that needs to be marked as
not supported. I didn't see anything obv
FAIL: gcc.dg/vect/pr33804.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr33804.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 1
FAIL: gcc.dg/vect/pr33953.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr33953.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 1
I assume these fail because we don't dump files from the target.
How do you indicate these are not supported?
2008-03-13 Uros Bizjak <[EMAIL PROTECTED]>
* gcc.dg/vect/vect-align-2.c: Remove dg-do run directive.
(main): Call check_vect.
Tested on x86_64-pc-linux-gnu, committed to mainline.
Uros.
Index: vect-align-2.c
===
--- vect-align-2.c (revision 133190)
+++ vect-align-2.c (working copy)
@@ -1,5 +1,4 @@
/* { dg-require-effective-target vect_int } */
-/* { dg-do run } */
#include
#include
@@ -36,6 +35,8 @@
{
struct foo *fp = (struct foo *) malloc (2*sizeof (struct foo));
+ check_vect ();
+
fbar(fp);
return 0;
}
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Re: dg-skip-if was Re: gcc 4.3.0 i386 default question
On Friday 14 March 2008, Joseph S. Myers wrote:
> On Thu, 13 Mar 2008, Joel Sherrill wrote:
> > > Also, if you use a multilib option in testing, that option goes on the
> > > command line *after* the options specified in dg-options. The tests
> > > may need to use dg-skip-if to skip them if any CPU option other than
> > > the one in the test is explicitly specified (so it would be tested if
> > > no explicit -mcpu option is used, or if -mcpu=405 is the multilib
> > > option being tested).
> >
> > Are you thinking of something roughly like this?
> >
> > /* { dg-skip-if "" { { !-mcpu=405 } } { "*" } { "" } } */
>
> I'm thinking of
>
> /* { dg-skip-if "" { *-*-* } { "-mcpu=*" } { "-mcpu=405" } } */
I you have several of these you might want to consider adding an
effective-target check that uses a compile test rather than guessing from
commandline options. c.f. check_effective_target_arm32 and
check_effective_target_arm_vfp_ok.
Paul
Re: Test Harness and SPARC VIS Instructions
On Fri, Mar 14, 2008 at 3:45 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: > It now looks like the scan-tree-dump-times tests are the next > easy group that isn't supported that needs to be marked as > not supported. I didn't see anything obv > > FAIL: gcc.dg/vect/pr33804.c scan-tree-dump-times vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/pr33804.c scan-tree-dump-times vect "vectorizing stmts > using SLP" 1 > FAIL: gcc.dg/vect/pr33953.c scan-tree-dump-times vect "vectorized 1 loops" 1 > FAIL: gcc.dg/vect/pr33953.c scan-tree-dump-times vect "vectorizing stmts > using SLP" 1 > > I assume these fail because we don't dump files from the target. No, these dumps are produced by the compiler, this test is not executable test. It checks for some feature, and the failure means that this feature is not supported, or was not triggered for some reason. There are many check_effective_target_vect_ procedures in testsuite/lib/target-supports.exp, and depending on what your target supports, you should add the target to the correct ones. > How do you indicate these are not supported? See above. Uros.
Re: dg-skip-if was Re: gcc 4.3.0 i386 default question
Joseph S. Myers wrote:
On Thu, 13 Mar 2008, Joel Sherrill wrote:
Also, if you use a multilib option in testing, that option goes on the
command line *after* the options specified in dg-options. The tests may
need to use dg-skip-if to skip them if any CPU option other than the one
in the test is explicitly specified (so it would be tested if no explicit
-mcpu option is used, or if -mcpu=405 is the multilib option being
tested).
Are you thinking of something roughly like this?
/* { dg-skip-if "" { { !-mcpu=405 } } { "*" } { "" } } */
I'm thinking of
/* { dg-skip-if "" { *-*-* } { "-mcpu=*" } { "-mcpu=405" } } */
Thanks. Wow without an example, I don't think I ever would have
gotten it. That is cryptic.
The above is close but didn't work. It looks like the arguments
are "line target include exclude" so I swapped the last two
arguments to get this which I added after the dg-options
which adds -mcpu=405
/* { dg-skip-if "" { *-*-* } { "-mcpu=405" } { "-mcpu=" } } */
I think this is doing what we want it to. It looks like it results
the tests getting run when -mcpu=405 and excluded when
-mcpu=603e is set on the board cflags.
I did a grep and there are 155 CPU specific test cases that appear
to need to be reviewed for this.
$ grep -r dg-options * | grep mcpu | grep -v .svn | cut -d'/' -f1 | uniq -c
8 alpha
14 frv
3 m68k
76 powerpc
54 sparc
If you all think this is the right approach, ack me and I will
get the powerpc cases done first and submit a patch for review.
--joel
but I don't guarantee that will work as expected. (There are some tests
in gcc.target/cris skipping on "-march*", which seems similar.)
--
Joseph S. Myers
[EMAIL PROTECTED]
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Re: dg-skip-if was Re: gcc 4.3.0 i386 default question
On Fri, 14 Mar 2008, Joel Sherrill wrote: > If you all think this is the right approach, ack me and I will > get the powerpc cases done first and submit a patch for review. Janis will need to confirm the right approach. The aim is: * If no -mcpu option in the multilib flags, run the test (with the -mcpu option from dg-options getting added). * If there is a -mcpu option in the multilib flags, and it's the same as that in dg-options, run the test. * If there is a -mcpu option in the multilib flags, and it's different from that in dg-options, skip the test because the multilib flags would override dg-options. -- Joseph S. Myers [EMAIL PROTECTED]
Re: dg-skip-if was Re: gcc 4.3.0 i386 default question
On Fri, 2008-03-14 at 10:18 -0500, Joel Sherrill wrote:
> /* { dg-skip-if "" { *-*-* } { "-mcpu=405" } { "-mcpu=" } } */
>
> I think this is doing what we want it to. It looks like it results
> the tests getting run when -mcpu=405 and excluded when
> -mcpu=603e is set on the board cflags.
The test directives are documented in the internals manual. From
sourcebuild.texi:
@item @{ dg-skip-if @var{comment} @{ @var{selector} @}
@{ @var{include-opts} @} @{ @var{exclude-opts} @} @}
Skip the test if the test system is included in @var{selector} and if
each of the options in @var{include-opts} is in the set of options with
which the test would be compiled and if none of the options in
@var{exclude-opts} is in the set of options with which the test would be
compiled.
The directive above says to skip the test on any target when
"-mcpu=450" is used and "-mcpu=" is not used. You'd actually
want "-mcpu=*", since "-mcpu=" isn't a full option, but then
the test will never be skipped whenever -mcpu=* is used.
Proc check_conditional_xfail from framework.exp in DejaGnu
processes the lists of included and excluded option and with
"--verbose --verbose" in RUNTESTFLAGS will print messages to
the test log (e.g. obj_dir/gcc/testsuite/gcc/gcc.log) about
its progress.
I think that dg-skip-if won't do what you need and you'll need
to add effective-target keywords.
Janis
Re: dg-skip-if was Re: gcc 4.3.0 i386 default question
On Fri, 2008-03-14 at 10:21 -0700, Janis Johnson wrote:
> On Fri, 2008-03-14 at 10:18 -0500, Joel Sherrill wrote:
>
> > /* { dg-skip-if "" { *-*-* } { "-mcpu=405" } { "-mcpu=" } } */
> >
> > I think this is doing what we want it to. It looks like it results
> > the tests getting run when -mcpu=405 and excluded when
> > -mcpu=603e is set on the board cflags.
>
> The test directives are documented in the internals manual. From
> sourcebuild.texi:
>
> @item @{ dg-skip-if @var{comment} @{ @var{selector} @}
> @{ @var{include-opts} @} @{ @var{exclude-opts} @} @}
> Skip the test if the test system is included in @var{selector} and if
> each of the options in @var{include-opts} is in the set of options with
> which the test would be compiled and if none of the options in
> @var{exclude-opts} is in the set of options with which the test would be
> compiled.
>
> The directive above says to skip the test on any target when
> "-mcpu=450" is used and "-mcpu=" is not used. You'd actually
> want "-mcpu=*", since "-mcpu=" isn't a full option, but then
> the test will never be skipped whenever -mcpu=* is used.
>
> Proc check_conditional_xfail from framework.exp in DejaGnu
> processes the lists of included and excluded option and with
> "--verbose --verbose" in RUNTESTFLAGS will print messages to
> the test log (e.g. obj_dir/gcc/testsuite/gcc/gcc.log) about
> its progress.
>
> I think that dg-skip-if won't do what you need and you'll need
> to add effective-target keywords.
On the other hand, to run a test for -mcpu=450 but no other -mcpu
option, this very ugly directive works (pattern matching is done
with globs):
/* { dg-skip-if "" { *-*-* } { "" } { "-mcpu=[0-35-9][0-46-9][1-9]*" } } */
That kind of thing could get ugly very quickly if there are
multiple cpus that would work.
Re: dg-skip-if was Re: gcc 4.3.0 i386 default question
On Fri, 14 Mar 2008, Paul Brook wrote: > I you have several of these you might want to consider adding an > effective-target check that uses a compile test rather than guessing from > commandline options. c.f. check_effective_target_arm32 and > check_effective_target_arm_vfp_ok. Note the issue is *not* an error if two options are present, simply that one overrides the other. The tests must be run, with the option from dg-options, if no -mcpu multilib option is passed. (This probably covers most runs of the tests.) The tests should be run if the same option as in dg-options is also in the multilib options. (This is probably a less frequent case.) The tests must not be run if a different option is in dg-options. The compiler won't give the errors that are useful in checking effective targets, it will just quietly have the multilib option override the option in dg-options. -- Joseph S. Myers [EMAIL PROTECTED]
The Linux binutils 2.18.50.0.5 is released
This is the beta release of binutils 2.18.50.0.5 for Linux, which is
based on binutils 2008 0314 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.18.50.0.5 to
[EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.18.50.0.4:
1. Update from binutils 2008 0314.
2. Add Intel XSAVE new instruction support.
3. Fix an ia64 linker crash on unsupported TLS relocations. PR 5913.
4. Fix x86 assembler for gcc 4.3.
5. Fix a linker memory corruption. PR 5788.
6. Correct linker 64k section support. PR 5900.
7. Correct hidden, weak and undefined symbol handling. PR 5789.
8. Fix linker for 64bit targets on 32bit hosts. PR 5303/5755.
9. Fix assembler crash with .set on register. PR 5543.
10. Fix a typo in linker. PR 5765.
11. Fix "string -O" infinite loop. PR 5713.
12. Fix .exitm in assembler. PR 5895.
13. Fix a linker crash. PR 5761.
14. Fix various arm bugs.
15. Fix various bfin bugs.
16. Fix various h8 bugs.
17. Fix various ppc bugs.
18. Fix various spu bugs.
19. Fix various xtensa bugs.
Changes from binutils 2.18.50.0.3:
1. Update from binutils 2008 0208.
2. Update readelf/objdump to dump DWARF frame info with machine
register names on x86.
3. Optimize x86-64 assembler to omit REX.W prefix when it is ignored.
4. Add operand size check to x86 assembler. PR 5534.
5. Add -march=CPU[,+EXTENSION...], -mmnemonic, -msyntax, -mindex-reg,
-mnaked-reg and -mold-gcc options to x86 assembler.
6. Add -Mintel-mnemonic/-Mintel-mnemonic options to x86 disassembler.
7. Update x86 disassembler to handle r12 like rsp in memory operand.
8. Update x86 disassembler to properly support movntq, movntsd,
movntss, movntps, movntpd, movntdq and movntdqa.
9. Update x86 disassembler to support AMD nops.
10. Update x86 disassembler for cvtsi2ss/cvtsi2sd.
11. Fix x86 assembler to support new instructions on 2 different archs.
12. Update linker not to generate incorrect debug info for 64bit target
on 32bit host. PR 5303.
13. Update ia64 assembler to support new registers in Itanium 9100
series.
14. Fix strip on PT_NOTE segment. PR 5488.
15. Fix strip/objcopy on HPUX/ia64. PR 5449.
16. Fix strip/objcopy for EFI. PR 5307.
17. Remove duplicated sections from objdump for COFF/PE. PR 5299.
18. Fix a linker corruption. PR 5522.
19. Fix mingw for 64bit targets.
20. Fix various arm bugs.
21. Fix various fr30 bugs.
22
Re: Official GCC git repository
Bernardo Innocenti wrote: >Fair enough. I hereby volunteer to setup and maintain the git >mirror on gcc.gnu.org if someone provides me a shell account >there. Having done some heavy public git mirroring lately, and reconnecting old trees (fixing history), the following might be useful: Recommended .git/config settings before starting the mirror: [repack] UseDeltaBaseOffset = true [svn] noMetadata = true [pack] compression = 9 And then in the importscript: git svn fetch git svn fetch -t cp .git/remotes/* .git/heads # depending on where the SVN branches cp .git/remotes/origin/* .git/heads# end up cp .git/remotes/trunk .git/heads/master -- Sincerely, [EMAIL PROTECTED] Stephen R. van den Berg.
Re: Official GCC git repository
On Fri, Mar 14, 2008 at 1:44 PM, Stephen R. van den Berg <[EMAIL PROTECTED]> wrote: > > [svn] >noMetadata = true This will prevent users from using the GCC git repository to bootstrap their own local git-svn-aware repositories. We definitely don't want to do this. Ollie
Re: [RFC] GCC caret diagnostics
On Fri, Mar 7, 2008 at 10:54 AM, Tom Tromey <[EMAIL PROTECTED]> wrote: > > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes: > > Manuel> Here is a patch that give us caret diagnostics in C/C++. > > Nice. > > Manuel> The third approach would be to store an offset and when > Manuel> generating diagnostics, reopen the file, fseek to the offset > Manuel> and print that line. > > I tend to favor this, provided that the performance is not too awful. > But maybe this is painful due to iconv translation? > > Ian suggested that we delete this information after the FE is > finished. This makes sense, I think, from a memory-saving > perspective. But, that means we will get different kinds of error > output depending on when a diagnostic is emitted, which I think is > pretty unfriendly -- it exposes implementation details of gcc to the > user. > > So, the reason I favor trying the reopen-and-seek approach is that it > would let us keep this information around and be consistent in what we > print. > > What do you think of that? It sounds a better plan to me -- it works well in practice was evidenced by unnamed compilers featuring diagnostics with caret.
Re: [RFC] GCC caret diagnostics
On Fri, Mar 7, 2008 at 11:53 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: > On Fri, Mar 7, 2008 at 4:54 PM, Tom Tromey <[EMAIL PROTECTED]> wrote: > > > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes: > > > > Manuel> Here is a patch that give us caret diagnostics in C/C++. > > > > Nice. > > > > Manuel> The third approach would be to store an offset and when > > Manuel> generating diagnostics, reopen the file, fseek to the offset > > Manuel> and print that line. > > > > I tend to favor this, provided that the performance is not too awful. > > But maybe this is painful due to iconv translation? > > > > Ian suggested that we delete this information after the FE is > > finished. This makes sense, I think, from a memory-saving > > perspective. But, that means we will get different kinds of error > > output depending on when a diagnostic is emitted, which I think is > > pretty unfriendly -- it exposes implementation details of gcc to the > > user. > > > > So, the reason I favor trying the reopen-and-seek approach is that it > > would let us keep this information around and be consistent in what we > > print. > > > > What do you think of that? > > I think we support input from stdin, at least qemu used to work that way ;) > > If you want to improve the memory situation maybe storing the input > in compressed format in memory is ok. (Or compressing the cpp token > stream if we want to support diagnostics on the preprocessed output, > which I'd love to have in some cases) I would not feel bad if we don't provide caret diagnostics for `input from stdin'. `stdin' is already specially weird anyway :-)
Re: [RFC] GCC caret diagnostics
On Fri, Mar 7, 2008 at 9:06 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Tom Tromey <[EMAIL PROTECTED]> writes: > > > Ian suggested that we delete this information after the FE is > > finished. This makes sense, I think, from a memory-saving > > perspective. But, that means we will get different kinds of error > > output depending on when a diagnostic is emitted, which I think is > > pretty unfriendly -- it exposes implementation details of gcc to the > > user. > > I think that is mostly OK in practice because most diagnostics are > issued by the front end. But I admit that some come from the > middle-end, so there would be an inconsistency. There are a number of people (including me) who believe that diagnostics from the middle end are oddities. Not everybody is of that opinion, but I would argue that we should not encourage diagnostics from the middle end.
Re: [RFC] GCC caret diagnostics
On 08 Mar 2008 15:39:20 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > >Another approach would be to only use the carets for parse errors, > >which is where they are the most helpful. > > And preprocessor if possible Yes, definitely.
Re: [RFC] GCC caret diagnostics
On Wed, Mar 12, 2008 at 7:00 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > On 07/03/2008, Tom Tromey <[EMAIL PROTECTED]> wrote: > > > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes: > > > Manuel> The third approach would be to store an offset and when > > Manuel> generating diagnostics, reopen the file, fseek to the offset > > Manuel> and print that line. > > > > I tend to favor this, provided that the performance is not too awful. > > But maybe this is painful due to iconv translation? > > How should a file be properly opened within GCC? I find the code in > libcpp/files.c pretty confusing and also I am not interested in > parsing the file, so some of the conversions it makes are probably > superflous (or perhaps even impossible when calling from > expand_location). > > > > How about -fshow-caret instead of -fdiagnostics-show-caret? > > (By analogy with -fshow-column.) > > Well, we have -fdiagnostics-show-option and > -fdiagnostics-show-location. So 2 versus 1. ;-) That said, I would > also prefer -fshow-option and -fshow-location. This was done long time ago to reserve a `diagnostic' namespace in the maze of -f options. I would suggest we continue that for consistency.
Re: [RFC] GCC caret diagnostics
On Wed, Mar 12, 2008 at 11:00 PM, Chris Lattner <[EMAIL PROTECTED]> wrote: > > > On Mar 12, 2008, at 5:07 PM, Manuel López-Ibáñez wrote: > > > On 08/03/2008, Chris Lattner <[EMAIL PROTECTED]> wrote: > >> > >> clang points into the original input buffer that was lexed from. > >> This > >> requires keeping the original files mapped into the address space of > >> the compiler. However, clang only produces diagnostics from the > >> front- > >> end, not from the middle-end. > > > > So no warnings for uninitialized variables? > > The clang front-end generates these warnings. This means that the set > of warnings produced by the compiler doesn't change as the optimizer > evolves, are generally less mystifying to the user, and have perfect > location info as a side effect. People who use -Werror tend to prefer > when they don't get new random warnings due to a compiler upgrade. > This approach is similar to what Java compilers do and frontends like > EDG do (afaik). I strongly support this point of view, and I would like to encourage fellow GCC developers to give it considerations. I know Mark Mittchell had spoken in favour of it in the past. > > The Clang project is also growing a static analysis engine which is > very adept at solving path sensitive versions of these problems, which > is useful for finding deeper bugs. This is a debate we would like to have in a different thread :-)
gcc-4.4-20080314 is now available
Snapshot gcc-4.4-20080314 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080314/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 133226 You'll find: gcc-4.4-20080314.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080314.tar.bz2 C front end and core compiler gcc-ada-4.4-20080314.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080314.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080314.tar.bz2 C++ front end and runtime gcc-java-4.4-20080314.tar.bz2 Java front end and runtime gcc-objc-4.4-20080314.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080314.tar.bz2The GCC testsuite Diffs from 4.4-20080307 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: gcc-4.1-20080303 is now available
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?
Re: gcc-4.1-20080303 is now available
"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. Ian
GCC 4.3.1 Status Report (2008-03-15)
Status == The GCC 4.3 branch is open for commits under normal release branch rules. GCC 4.3.1 is due no later than 2008-05-05, but if a workaround for the x86 direction flag issue is agreed and committed soon then 4.3.1-rc1 may come around a week after such a workaround is committed to the branch, with the release following about a week later subject to no problems requiring 4.3.1-rc2 to be built. Quality Data Priority # Change from Last Report --- --- P10 +- 0 P2 84 - 7 P3 25 + 17 --- --- Total 109 + 10 Previous Report === http://gcc.gnu.org/ml/gcc/2008-03/msg00371.html Previous report with statistics: http://gcc.gnu.org/ml/gcc/2008-03/msg00157.html -- Joseph S. Myers [EMAIL PROTECTED]
Re: gcc-4.1-20080303 is now available
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? Wow. I just counted. The snapshot has 85 PR's fixed in the core compiler, and 24 in the C++ front end, since 4.1.2. "Amazingly active" is right. I think that an official release should be put out containing those fixes; they've gotten lots of testing since 4.1-based distros are using those fixes, if I understand correctly. Not even sure that we should close the branch if there's that much fixing going on.
Re: gcc-4.1-20080303 is now available
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.
GCC 4.2.4 Status Report (2008-03-15)
Status == The GCC 4.2 branch is open for commits under normal release branch rules. All fixes going on that branch should first have gone on trunk and 4.3 branch. GCC 4.2.4 is due around 2008-04-02, so 4.2.4-rc1 should be built by one of the release managers around 2008-03-26. Any further 4.2 releases after 4.2.4 may depend on whether there is expressed user and developer interest in further releases from this branch, or whether 4.3 has been widely adopted in place of 4.2. Quality Data Priority # Change from Last Report --- --- P1 23 - 7 P2 126 + 10 P3 48 + 23 --- --- Total 197 + 26 Previous Report === http://gcc.gnu.org/ml/gcc/2008-02/msg00015.html Previous report with statistics: http://gcc.gnu.org/ml/gcc/2008-01/msg00332.html -- Joseph S. Myers [EMAIL PROTECTED]
Re: Official GCC git repository
On Thu, 13 Mar 2008, David Woodhouse wrote: I could never understand why anyone would use anything but CVS (if that works for them), or git. The VCS-du-jour craze just confuses me. Version control is complicated, much more so than it first appears. There's a very large design space. Knowing that, it's not surprising that there are so many different VCS systems, embodying lots of different approaches. Nick
successful build
Hi list, the 4.3.0 version compiled and installed without promblems, using msys under WindowsXP SP2. Thanks to the GCC team! $ gcc -v Using built-in specs. Target: mingw32 Configured with: ../gcc-4.3.0/configure --with-gcc --build=mingw32 --prefix=/mingw --with-mpfd=/usrlocal --with-gmp=/usrlocal --disable-werror --disable-nls --enable-checking=release Thread model: win32 gcc version 4.3.0 (GCC) $ uname -a MSYS_NT-5.1 CHRISTIANHOME 1.0.11(0.46/3/2) 2007-07-29 17:16 i686 Msys
Re: gcc-4.1-20080303 is now available
On Fri, Mar 14, 2008 at 7:31 PM, 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. I forgot about that, and got reminded only after reading Gerald's message on [EMAIL PROTECTED] -- Gaby
Re: gcc-4.1-20080303 is now available
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... ? --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
