Use compiler optimization for c68kexec.c

[piggynl]

In riscv64, gcc generates unlinkable ELF for c68kexec.c, causing yabause fails to build.

This is a GCC bug. For long branches over 1MiB, RISC-V requires an indirect branch sequence (auipc + jalr) instead a direct branch (j). But GCC can only generate a j with an overflowed operand now. The jump if (!C68k_Initialised) goto C68k_Init; crosses almost the entire function body, which is over 1MiB in riscv64, so we will encounter this bug.

yabause/yabause/src/c68k/c68kexec.c

Line 207 in 7e38821

if (!C68k_Initialised) goto C68k_Init;

yabause/yabause/src/c68k/c68kexec.c

Lines 323 to 332 in 7e38821

	C68k_Init:
	{
	u32 i, j;
	#include "c68k_ini.inc"
	C68k_Initialised = 1;
	}
	return 0;

Enabling compiler optimization (specifically -freorder-blocks) allows GCC to reorder the C68k_Init block to the front of the function, so there won't be a long branch, and yabause will build successfully.

I noticed compiler optimization is disabled for c68kexec.c on purpose. Does any code depend on disabling compiler optimizations? Maybe there is something I can help with?

[piggynl]

Remove /Od for MSVC and replace -O0 with -fno-strict-aliasing for other compilers (MSVC does not implement strict aliasing optimizations at all).

With this change, GCC doesn't complain about code may be misoptimized unless ‘-fno-strict-aliasing’ is used anymore. I think the program should behave properly now.

[CoelacanthusHex]

This is a GCC bug. For long branches over 1MiB, RISC-V requires an indirect branch sequence (auipc + jal) instead a direct branch (j).

Should be auipc + jalr？