Age | Commit message (Collapse) | Author |
|
|
|
|
|
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.
|
|
|
|
Make an exception for flexible array members, though we should also
check that the flexible array member, if any, is last.
|
|
|
|
This function also ensures that the string prefixes (if any) are
compatible. It should make it easier to implement wide string
support.
|
|
|
|
C11 6.7.5p6 says "An alignment specification of zero has no effect".
|
|
This reverts commit 6229709b8ae21d7722fef48ad8a9f2f10b900030.
I still don't understand how out-of-range enum constants are supposed
to work.
|
|
gcc and clang allow enum constants out of range of int, but this
means that the type of enumerator may differ inside and outside the
enum specifier.
Instead, only allow out-of-range enum constants when their types
are compatible with the final enum type.
|
|
|
|
|
|
|
|
|
|
Even though we don't support VLAs yet, we should still be parsing the
VLA syntax, then failing after if it was not a constant expression.
|
|
This is accepted for C2X[0].
[0] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2265.pdf
|
|
|
|
|