Re: A couple more subversion notes
Daniel Berlin <[EMAIL PROTECTED]> writes: | On Fri, 2005-10-21 at 02:19 +0200, Lars Gullik Bjønnes wrote: | > Bernd Schmidt <[EMAIL PROTECTED]> writes: | > | > | Lars Gullik Bjønnes wrote: | > | > It seems that svn is unable to send all its requests to the svn | > | > repo over one ssh connection. In one test I just did I had to enter | > | > the ssh password five times. | > | | > | man ssh-agent | > | > The connection is still set up five times with ssh-agent... it is just | > hidden from view. | > | We've been through this, actually. | We only use svn+ssh because that is what the current sourceware auth | infrastructure is, and svn is a plaintext transport. mmm... so when using plain svn: then thre is only one connection? or is five connections made then too? note that my observation was just an answer to the question: "why does svn+ssh have to pay the connection setup price when cvs+ssh (seemingly) doesn't" -- Lgb
Re: RFC: future gfortran development and subversion
Paul Thomas wrote: >>>I spent nearly 5 hours yesterday reading the svn FAQ, mailing list >>>archives, and the docs. I never came across this solution. >>> >>> > > Could somebody please distill the wisdom from this thread onto the > Wiki? I can understand why Steve might send 5 hours on it. It's bad > that one person winds up doing it and unforgivable if everybody does. > > How about adding to the list of common things that an aspiring > contributor might want to do? I've already added this to the section on svn switch in the wiki. - Tobi
Re: Compilation of Ada under FreeBSD
Selon "Joel Sherrill <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]>: > Frédéric PRACA wrote: > > Hello, > > I'm trying to build a cross-compiler for RTEMS. Building C or C++ > cross-compiler > > is not a problem but building the Ada compiler does'nt work. In fact, even > > building a normal compiler does'nt work at all. The main reason I found is > that > > the gcc driver of FreeBSD doesn't support ada and it seems that GNAT is not > > sufficient. How can I do ? > > I didn't noticed the domain name. :) Well, I was just a documentation translator. > I assume you would be more interested in bootstrapping your way to a > ports package of some recent gnat. The native gnat version and cross > gnat version need to be the same. Well building a GNATGcc will be a first step, I'll try to initiate a port later when I'll understand everything I have to do ;-) Thanks Joe Fred
Re: A couple more subversion notes
On 2005-10-21 09:29:24 +0200, Lars Gullik Bjønnes wrote:
> mmm... so when using plain svn: then thre is only one connection? or
> is five connections made then too?
5 connections too, but each connection should be much faster
(almost immediate). The number of connections does not depend
on the method ("svn", "svn+ssh", "http" or whatever).
> note that my observation was just an answer to the question: "why
> does svn+ssh have to pay the connection setup price when cvs+ssh
> (seemingly) doesn't"
Subversion assumes that a connection is cheap (though in practice,
this is not always true), so can make several ones (5 for some
commands). The recommended solution for ssh is to use some tools
like fsh to do only one authentication.
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web:
Re: A couple more subversion notes
Lars Gullik Bjønnes writes: > Bernd Schmidt <[EMAIL PROTECTED]> writes: > > | Lars Gullik Bjønnes wrote: > | > It seems that svn is unable to send all its requests to the svn > | > repo over one ssh connection. In one test I just did I had to enter > | > the ssh password five times. > | > | man ssh-agent > > The connection is still set up five times with ssh-agent... it is just > hidden from view. It is, but the issue doesn't arise if you use SSH connection caching. Well, it does arise in the sense that multiple connections are made, but they are simple TCP connections with little overhead. Were there no caching I would be strongly opposed to using Subversion but with it I have no objection at all. Andrew
Re: A couple more subversion notes
For example a cron job could simply grab a diff of
everything since the last time it ran and then apply it to the CVS
repository. The only even slightly tricky part would be getting the
cvs add and rm commands right. We could run that script an hour.
Anybody who needs more cutting edge sources can switch to SVN.
I don't promise anything on the timing, but I can do this. I already
have a very similar arch-to-cvs script which I attach.
Paolo
#!/bin/sh
: ${EDITOR:=`which vi`}
if which baz > /dev/null 2>&1; then
: ${TLA:=`which baz`}
else
: ${TLA:=`which tla`}
fi
# Some tools get completely confused in stupid ways by non-default
# settings of LANG (like gawk, which fucks up regexp character ranges).
LANG=C; export LANG
TMP_PFX="/tmp/tla-to-cvs.$$"
if test "$1" == --debug; then
shift
else
trap "rm -rf $TMP_PFX" 0 1 2 3 11 15
fi
if test "$#" -ne 2; then
echo "Usage: tla-to-cvs ARCH-DIR CVS-DIR" >&2
exit 1
fi
mkdir $TMP_PFX
PWD=`pwd`
TREE_ROOT=`cd $1 && $TLA tree-root 2>/dev/null || echo NONE`
CVS_ROOT=`cd $2 && pwd || echo NONE`
if test $TREE_ROOT = NONE; then
echo "$TREE_ROOT: Not an arch working directory" >&2
exit 1
fi
if test $CVS_ROOT != NONE && test -d $CVS_ROOT/CVS; then :; else
echo "$CVS_ROOT: Not a CVS working directory" >&2
exit 1
fi
if (cd $2 && cvs update > $TMP_PFX/cvs_update_log 2>&1); then :; else
cat $TMP_PFX/cvs_update_log >&2
echo "$CVS_ROOT: problems updating from CVS" >&2
exit 1
fi
if grep ^C $TMP_PFX/cvs_update_log >&2; then
echo "$CVS_ROOT: conflicts updating from CVS" >&2
exit 1
fi
# Get the list of files in the repository
cd $TREE_ROOT
$TLA inventory -s | sort > $TMP_PFX/arch-file-list
cd $PWD
cd $CVS_ROOT
find . ! -type d | sed -e '/\/CVS\//d' -e 's,^\./,,' | sort >
$TMP_PFX/cvs-file-list
cd $PWD
# Find the added, removed, changed files
comm -13 $TMP_PFX/cvs-file-list $TMP_PFX/arch-file-list | fgrep -v
.arch-inventory > $TMP_PFX/added-file-list
comm -23 $TMP_PFX/cvs-file-list $TMP_PFX/arch-file-list | fgrep -v .cvsignore >
$TMP_PFX/removed-file-list
comm -12 $TMP_PFX/cvs-file-list $TMP_PFX/arch-file-list >
$TMP_PFX/common-file-list
: > $TMP_PFX/changed-file-list
for i in `cat $TMP_PFX/common-file-list`; do
if cmp $TREE_ROOT/$i $CVS_ROOT/$i >/dev/null 2>&1; then :; else
echo "$i" > $TMP_PFX/changed-file-list
fi
done
test -s $TMP_PFX/added-file-list || \
test -s $TMP_PFX/changed-file-list || test -s $TMP_PFX/removed-file-list || \
{
echo $0: CVS repository is up-to-date
exit 0
}
# Make a changelog and edit it
echo update from arch > $TMP_PFX/log_msg
echo >> $TMP_PFX/log_msg
for i in `grep -h ChangeLog $TMP_PFX/added-file-list
$TMP_PFX/changed-file-list`; do
dir=`dirname $i`
if [ -f $CVS_ROOT/$dir/ChangeLog ]; then
cvs_log=$CVS_ROOT/$dir/ChangeLog
else
cvs_log=/dev/null
fi
# This script tries to find everything that was added to the ChangeLogs
# by looking at the diff. The lines in the first hunk are kept, up to the
# first bunch of added lines (included).
diff -u $cvs_log $TREE_ROOT/$dir/ChangeLog | sed \
-e '1,/^@@/c\' -e "$dir:" \
-e '/^+/,$ {' \
-e 's/^+//' \
-e 't' \
-e 's/.*//' \
-e 'q' \
-e '}' \
-e '/^-/d' \
-e 's/^.//' | sed -e '/^\.:/d' >> $TMP_PFX/log_msg
done
$EDITOR $TMP_PFX/log_msg
# Move the changes to the CVS repository
for i in `cat $TMP_PFX/added-file-list`; do
echo "A $i" >&2
cp $TREE_ROOT/$i $CVS_ROOT/$i
done
for i in `cat $TMP_PFX/changed-file-list`; do
echo "M $i" >&2
cp $TREE_ROOT/$i $CVS_ROOT/$i
done
for i in `cat $TMP_PFX/removed-file-list`; do
echo "R $i" >&2
rm $CVS_ROOT/$i
done
# Check them in
cd $CVS_ROOT
if test -s $TMP_PFX/added-file-list; then
echo "* adding files to CVS" >&2
xargs cvs add < $TMP_PFX/added-file-list
fi
if test -s $TMP_PFX/removed-file-list; then
echo "* removing files from CVS" >&2
xargs cvs remove < $TMP_PFX/removed-file-list
fi
echo "* checking in changes to CVS" >&2
cvs ci -F $TMP_PFX/log_msg
Re: A couple more subversion notes
On 19 Oct 2005, Giovanni Bajo yowled: > Andreas Schwab <[EMAIL PROTECTED]> wrote: > >>> If I remove the socket file, it just does a normal connection. >> >> It doesn't for me. >> >> $ ssh gcc.gnu.org >> Couldn't connect to /var/tmp/schwab/ssh_%h: No such file or directory > > Ah, maybe it's a later fix? I'm using: > > $ ssh -V > OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005 A typical case of `horrid bug fixed by a merge the day after the release': , | 20050525 | [...] |- [EMAIL PROTECTED] 2005/04/26 13:08:37 | [ssh.c ssh_config.5] | fallback gracefully if client cannot connect to ControlPath. ok djm@ | [...] | 20050524 | [...] | - Release 4.1p1 ` 4.2p1 has the fix (as does 4.1, but I doubt that's much use unless you're running OpenBSD). -- `"Gun-wielding recluse gunned down by local police" isn't the epitaph I want. I am hoping for "Witnesses reported the sound up to two hundred kilometers away" or "Last body part finally located".' --- James Nicoll
Is the test svn repository working fine?
Hi, I'm having troubles with non-anonymous check outs: paolo:~/test-svn> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk Permission denied (publickey,gssapi-with-mic). svn: Connection closed unexpectedly I have svn1.2.3 and the latest openssh, of course cvs works fine for me. Any hint? Thanks in advance, Paolo.
Re: A couple more subversion notes
On Thu, 20 Oct 2005, Daniel Berlin wrote: > 1.4 should have svn and SSL support, in a way that will allow us to not > have to pay the ssl handshake peanlty except during things requiring > auth. When this comes along, we will move to it, which will probably > require some sort of underlying authentication change (I doubt we want > to give everyone real passwords in the passwd file). Luckily there is > already support for external password databases in svnserve. If using SSL, I think SSL client certificates would be the best way to authenticate. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: Is the test svn repository working fine?
Paolo Carlini wrote: >... of course cvs works fine for me. > > This is not really relevant, however, because uses ssh1... Sorry. Paolo.
Re: Is the test svn repository working fine?
Paolo Carlini wrote: >I'm having troubles with non-anonymous check outs: > > By now I'm pretty sure that it's not (completely, at least) my fault, because I tested my svn+ssh setup with 3-4 servers around the world and all asked a password, as expected. Paolo.
Re: RFC: future gfortran development and subversion
On Fri, 2005-10-21 at 06:56 +0200, Paul Thomas wrote: > Dear All, > > >>I spent nearly 5 hours yesterday reading the svn FAQ, mailing list > >>archives, and the docs. I never came across this solution. > >> > >> > Could somebody please distill the wisdom from this thread onto the > Wiki? I can understand why Steve might send 5 hours on it. It's bad > that one person winds up doing it and unforgivable if everybody does. > > How about adding to the list of common things that an aspiring > contributor might want to do? I'm about to send an email with my plans, which include organizing the wiki docs. :) > > Paul T >
Marking conditional blocks
Hi, I want to demarcate conditional statments similar to how NOTE's are use to make loop starts and ends. For example, an if statement would be marked before the if statement, before both the then and else branches and then finally at the end of the block. So can some body suggest as to where I can do this ? Doing it with the control flow graph seems not very successfull. Would doing it with the grammer rules be the easiest ? I would appreciate ideas, opinions ... regards Shrey
Re: Is the test svn repository working fine?
Paolo Carlini <[EMAIL PROTECTED]> writes: > By now I'm pretty sure that it's not (completely, at least) my fault, > because I tested my svn+ssh setup with 3-4 servers around the world and > all asked a password, as expected. This is configurable in the ssh server. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Vector et emergo: On the vectorization of the HIRLAM Weather Prediction code.
L.S., At the last GCC summit I showed that complete compilation of the HIRLAM Numerical Weather Prediction suite by gfortran/gcc was near completion - only a few compiler bugs were between us and running programs. This (autumn) holiday, I was able to convince myself that the problems on the part of gfortran/gcc were confined to gfortran not knowing the LOC (extension) intrinsic, which will be part of LLNL's "Cray" pointers package, and an "unclassifiable statement" when trying to parse a five part concatenation of substrings (for which I'll file a bug report shortly). All other problems are due to HIRLAM people not following standards closely enough, which I will remedy effectively ;-) Therefore, the next challenge presented itself: Given that the HIRLAM code always has performed well on vector machines (as of '85), it's a natural to compile it with -ftree-vectorize -ftree-vectorizer-verbose=n compiler options, to see what the vectorizer can make of it. Here are the top level results: Loops considered by the vectorizer as potentially vectorizable: 10420. Loops actually vectorized: 2645. Loops not vectorized:7775. of which: - unhandled data-ref: 3479. - complicated access pattern: 1500. - can't determine dependence: 1456. - unsupported use in stmt: 662. - no vectype for type (complex8): 235. - relevant stmt not supported: 120. - mixed data-types:149. I'll send examples of the top three of this list, plus the ultimate example why 235 occurrences of "no vectype for type (complex8)" is an unnessary thing. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM 1: This dependence is determinable.
L.S., This code: SUBROUTINE S(N, M) DIMENSION A(N, M), B(N, M) READ*,A,B DO J = 1, M DO I = 1, N A(I, J) = A(I, J) + B(I, J) ENDDO ENDDO PRINT*,A END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect1.f draws the following "not vectorized" message: vect1.f:5: note: not vectorized: can't determine dependence between (*a_23)[D.951_86] and (*a_23)[D.951_86] vect1.f:5: note: vectorized 0 loops in function. That's pretty silly, of course :-) Source and destination A(I,J) overlap exactly, so vectorization of this loop is certainly possible. The equivalent rank-1 example is vectorized without problems. Exempting this one special case from "can't determine dependence" will mean about 1000 more vectorized loops in HIRLAM. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: A couple more subversion notes
On Fri, 2005-10-21 at 09:29 +0200, Lars Gullik Bjønnes wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > | On Fri, 2005-10-21 at 02:19 +0200, Lars Gullik Bjønnes wrote: > | > Bernd Schmidt <[EMAIL PROTECTED]> writes: > | > > | > | Lars Gullik Bjønnes wrote: > | > | > It seems that svn is unable to send all its requests to the svn > | > | > repo over one ssh connection. In one test I just did I had to enter > | > | > the ssh password five times. > | > | > | > | man ssh-agent > | > > | > The connection is still set up five times with ssh-agent... it is just > | > hidden from view. > | > > | We've been through this, actually. > | We only use svn+ssh because that is what the current sourceware auth > | infrastructure is, and svn is a plaintext transport. > > mmm... so when using plain svn: then thre is only one connection? or > is five connections made then too? No, still 5 But it's ssh handshaking that takes a while, establishing tcp connections is quite quick (or else your web browser would take 8 years to load a page with 50 images :P)
Re: Marking conditional blocks
On Oct 21, 2005 02:55 PM, shreyas krishnan <[EMAIL PROTECTED]> wrote: > Hi, > I want to demarcate conditional statments similar to how NOTE's > are use to make loop starts and ends. The fact that we use NOTEs for loops is considered a mis-feature. May I suggest you browse gcc-patches archives for the structure analysis / region formation patches of which previews were posted recently? Gr. Steven
Vectorizing HIRLAM 2: One out of the "unhandled data-ref" garbage bin :-)
L.S., This code: SUBROUTINE S(A, B, N) DIMENSION A(N), B(N) READ*,Z,B DO I = 1, N A(I) = Z * B(I) ENDDO PRINT*,A END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect2.f draws the following "not vectorized" message: vect2.f:4: note: not vectorized: unhandled data-ref vect2.f:4: note: vectorized 0 loops in function. Hmmm, how about broadcasting Z to a vector register and using that in a vectorized version of this loop :-) ? Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 1: This dependence is determinable.
On Oct 21, 2005 03:12 PM, Toon Moene <[EMAIL PROTECTED]> wrote: > L.S., Toon S., welcome back :-) May I suggest you try the autovect-branch too, a lot of vectorizer enhancements are still pending there... Gr. Steven
Re: Vectorizing HIRLAM 2: One out of the "unhandled data-ref" garbage bin :-)
On Oct 21, 2005, at 9:19 AM, Toon Moene wrote: L.S., This code: SUBROUTINE S(A, B, N) DIMENSION A(N), B(N) READ*,Z,B DO I = 1, N A(I) = Z * B(I) ENDDO PRINT*,A END when compiled thusly: The problem here is not really related to the vectorizer but the tree aliasing code. The loop looks like this at -O2 in the tree dumps: # z_49 = PHI ; # i_1 = PHI <1(1), i_48(3)>; :; D.982_41 = i_1 + -1; # VUSE ; D.983_43 = (*b_20)[D.982_41]; # VUSE ; z.4_45 = z; D.985_46 = D.983_43 * z.4_45; # z_124 = V_MAY_DEF ; (*a_36)[D.982_41] = D.985_46; i_48 = i_1 + 1; if (i_1 == D.972_25) goto ; else goto ; Notice how the statement which does "A(I) =" has a V_MAY_DEF of z. If we recorded it correctly, A and B would aliasing nothing as they are arguments passed in. -- Pinski
Vectorizing HIRLAM 3: Can't vectorize DOUBLE COMPLEX loops ...
L.S., The following code: SUBROUTINE S(N) DOUBLE COMPLEX A(N), B(N) READ*,B DO I = 1, N A(I) = B(I) ENDDO PRINT*,A END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect3.f draws the following "not vectorized" message: vect3.f:4: note: not vectorized: no vectype for stmt: D.929_51 = (*b_8)[D.928_48] scalar_type: complex8 vect3.f:4: note: vectorized 0 loops in function. Which begs the question: Why not vectorizing *after* complex computation has been lowered to the equivalent floating point computation ? HIRLAM contains relatively few complex computation - however, a sizable number of physics problems are more easily expressed using (DOUBLE) COMPLEX quantities. It seems they are on the short end of the rope as far as vectorization is concerned. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM 4: complicated access patterns examined.
L.S., This code: SUBROUTINE S(N) DIMENSION A(N), B(N) READ*,ISTART,ISTOP,B DO I = ISTART, ISTOP A(I) = B(I) ENDDO PRINT*,A END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f draws the following "not vectorized" message: vect4.f:4: note: not vectorized: complicated access pattern. vect4.f:4: note: vectorized 0 loops in function. This sort of coding is rather prevalent in HIRLAM, especially in the interesting inner loops. One needs this when not all of the inner area is accessible / computable by the code at hand (for instance because there are inaccessible "halo's" around the subarea that have to be treated specially). The funny thing is that replacing ISTART with a constant makes this loop vectorizable. So what's the fundamental difference (as far as vectorizing is concerned) between a constant and a loop invariant :-) ? Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Vectorizing HIRLAM 5: Another one out of the "unhandled data-ref" grab bag.
L.S., This code: SUBROUTINE S(N) DIMENSION A(N), B(12) COMMON /COM/ B DO I = 1, 12 A(I) = B(I) ENDDO PRINT*,A(1:12) END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect5.f draws the dreaded "unhandled data-ref" message: vect5.f:4: note: not vectorized: unhandled data-ref vect5.f:4: note: vectorized 0 loops in function. Hmmm, this is rather common (pun intended) in old Fortran code. Why is this style "punished" by not being vectorizable ;-) ? Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Is the test svn repository working fine?
Andreas Schwab wrote: >>By now I'm pretty sure that it's not (completely, at least) my fault, >>because I tested my svn+ssh setup with 3-4 servers around the world and >>all asked a password, as expected. >> >> >This is configurable in the ssh server. > > Ok. I tried using my old-good ssh1 (which I'm usually using for gcc's cvs), setting SVN_SSH, as suggested privately by Daniel. Now what happens is that I'm indeed requested a password, exactly as happens for cvs, but for some reason the usual password which I'm using together with cvs is not ok, keeps asking: paolo:~/test-svn> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk Enter passphrase for RSA key '[EMAIL PROTECTED]': Enter passphrase for RSA key '[EMAIL PROTECTED]': ... ... Of course, I would rather prefer using the new openssh4.2p1: if I configure it to use Protocol 1, same behavior... Paolo.
Vectorizing HIRLAM 6: Honoring Fortran's Alias Requirements - might be a bug.
L.S., This code: SUBROUTINE S(N) INTEGER N COMMON /COM/ A(100) REAL A REAL B(N), C(N), D(N) DO I = 1, N B(I) = D(I) ENDDO DO I = 1, N A(I) = B(I) ENDDO CALL S1(C(1)) END when compiled thusly: $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f draws the following "not vectorized" message: vecta.f:6: note: LOOP VECTORIZED. vecta.f:9: note: not vectorized: can't determine dependence between (*b_15)[D.928_29] and com.a[D.928_29] vecta.f:9: note: vectorized 1 loops in function. This cannot be right. According to the Fortran Standards that have been, that are, and that will be, A (which resides in common) and B (which is a local array) cannot have *any* storage in common. They're disjoint - they won't unite no matter what. So where does the compiler lose this valuable information ? This is a hunt for the more advance vector-sorcerer. Note that removing the (1) from the CALL in the last-but-one line makes the compiler recall the ever important Fortran alias rules. [ Sprinkle the above with :-) liberally ] Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Grabbing Gomp (was: Is gcc optimized for thread level parallelism?)
Jim Wilson wrote: No, but we are working on OpenMP support, which is somewhat related. This isn't automatic parallelization; it requires programmer instrumentation via pragmas. This is probably more directed at multiprocessor machines than threads, but it is a start in the right direction. See http://gcc.gnu.org/projects/gomp/ This is still in early stages of implementation. Don't expect anything to work yet. Where is the gomp branch in terms of the SVN transition? Should I still grab it via CVS, or is it in the new SVN repository? Congratulations the Gomp tema on their progress. I've been detained elsewhere by a variety of issues, and unable to follow Gomp since earlier this year, but I hope to get back into it when time permits in a few weeks. -- Scott Robert Ladd <[EMAIL PROTECTED]> Coyote Gulch Productions http://www.coyotegulch.com
Subversion access via http proxy
Hi, I used to be able to access the svn.toolchain.org test repository through our http proxy (the firewall will not permit svn or even svn+ssh directly). That repository had a published username and password for anonymous access. The instructions are still in the wiki, although you have to go back a few versions now. Is there any equivalent for the new gcc.gnu.org repository? I tried anoncvs and anonsvn, among others. If so could somebody put it on the wiki. Thanks. Andrew Stubbs P.S. The wiki page seems to have got a little confused. It used to have three different examples of how to check out, but now has three very similar examples (some broken). Now that there is a read only non-secure service set up the changes to these examples can probably be largely reverted.
Re: Vectorizing HIRLAM 6: Honoring Fortran's Alias Requirements - might be a bug.
On Friday 21 October 2005 09:51, Toon Moene wrote: > So where does the compiler lose this valuable information ? > Toon, could you open PRs for these problems? Some of the failures you see look like aliasing problems. It'd be nice to have them in bugzilla, even if they end up being dups of existing reports. Thanks.
Re: Is the test svn repository working fine?
Paolo Carlini wrote: >I tried using my old-good ssh1 (which I'm usually using for gcc's cvs), >setting SVN_SSH, as suggested privately by Daniel. Now what happens is >that I'm indeed requested a password, exactly as happens for cvs, but >for some reason the usual password which I'm using together with cvs is >not ok, keeps asking: > >paolo:~/test-svn> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk >Enter passphrase for RSA key '[EMAIL PROTECTED]': >Enter passphrase for RSA key '[EMAIL PROTECTED]': > > This is *totally* crazy: if I enter the password *3* times, then it works! If someone is curious and wants more debug info to figure out how this could even be possible, just let me know... Paolo.
RE: How do I disable classes of test?
Daniel Towner wrote: > Hi Dave, > > Thanks for that patch. It has taken me a while to get around to using > it, but it is very useful. I've attached a version which works with the > current mainline. > > Was there any particular reason why you haven't submitted it to > mainline, as I'm sure that others could benefit from it? > > dan. None in particular, except that I'm not currently running with 4.x series! cheers, DaveK -- Can't think of a witty .sigline today
Re: Is the test svn repository working fine?
> >paolo:~/test-svn> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk > >Enter passphrase for RSA key '[EMAIL PROTECTED]': > >Enter passphrase for RSA key '[EMAIL PROTECTED]': > > This is *totally* crazy: if I enter the password *3* times, then it works! > > If someone is curious and wants more debug info to figure out how this > could even be possible, just let me know... See previous threads about how svn makes multiple connections to the server, each requiring authorization. Paul
Re: Is the test svn repository working fine?
Paul Brook wrote: >See previous threads about how svn makes multiple connections to the server, >each requiring authorization. > > Argh! I glanced briefly over those threads... While you are at it, are you willing to summarize the solution for this annoyance and/or point me to the relevant subthread? Thanks, Paolo.
Re: Is the test svn repository working fine?
Paul Brook wrote: >>>paolo:~/test-svn> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk >>>Enter passphrase for RSA key '[EMAIL PROTECTED]': >>>Enter passphrase for RSA key '[EMAIL PROTECTED]': >>> >>> >>This is *totally* crazy: if I enter the password *3* times, then it works! >> >>If someone is curious and wants more debug info to figure out how this >>could even be possible, just let me know... >> >> >See previous threads about how svn makes multiple connections to the server, >each requiring authorization. > > I guess it is the SSH connection caching thing?!? I tought it was for performance not also for finger saving... ;) Paolo.
Re: Is the test svn repository working fine?
On Friday 21 October 2005 15:59, Paolo Carlini wrote: > Paul Brook wrote: > >See previous threads about how svn makes multiple connections to the > > server, each requiring authorization. > > Argh! I glanced briefly over those threads... > > While you are at it, are you willing to summarize the solution for this > annoyance and/or point me to the relevant subthread? Use ssh-agent(1) and/or ssh connection caching http://gcc.gnu.org/wiki/SSH%20connection%20caching Paul
Re: Is the test svn repository working fine?
On 10/21/05, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Paul Brook wrote: > > >See previous threads about how svn makes multiple connections to the server, > >each requiring authorization. > > > > > Argh! I glanced briefly over those threads... > > While you are at it, are you willing to summarize the solution for this > annoyance and/or point me to the relevant subthread? Make use of ssh-agent. Richard.
Re: Is the test svn repository working fine?
Paolo Carlini <[EMAIL PROTECTED]> wrote: >> See previous threads about how svn makes multiple connections to the >> server, each requiring authorization. >> >> > Argh! I glanced briefly over those threads... > > While you are at it, are you willing to summarize the solution for this > annoyance and/or point me to the relevant subthread? http://gcc.gnu.org/wiki/SSH%20connection%20caching -- Giovanni Bajo
stack memory
Hi,
With the sun compiler, the declared buffer is pushed onto the stack upon
entry into function foo and not only when it goes into scope.
Do you know if gcc will use the stack for the buffer if it never goes into
scope?
function foo()
{
if ( debug > 0 )
{
char debug_buffer[4096];
}
}
Thanks,
Ivan
Re: Is the test svn repository working fine?
Giovanni Bajo wrote: >>While you are at it, are you willing to summarize the solution for this >>annoyance and/or point me to the relevant subthread? >> >> >http://gcc.gnu.org/wiki/SSH%20connection%20caching > > Ok. The only problem is that, for some reason, I can use only Protocol 1, not Protocol 2. Anyone knows why? Maybe I have to send to the overseers a new public key? Thanks for the feedback, Paolo.
Re: Is the test svn repository working fine?
> >See previous threads about how svn makes multiple connections to the > > server, each requiring authorization. > > I guess it is the SSH connection caching thing?!? I tought it was for > performance not also for finger saving... ;) I think it's configurable via the ControlMaster option. The default is to allow secondary connections without asking for a password. Paul
Re: Is the test svn repository working fine?
Paolo Carlini <[EMAIL PROTECTED]> wrote: >>> While you are at it, are you willing to summarize the solution for this >>> annoyance and/or point me to the relevant subthread? >>> >>> >> http://gcc.gnu.org/wiki/SSH%20connection%20caching >> >> > Ok. The only problem is that, for some reason, I can use only Protocol > 1, not Protocol 2. > > Anyone knows why? > > Maybe I have to send to the overseers a new public key? Probably. I can never remember which is which, so I always provide both the keys (generated with "-tdsa" and "-trsa" option of ssh-keygen). BTW: I just simplified that Wiki page a little. -- Giovanni Bajo
Re: Is the test svn repository working fine?
Giovanni Bajo wrote: >>Ok. The only problem is that, for some reason, I can use only Protocol >>1, not Protocol 2. >> >>Anyone knows why? >> >>Maybe I have to send to the overseers a new public key? >> >> >Probably. I can never remember which is which, so I always provide both the >keys (generated with "-tdsa" and "-trsa" option of ssh-keygen). > > Ok, just sent to overseers both, as you suggest, generated with openssh4.2p1. >BTW: I just simplified that Wiki page a little. > > Thanks. To my best knowledge, at least 'til a couple of years ago, many people accessed gcc's cvs with Protocol 1, and now have to upgrade to use subversion at its best. Paolo.
Re: Vectorizing HIRLAM 1: This dependence is determinable.
Hi Toon, Thanks for the testcases. This one does get vectorized with autovect-branch: ~/autovect_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec -ftree-vectorizer-verbose=4 -S hilaram1.f90 hilaram1.f90:5: note: dependence distance = 0. hilaram1.f90:5: note: accesses have the same alignment. hilaram1.f90:5: note: dependence distance modulo vf == 0 between (*a_25)[D.949_60] and (*a_25)[D.949_60] hilaram1.f90:5: note: Alignment of access forced using peeling. hilaram1.f90:5: note: Vectorizing an unaligned access. hilaram1.f90:5: note: LOOP VECTORIZED. hilaram1.f90:9: note: vectorized 1 loops in function. dorit > L.S., > > This code: > > SUBROUTINE S(N, M) > DIMENSION A(N, M), B(N, M) > READ*,A,B > DO J = 1, M > DO I = 1, N > A(I, J) = A(I, J) + B(I, J) > ENDDO > ENDDO > PRINT*,A > END > > when compiled thusly: > > $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 - > msse2 vect1.f > > draws the following "not vectorized" message: > > vect1.f:5: note: not vectorized: can't determine dependence between > (*a_23)[D.951_86] and (*a_23)[D.951_86] > vect1.f:5: note: vectorized 0 loops in function. > > That's pretty silly, of course :-) > Source and destination A(I,J) overlap exactly, so vectorization of this loop > is certainly possible. The equivalent rank-1 example is vectorized without > problems. > > Exempting this one special case from "can't determine dependence" will mean > about 1000 more vectorized loops in HIRLAM. > > Kind regards, > > -- > Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 2: One out of the "unhandled data-ref" garbage bin :-)
>
> On Oct 21, 2005, at 9:19 AM, Toon Moene wrote:
>
> > L.S.,
> >
> > This code:
> >
> > SUBROUTINE S(A, B, N)
> > DIMENSION A(N), B(N)
> > READ*,Z,B
> > DO I = 1, N
> > A(I) = Z * B(I)
> > ENDDO
> > PRINT*,A
> > END
> >
> > when compiled thusly:
>
> The problem here is not really related to the vectorizer but the
> tree aliasing code. The loop looks like this at -O2 in the tree dumps:
># z_49 = PHI ;
># i_1 = PHI <1(1), i_48(3)>;
> :;
>D.982_41 = i_1 + -1;
># VUSE ;
>D.983_43 = (*b_20)[D.982_41];
># VUSE ;
>z.4_45 = z;
>D.985_46 = D.983_43 * z.4_45;
># z_124 = V_MAY_DEF ;
>(*a_36)[D.982_41] = D.985_46;
>i_48 = i_1 + 1;
>if (i_1 == D.972_25) goto ; else goto ;
>
> Notice how the statement which does "A(I) =" has a V_MAY_DEF of z. If
> we
> recorded it correctly, A and B would aliasing nothing as they are
> arguments
> passed in.
>
I think we actually fail before we try to antlialias A,B,z, because we
don't handle an invariant load ("z.4_45 = z;"). Invariant code motion
probably fails to take this out of the loop because of aliasing problems
dorit
> -- Pinski
>
Re: Vectorizing HIRLAM 2: One out of the "unhandled data-ref" garbage bin :-)
[EMAIL PROTECTED] wrote on 21/10/2005 03:19:57 PM: > L.S., > > This code: > > SUBROUTINE S(A, B, N) > DIMENSION A(N), B(N) > READ*,Z,B > DO I = 1, N > A(I) = Z * B(I) > ENDDO > PRINT*,A > END > > when compiled thusly: > > $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 - > msse2 vect2.f > > draws the following "not vectorized" message: > > vect2.f:4: note: not vectorized: unhandled data-ref > vect2.f:4: note: vectorized 0 loops in function. > > Hmmm, how about broadcasting Z to a vector register and using that in a > vectorized version of this loop :-) ? > this is not a problem, the vectorizer knows how to handle constants/invariants. The problem is that the access to Z in the loop translates to a load, which accesses the same location in memory in each iteration of the loop. The way to handle that is to effectively take the invariant load out of the loop, if aliasing doesn't stop us (as Pinski pointed out). dorit > Kind regards, > > -- > Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
This one gets vectorized for me, on powerpc-linux: ~/mainline_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec -ftree-vectorizer-verbose=4 -S hilaram4.f90 hilaram4.f90:4: note: Alignment of access forced using peeling. hilaram4.f90:4: note: Vectorizing an unaligned access. hilaram4.f90:4: note: LOOP VECTORIZED. hilaram4.f90:7: note: vectorized 1 loops in function. dorit > L.S., > > This code: > > SUBROUTINE S(N) > DIMENSION A(N), B(N) > READ*,ISTART,ISTOP,B > DO I = ISTART, ISTOP > A(I) = B(I) > ENDDO > PRINT*,A > END > > when compiled thusly: > > $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 - > msse2 vect4.f > > draws the following "not vectorized" message: > > vect4.f:4: note: not vectorized: complicated access pattern. > vect4.f:4: note: vectorized 0 loops in function. > > This sort of coding is rather prevalent in HIRLAM, especially in the > interesting inner loops. One needs this when not all of the inner area > is accessible / computable by the code at hand (for instance because there > are inaccessible "halo's" around the subarea that have to be treated > specially). > > The funny thing is that replacing ISTART with a constant makes this loop > vectorizable. So what's the fundamental difference (as far as vectorizing > is concerned) between a constant and a loop invariant :-) ? > > Kind regards, > > -- > Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 5: Another one out of the "unhandled data-ref" grab bag.
Like HIRLAM 6, this is also an aliasing problem: hilaram5.f90:4: note: not vectorized: can't determine dependence between com.b[D.909_22] and (*a_8)[D.909_22] hilaram5.f90:7: note: not vectorized: unhandled data-ref hilaram5.f90:7: note: vectorized 0 loops in function. dorit > L.S., > > This code: > > SUBROUTINE S(N) > DIMENSION A(N), B(12) > COMMON /COM/ B > DO I = 1, 12 > A(I) = B(I) > ENDDO > PRINT*,A(1:12) > END > > when compiled thusly: > > $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 - > msse2 vect5.f > > draws the dreaded "unhandled data-ref" message: > > vect5.f:4: note: not vectorized: unhandled data-ref > vect5.f:4: note: vectorized 0 loops in function. > > Hmmm, this is rather common (pun intended) in old Fortran code. > Why is this style "punished" by not being vectorizable ;-) ? > > Kind regards, > > -- > Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 3: Can't vectorize DOUBLE COMPLEX loops ...
Yes, we don't vectorize complex types yet. dorit > L.S., > > The following code: > > SUBROUTINE S(N) > DOUBLE COMPLEX A(N), B(N) > READ*,B > DO I = 1, N > A(I) = B(I) > ENDDO > PRINT*,A > END > > when compiled thusly: > > $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 - > msse2 vect3.f > > draws the following "not vectorized" message: > > vect3.f:4: note: not vectorized: no vectype for stmt: D.929_51 = > (*b_8)[D.928_48] scalar_type: complex8 > vect3.f:4: note: vectorized 0 loops in function. > > Which begs the question: Why not vectorizing *after* complex computation has > been lowered to the equivalent floating point computation ? > > HIRLAM contains relatively few complex computation - however, a sizable number > of physics problems are more easily expressed using (DOUBLE) COMPLEX > quantities. It seems they are on the short end of the rope as far as > vectorization is concerned. > > Kind regards, > > -- > Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Is the test svn repository working fine?
Richard Guenther wrote: >>Argh! I glanced briefly over those threads... >> >>While you are at it, are you willing to summarize the solution for this >>annoyance and/or point me to the relevant subthread? >> >> >Make use of ssh-agent. > > By the way, time ago, while becoming acquainted with ssh, I read about ssh-agent but decided not to use it: usually I don't like too much happening "automatically" ;) and, seriously, having to type a password gives me one more chance to stop a commit and avoid mistakes. But now, with svn, "something" is definitely necessary, and the best solution seems in fact Protocol 2 + connection caching... I'm waiting for overseers to install my new rsa and dsa Protocol 2 public keys... Paolo.
Successful gcc-4.0.2 build (MinGW i386 on WinXP)
I managed to build gcc-4.0.2 using MinGW 5.0.0 candidate gcc 3.4.4 with flag --enable-languages=c,c++ in MSys together with msysDTK 1.0.1 and upgraded autoconf(2.59), automake(1.82) and libtool(1.5) on a WinXP system. Since lack of test tools, testing is skipped, while the compilers work indeed :) Now the output from MSys in the objdir directory: $ ../gcc-4.0.2/config.guess i686-pc-mingw32 $ gcc -v Using built-in specs. Target: i686-pc-mingw32 Configured with: ../gcc-4.0.2/configure --prefix=/mingw --enable-languages=c,c++ --disable-nls --enable-threads Thread model: win32 gcc version 4.0.2 $ uname MINGW32_NT-5.1
Re: Is the test svn repository working fine?
Paolo Carlini <[EMAIL PROTECTED]> writes: > Ok, just sent to overseers both, as you suggest, generated with > openssh4.2p1. You don't need to generate a new one, just convert your RSA key for protocol 1 with ssh-keyconvert(1) to the format used with protocol 2. > Thanks. To my best knowledge, at least 'til a couple of years ago, many > people accessed gcc's cvs with Protocol 1 Many years ago gcc.gnu.org only supported ssh protocol 1. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Is the test svn repository working fine?
Andreas Schwab wrote: >>Ok, just sent to overseers both, as you suggest, generated with >>openssh4.2p1. >> >> >You don't need to generate a new one, just convert your RSA key for >protocol 1 with ssh-keyconvert(1) to the format used with protocol 2. > > Ah! This is *so* nice! Really puzzling, however, that the public one, at gcc, is still ok... Thanks! Paolo.
Re: Is the test svn repository working fine?
Andreas Schwab wrote: >You don't need to generate a new one, just convert your RSA key for >protocol 1 with ssh-keyconvert(1) to the format used with protocol 2. > > Sorry, dumb question: are you really sure openssh4.2p1 still installs that utility? I cannot find it... Paolo.
Re: Is the test svn repository working fine?
Paolo Carlini <[EMAIL PROTECTED]> writes: > Sorry, dumb question: are you really sure openssh4.2p1 still installs > that utility? I cannot find it... Sorry, I mistyped, it is called ssh-keyconverter. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Is the test svn repository working fine?
Paolo Carlini <[EMAIL PROTECTED]> writes: > Andreas Schwab wrote: > >>>Ok, just sent to overseers both, as you suggest, generated with >>>openssh4.2p1. >>> >>> >>You don't need to generate a new one, just convert your RSA key for >>protocol 1 with ssh-keyconvert(1) to the format used with protocol 2. >> >> > Ah! This is *so* nice! > > Really puzzling, however, that the public one, at gcc, is still ok... Note that it is still needed to send your converted public key to overseers@ for installation into your account. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Is the test svn repository working fine?
Andreas Schwab wrote: >>Sorry, dumb question: are you really sure openssh4.2p1 still installs >>that utility? I cannot find it... >> >> >Sorry, I mistyped, it is called ssh-keyconverter. > > Nope. I think that utility has been removed in the openss3.8 time frame... I can find it, of course, worst case I ask Olaf directly ;) Paolo.
Re: Is the test svn repository working fine?
Andreas Schwab wrote: >Note that it is still needed to send your converted public key to >overseers@ for installation into your account. > > Ah, ok, like this makes sense. Then, after all, I can just wait having the new Protocol 2 key installed, no? Paolo.
Re: Is the test svn repository working fine?
Paolo Carlini <[EMAIL PROTECTED]> writes: > Nope. I think that utility has been removed in the openss3.8 time frame... It's still part of openssh 4.1p1. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Is the test svn repository working fine?
Andreas Schwab wrote: >>Nope. I think that utility has been removed in the openss3.8 time frame... >> >> >It's still part of openssh 4.1p1. > > Ah, ok, good to know. Anyway, in the meanwhile my keys have been installed and everything works very well here! Paolo.
regression hunt setup using Subversion
*** Warning: Your file, reghunt.20051020.tar.bz2, contains more than 32 files after decompression and cannot be scanned. *** Here's my current regression hunt setup using Subversion in case anyone would like to try it out. I plan to update contrib/reghunt. The regression hunting script in contrib/ is reg_search, which starts with two dates. The new script is reg-hunt, which starts with two identifiers that index entries in a file, with each entry also including the SVN revision number. I've used that script with CVS as well, with each file entry having information about a patch from the gcc-cvs mailing list archive. Setting up that file was pretty awful, but for Subversion it's trivial. Unlike what's currently in contrib/reghunt, the tarball has everything needed for regression hunts except an rsync copy of the repository. It includes files for several examples that I use for testing changes to my setup on powerpc64-unknown-linux-gnu and i686-pc-linux-gnu. Happy hunting! Janis reghunt.20051020.tar.bz2 Description: BZip2 compressed data
Re: regression hunt setup using Subversion
The use of ncpu=`grep '^processor' /proc/cpuinfo | wc -l` seems Linux-specific; this looks like it should be in gcc-svn-env as a default for the user to customise, rather than in bin/gcc-build-*. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: regression hunt setup using Subversion
On Oct 21, 2005, at 3:11 PM, Joseph S. Myers wrote: The use of ncpu=`grep '^processor' /proc/cpuinfo | wc -l` seems Linux-specific; this looks like it should be in gcc-svn-env as a default for the user to customise, rather than in bin/gcc-build-*. I don't think it is Linux specific, it works on my openBSD box. It might work on other OS's which have /proc on it too like Solaris. -- Pinski
Re: regression hunt setup using Subversion
On Fri, Oct 21, 2005 at 03:14:47PM -0400, Andrew Pinski wrote: > > On Oct 21, 2005, at 3:11 PM, Joseph S. Myers wrote: > > >The use of > > > >ncpu=`grep '^processor' /proc/cpuinfo | wc -l` > > > >seems Linux-specific; this looks like it should be in gcc-svn-env as a > >default for the user to customise, rather than in bin/gcc-build-*. > > > I don't think it is Linux specific, it works on my openBSD box. It > might > work on other OS's which have /proc on it too like Solaris. I was afraid of this, which is why before I only submitted the toplevel scripts for contrib/ and let people provide their own build scripts. I'm happy to make things more portable, though, as long as people provide suggestions like this; thanks. Janis
Re: Grabbing Gomp (was: Is gcc optimized for thread level parallelism?)
Scott Robert Ladd <[EMAIL PROTECTED]> writes: > Jim Wilson wrote: > > No, but we are working on OpenMP support, which is somewhat > > related. This isn't automatic parallelization; it requires > > programmer instrumentation via pragmas. This is probably more > > directed at multiprocessor machines than threads, but it is a start > > in the right direction. See > > http://gcc.gnu.org/projects/gomp/ > > This is still in early stages of implementation. Don't expect > > anything to work yet. > > Where is the gomp branch in terms of the SVN transition? Should I > still grab it via CVS, or is it in the new SVN repository? We are still using CVS, and the branch is in there. When we move to SVN, all the CVS branches will be available via SVN. Ian
Vectorizing HIRLAM NN.
L.S., As Dorit indicated - it's better to perform vectorization experiments from the autovect branch. Further data on this with respect to the HIRLAM code base will be based on builds off the autovect branch. Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: regression hunt setup using Subversion
if sysctl is present in the path, "sysctl hw.ncpu" might be useful as well. Seems to work on FreeBSD and Darwin, assuming you don't require granularity of whether those CPUs are HTT or not. Shantonu On Oct 21, 2005, at 12:27 PM, Janis Johnson wrote: On Fri, Oct 21, 2005 at 03:14:47PM -0400, Andrew Pinski wrote: On Oct 21, 2005, at 3:11 PM, Joseph S. Myers wrote: The use of ncpu=`grep '^processor' /proc/cpuinfo | wc -l` seems Linux-specific; this looks like it should be in gcc-svn-env as a default for the user to customise, rather than in bin/gcc-build-*. I don't think it is Linux specific, it works on my openBSD box. It might work on other OS's which have /proc on it too like Solaris. I was afraid of this, which is why before I only submitted the toplevel scripts for contrib/ and let people provide their own build scripts. I'm happy to make things more portable, though, as long as people provide suggestions like this; thanks. Janis
Re: RFC: future gfortran development and subversion
On 10/19/05, Daniel Berlin <[EMAIL PROTECTED]> wrote: > Karl, Ben, have you ever seen a lengthy discussion indicating that > compressed and no-text base working copies are unlikely to happen? Au contraire, the feature has been in our to-do list (issue tracker) for years. We even accepted a Summer of Code student to implement this feature. (Unfortunately he never completed.) But it's something that AFAIK, the whole svn developer community wants. I just don't think anyone is actively working on it yet.
RE: [gelato-gcc] 15 Sept notes from GCC improvement for Itaniumconference call - Final Version
ON THE CALL: Bob Kidd (UIUC), Vladimir Makarov (Red Hat), Mark Smith (Gelato), Wenguang Chen (Tsinghua), Mark Davis (Intel), Diego Novillo (Red Hat), Andrey Belevantsev (RAS), Dan Berlin (IBM), Wen-mei Hwu (UIUC), Shin-Ming Liu (HP) The call covered: - current status / updates on the 3 improvement areas - brain storming how to help out Dan with the alias analysis improvement TODO list - GCC session at Brazil Gelato meeting - planned presentations (tentative schedule): - Diego Novillo (Monday 10/3, 7:30 to 8pm) - Shin-ming Liu (Monday 10/3, 8 to 8:30pm) - Bob Kidd (Monday 10/3, 8:30 to 9pm - Canqun Yang (Tuesday 10/4, 10 to 10:30am) - general discussion (Tuesday 10/4, 10:30 to 11:30am) - next steps, action items - continue discussion on alias analysis improvements and determine concrete ways to help - review and update IA-64 project list - a discussion on corporate IP needed for GCC -- can companies donate IP to GCC? - planned attendance (from those on the call) - Bob Kidd - Shin-ming Liu - Mark Davis - Wenguang Chen - Diego Novillo - Mark Smith Additional detail can be found below. NEXT MEETING: At Gelato Meeting in Porto Alegre, Brazil, October 2-5, 2005. Bob Kidd: - The patch to move superblock formation is ready to go and tested on x86, x86_64, and ia64. I'll post it to gcc-patches and post a message to the gcc mailing list with details shortly. Dan Berlin: --- The current status of the aliasing work is that work is proceeding on both intraprocedural and interprocedural call clobbering. Most of the infrasturcture to get it to be able to be start work on the actual improved algorithms and use the results is done, or will be done by next week. The main task that it would be helpful to have other people work on would be the "Aliasing Oracle" (pairwise query system for statements) implementation for tree-ssa. The backend already uses a query system exclusively (because it's aliasing is almost exclusively type based). This is an alternate way of representing and accessing the aliasing results that can provide better information (though more expensive to query) than the current representation provides. Our current analyses can actually provide better information that we represent. The eventual plan is to have a hybrid where optimizations use the current "virtual ssa" form to discover what appear to be things that alias, then query the "Aliasing Oracle" to see if it can disambiguate the aliases further if necessary (IE it decides it wants to try to sink a store past that point, or whatever). The implementation can start out simple, (IE even something that simply looked at base + offset of pointers in the two statements, and gave answers, would be a good start) and I'm more than happy to help mentor/introduce anyone to how to work with GCC's tree-ssa form to make this work, if they want to help implement it. Seriously. I'm really more than happy to spend hours teaching someone how to work with this stuff. IBM Research is also more than happy to let me do so. I already help Ken Zadeck a lot with understanding how to get things done in GCC, and he has become quite adept at working with GCC in a short time (< 6 months). If somebody has the resources to provide someone competent to work on aliasing, I'm glad to put them to work for you being productive on GCC :). Vladimir Makarov: - Zdenek Dvorak submitted a patch implementing prefetching on tree-ssa recently. It would be interesting to look how it will work for Itanium. HP and Intel are interesting in gcc performance improvement. If HP and Intel guys know for sure that gcc uses their patents or some their patents could be used for gcc performance improvement, it would be good to give FSF a permission to use the patents in gcc. On the other hand, investigating what patents gcc uses might be a dangerous thing because any compiler most probably uses algorithms patented by other companies. Diego Novillo: -- I spoke briefly about GCC's development process: * Legal issues need to be resolved early. Assign personal and corporate copyright to the FSF. * It's important to participate in the main development lists (gcc and gcc-patches). IRC is a good meeting place, too. * GCC works in three main stages: o Stage 1: Everything goes. o Stage 2: Stabilization. o Stage 3: Bug fixes only. * Work that spans multiple GCC stages is done on CVS branches in the main FSF repository. * I will present at the next Gelato conference. I'll describe GCC's internals, its development process, what is going on and what needs to be done. ___ Gelato-gcc mailing list [EMAIL PROTECTED] https://www.gelato.unsw.edu.au/mailman/
Re: RFC: future gfortran development and subversion
Thomas, Currently, gfortran is in a half-usable state. It is not yet ready as a replacement for g77 (see PR 19292) and there are quite a lot of things it gets wrong with Fortran 95. I think that this is way too strong. Of the outstanding PR19292 "bugs": 5900 The penultimate entry says - I would like to propose that this bug be closed. This is about as good as it gets. We should set up some automatic regression testing on LAPACK from hence forth. 13939 Concerns ugly commas - do we want this? If so, it can be done. 14067 The final comment is "The ICE is fixed, but this could still do with a warning." 14994 SECNDS missing - I would say that this should be done. I have used an interface to get round this one. 15234 libgfortran doesn't compile on Tru64 UNIX V4.0F - ??? 5.0 is no problem with a gcc-3.x 16465 parser chokes with ffixed-line-length-7 - is this essential? 16580 hm, gfortran ICE on test g77.f-torture/execute/intrinsic77.f is this a show stopper? 17737 ICE when variable appears in two data statements - invalid code. 18026 boz initialization of REALs fails. Penultimate comment " I've removed the "reject-valid" keyward because the code is not valid Fortran 95. From section 5.2.10, we have:" 18737 ICE on invalid use of external keyword - this should be fixed. 19425 Duplicate SAVE attribute problem - illegal f95 and questionable f77 20441 -finit-local-zero is missing from gfortran - a useful legacy requirement IMHO. 20811 gfortran include problem (regression from g77) - this should be fixed. A good tyro project. 21565 namelist in block data is illegal - I had better deal with this, hadn't I? 22175 BYTE Type Statement - Last comment "We do have a patch adding that enhancement." 22244 dimension information is lost for multi-dimension array - primarily gdb and optimization problem. 22282 loc intrinsic and %loc construction is not implemented in gfortran - do-able but not a disaster. 22290 Optimize Assigned GOTO to cause error with -O1 or higher - we seem to have a fix for this(?) 22359 fseek intrinsic appears to be unimplemented - should be done (using C fseek?). 23060 %VAL construct not implemented - do we want this? If so, it is do-able. 23912 MOD function requires same kind arguments - very fixable. I would say that this is a 33:33:33 mix of fixed:do-able:ignorable/wrong - let's have a blitz on it. Paul
Re: RFC: future gfortran development and subversion
The following 2 bugs have patches submitted: On Oct 21, 2005, at 5:06 PM, Paul Thomas wrote: 19425 Duplicate SAVE attribute problem - illegal f95 and questionable f77 22282 loc intrinsic and %loc construction is not implemented in gfortran - do-able but not a disaster. -- Pinski
Re: stack memory
On Oct 21, 2005, at 8:05 AM, Ivan Novick wrote: With the sun compiler, the declared buffer is pushed onto the stack upon entry into function foo and not only when it goes into scope. Yup. Do you know if gcc will use the stack for the buffer if it never goes into scope? Yes, it usually will. If you require that it not, use a different function and use noline.
svn tag inspection
svn tag inspection: mrs $ time cvs log version.c | grep apple-gcc-52 real0m3.640s user0m0.181s sys 0m0.037s mrs $ time svn ls svn+ssh://gcc.gnu.org/svn/gcc/tags | grep -i apple- gcc-52 real0m5.233s user0m0.083s sys 0m0.061s Is there a better/faster way of doing this? I did: svn co svn+ssh://gcc.gnu.org/svn/gcc/tags in the hopes that I could just update it form time to time, and have a list of all tags, but... empty directory...
Re: regression hunt setup using Subversion
Shantonu Sen <[EMAIL PROTECTED]> writes: > if sysctl is present in the path, "sysctl hw.ncpu" might be useful as > well. Seems to work on FreeBSD and Darwin, assuming you don't require > granularity of whether those CPUs are HTT or not. Or "getconf _NPROCESSORS_ONLN" (the POSIX way). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: regression hunt setup using Subversion
On Oct 21, 2005, at 4:11 PM, Andreas Schwab wrote: Shantonu Sen <[EMAIL PROTECTED]> writes: Or "getconf _NPROCESSORS_ONLN" (the POSIX way). On darwin: $ getconf _NPROCESSORS_ONLN undefined :-(
Re: svn tag inspection
On Fri, 2005-10-21 at 15:38 -0700, Mike Stump wrote: > svn tag inspection: > > mrs $ time cvs log version.c | grep apple-gcc-52 > real0m3.640s > user0m0.181s > sys 0m0.037s > > mrs $ time svn ls svn+ssh://gcc.gnu.org/svn/gcc/tags | grep -i apple- > gcc-52 > real0m5.233s > user0m0.083s > sys 0m0.061s > Not a fair comparison, since the svn repo has merged old-gcc into it's version.c, which adds another thousand revisions. > Is there a better/faster way of doing this? Use svn:// for readonly ops until we move to ssl auth (or i make it only resort to ssh for write ops)? I may come out with a patch that makes SVN only use ssh for write operations, before we move to ssl. Depends on time constraints, etc. We shall see. Anyway: [EMAIL PROTECTED]:~> time svn ls svn://gcc.gnu.org/svn/gcc/tags|grep -i apple-gcc-52 real0m3.269s user0m0.080s sys 0m0.016s You'll also get a much faster time if you moved the apple tags into a subdir (probably a second). Personally, one of the first things i think we should do on the new repo is organize the tags dir somehow. > I did: > > svn co svn+ssh://gcc.gnu.org/svn/gcc/tags > That would be insane. > in the hopes that I could just update it form time to time, and have > a list of all tags, but... empty directory... Uh, that won't give you an empty dir, it will give you *every single tag* You must have put a -N in there. >
So here is the final subversion plan
After considering all the comments, etc, here is the plan. We will move to subversion starting Wednesday, October 26th. This means that CVS except for wwwdocs will become readonly at that time. The conversion should take roughly 39 hours. I have chosen wednesday because: a. 1.3.0rc1 will be out tonight or this weekend (it would have been this morning, but there is a small packaging issue being worked out). Using a 1.3 client, the checkout sizes of the converted repo (NOT THE ONE CURRENTLY THERE) is 640 meg, instead of 900 someodd meg. b. 39 hours means it will finish around Friday sometime, which gives the weekend, which is usually light usage, to solve any immediate problems we haven't seen yet. c. Since we want people using a 1.3 client, waiting for 1.3.0 to release is wrong, since you want to know about any critical or showstopper bugs during the RC phase so they can be *fixed* in 1.3.0, not wait till it's released and then complain and wait for 1.3.1. d. It will give me a bit of time to reorg the wiki documentation, and replace our current cvs docs with an equivalent (though i'm very tempted to reorg the wiki docs and simply point people at the reorg'd wiki docs instead of having 2 pages that describe how to work with svn + gcc) Savannah should start mirroring gcc.gnu.org::gcc-svn sometime Friday, and throw a readonly svnserve somewhere (Again, i recommend a 1.3 or 1.3.0 release, for performance reasons) :). Before anyone asks, due to some bug fixes by iant to the old-gcc/gcc merging script by iant, the revisions for the new gcc repo will be slightly different from the old one, and thus: You will need to delete your current svn/svk based checkouts and redo them. --Dan
Re: svn tag inspection
Mike Stump <[EMAIL PROTECTED]> wrote: > I did: > > svn co svn+ssh://gcc.gnu.org/svn/gcc/tags > > in the hopes that I could just update it form time to time, and have > a list of all tags, but... empty directory... Besides the fact that you must have used -N, remember that you don't need all those merging tags anymore (forever). You can either live with a single tag per branch which you move along, or don't use tags alone and use svnmerge.py (see contrib scripts in 1.3). I am going to write some details in the wiki about this (I wrote svnmerge.py). In fact, after the subversion conversion is over, we can "svn delete" all those merging tags for good since they're there because you can't delete them in CVS but we really don't need them anymore (before anybody asks: "svn delete" keeps history of course). Giovanni Bajo
Re: svn tag inspection
On Oct 21, 2005, at 5:38 PM, Daniel Berlin wrote: You'll also get a much faster time if you moved the apple tags into a subdir (probably a second). Once we're converted, I'd propose to `cleanup' all the tags. We can svn rm the really old ones, logically group them and so on... You must have put a -N in there. I used -N first, it is sticky. :-)
Re: RFC: future gfortran development and subversion
--- Paul Thomas <[EMAIL PROTECTED]> wrote: > Thomas, > > >Currently, gfortran is in a half-usable state. It is not yet > >ready as a replacement for g77 (see PR 19292) and there are quite > >a lot of things it gets wrong with Fortran 95. > > > I think that this is way too strong. Of the outstanding PR19292 "bugs": > > > 22290 Optimize Assigned GOTO to cause error with -O1 or higher - we seem to > have a fix for this(?) > Patch here: http://gcc.gnu.org/ml/fortran/2005-10/msg00194.html But has not been reviewed. Best Regards, Feng Wang -- Creative Compiler Research Group, National University of Defense Technology, China. __ Meet your soulmate! Yahoo! Asia presents Meetic - where millions of singles gather http://asia.yahoo.com/meetic
Re: RFC: future gfortran development and subversion
So, collecting together the response to last night's mail: Status of PR 19292 metabug:- 5900 The penultimate entry says - I would like to propose that this bug be closed. This is about as good as it gets. We should set up some automatic regression testing on LAPACK from hence forth. Let's close it then - how about it, one of you Lapack afficianados? 13939 Concerns ugly commas - do we want this? If so, it can be done. 14067 The final comment is "The ICE is fixed, but this could still do with a warning." 14994 SECNDS missing - I would say that this should be done. I have used an interface to get round this one. I will do this. 15234 libgfortran doesn't compile on Tru64 UNIX V4.0F - ??? 5.0 is no problem with a gcc-3.x 16465 parser chokes with ffixed-line-length-7 - is this essential? 16580 hm, gfortran ICE on test g77.f-torture/execute/intrinsic77.f is this a show stopper? 17737 ICE when variable appears in two data statements - invalid code. I'll put this on my TODO list. 18026 boz initialization of REALs fails. Penultimate comment " I've removed the "reject-valid" keyward because the code is not valid Fortran 95. From section 5.2.10, we have:" 18737 ICE on invalid use of external keyword - this should be fixed. It is on my personal TODO list, I'll move it to the top of the pile. 19425 Duplicate SAVE attribute problem - illegal f95 and questionable f77 Patch submitted (pinskia reply) 20441 -finit-local-zero is missing from gfortran - a useful legacy requirement IMHO. 20811 gfortran include problem (regression from g77) - this should be fixed. A good tyro project. 21565 namelist in block data is illegal - I had better deal with this, hadn't I? On the TODO list. 22175 BYTE Type Statement - Last comment "We do have a patch adding that enhancement." Asher Langton has done it. (FX reply) 22244 dimension information is lost for multi-dimension array - primarily gdb and optimization problem. 22282 loc intrinsic and %loc construction is not implemented in gfortran - do-able but not a disaster. Part of the Cray patch (FX reply) that Steve will commit next week-ish. 22290 Optimize Assigned GOTO to cause error with -O1 or higher - we seem to have a fix for this(?) Patch here: (FW reply) http://gcc.gnu.org/ml/fortran/2005-10/msg00194.html But has not been reviewed. I will look at it next week but might need help/advice. 22359 fseek intrinsic appears to be unimplemented - should be done (using C fseek?). FX intends to do - timescale? + putc, getc and so on. 23060 %VAL construct not implemented - do we want this? If so, it is do-able. 23912 MOD function requires same kind arguments - very fixable. I would say that this is a 33:33:33 mix of fixed:do-able:ignorable/wrong - let's have a blitz on it. On the basis of the replies, the proportions are more like 50:25:25. If somebody wants to do my TODOs, feel welcome. Are you back FengWang? You are the one saddled with legacy code and must, I suppose, have an interest in some of these? Paul
