View Issue Details

IDProjectCategoryView StatusLast Update
0033952FPCCompilerpublic2019-01-13 11:51
ReporterBerndAssigned ToFlorian 
Status closedResolutionfixed 
Product Version3.1.1Product Build39409 
Target VersionFixed in Version3.3.1 
Summary0033952: AVR, output string corrupt if compiled with optimization level -O2.
DescriptionThe output string is corrupt, if the program is compiled with optimization level -O2. The program runs fine with optimization levels -O1 and -O3. I noticed this on an ATMega2560, when I sent strings over the UART. The problem is reproducible with Laksens avrsim ( too.

This seems to be a regression which was introduced with fpc revision 38487/38488. Revision 38486 does not show this problem.

Attached is the test project.
TagsNo tags attached.
Fixed in Revision40848
Attached Files



2018-07-08 13:47

reporter (7,224 bytes)


2018-12-29 12:33

reporter   ~0112977

I would like to put this issue on top again.
I checked again with trunk 3.3.1, revision 40685 and the compiled binary showed the same problem with optimization level -O2.
There is no problem with -O1, -O3 and -O4. I am a little bit worried, since the rtl is by default compiled with -O2.

Christo Crause

2019-01-05 10:49

reporter   ~0113186

Confirmed bug as described above with trunk 40709.

Christo Crause

2019-01-05 12:05

reporter   ~0113189

This seems to be a subtle bug that only becomes visible in a very specific scenario - where the register r23 carries a non-zero value but isn't cleared before the call to fpc_shortstr_to_shortstr. This causes the length comparison between source and destination to be wrong, leading in this case to the assignment of the maximum length of the destination (20 in the example attached), resulting in spurious characters in the result.

In the original attachment the bug can be seen by noting that r23 is assigned in the Delay procedure (just below label .Lj5) and not cleared again before the first call to fpc_shortstr_to_shortstr in Dbg_WriteLn. Relevant code snippet from debugsim.s:

# Var s located in register r18
    mov r20,r18
    ldi r22,20
// missing mov r23, r1 or ldi r23, 0 to zero out previous value in r23
    ldi r24,lo8(2)
    ldi r25,hi8(2)
    add r24,r28
    adc r25,r29
    call fpc_shortstr_to_shortstr
# [37] s:= s + 0000013#10;

Note that correct code is only generated under no optimization, at any optimization level the above clearing of r23 is absent, probably because the previous assignment to r23 happened in a separate unit, so the optimizer isn't aware of this at compile time?

Do-wan Kim

2019-01-05 16:44

reporter   ~0113192

How about using "-OoNOCSE" switch?

Christo Crause

2019-01-06 06:10

reporter   ~0113199

The CSE optimization is inactive by default for the AVR target. Explicitly setting -OoNOCSE or -OoCSE doesn't make a difference for this case.


2019-01-06 11:52

reporter   ~0113201

this is generated with the last working revision 38486 and optimization level -O2. r23 seemed to be cleared before calling fpc_shortstr_to_shortstr.

# Var s located at r28+2, size=OS_16
    std Y+2,r24
    std Y+3,r25
    ldd r18,Y+2
    ldd r21,Y+3
    mov r20,r18
    ldi r22,20
    mov r23,r1
    ldi r24,lo8(4)
    ldi r25,hi8(4)
    add r24,r28
    adc r25,r29
    call fpc_shortstr_to_shortstr
# [37] s:= s + 0000013#10;


2019-01-12 14:31

administrator   ~0113350

Thanks for the analysis. Should be fixed now.


2019-01-13 11:51

reporter   ~0113374

Thank you.

Issue History

Date Modified Username Field Change
2018-07-08 13:47 Bernd New Issue
2018-07-08 13:47 Bernd File Added:
2018-12-29 12:33 Bernd Note Added: 0112977
2019-01-05 10:49 Christo Crause Note Added: 0113186
2019-01-05 12:05 Christo Crause Note Added: 0113189
2019-01-05 16:44 Do-wan Kim Note Added: 0113192
2019-01-06 06:10 Christo Crause Note Added: 0113199
2019-01-06 11:52 Bernd Note Added: 0113201
2019-01-12 14:31 Florian Fixed in Revision => 40848
2019-01-12 14:31 Florian Note Added: 0113350
2019-01-12 14:31 Florian Status new => resolved
2019-01-12 14:31 Florian Fixed in Version => 3.3.1
2019-01-12 14:31 Florian Resolution open => fixed
2019-01-12 14:31 Florian Assigned To => Florian
2019-01-13 11:51 Bernd Note Added: 0113374
2019-01-13 11:51 Bernd Status resolved => closed