| 2019-03-02 11:13:51 |
Tony |
bug |
|
|
added bug |
| 2019-03-02 11:13:51 |
Tony |
attachment added |
|
Source code for bug https://bugs.launchpad.net/bugs/1818326/+attachment/5242783/+files/BigEndianBug.c |
|
| 2019-03-02 11:28:36 |
Tony |
description |
If a 16-bit integer is loaded from memory as a little-endian, and then immediately again as a big-endian, the compiler optimises away the second load, but forgets to switch its endianness. The attached file BigEndianBug.c shows the problem: f2 returns 0x1234 instead of the expected 0x3412.
Incidentally, there is a minor problem in f1 too: the uxth instruction is redundant. (This is still the case at optimisation level O3.)
Compile command:
arm-none-eabi-gcc.exe" -c -oBigEndianBug.o -march=armv6-m -mthumb -Wall -Wa,-a,-adn -O1 BigEndianBug.c >BigEndianBug.lst
Compiler version:
arm-none-eabi-gcc.exe (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
Running on Windows 10. |
If a 16-bit integer is loaded from memory as a little-endian, and then immediately again as a big-endian, the compiler optimises away the second load, but forgets to switch its endianness. The attached file BigEndianBug.c shows the problem: f2 returns 0x1234 instead of the expected 0x3412.
Incidentally, there is a minor problem in f1 too: the uxth instruction is redundant. (This is still the case at optimisation level O3.)
Compile command:
arm-none-eabi-gcc.exe" -c -oBigEndianBug.o -march=armv6-m -mthumb -Wall -Wa,-a,-adn -O1 BigEndianBug.c >BigEndianBug.lst
Compiler version:
arm-none-eabi-gcc.exe (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
(but these problems were also there in version 7 2018-q2-update).
Running on Windows 10. |
|
| 2019-03-02 12:01:45 |
Tony |
description |
If a 16-bit integer is loaded from memory as a little-endian, and then immediately again as a big-endian, the compiler optimises away the second load, but forgets to switch its endianness. The attached file BigEndianBug.c shows the problem: f2 returns 0x1234 instead of the expected 0x3412.
Incidentally, there is a minor problem in f1 too: the uxth instruction is redundant. (This is still the case at optimisation level O3.)
Compile command:
arm-none-eabi-gcc.exe" -c -oBigEndianBug.o -march=armv6-m -mthumb -Wall -Wa,-a,-adn -O1 BigEndianBug.c >BigEndianBug.lst
Compiler version:
arm-none-eabi-gcc.exe (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
(but these problems were also there in version 7 2018-q2-update).
Running on Windows 10. |
If a 16-bit integer is loaded from memory as a little-endian, and then immediately again as a big-endian, the compiler optimises away the second load, but forgets to switch its endianness. The attached file BigEndianBug.c shows the problem: f2 returns 0x1234 instead of the expected 0x3412.
Incidentally, there is a minor problem in f1 too: the uxth instruction is redundant. (This is still the case at optimisation level O3.)
Compile command:
arm-none-eabi-gcc.exe -c -oBigEndianBug.o -march=armv6-m -mthumb -Wall -Wa,-a,-adn -O1 BigEndianBug.c >BigEndianBug.lst
Compiler version:
arm-none-eabi-gcc.exe (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074]
(but these problems were also there in version 7 2018-q2-update).
Running on Windows 10. |
|
| 2019-03-02 17:36:28 |
Tony |
attachment removed |
Source code for bug https://bugs.launchpad.net/gcc-arm-embedded/+bug/1818326/+attachment/5242783/+files/BigEndianBug.c |
|
|
| 2019-03-02 17:36:52 |
Tony |
attachment added |
|
BigEndianBug.c https://bugs.launchpad.net/gcc-arm-embedded/+bug/1818326/+attachment/5242873/+files/BigEndianBug.c |
|
