Re: GCC8 v.s. amiga

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

Hi. Sorry for the late reply. Some updates:

On 2020/06/04 19:06, Rin Okuyama wrote:
> For my Amiga A1200 with 68060, kernel built by GCC8 does not work.
> It randomly crashes, and I could not enter DDB nor even obtain
> backtrace; it suddenly freezes.

I forgot to note an important information: ``randomly'' here means when
kernel freezes is almost unpredictable. Some time, it crashes just after
exec /sbin/init, but other time, it freezes after survival of 12 hours in
multiuser with heavy load!

When kern_tc.o is built by GCC7, I've never observed such a freeze.
Uptime exceeds few days at least.

This is why everything takes a loooong time ;).

On 2020/06/04 19:11, John Paul Adrian Glaubitz wrote:
> Do you have the possibility to test GCC 10? The m68k backend has been
> partially rewritten for version 10 which has fixed some bugs in the
> code generation.

Yeah, I donated that campaign a little :).

> At least on Debian, the kernel built with GCC 10 boots fine on my
> Amiga 4000 and qemu-m68k.

Unfortunately, GCC10 (and also 9 and 8) crashes by ICE when building our
kernel:

| #   compile  A1200/kern_tc.o
| ...
| during RTL pass: expand
| In file included from ../../../../sys/param.h:145,
|                  from ../../../../kern/kern_tc.c:49:
| ../../../../sys/time.h: In function 'tc_windup':
| ../../../../sys/time.h:113:11: internal compiler error: Segmentation fault
|   113 |  bt->frac += x;
|       |           ^~
| 0xe76208 crash_signal
|         /build/work/gcc-10.1.0/gcc/toplev.c:328
| Please submit a full bug report,
| ...

cf.: https://nxr.netbsd.org/xref/src/sys/sys/time.h#113

I guess why Linux builds and ours does not is:

(1) Linux #undef STRICT_ALIGNMENT and friends, but we do not
(2) We #define BIGGEST_ALIGNMENT 64, but Linux does not

For GCC in our local tree, we worked around for this:

http://cvsweb.netbsd.org/bsdweb.cgi/src/external/gpl3/gcc/dist/gcc/expr.c#rev1.2

| Module Name:	src
| Committed By:	chs
| Date:		Sun Oct  9 21:17:34 UTC 2011
|
| Modified Files:
| 	src/external/gpl3/gcc/dist/gcc: expr.c
|
| Log Message:
| in emit_push_insn(), ignore alignment if we don't have a type.
| works around a gcc ICE on m68k.  from mrg.
|
| To generate a diff of this commit:
| cvs rdiff -u -r1.1.1.1 -r1.2 src/external/gpl3/gcc/dist/gcc/expr.c

If this patch applied, GCC10 does build our kernel, but

(a) Kernel built by GCC8 with kern_tc.o replaced by that with GCC10
---> eventually crashes as before

(b) Entire kernel built by GCC10
---> does not boot singleuser

On 2020/06/06 7:00, Christos Zoulas wrote:
> Wow, you did a lot of work... If I wanted to drill this down more I would
> start comparing rhe generated assembly from gcc-7 and gcc-8, or split the
> file into individual functions and see which one is broken.

Thanks :). Reading entire assembler code is tough, so, I spitted
kern_tc.c into tc_windup() (and inline function tc_delta()) and other
functions. I considered tc_windup() is most suspicious; it is invoked by
hardclock() every second at least. Then, built only tc_windup() by GCC7
to see what happens.

Then, the kernel survives 12 hours with heavy load as described above.
But it froze after all. Maybe the situation is ``improved''; in most
cases when kern_tc.c is built by GCC8, kernel freezes after few hours in
multiuser mode.

Now, I incline to guess that GCC/m68k has bug in 64bit integer support.
ICE described above is an example. As far as I can see, I do not observe
any similar ICE for other architectures when the workaround above is
removed. Also, for m68k, ICE does not occur if

(A) #undef STRICT_ALIGNMENT

or

(B) #define BIGGEST_ALIGNMENT 32

In addition, gcc/config/m68k does not contain E_DImode (== long long)
at all. Other purely 32bit arch, e.g., sh contains it (they removed sh5
support long ago). I'm far from familiar with GCC internal, but this
seems strange...

Thanks, and sorry for long, disordered message...
rin