[PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0]

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



[-- Attachment #2: 0019-Revert-Move-void_list_node-init-to-common-code.patch --]
[-- Type: application/x-patch, Size: 7578 bytes --]

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Richard Biener]

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

Why?!

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0]

Because if I don't, all java files break:

/bin/bash ./libtool  --tag=GCJ   --mode=compile
/home/zopolis4/trustme/./gcc/gcj
-B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
-B/home/zopolis4/trustme/./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 -fclasspath=
-fbootclasspath=/home/zopolis4/trustme/../gcj/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o
java/lang/Object.lo
-fsource-filename=/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java
/home/zopolis4/trustme/../gcj/libjava/classpath/lib/java/lang/Object.class
libtool: compile:  /home/zopolis4/trustme/./gcc/gcj
-B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
-B/home/zopolis4/trustme/./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
-fclasspath= -fbootclasspath=/home/zopolis4/trustme/../gcj/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java
/home/zopolis4/trustme/../gcj/libjava/classpath/lib/java/lang/Object.class
 -fPIC -o java/lang/.libs/Object.o
/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java: In class
'java.lang.Object':
/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java: In method
'java.lang.Object.finalize(void)':
In file included from <built-in>:63:
/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java:119:
internal compiler error: in start_java_method, at java/decl.cc:1779
  119 |   }
      |
0x662bca start_java_method(tree_node*)
        /home/zopolis4/trustme/../gcj/gcc/java/decl.cc:1779
0x862829 parse_class_file
        /home/zopolis4/trustme/../gcj/gcc/java/jcf-parse.cc:1634
0x8630ed java_parse_file()
        /home/zopolis4/trustme/../gcj/gcc/java/jcf-parse.cc:1970
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[3]: *** [Makefile:10643: java/lang/Object.lo] Error 1
make[3]: Leaving directory '/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava'
make[2]: *** [Makefile:10265: all-recursive] Error 1
make[2]: Leaving directory '/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava'
make[1]: *** [Makefile:15471: all-target-libjava] Error 2
make[1]: Leaving directory '/home/zopolis4/trustme'
make: *** [Makefile:1016: all] Error 2

I asked about this in
https://gcc.gnu.org/pipermail/gcc-help/2022-November/141981.html, but
got no response, so I reverted the commit.

On Sat, Nov 26, 2022 at 7:17 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Fri, Nov 25, 2022 at 9:46 AM Zopolis0 via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
> >
>
> Why?!

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Richard Biener]

> Am 26.11.2022 um 02:40 schrieb Zopolis0 <creatorsmithmdt@gmail.com>:
> 
> Because if I don't, all java files break:
> 
> /bin/bash ./libtool  --tag=GCJ   --mode=compile
> /home/zopolis4/trustme/./gcc/gcj
> -B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
> -B/home/zopolis4/trustme/./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 -fclasspath=
> -fbootclasspath=/home/zopolis4/trustme/../gcj/libjava/classpath/lib
> --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o
> java/lang/Object.lo
> -fsource-filename=/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java
> /home/zopolis4/trustme/../gcj/libjava/classpath/lib/java/lang/Object.class
> libtool: compile:  /home/zopolis4/trustme/./gcc/gcj
> -B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
> -B/home/zopolis4/trustme/./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
> -fclasspath= -fbootclasspath=/home/zopolis4/trustme/../gcj/libjava/classpath/lib
> --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c
> -fsource-filename=/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java
> /home/zopolis4/trustme/../gcj/libjava/classpath/lib/java/lang/Object.class
> -fPIC -o java/lang/.libs/Object.o
> /home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java: In class
> 'java.lang.Object':
> /home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java: In method
> 'java.lang.Object.finalize(void)':
> In file included from <built-in>:63:
> /home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java:119:
> internal compiler error: in start_java_method, at java/decl.cc:1779
>  119 |   }
>      |
> 0x662bca start_java_method(tree_node*)
>        /home/zopolis4/trustme/../gcj/gcc/java/decl.cc:1779
> 0x862829 parse_class_file
>        /home/zopolis4/trustme/../gcj/gcc/java/jcf-parse.cc:1634
> 0x8630ed java_parse_file()
>        /home/zopolis4/trustme/../gcj/gcc/java/jcf-parse.cc:1970
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.
> make[3]: *** [Makefile:10643: java/lang/Object.lo] Error 1
> make[3]: Leaving directory '/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava'
> make[2]: *** [Makefile:10265: all-recursive] Error 1
> make[2]: Leaving directory '/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava'
> make[1]: *** [Makefile:15471: all-target-libjava] Error 2
> make[1]: Leaving directory '/home/zopolis4/trustme'
> make: *** [Makefile:1016: all] Error 2

Please debug the above and see why it ICEs.  How does the Java FE initialize void_list_node?

> I asked about this in
> https://gcc.gnu.org/pipermail/gcc-help/2022-November/141981.html, but
> got no response, so I reverted the commit.
> 
>> On Sat, Nov 26, 2022 at 7:17 AM Richard Biener
>> <richard.guenther@gmail.com> wrote:
>> 
>>> On Fri, Nov 25, 2022 at 9:46 AM Zopolis0 via Gcc-patches
>>> <gcc-patches@gcc.gnu.org> wrote:
>>> 
>> 
>> Why?!

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0]

> How does the Java FE initialize void_list_node?
https://github.com/Zopolis4/gcj/blob/master/gcc/java/builtins.cc#L503
```
void_list_node = end_params_node;
```

end_params_node is defined a couple times around the Java frontend,
not sure which definition it is using.

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Andrew Pinski]

