gcc/unwind-pe.h broken
Hello Andreas Your latest patch to unwind-pe.h breaks at least canadian cross-compilation host=mingw target=mingw: In file included from /usr/local/src/gcc/libgcc/../gcc/unwind-dw2.c:40: /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:133: error: expected declaration specifiers or '...' before '_uleb128_t' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h: In function 'read_uleb128': /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:137: error: '_uleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:137: error: (Each undeclared identifier is reported only once /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:137: error: for each function it appears in.) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:137: error: expected ';' before 'result' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:139: error: 'result' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:143: error: expected ')' before 'byte' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:148: error: 'val' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h: At top level: /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:155: error: expected declaration specifiers or '...' before '_sleb128_t' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h: In function 'read_sleb128': /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:159: error: '_uleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:159: error: expected ';' before 'result' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:161: error: 'result' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:165: error: expected ')' before 'byte' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:172: error: expected ')' before numeric constant /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:174: error: 'val' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:174: error: '_sleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:174: error: expected ';' before 'result' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h: In function 'read_encoded_value_with_base': /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:218: error: '_uleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:218: error: expected ';' before 'tmp' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:219: error: 'tmp' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:219: error: too many arguments to function 'read_uleb128' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:226: error: '_sleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:226: error: expected ';' before 'tmp' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:227: error: too many arguments to function 'read_sleb128' Marco
Re: gcc/unwind-pe.h broken
Marco Trudel wrote: Hello Andreas Your latest patch to unwind-pe.h breaks at least canadian cross-compilation host=mingw target=mingw: In file included from /usr/local/src/gcc/libgcc/../gcc/unwind-dw2.c:40: /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:133: error: expected declaration specifiers or '...' before '_uleb128_t' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h: In function 'read_uleb128': /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:137: error: '_uleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:137: error: (Each undeclared identifier is reported only once /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:137: error: for each function it appears in.) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:137: error: expected ';' before 'result' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:139: error: 'result' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:143: error: expected ')' before 'byte' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:148: error: 'val' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h: At top level: /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:155: error: expected declaration specifiers or '...' before '_sleb128_t' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h: In function 'read_sleb128': /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:159: error: '_uleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:159: error: expected ';' before 'result' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:161: error: 'result' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:165: error: expected ')' before 'byte' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:172: error: expected ')' before numeric constant /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:174: error: 'val' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:174: error: '_sleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:174: error: expected ';' before 'result' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h: In function 'read_encoded_value_with_base': /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:218: error: '_uleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:218: error: expected ';' before 'tmp' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:219: error: 'tmp' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:219: error: too many arguments to function 'read_uleb128' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:226: error: '_sleb128_t' undeclared (first use in this function) /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:226: error: expected ';' before 'tmp' /usr/local/src/gcc/libgcc/../gcc/unwind-pe.h:227: error: too many arguments to function 'read_sleb128' Addition: I had to revert the changes of these files to make the build work again: - gcc/unwind-pe.h - libstdc++-v3/libsupc++/eh_personality.cc - libjava/exception.cc - gcc/unwind-c.c - gcc/unwind-dw2-fde.c I can try patches if you need to verify them. thanks Marco
Re: Failure to build libjava on 512MB machine
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 release of the Classpath library, and it's big. But that doesn't explain this bug. You mean 0.93, right? > or is this simply a bug? I think so. javax/swing/text/html/parser is quite small: $ /usr/bin/time make javax/swing/text/html/parser.lo What? No way! I always thought this must be something about 7gb or so. Compiling my canadian cross mingw takes 2h. 40min to 50min is spend for compiling html/parser... I think a linux normal build (static, 32bit) also needs about 2h. A cross host=mingw target=linux took only 50min to my surprise. 0.53user 0.16system 0:00.74elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+26369minor)pagefaults 0swaps $ ls -lh javax/swing/text/html/.libs/parser.o -rw-r--r-- 1 aph aph 260K Jan 30 11:44 javax/swing/text/html/.libs/parser.o I don't know why it is using so much memory in your case. I assume is has something to do with optimization. - I noticed myself that I can't compile some jars on mingw (Waited an hour) while it just took a few minutes on Linux (cross to mingw) - A user of my builds reported also out of memory exceptions with recent gcc builds when optimization is used - someone made a java or libjava bugreport about that Marco > Gerald > > echo /sw/test/GCC/trunk/libjava/classpath/lib/gnu/javax/swing/text/html/parser/*.class > gnu/javax/swing/text/html/parser.list > /bin/sh ./libtool --mode=compile /files/pfeifer/OBJ-0129-2308/gcc/gcj -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o gnu/javax/swing/text/html/parser.lo -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list > /files/pfeifer/OBJ-0129-2308/gcc/gcj -B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ -B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer -fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list -fPIC -o gnu/javax/swing/text/html/.libs/parser.o > jc1: out of memory allocating 4072 bytes after a total of 536273352 bytes > gmake[3]: *** [gnu/javax/swing/text/html/parser.lo] Error 1 > gmake[3]: Leaving directory `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' > gmake[2]: *** [all-recursive] Error 1 > gmake[2]: Leaving directory `/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava' > gmake[1]: *** [all-target-libjava] Error 2 > gmake[1]: Leaving directory `/files/pfeifer/OBJ-0129-2308' > gmake: *** [bootstrap-lean] Error 2
Re: Failure to build libjava on 512MB machine
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-bit box of mine it fails with about 500MB of main memory. I also only have 500mb on my building box... On Tue, 30 Jan 2007, Tom Tromey wrote: I suppose with some awful build hacking we could split this .o into multiple parts. I'm fine with the situation as it is, myself, but I will do this if the consensus is that we should. Please, pleeease. This really hurts. No I can no longer build libgcj on my notebook and one or two older (but not that old) testers of mine. For me it's fine too... Gerald, what about using a bigger swap partition? Marco
Re: Failure to build libjava on 512MB machine
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 proposal was more that, if it "WORKSFORUS", then I wouldn't bother hacking on the build. Build hacking is unpleasant and I am somewhat motivated to avoid it. Anyhow, I'm testing a patch for this case. And, this will make it a bit simpler to split other objects should it be needed. Aren't you here solving the wrong problem? The problem that is caused by the real problem? If it takes about 30 to 40min to build this html/parser.o and gnu-xml.o needs about 1 or 2 minutes but is - last time I took a look - a lot bigger than the html parser, shouldn't then be investigated why this html parser is such a hard thing? Otherwise there might just come another object after some changes with the same problem... Marco
Re: Failure to build libjava on 512MB machine
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 Marco> why this html parser is such a hard thing? It is just a really big file. I think there's more than that. Way bigger files need way less time to compile... If it still takes too much memory to compile, I suppose I, or someone (hint, hint), will look at how to shrink it. Makefile has been updated to split the compilation, right? I just compiled a rev 121540 and still, htmp/parser[FOOBAR].o takes way over 30min. A good example is also to compile ecj.jar. It can need from 1min to way over 30min, depending on the gcj. I'll try some test compilations and send statistics as soon as my machine is free for some extra work. This might be a x86, 32bit, static gcj or whatever problem only. But optimization seems to be involved... Marco
Re: [RFA] Boehm GC support addition for debugging
I already sent a patch for that to the java-patches list... Andreas Tobler wrote: Andrew Pinski wrote: On Jun 26, 2006, at 10:02 PM, Andrew Pinski wrote: On Jun 26, 2006, at 9:01 AM, Bryce McKinlay wrote: Otherwise, this is fine. No it is not, it broke bootstrap on powerpc-darwin: Did you look when the function would have been declared. From gc.h: #if defined(GC_PTHREADS) && !defined(GC_SOLARIS_THREADS) \ && !defined(GC_WIN32_THREADS) && !defined(GC_DARWIN_THREADS) GC_API void GC_suspend_thread GC_PROTO((pthread_t)); GC_API void GC_resume_thread GC_PROTO((pthread_t)); #endif So this is not just Darwin but also Windows and maybe solaris too. Solaris too. :( I'd wish being a bit more careful with such patches. Everyone can ask for RFT and I'll happily test on my farm as time permits. Andreas P.S, Me being a _spare_ time contributor
