public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Segfault in libjava/prims.cc while compiling gcj
@ 2022-05-18  9:23 Zopolis0
  2022-05-18  9:59 ` Xi Ruoyao
  2022-05-19 10:47 ` Florian Weimer
  0 siblings, 2 replies; 17+ messages in thread
From: Zopolis0 @ 2022-05-18  9:23 UTC (permalink / raw)
  To: gcc-help

While compiling gcj on my msterrebase branch (
https://github.com/Zopolis4/gcj/tree/msterrebase), the compilation fails on
a segfault in prims.cc:
make[5]: Entering directory
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libjava'
depbase=`echo prims.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/bash ./libtool  --tag=CXX   --mode=compile
/home/zopolis4/gcjbuild/./gcc/xgcc -shared-libgcc
-B/home/zopolis4/gcjbuild/./gcc -nostdinc++
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-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 -fno-checking  -m32
-DHAVE_CONFIG_H -I. -I../../../../gcj/libjava -I./include -I./gcj
 -I../../../../gcj/libjava -Iinclude -I../../../../gcj/libjava/include
-I../../../../gcj/libjava/classpath/include -Iclasspath/include
-I../../../../gcj/libjava/classpath/native/fdlibm
-I../../../../gcj/libjava/../boehm-gc/include -I../boehm-gc/include
 -I../../../../gcj/libjava/libltdl
-I../../../../gcj/libjava/.././libjava/../libgcc
-I../../../../gcj/libjava/../zlib
-I../../../../gcj/libjava/../libffi/include -I../libffi/include  -fno-rtti
-fnon-call-exceptions  -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra
-Wall -D_GNU_SOURCE -DPREFIX="\"/usr/local\""
-DTOOLEXECLIBDIR="\"/usr/local/lib/../lib32\"" -DJAVA_HOME="\"/usr/local\""
-DBOOT_CLASS_PATH="\"/usr/local/share/java/libgcj-13.0.0.jar\""
-DJAVA_EXT_DIRS="\"/usr/local/share/java/ext\""
-DGCJ_ENDORSED_DIRS="\"/usr/local/share/java/gcj-endorsed\""
-DGCJ_VERSIONED_LIBDIR="\"/usr/local/lib/../lib32/gcj-13.0.0-18\""
-DPATH_SEPARATOR="\":\"" -DECJ_JAR_FILE="\"\""
-DLIBGCJ_DEFAULT_DATABASE="\"/usr/local/lib/../lib32/gcj-13.0.0-18/classmap.db\""
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"gcj-13.0.0-18/classmap.db\""
-fno-omit-frame-pointer -g -O2 -D_GNU_SOURCE  -m32 -MT prims.lo -MD -MP -MF
$depbase.Tpo -c -o prims.lo ../../../../gcj/libjava/prims.cc &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  /home/zopolis4/gcjbuild/./gcc/xgcc -shared-libgcc
-B/home/zopolis4/gcjbuild/./gcc -nostdinc++
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-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 -fno-checking -m32
-DHAVE_CONFIG_H -I. -I../../../../gcj/libjava -I./include -I./gcj
-I../../../../gcj/libjava -Iinclude -I../../../../gcj/libjava/include
-I../../../../gcj/libjava/classpath/include -Iclasspath/include
-I../../../../gcj/libjava/classpath/native/fdlibm
-I../../../../gcj/libjava/../boehm-gc/include -I../boehm-gc/include
-I../../../../gcj/libjava/libltdl
-I../../../../gcj/libjava/.././libjava/../libgcc
-I../../../../gcj/libjava/../zlib
-I../../../../gcj/libjava/../libffi/include -I../libffi/include -fno-rtti
-fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra
-Wall -D_GNU_SOURCE -DPREFIX=\"/usr/local\"
-DTOOLEXECLIBDIR=\"/usr/local/lib/../lib32\" -DJAVA_HOME=\"/usr/local\"
-DBOOT_CLASS_PATH=\"/usr/local/share/java/libgcj-13.0.0.jar\"
-DJAVA_EXT_DIRS=\"/usr/local/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/usr/local/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/usr/local/lib/../lib32/gcj-13.0.0-18\"
-DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\"
-DLIBGCJ_DEFAULT_DATABASE=\"/usr/local/lib/../lib32/gcj-13.0.0-18/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-13.0.0-18/classmap.db\"
-fno-omit-frame-pointer -g -O2 -D_GNU_SOURCE -m32 -MT prims.lo -MD -MP -MF
.deps/prims.Tpo -c ../../../../gcj/libjava/prims.cc  -fPIC -DPIC -o
.libs/prims.o
../../../../gcj/libjava/prims.cc: In function ‘void _Jv_catch_segv(int,
siginfo_t*, void*)’:
../../../../gcj/libjava/prims.cc:182:23: internal compiler error:
Segmentation fault
  182 |     = new java::lang::NullPointerException;
      |                       ^~~~~~~~~~~~~~~~~~~~
0x11bd5af crash_signal
        ../../gcj/gcc/toplev.cc:322
0x7f56707c8d5f ???
        ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xbda1b4 location_wrapper_p(tree_node const*)
        ../../gcj/gcc/tree.h:4210
0xbda1b4 tree_strip_any_location_wrapper(tree_node*)
        ../../gcj/gcc/tree.h:4222
0xbda1b4 is_overloaded_fn(tree_node*)
        ../../gcj/gcc/cp/tree.cc:2565
0xbda4d8 really_overloaded_fn(tree_node*)
        ../../gcj/gcc/cp/tree.cc:2607
0xa70eba build_new_1
        ../../gcj/gcc/cp/init.cc:3343
0xa73831 build_new(unsigned int, vec<tree_node*, va_gc, vl_embed>**,
tree_node*, tree_node*, vec<tree_node*, va_gc, vl_embed>**, int, int)
        ../../gcj/gcc/cp/init.cc:4068
0xb2d1b7 cp_parser_new_expression
        ../../gcj/gcc/cp/parser.cc:9307
0xb2d821 cp_parser_unary_expression
        ../../gcj/gcc/cp/parser.cc:8895
0xafbc36 cp_parser_binary_expression
        ../../gcj/gcc/cp/parser.cc:10043
0xafc7be cp_parser_assignment_expression
        ../../gcj/gcc/cp/parser.cc:10347
0xafeb61 cp_parser_constant_expression
        ../../gcj/gcc/cp/parser.cc:10650
0xafec61 cp_parser_initializer_clause
        ../../gcj/gcc/cp/parser.cc:25340
0xb0234c cp_parser_initializer
        ../../gcj/gcc/cp/parser.cc:25280
0xb325e3 cp_parser_init_declarator
        ../../gcj/gcc/cp/parser.cc:22844
0xb0c738 cp_parser_simple_declaration
        ../../gcj/gcc/cp/parser.cc:15315
0xb0e4d0 cp_parser_declaration_statement
        ../../gcj/gcc/cp/parser.cc:14394
0xb0ed49 cp_parser_statement
        ../../gcj/gcc/cp/parser.cc:12471
0xb0fc9d cp_parser_statement_seq_opt
        ../../gcj/gcc/cp/parser.cc:12883
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[5]: *** [Makefile:9945: prims.lo] Error 1
make[5]: Leaving directory
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libjava'
make[4]: *** [Makefile:10258: all-recursive] Error 1
make[4]: Leaving directory
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libjava'
make[3]: *** [Makefile:12792: multi-do] Error 1
make[3]: Leaving directory
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava'
make[2]: *** [Makefile:12758: all-multi] Error 2
make[2]: Leaving directory
'/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/libjava'
make[1]: *** [Makefile:23521: all-target-libjava] Error 2
make[1]: Leaving directory '/home/zopolis4/gcjbuild'
make: *** [Makefile:1085: all] Error 2

Is this an error within prims.cc? Or is it catching an error from somewhere
else? Should I report this as per the instructions? If so, how do I do that
when the arguments are already set?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18  9:23 Segfault in libjava/prims.cc while compiling gcj Zopolis0
@ 2022-05-18  9:59 ` Xi Ruoyao
  2022-05-18 10:38   ` Zopolis0
  2022-05-19 10:47 ` Florian Weimer
  1 sibling, 1 reply; 17+ messages in thread
From: Xi Ruoyao @ 2022-05-18  9:59 UTC (permalink / raw)
  To: Zopolis0, gcc-help

On Wed, 2022-05-18 at 19:23 +1000, Zopolis0 via Gcc-help wrote:

/* snip */

> ../../../../gcj/libjava/prims.cc:182:23: internal compiler error:
> Segmentation fault

/* snip */

> Is this an error within prims.cc?

No.  No matter prims.cc is erroneous or not, the compiler should not
crash.

> Or is it catching an error from somewhere else?

It indicates a bug in the compiler.

> Should I report this as per the instructions?

Maybe.  We don't know if you introduced the bug or the bug has been
already in GCC trunk.

Try to get a preprocessed file (by changing "-c" to "-E" in the command
line, and "-o prims.o" to "-o prims.ii").  Then compile prims.ii using
*unmodified and latest* g++ trunk with all flags (esp. -m32, -Ox, and -
f...) in the command line.  But "-D...", "-I...", and "-B..." shall be
removed.

If the segfault can be reproduced with unmodified g++ trunk with the
instruction above, try to remove some flags (for example, remove -m32,
change -O2 to -O1 or -O0, etc) and get a minimal set of flags to produce
the crash.  Then use cvise (https://github.com/marxin/cvise) to reduce
prims.ii into a test case and report via https://gcc.gnu.org/bugzilla
with the test case attached.

If the segfault can't be reproduced with latest g++ trunk and the
preprocessed file, you can try to rebase your changes onto the latest
trunk.  If the crash still happens for the rebased code, it indicates
you've done something wrong modifying GCC.  You can still use cvise to
get a minimal test case to reproduce the crash for you, and then use a
debugger (like gdb) to figure out what's going wrong.
-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18  9:59 ` Xi Ruoyao
@ 2022-05-18 10:38   ` Zopolis0
  2022-05-18 10:43     ` Jonathan Wakely
  0 siblings, 1 reply; 17+ messages in thread
From: Zopolis0 @ 2022-05-18 10:38 UTC (permalink / raw)
  To: Xi Ruoyao; +Cc: gcc-help

I'm unable to use the system g++ to compile it as removing any of the
includes breaks it, removing any of the -B arguments breaks it, but not
removing the -B arguments break it. Not exactly sure how to compile a
preprocessed file either. As it stands, I have been unable to reproduce the
error or change any of the flags, although I have been able to produce a
preprocessed file as per your instructions.

On Wed, May 18, 2022 at 7:59 PM Xi Ruoyao <xry111@xry111.site> wrote:

> On Wed, 2022-05-18 at 19:23 +1000, Zopolis0 via Gcc-help wrote:
>
> /* snip */
>
> > ../../../../gcj/libjava/prims.cc:182:23: internal compiler error:
> > Segmentation fault
>
> /* snip */
>
> > Is this an error within prims.cc?
>
> No.  No matter prims.cc is erroneous or not, the compiler should not
> crash.
>
> > Or is it catching an error from somewhere else?
>
> It indicates a bug in the compiler.
>
> > Should I report this as per the instructions?
>
> Maybe.  We don't know if you introduced the bug or the bug has been
> already in GCC trunk.
>
> Try to get a preprocessed file (by changing "-c" to "-E" in the command
> line, and "-o prims.o" to "-o prims.ii").  Then compile prims.ii using
> *unmodified and latest* g++ trunk with all flags (esp. -m32, -Ox, and -
> f...) in the command line.  But "-D...", "-I...", and "-B..." shall be
> removed.
>
> If the segfault can be reproduced with unmodified g++ trunk with the
> instruction above, try to remove some flags (for example, remove -m32,
> change -O2 to -O1 or -O0, etc) and get a minimal set of flags to produce
> the crash.  Then use cvise (https://github.com/marxin/cvise) to reduce
> prims.ii into a test case and report via https://gcc.gnu.org/bugzilla
> with the test case attached.
>
> If the segfault can't be reproduced with latest g++ trunk and the
> preprocessed file, you can try to rebase your changes onto the latest
> trunk.  If the crash still happens for the rebased code, it indicates
> you've done something wrong modifying GCC.  You can still use cvise to
> get a minimal test case to reproduce the crash for you, and then use a
> debugger (like gdb) to figure out what's going wrong.
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18 10:38   ` Zopolis0
@ 2022-05-18 10:43     ` Jonathan Wakely
  2022-05-18 10:45       ` Zopolis0
  0 siblings, 1 reply; 17+ messages in thread
From: Jonathan Wakely @ 2022-05-18 10:43 UTC (permalink / raw)
  To: Zopolis0; +Cc: Xi Ruoyao, gcc-help

On Wed, 18 May 2022 at 11:39, Zopolis0 via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> I'm unable to use the system g++ to compile it as removing any of the
> includes breaks it, removing any of the -B arguments breaks it, but not
> removing the -B arguments break it.

Don't remove them then, that's not what you were asked to do.

> Not exactly sure how to compile a
> preprocessed file either.

Rea the email you replied to, you use -E as described.

> As it stands, I have been unable to reproduce the
> error or change any of the flags, although I have been able to produce a
> preprocessed file as per your instructions.

Because you didn't follow the instructions.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18 10:43     ` Jonathan Wakely
@ 2022-05-18 10:45       ` Zopolis0
  2022-05-18 10:57         ` Jonathan Wakely
  0 siblings, 1 reply; 17+ messages in thread
From: Zopolis0 @ 2022-05-18 10:45 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: Xi Ruoyao, gcc-help

I thought "  But "-D...", "-I...", and "-B..." shall be
removed." was asking me to remove them.

I used -E, I said I produced the file.

The bit I'm confused about is "Then compile prims.ii using".

On Wed, May 18, 2022 at 8:43 PM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Wed, 18 May 2022 at 11:39, Zopolis0 via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > I'm unable to use the system g++ to compile it as removing any of the
> > includes breaks it, removing any of the -B arguments breaks it, but not
> > removing the -B arguments break it.
>
> Don't remove them then, that's not what you were asked to do.
>
> > Not exactly sure how to compile a
> > preprocessed file either.
>
> Rea the email you replied to, you use -E as described.
>
> > As it stands, I have been unable to reproduce the
> > error or change any of the flags, although I have been able to produce a
> > preprocessed file as per your instructions.
>
> Because you didn't follow the instructions.
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18 10:45       ` Zopolis0
@ 2022-05-18 10:57         ` Jonathan Wakely
  2022-05-18 11:01           ` Xi Ruoyao
  2022-05-18 11:16           ` Zopolis0
  0 siblings, 2 replies; 17+ messages in thread
From: Jonathan Wakely @ 2022-05-18 10:57 UTC (permalink / raw)
  To: Zopolis0; +Cc: Xi Ruoyao, gcc-help

On Wed, 18 May 2022 at 11:45, Zopolis0 wrote:
>
> I thought "  But "-D...", "-I...", and "-B..." shall be
> removed." was asking me to remove them.
>
> I used -E, I said I produced the file.

Ah I missed that, sorry. I thought you were still trying to produce a .ii file.

So then you should be able to compile the .ii file as described. A .ii
file needs no headers, so removing -I... options shouldn't matter, and
has already expanded macros, so removing -D... options shouldn't
matter. And the system g++ knows how to find its own sub-programs, so
the -B... options would just confuse it.

What command are you actually running to try and compile the .ii file?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18 10:57         ` Jonathan Wakely
@ 2022-05-18 11:01           ` Xi Ruoyao
  2022-05-18 23:20             ` Zopolis0
  2022-05-18 11:16           ` Zopolis0
  1 sibling, 1 reply; 17+ messages in thread
From: Xi Ruoyao @ 2022-05-18 11:01 UTC (permalink / raw)
  To: Jonathan Wakely, Zopolis0; +Cc: gcc-help

On Wed, 2022-05-18 at 11:57 +0100, Jonathan Wakely wrote:
> On Wed, 18 May 2022 at 11:45, Zopolis0 wrote:
> > 
> > I thought "  But "-D...", "-I...", and "-B..." shall be
> > removed." was asking me to remove them.
> > 
> > I used -E, I said I produced the file.
> 
> Ah I missed that, sorry. I thought you were still trying to produce a
> .ii file.

My mistake: I didn't expect that this .ii file contains "extern Java {
... }", not supported by GCC trunk.

So for the OP, the only option seems to reduce the .ii file into a test
case and debug the compiler.  I guess the OP has made some mistake
implementing "extern Java" for C++ FE.
-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18 10:57         ` Jonathan Wakely
  2022-05-18 11:01           ` Xi Ruoyao
@ 2022-05-18 11:16           ` Zopolis0
  1 sibling, 0 replies; 17+ messages in thread
From: Zopolis0 @ 2022-05-18 11:16 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: Xi Ruoyao, gcc-help

I'm running gcc -shared-libgcc -nostdinc++
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -fno-checking -m32 -fno-rtti
-fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -ffloat-store
-fomit-frame-pointer -Usun -Wextra -Wall -fno-omit-frame-pointer -g -O2
-m32 -MD -MP -fPIC -DPIC -c .libs/prims.ii to compile the .ii file, which I
created with /home/zopolis4/gcjbuild/./gcc/xgcc -shared-libgcc
-B/home/zopolis4/gcjbuild/./gcc -nostdinc++
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/home/zopolis4/gcjbuild/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-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 -fno-checking -m32
-DHAVE_CONFIG_H -I. -I../../../../gcj/libjava -I./include -I./gcj
-I../../../../gcj/libjava -Iinclude -I../../../../gcj/libjava/include
-I../../../../gcj/libjava/classpath/include -Iclasspath/include
-I../../../../gcj/libjava/classpath/native/fdlibm
-I../../../../gcj/libjava/../boehm-gc/include -I../boehm-gc/include
-I../../../../gcj/libjava/libltdl
-I../../../../gcj/libjava/.././libjava/../libgcc
-I../../../../gcj/libjava/../zlib
-I../../../../gcj/libjava/../libffi/include -I../libffi/include -fno-rtti
-fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra
-Wall -D_GNU_SOURCE -DPREFIX=\"/usr/local\"
-DTOOLEXECLIBDIR=\"/usr/local/lib/../lib32\" -DJAVA_HOME=\"/usr/local\"
-DBOOT_CLASS_PATH=\"/usr/local/share/java/libgcj-13.0.0.jar\"
-DJAVA_EXT_DIRS=\"/usr/local/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/usr/local/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/usr/local/lib/../lib32/gcj-13.0.0-18\"
-DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\"
-DLIBGCJ_DEFAULT_DATABASE=\"/usr/local/lib/../lib32/gcj-13.0.0-18/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-13.0.0-18/classmap.db\"
-fno-omit-frame-pointer -g -O2 -D_GNU_SOURCE -m32 -MT prims.lo -MD -MP -MF
.deps/prims.Tpo -E ../../../../gcj/libjava/prims.cc  -fPIC -DPIC -o
.libs/prims.ii

Attempting to compile that file breaks horribly, mainly on the lack of
declarations for jsize, jint, jboolean and so on.

On Wed, May 18, 2022 at 8:58 PM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:

> On Wed, 18 May 2022 at 11:45, Zopolis0 wrote:
> >
> > I thought "  But "-D...", "-I...", and "-B..." shall be
> > removed." was asking me to remove them.
> >
> > I used -E, I said I produced the file.
>
> Ah I missed that, sorry. I thought you were still trying to produce a .ii
> file.
>
> So then you should be able to compile the .ii file as described. A .ii
> file needs no headers, so removing -I... options shouldn't matter, and
> has already expanded macros, so removing -D... options shouldn't
> matter. And the system g++ knows how to find its own sub-programs, so
> the -B... options would just confuse it.
>
> What command are you actually running to try and compile the .ii file?
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18 11:01           ` Xi Ruoyao
@ 2022-05-18 23:20             ` Zopolis0
  2022-05-19  4:32               ` Zopolis0
  0 siblings, 1 reply; 17+ messages in thread
From: Zopolis0 @ 2022-05-18 23:20 UTC (permalink / raw)
  To: Xi Ruoyao; +Cc: Jonathan Wakely, gcc-help

I'm not sure what you mean by not supported by GCC trunk, the code is part
of the gcc trunk (not the upstream one, though). The code compiled in Sep
2016, so something must have changed between
37b204de605563e7932e26099d28ea8c86cb1935 and now.

On Wed, May 18, 2022 at 9:02 PM Xi Ruoyao <xry111@xry111.site> wrote:

> On Wed, 2022-05-18 at 11:57 +0100, Jonathan Wakely wrote:
> > On Wed, 18 May 2022 at 11:45, Zopolis0 wrote:
> > >
> > > I thought "  But "-D...", "-I...", and "-B..." shall be
> > > removed." was asking me to remove them.
> > >
> > > I used -E, I said I produced the file.
> >
> > Ah I missed that, sorry. I thought you were still trying to produce a
> > .ii file.
>
> My mistake: I didn't expect that this .ii file contains "extern Java {
> ... }", not supported by GCC trunk.
>
> So for the OP, the only option seems to reduce the .ii file into a test
> case and debug the compiler.  I guess the OP has made some mistake
> implementing "extern Java" for C++ FE.
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18 23:20             ` Zopolis0
@ 2022-05-19  4:32               ` Zopolis0
  2022-05-19  8:06                 ` Xi Ruoyao
  0 siblings, 1 reply; 17+ messages in thread
From: Zopolis0 @ 2022-05-19  4:32 UTC (permalink / raw)
  To: Xi Ruoyao; +Cc: Jonathan Wakely, gcc-help

Ah. On further inspection, I presume the reason prims.cc fails to compile
under any circumstances with the system gcc is because the system gcc has
no support for the standard java types, which are enabled if extern "Java"
is seen. The system gcc, having no such types, cannot act on the extern
Java and thus the compilation fails. I'm now looking into using a version
of gcc 6 configured with --enable-languages=java, or hacking my code to
disable the compilation of libjava, and then use that version. Should I
still report the ICE, even if the upstream gcc would fail before reaching
it?

On Thu, May 19, 2022 at 9:20 AM Zopolis0 <creatorsmithmdt@gmail.com> wrote:

> I'm not sure what you mean by not supported by GCC trunk, the code is part
> of the gcc trunk (not the upstream one, though). The code compiled in Sep
> 2016, so something must have changed between
> 37b204de605563e7932e26099d28ea8c86cb1935 and now.
>
> On Wed, May 18, 2022 at 9:02 PM Xi Ruoyao <xry111@xry111.site> wrote:
>
>> On Wed, 2022-05-18 at 11:57 +0100, Jonathan Wakely wrote:
>> > On Wed, 18 May 2022 at 11:45, Zopolis0 wrote:
>> > >
>> > > I thought "  But "-D...", "-I...", and "-B..." shall be
>> > > removed." was asking me to remove them.
>> > >
>> > > I used -E, I said I produced the file.
>> >
>> > Ah I missed that, sorry. I thought you were still trying to produce a
>> > .ii file.
>>
>> My mistake: I didn't expect that this .ii file contains "extern Java {
>> ... }", not supported by GCC trunk.
>>
>> So for the OP, the only option seems to reduce the .ii file into a test
>> case and debug the compiler.  I guess the OP has made some mistake
>> implementing "extern Java" for C++ FE.
>> --
>> Xi Ruoyao <xry111@xry111.site>
>> School of Aerospace Science and Technology, Xidian University
>>
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-19  4:32               ` Zopolis0
@ 2022-05-19  8:06                 ` Xi Ruoyao
  2022-05-20 10:50                   ` Zopolis0
  0 siblings, 1 reply; 17+ messages in thread
