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 wr
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
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
proble
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
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 pristi
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,
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
> h
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 answ
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 t
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 operati
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 pro
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,
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 mac
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 funct
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 rig
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 F
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 am
__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 preven
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
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. Bu
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
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
> `l
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 th
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 re
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
> distribut
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
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 nu
> -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
>
>
> >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.
> >
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 c
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 stuc
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
* 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 list
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
> -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 dis
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.
> An
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
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 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
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_SE
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
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 d
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 mess
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 o
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
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).
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 kno
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
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 me
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
>
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
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 r
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/config
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
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 ac
55 matches
Mail list logo
