> git repack -a -d --depth=250 --window=250
>
Since I have the whole gcc repo locally I'll give this a shot overnight
just to see what can be done at the extreme end or things.
Harvey
On Thu, Dec 06, 2007 at 01:47:54AM -0500, Jon Smirl wrote:
> The key to converting repositories of this size is RAM. 4GB minimum,
> more would be better. git-repack is not multi-threaded. There were a
> few attempts at making it multi-threaded but none were too successful.
> If I remember right, w
On 12/6/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > While you won't get the git svn metadata if you clone the infradead
> > repo, it can be recreated on the fly by git svn if you want to start
> > commiting directly to gcc svn.
> >
> I will give this a try :)
Back when I was working on the Mo
On Thu, 6 Dec 2007, Daniel Berlin wrote:
>
> Actually, it turns out that git-gc --aggressive does this dumb thing
> to pack files sometimes regardless of whether you converted from an
> SVN repo or not.
Absolutely. git --aggressive is mostly dumb. It's really only useful for
the case of "I kno
> While you won't get the git svn metadata if you clone the infradead
> repo, it can be recreated on the fly by git svn if you want to start
> commiting directly to gcc svn.
>
I will give this a try :)
On Thu, 2007-12-06 at 00:11 -0500, Daniel Berlin wrote:
> On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Daniel Berlin" <[EMAIL PROTECTED]>
> > Date: Wed, 5 Dec 2007 23:32:52 -0500
> >
> > > On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > > > From: "Daniel Berlin" <[EMAIL PR
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 23:32:52 -0500
>
> > On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > > From: "Daniel Berlin" <[EMAIL PROTECTED]>
> > > Date: Wed, 5 Dec 2007 22:47:01 -0500
> > >
> > > > T
On Wed, 2007-12-05 at 20:54 -0800, Linus Torvalds wrote:
>
> On Wed, 5 Dec 2007, Harvey Harrison wrote:
> >
> > If anyone recalls my report was something along the lines of
> > git gc --aggressive explodes pack size.
> [ By default, for example, "git svn clone/fetch" seems to create those
> h
On Wed, 5 Dec 2007, Harvey Harrison wrote:
>
> If anyone recalls my report was something along the lines of
> git gc --aggressive explodes pack size.
Yes, --aggressive is generally a bad idea. I think we should remove it or
at least fix it. It doesn't do what the name implies, because it actua
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 23:32:52 -0500
> On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Daniel Berlin" <[EMAIL PROTECTED]>
> > Date: Wed, 5 Dec 2007 22:47:01 -0500
> >
> > > The size is clearly not just svn data, it's in the git pack itself.
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 22:47:01 -0500
>
> > The size is clearly not just svn data, it's in the git pack itself.
>
> And other users have shown much smaller metadata from a GIT import,
> and yes those ar
On Wed, 2007-12-05 at 20:20 -0800, David Miller wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 22:47:01 -0500
>
> > The size is clearly not just svn data, it's in the git pack itself.
>
> And other users have shown much smaller metadata from a GIT import,
> and yes th
I fought with this a few months ago when I did my own clone of gcc svn.
My bad for only discussing this on #git at the time. Should have put
this to the list as well.
If anyone recalls my report was something along the lines of
git gc --aggressive explodes pack size.
git repack -a -d --depth=100
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 22:47:01 -0500
> The size is clearly not just svn data, it's in the git pack itself.
And other users have shown much smaller metadata from a GIT import,
and yes those are including all of the repository history and branches
not just
Michael Meissner wrote:
One of the things that I've been interested in is adding support to GCC to
compile individual functions with specific target options. I first presented a
draft at the Google mini-summit, and then another draft at the GCC developer
summit last July.
...
The proposal is a
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 21:41:19 -0500
>
> > It is true I gave up quickly, but this is mainly because i don't like
> > to fight with my tools.
> > I am quite fine with a distributed workflow, I now use 8
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 21:41:19 -0500
> It is true I gave up quickly, but this is mainly because i don't like
> to fight with my tools.
> I am quite fine with a distributed workflow, I now use 8 or so gcc
> branches in mercurial (auto synced from svn) and m
On 12/5/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Daniel Berlin" <[EMAIL PROTECTED]>
> Date: Wed, 5 Dec 2007 14:08:41 -0500
>
> > So I tried a full history conversion using git-svn of the gcc
> > repository (IE every trunk revision from 1-HEAD as of yesterday)
> > The git-svn import was
From: "Daniel Berlin" <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 14:08:41 -0500
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I
Hi Bernhard,
Please open a gcc bug and assign it to me.
Thanks.
H.J.
---
On Wed, Dec 05, 2007 at 03:02:32PM +0100, Bernhard Fischer wrote:
> Hi,
>
> My libc is configured to omit any FP support (UCLIBC_HAS_FLOATS is not set)
> but the recent libbid updates seems to unconditionally pull in floa
Ben Elliston wrote:
Something else that hasn't been raised is that ChangeLogs can be
revised. We often see people making mistakes with their ChangeLog
entries, but since the ChangeLog is versioned, they can revise it. If
you screw up a commit message, it's much harder to fix it (and a purist
m
On Wed, 2007-12-05 at 18:35 -0500, Daniel Berlin wrote:
> svn propedit --revision svn:log
OK, well, it used to be a bit trickier in CVS .. :-)
Ben
> > > > Thanks for the quick response!
> > > > I'm sure it seems I like to make hard wok for myself! It gets worse,
> > > > I'm porting Gentoo Linux to iWMMXt with pure EABI kernel and
> > > > userspace. I'm not concerned about being able to run old binaries.
> > > > So is using abi=iwmmxt really
On Dec 5, 2007 1:40 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>
> > Out of curiosity, how much of that is the .git/svn directory? This is
> > where git-svn-specific data is stored. It is *very* inefficient, at
> > least for the 1.5.2.5 version I'm using.
> >
>
> I was only counting the space i
On Thu, 2007-12-06 at 00:34 +0100, Andreas Schwab wrote:
> Harvey Harrison <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2007-12-05 at 21:23 +0100, Samuel Tardieu wrote:
> >> > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
> >>
> >> Daniel> So I tried a full history conversion using git-s
On Dec 5, 2007 6:15 PM, Ben Elliston <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-12-04 at 09:18 -0700, Tom Tromey wrote:
>
> > First, continuing to have good quality messages. Right now at the
> > very least you get a (semi-) accurate record of what was touched.
> > I've seen plenty of ChangeLog-les
Harvey Harrison <[EMAIL PROTECTED]> writes:
> On Wed, 2007-12-05 at 21:23 +0100, Samuel Tardieu wrote:
>> > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>>
>> Daniel> So I tried a full history conversion using git-svn of the gcc
>> Daniel> repository (IE every trunk revision from 1-H
On Tue, 2007-12-04 at 09:18 -0700, Tom Tromey wrote:
> First, continuing to have good quality messages. Right now at the
> very least you get a (semi-) accurate record of what was touched.
> I've seen plenty of ChangeLog-less projects out there than end up with
> commits like "fixed a bug", or ev
On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc --aggressive -
Snapshot gcc-4.2-20071205 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071205/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Dec 05, 2007 at 04:32:00PM -0500, NightStrike wrote:
> On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > Patch manager will be dying for a week or two while i change hosting.
> >
> > of course, if nobody is still using it, i can just kill it permanently.
grep -F -e patchapp gcc-b
On 05 December 2007 21:04, Daniel Berlin wrote:
> Patch manager will be dying for a week or two while i change hosting.
>
> of course, if nobody is still using it, i can just kill it permanently.
Well I haven't submitted any patches just lately, but I always use it when I
do, I think it's very
On Wed, Mar 01, 2006 at 06:20:53PM +, Steven Newbury wrote:
> OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc
> and
> --disable-multilib. The vendor string is for my build scripts and also will
> help differentiate the toolchain, is that valid?
Yep.
--
Daniel Ja
On Wed, Dec 05, 2007 at 09:05:33AM -0500, Diego Novillo wrote:
> In my simplistic view of this problem, I've always had the idea that -O0
> -g means "full debugging bliss", -O1 -g means "tolerable debugging"
> (symbols shouldn't disappear, for instance, though they do now) and -O2
> -g means "yo
On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> As I said, maybe i'll look at git in another year or so.
> But i'm certainly going to ignore all the "git is so great, we should
> move gcc to it" people until it works better, while i am much more
> inclined to believe the "hg is so great, we
At revision 130629 regtesting on Intel Darwin9 gives a dozen
The process has forked and you cannot use this CoreFoundation functionality
safely. You MUST exec().
Break on
__THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
to debug.
then stop to do
On Wed, 2007-12-05 at 21:23 +0100, Samuel Tardieu wrote:
> > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> Daniel> So I tried a full history conversion using git-svn of the gcc
> Daniel> repository (IE every trunk revision from 1-HEAD as of
> Daniel> yesterday) The git-svn import w
On 12/5/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> > "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> Daniel> So I tried a full history conversion using git-svn of the gcc
> Daniel> repository (IE every trunk revision from 1-HEAD as of
> Daniel> yesterday) The git-svn import was d
On 12/5/07, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2007 11:08 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > So I tried a full history conversion using git-svn of the gcc
> > repository (IE every trunk revision from 1-HEAD as of yesterday)
> > The git-svn import was done using repacks
Boris Boesler <[EMAIL PROTECTED]> writes:
> I assume that GCC internals assume that memory can be byte (8 bits)
> addressed - for historical reasons.
No. gcc internals assume that memory can be addressed in units of
size BITS_PER_UNIT. The default for BITS_PER_UNIT is 8. I have
written back
On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> Patch manager will be dying for a week or two while i change hosting.
>
> of course, if nobody is still using it, i can just kill it permanently.
>
What is the patch manager?
> On GCC we use -gnato on tests known to need it
> (/gcc/testsuite/ada/acats/overflow.lst) since we want to test
> flags the typical GCC/Ada user does use and not what official validation
> requires (which is -gnato -gnatE IIRC).
But you're running a test that's *part* of the official validation a
Tony,
To configure common-logging to use JDK logger. Create a file named
"commons-loggin.properties" with the following:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
In a webapp this would go into WEB-INF/classes directory.
I'm not sure where to put it for the ro
> Richard, Arnaud, could you check amongst GNAT experts if for such types
> (non power of two modulus), it's not worth enabling overflow checks by
> default now that we have VRP doing non trivial optimisations? People
> using non power of two modulus are not caring for performance anyway, so
> havi
Patch manager will be dying for a week or two while i change hosting.
of course, if nobody is still using it, i can just kill it permanently.
> "Daniel" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Daniel> So I tried a full history conversion using git-svn of the gcc
Daniel> repository (IE every trunk revision from 1-HEAD as of
Daniel> yesterday) The git-svn import was done using repacks every
Daniel> 1000 revisions. After it finis
On 2007-11-27 18:29, Michael Eager wrote:
> Joseph S. Myers wrote:
> > On Tue, 27 Nov 2007, Michael Eager wrote:
> >
> >> I think that there is a pervasive understanding that SImode is
> >> single precision integer, 32-bits long.
> >
> > Only among contributors not considering non-8-bit bytes. SI
On Dec 5, 2007 11:08 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc -
Wednesday 05 December 2007 21:08:41 Daniel Berlin yazmıştı:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc --aggre
On 12/5/07, NightStrike <[EMAIL PROTECTED]> wrote:
> On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > I already have two way sync with hg.
> > Maybe someday when git is more usable than hg to a normal developer,
> > or it at least is significantly smaller than hg, i'll look at it
> > again.
On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> I already have two way sync with hg.
> Maybe someday when git is more usable than hg to a normal developer,
> or it at least is significantly smaller than hg, i'll look at it
> again.
Sorry, what is hg?
For the record:
[EMAIL PROTECTED]:/compilerstuff/gitgcc/gccrepo$ git --version
git version 1.5.3.7
(I downloaded it yesterday when i started the import)
On 12/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every tr
So I tried a full history conversion using git-svn of the gcc
repository (IE every trunk revision from 1-HEAD as of yesterday)
The git-svn import was done using repacks every 1000 revisions.
After it finished, I used git-gc --aggressive --prune. Two hours
later, it finished.
The final size after t
On 11/25/07 3:43 PM, Mark Mitchell wrote:
My suggestion (not as a GCC SC member or GCC RM, but just as a fellow
GCC developer with an interest in improving the compiler in the same way
that you're trying to do) is that you stop writing code and start
writing a paper about what you're trying to d
Hi,
My libc is configured to omit any FP support (UCLIBC_HAS_FLOATS is not set)
but the recent libbid updates seems to unconditionally pull in floatingpoint
accessor functions thus breaking bootstrap. My notes on this read:
8<
Follows:
Precedes:
do not pull in allegedly unn
On 12/5/07, Jan Beulich <[EMAIL PROTECTED]> wrote:
> >>> "Andrew Pinski" <[EMAIL PROTECTED]> 25.11.07 19:45 >>>
> >On 11/25/07, Luca <[EMAIL PROTECTED]> wrote:
> >> 7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
> >> to allow 64-bit pointers in 32-bit mode and viceversa
> >
>
>>> "Andrew Pinski" <[EMAIL PROTECTED]> 25.11.07 19:45 >>>
>On 11/25/07, Luca <[EMAIL PROTECTED]> wrote:
>> 7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
>> to allow 64-bit pointers in 32-bit mode and viceversa
>
>This is already there, try using __attribute__((mode(DI) )).
57 matches
Mail list logo
