M16C TOOLCHAIN - SOLVED AND KNOWN PROBLEMS

Copyright (c) 2001-2005 Altium BV
Document date: March 10, 2005

This file describes the solved and known problems of version 3.1 revision 1 of the M16C Toolchain.


SOLVED PROBLEMS
KNOWN PROBLEMS
RESTRICTIONS


SOLVED PROBLEMS


Solved in version v3.1r1:
PR31193 (C Compiler): Optimizer problem when a SFR register content is loaded into itself.
PR33185 (Miscellaneous): No umlaut supported in directory/filename in flasher
PR33385 (Install Shield): Remote EVA product has a random @ in the showroom string
PR33406 (Assembler): asm controls don't work properly
PR33460 (C Libraries): malloc/free in the medium memory model don't work with heaps > 64k.
PR33754 (Linker/Locator): Linker gives unrecoverable error when stripping debug info
PR33780 (EDE): #pragma asm conversion bug: truncates long lines
PR33917 (Run Time Libs): _case_* runtime functions don't function properly
PR33925 (C Compiler): complement operator for __bit and _Bool generates wrong code
PR33962 (C Compiler): Internal error in powersupply.cpp
PR33998 (C Compiler): compiler takes over an hour for example - and allocates over 800M
PR34016 (Simulator): Simulator does not set/clear overflow flag for rmpa instruction
PR34044 (C Compiler): internal consistency check failed on intrinsic __reit()
PR34045 (C Compiler): case values > 0x8000 lead to error from assembler
PR34050 (Simulator): Simulator loops forever on cstart code for M16C/6P processor
PR34053 (C Compiler): long long shift: both compiler and simulator do it incorrectly
PR34058 (C Compiler): incorrect code generated for passing 2-valued enum as parameter
PR34062 (C Compiler): internal consistency check failed on implicit array to integer cast

Solved in version v3.0r1p3:
PR33489 (C Compiler): Compiler generates illegal code for shifting a long
PR33514 (CrossView): Crossview can't debug properly when USP is used as stackpointer
PR33515 (C Compiler): Incorrect code generate for returning carry. Incorrectly simulated.
PR33547 (C Compiler): Compiler generates endless loop for struct copy
PR33548 (C Compiler): Internal error on example
PR33558 (C Compiler): The __frame() unknown register names should give an error.
PR33583 (Linker/Locator): The Misra C report from the linker does not work
PR33661 (C Libraries): libc can not be rebuild due to files missing
PR33665 (Linker/Locator): lkm16c runs forever on example
PR33681 (Assembler): Linker fails with S602: assembler generates illegal relocation
PR33690 (C Compiler): Internal consistency check failed on switch() statement
PR33724 (C Compiler): Incorrect code generated for c99 variable length arrays
PR33725 (Archiver): arm16c crashes when putting a source file in an achive
PR33736 (C Compiler): Invalid code generated for struct members of a link list
PR33767 (C Compiler): Compiler produces illegal assembly pusha [a0]

Solved in version v3.0r1p2:
PR33398 (Assembler): Escapes in strings don't work
PR33430 (ROM/RAM Monitor): FoUSB does not work properly
PR33450 (Simulator): stc isp, X is simulated as stc sp, X
PR33465 (EDE): Project->Properties->Directories->Working Directory setting is overwritten
PR33471 (C Compiler): Struct copies of 3 and 5 bytes and nested structs generate incorrect code.

Solved in version v3.0r1p1:
PR33372 (C Compiler): __bankswitch destroys FB register
PR33395 (C Compiler): incorrect code generated for odd-sized struct copy
PR33414 (CrossView): Crossview can't debug local c++ variables
PR33422 (C++ frontend): C++ has __size_t wrongly defined for large memory model
PR33428 (Run Time Libs): Printf prints garbage if vsprintf is linked

Solved in version v3.0r1:
PR22391 (C Compiler): _bit structures are not allowed
PR22429 (C Compiler): compiler should give error on possible programmers error
PR22794 (Miscellaneous): 'broken file' error for absolute files downloaded to Mitsubishi PD30 emulator
PR22917 (Assembler): improve error message on instructions with missing size specifier
PR30309 (Assembler): compiler generates debug information for label that is optimized away.
PR30427 (C Compiler): missing intrinsic functions for BTSTC and BTSTS instructions
PR30547 (C Compiler): volatile variable assignment optimized away by compiler
PR30565 (C Compiler): compiler generates lifetime info but skips corresponding identifier info
PR30610 (C Compiler): compiler optimisation request for bit inversion
PR30611 (C Compiler): optimisation request for long value assignment
PR30716 (C Compiler): result of compare between indirect float and long is incorrect
PR30718 (C Compiler): dereferenced function return value used as function argument is incorrect
PR30723 (C Compiler): In some cases using -A will cause incorrect bitfield in struct behaviour
PR30724 (C Compiler): when using structured bitfield assignments in functions the result is incorrect
PR30790 (C++ Compiler): incorrect C++ error
PR31098 (C++ Compiler): _I and other predefined values not supported in C++
PR31173 (CrossView): Crossview gives 'illegal digit in octal number' on file starting with '0' char
PR31270 (Locator): Generate warning on overlapping absolute sections
PR31295 (C Compiler): unable to watch void pointer types in Crossview Pro
PR31297 (CrossView): struct variable not shown correctly in watch window
PR31482 (Locator): allow option to show total of used RAM/ROM
PR31524 (C Compiler): Add a #pragma defaultsect
PR31529 (C Compiler): initialized function pointer is placed in ROM when 'keep strings in ROM' is used
PR31683 (C Compiler): incorrect code generated when using dereferencing a post/pre incremented pointer
PR31856 (C Compiler): In some cases the compiler uses stack as an intermediate when copying structs
PR31881 (C Compiler): Assertion error S003
PR31950 (C Compiler): compiler incorrectly optimizes variable access
PR31981 (C Compiler): compiler generates incorrect type information for pointer to an enumrate type
PR31983 (C Compiler): incorrect code generated for _ldc_sp() parameter
PR32030 (Assembler): Assembler does not support A0 and A1 as argument to DIV.B, DIVX.B and DIVU.B
PR32070 (C++ Compiler): Mix C++ code in assembler list file
PR32098 (C Compiler): unable to watch pointer in Crossview Pro
PR32193 (C Compiler): pragma optimize b does not work
PR32245 (EDE): Changing reset vector and/or fixed vector table causes locator error
PR32278 (C Compiler): incorrect code generated for float/array union swap function
PR32579 (EDE): allow user defined startup function to be called before _init
PR32587 (C Compiler): shifting SFR bit results in assertion
PR32618 (Compiler Manual): The __lc_b example in chapter 10.7.1 is wrong
PR32685 (C Compiler): Compiler S320 on example using short variables
PR32688 (Locator): reserved area is removed when absolute section overlaps
PR32760 (CrossView): Crossview can't show local static variable
PR32849 (Simulator): Generic move instruction incorrectly simulated
PR33061 (EDE): Add sfr's for m16c/26a, m16c/28, m16c/29 processor families
PR33190 (EDE): Support R8C/14, R8C/15, R8C/16, R8C/17
PR33230 (CrossView): With the 'call;return->jump' on, cumulative profiling does not work
PR33231 (EDE): 626p derivative support can be improved
PR33239 (Miscellaneous): __sfr in v30 means something else then in v2.3
PR33242 (Assembler): bsbit only initializes the first bit
PR33243 (CrossView): TCP/IP settings don't work in crossview for rom monitor
PR33244 (C examples): Makefiles for examples and rom monitors are missing or not working
PR33245 (ROM/RAM Monitor): Add rom monitor and examples for Glyn/USB and Glyn/26
PR33250 (C Compiler): __asmfunc should have a proper defined calling convention
PR33310 (C Compiler): S900 in indirect function call
PR33311 (C Compiler): Compiler crash with tailmerging
PR33362 (C Libraries): Stack alignment in stdarg.h va_start incorrect.
PR33363 (C Compiler): volatile read incorrectly optimized away


SOLVED PR22391: _bit structures are not allowed
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
_bit structures are currently not allowed.


SOLVED PR22429: compiler should give error on possible programmers error
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
In certain cases a user programming error leads to an invalid
instruction being generated. The compiler could detect this
fault and give an error instead of generating the invalid
instruction (see PR22414).

EXAMPLE:
void main( void )
{
    char a[2];

    a[2] = 1;  /* a[2] is out of array scope and
                  might result in the instruction MOV [FB],...
                  being generated, this instruction is invalid
                  since it must always have a displacement => 0[FB] */
}


