> Am 26.11.2022 um 02:55 schrieb Zopolis0 <creatorsmith...@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 <creatorsmith...@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.guent...@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.

Reply via email to