IAR Information Center for Renesas RX

Important information
New features
Known problems
Program corrections
User guide corrections
Miscellaneous
Release history

Important information

Binary compatibility
Object modules produced with earlier versions of the compiler cannot be linked together with modules produced with version 4.x.

The --fpu option
From v4.10 and onwards, the --no_fpu option is replaced by the new option --fpu={none|32|64} where 32-bit floating point format is the default.

Using the __ramfunc keyword
From v2.90.4 and onwards, the __ramfunc keyword can be used also in big-endian mode. A consequence of this is that little-endian __ramfunc declared functions are no longer initialized by the default (data) initializing routines and therefore you need to make __iar_init_ramfunc a required symbol when linking object code (that uses __ramfunc) from older versions. Further, existing linker configuration files (.icf) need the .textrw section to be initialized manually in big-endian mode. This is achived by adding the line:
initialize manually { rw section .textrw }

ID code and system register setting
From version 2.60 and later, setting the ID code bytes and system registers like MDES, OFS0 and OFS1, etc, is no longer done in the linker configuration files. Default values are set in the runtime libraries and if you want to override these, you do this on C or assembler level. See the Development Guide for detailed information.

New features

None

Known Problems

[EWRX-622] The compiler passes arguments like struct {char a;}, struct {short b;}, or class/union in registers. This is not compliant with the Renesas ABI. This means that, for example, if function calls with such arguments are made to libraries built with the Renesas CCRX compiler, they will fail.

Program Corrections

[EWRX-641, TPB-3269] The compiler can generate incorrect code for comparisons between floating-point numbers, regardless of optimization level. If at least one of the numbers is NaN, the outcome of the comparison is sometimes reversed.

User guide corrections

Subnormal numbers for floating-point numbers
If the 64-bit FPU is used (--fpu=64) subnormal numbers are not supported, neither for 32-bit nor for 64-bit floating-point numbers.
New intrinsic functions related to the double-precision floating-point unit
The following intrinsic functions have been added to set/read values to/from the respective named registers:
__intrinsic void __set_DPSW_register(unsigned long) __intrinsic void __set_DCMR_register(unsigned long) __intrinsic void __set_DECNT_register(unsigned long) __intrinsic unsigned long __get_DPSW_register(void) __intrinsic unsigned long __get_DCMR_register(void) __intrinsic unsigned long __get_DECNT_register(void) __intrinsic unsigned long __get_DEPC_register(void)
New predefined symbol related to the double-precision floating-point unit
__DPFPU - Double-precision floating-point unit (DPFPU) used (--fpu=64)

Miscellaneous

Nothing

Release history

4.13.1 2019-11-20

Program corrections

[EWRX-638]
If a switch just contains a case value with zero and a default case, and those two set a bool variable to true or false, testing a single bit and using it as a switch argument can produce the wrong result. See this code example:
```
switch((varOfSignedType & 1U) == 0U)
{
  case 0: b = false; break;
  default: b = true; break;
}
```
[EWRX-630]
The wrong value is computed for 8- and 16-bit signed variables when the expression can be transformed into a MIN or MAX operation, and the variable is updated with a negative constant. For example:
```
short a, b;
while (a > b)
{
   a -= 4;     // negative constant
   if (a < b)  // max operation 
   a=b;
}
```

New features

Double-precision floating-point unit
The RXv3 double-precision floating-point unit (DPFPU) is now supported (--fpu=64).

4.12.1 2019-06-18

Program corrections

[EWRX-610] Boolean 'AND' together with a right-shift operation can result in a internal error when compiling for the RXv3 core.
[EWRX-597] On optimization level High, the compiler applies an integer saturate idiom for floating-point values, which does not work for negative floats or NaN. For example:
```
if (value > 1.0F) 
  value = 1.0F;
if (value < -1.0F) 
  value = -1.0F;
```
[EWRX-636] On optimization level Medium or higher, the optimizer can fail to preserve the implicit destination register for EMUL and EMULU.

