Only the low bytes are compared. Originally, signed 16-bit compares were optimized into signed 8-bit compares. But, the sign bits are in the high bytes; and, they're equal. Therefore, the low bytes always must be compared as unsigned numbers.
Fixes#1348.
The old broken code defers the count until the end of the (parent function's) argument list. But, a nested function call clears the pointer to the deferred type. That leads to an access violation.
The new code defers only until the end of each argument. Fixes#1320.
Test expressions like `unsigned char x = ...; ... = x / 2;`
These use `int` constants with values representable by
`unsigned int` / `unsigned char`, so using unsigned codegen should
be possible.
Additional tests for #1308. These are things we want to generate better
code for, so add tests that the behavior doesn't change.
In g_typeadjust, before we apply the integral promotions, we check if
both types are unsigned char. If so, we promote to unsigned int, rather
than int, which would be chosen by the standard rules. This is only a
performance optimization and does not affect correctness, as the flags
returned by g_typeadjust are only used for code generation, and not to
determine types of other expressions containing this one. All unsigned
char bit-patterns are valid as both int and unsigned int and represent
the same value, so either signed or unsigned int operations can be used.
This special case part is not duplicated by ArithmeticConvert.
Partial fix for #1308.
Both signed and unsigned chars are promoted to int by C's evaluation
rules. It is more efficient to use unsigned operations when possible,
however. These tests will help test the correctness of optimizations
doing that. See #1308.
Partial fix for ICE in #1211. This may fix enough to allow #1049 to be
fixed.
When merging labels, keep the first label with a ref that has no JumpTo;
this is a data segment label, used by computed gotos.
The real fix is to track and rewrite labels in data, but this is more
involved.
Fixes#1267
Avoid ICE, but treat plain int bit-fields declared via typedef as
signed rather than unsigned. It is more efficient to treat them
as unsigned, but this requires distinguishing int from signed int,
and this is curently not done.
This previously resulted in an ICE:
cc65: Check failed: (Entry->Type->C & T_MASK_SIGN) == T_SIGN_SIGNED,
file 'cc65/symtab.c', line 874
This CHECK is in the code that deals with changing `int` bitfields to
`unsigned int`.
Work around this by treating enum bit-fields as having their signedness
specified, so this type change code does not get called.
Fixes#1244.
cl65 creates intermediate files based on the source file name in the source file directory. Calling cl65 in parallel with the same source file causes those intermediate files to get overwritten.
Fixes#1080
Prior to this PR, `int`, `signed int`, and `unsigned int`
bitfields are all treated as `unsigned int`.
With this PR, `signed int` will be treated as `signed int`,
and the others remain unsigned.
Since `Type` does not distinguish between `int` and `signed int`,
add an extra `int* SignenessSpecified` param to `ParseTypeSpec`
so we can tell these apart for bit-fields and treat plain `int : N`
as `unsigned int : N` since it is more efficient to zero-extend
than sign-extend.
Fixes#1095
Previously, the following rules were used for binary operators:
* If one of the values is a long, the result is long.
* If one of the values is unsigned, the result is also unsigned.
* Otherwise the result is an int.
C89 specifies the "usual arithmetic conversions" as:
* The integral promotions are performed on both operands.
* Then the following rules are applied:
* If either operand has type unsigned long int, the other operand is
converted to unsigned long int.
* Otherwise, if one operand has type long int and the other has type
unsigned int, if a long int can represent all values of an unsigned int,
the operand of type unsigned int is converted to long int; if a long int
cannot represent all the values of an unsigned int, both operands are
converted to unsigned long int.
* Otherwise, if either operand has type long int, the other operand is
converted to long int.
* Otherwise, if either operand has type unsigned int, the other operand is
converted to unsigned int.
* Otherwise, both operands have type int.
https://port70.net/~nsz/c/c89/c89-draft.html#3.2.1.5
As one example, these rules give a different result for an operator
with one long operand and one unsigned int operand. Previously,
the result type was unsigned long. With C89 semantics, it is just long,
since long can represent all unsigned ints.
Integral promotions convert types shorter than int to int (or unsigned int).
Both char and unsigned char are promoted to int since int can represent
all unsigned chars.
https://port70.net/~nsz/c/c89/c89-draft.html#3.2.1.1
Rename promoteint to ArithmeticConvert, since this is more accurate.
Fixes#170
