Update use of async functions in self hosted compiler

[Vexu]

Follow up to #3748.

Blocked by #3190 (or something similar).
#3777 is avoided with a @panic.

[andrewrk]

Blocked by #3190 (or something similar).
#3777 is avoided with a @panic.

I'm having a look into these issues today.

[Vexu]

Looks like there is a bug in std.heap.c_allocator. Running zig-cache/bin/zig fmt build.zig crashes with incorrect alignment when using it. direct_allocator works fine though.

[andrewrk]

Currently, c_allocator just wraps realloc. This guarantees an alignment of 8 bytes only. However, an async function frame (on some targets, such as x86_64) requires alignment 16. I briefly tried to use one of the libc aligned memory allocation functions in the past, but it wasn't available on all the libcs we wanted to target.

However, that was before we had libc versioning support, and upon further reflection, we can certainly do better than realloc unconditionally.

Here's some brief research:

• musl supports memalign, posix_memalign, and aligned_alloc. (we provide musl so it will always have all of these)
• glibc supports memalign in all versions; posix_memalign since 2.1.91, aligned_alloc since 2.16.
• FreeBSD and NetBSD support posix_memalign and aligned_alloc
• macOS supports posix_memalign
• mingw-w64 and windows UCRT have _aligned_realloc

I believe that covers all the targets, so we can solve this with some additional logic in std.heap.cRealloc and std.heap.cShrink.

[andrewrk]

I extracted an issue out of my previous comment: #3783

[richfelker]

Per specification, realloc guarantees max_align_t alignment, which should be 16 on x86_64, but does not preserve any further alignment obtained from memalign-family. However max_align_t alignment is only 8 on 32-bit x86 and some other archs. musl always provides at least 16 but this is an implementation detail. Windows may have less than 16 on x86_64 because Windows..

[andrewrk]

Thanks - I'm going to update #3783 with a recommendation based on this information.