Ticket #477 (Fixed)Wed Dec 04 21:43:47 UTC 2019
cc 5.79 64bit arithmetic optimisation bug
| Reported by: | Jeffrey Lee (213) | Severity: | Critical |
| Part: | RISC OS: C/C++ toolchain | Release: | |
| Milestone: | Status | Fixed |
Details by Jeffrey Lee (213):
cc 5.79 appears to have an optimisation bug that results in incorrect code generation for some 64bit arithmetic operations. Specifically, it sometimes produces this type of broken output:
MOV a2,#0
LDR a2,[sp]
ADC a1,a2,a2
Instead of this correct output (seen with cc 5.78):
MOV a2,#0
ADC a3,a2,#0
LDR a2,[sp]
ADD a1,a3,a2
This is seen with the “acc3 += ctx->s3 + (uint32_t) ( d >> 32U )” line in the poly1305_compute_mac function in mbedTLS.
Comparing the disassembly of poly1305.c built using the new and old compiler, it looks like there may be a general problem where the new compiler is averse to optimising “MOV z,#0 ; ADC x,y,z” down to “ADC x,y,#0”. Not necessarily a problem in itself, except in this case where it’s reused the register containing the zero value.
Changelog:
Modified by Jeffrey Lee (213) Wed, December 04 2019 - 21:55:53 GMT
- Attachment added: test
Actually, it’s not the “acc3” line, it’s one of the earlier ones, probably part of the “acc + -(2^130 – 5)” calculation.
Test source file attached (poly1305_compute_mac function from mbedTLS). Default compiler settings should result in the bad output being produced (e.g. “%cc -s test.c”). Look for the differences around lines 42-48 of the assembler file. I did try stripping out some bits of the function to make the test case shorter, but that resulted in different code generation which doesn’t trigger the bug.
Modified by Sprow (202) Wed, January 08 2020 - 13:19:18 GMT
- Status changed from Open to Fixed
AcornSSL back to reality (see https://www.riscosopen.org/forum/forums/11/topi…) with cc 5.80
