Re: [patch] boehm-gc: link libgcjgc with -ldl
On 09/04/2013 11:00 AM, Matthias Klose wrote: > The boehm-gc tests currently fail to build with a linker with > --no-copy-dt-needed-entries as the default. Hmm, isn't that a bug in the linker? Andrew.
Re: [patch] boehm-gc: link libgcjgc with -ldl
On 09/04/2013 11:24 AM, Matthias Klose wrote: > Am 04.09.2013 12:21, schrieb Andrew Haley: >> On 09/04/2013 11:00 AM, Matthias Klose wrote: >>> The boehm-gc tests currently fail to build with a linker with >>> --no-copy-dt-needed-entries as the default. >> >> Hmm, isn't that a bug in the linker? > > No, it's the default in gold and in the bfd linker since 2.23. Oh, right. I wonder how many other things this will break. OK. Andrew.
Re: [PATCH, PowerPC] Fix PR57949 (ABI alignment issue)
On 09/12/2013 03:11 AM, Alan Modra wrote: > We have precedent for compiling libffi based on gcc preprocessor > defines, eg. __NO_FPRS__, so here's a way of making upstream libffi > compatible with the various versions of gcc out there. I've taken the > condition under which we align aggregates from > rs6000_function_arg_boundary, and defined a macro with a value of the > maximum alignment. I would have thought that a runtime or configure-time test in libffi would be better. Andrew.
Re: [Java] Tidy bultins and add __bultin_unreachable
On 10/16/2012 08:17 AM, Jan Hubicka wrote: > * builtins.c (define_builtin): Accept ECF flags and > use set_call_expr_flags. > (initialize_builtins): Update; add BULIT_IN_UNREACHALE. > > * calls.c (set_call_expr_flags): New. > * tree.h (set_call_expr_flags): Declare. OK, thanks. Andrew.
Re: [wwwdocs,Java] Replace sources.redhat.com by sourceware.org
On 10/23/2012 10:47 AM, Andrew Hughes wrote: > It's never been obvious to me how the web material gets updated. GCJ > regularly misses out on being mentioned in changes too, despite fixes going > in. Web material gets updated with patches through the same process as the software. Andrew.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 10/31/2012 09:49 AM, Richard Biener wrote: > On Tue, Oct 30, 2012 at 10:05 PM, Kenneth Zadeck > wrote: >> jakub, >> >> i am hoping to get the rest of my wide integer conversion posted by nov 5. >> I am under some adverse conditions here: hurricane sandy hit her pretty >> badly. my house is hooked up to a small generator, and no one has any power >> for miles around. >> >> So far richi has promised to review them. he has sent some comments, but >> so far no reviews.Some time after i get the first round of them posted, >> i will do a second round that incorporates everyones comments. >> >> But i would like a little slack here if possible.While this work is a >> show stopper for my private port, the patches address serious problems for >> many of the public ports, especially ones that have very flexible vector >> units.I believe that there are significant set of latent problems >> currently with the existing ports that use ti mode that these patches will >> fix. >> >> However, i will do everything in my power to get the first round of the >> patches posted by nov 5 deadline. > > I suppose you are not going to merge your private port for 4.8 and thus > the wide-int changes are not a show-stopper for you. > > That said, I considered the main conversion to be appropriate to be > defered for the next stage1. There is no advantage in disrupting the > tree more at this stage. We are still in Stage 1. If it were later in the release cycle this argument would have some merit, but under the rules this sort of thing is allowed at any point in Stage 1. If we aren't going to allow something like this because "it's too late" we should have closed Stage 1 earlier. Andrew.
Re: [PATCH] Properly install libgcc_bc dummy library
On 12/09/2013 02:31 PM, Richard Biener wrote: > On Mon, Dec 9, 2013 at 3:08 PM, Andreas Schwab wrote: >> The rules to install the dummy libgcc_bc library have never worked as >> intented, probably due to the fact that the fedora gcc package installs >> it by hand, ignoring all damage that has been done. The target that >> creates libgcj_bc.la for the testsuite is mucking around with internal >> details that will confuse libtool when it tries to install it, the >> effect of which can't be undone by install-exec-hook. We need to create >> a clean second copy that is actually installed. > > Ok if nobody objects in the next 24h. OK, thanks! Andrew.
Re: [patch] powerpc64 FreeBSD support for boehm-gc
On 12/20/2013 10:15 PM, Andreas Tobler wrote: > Ok for gcc trunk? OK, thanks. Andrew.
Re: [patch] powerpc64 FreeBSD support for boehm-gc
On 12/26/2013 12:11 AM, Andreas Tobler wrote: > On 21.12.13 18:27, Andrew Haley wrote: >> On 12/20/2013 10:15 PM, Andreas Tobler wrote: >>> Ok for gcc trunk? >> >> OK, thanks. >> > > May I get this one down to 4.8 too? Not really needed, but for > completeness. Results will follow... No objections from me. Andrew.
Re: [PATCH] Clarify __atomic_compare_exchange_n docs
On 09/29/2015 04:21 PM, Sandra Loosemore wrote: > What is "weak compare_exchange", and what is "the strong variation", and > how do they differ in terms of behavior? It's in C++11 29.6.5: Remark: The weak compare-and-exchange operations may fail spuriously, that is, return false while leaving the contents of memory pointed to by expected before the operation is the same that same as that of the object and the same as that of expected after the operation. [ Note: This spurious failure enables implementation of compare-and-exchange on a broader class of machines, e.g., load- locked store-conditional machines. A consequence of spurious failure is that nearly all uses of weak compare-and-exchange will be in a loop. When a compare-and-exchange is in a loop, the weak version will yield better performance on some platforms. When a weak compare-and-exchange would require a loop and a strong one would not, the strong one is preferable. — end note ] The classic use of this is for shared counters: you don't care if you miss an occasional count but you don't want the counter to go backwards. Whether we should replicate all of the C++11 language is perhaps something we should discuss. Andrew.
Re: [PATCH] Clarify __atomic_compare_exchange_n docs
On 10/01/2015 06:32 PM, Jonathan Wakely wrote: > I would suggest we don't try to reproduce the standard definition, but > just say the weak version can fail spuriously and the strong can't. > IMHO this isn't the place to educate people in the fine points of > low-level atomics. As it says, "when in doubt use the strong > variation". > > i.e. apply this in addition to my earlier suggestion. "If you don't already know what a weak CAS is you probably should not even think of using it." :) Andrew.
Re: [PATCH] libjava: fix locale handling when sorting JNI methods
On 23/10/15 04:56, Mike Frysinger wrote: > 2015-10-22 Mike Frysinger > > * scripts/check_jni_methods.sh.in: Run sort with LC_ALL=C, and > combine `sort|uniq` into `sort -u`. Looks OK to me. Andrew.
Re: update zlib to 1.2.8
On 23/11/15 04:37, Matthias Klose wrote: > In GCC zlib is only used for libjava; for binutils and gdb it is used when > building without --with-system-zlib. This just updates zlib from 1.2.7 to > 1.2.8 > (released in 2013). Applies cleanly, libjava still builds and doesn't show > any > regressions in the testsuite. Ok to apply (even if we already are in stage3)? Fine by me; GDB assent is more important. Andrew.
Re: [Patch ARM] Fix PR target/56846
On 25/08/14 11:32, Tony Wang wrote:
> Hi all,
>
> The bug is reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846,
> and it’s about the problem that
> when exception handler is involved in the function, then _Unwind_Backtrace
> function will run into deadloop on
> arm target.
>
> Cmd line: arm-none-eabi-g++ -mthumb -mcpu=cortex-m3 -O0 -g -std=c++11
> -specs=rdimon.specs main.c -o main.exe
> #include
> #include
> _Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg)
> {
> void *ip = (void *)_Unwind_GetIP(context);
> printf("Address: %p\n", ip);
> return _URC_NO_REASON;
> }
> void bar()
> {
> puts("This is in bar");
> _Unwind_Backtrace((_Unwind_Trace_Fn)&trace_func, 0);
> }
> void foo()
> {
> try
> {
> bar();
> }
> catch (...)
> {
> puts("Exception");
> }
> }
>
> The potential of such a bug is discussed long time ago in mail:
> https://gcc.gnu.org/ml/gcc/2007-08/msg00235.html. Basically, as the ARM EHABI
> does not define how to implement
> the Unwind_Backtrace, Andrew give control to the personality routine to
> unwind the stack, and use the unwind
> state combination of “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND” to
> represent that the caller is asking the
> personality routine to only unwind the stack for it.
>
> However, the pr in the libstdc++-v3 doesn’t handle such a unwind state
> pattern correctly. When the backtrace
> function passes such a pattern to it, it will still return _URC_HANDLER_FOUND
> to the caller in some cases.
> It’s because the pr will think that the _Unwind_Backtrace is raising a none
> type exception to it, so if the
> exception handler in current stack frame can catch anything(like catch(…)),
> the pr will return
> _URC_HANDLER_FOUND to the caller and ask for next step. But definitely, the
> unwind backtrace function don’t
> know what to do when pr return an exception handler to it.
>
> So this patch just evaluate such a unwind state pattern at the beginning of
> the personality routine in
> libstdc++-v3, if we meet with “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND”,
> then we directly call macro
> CONTINUE_UNWINDING to unwind the stack and return.
>
> Is this a reasonable fix?
>
> gcc/libstdc++-v3/ChangeLog:
> 2014-8-25 Tony Wang
>
> PR target/56846
> * libsupc++/eh_personality.cc: Return with CONTINUE_UNWINDING
> when meet with the unwind state pattern:
> _US_VIRTUAL_UNWIND_FRAME |
> _US_FORCE_UNWIND
That looks very sensible, but it's not my call to approve it.
Andrew.
Re: [C++ Patch, Java related/RFC] PR 11006
On 11/04/2013 05:21 PM, Jason Merrill wrote: > Surely it should be valid to allocate a Java boolean type. Andrew, > how should that work? It's not allowed. All objects that are allocated by new must be of class type (i.e. instances of a subclass of java.lang.Object), but boolean is a primitive type. Andrew.
Re: wide-int, java
On 11/23/2013 07:22 PM, Mike Stump wrote: > java: > * boehm.c: Include wide-int.h. > (mark_reference_fields): Use a wide_int mask. > (get_boehm_type_descriptor): Use wide-int interfaces. > * expr.c: Include wide-int.h. > (build_newarray): Remove bogus "== INTEGER_CST". > (expand_java_pushc): Use real_from_integer. > (build_field_ref): Use INT_CST_LT instead of INT_CST_LT_UNSIGNED. > * jcf-parse.c: Include wide-int.h. > (get_constant): Use wide-int interfaces. This looks reasonable, thanks. Andrew.
Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 06/10/14 05:08, Chen Gang wrote: > After try normal configure, get almost the same result, I guess, our > testsuite under Darwin x86_64 is OK. > > If no any additional reply within a week, I shall continue to try to > analyze the libjava Throw_2 issue. Throw_2 is a test specially contrived to detect segfaults that are not being correctly detected and turned into NullPointerException()s. A failure indicates that the segfault signal handler is broken. Andrew.
Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 10/06/2014 02:53 PM, Chen Gang wrote:
> On 10/6/14 16:37, Andrew Haley wrote:
>> On 06/10/14 05:08, Chen Gang wrote:
>>> After try normal configure, get almost the same result, I guess, our
>>> testsuite under Darwin x86_64 is OK.
>>>
>>> If no any additional reply within a week, I shall continue to try to
>>> analyze the libjava Throw_2 issue.
>>
>> Throw_2 is a test specially contrived to detect segfaults that are
>> not being correctly detected and turned into NullPointerException()s.
>> A failure indicates that the segfault signal handler is broken.
>
> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
> and after run it without any parameters, "1" is printed, but "2" is not
> printed.
>
> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>
> And I shall continue to try to analyze it (within this month), and
> welcome any additional ideas, suggestions, and completion for it,
Not every platform supports unwinding through signal handlers. In x86
Linux there is some very clever code which interacts with the kernel to
allow this.
Andrew.
Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 10/06/2014 03:27 PM, Chen Gang wrote:
> On 10/6/14 21:54, Andrew Haley wrote:
>> On 10/06/2014 02:53 PM, Chen Gang wrote:
>>> On 10/6/14 16:37, Andrew Haley wrote:
>>>> On 06/10/14 05:08, Chen Gang wrote:
>>>>> After try normal configure, get almost the same result, I guess, our
>>>>> testsuite under Darwin x86_64 is OK.
>>>>>
>>>>> If no any additional reply within a week, I shall continue to try to
>>>>> analyze the libjava Throw_2 issue.
>>>>
>>>> Throw_2 is a test specially contrived to detect segfaults that are
>>>> not being correctly detected and turned into NullPointerException()s.
>>>> A failure indicates that the segfault signal handler is broken.
>>>
>>> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
>>> and after run it without any parameters, "1" is printed, but "2" is not
>>> printed.
>>>
>>> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
>>> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
>>> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>>>
>>> And I shall continue to try to analyze it (within this month), and
>>> welcome any additional ideas, suggestions, and completion for it,
>>
>> Not every platform supports unwinding through signal handlers. In x86
>> Linux there is some very clever code which interacts with the kernel to
>> allow this.
>
> Excuse me, I am not quite familiar with Java, I guess what you said is:
>
> - The related feature need OS kernel support, if OS kernel does not
>support, it may report "Abort trap: 6" or others.
>
> - And OS kernel has feature to support "1" printed does not mean it
>also has feature to support "2" printed.
>
> - And I need try to make sure that my current Darwin kernel whether
>supports it or not.
>
> If what I guess is incorrect, please let me know, thanks.
That sounds approximately right, but it's changed a lot since I last
looked. It may be that the magic is in glibc rather than the kernel.
> For me, whether Darwin kernel supports or not, we have to improve
> current implementation (may be testsuite configure or Makefile) to
> avoid testsuite breaking.
The testsuite isn't breaking: it's telling you something useful.
Andrew.
Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'
On 10/06/2014 04:00 PM, Chen Gang wrote:
> On 10/6/14 22:28, Andrew Haley wrote:
>> On 10/06/2014 03:27 PM, Chen Gang wrote:
>>> On 10/6/14 21:54, Andrew Haley wrote:
>>>> On 10/06/2014 02:53 PM, Chen Gang wrote:
>>>>> On 10/6/14 16:37, Andrew Haley wrote:
>>>>>> On 06/10/14 05:08, Chen Gang wrote:
>>>>>>> After try normal configure, get almost the same result, I guess, our
>>>>>>> testsuite under Darwin x86_64 is OK.
>>>>>>>
>>>>>>> If no any additional reply within a week, I shall continue to try to
>>>>>>> analyze the libjava Throw_2 issue.
>>>>>>
>>>>>> Throw_2 is a test specially contrived to detect segfaults that are
>>>>>> not being correctly detected and turned into NullPointerException()s.
>>>>>> A failure indicates that the segfault signal handler is broken.
>>>>>
>>>>> OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
>>>>> and after run it without any parameters, "1" is printed, but "2" is not
>>>>> printed.
>>>>>
>>>>> Under Fedora 20 x86_64, the same gcc code, it is OK ("2" can be printed),
>>>>> but under Darwin x86_64, it is "Abort trap: 6" instead of. The related
>>>>> code: "try{Double.parseDouble(str());}catch", and "str(){return null;}".
>>>>>
>>>>> And I shall continue to try to analyze it (within this month), and
>>>>> welcome any additional ideas, suggestions, and completion for it,
>>>>
>>>> Not every platform supports unwinding through signal handlers. In x86
>>>> Linux there is some very clever code which interacts with the kernel to
>>>> allow this.
>>>
>>> Excuse me, I am not quite familiar with Java, I guess what you said is:
>>>
>>> - The related feature need OS kernel support, if OS kernel does not
>>>support, it may report "Abort trap: 6" or others.
>>>
>>> - And OS kernel has feature to support "1" printed does not mean it
>>>also has feature to support "2" printed.
>>>
>>> - And I need try to make sure that my current Darwin kernel whether
>>>supports it or not.
>>>
>>> If what I guess is incorrect, please let me know, thanks.
>>
>> That sounds approximately right, but it's changed a lot since I last
>> looked. It may be that the magic is in glibc rather than the kernel.
>>
>
> OK, thanks, I shall also notice about glibc when I try to analyze it,
> e.g. need try to build and install upstream glibc instead of the Darwin
> glibc (I am not quite sure whether I can do that, I guess I can).
>
>
>>> For me, whether Darwin kernel supports or not, we have to improve
>>> current implementation (may be testsuite configure or Makefile) to
>>> avoid testsuite breaking.
>>
>> The testsuite isn't breaking: it's telling you something useful.
>>
>
> Sorry it is breaked, at present, I temporarily skipped it and then can
> let "make check" finish, the related temporarily skip diff may like
> below (in real action, I modify the related Makefile, directly):
You're missing what I'm saying. The testuite is not broken.
You should be running "make -k check".
Andrew.
Re: [Java PATCH] Generate declarations in jvgenmain.c
On 06/10/14 22:00, Mark Wielaard wrote: > If no java maintainer responds, try CCing java-patc...@gcc.gnu.org > to draw their attention. Please. I can't see the patch here. Andrew.
Re: [Java PATCH] Generate declarations in jvgenmain.c
On 10/07/2014 09:31 AM, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-linux, ok for trunk? OK, thanks. Andrew.
Re: [PATCH x86, java, PR63536] Fix java bootstrap for -mtune=intel/slm
On 10/15/2014 05:54 PM, Evgeny Stupachenko wrote: > The patch fixes java i686 bootstrap for -mtune=intel/slm. > > Recent changes triggered java to write a note on compilation for a > function without context. > > make check in progress > > Is it ok? I guess so, but I don't understand how any function ends up with a null DECL_CONTEXT. Nontheless, this must go to java-patc...@gcc.gnu.org Andrew.
Re: PING: Re: [patch 6/10] debug-early merge: Java front-end
On 20/05/15 23:32, Aldy Hernandez wrote: > Perhaps I should've sent this to the java-patches list. > > PING. OK, I believe it. Andrew.
Re: [patch] libjava testsuite
On 05/25/2015 08:29 PM, Andreas Tobler wrote: > Ok for trunk? OK, thanks. Andrew.
Re: [patch] libjava signal handling for FreeBSD (amd64/i386)
On 27/05/15 20:53, Andreas Tobler wrote: > Is this ok for trunk? Excellent, thanks. Andrew.
Re: [PATCH] Fix PR64044
On 11/24/2014 12:29 PM, Richard Biener wrote: > > The following fixes an issue I found when more aggressively > constant-folding from static initializers. The Java frontend > fails to provide an initializer for the classdollar field > it creates but nevertheless marks them with TREE_READONLY > whilst being static. > > Thus the following patch removes setting of TREE_READONLY. > > Bootstrap & regtest running on x86_64-unknown-linux-gnu. > > Ok? OK, thanks. Andrew.
Re: [PATCH] Implement libffi for AARCH64:ILP32
On 09/02/15 08:40, Andrew Pinski wrote: > For ILP32, we need to use long long types for ffi_arg and ffi_sarg. > And then we need to fix up the closure code to load cif, fn, and > user_data by 32bit instead of 64bits as they are stored as pointers in > C code. Would it make more sense to use int64_t rather than long long? Andrew.
Re: [patch] Provide a can_compare_and_swap_p target hook.
On 11/06/2014 05:57 PM, Andrew MacLeod wrote: > It looks like java is deciding whether or not GCC can inline atomic > operations or not, and if it can't, doesn't want the atomic > operations... which presumably means there is no dependency on > libatomic at runtime. > > A call to can_compare_and_swap_p(mode) is analogous to a compile time > version of folding atomic_always_lock_free(mode) to a constant... > Frankly that seems like a reasonable question for some front end to > ask... and elect not to emit atomic calls if so desired. (which is what > java is doing I think) > > whether it still needs to do that is a question for some java person. I did it because some targets did not have library support for some builtins, so a compile would fail with a (to a Java programmer) baffling error message. The Java operations certainly should use the generic builtins. Andrew.
Re: [patch] Provide a can_compare_and_swap_p target hook.
On 06/11/14 19:05, Andrew MacLeod wrote:
>
>
> 1) Given that the compiler *always* provides support via libatomic now
> (even if it is via locks), does that mean that VMSupportsCS8_builtin()
> should always return true?
>
> or should we map to that a call to __atomic_always_lock_free() ? (that
> always gets folded to a true or false at compile time) my guess is the
> latter?
Perhaps so. The problem is that some targets can't do CAS on 64-bit
doublewords.
> 2) and in compareAndSwapLong_builtin(), thre is a wonky bit:
>
> /* We don't trust flag_use_atomic_builtins for multi-word compareAndSwap.
> Some machines such as ARM have atomic libfuncs but not the multi-word
> versions. */
>if (can_compare_and_swap_p (mode,
>(flag_use_atomic_builtins
> && GET_MODE_SIZE (mode) <= UNITS_PER_WORD)))
> <..> /* generate 8 byte CAS */
>
> I gather we dont need to do anything special here anymore either? As
> an observation of inconsistency,
> compareAndSwapObject_builtin doesn't do that check before calling the 8
> byte CAS :
I believe that any machine which has 64-bit pointers and can do CAS
can do a 64-bit CAS. I'm worried about 32-bit machines trying to do a
64-bit CAS.
> 3) And finally, is flag_use_atomic_builtins suppose to turn them off
> completely? Right now it is passed in to the second parameter of
> can_compare_and_swap_p, which really just says can we compare and swap
> without calling a libfunc.. so currently if the flag is 0, but there
> is native support, the call is generated anyway. should that condition
> really be:
>
> if (flag_use_atomic_builtins)
>{
> <...> /* generate atomic call */
> }
I'm sorry, I really can't remember. I can't think of any reason to
want to turn off builtin support. You have to remember that all this
was written when our support for atomic builtins was seriously flaky
and we would just punt back to the user anything we hadn't written
yet.
Andrew.
[PATCH] Delete GCJ
As discussed. I think I should ask a Global reviewer to approve this one. For obvious reasons I haven't included the diffs to the deleted gcc/java and libjava directories. The whole tree, post GCJ-deletion, is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch if anyone would like to try it. Andrew. 2016-09-05 Andrew Haley * Makefile.def: Remove libjava. * Makefile.tpl: Likewise. * Makefile.in: Regenerate. * configure.ac: Likewise. * configure: Likewise. * gcc/java: Remove. * libjava: Likewise. Index: Makefile.in === --- Makefile.in (revision 239988) +++ Makefile.in (working copy) @@ -322,8 +322,6 @@ HOST_LIBELFLIBS = @libelflibs@ HOST_LIBELFINC = @libelfinc@ -EXTRA_CONFIGARGS_LIBJAVA = @EXTRA_CONFIGARGS_LIBJAVA@ - # -- # Programs producing files for the BUILD machine # -- @@ -1007,7 +1005,6 @@ maybe-configure-target-winsup \ maybe-configure-target-libgloss \ maybe-configure-target-libffi \ -maybe-configure-target-libjava \ maybe-configure-target-zlib \ maybe-configure-target-boehm-gc \ maybe-configure-target-rda \ @@ -1174,7 +1171,6 @@ all-target: maybe-all-target-winsup all-target: maybe-all-target-libgloss all-target: maybe-all-target-libffi -all-target: maybe-all-target-libjava all-target: maybe-all-target-zlib all-target: maybe-all-target-boehm-gc all-target: maybe-all-target-rda @@ -1268,7 +1264,6 @@ info-target: maybe-info-target-winsup info-target: maybe-info-target-libgloss info-target: maybe-info-target-libffi -info-target: maybe-info-target-libjava info-target: maybe-info-target-zlib info-target: maybe-info-target-boehm-gc info-target: maybe-info-target-rda @@ -1355,7 +1350,6 @@ dvi-target: maybe-dvi-target-winsup dvi-target: maybe-dvi-target-libgloss dvi-target: maybe-dvi-target-libffi -dvi-target: maybe-dvi-target-libjava dvi-target: maybe-dvi-target-zlib dvi-target: maybe-dvi-target-boehm-gc dvi-target: maybe-dvi-target-rda @@ -1442,7 +1436,6 @@ pdf-target: maybe-pdf-target-winsup pdf-target: maybe-pdf-target-libgloss pdf-target: maybe-pdf-target-libffi -pdf-target: maybe-pdf-target-libjava pdf-target: maybe-pdf-target-zlib pdf-target: maybe-pdf-target-boehm-gc pdf-target: maybe-pdf-target-rda @@ -1529,7 +1522,6 @@ html-target: maybe-html-target-winsup html-target: maybe-html-target-libgloss html-target: maybe-html-target-libffi -html-target: maybe-html-target-libjava html-target: maybe-html-target-zlib html-target: maybe-html-target-boehm-gc html-target: maybe-html-target-rda @@ -1616,7 +1608,6 @@ TAGS-target: maybe-TAGS-target-winsup TAGS-target: maybe-TAGS-target-libgloss TAGS-target: maybe-TAGS-target-libffi -TAGS-target: maybe-TAGS-target-libjava TAGS-target: maybe-TAGS-target-zlib TAGS-target: maybe-TAGS-target-boehm-gc TAGS-target: maybe-TAGS-target-rda @@ -1703,7 +1694,6 @@ install-info-target: maybe-install-info-target-winsup install-info-target: maybe-install-info-target-libgloss install-info-target: maybe-install-info-target-libffi -install-info-target: maybe-install-info-target-libjava install-info-target: maybe-install-info-target-zlib install-info-target: maybe-install-info-target-boehm-gc install-info-target: maybe-install-info-target-rda @@ -1790,7 +1780,6 @@ install-pdf-target: maybe-install-pdf-target-winsup install-pdf-target: maybe-install-pdf-target-libgloss install-pdf-target: maybe-install-pdf-target-libffi -install-pdf-target: maybe-install-pdf-target-libjava install-pdf-target: maybe-install-pdf-target-zlib install-pdf-target: maybe-install-pdf-target-boehm-gc install-pdf-target: maybe-install-pdf-target-rda @@ -1877,7 +1866,6 @@ install-html-target: maybe-install-html-target-winsup install-html-target: maybe-install-html-target-libgloss install-html-target: maybe-install-html-target-libffi -install-html-target: maybe-install-html-target-libjava install-html-target: maybe-install-html-target-zlib install-html-target: maybe-install-html-target-boehm-gc install-html-target: maybe-install-html-target-rda @@ -1964,7 +1952,6 @@ installcheck-target: maybe-installcheck-target-winsup installcheck-target: maybe-installcheck-target-libgloss installcheck-target: maybe-installcheck-target-libffi -installcheck-target: maybe-installcheck-target-libjava installcheck-target: maybe-installcheck-target-zlib installcheck-target: maybe-installcheck-target-boehm-gc installcheck-target: maybe-installcheck-target-rda @@ -2051,7 +2038,6 @@ mostlyclean-target: maybe-mostlyclean-target-winsup mostlyclean-target: maybe-mostlyclean-target-libgloss mostlyclean-target: maybe-mostlyclean-target-libffi -mostlyclean-target: maybe-mostlyclean-target-libjava mostlyclean-target: maybe-mostlyclean-target-zlib mostlyclean-target: maybe-mostlyclean-target-boe
Re: [PATCH] Delete GCJ
On 05/09/16 16:29, Matthias Klose wrote: > Please consider removing boehm-gc as well. The only other user is > --enable-objc-gc, which better should use an external boehm-gc. I can do that, but I do not want to do so with this patch. Andrew.
Re: [PATCH] Delete GCJ
On 05/09/16 17:15, Richard Biener wrote: > On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley > wrote: >> As discussed. I think I should ask a Global reviewer to approve this >> one. For obvious reasons I haven't included the diffs to the deleted >> gcc/java and libjava directories. The whole tree, post GCJ-deletion, >> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch >> if anyone would like to try it. > > Isn't there also java specific C++ frontend parts? There certainly are, but deleting them without breaking anything else is going to be rather delicate. I'm trying to do this one step at a time, rather cautiously. Andrew.
Re: [DOC PATCH] Rewrite docs for inline asm
On 04/04/14 20:48, dw wrote: > I do not have write permissions to check this patch in. We must fix that. Andrew.
Re: [PATCH] Delete GCJ
On 22/01/17 18:41, Per Bothner wrote: > In my opinion, all/most of these should be restored. Because of the historical interest? That's a good point, and perhaps I was too hasty. Sorry. Andrew.
Re: [PATCH] Delete GCJ
On 23/01/17 13:41, Jakub Jelinek wrote: > On Mon, Jan 23, 2017 at 04:51:44AM -0800, Per Bothner wrote: >> The last part is moot, as we should strive to not move pages and thus break >> links. > > I meant updating URLs in the pages when they refer to external web pages > which move over time (or switch from http to https, or disappear, etc.). > Gerald > does a great job handling that, but if there are too many pages for > historical purpose only, it will make his work harder. We can redirect to somewhere else. Andrew.
[PATCH] Loop splitting breaks with loops of pointer type
Loop splitting is fine when the control variable is of integer type,
but when it is a pointer type the upper bound of the new loop is
calculated incorrectly.
The calculation should be guard_init + (end-beg), but instead we do
guard_init - (end-beg).
Fixed thusly. Bootstrapped, regtested.
OK?
Andrew.
2017-03-08 Andrew Haley
PR tree-optimization/79894
* tree-ssa-loop-split.c (compute_new_first_bound): When
calculating the new upper bound, (END-BEG) should be added, not
subtracted.
Index: gcc/tree-ssa-loop-split.c
===
--- gcc/tree-ssa-loop-split.c (revision 245948)
+++ gcc/tree-ssa-loop-split.c (working copy)
@@ -436,7 +436,6 @@
if (POINTER_TYPE_P (TREE_TYPE (guard_init)))
{
enddiff = gimple_convert (stmts, sizetype, enddiff);
- enddiff = gimple_build (stmts, NEGATE_EXPR, sizetype, enddiff);
newbound = gimple_build (stmts, POINTER_PLUS_EXPR,
TREE_TYPE (guard_init),
guard_init, enddiff);
2017-03-08 Andrew Haley
PR tree-optimization/79894
* gcc.dg/tree-ssa/pr79943.c: New test.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr79943.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr79943.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr79943.c (revision 0)
@@ -0,0 +1,40 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fsplit-loops -fdump-tree-lsplit-details" } */
+/* { dg-require-effective-target int32plus } */
+
+#ifdef __cplusplus
+extern "C" void abort (void);
+#else
+extern void abort (void);
+#endif
+
+typedef struct {
+ int n;
+} region_t;
+
+void set (region_t *region) __attribute__((noinline));
+void doit (region_t *beg, region_t *end, region_t *limit)
+ __attribute__((noinline));
+
+region_t regions[10];
+
+void
+set (region_t *region) {
+ region->n = 1;
+}
+
+void
+doit (region_t *beg, region_t *end, region_t *limit) {
+ for (region_t *cur = beg; cur < end; cur++) {
+if (cur < limit) {
+ set(cur);
+}
+ }
+}
+
+int
+main (void) {
+ doit(®ions[0], ®ions[2], ®ions[10]);
+ if (regions[1].n != 1)
+abort();
+}
Re: [wwwdocs,Java] java/index.html -- fix formatting on gcc.gnu.org
On 16/04/16 21:31, Gerald Pfeifer wrote:
> On Sun, 10 Apr 2016, Andrew Hughes wrote:
>>> That said, looking at the page, and how since 2005 nearly all changes
>>> have been maintainance ones from me, is it really worthwhile keeping
>>> this (short of historic reasons)?
>> I guess the next news will be the removal of GCJ during the
>> GCC 7 development period, so its remaining shelf life should
>> be limited anyway.
>
> Soo, GCC 6 has branched -- would it make sense for you guys to
> start this removal?
Sounds good. OTOH, I don't think there's any great hurry.
> Somewhat related, any concerns if I were to remove
> https://gcc.gnu.org/java/status.html now?
>
> ("Status of GCJ as of GCC 3.2" _really_ is rather old.)
It's so old that I don't think it's of any use. However, I wonder if
it might make more sense to at least have a page saying that GCJ is
gone.
Andrew.
Re: [wwwdocs,Java] Remove java/status.html
On 17/04/16 17:09, Gerald Pfeifer wrote: > My recommendation is to handle that via java/index, which is the > main page, and redirect other GCJ pages to that one as we remove > them. > > Like in the following, for java/status.html. > > Are you fine with that? OK, thanks. Andrew.
Re: [PATCH] [AArch64] support -mfentry feature for arm64
On 04/15/2016 06:29 PM, Alexander Monakov wrote: > Alternatively: replace first nop with a short forward branch that > jumps over the rest of the pad, patch rest of the pad, patch the > initial forward branch. That may not be safe. Consider an implementation which looks ahead in the instruction stream and decodes the instructions speculatively. I suppse you could begin the block of instructions after the branch with an ISB. On balance, the trap sounds like the best plan. We do this in Java all the time: every method begins with a NOP, and we patch it either to a trap or to a call to the replacement code. Andrew.
Re: [PATCH] [AArch64] support -mfentry feature for arm64
On 04/18/2016 06:13 PM, Michael Matz wrote: > On Mon, 18 Apr 2016, Andrew Haley wrote: > >> On 04/15/2016 06:29 PM, Alexander Monakov wrote: >> >>> Alternatively: replace first nop with a short forward branch that >>> jumps over the rest of the pad, patch rest of the pad, patch the >>> initial forward branch. >> >> That may not be safe. Consider an implementation which looks ahead in >> the instruction stream and decodes the instructions speculatively. > > It should go without saying that patching instructions is followed by > whatever means necessary to flush any such caches on a particular > implementation (here after patching the jump, after patching the rest, and > after patching the first insn again, i.e. three times). That doesn't necessarily help you, though, without an ISB in the reading thread. Andrew.
Re: [PATCH] [AArch64] support -mfentry feature for arm64
On 18/04/16 18:34, Michael Matz wrote: > Hi, > > On Mon, 18 Apr 2016, Andrew Haley wrote: > >>>> That may not be safe. Consider an implementation which looks >>>> ahead in the instruction stream and decodes the instructions >>>> speculatively. >>> >>> It should go without saying that patching instructions is followed >>> by whatever means necessary to flush any such caches on a >>> particular implementation (here after patching the jump, after >>> patching the rest, and after patching the first insn again, >>> i.e. three times). >> >> That doesn't necessarily help you, though, without an ISB in the reading >> thread. > > I don't understand, which reading thread? We're writing, not reading > instructions. You mean other executing threads? Yes. > I will happily declare any implementation where it's impossible to > safely patch the instruction stream by flushing the respective > buffers or other means completely under control of the patching > machinery, to be broken by design. You can declare anything you want, but we have to program for the architectural specification. > What failure mode do you envision, exactly? It's easiest just to quote from the spec: How far ahead of the current point of execution instructions are fetched from is IMPLEMENTATION DEFINED. Such prefetching can be either a fixed or a dynamically varying number of instructions, and can follow any or all possible future execution paths. For all types of memory: The PE might have fetched the instructions from memory at any time since the last Context synchronization operation on that PE. Any instructions fetched in this way might be executed multiple times, if this is required by the execution of the program, without being re-fetched from memory. In the absence of an ISB, there is no limit on the number of times such an instruction might be executed without being re-fetched from memory. The ARM architecture does not require the hardware to ensure coherency between instruction caches and memory, even for locations of shared memory. So, if you write a bunch of instructions (which might have been pre-fetched) and then rewrite a NOP to jump to those instructions you need to make sure that the thread which might be running concurrently does an ISB. Note also: Memory accesses caused by instruction fetches are not required to be observed in program order, unless they are separated by an ISB or other context synchronization event. So, if you modify instruction memory in one thread, other threads may see those changes in a different order from the writing thread. Sure, the writing thread executes the cache maintenance instructions on its side, but you also need to do something on the side which is executing the instructions. I have wondered if it might be a good idea to use an inter-processor interrupt to force a context synchronization event across all PEs. Andrew.
Re: [PATCH] [AArch64] support -mfentry feature for arm64
On 04/19/2016 02:19 PM, Michael Matz wrote: > Well, yeah, that's traditional insn caches on multiple cores. From > user space you need kernel help for this, doing interprocess > interrupts to flush all such buffers on all cores (or at least those > potentially fetching stuff in the patched region, if such > granularity is possible). An implementation providing such is > non-broken :) Sure. If you know of any such facility in Linux userspace, please let me know. :-) But there are ways of doing patching sequences which don't require IPIs across all the cores; which was my point. > Alternatively the various invalidate cache instructions need to have > a form that invalidates the i$ on all cores. I'm fairly sure we haven't got that in the AArch64 architecture. Andrew.
Re: [PATCH] [AArch64] support -mfentry feature for arm64
On 04/19/2016 03:37 PM, Pedro Alves wrote: > On 04/19/2016 02:25 PM, Andrew Haley wrote: >> On 04/19/2016 02:19 PM, Michael Matz wrote: >> >>> Well, yeah, that's traditional insn caches on multiple cores. From >>> user space you need kernel help for this, doing interprocess >>> interrupts to flush all such buffers on all cores (or at least those >>> potentially fetching stuff in the patched region, if such >>> granularity is possible). An implementation providing such is >>> non-broken :) >> >> Sure. If you know of any such facility in Linux userspace, please let >> me know. :-) > > Sounds like a job for the sys_membarrier system call: > > https://lkml.org/lkml/2015/3/18/531 > https://lwn.net/Articles/369567/ > > I think it's available in Linux 4.3+. So it is, thanks. I'm guessing that might be good enough for full instruction synchronization barriers, but from looking at the kernel source I can't really tell. Andrew.
Re: [PATCH] Delete GCJ
On 10/09/16 12:59, NightStrike wrote: > Could we at least reach out and see if there's someone else who could > be the maintainer? I noticed gcj patches recently, so there's still > interest. 1. It's too late. We have been discussing this for a long time, and we're now doing what we decided. 2. Maintaining GCJ requires a lot of knowledge of both Java and GCC internals. There are very few people in the world with that knowledge, and I'm fairly sure I know them by name. 3. The Classpath library is very old and is unmaintained. The only practical way to update GCJ would be to use the OpenJDK class libraries instead, but updating GCJ to use those class libraries is a very substantial job. So, I cannot prevent anyone from coming along to maintain GCJ, and neither would I want to. However, such a proposal would have to be credible. It is a multi-engineer-year commitment, and not just any ordinary engineers. Andrew.
Re: [PATCH] Delete GCJ
On 30/09/16 11:27, Marek Polacek wrote: > Can we move forward with this patch, then? I've been travelling for several weeks. However, I'm back at my desk now, so I can move this forward. I have all the approvals and everybody has had time to respond. However, I'll need to pull some more recent changes into my tree and merge again. Andrew.
Re: [PATCH] Delete GCJ
On 05/09/16 17:25, Gerald Pfeifer wrote: > And here is the patch for the web pages. > > Note I did not include all the removed java/* contents. Is there > anything particular you'd like to retain there? No, please delete it all. Thanks, Andrew.
Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion
Pushed. 2016-09-30 Andrew Haley * MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion. Index: MAINTAINERS === --- MAINTAINERS (revision 240658) +++ MAINTAINERS (working copy) @@ -155,9 +155,6 @@ c++Jason Merrill c++Nathan Sidwell go Ian Lance Taylor -java Per Bothner -java Andrew Haley -java Tom Tromey objective-c/c++Mike Stump objective-c/c++Iain Sandoe @@ -352,6 +349,7 @@ Andrea Bona Paolo Bonzini Neil Booth +Per Bothner Robert Bowdidge Joel Brobecker Dave Brolley @@ -425,6 +423,7 @@ Wei Guozhi Mostafa Hagog Olivier Hainque +Andrew Haley Stuart Hastings Michael Haubenwallner Pat Haugen @@ -608,6 +607,7 @@ Philipp Tomsich Konrad Trifunovic Markus Trippelsdorf +Tom Tromey Martin Uecker David Ung Neil Vachharajani
Re: Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion
On 30/09/16 17:38, Rainer Orth wrote: > but both Per and Tom are still libcpp maintainers, so no need to add > them to the write-after-approval list. Ooh, I had no idea. Will fix, thanks. Andrew.
Re: [PATCH] Fix bootstrap with --enable-languages=all,go
On 30/09/16 23:16, Rainer Orth wrote: > me too, though mostly to have maximum test coverage (primarily on > Solaris). As expected, a x86_64-apple-darwin16 bootstrap with > --enable-objc-gc just failed for me. I'm testing the following patch > (on top of Jakub's). > > Rainer > > > 2016-10-01 Rainer Orth > > * configure.ac (target_libraries): Readd target-boehm-gc. > Restore --enable-objc-gc handling. > * configure: Regenerate. Thanks everybody. My apologies. Andrew.
Re: [PATCH] Delete GCJ
On 02/10/16 14:27, Andreas Schwab wrote:
> Things we may want to remove:
>
> - references to java in contrib (download_ecj, gcc_update,
> patch_tester.sh, update-copyright.py)
> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> - references to java in install.texi
Yes, that's true. Thanks for doing the search.
Andrew.
Re: [PATCH] Delete GCJ
On 04/10/16 09:39, Rainer Orth wrote: > Hi Matthias, > >> On 05.09.2016 17:13, Andrew Haley wrote: >>> As discussed. I think I should ask a Global reviewer to approve this >>> one. For obvious reasons I haven't included the diffs to the deleted >>> gcc/java and libjava directories. The whole tree, post GCJ-deletion, >>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch >>> if anyone would like to try it. >> >> still breaks bootstraps when configured with --enable-objc-gc. >> >> the immediate step should be to fix the bootstrap failure, as an additional >> step >> to remove boehm-gc from the gcc sources and be able to use an external >> boehm-gc. > > the first part is handled by my unreviewed patch > > https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html Looks obvious to me, fixes bootstrap. I think no-one will complain if you check it in. Andrew.
Re: [patch] Don't encode the minor version in the gcj abi version
On 28/04/16 08:55, Matthias Klose wrote: > Ok for the 6 branch and the trunk? OK, Andrew.
Re: [patch] Don't encode the minor version in the gcj abi version
On 04/28/2016 12:45 PM, Matthias Klose wrote: > yes, that looks good. Can't approve it myself. OK. Andrew.
Re: [PATCH] Make basic asm implicitly clobber memory
On 06/05/16 07:35, David Wohlferd wrote: > 1) I'm not clear precisely what problem this patch fixes. It's true > that some people have incorrectly assumed that basic asm clobbers > memory and this change would fix their code. But some people also > incorrectly assume it clobbers registers. I assume that's why Jeff > Law proposed making basic asm "an opaque blob that > read/write/clobber any register or memory location." A few more things: Jeff Law did propose this, but it's impossible to do because it inevitably causes reload failures. My argument in support of Bernd's proposal is that it makes sense from a *practical* software reliability point of view. It wouldn't hurt, and might fix some significant bugs. It's similar to the targets which always implicitly clobber "cc". It corresponds to what I always assumed basic asm did, and I'm sure that I'm not alone. This change might fix some real bugs and it is extremely unlikely to break anything. Andrew.
Re: [PATCH] Make basic asm implicitly clobber memory
On 05/20/2016 07:50 AM, David Wohlferd wrote: > At a minimum, suddenly forcing an unexpected/unneeded memory clobber > can adversely impact the optimization of surrounding code. This can > be particularly annoying if the reason for the asm was to improve > performance. And adding a memory clobber does add a dependency of > sorts, which might cause the location of the asm to shift in an > unfortunate way. And there's always the long-shot possibility that > some weird quirk or (very) badly-written code will cause the asm to > flat out fail when used with a memory clobber. And if this change > does produce any of these problems, I feel pity for whoever has to > track it down. OTOH, if a memory clobber does change code gen it probably changes it in a way which better fits user expectations, and perhaps it fixes a bug. That's a win, and it is far, far more important than any other consideration. Given that a basic asm statements has neither inputs nor outputs, it must have side effects to be useful. All this patch does is recognize that fact. I'm not saying your scenario won't occur, but it won't in the majority of cases. > I realize deprecation/removal is drastic. Especially since basic > asm (mostly) works as is. But fixing memory clobbers while leaving > the rest broken feels like half a solution, meaning that some day > we're going to have to fiddle with this again. Yes, we will undoubtedly have to fiddle with basic asm again. We should plan for deprecation. But I think you're close to the all-or-nothing fallacy: that because this patch doesn't solve all the problems with basic asm, it isn't worth having. Andrew.
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On 08/11/2015 07:54 PM, Jeff Law wrote: > It's probably time for the occasional discussion WRT dropping > gcj/libjava from the default languages and replace them with either Ada > or Go. > > gcj/libjava are dead IMHO. I have no objections. GCJ has been tremendously useful bootstrapping the OpenJDK ecosystem, but we no longer need it in order to have free Java. Andrew.
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On 12/08/15 15:44, Jeff Law wrote: > My inclination is to replace GCJ with Go, but Ian wasn't comfortable > with that when I suggested it a couple years ago. Because Go wasn't ready for prime time? Andrew.
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On 14/08/15 08:43, Richard Biener wrote: > So what about removing classpath from the repository? We still > retain basic language support via java/ javax/ and gnu/ that way > I believe. I don't think we do. Andrew.
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On 20/08/15 09:24, Matthias Klose wrote: > On 08/20/2015 06:36 AM, Tom Tromey wrote: >> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of >> Andrew> OpenJDK/IcedTea. >> >> Andrew Haley said the opposite here: >> >> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html > > if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj > available for the target platform is required. Starting with OpenJDK > 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8 > available on the cross platform. It might be possible to cross > build older OpenJDK versions, but this usually is painful. Sure, but we don't need GCJ going forward. I don't think that there are any new platforms to which OpenJDK has not been ported which will require GCJ to bootstrap. And even if there are, anybody who needs to do that can (and, indeed, should) use an earlier version of GCJ. It's not going to go away; it will always be in the GCC repos. And because newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK. Andrew.
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On 08/20/2015 03:57 PM, Andrew Hughes wrote: > - Original Message - >> On 20/08/15 09:24, Matthias Klose wrote: >>> On 08/20/2015 06:36 AM, Tom Tromey wrote: >>>> Andrew> No, it isn't. It's still a necessity for initial bootstrapping of >>>> Andrew> OpenJDK/IcedTea. >>>> >>>> Andrew Haley said the opposite here: >>>> >>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html >>> >>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj >>> available for the target platform is required. Starting with OpenJDK >>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8 >>> available on the cross platform. It might be possible to cross >>> build older OpenJDK versions, but this usually is painful. >> >> Sure, but we don't need GCJ going forward. I don't think that there >> are any new platforms to which OpenJDK has not been ported which will >> require GCJ to bootstrap. And even if there are, anybody who needs to >> do that can (and, indeed, should) use an earlier version of GCJ. It's >> not going to go away; it will always be in the GCC repos. And because >> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more >> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK. > > I don't see how we don't at present. How else do you solve the > chicken-and-egg situation of needing a JDK to build a JDK? I don't > see crossing your fingers and hoping there's a binary around > somewhere as a very sustainable system. That's what we do with GCC, binutils, etc: we bootstrap. > From a personal point of view, I need gcj to make sure each new > IcedTea 1.x and 2.x release bootstraps. Sure, but all that does is test that the GCJ bootstrap still works. And it's probably the only serious use of GCJ left. > I don't plan to hold my system GCC at GCC 5 for the next decade or > however long we plan to support IcedTea 2.x / OpenJDK 7. It's also > still noticeably faster building with a native ecj than OpenJDK's > javac. It would cause me and others a lot of pain to remove gcj at > this point. What exactly is the reason to do so, other than some > sudden whim? It's not a sudden whim: it's something we've been discussing for years. The only reason GCJ is still alive is that I committed to keep it going while we still needed it boot bootstrap OpenJDK. Maintaining GCJ in GCC is a significant cost, and GCJ has reached the end of its natural life. Classpath is substantially unmaintained, and GCJ doesn't support any recent versions of Java. Andrew.
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On 08/20/2015 05:03 PM, Andrew Hughes wrote: > The issue is that we're still supporting a version of OpenJDK/IcedTea where > there is no previous version (6). Surely OpenJDK 6 can build itself. And in the unlikely event of an entirely new architecture which has No OpenJDK we'd have to grab an old GCJ and build it with that. If GCJ is included as part of GCC but is not maintained and tested, it will soon rot. That isn't an option IMO. Andrew.
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
On 08/20/2015 05:38 PM, Richard Biener wrote: > So gij, witten in C++ is enough? No: the runtime library needs gcj. Andrew.
Re: [patch] [java] bump libgcj soname
On 02/01/16 14:40, Matthias Klose wrote: > > preparing for a test rebuild of the archive, and trying to run gcj-dbtool > (from > GCC 5) with libgcj16 (from GCC 6): > > $ gcj-dbtool -n /tmp/foo.db > libgcj failure: gcj linkage error. > Incorrect library ABI version detected. Aborting. > > Aborted (core dumped) > > natClassLoader.cc:_Jv_CheckABIVersion checks the ABI version, which is > defined as > > libjava/include/jvm.h:#define GCJ_CXX_ABI_VERSION (__GNUC__ * 10 + > __GNUC_MINOR__ * 1000) > > so this will be seen with everything directly linked to libgcj with a > libgcj16 > upgraded to GCC 6. So what to do? Bump the soname, or discard this check? I'd bump the soname. > In any case, GCJ_CXX_ABI_VERSION should be changed to not include > __GNUC_MINOR__ > anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so that it > won't change anymore with future releases from the gcc-5 branch? That's safe only if Classpath and libgcj are not changed at all. I guess we can guarantee that on the gcc-5 branch? Andrew.
Re: [patch] [java] bump libgcj soname
On 02/01/16 15:53, Matthias Klose wrote: >>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include >>> __GNUC_MINOR__ >>> >> anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so >>> >> that it >>> >> won't change anymore with future releases from the gcc-5 branch? >> > >> > That's safe only if Classpath and libgcj are not changed at all. > why? Because of the way that gcj's linkage works. If you change any of the vtable/itable indexes your program will crash. Andrew.
Re: [patch] [java] bump libgcj soname
On 03/01/16 11:38, Matthias Klose wrote: > On 02.01.2016 17:11, Andrew Haley wrote: >> On 02/01/16 15:53, Matthias Klose wrote: >>>>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include >>>>> __GNUC_MINOR__ >>>>>>> anymore. Maybe for the gcc-5-branch, set it unconditionally to 3 so >>>>>>> that it >>>>>>> won't change anymore with future releases from the gcc-5 branch? >>>>> >>>>> That's safe only if Classpath and libgcj are not changed at all. >>> why? >> >> Because of the way that gcj's linkage works. If you change any of the >> vtable/itable indexes your program will crash. > > Right, but this no change compared to the 4.x.y releases. > > This is what I committed to the trunk. > > So what to do with the gcc-5 branch? Apply the same patch to jvm.h, or fix > the > minor version to 3? The latter would be compatible at least with the 5.3 > release. Neither. If you link a program with libgcj then you need to recompile it when a new version of libgcj comes along. It has always been this way. Why change this rule now, at this stage of GCJ's life? Andrew.
Re: [patch] [java] bump libgcj soname
On 03/01/16 15:52, Matthias Klose wrote: > No, libgcj versions up to 4.9.3 didn't change the value for releases taken > from > the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same > GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* > GCJ_CXX_ABI_VERSIONs. > >> > Why change this rule now, at this stage of GCJ's life? > This was changed by the change of the version schema, an unintential change > for > GCJ_CXX_ABI_VERSION. I want to keep it that way, not change it with every > release from the gcc-5 branch. Because effectively we've done an arithmetic shift left on the GCC version numbering, I guess? So where we would have had 5.1.1, 5.1.2, 5.1.3, we now have 5.1, 5.2, 5.3? If that's the idea, your patch is OK. Thanks, Andrew.
Re: ASAN merge...
On 11/14/2012 01:49 PM, Richard Earnshaw wrote: > Please please don't get into the habit of calling it ARM32 and ARM64, > you're just sowing confusion; there are good reasons why those names > weren't adopted (some technical, some not) and I'm not about to rehash > them all now. AArch32 and AArch64 aren't that much harder to type and > they are completely unambiguous. And they can't be pronounced in any reasonable way. I think you're going to lose this one. Andrew
Re: [patch] update zlib to 1.2.7
On 11/16/2012 05:34 PM, Matthias Klose wrote: > this is an update of zlib from 1.2.5 to 1.2.7, the compressed changes are > attached. No merge glitches. Ok for the trunk? Fine by me, because I guess we should keep up with supported zlib, as long as it all still works. Andrew.
Re: [PATCH] Fix linking with -findirect-dispatch
On 04/26/2013 12:22 PM, Matthias Klose wrote: > I do see this now too, however the root of the problem seems to be a linker > which defaults to --as-needed (which is the case on SuSe afaik). Is this a non-standard thing? So SuSe has a special --configure option which does this? We can always patch in --no-as-needed Andrew.
Re: Avoid privatization of TLS variables
I may be guilty of missing a crucial point here, but: why do we care about having a small limit of static TLS variables? We surely could allocate, say, a megabyte of static TLS for each thread. We already allocate 64M for the thread-local malloc arena, after all. It doesn't cost anything beyond a little address space. What am I missing? Andrew.
Re: Avoid privatization of TLS variables
On 27/09/14 08:56, Andrew Haley wrote: > I may be guilty of missing a crucial point here, but: why do we care > about having a small limit of static TLS variables? > > We surely could allocate, say, a megabyte of static TLS for each > thread. We already allocate 64M for the thread-local malloc arena, On 64-bit systems, I mean. > after all. It doesn't cost anything beyond a little address space. > > What am I missing? > > Andrew. >
Re: [PATCH] Fix typo in `aot-compile' option list
On 06/20/2013 09:09 PM, Roland Lutz wrote: > Signed-off-by: Roland Lutz > --- > libjava/contrib/aot-compile.in |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libjava/contrib/aot-compile.in b/libjava/contrib/aot-compile.in > index 91cfc67..2ee6739 100644 > --- a/libjava/contrib/aot-compile.in > +++ b/libjava/contrib/aot-compile.in > @@ -52,7 +52,7 @@ try: > sys.argv[1:], > "M:C:D:m:c:l:e:", > ["make=", "gcj=", "dbtool=", > - "makeflags=" "gcjflags=", "ldflags=", > + "makeflags=", "gcjflags=", "ldflags=", >"exclude="]) > srcdir, dstdir = args > except: > OK with a ChangeLog entry. Andrew.
Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer
On 08/08/2012 11:08 PM, Dodji Seketeli wrote: > OK to commit? Looks good, but what sets LIBXML2_NEW_BUFFER ? Andrew.
Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer
On 06/21/2013 12:19 PM, Daniel Veillard wrote: > On Fri, Jun 21, 2013 at 12:13:35PM +0100, Andrew Haley wrote: >> On 08/08/2012 11:08 PM, Dodji Seketeli wrote: >>> OK to commit? >> >> Looks good, but what sets LIBXML2_NEW_BUFFER ? > > I lack context but I think I can answer that one :) > > LIBXML2_NEW_BUFFER is a libxml2 public macro from > > /* > * LIBXML2_NEW_BUFFER: > * > * Macro used to express that the API use the new buffers for > * xmlParserInputBuffer and xmlOutputBuffer. The change was > * introduced in 2.9.0. > */ > > http://xmlsoft.org/html/libxml-tree.html#LIBXML2_NEW_BUFFER Sure, but there's no point adding it to libgcj if it's not set by anything. It needs an autoconf macro or somesuch. Andrew.
Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer
On 06/24/2013 09:13 AM, Dodji Seketeli wrote: > Just to make sure I understand what you are saying; do you mean that the > accessor macro GET_XML_OUTPUT_BUFFER_SIZE (that depends on > LIBXML2_NEW_BUFFER) shouldn't be defined in > libjava/classpath/native/jni/xmlj/xmlj_io.c but somewhere else by an > autoconf macro? If so, maybe you should elaborate more on what you have > in mind exactly as I am not really well acquainted with (the configury > of) gnu classpath. I did this thing quickly so that the build doesn't > break on newer versions of libxml2. OK, I get it now, thanks. Andrew.
Re: fatal error: gnu/stubs-32.h: No such file
On 07/29/2013 02:06 PM, FX wrote:
> +build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
> +either:
> +
> +@itemize @bullet
> +@item having 32-bit libc developer package properly installed (the exact
> +name of the package depends on your distro); otherwise, you may encounter an
> +error such as @samp{fatal error: gnu/stubs-32.h: No such file}
> +@item building GCC as a 64-bit only compiler, by configuring with the
> +option @option{--disable-multilib}
> +@end itemize
Looks good.
This should be
"Make sure you either have the 32-bit libc developer package properly
installed (the exact name of the package depends on your distro) or
you must build GCC as a 64-bit-only compiler by configuring with the
--disable-multilib option. Otherwise, you may encounter an
error such as @samp{fatal error: gnu/stubs-32.h: No such file}
Re: fatal error: gnu/stubs-32.h: No such file
On 07/29/2013 02:55 PM, Bruce Korb wrote: > On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley wrote: > >> There should be a better diagnostic. > > If you remember, the start of this thread was: > >> Why is it that configure worked but stubs-32.h was not found? > > That is the correct thing to do. The reply, basically, was: > > It's too hard. It was "This is possible, but it's tricky, and it's really important to get it right. We don't want a half-arsed patch." >>> But we know people are running into this issue and reporting it. >> Yes. But that on its own is not sufficient to change the default > > That's a pretty obnoxious comment. Oh dear. > I translate it as, "I don't care if people are having trouble. That's a mistranslation. It means that there are other criteria beyond some people having trouble. Such as, we really want multilibs to be built. > It is a nuisance to me to do that and anyone building GCC should > already know they need -devel for 32 bits." I guess > I can be obnoxious, too. But slightly more politely put: > >> No, we aren't. We're disagreeing about whether it's acceptable to >> enable a feature by default that breaks the compiler build half way >> through with an obscure error message. Real systems need features that >> aren't enabled by default sometimes. > > The fundamental issue, to me, is: What do you do when you cannot > proceed? > > I think you should detect the issue as *soon as practical* and then > *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. Yes! Yes! Yes! Andrew.
Backport from trune:
I think this one is obvious/trivial, but I'll ask anyway.
OK?
Andrew.
2013-08-12 Andrew Haley
Backport from mainline:
* 2013-07-11 Andreas Schwab
* config/aarch64/aarch64-linux.h (CPP_SPEC): Define.
Index: gcc/config/aarch64/aarch64-linux.h
===
--- gcc/config/aarch64/aarch64-linux.h (revision 201661)
+++ gcc/config/aarch64/aarch64-linux.h (working copy)
@@ -23,6 +23,8 @@
#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64.so.1"
+#define CPP_SPEC "%{pthread:-D_REENTRANT}"
+
#define LINUX_TARGET_LINK_SPEC "%{h*} \
%{static:-Bstatic} \
%{shared:-shared} \
Re: [patch java]: Avoid looping over the end_params_node in put_decl_node
On 03/22/2013 08:13 AM, Kai Tietz wrote: > Tested for i686-w64-mingw32, x86_64-w64-mingw32, and > x86_64-unknown-linux-gnu. Ok for apply? Yes, thanks. Andrew.
Re: [patch libffi]: Make sure code is position-independent for x64 targets
On 03/22/2013 07:42 AM, Kai Tietz wrote: > Tested for x86_64-w64-mingw32, and for upcoming x86_64-pc-cygwin > target. Ok for apply? Yes, that's fine. Andrew.
Re: [PATCH] Enable java for aarch64
On 04/13/2013 07:21 PM, Andreas Schwab wrote: > # of unexpected failures 29 Looks basically OK. What were the failures, though? Andrew.
Re: [DOC PATCH] Rewrite docs for inline asm
On 04/25/2014 04:43 PM, James Greenhalgh wrote: > Beyond comments on ChangeLog formatting, the review for this patch seems > to have stalled again. > > The patch has been in review for two months now, with broadly positive > comments > and all suggestions made thus far have been incorporated. I'd therefore like > to > > *ping* > > this on David's behalf and try to get the review moving again. We're waiting for Joseph Myers or, at a pinch, a maintainer with global write privs. Andrew.
Re: [DOC PATCH] Rewrite docs for inline asm
On 04/26/2014 10:33 PM, Gerald Pfeifer wrote: >>> +any symbols it references. This may result in those symbols getting >>> discarded >>> >> +by GCC as unreferenced. > We can omit "by GCC" here. We can, but we should not. We should avoid the passive voice like the plague in technical documentation, even if doing so leads to some slight redundancy. Andrew.
Re: [DOC PATCH] Rewrite docs for inline asm
On 04/27/2014 11:56 AM, Richard Kenner wrote: > any symbols it references. This may result in those symbols getting > discarded by GCC as unreferenced. >>> >>> We can omit "by GCC" here. >> >> We can, but we should not. We should avoid the passive voice like the >> plague in technical documentation, even if doing so leads to some >> slight redundancy. > > I agree, but that's still passive voice (you need not omit the actor to be > using passive voice)! Active voice (which is indeed preferred) is "This > may result in GCC discarding those symbols as unreferenced." Indeed. That's definitely better. Andrew.
Re: [DOC PATCH] Rewrite docs for inline asm
On 05/05/2014 09:23 PM, Gerald Pfeifer wrote: > Understood. Let's see that we can get an update committed soon. > We can always improve on it further later on, which then will be > a lot easier to do, review, and get pushed. Yes. We already know that this is better than the current docs. Let's check it in. Andrew.
Re: [DOC PATCH] Rewrite docs for inline asm
On 05/29/2014 11:22 AM, Eric Botcazou wrote: >> Yes. We already know that this is better than the current docs. >> Let's check it in. > > As far as I can see you did it, but didn't add a ChangeLog entry (so David > isn't properly credited with the rewrite)? Fixed. Thanks, Andrew.
Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs
On 02/19/2014 09:03 AM, Richard Biener wrote: > On Tue, 18 Feb 2014, Richard Biener wrote: > >> >> The following two pieces fix the fallout of >> >> 2013-05-22 Mark Mitchell >> Sandra Loosemore >> >> * configure.ac (dbexecdir): Base on $(toolexeclibdir), not >> $(libdir). >> ... >> >> that makes a wreck out of my 4.9-based libjava installs. >> >> First it avoids to break dbexecdir with MULTSUBDIR= by removing >> the redundant but non-version-specific-aware multilib addition. >> >> Second, it makes sure that gcc_version, used in the >> version-specific path, is defined at all in classpath/ and its >> subdirs. >> >> Tested for my particular configuration, I'll do a default, >> non-version-specific one as well (but expect no changes). >> >> Ok for trunk? > > In addition to my weird non-multilib version-specific variant > I now tested regular non-version-specific and multilib variant > as well as version-specific multilib variant and all looks ok. > > Thus, > > Ok for trunk? It may be that someone understands this, but I don't. What does this change do? Andrew.
Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs
On 02/19/2014 09:34 AM, Richard Biener wrote: > Sandras patch was supposed to introduce support > for --enable-version-specific-runtime-libs in libgcj (but obviously > it failed, given the result above). Sandra? You're very quiet. What say you? I don't want this ping-ponging. Andrew.
Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs
On 02/19/2014 04:38 PM, Sandra Loosemore wrote: > I am OK with Richard's fix. Fine by me then, Andrew.
Re: [PATCH] libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c: Be sure 'errbuf' always be zero terminated.
On 07/30/2014 04:01 PM, Chen Gang wrote: > I shall stop making this kind of patch, next. The reason is that I worry > about what I have done have negative effect to others. And next, I shall > try to send another kinds of patches for gcc when I have time. > > Many persons or companies use open source who never give thanks or > contribution back to open source. But open source (especially, > fundamental software) still provide common contributions to outside. > > What I have done is only for contribution back to open source, so I can > understand none-reply from open source (at least, it is not the excuse > to let myself stop). But what I worry about is whether bother others. You only posted it yesterday. It certainly looks reasonable enough, but you surely don't expect an instant response. By the way, the correct mailing list is java-patc...@gcc.gnu.org. Andrew.
Re: [PATCH, libjava]: Avoid suggest parentheses around comparison in operand of '|' in java/lang/natObject.cc
On 03/10/2014 08:13 PM, Uros Bizjak wrote: > OK for mainline SVN and release branches? Sure. You don't need approval for pa Thanks, Andrew.
Re: [PATCH, libjava]: Avoid suggest parentheses around comparison in operand of '|' in java/lang/natObject.cc
On 03/10/2014 08:13 PM, Uros Bizjak wrote: > OK for mainline SVN and release branches? Sure. You don't need approval for patches that are obviously correct/trivial. Thanks, Andrew.
UBSan fix: avoid undefined behaviour in bitmask
UBSan detected that we were trying to set a non-existent bit in a mask.
I don't think it has mattered before now because when this happens the
value in the mask is not used. However, better safe than sorry.
Andrew.
2014-03-28 Andrew Haley
* boehm.c (mark_reference_fields): Avoid unsigned integer overflow
when calculating an index into a bitmap descriptor.
Index: gcc/java/boehm.c
===
--- gcc/java/boehm.c(revision 208839)
+++ gcc/java/boehm.c(working copy)
@@ -107,7 +107,11 @@
bits for all words in the record. This is conservative, but the
size_words != 1 case is impossible in regular java code. */
for (i = 0; i < size_words; ++i)
- *mask = (*mask).set_bit (ubit - count - i - 1);
+ {
+ int bitpos = ubit - count - i - 1;
+ if (bitpos >= 0)
+ *mask = (*mask).set_bit (bitpos);
+ }
if (count >= ubit - 2)
*pointer_after_end = 1;
Re: Remove obsolete Solaris 9 support
On 04/16/2014 12:16 PM, Rainer Orth wrote: > * I'm removing the check from classpath. Again, I'm > uncertain if this is desirable. In the past, classpath changes were > merged upstream by one of the libjava maintainers. We should not diverge from GNU Classpath unless there is a strong reason to do so. Andrew.
Re: [wwwdocs,Java] Obsolete GCJ FAQ entry for Solaris?
On 12/21/2012 04:02 AM, Gerald Pfeifer wrote: > PING. > > On Fri, 2 Nov 2012, Gerald Pfeifer wrote: >> Rainer (or others), >> >> the FAQ entry below seems obsolete to me (dates back more than a >> decade). Shall we remove it, or is there something else we still >> should document (in addition to gcc/doc/install.texi)? OK, thanks. Andrew.
Re: building binutils from same directory as gcc
On 10/30/2011 01:51 PM, Gerald Pfeifer wrote: > Why not just declare > that building from the same directory is not support and have one > simple set of instructions that always works, as opposed to "this > ought to work with snapshots but not with direct checkouts"? That's right. Is there ever any advantage to building in-srcdir? I'm not aware of one. Andrew.
Re: building binutils from same directory as gcc
On 11/01/2011 04:51 PM, Mike Stump wrote: > On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote: >> On 10/30/2011 01:51 PM, Gerald Pfeifer wrote: >>> Why not just declare >>> that building from the same directory is not support and have one >>> simple set of instructions that always works, as opposed to "this >>> ought to work with snapshots but not with direct checkouts"? >> >> That's right. Is there ever any advantage to building in-srcdir? > > Yes. You can do configure && make && make install. Huh? I do that all the time without building in-srcdir. I need a path to "configure", but that'll always be true for everyone who doesn't have "." in their PATH. Andrew.
Re: building binutils from same directory as gcc
On 11/02/2011 05:11 PM, Mike Stump wrote: > On Nov 2, 2011, at 2:42 AM, Andrew Haley wrote: >> On 11/01/2011 04:51 PM, Mike Stump wrote: >>> On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote: >>>> On 10/30/2011 01:51 PM, Gerald Pfeifer wrote: >>>>> Why not just declare >>>>> that building from the same directory is not support and have one >>>>> simple set of instructions that always works, as opposed to "this >>>>> ought to work with snapshots but not with direct checkouts"? >>>> >>>> That's right. Is there ever any advantage to building in-srcdir? >>> >>> Yes. You can do configure && make && make install. >> >> Huh? > > Ah, yes, yet another advantage, one can also do: > > ./configure && make && make install Of course. That's what "building in-srcdir" means. > :-) I do realize that you may not choose to value the feature, but > that doesn't mean that everyone has the same valuation you have. Sure, but that doesn't answer the question, which was "is there ever any advantage to building in-srcdir?" The answer "Yes: one can build in srcdir" doesn't quite do it! Andrew.
Re: [PATCH] Set correct source location for deallocator calls
On 08/30/2012 03:28 PM, Richard Henderson wrote: > On 08/17/2012 03:02 PM, Dehao Chen wrote: >> I spend a whole day working on this, but find it very difficult to add >> such a java test because: >> >> * First, libjava testsuits are all runtime tests, i.e., it compiles >> the byte code to native code, execute it, and compares the output to >> expected output. There is no way to scan the assembly. >> * Though there is a way to derive the line number at runtime in java >> (using Exception().getStackTrace()), this method only works on VM, and >> the gcj generated native code does not get the lineno. >> >> Any suggestions on this? > > Hmm, not from me, unfortunately. Cc'ing the java list for clues. > I won't hang up the main patch for this though. Fair enough. As Bryce said, line numbers should work if you have addr2line installed. Can't we scan the assembly? Is the problem simply that the logic to scan the assembly code isn't present in the libgcj testsuite? Andrew.
