Re: GCC8 v.s. amiga

Hi,

I can confirm that I experienced all of the same problems as Rin and
others with FS-UAE 3.0.5 (also brief testing with WinUAE 4.4.0 showed
identical behavior) and emulated 68040. I see random freezes with a
kernel built with GCC 8. I can't enter DDB or dump. On WinUAE, the
status bar actually changes to "HALT".

My suspicion at the moment is that these mysterious freezes on real
and emulated Amigas are due to a bug in locore.s or some other
low-level Amiga-specific asm or C code that nobody has discovered yet,
related to the C code being optimized differently between GCC 7 and
GCC 8.

I'd still like to solve the problems I was seeing with CPUFLAGS that I
reported in my own thread (and I'll submit the whitespace patch I made
that I know is good upstream), but my highest priority, as far as
NetBSD hacking, is to try to help out in any way I can to figure out
why the kernels are crashing with GCC 8 (and up). I'll review the
kernel code and set aside the GCC backend for now. I think the problem
is in the kernel, not GCC.

Thanks,
Jake

On Sat, Jun 27, 2020 at 4:02 AM Rin Okuyama <[email protected]> wrote:
>
> Hi,
>
> On 2020/06/27 19:02, Michael van Elst wrote:
> > [email protected] (Rin Okuyama) writes:
> ...
> >> Hmm, then it is problem peculiar to 68060, or GCC miscompile something
> >> with tuning for 68060. I observed the problem both for -m68060 and
> >> -m68020-60.
> >
> >> Which compiler flag do you use? Do you use GENERIC? Then, it is
> >> compiled with -m68020-60 by arch/m68k/Makefile.cmachflags...
> >
> >
> > I use a mostly stripped down GENERIC, but no change to CPU flags.
> > So yes, it is built with -m68020-60.
> >
> >
> >> Or emulator accepts some kinds of instructions that do not work on
> >> real hardwares?
> >
> > I don't think so. But it doesn't emulate caches and the TLB works
> > differently.
>
> Thank you for your comments! I understand the situation.
>
> > Saying that, after a few hours idling in multi-user, the system
> > paniced with an uvm_fault followed by an illegal instruction
> > trap. Neither looked real in DDB.
> >
> > I'll have to retry this with a gcc7-built kernel, it could be
> > some other m68k instability introduced in -current.
>
> Hmm, for my A1200, a GCC7-buit kernel as of last week works without
> problems at least for several days. So, it can be due to GCC8.
>
> Thanks,
> rin