arm-none-eabi-gcc: Some platforms not building with v6.1.1-2 #5519

miri64 · 2016-06-06T10:33:19Z

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 text was updated successfully, but these errors were encountered:

miri64 · 2016-06-06T10:42:42Z

(The samd21 error was actually caused by an update to newlib ;-))

Kijewski · 2016-06-06T13:43:41Z

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;
}

#endif

miri64 · 2016-06-06T13:48:42Z

I guess just excluding the code when #if !ADC_NUMOF would be the way to go ;-)

Kijewski · 2016-06-06T13:51:27Z

You're right. An error message at link-time could be considered more useful than odd errors at runtime. :)

jnohlgard · 2016-06-13T07:36:55Z

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.

OlegHahm · 2016-06-13T09:47:12Z

I'll add a note to the README to avoid new users being confused.

jnohlgard · 2016-07-18T18:33:32Z

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}^'

OlegHahm · 2016-07-18T23:25:24Z

Is ARM7 even officially supported by this version?

jnohlgard · 2016-07-19T09:51:03Z

@OlegHahm I believe it is. lpc2387 is of the family ARM7TDMI which uses the armv4t architecture which should be supported in GCC.

OlegHahm · 2016-07-19T12:43:15Z

Thanks for the clarification.

kYc0o · 2016-07-26T12:40:13Z

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.

kYc0o · 2016-11-01T22:38:33Z

We still have this bug?

miri64 · 2016-11-01T22:41:05Z

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]

kYc0o · 2016-11-01T22:43:37Z

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.

miri64 · 2016-11-01T22:44:07Z

(mine is Ubuntu 16.04 LTS ;-))

miri64 · 2016-11-01T22:45:38Z

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 :-/

kYc0o · 2016-11-01T22:48:19Z

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.

miri64 · 2016-11-04T16:30:58Z

There might be a new issue with GCC 6 (RIOT-OS/Release-Specs#28) so I'm leaving this open.

OlegHahm · 2017-01-14T11:17:28Z

I think all issues have been resolved with the most up-to-date gcc6 version.

kYc0o · 2017-02-28T13:19:37Z

@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...

miri64 added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Platform: ARM Platform: This PR/issue effects ARM-based platforms labels Jun 6, 2016

miri64 assigned jnohlgard Jun 6, 2016

miri64 mentioned this issue Jun 12, 2016

stm32: compiler errors in DAC #5543

Closed

OlegHahm added this to the Release 2016.07 milestone Jun 12, 2016

jnohlgard mentioned this issue Jul 5, 2016

cpu: Fix array-bounds errors with GCC 6 #5602

Merged

OlegHahm closed this as completed in #5602 Jul 14, 2016

jnohlgard reopened this Jul 18, 2016

kYc0o modified the milestones: Release 2016.10, Release 2016.07 Jul 26, 2016

miri64 modified the milestones: Release 2017.01, Release 2016.10 Nov 4, 2016

OlegHahm closed this as completed Jan 14, 2017

kaspar030 mentioned this issue Aug 29, 2017

README.md: remove obsolete gcc6 issue warning #7534

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

arm-none-eabi-gcc: Some platforms not building with v6.1.1-2 #5519

arm-none-eabi-gcc: Some platforms not building with v6.1.1-2 #5519

miri64 commented Jun 6, 2016

miri64 commented Jun 6, 2016

Kijewski commented Jun 6, 2016 •

edited

Loading

miri64 commented Jun 6, 2016

Kijewski commented Jun 6, 2016

jnohlgard commented Jun 13, 2016

OlegHahm commented Jun 13, 2016

jnohlgard commented Jul 18, 2016

OlegHahm commented Jul 18, 2016

jnohlgard commented Jul 19, 2016 •

edited

Loading

OlegHahm commented Jul 19, 2016

kYc0o commented Jul 26, 2016

kYc0o commented Nov 1, 2016

miri64 commented Nov 1, 2016

kYc0o commented Nov 1, 2016

miri64 commented Nov 1, 2016

miri64 commented Nov 1, 2016

kYc0o commented Nov 1, 2016

miri64 commented Nov 4, 2016

OlegHahm commented Jan 14, 2017

kYc0o commented Feb 28, 2017

arm-none-eabi-gcc: Some platforms not building with v6.1.1-2 #5519

arm-none-eabi-gcc: Some platforms not building with v6.1.1-2 #5519

Comments

miri64 commented Jun 6, 2016

miri64 commented Jun 6, 2016

Kijewski commented Jun 6, 2016 • edited Loading

miri64 commented Jun 6, 2016

Kijewski commented Jun 6, 2016

jnohlgard commented Jun 13, 2016

OlegHahm commented Jun 13, 2016

jnohlgard commented Jul 18, 2016

OlegHahm commented Jul 18, 2016

jnohlgard commented Jul 19, 2016 • edited Loading

OlegHahm commented Jul 19, 2016

kYc0o commented Jul 26, 2016

kYc0o commented Nov 1, 2016

miri64 commented Nov 1, 2016

kYc0o commented Nov 1, 2016

miri64 commented Nov 1, 2016

miri64 commented Nov 1, 2016

kYc0o commented Nov 1, 2016

miri64 commented Nov 4, 2016

OlegHahm commented Jan 14, 2017

kYc0o commented Feb 28, 2017

Kijewski commented Jun 6, 2016 •

edited

Loading

jnohlgard commented Jul 19, 2016 •

edited

Loading