~mcf/cproc

configure: Undefine __PIC__

QBE doesn't emit position-independent code, so we don't want __PIC__
defined if the preprocessor does by default.
driver: Pass -nostdinc on to preprocessor
qbe: Support more aligned types in funccopy

We don't have any of these currently, but it's easier to support
than to error out.
qbe: Fix temporary type for < 8 byte aligned struct copies
Add test for string concatenation corner case
Revert "Add stringconcat function to concatenate adjacent string literals"

This reverts commit c16f07acf655b9f4fb006d8256b4027fb5a13aa8.

This incorrectly allows octal escapes to span between adjacent
string literals (e.g. "\0" "1" is not the same as "\01").
38d90628 — Nihal Jere 4 months ago
qbe, init: Handle prefixed string literals
Make string literal data unsigned char
CI: Switch to debian/stable
decl: Include location for _Complex/_Atomic error messages
expr: Fix varargs again and add more tests
qbe: Add default cases to avoid uninitialized warning
Add config.mk to .gitignore
configure: Drop -E from preprocesscmd

We are already using cpp here, so -E is redundant.
driver: Pass -P through to the pre-processor

Since we no longer pass -P to cpp ourselves, we need to pass it
through when it appears on the command-line instead of ignoring it.
decl: Relax restrictions for 0-length array member

Zero-length array members are quite common in linux UAPI headers,
where they don't follow the restrictions of flexible array members.
Since they are non-standard, relax the error checking for them,
rather than considering them the same as a flexible array member.
Fix type-checking of va_list arguments to varargs built-ins

If the argument was a function parameter, its type has already been
adjusted. So on x86_64, we can't just ignore the automatic
array-to-pointer conversion, since it was never a pointer to begin
with.

Instead, keep track of the adjusted va_list type, and check that
the arguments to varargs built-ins match that type.
Add tests for char/wchar_t signedness
Use architecture-specific va_list type

Previously, cproc effectively used used

	typedef struct { /* 32 bytes, 8-byte aligned */ } __builtin_va_list[1];

However, this is not quite correct for x86_64 nor aarch64, though
it was close enough for both to work in most cases.

In actuality, for x86_64 we want

	typedef struct { /* 24 bytes, 8-byte aligned */ } __builtin_va_list[1];

and for aarch64 we want

	typedef struct { /* 32 bytes, 8-byte aligned */ } __builtin_va_list;

The difference only appears when the size of va_list matters, or
when va_list is passed as a parameter. However, the former is not
often the case, and the aarch64 ABI replaces aggregate arguments
with pointers to caller-allocated memory, which is quite similar
to arrays decaying to pointers in C except that the struct is not
copied.

Additionally, riscv64 simply uses

	typedef void *__builtin_va_list;

which again has a different size and calling convention.

To fix this, make the __builtin_va_list type architecture-specific
and use architecture-specific tests for varargs-related functionality.
Prepare for supporting architecture-specific va_list type
Next