[Bug java/64044] Java emits bogus .class$ decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64044 Andrew Haley changed: What|Removed |Added CC||aph at redhat dot com --- Comment #2 from Andrew Haley --- So, is the solution to this trivially not to mark the .class$ decls as TREE_CONST ?
[Bug inline-asm/63900] memory constrains needlessly doing memory clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63900 Andrew Haley changed: What|Removed |Added CC||aph at redhat dot com --- Comment #2 from Andrew Haley --- (In reply to Andrew Pinski from comment #1) > (In reply to David from comment #0) > > Change MYSIZE to 3 (or 12, 1000, 0xfff, etc) we see the value getting > > read from memory before calling printf, indicating the asm performed a full > > clobber (affecting buff2) instead of just clobbering buff as was intended. > > So that is just an optimization anyways. So closing as invalid. Why is this invalid? Looks like a missed-optimization to me.
[Bug java/60667] Undefined behavior in Java FE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60667 Andrew Haley changed: What|Removed |Added CC||aph at redhat dot com --- Comment #2 from Andrew Haley --- I can't investigate this with today's trunk, because it does not build with ubsan: i386 /scratch/gcc/configure --with-build-config=bootstrap-ubsan --enable-languages=java /scratch/gcc/obj-i686-pc-linux-gnu/./prev-gcc/xg++ -B/scratch/gcc/obj-i686-pc-linux-gnu/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -nostdinc++ -B/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/include -I/scratch/gcc/libstdc++-v3/libsupc++ -L/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs -L/scratch/gcc/obj-i686-pc-linux-gnu/prev-i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -fsanitize=undefined -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/scratch/gcc/gcc -I/scratch/gcc/gcc/build -I/scratch/gcc/gcc/../include -I/scratch/gcc/gcc/../libcpp/include \ -o build/read-rtl.o /scratch/gcc/gcc/read-rtl.c /scratch/gcc/gcc/read-rtl.c: In function 'bool read_rtx(const char*, rtx_def**)': /scratch/gcc/gcc/read-rtl.c:1031:1: internal compiler error: Segmentation fault read_rtx (const char *rtx_name, rtx *x) ^ 0xda18f2 crash_signal /scratch/gcc/gcc/toplev.c:337 0x5ea774 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /scratch/gcc/gcc/tree.h:2826 0xd9282f place_field(record_layout_info_s*, tree_node*) /scratch/gcc/gcc/stor-layout.c:1076 0xd98085 layout_type(tree_node*) /scratch/gcc/gcc/stor-layout.c:2292 0xdc4480 ubsan_create_data(char const*, unsigned int, ubsan_mismatch_data const*, ...) /scratch/gcc/gcc/ubsan.c:465 0xdc4829 ubsan_instrument_unreachable(unsigned int) /scratch/gcc/gcc/ubsan.c:517 0x92d8cb fold_builtin_0 /scratch/gcc/gcc/builtins.c:10306 0x93022c fold_builtin_n /scratch/gcc/gcc/builtins.c:1 0x93a145 fold_call_stmt(gimple_statement_base*, bool) /scratch/gcc/gcc/builtins.c:14251 0xb2690b gimple_fold_builtin(gimple_statement_base*) /scratch/gcc/gcc/gimple-fold.c:888 0xb27967 gimple_fold_call /scratch/gcc/gcc/gimple-fold.c:1179 0xb27d6d fold_stmt_1 /scratch/gcc/gcc/gimple-fold.c:1258 0xb282fb fold_stmt(gimple_stmt_iterator*) /scratch/gcc/gcc/gimple-fold.c:1366 0xe2140c fold_marked_statements /scratch/gcc/gcc/tree-inline.c:4497 0xe2188e optimize_inline_calls(tree_node*) /scratch/gcc/gcc/tree-inline.c:4622 0x1492868 inline_transform(cgraph_node*) /scratch/gcc/gcc/ipa-inline-transform.c:453 0xcb73f0 execute_one_ipa_transform_pass /scratch/gcc/gcc/passes.c:2066 0xcb7557 execute_all_ipa_transforms() /scratch/gcc/gcc/passes.c:2107 0x9951c4 expand_function /scratch/gcc/gcc/cgraphunit.c:1767 0x9957e1 expand_all_functions /scratch/gcc/gcc/cgraphunit.c:1908 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [build/read-rtl.o] Error 1 make[3]: Leaving directory `/scratch/gcc/obj-i686-pc-linux-gnu/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/scratch/gcc/obj-i686-pc-linux-gnu' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/scratch/gcc/obj-i686-pc-linux-gnu' make: *** [all] Error 2
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #37 from aph at redhat dot com 2010-04-13 17:02 --- Subject: Re: [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux On 04/13/2010 05:52 PM, mikpe at it dot uu dot se wrote: >> Is it maybe the case that "Compact model 1" unwinder data isn't yet being >> merged? > > They have to be adjacent to be merged. Looks like there's something else > between f2 and f1 in your object code. (You are using binutils >= 2.20 right?) Yes. OK, that explains it: gcc trunk outputs the functions in a completely different order. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug java/40816] error: 'jvariant::jvariant(jbyte)' cannot be overloaded
--- Comment #3 from aph at redhat dot com 2010-01-23 23:18 --- Subject: Re: error: 'jvariant::jvariant(jbyte)' cannot be overloaded On 01/22/2010 11:43 AM, mathieu dot malaterre at gmail dot com wrote: > --- Comment #2 from mathieu dot malaterre at gmail dot com 2010-01-22 > 11:43 --- > Any update ? No, I've just been cowardly. Remind me next week and I'll commit the change. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40816
[Bug inline-asm/39847] 16 symbolic register names generates error: more than 30 operands in 'asm'
--- Comment #10 from aph at redhat dot com 2009-04-22 17:33 --- Subject: Re: 16 symbolic register names generates error: more than 30 operands in 'asm' > 0) I will build gcc-4.4 and try that. I will also make the 1 line patch to it > to try increasing the number of asm params, and try that. I would prefer that > someone with more guts inside the guts of gcc do the latter, I fear I would > rapidly end up over my head. Is it a magic number or just a stupid default? Try max_recog_operands = FIRST_PSEUDO_REGISTER*2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39847
[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives
--- Comment #7 from aph at redhat dot com 2009-04-20 15:44 --- Subject: Re: [arm] libjava build failure due to missing thread synchronization primitives >> I'm not quite sure what you're trying to do. >> >> What did you change to support arm-eabi* ? > > I changed libjava/configure.host to also support arm-eabi > (arm*-elf|arm*-eabi)but that probably wasn't enough. Given that arm-elf > appears > to be supported for this as per the last comment in the bug report, I thought > it would make sense to have it working for arm-eabi. > > I decided to go back and try an arm-elf build as well just now. I get a > failure > with jni-libjvm.cc with an error about ParkHelper not naming a type. Hence > this > appears to be broken on trunk as revision 146222 for arm-elf as well as > arm-eabi. Probably. The java.lang.concurrent library requires thread support, so the only way you're going to get it to run with no threads is to create dummy definitions for ParkHelper. That should be easy, since null definitions for park() and unpark() will be fine. Just add these to libjava/no-threads.cc and libjava/include/no-threads.h. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340
[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives
--- Comment #5 from aph at redhat dot com 2009-04-20 08:48 --- Subject: Re: [arm] libjava build failure due to missing thread synchronization primitives ramana at gcc dot gnu dot org wrote: > --- Comment #4 from ramana at gcc dot gnu dot org 2009-04-20 05:58 > --- > The build is broken currently for arm-none-eabi targets on trunk. > > Attempting a simple fix of supporting arm-eabi* got me past the error reported > in the original bug report. but I still get a failure with the following error > message. I'm not quite sure what you're trying to do. What did you change to support arm-eabi* ? Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340
[Bug libgcj/38396] [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc
--- Comment #27 from aph at redhat dot com 2009-04-04 21:13 --- Subject: Re: [4.3 Regression] ecj1 linked against both -lgcj and -lgcj_bc dominiq at lps dot ens dot fr wrote: > Out of curiosity, how can a pr like this one be "UNCONFIRMED"? Insanity is the only explanation I can think of. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38396
[Bug libgcj/5303] Undocumented java programs
--- Comment #15 from aph at redhat dot com 2009-02-09 16:46 --- Subject: Re: Undocumented java programs mmitchel at gcc dot gnu dot org wrote: > --- Comment #14 from mmitchel at gcc dot gnu dot org 2009-02-09 16:20 > --- > Would the Java maintainers accept a patch to remove addr2name.awk? Sure. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5303
[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME
--- Comment #18 from aph at redhat dot com 2008-12-10 13:46 --- Subject: Re: [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME jakub at gcc dot gnu dot org wrote: > --- Comment #17 from jakub at gcc dot gnu dot org 2008-12-10 13:30 > --- > For #c12, those weren't present in 4.3 libgcj_bc.so, but I don't see why it > matters. 4.3 linked ecj1 doesn't need any of those symbols. The reason why > it > has DT_NEEDED libgcj.so.9 is IMHO that libgcj.la was in ecjx's LDADD, so > libtool > linked it with -lgcj (and as -Wl,--as-needed -lgcj -Wl,--no-as-needed wasn't > used, it was added to DT_NEEDED unconditionally). > The fix really is not to have libgcj.la in LDADD for dynamically linked ecj1. > I'm just not sure about !ENABLE_SHARED build if USE_LIBGCJ_BC is true, maybe > libgcj.la is needed in that case (not sure if libgcj_bc.la has libgcj.la as a > dependency in that case). We, then, have two unrelated bugs to fix on 4.3 branch. 1. The missing symbols in libgcj_bc that cause BC-compiled applications to have a DT_NEEDED libgcj.so.9. 2. ecjx's LDADD to libgcj.la. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38396
[Bug libgcj/38396] [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME
--- Comment #14 from aph at redhat dot com 2008-12-10 12:46 --- Subject: Re: [4.4 Regression] libgcj_bc for 4.3 and 4.4 are binary incompatible but have the same SONAME rguenther at suse dot de wrote: >> Look at the exported symbols in the old version of libgcj_bc.so. >> >> Make sure that these symbols are exported: >> >> _Jv_JNI_PopSystemFrame >> _Jv_LookupInterfaceMethod >> _Jv_MonitorExit >> _Jv_RegisterResource > > readelf -s libgcj_bc.so | grep > '_Jv_RegisterResource\|_Jv_JNI_PopSystemFrame\|_Jv_LookupInterfaceMethod\|_Jv_MonitorExit' > 43: 1330 2 FUNCGLOBAL DEFAULT 12 > _Jv_LookupInterfaceMethod > > so only _Jv_LookupInterfaceMethod is there. Right, so that's probably what's causing the DT_NEEDED for libgcj.so.9. > But they are all provided by > both libgcj.so.9 and libgcj.so.10 (which is what /usr/lib64/libgcj_bc.so.1 > links to). The libgcj_bc.so is in /usr/lib64/gcc/x86_64-suse-linux/4.3 > and thus only used if you link with gcj 4.3. Right, so this is a bug in gcj 4.3. All symbols used by BC-compiled programs need to be in libgcj_bc.so. As has already been said, /usr/lib64/libgcj_bc.so.1 is not a link to libgcj.so.x in FSF gcj. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38396
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #36 from aph at redhat dot com 2008-11-05 14:02 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected ro at techfak dot uni-bielefeld dot de wrote: > After rebuilding jc1 and rerunning the libjava testsuite on > alpha-dec-osf5.1b, I'm back at the same set of testsuite failures that I > had on 20080313. Feel free to CC me with any of these. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #31 from aph at redhat dot com 2008-11-04 23:06 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-04 > 19:01 --- > Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI > version detected > >> That error now is gone, but we may only have stepped to the next error on >> these >> platforms. We can decide if it should continue in this bug or a new bug >> should >> be opened. > > If the error is releated to the running of constructors for class > registration or resource registration, then I think we should continue > with this bug. Otherwise, it's a new bug. OK, but I need to know if my patch has been tested well enough for me to check it in. I'm fairly certain it doesn't break x86 GNU/Linux. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #27 from aph at redhat dot com 2008-11-04 18:16 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected dje dot gcc at gmail dot com wrote: > --- Comment #25 from dje dot gcc at gmail dot com 2008-11-04 18:11 > --- > Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI > version detected > >> This patch works on x86_64 GNU/Linux. >> >> Please HP/UX, AIX, and OSF users make sure it works for them as well. > > I recompiled jc1 and libjava with the patch. I still encounter failures with > execution tests. I will be interested to learn Dave's results on HP-UX. Oh dear: I followed mmitchel's instructions to the letter. Sooner or later someone is going to have to be allowed access to a suitable machine. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #24 from aph at redhat dot com 2008-11-04 16:09 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect
library ABI version detected
mark at codesourcery dot com wrote:
> You shouldn't call that function. Instead, you should set
> DECL_STATIC_{CONSTRUCTOR,DESTRUCTOR}. Then, cgraph will do the right
> thing. If necessary, you can also call decl_init_priority_insert.
This patch works on x86_64 GNU/Linux.
Please HP/UX, AIX, and OSF users make sure it works for them as well.
Thanks,
Andrew.
2008-11-04 Andrew Haley <[EMAIL PROTECTED]>
* jcf-parse.c (java_emit_static_constructor): Don't call
cgraph_build_static_cdtor. Rewrite.
Index: jcf-parse.c
===
--- jcf-parse.c (revision 141575)
+++ jcf-parse.c (working copy)
@@ -1699,7 +1699,32 @@
write_resource_constructor (&body);
if (body)
-cgraph_build_static_cdtor ('I', body, DEFAULT_INIT_PRIORITY);
+{
+ tree name = get_identifier ("_Jv_global_static_constructor");
+
+ tree decl = build_decl (FUNCTION_DECL, name,
+ build_function_type (void_type_node,
void_list_node));
+
+ tree resdecl = build_decl (RESULT_DECL, NULL_TREE, void_type_node);
+ DECL_ARTIFICIAL (resdecl) = 1;
+ DECL_RESULT (decl) = resdecl;
+ current_function_decl = decl;
+ allocate_struct_function (decl, false);
+
+ TREE_STATIC (decl) = 1;
+ TREE_USED (decl) = 1;
+ DECL_ARTIFICIAL (decl) = 1;
+ DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (decl) = 1;
+ DECL_SAVED_TREE (decl) = body;
+ DECL_UNINLINABLE (decl) = 1;
+
+ DECL_INITIAL (decl) = make_node (BLOCK);
+ TREE_USED (DECL_INITIAL (decl)) = 1;
+
+ DECL_STATIC_CONSTRUCTOR (decl) = 1;
+ java_genericize (decl);
+ cgraph_finalize_function (decl, false);
+}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #18 from aph at redhat dot com 2008-11-03 15:12 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-03 > 15:02 --- > Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI > version detected > >> --- Comment #13 from aph at gcc dot gnu dot org 2008-11-03 10:18 --- >> As a Java maintainer I'm happy to have a look at this, but I have no access >> to >> HP/UX hardware. > > I could provide access. However, debugging this with gdb is tricky. > It can't set a breakpoint in a constructor in a shared library. There's > some issue with load notifications. It's also not possible to link > with -static. That doesn't matter, because it's not a runtime bug, it's a compiler bug. We have to debug the compiler. > I'm willing to look at anything you suggest. There's a couple of > other PRs related to gcj-dbtool that probably relate to this problem. > > The org-xml.list is one in which I see the same class registered twice > (e.g., _ZN3org3xml3sax3ext14LexicalHandler6class$E). Okay, the question is why is cgraph_build_static_cdtor() being called twice, once from cgraph_optimize() and once from java_parse_file() ? And, if the FE should not call cgraph_build_static_cdtor(), why does the code generation fail if the call is removed ? The entire solution to this problem lies in that answer. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/21206] gcj seems not to pass the option to ld correctly
--- Comment #10 from aph at redhat dot com 2006-02-23 15:41 --- Subject: Re: gcj seems not to pass the option to ld correctly Rainer Emrich writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Andrew Haley schrieb: > > Rainer Emrich writes: > > > The config.log in libjava has two entries for libiconv: > > > LIBICONV > > > which is > > > LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib/libiconv.so > > > -Wl,-rpath -Wl,/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > > > in my case. > > > > > > The second is > > > LTLIBICONV > > > which is > > > LTLIBICONV='-L/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib -liconv > > > -R/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > > > in my case. > > > > > > I changed the libgcj.spec file manually to the second. That seems to work. > > > So, my conclusion is to change the libgcj.spec.in. > > > The following line: > > > *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > > > %(libgcc) %(liborig) > > > should be changed to > > > *lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > > > %(libgcc) %(liborig) > > > > > > Any comments? > > > > Looks right to me. BTW, what failure caused you to find this? > See the following messages: > > http://gcc.gnu.org/ml/gcc/2006-02/msg00415.html > http://gcc.gnu.org/ml/gcc/2006-02/msg00482.html Yes, I agree with your reasoning. AFAIK Mark Mitchell has to approve this as it's for the release, but it's OK by me if it passes bootstrap. I don't see this problem on my system because LIBICONV and LTLIBICONV are both null. AFAIK that's because iconv is in libc. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21206
[Bug java/21206] gcj seems not to pass the option to ld correctly
--- Comment #8 from aph at redhat dot com 2006-02-23 13:38 --- Subject: Re: Re: gcj seems not to pass the option to ld correctly Rainer Emrich writes: > The config.log in libjava has two entries for libiconv: > LIBICONV > which is > LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib/libiconv.so > -Wl,-rpath -Wl,/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > in my case. > > The second is > LTLIBICONV > which is > LTLIBICONV='-L/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib -liconv > -R/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib' > in my case. > > I changed the libgcj.spec file manually to the second. That seems to work. > So, my conclusion is to change the libgcj.spec.in. > The following line: > *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > %(libgcc) %(liborig) > should be changed to > *lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ > %(libgcc) %(liborig) > > Any comments? Looks right to me. BTW, what failure caused you to find this? Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21206
[Bug bootstrap/20155] [4.0 Regression] libgcj build fails with "execvp: /bin/sh: Argument list too long"
--- Additional Comments From aph at redhat dot com 2005-08-08 17:03 --- Subject: Re: [4.0 Regression] libgcj build fails with "execvp: /bin/sh: Argument list too long" bonzini at gcc dot gnu dot org writes: > > Andrew, is a backport fine with you? Yes. Go for it. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20155
[Bug java/22460] GCJ produces mis-match (non compatible) types in MODIFY_EXPR (from byte-code)
-- What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22460
[Bug java/21428] [3.4/4.0/4.1 Regression] bogus warning: unused parameter 'this'
--- Additional Comments From aph at redhat dot com 2005-06-30 08:58 --- Ah, thanks. It was a causalty of a hard disk crash I had. I'll do it once 4.0 is thawed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21428
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From aph at redhat dot com 2005-06-06 13:15 --- With that change, passes bootstrap with c/c++/java, perfect i686-pc-linux-gnu libgcj test result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From aph at redhat dot com 2005-06-06 11:34 --- I think you want mark_stmt_necessary (stmt, true) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From aph at redhat dot com 2005-06-06 11:09 --- Failure during bootstrap: ./xgcc -B./ -B/home/aph/gcc4/install/i686-pc-linux-gnu/bin/ -isystem /home/aph/gcc4/install/i686-pc-linux-gnu/include -isystem /home/aph/gcc4/install/i686-pc-linux-gnu/sys-include -L/home/aph/gcc4/build/gcc/../ld -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I/home/aph/gcc4/gcc/gcc -I/home/aph/gcc4/gcc/gcc/. -I/home/aph/gcc4/gcc/gcc/../include -I/home/aph/gcc4/gcc/gcc/../libcpp/include -DL_moddi3 -fvisibility=hidden -DHIDE_EXPORTS -fexceptions -fnon-call-exceptions -c /home/aph/gcc4/gcc/gcc/libgcc2.c -o libgcc/./_moddi3.o /home/aph/gcc4/gcc/gcc/libgcc2.c: In function '__divdi3': /home/aph/gcc4/gcc/gcc/libgcc2.c:1056: error: Type mismatch between an SSA_NAME and its symbol. /home/aph/gcc4/gcc/gcc/libgcc2.c:1056: error: Missing definition for SSA_NAME: D.4215_136in statement: # TMT.31_158 = V_MAY_DEF ; *rp_35 = D.4215_136; /home/aph/gcc4/gcc/gcc/libgcc2.c:1056: internal compiler error: verify_ssa failed. Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From aph at redhat dot com 2005-06-06 10:44 --- OK, I'm looking at it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug java/17845] can't build GNU Classpath
--- Additional Comments From aph at redhat dot com 2004-10-11 09:11 --- Subject: can't build GNU Classpath I think I'm going to have to give up on this bug. If I can't duplicate the problem myself and you can't duplicate the propblem on any machine to which I have access there's nothing that I can do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17845
