Re: Java front-end and library patches v2
The astute among you may have noticed that I in fact sent no patches. This is for two reasons-- 1. Google did something behind the scenes and broke git send-email for me again 2. Thanks to Iain Sandoe, the build now completes, and he provided a couple other fixes as well. There are still a couple issues post-build, though, and it makes more sense to work through those before posting a v2.
Java front-end and library patches v2
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. Answers to the questions asked on my last patch series leading email: > 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. > 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.
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 ver
Re: Java front-end and library patches.
Patch 19 has been resolved.
Re: Java front-end and library patches.
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.
> 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.
> 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 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.
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.
Hi! On 2022-11-30T23:18:06+1100, Zopolis0 via Gcc-patches 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.
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 jos...@codesourcery.com
Re: Java front-end and library patches.
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 School of Aerospace Science and Technology, Xidian University
Re: Java front-end and library patches.
> * 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.
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 jos...@codesourcery.com
Java front-end and library patches.
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.
