RX Compiler UINT64 Code Generation Problem?

I'm running on a RX64M using the RX compiler (2.06) and found that some of the code in the FIT BSP wasn't working as expected.  I think it may be a compiler bug.  I setup a simple test and confirmed that it doesn't behave as I would expect.

int main(void)
{
    unsigned long long tmp, tmp2;
    unsigned long failures = 0;

    /* subtracting constant > 32bits works */
    tmp = 1099511627776;

    tmp -= (unsigned long long)2;

    if (tmp != (unsigned long long)1099511627774)
    {
        failures++;
    }

    /* subtracting variable with value < 32bits works */
    tmp = 78000;
    tmp2 = 2;

    tmp -= tmp2;

    if (tmp != (unsigned long long)77998)
    {
        failures++;
    }

    /* subtracting constant < 32 bits fails */
    tmp = 78000;

    tmp -= 2ULL;

    if (tmp != 77998ULL)
    {
        failures++;
    }

    /* subtracting constant < 32 bits fails */
    tmp = 78000;

    tmp -= (unsigned long long)2;

    if (tmp != (unsigned long long)77998)
    {
        failures++;
    }

    /* subtracting constant < 32 bits fails */
    tmp = 78000;

    tmp += (unsigned long long)-2;

    if (tmp != (unsigned long long)77998)
    {
        failures++;
    }
}

There is a sign extension flaw in the code generation that gets produced when the constant being subtracted requires less than 32 bits.

I'm running with no optimizations on RX64M with the RXv2 architecture selected for the instruction set.

  • Hi,

    I don't know if someone else have tried this one, but maybe, I think it's a compiler error.

    -MarkBau
    RenesasRulz Forum Moderator
  • Hello,

    I tried to verify your problem but I cannot see it. I created a new project using your code in main(). All calculations give the correct result.

    I use CC-RX 2.06 in e2 studio 5.4.0.018.

    I selected -optimize=0 for compiler and standard library, although I don't understand why anyone would use this. optimize=0 generates 60% more code compared to default optimize=2 on this simple code.

    I run the code in the simulator and on a RSK+RX64M with E1. All subtractions are correct.

    I attach my project for reference.

    Divide_UnsignedLongLongConst.zip

    MarkBau, have you tried this?

  • HI Folks,

    I am voting with FrankL, works fine when I build it also.
    Maybe you will see your issue when you look at FrankL's project.
    There are a number of settings that may affect numerical operation / results of the compiler, but I have not found one that causes this code to fail. Review compiler settings.
    Also remember, when casting up and down from differing sizes, you sometimes have to be careful of the Endianess of your results. Casting usually works, but can be troublesome at times (normally fails when done through indirect using pointers).

    Good luck!
  • I upgraded to 5.4.0.0.18 my test project runs successfully. I made no changes to code or settings. Prior to upgrading I was getting 0xFFFFFFFF in the upper 32 bits of the 64 bit integer rather than 0x0000000 as it should be.
  • In reply to tshannon:

    Hmmmm. Changing the e2 studio version does not change anything in the generated code. So it is unlikely that updating e2 studio fixed the problem.
    At least it is working now as expected.
  • In reply to FrankL:

    The e2 studio upgrade was noise which makes sense given that the compiler version was the same. It turns out the actual variable is the debugger. I typically use a Segger J-Link Ultra+ for debugging on my target. When the project ran successfully I used an E1 on the RSK. If I switch to the Segger on the RSK, it fails. The only thing I change in the project is the debugger in the launch settings.
  • In reply to tshannon:

    This does not make any more sense. This would imply that the debugger changes the generated code, which it cannot.
    It may be that the variable display in J-link has a bug in that it which causes the upper 4 byte to show the wrong value. and it may have a problem when you change variable values manually. I haven't checked this. But if the application works using E1, it also has to work if you use J-Link Ultra+.
  • In reply to FrankL:

    When I use J-Link Ultra + I also see the wrong result. But this happens only when I use single step. When I do a simple run to breakpoint the calculations are correct. At least the failure counter does not count anything. I have a take a closer look at this later on.
  • In reply to FrankL:

    Frank - I had just discovered the same thing. Single stepping fails but simply running to a breakpoint at the end shows zero failures.
  • In reply to tshannon:

    I reported this to Segger and have tested a patch. The official fix will be in version 6.16e of the J-Link software.
  • This thread will be archived because the issue has been patched.

    Mike Clements
    RenesasRulz Moderator