Age | Commit message (Collapse) | Author |
|
|
|
|
|
These were removed in C23.
|
|
|
|
evalexpr() was originally named `constexpr`, since it matched the
constant-expression rule in the grammar. It had to be renamed due
to conflict with the C23 constexpr keyword.
However, since 2e3ecc70, eval has just one argument, so just call
eval(condexpr()) directly.
|
|
|
|
|
|
|
|
|
|
|
|
Fixes: https://todo.sr.ht/~mcf/cproc/64
|
|
This should be fixed so that array types are never qualified, but
for now, just union the array type qualifiers with the element type
qualifiers. See issue 79 for more details.
|
|
The addition of C23 keywords made 'constexpr'
unusable as a function name. This prevents cproc
from bootstrapping. This patch simply renames
the problematic function to 'evalexpr'.
|
|
|
|
|
|
|
|
fb00ba6978 had the side-effect of introducing an integer to pointer
cast, which was not evaluated as a constant expression. To fix this,
just set the type of the expression.
|
|
|
|
|
|
|
|
|
|
as long as `size_t`'s conversion rank is >= `int` this check would work
out fine.
but in case size_t happens to be less than int (which I believe is valid
under the C standard) then comparison will take place in `signed int`
and the operand `-1` will not get implicitly converted to SIZE_MAX.
explicitly cast it to size_t to avoid such issues.
|
|
|
|
|
|
This is necessary to fix unary negation of floating-point 0 (also
depends on a pending qbe patch).
|
|
We only require a type of at least 64 bits, so just use unsigned
long long.
Only siphash remains as the last user of uint64_t.
|
|
|
|
|
|
|
|
|
|
|
|
These are in the latest C23 draft.
|
|
|
|
Thanks to Nihal Jere for his initial patches implementing this
feature.
Fixes #35.
|
|
|
|
We explicitly ignore ERANGE for strtod, and in any other error case,
the end pointer is set to the beginning of the string.
|
|
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).
|
|
This will prepare us for adding a signed int64_t field called i.
|
|
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).
|
|
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").
|
|
|
|
|
|
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.
|
|
|
|
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.
|