Problem on Front-End List Page
To the GCC team, Many IDEs other than the ones that you list on your page of front-ends to GCC compiler exist. One such IDE is XCode 3.1.3, which is developed by Apple, Inc. From a Visitor to Your Website
Re: GCC 4.0 RC1 Available
Mark Wielaard wrote:
On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote:
Try compiling to native:
$ gcj -o CL CL.java --main=CL
$ CLASSPATH=.:/:/usr:/random ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Aha. Thanks. As a workaround you can use the GCJ_PROPERTIES environment
variable for now:
GCJ_PROPERTIES='java.class.path=../..' ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:../../],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
I am looking for a real solution.
It looks like this was caused by this patch:
2005-04-01 Thomas Fitzsimmons <[EMAIL PROTECTED]>
PR libgcj/20090, PR libgcj/20526
* gij.cc (nonstandard_opts_help): New function.
(add_option): New function.
(main): Support java options. Set java.class.path. Don't set
_Jv_Jar_Class_Path.
...
Tom is working on a solution.
Regards
Bryce
Re: [rfc] mainline slush
Was this not fixed by: 2005-05-18 Paolo Bonzini <[EMAIL PROTECTED]> * Makefile.am (Makefile.deps): Do not use \0, it is unportable. * Makefile.in: Regenerate. ? Bryce David Daney wrote: Perhaps sending this to java-patches will help... Mike Stump wrote: On May 19, 2005, at 10:11 AM, Mark Mitchell wrote: Nobody's objected, and it's fine by me. So, let's do it. Ping. I kinda wish someone would review the libjava breakage patch for darwin... http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01821.html otherwise, I don't see the point in slushing to fix things.
Re: Java bootstrap fails compiling libjava
I've just done an x86_64 build of HEAD and didn't see this error. Bryce Richard Guenther wrote: On x86_64 I see /net/pherkad/scratch/rguenth/gcc-obj/./gcc/gcj -B/net/pherkad/scratch/rguenth/gcc-obj/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include --encoding=UTF-8 -Wno-deprecated -C -g -classpath '' -bootclasspath /net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libjava':'/net/pherkad/scratch/rguenth/gcc/libjava':'/net/pherkad/scratch/rguenth/gcc/libjava/external/w3c_dom':'/net/pherkad/scratch/rguenth/gcc/libjava/external/sax -d /net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libjava \ -MD -MF gnu/awt.deps @gnu/awt.list /net/pherkad/scratch/rguenth/gcc/libjava/gnu/awt/LightweightRedirector.java: In class 'gnu.awt.LightweightRedirector': /net/pherkad/scratch/rguenth/gcc/libjava/gnu/awt/LightweightRedirector.java: In method 'gnu.awt.LightweightRedirector.redirect(java.awt.AWTEvent)': /net/pherkad/scratch/rguenth/gcc/libjava/gnu/awt/LightweightRedirector.java:48: error: Unreachable statement. return event; ^ /net/pherkad/scratch/rguenth/gcc/libjava/gnu/awt/LightweightRedirector.java:43: internal compiler error: internal error in check-init: tree code not implemented: identifier_node Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [gnu/awt.stamp] Error 1 make[2]: Leaving directory `/net/pherkad/scratch/rguenth/gcc-obj/x86_64-unknown-linux-gnu/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/net/pherkad/scratch/rguenth/gcc-obj' make: *** [bootstrap] Error 2 Last updated a few minutes ago. Just FYI. Richard.
Re:
Tom Tromey wrote: I'm checking this in on the trunk. If I remember I'll put it on the 4.0 branch once it reopens (there are a fair number of patches pending for it ... I hope it reopens soon). Mark, The extended freeze of the 4.0 branch is making things difficult for libgcj because we have a large backlog of runtime patches which we are unable to apply at this time. The longer the freeze continues, the more difficult it becomes for us to keep track of what needs applying and increases the chances that something will be forgotten, resulting in problems and wasted time further down the line. Could we get an exemption from the freeze rules for low-risk, runtime only libgcj fixes as determined by the libgcj maintainers? Alternatively, could we rethink our release policy to ensure that the duration of freezes is minimized in the future? I do think that a hard freeze in the days leading up to a release is useful and important, but keeping it in place for weeks just because a couple of bugs remain unfixed doesn't seem helpful. Thanks Bryce
Re: please update the gcj main page
Ranjit Mathew wrote: As for your suggestion, I believe the correct place would be "2.8 What features of the Java language are/aren't supported?" in the FAQ: http://gcc.gnu.org/java/faq.html#2_8 in addition to the front-page (if so desired). The FAQ is badly in need of an update - in fact, it should be moved over to the Wiki (http://gcc.gnu.org/wiki/GCJ) in order to be easier to update and maintain. We need to avoid incorporating too many random factiods on the front page, but mentioning that GCJ is currently approximately-compatible with Java 1.4.2 would be worthwhile. Bryce
Re: please update the gcj main page
John M. Gabriele wrote: Ah. Some expansion of that faq item would be useful (re. 1.4 vs 1.5). Following the link to the JLS page, I see that they are still pointing users to what looks to me like the Java 1.4 spec (I browsed the online html version's index, and there's no mention of generics or autoboxing), though a new version of that JLS book seems to be coming out last month. :) Also note that the "table of contents" at the top of the GCJ faq page has a typo: s/arn't/aren't/. in addition to the front-page (if so desired). Yes. How do we go about it? :) The web pages can be found in the "wwwdocs" module in GCC cvs. Go here for details: http://gcc.gnu.org/cvs.html Fixes and updates should be submitted to [EMAIL PROTECTED] and [EMAIL PROTECTED] We appreciate your help with this! Bryce
Re: Big Classpath Merge warning
Thorsten Glaser wrote: Tom Tromey dixit: I'm finally ready to check in the big classpath merge, and I wanted to post a short warning before I went ahead with it. Is it possible to use a current libgcj or classpath with gcc 3.4? Not really. It would probably be possible to backport most things, but not without some hacking. Bryce
eamonn raymona deepak
camille laura maryam
Re: Patch: Boehm GC 6.6 merge
Andrew Haley wrote: Ranjit Mathew writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Bryce McKinlay wrote: > > This patch merges the GC 6.6 sources into the libgcj trunk. Two patches > [...] > > This little bit in "boehm-gc/include/private/gcconfig.h" (line 306): > - - 8< - > > +# else > > +#if defined(__i386__) > > +# define I386 > > --> Not really supported, but at least we recognize it. > > +#endif > - - 8< - > causes a bootstrap failure for me on i686-pc-linux-gnu. > Note that the "Not really" bit is not inside a comment. The differences between our gcconfig.h and the stock Boehm 6.6 version are hard for me to understand. Bryce, what are the reasons for them? I understand why we want to define USE_MMAP for Linux, but the rest look spurious. Some of these come from changes for darwin/PPC64 support that are in our tree but not yet in the upstream GC sources - I believe the "Not really supported" bit is supposed to refer to Darwin/x86. I'm investigating and will check in a fix shortly. Most of the other diffs look like whitespace changes and can be stripped out. Bryce
Re: Boehm GC memory leak on Darwin
Thanks Sandro, I have checked this in to the trunk and the 4.1 branch.
It would be great to get a copyright assignment form from you so that we
can check in the rest of your Darwin/x86 patches. Have you started the
copyright assignment process? If not, the form to do so can be found here:
http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html
Bryce
Sandro Tolaini wrote:
I'm sending this note again since I have been caught in this bug once
more. Under Darwin (PPC and Intel) there is a serious memory leak at
every Boehm GC cycle. See discussion and patch here:
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-December/001071.html
I think that the patch should be applied to every maintained branch.
Please maintainers, check this in!
2006-04-11 Bryce McKinlay <[EMAIL PROTECTED]>
* darwin_stop_world.c (GC_push_all_stacks, GC_stop_world,
GC_start_world): Call vm_deallocate to free act_list. Fix from
Bruce Mitchener.
Index: darwin_stop_world.c
===
--- darwin_stop_world.c (revision 112716)
+++ darwin_stop_world.c (working copy)
@@ -155,6 +155,7 @@
# endif
GC_push_all_stack(lo, hi);
} /* for(p=GC_threads[i]...) */
+vm_deallocate(current_task(), (vm_address_t)act_list, sizeof(thread_t) * listcount);
}
static mach_port_t GC_mach_handler_thread;
@@ -297,6 +298,7 @@
changes = result;
prev_list = act_list;
prevcount = listcount;
+vm_deallocate(current_task(), (vm_address_t)act_list, sizeof(thread_t) * listcount);
} while (changes);
@@ -368,6 +370,7 @@
}
}
}
+vm_deallocate(current_task(), (vm_address_t)act_list, sizeof(thread_t) * listcount);
# if DEBUG_THREADS
GC_printf0("World started\n");
# endif
_darwin10_Unwind_FindEnclosingFunction
libgcc_s and libgcj contain a hack which renames _Unwind_FindEnclosingFunction to _darwin10_Unwind_FindEnclosingFunction on darwin targets. It appears this was introduced to work around an issue in OS X 10.6 where the _Unwind_FindEnclosingFunction was implemented as a stub which called abort(). see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991 This has since been fixed in OS X 10.7+, and the system's _Unwind_FindEnclosingFunction now works. In Mac OS X 10.7 and 10.8, libgcc_s is installed as a symlink to libSystem: $ ls -l /usr/lib/libgcc_s.1.dylib lrwxr-xr-x 1 root wheel 17 Jun 19 13:16 /usr/lib/libgcc_s.1.dylib -> libSystem.B.dylib Unfortunately this means that libgcj does not work on a standard Mac OS X installation, because dyld will see the symlink and resolve libgcc_s to libSystem before it checks anywhere else: $ gcj Hello.class --main=Hello $ ./a.out dyld: _dyld_bind_fully_image_containing_address() error dyld: Symbol not found: __darwin10_Unwind_FindEnclosingFunction Referenced from: /usr/local/lib/libgcj.13.dylib Expected in: /usr/lib/libSystem.B.dylib in /usr/local/lib/libgcj.13.dylib Trace/BPT trap: 5 This can be worked around by adjusting the system library path, or forcing libgcc_s to be loaded with DYLD_INSERT_LIBRARIES, but libgcj should work out-of-the-box for without having to hack the dyld configuration - so clearly we should not be renaming _Unwind_FindEnclosingFunction on OS X 10.7+ configurations. But I'm not convinced that this solution was ever really right to begin with. Even on a 10.6 system, things ought to work so long as you ensure libgcc_s is loaded before libSystem. Shouldn't the _darwin10_Unwind_FindEnclosingFunction rename be removed entirely? Bryce
Architecture instruction utilization rates
Hello all, I'm just curious about this, but what is the percentage of (and what are the) unused instructions for each supported architecture under GCC?
