RE: gcj/sparc64?
Thanks. While I have an easy repro, it's less easy to repro with any "onion peeling" or logging. For a while I was avoiding the problem via -enable-languages=c,c++. This command is what fails (but not always) /obj/gcc.1/i686-pc-cygwin/sparc64-sun-solaris2.10/gcc/jc1.exe /src/gcc/libjava/ classpath/lib/gnu/javax/swing/text/html/parser/HTML_401F.class -fuse-divide-subr outine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -quiet -dumpbas e HTML_401F.class -mcpu=v9 -auxbase-strip gnu/javax/swing/text/html/parser/HTML_ 401F.o -g -O2 -Wno-deprecated -version -fencoding=UTF-8 -fbootstrap-classes -fso urce-filename=/obj/gcc.1/i686-pc-cygwin/sparc64-sun-solaris2.10/sparc64-sun-sola ris2.10/libjava/classpath/lib/classes -fbootclasspath=./:/src/gcc/libjava/classp ath/lib/ -faux-classpath /d/DOCUME~1/jay/LOCALS~1/Temp/cciZj3jk.zip -MD_ -MT gnu /javax/swing/text/html/parser/HTML_401F.lo -MF gnu/javax/swing/text/html/parser/ HTML_401F.deps -o /d/DOCUME~1/jay/LOCALS~1/Temp/ccqOtWtu.s output is: GNU Java (GCC) version 4.3.1 (sparc64-sun-solaris2.10) compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Class path starts here: /d/DOCUME~1/jay/LOCALS~1/Temp/cciZj3jk.zip/ (zip) ./ (system) /src/gcc/libjava/classpath/lib/ (system) /src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java: In c lass 'gnu.javax.swing.text.html.parser.HTML_401F': /src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java: In m ethod 'gnu.javax.swing.text.html.parser.HTML_401F.defineElements()': /src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java:0: in ternal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. and then here it is under a debugger: Program received signal SIGSEGV, Segmentation fault. 0x008fc34a in htab_mod (hash=7818600, htab=0x27b75c8) at /src/gcc/libiberty/hashtab.c:270 270 return htab_mod_1 (hash, p->prime, p->inv, p->shift); (gdb) bt #0 0x008fc34a in htab_mod (hash=7818600, htab=0x27b75c8) at /src/gcc/libiberty/hashtab.c:270 #1 0x008fc752 in htab_find_slot_with_hash (htab=0x27b75c8, element=0x330a0, hash=7818600, insert=INSERT) at /src/gcc/libiberty/hashtab.c:624 #2 0x008fc8fc in htab_find_slot (htab=0x27b75c8, element=0x330a0, insert=INSERT) at /src/gcc/libiberty/hashtab.c:678 #3 0x006ce782 in get_def_blocks_for (var=0x3ba6b40) at /src/gcc/gcc/tree-into-ssa.c:466 #4 0x006d2d78 in mark_use_interesting (var=0x3ba6b40, stmt=0x7c0ec6a0, bb=0x79a11300, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2375 #5 0x006d2bb8 in prepare_block_for_update (bb=0x79a11300, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2448 #6 0x006d2cec in prepare_block_for_update (bb=0x79a11280, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #7 0x006d2cec in prepare_block_for_update (bb=0x79a111c0, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #8 0x006d2cec in prepare_block_for_update (bb=0x79a110c0, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #9 0x006d2cec in prepare_block_for_update (bb=0x79a11040, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #10 0x006d2cec in prepare_block_for_update (bb=0x79a10f80, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #11 0x006d2cec in prepare_block_for_update (bb=0x79a10e80, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #12 0x006d2cec in prepare_block_for_update (bb=0x79a10e00, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #13 0x006d2cec in prepare_block_for_update (bb=0x79a10d40, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #14 0x006d2cec in prepare_block_for_update (bb=0x79a10c40, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #15 0x006d2cec in prepare_block_for_update (bb=0x79a10bc0, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #16 0x006d2cec in prepare_block_for_update (bb=0x79a10b00, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #17 0x006d2cec in prepare_block_for_update (bb=0x79a10a00, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #18 0x006d2cec in prepare_block_for_update (bb=0x79a10980, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #19 0x006d2cec in prepare_block_for_update (bb=0x79a108c0, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #20 0x006d2cec in prepare_block_for_update (bb=0x79a107c0, ... ... pages and pages ... ... #9950 0x006d2cec in prepare_block_for_update (bb=0x7c82e7c0, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #9951 0x006d2cec in prepare_block_for_update (bb=0x7c82e740, insert_phi_p=1 '\001') at /src/gcc/gcc/tree-into-ssa.c:2464 #9952 0x006d2cec in prepare_block_for_update (bb=0x7c82e6c0, insert_phi
Re: gcj/sparc64?
Jay wrote: > /src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java:0: > in > ternal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. This stack exhaustion is PR36218 which was supposedly fixed on mainline. Two problems: the fix needs to be extended to Cygwin as well as MinGW, and you're not building mainline. > I wish Windows code was PIC, then wouldn't worry about base addresses and > the cost of relocs.. (even if AMD64 is mostly PIC, the data still isn't, e.g. > vtables). With --enable-auto-image-base this becomes nearly a non-issue. Libtool has been enabling that by default on PE for a long time. There was also a patch several years ago to support a variant of ELF-style PIC on Windows, but it was never reviewed nor commented on. The ABI implications probably make this infeasible anyway. In any case this has zero to do with the topic of this thread. Brian
RE: gcj/sparc64?
> From: brian@ >> > This stack exhaustion is PR36218 which was supposedly fixed on > mainline. Two problems: the fix needs to be extended to Cygwin as well > as MinGW, and you're not building mainline. > >> I wish Windows code was PIC > > zero to do with the topic of this thread. I agree it's a tangent. It seems the PIC compilation succeeds. The whole thing where things get compiled twice, PIC and non-PIC, bugs me. It's a "great" way to slow down builds. I guess configure -only-pic might be nice. I understand the results, if only linked into an executabe, might be slower. Picking a base address that might not conflict with other code/data doesn't eliminate the problem, just reduces it, and a cost of random burning of address space. (I don't know the algorithm, "random" isn't the right word). If the code/data were really PIC, it could be tightly packed. Thanks. I'm trying it out with an 8meg stack like was applied to mingwin. I believe Solaris hosts need a fix here too. And djgpp. And perhaps others. AIX? Irix? HP-UX? *BSD? Or most systems default to 8 or 32meg? Not worth changing the gcc code to reduce or eliminate the recursion? - Jay
Re: gcj/sparc64?
Jay <[EMAIL PROTECTED]> writes: > I guess configure -only-pic might be nice. It's spelled --with-pic. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
[wwwdocs] PATCH for Re: New mirror GCC at FPT Telecom
On Tue, 29 Jul 2008, [EMAIL PROTECTED] wrote: > We have set up a new mirror. This is our information: > > URL: >- http://mirror-fpt-telecom.fpt.net/gcc/ >- ftp://mirror-fpt-telecom.fpt.net/mirror/gcc/ > > Location: >- Company: FPT Telecom >- City: HoChiMinh >- Country: Viet Nam > > Contact: >- Name: Minh Vu Tong >- email: [EMAIL PROTECTED] Thanks you very much for setting up a mirror and letting us know (with all the information provided). I updated our official mirror list with the patch below. I refrained from also adding the ftp:// URL which always reset the connection when I tested, whereas the http:// URL worked fine. Please let me know if there are any updates or anything else we should consider. Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.181 diff -u -3 -p -r1.181 mirrors.html --- mirrors.html27 Jun 2008 10:53:13 - 1.181 +++ mirrors.html10 Aug 2008 22:48:55 - @@ -51,6 +51,7 @@ Key fingerprint = 90AA 4704 69D3 965A 87 US, Virginia: ftp://mirrors.rcn.net/pub/sourceware/gcc/";>mirrors.rcn.net (also available via http://mirrors.rcn.net/pub/sourceware/gcc/";>http) US, St. Louis (no snapshots): ftp://mirrors.laffeycomputer.com/pub/gcc.gnu.org/pub/gcc/";>mirrors.laffeycomputer.com, thanks to mirrormaster at laffey dot biz US, Texas: http://gcc.releasenotes.org";>gcc.releasenotes.org, thanks to Alex Korolev (alex at releasenotes dot org) +Viet Nam, HoChiMinh: http://mirror-fpt-telecom.fpt.net/gcc/";>http://mirror-fpt-telecom.fpt.net/gcc/, thanks to Minh Vu Tong (mirror at fpt dot net) If you wish to host a new mirror site, please contact
Java Development with GCJ
Hello -- I am acting for a friend with a java application who needs to run it on a microcontroller. Though aware of GC, I only recently learned of GCJ. Accordingly, I am looking for developer resources using GCJ for microcontrollers. Anyone, manufacturer, developer, or hobbyist who has put forward the effort to define the microcontroller hardware for GCJ so that effective compilation may be done. Additionally, since one of the main show stoppers is the Java class libraries, I would also be interested in any efforts to convert the class libraries, on some basis, for microcontroller usage. Clearly this cannot be a direct compilation in all cases, especially for graphics, but any such activity may beat starting from square one. Thanks for your time and attention. Daniel B. Davis (301) 587-4207
Re: Java Development with GCJ
On Sun, Aug 10, 2008 at 6:28 PM, Daniel B. Davis <[EMAIL PROTECTED]> wrote: > Hello -- > > I am acting for a friend with a java application who needs to run it on a > microcontroller. Though aware of GC, I only recently learned of GCJ. > > Accordingly, I am looking for developer resources using GCJ for > microcontrollers. Anyone, manufacturer, developer, or hobbyist who has put > forward the effort to define the microcontroller hardware for GCJ so that > effective compilation may be done. > It depends on the microcontroller. If it is well supported by GCC and runs Linux and glibc, then if GCJ/libgcj are not already working it would be fairly simple to get it working. If it does not meet these criteria, then it may be more difficult. > Additionally, since one of the main show stoppers is the Java class > libraries, I would also be interested in any efforts to convert the class > libraries, on some basis, for microcontroller usage. Clearly this cannot be > a direct compilation in all cases, especially for graphics, but any such > activity may beat starting from square one. > GCC ships with a fairly complete java runtime library (libgcj). David Daney
