| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This simplifies the creation of allocation instructions in the start
block.
|
|
Also, add bounds checks for float-to-int conversions. If the integer
part can't be represented in the result type, C behavior is undefined.
Although this means the result is arbitrary, we need to avoid
undefined behavior in cproc itself when given such a program as
input.
|
|
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.
|
|
|
|
|
|
|
|
C23 relaxes the restriction that labels must always be followed by
statements in N2508[0].
[0] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2508.pdf
|
|
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.
|
|
|
