On Sat, 3 Feb 2007, Gerald Pfeifer wrote:
>> I'd be curious to know the effect of removing the "complexity" field of
>> struct tree_exp.
> Doesn't work:
>
> trunk/gcc/cp/pt.c: In function 'tsubst_expr':
> trunk/gcc/cp/pt.c:8924: error: 'struct tree_exp' has no member named
> 'complexity'
Th
Tom Tromey wrote:
"Marco" == Marco Trudel <[EMAIL PROTECTED]> writes:
Marco> If it takes about 30 to 40min to build this html/parser.o and
Marco> gnu-xml.o needs about 1 or 2 minutes but is - last time I took a look
Marco> - a lot bigger than the html parser, shouldn't then be investigated
Marc
On Fri, 2 Feb 2007, Paolo Bonzini wrote:
> I'd be curious to know the effect of removing the "complexity" field of
> struct tree_exp. It should be possible to bootstrap C/C++/Java/Fortran
> with a two line patch removing the field from tree.h, and the only
> reference to it in tree.c (via the m
Still, this shows that we did have an increase in memory use recently,
which may be worth looking into. (And, of course, I'm happily testing
Tom's patch as we speak.)
I'd be curious to know the effect of removing the "complexity" field of
struct tree_exp. It should be possible to bootstrap
On Thu, 1 Feb 2007, Gerald Pfeifer wrote:
> The tester where this problem first surfaced as a 32-bit Athlon machine,
> with 512MB main memory and 1GB swap. The machine runs FreeBSD 5.4.
>
> I agree with your intuition that even if the machines is swapping heavily,
> this amount of virtual memory
>
> On Wed, 31 Jan 2007, Andrew Haley wrote:
> > Can you tell us a bit more about the config? It really shouldn't be
> > failing to compile this program.
>
> The tester where this problem first surfaced as a 32-bit Athlon machine,
> with 512MB main memory and 1GB swap. The machine runs FreeBSD
On Wed, 31 Jan 2007, Andrew Haley wrote:
> Can you tell us a bit more about the config? It really shouldn't be
> failing to compile this program.
The tester where this problem first surfaced as a 32-bit Athlon machine,
with 512MB main memory and 1GB swap. The machine runs FreeBSD 5.4.
I agree w
> "Marco" == Marco Trudel <[EMAIL PROTECTED]> writes:
Marco> If it takes about 30 to 40min to build this html/parser.o and
Marco> gnu-xml.o needs about 1 or 2 minutes but is - last time I took a look
Marco> - a lot bigger than the html parser, shouldn't then be investigated
Marco> why this htm
Tom Tromey wrote:
"Benjamin" == Benjamin Kosnik <[EMAIL PROTECTED]> writes:
Benjamin> but I am
Benjamin> somewhat concerned with the response of the java maintainers (and
Benjamin> others) that it's OK to require >512MB to bootstrap gcc with java, or
Benjamin> that make times "WORKSFORME."
My
> "Benjamin" == Benjamin Kosnik <[EMAIL PROTECTED]> writes:
Benjamin> but I am
Benjamin> somewhat concerned with the response of the java maintainers (and
Benjamin> others) that it's OK to require >512MB to bootstrap gcc with java, or
Benjamin> that make times "WORKSFORME."
My proposal was mo
> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
Gerald> Ouch. I can confirm that on a 32-bit box of mine it fails with about
Gerald> 500MB of main memory.
It is interesting that it is the HTML parser that is causing
problems. For me, gnu-xml.lo is usually the awful one.
Does that o
Marcin Dalecki wrote:
512MB is *certainly* resonable. It's the most common amount of
shipping RAM
for in esp. notebooks and it's what usually get's allocated to
virtualization
solutions.
I agree 512M is reasonable (really a compiler taking more than
half a gigabyte for any normal sources i
Wiadomość napisana w dniu 2007-01-31, o godz12:50, przez Andrew Haley:
Benjamin Kosnik writes:
I am somewhat concerned with the response of the java maintainers
(and others) that it's OK to require >512MB to bootstrap gcc with
java, or that make times "WORKSFORME."
Well, I didn't say that,
Benjamin Kosnik writes:
>
> I am somewhat concerned with the response of the java maintainers
> (and others) that it's OK to require >512MB to bootstrap gcc with
> java, or that make times "WORKSFORME."
Well, I didn't say that, so I hope you aren't referring to me. But
before we do anything
On Wed, Jan 31, 2007 at 11:42:12AM +, Andrew Haley wrote:
> Andrew Haley writes:
> > >
> > > It does look like we are scaring away some people with the long
> > > build times and memory hungry build of libjava. I only started
> > > building libgcj again recently when I got a
> > > 3G
May I respectfully point out that the gcc make process already has
hard-coded hackery to work around the limitations of certain machines,
oses, non-GNU makes, linkers, and assembers, etc? (The thing that comes
to mind is the 42 item limit for make rules on AIX: see
libstdc++-v3/include/Makefi
Andrew Haley writes:
> >
> > It does look like we are scaring away some people with the long
> > build times and memory hungry build of libjava. I only started
> > building libgcj again recently when I got a
> > 3Ghz/64-bit/dual-core/2GB machine. And even on that box an
> > compile/ins
Mark Wielaard writes:
> On Tue, 2007-01-30 at 12:55 -0700, Tom Tromey wrote:
> > > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > Andrew> Anyway, I tried again, this time with the right file, and it took
> > Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgda
Le Wed, Jan 31, 2007 at 09:45:04AM +, Andrew Haley écrivait/wrote:
>
> I'd want a bit more information. There's no reason that a 512M box
> couldn't cope with a 550M process. Sure, it'll be slow, but it should
> still work, and this is an extreme case. If there is to be a maximum
> process
On Tue, 2007-01-30 at 12:55 -0700, Tom Tromey wrote:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> Anyway, I tried again, this time with the right file, and it took
> Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
> 0maxresident)k
> Andrew> and in
Gerald Pfeifer writes:
> On Tue, 30 Jan 2007, Andrew Haley wrote:
> > 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
> > 0maxresident)k
> >
> > and indeed, it does want a lot of memory - at peak some 550m. It'll
> > be smaller on a 32-bit box, but not much smaller.
>
> Ou
Tom Tromey writes:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> Anyway, I tried again, this time with the right file, and it took
> Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
> 0maxresident)k
> Andrew> and indeed, it does want a lot of
Anyway, I tried again, this time with the right file, and it took
78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
and indeed, it does want a lot of memory - at peak some 550m. It'll
be smaller on a 32-bit box, but not much smaller.
I want to get rid of TREE_COMP
Gerald Pfeifer wrote:
On Tue, 30 Jan 2007, Andrew Haley wrote:
78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
and indeed, it does want a lot of memory - at peak some 550m. It'll
be smaller on a 32-bit box, but not much smaller.
Ouch. I can confirm that on a 32-
On Tue, 30 Jan 2007, Andrew Haley wrote:
> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
>
> and indeed, it does want a lot of memory - at peak some 550m. It'll
> be smaller on a 32-bit box, but not much smaller.
Ouch. I can confirm that on a 32-bit box of mine it
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
Andrew> Anyway, I tried again, this time with the right file, and it took
Andrew> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata
0maxresident)k
Andrew> and indeed, it does want a lot of memory - at peak some 550m. It'll
An
Marco Trudel writes:
> Andrew Haley wrote:
> > Gerald Pfeifer writes:
> > > I can no longer build libjava on a machine with "just" 512MB of main
> > > memory (FreeBSD/i386 5.4 in this case).
> > >
> > > Three weeks ago the build worked on that very machine; did we raise
> > > our mini
Andrew Haley wrote:
Gerald Pfeifer writes:
> I can no longer build libjava on a machine with "just" 512MB of main
> memory (FreeBSD/i386 5.4 in this case).
>
> Three weeks ago the build worked on that very machine; did we raise
> our minimum requirements
We just imported a whole new rele
Gerald Pfeifer writes:
> I can no longer build libjava on a machine with "just" 512MB of main
> memory (FreeBSD/i386 5.4 in this case).
>
> Three weeks ago the build worked on that very machine; did we raise
> our minimum requirements
We just imported a whole new release of the Classpath li
I can no longer build libjava on a machine with "just" 512MB of main
memory (FreeBSD/i386 5.4 in this case).
Three weeks ago the build worked on that very machine; did we raise
our minimum requirements or is this simply a bug?
Gerald
echo
/sw/test/GCC/trunk/libjava/classpath/lib/gnu/javax/swin
30 matches
Mail list logo
