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
> >
>
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 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
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, 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?
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 -
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.
> "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
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
> 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
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
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
> 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
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, 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
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 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
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 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 -
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 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
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 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
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 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
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
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 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
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
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.
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 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
>>> "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) )).
> > > > 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
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
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
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 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 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
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
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
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
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
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
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 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
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 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 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
> 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, 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
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, 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
> 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
57 matches
Mail list logo
