• Locked Locked
  • Replies 4 replies
  • Subscribers 119 subscribers
  • Views 4314 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

armcc problem?

Ric Peregrino
Note: This was originally posted on 20th April 2009 at http://forums.arm.com

Hello,

We're using armcc here version:
  ARM/Thumb C/C++ Compiler, RVCT3.1 [Build 739]

And it seems to have an issue. Here's some simple c-code:

  main () {
    volatile unsigned int tmp32;

    printf ("GPIO: 1_reset: before\n");

    // touch tb_gpio
    *(unsigned int *)(0x50000004) = 0x12345678;
    tmp32 = *((volatile unsigned int *)(0x50000004));
    printf ("GPIO: tmp32 = 0x%0x\n", tmp32);
    printf ("GPIO: tmp32 = 0x%0x\n", tmp32);
    if (tmp32 != 0x12345678) printf("FAIL: 1st tb_gpio WRV failed!\n");

Here's the resulting output:

  # GPIO: 1_reset: before 
  # GPIO: tmp32 = 0x12345678
  # GPIO: tmp32 = 0x0
  # FAIL: 1st tb_gpio WRV failed!

Why is the 2nd printf of tmp32 different? Here's the disassembled code, and it seems that the first printf is printing not tmp32 which is in r4, but the literal that was written, which is in r6:

       0x00040082:    4e2b        +N      LDR      r6,[pc,#172]  ; [0x40130] = 0x12345678
        0x00040084:    f04f45a0    O..E    MOV      r5,#0x50000000
        0x00040088:    606e        n`      STR      r6,[r5,#4]
        0x0004008a:    686c        lh      LDR      r4,[r5,#4]
        0x0004008c:    4631        1F      MOV      r1,r6
        0x0004008e:    a029        ).      ADR      r0,{pc}+0xa6 ; 0x40134
        0x00040090:    f000fcf6    ....    BL       __0printf  ; 0x40a80
        0x00040094:    4621        !F      MOV      r1,r4
        0x00040096:    a027        '.      ADR      r0,{pc}+0x9e ; 0x40134
        0x00040098:    f000fcf2    ....    BL       __0printf  ; 0x40a80

This make sense? Is this an armcc bug? If so, what next?

Cheers,
Ric Peregrino
Dust Networks
Parents
  • Arm Employee Badge
    Note: This was originally posted on 22nd April 2009 at http://forums.arm.com

    Hi Ric, 

    My usual fixes for compiler bugs when no patch is available it to try a lower optimization level for the file in which the bug occurs, or try restructuring the code to see if it "goes away".

    Splitting the known buggy function out into a separate file can reduce the impact of the lower optimization level, because the other code can still be compiled at -O3.

    Raising the issue formally with ARM support (email support@arm.com) may be able to provide more information.
Reply
  • Arm Employee Badge
    Note: This was originally posted on 22nd April 2009 at http://forums.arm.com

    Hi Ric, 

    My usual fixes for compiler bugs when no patch is available it to try a lower optimization level for the file in which the bug occurs, or try restructuring the code to see if it "goes away".

    Splitting the known buggy function out into a separate file can reduce the impact of the lower optimization level, because the other code can still be compiled at -O3.

    Raising the issue formally with ARM support (email support@arm.com) may be able to provide more information.
Children
No data