slightly updated in status. x86-64 and sparc and mips64-eb
all appear to work well enough to complete or get well into
an atf run (still going.)
note first ICE segv on sh3
- live patching support
- shell completion help
- generally better diagnostic output (less verbose/more useful)
- diagnostics and optimisation choices can be emitted in json
- asan memory usage reduction
- many general, and specific to switch, inter-procedure,
profile and link-time optimisations. from the release notes:
"Overall compile time of Firefox 66 and LibreOffice 6.2.3 on
an 8-core machine was reduced by about 5% compared to GCC 8.3"
- OpenMP 5.0 support
- better spell-guesser
- partial experimental support for c2x and c++2a
- c++17 is no longer experimental
- arm AAPCS GCC 6-8 structure passing bug fixed, may cause
incompatibility (restored compat with GCC 5 and earlier.)
- openrisc support
else sys.mk will attempt to write it to the source tree,
which may be r/o and fail.
XXX may cause updates builds to fail because a file listed
in .depend won't exist anymore.
Reset STACK_BOUNDARY to default, 16, to fix strange freeze for amiga,
when kernel is compiled by GCC8.
For m68k, the stack pointer is required to be aligned to 16-bit boundary
by architecture. Whereas System V ABI demands it to be aligned to 32-bit
boundary.
According to the document, STACK_BOUNDARY is ``the minimum alignment
enforced by hardware for the stack pointer on this machine.'' Whereas,
PREFERRED_STACK_BOUNDARY should be used ``if you wish to preserve a
certain alignment for the stack pointer, greater than what the hardware
enforces.''
Therefore, STACK_BOUNDARY and PREFERRED_STACK_BOUNDARY should be 16 and
32, respectively, for m68k. This is how Linux/m68k does.
GCC 8 generates codes that wisely allocate 64-bit objects on stack by
using STACK_BOUNDARY. This corrupts the stack frame if it is not properly
aligned.
Since the architecture only guarantees the stack pointer to be aligned to
16-bit boundary, it is not aligned to 32-bit boundary in an instance in
general. If the interrupt occurs at this moment, the interrupt handler
spoils the stack frame as explained above, which results in the mysterious
kernel freezes.
I guess that similar failures can occur even for userland with signal.
With this setting, amiga kernel works just fine as far as I can see.
Furthermore, I've confirmed for amiga, mac68k, and sun3,
(1) Kernel compiled by patched GCC8 works with
(1-a) userland built by GCC7 and non-modified GCC8, and
(1-b) userland built by patched GCC8.
(2) Userland binaries compiled by GCC7 and non-modified GCC8 work fine
with kernel and base libraries built by patched GCC8.
(3) There's no regression observed for tests/kernel, tests/lib/libc/sys,
and tests/lib/libc/gen.
This also fixes sun2 kernel to a considerable extent. With non-modified
GCC8, sun2 kernel crashes in strange ways during the early boot stages.
With this change, it boots singleuser.
OK mrg
Remove stray ``&&'' introduced in the previous revision, so that
host tools are correctly passed to configure script.
No similar problem for gcc.old. No release branches are affected.
Seems like false positive since the ASM_GENERATE_INTERNAL_LABEL macro
stores the value into prev_label, so it is alright for prev_label to
be uninitialized.
Error was reported when build.sh was run with MKSANITIZER=yes flag.
Reviewed by: kamil@
accident when i wrote ${MACHINE_ARCH} != "sh3", but this should
have been MACHINE_CPU.) this means m68k is the only one left.
update various other parts and note some of the m68k issues.