SOLVED PR22794: 'broken file' error for absolute files downloaded to Mitsubishi PD30 emulator
Component: Miscellaneous
Solved in: v3.0r1

DESCRIPTION:
When downloading an absolute file to the Mitsubishi PD30 debugger,
it may give a 'broken file' error. This is caused by the PD30 debugger
not being able to handle debug info for local assembler labels.

WORKAROUND:
Disable the generation of local assembler labels. In EDE go to the
EDE | Assembler Options | Object tab. Uncheck the option 'HLL debug when
available, otherwise assembly level debug', also make sure that the
option 'Assembler local symbols information' is unchecked. Rebuilding
the project then should solve the problem.


SOLVED PR22917: improve error message on instructions with missing size specifier
Component: Assembler
Solved in: v3.0r1

DESCRIPTION:
When a size specifier is forgotten on an instruction the assembler will
give an 'unknown mnemonic' error. Instead it would be more helpfull if
the error tells that only the size specifier is missing.

EXAMPLE:
    CSEG AT 0E0000H

    ADJNZ #-1,R0,_label    ; => will trigger 'unknown mnemonic' error
                           ; although the mnemonic is known but only
                           ; the specifier is forgotten! (should be ADJNZ.W)
_label:
    END


SOLVED PR30309: compiler generates debug information for label that is optimized away.
Component: Assembler
Solved in: v3.0r1

DESCRIPTION:
When the following example is compiled using no optimization. The compiler
still optimizes away the goto label. However debug information is generated
for that label, this causes the assembler to trigger an error.

compile with -O0 -g

EXAMPLE:
int main( void )
{
    int status = 0;

    if ( status != 0 )
    {
        goto exception;
    }
exception:

    return status;
}

WORKAROUND:
Use optimization for this case.


SOLVED PR30427: missing intrinsic functions for BTSTC and BTSTS instructions
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
In the list of intrinsic functions the functions for the BTSTC and the
BTSTS instructions are missing. These could come in handy when defining
a semaphore.



SOLVED PR30547: volatile variable assignment optimized away by compiler
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
The compiler sometimes optimizes accesses to volatile variables, which
is incorrect.

EXAMPLE:
volatile unsigned char x;

void main( void )
{
    unsigned char tmp;
    tmp = x;   /* incorrectly optimised away */
}



SOLVED PR30565: compiler generates lifetime info but skips corresponding identifier info
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
In certain cases when compiling with debug information (-g), the compiler skips generating identifier info, butstill generates lifetime info for a variable. This will cause the
assembler to generate E287, unknown LTIM identifier.


EXAMPLE:
typdef struct
{
    int x0;
    int x1;
} t_str;

void f( char *s, int x )
{
    t_str r1;
    t_str r2;
    int n = 0;
    int loc;

    for ( ;;n++ )
    {
        if ( s )
        {
            break;
        }
    }

    {
         int x1;
         switch ( x );
         {
         case 0:
             xl = x1.r1;
         }
         r2.x0 = xl;
    }
}


WORKAROUND:
Compile with -gl instead of -g
Initialize variable xl, or add a 'default' case.


SOLVED PR30610: compiler optimisation request for bit inversion
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
The compiler could use a single instruction on the following example:
   bitx = !bitx;   =>   bnot  bitx



SOLVED PR30611: optimisation request for long value assignment
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
The compiler could use less instruction on the following example:

_sfrlong longsfr;
unsigned char tbl[] = { 1,2,3,4 };

void f( void )
{
   longsfr = tbl[0];
}


SOLVED PR30716: result of compare between indirect float and long is incorrect
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
The following code results in an incorrect boolean result value

static float f2 = 1.2;
auto float * pf2 = &f2;
auto long stlong = 8;
int res = stlong8 < *pf2;

------------
res = 1 instead of 0

Compile with -O0
This error not only occurs when comparing longs but also unsigned chars and other types.

EXAMPLE:
int main()
{
static float f2 = 1.2;
auto float * pf2 = &f2;
auto long stlong = 8;
int res = stlong < *pf2;
return res;
}

WORKAROUND:
Compile with -O1 or with -O3

or

move the long value to a float variable and compare using this float value
e.g.

int main()
{
static float f2 = 1.2;
auto float * pf2 = &f2;
auto long stlong = 8;
float f1 = stlong;
int res = f1 < *pf2;
return res;
}


SOLVED PR30718: dereferenced function return value used as function argument is incorrect
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
dereferenced function return value used as function argument in combination with post- decrement/increment results in an incorrect value

EXAMPLE:
void equals(int x, int y) /*the x value is invalid*/
{
}

int* f(void)
{
static int a = 9;
return &a;
}

void main(void)
{
equals((*f()) --, 9);
}

WORKAROUND:
decrement value after calling the function
e.g.

equals(*f(), 9);
*f()--;



SOLVED PR30723: In some cases using -A will cause incorrect bitfield in struct behaviour
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
In some cases using -A will cause incorrect bitfield in struct behaviour

EXAMPLE:
struct fields
{
unsigned x1:1;
unsigned x2:2;
unsigned x3:3;
unsigned :1;
unsigned x4:4;
} b, *p = &b;

void main(void)
{
b.x1 = 1;
b.x2 = p->x3 = b.x4 = 0;
}

WORKAROUND:
Don't compile with -A(0)

or

seperate the assignment of 0, like
b.x2 = 0;
p->x3 = 0;
b.x4 = 0;



SOLVED PR30724: when using structured bitfield assignments in functions the result is incorrect
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
When assigning a value to a bitfield of a structure in a function this results in an incorrect value

EXAMPLE:
The following example was compiled with -O0  and -A

struct fields
{
unsigned x1:1;
unsigned x2:2;
unsigned x3:3;
unsigned :1;
unsigned x4:4;
} b, *p = &b;

void f(int x){}

void main
{
b.x3 = 7;
b.x2 = 2;
f(p->x3 *= b.x2
);
}/* the function f gets the wrong value as an argument, 14 instead of 6*/

WORKAROUND:
before calling function f, do the multiply and assigment

e.g.

p->x3 *= b.x2;
f(p->x3);


SOLVED PR30790: incorrect C++ error
Component: C++ Compiler
Solved in: v3.0r1

DESCRIPTION:
Selecting 'issue warnings for non ansi features' under the c++ compiler tab c gives a message saying that this mode is incompatible with TASKING embedded. I have not got the EC++ compliance tick box checked.



SOLVED PR31098: _I and other predefined values not supported in C++
Component: C++ Compiler
Solved in: v3.0r1

DESCRIPTION:
Macro "_I" used in following line is undefined in C++ mode.

_fset(_I);   /* Enable interrupt */



WORKAROUND:
Use the corresponding value directly.


SOLVED PR31173: Crossview gives 'illegal digit in octal number' on file starting with '0' char
Component: CrossView
Solved in: v3.0r1

DESCRIPTION:
When CrossView tries to load a file with a leading zero it assumes that it's
an octal value and generated the error message: illegal digit in octal number.



SOLVED PR31193: Optimizer problem when a SFR register content is loaded into itself.
Component: C Compiler
Solved in: v3.1r1

DESCRIPTION:
Optimizer problem when a SFR register content is loaded into itself. Since SFRs should be treated as volatile the compiler must generate code for the line:
P4 = P4;

But it doesn't. Also when all optimizations are switched off it does not work.

EXAMPLE:
P4 = P4

WORKAROUND:
A workaround is to use a pointer dereference like:

P4 = *(_near volatile unsigned char *) 0x3E8;        // SFR P4 is located at address 03E8H



SOLVED PR31270: Generate warning on overlapping absolute sections
Component: Locator
Solved in: v3.0r1

DESCRIPTION:
When absolute sections overlap the locator should at least give some warning.



SOLVED PR31295: unable to watch void pointer types in Crossview Pro
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
It is not possible to load a variable declared using an undefined struct in the debugger, it will result in an error message that a void type can not be loaded.

EXAMPLE:
--------------------------------------------
Module 1:
--------------------------------------------
extern void foo(void);
struct t_str
{
    int x;
}
void main( void )
{
  foo();
}
--------------------------------------------
Module 2:
--------------------------------------------
/*
* debug info generated for variable 'var' will
* be incomplete, resulting in a Crossview
* error when trying to watch it.
*/
struct t_str *var;
void foo(void)
{
    p = var;
}



SOLVED PR31297: struct variable not shown correctly in watch window
Component: CrossView
Solved in: v3.0r1

