[PATCH 16/56] gcc: Re-add TYPE_METHODS.

[PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Zopolis0]

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: 0016-gcc-Re-add-TYPE_METHODS.patch --]
[-- Type: application/x-patch, Size: 841 bytes --]

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Richard Biener]

On Fri, Nov 25, 2022 at 9:55 AM Zopolis0 via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>

Why add this when nothing uses it and you need to re-add binfo because
of this?  If the frontend uses
it then add it to lang_type.

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Zopolis0]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

Because the frontend uses TYPE_BINFO specifically. It expects a TYPE_BINFO
that writes to this value, and will break with replacements. I have tried a
number of alternatives, and this is what works.

I can't use lang_1 because other frontends use it in ways that java doesn't
expect and I can't create a replacement for TYPE_BINFO because then it
won't have the regular checks that TYPE_BINFO has.

I couldn't find a better solution because I'm not particularly versed with
the internal workings of gcc, if you can think of a better idea feel free
to let me know.

On Sat, 26 Nov 2022 at 07:20, Richard Biener <richard.guenther@gmail.com>
wrote:

> On Fri, Nov 25, 2022 at 9:55 AM Zopolis0 via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
>
> Why add this when nothing uses it and you need to re-add binfo because
> of this?  If the frontend uses
> it then add it to lang_type.
>

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Zopolis0]

Oh wait wrong patch. You talking about binfo confused me.

Anyways, I re-added this because replacing Java's usage of
TYPE_METHODS with TYPE_FIELDS even when I properly checked for
different types of functions still broke things, so I added this as a
stopgap.

No idea what you are talking about with binfo though, I added binfo
for the reasons you can see in the email above, nothing to do with
TYPE_METHODS.

On Sat, Nov 26, 2022 at 11:16 AM Zopolis0 <creatorsmithmdt@gmail.com> wrote:
>
> Because the frontend uses TYPE_BINFO specifically. It expects a TYPE_BINFO that writes to this value, and will break with replacements. I have tried a number of alternatives, and this is what works.
>
> I can't use lang_1 because other frontends use it in ways that java doesn't expect and I can't create a replacement for TYPE_BINFO because then it won't have the regular checks that TYPE_BINFO has.
>
> I couldn't find a better solution because I'm not particularly versed with the internal workings of gcc, if you can think of a better idea feel free to let me know.
>
> On Sat, 26 Nov 2022 at 07:20, Richard Biener <richard.guenther@gmail.com> wrote:
>>
>> On Fri, Nov 25, 2022 at 9:55 AM Zopolis0 via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>> >
>>
>> Why add this when nothing uses it and you need to re-add binfo because
>> of this?  If the frontend uses
>> it then add it to lang_type.

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Richard Biener]

> Am 26.11.2022 um 02:55 schrieb Zopolis0 <creatorsmithmdt@gmail.com>:
> 
> Oh wait wrong patch. You talking about binfo confused me.
> 
> Anyways, I re-added this because replacing Java's usage of
> TYPE_METHODS with TYPE_FIELDS even when I properly checked for
> different types of functions still broke things, so I added this as a
> stopgap.
> 
> No idea what you are talking about with binfo though, I added binfo
> for the reasons you can see in the email above, nothing to do with
> TYPE_METHODS.

TYPE_METHODS uses the field used by TYPE_BINFO so the patches are related.
I fear you have to understand what the java
Frontend does to fix your problem, I certainly don’t know what it does wrong here.  Re-adding a field to all types is a no-go

Richard 

