RM57L843: ARM-CGT-CLANG: incorrect code generation for local struct under -Os

Part Number: RM57L843

I'm working with a program that needs to compute IP checksums, and it seems like there's a bug in the tiarmclang compiler. When I compile bug-report.c (using ARM-CGT-CLANG 4.0.3.LTS) under -Os, it drops lines 102 and 103:

		fakehdr.zero = 0;
		fakehdr.protocol = protocol;

That is, the values are never stored to offsets 8 and 9 in memory. Then the output of the checksum computation is incorrect.

Compiling under -O0 produces the correct output (values are stored to offsets 8 and 9).

The bug seems to have been introduced sometime between 3.2.3.LTS and 4.0.0.LTS. The bug continues to exist up through 5.0.0.STS. 

3.2.3.LTS:
      84: 68d0          ldr     r0, [r2, #12]
      86: 2400          movs    r4, #0
      88: 6912          ldr     r2, [r2, #16]
      8a: f88d 1009     strb.w  r1, [sp, #9]
      8e: 4661          mov     r1, r12
      90: f88d 4008     strb.w  r4, [sp, #8]
      94: 9000          str     r0, [sp]
      96: fa9c f09c     rev16.w r0, r12
      9a: 9201          str     r2, [sp, #4]
      9c: f8ad 000a     strh.w  r0, [sp, #10]
      a0: 4618          mov     r0, r3
      a2: f7ff fffe     bl      0xa2 <checksum+0xa2>    @ imm = #-4
4.0.0.LTS:
      74: 68d0          ldr     r0, [r2, #0xc]
      76: ba4c          rev16   r4, r1
      78: 6912          ldr     r2, [r2, #0x10]
      7a: f8ad 400a     strh.w  r4, [sp, #0xa]
      7e: e9cd 0200     strd    r0, r2, [sp]
      82: 4618          mov     r0, r3
      84: f7ff fffe     bl      0x84 <checksum+0x84>    @ imm = #-0x4
5.0.0.STS:
      72: 68d0          ldr     r0, [r2, #0xc]
      74: ba4c          rev16   r4, r1
      76: 6912          ldr     r2, [r2, #0x10]
      78: f8ad 400a     strh.w  r4, [sp, #0xa]
      7c: e9cd 0200     strd    r0, r2, [sp]
      80: 4618          mov     r0, r3
      82: f7ff fffe     bl      0x82 <checksum+0x82>    @ imm = #-0x4
  • Thank you for notifying us of this problem, and for submitting a test case.  I am able to reproduce this behavior.  I filed the issue EXT_EP-13228 to have it investigated.  You are welcome to follow it with that link.  For now, the description of the problem is vague.  Once the bug is characterized, the description is changed to be more specific.

    Thanks and regards,

    -George