DESCRIPTION:
A struct containing bitfields is not displayed correctly in the data window.
On double click or hoovering of the mouse pointer over it, it is
shown correctly.


EXAMPLE:
class cx1
{
public:
    unsigned char a1 : 1;
    unsigned char a2 : 1;
    unsigned char a3 : 1;
    unsigned char a4 : 1;
    unsigned char h  : 1;
    unsigned char w  : 1;
};

class cx2
{
public:
   cx1 x1;
   cx1 x2;

   cx2(){}
};

cx2 test;  /* variable 'test' is not displayed correctly in the watch window */

void main( void )
{
    test.x1.a1 = 1;
    _nop();
    _nop();
}


SOLVED PR31482: allow option to show total of used RAM/ROM
Component: Locator
Solved in: v3.0r1

DESCRIPTION:
Allow a feature to get the total amount of ROM/RAM used for a project.
Currently this has to be calculated manually from the map file.


SOLVED PR31524: Add a #pragma defaultsect
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
Add a #pragma defaultsect to switch back to the default section names. I.e.

#pragma renamesect FD=myfardata

_far int my_i;

#pragma defaultsect

_far int i;




WORKAROUND:
Use the same name in the #pragma renamesect as the compiler would generate by default.



SOLVED PR31529: initialized function pointer is placed in ROM when 'keep strings in ROM' is used
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
When using an initialized function pointer and the 'keep strings in ROM' option
is enabled, the function pointer is also placed in ROM.

EXAMPLE:
typedef void (*t_fptr)( void );

t_fptr func = 0;


WORKAROUND:
Do not use an initialized function pointer, but instead initialize
it in for instance the 'main()' function.



SOLVED PR31683: incorrect code generated when using dereferencing a post/pre incremented pointer
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
incorrect code generated when using dereferencing a post/pre incremented pointer

EXAMPLE:
char p[5] = {1};
char *s = p;

void main(void)
{
*++s = 2;
if (*s != 2)
}

WORKAROUND:
turn of cse optimisation using -OC
or
split *++s into s++; and *s =




SOLVED PR31856: In some cases the compiler uses stack as an intermediate when copying structs
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
In some cases the compiler uses stack as an intermediate when copying structs. This is however not necessary in case of global struct in the same space and can be done in one time.



EXAMPLE:
TestStrukt X;
TestStrukt Y[3];

X.D = Y[i].D

WORKAROUND:
Use memcpy or
use a constant so X.D = Y[i].D becomes X.D = Y[2].D for example.


SOLVED PR31881: Assertion error S003
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
In some cases the compiler may generate assertion error S003.

WORKAROUND:
turn of CSE optimisation with -OC or -OE to turn off expression propagation


SOLVED PR31950: compiler incorrectly optimizes variable access
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
In the following example the compiler incorrectly optimizes away access
to the bitbyted variable.



EXAMPLE:
unsigned char sc_1;

_bit sc_10 _atbit(sc_1, 0);
_bit sc_11 _atbit(sc_1, 1);
_bit sc_12 _atbit(sc_1, 2);
_bit sc_13 _atbit(sc_1, 3);
_bit sc_14 _atbit(sc_1, 4);

void func_1(void)
{
    sc_1 = 0x12;

    sc_10 = 1, sc_12 = 1, sc_14 = 1; // sc_1 content now 0x15

// the compiler does not notice that the sc_1 content has changed because of
// the bit modifications and optimizes the if case irregulary away
    if(sc_1 == 0x17)
        sc_1 = 0x34;
}


WORKAROUND:
Make the sc_1 variable volatile.



SOLVED PR31981: compiler generates incorrect type information for pointer to an enumrate type
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
For a function having a pointer to an enumerate type as parameter
the compiler generates incorrect type info. Instead of using
the enumeration type as pointer type an 'int' type is used.

In case of an external function call the correct type info is
used, this results in W112 from the linker (type conflict for
symbol <_f>).


EXAMPLE:
=================================================================
test1.c
=================================================================
typedef enum
{
    RED
} t_color;

void f( t_color *ptr );  /* correct info for this external */
t_color color;

void main( void )
{
    f( &color );
}

=================================================================
test2.c
=================================================================
typedef enum
{
    RED
} t_color;

void f( t_color *ptr )  /* incorrect info for this definition */
{
    ptr = ptr;
}



SOLVED PR31983: incorrect code generated for _ldc_sp() parameter
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
In the small memory model the compiler generates incorrect code for
a struct parameter used in the _ldc_sp().


EXAMPLE:
An expression like:

struct somestruct
{
    unsigned int * iptr0;
    unsigned char c;
    unsigned int i;
    unsigned int * iptr1;
};

struct somestruct foo;
struct somestruct * psomestruct=&foo;

...
some_func()
{
...
_ldc_sp((unsigned int) *(psomestruct->iptr0));
...
}

results in:

; demo.c    103     _ldc_sp((unsigned int) *(psomestruct->iptr0));
SYMB LINE, 103
mov.w _psomestruct,A0
mov.w [A0],A0
mov.w [A0],A0 ; --------> That's one MOV too much !
ldc A0,sp

The double move causes a wrong value in the register and subsequently false
content of the stack pointer.



SOLVED PR32030: Assembler does not support A0 and A1 as argument to DIV.B, DIVX.B and DIVU.B
Component: Assembler
Solved in: v3.0r1

DESCRIPTION:
Assembler does not support A0 and A1 as argument to DIV.B, DIVX .B and DIVU.B

EXAMPLE:
DIV.B A0 is not accepted by the assembler. Same for DIVU.B and DIVX.B


SOLVED PR32070: Mix C++ code in assembler list file
Component: C++ Compiler
Solved in: v3.0r1

DESCRIPTION:
It would be quite helpfull to know which assembly code corresponds
with which C++ code.



SOLVED PR32098: unable to watch pointer in Crossview Pro
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
When watching pointer "p" from function "foo" with CrossView, it will result in an error message that a void type can not be loaded. The example code was generated by our C++ compiler.




EXAMPLE:
--------------------------------------------
Module 1:
--------------------------------------------
extern void foo(void);
struct t_str
{
    int x;
}
void main( void )
{
  foo();
}
--------------------------------------------
Module 2:
--------------------------------------------
/*
* debug info generated for variable 'var' will
* be incomplete, resulting in a Crossview
* error when trying to watch it.
*/
struct t_str *var;
void foo(void)
{
    p = var;
}



SOLVED PR32193: pragma optimize b does not work
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
Pragma optimize b does not work. Only -Ob on the command line works


EXAMPLE:
#pragma optimize b

int i;

#pragma optimize B


SOLVED PR32245: Changing reset vector and/or fixed vector table causes locator error
Component: EDE
Solved in: v3.0r1

DESCRIPTION:
When trying to locate the reset vector and the fixed interrupt vector table
on an absolute address but the locator exits with the following error messages:

Locating glyn62serial.out to glyn62serial.abs (IEEE-695)
lcm16 W142 (2): No room for section .reset in read-only memory, trying    
            writable memory ...
lcm16 E200 (0): Absolute address 0xefffc occupied                        
lcm16 W142 (2): No room for section .fvectab in read-only memory, trying  
            writable memory ...
lcm16 E200 (0): Absolute address 0xeffdc occupied                        



SOLVED PR32278: incorrect code generated for float/array union swap function
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
In the following example incorrect code is being generated
for the swap function. Apparently the wrong registers are
being used.

EXAMPLE:
float f( float val )
{
    union
    {
        float f;
        unsigned char arr[4];
    } un;
    un.f = val;
    temp = un.arr[0];
    un.arr[0] = un.arr[3];
    un.arr[3] = temp;
    temp = un.arr[1];
    un.arr[1] = un.arr[2];
    un.arr[2] = temp;
    return un.f;
}



SOLVED PR32579: allow user defined startup function to be called before _init
Component: EDE
Solved in: v3.0r1

DESCRIPTION:
It may be required to do some initialization of external memory mapped I/O
devices which must be done pretty soon after the program start after reset.
Since the variable initialization/clear loop of the startup code can take
quite some time it is necessary to do the initialization of the external
devices before. Therefore it would be helpful to introduce a feature like
'call this function before variable initialization/clearance' where the user
can fill in a C function name with a leading underscore and this C function
is then called automatically by the startup code before the variable
initialization using a jsr _C_function_name



SOLVED PR32587: shifting SFR bit results in assertion
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
When a SFR bit is shifted the compiler asserts with S320.


EXAMPLE:
/*
* cm16 main2.c -gn -s -Cm306nx
*   results in:
* cm16 S320: "main2.c" line 6: assertion failed - please report
*/

