• State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 22 subscribers
  • Views 3645 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

Defect insice ARM compiler intrinsic memset function

Jaroslav Fojtík

I have found severe defect inside ARM cor Cortex-M3 compiler. It occurs only in release build.

And this is compilation result. Only 8 bytes is cleared, by using STR.

0x00013F06 F88D5008 STRB r5,[sp,#0x08]
23: UINT8 data[9];

64: continue;
65: }
66:
0x00013F42 E00F B 0x00013F64

67: memset(data,0, sizeof(data));
70:
0x00013F44 9504 STR r5,[sp,#0x10]
0x00013F46 9505 STR r5,[sp,#0x14]

71: if(ReadBlockFromSRAM(data, addr, sizeof(data)))
72: {
0x00013F48 2209 MOVS r2,#0x09

=============================================================

When I use:
x2 = sizeof(data);
memset(data,0,x2);

It works fine.

Parents
  • 0 in reply to Tamiryan Michael

    "Because the last memset address THE STACK using STR (not STRB), it will indeed overwrite one byte...! Tested on CM0 (LPC1114) device."

    Is that actually a problem?

    <speculate>
    The compiler would probably have aligned the 7 byte array to a multiple of 4 (or is it 8?). It knows what it has done, so the compiler writer's logic might be that clearing an extra (unused) byte should not be an issue and would be a faster operation.
    </speculate>

Reply
  • 0 in reply to Tamiryan Michael

    "Because the last memset address THE STACK using STR (not STRB), it will indeed overwrite one byte...! Tested on CM0 (LPC1114) device."

    Is that actually a problem?

    <speculate>
    The compiler would probably have aligned the 7 byte array to a multiple of 4 (or is it 8?). It knows what it has done, so the compiler writer's logic might be that clearing an extra (unused) byte should not be an issue and would be a faster operation.
    </speculate>

Children
  • 0 in reply to IB Shy

    The compiler would probably have aligned the 7 byte array to a multiple of 4 (or is it 8?). It knows what it has done, so the compiler writer's logic might be that clearing an extra (unused) byte should not be an issue and would be a faster operation.

    Make perfect sense, but the behavior I observed with the little sample I posted is as follows:

    First, 7 times 4 is written to the buffer (not altering the last, 8th byte).
    Then, 7 (not 8!) 1 is written to the buffer (not altering the last, 8th byte).
    Finally, clearing 8 (not 7) bytes to 0.
    Why the difference?

    Is this still consistent? I am not sure this is a tool chain issue but it looks strange to me.

  • 0 in reply to Tamiryan Michael

    Is this still consistent? I am not sure this is a tool chain issue but it looks strange to me.

    It's not a problem at all. As long as the program output is correct, there is nothing to worry about. You will discover more strange things when studying compiler output as compilers perform more advanced optimizations with time. It only becomes a problem when a program malfunctions at high optimization levels and you suspect a compiler bug: pinpointing the bug can be extremely hard.