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

[Andrew Haley via Gcc-patches]

On 5/1/20 11:48 AM, JiangNing OS via Gcc-patches wrote:
> In reality, a lot of users are still using old gcc versions running on new 
> hardware. OpenJDK is a typical example, I think.

We can change the OpenJDK build scripts to use -moutline-atomics if
it's available. I agree with Richard 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

[PATCH] Loop splitting breaks with loops of pointer type

[Andrew Haley]

Loop splitting is fine when the control variable is of integer type,
but when it is a pointer type the upper bound of the new loop is
calculated incorrectly.
The calculation should be guard_init + (end-beg), but instead we do
guard_init - (end-beg).

Fixed thusly.  Bootstrapped, regtested.

OK?

Andrew.


2017-03-08  Andrew Haley  <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-split.c
===
--- gcc/tree-ssa-loop-split.c   (revision 245948)
+++ gcc/tree-ssa-loop-split.c   (working copy)
@@ -436,7 +436,6 @@
   if (POINTER_TYPE_P (TREE_TYPE (guard_init)))
 {
   enddiff = gimple_convert (stmts, sizetype, enddiff);
-  enddiff = gimple_build (stmts, NEGATE_EXPR, sizetype, enddiff);
   newbound = gimple_build (stmts, POINTER_PLUS_EXPR,
   TREE_TYPE (guard_init),
   guard_init, enddiff);


2017-03-08  Andrew Haley  <a...@redhat.com>

PR tree-optimization/79894
* gcc.dg/tree-ssa/pr79943.c: New test.

Index: gcc/testsuite/gcc.dg/tree-ssa/pr79943.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr79943.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr79943.c (revision 0)
@@ -0,0 +1,40 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fsplit-loops -fdump-tree-lsplit-details" } */
+/* { dg-require-effective-target int32plus } */
+
+#ifdef __cplusplus
+extern "C" void abort (void);
+#else
+extern void abort (void);
+#endif
+
+typedef struct {
+  int n;
+} region_t;
+
+void set (region_t *region) __attribute__((noinline));
+void doit (region_t *beg, region_t *end, region_t *limit)
+  __attribute__((noinline));
+
+region_t regions[10];
+
+void
+set (region_t *region) {
+  region->n = 1;
+}
+
+void
+doit (region_t *beg, region_t *end, region_t *limit) {
+  for (region_t *cur = beg; cur < end; cur++) {
+if (cur < limit) {
+  set(cur);
+}
+  }
+}
+
+int
+main (void) {
+  doit([0], [2], [10]);
+  if (regions[1].n != 1)
+abort();
+}

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 23/01/17 13:41, Jakub Jelinek wrote:
> On Mon, Jan 23, 2017 at 04:51:44AM -0800, Per Bothner wrote:

>> The last part is moot, as we should strive to not move pages and thus break 
>> links.
> 
> I meant updating URLs in the pages when they refer to external web pages
> which move over time (or switch from http to https, or disappear, etc.).  
> Gerald
> does a great job handling that, but if there are too many pages for
> historical purpose only, it will make his work harder.

We can redirect to somewhere else.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

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

[Andrew Haley]

On 04/10/16 09:39, Rainer Orth wrote:
> Hi Matthias,
> 
>> On 05.09.2016 17:13, Andrew Haley wrote:
>>> As discussed.  I think I should ask a Global reviewer to approve this
>>> one.  For obvious reasons I haven't included the diffs to the deleted
>>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>>> if anyone would like to try it.
>>
>> still breaks bootstraps when configured with --enable-objc-gc.
>>
>> the immediate step should be to fix the bootstrap failure, as an additional 
>> step
>> to remove boehm-gc from the gcc sources and be able to use an external 
>> boehm-gc.
> 
> the first part is handled by my unreviewed patch
> 
>   https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html

Looks obvious to me, fixes bootstrap.  I think no-one will complain
if you check it in.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 02/10/16 14:27, Andreas Schwab wrote:
> Things we may want to remove:
> 
> - references to java in contrib (download_ecj, gcc_update,
>   patch_tester.sh, update-copyright.py)
> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> - references to java in install.texi

Yes, that's true.  Thanks for doing the search.

Andrew.

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Andrew Haley]

On 30/09/16 23:16, Rainer Orth wrote:
> me too, though mostly to have maximum test coverage (primarily on
> Solaris).  As expected, a x86_64-apple-darwin16 bootstrap with
> --enable-objc-gc just failed for me.  I'm testing the following patch
> (on top of Jakub's).
> 
>   Rainer
> 
> 
> 2016-10-01  Rainer Orth  
> 
>   * configure.ac (target_libraries): Readd target-boehm-gc.
>   Restore --enable-objc-gc handling.
>   * configure: Regenerate.

Thanks everybody.  My apologies.

Andrew.

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

[Andrew Haley]

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

[Andrew Haley]

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 240658)
+++ MAINTAINERS (working copy)
@@ -155,9 +155,6 @@
 c++Jason Merrill   <ja...@redhat.com>
 c++Nathan Sidwell  <nat...@codesourcery.com>
 go Ian Lance Taylor<i...@airs.com>
-java   Per Bothner <p...@bothner.com>
-java   Andrew Haley<a...@redhat.com>
-java   Tom Tromey  <tro...@redhat.com>
 objective-c/c++Mike Stump  <mikest...@comcast.net>
 objective-c/c++Iain Sandoe <i...@codesourcery.com>

@@ -352,6 +349,7 @@
 Andrea Bona<andrea.b...@st.com>
 Paolo Bonzini  <bonz...@gnu.org>
 Neil Booth <n...@daikokuya.co.uk>
+Per Bothner <p...@bothner.com>
 Robert Bowdidge<bowdi...@apple.com>
 Joel Brobecker <brobec...@gnat.com>
 Dave Brolley   <brol...@redhat.com>
@@ -425,6 +423,7 @@
 Wei Guozhi <car...@google.com>
 Mostafa Hagog      <ha...@gcc.gnu.org>
 Olivier Hainque<hain...@adacore.com>
+Andrew Haley   <a...@redhat.com>
 Stuart Hastings<stu...@apple.com>
 Michael Haubenwallner  
<michael.haubenwall...@ssi-schaefer.com>
 Pat Haugen <pthau...@us.ibm.com>
@@ -608,6 +607,7 @@
 Philipp Tomsich
<philipp.toms...@theobroma-systems.com>
 Konrad Trifunovic  <konrad.trifuno...@inria.fr>
 Markus Trippelsdorf<mar...@trippelsdorf.de>
+Tom Tromey  <tro...@redhat.com>
 Martin Uecker  <uec...@eecs.berkeley.edu>
 David Ung  <dav...@mips.com>
 Neil Vachharajani  <nvach...@gmail.com>

Re: [PATCH] Delete GCJ

[Andrew Haley]

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

[Andrew Haley]

On 30/09/16 11:27, Marek Polacek wrote:
> Can we move forward with this patch, then?

I've been travelling for several weeks.  However, I'm back at my desk
now, so I can move this forward.  I have all the approvals and
everybody has had time to respond.  However, I'll need to pull some
more recent changes into my tree and merge again.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 10/09/16 12:59, NightStrike wrote:
> Could we at least reach out and see if there's someone else who could
> be the maintainer?  I noticed gcj patches recently, so there's still
> interest.

1.  It's too late.  We have been discussing this for a long time, and
we're now doing what we decided.

2.  Maintaining GCJ requires a lot of knowledge of both Java and GCC
internals.  There are very few people in the world with that
knowledge, and I'm fairly sure I know them by name.

3.  The Classpath library is very old and is unmaintained.  The only
practical way to update GCJ would be to use the OpenJDK class
libraries instead, but updating GCJ to use those class libraries is a
very substantial job.

So, I cannot prevent anyone from coming along to maintain GCJ, and
neither would I want to.  However, such a proposal would have to be
credible.  It is a multi-engineer-year commitment, and not just any
ordinary engineers.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

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
>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>> if anyone would like to try it.
> 
> Isn't there also java specific C++ frontend parts?