4.11.1 2019-02-18

Program corrections

[EWRX-594] The intrinsic function __exchange(unsigned long a, unsigned long *b) fails to update a if a has static storage duration or resides on the stack frame.

4.10.2 2018-11-28

Program corrections

[EWRX-573] On optimization level Low, the compiler produces expressions for address constants that the assembler and linker fail to process, resulting in the link-time error "Error[Lp002]: relocation failed: Stack relocation error". For example, in the code
```
return ((int)ptr - (int)&mStruct[2].a);
```
the term on the right-hand side is such a constant address expression, and will trigger the error.
[EWRX-562]
At optimization level High, if a complex expression includes several logical bitwise operations (OR, AND, or XOR) of the same type where at least one operand is a literal integer and one is a load from memory, then one memory load might be lost. For example, in the case:
```
  x = a[2] & b[5] & b[2] & 3;
```
the b[2] load is lost, causing b[5] to be used twice, so the effective expression becomes:
```
  x = a[2] & b[5] & 3;
```

4.10.1 2018-06-29

Program corrections

[EWRX-547] In big-endian mode, a 2-byte union residing in a register (for example a parameter or a local variable) cannot be accessed both word-wise and byte-wise, because the byte access will not access the same part of the register as a word access does.
[EWRX-546] Under Windows 10, a memory dependence causes some integer promotion casts to be present or absent, which in turn causes a register renumbering. The code is correct in both cases, but function sizes and execution speed might differ by a small percentage.
[EWRX-526] The top half of the result of a 64-bit left shift operation is set to zero when the left operand is known. It affects all optimization levels except -Ol and -On. For example:
a_longlong |= (1ULL<<count);

New features

Support for the C11 language standard
The compiler and libraries adds support for the latest C language standard ISO/IEC 9899:2011.
Note: the new C library binary object interface is incompatible with earlier EWRX versions.
Support for the C++14 language standard
The compiler and libraries now supports the latest C++ standard ISO/IEC 14882:2014.
Note: the new C++ library binary object interface is incompatible with earlier EWRX versions.
Stack protection
The IAR C/C++ compiler for RX now supports stack protection. A canary value will be placed between the stack variables and the return address so that the system can detect corruption of a function return address before the function returns to that address. The compiler will use heuristic to determine whether a function needs stack protection or not. If any defined local variable has the array type or a structure type that contains a member of array type, the function will need stack protection. See IAR C/C++ Development Guide for more information.

3.10.7 2018-01-30

Program corrections

[EWRX-534] The optimizer combines shifts operations (<< or >>) distributed in a binary expression (+ - & | ^) even though the shift counts are not identical. An example with '+' as the binary operator and left shifts in both arguments:
((c*16)<<1) + (((c-1)*4)<<1) is first simplified to
(c<<5) + ((c-1)<<3) which is then incorrectly rewritten as
(c + c-1)<<3
This error occurs if both shift counts are simplified expressions in themselves, as in the example above. The expression can be explicit in the source code or the result of previous optimizations. Because of this, there is no effective workaround.
[EWRX-533] Using the _ALIGNOF_ operator causes an internal error.
[EWRX-526] The top half of the result of a 64-bit left shift operation is set to zero when the left operand is known. It affects all optimization levels except -Ol and -On. For example:
a_longlong |= (1ULL<<count);
[EWRX-517, EWRX-532, TPB-2777] On optimization level Medium or High, code between two function calls is incorrectly optimized if
1) the first function call is to a C library function where one of its argument expressions is returned by the function (for example memcpy, memmove, memset, strcat, strncat, strcpy, strncpy, gets, frexp, or modf),
2) the second function call has an identical argument expression as one of its arguments, and
3) the code between the two calls modifies any part of the object that the argument expression refers to.
For example:
memset(&a, 0, sizeof(a)); // returns first argument a.b = 1; // this code is removed foo(&a); // same expression used as argument

3.10.4 2017-08-31

New features

