New Toolchain Releases for the Renesas RX and RL78 Families

Today we are releasing two new versions for the Renesas RX and RL78 families of products.

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

  • GCC for Renesas 4.9.2.201603-GNURL78 (Windows | Linux)
    1. (Improvement) Added multiple new RTL patterns (in the RTL/code generator part of the compiler) aimed to reduce the overallsize of the RL78 executables.
    2. (Bug Fix) Fixed the failed tests from the DejaGnu regression test suite when the “-free” compile option is used in conjuction with the “-lto” one.
    3. (Improvement) Applied a fix for avoiding the generation of large code size for the conditional operator in certain cases (e.g. when testing a signed integer value for not being zero).
    4. (Bug Fix) -fwhole-program optimization switch can be used now without (incorrectly) remove the .fvectors and .rvectors tables and the interrupt handlers from the program.
    5. (Improvement) The compiler’s decisions to call “__mulsi3” or use the “mulhu” instruction when “-mcpu-g14” is specified are now consistent.
    6. (Improvement) Reduced the size of the “libgcc” library by employing “clrb/clrw” instructions wherever possible.
    7. (Bug Fix) Fixed an issue in the GNU assembler that was generating spurios “L0^A” labels visible when debugging the code in e2Studio.
  • GCC for Renesas 4.8.0.201603-GNURX (Windows | Linux)
    1. (Bug Fix) -fwhole-program is a very useful optimization technique, unfortunately in case of RX/RL78 it removes the .fvectors and .rvectors tables and all the interrupt handlers.
    2. (Improvement) bsr can do maximum a 24 bit jump not 32 bit like jsr which sometimes is not enough. For example if in a function there are multiple calls to another function, GCC can generate only one mov.l instruction and multiple jsr instructions. Because jsr is only 2 bytes long at some point the mov.l combination becomes more code size efficient than bsr.
    3. (Improvement)  GNURX toolchain has builtin functions for bit manipulation instructions (BSET, BNOT, BCLR) when dest is a register. Now the toolchain supports builtin functions when dest is a memory location.
    4. (Bug Fix) The RX toolchain fsub instruction does not load the correct values for its parameters for RX64M target causing the subtraction to fail.
    5. (Bug Fix) The GNURX compiler generates the following warning “foo.c:3: warning: format ‘%f’ expects type ‘double’, but argument 2 has type ‘float’ “when -m32bit-doubles and -Wall parameters are passed. This is unnecessary because float is promoted to double in variadic functions.
Sex Cam

4 Responses to New Toolchain Releases for the Renesas RX and RL78 Families

  1. samson123 says:

    Compiling the code with -g3 throws below error while linking

    BFD: Dwarf Error: found dwarf version ‘0’, this reader only handles version 2, 3 and 4 information.
    B

  2. GNU Tools Support says:

    Hello,

    Thank you for reaching out to us!

    If this issue persists, could you please open a support ticket and specify what toolchain you were attempting to compile and for which target, as well as the operating system you were using for the procedure? We should be able to assist faster this way.


    Thank you,
    The GNU Tools Team

  3. samson123 says:

    The issue occurred when I was using “-mbig-endian-data” switch, I wanted to compile the code for big endian and trying to link libc.a( which I think is compiled with little endian)

    Issue resolved when removed the switch i.e. compiled for little endian

  4. GNU Tools Support says:

    Thank you for the details provided.

    It seems that you may be trying to compile the RX toolchain source code. While multiple versions of the libc.a library exist (including ones compiled for big endian formats, e.g. referring to the “-mbig-endian-data” flag), the compiler (rx-elf-gcc) should know on its own to which library to link to. However, when using the linker (rx-elf-ld) manually, you would have to specify the proper library on your own.

    If you could share a test command, or a sample project we could work with, it would quickly allow us to be able to assess the impact of the issue reported and provide more accurate feedback.


    Thank you,
    The GNU Tools Team.

Leave a Reply

Support