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
These test cases don't use dynamic labels.
https://github.com/cc65/cc65/issues/1209#issuecomment-678738971
Also update the original test case for consistency:
* Change failure message to just "FAIL", as there is only one failure
* Outdent label definitions
* Clarify description
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