unsigned char x;

void main( void )
{
    x = P3_1 << 1;
}



SOLVED PR32618: The __lc_b example in chapter 10.7.1 is wrong
Component: Compiler Manual
Solved in: v3.0r1

DESCRIPTION:
The example for __lc_b_section, __lc_e_section in chapter
10.7.1 LOCATOR LABELS REFERENCE is wrong. In the printf line:

printf( "Text size is 0x%x\n",
     _lc_e__text - _lc_b__text );

is an additional underscore used which makes the compiler complain. Correct is:

printf( "Text size is 0x%x\n",
     _lc_e_text - _lc_b_text );

Furthermore the arrays could be declared _far to make the example work in the Small
Memory Model too.




SOLVED PR32685: Compiler S320 on example using short variables
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
The following examples triggers a compiler assertion S320.


EXAMPLE:
void f( void )
{
    unsigned short i;
    unsigned short prev;

    for ( i=130; i--; )
    {
        prev = 44444 * prev;
    }
}

WORKAROUND:
Use 'int' instead of short.


SOLVED PR32688: reserved area is removed when absolute section overlaps
Component: Locator
Solved in: v3.0r1

DESCRIPTION:
When the _at keyword is used to locate a constant into a reserved area, the reserved
area is not reserved anymore which allows the locator to place other, non absolute
sections into this range too.



SOLVED PR32760: Crossview can't show local static variable
Component: CrossView
Solved in: v3.0r1

DESCRIPTION:
Crossview can't show local static variable, even though debug info is
generated for the variable.


EXAMPLE:
float f1;

void main( void )
{
    volatile static float vsf_var = 1.1234;

    vsf_var = 10.8;

    f1 = vsf_var;
}


SOLVED PR32849: Generic move instruction incorrectly simulated
Component: Simulator
Solved in: v3.0r1

DESCRIPTION:
The customer reported that the generic move instruction:
MOV.B:G #0xFF, A0


leads to a wrong result in our simulator debugger.
Testcase attached.


EXAMPLE:
mov.w #-1,a0
mov.b #0xff,a0
tst.w #0xff00,a0
bz  error

WORKAROUND:
Use mov.w instead of mov.w
Or use mov.b:q #-1, a0 if possible.
Ore use "and.b #0xff,a0" afterwards for the zero-extention.


SOLVED PR33061: Add sfr's for m16c/26a, m16c/28, m16c/29 processor families
Component: EDE
Solved in: v3.0r1

DESCRIPTION:
The m16c processor families
  m16c/26a
  m16c/28
  m16c/29
Are not yet supported in m16c v30rb







SOLVED PR33185: No umlaut supported in directory/filename in flasher
Component: Miscellaneous
Solved in: v3.1r1

DESCRIPTION:
When trying to flash the application with an umlaut in path/filename the flasher proceeds up to "Parsingfile: .\zero3.abs" and then exits ungracefully.



WORKAROUND:
Don't use umlauts in path/filenames


SOLVED PR33190: Support R8C/14, R8C/15, R8C/16, R8C/17
Component: EDE
Solved in: v3.0r1

DESCRIPTION:
Support new R8C derivitives:
R8C/14, R8C/15, R8C/16, R8C/17
See http://www.renesas.com/eng/products/mpumcu/16bit/m16c/dsum/r8cdsume.html


SOLVED PR33230: With the 'call;return->jump' on, cumulative profiling does not work
Component: CrossView
Solved in: v3.0r1

DESCRIPTION:
Selecting a function for which the compiler optimization -Oz has replaced a 'call func;return' sequence by a 'jump func' instruction results in an error message:
Internal error: run-time support function "CpuIsFunctionExitPoint" is not implemented.
"The exit points of function main could not be determined"
Crossview should recognize a jump to an address outside the function as an exit point.



WORKAROUND:
Disable call;return->jump optimization, eg by choosing 'debug purpose' in EDE | projcet options | compiler | optimizations.


SOLVED PR33231: 626p derivative support can be improved
Component: EDE
Solved in: v3.0r1

DESCRIPTION:
- The startup code should use the undocumented PLC03 bit instead of a wait loop.
- EDE | Project options | startup code | SFR's | system clock
    should include the PLL clock.
- The glyn m30626 board has a 12 MHz XTAL ( as opposed to the 3DK/ 6MHz)
   Thus it runs on PLLx2. The PLL change however is hardcoded.



SOLVED PR33239: __sfr in v30 means something else then in v2.3
Component: Miscellaneous
Solved in: v3.0r1

DESCRIPTION:
In v30, __sfr declared variables define storage, just like other variables.
In v2.3 however, this was not the case.
v2.3 projects with __sfr's should be properly converted by the conversion tool.


SOLVED PR33242: bsbit only initializes the first bit
Component: Assembler
Solved in: v3.0r1

DESCRIPTION:
For 'bsbit 3,1', three bits are allocated, but only one bit is initialized.


SOLVED PR33243: TCP/IP settings don't work in crossview for rom monitor
Component: CrossView
Solved in: v3.0r1

DESCRIPTION:
The settings for TCP/IP don't show up in the communications dialog, although the rommonitor debug instrument supports it.


SOLVED PR33244: Makefiles for examples and rom monitors are missing or not working
Component: C examples
Solved in: v3.0r1

DESCRIPTION:
Add working makefiles for the examples and rommonitors.


SOLVED PR33245: Add rom monitor and examples for Glyn/USB and Glyn/26
Component: ROM/RAM Monitor
Solved in: v3.0r1

DESCRIPTION:
Add rom monitor and examples for Glyn/USB and Glyn/26.


SOLVED PR33250: __asmfunc should have a proper defined calling convention
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
__asmfunc now uses the default calling convention.
It should get its own, probably just like v2.3r2.
Stack parameters should be forbidden.



SOLVED PR33310: S900 in indirect function call
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
Assertion in register allocator.
Indirect function call with full parameters and a __far load of the function pointer.


EXAMPLE:
typedef void (*LCD_CLEARXY)      (int x, int y,int breite,int hoehe);typedef const struct LCD_OBJ {  LCD_CLEARXY        clearxy;} LCD_OBJ;int bub = 0;void clearxy(int x, int y,int breite,int hoehe){    bub += x + y + breite + hoehe;}LCD_OBJ obj = {clearxy};LCD_OBJ *LcdGetObj(void){    return &obj;}void LcdClearXY(void){    LCD_OBJ *o = LcdGetObj();        o->clearxy(1,2,3,4);}int main(void){    LcdClearXY();    if (bub != 10)        return 1;    return 0;}

WORKAROUND:
Use -OA.


SOLVED PR33311: Compiler crash with tailmerging
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
This example crashes the compiler

EXAMPLE:
typedef enum {OFF = 0, ON = 1} SWITCH;
typedef enum { UART1, UART2 } UART;

SWITCH  UartGetCTS(UART uart)
{
        switch (uart) {
        case UART1:
                return ON;
                break;
        case UART2:
                return ON;
                break;
        default:
                break;
        }

}



SOLVED PR33362: Stack alignment in stdarg.h va_start incorrect.
Component: C Libraries
Solved in: v3.0r1

DESCRIPTION:
------------------------------------------
1) In stdarg.h the macros

#define va_start(ap,last) (ap[0] = ((char *)&last + (sizeof(last) + 1 & ~ 1u)))

va_start aligns the address of the next element to 2, while the compiler does not appear to do such an aligment.  


SOLVED PR33363: volatile read incorrectly optimized away
Component: C Compiler
Solved in: v3.0r1

DESCRIPTION:
The customer detected an optimizer problem. The attached testcase shows that the compiler removes the access to a SFR register which is not allowed since SFR register should be treated volatile. However the compiler may remove the write access to the local variable 'bdummy' since this variable is not needed/used later on.


EXAMPLE:
/* * Compile with: ccm16 -Cm16c62p -tmp -o testsfr testsfr.c */
static volatile    unsigned char    buf;

int main(int argc, char **argv)
{
    unsigned char    bdummy;
    unsigned char    status = U1RBH;  

    if (status & 0x60U)
    {    
         /* THIS ACCESS TO U1RBL WILL BE WRONLGY OPTIMIZED AWAY!!! */    
         bdummy = U1RBL;    
         return 1;
    }
    else
    {
        buf = U1RBL;
    }
    return 0;
}


SOLVED PR33372: __bankswitch destroys FB register
Component: C Compiler
Solved in: v3.0r1p1

