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 reaso
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 th
> * 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
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 m
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
> > messag
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. ;-)
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.
> 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 the
> 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.
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
Patch 19 has been resolved.
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 i
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 reaso
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 coupl
14 matches
Mail list logo
