gcc v12 catastrophic internal compiler error, cc1 randomly fails

[DiTBho]

Code: [Select]

#ldd /usr/bin/wget
        linux-vdso.so.1 (0x7ffa7000)
        libpcre2-8.so.0 => /lib/libpcre2-8.so.0 (0x77c70000)
        libssl.so.3 => /usr/lib/libssl.so.3 (0x77bc0000)
        libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x77840000)
        libz.so.1 => /lib/libz.so.1 (0x77800000)
        libc.so.6 => /lib/libc.so.6 (0x77620000)
        libatomic.so.1 => /usr/lib/gcc/mipsel-unknown-linux-gnu/12/libatomic.so.1 (0x775f0000)
        /lib/ld.so.1 (0x77dc2000)

and some applications like net-misc/wget v1.21.3-r1 have dependencies with gcc-v12
          libatomic.so.1 => /usr/lib/gcc/mipsel-unknown-linux-gnu/12/libatomic.so.1

[Nominal Animal]

If you use a mipsel-linux-gnu-gcc to cross-compile the following to an object file (or library), using a much later GCC version, you get all needed functions:

Code: [Select]

char   sync_fetch_and_add_1  (char  *ptr, char  val) { return __sync_fetch_and_add  (ptr, val); }
char   sync_fetch_and_sub_1  (char  *ptr, char  val) { return __sync_fetch_and_sub  (ptr, val); }
char   sync_fetch_and_and_1  (char  *ptr, char  val) { return __sync_fetch_and_and  (ptr, val); }
char   sync_fetch_and_xor_1  (char  *ptr, char  val) { return __sync_fetch_and_xor  (ptr, val); }
char   sync_fetch_and_or_1   (char  *ptr, char  val) { return __sync_fetch_and_or   (ptr, val); }
char   sync_fetch_and_nand_1 (char  *ptr, char  val) { return __sync_fetch_and_nand (ptr, val); }

char   sync_add_and_fetch_1  (char  *ptr, char  val) { return __sync_add_and_fetch  (ptr, val); }
char   sync_sub_and_fetch_1  (char  *ptr, char  val) { return __sync_sub_and_fetch  (ptr, val); }
char   sync_and_and_fetch_1  (char  *ptr, char  val) { return __sync_and_and_fetch  (ptr, val); }
char   sync_xor_and_fetch_1  (char  *ptr, char  val) { return __sync_xor_and_fetch  (ptr, val); }
char   sync_or_and_fetch_1   (char  *ptr, char  val) { return __sync_or_and_fetch   (ptr, val); }
char   sync_nand_and_fetch_1 (char  *ptr, char  val) { return __sync_nand_and_fetch (ptr, val); }

short  sync_fetch_and_add_2  (short *ptr, short val) { return __sync_fetch_and_add  (ptr, val); }
short  sync_fetch_and_sub_2  (short *ptr, short val) { return __sync_fetch_and_sub  (ptr, val); }
short  sync_fetch_and_and_2  (short *ptr, short val) { return __sync_fetch_and_and  (ptr, val); }
short  sync_fetch_and_xor_2  (short *ptr, short val) { return __sync_fetch_and_xor  (ptr, val); }
short  sync_fetch_and_or_2   (short *ptr, short val) { return __sync_fetch_and_or   (ptr, val); }
short  sync_fetch_and_nand_2 (short *ptr, short val) { return __sync_fetch_and_nand (ptr, val); }

short  sync_add_and_fetch_2  (short *ptr, short val) { return __sync_add_and_fetch  (ptr, val); }
short  sync_sub_and_fetch_2  (short *ptr, short val) { return __sync_sub_and_fetch  (ptr, val); }
short  sync_and_and_fetch_2  (short *ptr, short val) { return __sync_and_and_fetch  (ptr, val); }
short  sync_xor_and_fetch_2  (short *ptr, short val) { return __sync_xor_and_fetch  (ptr, val); }
short  sync_or_and_fetch_2   (short *ptr, short val) { return __sync_or_and_fetch   (ptr, val); }
short  sync_nand_and_fetch_2 (short *ptr, short val) { return __sync_nand_and_fetch (ptr, val); }

int    sync_fetch_and_add_4  (int   *ptr, int   val) { return __sync_fetch_and_add  (ptr, val); }
int    sync_fetch_and_sub_4  (int   *ptr, int   val) { return __sync_fetch_and_sub  (ptr, val); }
int    sync_fetch_and_and_4  (int   *ptr, int   val) { return __sync_fetch_and_and  (ptr, val); }
int    sync_fetch_and_xor_4  (int   *ptr, int   val) { return __sync_fetch_and_xor  (ptr, val); }
int    sync_fetch_and_or_4   (int   *ptr, int   val) { return __sync_fetch_and_or   (ptr, val); }
int    sync_fetch_and_nand_4 (int   *ptr, int   val) { return __sync_fetch_and_nand (ptr, val); }

