Java front-end and library patches.

Java front-end and library patches.

[Zopolis0]

Disclaimer: this does not currently work.

The front-end and library compile successfully, but fail to link at
the very end.
This is due to a regression caused by
1dedc12d186a110854537e1279b4e6c29f2df35a, which I have been unable to
solve.

Nevertheless, I am posting this patch series for two reasons.

Firstly, to get feedback and reviews on the 56 already existing
patches, even though most are just re-adding code or making idiomatic
changes, so that when the final issue is solved everything has already
been approved (hopefully) and the merge is good to go.

Secondly, to get assistance with the final issue, because it is simply
beyond me, and history has shown that asking for help via gcc-patches
will yield nothing.

You'll need libtool 2.4.7 and a bleeding-edge version of bdwgc to
build it, in case anyone planned to do some testing.

I have compressed the larger patches with bzip3, and attached the
rest, hopefully as plaintext.

Re: Java front-end and library patches.

[Joseph Myers]

On Fri, 25 Nov 2022, Zopolis0 via Gcc-patches wrote:

> Firstly, to get feedback and reviews on the 56 already existing
> patches, even though most are just re-adding code or making idiomatic
> changes, so that when the final issue is solved everything has already
> been approved (hopefully) and the merge is good to go.

I think a lot more explanation is needed to get much useful feedback.

* Each patch should have its own explanation of what it is doing and why, 
in the message body (not in an attachment).  Just the commit summary line 
and ChangeLog entries aren't enough, we need the actual substantive commit 
message explaining the patch.

* An overall explanation is needed of what the patch series is doing and 
why.  Why is it now considered useful to add this front end back?  Which 
version is the basis of the one being added back - the version removed 
from GCC (that used ECJ for converting Java source to Java byte-code), or 
some other version?  How has the series been validated?  Would you propose 
to maintain the front end and libraries in future?  Would you re-open any 
bugs against the front end or libraries that were closed (as WONTFIX or 
otherwise) as a result of it being removed from the tree (maybe when it 
was removed, maybe later when the last release series with the front end 
ceased to be supported)?  And so on.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Java front-end and library patches.

[Zopolis0]

> * Each patch should have its own explanation of what it is doing and why,
> in the message body (not in an attachment).  Just the commit summary line
> and ChangeLog entries aren't enough, we need the actual substantive commit
> message explaining the patch.

The thing is, most of the patches do not need an explanation. Patches
1-13 are just re-adding code, 20-43 and 47 are just applying treewide
changes that Java missed out on, and patches 44-56 are either
incredibly simple or self-evident. If you feel like any of the listed
patches require an explanation, let me know and I will provide one,
but for now I dont see a reason to explain those.

However, patches 14-19 do need an explanation, as proven by multiple
reviews simply asking why I had made them. I'll send follow up
messages to those.

> Why is it now considered useful to add this front end back?

The way I see it, the Java front end was removed due to a lack of
maintenance and improvement. To put it simply, I am going to maintain
and improve it. That is the difference between now and then. There is
more nuance, but that is the gist of it.

> Which version is the basis of the one being added back...?

The exact same one that was removed from GCC, with the version taken
being the one right before it was removed.

> How has the series been validated?

I'm not exactly sure what you mean by this.

> Would you propose to maintain the front end and libraries in future?

I have big plans for the library, and plan to maintain that long into
the future. In regards to the actual front-end code, I will do what I
can to make sure it remains at its previous level of function, but
that is about it. I dislike working with the front end code, so I will
fix it, but I will not make sweeping changes to it.

>  Would you re-open any bugs against the front end or libraries that were closed...as a result of it being removed from the tree...?

Good point, I hadn't thought of that. It makes sense to re-open them,
as they are by definition valid again, although I may have difficulty
with the frontend ones, as that is not my strong suit.




Just a brief overview of my plans for the frontend and library-- When
GCJ was first introduced it was "the free Java implementation". It was
trying to offer a bytecode compiler, a machine code compiler and a
runtime library. Clearly, this was too much, as it borrowed another
bytecode compiler and runtime library, and even then the runtime
library fell into dissaray.

Now, we have many pieces of the puzzle. We have a bounty of free Java
bytecode compilers, and a free runtime library. The only thing missing
is a free machine code compiler, which GCJ was and is. I plan to
replace Classpath with the OpenJDK, and double down on the machine
code aspect of GCJ, dropping bytecode and interpreted support.

Re: Java front-end and library patches.