There certainly are, but deleting them without breaking anything else
is going to be rather delicate.  I'm trying to do this one step at a
time, rather cautiously.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

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

[Andrew Haley]

As discussed.  I think I should ask a Global reviewer to approve this
one.  For obvious reasons I haven't included the diffs to the deleted
gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
if anyone would like to try it.

Andrew.


2016-09-05  Andrew Haley  <a...@redhat.com>

* Makefile.def: Remove libjava.
* Makefile.tpl: Likewise.
* Makefile.in: Regenerate.
* configure.ac: Likewise.
* configure: Likewise.
* gcc/java: Remove.
* libjava: Likewise.

Index: Makefile.in
===
--- Makefile.in (revision 239988)
+++ Makefile.in (working copy)
@@ -322,8 +322,6 @@
 HOST_LIBELFLIBS = @libelflibs@
 HOST_LIBELFINC = @libelfinc@

-EXTRA_CONFIGARGS_LIBJAVA = @EXTRA_CONFIGARGS_LIBJAVA@
-
 # --
 # Programs producing files for the BUILD machine
 # --
@@ -1007,7 +1005,6 @@
 maybe-configure-target-winsup \
 maybe-configure-target-libgloss \
 maybe-configure-target-libffi \
-maybe-configure-target-libjava \
 maybe-configure-target-zlib \
 maybe-configure-target-boehm-gc \
 maybe-configure-target-rda \
@@ -1174,7 +1171,6 @@
 all-target: maybe-all-target-winsup
 all-target: maybe-all-target-libgloss
 all-target: maybe-all-target-libffi
-all-target: maybe-all-target-libjava
 all-target: maybe-all-target-zlib
 all-target: maybe-all-target-boehm-gc
 all-target: maybe-all-target-rda
@@ -1268,7 +1264,6 @@
 info-target: maybe-info-target-winsup
 info-target: maybe-info-target-libgloss
 info-target: maybe-info-target-libffi
-info-target: maybe-info-target-libjava
 info-target: maybe-info-target-zlib
 info-target: maybe-info-target-boehm-gc
 info-target: maybe-info-target-rda
@@ -1355,7 +1350,6 @@
 dvi-target: maybe-dvi-target-winsup
 dvi-target: maybe-dvi-target-libgloss
 dvi-target: maybe-dvi-target-libffi
-dvi-target: maybe-dvi-target-libjava
 dvi-target: maybe-dvi-target-zlib
 dvi-target: maybe-dvi-target-boehm-gc
 dvi-target: maybe-dvi-target-rda
@@ -1442,7 +1436,6 @@
 pdf-target: maybe-pdf-target-winsup
 pdf-target: maybe-pdf-target-libgloss
 pdf-target: maybe-pdf-target-libffi
-pdf-target: maybe-pdf-target-libjava
 pdf-target: maybe-pdf-target-zlib
 pdf-target: maybe-pdf-target-boehm-gc
 pdf-target: maybe-pdf-target-rda
@@ -1529,7 +1522,6 @@
 html-target: maybe-html-target-winsup
 html-target: maybe-html-target-libgloss
 html-target: maybe-html-target-libffi
-html-target: maybe-html-target-libjava
 html-target: maybe-html-target-zlib
 html-target: maybe-html-target-boehm-gc
 html-target: maybe-html-target-rda
@@ -1616,7 +1608,6 @@
 TAGS-target: maybe-TAGS-target-winsup
 TAGS-target: maybe-TAGS-target-libgloss
 TAGS-target: maybe-TAGS-target-libffi
-TAGS-target: maybe-TAGS-target-libjava
 TAGS-target: maybe-TAGS-target-zlib
 TAGS-target: maybe-TAGS-target-boehm-gc
 TAGS-target: maybe-TAGS-target-rda
@@ -1703,7 +1694,6 @@
 install-info-target: maybe-install-info-target-winsup
 install-info-target: maybe-install-info-target-libgloss
 install-info-target: maybe-install-info-target-libffi
-install-info-target: maybe-install-info-target-libjava
 install-info-target: maybe-install-info-target-zlib
 install-info-target: maybe-install-info-target-boehm-gc
 install-info-target: maybe-install-info-target-rda
@@ -1790,7 +1780,6 @@
 install-pdf-target: maybe-install-pdf-target-winsup
 install-pdf-target: maybe-install-pdf-target-libgloss
 install-pdf-target: maybe-install-pdf-target-libffi
-install-pdf-target: maybe-install-pdf-target-libjava
 install-pdf-target: maybe-install-pdf-target-zlib
 install-pdf-target: maybe-install-pdf-target-boehm-gc
 install-pdf-target: maybe-install-pdf-target-rda
@@ -1877,7 +1866,6 @@
 install-html-target: maybe-install-html-target-winsup
 install-html-target: maybe-install-html-target-libgloss
 install-html-target: maybe-install-html-target-libffi
-install-html-target: maybe-install-html-target-libjava
 install-html-target: maybe-install-html-target-zlib
 install-html-target: maybe-install-html-target-boehm-gc
 install-html-target: maybe-install-html-target-rda
@@ -1964,7 +1952,6 @@
 installcheck-target: maybe-installcheck-target-winsup
 installcheck-target: maybe-installcheck-target-libgloss
 installcheck-target: maybe-installcheck-target-libffi
-installcheck-target: maybe-installcheck-target-libjava
 installcheck-target: maybe-installcheck-target-zlib
 installcheck-target: maybe-installcheck-target-boehm-gc
 installcheck-target: maybe-installcheck-target-rda
@@ -2051,7 +2038,6 @@
 mostlyclean-target: maybe-mostlyclean-target-winsup
 mostlyclean-target: maybe-mostlyclean-target-libgloss
 mostlyclean-target: maybe-mostlyclean-target-libffi
-mostlyclean-target: maybe-mostlyclean-target-libjava
 mostlyclean-target: maybe-mostlyclean-target-zlib
 mostlyclean-target: maybe-mostlyclean-

Re: [DOC PATCH] Rewrite docs for inline asm

[Andrew Haley]

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

[Andrew Haley]

On 05/20/2016 07:50 AM, David Wohlferd wrote:

> At a minimum, suddenly forcing an unexpected/unneeded memory clobber
> can adversely impact the optimization of surrounding code.  This can
> be particularly annoying if the reason for the asm was to improve
> performance.  And adding a memory clobber does add a dependency of
> sorts, which might cause the location of the asm to shift in an
> unfortunate way.  And there's always the long-shot possibility that
> some weird quirk or (very) badly-written code will cause the asm to
> flat out fail when used with a memory clobber.  And if this change
> does produce any of these problems, I feel pity for whoever has to
> track it down.

OTOH, if a memory clobber does change code gen it probably changes it
in a way which better fits user expectations, and perhaps it fixes a
bug.  That's a win, and it is far, far more important than any other
consideration.

Given that a basic asm statements has neither inputs nor outputs, it
must have side effects to be useful.  All this patch does is recognize
that fact.  I'm not saying your scenario won't occur, but it won't in
the majority of cases.

> I realize deprecation/removal is drastic.  Especially since basic
> asm (mostly) works as is.  But fixing memory clobbers while leaving
> the rest broken feels like half a solution, meaning that some day
> we're going to have to fiddle with this again.

Yes, we will undoubtedly have to fiddle with basic asm again.  We
should plan for deprecation.

But I think you're close to the all-or-nothing fallacy: that because
this patch doesn't solve all the problems with basic asm, it isn't
worth having.

Andrew.

Re: [PATCH] Make basic asm implicitly clobber memory

[Andrew Haley]

On 06/05/16 07:35, David Wohlferd wrote:

> 1) I'm not clear precisely what problem this patch fixes.  It's true
> that some people have incorrectly assumed that basic asm clobbers
> memory and this change would fix their code.  But some people also
> incorrectly assume it clobbers registers.  I assume that's why Jeff
> Law proposed making basic asm "an opaque blob that
> read/write/clobber any register or memory location."

A few more things:

Jeff Law did propose this, but it's impossible to do because it
inevitably causes reload failures.