> 
>> On Sat, Nov 26, 2022 at 11:16 AM Zopolis0 <creatorsmithmdt@gmail.com> wrote:
>> 
>> Because the frontend uses TYPE_BINFO specifically. It expects a TYPE_BINFO that writes to this value, and will break with replacements. I have tried a number of alternatives, and this is what works.
>> 
>> I can't use lang_1 because other frontends use it in ways that java doesn't expect and I can't create a replacement for TYPE_BINFO because then it won't have the regular checks that TYPE_BINFO has.
>> 
>> I couldn't find a better solution because I'm not particularly versed with the internal workings of gcc, if you can think of a better idea feel free to let me know.
>> 
>>> On Sat, 26 Nov 2022 at 07:20, Richard Biener <richard.guenther@gmail.com> wrote:
>>> 
>>> On Fri, Nov 25, 2022 at 9:55 AM Zopolis0 via Gcc-patches
>>> <gcc-patches@gcc.gnu.org> wrote:
>>>> 
>>> 
>>> Why add this when nothing uses it and you need to re-add binfo because
>>> of this?  If the frontend uses
>>> it then add it to lang_type.

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Zopolis0]

> TYPE_METHODS uses the field used by TYPE_BINFO so the patches are related.

As the person who wrote the patches, I can confirm that they are not
in fact related. Or, at least, they fix different issues and have no
reliance upon each other. If you mean related as in they both contain
RECORD_OR_UNION_CHECK, sure, but even then they are two very different
patches, with one being a temporary stopgap and the other being a
thought-through change that solves a large issue with minimal addition
and leaves existing functionality intact.

> Re-adding a field to all types is a no-go

To be entirely honest, my current priority is simply to get this
merged so I can spend less time keeping up with upstream changes
breaking everything and spend more time actually improving things. The
additional labour cost for the maintainer who is making the change and
understands it deeply is much less than what it takes for me to bisect
the issue, find the commit, understand it and fix the issue.

From my point of view, temporarily re-adding a grand total of two
lines is worth that goal.
If you consider this a large enough issue that you won't accept that,
then let me know so we don't dance around the issue and I can get on
with solving the issue.

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Xi Ruoyao]

On Sat, 2022-11-26 at 18:30 +1100, Zopolis0 via Gcc-patches wrote:
> > Re-adding a field to all types is a no-go
> 
> To be entirely honest, my current priority is simply to get this
> merged so I can spend less time keeping up with upstream changes
> breaking everything and spend more time actually improving things. The
> additional labour cost for the maintainer who is making the change and
> understands it deeply is much less than what it takes for me to bisect
> the issue, find the commit, understand it and fix the issue.

No.  Java was removed to reduce the maintenance burden, you can't just
reintroduce the burden and say "hey, I don't want to pay for the burden
so you please do it".

And we are in stage 3 now so it's not possible to merge 50+ patches
(completely not reviewed in stage 1) until GCC 14 stage 1 opens.

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

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Zopolis0]

> No.  Java was removed to reduce the maintenance burden, you can't just
> reintroduce the burden and say "hey, I don't want to pay for the burden
> so you please do it".

There were two sentences there. You appear to only have read the first one.

I just took on 6 years of that maintenance burden in 4 months while
teaching myself the gcc tree.
I can confirm with absolute certainty that the burden would have been
pitiful had java been in the tree. Many of the changes were just
idiomatic find and replaces that I had to do myself, tracking down the
commit that removed or renamed something, in some cases just silently
breaking things so I had to bisect 6 years of changes. If Java had
been in the tree, it would have introduced a pitiful additional
burden. I can think of around 5 changes that I made that would have
required something more than just a sed script, and even then those
were very simple changes.

I am not suggesting that I wish to shift the overall burden of
maintenance away from myself, rather that it would be nice if I did
not have to track down breaking commits every 3 months, when the
author could have very easily included Java in the changes if it was
in the tree.

> And we are in stage 3 now so it's not possible to merge 50+ patches
> (completely not reviewed in stage 1) until GCC 14 stage 1 opens.

On a lighter note, this is fair. I was hoping to make the stage 1
window, but with 2 front-ends already in contention I thought my odds
of making it in regardless were poor, and I just didn't have the time
to fix the last issues.

I've sent these patches now so they can get reviewed now, so that they
aren't waiting in review limbo when merging is open again.