int    sync_add_and_fetch_4  (int   *ptr, int   val) { return __sync_add_and_fetch  (ptr, val); }
int    sync_sub_and_fetch_4  (int   *ptr, int   val) { return __sync_sub_and_fetch  (ptr, val); }
int    sync_and_and_fetch_4  (int   *ptr, int   val) { return __sync_and_and_fetch  (ptr, val); }
int    sync_xor_and_fetch_4  (int   *ptr, int   val) { return __sync_xor_and_fetch  (ptr, val); }
int    sync_or_and_fetch_4   (int   *ptr, int   val) { return __sync_or_and_fetch   (ptr, val); }
int    sync_nand_and_fetch_4 (int   *ptr, int   val) { return __sync_nand_and_fetch (ptr, val); }

int    sync_bool_compare_and_swap_1 (char  *ptr, char  oldval, char  newval) { return __sync_bool_compare_and_swap (ptr, oldval, newval); }
int    sync_bool_compare_and_swap_2 (short *ptr, short oldval, short newval) { return __sync_bool_compare_and_swap (ptr, oldval, newval); }
int    sync_bool_compare_and_swap_4 (int   *ptr, int   oldval, int   newval) { return __sync_bool_compare_and_swap (ptr, oldval, newval); }

char   sync_val_compare_and_swap_1 (char  *ptr, char  oldval, char  newval) { return __sync_val_compare_and_swap (ptr, oldval, newval); }
short  sync_val_compare_and_swap_2 (short *ptr, short oldval, short newval) { return __sync_val_compare_and_swap (ptr, oldval, newval); }
int    sync_val_compare_and_swap_4 (int   *ptr, int   oldval, int   newval) { return __sync_val_compare_and_swap (ptr, oldval, newval); }

char   sync_lock_test_and_set_1 (char  *ptr, char  value) { return __sync_lock_test_and_set (ptr, value); }
short  sync_lock_test_and_set_2 (short *ptr, short value) { return __sync_lock_test_and_set (ptr, value); }
int    sync_lock_test_and_set_4 (int   *ptr, int   value) { return __sync_lock_test_and_set (ptr, value); }

void   sync_lock_release_1 (char  *ptr) { __sync_lock_release (ptr); }
void   sync_lock_release_2 (short *ptr) { __sync_lock_release (ptr); }
void   sync_lock_release_4 (int   *ptr) { __sync_lock_release (ptr); }

void   sync_synchronize (void) { __sync_synchronize(); }
that you can then rename with __ prefixes.

Using mipsel-linux-gnu-gcc-9.4.0 -Wall -Os -S, you get the attached libgccsync.s, which you can include in any project or compile to an object file using simply gcc -c libgccsync.s, and it will provide the missing functions.  This works, because later GCC versions (on MIPS) do support the built-ins, emitting the necessary code inline.

Do note that OpenWRT has used GCC-7.4.0, GCC-8.4.0, and most recently GCC-11.2.0 as the (native) compiler on routers, including for mipsel_mips32 for Mikrotik RB532A and for mipsel_24kc for Mikrotik RBM33G.  I am not at all convinced that GCC-4.1.2 is any kind of a sweet spot for MIPS architectures.

[DiTBho]

Do note that OpenWRT has used GCC-7.4.0, GCC-8.4.0 [..]

I am not at all convinced that GCC-4.1.2 is any kind of a sweet spot for MIPS architectures.

I am using v4.1.2 simply for these reasons:
- it has been (1)hardly tested tested hard in 2007, 2008, 2009 stages
- and I also have an "hardened" profile
- it's a lot faster than gcc v12 (when gcc v12 doesn't crash, I can compare time-exec values)
- it consumes less ram
- it consumes only 200Mbyte of space (gcc v12 consumes much more space)
- I can re-use 2007, 2008, 2009 stages
- and it's what I practically have ready on hands

I can put gcc v7.4.0 and v8.4.0 on both Catalyst and my-builder; this requires more work, but I will at some point, just I was not prepared to the catastrophic internal compiler error of gcc v12.

edit:
(1) typos

[Nominal Animal]

and some applications like net-misc/wget v1.21.3-r1 have dependencies with gcc-v12
          libatomic.so.1 => /usr/lib/gcc/mipsel-unknown-linux-gnu/12/libatomic.so.1

Yep, they use the __atomic_ builtins introduced in GCC-4.8 instead of the Intel __sync_ ones.  If it does not depend on other libraries, you should be able to use the latest version even with older compiler versions.  (Even on 32-bit MIPS, libatomic should support 64-bit atomic ops, but it uses internal locking primitives for these I think.)

hardly tested

hardly tested != tested hard
hardly tested == tested only little
 

- I can re-use 2007, 2008, 2009 stages
- and it's what I practically have ready on hands

Okay, that makes ample sense to me too.

I can put gcc v7.4.0 and v8.4.0 on both Catalyst and my-builder

I would only bother with GCC 8.4.0 or 11.3.0 at this point.  Also check the patches OpenWRT applies to GCC.