The compiler now supports an unlimited RWPI (position-independent writable data) block size.

3.10.3 2017-06-14

Program corrections

[EW26622] The processor status word (PSW) is not restored correctly for __monitor declared functions that call other functions with stack parameters.
[EW26580] The __ro_placement object attribute does not work correctly for initialized C++ const declared objects under RWPI (position-independent read/write data).

[EW26610] If-else statements setting and clearing the same bit sometimes causes an internal error when inside other control blocks.

3.10.2 2017-05-15

Program corrections

[EW26566] Intermediate values may be overwritten even on low optimization when part of the function is non-returning.

[EW26538] On high optimization, code setting a bit to a conditional value sometimes causes an internal error.

[EW26544] Switch statements sometimes produce incorrect jump tables if they have a fairly large and compact set of case values except a few outliers.

3.10.1 2017-04-20

Program corrections

[EW26246] Some library functions are erroneously flagged as having side-effects and this causes MISRA-C:2012 rule 13.5 to trigger.

New features

C-RUN Runtime analysis
The add-on product C-RUN for runtime analysis is now supported. C-RUN features arithmetic checks, advanced bounds checking, and heap checking. See the C-SPY Debugging Guide for more information.

2.90.4 2016-10-26

Program corrections

[EW26188] An internal error is generated for the expression asm("SETPSW I");

New features

The __ramfunc keyword, which makes a function execute in RAM, can now be used also in big-endian mode.

2.90.1 2016-06-08

Program corrections

[EW26080] The optimizer may in rare cases reuse registers even though they are needed for correct execution.

[EW26087] The compiler requires that absolutely placed variables are declared const when placed in the upper memory range.

[EW25988] The compiler rewrites saturation expressions to use the MAX and MIN instructions, but does not handle long long types causing an internal error.

[EW25956] Under rare circumstances, square operations will be wrong in the 9th mantissa bit (approximately 0.5% too low). This error also affects some of the math library functions.

[EW25923] Shifting a long long variable (64-bit integer) by one step (right or left) can generate erroneous code, if the source and destination registers partially overlap.

[EW25918] Using the stack usage analysis feature with certain code examples might trigger an internal error.

[EW25729] A whitespace-only line in a new style inline assembler statement can cause an internal error in the compiler.

[EW25672] The optimization hoist-out-of-if is done in a memory-dependent order. This might result in different code generated for small compilation environment changes.

2.80.2 2015-08-03

Program corrections

[EW25511] An internal error might be generated due to an error in the labels alignment optimization. It occurs on optimization levels -Oh and -Ohs if --align_func=N is used with N > 2.

[EW25510] Compile result is not the same with same source/compiler options.

[EW25513] The reserved parts of the NMI vector and the option-setting memory are zeroed, but should be all ones.

2.80.1 2015-06-30

Program corrections

[EW25430] The use of the intrinsic function __illegal_opcode() results in an internal error.

[EW25362] Subtracting one pointer from another sometimes causes an internal error.

[EW25298] The compiler optimization technique constant propagation requires an extremely long compile time for certain code examples.

[EW25135] An internal error is sometimes generated after an undefined section error "Error[As010]: Section name expected".

[EW26607] A conditional increment by 1 of a register is removed by the optimizer when including a copy.

New features

DSP intrinsic functions added
Intrinsic functions for DSP multiply-accumulate operations have been added.

2.70.1 2015-02-23

Program corrections

[EW25153] The development guide is using an incorrect interrupt vector table naming.

[EW24936] Stack usage is calculated also for functions that are explicitly listed with the stack usage control directive exclude.

[EW24733] The compiler does not check the MISRA-C:2004 rule 10.6 correctly. It bases the check on the usage of the constant instead of on the type of the constant.

[EW25182] At high optimization, an increment of a pointer by a bit field causes a register variable to be destroyed.

New features

The compiler can now optionally generate both position-independent code and/or position-independent data.
The compiler optimizes for higher execution speed compared to the previous version.
The C/C++ Development Guide, and C-SPY Debugging Guide have been updated to reflect the product changes.