From: Xi Ruoyao @ 2022-05-19  8:06 UTC (permalink / raw)
  To: Zopolis0; +Cc: Jonathan Wakely, gcc-help

On Thu, 2022-05-19 at 14:32 +1000, Zopolis0 wrote:
> Ah. On further inspection, I presume the reason prims.cc fails to
> compile under any circumstances with the system gcc is because the
> system gcc has no support for the standard java types, which are
> enabled if extern "Java" is seen. The system gcc, having no such
> types, cannot act on the extern Java and thus the compilation fails.
> I'm now looking into using a version of gcc 6 configured with --
> enable-languages=java, or hacking my code to disable the compilation
> of libjava, and then use that version. Should I still report the ICE,
> even if the upstream gcc would fail before reaching it?

No, because the ICE can't be reproduced with upstream GCC so no upstream
developer will be able to debug it.

You are on yourself unless you can recruit someone :). 

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-18  9:23 Segfault in libjava/prims.cc while compiling gcj Zopolis0
  2022-05-18  9:59 ` Xi Ruoyao
@ 2022-05-19 10:47 ` Florian Weimer
  2022-05-19 12:22   ` Zopolis0
  1 sibling, 1 reply; 17+ messages in thread
From: Florian Weimer @ 2022-05-19 10:47 UTC (permalink / raw)
  To: Zopolis0 via Gcc-help; +Cc: Zopolis0

* Zopolis:

> ../../../../gcj/libjava/prims.cc:182:23: internal compiler error:
> Segmentation fault
>   182 |     = new java::lang::NullPointerException;
>       |                       ^~~~~~~~~~~~~~~~~~~~

This is likely a bug in the CNI implementation, specific to your GCJ
port.  Allocation of CNI classes is different from regular C++ classes.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-19 10:47 ` Florian Weimer
@ 2022-05-19 12:22   ` Zopolis0
  2022-05-21  7:12     ` Zopolis0
  0 siblings, 1 reply; 17+ messages in thread