DESCRIPTION:
2.) Error if an interrupt-Routine is used with the qualifier __bankswitch

If an interrupt-Routine is used with the qualifier __bankswitch
at the end of the routine, just in front of the RETI command an additionally
POPC FB, before the "fclr B". This means the FB from the wrong bank is restored.



Please inform me on which way I can have a work around for the 2 problems.


EXAMPLE:
int i,j;

void __bankswitch __interrupt(0) isr(void)
{
    int arr[5];

    for (int k=0; i<5; i++)
    {
        arr[k] += j;
    }
    for (int k=0; i<5; i++)
    {
        i *= arr[k];
    }
}


int main(void)
{
    int bub[10] = {5};

    __int(0);
    
    if (bub[0] != 5)
        return 1;
    return 0;
}



SOLVED PR33385: Remote EVA product has a random @ in the showroom string
Component: Install Shield
Solved in: v3.1r1

DESCRIPTION:
Remote EVA product has a random @ in the showroom string


SOLVED PR33395: incorrect code generated for odd-sized struct copy
Component: C Compiler
Solved in: v3.0r1p1

DESCRIPTION:
The new version 3.0 rb1 generates a code, which is not correct
If an odd number of bytes should be copied from one RAM area to an other,
then the generated code is not correct.

I have two different results:
1.)
21 Bytes should be copied. Then the routine starts at the end of the area
and copies 1 byte. But the source it uses is not the end of the block (3
Byte before the end). The other 20 Bytes are copied with word instructions.

2.)
3 Bytes should be copied.
In this module cocofu functions are generated. And instead of 3 Bytes, 2
Words are copied.

In the 1.) case the last Byte of the copied area is not correct.
In the 2.) case 1 byte behind the copied area is destroyed.



EXAMPLE:
// -Ml for 2nd bug.


typedef struct even_s
{
    unsigned char x[20];
} even_t;

typedef struct odd_s
{
    unsigned char x[21];
} odd_t;

typedef struct embed_s
{
    unsigned int pre;
    even_t even;
    unsigned int middle;
    odd_t odd;
    unsigned int post;
} embed_t;

embed_t embed = {0xabcd,
         {{2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21}},
         0xabcd,
         {{23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43}},
         0xabcd};

embed_t e2 = {0xdcba,
          {{52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71}},
          0xdcba,
          {{73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93}},
          0xdcba};
embed_t e3 = {0xfedc,
          {{102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121}},
          0xfedc,
          {{123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143}},
          0xfedc};

//define __noinline        /* to test with eg gcc define __noinline away*/

int __noinline check_embed(embed_t *o)
{
    int i;

    if (o->pre != 1)
        return 1;
    if (o->middle != 22)
        return 2;
    if (o->post != 44)
        return 3;
    
    for (i=1; i<20; i++)
        if (o->even.x[i] != i+2)
            return 0x100 | i;

    for (i=1; i<21; i++)
        if (o->odd.x[i] != i+23)
            return 0x200 | i;
    return 0;
}

even_t __noinline func_even(even_t e)
{
    return e;
}

odd_t __noinline func_odd(odd_t e)
{
    return e;
}

int main(void)
{
    e2.even = func_even(embed.even);
    if (e2.pre != 0xdcba)
        return 1;
    if (e2.middle != 0xdcba)
        return 2;
    if (e2.post != 0xdcba)
        return 3;

    e2.odd = func_odd(embed.odd);
    if (e2.pre != 0xdcba)
        return 4;
    if (e2.middle != 0xdcba)
        return 5;
    if (e2.post != 0xdcba)
        return 6;

    e2.pre = 1; e2.middle = 22; e2.post = 44;
    if (check_embed(&e2))
        return check_embed(&e2);

    e3.even = e2.even;
    if (e3.pre != 0xfedc)
        return 8;
    if (e3.middle != 0xfedc)
        return 9;
    if (e3.post != 0xfedc)
        return 10;

    e3.odd = e2.odd;
    if (e3.pre != 0xfedc)
        return 11;
    if (e3.middle != 0xfedc)
        return 12;
    if (e3.post != 0xfedc)
        return 13;
    
    e3.pre = 1; e3.middle = 22; e3.post = 44;
    if (check_embed(&e3))
        return 14;
    
    return 0;
}

    


WORKAROUND:
Use even sized structs, this also yields better code.


SOLVED PR33398: Escapes in strings don't work
Component: Assembler
Solved in: v3.0r1p2

DESCRIPTION:
Escaping with '\' in strings in the assembler does not work. The '\' are copied verbatim.



SOLVED PR33406: asm controls don't work properly
Component: Assembler
Solved in: v3.1r1

DESCRIPTION:
$title "TITLE"
asm16c E118: ["e.src" 11] expected identifier



SOLVED PR33414: Crossview can't debug local c++ variables
Component: CrossView
Solved in: v3.0r1p1

DESCRIPTION:
The customer detected that no debug information is generated for local variables when a C++ project is used. Testcase attached. When the .cpp file is renamed to a .c file and added to the project instead it works OK.




SOLVED PR33422: C++ has __size_t wrongly defined for large memory model
Component: C++ frontend
Solved in: v3.0r1p1

DESCRIPTION:
In C++, __size_t is always unsigned int.
In the large memory model, it should be unsigned long.
This, among other things, cause c library function calls involving size_t arguments to fail.



SOLVED PR33428: Printf prints garbage if vsprintf is linked
Component: Run Time Libs
Solved in: v3.0r1p1

DESCRIPTION:
The customer reported a problem in the medium and large memory model when the functions related to the vsprintf function are linked. Although vsprintf and the related functions do not need to be used by the application the fact that they are linked scrambles the printf function results.

Testcase attached.



EXAMPLE:
#include <stdio.h>

void main(void)
{
    volatile     int h = 0, m = 0, s = 0;

    printf("long long: %lld\n", 1LL); // spoils the call below
    printf( "Time: %02d:%02d:%02d\r\n", h,m,s );
}


WORKAROUND:
Don't link printf_llong



SOLVED PR33430: FoUSB does not work properly
Component: ROM/RAM Monitor
Solved in: v3.0r1p2

DESCRIPTION:
Use the dimonm16c_usb debug instrument to debug Renesas FoUSB targets often fail on startup.


SOLVED PR33450: stc isp, X is simulated as stc sp, X
Component: Simulator
Solved in: v3.0r1p2

DESCRIPTION:
    stc isp, X

is simulated incorrectly as

   stc sp, X

EXAMPLE:
extern char _lc_bs[];

int main(int argc)
{
    /* lc_bs = 400  * lc_es = 4400 */
    /* running with ISP */
    __fclr(__U);        /* SSP = 43fd = ISP */
    if (__stc_isp() < (unsigned int) &_lc_bs[0])
    {
        return 1;
    }            /* running with USP */
    __fset(__U);
    __ldc_sp(0x300);
    /*
     *    USP = 300 = SSP
     *    ISP = 43FD
     *    lc_bs = 400
     */
    if (__stc_isp() < (unsigned int) &_lc_bs[0])
    {
        /* WRONG ? */
        return 2;
    }
    return 0;
}



SOLVED PR33460: malloc/free in the medium memory model don't work with heaps > 64k.
Component: C Libraries
Solved in: v3.1r1

DESCRIPTION:
> As far as I understood this means that in the medium and large memory
> model the heap may be bigger than 64kB without having to modify the malloc/free functions, or?

Eh, unfortunately not for the medium memory model. The medium memory model uses __paged qualified pointers internally, and these are restricted to 64k objects.

Thus
    void *malloc(size_t)
means
   __paged void *malloc(unsigned int);
in the medium memory model.

However, the linker just allocates a heap in far memory, and it can thus exceed 64k.
So the ede option is not needed for the medium memory model.

But sizes > 64k  can not be used with the default malloc/free: objects may not pass 64k object boundaries.



SOLVED PR33465: Project->Properties->Directories->Working Directory setting is overwritten
Component: EDE
Solved in: v3.0r1p2

DESCRIPTION:
When Selecting:
Project->Properties->Directories->Working Directory[D:\my_own\diectory]
[OK]

and changing any of the project options (Compiler, startup etc... anything)

The default %v%p entry is written into
Project->Properties->Directories->Working Directory
instead of keeping the previsouly user selected working directory.

The behaviour can be reproduced with any example project of both v2.3r2 and
v3.0r1.



SOLVED PR33471: Struct copies of 3 and 5 bytes and nested structs generate incorrect code.
Component: C Compiler
Solved in: v3.0r1p2