Again, it is rather simple to implement utilities to check memory usage, say as an interposing library (that calls e.g. getrusage() for maxrss and checks /proc/self/maps for mappings after each mmap() call) you use via LD_PRELOAD; the issue with GCC is its peak memory use, so normal process statistics utilities like top are unlikely to capture that accurately.
All I'd need is verify no surprises in the /proc/self/maps format on MIPS, i.e. a copy of cat /proc/self/maps output on MIPS, really.

[DiTBho]

- I can re-use 2007, 2008, 2009 stages
- and it's what I practically have ready on hands

Okay, that makes ample sense to me too.

Technically what I am doing is part of the Sonoko project; this has been going on for 5 years and the bloody Murphy's law has been pretty harsh: *everything* that could go wrong has gone wrong

So, an old and obsolete Stage4 that actually work is better than a modern one that well is modern but has problem from the C compiler up.

would only bother with GCC 8.4.0

gcc-v8.5.0 looks promising, next week I will try to cross-compile it on a dedicated mac-mini.

it is rather simple to implement utilities to check memory usage

Sure, looks suuuuuuuper 

Code: [Select]

# cat /proc/self/maps
55560000-55569000 r-xp 00000000 08:03 9531391    /bin/cat
5557f000-55580000 r--p 0000f000 08:03 9531391    /bin/cat
55580000-55581000 rw-p 00010000 08:03 9531391    /bin/cat
55581000-555a2000 rw-p 00000000 00:00 0          [heap]
77b6c000-77b8e000 rw-p 00000000 00:00 0
77b8e000-77c00000 r--p 00000000 08:03 12894875   /usr/lib/locale/locale-archive
77c00000-77db5000 r-xp 00000000 08:03 815666     /lib/libc.so.6
77db5000-77dcd000 ---p 001b5000 08:03 815666     /lib/libc.so.6
77dcd000-77dd0000 r--p 001bd000 08:03 815666     /lib/libc.so.6
77dd0000-77dd3000 rw-p 001c0000 08:03 815666     /lib/libc.so.6
77dd3000-77dd8000 rw-p 00000000 00:00 0
77ddb000-77e07000 r-xp 00000000 08:03 1261748    /lib/ld.so.1
77e18000-77e1a000 rw-p 00000000 00:00 0
77e1a000-77e1b000 r--p 0002f000 08:03 1261748    /lib/ld.so.1
77e1b000-77e1c000 rw-p 00030000 08:03 1261748    /lib/ld.so.1
7fa73000-7fa94000 rwxp 00000000 00:00 0          [stack]
7fefd000-7fefe000 r-xp 00000000 00:00 0
7ff46000-7ff47000 r--p 00000000 00:00 0          [vvar]
7ff47000-7ff48000 r-xp 00000000 00:00 0          [vdso]


[DiTBho]

Code: [Select]

2023-03-26--20-52-13---2023-03-26--21-45-47 - [ net-dialup/minicom ] - failure - root@dev2.40.0/4.1.2
     cc1: error: unrecognized command line option "-Wno-format-truncation"
     minicom-2.8-r1 forked into overlay net-dialup/minicom, minicom-2.8-r11
     patch "minicom-2.8-gcc-4.1.2-fix.patch" created and applied
2023-03-26--22-24-44---2023-03-26--23-05-11 - [ =net-dialup/minicom-2.8-r11 ] - success - root@dev2.40.0/4.1.2

thus, my-builder uses modern gcc-v12 for cross-compiling (source=i686, target=mips2el), while Catalyst (on Qemu/mips2el) uses gcc-v4.1.2

Gcc-v4.1.2 is doing a great job of proving that 90% of system-2023 and 70% of world-2023 (both minimal & server-profile) can be compiled with v4.1.2 (C only) just by fixing ebuilds from things like

• error: ..for.. loop initial declaration used outside C99 mode
• error: cc1, unrecognized command line option "-Wno-format-truncation"
• ...

and ...




.... and

Code: [Select]

>[1] mipsel-unknown-linux-gnu-4.1.2 (tested hard, stable)
 (2) mipsel-unknown-linux-gnu-4.8.3 (new)
 (3) mipsel-unknown-linux-gnu-12 (broken, unstable)

we have a new native compiler: say hAllo to gcc-v4.8.3 

(yesterday afternoon gcc-v4.1.2 compiled v4.8.3 when I was out for a jog but reports say "with all tests passed", and now v4.8.3 is compiling itself)

[DiTBho]

excellent news!

Code: [Select]

2023-03-28--07-52-23---2023-03-28--10-46-59 - [ dev-libs/elfutils ] - success - root@dev2.40.0/4.8.3
               QA_tests[ dev-libs/elfutils ] - success

gcc-v4.8.3 actually works! and can be used to compile gcc-v8.*!
meanwhile, dev-util/strace will be recompiled with elfutils support

now we have tools to investigate the weird gcc-v12 behavior!