From: Zopolis0 @ 2022-05-19 12:22 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Zopolis0 via Gcc-help

It's the same implementation from when it was removed, unless you mean code
outside of gcc/java and libjava, which in that case I could have made an
error copying it in or modernising it.

On Thu, May 19, 2022 at 8:47 PM Florian Weimer <fweimer@redhat.com> wrote:

> * Zopolis:
>
> > ../../../../gcj/libjava/prims.cc:182:23: internal compiler error:
> > Segmentation fault
> >   182 |     = new java::lang::NullPointerException;
> >       |                       ^~~~~~~~~~~~~~~~~~~~
>
> This is likely a bug in the CNI implementation, specific to your GCJ
> port.  Allocation of CNI classes is different from regular C++ classes.
>
> Thanks,
> Florian
>
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-19  8:06                 ` Xi Ruoyao
@ 2022-05-20 10:50                   ` Zopolis0
  0 siblings, 0 replies; 17+ messages in thread
From: Zopolis0 @ 2022-05-20 10:50 UTC (permalink / raw)
  To: Xi Ruoyao; +Cc: Jonathan Wakely, gcc-help

I have reproduced the issue with /usr/local/gccjava/usr/local/bin/gcc -m32
.libs/prims.ii, where I installed what compiled before failing with make
DESTDIR=/usr/local/gccjava. Using -freport-bug results in it saying The bug
is not reproducible, so it is likely a hardware or OS problem., which makes
me think that its not an actual ICE in the code itself, given that all the
ICE's just happen to be on areas of code for catching ICEs.