DESCRIPTION:
Struct copies of 3 and five bytes sometimes copy 4 cq 6 bytes, destroying surrounding stuff.
Also, a copy of nested struct within the struct results in incorrect code for the large memory model.

PR 33395 also fixes struct copies, but v3.0r1 patch 1 does not solve them all.


SOLVED PR33489: Compiler generates illegal code for shifting a long
Component: C Compiler
Solved in: v3.0r1p3

DESCRIPTION:
The customer supplied me the attached testcase. The compiler generates wrong code since the max. number of shifts used in an SHL.L instruction is -16 to +16 and therefore a shift of 22 will lead to an indeterminated result.




SOLVED PR33514: Crossview can't debug properly when USP is used as stackpointer
Component: CrossView
Solved in: v3.0r1p3

DESCRIPTION:
Crossview uses the wrong addresses for locals on the stack if USP is used as stackpointer.

EXAMPLE:
#include <stdio.h>
#include <string.h>

typedef struct
{
        int     i;
        char    *p;
} foo_t;

void bar(foo_t *ptr)
{
        ++ptr->i;
}

void doit(void)
{
        foo_t   foo;

        foo.i = 42;
        foo.p = "sumthin";

        bar(&foo);
}

void main(void)
{
        char stack[50];
        int i;

        memset(stack, 0, sizeof (stack));
        __asm("fset u");
        __asm("ldc %0,sp" : : "r"(stack + sizeof (stack)));
        doit();
        __asm("fclr u");
        printf("stack:");
        for (i = sizeof (stack) - 16; i < sizeof (stack); ++i)
        {
                printf(" %02x", (unsigned char)stack[i]);
        }
        printf("\n");
}




SOLVED PR33515: Incorrect code generate for returning carry. Incorrectly simulated.
Component: C Compiler
Solved in: v3.0r1p3

DESCRIPTION:
After calling a function that returns an enums or a __bit in the carry register, it is often immediately destroyed by a "add.b X,SP" instruction.

This instruction is incorrectly simulated, it does not write bugs. So the bug is only detectable on hardware.

EXAMPLE:
After calling a function that returns an enums or a __bit in the carry register, it is often immediately destroyed by a "add.b X,SP" instruction.

This instruction is incorrectly simulated, it does not write bugs. So the bug is only detectable on hardware.


SOLVED PR33547: Compiler generates endless loop for struct copy
Component: C Compiler
Solved in: v3.0r1p3

DESCRIPTION:
The customer supplied me the attached testcase. He uses already v3.0 patch 2 but
there is a still a bug related to struct copying. The problematic line is marked
with //UK in the .c file. The compiler produces a wrong end of loop condition and
therefore the loop becomes endless.

To workaround this problem the expression simplification optimization can be
switched off.

EXAMPLE:
// original AUTHOR: M.Kruse, RST Rostock System-Technik GmbH

#include <assert.h>
#include <stdio.h>

#define CAN0_RXQUE_SIZE  20

/// describes a CAN Message Object
typedef struct
{
    unsigned int            BoxInd;            ///< mailbox index
    unsigned long            Id;            ///< CAN identifier
    unsigned int            Dlc;            ///< data length code
    unsigned int            Data[8];        ///< data field
} SCan0MsgObj;

/// describes the CAN Message Object Queue
typedef struct
{
    unsigned int                Cnt;        ///< count of objects in the queue
    unsigned int                Rind;        ///< read index
    unsigned int                Wind;        ///< write index
    SCan0MsgObj        Obj[CAN0_RXQUE_SIZE]; ///< object buffer
} SCan0MsgObjQue;



SCan0MsgObj obj1 = {1,2,3,{4,5,6,7,8,9,10,11}};
SCan0MsgObj obj2 = {12,13,14,{15,16,17,18,19,20,21,22}};;
unsigned int ba = 0xfedc;
SCan0MsgObjQue RxQue = {23, 24,  0, /* Wind must be 0 for the bug to show up */
            {{25,26,27,{28,29,30,31,32,33,34}},
            {45,46,47,{48,49,50,51,52,53,54}},
            {65,66,67,{68,69,70,71,72,73,74}},
            {85,86,87,{88,89,90,91,92,93,94}}},
};
unsigned int boe = 0xabcd;

unsigned int WriteRxQueObj(SCan0MsgObj* pObj)
{
    obj1 = *pObj;
    
    if (pObj == NULL)
        return 0;

    if (RxQue.Cnt > CAN0_RXQUE_SIZE)
        return 0;
    
//UK
    RxQue.Obj[RxQue.Wind] = *pObj ;            /* bug: "cmp a0,r0; jleu" with r0==0 will loop forever */
    RxQue.Wind = (RxQue.Wind + 1) % CAN0_RXQUE_SIZE;
    RxQue.Cnt++;
    return 1;    
}

//////////////////////////////////////////////////////
int main(void)
{
    RxQue.Cnt = 0;
    RxQue.Wind = 0;

    int ret = WriteRxQueObj(&obj2);

    assert(RxQue.Cnt == 1);
    assert(RxQue.Wind == 1);
    assert(RxQue.Obj[0].BoxInd == 12);
    assert(RxQue.Obj[0].Id == 13);
    assert(RxQue.Obj[0].Dlc == 14);
    assert(RxQue.Obj[0].Data[0] == 15);
    assert(RxQue.Obj[0].Data[1] == 16);
    assert(RxQue.Obj[0].Data[2] == 17);
    assert(RxQue.Obj[0].Data[3] == 18);
    assert(RxQue.Obj[0].Data[4] == 19);
    assert(RxQue.Obj[0].Data[5] == 20);
    assert(RxQue.Obj[0].Data[6] == 21);
    assert(RxQue.Obj[0].Data[7] == 22);

    assert(boe == 0xabcd);
    assert(ba == 0xfedc);

    assert(ret==1);
    
    printf("all right\n");
    return 0;
}



SOLVED PR33548: Internal error on example
Component: C Compiler
Solved in: v3.0r1p3

DESCRIPTION:
The attached example fails with an internal error.

EXAMPLE:
__paged int e_rotate = 1;
__paged int e_down = 2;

void PaintPiece(char, char, char, char);
char RandomType(void);
void WaitEvent ( int );

void _os_u_tetris(void)
{
     char type = RandomType();
     int col =  RandomType();;

     WaitEvent( e_rotate | e_down );
     PaintPiece(20,7,type,(char)col);    /* regalloc fails on move from RC_R01A_lo to R1H, while R1L is already used... */
}

void WaitEvent ( int x) { PaintPiece(1,2,3,4); for (int i=0; i<x; i++) __nop(); }
char RandomType(void)    { return 5; }
void PaintPiece(char a, char b, char c, char d)    {}

int main(void)
{
    
    _os_u_tetris();
}





SOLVED PR33558: The __frame() unknown register names should give an error.
Component: C Compiler
Solved in: v3.0r1p3

DESCRIPTION:
The __frame() qualifier should give an error for registernames it does not recognize.
Furthermore, it should use a case insensitive compare for register names.

EXAMPLE:
/* should return 0 */

long hatsikidee = 0x12345678;

long bub(long a, long b, __far long*c)
{
    return a + b + *c;
}

void __interrupt(18) __frame(r0, r1, r2, r3, a0, a1) isr(void)
{
    long c = 3;
    hatsikidee = bub(1L, 2L, &c);
}

int main(void)
{
    long c = 100;
    int result = bub(300L,200L,&c);
    
    __int(18);

    if (result != 600)
        return 1;

    if (hatsikidee != 6)
        return 2;

    return 0;
}



SOLVED PR33583: The Misra C report from the linker does not work
Component: Linker/Locator
Solved in: v3.0r1p3

DESCRIPTION:
The MisraC report option results in only a header in the .mcr file.

M16C linker - Misra C (task: task1)
----------------------------------------------------------------------------------------------------------------------------------------------------------------



SOLVED PR33661: libc can not be rebuild due to files missing
Component: C Libraries
Solved in: v3.0r1p3

DESCRIPTION:
The following functions are referred to in the makefile for the standard C
library:


        _cgef.c
        _cgtf.c
        _cltf.c
        _clef.c
        _cge.c
        _cgt.c
        _clt.c
        _cle.c
        _caddl.c
        _csubl.c
        _cdivl.c
        _ceql.c
        _cnel.c
        _cgel.c
        _cgtl.c
        _cltl.c
        _clel.c
        cacosl.c
        casinl.c
        catanl.c
        ccosl.c
        csinl.c
        ctanl.c
        cacoshl.c
        casinhl.c
        catanhl.c
        ccoshl.c
        csinhl.c
        ctanhl.c
        cexpl.c
        clogl.c
        cabsl.c
        cpowl.c
        csqrtl.c
        cargl.c
        cimagl.c
        conjl.c
        cprojl.c
        creall.c

