Re: Details for svn test repository
> Hoewver, please not that control c'ing cvs at the wrong time will cause > repository corruption as well. Subversion just doesn't let you do it > during the small time windows where ^^ where it will require the database code to go have to recover and cleanup the transaction, as some people have that set to require manual intervention Again, this has no effect when used against our server, so feel free to kill whatever processes you like.
Re: Details for svn test repository
Next time you don't want to deal with configuring source, install the binaries. I don't think that's fair. There are a very wide variety of machines used for GCC development and we want to *encourage* that. Plus, some people may use NFS and do filesystem stuff on a different machine than they use for GCC development. You can't always assume that binaries are available for every machine in question. I was concerned about the difficulty in building svn and must say that I wasn't at all encouraged by this report.
Re: Details for svn test repository
On Thu, 10 Feb 2005, Daniel Berlin wrote: > It *only* sends compressed texts, there is no need to pass extra > options. Although checkout/update are probably the normal use cases which use the bulk of the bandwidth - along with commit where svn can send diffs and cvs needs to upload the whole changed file - svn log appears to receive logs from the server in uncompressed form, which can be large for logs of e.g. the whole gcc/ directory. I'm sure those people developing GCC on dialup would be glad of compression even for much smaller logs. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Empty vectors in RTL
I just happened to write
(define_insn "foo"
[(set (match_operand:SI 0 "register_operand" "=r")
(unspec:SI [] 42))]
""
"xxx\t%0")
This is because I have an instruction which sets a register but
doesn't depend on anything visible to gcc. When I tried to rebuild
gcc, genflags crashed, because it tried to get the length of an empty
vector (in max_operand_1, calling XVECLEN, which tried to dereference
a NULL pointer).
This patch fixes the immediate crash, but is this the right thing to
do? Or should I always put something inside the vector, even if there
is nothing meaningful to put in there?
If it is required to always put something inside a vector, then I
think that read_rtx_1 should give an error upon seeing an empty vector
(at least for case 'E'). Otherwise, I think we need something like
this patch, as there is a lot of code which expects to call XVECLEN on
any 'E' format.
Ian
Index: read-rtl.c
===
RCS file: /cvs/gcc/gcc/gcc/read-rtl.c,v
retrieving revision 1.32
diff -p -u -r1.32 read-rtl.c
--- read-rtl.c 29 Sep 2004 11:23:11 - 1.32
+++ read-rtl.c 11 Feb 2005 02:21:58 -
@@ -1247,12 +1247,9 @@ read_rtx_1 (FILE *infile)
list_counter++;
obstack_ptr_grow (&vector_stack, read_rtx_1 (infile));
}
- if (list_counter > 0)
- {
- return_vec = rtvec_alloc (list_counter);
- memcpy (&return_vec->elem[0], obstack_finish (&vector_stack),
- list_counter * sizeof (rtx));
- }
+ return_vec = rtvec_alloc (list_counter);
+ memcpy (&return_vec->elem[0], obstack_finish (&vector_stack),
+ list_counter * sizeof (rtx));
XVEC (return_rtx, i) = return_vec;
obstack_free (&vector_stack, NULL);
/* close bracket gotten */
Re: Details for svn test repository
On 2005-02-11, at 02:19, Daniel Berlin wrote: Uh, why do you want the server stuff for gcc purposes? Just curious. Why not? If I want to try it out I want to try it out on my own repos too. Maybe I was just too optimistic about it. And then I simply didn't know up front what I will get - just the client the server or what else ot of it. configure --help didn't tell anything about it. These are java bindings, if you don't use them, don't use them. They are there. They have to be supported maintained and so on... they may break things if I suddenly update something on the system... And don't tell me this isn't going to happen. I did already enough oracle installations in my life to get always nervous if I hear the word Java... Uh, you could simply build it with --disable-shared if you really wanted No this certainly didn't work. It was still building the shared stuff. No problem I got APR. The apr - Fortunately it was possible to compile this thing with some tweaks. With some tweaks? It should compile out of the box on osx. I've done it before. The emphasis is on should... However most of the dependencies couldn't be specified. The thing just went on to look for them no matter what I told it. Having built apr many many times, i've never seen this problem. So look closer... Try disabling ldap: --without-ldap will give you a link error for the library named well: "no". Didn't find much of the things already present in the OS. That much about a reproductible setup... Down the bin it is. subversion setup itself was no better. mod_apache_blah/perl/python/ruby and what a not... It requires none of these things, it simply checks fo them, and will build bindings if you like. So I would like to be able to disable stuff I don't need. Nothing there - no chance of something to be broken. (The perfect error free code - the null code doing nothing!) Finally of course I was able to resolve those problems. But the questions remain: 1. What do I have? Which *kind* of subversion do I have? Checkouts seem to work but which "feature" do I miss? In the end, you have the same thing you would have gotten from a client install. No I like to know what I get. I like to know what the application contains what it is supporting and so on. This can't be established for a naive compile relying on configure scripts which have broken --disable-xxx or --without-xxx directives. Call me pedantic. But this is what you get too if working long enough in security sensitive environments. Maybe I'm not the windows generation which didn't grow up with the impression imposed on them that crashing software is something ethernal to life... What do you mean? You can happily abort a checkout and restart it later through hitting ctrl-c. And now imagine you don't have an 1G connection working 24/7. Just start the command and plug the LAN from you computer and watch svn never noticing this. Press ctrl-c and watch svn never timing out... Good test for poorly written software btw. 5. The client didn't handle signals properly (^C). It was trying for ever to finish a transaction it should abort. For the database based server backend (not the filesystem based one), A ha! There are multiple application which are posing as subversion-server. So what is a subversion server? Which "backend" did I get during the configure process? Which backends did I get I never wanted to have? Wondering why this makes me nervous? Well maybe I did already see too much CERT anouncments in my life... the stupid database library will require aborting the transaction if you an abort a transaction, even if it is a readonly one, So it will only let you abort an operation at certain times. Against our server, it doesn't matter, so you can control-z and kill it. Hoewver, please not that control c'ing cvs at the wrong time will cause repository corruption as well. Subversion just doesn't let you do it during the small time windows where A ha! Apparently the word transaction wasn't in the dictionary out there? Again poor quality for a new design. If a backend isn't as "secure" as another and could cause things to break or even work differently. Well it shouldn't be a back-end in first place at all. 6. Seeing problems 4. and 5. in the client I don't even want to have a look at the server - I already know up front that there will be enough problems with it. You just provided "internals" information which tells me that the speculation was right. Anyway as a summary - down it to the bin: There is no such a thing as subversion - there is a bunch of very different applications compiled from the same source code out there posing as a single one. What are you talking about? I am talking about the fact that it wasn't possible to control the feature set of this application. Thus you have a single source base which you can use to compile very different multiple applications. But you have a single application at hand. You didn't want to install perfec
Re: Details for svn test repository
On Feb 10, 2005, at 9:13 PM, Richard Kenner wrote: Next time you don't want to deal with configuring source, install the binaries. I don't think that's fair. There are a very wide variety of machines used for GCC development and we want to *encourage* that. Plus, some people may use NFS and do filesystem stuff on a different machine than they use for GCC development. You can't always assume that binaries are available for every machine in question. I was concerned about the difficulty in building svn and must say that I wasn't at all encouraged by this report. I think this report was misleading. I just did a build with no options to svn on powerpc-darwin (aka Mac OS X) and I had troubles. -- Pinski
Re: Details for svn test repository
On Fri, 2005-02-11 at 03:50 +0100, Marcin Dalecki wrote: > On 2005-02-11, at 02:19, Daniel Berlin wrote: > > > > Uh, why do you want the server stuff for gcc purposes? > > Just curious. Why not? If I want to try it out I want to try it out on > my own > repos too. Maybe I was just too optimistic about it. And then I simply > didn't know up front what I will get - just the client the server or > what else > ot of it. configure --help didn't tell anything about it. > > > These are java bindings, if you don't use them, don't use them. > > They are there. They have to be supported maintained and so on... they > may break things if I suddenly update something on the system... Whatever. Forget it, i'm not even going to bother responding to your message. It reads like one large troll.
Re: Empty vectors in RTL
Ian Lance Taylor writes: > This patch fixes the immediate crash, but is this the right thing to > do? Or should I always put something inside the vector, even if there > is nothing meaningful to put in there? I found other cases where an empty vector produces a NULL pointer and leads to a later crash. So I don't think it is safe to have an empty vector in RTL for the 'E' format. I propose this patch. OK if it passes testsuite and bootstrap? Or should this wait for 4.1? Ian 2005-02-10 Ian Lance Taylor <[EMAIL PROTECTED]> * read-rtl.c (read_rtx_1): Give fatal error if we see a vector with no elements. Index: read-rtl.c === RCS file: /cvs/gcc/gcc/gcc/read-rtl.c,v retrieving revision 1.32 diff -p -u -r1.32 read-rtl.c --- read-rtl.c 29 Sep 2004 11:23:11 - 1.32 +++ read-rtl.c 11 Feb 2005 03:15:23 - @@ -1253,6 +1253,9 @@ read_rtx_1 (FILE *infile) memcpy (&return_vec->elem[0], obstack_finish (&vector_stack), list_counter * sizeof (rtx)); } + else if (format_ptr[i] == 'E') + fatal_with_file_and_line (infile, + "vector must have at least one element"); XVEC (return_rtx, i) = return_vec; obstack_free (&vector_stack, NULL); /* close bracket gotten */
Re: Details for svn test repository
On Thu, 2005-02-10 at 22:00 -0500, Andrew Pinski wrote: > On Feb 10, 2005, at 9:13 PM, Richard Kenner wrote: > > > Next time you don't want to deal with configuring source, install > > the > > binaries. > > > > I don't think that's fair. There are a very wide variety of machines > > used for GCC development and we want to *encourage* that. It was perfectly fair. He's complaining the source has dependencies, and uses configure to find out what is available, and complains when it can't find the things it absolutely depends on. (He neglected to mention that it tells you what to get and where to get it, including urls, of course) He's also just flat out not reading. He complains it doesn't tell him what he's missing, giving the example of the database backend. However, the configure script contains this, and removing bdb libraries prints this message: You don't seem to have Berkeley DB version $db_version or newer installed and linked to APR-UTIL. We have created Makefiles which will build without the Berkeley DB back-end; your repositories will use FSFS as the default back-end. You can find the latest version of Berkeley DB here: http://www.sleepycat.com/download/index.shtml When it detects a missing apr, which is a requirement, it prints: echo "The Apache Portable Runtime (APR) library cannot be found." echo "Please install APR on this system and supply the appropriate" echo "--with-apr option to 'configure'" echo "" echo "or" echo "" echo "get it with SVN and put it in a subdirectory of this source:" echo "" echo " svn co \\" echo "http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x \\" echo "apr" echo "" echo "Run that right here in the top level of the Subversion tree," echo "then run autogen.sh again." echo "" echo "Whichever of the above you do, you probably need to do" echo "something similar for apr-util, either providing both" echo "--with-apr and --with-apr-util to 'configure', or" echo "getting both from SVN with:" echo "" echo " svn co \\" echo "http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x \\" echo "apr-util" echo "" How absolutely unfriendly! It told you where you can check it out, and exactly what to do when you got it! > Plus, some > > people may use NFS and do filesystem stuff on a different machine than > > they use for GCC development. You can't always assume that binaries > > are > > available for every machine in question. I wasn't. I was simply stating that if one is going to complain about having to get source to build from source, one is in the wrong business. Because every user program depends on some library or another. This one tlels you what the libraries are and where to get them, without having to google around to find the real source. > > > > I was concerned about the difficulty in building svn and must say that > > I > > wasn't at all encouraged by this report. > > I think this report was misleading. I just did a build with no options > to svn > on powerpc-darwin (aka Mac OS X) and I had troubles. I also have built svn on an osx machine with *nothing* but the developer tools installed, with absolutely no trouble. I know David has built it on aix. Anyone is free to try and build it on the platform they use to develop gcc. If it does not work, please, let me know. Kenner, before you complain about difficulties building it, you should probably try building it. If you run into trouble, please feel free to also complain on the subversion/apr/whatever mailing list, and i'm sure they'll be happy to fix their source if it's broken or not working.
Re: Empty vectors in RTL
On Thu, Feb 10, 2005 at 10:21:19PM -0500, Ian Lance Taylor wrote: > I found other cases where an empty vector produces a NULL pointer and > leads to a later crash. So I don't think it is safe to have an empty > vector in RTL for the 'E' format. This surprises me not at all. FYI, typically we put (const_int 0) into the vector when we've nothing else meaningful. > I propose this patch. OK if it passes testsuite and bootstrap? Yes. r~
Re: Details for svn test repository
Out of curiosity, although svn certainly seems attractive, are there any concerns observing that: - ironically it seems that the svn isn't itself under svn control but cvs? Has svn ever been relied upon for a significant open source project? - there doesn't seem to be an analogous svn web-based viewer? Is one planned to be available in the timeframe being considered for gcc use? - would the intend be to pull the entire unified tree (i.e. binutils, etc.) under svn? If not, might that create some potential complications? - is the svn client sw known to be cleanly build-able, reasonably robust. and secure on all likely significant client platforms? (just curious, as it wasn't obvious after some basic research?)
Re: Details for svn test repository
Against my better judgement, i'll respond anyway. On Fri, 2005-02-11 at 03:50 +0100, Marcin Dalecki wrote: > On 2005-02-11, at 02:19, Daniel Berlin wrote: > > > > Uh, why do you want the server stuff for gcc purposes? > > Just curious. Why not? If I want to try it out I want to try it out on > my own > repos too. Maybe I was just too optimistic about it. And then I simply > didn't know up front what I will get - just the client the server or > what else > ot of it. configure --help didn't tell anything about it. The configure script prints out copious messages about what it is going to disable because of what dependencies, so you are either not paying attention, or again, you are trolling. > > > These are java bindings, if you don't use them, don't use them. > > They are there. They have to be supported maintained and so on... they > may break things if I suddenly update something on the system... > And don't tell me this isn't going to happen. I did already enough > oracle > installations in my life to get always nervous if I hear the word > Java... So disable them if you are really worried about it. Most people want them, so it's included by default if possible. This is true of all the features you detest. > > > Uh, you could simply build it with --disable-shared if you really > > wanted > > No this certainly didn't work. It was still building the shared stuff. You need to be more specific. No it isn't. It still builds the libraries, but they are static. The libraries that are necessary are built. > > >> No problem I got APR. The apr - > >> Fortunately it was possible to compile this thing with some tweaks. > > > > With some tweaks? > > It should compile out of the box on osx. I've done it before. > > The emphasis is on should... It does. If it does not, you need to report a bug against apr, including all of your details. I'm sure they will be glad to fix it. > > >> However most of the > >> dependencies couldn't be specified. The thing just went on to look for > >> them no matter what I told it. > > > > Having built apr many many times, i've never seen this problem. > > So look closer... Try disabling ldap: --without-ldap will give you a > link > error for the library named well: "no". Please file a bug against apr. > > >> Didn't find much of the things already > >> present in the OS. That much about a reproductible setup... Down the > >> bin it is. > >> > >> subversion setup itself was no better. > >> mod_apache_blah/perl/python/ruby > >> and what a not... > > > > It requires none of these things, it simply checks fo them, and will > > build bindings if you like. > > So I would like to be able to disable stuff I don't need. Nothing there > - no > chance of something to be broken. (The perfect error free code - the > null code > doing nothing!) So disable them. It tells you what happens! The configure --help will also tell you, contary to your claims otherwise. > > >> Finally of course I was able to resolve those problems. But the > >> questions remain: > >> > >> 1. What do I have? Which *kind* of subversion do I have? Checkouts > >> seem > >> to work > >> but which "feature" do I miss? > > > > In the end, you have the same thing you would have gotten from a client > > install. > > No I like to know what I get. I like to know what the application > contains > what it is supporting and so on. This can't be established for a naive > compile > relying on configure scripts which have broken --disable-xxx or > --without-xxx directives. If you have discovered a broken directive, please report a bug against the approriate configure script. > Call me pedantic. But this is what you get too if working long enough > in security > sensitive environments. Maybe I'm not the windows generation which > didn't grow up > with the impression imposed on them that crashing software is something > ethernal > to life... > > > What do you mean? > > You can happily abort a checkout and restart it later through hitting > > ctrl-c. > > And now imagine you don't have an 1G connection working 24/7. Just > start the > command and plug the LAN from you computer and watch svn never noticing > this. > Press ctrl-c and watch svn never timing out... Good test for poorly > written > software btw. > > >> > >> 5. The client didn't handle signals properly (^C). It was trying for > >> ever to finish a > >> transaction it should abort. > > > > For the database based server backend (not the filesystem based one), > > A ha! There are multiple application which are posing as > subversion-server. So what is > a subversion server? Anything that speaks any of the protocols subversion clients speak, the same way a cvs server is anything that speaks any of the protocols cvs clients speak. > Which "backend" did I get during the configure > process? Which backends did I get I never wanted to have? Wondering why > this makes me nervous? Well maybe I did already see too much CERT > anouncments in >
Re: Details for svn test repository
On Thu, 2005-02-10 at 22:32 -0500, Paul Schlie wrote: > Out of curiosity, although svn certainly seems attractive, are there any > concerns observing that: > > - ironically it seems that the svn isn't itself under svn control but cvs? What? It's been under subversion control pretty much since day 1. Whatever gave you this idea? > Has svn ever been relied upon for a significant open source project? Yes, Mono, all of the apache projects, SpamAssassin, etc. > > - there doesn't seem to be an analogous svn web-based viewer? There are many. The one that most people use as a cvs viewer, viewcvs, supports svn already. There is also websvn, chora, and a number of other svn repository viewers. This is not hard info to find, to be honest, http://subversion.tigris.org/project_links.html Under "repository browsing tools", lists the major ones. > Is one > planned to be available in the timeframe being considered for gcc use? Uh, if it wasn't, and they weren't already mature, we wouldn't be having this discussion. > > - would the intend be to pull the entire unified tree (i.e. binutils, etc.) > under svn? Not right now. > If not, might that create some potential complications? No more complications than currently exists. > > - is the svn client sw known to be cleanly build-able, reasonably robust. > and secure on all likely significant client platforms? Yes.
Re: Details for svn test repository
On 2005-02-11, at 04:23, Daniel Berlin wrote: It was perfectly fair. He's complaining the source has dependencies, and uses configure to find out what is available, and complains when it can't find the things it absolutely depends on. Because apr and apr-util are providing things subversion doesn't need and because there is no application on my system needing them, I was complaining about the inability to control whatever I get those features sucked in or not. (He neglected to mention that it tells you what to get and where to get it, including urls, of course) Because I didn't complain about this at all. He's also just flat out not reading. He complains it doesn't tell him what he's missing, giving the example of the database backend. No! I'm complaining that it doesn't allow me to control what feature set I get. And I was complaining about the number of artificial dependencies the system is introducing. I wasn't. I was simply stating that if one is going to complain about having to get source to build from source, one is in the wrong business. Where did I say that? Because every user program depends on some library or another. Which is of course false. This one tlels you what the libraries are and where to get them, without having to google around to find the real source. This wasn't the problem. Again the problem was how to control the feature set during the source code setup stage. I also have built svn on an osx machine with *nothing* but the developer tools installed, with absolutely no trouble. And you didn't have control about the features it contains. You didn't mention that it needs apr and apr-util *installed* at least...
Re: Details for svn test repository
On Fri, 2005-02-11 at 04:39 +0100, Marcin Dalecki wrote: > On 2005-02-11, at 04:23, Daniel Berlin wrote: > >>> > > It was perfectly fair. He's complaining the source has dependencies, > > and > > uses configure to find out what is available, and complains when it > > can't find the things it absolutely depends on. > > Because apr and apr-util are providing things subversion doesn't need And at the same time, providing things it does need, hence the requirement. It relies on it for portable file i/o and such (particularly across unix and win32). > > Because every user program depends on some library or another. > > Which is of course false. Whatever. Everything in /usr/bin and /usr/sbin on my osx box, my windows machine, my linux machine, and the aix box appear to be linked against shared library. If you want to lawyer me, don't bother. I've got a JD, i'm taking the bar exam in 11 days. I'm not going for absolute precision in everything i say on the gcc development mailing list, as most normal human beings do not when they write. I'm not talking to you giving you a very precise opinion of law, i'm generalizing about the state of user programs. So feel free to replace "every user program" with "vast majority of useful user programs" like everyone else who read the email did. --Dan
Re: Details for svn test repository
On Thu, 2005-02-10 at 23:33 -0500, Daniel Berlin wrote: > On Fri, 2005-02-11 at 04:39 +0100, Marcin Dalecki wrote: > > On 2005-02-11, at 04:23, Daniel Berlin wrote: > > >>> > > > It was perfectly fair. He's complaining the source has dependencies, > > > and > > > uses configure to find out what is available, and complains when it > > > can't find the things it absolutely depends on. > > > > Because apr and apr-util are providing things subversion doesn't need > > And at the same time, providing things it does need, hence the > requirement. > It relies on it for portable file i/o and such (particularly across unix > and win32). Here, and before you try to interpret this as saying it only saying it uses it only for portable file i/o (including portable file status, deletion, opening, closing, determining stdin/stdout, unique files, permissions, reading, writing, path encoding and decoding, etc), it also very heavily uses it for the portable memory pool, portable dso loading, In fact, if you look at the web page for APR, you can discover exactly why it was created, and what it does, and then if you look at the history of subversion, you can discover why apr was used for these things, instead of reimplementing the wheel again. --Dan
Re: Details for svn test repository
On Fri, 2005-02-11 at 02:20 +, Joseph S. Myers wrote: > On Thu, 10 Feb 2005, Daniel Berlin wrote: > > > It *only* sends compressed texts, there is no need to pass extra > > options. > > Although checkout/update are probably the normal use cases which use the > bulk of the bandwidth - along with commit where svn can send diffs and cvs > needs to upload the whole changed file - svn log appears to receive logs > from the server in uncompressed form, This is true. However, you are talking about reporting data, and he was asking about checkout of actual things in the repository. :) > which can be large for logs of e.g. > the whole gcc/ directory. I'm sure those people developing GCC on dialup > would be glad of compression even for much smaller logs. > In this case it may be best to just offer anonymous ssh with compression, the way other people do (however, rather than have a key that everyone installs, you just have an anonssh password). However, i will explore making it use zlib to send logs when possible anyway (this should be able to be implemented in a backwards compatible manner because of how the protocol works).
Re: Details for svn test repository
On 2005-02-11, at 04:51, Daniel Berlin wrote: Against my better judgement, i'll respond anyway. On Fri, 2005-02-11 at 03:50 +0100, Marcin Dalecki wrote: On 2005-02-11, at 02:19, Daniel Berlin wrote: Uh, why do you want the server stuff for gcc purposes? Just curious. Why not? If I want to try it out I want to try it out on my own repos too. Maybe I was just too optimistic about it. And then I simply didn't know up front what I will get - just the client the server or what else ot of it. configure --help didn't tell anything about it. The configure script prints out copious messages about what it is going to disable because of what dependencies, so you are either not paying attention, or again, you are trolling. OK. I just took a redhat spec as configure command template. As it turns out this was a mistake on my part... argh! JBLD was once again the root of the problem. Unfortunately due to this I didn't notice that subversion packages apr/, apr-utils/, neon/ and db4/ as it should within itself thus making it self containing - which is indeed fine. Much much better then autogen. Thumbs up! Contrary to the origingal apr-1.1.0.tar.bz2 the configure scripts inside subversion honor --disable-shared and other flags properly. If not linking against shared apr the subversion configure script suddenly starts to honour --disable-shared itself... OK. that explains my previous problems. The only thing which makes me still a bit nervous is that apr-0.9.5 seems a bit of way off behind apr-1.1.0. However there seem to be no serious sec. advisories for apr versions newer then 0.9.4 out there...
Re: Details for svn test repository
Paul Schlie wrote: > Out of curiosity, although svn certainly seems attractive, are there any > concerns observing that: > > - ironically it seems that the svn isn't itself under svn control but cvs? svn was initially developed in cvs, but has been self-hosted since August 2001. You must have somehow found the old historical tree (unsurprisingly, at the time when svn converted to self-hosting there were no conversion scripts for the old history in CVS like there are now). >ÂÂÂHasÂsvnÂeverÂbeenÂreliedÂuponÂforÂaÂsignificantÂopenÂsourceÂproject? There's a (partial, of course) list of projects now using svn on http://subversion.tigris.org/propaganda.html - a few off the list are apache, samba, mono, and cups. > - there doesn't seem to be an analogous svn web-based viewer? Is one >ÂÂÂplannedÂtoÂbeÂavailableÂinÂtheÂtimeframeÂbeingÂconsideredÂforÂgccÂuse? viewcvs actually supports svn natively, and there are also svn-only interfaces like trac, websvn, and probably some others too. > - would the intend be to pull the entire unified tree (i.e. binutils, > etc.) >ÂÂÂunderÂsvn?ÂIfÂnot,ÂmightÂthatÂcreateÂsomeÂpotentialÂcomplications? It might fail to help clean them up, but as CVS provides no inter-file relationships at all, I don't see how it's meaningfully worse. I haven't any idea what plans are or aren't being ade. > - is the svn client sw known to be cleanly build-able, reasonably robust. >ÂÂÂandÂsecureÂonÂallÂlikelyÂsignificantÂclientÂplatforms? the client and the fsfs server backend ought to be as portable as apr is (so anyplace that apache can run). BDB has some additional requirements, but in any case a client doesn't need either backend, just the working copy stuff. > (just curious, as it wasn't obvious after some basic research?)
Re: Details for svn test repository
On 2005-02-11, at 05:43, Daniel Berlin wrote: In fact, if you look at the web page for APR, you can discover exactly why it was created, and what it does, and then if you look at the history of subversion, you can discover why apr was used for these things, instead of reimplementing the wheel again. Yes sure that's fine. Being misguided by a Linux distro vendor of particular prominence I didn't notice you integrated it in to subversion in the proper way. Sorry! One thing for sure apr does what it does in a way far superior to the historically "grown", well, libiberty.
Re: Details for svn test repository
Marcin Dalecki wrote: > OK. I just took a redhat spec as configure command template. As it > turns out this > was a mistake on my part... argh! JBLD was once again the root of the > problem. > Unfortunately due to this I didn't notice that subversion packages > apr/, apr-utils/, neon/ and db4/ as it should within itself thus making > it self > containing - which is indeed fine. Much much better then autogen. > Thumbs up! Indeed, taking a distro template (which quite understandably arranges for everything possible to be packaged as external dependencies) is the wrong approach if you want a self-contained build :-) > Contrary to the origingal apr-1.1.0.tar.bz2 the configure scripts inside > subversion honor --disable-shared and other flags properly. > If not linking against shared apr the subversion configure script > suddenly starts > to honour --disable-shared itself... OK. that explains my previous > problems. > > The only thing which makes me still a bit nervous is that apr-0.9.5 > seems a bit > of way off behind apr-1.1.0. However there seem to be no serious sec. > advisories for > apr versions newer then 0.9.4 out there... This is due to svn's binary compatibility policy. svn is somewhat unusual in that it provides and public library API's (including language bindings, hence the plethora of optional java/perl/python/etc dependencies), as well as the commandline tools. This frees alternate frontends like svk, plugins to integrate into IDEs, web frontends, and other such additions from needing to constantly chase changes to the core. Since apr 1.x is a new soname from apr 0.9.x, with incompatible ABI changes, svn is therefore not permitted (by their own rules) to migrate until they too change major version numbers. Anyway, thus far both branches of apr are maintained (apache httpd 2.0 is also still using libapr0, so I don't think there's much risk of neglect just yet). The latest apr 0.9.x release is only 3 days old, so it's not like this is an old and abandoned branch...
Re: Details for svn test repository
> From: Daniel Berlin <[EMAIL PROTECTED]> >> On Thu, 2005-02-10 at 22:32 -0500, Paul Schlie wrote: >> Out of curiosity, although svn certainly seems attractive, are there any >> concerns observing that: >> >> - ironically it seems that the svn isn't itself under svn control but cvs? > What? > It's been under subversion control pretty much since day 1. > Whatever gave you this idea? - I apparently misinterpreted: http://svn.collab.net/viewcvs/svn/trunk/ as was viewing it via viewcvs (which I now understand is svn friendly) And thank for the remaining answers as well, -paul-
Re: C++ testcase question: pointers to member functions
Zack Weinberg wrote:
On Thu, 2005-02-10 at 16:05 -0800, Janis Johnson wrote:
On Thu, Feb 10, 2005 at 04:00:49PM -0800, Zack Weinberg wrote:
On Thu, 2005-02-10 at 15:47 -0800, Janis Johnson wrote:
There are eight tests that check for that error message, although
probably not in quite the same way.
I may be confused - this *is* g++.mike/p10769a.C we are talking about,
yes? If so, I'd like to point out that g++.mike/p10769b.C appears to be
constructively the exact same test case except with dg-error markers on
the offending conversions instead of dg-boguses.
Except that p10769b.C doesn't use -Wno-pmf-conversions and gets different
error messages.
My bad, I should read more carefully. Um, is -Wno-pmf-conversions a
useful feature anymore, given that we are issuing errors with or without
it?
It looks like we do still use that flag in a couple of places, and I
don't see a deprecation note anywhere. Perhaps I was mistaken, but I
distinctly thought we'd killed this off.
It looks like we do still accept:
struct S {
void f();
};
void g() {
reinterpret_cast(&S::f);
}
But, the form in the test case where we are not even starting with a
pointer-to-member, but merely the name of a member function. I think
that's an intentional tightening; C++ doesn't allow you to do anything
with the name of a member function, except call it. And, the tightening
goes back at least to G++ 3.2, as far as I can tell. So, I think
removing the test case is still OK.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Re: How to get m/c dependent attributes from RTL (expressions, not a variable)?
_On 10-Feb-2005 08:36, James E Wilson san wrote_: Balaji S wrote: I have introduced m/c dependent attributes and handling it's semantics via the attribute's handler. And i want to use these attributes during assembly printing from RTL. How to get these attributes? This isn't how attributes are normally used. They are normally used for changing how variables/functions are defined, and how we emit RTL to access them. There is no guarantee that tree info for variable declarations will still be accessible when converting RTL insns to assembly. There is also the problem that the optimizer can do various things to memory load/store instructions. There may not be a one-to-one correspondence between loads and variables, and hence no guarantee that you have a usable mem_expr. If you need something special here, it really needs to be done when the RTL is emitted, not when the assembly is emitted. Yes. I agree on your point that attributes may not be valid after optimizations. Can you please tell me how to get these attributes while emitting RTL? My requirement is, need the newly introduced attributes while doing memory access. Thanks in advance, Balaji Sivan