On Thu, May 19, 2022 at 6:06 PM Xi Ruoyao <xry111@xry111.site> wrote:

> On Thu, 2022-05-19 at 14:32 +1000, Zopolis0 wrote:
> > Ah. On further inspection, I presume the reason prims.cc fails to
> > compile under any circumstances with the system gcc is because the
> > system gcc has no support for the standard java types, which are
> > enabled if extern "Java" is seen. The system gcc, having no such
> > types, cannot act on the extern Java and thus the compilation fails.
> > I'm now looking into using a version of gcc 6 configured with --
> > enable-languages=java, or hacking my code to disable the compilation
> > of libjava, and then use that version. Should I still report the ICE,
> > even if the upstream gcc would fail before reaching it?
>
> No, because the ICE can't be reproduced with upstream GCC so no upstream
> developer will be able to debug it.
>
> You are on yourself unless you can recruit someone :).
>
> --
> Xi Ruoyao <xry111@xry111.site>
> School of Aerospace Science and Technology, Xidian University
>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-19 12:22   ` Zopolis0
@ 2022-05-21  7:12     ` Zopolis0
  2022-06-15  7:51       ` Zopolis0
  0 siblings, 1 reply; 17+ messages in thread
From: Zopolis0 @ 2022-05-21  7:12 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Zopolis0 via Gcc-help

Running with make -k reveals that all the errors are segfaults, and all of
them are on return new or throw new statements. One such error is on the
return new FileOutputStream (ch);  line in natVMChannels.cc:

FileOutputStream*
VMChannels::newOutputStream(FileChannelImpl* ch)
{
  // Needs to be native to bypass Java access protection.
  return new FileOutputStream (ch);
}

Given that this does not seem like the kind of code to generate a segfault,
I think there is a different issue here.


On Thu, May 19, 2022 at 10:22 PM Zopolis0 <creatorsmithmdt@gmail.com> wrote:

> It's the same implementation from when it was removed, unless you mean
> code outside of gcc/java and libjava, which in that case I could have made
> an error copying it in or modernising it.
>
> On Thu, May 19, 2022 at 8:47 PM Florian Weimer <fweimer@redhat.com> wrote:
>
>> * Zopolis:
>>
>> > ../../../../gcj/libjava/prims.cc:182:23: internal compiler error:
>> > Segmentation fault
>> >   182 |     = new java::lang::NullPointerException;
>> >       |                       ^~~~~~~~~~~~~~~~~~~~
>>
>> This is likely a bug in the CNI implementation, specific to your GCJ
>> port.  Allocation of CNI classes is different from regular C++ classes.
>>
>> Thanks,
>> Florian
>>
>>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-05-21  7:12     ` Zopolis0
@ 2022-06-15  7:51       ` Zopolis0
  2022-06-17  9:20         ` Zopolis0
  0 siblings, 1 reply; 17+ messages in thread
