ard that 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
?
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
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
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.
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
>>>
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,ming
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
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.
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
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.
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
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
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
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.
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.
On 04/04/14 20:48, dw wrote:
> I do not have write permissions to check this patch in.
We must fix that.
Andrew.
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 clobbe
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 as
On 04/28/2016 12:45 PM, Matthias Klose wrote:
> yes, that looks good. Can't approve it myself.
OK.
Andrew.
On 28/04/16 08:55, Matthias Klose wrote:
> Ok for the 6 branch and the trunk?
OK,
Andrew.
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
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
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.
&
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
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
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.
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
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
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.
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?
>> >
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.
>
> Abor
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
> regre
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.
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
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 th
On 08/20/2015 05:38 PM, Richard Biener wrote:
> So gij, witten in C++ is enough?
No: the runtime library needs gcj.
Andrew.
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
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
>>&
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:
>>
>> h
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.
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.
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 Ope
On 27/05/15 20:53, Andreas Tobler wrote:
> Is this ok for trunk?
Excellent, thanks.
Andrew.
On 05/25/2015 08:29 PM, Andreas Tobler wrote:
> Ok for trunk?
OK, thanks.
Andrew.
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.
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_
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
> w
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
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_
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 fu
On 10/07/2014 09:31 AM, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK, thanks.
Andrew.
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.
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 wro
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
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 n
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
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 thre
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
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
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 sou
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.
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 c
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 docu
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 documentati
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
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 reaso
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):
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.
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.
On 02/19/2014 04:38 PM, Sandra Loosemore wrote:
> I am OK with Richard's fix.
Fine by me then,
Andrew.
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.
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
>> $(l
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
On 12/20/2013 10:15 PM, Andreas Tobler wrote:
> Ok for gcc trunk?
OK, thanks.
Andrew.
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
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".
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
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 fro
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.
>>
>&
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.
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-li
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?
>
>
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 a
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
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 conte
On 08/08/2012 11:08 PM, Dodji Seketeli wrote:
> OK to commit?
Looks good, but what sets LIBXML2_NEW_BUFFER ?
Andrew.
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/lib
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 pat
On 04/13/2013 07:21 PM, Andreas Schwab wrote:
> # of unexpected failures 29
Looks basically OK. What were the failures, though?
Andrew.
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.
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.
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
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.
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 AA
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 hoo
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.
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.
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.
>
>
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
On 09/04/2012 06:17 PM, Bryce McKinlay wrote:
> On Tue, Sep 4, 2012 at 6:12 PM, Andrew Haley wrote:
>
>>> He's also planning to use it for libgo, and other gcc runtime libs
>>> have indicated interest. It doesn't have to work on all platforms, and
>&g
1 - 100 of 164 matches
Mail list logo