2.60.5 2014-09-05

Program corrections

[EW24945] The compiler will generate an internal error if a char or short variable is saturated. Example:
```
short x;
void restrict_x()
{
  if(x < 12)
    x = 12;
  if(x > 2345)
    x = 2345;
}
```

2.60.4 2014-09-02

Program corrections

[EW24862] Only a NOP instruction is inserted instead of the actual delay loop if you use the intrinsic function __delay_cycles().

[EW24891] Saturation code for short and char was not handled by the compiler and therefore an internal error was generated. Example: short b = c > 0xfff ? 0xfff : c < 0 ? 0 : c;

[EW24918] In rare cases the compiler optimizes two instructions to one by replacing the second instruction with a new one and then removing the first instruction. The error occurs when the new instruction uses a register that has been changed between the original first and second instruction.

2.60.2 2014-06-23

Program corrections

[EW24676] The compiler marks main() as a call graph root. This leads to a warning and that main() stack usage is counted twice.

2.60.1 2014-04-15

Program corrections

[EW24574] Multiplying two long variables into a resulting long long variable will in some cases destroy the contents of the two multiplied variables.

[EW24550] In rare cases, a memory dependency problem in the compiler causes the same project built on two different computers to produce slightly different output. The reason is that a different amount of function inlining is performed by the compiler. The code is functionally correct in both cases.

[EW24390] If arithmetic saturation is implemented and the saturation value is a multiple of two, incorrect code will be generated.
//Example signed int signed_saturate(int i) { if( i > 1<<n-1) //n is 2 to 31 i = 1<<n-1; // causes error if( i < -1<<n) i = -1<<n; // causes error return i; } //Example unsigned unsigned int unsigned_saturate(unsigned int i) { if( i > 1<<n-1) //n is 2 to 31 i = 1<<n-1; // causes error return i; }

New features

Stack usage analysis
With stack usage analysis enabled, a stack usage section will be added to the linker map file with listings of the maximum stack depth for each call graph root. The analysis process can be customized to take into account such constructs as calls via function pointers and recursion. The output can optionally be generated in XML format for post-processing activities.

2.50.1 2013-12-03

New features

RXv2 core support
Support for the new Renesas RXv2 core has been added. The RXv2 core is backward compatible with the RXv1 core, while delivering improved performance and reduced power consumption.

2.42.3 2013-10-18

Program corrections

[EW24030] A problem in the optimizer will in rare cases cause the error CoreUtil/General]: signed not set when optimizing for size.

2.42.2 2013-06-26

Program corrections

[EW23964] Error Pa128 (truncating cast in constant expression) is suppressable in some cases where doing so will result in an internal error.

[EW23959] The combination having a volatile variable that is read but not used together with the common subexpression elimination optimization enabled can in rare cases result in incorrect code being generated.

[EW23958] The error "Error[As025]: Limit exceeded" is in some cases generated when you have objects bigger than 64KBytes.

[EW24015] For function calls where parameters are casted from float to unsigned int or unsigned long, the second parameter in the call can in some cases get an incorrect value.

2.42.1 2013-04-19

Program corrections

[EW23881] At optimization level High, the compiler in some cases moves an ADD instruction to optimize away a compare instruction without checking if the source register is valid for the new location of the ADD instruction.

[EW23856] Expressions including a function-local static variable (v) can be incorrectly optimized (on optimization level High), if v is initialized with a non-zero constant and every assignment to v assigns it another constant.

[EW23755] A function call is in some cases optimized away when using optimization level High, favoring size (-Ohz), and the near data model.

2.41.2 2012-12-13

Program corrections

[EW23598] Two nested loops where both loop variables were used in the same index expression in an array access or pointer indirection, and the variables were of a smaller type than the index type for the array or pointer type, could trigger an internal error.

[EW23638] Reading and writing to the interrupt stack pointer via the intrinsic function _builtin_get_isp() no longer causes an internal error.