From: Zopolis0 @ 2022-06-15  7:51 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Zopolis0 via Gcc-help

Never mind, that was a coincidence. All of the errors are on lines calling
java:: something, or calling _Jv_ something.

On Sat, 21 May 2022 at 17:12, Zopolis0 <creatorsmithmdt@gmail.com> wrote:

> Running with make -k reveals that all the errors are segfaults, and all of
> them are on return new or throw new statements. One such error is on the
> return new FileOutputStream (ch);  line in natVMChannels.cc:
>
> FileOutputStream*
> VMChannels::newOutputStream(FileChannelImpl* ch)
> {
>   // Needs to be native to bypass Java access protection.
>   return new FileOutputStream (ch);
> }
>
> Given that this does not seem like the kind of code to generate a
> segfault, I think there is a different issue here.
>
>
> On Thu, May 19, 2022 at 10:22 PM Zopolis0 <creatorsmithmdt@gmail.com>
> wrote:
>
>> It's the same implementation from when it was removed, unless you mean
>> code outside of gcc/java and libjava, which in that case I could have made
>> an error copying it in or modernising it.
>>
>> On Thu, May 19, 2022 at 8:47 PM Florian Weimer <fweimer@redhat.com>
>> wrote:
>>
>>> * Zopolis:
>>>
>>> > ../../../../gcj/libjava/prims.cc:182:23: internal compiler error:
>>> > Segmentation fault
>>> >   182 |     = new java::lang::NullPointerException;
>>> >       |                       ^~~~~~~~~~~~~~~~~~~~
>>>
>>> This is likely a bug in the CNI implementation, specific to your GCJ
>>> port.  Allocation of CNI classes is different from regular C++ classes.
>>>
>>> Thanks,
>>> Florian
>>>
>>>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Segfault in libjava/prims.cc while compiling gcj
  2022-06-15  7:51       ` Zopolis0
@ 2022-06-17  9:20         ` Zopolis0
  0 siblings, 0 replies; 17+ messages in thread