My argument in support of Bernd's proposal is that it makes sense from
a *practical* software reliability point of view.  It wouldn't hurt,
and might fix some significant bugs.  It's similar to the targets
which always implicitly clobber "cc".  It corresponds to what I always
assumed basic asm did, and I'm sure that I'm not alone.  This change
might fix some real bugs and it is extremely unlikely to break
anything.

Andrew.

Re: [patch] Don't encode the minor version in the gcj abi version

[Andrew Haley]

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

[Andrew Haley]

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

[Andrew Haley]

On 04/19/2016 03:37 PM, Pedro Alves wrote:
> On 04/19/2016 02:25 PM, Andrew Haley wrote:
>> On 04/19/2016 02:19 PM, Michael Matz wrote:
>>
>>> Well, yeah, that's traditional insn caches on multiple cores.  From
>>> user space you need kernel help for this, doing interprocess
>>> interrupts to flush all such buffers on all cores (or at least those
>>> potentially fetching stuff in the patched region, if such
>>> granularity is possible).  An implementation providing such is
>>> non-broken :)
>>
>> Sure.  If you know of any such facility in Linux userspace, please let
>> me know.  :-)
> 
> Sounds like a job for the sys_membarrier system call:
> 
>  https://lkml.org/lkml/2015/3/18/531
>  https://lwn.net/Articles/369567/
> 
> I think it's available in Linux 4.3+.

So it is, thanks.  I'm guessing that might be good enough for full
instruction synchronization barriers, but from looking at the kernel
source I can't really tell.

Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Andrew Haley]

On 04/19/2016 02:19 PM, Michael Matz wrote:

> Well, yeah, that's traditional insn caches on multiple cores.  From
> user space you need kernel help for this, doing interprocess
> interrupts to flush all such buffers on all cores (or at least those
> potentially fetching stuff in the patched region, if such
> granularity is possible).  An implementation providing such is
> non-broken :)

Sure.  If you know of any such facility in Linux userspace, please let
me know.  :-)

But there are ways of doing patching sequences which don't require
IPIs across all the cores; which was my point.

> Alternatively the various invalidate cache instructions need to have
> a form that invalidates the i$ on all cores.

I'm fairly sure we haven't got that in the AArch64 architecture.

Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Andrew Haley]

On 18/04/16 18:34, Michael Matz wrote:
> Hi,
> 
> On Mon, 18 Apr 2016, Andrew Haley wrote:
> 
>>>> That may not be safe.  Consider an implementation which looks
>>>> ahead in the instruction stream and decodes the instructions
>>>> speculatively.
>>>
>>> It should go without saying that patching instructions is followed
>>> by whatever means necessary to flush any such caches on a
>>> particular implementation (here after patching the jump, after
>>> patching the rest, and after patching the first insn again,
>>> i.e. three times).
>>
>> That doesn't necessarily help you, though, without an ISB in the reading 
>> thread.
> 
> I don't understand, which reading thread?  We're writing, not reading 
> instructions.  You mean other executing threads? 

Yes.

> I will happily declare any implementation where it's impossible to
> safely patch the instruction stream by flushing the respective
> buffers or other means completely under control of the patching
> machinery, to be broken by design. 

You can declare anything you want, but we have to program for the
architectural specification.

> What failure mode do you envision, exactly?

It's easiest just to quote from the spec:

How far ahead of the current point of execution instructions are
fetched from is IMPLEMENTATION DEFINED. Such prefetching can be
either a fixed or a dynamically varying number of instructions,
and can follow any or all possible future execution paths. For all
types of memory:

   The PE might have fetched the instructions from memory at any
   time since the last Context synchronization operation on that
   PE.

   Any instructions fetched in this way might be executed multiple
   times, if this is required by the execution of the program,
   without being re-fetched from memory. In the absence of an ISB,
   there is no limit on the number of times such an instruction
   might be executed without being re-fetched from memory.

The ARM architecture does not require the hardware to ensure
coherency between instruction caches and memory, even for
locations of shared memory.

So, if you write a bunch of instructions (which might have been
pre-fetched) and then rewrite a NOP to jump to those instructions you
need to make sure that the thread which might be running concurrently
does an ISB.

Note also:

Memory accesses caused by instruction fetches are not required to
be observed in program order, unless they are separated by an ISB
or other context synchronization event.

So, if you modify instruction memory in one thread, other threads may
see those changes in a different order from the writing thread.  Sure,
the writing thread executes the cache maintenance instructions on its
side, but you also need to do something on the side which is executing
the instructions.

I have wondered if it might be a good idea to use an inter-processor
interrupt to force a context synchronization event across all PEs.

Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Andrew Haley]

On 04/18/2016 06:13 PM, Michael Matz wrote:

> On Mon, 18 Apr 2016, Andrew Haley wrote:
> 
>> On 04/15/2016 06:29 PM, Alexander Monakov wrote:
>>
>>> Alternatively: replace first nop with a short forward branch that
>>> jumps over the rest of the pad, patch rest of the pad, patch the
>>> initial forward branch.
>>
>> That may not be safe.  Consider an implementation which looks ahead in
>> the instruction stream and decodes the instructions speculatively.
> 
> It should go without saying that patching instructions is followed by 
> whatever means necessary to flush any such caches on a particular 
> implementation (here after patching the jump, after patching the rest, and 
> after patching the first insn again, i.e. three times).

That doesn't necessarily help you, though, without an ISB in the reading
thread.

Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Andrew Haley]

On 04/15/2016 06:29 PM, Alexander Monakov wrote:

> Alternatively: replace first nop with a short forward branch that
> jumps over the rest of the pad, patch rest of the pad, patch the
> initial forward branch.

That may not be safe.  Consider an implementation which looks ahead in
the instruction stream and decodes the instructions speculatively.  I
suppse you could begin the block of instructions after the branch with
an ISB.  On balance, the trap sounds like the best plan.  We do this
in Java all the time: every method begins with a NOP, and we patch it
either to a trap or to a call to the replacement code.

Andrew.

Re: [wwwdocs,Java] Remove java/status.html

[Andrew Haley]

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

[Andrew Haley]

On 16/04/16 21:31, Gerald Pfeifer wrote:
> On Sun, 10 Apr 2016, Andrew Hughes wrote:
>>> That said, looking at the page, and how since 2005 nearly all changes
>>> have been maintainance ones from me, is it really worthwhile keeping
>>> this (short of historic reasons)?
>> I guess the next news will be the removal of GCJ during the
>> GCC 7 development period, so its remaining shelf life should
>> be limited anyway.
> 
> Soo, GCC 6 has branched -- would it make sense for you guys to
> start this removal?

Sounds good.  OTOH, I don't think there's any great hurry.

> Somewhat related, any concerns if I were to remove
> https://gcc.gnu.org/java/status.html now?
> 
> ("Status of GCJ as of GCC 3.2" _really_ is rather old.)

It's so old that I don't think it's of any use.  However, I wonder if
it might make more sense to at least have a page saying that GCJ is
gone.

Andrew.

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 03/01/16 15:52, Matthias Klose wrote:
> No, libgcj versions up to 4.9.3 didn't change the value for releases taken 
> from 
> the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same 
> GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* 
> GCJ_CXX_ABI_VERSIONs.
> 
>> > Why change this rule now, at this stage of GCJ's life?
> This was changed by the change of the version schema, an unintential change 
> for 
> GCJ_CXX_ABI_VERSION.  I want to keep it that way, not change it with every 
> release from the gcc-5 branch.

Because effectively we've done an arithmetic shift left on the GCC version
numbering, I guess?  So where we would have had 5.1.1, 5.1.2, 5.1.3, we now
have 5.1, 5.2, 5.3?

If that's the idea, your patch is OK.

Thanks,