[Xi Ruoyao]

On Wed, 2022-11-30 at 23:18 +1100, Zopolis0 via Gcc-patches wrote:
> 20-43 and 47 are just applying treewide changes that Java missed out
> on

Add something like "adapt Java frontend for r11-1234 change" then.  So
the reviewer can take a look at https://gcc.gnu.org/r11-1234 and review
the change more easily.

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: Java front-end and library patches.

[Joseph Myers]

On Wed, 30 Nov 2022, Zopolis0 via Gcc-patches wrote:

> > * Each patch should have its own explanation of what it is doing and why,
> > in the message body (not in an attachment).  Just the commit summary line
> > and ChangeLog entries aren't enough, we need the actual substantive commit
> > message explaining the patch.
> 
> The thing is, most of the patches do not need an explanation. Patches
> 1-13 are just re-adding code,

Then state that in the message body (with a reference to the commit that 
removed the code).

Just because code was removed in a given form doesn't mean it should be 
added back in that form.  For example, patch 13, "Re-add 
flag_evaluation_order, reorder_operands_p, and add reorder bool argument 
to tree_swap_operands_p", seems suspicious.  That sort of global state 
affecting IR semantics is best avoided; rather, the Java gimplification 
support should deal with ensuring the correct ordering for operations in 
the GIMPLE generated.  Note that C++ flag_strong_eval_order (for C++17 
evaluation order requirements) is specific to the front end; it doesn't 
require anything in expr.cc or fold-const.cc or other language-independent 
files.  So you should do something similar for Java rather than adding 
back global language-independent state for this.

Patches 1 and 2 don't seem to have reached the mailing list.

> 20-43 and 47 are just applying treewide
> changes that Java missed out on,

So say for each one exactly which commit it's applying the changes for.

> > How has the series been validated?
> 
> I'm not exactly sure what you mean by this.

What target triplets did you run the GCC testsuite on (before and after 
the changes, with no regressions), with what results for the Java-specific 
tests?

> I plan to
> replace Classpath with the OpenJDK, and double down on the machine
> code aspect of GCJ, dropping bytecode and interpreted support.

This sort of thing is key information to include in the summary message 
for any future versions of the patch series.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Java front-end and library patches.

[Thomas Schwinge]

Hi!

On 2022-11-30T23:18:06+1100, Zopolis0 via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> However, patches 14-19 do need an explanation, as proven by multiple
> reviews simply asking why I had made them. I'll send follow up
> messages to those.

Well, (at least for some of them) re-work rather than explanations.  ;-)


Anyway:

>> Why is it now considered useful to add this front end back?
>
> The way I see it, the Java front end was removed due to a lack of
> maintenance and improvement. To put it simply, I am going to maintain
> and improve it. That is the difference between now and then. There is
> more nuance, but that is the gist of it.

Ha, nice!  As it happens, a few months ago, I started the same task...
(... but with very low priority, so have not yet gotten very far...)


>> How has the series been validated?
>
> I'm not exactly sure what you mean by this.

Testing; the integrated GCC/Java test suites, as well as possibly any
external test suites.  To make sure that we're (a) not regressing
anything in non-Java GCC, and (b) that we're maintaining the
functionality level of the "old" GCC/Java.  That said, I found that the
integrated GCC/Java test suites are not exactly testing all that should
be tested...

My approach has been to establish an "old" baseline, and then gradually
rebase this onto specific GCC master branch commits, and catch up with
tree-wide changes along the way.  I've not gotten all too far yet; made a
stop to first add more testing to the baseline, so that I can be
reasonably sure that GCC/Java doesn't regress in functionality.  (It's
been sitting in that state for a number of months now...)  It may be a
somewhat more painful approach in comparison to the "all in one go"
approach that you seem to have attempted (?), but it seemed more
appropriate for me, as I'm only able to spend occasional small blocks of
time on this.


>> Would you propose to maintain the front end and libraries in future?
>
> I have big plans for the library, and plan to maintain that long into
> the future. In regards to the actual front-end code, I will do what I
> can to make sure it remains at its previous level of function, but
> that is about it. I dislike working with the front end code, so I will
> fix it, but I will not make sweeping changes to it.

I might thus be interested in joining that effort (I'm more interested in
the front end and GCC proper parts) -- but, again, this will be
low-priority project for me.


Grüße
 Thomas


