Code Generation

Recursive calls incorrectly indicated (XC8-2451) The compiler might indicate that a function has been recursively called when indirectly called via a pointer that is also used to hold other function addresses at other times in the program. The compiler considers the targets of a pointer over the entire lifetime of the pointer object, which might fool the compiler into believing that recursion has taken place.

WREG0 (CPU)

-Xxc8 -W--dwarf-use-loclists=never

-Wa,-no_merge

-mrom -mreserve

•

•

•

•

•

•

•

Not this array size (XC8-2445) Const-qualified arrays of bytes with a size of exactly 0x8000 will trigger an error indicating that the array dimension must be larger than zero. Larger or smaller arrays will

compiler correctly.

Incorrect tracking of double indirection (XC8-2444) When a pointer variable is assigned an address indirectly via another pointer, the assigned address might not be correctly tracked by the compiler, resulting in an incorrect pointer size being used.

Size-of symbols not functioning (XC8-2412) The map file contains symbols, for example

, that suggest they might show the size of functions. These always indicate the value 0 and cannot be used to determine the size of any routine.

Missing delays (XC8-2345) When building for Baseline and Mid-range PIC devices, the and delay builtins are missing.

Bad array access (XC8-2286) For projects that target PIC18 devices and that use expressions reading large arrays that can span multiple banks, array accesses using a constant array index might have used the wrong instruction. Using a pointer to the array (rather than the array identifier) and the same index will work correctly.

Read of volatile objects not performed (XC8-2273) If the true and false statements for an statement are identical, the compiler will try to simplify such situations. If the controlling expression inside the

accesses seemingly redundant objects, code to access to these objects might be incorrectly removed.

Wrong CRC write order (XC8-1997) The multi-byte CRCDATA register must be written in a specific byte order to ensure that the data is latched correctly. There is no guarantee that this will take place for C code that writes to this register as a whole. Code should instead write to the individual registers within CRCDATA (T, U, H, and L registers) in the intended order.

Bad tail merge optimization (XC8-1978) In rare circumstances where two or more PIC18 code sequences immediately before a jump to the same destination contain instructions that differ only in the

banked/common access bit, these sequences might be incorrectly merged into one.

Undetected Division by zero in assembly (XC8-1960) Division of a literal constant by zero is not being detected in the assembler, which may cause the assembler to crash.

Illegal instruction not detected (XC8-1956) Using a operand to the instruction does not trigger any error or warning, and the instruction is encoded use the Access Bank memory.

Right shift wrong (XC8-1941) Right-shifting a variable by 16 bits can omit the sign extension, producing an incorrect result.

Incorrect pointer arithmetic (XC8-1940) Incrementing to a pointer to an array, e.g. , should add a value being the size of the array. Instead, it is adding the size of the array's elements.

Static function diagnostics (XC8-1938) Depending on the order of the input C files, one may or may not get an “undefined symbol” error for a function defined as in one file but used and declared

in another, but undefined at link-time.

Incorrect array sizes (XC8-1934) When compiling C99 programs, the compiler may make incorrect assumptions about the size of pointers used to define the size of an auto array.

Inappropriate and missing types (XC8-1886) The header used by C99 builds defines

( ) as being types with a size of 4 bytes, whereas a type with a width of 2 bytes would be the fastest types. The ( ) types are missing entirely.

__size_of_strncmp

_delaywdt_us _delaywdt_ms

if()

if() volatile

,w movwf

signed long

char (*ptr) [32]

static extern

<stdint.h>

u int_fast16_t

u int_fast24_t

Case ranges ignored (XC8-1855) When the Clang front end is used for building, it silently ignores case ranges in statements and matches only the initial case value in the range. Clang is used when building for the C99 standard.

Unsupported directive (XC8-1817) The assembly directive is not supported.

Bogus warning for absolute functions (XC8-1809) Functions that are made absolute might trigger the

warning when compiling for

devices that have vectored interrupts, e.g. a PIC18F25K42. This warning can be ignored.

Generate no code warning (XC8-1803) Some of the C99 standard library character classification functions

(viz. , , , , , , and )

will cause the compiler to emit the warning . This is a side-effect of their implementation, and can be safely ignored.

FLT_ROUNDS macro not defined (XC8-1791) The macro, which should be defined by is not defined and its use will result in an undefined symbol error.

Excessive consumption of decimals (XC8-1790) The A, E, F, and G conversion specifiers in the C99 functions will consume 'p' and 'P' in decimal numbers.

Special float strings not recognised (XC8-1789) The A, E, F, and G conversion specifiers in the C99 functions do not recognise strings representing infinity and NaN (not a number).

Errno affects scans (XC8-1786) If the variable is non-zero before calling any of the C99 functions, then any of the following conversion specifiers will fail: A, D, E, F, G, O, S and X.

Character set conversions not supported (XC8-1785) The character-set conversion specifiers in the C99 functions are not supported.

White space not counted (XC8-1784) The conversion-specifier in the C99 fails to count white-space in the input string.

Error not set for string conversions (XC8-1782) The C99 family of functions (including and ) do not set to for values outside the representable range.

Scanning hex floating-point (XC8-1781) The C99 , , , and conversion specifiers will only convert the leading zero of any hexadecimal floating-point constant. This results in an assignment of zero to the function arguments which receive the converted input, and the remainder of the string from the character is scanned according to the format string.

Undetected bad config values (XC8-1771) If the argument to the directive is a literal numerical value with a valid initial value followed by illegal characters, for example

, the initial portion of the value is read and the remainder silently ignored.

This might be encountered of you accidentally attempt to specify a binary value to this pragma, using a prefix.

fmod() and zero (XC8-1641) The library function is non-compliant when second argument is zero.

Currently, it returns the first argument in this case. It should return either trigger a domain error or return zero.

Can't generate code for floating-point operations (XC8-1613, XC8-1614) Expression that perform operations on the results of two complex floating-point expression, e.g. use of the operator in the

following , might trigger can't generate code error

messages.

switch

DDW

(1262) object "*" lies outside available data space

isalpha() isdigit() isgraph() islower() isprint() isspace() isupper() expression generates no code

String literal expressions (XC8-1610) Accessing a character of a string literal might produce an error

message when using the initialize an object, e.g. .

Too many side-effects (XC8-1587) Incorrect PIC18 code is being generated for expressions involving compound assignment operators and where the lefthand side has effects. In this cases, the side-effects of the lefthand side will occur twice.

IDLOC value truncation (XC8-1570) The IDLOC values for some devices, e.g. PIC18F8723, are currently limited to being 4-bits wide. The truncation can be removed by editing the file (located in the directory) corresponding to your device, and changing the mask value, bolded in this example:

CWORD:200000:F:FF:IDLOC0