Andrew.

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 03/01/16 11:38, Matthias Klose wrote:
> On 02.01.2016 17:11, Andrew Haley wrote:
>> On 02/01/16 15:53, Matthias Klose wrote:
>>>>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include 
>>>>> __GNUC_MINOR__
>>>>>>> anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so 
>>>>>>> that it
>>>>>>> won't change anymore with future releases from the gcc-5 branch?
>>>>>
>>>>> That's safe only if Classpath and libgcj are not changed at all.
>>> why?
>>
>> Because of the way that gcj's linkage works.  If you change any of the
>> vtable/itable indexes your program will crash.
> 
> Right, but this no change compared to the 4.x.y releases.
> 
> This is what I committed to the trunk.
> 
> So what to do with the gcc-5 branch? Apply the same patch to jvm.h, or fix 
> the 
> minor version to 3? The latter would be compatible at least with the 5.3 
> release.

Neither.  If you link a program with libgcj then you need to recompile
it when a new version of libgcj comes along.  It has always been this
way.  Why change this rule now, at this stage of GCJ's life?

Andrew.

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 02/01/16 14:40, Matthias Klose wrote:
> 
> preparing for a test rebuild of the archive, and trying to run gcj-dbtool 
> (from 
> GCC 5) with libgcj16 (from GCC 6):
> 
> $ gcj-dbtool -n /tmp/foo.db
> libgcj failure: gcj linkage error.
> Incorrect library ABI version detected.  Aborting.
> 
> Aborted (core dumped)
> 
> natClassLoader.cc:_Jv_CheckABIVersion checks the ABI version, which is 
> defined as
> 
> libjava/include/jvm.h:#define GCJ_CXX_ABI_VERSION (__GNUC__ * 10 + 
> __GNUC_MINOR__ * 1000)
> 
> so this will be seen with everything directly linked to libgcj with a 
> libgcj16 
> upgraded to GCC 6. So what to do? Bump the soname, or discard this check?

I'd bump the soname.

> In any case, GCJ_CXX_ABI_VERSION should be changed to not include 
> __GNUC_MINOR__ 
> anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so that it 
> won't change anymore with future releases from the gcc-5 branch?

That's safe only if Classpath and libgcj are not changed at all.  I guess
we can guarantee that on the gcc-5 branch?

Andrew.

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 02/01/16 15:53, Matthias Klose wrote:
>>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include 
>>> __GNUC_MINOR__
>>> >> anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so 
>>> >> that it
>>> >> won't change anymore with future releases from the gcc-5 branch?
>> >
>> > That's safe only if Classpath and libgcj are not changed at all.
> why?

Because of the way that gcj's linkage works.  If you change any of the
vtable/itable indexes your program will crash.

Andrew.

Re: update zlib to 1.2.8

[Andrew Haley]

On 23/11/15 04:37, Matthias Klose wrote:
> In GCC zlib is only used for libjava; for binutils and gdb it is used when 
> building without --with-system-zlib.  This just updates zlib from 1.2.7 to 
> 1.2.8 
> (released in 2013).  Applies cleanly, libjava still builds and doesn't show 
> any 
> regressions in the testsuite.  Ok to apply (even if we already are in stage3)?

Fine by me; GDB assent is more important.

Andrew.

Re: [PATCH] libjava: fix locale handling when sorting JNI methods

[Andrew Haley]

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

[Andrew Haley]

On 09/29/2015 04:21 PM, Sandra Loosemore wrote:
> What is "weak compare_exchange", and what is "the strong variation", and 
> how do they differ in terms of behavior?

It's in C++11 29.6.5:

Remark: The weak compare-and-exchange operations may fail spuriously,
that is, return false while leaving the contents of memory pointed to
by expected before the operation is the same that same as that of the
object and the same as that of expected after the operation. [ Note:
This spurious failure enables implementation of compare-and-exchange
on a broader class of machines, e.g., load- locked store-conditional
machines. A consequence of spurious failure is that nearly all uses of
weak compare-and-exchange will be in a loop.  When a
compare-and-exchange is in a loop, the weak version will yield better
performance on some platforms. When a weak compare-and-exchange would
require a loop and a strong one would not, the strong one is
preferable. — end note ]

The classic use of this is for shared counters: you don't care if you
miss an occasional count but you don't want the counter to go
backwards.

Whether we should replicate all of the C++11 language is perhaps
something we should discuss.

Andrew.

Re: [PATCH] Clarify __atomic_compare_exchange_n docs

[Andrew Haley]

On 10/01/2015 06:32 PM, Jonathan Wakely wrote:
> I would suggest we don't try to reproduce the standard definition, but
> just say the weak version can fail spuriously and the strong can't.
> IMHO this isn't the place to educate people in the fine points of
> low-level atomics. As it says, "when in doubt use the strong
> variation".
> 
> i.e. apply this in addition to my earlier suggestion.

"If you don't already know what a weak CAS is you probably should
not even think of using it."  :)

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 20/08/15 09:24, Matthias Klose wrote:
 On 08/20/2015 06:36 AM, Tom Tromey wrote:
 Andrew No, it isn't. It's still a necessity for initial bootstrapping of
 Andrew OpenJDK/IcedTea.

 Andrew Haley said the opposite here:

 https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
 
 if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
 available for the target platform is required. Starting with OpenJDK
 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
 available on the cross platform.  It might be possible to cross
 build older OpenJDK versions, but this usually is painful.

Sure, but we don't need GCJ going forward.  I don't think that there
are any new platforms to which OpenJDK has not been ported which will
require GCJ to bootstrap.  And even if there are, anybody who needs to
do that can (and, indeed, should) use an earlier version of GCJ.  It's
not going to go away; it will always be in the GCC repos.  And because
newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 08/20/2015 03:57 PM, Andrew Hughes wrote:
 - Original Message -
 On 20/08/15 09:24, Matthias Klose wrote:
 On 08/20/2015 06:36 AM, Tom Tromey wrote:
 Andrew No, it isn't. It's still a necessity for initial bootstrapping of
 Andrew OpenJDK/IcedTea.

 Andrew Haley said the opposite here:

 https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html

 if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
 available for the target platform is required. Starting with OpenJDK
 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
 available on the cross platform.  It might be possible to cross
 build older OpenJDK versions, but this usually is painful.

 Sure, but we don't need GCJ going forward.  I don't think that there
 are any new platforms to which OpenJDK has not been ported which will
 require GCJ to bootstrap.  And even if there are, anybody who needs to
 do that can (and, indeed, should) use an earlier version of GCJ.  It's
 not going to go away; it will always be in the GCC repos.  And because
 newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
 sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.
 
 I don't see how we don't at present. How else do you solve the
 chicken-and-egg situation of needing a JDK to build a JDK? I don't
 see crossing your fingers and hoping there's a binary around
 somewhere as a very sustainable system.

That's what we do with GCC, binutils, etc: we bootstrap.

 From a personal point of view, I need gcj to make sure each new
 IcedTea 1.x and 2.x release bootstraps.

Sure, but all that does is test that the GCJ bootstrap still works.
And it's probably the only serious use of GCJ left.

 I don't plan to hold my system GCC at GCC 5 for the next decade or
 however long we plan to support IcedTea 2.x / OpenJDK 7. It's also
 still noticeably faster building with a native ecj than OpenJDK's
 javac.  It would cause me and others a lot of pain to remove gcj at
 this point. What exactly is the reason to do so, other than some
 sudden whim?

It's not a sudden whim: it's something we've been discussing for years.
The only reason GCJ is still alive is that I committed to keep it
going while we still needed it boot bootstrap OpenJDK.  Maintaining
GCJ in GCC is a significant cost, and GCJ has reached the end of its
natural life.  Classpath is substantially unmaintained, and GCJ
doesn't support any recent versions of Java.

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

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

[Andrew Haley]

On 08/20/2015 05:03 PM, Andrew Hughes wrote:
 The issue is that we're still supporting a version of OpenJDK/IcedTea where
 there is no previous version (6).

Surely OpenJDK 6 can build itself.  And in the unlikely event of an
entirely new architecture which has No OpenJDK we'd have to grab an
old GCJ and build it with that.

If GCJ is included as part of GCC but is not maintained and tested, it
will soon rot.  That isn't an option IMO.

Andrew.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

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

[Andrew Haley]

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

[Andrew Haley]

On 08/11/2015 07:54 PM, Jeff Law wrote:
 It's probably time for the occasional discussion WRT dropping 
 gcj/libjava from the default languages and replace them with either Ada 
 or Go.
 
 gcj/libjava are dead IMHO.