> Just a brief overview of my plans for the frontend and library-- When
> GCJ was first introduced it was "the free Java implementation". It was
> trying to offer a bytecode compiler, a machine code compiler and a
> runtime library. Clearly, this was too much, as it borrowed another
> bytecode compiler and runtime library, and even then the runtime
> library fell into dissaray.
>
> Now, we have many pieces of the puzzle. We have a bounty of free Java
> bytecode compilers, and a free runtime library. The only thing missing
> is a free machine code compiler, which GCJ was and is. I plan to
> replace Classpath with the OpenJDK, and double down on the machine
> code aspect of GCJ, dropping bytecode and interpreted support.
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: Java front-end and library patches.

[Zopolis0]

In response to the testing thing, one critical issue is that these
patches aren't entirely functional (see the second point of my
original message), so I can't test yet. I'll check once I can though.

Re: Java front-end and library patches.

[Zopolis0]

>  the "all in one go" approach that you seem to have attempted (?)

I did do all the patches in one go onto master, but for rebases and
bisects I did apply them on various baselines. See
https://github.com/Zopolis4/gcj-branches, where all the branches
labellled newplan/year-month-day will have these patches reapplied on
that date.

On Fri, Dec 2, 2022 at 11:24 AM Zopolis0 <creatorsmithmdt@gmail.com> wrote:
>
> In response to the testing thing, one critical issue is that these
> patches aren't entirely functional (see the second point of my
> original message), so I can't test yet. I'll check once I can though.

Re: Java front-end and library patches.

[Zopolis0]

> Patches 1 and 2 don't seem to have reached the mailing list.

File size issues on the receiving server. I bzip3 compressed them, but
they were still too big.

Re: Java front-end and library patches.

[Zopolis0]

I've been looking over the reviews as well as a few things I've
encountered locally, and collected this list:

Unfortunately, I am simply not familiar enough with the gcc tree to
implement patch 16, although there is a slight possibility that I may
be able to do patch 19, and a stronger one that I could do patch 16.
(Although I have been working on patch 19 and 16 for a few months now
and with little success).

I can definitely do patch 53, and am working on that.

While patch 13, 16 and 19 are all sub-par solutions, they are
solutions, and as such implementing better solutions is a lower
priority than fixing the remaining issue, the -dumpbase caused linker
error. I would very much appreciate help in that area specifically, as
once that is solved we'll have a working compiler and library, and
then I can focus on improving the library.

(Patch 13) Re-add flag_evaluation_order, reorder_operands_p, and add
reorder bool argument to tree_swap_operands_p:
Replace with front-end specific function ala flag_strong_eval_order

(Patch 16) gcc: Re-add TYPE_METHODS:
Remove, replace instances of TYPE_METHODS with TYPE_FIELDS in the java frontend

(Patch 19) Revert "Move void_list_node init to common code".
(8ff2a92a0450243e52d3299a13b30f208bafa7e0):
Remove, handle properly in Java frontend.

Breakage caused by 1dedc12d186a110854537e1279b4e6c29f2df35a:
Changes to -dumpbase cause undefined link errors, fix usage of
-dumpbase in gcc/java/jvspec.cc

(Patch 53) classpath: Use modern autotools mkdir -p handling:
Find way to make MKDIR_P propagate to generated copy-vmresources.sh

Re: Java front-end and library patches.

[Zopolis0]

Patch 19 has been resolved.

Re: Java front-end and library patches.

[Zopolis0]

Re: 1dedc12d186a110854537e1279b4e6c29f2df35a breakage

I've done some more research, it's not the -dumpbase. Comparing the
java frontend on master as opposed to one based on a commit right
before 1dedc12, the master has '-dumpdir' '.libs/jv-convert-' while
the one before does not, which I believe is causing the breakage.

