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
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 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 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 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
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
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
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/07/2014 09:31 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK, thanks.
Andrew.
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
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
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
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/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
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
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
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 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
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 04:38 PM, Sandra Loosemore wrote:
I am OK with Richard's fix.
Fine by me then,
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 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 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
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 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:
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 09/30/2011 08:54 PM, Joseph S. Myers wrote:
On Fri, 30 Sep 2011, Ramana Radhakrishnan wrote:
On 26 July 2011 10:01, Dr. David Alan Gilbert david.gilb...@linaro.org
wrote:
+
+extern unsigned int __write(int fd, const void *buf, unsigned int count);
Why are we using __write instead of
Two patches, both in trunk for some time, which fix crashes on ARM.
Andrew.
2011-10-04 Andrew Haley a...@redhat.com
* src/arm/ffi.c (FFI_INIT_TRAMPOLINE): Clear icache.
Index: libffi/src/arm/ffi.c
===
--- libffi/src/arm
On 10/09/2011 12:09 PM, Matthias Klose wrote:
This did break libobjc and libjava on arm-linux-gnueabi.
libobjc now has an undefined reference to _Unwind_decode_target2, which can be
avoided with
--- libobjc/exception.c.orig2011-07-21 15:33:57.0 +
+++ libobjc/exception.c
On 04/03/2012 11:53 AM, Richard Earnshaw wrote:
Now, I wonder why the dynamic linker cannot figure out the ABI itself
by means of using ELF flags or so?
There are no ELF flags for this in executables. The attributes only
apply to object files and anyway they are too expensive to decode at
This adds support for the new (Version 51.0) class file format. It
doesn't actually generate code for invokedynamic bcause we don't have
any runtime support yet, but it's a start. jcf-dump prints all of the
new attributes.
Andrew.
2012-04-11 Andrew Haley a...@redhat.com
* jcf.h
[-Werror=unused-function]
jcf_parse_bootstrap_methods (JCF* jcf, int attribute_length ATTRIBUTE_UNUSED)
^
cc1plus: all warnings being treated as errors
make[3]: *** [java/jcf-parse.o] Error 1
make[3]: *** Waiting for unfinished jobs
Sorry.
Andrew.
2012-04-11 Andrew Haley
On 04/11/2012 04:57 PM, Rainer Orth wrote:
Ok for mainline?
Rainer
2012-04-11 Rainer Orth r...@cebitec.uni-bielefeld.de
* jcf-dump.c (print_constant): Cast JPOOL_USHORT2, JPOOL_USHORT1
results to long to match formats.
Sure. Sorry for the noise.
I wonder what
On 04/20/2012 01:57 PM, Dinar Temirbulatov wrote:
Here is the patch that adds support for divide 64-bit by constant for
32-bit target machines, this patch was tested on arm-7a with no new
regressions, also I am not sure on how to avoid for example i686
targets since div operation there is fast
On 04/27/2012 10:30 PM, Richard Henderson wrote:
We can perform a single-copy atomic load with an ldrexd insn.
If the load is all we care about, we need not pair this with
a strexd.
Can we? It's good to know. I have had a long email exchange with
engineers at ARM, and they would not say that
On 04/30/2012 11:50 AM, Richard Earnshaw wrote:
On 30/04/12 09:51, Andrew Haley wrote:
On 04/27/2012 10:30 PM, Richard Henderson wrote:
We can perform a single-copy atomic load with an ldrexd insn.
If the load is all we care about, we need not pair this with
a strexd.
Can we? It's good
On 05/17/2012 12:14 AM, Benjamin De Kosnik wrote:
Allows use of --enable-symvers=gnu-versioned-namespace while
configuring in libjava. The rest of the target libs that use
--enable-symvers already handle this. As per libstdc++/52700.
Pretty simple, but will wait for OK for trunk/branch
On 07/30/2012 03:18 PM, Julian Brown wrote:
There are two issues in play here:
1. Exception-handling is handled in a target-specific way for ARM,
defined in the EHABI document (Exception handling ABI for the ARM
architecture, IHI 0038A). However, no mention of forced unwinding is
made in
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,
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
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
On 09/04/2012 06:08 PM, Bryce McKinlay wrote:
On Tue, Sep 4, 2012 at 5:39 PM, Andrew Haley a...@redhat.com wrote:
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
On 09/04/2012 06:17 PM, Bryce McKinlay wrote:
On Tue, Sep 4, 2012 at 6:12 PM, Andrew Haley a...@redhat.com 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
I can't see how it would be any less
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 a multicore ARM, you really do have to clear both caches, not just the
dcache. This bug may exist in other ports too.
Andrew.
2011-07-11 Andrew Haley a...@redhat.com
* src/arm/ffi.c (FFI_INIT_TRAMPOLINE): Clear icache.
diff --git a/src/arm/ffi.c b/src/arm/ffi.c
index 885a9cb
On 12/07/11 10:12, Richard Earnshaw wrote:
On 11/07/11 17:23, Andrew Haley wrote:
On a multicore ARM, you really do have to clear both caches, not just the
dcache. This bug may exist in other ports too.
Andrew.
2011-07-11 Andrew Haley a...@redhat.com
* src/arm/ffi.c
On 21/07/11 16:33, Joseph S. Myers wrote:
On Tue, 12 Jul 2011, Andrew Haley wrote:
*(unsigned int*) __tramp[0] = 0xe92d000f; /* stmfd sp!, {r0-r3} */ \
*(unsigned int*) __tramp[4] = 0xe59f; /* ldr r0, [pc] */ \
*(unsigned int*) __tramp[8] = 0xe59ff000; /* ldr pc, [pc
On 07/25/2011 10:33 AM, Andrew Haley wrote:
On 21/07/11 16:33, Joseph S. Myers wrote:
My suggestion would be putting the instruction sequence in a .s file,
rather than hardcoding the instruction encodings here, and writing the
code to read from the sequence as assembled by the assembler
On 07/11/2012 10:44 AM, Steven Bosscher wrote:
Remove force_evaluation_order because the only caller is
force_evaluation_order itself.
Will commit after a few days, if no-one objects.
No problem. I presume that its caller was removed because it wasn't
needed, but I don't quite know why it
On 07/18/2012 05:30 PM, H.J. Lu wrote:
2012-07-16 H.J. Lu hongjiu...@intel.com
PR libjava/53973
* include/x86_64-signal.h (CHECK_67H_PREFIX): New.
(HANDLE_DIVIDE_OVERFLOW): Check and and skip 67h address size
prefix if CHECK_67H_PREFIX is 1. Use ULL suffix for
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
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
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
On 11/22/2011 08:53 PM, Jeff Law wrote:
* lang.c (java_init_options_struct): Disable optimizations
which assume a NULL pointer dereference will cause a fault.
This is OK.
Thanks,
Andrew.
On 16/05/11 10:45, Richard Guenther wrote:
On Fri, May 13, 2011 at 7:14 PM, Ian Lance Taylor i...@google.com wrote:
I noticed that buglist.cgi was taking quite a bit of CPU time. I looked
at some of the long running instances, and they were coming from
searchbots. I can't think of a good
On 05/16/2011 02:10 PM, Richard Guenther wrote:
On Mon, May 16, 2011 at 3:04 PM, Andrew Haley a...@redhat.com wrote:
On 05/16/2011 01:09 PM, Michael Matz wrote:
Hi,
On Mon, 16 May 2011, Andrew Haley wrote:
On 16/05/11 10:45, Richard Guenther wrote:
On Fri, May 13, 2011 at 7:14 PM, Ian
On 05/16/2011 02:22 PM, Michael Matz wrote:
Hi,
On Mon, 16 May 2011, Andrew Haley wrote:
It's not quite the same information, surely. Wouldn't searchers be
directed to an email rather than the bug itself?
Yes, though there is a link in all mails.
Right, so we are contemplating
On 05/16/2011 02:32 PM, Michael Matz wrote:
On Mon, 16 May 2011, Andrew Haley wrote:
It routinely is. bugzilla performance is terrible most of the time
for me (up to the point of five timeouts in sequence), svn speed is
mediocre at best, and people with access to gcc.gnu.org often
On 05/16/2011 02:42 PM, Richard Guenther wrote:
On Mon, May 16, 2011 at 3:34 PM, Andrew Haley a...@redhat.com wrote:
On 05/16/2011 02:32 PM, Michael Matz wrote:
On Mon, 16 May 2011, Andrew Haley wrote:
It routinely is. bugzilla performance is terrible most of the time
for me (up
On 05/23/2011 04:52 PM, Nathan Sidwell wrote:
This patch fixes an interoperability issue with code generated by ARM's EABI
compiler.
This patch results has been tested for arm-linux, and independently tested by
ARM with mixed RVCT-generated code confirming the defect has been fixed.
ok?
On 05/24/2011 07:28 PM, H.J. Lu wrote:
This patch implements pause intrinsic suggested by Andi. OK
for trunk?
What does full memory barrier here mean?
+@table @code
+@item void __builtin_ia32_pause (void)
+Generates the @code{pause} machine instruction with full memory barrier.
+@end table
On 05/25/2011 03:47 PM, H.J. Lu wrote:
On Wed, May 25, 2011 at 7:36 AM, Andrew Haley a...@redhat.com wrote:
On 05/25/2011 01:34 PM, H.J. Lu wrote:
On Wed, May 25, 2011 at 3:26 AM, Andrew Haley a...@redhat.com wrote:
On 05/24/2011 07:28 PM, H.J. Lu wrote:
This patch implements pause intrinsic
On 05/25/2011 03:57 PM, Richard Guenther wrote:
asm volatile ( : : : memory) in fact will work as a full memory barrier
How? You surely need MFENCE or somesuch, unless all you
care about is a compiler barrier. That's what I think needs
to be clarified.
Andrew.
On 05/25/2011 06:26 PM, Andrew Pinski wrote:
On Wed, May 25, 2011 at 10:19 AM, H.J. Lu hjl.to...@gmail.com wrote:
--
H.J.
---
Index: doc/extend.texi
===
--- doc/extend.texi (revision 174216)
+++ doc/extend.texi
On 08/10/2011 06:00 PM, Jie Liu wrote:
For the previous analysis libjava patches for RTEMS[1], there are 6
cases need to pay more attention. PR18699, TLtest, Thread_Interrupt,
Thread_Sleep_2, Throw_2 and bclink.
After add patch to bdwgc for RTEMS pthread support[2]:
PR18699
On 08/15/2011 03:07 PM, Jie Liu wrote:
Looks OK, but there is no ChangeLog. Do you have copyright
assignment?
Have added ChangeLog to the patch, please see the attachment. And I
think I have copyright assignment, because I have Free Software
Foundation paperwork, as ASSIGNMENT - GNU GCC
On 03/05/2012 05:01 PM, Rainer Orth wrote:
* In libjava, there were several workarounds for OSF bugs/quirks. I've
ripped them out as explained above.
There's one particular issue: the change to java/io/File.java required
my to regenerate the .class file in classpath. I've used Sun
On 04/02/2012 10:06 PM, dann frazier wrote:
On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
On 29/03/12 20:34, dann frazier wrote:
This is an updated version of a patch Debian and Ubuntu are using to
use an alternate linker path for hardfloat binaries. The difference
with
On 04/03/2012 05:09 PM, Richard Earnshaw wrote:
On 03/04/12 12:01, Jakub Jelinek wrote:
On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
If, so then there's only one way to sort out this mess.
/lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader
On 12/10/2011 12:05 PM, Kai Tietz wrote:
2011-12-10 Kai Tietz kti...@redhat.com
PR libgcj/50053
* java/lang/natClass.cc (java::lang::Class::newInstance): Special case
member-call for 32-bit IA native Window target.
OK, thanks.
Andrew.
On 12/13/2011 05:51 PM, Rainer Orth wrote:
2011-12-13 Rainer Orth r...@cebitec.uni-bielefeld.de
* configure.ac (i?86-*-linux*): Set SIGNAL_HANDLER_AUX.
* configure: Regenerate.
* include/i386-signal.h: Wrap in __i386__, include
java-signal-aux.h otherwise.
OK,
On 01/09/2012 04:09 PM, Rainer Orth wrote:
In the absence of a listed libffi maintainer (Anthony Green used to be
listed in MAINTAINERS, but isn't anymore despite still taking care of
upstream libffi), it probably needs a global reviewer.
Sorry, I usually do it but missed this one. It's fine.
On 01/29/2012 02:15 PM, Kai Tietz wrote:
2012-01-29 Kai Tietz kti...@redhat.com
PR target/51500
* interpret.cc (_Jv_init_cif): Handle thiscall
convention for 32-bit Windows.
* java/lang/reflect/natMethod.cc (_Jv_CallAnyMethodA):
Likewise.
*
On 02/01/2012 09:47 AM, Kai Tietz wrote:
I sent update-patch to ML for libffi to support closure-code for
thiscall. So the hunk in patch for java/lang/reflect/natVMProxy.cc
(ncode): Force SYSV closure for 32-bit Windows. Isn't necessary, if
the fix in libffi gets applied.
Ok to commit
On 02/02/2012 06:47 PM, Kai Tietz wrote:
2012-02-02 Kai Tietz kti...@redhat.com
PR libjava/48512
* configure.ac (THREADSTARTFILESPEC): Don't add crtmet.o file for
w64 windows targets.
* configure: Regenerated.
Tested for i686-w64-mingw32, and
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.
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
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
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 25/05/11 20:17, Basile Starynkevitch wrote:
On Wed, 25 May 2011 11:26:51 +0100
Andrew Haley a...@redhat.com wrote:
On 05/24/2011 07:28 PM, H.J. Lu wrote:
This patch implements pause intrinsic suggested by Andi. OK
for trunk?
What does full memory barrier here mean?
+@table @code
On 05/26/2011 10:34 AM, Richard Guenther wrote:
Index: doc/extend.texi
===
--- doc/extend.texi (revision 174216)
+++ doc/extend.texi (working copy)
@@ -8699,7 +8699,8 @@ The following built-in function is alway
@table
On 05/26/2011 02:51 PM, Richard Guenther wrote:
On Thu, May 26, 2011 at 3:30 PM, Andrew Haley a...@redhat.com wrote:
On 05/26/2011 10:34 AM, Richard Guenther wrote:
Index: doc/extend.texi
===
--- doc/extend.texi (revision
On 30/05/11 04:26, Joern Rennecke wrote:
Except or the fortran bits (committed), this patch hasn't been reviewed for
three weeks:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00582.html
This is OK. I said so already.
Andrew.
On 05/26/2011 08:37 PM, Basile Starynkevitch wrote:
On Thu, 26 May 2011 13:48:13 -0400
Paul Koning paul_kon...@dell.com wrote:
Relax? Weird. Pause is just as weird. It might be an ia32 instruction,
so as an ia32 builtin it is a reasonable name But if you want a generic
builtin, you
On 06/01/2011 05:45 PM, Bryce McKinlay wrote:
Can I suggest that you cc such approvals to gcc-patches. Richard (and
others) may not be subscribed to the j...@gcc.gnu.org list.
Sorry, I meant to do so. This idiot mailer has its reply list button
replying to just the one list, not all the
On 06/01/2011 12:34 PM, Richard Guenther wrote:
java/
* decl.c (java_init_decl_processing): Properly initialize
size_type_node.
Index: gcc/java/decl.c
===
--- gcc/java/decl.c (revision 174520)
+++
On 05/29/2011 02:07 AM, Gerald Pfeifer wrote:
The vast majority of users does not need the former and the latter is
on the verge of becoming practically irrelevant. As one datapoint, the
entire FreeBSD Ports Collection has a single(!) port relying on GCJ.
It's not quite as irrelevant as you
On 12/06/11 16:45, Jie Liu wrote:
Hi,
Java HelloWorld compiled by cross gcj for RTEMS can run without
problem now, I think it's time for get the boehm-gc patch reviewed and
merged. :) Here is the patch:
Index: mach_dep.c
On 06/21/2011 02:55 PM, Rainer Orth wrote:
As described in the PR, unless the UTF-8 encoding of \ufeff is padded
with a NUL byte, the iconv_init test fails for the native Tru64 UNIX
libiconv, iconv_byte_swap isn't set correctly and later iconv calls
fail. This patch fixes this, allowing the
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
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
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 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
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,
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 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
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
On 08/08/2012 11:08 PM, Dodji Seketeli wrote:
OK to commit?
Looks good, but what sets LIBXML2_NEW_BUFFER ?
Andrew.
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
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
1 - 100 of 156 matches
Mail list logo
