Austriaon gcc mirror is offline
On your https://gcc.gnu.org/mirrors.html page, first mirror listed is Austrian ftp://gd.tuwien.ac.at/gnu/gcc. I've noticed that it is offline for a few days. I tried firing email to Antonin.Sprinzl at tuwien.ac.at as listed on a page, but it keeps being dropped with the reply ( "Generic address unknown" ), so I'm contacting you. Best regards, Branko Badrljica
Re: GCC 4.0 Freeze
Zack Weinberg wrote: "This compiler does not support all of Fortran 77 yet. We recommend distributors continue to provide packages of g77 from GCC 3.4 for the time being. When gfortran is considered a complete replacement for g77 we will announce it." "We recommend distributors continue..." Oh I say, is it really so hard? -- Brane
Re: GCC 4.0 Freeze
Zack Weinberg wrote: Branko Äibej <[EMAIL PROTECTED]> writes: Zack Weinberg wrote: "This compiler does not support all of Fortran 77 yet. We recommend distributors continue to provide packages of g77 from GCC 3.4 for the time being. When gfortran is considered a complete replacement for g77 we will announce it." "We recommend distributors continue..." Oh I say, is it really so hard? Are you objecting to the absence of "that" after "recommend"? Indeed. I don't personally find that infelicitous (and find the version with a "that" excessively verbose) but I wouldn't be surprised if other dialects of English held the opposite perspective. Well, the sentence seems lopsided to me without the "that". But then, I prefer "it's not as weird as all that" to "it's not that weird", at least in formal communication. Maybe I'm just weird myself. z "prescriptivism considered mandatory or harmful on a case-by-case basis" w Heh. :) -- Brane
Re: [PATCH]: Proof-of-concept for dynamic format checking
Mike Stump wrote:
Imagine the following program:
{
int i = 234234;
printf ("%d", i);
}
imagine the folder collapsing this to puts ("234234");
Now imagine that the output of the original program depends on the
locale that's in force at execution time, which defines numberic output
to be in arabic numerals (real ones, not the sort we see in ASCII).
-- Brane
Re: svn tag inspection
Giovanni Bajo wrote: Jeffrey A Law <[EMAIL PROTECTED]> wrote: 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). Just a minor correction, you can certainly delete cvs tags. It just isn't something I'd necessarily recommend doing :-) cvs tag -d I think that is not a versioned operatoin (but I might be wrong). It's not. The point is that with svn you can remove all those tags as versioned operations, so you are really not destroying past history, Just to make this completely clear: removing a tag in SVN simply means that you remove the tag rirectory in HEAD. The tag (directory) still exists in previous revisions, so you can still, e.g., do a diff between two deleted tags. However, by deleting obsolete tags, you reduce the size of the tags directory in HEAD, thus obviously speeding up any queries amongs the current tags. and you're making the tags list much more meaningful and useful for everyday use. IMO we should do the same with closed branches, they really serve no purpose there in /branches in the current revision, we can safely "svn rm" them (or move to a /branches/closed subdir). Giovanni Bajo -- -- Brane
Re: svn diff branch woprking copy against mainline?
Joe Buck wrote: On Wed, Nov 02, 2005 at 06:28:42PM -0500, Daniel Berlin wrote: On Wed, 2005-11-02 at 14:33 -0800, Mike Stump wrote: On Nov 2, 2005, at 2:18 PM, Joern RENNECKE wrote: I tried: bash-2.05b$ svn diff Makefile.in svn+ssh://[EMAIL PROTECTED]/svn/ gcc/trunk/gcc/[EMAIL PROTECTED] But that gives me an error message: svn: Target lists to diff may not contain both working copy paths and URLs This works for us: svn diff --old svn+ssh://gcc.gnu.org/svn/gcc/tags/gcc_4_0_1_release/ gcc/file.c --new file.c for example. svn needs to go on a long command line diet, True. However, it *does* need some way to differentiate between url->url, url->wc, and wc->url commands, so even if there was an SVNROOT, you'd still have to specify it on the command lines :) It certainly seems that --old and --new are redundant. I suggest a search in http://svn.haxx.se/dev/. Also, you could consider stealing some ideas from Perforce, where the command would be something like p4 diff [EMAIL PROTECTED] file.c and the RCS figures out how to map the label to the repository version. Basically, the # and @ characters are special; # is used to introduce a revision number (the global revision number), and a number of things can follow @, like a label, or a date. This seems to be a common misconception. The important thing to remember here is that there is no separate namespace for labels and branches in SVN, and that the layout of the repository is arbitrary. IOW, the fact that you have branches in /branches is a convention, not something imposed by the SVN server. With the above in mind, your p4 example would translate to something like this: svn diff [EMAIL PROTECTED]/gcc_4_0_1_release file.c (not that this would work, for reasons discussed to death in the [EMAIL PROTECTED] archives). Now suppose your file.c is trunk/somdir/file.c. How is Subversion supposed to translate from trunk/somedir/[EMAIL PROTECTED]/gcc_4_0_1_release to the intuitively correct path in the repo, which is branches/gcc_4_0_1_release/somedir/file.c ? It can't, because it doesn't know that trunk is special. Now, as of not too long ago we can teach the svn client to expand the repository root; your example would become (assuming your working copy is on trunk, and assuming % expands to the repos root): svn diff --old %/branches/gcc_4_0_1_release/somedir/file.c --new file.c I suppose that's a bit better, although I admit it's not ideal. However, before coming up with a zillion suggestions about how to make the syntax nicer, please do consider the idea that we did put a lot of thought into the diff syntax, and that covering all the uses and edge cases and is not easy. I'll be the first to admit that the current syntax sucks, but it works -- as opposed to most proposed (and many once implemented, now defunct...) forms that usually break down in the most trivial cases. Telling the SVN devs to "change the diff syntax like /this/" is a bit like telling the GCC devs to "just add this extension to g++". We all know what the response to /that/ usually is. :) -- Brane
Re: svn diff branch woprking copy against mainline?
Paolo Bonzini wrote: More formally, you can say that any file in the checkout is made of BASE/DIR/filename where BASE is the URL passed to the latest `svn co' or `svn switch' command. The current SVN working copy philosophy (the same as CVS's, by the way) is that every working copy directory is self-contained. If we start recording command parameters in the working copy, we break that property. Anyway, there are other ways of achieving this behaviour that are more friendly to SVN's concept; they'd been discussed in the past and are being discussed now on the SVN dev list, but (unlike simple root URL expansion) aren't trivial to implement, so don't expect any changes in this area by the day after tomorrow. (I don't want to discuss these things in more detail on this list; SVN design discussions belong on the SVN dev list, and duplicating them here would be counter-productive. Of course, anyone is welcome to participate in discussions on our dev list.) -- Brane
Re: svn diff branch woprking copy against mainline?
Joern RENNECKE wrote: Branko Čibej wrote: It certainly seems that --old and --new are redundant. I suggest a search in http://svn.haxx.se/dev/. What should we search for? I tried both of --old and --new, and both searches came up empty. Heh, that's Google search for you... Try "--old" "--new" Also, you could consider stealing some ideas from Perforce, where the command would be something like p4 diff [EMAIL PROTECTED] file.c and the RCS figures out how to map the label to the repository version. Basically, the # and @ characters are special; # is used to introduce a revision number (the global revision number), and a number of things can follow @, like a label, or a date. This seems to be a common misconception. The important thing to remember here is that there is no separate namespace for labels and branches in SVN, and that the layout of the repository is arbitrary. IOW, the fact that you have branches in /branches is a convention, not something imposed by the SVN server. It's not a misconception, it's a perception of an svn shortcoming. There should be a configurable mapping from branch/tag names to branch/tag locations. I.e. you tell the svn server once what your conventions are, and then you don't have to apply them by hand every time you refer to a branch or tag. Without such a mechanism, svn makes a rather poor cvs replacement. As I said in another post, I don't want to repeat past [EMAIL PROTECTED] discussions on this list (and yes, you're talking about things we've already discussed to death. :) -- Brane
Re: svn diff branch woprking copy against mainline?
Andreas Schwab wrote: Branko Čibej <[EMAIL PROTECTED]> writes: Paolo Bonzini wrote: More formally, you can say that any file in the checkout is made of BASE/DIR/filename where BASE is the URL passed to the latest `svn co' or svn switch' command. The current SVN working copy philosophy (the same as CVS's, by the way) is that every working copy directory is self-contained. If we start recording command parameters in the working copy, we break that property. Isn't this what the "Repository Root" from svn info gives? No, that's the root of the repository, not the parameter given to "svn co". If you svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk the repository root that gets recorded is svn+ssh://gcc.gnu.org/svn/gcc The same root is recorded if you svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/bounded-pointers-branch -- Brane
Re: svn diff branch woprking copy against mainline?
Kevin Puetz wrote: I'm replying to a thread off of gcc-devel, but as I think I may have just had a thought that hasn't already been chewed through. So, I'm shifting to subversion-devel. If I'm wrong and this is already debunked, just shoot me down... Branko Čibej wrote: Andreas Schwab wrote: Isn't this what the "Repository Root" from svn info gives? No, that's the root of the repository, not the parameter given to "svn co". If you svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk the repository root that gets recorded is svn+ssh://gcc.gnu.org/svn/gcc The same root is recorded if you svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/bounded-pointers-branch -- Brane Sure. But svn info also knows (and has known for far longer) the URL. and URL with the Repository-Root prefix whacked off is BASE/DIR. So that info is obtainable. You can't tell which is BASE and which is DIR. -- Brane
Re: New branch: ia64-improvements-branch
Could I make a small suggestion? Now that GCC has switched to SVN, and tag and branch names are for all practical purposes in different namespaces, you could drop the "-branch" suffix from new branch names. That'll save 8 chars per branch URL; not much, but the best you can do until we come up with a better (diff) syntax.for SVN. :) (You could also rename old branches, but then old changelogs would be outdated.) -- Brane
Re: svn speed traversing slow filesystems
Kaveh R. Ghazi wrote: > On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote: > > Hi Dan, > > > > (BTW, sorry for the reposted messages.) > > > > While I was waiting for some svn commands to finish (cleanup, > > update) on my solaris2.7 box, which has a slow filesystem, I > > happened to run truss -p out of curiosity to see what was > > taking so long. Turns out that svn does many file operations on > > long pathnames. I recall that gnu find and other gnu utilities that > > do directory traversal got jumbo speedups by changing to the > > directory and running the file ops on "./filename" without long path > > prefixes. > > > > Could a future svn version get the same speedup? > > Actually, i just removed the need for most stat calls during update > in 1.4. Thanks Dan, that's great, but for the remaining i/o calls, it really does matter if you use long/paths/with/lots/of/slashes rather than chdir and ./filenames instead. I believe other recursive gnu utils besides gnufind like "rm -r" or "mkdir -p" etc were modified to use the chdir mechanism also because the benefit was so great. Yes that's fine, but we can't do this in SVN. We do the real work in libraries that are supposed to be thread-safe. The cwd is per-process on POSIX systems, as far as I know. No, please don't say we can do it "just for the command-line client." As Dan pointed out, there are better ways of speeding things up. -- Brane
Re: Accessing the subversion repository
Daniel Berlin wrote: On Tue, 2005-02-15 at 15:59 +, Andrew STUBBS wrote: I should note that svn treats it's remote connections as disposable, so svn+ssh will probably connect more than once for things like remote diffs. So if it takes a while to authenticate, this may not be your best bet if you are looking for blazing speed (as some seem to be :P). Isn't there some was of setting up a svnserve deamon or something? I'm sure I read that somewhere, or maybe I just misunderstood something somewhere. Anyway, I can live with it for the moment. This is the svnserve daemon (that's what svn:// and svn+ssh:// urls access). :) svnserve is the proprietary protocol like pserver. http uses DAV. When accessing a server via ssh svn spawns an svnserve with the -t option, does it not? I got the impression from somewhere that this could be made to persist. It does persist, but svnserve is just spawning threads/forking. The client is what is opening multiple connections. However, since svnserve clearly does persist when run as a local server (in deamon mode, not inetd) it is clear where I could have gotten the wires crossed. It is possible to run a local server as a proxy for a remote server, in order to limit the number of password requests? Not at the moment, but you could just use svk and access stuff that way if that was your goal. should work fine. One could always use ssh to open a tunnel to the remote host, then use plain svn:// over that, I suppose. -- Brane
gcc@gcc.gnu.org
Richard Guenther wrote: On Wed, 16 Feb 2005, Paul Schlie wrote: Richard Guenther wrote: While trying to implement folding of &a +- cst to &a[c] I came along the C frontend, which for int a[4]; int *p = &a[-1]; produces p = &a + (int *)-4; Would guess it should be: p = &a - (int *)4; or even: p = &a + - (int *)4; Yes, of course, but it is the C frontent that is producing &a + (int *)-4, not me. I'm just trying to work around this... In fact, it is c-common.c:2289 that does -4 -> (int *)-4 conversion, but pointer_int_sum is already called with PLUS_EXPR. build_unary_op unconditionally expands &x[y] to x+y, regardless of the sign of y. Of course the standard says that they are equal. But is &x[-1] == x + (int *)4*(int *)-1 ? From this follows that we have no way to convert this back to &x[-1], as we loose the sign information by the (int *) cast. How do the loop optimizers handle this - negative offsets by relying on unsigned pointer wrap-around? Out of curiosity, how can a cast to int* ever be correct here? The result of adding (or subtracting) two pointers is a ptrdiff_t, so it seems to me that the original transformation should be &a[-1] -> &a + (ptrdiff_t)-4 -- Brane