Master:
zopolis4@epidural ~/g/x/libjava> /bin/bash ./libtool --tag=GCJ
--mode=link /home/zopolis4/gcjbuild/./gcc/gcj
-B/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/ -B/h
ome/zopolis4/gcjbuild/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local
/x86_64-pc-linux-gnu/sys-include
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava
-fomit-frame-pointer -Usun -v -g -O2  -o jv-convert
--main=gnu.gcj.convert.Convert
 -rpath /usr/local/lib/../lib64 -shared-libgcc
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/.libs libgcj.la
libtool: link: /home/zopolis4/gcjbuild/./gcc/gcj
-B/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/
-B/home/zopolis4/gcjbuild/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -fomit-frame-pointer -Usun
-v -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert
-shared-libgcc
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/.libs
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava
./.libs/libgcj.so -lpthread -lrt -lltdl -lgc -Wl,-rpath
-Wl,/usr/local/lib/../lib64
Reading specs from /home/zopolis4/gcjbuild/./gcc/specs
Reading specs from
/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=/home/zopolis4/gcjbuild/./gcc/gcj
COLLECT_LTO_WRAPPER=/home/zopolis4/gcjbuild/./gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/zopolis4/gcjbuild/../gcj/configure
--disable-bootstrap --disable-multilib --disable-libstdcxx
--disable-libquadmath --disable-libgomp --disable-libgfortran
--enable-languages=java : (reconfigured)
/home/zopolis4/gcjbuild/../gcj/configure --disable-bootstrap
--disable-multilib --disable-libstdcxx --disable-libquadmath
--disable-libgomp --disable-libgfortran --disable-libgm2
--enable-languages=java : (reconfigured)
/home/zopolis4/gcjbuild/../gcj/configure --disable-bootstrap
--disable-multilib --disable-libstdcxx --disable-libquadmath
--disable-libgomp --disable-libgfortran --disable-libgm2
LDFLAGS='-static-libstdc++ -static-libgcc
-L/usr/lib/gcc/x86_64-linux-gnu/12' --enable-languages=c,c++,java,lto
--no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221214 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B'
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/' '-B'
'/home/zopolis4/gcjbuild/./gcc/' '-B'
'/usr/local/x86_64-pc-linux-gnu/bin/' '-B'
'/usr/local/x86_64-pc-linux-gnu/lib/' '-isystem'
'/usr/local/x86_64-pc-linux-gnu/include' '-isystem'
'/usr/local/x86_64-pc-linux-gnu/sys-include' '-fomit-frame-pointer'
'-U' 'sun' '-v' '-g' '-O2' '-o' '.libs/jv-convert' '-shared-libgcc'
'-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/.libs'
'-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava'
'-fbootclasspath=./:/usr/local/share/java/libgcj-13.0.0.jar'
'-specs=/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/libgcj.spec'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir'
'.libs/jv-convert-' //here is the big differentiation point
 /home/zopolis4/gcjbuild/./gcc/jvgenmain
.libs/jv-convert-gnu.gcj.convert.Convertmain /tmp/ccomuP4d.i
COLLECT_GCC_OPTIONS='-B'
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/' '-B'
'/home/zopolis4/gcjbuild/./gcc/' '-B'
'/usr/local/x86_64-pc-linux-gnu/bin/' '-B'
'/usr/local/x86_64-pc-linux-gnu/lib/' '-isystem'
'/usr/local/x86_64-pc-linux-gnu/include' '-isystem'
'/usr/local/x86_64-pc-linux-gnu/sys-include' '-fomit-frame-pointer'
'-U' 'sun' '-v' '-g' '-O2' '-o' '.libs/jv-convert' '-shared-libgcc'
'-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/.libs'
'-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava'
'-specs=/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/libgcj.spec'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir'
'.libs/jv-convert-'
 /home/zopolis4/gcjbuild/./gcc/cc1 /tmp/ccomuP4d.i -quiet
-mtune=generic -march=x86-64 -g -O2 -imultiarch x86_64-linux-gnu
-iprefix /home/zopolis4/gcjbuild/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.0/
-isystem /home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/include
-isystem /home/zopolis4/gcjbuild/./gcc/include -isystem
/home/zopolis4/gcjbuild/./gcc/include-fixed/x86_64-linux-gnu -isystem
/home/zopolis4/gcjbuild/./gcc/include-fixed -version
-fomit-frame-pointer -fdollars-in-identifiers -o /tmp/ccG4mONV.s
GNU C17 (GCC) version 13.0.0 20221214 (experimental) (x86_64-pc-linux-gnu)
        compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR
version 4.1.0, MPC version 1.2.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 13.0.0 20221214 (experimental) (x86_64-pc-linux-gnu)
        compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR
