English
Is this a bug in GCC?
Is this a bug in GCC?
Hi,
Chip uses Renesas RX231 and the compiler uses 4.8.4.201803-GNURX.
The options to use are:
-Os
-isa=v2
64bit-doubles
When compile the following strange C function,
After calling val64 () at 0xfff828ec, the upper 32 bits are not used for multiplication.
Looks like optimization has failed.
uint64_t val64()
{
uint32_t high;
uint16_t low;
high = rand();
low = rand() % 0xFFFF;
return ((uint64_t)high << 32) + low;
}
uint32_t test(void)
{
volatile uint64_t tmp;
int i;
val64();
tmp = val64();
for (i=0; i<2; i++) {
tmp = val64();
tmp = val64() * 1000;
}
tmp /= 100;
return 0;
}
Compiled assemble code of test()
(gdb) disas test
Dump of assembler code for function test:
0xfff828c5 <+0>: pushm r6-r12
0xfff828c7 <+2>: sub #8, r0
0xfff828c9 <+4>: mov.l #0xfff828a8, r6 ;; 0xfff828a8 is val64()
0xfff828cf <+10>: jsr r6
0xfff828d1 <+12>: jsr r6
0xfff828d3 <+14>: mov.l r2, r10
0xfff828d5 <+16>: mov.l r1, [r0]
0xfff828d7 <+18>: mov.l r2, 4[r0]
0xfff828d9 <+20>: mov.l #2, r7
0xfff828db <+22>: mov.l #0x3e8, r11
0xfff828df <+26>: mul r2, r11
0xfff828e1 <+28>: mov.l #0x3e8, r12
0xfff828e5 <+32>: jsr r6
0xfff828e7 <+34>: mov.l r1, [r0]
0xfff828e9 <+36>: mov.l r10, 4[r0]
0xfff828ec <+39>: jsr r6
0xfff828ee <+41>: mov.l r1, r4
0xfff828f0 <+43>: emulu r12, r4
0xfff828f3 <+46>: mov.l r4, r14
0xfff828f5 <+48>: add r11, r5
0xfff828f7 <+50>: mov.l r14, [r0]
0xfff828f9 <+52>: mov.l r5, 4[r0]
0xfff828fb <+54>: sub #1, r7
0xfff828fd <+56>: bne.b 0xfff828e5
0xfff828ff <+58>: mov.l [r0], r1
0xfff82901 <+60>: mov.l 4[r0], r2
0xfff82903 <+62>: mov.l #100, r3
0xfff82906 <+65>: mov.l r7, r4
0xfff82908 <+67>: bsr.a 0xfffaa2a0
0xfff8290c <+71>: mov.l r1, [r0]
0xfff8290e <+73>: mov.l r2, 4[r0]
0xfff82910 <+75>: mov.l r7, r1
0xfff82912 <+77>: rtsd #36, r6-r12
End of assembler dump.
Regards
Takayuki
Hello,
Thank you for reporting this issue to us!
A possible workaround would be changing the optimization level to -O0 (none).
In e2studio 7.4 you can do this by right-clicking on your project → Properties → C/C++ Build → Settings → Optimization → Optimization Level.
We are working on resolving this issue in one of our future releases. Please check regularly on our support platform at https://llvm-gcc-renesas.com to find out when this issue will be resolved. If you signed up to receive targeted emails about Renesas products when creating your account, you will also receive a newsletter whenever new releases are available.
Please let us know if we can be of further assistance!
–
Best regards,
The GNU Tools Team
-
Thank you for answering.
however, optimization level -O0 does not fit in ROM.
In a little more detail, please tell us which optimization flag is the problem.
ex. -frerun-cse-after-loopRegards
Takayuki -
Hello,
We are currently investigating which algorithm, from the ones employed by the code size optimization (-Os) option, is the culprit.
In the meantime, we suggest one of the following:
1. You could change the optimization level to -O0 (none) for that specific file in which the function resides by right-clicking on the file → Properties → C/C++ Build → Settings → Compiler → Source → User defined compiler options.
2. Add the optimize attribute to the function prototype:
uint32_t test(void) __attribute((optimize(“-O0”)));
uint32_t test(void)
{ … }
This will ensure that only that function will be compiled without any optimization flags.We are sorry for any inconvenience caused.
–
Best regards,
The GNU Tools Team -
Thank you for your answer.
It corresponded by __attribute ((optimize (“-O0”))).
-
Hello,
We investigated this issue and found out that the loop invariants algorithm seems to be causing the issue. We suggest disabling it by using the -fno-move-loop-invariants option. We also want to inform you that we are working on a fix for this, which will be available in one of the next releases.
Thank you for your understanding!
–
Best regards,
The GNU Tools Team -
Thank you for answering！
Resolved with -fno-move-loop-invariants.:) -
Dear customer,
We are happy to report that this issue should be resolved in the new 2019q4 release of the GCC for Renesas RX toolchain, present on our website for download at: https://gcc-renesas.com/downloads/download.php?f=rx/8.3.0.201904/gcc-8.3.0.201904-GNURX-ELF.exe
If you have any further questions about the issue, please let us know.
– Thank you,
The GNU Tools Team -
I am late.x(
Thank you for contacting us.
I will confirm it.
