| Age | Commit message (Collapse) | Author |
|---|
|
We will use the name 'label' for a function.
|
|
|
|
These are in the latest C23 draft.
|
|
|
|
|
|
Thanks to Nihal Jere for his initial patches implementing this
feature.
Fixes #35.
|
|
Also, make utf*enc assert that the codepoint is valid and return 0
for an invalid codepoint. This makes it possible to use safely
without error checking. We intend that these functions will only
be called with valid codepoints.
|
|
Also, make utf8dec take unsigned char * to avoid overflow when
converting to signed char.
|
|
|
|
Although we don't need the cnew in this case, we still need to do
the appropriate extension to 32-bit.
|
|
We explicitly ignore ERANGE for strtod, and in any other error case,
the end pointer is set to the beginning of the string.
|
|
It is implementation-defined whether malloc returns NULL or some
pointer when the size is 0, so we don't want to error out if the
implementation chose NULL.
|
|
We now hard-code the float precision in the format string instead
of using the float.h macros.
The other headers were never used (except maybe prior to the first
commit).
|
|
7e838669 removed conversion to bool for int expressions used only
to control jnz, but incorrectly dropped the conversion for the
right-hand-side of logical and/or as well. We need the result of
the expression to be 0 or 1, so we still need that conversion.
|
|
|
|
|
|
Instead, use an additional int64_t member in the union. Since
exact-width integer types have no padding bits or trap representations,
and use two's-complement representation, we can portably access an
int64_t union member stored as uint64_t and vice-versa.
This allows us to reinterpret the value without invoking potentially
implementation-defined behavior of casting an unsigned integer to
a signed integer type which may not be able to represent its value.
|
|
This will prepare us for adding a signed int64_t field called i.
|
|
We now do this evaluation during parsing.
|
|
We don't need exact-width integer types here.
|
|
This compiles `0 ? e1 : e2` as `e2`, and `1 ? e1 : e2` as `e1`
(while still adjusting the type as necessary).
|
|
|
|
|
|
As in ede6a5c9, if an expression is used only to control a jnz, we
don't need to convert it to a 0 or 1 value. QBE ignores the upper
32-bits of the argument to jnz, so the conversion is still needed
for pointer, long, and floating point types (including float since
-0 has non-zero bit representation).
|
|
QBE doesn't emit position-independent code, so we don't want __PIC__
defined if the preprocessor does by default.
|
|
|
|
We don't have any of these currently, but it's easier to support
than to error out.
|
|
|
|
|
|
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").
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
