Build errors with current master and armgcc 10.2.1: EEPROMEmulation

[smcharg]

Recently a build error has crept in due to what appears to be use of an uninitialized constant value for an array size in a virtual function. I'm wondering if there are some build paths which do no invoke an override for setting the value BYTES_PER_BLOCK.

An excerpt of the build output follows.

Any suggestions for a remedy?

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C freertos.armv7m all
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C console all
make[3]: Nothing to be done for all'. /Applications/Xcode.app/Contents/Developer/usr/bin/make -C utils all make[3]: Nothing to be done for all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C executor all
make[3]: Nothing to be done for all'. /Applications/Xcode.app/Contents/Developer/usr/bin/make -C os all make[3]: Nothing to be done for all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C dcc all
make[3]: Nothing to be done for all'. /Applications/Xcode.app/Contents/Developer/usr/bin/make -C openlcb all make[3]: Nothing to be done for all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C withrottle all
make[3]: Nothing to be done for all'. /Applications/Xcode.app/Contents/Developer/usr/bin/make -C freertos all make[3]: Nothing to be done for all'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C freertos_drivers all
/opt/armgcc/default/bin/arm-none-eabi-g++ -c -Os -fno-strict-aliasing -fno-strength-reduce -fomit-frame-pointer -fdata-sections -ffunction-sections -g -MD -MP -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -Wall -Werror -Wno-unknown-pragmas -fdata-sections -ffunction-sections -fno-builtin -fno-stack-protector -mfix-cortex-m3-ldrd -D__FreeRTOS__ -DGCC_ARMCM3 -specs=nano.specs -std=c++14 -D_ISOC99_SOURCE -D__STDC_FORMAT_MACROS -fno-exceptions -fno-rtti -Wsuggest-override -Wno-psabi -I./ -I/Users/sid/git/openmrn/src/ -I/Users/sid/git/openmrn/include -I/Users/sid/FreeRTOS/Source/include -I/Users/sid/FreeRTOS/Source/portable/GCC/ARM_CM3 -I/Users/sid/git/openmrn/include/freertos -idirafter /Users/sid/git/openmrn/include/freertos_select -I/Users/sid/git/openmrn/src/freertos_drivers/common -MD -MF EEPROMEmulation.d /Users/sid/git/openmrn/src/freertos_drivers/common/EEPROMEmulation.cxx -o EEPROMEmulation.o
In member function 'virtual void EEPROMEmulation::write(unsigned int, const void*, size_t)',
inlined from 'virtual void EEPROMEmulation::write(unsigned int, const void*, size_t)' at /Users/sid/git/openmrn/src/freertos_drivers/common/EEPROMEmulation.cxx:127:6:
/Users/sid/git/openmrn/src/freertos_drivers/common/EEPROMEmulation.cxx:162:21: error: variable-length array bound is unknown [-Werror=vla-larger-than=]
162 | uint8_t data[BYTES_PER_BLOCK];
| ^~~~
/Users/sid/git/openmrn/src/freertos_drivers/common/EEPROMEmulation.cxx:177:21: error: variable-length array bound is unknown [-Werror=vla-larger-than=]
177 | uint8_t data[BYTES_PER_BLOCK];
| ^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [EEPROMEmulation.o] Error 1
make[2]: *** [build-freertos_drivers] Error 2
make[1]: *** [build-freertos.armv7m] Error 2
make: *** [build-targets] Error 2
sids-imac:openmrn sid$ /opt/armgcc/default/bin/arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
`

[balazsracz]

This problem was introduced by GCC9. The code compiles fine with this version: ``` $ /opt/armgcc/default/bin/arm-none-eabi-g++ --version arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.1 20181213 (release) [gcc-8-branch revision 267074] Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` Usually compiler upgrades come with a dozen such issues, hence I move forward rather rarely. I can propose two things: 1) you could downgrade to the compiler to the one I use and be saved from such troubles; 2) or you could discover all issues caused by the upgrade and propose PRs to fix them. After that I will move forward with my compiler version. WDYT?