Recent 4.3.0 breaks the build of pdftk again with pdftk.C:4936: error: Java method 'void com::lowagie::text::pdf::PdfReader::removeUnusedNode(com::lowagie::text::pdf::PdfObject*, JArray<bool>*)' has non-Java parameter type 'JArray<bool>*' where appearantly the frontend has substituted bool for jboolean and now rejects it on the basis that bool is not TYPE_FOR_JAVA.
Created attachment 15261 [details] testcase
Works with 4.2.3 and 4.1.3. Worked with 4.3.0 somewhen in January.
jboolean is lost in convert_template_argument: /* We only form one instance of each template specialization. Therefore, if we use a non-canonical variant (i.e., a typedef), any future messages referring to the type will use the typedef, which is confusing if those future uses do not themselves also use the typedef. */ if (TYPE_P (val)) val = canonical_type_variant (val); As jboolean is now everywhere but on ppc-darwin a variant of bool, and only the former has TYPE_FOR_JAVA set, we have this error. Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131840 I guess the easiest fix is just make jboolean make_unsigned_type (1) on all targets, not just on ppc-darwin.
Subject: Re: [4.3/4.4 Regression] Rejects JArray<jboolean> On Sat, 8 Mar 2008, jakub at gcc dot gnu dot org wrote: > ------- Comment #3 from jakub at gcc dot gnu dot org 2008-03-08 20:55 ------- > jboolean is lost in convert_template_argument: > /* We only form one instance of each template specialization. > Therefore, if we use a non-canonical variant (i.e., a > typedef), any future messages referring to the type will use > the typedef, which is confusing if those future uses do not > themselves also use the typedef. */ > if (TYPE_P (val)) > val = canonical_type_variant (val); > As jboolean is now everywhere but on ppc-darwin a variant of bool, and only the > former has TYPE_FOR_JAVA set, we have this error. > Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131840 > I guess the easiest fix is just make jboolean make_unsigned_type (1) on all > targets, not just on ppc-darwin. This will cause wrong code generation for jboolean i = 1; i += 2; Richard.
No, it will not generate the wrong code for jboolean i = 1; i += 2; You are wrong to assume that jboolean must behave in the same way as boolean. It's a Java type, not a C++ type. Having exact conformance with C++ boolean is not important, having arrays of boolean compile is. The right fix *is* just make jboolean make_unsigned_type (1) on all targets.
Subject: Re: [4.3/4.4 Regression] Rejects JArray<jboolean> On Mon, 10 Mar 2008, aph at gcc dot gnu dot org wrote: > ------- Comment #5 from aph at gcc dot gnu dot org 2008-03-10 19:06 ------- > No, it will not generate the wrong code for > > jboolean i = 1; > i += 2; > > You are wrong to assume that jboolean must behave in the same way as boolean. > It's a Java type, not a C++ type. > > Having exact conformance with C++ boolean is not important, having arrays > of boolean compile is. > > The right fix *is* just make jboolean make_unsigned_type (1) on all > targets. So you can just revert 2008-02-04 Richard Guenther <rguenther@suse.de> PR java/35035 * decl.c (record_builtin_java_type): Make jboolean a integer type again where its mode doesn't match that of bool. 2008-01-25 Richard Guenther <rguenther@suse.de> PR c++/33887 * decl.c (record_builtin_java_type): Make __java_boolean a variant of bool. * typeck.c (structural_comptypes): Move TYPE_FOR_JAVA check after TYPE_MAIN_VARIANT check. then. Still with C++ now reducing operations on bit-precision types you get different answers for the above case now. Richard.
Okay, but I don't quite understand this final sentence: "Still with C++ now reducing operations on bit-precision types you get different answers for the above case now." What exactly do you mean by this?
Subject: Re: [4.3/4.4 Regression] Rejects JArray<jboolean> On Tue, 11 Mar 2008, aph at gcc dot gnu dot org wrote: > ------- Comment #7 from aph at gcc dot gnu dot org 2008-03-11 09:58 ------- > Okay, but I don't quite understand this final sentence: > > "Still with C++ now reducing operations on bit-precision types > you get different answers for the above case now." > > What exactly do you mean by this? With gcc 4.2 jboolean j = 2; if (j) ... was in some cases compiled to assign true to j. Starting with gcc 4.3 all jboolean values will consistently behave as if you'd write j & 1. See the libjava fix 2008-01-18 Alexandre Oliva <aoliva@redhat.com> PR c++/33887 * link.cc (_Jv_Linker::prepare_constant_time_tables): has_interfaces is boolean, treat it as such. that corrected one instance in libjava that we 'miscompiled' after this change. Richard.
Subject: Bug 35469 Author: rguenth Date: Wed Mar 12 14:25:48 2008 New Revision: 133142 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133142 Log: 2008-03-12 Richard Guenther <rguenther@suse.de> PR c++/35469 Revert: 2008-02-04 Richard Guenther <rguenther@suse.de> PR java/35035 * decl.c (record_builtin_java_type): Make jboolean a integer type again where its mode doesn't match that of bool. 2008-01-25 Richard Guenther <rguenther@suse.de> PR c++/33887 * decl.c (record_builtin_java_type): Make __java_boolean a variant of bool. * typeck.c (structural_comptypes): Move TYPE_FOR_JAVA check after TYPE_MAIN_VARIANT check. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c
Subject: Bug 35469 Author: rguenth Date: Wed Mar 12 14:29:35 2008 New Revision: 133143 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133143 Log: 2008-03-12 Richard Guenther <rguenther@suse.de> PR c++/35469 Revert: 2008-02-04 Richard Guenther <rguenther@suse.de> PR java/35035 * decl.c (record_builtin_java_type): Make jboolean a integer type again where its mode doesn't match that of bool. 2008-01-25 Richard Guenther <rguenther@suse.de> PR c++/33887 * decl.c (record_builtin_java_type): Make __java_boolean a variant of bool. * typeck.c (structural_comptypes): Move TYPE_FOR_JAVA check after TYPE_MAIN_VARIANT check. Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/decl.c branches/gcc-4_3-branch/gcc/cp/typeck.c
Fixed.
Err, fixed.