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

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

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

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

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

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

<    1   2