gcc-2.95.3: Internal compiler error in `instantiate_virtual_regs_1', at function.c:3885

[jens-maus]

Why trying to compile the latest amisslv4 sources (https://github.com/jens-maus/amissl/tree/master) using yours (and other existing) gcc-2.95.3 based cross compilers I run into the following issue:

[...]
m68k-amigaos-gcc -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSLDIR="\"AmiSSL:\"" -DENGINESDIR="\"AmiSSL:engines\"" -m68020-60 -msoft-float -DNO_INLINE_VARARGS -D__NO_NET_API -DB_ENDIAN -DOPENSSL_SYS_AMIGA -D__amigaos3__ -DOPENSSL_NO_STDIO -I../../include -I../../include/netinclude -W -Wall -O0 -g -gstabs -DBN_DEBUG -DCONF_DEBUG -DDEBUG  -resident32 -DAMISSL_COMPILE -I../../libcmt/include  -Iinclude -I../../openssl -I../../openssl/crypto/include -I../../openssl/include -Icrypto/include -c -o crypto/bn/bn_nist.o ../../openssl/crypto/bn/bn_nist.c
../../openssl/crypto/bn/bn_nist.c: In function `BN_nist_mod_192':
../../openssl/crypto/bn/bn_nist.c:491: Internal compiler error in `instantiate_virtual_regs_1', at function.c:3885
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

Compiling with anything higher than -O0 (e.g. -O1) already worksaround this problem.

After investigation I found the following gcc bugzilla entry reporting on a similar issue with GCC 2.95.3 and m68k builds:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8343

This resource suggests the following patch to be applied:

--- gcc-2.95.3/gcc/config/m68k/m68k.md
+++ gcc-2.95.3/gcc/config/m68k/m68k.md
@@ -3062,7 +3062,7 @@
   [(parallel
     [(set (subreg:SI (match_operand:DI 0 "register_operand" "") 1)
    (mult:SI (match_operand:SI 1 "register_operand" "")
-      (match_operand:SI 2 "nonimmediate_operand" "")))
+      (match_operand:SI 2 "register_operand" "")))
      (set (subreg:SI (match_dup 0) 0)
    (truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (match_dup 1))
               (zero_extend:DI (match_dup 2)))
@@ -3101,7 +3101,7 @@
   [(parallel
     [(set (subreg:SI (match_operand:DI 0 "register_operand" "") 1)
    (mult:SI (match_operand:SI 1 "register_operand" "")
-      (match_operand:SI 2 "nonimmediate_operand" "")))
+      (match_operand:SI 2 "register_operand" "")))
      (set (subreg:SI (match_dup 0) 0)
    (truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (match_dup 1))
               (sign_extend:DI (match_dup 2)))

After having added that match to the patches/gcc-2.95.3/gcc/config/m68k/m68k.md.diff file in your repository the problem still exists and prevents from building a nice debug build of the latest AmiSSL developer build.

I might be missing something here as I can't see that the gcc binary actually changed at all with the patch applied?!? Any help appreciated.

[cahirwpz]

From the patch set I cannot really tell which instructions are affected. I suppose it is int32 * int32 -> int64. I'll investigate machine description file and try to apply the patch.

[cahirwpz]

Hmm... could you explain in details how AmiSSL can be compiled with bare amigaos-cross-toolchain? Do I need some specific setup?

EDIT: I see... clib2 is required I presume?

[jens-maus]

A bit. All you need in principle is a Linux-based cross compiler setup with m68k-amigaos-gcc in your PATH. Then checkout the git repo and do:

make OS=os3

However, you will require clib2 for OS3/m68k manually setup with your cross-toolchain. That's a little bit harder to achieve and that's why I have added ticket #32 to directly add the possibility to your toolchain to add cllib2 support. Another thing that is required to have a fixed baserel support is binutils-2.14 for which we still have proper patches in the adtools project. But to trigger the compiler error mentioned here binutils-2.14 isn't required.

Please note also that I have added workarounds for the problem reported here. Now the default debug build is performed with -O1 rather than -O0 which shows the problem reported here. Also note that I have already tried to apply the patch I listed here already and it didn't make the bug go away. So there might be other effects causing it.

[cahirwpz]

Porting ashldi3, ashrdi3 and lshrdi3 from change 233603 helped to solve the problem.