I have no objections.  GCJ has been tremendously useful bootstrapping
the OpenJDK ecosystem, but we no longer need it in order to have free
Java.

Andrew.

Re: [patch] libjava signal handling for FreeBSD (amd64/i386)

[Andrew Haley]

On 27/05/15 20:53, Andreas Tobler wrote:
 Is this ok for trunk?

Excellent, thanks.

Andrew.

Re: [patch] libjava testsuite

[Andrew Haley]

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

[Andrew Haley]

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

[Andrew Haley]

On 09/02/15 08:40, Andrew Pinski wrote:
 For ILP32, we need to use long long types for ffi_arg and ffi_sarg.
 And then we need to fix up the closure code to load cif, fn, and
 user_data by 32bit instead of 64bits as they are stored as pointers in
 C code.

Would it make more sense to use int64_t rather than long long?

Andrew.

Re: [PATCH] Fix PR64044

[Andrew Haley]

On 11/24/2014 12:29 PM, Richard Biener wrote:
 
 The following fixes an issue I found when more aggressively 
 constant-folding from static initializers.  The Java frontend
 fails to provide an initializer for the classdollar field
 it creates but nevertheless marks them with TREE_READONLY
 whilst being static.
 
 Thus the following patch removes setting of TREE_READONLY.
 
 Bootstrap  regtest running on x86_64-unknown-linux-gnu.
 
 Ok?

OK, thanks.

Andrew.

Re: [patch] Provide a can_compare_and_swap_p target hook.

[Andrew Haley]

On 06/11/14 19:05, Andrew MacLeod wrote:
 
 
 1) Given that the compiler *always* provides support via libatomic now 
 (even if it is via locks), does that mean that VMSupportsCS8_builtin() 
 should always return true?
 
 or should we map to that a call to __atomic_always_lock_free() ? (that 
 always gets folded to a true or false at compile time)  my guess is the 
 latter?

Perhaps so.  The problem is that some targets can't do CAS on 64-bit
doublewords.

 2) and in compareAndSwapLong_builtin(), thre is a wonky bit:
 
 /* We don't trust flag_use_atomic_builtins for multi-word compareAndSwap.
   Some machines such as ARM have atomic libfuncs but not the multi-word
   versions.  */
if (can_compare_and_swap_p (mode,
(flag_use_atomic_builtins
  GET_MODE_SIZE (mode) = UNITS_PER_WORD)))
  .. /* generate 8 byte CAS  */
 
 I gather we dont need to do anything special here anymore either? As 
 an observation of inconsistency,
 compareAndSwapObject_builtin  doesn't do that check before calling the 8 
 byte CAS :

I believe that any machine which has 64-bit pointers and can do CAS
can do a 64-bit CAS.  I'm worried about 32-bit machines trying to do a
64-bit CAS.

 3) And finally, is flag_use_atomic_builtins suppose to turn them off 
 completely?  Right now it is passed in  to the second parameter of 
 can_compare_and_swap_p, which really just says can we compare and swap 
 without calling a libfunc..   so currently if the flag is 0, but there 
 is native support, the call is generated anyway.   should that condition 
 really be:
 
 if (flag_use_atomic_builtins)
{
 ... /* generate atomic call */
   }

I'm sorry, I really can't remember.  I can't think of any reason to
want to turn off builtin support.  You have to remember that all this
was written when our support for atomic builtins was seriously flaky
and we would just punt back to the user anything we hadn't written
yet.

Andrew.

Re: [patch] Provide a can_compare_and_swap_p target hook.

[Andrew Haley]

On 11/06/2014 05:57 PM, Andrew MacLeod wrote:
 It looks like java is deciding whether or not GCC can inline atomic 
 operations or not, and if it can't, doesn't want the atomic 
 operations...   which presumably means there is no dependency on 
 libatomic at runtime.
 
 A call to can_compare_and_swap_p(mode) is analogous to a compile time 
 version of folding atomic_always_lock_free(mode) to a constant...   
 Frankly that seems like a reasonable question for some front end to 
 ask...  and elect not to emit atomic calls if so desired. (which is what 
 java is doing I think)
 
 whether it still needs to do that is a question for some java person.

I did it because some targets did not have library support for some
builtins, so a compile would fail with a (to a Java programmer)
baffling error message.

The Java operations certainly should use the generic builtins.

Andrew.

Re: [PATCH x86, java, PR63536] Fix java bootstrap for -mtune=intel/slm

[Andrew Haley]

On 10/15/2014 05:54 PM, Evgeny Stupachenko wrote:
 The patch fixes java i686 bootstrap for -mtune=intel/slm.
 
 Recent changes triggered java to write a note on compilation for a
 function without context.
 
 make check in progress
 
 Is it ok?

I guess so, but I don't understand how any function ends up with a null
DECL_CONTEXT.

Nontheless, this must go to java-patc...@gcc.gnu.org

Andrew.

Re: [Java PATCH] Generate declarations in jvgenmain.c

[Andrew Haley]

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

[Andrew Haley]

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'

[Andrew Haley]

On 06/10/14 05:08, Chen Gang wrote:
 After try normal configure, get almost the same result, I guess, our
 testsuite under Darwin x86_64 is OK.
 
 If no any additional reply within a week, I shall continue to try to
 analyze the libjava Throw_2 issue.

Throw_2 is a test specially contrived to detect segfaults that are
not being correctly detected and turned into NullPointerException()s.
A failure indicates that the segfault signal handler is broken.

Andrew.

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Andrew Haley]

On 10/06/2014 02:53 PM, Chen Gang wrote:
 On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
 After try normal configure, get almost the same result, I guess, our
 testsuite under Darwin x86_64 is OK.

 If no any additional reply within a week, I shall continue to try to
 analyze the libjava Throw_2 issue.

 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.
 
 OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
 and after run it without any parameters, 1 is printed, but 2 is not
 printed.
 
 Under Fedora 20 x86_64, the same gcc code, it is OK (2 can be printed),
 but under Darwin x86_64, it is Abort trap: 6 instead of. The related
 code: try{Double.parseDouble(str());}catch, and str(){return null;}.
 
 And I shall continue to try to analyze it (within this month), and 
 welcome any additional ideas, suggestions, and completion for it, 

Not every platform supports unwinding through signal handlers.  In x86
Linux there is some very clever code which interacts with the kernel to
allow this.

Andrew.

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Andrew Haley]

On 10/06/2014 03:27 PM, Chen Gang wrote:
 On 10/6/14 21:54, Andrew Haley wrote:
 On 10/06/2014 02:53 PM, Chen Gang wrote:
 On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
 After try normal configure, get almost the same result, I guess, our
 testsuite under Darwin x86_64 is OK.

 If no any additional reply within a week, I shall continue to try to
 analyze the libjava Throw_2 issue.

 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.

 OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
 and after run it without any parameters, 1 is printed, but 2 is not
 printed.

 Under Fedora 20 x86_64, the same gcc code, it is OK (2 can be printed),
 but under Darwin x86_64, it is Abort trap: 6 instead of. The related
 code: try{Double.parseDouble(str());}catch, and str(){return null;}.

 And I shall continue to try to analyze it (within this month), and 
 welcome any additional ideas, suggestions, and completion for it, 

 Not every platform supports unwinding through signal handlers.  In x86
 Linux there is some very clever code which interacts with the kernel to
 allow this.
 
 Excuse me, I am not quite familiar with Java, I guess what you said is:
 
  - The related feature need OS kernel support, if OS kernel does not
support, it may report Abort trap: 6 or others.
 
  - And OS kernel has feature to support 1 printed does not mean it
also has feature to support 2 printed.
 
  - And I need try to make sure that my current Darwin kernel whether
supports it or not.
 
 If what I guess is incorrect, please let me know, thanks.

That sounds approximately right, but it's changed a lot since I last
looked.  It may be that the magic is in glibc rather than the kernel.

 For me, whether Darwin kernel supports or not, we have to improve
 current implementation (may be testsuite configure or Makefile) to
 avoid testsuite breaking.

