| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
We don't need the length constant anymore, so just use that name
for the length expression.
References: https://todo.sr.ht/~mcf/cproc/1
|
|
There may be multiple nested array types, so this doesn't work in
general.
References: https://todo.sr.ht/~mcf/cproc/79
|
|
|
|
|
|
Implements: https://todo.sr.ht/~mcf/cproc/72
|
|
|
|
We store alignment as int, so check that it fits to avoid
implementation-defined behavior.
Also, fix printf format specifier and drop unneeded parentheses.
|
|
References: https://todo.sr.ht/~mcf/cproc/68
|
|
Currently, all attributes are ignored.
References: https://todo.sr.ht/~mcf/cproc/68
|
|
|
|
|
|
|
|
|
|
Fixes: https://todo.sr.ht/~mcf/cproc/64
|
|
This will facilitate supporting underlying types other than int or
unsigned, possible in C23.
References: https://todo.sr.ht/~mcf/cproc/64
|
|
These should should act as zero initializers, but since init==NULL
was used to mean both "no initializer" and "empty initializer",
empty initializers weren't zero-initializing the variable.
|
|
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'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Previously, the qualifiers were saved, but accidentally ignored
when the typedef was referenced.
|
|
|
|
It could be NULL in some cases.
|
|
This is specified by the last sentence in C11 6.7.5p6.
|
|
|
|
This is not yet supported by QBE, so for now we allocate a bit extra
and choose the address in the allocated region with an aligned
address.
|
|
|
|
This requires a not-yet-upstream QBE patch, and is needed for riscv64
support, since the calling convention may be different depending
on whether the argument is named or variadic.
|
|
Thanks to Nihal Jere for his initial patches implementing this
feature.
Fixes #35.
|
|
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 reverts commit c16f07acf655b9f4fb006d8256b4027fb5a13aa8.
This incorrectly allows octal escapes to span between adjacent
string literals (e.g. "\0" "1" is not the same as "\01").
|
|
|
|
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.
|
|
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.
|
|
This way we avoid leaking backend-specific details of type
representation outside qbe.c. It also facilitates some future
simplifications.
|
|
|
