| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
We are already using cpp here, so -E is redundant.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
The location should not include preceding whitespace and was off
by one.
|
|
|
|
Fixes #66.
|
|
|
|
|
|
Some operating systems do not support uchar.h, and glibc only defines
char16_t/char32_t for GNU C compilers.
|
|
When declarator() is called with allowabstract == false, the caller
can assume that it will always return the identifier being declared.
However, abstract function declarators were incorrectly accepted
in this case with name set to NULL instead of erroring out due to
invalid syntax.
To fix this, only skip forward to function declarator parsing for
abstract declarators, since this is the only case where we can't
immediately tell whether we have a parenthesized declarator or a
function declarator.
Fixes #74.
|
|
These will be needed to implement wide string literals.
|
|
|
|
|
|
|
|
Now that we don't track QBE types within values, we don't have to
worry about generating incorrect SSA when passing an 'l' value to
a function taking a 'w'. So we can just return the source value
instead of emitting a dummy copy instruction.
|
|
This way we avoid leaking backend-specific details of type
representation outside qbe.c. It also facilitates some future
simplifications.
|
|
We always store the result to a w temporary, so there is no difference.
In fact, QBE provides loadw as an alias for loadsw precisely for
this reason.
|
|
|
|
Make an exception for flexible array members, though we should also
check that the flexible array member, if any, is last.
|
|
|
|
Make the ID an unsigned int. This will make it small enough to
efficiently pass struct value by value. It also simplifies things
slightly.
|
|
conversion
The conversion is only needed for floating types. QBE isn't able
to optimize it away for integer types yet, so removing this unnecessary
conversion has a substantial performance benefit.
|
|
|
|
|
|
This function also ensures that the string prefixes (if any) are
compatible. It should make it easier to implement wide string
support.
|
|
|
|
This will facilitate the support of wide-string literals.
Based on patch from Nihal Jere.
|
|
It appears that some operating systems don't yet support the C11
DBL_DECIMAL_DIG. In order to ensure consistent output no matter the
precision of long double (which varies from arch to arch), just use
a fixed 17, which is sufficient for IEEE 754 binary64.
|
|
|
|
|
|
|
|
DECIMAL_DIG may vary from system to system depending on the width
of long double, causing one of the tests to fail.
|
|
FreeBSD 13 no longer contains a standalone assembler in the base
install, and also added a hard-requirement on _Thread_local.
|
|
QBE support isn't quite there yet, but is progressing smoothly.
|
|
|
|
|
|
C11 6.7.5p6 says "An alignment specification of zero has no effect".
|