From: Zopolis0 @ 2022-06-17  9:20 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Zopolis0 via Gcc-help

At my wit's end here, posted a bounty:
https://app.bountysource.com/issues/109355626-ice-s

On Wed, Jun 15, 2022 at 5:51 PM Zopolis0 <creatorsmithmdt@gmail.com> wrote:

> Never mind, that was a coincidence. All of the errors are on lines calling
> java:: something, or calling _Jv_ something.
>
> On Sat, 21 May 2022 at 17:12, Zopolis0 <creatorsmithmdt@gmail.com> wrote:
>
>> Running with make -k reveals that all the errors are segfaults, and all
>> of them are on return new or throw new statements. One such error is on
>> the  return new FileOutputStream (ch);  line in natVMChannels.cc:
>>
>> FileOutputStream*
>> VMChannels::newOutputStream(FileChannelImpl* ch)
>> {
>>   // Needs to be native to bypass Java access protection.
>>   return new FileOutputStream (ch);
>> }
>>
>> Given that this does not seem like the kind of code to generate a
>> segfault, I think there is a different issue here.
>>
>>
>> On Thu, May 19, 2022 at 10:22 PM Zopolis0 <creatorsmithmdt@gmail.com>
>> wrote:
>>
>>> It's the same implementation from when it was removed, unless you mean
>>> code outside of gcc/java and libjava, which in that case I could have made
>>> an error copying it in or modernising it.
>>>
>>> On Thu, May 19, 2022 at 8:47 PM Florian Weimer <fweimer@redhat.com>
>>> wrote:
>>>
>>>> * Zopolis:
>>>>
>>>> > ../../../../gcj/libjava/prims.cc:182:23: internal compiler error:
>>>> > Segmentation fault
>>>> >   182 |     = new java::lang::NullPointerException;
>>>> >       |                       ^~~~~~~~~~~~~~~~~~~~
>>>>
>>>> This is likely a bug in the CNI implementation, specific to your GCJ
>>>> port.  Allocation of CNI classes is different from regular C++ classes.
>>>>
>>>> Thanks,
>>>> Florian
>>>>
>>>>

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2022-06-17  9:20 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-18  9:23 Segfault in libjava/prims.cc while compiling gcj Zopolis0
2022-05-18  9:59 ` Xi Ruoyao
2022-05-18 10:38   ` Zopolis0
2022-05-18 10:43     ` Jonathan Wakely
2022-05-18 10:45       ` Zopolis0
2022-05-18 10:57         ` Jonathan Wakely
2022-05-18 11:01           ` Xi Ruoyao
2022-05-18 23:20             ` Zopolis0
2022-05-19  4:32               ` Zopolis0
2022-05-19  8:06                 ` Xi Ruoyao
2022-05-20 10:50                   ` Zopolis0
2022-05-18 11:16           ` Zopolis0
2022-05-19 10:47 ` Florian Weimer
2022-05-19 12:22   ` Zopolis0
2022-05-21  7:12     ` Zopolis0
2022-06-15  7:51       ` Zopolis0
2022-06-17  9:20         ` Zopolis0

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).