version 4.1.0, MPC version 1.2.1, isl version isl-0.25-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f162c9d9cbdc4292aa66b1d49d6c1990
COLLECT_GCC_OPTIONS='-B'
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/' '-B'
'/home/zopolis4/gcjbuild/./gcc/' '-B'
'/usr/local/x86_64-pc-linux-gnu/bin/' '-B'
'/usr/local/x86_64-pc-linux-gnu/lib/' '-isystem'
'/usr/local/x86_64-pc-linux-gnu/include' '-isystem'
'/usr/local/x86_64-pc-linux-gnu/sys-include' '-fomit-frame-pointer'
'-U' 'sun' '-v' '-g' '-O2' '-o' '.libs/jv-convert' '-shared-libgcc'
'-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/.libs'
'-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava'
'-specs=/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/libgcj.spec'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir'
'.libs/jv-convert-'
 /home/zopolis4/gcjbuild/./gcc/as -v --gdwarf-5 --64 -o
/tmp/ccoyR03i.o /tmp/ccG4mONV.s
GNU assembler version 2.39.50 (x86_64-linux-gnu) using BFD version
(GNU Binutils for Debian) 2.39.50.20221208
COMPILER_PATH=/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/:/home/zopolis4/gcjbuild/./gcc/
LIBRARY_PATH=/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/:/home/zopolis4/gcjbuild/./gcc/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B'
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/' '-B'
'/home/zopolis4/gcjbuild/./gcc/' '-B'
'/usr/local/x86_64-pc-linux-gnu/bin/' '-B'
'/usr/local/x86_64-pc-linux-gnu/lib/' '-isystem'
'/usr/local/x86_64-pc-linux-gnu/include' '-isystem'
'/usr/local/x86_64-pc-linux-gnu/sys-include' '-fomit-frame-pointer'
'-U' 'sun' '-v' '-g' '-O2' '-o' '.libs/jv-convert' '-shared-libgcc'
'-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/.libs'
'-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava'
'-specs=/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/libgcj.spec'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir'
'.libs/jv-convert.'
 /home/zopolis4/gcjbuild/./gcc/collect2 -plugin
/home/zopolis4/gcjbuild/./gcc/liblto_plugin.so
-plugin-opt=/home/zopolis4/gcjbuild/./gcc/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccmsk44b.res
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcj -plugin-opt=-pass-through=-lm
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lrt
-plugin-opt=-pass-through=-ldl -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o .libs/jv-convert
/lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o
/home/zopolis4/gcjbuild/./gcc/crtbegin.o
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava/.libs
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava
-L/home/zopolis4/gcjbuild/./gcc -L/lib/x86_64-linux-gnu
-L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64
/tmp/ccoyR03i.o ./.libs/libgcj.so -lpthread -lrt -lltdl -lgc -rpath
/usr/local/lib/../lib64 -lgcc_s -lgcc -lgcj -lm -lpthread -lrt -ldl
-lgcc_s -lgcc -lc -lgcc_s -lgcc /home/zopolis4/gcjbuild/./gcc/crtend.o
/lib/x86_64-linux-gnu/crtn.o
/usr/bin/ld: /tmp/ccoyR03i.o: in function `main':
/tmp/ccomuP4d.i:12: undefined reference to
`libs__U2f_jv__U2d_convert__U2d_gnu::gcj::convert::Convert::class$'
collect2: error: ld returned 1 exit status