These functions cannot be compiled since they are missing from the lib/src
directory. Thus the library cannot be rebuilt.


SOLVED PR33665: lkm16c runs forever on example
Component: Linker/Locator
Solved in: v3.0r1p3

DESCRIPTION:
Upon build of the attached project the linker does not finish the output of
the .elf file but hangs up.
The process must be killed via Task list.
This behaviour can be observed using WIN98SE and WIN2k.




SOLVED PR33681: Linker fails with S602: assembler generates illegal relocation
Component: Assembler
Solved in: v3.0r1p3

DESCRIPTION:
Please find attached a testcase to reproduce the following behaviour:


TASKING program builder v3.0r1 Build 072 SN 00979910
lkm16c E121: relocation patch error in "task1": relocation value 0xa1271 for
relocation of type R_M16C_DSP8 in section "http_CO" at offset 2312 is out of
range (should be 8-bit signed or unsigned)
lkm16c S602: unrecoverable error: fatal locate error
wmk: *** action exited with value 1.


The project file :
HTTPLedControl_IASWebBoard62P_v3_0r1.pjt
can be found in:
\App\HTTPServerSamples\HTTPLedControl\Firmware


After trying to clean up a location conflict for the monitor reserve
(0xfe000, size 0x2000) and the fixed vector table (0xFFFDC) the linker
throws the fatal error message.




SOLVED PR33690: Internal consistency check failed on switch() statement
Component: C Compiler
Solved in: v3.0r1p3

DESCRIPTION:
The attached example fails with an internal consistency check in the compiler

EXAMPLE:
define ClearKey 0x10
#define DownArrow 0x11
#define UpArrow 0x12

unsigned char se_getchar();
extern __near unsigned char c;
void ReadLog(char *Dest, int Direction);
void ShowLog(char* Buffer, unsigned char Eng);



void LogRead(void)
{
char Buffer[8];
int direction = 0x0;


    while (1)
    {
        ReadLog(Buffer,direction);     // 1
        ShowLog(Buffer, 1);            // 1
        c = 0x0;                       //  2
        while (c==0)                   //  2
        {                              //  2
            c = se_getchar();          //  2
        }                              //  2

        switch (c)                     //    3
        {                              //    3
            case ClearKey :               //    3
                return;                //    3
            case DownArrow:            //    3
                direction = -1;        //    3
                break;                 //    3
            case UpArrow :             //    3
                direction = 1;         //    3
                break;                 //    3
            default :                  //    3
                break;                 //    3
        }                              //    3
    }
}



SOLVED PR33724: Incorrect code generated for c99 variable length arrays
Component: C Compiler
Solved in: v3.0r1p3

DESCRIPTION:
The attached example generates incorrect code, in all memory models.

EXAMPLE:
#include <stdio.h>

int vla_bounds (int len)
{
        char dummy1[len];
        char buf10[len];
        return buf10[0];
}

int main(void)
{
        fprintf(stderr, "==> vla\n");
        vla_bounds(8);
        return 0;
}




SOLVED PR33725: arm16c crashes when putting a source file in an achive
Component: Archiver
Solved in: v3.0r1p3

DESCRIPTION:
coredump when puting source file in archive


SOLVED PR33736: Invalid code generated for struct members of a link list
Component: C Compiler
Solved in: v3.0r1p3

DESCRIPTION:
Please find attached an addtional verified buildable testcase.


The addresses are not correctly written into the struct member pointers of a
linked list.



EXAMPLE:
typedef struct list_entry_s list_entry_t;

struct list_entry_s {
    unsigned short id;
    void __near * entry;
    list_entry_t __near * prev;
    list_entry_t __near * next;
};

typedef struct list_s list_t;

struct list_s {
    int count;
    list_entry_t __near * first;
};


void __near * sc_msgAlloc(int size);
void sc_error(int a);

int main(void )
{
    list_t __near * l;

    l = (list_t __near *)sc_msgAlloc(sizeof(list_t));
    l->first = (list_entry_t __near *)sc_msgAlloc(sizeof(list_entry_t));
    if ( !l->first ){
        sc_error(10);
        return -1;
    }
/************
** the following code is wrong optimized
************/
    l->first->next = l->first;
    l->first->prev = l->first;
    return 0;
}

#include <stdlib.h>
void __near * sc_msgAlloc(int size)
{
return (void __near *) malloc(size);
}
void sc_error(int a)
{
__nop();

}


WORKAROUND:
The bug is in a peephole optimization, so with -OY the bug won't show.

With #pragma optimize OY and #pragma optimize restore you can apply this to a small program section.


SOLVED PR33754: Linker gives unrecoverable error when stripping debug info
Component: Linker/Locator
Solved in: v3.1r1

DESCRIPTION:
The customer reported a linker problem. When the option 'Strip Symbolic
debug information' in menu 'Project|Project Options|Linker|Miscellaneous' is
activated the linker error messages:


lkm16c F009: object store error: symbol id does not exist
lkm16c S602: unrecoverable error: fatal link error


are generated. As a workaround one can deactivate the option 'Generate debug
information' in menu 'Project|Project Options|C Compiler|Debug' and the
option 'HLL debug when available,...' in menu 'Project|Project
Options|Assembler|Debug'.


You can verify this problem using one of the example projects.



SOLVED PR33767: Compiler produces illegal assembly pusha [a0]
Component: C Compiler
Solved in: v3.0r1p3

DESCRIPTION:
I ran into another bug of the M16C Compiler V 3.0r1 Patch 2.

Problem: With optimization -O3 --tradeoff=0 (i.e. for speed not size)
produces an illegal assembly opcode.

It generates an : pusha [a0], but should instead generate pusha 0[a0]
AFAICS.

BTW: Switching off peephole does not change anything.


This is IMHO a flaw in the assembler, it should accept [a0] as 0[a0] where
needed.


See attached example which demonstrates the problem.
Note: It does not make much sense in this state, it is a cooked down
source.



SOLVED PR33780: #pragma asm conversion bug: truncates long lines
Component: EDE
Solved in: v3.1r1

DESCRIPTION:
#asm conversion from v2.3 to v3 style __asm() sometimes leads to truncated lines, if tabs are present at the start of lines.


SOLVED PR33917: _case_* runtime functions don't function properly
Component: Run Time Libs
Solved in: v3.1r1

DESCRIPTION:
please find attached a testcase (specially the .elf file) that allows to
reproduce a false jump (via incorrectly loaded R0) to Nirvana with switch
condition NON NULL.
The customer noted that not only __case_s16_far is involved but also
__case_u16_far and other case library subroutines lead to that kind of
behaviour.



SOLVED PR33925: complement operator for __bit and _Bool generates wrong code
Component: C Compiler
Solved in: v3.1r1

DESCRIPTION:
The customer reported a problem with the ~ operator when it's used on a bit
variable. The attached example can be used for reproduction of the bug.




SOLVED PR33962: Internal error in powersupply.cpp
Component: C Compiler
Solved in: v3.1r1

DESCRIPTION:
Internal error in powersupply.cpp




SOLVED PR33998: compiler takes over an hour for example - and allocates over 800M
Component: C Compiler
Solved in: v3.1r1

DESCRIPTION:
The customer uses Mathlab/Simuling to automatically generate a C file which
is then processed by our M16C compiler. This file is pretty large (1.8 MB).
When he compiles the file it takes around 3 hours. He uses Win 2000 and has
a fast PC (2.0 GHz).



SOLVED PR34016: Simulator does not set/clear overflow flag for rmpa instruction
Component: Simulator
Solved in: v3.1r1

DESCRIPTION:
Problem Description:
---------------------
For M16C/6N, if the parameters for an RMPA.W instruction would cause the sum to have a signed overflow, Crossview Pro's simulation doesn't set the Overflow flag in the simulated FLG register.
--



SOLVED PR34044: internal consistency check failed on intrinsic __reit()
Component: C Compiler
Solved in: v3.1r1

DESCRIPTION:
Using " __reit(); " causes consistency check failure,
__asm("reit"); " doesn't.


WORKAROUND:
Use __asm("reit"),  or don't use -g.


SOLVED PR34045: case values > 0x8000 lead to error from assembler
Component: C Compiler
Solved in: v3.1r1

DESCRIPTION:
Please find attached a testcase to reproduce the following behaviour:
asm16c E217: ["main.src" 16] expression out of range (-32768 and -1 decimal)



