Re: Details for svn test repository
On Thu, 2005-02-10 at 18:41, Joseph S. Myers wrote: > On Thu, 10 Feb 2005, Daniel Berlin wrote: > > > The only way to properly do this then is to just hack up the rcs files > > with the old-gcc data, where approriate, and increment all the other > > revision numbers. > > So does anyone wish to write a pre-pass which hacks up the old-gcc and gcc > RCS files into something good to pass to cvs2svn (which could then be used > as a stage in future trial conversions, and the final conversion)? It ought to be possible to obsolete all versions on the trunk in old-gcc after the fork was made, and in current-gcc to bump the major revision number for all commits (not in the live repository of course). A real guru might be able to force all the old-gcc work post split to appear to have been done on a branch... R.
Re: Details for svn test repository
Are you just I'll informed or plain . ? ( Sorry if it comes off a bit rough ). Subversion have been self hosting since a year or more, and as for significant other projects apache is one :-) ... You could have googled a bit before blurting out obviously false statements. A good place to start would be www.tigris.org where svn is hosted, ( and also contains all the other information you talk about ), the query on google was 'subversion homepage'. The main complaint on svn seem's to be a slow blame command, which is being worked on and has some improvement in the next release, ( from the mailinglist ). / regards, Lars Segerlund. On Thu, 10 Feb 2005 22:32:18 -0500 Paul Schlie <[EMAIL PROTECTED]> 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? > 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
On Wed, 09 Feb 2005 00:11:54 -0500, Daniel Berlin <[EMAIL PROTECTED]> wrote: > (Thanks very much to Al Stone of HP for hosting the test repo on > toolchain.org! This would not have been possible without him) Tried it, including builting svn on a Debian woody machine without root access and problems. The only thing I noticed is that a checked out HEAD is now 784MB instead of 280MB with CVS. Is there a way to have "cheap" multiple development trees, like cp -Rl the whole thing and svn is still happy? I usually have about 10 gcc trees lying around, half of them being "different" HEADs - and 8Gb instead of 3Gb counts, even in the days of el-cheapo disk-space. Richard.
GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
I was wondering why the above gcc parameter does not enable the use of the
fst/fld opcodes for pentium processors, while -march=i686 does. The Intel
manuals specifically say that they can be used across all pentium processors.
Example :
$ gcc -g -c -mcpu=i586 mdouble.cpp -o mdouble.o
$ objdump -dS -M intel mdouble.o
<...>
void foo()
{
0: 55 push ebp
1: 89 e5 movebp,esp
3: 83 ec 10subesp,0x10
double d;
double a;
d = 3.0;
6: b8 00 00 00 00 moveax,0x0
b: ba 00 00 08 40 movedx,0x4008
10: 89 45 f8movDWORD PTR [ebp-8],eax
13: 89 55 fcmovDWORD PTR [ebp-4],edx
a = d;
16: 8b 45 f8moveax,DWORD PTR [ebp-8]
19: 8b 55 fcmovedx,DWORD PTR [ebp-4]
1c: 89 45 f0movDWORD PTR [ebp-16],eax
1f: 89 55 f4movDWORD PTR [ebp-12],edx
}
22: c9 leave
23: c3 ret
While :
$ gcc -g -c -mcpu=i686 mdouble.cpp -o mdouble.o
$ objdump -dS -M intel mdouble.o
<...>
void foo()
{
0: 55 push ebp
1: 89 e5 movebp,esp
3: 83 ec 10subesp,0x10
double d;
double a;
d = 3.0;
6: dd 05 00 00 00 00 fldds:0x0
c: dd 5d f8fstp QWORD PTR [ebp-8]
a = d;
f: dd 45 f8fldQWORD PTR [ebp-8]
12: dd 5d f0fstp QWORD PTR [ebp-16]
}
15: c9 leave
16: c3 ret
FLD and FSTP are available on all pentium processors.
Is there a chance, for other reasons, that my code will not run on a pentium
if I use -march=i686 ?
Thanks for any help on this,
Peter
--
Peter Soetens, Research Assistant http://www.orocos.org
Katholieke Universiteit Leuven
Division Production Engineering, tel. +32 16 322773
Machine Design and Automation fax. +32 16 322987
Celestijnenlaan 300B [EMAIL PROTECTED]
B-3001 Leuven Belgium http://www.mech.kuleuven.ac.be/pma
Re: Details for svn test repository
Daniel Berlin wrote: And towards this end,i'm working on making blame a lot faster Will this also cover annotate using an -r option to go past the last reformatting delta? Other than that, what operations are people still worried about the slowness of? Because svn keeps an extra pristine copy for checkouts, I'll have to use svn export for automatic regression tests. With cvs, the overhead of the cvs information is small, so I could use checkouts, and when I wanted to work on / test some patches with a baseline known to build and to have a specific set of regressions, I just copied over the checked out tree and started working on it. With svn, I'll have to do a fresh checkout of the files/directories I'll be working on. The book mentions that there is an intent to make the extra pristine copy optional, but AFAICT this isn't something that is available now.
Re: temp obj created by compiler
Hi Jonathan & Everyone, Thanks for your reply. Yes, as you pointed out, it will create only 2 temporaries as below: X a(1); sub r3, fp, #16 mov r0, r3 mov r1, #1 bl X::X[in-charge](int) a = f(a); sub r3, fp, #24 sub r2, fp, #16 mov r0, r3 mov r1, r2 bl X::X[in-charge](X const&) sub r2, fp, #24 sub r3, fp, #20 mov r0, r3 mov r1, r2 bl f(X) sub r3, fp, #20 mov r0, r3 bl X::~X [in-charge]()=>dtor for temp1 sub r3, fp, #24 mov r0, r3 bl X::~X [in-charge]()=>dtor for temp2 sub r3, fp, #16 mov r0, r3 bl X::~X [in-charge]()=>dtor for a What i want to know is how to find what are the temporaries inserted by the compl. I tried looking into the ABI but couldn't get much help. Is there any way i can figure out the temporaries inserted by the compl. Looking forward for more help. :) Best regards, San --- Jonathan Wakely <[EMAIL PROTECTED]> wrote: > On Thu, Feb 10, 2005 at 01:49:44PM +, Jonathan > Wakely wrote: > > > > a = f(a); //this will create 4 temorary objects > > > > Why? I think this will only create two > temporaries. > > > > One when a is copied to the "x" parameter of f() > and one when "x" is > > copied to the return value; > > to be clear, "x" isn't a true temporary as it has a > name, but it is > created and destroyed during the execution of f(), > which is what I > assume you meant. > > jon > > -- > "Keep away from people who try to belittle your > ambitions. Small people > always do that, but the really great make you feel > that you, too, can > become great." > - Mark Twain > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: temp obj created by compiler
On Fri, Feb 11, 2005 at 05:44:52AM -0800, san san wrote: > Hi Jonathan & Everyone, Hello again San, > What i want to know is how to find what are the > temporaries inserted by the compl. I don't think I understand your question properly. > I tried looking into the ABI but couldn't get much > help. Is there any way i can figure out the > temporaries inserted by the compl. The compiler creates and destroys objects as dictated by the C++ standard. If the language rules require a temporary object to be created then the compiler will create one. Your code passes objects by value, not by reference, which causes objects to be created and destroyed. Apologies if I've misunderstood you, jon -- "Political satire became obsolete when Henry Kissinger was awarded the Nobel Prize." - Tom Lehrer
Mixed working copies (Was Re: Details for svn test repository)
On Fri, 2005-02-11 at 11:19 +, Chris Jefferson wrote: > Daniel Berlin wrote: > > > As the help page says, feel free to try things. > > Please ask me (either email or irc) if you need help. > > However, the very well written book at http://svnbook.red-bean.com/1.1 > > probably also has the answers (such as what the status flags mean, etc) > > > > I thought I'd email this rather than put it on the mailing list, as > hopefully it's easy to get around (I can't use irc...) > > I work on the libstdcxx_so_7-branch. This includes only a copy of the > libstdc++-v3 directory. As CVS is quite stupid about directories, on CVS > I could just check out gcc branch and the libstdc++-v3 from > libstdcxx_so_7 and pop the new libstdc++-v3 into gcc's directory and > everything would work fine(ish). > > It's not clear to me what the best way of working with libstdcxx_so_7 is > going to be in svn. Any suggestions? > (i've copied this back to the mailing list, since it is probably useful for others to know. I believe the svnhelp page on the wiki has this info on it as well. Hopefully, you don't mind :P) Easy enough. svn co the trunk of gcc (svn co svn://svn.toolchain.org/svn/gcc co trunk) go to the libstdc++-v3 directory of the trunk. type "svn switch svn://svn.toolchain.org/svn/gcc/branches/libstdcxx_so_7-branch/libstdc+ +-v3 ." It will switch that part of your working copy to the libstdcxx_so_7 branch. svn is happy to let you have working copies that are mixed from various branches, and update will update each part of the working copy approriately. > Thank you, > > Chris
Re: temp obj created by compiler
Hi Jon, Thanks again for replying. Let me clarify my problem: I have an assembly file of a .cpp file, from the assembly file i want to figure out where the compl has created temp objects. For this i thought of looking for copy-ctor becuase temp obj. are created using copy-ctors. I am not sure if there is any other way by which i can figure out that. I hope i am clear this time :). Regards, San --- Jonathan Wakely <[EMAIL PROTECTED]> wrote: > On Fri, Feb 11, 2005 at 05:44:52AM -0800, san san > wrote: > > > Hi Jonathan & Everyone, > > Hello again San, > > > What i want to know is how to find what are the > > temporaries inserted by the compl. > > I don't think I understand your question properly. > > > I tried looking into the ABI but couldn't get much > > help. Is there any way i can figure out the > > temporaries inserted by the compl. > > The compiler creates and destroys objects as > dictated by the C++ > standard. If the language rules require a temporary > object to be > created then the compiler will create one. > > Your code passes objects by value, not by reference, > which causes > objects to be created and destroyed. > > Apologies if I've misunderstood you, > > jon > > -- > "Political satire became obsolete when Henry > Kissinger was awarded the > Nobel Prize." > - Tom Lehrer > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Details for svn test repository
On Fri, 2005-02-11 at 13:28 +, Joern RENNECKE wrote: > Daniel Berlin wrote: > > > > > > >And towards this end,i'm working on making blame a lot faster > Will this also cover annotate using an -r option to go past the last > reformatting > delta? > yes. > >Other than that, what operations are people still worried about the > >slowness of? > Because svn keeps an extra pristine copy for checkouts, I'll have to use > svn export for > automatic regression tests. I don't understand why. Is this because of the amount of space the working copy takes up?
Re: temp obj created by compiler
On Fri, Feb 11, 2005 at 06:08:55AM -0800, san san wrote:
> Hi Jon,
>
> Thanks again for replying. Let me clarify my problem:
> I have an assembly file of a .cpp file, from the
> assembly file i want to figure out where the compl has
> created temp objects.
Ah, I see what you mean now - but I probably can't help you with that.
> For this i thought of looking for copy-ctor becuase
> temp obj. are created using copy-ctors. I am not sure
> if there is any other way by which i can figure out
> that.
Not necessarily true, temporaries might be created by any non-explicit
constructor, consider
struct A {
A(int);
};
void f(const A&);
f(0); // creates a temporary A using A::A(int)
jon
--
"It is always the best policy to tell the truth, unless, of course, you
are an exceptionally good liar."
- Jerome K. Jerome
Re: temp obj created by compiler
Thanks Jon,
Can anyone throw more light on this.
Regards,
Sanjiv
--- Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 11, 2005 at 06:08:55AM -0800, san san
> wrote:
>
> > Hi Jon,
> >
> > Thanks again for replying. Let me clarify my
> problem:
> > I have an assembly file of a .cpp file, from the
> > assembly file i want to figure out where the compl
> has
> > created temp objects.
>
> Ah, I see what you mean now - but I probably can't
> help you with that.
>
> > For this i thought of looking for copy-ctor
> becuase
> > temp obj. are created using copy-ctors. I am not
> sure
> > if there is any other way by which i can figure
> out
> > that.
>
> Not necessarily true, temporaries might be created
> by any non-explicit
> constructor, consider
>
> struct A {
> A(int);
> };
>
> void f(const A&);
>
> f(0); // creates a temporary A using A::A(int)
>
> jon
>
> --
> "It is always the best policy to tell the truth,
> unless, of course, you
> are an exceptionally good liar."
> - Jerome K. Jerome
>
__
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
Re: Details for svn test repository
Richard Guenther wrote: > On Wed, 09 Feb 2005 00:11:54 -0500, Daniel Berlin <[EMAIL PROTECTED]> > wrote: >> (Thanks very much to Al Stone of HP for hosting the test repo on >> toolchain.org! This would not have been possible without him) > > Tried it, including builting svn on a Debian woody machine without > root access and > problems. The only thing I noticed is that a checked out HEAD is now > 784MB instead > of 280MB with CVS. Is there a way to have "cheap" multiple This is because of the 'text-base' - svn keeps pristine copies of the checked-out version locally, which makes diffing your local mods a local operation (and correspondingly, makes it much faster), lets it send only diffs on the network, lets 'svn status' ignore files that were touched but not really modified, etc. There's a tradeoff in disk space, but it's generally a good one in these heady days of 50Â/GB disk space :-) > development trees, like > cp -Rl the whole thing and svn is still happy? I usually have about You may want to pose this question on the svn list, but I don't see any immediate reason that wouldn't work. svn is (as far as I know) using the unlink()/rename() approach to ensure robustness, which should also make it hardlink-friendly. The savings will tend to degrade over time though, since doing svn up on each folder would break the linking for files in which it receives modifications (even if each tree gets the same modifications) - but I expect you knew that. > 10 gcc trees > lying around, half of them being "different" HEADs - and 8Gb instead > of 3Gb counts, > even in the days of el-cheapo disk-space. You might also find a client like svk serves your needs better - as part of supporting disconnected operation, it takes a different tack on this matter. Instead of keeping a text-base in the working copy, it keeps a local mirror of part or all of the repository (which can be partial in both layout and time - 'only includes module/portion/*' and/or 'only includes revisions N-HEAD'). This mirror of the repo can then be used to support multiple working copies, each of which is then entirely pristine (svk even keeps its admin data about what revisions are checked out to each WC elsewhere, not in subfolders). And it can commit right back to the upstream. > Richard.
Re: C++ testcase question: pointers to member functions
Mark Mitchell <[EMAIL PROTECTED]> writes: [...] | 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 That recollection is exact. -- Gaby
Re: Details for svn test repository
Daniel Berlin wrote: Because svn keeps an extra pristine copy for checkouts, I'll have to use svn export for automatic regression tests. I don't understand why. Is this because of the amount of space the working copy takes up? Yes. Sometimes stuff breaks and you don't notice it right away (E.g. because the feature is not automatically tested, or because of noise from other test failures). So it is useful to keep several month worth of test builds around. Doubling the amount of space taken up by this is not acceptable. Ideally, you could do an read-only checkout, and iin addition to the actual files you'd only store the repository location and revision numbers of the checkedout files, and maybe an md5 od SHA1 hash. When you then later decide that you want to work on some of the source, you could tell svn to create the pristine copies in for a set of files and/or sub-trees and change the files to read-write (taking umask into account where available).
Re: GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
I think Intel's confusing numbering system has confused
you. All ix86 processors, if the expression
x in first ix86 < x in second ix86
holds true, then second ix86 is compatible. The i586 is
NOT the Pentium. Nor is the i686. But the i686 was one of
the first Intel processors with built-in FPU. If you are
asking for Pentium, try the following switches:
-march=pentium
-march=pentium -mmmx # Pentium MMX
-march=pentium2
-march=pentium3
-march=celron
-march=pentium4
-march=prescott # this will probably get you in trouble
If you use any of these switches, it will add FP
instruction calls. -march=prescott has caused more than
one problem elsewhere.
Samuel Lauber
> I was wondering why the above gcc parameter does not enable the use of the
> fst/fld opcodes for pentium processors, while -march=i686 does. The Intel
> manuals specifically say that they can be used across all pentium processors.
>
> Example :
> $ gcc -g -c -mcpu=i586 mdouble.cpp -o mdouble.o
> $ objdump -dS -M intel mdouble.o
> <...>
> void foo()
> {
> 0: 55 push ebp
> 1: 89 e5 movebp,esp
> 3: 83 ec 10subesp,0x10
> double d;
> double a;
> d = 3.0;
> 6: b8 00 00 00 00 moveax,0x0
> b: ba 00 00 08 40 movedx,0x4008
>10: 89 45 f8movDWORD PTR [ebp-8],eax
>13: 89 55 fcmovDWORD PTR [ebp-4],edx
> a = d;
>16: 8b 45 f8moveax,DWORD PTR [ebp-8]
>19: 8b 55 fcmovedx,DWORD PTR [ebp-4]
>1c: 89 45 f0movDWORD PTR [ebp-16],eax
>1f: 89 55 f4movDWORD PTR [ebp-12],edx
> }
>22: c9 leave
>23: c3 ret
>
> While :
> $ gcc -g -c -mcpu=i686 mdouble.cpp -o mdouble.o
> $ objdump -dS -M intel mdouble.o
> <...>
> void foo()
> {
> 0: 55 push ebp
> 1: 89 e5 movebp,esp
> 3: 83 ec 10subesp,0x10
> double d;
> double a;
> d = 3.0;
> 6: dd 05 00 00 00 00 fldds:0x0
> c: dd 5d f8fstp QWORD PTR [ebp-8]
> a = d;
> f: dd 45 f8fldQWORD PTR [ebp-8]
>12: dd 5d f0fstp QWORD PTR [ebp-16]
> }
>15: c9 leave
>16: c3 ret
>
> FLD and FSTP are available on all pentium processors.
> Is there a chance, for other reasons, that my code will not run on a pentium
> if I use -march=i686 ?
--
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powered by Outblaze
Using up double diskspace for working copies (Was Re: Details for svn test repository)
On Fri, 2005-02-11 at 15:29 +, Joern RENNECKE wrote: > Daniel Berlin wrote: > > > > > > >>Because svn keeps an extra pristine copy for checkouts, I'll have to use > >>svn export for > >>automatic regression tests. > >> > >> > > > >I don't understand why. > >Is this because of the amount of space the working copy takes up? > > > > > > Yes. Sometimes stuff breaks and you don't notice it right away (E.g. > because the > feature is not automatically tested, or because of noise from other test > failures). > So it is useful to keep several month worth of test builds around. > Doubling the > amount of space taken up by this is not acceptable. Then you are correct, the only way to do what you want is export, or cp excluding the .svn directories. Do you consider this a show stopper, or are you willing to export your trees? Because if it's a show stopper, then so will be arch, monotone, or any of our other replacements (they all either store the entire repo on your disk, or have stuff in the working copy), and we will be stuck with cvs until everyone is happy to use up double/whatever disk. Again guys, i'm not trying to force anything on anyone. If we don't want to move, we don't *have* to move. I just have a hard time seeing us using cvs for another 5-10 years, and i have a hard time seeing what is going to miraculously change about our repository between then and now. The only thing i see changing is maybe things like svn grow the ability to compress their working copies (already been suggested and i believe someone is working on it), or whatever. I highly doubt the basic fact that the checkouts take more space will change, even if the constant changes from 2.5 to 1.5. So if the fact that checkouts are larger is a showstopper for people, (IE they aren't willing to adjust), we might as well quit evaluating now :)
Re: License text irregularity in gcc/config/mips/linux-unwind.h
__Way__ to close to the LGPL. The LGPL in effect, says the GPL with that kind exception (letting people link this with there program regardless of whether the license is GPL-compatible). I think that those exceptions in `libgcc' are conflicting with one of the sections of the GPL that prevents proprietary software authors from linking in GPLd software. I think that is an important privlage for the free software community. As for the exception missing, it should be kept that way. Samuel Lauber > It seems that most source files for libgcc have the following exception text: > > -8< > > In addition to the permissions in the GNU General Public License, the > Free Software Foundation gives you unlimited permission to link the > compiled version of this file with other programs, and to distribute > those programs without any restriction coming from the use of this > file. (The General Public License restrictions do apply in other > respects; for example, they cover modification of the file, and > distribution when not linked into another program.) > > -8< > > Which allows libgcc to be linked to a program with out forcing that > program to be GPLed. > > gcc/config/mips/linux-unwind.h is part of libgcc but does not have > the exception in its copyright section. > > It seems that this is an oversight. > > I can add the exception if it is deemed the proper thing to do. > > David Daney -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Why is this diagnostic only reported with -pedantic?
This is _not_ a bug. This is _C_, not C++. ISO C99
requires a diagnostic for it. I think what's going on is
that the compiler is warning about a return with a value
in function returning void in foo(), but baz() is trying
to return a value from a function that never returned
anything. This is probably a confusingly worded warning.
Samuel Lauber
> > Given this program:
> > static void foo(void) { return(1); }
> > static void bar(void) { }
> > static void baz(void) { return(bar()); }
> > int main(int argc, char * argv[]) {
> > baz();
> > return(1);
> > }
> >
> > A compile without -pedantic gives a warning for foo(), but not for
> > baz():
> > $ gcc-3.4 foo.c
> > foo.c: In function `foo':
> > foo.c:1: warning: `return' with a value, in function returning void
> >
> > A compile with -pedantic gives a warning for both functions.
> > $ gcc-3.4 -pedantic foo.c
> > foo.c: In function `foo':
> > foo.c:1: warning: `return' with a value, in function returning void
> > foo.c: In function `baz':
> > foo.c:3: warning: `return' with a value, in function returning void
>
> The code in baz() is perfectly legal since ISO C++ allows void
> returns. -pedantic should not warn about it because it is not a GCC extension
> at all. Would you please file a bugreport about the incorrect warning emitted
> for baz()?
>
> Thanks
> Giovanni Bajo
--
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powered by Outblaze
Re: GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
Hi Samuel,
On Friday 11 February 2005 16:38, you wrote:
> I think Intel's confusing numbering system has confused
> you. All ix86 processors, if the expression
> x in first ix86 < x in second ix86
> holds true, then second ix86 is compatible. The i586 is
> NOT the Pentium. Nor is the i686. But the i686 was one of
> the first Intel processors with built-in FPU. If you are
> asking for Pentium, try the following switches:
> -march=pentium
> -march=pentium -mmmx # Pentium MMX
> -march=pentium2
> -march=pentium3
> -march=celron
> -march=pentium4
> -march=prescott # this will probably get you in trouble
>
> If you use any of these switches, it will add FP
> instruction calls. -march=prescott has caused more than
> one problem elsewhere.
This is what the GCC manual says, I added the '***'s
-mcpu=cpu-type
Tune to cpu-type everything applicable about the generated code, except
for the ABI and the set of available instructions. The choices for cpu-type
are i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro, pentium2,
pentium3, pentium4, prescott, nocona, k6, k6-2, k6-3, athlon, athlon-tbird,
athlon-4, athlon-xp, athlon-mp, winchip-c6, winchip2 and c3.
While picking a specific cpu-type will schedule things appropriately for
that particular chip, the compiler will not generate any code that does not
run on the i386 without the -march=cpu-type option being used. ***i586 is
equivalent to pentium and i686 is equivalent to pentiumpro***. k6 and athlon
are the AMD chips as opposed to the Intel ones.
-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for
cpu-type are the same as for -mcpu. Moreover, specifying -march=cpu-type
implies -mcpu=cpu-type.
My experiments with setting options confirms the ***'d part, wrt the FPU
opcodes being used : i586, pentium and pentium-mmx generate the same (non
fpu-using) code, while i686 and pentiumpro generate the fpu-using code.
Any other hints ?
Peter
PS : please CC me since I'm not on the list. Thank you.
>
> Samuel Lauber
>
> > I was wondering why the above gcc parameter does not enable the use of
> > the fst/fld opcodes for pentium processors, while -march=i686 does. The
> > Intel manuals specifically say that they can be used across all pentium
> > processors.
> >
> > Example :
> > $ gcc -g -c -mcpu=i586 mdouble.cpp -o mdouble.o
> > $ objdump -dS -M intel mdouble.o
> > <...>
> > void foo()
> > {
> > 0: 55 push ebp
> > 1: 89 e5 movebp,esp
> > 3: 83 ec 10subesp,0x10
> > double d;
> > double a;
> > d = 3.0;
> > 6: b8 00 00 00 00 moveax,0x0
> > b: ba 00 00 08 40 movedx,0x4008
> >10: 89 45 f8movDWORD PTR [ebp-8],eax
> >13: 89 55 fcmovDWORD PTR [ebp-4],edx
> > a = d;
> >16: 8b 45 f8moveax,DWORD PTR [ebp-8]
> >19: 8b 55 fcmovedx,DWORD PTR [ebp-4]
> >1c: 89 45 f0movDWORD PTR [ebp-16],eax
> >1f: 89 55 f4movDWORD PTR [ebp-12],edx
> > }
> >22: c9 leave
> >23: c3 ret
> >
> > While :
> > $ gcc -g -c -mcpu=i686 mdouble.cpp -o mdouble.o
> > $ objdump -dS -M intel mdouble.o
> > <...>
> > void foo()
> > {
> > 0: 55 push ebp
> > 1: 89 e5 movebp,esp
> > 3: 83 ec 10subesp,0x10
> > double d;
> > double a;
> > d = 3.0;
> > 6: dd 05 00 00 00 00 fldds:0x0
> > c: dd 5d f8fstp QWORD PTR [ebp-8]
> > a = d;
> > f: dd 45 f8fldQWORD PTR [ebp-8]
> >12: dd 5d f0fstp QWORD PTR [ebp-16]
> > }
> >15: c9 leave
> >16: c3 ret
> >
> > FLD and FSTP are available on all pentium processors.
> > Is there a chance, for other reasons, that my code will not run on a
> > pentium if I use -march=i686 ?
--
Peter Soetens, Research Assistant http://www.orocos.org
Katholieke Universiteit Leuven
Division Production Engineering, tel. +32 16 322773
Machine Design and Automation fax. +32 16 322987
Celestijnenlaan 300B [EMAIL PROTECTED]
B-3001 Leuven Belgium http://www.mech.kuleuven.ac.be/pma
Re: Details for svn test repository
On Fri, 11 Feb 2005 15:29:11 +, Joern RENNECKE <[EMAIL PROTECTED]> wrote: > Daniel Berlin wrote: > > > > > > >>Because svn keeps an extra pristine copy for checkouts, I'll have to use > >>svn export for > >>automatic regression tests. > >> > >> > > > >I don't understand why. > >Is this because of the amount of space the working copy takes up? > > > > > > Yes. Sometimes stuff breaks and you don't notice it right away (E.g. > because the > feature is not automatically tested, or because of noise from other test > failures). > So it is useful to keep several month worth of test builds around. > Doubling the > amount of space taken up by this is not acceptable. If cp -Rl will not confuse svn, as Kevin suggests, first copying the repository using hard-links for files and then updating the new copy should save a lot of disk space. I'll try, if svk helps here, too. Richard.
Re: License text irregularity in gcc/config/mips/linux-unwind.h
On Fri, Feb 11, 2005 at 04:49:59PM +0100, Sam Lauber wrote: > __Way__ to close to the LGPL. The LGPL in effect, says the > GPL with that kind exception (letting people link this > with there program regardless of whether the license is > GPL-compatible). I think that those exceptions in > `libgcc' are conflicting with one of the sections of the > GPL that prevents proprietary software authors from > linking in GPLd software. I think that is an important > privlage for the free software community. > As for the exception missing, it should be kept that way. Don't teach your grandmother to suck eggs. The exception is there for a reason. The licence has been carefully chosen. jon -- "Those who don't understand UNIX are doomed to reinvent it, poorly." - Henry Spencer
Re: GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
On Fri, Feb 11, 2005 at 04:38:03PM +0100, Sam Lauber wrote: > I think Intel's confusing numbering system has confused > you. All ix86 processors, if the expression > x in first ix86 < x in second ix86 > holds true, then second ix86 is compatible. The i586 is > NOT the Pentium. So why does the GCC manual say that -mtune=pentium is equivalent to -mtune=i586 ? > the first Intel processors with built-in FPU. If you are > asking for Pentium, try the following switches: > -march=pentium > -march=pentium -mmmx # Pentium MMX or -march=pentium-mmx > -march=pentium2 > -march=pentium3 > -march=celron > -march=pentium4 > -march=prescott # this will probably get you in trouble > > If you use any of these switches, it will add FP > instruction calls. -march=prescott has caused more than > one problem elsewhere. > > Samuel Lauber -- "Fanaticism consists in redoubling your efforts when you have forgotten your aims." - George Santayana
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
Daniel Berlin wrote: Then you are correct, the only way to do what you want is export, or cp excluding the .svn directories. Do you consider this a show stopper, or are you willing to export your trees? No, I don't think it is a show stopper, but it is a drawback. The plan is to have the regression tester find out the current head revision, and then export this, and stash away the version number used. I should then be able to do a checkout of selected files / subtrees if and when it is needed. I don't know how well the server will take the extra load, but I wouldn't expect it to be a major problem. I also consider this to be a drawback in terms of ease of use, however, not as bad as the missing ability in CVS to copy / rename files while keeping the history. Because if it's a show stopper, then so will be arch, monotone, or any of our other replacements (they all either store the entire repo on your disk, or have stuff in the working copy), and we will be stuck with cvs until everyone is happy to use up double/whatever disk. Actually, having one copy of the entire repository might be cheaper than having several dozen double checkouts. But then, having no firm, easily memorized revision numbers is certainly a much larger issue. I understand that distributed revision control systems would make it much harder to refer to a particular version.
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
On Fri, 2005-02-11 at 16:35, Joern RENNECKE wrote: > Actually, having one copy of the entire repository might be cheaper than > having > several dozen double checkouts. But then, having no firm, easily memorized > revision numbers is certainly a much larger issue. I understand that > distributed > revision control systems would make it much harder to refer to a particular > version. > Why do you need to keep the source around at all (unless you are actively working on that version)? All you need is the single revision number string and you can guarantee to get exactly that source code back at any time you want, should you need it. So you should only need at most one copy of the source in your regression testing system, and when you copy the binaries, just record which revision they were built from. R.
Re: Details for svn test repository
On Fri, 2005-02-11 at 17:20 +0100, Richard Guenther wrote: > On Fri, 11 Feb 2005 15:29:11 +, Joern RENNECKE > <[EMAIL PROTECTED]> wrote: > > Daniel Berlin wrote: > > > > > > > > > > >>Because svn keeps an extra pristine copy for checkouts, I'll have to use > > >>svn export for > > >>automatic regression tests. > > >> > > >> > > > > > >I don't understand why. > > >Is this because of the amount of space the working copy takes up? > > > > > > > > > > Yes. Sometimes stuff breaks and you don't notice it right away (E.g. > > because the > > feature is not automatically tested, or because of noise from other test > > failures). > > So it is useful to keep several month worth of test builds around. > > Doubling the > > amount of space taken up by this is not acceptable. > > If cp -Rl will not confuse svn, I honestly do not know if it will. If it does, and it's not too much of a hassle to make it *not* confuse svn, i'm sure they'll include such a feature if i coded it up. But someone would have to tell me what i need to code first :)
Re: Details for svn test repository
On Fri, 11 Feb 2005, Joern RENNECKE wrote: > revision numbers of the checkedout files, You mean the revision number of the whole checked out tree, which the "svnversion" utility will tell you in any checked out svn tree (including whether the tree is modified or mixed version). Given such a number, if you don't intend to do svn operations on that tree afterwards you can remove the .svn directories and reconstruct the checked out tree using the version number later. -- 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: GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
> -Original Message- > From: gcc-owner On Behalf Of Jonathan Wakely > Sent: 11 February 2005 16:34 > On Fri, Feb 11, 2005 at 04:38:03PM +0100, Sam Lauber wrote: > > > I think Intel's confusing numbering system has confused > > you. All ix86 processors, if the expression > > x in first ix86 < x in second ix86 > > holds true, then second ix86 is compatible. The i586 is > > NOT the Pentium. > > So why does the GCC manual say that -mtune=pentium is equivalent to > -mtune=i586 ? In terms of general terminology, it works like this. 'Pentium' refers to one cpu and one cpu only: the one introduced by Intel after the '486. i586 refers to all roughly-pentium-equivalent processors of that generation: the Pentium itself, the AMD K5, the Cyrix 586, etc. Likewise for i686 and Pentium Pro / K6 / Cyrix 686, etc. As to whether gcc uses the terms with precision, I cannot comment. But I would guess that the reason the two -mtune settings are the same is because gcc's scheduling and codegen decisions are not specialised for individual processors in the i586 category, but are generic to all of them. cheers, DaveK -- Can't think of a witty .sigline today
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
> > > >Because if it's a show stopper, then so will be arch, monotone, or any > >of our other replacements (they all either store the entire repo on your > >disk, or have stuff in the working copy), and we will be stuck with cvs > >until everyone is happy to use up double/whatever disk. > > > > > Actually, having one copy of the entire repository might be cheaper than > having > several dozen double checkouts. Yes, at some point the double space outruns the cost of the entire repo. For gcc, the cost of the entire repo is 4.4 gig right now. For your case, it might be cheaper to rsync the repo (unlike cvs, for each extra global revision to download, it's going to be 1 new file, and the old files won't be different. So it's going to be a *very fast* rsync), and export directly from that. > But then, having no firm, easilywaiting : memorized > revision numbers is certainly a much larger issue. I understand that > distributed > revision control systems would me ay iit much harder to refer to a particular > version. yeah, this is because they generally have some UUID or something as part of the revision number. >
Re: GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
On Fri, Feb 11, 2005 at 04:58:42PM -, Dave Korn wrote: > > -Original Message- > > From: gcc-owner On Behalf Of Jonathan Wakely > > Sent: 11 February 2005 16:34 > > > On Fri, Feb 11, 2005 at 04:38:03PM +0100, Sam Lauber wrote: > > > > > I think Intel's confusing numbering system has confused > > > you. All ix86 processors, if the expression > > > x in first ix86 < x in second ix86 > > > holds true, then second ix86 is compatible. The i586 is > > > NOT the Pentium. > > > > So why does the GCC manual say that -mtune=pentium is equivalent to > > -mtune=i586 ? > > In terms of general terminology, it works like this. > > 'Pentium' refers to one cpu and one cpu only: the one introduced by Intel > after the '486. > > i586 refers to all roughly-pentium-equivalent processors of that generation: > the Pentium itself, the AMD K5, the Cyrix 586, etc. > > Likewise for i686 and Pentium Pro / K6 / Cyrix 686, etc. True, I should have been clearer. I'm aware that "Pentium" (TM) != i586, but for the OP's purposes -mtune=pentium and -mtune=i586 are the same. Debating the difference between Pentium, pentium, i586 etc. is off-topic and that is what I was drawing attention to - GCC doesn't distinguish so the mail I replied to was unhelpful in making the distinction. jon -- "There is nothing noble in being superior to your fellow men - true nobility is being superior to your former self." - www.radiohead.com
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
On Fri, Feb 11, 2005 at 12:00:26PM -0500, Daniel Berlin wrote: > > > > > > > >Because if it's a show stopper, then so will be arch, monotone, or any > > >of our other replacements (they all either store the entire repo on your > > >disk, or have stuff in the working copy), and we will be stuck with cvs > > >until everyone is happy to use up double/whatever disk. > > > > > > > > Actually, having one copy of the entire repository might be cheaper than > > having > > several dozen double checkouts. > > Yes, at some point the double space outruns the cost of the entire repo. > For gcc, the cost of the entire repo is 4.4 gig right now. > For your case, it might be cheaper to rsync the repo (unlike cvs, for > each extra global revision to download, it's going to be 1 new file, and > the old files won't be different. So it's going to be a *very fast* > rsync), and export directly from that. Since I think this is a very important point, I'm going to contribute a couple of supporting statistics... The CVS repository is about 2.6GB. So, smaller than the subversion repository, but not by enough to bug me. Rsyncing it takes forever. Cvsup updating is very fast, however. I expect rsyncing the SVN repository to be comparably fast (less data transfered, less writing on client side, more reading on server side). A complete CVS checkout is 260MB, or about 10% of the repository. If you've just got the one checkout, the checkouts win. I've got a dozen right now; from what I've been hearing, svk would be the biggest win for me. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
Richard Earnshaw wrote: Why do you need to keep the source around at all (unless you are actively working on that version)? All you need is the single revision number string and you can guarantee to get exactly that source code back at any time you want, should you need it. Only while the server is up and running, in a sane state, and the internet connection to the server machine works all the way from here to there. Which is not all the time, I am afraid to say. Someone would also have to hack gdb to retrieve the source code via cvs/svn. Moreover, I often want just a quick look at the source, and a checkout has quite a long latency for that. And finally, sometimes bugs in the checkout process or changes in the modules file can cause strange build failures. If I don't keep around the sources axactly they were checked out, there is no guarantee that the build (or non-build) can be reproduced, and if it isn't reproducible because of a transient problem, the best way to start is to compare the sources of the original checkout with the new checkout... oops, you were just talking of not having these. So you should only need at most one copy of the source in your regression testing system, and when you copy the binaries, just record which revision they were built from. Huh? Why would I want to copy the binaries?
Re: Details for svn test repository
* Daniel Berlin:
>> You could be right, but I don't see how. Once you've set the revision
>> numbers, can you really go back and insert earlier revision numbers?
> Only by dumping and reloading.
Yes, but you don't want to do this as soon as revision numbers are
used in bug reports, mailing lists, and so on ("this was fixed in
r16432").
>> Once you've created revisions in which files are not renamed, can you
>> really insert the file renames?
>
> Only by dumping and reloading.
This should be possible without revision numbers, though.
Re: Details for svn test repository
Joseph S. Myers wrote: You mean the revision number of the whole checked out tree, which the "svnversion" utility will tell you in any checked out svn tree (including whether the tree is modified or mixed version). Given such a number, if you don't intend to do svn operations on that tree afterwards you can remove the .svn directories and reconstruct the checked out tree using the version number later. Is there an svn command to do that without doing a new checkout from the repository?
RE: GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
> -Original Message- > From: 'Jonathan Wakely' > Sent: 11 February 2005 17:06 > Debating the difference between Pentium, pentium, i586 etc. > is off-topic > and that is what I was drawing attention to - GCC doesn't > distinguish so > the mail I replied to was unhelpful in making the distinction. Apart from the fact that it is a unique enough occasion to have seen Sam post something technically accurate that it would be worthy of comment even if it was discussing butter-churning techniques, I think that if we refer back to the OP's question: > I was wondering why the above gcc parameter does not enable the use of the > fst/fld opcodes for pentium processors, while -march=i686 does. The Intel > manuals specifically say that they can be used across all pentium processors. it is entirely appropriate to point out that -march=i586 tunes the output to be suitable for a larger group of processors than just the intel ones. Therefore there may be additional constraints that the OP could not have deduced from reading the specs for the Intel manuals. Didn't the Cyrix series always have pretty poor FP support compared to the others? cheers, DaveK -- Can't think of a witty .sigline today
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
On Fri, 2005-02-11 at 17:11, Joern RENNECKE wrote: > Moreover, I often want just a quick look at the source, and a checkout > has quite > a long latency for that. It ought to be less bad for SVN than CVS, particularly for older code, and branches. Though I agree it's not going to be zero. > And finally, sometimes bugs in the checkout process or changes in the > modules file > can cause strange build failures. I'm not sure what SVN has in the way of modules support, but I'd be *very* surprised if anything it had wasn't version controlled, so this should be much less of a problem than it can be with CVS. > >So you should only need at most one copy of the source in your > >regression testing system, and when you copy the binaries, just record > >which revision they were built from. > > > > > > Huh? Why would I want to copy the binaries? > Sorry, I must have mis-understood. I thought you wanted to keep binaries of builds around so that you could work out quickly *when* a regression had been introduced, even if you hadn't tested a particular combination on that build originally. R.
Re: GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
On Fri, Feb 11, 2005 at 05:14:52PM -, Dave Korn wrote: > > -Original Message- > > From: 'Jonathan Wakely' > > Sent: 11 February 2005 17:06 > > > Debating the difference between Pentium, pentium, i586 etc. > > is off-topic > > and that is what I was drawing attention to - GCC doesn't > > distinguish so > > the mail I replied to was unhelpful in making the distinction. > > Apart from the fact that it is a unique enough occasion to have seen Sam > post > something technically accurate that it would be worthy of comment even if it > was > discussing butter-churning techniques, I think that if we refer back to the > OP's > question: > > > I was wondering why the above gcc parameter does not enable the use of the > > fst/fld opcodes for pentium processors, while -march=i686 does. The Intel > > manuals specifically say that they can be used across all pentium > > processors. > > it is entirely appropriate to point out that -march=i586 tunes the output to > be > suitable for a larger group of processors than just the intel ones. Therefore > there may be additional constraints that the OP could not have deduced from > reading the specs for the Intel manuals. True - I stand corrected. Maybe I reacted too quickly assuming the butter recipe was nonsense ;) > Didn't the Cyrix series always have pretty poor FP support compared to the > others? Thanks for the correction and extra info, jon -- "Anybody who hates dogs and loves whiskey can't be all bad." - W.C. Fields
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
Richard Earnshaw wrote: Huh? Why would I want to copy the binaries? Sorry, I must have mis-understood. I thought you wanted to keep binaries of builds around so that you could work out quickly *when* a regression had been introduced, even if you hadn't tested a particular combination on that build originally. R. Yes, I keep the binaries around, but I just leave them where they were built (till I eventually need to reclaim the space).
Re: Details for svn test repository
On Thursday, February 10, 2005, at 03:42 PM, Daniel Berlin wrote: On Thu, 2005-02-10 at 15:25 -0800, Mike Stump wrote: On Feb 9, 2005, at 8:54 PM, Daniel Berlin wrote: I also plan on excluding merge tags The last merge tag on active branches should be kept, as they would be used for the next merge?! Uh, you don't need a tag to merge anymore. How could it know what to merge? Take for example, the apple-ppc-branch for example.
Re: How to get m/c dependent attributes from RTL (expressions, not a variable)?
Balaji S wrote: 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. It depends on what you are doing, and you might need to write new code to be able to do it. See for instance TARGET_ENCODE_SECTION_INFO which is one common way of handling target dependent attributes. This is specifically for attributes that control which object file section a variable is placed in though, and probably not useful for other purposes. Also, I didn't mention it before, but if you are using current gcc sources, then depending on what you are doing, you might need to change how the gimple is emitted. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
RFC: PR 19910
This bug (which I just filed) is an ICE in the -ftree-loop-linear code.
It's expecting the
ssa-trees for different index variables in nested loops to refer to
different user variables.
In this case the different user variables have gotten coalesced by
copyrename2; this
happens only because they're inline copies:
/* Never attempt to coalesce 2 user variables unless one is an inline
variable. */
if (!ign1 && !ign2)
{
if (DECL_FROM_INLINE (root2))
ign2 = true;
else if (DECL_FROM_INLINE (root1))
ign1 = true;
else
{
if (debug)
fprintf (debug, " : 2 different USER vars. No coalesce.\n");
return;
}
}
Is tree-loop-linear correct to have this expectation?
What's the reason for not, in general, coalescing user variables? If
it's a correctness
issue the above is insufficient; but no other phase seems to mind.
Re: Details for svn test repository
On Thursday, February 10, 2005, at 06:13 PM, Richard Kenner wrote: I was concerned about the difficulty in building svn and must say that I wasn't at all encouraged by this report. I would instead, look to the people that know how to do it well, to post something up on the wiki pages on how to do it for a few common platforms. I need to do it for darwin, but have been putting it off, as it requires slightly more than no work. I think I just want to file a bug report against darwin to include it. :-)
Re: Moving to an alternate VCS
Chris Jefferson dixit: > As someone who just started submitting code, I'd say for a beginner the most > important features of the version control system are (in particular relating > to > CVS) 4) [svn] Get rid of the forced "ChangeLog" entry - writing (it's already the changeset's commit message) - formatting (can't that be done automagically?) - rotating (d'oh) I've always found the FSF's ChangeLog policy a bit weird (for CVS projects - for RCS projects it's understandable). bye, //mirabile -- > [...] Echtzeit hat weniger mit "Speed"[...] zu tun, sondern damit, daß der > richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt. Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...] weil selbst einfachste Operationen *echt* *Zeit* brauchen. (aus d.a.s.r)
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
On Fri, 2005-02-11 at 17:24 +, Richard Earnshaw wrote: > On Fri, 2005-02-11 at 17:11, Joern RENNECKE wrote: > > > Moreover, I often want just a quick look at the source, and a checkout > > has quite > > a long latency for that. > > It ought to be less bad for SVN than CVS, particularly for older code, > and branches. Though I agree it's not going to be zero. > > > And finally, sometimes bugs in the checkout process or changes in the > > modules file > > can cause strange build failures. > > I'm not sure what SVN has in the way of modules support, but I'd be > *very* surprised if anything it had wasn't version controlled, so this > should be much less of a problem than it can be with CVS. > It has svn:externals, which is more or less the modules file on crack. http://svnbook.red-bean.com/en/1.1/ch07s03.html (It properly updates the modules when thye need to be updated. The only thing that doesn't work is recursive commits through external repositories. You need to run commit in each dir seperately).
Re: Using up double diskspace for working copies (Was Re: Details for svn test repository)
On Fri, 2005-02-11 at 12:08 -0500, Daniel Jacobowitz wrote: > On Fri, Feb 11, 2005 at 12:00:26PM -0500, Daniel Berlin wrote: > > > > > > > > > > > >Because if it's a show stopper, then so will be arch, monotone, or any > > > >of our other replacements (they all either store the entire repo on your > > > >disk, or have stuff in the working copy), and we will be stuck with cvs > > > >until everyone is happy to use up double/whatever disk. > > > > > > > > > > > Actually, having one copy of the entire repository might be cheaper than > > > having > > > several dozen double checkouts. > > > > Yes, at some point the double space outruns the cost of the entire repo. > > For gcc, the cost of the entire repo is 4.4 gig right now. > > For your case, it might be cheaper to rsync the repo (unlike cvs, for > > each extra global revision to download, it's going to be 1 new file, and > > the old files won't be different. So it's going to be a *very fast* > > rsync), and export directly from that. > > Since I think this is a very important point, I'm going to contribute a > couple of supporting statistics... > > The CVS repository is about 2.6GB. 3200989 cvsfiles oh, wait, that includes wwwdocs and whatnot, sorry. > A complete CVS checkout is 260MB, or about 10% of the repository. If > you've just got the one checkout, the checkouts win. I've got a dozen > right now; from what I've been hearing, svk would be the biggest win > for me. > You can't mix svn and svk commits against the same repo. It confuses svk (not svn). You can use svk readonly, of course.
Re: Details for svn test repository
On Fri, 2005-02-11 at 17:13 +, Joern RENNECKE wrote: > Joseph S. Myers wrote: > > > > > > >You mean the revision number of the whole checked out tree, which the > >"svnversion" utility will tell you in any checked out svn tree (including > >whether the tree is modified or mixed version). Given such a number, if > >you don't intend to do svn operations on that tree afterwards you can > >remove the .svn directories and reconstruct the checked out tree using the > >version number later. > > > > > > Is there an svn command to do that without doing a new checkout from the > repository? > You mean tell you what the current version of the repo is? svnlook can do it, but it requires direct access to the repo. I could always make something that just prints out svnlook youngest to a socket and closes the connection (so you could netcat it or whatever), if that is what you need.
Re: Details for svn test repository
On Fri, 2005-02-11 at 11:19 -0800, Mike Stump wrote: > On Thursday, February 10, 2005, at 06:13 PM, Richard Kenner wrote: > > I was concerned about the difficulty in building svn and must say that > > I > > wasn't at all encouraged by this report. > > I would instead, look to the people that know how to do it well, to > post something up on the wiki pages on how to do it for a few common > platforms. I need to do it for darwin, but have been putting it off, > as it requires slightly more than no work. I think I just want to file > a bug report against darwin to include it. :-) Andrew pinski has reported there is on problem compiling it on darwin out of the box. >
Re: RFC: PR 19910
On Fri, 2005-02-11 at 11:17 -0800, Dale Johannesen wrote: > This bug (which I just filed) is an ICE in the -ftree-loop-linear code. > It's expecting the > ssa-trees for different index variables in nested loops to refer to > different user variables. It shouldn't be expecting this. and that's not where the ICE actually comes from. The real problem is that their is a linear offset generated in the transformed loop, and since this never triggered so far (we never made transforms that complex), i never added code to convert complex linear offsets back into gcc expressions. You just need to make lle_to_gcc_expression handle linear offsets, and everything will turn out okay.
Re: Details for svn test repository
On Fri, 2005-02-11 at 10:06 -0800, Mike Stump wrote: > On Thursday, February 10, 2005, at 03:42 PM, Daniel Berlin wrote: > > > On Thu, 2005-02-10 at 15:25 -0800, Mike Stump wrote: > >> On Feb 9, 2005, at 8:54 PM, Daniel Berlin wrote: > >>> I also plan on excluding merge tags > >> > >> The last merge tag on active branches should be kept, as they would be > >> used for the next merge?! > > > > Uh, you don't need a tag to merge anymore. > > How could it know what to merge? > Take for example, the > apple-ppc-branch for example. Find the current revision of the apple-ppc-branch using svn info on your checked out copy. >From your checked out copy of the apple ppc branch, type: "svn merge -r:HEAD svn://svn.toolchain.org/svn/gcc/trunk " That will merge in all the changes from the HEAD since the last time you merged. In general, you don't need a tag to merge, you just need the last global revision number for your current tree (unlike cvs, where you *have* to tag every file so you have a global set of revision numbers). There is actually a tool that automates this using properties so you don't need to remember anything at all, and also lets you cherry pick revisions if you want to. http://www.dellroad.org/svnmerge/index Even further automated history tracking is planned for future versions of subversion.
Re: Moving to an alternate VCS
On Fri, 11 Feb 2005, Thorsten Glaser wrote: > 4) [svn] Get rid of the forced "ChangeLog" entry >- writing (it's already the changeset's commit message) >- formatting (can't that be done automagically?) >- rotating (d'oh) > > I've always found the FSF's ChangeLog policy a bit weird > (for CVS projects - for RCS projects it's understandable). ChangeLog files are highly useful for doing a cvs update and then looking to see what changed recently - without noting the version number previously had, and that now had, to do a log of just the relevant part. Similarly they are useful in snapshots and releases. Automatic generation on checkout or similar doesn't suffice since svn doesn't version the log messages themselves - although in principle in a system with log messages being versioned you could allow all people with write access freely to fix typos in and otherwise correct log messages and derive ChangeLogs from the log messages at checkout/export. In practice there is a very stylised (but not universally followed) relation between log messages and ChangeLog entries; the header lines from the ChangeLog entries are included in the log message iff you're committing someone else's patch, and commits to multiple directories with separate ChangeLogs should indicate in the log message which ChangeLogs are involved. But the log message does not distinguish which of someone's multiple email addresses they are using in their ChangeLog entry. -- 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: Moving to an alternate VCS
On Fri, 2005-02-11 at 21:20 +, Joseph S. Myers wrote: > On Fri, 11 Feb 2005, Thorsten Glaser wrote: > > > 4) [svn] Get rid of the forced "ChangeLog" entry > >- writing (it's already the changeset's commit message) > >- formatting (can't that be done automagically?) > >- rotating (d'oh) > > > > I've always found the FSF's ChangeLog policy a bit weird > > (for CVS projects - for RCS projects it's understandable). > > ChangeLog files are highly useful for doing a cvs update and then looking > to see what changed recently - without noting the version number > previously had, and that now had, to do a log of just the relevant part. > Similarly they are useful in snapshots and releases. Automatic generation > on checkout or similar doesn't suffice since svn doesn't version the log > messages themselves - although in principle in a system with log messages > being versioned you could allow all people with write access freely to fix > typos in and otherwise correct log messages and derive ChangeLogs from the > log messages at checkout/export. The log messages are revision properties, so they don't really need to be versioned. [EMAIL PROTECTED]:~/trunk> svn propget --revprop -r HEAD svn:log Comment fix. * include/svn_client.h(svn_client_propget2): Refer to peg_revision->kind, not just peg_revision. [EMAIL PROTECTED]:~/trunk> svn propget --revprop -r 12964 svn:log Spanish translation updated. * subversion/po/es.po: Some translation updates. If you were to edit it, it would overwrite the property for that revision (which is what you want if you fix typos). So you could derive changelogs if you really wanted to. Anyway, the rest of your comment stands, however.
Re: Moving to an alternate VCS
On Fri, 11 Feb 2005, Daniel Berlin wrote: > If you were to edit it, it would overwrite the property for that > revision (which is what you want if you fix typos). It is not what you want when you want to be able to reproduce from the version control system the files that went into a particular release or snapshot, complete with the typos present in the log messages that went into that release's or snapshot's ChangeLogs. It is also not what you want to give free access to everyone to correct typos in log messages, when you want mistakes in so doing to be readily revertable. We do not however need to do anything different with ChangeLogs to change the version control system. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
3.4.3 C++ parsing bug?
Can someone verify that this is valid C++ before I submit a bug report:
// test.C
template class A {static T* c;};
class B : public A {};
B* A::c=0;
// end test.C
g++ -v -c test.C
Reading specs from /usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr/local/gcc343
--disable-threads
Thread model: single
gcc version 3.4.3
/usr/local/gcc343/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1plus -quiet -v
-D_GNU_SOURCE test.C -quiet -dumpbase test.C -mtune=pentiumpro -auxbase test
-version -o /tmp/cczC5foC.s
ignoring nonexistent directory
"/usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux
-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.
4.3
/usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.
4.3/i686-pc-linux-gnu
/usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.
4.3/backward
/usr/local/include
/usr/local/gcc343/include
/usr/local/gcc343/lib/gcc/i686-pc-linux-gnu/3.4.3/include
/usr/include
End of search list.
GNU C++ version 3.4.3 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.2.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=31994
test.C:7: error: too few template-parameter-lists
test.C:7: error: expected `,' or `;' before '=' token
Compilation exited abnormally with code 1 at Fri Feb 11 13:35:48
Thanks in advance
Jan N. Reimers (Ph.D.)
Manager, Materials Research
E-One Moli Energy (Canada) Ltd.
Re: 3.4.3 C++ parsing bug?
On Fri, 11 Feb 2005, Jan Reimers wrote:
> Can someone verify that this is valid C++ before I submit a bug report:
>
> // test.C
> template class A {static T* c;};
>
> class B : public A {};
>
> B* A::c=0;
> // end test.C
>
At least Comeau C++ 4.3.3 and Intel C++ 8.0 compile it and to me it also
looks ok, but I'm not at all C++ language lawer!
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
Re: 3.4.3 C++ parsing bug?
On Fri, Feb 11, 2005 at 01:53:23PM -0800, Jan Reimers wrote:
> Can someone verify that this is valid C++ before I submit a bug report:
>
> // test.C
> template class A {static T* c;};
>
> class B : public A {};
>
> B* A::c=0;
> // end test.C
It's not valid (though a number of compilers have accepted it in the
past); for template specializations you need template<>, and your
definition of A::c is a specialization.
Instead write
template<>
B* A::c = 0;