The testsuite isn't breaking: it's telling you something useful.

Andrew.

Re: Libjava test failure Was: [PATCH] microblaze: microblaze.md: Use 'SI' instead of 'VOID' for operand 1 of 'call_value_intern'

[Andrew Haley]

On 10/06/2014 04:00 PM, Chen Gang wrote:
 On 10/6/14 22:28, Andrew Haley wrote:
 On 10/06/2014 03:27 PM, Chen Gang wrote:
 On 10/6/14 21:54, Andrew Haley wrote:
 On 10/06/2014 02:53 PM, Chen Gang wrote:
 On 10/6/14 16:37, Andrew Haley wrote:
 On 06/10/14 05:08, Chen Gang wrote:
 After try normal configure, get almost the same result, I guess, our
 testsuite under Darwin x86_64 is OK.

 If no any additional reply within a week, I shall continue to try to
 analyze the libjava Throw_2 issue.

 Throw_2 is a test specially contrived to detect segfaults that are
 not being correctly detected and turned into NullPointerException()s.
 A failure indicates that the segfault signal handler is broken.

 OK, thank, at present, it passes compiling (can generate 'Throw_2.exe'),
 and after run it without any parameters, 1 is printed, but 2 is not
 printed.

 Under Fedora 20 x86_64, the same gcc code, it is OK (2 can be printed),
 but under Darwin x86_64, it is Abort trap: 6 instead of. The related
 code: try{Double.parseDouble(str());}catch, and str(){return null;}.

 And I shall continue to try to analyze it (within this month), and 
 welcome any additional ideas, suggestions, and completion for it, 

 Not every platform supports unwinding through signal handlers.  In x86
 Linux there is some very clever code which interacts with the kernel to
 allow this.

 Excuse me, I am not quite familiar with Java, I guess what you said is:

  - The related feature need OS kernel support, if OS kernel does not
support, it may report Abort trap: 6 or others.

  - And OS kernel has feature to support 1 printed does not mean it
also has feature to support 2 printed.

  - And I need try to make sure that my current Darwin kernel whether
supports it or not.

 If what I guess is incorrect, please let me know, thanks.

 That sounds approximately right, but it's changed a lot since I last
 looked.  It may be that the magic is in glibc rather than the kernel.

 
 OK, thanks, I shall also notice about glibc when I try to analyze it,
 e.g. need try to build and install upstream glibc instead of the Darwin
 glibc (I am not quite sure whether I can do that, I guess I can).
 
  
 For me, whether Darwin kernel supports or not, we have to improve
 current implementation (may be testsuite configure or Makefile) to
 avoid testsuite breaking.

 The testsuite isn't breaking: it's telling you something useful.

 
 Sorry it is breaked, at present, I temporarily skipped it and then can
 let make check finish, the related temporarily skip diff may like
 below (in real action, I modify the related Makefile, directly):

You're missing what I'm saying.  The testuite is not broken.

You should be running make -k check.

Andrew.

Re: Avoid privatization of TLS variables

[Andrew Haley]

I may be guilty of missing a crucial point here, but: why do we care
about having a small limit of static TLS variables?

We surely could allocate, say, a megabyte of static TLS for each
thread.  We already allocate 64M for the thread-local malloc arena,
after all.  It doesn't cost anything beyond a little address space.

What am I missing?

Andrew.

Re: Avoid privatization of TLS variables

[Andrew Haley]

On 27/09/14 08:56, Andrew Haley wrote:
 I may be guilty of missing a crucial point here, but: why do we care
 about having a small limit of static TLS variables?
 
 We surely could allocate, say, a megabyte of static TLS for each
 thread.  We already allocate 64M for the thread-local malloc arena,

On 64-bit systems, I mean.

 after all.  It doesn't cost anything beyond a little address space.
 
 What am I missing?
 
 Andrew.
 

Re: [Patch ARM] Fix PR target/56846

[Andrew Haley]

On 25/08/14 11:32, Tony Wang wrote:
 Hi all,
 
 The bug is reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846, 
 and it’s about the problem that
 when exception handler is involved in the function, then _Unwind_Backtrace 
 function will run into deadloop on
 arm target. 
 
 Cmd line: arm-none-eabi-g++ -mthumb -mcpu=cortex-m3 -O0 -g -std=c++11 
 -specs=rdimon.specs main.c -o main.exe
 #include unwind.h
 #include stdio.h
 _Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg)
 {
   void *ip = (void *)_Unwind_GetIP(context);
   printf(Address: %p\n, ip);
   return _URC_NO_REASON;
 }
 void bar()
 {
   puts(This is in bar);
   _Unwind_Backtrace((_Unwind_Trace_Fn)trace_func, 0);
 }
 void foo()
 {
   try
   {
 bar();
   }
   catch (...)
   {
 puts(Exception);
   }
 }
 
 The potential of such a bug is discussed long time ago in mail:
 https://gcc.gnu.org/ml/gcc/2007-08/msg00235.html. Basically, as the ARM EHABI 
 does not define how to implement
 the Unwind_Backtrace, Andrew give control to the personality routine to 
 unwind the stack, and use the unwind
 state combination of “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND” to 
 represent that the caller is asking the
 personality routine to only unwind the stack for it. 
 
 However, the pr in the libstdc++-v3 doesn’t handle such a unwind state 
 pattern correctly. When the backtrace
 function passes such a pattern to it, it will still return _URC_HANDLER_FOUND 
 to the caller in some cases.
 It’s because the pr will think that the _Unwind_Backtrace is raising a none 
 type exception to it, so if the
 exception handler in current stack frame can catch anything(like catch(…)), 
 the pr will return
 _URC_HANDLER_FOUND to the caller and ask for next step. But definitely, the 
 unwind backtrace function don’t
 know what to do when pr return an exception handler to it.
 
 So this patch just evaluate such a unwind state pattern at the beginning of 
 the personality routine in
 libstdc++-v3, if we meet with “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND”, 
 then we directly call macro
 CONTINUE_UNWINDING to unwind the stack and return.
 
 Is this a reasonable fix?
 
 gcc/libstdc++-v3/ChangeLog:
 2014-8-25   Tony Wang tony.w...@arm.com
 
  PR target/56846
  * libsupc++/eh_personality.cc: Return with CONTINUE_UNWINDING
  when meet with the unwind state pattern: 
 _US_VIRTUAL_UNWIND_FRAME |
  _US_FORCE_UNWIND

That looks very sensible, but it's not my call to approve it.

Andrew.

Re: [PATCH] libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c: Be sure 'errbuf' always be zero terminated.

[Andrew Haley]

On 07/30/2014 04:01 PM, Chen Gang wrote:
 I shall stop making this kind of patch, next. The reason is that I worry
 about what I have done have negative effect to others. And next, I shall
 try to send another kinds of patches for gcc when I have time.
 
 Many persons or companies use open source who never give thanks or
 contribution back to open source. But open source (especially,
 fundamental software) still provide common contributions to outside.
 
 What I have done is only for contribution back to open source, so I can
 understand none-reply from open source (at least, it is not the excuse
 to let myself stop). But what I worry about is whether bother others.

You only posted it yesterday.  It certainly looks reasonable enough,
but you surely don't expect an instant response.  By the way, the
correct mailing list is java-patc...@gcc.gnu.org.

Andrew.

Re: [DOC PATCH] Rewrite docs for inline asm

[Andrew Haley]

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

[Andrew Haley]

On 05/05/2014 09:23 PM, Gerald Pfeifer wrote:
 Understood.  Let's see that we can get an update committed soon.
 We can always improve on it further later on, which then will be
 a lot easier to do, review, and get pushed.

Yes.  We already know that this is better than the current docs.
Let's check it in.

Andrew.

Re: [DOC PATCH] Rewrite docs for inline asm

[Andrew Haley]