New features

New core option for RX100

2.41.1 2012-11-27

New features

Improved Source Browser performance
The Source Browser now consumes less resources, which leads to better performance compared to the previous version.
Improved optimization
The compiler optimizes for higher execution speed compared to the previous version.
Extended inline assembler
The inline assembler has been extended with the possibility to take input arguments, give return values, and read or write to C symbols. The syntax is similar to the syntax used in GNU GCC.

2.40.1 2012-06-01

New features

Support for multiple inheritance
The compiler now supports the C++ feature Multiple inheritance.

Improved optimization
The compiler optimizes both for smaller code size and higher execution speed, compared to the previous version.

Program corrections

[EW23236] When two variables with absolute locations are defined in different modules, the addresses no longer get reversed.

2.30.1 2011-06-28

Program corrections

[EW22505] The total number of errors and warnings presented by the compiler was doubled compared to the real amount.

[EW22504] In an expression on the form u.c[2]=(unsigned char)*p++;, *p was in some cases incorrectly treated as signed.

[EW22445] Under high optimization, a sign extending cast could be removed even when required for correct results.

[EW22389] 32-bit floating point comparisons with zero no longer exclude 0.0 from the expected range if subnormal numbers are disabled.

[EW22985] A struct that was member of another struct, smaller than or equal to 4 bytes and passed as a parameter could in some cases lead to incorrect code and trigger a warning.

2.20.4 2011-04-08

New features

Under high optimization (-Oh or -Ohs) and in combination with the option --align_func=4, performance has been improved by more efficient alignment of internal labels.

Program corrections

[EW22258] The intrinsics __get_interrupt_level() and __set_interrupt_level() operated on bits 24 to bit 26 only and not bit 23.

[EW22267] At optimization level high, MOV.L instead of MOVU.W was sometimes used to copy 16-bit return values into registers which lead to that the high bits were not cleared as required. This has been corrected.

[EW22272] In some cases the compiler instruction scheduler moved instructions over _disable_interrupt() and _enable_interrupt() which is not allowed. This has been corrected.

[EW22287] Calls to functions that return small structs with alignment less than 4 sometimes lead to an internal error in the compiler.

[EW22345] Loops accessing special function registers (SFRs) could be optimized into SMOVF or SSTR instructions, leading to unexpected program behavior because of unpredictable access byte order.

2.20.3 2011-02-01

Program corrections

[EW22172] 8- and 16-bit function parameters and return values were sometimes not properly extended as required by the RX ABI. This has been corrected.

2.20.1 2010-12-20

New features

Position-independent code and data (ropi)
The compiler can now optionally generate position-independent code and position-independent data.

DLIB multithreaded support
The DLIB library now has improved support for threaded environments.

Improved optimization
Code generated for long long, double and floating-point operations is now several times faster compared to the previous version. Some optimizations that are beneficial for benchmark suites like Coremark and Dhrystone have also been implemented but not to the extent that code size grows dramatically and therefore cannot be used in real applications.

Program corrections

[EW21972] Left shift on short and char variables did not cast back the result to the original data types.

[EW21808] Empty switch case bodies could generate an internal error on optimization level low.

2.10.1 2010-06-02

New features

Renesas RX ABI compliance
The IAR compiler, assembler, linker and debugger now comply on C level with Renesas ABI (Application Binary Interface), based on ELF/DWARF. An advantage with this compliance is that modules produced with the Renesas toolchain can be linked with IAR Embedded Workbench for RX.
C99 compliance
The IAR C/C++ Compiler for RX now supports the ISO/IEC 9899:1999 standard.

Program corrections

[EW21599] Returning from an interrupt function could cause undefined behavior if the function used only one register.
[EW21757] An interrupt function that only used one register could generate an illegal instruction, POPM R1,R1.

1.12 2010-01-15

[EW21360] Code generation for string move functions was not correct. This has now been corrected.

1.11 2009-10-05

1.10 2009-05-05

Initial release.