Before breakage:
ihateubuntu@CB10LOAN01L ~/s/x/libjava> /bin/bash ./libtool --tag=GCJ
--mode=link /home/ihateubuntu/shmubuntu/gcc/gcj
-B/home/ihateubuntu/shmubuntu/gcc/ -B/home/ihateubuntu
/shmubuntu/x86_64-pc-linux-gnu/libjava/
-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava
-fomit-frame-pointer -Usun -g -v -O2  -o jv-convert
--main=gnu.gcj.convert
.Convert -rpath /usr/local/lib/../lib64 -shared-libgcc
-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/.libs
libgcj.la
libtool: link: /home/ihateubuntu/shmubuntu/gcc/gcj
-B/home/ihateubuntu/shmubuntu/gcc/
-B/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/
-fomit-frame-pointer -Usun -g -v -O2 -o .libs/jv-convert
--main=gnu.gcj.convert.Convert -shared-libgcc
-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/.libs
-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava
./.libs/libgcj.so -lpthread -lrt -lgc -Wl,-rpath
-Wl,/usr/local/lib/../lib64
Reading specs from /home/ihateubuntu/shmubuntu/gcc/specs
Reading specs from
/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=/home/ihateubuntu/shmubuntu/gcc/gcj
COLLECT_LTO_WRAPPER=/home/ihateubuntu/shmubuntu/gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcj-branches/configure --disable-bootstrap
--disable-multilib --disable-libstdcxx --disable-libquadmath
--disable-libgomp --disable-libgfortran --enable-languages=java
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200526 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B' '/home/ihateubuntu/shmubuntu/gcc/' '-B'
'/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/'
'-fomit-frame-pointer' '-U' 'sun' '-g' '-v' '-O2' '-o'
'.libs/jv-convert' '-shared-libgcc'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/.libs'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava'
'-fbootclasspath=./:/usr/local/share/java/libgcj-11.0.0.jar'
'-specs=/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/libgcj.spec'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/ihateubuntu/shmubuntu/gcc/jvgenmain gnu.gcj.convert.Convertmain
/tmp/ccSJFsbJ.i
COLLECT_GCC_OPTIONS='-B' '/home/ihateubuntu/shmubuntu/gcc/' '-B'
'/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/'
'-fomit-frame-pointer' '-U' 'sun' '-g' '-v' '-O2' '-o'
'.libs/jv-convert' '-shared-libgcc'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/.libs'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava'
'-specs=/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/libgcj.spec'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/ihateubuntu/shmubuntu/gcc/cc1 /tmp/ccSJFsbJ.i -quiet -dumpbase
gnu.gcj.convert.Convertmain.c -mtune=generic -march=x86-64 -g -O2
-imultiarch x86_64-linux-gnu -iprefix
/home/ihateubuntu/shmubuntu/gcc/../lib/gcc/x86_64-pc-linux-gnu/11.0.0/
-isystem /home/ihateubuntu/shmubuntu/gcc/include -isystem
/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/include
-isystem /home/ihateubuntu/shmubuntu/gcc/include-fixed -version
-fomit-frame-pointer -fdollars-in-identifiers -o /tmp/ccE1sfwm.s
GNU C17 (GCC) version 11.0.0 20200526 (experimental) (x86_64-pc-linux-gnu)
        compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 11.0.0 20200526 (experimental) (x86_64-pc-linux-gnu)
        compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 60735a0af2909bb2b29ae4dbf7f62f9c
COLLECT_GCC_OPTIONS='-B' '/home/ihateubuntu/shmubuntu/gcc/' '-B'
'/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/'
'-fomit-frame-pointer' '-U' 'sun' '-g' '-v' '-O2' '-o'
'.libs/jv-convert' '-shared-libgcc'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/.libs'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava'
'-specs=/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/libgcj.spec'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/ihateubuntu/shmubuntu/gcc/as -v --64 -o /tmp/cc0GThTZ.o /tmp/ccE1sfwm.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.30
COMPILER_PATH=/home/ihateubuntu/shmubuntu/gcc/:/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/
LIBRARY_PATH=/home/ihateubuntu/shmubuntu/gcc/:/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B' '/home/ihateubuntu/shmubuntu/gcc/' '-B'
'/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/'
'-fomit-frame-pointer' '-U' 'sun' '-g' '-v' '-O2' '-o'
'.libs/jv-convert' '-shared-libgcc'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/.libs'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava'
'-specs=/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/libgcj.spec'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' //no spurious
dumpdir option
 /home/ihateubuntu/shmubuntu/gcc/collect2 -plugin
/home/ihateubuntu/shmubuntu/gcc/liblto_plugin.so
-plugin-opt=/home/ihateubuntu/shmubuntu/gcc/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccvquphD.res
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcj -plugin-opt=-pass-through=-lm
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lrt
-plugin-opt=-pass-through=-ldl -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o .libs/jv-convert
/usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/home/ihateubuntu/shmubuntu/gcc/crtbegin.o
-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/.libs
-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava
-L/home/ihateubuntu/shmubuntu/gcc
-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
/tmp/cc0GThTZ.o ./.libs/libgcj.so -lpthread -lrt -lgc -rpath
/usr/local/lib/../lib64 -lgcc_s -lgcc -lgcj -lm -lpthread -lrt -ldl
-lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/ihateubuntu/shmubuntu/gcc/crtend.o
/usr/lib/x86_64-linux-gnu/crtn.o
COLLECT_GCC_OPTIONS='-B' '/home/ihateubuntu/shmubuntu/gcc/' '-B'
'/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/'
'-fomit-frame-pointer' '-U' 'sun' '-g' '-v' '-O2' '-o'
'.libs/jv-convert' '-shared-libgcc'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/.libs'
'-L/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava'
'-specs=/home/ihateubuntu/shmubuntu/x86_64-pc-linux-gnu/libjava/libgcj.spec'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'