On 04/27/2014 11:56 AM, Richard Kenner wrote:
 any symbols it references. This may result in those symbols getting
 discarded by GCC as unreferenced.

 We can omit by GCC here.

 We can, but we should not.  We should avoid the passive voice like the
 plague in technical documentation, even if doing so leads to some
 slight redundancy.
 
 I agree, but that's still passive voice (you need not omit the actor to be
 using passive voice)!  Active voice (which is indeed preferred) is This
 may result in GCC discarding those symbols as unreferenced.

Indeed.  That's definitely better.

Andrew.

Re: [DOC PATCH] Rewrite docs for inline asm

[Andrew Haley]

On 04/26/2014 10:33 PM, Gerald Pfeifer wrote:
 +any symbols it references. This may result in those symbols getting 
 discarded 
  +by GCC as unreferenced.
 We can omit by GCC here.

We can, but we should not.  We should avoid the passive voice like the
plague in technical documentation, even if doing so leads to some
slight redundancy.

Andrew.

Re: [DOC PATCH] Rewrite docs for inline asm

[Andrew Haley]

On 04/25/2014 04:43 PM, James Greenhalgh wrote:
 Beyond comments on ChangeLog formatting, the review for this patch seems
 to have stalled again.
 
 The patch has been in review for two months now, with broadly positive 
 comments
 and all suggestions made thus far have been incorporated. I'd therefore like
 to
 
 *ping*
 
 this on David's behalf and try to get the review moving again.

We're waiting for Joseph Myers or, at a pinch, a maintainer with global
write privs.

Andrew.

Re: Remove obsolete Solaris 9 support

[Andrew Haley]

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 strong reason
to do so.

Andrew.

UBSan fix: avoid undefined behaviour in bitmask

[Andrew Haley]

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 (mark_reference_fields): Avoid unsigned integer overflow
when calculating an index into a bitmap descriptor.

Index: gcc/java/boehm.c
===
--- gcc/java/boehm.c(revision 208839)
+++ gcc/java/boehm.c(working copy)
@@ -107,7 +107,11 @@
 bits for all words in the record. This is conservative, but the
 size_words != 1 case is impossible in regular java code. */
  for (i = 0; i  size_words; ++i)
-   *mask = (*mask).set_bit (ubit - count - i - 1);
+   {
+ int bitpos = ubit - count - i - 1;
+ if (bitpos = 0)
+   *mask = (*mask).set_bit (bitpos);
+   }

  if (count = ubit - 2)
*pointer_after_end = 1;

Re: [PATCH, libjava]: Avoid suggest parentheses around comparison in operand of '|' in java/lang/natObject.cc

[Andrew Haley]

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

[Andrew Haley]

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

[Andrew Haley]

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 $(toolexeclibdir), not
 $(libdir).
 ...

 that makes a wreck out of my 4.9-based libjava installs.

 First it avoids to break dbexecdir with MULTSUBDIR= by removing
 the redundant but non-version-specific-aware multilib addition.

 Second, it makes sure that gcc_version, used in the
 version-specific path, is defined at all in classpath/ and its
 subdirs.

 Tested for my particular configuration, I'll do a default,
 non-version-specific one as well (but expect no changes).

 Ok for trunk?
 
 In addition to my weird non-multilib version-specific variant
 I now tested regular non-version-specific and multilib variant
 as well as version-specific multilib variant and all looks ok.
 
 Thus,
 
 Ok for trunk?

It may be that someone understands this, but I don't.  What does this change
do?

Andrew.

Re: [PATCH] Fix libjava install with --enable-version-specific-runtime-libs

[Andrew Haley]

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

[Andrew Haley]

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

[Andrew Haley]

On 12/26/2013 12:11 AM, Andreas Tobler wrote:
 On 21.12.13 18:27, Andrew Haley wrote:
 On 12/20/2013 10:15 PM, Andreas Tobler wrote:
 Ok for gcc trunk?

 OK, thanks.

 
 May I get this one down to 4.8 too? Not really needed, but for
 completeness. Results will follow...

No objections from me.

Andrew.

Re: [patch] powerpc64 FreeBSD support for boehm-gc

[Andrew Haley]

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

[Andrew Haley]

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 has been done.  The target that
 creates libgcj_bc.la for the testsuite is mucking around with internal
 details that will confuse libtool when it tries to install it, the
 effect of which can't be undone by install-exec-hook.  We need to create
 a clean second copy that is actually installed.
 
 Ok if nobody objects in the next 24h.

OK, thanks!

Andrew.

Re: [C++ Patch, Java related/RFC] PR 11006

[Andrew Haley]

On 11/04/2013 05:21 PM, Jason Merrill wrote:
 Surely it should be valid to allocate a Java boolean type.  Andrew,
 how should that work?

It's not allowed.  All objects that are allocated by new must be of
class type (i.e.  instances of a subclass of java.lang.Object), but
boolean is a primitive type.

Andrew.

Re: [PATCH, PowerPC] Fix PR57949 (ABI alignment issue)

[Andrew Haley]

On 09/12/2013 03:11 AM, Alan Modra wrote:
 We have precedent for compiling libffi based on gcc preprocessor
 defines, eg. __NO_FPRS__, so here's a way of making upstream libffi
 compatible with the various versions of gcc out there.  I've taken the
 condition under which we align aggregates from
 rs6000_function_arg_boundary, and defined a macro with a value of the
 maximum alignment.

I would have thought that a runtime or configure-time test in libffi
would be better.

Andrew.

Re: [patch] boehm-gc: link libgcjgc with -ldl

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

Andrew.

Re: [patch] boehm-gc: link libgcjgc with -ldl

[Andrew Haley]

On 09/04/2013 11:24 AM, Matthias Klose wrote:
 Am 04.09.2013 12:21, schrieb Andrew Haley:
 On 09/04/2013 11:00 AM, Matthias Klose wrote:
 The boehm-gc tests currently fail to build with a linker with
 --no-copy-dt-needed-entries as the default.

 Hmm, isn't that a bug in the linker?
 
 No, it's the default in gold and in the bfd linker since 2.23.

Oh, right.  I wonder how many other things this will break.  OK.

Andrew.

Backport from trune:

[Andrew Haley]

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-linux.h
===
--- gcc/config/aarch64/aarch64-linux.h  (revision 201661)
+++ gcc/config/aarch64/aarch64-linux.h  (working copy)
@@ -23,6 +23,8 @@

 #define GLIBC_DYNAMIC_LINKER /lib/ld-linux-aarch64.so.1

+#define CPP_SPEC %{pthread:-D_REENTRANT}
+
 #define LINUX_TARGET_LINK_SPEC  %{h*} \
%{static:-Bstatic}  \
%{shared:-shared}   \

Re: fatal error: gnu/stubs-32.h: No such file

[Andrew Haley]

On 07/29/2013 02:06 PM, FX wrote:
 +build of a native compiler on @samp{x86_64-unknown-linux-gnu}, beware of
 +either:
 +
 +@itemize @bullet
 +@item having 32-bit libc developer package properly installed (the exact
 +name of the package depends on your distro); otherwise, you may encounter an
 +error such as @samp{fatal error: gnu/stubs-32.h: No such file}
 +@item building GCC as a 64-bit only compiler, by configuring with the
 +option @option{--disable-multilib}
 +@end itemize

Looks good.

This should be

Make sure you either have the 32-bit libc developer package properly
installed (the exact name of the package depends on your distro) or
you must build GCC as a 64-bit-only compiler by configuring with the
--disable-multilib option.  Otherwise, you may encounter an
error such as @samp{fatal error: gnu/stubs-32.h: No such file}

Re: fatal error: gnu/stubs-32.h: No such file

[Andrew Haley]

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 to do.  The reply, basically, was:
 
 It's too hard.

It was This is possible, but it's tricky, and it's really important
to get it right.  We don't want a half-arsed patch.

 But we know people are running into this issue and reporting it.
 Yes.  But that on its own is not sufficient to change the default
 
 That's a pretty obnoxious comment.

Oh dear.

 I translate it as, I don't care if people are having trouble.