EXAMPLE:
static char TestFunk1 (char value);
static char TestFunk2 (char value);



void main (void)
{

/*
   volatile unsigned short usTest = 0;
   volatile unsigned char ucFehler;
   volatile unsigned short usIbModulError;


         switch(usTest)
         {
            case (unsigned short)0x8004:
               ucFehler = 7;
               usIbModulError = 1;
               break;
            case (unsigned short)0x8010:
               ucFehler = 8;
               usIbModulError = 2;
               break;
            case (unsigned short)0x8020:
               ucFehler = 9;
               usIbModulError = 3;
               break;
            case (unsigned short)0x8040:
               ucFehler = 10;
               usIbModulError = 4;
               break;
         }

*/

   volatile unsigned short intTest = 0x8055;
   volatile unsigned char ucFehler;
   volatile unsigned short usIbModulError;


#pragma jump_switch
         switch(intTest)
         {
            case 0x8004:
               ucFehler = 10;
               usIbModulError = 1;
               break;
            case 0x8010:
               ucFehler = 9;
               usIbModulError = 2;
               break;
            case 0x8020:
               ucFehler = 8;
               usIbModulError = 3;
               break;
            case 0x8030:
               ucFehler = 7;
               usIbModulError = 4;
               break;
            case 0x8040:
               ucFehler = 6;
               usIbModulError = 5;
               break;
            case 0x8050:
               ucFehler = 5;
               usIbModulError = 6;
               break;
            case 0x8060:
               ucFehler = 4;
               usIbModulError = 7;
               break;
            case 0x8070:
               ucFehler = 3;
               usIbModulError = 8;
               break;
            case 0x8080:
               ucFehler = 2;
               usIbModulError = 9;
               break;
            case 0x8090:
               ucFehler = 1;
               usIbModulError = 10;
               break;
         }

    {
        char i;
        char wert = 0;

        for (i = 0; i < 20; i++)
        {
             wert = TestFunk1 (wert);
             if (wert > 100)
               wert = 0;
             wert = TestFunk2 (wert);
             if (wert > 100)
               wert = 0;
        }
    }
}


static char
TestFunk1 (char value)

{

   return (value + 5);
}


static char
TestFunk2 (char value)

{

   return (value + 10);
}




SOLVED PR34050: Simulator loops forever on cstart code for M16C/6P processor
Component: Simulator
Solved in: v3.1r1

DESCRIPTION:
For m16c/62P processors, the startup code by default uses the PLL clock.
To set this clock, a stabilize loop is present: it sets PLC07 and loops until PLC03 is set. As the simulator does not implement the SFR's, it loops forever here.

A solution is to extend the simulator with rudimentary support for PLC0.
When PLC07 is set, PLC03 is also set.


SOLVED PR34053: long long shift: both compiler and simulator do it incorrectly
Component: C Compiler
Solved in: v3.1r1

DESCRIPTION:
The M16C compiler, v3.0 r1, generates these instructions to shift a long long int in R3R1R2R0 right by 1 bit:
      sha.l #-1, R3R1
      rorc.w R2
      rorc.w R0
The problem is that the C flag output from the sha.l is -indeterminate-, per the M16C-60 Software Manual.



SOLVED PR34058: incorrect code generated for passing 2-valued enum as parameter
Component: C Compiler
Solved in: v3.1r1

DESCRIPTION:
If a two valued enum is passed as a parameter in a byte register, sometimes the 7 unused bits are not cleared.



SOLVED PR34062: internal consistency check failed on implicit array to integer cast
Component: C Compiler
Solved in: v3.1r1

DESCRIPTION:
The compiler reported an internal inconsistency.
cm16c -g -O0 -Mm 34062.c

void example(const char __far *s)
{
     char    c[4] = {s[0],s[1],0,0};
     int     i = atoi(c);
}



EXAMPLE:
void example(const char __far *s)
{
     char    c[4] = {s[0],s[1],0,0};
     int     i = atoi(c);
}



KNOWN PROBLEMS


PR30922 (Assembler): no error/warning triggered on variable type mismatch
PR31181 (C Compiler): Introduce a compiler switch to turn dedicated warnings into errors.
PR31300 (C++ Compiler): C++ compiler uses memcpy without generating the proper prototype
PR31785 (CrossView): Improve showing multidimensional array in Crossview Pro
PR32279 (EDE): Unable to diff with archived PVCS file.
PR32458 (CrossView): add option to specify Crossview shutdown time after losing serial connection
PR32577 (Miscellaneous): Allow flash blocks to be disabled from erasing
PR33094 (EDE): Error message is needed when only entering a Note for reserved area
PR33401 (Reg. Def. Files): lint warns about a char pointer to __bitstruct_t (32 bits)
PR33840 (CrossView): Crossview gives error when a typedef is used in a sfr file
PR34046 (CrossView): Probe breakpoints are slow

KNOWN PR30922: no error/warning triggered on variable type mismatch
Component: Assembler

DESCRIPTION:
If a variable is qualified with a memory type in the EXTERN directive
the linker should trigger a warning or error when it doesn't match with
the public definition. This does not seem to happen.

EXAMPLE:
=======================
file1.src
=======================
    EXTERN (DATA)_var

    DEFSECT "cseg",CODE
    SECT    "cseg"

    MOV.B #1,_var

    END
=======================
file2.src
=======================
    GLOBAL _var

    DEFSECT "dseg", FDATA
    SECT    "dseg"
_var:
    DS 1

    END



KNOWN PR31181: Introduce a compiler switch to turn dedicated warnings into errors.
Component: C Compiler

DESCRIPTION:
Introduce a switch to turn dedicated warnings into errors.




KNOWN PR31300: C++ compiler uses memcpy without generating the proper prototype
Component: C++ Compiler

DESCRIPTION:
In the C code generated by the C++ compiler the function memcpy() may be
used. However when used no prototype for this memcpy() function is generated.
This results in W112 from the linker:

lkm16 W112 (4) main.obj: Type conflict for symbol <_memcpy> in memcpy.obj




KNOWN PR31785: Improve showing multidimensional array in Crossview Pro
Component: CrossView

DESCRIPTION:
Multi dimensional arrays like:

unsigned char test[10][10];

are not displayed very well readable in the debugger.




KNOWN PR32279: Unable to diff with archived PVCS file.
Component: EDE

DESCRIPTION:
When using EDE to Diff two source files, one a current version on a local disk,
and another older version on an archived PVCS drive, the EDE gives the error:

Error: Unable to open the following file for writing: \pt5301.tmp




KNOWN PR32458: add option to specify Crossview shutdown time after losing serial connection
Component: CrossView

DESCRIPTION:
It takes quite some time until CrossView Pro ROM shuts down when it loses the serial
communication (i.e. because the target CPU crashed). Introduce an option to specify
a delay time after which CrossView Pro shuts down automatically when it loses the
connection to the target.



KNOWN PR32577: Allow flash blocks to be disabled from erasing
Component: Miscellaneous

DESCRIPTION:
Sometimes parts of flash are used for storing non-volatile
variables. When flashing a new application the entire flash
area however is erased. Allow certain blocks to be protected
from erasing.


KNOWN PR33094: Error message is needed when only entering a Note for reserved area
Component: EDE

DESCRIPTION:
When an entry is made under 'notes' in 'Linker/Locator|Reserved areas' but by accident no start and end addresses are specified, a very unclear linker error is given:
"syntax error: at "," missing ............" for the lsl file.
There should be a proper error message.





KNOWN PR33401: lint warns about a char pointer to __bitstruct_t (32 bits)
Component: Reg. Def. Files

DESCRIPTION:
Lint gives warnings like
"Info 826 Suspicious pointer-to-pointer conversion (area too small)"
when __bitstruct_t (for 32 bits) is used on a 8 bit SFR.
To prevent these warnings, 16 and 8 bit __bitstruct_t should be used.



KNOWN PR33840: Crossview gives error when a typedef is used in a sfr file
Component: CrossView

DESCRIPTION:
When a sfr file contains typedefinitions, crossview issues an error in the command window, like
  regm306na.sfr: illegal type CAN_MRRead sfr file regm306na.sfr: illegal type
This SFR can not be shown in the register window. Watch-windows however can properly display the sfr.



KNOWN PR34046: Probe breakpoints are slow
Component: CrossView

DESCRIPTION:
Probe breakpoints when executed using the ROM monitor are slow.
Some communication overhead, like redundant read of registers could be avoided.

RESTRICTIONS


None.