The Renesas RX and RL78 Targets Get Updated Toolchains Today (Release 2019q2)

The most popular Renesas targets, RX and RL78, are receiving updated toolchains today, for the first time this year. Both releases include an update to Newlib 3.1.0, and several additional improvements or bug-fixes.

The release notes for each of these platforms may be found below, covering what changes each of these new toolchain versions bring:

  • GCC for Renesas (Windows | Linux)
    1. [Binutils][Bug Fix] Objdump decoded instructions as g14 specific instructions.
    2. [GCC][Bug Fix] Fixed the unexpected result generated when comparing to a global pointer.
    3. [Newlib][Improvementx] Updated to newlib version 3.1.0.
    4. [Newlib][Improvement] Nano libraries are now available. To use newlib-nano, users should provide additional gcc compile and link time option. –specs=nano.specs should be passed along with -specs=sim.specs if msim would be needed, else if msim is not needed -specs=lnosys.specs should be passed along with nano.specs. For example: $ rl78-elf-gcc test.c –specs=nano.specs -specs=sim.specs $(OTHER_OPTIONS)
    5. [Newlib][Improvement] Optimized string functions.
    6. [Newlib][Bug Fix] Added KEEP syntax for the frodata section into the default linker-script.
  • Known issues
    • ES is used without being initialized.

      In order to initialize ES, the address should be stored in a far pointer before usage. So instead of:

      ((volatile reg __far*)0x000FFF).bit._1 = 0;

      the code will be:

      volatile reg __far *address0 = 0x000FFF;
      (*address0).bit._1 = 0;

    • The __far keyword is not supported for C++ projects.
  • GCC for Renesas (Windows | Linux)
    1. [Binutils][Bug-Fix] Fixed the objdump code generation for MOV, POP, PUSH
    2. [Binutils][Bug-Fix] Fixed the dissambly generation of NOP instructions
    3. [Binutils][Bug-Fix] Improved the opcode decoding for RXv3 instructions
    4. [GCC][Bug-Fix] Fixed the detection of SSTR string opcode.
    5. [GCC][Improvement] The rmpa builtin function can now accept byte/word/long access size and parameters.
    6. [GCC][Improvement] Implemented save and rstr as attributes.
    7. [GCC][Improvement] The -mtfu option is now supported. TFU builtin functions are now available.
    8. [GCC][Improvement] A warning is now generated when mvtipl is used with -mcpu=rx610
    9. [GCC][Bug-Fix] Fixed the bit set builtin fuctions atomic access.
    10. [GCC][Bug-Fix] Fixed the isinf_sign and isnan builtin functions bug generated due to the newlib update.
    11. [GCC][Improvement] Optimized the xchg builtin function.
    12. [GDB][Bug-Fix] Fixed the simulation of some RXv3 instructions.
    13. [Newlib][Improvement] Updated to newlib version 3.1.0
    14. [Newlib][Improvement] Nano libraries are now available
    15. [Newlib][Improvement] Optimized string library functions.
    16. [Newlib][Improvement] Optimized the sqrt function.
  • Known issues
    • In certain cases the program will time out while executing with following options:
      (Note: Both flags need to be accompanied by “-fno-diagnostics-show-caret -w -O1 -DSTACK_SIZE=4096 -msim -lm” for the problem to be observed.)
      a) -funroll-loops
      b) -fpeel-loops
    • An incomplete type error can be observed ocasionally when using the -fpack-struct option in C++. The combination of the flags that reproduce this problem is “-fpack-struct -fno-diagnostics-show-caret -nostdinc++ -fmessagelength=0 -std=c++11 -pedantic-errors -Wno-long-long -S -msim

The Linux installer for both toolchains also offers command-line flags to automate installation as much as possible, as well as the ability to also act as an uninstaller for the toolchains. Therefore, the installer can both install and uninstall the toolchain from one or more paths from your Linux distribution. The release notes for both toolchains also include the list of the currently known issues presented above, to which we fully commit to adequately handle in the coming updates.

We are deeply grateful for any feedback you may have regarding this release, so please let us know if you have any questions or comments.

