Re: Should ARMv8-A generic tuning default to -moutline-atomics

hat we should not change codegen for an existing GCC release series unless there is a bug. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

[PATCH] Loop splitting breaks with loops of pointer type

? Andrew. 2017-03-08 Andrew Haley <a...@redhat.com> 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-s

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

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 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/j

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

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 > > >

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.

Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion

Pushed. 2016-09-30 Andrew Haley <a...@redhat.com> * MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion. Index: MAINTAINERS === --- MAINTAINERS (revision

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.

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

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.

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 <a...@redhat.com> > 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

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.

[PATCH] Delete GCJ

like to try it. Andrew. 2016-09-05 Andrew Haley <a...@redhat.com> * Makefile.def: Remove libjava. * Makefile.tpl: Likewise. * Makefile.in: Regenerate. * configure.ac: Likewise. * configure: Likewise. * gcc/java: Remove. * libjava: Li

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] 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

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

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] 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] [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,

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

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. &

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 re

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

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: [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

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

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.

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. > >

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? >>

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 >

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: [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

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

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

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

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, 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

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 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 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

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] libjava testsuite

On 05/25/2015 08:29 PM, Andreas Tobler wrote: Ok for trunk? OK, thanks. 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] 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

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

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

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

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

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.

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

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

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

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

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

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

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:

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

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: [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

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

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

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

Re: Remove obsolete Solaris 9 support

On 04/16/2014 12:16 PM, Rainer Orth wrote: * I'm removing the sys/loadavg.h 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

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 a...@redhat.com * boehm.c

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.

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 m...@codesourcery.com Sandra Loosemore san...@codesourcery.com * configure.ac (dbexecdir): Base on

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] 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

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] 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 sch...@suse.de 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

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

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

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

Backport from trune:

I think this one is obvious/trivial, but I'll ask anyway. OK? Andrew. 2013-08-12 Andrew Haley a...@redhat.com Backport from mainline: * 2013-07-11 Andreas Schwab sch...@suse.de * config/aarch64/aarch64-linux.h (CPP_SPEC): Define. Index: gcc/config/aarch64/aarch64

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

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 a...@redhat.com 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

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

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

Re: [PATCH] Fix typo in `aot-compile' option list

On 06/20/2013 09:09 PM, Roland Lutz wrote: Signed-off-by: Roland Lutz rl...@hedmen.org --- 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

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

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: [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: [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

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

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: 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 zad...@naturalbridge.com 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

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: [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,

Re: [PATCH] Set correct source location for deallocator calls

On 09/08/2012 10:42 PM, Dehao Chen wrote: I've added a libjava unittest which verifies that this patch will not break Java debug info. I've also incorporated Richard's review in the previous mail. Attached is the new patch, which passed bootstrap and all gcc/libjava testsuites on x86. Is it

Re: [PATCH] Set correct source location for deallocator calls

On 09/04/2012 09:31 PM, Dehao Chen wrote: Looks like even with addr2line properly installed, the gcj generated code cannot get the correct source file/lineno. Do I need to pass in #javac stacktrace.java #java stacktrace stacktrace.e(stacktrace.java:42) stacktrace.d(stacktrace.java:38)

Re: [PATCH] Set correct source location for deallocator calls

On 09/04/2012 05:07 PM, Dehao Chen wrote: On Thu, Aug 30, 2012 at 9:33 AM, Richard Henderson r...@redhat.com wrote: On 08/30/2012 08:20 AM, Andrew Haley wrote: Is the problem simply that the logic to scan the assembly code isn't present in the libgcj testsuite? Yes, exactly. For this case

Re: [PATCH] Set correct source location for deallocator calls

On 09/04/2012 05:32 PM, Bryce McKinlay wrote: On Tue, Sep 4, 2012 at 5:07 PM, Dehao Chen de...@google.com wrote: On Thu, Aug 30, 2012 at 9:33 AM, Richard Henderson r...@redhat.com wrote: On 08/30/2012 08:20 AM, Andrew Haley wrote: Is the problem simply that the logic to scan the assembly code

  1   2   >