View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0033952||FPC||Compiler||public||2018-07-08 13:47||2019-01-13 11:51|
|Product Version||3.1.1||Product Build||39409|
|Target Version||Fixed in Version||3.3.1|
|Summary||0033952: AVR, output string corrupt if compiled with optimization level -O2.|
|Description||The 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 (https://github.com/Laksen/fp-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.
|Tags||No tags attached.|
|Fixed in Revision||40848|
string_corrupt.zip (7,224 bytes)
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.
||Confirmed bug as described above with trunk 40709.|
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
// missing mov r23, r1 or ldi r23, 0 to zero out previous value in r23
#  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?
||How about using "-OoNOCSE" switch?|
||The CSE optimization is inactive by default for the AVR target. Explicitly setting -OoNOCSE or -OoCSE doesn't make a difference for this case.|
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
#  s:= s + 0000013#10;
||Thanks for the analysis. Should be fixed now.|
|2018-07-08 13:47||Bernd||New Issue|
|2018-07-08 13:47||Bernd||File Added: string_corrupt.zip|
|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|