arm-none-eabi-gcc: Some platforms not building with v6.1.1-2
miri64 opened this issue · comments
Arch just gave me a shiny new version of GCC to play with and I got some issues building examples/default now:
$ make -C examples/default/ buildtest
make: Entering directory '/home/martine/Repositories/RIOT-OS/RIOT/examples/default'
Building for airfy-beacon .. success
Building for arduino-due .. success
Building for arduino-mega2560 .. success
Building for avsextrem .. success
Building for cc2538dk .. success
Building for cc2650stk .. success
Building for chronos .. success
Building for ek-lm4f120xl .. success
Building for f4vi1 .. failed
Building for fox .. failed
Building for frdm-k64f .. success
Building for iotlab-m3 .. failed
Building for limifrog-v1 .. failed
Building for mbed_lpc1768 .. success
Building for msb-430 .. success
Building for msb-430h .. success
Building for msba2 .. success
Building for msbiot .. success
Building for mulle .. success
Building for native .. success
Building for nrf51dongle .. failed
Building for nrf52dk .. success
Building for nrf6310 .. failed
Building for nucleo-f072 .. failed
Building for nucleo-f091 .. failed
Building for nucleo-f103 .. success
Building for nucleo-f303 .. failed
Building for nucleo-f334 .. failed
Building for nucleo-f401 .. failed
Building for nucleo-l1 .. failed
Building for openmote-cc2538 .. success
Building for pba-d-01-kw2x .. success
Building for pca10000 .. failed
Building for pca10005 .. success
Building for pttu .. success
Building for qemu-i386 .. success
Building for remote .. success
Building for saml21-xpro .. failed
Building for samr21-xpro .. failed
Building for slwstk6220a .. success
Building for spark-core .. success
Building for stm32f0discovery .. failed
Building for stm32f3discovery .. success
Building for stm32f4discovery .. success
Building for telosb .. success
Building for udoo .. success
Building for weio .. success
Building for wsn430-v1_3b .. success
Building for wsn430-v1_4 .. success
Building for yunjia-nrf51822 .. success
Building for z1 .. success
/home/martine/Repositories/RIOT-OS/RIOT/Makefile.buildtests:38: recipe for target 'buildtest' failed
make: *** [buildtest] Error 1
make: Leaving directory '/home/martine/Repositories/RIOT-OS/RIOT/examples/default'
Among the boards failing are some of our most important ones. Here's a collection of a few errors I managed to identify:
/home/martine/Repositories/RIOT-OS/RIOT/cpu/stm32_common/periph/dac.c: In function 'dac_set':
/home/martine/Repositories/RIOT-OS/RIOT/cpu/stm32_common/periph/dac.c:76:19: error: array subscript is above array bounds [-Werror=array-bounds]
if (dac_config[line].chan) {
~~~~~~~~~~^~~~~~
/home/martine/Repositories/RIOT-OS/RIOT/cpu/stm32_common/periph/dac.c: In function 'dac_poweron':
/home/martine/Repositories/RIOT-OS/RIOT/cpu/stm32_common/periph/dac.c:91:38: error: array subscript is above array bounds [-Werror=array-bounds]
DAC->CR |= (1 << (16 * dac_config[line].chan));
~~~~~~~~~~^~~~~~
/home/martine/Repositories/RIOT-OS/RIOT/cpu/stm32_common/periph/dac.c: In function 'dac_poweroff':
/home/martine/Repositories/RIOT-OS/RIOT/cpu/stm32_common/periph/dac.c:96:39: error: array subscript is above array bounds [-Werror=array-bounds]
DAC->CR &= ~(1 << (16 * dac_config[line].chan));
~~~~~~~~~~^~~~~~
cc1: all warnings being treated as errors
/home/martine/Repositories/RIOT-OS/RIOT/cpu/samd21/include/samd21.h:230:0: error: "LITTLE_ENDIAN" redefined [-Werror]
#define LITTLE_ENDIAN 1
In file included from /usr/arm-none-eabi/include/sys/types.h:67:0,
from /usr/arm-none-eabi/include/stdio.h:48,
from /home/martine/Repositories/RIOT-OS/RIOT/examples/default/main.c:25:
/usr/arm-none-eabi/include/machine/endian.h:17:0: note: this is the location of the previous definition
#define LITTLE_ENDIAN _LITTLE_ENDIAN
cc1: all warnings being treated as errors
/home/martine/Repositories/RIOT-OS/RIOT/cpu/nrf51/periph/adc.c: In function 'adc_sample':
/home/martine/Repositories/RIOT-OS/RIOT/cpu/nrf51/periph/adc.c:80:41: error: array subscript is above array bounds [-Werror=array-bounds]
(1 << (adc_config[line] + 8)) |
~~~~~~~~~~^~~~~~
cc1: all warnings being treated as errors
Obvious workaround for now is not to update, but for the future I think it's beneficial (also with #1121 in mind) to fix those warnings.
(The samd21 error was actually caused by an update to newlib ;-))
The various adc.c use an illegal array definition: static const uint8_t adc_config[] = {};. GCC and Clang seem ignores this unless you actually subscript this array in your code.
Proposed fix:
#ifdef ADC_CONFIG
static const uint8_t adc_config[] = ADC_CONFIG;
int adc_sample(adc_t line, adc_res_t res)
{
…
}
#else
int adc_sample(adc_t line, adc_res_t res)
{
(void) line, (void) res;
return -1;
}
#endifI guess just excluding the code when #if !ADC_NUMOF would be the way to go ;-)
You're right. An error message at link-time could be considered more useful than odd errors at runtime. :)
I will keep this issue in mind during the summer and fix this in steps, any patches are welcome.
Please reference this issue number (#5519) for any PRs that fix anything related to GCC-6.
I am currently building a GCC 6 toolchain on my system and can test any PRs related to this.
I'll add a note to the README to avoid new users being confused.
Reopening because lpc2387 fails with current release of GCC-6 (arm-none-eabi-gcc-6.1.0)
Should be fixed in 6.2.0 (unreleased), see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70830
Building for msba2 .. failed
Building application "default" for "msba2" with MCU "lpc2387".
/tmp/ccl0WCcs.s: Assembler messages:
/tmp/ccl0WCcs.s:103: Error: push/pop do not support {reglist}^ -- `pop {r0,r1,r2,r3,ip,pc}^'
Is ARM7 even officially supported by this version?
@OlegHahm I believe it is. lpc2387 is of the family ARM7TDMI which uses the armv4t architecture which should be supported in GCC.
Thanks for the clarification.
Since this bug is being fixed in a new compiler version, I'll move it to the next release to wait for such new version, then test if it really solves this and close it.
We still have this bug?
Seems like it... I'm not sure what you meant by "new compiler version". The one on Ubuntu is currently
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
According to @gebart comment this is solved in gcc 6.2.0, but It don't know if it was already released and included to any LTS distribution.
(mine is Ubuntu 16.04 LTS ;-))
Wait... what am I talking about... this issue only effects GCC 6... so sorry about the noise... Don't know about other toolchains of other distributions either :-/
Yes it's OK, and the news say that GCC 6.2 was released, maybe we can wait for an input from @gebart if he has a way to test it in such GCC version.
There might be a new issue with GCC 6 (RIOT-OS/Release-Specs#28) so I'm leaving this open.
I think all issues have been resolved with the most up-to-date gcc6 version.
@OlegHahm Would you mind to re-modify the README about this issue? It's one of the first things we see when we come to the repo so it can scare people...