On Fri, Nov 25, 2022 at 11:37 PM Zopolis0 via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> > How does the Java FE initialize void_list_node?
> https://github.com/Zopolis4/gcj/blob/master/gcc/java/builtins.cc#L503
> ```
> void_list_node = end_params_node;
> ```
>
> end_params_node is defined a couple times around the Java frontend,
> not sure which definition it is using.

What happens if you remove end_params_node from the Java front-end and
replace it with void_list_node?

Thanks,
Andrew

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0]

> What happens if you remove end_params_node from the Java front-end and
> replace it with void_list_node?

Sadly, nothing.

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Richard Biener]

On Sat, Nov 26, 2022 at 9:41 AM Zopolis0 <creatorsmithmdt@gmail.com> wrote:
>
> > What happens if you remove end_params_node from the Java front-end and
> > replace it with void_list_node?
>
> Sadly, nothing.

But that looks like the correct thing to do.

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0]

> But that looks like the correct thing to do.

It's not. The patch I reverted changes it so that no matter what,
void_list_node = build_tree_list (NULL_TREE, void_type_node);.

Before, each front-end set it in their own way, but they all set it
via void_list_node = build_tree_list (NULL_TREE, void_type_node); or a
synonym anyway. So while the patch made sense in a java-free context,
given that java sets it a different way, I can't see a world in which
this commit stays active and Java works, unless we find a way to set
it in tree.cc for every language except Java.

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Richard Biener]

On Fri, Dec 2, 2022 at 1:23 AM Zopolis0 <creatorsmithmdt@gmail.com> wrote:
>
> > But that looks like the correct thing to do.
>
> It's not. The patch I reverted changes it so that no matter what,
> void_list_node = build_tree_list (NULL_TREE, void_type_node);.
>
> Before, each front-end set it in their own way, but they all set it
> via void_list_node = build_tree_list (NULL_TREE, void_type_node); or a
> synonym anyway. So while the patch made sense in a java-free context,
> given that java sets it a different way, I can't see a world in which
> this commit stays active and Java works, unless we find a way to set
> it in tree.cc for every language except Java.

The middle-end expects it to be this way, it's not correct for a frontend
to define it in other ways.  That means you need to try to understand
_why_ the frontend isn't happy with the middle-ends definition.

How does Java build end_params_node?

Richard.

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Richard Biener]

On Fri, Dec 2, 2022 at 8:43 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Fri, Dec 2, 2022 at 1:23 AM Zopolis0 <creatorsmithmdt@gmail.com> wrote:
> >
> > > But that looks like the correct thing to do.
> >
> > It's not. The patch I reverted changes it so that no matter what,
> > void_list_node = build_tree_list (NULL_TREE, void_type_node);.
> >
> > Before, each front-end set it in their own way, but they all set it
> > via void_list_node = build_tree_list (NULL_TREE, void_type_node); or a
> > synonym anyway. So while the patch made sense in a java-free context,
> > given that java sets it a different way, I can't see a world in which
> > this commit stays active and Java works, unless we find a way to set
> > it in tree.cc for every language except Java.
>
> The middle-end expects it to be this way, it's not correct for a frontend
> to define it in other ways.  That means you need to try to understand
> _why_ the frontend isn't happy with the middle-ends definition.
>
> How does Java build end_params_node?

Looking at the 4.7 tree it does

decl.c:  end_params_node = tree_cons (NULL_TREE, void_type_node, NULL_TREE);

that's exactly the same.

> Richard.

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0]

Ok, well following that logic it should work to just remove the
void_list_node definition that java uses, as per 8ff2a92. However, it
doesn't, so clearly java does something else to the end_params_node
definition that it shouldn't be, or something similar. I'll have a
look.

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0]

I had a look-- issue fixed, rough patch below. Full patch will be part of v2.

From b0d93d8212328fabcbdb32c266c265a4eed49e00 Mon Sep 17 00:00:00 2001
From: Maximilian Downey Twiss <creatorsmithmdt@gmail.com>
Date: Thu, 15 Dec 2022 09:54:36 +1100
Subject: [PATCH] java: Adjustments to end_params_node and void_list_node.

gcc/java/ChangeLog:

* builtins.cc (initialize_builtins): Do not set void_list_node to
end_params_node.
* decl.cc (java_init_decl_processing): Set end_params_node to void_list_node.
---
 gcc/java/builtins.cc | 2 --
 gcc/java/decl.cc     | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/gcc/java/builtins.cc b/gcc/java/builtins.cc
index 45d736a0d7b8..a882a5c4d521 100644
--- a/gcc/java/builtins.cc
+++ b/gcc/java/builtins.cc
@@ -499,8 +499,6 @@ initialize_builtins (void)
       java_builtins[i].method_name.t = m;
     }

-  void_list_node = end_params_node;
-
   float_ftype_float_float
     = build_function_type_list (float_type_node,
  float_type_node, float_type_node, NULL_TREE);
diff --git a/gcc/java/decl.cc b/gcc/java/decl.cc
index 6319d1ce18a0..018003104ced 100644
--- a/gcc/java/decl.cc
+++ b/gcc/java/decl.cc
@@ -957,7 +957,7 @@ java_init_decl_processing (void)
   build_decl (BUILTINS_LOCATION,
       TYPE_DECL, get_identifier ("Method"), method_type_node);

-  end_params_node = tree_cons (NULL_TREE, void_type_node, NULL_TREE);
+  end_params_node = void_list_node;

   t = build_function_type_list (ptr_type_node, class_ptr_type, NULL_TREE);
   alloc_object_node = add_builtin_function ("_Jv_AllocObject", t,