That's a mistranslation.  It means that there are other criteria
beyond some people having trouble.  Such as, we really want multilibs
to be built.

 It is a nuisance to me to do that and anyone building GCC should
 already know they need whateveritwas-devel for 32 bits.  I guess
 I can be obnoxious, too.  But slightly more politely put:
 
 No, we aren't. We're disagreeing about whether it's acceptable to
 enable a feature by default that breaks the compiler build half way
 through with an obscure error message. Real systems need features that
 aren't enabled by default sometimes.
 
 The fundamental issue, to me, is: What do you do when you cannot
 proceed?
 
 I think you should detect the issue as *soon as practical* and then
 *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*.

Yes!  Yes!  Yes!

Andrew.

Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer

[Andrew Haley]

On 06/24/2013 09:13 AM, Dodji Seketeli wrote:
 Just to make sure I understand what you are saying; do you mean that the
 accessor macro GET_XML_OUTPUT_BUFFER_SIZE (that depends on
 LIBXML2_NEW_BUFFER) shouldn't be defined in
 libjava/classpath/native/jni/xmlj/xmlj_io.c but somewhere else by an
 autoconf macro?  If so, maybe you should elaborate more on what you have
 in mind exactly as I am not really well acquainted with (the configury
 of) gnu classpath.  I did this thing quickly so that the build doesn't
 break on newer versions of libxml2.

OK, I get it now, thanks.

Andrew.

Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer

[Andrew Haley]

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

[Andrew Haley]

On 06/21/2013 12:19 PM, Daniel Veillard wrote:
 On Fri, Jun 21, 2013 at 12:13:35PM +0100, Andrew Haley wrote:
 On 08/08/2012 11:08 PM, Dodji Seketeli wrote:
 OK to commit?

 Looks good, but what sets LIBXML2_NEW_BUFFER ?
 
   I lack context but I think I can answer that one :)
 
 LIBXML2_NEW_BUFFER is a libxml2 public macro from libxml/tree.h
 
 /*
  * LIBXML2_NEW_BUFFER:
  *
  * Macro used to express that the API use the new buffers for
  * xmlParserInputBuffer and xmlOutputBuffer. The change was
  * introduced in 2.9.0.
  */
 
 http://xmlsoft.org/html/libxml-tree.html#LIBXML2_NEW_BUFFER

Sure, but there's no point adding it to libgcj if it's not set by
anything.  It needs an autoconf macro or somesuch.

Andrew.

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

[Andrew Haley]

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
 --- a/libjava/contrib/aot-compile.in
 +++ b/libjava/contrib/aot-compile.in
 @@ -52,7 +52,7 @@ try:
   sys.argv[1:],
   M:C:D:m:c:l:e:,
   [make=, gcj=, dbtool=,
 - makeflags= gcjflags=, ldflags=,
 + makeflags=, gcjflags=, ldflags=,
exclude=])
   srcdir, dstdir = args
   except:
 

OK with a ChangeLog entry.

Andrew.

Re: [PATCH] Fix linking with -findirect-dispatch

[Andrew Haley]

On 04/26/2013 12:22 PM, Matthias Klose wrote:
 I do see this now too, however the root of the problem seems to be a linker
 which defaults to --as-needed (which is the case on SuSe afaik).

Is this a non-standard thing?  So SuSe has a special --configure option
which does this?  We can always patch in --no-as-needed

Andrew.

Re: [PATCH] Enable java for aarch64

[Andrew Haley]

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

[Andrew Haley]

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

[Andrew Haley]

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?

[Andrew Haley]

On 12/21/2012 04:02 AM, Gerald Pfeifer wrote:
 PING.
 
 On Fri, 2 Nov 2012, Gerald Pfeifer wrote:
 Rainer (or others),

 the FAQ entry below seems obsolete to me (dates back more than a
 decade).  Shall we remove it, or is there something else we still
 should document (in addition to gcc/doc/install.texi)?

OK, thanks.

Andrew.

Re: ASAN merge...

[Andrew Haley]

On 11/14/2012 01:49 PM, Richard Earnshaw wrote:

 Please please don't get into the habit of calling it ARM32 and ARM64, 
 you're just sowing confusion; there are good reasons why those names 
 weren't adopted (some technical, some not) and I'm not about to rehash 
 them all now.  AArch32 and AArch64 aren't that much harder to type and 
 they are completely unambiguous.

And they can't be pronounced in any reasonable way.  I think
you're going to lose this one.

Andrew

Re: [patch] update zlib to 1.2.7

[Andrew Haley]

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

[Andrew Haley]

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 house is hooked up to a small generator, and no one has any power
 for miles around.

 So far richi has promised to review them.   he has sent some comments, but
 so far no reviews.Some time after i get the first round of them posted,
 i will do a second round that incorporates everyones comments.

 But i would like a little slack here if possible.While this work is a
 show stopper for my private port, the patches address serious problems for
 many of the public ports, especially ones that have very flexible vector
 units.I believe that there are significant set of latent problems
 currently with the existing ports that use ti mode that these patches will
 fix.

 However, i will do everything in my power to get the first round of the
 patches posted by nov 5 deadline.
 
 I suppose you are not going to merge your private port for 4.8 and thus
 the wide-int changes are not a show-stopper for you.
 
 That said, I considered the main conversion to be appropriate to be
 defered for the next stage1.  There is no advantage in disrupting the
 tree more at this stage.

We are still in Stage 1.  If it were later in the release cycle this
argument would have some merit, but under the rules this sort of thing
is allowed at any point in Stage 1.  If we aren't going to allow
something like this because it's too late we should have closed
Stage 1 earlier.

Andrew.

Re: [wwwdocs,Java] Replace sources.redhat.com by sourceware.org

[Andrew Haley]

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

[Andrew Haley]

On 10/16/2012 08:17 AM, Jan Hubicka wrote:
   * builtins.c (define_builtin): Accept ECF flags and
   use set_call_expr_flags.
   (initialize_builtins): Update; add BULIT_IN_UNREACHALE.
 
   * calls.c (set_call_expr_flags): New.
   * tree.h (set_call_expr_flags): Declare.

OK, thanks.

Andrew.

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

[Andrew Haley]

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 ok for trunk?

Yes, thanks.

Andrew.

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

[Andrew Haley]

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)
 stacktrace.c(stacktrace.java:31)
 stacktrace.b(stacktrace.java:26)
 stacktrace.a(stacktrace.java:19)
 stacktrace.main(stacktrace.java:12)
 #gcj *.class -o stacktrace.exe
 #./stacktrace.exe
 stacktrace.e(stacktrace.exe:-1)
 stacktrace.d(stacktrace.exe:-1)
 stacktrace.c(stacktrace.exe:-1)
 stacktrace.b(stacktrace.exe:-1)
 stacktrace.a(stacktrace.exe:-1)
 stacktrace.main(stacktrace.exe:-1)

Works for me:

[aph@nighthawk ~]$ gcj stacktrace.java --main=stacktrace -g
[aph@nighthawk ~]$ ./a.out
stacktrace.e(stacktrace.java:42)
stacktrace.d(stacktrace.java:38)
stacktrace.c(stacktrace.java:31)
stacktrace.b(stacktrace.java:26)
stacktrace.a(stacktrace.java:19)
stacktrace.main(stacktrace.java:12)

Aren't you just compiling without -g ?  There is no debuginfo.

Andrew.

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

[Andrew Haley]

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, I don't think that we want a testcase to rely on
 addr2line in the system. So how about that that we add a test when
 assembly scan is available in libgcj testsuit?

Fine by me.  I guess you can just copy the scanning code from the gcc
testsuite.

Andrew.

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

[Andrew Haley]

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 isn't present in the libgcj testsuite?

 Yes, exactly.

 For this case, I don't think that we want a testcase to rely on
 addr2line in the system. So how about that that we add a test when
 assembly scan is available in libgcj testsuit?
 
 Once Ian Lance Taylor's libbacktrace patch is integrated (see:
 http://gcc.gnu.org/ml/gcc/2012-08/msg00317.html), we'll be able to get
 rid of the code that calls addr2line from libgcj.

As I understand it, Ian Taylor's backtrace patch is intended for use in
gcc development, and as he puts it Since its use in GCC would
be purely for GCC developers, it's not essential that it be fully
portable.  Not for gcj runtime.

Andrew.