15 Responses to The Renesas RX and RL78 Targets Get Updated Toolchains Today (Release 2019q2)

  1. andrepereira says:

    How do i integrate toolchain on e2studio ?

    • GNU Tools Support says:

      You need to please install the toolchain first, then open up a recent version of e2Studio and the toolchain should be automatically detected. Just in case the automatic detection fails, you may also go to e2Studio and click the Help menu, then choose “Add Renesas Toolchains”.

  2. andrepereira says:

    I forgot to explain that I am using UBUNTU-MATE linux. I downloaded the gcc and run the file, but when I go to the e2studio integration part, the toolchain file does not been reconized by defalt.
    Is there a way to do that less paintfull ?

  3. alice.trifu says:


    Unfortunately, at this point, only the GNURX and ARM toolchains are supported by E2studio, on the Linux version, as you can see on Window → Preferences → Renesas → Renesas Toolchain Management.

    In the near future, we will strongly advocate that support for GNURL78 toolchains to be added in E2studio for Linux.

    Please let us know if we can help you with anything else.

    Kind regards,
    The GNU Tools Team

  4. says:


    e2studio is not recognised __far keyword. using Renesas for windows.

    getting build error.


    #define RADIO_FAR __far

    void (RADIO_FAR *TxDone )( void );

    can u please help me.
    error: expected identifier or ‘(‘ before ‘__far’

    • Darius Galis says:


      Unlike CCRL/IAR, the GCC RL78 doesn’t use the __far attribute for instructions that will be saved in the code section. In fact, in GCC this is not possible because the standard defines named address spaces only for data sections (please see the following: ).

      In order to handle code bigger than 64 KB, GCC uses a PLT (Procedure Linkage Table) to achieve this feat. A good explanation about this can be found here: .

      Although the article is about dynamic libraries, the same principle can be applied. Please observe the key part of the article:
      “The indirection used here is called a procedure linkage table or PLT. Code does not call an external function directly, but only via a PLT stub. Let’s examine this…”

      Please let us know if we can be of further assistance,

      Best Regards,
      The GNU Tools Team

  5. says:

    how to set all variables as volatile variables using gnurl78
    compiler options?

  6. says:

    how to set all variables default as type volatile using gnurl78 compiler options?

  7. says:

    how to set all variables default as type volatile in e2studio?

  8. says:

    while hardware debugging getting error messages “NO SOURCE AVAILABLE FOR VECTORS() AT 0x” and “BREAK AT ADDRESS 0x NO DEBUF INFORMATION AVAILABLE”
    and getting stuck at brk instruction.

    how to get rid of this?

    can I get help?

    • Darius Galis says:


      Thank you for reaching out to us!

      The “No source available” message is usually generated when the project is built without any debug information option enabled. We suggest checking the Project’s Debug Settings to be set at least as Debug level of -g2 and if the entry point is set correctly or the vector table is loaded at the correct address. If all those settings are correct, and the issue still persists we encourage you to open a private support ticket on our platform in which you can attach your project in order for us to investigate the issue more closely.

      Regarding the volatile question, we would like to ask you for more details about what you are trying to achieve by disabling the optimization for every variable. The GCC compiler does not have an option that sets all variables as volatile, but it supports options that disable certain optimization passes. If you can provide us with some explanation about why you are needing this option, we might be able to offer more in-depth support.

      We are looking forward to hearing from you,
      The GNU Tools Team

      • says:

        Hi Darius Galis, Thank you for your accountability and improvise us.

        we want to brief more about tool settings we follow.
        debug level – g2
        debug format -default
        optimization -(Os)
        vectors and device level settings given below
        const unsigned char Option_Bytes[] __attribute__ ((section (“.option_bytes”))) = {
        0x6EU, 0xFFU, 0xAAU, 0x84U

        const unsigned char Security_Id[] __attribute__ ((section (“.security_id”))) = {
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00

        #define VEC __attribute__ ((section (“.vec”)))
        const void *HardwareVectors[] VEC = {
        // Address 0x0
        // Secure for Debugging

        #define VECT_SECT __attribute__ ((section (“.vects”)))
        const void *Vectors[] VECT_SECT = {
        // Address 0x4
        R_Dummy, ////(void*)0xFFFF
        // Address 0x6
        // Address 0x8
        // Address 0xA
        // Address 0xC
        // Address 0xE
        // Address 0x10
        // Address 0x12
        // Address 0x14
        // Address 0x16
        // Address 0x18
        // Address 0x1A
        // Address 0x1C
        // Address 0x1E
        // Address 0x20
        // Address 0x22
        // Address 0x24
        // Address 0x26
        // Address 0x28
        // Address 0x2A
        // Address 0x2C
        // Address 0x2E
        // Address 0x30
        // Address 0x32
        // Address 0x34
        // Address 0x36
        // Address 0x38
        // Address 0x3A
        // Address 0x3C
        // Address 0x3E
        // Address 0x40
        // Address 0x42
        // Address 0x44
        // Address 0x46
        // Address 0x48
        // Address 0x4A
        // Address 0x4C
        // Address 0x4E
        // Address 0x50
        // Address 0x52
        // Address 0x54
        // Address 0x56
        // Address 0x58
        // Address 0x5A
        // Address 0x5C
        // Address 0x5E
        // Address 0x60
        // Address 0x62
        // Address 0x64
        // Address 0x66
        // Address 0x68
        // Address 0x6A
        // Address 0x6C
        // Address 0x6E
        // Address 0x70
        // Address 0x72
        // Address 0x74
        // Address 0x76
        // Address 0x78
        // Address 0x7A
        // Address 0x7C
        // Address 0x7E
        while hardware debugging The ERROR MESSAGE is
        Break at address “0xc7fc2” with no debug information available, or outside of program code.

        the address is 0xc7fc2 is reserved memory where the brkl instructions are exist.
        device memory range is 0x0000 to 0x1FFFF and F0000 to FFFFF.
        device reserved memory is 0x20000 to 0xEFFFF
        the device reserved memory is not supposed to be used for programming/debugging.

        requesting you to please provide some advise on this.


  9. says:

    the error might be due to vectors?

    can you help us?

    • Darius Galis says:


      Thank you for the quick answer.

      While the information provided is useful, it doesn’t help getting to the root of the issue. This was the reason why we kindly asked you to open a private support ticket in which you should attach the ENTIRE e2studio project. It contains all the information needed to assess the generation of this undesirable behavior either through project-related configurations or specific code instructions (eg: vector table loading, not defining, at a wrong address).

      Thank you for your understanding,
      The GNU Tools Team

Leave a Reply